PaparazziUAV - User contributions [en]

New Gaia

2018-11-22T20:41:36Z

Flixr: internal link label for test

(Webpage currently incomplete)

New Gaia is an update of the current gaia agent.

This system has been developed by an ENAC team of 4 students from the IENAC10S promo. It enables one to generate a complex environment with several meteorological phenomena.

= Presentation =

== Functionalities ==

Fully connected to the Paparazzi simulator through the IVY middleware, New Gaia allows the user to add elements of a realistic meteorological environment to the current simulation thanks to an adapted GUI. The initial version of the program proposes three meteorological phenomena : thermal columns, turbulences and a vertical profile. Also are all the parameters of the simulation taken into account in order to offer the most complete customization capability : several UAVs, geographic coordinates, the background map, etc.

The models of the phenomena have been chosen based on two characteristics that are the way they can represent reality and a low resources need. For more details, please check the documentation.

Finally some misc have been implemented to reuse the functionalities of the current gaia agent like the simulation speed control.

== The project ==

It has been a two-month long project proposed by the ENAC micro-drones lab to the 2nd year of the IENAC S formation, and designed within the ENAC infrastructures in Toulouse. To know more about us, please check [[New_Gaia#About_us|About us]].

= How to get New Gaia ? =

The installation described here is for debian-like systems (typically Ubuntu). Thank you for sharing your experience on others systems!

== Requirements ==
In order to compile the files with the included makefile, you need JDK 1.6.0_24. And in order to run the file, you need the JRE 1.6.0_24 (included in the JDK). They can be found at [http://www.oracle.com/technetwork/java/javase/downloads/jdk6-downloads-1637591.html].

Please note that New_Gaia uses JDOM version 2.0.1 to generate XML files and the ivy package designed for java. They are included as jar files in the application, so you don't have to download them.

== The source code ==
Get the [https://github.com/paparazzi/new_gaia source code] from our Github repository.

== Compilation ==
To compile the files, we wrote a makefile for you. Simply enter "make" to do so.

= How to use New Gaia ? =

== Finding the maps files ==
New_Gaia can display a background that helps (a lot) to set the thermal columns where one wants. To do so, New_Gaia uses the same files that Paparazzi. That's why the background must be filled thanks to Paparazzi before it can be used by New_Gaia. (These .jpg files are located in the /var/maps directory of Paparazzi)

== Finding the SRTM files ==
The SRTM files used to determine the influence of the terrain on the meteorological phenomena can be found at [http://dds.cr.usgs.gov/srtm/version2_1/SRTM3/]

== Executing the application ==
Once the application is compiled, you can run it with the command "make run". As a student project, this application doesn't appear in the "Tools" menu of Paparazzi, that's why it's necessary to run it manually in a terminal.

New_Gaia handles three main meteorological phenomena : thermal columns, the wind and turbulences. Each phenomenon can be customized thanks to the interface :

[[File:Phenomenes.png|900px]]

=== Thermal Columns ===

Let's begin with the thermal columns. To create a thermal column, click on the appropriate button and click somewhere on the map : a column with its initial parameters is created.
As you can see on the properties panel on the right, a lateral view of the column is displayed. Two areas are shown : a gray one, in which up-wind blows and a white one in which down-wind blows. Please note that the "radius" of a column refers to the radius of its up-wind area.

[[File:Thermal_column.png|900px]]

The "Maximum Vertical Speed" property refers to the speed of the wind at the center of the thermal column, this speed decreases then and becomes negative (down-wind area).

You can set the radius of the thermal column thanks to the handler on the left of the column. The height of the column is then calculated : the larger the column is, the higher it is.

=== Vertical Profile ===

The second meteorological phenomenon that can be set to customize the state of the weather is the vertical profile. It represents the speed and direction of the wind functions of height.

[[File:Vertical profile1.png|900px]]

The wind speed consists in a polylinear function linking the highest point (or handler), the lowest point and the points you may create. Each point represents a height, a speed and a direction used to determine the wind functions of the heigth.
To create a new point, simply left click in the vertical profile area. To erase a point, right click on it. Please note that the highest and lowest points can't be erased. Except of the highest point, a point's height can't be modified. If the height of a point doesn't satisfy you, erase it and create a new one. Nevertheless, a point's speed can be modified. To do so, move the point with a drag'n'drop.

[[File:Vertical profile2.png|900px]]

Finally, the layer of the atmosphere between 0 and 150m is influenced by the terrain and thus can't be modified.

The following image is an example of a wind turning along the altitude from East to West :

[[File:Vertical profile3.png|900px]]

=== Turbulences ===

The last meteorological phenomenon represents turbulences. This one is quite simple : it consists in random components added to the wind on the three axis. The level of turbulences is depicted by 4 values :

* 0 = no turbulences
* 1 = low turbulences
* 2 = medium turbulences
* 3 = severe turbulences

[[File:Turbulences.png|900px]]

= About us =

The team is composed by four students from the IENAC10S promo :

* BENREJEB Ons, developer,
* OTT Alexandra, developer,
* CARRIERE Sébastien, developer,
* EBRO Hugo, project lead, developer.

DevGuide/Releasing

2017-11-12T13:59:14Z

Flixr:

= Create new release =

First of course the [https://github.com/paparazzi/paparazzi/blob/master/CHANGELOG.md CHANGELOG] should be updated.

Stable release series have an even MINOR number, ongoing development has an uneven MINOR number.

A stable release is generally done with the following steps:

<ol>
<li>creating an annotated tag with <tt>vMAJOR.MINOR.PATCH_stable</tt> in git. If it is the first release of a MAJOR.MINOR series, also create the vMAJOR.MINOR branch.</li>
<li>Add the release on https://github.com/paparazzi/paparazzi/releases</li>
<li>As the tarballs that github automatically creates don't include the submodules, run
<source lang="bash">
./make_release_tarball.sh
mv paparazzi.tar paparazzi_vMAJOR.MINOR.PATCH_stable.tar
gzip paparazzi_vMAJOR.MINOR.PATCH_stable.tar
</source>
and upload this tarball to the github release
</li>
<li>Update docs if a new stable branch: adjust [https://github.com/paparazzi/paparazzi.github.com/blob/master/index.html index.html] and add the branch to the [https://gist.github.com/flixr/4989376 pprz-update-dox.sh] script on odin.paparazziuav.org</li>
</ol>

[[Category:Developer_Documentation]]

DevGuide/Releasing

2017-11-12T13:53:58Z

Flixr: how to create a release

= Create new release =

First of course the [https://github.com/paparazzi/paparazzi/blob/master/CHANGELOG.md CHANGELOG] should be updated.

Stable release series have an even MINOR number, ongoing development has an uneven MINOR number.

A stable release is generally done with the following steps:

<ol>
<li>creating an annotated tag with <tt>vMAJOR.MINOR.PATCH_stable</tt> in git. If it is the first release of a MAJOR.MINOR series, also create the vMAJOR.MINOR branch.</li>
<li>Add the release on https://github.com/paparazzi/paparazzi/releases</li>
<li>As the tarballs that github automatically creates don't include the submodules, run
<source>
./make_release_tarball.sh
mv paparazzi.tar paparazzi_vMAJOR.MINOR.PATCH_stable.tar
gzip paparazzi_vMAJOR.MINOR.PATCH_stable.tar
</source>
and upload this tarball to the github release
</li>
<li>Update docs if a new stable branch: adjust [https://github.com/paparazzi/paparazzi.github.com/blob/master/index.html index.html] and add the branch to the [https://gist.github.com/flixr/4989376 pprz-update-dox.sh] script on odin.paparazziuav.org</li>
</ol>

[[Category:Developer_Documentation]]

Developer Guide

2017-11-12T13:30:00Z

Flixr:

==Introduction==

By the time you land on this page, you probably want to enhance the Paparazzi project, that is really good for your karma and really appreciated by the Paparazzi community. We welcome contributions and improvements to the documentation.
[[Image:FixIt.jpg|right|FixIt]]

See also [[Doxygen]] for documentation close to the code.

==[[Contributing|Contributing]]==
You would like to contribute, but are not sure how, then [[Contributing|this is the page to visit]]

==[[DevGuide/CodeEditors|Code Editing]]==
How to setup your IDE for use with the source code

==[[DevGuide/LearningToProgram|Learning to Program]]==
Improve your Paparazzi code in OCAML,C,C++ and Python

==[[DevGuide/AircraftBuildProcess|Aircraft build process and code generation]]==
Description of the (rather complicated) build system and code generation regarding the airborne firmwares

==[[DevGuide/DesignOverview|Design Overview]]==
Attempt at a longer walk through the airborne code architecture

==[[FirmwareArchitecture|Firmware Architecture]]==
Attempt at brief overview of the firmware architecture with modules and subsystems

==[[DevGuide/Communications|Communications]]==
How telemetry and datalink is done

==[[DevGuide/CommunicationsNew|Communications (Proposed New system)]]==
How the telemetry and datalink works

==[[DevGuide/Server_GCS_com|Server-GCS communications]]==
How the Server and the Ground Control Station interact with each other

==[[DevGuide/Values|Values]]==
A short walk through the system and how values are handled

==[[DevGuide/Settings|Settings]]==
Settings is the generic mechanism that allows to set and get the value of any variable of the embedded code.

==[[DevGuide/Mathlib|Paparazzi Math Library]]==
The custom Paparazzi math library written in C and how to use it in external programs

==[[Reference/bootloader]]==
All of the questions and answers about the bootloader, but were afraid to ask

===[[Lpc21iap|LPC USB firmware]]===
All of the answers to the Paparazzi USB bootloader of question you never dared to ask

====[[Lpc21BootloaderUpload|Upload Bootloader for LPC21xx]]====
How to [[[[Lpc21BootloaderUpload|upload the Bootloader]] to a LPC2148 processor based Autopilot board like the TWOG

===[[Luftboot|Upload the luftboot bootloader]]===
How to upload the Bootloader to a STM32 processor based Autopilot board like the [[Elle0]] or [[Lisa/M]]

===[[DFU|Upload with DFU (with native or custom dfu bootloader)]]===
Using the native (embedded in ROM) or custom (e.g. [[Luftboot]] or [[KroozSD#Bootloader|KroozSD]]==) bootloader to upload Paparazzi code

===[[STLink|Upload with STLink via SWD (without Bootloader)]]===
General ST-LinkV2 page.

==[[DevGuide/GDB_OpenOCD_Debug|GDB OpenOCD Debug]]==
Using GDB or OpenOCD to directly flash and debug Hardware

==[[DevGuide/USB-Serial|USB-Serial]]==
Using a USB connection instead of UART for use with telemetry

==[[ControlTheory]]==
All [[ControlTheory|information you are looking for about the harsh reality of Control Theory]] needed to let your aircraft fly

==[[Demystified/Altitude and Height|Altitude and Height]]==
Altitude and Height demystified

==[[Abi|AirBorne Interface ABI]]==
Presentation of the airborne communication system

==[[DevGuide/StateInterface]]==
A stateinterface is a stateinterface is a stateinterface, [[DevGuide/StateInterface|poems aside read more about what the stateinterface entails here]]

==[[RT_Paparazzi]]==
[[RT_Paparazzi|Real Time Paparazzi]] how-to and guidelines

==[[Builds|Continuous Integration builds]]==
Info on the [[Builds|Continuous Integration builds]] (CI) server

==[[Coding Standards]]==
JPL (Jet Propulsion Laboratory) released their own coding standards (can be downloaded for free here: [http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf JPL C Coding Standards and Guidelines]). They include MISRA-C rules and directives, but add their own rules on top of that. They also specify different levels of compliance (LOC) because not always it is necessary to comply with all of the rules. Anyway, they are making things that go to space, so we can definitely learn something about good coding practices from them.

==[[DevGuide/Releasing]]==
Info for maintainers on how to create a new release.

[[Category:Developer_Documentation]]

Installation/Linux

2017-08-24T18:46:59Z

Flixr: added debian stretch

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

'''<span style="color:red">This page only describes the installation of the prerequisite tools and dependencies on Debian/Ubuntu needed for Paparazzi.</span>'''

'''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 ===
'''Binary packages for Ubuntu are available for the ''i386'', ''amd64'' and ''armhf'' architectures.'''

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 ===
'''Binary packages for Debian are available for the ''i386'' and ''amd64'' architectures. ''armhf'' packages seem to be currently not supported by the OpenSUSE build service.'''

For Debian Wheezy (7.0), Jessie (8.0) and Stretch (9.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_9.0/Release.key" -O- | sudo 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_9.0/ ./" | tee -a /etc/apt/sources.list
echo "deb http://download.opensuse.org/repositories/home:/flixr:/paparazzi-uav/Debian_8.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).

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

'''This is the recommended method'''

Note that there are actually two '''different''' toolchains available!
* [https://launchpad.net/gcc-arm-embedded/ ARM gcc-arm-embedded toolchain] with Debian package name ''gcc-arm-embedded''
** 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 ====

'''This is the recommended toolchain'''

On ''most'' Ubuntu versions the [https://launchpad.net/gcc-arm-embedded/ gcc-arm-embedded toolchain] can be installed as a debian package from the [https://launchpad.net/~team-gcc-arm-embedded/+archive/ubuntu/ppa ppa]:
sudo add-apt-repository ppa:team-gcc-arm-embedded/ppa
sudo apt-get update
sudo apt-get install gcc-arm-embedded

<div class="toccolours mw-collapsible mw-collapsed" style="width:800px">
Previously there was a PPA by terry.guo that contained this toolchain under the package name ''gcc-arm-none-eabi''
<div class="mw-collapsible-content">
See https://launchpad.net/gcc-arm-embedded/+announcement/13824 for details on how to switch the newer
PPA and package.
</div></div>

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

Current Debian ('''jessie''') and Ubuntu (14.04 '''trusty''' and later) releases 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 gdb-arm-none-eabi

=== ARM gcc-arm-embedded tarball ===
Another way is to download and unpack the tarball and add it to your PATH:

* Download gcc-arm-none-eabi-*-*-linux.tar.bz2 from [https://launchpad.net/gcc-arm-embedded/+download External Downloads] section of ARM gcc-arm-embedded project
* Unpack it to a directory of your choice
* Add the bin folder in to your PATH

e.g.:
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
sudo 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]].

=== 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).<br>
'''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 <b>lpc21isp</b> and <b>openocd</b> 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/
sudo udevadm control --reload-rules

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.<br>
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)<br/>
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-linux-gnueabi-gcc cross-compiler not found ===

=== Ubuntu ===
apt-get install gcc-arm-linux-gnueabi

=== Debian ===
Starting with jessie, there were [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771496#41 some changes] to the way cross-compilers are set up. To make it work you will have to add armel architecture and pick up some crossbuild tools.

First edit your /etc/apt/sources.list and add the following line, to enable the emdebian repo:
deb http://emdebian.org/tools/debian/ jessie main

Run the following command in your terminal to add the keys for it
curl http://emdebian.org/tools/debian/emdebian-toolchain-archive.key | sudo apt-key add -

Then you could add armel architecture and fetch the missing cross-compiler packages
dpkg --add-architecture armel
apt-get update
apt-get install crossbuild-essential-armel

You could find out more about cross-toolchains in jessie on debian [https://wiki.debian.org/CrossToolchains wiki page].

Note that some of your repos might not mirror embedded architectures, which would give you an error when you try to update the sources. In that case you will have to specify which architecture you do want from them by editing the corresponding entry in your sources.list file, in a way described [https://wiki.debian.org/Multiarch/HOWTO here]. Like in this example with the crunchbang repo you could specify it by adding [arch=amd64,i386] to the line, so you only enable amd64 and i386 architectures:
deb [arch=amd64,i386] http://packages.crunchbang.org/waldorf waldorf main

===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)<br/>
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 occurs, maybe [http://packages.ubuntu.com/search?keywords=lib32ncurses5 lib32ncurses5] is missing. <br/>
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]]

Installation/FromScratch

2017-05-13T19:14:45Z

Flixr: boa package is not needed

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

'''Users of recent Debian/Ubuntu distributions are advised to use the binary packages as described in [[Installation/Linux]].'''

<span style="color:#FF0000">'''WARNING! Only use if you are proficient in working with Linux!'''</span>

== Intro ==

Users of other Linux flavors or anyone needing manual control of each individual package can install them independently. <br/>
The list of dependencies of the Debian package is located in the [https://github.com/paparazzi/paparazzi-portability-support/blob/master/debian/paparazzi-dev/debian/control <tt>debian/control</tt>] file and may help users of other distributions.

Some corresponding source tarballs can be downloaded from [https://launchpad.net/~paparazzi-uav/+archive/ppa/+packages paparazzi-uav ppa] on launchpad. (maybe building the packages from source is more reliable in view of dependencies)

For distributions using RPM packaging, the [http://packages.debian.org/unstable/source/alien alien] tool can be used to convert a .deb package into a .rpm package.

As with all Wiki pages, also this page is a work in progress. Try to be a big help to the Paparazzi project and improve this page whenever you can. If you have a distribution different from Ubuntu which doesn't satisfy any other dependency and have instructions about compiling it, packaging it, feel free to add any reference on how to do that on this wikipage.

== Goal ==

The goal of this page is to clarify about which version of each piece of software has to be compiled, where to find that software, patches needed to make it compile on Linux, maybe even FreeBSD or OSX.

== Fedora 19 ==

To build paparazzi-uav on Fedora 19, you must install the next packages from the official repository:
* ocaml
* ocaml-findlib
* ocaml-xml-light
* ocaml-ocamlnet
* ocaml-lablgtk-devel
* libxml2-devel
* SDL-devel
* libusb-devel

Paparazzi-uav needs to include some ocaml headers when it compiles the simulator, then please be sure that they are included. If not, edit sw/simulator/Makefile and add:

CAML_CFLAGS = -I/usr/lib64/ocaml

The following packages must be built from source code (they are not included in the official repository):
* ivy-c
* ivy-ocaml

Paparazzi-uav was successfully compiled using ivy-c 3.14 (downloaded from SVN repository, revision #3602) and ivy-ocaml 1.2. Please note that the ivy-c version is an unstable version!

Additionally, you need install the next RPMs to build ivy-c:
* pcre-devel
* libXt-devel
* tcl-devel
* glib2-devel

Don't forget to set the environment variable PKG_CONFIG before building ivy-ocaml, e.g:

$ export PKG_CONFIG=/usr/local/lib/pkgconfig

== Fedora 24 ==
NOTE: Built upon Fedora 19 instruction, unnecessary instructions may occour.

1. Install dependencies:
$ sudo dnf install ocaml ocaml-findlib ocaml-xml-light ocaml-ocamlnet ocaml-lablgtk-devel ocaml-camlp4-devel libxml2-devel SDL-devel libusb-devel pcre-devel libXt-devel tcl-devel tk-devel glib2-devel gsl-devel

2. Edit the PKG_CONFIG_PATH variable in your ~/.bashrc file to accomondate /usr/local/lib/pkgconfig/ (default for ivy libs)

3. Edit all the ivy specific .pc files in /usr/local/lib/pkgconfig, changing line 3 from "libdir=${exec_prefix}/lib" to "libdir=${exec_prefix}/lib64"

4. Install ivy-python via pip and compile and istall ivy-c and ivy-ocaml from source as shown [[Installation/FromScratch#IVY]]

Note: dependencies for compiling ivy-c and ivy-ocaml are already covered above (except toolchain!).

5. Compile and install [[JSBSim|JSBsim from source]]

Hacks: Link libivy and libJSBsim after compiling
$ sudo ln -s /usr/local/lib64/libivy.so /usr/local/lib64/libivy.so.3 /usr/lib
$ sudo ln -s /opt/jsbsim/lib/libJSBSim.so.0 /usr/lib
$ sudo ldconfig

== Arch Linux ==

This is a dirty hacked together (not really according to "the Arch Way") install, but works on a fresh installed Archbang GNU/Linux.

'''NOTE: following issues '''
# Only written and tested for Archbang and Manjaro, not tested on vanilla Arch Linux yet.
# It seems that the error "unbound module GnoCanvas" can be resolved by installing lablgtk2 via yaourt first and then conf-gnomecanvas over opam.
# No symlink from liblglibivy.so.3 and liblglibivy.so.3 to libglibivy.so.3.15, so can't find these files.
# If pkg-config can't find some .pc files, a pkg-config path might not be set and exported properly. Use "pkg-config --variable pc_path pkg-config" to check if the path containing the ''ivy-c.pc'', ''ivy-glib.pc'' and ''ivy-tcl.pc'' files is found.
# "ocamlfind: Package `netclient' not found" -> seems that the opam packages need to be installed in a specific order... (try ocamlnet first, then lablgtk.2.16)

'''Requirements:'''
# Up to date system
#* pacman -Syyu
# Install Yaourt
#*https://astrofloyd.wordpress.com/2015/01/17/installing-yaourt-on-arch-linux/

'''Install Paparazzi:'''
# Packages base-devel, yajl and general dependencies
#: <pre># pacman -S base-devel yajl subversion git libusb pcre ocaml camlp4 tcl tk python python-pip sdl glade</pre>
# Check if the PKG_CONFIG_PATH points to ''/usr/local/lib/pkgconfig'', otherwise set and export it
#: <pre>$ echo 'export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/' >> ~/.bashrc</pre>
# Build and install Ivy-C from Source
#: <pre>$ svn checkout https://svn.tls.cena.fr/svn/ivy/ivy-c/trunk /home/$USER/temp/ivy-c 
$ cd /home/$USER/temp/ivy-c/src 
$ make 
$ sudo make install</pre>
# '''Dirty''' All the ivy libs are installed in ''/usr/local/lib64'' and not ''/usr/local/lib'' as the .pc files point to currently. <br/>
#:Change in the third line (libdir) in the ivy-c.pc, ivy-glib.pc and ivy-tcl.pc file from ''lib'' to ''lib64'' and the fourth line (includedir) from ''include'' to ''include/Ivy''
# '''Dirty'''For libgivy, libivy and libtclivy (.so and .so.3 ending) is a link directing to the lib with .so.3.15 availaible, but not for libglibivy. <br/>
#Create these links for libglibivy
#: <pre>$ sudo ln -s /usr/local/lib64/libglibivy.so.3.15 /usr/local/lib64/libglibivy.so 
$ sudo ln -s /usr/local/lib64/libglibivy.so.3.15 /usr/local/lib64/libglibivy.so.3</pre>
# Install opam (OCaml packet manager) via yaourt
#: <pre>$ yaourt -S opam</pre>
# Initialize opam
#: <pre>$ opam init 
$ f 
$ ~/.bashrc 
$ echo 'eval `opam config env`' >> ~/.bashrc</pre>
# Install and pin lablgtk.2.16.0 (2.18.0 will not work)
#: <pre>$ opam install -v lablgtk.2.16.0 
$ opam pin add lablgtk 2.16.0</pre>
# Install OCaml packets via opam
#: <pre>$ opam install ocamlfind ocamlnet xml-light pcre ivy</pre>
#: If this fails at Ivy related parts check the notes on top of this guide.
# Install ivy-python via pip
#: <pre>$ sudo pip install ivy-python</pre>
# Install the Toolchain for Paparazzi (e.g. [https://aur.archlinux.org/packages/gcc-arm-none-eabi-bin/ gcc-arm-none-eabi-bin] from the AUR)
#: <pre>$ sudo pacman -S gcc-arm-none-eabi-bin</pre>

Optional:

# Install flashing utilities if needed
$ yaourt stlink-git dfu-util
# Install [[JSBSim]] for [[NPS]]

[[Installation#Getting_the_Source_Code|Download]] and [[Installation#Launching_the_Software|build Paparazzi]]

== Installing the Cross compiler toolchain ==

There are currently two different toolchains available that can be used on Linux based systems with Paparazzi. For more information see [[Installation/Linux#ARM_embedded_toolchain]]

== Installing OCaml packages using OPAM ==

One possibility to install and manage OCaml packages is [http://opam.ocamlpro.com/ OPAM (OCaml Package Manager)]:<br/>
'''Please first check the official [http://opam.ocaml.org/doc/Install.html OPAM install guide] for the simplest method.'''<br/>
To install it from the latest git tree run:
<nowiki>git clone https://github.com/OCamlPro/opam.git</nowiki>
cd opam
./configure && make
sudo make install

opam init
eval `opam config env`

Update your shell environment as per opam init's instructions. E.g. add to your ''~/.profile'':
eval `opam config env`

Build and install OCaml libs:
opam install ocamlfind xml-light pcre ocamlnet
opam install -v lablgtk

== IVY ==

IVY is a simple protocol and a set of open-source libraries and programs that allows applications to broadcast information through text messages, with a subscription mechanism based on regular expressions. The project can be found at: http://www.eei.cena.fr/products/ivy/

In the paparazzi project, Ivy is used to send telemetry data to where ever you want.

NOTE: Do not confuse this IVY with the Apache Ivy project.

=== Ivy-python ===

The ivy-python package makes it possible to use the IVY libraries from within the Python programming language. The ivy-python package is architecture independent, so it can be downloaded from the Ubuntu or Debian paparazzi repository.

The easiest way to instally it on non Debian based systems is using [https://pip.pypa.io/ pip] to install the [https://pypi.python.org/pypi/ivy-python ivy-python package] from [https://pypi.python.org/pypi PyPi - the Python Package Index].
pip install ivy-python

Or install from the source repository via

git clone https://gitlab.com/ivybus/ivy-python.git
cd ivy-python
./setup.py install

=== Ivy-c ===

To be able to use ivy-c, the libraries need to be installed.

Required packages (Debian based):
* tk-dev
* libpcre3-dev
* libxt-dev
* pkg-config
* libglib2.0-dev

Download source, compile and install libraries:

# mkdir -p /opt/ivy-c
# cd /opt/ivy-c
# svn co https://svn.tls.cena.fr/svn/ivy/ivy-c/trunk
# cd /opt/ivy-c/trunk/src
# make
# make install

It is possible you get errors of the test module when compiling, just ignore the messages, it is not important for the Paparazzi project. Contact the IVY team to help them also to resolve also the testing makefile issue.

==== troubleshooting ====

Error message:
gcc -c -O2 -Wall -Wshadow -fPIC -I/usr/include/tcl8.4 -DTCL_CHANNEL_INTEGRATION ivytcl.c
ivytcl.c:28:17: fatal error: tcl.h: No such file or directory

The Makefile cannot read the tcl-dev version you have installed and assumes that version 8.4 is installed, but can't find the appropriate folder.<br/>
Edit the line 57 of the Makefile from TCLVERS=8.4 according to your installed version, or just delete the 8.4, both work.

Can't find 64bit libs:
Your ivy libs were probably installed to /usr/local/lib64 and you have to make symbolic links so that they will be found:
$ sudo ln -s /usr/local/lib64/libivy.so /usr/local/lib64/libivy.so.3 /usr/lib
or
sudo ln -s /usr/local/lib64/libivy.so /usr/local/lib64/libivy.so.3 /usr/local/lib

If you get an error relating to ivytestready.c, make the following changes:
mkdir /opt/ivy-c/trunk/tools/Ivy
cd /opt/ivy-c/trunk/tools/Ivy
cp ../../src/ivy.h .
cp ../../src/ivyloop.h .
cp ../../src/ivysocket.h .
cp ../../src/timer.h .
cd ~/develop/ivy-c/trunk/src
make

This copies files from the src directory to the Ivy folder in tools which did not appear after running svn above.

=== Ivy-OCaml ===

ivy-ocaml provides OCaml bindings for ivy-c and is needed for most of the ground segment agents that are written in OCaml like [[Server]] and [[GCS]].

Download source, compile and install libraries:

# mkdir -p /opt/ivy-ocaml
# cd /opt/ivy-ocaml
# svn co https://svn.tls.cena.fr/svn/ivy/ivy-ocaml/trunk
# cd /opt/ivy-ocaml/trunk
# make
# make install

==== ivy-ocaml via OPAM ====
Or use OPAM: While the source repository and debian package is named ''ivy-ocaml'', in OPAM it is only named ''ivy'' (since it is obviously for OCaml).

$ opam update
$ opam install ivy

== LPC21ISP ==

lpc21isp is only needed to serially flash the LPC2148 based autopilots (e.g. [[Lpc21BootloaderUpload bootloader]] for tiny, twog, umarim). LPC21ISP is an in-circuit programming (ISP) tool for the microcontroller used on the Paparazzi autopilot boards. The lpc21isp project is hosted on sourceforge and one can find the source packages and information at http://sourceforge.net/projects/lpc21isp/

Get the SVN version via

$ mkdir -p /opt/lpc21isp
$ cd /opt/lpc21isp
$ svn co https://lpc21isp.svn.sourceforge.net/svnroot/lpc21isp lpc21

To compile go into the source directory and then do

$ cd lpc21
$ make -f Makefile clean all

To install

$ exportline="PATH=$PATH:/opt/lpc21isp"
$ if grep -Fxq "$exportline" ~/.profile; then echo nothing to do ; else echo $exportline >> ~/.profile; fi
$ source ~/.profile

== Paparazzi-dev Debian/Ubuntu packages ==

For Ubuntu users, you can install the following packages from standard repository. You can just copy the line(s) and paste into your terminal. But do not copy the $ sign, this symbol is just added on this page to show that it is to be pasted at a normal terminal prompt.

=== Whole lot in one ===

sudo apt-get install ocaml libcamlimages-ocaml liblablgtk2-ocaml-dev liblablgtk2-gl-ocaml-dev \
liblablgtk2-gnome-ocaml-dev libxml-light-ocaml-dev libocamlnet-ocaml-dev libpcre-ocaml \
libpcre-ocaml-dev libgnomecanvas2-0 libgnomecanvas2-dev libglade2-0 libglade2-dev make build-essential \
git gnuplot m4 libtool libftdi-dev libmpfr-dev tcl8.5-dev xutils-dev

=== Ocaml and libraries ===

Ocaml, short for Objective Caml is the most popular variant of the Caml language. The Paparazzi Ground Control Station (GCS) and some of it's tools are crafted in this language.

* ocaml, ocaml-camlimages-devel, ocaml-lablgtk2-devel, ocaml-xml-light-devel, ocamlnet-ocaml-devel

$ sudo apt-get install ocaml libcamlimages-ocaml liblablgtk2-ocaml-dev liblablgtk2-gl-ocaml-dev \
liblablgtk2-gnome-ocaml-dev libxml-light-ocaml-dev libocamlnet-ocaml-dev

=== Gnome canvas Library ===

The GnomeCanvas is an engine for structured graphics that offers a rich imaging model, high performance rendering, and a powerful, high level API. This widget can be used for flexible display of graphics and for creating interactive user interface elements.

$ sudo apt-get install libgnomecanvas2-0 libgnomecanvas2-dev

=== USB Library ===

The libusb project aims to create a library for use by user level applications to access USB devices regardless of OS. [http://www.libusb.org]

$ sudo apt-get install libusb-dev

=== Ocaml PCRE ===

This OCaml-library interfaces the PCRE (Perl-compatibility regular expressions) C library. it can be used for matching regular expressions which are written in Perl style.

$ sudo apt-get install libpcre-ocaml libpcre-ocaml-dev

=== Glade Library ===

Libglade is a library that performs a similar job to the C source output routines in the GLADE user interface builder. Whereas GLADE's output routines create C source code that must be compiled, libglade builds the interface from an XML file (GLADE's save format) at runtime. This can allow modifying the user interface without recompiling.

$ sudo apt-get install libglade2-0 libglade2-dev

=== Tcl/Tk ===

$ sudo apt-get install tcl-dev

Also the some utils are required to compile and install Ivy.

$ sudo apt-get install xutils-dev

=== Make ===

GNU Make is an utility which controls the generation of executables and other target files of a program from the program's source files.

$ sudo apt-get install make

=== Build essential ===

$ sudo apt-get install build-essential

=== Libtool ===

GNU libtool is a generic library support script. Libtool hides the complexity of using shared libraries behind a consistent, portable interface. Creating the files for Paparazzi software building becomes less cumbersome by using this tool.

$ sudo apt-get install libtool

=== libpcre3-dev ===

Required for compiling Ivy-C.

$ apt-get install libpcre3-dev

=== Git Client ===

Git is a version control system. Version control systems allow many individuals to collaborate on the Paparazzi source code. This is needed to retrieve the latest sourcecode from various packages and Paparazzi sourcecode itself.

$ sudo apt-get install git

=== Subversion ===

Version control system, required for cloning the ivy packages.

$ apt-get install subversion

=== GNU Plot ===

A command-line driven interactive plotting program. Unknow if it is used

$ sudo apt-get install gnuplot

=== Meld ===

Meld is a graphical front end to the diff program. It provides a side-by-side view of the differences between two files. It is used by the Paparazzi Center when configuration changes are not yet saved and the option comes along where one either can keep or view changes made in aircraft- and other configuration files.

$ sudo apt-get install meld

=== FTDI library ===

libftdi is a library that talks to FTDI's 232 type chips, including the popular bitbang mode, using libusb. A library to be able to use with a debugging Autopilot hardware boards.

$ sudo apt-get install libftdi-dev

=== MPFR library ===

The MPFR library is a C library for multiple-precision floating-point computations with correct rounding. MPFR is based on the GMP multiple-precision library. The main goal of MPFR is to provide a library for multiple-precision floating-point computation which is both efficient and has a well-defined semantics.

$ sudo apt-get install libmpfr-dev

=== ImageMagick ===

ImageMagick is a software suite to create, edit, and compose bitmap images. It can read, convert and write images in a variety of formats. Use ImageMagick to translate, flip, mirror, rotate, scale, shear and transform images, adjust image colors, apply various special effects, or draw text, lines, polygons, ellipses and Bézier curves. Being able to modify image based map pictures is a feature that may come in handy one time.

$ sudo apt-get install imagemagick

=== Optional on an older OS ===

If you have an older OS distribution it never hurts to install the following...

$ sudo apt-get install libx11-6 libx11-dev texinfo libncurses5 libncursesw5 libncursesw5-dev zlibc

== Paparazzi Main sourcecode ==

See the main [[Installation#Getting_the_Source_Code]] page

TIP:
If you get the File "pprz.mli", line 149, characters 78-89: Error: Unbound type constructor Ivy.binding
...this happens when IVY libraries are not yet installed. How to do this, read the part on installing IVY on this page

== Useful links ==

https://launchpad.net/gcc-arm-embedded/

https://github.com/paparazzi/paparazzi-portability-support

http://wiki.ubuntuusers.de/GNU_arm-toolchain

http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/ARM-Options.html#ARM-Options

http://mcuprogramming.com/forum/arm/gnu-arm-toolchain-installer/

http://www.ethernut.de/en/documents/cross-toolchain-osx.html

http://www.hermann-uwe.de/blog/building-an-arm-cross-toolchain-with-binutils-gcc-newlib-and-gdb-from-source

[[Category:Software]] [[Category:Developer_Documentation]] [[Category:Installation]]

New Gaia

2017-01-05T20:35:28Z

Flixr: /* The project */

(Webpage currently incomplete)

New Gaia is an update of the current gaia agent.

This system has been developed by an ENAC team of 4 students from the IENAC10S promo. It enables one to generate a complex environment with several meteorological phenomena.

= Presentation =

== Functionalities ==

Fully connected to the Paparazzi simulator through the IVY middleware, New Gaia allows the user to add elements of a realistic meteorological environment to the current simulation thanks to an adapted GUI. The initial version of the program proposes three meteorological phenomena : thermal columns, turbulences and a vertical profile. Also are all the parameters of the simulation taken into account in order to offer the most complete customization capability : several UAVs, geographic coordinates, the background map, etc.

The models of the phenomena have been chosen based on two characteritics that are the way they can represent reality and a low resources need. For more details, please check the documentation.

Finally some misc have been implemented to reuse the functionalities of the current gaia agent like the simulation speed control.

== The project ==

It has been a two-month long project proposed by the ENAC micro-drones lab to the 2nd year of the IENAC S formation, and designed within the ENAC infrastructures in Toulouse. To know more about us, please check [[New_Gaia#About_us]].

= How to get New Gaia ? =

The installation described here is for debian-like systems (typically Ubuntu). Thank you for sharing your experience on others systems!

== Requirements ==
In order to compile the files with the included makefile, you need JDK 1.6.0_24. And in order to run the file, you need the JRE 1.6.0_24 (included in the JDK). They can be found at [http://www.oracle.com/technetwork/java/javase/downloads/jdk6-downloads-1637591.html].

Please note that New_Gaia uses JDOM version 2.0.1 to generate XML files and the ivy package designed for java. They are included as jar files in the application, so you don't have to download them.

== The source code ==
Get the [https://github.com/paparazzi/new_gaia source code] from our Github repository.

== Compilation ==
To compile the files, we wrote a makefile for you. Simply enter "make" to do so.

= How to use New Gaia ? =

== Finding the maps files ==
New_Gaia can display a background that helps (a lot) to set the thermal columns where one wants. To do so, New_Gaia uses the same files that Paparazzi. That's why the background must be filled thanks to Paparazzi before it can be used by New_Gaia. (These .jpg files are located in the /var/maps directory of Paparazzi)

== Finding the SRTM files ==
The SRTM files used to determine the influence of the terrain on the meteorological phenomena can be found at [http://dds.cr.usgs.gov/srtm/version2_1/SRTM3/]

== Executing the application ==
Once the application is compilated, you can run it with the command "make run". As a student project, this application doesn't appear in the "Tools" menu of Paparazzi, that's why it's necessary to run it manually in a terminal.

New_Gaia handles three main meteorological phenomena : thermal columns, the wind and turbulences. Each phenomenon can be customized thanks to the interface :

[[File:Phenomenes.png|900px]]

=== Thermal Columns ===

Let's begin with the thermal columns. To create a thermal column, click on the appropriate button and click somewhere on the map : a column with its initial parameters is created.
As you can see on the properties panel on the right, a lateral view of the column is displayed. Two areas are shown : a gray one, in which up-wind blows and a white one in which down-wind blows. Please note that the "radius" of a column refers to the radius of its up-wind area.

[[File:Thermal_column.png|900px]]

The "Maximum Vertical Speed" property refers to the speed of the wind at the center of the thermal column, this speed decreases then and becomes negative (down-wind area).

You can set the radius of the thermal column thanks to the handler on the left of the column. The height of the column is then calculated : the larger the column is, the heigher it is.

=== Verticale Profile ===

The second meteorological phenomenon that can be set to customize the state ot the weather is the vertical profile. It represents the speed and direction of the wind functions of height.

[[File:Vertical profile1.png|900px]]

The wind speed consists in a polylinear function linking the heighest point (or handler), the lowest point and the points you may create. Each point represents a height, a speed and a direction used to determine the wind functions of the heigth.
To create a new point, simply left click in the verticale profile area. To erase a point, right click on it. Please note that the highest and lowest points can't be erased. Except of the heighest point, a point's height can't be modified. If the height of a point doesn't satisfy you, erase it and create a new one. Nevertheless, a point's speed can be modified. To do so, move the point with a drag'n'drop.

[[File:Vertical profile2.png|900px]]

Finally, the layer of the atmosphere between 0 and 150m is influenced by the terrain and thus can't be modified.

The following image is an example of a wind turning along the altitude from East to West :

[[File:Vertical profile3.png|900px]]

=== Turbulences ===

The last meteorological phenomenon represents turbulences. This one is quite simple : it consists in random components added to the wind on the three axis. The level of turbulences is depicted by 4 values :

* 0 = no turbulences
* 1 = low turbulences
* 2 = medium turbulences
* 3 = severe turbulences

[[File:Turbulences.png|900px]]

= About us =

The team is composed by four students from the IENAC10S promo :

* BENREJEB Ons, developer,
* OTT Alexandra, developer,
* CARRIERE Sébastien, developer,
* EBRO Hugo, project lead, developer.

New Gaia

2017-01-05T20:35:13Z

Flixr:

(Webpage currently incomplete)

New Gaia is an update of the current gaia agent.

This system has been developed by an ENAC team of 4 students from the IENAC10S promo. It enables one to generate a complex environment with several meteorological phenomena.

= Presentation =

== Functionalities ==

Fully connected to the Paparazzi simulator through the IVY middleware, New Gaia allows the user to add elements of a realistic meteorological environment to the current simulation thanks to an adapted GUI. The initial version of the program proposes three meteorological phenomena : thermal columns, turbulences and a vertical profile. Also are all the parameters of the simulation taken into account in order to offer the most complete customization capability : several UAVs, geographic coordinates, the background map, etc.

The models of the phenomena have been chosen based on two characteritics that are the way they can represent reality and a low resources need. For more details, please check the documentation.

Finally some misc have been implemented to reuse the functionalities of the current gaia agent like the simulation speed control.

== The project ==

It has been a two-month long project proposed by the ENAC micro-drones lab to the 2nd year of the IENAC S formation, and designed within the ENAC infrastructures in Toulouse. To know more about us, please check [[[New_Gaia#About_us]].

= How to get New Gaia ? =

The installation described here is for debian-like systems (typically Ubuntu). Thank you for sharing your experience on others systems!

== Requirements ==
In order to compile the files with the included makefile, you need JDK 1.6.0_24. And in order to run the file, you need the JRE 1.6.0_24 (included in the JDK). They can be found at [http://www.oracle.com/technetwork/java/javase/downloads/jdk6-downloads-1637591.html].

Please note that New_Gaia uses JDOM version 2.0.1 to generate XML files and the ivy package designed for java. They are included as jar files in the application, so you don't have to download them.

== The source code ==
Get the [https://github.com/paparazzi/new_gaia source code] from our Github repository.

== Compilation ==
To compile the files, we wrote a makefile for you. Simply enter "make" to do so.

= How to use New Gaia ? =

== Finding the maps files ==
New_Gaia can display a background that helps (a lot) to set the thermal columns where one wants. To do so, New_Gaia uses the same files that Paparazzi. That's why the background must be filled thanks to Paparazzi before it can be used by New_Gaia. (These .jpg files are located in the /var/maps directory of Paparazzi)

== Finding the SRTM files ==
The SRTM files used to determine the influence of the terrain on the meteorological phenomena can be found at [http://dds.cr.usgs.gov/srtm/version2_1/SRTM3/]

== Executing the application ==
Once the application is compilated, you can run it with the command "make run". As a student project, this application doesn't appear in the "Tools" menu of Paparazzi, that's why it's necessary to run it manually in a terminal.

New_Gaia handles three main meteorological phenomena : thermal columns, the wind and turbulences. Each phenomenon can be customized thanks to the interface :

[[File:Phenomenes.png|900px]]

=== Thermal Columns ===

Let's begin with the thermal columns. To create a thermal column, click on the appropriate button and click somewhere on the map : a column with its initial parameters is created.
As you can see on the properties panel on the right, a lateral view of the column is displayed. Two areas are shown : a gray one, in which up-wind blows and a white one in which down-wind blows. Please note that the "radius" of a column refers to the radius of its up-wind area.

[[File:Thermal_column.png|900px]]

The "Maximum Vertical Speed" property refers to the speed of the wind at the center of the thermal column, this speed decreases then and becomes negative (down-wind area).

You can set the radius of the thermal column thanks to the handler on the left of the column. The height of the column is then calculated : the larger the column is, the heigher it is.

=== Verticale Profile ===

The second meteorological phenomenon that can be set to customize the state ot the weather is the vertical profile. It represents the speed and direction of the wind functions of height.

[[File:Vertical profile1.png|900px]]

The wind speed consists in a polylinear function linking the heighest point (or handler), the lowest point and the points you may create. Each point represents a height, a speed and a direction used to determine the wind functions of the heigth.
To create a new point, simply left click in the verticale profile area. To erase a point, right click on it. Please note that the highest and lowest points can't be erased. Except of the heighest point, a point's height can't be modified. If the height of a point doesn't satisfy you, erase it and create a new one. Nevertheless, a point's speed can be modified. To do so, move the point with a drag'n'drop.

[[File:Vertical profile2.png|900px]]

Finally, the layer of the atmosphere between 0 and 150m is influenced by the terrain and thus can't be modified.

The following image is an example of a wind turning along the altitude from East to West :

[[File:Vertical profile3.png|900px]]

=== Turbulences ===

The last meteorological phenomenon represents turbulences. This one is quite simple : it consists in random components added to the wind on the three axis. The level of turbulences is depicted by 4 values :

* 0 = no turbulences
* 1 = low turbulences
* 2 = medium turbulences
* 3 = severe turbulences

[[File:Turbulences.png|900px]]

= About us =

The team is composed by four students from the IENAC10S promo :

* BENREJEB Ons, developer,
* OTT Alexandra, developer,
* CARRIERE Sébastien, developer,
* EBRO Hugo, project lead, developer.

Bebop

2016-12-27T08:58:28Z

Flixr: /* Video */

<div style="float: right; width: 15%"><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Autopilots</categorytree></div>
<div style="float: right; width: 45%; overflow: hidden">[[Image:Parrot-bebop-drone-new-03.jpeg|right|500px|Parrot Bebop]]</div>
<div style="float: right; width: 40%">__TOC__</div>

= Introduction =

By default the [http://www.parrot.com/usa/products/bebop-drone/ Bebop] from [http://www.parrot.com/ Parrot] is a Wifi controlled flying quadrotor, designed to be controlled with an Android or iOS device.

'''No more restrictions''' as from now; with a few simple clicks you can '''run Paparazzi on the Bebop''' and have full autonomous flight and much more!

= Getting started =

What you need:
# A bebop drone (1 or 2) with the newest firmware
# A joystick (example: http://www.hobbyking.com/hobbyking/store/__20951__Hobbyking_6CH_RC_Flight_Simulator_System_Mode_2_.html
# A laptop with Ubuntu, or a virtual box. You can download one here: https://mega.nz/#!1JpTiTjS!GdAHpa-_FAQAFPNypp3a3Up0B0yo1kYLXi3YLMXSAoo}. The password for this virtual box is "mavlabcourse" (the same as the username).

Steps you will need to follow:
# Install Paparazzi: http://wiki.paparazziuav.org/wiki/Installation . This is already done on the provided virtual box
# Start paparazzi with the default configuration
# Power up your Bebop.
# If you have a Bebop 2 or a Bebop 1 with firmware v3.2.0 or higher press the '''on/off button four times''' in short fast after powerup
# Make a Wifi connection with your PC and the Bebop
# In the Paparazzi center choose "Bebop" Or "Bebop2" in the airframe dropdown menu
# Press "Upload"
# Select Flight UDP in the session menu
# Press execute

Voila, you will get telemetry from the Bebop. Now it is up to you how and where to fly.
Useful things to watch are:
# The video series here: https://www.youtube.com/watch?v=eojAPZvT1Ck . Although it is made for the ARDrone the steps are very similar for the bebop drone.
# This site has several documents on how to program something for your drone: http://mavlabcourse.tk/ . Although these documents assume you have an indoor flight area, you can also fly outside with the internal GPS of the Bebop.

Do you need help with any of the steps? Please visit us at https://gitter.im/paparazzi/discuss

= Features =
== Connectivity ==
* Wi-Fi antennas: MIMO dual-band with 2 double-set of dipole antennas for 2.4 and 5 GHz
* Sending power: Up to 26 dBm
* Signal range: N/A

== Structure ==
* 4 Brushless Outrunner motors
* Glass fiber reinforced (15%) ABS structure
* High-resistance EPP outdoor hull: Clip and unclip easily to adapt to indoor and outdoor flight, protects the propellers against potential bumps, can be removed to reduce wind factor
* Three-blade auto-block propellers in Polycarbonate with fast disassembly system
* Anti-vibration bumpers

=== Full Motor details ===

In case for a simor motor model

* Magnets: 12
* Stators: 9
* Layers of stator metal: 15

* Copper windings: 34
* Copper diameter: 0.29mm
* Copper resistance: over 50 cm wire ~0.3 ohm

Dimentions:
* Flange height 7.67mm
* Flange dia22.7mm
* Axis length 19.4mm
* Axis dia 1.9 mm
* Statorheight 5.55mm
* Stator diam 18.33mm

Weight:
* Flange weight 3.05g
* Flange and magnets 5.15g (Magnet ~ 1.5mm thick on a Flange dia22.7mm)
* Magnet only (and the glue) 2.1g

== Camera ==
* Camera with "Fisheye" lens 180° 1/2,3": 6 optical elements and 14 Mega pixels sensor
* Video stabilization: Digital on 3-axes
* Video definition: 1920x1080p (30fps)
* Photo definition: 3800x3188 pixels
* Video encoding: H264
* Photo file format: RAW, DNG
* Internal memory: Flash 8 GB
* Extended memory: Micro USB

== Battery ==
* Lithium Polymer 1200 mAh
* Flight time: Around 12 minutes

== Processor ==
* Motherboard:
** Parrot P7 dual-core CPU Cortex A9
** Quad core GPU
** 8Gb flash memory
* All fixed on a magnesium shelf that acts as electromagnetic shielding and in the same run as a heat sink for heat dissipation and cooling of the all the onboard processors

== Sensors ==
* 3-axes magnetometer (AKM 8963)
* 3-axes gyroscope (MPU 6050)
* 3-axes accelerometer (MPU 6050)
* Optical-flow sensor (Fig.8): Vertical stabilization camera (Every 16 milliseconds, an image of the ground is taken and compared to the previous one to determine the speed of the Bebop Drone)
* Ultrasound sensor (Analyzes the flight altitude up to 8 meters)
* Pressure sensor (MS 5607)

== Geo-location ==
* GNSS (GPS + GLONASS + Galileo, [http://www.furuno.com/en/products/gnss-module/GN-87 Furuno GN-87F])

== Dimensions ==
* 28x32x3.6cm without the hull
* 33x38x3.6cm with the hull

== Weight ==
* 380g without the hull
* 400g with the hull

== OS/Software ==
* Operating system: Linux (kernel 3.4.11 #3 SMP PREEMPT)
* glibc: (Sourcery CodeBench Lite 2012.03-57) 2.15
* libstdc++: GLIBCXX_3.4 - GLIBCXX_3.4.16

= Pinout =
== GPIO ==
* 6 Fans Enable
* 9 WiFi Reset
* 73 P7MU IRQ
* 81 GPS Power Enable
* 85 Fan Enable
* 89 VCAM FSYNC gyro
* 90 HCAM FSYNC gyro
* 91 DRDY MPU6050
* 124 Magneto interrupt
* 128 (video) Slew rate??
* 129 VCAM enable
* 130 (video) Slew rate??
* 132 HCAM enable
* 199 BLDC micro-controller reset (forces it into bootloader) ON/OFF
* 200 US Pulse level
* 201 On/Off button (default monitor to files running: /bin/onoffbutton)
* 202 USB Host mode pin 3V3 (HOST_MODE_3V3)
* 203 USB Host mode on
* 204 USB0 OC

== PWM ==
* 6 Heating resistor for warming IMU sensors (125000ns period, 0ns duty)
* 8 MPU6050 clock (31510ns period, 15258ns duty) Desired frequency is 32768kHz with 50% duty cycle (period=30517us). Period was set empirically to 31517 to get a 5ms data ready period. Desired frequency is slightly modified to synchronize camera and IMU
* 9 Vertical camera clock (23ns period = 43MHz)
* 11 Horizontal camera lock (77ns period = 13MHz)

== I2C ==
* I2C-0
** FPGA
** P7MU
** EEPROM Unknown EEPROM for Front camera calibration (addr 0x55)
** MT9f002 CMOS Digital Image Sensor (1/2.3 inch 14Mp, front camera) [http://www.onsemi.com/PowerSolutions/product.do?id=MT9F002 MT9f002] (addr 0x10)
** MT9v117 CMOS Digital Image Sensor (1/6 inch VGA, bottom camera) [http://www.aptina.com/assets/downloadDocument.do?id=553 MT9v117] (addr 0x5d)
* I2C-1
** Cypress Motor Controller (Parrot BLDC) [[Bebop/BLDC]] (addr 0x08)
** AKM8963 Magnetometer [http://www.akm.com/akm/en/file/datasheet/AK8963.pdf AK8963]
** MS5607 Barometer [http://meas-spec.com/product/pressure/MS5607-02BA03.aspx MS5607]
* I2C-2
** MPU6050 Gyro + Accel [http://invensense.com/mems/gyro/documents/RM-MPU-6000A.pdf MPU6050] (rotation changed in version 2)

== SPI ==
* spidev1.0 Sonar (Only data pin connected for generating pulses)

== UART ==
* ttyPA1 GPS (Furuno GN-87F on v1 and Ublox Neo M8N on v2)

== Other ==
* /dev/hx280 Hantro (On2) Video encoder. Hantro chip video encoder used for the HCAM.
* /sys/bus/iio/devices/iio:device0 (p7mu-adc_2) Sonar ADC

= Actuators =
The Bebop has 4 Brushless motors, which are controlled by the cypress chip on I2C-1. This Cypress chip contains custom made firmware(BLDC) by Parrot, which can be automatically updated using a bootloader in the ESC part of the mainboard.
The firmware from Parrot contains a nice closed loop RPM control, which is automatically tuned inside the factory.
Since version 2 Parrot changed the order and rotation direction of the motors.

For more information about how to communicate with the BLDC look at [[Bebop/BLDC]]. Or take a look at the "bebop" actuator inside the <code>airborne/boards/bebop/</code> folder.

= Onboard applications =

The original programs on the Bebop

* /usr/bin/dragon-prog Main program that controls the drone
* /bin/watchdog.sh Checks if Dragon is still running and reboots dragon-prog if it somehow would not be running anymore

* BLDC_Test_Bench Controls the Brushless Motor Controllers for testing and playing sounds etc.
* bcmwl Everything with wifi
* diagnostic Outputs sensor diagnostic
* mk3_camera_eeprom Reads the front camera EEPROM
* config_mt9v117 Configure the bottom camera

= Cross compiler =
For the Bebop you need to use a recent version GNU gcc-arm-linux-gnueabi (Ubuntu/Linaro 4.7.4-2ubuntu1) 4.7.4 provided with Ubuntu since 14.04 LTS.

[http://electronics.stackexchange.com/questions/21594/is-code-sourcery-g-lite-still-a-viable-projectIn the past you could also crosscompile with Sourcery CodeBench Lite 2012.03-57 for ARM GNU/Linux from <s>Greedy</s> Mentor Graphics, previously called codesourcery. However the open'ness there is nowhere to be found anymore, so we'll say "No thanks" to Codesourcery ,now <s>Greedy</s> Mentor"]
but if you [http://sourcery.mentor.com/public/gnu_toolchain/arm-none-linux-gnueabi/arm-2012.03-57-arm-none-linux-gnueabi.bin insist] , feel <s>free</s> restricted.

= Tips & Tricks =

== Video ==
Make sure the [http://docs.paparazziuav.org/latest/module__video_rtp_stream.html video_rtp_stream.xml] module enabled in the airframe.
Receive a video stream with e.g. avplay, vlc or a python app:
$ avplay -loglevel quiet -max_delay 50 -fflags nobuffer rtp://192.168.42.1:5000
$ vlc ~/paparazzi/var/sdp_tmp/192.168.42.1/stream.sdp
$ ~/paparazzi/sw/tools/rtp_viewer/rtp_viewer.py

== Factory Reset ==
You can reset the Parrot Bebop Drone to factory settings. You '''will''' loose all your photos and movies recorded on your Bebop.
To do this you need to press and hold the power button for 10 seconds. The LED will blink green and orange for a while, then green and the drone will shutdown.

== Firmware ==
It is not important which firmware you use for Paparazzi to fly. Note that we test flew the Bebop with Firmware v1.98.11 and v2.0.57

Note that v3.2.0 is the latest Firmware know as of 20160413 and PPRZ video stream does not work. Feel free to fix it and make a pull request.
If even newer firmware is available please report any (if any) issues found related to the firmware.

= Using the MicroUSB for serial data =

The Bebop has this tiny USB connector just above the power button. This USB connector can also be used with help of a USB to Serial FTDI conversion board.
To use the driver in current firmware OTG serving should be off. More information, photos, connection examples, sourcode and real life example of how to use this port.

[[Category:Autopilots]]

Pixhawk

2016-12-13T19:15:28Z

Flixr: use wiki links!

<div style="float: right; width: 45%; overflow: hidden">[[File:Pixhawk 1 v2.4.jpg|thumb|Pixhawk 1 v2.4]]</div>

=Paparazzi on Pixhawk=

The Pixhawk is an open hardware autopilot that was originally developed by ETHZ in the [https://pixhawk.ethz.ch/ PIXHAWK project]. Paparazzi now supports the Pixhawk and the firmware can be uploaded through the orignal PX4 custom bootloader, which happens directly through the USB port of the Pixhawk. This means that it is possible to easily switch between the Paparazzi AP and other projects that support the Pixhawk hardware (i.e. PX4 and APM).

It is also possible to directly upload to the Pixhawk by means of the JTAG port, but this is not recommended as it involves soldering and permanently removes the PX4 bootloader (which means reverting to PX4 or APM firmware is complicated). Therefor, this wiki focuses on flashing through the PX4 bootloader.

An step-by-step example on flying Paparazzi with a Pixhawk can be found on the [[Iris]] page.

=Intro=

This page is intended as a guide on how to get the Paparazzi autopilot running on a Pixhawk board. For the specifications and pin-out details we recommend to look at the [https://pixhawk.org/modules/pixhawk Pixhawk site]. Details on how to flash the board with Paparazzi can be found [[#Flashing|below]]. A complete step by step example on how to get a drone flying with Paparazzi + Pixhawk is provided with the [[Iris]] drone. A list of features that are currently (not) supported in Paparazzi can be found [[#Features|here]].

The Pixhawk consists of the PX4IO (designed around a stm32f1) and the PX4FMU (designed around a stm32f4), which are glued together in one pcb. Uploading of the autopilot (which runs only on the PX4FMU) happens directly from computer over USB to the PX4FMU, by means of the PX4 bootloader. In the original PX4 and APM Pixhawk software, the compiled PX4IO code (which runs the Fly By Wire) is embedded with the PX4FMU code, and the PX4FMU code would flash the PX4IO board at startup. But, in Paparazzi, the PX4IO is flashed from the computer --> USB -> PX4FMU --> internal UART --> PX4IO, directly from Paparazzi Center. This means PX4IO board can be flashed without changing the autopilot, and vice versa.

=Getting started=

In short, the steps you'll need to run through are roughly the following:

*1. Define your aircraft and settings for the Pixhawk (e.g. see the [https://github.com/paparazzi/paparazzi/blob/master/conf/airframes/TUDELFT/tudelft_iris_indi.xml Iris airframe] )
*2. Connect the Pixhawk via USB to your computer, and upload the AP firmware
*3. Replug the USB, and upload the FBW code. Replug USB again.

Details on steps 2 and 3 can be found in [[#Flashing|Flashing]]. Details on step 1 can be found [[#Airframe config|further below]].

=Flashing=
[[File:Build AP.jpg|thumb|Figure 2; building the AP]]
[[File:Upload AP.jpg|thumb|Figure 3; flashing the AP]]
[[File:Build FBW.jpg|thumb|Figure 4; building the FBW]]
[[File:Upload FBW.jpg|thumb|Figure 5; flashing the FBW]]

In order to flash the Pixhawk, both the AP (AutoPilot on the PX4FMU) and the FBW (Fly By Wire on the PX4IO) have to be flashed. Paparazzi uses the default PX4 bootloader to upload and flash the code in both systems, but the FBW is flashed through the AP. This means that at least for the first time, the AP has to be flashed with Paparazzi first.

* To flash the AP (See figure 2 and 3):
** Select your aircraft (1).
** Select the AP (2).
** Click the build button (3).
** After the compilation was completed successfully (4), plug in the USB cable to computer and the Pixhawk.
** After 5 seconds click upload (5).
** You should see "upload successful" (6).

* To flash the FBW (See figure 4 and 5):
** Select FBW (7).
** Click the build button (8).
** After the compilation was completed successfully (9), plug in the USB cable to computer and the Pixhawk.
** After 5 seconds click upload (10).
** You should see "upload successful" (11).

Notes:
* After flashing the FBW, it is required to re-power the Pixhawk.
* The flashing of the FBW is disabled 20 seconds after power up. Re-power to reset the time.
* Whether the current code is APM, PX4 or Paparazzi, the flashing steps remain the same.
* In case of problems such as in figure 6, most of the time it can be solved by re-powering the Pixhawk (e.g. re-plugging the USB, and removing the battery), wait for 5 seconds for the computer to recognize the USB device, and click the upload button again.

[[File:Upload problems.jpg|thumb|Figure 6; upload problems]]

=Airframe config=

In order to fly a drone with the Pixhawk system in paparazzi, some Pixhawk specific configuration is required.

* Define seperate <firmware>'s for both the fbw and the ap:
{{Box Code|conf/airframes/<yourairframe>.xml|<source lang="xml">
<target name="ap" board="px4fmu_2.4" />
</source>}}
And:
{{Box Code|conf/airframes/<yourairframe>.xml|<source lang="xml">
<target name="fbw" board="px4io_2.4" />
</source>}}

*Configure the interMCU communication to use UART 6 at the AP:
{{Box Code|conf/airframes/<yourairframe>.xml|<source lang="xml">
<module name="intermcu" type="uart">
<configure name="INTERMCU_PORT" value="UART6" />
<configure name="INTERMCU_BAUD" value="B1500000" /> 
</module>
</source>}}
And at the FBW:
{{Box Code|conf/airframes/<yourairframe>.xml|<source lang="xml">
<define name="INTERMCU_LOST_CNT" value="100" />
<module name="intermcu" type="uart">
<configure name="INTERMCU_PORT" value="UART2" />
<configure name="INTERMCU_BAUD" value="B1500000" />
</module>
</source>}}
Configuration of the baud at 1500000 is strongly recommended, as this will remain backwards compatible with the PX4 code and bootloader. However, in Paparazzi the baud rate is slowed down to 230400 10s after start up, as the Pixhawk hardware actually does not seem to support flawless data transfers at those speeds. At least not in Paparazzi.
*Define the IMU to be:
{{Box Code|conf/airframes/<yourairframe>.xml|<source lang="xml">
<module name="imu" type="px4fmu_v2.4"/>
</source>}}
Which uses the l3gd20 gyro and the lsm303d accelero. The Pixhawk has two IMU's, so alternatively you can also use the MPU6000 IMU:
{{Box Code|conf/airframes/<yourairframe>.xml|<source lang="xml">
<module name="imu" type="mpu6000"/>
</source>}}

*Add the px4_flash module:
{{Box Code|conf/airframes/<yourairframe>.xml|<source lang="xml">
<modules main_freq="512">
<module name="px4_flash" />
...
</source>}}
This enables uploading through the PX4 bootloading and activates the usb-serial device after startup.

=Videos=

{{#ev:youtube|h44Np-O_X0w|200|left}} Paparazzi UAV Pixhawk support teaser - Video by the [http://mavlab.lr.tudelft.nl/ TU Delft MAVLab]

<br style="clear:both">

=Features=

The features that are currently supported by Paparazzi are the following:
*The dual processor setup (main stm32f4 and co stm32f1 processor), in a AP (AutoPilot) + FBW (Fly By Wire)
*Dual IMU (selectable from airframe config)
**MPU6000, 3axis acc + gyro + magneto
**LSM303 3-axis acc + magneto, L3G 3-axis gyro
*External GPS + Magneto
*8+6 pwm outputs (8 on FBW, 6 on AP)
*Arm button led denotes mode info
*Spektrum RC, including binding through software
*PPM RC

The features that are not yet supported by Paparazzi are the following:
*The multicolor led
*The buzzer
*The on-board arm button
*The SD card SDIO
*SBus out, RC downlink (e.g. gps info, battery info)

Iris

2016-12-13T19:11:11Z

Flixr: use wiki links!

[[File:Iris.jpg|thumb|The 3DR Iris+ with 3DR radio and 3DR RC receiver]]

= Introduction =

The Iris+ drone was manufactured by 3DR and is based around the Pixhawk autopilot. Paparazzi [[Pixhawk|supports]] the Pixhawk hardware, and this page serves as simple step-by-step guide to get a Pixhawk based drone flying on with the Paparazzi autopilot. In this example, only standard Pixhawk hardware is used, as it comes delivered with the stock Iris.

= Getting the Iris flight ready=

You'll need:
# The stock Iris drone, (equipped with the Pixhawk),
# Its stock 3DR radio's and 3DR RC.
# The Pixhawk should still contain the PX4 / APM bootloader.
# A computer with Paparazzi [[Installation|installed]].
# A micro USB cable.
# Optional: the 3DR Tarrot Gimbal and a GoPro 3.

Steps you will need to perform:
# Plug in the USB cable to the Iris. <b>Remove the props. Leave the battery disconnected.</b>
# Flash both the AP and FBW. See [[Pixhawk#Flashing|here] ]
# Power cycle the Pixhawk (e.g. replug USB).
# Make sure to set the target to AP again, and build. Uploading is not necessary, this step is required to prevent md5 checksum errors.
# Plug in the 3DR radio to the computer. Select the <i>Flight USB0 @57600</i> session in Paparazzi Center, and click execute. Paparazzi GCS will start.
# [[ImuCalibration|Calibrating the Magnetometer]] and [[#Calibrate the ESCs | calibrate the ESCs]] of the Iris+.

==Calibrate the ESCs==
The original PX4 firmware calibrates the ESCs automatically, paparazzi does not support this. Therefor it is needed to calibrate the ESCs manually. For this two options are available:
* Calibrate by using a servo tester
* Calibrate using <i> mode RC direct</i>
The first option requires the user to have a servo tester, open up the Iris+ and disconnect wires. Therefor, this wiki describes the second option.

In order to use the <i>RC direct mode</i>, a change is required in the airframe xml configuration. Comment or temporarily remove the following line:
{{Box Code|conf/airframes/TUDELFT/tudelft_iris_indi.xml|<source lang="xml">
<define name="FBW_MODE_AUTO_ONLY" value="true"/>
</source>}}
Optionally: change the following lines in the section AUTOPILOT:
{{Box Code|conf/airframes/TUDELFT/tudelft_iris_indi.xml|<source lang="xml">
<define name="MODE_STARTUP" value="AP_MODE_ATTITUDE_DIRECT" />
<define name="MODE_MANUAL" value="AP_MODE_ATTITUDE_DIRECT" />
</source>}}
to:
{{Box Code|conf/airframes/TUDELFT/tudelft_iris_indi.xml|<source lang="xml">
<define name="MODE_STARTUP" value="AP_MODE_RC_DIRECT" />
<define name="MODE_MANUAL" value="AP_MODE_RC_DIRECT" />
</source>}}
This last step is not required, but properly communicates the new mode to the GCS software.

<b> Important: for safety it is <i>strongly</i> recommended to remove the propellers </b> <br/>

[[File:3DRRC.jpg|thumb|Close up of the 3DR RC receiver. 1) The manual Kill switch. 2) The Gimbal control. 3) The mode switch.]]
Build and upload the FBW firmware, and if the optional steps were taken, also build and upload the AP.

The system is now ready to calibrate the ESCs. Perform the following steps:
* Power off the Iris+
* On the RC
** Set the set radio mode (switch 3 in figure 2) to <i>std</i>
** Disable manual kill by setting the kill switch (switch 1 in figure 2) to <i>on</i>
** Put the throttle to max.
** Turn on the RC
* Plug in the usb cable to the Iris+. The AP can now boot.
* Wait approximately 10 seconds until the leds blinks slow (once per second).
* Plug in the battery to the Iris+ (with props removed!). You should hear a beep coming from the ESCs.
* On the RC, put the throttle to zero. You should hear confirmation beeps from the ESCs.
* Validate the range of the throttle stick by slowly throttling up to max. The motors should spin accordingly.
* Revert the changes made to the airframe xml, and upload the firmware(s).

Iris

2016-12-13T19:09:43Z

Flixr: use wiki links!

[[File:Iris.jpg|thumb|The 3DR Iris+ with 3DR radio and 3DR RC receiver]]

= Introduction =

The Iris+ drone was manufactured by 3DR and is based around the Pixhawk autopilot. Paparazzi [[Pixhawk|supports]] the Pixhawk hardware, and this page serves as simple step-by-step guide to get a Pixhawk based drone flying on with the Paparazzi autopilot. In this example, only standard Pixhawk hardware is used, as it comes delivered with the stock Iris.

= Getting the Iris flight ready=

You'll need:
# The stock Iris drone, (equipped with the Pixhawk),
# Its stock 3DR radio's and 3DR RC.
# The Pixhawk should still contain the PX4 / APM bootloader.
# A computer with Paparazzi [http://wiki.paparazziuav.org/wiki/Installation installed].
# A micro USB cable.
# Optional: the 3DR Tarrot Gimbal and a GoPro 3.

Steps you will need to perform:
# Plug in the USB cable to the Iris. <b>Remove the props. Leave the battery disconnected.</b>
# Flash both the AP and FBW. See [https://wiki.paparazziuav.org/wiki/Pixhawk#Flashing here]
# Power cycle the Pixhawk (e.g. replug USB).
# Make sure to set the target to AP again, and build. Uploading is not necessary, this step is required to prevent md5 checksum errors.
# Plug in the 3DR radio to the computer. Select the <i>Flight USB0 @57600</i> session in Paparazzi Center, and click execute. Paparazzi GCS will start.
# [https://wiki.paparazziuav.org/wiki/ImuCalibration Calibrating the Magnetometer] and [[#Calibrate the ESCs | calibrate the ESCs]] of the Iris+.

==Calibrate the ESCs==
The original PX4 firmware calibrates the ESCs automatically, paparazzi does not support this. Therefor it is needed to calibrate the ESCs manually. For this two options are available:
* Calibrate by using a servo tester
* Calibrate using <i> mode RC direct</i>
The first option requires the user to have a servo tester, open up the Iris+ and disconnect wires. Therefor, this wiki describes the second option.

In order to use the <i>RC direct mode</i>, a change is required in the airframe xml configuration. Comment or temporarily remove the following line:
{{Box Code|conf/airframes/TUDELFT/tudelft_iris_indi.xml|<source lang="xml">
<define name="FBW_MODE_AUTO_ONLY" value="true"/>
</source>}}
Optionally: change the following lines in the section AUTOPILOT:
{{Box Code|conf/airframes/TUDELFT/tudelft_iris_indi.xml|<source lang="xml">
<define name="MODE_STARTUP" value="AP_MODE_ATTITUDE_DIRECT" />
<define name="MODE_MANUAL" value="AP_MODE_ATTITUDE_DIRECT" />
</source>}}
to:
{{Box Code|conf/airframes/TUDELFT/tudelft_iris_indi.xml|<source lang="xml">
<define name="MODE_STARTUP" value="AP_MODE_RC_DIRECT" />
<define name="MODE_MANUAL" value="AP_MODE_RC_DIRECT" />
</source>}}
This last step is not required, but properly communicates the new mode to the GCS software.

<b> Important: for safety it is <i>strongly</i> recommended to remove the propellers </b> <br/>

[[File:3DRRC.jpg|thumb|Close up of the 3DR RC receiver. 1) The manual Kill switch. 2) The Gimbal control. 3) The mode switch.]]
Build and upload the FBW firmware, and if the optional steps were taken, also build and upload the AP.

The system is now ready to calibrate the ESCs. Perform the following steps:
* Power off the Iris+
* On the RC
** Set the set radio mode (switch 3 in figure 2) to <i>std</i>
** Disable manual kill by setting the kill switch (switch 1 in figure 2) to <i>on</i>
** Put the throttle to max.
** Turn on the RC
* Plug in the usb cable to the Iris+. The AP can now boot.
* Wait approximately 10 seconds until the leds blinks slow (once per second).
* Plug in the battery to the Iris+ (with props removed!). You should hear a beep coming from the ESCs.
* On the RC, put the throttle to zero. You should hear confirmation beeps from the ESCs.
* Validate the range of the throttle stick by slowly throttling up to max. The motors should spin accordingly.
* Revert the changes made to the airframe xml, and upload the firmware(s).

Main Page

2016-10-02T08:12:18Z

Flixr: v5.10 released

__NOTOC__
__NOEDITSECTION__

[[Image:Welcome to paparazziuav.png|600px|center]]

<center>{{Hotbar}}</center>

'''[http://paparazziuav.org Paparazzi UAV]''' (Unmanned Aerial Vehicle) is an open-source drone hardware and software project encompassing autopilot systems and ground station software for multicopters/multirotors, fixed-wing, helicopters and hybrid aircraft that was founded in 2003. [http://paparazziuav.org Paparazzi UAV] was designed with autonomous flight as the primary focus and manual flying as the secondary. From the beginning it was designed with portability in mind and the ability to control multiple aircraft within the same system. Paparazzi features a dynamic flight plan system that is defined by mission states and using way points as “variables”. This makes it easy to create very complex fully automated missions without the operators intervention. For more project information, [[General|see here]].

{{P Header Box|color=#D51D00|size=100%|<center>Legal Disclaimer</center>}}

The Paparazzi software source and hardware design is distributed without any guarantee. Before flying, please refer to your country's national aviation regulation for Unmanned Aerial Systems, or the one of the country you intend to overfly.


{{P Topic Table|{{P Header Box|ico=favicon32.png|[[General]]}}
{{:General/Index}}
{{P Header Box|ico=Gear.png|[[Hardware]]}}
{{:Hardware/Index}}
{{P Header Box|ico=Code.png|[[Software]]}}
{{:Software/Index}}
{{P Header Box|ico=favicon32.png|[[Miscellaneous]]}}
{{:Miscellaneous/Index}}

|{{P Release|v5.10_stable|v5.10}}


{{P Header Box|ico=RSS.png|[http://blog.paparazziuav.org Paparazzi UAV Blog]}}
<rss max=10 item-max-length="1000">http://feeds.feedburner.com/PaparazziBlog</rss>


{{P Header Box|ico=Video.png|Video Collection}}

<center>{{#ev:youtubeplaylist|PLekU8nVT6qLm3oOudER7WVuj2plH_aU4u}}</center>

}}

Subsystem/stabilization

2016-09-26T18:31:12Z

Flixr: /* Rate Control */

<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages hideprefix=always>Subsystems</categorytree>
== Stabilization subsystem ==
The ''stabilization'' subsystem provides the attitude controller for rotorcrafts.

Currently possible attitude ''stabilization'' subsystem types are
* ''[[Subsystem/stabilization#Quaternion|int_quat]]''
* ''[[Subsystem/stabilization#Quaternion|float_quat]]''
* ''[[Subsystem/stabilization#Euler|int_euler]]''
* ''[[Subsystem/stabilization#Euler|float_euler]]''
* ''[[Subsystem/stabilization#INDI|indi]]''

== Attitude Control Implementations ==
There are several different attitude control algorithm implementations.

They use the same ''STABILIZATION_ATTITUDE'' xml configuration section:
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<section name="STABILIZATION_ATTITUDE" prefix="STABILIZATION_ATTITUDE_">

<define name="SP_MAX_PHI" value="45." unit="deg"/>
<define name="SP_MAX_THETA" value="45." unit="deg"/>
<define name="SP_MAX_R" value="90." unit="deg/s"/>
<define name="DEADBAND_A" value="0"/>
<define name="DEADBAND_E" value="0"/>
<define name="DEADBAND_R" value="250"/>


<define name="REF_OMEGA_P" value="800" unit="deg/s"/>
<define name="REF_ZETA_P" value="0.85"/>
<define name="REF_MAX_P" value="400." unit="deg/s"/>
<define name="REF_MAX_PDOT" value="RadOfDeg(8000.)"/>

<define name="REF_OMEGA_Q" value="800" unit="deg/s"/>
<define name="REF_ZETA_Q" value="0.85"/>
<define name="REF_MAX_Q" value="400." unit="deg/s"/>
<define name="REF_MAX_QDOT" value="RadOfDeg(8000.)"/>

<define name="REF_OMEGA_R" value="500" unit="deg/s"/>
<define name="REF_ZETA_R" value="0.85"/>
<define name="REF_MAX_R" value="180." unit="deg/s"/>
<define name="REF_MAX_RDOT" value="RadOfDeg(1800.)"/>


<define name="PHI_PGAIN" value="1000"/>
<define name="PHI_DGAIN" value="400"/>
<define name="PHI_IGAIN" value="200"/>

<define name="THETA_PGAIN" value="1000"/>
<define name="THETA_DGAIN" value="400"/>
<define name="THETA_IGAIN" value="200"/>

<define name="PSI_PGAIN" value="500"/>
<define name="PSI_DGAIN" value="300"/>
<define name="PSI_IGAIN" value="10"/>


<define name="PHI_DDGAIN" value="300"/>
<define name="THETA_DDGAIN" value="300"/>
<define name="PSI_DDGAIN" value="300"/>
</section>
</source>
}}

; ''SP_MAX_*'': maximum ''PHI''/''THETA'' (roll/pitch) angles and maximum angular velocity ''R'' around yaw axis
; ''DEADBAND_*'': RC stick deadband around the center for ''A'',''E'',''R'' (roll,pitch,yaw)
; ''REF_*'': parameters for the [[Control_Loops#Reference_generators_2|reference generator]]
; ''REF_OMEGA_*'' : second order model natural frequency for respective axis
; ''REF_ZETA_*'' : second order model damping factor for respective axis
; ''REF_MAX_x'' : bound on ref model angular speed
; ''REF_MAX_xDOT'' : bound on ref model angular acceleration
; ''[PHI|THETA|PSI]_[PID]GAIN'': gains for the feedback control of the respective axis
; ''[PHI|THETA|PSI]_DDGAIN'': feedforward gains for the respective axis

=== Quaternion ===
Attitude controllers using quaternions (no gimbal lock).
There is a fixed point implementation (recommended) and a floating point implementation for reference and testing.

* fixed point: <source lang="xml"><subsystem name="stabilization" type="int_quat"/></source>
* floating point: <source lang="xml"><subsystem name="stabilization" type="float_quat"/></source>
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="rotorcraft">
...
<subsystem name="stabilization" type="int_quat"/>
</firmware>
</source>
}}
You also need the ''STABILIZATION_ATTITUDE'' xml configuration section as described above.

=== Euler ===
Attitude controller using Euler Angles. Due to the inherent singularities (e.g. 90deg pitch) of the euler angles representation you can't use this controller if you want to fly in regimes close or at these singularities (e.g. acrobatics or transitioning vehicles).
See [[Control_Loops#Attitude_loop]] for diagrams of the control loop.
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="rotorcraft">
...
<subsystem name="stabilization" type="int_euler"/>
</firmware>
</source>
}}
You also need the ''STABILIZATION_ATTITUDE'' xml configuration section as described above.

=== INDI ===
Attitude controller based on an Incremental Nonlinear Dynamic Inversion inner loop. It controls the angular acceleration in an incremental way. Detailed information can be found in the paper 'Adaptive Incremental Nonlinear Dynamic Inversion for Micro Aerial Vehicles' (http://arc.aiaa.org/doi/abs/10.2514/1.G001490).

The idea is that any moment on the drone, results in an angular acceleration. With the onboard gyroscope, we measure the angular rate. This means that if we take the derivative of the angular rate, we have a measure of all moments on the drone through the angular acceleration. This includes the moment caused by the inputs. We know what the angular acceleration is with the inputs that we are giving, so to change the angular acceleration to a desired value, we just need to increment these inputs. How much we should increment the inputs to get a certain increment in angular acceleration is determined by the ''control effectiveness''.

The benefit of using INDI over PID is that the disturbance rejection is a lot faster. This means that an external moment on the drone due to wind or something else is counteracted as fast as the drone can measure it and the actuators can move. Compare this to the integrator gain of a PID controller, that only slowly removes steady state offsets.

More practical information can be found on [[working with INDI]]

== Rate Control ==
There is only one rate control implementation. It allows you to fly a rotorcraft like a helicopter by controlling the angular rate directly instead of having (self-leveling) attitude control.
See [[Control_Loops#Rate_loop]] for diagrams of the control loop.
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="rotorcraft">
...
<module name="stabilization" type="rate"/>
</firmware>

<section name="STABILIZATION_RATE" prefix="STABILIZATION_RATE_">

<define name="SP_MAX_P" value="10000"/>
<define name="SP_MAX_Q" value="10000"/>
<define name="SP_MAX_R" value="10000"/>
<define name="DEADBAND_P" value="20"/>
<define name="DEADBAND_Q" value="20"/>
<define name="DEADBAND_R" value="200"/>
<define name="REF_TAU" value="4"/>


<define name="GAIN_P" value="400"/>
<define name="GAIN_Q" value="400"/>
<define name="GAIN_R" value="350"/>

<define name="IGAIN_P" value="75"/>
<define name="IGAIN_Q" value="75"/>
<define name="IGAIN_R" value="50"/>


<define name="DDGAIN_P" value="300"/>
<define name="DDGAIN_Q" value="300"/>
<define name="DDGAIN_R" value="300"/>
</section>
</source>
}}

[[Category:User_Documentation]] [[Category:Subsystems]]

MediaWiki:Sidebar

2016-08-24T19:07:44Z

Flixr:

MediaWiki:Sidebar

2016-08-24T19:06:59Z

Flixr:

MediaWiki:Sidebar

2016-08-24T19:06:40Z

Flixr:

MediaWiki:Sidebar

2016-08-24T19:06:17Z

Flixr: add quick link for howto get a wiki account

Contributing

2016-08-24T17:26:03Z

Flixr: /* Wiki */

== How to contribute ==
There are lots of ways to contribute to Paparazzi and get involved. Contributions in the form of elaborating on and expanding documentation, wiki pages, tutorials and code fixes are always welcome and encouraged.

This page will give you a head start on how you can contribute.

=== Wiki ===

If you don't have a Wiki account yet join the [https://gitter.im/paparazzi/discuss Gitter channel] (there is an open chat button in the right lower corner of the page too) and ask and we will Create an account for you. We had to disable normal account creation due to spam attacks.

You can then immediately start adding information, cleaning up, or fixing typos. It is a tremendous contribution to the quality of the PaparazziUAV documentation when you do this! Just Do It:

[[Image:Just_Do_It.gif|400px]]

You do not need a lot of deep technical knowledge to be helpful. If you read something and it is not clear to you, ask for an explanation in the Gitter Chat and then do not forget to add that information to the Wiki.

Some information and links on how to edit the wiki can be found at [[Help:Editing|Help with Editing]].

Please be aware of past edits and page histories. Try not to remove this; if you are moving/renaming a page, use the '''move''' tab at the top of a page. This ensures the revision history is moved with the page.

=== Software development ===

[[File:AGoodCombinationSTM32ProgressnDebugging.jpg|300px|thumb|Left|Learning Tools]]

We use the distributed version control system [http://git-scm.com/ git]. The [http://github.com/paparazzi/paparazzi/ Papaprazzi master repository is hosted on Github].

Also see the [[Git|Git wiki page]] for more details about setting up Git and cloning the source-code and data repository.

Please also have a look at the [http://docs.paparazziuav.org/latest/styleguide.html Coding Style Guide].

Here is the short version if you already know git:
# Create an account on [http://github.com/ github].
# Fork the [http://github.com/paparazzi/paparazzi/ papaprazzi repo] on github. (After logging in press the '''fork''' button).
# If you want to clone with SSH: '''git clone git@github.com:<yourname>/paparazzi.git'''<br/>Or with HTTPS: '''git clone <nowiki>https://github.com/<yourname>/paparazzi.git</nowiki>'''<br/>[https://help.github.com/articles/which-remote-url-should-i-use Which remote URL should I use?]
# '''git remote add upstream <nowiki>https://github.com/paparazzi/paparazzi.git</nowiki>'''
# '''git fetch upstream'''
# checkout a new branch based on the development branch (master):<br/>'''git checkout -b my_new_feature upstream/master'''
# fix/code and commit in logical units (with a [http://bit.ly/goodcommitmessages good commit message])
# push your feature/bugfix branch
# Send us a [http://help.github.com/pull-requests/ pull request] on github. (Or send patches to the mailing list).

=== Defects and Features ===
To report a Paparazzi defect or issue. Submit a feature request using the simple [https://github.com/paparazzi/paparazzi/issues issue tracker on github].

=== Continuous Integration Builds ===
There are [[Builds|build servers]] running some [[Builds/Tests|Continuous Integration tests]].

[[Category:Developer_Documentation]]

Main Page

2016-08-22T21:24:30Z

Flixr: Protected "Main Page": fuck the spammers ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))

__NOTOC__
__NOEDITSECTION__

[[Image:Welcome to paparazziuav.png|600px|center]]

<center>{{Hotbar}}</center>

'''[http://paparazziuav.org Paparazzi UAV]''' (Unmanned Aerial Vehicle) is an open-source drone hardware and software project encompassing autopilot systems and ground station software for multicopters/multirotors, fixed-wing, helicopters and hybrid aircraft that was founded in 2003. [http://paparazziuav.org Paparazzi UAV] was designed with autonomous flight as the primary focus and manual flying as the secondary. From the beginning it was designed with portability in mind and the ability to control multiple aircraft within the same system. Paparazzi features a dynamic flight plan system that is defined by mission states and using way points as “variables”. This makes it easy to create very complex fully automated missions without the operators intervention. For more project information, [[General|see here]].

{{P Header Box|color=#D51D00|size=100%|<center>Legal Disclaimer</center>}}

The Paparazzi software source and hardware design is distributed without any guarantee. Before flying, please refer to your country's national aviation regulation for Unmanned Aerial Systems, or the one of the country you intend to overfly.


{{P Topic Table|{{P Header Box|ico=favicon32.png|[[General]]}}
{{:General/Index}}
{{P Header Box|ico=Gear.png|[[Hardware]]}}
{{:Hardware/Index}}
{{P Header Box|ico=Code.png|[[Software]]}}
{{:Software/Index}}
{{P Header Box|ico=favicon32.png|[[Miscellaneous]]}}
{{:Miscellaneous/Index}}

|{{P Release|v5.8.2_stable|v5.8}}


{{P Header Box|ico=RSS.png|[http://blog.paparazziuav.org Paparazzi UAV Blog]}}
<rss max=10 item-max-length="1000">http://feeds.feedburner.com/PaparazziBlog</rss>


{{P Header Box|ico=Video.png|Video Collection}}

<center>{{#ev:youtubeplaylist|PLekU8nVT6qLm3oOudER7WVuj2plH_aU4u}}</center>

}}

Talk:Main Page

2016-08-22T21:23:28Z

Flixr: Flixr moved page Talk:Thunderbird Technical Support Phone Number +1 888-990-8801 to Talk:Main Page over a redirect without leaving a redirect: fucking spammers

Main Page

2016-08-22T21:23:27Z

Flixr: Flixr moved page Thunderbird Technical Support Phone Number +1 888-990-8801 to Main Page over a redirect without leaving a redirect: fucking spammers

__NOTOC__
__NOEDITSECTION__

[[Image:Welcome to paparazziuav.png|600px|center]]

<center>{{Hotbar}}</center>

'''[http://paparazziuav.org Paparazzi UAV]''' (Unmanned Aerial Vehicle) is an open-source drone hardware and software project encompassing autopilot systems and ground station software for multicopters/multirotors, fixed-wing, helicopters and hybrid aircraft that was founded in 2003. [http://paparazziuav.org Paparazzi UAV] was designed with autonomous flight as the primary focus and manual flying as the secondary. From the beginning it was designed with portability in mind and the ability to control multiple aircraft within the same system. Paparazzi features a dynamic flight plan system that is defined by mission states and using way points as “variables”. This makes it easy to create very complex fully automated missions without the operators intervention. For more project information, [[General|see here]].

{{P Header Box|color=#D51D00|size=100%|<center>Legal Disclaimer</center>}}

The Paparazzi software source and hardware design is distributed without any guarantee. Before flying, please refer to your country's national aviation regulation for Unmanned Aerial Systems, or the one of the country you intend to overfly.


{{P Topic Table|{{P Header Box|ico=favicon32.png|[[General]]}}
{{:General/Index}}
{{P Header Box|ico=Gear.png|[[Hardware]]}}
{{:Hardware/Index}}
{{P Header Box|ico=Code.png|[[Software]]}}
{{:Software/Index}}
{{P Header Box|ico=favicon32.png|[[Miscellaneous]]}}
{{:Miscellaneous/Index}}

|{{P Release|v5.8.2_stable|v5.8}}


{{P Header Box|ico=RSS.png|[http://blog.paparazziuav.org Paparazzi UAV Blog]}}
<rss max=10 item-max-length="1000">http://feeds.feedburner.com/PaparazziBlog</rss>


{{P Header Box|ico=Video.png|Video Collection}}

<center>{{#ev:youtubeplaylist|PLekU8nVT6qLm3oOudER7WVuj2plH_aU4u}}</center>

}}

Main Page

2016-08-22T21:20:06Z

Flixr: Reverted edits by Spammer (talk) to last revision by Flixr

__NOTOC__
__NOEDITSECTION__

[[Image:Welcome to paparazziuav.png|600px|center]]

<center>{{Hotbar}}</center>

'''[http://paparazziuav.org Paparazzi UAV]''' (Unmanned Aerial Vehicle) is an open-source drone hardware and software project encompassing autopilot systems and ground station software for multicopters/multirotors, fixed-wing, helicopters and hybrid aircraft that was founded in 2003. [http://paparazziuav.org Paparazzi UAV] was designed with autonomous flight as the primary focus and manual flying as the secondary. From the beginning it was designed with portability in mind and the ability to control multiple aircraft within the same system. Paparazzi features a dynamic flight plan system that is defined by mission states and using way points as “variables”. This makes it easy to create very complex fully automated missions without the operators intervention. For more project information, [[General|see here]].

{{P Header Box|color=#D51D00|size=100%|<center>Legal Disclaimer</center>}}

The Paparazzi software source and hardware design is distributed without any guarantee. Before flying, please refer to your country's national aviation regulation for Unmanned Aerial Systems, or the one of the country you intend to overfly.


{{P Topic Table|{{P Header Box|ico=favicon32.png|[[General]]}}
{{:General/Index}}
{{P Header Box|ico=Gear.png|[[Hardware]]}}
{{:Hardware/Index}}
{{P Header Box|ico=Code.png|[[Software]]}}
{{:Software/Index}}
{{P Header Box|ico=favicon32.png|[[Miscellaneous]]}}
{{:Miscellaneous/Index}}

|{{P Release|v5.8.2_stable|v5.8}}


{{P Header Box|ico=RSS.png|[http://blog.paparazziuav.org Paparazzi UAV Blog]}}
<rss max=10 item-max-length="1000">http://feeds.feedburner.com/PaparazziBlog</rss>


{{P Header Box|ico=Video.png|Video Collection}}

<center>{{#ev:youtubeplaylist|PLekU8nVT6qLm3oOudER7WVuj2plH_aU4u}}</center>

}}

Joystick

2016-07-23T18:58:56Z

Flixr:

=Introduction=

A Joystick can be used to control your aircraft in the simulator or via the modem [[Subsystem/radio_control#Datalink|using radio_control type datalink]] in real flight using [[Input2Ivy]].

==Examples==
Here a regular gaming pad, perfectly capable to control your aircraft when in manual or assisted flight

<gallery>
File:Logitech_Extreme_3D_Pro_Joystick.jpg|Logitech Extreme 3D_Pro Joystick
</gallery>

Here and example of an Joystic that looks like an RC transmitter, but is just an USB connected Joystick. Handy for quick tests, and for ER 13, why not add one to you Paparazzi toolset?

<gallery>
File:Hk_6ch_rc_joystick_overview.jpg|Hk 6channel RC transmitterlook joystick via USB
File:Hk_6ch_rc_joystick_large.jpg|Hk 6channel RC transmitterlook joystick via USB closeup
</gallery>

Here a real RC transmitter connected via trainer port to your PC to be used as a Joystick

=Quick test=

If plugged in, under Linux a quick test to see if the device is recognized via:

$ dmesg

Although the message is a little different for evey joysticktype, it should display something like this in last lines:

...
[ 8988.708567] usb 2-4.3: new low-speed USB device number 7 using ehci-pci
[ 8988.804672] usb 2-4.3: New USB device found, idVendor=0603, idProduct=1a13
[ 8988.804679] usb 2-4.3: New USB device strings: Mfr=0, Product=34, SerialNumber=0
[ 8988.804683] usb 2-4.3: Product: ART TECH GAME.
[ 8988.808821] input: ART TECH GAME. as /devices/pci0000:00/0000:00:06.1/usb2/2-4/2-4.3/2-4.3:1.0/input/input14
[ 8988.809007] hid-generic 0003:0603:1A13.0006: input,hidraw4: USB HID v1.00 Joystick [ART TECH GAME. ] on usb-0000:00:06.1-4.3/input0
...
=Joystick Calibration=
You should always calibrate your joystick. By calibrating you make sure that your Joystick is not sending steering comanding values; while it should not when the steering sticks are in neutral position.

==Linux==
Install the joystick and the jstest-gtk packages via:

$ sudo apt-get install joystick jstest-gtk

Use the graphical jstest-gtk tool (or the commandline jstest) to view/edit your joystick calibration and axis/button mappings.
Start it via:

$ jstest-gtk

===Store the calbration===
Your calibration and mapping will only be lost once you unplug the joystick, so store your configuration via:

$ sudo jscal-store /dev/input/js0

If you replug your joystick the next time, udev should take care of automatically loading the appropriate configuration.

==OSX==

Feel free to add your instructions here.

[[Category:Hardware]] [[Category:User_Documentation]]

Flight Plans

2016-07-13T12:28:37Z

Flixr: /* Call */

A '''flight plan''' is a XML document which one can create and store aboard an autopilot. The flight plan will describe how you want your aircraft to travel if released into into the wild blue yonder.

== DTD and Structure ==

The formal description of the flight plan file is given in the [http://en.wikipedia.org/wiki/Document_Type_Definition '''DTD'''] (located in <tt>conf/flight_plans/flight_plan.dtd</tt>). This
DTD must be referenced in the header of your flight plan XML document using the following line:<br>

<source lang="xml"><!DOCTYPE flight_plan SYSTEM "flight_plan.dtd"></source>

The flight plans are stored in the <tt>conf/flight_plans</tt> directory. The [[Flight_Plan_Editor|flight plan editor]] can be used to create basic flight plans via the GUI.

Extract from the [http://en.wikipedia.org/wiki/Document_Type_Definition DTD]:
<tt><!ELEMENT flight_plan (header?,waypoints,sectors?,variables?,includes?,exceptions?,blocks)></tt>

'''A flight plan is composed of two mandatory elements: [[#waypoints|waypoints]] and [[#blocks|blocks]]'''

The root <tt>flight_plan</tt> element is specified with several attributes:
<tt>'''<flight_plan name lat0 lon0 ground_alt security_height home_mode_height qfu alt max_dist_from_home>'''</tt>
; <tt>'''name'''</tt>: The name of the mission (a text string)
; <tt>'''lat0, lon0'''</tt>: Defines the latitude and longitude coordinates of the reference point {0,0} in WGS84 degree coordinates
; <tt>'''ground_alt'''</tt>: The ground altitude (in meters), Above Sea Level where you are flying. It defines the <tt>GROUND_ALT</tt> constant value which can be used in combination with a waypoint <height> parameter to define a waypoint height
; <tt>'''security_height'''</tt>: The height (over <tt>'''ground_alt'''</tt>) used by the circle-home failsafe procedure and in other flight procedures such as formation flight and anti-collision avoidance. Warnings are produced if you place a waypoint lower than <tt>'''security_height'''</tt> (usually the case for the landing point)
; <tt>'''home_mode_height'''</tt> (optional): This optional attribute available since v4.2 allows to override <tt>'''security_height'''</tt> as failsafe height in home mode. If <tt>'''home_mode_height'''</tt> Is set lower than <tt>'''security_height'''</tt>, the later is used. This attribute is useful if you need to return home at a high altitude rather than a low altitude.
; <tt>'''qfu'''</tt> (optional): defines the global constant <tt>QFU</tt>. It usually is the magnetic heading in degrees (north=0, east=90) of the runway, the opposite of wind direction. This constant may be used in the mission description. It is also used by the simulator as the original course of the aircraft. So if you want to take off and climb to the West you would use qfu=270.
; <tt>'''alt'''</tt>: The default altitude of waypoints ([[Altitude_definitions|Above Sea Level]]). So if your ground altitude is 400 then alt needs to be a value greater than ground altitude and above any obstructions in the flight plan.
; <tt>'''max_dist_from_home'''</tt>: A radius representing the maximum allowed distance (in meters) from the HOME waypoint. Exceeding this value (ie flying outside the circle with this radius) will trigger an exception. It is up to you to define the block to be executed (ie what to do) for the exception.

''Here is an '''example''' of such a line in the top of a flight plan:''

<source lang="xml">
<flight_plan alt="250" ground_alt="185" lat0="43.46223" lon0="1.27289" name="Example Muret" max_dist_from_home="300" qfu="270" security_height="25" >
</source>

Note that a flight plan could also contain optional <tt>include</tt>'s and <tt>exceptions</tt> cases.

In English the above flight plan says the name is Example Muret. The reference coordinates for the 0,0 point is: 43.46223 (lat) and 1.27289 (long). The flying site 0,0 location is 185m above sea level. The security height is 25m above 0,0 point or 210m above sea level. The default (ie if not defined in a waypoint this alt is used) altitude is 250m (above sea level). The home mode block altitude is defined to be 150m above sea level. Also, for security, a circle is defined with a radius that's 300m from 0,0 position. This is the max_dist_from_home value. Fly 301m from 0,0 and an exception is triggered. A useful block is to trigger/go to the home mode block and return to home when the aircraft flies outside the safety circle. Example flight plans are helpful for study before you build your own from scratch.

== Waypoints ==

The waypoints are the geographic locations used to specify the trajectories. A waypoint is specified by it's name and coordinates:
<tt>''' <waypoint name wpx wpy [alt] [height]/> '''</tt>
where wpx and wpy are real positional coordinates ( <tt>'''lat/lon'''</tt> ) '''or''' UTM coordinates ( <tt>'''utm_x0/utm_y0'''</tt> ) '''or''' relative coordinates ( <tt>'''x/y'''</tt> ) in meters from your reference point {0,0} . <tt>alt</tt> is an optional parameter and can be used to assign an altitude to a particular waypoint that is different from the globally defined <tt>alt</tt> parameter of the flightplan. The <tt>height</tt> attribute can be used to set the waypoint height relative to the [[Altitude_definitions|ground altitude]] (<tt>ground_alt</tt>) of the flight plan for this waypoint.

An example:
<source lang="xml">
<waypoints>
<waypoint name="HOME" x="0.0" y="30.0"/>
<waypoint name="BRIDGEOVERRIVER" x="-100.0" y="60.0" alt="270."/>
<waypoint name="MyBarn" x="-130.0" y="217.5" alt="3000."/>
<waypoint name="3" x="-30.0" y="50" height="50."/>
<waypoint name="4" x="-30.0" y="50." alt="ground_alt + 50"/>
<waypoint name="_MYHELPERSPOT" x="-30.0" y="60" height="50."/>
<waypoint name="_MYOTHERHELPERSPOT" x="-70.0" y="90" height="70."/>
<waypoint name="TOWER" lat="48.858249" lon="2.294494" height="324."/>
<waypoint name="MountainCAFE" utm_x0="360284.8" utm_y0="4813595.5" alt="1965."/>
</waypoints>
</source>

'''Tips'''
* Waypoints are easily adjusted with the [[Flight_Plan_Editor|flight plan editor]].
* If a waypoint name starts with an underscore ( _ ), the waypoint is '''not displayed''' in the GCS, except in editor mode.
* The maximum number of waypoints is 254.
* A waypoint named <tt>HOME</tt> is required if the failsafe HOME mode procedure is used.
* A waypoints index/reference pointer is derived by prefixing the waypoint name with "WP_". Useful when a [[#Call |call function]] uses the waypoints reference index vs. it's name.

== Sectors ==

=== Static sectors (default) ===

Flat ''Sectors'' can be described as an area defined by list of waypoint corners. Such an area will be displayed in the Ground Control Station (GCS) by colored lines connecting the cornerpoints.
A function is generated to check if a point, usually the aircraft itself, is ''inside'' this sector. Currently, this feature requires that the polygon is <b>convex</b> and described in a <b>clockwise</b> order. For a sector named <tt>MyBigGarden</tt> the generated function for the example here would be <tt>bool_t InsideMyBigGarden(float x, float y);</tt> where <tt>x</tt> and <tt>y</tt> are east and north coordinated, in meters, relative to the geographic reference of the flight plan. If the flight plan is dynamically relocated, such a sector will be relocated but the display is currently not updated on the GCS. It would be great if one would help improving that part of the source code. Note that sector names are not allowed to contain spaces.

For example, with the following element in a flight plan.
<source lang="xml">
<sectors>
<sector name="MyBigGarden" color="red">
<corner name="_1"/>
<corner name="_2"/>
<corner name="_3"/>
<corner name="_4"/>
</sector>
</sectors>
</source>

It is then possible to add an exception clause to your flightplan. For example if the aircraft for some reason flies outside this, defined by us, sector the airframe will fly to a standby waypoint. The exclamation mark (!) means the boolean operator <tt>NOT</tt> in this example. In regular language one would describe "If my airframe is NOT inside the MyBigGarden sector anymore then deroute it to the standby waypoint. In Flightplan "Speak" this is written like:
<source lang="xml">
<exception cond="! InsideMyBigGarden(GetPosX(), GetPosY())" deroute="standby"/>
</source>

NOTE: editing of the waypoints of the sector during the flight will not dynamically update the inside function. It will always check if the position is inside the original sector.

'''Tips'''
* A nice option in the corner notation is that one can add an underscore ( _ ) in front of the name; a corner or waypoint name that starts with an underscore is not displayed in the GCS. Only in editor mode it is visible. It is visible in editor mode, because if you the could not see it, it also would be not possible to edit or drag the corner or waypoint to another position.
* The color indicating the sector borders is not fixed but can be defined by oneself if wished for via the color attribute.

=== Dynamic sectors ===

With the latest version (v5.5-devel-628), it is possible to create dynamic sectors. The procedure to create the sector is the same than for the static version with an extra attribute '''type="dynamic"''':
<source lang="xml">
<sectors>
<sector name="MyBigGarden" color="red" type="dynamic">
<corner name="C1"/>
<corner name="C2"/>
<corner name="C3"/>
<corner name="C4"/>
</sector>
</sectors>
</source>

It is also recommended to avoid using hidden waypoints (no _ prefix), so you can move the corner of your sector from the GCS. The polygon is updated on the 2D map to reflect the new waypoints positions.
Beside the possibility to change the shape of the area in flight, one of the main benefit is that the algorithm behind allows concave hulls. The only restriction is that the edges of the polygon should not cross each other.

The generated function is the same than the static version and can be used the same way.

== Variables ==

'''Available since v5.9'''

It is possible to declare a list of variables that will be automatically created during the flight plan generation and available for the rest of the system from the generated flight plan header and of course inside the flight plan itself. With appropriate attributes, it is also possible to make the variables accessible from the telemetry as a [[Settings|setting]].

The following code will produce a '''float''' variable initialized to 0:
<source lang="xml">
<variables>
<variable var="my_var"/>
</variables>
</source>

The type and the initial value can be changed with the '''type''' and '''init''' attributes:
<source lang="xml">
<variables>
<variable var="my_var" init="10" type="int"/>
</variables>
</source>

To produce an automatic setting for a variable, at least '''min''', '''max''' and '''step''' attributes need to be specified:
<source lang="xml">
<variables>
<variable var="my_var" min="0." max="10." step="0.1"/>
</variables>
</source>
They will appear under the '''Flight Plan''' settings tab in the GCS. So more attributes can be specified: '''shortname''', '''unit''', '''alt_unit''', '''alt_unit_coef''', '''values'''. See [[Settings]] page for more information about these options.

== Includes ==

<tt>include</tt> is used to add some flight plan elements defined in an external procedure. It’s useful to include pre-written procedures with only few arguments and then clarify the flight plan.
Here is the structure:
<tt><include name procedure> [<arg name value />]*[<with from to />]*</include></tt>
where <tt>name</tt> attribute of the include element will be used in this flight plan to prefix the blocks of the <tt>procedure</tt>, the XML referenced file.
Named arguments may be given with their value in the <tt>arg</tt> elements. The <tt>with</tt> tag allows to link labels (e.g. attribute of a deroute instruction or of an exception) from the procedure to blocks of the main flight plan.
Then, each block of the procedure is like any block of the flight plan and is designated with a dotted identifier: block <tt>b</tt> of a procedure named <tt>p</tt> is named <tt>b.p</tt> .

Here is an example:
<source lang="xml">
<includes>
<include name="landing" procedure="landing.xml"/>
</includes>
</source>

== Blocks ==

Block elements are the main part of a flight plan: they describe each unit of the mission.
They are made of various primitives, called stages and exceptions, you can put one after the other. When a
stage (or a block) is finished, the autopilot goes to the next one. The behaviour after the last stage of the last block is undefined.

As described in the DTD, the <tt>blocks</tt> element is composed of <tt>block</tt> elements which are sequence of ''stages'':
<source lang="xml">
<!ELEMENT blocks (block+)>
<!ELEMENT block (exception|while|heading|attitude|go|xyz|set|call|circle|deroute|stay|follow|survey_rectangle|for|return|eight|oval|home|path)*>
</source>

Example:
<source lang="xml">
<block name="circlehome">
<circle radius="75" wp="HOME"/>
</block>
</source>

You can add a button in the [[GCS#Strips|strip of the aircraft]] with the attribute <tt>strip_button</tt>:
<source lang="xml">
<block name="descent" strip_button="Descent">
<circle wp="HOME" throttle="0.0" pitch="-15" vmode="throttle"/>
</block>
</source>
This button will activate the block. If the attribute <tt>group</tt> is specified, all strip buttons of the same group will be placed vertically on top of each other.

In the same way, a key shortcut can be specified:
<source lang="xml">
<block key="D" name="descent" strip_button="Descent">
<circle wp="HOME" throttle="0.0" pitch="-15" vmode="throttle"/>
</block>
</source>
Modifiers are allowed, using the syntax of [http://library.gnome.org/devel/gtk/2.15/gtk-Keyboard-Accelerators.html#gtk-accelerator-parse GTK accelerators].

An icon can be specified to display the button. The <tt>strip_button</tt> label then is a tooltip for the icon. The icon must be an image file available in the directory <tt>data/pictures/gcs_icons</tt>:
<source lang="xml"><block name="Takeoff" strip_icon="takeoff.png" strip_button="Takeoff"></source>

You can call functions before or after each execution of the block:
<source lang="xml">
<block name="circlehome" pre_call="function_to_call_before_circle()" post_call="function_to_call_after_circle()">
<circle wp="HOME"/>
</block>
</source>

==== Expressions ====

Most of the numeric attributes in stages are analyzed as C expressions. The syntax of this C expression is restricted to
* numeric constants
* some internal autopilot variables (not fully documented, see [[Flight_Plans#Internal_Variables_in_Flight_Plans|internal variables section]] below and other examples)
* Some binary operators: <, >, <=, >=, <>, ==, +, -, /, *
* Some utility functions

Some examples of usable expressions are given in the next sections.
=== Initialization Blocks ===
Most flight plans will have three blocks of flight plan initialization blocks. It is good practice to follow this example below if you first start learning to create flightplans

The first block waits until the GPS fix has been established, as shown below.
<source lang="xml">
<blocks>
<block name="Wait GPS">
<set value="1" var="kill_throttle"/>
<while cond="!GpsFixValid()"/>
</block>
</source>
The second block updates the local waypoints with respect to the UAV.
<source lang="xml">
<block name="Geo init">
<while cond="LessThan(NavBlockTime(), 10)"/>
<call fun="NavSetGroundReferenceHere()"/>
</block>
</source>
This next block prevents the UAV from starting the engine and taking off.
<source lang="xml">
<block name="Holding point">

<set value="1" var="kill_throttle"/>
<attitude roll="0" throttle="0" vmode="throttle"/>
</block>
</source>

=== Exceptions ===

The flight manager can handle exceptions. They consist in conditions checked periodically (at the same pace as the navigation control), allowing the control to jump to a given block. Here is the syntax of exceptions:
<source lang="xml"><exception cond="..." deroute="..."></source>
where <tt>cond</tt> is an expression and <tt>deroute</tt> is the name of the block we want to switch to as soon as the condition is true.

Here are some example of exceptions:
<source lang="xml">
<exception cond="10 > PowerVoltage()" deroute="go_down"/>
<exception cond="(ground_alt+10 > GetPosAlt())" deroute="go_up"/>
<exception cond="(autopilot_flight_time > 840)" deroute="quick_land"/>
</source>

Exceptions can be local to a block or global to the flight plan, in the <tt><exceptions></tt> element. In the following example, time since last reception of a message from the ground station is monitored and the navigation is switched to the <tt>Standby</tt> block if no message have been received for 22s. This exception is valid for '''all''' the blocks.
<source lang="xml">
<flight_plan ...>
<waypoints> ... </waypoints>
<exceptions>
<exception cond="datalink_time > 22" deroute="Standby"/>
</exceptions>
<blocks> ...
</source>

=== Deroute ===

The <tt>deroute</tt> is the ''goto'' directive of the flight plan; it switches the navigation to the given block:
<source lang="xml"><deroute block="landing"/></source>

Note that this primitive should not be used to execute loops which are provided by the following elements.

=== Return ===

The <tt>return</tt> is also a ''goto'' directive that brings you back to the last block (and last stage). It has no argument.
<source lang="xml"><return/></source>

=== Loops ===

Unbounded loops are written with <tt>while</tt> elements whose <tt>cond</tt> attribute is a boolean expression.
Children of <tt>while</tt> are stages:
<source lang="xml">
<while cond="TRUE">
<go wp="A"/>
<go wp="B"/>
<go wp="C"/>
<while cond="5 > stage_time"/>
</while>
</source>
In this example, we run an infinite loop, letting the aircraft try to go via waypoints <tt>A</tt>, <tt>B</tt> and <tt>C</tt> and waiting for 5 seconds before repeating.

Bounded loops are written with the <tt>for</tt> tag:
<source lang="xml">
<for var="i" from="0" to="3">
...
</for>
</source>
where the body of the loop will be run four times.

The variable of a <tt>for</tt> loop can be used inside expressions appearing as attributes of the stages:
<source lang="xml">
<for var="i" from="1" to="5">
<circle wp="HOME" radius="75" alt="ground_alt+50*$i" until="stage_time>10" />
</for>
</source>

In this example, the aircraft will circle around waypoint '''HOME''' for 10 seconds at and altitude above ground of 50m, 10 seconds at altitude 100 meter (50+50), ... until 250m (5x +50).

Note: Two bounded loops using the same control variable are not allowed in the same block.

=== Navigation modes ===

Navigation modes give the description of the desired trajectory in 3D. While the horizontal mode is specified through
''stages'', the vertical control is specified with various attributes of these stages. The current available navigation stages are
* attitude : just keep a fixed attitude;
* heading : keep a given course;
* go : go to a given waypoint;
* path : list of waypoints linked by ''go''
* circle : circle around a waypoint;
* oval : two half circles with a straight between two nav points
* eight : fly a figure of eight through a waypoint and around another
* stay : hold the position (hard to realize for a fixed-wing aircraft);
* follow : follow another aircraft;
* xyz : circle around a point moveable with the RC transmitter stick (obsolete with the datalink).

The vertical control is achieved using the <tt>vmode</tt> attribute of these stages. The possible values are
* '''alt''' (the default) : the autopilot keeps the desired altitude which is the altitude of the waypoint (if any) or the altitude specified with the <tt>alt</tt> attribute;
* '''climb''' : the autopilot keeps the desired vertical speed specified with the <tt>climb</tt> attribute (in m/s);
* '''throttle''' : the autopilots sets the desired throttle specified with the <tt>throttle</tt> attribute (between 0 and 1);
* '''glide''' : the autopilot keeps the desired slope between two waypoints

The default control is done with the throttle. However, setting the <tt>pitch</tt> attribute to '''auto''' and the <tt>throttle</tt> attribute to a constant allows a vertical control only by controlling the attitude of the A/C.
The <tt>pitch</tt> attribute also can be set to any value (in degrees) while the throttle control is in use: it usually affects the airspeed of the aircraft.

The different navigation modes are detailed in the next sections.

=== Attitude ===

Element <tt>attitude</tt> is the navigation mode which corresponds to the current lowest control loop for horizontal mode.
The autopilot then keeps a constant attitude. The <tt>roll</tt> attribute is required (in degrees, positive to put right wing low).

To fly away, at constant airspeed:
<source lang="xml"><attitude roll="0" vmode="throttle", throttle="0.5"/></source>

To fly around, holding a given altitude:
<source lang="xml"><attitude roll="30" alt="ground_alt+50"/></source>

Note that it is not a ''safe'' navigation mode since the geographic position of the plane is not controlled. However, this mode is useful to tune the roll attitude control loop.

=== Heading ===

<tt>heading</tt> primitive is relative to the second level loop for horizontal mode in the autopilot which will keep the given <tt>course</tt>, a required attribute (in degrees, clockwise, north=0, east=90).

One example to takeoff, following the QFU, 80% throttle, nose up (15 degrees) until height of 30m is reached:
<source lang="xml"><heading course="QFU" vmode="throttle" throttle="0.8" pitch="15" until="(GetPosAlt() > ground_alt+30)"/></source>

=== Go ===

The <tt>go</tt> primitive is probably the most useful one. Basically, the autopilot will try to join a given waypoint (<tt>wp</tt>, the only required attribute). So the simplest thing you can ask for is
<source lang="xml"><go wp="HOME"/></source>
which will set the '''HOME''' waypoint as the desired target position. Note than since <tt>vmode="alt"</tt> is the default, the altitude of the target waypoint is also taken into account. The navigation will switch to the next stage as soon as the target is reached.

It is usually not a good idea to try to join a waypoint without asking for a precise trajectory, i.e. a given line.
Setting the <tt>hmode</tt> attribute to '''route''', the navigation will go over a segment joining two waypoints:
<source lang="xml"><go from="wp1" wp="wp2" hmode="route"/></source>

The target altitude is the altitude of the target waypoint; it can also be set with the <tt>alt</tt> attribute. The following example keeps an altitude with fixed throttle:
<source lang="xml"><go from="wp2" wp="wp3" hmode="route" pitch="auto" throttle="0.75" alt="ground_alt+100"/></source>

The attributes related to the vertical control can also be set to replace the default altitude mode:
<source lang="xml"><go from="wp1" wp="wp2" hmode="route" vmode="climb" climb="1.5"/></source>

Finally, the <tt>approaching_time</tt> (in seconds) attribute helps to decide when the target is ''reached''. It can be set
to '''0''' to go over the target waypoint (default value is the '''CARROT''' time, set in the airframe configuration file).
<source lang="xml"><go from="wp1" wp="wp2" hmode="route" approaching_time="1"/></source>

=== Path ===

The <tt>path</tt> primitive is just a shorthand expression for a set of <tt>go</tt> primitives. A list of waypoints defined with the <tt>wpts</tt> attribute is pre-processed into a set of <tt>go</tt> primitives with the <tt>hmode</tt> attribute. For example:
<source lang="xml"><path wpts="wp1, wp2, wp3"/></source>

Other attributes are optional:
<source lang="xml"><path wpts="wp3, wp1, wp2" approaching_time="1" pitch="auto" throttle="0.5"/></source>

=== Circle ===

The <tt>circle</tt> primitive is the second main navigation mode: the trajectory is defined as a circle around a given waypoint with a given radius:
<source lang="xml"><circle wp="HOME" radius="75"/></source>
A positive radius makes the UAS move clockwise, a negative counter-clockwise.

The <tt>until</tt> attribute may be used to control the end of the stage. The following example defines an ascending trajectory at constant throttle, nose up (15 degrees), over growing circles, until the battery level is low:
<source lang="xml"><circle wp="wp1" radius="50+(GetPosAlt()-ground_alt)/2" vmode="throttle" throttle="0.75" pitch="15" until="10>PowerVoltage()"/></source>

=== Oval ===
The oval consists of two half circles that are connected with two straight lines. This flight path is usefull when a IMU is used because the straights allow for level flight.
<source lang="xml"> <oval p1="1" p2="2" radius="nav_radius"/> </source>

=== Eight ===
'''Works only for Fixed-wing!''' Fly a figure of eight that consists of two straight legs that pass though the center and the center of the half circle at the end of the two legs is in the turn around waypoint. The altitude of the center waypoint is used for the entire figure. The turn around waypoint is moved to match radius given.
<source lang="xml"> <eight center="1" radius="nav_radius" turn_around="2"/> </source>

=== Survey rectangle ===
Fly a survey rectangle defined by two waypoints. The distance between the legs of the grid (in meter) and the orientation of the grid (NS or WE) can be set by the operator. The plane will turn outside of the border of the rectangle before starting a new leg.
<source lang="xml"> <survey_rectangle wp1="1" wp2="2" grid="200" orientation="NS"/> </source>

=== Follow ===

The <tt>follow</tt> is a special primitive which makes the UAS follow another UAS (real or simulated, named with its <tt>ac_id</tt>) at a given <tt>distance</tt> (in meters) behind and at a given <tt>height</tt> (in meters) above.

In this example, the autopilot will try to follow A/C number '''4''', staying '''50'''m behind and '''20'''m above.
<source lang="xml"><follow ac_id="4" distance="50" height="20"/></source>

=== Stay ===

The <tt>stay</tt> Here the UAS with try to stay at the waypoint as best as it can. For an aircraft capable of hovering it will just hang above the waypoint. For a fixedwing type UAV,<tt>stay</tt> will mean the aircraft will constantly fly straight through the waypoint in a flower like pattern with the smallest turn radius it can manage.
<source lang="xml"><stay wp="HOME" alt="10"/></source>

=== XYZ ===

<tt>xyz</tt> is a special mode where the UAS circles around a user moveable waypoint. This waypoint is moved with the RC sticks:
* YAW channel controls the point over the west-east axis;
* PITCH channel controls the point over the south-north axis;
* ROLL channel controls the altitude.

Example (default radius is '''100'''):
<source lang="xml"><xyz radius="40"/></source>

=== Set ===

The <tt>set</tt> element is a dangerous one which should be used only by expert users: it is used to directly set an internal variable of the autopilot. For example, you can change the value of the default ground altitude, a variable used by the home mode failsafe procedure (and maybe by your own flight plan):
<source lang="xml"><set var="ground_alt" value="ground_alt+50"/></source>
This directive is extremely powerful and has great potential for error - use with caution.

=== Call ===

The <tt>call</tt> allows the user to define its own navigation procedures in C. The <tt>value</tt> must be a call to a boolean function which must return TRUE as long as the stage is not completed (a function which should be called only once would then return immediately FALSE).
This feature is illustrated with the '''line''' pattern:
<source lang="xml">
<call fun="nav_line_setup()"/>
<call fun="nav_line_run(WP_1, WP_2, nav_radius)"/>
</source>
where <tt>nav_line_setup()</tt> returns FALSE and <tt>nav_line_run()</tt> always returns TRUE (this stage never ends). '''Note''' that a waypoints index is derived/denoted by prefixing the waypoint name with <tt>WP_</tt>(i.e.: 1 --> WP_1, 2 --> WP_2)
<br />

To call ''any'' function exactly once regardless of the return value (e.g. call a void function), add <tt>loop="FALSE"</tt>
<source lang="xml">
<call fun="viewvideo_take_shot(TRUE)" loop="FALSE"/>
</source>
or use the <tt>call_once</tt> alias:
<source lang="xml">
<call_once fun="viewvideo_take_shot(TRUE)"/>
</source>

Such extra navigation functions are usually written as a [[Modules|Module]] and the header files are included automatically.

If you want to call functions that are not part of a module, you need to include the header file which contains the function declaration:or supplementary C file which must be specified in the
<source lang="xml">
<header>
#include "path/to/header.h"
</header>
</source>
where the path is relative to the <tt>sw/airborne</tt> directory.

You can also call functions before or after each execution of the block (this means continuously on each iteration of each stage of the block, not just when entering o exiting the block).
<source lang="xml">
<block name="circlehome" pre_call="function_to_call_before_circle()" post_call="function_to_call_after_circle()">
<circle wp="HOME"/>
</block>
</source>

=== Pre Call ===

<source lang="xml">
<block name="Standby" strip_button="Standby" strip_icon="home.png" pre_call="if(!InsideKill(GetPosX(), GetPosY())) NavKillThrottle();">
</source>

=== Post Call ===

<source lang="xml">
<block name="traj" pre_call="formation_pre_call()" post_call="formation_flight()"> 
</source>

== Procedures ==

Procedures are libraries which can be included in flight plans. They are composed of waypoints, sectors and blocks. The header of a procedure may contain some parameters which are replaced by arguments when the procedure is included.

Extract of the DTD: a procedure is a sequence of parameters, waypoints, ...:
<source lang="xml"><!ELEMENT procedure (param*,header?,waypoints?,sectors?,exceptions?,blocks?)></source>

A <tt>param</tt>eter is just a name. A parameter is optional if it is declared with a default value.
An example with a required and an optional parameter:
<source lang="xml">
<param name="alt"/>
<param name="radius" default_value="75"/>
</source>

Procedures are called with the <tt>include</tt> element in a flight plan. A procedure cannot be included twice or by another procedure. A procedure call requires:

* the name of the procedure file, the name given to this inclusion;
* values for the parameters;
* backlinks for block name exits of the procedure.

For example:
<source lang="xml"><include name="landing" procedure="landing.xml"/></source>

Here is the corresponding procedure '''landing.xml''':
<source lang="xml">
<!DOCTYPE procedure SYSTEM "flight_plan.dtd">
<procedure>
<waypoints>
<waypoint name="AF" x="177.4" y="45.1" alt="30"/>
<waypoint name="TD" x="28.8" y="57.0" alt="0"/>
<waypoint name="_BASELEG" x="168.8" y="-13.8"/>
</waypoints>
<blocks>
...
<block name="land">
<call fun="nav_compute_baseleg(WP_AF, WP_TD, WP__BASELEG, nav_radius)"/>
<circle radius="nav_radius" until="NavCircleCount() > 0.5" wp="_BASELEG"/>
<circle radius="nav_radius" until="And(NavQdrCloseTo(DegOfRad(baseleg_out_qdr)-10), 10 > fabs(GetPosAlt()- WaypointAlt(WP__BASELEG)))" wp="_BASELEG"/>
</block>
...
</blocks>
</procedure>
</source>

Note that the name of procedure '''land''' block will be renamed into '''landing.land''':
<source lang="xml"><deroute block="landing.land"/></source>
will jump to this procedure block.

Suppose you have a go-around condition in your landing procedure. You would write it
<source lang="xml"><exception cond="..." deroute="go-around"/></source>
then you must link this block exit with one of your block (e.g. <tt>Standby</tt>). So you would include the procedure as follows:
<source lang="xml">
<include name="landing" procedure="landing.xml">
<with from="go-around" to="Standby"/>
</include>
</source>

== Internal Variables in Flight Plans ==

The flight plan can use several internal variables, macros and functions coming from the rest of the system or the flight plan API itself. The following list present some of the most commonly used variables, but much more are actually available:

* '''autopilot_flight_time''': time in seconds since autopilot was booted (integer)
* '''datalink_time''': time in seconds since last connection of telemetry to ground control station (including ''subsystems/datalink/datallink.h'' in the '''header''' section is required) (integer)
* '''GetPosAlt()''': returns the current altitude above ground level in meter (float)
* '''GetPosX()''': returns x (easting) of current position relative to reference in meter (float)
* '''GetPosY()''': returns y (northing) of current position relative to reference in meter (float)
* <s>'''ground_alt''': altitude above ground level in meter (float)</s> (v5.8 and higher - use '''GetAltRef()''' instead)
* '''GetAltRef()''': returns reference altitude, usually ground_alt
* '''NavSetGroundReferenceHere()''': reset position and altitude reference point to current position
* '''NavSetAltitudeReferenceHere()''': reset altitude reference to current alt but keep previous horizontal position reference
* '''NavSetWaypointHere(_wp)''': set position of a waypoint given as argument to the current position
* '''WaypointX(_wp)''': returns x (easting) of waypoint position relative to reference in meter (float)
* '''WaypointY(_wp)''': returns y (northing) of waypoint position relative to reference in meter (float)
* '''WaypointAlt(_wp)''': returns waypoint altitude in meter (float)
* '''nav_radius''': free variable usually used to set circle radius in flight plan
* '''NavKillThrottle()''': function to switch off throttle
* '''PowerVoltage()''': returns current voltage of the battery
* all functions from the [http://docs.paparazziuav.org/latest/group__state__interface.html state interface API]
* all functions from the [http://docs.paparazziuav.org/latest/subsystems_2navigation_2waypoints_8h.html waypoint API]
* all variables declared in [[modules]] headers

== Advanced Examples ==

Parameters used in a flight plan can be computed expressions. In this example, the plane is asked to perform 5 circles at progressively increasing altitudes for exactly one minute at each altitude:
<source lang="xml">
<for var="i" from="1" to="5">
<circle wp="HOME" radius="75"
alt="ground_alt + 50*$i"
until="stage_time > 60" />
</for>
</source>

Below you find some random examples of the posibilities. This is only the tip of the iceberg, use your imagination and go wild with new creative ideas for your flightplan

=== Gains on the fly ===

It is very well possible to set specific gain for an airframe if it reaches e.g a certain block.

=== Dynacmically adjustable maximum speed ===

<source lang="xml">
<call_once fun="gh_set_max_speed(2.0)"/>
</source>

=== Immobilize Actuators ===

h_ctl setpoints variable are set by the h_ctl_attitude_loop() (from fw_h_ctl.c) loop) which can be disabled with the h_ctl_disabled flag:

<source lang="xml">
<set var="h_ctl_disabled" value="TRUE"/>
<set var="h_ctl_aileron_setpoint" value="0"/>
<set var="h_ctl_elevator_setpoint" value="MAX_PPRZ/2"/>
.... waiting for a condition ...
<set var="h_ctl_disabled" value="FALSE"/>
</source>

== Tips and Tricks ==

There are many ways to skin a cat just as there are many ways to craft your flight plan. Following the best practices tips can save you from a lot of frustration and mishap.

* Simulate your flight plan before taking it to the sky. Flight plans should always be carefully tested prior to flight, take a look at the [[Simulation|simulation]] page for details on how to simulate your plan.
* Make an subdirectory in the Flight_plan directory with your own name and add your flight plans there. Make sure that the location of the DTD is correct, e.g by using relative directory double dots as in <tt><!DOCTYPE flight_plan SYSTEM "../flight_plan.dtd"></tt>

* Take a good look at other flight plans included with Paparazzi. To learn from example flight plans please visit the [[Flight_Plan_Examples|flight plan examples]] page
* There are several option to build failsafe features into you flightplan, [[Failsafe|for some examples visit the Failsafe page]].
* Some flight plan examples define waypoint locations using relative coordinates. These are relative positions from the fixed lat and lon in the header of the flight plan. When simulating your flight plan the aircraft always use the lat/lon as defined in the flight plan since a regular simulation has no notion of you current position of you local PC where you simulate on. This is something to keep in mind if you test your flight plan in real flights.

=== V5.8+ ===
* If you don't like the '''No SRTM data found to check altitude''' warning, either in your flight plan editor or in GCS itself click on the '''Nav->display SRTM'''. It will ask you whether you want to download SRTM data. Say yes, and it will save the data in ''data/srtm'' directory, so you don't get the warning any more and check the ground altitude even without GPS.

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

Main Page

2016-06-21T19:21:32Z

Flixr: v5.8.2 maintenance release

__NOTOC__
__NOEDITSECTION__

[[Image:Welcome to paparazziuav.png|600px|center]]

<center>{{Hotbar}}</center>

'''[http://paparazziuav.org Paparazzi UAV]''' (Unmanned Aerial Vehicle) is an open-source drone hardware and software project encompassing autopilot systems and ground station software for multicopters/multirotors, fixed-wing, helicopters and hybrid aircraft that was founded in 2003. [http://paparazziuav.org Paparazzi UAV] was designed with autonomous flight as the primary focus and manual flying as the secondary. From the beginning it was designed with portability in mind and the ability to control multiple aircraft within the same system. Paparazzi features a dynamic flight plan system that is defined by mission states and using way points as “variables”. This makes it easy to create very complex fully automated missions without the operators intervention. For more project information, [[General|see here]].

{{P Header Box|color=#D51D00|size=100%|<center>Legal Disclaimer</center>}}

The Paparazzi software source and hardware design is distributed without any guarantee. Before flying, please refer to your country's national aviation regulation for Unmanned Aerial Systems, or the one of the country you intend to overfly.


{{P Topic Table|{{P Header Box|ico=favicon32.png|[[General]]}}
{{:General/Index}}
{{P Header Box|ico=Gear.png|[[Hardware]]}}
{{:Hardware/Index}}
{{P Header Box|ico=Code.png|[[Software]]}}
{{:Software/Index}}
{{P Header Box|ico=favicon32.png|[[Miscellaneous]]}}
{{:Miscellaneous/Index}}

|{{P Release|v5.8.2_stable|v5.8}}


{{P Header Box|ico=RSS.png|[http://blog.paparazziuav.org Paparazzi UAV Blog]}}
<rss max=10 item-max-length="1000">http://feeds.feedburner.com/PaparazziBlog</rss>


{{P Header Box|ico=Video.png|Video Collection}}

<center>{{#ev:youtubeplaylist|PLekU8nVT6qLm3oOudER7WVuj2plH_aU4u}}</center>

}}

Flight Plans

2016-06-19T20:08:13Z

Flixr: /* Dynacmically adjustable maximum speed */

A '''flight plan''' is a XML document which one can create and store aboard an autopilot. The flight plan will describe how you want your aircraft to travel if released into into the wild blue yonder.

== DTD and Structure ==

The formal description of the flight plan file is given in the [http://en.wikipedia.org/wiki/Document_Type_Definition '''DTD'''] (located in <tt>conf/flight_plans/flight_plan.dtd</tt>). This
DTD must be referenced in the header of your flight plan XML document using the following line:<br>

<source lang="xml"><!DOCTYPE flight_plan SYSTEM "flight_plan.dtd"></source>

The flight plans are stored in the <tt>conf/flight_plans</tt> directory. The [[Flight_Plan_Editor|flight plan editor]] can be used to create basic flight plans via the GUI.

Extract from the [http://en.wikipedia.org/wiki/Document_Type_Definition DTD]:
<tt><!ELEMENT flight_plan (header?,waypoints,sectors?,variables?,includes?,exceptions?,blocks)></tt>

'''A flight plan is composed of two mandatory elements: [[#waypoints|waypoints]] and [[#blocks|blocks]]'''

The root <tt>flight_plan</tt> element is specified with several attributes:
<tt>'''<flight_plan name lat0 lon0 ground_alt security_height home_mode_height qfu alt max_dist_from_home>'''</tt>
; <tt>'''name'''</tt>: The name of the mission (a text string)
; <tt>'''lat0, lon0'''</tt>: Defines the latitude and longitude coordinates of the reference point {0,0} in WGS84 degree coordinates
; <tt>'''ground_alt'''</tt>: The ground altitude (in meters), Above Sea Level where you are flying. It defines the <tt>GROUND_ALT</tt> constant value which can be used in combination with a waypoint <height> parameter to define a waypoint height
; <tt>'''security_height'''</tt>: The height (over <tt>'''ground_alt'''</tt>) used by the circle-home failsafe procedure and in other flight procedures such as formation flight and anti-collision avoidance. Warnings are produced if you place a waypoint lower than <tt>'''security_height'''</tt> (usually the case for the landing point)
; <tt>'''home_mode_height'''</tt> (optional): This optional attribute available since v4.2 allows to override <tt>'''security_height'''</tt> as failsafe height in home mode. If <tt>'''home_mode_height'''</tt> Is set lower than <tt>'''security_height'''</tt>, the later is used. This attribute is useful if you need to return home at a high altitude rather than a low altitude.
; <tt>'''qfu'''</tt> (optional): defines the global constant <tt>QFU</tt>. It usually is the magnetic heading in degrees (north=0, east=90) of the runway, the opposite of wind direction. This constant may be used in the mission description. It is also used by the simulator as the original course of the aircraft. So if you want to take off and climb to the West you would use qfu=270.
; <tt>'''alt'''</tt>: The default altitude of waypoints ([[Altitude_definitions|Above Sea Level]]). So if your ground altitude is 400 then alt needs to be a value greater than ground altitude and above any obstructions in the flight plan.
; <tt>'''max_dist_from_home'''</tt>: A radius representing the maximum allowed distance (in meters) from the HOME waypoint. Exceeding this value (ie flying outside the circle with this radius) will trigger an exception. It is up to you to define the block to be executed (ie what to do) for the exception.

''Here is an '''example''' of such a line in the top of a flight plan:''

<source lang="xml">
<flight_plan alt="250" ground_alt="185" lat0="43.46223" lon0="1.27289" name="Example Muret" max_dist_from_home="300" qfu="270" security_height="25" >
</source>

Note that a flight plan could also contain optional <tt>include</tt>'s and <tt>exceptions</tt> cases.

In English the above flight plan says the name is Example Muret. The reference coordinates for the 0,0 point is: 43.46223 (lat) and 1.27289 (long). The flying site 0,0 location is 185m above sea level. The security height is 25m above 0,0 point or 210m above sea level. The default (ie if not defined in a waypoint this alt is used) altitude is 250m (above sea level). The home mode block altitude is defined to be 150m above sea level. Also, for security, a circle is defined with a radius that's 300m from 0,0 position. This is the max_dist_from_home value. Fly 301m from 0,0 and an exception is triggered. A useful block is to trigger/go to the home mode block and return to home when the aircraft flies outside the safety circle. Example flight plans are helpful for study before you build your own from scratch.

== Waypoints ==

The waypoints are the geographic locations used to specify the trajectories. A waypoint is specified by it's name and coordinates:
<tt>''' <waypoint name wpx wpy [alt] [height]/> '''</tt>
where wpx and wpy are real positional coordinates ( <tt>'''lat/lon'''</tt> ) '''or''' UTM coordinates ( <tt>'''utm_x0/utm_y0'''</tt> ) '''or''' relative coordinates ( <tt>'''x/y'''</tt> ) in meters from your reference point {0,0} . <tt>alt</tt> is an optional parameter and can be used to assign an altitude to a particular waypoint that is different from the globally defined <tt>alt</tt> parameter of the flightplan. The <tt>height</tt> attribute can be used to set the waypoint height relative to the [[Altitude_definitions|ground altitude]] (<tt>ground_alt</tt>) of the flight plan for this waypoint.

An example:
<source lang="xml">
<waypoints>
<waypoint name="HOME" x="0.0" y="30.0"/>
<waypoint name="BRIDGEOVERRIVER" x="-100.0" y="60.0" alt="270."/>
<waypoint name="MyBarn" x="-130.0" y="217.5" alt="3000."/>
<waypoint name="3" x="-30.0" y="50" height="50."/>
<waypoint name="4" x="-30.0" y="50." alt="ground_alt + 50"/>
<waypoint name="_MYHELPERSPOT" x="-30.0" y="60" height="50."/>
<waypoint name="_MYOTHERHELPERSPOT" x="-70.0" y="90" height="70."/>
<waypoint name="TOWER" lat="48.858249" lon="2.294494" height="324."/>
<waypoint name="MountainCAFE" utm_x0="360284.8" utm_y0="4813595.5" alt="1965."/>
</waypoints>
</source>

'''Tips'''
* Waypoints are easily adjusted with the [[Flight_Plan_Editor|flight plan editor]].
* If a waypoint name starts with an underscore ( _ ), the waypoint is '''not displayed''' in the GCS, except in editor mode.
* The maximum number of waypoints is 254.
* A waypoint named <tt>HOME</tt> is required if the failsafe HOME mode procedure is used.
* A waypoints index/reference pointer is derived by prefixing the waypoint name with "WP_". Useful when a [[#Call |call function]] uses the waypoints reference index vs. it's name.

== Sectors ==

=== Static sectors (default) ===

Flat ''Sectors'' can be described as an area defined by list of waypoint corners. Such an area will be displayed in the Ground Control Station (GCS) by colored lines connecting the cornerpoints.
A function is generated to check if a point, usually the aircraft itself, is ''inside'' this sector. Currently, this feature requires that the polygon is <b>convex</b> and described in a <b>clockwise</b> order. For a sector named <tt>MyBigGarden</tt> the generated function for the example here would be <tt>bool_t InsideMyBigGarden(float x, float y);</tt> where <tt>x</tt> and <tt>y</tt> are east and north coordinated, in meters, relative to the geographic reference of the flight plan. If the flight plan is dynamically relocated, such a sector will be relocated but the display is currently not updated on the GCS. It would be great if one would help improving that part of the source code. Note that sector names are not allowed to contain spaces.

For example, with the following element in a flight plan.
<source lang="xml">
<sectors>
<sector name="MyBigGarden" color="red">
<corner name="_1"/>
<corner name="_2"/>
<corner name="_3"/>
<corner name="_4"/>
</sector>
</sectors>
</source>

It is then possible to add an exception clause to your flightplan. For example if the aircraft for some reason flies outside this, defined by us, sector the airframe will fly to a standby waypoint. The exclamation mark (!) means the boolean operator <tt>NOT</tt> in this example. In regular language one would describe "If my airframe is NOT inside the MyBigGarden sector anymore then deroute it to the standby waypoint. In Flightplan "Speak" this is written like:
<source lang="xml">
<exception cond="! InsideMyBigGarden(GetPosX(), GetPosY())" deroute="standby"/>
</source>

NOTE: editing of the waypoints of the sector during the flight will not dynamically update the inside function. It will always check if the position is inside the original sector.

'''Tips'''
* A nice option in the corner notation is that one can add an underscore ( _ ) in front of the name; a corner or waypoint name that starts with an underscore is not displayed in the GCS. Only in editor mode it is visible. It is visible in editor mode, because if you the could not see it, it also would be not possible to edit or drag the corner or waypoint to another position.
* The color indicating the sector borders is not fixed but can be defined by oneself if wished for via the color attribute.

=== Dynamic sectors ===

With the latest version (v5.5-devel-628), it is possible to create dynamic sectors. The procedure to create the sector is the same than for the static version with an extra attribute '''type="dynamic"''':
<source lang="xml">
<sectors>
<sector name="MyBigGarden" color="red" type="dynamic">
<corner name="C1"/>
<corner name="C2"/>
<corner name="C3"/>
<corner name="C4"/>
</sector>
</sectors>
</source>

It is also recommended to avoid using hidden waypoints (no _ prefix), so you can move the corner of your sector from the GCS. The polygon is updated on the 2D map to reflect the new waypoints positions.
Beside the possibility to change the shape of the area in flight, one of the main benefit is that the algorithm behind allows concave hulls. The only restriction is that the edges of the polygon should not cross each other.

The generated function is the same than the static version and can be used the same way.

== Variables ==

'''Available since v5.9'''

It is possible to declare a list of variables that will be automatically created during the flight plan generation and available for the rest of the system from the generated flight plan header and of course inside the flight plan itself. With appropriate attributes, it is also possible to make the variables accessible from the telemetry as a [[Settings|setting]].

The following code will produce a '''float''' variable initialized to 0:
<source lang="xml">
<variables>
<variable var="my_var"/>
</variables>
</source>

The type and the initial value can be changed with the '''type''' and '''init''' attributes:
<source lang="xml">
<variables>
<variable var="my_var" init="10" type="int"/>
</variables>
</source>

To produce an automatic setting for a variable, at least '''min''', '''max''' and '''step''' attributes need to be specified:
<source lang="xml">
<variables>
<variable var="my_var" min="0." max="10." step="0.1"/>
</variables>
</source>
They will appear under the '''Flight Plan''' settings tab in the GCS. So more attributes can be specified: '''shortname''', '''unit''', '''alt_unit''', '''alt_unit_coef''', '''values'''. See [[Settings]] page for more information about these options.

== Includes ==

<tt>include</tt> is used to add some flight plan elements defined in an external procedure. It’s useful to include pre-written procedures with only few arguments and then clarify the flight plan.
Here is the structure:
<tt><include name procedure> [<arg name value />]*[<with from to />]*</include></tt>
where <tt>name</tt> attribute of the include element will be used in this flight plan to prefix the blocks of the <tt>procedure</tt>, the XML referenced file.
Named arguments may be given with their value in the <tt>arg</tt> elements. The <tt>with</tt> tag allows to link labels (e.g. attribute of a deroute instruction or of an exception) from the procedure to blocks of the main flight plan.
Then, each block of the procedure is like any block of the flight plan and is designated with a dotted identifier: block <tt>b</tt> of a procedure named <tt>p</tt> is named <tt>b.p</tt> .

Here is an example:
<source lang="xml">
<includes>
<include name="landing" procedure="landing.xml"/>
</includes>
</source>

== Blocks ==

Block elements are the main part of a flight plan: they describe each unit of the mission.
They are made of various primitives, called stages and exceptions, you can put one after the other. When a
stage (or a block) is finished, the autopilot goes to the next one. The behaviour after the last stage of the last block is undefined.

As described in the DTD, the <tt>blocks</tt> element is composed of <tt>block</tt> elements which are sequence of ''stages'':
<source lang="xml">
<!ELEMENT blocks (block+)>
<!ELEMENT block (exception|while|heading|attitude|go|xyz|set|call|circle|deroute|stay|follow|survey_rectangle|for|return|eight|oval|home|path)*>
</source>

Example:
<source lang="xml">
<block name="circlehome">
<circle radius="75" wp="HOME"/>
</block>
</source>

You can add a button in the [[GCS#Strips|strip of the aircraft]] with the attribute <tt>strip_button</tt>:
<source lang="xml">
<block name="descent" strip_button="Descent">
<circle wp="HOME" throttle="0.0" pitch="-15" vmode="throttle"/>
</block>
</source>
This button will activate the block. If the attribute <tt>group</tt> is specified, all strip buttons of the same group will be placed vertically on top of each other.

In the same way, a key shortcut can be specified:
<source lang="xml">
<block key="D" name="descent" strip_button="Descent">
<circle wp="HOME" throttle="0.0" pitch="-15" vmode="throttle"/>
</block>
</source>
Modifiers are allowed, using the syntax of [http://library.gnome.org/devel/gtk/2.15/gtk-Keyboard-Accelerators.html#gtk-accelerator-parse GTK accelerators].

An icon can be specified to display the button. The <tt>strip_button</tt> label then is a tooltip for the icon. The icon must be an image file available in the directory <tt>data/pictures/gcs_icons</tt>:
<source lang="xml"><block name="Takeoff" strip_icon="takeoff.png" strip_button="Takeoff"></source>

You can call functions before or after each execution of the block:
<source lang="xml">
<block name="circlehome" pre_call="function_to_call_before_circle()" post_call="function_to_call_after_circle()">
<circle wp="HOME"/>
</block>
</source>

==== Expressions ====

Most of the numeric attributes in stages are analyzed as C expressions. The syntax of this C expression is restricted to
* numeric constants
* some internal autopilot variables (not fully documented, see [[Flight_Plans#Internal_Variables_in_Flight_Plans|internal variables section]] below and other examples)
* Some binary operators: <, >, <=, >=, <>, ==, +, -, /, *
* Some utility functions

Some examples of usable expressions are given in the next sections.
=== Initialization Blocks ===
Most flight plans will have three blocks of flight plan initialization blocks. It is good practice to follow this example below if you first start learning to create flightplans

The first block waits until the GPS fix has been established, as shown below.
<source lang="xml">
<blocks>
<block name="Wait GPS">
<set value="1" var="kill_throttle"/>
<while cond="!GpsFixValid()"/>
</block>
</source>
The second block updates the local waypoints with respect to the UAV.
<source lang="xml">
<block name="Geo init">
<while cond="LessThan(NavBlockTime(), 10)"/>
<call fun="NavSetGroundReferenceHere()"/>
</block>
</source>
This next block prevents the UAV from starting the engine and taking off.
<source lang="xml">
<block name="Holding point">

<set value="1" var="kill_throttle"/>
<attitude roll="0" throttle="0" vmode="throttle"/>
</block>
</source>

=== Exceptions ===

The flight manager can handle exceptions. They consist in conditions checked periodically (at the same pace as the navigation control), allowing the control to jump to a given block. Here is the syntax of exceptions:
<source lang="xml"><exception cond="..." deroute="..."></source>
where <tt>cond</tt> is an expression and <tt>deroute</tt> is the name of the block we want to switch to as soon as the condition is true.

Here are some example of exceptions:
<source lang="xml">
<exception cond="10 > PowerVoltage()" deroute="go_down"/>
<exception cond="(ground_alt+10 > GetPosAlt())" deroute="go_up"/>
<exception cond="(autopilot_flight_time > 840)" deroute="quick_land"/>
</source>

Exceptions can be local to a block or global to the flight plan, in the <tt><exceptions></tt> element. In the following example, time since last reception of a message from the ground station is monitored and the navigation is switched to the <tt>Standby</tt> block if no message have been received for 22s. This exception is valid for '''all''' the blocks.
<source lang="xml">
<flight_plan ...>
<waypoints> ... </waypoints>
<exceptions>
<exception cond="datalink_time > 22" deroute="Standby"/>
</exceptions>
<blocks> ...
</source>

=== Deroute ===

The <tt>deroute</tt> is the ''goto'' directive of the flight plan; it switches the navigation to the given block:
<source lang="xml"><deroute block="landing"/></source>

Note that this primitive should not be used to execute loops which are provided by the following elements.

=== Return ===

The <tt>return</tt> is also a ''goto'' directive that brings you back to the last block (and last stage). It has no argument.
<source lang="xml"><return/></source>

=== Loops ===

Unbounded loops are written with <tt>while</tt> elements whose <tt>cond</tt> attribute is a boolean expression.
Children of <tt>while</tt> are stages:
<source lang="xml">
<while cond="TRUE">
<go wp="A"/>
<go wp="B"/>
<go wp="C"/>
<while cond="5 > stage_time"/>
</while>
</source>
In this example, we run an infinite loop, letting the aircraft try to go via waypoints <tt>A</tt>, <tt>B</tt> and <tt>C</tt> and waiting for 5 seconds before repeating.

Bounded loops are written with the <tt>for</tt> tag:
<source lang="xml">
<for var="i" from="0" to="3">
...
</for>
</source>
where the body of the loop will be run four times.

The variable of a <tt>for</tt> loop can be used inside expressions appearing as attributes of the stages:
<source lang="xml">
<for var="i" from="1" to="5">
<circle wp="HOME" radius="75" alt="ground_alt+50*$i" until="stage_time>10" />
</for>
</source>

In this example, the aircraft will circle around waypoint '''HOME''' for 10 seconds at and altitude above ground of 50m, 10 seconds at altitude 100 meter (50+50), ... until 250m (5x +50).

Note: Two bounded loops using the same control variable are not allowed in the same block.

=== Navigation modes ===

Navigation modes give the description of the desired trajectory in 3D. While the horizontal mode is specified through
''stages'', the vertical control is specified with various attributes of these stages. The current available navigation stages are
* attitude : just keep a fixed attitude;
* heading : keep a given course;
* go : go to a given waypoint;
* path : list of waypoints linked by ''go''
* circle : circle around a waypoint;
* oval : two half circles with a straight between two nav points
* eight : fly a figure of eight through a waypoint and around another
* stay : hold the position (hard to realize for a fixed-wing aircraft);
* follow : follow another aircraft;
* xyz : circle around a point moveable with the RC transmitter stick (obsolete with the datalink).

The vertical control is achieved using the <tt>vmode</tt> attribute of these stages. The possible values are
* '''alt''' (the default) : the autopilot keeps the desired altitude which is the altitude of the waypoint (if any) or the altitude specified with the <tt>alt</tt> attribute;
* '''climb''' : the autopilot keeps the desired vertical speed specified with the <tt>climb</tt> attribute (in m/s);
* '''throttle''' : the autopilots sets the desired throttle specified with the <tt>throttle</tt> attribute (between 0 and 1);
* '''glide''' : the autopilot keeps the desired slope between two waypoints

The default control is done with the throttle. However, setting the <tt>pitch</tt> attribute to '''auto''' and the <tt>throttle</tt> attribute to a constant allows a vertical control only by controlling the attitude of the A/C.
The <tt>pitch</tt> attribute also can be set to any value (in degrees) while the throttle control is in use: it usually affects the airspeed of the aircraft.

The different navigation modes are detailed in the next sections.

=== Attitude ===

Element <tt>attitude</tt> is the navigation mode which corresponds to the current lowest control loop for horizontal mode.
The autopilot then keeps a constant attitude. The <tt>roll</tt> attribute is required (in degrees, positive to put right wing low).

To fly away, at constant airspeed:
<source lang="xml"><attitude roll="0" vmode="throttle", throttle="0.5"/></source>

To fly around, holding a given altitude:
<source lang="xml"><attitude roll="30" alt="ground_alt+50"/></source>

Note that it is not a ''safe'' navigation mode since the geographic position of the plane is not controlled. However, this mode is useful to tune the roll attitude control loop.

=== Heading ===

<tt>heading</tt> primitive is relative to the second level loop for horizontal mode in the autopilot which will keep the given <tt>course</tt>, a required attribute (in degrees, clockwise, north=0, east=90).

One example to takeoff, following the QFU, 80% throttle, nose up (15 degrees) until height of 30m is reached:
<source lang="xml"><heading course="QFU" vmode="throttle" throttle="0.8" pitch="15" until="(GetPosAlt() > ground_alt+30)"/></source>

=== Go ===

The <tt>go</tt> primitive is probably the most useful one. Basically, the autopilot will try to join a given waypoint (<tt>wp</tt>, the only required attribute). So the simplest thing you can ask for is
<source lang="xml"><go wp="HOME"/></source>
which will set the '''HOME''' waypoint as the desired target position. Note than since <tt>vmode="alt"</tt> is the default, the altitude of the target waypoint is also taken into account. The navigation will switch to the next stage as soon as the target is reached.

It is usually not a good idea to try to join a waypoint without asking for a precise trajectory, i.e. a given line.
Setting the <tt>hmode</tt> attribute to '''route''', the navigation will go over a segment joining two waypoints:
<source lang="xml"><go from="wp1" wp="wp2" hmode="route"/></source>

The target altitude is the altitude of the target waypoint; it can also be set with the <tt>alt</tt> attribute. The following example keeps an altitude with fixed throttle:
<source lang="xml"><go from="wp2" wp="wp3" hmode="route" pitch="auto" throttle="0.75" alt="ground_alt+100"/></source>

The attributes related to the vertical control can also be set to replace the default altitude mode:
<source lang="xml"><go from="wp1" wp="wp2" hmode="route" vmode="climb" climb="1.5"/></source>

Finally, the <tt>approaching_time</tt> (in seconds) attribute helps to decide when the target is ''reached''. It can be set
to '''0''' to go over the target waypoint (default value is the '''CARROT''' time, set in the airframe configuration file).
<source lang="xml"><go from="wp1" wp="wp2" hmode="route" approaching_time="1"/></source>

=== Path ===

The <tt>path</tt> primitive is just a shorthand expression for a set of <tt>go</tt> primitives. A list of waypoints defined with the <tt>wpts</tt> attribute is pre-processed into a set of <tt>go</tt> primitives with the <tt>hmode</tt> attribute. For example:
<source lang="xml"><path wpts="wp1, wp2, wp3"/></source>

Other attributes are optional:
<source lang="xml"><path wpts="wp3, wp1, wp2" approaching_time="1" pitch="auto" throttle="0.5"/></source>

=== Circle ===

The <tt>circle</tt> primitive is the second main navigation mode: the trajectory is defined as a circle around a given waypoint with a given radius:
<source lang="xml"><circle wp="HOME" radius="75"/></source>
A positive radius makes the UAS move clockwise, a negative counter-clockwise.

The <tt>until</tt> attribute may be used to control the end of the stage. The following example defines an ascending trajectory at constant throttle, nose up (15 degrees), over growing circles, until the battery level is low:
<source lang="xml"><circle wp="wp1" radius="50+(GetPosAlt()-ground_alt)/2" vmode="throttle" throttle="0.75" pitch="15" until="10>PowerVoltage()"/></source>

=== Oval ===
The oval consists of two half circles that are connected with two straight lines. This flight path is usefull when a IMU is used because the straights allow for level flight.
<source lang="xml"> <oval p1="1" p2="2" radius="nav_radius"/> </source>

=== Eight ===
'''Works only for Fixed-wing!''' Fly a figure of eight that consists of two straight legs that pass though the center and the center of the half circle at the end of the two legs is in the turn around waypoint. The altitude of the center waypoint is used for the entire figure. The turn around waypoint is moved to match radius given.
<source lang="xml"> <eight center="1" radius="nav_radius" turn_around="2"/> </source>

=== Survey rectangle ===
Fly a survey rectangle defined by two waypoints. The distance between the legs of the grid (in meter) and the orientation of the grid (NS or WE) can be set by the operator. The plane will turn outside of the border of the rectangle before starting a new leg.
<source lang="xml"> <survey_rectangle wp1="1" wp2="2" grid="200" orientation="NS"/> </source>

=== Follow ===

The <tt>follow</tt> is a special primitive which makes the UAS follow another UAS (real or simulated, named with its <tt>ac_id</tt>) at a given <tt>distance</tt> (in meters) behind and at a given <tt>height</tt> (in meters) above.

In this example, the autopilot will try to follow A/C number '''4''', staying '''50'''m behind and '''20'''m above.
<source lang="xml"><follow ac_id="4" distance="50" height="20"/></source>

=== Stay ===

The <tt>stay</tt> Here the UAS with try to stay at the waypoint as best as it can. For an aircraft capable of hovering it will just hang above the waypoint. For a fixedwing type UAV,<tt>stay</tt> will mean the aircraft will constantly fly straight through the waypoint in a flower like pattern with the smallest turn radius it can manage.
<source lang="xml"><stay wp="HOME" alt="10"/></source>

=== XYZ ===

<tt>xyz</tt> is a special mode where the UAS circles around a user moveable waypoint. This waypoint is moved with the RC sticks:
* YAW channel controls the point over the west-east axis;
* PITCH channel controls the point over the south-north axis;
* ROLL channel controls the altitude.

Example (default radius is '''100'''):
<source lang="xml"><xyz radius="40"/></source>

=== Set ===

The <tt>set</tt> element is a dangerous one which should be used only by expert users: it is used to directly set an internal variable of the autopilot. For example, you can change the value of the default ground altitude, a variable used by the home mode failsafe procedure (and maybe by your own flight plan):
<source lang="xml"><set var="ground_alt" value="ground_alt+50"/></source>
This directive is extremely powerful and has great potential for error - use with caution.

=== Call ===

The <tt>call</tt> allows the user to define its own navigation procedures in C. The <tt>value</tt> must be a call to a boolean function which must return TRUE as long as the stage is not completed (a function which should be called only once would then return immediately FALSE).
This feature is illustrated with the '''line''' pattern:
<source lang="xml">
<call fun="nav_line_setup()"/>
<call fun="nav_line_run(WP_1, WP_2, nav_radius)"/>
</source>
where <tt>nav_line_setup()</tt> returns FALSE and <tt>nav_line_run()</tt> always returns TRUE (this stage never ends). '''Note''' that a waypoints index is derived/denoted by prefixing the waypoint name with <tt>WP_</tt>(i.e.: 1 --> WP_1, 2 --> WP_2)
<br />

To call ''any'' function exactly once regardless of the return value (e.g. call a void function), add <tt>loop="FALSE"</tt>
<source lang="xml">
<call fun="viewvideo_take_shot(TRUE)" loop="FALSE"/>
</source>

Such extra navigation functions are usually written as a [[Modules|Module]] and the header files are included automatically.

If you want to call functions that are not part of a module, you need to include the header file which contains the function declaration:or supplementary C file which must be specified in the
<source lang="xml">
<header>
#include "path/to/header.h"
</header>
</source>
where the path is relative to the <tt>sw/airborne</tt> directory.

You can also call functions before or after each execution of the block (this means continuously on each iteration of each stage of the block, not just when entering o exiting the block).
<source lang="xml">
<block name="circlehome" pre_call="function_to_call_before_circle()" post_call="function_to_call_after_circle()">
<circle wp="HOME"/>
</block>
</source>

=== Pre Call ===

<source lang="xml">
<block name="Standby" strip_button="Standby" strip_icon="home.png" pre_call="if(!InsideKill(GetPosX(), GetPosY())) NavKillThrottle();">
</source>

=== Post Call ===

<source lang="xml">
<block name="traj" pre_call="formation_pre_call()" post_call="formation_flight()"> 
</source>

== Procedures ==

Procedures are libraries which can be included in flight plans. They are composed of waypoints, sectors and blocks. The header of a procedure may contain some parameters which are replaced by arguments when the procedure is included.

Extract of the DTD: a procedure is a sequence of parameters, waypoints, ...:
<source lang="xml"><!ELEMENT procedure (param*,header?,waypoints?,sectors?,exceptions?,blocks?)></source>

A <tt>param</tt>eter is just a name. A parameter is optional if it is declared with a default value.
An example with a required and an optional parameter:
<source lang="xml">
<param name="alt"/>
<param name="radius" default_value="75"/>
</source>

Procedures are called with the <tt>include</tt> element in a flight plan. A procedure cannot be included twice or by another procedure. A procedure call requires:

* the name of the procedure file, the name given to this inclusion;
* values for the parameters;
* backlinks for block name exits of the procedure.

For example:
<source lang="xml"><include name="landing" procedure="landing.xml"/></source>

Here is the corresponding procedure '''landing.xml''':
<source lang="xml">
<!DOCTYPE procedure SYSTEM "flight_plan.dtd">
<procedure>
<waypoints>
<waypoint name="AF" x="177.4" y="45.1" alt="30"/>
<waypoint name="TD" x="28.8" y="57.0" alt="0"/>
<waypoint name="_BASELEG" x="168.8" y="-13.8"/>
</waypoints>
<blocks>
...
<block name="land">
<call fun="nav_compute_baseleg(WP_AF, WP_TD, WP__BASELEG, nav_radius)"/>
<circle radius="nav_radius" until="NavCircleCount() > 0.5" wp="_BASELEG"/>
<circle radius="nav_radius" until="And(NavQdrCloseTo(DegOfRad(baseleg_out_qdr)-10), 10 > fabs(GetPosAlt()- WaypointAlt(WP__BASELEG)))" wp="_BASELEG"/>
</block>
...
</blocks>
</procedure>
</source>

Note that the name of procedure '''land''' block will be renamed into '''landing.land''':
<source lang="xml"><deroute block="landing.land"/></source>
will jump to this procedure block.

Suppose you have a go-around condition in your landing procedure. You would write it
<source lang="xml"><exception cond="..." deroute="go-around"/></source>
then you must link this block exit with one of your block (e.g. <tt>Standby</tt>). So you would include the procedure as follows:
<source lang="xml">
<include name="landing" procedure="landing.xml">
<with from="go-around" to="Standby"/>
</include>
</source>

== Internal Variables in Flight Plans ==

The flight plan can use several internal variables, macros and functions coming from the rest of the system or the flight plan API itself. The following list present some of the most commonly used variables, but much more are actually available:

* '''autopilot_flight_time''': time in seconds since autopilot was booted (integer)
* '''datalink_time''': time in seconds since last connection of telemetry to ground control station (including ''subsystems/datalink/datallink.h'' in the '''header''' section is required) (integer)
* '''GetPosAlt()''': returns the current altitude above ground level in meter (float)
* '''GetPosX()''': returns x (easting) of current position relative to reference in meter (float)
* '''GetPosY()''': returns y (northing) of current position relative to reference in meter (float)
* <s>'''ground_alt''': altitude above ground level in meter (float)</s> (v5.8 and higher - use '''GetAltRef()''' instead)
* '''GetAltRef()''': returns reference altitude, usually ground_alt
* '''NavSetGroundReferenceHere()''': reset position and altitude reference point to current position
* '''NavSetAltitudeReferenceHere()''': reset altitude reference to current alt but keep previous horizontal position reference
* '''NavSetWaypointHere(_wp)''': set position of a waypoint given as argument to the current position
* '''WaypointX(_wp)''': returns x (easting) of waypoint position relative to reference in meter (float)
* '''WaypointY(_wp)''': returns y (northing) of waypoint position relative to reference in meter (float)
* '''WaypointAlt(_wp)''': returns waypoint altitude in meter (float)
* '''nav_radius''': free variable usually used to set circle radius in flight plan
* '''NavKillThrottle()''': function to switch off throttle
* '''PowerVoltage()''': returns current voltage of the battery
* all functions from the [http://docs.paparazziuav.org/latest/group__state__interface.html state interface API]
* all functions from the [http://docs.paparazziuav.org/latest/subsystems_2navigation_2waypoints_8h.html waypoint API]
* all variables declared in [[modules]] headers

== Advanced Examples ==

Parameters used in a flight plan can be computed expressions. In this example, the plane is asked to perform 5 circles at progressively increasing altitudes for exactly one minute at each altitude:
<source lang="xml">
<for var="i" from="1" to="5">
<circle wp="HOME" radius="75"
alt="ground_alt + 50*$i"
until="stage_time > 60" />
</for>
</source>

Below you find some random examples of the posibilities. This is only the tip of the iceberg, use your imagination and go wild with new creative ideas for your flightplan

=== Gains on the fly ===

It is very well possible to set specific gain for an airframe if it reaches e.g a certain block.

=== Dynacmically adjustable maximum speed ===

<source lang="xml">
<call_once fun="gh_set_max_speed(2.0)"/>
</source>

=== Immobilize Actuators ===

h_ctl setpoints variable are set by the h_ctl_attitude_loop() (from fw_h_ctl.c) loop) which can be disabled with the h_ctl_disabled flag:

<source lang="xml">
<set var="h_ctl_disabled" value="TRUE"/>
<set var="h_ctl_aileron_setpoint" value="0"/>
<set var="h_ctl_elevator_setpoint" value="MAX_PPRZ/2"/>
.... waiting for a condition ...
<set var="h_ctl_disabled" value="FALSE"/>
</source>

== Tips and Tricks ==

There are many ways to skin a cat just as there are many ways to craft your flight plan. Following the best practices tips can save you from a lot of frustration and mishap.

* Simulate your flight plan before taking it to the sky. Flight plans should always be carefully tested prior to flight, take a look at the [[Simulation|simulation]] page for details on how to simulate your plan.
* Make an subdirectory in the Flight_plan directory with your own name and add your flight plans there. Make sure that the location of the DTD is correct, e.g by using relative directory double dots as in <tt><!DOCTYPE flight_plan SYSTEM "../flight_plan.dtd"></tt>

* Take a good look at other flight plans included with Paparazzi. To learn from example flight plans please visit the [[Flight_Plan_Examples|flight plan examples]] page
* There are several option to build failsafe features into you flightplan, [[Failsafe|for some examples visit the Failsafe page]].
* Some flight plan examples define waypoint locations using relative coordinates. These are relative positions from the fixed lat and lon in the header of the flight plan. When simulating your flight plan the aircraft always use the lat/lon as defined in the flight plan since a regular simulation has no notion of you current position of you local PC where you simulate on. This is something to keep in mind if you test your flight plan in real flights.

=== V5.8+ ===
* If you don't like the '''No SRTM data found to check altitude''' warning, either in your flight plan editor or in GCS itself click on the '''Nav->display SRTM'''. It will ask you whether you want to download SRTM data. Say yes, and it will save the data in ''data/srtm'' directory, so you don't get the warning any more and check the ground altitude even without GPS.

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

Modules

2016-06-17T21:23:14Z

Flixr: add autoload

<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Modules</categorytree>
The modules allow to add new code in a flexible way with initialisation, periodic and event functions without modifying the main AP loop.

See [[FirmwareArchitecture]] and [[Subsystems]] for the differences of modules to subsystems.

=== Available modules ===

There is a special page listing all currently available modules to simply extend your Paparazzi autopilot board possibilities. [[Modules_list| Go here to inspect this list of modules]].

The auto-generated list and short doc for all modules in the master branch can be found at the [http://docs.paparazziuav.org/latest/onboard_modules.html onboard modules page of the doxygen docs].

=== Make your own ===

It is very possible to make your own module and to share it with the world. To make it even easier there is a helper tool called "create_module" in the main Paparazzi directory. Try it, you'll be surprised how easy it is to start your own module with the help of this tool.

=== In the airframe file ===

To add a new module for an aircraft, add a section '''modules''' in his airframe xml file :
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<modules main_freq="60">
<load name="demo_module.xml"/>
<load name="dummy.xml">
<define name="BLA" value="1"/>
<define name="BLUB"/>
<configure name="FOO" value="BAR"/>
</load>
</modules>
</source>
}}
* The main_freq parameter (in Hz) is optional. If present, it allows to specify the frequency of the main loop. Default is the ''main periodic frequency'' of the autopilot. If not needed to be specified, then the first line is just: <modules>
* The children "define" generate compilation defines for all the targets of a module and can be used with or without value. It allows to keep the module description more generic add to place the airframe dependent parameters in the airframe xml file.
* The child "configure" generates a makefile variable.

{| class="wikitable"
|-
| Since '''v5.8''' it is possible to safely replace ''subsystem'' by ''module'' in your airframe file. The roadmap of Paparazzi is to convert existing [[subsystems]] to modules.

As a result, modules can be loaded using the same format than subsystems, as children of the '''firmware''' node.
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="...">
<module name="demo_module"/>
<module name="dummy">
<define name="BLA" value="1"/>
<define name="BLUB"/>
<configure name="FOO" value="BAR"/>
</module>
<target name="..." board="...">
<module name="something" type="sometype"/>
</target>
</modules>
</source>
}}

The '''modules''' node is then only needed if a custom ''main_freq'' parameter need to be specified.
|}

=== In the module file ===

The modules description files are located in '''conf/modules'''.
{{Box Code|conf/modules/mymodule.xml|
<source lang="xml">
<!DOCTYPE module SYSTEM "module.dtd">
<module name="demo_module" dir="demo_module">
<doc>
<description>
Demo module.
More details about this module.
</description>
<configure name="SOMETHING" value="S1|S2|S3" description="The thing to use"/>
<define name="DEMO_MODULE_LED" value="LED_X" description="LED Selection"/>
</doc>
<settings>
<dl_settings name="bla">
<dl_setting min="0" max="5" step="1" var="bla_bla" shortname="bb"/>
</dl_settings>
<settings>
<depends>foo.xml,bar|baz</depends>
<conficts>boo</conflicts>
<header>
<file name="demo_module.h"/>
</header>
<init fun="init_demo()"/>
<periodic fun="periodic_1Hz_demo()" freq="1." start="start_demo()" stop="stop_demo()"/>
<periodic fun="periodic_10Hz_demo()" period="0.1" start="start_demo()" stop="stop_demo()"/>
<makefile>
<raw>
#Raw makefile section
</raw>
<define name="USE_SOMETHING" value="$(SOMETHING)"/>
<define name="DEMO_MODULE_LED" value="2"/>
<file name="demo_module.c"/>
</makefile>
</module>
</source>
}}

* module
** name : this parameter is the name of the module (mandatory)
** dir : the name of the directory in '''sw/airborne/modules''' where the source code is located (in the above example: sw/airborne/modules/demo_module), if not specified, the name of the module is used as default directory name

* doc
** description: a description of the module. The content of the first line until the dot is treated as the brief description used as the name in the [http://paparazzi.github.com/docs/latest/onboard_modules.html generated docs] (mandatory).
** define: describe the possible define flags for this module with default values and a short description (usually called from the [[Airframe_Configuration|airframe firmware section]])
** configure: describe the possible configuration options for this module with default values and a short description (usually called from the [[Airframe_Configuration|airframe firmware section]])
** section: describe the parameters that can be added as a section in the [[Airframe_Configuration|airframe configuration file]]

* settings_file (0 or more)
** file name of a settings xml file

* settings (0 or more): use the same format than systems [[Settings]]
** target: a list of targets allowed or forbidden for which embedded settings should be used
** dl_settings node with a tab name
*** dl_setting: setting description, see [[Settings]] page for details

* depends (0 or 1 'depends' node)
** comma separated list of required modules
** allows to specify OR dependencies with pipe (|) similar to Debian depends, ex: <code>foo,bar|baz</code> would make it depend on foo AND (bar OR baz)
** the elements can be a xml file (in conf/modules) or a module name (as set in the module xml 'name' node)
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px">
Prior to '''v5.3.0_testing''' we had one <tt>depend</tt> node instead of <tt>depends</tt> and <tt>conflicts</tt>:
<div class="mw-collapsible-content">'depend' node used prior to '''v5.3_devel-438-g8be5c42'''):
* depend (0 or 1 'depend' node)
** require : the list of required modules
** conflict : the list of conflicting modules
** the elements of a list are separated with a pipe (|), ex: "bla|boo"
** the elements can be a xml file (in conf/modules) or a module name (in sw/airborne/modules)
</div></div>
* conflicts (0 or 1 'conflicts' node)
** comma separated list of conflicting modules
** the elements can be a xml file (in conf/modules) or a module name (as set in the module xml 'name' node)

* autoload (0 or 1 'autoload' node)
** name : the name of the module which should also be automatically loaded

* header (0 or 1 'header' node)
** file : the name of the header to automatically include in modules.h

* init (0 or more 'init' node)
** fun : initialization function name, called once at startup

* periodic (0 or more 'periodic' node)
** fun : periodic function name (mandatory)
** period : period of the function in seconds, cannot be higher than the main frequency (if not specified, use freq parameter)
** freq : frequency of the function in Hz, cannot be higher than main frequency (used if period is not defined; if nor period nor freq are defined, the maximum frequency is used by default)
** delay : integer that can be used to impose a sequence in the periodic functions (use values between 0 and main_freq/function_freq)
** start : function to be executed before the periodic function starts
** stop : function to be executed after the periodic function stops (never called if autorun=LOCK)
** autorun : TRUE to make the periodic function starts automatically after init, FALSE to make it way for a user command to start, LOCK to make it always true (default is LOCK)

* event (0 or more 'event' node)
** fun : event function name called in each cycle of the main AP loop

* datalink (0 or more 'datalink' node)
** message : name of the datalink (uplink) message to be parsed
** fun : name of the function called when a message arrived

* makefile (0 or more 'makefile' node)
** target : a list of build targets separated with pipes (ex: <makefile target="tunnel|foo">) (default is "ap|sim|nps")
** define : each define node specifies a CFLAGS for the current targets
*** name : name of the define (ex: name="USE_MODULE_LED" -> target.CFLAGS += -DUSE_MODULE_LED) (mandatory)
*** value : the value to associate (ex: name="DEMO_MODULE_LED" value="2" -> target.CFLAGS += -DDEMO_MODULE_LED=2)
*** type : the type of define, possible values are "define" or "D", "include" or "I" (ex: name="$(ARCH_SRC)" type="include" -> target.CFLAGS += -I$(ARCH_SRC) ) (default is "define")
** file
*** name : the name of the c file (located in "sw/airborne/modules/<dir_name>") to add in the Makefile (ex: name="demo_module.c" -> target.srcs += modules/<dir_name>/demo_module.c)
*** dir : select a directory for this file only (overrides the default directory)
** file_arch (hardware related code)
*** name : the name of the c file (located in "sw/airborne/arch/<ARCH>/modules/<dir_name>") add in the Makefile (ex: name="demo_module_hw.c" -> target.srcs += arch/<ARCH>/modules/<dir_name>/demo_module_hw.c)
*** dir : select a directory for this file only (overrides the default directory)
** raw : allows to define a raw makefile section

If the compilation target is not supported by the module, it will be automatically unloaded. This may require a 'clean_ac' to work.

=== In the airborne code ===

The code corresponding to a module should be placed in the directory "sw/airborne/modules/<dir_name>" where dir_name must match the one in your conf file (attribute "dir" if specified, "name" otherwise). There are also defines generated for the frequency and period of every periodic functions of the module that can be used in the code: <PERIODIC_FUNCTION_NAME>_FREQ and <PERIODIC_FUNCTION_NAME>_PERIOD.

=== Starting / stopping a module ===

If modules are loaded with periodical functions that are not locked, a new tab will automatically appear in the setting page of the GCS that allows you to start and stop them.

An other possibility is that any file that includes the header "modules.h" can start or stop the periodic tasks.

=== Telemetry ===

In the [[telemetry]] file, if a module name is specified in a field '''message''', it will be included in the telemetry messages only if the corresponding module is loaded.

<source lang="xml">
<message name="SOME_MODULE_MSG" period="2" module="module_name"/>
</source>

This functionality was removed again in v5.9 ([https://github.com/paparazzi/paparazzi/pull/1678 #1678]), since it is not needed anymore with the <tt>register_periodic_telemetry</tt> functionality we have since v5.0.

[[Category:Developer_Documentation]] [[Category:Modules]]

Subsystem/ins

2016-06-15T07:52:36Z

Flixr: /* float_invariant */

<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages hideprefix=always>Subsystems</categorytree>
== INS subsystem ==
The INS (Inertial Navigation System) subsystem specifies which position and velocity estimation algorithm you are using.

Most of the INS filters are only providing position and speed, and they need to be used together with an [[Subsystem/ahrs|AHRS (Attitude and Heading Reference System) filter]] for attitude. Currently, only the experimental invariant filter is a full INS.

Currently possible INS subsystem types are:

{| class="wikitable" style="text-align:center" border="1"
! Type !! Point Type !! Firmwares !! Notes
|-
|'''[[Subsystem/ins#alt_float|alt_float]]''' || floating || fixedwing ||
|-
|'''[[Subsystem/ins#GPS passthrough (gps_passthrough)|gps_passthrough]]''' || || all ||
|-
|'''[[Subsystem/ins#xsens|xsens]]''' || || ||
|-
|'''[[Subsystem/ins#xsens700|xsens700]]''' || || ||
|-
|'''[[Subsystem/ins#no_type|no_type]]''' || || all ||
|-
|'''[[Subsystem/ins#Horizontal Filter Float (hff)|Horizontal Filter Float (hff)]]''' || floating || ||
|-
|'''[[Subsystem/ins#extended|extended]]''' || floating? || all ||
|-
|'''[[Subsystem/ins#vectornav|vectornav]]''' || || all ||
|-
|'''[[Subsystem/ins#float_invariant|float_invariant]]''' || floating || all ||
|}

e.g. for the extended filter:
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
<subsystem name="ins" type="extended"/>
</firmware>
</source>
}}

== Implementations ==

=== alt_float ===
Filters altitude and climb rate for fixedwings.

A 2-state Kalman filter that estimates vertical position and vertical velocity from GPS and barometric data.

When ''USE_BAROMETER'' is defined to ''TRUE'':
* GPS horizontal position and horizontal velocity is directly passed through
* GPS vertical position sets the altitude for the barometric reference pressure (QFE)
* Vertical position and velocity is a filtered based on barometric pressure with respect to the reference pressure and GPS vertical velocity readings.

When ''USE_BAROMETER'' is not defined, ''FALSE'' or ''0'':
* GPS velocity is directly passed through to the vehicle's state.
* GPS horizontal position is directly passed through.
* Altitude is filtered based on GPS height and vertical velocity data.

'''Parameters'''

USE_BAROMETER - Enables the use of barometric data

DEBUG_ALT_KALMAN - Enables debug messages from the subsystem (Default: not defined)

e.g. to use with barometer:
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing">
...
<subsystem name="ins" type="alt_float">
<define name="USE_BAROMETER" value="TRUE"/>
<subsystem>
</firmware>
</source>
}}

=== GPS passthrough (gps_passthrough) ===
"dummy" INS that does no filtering whatsoever. It directly passes GPS position and velocity through.
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
<subsystem name="ins" type="gps_passthrough"/>
</firmware>
</source>
}}

=== xsens ===
XSens Mti-G
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<subsystem name="ins" type="xsens">
<configure name="XSENS_UART_NR" value="0"/>
<configure name="XSENS_UART_BAUD" value="B115200"/>
</subsystem>
</source>
}}

=== xsens700 ===
XSens Mti-G
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<load name="ins_xsens_MTiG_fixedwing.xml">
<configure name="XSENS_UART_NR" value="0"/>
</load>
</source>
}}

=== no_type ===
Vertical filter (in float) estimating altitude, vertical velocity and accelerometer bias.

If USE_GPS, horizontal position and velocity is set directly by GPS.
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<subsystem name="ins"/>
</source>
}}

=== Horizontal Filter Float (hff) ===
simple with float vertical and horizontal filters for INS
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
<subsystem name="ins" type="hff"/>
</firmware>
</source>
}}

=== extended ===
Extended vertical filter (in float).

A 4-state Kalman filter that estimates:
* vertical position
* vertical speed
* accelerometer bias
* barometric offset
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
<subsystem name="ins" type="extended"/>
</firmware>
</source>
}}

'''Parameters'''

INS_PROPAGATE_FREQUENCY - Defines the frequency (Hz) of the propagation model (Default: PERIODIC_FREQUENCY)

=== vectornav ===
Driver for the Vectornav VN-200 INS, see also [[Sensors/imu#Vectornav_VN-200]].

=== float_invariant ===
A full INS estimating attitude, velocity, position and biases via invariant filter

[[Category:User_Documentation]] [[Category:Subsystems]]

Installation/Linux

2016-05-30T10:54:48Z

Flixr: terry.guo PPA doesn't exist anymore

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

'''<span style="color:red">This page only describes the installation of the prerequisite tools and dependencies on Debian/Ubuntu needed for Paparazzi.</span>'''

'''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 ===
'''Binary packages for Ubuntu are available for the ''i386'', ''amd64'' and ''armhf'' architectures.'''

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 ===
'''Binary packages for Debian are available for the ''i386'' and ''amd64'' architectures. ''armhf'' packages seem to be currently not supported by the OpenSUSE build service.'''

For Debian Wheezy (7.0) and Jessie (8.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_8.0/Release.key" -O- | sudo 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_7.0/ ./" | tee -a /etc/apt/sources.list
echo "deb http://download.opensuse.org/repositories/home:/flixr:/paparazzi-uav/Debian_8.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).

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

'''This is the recommended method'''

Note that there are actually two '''different''' toolchains available!
* [https://launchpad.net/gcc-arm-embedded/ ARM gcc-arm-embedded toolchain] with Debian package name ''gcc-arm-embedded''
** 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 ====

'''This is the recommended toolchain'''

On ''most'' Ubuntu versions the [https://launchpad.net/gcc-arm-embedded/ gcc-arm-embedded toolchain] can be installed as a debian package from the [https://launchpad.net/~team-gcc-arm-embedded/+archive/ubuntu/ppa ppa]:
sudo add-apt-repository ppa:team-gcc-arm-embedded/ppa
sudo apt-get update
sudo apt-get install gcc-arm-embedded

<div class="toccolours mw-collapsible mw-collapsed" style="width:800px">
Previously there was a PPA by terry.guo that contained this toolchain under the package name ''gcc-arm-none-eabi''
<div class="mw-collapsible-content">
See https://launchpad.net/gcc-arm-embedded/+announcement/13824 for details on how to switch the newer
PPA and package.
</div></div>

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

Current Debian ('''jessie''') and Ubuntu (14.04 '''trusty''' and later) releases 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

=== ARM gcc-arm-embedded tarball ===
Another way is to download and unpack the tarball and add it to your PATH:

* Download gcc-arm-none-eabi-*-*-linux.tar.bz2 from [https://launchpad.net/gcc-arm-embedded/+download External Downloads] section of ARM gcc-arm-embedded project
* Unpack it to a directory of your choice
* Add the bin folder in to your PATH

e.g.:
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
sudo 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]].

=== 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).<br>
'''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 <b>lpc21isp</b> and <b>openocd</b> 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/
sudo udevadm control --reload-rules

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.<br>
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)<br/>
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-linux-gnueabi-gcc cross-compiler not found ===

=== Ubuntu ===
apt-get install gcc-arm-linux-gnueabi

=== Debian ===
Starting with jessie, there were [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771496#41 some changes] to the way cross-compilers are set up. To make it work you will have to add armel architecture and pick up some crossbuild tools.

First edit your /etc/apt/sources.list and add the following line, to enable the emdebian repo:
deb http://emdebian.org/tools/debian/ jessie main

Run the following command in your terminal to add the keys for it
curl http://emdebian.org/tools/debian/emdebian-toolchain-archive.key | sudo apt-key add -

Then you could add armel architecture and fetch the missing cross-compiler packages
dpkg --add-architecture armel
apt-get update
apt-get install crossbuild-essential-armel

You could find out more about cross-toolchains in jessie on debian [https://wiki.debian.org/CrossToolchains wiki page].

Note that some of your repos might not mirror embedded architectures, which would give you an error when you try to update the sources. In that case you will have to specify which architecture you do want from them by editing the corresponding entry in your sources.list file, in a way described [https://wiki.debian.org/Multiarch/HOWTO here]. Like in this example with the crunchbang repo you could specify it by adding [arch=amd64,i386] to the line, so you only enable amd64 and i386 architectures:
deb [arch=amd64,i386] http://packages.crunchbang.org/waldorf waldorf main

===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)<br/>
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 occurs, maybe [http://packages.ubuntu.com/search?keywords=lib32ncurses5 lib32ncurses5] is missing. <br/>
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]]

Installation

2016-05-30T10:14:06Z

Flixr: terry.guo PPA for gcc-arm-none-eabi doesn't exist anymore, https://launchpad.net/gcc-arm-embedded/+announcement/13824

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

== Introduction ==

Paparazzi is very easily installed on any laptop or workstation running the [http://www.ubuntu.com/ Ubuntu Linux OS] or virtually any [http://www.debian.org/ Debian] based [http://en.wikipedia.org/wiki/Linux Linux] or Apple Macintosh running [http://en.wikipedia.org/wiki/OS_X Mac OS X]. There is also work being done to port Paparazzi to Windows.

The steps required to install the software needed to be able to let your UAS fly are:

# Install tools and prerequisites needed by Paparazzi.
# Download the source code from the source repository.
# Compile the Paparazzi software from sourcecode
# Complete any final configuration

== Quickstart for Ubuntu users ==
Love one-liners? To get the latest Paparazzi up and running on your '''Ubuntu 12.04 or higher OS''', make sure you have internet, then just copy and paste the text below into your terminal and press [enter] ... and wait a while...

sudo add-apt-repository -y ppa:paparazzi-uav/ppa && sudo add-apt-repository -y ppa:team-gcc-arm-embedded/ppa && sudo apt-get update && \
sudo apt-get -f -y install paparazzi-dev paparazzi-jsbsim gcc-arm-embedded && cd ~ && <nowiki>git clone --origin upstream https://github.com/paparazzi/paparazzi.git</nowiki> && \
cd ~/paparazzi && git remote update -p && \
git checkout -b v5.8 upstream/v5.8 && sudo cp conf/system/udev/rules/*.rules /etc/udev/rules.d/ && sudo udevadm control --reload-rules && \
make clean && make && ./paparazzi

[[File:Done.jpg|frameless|center|Done!]]
If all went well the Paparazzi Center should now be running... '''skip''' the rest of this page and go fly!

If you are new you'll need to do some more things before you go fly like configuring your XML definition file detailing your airframe configuration. There is help here for that: [[Airframe_Configuration]]

In case you have no autopilot hardware yet, no problem, you can get hardware [[Get_Hardware|here]] or just buy a ready to fly aircraft that can run Paparazzi Software like the Parrot Drones [http://www.parrot.com/products/bebop-drone/ Parrot Bebop] and run Paparazzi on your Parrot [[AR_Drone_2|ARDRone2]], [[Bebop|Bebop]] and Bebop2 (soon the Disco drone).

== OS Specific Instructions ==

For Linux an instructional video explaining it all in detail can be found here https://www.youtube.com/watch?v=eW0PCSjrP78

The process of installing the prerequisite tools and dependencies needed by Paparazzi is specific to the operating system you are using. For detailed installation instructions, please see the following pages:
*[[Installation/Linux|Installing prerequisites tools on Linux]]
*[[Installation/MacOSX|Installing prerequisites tools on Mac OS X]]
*[[Installation/RaspberryPi|Installing prerequisites tools on the RaspberryPi (Raspbian)]]

For more advanced installation information or developers, please see the following pages:
*[[Installation/FromScratch|Installing everything from scratch]] For non Debian based Linux distributions or if one just wants to be able to use all the latest and greatest compilers, or source code of everything to improve something. Then there is no other way than to install from scratch.
*[[Installation/Windows|Installing prerequisite tools on Windows]] Note that this is '''a work in progress, and not finished yet'''. It would be fantastic if you are interested in running Paparazzi on this OS to help out with the porting. Being able to help is one of opensource software main features. If your skill- set is not so good in this area, but you still insist using Windows OS, then it is best to install a VirtualMachine from within Windows where you run the free Ubuntu OS of choice.

=== Virtual Machines ===

It is also possible to have your Debian/Ubuntu running in a virtual machine, for instance with [http://www.virtualbox.org/ VirtualBox]. This requires minimal changes to your computer setup, as you can run the VM from all common platforms (Windows, OS X, Linux). The virtual machine image can easily be transferred between different laptops, giving greater flexibility. Unfortunately, the Open-Source Edition of VirtualBox doesn't include the necessary USB support, so you'll need to get the regular version from the website.

If you are new and this is your first time installing it is suggested you keep it simple. Use the standard Linux or OS X install. Select a system you can dedicate to the Linux installation. No VMs or dual boot configurations. The idea is do a very simple generic installation that is certain to have no issues. This reassures you that the installation process works and you can see and use a working Paparazzi install for some time before you try a more complicated install. The install is well documented and certain to succeed if followed exactly. Most issues arise when someone unfamiliar with Paparazzi or their OS tries a non-standard install that requires special steps that are not documented. Generally, commands can be copied and pasted for easy, step-by-step installation.

== Getting the Source Code ==
The Paparazzi source code is hosted on [https://github.com/paparazzi/paparazzi Github]. While you can download it as a tarball from https://github.com/paparazzi/paparazzi/releases, it is recommended to clone the repository with [[git]].

From the directory of your choice type:
git clone --origin upstream https://github.com/paparazzi/paparazzi.git
Check out the released stable version branch:
cd paparazzi
git checkout v5.8

'''If this whole "Git" thing is new to you, more options and information can be found on the [[git|Git page]].'''

== Launching the Software ==
Make sure you have installed the <tt>paparazzi-dev</tt> package as described above. Without these you will not be able to compile the sourcecode.
The first step is to compile. From the <tt>paparazzi</tt> directory (<tt>cd ~/paparazzi</tt>), run

make

You will have to run this command after each update of the source (<tt>git pull</tt> command).
Launch the software from the <tt>paparazzi</tt> directory with

./paparazzi

From the [[Paparazzi_Center|Paparazzi Center]] interface, select the ''Microjet'' aircraft, select the ''sim'' target and ''Build'' it. Then ''Execute'' the ''Simulation'' session. The procedure is detailed in the [[Simulation]] page.

=== Environment Variables ===

If ('''and only if''') you want to directly launch some Paparazzi agents (the ''Tools'' of the [[Paparazzi_Center|Paparazzi Center]]) from the command line, without using the Paparazzi Center, you must have the Paparazzi source and home environment variables set correctly in your shell. These variables can be automatically set in your shell by adding the following lines to your .bashrc file:
{{Box Code|~/.bashrc|
<source lang="bash">
export PAPARAZZI_HOME=''your paparazzi software directory''
export PAPARAZZI_SRC=''your paparazzi software directory''
</source>
}}

Verify that your variables are set correctly with the following command:
:<source lang="bash">env | grep PAPARAZZI</source>
which should return the following:
<source lang="bash">
PAPARAZZI_HOME=''your paparazzi software directory''
PAPARAZZI_SRC=''your paparazzi software directory''
</source>

If you wish to manually set the env variables (i.e. when compiling a backup copy of your code in a different folder) execute the following command from the folder you wish to set as your active paparazzi folder:
:<source lang="bash">export PAPARAZZI_HOME=`pwd`;export PAPARAZZI_SRC=`pwd`</source>

== Software Updates ==
'''We manage the software with the git version control system. Learn it! If you are new to it, see the [[Git|Git wiki page]].'''

Paparazzi is a very rapidly evolving project and as such you might want to update your software regularly. See the [[RepositoryStructure|branching model and release process page]].

Any new files you created will not be lost/overwritten when updating (like your own airframe file). Nevertheless, as with all things, backups are advised.
If you modified source code, the best way is of course to use the version control system [[Git]] to commit your changes. Otherwise at least use the brute force method and save everything in another directory.

Update your software with care and caution, and always test the functionality on the ground and in the air as some updates will affect tuning parameters. You might need to update your airframe file as well. The compiler will usually complain if there is a problem, at which point you can look at the [[Airframe_Configuration|Airframe Configuration wiki page]] again, look on the [[Contact#Mailing_List|mailing list]] or some of the most recent airframe files on git to find the proper syntax.

'''See also the [[Release Upgrades]] page for information on how to update your configuration from one release to the next.'''

=== Quick'n dirty description ===

To download and automatically merge any updated source files, run the following command from your Paparazzi directory
git pull

After any git update or source code modification the code can be recompiled from ''your paparazzi software directory'' with the following command:

make

The ''make'' command will only recompile portions of the software where changed have been detected.
If it does not behave as expected you can delete all compiled files and recompile from scratch with the following commands:

make clean
make

If you'd like to check that the code compiles all example airframes then you can run the test suite using the command

make test

For more details see the [[Builds/Tests|tests page]].

== Using the Live CD ==

There is a [[LiveCD]] available, but it dates back to 2008. It is still an easy way to get a first glimpse of Paparazzi however without installing anything.

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

Modules

2016-05-25T08:24:02Z

Flixr: /* Telemetry */

<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Modules</categorytree>
The modules allow to add new code in a flexible way with initialisation, periodic and event functions without modifying the main AP loop.

See [[FirmwareArchitecture]] and [[Subsystems]] for the differences of modules to subsystems.

=== Available modules ===

There is a special page listing all currently available modules to simply extend your Paparazzi autopilot board possibilities. [[Modules_list| Go here to inspect this list of modules]].

The auto-generated list and short doc for all modules in the master branch can be found at the [http://docs.paparazziuav.org/latest/onboard_modules.html onboard modules page of the doxygen docs].

=== Make your own ===

It is very possible to make your own module and to share it with the world. To make it even easier there is a helper tool called "create_module" in the main Paparazzi directory. Try it, you'll be surprised how easy it is to start your own module with the help of this tool.

=== In the airframe file ===

To add a new module for an aircraft, add a section '''modules''' in his airframe xml file :
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<modules main_freq="60">
<load name="demo_module.xml"/>
<load name="dummy.xml">
<define name="BLA" value="1"/>
<define name="BLUB"/>
<configure name="FOO" value="BAR"/>
</load>
</modules>
</source>
}}
* The main_freq parameter (in Hz) is optional. If present, it allows to specify the frequency of the main loop. Default is the ''main periodic frequency'' of the autopilot. If not needed to be specified, then the first line is just: <modules>
* The children "define" generate compilation defines for all the targets of a module and can be used with or without value. It allows to keep the module description more generic add to place the airframe dependent parameters in the airframe xml file.
* The child "configure" generates a makefile variable.

{| class="wikitable"
|-
| Since '''v5.8''' it is possible to safely replace ''subsystem'' by ''module'' in your airframe file. The roadmap of Paparazzi is to convert existing [[subsystems]] to modules.

As a result, modules can be loaded using the same format than subsystems, as children of the '''firmware''' node.
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="...">
<module name="demo_module"/>
<module name="dummy">
<define name="BLA" value="1"/>
<define name="BLUB"/>
<configure name="FOO" value="BAR"/>
</module>
<target name="..." board="...">
<module name="something" type="sometype"/>
</target>
</modules>
</source>
}}

The '''modules''' node is then only needed if a custom ''main_freq'' parameter need to be specified.
|}

=== In the module file ===

The modules description files are located in '''conf/modules'''.
{{Box Code|conf/modules/mymodule.xml|
<source lang="xml">
<!DOCTYPE module SYSTEM "module.dtd">
<module name="demo_module" dir="demo_module">
<doc>
<description>
Demo module.
More details about this module.
</description>
<configure name="SOMETHING" value="S1|S2|S3" description="The thing to use"/>
<define name="DEMO_MODULE_LED" value="LED_X" description="LED Selection"/>
</doc>
<settings>
<dl_settings name="bla">
<dl_setting min="0" max="5" step="1" var="bla_bla" shortname="bb"/>
</dl_settings>
<settings>
<depends>foo.xml,bar|baz</depends>
<conficts>boo</conflicts>
<header>
<file name="demo_module.h"/>
</header>
<init fun="init_demo()"/>
<periodic fun="periodic_1Hz_demo()" freq="1." start="start_demo()" stop="stop_demo()"/>
<periodic fun="periodic_10Hz_demo()" period="0.1" start="start_demo()" stop="stop_demo()"/>
<makefile>
<raw>
#Raw makefile section
</raw>
<define name="USE_SOMETHING" value="$(SOMETHING)"/>
<define name="DEMO_MODULE_LED" value="2"/>
<file name="demo_module.c"/>
</makefile>
</module>
</source>
}}

* module
** name : this parameter is the name of the module (mandatory)
** dir : the name of the directory in '''sw/airborne/modules''' where the source code is located (in the above exemple: sw/airborne/modules/demo_module), if not specified, the name of the module is used as default directory name

* doc
** description: a description of the module. The content of the first line until the dot is treated as the brief description used as the name in the [http://paparazzi.github.com/docs/latest/onboard_modules.html generated docs] (mandatory).
** define: describe the possible define flags for this module with default values and a short description (usually called from the [[Airframe_Configuration|airframe firmware section]])
** configure: describe the possible configuration options for this module with default values and a short description (usually called from the [[Airframe_Configuration|airframe firmware section]])
** section: describe the parameters that can be added as a section in the [[Airframe_Configuration|airframe configuration file]]

* settings_file (0 or more)
** file name of a settings xml file

* settings (0 or more): use the same format than systems [[Settings]]
** target: a list of targets allowed or forbidden for which embedded settings should be used
** dl_settings node with a tab name
*** dl_setting: setting description, see [[Settings]] page for details

* depends (0 or 1 'depends' node)
** comma separated list of required modules
** allows to specify OR dependencies with pipe (|) similar to Debian depends, ex: <code>foo,bar|baz</code> would make it depend on foo AND (bar OR baz)
** the elements can be a xml file (in conf/modules) or a module name (as set in the module xml 'name' node)
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px">
Prior to '''v5.3.0_testing''' we had one <tt>depend</tt> node instead of <tt>depends</tt> and <tt>conflicts</tt>:
<div class="mw-collapsible-content">'depend' node used prior to '''v5.3_devel-438-g8be5c42'''):
* depend (0 or 1 'depend' node)
** require : the list of required modules
** conflict : the list of conflicting modules
** the elements of a list are separated with a pipe (|), ex: "bla|boo"
** the elements can be a xml file (in conf/modules) or a module name (in sw/airborne/modules)
</div></div>
* conflicts (0 or 1 'conflicts' node)
** comma separated list of conflicting modules
** the elements can be a xml file (in conf/modules) or a module name (as set in the module xml 'name' node)

* header (0 or 1 'header' node)
** file : the name of the header to automatically include in modules.h

* init (0 or more 'init' node)
** fun : initialization function name, called once at startup

* periodic (0 or more 'periodic' node)
** fun : periodic function name (mandatory)
** period : period of the function in seconds, cannot be higher than the main frequency (if not specified, use freq parameter)
** freq : frequency of the function in Hz, cannot be higher than main frequency (used if period is not defined; if nor period nor freq are defined, the maximum frequency is used by default)
** delay : integer that can be used to impose a sequence in the periodic functions (use values between 0 and main_freq/function_freq)
** start : function to be executed before the periodic function starts
** stop : function to be executed after the periodic function stops (never called if autorun=LOCK)
** autorun : TRUE to make the periodic function starts automatically after init, FALSE to make it way for a user command to start, LOCK to make it always true (default is LOCK)

* event (0 or more 'event' node)
** fun : event function name called in each cycle of the main AP loop

* datalink (0 or more 'datalink' node)
** message : name of the datalink (uplink) message to be parsed
** fun : name of the function called when a message arrived

* makefile (0 or more 'makefile' node)
** target : a list of build targets separated with pipes (ex: <makefile target="tunnel|foo">) (default is "ap|sim|nps")
** define : each define node specifies a CFLAGS for the current targets
*** name : name of the define (ex: name="USE_MODULE_LED" -> target.CFLAGS += -DUSE_MODULE_LED) (mandatory)
*** value : the value to associate (ex: name="DEMO_MODULE_LED" value="2" -> target.CFLAGS += -DDEMO_MODULE_LED=2)
*** type : the type of define, possible values are "define" or "D", "include" or "I" (ex: name="$(ARCH_SRC)" type="include" -> target.CFLAGS += -I$(ARCH_SRC) ) (default is "define")
** file
*** name : the name of the c file (located in "sw/airborne/modules/<dir_name>") to add in the Makefile (ex: name="demo_module.c" -> target.srcs += modules/<dir_name>/demo_module.c)
*** dir : select a directory for this file only (overrides the default directory)
** file_arch (hardware related code)
*** name : the name of the c file (located in "sw/airborne/arch/<ARCH>/modules/<dir_name>") add in the Makefile (ex: name="demo_module_hw.c" -> target.srcs += arch/<ARCH>/modules/<dir_name>/demo_module_hw.c)
*** dir : select a directory for this file only (overrides the default directory)
** raw : allows to define a raw makefile section

If the compilation target is not supported by the module, it will be automatically unloaded. This may require a 'clean_ac' to work.

=== In the airborne code ===

The code corresponding to a module should be placed in the directory "sw/airborne/modules/<dir_name>" where dir_name must match the one in your conf file (attribute "dir" if specified, "name" otherwise). There are also defines generated for the frequency and period of every periodic functions of the module that can be used in the code: <PERIODIC_FUNCTION_NAME>_FREQ and <PERIODIC_FUNCTION_NAME>_PERIOD.

=== Starting / stopping a module ===

If modules are loaded with periodical functions that are not locked, a new tab will automatically appear in the setting page of the GCS that allows you to start and stop them.

An other possibility is that any file that includes the header "modules.h" can start or stop the periodic tasks.

=== Telemetry ===

In the [[telemetry]] file, if a module name is specified in a field '''message''', it will be included in the telemetry messages only if the corresponding module is loaded.

<source lang="xml">
<message name="SOME_MODULE_MSG" period="2" module="module_name"/>
</source>

This functionality was removed again in v5.9 ([https://github.com/paparazzi/paparazzi/pull/1678 #1678]), since it is not needed anymore with the <tt>register_periodic_telemetry</tt> functionality we have since v5.0.

[[Category:Developer_Documentation]] [[Category:Modules]]

Modems/xbee

2016-05-04T18:52:15Z

Flixr: X-CTU 6 is available natively for linux

Paparazzi supports the following modem protocols:
* Standard transparent serial (pprz protocol, AT mode) - compatible with all modems and can be used to connect the autopilot directly to a PC for testing without a modem.
* Digi (formerly Maxstream) API protocol (xbee) - compatible with all Digi modems including the 9XTend and Zigbee. This protocol enables hardware addressing through API mode, allowing multiple aircraft to be managed from a single ground modem.
<br/>

== Introduction ==

=== Installation of X-CTU ===
The simplest way to configure the XBee modems is to use the [http://www.digi.com/support/productdetail?pid=3352 X-CTU] software from Digi. It runs natively under MacOS X, Windows and Linux.
To use versions before X-CTU 6 under Linux, use Wine.

==== Installation using Wine ====
'''X-CTU versions 6 and up are available natively for Linux''', so using Wine is only needed for older versions.

Under Wine make sure you have the USB serial link connecting to XBee mapped to a com port (please consult [[Installation/Linux/udev | paparazzi linux device naming]]):

* First of all you should install wine.
* Then install winetricks (X-CTU requires MS Visual C++ Redistributable package so winetricks will make things much easier to get installed).
* Then ('''!important''') run wine configuration before doing something else, so wine can create ~/.wine
* Make symlink to your modem device.

$ sudo ln -s /dev/paparazzi/xbee ~/.wine/dosdevices/com4

* Set permissions for COM port (if you are not root):

$ sudo ls -l /dev/paparazzi/xbee
lrwxrwxrwx 1 root root 10 june 14 19:00 /dev/paparazzi/xbee -> /dev/ttyUSB0
$ sudo chown <your_user_name_here> /dev/ttyUSB0

* Run X-CTU setup and install it.
* Then run installed application. When window opens switch to "User Com Ports" tab and add com port "COM4. Note: This procedure have to be made every time you start X-CTU on Linux.
* Click "Test/Query" button. If you get some modem information (like serial, etc.) after a little time, then you have modem link established.

If X-CTU complains on com port connectivity, try adding theese strings to ~/.wine/system.reg
[hardware\\DEVICEMAP\\SERIALCOMM]
"COM1"="COM1"

If your X-CTU does not update its firmware correctely from the web, follow the steps described in the chapter "Manually Update the X-CTU firmware files" of [http://wiki.openpilot.org/display/Doc/Configure+Xbee+via+Linux this page].

=== Configuring XBee AT mode using X-CTU ===
This is the recommended way to start. With this firmware the modems basically act as a serial link replacement and don't do any mesh networking. The pprz protocol is based on this mode.
<br/>
Basic approach:
# Connect your XBee to your PC. There are several vendors of [[Modems#GCS_Adaptation|USB boards]].
# Start the X-CTU programm and go to the modem configuration.
# Click on READ
# Select the appropriate function set with AT command set.
# set PAN ID, etc... depending on which XBee you use
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly. At a higher baudrate setting, transmission can only be done in one direction.
# Then write the firmware to the module.
If X-CTU asks you to reset the XBee, you have to connect the RST pin (5) to the GND pin (10) of the XBee. You can do this manually using tweezers or a short wire.

=== Configuring XBee using a terminal emulator ===

Alternatively you can configure your XBee using a text-based modem control and terminal emulation program, such as [http://en.wikipedia.org/wiki/Minicom Minicom] for Linux or [http://freeware.the-meiers.org CoolTerm] for Linux, Mac OSX, or Windows.

The xBee modules can be set to the following baud rates:

{|border="1" cellspacing="0" style="text-align:center" cellpadding="6"
!''Baud Code''!!''Baud Rate''!!''Notes''
|-
|0||1200||
|-
|1||2400||
|-
|2||4800||
|-
|3||9600||
|-
|4||19200|| Use with fixedwing aircraft and their GCSs
|-
|5||38400||
|-
|6||57600|| Use with rotorcraft or transitioning aircraft and their GCSs
|-
|7||115200||
|}

'''Quick, I'm in a rush''':
$ sudo screen /dev/ttyUSB0 9600
+++
ATBD6<enter>
ATAP1<enter>
ATWR<enter>

'''Minicom Instructions''':
* Connect XBee to your computer
* Setup minicom (by default XBee modems come set up for 9600 baud) 8-N-1
* Type Ctrl-A A in minicom this will set it up to add linefeeds to the stream
* Type three '+' in quick succession resulting in "+++" string (you have 10s to type your next command otherwise the modem will revert back to transparent mode). Do NOT press enter.
** you get a confirmation: 'OK'
* Type "AT<enter>"
** you get a confirmation: 'OK'
* Type "ATBD<enter>"
** you get the current baudrate code: '3'
* To set another baudrate select one from the above table and type "ATBD <baud code><enter>":
* Type "ATAP 0 or 1 for API mode or not<enter>"
* To store the new baudrate in the rom type "ATWR<enter>"
* Now you can close minicom
* Reconnect modem
* Restart minicom with the new baudrate
* Test that the modem is setup correctly by typing "+++" and getting "OK" confirmation

'''CoolTerm Instructions''':
* Connect xBee to your computer
* Open CoolTerm and click 'Options.' From the 'Serial Port' tab select:
**Port: USB Serial (or as appropriate for your xBee carrier board)
**Baudrate: 9600
**Data Bits: 8
**Parity: None
**Stop Bits 1
*From the 'Terminal' tab enable Local Echo
*Click OK
*Click Connect
* Type three '+' in quick succession resulting in "+++" string (you have 10s to type your next command otherwise the modem will revert back to transparent mode). Do NOT press enter.
** you get a confirmation: 'OK'
* Type "AT<enter>"
** you get a confirmation: 'OK'
* Type "ATBD<enter>"
** you get the current baudrate code: '3'
* To set another baudrate select one from the above table and type "ATBD <baud code><enter>":
* To store the new baudrate in the rom type "ATWR<enter>"
* Now you can close CoolTerm.
* Reconnect modem
* Restart CoolTerm, change options to new baudrate, and connect
* Test that the modem is setup correctly by typing "+++" and getting "OK" confirmation

== XBee Pro ZB (AT command set) ==
This 2.4GHz modem uses ZigBee PRO Feature Set and is compatible with devices from other vendors using the ZigBee PRO Feature Set.

=== Flashing the airborne module ===
# Connect your XBee, start X-CTU, click READ
# Select the function set '''ZIGBEE END DEVICE AT''' (or ZIGBEE ROUTER AT).
# Set the PAN ID to any number, must be the same as the pan id of the coordinator (Ground Station).
# Set the Node Identifier (NI) to your aircraft name or any other appropriate name.
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.
# Then write the firmware to the module.

=== Flashing the ground station module ===
# Connect your XBee, start X-CTU, click READ
# Select the function set '''ZIGBEE COORDINATOR AT'''.
# Set the PAN ID to any number, must be the same as the pan id of the end device (aircraft).
# Set the Node Identifier (NI) to PPRZ_GROUND or any other appropriate name.
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.
# Then write the firmware to the module.

=== Pairing your Modems ===

For maximum performance you can pair the ground modem to the airborne modem. Set the "DH - Destination Address High" and "DL - Destination Address Low" to the unique serial number "SH - Serial Number High" and "SL - Serial Number Low" of the other modem. Do so both on the ground modem and on the airborne modem. Failing to properly pair your modems will likely result in poor throughput and data loss between your airframe and your ground control station. If this is the case you may see errors on the Paparazzi Center console like <tt>Failure("Pprz.values_of_payload, wrong argument: 00 08 ")</tt> or <tt>Failure("Pprz.values_of_payload, too many bytes in message PONG: 00 03 02 2a 00 00 00 00 00 00 00 00 00 00 00 00 ")</tt>. Pairing does help and the error messages will disappear.

=== Reviving a non-responding Xbee Pro ===

To bring an apparently dead XBee Pro Series 2 back to life, do the following:

#Connect the USB device that holds the XBee to your laptop/desktop (without the XBee connected).
#Open X-CTU.
#In the tab used to program the device, select the proper modem (normally you would do a READ to get the values).
#Choose the option you want to program (i.e., "END DEVICE" or "COORDINATOR") as if you were programming it.
#With the XBee not in the device, click "WRITE". It will hang, timeout, and bring up a dialog box.
#Before you click OK to the dialog box, plug in the XBee module (carefully).
#Click OK to clear the message and it should start programming automatically.

=== Other tutorials ===

[http://pixhawk.ethz.ch/tutorials/how_to_configure_xbee PixHawk: HowTo configure XBee]

[http://wiki.openpilot.org/display/Doc/Configure+Xbee+via+Linux openpilot: XBee RF modems]

== XBee Pro ZNet 2.5 (AT command set) ==
These are legacy modems and not recommended/sold by Digi anymore.
It is recommended to upgrade these to XBee Pro ZB with the [ftp://ftp1.digi.com/support/images/ZNet%202.5%20to%20ZB%20Conversion%20Kit.zip ZNet 2.5 to ZB Conversion Kit] from Digi.
<br/>
If you want to use ZNet 2.5 feature set nevertheless, here is how to configure it:

=== Flashing the airborne module ===
# Connect your XBee, start X-CTU, click READ
# Select the function set '''ZNET 2.5 ROUTER/END DEVICE AT'''.
# Set the PAN ID to any number, must be the same as the pan id of the coordinator (Ground Station).
# Set the Node Identifier (NI) to your aircraft name or any other appropriate name.
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.
# Then write the firmware to the module.

=== Flashing the ground station module ===
# Connect your XBee, start X-CTU, click READ
# Select the function set '''ZNET 2.5 COORDINATOR DEVICE AT'''.
# Set the Destination Address Low (DL) to FFFF.
# Set the PAN ID to any number, must be the same as the pan id of the end device (aircraft).
# Set the Node Identifier (NI) to PPRZ_GROUND or any other appropriate name.
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.
# Then write the firmware to the module.

=== Setup ===

For the ZigBee ZNet 2.5 and ZB modules to work one of the modules has to be flashed with the coordinator firmware. All the others in the same PAN can either run as routers or end-devices.
* Flash one module (ground station) with the coordinator AT firmware
* Flash aircraft module with router or end-device AT firmware
To allow modules to join any PAN set the PAN ID to zero (default setting). Then the coordinator will generate a random PAN ID and routers and end-devices will join the first PAN they find.

If you operate in an environment with multiple zigbee PANs it is recommended to set the PAN ID explicitly:
* Set PAN ID to some unique (but same) ID on both modules
* Set a Node Identifier for each module (e.g. ground, aircraft)
<br/>

== XBee Pro DigiMesh / 802.15.4 ("Series 1") ==

=== Flashing the airborne module ===
# Connect your XBee, start X-CTU, click READ
# Leave the function set on '''XBEE PRO 802.15.4'''.
# Set the PAN ID to any number, must be the same as the pan id of the coordinator (Ground Station).
# Set the Node Identifier (NI) to your aircraft name or any other appropriate name.
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.
# Then write the firmware to the module.

=== Flashing the ground station module ===
# Connect your XBee, start X-CTU, click READ
# Leave the function set on '''XBEE PRO 802.15.4'''.
# '''Set Coordinator Enable to "1 - COORDINATOR".'''
# Set the PAN ID to any number, must be the same as the pan id of the end device (aircraft).
# Set the Node Identifier (NI) to PPRZ_GROUND or any other appropriate name.
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.
# Then write the firmware to the module.

(Tested on XBP24 Firmwareversion 10E6)

== XBee Pro 868 MHZ ==

=== Getting Them Working ===
Even with the xbee868.xml telemetry file, XBee868s will not last over 6 minutes. There is a special 868 build flag (in slayer1.xml), and matching option for the datalink but I could not get this to work. Eventually, I got them to work for about 20 minutes, which happily is the flight endurance of a heavily overloaded GWS Formosa.

I did this using a command window, but you could use X-CTU if you are a wuss or have Windows handy.

#Attach Xbee and start serial comm program (I use <code>screen /dev/ttyUSB0 <baud rate, just a number, no angled brackets></code>, you can also use pico- or microcom)
#Type AT and enter. You should get an OK back.
#ATMT and enter. You should get a number—this represents the number of extra times each packet will be broadcast. We now need to change this to zero.
#ATMT0 and enter => OK
#ATRR and enter. This number is the number of retries that will be sent if an ACK is not received. Disabling this will also have the side effect of disabling ACKs, giving us more packets to play with.
#ATRR0 and enter => OK
#Type ATWR to store the new stuff in the firmware. You should get an OK.
#Set the datalink to transparent mode both in your airframe file and on the datalink.

You may also want to drop the power level to 1mW for testing, or it won't actually work - they are just too damn powerful to talk to each other at a range of a couple of feet. I also used 1mW for flying - never lost the link, even after a mile. Didn't get round to range testing them though.

You probably want to do this to both XBees (at least I did). I personally had the baud rate at 57600 for legacy reasons, but it should work just as well at any other baud rate. '''Thanks to CheBuzz for this info''', and for helping me work all this out at 11pm the night before EMAV09.

== XBee 868LF ==

These relativly new modems use the whole spectrum allowed in your country to avoid Duty Cycle restrictions.

== XBee Pro XSC (900MHZ) ==

== Configuring XBee API mode (xbee protocol) ==

[[Category:Hardware]] [[Category:User_Documentation]]

Installation/Linux

2016-05-03T17:15:54Z

Flixr: /* Installation of dependencies */ add architecture info

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

'''<span style="color:red">This page only describes the installation of the prerequisite tools and dependencies on Debian/Ubuntu needed for Paparazzi.</span>'''

'''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 ===
'''Binary packages for Ubuntu are available for the ''i386'', ''amd64'' and ''armhf'' architectures.'''

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 ===
'''Binary packages for Debian are available for the ''i386'' and ''amd64'' architectures. ''armhf'' packages seem to be currently not supported by the OpenSUSE build service.'''

For Debian Wheezy (7.0) and Jessie (8.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_8.0/Release.key" -O- | sudo 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_7.0/ ./" | tee -a /etc/apt/sources.list
echo "deb http://download.opensuse.org/repositories/home:/flixr:/paparazzi-uav/Debian_8.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).

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

'''This is the recommended method'''

Note that there are actually two '''different''' toolchains available that unfortunately have the same Debian package name (<tt>gcc-arm-none-eabi</tt>)!
* [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.

You can list the available versions with <tt>apt-cache policy gcc-arm-none-eabi</tt>

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

'''This is the recommended toolchain'''

On ''most'' Ubuntu versions 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.
Check available versions after adding the PPA with

apt-cache policy gcc-arm-none-eabi

To install a specific version (the one from terry.guo PPA) specify the version explicitly, e.g.
sudo add-apt-repository ppa:terry.guo/gcc-arm-embedded
sudo apt-get update
sudo apt-get install gcc-arm-none-eabi=4.9.3.2015q3-1trusty1
Meanwhile we are working with Debian to consolidate and unify this toolchain.

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

Current Debian ('''jessie''') and Ubuntu (14.04 '''trusty''' and later) releases 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

=== ARM gcc-arm-embedded tarball ===
Another way is to download and unpack the tarball and add it to your PATH:

* Download gcc-arm-none-eabi-*-*-linux.tar.bz2 from [https://launchpad.net/gcc-arm-embedded/+download External Downloads] section of ARM gcc-arm-embedded project
* Unpack it to a directory of your choice
* Add the bin folder in to your PATH

e.g.:
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
sudo 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]].

=== 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).<br>
'''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 <b>lpc21isp</b> and <b>openocd</b> 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/
sudo udevadm control --reload-rules

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.<br>
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)<br/>
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-linux-gnueabi-gcc cross-compiler not found ===

=== Ubuntu ===
apt-get install gcc-arm-linux-gnueabi

=== Debian ===
Starting with jessie, there were [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771496#41 some changes] to the way cross-compilers are set up. To make it work you will have to add armel architecture and pick up some crossbuild tools.

First edit your /etc/apt/sources.list and add the following line, to enable the emdebian repo:
deb http://emdebian.org/tools/debian/ jessie main

Run the following command in your terminal to add the keys for it
curl http://emdebian.org/tools/debian/emdebian-toolchain-archive.key | sudo apt-key add -

Then you could add armel architecture and fetch the missing cross-compiler packages
dpkg --add-architecture armel
apt-get update
apt-get install crossbuild-essential-armel

You could find out more about cross-toolchains in jessie on debian [https://wiki.debian.org/CrossToolchains wiki page].

Note that some of your repos might not mirror embedded architectures, which would give you an error when you try to update the sources. In that case you will have to specify which architecture you do want from them by editing the corresponding entry in your sources.list file, in a way described [https://wiki.debian.org/Multiarch/HOWTO here]. Like in this example with the crunchbang repo you could specify it by adding [arch=amd64,i386] to the line, so you only enable amd64 and i386 architectures:
deb [arch=amd64,i386] http://packages.crunchbang.org/waldorf waldorf main

===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)<br/>
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. <br/>
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]]

FAQ

2016-05-01T19:57:44Z

Flixr: add USB/DFU flashing entry

__TOC__

==Is it possible to do XYZ?==
:Yes, sure! The beauty Paparazzi is that it is fully opensource'ed - '''Any''' feature or function you want '''can be added''' to the software and even the hardware.

==How can I contribute?==
:See the [[Contributing| how to contribute]] wiki page.

==How do I check which Paparazzi Version I'm using==
: Run ./paparazzi_version from you paparazzi directory.
: This simple script will run ''git describe'' to find the next reachable tag and print something like ''v5.1.1_testing-43-ge060371''.
: The output contains the most recent reachable tag, number of commits since then, SHA1 of that commit and whether the working directory was dirty.
: If you have an older version of Paparazzi that does not contain that script you can just run <tt>git describe --match "v[0-9].[0-9]*" --dirty --always --long</tt>

==What equipment and components are suggested==
# Linux (Debian or Ubuntu) compatible or Apple Macintosh notebook computer, preferably with a very bright screen for outdoor use.
# Most any airframe that will accommodate a Paparazzi Autopilot and some extra weight and wiring - ''brushless motors are strongly suggested.'' See the [[Gallery|User's Gallery]] for some airframe examples.
# One of the [[Autopilots]] from one of the [[Get_Hardware|Paparazzi vendors]] or build your own from the downloadable plans/gerbers
# If it is not already included with the AP a external [[IMU]]
# A 2.4 GHz R/C Transmitter and Receiver with a 3-position switch and PPM output for selecting Manual/Stabilized/Auto.
# A pair of [[Modems]] along with any enclosures and antennas
# A [[Serial_Adapter|USB <-> UART]] adapter for connecting the modem to your USB port and/or for serial flashing of bootloader code or tunnel access to the GPS receiver
# A standard Mini-B and Micro-B USB cable
# Lots of [[Other_Hardware#Wiring|very durable wire, crimpers, and molex pins or pre-crimped wire.]]

==Are internal combustion engines supported?==
:Yes, not relying solely on inertial measurement, the Paparazzi system is very well suited for aircraft with high vibration levels. Care must be taken to prevent oily exhaust residue buildup on the IR sensors and a simple variable must be added to properly address the special idle/kill needs of an IC engine.

==Can Paparazzi fly a glider?==
:Sure. Paparazzi uses throttle and pitch to control climb rate by default. You can fit an airspeed sensor and adjust your airframe configuration to maintain airspeed instead.

==Will the autopilot provide enough 5V power for many/large/digital servos as well as a modem, video TX, etc.?==
:Depends on the Autopilot, compare the maximum output of the AP and the needed power
:The [[Tiny]] includes a high capacity and high efficiency switching voltage regulator intended to power servos, modems, video systems and other payloads. This regulator should be preferred to power the servos rather than a linear regulator. While linear regulators may be rated for several amps, they require a great deal of cooling and can easily overheat with only a few hundred milliamps of continuous current without cooling. By comparison, the switching regulator included on the Tiny can work continuously at 2A with little or no cooling. Be careful using high power or digital servos consuming a lot of current. If you use four or more of them on your airframe it is recommended to supply them separately. It is important to realize that the servos in any stabilized aircraft will operate continuously. Therefore a power supply that powers the servos reliably in manual flight may easily overheat or produce critical voltage drops in autonomous flight.

==Do I need a separate battery or regulator to isolate the autopilot, servos, video, modem, etc. from one another?==
:The autopilot processor and sensors are powered by a 3.3V regulator and therefore are rather isolated from voltage fluctuations on the battery or 5V bus.

==Can I use a Sirf, Trimble, etc. instead of the u-Blox GPS receiver?==
:Yes, but it would require a tremendous amount of work as some of the navigation code is dependent on some of the UBX messages. NMEA does not provide messages in the desired form and substantial calculation would be required for conversion. Any of the other proprietary protocols would work but you would need to write your own protocol handler. u-Blox (Hobbyking's costs <14€) offers great performance, size, and speed as well as the ability to easily configure the internal Kalman filter parameters to expect significant acceleration in 3-D space - a very important feature.

==Does Paparazzi use DGPS, WAAS, EGNOS, or MSAS?==
:Most modern GPS receivers have the ability to process serial data sent from an external DGPS receiver, but the advent of WAAS/EGNOS has made the early ground-based DGPS transmitters nearly obsolete. The u-Blox GPS receiver supports all common SBAS systems (WAAS, EGNOS, and MSAS), as well as any standard form of external DGPS. It's important to understand that DGPS merely improves the ''accuracy'' of the position estimate by subtracting any static error. The only way to improve the ''precision'' of the GPS is by improving the antenna or the GPS module itself. See [http://en.wikipedia.org/wiki/Accuracy_and_precision Wikipedia:Accuracy and Precsion] for a detailed explanation of these terms.

==How does the R/C receiver interface with the autopilot?==
:Standard hobby R/C transmitters multiplex up to 9 channels of PWM servo data into a single PPM signal which is encoded onto an FM wave for transmission, this signal is then decoded by the RF section of the R/C receiver back into the original PPM signal containing 9 servo position PWM values. This signal is normally then sent to a demultiplexer (i.e. 4017) where it is separated into 9 individual servo signals on 9 individual pins. The Paparazzi autopilot intercepts the signal between the RF section and the demultiplexer and does its own demultiplexing, filtering, and processing before multiplexing the manual or autonomous servo commands back into a single signal and passing them to the 4017 to be distributed to the servos.

==Why does Paparazzi tap directly into the R/C receiver instead of using individual servo signals?==
:By connecting directly to the RF section of the R/C receiver we are able to obtain up to 9 channels of R/C servo data from a small, lightweight inexpensive 4 channel receiver with only 3 wires needed to connect the components. Furthermore, the autopilot then has direct access to the raw R/C signal where it can be filtered, evaluated, and assessed for quality. The autopilot can then alert the user of any loss of R/C signal as well as perform any pre-configured autonomous commands in response to a loss of signal.

==Are PCM or 2.4GHz R/C systems compatible with Paparazzi?==
:Yes. Most good 2.4Ghz receivers can directly output a PPM signal on one servo pin. A general rule of thumb is that if you see any type of demultiplexer on your R/C receiver, you can look up the data sheet for it and likely tap into the input pin with success. Some information on compatible R/C receivers and how to find the PPM signal of your own receiver is given in the [[Other_Hardware#R.2FC_Receiver|RC receiver]] section.

:If that's not possible, you can use the available PPM encoder board, to re-multiplex the servo channels into one PPM signal. This seems to be a common solution.

==What R/C transmitters are compatible?==
:No mixing or programming is done in the transmitter so even the simplest models will suffice but one important requirement is a 3-position switch to select among the three autopilot modes: manual, stabilized only, and fully autonomous. Those handy with electronics can replace a dial with a switch and resistor if needed. The transmitter's PPM values need to be recorded and the channel used to control the autopilot mode must be stated. Some commonly used transmitter configuration files are provided in the [http://cvs.savannah.gnu.org/viewvc/paparazzi/paparazzi3/conf/radios/ conf/radios] folder and the syntax of these files is easy to follow for those using other brands or models.

==Can a gamepad/joystick be used to control the aircraft through the modem?==
:Yes, the code to do this was written some time ago though it was not tested in flight due to latency concerns with the primitive [[Modems#Coronis_WaveCard|Coronis]] modems used at the time. Any of the [[modems]] currently recommended should work well in this manner but the theoretical reliability is still questionable due to the fact that no interrupt or prioritization structure exists for the telemetry data so any manual control inputs would be lumped in with the rest of the data to be lost or delayed as needed.

==What do MANUAL/AUTO1/AUTO2 stand for?==

:Those are the three modes that Paparazzi can operate in. Confer to [[AutopilotModes]] for more information.

==What Electronic Speed Controllers (ESC) are compatible?==
:Any controller can be used, the exact PWM value that is sent to the controller for 0-100% throttle is completely configurable in the airframe file so all controllers are compatible and any controller will arm properly with or without the use of an R/C transmitter. Upon each boot, the autopilot immediately sends whatever you have defined as 0% throttle (typically around 1200μs) and maintains that signal until a manual or autonomous command is given. Most modern controllers are "auto calibrating" which is an undesirable feature for R/C pilots and even more so for autonomous systems but can be dealt with. The calibration is done by defining the PWM value at boot to be 0% power and then defining some initial arbitrary mid-range value such as 1500μs to be 100% until a higher value is seen. The net result of this behavior is that the motor is given full power at any command above 50% throttle until 100% throttle has actually been commanded at least once. This is not an issue for planes that routinely take off at 100% throttle but can disrupt the throttle tuning and altitude control on any flights where 100% throttle has never been commanded. [http://www.castlecreations.com/products/products_fly.html Castle Creations Electronic Speed Controllers] can be configured for "fixed endpoints" so the ESC does not need to "learn" the endpoints at first takeoff this providing a consistent and predictable throttle response. By default this range 1250-1850μs but can be set at different values where needed.

: For quadrocopters a ESc with a very low latency is highly recommended. That can be a cheap standard ESC with a upgraded firmware (which uses I2C as input) or a high quality esc (mocrocopter ESC)

==Can traditional throttle stick programming be done on the ESC once connected to the autopilot?==
:Yes. If the transmitter is on with the throttle at full or whatever is required for your ESC when the autopilot is first booted, the autopilot will immediately see the manual control signal and the throttle position and pass that along to the ESC as the first value, triggering the programming mode.

==Does Paparazzi support digital servos?==
:Of course. Digital servos use exactly the same electrical interface as their analog counterparts, the only difference being in the way they control the motor. Analog servos use a '''P'''roportional feedback loop, meaning the voltage sent to the motor is proportional to the difference between the measured and intended position of the arm. Digital servos use a '''P'''roportional + '''D'''erivative ('''PD''') feedback loop. The derivative term considers the current speed and direction of the servo as well as the speed and direction of the pilot's stick command. The derivative term will increase power to the motor if the servo is moving the wrong direction (providing faster direction changes) and will reduce/reverse power if the servo is near it's desired position but moving too fast (reducing overshoot). The net effect of this is that a digital servo can use a much stronger '''P''' term without risk of oscillation and overshoot because the '''D''' term is there to intelligently dampen it as needed and boost it whenever it can.
:How does the inclusion of a '''D''' term make an analog servo become digital? Analog servos use a simple opamp to linearly relate the motor voltage to the difference between the potentiometer reading and PWM signal, whereas digital servos use a microprocessor to analyze the potentiometer position and velocity as well as the current and recent PWM signals to calculate the optimum voltage to send to the motor.
:'''Important:''' Please be aware that autonomous flight involves ''continuous'' movement of all servos. Make sure your power supply is capable of handling this and that your servos are capable of continuous operation without overheating - especially if you use digital servos.

==Can I solder wires directly to the autopilot instead of using the molex connectors?==
:Sure, only for some board it is easier to do than for others. Tiny: All of the molex headers are thru-hole and you can easily solder small gauge wire directly to the pins that protrude from these headers on the back of the board. It's important to note that '''standard servo wire cannot be soldered reliably''' in this fashion - you must use only high-grade wire intended for soldering (no vinyl insulation!). Direct soldering is not recommended, but it is possible ofcourse. See the [[Other_Hardware#Wiring|Wiring]] section for suggested wire types and sources. If you want to go the direct soldering path, be sure to you have '''excellent soldering skills''' and use high quality wiring.

==What are the paparazzi failsafe features and how do I configure them?==
The basic autopilot already has several built-in failsafe features ranging from lowlevel to highlevel and from implied to optional. For more details take a look on the [[Failsafe]] page.

==Why do I only get a blank (black) GCS==
:The GCS stays blank until you get telemetry messages (either from the real aircraft or simulated) with the correct MD5 checksum meaning the autopilot has the correct and up to date flightplan/airframe/... programmed in it (in case of an MD5 problem you constantly get a lot of warnings in paparazzi center).
:'''Solution''': Probably your telemetry is not set up correctly, this is most likely a [[XBee configuration]] issue.[[Subsystem/telemetry#Configure_Options|Configure the baudrate for your XBee connected to the autopilot]] and [[Subsystem/telemetry#Set_GCS_baud_rate|set the baudrate for the link to the one the ground XBee uses]] (They don't need to be the same). Also make sure your xbee cable is correct, transmit (tx) of xbee goes to receive (rx) on the autopilot and vice versa.

==Why do I get a Failure("#of_world:no georef") when trying to load map tiles==
:You get the georef error because the location is not initialized (probably GCS still blank and no aircraft are present). You can't get map tiles for nowhere...
:'''Solution''': Set up your telemetry properly so you get messages from the aircraft OR start a simulation with the appropriate coordinates then load the map tiles.

==How do I check if my telemetry is working?==
:'''Solution''': Launch the link and messages tools in the Paparazzi Center. You should see the the messages coming in (blinking green) in the messages window.
: If you get an the error ''Failure("Error opening modem serial device : fd < 0 (/dev/ttyUSB0)")'' from ''link'', your modem is either not connected at all, or just available under a different device name. Check if you set the [[Installation#Setting_access_rights_for_USB_download|udev rules]] and if your modem becomes available under the device you set.
: You might need to adjust the device and baud-rate of the link according to your setup, e.g. <tt>link -d /dev/ttyUSB0 -s 57600</tt>
: If you're stuck you can make ''link'' very verbose by setting the ''PPRZ_DEBUG'' environment variable to '' '*' ''

==Why don't I get a GPS position?==
:'''Problem''': Your GPS seems to be working, but you cannot get a valid position fix. Speed and course are displayed correctly, though. Possibly you also see Invalid_argument("Latlong.of_utm") errors on the GCS log.

This may happen if you have configured the wrong GPS subsystem for your Tiny board.
If you have the LEA-5H module on your Tiny board, but have configured
<tt><subsystem name="gps" type="ublox_utm"/></tt>
in your airframe file, this will occur because the 5H module does not support UTM position.

:'''Solution''': Make sure your GPS is [[GPS#GPS_configuration_using_U-Center|configured]] correctly and change the gps type to "<tt>ublox</tt>" if applicable.

==Why do I get a CRITICAL **: murrine_style_draw_box: assertion `width >= -1' failed error message on starting the GCS==
:'''Solution''': This error is not critical at all and can be safely ignored.
It is triggered by a bug in the Murrine GTK engine in combination with the default theme which Ubuntu uses, as detailed here:
https://bugs.launchpad.net/ubuntu/+source/light-themes/+bug/538499

==Do Paparazzi autopilots support onboard datalogging with an uSD or SD card?==
:This depends on the board you are using. Writing to an SD card takes a considerable amount of processor resources, enough to significantly impact critical timings and autopilot performance on usual processors. For this reason, onboard datalogging is not supported on those autopilots. If logging is needed for these processors (say for use without a datalink) then a second board that "sniffs" the datalink telemetry is needed (see [[Data Logger]]). However, Recently introduced boards like the [[Apogee/v1.00]] using a faster processor and an on board SD card tray allow logging of flight recorder information and individual data of sensors if activated in the air frame file.

==Telemetry not working==
:If you are receiving the error "Failure("Error opening modem serial device : fd < 0 (/dev/ttyUSB0)")"
:'''Solution''': You might need to add your user to the modems group (dialout), then log out and in again.
:write in terminal:$ sudo adduser <user> dialout
:it will be effective after your next login or simply write:
:$newgrp dialout

==Can't flash autopilot==
:If you are trying to flash your autopilot board via USB and get e.g. <tt>can't find STM32 (autopilot) device</tt>
:'''Solution''': Check if your board is recognized by the kernel and you have sufficient rights on the device (should normally be set by [[Udev]] rules).
:See also [[DFU#Troubleshooting]]

==What does the name "Paparazzi" mean?==
:The original name of the project reads "PaparaDzIY" (http://www.nongnu.org/paparazzi/gallery_v0.html) which might be a French abbreviation, but the meaning of that name seems to be lost. In cases where the name "Paparazzi" is unfavourably (i.e. for serious applications not dealing with taking unasked pictures of persons) the use of the abbreviation PPRZ can be recommended.

[[Category:User_Documentation]]

Installation/Linux

2016-04-23T17:57:53Z

Flixr: /* Debian */

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

'''<span style="color:red">This page only describes the installation of the prerequisite tools and dependencies on Debian/Ubuntu needed for Paparazzi.</span>'''

'''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 Wheezy (7.0) and Jessie (8.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_8.0/Release.key" -O- | sudo 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_7.0/ ./" | tee -a /etc/apt/sources.list
echo "deb http://download.opensuse.org/repositories/home:/flixr:/paparazzi-uav/Debian_8.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).

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

'''This is the recommended method'''

Note that there are actually two '''different''' toolchains available that unfortunately have the same Debian package name (<tt>gcc-arm-none-eabi</tt>)!
* [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.

You can list the available versions with <tt>apt-cache policy gcc-arm-none-eabi</tt>

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

'''This is the recommended toolchain'''

On ''most'' Ubuntu versions 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.
Check available versions after adding the PPA with

apt-cache policy gcc-arm-none-eabi

To install a specific version (the one from terry.guo PPA) specify the version explicitly, e.g.
sudo add-apt-repository ppa:terry.guo/gcc-arm-embedded
sudo apt-get update
sudo apt-get install gcc-arm-none-eabi=4.9.3.2015q3-1trusty1
Meanwhile we are working with Debian to consolidate and unify this toolchain.

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

Current Debian ('''jessie''') and Ubuntu (14.04 '''trusty''' and later) releases 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

=== ARM gcc-arm-embedded tarball ===
Another way is to download and unpack the tarball and add it to your PATH:

* Download gcc-arm-none-eabi-*-*-linux.tar.bz2 from [https://launchpad.net/gcc-arm-embedded/+download External Downloads] section of ARM gcc-arm-embedded project
* Unpack it to a directory of your choice
* Add the bin folder in to your PATH

e.g.:
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
sudo 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]].

=== 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).<br>
'''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 <b>lpc21isp</b> and <b>openocd</b> 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.<br>
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)<br/>
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-linux-gnueabi-gcc cross-compiler not found ===

=== Ubuntu ===
apt-get install gcc-arm-linux-gnueabi

=== Debian ===
Starting with jessie, there were [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771496#41 some changes] to the way cross-compilers are set up. To make it work you will have to add armel architecture and pick up some crossbuild tools.

First edit your /etc/apt/sources.list and add the following line, to enable the emdebian repo:
deb http://emdebian.org/tools/debian/ jessie main

Run the following command in your terminal to add the keys for it
curl http://emdebian.org/tools/debian/emdebian-toolchain-archive.key | sudo apt-key add -

Then you could add armel architecture and fetch the missing cross-compiler packages
dpkg --add-architecture armel
apt-get update
apt-get install crossbuild-essential-armel

You could find out more about cross-toolchains in jessie on debian [https://wiki.debian.org/CrossToolchains wiki page].

Note that some of your repos might not mirror embedded architectures, which would give you an error when you try to update the sources. In that case you will have to specify which architecture you do want from them by editing the corresponding entry in your sources.list file, in a way described [https://wiki.debian.org/Multiarch/HOWTO here]. Like in this example with the crunchbang repo you could specify it by adding [arch=amd64,i386] to the line, so you only enable amd64 and i386 architectures:
deb [arch=amd64,i386] http://packages.crunchbang.org/waldorf waldorf main

===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)<br/>
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. <br/>
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]]

RC Receivers and Radios

2016-04-22T15:25:44Z

Flixr: add hardware category tree on right

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

= Introduction=

To be able to test your airframe before it flies fully autonomous a regular RC transmitter in combination with a receiver can be used. This is essential for testing and tuning your airframe. For this to work the received steering commands have to leave the receiver. Only then with this flow of command data the autopilot when flown in manual mode can do something you tell it to. This page is to give you information of how to connect various receivers. Also how to modify receiver so they can talk to the autopilot.

=Setup=

Once you have physically connected your receiver we need to setup the transmitter and receiver combination correctly. This can be an complex task due to the overwhelming amount of options. [[rc_transmitter_and_receiver_setup| To assist you in this setup quest a specific wiki page]] is available to help you out.

If you have a new Graupner HOTT system, the [[Graupner_HOTT_setup| Graupner HOTT setup]] page will provide all key information about setting up the Graupner transmitter and receiverand correctly output a ppm sum stream.

=2.4GHz Receivers=

There are three output type in use which you can connect a 2.4GHz receiver to your autopilot board:
# CPPM, where the C stands for '''C'''ombined, the PPM sum stream output, supported on all current autopilot boards,
# Spektrum serial data output
# S-BUS data output

If you come across the term "Satellite Receiver", it has nothing to do with satellites in earth orbit. It is just a term to describe an auxiliary receiver normally used to improve reception by plugging into the 'main' receiver.

If your receiver can not output one of the signals above, maybe you need following:

# Must have combined PPM pulsetrain out or use [[PPM_Encoder | PPM Encoder]] board. See the [[Get_Hardware| Get Hardware]] page for links to suppliers)
# At least one extra channel beyond those needed to control the servos and motor. (throttle-roll-pitch-mode)

=HOTT=

==CPPM output==

===Graupner GR-12/GR-16/GR-20 HOTT===

GR-12/GR-16/GR-20 are Transmitters from the [http://www.graupner.de/en/products/1736df13-32af-4183-aa8e-80f31a7f03cb/productcategory.aspx Graupner HOTT Series].

* 2.4 GHz FHSS system
* regular software updates, good support
* different languages (also with voice output)
* receivers work with 3.6 V to 8.4 V (functional down to 2.5 V)
* highly adjustable

For a detailed instructions for updates and setup look at the [[Graupner_HOTT_setup]] page.

=Spektrum=

The wildly popular Spektrum and other brands of receivers using the spectrum protocol are widely available. Below a few of the tested ones. It is very likly others will also work well with Paparazzi, the only diffrence is, we did not thest them yet. Best of all the protocol is well reverse engineered and almost all details are known and implemented in various opensource libraries.

==DSM2 v.s. DSMX==

If you have no specific reason, use DSMX equipment. '''DSMX''' is more robust against interference and '''advised''' over DSM2 receivers. [http://www.rcmodelreviews.com/dx8dsmxreview.shtml This very good article explains it all in depth]. We could not have explained it better ourselves.

==CPPM output==

A nice solution for e.g. Tiny and TWOG autopilot boards is use modern DSM and your trusty based autopilot board with the CPPM inputoption. This works as well on LPC and STM based boards. Note that for a configuration radio file on should choose an own one '''not spektrum''' regardless that the connection is over DSM the pulses are PPM out not the serial DSM.

===OrangeRx R410X===

[[Image:Orange_RX410X_cppm_out.jpg|thumb|left|Orange R410X Receiver]]

OrangeRx R410X DSMX compatible 4Ch with '''6 Channels''' PWM/CPPM out. This is the prefered modern alternative if you are looking to replace your "Classic" 35/36/40/41/72mHz receivers PWM/CPPM out for a robust DSMX receiver at almost no cost. Last time we looked the receivers where sold for about 8 Euro (~ 10 USD)

In order to use the receiver, failsafe has to be deactivated so the AP can detect the loss of signal (the rx still outputs PPM-frames if you don't). To deactivate it you have to give full thottle and also give full trim. Then you have to (re-)bind the rx. Check carefully if the GCS displays NONE if you switch of the tx.

<br style="clear:both">

===OrangeRx R615X===

[[Image:Orange_RX_615_with_CPPM.jpg|thumb|left|Orange R615X Receiver]]

Another option is to use the OrangeRx R615X 6Ch 2.4GHz Receiver with CPPM out.

<br style="clear:both">

===DT RX31c===

A Deltang, with software v3.5 also DSMX support, so small it is sure worth mentioning:
[[Image:DT_RX31_CPPM.jpg|thumb|left|DT Receiver Rx31c 7ch SumPPM]]

* Outputs combined PPM (Sum PPM),7 channels for e.g. a Spektrum DX8 and DX6 transmitter
* Subminiature receiver with full range. Only 0.21 grams!. Cost about EUR 30.
* The solution for very tiny aircraft.
* The channels order with Spectrum DX8 in acro mode: Throttle, Roll,Pitch, Gear, Mix, Flap,Aux2
[http://www.deltang.co.uk/rx31b.htm This manufacturer has more interesting receivers, worth a look]

<br style="clear:both">

==Direct serial output==

===OrangeRx R110X===

<gallery>
File:Orange_RX110X.jpg|Orange DSMX small receiver
File:Orange_RX110XL.jpg|Orange DSMX small receiver with longer antenna
</gallery>

OrangeRx R110X Satellite DSMX Receiver [http://www.hobbyking.com/hobbyking/store/__38393__OrangeRx_R110X_2_4Ghz_DSMX_Satellite_Receiver.html| R110X]. Works well, simple to connect. Although called, "Satellite Receiver" it is usable as a ful blown receiver when connected to an AP board. There is also a version with long antenna with two U.FL connectors on the PCB.

<br style="clear:both">

===Spektrum 9645===

[[Image:Spektrum_9645_satellite_receiver.jpg|thumb|left|Spektrum 9645 satellite receiver]]

[http://www.spektrumrc.com/Products/Default.aspx?ProdID=SPM9645| Spektrum 9645 satellite receiver]. Works well, simple to connect. the DSMX mode is not used, it is used in the DSM2 mode, the receiver is backards compatible with that protocol.
<br style="clear:both">

==S-Bus output Spektrum==

Although drafted up by Futaba there are lots of receivers from other brands also giving S-Bus signal output. Paparazzi is perfectly capable to decode the S-Bus information from whatever receiver and use it.

===Orange DSMX 3C 14ch SBus output===

If you need a tiny DSMX receiver with SBus out to connect directly to your autopilot, a good option is to use this one

[[File:Orange DSMX 3ch 14ch sbus out.jpg|thumbnail|left|Orange DSMX 14channel SBus output]]

<br style="clear:both">

===Orange DSMX 8C 14ch SBus output===

For more reception redundancy, one can add a satellite receiver like the RX110XL, and still have SBus output

<gallery>
File:Orange_RX800X.jpg|Orange DSMX 8 with 14CH SBus output
File:Orange_RX800X_and_RX110XL.jpg|Orange DSMX and a satellite
</gallery>
<br style="clear:both">

=FASST=

Futaba FASST, Robust receivers. Read more about the FASST system [http://www.futaba-rc.com/technology/fasst.html here].

==CPPM output==

===Futaba FASST 7-channel receiver===

[[Image:rs617fasst.jpg|thumb|left|Futaba RS 617]]

* Pin 8 (upper right corner in picture) of the small IC on the right contains 5 PPM pulses and can go directly to paparazzi. Pulse 6 and 7 go directly to the servos.
* Best is to remove the resistors of one of the channels and connect a small wire to pin 8 to get the combined 5 pulses on the robust 1/10th inch header.
* Do not forget to use channel 3 (only failsafe channel) as mode switch with fail safe "throttle off" as mode 2.
<br style="clear:both">

===Robbe RASST 7 & 8 channel receivers===

Robbe has produced line of Futaba FASST compatible receivers that can output only PPM which results ablility to plug into autopilot without encoder.
* [http://www.robbe.de/empfaenger-r-6007-sp-2-4-g-rasst.html R6007SP 2,4 GHz RASST] - 7 channel, for small aircraft
* [http://www.robbe.de/empf-r6107sp-2-4-ghz-rasst.html R6107SP 2,4 GHz RASST] - 7 channel, >1000m range
* [http://www.robbe.de/empf-r6008sp-2-4-ghz-rasst.html R6008SP 2,4 GHz RASST] - 8 channel, upto 3000m range

====Switch Assignment====

To assign the three position switch to any other channel but channel 7 follow these steps:
# Set up aux2(refers to aux2 on rx not the switch on the tx. aka ch7) with its input selected as 3 pos switch.
# Set up this mix - Gear to Gear (Up=-100, Down=-100, Offset =0). This inhibits the gear switch.
# Set up another mix - Aux2 to Gear (Up=100, Down=100, Offset = 0).
Notes:
#Gear on a DX-7 Air is Channel 5 and AUX2 is CH7. Once again i am referring to the inputs which are labeled on the RX not what the switches are named on the TX. If your using a DX-7 heli please substitute the names for what the rx channels are named into this guide
# DX7 Heli the 3-pos switch is named "flight mode"
# DX7 Air the 3-pos switch is named "flaps"

====Failsafe Setup====

To set up the mode channel (3 pos switch) to default to auto2 if connection is lost between rx and tx follow these steps:
# Put 3 position Switch into AUTO2 Position
# Put in bind plug
# Power up
# REMOVE the bind plug
# Power up Tx while pushing bind button
# Wait until light becomes steady and not blinking (it may become steady right off but will then start blinking again so let it go at least 5 seconds)

==S.bus output==

===S.bus to CPPM===

Frsky has an [http://www.frsky-rc.com/product/pro.php?pro_id=112 SBUS to CPPM converter] which can be used with S.bus receiver e.g. [http://www.gpdealera.com/cgi-bin/wgainf100p.pgm?I=FUTL7661 R6303SB]

====Failsafe====

To properly get the LOST bit when the S.bus receiver is out of range a hack for lpc21 is to use the led signal of the receiver (if the color is changed/tuned off when the signal is lost) and put this to a GPIO input. Then define some parameters to turn this into RC_LOST signal.

See sw/airborne/arch/lpc21/subsystems/radio_control/ppm_arch.h:54
And for the airframe (for pin P0.17):

{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<subsystem name="radio_control" type="ppm">
<define name="USE_PPM_RSSI_GPIO"/>
<define name="PPM_RSSI_IOPIN" value="IO0PIN"/>
<define name="PPM_RSSI_PIN" value="17"/>
<define name="PPM_RSSI_VALID_LEVEL" value="0"/>
</subsystem>
</source>
}}

=MULTIPLEX=

==CPPM output==

===Jeti Duplex 2.4 GHz Receiver Rsat 2===

[[Image:Jeti_Duplex_Rsat2.jpg|thumb|left|Jeti RSat 2]]
* Outputs PPM, no soldering or PPM board required
* Only 12 gramms
* Full duplex technology provides safe radio link and redundant telemetry to standard paparazzi telemetry.
* [http://www.jetimodel.cz/index.php?page=products&old=0&category=4 Transmitter module] can be installed in any receiver.

More information can be found a the [http://www.jetimodel.cz/index.php?page=product&id=165 Homepage of Jeti] and the [http://www.mikrokopter.de/ucwiki/JetiDuplex MikroKopter Wiki].
<br style="clear:both">

=PCM Receivers=

Most of the known PCM transmitter also can be set to PPM mode. If this is set, then the regular description for PPM applies since the PCM receiver like a JR/Gaupner SMC16 Scan can output PPM perfectly.

However if setting up you transmitter to PPM out then the following applies:

# Must use ppm encoder board. (See [[Get_Hardware|Get Hardware]] page for suppliers)
# At least one extra channel beyond those needed to control the servos and motor.

= PPM Receivers =

To use a 26/27/35/40/41/72/ MHz receiver a few requirements are necessary

# At least one extra channel beyond those needed to control the servos and motor.
# A receiver or modified receiver which outputs a full ppm signal.

== R/C Receiver Interface==

All versions of the Paparazzi autopilot include a connector to interface with a standard R/C receiver for manual or semi-autonomous control during the testing and tuning phases. Two interface options exist:
# Tap into the PPM signal running between the RF section and the servo driver of your receiver and route it to the Paparazzi. Let the Paparazzi generate individual servo signals and connect all servos directly to the autopilot. This method requires only 3 wires to the receiver (power and PPM), is compatible with all Paparazzi autopilots, and provides 8 manual R/C channels and the potential for more autonomous channels regardless of the capability of the R/C receiver.
# Cut the PPM trace and route it thru the autopilot and back to the receiver, using the servo driver IC on your R/C receiver to drive the servos. This option requires 4 wires (Ground, PPM-in, PPM-out, Reset) and your receiver must have a supported servo driver IC. This allows you to use the large servo connectors on your R/C receiver and does not require any modification to your servos or ESC but does require you to cut a trace on your R/C receiver and limits the number of servos to the capacity of your receiver. Compatible with Classix and Tiny 1.1.
# Note that on the Classix the PPM_in pin is FOO2...

Note 1: Exact value not critical. Depending on RC Transmitter type & Manufacturer.<br>
Note 2: Depending on Transmitter number of Channels and t,,n,, durations.<br>
Note 3: Not critical. Depending on Synchro detection method.</small>]]

<gallery>
Image:RC_Receiver_Timing_Diagram.jpg||PPM Timing Diagram
Image:RC_Receiver_Tiny.jpg|3-Wire setup, driving servos from the autopilot
Image:RC_Receiver_classix.jpg|4-Wire setup, driving servos from the R/C receiver
</gallery>
<br style="clear:both">

=== Common demux chips ===

Typical used chips are the cmos [http://www.doctronics.co.uk/4015.htm 4015] and [http://www.doctronics.co.uk/4017.htm 4017].

The 4015 uses either pin 1 or pin 9 for the clock and the input is on 7 and 15. The 4017 has just one shift register and has its clock input on pin 14 and the enable on pint 13.

In most receivers you are after the clock; though some may be pulsed; in which case you need the enable. Note that the 4017 enable has inverted logic (low to be enabled) whereas the input on the 4015 can be either (typically high). If the enable pin is held low (4017) or if the input pin (4015) is held high always;e.g. connected to the ground or the Vcc - then it is fair to assume that the PPM signal is most propably on the clock input.

== 35/40Mhz RC Receivers ==

Note that there is information on modifying other receiver models at [http://mikrokopter.de/ucwiki/RC-Empf%C3%A4nger mikrokopter.de]. It's in German however the pictures contain most of the information or use google translate.
Shielded wire is recommended for receiver and autopilot connection, as unshielded one may cause noise in receiver.

=== Futaba FP-R116FB 6 Channel FM 35MHz receiver ===

[[Image:Rc_fut_web.jpg|thumb|left|Wiring of a Futaba R136]]
*Orange wire is connected to PPM signal
*Red wire is connected to VCC
*Brown wire is connected to GND
<br style="clear:both">

=== Futaba R136F 6 Channel FM receiver ===

[[Image:rx_futaba136.jpg|thumb|left|Wiring of a Futaba R136]]
*41 MHz
*White wire is connected to PPM signal
<br style="clear:both">

=== Futaba R168DF 8 Channel dual FM receiver ===

[[Image:rx_futaba168df.jpg|thumb|left|Wiring of a Futaba R168DF]]
*35 MHz
*PPM wire is connected to 862 receiver pin on the board. VCC and GND is on the 8/B original position.
<br style="clear:both">

=== ACT Micro-6 FM receiver ===

[[Image:rx_act_micro-6.jpg|thumb|left|Wiring of a ACT Micro-6]]
*Available in 35 or 40 MHz versions
*White wire is connected to PPM signal
*[http://www.acteurope.com/Micro_6anl.pdf Datasheet (German)]
<br style="clear:both">

=== ACT DSL-4top [http://www.mikrokopter.de/ucwiki/DSL4top mikrokopter.de] version ===

[[Image:DSL4top.jpg|thumb|left|DSL-4top mikrokopter.de version]]
* Special version for mikrokopter.de - Only available in their [https://www.mikrocontroller.com/index.php?main_page=product_info&products_id=215&zenid=8ce8bab70f3e9d684e01f724316d9690 shop]!
* '''Outputs PPM directly''' on the channel 1 connector!
* No soldering necessary
* ACT Lifetime warranty
* Sells for ~45 euro
<br style="clear:both">

=== Futaba R115F 5 Channel FM receiver ===

[[Image:pprz_rx115.jpg|thumb|left|Wiring of a Futaba R115]]
*Available in 35 and 40 MHz versions
*White wire is connected to PPM signal
<br style="clear:both">

=== JETI REX 5 plus (no MPD) receiver ===

[[Image:520_Jeti_5_plus.jpg|thumb|left|Wiring of a REX 5]]

*Popular Czech made micro r/c receiver, available in 35 or 40 MHz versions
*´folded´ PCB design with parts inside, mostly inaccessable
*Small grey wire is connected to via with PPM signal
*Unusual connector used for testing, soldering recommended
*shielded wire recommended, this one taken from PC parts recycling (former soundcard to m/b connector cable)
*[http://www.jetimodel.cz/eng/navody_en/rex5_eng.pdf Datasheet (English)]
<br style="clear:both">
[[Image:DSC02414.JPG|thumb|left|other Layout of REX 5]]

=== Receiver RX-7-SYNTH IPD receiver [http://www.multiplex-rc.de/hp/produkte/artikel_detail.jsp?lfdnr=55880&action=add2notice&qty=1&cachenepper=1227896925116 Multiplex-rc.de] ===

[[Image:RX-7-SYNTH_IPD.jpg|thumb|left|Wiring of RX-7-SYNTH IPD]]

*Available in 35, 36 and 40 MHz versions
*A compact, high-quality 7-channel single-conversion FM / PPM IPD receiver
*Easy modification through connectors, see pictures
<br style="clear:both">

=== Protech 5FM 35 mHz Receiver ===

The low cost Protech '5FM' receiver makes use of an SMD version of the standard 74AHC164[http://www.ic-on-line.cn/IOL/datasheet/74ahct164_18057.pdf] 8 bit shift register; you are after PIN 1 of this chip. The circuit board has a testpad for just this pin at the top side of the circuit board.

<gallery>
Image:protech-5fm.jpg|Figure 1. <br>Protech 5FM 35 mHZ Receiver, mark 2
Image:protech-5fm-pad.jpg|Figure 2. <br> PPM tap location for the Protech 5FM receiver, near the 74AHC164 shift register
Image:protech-5fm-scope.jpg|Figure 3.<br> Protech 5FM PPM signal - not very clean/digital
</gallery>

Two physical versions exist; the older one [http://www.protech.be/Manuals/PRO205manual%20web.pdf] and a newer one pictured (fig 1). It has been distributed by protech with various ready-to-fly planes; such as the Skyraider[http://www.modelbouwforum.nl/forums/beginners/50677-protech-skyraider.html].

The solder/testpad you are after the one right next the 74x164 chip its pin 1. In this image it has a jellow wire soldered to it (the yellow wire at the top left is the normal antenna connector (fig 2). Note however that the signal is not very clean (1v/div) - which may cause issues - as shown in the above image (fig 3).

This is further compunded by the relatively noisy electrical engines; which are not brushless. A ferrite coil does not seem to help enough - Papparazi and GPS loose sync often through Xbee. Replacing the engine by a brushless outrunnen resolve the issue completely.

=== Profi Penta 35 MHz ===

<gallery>
Image:DSC00547.JPG
Image:DSC00545.JPG
</gallery>

=== Graupner R16Scan ===

The Graupner R16Scan and SMC16Scan are available in 35,36,40,41Mhz versions and belongs to one of the most reliable traditional receivers in it's class. It's a highly selective PLL SCAN narrow-band FM superhet receiver. Has 8 servo connections. And the best thing; No crystals swap is required with this receiver since it scans for your TX transmission frequency. Modified for PPM output, it can output 9 separate channels.

To modify this receiver for use with an autopilot some soldering on tiny IC pins is needed. No additional electronic parts needed.

# Desolder existing resistor from IC pin, fast and carefully
# solder a short wire to the pin on the other side of the IC as on the picture, preferably als put some isolation over it
# Solder this wire to the resistor, move isolation over resistor
# Use a little UHU por glue to make sure nothing moves when flying in rought conditions

The PPM combined data is now available on connector 8. You still can power the receiver seperatly via + - pins if you want to. Or straight from the AP board 5v out.

<gallery>
Image:Graupner_R16Scan_pwm_modification_01.jpg|How to modify
Image:Graupner_R16Scan_pwm_modification_02.jpg|Modification from other side
Image:Graupner_R16Scan_pwm_modification_03.jpg|Modification Closeup
Image:Graupner_R16Scan_pwm_modification_04.jpg|Well... why not change them all in one go.
</gallery>

== 72Mhz Receivers ==

=== Castle Creations [http://www.castlecreations.com/products/berg_ms4l.html Berg 4L] ===

[[Image:berg4L.jpg|thumb|left|Wiring of a Berg 4L]]
* Expect fantastic performance from these $40 USD parts but be warned that they are known to have unreliable crystal sockets and brittle antenna wire. The ''Berg 7'' channel receiver should work equally well and is known to have a better crystal socket - note that either receiver will provide '''8 channels''' in manual R/C mode when used with Paparazzi. Note: the rugged ''Berg 4'' cannot be modified, only the ''Berg 4L'' and ''Berg 7''.

To Modify a Berg4L, follow these instructions:
# Remove the shrink wrap. Use a good knife and be careful to not damage any of the components on the receiver. I would recommend that you cut on the sides (edge of the PCB) to be sure to avoid damaging the shielding
# Desolder the headers. We will not use them with tiny AP as the servos are connected directly to the AP. This is pretty easy to do when you have a hot air rework station. If you don't have one, your best bet is to cut the header off and remove the left over pins one by one with a regular iron. There is a piece of shielding material that is connected to one of the ground pins of the header. You need to remove it carefully from the header without damaging it and re-solder it to the gnd pad.
# You need to solder 3 wires to the receiver. Gnd, +5V and PPM. To locate the PPM signal, first locate the PIC micro controller close to the location of the headers. The PPM signal is on the corner pin closest to the corner of the receiver. Soldering a 28guage wire directly to the PIN isn't very difficult. For the power connection, use the pads that were used for the header. The outside pin is Gnd, the second pin is +5V. What I did is solder the wires on the pad going straight down, then I looped the 3 wires 360 degrees and glued them to the PCB with hot glue. This provides good strain relief.
# While you have the PCB in your hands, take the opportunity to remove the crystal connector and solder your crystal directly to the PCB for added reliability.
# I also used some hot glue to add more strain relief to the antenna
# Use some large shrink wrap to cover the entire receiver again
<br style="clear:both">

=== Hitec Electron 6 72MHz Reciever ===

This was written for MNAV from crossbow but is still usable with PPRZ.

[[Image:Electron6mod.jpg|thumb|left]]
<br style="clear:both">

=== Corona Synthesized Dual-Conv Receiver 8Ch ===

[http://www.corona-rc.com/coproductshowE.asp?ArticleID=63 manual]

This receiver is available in 27,35,36,40,72 mhz and a Synthesized receiver, meaning you do not need to change frequency crystals.

How to modify for combined signal

# Cut the 8th channel PWM output pin near the PCB.
# Connected a pin from the Atmel (see picture) to the 8th channel PWM signal. (optionally, weaving the wire through some holes on the board.) Make sure you have a fine tip on your soldering iron and a magnifying glass strapped to your head!
# Glue the wire down (CA works)
# Be sure to glue the pin that you cut in place (previously, being soldered to the board was holding the pin in place)

It is maybe possible to reprogram the atmel with your own firmware. If you succeed in this plz add relevant info here.

That pin provides a 1V to 2V signal, it works with the PPRZ, although its a bit gittery (the slew rate is not real good).
<gallery>
Image:Corona_Synthesized_Receiver_72Mhz_bottom.jpg
Image:Corona_Synthesized_Receiver_72Mhz_top.jpg
Image:Corona_Synthesized_Receiver_72Mhz_top_atmel.jpg
</gallery>
<br style="clear:both">

= UHF Receivers =

Note that in most countries an amateur radio license is required to use 433MHz UHF.<br/>
See also [[Modems#HAM_.2F_CEPT_Licence]].

== Scherrer UHF ==
[[Image:ScherrerUHF.jpg|thumb|left|Scherrer UHF Rx]]

The [http://www.webx.dk/rc/uhf-link3/uhf-link3.htm Scherrer UHF] is a high quality diversity radio control system. It has a PPM output and can be connected directely to Paparazzi. A ppm encoder board is not required. It has an RSSI output.
<br style="clear:both">

== ImmersionRC EzUHF ==
[[Image:EzUHFTx.jpg|thumb|left|ImmersionRC Tx]]

The [http://www.immersionrc.com/products.htm ImmersionRC EzUHF] is a high quality diversity radio control system. The recent firmwares have a PPM output on Ch. 1, but this needs to be activated through the PC configuration software with the proper firmware loaded. It connects directly to EzOSD and the TrackR2 which enables RSSI monitoring and head tracking for FPV.

Some people had issues with the exact timing, where the ROLL channel disappeared. If the radio has more than 6 channels, there may be methods to slave another channel to the roll channel (usually for the operation of dual ailerons). The ezuhf configuration file is using this method, where channel 1 is copied to channel 6. The EzUHF modules receive the PPM output stream from the radio and need to interpret it. For this reason, the ezuhf configuration file should be verified for proper functioning and you may find that channels are remapped to others with different purposes.

Search "sander style" antennas for a way to build your own cheap, high-quality antennas for these rx modules and which provide a range well beyond the horizon.

See [http://www.immersionrc.com/EzUHF.htm EzUHF manual+firmware] for more information.
<br style="clear:both">

==OrangeRx Open LRS 433MHz 9Ch Receiver==
No Image? Indeed, if you have this device, plz upload a photo.

Via a firmware update this receiver is capable of CPPM output on Pin 5. A good option if you need very long range RC control. If you are able, it is posible to wriggle telemetry output in return for this module also. The Paparazzi Team has not tried it. So if you want to land up in the PPRZ hal of fame, try it and report back, that would be awesome!

<br style="clear:both">

= Radios=

The word radio here is a RC Transmitter (TX), nothing to do with a device to liten to your favorite music channel. Opensource enthousiasts as we are, there are also various opensource based RC transmiitter for even more flexibility.
We won't advise of specific brand here, the only keyword here is reliability. For 100% autonomous flight one could argue, no RC transmitter is needed. That is true, but experience shows that it is better to have a backup control device.

[[Category:Hardware]] [[Category:User_Documentation]]

Subsystem/ahrs

2016-04-22T10:01:25Z

Flixr: /* Complementary Quaternion (fixed point) */

<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages hideprefix=always>Subsystems</categorytree>
== AHRS subsystem ==
The '''A'''ttitude and '''H'''eading '''R'''eference '''S'''ystem subsystem specifies which attitude estimation filter you are using.

Currently possible AHRS subsystem types are:

{| class="wikitable" style="text-align:center" border="1"
! Type !! Point type !! Firmwares !! Notes
|-
|'''[[Subsystem/ahrs#Complementary_Quaternion_.28fixed_point.29|int_cmpl_quat]]''' || fixed || all ||
|-
|'''[[Subsystem/ahrs#Complementary_Quaternion.2FRotation_Matrix_.28floating_point.29|float_cmpl]]''' || floating || all ||
|-
|'''[[Subsystem/ahrs#DCM_.28floating_point.29|float_dcm]]''' || floating || fixedwing ||
|-
|'''[[Subsystem/ahrs#Complementary_Euler_.28fixed_point.29|int_cmpl_euler]]''' || fixed || rotorcraft ||
|-
|'''[[Subsystem/ahrs#Kalman_Filter_Quaternion|float_mlkf]]''' || floating || rotorcraft ||
|-
| '''[[Subsystem/ahrs#Infrared|infrared]]''' || || fixedwing? ||
|}

e.g. for the latest complementary filter:
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
<subsystem name="ahrs" type="int_cmpl_quat"/>
</firmware>
</source>
}}

== Implementations ==

There is a test program ( sw/airborne/test/ahrs/compare_ahrs.py ) to compare different AHRS implementations on simple test cases.

<span style="color:#FF0000">'''Caution!'''</span> '''Please also see [https://github.com/paparazzi/paparazzi/issues/93 issue 93] about proper handling of BODY_TO_IMU in all AHRS algorithms.'''

=== Complementary Quaternion (fixed point) ===

To measure attitude angles, gyrometers measurements are integrated. The result of integration is accurate for short term, but gyro bias is accumulated, which results in long term errors (drift).
On the other hand, accelerometers can be used to measure angles directly, but they suffer from noise due to vibrations. The measurement is then only accurate when averaged over a long term. Also, accelerometers alone are unable to give accurate angles when the vehicle is accelerating.
Complementary filter takes advantage of both sensors, using a low-pass filter on accelerometer readings and high pass filter on gyrometers readings, to estimate attitude angles.
* No danger of [http://en.wikipedia.org/wiki/Gimbal_lock gimbal lock], since quaternions are used.
* The arithmetic is [http://en.wikipedia.org/wiki/Fixed-point_arithmetic fixed point] and is thus suitable if the processor (on your board) has no [http://en.wikipedia.org/wiki/Floating_point_unit FPU].
* Estimates the gyro bias.
* For rotorcrafts: uses magnetometer for heading. Needs calibration!<br/>You can add <source lang="xml" enclose="none"><configure name="USE_MAGNETOMETER" value="TRUE"/></source> to be explicit about it.
* Also suitable for fixedwings, but you need GPS.
** Compensation of centrifugal force via GPS speed (to fly in circles with a fixedwing).<br/>Enabled with AHRS_GRAVITY_UPDATE_COORDINATED_TURN which is set by default for a fixedwing firmware.
** For fixedwing firmware, GPS course is used for heading estimation by default (and magnetometer disabled), add <source lang="xml" enclose="none"><configure name="USE_MAGNETOMETER" value="FALSE"/></source> if you want to be explicit.
** To use magnetometer for heading: <source lang="xml" enclose="none"><configure name="USE_MAGNETOMETER" value="TRUE"/></source> and <source lang="xml" enclose="none"><configure name="AHRS_USE_GPS_HEADING" value="FALSE"/></source>

Other flags of interest are:
*AHRS_PROPAGATE_LOW_PASS_RATES : apply a low pass filter on rotational velocity
*AHRS_MAG_UPDATE_ALL_AXES : use mag to also update roll/pitch and not only yaw (not recommended in most cases)

* NEW since [https://github.com/paparazzi/paparazzi/commit/b40da0ae56e861e088017c01426d0c4ed7c43350 v5.1_devel-455-gb40da0a]:
** Proper scaling of corrections for 100Hz fixedwing or 500Hz for rotorcraft.
** Allow tuning of the accel and mag correction natural freqency and damping.
** Tunable gravity_heuristic_factor to reduce accelerometer influence only when the vehicle is accelerating (norm of ax,ay,az ~ 9,81 m/s2).

* Flags of interest in master branch are:
** AHRS_PROPAGATE_FREQUENCY: IMU gyrometer reading frequency ( Hz, depend on IMU subsystem used and its configuration)
** AHRS_CORRECT_FREQUENCY: IMU accelerometer reading frequency (Hz)
** AHRS_MAG_CORRECT_FREQUENCY: IMU magnetometer reading frequency (Hz)
** AHRS_ACCEL_OMEGA: Complementary filter accelerometer cut-off frequency (rd/s). Default is 0.063 rd/s, the accelerometer reading are "averaged" over 100 seconds (= 2*pi/0.063) to correct gyro bias. Lower the cut-off frequency reduce the influence of accelerometers. WARNING: if ACCEL_OMEGA is set at a lower frequency, the gyro bias variations may not be corrected fast enough. As a result, the computed attitude may show significant static (or low frequency) errors. If accel_omega is set higher, the gyro bias will be well corrected and the static accuracy of the computed angle will be very good, but the dynamic error of the computed angle may be bad.
** AHRS_ACCEL_ZETA: Complementary filter accelerometer damping. Default is 0.9
** AHRS_MAG_OMEGA:Complementary filter magnetometer cut-off frequency (rd/s). Default is 0.04 rd/s. Acts the same as accelerometer but on the yaw axis.
** AHRS_MAG_ZETA:Complementary filter magnetometer damping. Default is 0.9
** AHRS_GRAVITY_HEURISTIC_FACTOR: Default is 30. Reduce accelerometer cut-off frequency when the vehicle is accelerating: norm(ax,ay,az) ~ 9,81 m/s2. WARNING: when the IMU is not well damped, the norm of accelerometers never equals to 9,81 m/s2. As a result, the GRAVITY_HEURISTIC_FACTOR will reduce the accelerometer bandwith even if the vehicle is not accelerating. Set AHRS_GRAVITY_HEURISTIC_FACTOR = 0 in case of vibrations.
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
<subsystem name="ahrs" type="int_cmpl_quat"/>
</firmware>

<section name="AHRS" prefix="AHRS_">
<define name="H_X" value=" 0.51562740288882"/>
<define name="H_Y" value="-0.05707735220832"/>
<define name="H_Z" value=" 0.85490967783446"/>
</section>
</source>
}}

Also see the [[Subsystem/ahrs#Local_Magnetic_Field|Local Magnetic Field]] section.

To use '''int_cmpl_quat''' for fixedwings without magnetometer (GPS based heading estimation instead):
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing">
...
<subsystem name="ahrs" type="int_cmpl_quat"/>
<configure name="USE_MAGNETOMETER" value="FALSE"/>
</firmware>
</source>
}}

=== Complementary Quaternion/Rotation Matrix (floating point) ===
* Estimates the gyro bias.
* By default uses magnetometer for heading for rotorcrafts.
* Choose either ''type="float_cmpl_rmat"'' or ''type="float_cmpl_quat"'', which define ''AHRS_PROPAGATE_RMAT'' or ''AHRS_PROPAGATE_QUAT'' respectively to select if the propagation is done in rotation matrix or quaternion representation.
* For fixedwings:
** Compensation of centrifugal force via GPS speed (to fly in circles with a fixedwing).<br/>Enabled with AHRS_GRAVITY_UPDATE_COORDINATED_TURN which is set by default for a fixedwing firmware.
** GPS based heading estimation: https://github.com/paparazzi/paparazzi/issues/130
Other flags of interest are:
* AHRS_PROPAGATE_LOW_PASS_RATES : apply a low pass filter on rotational velocity
* AHRS_MAG_UPDATE_ALL_AXES : use mag to also update roll/pitch and not only yaw (not recommended in most cases)
* AHRS_GRAVITY_HEURISTIC_FACTOR: Default is 30. Reduce accelerometer cut-off frequency when the vehicle is accelerating: norm(ax,ay,az) ~ 9,81 m/s2. WARNING: when the IMU is not well damped, the norm of accelerometers never equals to 9,81 m/s2. As a result, the GRAVITY_HEURISTIC_FACTOR will reduce the accelerometer bandwith even if the vehicle is not accelerating. Set AHRS_GRAVITY_HEURISTIC_FACTOR = 0 in case of vibrations

{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="rotorcraft or fixedwing">
...
<subsystem name="ahrs" type="float_cmpl_quat">
</subsystem>
</firmware>

<section name="AHRS" prefix="AHRS_">
<define name="H_X" value=" 0.51562740288882"/>
<define name="H_Y" value="-0.05707735220832"/>
<define name="H_Z" value=" 0.85490967783446"/>
</section>
</source>
}}

Also see the [[Subsystem/ahrs#Local_Magnetic_Field|Local Magnetic Field]] section.

<p>
No danger of [http://en.wikipedia.org/wiki/Gimbal_lock gimbal lock], since quaternions are used.
<br/>
Suitable for fixedwings. Needs GPS!
<br/>
Suitable for rotorcraft if the magnetometer is calibrated.
<br/>
The arithmetic is [http://en.wikipedia.org/wiki/Floating_point floating point] and is thus '''not''' suitable if the processor (on your board) has '''no''' [http://en.wikipedia.org/wiki/Floating_point_unit FPU].
</p>

=== DCM (floating point) ===
* No direct gyro bias estimation, but also compensates for attitude drift.
* Uses GPS speed for heading.
* Compensation of centrifugal force via GPS speed (to fly in circles with a fixedwing).
* '''Careful, it doesn't handle all BODY_TO_IMU rotations (mounting positions) correctly!'''

The algorithm was developed by William Premerlani and Paul Bizard. The theory can be found here: [[Media:DCMDraft2.pdf|DCMDraft2.pdf]] The algorithm is also used in the AHRS systems of the AdruIMU.
The name DCM for the algorithm is really a misnomer, as that just means that the orientation is represented as a '''D'''irection'''C'''osine'''M'''atrix (rotation matrix). But since people already know it under that name, we kept it.

Other flags of interest are:
*USE_MAGNETOMETER : use magnetometer to update yaw (UNTESTED. The magnetometer code has to be improved, since ferromagnetic materials affect the magnetic field. This is currently not implemented.)
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing">
...
<subsystem name="ahrs" type="float_dcm"/>
</firmware>
</source>
}}

=== Complementary Euler (fixed point) ===
* Not recommended for fixedwings, as this filter doesn't compensate for centrifugal force when flying turns.
* Magnetometer is always only used for heading (yaw).
* '''Does not handle the accel and mag updates correctly if BODY_TO_IMU is used for more than just adjustment by a few degrees.'''
* In general, rather use ''[[Subsystem/ahrs#Complementary_Quaternion_.28fixed_point.29|int_cmpl_quat]]''

Optional flags/defines are:
* FACE_REINJ_1 : defaults to 1024
* IMU_MAG_OFFSET : offset to subtract from the heading calculated by the magnetometer
* USE_NOISE_FILTER : apply a simple filter on the rate and accel inputs
* USE_NOISE_CUT : cut rate input at 1 rad/s and accel input at 20m/s²

{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="rotorcraft">
...
<subsystem name="ahrs" type="int_cmpl_euler"/>
</firmware>

<section name="MISC">
<define name="FACE_REINJ_1" value="1024"/> 
</section>
</source>
}}

<p>
Possible danger of [http://en.wikipedia.org/wiki/Gimbal_lock gimbal lock], since quaternions are not used.
<br/>
Repeat from above: '''Not''' suitable for fixedwings.
<br/>
Suitable for rotorcraft. The magnetometer is used to determine the yaw and needs to be calibrated.
Recommended replacement: [[Subsystem/ahrs#Complementary_Quaternion_.28fixed_point.29|int_cmpl_quat]]
<br/>
The arithmetic is [http://en.wikipedia.org/wiki/Fixed-point_arithmetic fixed point] and is thus suitable if the processor (on your board) has no [http://en.wikipedia.org/wiki/Floating_point_unit FPU].
</p>

=== Kalman Filter Quaternion ===
Multiplicative Linearized [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter] in quaternion formulation.
* Available in v5.0 and later
* Estimates the gyro bias.
* Uses magnetometer to update all 3 axes.
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="rotorcraft">
...
<subsystem name="ahrs" type="float_mlkf"/>
</firmware>

<section name="AHRS" prefix="AHRS_">
<define name="H_X" value=" 0.51562740288882"/>
<define name="H_Y" value="-0.05707735220832"/>
<define name="H_Z" value=" 0.85490967783446"/>
</section>
</source>
}}

Also see the [[Subsystem/ahrs#Local_Magnetic_Field|Local Magnetic Field]] section.

<p>
No danger of [http://en.wikipedia.org/wiki/Gimbal_lock gimbal lock], since quaternions are used.
<br/>
'''Not''' suitable for fixedwings!
<br/>
Suitable for rotorcraft. The magnetometer is used and needs to be well calibrated.
Estimates attitude and heading. Does not use GPS.
<br/>
The arithmetic is [http://en.wikipedia.org/wiki/Floating_point floating point] and is thus '''not''' suitable if the processor (on your board) has '''no''' [http://en.wikipedia.org/wiki/Floating_point_unit FPU].
</p>

=== Infrared ===
For use with infrared sensors that detect aircraft attitude and the [[Module/infrared| infrared module]].

== Local Magnetic Field ==
[[Image:Noaa_mag_data.png|thumb|right|200px|Screenshot of noaa page]]
[[Image:Normalised_mag_fields.png|thumb|right|200px|Screenshot of scilab page]]
'''This is needed if the magnetometer should be used !'''<br/>
Take also a look at [[ImuCalibration#Calibrating_for_the_Earth_magnetic_field| magnetometer calibration]] which should be done to increase accuracy !

First the values of the local magnetic field vector are needed. They can be found at the states geological institute.

USA [http://www.ngdc.noaa.gov/geomag-web/#igrfwmm ngdc.noaa.gov]

Needed values are:
* north component (x)
* east component (y)
* vertical component (z)

The vector components are in nanotesla (nT) but AHRS needs these values as a unit vector (the length of a unit vector is 1), so they need to be normalized.

'''Convert them:'''

Copy the north(x), east(y), and vertical(z) component values into scilab and execute "X/norm(X)" or run this in ipython:

<source lang=python>
import numpy as np
x = np.array([20875.1, 8480.2, -51279.8])
x/np.linalg.norm(x)
</source>

or enter this into [http://wolframalpha.com Wolfram Alpha]:
<source lang=python>
Normalize[{20875.1, 8480.2, -51279.8}]
</source>

Lastly, enter the results into your airframe file as H_X, H_Y, and H_Z:
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<section name="AHRS" prefix="AHRS_">
<define name="H_X" value="0.372692"/>
<define name="H_Y" value="0.151401"/>
<define name="H_Z" value="-0.915521"/>
</section>
</source>
}}

=== Update geomagnetic field vector based on GPS ===
You can also add the [http://docs.paparazziuav.org/latest/module__geo_mag.html geo_mag.xml module], which will update the normalized magnetic field at startup using GPS fix:
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<modules>
<load name="geo_mag.xml"/>
</modules>
</source>
}}

== Enabling External Sensors ==

By default the AHRS algorithms will utilize onboard sensors. Paparazzi currently has support for external Magnetometers. In order to use an external sensor you must specify the ABI Message ID of the sensor.

{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<subsystem name="ahrs" type="float_cmpl_quat">
<define name="AHRS_FC_MAG_ID" value="MAG_HMC58XX_SENDER_ID"/>
</subsystem>
</source>
}}

{| class="wikitable" style="text-align:center" border="1"
! Type !! AHRS_XXX_MAG_ID
|-
|'''[[Subsystem/ahrs#Complementary_Quaternion_.28fixed_point.29|int_cmpl_quat]]''' || AHRS_ICQ_MAG_ID
|-
|'''[[Subsystem/ahrs#Complementary_Quaternion.2FRotation_Matrix_.28floating_point.29|float_cmpl]]''' || AHRS_FC_MAG_ID
|-
|'''[[Subsystem/ahrs#DCM_.28floating_point.29|float_dcm]]''' || AHRS_DCM_MAG_ID
|-
|'''[[Subsystem/ahrs#Complementary_Euler_.28fixed_point.29|int_cmpl_euler]]''' || AHRS_ICE_MAG_ID
|-
|'''[[Subsystem/ahrs#Kalman_Filter_Quaternion|float_mlkf]]''' || AHRS_MLKF_MAG_ID
|}

[[Category:User_Documentation]] [[Category:Subsystems]]

Radio Control

2016-04-18T14:01:31Z

Flixr: /* PPM Radio Configuration */

== PPM Radio Configuration ==

This XML file, usually located in the <tt>conf/radios</tt> directory, contains a description of the radio control transmitter PPM signal. It should follow the grammar described in <tt>radio.dtd</tt>.

<span style="color:#FF0000">'''CAUTION!'''</span> <b>This is only used for receivers with PPM output, so it does not apply to receivers/satellites with serial output, e.g. SBus, Spektrum and [[SuperbitRF]].</b>

The contents are an '''ordered''' sequence of elements describing each channel with its name and its range:

<tt><source lang="xml"><!DOCTYPE radio SYSTEM "radio.dtd">
<radio name="cockpitMM" data_min="900" data_max="2100" sync_min ="5000" sync_max ="15000" pulse_type="POSITIVE">
<channel ctl="D" function="ROLL" min="2000" neutral="1498" max="1000" average="0"/>
...
<channel ctl="E" function="MODE" min="2000" neutral="1500" max="1000" average="1"/>
...
</radio></source></tt>

The order of the channels must be the order of the pulses in the PPM signal.

Among the top attributes, we find

* <tt>name</tt>: used only in debug traces.
* <tt>data_min</tt> (resp. <tt>_max</tt>): the minimum (resp. max) width (in microseconds) used to code one channel of the PPM signal.
* <tt>sync_min</tt> (resp. <tt>_max</tt>): the minimum (resp. max) width (in microseconds) between two impulses set of the PPM signal.
* <tt>pulse_type</tt>: the polarity of the PPM pulse. Can be either <tt>POSITIVE</tt> (FUTABA, Hitec, Multiplex etc) or <tt>NEGATIVE</tt> (JR, Graupner etc.).<br/>With <tt>POSITIVE</tt> it will trigger on the rising flank to measure the time of the positive pulse, with <tt>NEGATIVE</tt> on the falling flank (for a negative pulse width).

Each channel is described with its transmitter name (<tt>ctl</tt>), its <tt>function</tt> name, its range in microseconds and its neutral value in microseconds.
These values are used by the autopilot to compute a normalized input from the PPM signal (this file is preprocessed and the produced code is included in the airborne code). Note that the <tt>min</tt> and <tt>max</tt> attributes can be exchanged to reverse the direction of the command.

'''Wrong attributes of the "radio" element will prevent the decoder to recognize any PPM frame; same for a wrong number or channels.'''

=== Number of channels ===

Note that the number of channels in your radio file <b>must exactly match</b> the number of channels in the ppm sum signal the autopilot receives.<br>
Also the ''function'' names must be unique.

* in case of analog 35MHz receivers it is the RC - TRANSMITTER that makes the pulse train (receiver only does RF part)
** radio file depends on transmitter, you could swap to another receiver (and e.g. you can use a 4channel receiver to receive 9 pulses :-) )
* in case of digital receivers it is not the transmitter but the receiver that makes the pulses
** e.g. Futaba Fasst 6017: you can use any compatible transmitter without need to change the radio file
* in case of an encoder it is the encoder that makes the summed pulse
** if the encoder software makes 8 pulses, even with a 5 channel RC connected paparazzi will get 8: so the radio file should read 8

This means if your transmitter sends for example a PPM18 (Graupner/JR) signal you have nine (9) different servo channels. Even if you use a receiver with less channels you must set up <b>all</b> transmitting servos, even if you do not use them then you must use "bogus switches" related to functions. For example a six (6) servo channels out receiver with five (5) functions used in combination with a nine (9) servo channels transmitter would need four (4) bogus entries. (5 + 4 = 9)

<source lang="xml">
...
<channel ctl="NoneA" function="NOTUSEDA" min="1100" neutral="1500" max="1900" average="0"/>
<channel ctl="NoneB" function="NOTUSEDB" min="1100" neutral="1500" max="1900" average="0"/>
<channel ctl="NoneC" function="NOTUSEDC" min="1100" neutral="1500" max="1900" average="0"/>
<channel ctl="NoneD" function="NOTUSEDD" min="1100" neutral="1500" max="1900" average="0"/>
...
</source>

=== Averaging ===

The <tt>average</tt> attribute must be set to '''1..x''' for ''discrete'' channels for which a trivial averaging filter will be applied. The neutral of a discrete channel need to be halfway through the min and max values. Otherwise it won't be mapped properly by the filter. Note that averaging a channel gives the output an additional small delay.

== Direction ==

The following signs have been used in the radio configuration files distributed in <tt>conf/radios</tt>:

* '''ROLL''': The <tt>min</tt> attribute value stands for the right position of the stick (turning right)
* '''PITCH''': The <tt>max</tt> attribute value stands for the up position of the stick (pitching up)

''' From "v3.9" on this has been changed to follow standard aerospace conventions:'''
* '''ROLL''': The <tt>max</tt> attribute value stands for the right position of the roll stick (banking right)
* '''PITCH''': The <tt>max</tt> attribute value stands for the "up" position of the pitch stick pulled towards you (pitching up)
* '''YAW''': The <tt>max</tt> attribute value stands for the right position of the yaw stick (yawing clock-wise)

=== Practical test ===
In the RC message:
* when the ROLL stick is pulled to the right (aircraft banks right), you should see a value close to -MAX_PPRZ (-9600) in the ROLL channel
* When the PITCH stick is pulled (aircraft pitches up), you should see a value close to MAX_PPRZ (9600) in the PITCH channel

''' From "v3.9" on this has been changed to follow standard aerospace conventions:'''
* when the ROLL stick is pulled to the right (aircraft banks right), you should see a value close to MAX_PPRZ (9600) in the ROLL channel
* When the PITCH stick is pulled (aircraft pitches up), you should see a value close to MAX_PPRZ (9600) in the PITCH channel
* When the YAW stick is pulled to the right (aircraft yawing clock-wise), you should see a value close to MAX_PPRZ (9600) in the YAW channel

This works with all kind of radios (PPM, USB, 2.4GHz)

== Example ==

Below you find an example of a radio file.

<source lang="xml">
<?xml version="1.0"?>





<radio name="GraupnerMC20" data_min="950" data_max="2150" sync_min="5000" sync_max="15000" pulse_type="NEGATIVE">
<channel ctl="A" function="THROTTLE" min="1100" neutral="1100" max="1900" average="0"/> 
<channel ctl="B" function="ROLL" min="1100" neutral="1500" max="1900" average="0"/> 
<channel ctl="C" function="PITCH" min="1900" neutral="1500" max="1100" average="0"/> 
<channel ctl="D" function="YAW" min="1100" neutral="1500" max="1900" average="0"/> 
<channel ctl="E" function="MODE" min="1100" neutral="1500" max="1900" average="1"/> 
<channel ctl="F" function="GAIN1" min="1100" neutral="1500" max="1900" average="0"/> 
<channel ctl="G" function="GAIN2" min="1100" neutral="1500" max="1900" average="0"/> 
<channel ctl="H" function="SWITCH1" min="1100" neutral="1500" max="1900" average="1"/> 
<channel ctl="I" function="UNUSED" min="1100" neutral="1500" max="1900" average="1"/> 
</radio>
</source>

== PPM input to output chain ==
The chain from ppm input to servo output has intermediate steps and roughly looks like this:

ppm input --(radio.xml)--> ppm_pulses[] --(radio.xml)--> radio_control.values[] --([[Fixedwing_Configuration#Manual|rc_commands]])--> commands[] --([[Fixedwing_Configuration#Servos|command_laws,servos]])--> actuators_pwm_values[] ppm out

Written in parenthesis is where you configure how to transform one value into the other.

So in a simple case without fancy mixing, e.g. looking at the roll command / aileron servo while in MANUAL mode:
#PPM sum signal is read and split into channels as specified in your radio xml file.<br/>It does some sanity checking on the pulse length and frame lenght according to the top attributes in that file.<br/>This is written to the ppm_pulses array, where you now have the length of the pulse in system ticks.
#Now these get converted to radio_control.values array according to the channels in your radio xml file.<br/>They get scaled to MAX_PPRZ (9600), meaning what you specified as max is 9600, neutral is 0, etc.<br/>radio_control.values[RADIO_ROLL] now has the value 9600 if the pulse width of that channels was "max"
#Mapping of RC commands to the actual commands as specified in rc_commands section.<br/>In your case simply copy radio_control.values[RADIO_ROLL] to commands[COMMAND_ROLL]
#Applying command_laws (mixing) to get the commands for each servo.<br/>Again just copying in your case...
#Scaling from commands with MAX_PPRZ scale to the actual pwm output signal according to the servos section.

== Measuring the PPM time values ==

[[Image:RC_Receiver_Timing_Diagram.jpg|thumb|R/C receiver timing diagram]]

There are two common ways to measure the time characteristics of the PPM signal:
# Using an oscilloscope: easy to achieve with a high level digital scope with capture and measure facilities.
# Using the telemetry of the autopilot: the '''PPM''' message (defined in <tt>conf/messages.xml</tt>) contains the sequence of a (recently) received PPM signal.

With the default telemetry configuration file (<tt>conf/telemetry/default_fixedwing.xml</tt>), this message is '''not''' sent in the '''default''' fbw telemetry mode (numbered 0).

There are two ways to enable this message:
* Use the settings mechanism to change the FBW telemetry mode while the autopilot is already running:<br/>In the GCS: Settings -> telemetry -> tele_FBW -> set to debug (1)
* This mode can be permanently changed to '''debug''' (numbered 1) in the airframe file by setting the '''TELEMETRY_MODE_FBW''' constant in your firmware section:
<source lang="xml"><define name="TELEMETRY_MODE_FBW" value="1"/></source>

'''Since "v3.9" the values in the PPM message are in µs.'''

Before "v3.9" the time unit used in this '''PPM''' message was hardware dependent:
* On the obsolete AVR hardware, 1 microsecond = 16 units (because the crystal is running at 16MHz)
* on the LPC hardware, 1 microsecond = 15 units (because the cristal is running at 12MHz)
*:(<tt>conf/autopilot/tiny.h</tt>), the CPU clock is 5 times more, the peripheral bus is 4 times less, and the timer is not prescaled (<tt>sw/airborne/arch/lpc21/mcu_periph/sys_time_arch.h</tt>) !!!)

== Tips ==

If one has a good servo tester the output values at the receiver side can be measured

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

Radio Control

2016-04-18T14:01:19Z

Flixr: /* PPM Radio Configuration */

== PPM Radio Configuration ==

This XML file, usually located in the <tt>conf/radios</tt> directory, contains a description of the radio control transmitter PPM signal. It should follow the grammar described in <tt>radio.dtd</tt>.

<span style="color:#FF0000">'''CAUTION!'''</span> <b>This is only used for receivers with PPM output, so it does not apply to receivers/satellites with serial output, e.g. SBus, Spektrum and[[SuperbitRF]].</b>

The contents are an '''ordered''' sequence of elements describing each channel with its name and its range:

<tt><source lang="xml"><!DOCTYPE radio SYSTEM "radio.dtd">
<radio name="cockpitMM" data_min="900" data_max="2100" sync_min ="5000" sync_max ="15000" pulse_type="POSITIVE">
<channel ctl="D" function="ROLL" min="2000" neutral="1498" max="1000" average="0"/>
...
<channel ctl="E" function="MODE" min="2000" neutral="1500" max="1000" average="1"/>
...
</radio></source></tt>

The order of the channels must be the order of the pulses in the PPM signal.

Among the top attributes, we find

* <tt>name</tt>: used only in debug traces.
* <tt>data_min</tt> (resp. <tt>_max</tt>): the minimum (resp. max) width (in microseconds) used to code one channel of the PPM signal.
* <tt>sync_min</tt> (resp. <tt>_max</tt>): the minimum (resp. max) width (in microseconds) between two impulses set of the PPM signal.
* <tt>pulse_type</tt>: the polarity of the PPM pulse. Can be either <tt>POSITIVE</tt> (FUTABA, Hitec, Multiplex etc) or <tt>NEGATIVE</tt> (JR, Graupner etc.).<br/>With <tt>POSITIVE</tt> it will trigger on the rising flank to measure the time of the positive pulse, with <tt>NEGATIVE</tt> on the falling flank (for a negative pulse width).

Each channel is described with its transmitter name (<tt>ctl</tt>), its <tt>function</tt> name, its range in microseconds and its neutral value in microseconds.
These values are used by the autopilot to compute a normalized input from the PPM signal (this file is preprocessed and the produced code is included in the airborne code). Note that the <tt>min</tt> and <tt>max</tt> attributes can be exchanged to reverse the direction of the command.

'''Wrong attributes of the "radio" element will prevent the decoder to recognize any PPM frame; same for a wrong number or channels.'''

=== Number of channels ===

Note that the number of channels in your radio file <b>must exactly match</b> the number of channels in the ppm sum signal the autopilot receives.<br>
Also the ''function'' names must be unique.

* in case of analog 35MHz receivers it is the RC - TRANSMITTER that makes the pulse train (receiver only does RF part)
** radio file depends on transmitter, you could swap to another receiver (and e.g. you can use a 4channel receiver to receive 9 pulses :-) )
* in case of digital receivers it is not the transmitter but the receiver that makes the pulses
** e.g. Futaba Fasst 6017: you can use any compatible transmitter without need to change the radio file
* in case of an encoder it is the encoder that makes the summed pulse
** if the encoder software makes 8 pulses, even with a 5 channel RC connected paparazzi will get 8: so the radio file should read 8

This means if your transmitter sends for example a PPM18 (Graupner/JR) signal you have nine (9) different servo channels. Even if you use a receiver with less channels you must set up <b>all</b> transmitting servos, even if you do not use them then you must use "bogus switches" related to functions. For example a six (6) servo channels out receiver with five (5) functions used in combination with a nine (9) servo channels transmitter would need four (4) bogus entries. (5 + 4 = 9)

<source lang="xml">
...
<channel ctl="NoneA" function="NOTUSEDA" min="1100" neutral="1500" max="1900" average="0"/>
<channel ctl="NoneB" function="NOTUSEDB" min="1100" neutral="1500" max="1900" average="0"/>
<channel ctl="NoneC" function="NOTUSEDC" min="1100" neutral="1500" max="1900" average="0"/>
<channel ctl="NoneD" function="NOTUSEDD" min="1100" neutral="1500" max="1900" average="0"/>
...
</source>

=== Averaging ===

The <tt>average</tt> attribute must be set to '''1..x''' for ''discrete'' channels for which a trivial averaging filter will be applied. The neutral of a discrete channel need to be halfway through the min and max values. Otherwise it won't be mapped properly by the filter. Note that averaging a channel gives the output an additional small delay.

== Direction ==

The following signs have been used in the radio configuration files distributed in <tt>conf/radios</tt>:

* '''ROLL''': The <tt>min</tt> attribute value stands for the right position of the stick (turning right)
* '''PITCH''': The <tt>max</tt> attribute value stands for the up position of the stick (pitching up)

''' From "v3.9" on this has been changed to follow standard aerospace conventions:'''
* '''ROLL''': The <tt>max</tt> attribute value stands for the right position of the roll stick (banking right)
* '''PITCH''': The <tt>max</tt> attribute value stands for the "up" position of the pitch stick pulled towards you (pitching up)
* '''YAW''': The <tt>max</tt> attribute value stands for the right position of the yaw stick (yawing clock-wise)

=== Practical test ===
In the RC message:
* when the ROLL stick is pulled to the right (aircraft banks right), you should see a value close to -MAX_PPRZ (-9600) in the ROLL channel
* When the PITCH stick is pulled (aircraft pitches up), you should see a value close to MAX_PPRZ (9600) in the PITCH channel

''' From "v3.9" on this has been changed to follow standard aerospace conventions:'''
* when the ROLL stick is pulled to the right (aircraft banks right), you should see a value close to MAX_PPRZ (9600) in the ROLL channel
* When the PITCH stick is pulled (aircraft pitches up), you should see a value close to MAX_PPRZ (9600) in the PITCH channel
* When the YAW stick is pulled to the right (aircraft yawing clock-wise), you should see a value close to MAX_PPRZ (9600) in the YAW channel

This works with all kind of radios (PPM, USB, 2.4GHz)

== Example ==

Below you find an example of a radio file.

<source lang="xml">
<?xml version="1.0"?>





<radio name="GraupnerMC20" data_min="950" data_max="2150" sync_min="5000" sync_max="15000" pulse_type="NEGATIVE">
<channel ctl="A" function="THROTTLE" min="1100" neutral="1100" max="1900" average="0"/> 
<channel ctl="B" function="ROLL" min="1100" neutral="1500" max="1900" average="0"/> 
<channel ctl="C" function="PITCH" min="1900" neutral="1500" max="1100" average="0"/> 
<channel ctl="D" function="YAW" min="1100" neutral="1500" max="1900" average="0"/> 
<channel ctl="E" function="MODE" min="1100" neutral="1500" max="1900" average="1"/> 
<channel ctl="F" function="GAIN1" min="1100" neutral="1500" max="1900" average="0"/> 
<channel ctl="G" function="GAIN2" min="1100" neutral="1500" max="1900" average="0"/> 
<channel ctl="H" function="SWITCH1" min="1100" neutral="1500" max="1900" average="1"/> 
<channel ctl="I" function="UNUSED" min="1100" neutral="1500" max="1900" average="1"/> 
</radio>
</source>

== PPM input to output chain ==
The chain from ppm input to servo output has intermediate steps and roughly looks like this:

ppm input --(radio.xml)--> ppm_pulses[] --(radio.xml)--> radio_control.values[] --([[Fixedwing_Configuration#Manual|rc_commands]])--> commands[] --([[Fixedwing_Configuration#Servos|command_laws,servos]])--> actuators_pwm_values[] ppm out

Written in parenthesis is where you configure how to transform one value into the other.

So in a simple case without fancy mixing, e.g. looking at the roll command / aileron servo while in MANUAL mode:
#PPM sum signal is read and split into channels as specified in your radio xml file.<br/>It does some sanity checking on the pulse length and frame lenght according to the top attributes in that file.<br/>This is written to the ppm_pulses array, where you now have the length of the pulse in system ticks.
#Now these get converted to radio_control.values array according to the channels in your radio xml file.<br/>They get scaled to MAX_PPRZ (9600), meaning what you specified as max is 9600, neutral is 0, etc.<br/>radio_control.values[RADIO_ROLL] now has the value 9600 if the pulse width of that channels was "max"
#Mapping of RC commands to the actual commands as specified in rc_commands section.<br/>In your case simply copy radio_control.values[RADIO_ROLL] to commands[COMMAND_ROLL]
#Applying command_laws (mixing) to get the commands for each servo.<br/>Again just copying in your case...
#Scaling from commands with MAX_PPRZ scale to the actual pwm output signal according to the servos section.

== Measuring the PPM time values ==

[[Image:RC_Receiver_Timing_Diagram.jpg|thumb|R/C receiver timing diagram]]

There are two common ways to measure the time characteristics of the PPM signal:
# Using an oscilloscope: easy to achieve with a high level digital scope with capture and measure facilities.
# Using the telemetry of the autopilot: the '''PPM''' message (defined in <tt>conf/messages.xml</tt>) contains the sequence of a (recently) received PPM signal.

With the default telemetry configuration file (<tt>conf/telemetry/default_fixedwing.xml</tt>), this message is '''not''' sent in the '''default''' fbw telemetry mode (numbered 0).

There are two ways to enable this message:
* Use the settings mechanism to change the FBW telemetry mode while the autopilot is already running:<br/>In the GCS: Settings -> telemetry -> tele_FBW -> set to debug (1)
* This mode can be permanently changed to '''debug''' (numbered 1) in the airframe file by setting the '''TELEMETRY_MODE_FBW''' constant in your firmware section:
<source lang="xml"><define name="TELEMETRY_MODE_FBW" value="1"/></source>

'''Since "v3.9" the values in the PPM message are in µs.'''

Before "v3.9" the time unit used in this '''PPM''' message was hardware dependent:
* On the obsolete AVR hardware, 1 microsecond = 16 units (because the crystal is running at 16MHz)
* on the LPC hardware, 1 microsecond = 15 units (because the cristal is running at 12MHz)
*:(<tt>conf/autopilot/tiny.h</tt>), the CPU clock is 5 times more, the peripheral bus is 4 times less, and the timer is not prescaled (<tt>sw/airborne/arch/lpc21/mcu_periph/sys_time_arch.h</tt>) !!!)

== Tips ==

If one has a good servo tester the output values at the receiver side can be measured

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

Simulation

2016-04-17T10:47:42Z

Flixr: /* Available Simulators */

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

This page describes the steps needed to run a simulated flight with an UAS.

== Available Simulators ==

Paparazzi currently has two different simulator targets with different degrees of realism and intended purpose:

# '''sim''': The basic fixedwing simulator written in OCaml without IMU simulation or any sensor models (noise, bias, etc) and mainly intended to test [[Flight_Plans|flight plan]] logic.
# '''nps''': [[NPS]] is a more advanced rotorcraft and fixedwing simulator with sensor models and commonly uses [[JSBSim]] as FDM ('''F'''light '''D'''ynamic '''M'''odel). Other FDM's can be integrated easily. At the moment CRRCSIM, YASIM and JSBSIM are tried as FDM backend.

A FDM is a set of mathematical equations used to calculate the physical forces acting on a simulated aircraft, such as thrust, lift, and drag.

== Compiling and starting ==

'''This describes the basic fixedwing sim, for rotorcraft or advanced fixedwing simulation, see [[NPS]].'''

From the [[Paparazzi_Center|Paparazzi Center]] select the Microjet aircraft (from the '''A/C''' combo box) which is configured with the <tt>basic.xml</tt> flight plan. From the '''Target''' combo box, select <tt>sim</tt> and click the '''Build''' button to compile the airbone code to be run on your Linux box. From the '''Session''' combo box, select <tt>Simulation</tt> entry and click '''Execute''' to start the simulation. It will start
three processes which are listed in the window below:
* '''Microjet''' is the interface of a simulator program. It runs the same code as the one for the autopilot processor plus a rudimentary flight dynamic model. it allows you to test the interactions with the UAV and the flight plan execution.
* '''GCS''' ([[GCS|Ground Control Station]]) is the main window. It displays the track of the aircraft, as well as informations about the execution of its flight plans. This program provide menus for the datalink functions and is able to edit a flight plan.
* '''Server''' is a hidden process which won't be described here (see [[Overview|the architecture of the system]])

== Start the Simulation ==

The aircraft has automatically been booted, as if the autopilot board had been powered. Its position and its flight parameters are displayed in the GCS window. If you omit the -boot option of the sim the aircraft is not automatically booted and you can first place the aircraft where you want it to start from and then boot.

The map widget is able use many map formats and display them according to many projections. To make things simple, we start by using images from [http://maps.google.com Google]. From the toolbar in the top right corner of the GCS, click the Google Earth icon ('''Google maps fill'''). The program attempts to download the required satellite images from the Google servers. If it succeeds, you should now see the nice countryside of Muret (a city close to Toulouse, France). Navigation and other features of the map are described on the [[GCS#map|GCS]] page.

The lower part of the GCS displays the flight plan in a tree view. You see that the current flight plan is composed of several ''blocks'':
* '''wait GPS''' and '''geo init''' which are instructions to run this flight plan anywhere in the world, by translating the waypoints around the current location of aircraft as soon as it is reported by the GPS.
* '''Holding point''' (it should be the current active block) which instructs the autopilot to wait for launch.
* '''Takeoff''' which will instruct the aircraft to climb full throttle to a security altitude
* '''Standby''' which is a simple circle around the '''STDBY''' waypoint.

Switch to the '''Takeoff''' block by a double click on the line or using the corresponding button (an icon figuring an airway) on the left side of the strip.

== Fly ==

In the Simulator ('''Microjet''' window), press the '''Launch''' button to simulate a hand launch or click the launch button in the GCS (the green aircraft icon). The autopilot detects the launch by monitoring the groundspeed. The flight time (in the aircraft label on the GCS) then starts to count.

Position of the aircraft is displayed on the map: the aircraft goes to the '''CLIMB''' waypoint (to the norht-west) and then around the '''STDBY''' waypoint. Current block also changes accordingly in the flight plan display.

The orange triangle (the carrot) on the map is the point that the aircraft is navigating toward.

== Line ==

Jump to this block with double-click on the <tt>Line 1-2</tt> line in the flight plan or using the corresponding button in the strip (figuring a blue line between two white points). The aircraft will try to follow a line joining the waypoints '''1''' and '''2''', doing nice U-turns at both ends.

=== Move waypoints ===

While the aircraft is flying (or here while the simulator is integrating differential equations), you can move the waypoints on the GCS interface by cliking and dragging (with the left button). When the mouse button is released, a popup window allows you to change the altitude of the waypoint. After validation, the waypoint changes are sent to the autopilot and the followed track is changed accordingly.

=== Coming back around ===

Select the '''Standby''' block (the ''home'' blue icon) to instruct the aircraft to fly around the '''STDBY''' waypoint.

== Fly too far ==

If you unzoom the map (using the PageDown key or he mouse wheel), you will see a large circle around the waypoints. This circle show the allowed flying zone that the autopilot must not leave or it will enter an emergency navigation mode and circles the '''HOME''' waypoint until the further direction is received.

Move the waypoint '''2''' out of this circle (close to the circle in the north-east corner) and switch back to the 'Line 1-2''' block to force the plane to get out of this safety zone.

The aircraft flies to the '''2''' waypoint, cross the protection enveloppe and switches to ''home'' mode: the AP mode in the aircraft strip switches from '''AUTO2''' to '''HOME'''.

To get out of this mode and switch back to the default '''AUTO2''', click on the '''AUTO2''' button in the aircraft strip. The aircraft then flies again towards '''too far''' and again swithes to '''HOME''' mode.

== Change the environment ==

Launch the '''Environment Simulator''' from the '''Tools' menu in the '''Paparazzi Center'''.

[[file:PPRZ_Environment_settings_Gaia_GUI.png]]

This interface, also known as '''Gaia''', allows the user to change:

* The time-scale: This make the simulation of the flight speed up time, good if you have a extensive flightpland and you do not want to wait the real time it would taketo fly the aircraft in a real life flight. It is best not use a times-cale higher than 2x for a first tryout.
* The Wind speed: Set the wind speed while simulating. Try to set it to e.g. 5m/s and observe the trajectory and the speed evolution in the aircraft strip and in the '''PFD''' page of the notebook
* The Wind direction: Set the direction the wind comse from. For fun try to take of with stong wind from the side.
* A GPS failure: Simulate GPS loss on the aircraft ('''GPS OFF''') and observe the resulting mode ('''NO_GPS''') and trajectory. In this mode, the autopilot can for example use a the failsafe roll, pitch and throttle settings defined in the airframe file. Note that in a real flight, an aircraft without GPS won't be able to send it's position ... The simulation is cheating here! It must, otherwise not possible to show the path in the simulator ofcourse.

Environment Simulator, Gaia can aslo be started with initial values set by commandline option.

-b Bus Default is 127.255.255.255:2010
-t Set time scale (default: 1.0)
-w Set wind speed (0-30m/s)
-d Set wind direction 0-359 deg
-g Turn off GPS
-help Display this list of options
--help Display this list of options

If you are in the testfield and forgot the parameters, just use the "help"

$ ./gaia --help

This make testing more convieniet since on can save a session with this parameters and on restart imidately have the same settings again.

=== Example ===

Starting gaia with the following parameters on the command line:

$ sw/simulator/gaia -t 3 -d 340 -w 11

This sets a 3x speedup of the time with wind coming from 340 degrees with a windspeed of 11m/s

== Other navigation patterns ==

Using the buttons in the strip, you can play with other navigation patterns: figure of eights, oval, survey of a rectangle (with a north-south sweeping), ''Circle around here'' (which sets a waypoint to the current location of the plane and flies a circle around).

== Landing ==

To automatically land the aircraft:
* Set the '''TD''' (Touch Down) waypoint where you want to land. Be sure that the waypoint is on the ground (185m in Muret)
* Set the '''AF''' (Approach Fix) waypoint where you want to start the final descent (the ''glide''). If you have set some wind with Gaia, you probably want to fly '''AF-TD''' upwind (an estimation of the wind experienced by the aircraft is displayed in the left-upper corner of the map).
* Switch to the '''Land right''' or the '''Land left''' block (icons in the strip) according to the direction of the last turn you want to do (for example, if '''AF''' is on the east side of '''TD''' and you want to maneuvre from the north, choose a '''Land right''')

== Multiple UAV Simulation ==

To simulate multiple aircrafts, you just have to launch a second simulator (tools->simulator, then -a yourairframe) and the server and the GCS should take care of the rest.

== View the simulation in Flight Gear ==

To view the simulation in [[FlightGear]], do the following:
* [[FlightGear|install Flight Gear]]
* In Paparazzi Center, add the option <tt>--fg_host 127.0.0.1</tt> (replace the IP address if FG is running on another host as appropriate) to the Simulator line and restart it, e.g.:
<path_to_paparazzi>/sw/simulator/pprzsim-launch --aircraft <your_ac_name> -t sim --boot --norc --fg_host 127.0.0.1
<div class="toccolours mw-collapsible mw-collapsed">
Prior to '''v5.0''' launchsitl was used instead of pprzsim-launch. Click expand to see the details.
<div class="mw-collapsible-content">
<path_to_paparazzi>/sw/simulator/launchsitl -a <your_ac_name> -boot -norc -fg 127.0.0.1
</div></div>
* Launch Flight Gear with the following command:
fgfs --fdm=null --native-gui=socket,in,30,,5501,udp

=== Old version ===
For Flight Gear visualization, version 2.12 or greater with rembrand visualisation options switched on is the nicest. If you wish to use a very old version, Flightgear v2.4 or lower, you must add the following to the firmware section of your airframe file:
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
<define name="FG_2_4" value="1"/>
...
</firmware>
</source>
}}

[[Category:Simulation]] [[Category:Software]] [[Category:User_Documentation]]

Talk:Telemetry

2016-03-16T19:21:29Z

Flixr:

The add messages section seems to be out dated for version 5.8. The AIRSPEED messages are already implemented. I tried to get this working for a module I made following the instructions but it did not work. I think they need to be updated. Also the "find_free_msg_id.out" was replaced by *.ml script which I could not use. --[[User:Lethargi|Lethargi]]

Solution:
cd sw/tools
make
./find_free_msg_id.out

AR Drone 2

2016-03-14T22:31:11Z

Flixr: /* Autonomy */ ardrone2_sdk has been removed, use simply ardrone2

{|align=right
|-
|<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>AR Drone 2</categorytree>
|}

== Introduction ==

[[File:800px-Parrot_AR.Drone_2.JPG|thumb|300px|Parrot's AR Drone 2]] [[File:ARdrone_exploded.jpg|thumb|300px|Exploded view of the AR Drone 2.]]

So you have this nice Parrot AR.Drone 2.0 and would like to let it perform autonomous flights; You came to the right place. The only thing you need beside an AR.Drone 2.0, is an accurate GPS receiver and a laptop with [http://www.ubuntu.com/download/desktop Ubuntu Linux] OS installed.

Replace the current AR.Drone 2.0 brain by uploading paparazzi in current ARM chip and use the aready available sensors. Connect a GPS on the USB port, use Wifi for telemetry and optional manal control.

No soldering or other modifications in the electronics to make. Only with Paparazzi software and a GPS receiver it is possible to let the AR.Drone 2.0 fly autonomous missions under spectacular better control than the original onboard control.

...as simple as that, have fun and try it for yourself...

=== Help ===

Paparazzi is a very mature project that has existed since 2003. So your questions concerning paparazzi have possibly already been asked and answered on theso called "mailing list". It would be best to first read through the [http://lists.gnu.org/archive/html/paparazzi-devel/ mailinglist ]. If the answer is not there please ask your question on this mailinglist or maybe even via the IRC channel [http://paparazzi.enac.fr/wiki/Main_Page icons on the top of main page]. You will find your question is likely addressed within hours or days. Paparazzi is a global project so in most cases somewhere in the world someone is reading your email/question and will reply.

=== History ===

On September 3rd 2012 two Delft University of Technology student teams started a new UAV robotics project under the guidance of [mailto:microuav@gmail.com ing. ir. B. D. W. Remes]. Both teams shared a similar objective, namely getting the AR Drone v2.0 to fly autonomously using the advanced opensource Paparazzi Software.

{{#ev: youtubehd|oX423smmPEc}}

=== Easy ===

When you have finished you autonomous flight with paparazzi and want to fly with the standard [http://ardrone2.parrot.com/apps/| ARDrone2 apps], just unplugging and re-plugging the battery will make your drone a standard ARDrone2 again.

== The Hardware ==

[[File:Ardrone2_snow.gif|320pxleft|AR.Drine 2.0]]

First some generic information about the airframe hardware just to satisfy curiosity.

=== HD Video recording ===

Get high definition live video streaming to your smartphone or tablet as you are flying. See a clean, sharp image just as if you were in the pilot seat.

* HD Camera. 720p 30fps
* Wide angle lens : 92° diagonal
* H264 encoding base profile
* Low latency streaming
* Video storage on the fly with the remote device
* JPEG photo
* Video storage on the fly with Wi-Fi directly on your remote device or on a USB key

=== Robust structure ===

Trying your most daring tricks won’t even challenge this cutting edge design which is made to last.

* Carbon fiber tubes : Total weight 380g with outdoor hull, 420g with indoor hull
* High grade 30% fiber charged nylon plastic parts
* Foam to isolate the inertial center from the engines’ vibration
* EPP hull injected by a sintered metal mold
* Liquid Repellent Nano-Coating on ultrasound sensors
* Fully reparable: All parts and instructions for repairing available on the internet

=== Electronic assistance ===

AR.Drone 2.0 on-board technology gives you extreme precision control and automatic stabilization features.

* 1GHz 32 bit ARM Cortex A8 processor with 800MHz video DSP TMS320DMC64x
* Linux 2.6.32
* 1Gbit DDR2 RAM at 200MHz
* USB 2.0 high speed for extensions
* Wi-Fi b,g,n
* 3 axis gyroscope 2000°/second precision
* 3 axis accelerometer +-50mg precision
* 3 axis magnetometer 6° precision
* Pressure sensor +/- 10 Pa precision
* Ultrasound sensors for ground altitude measurement
* 60 fps vertical QVGA camera for ground speed measurement

=== Motor ===

Fly high. Fly fast. Far away from the ground.

* 4 brushless inrunner motors. 14.5W 28,500 RMP
* Micro ball bearing
* Low noise Nylatron gears for 1/8.75 propeller reductor
* Tempered steel propeller shaft
* Self-lubrificating bronze bearing
* Specific high propelled drag for great maneuverability
* 8 MIPS AVR CPU per motor controller
* 3 elements 1000 mA/H LiPo rechargeable battery (Autonomy: 12 minutes)
* Emergency stop controlled by software
* Fully reprogrammable motor controller
* Water resistant motor’s electronic controller

== Autopilot ==

[[File:ardrone2_mainboard.jpg|320pxleft|AP Mainboard]]

The main board in the AR.Drone 2.0 '''IS''' the autopilot

== GPS ==

To fly autonomous to a certain geo coordinate a GPS is needed. Although it is theoretically possible to use the original orange Parrot GPS dongle it is not advised, the performance is just not good enough for great autonomous flights. The solution that '''is advised''' is to use an '''uBlox GPS''' module.

See [[AR_Drone_2/GPS]] for details.

== Installation ==

=== Prerequisites ===

To be able to fly your AR.Drone 2.0 you need '''ARDrone2 firmware v2.4.8''' or higher on your ARDrone. And for your Paparazzi GCS laptop it's best to have Ubuntu Linux v14.04 LTS or higher installed

Go to the [[AR_drone_2/Software_installation|Operating System and Paparazzi Installation page]] to follow instructions to install the operating system and Paparazzi.

If you followed the [[AR_drone_2/Software_installation|Operating System and Paparazzi Installation page]] you now have a working fresh install of Ubuntu v12.04 or v14.04 operating system on your Wifi enabled laptop. Newer versions of Ubuntu '''might''' work as well, only are never tried at the time of writing.

Note: the above is simply one long command to the Linux command interpreter. The && are simply saying if the command to the left returns successful return code then run the command on the right .. and so on. So if the command fails the rest of the commands to the right will not be executed. It maybe helpful then to simply copy/paste each command one at a time. Just grab between the '&&'

== Autonomy ==

[[Image:GCSParrotardroneandpaparazzi.jpg|Right|570px|GCS for Paparazzi Parrot AR.Drone 2.0]]

To give your ARDrone2 the autonomy essential for autonomous flight, the Paparazzi Control Center needs to be started by clicking on the paparazzi icon on your desktop (see installing paparazzi Wiki details).

[[Image:Paparazzi_installed.png|500px]]

'''Terminal''' at the terminal, just cut 'n paste the line below, in your terminal command prompt, then press enter

~/paparazzi/paparazzi

Paparazzi Center will launch for the very first time and show you a screen like this:

[[Image:1_first_paparazzi_center_start.png|Paparazzi Center first start]]

Now that you have Paparazzi Center running grab your ARDrone2 to set it up for autonomous flight:

# Insert the GPS module into your ARDrone2 and power it up by connecting the battery.
# Establish a Wifi connection between the ARDrone2 and your laptop
[[Image:1.1_select_ardrone2_in_list.png|500px|Select ardrone2_v2.4.3 in Wireless Network List]]
[[Image:1.2_connected_to_ardrone2.png|400px|Your AR.Drone2 is now connected]]

At this moment it is important that you have an ARDrone2 that has it's GPS device connected and has established a Wifi connection with your computer. You can now continue uploading the Autopilot to the ARDrone2.

# At Paparazzi Center select ''ardrone2'' at the "A/C" drop-down box

[[Image:2_choose_ardrone2_sdk_from_ac_dropdown.png|Choose ardrone2 from A/C selection]]

# Make sure "ap" (Autopilot) is set as Target
# Press the [Upload] button (NOTE: It will show 3 ignored errors, that's fine, don't worry...)

[[Image:3_press_upload.png|Press Upload]]

# now in In the Paparazzi control center Select ''Flight UDP/Wifi'' as session

[[Image:4_select_ardrone_flight_session.png|Select "Flight UDP/Wifi" as session]]

# Press the [Execute] button

[[Image:5_press_execute.png|Press Execute]]

== Flying ==

Take your AR Drone and laptop outside. A clear view of the sky is essential for GPS to work properly. A good GPS position signal is necessary for optimal autonomous flight. However GPS is only accurate to within several meters, so make sure you have enough of free space around to let it fly without bumping into something.

After waiting for about a minute a GPS signal will be found. The ARDrone2 location should now appear in your GCS map

[[Image:GCSParrotardroneandpaparazzi.jpg|300px|GCS for Paparazzi Parrot AR.Drone 2.0]]

When you fly the first time on this spot you need to download the Google map tiles on to your laptop. Connect your wifi to your wireless router, when you have connection click on the black GCS map. Once downloaded the tiles are saved so you will not need an Internet connection next time. You can also run the GCS in advance, get the tiles, and later fly without an Internet connection.

[[Image:Paparazzi_GCS_Ardrone_layout_NoWifiNoTelemetryConnectionOrNoTilesDownloaded.jpg|300px|GCS for Paparazzi Parrot AR.Drone 2.0]]

and press the keyboard key combination [CTRL+G]. You will see the map appear. When you are done downloading the tiles re-connect to you drone.

[[Image:GCSParrotardroneandpaparazzi.jpg|300px|GCS for Paparazzi Parrot AR.Drone 2.0]]

If no Wifi connection is availabe from your laptop to the ARDRone2, you will have a blank screen. That is perfectly normal. Just make sure you make a Wifi connection to your AR drone first.

=== Takeoff===

# Press the [Takeoff] button and keep a good eye on where your Drone flies.

[[Image:GCSParrotardroneandpaparazziTakeoff.jpg|200|Takeoff Paparazzi Parrot AR.Drone 2.0]]

When all worked out well the drone took off, followed a line back and forth and landed again, congratulations you made your first autonomous flight!

=== Move waypoints===

To have some fun with your AR.Drone 2.0 in flight, one could move the ''standby'' waypoint to another location close by.

=== Home ===
Home: Let the ARDrone come back where you took off

[[Image:GCSParrotardroneandpaparazziHome.jpg|200|Home Paparazzi Parrot AR.Drone 2.0]]

=== Land ===
Land: Land the drone where you took off

[[Image:GCSParrotardroneandpaparazziLAnd.jpg|200px|LAnd Paparazzi Parrot AR.Drone 2.0]]

== Next steps ==

Now that your Parrot AR.Drone 2.0 flew autonomously you can dive deeper into the world Paparazzi and it's [[Flight_Plans]]. Just browse around this Wiki and read and try things that interest you the most, have fun!

== Experts==

After you have now experienced your first feeling of quite some autonomous flights with your Paparazzi controlled UAV you might want to become an expert on the AR.Drone 2.0.
Read on below to be able learn, change and create great new things...

== Sign conventions ==

This section will show the sign conventions used by the SDK of the Parrot AR.Drone 2.0. One can read these values directly from the AR.Drone software. This is a good refference also fro the PPRZ version.

=== Body axis ===

[[File:body axis convention.jpg|thumb|right|350px|Body axis convention]]

Relevant units:

* Velocities in x,y,z (Vx, Vy, Vz [mm/s])
* Accelerations in x,y,z (Ax, Ay, Az [mg])
* Position in z (altitude [mm])

=== Angles ===

[[File:roll convention.jpg|150px|Roll convention]]
[[File:pitch convention.jpg|150px|Pitch convention]]
[[File:yaw convention.jpg|150px|Yaw convention]]

Relevant units:
* Angles psi (yaw), phi (roll), theta (pitch) [mdeg]
* Rates p (roll rate), q (pitch rate), r (yaw rate) [deg/s]
<br>

<br>

<br>

== Simulation ==

=== Introduction ===

This page will guide you through the creation of the mechanical model with JSBSim for Paparazzi.

=== Setting up the simulation environment ===

See [[Setting up simulation environment]].

=== Creating the mechanical model ===

Not every feature of the JSMSim model is needed for Paparazzi. Below is a list of features that should be included in the .xml file.

* Header
* Metrics
* Mass balance
* Ground reactions
* Propulsion

=== Example .xml file ===

This section displays a standard .xml file, with some added comments per segment. For a more extensive guide on JSBSim read the extensive [http://jsbsim.sourceforge.net/JSBSimReferenceManual.pdf JSBSim manual]

'''<fileheader>'''
<author> "Name of author" </author>
<filecreationdate> "Date of creation" </filecreationdate>
<version> "Version" </version>
<description> "Description" </description>
''' </fileheader> '''

==== Metrics ====
Metrics

'''<metrics>'''
<wingarea unit="IN2"> 0 </wingarea>
<wingspan unit="IN"> 0 </wingspan>
<chord unit="IN"> 0 </chord>
<htailarea unit="FT2"> 0 </htailarea>
<htailarm unit="FT"> 0 </htailarm>
<vtailarea unit="FT2"> 0 </vtailarea>
<vtailarm unit="FT"> 0 </vtailarm>
<location name="AERORP" unit="IN">
<x> 0 </x>
<y> 0 </y>
<z> 0 </z>
</location>
<location name="EYEPOINT" unit="IN">
<x> 0 </x>
<y> 0 </y>
<z> 0 </z>
</location>
<location name="VRP" unit="IN">
<x> 0 </x>
<y> 0 </y>
<z> 0 </z>
</location>
'''</metrics>'''

==== Mass balance ====

''' <mass_balance>'''
<ixx unit="SLUG*FT2"> 0.1 </ixx>
<iyy unit="SLUG*FT2"> 0.1 </iyy>
<izz unit="SLUG*FT2"> 0.2 </izz>
<ixy unit="SLUG*FT2"> 0. </ixy>
<ixz unit="SLUG*FT2"> 0. </ixz>
<iyz unit="SLUG*FT2"> 0. </iyz>
<emptywt unit="LBS"> 1 </emptywt>
<location name="CG" unit="M">
<x> 0 </x>
<y> 0 </y>
<z> 0 </z>
</location>
'''</mass_balance>'''

==== Ground reactions ====

This section creates contact points with the ground for the AR.Drone 2.0. The ground reactions were designed with aircraft wheels in mind. Therefore, the specifications and locations of the ground reactions do not really matter, due to the vertical take-off the quadrotor.

'''<ground_reactions>'''
<contact type="STRUCTURE" name="CONTACT_FRONT">
<location unit="M">
<x>-0.15 </x>
<y> 0 </y>
<z>-0.1 </z>
</location>
<static_friction> 0.8 </static_friction>
<dynamic_friction> 0.5 </dynamic_friction>
<spring_coeff unit="N/M"> 500 </spring_coeff>
<damping_coeff unit="N/M/SEC"> 100 </damping_coeff>
<damping_coeff_rebound type="SQUARE" unit="N/M2/SEC2"> 1000 </damping_coeff_rebound>
<max_steer unit="DEG"> 0.0 </max_steer>
<brake_group> NONE </brake_group>
<retractable>0</retractable>
</contact>

<contact type="STRUCTURE" name="CONTACT_BACK">
<location unit="M">
<x> 0.15</x>
<y> 0 </y>
<z>-0.1 </z>
</location>
<static_friction> 0.8 </static_friction>
<dynamic_friction> 0.5 </dynamic_friction>
<spring_coeff unit="N/M"> 500 </spring_coeff>
<damping_coeff unit="N/M/SEC"> 100 </damping_coeff>
<damping_coeff_rebound type="SQUARE" unit="N/M2/SEC2"> 1000 </damping_coeff_rebound>
<max_steer unit="DEG"> 0.0 </max_steer>
<brake_group> NONE </brake_group>
<retractable>0</retractable>
</contact>

<contact type="STRUCTURE" name="CONTACT_RIGHT">
<location unit="M">
<x> 0. </x>
<y> 0.15</y>
<z>-0.1 </z>
</location>
<static_friction> 0.8 </static_friction>
<dynamic_friction> 0.5 </dynamic_friction>
<spring_coeff unit="N/M"> 500 </spring_coeff>
<damping_coeff unit="N/M/SEC"> 100 </damping_coeff>
<damping_coeff_rebound type="SQUARE" unit="N/M2/SEC2"> 1000 </damping_coeff_rebound>
<max_steer unit="DEG"> 0.0 </max_steer>
<brake_group> NONE </brake_group>
<retractable>0</retractable>
</contact>

<contact type="STRUCTURE" name="CONTACT_LEFT">
<location unit="M">
<x> 0. </x>
<y>-0.15</y>
<z>-0.1 </z>
</location>
<static_friction> 0.8 </static_friction>
<dynamic_friction> 0.5 </dynamic_friction>
<spring_coeff unit="N/M"> 500 </spring_coeff>
<damping_coeff unit="N/M/SEC"> 100 </damping_coeff>
<damping_coeff_rebound type="SQUARE" unit="N/M2/SEC2"> 1000 </damping_coeff_rebound>
<max_steer unit="DEG"> 0.0 </max_steer>
<brake_group> NONE </brake_group>
<retractable>0</retractable>
</contact>
'''</ground_reactions>'''

The full configuration and Flight Dynamics Model (FDM) files to fly the AR.Drone autonomously in JSBsim. A very thorough [http://jsbsim.sourceforge.net/JSBSimReferenceManual.pdf JSBSIM reference manual] can be found on the JSBSIM documentation page, in creating the .xml configuration file the team followed this manual closely.

=== AR.Drone.xml ===

'''FileHeader'''

The configuration file will be prefixed with a FileHeader that includes information such as author, contact information, notes, dates, descriptions, and references.
''' <fileheader> '''
<author> "Name of author" </author>
<filecreationdate> "Date of creation" </filecreationdate>
<version> "Version" </version>
<description> "Description" </description>
''' </fileheader> '''

'''Metrics'''

The start of the configuration file will be the physical characteristics of the AR.Drone2, in essence, those static measurements of the aircraft (e.g. weight, wing area, control surface arms, etc.). The values for the wing area and wingspan were measured off of the actual model, measured using a CAD model of the drone, and using official figures found online. It was concluded that all of these values were the same thus it was fairly certain that the figures found were correct.
'''<metrics>'''
<wingarea unit="IN2"> 0 </wingarea>
<wingspan unit="IN"> 0 </wingspan>
<chord unit="IN"> 0 </chord>
<htailarea unit="FT2"> 0 </htailarea>
<htailarm unit="FT"> 0 </htailarm>
<vtailarea unit="FT2"> 0 </vtailarea>
<vtailarm unit="FT"> 0 </vtailarm>
<location name="AERORP" unit="IN">
<x> 0 </x>
<y> 0 </y>
<z> 0 </z>
</location>
<location name="EYEPOINT" unit="IN">
<x> 0 </x>
<y> 0 </y>
<z> 0 </z>
</location>
<location name="VRP" unit="IN">
<x> 0 </x>
<y> 0 </y>
<z> 0 </z>
</location>
'''</metrics>'''

'''Mass Balance'''

Building upon the metrics of the aircraft, the Mass Balance sections is where the center of gravity and moment of inertia are defined.
''' <mass_balance>'''
<ixx unit="SLUG*FT2"> 0.1 </ixx>
<iyy unit="SLUG*FT2"> 0.1 </iyy>
<izz unit="SLUG*FT2"> 0.2 </izz>
<ixy unit="SLUG*FT2"> 0. </ixy>
<ixz unit="SLUG*FT2"> 0. </ixz>
<iyz unit="SLUG*FT2"> 0. </iyz>
<emptywt unit="LBS"> 1 </emptywt>
<location name="CG" unit="M">
<x> 0 </x>
<y> 0 </y>
<z> 0 </z>
</location>
'''</mass_balance>'''

'''Ground Reactions'''

The points of contact which the aircraft has with the ground are defined in the Ground Reactions section of the configuration file.
'''<ground_reactions>'''
<contact type="STRUCTURE" name="CONTACT_FRONT">
<location unit="M">
<x>-0.15 </x>
<y> 0 </y>
<z>-0.1 </z>
</location>
<static_friction> 0.8 </static_friction>
<dynamic_friction> 0.5 </dynamic_friction>
<spring_coeff unit="N/M"> 500 </spring_coeff>
<damping_coeff unit="N/M/SEC"> 100 </damping_coeff>
<damping_coeff_rebound type="SQUARE" unit="N/M2/SEC2"> 1000 </damping_coeff_rebound>
<max_steer unit="DEG"> 0.0 </max_steer>
<brake_group> NONE </brake_group>
<retractable>0</retractable>
</contact>

<contact type="STRUCTURE" name="CONTACT_BACK">
<location unit="M">
<x> 0.15</x>
<y> 0 </y>
<z>-0.1 </z>
</location>
<static_friction> 0.8 </static_friction>
<dynamic_friction> 0.5 </dynamic_friction>
<spring_coeff unit="N/M"> 500 </spring_coeff>
<damping_coeff unit="N/M/SEC"> 100 </damping_coeff>
<damping_coeff_rebound type="SQUARE" unit="N/M2/SEC2"> 1000 </damping_coeff_rebound>
<max_steer unit="DEG"> 0.0 </max_steer>
<brake_group> NONE </brake_group>
<retractable>0</retractable>
</contact>

<contact type="STRUCTURE" name="CONTACT_RIGHT">
<location unit="M">
<x> 0. </x>
<y> 0.15</y>
<z>-0.1 </z>
</location>
<static_friction> 0.8 </static_friction>
<dynamic_friction> 0.5 </dynamic_friction>
<spring_coeff unit="N/M"> 500 </spring_coeff>
<damping_coeff unit="N/M/SEC"> 100 </damping_coeff>
<damping_coeff_rebound type="SQUARE" unit="N/M2/SEC2"> 1000 </damping_coeff_rebound>
<max_steer unit="DEG"> 0.0 </max_steer>
<brake_group> NONE </brake_group>
<retractable>0</retractable>
</contact>

<contact type="STRUCTURE" name="CONTACT_LEFT">
<location unit="M">
<x> 0. </x>
<y>-0.15</y>
<z>-0.1 </z>
</location>
<static_friction> 0.8 </static_friction>
<dynamic_friction> 0.5 </dynamic_friction>
<spring_coeff unit="N/M"> 500 </spring_coeff>
<damping_coeff unit="N/M/SEC"> 100 </damping_coeff>
<damping_coeff_rebound type="SQUARE" unit="N/M2/SEC2"> 1000 </damping_coeff_rebound>
<max_steer unit="DEG"> 0.0 </max_steer>
<brake_group> NONE </brake_group>
<retractable>0</retractable>
</contact>
'''</ground_reactions>'''

'''Propulsion'''

Each of the four motors is defined in the Propulsion section.
'''<propulsion>
<engine file="eng_150w" name="front left">
<location unit="M">
<x> -0.2 </x>
<y> 0.2 </y>
<z> 0.0 </z>
</location>
<orient unit="DEG">
<pitch> 90.00 </pitch>
<roll> 0.00 </roll>
<yaw> 0.00 </yaw>
</orient>
<feed>0</feed>
<thruster file="18x8">
<location unit="M">
<x> -0.2 </x>
<y> 0.2 </y>
<z> 0.025 </z>
</location>
<orient unit="DEG">
<pitch> 90.00 </pitch>
<roll> 0.00 </roll>
<yaw> 0.00 </yaw>
</orient>
<sense> 1 </sense>
<p_factor> 10 </p_factor>
</thruster>
</engine>
<engine file="eng_150w" name="front right">
<location unit="M">
<x> 0.2 </x>
<y> 0.2 </y>
<z> 0.0 </z>
</location>
<orient unit="DEG">
<pitch> 90.00 </pitch>
<roll> 0.00 </roll>
<yaw> 0.00 </yaw>
</orient>
<feed>0</feed>
<thruster file="18x8">
<location unit="M">
<x> 0.2 </x>
<y> 0.2 </y>
<z> 0.025 </z>
</location>
<orient unit="DEG">
<pitch> 90.00 </pitch>
<roll> 0.00 </roll>
<yaw> 0.00 </yaw>
</orient>
<sense> 1 </sense>
<p_factor> 10 </p_factor>
</thruster>
</engine>
<engine file="eng_150w" name="rear left">
<location unit="M">
<x> -0.2 </x>
<y> -0.2 </y>
<z> 0.0 </z>
</location>
<orient unit="DEG">
<pitch> 90.00 </pitch>
<roll> 0.00 </roll>
<yaw> 0.00 </yaw>
</orient>
<feed>0</feed>
<thruster file="18x8">
<location unit="M">
<x> -0.2 </x>
<y> -0.2 </y>
<z> 0.025 </z>
</location>
<orient unit="DEG">
<pitch> 90.00 </pitch>
<roll> 0.00 </roll>
<yaw> 0.00 </yaw>
</orient>
<sense> -1 </sense>
<p_factor> 10 </p_factor>
</thruster>
</engine>
<engine file="eng_150w" name="rear right">
<location unit="M">
<x> 0.2 </x>
<y> -0.2 </y>
<z> 0.0 </z>
</location>
<orient unit="DEG">
<pitch> 90.00 </pitch>
<roll> 0.00 </roll>
<yaw> 0.00 </yaw>
</orient>
<feed>0</feed>
<thruster file="18x8">
<location unit="M">
<x> 0.2 </x>
<y> -0.2 </y>
<z> 0.025 </z>
</location>
<orient unit="DEG">
<pitch> 90.00 </pitch>
<roll> 0.00 </roll>
<yaw> 0.00 </yaw>
</orient>
<sense> -1 </sense>
<p_factor> 10 </p_factor>
</thruster>
</engine>
<tank type="FUEL" number="0">
<location unit="M">
<x> 0.00 </x>
<y> 0.00 </y>
<z> -0.07 </z>
</location>
<capacity unit="KG"> 0.480 </capacity>
<contents unit="KG"> 0.480 </contents>
</tank>
'''</propulsion>'''

'''Flight Control'''

'''<flight_control name="FCS: quad-copter">'''
<channel name="Control Input">
<summer name="Pitch Command Sum">
<input>fcs/elevator-cmd-norm</input>
<input>fcs/pitch-trim-cmd-norm</input>
<clipto>
<min>-1</min>
<max>1</max>
</clipto>
</summer>
<summer name="Roll Command Sum">
<input>fcs/aileron-cmd-norm</input>
<input>fcs/roll-trim-cmd-norm</input>
<clipto>
<min>-1</min>
<max>1</max>
</clipto>
</summer>
<summer name="Yaw Command Sum">
<input>fcs/rudder-cmd-norm</input>
<input>fcs/yaw-trim-cmd-norm</input>
<clipto>
<min> -1 </min>
<max> 1 </max>
</clipto>
</summer>
</channel>
<channel name="Power">
<fcs_function name="Power FWD">
<function>
<sum>
<product>
<property>fcs/throttle-cmd-norm[0]</property>
<value>0.58</value>
</product>
<product>
<property>fcs/roll-command-sum</property>
<value>0.0</value>
</product>
<product>
<property>fcs/pitch-command-sum</property>
<value>-0.28</value>
</product>
<product>
<property>fcs/yaw-command-sum</property>
<value>-0.14</value>
</product>
</sum>
<clipto>
<min>0</min>
<max>1</max>
</clipto>
</function>
<output>fcs/throttle-pos-norm[0]</output>
</fcs_function>
<fcs_function name="Power Aft">
<function>
<sum>
<product>
<property>fcs/throttle-cmd-norm[1]</property>
<value>0.58</value>
</product>
<product>
<property>fcs/roll-command-sum</property>
<value>0.0</value>
</product>
<product>
<property>fcs/pitch-command-sum</property>
<value>0.28</value>
</product>
<product>
<property>fcs/yaw-command-sum</property>
<value>-0.14</value>
</product>
</sum>
<clipto>
<min>0</min>
<max>1</max>
</clipto>
</function>
<output>fcs/throttle-pos-norm[1]</output>
</fcs_function>
<fcs_function name="Power Left">
<function>
<sum>
<product>
<property>fcs/throttle-cmd-norm[2]</property>
<value>0.58</value>
</product>
<product>
<property>fcs/roll-command-sum</property>
<value>-0.28</value>
</product>
<product>
<property>fcs/pitch-command-sum</property>
<value>0.0</value>
</product>
<product>
<property>fcs/yaw-command-sum</property>
<value>0.14</value>
</product>
</sum>
<clipto>
<min>0</min>
<max>1</max>
</clipto>
</function>
<output>fcs/throttle-pos-norm[2]</output>
</fcs_function>
<fcs_function name="Power Right">
<function>
<sum>
<product>
<property>fcs/throttle-cmd-norm[3]</property>
<value>0.58</value>
</product>
<product>
<property>fcs/roll-command-sum</property>
<value>0.28</value>
</product>
<product>
<property>fcs/pitch-command-sum</property>
<value>0.0</value>
</product>
<product>
<property>fcs/yaw-command-sum</property>
<value>0.14</value>
</product>
</sum>
<clipto>
<min>0</min>
<max>1</max>
</clipto>
</function>
<output>fcs/throttle-pos-norm[3]</output>
</fcs_function>
</channel>
'''</flight_control>'''

'''Aerodynamics'''
'''<aerodynamics>'''
<axis name="LIFT">
</axis>
<axis name="DRAG">
<function name="aero/coefficient/CD0">
<description>Overall Drag</description>
<product>
<property>aero/qbar-psf</property>
<property>metrics/Sw-sqft</property>
<value>1</value>
</product>
</function>
</axis>
<axis name="SIDE">
</axis>
<axis name="ROLL">
</axis>
<axis name="PITCH">
</axis>
<axis name="YAW">
</axis>
'''</aerodynamics>'''

=== AR.Drone-set.xml ===
The set .xml file is used by Flightgear for the simulation of the aircraft and sees no further use by JSBSIM for the creation of the FDM. All variables and settings within this particular .xml file are implemented in the drone simulation (e.g. sounds, sights, systems, etc.). A CAD model of the drone is also used herein for visual representation. The model was animated in the [http://www.blender.org/ Blender] open-source 3D computer graphics software. Therein it was imported as a .stl file from a CAD editor and exported as a .ac file which Flightgear could implement as a visual during simulation. At the time of writing this was the most straightforward method for importing and exporting the model although it required the implementation of an additional python script. These import and export features will soon be default in Blender distributions.

'''Simulation and Visuals'''

An autopilot system is used during the simulation; the autopilot system is from the Malolo1 DIY Drones ArduPlane repository on Google Code, it can be found in full [http://code.google.com/p/ardupilot-mega/source/browse/Tools/autotest/aircraft/Rascal/Systems/110-autopilot.xml?name=ArduCopter-2.5 here]. The code for the Malolo1 is distributed, free of costs, under the GNU General Public License. It was implemented in the Flightgear simulation of the AR.Drone2 as a reliable autopilot system to maintain stable flight. When implementing it in your own code take special care to ensure that all paths and directories are appropriate for your own project.

<sim>
<description> Parrot AR.Drone 2.0 </description>
<author> Author </author>
<aircraft-version> 0.0 </aircraft-version>
<status> beta version </status>
<flight-model>jsb</flight-model>
<aero>AR.Drone</aero>
<systems>
<autopilot>
<path>Aircraft/Malolo1/Systems/110-autopilot.xml</path>
</autopilot>
<electrical>
<path>Aircraft/Malolo1/Systems/electrical.xml</path>
</electrical>
</systems>
<sound>
<path>Aircraft/Generic/generic-sound.xml</path>
</sound>
<panel>
<visibility archive="n">false</visibility>
</panel>
<model>
<path archive="y">Aircraft/AR.Drone/Models/visualmodels.xml</path>
</model>
<view>
<internal archive="y">true</internal>
<config>
<x-offset-m archive="y">0.0</x-offset-m>
<y-offset-m archive="y">0.15</y-offset-m>
<z-offset-m archive="y">0.90</z-offset-m>
<pitch-offset-deg>0</pitch-offset-deg>
</config>
</view>
<chase-distance-m archive="y" type="double">-5.5</chase-distance-m>
<help>
<title> Parrot AR.Drone </title>
</help>
</sim>

'''Controls, Consumables, Payload, and Nasal'''
<controls>
<flight>
<aileron-trim>0.00</aileron-trim> 
<elevator-trim>0.00</elevator-trim> 
</flight>
</controls>
<consumables>
<fuel>
<tank n="0">
<level-gal_us>0.1667</level-gal_us>
</tank>
</fuel>
</consumables>
<payload>
<weight>
<name type="string">Payload</name>
<weight-lb alias="/fdm/jsbsim/inertia/pointmass-weight-lbs[0]"/>
<min-lb type="double">0.0</min-lb>
<max-lb type="double">1.0</max-lb>
</weight>
</payload>
<nasal>
<AR.Drone>
<script>
setlistener("/sim/signals/fdm-initialized", func {
var left = screen.display.new(20, 10);
left.add("/fdm/jsbsim/fcs/throttle-pos-norm[0]");
left.add("/fdm/jsbsim/fcs/throttle-pos-norm[1]");
left.add("/fdm/jsbsim/fcs/throttle-pos-norm[2]");
left.add("/fdm/jsbsim/fcs/throttle-pos-norm[3]");
left.add("/orientation/pitch-deg");
var right = screen.display.new(-250, 20);
right.add("/fdm/jsbsim/moments/l-prop-lbsft");
right.add("/fdm/jsbsim/moments/m-prop-lbsft");
right.add("/fdm/jsbsim/moments/n-prop-lbsft");
});
</script>
</AR.Drone>
</nasal>

== Flightgear ==

This section will explain the installation of FlightGear and the creation of an visual model for Flightgear.

[[Image:Flightgear Screenshot indoor.png|thumb|right|400px|An example AR.Drone flying in FlightGear]]

=== Download FlightGear ===

FlightGear can be downloaded from http://www.flightgear.org/download/ . Installation should be self-explanatory. The aircraft models will be located in: (...\FlightGear\Data\Aircraft).

=== Visual model ===

Flightgear uses .ac files from the AC3D program, a 3D design program by Inivis[http://www.inivis.com/]. A free alternative is Blender[http://www.blender.org/], which can export its files to the .ac format with a plugin[http://wiki.blender.org/index.php/Extensions:2.4/Py/Scripts/Export/AC3D] (instructions on how to install also found in link).

Our minor group used an existing model[http://grabcad.com/library/ar-drone-parrot], (registering required), which we exported to .stl in Autodesk. Then we imported the .stl files with Blender, and exported them again in the required .ac format.

==== Moving parts ====

To use animated moving parts in the model, all the moving parts have to be exported individually. All parts are linked together by the model's set file.

== Setting up the folder ==
Inside your aircraft folder (...\FlightGear\Data\Aircraft\"Aircraft name"), a .xml file is needed to enable Flightgear to load the model. This file should be named as: "Aircraft name"-set.xml. Inside, it links to main visual model file. All visual model files should go into the "Models" folder of the aircraft: (...\FlightGear\Data\Aircraft\"Aircraft name"\Models). The main .xml file should indicate the lay-out of the model (see Example files).

==== Clarification of the .xml files ====
main.xml:

The .ac file contains the body model of the quadrotor:
<path>myquadrotor.ac</path>

The 4 <model> nodes contain information about the location and orientation of the propellors. The <path> links to the location of the engine file. The <offsets> manually places the propellors in (about) the right place. This has no consequences for the performance of the aircraft. For the FlightGear coordinate system, see: [http://www.city-gallery.com/knoblock/projects/flightgear/Docs/coords.html]. The <pitch/yaw/roll-deg> can be used if the imported file has the wrong orientation.

<model>

<name>Engine1</name>
<path>Aircraft/myquadrotor/Models/engine1.xml</path>
<offsets>
<x-m>0.3</x-m>
<y-m>-0.2</y-m>
<z-m>0.0</z-m>
<pitch-deg>0</pitch-deg>
</offsets>
</model>

Using <offsets> the orientation of the model was corrected:

<offsets>
<heading-deg>270</heading-deg>
</offsets>

engine1.xml:

Contains the model of the rotor:
<path>rotor.ac</path>

<Animation> is used for the animation of the propeller. You can declare the type of animation (spin), the center of the animation, around which axis to spin and in which direction (clockwise or ccw).
<animation>
<type>spin</type>
<object-name>propeller</object-name>
<property>engines/engine[0]/rpm</property>
<factor>1</factor>
<centre>
<x-m>0</x-m>
<y-m>0</y-m>
<z-m>0</z-m>
</centre>
<axis>
<x>0</x>
<y>0</y>
<z>-1</z>
</axis>
</animation>

=== Example files ===
main.xml file:
<PropertyList>
<path>myquadrotor.ac</path>

<model>

<name>Engine1</name>
<path>Aircraft/myquadrotor/Models/engine1.xml</path>
<offsets>
<x-m>0.3</x-m>
<y-m>-0.2</y-m>
<z-m>0.0</z-m>
<pitch-deg>0</pitch-deg>
</offsets>
</model>

<model>

<name>Engine2</name>
<path>Aircraft/myquadrotor/Models/engine2.xml</path>
<offsets>
<x-m> -0.3</x-m>
<y-m>0.2</y-m>
<z-m> 0.0</z-m>
<pitch-deg>0</pitch-deg>
</offsets>
</model>

<model>

<name>Engine3</name>
<path>Aircraft/myquadrotor/Models/engine3.xml</path>
<offsets>
<x-m>-0.3</x-m>
<y-m>-0.2</y-m>
<z-m> 0.0</z-m>
<pitch-deg>0</pitch-deg>
</offsets>
</model>

<model>

<name>Engine4</name>
<path>Aircraft/myquadrotor/Models/engine4.xml</path>
<offsets>
<x-m> 0.3</x-m>
<y-m> 0.2 </y-m>
<z-m> 0.0</z-m>
<pitch-deg>0</pitch-deg>
</offsets>
</model>

<offsets>
<heading-deg>270</heading-deg>
</offsets>
</PropertyList>

engine1.xml file:

<PropertyList>

<path>rotor.ac</path>

<animation>
<type>spin</type>
<object-name>propeller</object-name>
<property>engines/engine[0]/rpm</property>
<factor>1</factor>
<centre>
<x-m>0</x-m>
<y-m>0</y-m>
<z-m>0</z-m>
</centre>
<axis>
<x>0</x>
<y>0</y>
<z>-1</z>
</axis>
</animation>

</PropertyList>

== View ARDrone 2 live video ==

=== Option 1: Simple low quality MJPEG over RTP ===

Add the '''video_stream_rtp.xml''' module to your airframe file. (you can save higher quality frames by clicking on the snapshot setting in the ground-station)

Make a text file with extension .sdp and add the following content [https://github.com/tudelft/ardrone2_gstreamer/blob/master/sdp/x86_config-mjpeg.sdp link]

v=0
m=video 5000 RTP/AVP 26
c=IN IP4 0.0.0.0

Open the SDP file with VLC or another video viewer while the code with module is running on the drone.

=== Option 2: Use the precompiled gstreamer with MP4 encoding on the DSP ===

git clone https://github.com/tudelft/ardrone2_gstreamer.git

Once connected to the ARDrone2 you can upload gstreamer to the ARDrone using (make sure you did not already add a lot of data to the drone like pictures etc because gstreamer will need all normally available free space):

cd ardrone2_gstreamer/
make drone (or manually untar arm_light.tgz and mount and start dsp images: see ardrone.py script for details: reboot drone if starting dsp mp4 images fails)

Before you start encoding video on ARDrone2 the DSP inside the OMAP, it must still load the proper binaries (see todo/basescript.sh for an alternative)

./ardrone2.py startvideo (this step must be repeated every time you reboot the drone)

After this you can use gstreamer on the drone: telnet to the drone and run for instance:

telnet 192.168.1.1
gst-launch v4l2src device=/dev/video1 ! videorate ! 'video/x-raw-yuv,framerate=15/1' ! videoscale ! video/x-raw-yuv, width=320, height=240 ! dspmp4venc ! rtpmp4vpay config-interval=2 ! udpsink host=192.168.1.255 port=5000

(to open video1, downrate, downsample, MP4-encode on dsp, add RTP protocol, UDP stream to IP:port)

and view and save the stream on your PC using the opposite chain:

gst-launch-0.10 udpsrc uri=udp://0.0.0.0:5000 caps = 'application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)MP4V-ES, payload=(int)96' ! rtpmp4vdepay ! ffdec_mpeg4 ! ffmpegcolorspace ! tee name=split ! ximagesink split. ! queue ! ffmpegcolorspace ! ffenc_mpeg4 ! avimux ! filesink location=video.avi

==== don't have gstreamer on your PC yet? ====

Install gstreamer with codecs on unbuntu: make install should achieve this

sudo apt-get install gstreamer0.10-ffmpeg

device=/dev/video1 is front camera
device=/dev/video2 is bottom camera

Other way to video client in ubuntu:
e.g.:
gst-launch-0.10 -vvv playbin uri=file:///home/YOURNAME_AND_SUBFOLDER/ardrone2_gstreamer/sdp/x86_config-mp4.sdp
or see https://github.com/tudelft/ardrone2_gstreamer/blob/master/sdp/Makefile for options

if the above command fails for Ubuntu 12.04 users, you can try this
gst-launch-0.10 udpsrc uri=udp://0.0.0.0:5000 caps = 'application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)MP4V-ES, payload=(int)96' ! rtpmp4vdepay ! ffdec_mpeg4 ! ffmpegcolorspace ! ximagesink

5) if you want to kill your video on the drone
telnet 192.168.1.1
killall -9 gst-launch

== Making Gstreamer Plugins for the ARDrone ==

To combine your own vision with efficient exising gstreamer functions (like dspmp4encode) you should create a plugin and add it to the gstreamer chain:

=== Install ===

We first must install the framework on your development PC. We assume you already have installed the Paparazzi sourcecode. If not, please do that first, then come back to this page.

git clone https://github.com/tudelft/ardrone2_vision.git
cd ardrone2_vision
make install (install some tools needed; scratchbox2 and qemu)
make

If you need to change your cross compiler:

gedit ./ardrone2_gstreamer/Makefile

And add edit the path to your ardrone crosscompiler and '''make install''' again to setup sb2

Make your own vision plugin

./create_new_plugin.py

== OpenCV 3 ==

Here the description on how to get OpenCV 3 on your AR.Drone 2.0. If there is not so much text of explanation here... it is your turn to extend this Wikipage with your knowledge please.

[http://docs.opencv.org/doc/tutorials/introduction/crosscompilation/arm_crosscompile_with_cmake.html]

== Tips and Tricks==

=== Transfer files ===

For transferring files the File Transfer Protocol (FTP) used in this project, was FileZilla. When you installed FileZilla, it will be pretty easy to transfer files.

First you need to connect to the AR.Drone 2, by entering the ip-address of the AR.Drone 2 which is by default "192.168.1.1". Leave all other settings of FileZilla the same and press connect. When you are connected to the AR.Drone 2, keep in mind that programs need to be transferred in binary mode which can be set in the FileZilla Settings.

=== Into the Brain ===

=== login to console on AR.Drone2 via telnet ===
To connect to AR.Drone2 you need a telnet client, so that you can connect with the busybox telnet server on the AR.Drone2.
When your computer is connected trough wifi with the the AR.Drone2, the drone's IP-address defaults to 192.168.1.1.

You can now connect by typing:

$ telnet 192.168.1.1

A busybox welcome message will show when you connect.

It is convenient to make a hosts definition so you can type:

$ telnet ardrone2

You do this by adding <code>192.168.1.1 ardrone2</code> to /etc/hosts

=== Change WiFi channel ===

Sometimes it is nice to be able to change a Wifi channel in an area where there a lot of Wifi devices are in one place. Do it via:

# iwconfig ath0 channel X commit

=== Connect via a router ===

To have a more flexible network setting the drone to use a router would be a good device to use. [[ardrone2userouter | This page explains how to use a router icw a AR.Drone 2.0]]

=== Eclipse Post-build steps ===

While developing with the arm [toolchain] to create some test applications for AR.Drone2 we used a post-build step to quickly upload the file from development computer to the AR.Drone2.

publish.sh
echo "Release script"

# first call a telnet script that stops the test program
/home/dhensen/telnet_stop_script.sh | telnet

# requires having 192.168.1.1 ardrone2 in /etc/hosts
ftp ardrone2 <<END_SCRIPT
# type an arbitrary username on the next line
dhensen
# change the source and target dir to fullfill your needs
put /home/dhensen/workspace/test/Release/test /bin/test
quit
END_SCRIPT

# lastly call a telnet script that gives the test program the right permissions
/home/dhensen/telnet_permission.sh | telnet

exit 0

telnet_stop_script.sh
#!/bin/sh
host=ardrone2
port=23
login=notneeded
passwd=notneeded
cmd="killall -9 test"

echo open ${host} ${port}
sleep 0.1
echo ${cmd}
sleep 0.1
echo exit

telnet_permission.sh
#!/bin/sh
host=ardrone2
port=23
login=notneeded
passwd=notneeded
cmd="chmod 777 /data/video/bin/test"

echo open ${host} ${port}
sleep 0.1
echo ${cmd}
sleep 0.1
echo exit

You can use publish.sh in eclipse by opening Project Properties -> C/C++ Build -> Settings -> Build Steps.
Then in the Post-build steps section in the Command field type: /<your_path_to_file>/publish.sh while replacing your_path_to_file with the path where you saved publish.sh.

After building this script will now push your program called <code>test</code> to the AR.Drone2 automatically. This saves a lot of time, but you still have to run it yourself or adapt the script above to run it automatically. We did not require an automatic run script so we left it out here.

[[Category: AR Drone 2]]

=== Console Fixing ===

==== The traditional pinout ====

[[File:Ardrone2_hw1.jpg]]

==== Hardware V2 ====

The new 6 pin of 2013 PCB design. '''Warning''', mind pin 1, there is the full 12V battery voltage! Access the port via /dev/ttyO3

[[File:ArDrone2_SerialConsoleNewPinout2013.jpg]]

==== View Printf ====

First upload from paparazzi center, then telenet into you Drone's brain:

$ telnet 192.168.1.1

On the Drone to show all running processed:

# ps -aux

To kill AP process:

# killall -9 ap.elf

To restart the main autopilot PPRZ process:

# cd /data/video/paparazzi
# ./ap.elf

=== Debugging ===

==== Serial Console Cable ====

Via the bottom USB port

Debugging is much easier if we have a console cable. For this your USB to serial terminal cable is connected on /dev/ttyUSB0, found via e.g.

$ dmesg

To login to the drone in your regular Linux terminal use:

$ screen /dev/ttyUSB0 115200

=== Repair firmware via serial connection ===

Sometimes your AR.Drone 2.0 is quite messed up since you e.g .deleted some crucial files needed to boot your drone. You need to have a serial cable

http://forum.parrot.com/ardrone/en/viewtopic.php?id=5331

=== Repairing Firmware ===

If your ARdrone2 is really inaccessible, a.k.a. bricked, there is work for you to be done, sice so far no one managed to flash the firmware with external opensource tools. Theoretically possible, just n one ever managed.

=== Downgrade firmware ===

If you would like to downgrade, upgrade, or re-install firmware you can do so at your own risk by using these files and instructions.

Abbreviated instructions:

* Download the version you want below. (Don’t change the filename.)
* Power up your AR.Drone
* Connect your computer to the AR.Drone’s network
* Open a telnet session to 192.168.1.1
* type the following: echo “1.1.1″ > /firmware/version.txt
* press enter
* type the following: echo “1.1.1″ > /update/version.txt
* Connect an FTP client to 192.168.1.1 Port: 5551
* Upload the downloaded plf file to the FTP server (AR.Drone)
* Disconnect your computer from the AR.Drone
* Disconnect the battery from the AR.Drone
* Reconnect the battery
* Wait about 5 minutes while the upgrade completes, leave your drone switched on=

=== GDB ===

The Drone has GDB (GNU Debugger) installed by default

Connect to GDB via: {TODO}

== Boot sequence ==

Note that this section of the page is a work in progress, lease add more info if you have discovered more infrmation.

http://omappedia.org/wiki/Bootloader_Project

The drone 2.0 is based on a Texas Instruments OMAP3630, modified of course.

v1 process (it's similar but not the same, and there is no "load from USB" bootloader available for the 2.0 like there was for the v1):
http://embedded-software.blogspot.co.uk

How the boot process works:
* http://omappedia.org/wiki/Bootloader_Project

Parrot has modified it with their own bootloader(s) though.

Tools to load a different bootloader over UART:
* http://projects.goldelico.com/p/gta04-m … erialBoot/

Note that you won't be able to use his s-boot.bin, it's for a different board of course.

You can make the drone look for a bootloader over UART by plugging a device into the USB port. It might also work if you connect pin 2 to a 5v supply (I think this is VUSB in). You'll know it is working because the drone will wait for 2 seconds before you see the "Parrotboot" message.

Unlike the v1 there is no "flash via USB/UART" bootloader made available by Parrot, so you will have to make your own. There are 3630 configs for x-loader floating around on the web, but none will work out of the box. You need to modify it to set up the Parrot hardware correctly. And mae sure you set the required config for x-loader to make it ask for a 2nd stage bootloader over UART instead of USB. Maybe check out http://barebox.org too. Some hardware config info might be found in Parrot's GPL kernel modifications.

You might be able to use similar tools to load bootloaders from USB instead of UART (i.e. similarly to the tools available for the v1), but I personally have not managed to get as far with USB connection as others in this thread. Maybe my pins are broken.

Some complications you will run into:

# I found that even though I could upload a first stage bootloader via UART and the drone would try to execute it, the "regular" boot never stopped so it was hard to see what was going on. I also think I was getting errors on the upload, checksums failing etc.
# The serial number of your drone hardware is embedded in the NAND flash filesystem. When the Parrot kernel boots and tries to run, it checks this. So overwriting the system partition with one from a working drone will not work. You would need to reverse engineer this process somehow.

If you are were willing to spend another 6 weeks on it, try this:

# Get a bootloader working - x-loader, u-boot, barebox etc
# Try to get installer.plf to execute. Maybe it will ask for ardrone2_update.plf and execute it. If you're lucky, your broken files will be amongst those updated.
# If that fails, try to get to the point where you can mount the NAND filesystem, and modify it by hand.

http://embedded-software.blogspot.nl/2010/12/ar-drone-usb.html

== AR.Drone 1.0 ==

Some information on the AR.Drone 1.0 is still relevand for the AR.Drone 2.0
'+ BELOW FOR AR-DRONE 1 (ONE)+'

* http://awesome-drone.blogspot.nl/2011/01/ardrone-mainboard-overview.html
* http://arsmash.blogspot.nl/2011/04/watchdog-command.html
* http://blog.perquin.com/blog/ar-drone-gpio/

=== Boot sequence 1.0 ===

A.R. Drone's boot sequence

In order to be able to flash a custom kernel to A.R. Drone, it is necessary to understand it's boot sequence:

After reset, the program counter starts at the beginning P6 internal ROM. In this internal ROM, some kind of pre-bootloader exists that evaluates external pins and selects the corresponding boot mode (e.g. boot over USB, NAND, IIC, UART, ... ). Depending on the selected mode, the peripherals are set-up and it is tried to boot over this peripheral.
Boot over NAND: The pre-bootloader starts the memory controller, copies the bootloader from NAND to internal RAM and sets the program counter to the address in internal RAM which basically starts the bootloader.
Boot over USB: The pre-bootloader listens to USB and waits for the "Hello P6" command. If received, it replies and awaits an image (the usb_bootloader.bin). The received data is copied to internal RAM and the program counter is changed to the internal RAM address wich in effect starts the bootloader.

Depending on the started bootloader, either the UBI partitions are "mounted" and the kernel image is read or the bootloader waits until the kernel image is sent over USB.
If the installer.plf (which is basically a kernel image) is booted over USB, the "init" command of this image awaits the actual firmware (ardrone_update.plf) over USB and installs the content to NAND.

=== Custom firmware ===

Reading navigation data directly from Navboard
On A.R. Drones navigation board, the following sensors exist:

IDG-500 (Dual-axis gyroscope)
XV-3500CB (Z-axis gyroscope)
BMA150 (3-axis accelerometer)
Some ultrasonic stuff

For handling these sensors, a PIC24 is used. This device does the A/D conversion of the gyroscope data and the I2C communication with the BMA150.
Periodically, the sensor data is sent over UART to the mainboard where it is used by program.elf to control the Drone.

So... how to get this data without using program.elf?

First, start the sensor acquisition by calling:

echo -e -n "\1" > /dev/ttyPA2

Now, periodically, the nav boards sends a 0x2E sized frame to UART2.. so read it with:

dd if=/dev/ttyPA2 count=1 bs=46 | hexdump -C

The data seems to have the following format:

struct nav_data_tag
{
u16 size; /* +0x00 Size of the following data (0x2C) */
u16 sequence; /* +0x02 Sequence number */
u16 raw_accs[3]; /* +0x04 Raw data of the accelerometers*/
u16 raw_gyros[3]; /* +0x0A Raw data for the gyros */
u16 raw_gyros_110[2]; /* +0x10 4.5x Raw data (IDG) */
u16 uk_0x14; /* +0x14 Unkown. Maybe accs temperature */
u16 gyro_temp; /* +0x16 Gyro temperature (IDG) */
u16 vrefEpson; /* +0x18 Gyro v_ref (Epson) */
u16 vrefIDG; /* +0x1A Gyro v_ref (IDG) */
u16 uk_0x1C; /* Unkown */
u16 checksum; /* +0x1E Checksum */
u16 us_debut_echo; /* +0x20 Ultrasonic parameter */
u16 us_fin_echo; /* +0x22 Ultrasonic parameter */
u16 us_association_echo; /* +0x24 Ultrasonic parameter */
u16 us_distance_echo; /* +0x26 Ultrasonic parameter */
u16 us_courbe_temps; /* +0x28 Ultrasonic parameter */
u16 us_courbe_valeur; /* +0x2A Ultrasonic parameter */
u16 us_courbe_ref; /* +0x2C Ultrasonic parameter */
}

I haven't figured out much yet, but here are my first analysis results:

size: always 0x2C
sequence: increases every update
raw_accs: seems to contain the BMA values left-shifted by 2
raw_gyros: 12-bit A/D converted voltage of the gyros
raw_gyros_110: gyro values wieth another resolution (see IDG-500 datasheet)
gyro_temp: 12-bit A/D converted voltage of IDG's temperature sensor
vrefEpson: 12-bit A/D converted reference voltage of the Epson sensor
vrefIDG: as vrefEpson, but for IDG sensor
checksum: checksum (have to figure out how to calculate..
all others haven't yet figured out what they mean

Posted by es at 8:33 PM 9 comments
Email ThisBlogThis= Share to TwitterShare to Facebook
Labels: A.R. Drone
Wednesday, January 19, 2011
Creating, testing (and flashing -- TBD) a custom kernel
In my last post, I announced that creating and uploading a custom kernel works. Now I will explain how this can be done.

Thanks to MAPGPS from http://www.ardrone-flyers.com for testing my tools.

You need:

- Linux= I used Ubuntu 10.10
- ARDrone linux kernel source (get it from [1])
- ARDrone linux kernel config (get it from [2])
- The Sourcery G++ toolchain (get it from [3] or [4] )
- My plftool, usb_flash tool (see below)
- The old parrot flash tool (for ardrone_usb_bootloader.bin)
- libusb-0.1 (linux) or libusb-win32 (windows)
- zlib

Getting & Compiling plftool + usb_flash tool

These tools are not yet released. Thus I will not provide binaries for windows, instead you have to compile them by yourself. For windows, you need to use mingw32.

Getting the sources

The sources are stored at my google code project. In order to get them, you need to install a svn client. For linux you then call something like this:

svn checkout http://ardrone-tool.googlecode.com/svn/projects/libplf/trunk libplf
svn checkout http://ardrone-tool.googlecode.com/svn/projects/usb_flash/trunk usb_flash
svn checkout http://ardrone-tool.googlecode.com/svn/projects/plftool/trunk plftool

Compiling

Now that you got the sources, you need to compile them. First start with libplf as this is needed by all projects. The library contains the code to read and write .plf files.

$ cd libplf
$ make
$ cd ..

When compiling with mingw32 call "make -f Makefile.w32" instead.

If libplf was compiled succesfully you should get either a libplf.so or libplf.dll file.
Next compile plftool and usb_flash:

$ cd plftool
$ make
$ cd ..
$ cd usb_flash
$ make
$ cd ..

When compiling with mingw32, call "make -f Makefile.w32" instead.

This should create plftool(.exe) and usb_flash(.exe).

For Linux, if you do not want to install the libplf.so file, you need to call plftool and usb_flash with LD_LIBRARY_PATH=<path_to_the_folder_where_libplf.so_is_located> prefix.

E.g.

LD_LIBRARY_PATH=/home/$USER/projects/ardrone/tools/libplf plftool

For Windows, you need to add the folder where libplf.dll is located to your PATH variable before calling usb_flash or plftool.

Patching the kernel

As Parrot's published source code does not match the kernel delivered with firmware > 1.3.3, a patch is required to ensure correct behaviour. This patch mainly affects p6_sdhci.c.

You can get the patch from here. To apply it, just call:

$ cd linux-2.6.27
$ patch -p1 < p6_sdhci-patch1.patch

Compiling the kernel
Now as the kernel is patched, you should use Parrot's original config [2] and cross-compile the sources with Sourcery G++. Basically you need to do something like this (don't forget to add the Sourcery' bin directory to your PATH):

$ cp ARDrone_Version_20100809_1_2-busybox.config .config
$ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- zImage

After a few minutes (or hours) make informs you that the zImage file is available:

Kernel: arch/arm/boot/Image is ready
Kernel: arch/arm/boot/zImage is ready

Creating a kernel.plf file

If you got your zImage, it is time to build a kernel.plf file from it. This is done by plftool. plftool expects a build-ini file that describes the plf file. A sample ini file can be found at plftool/samples/kernel. Using the sample kernel.ini, you only have to modify the "File=" parameters in section "[zImage]" and "[BootParams]" so they point to the zImage file and to a text file, the boot parameters are located in (e.g. called bootparams.txt).

To create the kernel.plf from the kernel.ini, just call:

$ plftool -b kernel.ini -o kernel.plf

The tool should output something similar to this and create the kernel.plf file.

Creating kernel.plf based on this config:
File [HdrVersion: 11 EntryPoint: 0x40800000; Version: 0.0.0
TargetPlat=4, TargetAppl=78, HwCompat=0, LangZone=0]
zImage @ 0x40800000 (zImage)
initrd @ ---------- (no initrd)
bootparams @ 0x40700000 (bootparams.txt)

*** kernel.plf created ***

Testing the kernel.plf file
If kernel.plf file was created, it is time to test this file. First inspect it with plftool:

$ plftool -d -i kernel.plf

Have a look at dwFileType, dwEntryPoint and Section->LoadAddr.

If it looks okay, it is time to start (not flash= ) the kernel:

# Copy ardrone_usb_bootloader.bin to the folder of usb_flash
# Connect the drone to your PC via USB (the LED should be RED)
# Connect the BATTERY to your drone (the LED becomes GREEN)
# Check if the device was found (with lsusb)
# Start usb_flash in TEST mode:

usb_flash -t kernel.plf

This will load (NOT flash) the kernel over USB. In general, it is helpful to observe A.R. Drone's serial port, as the whole boot sequence is shown there. usb_flash outputs on success:

...

Mode: kernel test

*** VERIFICATION ***
Verifying ardrone_usb_bootloader.bin
Verifying test_kernel.plf

*** DOWNLOADING USB BOOTLOADER ***
Try [00/10] to connect to VID: 0x19cf PID: 0x1000
Found a possible device:
- Manufacturer: Parrot SA
- Product: P6 USB Stage1
- Serialnumber: ?
- Number of configurations: 1
Sending bootloader (0x5b20 bytes)
- Send Hello P6 (0xA3)
Success===

Checksum returned: 0x5256 Expected: 0x5256 => OK
Starting the bootloader...

*** INSTALLER DOWNLOAD ***
Closing usb connection...
Try [00/10] to connect to VID: 0x19cf PID: 0x1000
Found a possible device:
- Manufacturer: Parrot SA
- Product: P6 USB Stage1
- Serialnumber: ?
- Number of configurations: 1
loading installer
Uploading file: test_kernel.plf
Error Code returned: 0x00000000 ==> OK
*** INSTALLATION DONE ***

If everything works, the kernel boots up, WiFi ist started and you should be able to connect to the drone with telnet.

Check the kernel version with

uname -a

If the default kernel starts without problems, you can now begin to modify the kernel config.
Flashing the kernel to NAND works but I still need to modify the plftool.. so stay tuned.

Happy hacking :-)

# https://projects.ardrone.org/documents/show/19
# https://projects.ardrone.org/documents/show/18
# https://projects.ardrone.org/documents/show/20
# http://www.codesourcery.com/sgpp/lite/arm/portal/release858
Posted by es at 2:23 AM 7 comments
Email ThisBlogThis= Share to TwitterShare to Facebook
Labels: A.R. Drone, Custom Kernel, Flashing
Tuesday, January 11, 2011
Creating + Flashing Custom Kernel
Yeah...

Creating a kernel.plf file from zImage+initrd --> WORKS=
Booting this kernel.plf file over USB --> WORKS=
Flashing this kernel.plf to NAND --> to be done...

More will follow soon :-)
Posted by es at 11:53 PM 1 comments
Email ThisBlogThis= Share to TwitterShare to Facebook
Labels: A.R. Drone, Custom Kernel, Flashing
Sunday, January 9, 2011
Tools for A.R. Drone
I finally released some tools for A.R. Drone:

libplf - A library to read / write plf files
plf_inst_extract - A tool to extract and patch a ardrone_installer.plf from a given ardrone_update.plf
usb_flash - A tool to flash a ardrone_update.plf over USB. This tool requires:
ardrone_update.plf - the firmware to flash
ardrone_installer.plf - can be obtained from ardrone_update.plf with plf_inst_extract
ardrone_usb_bootloader.bin - was delivered with the old flash tool. I will probably write an open-source boot loader sooner or later.

Have a look at my google code project:

http://code.google.com/p/ardrone-tool
Posted by es at 2:17 AM 0 comments
Email ThisBlogThis= Share to TwitterShare to Facebook
Labels: A.R. Drone, Flashing, USB
A.R. Drone's boot sequence
In order to be able to flash a custom kernel to A.R. Drone, it is necessary to understand it's boot sequence:

After reset, the program counter starts at the beginning P6 internal ROM. In this internal ROM, some kind of pre-bootloader exists that evaluates external pins and selects the corresponding boot mode (e.g. boot over USB, NAND, IIC, UART, ... ). Depending on the selected mode, the peripherals are set-up and it is tried to boot over this peripheral.
Boot over NAND: The pre-bootloader starts the memory controller, copies the bootloader from NAND to internal RAM and sets the program counter to the address in internal RAM which basically starts the bootloader.
Boot over USB: The pre-bootloader listens to USB and waits for the "Hello P6" command. If received, it replies and awaits an image (the usb_bootloader.bin). The received data is copied to internal RAM and the program counter is changed to the internal RAM address wich in effect starts the bootloader.

Depending on the started bootloader, either the UBI partitions are "mounted" and the kernel image is read or the bootloader waits until the kernel image is sent over USB.
If the installer.plf (which is basically a kernel image) is booted over USB, the "init" command of this image awaits the actual firmware (ardrone_update.plf) over USB and installs the content to NAND.

== Datainterchange with other electronics ==

THe Ardrone 2 has various options:

# Use debug serial port
# USB to serial FTDI cable
# Extra Wifi dongle
# USB to Ethernet cable
# LED to PWM in

== Odroid XU ==

=== Hardware ===

1x FTDO

=== Option ===

== The past ==

Some info on older documentation but in certain cases very useful.

=== Reversing ===

Here info of a part of how the electronics where revered to make it possible to run PPRZ

* https://wiki.paparazziuav.org/wiki/AR_Drone_2/Motor_driver
* https://wiki.paparazziuav.org/wiki/AR_Drone_2/NAV_board

=== The "SDK" mode ===

The SDK mode is a thing from the past, '''no real reason to use it''', the links below are left as a reference.

* https://wiki.paparazziuav.org/wiki/AR_Drone_2/AT_Commands
* https://wiki.paparazziuav.org/wiki/AR_Drone_2/GPS

=== Past interesting projects ===

As an honor to the developers some links still here what all was achieved in the past:

* https://wiki.paparazziuav.org/wiki/TU_Delft_-_Search_and_Rescue_with_AR_Drone_2
* https://wiki.paparazziuav.org/wiki/TU_Delft_-_Lasergame_with_Autonomous_AR_Drone
* https://wiki.paparazziuav.org/wiki/AR_Drone_2/Multidirectional_distance_measurement
* https://wiki.paparazziuav.org/wiki/AR_Drone_2/Mapping
* https://wiki.paparazziuav.org/wiki/OLSR

== Links ==

* [http://ardrone2.parrot.com Manufacturer's site with all info about AR.Drone2 (Parrot)]
* [[http://embedded-software.blogspot.com/2011/01/ar-drones-boot-sequence.html Boot sequence]]

* https://play.google.com/store/apps/details?id=com.parrot.freeflight&hl=en
* https://itunes.apple.com/us/app/ar.race-2/id547160291

* AR.Drone 2.0 Blog http://blog.parrot.com/category/ar-drone/

* [[http://ardrone2.parrot.com/photos/photo-album/ | Press photos]]
* [[AR.Drone 2.0 reviews]]

* [[SDK http://ardrone.parrot.com/parrot-ar-drone/dev/developers | Parrot's own developer zone not PPRZ related]]
* [[https://projects.ardrone.org/wiki/ardrone-api/Gpl | Open source Software Licences]]

* [[http://ardrone2.parrot.com/ar-drone-academy/ | AR.Drone Academy]]

* [[http://www.parrotshopping.com/fr/p_parrot_listing.aspx?f=3377 | Spare parts]]
* [[http://www.youtube.com/playlist?list=PLDB67195526DEEE63&feature=plcp | Repair videos]]

[[Category:AR Drone 2]]

Airframe Configuration

2016-03-14T22:23:43Z

Flixr: /* Board targets */ ardrone2_sdk has been removed with https://github.com/paparazzi/paparazzi/pull/1222

<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>}}

<b>Also see the wiki pages for [[Fixedwing_Configuration|fixedwing specific configuration]] and [[Rotorcraft_Configuration|rotorcraft specific configuration]].</b>

== 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]]
* [[settings_modules]]
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/jsbsim/nps" (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"<br/>
board="pc"<br/>

More Information at [[Simulation]].

==== Board targets ====

target name="ap"<br/>
board=
"apogee_0.99",
"apogee_1.0",
"ardrone2",
"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",
"lisa_mx_2.0",
"lisa_s_0.1",
"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",

All targets can be found in /conf/boards.

==== 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 initialized) 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 makefile for the defaults.

To reconfigure the default assignment, assign the indicator to an other value. Use ''none'' if indicator should not be assigned to any LED.

{{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'' or reconfigure it to an other LED.

== Subsystems ==
{| class="wikitable"
|-
| Since '''v5.8''' it is possible to safely replace ''subsystem'' by ''module'' in your airframe file. The roadmap of Paparazzi is to convert existing subsystems to [[modules]].
|}
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 <b><tt>commands</tt></b> 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 <b><tt>servo</tt></b> definition the <b><tt>neutral</tt></b> and <b><tt>min</tt></b> 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 <b><tt>servos</tt></b> 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 <b><tt>servos</tt></b> 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 microseconds. 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µs - 2000µs with a 1500µs 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 <b><tt>neutral</tt></b> and <b><tt>min</tt></b>.

The attribute <b><tt>driver</tt></b> for <b><tt>servos</tt></b> node tells which actuators' driver is associated to 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 <b><tt>driver</tt></b> 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-2000µs 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 <b>zero (0)</b> not with one
* Servos are also known under the synonym <b>actuators</b>
* (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 <b><tt>servos</tt></b> are then linked to the commands in the <b><tt>command_laws</tt></b> 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 <b><tt>let</tt></b> element. The '''@''' symbol is used to reference a command value in the <b><tt>value</tt></b> attribute of the <b><tt>set</tt></b> and <b><tt>let</tt></b> 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 <b><tt>command_laws</tt></b> section is mandatory for both fixedwing and rotorcraft firmwares, only for fixedwing otherwise.

=== Battery ===

This section gives characteristics for monitoring the main power battery.

<b><tt>MILLIAMP_AT_FULL_THROTTLE</tt></b> 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. <b><tt>MILLIAMP_AT_FULL_THROTTLE</tt></b> 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 <b><tt>MILLIAMP_AT_FULL_THROTTLE</tt></b> 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 <b><tt>CURRENT_ESTIMATION_NONLINEARITY</tt></b> 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 <b><tt>CURRENT_ESTIMATION_NONLINEARITY</tt></b> 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 described above for <b><tt>MILLIAMP_AT_FULL_THROTTLE</tt></b>, but only partial throttle (cruise throttle) should be applied in flight.

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

The <b><tt>CATASTROPHIC_BAT_LEVEL</tt></b> (was previously <b><tt>LOW_BATTERY</tt></b>) 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). <b><tt>CRITIC</tt></b> and <b><tt>LOW</tt></b> 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 <b><tt>MAX_BAT_LEVEL</tt></b> 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">
<firmware name="fixedwing">
...
<define name="ADC_CHANNEL_VSUPPLY" value="ADC_4" />
</firmware>
...
<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 <b><tt>VoltageOfAdc(adc)</tt></b> 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>
}}

Calculating '''VOLTAGE_ADC_SCALE''':

<math>VOLTAGE\_ADC\_SCALE=\frac{Vref}{ADCresolution-1}\div\frac{R2}{R1+R2}</math>

*Vref - Voltage reference for the ADC (will be 3.3V in most cases, can be found in mcu/adc datasheet)
*ADCresolution - ADC bit depth (e.g. 2^12=4096 for a 12 bit ADC)
*R1 - Resistor between battery and ADC input pin of MCU
*R2 - Resistor between ADC input pin of the MCU and GND

It is also a good idea to measure the actual voltage of the battery with a precision voltage meter, compare it with the calculated value from the autopilot (e.g. via [[Paparazzi_Center#Messages]]) and edit the vales for ADC scaling. Since the resistors have a tolerance, this can fine tune the measurement.

=== 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

{| class="wikitable"
|-
| Since '''v5.8''' it is possible to safely replace ''subsystem'' by ''module'' in your airframe file. It is therefore also possible to use the modules the same way subsystems used to be (i.e. as children of the ''firmware'' node and not only the ''modules'' node as presented above. The roadmap of Paparazzi is to convert existing subsystems to [[modules]].
|}

=== GCS ===

[[Image:ac_icon_multi_uav.png|thumb|Various A/C icons demonstrated on a multi UAV simulation session]]

[[Image:Icons_Theme_Default.png|thumb|Default Theme]]

[[Image:Icons_Theme_Flat.png|thumb|Flat Theme]]

Use this <b>optional</b> 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="ICONS_THEME" value="flat_theme"/>
<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>
}}

* <tt>ICONS_THEME</tt> can be used to define an alternate/custom GCS icons theme for a given aircraft The '''flat_theme''' is one example of an alternate set of GCS icons.
* <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>quadrotor</tt> , <tt>hexarotor</tt> , <tt>octorotor</tt> , <tt>quadrotor_x</tt> , <tt>hexarotor_x</tt> , <tt>octorotor_x</tt> , <tt>home</tt>.

==== Custom Icons Theme Support ====

A custom icons theme is supported through the use of the '''ICONS_THEME''' attribute. Set the '''ICONS_THEME''' attribute ''value'' to the path of your custom icons theme directory and the given aircraft will now display your custom icons. Note that the path is relative to the default GCS icons path root: ''$PAPARAZZI_HOME/data/pictures/gcs_icons''

{{Box Code|code snippet|
<source lang="xml">
<section name="GCS">
<define name="ICONS_THEME" value="myawesome_icons"/>
</section>
</source>
}}

The directory that contains your custom icons, in this example named ''myawesome_icons'', is located at ''$PAPARAZZI_HOME/data/pictures/gcs_icons''.

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

JSBSim

2016-03-11T17:20:36Z

Flixr: /* From Source */

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

[http://jsbsim.org JSBSim] is an open source flight dynamics model (FDM) used in [[NPS]].

== Installation ==

=== Debian Package ===
On Debian/Ubuntu you can install the paparazzi-jsbsim package.
sudo apt-get install paparazzi-jsbsim
If you don't have that in your sources, see [[Installation/Linux#Adding_the_APT_repository]]

=== From Source ===
Compile JSBSIM from source (with specified date to make sure it works and API hasn't changed)
cvs -z3 -d:pserver:anonymous@jsbsim.cvs.sourceforge.net:/cvsroot/jsbsim co -D "23 Feb 2015" -P JSBSim
cd JSBSim
./autogen.sh
./configure --enable-libraries --enable-shared --prefix=/opt/jsbsim
make
sudo make install

When building a [[NPS]] simulator target, the build system will first try to find JSBSim via pkg-config and fall back to ''/opt/jsbsim''.

If you want to install to a different location, change the ''prefix'' to your liking.
And you need to add a <tt><makefile></tt> section to your airframe file and add the correct flags to point to the include files and libraries, depending on where it is installed.

With the default installation to <tt>/usr/local/</tt>, this would look like
<makefile location="after">
nps.CFLAGS += -I/usr/local/include/JSBSim
nps.LDFLAGS += -L/usr/local/lib
</makefile>

=== On OSX ===
* Install the JSBSim libraries onto your system. This should already be installed with <tt>paparazzi-tools</tt>, but if it isn't:
<code>$ sudo port install jsbsim</code>
It uses code from the cvs repo, so it should be the most up-to-date source.

== Troubleshooting ==
* If you get an error like "undefined reference to `pcre_compile'", edit file conf/Makefile.jsbsim, look for the line that begins with LDFLAGS and add -lpcre, e.g.:
LDFLAGS += $($(TARGET).LDFLAGS) -lpcre

[[Category:Simulation]] [[Category:Software]] [[Category:User_Documentation]]

JSBSim

2016-03-11T17:17:04Z

Flixr: /* From Source */ adjust date to currently used version

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

[http://jsbsim.org JSBSim] is an open source flight dynamics model (FDM) used in [[NPS]].

== Installation ==

=== Debian Package ===
On Debian/Ubuntu you can install the paparazzi-jsbsim package.
sudo apt-get install paparazzi-jsbsim
If you don't have that in your sources, see [[Installation/Linux#Adding_the_APT_repository]]

=== From Source ===
Compile JSBSIM from source (with specified date to make sure it works and API hasn't changed)
cvs -z3 -d:pserver:anonymous@jsbsim.cvs.sourceforge.net:/cvsroot/jsbsim co -D "23 Feb 2015" -P JSBSim
cd JSBSim
./autogen.sh
./configure --enable-libraries --enable-shared --prefix=/opt/jsbsim
make
sudo make install

If you want to install to a different location, change the ''prefix'' to your liking.
And you need to add a <tt><makefile></tt> section to your airframe file and add the correct flags to point to the include files and libraries, depending on where it is installed.

With the default installation to <tt>/usr/local/</tt>, this would look like
<makefile location="after">
jsbsim.CFLAGS += -I/usr/local/include/JSBSim
jsbsim.LDFLAGS += -L/usr/local/lib
</makefile>

=== On OSX ===
* Install the JSBSim libraries onto your system. This should already be installed with <tt>paparazzi-tools</tt>, but if it isn't:
<code>$ sudo port install jsbsim</code>
It uses code from the cvs repo, so it should be the most up-to-date source.

== Troubleshooting ==
* If you get an error like "undefined reference to `pcre_compile'", edit file conf/Makefile.jsbsim, look for the line that begins with LDFLAGS and add -lpcre, e.g.:
LDFLAGS += $($(TARGET).LDFLAGS) -lpcre

[[Category:Simulation]] [[Category:Software]] [[Category:User_Documentation]]

FirmwareArchitecture

2016-03-11T16:43:24Z

Flixr:

== Low Level drivers ==
low level code organization is roughly:
* '''sw/airborne/mcu_periph''' : interfaces/drivers for MCU peripherals like I2C, SPI, ADC, etc... (the HAL)
* '''sw/airborne/peripherals''' : drivers for external peripherals, like sensor chips, etc...
* '''sw/airborne/arch''' : everything that is architecture specific (''lpc21'', ''stm32'', ''linux'', ..)
* '''sw/airborne/boards''' : board definitions, pinout, etc... (no need to touch this unless you want to support a new board)

== Subsystems ==
[[Subsystems]] are just a convention used to provide several implementations of a peripheral (like microcontroller peripherals, an external imu board...), protocol (gps, communications...) or algorithm (control, estimation...). Function calls are written "by hand" and the build system takes care to compile the particular implementation.

They are selected and configured with a <source lang="xml" enclose="none"><subsystem name="foo" type="bar"></source> in the [[Airframe_Configuration#Firmware_and_Hardware_definitions|firmware section of the airframe file]]. All this does is basically include a makefile <tt>foo_bar.makefile</tt> that adds the respective sources and adds a few configuration options. (See <tt>conf/autopilot/subsystems/...</tt>)
This makes it easier to put an airframe file together (they replace the old raw makefile section) and also allows us to change the code and move/rename files behind the scenes without breaking everyones airframe files.
{| class="wikitable"
|-
| Since '''v5.8''' it is possible to safely replace ''subsystem'' by ''module'' in your airframe file. The roadmap of Paparazzi is to convert existing subsystems to [[modules]].
|}
=== Creating a new Subsystem ===
A new subsystem is required when adding support for new or alternate core functionalities, as listed above. Some new subsystems will rely on underlying peripheral or MCU peripheral drivers (for example a new IMU subsystem), others do not need this (for example a new set of control loops). An MCU peripheral uses on-chip hardware peripherals in the main microcontroller (such as the SPI hardware), while normal peripherals are external hardware such as an analog to digital converter integrated circuit (such as the MAX1168).

The general strategy for adding a new subsystem should be something along the lines of:
*(if required) write a peripheral driver for the specific device or device family in <tt>sw/airborne/peripherals/</tt>
*(if required) in the peripheral driver, use the <tt>sw/airborne/mcu_periph/*.[c|h]</tt> arch-independent mcu peripheral drivers to handle the communication and input-output operations
*(if required) you may wish to use a family generic c header (<tt>.h</tt>) file for register definitions, etc., if the driver could be used with a family of peripheral devices
*write a subsystem driver for the new functionality, device or device family in <tt>sw/airborne/subsystems/TYPE/</tt>
*you may wish to use a family generic c header (<tt>.h</tt>) file for register definitions, etc., if the driver could be used with a family of peripheral devices
*if you need to add complex features (for example, use a gpio for a reset, use an interrupt for data ready, etc), you will need to add some arch specific files in the correct location to handle some of the extra initialization and operation, for example in <tt>sw/airborne/arch/ARCHTYPE/subsystems|peripherals|mcu_periph|ETC/</tt>
*write a subsystem makefile to aid in building the code, found in <tt>conf/firmwares/subsystems/fixedwing|rotorcraft|shared/</tt>
*even though you technically need to make a new one, you can undoubtedly use existing examples to make your life easier. For example, for an IMU, try looking at the adxl345 peripheral driver, or possibly the imu_b2.[c|h] (which uses for example the ms2100 and max1168 peripherals) for some ideas
*last thing, make sure you USE MASTER for all development, and take a look at the [[Contributing]] page, and be sure to review the coding style guidelines
*heavily comment the code, especially regarding any magic numbers and operations (for example, scaling the input of a sensor)
Finally, master is always being updated and changed, so if you aren't quite sure about something, don't hesitate to ask on the mailing list. In addition, there may be style differences between newer, updated subsystems and older subsystems.

== Modules ==
[[Modules]] use code generation in order to allow people to use them by only editing the vehicle's xml configuration as opposed to changing/adding to the code of the autopilot. Typically, function calls are generated for initialisation and in the mainloop for timers (periodic in paparazzi slang) and events. The event and periodic functions of the Modules get called at the end of event_task_ap and periodic_task_ap respectively.

=== Creating a new Module ===
*See [[Modules]] for more information

== Discussion ==
So the difference is that with subsystems you explicitly call the functions (e.g. control loops) from the main ap loop, whereas the event/periodic functions of the Modules get called at the end of the main event/periodic tasks. So Modules are perfect to add stuff like extra payload and sensors, but Subsystems give you tighter control over when and in what order to call functions (e.g. for estimation/control).

Modules naturally provide the "several implementations" feature of the Subsystems. So, we could have a "generic" main.c consisting only in calls to the generated functions.
Nevertheless, care should be taken that switching to a "module only" configuration doesn't become detrimental to the readability and debugability of the code.

You can also wrap some subsystem code as a modules (e.g. infrared), or the other way round (e.g. imu_ppzuav). As you can see with the imu_ppzuav module it also still expects a direct ImuEvent call from main_ap, so you could say it's not a "pure" module.

[[Category:Software]] [[Category:Developer_Documentation]]

Docker

2016-03-10T10:09:02Z

Flixr: /* On Mac */

Docker is an open platform used to build, ship, and run distributed applications. You can learn more about Docker by visiting its website, https://docker.com.

In particular, if you're just getting started using Docker with Paparazzi, we encourage you to make use of the following resources:

* [https://www.docker.com/whatisdocker/ What is Docker] - A page that will give you excelent high level overview of Docker and its purpose.
* [https://docs.docker.com/ Documentation] - Browse the online documentation and references to find information about Docker's various functions and tools.
* [https://forums.docker.com/ Forums] - If you need help, just ask! Docker has a great user community, with lots of people willing to help answer any questions you might have.
* [https://groups.google.com/forum/#!forum/docker-userl Mailing list] - Another way to start a discussion and follow community activities.

For new users of Docker, those resources will provide you with most of the information you'll need to get familiar with the platform. Additional information pertaining to using Docker for Paparazzi can be found on this page.

You can test out Docker right now using a live online tutorial, try it out yourself: [http://docs.docker.com/linux/started/ Linux] / [http://docs.docker.com/mac/started/ Mac].

We have some images and scripts to easily build/test Paparazzi within a container.

== Pulling Paparazzi images ==
There are prebuilt images containing all the Paparazzi dependencies on [https://hub.docker.com/u/flixr/ Docker hub], which you can just pull:
<source lang="bash">
docker pull flixr/pprz-dep
docker pull flixr/pprz-dev
</source>
Or in your local clone of the Paparazzi repository:
<source lang="bash">
cd docker
make pull
</source>

The pprz-dep image contains all dependencies, the pprz-dev image adds some convenience stuff and a pprz user. Normally you will want to use the pprz-dev image.

== Building and Running Paparazzi inside Docker ==
You can simply start a shell inside the pprz-dev container
<source lang="bash">
docker run -it flixr/pprz-dev bash
</source>
You could now clone the paparazzi repo inside this container and build it.
However this does not give you access to the X-Server, USB, etc..

To make Docker more useful to us and enable using and editing Paparazzi files from the host system, the repo contains a [https://github.com/paparazzi/paparazzi/blob/master/docker/run.sh helper script]. See also https://github.com/paparazzi/paparazzi/pull/1272

Starting a shell (or [[Paparazzi Center]] directly) through this script will enable access to the X-Server, USB devices and audio and set mount your current Paparazzi directory in the home directory of the pprz user inside the container.
That way you can edit your code and configuration files from your host system using your favourite tools/IDE and then build and use them within Docker.

In your local clone of the Paparazzi repository:
<source lang="bash">
./docker/run.sh -it flixr/pprz-dev bash
</source>
or even easier:
<source lang="bash">
cd docker
make bash
</source>
And you get a new bash shell inside the Paparazzi Docker container... There you can just run <tt>make</tt> to build Paparazzi.
Once built, you can also directly use <tt>make paparazzi</tt> or <tt>make start</tt> accordingly to start the Paparazzi Center or the start.py tool.

== Troubleshooting ==
When using the run.sh script, you are sharing the paparazzi directly between your host system and the Docker container. This means that if you previously had Paparazzi built on your host system, you will need to rebuild it inside the Docker environment (<tt>make clean && make</tt>).

=== On Mac ===
There is currently no audio forwarding on OSX and X-Server access might be slower, see https://github.com/paparazzi/paparazzi/pull/1425

Possibly helpful pages:
* http://wiki.ros.org/docker/Tutorials/GUI

[[Category:Testing]] [[Category:Software]]

Installation

2016-03-09T10:56:27Z

Flixr: /* Quickstart for Ubuntu users */

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

== Introduction ==

Paparazzi is very easily installed on any laptop or workstation running the [http://www.ubuntu.com/ Ubuntu Linux OS] or virtually any [http://www.debian.org/ Debian] based [http://en.wikipedia.org/wiki/Linux Linux] or Apple Macintosh running [http://en.wikipedia.org/wiki/OS_X Mac OS X]. There is also work being done to port Paparazzi to Windows.

The steps required to install the software needed to be able to let your UAS fly are:

# Install tools and prerequisites needed by Paparazzi.
# Download the source code from the source repository.
# Compile the Paparazzi software from sourcecode
# Complete any final configuration

== Quickstart for Ubuntu users ==
Love one-liners? To get the latest Paparazzi up and running on your '''Ubuntu 12.04 or higher OS''', make sure you have internet, then just copy and paste the text below into your terminal and press [enter] ... and wait a while...

sudo add-apt-repository -y ppa:paparazzi-uav/ppa && sudo add-apt-repository -y ppa:terry.guo/gcc-arm-embedded && sudo apt-get update && \
sudo apt-get -f -y install paparazzi-dev paparazzi-jsbsim gcc-arm-none-eabi && cd ~ && <nowiki>git clone --origin upstream https://github.com/paparazzi/paparazzi.git</nowiki> && \
cd ~/paparazzi && git remote update -p && \
git checkout -b v5.8 upstream/v5.8 && sudo cp conf/system/udev/rules/*.rules /etc/udev/rules.d/ && \
echo -e "export PAPARAZZI_HOME=~/paparazzi" >> ~/.bashrc && echo -e "export PAPARAZZI_SRC=~/paparazzi" >> ~/.bashrc && source ~/.bashrc && \
make clean && make && ./paparazzi

[[File:Done.jpg|frameless|center|Done!]]
If all went well, and you've flown Paparazzi before, the Paparazzi Center should now be running... '''skip''' the rest of this page, go fly!

If you are new you'll need to do some more things before you go fly like configuring your XML definition file detailing your airframe configuration. There is help here for that: [[Airframe_Configuration]]

In case you have no autopilot hardware yet, no problem, go get hardware [[Get_Hardware|here]] or just buy a ready to fly aircraft that can run Paparazzi Software like the Parrot Drones [http://www.parrot.com/products/bebop-drone/ Parrot Bebop] and run Paparazzi on your Parrot [[AR_Drone_2|ARDRone2]], [[Bebop|Bebop]] and Bebop2 (soon the Disco drone).

== OS Specific Instructions ==

For Linux an instruction video explaining it all in detail can be watched here https://www.youtube.com/watch?v=eW0PCSjrP78

The process of installing the prerequisite tools and dependencies needed by Paparazzi is specific to the operating system you are using. For detailed installation instructions, please see the following pages:
*[[Installation/Linux|Installing prerequisites tools on Linux]]
*[[Installation/MacOSX|Installing prerequisites tools on Mac OS X]]
*[[Installation/RaspberryPi|Installing prerequisites tools on the RaspberryPi (Raspbian)]]

For more advanced installation information or developers, please see the following pages:
*[[Installation/FromScratch|Installing everything from scratch]] For non Debian based Linux distributions or if one just wants to be able to use all the latest and greatest compilers, or source code of everything to improve something. Then there is no other way than to install from scratch.
*[[Installation/Windows|Installing prerequisite tools on Windows]] Note that this is '''a work in progress, and not finished yet'''. It would be fantastic if you are interested in running Paparazzi on this OS to help out with the porting. Being able to help is one of opensource software main features. If your skil- set is not so good in this area, but you still insist using Windows OS, then it is best to install a VirtualMachine from within Windows where you run the free Ubuntu OS of choice.

=== Virtual Machines ===

It is also possible to have your Debian/Ubuntu running in a virtual machine, for instance with [http://www.virtualbox.org/ VirtualBox]. This requires minimal changes to your computer setup, as you can run the VM from all common platforms (Windows, OS X, Linux). The virtual machine image can easily be transferred between different laptops, giving greater flexibility. Unfortunately, the Open-Source Edition of VirtualBox doesn't include the necessary USB support, so you'll need to get the regular version from the website.

If you are new and this is your first time installing it is suggested you keep it simple. Use the standard Linux or OS X install. Select a system you can dedicate to the Linux installation. No VMs or dual boot configurations. The idea is do a very simple generic installation that is certain to have no issues. This reassures you that the installation process works and you can see and use a working Paparazzi install for some time before you try a more complicated install. The install is well documented and certain to succeed if followed exactly. Most issues arise when someone unfamiliar with Paparazzi or their OS tries a non-standard install that requires special steps that are not documented. Generally, commands can be copied and pasted for easy, step-by-step installation.

== Getting the Source Code ==
The Paparazzi source code is hosted on [https://github.com/paparazzi/paparazzi Github]. While you can download it as a tarball from https://github.com/paparazzi/paparazzi/releases, it is recommended to clone the repository with [[git]].

From the directory of your choice type:
git clone --origin upstream https://github.com/paparazzi/paparazzi.git
Check out the released stable version branch:
git checkout v5.8

'''If this whole "Git" thing is new to you, more options and information can be found on the [[git|Git page]].'''

== Launching the Software ==
Make sure you have installed the <tt>paparazzi-dev</tt> package as described above. Without these you will not be able to compile the sourcecode.
The first step is to compile. From the <tt>paparazzi</tt> directory (<tt>cd ~/paparazzi</tt>), run

make

You will have to run this command after each update of the source (<tt>git pull</tt> command).
Launch the software from the <tt>paparazzi</tt> directory with

./paparazzi

From the [[Paparazzi_Center|Paparazzi Center]] interface, select the ''Microjet'' aircraft, select the ''sim'' target and ''Build'' it. Then ''Execute'' the ''Simulation'' session. The procedure is detailed in the [[Simulation]] page.

=== Environment Variables ===

If ('''and only if''') you want to directly launch some Paparazzi agents (the ''Tools'' of the [[Paparazzi_Center|Paparazzi Center]]) from the command line, without using the Paparazzi Center, you must have the Paparazzi source and home environment variables set correctly in your shell. These variables can be automatically set in your shell by adding the following lines to your .bashrc file:
{{Box Code|~/.bashrc|
<source lang="bash">
export PAPARAZZI_HOME=''your paparazzi software directory''
export PAPARAZZI_SRC=''your paparazzi software directory''
</source>
}}

Verify that your variables are set correctly with the following command:
:<source lang="bash">env | grep PAPARAZZI</source>
which should return the following:
<source lang="bash">
PAPARAZZI_HOME=''your paparazzi software directory''
PAPARAZZI_SRC=''your paparazzi software directory''
</source>

If you wish to manually set the env variables (i.e. when compiling a backup copy of your code in a different folder) execute the following command from the folder you wish to set as your active paparazzi folder:
:<source lang="bash">export PAPARAZZI_HOME=`pwd`;export PAPARAZZI_SRC=`pwd`</source>

== Software Updates ==
'''We manage the software with the git version control system. Learn it! If you are new to it, see the [[Git|Git wiki page]].'''

Paparazzi is a very rapidly evolving project and as such you might want to update your software regularly. See the [[RepositoryStructure|branching model and release process page]].

Any new files you created will not be lost/overwritten when updating (like your own airframe file). Nevertheless, as with all things, backups are advised.
If you modified source code, the best way is of course to use the version control system [[Git]] to commit your changes. Otherwise at least use the brute force method and save everything in another directory.

Update your software with care and caution, and always test the functionality on the ground and in the air as some updates will affect tuning parameters. You might need to update your airframe file as well. The compiler will usually complain if there is a problem, at which point you can look at the [[Airframe_Configuration|Airframe Configuration wiki page]] again, look on the [[Contact#Mailing_List|mailing list]] or some of the most recent airframe files on git to find the proper syntax.

'''See also the [[Release Upgrades]] page for information on how to update your configuration from one release to the next.'''

=== Quick'n dirty description ===

To download and automatically merge any updated source files, run the following command from your Paparazzi directory
git pull

After any git update or source code modification the code can be recompiled from ''your paparazzi software directory'' with the following command:

make

The ''make'' command will only recompile portions of the software where changed have been detected.
If it does not behave as expected you can delete all compiled files and recompile from scratch with the following commands:

make clean
make

If you'd like to check that the code compiles all example airframes then you can run the test suite using the command

make test

For more details see the [[Builds/Tests|tests page]].

== Using the Live CD ==

There is a [[LiveCD]] available, but it dates back to 2008. It is still an easy way to get a first glimpse of Paparazzi however without installing anything.

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

DevGuide/Server GCS com

2016-02-28T20:29:47Z

Flixr: /* Advanced format */

The communication between the '''[[Server|server]]''' and the '''[[GCS]]''' is based on the [[Ivy]] middleware as described in the [[Overview#System_Architecture|system overview]].

The mechanism described below apply mainly to the Ocaml library provided by paparazzi (sw/lib/ocaml/pprz.ml*), even if the basic send/bind functions of Ivy can be used directly in C programs.

= How Ivy is used =

== Normal bind/send mechanism ==

[[Ivy]] is based on message subscription (based on [http://en.wikipedia.org/wiki/Regular_expression regular expression]):
* the '''bind''' function takes two parameters: a regular expression and a callback function.
* the '''send''' function sends strings and is used like the 'printf' C function.
when someone has a message to send that is matching the regular expression of one or more '''bind''', it will trigger the associated callback with the string as a parameter.

== Advanced request mechanism ==

In order to let a agent ask for some information, a answer/request mechanism has been integrated using the normal bind/send mechanism.

* the '''answerer''' function takes a message name (ex: MSG_NAME) and a callback function as parameters
** it binds to MSG_NAME_REQ messages
** it sends back a MSG_NAME message when the MSG_NAME_REQ callback is triggered
* the '''request''' function takes a message name (ex: MSG_NAME), a callback function and some values as parameters
** it binds to MSG_NAME message with the callback function given as parameter
** it sends a MSG_NAME_REQ message with the values given as parameters
** after receiving the reply from the answer and applying the callback function to the returned values, it unbinds from the message MSG_NAME

= Format of messages =

The messages used in paparazzi are described in the file ''conf/messages.xml''. Most of the messages used by the '''[[GCS]]''' or the '''server''' are from the class '''ground'''. Each message is composed of:
* a unique name (among all the messages)
* a unique ID (among its class)
* a list of ''fields'' with a name and a type

In the following subsections, ''anything'' means that a field can match any string that doesn't have whitespace, ''anything...'' means that the field can contain several or none ''anything'' separated by whitespace.

== Normal format ==

The normal format of the message when using the '''send''' function:
[timestamp] sender_name msg_name ''anything...''
timestamp is optional, default is false.

The normal '''bind''' function looks for messages of the form:
[timestamp or nothing] sender_name msg_name ''anything...'' when a sender name is given as a parameter
[timestamp or nothing] ''anything'' msg_name ''anything...'' else
This allow to receive the messages coming from a given sender or from anyone.

== Advanced format ==

When using the answer/request mechanism a unique request ID is added to the normal format. The format of this ID is '''pid_index'''. The Unix Process ID (pid) is unique for each running program, the index is incremented at each request. There is no timestamp.

The '''request''' send format:
sender_name request_id msg_name_REQ ''anything...''

The '''request''' bind format:
request_id ''anything'' msg_name ''anything...''

The '''answerer''' send format:
request_id sender_name msg_name ''anything...''

The '''answerer''' bind format:
''anything'' ''anything'' msg_name_REQ ''anything...''

= Server <-> GCS communication =

== Server ==

The '''server''' sends synthetic messages based on the telemetry data received from the UAVs (normal period is 500ms, 1s for alarms, 5s for WIND):
* NEW_AIRCRAFT (when a telemetry message ALIVE is received (and correct) for the first time)
* FLIGHT_PARAM
* NAV_STATUS
* ENGINE_STATUS
* AP_STATUS
* FLY_BY_WIRE
* DL_VALUES
* WAYPOINT_MOVED
* CAM_STATUS
* CIRCLE_STATUS
* SEGMENT_STATUS
* SURVEY_STATUS
* WIND
* TELEMETRY_STATUS
* TELEMETRY_ERROR
* BAT_LOW (trigger alarm)
* AIRPROX (alarm but not used anymore)
It answer to some requests:
* AIRCRAFTS (sends the list of all running aircraft known by the server)
* CONFIG (sends the configuration of a given aircraft)
It binds to:
* MOVE_WAYPOINT
* DL_SETTING
* GET_DL_SETTING
* JUMP_TO_BLOCK
* RAW_DATALINK
* WIND_CLEAR
* all messages of the class telemetry

== GCS ==

The '''[[GCS]]''' binds to all the messages sent by the '''server''' (except AIRPROX). It also binds the the messages TCAS_TA, TCAS_RA and DC_SHOT, which are direct telemetry messages.

It sends messages:
* MOVE_WAYPOINT
* DL_SETTING
* GET_DL_SETTING
* JUMP_TO_BLOCK
* RAW_DATALINK

It can request for CONFIG and AIRCRAFTS.

== Initialization sequence ==

When the '''server''' starts, the initialization is as follow:
* bind to ALIVE message and send a NEW_AIRCRAFT message when the callback is triggered
* bind to the messages sent by the GCS
* set '''answerer''' for AIRCRAFTS and CONFIG

When the '''[[GCS]]''' starts, the initialization is as follow:
* send request for AIRCRAFTS
** when the callback function is triggered with the list of working aircraft, send requests CONFIG for each of them
* bind to NEW_AIRCRAFT
** when the callback function is triggered with a new aircraft, send request CONFIG for it
* bind to messages sent by the '''server''' + some extra messages

The result is that the GCS asks for the aircraft already known by the server and then receives new aircraft when they appears.

[[Category:Software]] [[Category:Developer_Documentation]]