I agree. I trained my customers to use Alt Hold. Some got it. 
1 Like
I don’t entirely disagree with that. Pos Hold allows you to fly the aircraft like it’s in stabilize and hold position when you center the sticks, which is handy. Not sure what braking methods Pos Hold uses, though.
Time for another update on the project…
I have now spent a lot of time on developing the controller for the entry and glide phases. I have tried a number of different set ups and styles for the head speed controller. The one which has given the greatest results so far is a PD controller with a following trim.
The following trim was @bnsgeyer’s idea and is much like what is used in the control loop of full-size manned helicopters. It is essentially a feed forward of the collective position in the previous time step, that is filtered with a low pass filter. The filter then gives us the ability to control how quickly we want to allow the trim to change.
The P term contributes two things here. It aids in removing the error in head speed (like any normal P controller) and it essentially gives the direction for the trim to travel (either increase or decrease collective). The D term here simply allows us to use a larger P term without entering into controller instability. Due to the nature of the rotor system’s response it is not possible to have a larger P term without inducing instability. Commonly, in systems that exhibit this behaviour I terms are employed to gradually build up over time and reduce the error gap that is left by the P term. I originally tried a PID controller for this reason. Due to the speed of response of the system, only small I terms are useable. However, I terms have the advantage that they continually build with time also known as ‘wind up’ The trouble with an I controller in this application is that as long as it takes the I term to ‘wind up’, it takes almost as long for the I term to ‘unwind’ when it overshoots the error target. In this application it leads to the head speed doing one of two things:
- Large I term causing constant oscillation around the target head speed with large variations in RPM (as much as +/- 500 RPM) which also causes oscillations in attitude due to collective-pitch coupling effects.
- Smaller I term leads to the I controller taking so long to ‘wind-up’ the head speed doesn’t recover fast enough leading to unacceptably low head speeds or even blade stops.
So this is where the following trim comes in. It has the advantage that it can bridge larger gaps in error (just like the I term). Plus, the speed that the trim value can change is customizable for the phase of flight and It is not subject to the stability constraints of a traditional I term.
The head speed controller was then set up to allow a relatively faster filter frequency during the entry phase. This allows the collective trim value to change quickly and get to a sensible position, that is close enough for the helicopter in question. The speed of the filter is then reduced in the glide phase to allow the trim position to be fine tuned. It also has the added advantage of not limiting the trimmed position, which is still able to adapt to changing conditions, such as changing wind speed etc.
The attitude controller employs the speed-height controller from the L1-nav library. It is used to build airspeed up to a pre-defined value. Currently the target airspeed is simply pre-allocated in a parameter by the operator. A potential future improvement will be to use the measured instantaneous glide slope to control the airspeed target to achieve the best glide. That is, however, something that I will look into much further down the line.
Both controllers (headspeed and attitude) have a particularly hard time due to coupling effects. i.e. A change in the collective position or head speed causes a change in the pitching moment. Similarly, a change in attitude causes a change in head speed due to the change in inflow angle to the main disc. The coupling effects can be damped out by slowing the speed of the response of the controllers. However, slow the controllers too much and they become in effective, as it typically only takes 7-15 sec from engine failure to touch down, from the altitudes that we are normally operate from. I have arrived at a default tune that strikes the best balance, works ‘out-of-the’ box for all of the heli’s that I have tried in real flight (SITL). In some cases a bit of tuning will improve performance, but the controllers should get you out of a jam as is.
After a lot of testing in the sim it was time to test the code in real life. So here it is… A warts-and-all video of my test. Skip to 6:37 to see the autorotation. Be sure to switch to full screen at 1080p as the heli is so small in the video it is hard to see.
In summary it was a mixed bag of results. It is hard to tell from the video but the autorotation controller actually worked! The bailout from the autorotation however, did not…
Looking at the logs:
Looking at the head speed (above) it can be seen that there is an initial decrease in head speed. This is normal, particularly with small helis like my 450, as there isn’t much blade inertia to maintain speed and it takes time for the decent rate to build and drive the rotor. It can be seen that the head speed starts to build again. Great success! Then I elect to bailout with plenty of height to recover. This is where it all goes wrong. Essentially, the heli drops past the target altitude (set when the mode changes). The altitude controller, then raises the collective and stalls the main blades, leading to blade stop. The high collective also makes it harder for the motor to get the head back up to speed. To back this up, see the collective out:
The forward speed/attitude controller shows good signs on working (see below). It should be noted that as airspeed sensors are not currently support in copter (it is in the pipe line), the forward speed is currently an approximation of ground speed. Hence the issue introduced by wind.
To give you an appreciation of how quickly it all happens, see the decent rate below. The heli drops to a decent rate of 13 m/s (2560 ft/min)!!! Now this is a function of the fact that I am using a small 450, which are harder to autorotate due to their small disc size and low blade inertia. Larger helis will autorotate much better and slower (they will actually fly somewhat). That being said, it still a pretty good little test platform. It acts as a punishment test for the controller and has the added advantage that it is much much cheaper to repair when it all goes wrong 
.
Summary
So in summary, the controller itself shows strong signs of working as expected. The bailout needs a lot of work. All in all I am counting it as a win 
P.s. For those of you worried about the heli, having done the damage report, all it needs is a new undercarriage and a tail gear box. So, I am counting myself very lucky!
10 Likes
I have a ‘sacrificial’ Protos 500 I can test on. (I’ve used it for practicing autos).
Give me a shout when you want to additional testing done.
1 Like
@Implicit, that is very kind of you to offer. After reviewing the log from the last test I have a pretty good idea of how to improve the bailout. I will let you know when I have made the improvements 
1 Like
Few people will read the proposal category.
So here is a link to the detailed plan of IAMMATT:
Fingers crossed!
Matt, you should consider the new Tarot 550/600 helicopter. Pretty revolutionary design. Should be tougher and cheaper than a Trex.
It certainly looks pretty cool. It also looks like it will be a PITA to fit a flight controller and sensors to it.
Bah, nothing a 3d printer cant fix.
Last Monday saw the close of the Google Summer of Code period. Development of the autonomous autorotation will be continuing. To draw a line in the sand, from one phase of the project to the next (i.e. GSoC and post-GSoC), I have submitted a PR to master. This will bring the framework of the flight mode, the entry and glide controller, and the bail out controller into master for SITL only use. This will be a big help to me as I am far less likely to run into issues when rebasing my code off of master, as I will effectively have a space saver in the code.
For those interested the PR is here:
A demonstration of the functionality in SITL can be seen below:
If you want more detail about the parameters then please follow the link to the PR above. More detail is given there.
I also added some further functionality and robustness to the flight mode. Previously, you would have been forced to use RPM sensor 1 to read main rotor rpm. I have now added the flexibility so that operators can choose to use either RPM 1 or 2 for main rotor head speed. I have also added the monitoring of RPM sensor health. If the RPM sensor reports no signal or poor signal for a preset period of time then the controller will default the collective to the minimum position as defined by H_COL_MIN. If the unhealthy RPM sensor clears up then the controller will revert back to normal operation. A demo of both of these features can be seen here:
Finally, I have written a little GSoC project summary and review. For those interested it is here.
The next step is developing the flare phase controller. I am hoping to get some flight data from the community to help me with this. I will post more details and some instructions for those that want to contribute later today.
4 Likes
@IAMMATT Thanks for the amazing work here. I think we all realize what a significant undertaking developing an autonomous autorotational capability would be. I think most efforts of others to develop a similar capability fall short because they only addressed effectively one gross weight (light). So I appreciate your work thus far to make this autorotational capability applicable to a wide range of gross weights (up to 20kg). I look forward to working with you to bring this full capability to fruition.
3 Likes
Very interesting development in progress.
My Helis with direct drive tail will not work with Auto-rotation.
Never mind.
Fred,
Are you running DDVP with an electric motor or is your tailrotor connected to your main rotor. I guess I don’t understand.
Yeah,that’s a major issue with the direct drive. I get it from a mechanical simplificity point of view, but you then add one more motor/esc that can also fail, so I’m not quire sure what the benefit is.
Yes, I have on both Helis DDVP with an electric motor.
TR700 ( Jet-ranger ) and TR600 with longer tail. It is so easy to fiddle around this way. The main motor uses all its power for the main rotor only. As Jakob is saying for mechanical simplicity.
If I am building a new Heli and the Autonomous Auto-rotation is working ( available) for that reason, I would use a torque tube or belt driven tail for sure. But I cannot change the others back because their tail booms are not standard anymore. No tail failure for several years now.
That’s a really good looking Jet Ranger Fred.
In principle, a DDVP heli can be autorotated as well. I suppose it does depend on how it’s wired. Either the tail motor and esc is still functional in which case yaw control is still available. Or, the tail motor/esc is out, in which case it is just like a mechanical tail rotor failure case when the tail is driven off of the main shaft (a failure case that I will be developing for in the code).
For direct drive tails I would need to add in some extra functionality to the code to prevent the tail rotor esc from being shut down in the ‘practice autonomous autorotation’ whereby the pilot initiates. I don’t have the capacity to add this in at this point in time as I am still getting the fundamentals sorted. But, that’s not to say its not something I could look into later down the line.
Matt thank you for the reply. I will watch your development with interest!
I have some exciting news to share!
As some of you will already be aware, I submitted a funding request for a larger airframe to support the autorotation development. Well, this funding request was accepted by the ArduPilot funding committee! As an added bonus, @cczeets of Terraplane (an ArduPilot partner) has also contributed to the cause to enable me to get a larger 700 size heli for testing. So a huge thank you to both parties for the support that you have shown me in this project!
Call for Test Data
I am currently working on the flare phase. I am trying to define a target trajectory that the heli will attempt to follow during the flare. I would like some test data from autorotations from various helicopter sizes. If anybody has any log files where they have performed autorotations (or would be willing to go out and record some), I would be very appreciative if you could share them with me. The main things I need are the positions and velocities which come in any log file. An added bonus would be if you have an RPM sensor fitted so that I can look at the head speed as well. Any data would be most appreciated!
1 Like
Setting LOG_BITMASK to 65535 (Default) will give me all the data I need.