PaparazziUAV - User contributions [en]

Installation/Linux

2014-10-29T14:02:01Z

Garrosh: Improper invocation of tar command

<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Installation</categorytree>
__TOC__

'''This page only describes the installation of the prerequisite tools and dependencies on Debian/Ubuntu needed for Paparazzi.'''

'''See the general [[Installation]] page for how to [[Installation#Getting_the_Source_Code|download Paparazzi]] and [[Installation#Launching_the_Software|launching it]] after you followed the instructions here.'''

== Introduction ==

Paparazzi is very easily installed on any laptop or workstation running [http://www.ubuntu.com/ Ubuntu], [http://www.debian.org/ Debian] (or any of their derivatives).

The steps required to install the software needed to be able to let your UAS fly
<ul>
<li>[[Installation/Linux#Installation_of_dependencies|Install the basic Paparazzi dependencies]] and the [[Installation/Linux#ARM_embedded_toolchain|ARM cross compiling toolchain.]]
<li>[[Installation#Getting_the_Source_Code|Download the source code from the source repository.]]
<li>Allow access to your PC hardware connection by adding appropriate [[Udev]] rules.
<li>[[Installation#Launching_the_Software|Compile the binaries from the sources and launch the software.]]
</ul>

Users of other Linux flavors than a recent Ubuntu or Debian and anyone needing manual control of each individual package can [[Installation/Manual|install them independently]].

===For the impatient===

For Ubuntu add the [https://launchpad.net/~paparazzi-uav/+archive/ppa paparazzi-uav ppa] <tt>sudo add-apt-repository ppa:paparazzi-uav/ppa</tt> and install the <tt>paparazzi-dev</tt> package.

Since Paparazzi v5.0 the [https://launchpad.net/gcc-arm-embedded/ gcc-arm-embedded toolchain] is recommended.
Available as of Ubuntu 14.04, on older versions it can be [[Installation/Linux#ARM_embedded_toolchain|installed via tarball]].

Or just use the [[Installation#Quickstart_on_Ubuntu_12.04|Quickstart for Ubuntu 12.04 LTS]].

== Installation video Tutorials ==

{{#ev:youtubehd|SshFJrBuku8}} {{#ev:youtubehd|eW0PCSjrP78}}

== Installation of dependencies ==

=== Ubuntu ===

Add the installation sources for the Paparazzi software packages. Run from a terminal:
sudo add-apt-repository ppa:paparazzi-uav/ppa

Then update the systems package inventory and install the main Paparazzi software dependencies. This will take some time.
sudo apt-get update
sudo apt-get install paparazzi-dev

=== Debian ===

For Debian Squeeze (6.0) and Wheezy (7.0) packages are built using the [http://openbuildservice.org/ Open Build Service (OBS)] on [https://build.opensuse.org/project/show?project=home%3Aflixr%3Apaparazzi-uav OpenSUSE Build Service project home:flixr:paparazzi-uav]

[http://software.opensuse.org/download/package?project=home:flixr:paparazzi-uav&package=paparazzi-dev Install paparazzi-dev]

First add the key:
wget -q "http://download.opensuse.org/repositories/home:/flixr:/paparazzi-uav/Debian_7.0/Release.key" -O- | apt-key add -

Add the appropriate repo, depending on your Debian version to sources.list
echo "deb http://download.opensuse.org/repositories/home:/flixr:/paparazzi-uav/Debian_6.0/ ./" | tee -a /etc/apt/sources.list
echo "deb http://download.opensuse.org/repositories/home:/flixr:/paparazzi-uav/Debian_7.0/ ./" | tee -a /etc/apt/sources.list

Update the systems package inventory and install the main Paparazzi software dependencies.
sudo apt-get update
sudo apt-get install paparazzi-dev

== ARM embedded toolchain ==

For current Paparazzi versions (v5.0 and above) the [https://launchpad.net/gcc-arm-embedded/ gcc-arm-embedded toolchain] is recommended, which also supports the STM32F4 with FPU (hardware floating point).

The most common way is to download and unpack the tarball and add it to your PATH:

[http://pixhawk.org/dev/toolchain_installation_lin The Pixhawk Devs have mentioned the 4.8 as buggy.]

cd ~
wget https://launchpad.net/gcc-arm-embedded/4.7/4.7-2013-q2-update/+download/gcc-arm-none-eabi-4_7-2013q2-20130614-linux.tar.bz2
tar -vjxf gcc-arm-none-eabi-4_7-2013q2-20130614-linux.tar.bz2 -C /opt
rm -r gcc-arm-none-eabi-4_7-2013q2-20130614-linux.tar.bz2
exportline="PATH=$PATH:/opt/gcc-arm-none-eabi-4_7-2013q2/bin"
if grep -Fxq "$exportline" ~/.profile; then echo nothing to do ; else echo $exportline >> ~/.profile; fi
source ~/.profile

The file .profile will be sourced in every bash after logging out and in again. Until then,
source ~/.profile
can be used for every bash individually.

If you can not access your toolchain with PATH working, look a the [[Installation/Linux#Troubleshooting]].

==== ARM gcc-arm-embedded toolchain (from launchpad) - Debian Quick (Manual) Install Process ====

This approach is quick and low risk as it does not rely on any packages or make modifications to the system.

* Download latest gcc-arm-none-eabi-*-*-linux.tar.bz2 from [https://launchpad.net/gcc-arm-embedded/+download External Downloads] section of ARM gcc-arm-embedded project
* Create /opt/paparazzi folder if it does not exist
sudo mkdir /opt/paparazzi
* Decompress file to /opt/
sudo tar -xvf [name_of_downloaded_bz2_file] -C /opt
* Create symlink so Paparazzi Makefile can find the library
sudo ln -s /opt/[gcc-arm-xxxxxxx_name_of_folder] /opt/paparazzi/arm-multilib
* Attempt to build paparazzi autopilot firmware (example, Paparazzi Center build target ap)

=== gcc-arm-none-eabi as Debian/Ubuntu package ===

Note that there are actually two '''different''' toolchains available that unfortunately have the same package name!
* [https://launchpad.net/gcc-arm-embedded/ ARM gcc-arm-embedded toolchain]
** includes libstdc++ and newlib-nano
* [https://packages.debian.org/jessie/gcc-arm-none-eabi Debian gcc-arm-none-eabi toolchain]
** does not include libstdc++
** does not include newlib-nano

Both toolchains ''should'' work for most use-cases (if you don't need C++ or nano specs), although the [https://launchpad.net/gcc-arm-embedded/ ARM gcc-arm-embedded toolchain] is better tested.

==== gcc-arm-embedded toolchain ====

On ''most'' Ubuntu versions (currently lucid, precise, raring, saucy and trusty) the [https://launchpad.net/gcc-arm-embedded/ gcc-arm-embedded toolchain] can be installed as a debian package from the [https://launchpad.net/~terry.guo/+archive/gcc-arm-embedded ppa]:
sudo add-apt-repository ppa:terry.guo/gcc-arm-embedded
sudo apt-get update
sudo apt-get install gcc-arm-none-eabi

!!! If you are using Ubuntu 14.04 and later, please be careful because there are packages with same name but produced by Debian and inherited by Ubuntu. Simply follow the above 3 steps, you may end up with gcc-arm-none-eabi from Ubuntu. So to install gcc-arm-none-eabi from ARM, steps are:

sudo apt-get remove binutils-arm-none-eabi gcc-arm-none-eabi
sudo add-apt-repository ppa:terry.guo/gcc-arm-embedded
sudo apt-get update
sudo apt-get install gcc-arm-none-eabi=4.8.4.2014q3-0trusty11
Meanwhile we are working with Debian to consolidate and unify this toolchain.

==== gcc-arm-none-eabi Debian toolchain ====

Debian testing ('''jessie''') and Ubuntu 14.04 ('''trusty''') have the gcc-arm-none-eabi package in the official repositories ('''universe'''), and can be installed with:
sudo apt-get update
sudo apt-get install gcc-arm-none-eabi

=== Old toolchain for Paparazzi v4.x and earlier ===

'''For Paparazzi v4.x''' and earlier you need to install the <tt>paparazzi-arm-multilib</tt> package. It has support for both ARM7 (i.e. Tiny,TWOG,YAPA autopilot boards) as well as STM32F1 (i.e. LISA boards). 
'''This toolchain does not properly support STM32F4 based autopilots!!'''

You can install it explicitly with:
sudo apt-get install paparazzi-arm-multilib

== Optional Packages ==

The packages lpc21isp and openocd are normally '''automatically installed''' as they are recommended packages of paparazzi-dev, '''if not''' you can manually install them via:

sudo apt-get install lpc21isp openocd

<tt>lpc21isp</tt> is needed to serially flash the LPC2148 based autopilots (e.g. bootloader for tiny, twog, umarim), <tt>openocd</tt> is for flashing via JTAG (e.g. for Lisa boards) and debugging.

== Installing and running Paparazzi ==

Please see [[Installation#Getting_the_Source_Code|Getting the Source Code on the general Installation page]] for details on downloading the Paparazzi source code, compiling and running it.

== Udev rules ==

Add the appropriate [[Udev]] rule (available in fhe file ''50-paparazzi.rules'') to the USB handler. Simply copy as root <tt>conf/system/udev/rules/50-paparazzi.rules</tt> to <tt>/etc/udev/rules.d/</tt>, e.g in a terminal:

cd <your paparazzi directory>
sudo cp conf/system/udev/rules/50-paparazzi.rules /etc/udev/rules.d/

See the [[Udev]] page for more details.

== Troubleshooting ==

=== No access rights for USB devices ===

Some Linux distributions, don't allow standard (non admin) users to directly access the USB bus by default. On recent Ubuntu/Debian versions the first/main user is already a member of the ''plugdev'' group which should be sufficient for most cases. 
If you have problems, make yourself a member of the ''plugdev'' and ''dialout'' groups:

sudo adduser <your login> plugdev
sudo adduser <your login> dialout

Logout and login again.

=== arm-none-eabi-gcc: Command not found ===
Appeared on Debian Wheezy 7 (gcc-arm-none-eabi-4_8-2013q4 installed via tarball) 
If this error occurs, maybe the [https://packages.debian.org/de/wheezy/ia32-libs ia32-libs] are missing.

Enable multiarch and install ia32-libs:
dpkg --add-architecture i386
apt-get update
apt-get install ia32-libs

===arm-none-eabi-gdb: error with libncurses.so.5===
Appeared on Xubuntu 14.04 LTS (gcc-arm-none-eabi-4_8-2013q4 installed via tarball) 
Terminal output: arm-none-eabi-gdb: error while loading shared libraries: libncurses.so.5: cannot open shared object file: No such file or directory

If this error occours, maybe [http://packages.ubuntu.com/search?keywords=lib32ncurses5 lib32ncurses5] is missing. 
Found on [https://answers.launchpad.net/gcc-arm-embedded/+question/226680 launchpad q&a]

=== FTDI serial adapter not working on old Ubuntu version ===

On older Linux distributions (not needed for lucid and later), the Braille TTY driver interferes with FTDI USB Serial adapters. If somehow your FTDI serial adapter does not work, remove the package via:

sudo apt-get remove brltty

=== Code not starting on autopilot after changing gcc ===

If you changed the toolchain (e.g. installed a new one for having FPU-Support for the F4), you need to run

make clean && make

in sw/ext in order to rebuild the libs. Otherwise the embedded code can behave strange (most likely not start)

[[Category:Software]] [[Category:User_Documentation]] [[Category:Installation]]

Airframe Configuration

2014-02-13T17:29:59Z

Garrosh: Removed TeX non breaking space since they don't seem to be possible to do

<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Airframe_Configuration</categorytree>
== 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 <tt>conf/airframes/<yourairframe>.xml</tt> and always begins with a <!DOCTYPE airframe SYSTEM "airframe.dtd"> line and should look like this
{{Box Code|conf/airframes/<yourairframe>.xml|<source lang="xml">
<!DOCTYPE airframe SYSTEM "airframe.dtd">
<airframe name="yourairframe">

</airframe>
</source>}}

Also see the wiki pages for [[Fixedwing_Configuration|fixedwing specific configuration]] and [[Rotorcraft_Configuration|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_Plans|Flight Plan]]
* [[Settings]]
* [[Radio_Control|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.xml|<tt>conf/conf.xml</tt>]]. To create a new Aircraft, click new in the menu A/C in the [[Paparazzi_Center|Paparazzi Center]] and select your new airframe file, etc. (or specify it by hand in [[Conf.xml|<tt>conf/conf.xml</tt>]]).

== Firmware and Hardware definitions ==
First you should specify which firmware you want to use, that is if you have a <tt>[[Fixedwing_Configuration|fixedwing]]</tt> aircraft or a <tt>[[Rotorcraft_Configuration|rotorcraft]]</tt>:
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
</firmware>
</source>
}}
=== Select your Board ===
To specify autopilot hardware you are using and it's low-level settings you have to add a ''target''-tag.
Each ''target'' has two attributes, which are ''name'' and a corresponding ''board'' attribute.
The ''name'' attribute is either "ap" (autopilot) or "sim" (simulation).

{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
<target name="sim" board="pc"/> 
<target name="ap" board="lisa_m_1.0"/> 
...
</firmware>
</source>
}}

==== Simulation targets ====
target name="sim","jsbsim","nps" 
board="pc" 

More Information at [[Simulation]].

==== Board targets ====
target name="ap" 
board=
"apogee_0.99",
"apogee_1.0",
"ardrone2_raw",
"ardrone2_sdk",
"booz_1.0",
"classix",
"hb_1.1",
"krooz_sd",
"lisa_l_1.0",
"lisa_l_1.1",
"lisa_m_1.0",
"lisa_m_2.0",
"logom_2.6",
"navgo_1.0",
"sdlog_1.0",
"stm32f4_discovery",
"tiny_0.99",
"tiny_1.1",
"tiny_2.1",
"tiny_2.11",
"twog_1.0",
"umarim_1.0",
"umarim_lite_2.0",
"yapa_2.0",

==== Direct Makefile ====
Optionally you can also add a raw [http://en.wikipedia.org/wiki/Makefile 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'':
{{Box Code|conf/airframes/myplane.xml|
<source lang="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>
</source>
}}
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''.

== Subsystems ==

Each autopilot features certain [[Subsystems|subsystems]] which need to be configured properly.
The most important ones are described below.

=== IMU ===
Add the [[Subsystem/imu|imu subsystem]] with the type you are using.
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
<subsystem name="imu" type="aspirin_v1.5"/>
</firmware>
</source>
}}

See the [[Subsystem/imu|imu subsystem]] page for more details.
Also see the [[ImuCalibration|IMU calibration]] page.

=== AHRS ===
The [[Subsystem/ahrs|AHRS subsystem]] specifies which attitude estimation filter you are using, e.g. for the complementary filter:
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
<subsystem name="ahrs" type="int_cmpl_euler"/>
</firmware>
</source>
}}
All AHRS algorithms depend on an imu subsystem, except for the ahrs_infrared which depends on the infrared module.
See the [[Subsystem/ahrs|AHRS subsystem page]] for more details.

If the magnetometer should be used the [[Subsystem/ahrs#Local_Magnetic_Field|local magnetic field section]] must be filled in.

=== Radio Control ===

Supported types are:
* ''ppm''
* ''spektrum''
* ''datalink''

Just specify the appropriate [[Subsystem/radio_control|radio control subsystem]] in your firmware section, e.g.:
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
<subsystem name="radio_control" type="ppm"/>
</firmware>
</source>
}}

=== 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|telemetry file]], e.g. <tt>conf/telemetry/default.xml</tt>. Those wishing to experiment with "alternative" modems can reduce the number and period of each telemetry message to fit within most any bandwidth constraint.

The [[Subsystem/telemetry|telemetry subsystem]] 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/telemetry|telemetry subsystem]] in your firmware section. You can currently choose between the types ''transparent'', ''transparent_usb'' and ''xbee_api''.

'''The default baudrate is 57600 baud, see the [[Subsystem/telemetry|telemetry subsystem]] page for more details and configuration options.'''
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
<subsystem name="telemetry" type="transparent"/>
</firmware>
</source>
}}

=== 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 [[Subsystem/gps|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.
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
<subsystem name="gps" type="ublox"/>
</firmware>
</source>
}}

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 through the [[tunnel|UART Tunnel]] and [[GPS#GPS_configuration_using_U-Center|Configured with u-center]]

== XML Parameters ==
'''When defining parameters you can use [[Units|automatic unit conversion]] to conveniently set it in e.g. degrees.'''

=== Commands ===

The <tt>commands</tt> lists the abstract commands you need to control the aircraft. In a simple fixed-wing example, we have only three:
<source lang="xml">
<commands>
<axis name="THROTTLE" failsafe_value="0"/>
<axis name="ROLL" failsafe_value="0"/>
<axis name="PITCH" failsafe_value="0"/>
</commands>
</source>
For rotorcraft, it is usually:
<source lang="xml">
<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>
</source>

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 <tt>"THROTTLE"</tt>, the range is [0, 9600] and in the corresponding <tt>servo</tt> definition the <tt>neutral</tt> and <tt>min</tt> are usually the same for PWM based servos (see below). Note that these commands do not necessarily match the servo actuators. For example, the <tt>"ROLL"</tt> command is typically linked to two aileron actuators.

=== Servos ===

The above commands get translated to the <tt>servos</tt> here. In the example below we use two elevons and a motor. ([http://en.wikipedia.org/wiki/Elevon ''Elevons''] are surfaces used for both pitch and roll as on a flying wing.) These servos are listed in the <tt>servos</tt> section:
<source lang="xml">
<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>
</source>
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 <tt>"ELEVON_LEFTSIDE"</tt>, above). The ''standard'' travel for a hobby servo is 1000<math>\mu\text{s}</math> - 2000<math>\mu\text{s}</math> with a 1500<math>\mu\text{s}</math> 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 <tt>"THROTTLE"</tt> servo typically has the same value for the <tt>neutral</tt> and <tt>min</tt>.

The attribute <tt>driver</tt> for <tt>servos</tt> 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 [[Subsystem/actuators| actuators subsystems]] are loaded. Some boards are automatically loading a default driver, the one used when no <tt>driver</tt> 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 [[Rotorcraft_Configuration#Motor_Mixing|motor mixing]]:
** min: command to stop the motor
** neutral: motor idle command
** max: max thrust command

The <tt>servos</tt> are then linked to the commands in the <tt>command_laws</tt> section:
<source lang="xml">
<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>
</source>

[[Image:airframe_sign_conventions.jpg|thumb|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 <tt>let</tt> element. The '''@''' symbol is used to reference a command value in the <tt>value</tt> attribute of the <tt>set</tt> and <tt>let</tt> 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 <tt>command_laws</tt> section is mandatory for both fixedwing and rotorcraft firmwares, only for fixedwing otherwise.

=== Battery ===
This section gives characteristics for monitoring the main power battery.

<tt>MILLIAMP_AT_FULL_THROTTLE</tt> 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. <tt>MILLIAMP_AT_FULL_THROTTLE</tt> is used to compute the <tt>energy</tt> value of the <tt>BAT</tt> message when no [[Current_sensor|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 <tt>MILLIAMP_AT_FULL_THROTTLE</tt> 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 <tt>CURRENT_ESTIMATION_NONLINEARITY</tt> 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 <tt>CURRENT_ESTIMATION_NONLINEARITY</tt> 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 <tt>MILLIAMP_AT_FULL_THROTTLE</tt>, but only partial throttle (cruise throttle) should be applied in flight.

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

The <tt>CATASTROPHIC_BAT_LEVEL</tt> (was previously <tt>LOW_BATTERY</tt>) 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). <tt>CRITIC</tt> and <tt>LOW</tt> 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 <tt>MAX_BAT_LEVEL</tt> 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.
{{Box Code|conf/airframes/myplane.xml|
<source lang="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>
</source>
}}

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 <tt>VoltageOfAdc(adc)</tt> define and also specify offsets or anything else you might need, e.g.:
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<section name="BAT">
...
<define name="VOLTAGE_ADC_SCALE" value="0.0177531"/>
<define name="VOLTAGE_OFFSET" value="0.5" unit="V"/>
<define name="VoltageOfAdc(adc)" value ="(VOLTAGE_ADC_SCALE * adc + VOLTAGE_OFFSET)"/>
</section>
</source>
}}

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

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

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

=== GCS ===
Use this optional section to help customize parts of the GCS for a specific airframe:
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<section name="GCS">
...
<define name="ALT_SHIFT_PLUS_PLUS" value="30"/>
<define name="ALT_SHIFT_PLUS" value="5"/>
<define name="ALT_SHIFT_MINUS" value="-5"/>
<define name="SPEECH_NAME" value="Quad"/>
<define name="AC_ICON" value="flyingwing"/>
</section>
</source>
}}
[[Image:ac_icon_multi_uav.png|thumb|Various A/C icons demonstrated on a multi UAV simulation session]]

* <tt>ALT_SHIFT_PLUS_PLUS</tt> sets the number of metres the target altitude will change when the double up arrow button is pressed on the [[GCS#Strips|strip]]
* <tt>ALT_SHIFT_PLUS</tt> sets the number of metres the target altitude will change when the up arrow button is pressed on the [[GCS#Strips|strip]]
* <tt>ALT_SHIFT_MINUS</tt> sets the number of metres the target altitude will change when the down arrow button is pressed on the [[GCS#Strips|strip]]
* <tt>SPEECH_NAME</tt> a string ([a-zA-Z0-9_]) that will be used in place of the aircraft name specified in <tt>conf.xml</tt> for the [[Speech|speech]] and [[GCS#Alarms|alarms]] functionality. Set this to "_" to prevent the speech function from saying the aircraft name. Useful if your aircraft name takes a long time to say (i.e. "UAV1-A_with_spektrum" can be shortened to "Plane").
* <tt>AC_ICON</tt> can be used to define the vehicle icon (or overwrite the default icon) that shows up on the 2D-map of the GCS. Available values are: <tt>flyingwing</tt> , <tt>fixedwing</tt> , <tt>rotorcraft</tt> , <tt>home</tt>.

[[Category:User_Documentation]] [[Category:Airframe_Configuration]]

Airframe Configuration

2014-02-13T17:25:00Z

Garrosh: Changed miliseconds to microseconds on servo travel

<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Airframe_Configuration</categorytree>
== 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 <tt>conf/airframes/<yourairframe>.xml</tt> and always begins with a <!DOCTYPE airframe SYSTEM "airframe.dtd"> line and should look like this
{{Box Code|conf/airframes/<yourairframe>.xml|<source lang="xml">
<!DOCTYPE airframe SYSTEM "airframe.dtd">
<airframe name="yourairframe">

</airframe>
</source>}}

Also see the wiki pages for [[Fixedwing_Configuration|fixedwing specific configuration]] and [[Rotorcraft_Configuration|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_Plans|Flight Plan]]
* [[Settings]]
* [[Radio_Control|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.xml|<tt>conf/conf.xml</tt>]]. To create a new Aircraft, click new in the menu A/C in the [[Paparazzi_Center|Paparazzi Center]] and select your new airframe file, etc. (or specify it by hand in [[Conf.xml|<tt>conf/conf.xml</tt>]]).

== Firmware and Hardware definitions ==
First you should specify which firmware you want to use, that is if you have a <tt>[[Fixedwing_Configuration|fixedwing]]</tt> aircraft or a <tt>[[Rotorcraft_Configuration|rotorcraft]]</tt>:
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
</firmware>
</source>
}}
=== Select your Board ===
To specify autopilot hardware you are using and it's low-level settings you have to add a ''target''-tag.
Each ''target'' has two attributes, which are ''name'' and a corresponding ''board'' attribute.
The ''name'' attribute is either "ap" (autopilot) or "sim" (simulation).

{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
<target name="sim" board="pc"/> 
<target name="ap" board="lisa_m_1.0"/> 
...
</firmware>
</source>
}}

==== Simulation targets ====
target name="sim","jsbsim","nps" 
board="pc" 

More Information at [[Simulation]].

==== Board targets ====
target name="ap" 
board=
"apogee_0.99",
"apogee_1.0",
"ardrone2_raw",
"ardrone2_sdk",
"booz_1.0",
"classix",
"hb_1.1",
"krooz_sd",
"lisa_l_1.0",
"lisa_l_1.1",
"lisa_m_1.0",
"lisa_m_2.0",
"logom_2.6",
"navgo_1.0",
"sdlog_1.0",
"stm32f4_discovery",
"tiny_0.99",
"tiny_1.1",
"tiny_2.1",
"tiny_2.11",
"twog_1.0",
"umarim_1.0",
"umarim_lite_2.0",
"yapa_2.0",

==== Direct Makefile ====
Optionally you can also add a raw [http://en.wikipedia.org/wiki/Makefile 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'':
{{Box Code|conf/airframes/myplane.xml|
<source lang="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>
</source>
}}
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''.

== Subsystems ==

Each autopilot features certain [[Subsystems|subsystems]] which need to be configured properly.
The most important ones are described below.

=== IMU ===
Add the [[Subsystem/imu|imu subsystem]] with the type you are using.
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
<subsystem name="imu" type="aspirin_v1.5"/>
</firmware>
</source>
}}

See the [[Subsystem/imu|imu subsystem]] page for more details.
Also see the [[ImuCalibration|IMU calibration]] page.

=== AHRS ===
The [[Subsystem/ahrs|AHRS subsystem]] specifies which attitude estimation filter you are using, e.g. for the complementary filter:
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
<subsystem name="ahrs" type="int_cmpl_euler"/>
</firmware>
</source>
}}
All AHRS algorithms depend on an imu subsystem, except for the ahrs_infrared which depends on the infrared module.
See the [[Subsystem/ahrs|AHRS subsystem page]] for more details.

If the magnetometer should be used the [[Subsystem/ahrs#Local_Magnetic_Field|local magnetic field section]] must be filled in.

=== Radio Control ===

Supported types are:
* ''ppm''
* ''spektrum''
* ''datalink''

Just specify the appropriate [[Subsystem/radio_control|radio control subsystem]] in your firmware section, e.g.:
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
<subsystem name="radio_control" type="ppm"/>
</firmware>
</source>
}}

=== 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|telemetry file]], e.g. <tt>conf/telemetry/default.xml</tt>. Those wishing to experiment with "alternative" modems can reduce the number and period of each telemetry message to fit within most any bandwidth constraint.

The [[Subsystem/telemetry|telemetry subsystem]] 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/telemetry|telemetry subsystem]] in your firmware section. You can currently choose between the types ''transparent'', ''transparent_usb'' and ''xbee_api''.

'''The default baudrate is 57600 baud, see the [[Subsystem/telemetry|telemetry subsystem]] page for more details and configuration options.'''
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
<subsystem name="telemetry" type="transparent"/>
</firmware>
</source>
}}

=== 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 [[Subsystem/gps|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.
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
<subsystem name="gps" type="ublox"/>
</firmware>
</source>
}}

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 through the [[tunnel|UART Tunnel]] and [[GPS#GPS_configuration_using_U-Center|Configured with u-center]]

== XML Parameters ==
'''When defining parameters you can use [[Units|automatic unit conversion]] to conveniently set it in e.g. degrees.'''

=== Commands ===

The <tt>commands</tt> lists the abstract commands you need to control the aircraft. In a simple fixed-wing example, we have only three:
<source lang="xml">
<commands>
<axis name="THROTTLE" failsafe_value="0"/>
<axis name="ROLL" failsafe_value="0"/>
<axis name="PITCH" failsafe_value="0"/>
</commands>
</source>
For rotorcraft, it is usually:
<source lang="xml">
<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>
</source>

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 <tt>"THROTTLE"</tt>, the range is [0, 9600] and in the corresponding <tt>servo</tt> definition the <tt>neutral</tt> and <tt>min</tt> are usually the same for PWM based servos (see below). Note that these commands do not necessarily match the servo actuators. For example, the <tt>"ROLL"</tt> command is typically linked to two aileron actuators.

=== Servos ===

The above commands get translated to the <tt>servos</tt> here. In the example below we use two elevons and a motor. ([http://en.wikipedia.org/wiki/Elevon ''Elevons''] are surfaces used for both pitch and roll as on a flying wing.) These servos are listed in the <tt>servos</tt> section:
<source lang="xml">
<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>
</source>
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 <tt>"ELEVON_LEFTSIDE"</tt>, above). The ''standard'' travel for a hobby servo is 1000~<math>\mu\text{s}</math> - 2000~<math>\mu\text{s}</math> with a 1500~<math>\mu\text{s}</math> 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 <tt>"THROTTLE"</tt> servo typically has the same value for the <tt>neutral</tt> and <tt>min</tt>.

The attribute <tt>driver</tt> for <tt>servos</tt> 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 [[Subsystem/actuators| actuators subsystems]] are loaded. Some boards are automatically loading a default driver, the one used when no <tt>driver</tt> 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 [[Rotorcraft_Configuration#Motor_Mixing|motor mixing]]:
** min: command to stop the motor
** neutral: motor idle command
** max: max thrust command

The <tt>servos</tt> are then linked to the commands in the <tt>command_laws</tt> section:
<source lang="xml">
<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>
</source>

[[Image:airframe_sign_conventions.jpg|thumb|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 <tt>let</tt> element. The '''@''' symbol is used to reference a command value in the <tt>value</tt> attribute of the <tt>set</tt> and <tt>let</tt> 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 <tt>command_laws</tt> section is mandatory for both fixedwing and rotorcraft firmwares, only for fixedwing otherwise.

=== Battery ===
This section gives characteristics for monitoring the main power battery.

<tt>MILLIAMP_AT_FULL_THROTTLE</tt> 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. <tt>MILLIAMP_AT_FULL_THROTTLE</tt> is used to compute the <tt>energy</tt> value of the <tt>BAT</tt> message when no [[Current_sensor|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 <tt>MILLIAMP_AT_FULL_THROTTLE</tt> 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 <tt>CURRENT_ESTIMATION_NONLINEARITY</tt> 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 <tt>CURRENT_ESTIMATION_NONLINEARITY</tt> 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 <tt>MILLIAMP_AT_FULL_THROTTLE</tt>, but only partial throttle (cruise throttle) should be applied in flight.

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

The <tt>CATASTROPHIC_BAT_LEVEL</tt> (was previously <tt>LOW_BATTERY</tt>) 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). <tt>CRITIC</tt> and <tt>LOW</tt> 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 <tt>MAX_BAT_LEVEL</tt> 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.
{{Box Code|conf/airframes/myplane.xml|
<source lang="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>
</source>
}}

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 <tt>VoltageOfAdc(adc)</tt> define and also specify offsets or anything else you might need, e.g.:
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<section name="BAT">
...
<define name="VOLTAGE_ADC_SCALE" value="0.0177531"/>
<define name="VOLTAGE_OFFSET" value="0.5" unit="V"/>
<define name="VoltageOfAdc(adc)" value ="(VOLTAGE_ADC_SCALE * adc + VOLTAGE_OFFSET)"/>
</section>
</source>
}}

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

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

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

=== GCS ===
Use this optional section to help customize parts of the GCS for a specific airframe:
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<section name="GCS">
...
<define name="ALT_SHIFT_PLUS_PLUS" value="30"/>
<define name="ALT_SHIFT_PLUS" value="5"/>
<define name="ALT_SHIFT_MINUS" value="-5"/>
<define name="SPEECH_NAME" value="Quad"/>
<define name="AC_ICON" value="flyingwing"/>
</section>
</source>
}}
[[Image:ac_icon_multi_uav.png|thumb|Various A/C icons demonstrated on a multi UAV simulation session]]

* <tt>ALT_SHIFT_PLUS_PLUS</tt> sets the number of metres the target altitude will change when the double up arrow button is pressed on the [[GCS#Strips|strip]]
* <tt>ALT_SHIFT_PLUS</tt> sets the number of metres the target altitude will change when the up arrow button is pressed on the [[GCS#Strips|strip]]
* <tt>ALT_SHIFT_MINUS</tt> sets the number of metres the target altitude will change when the down arrow button is pressed on the [[GCS#Strips|strip]]
* <tt>SPEECH_NAME</tt> a string ([a-zA-Z0-9_]) that will be used in place of the aircraft name specified in <tt>conf.xml</tt> for the [[Speech|speech]] and [[GCS#Alarms|alarms]] functionality. Set this to "_" to prevent the speech function from saying the aircraft name. Useful if your aircraft name takes a long time to say (i.e. "UAV1-A_with_spektrum" can be shortened to "Plane").
* <tt>AC_ICON</tt> can be used to define the vehicle icon (or overwrite the default icon) that shows up on the 2D-map of the GCS. Available values are: <tt>flyingwing</tt> , <tt>fixedwing</tt> , <tt>rotorcraft</tt> , <tt>home</tt>.

[[Category:User_Documentation]] [[Category:Airframe_Configuration]]

Talk:Airframe Configuration

2014-02-13T17:21:18Z

Garrosh: Mistake about servo duty cycle

13 feb 2014 - According to wikipedia, [http://en.wikipedia.org/wiki/Servo_control] the duty cycle for most servos is in fact 2000 <math>\mu \text{s}</math>, and not 2000 ms