Tried to install arducopter op a speedybee mini FC + 4 in 1 ESC, and Speedybee35 frame. Quad has been flying using Betaflight, and now I am trying to get Arducopter running (flying). Did have some problems with understanding servo motor and sequence setup, but I got the correct settings working (Test A frontright, Test B backleft Test B Frontleft etc). But on trying te quad the only result is the quad is flipped on its back.
Since FC and ESC are flipped 180˚ on the Speedybee35 there must bee a conflict on physical motor wiring and servo settings? or in mine understanding how to do the settings.
Any ideas??
This might be the cause - the only thing that is correct in that quote is motor A.
This diagram is the one you want to follow. Refactor the motor (output) numbers in favor of getting A, B, C, and D to work properly when testing in Mission Planner.
If the autopilot board’s arrow is pointed aft, you should set AHRS_ORIENTATION,4, as well.
Hi Yuri, by flipped 180 I should have said roll180 (upside down), and I do use ahrs_orientation 8, so that should be ok? But because the ESC is also upside down the motor 4 output is on position A, and speedybee35 frame has downfacing motors, quite complex all in all
Ok, use AHRS_ORIENTATION,8.
But that doesn’t change the diagram. It just makes the autopilot understand how to match said diagram (among other critical things). Downfacing motors don’t matter, either.
Motor A needs to be front right and CCW. Motor B needs to be back right and CW. And so on. Motor direction is viewed from a top view. Focus on the letters and rearrange the output numbers until the letters match direction and position during Mission Planner’s motor test.
Hi Yuri, I cannot reproduce the servo settings use for my testing, so I did it all over again.
The result is : I am unable to find a correct working combination.
I tested all 16 combinations, see uploaded file.
From the test I would expect that the 5th motor configuration (motor 4 2 3 1) should give the wanted result, but the spinning rusults are the same as the last testsetup (motor 4 3 2 1).
Second thing I noticed is that on the motor test page the displayed motor configuration is not in line with the servo setup…
As a former software developer and tester I would suggest Bug?
While concerning that you got the same results with differing configs, I seriously doubt a bug. The motor mixing libraries are quite mature and have not changed substantially in years. Quad configurations are the most common, so a bug would surely have cropped up by now.
I will admit that the diagrams are confusing. I’ve tried pretty hard to make them make more sense to new users, but that only goes so far…
Exactly what procedure are you following when you change the configuration? Are you moving wires? Just changing parameters? Which parameters are you changing? The chart you show doesn’t make much sense.
Also, what are the FRAME_CLASS and FRAME_TYPE parameters that you’re using?
Frame class and type Quad and X (1 1)
At first I did only basic configuration, and when I ended with problems on motor configuration, I started all over following Chris Rosners Youtube ending with the same problems.
I even did swap the ESC and motors from an other Quad, but that did not help eather.
If it is of any help, I can send my settings file?
All you need to do is run motor test and note which motors spin when pressing the A-D buttons and then refactor the servo output parameters to fix it if it’s wrong. Reverse motor directions as required either in the ESC firmware config or swap a coupe wires. That’s it. It is no more complicated than that.
Again, what exactly are you doing when you try a new configuration? Are you moving wires AND changing parameters? If you’re doing both, that’s the root cause of your issues.
When I started installing Arducopter I did not change anything on the drone, just a software change from a flying Betaflight drone.
After not geting Arducopter correct configured, even not after folowing Cris Rosser’s instructions (blanked Arducopter version), I did try to switch for an other (same) ESC’s (plus motors) from another flying (INAV) drone. But with the same incorrect behaviour as result.
I will (again) start over again with a blank install, and will be back to you.
Chris Rosser has some misinformation in his videos. We have asked for corrections, and he has been unresponsive (even going so far as removing video comments by ArduPilot developers). I’m not sure how accurate the section on configuring outputs is, but I hesitate to recommend it.
I’ve asked the same question twice. Do you need me to reword it to be more clear? I’m not sure how better to help.
Chris Rosser and The Painless man have both removed corrections to their collect clicks at all costs YT postings. Stick to Ardupilot titled videos.
I should note that The Painless man removed a comment that had a link to the correction and links may die in any case.
Hi Yuri,
Started all over again with setup, strait forward
frame type, initial parameters, AHRS, RC7 option(arming), accel and compass, serial ports for MSP and compass. ESC set on dshot300, no radio, flightmodes and failsave.
Servos setting to 4 3 2 1, resulting in reported sequense on motor test page 1 4 2 3, and spinning result 1 2 4 3…
Thanks for your sugestions
Nothing you have reported so far is a bug or incorrect behavior.
This never changes unless you change frame type or class (and at this point you shouldn’t bother trying that):
Test A spins the output wired to Motor1
Test B spins the output wired to Motor4
Test C spins the output wired to Motor2
Test D spins the output wired to Motor3
So, for example, if you have things configured as in your image, and when you run Test B, the back left motor spins, then you know that SERVO1 is your back left motor, and as such, it should be configured as Motor2, and so on.
1 Like
Another potential alternative is to change the FRAME_TYPE to 14, which is this one:
And set:
SERVO1,Motor1
SERVO2,Motor2
SERVO3,Motor3
SERVO4,Motor4
This might do it if I’m understanding your layout correctly. But your posts regarding which motor spins during which test are VERY confusing.
Changing the orientation of the autopilot is entirely unnecessary to fix the issue at hand and very likely counterproductive. We have already addressed the AHRS_ORIENTATION parameter.
1 Like
That’s what I meant, when I read back over my comment it looks like I meant physical change.
The AHRS_ORIENTATION parameter is required to properly orient the IMUs and internal compass (if present). It has ZERO effect on motor order/numbering.
2 Likes