None of this guarantees the three wire connection to the motor will be in a particular order, so there is never a valid assumption regarding motor direction.
I can confirm that AM32 Configurator has no serious issue with Ardupilot 4.5.7 BL-HELI-Passthrough.
It always takes a second hit on the read button because the switch to passthrough is too slow in 4.5.7. IIRC 4.6 is faster.
Should mean, ESC 2-4 come up directly and 1 follows on second push of the button.
That has been my experience as well.
Just for the record, not to continue our dispute.
There was a great ESC in 2017, a VGOODRC Firefly ESC, that could be reversed literately by hand. And it was state of the art hardware as well. STM F051 which was later common for BLHELI32 ESCs.
OK, systematical approach.
With the T-Motor F7 FC:
Set Reversed Flag for Motors 2 and 3. Select DSHOT as protocol. Then write config.
With the PixHawk:
Then check if all ESCs are silent after the init beep.
Then check if all ESCs spin their respective motors via the motors page.
https://ardupilot.org/copter/docs/connect-escs-and-motors.html#checking-the-motor-numbering-with-the-mission-planner-motor-test
Find at least one motor that spins and use that channel to test all other motors by swapping the pins on the DuPont connector. This verifies the wiring.
I had to leave the workshop early today. Ill be working tomorrow for longer time on this. Thank you everyone for all the tips.
I am hoping now that the pixhawk is not damaged. ill keep you posted, thanks again.
So, i have managed something.
In the beginning i was checking which AUX port can pass through the signal to the ESC, until I managed that no motor was beeping. Now i tried to connect back to am32 config and I got what is shown in the image. So I am bit confused why now ESC#2 is not passing through, although when i test all motors, all of them can spin!
Note that this was managed without changing the parameters shown below, so i kept as shown below in my first connecting trial:
SERVO_BLH_BDMASK, 0
SERVO_BLH_MASK, 0
SERVO_BLH_OTYPE, 0
Then i changed this param SERVO_DSHOT_ESC from 1 to 3! and set the channels using the related params for servo_blh. One motor started to stupidly spinning once I power the avionics via battery. So i switched it back to 1.
The third trial was changing the params to include motor channels using the parameters above. At the moment the AUX output that I managed without beeping are: In AUX No. 3,4,5,6 (motor channel: 11,12,13,14)
SERVO11_FUNCTION,33
SERVO12_FUNCTION,34
SERVO13_FUNCTION,35
SERVO14_FUNCTION,36
And once I include the channels, one motor stops spinning when i use motor test.
So now I am not sure now what to do. Although all motors are spinning using the default params for esc telem:
SERVO_BLH_AUTO,1
SERVO_BLH_MASK,0
SERVO_BLH_OTYPE,0
yet, I can not pass through esc#2. And when I apply the changes that @menschel previously mentioned (for adding the channels) including SERVO_DSHOT_ESC to 3, then one motor start to beep for couple of seconds and then start spinning in a weird way.
I cannot find where I read it, some AM32 users mention they notice they need to press the Read twice, something like that.
you are right. In the beginning there was two esc’s would not pass through (ESC#1 and ESC#2) Then i clicked read back again and I only could manage ESC#1 to pass it through. I kept trying to click on read couple of times thinking that it might work but I never managed for ESC#2. So i am not sure why is that although all motors can rotate when i test them in Motor testing via mission planner.
or if someone has a schematic, one could diy.
I dont think i need to flash back again the firmware. All esc’s passed through when i used BetaFlight with Tmotor F7 controller. The issue is when I used pixhawk 6X and arducopter and not with the ESC
What i dont understand now why not all AUX ports are working despite setting up
SERVO_BLH_AUTO to 1
It seems this is another specialty of Copter. I typically run DSHOT ESCs on planes.
https://ardupilot.org/copter/docs/common-blheli32-passthru.html#pass-through-support
Set SERVO_BLH_AUTO to 1 to automatically enable pass-through on all outputs configured as motors.
I see that Motor 1 is reversed when connected through Pixhawk. Are you really sure that your wiring is correct?
Edit:
That results in PWM used, not DSHOT. Sure you can configure the ESC to listen to PWM instead.
Use an Arduino like described here.
You seem to be hung up a bit on this motor reversal thing, and I really don’t want to create a “dispute” as you say, but I think you are misunderstanding something.
The three phase wires that connect the motor to the ESC determine its “default” direction. They are not marked and can be connected in any order. As such, when the ESC provides speed control, the motor will spin in “a direction.” It’s not deterministic unless you are extremely savvy and do some analysis of the motor and its internal wire connections that is likely beyond the scope/capability (or necessity) of most users.
So, the process is to simply connect those wires and then run a motor test. If the motor spins in the correct direction, all is well, and we move on.
If not, we have several options:
- Flip-flop two wires by resoldering them to reverse the “default.” This is labor intensive and intrusive, as you are reapplying heat to the board.
- Reverse using passthrough and applying the reverse flag in the configurator.
- Use the RVMASK parameter
So it’s entirely logical that motor 1 might need reversing via the configurator (and motors 2 and 3 may not).
I hope this articulates my earlier point a bit clearer and helps explain why a manufacturer default that sets the reverse flags is largely inconsequential, as well as explaining what you are seeing in this user configuration.
Thanks for clarification Yuri. The discussion about Motor reversal is just a side show.
The real issue is that the Pixhawk 6X Outputs to the ESC do not work as expected.
I was expressing my suspicion that Channel 2 and 1 are somehow exchanged because the supposed reversed ESC#2 seems to turn up as ESC#1 if connected via ardupilot.
That is where I waive the flag because I have no clue about how the PixHawk 6X HW config works, especially with the F103 co-processor that seems to do parts of the output channels just like the PRUs on the TI AM3358 .
Maybe there is a regular Pixhawk6X user in the forum.
In most cases you do not need to set the servo_blh_otype parameter for Dshot. This is all that’s typically required:
MOT_PWM_TYPE, (Dshot protocol)
SERVO_BLH_AUTO,1
SERVO_DSHOT_ESC, (select type)
Setting the mask and Otype is superfluous.
This doesn’t actually matter much. If the ESC is not oriented with each corner corresponding to the numbering on the diagram, it’s pretty easy to just swap Motor1-4 around in the parameters to get the desired behavior such that the motor test properly corresponds to the lettering convention, A-D.
In a perfect world, the ESC would be oriented in such a way that we don’t have to do that, but space constraints often dictate a “non-standard” mounting solution.
@andyp1per is often the go-to dev for deeper hardware-level discussions.
I’d make a minor counterpoint that the reversal discussion is important because so many get it wrong, and this topic will exist long after the pressing issue at hand is solved.
IMHO the reversal problem is fundamentally unsolvable at autopilot level. Users need to read the documentation. (Does The Configurator handle motor spin direction check?)
Unless all manufacturers agree that wires are mounted in this particular way and connecting them to Standard ESC pad sequence always leads to CW prop rotation and all ESC manufacturers agree to use The Sequence in a way that is consistent with our or Betaflight’s motor directions somebody will get bitten.
I do not care about reversing the rotation for the motor. I do know that it is easily handled through switching the phase. Actually, thats why in my setup i have banana connectors (although this might introduce a risk for a mistake, which has happened to me!) however, i can understand that such option should exist because you can not always have a perfect design to reach to ESC and swap the phase.
Now, my main concern as a user followed the documentation and using reputable software is fairly having the ability to do things as they’re described. If there’s an error, we have such a nice community to ask about it and to know how it can be fixed. Yet no one had a direct answer why i can not successfully have my esc pass through as I was expecting? I managed to connect to three ESC’s why ESC#2 can not pass through when i use arducopter and pixhawk6X while when I use Tmotor F7 flight controller and Betaflight then all ESC’s are passing through?
if those params are unnecessary then why they exist? For a user that is trying to get deep understanding this introduces alot of unecessary confusion!
When these parameters shall be set and when is not?
I bought another ESC just to prevent doing this honestly-not because of its complexity (I have a solid experience with hardware) but because I am expecting that i get what I paid.
Any ideas for debugging and finding a solution are more than welcomed, and thank you everyone for your time and all ideas given to me.