Airframe Configuration

Airframe Configuration

Modules

Subsystems

Airframe Configuration

Autopilot generation

Fixedwing Configuration

Rotorcraft Configuration

About

The airframe file is the most important configuration file and contains all the hardware and software settings for your airframe. It describes what hardware you have and which firmware, sensors, algorithms, etc. you want to use and also holds your configuration parameters. All gains, trims, and behavior settings are defined with standard XML elements.

The XML airframe configuration file is located in conf/airframes/<yourairframe>.xml and always begins with a <!DOCTYPE airframe SYSTEM "airframe.dtd"> line.

Also see the wiki pages for fixedwing specific configuration and rotorcraft specific configuration.

Creating a new Aircraft

While the airframe file is where you configure most aspects of your aircraft, a fully specified aircraft needs several XML configuration files:

• Airframe (what this page is about)
• Flight Plan
• Settings
• Radio (if you use a PPM based R/C system)
• Telemetry

Each aircraft is assigned a name, unique ID and the associated configuration files in conf/conf.xml. To create a new Aircraft, click new in the menu A/C in the Paparazzi Center and select your new airframe file, etc. (or specify it by hand in conf/conf.xml).

Firmware and Hardware definitions

First you should specify which firmware you want to use, i.e. if you have a fixedwing aircraft or a rotorcraft:

File: conf/airframes/myplane.xml

<firmware name="fixedwing or rotorcraft"> ... </firmware>

Select your Board

To specify autopilot hardware you are using and it's low-level settings you have to add a target "ap" (autopilot) with board attribute.

Select the appropriate hardware autopilot board you are going to use in your airframe: "booz_1.0", "classix", "hb_1.1", "lisa_l_1.0", "lisa_l_1.1", "lisa_m_1.0", "lisa_m_2.0", "logom_2.6", "navgo_1.0", "pc", "sdlog_1.0", "tiny_0.99", "tiny_1.1", "tiny_2.1", "tiny_2.11", "twog_1.0", "yapa_2.0", "umarim_1.0", "umarim_lite_2.0"

File: conf/airframes/myplane.xml

<firmware name="fixedwing or rotorcraft"> <target name="sim" board="pc"/> <target name="ap" board="lisa_m_1.0"/> ... </firmware>

Note that the "pc" is a special kind of "board", and is mostly used only for simulation flights of an autopilot via your computer.

Direct Makefile

Optionally you can also add a raw Makefile section. This is only needed in very advanced setups. For example when testing newly developed hardware.

LEDs

You can configure the LEDs on the autopilot to be used for different status indicators:

SYS_TIME_LED

blinks with 1Hz

AHRS_ALIGNER_LED

blinks until the AHRS is aligned (gyro bias initilalized) and then stays on

GPS_LED

blinking if trying to get a fix, on if 3D fix

RADIO_CONTROL_LED

on if RC signal is ok

BARO_LED

only on booz and navgo boards: blinks until baro offset is initialized and then stays on

Depending on your board some of the LEDs on it are already assigned to some indicators by default, check the appropriate autopilot board page for the defaults. Use a configure node in the firmware section to assign an indicator to a LED number or disable that with none:

File: conf/airframes/myplane.xml

<firmware name="fixedwing or rotorcraft"> ... <configure name="SYS_TIME_LED" value="1"/> <configure name="RADIO_CONTROL_LED" value="2"/> <configure name="GPS_LED" value="none"/> </firmware>

Beware that you can only assign one indicator to a LED number. So if the LED you want to use is already in use because another indicator is set to that number by default you have to disable that other indicator by setting it to none.

IMU

Add the imu subsystem with the type you are using.

File: conf/airframes/myplane.xml

<firmware name="fixedwing or rotorcraft"> ... <subsystem name="imu" type="aspirin_v1.5"/> </firmware>

See the imu subsystem page for more details. Also see the IMU calibration page.

AHRS

The AHRS subsystem specifies which attitude estimation filter you are using, e.g. for the complementary filter:

File: conf/airframes/myplane.xml

<firmware name="fixedwing or rotorcraft"> ... <subsystem name="ahrs" type="int_cmpl_euler"/> </firmware>

All AHRS algorithms depend on an imu subsystem, except for the ahrs_infrared which depends on the infrared module. See the AHRS subsystem page for more details.

Radio Control

Supported types are:

• ppm
• spektrum
• datalink

Just specify the appropriate radio control subsystem in your firmware section, e.g.:

File: conf/airframes/myplane.xml

<firmware name="fixedwing or rotorcraft"> ... <subsystem name="radio_control" type="ppm"/> </firmware>

Telemetry (Modem)

The modem protocol and baud rate must be set in both the airframe file and ground station. Any standard baud rate can be used, with 9600 being adequate and 57600 recommended for most users to allow high speed telemetry for more detailed flight data analysis. The actual data rate is determined by the number of messages being sent and the period of each message as defined in your telemetry file, e.g. conf/telemetry/default.xml. Those wishing to experiment with "alternative" modems can reduce the number and period of each telemetry message to fit within most any bandwidth constraint.

Paparazzi supports the following modem protocols:

• Standard transparent serial (pprz) - this is compatible with all modems and can be used to connect the autopilot directly to a PC for testing without a modem.
• Maxstream API protocol (xbee) - compatible with all Maxstream modems including the 9XTend and Zigbee. This protocol enables hardware addressing, allowing multiple aircraft to be managed from a single ground modem.

Just specify the appropriate subsystem in your firmware section. You can currently choose between the types transparent, transparent_usb and xbee_api.

The default baudrate is 57600 baud!

File: conf/airframes/myplane.xml

<firmware name="fixedwing or rotorcraft"> ... <subsystem name="telemetry" type="transparent"> <configure name="MODEM_BAUD" value="B9600"/> </subsystem> </firmware>

Note that above the default of 57600 is being changed to 9600. If you wish 57600 you must be sure your modem is configured for 57600 and you would remove the <configure_name="MODEM_BAUD" line. Don't forget to add the "/" after the "transparent" to close the subsystem tag (and also not have </subsystem> ending tag. See the telemetry subsystem page for more details.

GPS

The serial port settings must match that of the GPS and are configured here along with the necessary files to interpret the u-blox UBX binary protocol:

Just specify the appropriate gps subsystem in your firmware section. You can currently choose between the types ublox and ublox_utm for the older series 4 modules which still provide a UTM message.

File: conf/airframes/myplane.xml

<firmware name="fixedwing or rotorcraft"> ... <subsystem name="gps" type="ublox"/> </firmware>

The correct UART is already defined by default according to your board. The default GPS baudrate is 38400baud.

If you need to set different baud rates or UART see the Subsystem/gps page for the options.

Note:

• u-blox GPS modules are factory configured for 9600 baud, 38,400 baud is recommended along with the other required changes. The GPS can be accessed directly thrugh the UART Tunnel and Configured with u-center

XML Parameters

When defining parameters you can use automatic unit conversion to conveniently set it in e.g. degrees.

Commands

The commands lists the abstract commands you need to control the aircraft. In a simple fixed-wing example, we have only three:

 <commands>
  <axis name="THROTTLE" failsafe_value="0"/>
  <axis name="ROLL"     failsafe_value="0"/>
  <axis name="PITCH"    failsafe_value="0"/>
 </commands>

For rotorcraft, it is usually:

 <commands>
  <axis name="PITCH"    failsafe_value="0"/>
  <axis name="ROLL"     failsafe_value="0"/>
  <axis name="YAW"      failsafe_value="0"/>
  <axis name="THRUST"   failsafe_value="0"/>
 </commands>

Each command is also associated with a failsafe value which will be used if no controller is active, for example during initialization of the autopilot board. The range of these values is [-9600:9600]. For "THROTTLE", the range is [0, 9600] and in the corresponding servo definition the neutral and min are usually the same for PWM based servos (see below). Note that these commands do not necessarily match the servo actuators. For example, the "ROLL" command is typically linked to two aileron actuators.

Servos

The above commands get translated to the servos here. In the example below we use two elevons and a motor. (Elevons are surfaces used for both pitch and roll as on a flying wing.) These servos are listed in the servos section:

 <servos>
  <servo name="THROTTLE"         no="0" min="1000" neutral="1000" max="2000"/>
  <servo name="ELEVON_LEFTSIDE"  no="1" min="2000" neutral="1500" max="1000"/>
  <servo name="ELEVON_RIGHTSIDE" no="2" min="1000" neutral="1500" max="2000"/>
 </servos>

Names are associated to the corresponding real physical connector to which a servo is connected on the autopilot board. For example no="2" means connector two on the board. Also the servo neutral value, total range and direction are defined. Min/max/neutral values are expressed in milliseconds. The direction of travel can be reversed by exchanging min with max (as in "ELEVON_LEFTSIDE", above). The standard travel for a hobby servo is 1000ms - 2000ms with a 1500ms neutral. Trim can be added by changing this neutral value. Absolute servo travel limits can be increased or reduced with the min/max values. The "THROTTLE" servo typically has the same value for the neutral and min.

The attribute driver for servos node tells which actuators' driver is associated the the listed servos. After the version v4.9_devel-164-gdb0d004, multiple servos sections can be defined and used together, if the correct actuators subsystems are loaded. Some boards are automatically loading a default driver, the one used when no driver attribute is specified.

Note the following important tips:

• Reverse the servo direction by exchanging min/max
• Trim should always be adjusted mechanically if possible to avoid asymmetrical travel
• Any reduction of the total travel range should be done mechanically to maintain precision
• Many servos will respond well to values slightly outside the normal 1000-2000ms range but experiment carefully as the servo may not operate reliably outside this range and may even suffer permanent damage.
• Board connector numbering starts with zero (0) not with one
• Servos are also known under the synonym actuators
• (after version v4.9_devel-164-gdb0d004) For I2C based motor speed control using the motor mixing:
  • min: command to stop the motor
  • neutral: motor idle command
  • max: max thrust command

The servos are then linked to the commands in the command_laws section:

 <command_laws>
  <let var="aileron"            value="@ROLL  * 0.3"/>
  <let var="elevator"           value="@PITCH * 0.7"/>  
  <set servo="THROTTLE"         value="@THROTTLE"/>
  <set servo="ELEVON_LEFTSIDE"  value="$elevator + $aileron"/>
  <set servo="ELEVON_RIGHTSIDE" value="$elevator - $aileron"/>
 </command_laws>

Sign conventions for flight dynamics

where the third line is the simplest: the throttle servo value equals throttle command value. The other lines define and control the pitch/roll mixing. Elevon values are computed with a combination of two commands, ROLL and PITCH. This mixer is defined with two intermediate variables aileron and elevator introduced with the let element. The @ symbol is used to reference a command value in the value attribute of the set and let elements. In the above example, the servos are limited to +/- 70% of their full travel for pitch and 30% for roll, only in combination can the servos reach 100% deflection. Note that these numbers should add up 100% or more, never less. For example, you may want 100% travel available for pitch - this means if a roll is commanded along with maximum pitch only one servo will respond to the roll command as the other has already reached its mechanical limit. If you find after tuning that these numbers add to less than 100% consider reducing the surface travel mechanically.

Note that the signs used in the description follow the standard convention.

After v4.9_devel-164-gdb0d004, the command_laws section is mandatory for both fixedwing and rotorcraft firmwares, only for fixedwing otherwise.

Bat

This section gives characteristics for monitoring the main power battery.

MILLIAMP_AT_FULL_THROTTLE represents the actual current (in mA) when full THROTTLE is applied. Note that when flying the current typically is significantly lower than in static tests at home on your workbench. MILLIAMP_AT_FULL_THROTTLE is used to compute the energy value of the BAT message when no Current sensor is mounted in the airframe. This value can also be used in flight plans. For example, if at full throttle your motor consumes 10 Amps, use a value of 10000. You can "tweak" this number after a few flights to match the capacity of your battery. If upon landing your bat.energy messages says that you used 2500 mAh while the energy recharged into the battery is only 2000 mAh, you could reduce the MILLIAMP_AT_FULL_THROTTLE value by 20% to match your in-flight current consumption. This tweaking is most precise if you fly full throttle only (respectively no throttle to glide down again).

The CURRENT_ESTIMATION_NONLINEARITY can be added to tweak the energy estimation for non full throttle cruise. As the current consumption is nonlinear, at 50% throttle it is likely to be substantially less than 50%. A superellipse is used to approximate this nonlinearity. The default setting is 1.2 and is used if the CURRENT_ESTIMATION_NONLINEARITY is not defined in your airframe file. A value 1 corresponds to linear behaviour, 1.5 corresponds to strong nonlinearity. The tweaking is done same as decribed above for MILLIAMP_AT_FULL_THROTTLE, but only partial throttle (cruise throttle) should be applied in flight.

If both MILLIAMP_AT_FULL_THROTTLE and CURRENT_ESTIMATION_NONLINEARITY are tweaked well, you get precise energy estimations with less than 5% error independant of your flight pattern without even requiring a current sensor.

The CATASTROPHIC_BAT_LEVEL (was previously LOW_BATTERY) value defines the voltage at which the autopilot will lock the throttle at 0% in autonomous mode (kill_throttle mode). This value is also used by the ground server to issue a CATASTROPHIC alarm message on the bus (this message will be displayed in the console of the GCS). CRITIC and LOW values will also used as threshold for CRITIC and WARNING alarms. They are optional and the respective defaults are 10.0 and 10.5V.

The MAX_BAT_LEVEL may be specified to improve the display of the battery gauge in the strip or in "papgets". Note that this definition is optional, with a default value of 12.5V.

File: conf/airframes/myplane.xml

<section name="BAT"> <define name="MILLIAMP_AT_FULL_THROTTLE" value="12000" unit="mA" /> <define name="CATASTROPHIC_BAT_LEVEL" value="6.0" unit="V"/> <define name="CRITIC_BAT_LEVEL" value="6.5" unit="V"/> <define name="LOW_BAT_LEVEL" value="7.0" unit="V"/> <define name="MAX_BAT_LEVEL" value="8.4" unit="V"/> </section>

The conversion of ADC measurements to Voltage is already defined for the different autopilot boards, if you need to override these defaults you can use the VoltageOfAdc(adc) define.

File: conf/airframes/myplane.xml

<section name="BAT"> ... <define name="VOLTAGE_ADC_A" value="0.0177531"/> <define name="VOLTAGE_ADC_B" value="0.173626"/> <define name="VoltageOfAdc(adc)" value ="(VOLTAGE_ADC_A * adc + VOLTAGE_ADC_B)"/> </section>

Modules

The modules allow to add new code in a flexible way with initialisation, periodic and event functions without modifying the main AP loop.

 <modules main_freq="60">
  <load name="demo_module.xml"/>
 </modules>

• The main_freq parameter (in Hz) allows to specify the frequency of the main loop. Default is 60 Hz