I suppose one simple solution is that in some cases, such as when the controller believes it is on the ground, there is simply no error accumulation. Pilots rate demands, are passed through directly to the PIDs. In combination with the Leaky-I, this will ensure the copter isn't in a state where it will flip over when the rotor starts. It will also solve your issue with placing the helicopter onto uneven ground from take-off. It will also make the swashplate behave as people expect it to on ground testing.
This can be turned on and off, by using the vestiges of rotor speed estimation I have implemented. From disarmed, and after the motor is started, there is a counter which estimates when the rotor is up to "flying speed" at which point the attitude controller can be given more authority to do it's job. When stopping the motor in flight, such as auto-rotation practice, or accidental disarms, it counts down the rotor speed, and after a certain point, it assumes the rotor is going too slow for flight control. This is a bad assumption, but without rotor speed feedback, it's all we have. At that point it can transition back to pure-rate pass-through.
The ultimate solution, is direct rotor speed feedback. I'm running this on my fork based on 3.3 right now.
The problem with RBS, preventing it, and recovering it, which I think is not understood here, is that RBS control loss occurs 90 degrees out of phase. RBS does not occur when the controller runs out of pitch authority, or when the pitch authority is not keeping up with the pitch error. It actually occurs when the roll authority is gone. In forward flight, the swashplate must tip forward, as you would expect, but much less than assumed. But it's also tipping heavily to the left (on a CW rotor). When the retreating blade stalls, it results in a pitch up. But the solution is NOT to apply more forward pitch output. That's one of the big problems with all of this. And that's what the proposed controller is going to do.
Anybody attempting to design a helicopter controller, should get a copy of Gordon Leishmans seminal title on the subject. Rotary aerodynamics are extremely complicated. Much moreso than a multirotor which is a much simpler model. The answer to every question, even from PhD level Rotary Aero Engineers is "it depends...". There are no simple answers or solutions.
I don't think RBS can be stopped by an automatic controller once it sets in. The retreating blade has stalled, it's got nothing left to give. When I hit it, the heli uncontrollable pitches back, until it is basically vertical at which point it slows rapidly. This will rip a UAV helicopter to pieces and must be avoided at all costs. Surely adding wild rate outputs to the thing, will not help the structure. There are plenty of other things that need to be done for a UAV controller besides trying to solve it with the attitude controller, which is futile. Airspeed sensor, adaptive rotor speed control, etc.
I agree Bill, that the attitude controller should never attempt to achieve a rate output greater than the setpoint. No matter what. This is a particular problem right now, for Acro pilots using Stabilize mode as a Bailout from an inverted attitude. It used to be, that the return to level was constrained by the Angular Accel parameters. But for 3.2 or 3.3, this was changed, again without discussion, to be a maximum output effort. This is what threatens to cut the boom off. Hasn't happened to me yet, but eventually it will.
I do appreciate any attempt to make the attitude controller more high performance. But not if it is done at the cost of good human machine interfaces. I cannot think of any case, where a human operator is given a live rate-based control input, where the control system will accumulate error, and actively tries to close that error resulting in movement even after a control is centered. If anybody can think of a single case where that happens, from any field, from flight control to economics, I'd love to see it. I can see the point of returning to the last commanded attitude in an FPV situation, where attitude is lost, and the pilot has lost orientation and can't see the attitude, nor does he have any feel for the forces or orientation of the vehicle as he's not inside it. But that's a very specific case, and I don't think the solution to it should be applied across the board.
On the question of a tail blowout, IMO, it's best to just let it blow out 180(ish) degrees. This will be a low-power condition now. Once control is lost, control is lost. The tail is snapping around, and it can't be stopped. Helicopter pilots must understand this condition, and be prepared for it. As far as the pilot is concerned, if it's 180 degrees nose forward, or 45 degrees from that point, or 90 degrees, it doesn't matter. It's not a situation where "Oh, good news, it only rotated 150 degrees so I'm much better off". He has to deal with the situation he finds himself in. For the controller to command the tail to keep moving after the event, with maximum power, trying to push the tail upwind, does absolutely nothing good for the pilot. And it's certainly not good for the machine.
IMO, this all comes down to this simple point: Ardupilot is almost exclusively used as a UAV controller. Nearly nobody is using it for Acrobatics or FPV racing. And that will not change, no matter how good the controller becomes. There's a whole host of reasons for that. From cost, to weight, to public perception. The FPV racing market is all about the Hype Cycle. Ardupilot cannot hope to keep up. While I can appreciate that Leonard is using Ardupilot for these very large FPV racers, it's a very small use-case. Even if you do not agree with that projection, I do not think that the wants and desires of that endeavor, should be over-running the control strategy that the vast majority of the existing users want. Most of our users, cannot even understand why a copter would keep drifting in the wind after they've released the sticks in a non-GPS mode. They certainly will not understand why the copter would keep rotating after they have released the yaw stick. Given their sense of orientation is often tenacious at best... why would a controller ever give Phantom Movements. Acro is one thing. Only skilled pilots use Acro. But the yaw controller is used the same way across modes, from Acro, to Loiter.
And it could not be any simpler than this:
I have attempted to make Ardupilot for Heli attractive to existing helicopter users. Whether beginner, or scale, or sport flying, I want them to try using it. I have attempted to emulate the behaviors of existing FBL controllers. They work very well, people like them, people are familiar with them. Having the controller give rate outputs when the sticks are centered, is not going to be accepted.
Everybody wants the rate controller to do it's very best to achieve the demanded rates. Nobody questions that.
I've never heard anybody state that they want the controller attempt to output a rate other what the control inputs are currently demanding.
It's just that simple.
Maybe there's a good use-case for FPV flying where the pilot's orientation is lost, and the controller can take it back faster than the user can. Fine. Provide an option for that. But it's hubris to force your will on others, especially when it's counter to every control system ever engineered before. It's not because you're just smarter than everybody else. This exact issue has been thought about at great length by others equally as smart. And it's been decided, time and time again, that electronic rate controllers should not sum rate demands. Period. It's a live rate command. That's it.