Copter: add sanity check of baro readings

[GekoCH]

Hy

Today I had a crash with the ArduCopter v3.0.1-rc1 firmware. Never experienced that before so I was really surprised that this can happen.

I first flew manually and set the copter to loiter. Then manually again and finally to loiter. Suddenly all the motors almost stopped spinning and the copter came down from 10m above ground and crashed to the ground.

The log file can be downloaded from my post:
http://diydrones.com/forum/topics/arducopter-v3-0-1-rc1-sudden-crash-out-of-loiter

In the log file you can see that the "throttle out" suddenly went down to 130 without any reason...

EDIT: Probably I found the problem, there was a huge spike from the BarAlt (jumped from 9.09m to 5275m) so there is probably the problem...

Andy

[rmackay9]

This is added to the "AC with only Tablet" milestone after developer discussion brought up that switching to stabilize and controlling with the virtual sticks while possible, may be less of an option with the tablet only interface.

[priseborough]

A spike filter should be applied to the baro alt. This could take the form of a rate of change limiter set to the maximum copter climb/descent rate plus margin. This could also be made asymmetric such that the rate limit is applied when the baro alt moves away from the inertial altitude, but not when it moves towards it.

[bstott]

+/- 10% ?

[priseborough]

The consequences for hitting the limiter whilst descending are not good (height undershoot into the ground), so I would go for a bit more.

[bstott]

Would be time based. X% over Yms. Weighted average? All time based allowing change.

[priseborough]

Simple rate of change limiter would suffice.

[bstott]

I'm noob to terms. Simple rate of change limiter? Wouldn't that be what I described?

+/- 10% rate of change over small increment of time. Or weighted average?

[priseborough]

No - it has a specific meaning. Here's an example.

http://www.mathworks.com.au/help/simulink/slref/ratelimiter.html

[dramida]

(just crashed, details here #968)
Simple solution: We need to put a validation algorithm to barometer values, same done withh GPS glitch validation. When baro data is incoherent , then altitude pid loop is disabled and motors put to hover throttle (ponderated by throttle stick)

A better strategy is a corelative filtering between baro alt, gps alt and Z acceleration (Kalman).

[priseborough]

EKF implemented in master does reject baro spikes.

[dramida]

yeah...tell that to APM users

[rmackay9]

This should be fix with this commit (and the 10 or so that follow it):
2289b98

This will go out with AC3.2-rc4