Copter rotate all axes when throttle is engaged


I just wanted to run this issue past the forum before submitting it as a bug on the ArduPilot GitHub page.

I have a homemade drone that was setup with the Durandal flight controller. A part list will be listed in the comments. (as part of this stage the motors were all tested on the bench to make sure they were being powered up in the right order)

At first I configured the autopilot with ArduPilot using QGroundControl. When testing the drone in the field the drone simply rotates on all axes when it is given any throttle. I also tried taking off with QGroundControl to rule out a radio controller related issue and got the same result - rotating on all axes.

To make sure the issue didn’t lie in the hardware, I switched out the firmware for PX4. The motors were tested again because they are ordered differently depending on the firmware. This time the drone took off smoothly and I was capable of controlling the drone with the radio controller and QGroundControl.

Following the sucess of the last test, I switched back to ArduPilot but this time I completed the configuration process on Mission Planner. Once again the motors were tested and when out in the field the drone rotated on all axes.

Is anyone else experiencing similar behaviour and is it worth opening a bug report from the ArduPilot repository?

Thanks in advance.


Part list as promised:

• 4 x
• 4 x
• Power management module
• 2 x (55mm)
• 4 x
• 2 x

I’m afraid I don’t have a link for the power management module but it seems to be a standard one from HolyBro.

Did you run the Motor Test in Mission Planner to assure proper order and direction?

@dkemxr, yes the motor test was run on both QGroundControl and Mission Planner.

My motor order is:
Motor 1: front right (anti-clockwise)
Motor 2: back left (anti-clockwise)
Motor 3: front left (clockwise)
Motor 4: back right (clockwise)

This order was then reflected by the order in which the ESCs were plugged into the back of the Durandal flight controller.


Sorry if this belabors the point but many get this wrong. In Mission Planner the sequence the test is run in is A-D (not motor number order) . If this is correct post your parameter file.

@dkemxr, this may well be my issue then.
My motors are ordered 1-4.
i.e. A = 1, B = 2, C = 3 and D = 4.
The same as expected if tested in QGC.

Please find attached the parameter file.
mpQuad.param (18.2 KB)

Yea, that’s not going to work. Connect the Front Right Motor (1) to the Durandal Main out 1, 2 (back left) to 2 and so on.
Then if it’s correct when you run the Motor Test Function in Mission Planner:
A will run the front right motor
B back right
C back left
D front left.
IOW Clockwise around the craft from the front right.
Note the direction also.

The Motor Test is the definitive test for order and direction. If that isn’t right then either it’s not connected correctly or the Frame Class is wrong.

Thanks @dkemxr, I’ll give this a go just now.

@dkemxr, I gave that a go and it didn’t work.
The motor test was fine and when run in sequence they went:
front right (A), back right (B), back left ( C ) then front left (D).

However, when I tried taking off with the props on it was flying rapidly in a backward direction with very little loft.

I doubt its any different but here’s the parameter file, a snippet of the frame setting and a few pictures of my drone.

Any ideas?

In Mission Planner HUD is it showing level when the is quad level? Did you do an accelerometer calibration? When you pitch and roll it is it correct in the HUD? On the Radio calibration screen are all the indicators moving with the correct stick input. It’s typical that Pitch has to be reversed in the radio.

The Mission Planner HUD is showing level when level.
Accelerometer calibration has been done.
Pitch/Roll is displaying correctly on the Mission Planner HUD.

Radio calibration is also ok and the indicators are moving with the correct stick input.

Well I guess post a link to the last flight log where it was flying backwards. I would say that you will need to set the initial tuning parameters for a craft of that size as defaults probbaly won’t work well. But it should at least get off the ground and hover with what you have.

The autopilot when flying was QGC and there seems to be a bug in the QGC code stopping me from viewing the log.
I’ll connect it to mission planner tomorrrow and create a new log.

I’ll be in touch soon.

If you are going to stick with Ardupilot use Mission Planner for configuration and calibration. You can use QGC after that as a flight ground station.

I tried that but Mission Planner is not ready to be released on the device (its only the beta version) I use when out flying. I tried it but it failed to connect to my Telem radio.

Do you have any other suggestion without having access to the logs?

Ah, the Android version right. It’s getting there. I would find a Windows PC.

Back to the pitch stick. Does the Pitch Green bar go down when you move the Tx stick up?

Nothing else to suggest, what you describe almost always results from what I suggested earlier but your test results sound correct.


Ok, I’ve run a test using the RC with the radio connected to my Windows PC.
I have downloaded the flight logs and they can be found here:

To rule out a radio calibration issue I have also create a video of the radio calibration screen on MP whilst toggling the sticks. (I should note if not already obvious the RC is in the default mode 2 with the throttle on the left) One thing to note is that the drone behaves the same way when controlled via the autopilot using QGC.
Video is here:

Thanks in advance for your help.

Invert the Pitch channel (2) in the Transmitter as I noted. I’ll take a look at the log.

@dkemxr, thanks for this. How do I go about inverting the pitch channel and how would this help because the drone does the same thing when controlled by the autopilot?

I’m not familiar with a Flysky Radio but on an OpenTx radio I just invert the output on Chan 2. On your Radio it looks like Menu>Functions>Reverse, Select Chan 2 then toggle from Normal to Reverse. Then test again in Mission Planner.