Helicopter Rotor Speed Governor

We’ve been working on a governor for ArduPilot and I now have it working pretty good:

I have test binaries built for various controllers. All the builds are ChibiOS:

The governor measures headspeed, not engine speed. It requires a hall effect sensor with a magnet on the main or autorotation gear. The sensor is plugged into the Aux5 pins on your controller. The settings to get RPM to work are the PWM count - set to 4 so aux5 or 6 can be used for other things.

The relay pins disabled:

Make the rpm settings for rpm1 as shown:

The new governor settings all start with H_RSC_GOV. They are:

  1. The disengage point: recommended setting 2% above your flight idle power setting (first point on the throttle curve). As shown in the below example, the governor disengages at 20% throttle.
  2. Droop Response setting: 0-100%. This sets how aggressive the governor is. A droop response setting too high in relation to how your prime mover reacts to throttle can cause the governor to surge or over-react to load change. Around 85% should work good for most piston engines. A little higher for turbines. A lot lower for electrics.
  3. RPM setpoint - set to desired headspeed
  4. Throttle Curve Gain - set to provide feedforward from the throttle curve for sudden change in load. If it over-runs on a sudden punchout, reduce the TC gain, etc… Can be set from 50-100%
  5. H_RSC_MODE - 4 is governor control.

Note in this design I’m trying to get away from settings that are not friendly to users. IMO most users understand stuff that’s 0-100% or whatever. Settings like 0.25 for 25%, or 250 pwm for 25% don’t make much sense to end users. So I did the scaling in the code, not with the settings, to make it simple to understand and set.

The type of governor used here is a proportional droop speed control. It is not a PID governor, as PID governors are notoriously unstable with combustion engines. If you’re interested in exactly what is a droop speed control, you can read about it from the oldest manufacturer of aircraft piston engine, turbine and propeller governors in the world.


You must first set your throttle curve and properly tune it. If the sensor fails the throttle control fails over to the throttle curve. Without a properly tuned curve, your helicopter will crash. For UAV operation it is recommended to set your throttle curve with a flight idle position (the throttle curve 0 point). This allows you to idle your engine down by pulling the collective to the bottom. Engaging the throttle hold (motor interlock in ArduPilot) will disengage the clutch and set the engine to ground idle power.

When tuning your throttle curve, tune it aggressive so it runs higher rpm than you normally fly at. This ensures adequate power available if the sensor fails. With the governor you don’t have to have a perfectly tuned throttle curve, but it should be “close enough” to fly the heli with no surprises. You can tune your curve with H_RSC_MODE 3 if you want. Or tune it with MODE 4 with the TC gain set to 100 and Droop Response set to 0. Either way works.

You can refer to the ArduPilot Helicopter Ground School videos if you want to take a refresher on setting throttle curves. Video 4 covers throttle curves, piston and turbine engines:


This governor was designed primarily for piston and turbine helicopters, as the engines don’t come with a governor (except for JetCat turbines) and buying one is quite expensive.But it does also work with electric helicopters - I tested it in my Synergy 626. The only difference with electric is the droop response setting. Electric motors have a quite flat torque curve so they don’t require as much droop response as combustion engines. However, unlike combustion engines, the speed of an electric motor droops as the battery voltage falls. This is where the governor will come in handy for an electric (if your ESC don’t have one).

Since most people use ESC’s with governor already built-in, I suspect the governor feature will be primarily used by people who fly pistons or Wren turbines.

There is a couple new logging items added with the governor feature - we now log helicopter throttle output and the governor output. This is an example log graph of the governor in operation. On the left side of the graph I was flying it, did a punchout (the sudden spike in throttle). I landed and disengaged the governor by pulling the collective/throttle down to flight idle power. You can see the governor output went to zero. I then re-engaged the governor by gradually increasing the throttle (via the collective throttle curve). The governor came on (the sudden spike in governor output and throttle), then went to steady state control back to governed headspeed as I continued increasing throttle to pull pitch for liftoff.

It is totally automatic. You don’t have to switch it on and off.

The governor “bites” pretty good when it engages, very similar to the governor in the Guimbal Cabri G2. I decided to not do a ramp-in of the governor for three reasons: if throttle hold is accidentally hit in flight, nothing makes a pilot madder than an engine that don’t come back right away. The second reason is autorotation practice with power-on recovery. The third reason is that the “bite” to get it up to speed at governor engage will not affect people who like to use auto takeoffs.

With auto landings, the system can be set to pull the throttle down to flight idle power and disengage the governor before auto-disarm and engine shutdown. This reduces the chances of a dynamic rollover vs governors that hold full headspeed while the system is trying to decide if it should disarm or not on the ground. And in the event the system screws up and pulls pitch again (I’ve seen this happen with auto landings), the engine power will come back immediately with no delay.

If you desire the governor to never disengage once it grabs, set the governor disengage to zero and it won’t let go of the throttle no matter what you do, short of hitting throttle hold.

In my experience with full-size helicopters - pilots, students and instructors love the governor in the G2. Where a Bell 206 Jet Ranger takes more training to fly because the governor is more “sloppy” and it takes time to schedule the N1 section of the engine so the N2 produces 100% torque. So while hard-edged controllers like this typically aren’t used in ArduPilot, this is not a place for a soft-edged one. It “bites” but it’s not so radical that it twists the heli on the ground as you can see from my vid - even in the snow. Let’s just say it comes on with authority and you know beyond a doubt the governor is working. It has been cold and snowy here, but in the couple autorotations I tried with it it actually comes back on power smoother than the Aerospire governor in flight. There’s not much out there for gasser helicopter governors. The old GV-1, which is not all that great. The Aerospire MultiGov Pro, which is designed primarily for 3D. And FBL units that have built-in governors. IMO this one beats the Aerospire for stability. And that was one of my primary goals was a governor that exhibits rock stable operation with no surging, and no over-runs on sudden unloading of the collective. Some speed droop on sudden loading is completely normal with any governor due to the way engines react to throttle and torque rise. But it should come back on speed after recovery without over-running. The Aerospire won’t - it over-runs every time and then slams the throttle shut because it went into over-speed, which causes the tail on the helicopter to jerk. This one won’t do that.

This has been a long requested feature in ArduPilot and was supposed to make it in clear back in 3.4. Except it never did.

Hope heli pilots find it useful.


Absolutely fantastic! Will test and report back

Great work Chris!!! Another big step forward for Trad Heli users. Thanks!!

Thanks Bill! Unfortunately, this was one of those projects where I flew a lot of beta code and it didn’t work right. Then I had to walk away from it and come back with a fresh outlook after studying some more engineering materials on governors, punching the calculator keys for two hours, and making spreadsheets to graph throttle response to torque curves.

When I started this project it looked simple. And the math behind a basic flyweight governor, which is the most proven and used governor of all recorded time, is very simple. Tailoring it so it fits the torque and power curve characteristics of various prime movers, not so much.

1 Like

Amazing news Chris, this is what i was looking for the gasser we are flying. 5 point throttle curve is already working fantastix and with this governor mode i cannot ask for more. Will test this as soon as possible.

Amazing, thanks Chris.

Whats with E-Helicopters?
Do we still need ESCs with a special helicopter feature set like a governor?
Or will every blheli_32 esc with telemetry out (and thus motor rpm readings) do in the future?

I’m not familiar with blheli_32. Maybe they are used in smaller helicopters? Most electric helicopters of UAV size use 160-200A ESC and I can’t recall I’ve seen a blheli_32 in one.

For pilot still flying 3.5 I backported the governor to the ArduHeli 3.5 code and made a new release, 3.5.7 with the governor in it.

I have binaries for the most popular controllers. It is not possible to fly this with Pixracer as it doesn’t have enough outputs on the servo rail for governor speed input.

Chris your governor works perfectly on a 700 with gt15hz gas motor. Installed a hall effect sensor and filter capacitor, flashed your firmware and it works exceptionally well. Good work mate

Thanks for the feedback on it! The code is still built on Copter 3.6.3. Have not had time to update it to 3.6.5, will do that this week.

The heli governor test builds have been updated to the latest Copter 3.6.5rc2. Binaries for the most popular boards can be downloaded here. If you have a board for which there is no binary, please let me know what it is and I’ll do a build for it.

Note this firmware version will identify as ArduHeli instead of ArduCopter so if you post logs Bill and I know you are running a custom build and not an official build.

Chris, well done? The governor function works beautifully. I initially had some issues with the sensitivity of the pickup sensor (align nitro) and adjusted it accordingly. Fortunately, I had a throttle curve setup and it failed over without any issues. You can clearly hear when the governor kicks in and it is a wonderful sound.

Thanks a lot!

Is the governor function available in the latest stable release? (3.6.5) From time to time I have Bad Logging and would like to upgrade as my understanding is that this has been fixed.

Thanks for the feedback on it. Yeah, everybody that has flown it so far likes how it comes in and works. It’s not a “sloppy” type thing where the pilot doesn’t know for sure if it’s working or not, and that’s the feedback I’ve gotten on it from other folks.

The build link posted above, built on 3.6.5rc2 should have the Bad Logging fix in it. That firmware has the slowdown setting for the SD card and is what I am currently flying. I will update those binaries, though, to the latest 3.6.5 release tonight and post a notice here that they are available for stable release users.

Can someone can send a link to a competible hall effect sensor?

Thank you

Just google for Align, Aerospire, or Spartan rpm sensor. Pick the one you want. Basically, any hall-effect sensor will work with a magnet on the main or autorotation gear.

Hello Chris,
Thank you.


So I put a soft-start feature in the heli governor. I did this primarily for turbines to prevent over-fueling the Ng and spiking the Turbine Inlet Temp beyond 1000C and burning up the power section when the governor comes on. It would make the N2 power turbine glow red with significant flame on the tailpipes.

But it works good for piston engines too. I uploaded new binaries that have this feature, and they are available in the link in the first post in this thread.

Little too cold here to mess with a kerostart turbine today, but this a demo with a piston heli.

In the process of looking through @ChrisOlson governor code, I got to thinking about how the controller could monitor the RPM. Not necessarily for governing the rotor but for determining the state of the rotor for the startup and shutdown part of the rotor speed controller (RSC). This idea was to replace the timers that are currently employed to determine the rotor has completed run up and is below the critical RPM. So my first thought was a FFT that was always running in the background but that sounded difficult cause I don’t know where there is an FFT library in ardupilot and probably a little computationally expensive. Also the measured rotor speed would have to probably lag behind the actual rotor speed because you had to capture enough data to perform the FFT and then determine the peaks. But it can also be determined by looking for the peaks in the accelerometer data. All rotors have a distinct once per revolution vibration in the accel data. I think my rotor is balanced pretty well but it still shows this 1/rev oscillation in the accel data. I would be interested to have Chris try it on one of his smoothest running heli’s :wink:
So I wrote a little function that looks for peaks in the y accel data. I just did a short flight and here is a plot of the estimated RPM

I had my ESC set for 1500 RPM and for the most part, it nailed it. As a first cut, I thought it did pretty well. I thought it was interesting how it caught the 2/rev for the spool up and spool down. I peformed some maneuvering and it tends to not do as well. I will have to look at some of the data to see if I can get it to work better, but I think this looks promising as a way to determine the state of the rotor system. Again this is not intended for actively controlling the rotor system.

@bnsgeyer it seems to me some time back you did look at a log or two of one of my bigger helicopters and it did exhibit the same characteristic. I’m pretty sure they all do. With newer controllers with built-in vibration damping this may be easier to detect. On the Pixhawk Cube forum I have seen Philip recommending in some cases to hard-mount the controller as soft mounts don’t tell you what the frame is doing and you’re losing data from your accels.

I have been flying CUAV controllers with built-in damping the same way - hard mounted - and have gotten excellent results from it.

Earlier controllers where folks have gone to great extent to isolate the sensors from vibration, and the controller is more sensitive to it, this may not work as well. So I think it will be an interesting research project.

The binaries have been updated in the 3.6 Governor code to reflect a change I made to add a method of scheduling the gas generator in two-stage turbine engines. The link is in the first post in this thread.

It is a relatively minor change, but it does effectively double the available governor output in the normal operational range to schedule the gas generator to meet N2 torque demand. This will change how the governor droop response setting is applied for piston engines. I flew it in two different piston machines, and both used a 55% governor droop setting after re-tuning.

I flew with a MW54 and 88% droop response worked nicely with the turbine.

The code is latest Copter 3.6.6 with the governor feature added to it. This feature is also now in PR for Copter 3.7 beta.

Hi Chris,
what values of Throttel curve do you use? , 0-25-50-75-100 ??