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, when the throttle is engaged the drone barely takes off (no more that 10cm) and rapidly flies in a backward direction.
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 rapidly flew in a backward direction with about 10cm of left when the throttle was engaged.
If this looks familiar check the RC input for the pitch, in this case it was reversed. Now before every maiden I spin the motors up just slightly and rock the stick forward and back to se if the machine moves right. I have found that in most builds I have done the pitch is always reversed. No idea why but that’s usually the case for me. So I do that test and then make what ever change is needed. In the transmitter or in the config.
Another thing that makes me think that its something other that the RC is because it doesn’t even take off properly with the Ground Control Station. Another thing to note is that it worked perfectly with PX4 and I had a similar experience with my other home build for ArduPilot. The common denoninator seems to be ArduPilot.
Can a param file from PX4 be copied over to ArudPilot?
The motor order is most likely. Props on the wrong motors, motors spinning in the wrong directions. You have made an assumption between QGC and MIssion planner that is not valid.
I was told the motors should be ordered like this for mission planner and ArduPilot.
And I can confirm the motor sequence works perfectly and the motors spin A -> B -> C then D.
The props are also on the right way because as stated above I had the drone in the air with PX4. The drone wouldn’t be able to generate any form of loft if they weren’t on the right way as I experienced months ago.
The PX4 and Arducopter motor order and directions are identical for the Quad X configuration. So there should be no changes to which ESCs connect to which motor outputs on the flight controllers.
The numbering of motor outputs (SERVOx in params) and motor connectors 1,2,3,4… are different to the motor test in MissionPlanner as per the diagram you referenced.
For example in MissionPlanner if you were to click on the “Test motor C” button then motor 2 should spin.
Over time I have figured this out.
Motors are wired the same way with both PX4 and ArduPilot.
The difference is the test order in QGroundControl.
In PX4,
motor 1 = front right
motor 2 = back left
motor 3 = front left
motor 4 = back right
(same as wiring)
Whereas in ArduPilot,
motor 1 = front right
motor 2 = back right (wired as motor 4)
motor 3 = back left (wired as motor 2)
motor 4 = front left (wired as motor 3)
No idea why this is the case but my drone is now taking off as expected.
Thanks @dkemxr, as a novice I didn’t really understand you at first.
It still doesn’t make a whole lot of sense why they would test motors in a different order from how they were wired but nevermind I’ve got it working now.
Any suggestions on a topic I opened about an hour ago:
Actually this is a question worth understanding the answer to because it comes up often enough. The reason is regardless of the frame type and class the Motor test always is run in the same Front right motor then clockwise around the craft*. There are 13 Frame types and they will all run in this order if connected properly. X-frame same order as BetaFlightX for example even though the motor outputs are ordered differently. This logic is built into Mission Planner specifically to do this. It’s a useful feature not a troublesome bug once understood.
*co-axials of course have a bit different order but it still follows this logic.
