Discussion: Look into improved curve fits for ms5611 Baro temp calibration

[Antiheavy]

The 5th order curve fit for the ms5611 Baro sensor sometimes does a poor job at cold temperatures.

We've been performing the offline temp calibration process on a few handfuls of autopilots and they all look fairly similar to this plot:

Our concern is the diverging curve fit at the cold temps.

Also, the ms5611 has a recommended temp compensation scheme which may be implemented somehow either inside the ms5611 or inside the PX4 drivers (not clear to me). There may be some confusion or conflicts with the off-board calibration and the chip/driver level compensation.

Improvements might involve:

• better handling of temperatures outside the calibrated limits. what should be done here? better/safer curve fits or extrapolations? warnings to the user? prevent arming until within calibrated limits? ( I'm not sure preventing operation outside calibration limits makes sense as it may force users to have expensive temp chambers to do wide temp calibrations.)
• better coordination between the ms5611 recommended temp compensation and the actual raw data calibration curves generated by PX4 (onboard and/or offline).

Thoughts?
@dagar @priseborough @M-Skelton

[M-Skelton]

Here are a few more examples for reference:

SN0077:

SN0075:

SN0072:

Another custom FMUv4 board:

A pixracer:

These calibrations were all done using the exact same method to perform the off-board calibration.

1. set calibration parameters
2. cold soak for 1 hr.
3. remove from freezer and connect usb cable
4. place into cooler
5. seal cooler
6. connect usb cable to the computer
7. let the calibration run for 30 min
8. run the off board python scripts

I think it's interesting that we see similar curves for 0075, 0072, and the developer FMUv4 board, but very different curves for the pixracer and 0077.

I think there's also something to address with:
#9054

I posted in the forums about the same issue a while ago for reference:
http://discuss.px4.io/t/mpu9250-internal-temperature-reading-seems-to-be-incorrect/5542/2

I think before we can roll this calibration into a production standard we need to ensure the sensors are reading correctly in the first place. As well as getting more consistent results.

As for how the firmware/autopilot should interpret past the calibrated range, I think reverting back to using the raw sensor reading might be a good idea for now. The curves that I posted hint at another inflection at the lower range that is shown. So I don't a linear interpolation out past the calibrated range would be of much use or a good idea.

If we could come up with a clever way to try and merge the raw and calibration data that would be neat, but as for the mechanics of how to implement that in a useful way, I don't have much of an instinct for at this moment.

[priseborough]

The manufacturers recommended compensation scheme is supposedly being implemented inside the Baro driver. This needs to be checked.

I agree that If we are doing our own serial number specific sensor calibration downstream of the driver then we are likely better off not doing the model number specific calibration provided by the manufacturer.

[dagar]

Pull request for testing #9267.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

Closing as stale.

[julianoes]

@dagar re-open if this is still going to happen.