Peter, I don’t know anything yet about EKFs, but I do know about barometric sensors, accelerometers and such, having designed circuits that use them.
When an accelerometer reads -1G in Z, and zero in the other axes, that doesn’t mean that it’s at a stable altitude. It only means that it’s not accelerating up nor down. But it still might be climbing or falling at a constant rate, even a very high rate. If it reads -0.5G in Z, that doesn’t mean that it’s sinking. It just means that it’s accelerating downward. It could actually be climbing, but decelerating the climb.
Barometers are very reliable sensors for absolute altitude, in the time frame of quadcopter flights, but they are too noisy and thus too unstable to quickly measure very small altitude changes, or to derive stable accurate, fast-responding vertical speed or vertical acceleration information.
So it makes a lot of sense to combine an accelerometer and a barometer, taking the acceleration directly from the accelerometer, the altitude directly from the barometer (with proper compensation for the atmospheric pressure/altitude curve, and a low-pass filter to reduce the noise). The vertical velocity might be be obtained by combining both with some weighting, after derivating the barometer signal and integrating the accelerometer signal.
A GPS is less stable for altitude than a barometer, but is largely free from weather effects, so it can be used for long-term altitude calibration of the barometer. I don’t know really how good the vertical velocity data is, for a modern GPS receiver. The old ones I worked with very quite lousy in this regard, But those used only a few sats for a solution, while modern ones use many sats.
All this long wording is just to support my claim that barometers should not be considered less trustworthy than accelerometers! To know at what altitude we are, several minutes into the flight, an accelerometer is completely useless. Any calculation based on accelerations measured throughout the flight would be extremely inaccurate. Likewise, of course, trying to fully stabilize the altitude just based on a barometer would be a poor approach, because the craft would try to follow the noise on the barometer’s output.
So I claim that if the barometer is duly considered in the calculations, and fully trusted for altitude, the craft should never shoot up and out of sight when the accelerometer is acting up due to vibration.
In a very simple altimeter/variometer I built roughly 20 years ago, using one of the few barometric sensors available at that time, averaging the sensor’s output over one second produced a noise of less than 20cm altitude. With longer averaging, the altitude resolution can be improved to the centimeter level. Uncompensated thermal drift is about -4 meters from switch-on to stabilization of this particular circuit. Altitude oscillations caused by a storm forming eddies around buildings can be as much as 15m, but nobody would fly a quadcopter in such conditions. Between one day and another the weather-induced altitude change can easily be 100m, and this is where GPS comes in…
Eventually I will have to look into EKFs, and maybe into the Ardupilot code, to better understand what you guys are doing. The reports about quadcopters rocketing up and getting lost because of vibration interfering with the accelerometer, and the accelerometer being trusted more than the barometer even in that situation, ring an alarm bell.
Anyway, I have now set up one switch to select between Stabilize, AltHold and Loiter, and another to override that and go into RTL mode. And I will pay a lot of attention to having low enough vibration, before I try to fly this drone.
I looked into Realflight, but seeing that it is commercial software turned me off. I’m in the process of weaning my computer from all commercial software, in favor of free, ideally open-source software. And if it’s portable, that’s a plus too! But the idea of using a simulator to get a feeling for manually flying a quadcopter is a good one. I will see what I can find.