Implementing an IMU/accelerometer/gyro driver? Use the FIFO!

[jonnor]

Hi everyone, my name is Jon. I work on machine learning for sensor systems, including condition monitoring of machines (at Soundsensing), and an open-source TinyML library called emlearn.

The use cases we care about often require high quality data and low-power. When using MicroPython in this area, I have noticed one limitation in the ecosystem: The lack of FIFO support in IMU drivers. So here is my attempt at raising this concern, and how we could address it :)

Current state of IMU drivers

Most of the IMU drivers out there today have functions to read the current values of the accelerometer/gyro/magnetometer data. Each call of the function returns a single datapoint in time. Example: (x, y, z) = get_xyz(). When one only does a single reading of the data, this works rather OK. For example, to check the current orientation of a rarely moving object, say for asset tracking.
However, many applications requires continious sampling of several samples. Examples include tracking a moving object, detect gestures, implement a regulation loop (PID), measure vibrations etc.

Problems with continuous sampling using repeated polling

Here is some example code for illustrating continuous sampling. At a slow 25 Hz and processing 1 second time-windows.
This could for example be human activity detection on a smartwatch, gesture detection, animal activity detection on a LoRa tracker, et.c.

SAMPLERATE = 25
THRESHOLD = 25 
sensor = SomeIMU(i2c=machine.I2C(...))
samples = []
while True:
    t = time.ticks_ms()
    xyz = sensor.get_xyz()
    samples.append(xyz)

    if len(samples) == THRESHOLD:
        process_samples(samples)
        samples = []

    # Try compensate for execution time causing variation in data sampling time
    # But - if more than 1/SAMPLERATE (4ms for 25 Hz) - will miss the entire timestep...
    time_spent = time.ticks_diff(time.ticks_ms(), t)

    # Very little benefit from lightsleep on very short durations
    wait_time = max(1000/SAMPLERATE - time_spent, 0)
    time.sleep_ms(wait_time)

Doing continuous sampling by fetching single samples is less-than-ideal for several reasons:

1. Any variation/delay in time of reading causes uneven sampling of data. Jitter/noise.
2. The microcontroller must be constantly running. High power consumption.
3. Hard for the program to do other work concurrently, while ensuring 1)

These problems become particular painful at high sample rates, or in low-power / battery-powered scenarios, or when trying to do multiple things at the same time (concurrency).

These concerns are generally independent of the programming language (more of a system design issue). However - there are a couple of reasons why it can easily be more problematic in MicroPython:

1. Variable delays in execution time due to garbage collection.
   When MicroPython code executes, there will at some point be a need to do some garbage collection. The likelihood increases with how much allocations the code does, but can generally happen at any point in time. One garbage collection run may take many milliseconds, and will cause the data to be sampled at the wrong time. This can mess up the results of many types of analysis - because they rely on regularly sampled data. Most methods from Digital Signal Processing, control theory, or Machine Learning expect regularly sampled data.

2. Execution time might be too slow for high samplerates.
   To read at 1kHz+, code would need to spend under 1 ms per iteration, which can be hard to achieve in MicroPython.

The solution: Use the FIFO buffer of the sensor

Any recent digital MEMS IMU will have a buffer that it can collect measurements into. Typically, this is referred to as a FIFO, since it is a First In First Out type of buffer/queue. For example, the LIS2dh/LIS3dh accelerometers have a 32 samples deep FIFO for its 3 axes. And BMA421 can store up to 1024 bytes, allowing to store 170 samples of tri-axial data.

When enabling FIFO mode, the sensor itself is responsible for timing the sampling. This means that it will be done at the correct time, independently of what our application code is doing. We can then spend time doing other things, or sleep. As long as one reads the FIFO before it overflows, one gets perfectly sampled data - with minimum computational effort.

How to implement

To support this kind of usage, the IMU driver should have:

• A function to enable FIFO sampling mode
• A function to read the FIFO fill level
• A function to read data from the FIFO. A)
• Optionally: A function to enable interrupts. B)

A) I recommend that the data reading returns the raw bytes.
This enables the application to decide when/if to convert to a physical unit (such as gravity). Sometimes it is useful to just store or process the raw values.

B) Most IMUs also support triggering an interrupt when the FIFO fill level has reached a certain threshold (watermark).
This can be useful to get absolutely the most out of, but is not critical. One can still get most of the benefits still by polling the FIFO level
and triggering readout based on that. It might also be that the interrupt pin is not connected, only I2C/SPI pins, so one should still support usage without interrupts.

Application code example with FIFO

Here is some illustrative code for how such a driver could be used in the same scenario as above.

SAMPLERATE = 25
THRESHOLD = 25 # NOTE: Should be max 75% of IMU FIFO capacity
imu = SuperIMU2k(i2c=machine.I2C(...), odr=SAMPLERATE)

while True:
    level = imu.get_fifo_level()
    if level < THRESHOLD:
        samples = imu.read_fifo_data(THRESHOLD)        

        # Can take up to 100 ms without needing to compensate sleep time
        # Or up to 1000ms if one does the compensation
        process_samples(samples) 

    machine.lightsleep(100)

This code will spend 90-99% of the time in lightsleep, for 10-100x power savings.
It will also work if using high samplerates (1000 Hz+) - will just need to reduce sleep times a bit.
And the same approach will work to collect data from multiple sensors running concurrently.

Call to Action: Use the FIFO!

So next time you are implementing a driver for an IMU, please consider supporting using the FIFO!
It will make the driver much more powerful and useable for a wider range of scenarios,
enabling people to get higher data quality and lower power consumption.

Drivers with FIFO support

Here is an initial start of divers that support FIFO.
Please let us know if you have made, or found more, and we can link them here!

• BMA423
• LIS2DH/LIS3DH
• BMP390 by @jornamon
• Your driver here

[jornamon]

I couldn’t agree more with your assessment of the usefulness and importance of taking advantage of the sensor FIFO, especially in MicroPython. I reached similar conclusions and followed a similar approach while writing a driver for the BMP390 pressure and temperature sensor.

[jonnor]

Thanks for your work on that driver. It was nice to have as a reference when I did the first FIFO implementation for a driver in MicroPython. I have added your driver to the list now!

[Josverl]

To raise visibility on awesome micropython, I'd suggest adding a comment or simple badge ⏩, or even a subsection for drivers that support fifo

[mattytrentini]

Fully agree, though I do prefer to use a watermark interrupt :)

I've raised a PR to add @antirez and @jornamon's drivers to the awesome list - and add the badge as @Josverl suggested.

@jonnor we should turn your gist into a 'proper' driver that's mip-installable and then add that. Or perhaps it would be best to add FIFO support to the existing LIS2MDL and LIS3MDL drivers? They look otherwise quite full-featured and well-documented.

[peterhinch]

@jonnor I agree with most of this, except for your suggestion of use within a control system feedback loop (e.g. PID controller). A FIFO introduces latency - a time delay which is anathema to control systems. In these applications precise timing and minimal latency arre paramount.

There are IMU controllers which support reading in a hard ISR, which provides minimal latency and tight timing. See
bno055 and
MPU6050 9150 and 9250.

[jornamon]

The added latency was one of my main concerns initially because my project required a quick response to changes in pressure, though not exceptionally fast. However, in the case of the BMP390, the additional latency doesn’t have to be significant. If latency is a critical concern, you can still read from the FIFO almost as quickly as performing regular readings. There’s no strict requirement to wait for batch readings; instead, you can use batch readings as a fallback if a blocking process delays your reading.

In the context of low-power applications, it is indeed essential to sleep as much as possible, but this is by design, so the delay shouldn’t come as a surprise.

Ultimately, the suitability of using a FIFO depends on the specific application. If fast reaction time is crucial, any added latency can be detrimental. However, for tasks involving digital filtering, which are often used in control loops, I found that unevenly spaced or missing samples had a more negative impact than the latency itself. While it might take a bit longer to react, you can ensure that you are responding to complete and evenly spaced samples consistently. Feeding an incomplete or unevenly spaced stream of samples to digital filters can lead to unintended consequences, and I would argue that the best way to ensure perfect timing (not latency) is using the device FIFO, even better than an ISR.

I’m not completely sure, but I believe that, at least in the ESP32 port, even ISR are blocked by the garbage collector. Does this also happen in bare metal ports?

[peterhinch]

ESP32 supports only soft ISR's which can indeed be slow if there is conflict with GC. Bare metal ports such as STM32 and RP2 support hard IRQ's which pre-empt GC but have strict coding rules.

In a control system application such as a drone or a balancing robot, I would use a bare metal port with a hard IRQ and an IMU whose driver supported hard IRQ's. The aim is to have the control code running on a regular tick (typically ~5ms 200Hz) which simplifies algorithms for filtering and integration. If there are missed samples something is wrong with the code :) A system like this has a sample acquisition time which is consistent within a small number of μs.

[jornamon]

Oh! That explains my poor experiences with ISR-based sampling on ESP32.

The integrated connectivity and the huge amounts of PSRAM are so convenient that I tend to use ESP32.

Anyways, in this port the FIFO is a life saver, because when you, sooner or later, get to process the samples, you're at least guaranteed to have them evenly spaced.

[peterhinch]

Indeed. You can often reduce GC latency by calling gc.collect() regularly. This is because GC takes less time when there is less work to do. Also, relevant to some applications, you know exactly when this blocking will occur.

If you're using PSRAM make sure you have recent firmware. There was a change late last year which reduced GC time.

[jornamon]

Yes that's a good point. I'm aware of the recent changes in memory management on the esp32 port, but all the experiences I'm talking about are previous to these changes. Probably with these improvements the situation is better now. Before, with 8MB of PSRAM the blocking delay was huge, in the hundreds of ms iirc.