From: Roy Vegard Ovesen <[EMAIL PROTECTED]>I am currently in the process of implementing the Bendix/King KAP 140
autopilot. This is a rate based autopilot, it uses the turn rate and rate
of climb as its primary inputs. The turn indicator instrument implements a
low-pass filter so that the indicated turn rate output from this
instrument is a bit sluggish. This sluggishness is bad for controller
performance because it adds a time delay. I see two possible solutions:
A lot of autopilots have a rate-of-turn hold input, not just the KAP140, so this is a generic problem. Avoid any hacks specific to this device.
Noted. My next project will probably be the S-TEC System Twenty/Thirty series.
Which is also rate-based. I figure the control system wil be very similar.
It is possible that the low pass is too strong, but I'd have to study it. The turn indicator is a gyro instrument and, unlike the VSI for example, doesn't actually have an inherent low pass that we _have to_ model right.
So in the real world a responsive turn rate indication would be available, right?
The low pass is primarily due to the fact that both the display routine and the underlying FDM are running in observable timestep increments. If we don't filter the data then the instrument looks different to the pilot because the increments actually modulate subtle changes in the indication so they become easier for the pilot to see and act upon. As a result, the aircraft becomes unnaturally easy to fly on instruments.
However, there are other human-corrective hacks we can do to the data.
1) Increase the responsiveness of the turn indicator. I'm not a pilot and
I've never seen a turn indicator in action so I don't know how resposive
these instruments are, so maybe increasing the responsiveness isn't a good
idea.
Because the low pass is computed digitally without any noise contribution,
you can back it out in the AP algorithm. I'm not suggesting you use a
filter with a carefully-placed zero to recover the raw signal though.
Instead, I suggest you put in a stronger differentiator term in the loop
and/or use a separate roll rate feedback loop from the roll angle feedback.
I could try that, but the PID algorithm also includes a low-pass filter on the derivate error, so that might kill this approach. Since the KAP140 (and S-TEC) do not get any input from the roll indicator, I will try to avoid that if possible.
Bear in mind that the TC signal is a composite of rate-of-turn and of rate-of-bank because the gyro is mounted at an angle, so the instrument can indicate a standard rate of turn when the nose has not moved at all. Thus, your feedback loop might be responding to the bank data component.
Yes, but that would also be the case for the real world KAP140 and S-TEC, right!?
2) Add another output property from the turn indicator instrument with higher responsiveness.
The lazy solution is to ignore the property associated with the instrument
and feed directly off the raw body data. The problem with doing that is
(a) it is not intuitive when working on the XML configuration files
(b) doesn't give the correct behavior for instrument failure situations
Point (b) is one of my goals to avoid.
I'm thinking that adding a second indicated-turn-rate property that is filtered with a higher bandwidth would be a good solution.
-- Roy Vegard Ovesen
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
