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?

DHC-6 AP's ALT HOLD behavior

Postby duardo_cola » Wed Jul 18, 2018 7:31 pm

I've been flying the DHC-6 and it's an ouststanding aircraft, very nice flights to this day. But I have a few problems with the autopilot: The 'Altitude Hold' command does not hold the current altitude, but rather seeks the selected altitude like a Level Change mode. Also there's no 'Altitude Arm' for when the plane is climbing in V/S or IAS mode and reaches the selected altitude (it just flies past it).

Is there any way I can correct the Altitude Hold and possibly add an Altitude Arm to the DHC-6 autopilot?

Thanks in advance.
duardo_cola
 
Posts: 7
Joined: Wed Jul 18, 2018 7:26 pm

Re: DHC-6 AP's ALT HOLD behavior

Postby wkitty42 » Thu Jul 19, 2018 2:32 am

does the DHC-6 actually have those options and do they respond as you are expecting? what does the POH for the DHC-6 say?

in any case, yes, you might could add and fix up these functions... i can't tell you how because that's above my paygrade but it is possible to modify the code and enhance the craft...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 5695
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: DHC-6 AP's ALT HOLD behavior

Postby duardo_cola » Thu Jul 19, 2018 5:05 pm

Hello, and thanks for the response.

The autopilot in the DHC-6 for FlightGear seeks the altitude selected in the altitude panel by descending or climbing until it reaches that altitude.

In the real autopilot, the Altitude Hold mode would hold the current altitude the airplane is at, independent of what's selected. If you're climbing and engage ALT HOLD, it will stop climbing and stay at the current altitude.

The 'Altitude Arm' mode, on the other hand, halts the climb/descent whenever it reaches the selected altitude when in V/S (Vertical Speed) or IAS (Indicated Airspeed) modes.

I tried tweaking the autopilot's XML file by changing the inputs, references and outputs in several different combinations, but the closest I got to actually holding the current altitude was maintaining the aircraft in a 0-degree pitch attitude, but the altitude keeps fluctuating up and down.

If someone could enlighten me with some hints for changing the autopilot behavior or contacting the developers, I would be very glad to do so.
duardo_cola
 
Posts: 7
Joined: Wed Jul 18, 2018 7:26 pm

Re: DHC-6 AP's ALT HOLD behavior

Postby Thorsten » Thu Jul 19, 2018 5:16 pm

In the real autopilot, the Altitude Hold mode would hold the current altitude the airplane is at, independent of what's selected. If you're climbing and engage ALT HOLD, it will stop climbing and stay at the current altitude.


To summarize wkitty42's question - how do you know?

I tried tweaking the autopilot's XML file by changing the inputs, references and outputs in several different combinations, but the closest I got to actually holding the current altitude was maintaining the aircraft in a 0-degree pitch attitude, but the altitude keeps fluctuating up and down.


Keep doing it - it's an art, not a science. Enough damping will get rid of the oscillations eventually...
Thorsten
 
Posts: 11057
Joined: Mon Nov 02, 2009 8:33 am

Re: DHC-6 AP's ALT HOLD behavior

Postby duardo_cola » Thu Jul 19, 2018 7:51 pm

Hello Thorsten,

The DHC-6-300 would come out of the assembly line in several different configurations. Some had autopilots, some didn't, depending on what was ordered. One of the systems used for DHC-6 autopilot was the Honeywell H-14. It had simple 'HDG', 'ILS/VOR' and 'ALT' modes, as well as roll and pitch wheels. 'HDG' would follow, by applying roll, the selected Heading on the compass. 'ILS/VOR' would follow a VOR radial or ILS, and 'ALT' would hold current altitude. You could climb and control pitch/vertical speed using the pitch wheel. When you reached your altitude, 'ALT' mode came in.

A 'Level Change' mode that seeks a selected altitude makes no sense for such aircraft. Ideally, the 'Level Change' would change the power accordingly (climb power for climbing, idle for descending) and then climb or descend using pitch to regulate the airspeed, maintaining it steady until the required altitude is reached. The DHC-6 has no Auto-throttles nor FADECs, so Level Change is inexistent.
duardo_cola
 
Posts: 7
Joined: Wed Jul 18, 2018 7:26 pm

Re: DHC-6 AP's ALT HOLD behavior

Postby Thorsten » Fri Jul 20, 2018 7:17 am

Sorry, you're repeating yourself - I'm not asking what you believe the AP does, I'm echoing a question as to the source of this knowledge - have you flown the aircraft, have you been building it, have you read the manual, have you seen it in a different sim,...? Is the AP you describe perhaps just one variant out of several different ones and the implemented AP represents a different variant?

It's not really a problem to make an AP behave one way or the other - it's more that I'm not interested in two people making claims as to how things should be, I'm interested in verifiable facts how things are.

So the source of your knowledge matters here.
Thorsten
 
Posts: 11057
Joined: Mon Nov 02, 2009 8:33 am

Re: DHC-6 AP's ALT HOLD behavior

Postby duardo_cola » Fri Jul 20, 2018 5:48 pm

Hello,

Here are a few sources:
1) Viking Air's Service Bulletin 6/49, page 19, dated August 22 1967:

"Auto Pilot (H-14 Honeywell) Servos Protection Against Ingress of Water
Mod. 6/1051
(A/C 3 thru 49)"

Can be found here: https://www.vikingair.com/customer-support/technical-publications?page=19

That shows us there were, indeed, DHC-6s configured with Honeywell's H-14 autopilot system. Further on,

2) "Flying" Magazine, issued April 1962 on the Honeywell H-14 autopilot (starts in pages 36/37, finishes in pages 98/99/100):

Honeywell H-14 Adaptative Autopilot for Light Twins

"Continuing the climb, the throttles were set to hold 500 fpm. To check the automatic altitude control, the figure used to guarantee leveling out from either a climb or descent at a given altitude is 10 per cent of the rate. Fifty feet below 6,000 feet, the altitude (alt) button was depressed on. The H-14 had the aircraft level right at the desired mark without snapping the nose over. Once cruise speed was attained, all that remained was to retard the throttles and readjust rpm. Any use of the pitch command wheel while the H-14 is in the alt mode immediately disengages the alt button and allows the change in altitude. Altitude was held within a needle width."

Can be found here: https://books.google.com.br/books?id=W9hDaNOiAXEC&printsec=frontcover&hl=pt-BR&source=gbs_ge_summary_r&cad=0#v=onepage&q&f=false

3) Honeywell H-14 Control Unit for sale on e-Bay:

The image shows the actual control for the autopilot. HDG SEL for seeking the selected Heading; ILS/VOR for tracking a VOR radial or descend in an ILS approach; ALT for holding current altitude, plus a turn wheel to control bank angle and a pitch wheel to control rate of climb or descent.

Can be found here: https://i.ebayimg.com/images/g/1gkAAOSwax5Yvenu/s-l500.jpg

Doesn't resemble much what we can see in Flightgear: https://imagebin.ca/v/49MMiGeHk1Bj

Again, the DHC-6 is an amazing aircraft in FG. If we could make a realistic autopilot it would surely be one of the best available for the sim. I'm willing to help with anything I can.
duardo_cola
 
Posts: 7
Joined: Wed Jul 18, 2018 7:26 pm

Re: DHC-6 AP's ALT HOLD behavior

Postby Thorsten » Sat Jul 21, 2018 5:46 am

Which leaves the question

Is the AP you describe perhaps just one variant out of several different ones and the implemented AP represents a different variant?

(aka, proving 'existence' vs. 'exclusivity') but in that case one ought to be able to do variants as well.

So... your problem is oscillations, and the solution to that is to add more damping (the differential term of a PID controller). What do you know about coding APs in FG already and in particular about how the DHC-6 AP is implemented (that'd make it easier to target what I try to explain)?
Thorsten
 
Posts: 11057
Joined: Mon Nov 02, 2009 8:33 am

Re: DHC-6 AP's ALT HOLD behavior

Postby duardo_cola » Sat Jul 21, 2018 3:13 pm

It's incredibly difficult to find any material on the auto flight systems for the DHC-6. In fact, the H-14 is the only one I've ever found anything about, so I guess that's a good reference to base the Flightgear model on.

I have very little knowledge about FG development. Never worked on an addon, I just like to simulate my flights. All I did was try and move around a few things in the XML (I do know XML, just not how the sim logic works).
duardo_cola
 
Posts: 7
Joined: Wed Jul 18, 2018 7:26 pm

Re: DHC-6 AP's ALT HOLD behavior

Postby Thorsten » Sat Jul 21, 2018 3:32 pm

Okay, I'll have a look at the DHC-6 AP and then coach you how to change it. At the heart of it is tuning PID controllers, for which the JSBSim Manual has a good section about the theory behind it - maybe you can try to give it a read?
Thorsten
 
Posts: 11057
Joined: Mon Nov 02, 2009 8:33 am

Re: DHC-6 AP's ALT HOLD behavior

Postby tdammers » Sat Jul 21, 2018 6:31 pm

I believe the PID controllers in the existing AP are probably good enough already - they're well tuned and do exactly what the existing AP implementation needs: climb, descend, hold, either by vertical speed or by airspeed. You'd just have to change the control layer above those, that is, the logic that determines which rate of climb or descent to set, and when and how to change it. And of course the control panel would have to be changed.
tdammers
 
Posts: 227
Joined: Wed Dec 13, 2017 10:35 am
Callsign: NL256
IRC name: nl256

Re: DHC-6 AP's ALT HOLD behavior

Postby Octal450 » Sat Jul 21, 2018 7:10 pm

No... not at all. It's really just a tweaked generic autopilot, which is where a lot of it's stability problems and oscillations come from.

I've been looking for distractions, so I could give it a tune up if you'd like.

J
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 duardo_cola » Sat Jul 21, 2018 7:15 pm

I noticed the same behavior on many many aircraft, and pointed out the DHC-6 because it really is an outstanding addon.

Would it be possible to change the behavior for the Autopilot Altitide Hold in the Flightgear base code? For a future release or something like that? That would definitely improve the quality of several addons.
duardo_cola
 
Posts: 7
Joined: Wed Jul 18, 2018 7:26 pm

Re: DHC-6 AP's ALT HOLD behavior

Postby Thorsten » Sun Jul 22, 2018 5:48 am

I've been looking for distractions, so I could give it a tune up if you'd like.


Give a man a fish and you'll feed him for a day - teach him to fish and you'll feed him for a lifetime.

Here's someone who is interested and willing to learn - give him a chance to do this himself - and we might end up with one more knowledgeable person able to deal with AP issues :D

Would it be possible to change the behavior for the Autopilot Altitide Hold in the Flightgear base code?


No - APs have to be craft-specific. The response you get from elevator up 10 degrees depends on how big the elevator is, how fast you're going, how high you are, what the inertia tensor looks like,...

In fact, it isn't readily appreciated (because often FDMs are not good enough to show this) - APs have to be situation specific. The gains you need at Mach 1.5 aren't the gains you need at Mach 0.6 because in reality the action of the airfoils is highly Mach dependent (and, well, a really obvious example - altitude hold in inverted flight requires flipping sign on the gains - before you claim that isn't a real situation, the Shuttle has this issue during ascent... and in fact altitude hold during the roll to heads-up attitude requires use of the rudder channel mixed with the elevator channel...)
Thorsten
 
Posts: 11057
Joined: Mon Nov 02, 2009 8:33 am

Re: DHC-6 AP's ALT HOLD behavior

Postby Thorsten » Sun Jul 22, 2018 8:08 am

Okay, the DHC-6 AP seems to be done using the FG autopilot (i.e. not JSBSim), so the syntax for that is found here:

http://wiki.flightgear.org/Autopilot_co ... _reference

The first thing when designing an AP is to understand the control chain, aka what influences what.

What you want to control is the altitude. What you usually use for that is the elevator - so what's the relation?

What the elevator actually controls is the pitching moment - setting the elevator to some value gives a rotational acceleration. The integral of that is a rotation rate around the pitch axis. By initiating and terminating such a rotation, you can control aircraft attitude (within limits...). Aircraft attitude has a loose relation with vertical speed (dependent on horizontal speed and throttle setting, nose up may actually make you climb or just fall faster...) . The integral of vertical speed is altitude.

So trying to directly use an altitude error to drive elevator setting is a bad idea - the chain is long, there's unknown factors which complicate the matter at many links, trying to control an integral with a proportional response is also blurry,...

The solution is to break the problem into stages. For instance, it might be a good idea to define a target sink/climb speed dependent on how you are in relation to your target altitude (such that this target speed always stays within what the aircraft can do). That'd be one stage - so you have reduced the problem to controlling vertical speed with the elevator, which is already easier.

Here's the actual code of the DHC-6 from the repo:



Code: Select all
    <!-- altitude hold -->
    <pi-simple-controller>
        <name>Altitude Hold (Altimeter based) Stage 1</name>
        <debug>false</debug>
        <enable>
            <prop>controls/autopilot/settings/altsetflag</prop>
        </enable>
        <input>
            <prop>instrumentation/altimeter/indicated-altitude-ft</prop>
        </input>
        <reference>
            <prop>autopilot/settings/target-altitude-ft</prop>
        </reference>
        <output>
            <prop>autopilot/internal/target-climb-rate-fps</prop>
        </output>
        <config>
            <Kp>0.3</Kp>
            <Ki>0.0</Ki>
            <u_min>-33.3</u_min>
            <u_max>33.3</u_max>
        </config>
    </pi-simple-controller>

    <pid-controller>
        <name>Altitude Hold (Altimeter based) Stage 2</name>
        <debug>false</debug>
        <enable>
            <prop>controls/autopilot/settings/altsetflag</prop>
        </enable>
        <input>
            <prop>velocities/vertical-speed-fps</prop>
        </input>
        <reference>
            <prop>autopilot/internal/target-climb-rate-fps</prop>
        </reference>
        <output>
            <prop>autopilot/settings/target-pitch-deg</prop>
        </output>
        <config>
            <Kp>0.06</Kp>
            <beta>1.0</beta>
            <alpha>0.1</alpha>
            <gamma>0.0</gamma>
            <Ti>10.0</Ti>
            <Td>0.00001</Td>
            <u_min>-5.0</u_min>
            <u_max>5.0</u_max>
        </config>
    </pid-controller>

    <pid-controller>
        <name>Altitude Hold (Altimeter based) Stage 3</name>
        <debug>false</debug>
        <enable>
            <prop>controls/autopilot/settings/altsetflag</prop>
        </enable>
        <input>
            <prop>orientation/pitch-deg</prop>
        </input>
        <reference>
            <prop>autopilot/settings/target-pitch-deg</prop>
        </reference>
        <output>
            <prop>controls/flight/elevator</prop>
        </output>
        <output>
            <prop>controls/flight/elevator-trim</prop>
        </output>
        <config>
            <Kp>-0.02</Kp>
            <beta>1.0</beta>
            <alpha>0.1</alpha>
            <gamma>0.0</gamma>
            <Ti>1.0</Ti>
            <Td>0.00001</Td>
            <u_min>-0.5</u_min>
            <u_max>0.5</u_max>
        </config>
    </pid-controller>


So the first stage does exactly what I wrote above - it investigates the difference between current alt and target alt and outputs a vertical speed such that the vertical speed never exceeds 33 fps. Here just a simple proportional response is used, no PID controller.

Now the second stage inputs that and outputs a target pitch. Since the relation between pitch and vertical speed is rather loose (it depends on airspeed, aircraft weight, throttle setting,...) there's a full PID controller employed, with the idea that the integral term over time corrects the looseness.

The third stage them uses the airfoil to drive the aircraft to a target pitch, and since again there's considerable looseness here, there's a full PID used.

I believe generally nesting PIDs is a bad idea - there should be one PID at the lowest level of a control chain (controlling the airfoils) and all the higher levels of the control chain should be linear (proportional) or non-linear functions - two coupled PIDs invite all sorts of unwanted cross-coupling.

So there's two possible sources for the oscillations you see here - the coupled PIDs, or insufficient damping (the Td terms) inside the controllers.

What I'd do is to simplify the control chain to use just one PID and then proceed to tune that. But let's also hear what it0uchpods has to say on the matter, he's done this an awful lot for craft which are more similar to the DHC-6 than what I've designed in terms of APs.
Thorsten
 
Posts: 11057
Joined: Mon Nov 02, 2009 8:33 am

Next

Return to Autopilot and route manager

Who is online

Users browsing this forum: No registered users and 1 guest