The method of fixing a maximum error doesn’t stop the aircraft at a particular angle. It will continue to flop around as the pilot swirls the sticks. In any case, the autopilot is not in a position to determine what is sensible commands from the pilot so as long as there are valid commands from the pilot the autopilot will do everything it can to follow them. So if a pilot is panicking and crashes the aircraft I will look at the log and if the desired and measured attitude follow reasonably closely I will be satisfied that the aircraft followed the pilots instruction and the pilot instructed the aircraft to crash.
In anything resembling a safely tuned aircraft the roll and pitch should not break free by any angle that would cause the pilot to become disorientated. In a normal safe flying condition the aircraft needs a large external force like the ones you mentioned here.
On your examples. 1 should be taken care of by better initialisation. 2 is a real issue and I would like to address that in the input shaping code. 3 and 4 are things that could cause a large attitude error but both would correct and bounce back to the original attitude very quickly assuming no airframe damage. 5 I can assure you that I will not let this happen in normal flight.
The response seems to be to my question about how we define a significant deviation from the desired angle. To do this we need to express the check in the form of a mathematical equation or check.
In my 5 example situations, it can’t, it’s locked.
It won’t flop around if servos are sleeping.
That’s why error is building up.
In normal condition your code is fine, so we will be talking about these kinds of rare situations.
Just a random idea:
if(there is too large error) //It’s over 9000! (centi degree of error)
{
keep_trying_to_fix;
wait_for_some_time;
if(large error is still there) //aircraft probably got grabbed by a bird!
ignore_error;
}
Ok, Correct. While the servos are sleeping neither the autopilot or the pilot can do anything. This causes the error to build up. So at this stage the pilot swirling the sticks has no effect on the aircraft but could rotate the ghost.
The autopilot doesn’t know the servos are sleeping but it does know where it wants to be and where the aircraft is. If it sees the error has grown greater than 90 degrees it starts to do something different from normal flight.
So what does keep_trying_to_fix mean?
So then the error persists for some period of time. What does ignore_error mean?
Do what it should normally do, output PWM trying to catch the ghost.
(Just an imaginary function to give you the idea.)
Discard all error that has built up up to this point.
Ghost now realign to the real aircraft.
**This is just one simple example.
Discarding error doesn’t sound right, does it?
So you are currently looking for a error to persist for a preset time. The timer starts if the error gets larger than 90 degrees. If the error persists for the full time then we reset the error back to zero.
If the aircraft is flying but has a bird attached to the tail boom. This will cause the aircraft to fight the additional load causing a slower rotation. Each time the error is reset the aircraft will suddenly rotate until the error builds up again and the controllers start to fight the load again.
The other thing to note here is that with an error of 90 degrees you have already swapped two axis. So with a 90 degree pitch up the roll becomes yaw and visa versa.
So the angle of 90 degrees is too large if this error will persist but by keeping it smaller you potentially stop the controllers fighting it.
If you reset the error to zero you stop the aircraft fighting the error at all. This doesn’t matter if the servos are dead but nothing matters then.
This is why Rob wants to drag the error of 10 degrees around and not let it grow further. It limits the axis offset problem and maintains at least some level of resistance. But why 10 degrees? Why all three axis? This could make a docile frame unable to fight small disturbances.
As far as the initial checks of the flight controls prior to turning rotors, I see several places in the software where it limits a function for helicopters because they could be in autorotation. One in particular, is relaxing the attitude controller. It says the reason why it’s not relaxed (in pitch and roll) is that the aircraft could be disarmed and trying to autorotate. Is there a reason that we have to have the aircraft flyable In a disarmed state? In AC 3.3, the motor interlock is linked to channel 8 which is also RSC. It also disarms the aircraft after so many seconds once the motor is disabled through channel 8. I think this feature is not specific to Heli and that the disarming occurs after 15 seconds with the collective or throttle for multicopters all the way down. I’m guessing with the motor interlock enabled (i think i’m saying that correctly) the automatic disarming feature is disabled. So it seems that there needs to be a better way heli handles motor interlock and RSC so as to allow the pilot to conduct autorotations with out disabling motor interlock and thus keeping the pilot from getting into a situation where the aircraft is disarmed and in an autorotation. Then features like relaxing the attitude controller while the aircraft is disarmed can be the same between multicopters and heli’s.
It doesn’t have to be 90, it can be anything you find is best fit, or user adjustable (might be useful for users with very weak/low headspeed heli)
We have to split into 2 cases
Something (external force) is stopping the aircraft from moving:
In this case, when error is reset, the aircraft will simply stop fighting and try to stay at its real angle
Unless the pilot is still swirling his stick.
Something is rotating the aircraft:
When error resets, the aircraft stops fighting but will continue to fight instantly after.
@Leonardthall and @PittRBM I apologize but I’m going to back up this discussion for a minute. This discussion is strictly regarding Acro mode? From my understanding of Acro, it is intended to mimic the bare aircraft control characteristics which in the case of a helicopter is rate command. So your stick input is directly proportional to an angular rate. From what I see in the code (AC 3.3.3), if the requested rate is not met, the ghost aircraft gets ahead of the actual aircraft and the error between the ghost and actual aircraft attitude is turned into a rate to bring the aircraft to the ghost aircraft attitude. In my opinion, the controller should be giving the pilot the commanded rate and closing the error on rate only. If the pilot is making an input, the controller should be giving him a rate regardless of the error in attitude. Now if the pilot centers the stick and the intended control architecture is to provide attitude hold, then the controller should do everything it can to hold the attitude when the stick was centered. And I guess this is what you are currently trying to address. I think some of this could be mitigated by not tracking attitude error unless the stick is centered. This would address an improperly tuned or docile aircraft, if i’m understanding Leonard correctly.
To follow up on the discussion on what defines the behavior of the attitude controller when the ghost aircraft significantly deviates from the actual attitude. In my opinion, we need to go back to the manner in which the aircraft is being flown. The situation is externally piloting the aircraft in Acro mode. The maximum tolerable error between the actual attitude and ghost aircraft is based on a reasonable reaction of the pilot to seeing the aircraft deviating from the pilots intended attitude. When the pilot comes on the controls which he ultimately will do, the attitude controller should abandon attitude hold and give the pilot the requested rates. I think it is unreasonable to continue having the ghost aircraft update the target attitude and close the error on that. At that point the pilot has no idea what the target attitude is nor does he care. If the disturbance was powerful enough to cause a deviation which made him come up on the controls, then the autopilot should follow the pilots rate commands only. I think the idea of having a maximum error allowed is not required in this situation. The pilot decides that.
This is why there is a Leaky I-term. This has been working great for 3 years. Again, this concept comes from existing FBL controllers.
They were. The problem is that some fundamental features of the code changed, and nobody went back and checked to make sure that heli didn’t get broken by those changes.
Servo feed through has been in the helicopter code for about 6 years.[quote=“Leonardthall, post:56, topic:15658”]
Whil
[/quote]
Actually, the helicopter code is cleaner than multirotor because it does not need the Stability Patch. Unfortunately, it did get a lot of complexity driven in by the flybar and external gyro code that was added recently. And the H1 code that has been around a while but is obsolete. This should be gutted in the interest of simplicity.
Yet this hasn’t been a problem for years? The angle error limit has been there for years. As demonstrated I have little helis doing 140 km/h . They go until RBS occurs, beyond which nothing can be done.[quote=“Leonardthall, post:56, topic:15658”]
In that case it is a race between the I term limited by Imax and the time it takes to rotate upside down and crash.
[/quote]
Doesn’t happen. You’re insinuating problems without ever having flown a helicopter.[quote=“Leonardthall, post:56, topic:15658”]
If the attitude controller loses control of roll or pitch then the pilot has no hope.
[/quote]
Have recovered from RBS with little issue no problem. That is the only time attitude control is lost IME.[quote=“Leonardthall, post:57, topic:15658”]
That is correct and I consider it a serious issue. It can result in the pilots inputs not matching the aircraft axis. This is exactly the problem I would like to discuss. Unfortunately you don’t seem to be able to get past the “we already had a solution, just limit the error to 10 degrees for everything” argument.
[/quote]
Actually what I can’t get past is that it worked. You made a fundamental change without discussing it with anybody. And then now are trying to suggest that the code you broke with unilateral changes, was broken already. It wasn’t.
What I will not tolerate, is any situation where live pilot rate requests, are significantly stored, and acted upon later.
Again, you are insinuating that there is something wrong with the helicopter controller. There is not. Or there was not… You changed the attitude controller without considering effects on code running after it. And without talking to anybody who would know.
Ground detection has been working on copter for a while. It’s not perfect, but pretty good. We can discuss this further if you’d like. In addition, helicopter detects hover vs fast flight. Something multirotor doesn’t even do yet. Again, been working for years.
Totally agree with this part. This is how it was. And how it should be.[quote=“Leonardthall, post:61, topic:15658”]
In anything resembling a safely tuned aircraft the roll and pitch should not break free by any angle that would cause the pilot to become disorientated. In a normal safe flying condition the aircraft needs a large external force like the ones you mentioned here.
[/quote]
Yes, pretty much only happens at RBS. However, in high speed flight, it’s normal that rates cannot keep up with stationary setpoints and lag. It is completely unacceptable to store up lag as error, and keep trying to close the error after sticks are centered.
Why do you keep talking as if this is something that is new that I want to add, and that it might not work. This was IN the code for 3 years. And it worked great. This is why I cannot figure out why you made such a radical change without talking to anybody about.
And please guys, stop talking about birds and sleeping servos. Those are not real problems. RBS and tailboom drag are the real issues.
I did this, because there has never before been a reason NOT to. Also, it’s been useful in cases where the Landing Detector triggered falsely, because the descent rate check was eliminated by somebody without discussion… And the helicopter disarms at 30 meters. I was able to at least have it land right side up, and not kill me, because I had flight control as it came down.[quote=“bnsgeyer, post:66, topic:15658”]
n AC 3.3, the motor interlock is linked to channel 8 which is also RSC. It also disarms the aircraft after so many seconds once the motor is disabled through channel 8. I think this feature is not specific to Heli and that the disarming occurs after 15 seconds with the collective or throttle for multicopters all the way down. I’m guessing with the motor interlock enabled (i think i’m saying that correctly) the automatic disarming feature is disabled. So it seems that there needs to be a better way heli handles motor interlock and RSC so as to allow the pilot to conduct autorotations with out disabling motor interlock and thus keeping the pilot from getting into a situation where the aircraft is disarmed and in an autorotation. Then features like relaxing the attitude controller while the aircraft is disarmed can be the same between multicopters and heli’s.
[/quote]
This is all my code. Heli CH8 RSC came first. I added the Interlock function so that Multirotors could benefit from this important safety feature.
The auto disarm time can be lengthened to allow autorotation using the param Disarm_Delay. Or turned off entirely by setting it to 0.
For pitch and roll, yes. Yaw is affected in other modes. Stabilize to Loiter.[quote=“bnsgeyer, post:68, topic:15658”]
From my understanding of Acro, it is intended to mimic the bare aircraft control characteristics which in the case of a helicopter is rate command.
[/quote]
Yes, exactly.[quote=“bnsgeyer, post:68, topic:15658”]
In my opinion, the controller should be giving the pilot the commanded rate and closing the error on rate only. If the pilot is making an input, the controller should be giving him a rate regardless of the error in attitude. Now if the pilot centers the stick and the intended control architecture is to provide attitude hold, then the controller should do everything it can to hold the attitude when the stick was centered.
[/quote]
Yes. This is basically how it was when the maximum error was limited to 10 degrees.[quote=“bnsgeyer, post:69, topic:15658”]
I think it is unreasonable to continue having the ghost aircraft update the target attitude and close the error on that. At that point the pilot has no idea what the target attitude is nor does he care. If the disturbance was powerful enough to cause a deviation which made him come up on the controls, then the autopilot should follow the pilots rate commands only.
[/quote]
Completely agree. This is what I want.
The previously existing attitude error limit, did this quite well. And simply. Since the stored error could never be more than 10 from where it is now, and the code featured pilot demanded rate feedforward already, it acted as a natural pure rate controller beyond that point. If tuned properly, the PID would already be very heavily loaded and the helicopter is doing everything it can already.
You have highlighted issues with heli that demonstrate they are not.
The Attitude controller is used in 6 different frame types, heli is just one of them. Heli is the only one that uses the Leaky I-term. And even then it is a hard coded value that can’t be tuned for different frames. It does work nicely for yours though doesn’t it Rob. I have never seen you actually work out what the maximum error your PID arrangement can achieve using the leaky I term and I doubt you ever did work it out.
Yes and I made it work for all the other configurations so that Heli didn’t have to do so much special handling. You have also made many other valuable contributions like the kill switch that came from the Heli background.
Actually, heli needs a stability patch. You currently have to limit your roll and pitch authority to prevent the collective binding your head up. I pointed this out to you quite a while when you had this problem and you have commented on the need for a heli stability patch for a while now. For those that don’t know what the name “stability patch” refers to it is simply a set of checks and limits that ensures you maintain your roll and pitch authority when less important commands are put in. In short, you don’t care about increasing your collective if you can’t control your attitude, for a copter it means throttle doesn’t help you stay airborne when you are upside down.
Actually, roll and pitch have never been limited by 10 degrees. This is the problem when you attempt to dictate how problems should be handled without understanding how the problems are caused or how they have actually been addressed. The roll and pitch have been limited by 30 degrees, an angle large enough for any pilot to notice all the issues you are using to insist on a 10 degree limit.
There are 6 frame types using the attitude controller. This isn’t all about just the helicopters you fly Rob. And again, do the maths before you[quote=“Rob_Lefebvre, post:70, topic:15658”]
Doesn’t happen. You’re insinuating problems without ever having flown a helicopter.
[/quote]
It doesn’t happen because you don’t reach that limit. Seems a bit silly to me to be making such a fuss about implementing a limit that Heli never reaches (on your aircraft, keeping focused on what is important here). Again, 6 frame types.
Yes, once the attitude controller regained control after RBS. Even you have to obey the rules of physics Rob. Anybody would think you are just replying for the sake of it here.
No it didn’t. We never had 10 degrees on all axis. I was the one that did the testing and saw it didn’t work. I was also the one that made the decision on what it was to try to best balance all the pro’s and cons that most people never know about because they never see them because I made sure they never hit those limits (just like you Rob).
You won’t tolerate it Rob? What, are you going to go and use PX4 or something? The pilot rate requests have been significantly stored and acted upon later for as long as ACRO has been flyable. That is what makes it flyable.
No, you said that these changes would affect the Pirouette Compensation code in Heli. I used the work “if” to emphasise that. The attitude controller doesn’t do Pirouette Compensation. That is in the Heli specific code. It has all the information needed to do it correctly so if it doesn’t do it correctly then the problem is in the Heli code. I could see how someone could get a little lazy and/or not understand the attitude controller well enough and use the wrong frame for the Pirouette Compensation. Not a problem with the attitude controller. Moving on.
Been doing it since you started flying ACRO Rob because before it did that you hated ACRO.
No it hasn’t, see above.
Agreed but only on Heli’s. 6 frame types. And this all boils down to control authority overwhelmed in roll and pitch OR control authority overwhelmed in Yaw. Then what happens next.
Wow, what a waste of time. While Rob may not be willing to listen to reason I hope this helps others start to appreciate some of the complexities here.
These problems shown here only showed up with 3.4. They were not there in 3.3 which is the last release that I oversaw and signed off on.
Oh God no. If these problems are not fixed, I will just have to fork and do what I need. This is actually how I operated for years.
3.3 was the first and only release where I had the time to fix problems to keep up with the latest stable, and sign off on a realease. Until then, I was running a fork based on the last stable, and then worked to make it fly helicopters properly. It has long been a battle of trying to find and fix issues introduced by multirotor changes without consideration for effects on helicopter.
Wow, where do I start. Ike I said before this discussion brings to light many issues that drive changes to the Heli code. So i started this post asking whether the 3.4.5 version for Heli frames is behaving properly. I guess that is debatable. I do know that Heli users are concerned with how well the Heli code is being looked after since Rob has left. This is one instance that creates doubt.
So what is the way forward? And I think the answer has to come from a developer other than Leonard or Rob. Unfortunately I think I know what the answer will be, because im sure much of this depends on money and I’m sure there is not much behind the development of Heli’s and maybe this is why the developers are trying to get the versions aligned more.
I don’t think you’re understanding what I just said.
These problems are not in 3.3. They are now in 3.4. I didn’t touch 3.4. It’s either a change you made to AC_AttitudeControl, or a change somebody else made to Heli_Control_Acro. Here’s the history. I don’t see it. Do you?
No. It is very common, that helicopters have “limited authority” on pitch and roll. If they have full servo throw on pitch and roll, they will usually destroy themselves. I can give you a few helicopter mechanical setup manuals if you would like to see yourself. This is what is typically done. The cyclic throw is always on a reduced range, as is the collective, such that the sum of the two do not cause any control binding.
You are partially right, I did initially think that I had a heli which could benefit from stability patch. I later realized that it was a mechanical setup error. I corrected it.
Well, it was when I wrote it. I’d have to dig deeper to figure out what happened. It’s too far back in the history to find. I can’t remember if my initial heading lock acro code was never merged in and then you re-wrote it. Or what. I don’t have my private repos that far back. Will have to let this go.
But you are right. It’s been 30 degrees for a long time. 30 degrees is quite a bit less than infinity which you have changed it to for 3.4…
So here we come to the crux of it…
Leonard, can you please remind me which Dev Call you were on which explained the changes to the Attitude Controller, which would indicate to the other developers, what has changed, and what they needed to do with the frames? Maybe I missed it. I dunno.
Did you raise an issue to tell people “Hey guys, I just made a major change to AC_AttitudeControl, you need to check your interfaces.”
Is there an email?
Admittedly, 30 degrees, which is more than I thought. Still a big difference from infinity.
Leonard, what I’m trying to get you to understand here, is that you cannot just keep making major, unilateral changes to the code, that affects downstream users of the outputs of that code, without informing people. It’s not fair to other developers.
Do you remember, how the Landing Detector used to have a descent rate check on it? But you removed it, because you thought it worked better without it. I don’t recall being asked for my input about that. I did express my concern at the time, but my thoughts on the matter were not valued. Later on, I had a heli crash. It disarmed, because it thought it was on the ground… even though it was still descending at 2 m/s and knew it, it thought it was on the ground because it wasn’t accelerating. It was in an established descent. There have been other crashes as well. Expensive multirotors destroyed themselves. Somebody else went and added a 1 m/s check in. You were very upset, because he did it without talking to you. Remember? Eventually you realized it was the right thing to do.
You see where I’m coming from? Other people, sometimes feel exactly like you did.
Yes, it probably never made it into the code because the problems are obvious as soon as you consider more than just the aircraft that one developer is flying.
But enough so that you have not had a problem hitting it and have not noticed it. Meaning for you the difference between infinity and 30 is nothing. Well, now that I think about it. It may have taken longer for you to temporarily loose control in RBS. You may find that you get a larger lean angle before it starts to slide. Based on the pid values you are using it is easy to calculate. You should do it and let us know.
Yes, this is often the case. People tend to write what is very valuable code but without appreciating all the ways it can cause problems. So generally this needs a complete rewrite to account for all the issues the original author simply doesn’t understand. I try to start with the original author’s work to ensure they are given appropriate credit.
Ok, on the “you didn’t talk to anybody” stupidity. First up, I talked to you extensively because better supporting Heli was a major goal of my changes. I spent more time talking to you about the particulars of the implementation than anybody else. At the time I was hoping you would bring Heli up to speed. Unfortunately this was when you were having your dummy spit and resigning from being a developer for … reasons. Thankfully Tridge and Randy have stepped up to the plate and the code is generally better for it despite your foot stomping silliness. Secondly, I did these changes as a direct request from Tridge, Randy, and the dev team because it solves a bunch of problems we have been aware of for a long time. Jonathan started the process with much of the basics and I refined it to ensure it was appropriately handling all the subtleties. This was one of the most tested parts of the code because it forms a fundamental building block. The only reason you were not part of this development was because you chose not to be a part of it.
I don’t, I talk to everybody who can offer some insight to the problem. It take a year or two before I get all the pieces in place for most of my non-maintenance changes. I generally spend 6 to 12 months playing with the math, simulations and looking for problems before even starting to code. By this time I have pretty much drained of ideas and perspectives any member of the dev team that I have access to.
On the Landing Detector, this has been a long standing battle the whole dev team has had. I was able to distil the work of a whole bunch of people down to realistic checks that could be done accurately given a large number of possible ways things could be tricked. Tridge added the descent check based on some crash logs. Tridge had done his background work and made a good decision that accounted for or balanced the numerous issues that check must address. The new check was not the same as the old one that caused problems. While I was worried given complexity of that check, Tridge was able to clearly demonstrate his train of thought and was willing to discuss any and all options. The current check represents the best compromise that the dev team can come up with. Lessons you could learn from if you still had any interest in contributing to the code.
And I took the time to understand the full scope of the decisions being made and on doing so realised they made the right decision, a decision that best balanced all the issues for all the frame types. I did not bury my head in the sand and make up stories in an attempt to get what i wanted without justification.