Pixhawk 4 holybro Arducopter 3.6.9 -> 4.0.1rc3, no control over two motors in an X8 with DSHOT

It flies! That’s the conclusion to end this thread. I’ve tested the 4.0.2-rc3 (or master, the first version for which the DShot banner messages work). In more detail:

-4 motors (the “upper” ones on X8) work in the DShot mode, with telemetry
-4 bottom motors work in PWM mode, the calibration is possible with BLHeli_32 (setup for DShot but fall back to PWM)
-the flight is maybe even smoother than previously. In particular the takeoff, not easy with this copter (long legs, CoG high)
-in telemetry, motors 3 and 2 have in average more RPM and more current - I don’t know how reliable this data are?
-the banner message works not correctly, is incomplete. It shows:

RCOut: PWM:1-8 DS300:9-12

and it should be

RCOut: PWM:1-8 DS300:9-12 PWM: 13-16

-4 DShots are functional and I can’t see how the promised 6 could be obtained for Pixhawk 4? I have identical ESCs and the setup which has been tested very carefully. PX4 promises only 4 DShots for this FC, maybe not without a reason?

-I hope that something will be done with enabling DShot for 8 motors. Right now, I don’t see any point in buing high end FCs - what you gain with better sensors you lose with less precise motor control. And not even a DShot hexacopter with Durandal? It’s a joke! How about using the CAPx inputs/outputs?

I attach the logs, screenshots of current and RPM for motors 1-4, and a bonus, a 360x180 pano made during this flight. Of course in non-optimal conditions, in sunny weather during winter (non-existent this year in Eastern Europe) the sun is too low on the horizon. But I’m very happy that my copter is again airworthy :slight_smile:

http://46.41.148.74/pan/psv-test/example/zakole.html

46.41.148.74/20-02-07_11-27-20.bin

1 Like

That’s great you found a solution that works Maciej! Quite novel I would say but creative :grinning: Thaks for sharing the pan shot, it’s cool!

Are you sure that is correct for the CUAV v5+? Reason I ask is that I have this flight controller in a HEX using Dshot on aux1-6 in Dshot150 mode. And it flies perfectly and I get telemetry from all 6 ESCs

EDIT

I reread and saw where you your PX4 only supports 4 vs AC 6… Nevermind

@ThePara,

OK, txs. I’m definitely not aware of the difference between DShot Telemetry and ESC telemetry. I only see BL Heli ESC telemetry mentioned on our DShot wiki page so I’ll have to chat with some of the other devs about this.

Re the difference in the onboard log’s RCOU ranges when using OneShot vs DShot. I’ve created an issue for it here so we will discuss it at the next dev call. I think the difference stems from the implementations. Regular PWM outputs and OneShot are basically the same thing except that OneShot uses a smaller range. DShot is a completely different protocol though as are ToshibaCAN, PiccoloCAN, KDECan, etc. These protocols are implemented almost as translations of the RegularPWM. I.e. the RegularPWM output continues but then AP takes the outputs and converts them to whatever protocol the ESC uses.

My personal view is that it would make support more difficult if we logged the “native” range output to the ESCs depending upon the protocol. An extreme example is ToshibaCAN which outputs in the range of 6300 to 32000. Trying to make sense of this in a log would be hard. To be consistent I think we should consider artificially logging OneShot in the 1000 ~ 2000 range as well but I suspect other devs will disagree… we shall see.

@maciek252,

Great that you’ve got it working and thanks for testing out “RCOut:”. As far as I know, besides me, you’re the first one to try it. I suspect the RCOut message is correct and we’ve got an issue in our hwdef file for the Pixhawk4. Our wiki page for the Pixhawk4 is inconsistent about whether the board supports 14 or 16pwm outputs (should be corrected soon) which may be related.

Thanks again for the report.

ArduPilot does not yet implement bi-directional DShot

not quite. You still need a mechanism to tell each ESC when it is safe to send telemetry. The method ArduPilot supports is to set the telemetry bit in DShot command packets. Some ESCs support an alternative method where a particular throttle level is sent which allows for non-DShot protocols to trigger telemetry send. ArduPilot does not yet support those non-DShot mechanisms

because the logging happens at a level above the translation to the 11 bit DShot values. We could change this, although there isn’t much advantage

The Holybro ESCs that I am using allow me to send telemetry at a 10hz rate regardless of being asked for it. This is a setting in the blheli32 firmware. I needed to enable this to get telemetry on my octo which is using oneshot

nice!
how do you prevent multiple ESCs sending at the same time and causing corruption on the UART?

Ummm. 🤷. I figured they would just fight it out. Lol

I don’t know honestly, but I do get different results for each esc so they might arbitrate?

I do think every now and then I get a collision, as a rpm line spikes super high. But I get maybe one of those every 20 mins of flight. If interested I can share a log

This is what I am referring to:

OK so here is an interesting question… And I do not want to drag up the “are we sending dshot or not” conversation… But…

If telemetry is being asked for when using dshot, and we don’t get any back, is dshot really being used?

Thanks for this clarification. Kept me from trying it myself.

@maciek252,

@tridge and I investigated this over the weekend and found two issues:

  • there is a hardware limitation that means the Pixhawk4 can only support 4 DShot outputs. In case it matters, the limitation is on the DMA (Direct memory access) channels which is required for high speed output. It seems that the DMA channel we would need to use to support 6 (or perhaps 8) dshot outputs is already being used to communicate with the IOMCU (the 2ndary processor on Pixhawk boards that sends outputs to the MAIN OUT channels).
  • there is a bug in the “RCOut” code (or more accurately a bug in some code that the “RCOut” relies on). We’ve got a fix here that will probably go out in Copter-4.0.3.

Anyway, the short answer is that it won’t be possible to get DShot working on more than 4 channels on a Pixhawk4. We’ve updated the wiki page for the Pixhawk4 to say this so hopefully this will be easier for the next person.

Thanks again for the testing and reporting back.

Great! Thanks, a negative result is better than uncertainty. I’ll test the RCOut code when it will be available.

But how about CAPx outputs? Maybe can IOMCU remain disabled and instead some PWM outputs be available via CAPx? For example, I need just 3 PWM in my copter, for the landing gear and triggering the photos. Would this require hardware modifications?

And what is the situation with Holybro Durandal? Also only 5 DShot outputs? Isn’t this already time to say goodbye to IOMCU? Anyway, many thanks for investigating, when looking at the other threads one can easily notice that ArduPilot users are interested in DShot!

Another interesting takeaway from this thread is that you can easily check if DShot is being enabled by connecting an ESC to the working outputs. The sound sequence for DShot is longer than for PWM.

So, Pixhawk 4 Mini should be able to run more DShot outputs, since it lacks the IOMCU.
Question is: how many ? :slight_smile:

@ThePara, My guess is the PixhawkMini can handle 6 DShot outputs but this is a guess.

hi dude can you see my problem too here is a link to it

So weirdly my new KakuteF7Mini reports 5 DShot outputs and 1 PWM - I don’t care because I am only using 4, but it seemed a little odd to me.

Based on the documentation, you can use Dshot on all outputs except 7,8

The Pixhawk4-Mini supports up to 11 PWM outputs. All 11 outputs support all normal PWM output formats. All outputs except numbers 7 and 8 support DShot.

Not only are you cross posting you are posting in the Copter 4.0 thread with an APM on 3.2 question. It doesn’t belong here and you will get answers in your previous post

1 Like

@andyp1per,

Maybe try asking it for 6 (by switching it to a hexacopter) and see if it really does give 6. I really don’t know about this area but perhaps it’s caused by the output groups although normally those are in pairs or sets of 4.

I’m happy that at least the “RCOut” reporting (in master) gives somewhat independent reporting of the outputs so we can more easily see problems.