The configuration process presents the user with specific and well defined motor order for all supported configurations in one portion of the document, with pictures, which we all naturally gravitate to, then changes to a completely different standard later in the same page, almost in fine print.
I agree that, if you carefully read the documentation it does define a clear algorithm for translating from one ordering to the other ordering, but why risk confusion by use by not maintaining one standard?
IMO, the ClockwiseX parameter setting just makes matters worse and again violates the least surprise rule. If someone picks up a quad that has been configured with ClockwiseX (or I do 6 months down the road) and it acts differently from the standard, documented way just because of some number that has been changed somewhere in the hundreds of other numbers on the parameter page, I think that’s a problem.
We are using inbuilt compass with no GPS module or telemetry radio . We are planning to build a drone without gps and telemetry radio. We cannot use external compass now. Any other solution?
Create a post in the Arducopter thread and suggest just that because that order is in firmware. There is an order that Arducopter codes for and there is a methodology that Ground Station software uses. If you have BLHeli_32 ESC you can use BLHeli Suite for motor test. That’s typically what I do when I configure ESC’s as I’m right there already. But for those using MP, and as The Mandalorian says, “This is The Way”
In my case, RC values jumping all over the place and keeping one rotor on the ground was caused by the way I had routed the wires from the FC to the receiver. It would act normal until the motors spun up. Moving the receiver and rerouting the wires was the answer for me.
