Launch your UAV from concept to sky faster and smarter

Choosing an ultra stable, low drift IMU for Mahymah: ICM42688P

By Milind

/

July 24, 2025

This is the third part of our series on the development of the Wint Mahymah flight controller, a powerful multi-domain system designed for demanding next generation UAVs. Building a flight controller for such diverse environments is a careful balancing act — combining high computational performance, precise sensing, and robust architecture within a compact and reliable design. In this blog, we'll walk through the key design choices, the trade-offs we evaluated, and the approach we ultimately adopted.

The previous part of this series talked about choosing an MCU which struck an appropriate compromise between performance, power efficiency, scalability, and long-term availability. This part continues from there and moves on to the next most important component in the stack: the Inertial Measurement Unit (IMU).

This sophisticated flight controller is being entirely designed and manufactured in India, embodying our philosophy of "Making in India, Making for the World."

Requirements and constraints while choosing an IMU

This section goes through the first part of the selection process - listing the requirements and constraints that must be considered while selecting the IMU and prioritizing them. This was a relatively quick process.

Requirements

  • Low-noise on both the accelerometer & gyroscope, critical for maintaining stability during fast maneuvers and in dynamic operating environments.
  • High-sampling rates, atleast 5 KHz (twice our intended loop frequency) providing the responsiveness needed for tight control loops and rapid disturbance rejection.
  • Strong thermal stability ensuring consistent sensor performance across wide temperature ranges and extended mission durations.
  • Fast SPI interface, allowing fast data transfer from the IMU to MCU (as compared to UART or I2C). Using SPI also allows the use of DMA, which doesn't work as well with other protocols.
  • Good documentation and support to facilitate platform-agnostic software driver design and implementation.
  • Low power consumption, for optimizing overall system efficiency, especially in battery-constrained autonomous systems.
  • Optional onboard processing of data, to reduce the load on the MCU while performing filtering and sensor fusion, and also add some extra redundancy.

Constraints

  • The sensor must have reasonable cost & availability.

The constraint listed above seems quite obvious, but presents an important point. We did not want to go with an exotic, cutting-edge sensor (such as photonics) which would be overkill for our purpose. We needed reasonable performance at reasonable pricing with strong availability, not a research platform, for a production-grade flight controller.

Based on the above, it was clear that most hobbyist sensors, such as the MPU6050/6000/9250 were not the best fit for us despite their ubiquity and low-cost. More modern sensors provided much better performance and power-consumption without being proportionally more expensive.

Vendors and options considered

Having listed the requirements, we finally narrowed down the search to 3 vendors - STMicroelectronics, Bosch & TDK. Each were popular silicon vendors with a strong supply-chain, support, documentation and portfolio of IMUs (and other sensors too).

Finally, we chose the ICM-42688P from TDK Invensense, as we found it to have low power-consumption and great performance. Here are all the options that we considered and why we rejected them -

  • ASM330LHH (automotive series 6-axis IMU) from STMicroelectronics - This was the next strongest contender due to its low-cost and great documentation, and even had slightly lower accelerometer noise compared to the ICM-42688P. It lost nonetheless, due to having a higher gyroscope noise-density and power-consumption (almost twice the power-consumption of the ICM-42688P). In most other aspects, it was fairly similar to the ICM-42688P.
  • BMI330 from Bosch - This was quickly rejected due to its higher noise density, slower SPI interface, and lower maximum output data rate, all of which made it unsuitable for the fast, high-resolution feedback loops required in next generation UAVs. Despite decent power efficiency and integrated features for gesture recognition, its overall dynamic performance and configurability fell short compared to TDK's ICM-42688-P and ST's offerings.
  • ICM-42670P from TDK - This was rejected due to its higher noise floor, reduced sampling rates, and significantly smaller FIFO. Although compact and power-efficient, this sensor did not align with the performance demands of high-speed, real-time control systems.

We've evaluated several newer IMUs that offer additional features on paper, but they often came with significantly higher noise density on both the gyroscope and accelerometer or slower output data rates and limited sampling capabilities. These trade-offs made them unsuitable for the level of precision and responsiveness we required.

Yet another reason for choosing the ICM-42688P is the fact that it is used in Pixhawk & CubePilot controllers as well. We want to choose our sensors based on the datasheet and numbers, but it also helps that a popular flight controller platform already uses the same sensor.

Designing an evaluation board

This section walks through the process of creating an evaluation board for the ICM-42688P, which is the next step after selecting the sensor. It would have been better to buy a pre-existing evaluation board, but we couldn't find any (atleast, not from a reliable source) and therefore decided to make our own.

The final board (labelled) looks as shown -

ICM-42688P Evaluation Board (PCB Breakout)

The evaluation board was designed to be simple, breadboard-friendly and re-usable beyond this project. It has the following features kept fairly simple and had the following features -

  • Dedicated voltage regulator and power LED - We used the LD39200 voltage regulator from ST, which is an ultra-low drop linear regulator with reverse current protection. The LD39200 has anadjustable voltage output and can supply a generous 2A. Additionally, it has a voltage drop of merely 0.13v at maximum load. Most importantly, the regulator has a wide input range, from 1.25v to 6v. In our case, we wanted 3.3v, and could power the board from an external 5v or 3.3v source without worrying about the sensor burning.
  • Separate headers for I2C, SPI and interrupts - The purpose of the breakout board is to break out the pins of the IC for convenient use. We decided to create separate rows for I2C and SPI on either side of the board, and make it breadboard friendly. This makes it much easier to evaluate the sensor than if the pins were shared and only on one side.
  • I2C address selection headers - These allow us to use shunt connectors to conveniently select the I2C headers, without messy wiring or ad-hoc soldering.
  • Pull-up resistor on Chip-Select and I2C Pins - This removes the need for external pull-up resistors, thus reducing evaluation time.

A potential improvement in the breakout would be the addition of the Adafruit Qwiic connector, which would make it compatible with a vast ecosystem of sensors.

Given that this sensor is an IMU, being able to mount it on a breadboard is quite helpful. This is because it can be mounted on a fixed platform with the other sensors, giving a stable and shared reference frame for all readings. If the pins were instead on a single side (requiring direct wiring to the MCU), all the sensors would be dangling from wires, making it impossible to test vibration resistance & sensor fusion algorithms.

Creating a platform-agnostic software driver

After designing the physical breakout board, we needed a robust software foundation to maximize the potential of the ICM-42688P. Our goal was to create a driver that wasn't just functional but adaptable across multiple platforms and projects. This approach aligns with our philosophy of building reusable components that provide long-term value.

Architecture for flexibility and performance

Our driver architecture provides a layered approach with clear separation of concerns -

The key to platform agnosticism lies in our Hardware Abstraction Layer (HAL). We designed an interface structure that defines the essential communication functions -

And functions of the following form -

The init, configuration and data functions implement the logic of executing a transaction with the IMU, by using the functions pointed to by the interface structure. This allows the consumer of the driver to implement the communication for their platform and communication protocol (SPI or I2C).

This structure allows us to inject platform-specific implementations while keeping the core driver logic consistent. Whether we're running on an STM32, ESP32, or any other microcontroller, the driver's behavior remains predictable.

Handling DMA in a cross-platform manner

For high-speed sampling applications like flight control, Direct Memory Access (DMA) is crucial. Our driver provides both polling-based and DMA-based reading modes.

Specifically when using DMA, the driver provides a function to start the DMA process, and another function which to be called on the completion of the DMA transfer. This allows the DMA read functionality to be performed in a cross-platform manner.

Instrumentation

Beyond simply using the sensor, the driver also includes instrumentation to provide insights into usage and speed-up debugging in case of errors or unexpected behaviour -

  • Performance metrics tracking - Our driver maintains statistics on communication speed and failure rate.
  • Self-diagnosis - Our driver implemented self-test functionality which works with the built-in self-test functionality of the sensor to give exceptional reliability.

Evaluation process

After finishing the hardware and software development process, the next steps are to thoroughly use the sensor in dynamic environments (such as stationary, vibrating, oscillating etc.) and test various sensor fusion algorithms.

The first part of the evaluation process is to individually test the breakout board and software driver with the STM32H7 MCU breakout board (from the previous part), similar to unit testing in software development. Once proper functioning has been determined, the next step is to place the sensor in various environments (static, vibrating, oscillating etc.) and characterize its tolerance, power-consumption etc.

After testing the sensor individually, the next step is to combine data from multiple sensors (multiple IMUs as well as other kinds of sensors) to characterize sensor fusion algorithms, which will be covered in a separate blog.

Handling Note for ICM-42688P

The ICM-42688-P is rated for Electrostatic Discharge (ESD) protection up to ±2000 V (HBM) and ±500 V (CDM), offering moderate robustness during handling. It is also compliant with JEDEC JESD78D standards for latch-up, with a tolerance of ±100 mA at 85 °C. Additionally, the device can withstand mechanical shock up to 10,000 g along any axis while unpowered.

Conclusion

The ICM-42688-P has emerged as a strong candidate, offering an excellent balance of performance, configurability, and noise characteristics in a compact and efficient package. To enhance reliability and improve resistance to drift and single-point failures, we plan to use three of these sensors on the flight controller for redundancy and cross-verification.

The next step involves choosing and evaluating a barometer (air-pressure sensor), which will follow a similar process to the IMU.

Through this blog, we hope to build transparency with our community by sharing our development and engineering process. If you have any thoughts or suggestions, you can share them with us at aerowint.com/contact, or write to our founders directly at milind@aerowint.com or aditya@aerowint.com.