I’m experiencing baromenter spikes. This results in crashes cause the apm tries to compensate the wrong height readings (in alt.hold and loiter)
I’m still investigating if my problem is a damaged barometer or a wrong installation of the board.
I found on internet many people that encountered this problem.
Someone solved it by covering the apm AND placing it inside a case.
This because the barometer is sensitive to light.
I considered that:
Alt.hold mode and loiter mode are simplified flight modes that helps inexperts to do safe flights
the price of a complete drone with good components is really high
3kg dropping from 10 meters becomes about 240kg on your head, so a drone is a really dangerous thing.
Considered all these aspects, MY QUESTION IS THE FOLLOWING ONE:
Don’t you think that we should strengthen the source code in order to avoid that a damaged or defective sensor causes a crash?
In example:
if the barometer changes values from 10meters to 100 meters in a really short time, it’s obvious that the reading is wrong and the value should be compensated with an offset in order to do not consider it.
Comparing more than one sensor is possible to identify impossible situations, in example:
-the barometer changes values from 20 meters to 10 meters in a really short time, but the accelerometers have no correspondant change, it’s obvious that the barometer reading should not be considered by adding an offset.
These are just 2 examples, the logic behind it can be more complicated but i think that an improvement on this side should be done.
Another solution (that requires hardware modification) could be the connection of a redundant apm, slave, and activated on demand, when the failure is detected. But this last idea is too much drastic, do not consider it.
[quote=“StefanG”]Which flight controller are you using?
And - this kind of things are in the work through better filter development.[/quote]
That’s really great
Here: APM 2.6 with 3dr external compass / gps, V2.9 software. (now running 3.1.4 but tests were made with 2.9.x)
After reading many examples of barometric problems I tried to experiment without flying.
The end results were:
From dark to sunlight: Altitude gain: 150 meters without moving the hexacopter by 1 mm
So even it isn’t in the doc of the barometer device, light isn’t a friend
At 22 Celcius degrees ambient temperature:
Start APM inside the 3dr enclosure. This enclosure is protected from any possible wind inside a plastic outer shell. APM connected to laptop with USB cable.
Run CLI and did baro calibration.
I guess self heating must do something to this pressure sensor… Values moved quite a bit and it took about an hour to get perfectly stable. (within ± 10 centimeters).
It appears that something improved quite a bit with V3.1.4 :mrgreen: Even from start, it looks quite stable and seems to behave nicely…
So No light and no wind will help your APM’s altitude behavior for sure
