While flying inside with a quadrotor with an HKPilot32 running ArduCopter V3.6-dev (why a dev version was used is another discussion...) and equipped with a LIDAR-Lite 3 and a disabled GPS, the quadrotor hit the roof (battery disconnected at that time) when we activated the auto land mode.
From the DataFlash logs, we see that CTUN.DAlt (Controller TUNing Desired Altitude) was set to around 4.6 m at that time (which is consistent with the quadrotor sudden ascension), while the quadrotor was flying around 1-2 m of altitude when land mode was activated. We see also that a previous land succeeded 2 min before, so the problem was quite unexpected.
Although the Auto Analysis function on our log suggests that we had accelerometers accuracy problems, I do not understand why CTUN.DAlt got this value considering the current altitude estimation. How is the desired altitude chosen in land mode? Also, is CTUN.Alt the best altitude estimation used by the land controller, or is it another one (I looked also to XKF1.PD but it is quite similar, but with the opposite sign)?
Thank you for letting me know if you have explanations on this behavior (log is in attachement)!
To be more clear : it appears that during AltHold with throttle to the min, the drone descended a little bit but it was not noticeable during the flight. In addition, neither Guided waypoints nor RTL made the drone come to the expected position and altitude, which resulted in a wrong panic reaction for the pilot!
Fabrice LE BARS said:
We got another similar behavior with an hexacopter climbing outside in Land mode (as well as RTL, AltHold with throttle set to the min, only Stabilize make it fall, see attachment), but I think now I know why.
In this flight, we had 2 propellers with a damaged end, making them unbalanced and probably leading to high vibrations. By looking closer to the VIBE values and the recommendations on http://ardupilot.org/copter/docs/common-measuring-vibration.html , it appears that both flights had too much vibrations. This post also seems to have the same problem : http://diydrones.com/forum/topics/uncontrolled-climbing-in-auto-mod... .
However, I am still a little bit surprised that even with at least 2 sensors that work correctly (baro and LIDAR-Lite for the quadrotor inside, baro and GPS for the hexarotor outside), the drone is still not able to realize that it is climbing while it should not...
Thank you, indeed, our RTL_ALT value was set to a dangerous value for our indoor environment, we definitely need to add that to our check-list.
However, the documentation of the LAND mode do not specify that this value is used, and in our case it was set to 15 m which does not seem to correspond to the 4.6 m that our drone wanted to reach. And the log does not seem to mention that a RTL or any failsafe was activated at any time.
I tried also to look closely to our LIDAR data to check if there was any "ghost" obstacle but there is nothing visible. I do not see other potential reasons for the drone to climb in the documentation of the LAND mode for now.
I noticed also the existence of the GND_ABS_PRESS parameter but its value looks correct.
I know the RTL command "RTL_ALT: RTL Altitude" can be set to climb to a certain height before a RTL Needs to be set to 0 to avoid a climb I believe.
I had a low battery FS kick in once, copter went to RTL mode as programmed for that event,( that I didn't realize at time), climbed to ceiling, which was too low for RTL Altitude and stayed trying to climb till I think I switched mode to STAB and I regained throttle control . Have been careful with any indoor testing and FailSafe settings since!
Look here for settings:
Also here for LAND information from WIKI, talks about sonar but maybe same applies to LIDAR sensing an obstacle as well?
Here is a screenshot that shows what happenned, where we see that the quadrotor tried to go to 4.6 m of altitude because of the CTUN.DAlt value.