Real-Time Companion-Computer Health Monitoring and Failsafe System

Hardware Companion Computers
1

Hi everyone,

I applied to GSoC 2026 with the Real-Time Companion-Computer Health Monitoring and Failsafe idea. It did not get one of the three slots ArduPilot was given this year, but I wanted to build it anyway, so here it is :slight_smile:

As we keep expanding ArduPilot with projects like Visual Follow-Me, GPS-Denied Autonomous Exploration with ROS 2 and High Altitude Non-GPS Navigation, more of the flight critical work sits on a companion computer. Right now ArduPilot has no way to tell if that companion has hung or dropped off mid flight. The copter keeps flying in GUIDED, waiting for commands that are never coming.

here is a small demo of the project https://www.youtube.com/watch?v=GweYXp5yXuU

How it works: the companion sends a 13 byte COMPANION_HEALTH message at 1 Hz. A new AP_CompanionHealth library follows the GCS failsafe pattern with four triggers: silence for CCH_TIMEOUT seconds, a frozen watchdog counter, a critical resource report, or a required process crashing (CCH_SVC_MASK). A pre-arm check blocks takeoff with a dead companion. CCH_ENABLE=-1 is warn only: full reporting and logging, no authority over the vehicle.

The transport is where I most want guidance. I added a new message instead of using ONBOARD_COMPUTER_STATUS (390): it is 240 bytes against 13, has no services field, and nothing in master reads it today. If the preference is 390, I will make the library accept it.

Code

Open questions: I have plenty for maintainers, but first I would really like a general review, obvious issues and bottlenecks I should work on before opening PRs. One convention question I do want to settle early: warn only is currently CCH_ENABLE=-1, the same style as Q_TRANS_FAIL_ACT. Should it stay a single parameter, or be split like BATT_MONITOR / BATT_FS_LOW_ACT, one parameter to enable monitoring and a separate one for the failsafe action? The rest of the parameter details are in the README.

Thanks,
Deepak

2

Do you have examples of things that aren’t covered by the current failsafes and timeouts?

IMHO complex vehicle health checking belongs in Lua as it is very setup specific.