Right now it is difficult to reliably report why the vehicle is in a failsafe condition. I'm not cognizant of how PX4 handles the situation but I will summarize the current ArduPilot (specifically plane) behavior for communicating this to the ground station, as the basis for why I am looking to expand on this.
- When the system enters the failsafe state it will send a status text message such as "MSG FS ON 0" (this is a loss of RC failsafe).
- When the timer before taking the short failsafe action expires you will recieve a message such as "Failsafe. Short event on," followed by a second status text that indicates what it did.
- A long failsafe will display much as a short failsafe did.
- The moment the aircraft enters the failsafe state the heartbeat starts broadcasting as MAV_STATE_CRITICAL. This is the only recurring message that indicates the aircraft is behaving under failsafe logic, and it provides no justification for that.
There are two large problems that I would like to look into addressing (Ignoring that our status text messages are truly confusing to the user):
- If you miss a status text packet for any reason you might not be sure why the aircraft is executing any failsafe logic at all. (You might think it was because of a loss of radio, and send the aircraft back to the mission even though it was a battery event). The only recurring info you receive is that you are in a failsafe state, which has the knock on effect for ArduPilot that we have no way of reporting to the GCS if the autopilot believes it has crashed or is not flying, as the failsafe has priority in the heartbeat.
- The second problem is that as we look into prioritizing failsafe events it gets hard to track on the GCS what failsafe are active, versus what ones are not. On the horizon of things we are looking at working on are multi stage battery failsafe's with different actions taking depending on which is true, it'd would be extremely nice for the GCS to know that failsafes foo and bar which were both active is now down to just foo.
My proposed solution is to add a FAILSAFE_HEARTBEAT packet that would be broadcast at the same rate as the normal heartbeat packet, but only when a failsafe is active (we could do all the time, but I suspect its a unneeded burden on the link most of the time). The packet would contain a bit mask of failsafe events to indicate which ones are active, as well as a enum that indicates what the current action the autopilot is attempting to take to resolve that. (RTL, land, circle modes/alt hold, terminate, parachute etc (or user overriden)) The last thing in the packet would just be a timer that counts the duration the aircraft has been in a failsafe state (useful for allowing the operator to predict when it will execute the next step of the failsafe logic).
I haven't worked up the message defintion XML's for this yet, I wanted to get some feedback from the various projects on if this approach is appealing?