Don't turn on the gyro unless you really really need it. It's a pig! Default to accel only is good.
On May 4, 2017 5:13 PM, "Jacob Rosenthal" <[email protected]> wrote: > 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 > > >
