Ok, here’s the only video I ever got. Acro starts at 3:45.
Yes, it’s not 3D flight. The system can’t handle 3D flight, the EKF will blow up. This is not a great demonstration of what the system can do. I don’t do 3D, but fast yank and bank flight. And the cameraman can’t follow it.
If you see any control problems for a UAV, please point them out.
I guess I was referring to the transition from (IIRC) 3.1 to 3.2 where Acro didn’t work and then you fixed it.
I’ve since gotten it to work with my underpowered Trex 500 with FBL and the only problem I had with it was lack of power because I’m using a 4S battery with a drivetrain designed for 6S.
Ok. Yeah, that’s a long time ago! 
Good stuff! I did not feel that comfortable flying in acro with the PID gains I was able to achieve before seeing the instabilities. If able I would still love for you to test my software. Thanks again for the feedback!
Well, yeah. A couple versions back. But in heli’s unless you’ve been involved with it, it all has to be checked out because being it’s sort of one with multi’s sometimes things get missed for heli. Heli needs more testers and there’s just not as many of us as there is in multi’s.
So I talked with one of the other guys. It’s as I suspected, it occurred because of the change from the Euler Angle attitude controller to Quaternions. I’m not sure if it is considered a Bug or a Feature. The maths to implement the 10° error limit in Quaternions is quite a bit harder. It is being proposed as a Feature, because after a loss of control, the copter will return to it’s original attitude when it regains control.
IMO, it’s a Bug.
Once a vehicle has lost control, the pilot will continue to enter rate commands, trying to regain control. It will store up all those commands. When/if it regains control, it will not return to the attitude it was at when it lost control, but will attempt to return to whatever heading it has stored up after the pilot moved the sticks trying to regain control. The pilot will continue moving the sticks, trying to regain some semblance of control, not understanding that the controller is continuing to sum their movements into the existing built up rate error.
The old behavior, would have it where after control was regained, the copter would now hold whatever attitude it’s at currently, and the pilot would have direct rate control after that point.
Why has this not been noted? IMO, probably because not a lot of people are flying Acro on Ardupilot. And those that do, if/when control loss occurs, they crash. And crashes happen, people move on. And this really only going to manifest itself in Acro mode. Except for yaw. Yaw will be affected in all modes.
But this is a particular problem for UAV helicopters. Consider the case of the classic “Tail Blowout”. You are flying backwards at speed, or even just hovering with a heavy tail wind. Tail blows up, copter rotates to face nose upwind. With AC3.3, it will stop there. The pilot can try to yaw it back around, and it may or may not, depending on conditions. If it can’t do it, it just won’t make it. The pilot will understand that.
With AC3.4, very different. After the blowout, the copter will keep trying to get back to the original heading. It will continue using maximum power on the tail to do so. If the conditions change, such that it suddenly can regain the original heading, it will suddenly do so. ie: flying backward fast, tail blows out, pilot slows the heli down, it suddenly yaws back around backward with no pilot input!
Or, if after the blowout, the pilot tries to yaw the heli backwards again, and it can’t, the error will build up until it passes 180°. At that point yaw will suddenly snap around the other way!
IMO, this is all quite unacceptable. Another roadblock to me moving to 3.4 and 3.5. This isn’t something I can fix myself either. That Quaternion maths stuff is beyond me.
Might have to pass the hat around to pay a developer to fix this. Anybody else interested?
Rob, in my development of the attitude leak feature, I learned a lot about the 3.4 attitude controller. I’m pretty sure I can fix this in pitch and roll. I think heading should follow. Give me two weeks to try it and you can look and try it in the sim.
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:
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.
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.