[Feature] IMU cleanups

[laurensvalk]

This task is split from pybricks/pybricks-micropython#156 so we can look at it separately.

---

https://github.com/pybricks/pybricks-micropython/blob/0a0332f5a9cb8b33b9d8f67f85badf51a408331b/lib/pbio/drv/imu/imu_lsm6ds3tr_c_stm32.c#L203

We probably need to verify what the actual sampling rate is, or measure it as we go. Similarly, we'll want to check if we are occasionally missing a few samples or not.

We'll also need to check this on Technic Hub, where the I2C setup is slightly different, in case there are any difference.

Once that is settled, we may need to experimentally verify lsm6ds3tr_c_from_fs2000dps_to_mdps and adjust as needed. Possibly per axis, see also below.

---

There is currently no adjustment for misalignment of the chip within the hub. This is possible using a calibration routine (see #943), but the benefit is fairly small for everyday users.

However, it may be useful to do this locally when we test for sample rates as above, to ensure we register the full Z measurement when tweaking lsm6ds3tr_c_from_fs2000dps_to_mdps.

---

In pbio, there is currently not a global pbio_imu instance that gets passed around, since there is only one imu instance. It may still be useful to make the code easier to follow.

---

Originally posted by @laurensvalk in pybricks/pybricks-micropython#156 (comment)

[laurensvalk]

Hmm... if [init] fails, won't calling other functions later cause a crash due to uninitialized values?

Originally posted by @dlech in pybricks/pybricks-micropython#156 (comment)

[laurensvalk]

Should raise NotImplementedError instead?

Originally posted by @dlech in pybricks/pybricks-micropython#156 (comment)

should this return PBIO_ERROR_INVALID_ARG if use_gyro is true on move hub (#if !PBIO_CONFIG_DRIVEBASE_USE_GRYO`)?

Originally posted by @dlech in pybricks/pybricks-micropython#156 (comment)

Probably better struct packing/smaller code size if this is the last item in the struct.

Originally posted by @dlech in pybricks/pybricks-micropython#156 (comment)

Intuitive drivebase integration still needs a bit of work. The COUNTERCLOCKWISE direction should probably also be done at the pbio level, not the module as we do know.

[laurensvalk]

Probably can do without the union here (we can cast to float * if we really need to but better if we just use the struct everywhere).

Or if we really must keep the union, the outer struct is redundant and we can just say typedef union {.

Originally posted by @dlech in pybricks/pybricks-micropython#156 (comment)

[laurensvalk]

On Technic Hub, it never becomes stationary with the default settings. So as per OP, we need to dig into the sensor configuration a bit more. It does become stationary if you double them to:

hub.imu.set_stationary_thresholds(angular_velocity=3, acceleration=500)

EDIT: Solved in #1026

[laurensvalk]

We probably need to verify what the actual sampling rate is, or measure it as we go. Similarly, we'll want to check if we are occasionally missing a few samples or not.

I wonder if the scale varies slightly per hub. One one hub, the heading seems to be off by a few degrees after one full rotation.

[dlech]

• Rename orientation.h to imu.h
• Drop #include <pbdrv/imu.h> and fix copyright date in above
• Rename pbio_orientation_set_base_orientation() to pbio_imu_set_base_orientation()
• Mark pbio_imu_init() as internal (doxygen `@condition INTERNAL``) or move to separate header file.

[laurensvalk]

Yeah, those are already done and pushed, just not merged to master yet.

[laurensvalk]

It turns out the sampling rate of the pbdrv_imu_lsm6ds3tr_c_stm32_process is quite different even between two Prime Hubs (826 Hz, vs 844 Hz). Once running on a particular hub, it is very constant.

It would be easy enough to compensate by measuring the frequency at runtime, but is there an explanation for this?

[laurensvalk]

It would be easy enough to compensate by measuring the frequency at runtime, but is there an explanation for this?

Done via pybricks/pybricks-micropython@1dbc334

[dlech]

but is there an explanation for this?

Since the IMU doesn't have an external crystal oscillator, there is never going to be an accurate (as noted) or stable (e.g. could change with temperature) clock on the IMU chip.

[laurensvalk]

• Update settings setter to match API in pybricks/pybricks-api@28ecc06

[laurensvalk]

The most critical parts here are now done and the implementation now matches the API proposal in pybricks/pybricks-api#137

[laurensvalk]

This is done.