# Airplane parameters in xml, airplane model version 2

Also see helicopter model, version 1.

## 0 About this document

This document is not complete yet. It may be inaccurate or wrong, too.

This document should not provide examples. Please take a look at the files you got when downloading/installing CRRCSim. At the time of this writing only `superzagi.xml` uses more features than other files.

You need to know basics about xml files: they are structured text. Whitespace and line breaks do not matter in most places. Just take a look at the examples and you will understand.

The files can be edited using a text editor. There are lots of them. Use something like notepad, vi, emacs, joe...

### 0.1 Changes

24.08.2008 | J. W. Wulf | More detailed section 2, 'Units'. AR explained. Updated CD_prof description.
25.08.2008 | J. W. Wulf | Example for section `CG`.
17.09.2008 | J. W. Wulf | Added spoiler and flaps section.
17.09.2008 | J. Reucker | Explained 3D node attributes.
06.10.2008 | Bob Parks | More detailed explanations to some parameters.
17.12.2009 | J. Reucker | Added retract section.
23.12.2009 | J. Reucker | Added max_force attribute to spring section.
27.11.2011 | L. Gasparini | Modified flap and spoiler section.
29.12.2012 | L. Gasparini | Further modified flap and spoiler section.

## 1 General information

The first part of the file should be quite easy to understand. It contains a description of the model and a changelog. Whenever you edit such a file, please add a new `change` section and fill in what is needed. The example below shows a template.

    <?xml version="1.0" encoding="iso-8859-1" ?>
    <CRRCSim_airplane version="2">
      <description>
        <en>
            This plane has been automatically converted from superzagi.air.
            Please update this text if you know more about it.
        </en>
      </description>
      <changelog>
        <change>
          <date>Unknown</date>
          <author>CRRCSim 0.9.5</author>
          <en>Automatically converted from .air file.</en>
        </change>
        <change>
          <date>Please write date.</date>
          <author>Please write your name and email.</author>
          <en>Please write down what you changed.</en>
        </change>
      </changelog>

Every text is written in english, so it is enclosed in `<en> </en>`. If you want to add something in italian for example, you should enclosed it in `<it> </it>`.

## 2 Units

Some sections have an attribute `units`, which tells which units are used for the values in that section. The tables below have a column named 'unit' if the unit is fixed, otherwise they have columns like 'units=0' and 'units=1'.

For example, the section `aero` has attribute `units`. Its documentation below tells you that you can set this attribute to '0' or '1', which lets CRRCSim expect a value with the unit indicated by just that table column.

There is a file called non_SI_units.txt in the CRRCSim distribution which explains some strange units.

Some parameters (especially aerodynamic coefficients) are without dimension, so their unit is just '1' (not to be confused with 'units=0' or 'units=1'!).

Some parameters (like filenames) of course can't be said to have a unit, so their table entry is '-'.

## 3 Aerodynamics: section `aero`

This section can stand on its own, but can also be a subsection of `config`.

### 3.1 Subsection `ref`

The following table explains attributes in that subsection.

Name | Description | units=0 | units=1
--- | --- | --- | ---
chord | reference chord | ft | m
span | reference span | ft | m
area | reference area | ft^2 | m^2
speed | Reference speed for Re-scaling of CD_prof (speed at which drag is `aero.drag.CD_prof`). | ft/s | m/s

### 3.2 Subsection `misc`

Name | Description | units=0 | units=1
--- | --- | --- | ---
Alpha_0 | baseline alpha This is the reference angle of attack (alpha) where a lot of parameters are defined. It can be anything you want, but you have to be consistent. Common references would be the center line of the body, the mean camber line of the wing root airfoil or the bottom of a flat bottom airfoil. If you are doing analysis in AVL, its probably easiest to make this zero in the coordinates you use for the AVL model definition. In the AVL Stability Derivative output (ST command), this is labeled "Alpha". | rad | rad
eta_loc | eta_loc for stall model | 1 | 1
CG_arm | CG_arm for stall model, see below. | 1 | 1
span_eff | span efficiency: Effective span, 0.95 for most planes, 0.85 flying wing. This is a measure of how well the wing is working. As mentioned, .95 is a good value for a conventional, aft tail airplane. Some flying wings are essentially using the outer wing as a surrogate for the horizontal tail, so the number is lower. For a canard, it could also be low. AVL does a good job of estimating this parameter. In the Stability Derivative output dump, it is the parameter "e". This parameter will vary with angle of attack and stability margin, particularly if the wing has twist. For a glider, pick a case at relatively high CL, like near the best glide ratio angle of attack, or near minimum sink. This parameter only has a weak effect on the handling, so get it sort of close and dont worry about it. (it is a big effect on efficiency). Note that AVL tends to slightly over estimate this parameter, so you might want to multiply the AVL value by .95 or so. | 1 | 1

#### 3.2.1 `CG_arm`

Email from Mark Drela, 10.01.2006:

The stall model computes the values (dCL_left, dCL_cent, dCL_right) which represent the changes in CL due to stall.
To get the stall effect on the Cm, these are multiplied by the length CG_arm, which is the distance between the CG and the effective point of application of dCL:
dCm_stall = (0.25*dCL_left + 0.5*dCL_cent + 0.25*dCL_right)*CG_arm;

The typical value CG_arm = 0.25 means that the point of application of the averaged dCL is 0.25*chord ahead of the CG.

This CG_arm can be deduced from airfoil data. If dCL and dCm are the changes due to stall, the implied CG_arm is
CG_arm = dCm/dCL
Typically, both dCm and dCL will be negative, so CG_arm is positive.

You can also adjust CG_arm to get a realistic simulator pitch response due to stall. The larger CG_arm is, the more pitch-down you will get during stall.

### 3.3 Subsection `m`

These parameters deal with pitching moment, or how the airplane rotates about the pitch axis (up or down elevator). The actual value would be foot-pounds or Newton-meters. What we have here are coeffients, that do not have dimensions, so we can apply them to airplanes of similar configuration, but different sizes, airspeeds and air densities.

To take one of these coefficients and convert it to the actual moment we would use the equation:
M= 1/2 * rho * velocity^2 * wing area * wing chord * Cm

The first terms, "1/2 * rho * velocity^2" are what is called dynamic pressure, or the ram pressure of the air. (hold your hand out a car window to feel this!). "rho" is density of air. The moment is also proportional to the wing area (i.e. what the pressure works on) and the chord of the wing (which is the moment arm). The area and chord are called "reference parameters". Usually they are the actual area and the actual mean chord of the wing, but they could actually be any area or length, as long as you are consistent. In AVL, these values are actually inputs to the program. What counts is that you be consistent. They are listed in the ST dump as Sref (area) and Cref (chord). In this file, they are `aero.ref.area` and `aero.ref.chord`.

Note that the yaw and roll deriviatvies use the wing span as the reference length instead of the chord. That is Bref in the AVL output and `aero.ref.span` in this file.

There are several terms that add up to the total pitching moment.

Name | Description | units=0 | units=1
--- | --- | --- | ---
Cm_0 | baseline Cm at angle_of_attack = `aero.misc.Alpha_0`. This is whatever the Cm is at the reference angle of attack. It can be varied by the airfoil, the neutral setting of the elevator, twist in the wing etc. In the AVL ST output dump, it is called "Cmtot" | 1 | 1
Cm_a | pitch-moment / alpha (pitch stability). Basically, Cm = `aero.m.Cm_0` + `aero.m.Cm_a`*(Alpha - `aero.misc.Alpha_0`) This is the change in pitching moment due to changes in alpha (angle of attack). For a stable plane, this is negative, meaning if the angle of attack increases, there is a nose down pitching moment. It is the slope of the CM vs alpha curve, as measured near the reference angle of attack. In the AVL ST output, this is in the "stability axis derivatives" section, y mom row, alpha column, labeled Cma. | 1 | 1
Cm_q | pitch-moment / pitch-rate (pitch damping) q is the "non dimensional pitch rate" of the airplane. Basically, it is related to the loop diameter divided the wing chord. It is the pitch damping effect. Think of the tail as a long paddle swinging through the air. The faster you rotate it, the more moment it makes, and the moment tries to stop the rotation. For normal planes it is mostly proportional to the tail area times the SQUARE of the moment arm. The force varies as the tangental speed of the tail in the rotation, and that is the angular rate times the moment arm. We take the force, and multiply it by the moment arm to get the pitching moment. In the AVL ST output this one is in the "pitch rate q'" column, in the y mom. Cm row, and labeled Cmq. Its normally negative. i.e. a rotation rate causes a moment to try to stop it. | 1 | 1
Cm_de | pitch-moment / elevator Cm delta elevator. This is the elevator sensitivity, or how much pitching moment do you get for a unit deflection of the elevator (delta e is "change in elevator"). The way elevator is defined (trailing edge down is positive deflection) we want this to be negative. i.e. trailing edge up gives a nose up moment. You need to have defined an elevator in AVL before it will tell you what this parameter is, but the label on it in the ST output depends on the order you defined control surfaces, so its hard to give an example. It will be in the last block of outputs in the ST file, the column should be labeled elevator, or whatever you called that control in the AVL setup. The row will be "y mom Cm". If elevator was the second control defined, it would be labeled "Cmd2" | 1 | 1

### 3.4 Subsection `lift`

Name | Description | units=0 | units=1
--- | --- | --- | ---
CL_0 | baseline CL at angle_of_attack = `aero.misc.Alpha_0` | 1 | 1
CL_max | positive stall limit | 1 | 1
CL_min | negative stall limit | 1 | 1
CL_a | lift slope; lift-force / alpha, round about 2 pi / (1 + 2/AR). AR=wingspan/(average chord). Basically, CL = `aero.lift.CL_0` + `aero.lift.CL_a`*(Alpha - `aero.misc.Alpha_0`) | 1 | 1
CL_q | lift-force / pitch-rate | 1 | 1
CL_de | lift-force / elevator | 1 | 1
CL_drop | CL drop during stall break | 1 | 1
CL_CD0 | CL at minimum profile CD: 0.30 for 7037, 0.15 MH32, 0.0 RG15, AGxx, power | 1 | 1

### 3.5 Subsection `drag`

Name | Description | units=0 | units=1
--- | --- | --- | ---
CD_prof | profile CD at `aero.ref.speed` | 1 | 1
Uexp_CD | CD Re-scaling exponent; scales profile CD with Reynolds number via simple power law | 1 | 1
CD_stall | drag coeff. during stalling | 1 | 1
CD_CLsq | d(CD)/d(CL^2), curvature of parabolic profile polar: 0.01 composites, 0.015 saggy ships, 0.02 beat up ship | 1 | 1
CD_AIsq | drag due to aileron deflection. d(CD)/d(aileron^2) , curvature of ail. CD influence: 0.01/(max_aileron)^2 | 1 | 1
CD_ELsq | drag due to elevon deflection. d(CD)/d(elevator^2), curvature of ele. CD influence: 0.01/(max_elevator)^2 for Zagi otherwise 0 | 1 | 1

### 3.6 Subsection `Y`

Name | Description | units=0 | units=1
--- | --- | --- | ---
CY_b | side-force / sideslip | 1 | 1
CY_p | side-force / roll-rate | 1 | 1
CY_r | side-force / yaw-rate | 1 | 1
CY_dr | side-force / rudder | 1 | 1
CY_da | side-force / aileron | 1 | 1

### 3.7 Subsection `l`

Name | Description | units=0 | units=1
--- | --- | --- | ---
Cl_b | roll-moment / sideslip (crucial for rudder-only turns) | 1 | 1
Cl_p | roll-moment / roll-rate (roll damping) | 1 | 1
Cl_r | roll-moment / yaw-rate | 1 | 1
Cl_dr | roll-moment / rudder | 1 | 1
Cl_da | roll-moment / aileron | 1 | 1

### 3.8 Subsection `n`

Name | Description | units=0 | units=1
--- | --- | --- | ---
Cn_b | yaw-moment / sideslip (yaw stability) | 1 | 1
Cn_p | yaw-moment / roll-rate (yaw-roll coupling) | 1 | 1
Cn_r | yaw-moment / yaw-rate (yaw damping) | 1 | 1
Cn_dr | yaw-moment / rudder | 1 | 1
Cn_da | yaw-moment / aileron | 1 | 1

### 3.9 Subsection `flaps`

Lift, drag and moment coefficients are altered when using flaps. For an example, see `Skorpion.xml` and `Wasabi.xml`.

Name | Description | units=0 | units=1
--- | --- | --- | ---
drag | How much drag is added when using flaps? CD = CD_without_flaps + (flap_input^2) * `flap.drag` | 1 | 1
lift | How much lift is added when using flaps? CL = CL_without_flaps + flap_input * `flap.lift` | 1 | 1
moment | How much moment is added when using flaps? Cm = Cm_without_flaps + flap_input * `flap.moment` | 1 | 1
eff_ratio | How much of the initial flap effectiveness (lift/drag/moment derivative) is retained at the maximum deflection angle (flap_input=0.5) ? Flap effectiveness usually decreases for large deflections (> 10-20deg), e.g. when flap are also used as landing aids (cfr. Wasabi model). This non-linear behaviour can be simulated setting `flap.eff_ratio` < 1. Reasonable values of `flap.eff_ratio` range from 0.5 down to 0.1 for maximum deflection from 30 to 60deg. The actual effectiveness is evaluated as: flap.lift(@flap_input) = flap.lift * (1. - (1. - `flap.eff_ratio`)) * flap_input and similarly for drag and moment. | 1 | 1

Usually changing flap setting change pitching moment and thus alter the trimmed angle of attack (AoA), so that elevator position must be adjusted (trimmed) to either keep the angle of attack unchanged or to trim to the new desired AoA. If you set `flap.moment` = 0, then the trimmed AoA will stay constant.

Flap (camber changing flap) can also be used "mixed" with elevator, so that an elevator input also generate a flap deflection to optimize airfoil camber for the desired lift coefficient (e.g. flaps are lowered when elevator is pulled). To achieve this effect the elevator should be mixed into flap input: the right amount of mixing is model dependent.

### 3.10 Subsection `spoiler`

This is similar to `flap`, except that the drag effect is linear not quadratic and that there is no eff_ratio parameter (spoiler effect is linear).

### 3.11 Subsection `retract`

This subsection describes how a retractable gear influences drag and lift (similar to a spoiler). For an example, see `sport.xml`.

Name | Description | units=0 | units=1
--- | --- | --- | ---
drag | How much drag is added when the gear is not fully retracted? CD = CD_without_gear + (1.0 - retract_input) * `retract.drag` | 1 | 1
lift | How does the gear influence lift? CL = CL_without_gear + (1.0 - retract_input) * `retract.lift` | 1 | 1

Please note that `retract.lift` is usually a negative coefficient, because the gear will disturb the airflow when it is not fully retracted and the wheel wells are open.

### 3.12 Subsection `prop`

This subsection describes model-dependant interaction effects between propeller and aerodynamics. For an example, see `Angel_S30E.xml`.

Name | Description | units=0 | units=1
--- | --- | --- | ---
torquefactor | Which fraction of propeller's torque actually produce a rolling moment ? roll_torque = prop_torque * `prop.torquefactor` | 1 | 1

Please note that `prop.torquefactor` shall be a coefficient < 1 (default to 0.25), because propeller's slipstream produces an aerodynamic rolling moment counteracting torque effect. Changing the sign of `prop.torquefactor` to negative change the net rolling effect from rolling left to rolling right, i.e. simulating a counterclockwise rotating propeller (seen from the cockpit).

## 4 Configuration: section `config`

There can be more than one configuration for an airplane, so there may be several `config` sections. Because of this, each `config` needs a description.

      <config version="1">
        <descr_long>
          <en> Powerful motor which makes this config heavy, too.</en>
        </descr_long>
        <descr_short>
          <en>powerful and heavy</en>
        </descr_short>

Additionally, instead of using the general `aero` section, a `config` section can contain its own `aero` section (see k2.xml for an example).

### 4.1 Subsection `mass_inertia`

Name | Description | units=0 | units=1
--- | --- | --- | ---
Mass | Mass of airplane | slug | kg
I_xx |  | slug ft^2 | kg m^2
I_yy |  | slug ft^2 | kg m^2
I_zz |  | slug ft^2 | kg m^2
I_xz |  | slug ft^2 | kg m^2

### 4.2 Subsection `sound`

The `sound` subsection contains the description of the sound samples used for this airplane. Each sample is described in a `sample` subsubsection.

#### 4.2.1 Subsubsection `sample`

Name | Description | units=0 | units=1
--- | --- | --- | ---
filename | name of file for engine sound | - | -
type | Type of sound: 0 glow engine, 1 electric engine, 2 glider sound | - | -
pitchfactor | This number converts from speed of propeller to pitch of engine sound. | s | s
maxvolume | The maximum sample volume (0.0 ... 1.0). The loudest sample should be set to 1.0. | 1 | 1
v_min | Only for type=2: minimal velocity (relative to the airplane's "neutral" velocity) at which the sound can be heard | 1 | 1
v_max | Only for type=2: velocity (relative to the airplane's "neutral" velocity) at which the sound reaches maximum volume. | 1 | 1
dist_max | Only for type=2: distance at which the sound reaches the minimum volume | ft | m

### 4.3 Subsection `power`

There is a separate documentation (`../power_propulsionspower_propulsion.html`) which explains the power and propulsion system.

## 5 Graphics: section `graphics`

### 5.1 Specifying a 3D model file

This section binds one or more 3D models to an XML file. The 3D model is what you actually see on screen when loading this model XML file. There can be more than one graphical representation for an airplane (e.g. for different configurations or different finishs), so there may be several `graphics` sections. Because of this, each `graphics` needs a description.

        <graphics version="1" model="zagi.ac" >
          <descr_long>
            <en>Automatically converted from superzagi.air.</en>
          </descr_long>
          <descr_short>
            <en>default</en>
          </descr_short>

Currently you only need to specify the name of the graphics file.

### 5.2 A word on 3D model files

The PLIB library used in CRRCsim to display the airplane model graphics can handle a lot of different file types. However, files in AC3D format (.ac) or 3DStudioMax format (.3ds) seem to work best. Any decent modelling tool should be able to export at least one of these formats. AC3D, Blender and Wings3D have been reported to work fine for creating CRRCsim models.

### 5.3 Object names in 3D files

3D modelling tools usually compose the whole model (the content of the 3D model file) from objects. An object is a group of surfaces (or faces for short) defined by connected vertices (a vertex is a single point in 3D space).

On object level, a modelling tool usually allows the user to define arbitrary names for single objects. These names provide better orientation while modelling. In CRRCsim, object names are also used to manipulate objects in several ways, like animating model parts or controlling the rendering process. Therefore the following conventions have been defined:

- The object name assigned to a model part in a 3D modelling tool may contain blanks (space characters). However, CRRCsim only uses everything up to the first blank as the object's real name. If you assign the name "Right wing" to an object, CRRCsim will internally refer to this object as "Right". Therefore it is recommended to substitute blanks by underscore characters ("Right_wing") or use CamelCase notation ("RightWing").
- The rest of an object's name (everything after the first blank character) is treated as additional information ("attributes")for the 3D rendering process. An object with the name "Rotor_disc -shadow" is internally referred to as "Rotor_disc", and the attribute "-shadow" tells the 3D engine not to render a shadow for this part of the model.

### 5.4 Object attributes

The following rendering attributes (see the preceding section) are currently defined for 3D objects:

Attribute | Description
--- | ---
-shadow | This object shall not cast a shadow.

## 6 Hard points and wheels: section `wheels`

This section contains a number of entries, each of them describing one hard point on the airplane. The caster angle is specified with respect to the plane body's z-axis, a value of zero means that the wheel is oriented straight ahead (which should be the case for most gears).

Name | Description | units=0 | units=1
--- | --- | --- | ---
percent_brake | Percentage of max braking applied initially | 1 | 1
caster_angle_rad | wheel angle | rad | rad

### 6.1 Subsection `pos`

Position of hard point in body axes with regard to center of gravity. Unit is feet (`units="0"`) or meters (`units="1"`). x positive forward, y positive right, z positive down.

Remark: 3D modelling tools sometimes use other coordinate system orientations. In this case the coordinates of a hard point have to be converted into the CRRCsim coordinate system. Here's an example for AC3D and Blender:

Axis in XML file | Axis in AC3D | Axis in Blender
--- | --- | ---
+X | +Z | -Y
+Y | -X | -X
+Z | -Y | -Z

This means that a point in AC3D at X = -3.28, Y = 0.55, Z = -0.37 (this could be the right wingtip of a 2m sailplane) will result in the following position tag:

            <pos x="-0.37" y="3.28" z="-0.55" />

Hardpoints may be located on animated control surfaces (e.g. on a retractable gear). In this case, specify an additional attribute "animation" that contains the name of the control surface animation that controls this part of the 3D model. Example (from sport.xml):

            <pos x="0.41677001" y="0" z="0.52499998" animation="nose_gear" />

In this case, the <animations> section of the file should of course contain an element <object name="nose_gear" /> that defines the actual movement. See section 8 for more details on animations.

### 6.2 Subsection `spring`

This subsection defines the springiness of the hardpoint, e.g. if a collision of this hardpoint with ground makes the plane bounce, is damped by the hardpoint's flexibility or leads to a crash.

The flight dynamics model calculates the forces on each hardpoint resulting from interaction with the ground or solid objects. If this value exceeds the specified `max_force`, the plane will be considered as crashed. The `max_force` attribute is optional; if it is not specified, it will internally be set to a very high default value so that this hardpoint will only cause a crash on insanely high load.

Name | Description | units=0 | units=1
--- | --- | --- | ---
constant | spring constant, has to be positive | slug / s^2 = lbf / ft | N/m
damping | damping, has to be positive | slug / s = lbf / (ft/s) | N/(m/s)
max_force | maximum force, has to be positive | lbf | N

### 6.3 Subsection `steering`

In this subsection a mapping of the hardpoint to an R/C channel can be defined. Possible values for the "mapping" parameter are "NOTHING" (which makes this subsection redundant), "RUDDER", "AILERON" or "ELEVATOR". By specifying a negative value for max_angle the coupling from the control input to the wheel will be reversed. A positive angle should be correct for a tail wheel while a steerable nose wheel usually needs a negative angle.

Name | Description | units=0 | units=1
--- | --- | --- | ---
mapping | symbolic name of the R/C channel | - | -
max_angle | deflection of the wheel at full control input | rad | rad

Example: this maps a nose wheel to the rudder channel, giving 20 degrees (= 0.349 radians) of wheel deflection at full rudder input.

            <steering mapping="RUDDER" max_angle="-0.349" />

## 7 Center of gravity: section `CG`

Position of center of gravity in body axes with regard to coordinates used by `wheels` and the 3D graphics file.
Unit is feet (`units="0"`) or meters (`units="1"`). x positive forward, y positive right, z positive down. Example:

              <CG units="0" x="-0.2234252" y="0" z="-0.043131893" />

This section and values do not have to exist, it is optional. However, it gives you the following advantage: There is no need to create the 3D model (and the points in the `wheels` section) around the center of gravity. You can use any reference point and give the position of the CG using your coordinates in this section.

This also makes it possible to change the location of the CG without changing the 3D model and `wheels`.

You can visually check the position of the CG using test mode, as the airplane rotates around the center of gravity (given that throttle=0).

## 8 Animated parts: section `animations`

This section contains information needed to animate parts of the model, e.g. to move the control surfaces according to stick input. It is optional to define animations for a model; however it is strongly recommended to make use of this feature because it adds much to the appearance of a model.

To animate a part of a 3D model it is required that this part is modelled as an independent object in the 3D model file, and that the object has a unique name. A proper 3D modelling tool should allow one to group surfaces to objects and give them names, so this shouldn't be a problem.

The `<animations>` section contains one `<animation>` subsection per animated object. The `<animation>` tag must contain a `type` attribute to define the kind of animation that should be created. Currently only the type `ControlSurface` is implemented.

Name | Description | unit
--- | --- | ---
type | kind of animation | -

### 8.1 Animation type `ControlSurface`

This kind of animation is used to rotate an object of the 3D model around an arbitrary axis according to stick input. It can be used to animate control surfaces like elevator or ailerons, or to animate gears that retract with a rotational movement.

#### 8.1.1 Subsection `object`

This subsection defines the object to which the animation is applied and the maximum amount of movement.

Name | Description | unit
--- | --- | ---
name | name of the object in the 3D model | -
max_angle | control surface deflection at full control input | rad

#### 8.1.2 Subsection `control`

This subsection defines how the surface interacts with the input from the controller. `mapping` can be set to one of `RUDDER`, `ELEVATOR`, `AILERON`, `THROTTLE`, `FLAP`, `SPOILER`, `RETRACT` or `PITCH`. There can be more than one `control` section for a surface, e.g. there will be a mapping to `ELEVATOR` and `AILERON` if the model has elevon controls (aka "delta-mix"). The `gain` setting determines the relationship of the control input to the surface deflection. A `gain` value of `1.0` means that the surface will travel the full `max_angle` from the `object` section above if the associated control is moved to its extents. Negative `gain` values will reverse the surface movement.

Name | Description | unit
--- | --- | ---
mapping | symbolic name of the R/C channel | -
gain | control surface deflection at full control input | -

#### 8.1.3 Subsection `hinge`

To define the rotation axis of the control surface it is mandatory to define exactly two `<hinge>` subsections. The rotation will occur around an imaginary axis from the first to the second hinge, and the direction of the rotation can be determined by applying the right-hand rule to this axis. The X/Y/Z values are kind of unit-less ("OpenGL"-units). They can be determined by selecting a vertex close to the hinge point in the 3D modelling tool and then transforming the displayed vertex coordinates into the coordinate system described below (same as with the `<wheel>` positions described above).

Name | Description | unit
--- | --- | ---
x | X coordinate (positive forward) | -
y | Y coordinate (positive right) | -
z | Z coordinate (positive down) | -

This is an example for the animation of left and right aileron on an 1.6m aerobatics model, giving 20 degrees (= 0.349 radians) of control surface deflection at full aileron input, assuming that the aileron objects of the 3D model are called `ail_right` and `ail_left`:

            <animations>
              <animation type="ControlSurface">
                <object name="ail_right" max_angle="0.349" />
                <control mapping="AILERON" gain="-1.0" />
                <hinge x="-0.56" y="0.63" z="0.03" />
                <hinge x="-2.64" y="0.40" z="0.02" />
              </animation>
              <animation type="ControlSurface">
                <object name="ail_left" max_angle="0.349" />
                <control mapping="AILERON" gain="-1.0" />
                <hinge x="0.56" y="0.63" z="0.03" />
                <hinge x="2.64" y="0.40" z="0.02" />
              </animation>
            </animations>

## 9 Launch presets: section `launch`

This section is optional. It contains launch presets that will be shown in the launch dialog of the GUI if this airplane is currently selected. The <launch> section shall only contain <preset> tags, each one containing the attributes that describe the launch process like in CRRCsim's main configuration file.

Name | Description | unit
--- | --- | ---
name_en | name of the preset for the GUI dialog | -
altitude | launch altitude above ground | ft
velocity_rel | velocity relative to the trimmed flight velocity | -
angle | launch angle (+ means "nose up") | rad
sal | simulate side-arm-launch (0: no, 1: yes) | -
rel_to_player | use launch position which is relative to player (0: no, 1: yes) | -
rel_front | launch position relative to player: forward distance (backwards negative) | foot
rel_right | launch position relative to player: distance to the right (left negative) | foot

Example:

          <launch>
            <preset name_en="Gap65 default (ground)" altitude="0" velocity_rel="0" angle="0.22" sal="0"
                    rel_to_player="1" rel_front="1" rel_right="-2" />
          </launch>