Trad Heli Attitude controller requirements - Help Requested

Always good for a dig eh Olli?

Your comment isn’t very helpful, as you have misunderstood what I said. I think your zeal to find something to dig at is affecting your comprehension of the problem.

Yes, but it’s not the same as the Integral in a standard PID controller.

The Climb/Descent Rate is not perfectly reliable as it gets fooled easily.

ie: Say a Helicopter which requires 5° collective to lift off.

Pilot inputs 2° collective while it spools up. As the rotor comes up to speed, it builds a pressure bubble under the copter. The Baro picks this up, and assumes that it is falling.

Alternatively, any heli, spooling up with negative pitch. This creates a negative pressure under the heli, making the system think it is climbing.

The EKF will use the accels, and cancel the baro error in the short term. But in the medium term, the baro error will dragg the altitude error up.

That’s an interesting point. Is this more reliable on landing because the rotor is already spun up and you are looking at it from a state that already accounts for this. Thus we are more susceptible on the take off if the rotors are starting from a static state?

Well, it’s not really more reliable on landing…

So, if you watch a heli landing very carefully, you will see that they tend to decelerate, and nearly stop, as they approach about 1 rotor span from the ground. They pause, and then continue their descent, often more slowly than before.

This is not programmatic. Well, we do have two programmed descent rates. One is during normal flight, and then there is the “final descent speed” but that is normally switched at 5 meters or so, I can’t remember what the default is.

The pause at about one meter, is because the baro is being affected by the downwash pressure bubble. It causes the system to think that it is descending faster than it really is. So the controller stops the descent. Since the altitude has stabilized, so does the pressure bubble. Then, the system realizes that it is in fact not descending, and resumes it’s descent. Often at a slower rate, as it’s a sort of natural balance between the actual descent rate, and the increasing pressure as the distance to ground closes.

Most multirotors do not experience this effect, as the baro is located above or in line with the rotor disk.

So it’s not more reliable on landing. It’s just happy chance that it does something we actually like, and so nobody talks about the problem.

I’ve never had a problem in strong wind at 1 lb/ft^2 disc loading. Like a NACA4412 will fly (not stalled) to -5 AoA, but that does not mean it will make the helicopter fly using that airfoil at -5 degrees. It only means the airfoil is still in a region of AoA that creates lift so it is not stalled.

So I think using the H_COL_MID param is still the most logical even with those types of airfoils. Even if the helicopter does fly at zero it’s not going to fly well at all. And since what we’re looking at doing is turning on the features in the attitude controller at the last moment, if H_COL_MID is 1500 and it reaches an actual of 1501 to trigger it, I can’t see that even with the asmmetric airfoils that it’s going to suddenly build up and cause the heli to flip over. Or the heli take off without ever activating it. I would go so far as to say that would be a feat you would have to deliberately try to achieve. If someone could demonstate otherwise with a real-world helicopter I’d be glad to say I"m wrong.

As a note, I do kind of like the asymmetric blades as I think they’re a little “cleaner” aerodynamically than symmetric airfoils when operating at a given AoA to get the same lift with either. I’ve had very good results with them (aside from the fact they were some cheap Chinese blades I got on eBay for $22).

1 Like

Rob, ah… I got the 700 sitting on the table in the hanger because it’s being flown this afternoon. Out of curiosity (been a long time since I set it up) I set servo man to 3 and checked the blade pitch with my gauge. I have it set to -2 at H_COL_MID. I don’t remember who told me to do that. But now that I think about it, one of our users, Jakob (I think it was) set up a 450 or something with asymmetric blades on it and I think he did that too.

Maybe that should be put in the wiki? H_COL_MID set to zero pitch for symmetric blades, and zero lift for whatever airfoil you’re using for asymmetric? Then if for sure should not be an issue. I think the code figures that param to be zero lift anyway for things like collective yaw torque et al.

1 Like

Well, but that’s the problem. Some parts of the code that are looking at the COL_MID number, are using it for things like torque calculations. Like COLYAW. I believe that the mininum torque pitch of asymmetric blades, would be 0 degrees, not -2. I don’t have any data on this. It’s my supposition, based on the thinking that 0 degrees would have the airfoil profile at it’s “cleanest”. So it would have less drag then it does at -2.

But I’m not sure. There are two things that cause drag. One is profile drag. The other is the induced drag, or basically, the work being done on the air. At 0 degrees, I suspect the profile drag is lowest. But it will be doing some work on the air. So…

Depending on how complicated we want to get, we could possibly need another number which represents the zero-lift point. And then… how would anybody even determine that? Airfoil plots would be the only way.

And, I’m really unsure about using the COL_MID to switch to full-I-term. That would mean that if you’re spooling up with the stick “near” the middle, but maybe slightly above, as would be very common, you would get I-term build up while the rotor is running up?

Hi oliw42,
Looks like you have done a lot of work on that controller and have done good job of making it available to the community. Well done!!

I agree that a heading hold PID controller like ours will inherently have overshoot and bounceback when excited with a step change. That is why Arducopter has a Jerk and Acceleration limited input shaper. The quick look through your links suggests that you added acceleration limiting on your rate request in a similar way. Is that right or did you do more?

We also have acceleration limited angle loop P controller that reduces overshoot and bounce back when recovering from large disturbances as opposed to user inputs.

So are we both referring to the same basic knowledge?

Thanks for posting the links.

1 Like

I believe you would. But would it actually create a problem at that point? If you’re into the positive collective range on the ground with a spinning rotor you can’t just stand there and watch to see what happens. You have to be ready to fly that helicopter. So if it starts to tip due to wind or I-term buildup, the pilot has to counter it.

My thinking is that flying any aircraft is a procedure of things that must be followed and there are specific actions you take that can be wrong or right. It’s like spooling up a PT6 to takeoff power - the procedure is to smoothly advance the throttle and check the EGT and TI. The momentary over-fuel of the gas generator sends the power section to 105% torque and then it settles down to 100% and the EGT drops back into the green. And then you release the brakes and start your takeoff roll. Improper procedure would be to let the aircraft roll while advancing the throttle and hope you get the EGT and torque nailed before rotation.

With ArduPilot, taking off in Acro, if the proper procedure is to hold collective slightly belown zero during runup, and when runup is complete start advancing collective, then that is the way to do it. Improper procedure would be to advance into positive collective range during runup and hope for the best.

Any aircraft I have ever flown is a system of checklists and procedures, combined with accumulated pilot skill.
The commerical multi manufacturers have attempted to make multi’s “foolpoof” so anybody can fly one and call themselves a “pilot”. I do not believe helicopters to be in that category of aircraft, nor do I think the software can be written to attempt to put them in that category. The software needs to be solid and predictable (which is what I liked about Bill’s code). But if you try to make it foolproof a fool will find a way around it.

Maybe the COL_MID is not the thing to use. But I do believe it would work way better than it does now.

Chris, I would like to agree with you. But it’s not the reality that UAV’s are currently operating in. Target salary for a UAV operator is $30,000. That’s Walmart Greeter money. Sad but true. If helicopters have any hope of market penetration, then they need to be as foolproof as possible. I don’t want them to remain this mythical beast of legend, because it would deny the industry the very important benefits they offer. Simply put, no other VTOL-capable aircraft can match their speed, range, duration, payload and wind tolerance abilities.

Now, I still haven’t read the middle portion of this thread. I might be missing what is happening here. My perception at this point, is that the plan is to get rid of the integrator leak, and the dynamic flying check, etc. And just switch hard to full I-term and attitude integrator lock as soon as we have some guess that we are off the ground.

If that’s what we’re talking about… I’m missing the explanation of why we would move away from something that works so well, and so simply, and so elegantly, and expose ourselves to all these problems.

Well, from what I understood we were only talking about acro here and the current problem it has for some users on takeoff with unexpected sudden attitude changes. Leonard was looking for an “indicator” that could be used to let the PID controller loose at the last second before takeoff to get that problem under control.

I do not think the Stabilize code needs to be changed at all. A helicopter does not need I term to hover. It only needs it to cruise in forward flight. And a flybar doesn’t need it all any time. All it needs is VFF.

1 Like

Ok. I certainly don’t want to speak for everyone.

Let me summarize where I ended. I’ll go over both modes with each state

Acro:
Unarmed: ghost locked to current attitude and I terms zeroed
Armed, landed: ghost locked to current attitude and I terms zeroed
Armed, not landed: ghost released and I term released
To go from an armed not landed state to an armed landed state, ghost will be decayed to current attitude and I term decayed to zero

Stabilize/Althold:
Unarmed: I terms zeroed
Armed, landed: I terms zeroed
Armed, not landed: I term released
To go from an armed not landed state to an armed landed state, I term decayed to zero

The transition from Armed landed to armed not landed depends on the criteria used to indicate takeoff.

So to confirm your perception, yes that is where I guess Leonard and I ended up. I’m not convinced this is the answer but am not adverse to trying it. I like the leaky integrator idea while on-deck and during transition cause it provides some short term attitude retention which isn’t a bad thing for transition.
Rob, I’m not sure how many users first understand and second are utilizing the leaky integrator with the ILMI parameter. I think many like Chris, have ILMI set to zero and leak off all of the I term. Obviously you incorporated the ILMI parameter to be able to retain attitude error on the ground, during transition, and in low speed flight. So effectively with the ILMI used as intended, the implementation above is pretty close except the implementation above doesn’t allow I term to build while landed and yours does but only to ILMI. Do you set up your heli’s with a non-zero ILMI? Just curious. I would assume you use this as designed.

Unfortunately this ground/air transition flying qualities is a matter of pilot preference. From what I understand of FBL 3 axis gyros, they incorporate a slower (5-7 second) integrator leak and many pilots coming from that experience probably will prefer it. As I think I do.

Right or wrong, It appears to me that Leonard is looking to modify the attitude controller for Trad Heli. @Leonardthall are you looking to incorporate the necessary state machines in the Heli_Stabilize_run and Heli_Acro_run routines to make these behaviors happen?
If this is happening then lets(Trad Heli Community) shape this the best WE can. I’m just giving my opinion but I don’t want to be the only one.

I apologize if I have dominated this discussion with my ideas.

1 Like

Hi Bill and also Chris.
Since you Bill turned up at the Trad.Helicopter part of Ardupilot I see real progress since 3DR stopped supporting the Devs. We Heli lovers thought Trad Helicopter is dead at this website. Robs FW 3.3.3. is fantastic. But let us move on now!
Again I am to old for helping you but I am confident now that the next few weeks will be a big step forward with the help of LeonardtH… Some persons of course want only the progress for the commercial interest guys. But I am a hobbyist and I am very happy what I see from you Bill and Chris.
Thanks a lot.

Bill, I am actually retaining .02 I term as of my last param file from the FBL heli dated June 7. But I can’t say it makes any difference (that I can tell). I think that was the day I flew that helicopter with the rate I turned completely off to see what it would do, and had a bit of an issue flying it in Auto that way. But it was fine in hover, even in Loiter.

It seems the biggest issue is when to let the ghost loose during transition in Acro. That’s a problem that could bite, and there was a lot of concern over the swash behavior in Acro. Does the attitude controller really need the rate I to go to full lock before the heli is moving? I just have not seen a problem with the way that leaky rate integrator works.

I dunno. Might be trying to fix something there that’s not really broke. Remember when I was testing that, rocking the helicopter around on the ground trying to get it to build up and tip over? I think I figured out that it really had to be turned up quite aways (like 0.1 or so) before it starts to cause a big issue that can surprise the pilot, because if you’re watching your disc it’s easy to counter it. The ghost aircraft, though, is a problem because the pilot does not know where it is if he/she inadvertently moved it.

[quote=“Leonardthall, post:69, topic:18281, full:true”]I agree that a heading hold PID controller like ours will inherently have overshoot and bounceback when excited with a step change. That is why Arducopter has a Jerk and Acceleration limited input shaper. The quick look through your links suggests that you added acceleration limiting on your rate request in a similar way. Is that right or did you do more?[/quote]yes and no. In chapter 6.3 I outlined what I think are the two generally possible approaches. I did both, pl see the last paragraph of chapter 6.3.
From my tests on the commercial gyros I had at hand at this time (about 5 different ones, from medium priced to cheap) I concluded that these use method one, an input shaper. I know that you also have all sorts of input shapers, but not all shapers are equally good for the task at hand. I tried some (but don’t ask me which ones, that’s more than 5 years ago LOL), but settled for the simplest and most text-book like, namely a simple LPF. That’s not exactly an acceleration limiter. I’m kind of convinced that method one is also what is used in the FBL units, at least in those available 5 years ago (I have not followed that topic since then, so my comments might be outdated).
As said, I also did something along method 2, and essentially everyone liked that method better, and in fact liked it much. It had a slight weakness at low commanded rates, so I wouldn’t claim it was perfect, but I think this could have been solved. I just went away from that project so it stopped at version v0.16. I would have to dig again into the code to retrieve what it was. Implementation-wise it was very simple, but it wasn’t very obvious to me at first. Something like that the step just goes to the I term or so. But as said in chapter 6.3, one can think about many approaches along this line. Just a matter of “creativity” :).

[quote=“Leonardthall, post:69, topic:18281, full:true”]So are we both referring to the same basic knowledge?[/quote]I can’t tell. I just see the info provided here, and I see conflicting info. If yes I would have thought that a yaw-back-bounce issue would not be a topic at all, and especially not have been named as the most obvious hint that something is fundamentally wrong with the current structures. Either the available structures&parameters are (often) just not used properly or are indeed not adequate. I can’t tell.

Maybe not totally appropriate, but personally I think that the approach to use AP as a companion to a FBL, as it was done some time ago (by tridge? can’t remember exactly) would be most profitable for Ap.These FBL guys have now for 15 years or so spend all their resources on getting this part right, I think it would be difficult for the AP community to catch up here.
EDIT: I guess that’s what I meant: http://diydrones.com/profiles/blogs/canberra-uav-demonstrates-helicopter-flight-with-downstream-fbl?id=705844%3ABlogPost%3A2210017&page=6#comments3

Cheers, Olli

@FRED_GOEDDERT thanks for the kind words. I find it hard to believe that trad Heli will make any good progress without commercial interest in supporting a full-time developer. The developers on the multi side are moving at such a fast pace that it makes it difficult for anyone but a full time Heli developer to be able to catch all the bugs on the heli side.

I think you are doing a great job too Bill. If we can bring heli up to a point where it is operating consistently with the multi code and the multi code accommodates the heli code then the support for heli will become much easier and time efficient. It will also be much easier for the developers working on the higher level code and capabilities to make changes without breaking heli. There will be a hard hump to get through then things will become much easier.

So onto what I am suggesting we do from here:

I would not advocate doing this unless we can establish the leaky I is not needed or we have a better solution. I would suggest we move forward gradually but purposefully while keeping as much of the code the same as possible. That way we maintain a safe base for people to test fly without re-tuning.

I would suggest that we can hold the I term zero with or without the leaky I term code so there is no reason to remove it. This will let us test the code without exposing the pilots to the risk that a non leaky I term will significantly change the flight behaviour.

The changes I suggest initially is:

ACRO
Unarmed: ghost locked to current attitude and I terms zeroed
Armed, landed: ghost locked to current attitude and I terms zeroed
Armed, not landed: ghost released and I term released using the same leaky I term

My understanding is the last state is what we currently have in the first stages of take off so we can continue to use the same code and checks there after. This keeps the risk to a minimum while attempting to address some of the major issues the heli users are facing. Correct me if I am wrong.

Stabilize/Alt Hold:
Unarmed: I terms zeroed
Armed, landed: I terms zeroed
Armed, not landed: I term released using the same leaky I term and code

This also lets us look at the issues associated with the threshold where we release the I term with the knowledge that the leaky I term will give us some safety margin because it will be the same as what people are used to. We can then get feedback and evaluate our approach and threshold in the context of the wider user base.

Once we are happy with the take off procedure and state machine we can start working on the landing.

In the background I will continue working on getting the pid rewrite with the notch filter done. But we should get the take off stuff done and tested before throwing a new variable into the mix.

I am very mindful that crashing a heli is not the same as crashing a multi, even a large multi. I want to minimise the risk of a tester having to deal with that.

Yes, I do.

I definitely think there is value in playing with the leak rate, as I’m sure it’s not optimized as it is now. So I like that you made that a parameter. And I think there is value in working on improving the Flying/NotFlying estimator, so that we can stop the I-term leak earlier possibly.

So how would the swashplate look if you move the heli around? It basically won’t deflect at all? Or it will only move in relation to the live rate? But soon as the heli stops moving, it won’t be trying to get back to where it was? This isn’t a technical thing, but I would prefer it indicates it is trying to get back, and then decay to the new location. I think it looks natural, and it’s what people expect to see from FBL controllers?

I’m fine with this, as this is the intermediate state when the user isn’t actually moving the thing around bench testing it.

Fine. Though are we still talking about unlimited angle error?

I think the major issue is the handling of the ghost in ACRO. So I would propose that we don’t touch how we handle the I term just yet. I do like the flexibility of the current code in that you can choose to leak the I term to zero or to some lower value (ILMI) than what you would need in forward flight (IMAX). Thus you can retain some I term on the ground with rotors turning. The biggest issue I had was that, in my opinion, the I term was being leaked too quickly so I added a parameter to allow users to adjust the leak rate. Thus you could set ILMI to zero and with the slower leak rate you got a short term attitude retention.
The big question is how to handle the ghost in ACRO. Working on this and then moving to the I term might be better plan? We can also get the decay of the ghost right for going from the not landed to the landed state.
Here is how I think that would look. Thoughts?
ACRO
Unarmed: ghost locked to current attitude and I terms zeroed
Armed, landed: ghost released but leaked to current attitude and I terms released but leaked to ILMI (I term as currently implemented in code)
Armed, not landed: ghost released (have to determine criteria) and I terms released but leaked to ILMI until horizontal speed > 1m/s (I term as currently implemented in code)

Stabilize/Alt Hold:
Unarmed: I terms zeroed
Armed, landed: I terms released but leaked to ILMI (as currently implemented in code)
Armed, not landed: I terms released but leaked to ILMI until horizontal speed > 1m/s (as currently implemented in code)