Just wondering if anyone has considered a flight mode between MANUAL and ACRO where it would behave like the gyro stabilizers do and only provide momentary correction to disturbances (like wind gusts) rather than locking attitude the way that ACRO does.
That way you could make a “sporty” plane better tolerate gusts and turbulance than in MANUAL mode, while still having all the safety features of Ardupilot (fences, failsafe, RTL, etc.).
Is there a documentation bug? It says this near the top of that page:
When flying in ACRO the aircraft will try to hold its existing attitude if you have no stick input. So if you roll the plane to a 30 degree bank angle with 10 degrees pitch and then let go of the sticks, the plane should hold that attitude. This applies upside down as well, so if you roll the plane upside down and let go of the sticks the plane will try to hold the inverted attitude until you move the sticks again.
It then says:
So to perform a simple horizontal roll, just start in level flight then hold the aileron stick hard over while leaving the elevator stick alone. The plane will apply elevator correction to try to hold your pitch while rolling, including applying inverse elevator while inverted.
Performing a loop is just as simple - just start with wings level then pull back on the elevator stick while leaving the aileron alone. The controller will try to hold your roll attitude through the loop.
Is the above written under the assumption that ACRO_LOCKING is enabled?
I did a brief bench-test experiment, and by default ACRO mode provided an impulse response to counteract a disturbance. In my experiment rolling the flight controller quickly 90 degrees to the right and holding it there resulted in a short pulse on the aileron outputs to counteract the roll, then the servo output returned to center even though the flight controller was still rolled 90 degrees.
After enabling ACRO_LOCKING, rolling the flight controller quickly 90 degrees to the right resulted in the aileron outputs deflecting and remaining deflected.
So I think the docs on the ACRO mode need to be updated to make it clear that without ACRO_LOCKING there is no attempt to maintain attitude over longer periods of time.
When flying in ACRO the aircraft will try to hold its existing attitude if you have no stick input. So if you roll the plane to a 30 degree bank angle with 10 degrees pitch and then let go of the sticks, the plane should hold that attitude.
Without ACRO_LOCKING this is only true for very short timeframes. It will only give an impulse correction to a disturbance, and if that correction is not enough it won’t do anything further.
As it stands, the documentation doesn’t really make it clear what the difference is between having ACRO_LOCKING and not having it.
I will eventually flight test it, but it’s still below freezing.
But it doesn’t need flight testing to realize that the existing description (about trying to hold attitude, with no mention of timeframe) more closely matches the ACRO_LOCKING behaviour than the default behaviour.
I see your point… and it sounds like you understand how ACRO works both with and without “locking” enabled.
Is there an “edit on github” link at the top right of that wiki page? You could easily suggest changes using that.
This is not true. The Integrator in the PID will provide attitude retention as long as it has the authority to do so. I demo this idea using ardupilot all the time. Acro locking is off. Then I only put P and D gain and zero I gain. The aircraft will not hold attitude. Then I add I gain and the aircraft will hold attitude. It isn’t precise but it will hold attitude. It does it very well in roll axis but it can be overpowered in the pitch axis with throttle because the integrator doesn’t have enough authority to fight the pitch changes caused by throttle changes
Acro mode is a rotation rate control mode.
The sticks command rotation rates around the aircrafts axis and the PID loops try to reach these rotation rates.
If you do not command a rotation rate on any axis, the aircraft will continue to fly in any attitude it is in, while the flightcontroller corrects for any disturbances. This is limited by how well the PID values are tuned and the performance of the aircraft. A high power 3d aircraft will stay in almost any attitude, while a heavy cargo aircraft will not be able to fly knife edge or climb indefinitly.
Your bench test shows the ailerons try to correct for the uncommanded rotation, but without actually flying (or in a windtunnel) the rudders have no way to correct the aircrafts attitude.
ACRO_LOCKING uses the accelerometers to activly hold and return the airplane into the given attitude as long as you do not give any stick input.
I’ll have to try it and see when the weather gets better, I guess.
Looking at the code, with ACRO_LOCKING disabled it does seem to be acting as a rotation rate control.
In this mode, suppose the plane is flying level with the sticks centered and the plane is subject to a wind gust that starts rotating it. There will be some delay before the flight controller brings the rotation rate back to zero. During that time it will have rotated by an amount given by integrating rate * time, which will change the attitude of the plane. Since it’s a rate control, there will be no attempt to return the plane back to the previous attitude, only to the previous rate.
If I were to roll 90 degrees with a high-wing trainer with a strong tendency to self-level and then take my hands off the controls, I would expect ACRO mode to dampen out wind gusts and turbulance but to still self-level.
That is not entirely true. The integrator acts to add up the attitude error and will apply inputs into the control system to zero the integrator which drives the aircraft back to its original attitude from which it was disturbed. So even though it is a rate controller, it does track pseudo attitude hold.
Are you sure the integrator will act on the attitude and not just the rate? In the code, libraries/APM_Control/AP_PitchController.cpp is a roll rate controller. The PID parameters are all documented as being related to the rate.
For the ACRO_LOCKED case the code is calling rollController.get_servo_out() which takes as input the desired bank angle and calculates a servo deflection from it. It actually disables the integrator entirely.
For the default case the code calls rollController.get_rate_out() which takes as input the desired roll rate, which feeds into the roll rate PID controller. So wouldn’t the I term be related to error in the rate, not the attitude?
If we have a momentary large disturbance that causes the plane to roll significantly with the sticks centered, I think the rate PID controller would act to bring the roll rate back to zero. But it shouldn’t bring the plane back to level.
Okay, I see what you mean. But there’s a gain on the I term that must be less than 1. And the purpose of the I term is to correct long-term differences between the desired rate and the actual rate. If the disturbance in the rate is large but short-lived the I term could be relatively small (due to the short time) even though the attitude change is large.