Unexpected Arming of Drone

1

Hello,
Myself and a colleague have been having a reproduceable issue where, when the radio controller is turned off, the propellors start turning very fast instantly upon the arming button being pressed. This occurs with a modified mixer where each actuation control channel is being passed directly to an individual motor. We haven’t gone through the firmware yet to figure out the root cause, but it surprised us a couple times and we thought we’d ask if anyone else has been having the same problem, and if not then let people know this is a potential issue.

2

Scary! Ok it would be good to get some more information:

  • What’s the PX4 version used?
  • Does this happen after flying? Or always?
  • Do you get error messages in QGC?

My hunch is that you are still armed after flying and then switch off the transmitter and it goes into RC failsafe which means RTL. If landing has not been detected it will want to fly up to clear trees and then come back and land :smile:.

3

Hi Julian, thanks for your reply. I’ve tested this on two separate Pixhawks, running both v1.7.3 and v1.8.2. I will continue to try to figure this issue out, but as it is potentially unsafe, I figured I’d bring it to your attention in parallel.

The problem occurs when the following steps are performed:

  1. The Pixhawk and Radio Controller are disconnected from power.
  2. The battery is connected to the Pixhawk.
  3. The arming button that came with the Pixhawk in pressed.
    Immediately upon the button being pressed, the motors start.

When the RC is turned on, the kill switch prevents the motors from turning. Upon the kill switch being activated the motors still turn without being armed. In fact, QGroundControl continues to see the drone as disarmed throughout the entire process.

The mixer used is as follows, with the objective of the four propellor outputs being set directly by offboard actuator commands from a companion computer (disconnected during the current tests):

M: 1
O: 10000 10000 0 -10000 10000
S: 0 0 10000 10000 0 -10000 10000

M: 1
O: 10000 10000 0 -10000 10000
S: 0 1 10000 10000 0 -10000 10000

M: 1
O: 10000 10000 0 -10000 10000
S: 0 2 10000 10000 0 -10000 10000

M: 1
O: 10000 10000 0 -10000 10000
S: 0 3 10000 10000 0 -10000 10000

Any insight you may have would be greatly appreciated!

4

Could it be that the last received signal from offboard just remains? Can you debug what is being set by offboard and what is being output by the driver (e.g. fmu.cpp or px4io.cpp)?