search

PX4 / PX4-Autopilot

PX4 Autopilot Software
https://px4.io
BSD 3-Clause "New" or "Revised" License
8.48k stars 13.5k forks source link

Reverting from DESCENT failsafe to Manual control not working as expected #Flyaway #16490

Open ludost opened 3 years ago

ludost commented 3 years ago

Describe the bug After losing valid position information (due to incorrect vibration isolation and sensor clipping) a quadcopter went from RTL to the DESCENT failsafe mode. Using the RC to try to obtain manual control failed, due to the commander trying to go to POSCTL mode, which was rejected due to the lost valid local position. From a pilot's perspective, it was expected that the commander would then first try ALTCTL mode, and finally MANUAL mode.

To Reproduce Steps to reproduce the behavior: This describes an incident flight, see flightlog. I wouldn't recommend trying to reproduce the incident. (See flightlog at: https://logs.px4.io/plot_app?log=5346ca52-872f-4f96-b7f0-6d013dad0f5d )

  1. Fly drone with too little vibration isolation (=dangerous!)
  2. Pull into a maneuver (e.g. strong pitch)
  3. Clipping of Z-axis will lead to incorrect height (falling), leading to the drone to quickly gain height.
  4. In trying to handle the incorrect behaving drone, the RTL mode was selected by the pilot
  5. The drone went into DESCENT failsafe mode
  6. Pilot tries to regain control by using the sticks on the RC
  7. The commander tries to switch to POSCTL mode, which continuously fails.
  8. Drone is brought back to the ground through repeated kill-switch application, followed by a muddy search through an empty field.

Expected behavior There was a clear indication that the pilot was actively trying to regain remote control. It was expected that the drone would revert to such a manual mode as best as it could, falling back to the less supporting modes when needed given the state. In this case, a fallback to Manual/stabilized mode would be expected.

Relevant code location https://github.com/PX4/PX4-Autopilot/blob/a444d2610a51f6cbcc3289fc845944218ba01266/src/modules/commander/Commander.cpp#L2083

Log Files and Screenshots https://logs.px4.io/plot_app?log=5346ca52-872f-4f96-b7f0-6d013dad0f5d https://user-images.githubusercontent.com/871852/103641879-afc88a00-4f52-11eb-8c07-69dfb2970661.mp4

Drone

Additional context There are several other strange things in this particular flight log, related to how the clipping issue was handled by the EKF2 algorithm. These will probably end up in some other issue(s).

MaEtUgR commented 3 years ago

I'm really sorry to read about your incident. As far as I can understand the problem case in terms of the state machine is: Flying an automatic mode, losing position estimate, taking over by RC override (not the mode switch or mode command).

The RC override only being allowed to take over in position mode is by design such that you can not accidentally take over in this exact situation when you don't see the drone. Now that you explained the incident in detail it'd likely make more sense to allow taking over if there's still altitude control and the drone is anyways not able to control the horizontal position.

I take this up in the dev call and check for the best way to implement it.

Thanks for your feedback @ludost , I hope it's repairable. In the meantime please make sure to map a mode switch or button for these "dangerous!" tests.

ludost commented 3 years ago

Thanks for the kind words, yes the drone is repaired and now less dangerous. Thanks for taking a good look at this failsafe behavior.

It was actually a "pilot error" that I didn't try to switch to manual mode myself, I only thought of that afterwards. That's maybe the main point: The drone went into unexpected behavior and I failed to regain control as a pilot. Controlling height through a kill switch is not "being in control" :+1: