Motor spinning when not armed

Hello all,

I’ve constructed a tripcopter, and I’m using a control board with the PX4 pro firmware.

I’ve set everything up in qgroundcontrol as per instructions, and then I tried to arm the tricopter. Plugging in the battery, the main LED blinks blue slowly (GPS not locked - fine, I don’t have a GPS on it) and the safety button flashes about once a second. I then hold down the safety button for one second, and hear a short tune (three notes). At this point, the rear motor starts to spin, quite fast! Thankfully, I’m paranoid and hadn’t attached the props, so no harm done. (If I then proceed to hold my throttle closed and rudder right, the tricopter arms, and I can hear the motor tones vary as I move the sticks around, which seems right.) But I can’t have the motor doing this each time I press the safety button, it’ll flip the copter over and probably injure me.

I tried doing manual ESC calibration on each motor - this didn’t change anything.

I tried swapping the rear motor with another motor - the ‘new’ rear motor now spins fast, so it’s not the motor itself.

I then swapped the signal cables plugged into channels 4 (rear throttle) and 2 (front left throttle) on the pixhawk, and that made the front left motor spin when not armed.

So I think I can say: it’s not the motor or the ESC, but PX4 is actually instructing the rear motor to spin when the copter isn’t armed.

My questions are the following:

  1. How do I track this down and fix it so I can arm and fly my copter?

  2. I thought it was impossible for the motors to turn until both arming steps (press the button; hold the throttle stick down right) were complete, even if there is a problem with my throttle settings. Have I uncovered a safety bug, or am I misunderstanding?

I’d be very grateful for any help you can provide.

HW Fault could cause this. Maybe one of your Output channels is shorted ie. to an AUX Port? AFAIK AUX goes to 1500 right after arming when no other signal present. What FC and where do you connect?

Hello Andreas,

Thanks for the suggestion. My FC is an HKPilot32. The offending channel is “MAIN OUT 4”. These pins are physically far from the AUX ports, and MAIN OUT 1 and 2 (which are behaving normally) are between 4 and the AUX ports. Here’s a link to an image of the layout of the FC: http://www.hobbyking.com/hobbyking/store/catalog/55561.jpg

I found a post from earlier in the year from someone having the exact same issue over at DIYDrones (with Y-, I’m Y+): http://diydrones.com/forum/topics/px4-qgroundcontrol-and-tri-copter-configuration
This makes me think it’s a problem with the firmware in a tricopter configuration.

I’m probably going to switch to the ardupilot firmware and see if that fixes things, but I’d like to help get to the bottom of this. Is there anyway I can log out the signals that the controller thinks it’s sending to the main out ports? That way we could find out if there is a short, or if the PX4 really is trying to run the rear motor.

Thanks again!

The .px4log file on the SD card will show the actuator signals, and QGC can show them live using the Analyze widget.

I’m reviving this thread as I’ve got the same issue, and would be interested to better understand the causes.
After I push the safety button and before I arm (with lever bottom right) the motors I have in AUX turn.
With the command pwm info I can see both the actual pwm and the settings and it shows that the motors in PWM_AUX CH1 (output1) and CH2 are set to the MIN value instead of the DISARMED value !
However those in PWM_MAIN (output0) are correctly set to DISARMED value.

nsh> pwm info
device: /dev/pwm_output0
channel 1: 900 us (alternative rate: 400 Hz failsafe: 900, disarmed: 900 us, min: 1000 us, max: 1950 us, trim:  0.00)
channel 2: 900 us (alternative rate: 400 Hz failsafe: 900, disarmed: 900 us, min: 1000 us, max: 1950 us, trim:  0.00)
channel 3: 900 us (alternative rate: 400 Hz failsafe: 900, disarmed: 900 us, min: 1000 us, max: 1950 us, trim:  0.00)
channel 4: 900 us (alternative rate: 400 Hz failsafe: 900, disarmed: 900 us, min: 1000 us, max: 1950 us, trim:  0.00)
nsh> pwm info -d /dev/pwm_output1
device: /dev/pwm_output1
channel 1: 1100 us (alternative rate: 50 Hz failsafe: 0, disarmed: 900 us, min: 1100 us, max: 2000 us, trim:  0.00)
channel 2: 1103 us (alternative rate: 50 Hz failsafe: 0, disarmed: 900 us, min: 1100 us, max: 2000 us, trim:  0.00)

Could this be related to the mixer for PWM_AUX using a Passthru signal ?

Mixer file below:

Inputs to the yaw motor mixers:
Yaw: Group 0 (Flight Control ) channel 2 (yaw) 
Throttle : Group 3 (RC PassThru) channel 5 (Aux1).

Left Motor is connected to channel 1
M: 2
O:      10000  10000      0 -10000  10000
S: 0 2  10000  10000      0 -10000  10000
S: 3 5      0  20000 -10000 -10000  10000

Right Motor is connected to channel 2
M: 2
O:      10000  10000      0 -10000  10000
S: 0 2  -10000  -10000      0 -10000  10000
S: 3 5      0  20000 -10000 -10000  10000

Would be grateful for any clues
Thx

Or maybe PX4 assumes that all motors are directly controlled by the main throttle signal and thus only disarms the channels that are controlled by it?

I guess this allows one to check for servo operation (flaps, rudder, etc) before arming?

But what if there are extra motors that need to be controlled by signals other than throttle?

You would need to mark these channels in the mixer code like we do for throttle.

Thanks,
I’ve looked at mixer_simple.cpp to see if I could figure out what you meant by marking the channels, but can’t see it.
Could you point me to an example section of code please?

Is this the section of code I should be looking at?
https://github.com/PX4/Firmware/blob/master/src/modules/px4iofirmware/mixer.cpp#L459#L479

In case someone else runs into the same issue. In 1.9.2 on my pixhawk 4 I also had the problem of the propeller of my fixed-wing spinning up a few seconds after boot up. This happened most of the times, but i could not reproduce in which cases exactly.
I noticed that PWM_DISARMED was set to 1000 (default 900). When resetting it to the default, the issue seems to be resolved