JSBSim Altitude Hold Autopilot example

[Jon Berndt]

I've made some more progress in building an example autopilot using the
JSBSim flight control components. I already have a wing leveler for the
C-172, but I added an altitude hold module last night. The idea - in words -
behind the altitude hold concept (at least the way I have implemented it) is
that once a target altitude has been set, one can determine the error
between where you are and where you want to be. This error term is limited
to 100, filtered with a slight lag, and then multiplied by 0.1 in order to
get a commanded HDOT (time derivative of altitude, or rate of climb) of 600
ft/min. This error is run through the altitude hold switch, and either this
quantity or zero is passed to a proportional-integral controller (PI). The
output from these two components is summed, multiplied by an appropriate
gain, and the signal is sent to the elevator. I have a plot online of
altitude versus time as the C-172 is commanded to fly (from takeoff) to 800
feet, then 850, then 600, then 2000 ft:
http://www.jsbsim.org/JSBSimAltHoldAP.pdf

The autopilot is configured in JSBSim as follows:

<COMPONENT NAME="Altitude Error" TYPE="SUMMER">
INPUT -position/h-sl-ft
INPUT ap/altitude_setpoint
CLIPTO -100 100
</COMPONENT>

<COMPONENT NAME="Alt Error Lag" TYPE="LAG_FILTER">
INPUT fcs/altitude-error
C1 0.25
</COMPONENT>

<COMPONENT NAME="HDot Command" TYPE="PURE_GAIN">
INPUT fcs/alt-error-lag
GAIN 0.1
</COMPONENT>

<COMPONENT NAME="HDot Error" TYPE="SUMMER">
INPUT fcs/hdot-command
INPUT -velocities/h-dot-fps
</COMPONENT>

<COMPONENT NAME="AP Alt Hold Switch" TYPE="SWITCH">
<TEST LOGIC="DEFAULT" VALUE="0.0">
</TEST>
<TEST LOGIC="AND" VALUE="fcs/hdot-error">
ap/altitude_hold == 1
</TEST>
</COMPONENT>

<COMPONENT NAME="Integral" TYPE="INTEGRATOR">
INPUT fcs/ap-alt-hold-switch
C1 0.0041
</COMPONENT>

<COMPONENT NAME="Proportional" TYPE="PURE_GAIN">
INPUT fcs/ap-alt-hold-switch
GAIN 0.035
</COMPONENT>

<COMPONENT NAME="Control Summer" TYPE="SUMMER">
INPUT fcs/integral
INPUT fcs/proportional
CLIPTO -1.0 1.0
</COMPONENT>

<COMPONENT NAME="Elevator" TYPE="PURE_GAIN">
INPUT fcs/control-summer
GAIN -1.0
OUTPUT ap/elevator_cmd
</COMPONENT>

-- end --

I've got some ideas for future enhancements, including a scheduled target
rate-of-climb, so that the aircraft does not try and achieve 600 ft/min near
its service ceiling or something silly like that. Also to be added is an
automatic cutoff or safety feature, and perhaps the use of throttle to
control altitude as appropriate. I guess I really need to read up on
specific A/P operation, but this is presently being modeled to give the
ability for JSBSim aircraft to fly automatic batch runs for testing, etc.

I am going to include this in the JSBSim automatic flight document soon, and
will have a block diagram with this, too.

Jon

[Roy Vegard Ovesen]

Post by Jon Berndt
I've made some more progress in building an example autopilot using the
JSBSim flight control components. I already have a wing leveler for the
C-172, but I added an altitude hold module last night. The idea - in words
- behind the altitude hold concept (at least the way I have implemented it)
is that once a target altitude has been set, one can determine the error
between where you are and where you want to be. This error term is limited
to 100, filtered with a slight lag, and then multiplied by 0.1 in order to
get a commanded HDOT (time derivative of altitude, or rate of climb) of 600
ft/min.

This is a slightly unusual way of doing it, normally the commanded HDOT would
be limited to 600 ft/min instead of the altitude error. But this approach
works great too.

Post by Jon Berndt
This error is run through the altitude hold switch, and either this
quantity or zero is passed to a proportional-integral controller (PI). The
output from these two components is summed, multiplied by an appropriate
gain, and the signal is sent to the elevator. I have a plot online of
altitude versus time as the C-172 is commanded to fly (from takeoff) to 800
http://www.jsbsim.org/JSBSimAltHoldAP.pdf

From the plot it looks like the altitude hold performs very well. But if you
try another test where you control the throttle in such a way that the
aircraft is unable to hold a 600 ft/min vertical speed. I think you will see
that the integrator will wind-up as the "HDot Error" value never reaches
zero.

Post by Jon Berndt
<COMPONENT NAME="Altitude Error" TYPE="SUMMER">
INPUT -position/h-sl-ft
INPUT ap/altitude_setpoint
CLIPTO -100 100
</COMPONENT>
<COMPONENT NAME="Alt Error Lag" TYPE="LAG_FILTER">
INPUT fcs/altitude-error
C1 0.25
</COMPONENT>
<COMPONENT NAME="HDot Command" TYPE="PURE_GAIN">
INPUT fcs/alt-error-lag
GAIN 0.1
</COMPONENT>
<COMPONENT NAME="HDot Error" TYPE="SUMMER">
INPUT fcs/hdot-command
INPUT -velocities/h-dot-fps
</COMPONENT>
<COMPONENT NAME="AP Alt Hold Switch" TYPE="SWITCH">
<TEST LOGIC="DEFAULT" VALUE="0.0">
</TEST>
<TEST LOGIC="AND" VALUE="fcs/hdot-error">
ap/altitude_hold == 1
</TEST>
</COMPONENT>

This integrator will start winding whenever the elevator is saturating and
still unable to achieve the commanded climb rate.

Post by Jon Berndt
<COMPONENT NAME="Integral" TYPE="INTEGRATOR">
INPUT fcs/ap-alt-hold-switch
C1 0.0041
</COMPONENT>
<COMPONENT NAME="Proportional" TYPE="PURE_GAIN">
INPUT fcs/ap-alt-hold-switch
GAIN 0.035
</COMPONENT>
<COMPONENT NAME="Control Summer" TYPE="SUMMER">
INPUT fcs/integral
INPUT fcs/proportional
CLIPTO -1.0 1.0
</COMPONENT>
<COMPONENT NAME="Elevator" TYPE="PURE_GAIN">
INPUT fcs/control-summer
GAIN -1.0
OUTPUT ap/elevator_cmd
</COMPONENT>
-- end --
I've got some ideas for future enhancements, including a scheduled target
rate-of-climb, so that the aircraft does not try and achieve 600 ft/min
near its service ceiling or something silly like that. Also to be added is
an automatic cutoff or safety feature, and perhaps the use of throttle to
control altitude as appropriate. I guess I really need to read up on
specific A/P operation, but this is presently being modeled to give the
ability for JSBSim aircraft to fly automatic batch runs for testing, etc.
I am going to include this in the JSBSim automatic flight document soon,
and will have a block diagram with this, too.
Jon
_______________________________________________
Flightgear-devel mailing list
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

[Jon S Berndt]

Post by Roy Vegard Ovesen

Post by Jon Berndt
between where you are and where you want to be. This error term is limited
to 100, filtered with a slight lag, and then multiplied by 0.1 in order to
get a commanded HDOT (time derivative of altitude, or rate of climb)
of 600 ft/min.

This is a slightly unusual way of doing it, normally the commanded HDOT would
be limited to 600 ft/min instead of the altitude error. But this
approach works great too.

We don't [_currently_] have a climb rate property in ft/min, although
we could add this easily, and I could also "manufacture" it in the AP
using a gain. I finished this up at 3 a.m. this morning, so keep that
in mind! I think your observation is a good suggestion for a
modification, though.

Post by Roy Vegard Ovesen
From the plot it looks like the altitude hold performs very well.
But if you try another test where you control the throttle in such a way
that the aircraft is unable to hold a 600 ft/min vertical speed. I think
you will see that the integrator will wind-up as the "HDot Error" value
never reaches zero.
This integrator will start winding whenever the elevator is
saturating and still unable to achieve the commanded climb rate.

Yep. I've got a wind-up protection feature in the integrator, but I
haven't used it, yet - that's another area where I want to add some
"protection".
Jon