Optimizing MEMS IMU data coherence and timing in navigation systems

Story

November 25, 2024

Mark Looney

Analog Devices

Systems developers can use certain techniques to manage the gap between slow/asynchronous computing loops and high-performance data capture and processing in MEMS IMUs [micro-electromechanical system inertial measurement units] (MEMS IMUs >2000 Hz). Quick prototyping that provides time-relevant representation of MEM IMU responses will be an important step for defense-industry autonomous vehicle (AV) developers, who are seeking to manage both expansion of their mission profiles, along with the increasingly serious threats to their existing position, navigation, and timing (PNT) services.

In a recent editorial in GPS World, expert Dana Goward identified society’s overreliance on GPS-provided position, navigation, and timing (PNT) services1. Faced with a complex set of threats to existing GPS/GNSS [global navigation satellite system] PNT services, many navigation-platform developers must quickly assess emerging technologies, which can help address vulnerabilities to their current PNT strategies. For those that are seeking to assess inertial sensing solutions for the first time, existing computing and I/O resources may limit data rates and synchronization functions, which might impede progress towards proper, in-situ assessment of sensor capability.

Many autonomous vehicle (AV) developers and operators are facing several challenges that are forcing them to consider adding inertial sensors to their platforms for the first time. For those that are using MEMS inertial measurement units (IMUs) for the first time, establishing data coherence at sample rates that support best-available performance can be a major challenge. Even in early prototyping and preliminary field trials, sample rates and synchronization can make a difference, especially when systems developers are relying on preliminary results to assist their requirements-development process. Therefore, identifying and optimizing key operating attributes (of a MEMS IMU) is an important first step in the development process.

The MEMS IMU

MEMS IMUs typically include triaxial linear acceleration and triaxial angular rate (gyroscopes) sensing, along (and around) three mutually orthogonal axes. Figure 1 provides an illustration of the inertial reference frame, along with each sensor polarity and axis assignments.

[Figure 1 ǀ Shown: an illustration of an inertial reference frame.]

Autonomous ground vehicle use case

Figure 2 illustrates a simplified flow chart for the main processing loop of an autonomous ground vehicle (AGV) that uses video, wheel-based odometry, and GPS for inertial navigation and tracking. The dotted lines also illustrate adding an operation to read the six inertial sensors from the ADIS16576 MEMS IMU into this loop.

[Figure 2 ǀ Shown: a simplified autonomous ground vehicle (AGV) processing flow chart.]

For purposes of illustration, the main loop will acquire data from the video and wheel-based odometers at the main loop rate of 50 Hz, while it will update GPS/PNT data at a rate of 10 Hz. The first generation of this AGV provided basic supply-delivery service between buildings at an airbase; in the next generation, the AGV operators must start evaluating additional sensors for managing partial GPS outages (such as only two GPS satellites available) and need to upgrade to guidance navigation control (GNC) to double the velocity over complex, off-road terrains.

The first challenge to address is that the example IMU per-forms best when operating at or near its natural sample rate of 4000 Hz, which is 80 times faster than the present AGV processing loop. Increasing the processing loop of the GNC system will require major changes, a move that is impractical for the first prototypes and preliminary field trials. What can be done to ensure that the preliminary field trials have the best chance to evaluate the merit of the IMU in this particular use case? The answer lies in optimizing a combination of the following operational attributes: data reduction, time coherence, synchronization, and buffering.

Data reduction

Reducing the data rate can be as simple as acquiring data at a slower rate. However, this approach can undersample the signals, which can introduce errors, especially under conditions at which AGV platforms are most reliant on the MEMS IMU for feedback sensing: that is, highly dynamic motion and environmental profiles. MEMS IMU core sensors (accelerometers, gyroscopes) and signal chains often have bandwidths that are wider than most other AGV sensing platforms. For example, the cut-off frequency is greater than 500 Hz in both linear and angular rate sensors on the ADIS16576. Therefore, reducing the bandwidth needs to be part of any strategy for reducing the data rates in the inertial signals.

One convenient method for managing this vulnerability is through use of digital filtering in the MEM IMU’s signal chain. For example, when adapting the ADIS16576 to the system in Figure 2, setting its Bartlett FIR [finite impulse response] filter to 64 taps per stage will reduce the cutoff frequency to approximately 20 Hz. Setting its decimation filter to average 80 sequential samples for each data update will reduce its output data rate (ODR) to 50 Hz. When employing these filters, the user must make sure that the data widths will support the resultant bit growth. In the case of the ADIS16576, this will require reading 32-bit data widths, through two separate 16-bit registers, for each inertial sensor. When using a burst-read command with a serial clock of 8 MHz, the communication sequence will require less than 40 μs.

Time coherence

After optimizing the data rates and associated bandwidth, the next opportunity for optimization comes from establishing time coherence between the IMU data sampling and a system clock reference. For purposes of illustration, let’s define the video sync (50 Hz) as the system reference. When operating in its factory-default configuration, the example IMU will use an internal clock reference, which inevitably will have some mismatch with the video sync. When the IMU’s ODR is lower than the video sync, the consequence will be reading “stale data” on occasion. When the IMU’s ODR is faster than the video sync, the consequence will be missed samples. The frequency of this occurrence will depend on the scale of the mismatch between each clock. Another limitation will be that the latency of the IMU data will vary by an entire sample cycle (20 ms = 1/50 Hz).

There are two different methods for establishing stronger time coherence. The first method is to use the IMU’s data-ready signal to trigger IMU data collection. Figure 3 is a flow chart that checks for IMU data after two different operations. This approach will eliminate the problem of missing data samples, to establish a time-coherent flow of IMU data, at the main loop rate of 50 Hz. This concept can also expand to check for “new data” in the IMU in-between the GNC processing and video read as well.

[Figure 3 ǀ A simplified AGV processing flow chart shows IMU interrupts.]

External synchronization

Another method for establishing time coherence and precise latency is to use external synchronization features on the MEMS IMU. The ADIS16576 offers two primary options: direct and scaled. Using the scaled sync mode will be the most appropriate mode for the flow chart in Figure 2. Since the system clock is operating at 50 Hz and the ADIS16576 performs best at 4000Hz, the clock scale should be set to a factor of 80. When used in conjunction with the on-board filtering, the outcome will still be a bandwidth of 20 Hz and an ODR, but with a fixed latency, with respect to the system clock reference (video sync).

Data buffering

In cases where AGV architects are evaluating a MEMS IMU for mission profiles that must push for “best-available” response times, they may need to sample rates that are beyond their current loop rates, as soon as practical in their prototyping. Data buffering provides a useful technique in this scenario and can provide flexibility to system processors to read IMU data at different times during their main processing loop. This approach may require the use of a co-located processor or use of an IMU that provides a first-in/first-out (FIFO) buffer function, if the IMU does not include a FIFO function.

Using the same example from Figure 2, while disabling all on-board filtering in the ADIS16576, the on-board FIFO will collect 80 samples during one cycle of the main loop. Since the on-board filters are not in operation, best-available performance is available in the 16-bit data widths. Therefore, the AGV processor can acquire all 80 samples, for all six inertial samples, in less than 4 ms, when using a serial clock of 8 MHz and a stall time of 6 μs, between each 16-bit communication segment.

Prototype first

Getting the most out of a MEMS IMU may drive substantial architectural change. Prior to making large investments in such upgrades, optimizing available digital features can help AGV developers evaluate their use cases and eventually, develop credible requirements for meeting their most important operational objectives. Quick prototyping that provides time-relevant representation of MEMS IMU responses will be an important step for autonomous vehicle developers who are seeking to manage both expansion of their mission profiles and need to counter the increasingly serious threats to existing PNT services. MES

Note

¹ Goward, Dana, “U.S. Dangerously Behind, PNT Leadership Needed,” GPS World, July 2024. https://www.gpsworld.com/us-dangerously-behind-pnt-leadership-needed.

Mark Looney joined Analog Devices, Inc. (ADI) in 1998 and is currently the Application Engineering Manager for the Inertial Sensing Technology Group. He earned BS and MS degrees in electrical engineering from the University of Nevada. Since joining the industry in 1995, Mark has worked in development, characterization and system-level integration of inertial sensing, high-speed analog-to-digital conversion, clock management, power management, and embedded processing technologies. Prior to joining ADI, Mark was a design engineer for Interpoint Corp. and was a founding member of IMATS, a vehicle fleet and traffic solutions start-up company.

Analog Devices, Inc. (ADI) https://www.analog.com