Abstract
For those 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 toward proper in situ assessment of sensor capability. One of the most common challenges is establishing time-coherent data capture, at data rates that MEMS IMUs require, for the best available performance and digital post-processing capacity. Main loops in computing platforms can be as slow as 10 Hz and often run on platforms that cannot support interrupt-driven data capture, based on data updates, from sensing functions. This article identifies techniques that system developers can use to manage the gap between slow/asynchronous computing loops and high performance data capture and processing in MEMS IMUs (>1000 Hz).
Introduction
In a recent editorial, PNT expert Dana Goward identified society’s overreliance on GPS-provided, position navigation timing services (PNT).1 Faced with a complex set of threats to existing GPS/GNSS PNT services, many navigation platform developers must quickly assess emerging technologies, which can help address vulnerabilities to their current PNT strategies. Guidance navigation control (GNC) systems for autonomous vehicles (AV) are one example of such systems that must identify a complex set of threats, which are associated with loss or corruption of PNT services.
In fact, many 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 who are using microelectromechanical systems (MEMS) inertial measurement units (IMUs) for the first time, establishing data coherence at sample rates that support the best available performance can be a significant challenge. Even in early prototyping and preliminary field trials, sample rates and synchronization can make a difference, especially when system developers are relying on preliminary results to inform their longer-term requirements in the development process. Therefore, identifying and optimizing key operating attributes (of a MEMS IMU) is an important first step.
MEMS IMU
MEMS IMUs typically include triaxial linear acceleration and triaxial angular rate (gyroscopes) sensing, along (and around) three mutually orthogonal axes. Figure 1 illustrates the inertial reference frame, along with each sensor’s polarity and axis assignments.
Autonomous Ground Vehicle (AGV) Use Case
Figure 2 illustrates a simplified flowchart for the main processing loop of an 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.
For illustration, the main loop acquires data from the video and wheel-based odometers at the main loop rate of 50 Hz, while it updates GPS/PNT data at a rate of 10 Hz. The first generation of this AGV provides basic supply delivery service between buildings at an airbase. In the next generation, AGV operators must evaluate additional sensors for managing partial GPS outages (such as only two GPS satellites available) and they need to upgrade to GNC to double the velocity over complex, off-road terrains. The ADIS16576 MEMS IMU is the first candidate for evaluation.
The first challenge is to address the large gap (factor of 80) between the loop update rate and the sample rate at which the MEMS IMU will provide the best available performance and operation. Increasing the processing loop of the GNC system will require major changes, which may not be practical 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 MEMS IMU in this particular use case? The answer lies in optimizing a combination of the following operational attributes: data reduction, time coherence, synchronization2, 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: 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. 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 the use of digital filtering in the MEMS IMU’s signal chain. For example, when adapting the ADIS16576 to the system in Figure 2, setting its Bartlett FIR 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, make sure that the data widths will support the resultant bit growth. In this specific example, the system processor will need to acquire two 16-bit registers (32 bits total) for each inertial sensor. Accommodating this requirement (32-bit inertial sensor data) will increase the communication sequence time from 24 μs to 40 μs, when using a burst-read command, with a serial clock frequency of 8 MHz and a 4 μs allocation for communication overhead.
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 ADIS16576 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 provides a flowchart 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.
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 flowchart in Figure 2. Since the system clock is operating at 50 Hz and this device provides the best performance at 4000 Hz, set the clock scale 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 of 50 Hz, but with a fixed latency with respect to the system clock reference (video sync).
Data Buffering
Data buffering is a useful technique for cases that value maximum data sample rates but must start their initial field trials with platforms that can only provide synchronous data communication service. System architects can implement data buffering by making this a requirement in their IMU selection or by pairing the IMU with a co-located, embedded processor.
Using the same example from Figure 2, while disabling all onboard filtering in the ADIS16576, the on-board FIFO will collect 80 samples during one cycle of the main loop. Since this configuration uses no filtering (in the IMU’s signal chain), systems can optimize the communication times by using 16-bit data formats. 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.
Conclusion
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 AV developers who are seeking to manage both expansion of their mission profiles, along with the increasing threats to their existing PNT services.
References
1 Dana Goward. “US Dangerously Behind, PNT Leadership Needed.” GPS World, July 2024.
2 Mark Looney. “Synchronizing MEMS IMUs with GPS in Autonomous Vehicles.” Inside GNSS, May 2024.