OK. I think the heading is more important than pitch-roll, as it affects all flight modes, not just Acro, which not a lot of people are using.
I will help try to get it through a PR if I can, or I’ll use it in my Fork if I have to.
That would be great. I’m pretty confident I can figure out heading 
First up a bug is when the code does not work as intended. The code does work as intended.
Second
This is verging on silly. To do this we need to have an aircraft set up to the absolute limit of it’s capabilities. Some external force or mechanical problem needs to create a large attitude error. This pilot god then has to be so fast as to prevent the attitude controller from closing the error and stupid enough to not slow the inputs as the aircraft continues to behave erratically. In reality the aircraft can’t close the error at all and nothing can save it or it returns to its pre disturbance state with some apparent overshoot that the pilot then corrects (the pilot only has to rotate say 90 degrees instead of the initial 180). So this whole description is exaggeration and hyped to try to inflate the importance of this feature.
So there are three issues here in order of significance in my opinion:
- Heli does not have a mode or state that allows the pilot to check the swash is working correctly. This should be a direct pilot input so the pilot does not need to understand the inner workings of the controllers to make sure the aircraft is safe to fly.
- The yaw axis can be overpowered in heli or quadplane. This will result in the controllers continuing to flight the yaw error and continue to be over powered. Simply limiting the error to 10 degrees doesn’t address the basic problem, just the movement after the problem ceases to exist.
- In ACRO the aircraft desired position can get in front of the current position if the aircraft has been tuned badly or experiences a overwhelming and sustained force.
I can see a need to address all three but each has very different solutions and in very different parts of the code.
I would think that an unconsidered edge case counts as a bug, but let’s not get pedantic about what is and is not a bug. Let’s call it an issue - and it is an issue, even if you think it might be a perceived issue (perception == reality, ergo perceived issue == real issue).
It is entirely not unreasonable to prevent the attitude error angle in acro mode from exceeding a small value - 5 to 15 degrees. In the event of a motor failing to commutate properly and then recovering, or after some kind of impact (e.g. with one of those flag things in an FPV race), or even if - gasp - an end user has a really bad configuration, we want the vehicle to somewhat pretend to be in a pure rate mode, since that is what the user is bound to expect out of acro mode.
For the same reasons, it is also not unreasonable to prevent the yaw angle error from exceeding a small value when the pilot is in control of yaw rate. There are any number of situations where the vehicle’s yaw authority could be insufficient - a helicopter with a vertical stabilizer, for example.
To rephrase Rob’s car analogy - you wouldn’t want your car’s electronic stability control to stay engaged and steer you off a cliff after you run into some understeer. If the pilot is giving an angular velocity command, we should be primarily respecting that angular velocity command.
Your own loiter controller follows the exact same principle - there is a limit on the position error, and there is a limit on the velocity at which position corrections are made.
Further, if we’re going to allow angle errors to be large, we need to do some thinking about what frame of reference the input angular velocity is in. Is it in the current vehicle body frame, or in target body frame? How does it instantaneously affect the vehicle? How does it rotate the target body frame?
perhaps a “we’re not keeping up with demanded attitude” check, and switch to direct rate control from sticks to PID inputs until it recovers?
Yes… though the 10 degree attitude error limit basically did that, because the desired attitude could never be more than 10 degrees from where we are.
But really almost anything is better than this.
WARNING:
If you are disarmed in Acro mode, and you push the roll stick such that it stores a large error (when the swashplate flips from one side to another is 180 degrees). The swashplate never relaxes.
If you then arm, and start the motor, the swash never resets. The rotor will spin up, and when it has sufficient speed, it will flip the heli over on the ground.
At this point, I would advise people not to take off in Acro. It’s unsafe.
So let’s sketch out what we want/need in the attitude controller.
- Angle Error Limit
- Angle Error Leak back to Zero over 4-5 seconds. Most FBL controllers do this as has been pointed out by others, and I think it’s a good idea.
- I would like to add Angular Rate Limit back in too.
Any other ideas?
This wasn’t unconsidered. This was something I carefully considered when I wrote the attitude controller (all three times). Calling it a bug is just exaggeration and attention seeking.
I don’t care about perceptions or feelings. While they are often the first step in finding and defining a problem/bug/missing feature, they are not enough to take action on if maintaining a professional and reliable autopilot.
Engineering problems have engineering solutions.
It is also not unreasonable to expect the aircraft to return to its starting point after temporary motor sync issue. Aircraft is level, thrust vector vertical, 3m up. Jonathan is testing his ESC’s in ACRO mode for some reason. You have a sync issue on your front left motor. The aircraft rotates on its diagonal axis by 200 degrees before the motor re-syncs. The aircraft is now upside down and pointing in the opposite direction to what it was initially. Now the question is, do you want the pilot to level the aircraft or do you want the attitude controller to level the aircraft. I am happy to do this test with each of my aircraft using the current code, are you willing to do the same test using each of your aircraft using your approach?
The simple fact is the autopilot can correct this error much more effectively and quickly than any pilot can and leave the pilot in a much better state to continue flying in acro. The current system will a small quad’s thrust vector back to the initial state quicker than any pilot could react correctly.
So no it isn’t unreasonable to limit the angle error, it also does not appear to be the best option.
Again, not unreasonable. That doesn’t mean it is a good thing to do or the best solution to the problem. For example. By limiting the error you prevent the yaw controller using the full authority if it has not saturated by that angle. This means a softly tuned aircraft will seem to slip any time it gets hit by a disturbance.
I don’t care, it isn’t a car.
Yes, the loiter controller does limit the error. The reason it does this is because any reasonable pilot can always react faster than the loiter controller can change position, the pilot input is then given priority. This is not the case for the attitude controller and acro.
I have thought about this. The pilot input is tracked in the frame it is entered in using a virtual ideal aircraft. These inputs are then translated to the vehicle frame in such a way as they keep the error constant. The Attitude controller is then left to remove the error and bring the actual airframe back on top of the virtual one. This is very predictable and minimises edge cases. It also separates out the functions keeping the code simple and easy to maintain (relatively).
If we are not keeping up with the demanded attitude we are talking about case 2 or 3 above. If it is case 3 where it is a poorly tuned aircraft then the pilot will see there is a problem very quickly and back off the inputs. They will then look into the tuning of their aircraft and fix the issue. This is just the same as any tuning issue. It results in poor performance and can be addressed by tuning. In this case the pilot would need to be deliberately attempting to get crazy high rotation rates and accelerations. They will be more than capable of handling this situation with the current code unless they are a complete idiot.
If it is case 2 where the yaw is experiencing a constant and overwhelming force. We are talking about weather vening. This is something I think is usefull feature to add. We can add this by limiting the yaw error but it still leaves the aircraft fighting and as the problems I stated earlier. This is an area I think is worth talking about in more detail.
This is a problem with the heli initialisation code not the attitude controller and it should be fixed. All aircraft should have their desired attitude set to the current attitude on arming.
It did used to do that. Something must have changed, and the Heli Acro mode wasn’t updated.
But then still we have the problem: User arms, but doesn’t start the motor yet. The move the roll/pitch stick. Large angle error is stored. Start the motor, crash. When there was a 10 degree angle error limit, it wouldn’t move more than 10 degrees, which won’t strike the blades on the ground.
An error bleed will further help this. It’s what all the other controllers do.
The Angle error limit - which one, at what point in the code?
Angle Error leak back to zero - What justification do you have for this? Over what time? How will you deal with the fact this will allow the aircraft to drift around and not hold attitude.
Angle rate limit - Why, how does this help anything. I think you are just adding changes for the hell of it.
You have to not only show that things directly address a problem but that they also don’t create additional (or worse) problems. Many of these issues are trade offs. We didn’t get to this point by hacking half baked ideas into the control code. I can justify every decision I have made in writing the attitude controllers, it is fair to expect the same of anybody making changes.
Now that I have the replies done.
I suspect that I am one of only a very few people that are pushing acro to a point where I regularly overwhelm the attitude controllers and cause the aircraft to blow out in one axis or another. The speed of these blow outs and the speed at which the attitude controller corrects the problem makes it impractical to expect the pilot to catch the vehicle in anything resembling the same time frame the attitude controller does.
In short, reducing the maximum angle error to 10 degrees in any axis in acro would dramatically reduce the safety of the aircraft when a blow out happens.
There are three issues here. We should be addressing each one and moving forward.
The point at which it existed before you removed it, worked well.
Over about 4-5 seconds is common. The justification, is that it solves problems if the sticks are moved before it has left the ground.
The drift should be easily taken care of by I-term. If not, then we turn it on/off with the Dynamic Flight function, same as we do for I-term leakage.
Not adding it. Returning it. It was there when I wrote the initial controller. You removed it without discussion.
And why? Large helicopters, which can’t achieve high rates. Particularly if they have horizontal or vertical stabilizers.
Ok. But you also have to show that your changes don’t cause problems for others before you make them. This keeps happening. I’ve had at least one crash, I think two, from changes that you made without discussion.
Angular Rate Limit should prevent error exceeding Angle Error Limit in normal situation.
Angle Error Limit is still needed to prevent tip over during take off
Leakage also is nice
Maybe only leak out error exceeding Angle Error Limit?
About how to return to previous angle (in case of blow out) after the aircraft regain control, IMO that’s not required when pilot is using Acro in the first place. If one wants it to, they probably have used Stabilize.
Keep in mind, angular rate is controlled in Acro mode by Acro_RP_P and the yaw is Acro_Y_P, but it affects yaw rate in all modes (yes, that’s pretty confusing).
But angular rate could be useful in Stabilize, if you whack the pitch stick from full forward to full backwards, with a horizontal stabilizer for example.
I don’t think you have experienced this. The effect is not dissimilar to being hit by a bat without warning. When flying fpv it is impossible to orientate at all until the spinning stops, if you have nothing but sky in the camera you have no idea which way to correct to bring the aircraft level. In line of sight the aircraft is back to the original orientation and flying again before even an expert pilot could orientate (for small aircraft).
This isn’t a if you want auto level fly in stabilize argument. This is a your aircraft just flipped upside down without warning in a turn 1m off the ground. Simple choice do you want to crash if so then you will appreciate the limited error design.
Leonard, why are your needs the only valid needs? You just stated, that you are probably the only person flying like this and needing this feature. Meanwhile, others of us, are saying “this does not suit us, we preferred it the way it was.” And then we are told that what we want, is wrong. You are saying that decades of research into controls engineering by other engineers is wrong, or unimportant.
It’s like when you removed the angular rate limit from having affect during a mode change from Acro to Stabilize. I told you it risks cutting off the tail on a helicopter. But you did it, changed an existing feature that somebody else wrote, without asking, and then didn’t fix it. You wanted maximum response from a multirotor to right itself. Reasonable in most cases as multirotors have more limited angular accel capability. But you didn’t consider the effect on helicopters, which have virtually unlimited angular accel capability up to the point of structural failure.
I have to say, this exact thing, is a large part of the reason I stopped developing and resigned as heli maintainer.
I have no problems with an angular rate limit to address the specific issue of the main rotor hitting the tail boom. There is heli specific rate controllers that could be used to do this without even asking me.
The issue is you are using a problem to justify changes that are unrelated to that problem. You are misrepresenting problems to exaggerate the importance of your issue. You are shutting down conversation on the actual problem because it is not leading to the outcome you desire. You are arguing to revert code without understanding the reasons it was done or the problems it solves. You are claiming crashes caused by code without logs or even a description. Finally, you are pretending that limiting the angle errors is the only solution (it isn’t the only solution or the best solution).
I have designed the attitude controller to be flexible in the way we use it. None of the issues here are a significant problem if they are handled in the right place and right way. The issue here is heli has a lot of short cuts in it that need to be cleaned up.
Before we handle problems they need to be clearly defined. We can then make discuss solutions and make changes that are a step forward not sideways or in this case backwards.