Circumventing Safety Features

I recently encountered an interesting problem when configuring all three drones simultaneously with the Skybrush drone management software.

I would power up all three drones and connect them to the network I configured for them. All three would appear on my laptop. After double-checking that they were actively connected, I manually rebooted each one and confirmed the connection using the Skybrush software.

With propellers removed, pre-arm checks approved. I would go and arm each drone.

“Arming” is the last step before takeoff for a drone. “Pre-Arm” ensures all safety checks (foreshadowing) are completed but does not start up motors. Arming, on the other hand, starts the motors at a low rpm and listens for control inputs (i.e., throttle up) for takeoff. It disarms if no input is provided within 10 seconds of the motors spinning.

But here’s where the problem occurred. Only one drone would go into arming mode, while the other two reported an “unknown” error and blinked red.

After some research and trial and error, I discovered that the drone reported an “RC Not Found” error to the ground station.

Now, that’s strange; it should be configured to ignore whether or not it had an RC connection for Pre-Flight. I went into QGroundControl and manually configured it to ignore pre-flight checks for the RC. After a quick reboot, I tried again.

Still, no luck, except the behavior changed slightly. After the blinking red error, I tried arming the drones again… and they all spun up! But Skybrush still showed them as reporting an error. This is not ideal for my case, but as the classic saying goes, a different error is still in progress.

After more research, I found a forum post with someone asking a similar question and a super helpful user linking to a page about configuring ArduPilot with autonomous flight software like SkyBrush.

It ended up being two parameters that affected my problem.

• FS_THR_ENABLE – Allow arming without checking for RC
• ARMING_CHECK – Disable RC failsafe for pre-arm checks

Setting those two and a quick reboot resulted in all three drones being able to go into pre-arm, then arming mode, and ready for takeoff. The corrected values are:

FS_THR_ENABLE	0
ARMING_CHECK	1048510

The longer string for ARMING_CHECK signifies which failsafe options to disable; Arducopter gives you 19 total options for failsafe, from Compass to Battery Levels. A complete list is provided here.

And finally, here’s a quick reference list I had ChatGPT create based on the parameter’s instructions:

Bit	Check	Value	Description
0	All	1	Enables all checks
1	Barometer	2	Ensures the barometer is functioning correctly
2	Compass	4	Verifies compass calibration
3	GPS lock	8	Requires a valid GPS lock before arming
4	INS	16	Checks Inertial Navigation System (IMU) health
5	Parameters	32	Confirms parameters are set correctly
6	RC Channels	64	Ensures RC signal is valid
7	Board voltage	128	Monitors voltage levels of the flight controller
8	Battery Level	256	Verifies battery level is sufficient
10	Logging Available	1024	Checks if logging is available
11	Hardware safety switch	2048	Requires safety switch to be engaged
12	GPS Configuration	4096	Verifies GPS is configured correctly
13	System	8192	Checks system-level health
14	Mission	16384	Ensures a valid mission is loaded
15	Rangefinder	32768	Checks rangefinder sensors
16	Camera	65536	Verifies camera is functioning correctly
17	AuxAuth	131072	Checks auxiliary authorization systems
18	VisualOdometry	262144	Monitors visual odometry sensor health
19	FFT	524288	Verifies Fast Fourier Transform data availability