Use for accelerometers and other embedded projects

[tarcieri]

Hello! This is just a heads up that I mentioned vek in an issue I opened on the Rust Embedded WG about an accelerometer crate:

rust-embedded/wg#340

It looks like vek might potentially be nice for these applications, aside from #20 which I think looks trivially fixable (I could potentially send a PR).

Anyway, if you have any thoughts on this I'd be curious, otherwise feel free to close this issue.

[yoanlcq]

Hi! Thanks for this, I appreciate it. 🙇‍♂️

I think the accelerometer crate is so thin that it could benefit from not actually enforcing specific vector types. IMO Accelerometer could be fn acceleration(&mut self) -> Result<[f32; 3], Error> and that would be fine, because it's trivially convertible to the relevant vector type of any math library (if it's supposed to return a 2D vector, just add a fn get_nb_elems() -> usize and set the unused elements to zero. This allows avoiding generics and make the API very lightweight).

Users won't mind; they will mind however if they picked nalgebra and your crate enforces a dependency on vek, in which case they end up with two different heavyweight math libraries in their app's dependency graph.

Assuming accelerometer delegates the math business to another crate, there's not much left aside from the Accelerometer trait and ErrorKind enum (there are many crates for error handling such as failure and error-chain, making Error somewhat redundant?).

If I were to start a project on an embedded platform with a need to get accelerometer data, I'd be way more interested in a collection of snippets that shows me how to get the data myself for that hardware; then I would use whichever data type I need or want (f32 ? u16 ? i16 ? depends on context), whichever math library I want, whichever error crate I want, and then write my app with all of that.
Maybe I would make an Accelerometer trait, but maybe not. Most likely I would just have a global fn get_device_acceleration() -> [f32; 3] specific to my app.

To quote John Carmack : Sometimes, the elegant implementation is just a function. Not a method. Not a class. Not a framework. Just a function.

To me the most interesting part is in your ADXL343 crate! This is where the magic happens, and what I think people will look for. accelerometer is mostly a (simple) specification that needs many implementors in order to be interesting. My 2 cents. :)

#20 is sadly not trivially fixable, if you're willing to go down the rabbit hole that leads to transcendantal functions causing overflow panics; I'm not surprised that this is not progressing ;)

[tarcieri]

I think the accelerometer crate is so thin that it could benefit from not actually enforcing specific vector types

That may be true for now, but I'd like to add a lot more functionality, e.g.:

https://github.com/NeoBirth/accelerometer.rs/pull/6/files

My goal with this is to have orientation tracking which is generic over all 3-axis accelerometers. To do that I really need a standard vector type.

I'm also trying to add noise smoothing through statistical analysis (outlier culling), which in the above implementation is generic across all accelerometer types whose vectors implement my current Vector trait.

#20 is sadly not trivially fixable, if you're willing to go down the rabbit hole that leads to transcendantal functions causing overflow panics; I'm not surprised that this is not progressing ;)

Oh really, that's unfortunate to hear.

My understanding is the libm crate which I'm presently using in accelerometer has similar issues, in which case I might consider using some special-case approximations for the handful of operations I happen to be using.

[tarcieri]

Guess I'll close this out as it's blocked on #20. Will keep an eye on that issue though.