Trad Heli Attitude controller requirements - Help Requested

ArduCopter Traditional Helicopter
162

The genesis of Spin When Armed was because users were arming, but leaving their throttle stick down so the motors are stopped. Then they would walk over, and accidentally bump their throttle stick. A multi can go from motors-off, to in your face in 1 second. So the Spin When Armed was created as a visual indicator to the user, that the copter is armed, so there is no misunderstanding.

Helicopters don’t really have this issue. It takes a while for the rotor to accelerate, at least if you’ve set them up properly. That being said, I don’t hate the idea of a “ground idle” type state where the rotors are turning slowly. However, this isn’t possible with heli ESC’s in governor mode as I understand it. Most won’t engage until 50%, and then they accelerate to 50% speed.

I’m not sure if I’m misreading what you are writing, but it sounds like you’re suggesting that when we are on the ground, and the rotor is not engaged, that we are “not stabilizing” ie: the servos are not moving? I’m very much against this if so. Is this what you’re saying?

163

Speaking of all this stuff…

I’ve just discovered what I believe to be a critical safety issue in 3.5 (don’t know if it was in 3.4 or not, it was not like this in 3.3).

If you have the heli on the ground, and you are in Loiter mode, rotors off, and the pilot moves the cyclic stick around, it’s apparent that the “leash head” is moving around. It’s possible to have the swash tilted all the way over, as it’s trying to fly somewhere, but can’t. I believe, though haven’t tested yet, that if you then start the motor, the helicopter will tip over and crash, or possibly leave the ground and zoom off in whatever direction.

I am very surprised, to say the least.

I assume this isn’t the case with multirotors, as somebody would have been hurt by now.

164

Rob, ground idle is used primarily to idle piston and turbine engines prior to engaging the clutch to get the rotors turning. It the stage before throttle hold is released to bring the power up slowly to get machinery turning. It will not be normally used by electrics.

Flight idle is used for warmup and cooldown of especially turbines, as two-stage engines need to have the power section turning at fairly good rpm to to prevent “blowtorching” the N2 engine stage. Flight idle is normally available at the bottom of the throttle curve (the H_RSC_THRCRV_0 point). The engine can be at full flight power within seconds, but the governor is not yet engaged.

Flight idle is also used (both in full-size and RC) as the minimum power setting that won’t shock-cool the engine, and eliminate risk of flameout, but allow autorotation without actually disengaging the clutch. It is used to make emergency landings where you can’t run the engine at rated power due to a mechanical issue (such as a blown N2 section or engine fire) but desire to be able to use what’s left of the engine for a power-on flare.

This terminology comes from the world of full-size helicopters (and turbine airplanes) and engine management.

Neither of these states really apply to electric powered aircraft. But Bill is designing them in to accommodate more advanced combustion engine machines. With electrics, once throttle hold is released it normally just accelerates up onto the governor (usually programmed into the ESC). There is no clutches to engage, etc… It is possible to use a flight idle with an electric by using the throttle curve. But the only real reason to use that would be for a pilot that is advancing to combustion engine machines and wants to practice engine management with a more forgiving helicopter.

I don’t think these changes will affect electric pilots at all - they won’t be able to tell any difference. But it does affect those of us that fly engines, as these “minor details” were often overlooked being the primary development effort is for electric and multicopter. As it is right now I had to “hack” a setup to even start a turbine engine with ArduPilot.

165

They are discontinued now. But they are a really good and stable controller, used almost exclusively in large turbine scale models. The problem with them is the PC software to set them up. It is not all that great. And they only have limited autopilot capability. They are more a FBL unit with a GPS so they can only do limited things like hover hands off, or fly limited waypoints. The scale people still use them because they are so stable, although more modern FBL units like the Mikado VBar are making their way into the scale world now because they are easier to set up.

ArduPilot is still viewed as one of the hardest of all systems to set up and get to work with helicopters. We hope to change that by Copter 3.7. And one of the things that needs to be addressed is some of the terminology used (not so much in the code), in the setup. People who have heli experience understand what throttle hold is. They do not understand motor interlock, as an example. So when the ground station announces “motor interlock enabled” for a fail to arm, this confuses people - “what is motor interlock”. If it stated, “throttle hold is off” instead, that makes instant sense to helicopter people and they know right where to look to fix the problem.

There’s a lot of little improvements that can be made like settings made in centidegrees could be made in degrees. Or throttle settings for the throttle curve instead of being in relative pwm values of 0-1000, could be in percentage throttle from 0-100% that people actually understand. I understand why the settings were originally made this way, but it can be improved going forward to make the user experience a little less daunting. And this was always the problem with the NAZA-H and Wookong-H too. The FBL manufacturers have made helicopter setup almost trivial and I feel ArduPilot has to catch up with that.

1 Like
166

So interesting, I recently set up a Brain2 on a Fireball. First time I’ve ever used a traditional FBL. I actually found the setup a bit tricky as I didn’t know much of the terminology. Just try to figure out how to program an FBL and a Futaba radio, together, based on their manuals which are clearly written by and for people who already know exactly what they’re doing.

So it’s all about what you’re used to.

ie: What is “AVCS Gyro”. I know now. But…

167

@Rob_Lefebvre we did find this issue in 3.6 and submitted PR 9298 which was merged for 3.6. This was not put into master because spool logic will fix this issue when it makes it into 3.7. We never backported for 3.5. If you feel it is necessary then we can but I think 3.6 will be released soon.

168

Futaba actually invented that term back in the days of the first tail lock gyro that actually worked. It stands for Angular Velocity Control System. It has stuck ever since in Futaba’s setup.

169

Thanks Bill. We likely won’t be moving to 3.6 for quite some time. Seems like this should be easily back-portable to our 3.5 branch which is based on Arduheli, shouldn’t it?

170

BTW, what ever happend to the issue with Ghost Copter being able to rotate without restriction relative the actual position? I never got resolution on this, though in my testing with 3.5, seems the angle is being limited.

171

@Rob_Lefebvre yes this would probably be a pretty easy fix to backport to 3.5. Do you just want to handle it on Chris’ ArduHeli repo or do we want to get Randy to do it on the Ardupilot repo?

So I am not sure about pitch and roll but the angle is definitely limited in yaw. We fixed it that in acro you couldn’t move the ghost away from the actual attitude while disarmed and armed up to the first time you go interlock enabled. I am not sure beyond that.

172

IMO, the loiter thing is a critical bug that should be fixed in 3.5. But it’ll be up to Randy.

I can try to do the back-port into our version of 3.5, then maybe I could PR it across to you guys.

Will also try to fix the post-landing hop fix.

173

Hi all,

I am working on the spool logic and I have a question about the best way to handle an auto rotation.

First some motivation:
The code attempts to handle the situation where the pilot is flying and accidentally disables the motor interlock. The current implementation condition is basically

If (!motors->get_interlock() && !ap.land_complete_maybe) {
pos_control->set_alt_target_from_climb_rate(-abs(g.land_speed), G_Dt, false);
heli_flags.init_targets_on_arming=true;
}

I am trying to completly remove motors->get_interlock() and ensure that heli has complete control of how it is handled from the motors library. To do this I need to ensure the general code provides the required flexibility and hooks from the motors library to handle all the required functions. I want to ensure there is still the ability to handle this situation effectively.

So my understanding of the problem:
Maintaining head speed is the critical factor. No head speed, no flying. We trade decent rate to maintain head speed. Slow decent rate, head speed drops, fast decent rate, head speed maintains or increases. The actual head speed is based on the average negative collective and the drag profile of the rotor.

Ok, so my concern with simply setting a negative climb rate:
This will run through a Position P -> Velocity P -> Acceleration PID nested controller architecture. With a request of -abs(g.land_speed) we are sure that we will get at least that decent rate but the actual collective position can vary greatly from negative to positive. My concern is two fold:

  1. The decent rate of -abs(g.land_speed) will not be sufficient to ensure we maintain a high enough rotor head speed to prevent the disk from stalling and preventing the pilot from recovering.
  2. Assuming the decent rate is sufficient to maintain head speed, there will be collective inputs from the altitude controller that will last long enough to reduce the rotor head speed below a recoverable level. OR the aircraft will enter this condition during a momentary drop in altitude that has already pre conditioned the controller to ask for positive collective and even with the decent rate request the collective will not got negative quick enough to prevent the rotor head dropping.

My question:
Assuming my understanding of the physics is ball park.
The steady state RPM of the head will be related to the steady state collective position and this will be a pretty stable relationship.
If the pilot holds a collective position that results in a particular minimum safe head RPM we will get a reasonably stable decent rate.
The decent rate can not be reduced below this value without reducing the head RPM to a lower unsafe value. Therefore this is the minimum safe decent rate.

So my question is why doesn’t heli have a specific parameter that defines the steady state collective position for auto rotation rather than specifying a decent rate that will result in an unknown and varying collective position?

Based on my limited understanding using a parameter like this would have a number of advantages:

  1. Heli would not rely on the vertical navigation controller design to ensure a safe auto-rotation.
  2. Heli would be able to choose to use a fixed collective value or a simple rpm based controller based on the setup.
  3. Heli could choose to make this work at all times independent of flight mode (or all non-manual collective flight modes)
  4. It reduces the risk of changes in the shared code removing the safety feature through a lack of appreciation of heli’s requirements.

Thanks.

1 Like
174

Mainly because there is no steady state collective in autorotation. The collective is normally feathered or even slightly positive and forward airspeed drives the rotor. When the flare is executed, again collective is still not used until it has lost enough speed to start increasing collective and use up the stored energy in the rotor. Small helicopters don’t autorotate all that well. My big ones can be easily flown over a 1/4 mile in autorotation and make several 360 degree turns. So the descent, or glide ratio, isn’t even the same on all of them.

Autorotation issues are only a problem in the altitude controlled modes because the autopilot tries to maintain altitude and stalls the main rotor. It takes a pretty steep dive to get it back. Where a normal autorotation is about 12-15 degrees nose-down @ 4:1 glide ratio, a recovery will require 45 degree nose-down dive to get headspeed back @ 1:1 glide ratio. It is the cyclic pitch and resulting angle of attack that drives the blades. Descent rate and headspeed is controlled thru the whole thing with the collective. It is very easy to overspeed the head in autorotation with sufficient forward airspeed.

Therefore all helicopters, full-size or RC, have what is called “best autorotation speed”. Just using the collective is called a “dead man’s auto” and usually ends with less than acceptable results.

All helicopters have what is called a height-velocity curve, more commonly known as the “dead man’s curve”. How the helicopter is autorotated depends totally on its speed and altitude at the time it is initiated. For this reason it is not something that the autopilot can easily handle. It requires a highly skilled pilot and lots of practice.

Bill and I have autorotation on our plate of things to do for heli. And the initial implementation of it will be an autopilot-assisted type of affair. The hardest part is designing how the autopilot is going to handle it in the initial stages of actual real-world engine failure to conserve headspeed and not have to do a recovery auto. And then control is handed over to the pilot to actually land it.

175

Leonard, on the above quoted, because autorotation is dependent on proper airspeed, not GPS or ground speed, it makes it more complicated to design a proper autopilot-assisted entry. If possible all autorotation landings are done nose into the wind to reduce the ground run.

Skookum Robotics has an autonomous autorotation feature in their SK-900/1000 autopilots. But it doesn’t work. It’s more of a softer crash than just letting it stall and drop. Which would not be acceptable (for me) in an ArduPilot implementation.

To try to answer your question, the sequence of events that needs to happen, assuming we are above the dead man’s curve:

  1. the collective is initially lowered to feathered
  2. the nose has to be pushed over to either build airspeed or maintain it - best auto speed for most RC helicopters is 20-25kts.
  3. collective has to be lowered to increase headspeed if too low.
  4. collective has to be raised to decrease headspeed if too high - headspeed too high reduces the glide ratio due to drag
  5. the helicopter has to be turned into the wind

Anywhere in the dead man’s curve, successful autorotation is not possible. All you can do is drop collective and use what you have to reduce the G-forces on impact. Without forward airspeed simply dropping collective results in fatal descent rates that can’t be arrested.

176

I think Chris has pointed out that this is a little more complicated than a one size fits all plus it is situation dependent. If the heli was close to the ground and the user accidentally hits the motor interlock switch, dropping the collective to enter an autorotational profile would slam the aircraft into the ground. However if the heli was high enough to enter an autorotational profile, then lowering Thebes’s collective would be ok.
So I think it was decided by Rob I assume that in altitude controlled modes, the controller should only command a slow descent so as to slow the autopilot in stalling the rotor and allow the pilot to come up on the controls.
I don’t know what the right answer is unless we have the aircraft look at altitiude but even that may not always be correct.

177

Yeah, we’ve discussed some ways to approach this. And I think we can do a better job than Skookum did if we don’t rely totally on the autopilot to land it. Just have the autopilot assist in the entry so when the pilot takes control he/she is not flying a stalled rotor. I’ve had them quit before in flight and you have about 2 seconds to take action if the heli has 20kts forward speed and is above 75ft AGL. I think we could increase that to 5-7 seconds under the same conditions. But it will require rpm sensor, and a failsafe to prevent entering unwanted autorotation due to failed sensor.

I think the important thing in the implementation of the spool logic is to set it up so throttle hold (motor interlock) can be used as normal in the RC helicopter world for pilots to practice autorotation procedure. That has never been designed into ArduPilot, and it is not that complicated to do.

The rest of any autorotation code will be heli-specific and will require lots of testing and development work because we have to design a dead man’s curve into the autorotation logic so it doesn’t do the wrong thing.

178

Ok, maybe I did not explain the problem clearly. At some stage in the past the question was asked:
“What happens if I accidentally pull the motor interlock during flight?”

Currently all that happens is the alt hold controllers are told to descend at abs(g.land_speed). From what Chris said this gives the pilot 2 seconds to react or bad things happen. So I am specifically talking about ONLY these 2 seconds.

We will almost certainly remove this code from all flight modes one way or another the question is how to best do it. Randy and I came up with two possible solutions the one I proposed above would be the simplest implementation to feather the collective and extend the time the pilot has to react with maybe warning messages to the ground station. The second is to implement a separate auto rotate mode that could be triggered by a fail-safe-like check.

In any case we need to find a way of:

  1. removing the 2-seconds-of-auto-rotation code from the flight modes.
  2. providing a structure that will let it be put back somewhere else.
  3. ensuring that Heli can have complete control on how it is handled to minimise the chances that other changes can crash an aircraft.

Based on this discussion and what you would like to do I think a separate flight mode that is triggered by a fail-safe may be the best approach. This would let Heli control exactly how and when that mode is triggered and also deal with all the complexity associated with extending the time the pilot has to retake control.

On the more enjoyable topic that I was not meaning to talk about…

So from what Chris said, there are two components that need to be managed airspeed and rotor head speed. A few thoughts that I am sure you have already discussed but I will say them anyway just in case:

  • When you don’t have a good airspeed sensor an angle of attack is often just as good.
  • If you don’t have an RPM sensor maybe you can live with a fixed collective setting.
  • On RC heli’s i imagine that the aircraft is not as prone to over speeding the head especially considering we normally run the head speed much lower than normal RC heli’s for efficiency.

Question: If this mode was enabled immediately the interlock was cut, could a fixed pitch angle and collective setting be defined that would result in a reasonably stable decent and head speed?

179

12 degrees nose-down and feathered collective (H_COL_MID) would work. BUT - this depends on altitude (height-velocity curve). At 75 feet AGL and the disc loading and headspeed most heli’s run, this would be great as long as the pilot has control immediately - either by re-enabling the throttle without the runup timer, or by taking over in a non-altitude mode to do a full-down auto.

There’s a reason the height-velocity curve has two components. One does not fit all.

Below 75 feet we have a problem. From a height of about 6-10 feet, engine failure or shutdown results in a pretty hard, survivable landing as the autopilot uses up stored energy to try to hold altitude. So nothing really needs to be done there. If the helicopter is in a forward flight profile, and is in translational lift, nose down, or doing nothing, is the wrong thing to do at that same altitude - a flare needs to be executed instead. The back elevator preserves the headspeed, the collective maintains the lift.

From 10 feet to 75 feet there’s not a lot we can do if the helicopter is not flying in translational lift. This is pretty much in the dead man’s curve, and there’s a reason it’s called that.

Translational lift speed is 16-24kts for all helicopters. Most RC ones are in ETL at 16kts. (m/s is about half of kts) due to typically lighter disc loading than full-size.

So let’s summarize in a very crude form:

  1. This should only apply to altitude controlled modes. Stabilize and acro should be left alone and do nothing. The pilot already has control, he/she can take care of it and we don’t want the autopilot doing anything weird
  2. We need a speed flag - the current dynamic flight flag doesn’t work here because it’s too slow. We need to put in an autorotation speed flag based on ETL speed of 16kts (8 m/s)

Speed flag off (out of ETL)

  1. Below ~20 ft AGL do nothing
  2. 20-75 ft AGL drop the collective progressively but no nose down. We are in the dead man’s curve and it’s going to be a hard landing. The higher you are, the more time the pilot has to react. At say, 30 ft AGL the collective needs to drop maybe a couple degrees as the pilot has time to re-engage the throttle as it uses up headspeed. If throttle is not re-engaged it’s going to crash hard. At 75 AGL we can drop collective, but not all the way to feather. This will delay the fall and give the pilot more time to react. But feathered collective results in acceleration of 32 ft/sec^2 minus drag

  3. 75 AGL feather it and put in 12 deg nose-down to build airspeed. The drag created from building airspeed slows the fall. A successful auto is easy from this height with a RC machine

Speed flag on (in ETL)

  1. <10ft AGL, just leave the collective alone and pull the nose up to 10 degrees. This will cause the heli to flare and try to gain altitude, but with simultaneous loss of headspeed it will land with considerable ground run. On grass with a little one it’s going to tumble. A bigger, heavier one will slide on the skids. But there is so little time for the pilot to react you have to take what you get.
  2. From 10 to 40 ft AGL feather the collective but don’t do anything with the attitude. Because we’re just doing to drop and flare it at 6 feet to build headspeed, then gradually pull pitch and set it down, and the ground run is going to be pretty significant. In the flare we’re either going to bang the tail stinger on the ground (due to too low of forward airspeed) or lower the nose and get a lot of ground run. But the helicopter will survive it.

  3. 40 ft AGL feather the collective and give us 12 degrees nose-down. We got room to play with here and can easily do a full-down auto with minimal ground run.

@bnsgeyer the above is based on lots of auto practice, primarily with big heavy UAV machines, and happens to be about the same height-velocity curve as for our Cabri G2 or 206B Jet Ranger, although the speeds with the full size heli’s are quite a bit higher (40+ kts - 60kts with the Jet Ranger), and the disc loading on the full-size is quite a bit higher. But the full-size is also running blade speed of 650 fps. With RC we are only at 450 fps. People that run excessively low blade speed below 450 fps with RC are going to have less than acceptable results with the above.

So would like your thoughts on this, as to whether it would be acceptable to use Leonard’s idea, or wait until we can do proper autorotation code to build-in the required height-velocity curve.

1 Like
180

@ChrisOlson thanks for the great information. I think until we have time to think about this more, we should try put a bandaid on this like has been done until now. I would like to get spool logic squared away and see what it will look like in its final form.

So I think I have a solution to this. For non manual throttle modes, a flag can be set to inform the motors class of this. Then the motors class will know if it sees the motor interlock disabled and the collective is above collective lower limit then it will perform a collective schedule that will be slow initially to allow the aircraft to descent without losing too much rotor speed but then ramp down quickly to collective lower limit or some specified autorotation collective value. I think this would be a little better than the current implementation of just a slow descent rate until it stalls the rotor.

1 Like
181

To be clear, this is a functionality that we should not revert, as we currently use it. The situation is that there are cases in operation, where we want to land, but want to remove rotor speed from the helicopter before touching down. This might be in cases where there’s some issue with the landing, such as weeds/grass etc, that will be hit by the tail rotor. Or perhaps a physical of PID tuning issue with the copter where we don’t want to get too close to the ground with full rotor speed.

In that case, the user can hover about 1-2 feet off the ground, and then throw the motor kill switch. The helicopter will do a controlled landing, and shed rotor speed on it’s way down.

Simply feathering the collective will not work out the same way, as the descent rate will not be defined or controlled. It could rise, it could fall… It could rise and then fall…