Feature request: BLHeli_32 ESC telemetry

[Hazakins]

BLHheli_32 ESC telemetry for OSD and logging.

[FPVZaphod]

...and possibly using the ESC Current Sensor as the main current sensor? Adding a static amount of mA permanently for static loads like FC and FPV Stuff, then we can get rid of the additional current sensor :-)

[Hazakins]

Installed a blheli32 esc this weekend. Would love to get temp and RPMs :)

[putimir]

Same here. I have an Airbot Ori32 4in1, so I'm stuck with no telemetry and no current readings :(

[jamesnabbott]

I'd love to see this feature too - ESC Current Sensor and RPM to start as OSD features, and as BLHeli_32 is developed and more features are added it would be great to see them too!

[jamesnabbott]

@FPVZaphod I think having both the battery current sensor and the ESC current sensor separate is important, a static value is not the best solution when it comes to systems with switchable vtx modules - an 800mw FPV system draws a lot more power over a long flight than a 200mw system!

[FPVZaphod]

Yeah, sure - but I think especially for very light builds it might be a big help. Copter ESCs used to be light, and if there is already a current sensor included, why not use it? I personally don't switch the TX power that often. A main current sensor is more accurate, without question. As long as it's calibrated well. But the ESC Sensor + a static load will be still way more exact than the virtual current sensor. I believe, the coding effort is quite small?

[cturn]

Ahh! Just went to enable esc telemetry and realized it wasn't implemented in iNav yet. After reading this request, I also noticed there is no Dshot protocol support ported over yet. I'm fairly certain the blheli32 telemetry uses the dshot special functions (dshot throttle values 0-50?) to relay the telem info to the FC. So the Dshot ESC protocol code would have to be ported over as a prerequisite to the esc telemetry code.

[digitalentity]

DSHOT is required for ESC telemetry. If somebody is going to have a crack at DSHOT - please, go ahead, but personally I think DSHOT will cause more harm than good on anything bigger than a miniquad.

[David-VG]

Are you sure @digitalentity? Dshot telemetry goes on a single wire to an empty UARTRX.

[stale[bot]]

This issue / pull request has been automatically marked as stale because it has not had any activity in 60 days. The resources of the INAV team are limited, and so we are asking for your help. This issue / pull request will be closed if no further activity occurs within two weeks.

[stale[bot]]

Automatically closing as inactive.

[xermalk]

This is something that would massively improve wiring in wings/planes and should really be considered for inav 2.1.

[Gmanzee]

I also agree this is a feature I would very much like to see added.

[davidngrc]

+1 for this

[teckel12]

I'd love to get this added only to stop the requests, as I'm just using the current sensor on the FC and never using DSHOT.

[David-VG]

I'd love to get this added only to stop the requests, as I'm just using the current sensor on the FC and never using DSHOT.

You can't read your RPMs or ESC temperature with your FC.

[digitalentity]

What's the practical use case for RPMs and ESC temperature besides "because I can"?

[David-VG]

What's the practical use case for RPMs and ESC temperature besides "because I can"?

Seriously you dont think the temperature of the first or second component to catch fire have some use?

[Gmanzee]

I would add, detecting RPM allows the flight controller to work out if you have lost propulsion and take some sort of failsafe action.

[digitalentity]

Seriously you dont think the temperature of the first or second component to catch fire have some use?

Choosing components with enough margin for rated parameters will nullify the need to monitor the temperature. Still, ESC telemetry comes naturally with DSHOT, so we'll have it even if it doesn't have much of a practical use.

[teckel12]

@David-VG Nor do I care about those values as neither have ever been an issue for me.

[teckel12]

@Gmanzee Sometimes the RPMs could be zero when flying, so I would hope that wouldn't trigger a failsafe. And I'm not sure if there could be any failsafe for a total motor loss. I've lost a motor and the other three motors could do nothing to recover.

[Gmanzee]

@teckel12 I was coming at this from the fixed wing perspective, you I now see clearly from the multi rotor angle. At a very basic level I was thinking if throttle is commanded and motor RPM = 0 then warn the user. Beyond that would certainly take some thought as how to safely handle your new glider. With fixed wing having one esc is usually all you have and having one with all these sensors built in can tidy up the wiring quite a bit.

[vavisimo]

+1 for FW/Plane , saving a lot of wiring

[Saxin]

@digitalentity Please consider adding this: Allows using readily available hardware for miniquads and keeping weight down (low wing loading). RPM can be used as measure of "actual thrust", I imagine it's possible to work out propulsion time constant given current and RPM.

[Gmanzee]

Other than the work and technicalities of implementing it I don't see a down side, granted I am asking others to do this work. What may help is it has already been done I think in most of the other firmwares, even Arduplane now. The ESCs also seem to be very nice bits of kit.

[teckel12]

@Saxin Still don't see how RPM or "actual thrust" would be useful, or even calculated. If you have the math, please share. Sounds like nothing but a marketing thing instead of actually being useful.

[teckel12]

@Gmanzee As DSHOT is dangerous, not all see it as "nice". It will eventually be added, when those who want the feature add it.

[Saxin]

@teckel12 Imagine jet engine, where the delay between throttle command to actual thrust can take quite long time (on RC jets it can be around 5-6 sec, from idle to WOT); electrical motors / props combinations will also exhibit a delay to some extent. Knowing and accounting for this delay can be very useful when navigating at speeds near stall speed, landing approach.

Calculation of thrust should be straight forward, erpm (blheli_32) + motor poles --> rpm + prop --> thrust measure. (Maybe my phrase of "actuall thrust" isn't he best, I meant measure of thrust)

Can you elaborate please -

As DSHOT is dangerous

[teckel12]

@Saxin DSHOT can be bad on a larger quads or fixed wings where there's longer wires which can be effected by noise from other devices (ESCs, runcam, VTx, etc). Because it's digital, it can (and does) cause total failure (IE crash). Not much good is an RPM measurement when the jet is in the lake.

[Gmanzee]

I'm not really that bothered about DSHOT, it's a waste of time on fixed wing anyway. The telemetry is the valuable asset for me. So for me at least there is a use case without DSHOT. I do believe you can command the telemetry data to stream continually without intervention, unfortunately can find the reference again to check if this still needs DSHOT. I'll report back when I find it.

[teckel12]

@Gmanzee How would RPM or current per ESC instead of total current be helpful? Sounds "cool" but useful?

[FPVZaphod]

ESC Current is useful to avoid the current sensor inside the flight contoller - not to have an additional one. It needs to be calibrated, heavy high current wired a contra productive against a flight controller damping. Beside saving weight, it also reduces magnetic influence of long wires. ESC temperature is without any discussion useful. RPM I see as "nice to have", but not really useful. Thrust is related to consumed power, not to RPM. Some other nice dShot-Features: Beacon Mode (saves the beeper), and for the tough ones: Reverse Thrust could be possible. Not sure if this is a nice idea ;-) Only down side: Most dShot-ESCs don't have a BEC, and just a few Fixed Wing Controllers have a BEC powerful enought to power Servos. So most likely it can save the Current Sensor in the Flight Controller, but you need to add a BEC. All over all I think there are more advantages than disadvantages. As long as PWM is still available :-)

[teckel12]

@FPVZaphod Maybe I just purchase parts that don't overpower other parts so temp/current per ESC just isn't useful at all to me. To me, it sounds like too much useless data, or worse, a crutch to use underpowered motors with overpowered ESCs, not to mention paired with a potentially dangerous communication protocol.

I've had really good luck with power distribution boards with current sensors and with the Omnibus F4 Pro. I have a few models with current sensors on the FC and have had zero issues.

But, I'm sure someone will eventually add ESC telemetry I just don't see the need so I'm not inspired to do it. Just trying to see the logic behind it and I have yet to see it.

[Gmanzee]

@teckel12 Current per ESC is of no consequence to me as I will only have one ESC in a fixed wing. Having an easy telemetry option on flight controllers without it onboard is of some consequence. As is the simplified wiring of having the battery go to the ESC and then to the motor, and nothing more.

I count every gram when assembling an aircraft and copper weighs a significant amount, these new BLHeli_32 ESCs utilize the latests FETs (genuine to) and also represent a very large current handling ability with respect to ESC weight. I despise dead weight, nothing gets a free ride. These ESCs represent a significant step in the right direction. Why wouldn't I want to use them, and squeeze everything out of them. To ignore them is standing still.

Temperature is a very valid measurement, an ESC that is comfortable is one environment isn't always comfortable in other environments. Ambient temperature can destroy an ESC. Launch also put strains on ESCs not seen in normal flight, it is very reasonable to optimize for this. No doubt the argument is pick a bigger ESC or improve you cooling, but are you going to rule of thumb this or science it. The latter requires data.

[Gmanzee]

When you land an aircraft that you are new to what do you do ? Do you check the temperature of things ? The battery the motor the ESC ?

[FPVZaphod]

@teckel12 : As mentioned before, a bigger ESC is way heavier. Modern Copter ESCs used to have Current- and Temperature Limiter. For the peak current of my T-Motor F80 in a Mini Race Wing a regular 40A fixed wing ESC is tight, better would be 60A. The 40A ESC is 44g. Currently I use a Kiss 32A Race ESC, 3.6 grams (!). This alone is reason enough to use a Copter ESC - the possibilities of dShot are just a nice addon. And - what do we loose, if PWM is still available as an option? The code exists, and it's very stable. I never lost a copter due to ESC control protocol failure, and the power density in a race copter is way higher than in a fixed wing. So interference is not an issue. Even my big X-Class Racer (4x2.4kw) with it's very long cables never had any problem. And yes, I still think it would not be bad to have an "ESC Overtemp" warning in the OSD in the case it happens. I never liked the thought to route several 10Amps through a tiny 36x36 Flight Controller PCB. Sounds more trustful to keep high current away from micro controllers and gyro sensors :-)

[teckel12]

@FPVZaphod The weight of the ESCs has nothing to do with the microcontroller being 32 bits. There are extremely light Blheli_S ESCs too. To compare to ESCs from 10 years ago is not a fair comparison.

[Saxin]

@teckel12 Take a look at those two pictures please, this alone is a good reason to implement and use current sensor on BL32 ESC which is on some is HAL affect based, I'll spare you the DVR (crash was at 120 km/h few meters above ground)

[FPVZaphod]

To boil it down a bit: What do we loose adding dShot? If some of us don't need it - fine. It's an Option, not a replacement. Beside the choice which current source should be used it won't affect anything in iNav. It's mostly a OSD thing, plus one or two new possible alarms. . Nothing to loose, a good win for some of us, no additional weight, no side effects. Code is available, tested and reliable. Why the whole discussion?

[teckel12]

@FPVZaphod Because seemingly no programmers are interested in these "features" and non-programmers can't live without them.

I'm sure someone will eventually add blheli_32 telemetry. I'd suggest those who are interested take a look at the code and port it. The code is already written, it only needs to be refractored for use in INAV.

[rb1205]

Frankly this stubbornness is baffling. It's like you're on a crusade to avoid dshot and esc telemetry to ever reach inav. The "I won't add it but others are free to" argument is kinda pointless if you try to shut down any discussion where dshot is ever mentioned.

Hell, the length of this discussion alone should be a reason to implement it, as it's quite obvious there's interest by the userbase.

[teckel12]

@rb1205 You're confusing stubbornness with the real issue, that no developers are running DSHOT nor BLHeli_32. How would you expect someone to develop and test it if they don't have the hardware? Maybe the reality of how programming works is not known to you? This is why I suggested that those who are interested in this feature look into refactoring the code to work with INAV.

BTW, the early stages of DSHOT have now been ported over to INAV. As far as I know, it has yet to be tested and telemetry is still not included.

Anyway, my guess is that developers are not too interested in DSHOT because of the problems it causes. Also, ESC telemetry isn't of interest as it serves no value to them. These are the reasons I'm not at all interested in DSHOT nor ESC telemetry and wouldn't spend my time porting over the code.

There are 3 realistic solutions here: 1) Wait for a developer to have interest in these technologies, buy the hardware, and write the code 1) Buy the hardware for a developer and have them write the code (this is how many FC targets are developed) 1) Write the code yourself

I hope this explains that it's not that there's not just some simple button a developer needs to press to make it work and they just refuse to press it out of spite. It requires hours of effort, the hardware, and hours of testing and re-coding. As this is a volunteer project, one shouldn't expect developers to spend many hours away from their family or doing something they'd rather do to write something that they have no interest in. It would be different if this was a paid program with paid programmers.

I would encourage that instead of just talking about it, demanding it, or whatever, to do something about it. Either step up and port the code yourself or buy the hardware for a developer who would be interested in porting the code. It's pointless to just talk about it, take action!

[Saxin]

@teckel12 , Tim - I have Airbot Typhoon32 V1.1 4in1 board with x1 motor out broken (yet still there are x3 fully functional), if you let me know where to send, I will send it first thing next week ?

[teckel12]

@Saxin Post you offer on the Slack general channel @ https://inavflight.slack.com/ to see if any developers are interested in taking this task on. With DSHOT also in the works, I feel confident that at least one developer will be interested.

[digitalentity]

@teckel12 @Saxin I'm not sure any developer will be interested in 4-in-1 ESC with only 3 motors working. If a developer is investing his/hers time into a feature it may be due to several reasons:

1. Just giving back to the community. Rare case. Altruists are quite rate.
2. Feature is useful to developers him/herself. In this case developer would expect to get a donation that is usable (flyable).
3. Fullfilling obligations to the community/sponsors/etc. In this case developer already has a decent compensation (hardware/money/etc) for investing his time into a feature.

For the record - my case is usually 2 or 3. I'm usually working on features myself or my sponsors see useful.

[Saxin]

Konstantin - do you want me to ask Airbot to send you some Blheli32 ESC ? if so let me know which and how many you need please ?

[digitalentity]

@Saxin I'm closely working with Airbot, no need to ask. I should have some BLHeli32 ESCs in my parts box somewhere. In case you didn't notice - I'm already working on #3879 😄

[digitalentity]

Blocked by #3879

[Saxin]

@digitalentity thanks, I did noticed and big thanks for that !!! Will happy test and provide feedback when ready for testing.