ardupilot
ardupilot copied to clipboard
ArduPilot
Fast ICM42xxx performance
At faster gyro backend rates (e.g. 4khz) the per-tick CPU load becomes quite important. This change reduces the CPU load a couple of ways:
- Increases the SPI clock on the MatekH743 to 16Mhz for the ICM42xxx gyros which are rated at up to 24Mhz (cannot currently get higher than 12.5Mhz because of the clock divisor). This gives about a 30% reduction in per-tick time.
- Synchronizes the ticks with the data. Before there were a lot of redundant ticks because data wasn't quite ready. Now the next tick is calculated from the time at which data is received.
Would this also apply for the Zealot H743 which has a ICM-42688-P
Yes, but manufacturer would need to confirm it is safe
Would this also apply for the Zealot H743 which has a ICM-42688-P
Yes, but manufacturer would need to confirm it is safe
I've checked with QIo-Tek, they say this fix isn't necessary because their design doesn't have the problem this is fixing.
I've checked with QIo-Tek, they say this fix isn't necessary because their design doesn't have the problem this is fixing.
Which can only mean they are not using this chip
I've checked with QIo-Tek, they say this fix isn't necessary because their design doesn't have the problem this is fixing.
Which can only mean they are not using this chip
It needs to be tested. Will higher sampling make the sampling accuracy of the sensor different? We haven't conducted actual hardware testing yet. We need to compare with the previous sampling speed.
It needs to be tested. Will higher sampling make the sampling accuracy of the sensor different? We haven't conducted actual hardware testing yet. We need to compare with the previous sampling speed.
For the 42688 the sampling is all done at 32Khz regardless of ODR. Higher ODR allows higher AP filter settings. This issue is addressing some issues that might be seen with higher ODR - mostly because the tick latency becomes more important
