Hi Kevin,
On 3 Feb 2017, at 23:43, Kevin Townsend wrote:
Hi Vipul,
On 04/02/17 01:08, Vipul Rahane wrote:
Hello All,
I will be taking over SensorAPI stuff from Sterling.
Kevin:
TSL2561 Driver and LSM303 Driver that you have implemented are pretty
good and I used both of them. I saw the values coming in using the
SensorAPI. I would also like to understand about sensors from you or
anybody else that is more experienced on these as I am kind of new to
it, I have some experience but not a lot to get a generic
understanding.
Happy to help where I can on my side. I'm currently on vacation, but
can look into this more seriously when I'm back next week.
Don’t take too much time away from the beach, it can wait. :-).
* Zero-g level offset (TyOff) is the standard deviation of the actual
output signal of a sensor from the ideal output signal. Should we be
thinking of calibration for sensors in the SensorAPI ? I think in
this case it comes with factory calibrated values which can be used
by a developer. But that will change once put on a PCB, hence the
concern.
For orientation you will ALWAYS needs to calibrate the sensors to get
meaningful data (especially the mag, but also the gyro for the
zero-offset level), and this will always have to be done in the final
enclosure and environment. So yes, we should have functions to store
and apply calibration coefficients for the accel/mag/gyro data types
(plus perhaps some other sensors types, but definately those three). I
think these should be stored in config memory somewhere, but we need
helper functions to assign and apply them and just default to '0'
values.
++1. I think having well-defined tables to store this calibration, and
helper functions to write and inspect it are incredibly important. You
don’t want everybody doing their own cal tables. We may not be able
to fully model every sensor, even within a type, but I think we can at
least provide the framework for storing & updating calibration data
(e.g. write-protect, overrideable sections, read and write formats over
console.)
* Operating mode of Sensors. Low Power mode Vs Normal Mode for
Accelerometer and Sleep Mode Vs Single Conversion Mode Vs Continuous
Conversion Mode. Modes should also be a part of our SensorAPI I
believe.
I think having built in power mode control at the API level is
extremely value (and often neglected), but I think you want to keep
things manageable as well so this might be pushed off to a second
version? I do think we should keep power mode in mind with any API
level decisions though. Sterling has some thoughts on this a while
back and made an initial proposal that I found very sensible.
We should probably take this to a separate thread, when we get to it. I
remember thinking that most of what was there in the driver framework
could be leveraged, but it would be good discuss all the various
scenarios (e.g. interrupt driven, polled) and ensure it ties together.
I think a lot of the logic here you want at the driver level, and not in
the sensor API, the sensor API just needs to ensure that operates in
such a way that it allows the driver control (which it does currently.)
* Should the Filter mode selection also be part of the SensorAPI ?
I think this should be a separate API, but also a key part of any
system using sensor data. The key thing is to support compatible types
between the sensor and filter APIs. float32 would be my lowest common
denominator, especially since the Cortex M4F has excellent float32
performance (13 cycle divide, 3 cycle multiply off the top of my head
... which is also as good or better than fixed point), although
int32_t is nice as a fallback. Float32 will be more painful on an M0,
but I think most orientation systems will probably be implement on an
M4F which has a lot more processing power per MHz for this kind of
work.
Agreed.
So far it looks like the SensorAPI does a great job apart from the
above stuff.
I liked what is there so far. There are some gaps to fill in
(DSP/Filtering, making composite sensor types like 'orientation' based
on lower level raw sensor data, etc.), but it's very nice so far and
moving things in a good, sustainable direction in my opinion!
+1 on all suggestions - esp. DSP/Filtering.
Sterling
