Im developing some (mostly accelerometer) sensors right now. Power modes
were brought up here, and Id love to see more talk about that, and in
specific sensor initial config state.
It looks like the LSM driver doesnt init the cfg struct in _init, so its
presumably the 0 enum values of
LSM303DLHC_ACCEL_RANGE_2
LSM303DLHC_ACCEL_RATE_POWER_DOWN
LSM303DLHC_MAG_GAIN_1_3
LSM303DLHC_MAG_RATE_0_7
Where as bno055 does a default config of
cfg->bc_opr_mode = BNO055_OPR_MODE_ACCONLY;
cfg->bc_pwr_mode = BNO055_PWR_MODE_NORMAL;
cfg->bc_units = BNO055_DO_FORMAT_ANDROID|
BNO055_ACC_UNIT_MS2|
BNO055_ANGRATE_UNIT_DPS|
BNO055_EULER_UNIT_DEG|
BNO055_TEMP_UNIT_DEGC;
cfg->bc_placement = BNO055_AXIS_CFG_P1;
cfg->bc_acc_range = BNO055_ACC_CFG_RNG_4G;
cfg->bc_acc_bw = BNO055_ACC_CFG_BW_6_25HZ;
cfg->bc_acc_res = 14;
cfg->bc_gyro_range = BNO055_GYR_CFG_RNG_2000DPS;
cfg->bc_gyro_bw = BNO055_GYR_CFG_BW_32HZ;
cfg->bc_gyro_res = 16;
cfg->bc_mag_odr = BNO055_MAG_CFG_ODR_2HZ;
cfg->bc_mag_xy_rep = 15;
cfg->bc_mag_z_rep = 16;
cfg->bc_mag_res = BNO055_MAG_RES_13_13_15;
Which looks like 'normal' mode but accel only on. and a bunch of other
stuff I havent looked up.
What the ethos behind the init of a driver? What state should init leave a
device in?
On Sat, Feb 4, 2017 at 12:58 PM, Sterling Hughes <
[email protected]> wrote:
> 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
>
