Trad Heli Attitude controller requirements - Help Requested

ArduCopter Traditional Helicopter
73

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
74

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.

75

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.

76

[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

77

@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.

78

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.

79

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?

80

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)

81

I would cast my vote for this scheme as a great first step for testing. The highlighted part above would be kind of like how a flybar acts on the ground when it’s running up which would be really cool for a FBL helicopter when compensating for wind, tilted takeoff pad, etc…

82

Hi olliw42,

Yes, I can relate to the challenge. We went through a similar process back in the 2.7 days (probably 5 years ago for us too now that I think about it, time flies) with the early APM2 boards. Low pass filters you discribe result in large errors with high inputs and slow response with low rates. Hard to make feel good.
Switching between out of heading hold results in poor slow rotation performance and little kinks as you switch between states. Gives the pilot an unsettled feeling and is both sloppy and over aggressive at the same time. It looks good to start off with but that nice feeling is elusive.
Acceleration input shapers work well but feel twitchy or a little sharp around mid stick. ACRO pilots don’t mind it but doing smooth transitions and flying smooth and slow is harder and feels unnatural.

We went through all this and more and none of them work well. They are all hacky and unsatisfying when you are dealing with the range of users arducopter supports. To get really nice feel you need acceleration and jerk limited input shaping and a tight tune. That was when it started to all make sense and feel good.

Yes, but Rob is seeing something that doesn’t make sense. It might be a tuning issue, it may be an input shaping issue, it may be a nonlinearity in the system that is messing up the PID loop, or as Rob said, it may be a fundamental problem with something we are doing in the controller. Pointing out problems or questions is the first step to understanding.

We will have to agree to disagree on that one. I feel confident that the community will bring it all together very soon!!

83

I 100% disagree with the concept of using hobby FBL controllers downstream of the autopilot. It’s a wrong-headed move. It’s throwing in the towel, and admitting that Ardupilot can never be good enough. That sort of message indicates that Ardupilot is not a top-quality controller, a hobby-grade system, and not professional grade. Do professional-grade closed-source systems rely on a hobby FBL controller? No.

The worst part about it, is that acceptance of this concept means that we’ve given up trying to make the rate controllers better.

And, not to say that things are really very bad. I was told by a commercial helicopter UAV user, who purchases systems at $100k+, that doing this was impossible:

But there it is. Notice, there’s no issue with yaw control.

1 Like
84

I agree, the first and most basic step is to lock the ACRO ghost to the current attitude during start up. This will make things safer and easier for people to understand.

Then have a look at I term handling and do some experimenting with the threshold thing. I would seriously look at locking the I term to zero though. It makes it clear things are working properly and minimises the risk of a pilot not paying attention and taking off with I term build up.

Once we get those two things sorted out we can look at the niceties such as:

But until then things like this just complicate the development. And I think you will find that doing this makes things more dangerous during take off just to make things look sexier on the ground. In any case we can discuss the pro’s and con’s of this when we get to it.

You are correct Rob, it will react like a rate only controller and show the reaction to an external disturbance or the pilots rate command. So rate disturbance rejection and rate command response. So the pilot could use this to look at the rate responses and flick to Stabilize to look at attitude disturbance rejection and attitude command response. This seems to be a really clear and predictable behaviour, especially if the I term is zero.

Just another thought and it might be a bad one… You could leave the I term unlocked when the aircraft is unarmed to show I term build up as well as the rate response like Rob is more comfortable with. This would also be consistent with the behaviour you want with false positive on the land detector and premature disarm. That way you can look at the response before and after arming to look at with and without I term.

85

I think I might have left that in by accident. I would like to see it not leaked but just released with some takeoff criteria to be defined.

I think that is the current implementation of the I term. I’m ok with it but I thought what I had proposed was much clearer from a controls check to the uninitiated. Plus then in conducting the controls check with nonzero ILMI, you have some I term buildup that you would have to correct for upon arming/spin up. It probably would be ok.

86

The idea of just resorting to using a hobby FBL controller is…

It’s like asking the question “Why would you bother trying to make an open source gimbal controller? DJI had this market locked. They’ve been doing it for years and know what they’re doing. Just buy theirs.”

There’s two answers to that question:

  1. I’m doing it because it’s fun.

  2. I’m doing it because I think I can do better than them.

Throwing in the towel and resorting to hobby FBL controllers, eliminates the possibility of #2. That leaves you with #1. Which is fine. Messing around with software is fun. But that’s not what I’m doing, it’s not why I was involved in this project. I’m doing this because I believe Open Source is a better system for end users. And because I believe we have attracted a unique group of people who can do better than the closed source systems.

But that does not mean that we won’t have a few bumps in the road along the way.

1 Like
87

That’s a good point. I think it makes a sense to zero out the I-term on arming, to clear out any I-term that was stored due to IL-Min.

88

I had a thought about what the problem with yaw control is. This is based on intuition, not data, so it needs to be looked at. But here it is:

Well, the first thing that has to be understood, is that the helicopter tail control is very non-linear, or more to the point, it’s very asymmetric. Stronger one direction than the other. We need to try to linearize this to get the best performance. I’ve thought about simply having a parameter such as a asymmetry adjuster. You would use a number such as 1.1.

What it would do is that when the yaw control output is pushing nose-right on a CCW helicopter, it would multiply the final yaw output by 1.1. When the yaw control output is pushing nose-left, it would divide the output by 1.1. This accounts for the fact the tail rotor has to work harder in one direction than the other, to resist the main rotor torque.

One question I have had, is where is the zero-crossing point? Is it tail rotor zero blade pitch? Or is it essentially the “trim” pitch, the pitch the heli is using during hover? Not sure.

Ok, now back to the large overshoot. And I’m saying it’s large. This is not a PID tuning issue, it’s a controls issue.

Here’s what I think it happening.

When I first created the angular acceleration damping code, it was an input shaper ONLY. It slowed down the acceleration of the yaw input target. It was supposed to prevent I-term windup, and angle error tracking windup, due to the pilot asking for accelerations rates that the vehicle control authority are capable of matching. It only limited the rate target, but it did not limit the rate error correction. The RATE PID loop always got unconstrained effort to close any angle error.

However, since then, I believe Leonard changed it, such that not only is the Rate Target being subject to the angular acceleration limits. But he also as moved the Angle Error Correction effort, to be subject to the accel limits. This makes sense if the Acceleration Limits are tuned to the maximum possible angular acceleration the vehicle systems can support.

However, I’m using them for more than that. The large helicopters are probably capable of somewhere around 540-720 deg/s/s accel rates. But I’m tuning them with values like 45-90 deg/s/s. This is more about pilot feel. A nice, soft, predictable response, for users operating a large UAV, often with sensitive payloads under it.

But, I suspect this is not working out well, because, any errors in yaw control which build up an angle error (which may be due to the non-linearity of yaw output), the controller is only attempting to close the error at 45-90 deg/s/s. That’s why I’m seeing this large, exaggerated overshoot and spring-back.

What’s needed, is the ability to have a difference between pilot input shaping angular acceleration limits. And the controllers error correction angular acceleration limits.

Correct me if I’m wrong Leonard, but this is how I understand the controller is working now.

89

I think if you check with tridge on why they did that, it was not because of shortcomings in the attitude controller. Both Rob and I have flown Pixhawks on helicopters over 70 mph with no issues. The Canberrra team was flying a piston helicopter at high speed, engine operating at maximum power output, collective pitch at maximum in turns - in a contest. An environment where the EKF can have an issue due to extreme vibrations and having redundant systems is quite important.

In the previous contest the Canberra team had used a flybar helicopter and actually had the EKF blow up in flight and had to fly it home in Acro. With FBL that redundancy can only (currently) be provided by using a downstream FBL unit, that just like flybar, does not depend on EKF. They set it up as a flybar helicopter with Flybar Mode set to 1 to be able to use the straight-thru control offered in Acro with the flybar code.

Since then, I think everybody automatically assumed Pixhawk/ArduPilot is not “up to the task”. It actually is. But in a contest like that, operating the helicopter continuous at the edge of its performance envelope, putting in a system to provide some redundancy is kind of a normal thing to do. How it got perceived by the rest of the user community is the unfortunate part.

90

Where I think the discussion about the I-term Leak vs. Lock/Unlock/Zero is going is this:

I’ve still not seen any technical reason why I-term Leak is bad. Or any user-perception reasons why it doesn’t feel right, conversely, I think most think it “feels” right on the ground, and it does appear to be the same as what FBL controllers do. (in fact, that’s how I came up with the idea, so no surprise).

I think Leonard’s issue with it, is that in flight, it can lead to sub-optimal performance, as it limits I-term build up. The I-Leak Min was an attempt to fix that. But not many are using it. Partially because it’s not well documented. But also because most just aren’t looking. The Heli Wiki is terrible to non-existent. But Lord knows I’ve talked about it enough on forums, etc. I know that there are commercial users building helis that are NOT using the ILeakMin, and that’s unforgivable… but anyway.

When we’re talking about locking/unlocking and/or zeroing the I-term when transitioning states, I much prefer Leaking the I-term instead of simply setting it to zero instantly. The servos jumping like that doesn’t seem right. And it if happened in flight, due to false ground detection or something, would be pretty bad. Leaking towards zero is soft, and allows the P and D-terms to largely catch the error if the aircraft is actually still flying.

I do agree that flying around with a Leaky-I is less than ideal. There is definitely merit to improving when it transitions from Leak to Full I-term.

Whether we keep Leaky, or go to some Lock/Unlock scheme, they both rely on effective guestimation of when we’re flying. However, I will point out… using Leaky-I is much less bad if we have false ground detection, than simply zeroing out the I-term.

91

Thing is, I’ve also flown a gas powered helicopter at high speed, with turns, etc. I was the first to do it remember. I’ve had a TRex 800 gas conversion flying for 3 years now. With no external FBL. And last summer, I got a Gaui GX9 flying, with no external FBL. And have never had an EKF blowup.

The fact is, there’s nothing wrong with Pixhawk/Arducopter that makes it require an external FBL. Even on a gas helicopter. However, it does require a very well engineered Pixhawk installation. I’ve sort of been beating around the bush on this over the past year because I didn’t want to potentially insult CUAV. But it has to be clearly said, because the issue just won’t go away. The problems they had were due to the Pixhawk installation. It’s just that simple.

Chris, remember the problem you had with vibration aliasing, which you solved by simply making a cable softer? Or it was rubbing on the case, or something? Gas helis are even worse for things like that.

Why are FBL controllers more tolerant? I’ve talked to Paul Riseborough about this. And it simply comes down to the fact that because the EKF in the Pixhawk is so much more complicated than what’s running in an FBL, it’s more sensitive to vibration. The Arducopter EKF is tracking not just angular rate, and possibly attitude angle, but also global position, altitude, including north reference, velocity, and even time.

Notice that the Skookum UAV controller, uses vibration isolators that look an awful lot like what we’ve been doing with Pixhawk for years. :wink: And this, from a company that knows how to build FBL controllers.

http://skookumuav.com/?page_id=203

92

Hah, I just spit coffee all over my keyboard… I just pictured someone in a bright blue vest with a big yellow “watch for falling prices” button doing a receipt check on Joe Public while he is on his way out the door with his new Phantom to start his “aerial photography business”! Thanks for that Rob. :slight_smile: In all seriousness though, I have to agree with you in regards to what will make helicopters a viable platform for “most users”. That is sad but true. Sales are what create money for whatever market we are talking about and these days in this “I want it now without any of the work” society, if its not easy it doesn’t sell. Pretty much every new entry into helicopters at my local flying field is rocking a Blade helicopter with SAFE system, why? Because its easy.
I agree with your sentiment that they offer many benefits and to get wider industry adoption they need to be at parity with multirotor’s in ease of flight, or people will just continue to use the former.
Tim