Accelerometer and Barometer temperature compensation

[breadoven]

PR provides temperature compensation for accelerometer and barometer altitude drift with changing sensor temperature.

Setting added for temperature compensation factor in measurement/K, currently limited to -50 to +50. It is possible to perform an auto calibration of the required compensation value by monitoring the measurement drift with the FC static for a period of time after boot up. This is currently triggered using a setting of 51 although it could use some other method. The auto calibration ends after a 5 minute timeout or on first arm.

Seems to work reasonably well for BMP280 barometers in the temperature range 15 to 40 C reducing drift of up to 4m down to < 1m. Needs more testing though because one board works with a value of 20 cm/K while another is closer to 40cm/K which seems excessive given the spec value for a BMP280 is supposed to be 12.6 cm/K. MPU6000 accelerometer returns a compensation factor of around 2.5 cm/s2 per Deg C.

Best tested by checking barometer altitude in the Configurator Sensor tab. First check drift with a setting of 0 and a cold FC. Then change setting to 51, power off and allow the FC to cool then power on again and recheck the barometer altitude. The barometer will drift as before until 5 mins after bootup at which point, if the calibration has worked, the barometer altitude should fall close to 0. This should be accompanied by a "success" beep (may need battery power for this rather than just USB). The calibrated setting can be saved by switching to the CLI and hitting "Save Settings" (or using the Save stick command or CMS). Power off again and allow the FC to cool down then recheck barometer altitude again, it should show much reduced altitude drift as it warms up.

The accelerometer isn't so easy check while calibrating given the lack of feedback, the acc value in the Sensors tab isn't the corrected value so can't be used. So it's more a question of checking the setting after the 5 min timeout to see if it has a non 0 value.

[mmosca]

Do we apply the compensation values covered in section 3.11 of the datasheet already?

https://www.bosch-sensortec.com/media/boschsensortec/downloads/datasheets/bst-bmp280-ds001.pdf

[breadoven]

Do we apply the compensation values covered in section 3.11 of the datasheet already?

https://www.bosch-sensortec.com/media/boschsensortec/downloads/datasheets/bst-bmp280-ds001.pdf

Pressure and temperature are calculated as per the spec sheet but you still get drift regardless. I get the impression those compensation calibration values are set when the chip is manufactured and tested but their accuracy can be affected when the chip is subsequently soldered in place. In reality the drift is pretty minimal ... more of an issue for multirotors hovering at low level I'd say than for fixed wing where it wouldn't be so noticeable.

[Jetrell]

When you ran your tests. Did your build include 10243 ?

I proceeded to run a baro temp calibration on a copter with a DPS310... The calibration was done with the flight battery connected, which also added to the boards heat by having the voltage regulator driving the VTX.
The air temperature inside the building was 18°c when calibrating.
Before I ran the calibration, altitude in the sensor tab was showing between -0.03 to +0.1meters.
Then I ran the calibration according to your recommendations. Of which I did a few times with a 10 minute cool down between all the processes... It came up with a 1.03, 3.42cm/K change. And 14.52cm/K change with only USB power, with all holding practically as close to zero as it did before the calibration. So I'm not sure how accurate calibration can actually be on this FC.

I then took it out for a hover. I did this without a GNSS fix, just in Althold, using the baro and IMU for vertical estimation.. The air temperature was 16°c, with some light wind.
After arming and entering a hover, then enabling Althold. The copter started to climb from 1 to 5 meters. So I landed and rebooted the FC.
On the next flight immediately after, Althold held within a meter of the altitude target. Although it did drift up and down considerably as the wind would lightly blow.

I find the baro altitude / temperature log data hard to gauge and interpret when comparing to line of sight video.

• Wind blowing over the surface of the barometers hole can increase the air pressure on the sensor, making the FC think the copter is lower in altitude than it actually is for a time. So it commands the copter to climb.

• While much cooler more dense air blowing over the sensing hole, might cool the charged air within the sensor case, if it can displace some of the warmer stationary air in contact with the piezo element... Under that condition, temperature compensation may stabilize altitude data, based on air density changes.. But how likely is this, when the baro sensor case is continuously being heated by the boards thermal mass ?

Open cell foam certainly helps to also divert some air flow around the sensor, as well as maintain a more consistent temperature. But the effect is still there.

Don't take my report as negative. I think it has to be a bit of both of the conditions above. I'm just trying to provide as much test data as possible. I wish it was a little more favorable.
I'll do some more tests with other Copters/FC's/baro's later when the weather clears.

[breadoven]

@Jetrell How did the DPS310 baro behave with no compensation, did it drift by several meters after 5 mins or so ? The spec sheet for it shows the same pressure temperature sensitivity as the BMP280 = 0.5 Pa/K so I'd expect similar behaviour, unless of course the original calibration for your particular baro was just less affected by the manufacturing process.

The auto calibration is really just to get a ball park figure. Ultimately you can just set a value and see how much the baro altitude drifts compared to no compensation and adjust from there. This compensation method also assumes a linear relationship which I don't think is the case over an extended temperature range. So you might find it overshoots at a lower temperature then undershoots at a higher temperature with a 0 point somewhere in between. Which I guess isn't a problem really since it's better than the situation without any compensation.

As far as the overall estimated Z is concerned the other issue is the IMU drifting, as shown in #10308. This may be more of a problem than baro and GPS drift since it's the baseline for the estimates so any constant offset in the Z acceleration will result in a constant offset in the estimates for altitude and velocity. Would be useful to improve this.

I did a test the other day using this PR with a multirotor with a BMP280 and a setting of 20 cm/K. Initially altitude control was poor until I realised the default alt sensor setting was set to GPS. It was flying in the back garden near trees and buildings which I think screws up the GPS accuracy badly, multi pathing etc I'd guess, position hold drifted badly and erratically. I switched to Baro Only and the altitude control was much better (position hold was still poor though ... as expected), probably the most stable altitude control I've had for a while, none of the yo yo'ing up and down and poor erratic response to the throttle stick corrections I've had recently.

[Jetrell]

How did the DPS310 baro behave with no compensation, did it drift by several meters after 5 mins or so ?

When testing it today before the calibration, the difference wasn't any worse with the DPS310, than it was after the calibration tests were done. Meaning the drift was still there to a similar degree, but not majorly.
But in saying that. This copter generally drifts far worse than my others in the colder weather.. Which may say something about the temperature compensation for this baro being less needed at warmer ambient temperatures, than at lower ones.

As far as the overall estimated Z is concerned the other issue is the IMU drifting. This may be more of a problem than baro and GPS drift since it's the baseline for the estimates so any constant offset in the Z acceleration will result in a constant offset in the estimates for altitude and velocity. Would be useful to improve this.

I'm leaning that way too.. At select points in the logs I was looking over today. When comparing Baro and IMU temperatures, with baro and navPos[2] altitude, against navAcc[2], acc[Z]. I could occasionally see the Acc average increase, which pushed the navPos[2] higher, even at times when the baro altitude was relatively steady. This was in Althold with the GNSS disabled.

[breadoven]

I've used the same method to compensate for IMU Acc Z drift which seems to work possibly more reliably than the Baro, the Auto calibration correction factor is much more consistent. I did notice though that there is already some bias correction applied to Acc drift based on Baro and GPS altitude corrections, uses inav_w_acc_bias. However, it's slow to respond and that's with the FC static on the bench, not sure how well it would work in flight, so using a temperature based correction would be better.

[breadoven]

Added temperature compensation for the accelerometer. Not so easy to check the affect during calibration so just check that a non zero setting value is returned after the 5 minute calibration timeout.

[Jetrell]

After much testing with different conditions and hardware. It appears to have helped improve reliability.. If I had to say how much across all tests. I'd say may be 25% increase.. Including some boards that were better and some that were not so good.

All tests used baro only and no GNSS vertical position. With today's ambient temp being 21°c.
I narrowed it down to the two highest influential effects with these sensors, that improve or reduce vertical position estimation.

• It was better to run both calibrations with only USB power for the board... To reduce the amount of heat from other electronic components altering the calibration in a detrimental way.
• Letting the whole copter and board heat-up thoroughly, when waiting for a GNSS fix.

The way I came to the conclusion for the second. Was by first leaving the copters in the shade until they got a GNSS fix.
This kept the sensor and board temperature around the low 30°, when armed.
I could lift off and enter Poshold. With the vertical drift averaging 0.5 - 0.8m to start with. But as the board warmed more. Into the mid 40° range. The altitude precision slowly increased. With the copters all generally holding within 0.2m of the target.

While if I left the copters in the sun while waiting for a GNSS fix. The sensors and board temperature would average in the high 50° range before arming.. Then once I armed and lifted off, then entering Poshold. The altitude precision was always better straight off the bat. Within 0.1 - 0.15m of the target... But the crunch was, as the sensors and board cooled down by the props air flow. The vertical precision also reduced. Meaning all copters would start to drift more, up to 0.5m after a couple of minutes.

So I'm left wondering how much benefit is related to sensor calibration, and how much is variably related to the ambient air temperature/sensor/board heating.
It sort of like this -
WINTER
Board starts cold, then warms from electrical heat, which increases sensor accuracy. Then colder winds and prop airflow then variably alter temperature and precision.. With observations normally showing the copter to rise in altitude to meet the target.

SUMMER
Board starts out warm and gets hotter from electrical and ambient heat. Leading to higher precision. With prop cooling and winds then often reducing accuracy somewhat.. With observations normally showing the copter to sink in altitude to reach the target.

It would make sense that the sensors would be more precise in the higher operation temperature ranges. Due to their mechanical and piezo electric components having even less resistance to motion as the temperature rises (within limits). This is likely why high end devices like the Pixhawk cube have a controlled temperature environment.

[Jetrell]

@breadoven I forgot to mention it won't allow calibration of the ICM42605 IMU's. I tried a few of them... So I only tested FC's with MPU6000.

[breadoven]

@breadoven I forgot to mention it won't allow calibration of the ICM42605 IMU's. I tried a few of them... So I only tested FC's with MPU6000.

As far as I can tell the ICM42605 IMU doesn't have a temperature output. Says it does in the data sheet but the INAV temperature function is shown as NULL. Same for the BMI160 IMU. What does the Gyro temperature show in the OSD ?

Not sure what to make of this and the general altitude control at the moment. Tested yesterday in an open space with a multirotor thinking the default altitude sensor was set to Baro Only and with temperature correction on both the Baro and Acc. It was unpredictable and inconsistent the way it reacted to stick movements. Realised after it was in fact set to GPS which doesn't seem to work well at all even with plenty of satellites locked. I did a test a few days ago with Baro Only and it seemed better, more consistent, altitude variations of 20-30cm.

However, looking at the logs the problem in both cases is the Z velocity isn't consistent with the Z Position, they are out of sync, not so much with Baro Only but noticeably worse when set to GPS. You end up in the situation where the MR hovers at a relatively constant altitude but there's a constant false vertical velocity being estimated by the IMU resulting in the actual hover altitude being offset from the desired altitude, with the offset being equal to the point that generates a velocity correction equal to the false estimated vertical velocity. This wouldn't be such a problem if it's hovering in roughly the right position but when you move the throttle stick to adjust the altitude you get erratic jumpy corrections rather than smooth vertical velocity changes. Might be worth testing with inav_w_z_gps_v set to 0 to remove GPS vertical velocity from the estimation if you're using the GPS setting.

[Jetrell]

As far as I can tell the ICM42605 IMU doesn't have a temperature output. Says it does in the data sheet but the INAV temperature function is shown as NULL. Same for the BMI160 IMU. What does the Gyro temperature show in the OSD ?

Yep you're right.. No OSD temp data shown with the ICM gyro's I tried.

However, looking at the logs the problem in both cases is the Z velocity isn't consistent with the Z Position, they are out of sync.

I've often noticed that too. And more so when the IMU temp is lower... While if the temp is higher, velocity will more often hit zero... This also rang true with acc[z] being equal to this copters ins_gravity_cmss at that point in time.

While other times, and more often, it was just as you described.
I really don't think it can be tuned out by inav_w_z_gps_v. I feel there is something fundamentally wrong since 7.1.
When the weather gets better next week. I want to flash back to 7.0. And run some tests.

I mentioned to you in an earlier PR. That inav_w_xyz_acc_p was replaced with a dynamic clipping factor.. And by the nature of "dynamic". Hardware and temperature variations could possibly be altering the accelerometer weight gain at a higher frequency rate than the INAV logging is capable of detecting the spikes.. Being that logging rate is limited to 50%.
This would also explain why the XY also goes for a wander occasionally in Poshold... In my case, even when the HDOP is like 0.9 with 27+ Satellites.

[Jetrell]

The weather cleared a bit.. So I got to test a build within 7.0 52f5cff and 2 flights with 8.0 on the same copter within 15 minutes of each other, with little wind. (This copter has an analog VTX, with an M8Q that never sees more than 16 Sats)

I loaded 7.0 and armed with 7 Satellites, took off and entered Poshold.. It was rather refreshing to see it hold XYZ within 1m. Even though EPH was 3.1m. And when it did drift a little on any of the 3 axis's, it was smooth... I thought I'd remembered it being like this... I've just done so much testing with 8.0, I'd forgot how much better it used to be with a lower Sat count.

Then I loaded the 8.0 Baro Only altitude, having 9 Satellites.. It held in a similar way. However the drifting motion was more erratic on XY.
Then I ran the same build with GPS and Baro. By then it had a fix of 11 Satellites. As soon as I entered Poshold, it drifted more abruptly to the left by about 4m. And over its 3 minute flight it climbed around 3m above the original target.

So this would seem to indicate something in 7.1 is messing up the position estimator... With the effect obviously being more pronounced with lower GNSS position accuracy .

Looking over the pull requests in 7.1. It surely has to be one of the commits in this.
I have four builds between the different commits of that complete pull request. I'll have to go through them an run some more tests later in the week.. @breadoven Unless you have the time to check if anything stands out.

[breadoven]

That sounds like the behaviour I'm seeing. Poshold will work OK for a while then suddenly lurch sideways and continue drifting for several meters. Altitude does the same when set to GPS, sometimes almost descending back to the ground and needing double normal hover throttle to stop it. Better using Baro Only.

Other thing I've now found is the fixed wing I tested the other day is locking up on disarm. Doesn't seem to affect the multirotor I tested with the same master firmware update, just this fixed wing. Admittedly it's using an F411 board but I'm not sure that would be the cause. Nothing in the changes from the master update leap out as the possible cause, strange.

[Jetrell]

@breadoven My testing was limited and quick. But from those few flights. It would appear that commit is part of the problem or causing it.

This would seem to confirm @ultrazar findings related to rangefinder being effected by this too in #10314

But what to do about it ? The dynamic method has merit. But it will obviously need more refinement and testing with many different build qualities. Or is it worth the hassle.

[ultrazar]

I've made a PR adding IMUTemperature read function for ICM42605 that might be useful for this.
Despite that I also commented my different proposal for the accelerometer drift correction which isn't based on temperature but a basic smoothing algorithm also in #10423

[mmosca]

@breadoven what is the satatus of this one? We are planing a feature freeze for Nov 15. Should we target this to 8.1 or 9, or do you think it will be ready before that?

[breadoven]

@breadoven what is the satatus of this one? We are planing a feature freeze for Nov 15. Should we target this to 8.1 or 9, or do you think it will be ready before that?

It works as it is. Needs cleaning up and something adding to docs explain its function and limitations. Should be good for 8.0 in that case.

[sensei-hacker]

@breadoven what is the satatus of this one? We are planing a feature freeze for Nov 15. Should we target this to 8.1 or 9, or do you think it will be ready before that?

It works as it is. Needs cleaning up and something adding to docs explain its function and limitations. Should be good for 8.0 in that case.

Just a gentle reminder if there is "cleaning up" you want to do.

[mmosca]

Should we push this to 8.1?