Re: [Flightgear-devel] JSBSim Altitude Hold Autopilot example

2004-04-30 Thread Roy Vegard Ovesen
On Friday 30 April 2004 13:59, Jon Berndt wrote:
 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.

 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

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.


 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


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

 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
 [EMAIL PROTECTED]
 http://mail.flightgear.org/mailman/listinfo/flightgear-devel

-- 
Roy Vegard Ovesen


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] JSBSim Altitude Hold Autopilot example

2004-04-30 Thread Jon S Berndt
 Roy Vegard Ovesen [EMAIL PROTECTED] wrote:

On Friday 30 April 2004 13:59, Jon Berndt wrote:

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.

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

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel