OK. But during init the sensor tells the rest of the system in the init
that it IS a gyro.
rc = sensor_set_driver(sensor, SENSOR_TYPE_ACCELEROMETER |
SENSOR_TYPE_MAGNETIC_FIELD | SENSOR_TYPE_GYROSCOPE |
SENSOR_TYPE_TEMPERATURE | SENSOR_TYPE_ROTATION_VECTOR |
SENSOR_TYPE_GRAVITY | SENSOR_TYPE_LINEAR_ACCEL |
SENSOR_TYPE_EULER, (struct sensor_driver *)
&g_bno055_sensor_driver);
But .. its currently not. Why is accel on and gryo not?
Why not nothing on?
I dont have an opinion here, just asking questions.
On Thu, May 4, 2017 at 3:16 PM, Dave Baker <[email protected]> wrote:
> 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
> > >
> >
>
