My 3DR Iris+ (Pixhawk with ArduCopter v3.4.2 Quad installed via Mission Planner) is unable to maintain a steady altitude in the Loiter flight mode. In particular, the altitude will remain fairly stable for a few moments but then–with no user input or change in elevation–the copter will rapidly ascend. Unfortunately, my only operating environment currently is a relatively small room (roughly 8-foot ceilings) which means I have to trigger the emergency switch and kill the motors to avoid serious damage. Because I’m inside I can’t use GPS so I’ve resorted to using a PX4Flow Optical Flow board and Maxbotix EZ4 Sonar in its place.
I’m fairly new to the scene so forgive me if I’ve left out any important information; I’m happy to provide it upon request. I’m attaching four log files to this post (actually two this post and two to an immediate reply post due to new user limitations) to hopefully allow someone more experienced to offer some insight. I thought the problem may lie in the EKF settings but that may be way off track. Either way, that was where my crude debugging led me and where I looked initially for a remedy.
The two files titled Default_Settings_X.bin were from two flights using the default EKF settings. IMU_0.bin is a log file from a flight where I disabled the use of the second on-board IMU and relied only on data from the first. Finally, fearing rangefinder issues, I turned my attention to the HGT_I_GATE parameter to try and avoid erroneous readings (I lowered the valid range from 5 standard deviations to 2) and that flight information is recorded in HGT_I_GATE_200.bin.
The copter displayed the rapid, unprompted ascension in each of the flights. As I said earlier, my only option at that point is to quickly end the flight by means of the emergency stop switch on the RC so, unfortunately, the flights were short and the flight data is fairly small. I hope that I’ve given you all enough information to help me with this issue but I’ll certainly provide or try anything I can to further the discussion.
I haven’t looked at your logs but there are some options for you to use:
if you are using Auto or Guided (unlikely since you are inside), terrain following so that your copter tries to maintain the same distance to the ground using your rangefinder (in this case a sonar)
changing the EKF parameters:
EK2_ALT_SOURCE which says to the EKF to rely on rangefinder altitude as long as it is healthy
EK2_RNG_USE_HGT which is the percentage of RNGFND_MAX_CM parameter that EKF can use for altitude
The last one is a little hard to explain, but let me give you an example. Let’s say you have RNGFND_MAX_CM set to 7m and EK2_RNG_USE_HGT to 70. This means that until 4.9m (70% * 7m) the EKF will look at the rangefinder to provide altitude. There are quite a few checks here to guarantee that the terrain below you is flat, which I guess it is in your case.
Thanks for the reply! Your first point is correct; I’m not using Auto or Guided mode. To your second point, I had actually already changed those parameters but tried varying them again with no luck. Interestingly, the jumps in altitude didn’t occur when I disabled the use of the rangefinder. The altitude wasn’t as stable as it normally is in Loiter mode when it’s functioning properly but, as I said, there was no unexpected behavior.
This leads me to think that erroneous data (spikes in the rangefinder readings) may be causing the issue as I’ve seen Err:24-0/1 in the flight logs when the copter “jumps” that correspond with Barometer Ratio Test (NKF4/9.SH) values over 1 (sometimes well over). If there’s an obvious fix that you’re aware of that would be great but, if not, do you think it would be beneficial to try and implement some sort of logic in the EKF code to ignore readings that seem false (for my particular environment and height limitations that shouldn’t be too difficult).
Yes, if your rangefinder doesn’t provide a smooth altitude and have spikes it can disturbe the EKF and cause it to change between cores (the EKF2 used in 3.4 has one core running for each IMU). I guess that in that case the baro is providing better altitude readings - and as it relies on pressure it is normal that it isn’t as stable as outside.
The EKF already looks at 3 samples from the rangefinder and picks the middle one, so I’m not sure if there is anything else that can be done. I can point you to code, in a different area, that went in recently, that tries to discard outliers without delaying rangefinder data: https://github.com/ArduPilot/ardupilot/commit/bcea3ac8d4e224661acdcd80c9318b77df30d342
Personally I would try to replicate that commit on top of 3.4 (should be very simple) and using the default EKF settings or with EK2_RNG_USE_HGT.
If none of that works I can only say that sonars are known to not be very reliable and maybe you can try a LIDAR one? No promises that it will fix your issue, but those are known to be better.