Hi there, I am using Plane 4.0 and have a RPi attached to autopilot on telem-2 port. I am assuming that GCS failsafe is taking action on telem-1 port, but If I need a additional failsafe option on telem2 due to companion computer guiding the plane might fail somehow and since the commands will timeout when CC is absent, I want to protect the Plane from undesired behaviour of loitering at that moment and just put it in RTL or AUTO mode so that it can run a pre-loaded LAND mission, Is there way to do so? Or I just have to give up on real radio failsafe and connect Rpi to telem-1 port? Because I could not find such option for telem2 so far.
Thanks in advance
I have tried the failsafe in simulation. Setup 2 connections, one with gcs and second with dronekit. Regardless of the port number, it works when there is no any connection. It does not work when 1 one of connections is still active. I digged into the codes and found out that it looks for the last heartbeat everytime. But I not expert of AP codebase.
I have few questions, does AP deal with telemetry ports just as one connection? I mean, it is not separating the channels and just acting like single connection on them? Because failsafe.last_heartbeat_ms must be being updated by the active connections constantly, once one of them disconnects it does not go into failsafe situation, both must be disconnected. So that no heartbeats received.
Thanks in advance!
Why do you think that gcs fs only works on telemetry 1 port?
I think it might not matter which port, but instead wherever the mavlink data is flowing, gcs failsafe is triggered on heartbeat timeout.
I thought it will work on telem1 because its called “GCS fs” and primary connection for gcs is telem1. And I needed to protect from possible telem2 loss which is commanding the FC mainly in GUIDED or loading missions and running autonomously for specific tasks. Most of the time, I am observing from GCS and sometimes modifying params, loading mission etc.
And for your question coming from, @Scott_Nunan
https://discuss.ardupilot.org/t/companion-computer-failsafe/54537/7?u=eminakgn
What is your topology? If the Fc is connected to your esc/servos then IT is the last item in the link and the fc is the thing that needs to detect a failsafe condition if CC coms is lost.
The way im doing it, is flight controller failsafe on gcs timeout. And the connection goes GCS - CC - FC, so any failure in the link will drive a failsafe RTL
So you actually combine GCS and CC together? I understand that there is just one running mavlink connection through your FC and that is on CC. How did you setup telemetry link between CC and GCS so that CC will receive from GCS and route to FC?
My topology is conventional one, gcs on telem1 and Raspberry Pi on telem2.
Yes raspberry pi zero with camera. And usb otg cable to usb modem. All telemetry and control goes via telemetry 2 port to rpi, along with picam video to server to java app and gstreamer into mp.
I cannot take any credit for the code. It was all done by Gennady Schmakov at Minla Rc
Looks good, but in my case, I am not or will be using internet connection to connect ArduPilot 
Any advice is welcome!
I am curious for ideas!
Sorry to bump an old thread, but did anyone have any luck with this? I’m interested in doing the same thing and looking for instructions and scripts to utilize in order to command an RPI to handle failsafe solutions during flight where the C2 link or GPS link is lost.
I am currently having a similar issue. I have my GCS telemetry radio (RFD900) connected to telem1 and companion computer running DroneKit connected to telem2. With dronekit running on the companion computer the GCS failsafe does not trigger when loosing connection with the GCS radio. I have tested this on the ground by starting dronekit and powering off the GCS radio. The plane stays in Manual mode and never goes into RTL. If I turn Dronekit off and power off the GCS radio, the plane goes into RTL and stays in RTL after reconnecting the GCS. Is there a way to handle GCS failsafes differently on each telem port or another work around? If not, I would propose adding this feature as this seems like a major limitation for any flight with a companion computer and without RC such as flying BLOS.
Currently the only work around I have found is to send a request data stream message via mavlink as described here which would require a significant code rewrite on the companion computer.