Correct. It was an attempt to hedge our bets on how to make the best out of a bad situation. If one were at high altitude, and don’t restart the motor or switch to a manual mode and auto-rotating it manually, the heli will crash. If one is at low altitude, and it attempts to maintain altitude, the rotor will stop, and the heli will crash. If at low altitude, and it goes into a plausible auto-rotation collective setting, it will slam into the ground. Auto rotation descent speed is going to be on the order of 5-10 m/s. You can’t land like that.
This is the only case where we can do something useful: Low altitude, and it will land before the rotor speed is gone. Everything else ends in crashing.
To be clear, even the mere idea of actually doing auto-rotation should not be taken lightly. It’s a very difficult thing. Autorotation is hopeless without a rotor speed sensor, and will need a feedback loop from rotor RPM to descent rate. Will also need a working Lidar to do the flare at just the right height. Everything else ends in a crash anyway.
Even LIDAR doesn’t work right at the speed the heli has to execute the flare at. That’s what wrong with the Skookum feature - it uses LIDAR and doesn’t work because it assumes the heli is going to come straight down instead of in a glide profile. So it basically bashes the heli into the ground and wrecks it because you need forward airspeed to properly autorotate and execute a flare. The big headspeed is gotten in the flare - not in the descent. And without the flare you can’t break the descent speed.
I do think we can make the autopilot set up an autorotation profile if it’s in flight, above 40 feet AGL, and moving at at least 8 m/s (16kts). The autopilot could basically fly it in an auto glide profile right into the ground at 12 deg nose-down. But a human pilot has to take over at some point. Because actually landing a helicopter in autorotation is skills the autopilot doesn’t possess, and is not going to be easily taught to it.
Here’s a good vid of autorotating a AS350, showing control inputs. There is nothing done fast or sudden. Autorotation is a total non-event if done properly.
The problem the autopilot has at present is that it can’t execute a smooth flare with a helicopter. It suddenly jerks the nose up even coming to a waypoint stop. This is unacceptable for autorotation (it’s actually unacceptable for flight). And the second problem is that the altitude estimating system in ArduPilot is very poor. And LIDAR does not work at the speeds and elevator angles used to bring a helicopter to a stop in an autorotation flare. The FBW autopilots used in full-size helicopters are much more accurate and precise than ArduPilot - none have achieved autonomously autorotating a helicopter to landing.
@Rob_Lefebvre As indicated in my most recent post to this discussion, I have a solution in mind that will allow the greater code to be consistent between heli and copter but still provide a similar descent profile initially so that if you choose to cut the motor at 1-2 ft off the ground, it will not slam the aircraft into the ground. I will be working on that in the coming weeks. @Leonardthall has done a good job with the non-manual throttle modes to handle the I-term and ghost behaviors so they are not affected by spool logic but rather the state of the aircraft (landed, flying, shutdown…). I’m working to keep all of the same behaviors that we had in previous versions.
@bnsgeyer does this preclude eventually doing an autorotation assist code? As Leonard said, the current system allows about two seconds before sufficient rotor speed is lost, making a full-down autorotation quite difficult.
Looking at Rob’s statement:
I agree it cannot be taken lightly. But I don’t agree everything else just ends in a crash, because I’ve done two successful autorotations with no damage to the helicopter in the past - both caused by drivetrain failure when in Auto flight mode.
We have the situation where a user inadvertently hits throttle hold in flight. This is usually an easy recovery - I remember once when I did it at about 20 feet in hover - hit the throttle hold instead of the governor switch. You tend to immediately go “that was dumb” and flip the switch again within a second or two and it’s like nothing happened. But that was in Stabilize so the heli lost maybe 3-4 feet of altitude. In an augmented mode it will maintain altitude and use up headspeed until it starts to drop.
Close to the ground, Rob obviously uses this, and there is no problem there either with the current behavior. Doesn’t matter if it was inadvertent or deliberate close to the ground - definitely don’t want the collective going to feather.
In flight, though, at a safe altitude and speed, it’s really no different as long as the switch is thrown again.
But in an actual drive failure if the system would set up a glide profile it would give the pilot time to react and get out of auto flight mode into a mode where the heli can be flown to safe landing. This is where the current system doesn’t work all that well. Within 2 seconds sufficient headspeed has already been lost to where the helicopter has to be dived at 45 degrees nose-down to recover. Which then results in converting energy stored in the dive into headspeed in the flare. And leaves very short time to pick out a landing spot.
I would envision an actual Autorotation flight mode that the pilot could engage as any other flight mode. And by using the proper RPM sensor could maybe be auto-engaged if the system detects a drive failure.
So I assume the spool logic will be totally separate from any sort of assisted autorotation, or autorotation flight mode, we might do eventually?
I think this is a good summary of why this has to be done.
The challeng here is this code is not being reverted. We are updating the spool logic and streamlining the code. So we have not reverted this code we have rewritten and improved the code and this heli specific code can not be included. We are trying to ensure that the resultant code is as close to the original as possible. Both Heli maintainers did not appreciate that you use this code the way you do. Sooner or later someone will reach for an undocumented feature or behaviour and it will not be there because someone did a bunch of work on the code and made it much better but left out this particular “quirk” that someone found useful.
Now that you point out how you use it, it actually makes much more sense.
So to do my summary thing I like to do:
Auto-rotation is hopeless unless you are only a foot or two above the ground.
In that case pulling the motor interlock combined with a negative decent rate will drop the aircraft onto the ground while bleeding head speed.
It is a useful feature for minimum head speed touch down
So the motor interlock, in addition to it’s defined function, is a low energy touch down switch. So we are not actually attempting to do or initiate an auto-rotation with this code like we first assumed.
Now my reaction is this behaviour can be reproduced with more control by removing it completly and leaving the motor interlock to do just what it’s documented function is. The pilot would then hover a foot or two above the ground and pull the motor interlock switch. They would then drop the throttle stick commanding a decent to only cm above the ground and wait until the head speed dropped to a point where the aircraft could not support it’s weight and it would drop the remaining cm onto the ground at absolute minimum head speed. Even if the pilot has become so used to this feature and does not automatically drop the throttle when they pull the motor interlock the worst that will happen is the aircraft will loose head speed at a foot or so above the ground rather than a couple cm.
From the code perspective we would be dramatically simplifying the code. It would be much clearer with less undocumented features and much lower risk to maintain. We can then leave the full auto-rotation behaviour to the fail-safe and extra mode approach that Randy suggested.
So the trick is to ensure that after we pull the motor interlock the aircraft continues to fly. One of the fundamental goals of the code changes is to treat the aircraft as flying when the spool state is not shut down so we are good there.
So my proposal:
Not attempt to add the automatic decent rate stuff back in.
Leave the motor interlock as purely a motor interlock and not attempt to second guess the pilot.
Educate the relatively small number of heli users about the change in behaviour.
Develop a heli failsafe library that can detect the various auto-rotation states (forward velocity, height, available sensors)
Add an auto-rotation mode that conducts a recovery appropriate to the altitude and available sensors, is capable of gliding to a landing point and conducting a plane like approach and touch down.
I have also just had a request from someone begging me to change the name from “Motor Interlock” to “Throttle Hold”. Like many things, Rob may have been trying to name this something that would make sense for both heli and multi pilots.
Would it make sense to rename this to “Throttle Hold”? I would be happy to do this from a multi rotor perspective.
If this is altitude controlled modes we’re talking about, this is pretty much true.
Can’t vouch for that one. Never done it before. In fact, I don’t think I ever would do it, as I like having full cyclic authority when the skids touch the ground.
I don’t think we want to go there. That would not be normal. If somebody wants to do it, fine, people do all kinds of stuff. But it’s a good way to tip a big one over unless you got moon lander feet on it. But most are equipped with skids or wheels so they can autorotate successfully. So I wouldn’t call this a common practice.
I don’t understand this one? How are we going to drop the collective and command a hover only cm above the ground until it uses up all the collective range? Why would we even want to do this? Why not just let it hang until it runs out of headspeed and collective - it will start coming down by itself without doing anything. You can’t hit a target descent rate with a helicopter in vertical descent with no engine and no forward flight speed. It is only going to hit the maximum descent rate that will be determined by aerodynamic drag. So having a bit of a problem wrapping my head around this one.
It would definitely make more sense IMO. I think Rob said he named it that from the mechanical engineering perspective. From the pilot’s perspective it has been throttle hold pretty much since the beginnings of rotor wing aviation. But only in helicopters. Not sure about multicopters. It is also backwards from what throttle hold is - “on” means throttle is held and the engine can only idle (or electric can’t start). “off” means unlimited throttle available.
No, like we discussed earlier, I wanted to get the spool logic implemented with minimal changes to I-term and ghost behaviors. I’m going to have a temporary fix for the non-manual throttle modes that will keep the collective from being feathered initially. The more I think about it, I may just freeze the collective for 1-2 seconds and then ramp it down to collective lower limit. I have to look at how this affects the rotorspeed bleed off if it was in a climb. It may not be perfect but the plan is that it will result in the aircraft settling to the ground if you engage throttle hold 1 to 2 feet off the ground.
Oh, OK. I guess I’m still trying to figure this out.
My opinion is that if TH goes to on in flight, either accidental or deliberate, it should do whatever is normal for powered flight in that flight mode, i.e. Stabilize and Acro it will do what the pilot commands, any altitude mode it will try to hold altitude as long as it can. My reason is because the power loss is fully recoverable (the ramp timer is not fully effective within a couple or 3 seconds) and the easy way out at higher than 2-5 feet is to just hit the TH switch again.
Let feathering of the collective, or any type of collective management be handled by autorotation code- not by spool logic.
Maybe I’m misunderstanding the spool logic and flying vs non-flying states and what TH means off or on in flight. Correct me if I’m wrong. I’m looking at Leonard’s proposal:
And I like it. I don’t see anything wrong with it as long as we’re not automatically feathering the collective with spool logic.
My point here was we currently pull the motor interlock (throttle hold) in Alt Hold and the altitude controller are commanded a decent rate. I am just suggesting that with the current implementation of the spool logic it will do the same thing except it will not command a negative decent rate. I was just pointing out that we can remove the automatic override of the pilots commanded decent or climb rate and leave it up to the pilot.
So: If the pilot pulls the throttle hold AND drops the throttle stick to the land speed setting it will do the same thing it does at the moment without the extra code.
As you say:
If the pilot doesn’t command a negative decent rate nothing to major should happen anyway.
You can for the first second or two while there is still head speed. I was explicitly talking about the 1 or 2 feet low energy landing function that Rob described.
This is the big win here. My input is purely to help give you full control of how you deal with all of these problems specifically for Heli with minimal impact or dependence on the rest of the code. My other observations and suggestions are just there in an attempt to spark ideas ect.
yeh, this is what I was getting at above. With the current setup I think we can just leave the pilot in control now.
Yeh, I think you are on the same page. The goal is to make sure we have identical or similar behaviour after these changes. My suggestion here is that the only thing that really changes is the automatic override of decent rate. If we leave this in pilot control as you suggest then we get almost the same behaviour and with a little pilot education there should be any issue.
It means that Bill does not need to try to build a nuclear reactor with a sowing kit… Ok, he does not need to try to do some tricky collective override function when the throttle hold function is pulled in flight. It gives him more freedom to get it right for “normal” operation.
Ah. Ok. I was afraid maybe I misunderstood. I agree 100%
Yeah, it doesn’t last long. And Rob will still be able to do the low energy landing.
I agree. I don’t see the usefulness of the descent rate, frankly. When any pilot starts auto training the first thing is to hover 3-5 feet and just cut it. Let the helicopter bleed off speed and set down by itself without using any collective adjustment. At 2 feet the alt controller will max it out on pitch and it will do the same thing. 2 feet is not a critical altitude to worry about. You can pick up any of these things and just dead drop 'em from 2 feet and it’s not going to hurt it. And the landing will be way gentler than that just letting it use up the headspeed and gradually losing lift.
So yeah, I’m onboard with it. Once we get this working then we can do auto code. Even the basic simple things like automatically managing the collective based on a height-velocity diagram to assist the pilot and buy him/her a precious few seconds to take over. If we’re in flight and TH goes on, we’re in autorotation and the autorotation library,or flight mode, takes over and decides what to do.
From 2 feet with auto code we can just freeze the collective and it will set the helicopter down gentle as a feather. My point was, that should not be in the spool logic - the spool logic just defines the state. Then let the state be handled by the autorotation lib.
I would suggest that the simplest and least restrictive option is to have the motors library continue to take collective commands as it normally would. That means we do not need to worry about deciding when to ignore the collective input and when we obey the collective input. That would mean that Bill does not have to do anything. I just need to make sure the rest of the code continues to fly the aircraft.
We are all on the same page, I am sure you both will decide on the most appropriate course of action.
All this conversation specially around the implementation of the autorotation, and although not directly related is to also throw to the ring if we should not consider having some IdleUp settings defined http://www.rcheliwiki.com/Idle_up_mode
Also, something else. Shouldn’t the range of the blade pitch angle be limited when Throttle Hold is engaged ?
That is pretty much the whole motivation of what Bill, Randy and I have been working on. These changes are all around acknowledging and supporting the need for aircraft to spool up and down and the idea that during that process they may be capable of flight.
This then provides a big improvement in flexibility for Heli to fully cater to the needs of the aircraft in the ways you are suggesting.
Initially we want to get as close as possible to the current behaviour. Then it is gloves off for Heli Dev’s!!
Ah, ok now I am tracking. What I didnt realize was that in addition to the I term and ghost handling being divorced from the spool mode, the altitude controller was also divorced from the spool mode. So yes, I agree that nothing else is needed for now and we’ll let the pilot maintain control. Now I just need to figure out how to get Leonard’s changes into my branch. Realized last night that it wasn’t as simple as cherry picking them.
Chris, I’ve done 100 auto-rotations with Arducopter. All in manual modes. Which, has to be the case in your two instances as well (switched to acro soon as you realized). What I was getting at, is that auto-auto-rotation is hopeless without rotor speed sensor and rangefinder.
This sort of thing happens all the time with Ardupilot. Nothing specific about this case.
Ok, I guess I’m fine with this. I made the decision to force a descent to avoid situations where an unaware pilot would leave it in a hover at altitude, or even worse attempt to climb, removing rotor energy faster. But if somebody else is taking responsibility for it and wants to go this way, that’s fine. We can train our pilots to work with the new behavior.
I totally agree with this, it’s the approach I had years ago in fact. Auto-auto-rotation has to be it’s own mode. Would probably look a lot like Land mode. At least initially.
I haven’t put any effort into it yet, because I think it’s nearly hopeless for a typical UAV-weight helicopter to auto-rotate successfully. The disk loading is quite high, meanwhile the rotor inertia effects don’t scale down well to small-size. Trying to get enough energy into the disk to arrest the descent is going to be very hard. Then consider that in many cases, your UAV isn’t flying over places where it’s safe to land. They don’t have the glide ratio of a plane which allows you some ability to pick a spot to land. With a heli, you’re landing, basically right where you are. I’ve put most of my energy into making the helis reliable in the first place, so it’s never been an issue.
I would be very happy if we could achieve, at a minimum, an auto-auto-rotation mode which does nothing but engage automatically when needed, and then use a rotorspeed->PID-> descent_rate loop which would attempt to maintain rotor speed. This would at least, in the case of a BVLOS flight, minimize the damage to the UAV and more importantly, the payload, to the minimum amount we reasonably can.
Perhaps a possible feature would be to rescale the “throttle” stick descent rate, where full up is 0 m/s descent, and full down is something quite a bit larger than the typical Alt_Hold descent rate. 10-20 m/s. This would allow a quasi-assisted auto-auto-rotation mode. If the pilot left the throttle in the middle, it would descend at a fast rate that might maintain rotor speed. But, they could attempt a landing by pushing up.
No! Please let’s not start using the illogical naming convention from R/C helis. The RC Heli world is a mess of really poor engineering, we don’t want to follow what they are doing.
And this is a great example. “Throttle Hold” does anything BUT “hold the throttle”. What it does, is cut the throttle. Why isn’t it called “Throttle Cut”. Or “Throttle Idle”?
Heck, what exactly does “Throttle” mean on an electric motor? There’s no such thing.
Interlock was chosen as it’s the proper engineering term for a control mechanism which removes power from a machine.
If we can’t clear this up with a glossary entry, then maybe at least go with some of the other things that Chris has suggested like “Flight Idle”, IIRC.
Yeah, we do. These systems have to be usable by your average UAV pilot.
No, please just do what Leonard suggested, just leave the collective in full flight control without any changes.
Yeah, but in this exact case, what the beginner pilot does not do, is keep feeding full positive up pitch to maintain altitude, and THEN it comes down with nearly no rotor speed. (leading to a tip-over, as you suggested above).
This seems to be the exact opposite of what you said above. Is it OK, or not OK, to drop the heli 2 feet with no rotor speed left for cyclic?
The result of my auto-descent rate, was that it bleeds out rotor speed, while descending. The makes sure it gets on the ground before all the energy is gone, leaving some left for cyclic control.
No PLEASE! This is not an acrobatic controller. It has some ability to do acro, and it does well enough at sport acrobatics. But let’s not further complicate helicopter UAV setup with non-sensical “Idle Up” terminology. What does that even mean? (Yes, I know what it means, but it’s nonsense to somebody not trained in the world of RC Helis). Nobody should suggest using these terms and functions, unless they understand how and why the evolved, and then come discuss what utility they present on a modern UAV helicopter with ESC governor and soft-start. The only remaining utility, is to change the head speed. Something very easy to set up with RSC_Passthrough.
Why?
I never bothered, because the “hover pitch” changes so quickly and drastically with even the slightest translational lift and rotor inflow velocity. You could try, but the value will be changing on about a 1-second time scale. So what is the point. Just let the auto-collective handle it, as it does now, quite well.
Go try flying in Stabilize mode, but do not touch your collective stick. Then tell me what “hover collective” is.
I practice them on FPV and I might do 30-40 of them in a practice session. Yes, they can only be done in a manual flight mode (Stabilize is better than Acro) and we have some ideas on how to implement it in the future. First modifying the throttle hold behavior so autorotation practice can be conducted without changing settings for the ramp timer. And then being able to practice recovering from a drivetrain failure from augmented modes.
Fully automatic autorotation will come after that, but will be aways away yet. If you recall I experimented with autorotation code in AC3.3.3 and we were not able to successfully land one autonomously except by using a dead man’s drop, which does not work for heavy UAV’s. Otherwise, with me on the sticks, I can autorotate a 32.8lb 800-class machine at 4:1 glide ratio and it’s not even a hairy deal. It’s all in the technique, which is hard to teach the autopilot. Bill has some additional ideas on how to teach the autopilot the required technique.
It’s not illogical, it well understood and documented in the RC helicopter world.
Our users are not computer programmers or engineers. They are pilots, and they like stuff pilots talk about. We can’t keep making ArduPilot so techie only a developer can set it up. We ran into this with Thunder Tiger because the setup of the system is so horribly “techie” that the average user can’t figure it out anymore. There is things like setting servo ranges from 1000-2000 pwm and people understand this. But then go to collective range and instead of percent or actual PWM, which people understand, now we have 0-1000 scaling. Which is again rescaled to 0-1 in the code. Since we’re already doing re-scaling anyway, why not make the setting something people understand?
Yeah, it all makes sense to the programmer or engineer. But try to rationalize it with the average user/pilot and you get looked at suspiciously like you’re not normal. Which, frankly, most engineers and programmers aren’t
We’re going to be making a long-term push to make this system easier to set up and use. We don’t necessarily have to change it in the code, but we can change the MavLink message to tell the pilot something they understand, at the least.
The main reason for lots of collective hunting in manual flight modes is headspeed too low. I have demonstrated hovering my piston machines at 3 feet in the wind, every bit as stable as full-size, hands-off in acro. Other than a little wind drift it looks like it’s in Loiter. But then, I’m running 450-500fps blade tip speed too, and only hovering on 4 degrees of pitch.
People, especially with electric, tend to run the headspeed too low with UAV helicopters. Which is great for flight time with electric. Not so great for overall performance and stability. It hampers a machine that should otherwise be able to cruise in level flight at 70kts at maximum takeoff weight to maybe only 40kts. And gives the pilot a workout trying to hover it in manual modes.
So an auto-tune on collective mid is not going to be that effective on heli’s. Especially ones like my gassers that can lift and happily fly away with their own weight in payload. And they might burn off about 15% of that weight in fuel burn in a one hour flight. So hover collective changes from takeoff to landing, changes with different payload - it is all part of flying a helicopter. And most helicopter pilots will not want the system doing some sort of compensation for it because in lifting heavy loads the pilot uses the pitch on the collective to determine how close we are to the performance capability of the machine at the density altitude that is present. Taking that away from experienced helicopter pilots would be a no-no. These things are not multicopters - they don’t fly like one.
Bill, I just dropped some comments on this PR, but to be sure you see them:
Hi Bill, I just tried this fix back-ported to AH3.5. It seems to have the desired effect that the leash head isn’t moving around. But seems to have the undesired side-effect that the copter does not stabilize at all. Seems there is some Rate activity, but no Stabilize activity. (ie: servos move to resist angular movement, but not to self-right).
I assume it’s the same for 3.6?
I think this needs to be improved. It’s probably not super critical, more of a UX thing. In the past, I had users complain that they aren’t sure their servos are working. You’ll notice that in AC3.3, I did a call to:
