**Feature Request** on pixracer Dshot and OSD

[LanceFung]

Hi I'm Lance from Yuneec:

Feature Request on pixracer

the Racer Must support the new ESC protocol multishot, Dshot600 and Dshot1200 ( BLheli 32
firmware)

If you can support OSD like how beta flight does ( rssi and voltage is very important for us )

Able to config through OSD is a very nice feature, and able to connect smartaudio from TBS unify
pro to change channel and output also come really handy.

Issues :

250 size race drone is totally out of date , Most of the Race size are 210 ( full size ) , 140 ( mini) , 100 ( micro)

( Accord to what I see in betaflight ) gyro update in up to 32KHz, depends on what esc you can support it 8kHz with blhelis and 32kHz with blheli32

[dagar]

Could you recommend an ESC to use for development?

Faster gyro updates have been discussed in detail and planned, but there's no firm timeline for implementation.

It probably makes sense to add more generic quad airframe configurations (different frame sizes) even if the actual configuration is minimal.

@MaEtUgR @rolandash @nkhoit FYI

[dagar]

@LanceFung have you configured PX4 on racers in those sizes (210, 140, 100, etc).
If so let's look at safe default parameters for each size class and create airframes.

[dagar]

As for the OSD it would be helpful to create another issue to document exactly what's needed, but again a developer is going to need that specific hardware.

[LanceFung]

Currently, most needed :
For ESC Blhelis Dshot 600 & multishot protocol: FlyColor Raptor BLS Pro BLHeli-S 30A ESC (2-4S DShot)

In the Future there everyone will move to
For ESC Blheli32 Dshot 1200/Proshot 1000 :
https://www.undergroundfpv.com/collections/escs/products/32bit-6s-30a-esc

[LanceFung]

I have put one on the 210 not 140 yet. ( but it could be a good side project :) ) did not tune the PID perfect yet.

Current mounting pixracer 30.5mm X 30.5mm hole with only fit. size 210-140.
size 110 will need to redesign the board.

[MaEtUgR]

@LanceFung Good to hear from you again, interesting requests for racing with PX4!
I personally support making PX4 support racing because there is big potential. It could get the racing FC software which has all the extra features of a "smart drone".

Here is the test build with the Pixracer board I did for this: https://docs.px4.io/en/frames_multicopter/qav_r_5_kiss_esc_racer.html

My point of view:

• Dshot would be useful, I use it on my racer but I'm not 100% sure how much difference it makes to OneShot142. Would need to test the difference (with KISS FC you can switch very easily)
• For OSD I have no idea what it takes because I never used it before. I use FrSky telemetry to my Taranis remote and the taranis speaking to me on switch flip which is supported by PX4: https://docs.px4.io/en/peripherals/frsky_telemetry.html
• Still most racers I still see have 6 inch props -> 250mm frame, 5 inch props -> ~210mm or 4 inch props -> ~180mm but I'm not sure what you're refering to with the very small quads. I think it will not happen very soon that the pixracer like it is right now will be produced in a much smaller size simply because there is a lot of hardware on that board to support all the features.
• The gyro update rate was in discussion a lot before. One thing is clear: we need a faster rate control loop (at least 1kHz) but how fast is effectively needed is up for discussion. 32kHz control loop sounds like total overkill to me but @priseborough told us before that reading out the sensor faster and filtering in software can allow to get rid of some aliasing effect caused by high frequency vibrations and I see potential there. Maybe we can even learn something from betaflight how to do this in practice...
• About the ESCs selection I agree BLHeli with DShot support is likely always the better choice. I personally use KISS ESCs which also support DShot until now but I'm keen to switch because they are closed source and pretty impractical to solder like you can see in my build tutorial linked above. Thanks for the links.

What do you think @potaito ? From speaking with you I infer you have some racer experience.

[potaito]

@MaEtUgR I don't have much to add to what's already been said, except for:

Dshot would be useful, I use it on my racer but I'm not 100% sure how much difference it makes to OneShot142. Would need to test the difference (with KISS FC you can switch very easily)

Dshot Is definitely the way to go. Lower latency, digital communication, and as far as I know there are still some unused bits in the protocol that could be used for motor feedback in the future (RPM and whatnot).

For OSD I have no idea what it takes because I never used it before. I use FrSky telemetry to my Taranis remote and the taranis speaking to me on switch flip which is supported by PX4: https://docs.px4.io/en/peripherals/frsky_telemetry.html

In Betaflight you can open the OSD menu and navigate it with specific control stick combinations. Similar how you can configure arming and disarming with control stick combinations in cleanflight/betaflight/px4. So I guess this would be easy to implement. As for the OSD functionality itself, I am not in the loop of what px4 currently is capable of.

Still most racers I still see have 6 inch props -> 250mm frame, 5 inch props -> ~210mm or 4 inch props -> ~180mm but I'm not sure what you're refering to with the very small quads. I think it will not happen very soon that the pixracer like it is right now will be produced in a much smaller size simply because there is a lot of hardware on that board to support all the features.

Can confirm. Most of the pilots in the last Swiss Drone Nationals a few months ago were flying 5 and 6 inch props. This has not changed at all compared to 2016.

The gyro update rate was in discussion a lot before. One thing is clear: we need a faster rate control loop (at least 1kHz) but how fast is effectively needed is up for discussion. 32kHz control loop sounds like total overkill to me but @priseborough told us before that reading out the sensor faster and filtering in software can allow to get rid of some aliasing effect caused by high frequency vibrations and I see potential there. Maybe we can even learn something from betaflight how to do this in practice...

Many pilots will tell you they feel the quad is more responsive with higher rates. True or not, it will be hard to convince them, that your 1khz loop performs the same, even if it does...

[MaEtUgR]

Here's a well known fpv guy doing a blind test dshot vs oneshot and he can't tell the difference: https://www.youtube.com/watch?v=0hDi-NRZq9Y I know it's not academic and people will look for the buzz word anyways but it's probably not the most important feature for end user performance. In fact according to him the ESCs you use or rather the Firmware version for him because he uses KISS ESCs makes the real noticable difference.

[dk7xe]

The advantages of Dshot (as described by Felix on rcgroups) compared to the most used analog signals like PWM as also oneshot125 or 42 are:

• no signal jitter.. if the FC sends 1375 the ESC will receive 1375.

• high resolution (2048steps).

• no oscillator drift (nomore calibrateing ESC's).

• more robust against spikes.

• safer as every singnal has a CRC (cyclic redundancy check).

• possibility to set motor spin direction via SW.

BLheli and KISS ESC are supporting this "new" protocol already.
-> https://www.rcgroups.com/forums/showthread.php?t=2756129
Since KISS ESC have some nice features and are available with high Amp reading they are of interest for bigger multikopter as well.

[potaito]

I did some more research regarding this topic and honestly, I am not too convinced with DSHOT. Here's why: You still need one UART Tx per ESC on the flight controller. Some boards don't even have that, others have four of these and you could not fly in configurations with more than four motors. I presume DSHOT had to be implemented like that if they wanted to remain backwards-compatible to PWM and all other analogue protocols, which obviously need one channel per ESC. On top of that I am not sure how DSHOT envisions motor feedback to be incorporated. As things are standing now, each motor would again require its own UART channel on the flight controller, resulting in 4x2 UART channels, i.e. 4x(RX+TX) for four motors. DSHOT is in my eyes only the first step towards digital motor control and still a compromise.

What might make much more sense, is to have all ESCs connected on the same UART port of the flight controller. This means, that ESC commands for all ESCs are sent to every ESC. Knowing its own id or number, every ESC knows what command to listen to and which ones to ignore. Motor feedback needs a bit more caution, as only one ESC should be sending feedback at any time. Otherwise there would be cross-talk. Some ESC protocols with proprietary firmware, for instance the Qualcomm and Yuneec ESCs work exactly that way, so it's definitely possible.

I believe at one point we (the whole flying community, not just px4 community) will have to make a move and use a more efficient ESC protocol that is not backwards-compatible. What would be really nice is to see open source ESC firmware as part of px4, including a new and open digital protocol. What do you guys think?

By the way, we do already have a driver in px4 for the Intel Aero that uses a digital protocol: https://github.com/PX4/Firmware/tree/master/src/drivers/tap_esc
But as far as I know, the ESC firmware of the Aero is not open-source, not sure if there even exist binaries for the public. Probably not.

[bkueng]

@potaito nice write-up! I'm not sure if you already know, but something like you describe already exists and is even integrated to PX4: Sapog ESC's which use UAVCAN (a bus which is by design better suited to attach multiple devices): https://github.com/PX4/sapog. There's also open reference HW: https://github.com/PX4/Hardware/tree/master/sapog_reference_hardware. I'm not sure if it's THE solution, but it's definitely worth looking into.

[potaito]

@bkueng No I have not seen this before, thanks! Looks promising..

[dk7xe]

@bkueng thank you for pointing that out. But for many users in the hobby domain UAVCAN is no issue because of the price. 79$ of a Sapog ESC compared to a 20$ BL_Heli or 25$ KISS ESC makes a difference.
I fully agree that UAVCAN is the better choice for (commercial) multiple ESC UAV designs. But leaving out the nice developments of the hobby market i disagree. From a user experience the simple advantage of no need to do ESC calibration makes a difference.
I have seen many fails of users simply not doing ESC calibration correct. With Dshot such kind of issue can be avoided. And not only for racers. There are a lot of ESC supporting DSHOT that are capable of 6S and >30A current.

[LorenzMeier]

Sounds like we need to work harder on a low cost UAVCAN option.

[dk7xe]

@LorenzMeier i guess so. Or at least the UAV CAN enabled ESC's need to become cheaper. Whatever comes first ;) But i think that what was meant with your statement. Would be happy to support.

[LorenzMeier]

Let's go back to the original topic of @LanceFung:

We do support all of the critical interfaces already - so rather than ticking arbitrary boxes it would be good to get to real measurements. That means I'd love to see sensor-to-output latency specs that are relevant and alike optimisations.

What is the best current racing ESC out there?

[LanceFung]

Hi Lorenz

From my user experience Hobbywing XRotor ESC and newer DYS ESCs are soild to me
T-motor as usually used by lots of Racer but I never use it myself.

BLheli 32 : ( support Dhsot 1200 )
---Hobby wing XRotor 30A BLHeli_32
---DYS ARIA 35A BLHeli_32
---TMOTOR F30A BLHeli_32

BLheli S : ( support Dshot 600)
---Hobby wing XRotor 30A Dshot
---DYS XSD30A-V2
---T MOTOR F30A
---Fly color Raptor BLS pro Dshot

My honest opinion is to get the system to be as compatible in the current available market.

FYI : All Dshot ESC can be directly connected to the PWM output on the fly-control board.
I agree with the future if we solder all signal to one UART which make life easy, but changing
user habit is another story

[dk7xe]

@LorenzMeier i would use the products from the inventor of Dshot @ronlix
KISS ESC24 v1 - supports Dshot 600
KISS ESC32 - supports Dshot 2400

i support the statement of @LanceFung. Dshot output to ESC should be via the PWM output pins.
Telemetry feedback from ESC's may be connected to one UART RX pin.

[potaito]

@LanceFung do you know for a fact, that this could be done with the PWM output? Is this how Betaflight and the like implemented it?

As far as I know, PWM outputs usually use GPIO pins, right? Even with the slowest DSHOT150 the required data rate would be 153600 bits / second. This means that in the worst case the GPIOs would have to be switched from high to low or vice versa within 1e6 / 153600 = 3.26 microseconds.

Do you think these timings can be accomplished with GPIOs and without UART? I have only little experience, but 3.26 microseconds seems very short.

[LorenzMeier]

The PX4 drivers can operate at faster speeds than required for these protocols and do so in hardware, not requiring GPIOs.

[MaEtUgR]

@potaito PPM and also the faster analog protocols like oneshot can be done with PWM hardware as more clever alternative to software GPIO bit banging...

---

I digged a bit deeper on how DSHOT is usually done and actually they use DMA channels and timers to directly control a GPIO pin without the CPU load. Here is a collection of everything I found:

The micro-controllers are simply using the direct memory access, and timer capability within micro-controllers to generate the necessary signals on a motor pin so as to minimise the CPU utilisation.

https://blck.mn/2016/11/dshot-the-new-kid-on-the-block/

The STM32 MCUs are able to emulate a parallel synchronous communication through the
GPIO interface, using the embedded DMA IP. The frame transmitted consists of up to 16
bits of data and a synchronous data clock. The transmission requires usage of timers to
generate the data clock and to control the transmission duration (timeout, number of data
sent).

http://www.st.com/content/ccc/resource/technical/document/application_note/7a/88/df/e3/d3/36/40/29/DM00169730.pdf/files/DM00169730.pdf/jcr:content/translations/en.DM00169730.pdf

Related code:
https://github.com/betaflight/betaflight/blob/master/src/main/drivers/pwm_output_dshot.c#L59

Some technical discussion trying to reproduce on arduino:
https://www.esp32.com/viewtopic.php?t=2954

Feature request for DSHOT on ardupilot:
ArduPilot/ardupilot#5300 (comment)
Maybe we can cooperate with them for the implementation or is there incompatibility.

---

Meanwhile I think it's worth considering support of dshot...
As far as I understand it's not really based directly on UART hardware and that's probably also why the dshot baudrates do not match any conventional UART baudrate.

[xkam1x]

I have been reading several forums about ESC protocol and it seems that digital bi-directional communication is a way to go.

The options are then i2c, CAN, UART and Dshot.
with i2c we have 400kbit/s.
CAN 1Mbit/s.
UART 1Mbit/s (depends on hardware).
Dshot 600kbit/s,

Since CAN needs licensing, it is probably best to avoid; otherwise cost of ESC will be higher and its adaptation will be slow.
i2c maybe a possible solution but I fear data integrity as SCL and SDA need to be synced.
UART is probably best as it does not require licensing and generally found on all micro controllers.
Dshot uses DMA which maybe difficult to program.

Personally I would like to see UART based ESC's and this how it can be done:
Hardware:

1. Invert UART signals.
2. Connect TX and RX togather.
3. Use 2 data lines, one with default pull high and other with default pull low to get differential signals (requires extra hardware but better reliability).
4. Share the UART bus with all ESC's.

Data packets could be sent like:
Sync1,Sync2,Motor 1 MSB,Motor 1 LSB,Motor 2 MSB,Motor 2 LSB,Motor 3 MSB,Motor 3 LSB,Motor 4 MSB,Motor 4 LSB,Data Request,Checksum

If whole message checksum has more overhead then we could use 11 bits for throttle value and 5 bits for checksum giving us 2048 levels and still keeping within 2 bytes.

Data request could contain first 4 bits as ESC ID and last 4 bits for data request. This allows for 15 motors and 15 different data packet structs, assuming last byte 0x00 means response not requested and it could be used to perform load balancing.

As soon as one message is sent, one of the ESC would respond with data packet requested and FC would process before requesting another.

This type of system does require ESC ID's to be set before hand but it is a onetime requirement.
Also we could change the Sync1 and Sync2 to indicate that the packet is throttle values or config parameters.

What do you think?

[limhyon]

Hi,
is there any update on this?
I can provide full development unit for this task.

https://www.uvify.com/draco-drone/

The drone we made is fully compatible with PX4 now.

[dk7xe]

The adupilot folks are making progress on dshot --> ArduPilot/ardupilot#5300 When will PX4 follow?

[LorenzMeier]

Independent of the actual merit of DShot I would be interested to push for top-of-the-line racing performance and I've pinged Hyon via email to arrange hardware.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

Closing as stale.

[LorenzMeier]

Dshot is now implemented on the first boards.

[Seeelefant]

Cool :-) , however besides Dshot there was also the request for "smartaudio from TBS unify
pro to change channel and output also come really handy.....". Was there any progress on this topic?

[MaEtUgR]

Update: Dshot is now supported with #12854