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.
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:
@Rob_Lefebvre I was not involved in the changes from 3.3.3 to 3.4. That is when your statement was removed and it became the way you see it today in 3.6. We would have to ask Leonard and Randy why they removed that statement. I guess I am wondering why in an unarmed state, this statement is critical. If they want to check their servos, they should go to stabilize and sweep the controls or better yet set servo_test param so the servos do a sweep on boot up.
Please take this in the good humour I intend it to be:
I have got to laugh here as this is all exactly the same as multirotors. We even have settings in place to deal with these issues. We can turn off the learning so it is set constant or we can let it learn but not save at the end of a flight, or we can set it to learn and save. This lets the pilot choose the approach.
So the reason we did this is so that when you switch from Stabilize to Alt_Hold based modes the aircraft doesn’t climb or descend. We let it choose between learn and learn+save because at the end of the flight the throttle can be at 1.5 times the take off setting with a full batter (or lower if you really stuff up). On my heavy lift aircraft the throttle can be a factor of 2 or 3 times different with and without load. All the same stuff. (we even get lower current draw in forward flight).
Remember, having a VERY friendly laugh here!!!
I am also not saying the heli users should or should not do anything. Just saying there is some thought and flexibility behind the way we have done it that can be used to accommodate heli users needs. IF you deem it appropriate.
We have one helicopter that we fly at 7000MSL with a bambi bucket on a sling load. It is about at the limitations of the main rotor at that altitude on a hot day if it’s humid. On a cooler day with less humidity it’s not an issue. So the pilot uses the collective as the gauge as to whether to lighten the load or not. It tells him exactly how much pitch he’s pulling to lift it. The second to last tick mark on the collective is 85% and that’s what we use for the gauge.
In full-size you have a torque gauge (turbine) or manifold pressure gauge (piston) to determine whether a sling load is safe to lift and fly with. Since the power loading is usually much higher in full-size, shaft power is the limiting factor in how much the helicopter can lift. In RC, we typically have higher power to weight ratio than full-size so the limiting factor becomes the main rotor and how much thrust it can produce. We got the power, but we don’t have the 650-750fps blade speeds full-size have. So thrust is the limiting factor. The only gauge we got is pitch, and the ground station has no such thing, so collective position becomes the “gauge”.
With helicopter there is limitations at maximum payload where it’s safe vs unsafe, and that’s usually around 85-90% pitch. You can lift the load at 100% and fly with it, but it’s not safe because turbulence or a downdraft can bring the helicopter down before you get it into forward flight and start producing more lift. A multicopter can’t fly if you’re using 100% throttle to lift a load. You got no overhead to stabilize it.
That’s where I was coming from on that statement.
Further complicating it is that not all pilots are going even set up the collective range the same. Some like considerable negative collective so normal hover range is ~75% stick. Others don’t like to use a lot of negative so they’ll set it up with maybe only -2.5 deg. Others like the way full-size is where there is no negative collective so they’ll set the bottom range to zero and enjoy a collective response that is much smoother and easier to fly. So for a pilot that runs -8 to +11 if you mess with the center collective position and make the collective non-linear the pilot is going to be VERY unhappy about it.
@Leonardthall despite my explanation of several reasons I would never use it, this doesn’t mean others won’t use it. If their collective pitch range is setup suitably so it can work properly, go ahead and put it in.
Would it adjust the IM_STAB_COL’s? I ask that because for folks that like to run a quite radial 3D pitch range, one of the purposes of the IM_STAB_COL’s is to be able to flatten the pitch curve around hover to make the helicopter easier to fly. When there is 18-19 degrees of pitch range the collective is VERY touchy and hard to hover. That’s why those settings exist to tame it down a bit for Stabilize. And they can be moved around a bit to adjust where the machine hovers as far as stick position in the Stabilize flight mode.
Personally I don’t use those settings either. I use my Idleup’s instead for varying loads. But Idleups are also not in ArduPilot - for that you need an external governor that supports the feature. If I take off and the collective is too high I simply switch to the next Idleup and bring it down to around 60% before switching to an augmented mode. Which also has the advantage of maintaining fully loaded cruise performance at maximum takeoff weight the same as for empty weight.
But there again, that’s just one more thing RC helicopters can do that multicopters lack
My point was not that there are not significant differences in the aerodynamic complexity of collective heli vs simple thrust of a multi.
My point was with multi there is the camp that says “I want to know what the actual throttle setting is because… so turn that automatic crap off!”. Then there is the camp that says “I fly all the time in Alt Hold and I don’t like it when I have to adjust my throttle position when I switch to Stabilise when hovering”.
So from a wider code perspective we have 4 inputs that we use to control the aircraft, roll, pitch, yaw and thrust. From the perspective of the code there is no assumption that hover throttle (or collective) is the same for all types of flight. We do record the throttle in a stationary hover to help remove jumps or twitches when people switch from Alt_Hold to Stabilise in a stationary hover and made sure that it could be disabled to accommodate people like yourself
It maybe worth stating this just in case it isn’t obvious.
The general code assumes that the roll, pitch, yaw and thrust settings result in approximately linear response from the aircraft. The motors library should attempt to linearise the ‘plant’ or aircraft dynamics as much as possible to get the most out of the aircraft. Of course if it isn’t perfectly linear that is fine you just need to ensure the PIDS are stable at the highest gain points on the curves.
I do think it could possibly be useful for many people that fly with static loads. I guess I was more curious as to how it would be dynamically adjusted to account for the custom pitch curve that some use with the IM_STAB_COL’s. By setting the two center IM_STAB_COL’s closer together in value this will flatten the pitch curve in the middle for folks that use a lot of pitch range. And can set the IM_STAB_COL_1 to reduce the amount of negative pitch that is set up. This makes the helicopter easier to hover, but it only applies to Stabilize.
Again, I prefer a linear collective response as the engine throttle is connected to the collective percentage with the throttle curve. If the collective out changes, it also changes throttle setting, even if the stick doesn’t move. This is all perfectly fine in flight if the throttle curve is properly tuned. But for landing and takeoff in Stabilize if the collective curve is steep at the ends and flatter in the middle it changes the whole spoolup/spooldown profile as to how fast the throttle servo responds vs collective movement. And if the bottom of the collective has been adjusted with IM_STAB_COL_1 it doesn’t allow a flight idle position for combustion engines. Since flight idle is the transition between ground idle, engaging the clutch and getting transmissions turning, then used for warmup of engines this has to be pretty smooth. It takes a little manipulation of the throttle for engaging the clutch so as to not get smoke coming out of the clutch from slipping it too much during initial spin-up.
The second stage is bringing engine power up on throttle curve until the governor takes over, which happens at a percentage of governed headspeed and minimum throttle. Then once it engages it takes 10 seconds to ramp to governed speed. It uses the throttle curve for feedforward for faster governor response, and there can be no settings that cause it to drop out in flight.
The point is, there is so many different types of setups in helicopters, some are electric and simple like multicopters, others are quite complex. It’s hard to make any feature that manipulates throttle or collective fit all. Because on some helicopters you’re also fiddling with the throttle settings if you manipulate collective curve. And the pilot may land and suddenly find out there is no flight idle because the system adjusted the collective position.
I think the majority of our users fly simple electrics, probably work fine. Those who fly more complex and advanced helicopters wouldn’t use such a feature.
My point is that I think trying to “learn” a hover throttle position on a helicopter is essentially useless. Yes, multirotors have similar effects from translational lift, etc. But the effect is about 10 times stronger in a helicopter. Any attempt to learn is quite likely going to induce oscillation between the physics, the learning code, and the pilot.
And I don’t see the point. In my experience working with UAV helis, and training people how to use them, even an accomplished and experienced UAV multirotor pilot, is completely overwhelmed by how “active” the collective pitch is on a heli.
Alt Hold is the “most manual” flight mode that we enable on our systems.
Meanwhile, skilled manual helicopter pilots have no problem at all dealing with it, and don’t need assistance. I vote for leave well enough alone.
[quote=“bnsgeyer, post:202, topic:18281”] I guess I am wondering why in an unarmed state, this statement is critical. If they want to check their servos, they should go to stabilize and sweep the controls or better yet set servo_test param so the servos do a sweep on boot up
What you suggest makes some sense. However, I received complaints from users. And I have to agree that it’s nice to see those servos moving as you walk the heli over to the launch area. If we compare to how other FBL systems work, are they ever in a state where the servos don’t move? No. So it also gets back to “being familiar to RC heli users”.
And like the auto-descent thing, it all has to be viewed through the lens of “the least wrong thing to do”. Let’s say somebody accidentally had a mid-air disarm, for some reason. And I have had that happen twice due to bugs in the landing detection code. With the way things were, at least the helicopter will attempt to stay upright on the way down. In both cases, this limited the damage from the impact.
What is the cost of having that line in there? An extra line of code? We have thousands of lines of code for pet features that nearly nobody uses. You can’t even buy an external tail gyro anymore. But we have support for it in there.
I was looking at the way multicopters do this and it is over-simplistic compared to what we already have in heli. What we have doesn’t do it automatically, but it adjusts both the curve and hover point. You can’t change the hover point without changing the curve, which would turn it into a non-linear setup for one that is set up linear. Which would be really bad.
So I’m afraid I have to agree. If it is thought this is a useful thing, have at it and see if you can make it work. But at least leave a way to totally disable it because the added complexity of helicopters simply does not lend itself well to things used in simple thrust machines with fixed-pitch. About the same as in the fixed-wing world, going from simple fixed-pitch airplanes to turboprops with constant-speed propellers. Takes a whole new regimen of training for the pilot to fly a complex airplane - and it’s going to take a new training regimen for the autopilot too to adapt this to helicopters.
When we put Rob’s descent feature in for low altitude hovering autorotations, here’s why it works so well. I did some work on the 716 and had to test fly it. So before I brought it in I figured I’d demo some hovering autos from 12-15 feet or so. This is a fairly heavy helicopter in the 3D world at 14 lbs (about double the weight of a normal 3D machine) running very low headspeed for a 700-class. This is what the autopilot can and can’t do when we do this code. Notice how the descent rate is almost linear for a good auto just under the dead man’s curve, but it does use all the collective if done properly.
I honestly don’t think ArduPilot’s altitude estimator is all that good (the ground station was showing minus 12-31 feet for most of this, for pete’s sake), and there’s just no way it can do The Smoothie.
It is very interesting seeing the way the energy bleeds off!
Based on what I know it takes to make plane land well, and what I have seen from the altitude estimate and baro measurements (especially in hover and near the ground), I agree you need a lidar to have any hope automatically timing collective input with the landing.
I still think it should be possible with a rpm sensor and lidar to do an auto-rotation automatically to a basic get-it-down-safely level. However I think you should consider it a long term project and focus on making sure the aircraft can be flown safely by pilots who are doing everything right. Then look at what you can do to mitigate risk after that.
Autorotations from hover are very difficult because it’s all about conversion of energy. The vertical component is less than the horizontal component in flight. And converting the horizontal component to lift is quite easy. There is no room for error when there is just the vertical component. So all I see the autopilot being able to do is try to maintain a descent rate from a low altitude hovering profile and try to maintain it until it runs out of lift. And hope the altitude wasn’t too high so it runs out before touchdown.
And it seems no two of them are the same. With the same helicopter, if I go to Idle2 at 1,750 rpm it’s fine from 20 feet in a hover entry. If it isn’t moving (forward flight) it has to be at 40 feet above that. From 20-40 feet with no airspeed is the “dead man’s curve”. Can’t put it into a dive fast enough to get any more than the vertical component because you’ve already lost 10 feet and critical headspeed in the first second in an actual engine-out emergency before you can react. This is where the autopilot can help. It doesn’t have to land the helicopter. Let a trained pilot do that. Just assist with the reaction time, and design it so the pilot doesn’t have to do anything more than move the sticks to take over manual control (like Pos Hold does).