Howto:Design an autopilot: Difference between revisions

Jump to navigation Jump to search

Howto:Design an autopilot (view source)

Revision as of 13:30, 5 May 2010

5,906 bytes added ,  5 May 2010
no edit summary
(Use the instrument airspeed value, not the 'raw' value, for the auto-throttle example.)
No edit summary
Line 168: Line 168:
  </pid-controller>
  </pid-controller>


And a filter, as our autopilot does not throttle up/down in split seconds. Depending on the number of engines of your aircraft, you might want to add more or delete some output properties.
And a filter, as our autopilot does not move the throttle levers up/down in split seconds (you can imagine how that would be potentially harmful to the flight crew). Depending on the number of engines of your aircraft, you might want to add more or delete some output properties.
  <filter>
  <filter>
   <name>SERVO-DRIVER:throttle</name>
   <name>SERVO-DRIVER:throttle</name>
Line 187: Line 187:
   <max-rate-of-change>0.1</max-rate-of-change>
   <max-rate-of-change>0.1</max-rate-of-change>
  </filter>
  </filter>
==Vertical speed hold==
Let's start with some thinking. For vertical-speed-hold, the controller has to compare your current rate-of-climb with your reference rate-of-climb. The ROC will be controlled by setting the pitch of the aircraft. We already have a pitch-hold controller, so we will set the target-pitch from our rate-of-climb controller. To not make our passengers barf when we enable our controller, it's important to set the target-pitch relative to our current pitch - which once again calls for a pid-controller (because of it's relative output).
To get the current pitch to a property which will be modified by a pid-controller later, we will now create a controller which serves as a so called "sample-and-hold" element. It simply copies the input property value to the output property value until it is disabled. The same property, that disables the sample-and-hold controller will enable the pid-controller that computes the pitch for the rate-of climb.Here is a sample-and-hold controller implemented with a gain-filter:
<filter>
  <name>AP:Pitch sample and hold</name>
  <debug>false</debug>
  <enable>
  <condition>
    <not>
    <property>/autopilot/locks/roc-lock</property>
    </not>
  </condition>
  </enable>
  <type>gain</type>
  <gain>1.0</gain>
  <input>/orientation/pitch-deg</input>
  <output>/autopilot/internal/target-pitch-deg</output>
</filter>
You probably have to adjust the property names. Note the condition element in the <enable> section - it has the same syntax as in the well-known <animation> elements. As long as the roc-lock property is false, input is copied to output. When it becomes true, the output property is no longer written by this filter and the next step can use this value as a start.
Right behind this filter, add a pid-controller using your current rate-of-climb as input and a target-rate-of-climb as reference. Enable this pid if your pitch sample-and-hold is not enabled (use the same condition, just remove the <not> elements). Your output goes to target-pitch-deg which should be the same property as the input of your pitch-hold controller. Use the same procedure to obtain the values for Kp and Ti. Kp will be small. The offset computes in feet per minute and 100fpm should result in a few degrees pitch change. Something like 0.01 or smaller will probably do. I'd expect Integrator time around 10-50. You should clamp the target-pitch to something less than +/- 90 degrees - probably -10 and +20 degrees or whatever is a reasonable value for your aircraft. It could look like this:
<pid-controller>
  <name>Vertical speed pitch hold</name>
  <debug>false</debug>
  <enable>
  <condition>
    <property>/autopilot/locks/roc-lock</property>
  </condition>
  </enable>
  <input>
  <prop>/autopilot/internal/vert-speed-fpm</prop>
  </input>
  <reference>/autopilot/settings/vertical-speed-fpm</reference>
  <output>
  <prop>/autopilot/settings/target-pitch-deg</prop>
  </output>
  <config>
  <Kp>0.001</Kp>
  <Ti>10.0</Ti>
  <Td>0.0</Td>
  <u_min>-10.0</u_min>
  <u_max>10.0</u_max>
  </config>
</pid-controller>
==Logic-controlled properties==
These two new elements should give you a rate-of-climb hold mode for your autopilot. If you are not yet confused which controllers should be enabled in what mode, you will be very soon as we will add even more elements. If you are in the need for some logic-controlled properties, the autopilot can do this, too - no need for [[nasal]] helpers! There is a <logic> element that does all the magic:
<logic>
  <name>Electrical Power</name>
  <input>
  <greater-than>
    <property>systems/electrical/outputs/autopilot</property>
    <value type="double">10.0</value>
  </greater-than>
  </input>
  <output>autopilot/has-power</output>
  <output>autopilot/servicable</output>
</logic>
This creates two boolean properties: has-power and serviceable, and sets them to true if the electrical system provides more than 10.0 volts. You can build complex logic tables to drive your analog stages of the autopilot.
==Altitude hold==
Now, that you have a ROC-hold mode, you most certainly want an altitude-hold with preselect. This will be a simple linear amplifier without any time dependencies. Again, you have to compare your current altitude with a reference value, but this time there will be no integrator involved. The bigger your offset from the reference altitude is, the bigger your rate of climb/descent should be. Let's assume, 1000ft offset should result in 500fpm ROC. The maximum rate of descent should be 1000fpm and the maximum rate of climb should be 2000fpm. Since there is no integrator involved, we use a simple gain filter to compute the rate of climb:
<filter>
  <name>Target Rate of Climb Computer (ALT HOLD)</name>
  <debug>false</debug>
  <enable>
  <prop>/autopilot/locks/altitude</prop>
  <value>altitude-hold</value>
  </enable>
  <type>gain</type>
  <input>position/altitude-ft</input>
  <reference>autopilot/settings/target-altitude-ft</reference>
  <gain>-0.5</gain> <!-- 1000ft offset gives 500fpm roc -->
  <output>autopilot/internal/target-roc-fpm</output>
  <min>-1000</min>
  <max>2000</max>
</filter>
If everything goes well, your chain of controllers for altitude hold looks something like this:
# '''Target Rate Of Climb Computer''' target-rate-of-climb = (reference-altitude - current-altitude) * 5
# '''Target Pitch Computer''' computes target-pitch-deg as a function of current-roc and target-roc
# '''Elevator Command Computer''' computes elevator-deflection as a function of current pitch and target pitch
# '''Elevator Servo Driver''' makes smooth movements of the elevator
This is nearly all for altitude-hold with altitude-preselect. You can add an altitude-sample-and-hold stage to add a "hold my current altitude" function.


[[Category:Aircraft enhancement|Design an autopilot]]
[[Category:Aircraft enhancement|Design an autopilot]]
[[Category:Howto|Design an autopilot]]
[[Category:Howto|Design an autopilot]]
Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/21306"

Navigation menu