As some of you know, I've been having some issues with altitude drift:
Various alt loss scenarios on alt hold, auto and loiter
Well, tonight I have a video showing it, and I think I've got a repeatable working solution to this. I run the test 3x for 2 hours (over 3 nights basically), and the last hour the baro is rock solid (+/- 0.05m).
It's not ideal - you need to get the APM booted up *one hour* before flight - but it does at least work. It should mean more accurate flight and less severe auto landings for those of us suffering from this. Power source is irrelevant, so I recommend power up from USB to save flight pack volts, then swapping to the pack when ready to fly.
As well as using this method, I highly recommend using black tape over the baro. It fluctuates by up to 10m if you flash a light over it! (I did have it on video, but managed to delete it!) It does re-settle, but why expose yourself to this problem. It will mostly affect you if you flying on on/off cloudy days.
To see this for yourself, dim the lights in your room, then flash a 60W bulb over the baro from about 10cm, which you have telemetry running. You see an immediate change in altitude and around a 15 second correction. Take the light away, and it will do the same.
Hope this helps someone.
Comments
@Euan Ramsay
Would it mean that internal temperature takes a long time to stabilize?
How did you reset the zero altitude after your two running hours?
@Euan: Did you do your experiment?
Thanks Euan!
I did another test on my platform with an altered driver. My assumption was that the (a few cents) cheaper part the MS5607 is perhaps more resiliant to thermal influence than it's more precise brother the MS5611. The MS5607 has 20cm and the MS5611 has 10cm resolution. The drivers differ slightly in the calculation and so I altered the MS5611 drivers "off" and "sens" calculation pretending that it is a 5607. The reported hight still rises but def. less than before (I think it could be half as well). During the testflight a difference was hard to tell but I think the 5611 driver was a little better. So just a short test note of something that seems stupid. That is def. no solution to the problem but perhaps something to try out by arducopter devs. Perhaps that could be a "dirty patch" to diminish the problem. I don't know and just want to report back a finding that might be useful.
Greetings Rob
Hi! I did a test on the ms baro and temperature. During operation the MS baro seems to heat itself up by +2,7 degree after 230sec.
EEPROM Calibration data from both tested parts.
Both are advertised to be MS5611.
The Prom 0 differs! Freeimu Baro has plastic cap. Naze32 has metal cap.
NAZE32 FREEIMUv035_MS
Promword 0: 4 0 16 bit reserved for manufacturer
Promword 1: 49495 49332 Pressure sensitivity
Promword 2: 49581 48279 Pressure offset
Promword 3: 30345 30707 Temperature coefficient of pressure sensitivity
Promword 4: 26329 26621 Temperature coefficient of pressure offset
Promword 5: 32904 31744 Reference temperature
Promword 6: 28273 28331 Temperature coefficient of the temperature |
Note: Promword 7 contains checksum data and is omitted here.
Test condition:
Ventilated room with about +24 Degree celsius.
Freeimu was not covered by foam or anything.
Naze32 was covered by much foam that most probably transduces heat of the surrounding chips.
Both parts were started at the same roomtemperature. The delta temperature from "cold start"
was measured over time.
Result:
The MS Baro on freeimu maxed out at +2,7 degree celsius after ca. 230 seconds
The MS Baro on Naze32 reached +6,2 degree after those 230sec and maxed out after
ca 600sec with +7,9 degree celsius.
Discussion:
The freeimuresult can be taken as normal Baro heating up during operation.
The other result shows a significant heat up from surrounding chips most likely
amplified by the attached foam.
According to this: http://de.wikipedia.org/wiki/Lufttemperatur#Abh.C3.A4ngigkeit_von_d...
the temperature/hight is almost linear on the first 2KM. A temperature of 10 deg. on the ground will be 0 deg in 2Km hight. So one degree difference would be 200m. That is without compensation mechanisms and airpressure compensation but shows the important role of the baro measured temperature. This test also shows that there is a significant difference in measured temperature and the surrounding chips on a pcb.
Cheers
Kraut Rob
Differential baro for something with very limited flight time is normally not necessary - except you are living in a place with frequent and severe airpressure changes. GPS will not solve for that as well because it has poor vertical resolution and produces 10m jumps quiet happily - I would choose a baro over gps any time in this regard. I don't know if it is supported in apm but maybe it is possible to connect a different baro over I2C, because the onboard ms5611 is connected with spi it could be disabled by software.
@c_j_g, Great idea! Differential barometers are the way to go and that gives a great reference. Solid altitude fro sure
@ Weather changes ambient air pressure
This could be a nice extension for andropilot and/or droidplanner sending correction data to the UAV. Some Tablets (motorola xoom e.g) or smarthones (galaxy s4 e.g) have buildin baro-sensors (using on the ground 99% of the changes should be the reason of weather changes).
What do you think, is such a thing is possible (MAVLINK, virtual RC Channel)?
-
1
-
2
-
3
of 3 Next