You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)
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 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.
The text was updated successfully, but these errors were encountered:
Well, I hope this wasn't overly ambitious/audacious to do without really talking to anyone about it, but I made an
accelerometer
crate:What is it?
There are presently three parts to it:
Accelerometer
trait which presently has a singleacceleration
method to obtain a reading from a device.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.Error
type, intended to (but not constrained to) allow you to pass along an optionalembedded-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 seenmadgwick
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 provideno_std
-compatible 2D and 3D vector libraries (or are supposed to be, but it seemsvek
isn't actuallyno_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 bymadgwick
. 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 theaccelerometer
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.
The text was updated successfully, but these errors were encountered: