Dshot telemetry #7264
Dshot telemetry #7264
Conversation
|
@joelucid: This does look interesting. Good work! A couple of remarks:
|
|
@mikeller, here's the preliminary spec: Commands 32-35 and 42-47 have been added in the context of this feature. I currently use commands 32 and 35. I've closely worked with Steffen Skaug, the author of blheli, blheli_s and blheli32, in designing this feature. We have both tested this (Dshot 300, Dshot 600, Dshot 1200 and Proshot 1000) on four different ESCs and three flight controllers. Steffen will be ready with a release of blheli32 when we are. I've reached out to Felix @ KISS, but have not heard back, yet. I believe once we have support from blheli32 and KISS we can consider the feature well supported in the ESC community. Important to adoption will be the availability of killer features using dshot telemetry. I plan to make available a new gyro/dterm filter soon (it's not xmas yet 😄), which will have such significant latency and noise suppression advantages over our current filters that it might be considered such a killer feature. An interesting question is Blheli_s. While the current blheli32 implementation uses DMA it's conceivable that this could be implemented using interrupts on those ESCs. Steffen has no current plans of addressing the Blheli_s installed base though. But given the open source nature of Blheli_s anybody can try to add this. The feature is run time configurable: set dshot_telemetry=on/off enables or disables it. Good point regarding the N channel motor signals. N channels cannot be used as input for timer capture and are thus not supported. I was able to fix this for the NOX board by simply using a different timer on the same pin, but clearly there may be boards where this will not work. |
|
Thanks @joelucid. A couple of points regarding the specification:
What does @ronlix think of this suggestion? I guess the solution for configurations with N timers on motor pins will be to force Only discovered this now, but how much effort is required to make this work with burst DMA? I think this will be a crucial part of getting this into Betaflight. Burst DMA has become a vital part of most newer flight controller designs, in terms of allowing designs that do not have DMA conflicts, and will become even more important when we look into using DMA to read gyro values. |
|
Hi, Wouldnt it be simpler to rise the telemetry Baud to 1 or 2 MHz and add a dshot rpm request command? Or use dshot commands to give the escs ids to have Them answer delayed (based on the ids) so you can get all rpms with one request. I think making the Signal Line bidirectional will make it much less robust. Regards Felix |
That's a valid point. You could probably even do this based on the 'telemetry request' bit in the Dshot frame, and define a 'fast RPM telemetry' mode where the ESC sent a short RPM only telemetry frame for every request, and a full telemetry frame at a fixed time interval. This would also get us around the current limitations on N channel motor timers and burst DMA - going back to the nightmarish situation we had with DMA conflicts before the advent of burst DMA isn't an option in my opinion. |
|
yes 42-47 are request telemetry value commands. Given the bandwidth constraints of the dshot line we can't use the telemetry bit with the same semantics as the traditional esc telemetry because we can't send more than one value back. Certainly not everything as is done in response to the telemetry bit. Secondly the telemetry bit is already used for requesting traditional esc telemetry. We considered adding additional bits to the dshot frame to request motor signal line telemetry. However erpm is likely the only item one wants to retrieve in real time and adding overhead to each frame for telemetry requests that happen only rarely did not seem like a good trade-off. These dshot telemetry request commands give the FC flexibility not only in how often a given telemetry type is retrieved, but also when. For example one may issue them when the current dshot motor value has not changed much. The only one implemented in BF for now with this PR is erpm telemetry which I consider by far the most significant for us. That said I do think the other telemetry items can be useful to avoid the extra wiring of serial telemetry. We could flag these extra commands as experimental. The thought behind ERPM period telemetry was to enable low powered ESCs to report a value that can be converted on the FC to ERPM. This could be essential in enabling blheli_s to support this feature. On the other hand we didn't want to force 4 divisions on the FC with blheli32 escs to support low powered FCs (like SilverWare). Burst dma should be doable once the response timing is strictly defined. That's needed since captured values are collected at update of the timer which may occur before the esc has started responding. |
|
The Basic Idea on the extra telemetry line was to Not need a bidirectional Line on throttle Line. To have fresh rpm telemety Data Something Like mikeller Said would work fine.. This would Work with all FCS and would make no extra dma Stress on both sides |
Yeah, that'd be another way to do it if the serial esc telemetry line is wired and can support that speed. Might cause compatibility problems due to filtering assuming the old baud rate though. |
|
I tested 1mhz for some time. Workes flawless :) |
I tested bidirectional dshot - also flawless ;) |
|
But seriously: what's your concern about a bidirectional throttle line? It makes it so simple: already wired on all escs, no extra pins required on the FC which might not be there on 20mm boards etc. |
Agreed there - considering all of the other telemetry data isn't really useful for flight performance enhancements, does not need super low latency, and is widely supported with 'back channel telemetry', I would even go as far as to say that real time ERPM feedback is the only thing we actually need in this way. This simplification will also make it possible to remove the need for the telemetry request commands (42 - 47), and have the ESC send a telemetry frame back after every received frame - there is no downside to this, and the data point will always be ERPM.
Assigning most of the remaining Dshot command space on 'experimental' features sounds like a bad idea - this will probably make it impossible to add non-experimental features in the future because there are no more Dshot commands available.
Ok. I see this point. But I think there is a logical mistake in there - being able to choose which one of ERPM / ERPM period to use does not enable the flight controller to determine which one will be supported by the ESCs it is communicating with, and once it knows what the ESC sends it can use that without having to configure it on the ESC. I think one of the following approaches would be better:
|
I'm cautious anticipating what will be needed in the future, but this is what we need to start, yes.
I'm pretty excited about using the motor signal line bidirectionally in general. Just makes the wiring so easy and doesn't require another uart on the FC. Can also potentially support older escs that don't yet have the backchannel. But I understand the concern of dshot command space pollution. We can certainly start with erpm only and figure out more scalable approaches to bidirectional comms if/as we actually start developing additional telemetry needs.
Good point. We envisioned this to be configured on the FC but auto-config would be nicer. I'd hate to lose one of the 12 bits though (crc also used on telemetry). Info frame when disarmed would be a useful approach, I agree. |
with unidirection you can add simple signal amplifier and or different filters. also you dont have to swich between transmitter and receiver settings (GPIO, Timer and DMA) im not sure what steffen is feeling here, but on ESC's you have time critical events that you need to take care of as soon as possible.. the sooner the better (the more efficient and smooth it can run the motor) adding time critical events makes this worse.. one thought, it is not much more work to emulate serial logic with the timers and DMA's, then doing Dshot. if its needed to go to a bidirectional communication, i think this would be a good way as it will "only" add more work for the FC's which have the bigger MCUs anyway ;) i dont know how good the results of your new gyro filter that includes RPMs are, and if it would be worth the work ;) but maybe it is... |
Agreed there - we might find that there are other data points on the ESC that can be used to improve the flight performance when sent back to the flight controller with low latency - but we don't know yet what they are, but most likely they are not the current high latency telemetry data points.
I don't quite follow there - 2 wire per ESC vs. 3, or 5 wires for a 4-in-one vs. 6. Does not seem a huge improvement in the big picture. As for ESCs without a telemetry pad, 'dedicated line' telemetry was always seen as something of an 'extra feature' that is nice to have, but does not provide much value beyond that, so users who don't want this will buy ESCs / flight controllers without telemetry pads. Low latency ERPM is different there, as this has the promise to add significant value in terms of flight performance, beyond just 'getting the data', so 'not interested in it' isn't really a thing.
Yeah, on second thought 'can calculate ERPM' is a constant for any given ESC, so having the flight controller detect this once on startup is the right thing to do. Making it configurable on the ESC doesn't make sense - if the ESC is fast enough to calculate it it should - any computation that can be farmed out from the flight controller will free up CPU time for other things. |
Well decide for yourself - this is an image of gyro, roll pids and motor traces using very narrow (q=5) notch filters on the first three motor harmonics, no other filtering on gyro and a 150hz lpf on the dterm. Total software latency of the dterm might be 2.7ms, on gyro maybe 0.5ms. Yet the traces are completely clean.
|
I do think we should have the two commands that we use now so that the esc only sends when it has been asked to. So "continuous rpm telemetry on" and "continuous rpm telemetry off". I don't want to go much further discussing telemetry for other items over dshot. Live telemetry for flight control relevant esc data has the potential to revolutionize quads - see image above. That's why I wanted it. Let's push the frontiers of flight control, not get slowed down by providing convenience telemetry features. |
|
Well, the throttle signals have a Higher priority then any Feedback. But If you go that way now, please define what Bits in which Order should be sent. So i can add it to the kiss ESC Code. If we find better ways later Things can be changed :) |
Thanks Felix! I think we'll be using commands 32 and 34 from this spec, to switch online rpm reporting on and off. Looks like we've tabled any additional telemetry for now since it's already provided on the serial telemetry line and in order to keep this simple. Responses are sent as normal dshot frame included CRC. The lsb scale for the values is in the spec. I fully agree - we can change this if we find problems. What I find most exciting for now is to get a sense for what we can do with rpm telemetry on the FC. I'm already using it for more effective filtering (#7271). But there are a lot of other ideas, like running pids for motor rpm on the FC to improve motor response. |
I disagree there - one core part of this change is an amendment of the Dshot protocol. As it is, this has deep implications on users of the protocol, and maintainers of software implementing it - if this is changed after being published, it will leave users of the pre-change version in a lurch to find firmware for their hardware that supports the change, and maintainers of firmware in a struggle to maintain support for legacy and new versions. For these reasons, the protocol design should get utmost care to be done right the first time round. So, I think what we should do now is to reduce the proposed protocol changes to what is actually needed, and leave options open for future extensions, which will come at a time when we have learned more on how this works out in practice: @sskaug, @ronlix: What are your thoughts on this. (Addition of making this a permanent change instead of a temporary one is based on the fact that the use case for this does not contain any cases of temporary change, plus the fact that this will save the bacon in case individual ESCs reset due to brown out or other problems.) While we are talking Dshot protocol, what are your thoughts on scraping These don't seem to be used, and using a single Dshot command for on/off isn't feasible, as there is no payload to encode on/off. |
|
@mikeller you misread my message. I said exactly what you repeated now. My openness to change was in regard to using the signal lines for telemetry. If that does cause the issues Felix worries about we can make changes. I said we want just the two commands. I wonder though - are we talking about the same protocol? Which has four commands to switch on LED’s? The command crowding angst seems to be a new phenomenon. |
|
@joelucid: Ok, I did misread then - you were not very specific about what would be changed later. ;-) The LED control commands were unilaterally added by BLHeli_32, and then accepted by Betaflight, which probably was not a good move in hindsight. But they go a long way towards showing that the command space in Dshot is very limited, and does not allow for powerful commands with parameters, and as such has to be used wisely. |
|
@mikeller I don’t think its a good idea to make this setting persistent since it would mean that after a FC change or reconfiguration the ESCs might end up sending telemetry against a line actively driven by the FC. As I said two commands: one to switch rpm telemetry on, one to switch it off for the existing session. |
Valid point, accepted. This will then probably require adding of detection / graceful handling of situations where some or all of the ESCs stop sending ERPM telemetry back in mid-flight. Then how about this: |
|
@mikeller yeah that’s how these commands were designed from the beginning and that’s how I still think they make the most sense. Hopefully we can move on to the more meaty discussions of what to do with rpm telemetry soon. |
|
@joelucid: Happy to do so - from the perspective of having to maintain the code going forward, protocols, and their implications for backwards compatibility, are the 'meaty' part that will make our lives easy or hard in years to come. |
|
@mikeller, my professional experience is to allow flexibility in apis and protocols in beta but nail them down once released. In the early phases it’s often more important to explore the core issues than fixing the protocols. But YMMV. |
|
@joelucid: Fair enough. I assumed that this was targeting inclusion in the upcoming 4.0 release. Considering the expected turnaround time for getting protocol changes released to beta testers by BLHeli_32 and KISS (and potentially BLHeli_S), if you feel that we need a longer beta period then we should schedule this for inclusion in 4.1. |
joelucid
force-pushed
the
dshot_telemetry
branch
from
14d2f15 to
816da6c
Compare
|
@mikeller, Rebased and sqashed |
|
A test version of blheli32 is now available: https://www.rcgroups.com/forums/showpost.php?p=40842949&postcount=3112 |
I'm still looking at RPM telemetry over serial telemetry link. @ronlix Did you evaluate the max speed of the tlm wire? |
|
Hi, in my tests im at 2mhz ATM. it seems to work relaiable eaven with only the internal pullups (4x ESC 1xFC) will let you know if i got something good :) and if you have ideas, im open. |
|
Can i chime in?? Looking at your code, the only validation you do on the incoming frames is the CRC. The CRC is only 4 bits, which means erroneous data will still get through. I think you should also be validating incoming frames using the frame length. You know what the expected frame, bit or nibble lengths are going to be.. so reject anything that falls outside the above thresholds. Otherwise, If we extend Proshot we can utilise another nibble (or two) of data and generate a 8 or 12bit CRC. |
|
@joelucid @ronlix As this pull request had been merged a while ago and there was a lot of discussion about the pro/cons... what is the current state with KISS/FETtec escs ? I tried to enable bidirectional dshot for a FETtec 4in1 but all motors won't be recognized anymore (no tones for motors). Using single telemetry wire and ESC_SENSOR works. Just asking because I'd like to enable RPM filter (which does not seem to be available for setups with dedicated telemetry wire(s)). |
|
Some time has passed, 4.2. is out. Any word from the KISS/FETtech team about bidir dshot? Once got used to RPM filtering, you don't want to miss it. I switched the 4in1 esc for experimental use, xrotor 40a mini 4in1 with a fettech 4in1 (i just love the slow starting up of the motors), but noise (Dshot300) is horrible compared to bidir dshot. |
|
RPM filtering is available since quite some time and does bring great benefits. Sad that KISS/Fettec escs silently became irrelevant in this whole discussion (which I think initially made great progress). Is there any chance to kind of reactivate this discussion with @joelucid @ronlix @mikeller ? As far as I understood (or not) RPM filtering is based on embedded eRPM information on the signal line (correct?). What would it mean implementation-wise to have eRPM via Onewire/telemetry channel as a second option available (effectively chosen by the pilot aka the person who wired the FC to the ESCs) ? |
|
@rauar: All for helping KISS/Fettec with the implementation of Dshot RPM feedback. Using ESC telemetry for RPM feedback was looked into, but with the very slow update rate of ~20 Hz this is not feasible in a way that will actually improve flight performance. |
|
Hi, as said before some time, the way for fettec ESCs to get the telemetry / eRPM feedback fast enough will be onewire. AFAIK there are ppl having working BF versions, they are just not complete for now. so there should be coming something soon :) regards Felix |
|
Hi @ronlix. Not sure what makes you think that the ~20 Hz update frequency per ESC that ESC telemetry allows will be fast enough - our tests have clearly shown that this is way too slow for this to work. If you are planning to change the ESC telemetry protocol, please make sure you get an agreement with @sskaug before you propose the change, so that the changeover can be done in a coordinated fashion that includes BLHeli_32. |
|
Hi @mikeller 1x signal wire (one HW uart half duplex pin.. mostly TX) the only down side is that the ESCs dont get their throttle command absolutly at the same time, as it is a chain of bytes that carrys the signal values. but we are talking abaut a couple of µs ;) regards Felix |
|
@ronlix: Not sure of the value of wasting valuable flash space for adding yet another proprietary protocol. I think it is better if we stay with the established and widely used Dshot for now and use the flash space to add features that actually give users something they don't already have. Feel free to add support for Dshot RPM feedback to your ESCs to bring their performance up to par with other ESCs when running Betaflight. |
|
hi, @mikeller well its as proprietary as Dshot is / was ;) we gave out all source since some time... and will put some documented examples on github soon. regards felix |
|
@ronlix: It is not as simple as that - if we add this, there will be at least two more proprietary ESC protocols that are out there with users that will ask for them to be added, with potentially more to come, as each manufacturer will want to add their own - adding proprietary protocols whenever a manufacturer comes up with one is really not the way that this should be going. |
|
Matek is still working on serialshot. Are there any statistics about which protocols are being used? |
|
@haslinghuis: Dshot is in the lead, but still ~15% of users using an analogue protocol (last 30 days):
|
This is a first version of dshot_telemetry which reads rpm telemetry from blheli32 escs on the dshot signal line after each dshot command. As a result the FC will be fully aware of the real time rpm of all motors, which opens up many new improvements like better filtering and motor control.
The feature does not support burst DMA and is not implemented on the HAL drivers. It's guarded by USE_DSHOT_TELEMETRY which needs to be set to enable it. If the firmware does support it the cli option dshot_telemetry needs to be set on to activate it.
The feature requires a custom blheli32 firmware which isn't yet released. This firmware implements a couple of new dshot commands which are used to manage the feature. I'm currently trying to get in touch with Felix of KISS to ensure compatibility with KISS ESCs now and going forward.
Clearly this isn't yet ready for integration, but I wanted to get the ball rolling so we can ensure safe delivery into 4.0. I would appreciate any help from devs more familiar with the driver internals to double check what I've done here.