Understanding EKFs for Altitude

I am trying to better understand how the EKFs work and integrate within each other/ the parameters that control their POS estimations.

I am configuring a multirotor for indoor flight in a warehouse, I just need the platform to be stable while in AltHold. I am unable to use GPS or a compass, I have been unable to get stable results and have had a few crashes. I m trying to better understand how to configure the EKFs so that they work correctly even without the added information from the GPS and MAG. Copter 3.5.x has been the most unstable for this. the minute I power the system on the POS(Vert) and POS(Horizontal) are already becoming confused. Look at the previous post below.
3.5 Altitude EKF issues

3.4.x has been the most reliable but not perfect, I have still seen many instances where the EKFs become confused and the altitude begins to lose control.

My biggest misunderstanding is the blend between the POS horizontal and Vert estimations. If maneuvering aggressively it is easy to cause the POS horizontal to become completely saturated and confused while the POS Vert stays relatively accurate, however the altitude still becomes unstable and will start to climb away. similar to the link above.

ArduCopter does not allow you to disable the MAG (MAG_ENABLE = 0) as it will not arm even with arming checks set to 0. I have instead set all the MAGs to 0 but still have to set a number for COMPASS_PRIMARY even though there is no primary MAG for the copter to use. the message “Bad Compass Error” displays on mission planner but the vehicle will arm. The yaw does drif a bit as expected because it should only be using the IMUs/Gyro for heading.

I simply need the copter to maintain its altitude without trying to do anything else, this has been harder than expected. are there any suggestions on how to configure the EKFs so the POS estimations remain accurate enough to allow the altitude to hold correctly?

Additional things tried:
EK2_IMU_MASK - trying to place more weight in the Baro measurements (no real luck)
EK2_IMU_MASK = 3 but I have tried just 1, no difference

It is also worth noting I have two 3DR X-8M that are my test platforms, one is configured with the PixHawk 1 and the other has a PixHawk 2.1. they both have the same issues.

Any suggestions would be really helpful. I am still waiting for the PRs to include to new EKF fixes which will have the new EK2_OGN_HGT_MASK param. I may create a custom build at test the new changes beforehand.

I thought since no one answred you, and I’m researching EKFs as well that I’d comment here.
I’m still learning the AP EKF, but here is a statement from the wiki

This process from 1) to 4) is referred to as ‘State Prediction’. A ‘state’ is a variables we are trying to estimate like roll,pitch yaw, height, wind speed, etc. The filter has other states besides position, velocity and angles that are assumed to change slowly. These include gyro biases, Z accelerometer bias, wind velocities, compass biases and the earth’s magnetic field. These other states aren’t modified directly by the ‘State Prediction’ step but can be modified by measurements a described later.

Estimated gyro and accelerometer noise (EKF_GYRO_NOISE and EKF_ACC_NOISE) are used to estimate the growth in error in the angles, velocities and position calculated using IMU data. Making these parameters larger causes the filters error estimate to grow faster. If no corrections are made using other measurements (eg GPS), this error estimate will continue to grow. These estimated errors are captured in a large matrix called the ‘State Covariance Matrix’.

Steps 1) to 5) are repeated every time we get new IMU data until a new measurement from another sensor is available.

If we had a perfect initial estimate, perfect IMU measurements and perfect calculations, then we could keep repeating 1) to 4) throughout the flight with no other calculations required. However, errors in the initial values, errors in the IMU measurements and rounding errors in our calculations mean that we can only go for a few seconds before the velocity and position errors become too large.

Without a truth source to stamp a Kalman with, it will rapidly grow in error because of the natural errors in these cheap IMUs. Even super expensive INUs, like Ring-laser Gyros, and Spinning Mass Gyros, will still have errors that cannot be totally relied upon and have to be constantly corrected manually. The ISS uses massive (can’t find the reference) spinning gyros to maintain accurate position data (and they also use massive gyros to maneuver it as well). But even these have to be manually updated for position regularly.

Thank you for the reply.
I have read through the wiki and was concerned about the reliance on other sensors such as GPS for fundamental flight performance.
I guess my biggest problem is the use of the EKFs in a mode such as AltHold. I have seen numerous problems using Arducopter without a GPS installed. I am the 1% of users and have been trying to figure out the best way to get reliable altitude assistance with manual lateral control (ie complete pilot controlled) but there have been situations where the Pos(Horizontal) becomes completely saturated (complete EKF confusion) which makes the Pos(Vertical) become unstable as well and Arducopter commands the multirotor into an uncontrolled climb or decent. The only way to save it is by switching into Stabilize.

I just think the use of the EKFs as they are setup now in AltHold the same way they are used in Loiter is flawed logic. Obviously in Loiter a GPS or some other sensor truthing source needs to be used. but in AltHold it has the sensors need for accurate hold already installed (Baro, Acc, Gyro). Arducopter knows when a GPS or other sensors are not connected and should revert to other ways of maintaining flight performance because the current EKF setup is inherently flawed. I have recently run Copter-3.6dev with the new EK2_OGN_HGT_MASK and have still seen the EKF runaway and altitude become unstable.
I cannot use a GPS or Optical flow because i am using the multirotor for indoor inspections and those place can sometimes be completely dark or featureless.

Arducopter with a GPS = magnificent performance and stability
Arducopter with out a GPS = a ticking time bomb of complete EKF saturation

I know my use case is a very small percentage but was hoping there was a more reliable way to configure the EKF use for AltHold without the worry of runaways. the PixHawk 2.1 has been the most unstable because of the IMU heaters which can make the IMU outputs very inaccurate over time as the temperature changes and no other sensor to truth the data.

I guess I just haven’t seen this happen. No idea how big your craft is, but my “toy” Skyviper can fly inside for the entire battery and never have issue. I suppose a larger craft may have more vibrations which will compound EKF errors.

Here is a simple screen shot of MP after one of the latest flights running copter 3.6dev. Granted I was purposely trying to invoke the EKF runaway to see how it compared to other Copter FW versions. The test platform is the 3DR X8 and I have one with a PH2.1 and PH1.

Notice it thought it was at -74m before we landed it. it was trying to command an aggressive climb which when flying inside… Can be a big problem.

I understand we don’t live and a perfect world and IMUs are very error prone, but when you start loosing control of a multirotor with expensive equipment on it, the pucker factor is real.

one surprising note is, the quickest way to invoke the EKFs is to try and hover as still as possible which seams counter intuitive.

Were you ever able to solve this problem of flying indoors without compasses? If so, what did you do? Thanks.