I’m troubleshooting a persistent issue with my Cube Orange running ArduPilot, and I could use some help. One arm’s motor consistently spins slower than the others, even after swapping both the ESC and the motor. The problem remains on that specific arm, which suggests something beyond just faulty hardware.
What I’ve Tried So Far:
Swapped ESCs→ Issue remains on the same arm, so not an ESC issue. Swapped Motors → The problem persists with a different motor, so not a motor issue. Checked Wiring → No loose or damaged connections between the flight controller, ESC, or motor. Motor Test in Mission Planner → All motors spin evenly to 2000 RPM during this test. ESC Calibration → Performed a full ESC calibration, but no change. Power Distribution Check → Verified that the ESC is getting power from the PDB. Flight Controller Settings → No unusual motor mappings or mix settings in Mission Planner.
Symptoms:
Only one arm has the issue, even after swapping components.
The motor behaves normally in the Motor Test (all reach 2000 RPM evenly).
However, during manual motor control, the affected motor spins noticeably slower than the others.
It doesn’t seem to be a mechanical issue (motor spins freely by hand).
No visible damage to wiring or connectors.
Logs show the flight controller is outputting commands, but the motor isn’t responding like the others.
Attached Files for Analysis:
I’ve uploaded the following to a Google Drive folder (link below) for reference: Parameter file – My current configuration settings. .BIN log file – A recorded log capturing the issue. Video – Showing the motor behavior during a throttle test.
Thought so. Your lengthy post and the results of that test are meaningless. This is one of the greatest misunderstandings about what closed loop control is posted about on the forum. If it performs properly in Motor Test move on with the configuration, calibration and tuning.
Just put the props on, hold carefully the copter and use stabilized mode, then incline the copter towards the “faulty” arm, I bet the “faulty” motor will spin up like crazy. This is dangerous.
I agree. It may be fun, but it’s dangerous. I don’t recommend anyone do a test like that. The motor test function will give the needed answers and keep drone parts & body parts out of harms way.
I appreciate the responses to this forum thread and the willingness to help. However, I want to preface this by saying that I have already reviewed multiple discussions on this exact issue. I can say with an “okay amount of confidence” that this is not a case of a closed-loop control mix-up.
With the limited assistance we’ve received, our team has spent over four hours methodically working through the suggested configurator. We meticulously entered all the parameters three separate times, experimented with various settings, and conducted extensive testing. Despite all of this, the motor is still exhibiting the same issue.
At this point, we have exhausted every possible troubleshooting step we can think of. I can elaborate on our trouble shooting as well. To provide more data for further analysis, I have added our .Tlog file to the same Google Drive folder linked earlier.
I implore anyone to take a closer look at our issue and help us resolve it. Before I hear another mention of an open-loop control issue, I’d appreciate any new insights that could lead to an actual solution. Now if it is said Closed-loop issue, and I’m the _-Hole, is there a resource I can use to assist with the methodic configurator, so it works properly?
Think of it this way: When you run the motors in stabilized mode the flight controller doesn’t know any better that you’re not intending to fly. So unless the flight controller IMU sees that the drone is sitting 0deg x and y, it is going to try to make some kind of correction (P-term). That will be one motor spinning faster than another. If nothing happens and the error persists, I-term will build and the controller will increase the speed of the motor.
The motor test function is in mission planner to address this. It will send commands to the motors without regard for the control loop. If all the motors react properly with the motor test function then there is nothing else to test. All the other ground tests may be fun or useful for dealing with a surplus of undergrads, but they don’t really prove much for the functionality of the drone.
Here is the link to my Google Drive folder from earlier: Google Drive Link
Newly added: A video from one of our flight test post-Methodic Configurator. Given the results, I think it’s fair to say this still qualifies as an “issue”. This flight test and all our “manual” tests from earlier have all been completed in Acro mode, as it seemed the stabilized mode was broken.
Wrong Motor Order or prop direction is usually the problem with that. And that most often comes with not understanding the order the motors run in using Motor Test. Not saying that’s what’s happening here but it typically is.