accel and gyro calibration move to msg/

[dagar]

Debugging possible issues with applying sensor calibrations.

Moving the calibration structs (accel_calibration, gyro_calibration, etc) allows for easy printing (print_message()) and debugging. It also lays the groundwork for moving to something entirely uORB based.

In this PR mpu6000 status or mpu9250 status will now print the actual calibrations used internally.

This also unifies how calibrations are applied at the end of a successful calibration between nuttx, linux, qurt.

[LorenzMeier]

@dagar Do you have an update here?

[dagar]

I haven't been able to reproduce the original problem seen in #9474 from a good vehicle calibration state.

[dagar]

This needs a quick line by line review, but should otherwise be safe to merge.
The only real difference at this time is running mpu6000 info or mpu9250 info will print the gyro and accel calibration.

[bkueng]

I'm not convinced by this:

• The topic does not have a device identifier
• More generally, why adding another topic for that which the sensors module needs to fill from params? Why not letting a driver read the calibration params directly (through a shared base class)?

[dagar]

More generally, why adding another topic for that which the sensors module needs to fill from params? Why not letting a driver read the calibration params directly (through a shared base class)?

There's not much to be convinced of here, at the moment it's simply a helper for debugging and printing what each individual driver instance is actually doing internally. In the referenced issue I'm fairly certain there's a weird edge case where the intended calibration parameters weren't loaded.

In the future I'd like to have the drivers start reading directly from params, but even in that case this might be useful. My next incremental step towards that was going to be refactoring the existing sensors module calibration parameter reading centrally so that a helper can fill this struct directly. Then gradually have the drivers themselves move to a base class that provides the functionality directly instead of via IOCTL.

I also want to explore some ideas for publishing an extremely low rate sensors status equivalent. These calibration messages could be fields in a larger composite message.

Worst case it's easy to move these out of msg/ later and back into a real header.

[bkueng]

In the future I'd like to have the drivers start reading directly from params, but even in that case this might be useful.

Good, the PR and description suggested otherwise. The topic is not required for that, but if you think it helps with debugging, fine (the referenced issue is already closed).

I do however request better topic descriptions: what are they used for, who publishes (or will publish) them? Our sensor pipeline regarding calibration is already complex, and adding these topics does not make it simpler.

[dagar]

Rebased on master and added calibration printing to a number of accels and gyros.

[dagar]

Good, the PR and description suggested otherwise. The topic is not required for that, but if you think it helps with debugging, fine (the referenced issue is already closed).

The reference issue wasn't really resolved properly, but got confused with other issues during someone's attempted reproduce.

If you're curious take a look starting here #9474 (comment). It appears that the calibrations changed as the result of an unrelated parameter update. I want to get the pieces in place so we can begin to investigate in place if this reoccurs in the field.

[dagar]

Rebased on master. Can I get another review? I'd like to keep going with this for debugging short term, and longer term getting away from IOCTL calls for calibration.

[davids5]

@dagar - I know this is for debugging and these changes make sense in the context of what was discussed. Can we add documentation to add that context. Describe the problem and the choices we may have to resolve the issues.