Hello, i was flying my APM 2.5 quadcopter (AC 3.1.2) in wind gusts in auto mode. Altitude was a little shaky due to high wind blowing in my copter. The baro did not had any sponge over it (my error), but it was encased in two layers, APM case and the protective dome. The stability was good so i decided to make an auto mission.
Suddenly, during second auto mission, at 30m altitude, an altitude spike appears in baro readings, indicating 170m instead of 30. In this moment all motors went to min throttle (200) and copter crashed.
The bug consist in the inability of arducopter to cope with bad readings of baro (some times they happen on bad weather). At most, even without filtered and validated baro data, autopilot should decrease altitude with max descent rate witch is 2m/s , but not put the motors to min throttle causing a sudden crash.
Before processing baro readings, data need some filtering and validation (like in GPS glitch case), or better a correlative filtration using accelerometer and GPS altitude
I have attached the logs.
Please decide for yourself by graphing baro altitude VS throttle out.
I don’t really think it’s a “find” as this is somewhat of a known issue. The program isn’t magic, and it cannot accommodate baro data that is that bad. With an altitude error of 140m, it’s going to crash if the pilot doesn’t take back control.
I actually suspect that the problem was due to light hitting the barometer, as that is much more likely to cause such a large spike than any aerodynamic effects.
How do you control the descent rate, when you don’t know the altitude, and thus don’t know the rate of change of altitude?
How do you control the descent rate, when you don’t know the altitude, and thus don’t know the rate of change of altitude?[/quote]
Indeed, without a valid input, the pid loop of the altitude controller would go to extreme. To avoid that crash, we need to imagine an integrity test for baro data as we did for GPS glitch. If barometer data is corrupted , motors should be driven from actual throttle to calculated hover throttle in a ramp. The final throttle should be 50% moderated by throttle stick position to allow some kind of altitude control immediately . Also a error message should be sent over mavlink.
The baro data integrity check should try to compare altitude variations against 10m/s or so and even to correlate with Z acceleration or GPS alt. My crash log presented in first post shows IMU 50Hz data, GPS data and baro data, we could use it to set the filter threshold.
And if you are not going to do anything with this bug, at least write with red letters on Arducopter instalation to check the sponge over baro or else…
I got a similar problem, when in a stable Loiter, during wind gusts my altitude signal (in Mission Planner, QuickView, “Altitude (m)”) shows suddenly height differences of +/- 20m within a second (!!!).
I have a hover throttle of about 400, you can imagine what happens then.
This happens also after a successful mission, when in landing mode - very funny, with our cars nearby…
My data flash log doesn´t show any altitude signals, i always have to investigate via Throttle Out or Climb Rate, anyone an idea why there is no baro logging (i selected for logging “nearly all” values)?
Foam: I bought a board with a fixed, soldered shield, the idiot forgot the foam on the baro, so i will improvise a cover.
By the way, in elder versions of APM, my sonar showed values in the “altitude” signal in lower height, now there is absolotely not even a “sonar voltage”, but in the terminal window in debug, its perfect.
In my opinion, there is still a massive problem in the height calculation.
this error I could not find. I have flown missions in gusts over 45 km / h without problems.
this error is probably not caused by a lack of filter, but because the cover of the baro missing.
have an APM and Pixhawk almost daily in use, mostly error-free.
Yes, this is true, if the wind is not blown directly into the sensor, you won’t have any issue. But, we would have a better software if it would be resilient to spikes in baro data, just in case. Easy to do, not a time consuming process for atmega. And a Mavlink message like “Bad baro” would be very helpful.
[quote=“KA800”]Hello
this error I could not find. I have flown missions in gusts over 45 km / h without problems.
this error is probably not caused by a lack of filter, but because the cover of the baro missing.
have an APM and Pixhawk almost daily in use, mostly error-free.[/quote]