For those seeking to assess inertial sensing solutions for the first time, existing computing and I/O resources may limit data rates and synchronisation 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 10Hz 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 (>1000Hz).
Introduction
In a recent editorial, PNT expert Dana Goward identified society’s overreliance on GPS-provided, position navigation timing services (PNT). 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 synchronisation 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 optimising 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 50Hz, while it updates GPS/PNT data at a rate of 10Hz. 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 optimising a combination of the following operational attributes: data reduction, time coherence, synchronisation, 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 20Hz.
Setting its decimation filter to average 80 sequential samples for each data update will reduce its output data rate (ODR) to 50Hz. 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 8MHz and a 4μs allocation for communication overhead.
For those seeking to assess inertial sensing solutions for the first time, existing computing and I/O resources may limit data rates and synchronisation 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 10Hz 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 (>1000Hz).
Introduction
In a recent editorial, PNT expert Dana Goward identified society’s overreliance on GPS-provided, position navigation timing services (PNT). 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 synchronisation 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 optimising 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 50Hz, while it updates GPS/PNT data at a rate of 10Hz. 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 optimising a combination of the following operational attributes: data reduction, time coherence, synchronisation, 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 20Hz.
Setting its decimation filter to average 80 sequential samples for each data update will reduce its output data rate (ODR) to 50Hz. 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 8MHz and a 4μs allocation for communication overhead.
By Mark Looney, Applications Engineer, Analog Devices
This article originally appeared in the April’26 magazine issue of Electronic Specifier Design – see ES’s Magazine Archives for more featured publications.
