Barometer drift with Temp

[brewski]

I noticed that there is appreciable drift with MS5611 Baro chip. I suspect other Baro chips will be similar.
From cold (25C) it drifts approx. 1.5 metres up after only ten minutes & noise increases. The foam on top probably traps heat & contributes to the drift.
I looked up specs for MS5611-01BA03 & see that there is a precision temperature sensor incorporated. Would it be possible to use this sensor to null out the drift?

[timecop]

This is already happening in the code.

[brewski]

Great. Which version?

[timecop]

All of them , the baro calculation includes compensating from temperature sensor. Thats why it does 2 reads, one from pressure adc and one from temperature adc.

[brewski]

Then why does reading drift so much?

[copterrichie]

Altitude holding has been a center of conversation for sometime now. viewtopic.php?f=8&t=2371

[brewski]

Checked it out. Looks like it is the "Too Hard Box"

[happul3]

Are you sure that the drift you observed is temperature-related? Have you established that it is repeatable and reproducible or is it one time observation? If it is the latter case, there is one explanation that does not have anything to do with your baro sensor. People sometimes forget that atmospheric pressure changes naturally quite a bit. For example, for the last couple of hours my weather station recorded ~1mbar drop per hour (it is actually nice weather outside, nothing extreme, good for flying). That is ~0.2 mbar change per 10 min. Guess what altitude difference corresponds to 0.2 mbar? It is about 1.5 m at sea level. So maybe your sensor and software ain't at fault after all

[treym]

hum... you are both right


1 : the pressure reading is temperature compensated , cf ms5611 datasheet
Temperature compensated pressure (10...1200mbar with 0.01mbar resolution)

2 : the altitude conversion from the pressure reading is not, cf : readDaCode , i presume 15°c .

Temperature decreases with altitude at a constant rate of -6.5° C/1000m (-1.98°C/1000ft) up to the tropopause.
The standard tropopause altitude is 11,000 m (36,089 ft). Therefore,the air which is considered as a perfect gas in the ISA model presents the following characteristics within the troposphere

http://www.meas-spec.com/downloads/MS5611-01BA03.pdf , starting page 17


EN: http://fisicaatmo.at.fcen.uba.ar/practicas/ISAweb.pdf
FR : http://fr.wikipedia.org/wiki/Atmosph%C3 ... _type_OACI
DE: http://de.wikipedia.org/wiki/Barometris ... d=26751842

[brewski]

I also have a weather station with remote sensors & base station connected to PC. I thought about atmospheric change when measuring the drift but it did not vary during the 10 minute period from cold start.
Quad was on table connected to PC running WinGUI 2.3 Pre10 for Navi b7. There is a repeatable upward drift with temperature & I suggested probably made worse with foam covering Baro IC. I don't thing the temp rise would be as bad when quad is hovering/flying due to prop downwash and air movement.
My FC is AIOP V2 with MS5611-01BA03.

[treym]

again , 1.5 meter drift for a 10min periode is totally legit change.. if you had another ms5611 on the ground i bet you would have noticed that the barometric pression had change during those 10 min ..

[brewski]

OK. So not related to temp, just drift?
The specs state 10cm accuracy. I wonder what their testing criteria are & at what temperature.
I guess with prop wash & hence varying pressure changing with revs we are probably lucky that a quad will hold alt within 50cm as we currently see if set up correctly.

[brewski]

Re ran test at 15C as cold front arrived.
Starting FC @ 20.30. At. Pres 1018.2 , Win GUI reporting 0.17m
20.40. At. Pres 1018.2, WinGUI reporting 1.65m
20.50. At Pres. 1018.3, WinGUI reporting .65m
21.00. At Pres. 1018.5, WinGUI reporting -.55
Looks like great sensor for reading atmospheric pressure but not so good as an altimeter when weather changing!
Maybe we should be using ultrasonic or even better laser range finding to determine height. Cheap Laser distance finding modules are readily available- just need someone to add the code.

[timecop]

Just make sure to implement that on another arduino pro mini, and connect to the rest of FC by I2C.

[ezio]

I'm curious how dji achieved such good result in alt hold.

[copterrichie]

I would assume by mixing the Acc Z axis with barometer readings. I recall someone did some experimenting around with using the Acc Z only for altitude holding.

[ezio]

I would assume by mixing the Acc Z axis with barometer readings. I recall someone did some experimenting around with using the Acc Z only for altitude holding.

But right now we also have this in MW and the accuracy is not that great.

[copterrichie]

But right now we also have this in MW and the accuracy is not that great.

In my opinion, I feel too much importance or bias is placed on the baro readings also the Wii is bit shifting the precision away on the ACC to eliminate noise.

[ezio]

But right now we also have this in MW and the accuracy is not that great.

In my opinion, I feel too much importance or bias is placed on the baro readings also the Wii is bit shifting the precision away on the ACC to eliminate noise.

I have spent some time to tune it correctly and there are days that it holds altitude very well +-10cm but with the same settings but other day it is +-5m. This is strange.

[copterrichie]

I just have too many projections underway and motivation is low to finish some of them however, one of the projects I want to play with is a vibration dampening plate many are using for the APM. I THINK if we reduce the vibration, we can improve the precision of the ACC especially the Z axis.

[brewski]

Mount looks good. Should allow a higher frequency setting on ACC/gyro LPF which should improve Z axis resolution & help with Alt Hold.

[crazyal]

here is a graph of a naze rev5.
The drift could be weather dependent tough. It was pretty windy outside when i did the warmup test.
IMO the easiest solution is to just wait a bit for the board to reach a thermal equilibrium or an external temperature sensor might work too.
Vibration dampening on the FC won't give you much better results. You can also do the low pass filtering in software.
Probably the main problem is in the sensor fusion of the baro and the ACC. A kalman filter might do the trick instead of a complementary one(not an option on 8-bit).
Also using two pid loops for velocity and altitude did improve things for me and many other people on baseflight.

[happul3]

Vibration dampening on the FC won't give you much better results. You can also do the low pass filtering in software.
Probably the main problem is in the sensor fusion of the baro and the ACC. A kalman filter might do the trick instead of a complementary one(not an option on 8-bit).

I agree - vibration dampening by mechanical design is not that different from software filtering. And neither one is a good solution if your props/motor create excessive vibration and makes copter wobbly/video jelly. But I do not think that has much to do with altitude hold anyway. Altitude changes happen on substantially slower timescale so vibrations should average out.

Most of problems with altitude hold seem to come from badly tuned pid parameters and, in some cases, unfortunate positioning of pressure sensor relative to air flow created by props (foam on top may not fix that). Keep in mind that the althold control is quite forgiving, allowing one to get away with really bad set of parameters. That makes manual tuning relying on visual assessment really difficult. And then there are natural pressure changes often translating in 10-100 cm/min barometric altitude changes. So the tuning process probably ends too early, yielding bad set of parameters and quite a bit of frustration.

How do we deal with it? I think that the first thing is to understand that there are two *independent* contributors to althold control. One is barometric - pressure sensor, and the other one is inertial - accelerometer. Second, one needs to understand that the two are complementary, each with its own strong points and shortcomings:

Pressure sensor will *never* be capable of reliably hold your flying toy within 10 cm window. Don't get me wrong - on a good day when atmospheric pressure is steady it is quite possible if your copter is reasonably designed. But the next day the pressure may not be so flat. So, amazing vertical stability I've seen in some videos showcasing naza controller cannot be achieved reproducibly with barometric control. On the plus side, pressure sensor can hold your copter reliably withing few meters widow *indefinitely long* (assuming reasonable flying weather).

Now, the accelerometer really shines when you want to keep copter parked in air. For a well designed copter and appropriate level of filtering, accelerometer should be able to keep copter within few cm when hovering. By the way, it should also be able to keep copter similarly steady in horizontal plane, but that is not implemented in Multiwii at all. But over long duration (or even shorter duration when the copter is moving), the unavoidable inaccuracies in numerical integration will result in vertical velocity error. In simple words, copter may be thinking that it is going up with 1 cm/sec velocity, but in fact it is descending. The big problem is that such error is not going away on its own because accelerometer has no way of measuring actual velocity. So, you one relies on inertial control *only*, the copter my appear remarkably stable initially, but may become increasingly and systematically unstable after a while.

In Multiwii code, the input from two contributing sensors is nicely merged, resulting in acceptable compromise. With proper pid values, the accelerometer should be primarily responsibly for short-term vertical stability, especially when hovering. But it should not always stay withing few cm window because pressure sensor contributes too. That make seem as an unwanted influence, but it is actually absolutely required when copter is actively flying (or whenever accelerometer produces cumulative error) for any significant duration to provide correct (even if inaccurate) absolute vertical velocity.

It should be possible to modify code to increase vertical stability at hover by dynamically increasing weight of accelerometer input and, respectively, decrease pressure sensor's. But that will be mostly cosmetic. Another possible improvement that occurred to me while I was writing this is to reset integrated velocity (variable vel) when copter is hovering for longer than predetermined duration. The way code works right now is that accumulated error in vel is compensated by barometric terms (I and P), which is somewhat inconsistent.

On a practical side, althold pid tuning procedure should start with P and I, keeping D zero. That will give you pure pressure sensor control, no contribution from accelerometer at all. Tuning is standard - increase till see oscillation, then decrease to get rid of oscillations. It is best to use bluetooth or something similar and collect alt data. Makes it easier to see oscillations when plotted. Even better to hook tuning parameters to pots and do tuning in real time. When finished, fly copter (low, close) with that set (P,I, D=0) few times, few days to get a feel for what to expect from purely pressure controlled althold. Modify sensor foam, protective cap, anything that is between sensor and airflow. Got improvements? Retune P and I. Finally, tune D, by gradually increasing it. You may want to experiment with decreasing P and I at that stage. Personally, it was quite illuminating to make P and I zeros and tune D to get an idea of how pure inertial control feels (strictly speaking, small code modification is also required to eliminate pbaro contribution to D-term), but I would not recommend that because I am unsure that it would not make some copter unstable.

Finally, please post results of your experiments, with plots acquired via bluetooth and respective parameters.

And a reminder: DO NOT ENGAGE ALTHOLD MODE UNTIL YOU'VE ACHIEVED STABLE HOVER UNDER MANUAL CONTROL (few seconds is all you need before flipping the switch)!

[copterrichie]

Now, the accelerometer really shines when you want to keep copter parked in air. For a well designed copter and appropriate level of filtering, accelerometer should be able to keep copter within few cm when hovering.

In Multiwii code, the input from two contributing sensors is nicely merged, resulting in acceptable compromise. With proper pid values, the accelerometer should be primarily responsibly for short-term vertical stability, especially when hovering. But it should not always stay withing few cm window because pressure sensor contributes too. That make seem as an unwanted influence, but it is actually absolutely required when copter is actively flying (or whenever accelerometer produces cumulative error) for any significant duration to provide correct (even if inaccurate) absolute vertical velocity.

It should be possible to modify code to increase vertical stability at hover by dynamically increasing weight of accelerometer input and, respectively, decrease pressure sensor's.

I AGREE with the above however, I personally believe eliminating as much vibration mechanically first and a well turn copter SHOULD be the foundation before applying any software filtering to the sensors etc.

Just my opinion.

[timecop]

I'm curious how dji achieved such good result in alt hold.

? dji althold only works while its hovering in one place.

[brewski]

I found a stable patch in the crazy weather we have been experiencing & took a reading from cold & then after 15 & 30 minutes. The pressure graph on my weather station was flat for the first 15 minutes & dropped .1 mb in following 15.

Start cold 15.30 1013.1mb Alt .02 Temp 21.5C
15.45 1013.1mb Alt 2.35
16.00 1013.2mb Alt 2.85 Temp 21.1C
Quad was inside house plugged into PC running WinGUI pre10 for navib7. Crius AIOP V2 running MW 2.3 navib7.
I maybe proved wrong but believe that either temp compensation is not working correctly in code or there is a drift issue with MS5611.

[treym]

are you sing a real wheater station ?



or are you just assuming that you are right by design ?

[brewski]

I have a semi professional WH-3081 weather station with wireless remote sensors. Raw data from base station inputs to PC running Cumulus software.
It tracks pretty well with airport readings & I would say at least 10 times more accurate than the bellows type mechanical barometer shown in pic.

Cheers..B

Cumulus.rar

(200.49 KiB) Downloaded 116 times

[brewski]

This morning I powered up FC for 10 minutes to stabilise temperature of sensor, cycled power to zero sensor & took some more readings.
Time 7.30, Air temp 19.5C, At Pres 1022.0 mb , Alt .06
Time 7.45, Ait Temp 19.5C, At Pres 1022.2 mb, Alt -.05
Time 8.00 , Air Temp 19.7, At Pres 1022.5 mb, Alt -1.75

As you can see with FC warm there is none of the rapid positive drift. The readings are now related solely to atmospheric pressure change.

Some are saying that the BS5611 is internally temperature compensated, but reading thru the data sheet all I can see is that there is a precision temp sensor integrated with baro & this temp data is output to I2C bus when register is interrogated.
If it is not possible for MW code to use this temp data to null out initial temp drift, then all we have to do is power up quad for 10 minutes & recycle power to zero Baro before flight.

Cheers..B

[brewski]

My ext mag board arrived today so I disabled the on board Mag chip by cutting jumper on my Crius AIOP V2, changed code to look only for Mag on 12C socket & it works! No more magnetic drift with motor speed if I hold sensor at least 50mm away from cables & dist board. Just have to work out now where to mount it,,any ideas?
Another benefit is that with disabled Mag chip, which is close to barometer module, the temp drift of barometer is much less & now acceptable as only .2m over 15 minutes from cold with barometric pressure stable.
It is either this or the instant winter we are experiencing with min temps dropping from approx 18C to 8C & max 25 to19c so not really sure.

28/6 Tested again today (20C) and got +1m drift in 15 minutes from cold. At Pres -.1mb over this time. I think board was already warm when I ran test yesterday. Definitely a lot less than previously probably due to having Mag disabled & only small piece of foam on Baro module.

[brewski]

I saw this warning re GPS sat lock & Baro temp drift on RC Groups Arducopter/APM 2.5

Avoiding "GPS glitch" and fly-away is NOT Rocket Science
You must ALWAYS wait 5 minutes OUTDOORS after connecting Lipo BEFORE Arming to fly.

During those 5 minutes;

1.GPS will drift [usually a LOT!] then settle.

2.Barometer will drift [sometimes A LOT!!] then settle, Arming will zero the Barometer reading.

After patiently waiting for 5 minutes, GPS and Barometer will be far more accurate.

If you disconnect Lipo even for an instant you must wait 5 Minutes again

Obviously a common problem with these sensors no matter what firmware FC is running. Unfortunately with MW arming does not zero the Barometer as far as I know.

[scrat]

I saw this warning re GPS sat lock & Baro temp drift on RC Groups Arducopter/APM 2.5

Avoiding "GPS glitch" and fly-away is NOT Rocket Science
You must ALWAYS wait 5 minutes OUTDOORS after connecting Lipo BEFORE Arming to fly.

During those 5 minutes;

1.GPS will drift [usually a LOT!] then settle.

2.Barometer will drift [sometimes A LOT!!] then settle, Arming will zero the Barometer reading.

After patiently waiting for 5 minutes, GPS and Barometer will be far more accurate.

If you disconnect Lipo even for an instant you must wait 5 Minutes again

Obviously a common problem with these sensors no matter what firmware FC is running. Unfortunately with MW arming does not zero the Barometer as far as I know.

Will test your suggestion. Thanks.

[copterrichie]

I fly with guys that own DJI products and it is clear to me, it is not the hardware that gives the product its flight characteristics but the start-up and calibration procedures.

[brewski]

Multiwii forum should have a start page as APM & others have done listing basics on getting started as well as safety related information.
I am an electronics engineer & it is obvious to me that these designs have some serious safety limitations. We assume that we can just plug in a lipo pack & fly without doing some kind of pre flight check..crazy!
With feedback systems such as EZ-GUI using Bluetooth or 3DR radio at least we can be assured that sensor data is within acceptable values & perform calibration if required before flying.
As someone new to this hobby I already know the dangers of a quad out of control & have the scars to prove it
We all need to help improve safety. Just letting FC warm up for 5 minutes before flight to stabilise & get an accurate GPS fix will prevent most of the flyaways & unpredictable behaviour reported in the forums.

[copterrichie]

Nothing personal, but there are just too many chiefs and not enough Indians around here. There is little to no cooperation but much competition and this is why things are in the state they are.

[ezio]

Nothing personal, but there are just too many chiefs and not enough Indians around here. There is little to no cooperation but much competition and this is why things are in the state they are.

+1