Hi Sterling,
All of the above can probably be fit into a package based on sensor
'orientation', which might be a natural organizational unit?
I think this belongs in the core sensor package itself, or as a
sub-directory of hw/sensor (i.e. hw/sensor/orientation). Orientation
is a very common transformation and having a unified API for it makes
sense to me, unless you think that the various factors that go into
orientation (e.g. accuracy) vary greatly based upon the type of sensor
that you’re looking at, and therefore the algorithms themselves will
vary greatly.
The orientation code is quite generic and I think should apply to almost
any accel/mag/gyro as is. It gets slightly more complicated with full
9DOF sensor fusion (adding gyro support in) since there are certain
assumptions about gyro unit types that get fed into the algorithm (rad/s
or dps from the gyro, for example), but if these are clearly defined
it's up to the user to make sure you feed the filter what it expects in
terms of units and scale.
FILTERS
A second very important helper unit is something that implements
basic DSP algorithms to filter raw sensor data. This is critical in
my opinion, but often neglected in open source systems.
My biggest question comes in: what are the standard types that we
allow to be passed to these filters? Is it just floats, or do we
allow you to, for example, pass accelerometer directly.
If there is one standard type for DSP, I think it should be
single-precision float, but having an int32_t, fixed-point and maybe
even double option might be nice. I generally write float and int32_t
based versions of any DSP filters as a minimum. Part of the reason I
want to discuss this on the dev list, though, is because you need to
design things like variable types in from the start, and it isn't always
obvious how to do it well.
This is easier once you start dealing with concrete examples, though, so
maybe adding orientation in can be done now since that code is very
independent, and then we can start looking at how you can add an IIR
filter between the raw data and the orientation transform to get cleaner
data (simple moving average implementation, etc.). You will quickly run
into issues of type, and dealing with filter parameters then.
BONUS POINTS: PEDOMETER
Yeah, I think this is useful. I’m not sure this belongs in the core,
but perhaps a package that uses Mynewt? I could be convinced
otherwise, if folks think it should be OS level.
This is a separate package to me, yes, since it's very application specific.
K.
