SoftFusion sensor framework with BMI, ICM, LSM6, MPU sensor implementations #200

New Issue

MrUnknownDE · 2026-04-05T17:52:12+02:00

MrUnknownDE commented

2026-04-05 17:52:12 +02:00

Originally created by @l0ud on 3/29/2024

Hi
This change is a is a collaborative effort among developers from Slime Discord to:

Reduce the amount of copy-pasting when implementing new IMUs.
Make adding new IMUs much quicker and simpler.
Support several new, promising IMUs in firmware.

Sfusion is based on a simplified version of 0.dev's BMI160 driver, providing a generic sensor framework with several calibration methods for very slim drivers focused on the low-level handling of particular IMUs.

This change adds support for the following IMUs:

BMI270 (good price/performance)
ICM42688 (similar to BMI270)
LSM6DS3TR-C (cheapest one)
LSM6DSV (best performing one)
LSM6DSR
LSM6DSO
MPU6050, without using its flaky onboard fusion.

All drivers were tested to be functional, some are already being used in many sets (LSM6DSV, partially BMI270).
One exception: MPU6050 sfusion driver may underperform until we find a way to change "restThGyr and restThAcc" in VQF based on the sensor. I would prefer to make this separate change, as this PR is already pretty large.
Driver code is written from scratch for Slime, so I don't expect any licensing problems. Required Bosch BMI firmware is provided in separated file and it's BSD-licensed.

Existing drivers were not affected except for the current ICM42688 implementation, which was removed as it didn't work.

Drivers are as minimal as possible to reduce code size not incorporating any external libraries and to have full control over IMU programming.

Other changes:

Significant SensorManager refactoring to reduce boilerplate code (like switch-cases for every IMU, ifdef with sensor addresses) and to reduce code size by not linking unused sensors.
Sensors' constructors were standardized to support SensorManager change.
The "Had data" flag was removed as I considered it not really useful and not supported by most sensors anyway.
Platform/Arduino versions were upgraded to have a toolchain with C++20, and the compiler was switched to use it. We checked functionality on ESP8266 and ESP32C3."

*Originally created by @l0ud on 3/29/2024* Hi This change is a is a collaborative effort among developers from Slime Discord to: - Reduce the amount of copy-pasting when implementing new IMUs. - Make adding new IMUs much quicker and simpler. - Support several new, promising IMUs in firmware. Sfusion is based on a simplified version of 0.dev's BMI160 driver, providing a generic sensor framework with several calibration methods for very slim drivers focused on the low-level handling of particular IMUs. This change adds support for the following IMUs: - BMI270 (good price/performance) - ICM42688 (similar to BMI270) - LSM6DS3TR-C (cheapest one) - LSM6DSV (best performing one) - LSM6DSR - LSM6DSO - MPU6050, without using its flaky onboard fusion. All drivers were tested to be functional, some are already being used in many sets (LSM6DSV, partially BMI270). One exception: MPU6050 sfusion driver may underperform until we find a way to change "restThGyr and restThAcc" in VQF based on the sensor. I would prefer to make this separate change, as this PR is already pretty large. Driver code is written from scratch for Slime, so I don't expect any licensing problems. Required Bosch BMI firmware is provided in separated file and it's BSD-licensed. Existing drivers were not affected except for the current ICM42688 implementation, which was removed as it didn't work. Drivers are as minimal as possible to reduce code size not incorporating any external libraries and to have full control over IMU programming. Other changes: - Significant SensorManager refactoring to reduce boilerplate code (like switch-cases for every IMU, ifdef with sensor addresses) and to reduce code size by not linking unused sensors. - Sensors' constructors were standardized to support SensorManager change. - The "Had data" flag was removed as I considered it not really useful and not supported by most sensors anyway. - Platform/Arduino versions were upgraded to have a toolchain with C++20, and the compiler was switched to use it. We checked functionality on ESP8266 and ESP32C3."

MrUnknownDE closed this issue

2026-04-05 17:52:12 +02:00

MrUnknownDE referenced this issue

2026-04-05 17:52:30 +02:00

mpu9250: fix magnetometer component issue introduced with #200 #296

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/SlimeVR-Tracker-ESP#200