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
• MPU6886
• 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]

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.

[jonnor]

Agreed that when latency is important, then using a (hard) ISR is the best way to go!

[peterhinch]

Some eight years ago, when MP was young, three of us (as the organisation micropython-imu) collaborated on IMU drivers. The principal application area that we envisaged was in control systems, hence we opted to ignore any FIFO but to require hard IRQ compatibility. We reasoned that, with a hard IRQ, users needing a FIFO could simply implement a queue and access it via asyncio. This is a flexible option: for example users might want to enqueue a timestamp with each sample.

We never anticipated the advent of devices unable to offer hard IRQ's, nor did we consider gesture detection. I think these issues may have changed the game somewhat.

If anyone is planning to summarise IMU chips and drivers I would suggest highlighting the following categories:

• FIFO support.
• Hard IRQ support.
• Built-in sensor fusion.
• Quaternion output.

The latter two are a very big deal IMO (see BNO055). Realtime sensor fusion is quite demanding if you have to do it in code.

[jonnor]

I needed FIFO support for MPU6886, and have implemented that now at https://github.com/jonnor/micropython-mpu6886/ - installable with mip, of course.