Skip to content

IMU support in firmware#42

Open
MoridinBG wants to merge 17 commits into
sghctoma:mainfrom
MoridinBG:firmware/imu
Open

IMU support in firmware#42
MoridinBG wants to merge 17 commits into
sghctoma:mainfrom
MoridinBG:firmware/imu

Conversation

@MoridinBG

Copy link
Copy Markdown
Contributor

This PR implements support for IMUs with a generic interface in imu_sensor and hardware specific implementations for LSM6DSO & MPU6050.

It defines 3 IMU positions - fork lowers, frame, rear axle.

It has the firmware changes from https://github.com/MoridinBG/sst/tree/firmware/tlv-file with some additional comments and renamings, without the dashboard changes.

It implements the same two step IMU calibration flow as described in the issue:

  1. The bike is static on level ground (make sure not to be on a slope).
  • Determines gyro bias
  • Records gravity vector to determine down
  1. The bike is on it's rear tire with the front in the air (make sure not to tilt it to the side or rotate the handlebar. It's tricky)
  • Samples gravity while tilted
  • Computes forward direction from gravity shift
  • Builds rotation matrix

After these two steps, the sensor is oriented so that when the bike is static:

  • X going positive is bike forward
  • Y going positive is bike left (brake side)
  • Z going positive is bike up (sky)

With this implementation, gravity is not removed - when bike is static on level ground the Z vector will read 1.00 (+/- noise), while X & Y are 0.00

There is an implementation for readings interpretation that is useful for debugging, but the forces from the ground, pedalling, breaking, shifting weight make it very unstable.
Data while in motion needs a very different approach.

Two step calibration, independent from sensor orientation on bike.
First finds the direction of gravity is found with the bike standing on level ground.
Then the bike is lifted on its rear tire with the front in the air and the forward direction is calculated. Take care in this step not to tilt the bike to the sides
My unit's SPI is broken and gives garbage data, so tested only over I2C
It's an old design so sensitivity is low, it is noisy, temp stability is bad and temp calibration is hard, but hey, it is very cheap!
Define optional fork, frame & rear IMUs over I2C/SPI
… for the required hardware in debug & release
@MoridinBG

MoridinBG commented Jan 4, 2026

Copy link
Copy Markdown
Contributor Author

This also introduces an interactive CMakePresets.json generator in generate_cmake_presets.py
After adding the IMUs there are now about 224 possible configuration combinations between sensors, picos, protocols, debug & release. I tried to generate them, but the VS Code picker struggles with that many.

The generator builds debug & release presets just for the hardware combination that the user picks hardware by hardware.

image

Also make the IMU buffer size dynamic, based on the number of enabled IMUs, as each entry is 6 int16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant