Hello Jacob, A sensor chip could have multiple sub-sensors that it can have, for example:
BNO055 has accelerometer, magnetometer, gyro, etc. The sensor framework knows what the device supports looking at the types. Configuring a sensor chip to work in a certain mode, for example ACCEL_ONLY Vs some other fusion mode is a choice the developer makes depending on the application. You could have nothing ON to save power. That would be something for the future where we do power management of the sensors. For now we are getting the data model going along with support for multiple types of sensors. Regards, Vipul Rahane > On May 4, 2017, at 3:19 PM, Jacob Rosenthal <[email protected]> wrote: > > 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 >>>> >>> >>
