There seems to be a flyaway case in the execution of the FlytOS.
Under my current setup, I am using a Pixhawk that has two telemetry links; on TELEM1 I have 3DR radio connected for gcs comms for backup and on TELEM2 I have RPI3 (with FlytOS) connected to the Pixhawk. The frame I am using is an OCTO
- Start OCTO in Stabilize mode
- Climb and settle at an altitude
- Switch mode to Guided mode
- Start Mission from the website flytbase.com . (NOT the 10.42.0.1 link) During the entire flight, the GCS is never connected to the WIFI-AP on the raspberry pi on the 10.42.0.1 link.
- Now with the mission started, the telemetry link on TELEM1 is lost.
- Following the TELEM1 link loss, the TELEM2 loses connection with 4G network.
When TELEM1 link was lost the OCTO should have gone into RTL mode due to loss of reception of heartbeat signal from GCS. However, since there is a secondary telemetry link from the PI, this never occurs, which is the expected behavior. However, when the 4G/LTE connection is lost, as mentioned in step 6, the OCTO still continues to do it’s mission and doesn’t switch over to RTL mode. This can result in a possibly FLY AWAY situation as there is no failsafe for this.
I think the problem may be with how the heartbeat signal is dealt with in the FlytOS, where the RPI3 keeps on generating the heartbeat signal internally to get telemetry, even after the 4G/LTE network connection to flytbase.com server has been lost.This possibly prevents the OCTO from ever going into RTL as the heartbeat signal is still available locally from the RPI3, since the script dealing with sending the telemetry information to website doesn’t feedback the “comms loss” status back to the OCTO itself.
Software version : 1.56 PE
Please let me know if there is some setting that i am missing or if the aforementioned issue is actually a bug