I am hoping someone might be able to help me understand the MAVLink and UAVTalk protocols a bit better, specifically with regard to implementing flight termination more gracefully than simply crashing. My questions relate to the uplink only.
1. Is there a regular transmission that is sent from GCS to the air vehicle that can be used to detect loss of uplink? And if so, are there any bytes in this packet that are constant or at least predictable and can be validated by an onboard flight termination device?
2. If a "go to home" command is issued to the air vehicle by the flight termination device, does the sequence number matter? In other words, does the autopilot obey the command regardless of how incorrect the sequence number is? I realise that this may be autopilot specific.
Thanks is advance,
Thank you. The command that is sent to the air vehicle is entered in a user field in the configuration software and stored in the flight termination device, so all of these possibilities are, er, possible. Just wanted to know whether I had to parse the uplinked MAV packets, and from what I have learned so far it seems that I do not.
Perfect, thanks Bill and Kevin.
Regarding monitoring of the telemetry uplink, I think the MAVLink uplink heartbeat should work fine, as long as it is sent often enough.
The hardware will not have authority over PWM or PPM entering the autopilot, so it will not be able to initiate a RTL that way, but sending a MAVLink command to the autopilot should be fine. Obviously if the autopilot does not respect the RTL command within a certain time frame, the flight termination device may take more definitive action.
I've written a GCS, so I'll give this a shot:
1) Yes - the GCS sends mavlink heartbeats (with the vehicle type listed as GCS)
2) For APM (at least) the sequence # matters if you are setting a new current waypoint (go to home would be setting 0 as the current waypoint). Setting mode to RTL does not need a sequence number (it is just a mode set)
Thanks for the clarification. :-)
I don't see anyway around monitoring MAVLink Heartbeat messages. To trigger failsafe you can either send a MAVLink message to RTL, or you could set the mode switch PWM to correspond to the failsafe option i.e. RTL as when you have TX loss.
I haven't looked to see if there is a rejection of packets with the same or out of sequence number, but it's only an 8 bit value. If you sent the command multiple times, it will loop round quite quickly and will be a fit, if you understand what I mean.
If i have any other ideas to keep it simple, I'll let you know.
Sorry I should have introduced myself - I run Millswood Engineering. Kevin contacted me a while back regarding flight safety matters and has been instrumental in encouraging and shaping a redesign of the current Failsafe board to be smaller, more capable, and better suited to the needs of multicopters.
Hence all the questions. Suggestions welcome!
Thanks Bill and Drone Savant for the added detail.
In fact the device that will be listening to the uplink and potentially sending a RTL command will be an update of this device.
I am not planning on monitoring the downlink, so any heartbeat must be GCS -> MAV.
I would prefer to make the device protocol agnostic, hence the question about sequence number. If a suitable RTL command can be framed at configuration time (rather than run time), this will avoid the need to parse MAVLink packets and have the added benefit of reducing processor overhead. Obviously the RTL command needs to be entered by the user at configuration time, and stored in non-volatile memory onboard the flight termination device.
If I have to parse I will, but my preference is to avoid it if poss.
Ah, thanks Bill.
I will try to read more of the MAVLink documentation.
Thank you Bill,
Yes, they were rather specific questions.
If there is no retry protocol, it is reasonable to assume that the autopilot must obey commands regardless of sequence number.
Looks like it was a vain hope.
I guess once a question slips off the front page it is destined for eternal obscurity.