Accelerometer crate

[tarcieri]

Well, I hope this wasn't overly ambitious/audacious to do without really talking to anyone about it, but I made an accelerometer crate:

• repo: https://github.com/NeoBirth/accelerometer.rs
• crate: https://crates.io/crates/accelerometer
• docs: https://docs.rs/accelerometer/

What is it?

There are presently three parts to it:

• An object-safe Accelerometer trait which presently has a single acceleration method to obtain a reading from a device.
• A set of 2D and 3D vector types and a corresponding Vector trait. These types should hopefully follow the same naming conventions (e.g. F32x3) and have the same structure (e.g. { x, y, z }) as I've seen people using in the existing accelerometer crates I've surveyed and therefore be a "drop in" replacement for most, but add niceties like component iterators, a few built-in vector arithmetic operations I've needed, and the ability to implement algorithms generically over 2D and 3D vectors.
• An Error type, intended to (but not constrained to) allow you to pass along an optional embedded-hal error as a cause, e.g. I2CError, or potentially signal other errors (e.g. incompatible device)

Future plans

Above: Demo of the orientation tracker on the Adafruit NeoTrellis M4 using the ADXL343 accelerometer driver I wrote (still a bit glitchy)

My real goal was to add Orientation tracking which uses a generic implementation that can work with any 3-axis accelerometer. I've seen madgwick and it looks very awesome, however my device lacks a gyroscope and magnetometer. But that's okay, because the information I'm trying to obtain is rather coarse-grained.

I have a WIP PR that includes some things like statistical analysis and outlier culling, intended to filter noisy data.

This feels NIH / I could do it better!

I poked around a little bit for some prior art around the general problems I was trying to solve in this crate. In addition to madgwick I came across coord (abandoned/deprecated), and vek, which both provide no_std-compatible 2D and 3D vector libraries (or are supposed to be, but it seems vek isn't actually no_std-compatible right now although it seems to be a small yak shave away).

Perhaps using vek makes sense: it implements quaternions, which I understand are all the rage for computing these sorts of spatial problems quickly, and are used by madgwick. It doesn't quite have all of the formulas I need yet but that seems like a problem solvable through PRs.

I'd be curious what authors of other accelerometer crates would think of switching to something like vek as the vector type, versus what I've implemented in the accelerometer crate which I hope follows existing Rust embedded accelerometer crate conventions but adds standard types with all the formulas you'd want to do vector arithmetic on accelerometer data.

If, on the other hand, people do like the vector types in this crate, but want to use them for things other than accelerometers, they could probably be extracted into their own separate crate.

All that said, if there's any other prior art around this sort of thing I missed, my apologies!

Move to WG org?

I'd be happy to move this crate over to the Rust Embedded WG GitHub org and potentially add some additional crate owners who can publish it if there's interest in that sort of thing.

[tarcieri]

Note: vek's author @yoanlcq suggested that the issues around no_std support might be quite difficult to fix (see https://github.com/yoanlcq/vek/issues/24)

[jamesmunns]

Closing this as part of the 2024 triage effort. IMO this is likely outside the scope of the embedded-hal team.

Please feel free to let me know if you disagree, and we can discuss at the next meeting on Matrix.