Autonomous Autorotation - GSoC Project Blog

Hi Everyone,

I am very pleased to announce that I have been fortunate enough to be accepted as a GSoC student for ArduPilot. My project will be to add autonomous autorotation support for traditional helicopters. This thread will be a blog for me to post my progress, interact with the community (getting your thoughts and opinions), and to help me gain an appreciation of the diversity of vehicles that this function needs to serve.

The primary goal of this project is to enable ArduCopter to detect power-train failures and subsequently perform an autorotation. My intention is to do this in a robust manor that maintains generality to all trad helis and doesn’t require excessive tuning. This approach will essentially involve building a generic H-V lookup table that can be scaled based on a few physical properties of the helicopter (e.g. blade mass, disc loading, etc). If you would like more info then you can read my project proposal by going here and clicking on the project title.

As this needs to be generically applicable to all helis it is unlikely to be flawless. One of the primary concerns is the lack of a reliable height estimation that could lead to the heli still having a hard landing. Therefore, this functionality will be developed to allow the pilot to still add control corrections when operating within VLOS. When operating BVLOS the functionality will still serve to ensure that minimal damage is occurred and will offer an additional level of redundancy to the system.

With regards to landing options, it is currently intended to offer the following options:

  • Landing straight ahead.
  • Circling descent to land into wind.
  • Attempting to land at the nearest rally point, into wind.
    This is obviously dependent upon ensuring reasonable wind direction estimates.

As a part of this project I will be asking the community for support in the form of providing me with data from successfully flown autorotations. I will be posting up the details of what I am looking for in the next few days.

So that’s the project in a nut shell. Let me know what you think!

Many thanks,



Great Matt

and welcome aboard.

I’m sure we’ll see this so desired feature very soon :slight_smile:

Great news Matt will be following you with interest and learning as you go.

Time for an update on the project so far.

In the very beginning of this project I spent some time playing with the pre-existing controllers in ArduCopter. I was looking to see if the pre-existing controllers might be suitable for use in the autonomous autorotation. A few research groups have attempted autonomous autorotation in the past using PX4 or ardupilot. Some of which, have done this using the pre-existing position controller. So my first port of call was to investigate the position controllers ability to perform an autonomous autorotation. The results I obtained using SITL can be seen in the below video.

In this video the autorotations are all performed autonomously in the new flight mode that I have created (mode 25 in the video). Sadly this video, does paint a rather rosy picture of the autorotation. This is for the following reasons:

  • The autorotations are being performed with a 3D heli. These have low disc loading, when compared to a utility/UAV heli. This makes them far easier to autorotate. So much so, that it is possible to perform vertical autorotations.

  • Real flight isn’t capable of simulating the vortex ring state or the turbulent wake flight regime. Both flight regimes can be present during an autorotation and worsen the performance of the helicopter. Hence, real flight, whilst a great development tool, does paint a some what pretty picture of helicopters in autorotation.

  • Notice in the video that I don’t initiate any autorotations from the hover at a high altitude. From the hover, at high altitudes, all of the attempts end in tears, and a lot of bits in a virtual bin bag. The reason for this is because the position controller sets targets and errors in the earth frame. This is fine, when the attitude doesn’t exceed small angles. However, from a high altitude hover (or low airspeed), one of the primary objectives is to lower the nose and build airspeed, being careful to not slow the head speed to much in the process. Now in this scenario, there is no longer a small pitch angle. The heli is effectively diving to change height into airspeed. The decent rate increases. The PSC was implemented to provide a target decent rate that will result in a safe rpm. With the heli in a dive, the descent rate criteria is now being surpassed. So what does the PSC do? increase collective to slow the descent. In this attitude, and flight regime, this action has the effect of slowing the head speed further. This in return reduces any lift being produced, making the decent rate increase, exacerbating the problem further!

So, in summary, the PSC was tried, but it isn’t suitable for autorotations. “Ah but what about the vertical autorotation! I have read of others achieving this with small size helicopters.” I hear you say. Yes, you would be entirely correct in saying this. Plenty of people have successfully performed vertical autorotations with rc helicopters. However, they have only been able to do this with 3D capable helicopters. In this case, the heli has remarkably low disc loading, and access to significant negative blade collective pitch range. As soon as you start operating with utility/UAV helicopters with higher disc loading (in the region of 1.0 lb/ft^2) then this just isn’t possible. However, we wanted to challenge our preconceived notions of the ‘dead-mans curve’ and see if it was. @ChrisOlson put his own machines on the line and conducted flight tests with one of his heavier setups. The conclusion: Vertical autos are not possible for anything other than a light weight 3D heli setup. As we want this autorotation mode to be viable for all heli users of ArduCopter, then the only way to achieve this is with a custom controller, capable of guiding our aircraft through a traditional autorotation procedure.


Beyond the above investigation, I have set up the ‘switchology’. i.e. how to get into and out of the new mode. Following lengthy discussions with @bnsgeyer and @ChrisOlson we agreed on the following layout:

  • When in a manual collective mode (stabilise and acro) users should be able to practise autorotations just like you can with any other rc helicopter. Flick throttle hold on and then its up to you to do the rest.
  • When in an non-manual mode the autorotation should be performed by the flight controller. This will either be initiated by the autopilot detecting a loss in power or by the pilot.
  • If the pilot chooses to ‘bailout’ of the autorotation, it should return back to the previous flight mode they were in.
  • For testing purposes, it should be possible to access the autonomous autorotation mode, from a manual collective mode such as stabilise or acro.
  • If the autorotation is initiated autonomously due to detection of a power failure, during an auto mission, and power restores during the manoeuvre (e.g. a kinked fuel tank vent line, causes the power failure, and unkinks during the autorotation), then the flight controller should restore power and bailout of the autorotation. However, the heli should not resume the mission and potentially fly further away from the pilot, instead the heli should recover, and await instruction from the pilot. I suspect in 99 cases out of 100, the pilot will want to investigate the cause of the power failure so will choose to fly the heli back to home.

This switchology and all of its requirements have now been setup and are working well. See the flow diagram below to get a better feel for how this switching works.

Let me know what you think? Does this cover all of your needs? Have I overlooked anything?

Further to that, I have now built a new controller library specifically for the autorotation controllers. The first controller I have built is a head speed/collective controller for the entry and glide phases. This controller attempts to maintain head speed with the collective. This does now mean that an RPM sensor is a requirement for the autonomous autorotation to work. But hey, what’s a few bucks/quid/euros/yen/denomination-of-your-choosing when it comes to saving your much loved flying machine?

So far the headspeed/collective controller works pretty well. The next phase is to created a weighted coupling between this controller and an airspeed/attitude controller. This will help the autopilot to decide when It is more important to pitch down to build airspeed, or pitch up to recover head speed.

Matt’s project is probably one of the most complicated that’s been attempted in heli. As Matt develops this, pilots that use it will have to learn the same aspects of helicopter flight that full-size pilots must learn. Primary to this is the Height-Velocity diagram (otherwise known as the “dead man’s curve” by helicopter pilots) and its significance in safe vs unsafe flight profiles for helicopters.

What this means for Matt’s project is that all conventional “wisdom” in RC autorotation, and the way it is taught, gets thrown out the window for heavy UAV’s. And switch to the same criteria full-size manned helicopters use. One difference is that in full-size light utility class typical best autorotation airspeed is 44-45kts. Medium-light class like Jet Rangers are closer to 70kts. Most UAV’s can be autorotated at 20kts, 25-28kts is better. The reason the UAV can be auto’d at slower airspeed is because of the lower disc loading compared to full-size - unless it has turbine power UAV helicopters simply do not have the power to fly at the disc loading and blade tip velocity that full-size flies at. Meaning the typical UAV cannot carry the weight per unit of rotor area that a manned helicopter can. But this also means lower possible airspeed for autorotation with the UAV.

The complexity of achieving this with an autopilot is non-trivial. It has never been achieved in full-size (yet) with $150,000 autopilots.


Will lidar be required for better altitude detection?

Also, Skokum claims to have autorotation in their FC, but I can’t find any examples of it…has anyone seen it?

And l almost forgot! Nice work!.

Thanks :slight_smile:

The jury is still out on LiDAR at the moment. A number of attempts at the vertical autorotation have used downwards facing LiDAR. In these types of autorotation the heli maintains much smaller pitch and roll attitudes, so the error introduced by the LiDAR not pointing straight down is small, and the laser remains pointing in the approximate terrain area under the heli giving a reasonable height estimation. Going back to the point my previous posts, vertical auto rotations aren’t viable for bigger UAVs and thus not what we are developing. I want to look at LiDAR and conduct some flight trials to see if it will be useful. I am also thinking about mounting a LiDAR on a 2-axis type platform that always points the LiDAR down, or at the predicted landing location. This may improve the height estimate.

Will LiDAR be mandatory for this mode? No. One idea we have discussed is to add in stick mixing, so that if the pilot can see the heli, either LOS, or via FPV then they can input some corrections if they are unhappy with the flight profile relative to the ground. However, overall the objective is to create a autonomous mode that will at least minimise the damage to the vehicle. If improved height estimation is installed then the survivability will improve.

With regards to the Skokum FC’s autorotation capability; @ChrisOlson knows more about this I, but my understanding is that it only works for 3D capable helis in the hovering autorotation.

The reason you won’t see any demonstrations of it from Skookum Robotics is because it uses a dump of negative pitch, then pulls big pitch right at the end and smashes the helicopter into the ground at about 2000 ft/min descent rate.

We tried it on a Velos 880 and it can land one of those in 3D configuration. But no way can it land a UAV - all it can do is a controlled crash. Having the feature and advertising it is different thing from the feature actually working. You can try this for yourself from a safe altitude. Put a fully-loaded UAV heli into stable hover, then shut it down and pull -6 pitch. The descent rate is approx the same as a rock at 32 ft/sec^2 acceleration rate. In fact, I’m not so sure the helicopter won’t beat the rock to the ground. There’s just no way that main rotor creates enough drag windmilling at -6 to slow down a UAV.

WARNING: If you do want to try this to experiment with it we have some special autorotation bailout code now that will bypass the ramp timer. You will need this to get out of it, along with having enough altitude to put the heli into a dive to recover or it will go into VRS and smash into the ground anyway at full power, unless you can get some heat on it and get it flying again. Remember that helicopters don’t fly in hover or vertical ascent/descent. All they do is use brute power to beat the air into submission and they have to have enough power to move air in mass equal to their own weight, plus overcome energy contained in moving mass, to get out of a dangerous flight profile like this. Put some airspeed on it and get it flying and then the helicopter is in its favorite flight profile, more like a fixed-wing.

Contact me and I’ll make an ArduHeli build with that bailout code in it for the experimenters if anybody is interested in trying it. I’ve tested it extensively in a real heli (not in the sim) and it works great in acro or stabilize flight modes. It was one of the first things we had to do because ArduPilot never allowed a way to bail out of an autorotation before.

Nice video about VRS recovery:


Thanks Markus. That is a good vid!

Hi Markus,
Good to see you are following and posting again. Do you have any heli’s flying ardupilot?

Hi Bill,

sorry, no heli’s flying ardupilot (only planes as UAV), but I fly a lot with heli’s :grinning:

@IAMMATT. Great work and thank you for the update.

How come from Auto Mode, if the ThrHold comes back off (gosh what a confusing name) it goes to Pos Hold? I agree it’s not great to return right back to Auto, but why not Loiter? I’m not a fan of Pos Hold, never use it, don’t recommend it.

The key idea here is, as you say, to not to resume the auto mission and potentially fly a compromised aircraft further away. There was no specific reason for Pos Hold. Would be happy to change it if there are better modes to enter into. Can you elaborate on why you prefer Loiter over position hold?

Loiter will stop in a more programatic fashion.

I actually disable Pos Hold on my commercial helis. So would rather not have to hack that later. The only reason Pos Hold exists is because people didn’t understand Loiter and how to make it perform as they want.

Ok, no problem. I will change it to loiter.

Awesome, thanks.

And filling in to meet the 20 character mininum… :slight_smile: