On Monday 25 Jan 2010, Pete Morgan wrote:
> thanks lee for the reply, particular about the "thinking it
> through" part; and am already thinking about a problem I've
> encountered, although I'm still trying to get the hang of the
> autopilot.
>
> VNAV. - (don't know how to explain the problem well)
>
> I've managed to get the Altitude hold, Vertical Speed, glidescope
> and Pitch to work well individually,
> eg the Altitude Hold has a spike filter on the <input> which
> removes the "lurches" and violent movements.
>
> However switching between the VNAV modes causes the "elevator"
> which all the PID's are individually driving to "Jump" to a new
> position. eg switching from -1000 fps vertical speed descent to a
> climb to altitude hold above.
> This "immediate elevator jump" can be clearly seen on the yoke
> and the HUD elevator indicator and causes the aircraft to bounce
> around.
>
> I'm not sure how to tackle this problem, or indeed what the real
> problem is.
>
> One thought would be to make ALL the vnav PID's/calculations feed
> a single output such as "target-climb-rate-fps",
> and then this would be filtlered to manipulate the elevator. That
> would mean making some convertion eg from the glideslope to
> "target-climb-rate-fps".
>
> Another would to have some sort of "crossfade" as the PID's swap
> from one to another.
>
> Are there any existing solutions to this problem.
>
> Any advice greatly appreciated.
>
> regards
> pete
The large initial deflections you can get when switching between
different controller cascades seems to occur because on the first
iteration the controller sees an error but has no 'trend history'
to know how effective its correction is, and so may command the max
correction. As the aircraft responds to the initial correction
though, the controller gets feedback upon which it then gauges the
correction for the next iteration.
There are a number of ways around this, from limiting the flight
control surface rate, either in the FDM config, or by inserting a
filter between the output from the controller and the control axis
input of the FDM, to filtering the target inputs, to using common
pid controllers in the control hierarchy.
I ended up using a three controller hierarchy in some aircraft, with
the same lower-level controllers being used by all modes and which
were always engaged; only the top level controllers were switched.
For example, for altitude-hold I might have the following hierarchy:
Altitude-hold: generates a target climb-rate in FPS from the
difference between the current altitude and the target altitude.
Climb-rate-hold: generates a target pitch angle from the
difference between the current climb-rate and the target
climb rate generated by the Altitude-hold controller.
Pitch-hold: generates an elevator deflection from the
difference betwen the current pitch and the target
pitch generated by the Climb-rate-hold controller.
but then I'd use the same Climb-rate-hold and Pitch-hold controllers
for the glideslope-hold hierarchy and just switch the Top level
Altitude hold controller off instead of duplicating the entire
hierarchy again.
Because the lower-level controllers are running continuously and are
not switched on and off they've got some trend history data to be
working with and this seems to ameliorate the problem by
effectively buffering the top-level input change.
This type of hierarchy isn't without its own problems though; at low
airspeeds you might need the Pitch-hold controller to be pretty
brutal and almost driving into oscillation but at high speeds you
need it to be much more delicate. However, judicious use of
filters and variable gains can usually get you around most
problems.
There is one type of autopilot problem that's more difficult fix
though: the autopilot controllers and filters should run at a
constant rate and although a <rate> parameter was added and
initially worked, I think it may have become broken at some point
and the rate at which the controllers and filters operate depends
more upon the frame rate than anything else. Because the rate at
which the controllers work is critical, depending upon the gains
used, a controller that might be stable on one system might become
unstable on a slower, or even sometimes a faster system (I've seen
this sort of problems happen both ways).
LeeE
------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
