The question might have been asked but i cannot find a trace…So I am asking it here.
Related to this question is the best practices related to flying a UAV :
Is the Radio channel has priority over the Mavlink ?
Is there any Fail-safe method implemented for Mavlink over UDP ?
What is the Fail-over mechanism when you lose the Mavlink (providing you can detect it) ?
Is the RTL can be triggered any time ,-either by radio or by the App ?
Obviously, I can experiment all these live, but it might be a petty expensive experiment…
I’m interested in this too - can anyone answer the detailed questions in OP’s post? It’s easy to say it’s safer to have the RC too, bit that doesn’t answer the questions regarding failsafe using a UDP radio - will the same failsafe be triggered as for loss of RC signal?
@ppoirier To answer your questions (to the best of my knowledge):
The radio channel doesn’t have priority over Mavlink. Whichever command was sent last (via radio or mavlink) will take effect. However, there are some commands that are only available via radio.
You can set the GCS Failsafe to control fallback when connection with the GCS is lost/dropped. The same mechanism is used with the 3DR Solo drone since it doesn’t make use of a RC controller.
Same as above.
Yes.
That said, flying without a RC controller turned on is only supported on ArduCopter v3.3 and higher, and you must have the Radio failsafe disabled in that case.
In addition, bear in mind that typical mavlink telemetry radios have a much shorter range then a RC controller.
I’ve pinged Randy (ArduCopter main developer) to confirm these answers since he has experience flying without a RC controller.
Looking at the issues, we can relate to some commits on rel 3.4: https://github.com/ArduPilot/ardupilot/issues/705 and this is @billbonney comment:
I think it should be simple as making GCS Failsafe a user defined failsafe (if enabled it works) otherwise ignored) The gotcha is option 2 if you want that as an extra safety feature. ie. if you use RC_OVERIDE GCS Failsafe automatically enables. Or maybe some option to have that enabled unless disabled (ie the Continue in Auto even if connection lost to telemtry)
GCS Failsafe - When enabled, the vehicle will trigger a Loiter for a period then RTL/LAND on connection lost. (There’s an extra mode to continue if in Auto for Plane)
RC_OVERIDE Failsafe. - When enabled and the user is controlling the vehicle via telemetry radio, trigger a Loiter for a period then RTL/LAND on connection lost to the GCS.
Connection lost is determined by receiving heartbeat packets from the the GCS.
And looking at the code: https://github.com/ArduPilot/ardupilot/blob/master/ArduCopter/events.cpp#L76
// return immediately if gcs failsafe is disabled, gcs has never been connected or we are not overriding rc controls from the gcs and we are not in guided mode
// this also checks to see if we have a GCS failsafe active, if we do, then must continue to process the logic for recovery from this state.
if ((!failsafe.gcs)&&(g.failsafe_gcs == FS_GCS_DISABLED || failsafe.last_heartbeat_ms == 0 || (!failsafe.rc_override_active && control_mode != GUIDED))) {
But the question remains: Are these GCS_FAILSAFE features are enabled within Tower ?
P.S.
It would be interesting to have a general workflow showing the complete failsafe logic = Including RC + Battery + GCS and others (Like Companion Computers) so we can build standardised checklist and procedures.
Some of your questions have been answered by others and some you already know but just in case…
re RC vs MAVLink priority. The “rc-overrides” (pilot’s stick inputs but sent by the GCS via mavlink) take priority over the pilot’s input. If they stop arriving (for a few seconds) Copter will fall back to the regular RC input
Copter really doesn’t have a failsafe for mavlink messages. We should change the GCS failsafe to do this (and there’s already a to-do item to do this). Currently the GCS failsafe only triggers if you’re using rc-overrides which is redundant because the radio failsafe (aka throttle failsafe) already covers this.
RTL (and any other flight mode) can be triggered any time by the RC transmitter or the GCS. They all get processed in the order they’re received (i.e last one wins).
Thanks Randy for your fast reply. Can you confirm if this feature is implemented on both Arducopter and ArduPlane (I cannot find the code within Plane, or should I ask Tridge ?).
@ne0fhyk , can you explain how the GCS fail safe is implemented within TOWER ?
I am planning on setting a Companion Computer on a QuadCopter, (Randy’s Balloon Popper). I am really looking to use Tower as the GCS because it is sitting right on top of my radio consequently I just want to make sure that the FAILSAFE features are fully compliant with Mission Planner so I can build my check-list and go through my test cases.
@ppoirier not sure what you mean, since all the failsafes are implemented in the autopilot. In Tower, you can use the Parameters screen to edit the failsafe value.
@ne0fhyk ,
Sorry for the confusion , I meant: supported in the sense of that Tower do offer an interface so that the user can modify the FLYSAFE setting (yes) and that there are no features in Tower that may automatically alter or overrides these settings (my guess is yes).
Then , this is how I could write the answer to my question:
Yes , you can use Tower as the main control for an ArduCopter, because the Failsafe features are implemented for any GCS that are Mavlink compliant. If you lose contact, for any reason with the GCS, the copter will either Land or RTL, depending on the GPS status. Unless the system is in AUTO mode and you have selected from the parameter list the FS_GCS_ENABLE parameter to 2, in which case we should continue with the mission.
The mission can be aborted if the pilot take control using RC, and switch to a manual mode (Not Guided Nor Auto), and regains control. In a case where both the GCS and the RC gets into Failsafe (beyond radio signal for example), the copter will either Land or RTL,depending on the GPS status or continue with the mission if the vehicle is in AUTO mode and the FS_THR_ENABLE parameter is set to “Enabled Continue with Mission in Auto Mode”, in which case there is no method within Ardupilot to terminate the mission.
Just an update: I did a couple of live test this week-end, going through most of the test cases and so far everything is working great.
Tower is a real good tool and has a lot of interesting features, I like the interface, it is is intuitive and easy to work with.
I have an aditional question, I am sending a mavlink message through a node-red-contrib-mf-mavlink in node-red software. I my node-red based dashboard to do the same task as tower do. I have few confusion in which mode i send my MAV_CMD_NAV_TAKEOFF mavlink command from node-red?
I have seen few tower videos, in which they initally put drone in RTL mode and when they give takeoff command drone switch to guided mode after takeoff is initiated.
consequently I just want to make sure that the FAILSAFE features are fully compliant with Mission Planner so I can build my check-list and go through my test cases.