Well lets not jump into this too quickly. I think we ought to look at this in the sim. I think switching into Loiter might not be the best mode to go to. Now that I think of it, even Poshold might not be a great choice. It depends on the braking that the mode invokes on reverting to the mode. That may cause undesirable behavior on recovery. Matt, I think you mentioned that you were seeing undesirable nose up on coming out of the auto. That may be due to the mode being poshold on recovery which would want to brake the aircraft if the users stick is centered. So think about this more, I would think stabilize or althold might be more appropriate to keep the recovery from being too abrupt in the pitch axis.
Yeah, Alt Hold is my usual bailout mode if the height estimate is working. Itâs the âcoast to a stopâ option. However, some users canât fly Alt Hold. âItâs a Flyaway!â because of wind.
I would agree. althold seems the most logical.
What does that mean?
IME the majority of commercial pilots can only fly in Loiter, Auto, and RTL. If you put them into a non-GPS mode, they will watch it being blown away by the wind, and claim Flyaway.
Ok. Now I understand. I think althold still makes most sense as it wonât cause unexpected braking and a smoother transition.
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.
