Support for bidirectional dshot telemetry

[spencerfolk]

To my knowledge (please, correct me if I'm wrong!), PX4 only supports ESC telemetry if the ESC has a dedicated telemetry wire, see the docs under the Telemetry tab. Each telemetry is wired up to a single UART on the FC and telemetry is gathered in a round-robin style scheduling. There are two problems with this setup:

1. Many ESCs do not have a dedicated telemetry pad.
2. The round-robin scheduling on a single UART means telemetry can only arrive (and be logged) so fast.

As a result, really the only useful features from ESC telemetry like RPM filtering only work on a limited number of setups and even then the telemetry might be too high latency to be useful for RPM filtering anyways. The solution to these issues already exists: bidirectional dshot telemetry, in which telemetry is passed through the signal pin. This alleviates (1) because a lot of ESCs, especially most newer ones, support dshot. It also eliminates (2) because telemetry is passed at each update on the ESC, which is much much faster than passing all telemetry onto a single UART.

The Betaflight community has already implemented bidirectional dshot telemetry specifically for use in their RPM filter which has seen very good performance.

Appreciate any thoughts on this. We would love to be able to get low latency RPM telemetry!

[dagar]

I'm definitely interested in mechanisms to get low latency RPM feedback. On PX4 I've already seen RPM filtering work extremely well on some vehicles using only the low rate dshot serial telemetry (~10 Hz).

I briefly looked into adding support for bidirectional dshot, but if I understand it correctly we'd need to move from using DMAR and a single DMA channel for all outputs to one DMA channel per motor. On most PX4 boards this would mean having to sacrifice DMA on some serial ports and/or SPI interfaces. It would be hard to do this in general, but it could be done on very specific setups.

Do you have a particular board in mind?

@Igor-Misic any thoughts on bidirectional dshot?

[spencerfolk]

How fast can dshot serial telemetry run? Could it run up to 100Hz or more? Beyond rpm filtering, I am interested in accurate rpm for estimation purposes. As a data point, what I found on Ardupilot forums is that serial telemetry was pretty much locked to below 50Hz and that bidirectional telemetry could run at the update rate on the ESCs.

We're running the Pixhawk 4 mini currently. I'm not familiar enough with how DMA works to comment on whether or not the change you suggested is feasible on our board.

[dagar]

I'm not sure about the max rate (depends on the ESC presumably), but if we get a good handle on the timing (telemetry delay, transport time, etc) couldn't we just estimate the RPM? We have delayed eRPM feedback and high rate commands that we're sending, should we try to do a little output predictor with corrections?

Ping me on slack if you're interested and we could hack something together quickly and then get real data from a vehicle.

[spiderkeys]

Having bi-dir dshot and RPM estimation/prediction would be pretty interesting to us. Since we are looking to break out all motor control via a separate CANnode board dedicated to motor control, we would have more DMA resources to allocate to DShot.

[Igor-Misic]

I briefly looked into adding support for bidirectional dshot, but if I understand it correctly we'd need to move from using DMAR and a single DMA channel for all outputs to one DMA channel per motor. On most PX4 boards this would mean having to sacrifice DMA on some serial ports and/or SPI interfaces. It would be hard to do this in general, but it could be done on very specific setups.

This is correct. Here are simplified steps explaining what needs to be done:

1. The peripheral driver shall be extended with one DMA per timer's channel
2. Add support for reversible DSHOT (ESC recognizes bidirectional dshot by reversed signal polarity)
3. Implement capability to reverse pin direction to capture GCR data
4. Decode RPM from GCR data

[li-haojia]

I'm also looking forward to this feature. With the higher frequency RPM data, we can also estimate the disturbance accurately, which is beneficial for maneuver trajectory tracking.

[dagar]

I'm also looking forward to this feature. With the higher frequency RPM data, we can also estimate the disturbance accurately, which is beneficial for maneuver trajectory tracking.

@mywisdomfly any particular board and setup you have in mind? I'd like to review a real (full) example from the perspective of the available DMA channels. My concern is having enough DMA for full bidirectional dshot (quad presumably), full serial DMA (rx/tx) to the companion computer, DMA for IMU on SPI, DMA for SD card, etc. Higher speed GPS (eg RTCM) and even newer RC protocols will also require DMA.

All that is to say I don't think we can have bidirectional dshot as an option everywhere, but maybe it's worth having 1 or 2 dedicated configurations.

[spencerfolk]

Glad to see there is more interest in this. I'd like to throw in Pixhawk mini as a dedicated configuration.

https://discuss.ardupilot.org/t/dma-on-a-pixhawk/15483

Looks like there are 16 DMA channels on the mini. This is way out of my wheelhouse, but I think it would be possible. How many DMA channels are currently in use?

[li-haojia]

Thanks for your reply @dagar. We have tested the Kakute H7 and CUAV V5+ with the Ardupilot firmware on a quadrotor. Both can support Bi-Dshot on the first 4 channels. We get the RPM data at about 333Hz on Kakute H7. And we also have the quad with CUAV Nora. (The hardware is similar to the CUAV X7. The Ardupilot also provides the Bi-Dshot option, but we haven't tested it.)

I suppose the hardware of Kakute H7 or CUAV Nora seems to guarantee the requirement. In my opinion, we can have just four pins to support the Bi-Dshot at first. They can be assigned on DMA1 through DMAMUX1.

By the way, I'm willing to do the test about this new feature. If you need any help, please let me know. I hope we can enjoy the Bi-Dshot on PX4. :)

PS: In the Kakute H7, the Ardupilot assigns the first four motor pins as the BI-Dshot. Here is its configuretion file.

PB0  TIM3_CH3 TIM3 PWM(1) GPIO(50) BIDIR
PB1  TIM3_CH4 TIM3 PWM(2) GPIO(51)
PB3  TIM2_CH2 TIM2 PWM(3) GPIO(52) BIDIR
PB10 TIM2_CH3 TIM2 PWM(4) GPIO(53) BIDIR

[li-haojia]

Shall we have a plan about the bi-dshot？ I'm willing to do the test.

[spencerfolk]

Any update on this? I see @julianoes was assigned to this.

[julianoes]

I made some progress. I estimate that I'll make a draft PR here in about 2 weeks.

[DEADLYBBS]

Is there a way to get bi-directional dshot for the kakute H7 at this time using the standard build? I do not know what other parameters have to be adjusted for this to work besides enabling dshot.

[junwoo091400]

@julianoes any progress?

[dagar]

It's still a bit early, but I've opened a pull request for those interested. #20749

[lnxraider]

Is bidirectional support enabled/working for PixHawk 6C?

[jgw365]

Is bidirectional support enabled/working for PixHawk 6C?

yes

[yzgarrard]

Hi, I'm using a PixHawk 6C with a hexarotor. Does the bidirectional support work for more than 4 motors?

[dakejahl]

I opened a PR to add support. For now the PR only supports 1 Timer and 4 channels and depends on DMA availability.
#23863

[teksingh220]

forget about pixhawk 6c, i am using pixhawk cube orange(not + version). even with this it is not working yet. They have it in their code but the hardware does not support this.

[julianoes]

@teksingh220 ok, I will try Cube Orange and Orange+ tomorrow, with #23863.

[teksingh220]

any update @julianoes ?

[julianoes]

@teksingh220 yes, see PR.