instead of using a standard Heli govenor ESC, we can use a BLHeli32 ESC.
This will lead us to a true Motor-RPM reading over telemetry, which enables us to:
Do the governor directly in the Ardupilot code including better tuning options.
In reply to: Helicopter Rotor Speed Governor
BlHeli32 ESCs are available up to 65A (Holybro) and pretty common up to 45A (TMotor, Holybro etc.) In the light of X-Class etc. I would expect a lot more high Current ESCs in the future.
65A should be enough for everything up to 500 sized helis, which could be ideal for getting started with TradHeli?
This could cut the costs per ESC in half on every build.
For Copter: BlHeli is the standard and therefore switching to Heli would be effortless.
It’s not motor rpm that I’m really after, I really need to know what the rotor speed is in order to judge start up and shutdown. The other issue with using BL Heli’s ESC‘s is that it drives everybody to one ESC which I don’t think is realistic. The solution I was looking for was trying to use something that’s already resident on the controller. The other idea would be to use a cheap Hall effect sensor that you can get for less than $10.
I’m not sure what you mean by this. I’m running Castle Creation ESCs and I’m pretty happy with the options I have and how well it holds rotort speed. Now there are probably things that could be improved like how to set up for practice autorotations but I’m pretty sure that can all be done now with the current software.
@ChrisOlson recently implemented a rotor speed governor which I was primarily designed for internal combustion engines but can be used for electric motors. Most of the responses we have received on this implementation have been positive and it is driven from RPM 1 sensor. So right now RPM 1 is connected to a hall effect sensor in Chris’ case but could be modified to receive other hardware inputs. I would think it would be possible to link it to the telemetry motor RPM from BLHeli. this would certainly work in governing the motor and therefore the rotor but doesn’t give us the complete picture on the state of the rotor which is important.
Now this is an interested concept. I’m not sure tradheli could implement it the same way because the rotors don’t stop when the motor stops. So this would have to be based on rotor speed using some rotor speed sensor.
The governor implementation I have will actually work measuring engine rpm as well as rotor rpm. But using engine or electric motor rpm is far from ideal. You could have the main or autorotation clutch start to slip in flight and the governor would happily keep the engine at governed speed while the helicopter crashes. The pilot would have no indication there is a problem until the helicopter started falling out of the sky.
Another situation is autorotations. You can shut a helicopter’s engine off in flight and it continues to fly just fine. To bail out of an autorotation the governor needs to know how fast the rotor is going to determine how to re-engage, engine rpm does not provide the required information.
Not all helicopters are geared the same. So if you use engine rpm now you have to do gearing calculations in the code to determine what RPPM is.
Where electric helicopters are concerned, helicopter-specific ESC’s have a soft start, and most already have built-in governor function. And typical amp range is 120 on the low end (500-550 class) to 200+ (700-800 class). Most of them over 160A are forced-air fan cooled. The BLHeli ESC’s are not designed for this as they are a multi-rotor ESC.
The governor code in ArduPilot is designed primarily for piston and turbine engines since these do not come with a governor, and adding an external governor is a quite expensive piece of kit. It will work fine for smaller electric helicopters, however, no matter what ESC it uses. So assuming a BLHeli ESC could handle the rigors of helicopter operation, the current governor already works with the addition of a $7-10 Align hall effect sensor and magnet on the autorotation gear.
Software that runs electric governor is really a lot different than the one that drives piston/turbine. Best way to have electric governor working good is using the rpm feedback from esc where provided.
Slipping oneways are not common on modern elicopters (most of them are oversized).
For autorotation recover there are some techiniques to have it working without knowing rotor rpm.
This is where all electric heli ESC’s get the rpm information - from the EMF feedback from the inactive phase in the motor. It is used by the built-in governor and typically the setup software will have entries for gearing information to set headspeed.
It is more common on heavily loaded UAV helicopters than with 3D. Under 3D operation the speeds are very high, lots of power, low torque load on the autorotation clutch. On UAV’s the helicopter can approach 1.5 lbs/ft^2 disc loading at slower speed with extreme torque load on the clutch. Even using the wrong lubricant can cause a slipping clutch on a big UAV heli that weighs 40-50 lbs, and it is a regular maintenance item during scheduled inspections.
For big pistons it is quite challenging to get a smooth autorotation recovery if full-down autos are not being done. The rotating mass in the engine, drivetrain and rotor is quite significant. If rotor speed has been lost during autorotation or in the flare and a recovery is attempted without going full-down, the torque must be controlled or it will jerk the tail 180 degrees. It has to come back on fast, but it has to be smooth to maintain yaw control of the helicopter.
The governor knowing what the rotor speed is is the key to determining how it handles the throttle to bring it back to rated speed without torque jerking it. I made a last-minute change to the governor code to handle this properly so the pilot can simply slam the collective into the climb range and the governor will handle accelerating the mass without LTE. I’ve yet to see an electric ESC governor that handles this properly if rotor speed is lost and power re-engaged. They will jerk the heli in a torque turn. I decided ArduPilot’s governor can do better than that.
Notice on the last fast recovery where I let rotor speed bleed off. Then I simply slam the collective into the climb range, the heli lifts off, and the governor handles smoothly finishing the acceleration to rated speed and re-engages in the air. And the tail holds perfect thru the whole affair.
Believe me, i know more about the subject than i would like. Having designed and produced thousands of helis and countless firmware releases on our flybarless system i understand and know each problem bit by bit.
What i wrote comes from 20 years experience in the heli and flybarless business.
That’s great! However, what @bnsgeyer was referring to in using rotor rpm is that we currently use two timers to determine when the heli is ready to fly. One of those timers is redundant and I think a hold-over from the old auto-takeoff method. Although it does also come into play for engaging certain modes using Altitude Hold too.
In the code there has always been a method used to estimate rotor speed based on Setpoint, which is really, really crude. And I recently added a method using an actual rpm sensor. So the rpm sensor is currently only for the governor. But we can use it to replace this old “estimated” rotor speed method. Bill is looking at a method to use when there is no rotor speed sensor available. And since rotor speed is independent of engine/motor speed and only somewhat loosely related, ESC rpm output tells us nothing that we need to know to accomplish the end goal. We need to know rotor speed. It is the RRPM, and what percentage of RRPM we are at, that determines whether or not the heli flies. In the absence of a rotor speed sensor Bill needs to make it work for all drive types, both electric and combustion engine, where no speed sensor is used.
If somebody wants to spend the time to get one particular type of ESC’s rpm telemetry output into the RPM Library it will work for the governor, but it won’t work as good as measuring rotor speed because the percentage ratio of RRPM vs ERPM yields different values, depending on transmission ratios in the main and tailrotor gearboxes. A helicopter may fly based on raw main thrust, but may be uncontrollable due to LTE. If the prime mover is not running, which is typical with electric drives during in-flight needle split, then that ESC rpm output tells us absolutely nothing about the flying state of the helicopter because it is zero.
First of all: Thank you for commenting on my post.
BlHeli is vendor independent but the code is closed source. You will get ESCs with the exact same feature set from around 10+ companies. I think that this is better than Align vs Hobbywing vs Castle Creations, which are all doing things differently.
BlHeli has two features:
Rampup Power
Maximum Acceleration
That is right and would be a very good feature. This speaks against ESC RPM (alone).
To my understanding: With current copter code and 8 motors with sufficient headroom the system will not detect the failure. Eventually the EKF will do the right thing…
The idea behind this post was to inform you guys about the possibilities from the copter world and have a look into that from a heli perspective. I have learned from that, that ESC RPM does tell half of the story only, but as pointed out copter code is not perfect as well.
I think we can all agree on the fact that more tradheli users will widen the chance to also get more contributions to the wiki and the code. So making the entry into the tradheli world as frictionless as possible seems an interesting subject to me. In the light of the quad trend, there will be more people trying to migrate from that part instead from the (acro-) heli world.
You seem to have an extensive background in the helicopter business. Thats a good thing, and part of why I tried the trad heli code in the first place.
But also think about that its cheaper, easier and safer to start with a sub 5kg e-heli with used parts. Which does not require the same level of awareness in case of RPM loss etc. An easy setup which minimal number of parts required would be best.
I think most people quickly move onto 600+ helis, and use much higher voltage setups.
I haven’t seen any high volt BLHeli ESC’s, but I may just not have seen them.
I think that if manufacturers make helicopter-specific ESC’s with BLHeli then we could look at it. But at the present time I don’t see anything in the offerings that would be suitable for helicopter. Even a 100A helicopter unit for a 500 is a monster with a big heat sink and 10ga wires hanging out of it.
A 200A one costs as much as a whole 500 helicopter. Anything less will go up in smoke. Helicopter ESC’s are designed to be operated at or above 85% continuous pwm throttle, and they tend to overheat if operated at lower throttle settings. Multirotor ESC’s are designed for a different duty cycle.
I would like to give my feedback for this post on the experiences and results I got trying to put the internal governor through the input of several BHeli Esc capable of returning the engine rpm. Simply that concept does not work for the simple fact that the error (true rpm varies in the order of 100rpms) that these ESCs have is very large and it does not serve the internal governor purpose. By the way, I don’t understand how DBSHOT improves the control when the error is large, increasing the sampling of an error does not reduce this error/variation. I ended up buying small magnets and a hall sensor, with a negligent cost (40cents 10pcs 3144, 2Euros 100 magnets in Aliexpress) , and soldered with a resistor and a led directly. This concept is working perfectly and very precise (8 poles glued to the rotor).
