Board index FlightGear Development Aircraft Autopilot and route manager

DHC-6 AP's ALT HOLD behavior

Designing a stable autopilot is one of the hardest things. Need help?

Re: DHC-6 AP's ALT HOLD behavior

Postby Octal450 » Sun Jul 22, 2018 1:05 pm

Hi,
Thorsten is correct, there are far too many PIDs in there, and tons of duplicated controllers. For example, why do NAV1 and HDG both have a Stage 2 that does the same thing? It's redundant, can under some conditions can be problematic since since the PropertyRule PIDs are "offset" based, so it's not an absolute value, but and offset from the <output> value.

In my autopilots, I usually have the cascade for Altitude like this:

Altitude error * gain = Target V/S FPM.
This doesn't need a PID, or even any integrator since the behavior is always the same.

Vertical speed error -> PID controller = target pitch degrees

Pitch degree error * gain = target pitch rate

Pitch rate error -> PID controller = elevator deflection

The reason we convert to pitch rate, is because since 0 rate means 0 rate, while in degrees, 14 deg might be 0 rate, or 5 deg might be 0 rate. Using rate makes these "offset" PIDs much more reliable since the action is far more linear than pitch degree control directly.

Outputting to trim and elevator both is a bad idea, instead it should control elevator, then adding an auto-trim below, which is only a single gain filter.

Regarding the oscillations, what I'd suggest is to restructure the file more simply. I can help out with that,but for that it may be best to join something like Discord or IRC, as it can get quite complicated. Once the layout is right, my approach for tuning PropRule PIDs is like this:
Start with Kp 0, Ti 1000000000000, and Td 0.0. To put it simply, the more Kp, the more proportional action, the more Td, the more derivative action, but the LESS the Ti, the more integrator action. Then, you can slowly increase Kp until it does not oscillate, but achieves what the demand is, then keep going until it gets unstable. Then bring the Kp back a little. From there, you want to increase Td VERY SLOWLY, if you add too much, either it will oscillate and vibrate the elevator, or when you enable the controller, it will go bad place then slowly correct itself. (JSBsim PIDs are much better if you need significant derivative action) You increase Td just a bit, it should make the response a bit more smooth, and can help to prevent overshooting. Lastly, start to decrease Ti, I usually bring it down first around 10.0, then go from there. The less Ti, the more the integration part will wind and slowly null steady state error. If you decrease it too far, it will start to oscillate. Most of the time, 1.0 to 10.0 is fine.

In terms of the altitude hold, you can just add a binding to the button that sets the altitude hold on, to a rounded current altitude, but this binding has to go before the altitude hold is engaged.
Code: Select all
<binding>
   <command>nasal</command>
   <script>setprop("/autopilot/settings/target-altitude-ft", math.round(getprop("/instrumentation/altimeter/indicated-altitude-ft"), 100));</script>
</binding>


That should do it.

Kind Regards,
Josh
Waste of time. Goodbye forever.
Octal450
 
Posts: 4398
Joined: Tue Oct 06, 2015 12:51 pm

Re: DHC-6 AP's ALT HOLD behavior

Postby Thorsten » Mon Jul 23, 2018 11:19 am

Vertical speed error -> PID controller = target pitch degrees


I wonder - does that step gain you anything? You're not putting any knowledge in here (like current weight or thrust) - you're just asking the integrator to fit the situation - which the lower-level integrator outputting the pitch channel is also asked to do - which opens the potential risk of two integrators working against each other (aka, they can both accumulate errors but have the net result zero).

Both in the Shuttle and in the Alouette-III I've managed to let the PID control the elevator channel directly from the vspeed error - which in essence also does a fit, just a little further down.

The Alouette works in a two-step scheme - first the altitude error drives a non-linear function to determine vspeed error, then the vspeed error drives a PID to determine pitch command. If you engage in cruise mode, this works just fine (in hover mode, altitude is determined by the collective setting, so of course the AP can't handle that, and Amelia is coded to fiddle with something like a Nasal PD controller to hold hover altitude).

So I'm just curious - did you run into a situation which made a pitch PID better behaved than a direct 2-step scheme?
Thorsten
 
Posts: 11057
Joined: Mon Nov 02, 2009 8:33 am

Re: DHC-6 AP's ALT HOLD behavior

Postby Octal450 » Mon Jul 23, 2018 1:30 pm

There are a few advantages to having it output to a pitch degree first, which mostly come from unusual situations:
Control based on pitch degree or rate is much more stable, in bad weather especially. This is due to how closely pitch and elevator are related, so, the loop becomes more stable since we are controlling the aircraft's rate itself. A V/S to elevator system works, but if other elements of instability are brought into the equation, (such as wind, or such), the controller will constantly lag far behind what needs to happen to keep the pitch stable. You could use G acceleration instead of Pitch for this same purpose, but I prefer using pitch as then I can easily limit the pitch angle limits of the A/P (which quite a few real life ones have also)

The integrators don't fight each other at all, the first one gets a pitch angle from v/s error, and the second achieves this pitch angle. If the first or second one wound up in a direction, it would it get farther from the error. For example, if you are stable, and the v/s integrator starts to go into a bad position, the target pitch angle would go in that direction also, and the second one would achieve the new pitch angle target. This does require that the pitch PID is quick enough to keep the pitch angle close to the target, but smoothly. With the loop properly tuned, that happens anyways.

tl:dr: It makes the whole A/P a bit more stable, and allows for other things to be added which don't rely on V/S without needing many different controllers.

Kind Regards,
Josh

PS: it may be easier to make the loop stable using PIDs in JSBsim, as the derivative (Kd) works better there.
Waste of time. Goodbye forever.
Octal450
 
Posts: 4398
Joined: Tue Oct 06, 2015 12:51 pm

Previous

Return to Autopilot and route manager

Who is online

Users browsing this forum: No registered users and 1 guest