I have seen people say that the MPU6000 is the superior gyro chip, even though the ICM chip has a faster refresh rate and is technically superior in any other use.
Why is it better to have a lower refresh rate on a drone’s gyro?
Drones and Model Aircraft Stack Exchange is a question and answer site for experienced flyers, pilots, and builders of drones and model aircraft. It only takes a minute to sign up.
Sign up to join this communityI have seen people say that the MPU6000 is the superior gyro chip, even though the ICM chip has a faster refresh rate and is technically superior in any other use.
Why is it better to have a lower refresh rate on a drone’s gyro?
It's not superior, it's just good enough, cheap enough and may be more noise resistant than ICM20602.
There's a bunch of flight controllers with dual IMUs onboard. For example, Lumenier Lux F7 has MPU6000 and ICM20602, you can choose which one to use. SP Racing F7 and H7 series use two ICM20602s fused together.
Also, there's BrainFPV Radix which uses BMI160 from Bosch Sensortec. It should, in theory, provide a more clean and noise resistant signal without the need for complicated software filtering.
Refresh rate is another thing in itself. Things start to get worse with higher refresh rates: you get all sorts of noises internal and external to the IMU, which can negatively affect motor speed regulation, which in turn might make motors run hot or even fry. Also, higher refresh rates require more processing power to filter the noise. Running IMU at 8+ kHz with RPM filtering gobbles up CPU pretty quick to the point that the quad even refuses to arm.
There has been a good deal of discussion on this topic, and it has been no small source of conflict between several of the main firmware players in the high-performance DIY drone flight controller world. The short version is that based on evidence gathered from flight recorder logs, the ICM series gyros are more sensitive to electrical and mechanical noise than the MPU6000 gyro.
One of the major issues is that the MPU6000 is considered NR/ND (Not recommended for new designs) since 2017-ish, and there is some question as to how much longer it will be available. This makes manufacturers hesitant about using it in new designs.
The core of the argument around the ICM gyro has to do with the DLPF bypass mode that enables 32 Khz read rates (see section 9.17 in the datasheet for the ICM 20602). There is one school of thought that this mode simply gives lower-level access to the same data that is used by the internal DLPF to create the 8 Khz data output, and external software filters can do a better job than the internal DLPF used to create the hardware-given 8 Khz data. There seems to be a good deal of support however that this is not the case. It appears that moving the gyro into 32 Khz read mode actually reduces the fundamental accuracy of the readings being taken. Mark Spatz has done a good deal of work logging and analyzing data recordings from multiple gyros with the conclusion that 32 Khz in experimental mode is producing data that is both different and dramatically less accurate than when not in experimental mode, though why disabling the internal DLPF would have this impact still remains a question.
Even taking this into account, the ICM series gyros can perform essentially as well as the MPU600 when care is taken. Many of the issues seen with the ICM gyros result from poorly executed filtering on the 3.3v power supply. See this research article for an exploration of why this is a problem. Essentially if the power supply lines can be kept clean, and the internal DLPF is kept on, the gyro seems to perform decently.
All that being said, having been involved in support in the drone industry for a while though, my personal experience has been that flight controllers that use the ICM gyro have a higher failure rate and a higher chance of having issues than flight controllers with the MPU6000. I have a shelf full of flight controllers I pulled due to ICMs that became too sensitive to tune, and much larger number of folks I've helped debug with the same issue, but I've not had that issue with MPU6000. While this is purely anecdotal, it aligns with the experience of enough pilots that it has become a common thought in the DIY drone hobby, hence the reason why this question even came up.