Onboard Temperature Calibration [WIP]

[bugobliterator]

Temperature Calibration Scheme for calibrating sensors. The module will be running onboard and processing data realtime.

TODOs:

Parameters for post and pre calibration stage not yet saved, add mechanism to store them.
Currently only gyro, include accel and baro.
Integrate with Events interface

Current Results:

Gyro Temperature Cal Temperature vs Gyro Bias plots (Temperature is on reference offset scale):

tempcal start inside nsh will kick off temperature cal.

[LorenzMeier]

If we compare this to https://github.com/PX4/Matrix, what parts of this standalone Matrix implementation can be replaced by the standard? I would much prefer to extend Matrix with whatever is missing and not have any math classes in here.

[jgoppert]

Yeah this is all supported by matrix. see the temp cal doc for the math. All you need is pseudoinverse. I can add a convenience method if you need. This code is very clean so of you see anything in matrix you can improve, let me know/ submit a PR. This math only supports a standard y = f (T), if you look at the temp cal document the math is much more general, could add more info like gyro data. I will try to sketch up the math for this in matrix.

[jgoppert]

Is anyone online to give me an overview of the online temp sampling strategy?

[bugobliterator]

I am online, which mode do you prefer for comm. On Sat, 21 Jan 2017 at 9:10 PM James Goppert < mailto:James Goppert <notifications@github.com> > wrote: a, pre, code, a:link, body { word-wrap: break-word !important; } Is anyone online to give me an overview of the online temp sampling strategy? — You are receiving this because you authored the thread. Reply to this email directly, #6413 (comment) , or https://github.com/notifications/unsubscribe-auth/AFbvCBqvlUqkg5ba_IjiGQfVnIONiPL_ks5rUibggaJpZM4LqEKe .

[jgoppert]

@bugobliterator and I came up with a short term plan:

1. Switch math over to matrix. He had it using matrix in the beginning but was unsure about the output and switched to known working code he had. If we can find any errors in the matrix inverse in Matrix through this process we will fix it.
2. Implement interval averaging for data collection to avoid over weighting one section of the fit.
3. We've determined that the algorithm is a recursive least squares solution, and I checked his derivation here: https://github.com/jgoppert/iekf_analysis/blob/master/Temperature%20Calibration.ipynb

Fit interface:

1. User enters start deg C, the fit starts when start temp bin is reached
2. Users enters stop deg C and the fit stops when stop bin is reached.
3. User enters number of bins for fit or it is hard-coded to 100 etc.. The bins are allocated, and then initialized with the first value.

When a sample is received, the bin is updated. We could update by storing the number of samples and sum and calculating the mean, or by using a low pass filter. The disadvantage of the man is that the value will become very static if we use this for online adaptation. The disadvantage to the low pass filter is that we will need to initialize it when we get the first sample and set the cutoff frequency very low so it might get stuck on the initial value. Maybe when initializing the bin we wait for 10 samples or so and initialize with the mean of those 10 samples.

Long term support for online adaptation:
Fixed bins are created and each bin is initialized to pre-calibrated data. While the user flies, they are updating the temperature bin they are in. Temperature cal is updated using this data at start or at fixed time intervals. Some consideration for the gyro bias estimation in the IEKF/ EKF2 is needed here, maybe already addressed in temp calibration document.

[bugobliterator]

@jgoppert @LorenzMeier I have changed to using Matrix functions in polyfit and converted it into a template with changeable order of polynomial, hence it can be used for anything relating to polynomial/curve/spline fitting. So do you think its a good idea to move it to the matrix library as well for anybody to use?

[LorenzMeier]

Ok. Please integrate with this PR next: #6396 and enable the full operation. I would propose that:

• user sends a temperature calibration command
• calibrator stores an "enabled" param in memory
• user cold-soaks the board
• calibrator starts taking samples 2 seconds after boot if enabled param is set (we need eventually motion detection)
• calibrator runs until reaching steady-state temperature (e.g. one minute within 0.5 deg or so)

This is a bit different from min and max as we likely need to work with what the user gives us (best effort). It would also be good to be able to set min and max as additional gates - if they are not reached, the calibration will be considered invalid.

We would set those to relatively small values though (e.g. -5 to 35) by default to users can reach them.

[jgoppert]

@bugobliterator yes, I think we should add it to Matrix. Let's pull it in after we get this temp call stuff wrapped up.

[LorenzMeier]

@bugobliterator Where is this standing?

[bugobliterator]

Discussion and PR moved to #6425