PaparazziUAV - User contributions [en]

DevGuide/Values

2009-03-18T19:12:11Z

Rcbrother: /* IR sensors */

= How do values travel through the system? =

Make sure you have a ready built system when trying to analyze the
software. Some of the embedded code is generated from the xml
configuration files at build time. You can find that in the var folder
for the aircraft you are using.

=== RC transmitter ===
The most important sensor. It gives stick movements from the safety
pilot to the aircraft. The values are derived from the angle of the
sticks or from position switches. The minimum configuration for a
Paparazzi transmitter is two sticks and one three-position switch for
manual, auto1 and auto2.

The angle is usually given from -100% to 100% for full sweep and 0% for
the middle position. This are the min / max positions and values we use:

[[Image:radio_robbe.jpg|Robbe transmitter]]

RC transmitters generate a pulse-pause-modulation PPM signal from the
angles (proprietary PCM does not work with Paparazzi). The information
is in the length of a pulse. Usually a 1.5ms pulse is middle position
and 1ms equals -100% and 2ms 100%. The pulses are sent as a packet and
repeat at about 15ms rate The following shows a 9 channel transmitter (this is 10 pulses) and a decoded servo #1. Use RC_FUTABA in your airframe conf file if you see a signal like this (pulses go "high").

[[Image:9ch_pulses.png|9 Channel PPM signal]]

RC transmitter use slightly different timings for the middle and 100%
positions and have different directions. The conf/radio folder contains
the descriptions for the different transmitters. Here, also no trim
should be used. Give the repeat time of the PPM pulse and the number of
channels (you have one pulse more than channels!). The switches can be
filtered by a low pass filter through the "average" descriptor.

=== RC receiver ===
The PPM signal is transmitted as FM signal and demodulated in your
receiver. The receiver demultiplexes the signals with a shift register
chip like 4015 or 4017 and gives it to servos. Paparazzi needs the
non-demultiplexed TTL level signal from the receiver. A good point to
grab that is the input of the shift register of the receiver (e.g. pin 1 of a 4015). Some newer receiver have microcontrollers which make it tricky to get the
signal.

[[Image:rx_jeti.jpg|Jeti Rex 4 receiver]]

The signal is low and goes high for the pulses in most cases, use
-DRADIO_CONTROL_TYPE=RC_FUTABA in your aircraft description file for
that. Some Graupner/JR receivers use inverted logic, use
-DRADIO_CONTROL_TYPE=RC_JR for them.

=== Inside Paparazzi ===

A normalized value is used for servo values within the Paparazzi
software. It ranges between MIN_PPRZ and MAX_PPRZ which is currently
-9600 and 9600. That is more than 14 bits resolution and a lot more
than what RC radios or servos can reproduce. Whenever a value is
calculated it should be trimmed to MIN and MAX by TRIM_PPRZ() or
TRIM_UPPRZ() for 0 and MAX bounds.

=== ADC sensors ===
Analog voltages between 0 and 3.3V can be measured with the internal
Analog/Digital converters (this refers to the LPC/ARM7 architecture).
The values are sampled through a NB_SAMPLES stages long low pass
filter. Every ADC pin has to be activated for ADC usage individually for
flexible configuration.

The resolution of the ADCs is 10 bits and that gives an integer value
between 0 and 1023 in the Paparazzi software. The values are converted
to more useful numbers for some sensors.

=== IR sensors ===
The thermopiles give a voltage as a (nonlinear) function of the
roll/tilt angle. The angle is calculated using the information given in
the aircraft file (neutral value, sensor alignment relative to the
aircraft axes, correction for diversitiy in sensitivity). Angles are
used as [http://en.wikipedia.org/wiki/Radian radians] (360° = 2 * pi) for calculations. Some flight plan
values are given in degrees, though.

=== SPI / I2C ===
Byte values can be read from SPI or I2C devices, e.g. to read data from
additional sensors.

=== Servos ===
At the end servos have to be moved. The PPRZ values are converted to
-100% .. 100% servo movements. The aircraft configuration file
describes the relation between the min/max actuation and the 1.0ms -
2.0ms long pulse.

Flight Plans

2009-03-18T10:02:47Z

Rcbrother:

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>

<tt><!DOCTYPE flight_plan SYSTEM "flight_plan.dtd"></tt>

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 in the GUI.

== Structure of the flight plan file ==

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

A flight plan is composed of two compulsory elements: [[#waypoints|waypoints]] and [[#blocks|blocks]] and typically contains optional <tt>include</tt>'s and global <tt>exceptions</tt>.

The root <tt>flight_plan</tt> element is specified with several attributes:
<tt><flight_plan name lat0 lon0 ground alt security height qfu alt max_dist_from_home></tt>
* <tt>name</tt>: the name of the mission (a text string)
* <tt>lat0, lon0</tt>: describe the latitude and longitude of the point {0,0} in WGS84 degree coordinates
* <tt>ground_alt</tt>: the ground altitude (in meters). It defines the <tt>GROUND_ALT</tt> constant value which can be used to define waypoint altitudes
* <tt>security_height</tt>: the altitude used by the circle-home failsafe procedure
* <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.
* <tt>alt</tt>: the default altitude of waypoints
* <tt>max_dist_from_home</tt>: the maximum allowed distance (in meters) from the HOME waypoint.

Here is an example of the first line of a flight plan:

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

=== Waypoints ===

The waypoints are the geographic locations used to specify the trajectories. A waypoint is specified with its name and its relative coordinates:
<tt> <waypoint name x y [alt] /> </tt>
where <tt>x</tt> and <tt>y</tt> are the coordinates in meters from point {0,0}. <tt>alt</tt> is optional and can be used to assign an altitude to a particular waypoint that is different from the globally defined <tt>alt</tt> above. Note that a waypoint named <tt>HOME</tt> is required as it is used by the failsafe HOME mode procedure.

One example:
<tt>
<waypoints>
<waypoint name="HOME" x="0.0" y="30.0"/>
<waypoint name="1" x="-100.0" y="60.0" alt="270."/>
<waypoint name="2" x="-130.0" y="217.5" alt="3000."/>
</waypoints>
</tt>

Waypoints are easily edited with the [[Flight_Plan_Editor|flight plan editor]].

Waypoints which name starts with an underscore are not displayed in the GCS, except in editor mode.

=== Sectors ===
Flat ''Sectors'' can be described as a list of waypoint corners. Such an area will be displayed in the GCS.
A function is generated to check if a point (usually the aircraft itself) is ''inside'' the polygon. Currently, this feature requires that the polygon is <b>convex</b> and described in a <b>clockwise</b> order. For a sector named <tt>sector</tt>, the generated function is <tt>bool_t InsideSector(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. Note: If the flight plan is dynamically relocated, such a sector will be relocated but the display is currently not updated on the GCS.

For example, with the following element in a flight plan (waypoints which name starts with an underscore are not displayed in the GCS, except in editor mode)
<tt>
<sectors>
<sector name="Muret">
<corner name="_1"/>
<corner name="_2"/>
<corner name="_3"/>
<corner name="_4"/>
</sector>
</sectors>
</tt>
it is then possible to write a exception to stay inside it:
<tt>
<exception cond="! InsideMuret(estimator_x, estimator_y)" deroute="standby"/>
</tt>

=== Include ===

<tt>include</tt> is used to add blocks 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 [x] [y] [rotate] > [<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 jump to the blocks of the <tt>procedure</tt>, the XML referenced file. The
procedure can be shifted (<tt>x</tt> meters east, <tt>y</tt> meters north) and <tt>rotate</tt>d (clockwise degrees, north=0).
Named arguments may be given with their value in the <tt>arg</tt> elements. The <tt>with</tt> tag allows to link labels 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:
<tt><include name="hippo1" procedure="hippo.xml" x="-100" y="150" rotate="0">
<arg name="alt" value="GROUND ALT+100"/>
<with from="event1" to="penta"/>
</include></tt>
where a jump to <tt>event1</tt> inside the <tt>hippo.xml</tt> procedure will actually jump to the <tt>penta</tt> block of the
current flight plan.

=== 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 go 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'':
<tt><!ELEMENT blocks (block+)>
<!ELEMENT block (exception|while|heading|attitude|go|xyz|set|circle|deroute|stay|follow
|survey_rectangle)*></tt>

Example:
<tt><block name="circlehome">
<circle radius="75" wp="HOME"/>
</block></tt>

You can add a button in the [[GCS#Strips|strip of the aircraft]] with the attribute <tt>strip_button</tt>:
<tt><block name="descent" strip_button="Descent">
<circle wp="HOME" throttle="0.0" pitch="-15" vmode="throttle"/>
</block> </tt>
This button will activate the block.

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>:
<tt><block name="Takeoff" strip_icon="takeoff.png" strip_button="Takeoff"></tt>

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

===== 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 examples)
* Some binary operators: <, >, <=, >=, <>, ==, +, -, /, *
* Some utility functions

Some examples of usable expressions are given in the next sections.

==== 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:
<tt><exception cond="..." deroute="..."></tt>
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:
<tt><exception cond="10 > PowerVoltage()" deroute="go_down"/>
<exception cond="(ground_alt+10 > estimator_z)" deroute="go_up"/>
<exception cond="(estimator_flight_time > 840)" deroute="quick_land"/></tt>

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.
<tt><flight_plan ...>
<waypoints> ... </waypoints>
<exceptions>
<exception cond="datalink_time > 22" deroute="Standby"/>
</exceptions>
<blocks> ...</tt>

==== Deroute ====

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

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

==== 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:
<tt><while cond="TRUE">
<go wp="A"/>
<go wp="B"/>
<go wp="C"/>
<while cond="5 > stage_time"/>
</while></tt>
In this example, we run an infinite loop, going to 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:
<tt><for var="i" from="0" to="3">
...
</for></tt>
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:
<tt><for var="i" from="1" to="5">
<circle wp="HOME" radius="75" alt="ground_alt+50*$i" until="stage_time>10" />
</for></tt>
In this example, we circle around '''HOME''' 10 seconds at height 50m, 10s at height 100m, ... until height 250m.
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;
* circle : circle around a waypoint;
* stay : hold the position (hard to realize for a fixed-win 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:
<tt><attitude roll="0" vmode="throttle", throttle="0.5"/></tt>

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

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:
<tt><heading course="QFU" vmode="throttle" throttle="0.8" pitch="15" until="(estimator_z > ground_alt+30)"/></tt>

==== 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
<tt><go wp="HOME"/></tt>
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:
<tt><go from="wp1" wp="wp2" hmode="route"/></tt>

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:
<tt><go from="wp2" wp="wp3" hmode="route" pitch="auto" throttle="0.75" alt="ground_alt+100"/></tt>

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

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).
<tt><go from="wp1" wp="wp2" hmode="route" approaching_time="1"/></tt>

==== 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:
<tt><circle wp="HOME" radius="75"/></tt>
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:
<tt><circle wp="wp1" radius="50+(estimator_z-ground_alt)/2" vmode="throttle" throttle="0.75" pitch="15" until="10>PowerVoltage()"/></tt>

==== 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.
<tt><follow ac_id="4" distance="50" height="20"/></tt>

==== Stay ====

The <tt>stay</tt> is a mode for UAS's able to hover:
<tt><stay wp="HOME" alt="10"/></tt>

==== 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'''):
<tt><xyz radius="40"/></tt>

==== 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):
<tt><set var="ground_alt" value="ground_alt+50"/></tt>
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:
<tt><call fun="nav_line_init()"/>
<call fun="nav_line(WP_1, WP_2, nav_radius)"/></tt>
where <tt>nav_line_init()</tt> returns FALSE and <tt>nav_line()</tt> always returns TRUE (this stage never ends).
Such functions usually are defined in a supplementary C file which must be specified in the airframe file (in the <tt>makefile</tt> section)
<tt>ap.srcs += nav_line.c
sim.srcs += nav_line.c</tt>
These functions also must be declared in a header file which must be mentioned in the header element of the flight plan:
<tt><header>
#include "nav_line.h"
</header></tt>
These C source file and H header file must be located in the <tt>sw/airborne</tt> directory.

== 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:
<for var = "i" from = "1" to = "5">
<circle wp = "HOME" radius="75"
alt = "ground_alt+50*$i"
until = "stage_time>60" />
</for>

== Procedures ==

Procedures are libraries which can be included in flight plans. They are composed of waypoints 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, optional global exceptions and blocks:
<tt><!ELEMENT procedure (param*,waypoints,exceptions?,blocks)></tt>

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:
<tt><param name="alt"/>
<param name="radius" default_value="75"/></tt>

Procedures are called with the <tt>include</tt> element in a flight plan (a procedure cannot be included by another procedure). A procedure call requires:
* the name of the procedure file, the name given to this inclusion;
* the relative position and the orientation of the procedure in the flight plan;
* values for the parameters;
* backlinks for block name exits of the procedure.

For example:
<tt><include name="hippo1" procedure="hippo.xml" x="-100" y="150" rotate="0">
<arg name="alt" value="ground_alt+100"/>
<with from="end" to="landing"/>
</include></tt>

Here is the corresponding procedure '''hippo.xml''':
<tt><procedure>
<param name="alt"/>
<param name="radius" default value="75"/>
<waypoints>
<waypoint name="c1" x="0" y="0"/>
<waypoint name="c2" x="250" y="0"/>
</waypoints>
<blocks>
<block name="oneturn">
<go hmode="route" alt="alt" from="c1" from_qdr="0" from_dist="radius" wp="c2" wp_qdr="0" wp_dist="radius"/>
<circle wp="c2" radius="radius" until="Qdr(180)" alt="alt"/>
<go hmode="route" alt="alt" from="c2" from_qdr="180" from_dist="radius" wp="c1" wp_qdr="180" wp_dist="radius"/>
<circle wp="c1" radius="radius" until="Qdr(0)" alt="alt"/>
<deroute block="end"/>
</block>
</blocks>
</procedure></tt>

Note that the name of procedure block is then '''hippo1.oneturn''':
<tt><deroute block="hippo1.oneturn"/></tt>
will jump to this procedure block.

== Flight Simulation ==
Complex flight plans should always be carefully tested prior to flight. See the [[Simulation|simulation]] page for details.

Flight Plans

2009-03-18T10:01:35Z

Rcbrother:

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 file using the following line:<br>

<tt><!DOCTYPE flight_plan SYSTEM "flight_plan.dtd"></tt>

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 in the GUI.

== Structure of the flight plan file ==

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

A flight plan is composed of two compulsory elements: [[#waypoints|waypoints]] and [[#blocks|blocks]] and typically contains optional <tt>include</tt>'s and global <tt>exceptions</tt>.

The root <tt>flight_plan</tt> element is specified with several attributes:
<tt><flight_plan name lat0 lon0 ground alt security height qfu alt max_dist_from_home></tt>
* <tt>name</tt>: the name of the mission (a text string)
* <tt>lat0, lon0</tt>: describe the latitude and longitude of the point {0,0} in WGS84 degree coordinates
* <tt>ground_alt</tt>: the ground altitude (in meters). It defines the <tt>GROUND_ALT</tt> constant value which can be used to define waypoint altitudes
* <tt>security_height</tt>: the altitude used by the circle-home failsafe procedure
* <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.
* <tt>alt</tt>: the default altitude of waypoints
* <tt>max_dist_from_home</tt>: the maximum allowed distance (in meters) from the HOME waypoint.

Here is an example of the first line of a flight plan:

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

=== Waypoints ===

The waypoints are the geographic locations used to specify the trajectories. A waypoint is specified with its name and its relative coordinates:
<tt> <waypoint name x y [alt] /> </tt>
where <tt>x</tt> and <tt>y</tt> are the coordinates in meters from point {0,0}. <tt>alt</tt> is optional and can be used to assign an altitude to a particular waypoint that is different from the globally defined <tt>alt</tt> above. Note that a waypoint named <tt>HOME</tt> is required as it is used by the failsafe HOME mode procedure.

One example:
<tt>
<waypoints>
<waypoint name="HOME" x="0.0" y="30.0"/>
<waypoint name="1" x="-100.0" y="60.0" alt="270."/>
<waypoint name="2" x="-130.0" y="217.5" alt="3000."/>
</waypoints>
</tt>

Waypoints are easily edited with the [[Flight_Plan_Editor|flight plan editor]].

Waypoints which name starts with an underscore are not displayed in the GCS, except in editor mode.

=== Sectors ===
Flat ''Sectors'' can be described as a list of waypoint corners. Such an area will be displayed in the GCS.
A function is generated to check if a point (usually the aircraft itself) is ''inside'' the polygon. Currently, this feature requires that the polygon is <b>convex</b> and described in a <b>clockwise</b> order. For a sector named <tt>sector</tt>, the generated function is <tt>bool_t InsideSector(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. Note: If the flight plan is dynamically relocated, such a sector will be relocated but the display is currently not updated on the GCS.

For example, with the following element in a flight plan (waypoints which name starts with an underscore are not displayed in the GCS, except in editor mode)
<tt>
<sectors>
<sector name="Muret">
<corner name="_1"/>
<corner name="_2"/>
<corner name="_3"/>
<corner name="_4"/>
</sector>
</sectors>
</tt>
it is then possible to write a exception to stay inside it:
<tt>
<exception cond="! InsideMuret(estimator_x, estimator_y)" deroute="standby"/>
</tt>

=== Include ===

<tt>include</tt> is used to add blocks 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 [x] [y] [rotate] > [<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 jump to the blocks of the <tt>procedure</tt>, the XML referenced file. The
procedure can be shifted (<tt>x</tt> meters east, <tt>y</tt> meters north) and <tt>rotate</tt>d (clockwise degrees, north=0).
Named arguments may be given with their value in the <tt>arg</tt> elements. The <tt>with</tt> tag allows to link labels 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:
<tt><include name="hippo1" procedure="hippo.xml" x="-100" y="150" rotate="0">
<arg name="alt" value="GROUND ALT+100"/>
<with from="event1" to="penta"/>
</include></tt>
where a jump to <tt>event1</tt> inside the <tt>hippo.xml</tt> procedure will actually jump to the <tt>penta</tt> block of the
current flight plan.

=== 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 go 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'':
<tt><!ELEMENT blocks (block+)>
<!ELEMENT block (exception|while|heading|attitude|go|xyz|set|circle|deroute|stay|follow
|survey_rectangle)*></tt>

Example:
<tt><block name="circlehome">
<circle radius="75" wp="HOME"/>
</block></tt>

You can add a button in the [[GCS#Strips|strip of the aircraft]] with the attribute <tt>strip_button</tt>:
<tt><block name="descent" strip_button="Descent">
<circle wp="HOME" throttle="0.0" pitch="-15" vmode="throttle"/>
</block> </tt>
This button will activate the block.

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>:
<tt><block name="Takeoff" strip_icon="takeoff.png" strip_button="Takeoff"></tt>

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

===== 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 examples)
* Some binary operators: <, >, <=, >=, <>, ==, +, -, /, *
* Some utility functions

Some examples of usable expressions are given in the next sections.

==== 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:
<tt><exception cond="..." deroute="..."></tt>
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:
<tt><exception cond="10 > PowerVoltage()" deroute="go_down"/>
<exception cond="(ground_alt+10 > estimator_z)" deroute="go_up"/>
<exception cond="(estimator_flight_time > 840)" deroute="quick_land"/></tt>

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.
<tt><flight_plan ...>
<waypoints> ... </waypoints>
<exceptions>
<exception cond="datalink_time > 22" deroute="Standby"/>
</exceptions>
<blocks> ...</tt>

==== Deroute ====

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

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

==== 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:
<tt><while cond="TRUE">
<go wp="A"/>
<go wp="B"/>
<go wp="C"/>
<while cond="5 > stage_time"/>
</while></tt>
In this example, we run an infinite loop, going to 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:
<tt><for var="i" from="0" to="3">
...
</for></tt>
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:
<tt><for var="i" from="1" to="5">
<circle wp="HOME" radius="75" alt="ground_alt+50*$i" until="stage_time>10" />
</for></tt>
In this example, we circle around '''HOME''' 10 seconds at height 50m, 10s at height 100m, ... until height 250m.
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;
* circle : circle around a waypoint;
* stay : hold the position (hard to realize for a fixed-win 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:
<tt><attitude roll="0" vmode="throttle", throttle="0.5"/></tt>

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

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:
<tt><heading course="QFU" vmode="throttle" throttle="0.8" pitch="15" until="(estimator_z > ground_alt+30)"/></tt>

==== 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
<tt><go wp="HOME"/></tt>
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:
<tt><go from="wp1" wp="wp2" hmode="route"/></tt>

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:
<tt><go from="wp2" wp="wp3" hmode="route" pitch="auto" throttle="0.75" alt="ground_alt+100"/></tt>

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

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).
<tt><go from="wp1" wp="wp2" hmode="route" approaching_time="1"/></tt>

==== 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:
<tt><circle wp="HOME" radius="75"/></tt>
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:
<tt><circle wp="wp1" radius="50+(estimator_z-ground_alt)/2" vmode="throttle" throttle="0.75" pitch="15" until="10>PowerVoltage()"/></tt>

==== 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.
<tt><follow ac_id="4" distance="50" height="20"/></tt>

==== Stay ====

The <tt>stay</tt> is a mode for UAS's able to hover:
<tt><stay wp="HOME" alt="10"/></tt>

==== 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'''):
<tt><xyz radius="40"/></tt>

==== 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):
<tt><set var="ground_alt" value="ground_alt+50"/></tt>
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:
<tt><call fun="nav_line_init()"/>
<call fun="nav_line(WP_1, WP_2, nav_radius)"/></tt>
where <tt>nav_line_init()</tt> returns FALSE and <tt>nav_line()</tt> always returns TRUE (this stage never ends).
Such functions usually are defined in a supplementary C file which must be specified in the airframe file (in the <tt>makefile</tt> section)
<tt>ap.srcs += nav_line.c
sim.srcs += nav_line.c</tt>
These functions also must be declared in a header file which must be mentioned in the header element of the flight plan:
<tt><header>
#include "nav_line.h"
</header></tt>
These C source file and H header file must be located in the <tt>sw/airborne</tt> directory.

== 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:
<for var = "i" from = "1" to = "5">
<circle wp = "HOME" radius="75"
alt = "ground_alt+50*$i"
until = "stage_time>60" />
</for>

== Procedures ==

Procedures are libraries which can be included in flight plans. They are composed of waypoints 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, optional global exceptions and blocks:
<tt><!ELEMENT procedure (param*,waypoints,exceptions?,blocks)></tt>

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:
<tt><param name="alt"/>
<param name="radius" default_value="75"/></tt>

Procedures are called with the <tt>include</tt> element in a flight plan (a procedure cannot be included by another procedure). A procedure call requires:
* the name of the procedure file, the name given to this inclusion;
* the relative position and the orientation of the procedure in the flight plan;
* values for the parameters;
* backlinks for block name exits of the procedure.

For example:
<tt><include name="hippo1" procedure="hippo.xml" x="-100" y="150" rotate="0">
<arg name="alt" value="ground_alt+100"/>
<with from="end" to="landing"/>
</include></tt>

Here is the corresponding procedure '''hippo.xml''':
<tt><procedure>
<param name="alt"/>
<param name="radius" default value="75"/>
<waypoints>
<waypoint name="c1" x="0" y="0"/>
<waypoint name="c2" x="250" y="0"/>
</waypoints>
<blocks>
<block name="oneturn">
<go hmode="route" alt="alt" from="c1" from_qdr="0" from_dist="radius" wp="c2" wp_qdr="0" wp_dist="radius"/>
<circle wp="c2" radius="radius" until="Qdr(180)" alt="alt"/>
<go hmode="route" alt="alt" from="c2" from_qdr="180" from_dist="radius" wp="c1" wp_qdr="180" wp_dist="radius"/>
<circle wp="c1" radius="radius" until="Qdr(0)" alt="alt"/>
<deroute block="end"/>
</block>
</blocks>
</procedure></tt>

Note that the name of procedure block is then '''hippo1.oneturn''':
<tt><deroute block="hippo1.oneturn"/></tt>
will jump to this procedure block.

== Flight Simulation ==
Complex flight plans should always be carefully tested prior to flight. See the [[Simulation|simulation]] page for details.

Flight Plans

2009-03-18T09:46:45Z

Rcbrother: /* Structure of the flight plan file */

The formal description of the flight plan file is given in the DTD (located in <tt>conf/flight_plans/flight_plan.dtd</tt>). This
DTD must be referenced in the header of your flight plan XML file using the following line:<br>

<tt><!DOCTYPE flight_plan SYSTEM "flight_plan.dtd"></tt>

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 in the GUI.

== Structure of the flight plan file ==

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

A flight plan is composed of two compulsory elements: [[#waypoints|waypoints]] and [[#blocks|blocks]] and typically contains optional <tt>include</tt>'s and global <tt>exceptions</tt>.

The root <tt>flight_plan</tt> element is specified with several attributes:
<tt><flight_plan name lat0 lon0 ground alt security height qfu alt max_dist_from_home></tt>
* <tt>name</tt>: the name of the mission (a text string)
* <tt>lat0, lon0</tt>: describe the latitude and longitude of the point {0,0} in WGS84 degree coordinates
* <tt>ground_alt</tt>: the ground altitude (in meters). It defines the <tt>GROUND_ALT</tt> constant value which can be used to define waypoint altitudes
* <tt>security_height</tt>: the altitude used by the circle-home failsafe procedure
* <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.
* <tt>alt</tt>: the default altitude of waypoints
* <tt>max_dist_from_home</tt>: the maximum allowed distance (in meters) from the HOME waypoint.

Here is an example of the first line of a flight plan:

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

=== Waypoints ===

The waypoints are the geographic locations used to specify the trajectories. A waypoint is specified with its name and its relative coordinates:
<tt> <waypoint name x y [alt] /> </tt>
where <tt>x</tt> and <tt>y</tt> are the coordinates in meters from point {0,0}. <tt>alt</tt> is optional and can be used to assign an altitude to a particular waypoint that is different from the globally defined <tt>alt</tt> above. Note that a waypoint named <tt>HOME</tt> is required as it is used by the failsafe HOME mode procedure.

One example:
<tt>
<waypoints>
<waypoint name="HOME" x="0.0" y="30.0"/>
<waypoint name="1" x="-100.0" y="60.0" alt="270."/>
<waypoint name="2" x="-130.0" y="217.5" alt="3000."/>
</waypoints>
</tt>

Waypoints are easily edited with the [[Flight_Plan_Editor|flight plan editor]].

Waypoints which name starts with an underscore are not displayed in the GCS, except in editor mode.

=== Sectors ===
Flat ''Sectors'' can be described as a list of waypoint corners. Such an area will be displayed in the GCS.
A function is generated to check if a point (usually the aircraft itself) is ''inside'' the polygon. Currently, this feature requires that the polygon is <b>convex</b> and described in a <b>clockwise</b> order. For a sector named <tt>sector</tt>, the generated function is <tt>bool_t InsideSector(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. Note: If the flight plan is dynamically relocated, such a sector will be relocated but the display is currently not updated on the GCS.

For example, with the following element in a flight plan (waypoints which name starts with an underscore are not displayed in the GCS, except in editor mode)
<tt>
<sectors>
<sector name="Muret">
<corner name="_1"/>
<corner name="_2"/>
<corner name="_3"/>
<corner name="_4"/>
</sector>
</sectors>
</tt>
it is then possible to write a exception to stay inside it:
<tt>
<exception cond="! InsideMuret(estimator_x, estimator_y)" deroute="standby"/>
</tt>

=== Include ===

<tt>include</tt> is used to add blocks 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 [x] [y] [rotate] > [<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 jump to the blocks of the <tt>procedure</tt>, the XML referenced file. The
procedure can be shifted (<tt>x</tt> meters east, <tt>y</tt> meters north) and <tt>rotate</tt>d (clockwise degrees, north=0).
Named arguments may be given with their value in the <tt>arg</tt> elements. The <tt>with</tt> tag allows to link labels 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:
<tt><include name="hippo1" procedure="hippo.xml" x="-100" y="150" rotate="0">
<arg name="alt" value="GROUND ALT+100"/>
<with from="event1" to="penta"/>
</include></tt>
where a jump to <tt>event1</tt> inside the <tt>hippo.xml</tt> procedure will actually jump to the <tt>penta</tt> block of the
current flight plan.

=== 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 go 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'':
<tt><!ELEMENT blocks (block+)>
<!ELEMENT block (exception|while|heading|attitude|go|xyz|set|circle|deroute|stay|follow
|survey_rectangle)*></tt>

Example:
<tt><block name="circlehome">
<circle radius="75" wp="HOME"/>
</block></tt>

You can add a button in the [[GCS#Strips|strip of the aircraft]] with the attribute <tt>strip_button</tt>:
<tt><block name="descent" strip_button="Descent">
<circle wp="HOME" throttle="0.0" pitch="-15" vmode="throttle"/>
</block> </tt>
This button will activate the block.

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>:
<tt><block name="Takeoff" strip_icon="takeoff.png" strip_button="Takeoff"></tt>

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

===== 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 examples)
* Some binary operators: <, >, <=, >=, <>, ==, +, -, /, *
* Some utility functions

Some examples of usable expressions are given in the next sections.

==== 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:
<tt><exception cond="..." deroute="..."></tt>
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:
<tt><exception cond="10 > PowerVoltage()" deroute="go_down"/>
<exception cond="(ground_alt+10 > estimator_z)" deroute="go_up"/>
<exception cond="(estimator_flight_time > 840)" deroute="quick_land"/></tt>

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.
<tt><flight_plan ...>
<waypoints> ... </waypoints>
<exceptions>
<exception cond="datalink_time > 22" deroute="Standby"/>
</exceptions>
<blocks> ...</tt>

==== Deroute ====

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

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

==== 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:
<tt><while cond="TRUE">
<go wp="A"/>
<go wp="B"/>
<go wp="C"/>
<while cond="5 > stage_time"/>
</while></tt>
In this example, we run an infinite loop, going to 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:
<tt><for var="i" from="0" to="3">
...
</for></tt>
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:
<tt><for var="i" from="1" to="5">
<circle wp="HOME" radius="75" alt="ground_alt+50*$i" until="stage_time>10" />
</for></tt>
In this example, we circle around '''HOME''' 10 seconds at height 50m, 10s at height 100m, ... until height 250m.
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;
* circle : circle around a waypoint;
* stay : hold the position (hard to realize for a fixed-win 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:
<tt><attitude roll="0" vmode="throttle", throttle="0.5"/></tt>

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

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:
<tt><heading course="QFU" vmode="throttle" throttle="0.8" pitch="15" until="(estimator_z > ground_alt+30)"/></tt>

==== 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
<tt><go wp="HOME"/></tt>
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:
<tt><go from="wp1" wp="wp2" hmode="route"/></tt>

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:
<tt><go from="wp2" wp="wp3" hmode="route" pitch="auto" throttle="0.75" alt="ground_alt+100"/></tt>

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

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).
<tt><go from="wp1" wp="wp2" hmode="route" approaching_time="1"/></tt>

==== 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:
<tt><circle wp="HOME" radius="75"/></tt>
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:
<tt><circle wp="wp1" radius="50+(estimator_z-ground_alt)/2" vmode="throttle" throttle="0.75" pitch="15" until="10>PowerVoltage()"/></tt>

==== 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.
<tt><follow ac_id="4" distance="50" height="20"/></tt>

==== Stay ====

The <tt>stay</tt> is a mode for UAS's able to hover:
<tt><stay wp="HOME" alt="10"/></tt>

==== 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'''):
<tt><xyz radius="40"/></tt>

==== 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):
<tt><set var="ground_alt" value="ground_alt+50"/></tt>
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:
<tt><call fun="nav_line_init()"/>
<call fun="nav_line(WP_1, WP_2, nav_radius)"/></tt>
where <tt>nav_line_init()</tt> returns FALSE and <tt>nav_line()</tt> always returns TRUE (this stage never ends).
Such functions usually are defined in a supplementary C file which must be specified in the airframe file (in the <tt>makefile</tt> section)
<tt>ap.srcs += nav_line.c
sim.srcs += nav_line.c</tt>
These functions also must be declared in a header file which must be mentioned in the header element of the flight plan:
<tt><header>
#include "nav_line.h"
</header></tt>
These C source file and H header file must be located in the <tt>sw/airborne</tt> directory.

== 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:
<for var = "i" from = "1" to = "5">
<circle wp = "HOME" radius="75"
alt = "ground_alt+50*$i"
until = "stage_time>60" />
</for>

== Procedures ==

Procedures are libraries which can be included in flight plans. They are composed of waypoints 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, optional global exceptions and blocks:
<tt><!ELEMENT procedure (param*,waypoints,exceptions?,blocks)></tt>

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:
<tt><param name="alt"/>
<param name="radius" default_value="75"/></tt>

Procedures are called with the <tt>include</tt> element in a flight plan (a procedure cannot be included by another procedure). A procedure call requires:
* the name of the procedure file, the name given to this inclusion;
* the relative position and the orientation of the procedure in the flight plan;
* values for the parameters;
* backlinks for block name exits of the procedure.

For example:
<tt><include name="hippo1" procedure="hippo.xml" x="-100" y="150" rotate="0">
<arg name="alt" value="ground_alt+100"/>
<with from="end" to="landing"/>
</include></tt>

Here is the corresponding procedure '''hippo.xml''':
<tt><procedure>
<param name="alt"/>
<param name="radius" default value="75"/>
<waypoints>
<waypoint name="c1" x="0" y="0"/>
<waypoint name="c2" x="250" y="0"/>
</waypoints>
<blocks>
<block name="oneturn">
<go hmode="route" alt="alt" from="c1" from_qdr="0" from_dist="radius" wp="c2" wp_qdr="0" wp_dist="radius"/>
<circle wp="c2" radius="radius" until="Qdr(180)" alt="alt"/>
<go hmode="route" alt="alt" from="c2" from_qdr="180" from_dist="radius" wp="c1" wp_qdr="180" wp_dist="radius"/>
<circle wp="c1" radius="radius" until="Qdr(0)" alt="alt"/>
<deroute block="end"/>
</block>
</blocks>
</procedure></tt>

Note that the name of procedure block is then '''hippo1.oneturn''':
<tt><deroute block="hippo1.oneturn"/></tt>
will jump to this procedure block.

== Flight Simulation ==
Complex flight plans should always be carefully tested prior to flight. See the [[Simulation|simulation]] page for details.

Flight Plans

2009-03-18T09:38:29Z

Rcbrother: /* Circle */

The formal description of the flight plan file is given in the DTD (located in <tt>conf/flight_plans/flight_plan.dtd</tt>). This
DTD must be referenced in the header of your flight plan XML file using the following line:<br>

<tt><!DOCTYPE flight_plan SYSTEM "flight_plan.dtd"></tt>

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 in the GUI.

== Structure of the flight plan file ==

Extract from the DTD:
<tt><!ELEMENT flight_plan (header?,waypoints,sectors?,include*,exceptions?,blocks)></tt>

A flight plan is composed of two compulsory elements: [[#waypoints|waypoints]] and [[#blocks|blocks]] and typically contains optional <tt>include</tt>'s and global <tt>exceptions</tt>.

The root <tt>flight_plan</tt> element is specified with several attributes:
<tt><flight_plan name lat0 lon0 ground alt security height qfu alt max_dist_from_home></tt>
* <tt>name</tt>: the name of the mission (a text string)
* <tt>lat0, lon0</tt>: describe the latitude and longitude of the point {0,0} in WGS84 degree coordinates
* <tt>ground_alt</tt>: the ground altitude (in meters). It defines the <tt>GROUND_ALT</tt> constant value which can be used to define waypoint altitudes
* <tt>security_height</tt>: the altitude used by the circle-home failsafe procedure
* <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.
* <tt>alt</tt>: the default altitude of waypoints
* <tt>max_dist_from_home</tt>: the maximum allowed distance (in meters) from the HOME waypoint.

Here is an example of the first line of a flight plan:

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

=== Waypoints ===

The waypoints are the geographic locations used to specify the trajectories. A waypoint is specified with its name and its relative coordinates:
<tt> <waypoint name x y [alt] /> </tt>
where <tt>x</tt> and <tt>y</tt> are the coordinates in meters from point {0,0}. <tt>alt</tt> is optional and can be used to assign an altitude to a particular waypoint that is different from the globally defined <tt>alt</tt> above. Note that a waypoint named <tt>HOME</tt> is required as it is used by the failsafe HOME mode procedure.

One example:
<tt>
<waypoints>
<waypoint name="HOME" x="0.0" y="30.0"/>
<waypoint name="1" x="-100.0" y="60.0" alt="270."/>
<waypoint name="2" x="-130.0" y="217.5" alt="3000."/>
</waypoints>
</tt>

Waypoints are easily edited with the [[Flight_Plan_Editor|flight plan editor]].

Waypoints which name starts with an underscore are not displayed in the GCS, except in editor mode.

=== Sectors ===
Flat ''Sectors'' can be described as a list of waypoint corners. Such an area will be displayed in the GCS.
A function is generated to check if a point (usually the aircraft itself) is ''inside'' the polygon. Currently, this feature requires that the polygon is <b>convex</b> and described in a <b>clockwise</b> order. For a sector named <tt>sector</tt>, the generated function is <tt>bool_t InsideSector(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. Note: If the flight plan is dynamically relocated, such a sector will be relocated but the display is currently not updated on the GCS.

For example, with the following element in a flight plan (waypoints which name starts with an underscore are not displayed in the GCS, except in editor mode)
<tt>
<sectors>
<sector name="Muret">
<corner name="_1"/>
<corner name="_2"/>
<corner name="_3"/>
<corner name="_4"/>
</sector>
</sectors>
</tt>
it is then possible to write a exception to stay inside it:
<tt>
<exception cond="! InsideMuret(estimator_x, estimator_y)" deroute="standby"/>
</tt>

=== Include ===

<tt>include</tt> is used to add blocks 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 [x] [y] [rotate] > [<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 jump to the blocks of the <tt>procedure</tt>, the XML referenced file. The
procedure can be shifted (<tt>x</tt> meters east, <tt>y</tt> meters north) and <tt>rotate</tt>d (clockwise degrees, north=0).
Named arguments may be given with their value in the <tt>arg</tt> elements. The <tt>with</tt> tag allows to link labels 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:
<tt><include name="hippo1" procedure="hippo.xml" x="-100" y="150" rotate="0">
<arg name="alt" value="GROUND ALT+100"/>
<with from="event1" to="penta"/>
</include></tt>
where a jump to <tt>event1</tt> inside the <tt>hippo.xml</tt> procedure will actually jump to the <tt>penta</tt> block of the
current flight plan.

=== 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 go 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'':
<tt><!ELEMENT blocks (block+)>
<!ELEMENT block (exception|while|heading|attitude|go|xyz|set|circle|deroute|stay|follow
|survey_rectangle)*></tt>

Example:
<tt><block name="circlehome">
<circle radius="75" wp="HOME"/>
</block></tt>

You can add a button in the [[GCS#Strips|strip of the aircraft]] with the attribute <tt>strip_button</tt>:
<tt><block name="descent" strip_button="Descent">
<circle wp="HOME" throttle="0.0" pitch="-15" vmode="throttle"/>
</block> </tt>
This button will activate the block.

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>:
<tt><block name="Takeoff" strip_icon="takeoff.png" strip_button="Takeoff"></tt>

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

===== 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 examples)
* Some binary operators: <, >, <=, >=, <>, ==, +, -, /, *
* Some utility functions

Some examples of usable expressions are given in the next sections.

==== 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:
<tt><exception cond="..." deroute="..."></tt>
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:
<tt><exception cond="10 > PowerVoltage()" deroute="go_down"/>
<exception cond="(ground_alt+10 > estimator_z)" deroute="go_up"/>
<exception cond="(estimator_flight_time > 840)" deroute="quick_land"/></tt>

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.
<tt><flight_plan ...>
<waypoints> ... </waypoints>
<exceptions>
<exception cond="datalink_time > 22" deroute="Standby"/>
</exceptions>
<blocks> ...</tt>

==== Deroute ====

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

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

==== 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:
<tt><while cond="TRUE">
<go wp="A"/>
<go wp="B"/>
<go wp="C"/>
<while cond="5 > stage_time"/>
</while></tt>
In this example, we run an infinite loop, going to 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:
<tt><for var="i" from="0" to="3">
...
</for></tt>
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:
<tt><for var="i" from="1" to="5">
<circle wp="HOME" radius="75" alt="ground_alt+50*$i" until="stage_time>10" />
</for></tt>
In this example, we circle around '''HOME''' 10 seconds at height 50m, 10s at height 100m, ... until height 250m.
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;
* circle : circle around a waypoint;
* stay : hold the position (hard to realize for a fixed-win 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:
<tt><attitude roll="0" vmode="throttle", throttle="0.5"/></tt>

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

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:
<tt><heading course="QFU" vmode="throttle" throttle="0.8" pitch="15" until="(estimator_z > ground_alt+30)"/></tt>

==== 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
<tt><go wp="HOME"/></tt>
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:
<tt><go from="wp1" wp="wp2" hmode="route"/></tt>

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:
<tt><go from="wp2" wp="wp3" hmode="route" pitch="auto" throttle="0.75" alt="ground_alt+100"/></tt>

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

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).
<tt><go from="wp1" wp="wp2" hmode="route" approaching_time="1"/></tt>

==== 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:
<tt><circle wp="HOME" radius="75"/></tt>
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:
<tt><circle wp="wp1" radius="50+(estimator_z-ground_alt)/2" vmode="throttle" throttle="0.75" pitch="15" until="10>PowerVoltage()"/></tt>

==== 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.
<tt><follow ac_id="4" distance="50" height="20"/></tt>

==== Stay ====

The <tt>stay</tt> is a mode for UAS's able to hover:
<tt><stay wp="HOME" alt="10"/></tt>

==== 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'''):
<tt><xyz radius="40"/></tt>

==== 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):
<tt><set var="ground_alt" value="ground_alt+50"/></tt>
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:
<tt><call fun="nav_line_init()"/>
<call fun="nav_line(WP_1, WP_2, nav_radius)"/></tt>
where <tt>nav_line_init()</tt> returns FALSE and <tt>nav_line()</tt> always returns TRUE (this stage never ends).
Such functions usually are defined in a supplementary C file which must be specified in the airframe file (in the <tt>makefile</tt> section)
<tt>ap.srcs += nav_line.c
sim.srcs += nav_line.c</tt>
These functions also must be declared in a header file which must be mentioned in the header element of the flight plan:
<tt><header>
#include "nav_line.h"
</header></tt>
These C source file and H header file must be located in the <tt>sw/airborne</tt> directory.

== 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:
<for var = "i" from = "1" to = "5">
<circle wp = "HOME" radius="75"
alt = "ground_alt+50*$i"
until = "stage_time>60" />
</for>

== Procedures ==

Procedures are libraries which can be included in flight plans. They are composed of waypoints 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, optional global exceptions and blocks:
<tt><!ELEMENT procedure (param*,waypoints,exceptions?,blocks)></tt>

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:
<tt><param name="alt"/>
<param name="radius" default_value="75"/></tt>

Procedures are called with the <tt>include</tt> element in a flight plan (a procedure cannot be included by another procedure). A procedure call requires:
* the name of the procedure file, the name given to this inclusion;
* the relative position and the orientation of the procedure in the flight plan;
* values for the parameters;
* backlinks for block name exits of the procedure.

For example:
<tt><include name="hippo1" procedure="hippo.xml" x="-100" y="150" rotate="0">
<arg name="alt" value="ground_alt+100"/>
<with from="end" to="landing"/>
</include></tt>

Here is the corresponding procedure '''hippo.xml''':
<tt><procedure>
<param name="alt"/>
<param name="radius" default value="75"/>
<waypoints>
<waypoint name="c1" x="0" y="0"/>
<waypoint name="c2" x="250" y="0"/>
</waypoints>
<blocks>
<block name="oneturn">
<go hmode="route" alt="alt" from="c1" from_qdr="0" from_dist="radius" wp="c2" wp_qdr="0" wp_dist="radius"/>
<circle wp="c2" radius="radius" until="Qdr(180)" alt="alt"/>
<go hmode="route" alt="alt" from="c2" from_qdr="180" from_dist="radius" wp="c1" wp_qdr="180" wp_dist="radius"/>
<circle wp="c1" radius="radius" until="Qdr(0)" alt="alt"/>
<deroute block="end"/>
</block>
</blocks>
</procedure></tt>

Note that the name of procedure block is then '''hippo1.oneturn''':
<tt><deroute block="hippo1.oneturn"/></tt>
will jump to this procedure block.

== Flight Simulation ==
Complex flight plans should always be carefully tested prior to flight. See the [[Simulation|simulation]] page for details.

Flight Plans

2009-03-18T09:37:38Z

Rcbrother: /* Stay */

The formal description of the flight plan file is given in the DTD (located in <tt>conf/flight_plans/flight_plan.dtd</tt>). This
DTD must be referenced in the header of your flight plan XML file using the following line:<br>

<tt><!DOCTYPE flight_plan SYSTEM "flight_plan.dtd"></tt>

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 in the GUI.

== Structure of the flight plan file ==

Extract from the DTD:
<tt><!ELEMENT flight_plan (header?,waypoints,sectors?,include*,exceptions?,blocks)></tt>

A flight plan is composed of two compulsory elements: [[#waypoints|waypoints]] and [[#blocks|blocks]] and typically contains optional <tt>include</tt>'s and global <tt>exceptions</tt>.

The root <tt>flight_plan</tt> element is specified with several attributes:
<tt><flight_plan name lat0 lon0 ground alt security height qfu alt max_dist_from_home></tt>
* <tt>name</tt>: the name of the mission (a text string)
* <tt>lat0, lon0</tt>: describe the latitude and longitude of the point {0,0} in WGS84 degree coordinates
* <tt>ground_alt</tt>: the ground altitude (in meters). It defines the <tt>GROUND_ALT</tt> constant value which can be used to define waypoint altitudes
* <tt>security_height</tt>: the altitude used by the circle-home failsafe procedure
* <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.
* <tt>alt</tt>: the default altitude of waypoints
* <tt>max_dist_from_home</tt>: the maximum allowed distance (in meters) from the HOME waypoint.

Here is an example of the first line of a flight plan:

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

=== Waypoints ===

The waypoints are the geographic locations used to specify the trajectories. A waypoint is specified with its name and its relative coordinates:
<tt> <waypoint name x y [alt] /> </tt>
where <tt>x</tt> and <tt>y</tt> are the coordinates in meters from point {0,0}. <tt>alt</tt> is optional and can be used to assign an altitude to a particular waypoint that is different from the globally defined <tt>alt</tt> above. Note that a waypoint named <tt>HOME</tt> is required as it is used by the failsafe HOME mode procedure.

One example:
<tt>
<waypoints>
<waypoint name="HOME" x="0.0" y="30.0"/>
<waypoint name="1" x="-100.0" y="60.0" alt="270."/>
<waypoint name="2" x="-130.0" y="217.5" alt="3000."/>
</waypoints>
</tt>

Waypoints are easily edited with the [[Flight_Plan_Editor|flight plan editor]].

Waypoints which name starts with an underscore are not displayed in the GCS, except in editor mode.

=== Sectors ===
Flat ''Sectors'' can be described as a list of waypoint corners. Such an area will be displayed in the GCS.
A function is generated to check if a point (usually the aircraft itself) is ''inside'' the polygon. Currently, this feature requires that the polygon is <b>convex</b> and described in a <b>clockwise</b> order. For a sector named <tt>sector</tt>, the generated function is <tt>bool_t InsideSector(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. Note: If the flight plan is dynamically relocated, such a sector will be relocated but the display is currently not updated on the GCS.

For example, with the following element in a flight plan (waypoints which name starts with an underscore are not displayed in the GCS, except in editor mode)
<tt>
<sectors>
<sector name="Muret">
<corner name="_1"/>
<corner name="_2"/>
<corner name="_3"/>
<corner name="_4"/>
</sector>
</sectors>
</tt>
it is then possible to write a exception to stay inside it:
<tt>
<exception cond="! InsideMuret(estimator_x, estimator_y)" deroute="standby"/>
</tt>

=== Include ===

<tt>include</tt> is used to add blocks 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 [x] [y] [rotate] > [<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 jump to the blocks of the <tt>procedure</tt>, the XML referenced file. The
procedure can be shifted (<tt>x</tt> meters east, <tt>y</tt> meters north) and <tt>rotate</tt>d (clockwise degrees, north=0).
Named arguments may be given with their value in the <tt>arg</tt> elements. The <tt>with</tt> tag allows to link labels 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:
<tt><include name="hippo1" procedure="hippo.xml" x="-100" y="150" rotate="0">
<arg name="alt" value="GROUND ALT+100"/>
<with from="event1" to="penta"/>
</include></tt>
where a jump to <tt>event1</tt> inside the <tt>hippo.xml</tt> procedure will actually jump to the <tt>penta</tt> block of the
current flight plan.

=== 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 go 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'':
<tt><!ELEMENT blocks (block+)>
<!ELEMENT block (exception|while|heading|attitude|go|xyz|set|circle|deroute|stay|follow
|survey_rectangle)*></tt>

Example:
<tt><block name="circlehome">
<circle radius="75" wp="HOME"/>
</block></tt>

You can add a button in the [[GCS#Strips|strip of the aircraft]] with the attribute <tt>strip_button</tt>:
<tt><block name="descent" strip_button="Descent">
<circle wp="HOME" throttle="0.0" pitch="-15" vmode="throttle"/>
</block> </tt>
This button will activate the block.

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>:
<tt><block name="Takeoff" strip_icon="takeoff.png" strip_button="Takeoff"></tt>

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

===== 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 examples)
* Some binary operators: <, >, <=, >=, <>, ==, +, -, /, *
* Some utility functions

Some examples of usable expressions are given in the next sections.

==== 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:
<tt><exception cond="..." deroute="..."></tt>
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:
<tt><exception cond="10 > PowerVoltage()" deroute="go_down"/>
<exception cond="(ground_alt+10 > estimator_z)" deroute="go_up"/>
<exception cond="(estimator_flight_time > 840)" deroute="quick_land"/></tt>

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.
<tt><flight_plan ...>
<waypoints> ... </waypoints>
<exceptions>
<exception cond="datalink_time > 22" deroute="Standby"/>
</exceptions>
<blocks> ...</tt>

==== Deroute ====

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

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

==== 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:
<tt><while cond="TRUE">
<go wp="A"/>
<go wp="B"/>
<go wp="C"/>
<while cond="5 > stage_time"/>
</while></tt>
In this example, we run an infinite loop, going to 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:
<tt><for var="i" from="0" to="3">
...
</for></tt>
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:
<tt><for var="i" from="1" to="5">
<circle wp="HOME" radius="75" alt="ground_alt+50*$i" until="stage_time>10" />
</for></tt>
In this example, we circle around '''HOME''' 10 seconds at height 50m, 10s at height 100m, ... until height 250m.
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;
* circle : circle around a waypoint;
* stay : hold the position (hard to realize for a fixed-win 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:
<tt><attitude roll="0" vmode="throttle", throttle="0.5"/></tt>

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

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:
<tt><heading course="QFU" vmode="throttle" throttle="0.8" pitch="15" until="(estimator_z > ground_alt+30)"/></tt>

==== 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
<tt><go wp="HOME"/></tt>
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:
<tt><go from="wp1" wp="wp2" hmode="route"/></tt>

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:
<tt><go from="wp2" wp="wp3" hmode="route" pitch="auto" throttle="0.75" alt="ground_alt+100"/></tt>

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

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).
<tt><go from="wp1" wp="wp2" hmode="route" approaching_time="1"/></tt>

==== 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:
<tt><circle wp="HOME" radius="75"/></tt>
A positive radius makes the UAV fly 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:
<tt><circle wp="wp1" radius="50+(estimator_z-ground_alt)/2" vmode="throttle" throttle="0.75" pitch="15" until="10>PowerVoltage()"/></tt>

==== 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.
<tt><follow ac_id="4" distance="50" height="20"/></tt>

==== Stay ====

The <tt>stay</tt> is a mode for UAS's able to hover:
<tt><stay wp="HOME" alt="10"/></tt>

==== 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'''):
<tt><xyz radius="40"/></tt>

==== 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):
<tt><set var="ground_alt" value="ground_alt+50"/></tt>
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:
<tt><call fun="nav_line_init()"/>
<call fun="nav_line(WP_1, WP_2, nav_radius)"/></tt>
where <tt>nav_line_init()</tt> returns FALSE and <tt>nav_line()</tt> always returns TRUE (this stage never ends).
Such functions usually are defined in a supplementary C file which must be specified in the airframe file (in the <tt>makefile</tt> section)
<tt>ap.srcs += nav_line.c
sim.srcs += nav_line.c</tt>
These functions also must be declared in a header file which must be mentioned in the header element of the flight plan:
<tt><header>
#include "nav_line.h"
</header></tt>
These C source file and H header file must be located in the <tt>sw/airborne</tt> directory.

== 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:
<for var = "i" from = "1" to = "5">
<circle wp = "HOME" radius="75"
alt = "ground_alt+50*$i"
until = "stage_time>60" />
</for>

== Procedures ==

Procedures are libraries which can be included in flight plans. They are composed of waypoints 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, optional global exceptions and blocks:
<tt><!ELEMENT procedure (param*,waypoints,exceptions?,blocks)></tt>

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:
<tt><param name="alt"/>
<param name="radius" default_value="75"/></tt>

Procedures are called with the <tt>include</tt> element in a flight plan (a procedure cannot be included by another procedure). A procedure call requires:
* the name of the procedure file, the name given to this inclusion;
* the relative position and the orientation of the procedure in the flight plan;
* values for the parameters;
* backlinks for block name exits of the procedure.

For example:
<tt><include name="hippo1" procedure="hippo.xml" x="-100" y="150" rotate="0">
<arg name="alt" value="ground_alt+100"/>
<with from="end" to="landing"/>
</include></tt>

Here is the corresponding procedure '''hippo.xml''':
<tt><procedure>
<param name="alt"/>
<param name="radius" default value="75"/>
<waypoints>
<waypoint name="c1" x="0" y="0"/>
<waypoint name="c2" x="250" y="0"/>
</waypoints>
<blocks>
<block name="oneturn">
<go hmode="route" alt="alt" from="c1" from_qdr="0" from_dist="radius" wp="c2" wp_qdr="0" wp_dist="radius"/>
<circle wp="c2" radius="radius" until="Qdr(180)" alt="alt"/>
<go hmode="route" alt="alt" from="c2" from_qdr="180" from_dist="radius" wp="c1" wp_qdr="180" wp_dist="radius"/>
<circle wp="c1" radius="radius" until="Qdr(0)" alt="alt"/>
<deroute block="end"/>
</block>
</blocks>
</procedure></tt>

Note that the name of procedure block is then '''hippo1.oneturn''':
<tt><deroute block="hippo1.oneturn"/></tt>
will jump to this procedure block.

== Flight Simulation ==
Complex flight plans should always be carefully tested prior to flight. See the [[Simulation|simulation]] page for details.

Flight Plans

2009-03-18T09:37:11Z

Rcbrother: /* Xyz */

The formal description of the flight plan file is given in the DTD (located in <tt>conf/flight_plans/flight_plan.dtd</tt>). This
DTD must be referenced in the header of your flight plan XML file using the following line:<br>

<tt><!DOCTYPE flight_plan SYSTEM "flight_plan.dtd"></tt>

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 in the GUI.

== Structure of the flight plan file ==

Extract from the DTD:
<tt><!ELEMENT flight_plan (header?,waypoints,sectors?,include*,exceptions?,blocks)></tt>

A flight plan is composed of two compulsory elements: [[#waypoints|waypoints]] and [[#blocks|blocks]] and typically contains optional <tt>include</tt>'s and global <tt>exceptions</tt>.

The root <tt>flight_plan</tt> element is specified with several attributes:
<tt><flight_plan name lat0 lon0 ground alt security height qfu alt max_dist_from_home></tt>
* <tt>name</tt>: the name of the mission (a text string)
* <tt>lat0, lon0</tt>: describe the latitude and longitude of the point {0,0} in WGS84 degree coordinates
* <tt>ground_alt</tt>: the ground altitude (in meters). It defines the <tt>GROUND_ALT</tt> constant value which can be used to define waypoint altitudes
* <tt>security_height</tt>: the altitude used by the circle-home failsafe procedure
* <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.
* <tt>alt</tt>: the default altitude of waypoints
* <tt>max_dist_from_home</tt>: the maximum allowed distance (in meters) from the HOME waypoint.

Here is an example of the first line of a flight plan:

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

=== Waypoints ===

The waypoints are the geographic locations used to specify the trajectories. A waypoint is specified with its name and its relative coordinates:
<tt> <waypoint name x y [alt] /> </tt>
where <tt>x</tt> and <tt>y</tt> are the coordinates in meters from point {0,0}. <tt>alt</tt> is optional and can be used to assign an altitude to a particular waypoint that is different from the globally defined <tt>alt</tt> above. Note that a waypoint named <tt>HOME</tt> is required as it is used by the failsafe HOME mode procedure.

One example:
<tt>
<waypoints>
<waypoint name="HOME" x="0.0" y="30.0"/>
<waypoint name="1" x="-100.0" y="60.0" alt="270."/>
<waypoint name="2" x="-130.0" y="217.5" alt="3000."/>
</waypoints>
</tt>

Waypoints are easily edited with the [[Flight_Plan_Editor|flight plan editor]].

Waypoints which name starts with an underscore are not displayed in the GCS, except in editor mode.

=== Sectors ===
Flat ''Sectors'' can be described as a list of waypoint corners. Such an area will be displayed in the GCS.
A function is generated to check if a point (usually the aircraft itself) is ''inside'' the polygon. Currently, this feature requires that the polygon is <b>convex</b> and described in a <b>clockwise</b> order. For a sector named <tt>sector</tt>, the generated function is <tt>bool_t InsideSector(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. Note: If the flight plan is dynamically relocated, such a sector will be relocated but the display is currently not updated on the GCS.

For example, with the following element in a flight plan (waypoints which name starts with an underscore are not displayed in the GCS, except in editor mode)
<tt>
<sectors>
<sector name="Muret">
<corner name="_1"/>
<corner name="_2"/>
<corner name="_3"/>
<corner name="_4"/>
</sector>
</sectors>
</tt>
it is then possible to write a exception to stay inside it:
<tt>
<exception cond="! InsideMuret(estimator_x, estimator_y)" deroute="standby"/>
</tt>

=== Include ===

<tt>include</tt> is used to add blocks 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 [x] [y] [rotate] > [<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 jump to the blocks of the <tt>procedure</tt>, the XML referenced file. The
procedure can be shifted (<tt>x</tt> meters east, <tt>y</tt> meters north) and <tt>rotate</tt>d (clockwise degrees, north=0).
Named arguments may be given with their value in the <tt>arg</tt> elements. The <tt>with</tt> tag allows to link labels 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:
<tt><include name="hippo1" procedure="hippo.xml" x="-100" y="150" rotate="0">
<arg name="alt" value="GROUND ALT+100"/>
<with from="event1" to="penta"/>
</include></tt>
where a jump to <tt>event1</tt> inside the <tt>hippo.xml</tt> procedure will actually jump to the <tt>penta</tt> block of the
current flight plan.

=== 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 go 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'':
<tt><!ELEMENT blocks (block+)>
<!ELEMENT block (exception|while|heading|attitude|go|xyz|set|circle|deroute|stay|follow
|survey_rectangle)*></tt>

Example:
<tt><block name="circlehome">
<circle radius="75" wp="HOME"/>
</block></tt>

You can add a button in the [[GCS#Strips|strip of the aircraft]] with the attribute <tt>strip_button</tt>:
<tt><block name="descent" strip_button="Descent">
<circle wp="HOME" throttle="0.0" pitch="-15" vmode="throttle"/>
</block> </tt>
This button will activate the block.

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>:
<tt><block name="Takeoff" strip_icon="takeoff.png" strip_button="Takeoff"></tt>

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

===== 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 examples)
* Some binary operators: <, >, <=, >=, <>, ==, +, -, /, *
* Some utility functions

Some examples of usable expressions are given in the next sections.

==== 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:
<tt><exception cond="..." deroute="..."></tt>
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:
<tt><exception cond="10 > PowerVoltage()" deroute="go_down"/>
<exception cond="(ground_alt+10 > estimator_z)" deroute="go_up"/>
<exception cond="(estimator_flight_time > 840)" deroute="quick_land"/></tt>

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.
<tt><flight_plan ...>
<waypoints> ... </waypoints>
<exceptions>
<exception cond="datalink_time > 22" deroute="Standby"/>
</exceptions>
<blocks> ...</tt>

==== Deroute ====

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

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

==== 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:
<tt><while cond="TRUE">
<go wp="A"/>
<go wp="B"/>
<go wp="C"/>
<while cond="5 > stage_time"/>
</while></tt>
In this example, we run an infinite loop, going to 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:
<tt><for var="i" from="0" to="3">
...
</for></tt>
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:
<tt><for var="i" from="1" to="5">
<circle wp="HOME" radius="75" alt="ground_alt+50*$i" until="stage_time>10" />
</for></tt>
In this example, we circle around '''HOME''' 10 seconds at height 50m, 10s at height 100m, ... until height 250m.
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;
* circle : circle around a waypoint;
* stay : hold the position (hard to realize for a fixed-win 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:
<tt><attitude roll="0" vmode="throttle", throttle="0.5"/></tt>

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

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:
<tt><heading course="QFU" vmode="throttle" throttle="0.8" pitch="15" until="(estimator_z > ground_alt+30)"/></tt>

==== 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
<tt><go wp="HOME"/></tt>
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:
<tt><go from="wp1" wp="wp2" hmode="route"/></tt>

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:
<tt><go from="wp2" wp="wp3" hmode="route" pitch="auto" throttle="0.75" alt="ground_alt+100"/></tt>

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

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).
<tt><go from="wp1" wp="wp2" hmode="route" approaching_time="1"/></tt>

==== 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:
<tt><circle wp="HOME" radius="75"/></tt>
A positive radius makes the UAV fly 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:
<tt><circle wp="wp1" radius="50+(estimator_z-ground_alt)/2" vmode="throttle" throttle="0.75" pitch="15" until="10>PowerVoltage()"/></tt>

==== 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.
<tt><follow ac_id="4" distance="50" height="20"/></tt>

==== Stay ====

The <tt>stay</tt> is a mode for UAVs able to hover:
<tt><stay wp="HOME" alt="10"/></tt>

==== 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'''):
<tt><xyz radius="40"/></tt>

==== 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):
<tt><set var="ground_alt" value="ground_alt+50"/></tt>
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:
<tt><call fun="nav_line_init()"/>
<call fun="nav_line(WP_1, WP_2, nav_radius)"/></tt>
where <tt>nav_line_init()</tt> returns FALSE and <tt>nav_line()</tt> always returns TRUE (this stage never ends).
Such functions usually are defined in a supplementary C file which must be specified in the airframe file (in the <tt>makefile</tt> section)
<tt>ap.srcs += nav_line.c
sim.srcs += nav_line.c</tt>
These functions also must be declared in a header file which must be mentioned in the header element of the flight plan:
<tt><header>
#include "nav_line.h"
</header></tt>
These C source file and H header file must be located in the <tt>sw/airborne</tt> directory.

== 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:
<for var = "i" from = "1" to = "5">
<circle wp = "HOME" radius="75"
alt = "ground_alt+50*$i"
until = "stage_time>60" />
</for>

== Procedures ==

Procedures are libraries which can be included in flight plans. They are composed of waypoints 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, optional global exceptions and blocks:
<tt><!ELEMENT procedure (param*,waypoints,exceptions?,blocks)></tt>

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:
<tt><param name="alt"/>
<param name="radius" default_value="75"/></tt>

Procedures are called with the <tt>include</tt> element in a flight plan (a procedure cannot be included by another procedure). A procedure call requires:
* the name of the procedure file, the name given to this inclusion;
* the relative position and the orientation of the procedure in the flight plan;
* values for the parameters;
* backlinks for block name exits of the procedure.

For example:
<tt><include name="hippo1" procedure="hippo.xml" x="-100" y="150" rotate="0">
<arg name="alt" value="ground_alt+100"/>
<with from="end" to="landing"/>
</include></tt>

Here is the corresponding procedure '''hippo.xml''':
<tt><procedure>
<param name="alt"/>
<param name="radius" default value="75"/>
<waypoints>
<waypoint name="c1" x="0" y="0"/>
<waypoint name="c2" x="250" y="0"/>
</waypoints>
<blocks>
<block name="oneturn">
<go hmode="route" alt="alt" from="c1" from_qdr="0" from_dist="radius" wp="c2" wp_qdr="0" wp_dist="radius"/>
<circle wp="c2" radius="radius" until="Qdr(180)" alt="alt"/>
<go hmode="route" alt="alt" from="c2" from_qdr="180" from_dist="radius" wp="c1" wp_qdr="180" wp_dist="radius"/>
<circle wp="c1" radius="radius" until="Qdr(0)" alt="alt"/>
<deroute block="end"/>
</block>
</blocks>
</procedure></tt>

Note that the name of procedure block is then '''hippo1.oneturn''':
<tt><deroute block="hippo1.oneturn"/></tt>
will jump to this procedure block.

== Flight Simulation ==
Complex flight plans should always be carefully tested prior to flight. See the [[Simulation|simulation]] page for details.

Flight Plans

2009-03-18T09:36:58Z

Rcbrother: /* Follow */

The formal description of the flight plan file is given in the DTD (located in <tt>conf/flight_plans/flight_plan.dtd</tt>). This
DTD must be referenced in the header of your flight plan XML file using the following line:<br>

<tt><!DOCTYPE flight_plan SYSTEM "flight_plan.dtd"></tt>

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 in the GUI.

== Structure of the flight plan file ==

Extract from the DTD:
<tt><!ELEMENT flight_plan (header?,waypoints,sectors?,include*,exceptions?,blocks)></tt>

A flight plan is composed of two compulsory elements: [[#waypoints|waypoints]] and [[#blocks|blocks]] and typically contains optional <tt>include</tt>'s and global <tt>exceptions</tt>.

The root <tt>flight_plan</tt> element is specified with several attributes:
<tt><flight_plan name lat0 lon0 ground alt security height qfu alt max_dist_from_home></tt>
* <tt>name</tt>: the name of the mission (a text string)
* <tt>lat0, lon0</tt>: describe the latitude and longitude of the point {0,0} in WGS84 degree coordinates
* <tt>ground_alt</tt>: the ground altitude (in meters). It defines the <tt>GROUND_ALT</tt> constant value which can be used to define waypoint altitudes
* <tt>security_height</tt>: the altitude used by the circle-home failsafe procedure
* <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.
* <tt>alt</tt>: the default altitude of waypoints
* <tt>max_dist_from_home</tt>: the maximum allowed distance (in meters) from the HOME waypoint.

Here is an example of the first line of a flight plan:

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

=== Waypoints ===

The waypoints are the geographic locations used to specify the trajectories. A waypoint is specified with its name and its relative coordinates:
<tt> <waypoint name x y [alt] /> </tt>
where <tt>x</tt> and <tt>y</tt> are the coordinates in meters from point {0,0}. <tt>alt</tt> is optional and can be used to assign an altitude to a particular waypoint that is different from the globally defined <tt>alt</tt> above. Note that a waypoint named <tt>HOME</tt> is required as it is used by the failsafe HOME mode procedure.

One example:
<tt>
<waypoints>
<waypoint name="HOME" x="0.0" y="30.0"/>
<waypoint name="1" x="-100.0" y="60.0" alt="270."/>
<waypoint name="2" x="-130.0" y="217.5" alt="3000."/>
</waypoints>
</tt>

Waypoints are easily edited with the [[Flight_Plan_Editor|flight plan editor]].

Waypoints which name starts with an underscore are not displayed in the GCS, except in editor mode.

=== Sectors ===
Flat ''Sectors'' can be described as a list of waypoint corners. Such an area will be displayed in the GCS.
A function is generated to check if a point (usually the aircraft itself) is ''inside'' the polygon. Currently, this feature requires that the polygon is <b>convex</b> and described in a <b>clockwise</b> order. For a sector named <tt>sector</tt>, the generated function is <tt>bool_t InsideSector(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. Note: If the flight plan is dynamically relocated, such a sector will be relocated but the display is currently not updated on the GCS.

For example, with the following element in a flight plan (waypoints which name starts with an underscore are not displayed in the GCS, except in editor mode)
<tt>
<sectors>
<sector name="Muret">
<corner name="_1"/>
<corner name="_2"/>
<corner name="_3"/>
<corner name="_4"/>
</sector>
</sectors>
</tt>
it is then possible to write a exception to stay inside it:
<tt>
<exception cond="! InsideMuret(estimator_x, estimator_y)" deroute="standby"/>
</tt>

=== Include ===

<tt>include</tt> is used to add blocks 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 [x] [y] [rotate] > [<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 jump to the blocks of the <tt>procedure</tt>, the XML referenced file. The
procedure can be shifted (<tt>x</tt> meters east, <tt>y</tt> meters north) and <tt>rotate</tt>d (clockwise degrees, north=0).
Named arguments may be given with their value in the <tt>arg</tt> elements. The <tt>with</tt> tag allows to link labels 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:
<tt><include name="hippo1" procedure="hippo.xml" x="-100" y="150" rotate="0">
<arg name="alt" value="GROUND ALT+100"/>
<with from="event1" to="penta"/>
</include></tt>
where a jump to <tt>event1</tt> inside the <tt>hippo.xml</tt> procedure will actually jump to the <tt>penta</tt> block of the
current flight plan.

=== 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 go 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'':
<tt><!ELEMENT blocks (block+)>
<!ELEMENT block (exception|while|heading|attitude|go|xyz|set|circle|deroute|stay|follow
|survey_rectangle)*></tt>

Example:
<tt><block name="circlehome">
<circle radius="75" wp="HOME"/>
</block></tt>

You can add a button in the [[GCS#Strips|strip of the aircraft]] with the attribute <tt>strip_button</tt>:
<tt><block name="descent" strip_button="Descent">
<circle wp="HOME" throttle="0.0" pitch="-15" vmode="throttle"/>
</block> </tt>
This button will activate the block.

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>:
<tt><block name="Takeoff" strip_icon="takeoff.png" strip_button="Takeoff"></tt>

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

===== 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 examples)
* Some binary operators: <, >, <=, >=, <>, ==, +, -, /, *
* Some utility functions

Some examples of usable expressions are given in the next sections.

==== 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:
<tt><exception cond="..." deroute="..."></tt>
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:
<tt><exception cond="10 > PowerVoltage()" deroute="go_down"/>
<exception cond="(ground_alt+10 > estimator_z)" deroute="go_up"/>
<exception cond="(estimator_flight_time > 840)" deroute="quick_land"/></tt>

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.
<tt><flight_plan ...>
<waypoints> ... </waypoints>
<exceptions>
<exception cond="datalink_time > 22" deroute="Standby"/>
</exceptions>
<blocks> ...</tt>

==== Deroute ====

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

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

==== 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:
<tt><while cond="TRUE">
<go wp="A"/>
<go wp="B"/>
<go wp="C"/>
<while cond="5 > stage_time"/>
</while></tt>
In this example, we run an infinite loop, going to 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:
<tt><for var="i" from="0" to="3">
...
</for></tt>
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:
<tt><for var="i" from="1" to="5">
<circle wp="HOME" radius="75" alt="ground_alt+50*$i" until="stage_time>10" />
</for></tt>
In this example, we circle around '''HOME''' 10 seconds at height 50m, 10s at height 100m, ... until height 250m.
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;
* circle : circle around a waypoint;
* stay : hold the position (hard to realize for a fixed-win 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:
<tt><attitude roll="0" vmode="throttle", throttle="0.5"/></tt>

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

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:
<tt><heading course="QFU" vmode="throttle" throttle="0.8" pitch="15" until="(estimator_z > ground_alt+30)"/></tt>

==== 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
<tt><go wp="HOME"/></tt>
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:
<tt><go from="wp1" wp="wp2" hmode="route"/></tt>

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:
<tt><go from="wp2" wp="wp3" hmode="route" pitch="auto" throttle="0.75" alt="ground_alt+100"/></tt>

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

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).
<tt><go from="wp1" wp="wp2" hmode="route" approaching_time="1"/></tt>

==== 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:
<tt><circle wp="HOME" radius="75"/></tt>
A positive radius makes the UAV fly 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:
<tt><circle wp="wp1" radius="50+(estimator_z-ground_alt)/2" vmode="throttle" throttle="0.75" pitch="15" until="10>PowerVoltage()"/></tt>

==== 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.
<tt><follow ac_id="4" distance="50" height="20"/></tt>

==== Stay ====

The <tt>stay</tt> is a mode for UAVs able to hover:
<tt><stay wp="HOME" alt="10"/></tt>

==== Xyz ====

<tt>xyz</tt> is a special mode where the UAV 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'''):
<tt><xyz radius="40"/></tt>

==== 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):
<tt><set var="ground_alt" value="ground_alt+50"/></tt>
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:
<tt><call fun="nav_line_init()"/>
<call fun="nav_line(WP_1, WP_2, nav_radius)"/></tt>
where <tt>nav_line_init()</tt> returns FALSE and <tt>nav_line()</tt> always returns TRUE (this stage never ends).
Such functions usually are defined in a supplementary C file which must be specified in the airframe file (in the <tt>makefile</tt> section)
<tt>ap.srcs += nav_line.c
sim.srcs += nav_line.c</tt>
These functions also must be declared in a header file which must be mentioned in the header element of the flight plan:
<tt><header>
#include "nav_line.h"
</header></tt>
These C source file and H header file must be located in the <tt>sw/airborne</tt> directory.

== 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:
<for var = "i" from = "1" to = "5">
<circle wp = "HOME" radius="75"
alt = "ground_alt+50*$i"
until = "stage_time>60" />
</for>

== Procedures ==

Procedures are libraries which can be included in flight plans. They are composed of waypoints 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, optional global exceptions and blocks:
<tt><!ELEMENT procedure (param*,waypoints,exceptions?,blocks)></tt>

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:
<tt><param name="alt"/>
<param name="radius" default_value="75"/></tt>

Procedures are called with the <tt>include</tt> element in a flight plan (a procedure cannot be included by another procedure). A procedure call requires:
* the name of the procedure file, the name given to this inclusion;
* the relative position and the orientation of the procedure in the flight plan;
* values for the parameters;
* backlinks for block name exits of the procedure.

For example:
<tt><include name="hippo1" procedure="hippo.xml" x="-100" y="150" rotate="0">
<arg name="alt" value="ground_alt+100"/>
<with from="end" to="landing"/>
</include></tt>

Here is the corresponding procedure '''hippo.xml''':
<tt><procedure>
<param name="alt"/>
<param name="radius" default value="75"/>
<waypoints>
<waypoint name="c1" x="0" y="0"/>
<waypoint name="c2" x="250" y="0"/>
</waypoints>
<blocks>
<block name="oneturn">
<go hmode="route" alt="alt" from="c1" from_qdr="0" from_dist="radius" wp="c2" wp_qdr="0" wp_dist="radius"/>
<circle wp="c2" radius="radius" until="Qdr(180)" alt="alt"/>
<go hmode="route" alt="alt" from="c2" from_qdr="180" from_dist="radius" wp="c1" wp_qdr="180" wp_dist="radius"/>
<circle wp="c1" radius="radius" until="Qdr(0)" alt="alt"/>
<deroute block="end"/>
</block>
</blocks>
</procedure></tt>

Note that the name of procedure block is then '''hippo1.oneturn''':
<tt><deroute block="hippo1.oneturn"/></tt>
will jump to this procedure block.

== Flight Simulation ==
Complex flight plans should always be carefully tested prior to flight. See the [[Simulation|simulation]] page for details.

Compiling

2009-03-02T15:52:54Z

Rcbrother: /* Installing the UART tunnel for direct access to the GPS */

Flight plans, tuning and configuration settings are compiled into a single binary image and transferred to the microcontroler flash rom through USB. Most tuning and flight plan parameters can be changed in-flight but after each power cycle, the autopilot reverts to the original settings. Permanent changes must be made in the source files, compiled, and uploaded to the autopilot.

== Configuring Non-Root users to access USB ==

Non-Root users typically do not have access to hardware I/O with USB ports included. The user you are using to program the autpilots must be a member of the ''plugdev'' group. The original user login given during the Linux install process usually is a member. If not, add yourself to this group with the following command:

sudo adduser <your login> plugdev

It will be effective only on your next login or after the command

newgrp plugdev

== USB flashing ==

The Paparazzi device rules are required for USB flashing. Copy them into place if you haven't already done so:
sudo cp $PAPARAZZI_HOME/conf/system/udev/rules/10-paparazzi.rules /etc/udev/rules.d/

If you are using Ubuntu, the Braille TTY driver interferes with FTDI USB Serial adapters and should be removed:

sudo apt-get remove brltty

[[Image:Tiny_test_wiring.jpg|thumb|Example wiring for programming and telemetry]]
If the autopilot senses a connected USB cable during power-on, it will wait to receive a firmware image rather than booting normally. The firmware can be compiled and flashed by several means, '''the simplest way using the [[Paparazzi_Center|Paparazzi Center]]''', the traditionnal way being:
make AIRCRAFT=''myplane'' clean_ac ap.upload
(where ''myplane'' is the name of your airframe as defined in <tt>conf/conf.xml</tt>)

This command erases any compiled autopilot code from the PC, recompiles everything from scratch, and then sends it to the autopilot.
Variations include:
* make AIRCRAFT=''myplane'' sim
*: Compiles your code for use in the simulator - note that "clean_ac" will remove this code, so the simulator code must be rebuilt each time a clean has been performed.
* make AIRCRAFT=''myplane'' fbw.upload
*: This is needed when configuring the separate "fly by wire" MCU on the [[Classix]] autopilot.
* make AIRCRAFT=''myplane'' ap
*: This will simply build the portions of autopilot code that have changed since the last compile without attempting to flash. Note: this method may not detect certain changes (i.e. changes to the airframe makefile section or CVS updated code).
* make AIRCRAFT=''myplane'' ap.upload FLASH_MODE=IAP
*: Specifies USB flashing. This should be specified at the top of the makefile section of your airframe file but can be overridden here. Use FLASH_MODE=IAS for serial flashing.

=== Verify that above downloads work ===

==== Step 1 ====

Connect the USB cable to the USB port (U23, corner of the board). You then typically should see feedback like:

~/paparazzi3$ dmesg | tail -5
[79212.484187] pl2303 1-2.3:1.0: device disconnected
[82312.463077] usb 5-1: new high speed USB device using ehci_hcd and address 23
[82327.555770] usb 5-1: device descriptor read/64, error -110
[82342.752307] usb 5-1: device descriptor read/64, error -110
[82342.968031] usb 5-1: new high speed USB device using ehci_hcd and address 24

which confirms that your device is powered up and visible. If not - check your power and connections. Failing that - prepare to download the USB Bootloader through the 'Download' connector.

Above output is for the Tiny2.1.

==== Step 2 ====

Secondly - download some firmare (here we're using a modified [http://paparazzi.enac.fr/wiki/index.php/Using_demo_programs_in_sw/airborne-tiny2.1 demo2] - which flashes the LEDs with a Tiny2.1 board):

$ export PAPARAZZI_HOME=.. if needed... etc.
$ make AIRCRAFT=DEMO demo2.upload
make[1]: Leaving directory `/usr/share/paparazzi'
cd sw/airborne; make PAPARAZZI_SRC=/usr/share/paparazzi PAPARAZZI_HOME=/home/dirkx/paparazzi3 TARGET=demo2 all
make[1]: Entering directory `/usr/share/paparazzi/sw/airborne'
/home/dirkx/paparazzi3/var/demo/demo2/demo2.elf :
section size addr
.text 956 16384
.ctors 0 17340
.dtors 0 17340
.data 0 1073741824
.bss 12 1073741824
.stack 4096 1073742080
.comment 54 0
Total 5118
make[1]: Leaving directory `/usr/share/paparazzi/sw/airborne'
cd sw/airborne; make PAPARAZZI_SRC=/usr/share/paparazzi PAPARAZZI_HOME=/home/dirkx/paparazzi3 TARGET=demo2 upload
make[1]: Entering directory `/usr/share/paparazzi/sw/airborne'
/usr/share/paparazzi/sw/ground_segment/lpc21iap/lpc21iap /home/dirkx/paparazzi3/var/demo/demo2/demo2.elf
.
Found USB device
BootROM code: 2.12
Part ID: 0x0402FF25 (LPC2148, 512k Flash, 32k+8k RAM)
BootLoader version: 1.3
#
Starting software at 0x00004000
make[1]: Leaving directory `/usr/share/paparazzi/sw/airborne'
make: Leaving directory `/usr/share/paparazzi'
~/paparazzi3$

which confirms that your device has the bootloader functioning. The important bit of output is:

Found USB device
BootROM code: 2.12
Part ID: 0x0402FF25 (LPC2148, 512k Flash, 32k+8k RAM)
BootLoader version: 1.3
#

Be aware that the demos involving serial ports do not currently work with Tiny V2's.

==== Step 3 ====

Observe the LEDs flashing.

==== Step 4 ====

Disconnect the usb cable, powercylce the unit - LEDs should flash again.

==== Step 5 ====

Select aircraft MJ5, build and upload.

Select airframe funjet1.xml (if you have a Tiny V2)

(Many thanks to hwarm for helping me figure this out.)

Connect the serial port of your tiny to your PC using a level converter and select session Flight usb serial@9600.

If you are using funjet1.xml:
*Stop all the processes but do not remove them.
*Edit the line Data Link and add "-s 57600" to the end, to tell the data link the baud rate of the MJ5.
*Restart Data Link, Server and GCS in that order.

If all went well, it should work and you should see messages coming in from the Tiny!

=== Installing the UART tunnel for direct access to the GPS ===

Type the following command from your paparazzi folder, substituting the name of your airframe and paying attention to case sensitivity:
make AIRCRAFT=''myplane'' tunnel.upload
Connect the usb cable and power on the autopilot to receive the code.

* This completely replaces the normal autopilot code (leaving the USB bootloader intact) with a simple serial-to-serial pass-thru that essentially connects the GPS serial port directly to the modem serial port. You will have no LED indicators or other autopilot functionality with this code. Use this only to gain direct access to the GPS for testing/configuration with [[GPS#GPS_configuration_using_U-Center|U-Center]] or other software.
* This can be done without the USB bootloader by appending ''FLASH_MODE=ISP'' to the command line (specifing ISP serial loading). This will require a serial cable connection (i.e. FTDI USB-to-TTL). '''WARNING!''' Installing tunnel code with the ISP method will erase any USB bootloader code. Make sure you are able to install a bootloader yourself.

=== Installing the USB Bootloader ===

The USB bootloader should only need to be installed once when the board is first built. It is loaded through the serial interface UART0 (Serial1) by holding pin P0.14 low during power-up on Tiny V1.x. For Tiny V2.x this pin is called BOOT and also GPS_RESET has to be tied low during the serial programming to keep the GPS receiver quiet that shares the serial port with the download. If you were supplied with a Tiny Autopilot it may have already had the USB bootloader installed, please check with your supplier.

You will need to convert the PC's RS232 Serial with voltage levels of +/-13V to 3.3V (or 5V) TTL in order to communicate directly with the device. This can be accomplished in multiple ways. The easiest and most convenient method is to purchase or build a USB -> Serial 3.3V adapter similar to this one [http://www.ftdichip.com/Products/EvaluationKits/TTL-232R-3V3.htm TTL-232R-3V3]
Here's a few other examples:
[http://www.sparkfun.com/commerce/product_info.php?products_id=199]
[http://www.sparkfun.com/commerce/product_info.php?products_id=718]
[http://www.pololu.com/products/pololu/0391/]
[http://www.hvwtech.com/products_view.asp?CatID=166&SubCatID=183&SubSubCatID=0&ProductID=409]
[http://shop.halfbase.com/product_info.php/products_id/54]
Users are strongly urged to use FTDI usb-serial converters as they are well supported by default in the linux kernel and since the Paparazzi ground station software is configured to look for modems on FTDI ports by default, the converter can likely serve as a modem interface after it's use in programming.

Make up a wiring harness similar to the following. You may vary the details however this is a working solution:

Tiny V1.x (SERIAL_1):<br />
TINY RXD0 <-- PC SERIAL TX (5V or 3.3V)
TINY TXD0 --> PC SERIAL RX (5V or 3.3V)
TINY P0.14 --> attach to ground, or wire through a pushbutton to ground
TINY GND --> PC SERIAL ADAPTER GND
TINY RESET --> ''optional'' wired to ground through a pushbutton so you can reset

Tiny V2.x (DOWNLOAD):<br />
TINY LPC_RXD0 <-- PC SERIAL TX (5V or 3.3V)
TINY LPC_TXD0 --> PC SERIAL RX (5V or 3.3V)
TINY BOOT --> attach to ground, or wire through a pushbutton to ground
TINY GPS_RESET --> attach to ground, or wire through a pushbutton to ground
TINY GND --> PC SERIAL ADAPTER GND

Once this wiring is ready you will be ready to send the USB Bootloader to the Tiny from the PC.

To prepare the Tiny to accept programming over its serial port you must have pin P0.14 LOW for at least 3mS while it is powering up or resetting. While it is still powered up it is ready to accept code over serial. Proceed now to instructions to load it via software.

'''In Linux'''

From your paparazzi3 folder in linux, type:

make upload_bl PROC=GENERIC

This will begin compiling your USB Bootloader and then attempt to transfer it to the Autopilot. This will also assume you are using a USB -> Serial adapter for the connection. It uses /dev/ttyUSB0 by default. If your adapter is mapped to a different tty, you will need to modify the Makefile accordingly.

'''In Windows'''

If for some reason you need to program your Tiny's USB Bootloader in windows grab a copy of [http://www.standardics.nxp.com/support/documents/microcontrollers/zip/flash.isp.utility.lpc2000.zip LPC2000 Flash Utility V2.2.3] or later. You will then prepare the Tiny and boot it into the ISP bootloader as mentioned above but program it with this utility. You will need to copy your compiled bl.hex file from Linux of course.

== Troubleshooting ==
As a rapidly evolving open-source project, on occasion your software may fail to compile after a [[Installation#Software_Updates|CVS Update]]. This is most likely due to a new or changed variable name that is now required in your airframe, flight plan, etc. Since the user-configured files are not updated automatically you may need to view the most recently changed sample airframe or flight plan files to find the required changes.<br>
See the [[Software_Troubleshooting|Software Troubleshooting]] page for help with common compiliation errors.

Airframe Configuration

2009-03-01T12:33:09Z

Rcbrother: /* Infrared */

The airframe configuration file is located in <tt>conf/airframes</tt> and contains
all the hardware and software settings for an aircraft. This is an [http://en.wikipedia.org/wiki/Xml XML] document containing some [http://en.wikipedia.org/wiki/Makefile Makefile] code at the bottom. All gains, trims, and behavior settings are defined with standard XML elements. The hardware definitions such as processor type, modem protocol, servo driver, etc. are contained in the makefile raw section.

== Selecting the Airframe File ==
Each airframe file must be assigned a name, unique ID, flight plan, etc. in [[Conf.xml|<tt>conf/conf.xml</tt>]] as follows:
<?xml version="1.0"?>
<conf>
<aircraft
name="Twin1"
ac_id="1"
airframe="airframes/twinstar1.xml"
radio="radios/mc3030.xml"
flight_plan="flight_plans/mav05_cw.xml"
telemetry="telemetry/default.xml"
gui_color="blue"
/>
<aircraft
name="Plaster"
ac_id="2"
airframe="airframes/plaster1.xml"
radio="radios/cockpitMM.xml"
telemetry="telemetry/default.xml"
flight_plan="flight_plans/dummy.xml"
/>
.
.
.
</conf>
Then, to compile and flash the airframe settings and associated flight plan to your autopilot, simply select the appropriate A/C and target in the [[Paparazzi_Center|Paparazzi Center]] or specify your airframe name in the flash command typed from the prompt:
make AIRCRAFT=<b>Twin1</b> ap.upload
More information can be found on the [[Conf.xml|conf.xml]] page

== XML Parameters ==
=== Commands ===

The <b><tt>commands</tt></b> lists the abstract commands you need to control the aircraft. In our example, we have only three:
<tt>
<commands>
<axis name="THROTTLE" failsafe_value="0"/>
<axis name="ROLL" failsafe_value="0"/>
<axis name="PITCH" failsafe_value="0"/>
</commands></tt>
Each command is associated with a failsafe value which will be used if no controller is active (during initialization for example). The range of these values is [-9600:9600]. Note that these commands do not necessarily match the servo actuators. For example, the ROLL command is typically linked to two aileron actuators.

=== Servos ===

The above commands get translated to the <b><tt>servos</tt></b> here. In this example we use two ailevons (surfaces used for both pitch and roll as on a flying wing) and a motor. These are listed in the <b><tt>servos</tt></b> section:
<tt>
<servos>
<servo name="THROTTLE" no="0" min="1000" neutral="1000" max="2000"/>
<servo name="AILEVON_LEFT" no="1" min="2000" neutral="1500" max="1000"/>
<servo name="AILEVON_RIGHT" no="2" min="1000" neutral="1500" max="2000"/>
</servos></tt>
where names are associated to the corresponding servo channel number on the autopilot and the neutral value, total range and direction are defined. Min/max/neutral values are expressed in milliseconds and the direction of travel can be reversed by exchanging min with max (as in <tt>"AILEVON_LEFT"</tt>, above). The ''standard'' travel for a hobby servo is 1000ms - 2000ms with a 1500ms neutral. Trim can be added by changing this neutral value, and absolute 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>. Note the following tips:
* Reverse the servo direction by exchanging min/max
* Trim should always be adjusted mechanically if possible to avoid asymetrical travel
* Any reduction of the total travel range should be done mechanically to maintain precision
* Many servos will respond well to values slightly outside the normal 1000-2000ms range but experiment carefully as the servo may not operate reliably outside this range and may even suffer permanent damage.

The <b><tt>servos</tt></b> are then linked to the commands in the <b><tt>command_laws</tt></b> section:
<tt>
<command_laws>
<let var="aileron" value="@ROLL * 0.3"/>
<let var="elevator" value="@PITCH * 0.7"/>
<set servo="THROTTLE" value="@THROTTLE"/>
<set servo="AILEVON_LEFT" value="$elevator + $aileron"/>
<set servo="AILEVON_RIGHT" value="$elevator - $aileron"/>
</command_laws></tt>
[[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. Ailevon 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.

=== Manual ===
The <tt>rc_command</tt> sections links the channels of the RC transmitter (defined in the [[Radio_Control|Radio Control]] file) to the <tt>commands</tt> defined above:

<rc_commands>
<set command="THROTTLE" value="@THROTTLE"/>
<set command="ROLL" value="@ROLL"/>
<set command="PITCH" value="@PITCH"/>
</rc_commands>

This example looks trivial since the channel values have the same name than the commands.

=== Autopilot Only Commands ===
For certain missions it might be required to control servos (payload) from the autopilot (gcs) at all times (even during manual flight). These commands should not be in the <rc_commands> block but in the special <ap_only_commands> block. This allows for instance the pantilt operator to keep working when in manual flight, or safety logic to automatically close cameras below a certain altitude during manual landings.

<ap_only_commands>
<copy command="PAN"/>
<copy command="TILT"/>
<copy command="SHOOT"/>
</ap_only_commands>

=== Auto1 ===
The next section, named <b><tt>AUTO1</tt></b>, gives the maximum roll and pitch (in radians) allowed for the augmented stability mode.
<tt>
<section name="AUTO1" prefix="AUTO1_">
<define name="MAX_ROLL" value="RadOfDeg(35)"/>
<define name="MAX_PITCH" value="RadOfDeg(35)"/>
</section>
</tt>
<br>

=== ADC ===
In the "adc" section, you will find the conformity between arguments and their assigned pins on the autopilot board.
<section name="adc" prefix="ADC_CHANNEL_">
<define name="IR1" value="ADC_1"/>
<define name="IR2" value="ADC_2"/>
<define name="IR_TOP" value="ADC_0"/>
</section>
'''Important note''': To ''activate'' an ADC entry, a flag must be defined in the <tt>makefile</tt> section. For the previous example, we would have to write:

ap.CFLAGS += -DADC -DUSE_ADC_0 -DUSE_ADC_1 -DUSE_ADC_2
ap.srcs += $(SRC_ARCH)/adc_hw.c

==== ADC Generic ====

In addition, if you want to receive the value of some ADC channel, you can use the "ADC Generic" service. When activated, the aircraft sends 2 values corresponding to the selected ADC channels. They can be read from the "Messages" application.
ap.CFLAGS += -DUSE_ADC_GENERIC -DUSE_ADC_3 -DADC_CHANNEL_GENERIC1=ADC_3 -DUSE_ADC_4 -DADC_CHANNEL_GENERIC2=ADC_4
ap.srcs += adc_generic.c
In this example, the ADC channels 3 and 4 are read and sent by telemetry at 4Hz:
<message name="ADC_GENERIC" ID="18">
<field name="val1" type="uint16"/>
<field name="val2" type="uint16"/>
</message>
Only two channels can be defined. If only one is activated, 0 will send for the second value.

=== Infrared ===
The <b><tt>INFRARED</tt></b> section describes the configuration of the infrared sensors.

The first definitions are relative to the electronic neutral of the sensors (a sensor here is a '''pair''' of thermopiles). A perfect sensor should give 512 if it measures the same value on both sides.

<section name="INFRARED" prefix="IR_">
<define name="ADC_IR1_NEUTRAL" value="512"/>
<define name="ADC_IR2_NEUTRAL" value="512"/>
<define name="ADC_TOP_NEUTRAL" value="512"/>

These neutrals are tuned with the "cupboard test": Put the sensor in a close box (a cupboard) and read the values of the IR_SENSORS message (ir1, ir2 and vertical). Set the neutrals (they are subtracted from the measurement) to get null values. E.g. if you read 5 for the ir1 value with ADC_IR1_NEUTRAL equal to 512, change the latter to 517.

The next lines define the installation of the horizontal and vertical sensors. The vertical sensor must give a positive value when the temperature under the aircraft is higher than the temperature above. The two channels of the horizontal sensor must give positive values when it is warmer on the right side and the rear side. To adjust these signs, use the following declarations:

<define name="IR1_SIGN" value="-1"/>
<define name="IR2_SIGN" value="-1"/>
<define name="TOP_SIGN" value="-1"/>

Then, define how the horizontal sensor is connected to the airframe, orientation '''aligned''' or '''tilted'''. In the aligned case, ir'''1''' is along the lateral axis (The axis that passes through the plane from wingtip to wingtip) and ir'''2''' along the longitudinal one. In the '''tilted''' case, the sensors are tilted by 45 degrees; ir'''1''' is along rear-left -- front-right, and ir'''2''' along rear-right -- front-left. The parameter "value" has no effect! If the airframe construction allows choose an aligned sensor orientation since this gives the best stabilization response results.

For help with orientation of '''Previous Versions of Infrared Sensor Boards''' try here : http://paparazzi.enac.fr/wiki/Previous_Infrared_Sensors

<define name="HORIZ_SENSOR_ALIGNED" value="1"/>
or
<define name="HORIZ_SENSOR_TILTED" value="1"/>

The three axis must give similar values for similar contrasts. The following factors can be used to scale these values. For example with an horizontal tilted sensor, the following ratios are usually needed:

<define name="LATERAL_CORRECTION" value="0.7"/>
<define name="LONGITUDINAL_CORRECTION" value="0.7"/>
<define name="VERTICAL_CORRECTION" value="1."/>
Default values are 1.

It may be hard to align the horizontal sensor with the aircraft. A tuning in flight will be needed to adjust the following neutrals. Adjust the roll neutral to fly straight. Adjust the pitch neutral to fly level with the desired throttle.
<define name="ROLL_NEUTRAL_DEFAULT" value="-2.5" unit="deg"/>
<define name="PITCH_NEUTRAL_DEFAULT" value="6" unit="deg"/>

Finally, an asymmetric (left/right, front/rear) correction can be added with a last set of factors.
<define name="CORRECTION_UP" value="1."/>
<define name="CORRECTION_DOWN" value="1."/>
<define name="CORRECTION_LEFT" value="1."/>
<define name="CORRECTION_RIGHT" value="1."/>
</section>
These corrections are set on the angles.

The old way to define the parameters is still possible, but must not be mixed with the new one describe above.

=== Gyro ===
Defines the type of gyro installed, each axis neutral, and any required temperature compensation. If the gyro has two axes, the pitch neutral is defined as well. Many gyros output their internal temperature and require a temperature-dependent linear correction be made to the neutral value. No correction is done for the temperature in this example.(<b><tt>ADC_TEMP_SLOPE=0</tt></b>).

<tt>
<section name="GYRO" prefix="GYRO_"
<define name="ADC_ROLL_COEFF" value="1"/>
<define name="ROLL_NEUTRAL" value="500"/>
<define name="ADC_TEMP_NEUTRAL" value="476"/>
<define name="ADC_TEMP_SLOPE" value="0"/>
</section>
</tt>

=== Bat ===
This section give characteristics for the monitoring of the main power battery. <b><tt>MILLIAMP_PER_PERCENT</tt></b> represents the consumption (in mA) for one percent of THROTTLE and for one time unit. It is used to compute the <tt>energy</tt> value of the <tt>BAT</tt> message.

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. This definition is optional with a default value of 12.5V.

<tt>
<section name="BAT">
<define name="MILLIAMP_PER_PERCENT" value="0.86"/>
<define name="VOLTAGE_ADC_A" value="0.0177531"/>
<define name="VOLTAGE_ADC_B" value="0.173626"/>
<define name="VoltageOfAdc(adc)" value ="(VOLTAGE_ADC_A * adc + VOLTAGE_ADC_B)"/>
<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>
</tt>

=== Horizontal Control ===
<tt>
<section name="HORIZONTAL CONTROL" prefix="H_CTL_">
<define name="COURSE_PGAIN" value="-0.4"/>
<define name="ROLL_MAX_SETPOINT" value="0.35" unit="radians"/>
<define name="ROLL_ATTITUDE_GAIN" value="-7500."/>
<define name="ROLL_RATE_GAIN" value="-1500"/>
<define name="PITCH_PGAIN" value="-8000."/>
<define name="ELEVATOR_OF_ROLL" value="1250"/>
</section>
</tt>

The outer loop acts on the route. It will produce a roll command from a course setpoint and a course measurement. The COURSE_PGAIN parameter is the factor multiplied by the course error (in radian) to get a roll setpoint (in radian). So if the plane is expected to go north (course=0) and is actually flying to 57 degrees (course=1 radian, i.e. ENE), with a gain of '''-0.4''', a roll of -0.4 (23 degrees) will be set for the lower control loop.

The ROLL_ATTITUDE_GAIN is used to compute a ROLL command from the roll error (setpoint minus measurement). If a gyro in installed, the ROLL_RATE_GAIN to keep a null roll rate. So these two gains provide a P-D controller.

===Vertical Control===

<section name="VERTICAL CONTROL" prefix="V_CTL_">

<define name="ALTITUDE_PGAIN" value="-0.1" unit="(m/s)/m"/>

<define name="ALTITUDE_MAX_CLIMB" value="3." unit="m/s"/>
These lines are associated with vertical control loops contained in ./sw/airborne/fw_v_ctl.c. These are outer loop parameters that calculate a desired climb rate based on altitude error. Here, if the altitude error is 10m, the climb setpoint will be set to 1m/s. ALTITUDE_MAX_CLIMB is a bounded value (in m/s) so that the outer loop does not calculate too large of a climb rate
<define name="AUTO_THROTTLE_NOMINAL_CRUISE_THROTTLE" value="0.65" unit="%"/>
<define name="AUTO_THROTTLE_MIN_CRUISE_THROTTLE" value=".4" unit="%"/>
<define name="AUTO_THROTTLE_MAX_CRUISE_THROTTLE" value="1" unit="%"/>
<define name="AUTO_THROTTLE_LOITER_TRIM" value="1000" unit="pprz_t"/>
<define name="AUTO_THROTTLE_DASH_TRIM" value="-2500" unit="pprz_t"/>
<define name="AUTO_THROTTLE_CLIMB_THROTTLE_INCREMENT" value="0.15" unit="%/(m/s)"/>
<define name="AUTO_THROTTLE_PGAIN" value="-0.008" unit="%/(m/s)"/>
<define name="AUTO_THROTTLE_IGAIN" value="0.25"/>
<define name="AUTO_THROTTLE_PITCH_OF_VZ_PGAIN" value="0.35" unit="rad/(m/s)"/>

These lines are associated with vertical rate control loops contained in ./sw/airborne/fw_v_ctl.c and are used by default in most cases. The default vertical control law is for the vertical rate to be managed by a combination of throttle and pitch.

<define name="AUTO_PITCH_PGAIN" value="-0.1"/>
<define name="AUTO_PITCH_IGAIN" value="0.025"/>
<define name="AUTO_PITCH_MAX_PITCH" value="0.5"/>
<define name="AUTO_PITCH_MIN_PITCH" value="-0.5"/>

These lines are associated with vertical control loops contained in ./sw/airborne/fw_v_ctl.c but are not used in default. The non-default vertical control law is for the vertical rate to be managed by the pitch.

<define name="THROTTLE_SLEW_LIMITER" value="2" unit="s"/>
THROTTLE_SLEW_LIMITER is the required time is seconds to change throttle from 0% to 100%.

=== Misc ===
<tt>
<section name="MISC">
<define name="NOMINAL_AIRSPEED" value ="12." unit="m/s">
<define name="CARROT" value="5." unit="s"/>
<define name="KILL_MODE_DISTANCE" value="(1.5*MAX_DIST_FROM_HOME)"/>
<define name="CONTROL_RATE" value"60" unit="Hz"/>
</section>
</tt>

* The "NOMINAL_AIRSPEED" is mainly used in the simulator.
* "CARROT" gives the distance (in seconds, so ground speed is taken into account) between the carrot and the aircraft.
* "KILL_MODE_DISTANCE" is the threshold distance to switch the autopilot into KILL mode (defined descent with no throttle)
* "CONTROL_RATE" is the rate of the low level control loops in Hertz (60 or 20).

== Hardware definitions - Makefile ==

The airframe file must include the description of the controller board and it's low-level settings. This is done in one <b><tt>makefile</tt></b> section starting with the autopilot model and flashing mode:
{{Box Code|conf/airframes/myplane.xml|
<makefile>
include $(PAPARAZZI_SRC)/conf/autopilot/tiny.makefile
<nowiki>FLASH_MODE=IAP</nowiki>
.
.
.
</makefile>
}}
Below this are the definintions and configuration of the peripherals and interfaces.

=== Radio Control ===
The Paparazzi autpilot can interface directly with the PWM signal from any standard hobby R/C receiver. Signal decoding configuration settings for this are stored in the [[Radio_Control|Radio Control]] file.

If you have a Tiny v1.1 Autopilot:
{{Box Code|conf/airframes/myplane.xml|
<nowiki>ap.CFLAGS += -DACTUATORS=\"servos_4015_MAT_hw.h\" -DSERVOS_4015_MAT</nowiki>
<nowiki>ap.srcs += $(SRC_ARCH)/servos_4015_MAT_hw.c actuators.c</nowiki>
<nowiki>ap.CFLAGS += -DRADIO_CONTROL -DRADIO_CONTROL_TYPE=RC_FUTABA</nowiki>
<nowiki>ap.srcs += radio_control.c $(SRC_ARCH)/ppm_hw.c</nowiki>
}}
If you have a Tiny v2 or TWOG v1 Autopilot:
{{Box Code|conf/airframes/myplane.xml|
<nowiki>ap.CFLAGS += -DACTUATORS=\"servos_4017_hw.h\" -DSERVOS_4017</nowiki>
<nowiki>ap.srcs += $(SRC_ARCH)/servos_4017_hw.c actuators.c</nowiki>
<nowiki>ap.CFLAGS += -DRADIO_CONTROL -DRADIO_CONTROL_TYPE=RC_FUTABA</nowiki>
<nowiki>ap.srcs += radio_control.c $(SRC_ARCH)/ppm_hw.c</nowiki>
}}
If you want to output standard PPM to a R/C receiver:
{{Box Code|conf/airframes/myplane.xml|
<nowiki>ap.CFLAGS += -DACTUATORS=\"servos_ppm_hw.h\" -DSERVOS_PPM_MAT</nowiki>
<nowiki>ap.srcs += $(SRC_ARCH)/servos_ppm_hw.c actuators.c</nowiki>
<nowiki>ap.CFLAGS += -DRADIO_CONTROL -DRADIO_CONTROL_TYPE=RC_FUTABA</nowiki>
<nowiki>ap.srcs += radio_control.c $(SRC_ARCH)/ppm_hw.c</nowiki>
}}
This is used in the case where you want to directly drive a receiver which has a microcontroller to do the decoding and driving of the servos (not a 4015 or 4017 decoder chip). The PPM is output on the SERV_CLK pin. The PPM frame rate, pulse width, and number of channels can be adjusted in the "servos_ppm_hw.h" file to suit your particular receiver.

If you have a Classix Autopilot:
{{Box Code|conf/airframes/myplane.xml|
<nowiki>ap.CFLAGS += -DRADIO_CONTROL -DRADIO_CONTROL_TYPE=RC_FUTABA</nowiki>
<nowiki>ap.EXTRA_SRCS += radio_control.c $(SRC_ARCH)/ppm_hw.c</nowiki>
<nowiki>ap.CFLAGS += -DACTUATORS=\"servos_direct_hw.h\"</nowiki>
<nowiki>ap.EXTRA_SRCS += $(SRC_ARCH)/servos_direct_hw.c</nowiki>
}}

You can set RADIO_CONTROL_TYPE to RC_FUTABA, for falling edge PPM, or RC_JR for rising edge PPM. "RC_FUTABA" is for the Futaba or compatible brands, and "RC_JR" for JR (a.k.a Graupner outside of the USA) or compatible brands.

For the Classix, you must specify which pins to use for PWM by adding "-DPWM_SERVO_0, etc." to the line fbw.CFLAGS. This activate the PWM channel.
<tt>wiring on classix PWM connector
connector LPC shared port
PWM1 PWM5 AD1_6 CAP1_3 P0.21
PWM2 PWM3 RXD0 EINT0 P0.1
PWM3 PWM1 TXD0 P0.0
PWM4 PWM6 RXD1 EINT3 P0.9
PWM5 PWM4 TXD1 AD1_1 P0.8
PWM6 PWM2 SSEL0 EINT2 P0.7</tt>
PWM1 and PWM6 should be safe. PWM4 and PWM5 should be OK if you're not using UART1 on the FBW processor - same for PWM2 and PWM3 if you're not using UART0 (disable FBW telemetry for that ).

=== 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 <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.

Paparazzi supports the following modem protocols:
* Standard transparent serial (pprz) - this is compatible with all modems and can be used to connect the autopilot directly to a PC for testing without a modem.
* Maxstream API protocol (xbee) - compatible with all Maxstream modems including the 9XTend and Zigbee. This protocol enables hardware addressing, allowing multiple aircraft to be managed from a single ground modem.
* Coronis Wavecard - necessary for operation with the unusual Coronis Wavecard modem.
Select the baud/protocol in the airframe file by commenting/uncommenting the appropriate section as follows:
==== Configuring The Serial Protocol ====
New users are advised to start with the standard serial protocol before attempting to setup an addressed API link. There are no real reasons for the novice user to use the xbee protocol over the standard PPRZTransport. Even if you are using a Maxstream modem you should still start out with the standard. Lastly it should be pointed out that using a single UAV there is no disadvantage and that the [http://www.engr.usu.edu/wiki/index.php/OSAM OSAM] Paparazzi Team at UAS 2008 took second place using the STANDARD protocol. The serial protocol works with virtually any modem as well as direct cable connections. The baud rates of the airborne modem, autopilot, ground modem, and PC must be configured correctly. The PC and autopilot serial ports do not need to be set to the same baud rate, i.e. when running multiple aircraft from a single ground modem, the ground modem may require a higher baud rate than any of the airborne modems in order to stream the data from multiple simultaneous sources.

{{Box Code|conf/airframes/myplane.xml|
<nowiki>
<section name="DATALINK" prefix="DATALINK_">
<define name="DEVICE_TYPE" value="PPRZ"/>
<define name="DEVICE_ADDRESS" value="...."/>
</section>
</nowiki>
}}
The above example tells the autopilot to send and recieve data in standard serial form.

{{Box Code|conf/airframes/myplane.xml - makefile section at the bottom|
# Serial modem
<nowiki>ap.CFLAGS += -DDOWNLINK -DUSE_UART0 -DDOWNLINK_TRANSPORT=PprzTransport -DDOWNLINK_FBW_DEVICE=Uart0 -DDOWNLINK_AP_DEVICE=Uart0 -DPPRZ_UART=Uart0 -DDATALINK=PPRZ -DUART0_BAUD=B57600</nowiki>
<nowiki>ap.srcs += downlink.c $(SRC_ARCH)/uart_hw.c datalink.c pprz_transport.c</nowiki>
}}
The above example configures the autopilot serial port (Uart0) to 57,600 baud and calls the serial transport protocol (pprz_transport.c). Use the "#" symbol to comment lines in this section of the airframe file.
<br>
Note:
* The autopilot and modem serial port baud rates must match at all times and also must match the ground modem rate, check your modem documentation to find the default baud rate and configure a different rate as needed.

<br style="clear:both>

Ensure that the ground station is using the same protocol and an equal or higher baud rate:
{{Box Code|conf/control_panel.xml|
<nowiki>
<session name="USB">
<program name="link">
<arg flag="-d" constant="/dev/paparazzi/ttyUSB0"/>

<arg flag="-uplink" constant=""/>
<arg flag="-s" constant="57600"/>
</program>
...
</session>
</nowiki>
}}
Use this constant /dev/paparazzi/ttyUSB0 when using either the ftdi cable or a Maxstream USB ground modem.. Otherwise use /dev/ttyUSB0 (the ttyUSB0 being the device that you are using. Note: it might not always be ttyUSB0). This paparazzi directory in the dev folder is created when setting the udev rules. [http://paparazzi.enac.fr/wiki/index.php/Installation#Setting_access_rights_for_USB_download Setting Udev rules]

==== Configuring The Maxstream API Protocol ====
The optional API protocol enables hardware addressing so that multiple aircraft can be managed from a single ground modem, or multiple aircraft and multiple ground stations can work simultaneously without interference from one another. API mode is enabled by sending an escape sequence (+++) followed by AT commands, this can be done automatically at each boot or can be permanently configured with the "ATWR" command for greater reliability.

{{Box Code|conf/airframes/myplane.xml|
<nowiki>
<section name="MISC">
...
<define name="XBEE_INIT" value="\"ATPL2\rATRN1\rATTT80\r\ATBD6\rATWR\r\""/>
...
</section></nowiki>
}}
The above example will program the Maxstream to API mode, 100mW power (ATPL2), 57600 baud (ATBD6), and permanently store the changes (ATWR). After flashing allow 30 seconds for the modem to store the changes, then disable the init string by adding the line <tt><define name="NO_XBEE_API_INIT" value="TRUE"/></tt> (the parameter "value" has no effect), update the baud rate as needed, and re-flash the autopilot. The modem and autopilot serial port baud rates must match eachother at all times.
<br>
Notes:
* Maxtream modems are factory configured for 9600 baud, in order to change baud rates, first configure the autopilot serial port to match the modem (DUART0_BAUD=B9600), boot the system so that the baud rate change command is sent to the modem (ATBD6) and permanently saved (ATWR), allow 30 seconds for the modem configuration to complete, then reprogram the autopilot with the new baud rate (DUART0_BAUD=B57600) and disabled modem configuration string <tt><define name="NO_XBEE_API_INIT" value="TRUE"/> </tt>.
* The ac_id defined in <tt>conf/conf.xml</tt> is permanently programmed into the modem so this procedure would need to be re-run if the modem is moved to another plane.
* For temporary boot-time API configuration remove any baud rate changes, remove <tt>ATWR\r</tt> from the end of the string.
* Upgrade your Maxstream firmware to the latest version before attempting API mode operation.

<br style="clear:both>

{{Box Code|confAgain/airframes/myplane.xml - makefile section at the bottom|
<nowiki># Maxstream API protocol</nowiki>
<nowiki>ap.CFLAGS += -DDOWNLINK -DUSE_UART0 -DDOWNLINK_TRANSPORT=XBeeTransport -DDOWNLINK_FBW_DEVICE=Uart0 -DDOWNLINK_AP_DEVICE=Uart0 -DXBEE_UART=Uart0 -DDATALINK=XBEE -DUART0_BAUD=B57600</nowiki>
<nowiki>ap.srcs += downlink.c $(SRC_ARCH)/uart_hw.c datalink.c xbee.c</nowiki>
}}
The above example configures the autopilot serial port (Uart0) to 57,600 baud and calls the Maxstream transport protocol (xbee.c). Use the "#" symbol to comment lines in this section of the airframe file.
<br style="clear:both>

Ensure that the ground station is using the same protocol and an equal or higher baud rate:
{{Box Code|conf/control_panel.xml|
<nowiki>
<session name="USB">
<program name="link">
<arg flag="-d" constant="/dev/paparazzi/ttyUSB0"/>
<arg flag="-transport" constant="xbee"/>
<arg flag="-uplink" constant=""/>
<arg flag="-s" constant="57600"/>
</program>
...
</session>
</nowiki>
}}
Use this constant /dev/paparazzi/ttyUSB0 when using either the ftdi cable or a Maxstream USB ground modem.. Otherwise use /dev/ttyUSB0 (the ttyUSB0 being the device that you are using. Note: it might not always be ttyUSB0). This paparazzi directory in the dev folder is created when setting the udev rules. [http://paparazzi.enac.fr/wiki/index.php/Installation#Setting_access_rights_for_USB_download Setting Udev rules]
=====Alternate Method=====
This is the way it is done in funjet1.xml and has been tested to work by Danstah

{{Box Code|conf/airframes/funjet1.xml|
<nowiki>
<section name="MISC">
...
<define name="XBEE_INIT" value="\"ATPL2\rATRN1\rATTT80\r\""/>

...
</section></nowiki>
}}
Also use this
{{Box Code|conf/airframes/funjet1.xml|
<nowiki>

<section name="DATALINK" prefix="DATALINK_">
<define name="DEVICE_TYPE" value="XBEE"/>
<define name="DEVICE_ADDRESS" value="...."/>
</section>
</nowiki>
}}
And Finally use this in the makefile section
{{Box Code|conf/airframes/funjet1.xml|
<nowiki>
ap.CFLAGS += -DDOWNLINK -DUSE_UART1 -DDOWNLINK_TRANSPORT=XBeeTransport -DXBEE_UART=Uart1 -DDATALINK=XBEE -DUART1_BAUD=B9600
ap.srcs += downlink.c $(SRC_ARCH)/uart_hw.c datalink.c xbee.c
</nowiki>
}}
By reading all the information above you should be able to infer what the above does.

Now keep in mind that the ground modem baud rate and airplanes modem baud rates do not have to match. The only things that need to match are the the modem on the planes baud rate and the rate defined in the airframe file. For example this planes modem is set to 9600 and this could be used with the ground modem configured above using 57600...
Also for multiple UAV's a good way to configure them is to use 9600 for the ap and use a ground modem configured to 57600 and its not a bad idea to use minimal telemetry.

=== 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:

{{Box Code|conf/airframes/myplane.xml|
<nowiki>ap.CFLAGS += -DGPS -DUBX -DUSE_UART1 -DGPS_LINK=Uart1 -DUART1_BAUD=B38400</nowiki>
<nowiki>ap.srcs += gps_ubx.c gps.c</nowiki>
}}
'''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 thru the [[Compiling#USB_flashing|UART Tunnel]] and [[GPS#GPS_configuration_using_U-Center Configured with|u-center]]

If using the u-blox LEA-5H, add the flag -DGPS_USE_LATLONG in the makefile section of the airframe xml file in the gps section. This flag must be inserted above "ap.srcs += gps_ubx.c gps.c" for proper operation.

{{Box Code|conf/airframes/myplane.xml|
<nowiki>ap.CFLAGS += -DGPS -DUBX -DUSE_UART1 -DGPS_LINK=Uart1 -DUART1_BAUD=B38400 -DGPS_USE_LATLONG
ap.srcs += gps_ubx.c gps.c</nowiki>
}}

=== Sensors ===

=== Control loops ===

The control loops can be divided in two largely independent groups : the vertical ones and the horizontal ones (files sw/airborne/fw_h_ctl.c and sw/airborne/fw_v_ctl.c ). Those loops can be commanded at different levels by either the R/C transmitter or the autonomous navigation routine.

First the horizontal loop:
{{Box Code|conf/airframes/funjet1.xml|
<nowiki>ap.CFLAGS += -DNAV -DAGR_CLIMB -DLOITER_TRIM
ap.srcs += nav.c fw_h_ctl.c fw_v_ctl.c
</nowiki>
}}

Airframe Configuration

2009-03-01T12:07:32Z

Rcbrother: /* Infrared */

The airframe configuration file is located in <tt>conf/airframes</tt> and contains
all the hardware and software settings for an aircraft. This is an [http://en.wikipedia.org/wiki/Xml XML] document containing some [http://en.wikipedia.org/wiki/Makefile Makefile] code at the bottom. All gains, trims, and behavior settings are defined with standard XML elements. The hardware definitions such as processor type, modem protocol, servo driver, etc. are contained in the makefile raw section.

== Selecting the Airframe File ==
Each airframe file must be assigned a name, unique ID, flight plan, etc. in [[Conf.xml|<tt>conf/conf.xml</tt>]] as follows:
<?xml version="1.0"?>
<conf>
<aircraft
name="Twin1"
ac_id="1"
airframe="airframes/twinstar1.xml"
radio="radios/mc3030.xml"
flight_plan="flight_plans/mav05_cw.xml"
telemetry="telemetry/default.xml"
gui_color="blue"
/>
<aircraft
name="Plaster"
ac_id="2"
airframe="airframes/plaster1.xml"
radio="radios/cockpitMM.xml"
telemetry="telemetry/default.xml"
flight_plan="flight_plans/dummy.xml"
/>
.
.
.
</conf>
Then, to compile and flash the airframe settings and associated flight plan to your autopilot, simply select the appropriate A/C and target in the [[Paparazzi_Center|Paparazzi Center]] or specify your airframe name in the flash command typed from the prompt:
make AIRCRAFT=<b>Twin1</b> ap.upload
More information can be found on the [[Conf.xml|conf.xml]] page

== XML Parameters ==
=== Commands ===

The <b><tt>commands</tt></b> lists the abstract commands you need to control the aircraft. In our example, we have only three:
<tt>
<commands>
<axis name="THROTTLE" failsafe_value="0"/>
<axis name="ROLL" failsafe_value="0"/>
<axis name="PITCH" failsafe_value="0"/>
</commands></tt>
Each command is associated with a failsafe value which will be used if no controller is active (during initialization for example). The range of these values is [-9600:9600]. Note that these commands do not necessarily match the servo actuators. For example, the ROLL command is typically linked to two aileron actuators.

=== Servos ===

The above commands get translated to the <b><tt>servos</tt></b> here. In this example we use two ailevons (surfaces used for both pitch and roll as on a flying wing) and a motor. These are listed in the <b><tt>servos</tt></b> section:
<tt>
<servos>
<servo name="THROTTLE" no="0" min="1000" neutral="1000" max="2000"/>
<servo name="AILEVON_LEFT" no="1" min="2000" neutral="1500" max="1000"/>
<servo name="AILEVON_RIGHT" no="2" min="1000" neutral="1500" max="2000"/>
</servos></tt>
where names are associated to the corresponding servo channel number on the autopilot and the neutral value, total range and direction are defined. Min/max/neutral values are expressed in milliseconds and the direction of travel can be reversed by exchanging min with max (as in <tt>"AILEVON_LEFT"</tt>, above). The ''standard'' travel for a hobby servo is 1000ms - 2000ms with a 1500ms neutral. Trim can be added by changing this neutral value, and absolute 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>. Note the following tips:
* Reverse the servo direction by exchanging min/max
* Trim should always be adjusted mechanically if possible to avoid asymetrical travel
* Any reduction of the total travel range should be done mechanically to maintain precision
* Many servos will respond well to values slightly outside the normal 1000-2000ms range but experiment carefully as the servo may not operate reliably outside this range and may even suffer permanent damage.

The <b><tt>servos</tt></b> are then linked to the commands in the <b><tt>command_laws</tt></b> section:
<tt>
<command_laws>
<let var="aileron" value="@ROLL * 0.3"/>
<let var="elevator" value="@PITCH * 0.7"/>
<set servo="THROTTLE" value="@THROTTLE"/>
<set servo="AILEVON_LEFT" value="$elevator + $aileron"/>
<set servo="AILEVON_RIGHT" value="$elevator - $aileron"/>
</command_laws></tt>
[[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. Ailevon 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.

=== Manual ===
The <tt>rc_command</tt> sections links the channels of the RC transmitter (defined in the [[Radio_Control|Radio Control]] file) to the <tt>commands</tt> defined above:

<rc_commands>
<set command="THROTTLE" value="@THROTTLE"/>
<set command="ROLL" value="@ROLL"/>
<set command="PITCH" value="@PITCH"/>
</rc_commands>

This example looks trivial since the channel values have the same name than the commands.

=== Autopilot Only Commands ===
For certain missions it might be required to control servos (payload) from the autopilot (gcs) at all times (even during manual flight). These commands should not be in the <rc_commands> block but in the special <ap_only_commands> block. This allows for instance the pantilt operator to keep working when in manual flight, or safety logic to automatically close cameras below a certain altitude during manual landings.

<ap_only_commands>
<copy command="PAN"/>
<copy command="TILT"/>
<copy command="SHOOT"/>
</ap_only_commands>

=== Auto1 ===
The next section, named <b><tt>AUTO1</tt></b>, gives the maximum roll and pitch (in radians) allowed for the augmented stability mode.
<tt>
<section name="AUTO1" prefix="AUTO1_">
<define name="MAX_ROLL" value="RadOfDeg(35)"/>
<define name="MAX_PITCH" value="RadOfDeg(35)"/>
</section>
</tt>
<br>

=== ADC ===
In the "adc" section, you will find the conformity between arguments and their assigned pins on the autopilot board.
<section name="adc" prefix="ADC_CHANNEL_">
<define name="IR1" value="ADC_1"/>
<define name="IR2" value="ADC_2"/>
<define name="IR_TOP" value="ADC_0"/>
</section>
'''Important note''': To ''activate'' an ADC entry, a flag must be defined in the <tt>makefile</tt> section. For the previous example, we would have to write:

ap.CFLAGS += -DADC -DUSE_ADC_0 -DUSE_ADC_1 -DUSE_ADC_2
ap.srcs += $(SRC_ARCH)/adc_hw.c

==== ADC Generic ====

In addition, if you want to receive the value of some ADC channel, you can use the "ADC Generic" service. When activated, the aircraft sends 2 values corresponding to the selected ADC channels. They can be read from the "Messages" application.
ap.CFLAGS += -DUSE_ADC_GENERIC -DUSE_ADC_3 -DADC_CHANNEL_GENERIC1=ADC_3 -DUSE_ADC_4 -DADC_CHANNEL_GENERIC2=ADC_4
ap.srcs += adc_generic.c
In this example, the ADC channels 3 and 4 are read and sent by telemetry at 4Hz:
<message name="ADC_GENERIC" ID="18">
<field name="val1" type="uint16"/>
<field name="val2" type="uint16"/>
</message>
Only two channels can be defined. If only one is activated, 0 will send for the second value.

=== Infrared ===
The <b><tt>INFRARED</tt></b> section describes the configuration of the infrared sensors.

The first definitions are relative to the electronic neutral of the sensors (a sensor here is a pair of thermopiles). A perfect sensor should give 512 if it measures the same value on both sides.

<section name="INFRARED" prefix="IR_">
<define name="ADC_IR1_NEUTRAL" value="512"/>
<define name="ADC_IR2_NEUTRAL" value="512"/>
<define name="ADC_TOP_NEUTRAL" value="512"/>

These neutrals are tuned with the "cupboard test": Put the sensor in a close box (a cupboard) and read the values of the IR_SENSORS message (ir1, ir2 and vertical). Set the neutrals (they are subtracted from the measurement) to get null values. E.g. if you read 5 for the ir1 value with ADC_IR1_NEUTRAL equal to 512, change the latter to 517.

The next lines define the installation of the horizontal and vertical sensors. The vertical sensor must give a positive value when the temperature under the aircraft is higher than the temperature above. The two channels of the horizontal sensor must give positive values when it is warmer on the right side and the rear side. To adjust these signs, use the following declarations:

<define name="IR1_SIGN" value="-1"/>
<define name="IR2_SIGN" value="-1"/>
<define name="TOP_SIGN" value="-1"/>

Then, define how the horizontal sensor is connected to the airframe, orientation '''aligned''' or '''tilted'''. In the aligned case, ir'''1''' is along the lateral axis (The axis that passes through the plane from wingtip to wingtip) and ir'''2''' along the longitudinal one. In the '''tilted''' case, the sensors are tilted by 45 degrees; ir'''1''' is along rear-left -- front-right, and ir'''2''' along rear-right -- front-left. The parameter "value" has no effect! If the airframe construction allows choose an aligned sensor orientation since this gives the best stabilization response results.

For help with orientation of '''Previous Versions of Infrared Sensor Boards''' try here : http://paparazzi.enac.fr/wiki/Previous_Infrared_Sensors

<define name="HORIZ_SENSOR_ALIGNED" value="1"/>
or
<define name="HORIZ_SENSOR_TILTED" value="1"/>

The three axis must give similar values for similar contrasts. The following factors can be used to scale these values. For example with an horizontal tilted sensor, the following ratios are usually needed:

<define name="LATERAL_CORRECTION" value="0.7"/>
<define name="LONGITUDINAL_CORRECTION" value="0.7"/>
<define name="VERTICAL_CORRECTION" value="1."/>
Default values are 1.

It may be hard to align the horizontal sensor with the aircraft. A tuning in flight will be needed to adjust the following neutrals. Adjust the roll neutral to fly straight. Adjust the pitch neutral to fly level with the desired throttle.
<define name="ROLL_NEUTRAL_DEFAULT" value="-2.5" unit="deg"/>
<define name="PITCH_NEUTRAL_DEFAULT" value="6" unit="deg"/>

Finally, an asymmetric (left/right, front/rear) correction can be added with a last set of factors.
<define name="CORRECTION_UP" value="1."/>
<define name="CORRECTION_DOWN" value="1."/>
<define name="CORRECTION_LEFT" value="1."/>
<define name="CORRECTION_RIGHT" value="1."/>
</section>
These corrections are set on the angles.

The old way to define the parameters is still possible, but must not be mixed with the new one describe above.

=== Gyro ===
Defines the type of gyro installed, each axis neutral, and any required temperature compensation. If the gyro has two axes, the pitch neutral is defined as well. Many gyros output their internal temperature and require a temperature-dependent linear correction be made to the neutral value. No correction is done for the temperature in this example.(<b><tt>ADC_TEMP_SLOPE=0</tt></b>).

<tt>
<section name="GYRO" prefix="GYRO_"
<define name="ADC_ROLL_COEFF" value="1"/>
<define name="ROLL_NEUTRAL" value="500"/>
<define name="ADC_TEMP_NEUTRAL" value="476"/>
<define name="ADC_TEMP_SLOPE" value="0"/>
</section>
</tt>

=== Bat ===
This section give characteristics for the monitoring of the main power battery. <b><tt>MILLIAMP_PER_PERCENT</tt></b> represents the consumption (in mA) for one percent of THROTTLE and for one time unit. It is used to compute the <tt>energy</tt> value of the <tt>BAT</tt> message.

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. This definition is optional with a default value of 12.5V.

<tt>
<section name="BAT">
<define name="MILLIAMP_PER_PERCENT" value="0.86"/>
<define name="VOLTAGE_ADC_A" value="0.0177531"/>
<define name="VOLTAGE_ADC_B" value="0.173626"/>
<define name="VoltageOfAdc(adc)" value ="(VOLTAGE_ADC_A * adc + VOLTAGE_ADC_B)"/>
<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>
</tt>

=== Horizontal Control ===
<tt>
<section name="HORIZONTAL CONTROL" prefix="H_CTL_">
<define name="COURSE_PGAIN" value="-0.4"/>
<define name="ROLL_MAX_SETPOINT" value="0.35" unit="radians"/>
<define name="ROLL_ATTITUDE_GAIN" value="-7500."/>
<define name="ROLL_RATE_GAIN" value="-1500"/>
<define name="PITCH_PGAIN" value="-8000."/>
<define name="ELEVATOR_OF_ROLL" value="1250"/>
</section>
</tt>

The outer loop acts on the route. It will produce a roll command from a course setpoint and a course measurement. The COURSE_PGAIN parameter is the factor multiplied by the course error (in radian) to get a roll setpoint (in radian). So if the plane is expected to go north (course=0) and is actually flying to 57 degrees (course=1 radian, i.e. ENE), with a gain of '''-0.4''', a roll of -0.4 (23 degrees) will be set for the lower control loop.

The ROLL_ATTITUDE_GAIN is used to compute a ROLL command from the roll error (setpoint minus measurement). If a gyro in installed, the ROLL_RATE_GAIN to keep a null roll rate. So these two gains provide a P-D controller.

===Vertical Control===

<section name="VERTICAL CONTROL" prefix="V_CTL_">

<define name="ALTITUDE_PGAIN" value="-0.1" unit="(m/s)/m"/>

<define name="ALTITUDE_MAX_CLIMB" value="3." unit="m/s"/>
These lines are associated with vertical control loops contained in ./sw/airborne/fw_v_ctl.c. These are outer loop parameters that calculate a desired climb rate based on altitude error. Here, if the altitude error is 10m, the climb setpoint will be set to 1m/s. ALTITUDE_MAX_CLIMB is a bounded value (in m/s) so that the outer loop does not calculate too large of a climb rate
<define name="AUTO_THROTTLE_NOMINAL_CRUISE_THROTTLE" value="0.65" unit="%"/>
<define name="AUTO_THROTTLE_MIN_CRUISE_THROTTLE" value=".4" unit="%"/>
<define name="AUTO_THROTTLE_MAX_CRUISE_THROTTLE" value="1" unit="%"/>
<define name="AUTO_THROTTLE_LOITER_TRIM" value="1000" unit="pprz_t"/>
<define name="AUTO_THROTTLE_DASH_TRIM" value="-2500" unit="pprz_t"/>
<define name="AUTO_THROTTLE_CLIMB_THROTTLE_INCREMENT" value="0.15" unit="%/(m/s)"/>
<define name="AUTO_THROTTLE_PGAIN" value="-0.008" unit="%/(m/s)"/>
<define name="AUTO_THROTTLE_IGAIN" value="0.25"/>
<define name="AUTO_THROTTLE_PITCH_OF_VZ_PGAIN" value="0.35" unit="rad/(m/s)"/>

These lines are associated with vertical rate control loops contained in ./sw/airborne/fw_v_ctl.c and are used by default in most cases. The default vertical control law is for the vertical rate to be managed by a combination of throttle and pitch.

<define name="AUTO_PITCH_PGAIN" value="-0.1"/>
<define name="AUTO_PITCH_IGAIN" value="0.025"/>
<define name="AUTO_PITCH_MAX_PITCH" value="0.5"/>
<define name="AUTO_PITCH_MIN_PITCH" value="-0.5"/>

These lines are associated with vertical control loops contained in ./sw/airborne/fw_v_ctl.c but are not used in default. The non-default vertical control law is for the vertical rate to be managed by the pitch.

<define name="THROTTLE_SLEW_LIMITER" value="2" unit="s"/>
THROTTLE_SLEW_LIMITER is the required time is seconds to change throttle from 0% to 100%.

=== Misc ===
<tt>
<section name="MISC">
<define name="NOMINAL_AIRSPEED" value ="12." unit="m/s">
<define name="CARROT" value="5." unit="s"/>
<define name="KILL_MODE_DISTANCE" value="(1.5*MAX_DIST_FROM_HOME)"/>
<define name="CONTROL_RATE" value"60" unit="Hz"/>
</section>
</tt>

* The "NOMINAL_AIRSPEED" is mainly used in the simulator.
* "CARROT" gives the distance (in seconds, so ground speed is taken into account) between the carrot and the aircraft.
* "KILL_MODE_DISTANCE" is the threshold distance to switch the autopilot into KILL mode (defined descent with no throttle)
* "CONTROL_RATE" is the rate of the low level control loops in Hertz (60 or 20).

== Hardware definitions - Makefile ==

The airframe file must include the description of the controller board and it's low-level settings. This is done in one <b><tt>makefile</tt></b> section starting with the autopilot model and flashing mode:
{{Box Code|conf/airframes/myplane.xml|
<makefile>
include $(PAPARAZZI_SRC)/conf/autopilot/tiny.makefile
<nowiki>FLASH_MODE=IAP</nowiki>
.
.
.
</makefile>
}}
Below this are the definintions and configuration of the peripherals and interfaces.

=== Radio Control ===
The Paparazzi autpilot can interface directly with the PWM signal from any standard hobby R/C receiver. Signal decoding configuration settings for this are stored in the [[Radio_Control|Radio Control]] file.

If you have a Tiny v1.1 Autopilot:
{{Box Code|conf/airframes/myplane.xml|
<nowiki>ap.CFLAGS += -DACTUATORS=\"servos_4015_MAT_hw.h\" -DSERVOS_4015_MAT</nowiki>
<nowiki>ap.srcs += $(SRC_ARCH)/servos_4015_MAT_hw.c actuators.c</nowiki>
<nowiki>ap.CFLAGS += -DRADIO_CONTROL -DRADIO_CONTROL_TYPE=RC_FUTABA</nowiki>
<nowiki>ap.srcs += radio_control.c $(SRC_ARCH)/ppm_hw.c</nowiki>
}}
If you have a Tiny v2 or TWOG v1 Autopilot:
{{Box Code|conf/airframes/myplane.xml|
<nowiki>ap.CFLAGS += -DACTUATORS=\"servos_4017_hw.h\" -DSERVOS_4017</nowiki>
<nowiki>ap.srcs += $(SRC_ARCH)/servos_4017_hw.c actuators.c</nowiki>
<nowiki>ap.CFLAGS += -DRADIO_CONTROL -DRADIO_CONTROL_TYPE=RC_FUTABA</nowiki>
<nowiki>ap.srcs += radio_control.c $(SRC_ARCH)/ppm_hw.c</nowiki>
}}
If you want to output standard PPM to a R/C receiver:
{{Box Code|conf/airframes/myplane.xml|
<nowiki>ap.CFLAGS += -DACTUATORS=\"servos_ppm_hw.h\" -DSERVOS_PPM_MAT</nowiki>
<nowiki>ap.srcs += $(SRC_ARCH)/servos_ppm_hw.c actuators.c</nowiki>
<nowiki>ap.CFLAGS += -DRADIO_CONTROL -DRADIO_CONTROL_TYPE=RC_FUTABA</nowiki>
<nowiki>ap.srcs += radio_control.c $(SRC_ARCH)/ppm_hw.c</nowiki>
}}
This is used in the case where you want to directly drive a receiver which has a microcontroller to do the decoding and driving of the servos (not a 4015 or 4017 decoder chip). The PPM is output on the SERV_CLK pin. The PPM frame rate, pulse width, and number of channels can be adjusted in the "servos_ppm_hw.h" file to suit your particular receiver.

If you have a Classix Autopilot:
{{Box Code|conf/airframes/myplane.xml|
<nowiki>ap.CFLAGS += -DRADIO_CONTROL -DRADIO_CONTROL_TYPE=RC_FUTABA</nowiki>
<nowiki>ap.EXTRA_SRCS += radio_control.c $(SRC_ARCH)/ppm_hw.c</nowiki>
<nowiki>ap.CFLAGS += -DACTUATORS=\"servos_direct_hw.h\"</nowiki>
<nowiki>ap.EXTRA_SRCS += $(SRC_ARCH)/servos_direct_hw.c</nowiki>
}}

You can set RADIO_CONTROL_TYPE to RC_FUTABA, for falling edge PPM, or RC_JR for rising edge PPM. "RC_FUTABA" is for the Futaba or compatible brands, and "RC_JR" for JR (a.k.a Graupner outside of the USA) or compatible brands.

For the Classix, you must specify which pins to use for PWM by adding "-DPWM_SERVO_0, etc." to the line fbw.CFLAGS. This activate the PWM channel.
<tt>wiring on classix PWM connector
connector LPC shared port
PWM1 PWM5 AD1_6 CAP1_3 P0.21
PWM2 PWM3 RXD0 EINT0 P0.1
PWM3 PWM1 TXD0 P0.0
PWM4 PWM6 RXD1 EINT3 P0.9
PWM5 PWM4 TXD1 AD1_1 P0.8
PWM6 PWM2 SSEL0 EINT2 P0.7</tt>
PWM1 and PWM6 should be safe. PWM4 and PWM5 should be OK if you're not using UART1 on the FBW processor - same for PWM2 and PWM3 if you're not using UART0 (disable FBW telemetry for that ).

=== 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 <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.

Paparazzi supports the following modem protocols:
* Standard transparent serial (pprz) - this is compatible with all modems and can be used to connect the autopilot directly to a PC for testing without a modem.
* Maxstream API protocol (xbee) - compatible with all Maxstream modems including the 9XTend and Zigbee. This protocol enables hardware addressing, allowing multiple aircraft to be managed from a single ground modem.
* Coronis Wavecard - necessary for operation with the unusual Coronis Wavecard modem.
Select the baud/protocol in the airframe file by commenting/uncommenting the appropriate section as follows:
==== Configuring The Serial Protocol ====
New users are advised to start with the standard serial protocol before attempting to setup an addressed API link. There are no real reasons for the novice user to use the xbee protocol over the standard PPRZTransport. Even if you are using a Maxstream modem you should still start out with the standard. Lastly it should be pointed out that using a single UAV there is no disadvantage and that the [http://www.engr.usu.edu/wiki/index.php/OSAM OSAM] Paparazzi Team at UAS 2008 took second place using the STANDARD protocol. The serial protocol works with virtually any modem as well as direct cable connections. The baud rates of the airborne modem, autopilot, ground modem, and PC must be configured correctly. The PC and autopilot serial ports do not need to be set to the same baud rate, i.e. when running multiple aircraft from a single ground modem, the ground modem may require a higher baud rate than any of the airborne modems in order to stream the data from multiple simultaneous sources.

{{Box Code|conf/airframes/myplane.xml|
<nowiki>
<section name="DATALINK" prefix="DATALINK_">
<define name="DEVICE_TYPE" value="PPRZ"/>
<define name="DEVICE_ADDRESS" value="...."/>
</section>
</nowiki>
}}
The above example tells the autopilot to send and recieve data in standard serial form.

{{Box Code|conf/airframes/myplane.xml - makefile section at the bottom|
# Serial modem
<nowiki>ap.CFLAGS += -DDOWNLINK -DUSE_UART0 -DDOWNLINK_TRANSPORT=PprzTransport -DDOWNLINK_FBW_DEVICE=Uart0 -DDOWNLINK_AP_DEVICE=Uart0 -DPPRZ_UART=Uart0 -DDATALINK=PPRZ -DUART0_BAUD=B57600</nowiki>
<nowiki>ap.srcs += downlink.c $(SRC_ARCH)/uart_hw.c datalink.c pprz_transport.c</nowiki>
}}
The above example configures the autopilot serial port (Uart0) to 57,600 baud and calls the serial transport protocol (pprz_transport.c). Use the "#" symbol to comment lines in this section of the airframe file.
<br>
Note:
* The autopilot and modem serial port baud rates must match at all times and also must match the ground modem rate, check your modem documentation to find the default baud rate and configure a different rate as needed.

<br style="clear:both>

Ensure that the ground station is using the same protocol and an equal or higher baud rate:
{{Box Code|conf/control_panel.xml|
<nowiki>
<session name="USB">
<program name="link">
<arg flag="-d" constant="/dev/paparazzi/ttyUSB0"/>

<arg flag="-uplink" constant=""/>
<arg flag="-s" constant="57600"/>
</program>
...
</session>
</nowiki>
}}
Use this constant /dev/paparazzi/ttyUSB0 when using either the ftdi cable or a Maxstream USB ground modem.. Otherwise use /dev/ttyUSB0 (the ttyUSB0 being the device that you are using. Note: it might not always be ttyUSB0). This paparazzi directory in the dev folder is created when setting the udev rules. [http://paparazzi.enac.fr/wiki/index.php/Installation#Setting_access_rights_for_USB_download Setting Udev rules]

==== Configuring The Maxstream API Protocol ====
The optional API protocol enables hardware addressing so that multiple aircraft can be managed from a single ground modem, or multiple aircraft and multiple ground stations can work simultaneously without interference from one another. API mode is enabled by sending an escape sequence (+++) followed by AT commands, this can be done automatically at each boot or can be permanently configured with the "ATWR" command for greater reliability.

{{Box Code|conf/airframes/myplane.xml|
<nowiki>
<section name="MISC">
...
<define name="XBEE_INIT" value="\"ATPL2\rATRN1\rATTT80\r\ATBD6\rATWR\r\""/>
...
</section></nowiki>
}}
The above example will program the Maxstream to API mode, 100mW power (ATPL2), 57600 baud (ATBD6), and permanently store the changes (ATWR). After flashing allow 30 seconds for the modem to store the changes, then disable the init string by adding the line <tt><define name="NO_XBEE_API_INIT" value="TRUE"/></tt> (the parameter "value" has no effect), update the baud rate as needed, and re-flash the autopilot. The modem and autopilot serial port baud rates must match eachother at all times.
<br>
Notes:
* Maxtream modems are factory configured for 9600 baud, in order to change baud rates, first configure the autopilot serial port to match the modem (DUART0_BAUD=B9600), boot the system so that the baud rate change command is sent to the modem (ATBD6) and permanently saved (ATWR), allow 30 seconds for the modem configuration to complete, then reprogram the autopilot with the new baud rate (DUART0_BAUD=B57600) and disabled modem configuration string <tt><define name="NO_XBEE_API_INIT" value="TRUE"/> </tt>.
* The ac_id defined in <tt>conf/conf.xml</tt> is permanently programmed into the modem so this procedure would need to be re-run if the modem is moved to another plane.
* For temporary boot-time API configuration remove any baud rate changes, remove <tt>ATWR\r</tt> from the end of the string.
* Upgrade your Maxstream firmware to the latest version before attempting API mode operation.

<br style="clear:both>

{{Box Code|confAgain/airframes/myplane.xml - makefile section at the bottom|
<nowiki># Maxstream API protocol</nowiki>
<nowiki>ap.CFLAGS += -DDOWNLINK -DUSE_UART0 -DDOWNLINK_TRANSPORT=XBeeTransport -DDOWNLINK_FBW_DEVICE=Uart0 -DDOWNLINK_AP_DEVICE=Uart0 -DXBEE_UART=Uart0 -DDATALINK=XBEE -DUART0_BAUD=B57600</nowiki>
<nowiki>ap.srcs += downlink.c $(SRC_ARCH)/uart_hw.c datalink.c xbee.c</nowiki>
}}
The above example configures the autopilot serial port (Uart0) to 57,600 baud and calls the Maxstream transport protocol (xbee.c). Use the "#" symbol to comment lines in this section of the airframe file.
<br style="clear:both>

Ensure that the ground station is using the same protocol and an equal or higher baud rate:
{{Box Code|conf/control_panel.xml|
<nowiki>
<session name="USB">
<program name="link">
<arg flag="-d" constant="/dev/paparazzi/ttyUSB0"/>
<arg flag="-transport" constant="xbee"/>
<arg flag="-uplink" constant=""/>
<arg flag="-s" constant="57600"/>
</program>
...
</session>
</nowiki>
}}
Use this constant /dev/paparazzi/ttyUSB0 when using either the ftdi cable or a Maxstream USB ground modem.. Otherwise use /dev/ttyUSB0 (the ttyUSB0 being the device that you are using. Note: it might not always be ttyUSB0). This paparazzi directory in the dev folder is created when setting the udev rules. [http://paparazzi.enac.fr/wiki/index.php/Installation#Setting_access_rights_for_USB_download Setting Udev rules]
=====Alternate Method=====
This is the way it is done in funjet1.xml and has been tested to work by Danstah

{{Box Code|conf/airframes/funjet1.xml|
<nowiki>
<section name="MISC">
...
<define name="XBEE_INIT" value="\"ATPL2\rATRN1\rATTT80\r\""/>

...
</section></nowiki>
}}
Also use this
{{Box Code|conf/airframes/funjet1.xml|
<nowiki>

<section name="DATALINK" prefix="DATALINK_">
<define name="DEVICE_TYPE" value="XBEE"/>
<define name="DEVICE_ADDRESS" value="...."/>
</section>
</nowiki>
}}
And Finally use this in the makefile section
{{Box Code|conf/airframes/funjet1.xml|
<nowiki>
ap.CFLAGS += -DDOWNLINK -DUSE_UART1 -DDOWNLINK_TRANSPORT=XBeeTransport -DXBEE_UART=Uart1 -DDATALINK=XBEE -DUART1_BAUD=B9600
ap.srcs += downlink.c $(SRC_ARCH)/uart_hw.c datalink.c xbee.c
</nowiki>
}}
By reading all the information above you should be able to infer what the above does.

Now keep in mind that the ground modem baud rate and airplanes modem baud rates do not have to match. The only things that need to match are the the modem on the planes baud rate and the rate defined in the airframe file. For example this planes modem is set to 9600 and this could be used with the ground modem configured above using 57600...
Also for multiple UAV's a good way to configure them is to use 9600 for the ap and use a ground modem configured to 57600 and its not a bad idea to use minimal telemetry.

=== 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:

{{Box Code|conf/airframes/myplane.xml|
<nowiki>ap.CFLAGS += -DGPS -DUBX -DUSE_UART1 -DGPS_LINK=Uart1 -DUART1_BAUD=B38400</nowiki>
<nowiki>ap.srcs += gps_ubx.c gps.c</nowiki>
}}
'''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 thru the [[Compiling#USB_flashing|UART Tunnel]] and [[GPS#GPS_configuration_using_U-Center Configured with|u-center]]

If using the u-blox LEA-5H, add the flag -DGPS_USE_LATLONG in the makefile section of the airframe xml file in the gps section. This flag must be inserted above "ap.srcs += gps_ubx.c gps.c" for proper operation.

{{Box Code|conf/airframes/myplane.xml|
<nowiki>ap.CFLAGS += -DGPS -DUBX -DUSE_UART1 -DGPS_LINK=Uart1 -DUART1_BAUD=B38400 -DGPS_USE_LATLONG
ap.srcs += gps_ubx.c gps.c</nowiki>
}}

=== Sensors ===

=== Control loops ===

The control loops can be divided in two largely independent groups : the vertical ones and the horizontal ones (files sw/airborne/fw_h_ctl.c and sw/airborne/fw_v_ctl.c ). Those loops can be commanded at different levels by either the R/C transmitter or the autonomous navigation routine.

First the horizontal loop:
{{Box Code|conf/airframes/funjet1.xml|
<nowiki>ap.CFLAGS += -DNAV -DAGR_CLIMB -DLOITER_TRIM
ap.srcs += nav.c fw_h_ctl.c fw_v_ctl.c
</nowiki>
}}

Main Page

2009-03-01T09:39:22Z

Rcbrother:

__NOTOC__
__NOEDITSECTION__

{|style="border-spacing:8px;margin:0px -8px" class="MainPageBG" style="width:100%;border:1px solid #9999bf;background-color:#f5fffa;vertical-align:top;color:#000; text-align: left;"
|-
|align="center" colspan="2"| <h2 style="margin:0;background-color:#82add9;font-size:150%;font-weight:bold;border:1px solid #a3bfb1;text-align:center;color:#ffffff;padding:0.2em 0.4em;">Welcome To Paparazzi</h2>
|-valign="top"
|
<h3 style="-moz-border-radius-topright: 1em;-moz-border-radius-topleft: 1em;
background:#cedff2;margin:-2px;padding:4px;">
[[Image:favicon32.png|32px]] [[General|General]]
</h3>
<div style="padding:6px;">
{{General}}
</div>
<h3 style="-moz-border-radius-topright: 1em;-moz-border-radius-topleft: 1em;
background:#cedff2;margin:-2px;padding:4px;">
[[Image:favicon32.png|32px]] [[Hardware|Hardware]]
</h3>
<div style="padding:6px;">
{{Hardware}}
</div>
<h3 style="-moz-border-radius-topright: 1em;-moz-border-radius-topleft: 1em;
background:#cedff2;margin:-2px;padding:4px;">
[[Image:favicon32.png|32px]] [[Software|Software]]
</h3>
<div style="padding:6px;">
{{Software}}
</div>
<h3 style="-moz-border-radius-topright: 1em;-moz-border-radius-topleft: 1em;
background:#cedff2;margin:-2px;padding:4px;">
[[Image:favicon32.png|32px]] [[Miscellaneous|Miscellaneous]]
</h3>
<div style="padding:6px;">
{{Miscellaneous}}
</div>

| class="MainPageBG" style="width:70%;border:1px solid #cedff2;background-color:#f5faff;vertical-align:top"|
{|width="100%" cellpadding="2" cellspacing="5" style="vertical-align:top;background-color:#f5fffa"
|-valign="top"
| <h2 style="margin:0;background-color:#cef2e0;font-size:120%;font-weight:bold;border:1px solid #a3bfb1;text-align:left;color:#000;padding:0.2em 0.4em;">The Paparazzi Project</h2>
|-
|style="color:#000"|[http://www.nongnu.org/paparazzi/ Paparazzi] is a free and open-source hardware and software project intended to create an exceptionally powerful and versatile autopilot system by allowing and encouraging input from the community. The project includes not only the airborne hardware and software, from voltage regulators and GPS receivers to [http://en.wikipedia.org/wiki/Kalman_filtering Kalman filtering] code, but also a powerful and ever-expanding array of ground hardware and software including modems, antennas, and a highly evolved user-friendly ground control software interface.
|-
|All hardware and software is open-source and freely available to anyone under the [http://www.gnu.org GNU] licencing agreement. [[Get_Hardware| Several vendors]] are currently producing and selling Paparazzi autopilots and popular accessories, making the system easy and affordable to all.
|-
|The key feature of the paparazzi autopilot is its unique combination of infrared thermopiles and inertial measurement for attitude sensing, providing a robust and accurate attitude estimate that requires no ground calibration and can recover from any launch attitude.
|-
| <h2 style="margin:0;background-color:#cef2e0;font-size:120%;font-weight:bold;border:1px solid #a3bfb1;text-align:left;color:#000;padding:0.2em 0.4em;">The Paparazzi project at ENAC</h2>
|-
|The Paparazzi mini [http://en.wikipedia.org/wiki/Unmanned_Aircraft_System UAS] project is now being used and developed at [http://www.enac.fr/ ENAC University].
|-
|style="color:#000"|
* A [http://www.debian.org debian] [http://www.recherche.enac.fr/paparazzi/debian/ repository] containing some packages not in the official distribution and required to run Paparazzi.
* PaparazziX [http://www.ubuntu.com/ Ubuntu] based live CD is available from the [http://www.recherche.enac.fr/paparazzi/paparazzix/ paparazzix directory].
* Nightly and release [http://www.recherche.enac.fr/paparazzi/tarball/ tarballs].
|}
{| width="100%" cellpadding="2" cellspacing="5" style="vertical-align:top;background-color:#faf5ff;border:1px solid #ddcef2; text-align: justify;"
| <h2 style="margin:0;background-color:#ddcef2;font-size:120%;font-weight:bold;border:1px solid #afa3bf;text-align:left;color:#000;padding:0.2em 0.4em;">News</h2>
|-
|<h3>February 16th, 2009</h3>
|-
| We have a new forum to talk about this project. Please visit and participate http://www.azoreanuav.com/forum . Please, vote in the next link to continue with the forum or not. http://www.azoreanuav.com/forum/viewtopic.php?f=2&t=7
|-
|-
|<h3>February 9th, 2009</h3>
|-
| 3 ENAC students have released a Graphical control application for Paparazzi on Mobile phone using Java technoligies. Check the [[Ipodrom]] project page for more details.
|-
|<h3>January 19, 2009</h3>
|-
| style="color:#000"|
Paparazzi Developers,<br>
This is to announce a Call for Papers for the 2009 ASME/IEEE International Conference on Mechatronic and Embedded Systems and Applications (MESA09), part of ASME IDETC09. The conference is to be held August 30 - September 2, 2009 at San Diego Convention Center. This Call for Papers is specific to the Session chaired by myself, Antoine Drouin , and Anton Kochevar. This topic of this session is " Open Source UAV Autopilots: Status and Progression", part of a symposium of MESA09 called "Small Unmanned Aerial Vehicle Technologies and Applications (SUAVTA)". This Technical Session is meant to be a session that will focus on Paparazzi, the topics can include specific features developed for Paparazzi or applications using Paparazzi along with other innovative aspects or uses of Paparazzi. We hope to make this one of the largest and best conferences dealing with Paparazzi. Please help us to promote Paparazzi and bring this amazing project to even more people. Full paper deadline is Feb. 27, 2009 using the online submission system.

Conference Website: https://www.asmeconferences.org/IDETC09/ (click MESA09, then, UAV Symposium, then this dedicated session) or http://iel.ucdavis.edu/mesa/MESA09/

If you have any further questions please email me at
daniel.morgan @ aggiemail.usu.edu (remove spaces)
Research Associate, Center for Self-Organizing and Intelligent Systems at Utah State University
http://www.engr.usu.edu/wiki/index.php/User:CSOIS
<br>
|-
|<h3>September 23, 2008</h3>
|-
| style="color:#000"| [[Image:motodrone_08u.JPG|thumb|left]]
A paparazzi team took part in the [http://motodrone.org/ Motodrone] event held in Finowfurt near Berlin.<br>
It was fun, the beer was cool and barbecues worked flawlessly. And we flew funjets...
<br>
[http://berlinvr.info/motodrone2008.html Video]

|-
|<h3>June 23, 2008</h3>
|-
| style="color:#000"| [[Image:Targets auvsi 08.JPG|thumb|left]]
The [http://www.engr.usu.edu/wiki/index.php/OSAM OSAM] Paparazzi team took 2nd place in the Sixth Annual Student Unmanned Aerial Systems Competition! The event is sponsored by AUVSI (Association for Unmanned Vehicle Systems International) and was held at Webster Field, St. Inigoes, Maryland. It should also be noted that this was Paparazzi's and the OSAM Paparazzi team's first time at the competition.<br>
[http://www.navair.navy.mil/pma263/seafarers/default.htm Link to competition]
<br>
[http://hjnews.townnews.com/articles/2008/07/12/news/news01.txt News Story]

|-
|<h3>June 13, 2008</h3>
|-
| style="color:#000"| [[Image:Twog_v1-00_top_side_3.jpg|thumb|left|'''T'''iny '''W'''ith'''O'''ut '''G'''ps]]
The new baby autopilot is born.<br>
His name is TWOG, he weighs 8 grams and is 40.2 x 30.5mm long. He' in good health and looks a lot like his mother Tiny v2, except for the GPS receiver.<br>
The proud parents invite you to visit the [[Twog_v1|pictures and technical information album]]...

|-
|<h3>March 26, 2008</h3>
|-
| style="color:#000"| [[Image:Heli_deck.jpg|thumb|left|Funjet on the helicopter deck]]
Scientists from the [http://web.gfi.uib.no/index_e.html Geophysical Institute of the University of Bergen/Norway] flew Paparazzi controlled [[media:Funjet_spitsbergen.jpg|Funjet]] aircrafts equipped with meteorological sensors in the Arctic sea around Spitsbergen only with the help of a RC safety pilot and no Paparazzi team member nearby. They took off and landed on the helicopter deck of the Norwegian icebreaking coast guard vessel [http://www.jtashipphoto.dk/JTA-W303%20Svalbard.htm KV Svalbard] for one week and set a new Paparazzi low temperature record by flying at around -20°C and 15m/s wind in altitudes up to 1500m. For another two weeks they also collected data on Spitsbergen near Longyearbyen. See pictures in the gallery and a [http://www.youtube.com/watch?v=VWEa_4Hlm2s video].

|-
|<h3>March 15, 2008</h3>
|-
| style="color:#000"| [[Image:Tiny_v2-1_3D_top.jpg|thumb|left|Tiny 2.11]]
A number of vendors are now offering assembled and unassembled autopilots, sensors and accessories. The software is written, the hardware is built, what are you waiting for? Getting started has never been easier! More details on the [[Get_Hardware|Get Hardware]] page.

|-
|<h3>February 6, 2008</h3>
|-
| style="color:#000"| [[Image:eeePC.jpg|thumb|left|Paparazzi running on eeePC]]
Looking for a small, light and cheap ground station ? Paparazzi runs on the [http://eeepc.asus.com ASUS eeePC] out of the box (after installing the Debian Paparazzi packages). Tested on the pre-installed Xandros distribution, on a standard Ubuntu and on the preconfigured [http://wiki.eeeuser.com/ubuntu:eeexubuntu:home eeeXubuntu].

|-
|<h3>January 27, 2008</h3>
|-
| style="color:#000"| [[Image:StormTV.jpg|thumb|left|Paparazzi's Storm on TV in Turkey]] [http://www.showtvnet.com/haber/playerd.asp?ptype=haber&product=/270108/ucak.wmv Storm on TV], A Paparazzi aircraft is featured on the biggest Television station in Turkey. (Sorry, the audio is only in Turkish...)

|-
|<h3>[[News Archives]]</h3>
|-
| style="color:#000"|
[[Image:One_Small_Step.jpg|thumb|left|[[News Archives]]]] [[News Archives|Browse the archives]] for a look back at the earlier days of Paparazzi.
|-

|}
|}

Installation/Linux

2009-01-07T20:18:02Z

Rcbrother: /* Software Updates */

Precompiled binaries can be downloaded and executed with the ''paparazzi-bin'' package but to maintain the power and flexibility of open-source code, most operations within Paparazzi involve recompilation of autopilot and/or ground station code. Therefore the typical installation requires all of the necessary C and OCaml compilers as well as some XML and [http://www.tls.cena.fr/products/ivy/ Ivy] handlers. These tools are provided by the ''paparazzi-dev'' package.

The Paparazzi sources are hosted by [http://savannah.nongnu.org/cvs/?group=paparazzi Savannah].

The Paparazzi packages are hosted at the [http://www.recherche.enac.fr/paparazzi/debian ENAC repository].

== Installation on Debian based distributions ==

Paparazzi is packaged for Debian as well as all of its dependencies. The [http://www.recherche.enac.fr/paparazzi/debian repository] hosted at ENAC holds their latest version.

=== Installation from the Command Line===
Just add the following lines to your repository list (<b>/etc/apt/sources.list</b>) and then
uncomment the line relevant to your operating system (e.g. one of etch, gutsy or hardy):

{{Box Code|/etc/apt/sources.list|
# Uncomment just _one_ of the following lines - depending on your OS version
# deb <nowiki>http://paparazzi.enac.fr/debian</nowiki> etch main
# deb <nowiki>http://paparazzi.enac.fr/debian</nowiki> lenny main
# deb <nowiki>http://paparazzi.enac.fr/ubuntu</nowiki> gutsy main
# deb <nowiki>http://paparazzi.enac.fr/ubuntu</nowiki> hardy main
# deb <nowiki>http://paparazzi.enac.fr/ubuntu</nowiki> intrepid main
}}

Note: It is not recommended to install both <tt>paparazzi-bin</tt> <b>and</b> <tt>paparazzi-dev</tt>.

Then, update your sources and '''either''' install the precompiled <b>bin</b>aries
sudo apt-get update
sudo apt-get install paparazzi-bin
<b>or</b> the dependencies needed for recompiling from the source (<b>dev</b>), and the cross-compiler (<b>arm7</b>) :
sudo apt-get update
sudo apt-get install paparazzi-dev
sudo apt-get install paparazzi-arm7

As stated before it is not recommended to install both <tt>paparazzi-bin</tt> <b>and</b> <tt>paparazzi-dev</tt>. While the <b>bin</b> package is self-contained and should be sufficient for users who do not want to patch the code, the <b>dev</b> meta-package provides only the tools to compile the source code which must be separately downloaded, from an archive or the CVS repository.

==== Optional/Obsolete Packages ====
Users of older AVR based boards will also need the paparazzi-avr package.

==== Extra for Ubuntu ====

The Braille TTY driver interferes with FTDI USB Serial adapters and should be removed:

sudo apt-get remove brltty

=== Installation thru Synaptic Package Manager ===
* Launch ''Synaptic Package Manager'' (''Applications/System'' Tools Menu)
* In '''Settings/Repositories''', add a new repository on URI = '''<nowiki>http://paparazzi.enac.fr/debian</nowiki>''', Distribution = '''etch''', Section = '''main''' . For Ubuntu, replace '''debian''' by '''ubuntu''' and '''etch''' by '''gutsy''' (or '''hardy''')
* Search for <tt>paparazzi-bin</tt>, <tt>paparazzi-dev</tt>, and <tt>paparazzi-arm7</tt> packages (use the ''Search'' button)
* Mark them for installation (right-click on package names)
* Left-click on ''Apply''

== Manual Installation of Individual Packages ==
Users of other Linux flavors or anyone needing manual control of each individual package can install them independently. The list of dependencies of the Debian package is located in the [http://cvs.savannah.gnu.org/viewvc/paparazzi/paparazzi3/debian/control.etch?revision=1.16&view=markup <tt> debian/control.etch</tt>] file and may help users of other distributions.

The binary packages and some corresponding source tarballs can be downloaded from

http://paparazzi.enac.fr/debian/dists/etch/main/binary-i386/

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

For Fedora (Core8) users, you can install the following packages from standard repository:
* ocaml.i386
* ocaml-camlimages-devel.i386
* ocaml-lablgtk-devel.i386
* ocaml-xml-light-devel.i386
* boa.i386
* libgnomecanvas-devel.i386
* libusb-devel.i386
* pcre-devel.i386
* arm-gp2x-linux-gcc.i386
* arm-gp2x-linux-binutils.i386
* glade2.i386
* and gcc, make, cvs, gnuplot, imagemagik...

Then you need [http://packages.debian.org/unstable/source/alien alien] tool to convert packages from the paparazzi repository:
* ivy-c
* ivy-c-dev
* ivy-ocaml (WARNING: debian and fedora have different path for ocaml (/usr/lib/ocaml/<version> vs. /usr/lib/ocaml), so you need to move by hand the files in /usr/lib/ocaml/<version> to /usr/lib/ocaml)
* lpc21isp

== Installing the Source Code (not needed with paparazzi-bin) ==
After the <tt>paparazzi-dev</tt> package is installed the complete source code should be downloaded from the CVS repository. See the [http://savannah.nongnu.org/cvs/?group=paparazzi project page] at Savannah for more details. From the directory of your choice type:
cvs -z3 -d:pserver:anonymous@cvs.savannah.nongnu.org:/sources/paparazzi co paparazzi3
This will download all of the code and install it into <tt>paparazzi3/</tt>

If you cannot use the CVS install, dayly updated tarballs can also be fetched from the [[Downloads|Downloads]] page.

== Launching the Software ==

If you are using the <tt>paparazzi-bin</tt> package or the Live-CD, just launch the <tt>paparazzi</tt> binary application and you will be guided through the installation of your personal configuration files.

If you are using the source code, the first step is to compile it. From the <tt>paparazzi3</tt> directory (<tt>cd paparazzi3</tt>), run

make

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

./paparazzi

From the [[Paparazzi_Center|Paparazzi Center]] interface, select the ''MJ5'' aircraft, select the ''sim'' target and ''Build'' it. Then ''Execute'' the ''Simulation'' session.

If ('''and only if''') you want to directly launch some Paparazzi agents (the ''Tools'' of the [[Paparazzi_Center|Paparazzi Center]]), 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|/home/your_username/.bashrc|
export PAPARAZZI_HOME<nowiki>=</nowiki>''your paparazzi3 directory''
export PAPARAZZI_SRC<nowiki>=</nowiki>''your paparazzi3 directory''
}}
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:
export PAPARAZZI_HOME=`pwd`;export PAPARAZZI_SRC=`pwd`
Verify that your variables are set correctly with the following command:
env | grep PAPARAZZI
which should return the following:
PAPARAZZI_HOME<nowiki>=</nowiki>''your paparazzi3 directory''
PAPARAZZI_SRC<nowiki>=</nowiki>''your paparazzi3 directory''

== Setting access rights for USB download ==

This may be required to flash the Paparazzi-boards directly thru USB. For flashing details, see [[Compiling]].

Default linux rights may not allow standard (non root) users to directly access the USB bus. You will need to make yourself a member of the plugdev "group" and then create a "rule", associated with that "group". <br>
Make yourself a member of the ''plugdev'' group:

sudo adduser <your login> plugdev

Logout and login again. Then add the appropriate rule (available ine fhe file ''10-paparazzi.rules'') to the USB handler. Simply copy as root <tt>$PAPARAZZI_HOME/conf/system/udev/rules/10-paparazzi.rules</tt> to <tt>/etc/udev/rules.d/</tt>

sudo cp $PAPARAZZI_HOME/conf/system/udev/rules/10-paparazzi.rules /etc/udev/rules.d/

== Software Updates ==
Paparazzi is a very rapidly evolving project and as such, you will find that variables and functions are frequently added, changed, or removed. 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. Your airframe file will not be updated by the CVS system and therefore any new or modified variable names will need to be added manually. The compiler will usually identify the problem variables at which point you can look at some of the most recent airframe files on the CVS to find the proper syntax. See the [[Compiling]] page for more help if needed.
<br>
That said, keeping your software up to date is easy with the CVS system. The system will compare all source code files with the server and update any that are needed, automatically merging any minor changes that you have incorporated along the way.

To download and automatically merge any updated source files, run the following command from your Paparazzi directory
cvs update -d
where the <tt>-d</tt> is needed to get any new directories.

After any CVS update or source code modification the code can be recompiled from ''your paparazzi3 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 deleted all compiled files and recompile from scratch with the following commands:

make clean
make

See the [[Compiling]] page for more info.

Users making changes to their code structure may prefer to have more control over the updating and merging process and may wish to install and use '''tkcvs''' instead which provides highlighted comparisons of any files that differ between your code and the CVS server and allows for a file by file update.

To update your Linux distribution as well as any dependencies of Paparazzi (seldom necessary), run the following as root:

sudo apt-get update
sudo apt-get upgrade

== LiveCd ==

The LiveCD is an easy way to test Paparazzi: no installation is required and no changes are made to your computer. Simply burn the image as a boot CD and reboot! The LiveCD includes Linux and the complete paparazzi binary package (code source, tools and cross compilers). It is intended for demonstration only and not frequently updated but it contains the complete system and can store changed files on a pen drive or compressed file on your hard drive so that it can compile, flash, and operate any aircraft, albeit slowly.

The CD image and a howto on [[Using the Boot CD]] is available from the [[Downloads|Downloads]] page.

The Paparazzi demo is launchable on the Live CD from the Paparazzi icon.

Knoppix allows for all the user data to be saved on a hard disk partition (most file systems are supported) or on a removable device (typically a USB pendrive). Note that this action is not destructive: the user data tree is compressed and stored on your file system as a single file (<tt>knoppix.img</tt>).
* From the Knoppix menu (second from bottom left), choose '''Configure''', '''Create a persistent KNOPPIX disk image'''
* Choose your media (be sure to connect your USB pendrive before booting!)
* Choose if you want an encrypted filesystem (to protect your flight plan designed for the next MAV competition :-) )
* Choose the size of your home directory (100Mb is recommended)
On the next reboot, this saved state will be automatically located and loaded.

Using this persistent feature, the Paparazzix Live CD can really be used to configure, simulate and fly an aircraft with the Paparazzi system.

The Live CD can also be used to install a Debian system on the hard disk, using the <tt>knoppix-installer</tt> command. Be sure to backup the hard disk before trying ...

[[Image:Lightscribe_CD_Cover_1.JPG|thumb|320px|LightScribe CD Cover]] A LiveCD needs some looks... In color or in LightScribe format, your CD will always look cool.
* Get the PDF version for download here [http://paparazzi.enac.fr/wiki_images/Lightscribe_CD_Cover_1.pdf LightScribe CD Cover 1].

* The LightScribe version is in Nero Cover Design format (.ncd) and it's here for download [http://paparazzi.enac.fr/wiki_images/Lightscribe_CD_Cover_1.zip LightScribe CD Cover 1]

* Better is ofcourse to use it on an OpenSource OS, some Linux software to be found here: [http://www.lightscribe.com/downloadSection/linux/index.aspx?id=815]

Installation/Linux

2009-01-07T20:17:00Z

Rcbrother: /* Software Updates */

Precompiled binaries can be downloaded and executed with the ''paparazzi-bin'' package but to maintain the power and flexibility of open-source code, most operations within Paparazzi involve recompilation of autopilot and/or ground station code. Therefore the typical installation requires all of the necessary C and OCaml compilers as well as some XML and [http://www.tls.cena.fr/products/ivy/ Ivy] handlers. These tools are provided by the ''paparazzi-dev'' package.

The Paparazzi sources are hosted by [http://savannah.nongnu.org/cvs/?group=paparazzi Savannah].

The Paparazzi packages are hosted at the [http://www.recherche.enac.fr/paparazzi/debian ENAC repository].

== Installation on Debian based distributions ==

Paparazzi is packaged for Debian as well as all of its dependencies. The [http://www.recherche.enac.fr/paparazzi/debian repository] hosted at ENAC holds their latest version.

=== Installation from the Command Line===
Just add the following lines to your repository list (<b>/etc/apt/sources.list</b>) and then
uncomment the line relevant to your operating system (e.g. one of etch, gutsy or hardy):

{{Box Code|/etc/apt/sources.list|
# Uncomment just _one_ of the following lines - depending on your OS version
# deb <nowiki>http://paparazzi.enac.fr/debian</nowiki> etch main
# deb <nowiki>http://paparazzi.enac.fr/debian</nowiki> lenny main
# deb <nowiki>http://paparazzi.enac.fr/ubuntu</nowiki> gutsy main
# deb <nowiki>http://paparazzi.enac.fr/ubuntu</nowiki> hardy main
# deb <nowiki>http://paparazzi.enac.fr/ubuntu</nowiki> intrepid main
}}

Note: It is not recommended to install both <tt>paparazzi-bin</tt> <b>and</b> <tt>paparazzi-dev</tt>.

Then, update your sources and '''either''' install the precompiled <b>bin</b>aries
sudo apt-get update
sudo apt-get install paparazzi-bin
<b>or</b> the dependencies needed for recompiling from the source (<b>dev</b>), and the cross-compiler (<b>arm7</b>) :
sudo apt-get update
sudo apt-get install paparazzi-dev
sudo apt-get install paparazzi-arm7

As stated before it is not recommended to install both <tt>paparazzi-bin</tt> <b>and</b> <tt>paparazzi-dev</tt>. While the <b>bin</b> package is self-contained and should be sufficient for users who do not want to patch the code, the <b>dev</b> meta-package provides only the tools to compile the source code which must be separately downloaded, from an archive or the CVS repository.

==== Optional/Obsolete Packages ====
Users of older AVR based boards will also need the paparazzi-avr package.

==== Extra for Ubuntu ====

The Braille TTY driver interferes with FTDI USB Serial adapters and should be removed:

sudo apt-get remove brltty

=== Installation thru Synaptic Package Manager ===
* Launch ''Synaptic Package Manager'' (''Applications/System'' Tools Menu)
* In '''Settings/Repositories''', add a new repository on URI = '''<nowiki>http://paparazzi.enac.fr/debian</nowiki>''', Distribution = '''etch''', Section = '''main''' . For Ubuntu, replace '''debian''' by '''ubuntu''' and '''etch''' by '''gutsy''' (or '''hardy''')
* Search for <tt>paparazzi-bin</tt>, <tt>paparazzi-dev</tt>, and <tt>paparazzi-arm7</tt> packages (use the ''Search'' button)
* Mark them for installation (right-click on package names)
* Left-click on ''Apply''

== Manual Installation of Individual Packages ==
Users of other Linux flavors or anyone needing manual control of each individual package can install them independently. The list of dependencies of the Debian package is located in the [http://cvs.savannah.gnu.org/viewvc/paparazzi/paparazzi3/debian/control.etch?revision=1.16&view=markup <tt> debian/control.etch</tt>] file and may help users of other distributions.

The binary packages and some corresponding source tarballs can be downloaded from

http://paparazzi.enac.fr/debian/dists/etch/main/binary-i386/

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

For Fedora (Core8) users, you can install the following packages from standard repository:
* ocaml.i386
* ocaml-camlimages-devel.i386
* ocaml-lablgtk-devel.i386
* ocaml-xml-light-devel.i386
* boa.i386
* libgnomecanvas-devel.i386
* libusb-devel.i386
* pcre-devel.i386
* arm-gp2x-linux-gcc.i386
* arm-gp2x-linux-binutils.i386
* glade2.i386
* and gcc, make, cvs, gnuplot, imagemagik...

Then you need [http://packages.debian.org/unstable/source/alien alien] tool to convert packages from the paparazzi repository:
* ivy-c
* ivy-c-dev
* ivy-ocaml (WARNING: debian and fedora have different path for ocaml (/usr/lib/ocaml/<version> vs. /usr/lib/ocaml), so you need to move by hand the files in /usr/lib/ocaml/<version> to /usr/lib/ocaml)
* lpc21isp

== Installing the Source Code (not needed with paparazzi-bin) ==
After the <tt>paparazzi-dev</tt> package is installed the complete source code should be downloaded from the CVS repository. See the [http://savannah.nongnu.org/cvs/?group=paparazzi project page] at Savannah for more details. From the directory of your choice type:
cvs -z3 -d:pserver:anonymous@cvs.savannah.nongnu.org:/sources/paparazzi co paparazzi3
This will download all of the code and install it into <tt>paparazzi3/</tt>

If you cannot use the CVS install, dayly updated tarballs can also be fetched from the [[Downloads|Downloads]] page.

== Launching the Software ==

If you are using the <tt>paparazzi-bin</tt> package or the Live-CD, just launch the <tt>paparazzi</tt> binary application and you will be guided through the installation of your personal configuration files.

If you are using the source code, the first step is to compile it. From the <tt>paparazzi3</tt> directory (<tt>cd paparazzi3</tt>), run

make

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

./paparazzi

From the [[Paparazzi_Center|Paparazzi Center]] interface, select the ''MJ5'' aircraft, select the ''sim'' target and ''Build'' it. Then ''Execute'' the ''Simulation'' session.

If ('''and only if''') you want to directly launch some Paparazzi agents (the ''Tools'' of the [[Paparazzi_Center|Paparazzi Center]]), 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|/home/your_username/.bashrc|
export PAPARAZZI_HOME<nowiki>=</nowiki>''your paparazzi3 directory''
export PAPARAZZI_SRC<nowiki>=</nowiki>''your paparazzi3 directory''
}}
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:
export PAPARAZZI_HOME=`pwd`;export PAPARAZZI_SRC=`pwd`
Verify that your variables are set correctly with the following command:
env | grep PAPARAZZI
which should return the following:
PAPARAZZI_HOME<nowiki>=</nowiki>''your paparazzi3 directory''
PAPARAZZI_SRC<nowiki>=</nowiki>''your paparazzi3 directory''

== Setting access rights for USB download ==

This may be required to flash the Paparazzi-boards directly thru USB. For flashing details, see [[Compiling]].

Default linux rights may not allow standard (non root) users to directly access the USB bus. You will need to make yourself a member of the plugdev "group" and then create a "rule", associated with that "group". <br>
Make yourself a member of the ''plugdev'' group:

sudo adduser <your login> plugdev

Logout and login again. Then add the appropriate rule (available ine fhe file ''10-paparazzi.rules'') to the USB handler. Simply copy as root <tt>$PAPARAZZI_HOME/conf/system/udev/rules/10-paparazzi.rules</tt> to <tt>/etc/udev/rules.d/</tt>

sudo cp $PAPARAZZI_HOME/conf/system/udev/rules/10-paparazzi.rules /etc/udev/rules.d/

== Software Updates ==
Paparazzi is a very rapidly evolving project and as such, you will find that variables and functions are frequently added, changed, or removed. 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. Your airframe file will not be updated by the CVS system and therefore any new or modified variable names will need to be added manually. The compiler will usually identify the problem variables at which point you can look at some of the most recent airframe files on the CVS to find the proper syntax. See the [[Compiling]] page for more help if needed.
<br>
That said, keeping your software up to date is easy with the CVS system. The system will compare all source code files with the server and update any that are needed, automatically merging any minor changes that you have incorporated along the way.

To download and automatically merge any updated source files, run the following command from your Paparazzi directory
cvs update -d
where the <tt>-d</tt> is needed to get any new directories.

After any CVS update or source code modification the code can be recompiled from ''your paparazzi3 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 deleted all compiled files and recompile from scratch with the following commands:

make clean
make

See the [[Compiling]] page for more info.

Users making changes to their code structure may prefer to have more control over the updating and merging process and may wish to install and use '''tkcvs''' instead which provides highlighted comparisons of any files that differ between your code and the CVS server and allows for a file by file update.

To update your Linux distribution as well as any dependencies of Paparazzi (seldom necessary), run the following as root:
sudo apt-get update
sudo apt-get upgrade

== LiveCd ==

The LiveCD is an easy way to test Paparazzi: no installation is required and no changes are made to your computer. Simply burn the image as a boot CD and reboot! The LiveCD includes Linux and the complete paparazzi binary package (code source, tools and cross compilers). It is intended for demonstration only and not frequently updated but it contains the complete system and can store changed files on a pen drive or compressed file on your hard drive so that it can compile, flash, and operate any aircraft, albeit slowly.

The CD image and a howto on [[Using the Boot CD]] is available from the [[Downloads|Downloads]] page.

The Paparazzi demo is launchable on the Live CD from the Paparazzi icon.

Knoppix allows for all the user data to be saved on a hard disk partition (most file systems are supported) or on a removable device (typically a USB pendrive). Note that this action is not destructive: the user data tree is compressed and stored on your file system as a single file (<tt>knoppix.img</tt>).
* From the Knoppix menu (second from bottom left), choose '''Configure''', '''Create a persistent KNOPPIX disk image'''
* Choose your media (be sure to connect your USB pendrive before booting!)
* Choose if you want an encrypted filesystem (to protect your flight plan designed for the next MAV competition :-) )
* Choose the size of your home directory (100Mb is recommended)
On the next reboot, this saved state will be automatically located and loaded.

Using this persistent feature, the Paparazzix Live CD can really be used to configure, simulate and fly an aircraft with the Paparazzi system.

The Live CD can also be used to install a Debian system on the hard disk, using the <tt>knoppix-installer</tt> command. Be sure to backup the hard disk before trying ...

[[Image:Lightscribe_CD_Cover_1.JPG|thumb|320px|LightScribe CD Cover]] A LiveCD needs some looks... In color or in LightScribe format, your CD will always look cool.
* Get the PDF version for download here [http://paparazzi.enac.fr/wiki_images/Lightscribe_CD_Cover_1.pdf LightScribe CD Cover 1].

* The LightScribe version is in Nero Cover Design format (.ncd) and it's here for download [http://paparazzi.enac.fr/wiki_images/Lightscribe_CD_Cover_1.zip LightScribe CD Cover 1]

* Better is ofcourse to use it on an OpenSource OS, some Linux software to be found here: [http://www.lightscribe.com/downloadSection/linux/index.aspx?id=815]

Installation/Linux

2008-12-01T22:59:50Z

Rcbrother: /* Installation from the Command Line */

Precompiled binaries can be downloaded and executed with the ''paparazzi-bin'' package but to maintain the power and flexibility of open-source code, most operations within Paparazzi involve recompilation of autopilot and/or ground station code. Therefore the typical installation requires all of the necessary C and OCaml compilers as well as some XML and [http://www.tls.cena.fr/products/ivy/ Ivy] handlers. These tools are provided by the ''paparazzi-dev'' package.

The Paparazzi sources are hosted by [http://savannah.nongnu.org/cvs/?group=paparazzi Savannah].

The Paparazzi packages are hosted at the [http://www.recherche.enac.fr/paparazzi/debian ENAC repository].

== Installation on Debian based distributions ==

Paparazzi is packaged for Debian as well as all of its dependencies. The [http://www.recherche.enac.fr/paparazzi/debian repository] hosted at ENAC holds their latest version.

=== Installation from the Command Line===
Just add the following lines to your repository list (<b>/etc/apt/sources.list</b>) and then
uncomment the line relevant to your operating system (e.g. one of etch, gutsy or hardy):

{{Box Code|/etc/apt/sources.list|
# Uncomment just _one_ of the following lines - depending on your OS version
# deb <nowiki>http://paparazzi.enac.fr/debian</nowiki> etch main
# deb <nowiki>http://paparazzi.enac.fr/debian</nowiki> lenny main
# deb <nowiki>http://paparazzi.enac.fr/ubuntu</nowiki> gutsy main
# deb <nowiki>http://paparazzi.enac.fr/ubuntu</nowiki> hardy main
# deb <nowiki>http://paparazzi.enac.fr/ubuntu</nowiki> intrepid main
}}

Note: It is not recommended to install both <tt>paparazzi-bin</tt> <b>and</b> <tt>paparazzi-dev</tt>.

Then, update your sources and '''either''' install the precompiled <b>bin</b>aries
sudo apt-get update
sudo apt-get install paparazzi-bin
<b>or</b> the dependencies needed for recompiling from the source (<b>dev</b>), and the cross-compiler (<b>arm7</b>) :
sudo apt-get update
sudo apt-get install paparazzi-dev
sudo apt-get install paparazzi-arm7

As stated before it is not recommended to install both <tt>paparazzi-bin</tt> <b>and</b> <tt>paparazzi-dev</tt>. While the <b>bin</b> package is self-contained and should be sufficient for users who do not want to patch the code, the <b>dev</b> meta-package provides only the tools to compile the source code which must be separately downloaded, from an archive or the CVS repository.

==== Optional/Obsolete Packages ====
Users of older AVR based boards will also need the paparazzi-avr package.

==== Extra for Ubuntu ====

The Braille TTY driver interferes with FTDI USB Serial adapters and should be removed:

sudo apt-get remove brltty

=== Installation thru Synaptic Package Manager ===
* Launch ''Synaptic Package Manager'' (''Applications/System'' Tools Menu)
* In '''Settings/Repositories''', add a new repository on URI = '''<nowiki>http://paparazzi.enac.fr/debian</nowiki>''', Distribution = '''etch''', Section = '''main''' . For Ubuntu, replace '''debian''' by '''ubuntu''' and '''etch''' by '''gutsy''' (or '''hardy''')
* Search for <tt>paparazzi-bin</tt>, <tt>paparazzi-dev</tt>, and <tt>paparazzi-arm7</tt> packages (use the ''Search'' button)
* Mark them for installation (right-click on package names)
* Left-click on ''Apply''

== Manual Installation of Individual Packages ==
Users of other Linux flavors or anyone needing manual control of each individual package can install them independently. The list of dependencies of the Debian package is located in the [http://cvs.savannah.gnu.org/viewvc/paparazzi/paparazzi3/debian/control.etch?revision=1.16&view=markup <tt> debian/control.etch</tt>] file and may help users of other distributions.

The binary packages and some corresponding source tarballs can be downloaded from

http://paparazzi.enac.fr/debian/dists/etch/main/binary-i386/

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

For Fedora (Core8) users, you can install the following packages from standard repository:
* ocaml.i386
* ocaml-camlimages-devel.i386
* ocaml-lablgtk-devel.i386
* ocaml-xml-light-devel.i386
* boa.i386
* libgnomecanvas-devel.i386
* libusb-devel.i386
* pcre-devel.i386
* arm-gp2x-linux-gcc.i386
* arm-gp2x-linux-binutils.i386
* glade2.i386
* and gcc, make, cvs, gnuplot, imagemagik...

Then you need [http://packages.debian.org/unstable/source/alien alien] tool to convert packages from the paparazzi repository:
* ivy-c
* ivy-c-dev
* ivy-ocaml (WARNING: debian and fedora have different path for ocaml (/usr/lib/ocaml/<version> vs. /usr/lib/ocaml), so you need to move by hand the files in /usr/lib/ocaml/<version> to /usr/lib/ocaml)
* lpc21isp

== Installing the Source Code (not needed with paparazzi-bin) ==
After the <tt>paparazzi-dev</tt> package is installed the complete source code should be downloaded from the CVS repository. See the [http://savannah.nongnu.org/cvs/?group=paparazzi project page] at Savannah for more details. From the directory of your choice type:
cvs -z3 -d:pserver:anonymous@cvs.savannah.nongnu.org:/sources/paparazzi co paparazzi3
This will download all of the code and install it into <tt>paparazzi3/</tt>

If you cannot use the CVS install, dayly updated tarballs can also be fetched from the [[Downloads|Downloads]] page.

== Launching the Software ==

If you are using the <tt>paparazzi-bin</tt> package or the Live-CD, just launch the <tt>paparazzi</tt> binary application and you will be guided through the installation of your personal configuration files.

If you are using the source code, the first step is to compile it. From the <tt>paparazzi3</tt> directory (<tt>cd paparazzi3</tt>), run

make

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

./paparazzi

From the [[Paparazzi_Center|Paparazzi Center]] interface, select the ''MJ5'' aircraft, select the ''sim'' target and ''Build'' it. Then ''Execute'' the ''Simulation'' session.

If ('''and only if''') you want to directly launch some Paparazzi agents (the ''Tools'' of the [[Paparazzi_Center|Paparazzi Center]]), 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|/home/your_username/.bashrc|
export PAPARAZZI_HOME<nowiki>=</nowiki>''your paparazzi3 directory''
export PAPARAZZI_SRC<nowiki>=</nowiki>''your paparazzi3 directory''
}}
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:
export PAPARAZZI_HOME=`pwd`;export PAPARAZZI_SRC=`pwd`
Verify that your variables are set correctly with the following command:
env | grep PAPARAZZI
which should return the following:
PAPARAZZI_HOME<nowiki>=</nowiki>''your paparazzi3 directory''
PAPARAZZI_SRC<nowiki>=</nowiki>''your paparazzi3 directory''

== Setting access rights for USB download ==

This may be required to flash the Paparazzi-boards directly thru USB. For flashing details, see [[Compiling]].

Default linux rights may not allow standard (non root) users to directly access the USB bus. You will need to make yourself a member of the plugdev "group" and then create a "rule", associated with that "group". <br>
Make yourself a member of the ''plugdev'' group:

sudo adduser <your login> plugdev

Logout and login again. Then add the appropriate rule (available ine fhe file ''10-paparazzi.rules'') to the USB handler. Simply copy as root <tt>$PAPARAZZI_HOME/conf/system/udev/rules/10-paparazzi.rules</tt> to <tt>/etc/udev/rules.d/</tt>

sudo cp $PAPARAZZI_HOME/conf/system/udev/rules/10-paparazzi.rules /etc/udev/rules.d/

== Software Updates ==
Paparazzi is a very rapidly evolving project and as such, you will find that variables and functions are frequently added, changed, or removed. 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. Your airframe file will not be updated by the CVS system and therefore any new or modified variable names will need to be added manually. The compiler will usually identify the problem variables at which point you can look at some of the most recent airframe files on the CVS to find the proper syntax. See the [[Compiling]] page for more help if needed.
<br>
That said, keeping your software up to date is easy with the CVS system. The system will compare all source code files with the server and update any that are needed, automatically merging any minor changes that you have incorporated along the way.

To download and automatically merge any updated source files, run the following command from your Paparazzi directory
cvs update -d
where the <tt>-d</tt> is needed to get any new directories.

After any CVS update or source code modification the code can be recompiled from ''your paparazzi3 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 deleted all compiled files and recompile from scratch with the following commands:

make clean
make

See the [[Compiling]] page for more info.

Users making changes to their code structure may prefer to have more control over the updating and merging process and may wish to install and use '''tkcvs''' instead which provides highlighted comparisons of any files that differ between your code and the CVS server and allows for a file by file update.

To update your Linux distribution as well as any dependencies of Paparazzi (seldom necessary), run the following as root:
apt-get update
apt get upgrade

== LiveCd ==

The LiveCD is an easy way to test Paparazzi: no installation is required and no changes are made to your computer. Simply burn the image as a boot CD and reboot! The LiveCD includes Linux and the complete paparazzi binary package (code source, tools and cross compilers). It is intended for demonstration only and not frequently updated but it contains the complete system and can store changed files on a pen drive or compressed file on your hard drive so that it can compile, flash, and operate any aircraft, albeit slowly.

The CD image and a howto on [[Using the Boot CD]] is available from the [[Downloads|Downloads]] page.

The Paparazzi demo is launchable on the Live CD from the Paparazzi icon.

Knoppix allows for all the user data to be saved on a hard disk partition (most file systems are supported) or on a removable device (typically a USB pendrive). Note that this action is not destructive: the user data tree is compressed and stored on your file system as a single file (<tt>knoppix.img</tt>).
* From the Knoppix menu (second from bottom left), choose '''Configure''', '''Create a persistent KNOPPIX disk image'''
* Choose your media (be sure to connect your USB pendrive before booting!)
* Choose if you want an encrypted filesystem (to protect your flight plan designed for the next MAV competition :-) )
* Choose the size of your home directory (100Mb is recommended)
On the next reboot, this saved state will be automatically located and loaded.

Using this persistent feature, the Paparazzix Live CD can really be used to configure, simulate and fly an aircraft with the Paparazzi system.

The Live CD can also be used to install a Debian system on the hard disk, using the <tt>knoppix-installer</tt> command. Be sure to backup the hard disk before trying ...

[[Image:Lightscribe_CD_Cover_1.JPG|thumb|320px|LightScribe CD Cover]] A LiveCD needs some looks... In color or in LightScribe format, your CD will always look cool.
* Get the PDF version for download here [http://paparazzi.enac.fr/wiki_images/Lightscribe_CD_Cover_1.pdf LightScribe CD Cover 1].

* The LightScribe version is in Nero Cover Design format (.ncd) and it's here for download [http://paparazzi.enac.fr/wiki_images/Lightscribe_CD_Cover_1.zip LightScribe CD Cover 1]

* Better is ofcourse to use it on an OpenSource OS, some Linux software to be found here: [http://www.lightscribe.com/downloadSection/linux/index.aspx?id=815]

Sensors/GPS

2008-09-28T12:21:30Z

Rcbrother: /* LEA-5H */

{| align=right
|-
| __TOC__
|}

==Overview==
[[Image:U-blox_color_warm_60.gif|100px]]

Paparazzi autopilots are designed around the popular [http://www.u-blox.com u-blox] brand of receivers.

*Features:
**Small size
**Excellent performance
**4Hz position update rate

The '''[[Tiny]]''' features an onboard LEA series GPS receiver and patch antenna, while '''[[Classix]]''' and '''[[Previous_Autopilots|AVR-based]]''' boards require an external receiver+antenna such as the [[#Paparazzi_Stand-alone_GPS_Receivers|Paparazzi GPS]] or [[#u-Blox_SAM-LS_GPS_Smart_Antenna|SAM-LS]]. Please note that the receivers must be configured (prior to use with the autopilot) as indicated below. Both modules have proven reliable and robust.

{|align = center
|-
|[[Image:Lea big.jpg|200px|thumb|center|u-blox LEA GPS Receiver]]
|[[Image:Ublox_SAM-LS.jpg|200px|thumb|center|u-blox SAM-LS GPS receiver (w/built-in Smart Antenna)]]
|}

'''Note:''' The proprietary UBX protocol is used as it offers more information and efficiency than the universal NMEA protocol. The protocol is parsed in <tt>sw/airborne/gps_ubx.c</tt>. Other GPS brands would require a similar parsing file to be written for NMEA or other proprietary protocols.

==GPS Receivers==

===u-Blox LEA Series Receivers===
[[Image:Lea big.jpg|100px|thumb|right|u-blox LEA]]
The '''[[Tiny]]''' and Paparazzi stand-alone GPS currently use the [http://www.u-blox.com/products/lea_4p.html u-blox LEA-4P] featuring [http://www.u-blox.com/technology/antaris4/index.html Antaris-4] technology and uBlox's more efficient UBX binary protocol. This module is a surface mount package which is soldered directly onto the PCB (Tiny or Paparazzi GPS). An external battery backup (capacitor) is used to enable the GPS to retain data while powered off for significantly faster signal re-aquisition. Any of the LEA-4x series receivers can be used including the less expensive LEA-4A and 4S models as the special boot configuration code required for these models is already written.

*4Hz Position update rate
*Supports active or passive antennas
*Supports [http://en.wikipedia.org/wiki/DGPS DGPS], [http://en.wikipedia.org/wiki/WAAS WAAS], [http://en.wikipedia.org/wiki/EGNOS EGNOS], and [http://en.wikipedia.org/wiki/MSAS MSAS]
*Low position [http://paparazzi.enac.fr/wiki_images/Gps_rx_noise.pdf noise] figure
[[Image:TINY_1.3_MCU_BOTTOM.JPG|thumb|center|250px|LEA-4P installed on the Tiny]]
<br style="clear:both">

===Paparazzi Stand-alone GPS Receivers===
There are currently two (LEA-based) stand-alone, GPS receiver + antenna, prototype boards in development; the first one is based on the Sangshin 13mm patch antenna.<br>
[[Image:Ppzgps13_800.jpg|100px|thumb|right]]
The second is based on the Sarantel helix antenna. Drawings for both are available from the [http://cvs.savannah.gnu.org/viewcvs/paparazzi/paparazzi3/hw/ CVS]
Another alternative is the NAVILOCK NL-507TTL u-blox TTL Modul 60416 which is availible for 28€ (amazon.de).

===u-Blox SAM-LS GPS Smart Antenna===
[[Image:Ublox_SAM-LS.jpg|100px|thumb|right|u-blox SAM-LS]]
The '''[[Classix]]''' and '''[[Previous_Autopilots|AVR-based]]''' boards use a stand alone module from u-blox called the SAM-LS. It is an integrated TIM-LP module with a ceramic patch antenna. This processor also runs on 4hz and must be configured to use the UBX protocol. With battery backup (3V watch battery) they show hot starts of around a couple seconds. The LEA-LA processor weighs a couple grams and the complete the SAM-LS module with antenna and shielding weighs about 20grams.

'''Note:''' Effective 12/2006 u-blox has begun to phase out the SAM-LS product. No replacement will be offered.

====Connecting external receivers to Classix, 1.2.1, Lite, and RoboStix boards====

The u-blox receivers require 3.3v power and all current models have 5V tolerant data lines. The best way to connect to the SAM-LS is to remove the bottom case and solder the 4 wires directly to the TIM-LL module (GND (pin 1) ,VCC (pin 2),TX (Pin 5),RX (pin 4)) check the TIM-LL datasheet for pinout diagrams. The Classix and Lite boards feature a 3.3V regulator to power the GPS.

===Sourcing from u-blox===

u-blox keeps tight control over the distribution of their products. They must be obtained DIRECTLY from their own reseller offices. These offices may not be available in your area, for example Canada does not have a reseller. Sample quantities can be obtained from uBlox but overnight or 2 day shipping is required which drives the cost up considerably. While it is a large hassle obtaining these devices, it is undoubtedly worth it.

Talking with ublox sale for two years, Confirmed, that Order is possiable Directly from ublox, by knowing what project it was for & how was it to be use. After long reply waiting time, the answer was: - YES, but at least 2K-3K in volume, otherwise they're not interested. Like to share the order ? It is 500pcs/Roll.

===Other potential source of u-blox GPS===

There seems to be a few alternative source of u-blox GPS out there. They are considerably cheaper then the samples u-blox offers (at least in america). We didn't buy from these sources yet. Do not take this as a recommandation, we do not know the level of service they offer, etc.

If you do order from any of them, please update this page with your feedback.

Here's a few link worth exploring:
*http://www.rfdesign.co.za/pages/5645456/Products/GPS-Products/Antaris-4-Modules.asp
*http://www.comet.srl.ro/shop/info.html?ID=6195 ( Link error )
*http://www.expedienttech.com/product.htm ( Singapore )
*http://shop.halfbase.com/index.php/cPath/22?osCsid=414472d5a544b080f9ae153fdc323798 ( B2B- min.10pcs @ $38 )

===Standalone GPS Module from CVS===
The Version 1 (V1) BOM is here.. Please post any pics you might have and check this for accuracy<br>
[http://paparazzi.enac.fr/wiki_images/Gps_13_BOM.xls V1 BOM]<br>
[http://paparazzi.enac.fr/wiki_images/TinygpsBOM.txt Eagle Parts List Output]<br>

[[Image:LEA5HExternalModulePinout.jpg|250px|thumb|right|LEA-5H Full Board Pinout]]

If this needs fixing don't be shy, fix away.

==GPS configuration using U-Center==

[[Image:U-center_screencap.jpg|thumb|u-center configuration software]]
[http://www.u-blox.com/products/u_center.html U-Center] is a very comprehensive freeware program intended for the configuration and evaluation of u-blox receivers.
* [http://www.u-blox.com/products/u_center.html Download u-center]

* Note: You must [[Compiling#USB_flashing|install the UART tunnel]] to enable direct access to the built-in GPS on the [[Tiny|Tiny]].
* Note: You can run u-center on Linux by installing "wine" ([http://www.winehq.org/site/download-deb Installation of Wine]) and setting up com1 as /dev/ttyUSB0 See Info on wine for "dosdevices" setup. Just download the u-setup.exe and run it with wine, follow prompts. This has been tested with Ubuntu7.10 and Ubuntu 8.04 so far.
* Note: You will need a driver for your FTDI cable if you run u-center on Windows, which can be found [http://www.ftdichip.com/Drivers/D2XX.htm here].
The u-blox and Tiny UARTs both operate at 3.3V TTL levels and are 5V TTL tolerant. You must use a level shifter such as the common MAX232 to connect these devices to a standard PC serial port. The easiest and most recommended method is to connect to a USB port instead of serial with the $20 [http://www.ftdichip.com/Products/EvaluationKits/TTL-232R.htm FTDI USB-TTL converter cable] available from Digikey, Mouser, or direct from FTDI. Other similar converters are available from [http://www.pololu.com/products/pololu/0391/ pololu] / [http://www.sparkfun.com/commerce/product_info.php?products_id=199 sparkfun] or [http://shop.halfbase.com/product_info.php/products_id/54 Halfbase]. A stand-alone GPS such as the SAM-LS will require clean 3.3V/50mA power and a common ground with the TTL converter.

* U-blox occasionally releases firmware updates. Log on to the u-blox website using ''paparazzi'' for username & password to view or download the latest firmware images. There have 'never' been any updates released for the Antaris-4 series used in the Tiny.

Start U-center and choose your com port from the pull down list under the connect button near the top left corner of the window. Choose your baudrate from the pull down box to the right of the connect button or select the auto-baud button to the right of that. U-blox default is 9600 baud. This must be changed to 19200 or higher to accomodate the 4Hz update rate.
<br>[[Image:U-center_buttons.jpg|connect, baud, and autobaud buttons]]
<br style="clear:both">

===Uploading the Configuration File===
Download the appropriate configuration file below and use u-center to load in onto your receiver. Under the ''Tools'' menu, choose ''GPS configuration''. Be sure the box 'Store configuration into BBR/Flash' is checked and hit the button ''File>>GPS''. A few errors and retries are normal, but a significant number of errors may indicate a poor connection and the software will notify you if it is unable to send all the data successfully.
* [[Media:Tiny_LEA-4P-v6.zip|LEA-4P]]
* [[Media:Tim-LL-V5.zip|TIM-LL]]
* [http://paparazzi.enac.fr/wiki_images/Tiny_LEA-5H-v5.zip LEA-5H (For Use w/ Firmware V5 ONLY!)]

===Manual Configuration===
If you prefer to setup your receiver manually or have a model not listed above, here are instructions to configure your receiver in u-center.
Open the message window (menu View->messages view) to start the configuration process by changing the following settings:

====LEA-4P====

1. Right Click on the '''NMEA''' Icon and choose '''disable child'''
2. Choose UBX->CFG->NAV2(Navigation 2) - set it to use '''Airborne 4G''' (tells the Kalman filter to expect significant changes in direction)
3. UBX->CFG->PRT - set '''USART1''' to '''38400bps''' (must match the value in your [[Airframe_Configuration#Hardware_definitions_-_Makefile|Airframe file]])
4. Change the baudrate of U-Center to 38400bps if the connection is lost at this point
5. UBX->CFG->RXM(Receiver Manager) - change '''GPS Mode''' to '''3 - Auto''' (Enabling faster bootup only if signal levels are very good)
6. UBX->CFG->RATE(Rates) - change the '''Measurement Period''' to '''250ms''' (4 Hz position updates)
7. UBX->CFG->SBAS : '''Disable''' (SBAS appears to cause occasional severe altitude calcuation errors)
8. UBX->NAV (not UBX->CFG->NAV): double click on '''POSUTM, SOL, STATUS, SVINFO, VELNED.''' They should change from grey to black
9. UBX->CFG->CFG : '''save current config''', click '''"send"''' in the lower left corner to permanently save these settings to the receiver

====LEA-5H====

1. Right Click on the '''NMEA''' Text on top of the tree and choose '''disable child messages'''
2. Choose UBX->CFG->NAV5(Navigation 5) - set it to use '''Airborne 8 <4G'''. This tells the Kalman filter to expect significant changes in direction.
Note that this setting is only good for faster moving airplanes. For a fixed position hovering heli, 'pedestrian' setting is better
3. UBX->CFG->PRT - set '''USART1''' to '''38400bps''' (must match the value in your [[Airframe_Configuration#Hardware_definitions_-_Makefile|Airframe file]])
4. Change the baudrate of U-Center to 38400bps if the connection is lost at this point
5. UBX->CFG->RATE(Rates) - change the '''Measurement Period''' to '''250ms''' This gives a 4 Hz position update since 4 x 250ms is one second.
6. UBX->CFG->SBAS : '''Disable''' (SBAS appears to cause occasional severe altitude calcuation errors)
7. UBX->NAV (not UBX->CFG->NAV): double click on '''POSLLH, SOL, STATUS, SVINFO, VELNED.''' They should change from grey to black
(add the flag -DGPS_USE_LATLONG in your [[Airframe_Configuration#Hardware_definitions_-_Makefile|Airframe file]]) also make sure you set tiny_2_1_1.h if you have the latest boards Tiny/TinyWOG)
8. UBX->CFG->CFG : '''save current config''', click '''"send"''' in the lower left corner to permanently save these settings to the receiver

* Cycle the power and verify that the new configuration was saved
* To reset the receiver to the factory defaults go to ''UBX->CFG->CFG'', select 'Revert to default configuration', and click ''Send'' at the bottom left corner. To permanently save these values choose 'Save current configuration' and click ''Send''.
* To backup the configuration to a file on your PC: under the tools menu, choose GPS configuration, then click GPS>>file. This file can be re-loaded in a similar manner to configure additional identical receivers. Be sure the box 'Store configuration into BBR/Flash' is checked when reloading a configuration file to make the changes permanent.
* To update the firmware on a LEA-5H get u-center >= 5.03, revert the GPS receiver to the default configuration, get an appropriate image from u-blox (fitting your receivers serial number), find the flash identification flash.txt file in the u-center install directory and be prepared to wait a long time.

#NOTE: If you have a Tiny with LEA-5H module you must use u-center and manually setup the parameters as shown above (at least switch to 38400 baud manually before transferring the configuration file).
#NOTE: POSUTM is not available on LEA-5H. Instead, use POSLLH. Additionally, add the flag -DGPS_USE_LATLONG in the makefile section of the airframe xml file.

===Reset to Default Settings===
The GPS module can be reset to its original default settings by pulling BOOT_INT high(3.3V) during a power cycle ([http://www.u-blox.com/customersupport/gps.g4/ANTARIS4_Modules_SIM(GPS.G4-MS4-05007).pdf Antaris Manual, p. 122]). It may be required after a wrong firmware upgrade or a bad configuration change.

===DGPS (Differential GPS)===
Differential GPS is any method of improving GPS accuracy by comparing the GPS-indicated position of a nearby location to the known value and transmitting any error to the mobile unit. DGPS was originally created as a means of bypassing the deliberately introduced inaccuracies in civilian GPS signals. The original method used low frequency ground radios to relay correction data to the mobile unit and is still used today at airports, shipping ports, and even individual farms. Satellite Based Augmentation System (SBAS) is a modern form of DGPS where the ground stations relay correction data to a GEO-Stationary satellite, which then relays it to the mobile unit on standard GPS frequencies eliminating the need for a separate radio reciever. SBAS is currently available in 3 regions, [http://www.environmental-studies.de/Precision_Farming/EGNOS_WAAS__E/3E.html WAAS, EGNOS, and MSAS] though only WAAS is officially operational. U-blox receivers support all common varieties of DGPS [http://www.u-blox.com/customersupport/gps.g3/ENGOS_Issues(GPS.G3-CS-04009).pdf read the u-blox SBAS application note].
* It is important to note that DGPS methods only improve the ''accuracy'' of the position calculation, not the ''precision''. Since Paparazzi navigation is typically performed relative to the power-on location, any static error that could be corrected with DGPS is irrelevant.

====WAAS issues====
WAAS has been officially operational and "suitable for safety-of-life applications" since 2003. The default setting of all u-blox receivers ignores WAAS correction data and only uses the WAAS satellites for regular navigation like any other satellite. U-blox recommends further limiting this setting to exclude any stray EGNOS/MSAS satellites in North America, and completely disabling all SBAS functions for use outside North America. In 2006 one formerly reliable Paparazzi aircraft began having great GPS problems and displaying very erratic altitude calculations, disabling WAAS immediately resolved the issue and this phenomenon was recreated several times for verification. Turns out a new WAAS satellite was being added to the system and the others were being moved that week for better distribution. Our advice is to completely disable WAAS.

====EGNOS issues====
EGNOS is officially in "testing mode" and no claims of reliability are made. The [http://www.u-blox.com/customersupport/faq_antaris u-blox FAQ] states the following:
* "Do you see issues with EGNOS?"
*:"Yes. Although the data transmitted by the EGNOS satellites are usually good and valuable (e.g. during the solar storms in autumn 2003), they can sometimes be very unreliable, for example when system tests are performed. As an example, u-blox has noticed erroneous range information (up to three hundred kilometers) on various EGNOS satellite over the last few months [2006]."

===Further Reading===

The u-blox [http://www.u-blox.com/customersupport/antaris4_doc.html System Integration Manual] covers a lot of GPS theory as well as product specific topics.

== Antenna options for the Tiny and Paparazzi GPS units ==

The '''[[Tiny|Tiny 1.1]]''' features a 28mm square ground plane intended to be centered below the [[#Sangshin_13mm_Patch|Sangshin 13mm patch antenna]]. Much better performance has been seen with the 18mm antennas and an augmented ground plane. The ground plane is a critical part of the antenna affecting not only the gain and polarization characteristics but also the center frequency of the system. Users are advised to expand the ground plane to approximately 36mm square, centered on the ceramic portion of the antenna (not the pin). This can be done with copper foil soldered to the vias of the existing ground plane.
[[image:gps_antenna_comparison.jpg|thumb|500px|left|SAM-LS 25mm / Emtac 20mm / Emtac 18mm / Sangshin 18mm / Sangshin 13mm / Sarantel P2]]
<br style="clear:both">

=== Sangshin 18mm Patch ===
[[image:Sangshin_18mm.jpg|thumb|Sangshin 18mm x 4mm 1580Mhz]]
The Sangshin KSA-ST1580MS18 antenna has proven to offer the best performance of the currently available options. These are available from any Sanshin distributor such as [http://www.rfmw.com rfmw] ([http://www.rfmw.com/PortalProductDetail.aspx?ProdId=232436&fmt=1 here]) and cost approximately $6.50/ea. in small quantities.

<br style="clear:both">

=== EMTAC 18mm Patch ===
[[image:Emtac_18mm.jpg|thumb|Emtac 18mm x 4mm 1580Mhz]]
Offering identical performance to the Sangshin in a less attractive package is the Emtac 18mm antenna. The part number for the standard 1580MHz 18x18x4mm is ANA1580T18D40 and is not listed on their website. Other frequencies are available on a special order basis and the 1584Mhz has proven to outperform all other frequencies when used with a 36mm ground plane and no radome. The use of a radome (any material covering the antenna) or a larger ground plane should theoretically favor even higher frequencies.

'''Availability'''

* [http://www.transplantgps.com/modules.html TransplantGPS] in MN, USA. The 1580Mhz models are usually available at a cost of $3.55ea but there may be a minimum order requirement of ~$50 USD.
* [http://www.onefastdaddy.com/catalog/product_info.php?products_id=43 PPZUAV] ~$10.00 USD (no min. order requirement)
<br style="clear:both">

=== Sangshin 13mm Patch ===

[[image:Sangshin_13mm_onboard.jpg|thumb|Sangshin 13mm x 4mm 1580Mhz]]
Part of interest: '''[http://www.sangshinec.com/eng/patch_spec.htm KSA-ST1580MS13]'''

The Tiny 0.99 (not 0.9) and 1.1 were designed around this antenna but users are advised to install 18mm units for better performance.

Size: 13 x 13 mm<br/>
Center Frequency: 1580 MHz<br/>
Bandwidth: 5 MHz<br/>
@Fo: -15 dB<br/>
GAIN (dBi): 0 dBi<br/>
Ground Plane: 50 x 50 mm<br/>

'''Available From'''

[http://www.systroninc.com/ Systronic INC.] - Alberta, Canada
<br style="clear:both">

=== Emtac 20mm Patch ===

[[image:Salvaged_20mm_onboard.jpg|thumb|Emtac 20mm x 4mm]]
The Tiny 0.9 was designed around this 1583Mhz antenna and performed extremely well. Emtac has replaced this with an 18mm model that they claim offers even better performance.

* Obsolete
<br style="clear:both">

=== Sarantel GeoHelix-P2 ===

[[image:Geohelix-p2.jpg|thumb|Sarantel Geohelix P-2 1575Mhz]]

This antenna is popular among UAV designers due to it's natural rejection of other radio frequencies such as those originating from the modem or video system as well as it's improved rejection of signals reflected from the ground. U-blox recommends this antenna and features it in their [http://www.u-blox.com/news/sarantel.html reference design]. Frequency and polarization are not dependent upon ground plane geometry so this antenna is sold only in the true GPS frequency of 1575Mhz.
The geometry makes this antenna very inconvenient to mount, especially in an airplane. Some very non-scientific testing has been done with one of these antennas connected to a Tiny with a short length of 50 Ohm coax above a 120mm square of ungrounded aluminum foil and performance was adequate. The helical design should theoretically outperform a patch in the air, but not on the ground, so any organized comparison will be difficult. Possibly the most important aspect of this antenna is it's natural RFI filtering, which should be evaluated further.

* [http://www.sarantel.com/products/geohelix-p2 GeoHelix-P2] Passive GPS Antenna [[http://www.sarantel.com/downloads/specifications/geohelix-p2.pdf datasheet]]

'''Availability'''

* Sarantel @ cost of approx $18 USD each (active versions available for ~$40)
<br style="clear:both">
* [http://www.onefastdaddy.com/catalog/product_info.php?products_id=40&osCsid=709e839698120c5cd324072b77d67cc1 PPZUAV]

Sensors/GPS

2008-09-19T10:25:20Z

Rcbrother: /* LEA-5H */

{| align=right
|-
| __TOC__
|}

==Overview==
[[Image:U-blox_color_warm_60.gif|100px]]

Paparazzi autopilots are designed around the popular [http://www.u-blox.com u-blox] brand of receivers.

*Features:
**Small size
**Excellent performance
**4Hz position update rate

The '''[[Tiny]]''' features an onboard LEA series GPS receiver and patch antenna, while '''[[Classix]]''' and '''[[Previous_Autopilots|AVR-based]]''' boards require an external receiver+antenna such as the [[#Paparazzi_Stand-alone_GPS_Receivers|Paparazzi GPS]] or [[#u-Blox_SAM-LS_GPS_Smart_Antenna|SAM-LS]]. Please note that the receivers must be configured (prior to use with the autopilot) as indicated below. Both modules have proven reliable and robust.

{|align = center
|-
|[[Image:Lea big.jpg|200px|thumb|center|u-blox LEA GPS Receiver]]
|[[Image:Ublox_SAM-LS.jpg|200px|thumb|center|u-blox SAM-LS GPS receiver (w/built-in Smart Antenna)]]
|}

'''Note:''' The proprietary UBX protocol is used as it offers more information and efficiency than the universal NMEA protocol. The protocol is parsed in <tt>sw/airborne/gps_ubx.c</tt>. Other GPS brands would require a similar parsing file to be written for NMEA or other proprietary protocols.

==GPS Receivers==

===u-Blox LEA Series Receivers===
[[Image:Lea big.jpg|100px|thumb|right|u-blox LEA]]
The '''[[Tiny]]''' and Paparazzi stand-alone GPS currently use the [http://www.u-blox.com/products/lea_4p.html u-blox LEA-4P] featuring [http://www.u-blox.com/technology/antaris4/index.html Antaris-4] technology and uBlox's more efficient UBX binary protocol. This module is a surface mount package which is soldered directly onto the PCB (Tiny or Paparazzi GPS). An external battery backup (capacitor) is used to enable the GPS to retain data while powered off for significantly faster signal re-aquisition. Any of the LEA-4x series receivers can be used including the less expensive LEA-4A and 4S models as the special boot configuration code required for these models is already written.

*4Hz Position update rate
*Supports active or passive antennas
*Supports [http://en.wikipedia.org/wiki/DGPS DGPS], [http://en.wikipedia.org/wiki/WAAS WAAS], [http://en.wikipedia.org/wiki/EGNOS EGNOS], and [http://en.wikipedia.org/wiki/MSAS MSAS]
*Low position [http://paparazzi.enac.fr/wiki_images/Gps_rx_noise.pdf noise] figure
[[Image:TINY_1.3_MCU_BOTTOM.JPG|thumb|center|250px|LEA-4P installed on the Tiny]]
<br style="clear:both">

===Paparazzi Stand-alone GPS Receivers===
There are currently two (LEA-based) stand-alone, GPS receiver + antenna, prototype boards in development; the first one is based on the Sangshin 13mm patch antenna. The second is based on the Sarantel helix antenna. Drawings for both are available from the [http://cvs.savannah.gnu.org/viewcvs/paparazzi/paparazzi3/hw/ CVS]
Another alternative is the NAVILOCK NL-507TTL u-blox TTL Modul 60416 which is availible for 28€ (amazon.de).

===u-Blox SAM-LS GPS Smart Antenna===
[[Image:Ublox_SAM-LS.jpg|100px|thumb|right|u-blox SAM-LS]]
The '''[[Classix]]''' and '''[[Previous_Autopilots|AVR-based]]''' boards use a stand alone module from u-blox called the SAM-LS. It is an integrated TIM-LP module with a ceramic patch antenna. This processor also runs on 4hz and must be configured to use the UBX protocol. With battery backup (3V watch battery) they show hot starts of around a couple seconds. The LEA-LA processor weighs a couple grams and the complete the SAM-LS module with antenna and shielding weighs about 20grams.

'''Note:''' Effective 12/2006 u-blox has begun to phase out the SAM-LS product. No replacement will be offered.

====Connecting external receivers to Classix, 1.2.1, Lite, and RoboStix boards====

The u-blox receivers require 3.3v power and all current models have 5V tolerant data lines. The best way to connect to the SAM-LS is to remove the bottom case and solder the 4 wires directly to the TIM-LL module (GND (pin 1) ,VCC (pin 2),TX (Pin 5),RX (pin 4)) check the TIM-LL datasheet for pinout diagrams. The Classix and Lite boards feature a 3.3V regulator to power the GPS.

===Sourcing from u-blox===

u-blox keeps tight control over the distribution of their products. They must be obtained DIRECTLY from their own reseller offices. These offices may not be available in your area, for example Canada does not have a reseller. Sample quantities can be obtained from uBlox but overnight or 2 day shipping is required which drives the cost up considerably. While it is a large hassle obtaining these devices, it is undoubtedly worth it.

Talking with ublox sale for two years, Confirmed, that Order is possiable Directly from ublox, by knowing what project it was for & how was it to be use. After long reply waiting time, the answer was: - YES, but at least 2K-3K in volume, otherwise they're not interested. Like to share the order ? It is 500pcs/Roll.

===Other potential source of u-blox GPS===

There seems to be a few alternative source of u-blox GPS out there. They are considerably cheaper then the samples u-blox offers (at least in america). We didn't buy from these sources yet. Do not take this as a recommandation, we do not know the level of service they offer, etc.

If you do order from any of them, please update this page with your feedback.

Here's a few link worth exploring:
*http://www.rfdesign.co.za/pages/5645456/Products/GPS-Products/Antaris-4-Modules.asp
*http://www.comet.srl.ro/shop/info.html?ID=6195 ( Link error )
*http://www.expedienttech.com/product.htm ( Singapore )
*http://shop.halfbase.com/index.php/cPath/22?osCsid=414472d5a544b080f9ae153fdc323798 ( B2B- min.10pcs @ $38 )

===Standalone GPS Module from CVS===
The Version 1 (V1) BOM is here.. Please post any pics you might have and check this for accuracy<br>
[http://paparazzi.enac.fr/wiki_images/Gps_13_BOM.xls V1 BOM]<br>
[http://paparazzi.enac.fr/wiki_images/TinygpsBOM.txt Eagle Parts List Output]<br>

[[Image:LEA5HExternalModulePinout.jpg|250px|thumb|right|LEA-5H Full Board Pinout]]

If this needs fixing don't be shy, fix away.

==GPS configuration using U-Center==

[[Image:U-center_screencap.jpg|thumb|u-center configuration software]]
[http://www.u-blox.com/products/u_center.html U-Center] is a very comprehensive freeware program intended for the configuration and evaluation of u-blox receivers.
* [http://www.u-blox.com/products/u_center.html Download u-center]

* Note: You must [[Compiling#USB_flashing|install the UART tunnel]] to enable direct access to the built-in GPS on the [[Tiny|Tiny]].
* Note: You can run u-center on Linux by installing "wine" ([http://www.winehq.org/site/download-deb Installation of Wine]) and setting up com1 as /dev/ttyUSB0 See Info on wine for "dosdevices" setup. Just download the u-setup.exe and run it with wine, follow prompts. This has been tested with Ubuntu7.10 and Ubuntu 8.04 so far.
* Note: You will need a driver for your FTDI cable if you run u-center on Windows, which can be found [http://www.ftdichip.com/Drivers/D2XX.htm here].
The u-blox and Tiny UARTs both operate at 3.3V TTL levels and are 5V TTL tolerant. You must use a level shifter such as the common MAX232 to connect these devices to a standard PC serial port. The easiest and most recommended method is to connect to a USB port instead of serial with the $20 [http://www.ftdichip.com/Products/EvaluationKits/TTL-232R.htm FTDI USB-TTL converter cable] available from Digikey, Mouser, or direct from FTDI. Other similar converters are available from [http://www.pololu.com/products/pololu/0391/ pololu] / [http://www.sparkfun.com/commerce/product_info.php?products_id=199 sparkfun] or [http://shop.halfbase.com/product_info.php/products_id/54 Halfbase]. A stand-alone GPS such as the SAM-LS will require clean 3.3V/50mA power and a common ground with the TTL converter.

* U-blox occasionally releases firmware updates. Log on to the u-blox website using ''paparazzi'' for username & password to view or download the latest firmware images. There have 'never' been any updates released for the Antaris-4 series used in the Tiny.

Start U-center and choose your com port from the pull down list under the connect button near the top left corner of the window. Choose your baudrate from the pull down box to the right of the connect button or select the auto-baud button to the right of that. U-blox default is 9600 baud. This must be changed to 19200 or higher to accomodate the 4Hz update rate.
<br>[[Image:U-center_buttons.jpg|connect, baud, and autobaud buttons]]
<br style="clear:both">

===Uploading the Configuration File===
Download the appropriate configuration file below and use u-center to load in onto your receiver. Under the ''Tools'' menu, choose ''GPS configuration''. Be sure the box 'Store configuration into BBR/Flash' is checked and hit the button ''File>>GPS''. A few errors and retries are normal, but a significant number of errors may indicate a poor connection and the software will notify you if it is unable to send all the data successfully.
* [[Media:Tiny_LEA-4P-v6.zip|LEA-4P]]
* [[Media:Tim-LL-V5.zip|TIM-LL]]
* [http://paparazzi.enac.fr/wiki_images/Tiny_LEA-5H-v5.zip LEA-5H (For Use w/ Firmware V5 ONLY!)]

===Manual Configuration===
If you prefer to setup your receiver manually or have a model not listed above, here are instructions to configure your receiver in u-center.
Open the message window (menu View->messages view) to start the configuration process by changing the following settings:

====LEA-4P====

1. Right Click on the '''NMEA''' Icon and choose '''disable child'''
2. Choose UBX->CFG->NAV2(Navigation 2) - set it to use '''Airborne 4G''' (tells the Kalman filter to expect significant changes in direction)
3. UBX->CFG->PRT - set '''USART1''' to '''38400bps''' (must match the value in your [[Airframe_Configuration#Hardware_definitions_-_Makefile|Airframe file]])
4. Change the baudrate of U-Center to 38400bps if the connection is lost at this point
5. UBX->CFG->RXM(Receiver Manager) - change '''GPS Mode''' to '''3 - Auto''' (Enabling faster bootup only if signal levels are very good)
6. UBX->CFG->RATE(Rates) - change the '''Measurement Period''' to '''250ms''' (4 Hz position updates)
7. UBX->CFG->SBAS : '''Disable''' (SBAS appears to cause occasional severe altitude calcuation errors)
8. UBX->NAV (not UBX->CFG->NAV): double click on '''POSUTM, SOL, STATUS, SVINFO, VELNED.''' They should change from grey to black
9. UBX->CFG->CFG : '''save current config''', click '''"send"''' in the lower left corner to permanently save these settings to the receiver

====LEA-5H====

1. Right Click on the '''NMEA''' Text on top of the tree and choose '''disable child messages'''
2. Choose UBX->CFG->NAV5(Navigation 5) - set it to use '''Airborne 8 <4G'''. This tells the Kalman filter to expect significant changes in direction. Not that this setting is only good for faster moving airplanes. For a fixed position hovering heli, 'pedestrian' setting is better
3. UBX->CFG->PRT - set '''USART1''' to '''38400bps''' (must match the value in your [[Airframe_Configuration#Hardware_definitions_-_Makefile|Airframe file]])
4. Change the baudrate of U-Center to 38400bps if the connection is lost at this point
5. UBX->CFG->RATE(Rates) - change the '''Measurement Period''' to '''250ms''' This gives a 4 Hz position update since 4 x 250ms is one second.
6. UBX->CFG->SBAS : '''Disable''' (SBAS appears to cause occasional severe altitude calcuation errors)
7. UBX->NAV (not UBX->CFG->NAV): double click on '''POSLLH, SOL, STATUS, SVINFO, VELNED.''' They should change from grey to black
(add the flag -DGPS_USE_LATLONG in your [[Airframe_Configuration#Hardware_definitions_-_Makefile|Airframe file]]) also make sure you set tiny_2_1_1.h if you have the latest boards Tiny/TinyWOG)
8. UBX->CFG->CFG : '''save current config''', click '''"send"''' in the lower left corner to permanently save these settings to the receiver

* Cycle the power and verify that the new configuration was saved
* To reset the receiver to the factory defaults go to ''UBX->CFG->CFG'', select 'Revert to default configuration', and click ''Send'' at the bottom left corner. To permanently save these values choose 'Save current configuration' and click ''Send''.
* To backup the configuration to a file on your PC: under the tools menu, choose GPS configuration, then click GPS>>file. This file can be re-loaded in a similar manner to configure additional identical receivers. Be sure the box 'Store configuration into BBR/Flash' is checked when reloading a configuration file to make the changes permanent.
* To update the firmware on a LEA-5H get u-center >= 5.03, revert the GPS receiver to the default configuration, get an appropriate image from u-blox (fitting your receivers serial number), find the flash identification flash.txt file in the u-center install directory and be prepared to wait a long time.

#NOTE: If you have a Tiny with LEA-5H module you must use u-center and manually setup the parameters as shown above (at least switch to 38400 baud manually before transferring the configuration file).
#NOTE: POSUTM is not available on LEA-5H. Instead, use POSLLH. Additionally, add the flag -DGPS_USE_LATLONG in the makefile section of the airframe xml file.

===Reset to Default Settings===
The GPS module can be reset to its original default settings by pulling BOOT_INT high(3.3V) during a power cycle ([http://www.u-blox.com/customersupport/gps.g4/ANTARIS4_Modules_SIM(GPS.G4-MS4-05007).pdf Antaris Manual, p. 122]). It may be required after a wrong firmware upgrade or a bad configuration change.

===DGPS (Differential GPS)===
Differential GPS is any method of improving GPS accuracy by comparing the GPS-indicated position of a nearby location to the known value and transmitting any error to the mobile unit. DGPS was originally created as a means of bypassing the deliberately introduced inaccuracies in civilian GPS signals. The original method used low frequency ground radios to relay correction data to the mobile unit and is still used today at airports, shipping ports, and even individual farms. Satellite Based Augmentation System (SBAS) is a modern form of DGPS where the ground stations relay correction data to a GEO-Stationary satellite, which then relays it to the mobile unit on standard GPS frequencies eliminating the need for a separate radio reciever. SBAS is currently available in 3 regions, [http://www.environmental-studies.de/Precision_Farming/EGNOS_WAAS__E/3E.html WAAS, EGNOS, and MSAS] though only WAAS is officially operational. U-blox receivers support all common varieties of DGPS [http://www.u-blox.com/customersupport/gps.g3/ENGOS_Issues(GPS.G3-CS-04009).pdf read the u-blox SBAS application note].
* It is important to note that DGPS methods only improve the ''accuracy'' of the position calculation, not the ''precision''. Since Paparazzi navigation is typically performed relative to the power-on location, any static error that could be corrected with DGPS is irrelevant.

====WAAS issues====
WAAS has been officially operational and "suitable for safety-of-life applications" since 2003. The default setting of all u-blox receivers ignores WAAS correction data and only uses the WAAS satellites for regular navigation like any other satellite. U-blox recommends further limiting this setting to exclude any stray EGNOS/MSAS satellites in North America, and completely disabling all SBAS functions for use outside North America. In 2006 one formerly reliable Paparazzi aircraft began having great GPS problems and displaying very erratic altitude calculations, disabling WAAS immediately resolved the issue and this phenomenon was recreated several times for verification. Turns out a new WAAS satellite was being added to the system and the others were being moved that week for better distribution. Our advice is to completely disable WAAS.

====EGNOS issues====
EGNOS is officially in "testing mode" and no claims of reliability are made. The [http://www.u-blox.com/customersupport/faq_antaris u-blox FAQ] states the following:
* "Do you see issues with EGNOS?"
*:"Yes. Although the data transmitted by the EGNOS satellites are usually good and valuable (e.g. during the solar storms in autumn 2003), they can sometimes be very unreliable, for example when system tests are performed. As an example, u-blox has noticed erroneous range information (up to three hundred kilometers) on various EGNOS satellite over the last few months [2006]."

===Further Reading===

The u-blox [http://www.u-blox.com/customersupport/antaris4_doc.html System Integration Manual] covers a lot of GPS theory as well as product specific topics.

== Antenna options for the Tiny and Paparazzi GPS units ==

The '''[[Tiny|Tiny 1.1]]''' features a 28mm square ground plane intended to be centered below the [[#Sangshin_13mm_Patch|Sangshin 13mm patch antenna]]. Much better performance has been seen with the 18mm antennas and an augmented ground plane. The ground plane is a critical part of the antenna affecting not only the gain and polarization characteristics but also the center frequency of the system. Users are advised to expand the ground plane to approximately 36mm square, centered on the ceramic portion of the antenna (not the pin). This can be done with copper foil soldered to the vias of the existing ground plane.
[[image:gps_antenna_comparison.jpg|thumb|500px|left|SAM-LS 25mm / Emtac 20mm / Emtac 18mm / Sangshin 18mm / Sangshin 13mm / Sarantel P2]]
<br style="clear:both">

=== Sangshin 18mm Patch ===
[[image:Sangshin_18mm.jpg|thumb|Sangshin 18mm x 4mm 1580Mhz]]
The Sangshin KSA-ST1580MS18 antenna has proven to offer the best performance of the currently available options. These are available from any Sanshin distributor such as [http://www.rfmw.com rfmw] ([http://www.rfmw.com/PortalProductDetail.aspx?ProdId=232436&fmt=1 here]) and cost approximately $6.50/ea. in small quantities.

<br style="clear:both">

=== EMTAC 18mm Patch ===
[[image:Emtac_18mm.jpg|thumb|Emtac 18mm x 4mm 1580Mhz]]
Offering identical performance to the Sangshin in a less attractive package is the Emtac 18mm antenna. The part number for the standard 1580MHz 18x18x4mm is ANA1580T18D40 and is not listed on their website. Other frequencies are available on a special order basis and the 1584Mhz has proven to outperform all other frequencies when used with a 36mm ground plane and no radome. The use of a radome (any material covering the antenna) or a larger ground plane should theoretically favor even higher frequencies.

'''Availability'''

* [http://www.transplantgps.com/modules.html TransplantGPS] in MN, USA. The 1580Mhz models are usually available at a cost of $3.55ea but there may be a minimum order requirement of ~$50 USD.
* [http://www.onefastdaddy.com/catalog/product_info.php?products_id=43 PPZUAV] ~$10.00 USD (no min. order requirement)
<br style="clear:both">

=== Sangshin 13mm Patch ===

[[image:Sangshin_13mm_onboard.jpg|thumb|Sangshin 13mm x 4mm 1580Mhz]]
Part of interest: '''[http://www.sangshinec.com/eng/patch_spec.htm KSA-ST1580MS13]'''

The Tiny 0.99 (not 0.9) and 1.1 were designed around this antenna but users are advised to install 18mm units for better performance.

Size: 13 x 13 mm<br/>
Center Frequency: 1580 MHz<br/>
Bandwidth: 5 MHz<br/>
@Fo: -15 dB<br/>
GAIN (dBi): 0 dBi<br/>
Ground Plane: 50 x 50 mm<br/>

'''Available From'''

[http://www.systroninc.com/ Systronic INC.] - Alberta, Canada
<br style="clear:both">

=== Emtac 20mm Patch ===

[[image:Salvaged_20mm_onboard.jpg|thumb|Emtac 20mm x 4mm]]
The Tiny 0.9 was designed around this 1583Mhz antenna and performed extremely well. Emtac has replaced this with an 18mm model that they claim offers even better performance.

* Obsolete
<br style="clear:both">

=== Sarantel GeoHelix-P2 ===

[[image:Geohelix-p2.jpg|thumb|Sarantel Geohelix P-2 1575Mhz]]

This antenna is popular among UAV designers due to it's natural rejection of other radio frequencies such as those originating from the modem or video system as well as it's improved rejection of signals reflected from the ground. U-blox recommends this antenna and features it in their [http://www.u-blox.com/news/sarantel.html reference design]. Frequency and polarization are not dependent upon ground plane geometry so this antenna is sold only in the true GPS frequency of 1575Mhz.
The geometry makes this antenna very inconvenient to mount, especially in an airplane. Some very non-scientific testing has been done with one of these antennas connected to a Tiny with a short length of 50 Ohm coax above a 120mm square of ungrounded aluminum foil and performance was adequate. The helical design should theoretically outperform a patch in the air, but not on the ground, so any organized comparison will be difficult. Possibly the most important aspect of this antenna is it's natural RFI filtering, which should be evaluated further.

* [http://www.sarantel.com/products/geohelix-p2 GeoHelix-P2] Passive GPS Antenna [[http://www.sarantel.com/downloads/specifications/geohelix-p2.pdf datasheet]]

'''Availability'''

* Sarantel @ cost of approx $18 USD each (active versions available for ~$40)
<br style="clear:both">
* [http://www.onefastdaddy.com/catalog/product_info.php?products_id=40&osCsid=709e839698120c5cd324072b77d67cc1 PPZUAV]

DevGuide/Communications

2008-09-15T15:16:14Z

Rcbrother: /* The "transport" layer */

This page describes the way the communications with the aircrafts are implemented in paparazzi

We'll start with high level stuff such as sending your own telemetry message or datalink (uplink) message. We'll then look at the lower layers
== sending telemetry message ==

Describe your message in the telemetry section in <tt>conf/messages.xml</tt>

This should looks like this

<message name="MARK" id="32">
<field name="ac_id" type="uint8"/>
<field name="lat" type="float" unit="deg"/>
<field name="long" type="float" unit="deg"/>
</message>

The '''id''' has to be unique. The fields can have type '''int8''', '''int16''', '''int32''', '''uint8''', '''uint16''', '''uint32''', '''float''' and arrays of those. They must be aligned on a multiple of their size (c.f. examples with ''pad'' fields).

This enables all the ground system to deal with your message and generate sending code for the airborne system. The code is generated in <tt>var/include/messages.h</tt>.

From the airborne code you can send the message by using this code, for example

DOWNLINK_SEND_MARK(&mark_id, &mark_lat, &mark_long);

You can also have the autopilot send the message periodically.
For doing that, in your telemetry file (for example <tt>conf/telemetry/default.xml</tt>, you can make your own and reference it in the [[Conf.xml|<tt>conf/conf.xml</tt>]] file). You can add a line like

<message name="MARK" period="1"/>

meaning that '''MARK''' will be sent every second. You then need to specify the arguments to your message in <tt>the sw/airborne/ap_downlink.h</tt> header by providing a macro

#define PERIODIC_SEND_MARK() DOWNLINK_SEND_MARK(&mark_id, &mark_lat, &mark_long)

You can have different telemetry modes having different rates for each message. For example you might want a verbose mode and a stealth mode.

When sent by the aircraft the message will be available on the ground ivy bus. You can watch it using the '''messages''' program or with the <tt>ivyprobe</tt> command line.

The file <tt>sw/ground_segment/cockpit/ant_track.c</tt> shows how to receive a message in a C program
For ocaml, we have a higher level library to receive messages (<tt>sw/lib/ocaml/pprz.ml</tt>).

== Adding datalink (uplink) messages ==

This is similar to the above. Add your message in the <tt>datalink</tt> section of <tt>messages.xml</tt>
This will generate parsing code for the airborne program (<tt>var/include/dl_protocol.h</tt>).

You then can add your handler in the <tt>sw/airborne/datalink.c</tt> code (a way should be fined to include external code in that) or you can just rewrite your own <tt>dl_parse_msg()</tt> function, for example in a test program where you want to receive only your own messages.

== The "transport" layer ==

Paparazzi can use the built-in transport layer of different hardware (currently only wavecards and xbee/xtends) and also provides his own layer for hardware lacking it (showing as remote serial ports). C sourcecode (.c) and belonging header (.h) -files are:
<tt>xbee.c, xbee.h</tt>
and
<tt>pprz_transport.c, pprz_transport.h</tt>

Modems

2008-09-15T13:09:10Z

Rcbrother: /* Pinout */

The Paparazzi autopilot features a 5V tolerant 3V TTL serial port to interface with any common radio modem. The bidirectional link provides real-time telemetry and in-flight tuning and navigation commands. The system is also capable overlaying the appropriate protocols to communicate thru non-transparent devices such as the Coronis Wavecard or Maxstream API-enabled products, allowing for hardware addressing for multiple aircraft or future enhancements such as data-relaying, inter-aircraft communication, RSSI signal monitoring and automatic in-flight modem power adjustment. Below is a list of some of the common modems used with Paparazzi, for details on configuring your modem see the [[Airframe_Configuration#Modem|Airframe Configuration]] page.

== Maxstream XBee Pro 2.4GHz (802.15.4, "Series 1") ==

These relatively cheap and light modules implement the [http://www.zigbee.org/en/index.asp ZigBee/IEEE 802.15.4] norm. They allow up to 1.6km (1 mile) range (Paparazzi tested to 2.5km (1.5 miles)). The main drawback of using such 2.4Ghz modules for datalink is that it will interfere with the 2.4Ghz analog video transmitters and a inevitable decrease in range when in proximity to any wifi devices.

{|
|-valign="top"
|[[Image:Xbee_Pro_USB_RF_Modem.jpg|thumb|left|XBee Pro USB Stand-alone Modem (XBP24-PKC-001-UA)]]
|
* Frequency Band 2.4Ghz
* Output Power 100mW (Xbee Pro)
* Sensitivity -100 dBm
* RF Data Rate Up to 250 Kbps
* Interface data rate Up to 115.2 Kbps
* Power Draw (typical) 214 mA TX / 55 mA RX
* Supply Voltage 3.3v
* Range (typical, depends on antenna & environment) Up to 1500m line-of-sight
* Dimensions 24 x 33mm
* Weight 4 grams
* Interface 20-pin mini connector
* Chip antenna, ¼ monopole integrated whip antenna or a U.FL antenna connector (3 versions)
* price : ~32$
|
[[Image:XBee_pro.jpg|thumb|left|XBee Pro OEM Modem]]
|}

=== Pinout ===

[[Image:Maxstream_Xbee_pinout.jpg|left|thumb|Maxstream XBee pinout]]
<br style="clear:both">

{|border="1"
|-valign="top"
||''Xbee 20-pin Header''||''Name''||''Notes''||''Suggested Color''||
|-
|1
| +3.3v
| Power
|Red
|-
|2
|DOUT
|Tx output - connect to Autopilot Rx
|Green
|-
|3
|DIN
|Rx input - connect to Autopilot Tx
|Blue
|-
|10
|GND
| Ground
|Black
|}

The image view is from above, top, thus NOT at the side where the connector pins come out

=== Documentation ===

* [http://www.maxstream.net/products/xbee/xbee-pro-oem-rf-module-zigbee.php product page]
* [http://www.maxstream.net/products/xbee/datasheet_XBee_OEM_RF-Modules.pdf datasheet]
* [http://www.maxstream.net/products/xbee/product-manual_XBee_OEM_RF-Modules.pdf user manual]

== Maxstream XBee Pro XSC 900Mhz ==

Maxstream has recently announced a promising new line of modems combining the small size and low cost of their popular Xbee line with the long range and 2.4Ghz video compatibility of their high end 900Mhz models. Sounds like the perfect modem for anyone who can use 900Mhz. Give them a try and post your results here!
{|
|-valign="top"
|[[Image:xbeeproxsc-rpsma.jpg|thumb|left|Maxstream XBee Pro XSC]]
|
* Frequency Band 900Mhz
* Output Power 100mW
* Sensitivity -100 dBm
* Data Rate: 9600 bps
* Range (typical, depends on antenna & environment) Up to 24km (15 miles) line-of-sight
* Interface 20-pin mini connector (Xbee compatible pinout)
* RPSMA, integrated whip antenna or U.FL antenna connector (3 versions)
* price : ~75 USD
|
|}
=== Documentation ===
* [http://www.digi.com/products/wireless/point-multipoint/xbee-pro-xsc.jsp http://www.digi.com/products/wireless/point-multipoint/xbee-pro-xsc.jsp]

== Maxstream 9XTend ==

These larger units have been tested on the 900Mhz band, but are also available in 2.4Ghz. They are a bit on the heavy side, about 20 grams, but give good performance at range. They have adjustable power settings from 100mW to 1W. Testing has shown range up to 3.2km (2 miles) with 100mW.

{|
|-valign="top"
|
[[Image:XTend_USB_RF_Modem.jpg|frame|left|9XTend USB Modem]]
|
* Frequency Band 900Mhz and 2.4Ghz (2 versions)
* Output Power 1mW to 1W software selectable
* Sensitivity -110 dBm (@ 9600 bps)
* RF Data Rate 9.6 or 115.2 Kbps
* Interface data rate up to 230.4 Kbps
* Power Draw (typical) 730 mA TX / 80 mA RX
* Supply Voltage 2.8 to 5.5v
* Range (typical, depends on antenna & environment) Up to 64km line-of-sight
* Dimensions 36 x 60 x 5mm
* Weight 18 grams
* Interface 20-pin mini connector
* RF connector RPSMA (Reverse-polarity SMA) or MMCX (2 versions)
* price : ~179 USD
|
[[Image:Xtend_module.jpg|frame|left|9XTend OEM Modem]]
|}

=== Pinout ===

[[Image:Maxstream_9XTend_Pinout.gif|thumb|left|Maxstream 9XTend Pinout]]

{| border="1"
|-valign="top"
||'''''9XTend 20-pin Header'''''||'''''Name'''''||'''''Tiny Serial-1 Header'''''||'''''Notes'''''
|-
||1||GND||1 (GND)||Ground
|-
||2||VCC||N/A (requires 5V)||5V power (150mA - 730mA Supplied from servo bus or other 5V source)
|-
||5||RX||8 (TX)||3-5V TTL data input - connect to Tiny TX
|-
||6||TX||7 (RX)||5V TTL data output - connect to Tiny RX
|-
||7||Shutdown||N/A (requires 5V)||Permanently connect this pin to the 5V bus for normal operation
|}
Notes:<br>
* 9XTend can run on voltages as low as 2.8V but users are strongly advised against connecting any modem (especially high power models) to the sensitive 3.3V bus supplying the autopilot processor and sensors.
<br style="clear:both">

=== Documentation ===

* [http://www.maxstream.net/products/xtend/oem-rf-module.php product page]
* [http://www.maxstream.net/products/xtend/datasheet_XTend_OEM_RF-Module.pdf datasheet]
* [http://www.maxstream.net/products/xtend/product-manual_XTend_OEM_RF-Module.pdf user manual]

== Aerocomm ==
Aerocomm's API mode is not yet implemented. Therefore they are used in transparent mode. Users are reporting these modems cause more interference with GPS reception then the Maxstream modem.

How to use this modem on ground station side? [http://paparazzi.enac.fr/wiki/index.php/User:SilaS#SDK-AC4868-250_ground_modem_part]

{|
|
=== AC4868-250 ===
* Frequency Band 868MHz (For Europe).
* Output Power (w/ 2dBi antenna) 250 mW
* Sensitivity (@ full RF data rate) -103 dB
* RF Data Rate Up to 28.8 Kbps
* INterface Data Rate Up to 57.6 Kbps
* Power Draw (typical) 240 mA TX / 36 mA RX
* Supply Voltage 3.3v & 5V or 3.3v only
* Range (typical, depends on antenna & environment) Up to 15 kilometers line-of-sight
* Dimensions 49 x 42 x 5mm
* Weight < 21 grams
* Interface 20-pin mini connector
* Antenna MMCX jack Connector
* price : ~80$
|
[[Image:ConnexLink_USB_RF_Modem.jpg|thumb|Aerocomm USB Stand-alone Modem]]
|-
|

=== AC4790-200 ===
* Frequency 902-928MHz (North America, Australia, etc).
* Output Power 5-200mW
* Sensitivity (@ full RF data rate) -110dB
* RF Data Rate up to 76.8 Kbps
* INterface Data Rate Up to Up to 115.2 Kbps
* Power Draw (typical) 68 mA
* Supply Voltage 3.3v & 5.5V
* Range (typical, depends on antenna & environment) Up to 6.4 kilometers line-of-sight
* Dimensions 42 x 48 x 5mm
* Weight < 20 grams
* Interface 20-pin mini connector
* Antenna MMCX jack Connector or internal
* price : ~80$
|
[[Image:ac4868_transceiver.jpg|thumb|left|AC4868 OEM Modem]]
|
|-
|

=== AC4790-1000 ===
* Frequency 902-928MHz (North America, Australia, etc).
* Output Power 5-1000mW
* Sensitivity (@ full RF data rate) -99dB
* RF Data Rate up to 76.8 Kbps
* INterface Data Rate Up to Up to 115.2 Kbps
* Power Draw (typical) 650 mA
* Supply Voltage 3.3V only
* Range (typical, depends on antenna & environment) Up to 32 kilometers with high-gain antenna
* Dimensions 42 x 48 x 5mm
* Weight < 20 grams
* Interface 20-pin mini connector
* Antenna MMCX jack Connector
* price : ~80$
|}

=== Pinout ===

[[Image:Aerocomm_AC4868_pinout.jpg|thumb|left|Aerocomm AC4868 modem pinout]]
[[Image:Aerocomm_AC4490-200_wired.jpg|thumb|left|Aerocomm AC4490 wiring example]]
<br style="clear:both">

{| border="1"
|+ Wiring the Aerocomm AC4868 to the Tiny
|-valign="top"
||'''''AC4868 20-pin Header'''''||'''''Name'''''||'''''Color'''''||'''''Tiny Serial-1'''''||'''''Notes'''''
|-
||2||Tx||green||7||''(Note 1)''
|-
||3||Rx||blue||8||''(Note 1)''
|-
||5||GND||black||1|| -
|-
||10+11||VCC||red||2||+3.3v
|-
||17||C/D||white||3||Low = Command High = Data
|}
''Note 1 : names are specified with respect to the AEROCOMM module''

=== Documentation ===
* [http://www.aerocomm.com/rf_transceiver_modules/ac4790_mesh-ready_transceiver.htm AC4790 product page]
* [http://www.aerocomm.com/docs/Datasheet_AC4790_HI.pdf AC4790 Datasheet]
* [http://www.aerocomm.com/docs/User_Manual_AC4790.pdf AC4790 Manual]
* [http://www.aerocomm.com/rf_transceiver_modules/ac4868_868mhz_rf_transceiver.htm AC4848 product page]
* [http://www.aerocomm.com/docs/Datasheet_AC4868_HI.pdf AC4868 Datasheet]
* [http://www.aerocomm.com/docs/User_Manual_AC4868.pdf AC4868 user manual]

== Radiotronix ==
These Radiotronix modems are used in transparent mode. Use the WI232EUR Evaluation Software for configuring the modems for the set speed. Connect /CMD and CTS for programming. The DTS version for the US market might cause severe interference with GPS reception, it is not recommended. For a nice ground station modem just add a FTDI232 USB->serial cable, a 3.3V regulator with 100nF capacitors from supplies to ground, solder a SMA cable/connector and put it in a nice case. Make sure you only connect RTS to /CMD if you want to reprogram the modem with the Evaluation software (see the open jumper connection in the picture, green wire) and leave it floating otherwise. The ANT-GXD105-FME/F from [http://www.roundsolutions.com Roundsolutions] was used as a ground station antenna at many competitions.
{|
|
=== WI232EUR ===
* Frequency Band 868MHz (for Europe)
* Output Power 32 mW
* RF Data Rate Up to 76.8 kbps
* Interface Data Rate up to 115.2 kbps
* Power Draw (typical) 65 mA TX / 20 mA RX
* Supply Voltage 3.3v
* Range (typical, depends on antenna & environment) 500 meters line-of-sight
* Dimensions 24 x 21 x 4mm
* Weight ~2 grams
* Interface solder connector
* Antenna solder connector
* price : ~25$
|
[[Image:Wi232eur_wiring.jpg|thumb|WI232EUR Modem]]
|-
|

=== Pinout ===

<br style="clear:both">

{| border="1"
|+ Wiring the WI232EUR to the Tiny
|-valign="top"
||'''''WI232 pins'''''||'''''Name'''''||'''''Tiny Serial-1'''''||'''''Notes'''''
|-
||6||TxD||7||''(Note 1)''
|-
||5||RxD||8||''(Note 1)''
|-
||15-18||GND||1|| -
|-
||19||VCC||2||+3.3v
|-
||4||/CMD||-||''(Note 2)''
|-
||7||CTS||-||''(Note 3)''
|}
''Note 1 : names are specified with respect to the Radiotronix module''

''Note 2 : connect to RTS to program device with Evaluation software''

''Note 3 : connect to CTS to program device with Evaluation software''

|
[[Image:Wi232eur_bopla.jpg|thumb|WI232EUR Modem in BOPLA case]]
|-
|
|}
=== Documentation ===
* [http://www.radiotronix.com/datasheets/new/eur_um.pdf WI232EUR data sheet]
* [http://www.radiotronix.com/datasheets/new/rk-eur_um.pdf WI232EUR user's manual]
* [http://www.radiotronix.com/downloads/software/EUR/setup.exe Evaluation software]

== Bluetooth ==
These modems do not give you a great range but Bluetooth can be found in a lot of recent laptops built-in. Maybe not useful for fixed wing aircrafts it might be used for in-the-shop testing or quadcopters. Make sure you get a recent Class 1 EDR 2.0 stick if you buy one for your computer.
{|
|
=== "Sparkfun" Roving Networks (WRL-08497) ===
* Frequency Band 2.4GHz
* Output Power 32 mW
* RF Data Rate up to ~300 kbps in SPP
* Interface Data Rate up to 921 kbps
* Power Draw (typical) 50 mA TX / 40 mA RX
* Supply Voltage 3.3v
* Range (typical, depends on antenna & environment) 100 meters line-of-sight
* Dimensions 26 x 13 x 2mm
* Weight ~1.5 grams
* Interface solder connector
* price : ~45$
|
[[Image:roving_nw_wiring.jpg|thumb|Roving Networks modem wiring]]
|-
|

To connect to it, get the MAC address of the bluetooth modem

me@mybox:~$ hcitool scan
Scanning ...
00:06:66:00:53:AD FireFly-53AD

and make a virtual connection to a Bluetooth serial port

sudo rfcomm bind 0 00:06:66:00:53:AD

now you can use Bluetooth as /dev/rfcomm0 with the Paparazzi 'link'. You might need to restart 'link' in case you get out of range and it disconnects (tbd). Set the Tiny serial speed to 115200 as the modules come preconfigured to that.
|}

== Coronis WaveCard ==

These relatively inexpensive and light modules implement a Coronis proprietary protocol. Low power consumption - high latency - I would not recommend these modules mostly because of the low quality of the distribution and support. The documentation is rather poor and not easily available.

'''Suport for these modems has been removed from the airborne code on Dec 10th, 2007.'''
{|
|-valign="top"
|
* Frequency Band 400MHz, 868Mhz and 915MHz (3 versions)
* Output Power 25mW and 500mW (2 versions)
* Sensitivity -110 dBm (@ 9600 bps)
* Data Rate 100 Kbps
* Power Draw (typical) 45mA (25mW), 450mA (500mW) TX / 15 mA RX
* Supply Voltage ...
* Range (typical, depends on antenna & environment) Up to 1km (25mW) , 5km (500mW) line-of-sight
* Dimensions 30 x 28 x 7mm (25mW), 37 x 30 x 7mm (500mW)
* 50 ohm RF port for antenna connection
|
[[Image:wavecard.jpg|Coronis Wavecard]]
|}

=== Documentation ===

* [http://www.coronis-systems.com/produit.php?lang=EN&id=WCA www.coronis-systems.com]
* [[Media:CS-COM-SPRD-WAVECARD-E03B.pdf|Wavecard datasheet]]

== Video Transmitter Telemetry ==

[[Image:video_tx_small.jpg|thumb|2.4GHz Video Transmitter]]
In order for the UAV to transmit video from an onboard camera, a video transmitter is needed. The paparazzi AP sends all telemetry data down with the video on the audio channel portion of the transmitter. This means that the transmitter must have an audio channel. These vary in power, and thus range, and run normally on 2.4Ghz. Small UAVs can get about 600m of range from the 50mW version, and extended range can be achieved using units up to 1W. Weight for these units varies from a couple grams to about 30 for the 1W with shielding. Please check for your countries regulations on 2.4Ghz transmission, as each is different.
<br style="clear:both">

== Antennas ==

Here are some examples of lightweight and efficient 868MHz antennas developped by the RF laboratory at ENAC.
[[Image:868mhz_twinstar_antenna_1.jpg|thumb|left|868MHz copper foil antenna attached to the aircraft tail]]
[[Image:868mhz_twinstar_antenna_2.jpg|thumb|left|868MHz copper foil antenna bottom view]]
[[Image:868mhz_ground_antenna.jpg|thumb|left|868MHz ground antenna]]
<br style="clear:both">

Sensors/GPS

2008-09-14T14:13:17Z

Rcbrother: /* GPS configuration using U-Center */

{| align=right
|-
| __TOC__
|}

==Overview==
[[Image:U-blox_color_warm_60.gif|100px]]

Paparazzi autopilots are designed around the popular [http://www.u-blox.com u-blox] brand of receivers.

*Features:
**Small size
**Excellent performance
**4Hz position update rate

The '''[[Tiny]]''' features an onboard LEA series GPS receiver and patch antenna, while '''[[Classix]]''' and '''[[Previous_Autopilots|AVR-based]]''' boards require an external receiver+antenna such as the [[#Paparazzi_Stand-alone_GPS_Receivers|Paparazzi GPS]] or [[#u-Blox_SAM-LS_GPS_Smart_Antenna|SAM-LS]]. Please note that the receivers must be configured (prior to use with the autopilot) as indicated below. Both modules have proven reliable and robust.

{|align = center
|-
|[[Image:Lea big.jpg|200px|thumb|center|u-blox LEA GPS Receiver]]
|[[Image:Ublox_SAM-LS.jpg|200px|thumb|center|u-blox SAM-LS GPS receiver (w/built-in Smart Antenna)]]
|}

'''Note:''' The proprietary UBX protocol is used as it offers more information and efficiency than the universal NMEA protocol. The protocol is parsed in <tt>sw/airborne/gps_ubx.c</tt>. Other GPS brands would require a similar parsing file to be written for NMEA or other proprietary protocols.

==GPS Receivers==

===u-Blox LEA Series Receivers===
[[Image:Lea big.jpg|100px|thumb|right|u-blox LEA]]
The '''[[Tiny]]''' and Paparazzi stand-alone GPS currently use the [http://www.u-blox.com/products/lea_4p.html u-blox LEA-4P] featuring [http://www.u-blox.com/technology/antaris4/index.html Antaris-4] technology and uBlox's more efficient UBX binary protocol. This module is a surface mount package which is soldered directly onto the PCB (Tiny or Paparazzi GPS). An external battery backup (capacitor) is used to enable the GPS to retain data while powered off for significantly faster signal re-aquisition. Any of the LEA-4x series receivers can be used including the less expensive LEA-4A and 4S models as the special boot configuration code required for these models is already written.

*4Hz Position update rate
*Supports active or passive antennas
*Supports [http://en.wikipedia.org/wiki/DGPS DGPS], [http://en.wikipedia.org/wiki/WAAS WAAS], [http://en.wikipedia.org/wiki/EGNOS EGNOS], and [http://en.wikipedia.org/wiki/MSAS MSAS]
*Low position [http://paparazzi.enac.fr/wiki_images/Gps_rx_noise.pdf noise] figure
[[Image:TINY_1.3_MCU_BOTTOM.JPG|thumb|center|250px|LEA-4P installed on the Tiny]]
<br style="clear:both">

===Paparazzi Stand-alone GPS Receivers===
There are currently two (LEA-based) stand-alone, GPS receiver + antenna, prototype boards in development; the first one is based on the Sangshin 13mm patch antenna. The second is based on the Sarantel helix antenna. Drawings for both are available from the [http://cvs.savannah.gnu.org/viewcvs/paparazzi/paparazzi3/hw/ CVS]
Another alternative is the NAVILOCK NL-507TTL u-blox TTL Modul 60416 which is availible for 28€ (amazon.de).

===u-Blox SAM-LS GPS Smart Antenna===
[[Image:Ublox_SAM-LS.jpg|100px|thumb|right|u-blox SAM-LS]]
The '''[[Classix]]''' and '''[[Previous_Autopilots|AVR-based]]''' boards use a stand alone module from u-blox called the SAM-LS. It is an integrated TIM-LP module with a ceramic patch antenna. This processor also runs on 4hz and must be configured to use the UBX protocol. With battery backup (3V watch battery) they show hot starts of around a couple seconds. The LEA-LA processor weighs a couple grams and the complete the SAM-LS module with antenna and shielding weighs about 20grams.

'''Note:''' Effective 12/2006 u-blox has begun to phase out the SAM-LS product. No replacement will be offered.

====Connecting external receivers to Classix, 1.2.1, Lite, and RoboStix boards====

The u-blox receivers require 3.3v power and all current models have 5V tolerant data lines. The best way to connect to the SAM-LS is to remove the bottom case and solder the 4 wires directly to the TIM-LL module (GND (pin 1) ,VCC (pin 2),TX (Pin 5),RX (pin 4)) check the TIM-LL datasheet for pinout diagrams. The Classix and Lite boards feature a 3.3V regulator to power the GPS.

===Sourcing from u-blox===

u-blox keeps tight control over the distribution of their products. They must be obtained DIRECTLY from their own reseller offices. These offices may not be available in your area, for example Canada does not have a reseller. Sample quantities can be obtained from uBlox but overnight or 2 day shipping is required which drives the cost up considerably. While it is a large hassle obtaining these devices, it is undoubtedly worth it.

Talking with ublox sale for two years, Confirmed, that Order is possiable Directly from ublox, by knowing what project it was for & how was it to be use. After long reply waiting time, the answer was: - YES, but at least 2K-3K in volume, otherwise they're not interested. Like to share the order ? It is 500pcs/Roll.

===Other potential source of u-blox GPS===

There seems to be a few alternative source of u-blox GPS out there. They are considerably cheaper then the samples u-blox offers (at least in america). We didn't buy from these sources yet. Do not take this as a recommandation, we do not know the level of service they offer, etc.

If you do order from any of them, please update this page with your feedback.

Here's a few link worth exploring:
*http://www.rfdesign.co.za/pages/5645456/Products/GPS-Products/Antaris-4-Modules.asp
*http://www.comet.srl.ro/shop/info.html?ID=6195 ( Link error )
*http://www.expedienttech.com/product.htm ( Singapore )
*http://shop.halfbase.com/index.php/cPath/22?osCsid=414472d5a544b080f9ae153fdc323798 ( B2B- min.10pcs @ $38 )

===Standalone GPS Module from CVS===
The Version 1 (V1) BOM is here.. Please post any pics you might have and check this for accuracy<br>
[http://paparazzi.enac.fr/wiki_images/Gps_13_BOM.xls V1 BOM]<br>
[http://paparazzi.enac.fr/wiki_images/TinygpsBOM.txt Eagle Parts List Output]<br>

[[Image:LEA5HExternalModulePinout.jpg|250px|thumb|right|LEA-5H Full Board Pinout]]

If this needs fixing don't be shy, fix away.

==GPS configuration using U-Center==

[[Image:U-center_screencap.jpg|thumb|u-center configuration software]]
[http://www.u-blox.com/products/u_center.html U-Center] is a very comprehensive freeware program intended for the configuration and evaluation of u-blox receivers.
* [http://www.u-blox.com/products/u_center.html Download u-center]

* Note: You must [[Compiling#USB_flashing|install the UART tunnel]] to enable direct access to the built-in GPS on the [[Tiny|Tiny]].
* Note: You can run u-center on Linux by installing "wine" ([http://www.winehq.org/site/download-deb Installation of Wine]) and setting up com1 as /dev/ttyUSB0 See Info on wine for "dosdevices" setup. Just download the u-setup.exe and run it with wine, follow prompts. This has been tested with Ubuntu7.10 and Ubuntu 8.04 so far.
* Note: You will need a driver for your FTDI cable if you run u-center on Windows, which can be found [http://www.ftdichip.com/Drivers/D2XX.htm here].
The u-blox and Tiny UARTs both operate at 3.3V TTL levels and are 5V TTL tolerant. You must use a level shifter such as the common MAX232 to connect these devices to a standard PC serial port. The easiest and most recommended method is to connect to a USB port instead of serial with the $20 [http://www.ftdichip.com/Products/EvaluationKits/TTL-232R.htm FTDI USB-TTL converter cable] available from Digikey, Mouser, or direct from FTDI. Other similar converters are available from [http://www.pololu.com/products/pololu/0391/ pololu] / [http://www.sparkfun.com/commerce/product_info.php?products_id=199 sparkfun] or [http://shop.halfbase.com/product_info.php/products_id/54 Halfbase]. A stand-alone GPS such as the SAM-LS will require clean 3.3V/50mA power and a common ground with the TTL converter.

* U-blox occasionally releases firmware updates. Log on to the u-blox website using ''paparazzi'' for username & password to view or download the latest firmware images. There have 'never' been any updates released for the Antaris-4 series used in the Tiny.

Start U-center and choose your com port from the pull down list under the connect button near the top left corner of the window. Choose your baudrate from the pull down box to the right of the connect button or select the auto-baud button to the right of that. U-blox default is 9600 baud. This must be changed to 19200 or higher to accomodate the 4Hz update rate.
<br>[[Image:U-center_buttons.jpg|connect, baud, and autobaud buttons]]
<br style="clear:both">

===Uploading the Configuration File===
Download the appropriate configuration file below and use u-center to load in onto your receiver. Under the ''Tools'' menu, choose ''GPS configuration''. Be sure the box 'Store configuration into BBR/Flash' is checked and hit the button ''File>>GPS''. A few errors and retries are normal, but a significant number of errors may indicate a poor connection and the software will notify you if it is unable to send all the data successfully.
* [[Media:Tiny_LEA-4P-v6.zip|LEA-4P]]
* [[Media:Tim-LL-V5.zip|TIM-LL]]
* [http://paparazzi.enac.fr/wiki_images/Tiny_LEA-5H-v5.zip LEA-5H (For Use w/ Firmware V5 ONLY!)]

===Manual Configuration===
If you prefer to setup your receiver manually or have a model not listed above, here are instructions to configure your receiver in u-center.
Open the message window (menu View->messages view) to start the configuration process by changing the following settings:

====LEA-4P====

1. Right Click on the '''NMEA''' Icon and choose '''disable child'''
2. Choose UBX->CFG->NAV2(Navigation 2) - set it to use '''Airborne 4G''' (tells the Kalman filter to expect significant changes in direction)
3. UBX->CFG->PRT - set '''USART1''' to '''38400bps''' (must match the value in your [[Airframe_Configuration#Hardware_definitions_-_Makefile|Airframe file]])
4. Change the baudrate of U-Center to 38400bps if the connection is lost at this point
5. UBX->CFG->RXM(Receiver Manager) - change '''GPS Mode''' to '''3 - Auto''' (Enabling faster bootup only if signal levels are very good)
6. UBX->CFG->RATE(Rates) - change the '''Measurement Period''' to '''250ms''' (4 Hz position updates)
7. UBX->CFG->SBAS : '''Disable''' (SBAS appears to cause occasional severe altitude calcuation errors)
8. UBX->NAV (not UBX->CFG->NAV): double click on '''POSUTM, SOL, STATUS, SVINFO, VELNED.''' They should change from grey to black
9. UBX->CFG->CFG : '''save current config''', click '''"send"''' in the lower left corner to permanently save these settings to the receiver

====LEA-5H====

1. Right Click on the '''NMEA''' Icon and choose '''disable child'''
2. Choose UBX->CFG->NAV5(Navigation 5) - set it to use '''Airborne 8 >4G''' (tells the Kalman filter to expect significant changes in direction)
3. UBX->CFG->PRT - set '''USART1''' to '''38400bps''' (must match the value in your [[Airframe_Configuration#Hardware_definitions_-_Makefile|Airframe file]])
4. Change the baudrate of U-Center to 38400bps if the connection is lost at this point
5. UBX->CFG->RATE(Rates) - change the '''Measurement Period''' to '''250ms''' (4 Hz position updates)
6. UBX->CFG->SBAS : '''Disable''' (SBAS appears to cause occasional severe altitude calcuation errors)
7. UBX->NAV (not UBX->CFG->NAV): double click on '''POSLLH, SOL, STATUS, SVINFO, VELNED.''' They should change from grey to black
(add the flag -DGPS_USE_LATLONG in your [[Airframe_Configuration#Hardware_definitions_-_Makefile|Airframe file]])
8. UBX->CFG->CFG : '''save current config''', click '''"send"''' in the lower left corner to permanently save these settings to the receiver

* Cycle the power and verify that the new configuration was saved
* To reset the receiver to the factory defaults go to ''UBX->CFG->CFG'', select 'Revert to default configuration', and click ''Send'' at the bottom left corner. To permanently save these values choose 'Save current configuration' and click ''Send''.
* To backup the configuration to a file on your PC: under the tools menu, choose GPS configuration, then click GPS>>file. This file can be re-loaded in a similar manner to configure additional identical receivers. Be sure the box 'Store configuration into BBR/Flash' is checked when reloading a configuration file to make the changes permanent.
* To update the firmware on a LEA-5H get u-center >= 5.03, revert the GPS receiver to the default configuration, get an appropriate image from u-blox (fitting your receivers serial number), find the flash identification flash.txt file in the u-center install directory and be prepared to wait a long time.

#NOTE: If you have a Tiny with LEA-5H module you must use u-center and manually setup the parameters as shown above (at least switch to 38400 baud manually before transferring the configuration file).
#NOTE: POSUTM is not available on LEA-5H. Instead, use POSLLH. Additionally, add the flag -DGPS_USE_LATLONG in the makefile section of the airframe xml file.

===Reset to Default Settings===
The GPS module can be reset to its original default settings by pulling BOOT_INT high(3.3V) during a power cycle ([http://www.u-blox.com/customersupport/gps.g4/ANTARIS4_Modules_SIM(GPS.G4-MS4-05007).pdf Antaris Manual, p. 122]). It may be required after a wrong firmware upgrade or a bad configuration change.

===DGPS (Differential GPS)===
Differential GPS is any method of improving GPS accuracy by comparing the GPS-indicated position of a nearby location to the known value and transmitting any error to the mobile unit. DGPS was originally created as a means of bypassing the deliberately introduced inaccuracies in civilian GPS signals. The original method used low frequency ground radios to relay correction data to the mobile unit and is still used today at airports, shipping ports, and even individual farms. Satellite Based Augmentation System (SBAS) is a modern form of DGPS where the ground stations relay correction data to a GEO-Stationary satellite, which then relays it to the mobile unit on standard GPS frequencies eliminating the need for a separate radio reciever. SBAS is currently available in 3 regions, [http://www.environmental-studies.de/Precision_Farming/EGNOS_WAAS__E/3E.html WAAS, EGNOS, and MSAS] though only WAAS is officially operational. U-blox receivers support all common varieties of DGPS [http://www.u-blox.com/customersupport/gps.g3/ENGOS_Issues(GPS.G3-CS-04009).pdf read the u-blox SBAS application note].
* It is important to note that DGPS methods only improve the ''accuracy'' of the position calculation, not the ''precision''. Since Paparazzi navigation is typically performed relative to the power-on location, any static error that could be corrected with DGPS is irrelevant.

====WAAS issues====
WAAS has been officially operational and "suitable for safety-of-life applications" since 2003. The default setting of all u-blox receivers ignores WAAS correction data and only uses the WAAS satellites for regular navigation like any other satellite. U-blox recommends further limiting this setting to exclude any stray EGNOS/MSAS satellites in North America, and completely disabling all SBAS functions for use outside North America. In 2006 one formerly reliable Paparazzi aircraft began having great GPS problems and displaying very erratic altitude calculations, disabling WAAS immediately resolved the issue and this phenomenon was recreated several times for verification. Turns out a new WAAS satellite was being added to the system and the others were being moved that week for better distribution. Our advice is to completely disable WAAS.

====EGNOS issues====
EGNOS is officially in "testing mode" and no claims of reliability are made. The [http://www.u-blox.com/customersupport/faq_antaris u-blox FAQ] states the following:
* "Do you see issues with EGNOS?"
*:"Yes. Although the data transmitted by the EGNOS satellites are usually good and valuable (e.g. during the solar storms in autumn 2003), they can sometimes be very unreliable, for example when system tests are performed. As an example, u-blox has noticed erroneous range information (up to three hundred kilometers) on various EGNOS satellite over the last few months [2006]."

===Further Reading===

The u-blox [http://www.u-blox.com/customersupport/antaris4_doc.html System Integration Manual] covers a lot of GPS theory as well as product specific topics.

== Antenna options for the Tiny and Paparazzi GPS units ==

The '''[[Tiny|Tiny 1.1]]''' features a 28mm square ground plane intended to be centered below the [[#Sangshin_13mm_Patch|Sangshin 13mm patch antenna]]. Much better performance has been seen with the 18mm antennas and an augmented ground plane. The ground plane is a critical part of the antenna affecting not only the gain and polarization characteristics but also the center frequency of the system. Users are advised to expand the ground plane to approximately 36mm square, centered on the ceramic portion of the antenna (not the pin). This can be done with copper foil soldered to the vias of the existing ground plane.
[[image:gps_antenna_comparison.jpg|thumb|500px|left|SAM-LS 25mm / Emtac 20mm / Emtac 18mm / Sangshin 18mm / Sangshin 13mm / Sarantel P2]]
<br style="clear:both">

=== Sangshin 18mm Patch ===
[[image:Sangshin_18mm.jpg|thumb|Sangshin 18mm x 4mm 1580Mhz]]
The Sangshin KSA-ST1580MS18 antenna has proven to offer the best performance of the currently available options. These are available from any Sanshin distributor such as [http://www.rfmw.com rfmw] ([http://www.rfmw.com/PortalProductDetail.aspx?ProdId=232436&fmt=1 here]) and cost approximately $6.50/ea. in small quantities.

<br style="clear:both">

=== EMTAC 18mm Patch ===
[[image:Emtac_18mm.jpg|thumb|Emtac 18mm x 4mm 1580Mhz]]
Offering identical performance to the Sangshin in a less attractive package is the Emtac 18mm antenna. The part number for the standard 1580MHz 18x18x4mm is ANA1580T18D40 and is not listed on their website. Other frequencies are available on a special order basis and the 1584Mhz has proven to outperform all other frequencies when used with a 36mm ground plane and no radome. The use of a radome (any material covering the antenna) or a larger ground plane should theoretically favor even higher frequencies.

'''Availability'''

* [http://www.transplantgps.com/modules.html TransplantGPS] in MN, USA. The 1580Mhz models are usually available at a cost of $3.55ea but there may be a minimum order requirement of ~$50 USD.
* [http://www.onefastdaddy.com/catalog/product_info.php?products_id=43 PPZUAV] ~$10.00 USD (no min. order requirement)
<br style="clear:both">

=== Sangshin 13mm Patch ===

[[image:Sangshin_13mm_onboard.jpg|thumb|Sangshin 13mm x 4mm 1580Mhz]]
Part of interest: '''[http://www.sangshinec.com/eng/patch_spec.htm KSA-ST1580MS13]'''

The Tiny 0.99 (not 0.9) and 1.1 were designed around this antenna but users are advised to install 18mm units for better performance.

Size: 13 x 13 mm<br/>
Center Frequency: 1580 MHz<br/>
Bandwidth: 5 MHz<br/>
@Fo: -15 dB<br/>
GAIN (dBi): 0 dBi<br/>
Ground Plane: 50 x 50 mm<br/>

'''Available From'''

[http://www.systroninc.com/ Systronic INC.] - Alberta, Canada
<br style="clear:both">

=== Emtac 20mm Patch ===

[[image:Salvaged_20mm_onboard.jpg|thumb|Emtac 20mm x 4mm]]
The Tiny 0.9 was designed around this 1583Mhz antenna and performed extremely well. Emtac has replaced this with an 18mm model that they claim offers even better performance.

* Obsolete
<br style="clear:both">

=== Sarantel GeoHelix-P2 ===

[[image:Geohelix-p2.jpg|thumb|Sarantel Geohelix P-2 1575Mhz]]

This antenna is popular among UAV designers due to it's natural rejection of other radio frequencies such as those originating from the modem or video system as well as it's improved rejection of signals reflected from the ground. U-blox recommends this antenna and features it in their [http://www.u-blox.com/news/sarantel.html reference design]. Frequency and polarization are not dependent upon ground plane geometry so this antenna is sold only in the true GPS frequency of 1575Mhz.
The geometry makes this antenna very inconvenient to mount, especially in an airplane. Some very non-scientific testing has been done with one of these antennas connected to a Tiny with a short length of 50 Ohm coax above a 120mm square of ungrounded aluminum foil and performance was adequate. The helical design should theoretically outperform a patch in the air, but not on the ground, so any organized comparison will be difficult. Possibly the most important aspect of this antenna is it's natural RFI filtering, which should be evaluated further.

* [http://www.sarantel.com/products/geohelix-p2 GeoHelix-P2] Passive GPS Antenna [[http://www.sarantel.com/downloads/specifications/geohelix-p2.pdf datasheet]]

'''Availability'''

* Sarantel @ cost of approx $18 USD each (active versions available for ~$40)
<br style="clear:both">
* [http://www.onefastdaddy.com/catalog/product_info.php?products_id=40&osCsid=709e839698120c5cd324072b77d67cc1 PPZUAV]

Installation/Linux

2008-09-11T21:50:11Z

Rcbrother: /* LiveCd */

Precompiled binaries can be downloaded and executed with the ''paparazzi-bin'' package but to maintain the power and flexibility of open-source code, most operations within Paparazzi involve recompilation of autopilot and/or ground station code. Therefore the typical installation requires all of the necessary C and OCaml compilers as well as some XML and [http://www.tls.cena.fr/products/ivy/ Ivy] handlers. These tools are provided by the ''paparazzi-dev'' package.

The Paparazzi sources are hosted by [http://savannah.nongnu.org/cvs/?group=paparazzi Savannah].

The Paparazzi packages are hosted at the [http://www.recherche.enac.fr/paparazzi/debian ENAC repository].

== Installation on Debian based distributions ==

Paparazzi is packaged for Debian as well as all of its dependencies. The [http://www.recherche.enac.fr/paparazzi/debian repository] hosted at ENAC holds their latest version.

=== Installation from the Command Line===
Just add the following lines to your repository list (<b>/etc/apt/sources.list</b>) and then
uncomment the line relevant to your operating system (e.g. one of etch, gutsy or hardy):

{{Box Code|/etc/apt/sources.list|
# Uncomment just _one_ of the following lines - depending on your OS version
# deb <nowiki>http://paparazzi.enac.fr/debian</nowiki> etch main
# deb <nowiki>http://paparazzi.enac.fr/ubuntu</nowiki> gutsy main
# deb <nowiki>http://paparazzi.enac.fr/ubuntu</nowiki> hardy main
}}

Note: It is not recommended to install both <tt>paparazzi-bin</tt> <b>and</b> <tt>paparazzi-dev</tt>.

Then, update your sources and '''either''' install the precompiled <b>bin</b>aries
sudo apt-get update
sudo apt-get install paparazzi-bin
<b>or</b> the dependencies needed for recompiling from the source (<b>dev</b>), and the cross-compiler (<b>arm7</b>) :
apt-get update
apt-get install paparazzi-dev
apt-get install paparazzi-arm7

As stated before it is not recommended to install both <tt>paparazzi-bin</tt> <b>and</b> <tt>paparazzi-dev</tt>. While the <b>bin</b> package is self-contained and should be sufficient for users who do not want to patch the code, the <b>dev</b> meta-package provides only the tools to compile the source code which must be separately downloaded, from an archive or the CVS repository.

==== Optional/Obsolete Packages ====
Users of older AVR based boards will also need the paparazzi-avr package.

==== Extra for Ubuntu ====

The Braille TTY driver interferes with FTDI USB Serial adapters and should be removed:

sudo apt-get remove brltty

=== Installation thru Synaptic Package Manager ===
* Launch ''Synaptic Package Manager'' (''Applications/System'' Tools Menu)
* In '''Settings/Repositories''', add a new repository on URI = '''<nowiki>http://paparazzi.enac.fr/debian</nowiki>''', Distribution = '''etch''', Section = '''main''' . For Ubuntu, replace '''debian''' by '''ubuntu''' and '''etch''' by '''gutsy''' (or '''hardy''')
* Search for <tt>paparazzi-bin</tt>, <tt>paparazzi-dev</tt>, and <tt>paparazzi-arm7</tt> packages (use the ''Search'' button)
* Mark them for installation (right-click on package names)
* Left-click on ''Apply''

== Manual Installation of Individual Packages ==
Users of other Linux flavors or anyone needing manual control of each individual package can install them independently. The list of dependencies of the Debian package is located in the [http://cvs.savannah.gnu.org/viewvc/paparazzi/paparazzi3/debian/control.etch?revision=1.16&view=markup <tt> debian/control.etch</tt>] file and may help users of other distributions.

The binary packages and some corresponding source tarballs can be downloaded from

http://paparazzi.enac.fr/debian/dists/etch/main/binary-i386/

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

For Fedora (Core8) users, you can install the following packages from standard repository:
* ocaml.i386
* ocaml-camlimages-devel.i386
* ocaml-lablgtk-devel.i386
* ocaml-xml-light-devel.i386
* boa.i386
* libgnomecanvas-devel.i386
* libusb-devel.i386
* pcre-devel.i386
* arm-gp2x-linux-gcc.i386
* arm-gp2x-linux-binutils.i386
* glade2.i386
* and gcc, make, cvs, gnuplot, imagemagik...

Then you need [http://packages.debian.org/unstable/source/alien alien] tool to convert packages from the paparazzi repository:
* ivy-c
* ivy-c-dev
* ivy-ocaml (WARNING: debian and fedora have different path for ocaml (/usr/lib/ocaml/<version> vs. /usr/lib/ocaml), so you need to move by hand the files in /usr/lib/ocaml/<version> to /usr/lib/ocaml)
* lpc21isp

== Installing the Source Code (not needed with paparazzi-bin) ==
After the <tt>paparazzi-dev</tt> package is installed the complete source code should be downloaded from the CVS repository. See the [http://savannah.nongnu.org/cvs/?group=paparazzi project page] at Savannah for more details. From the directory of your choice type:
cvs -z3 -d:pserver:anonymous@cvs.savannah.nongnu.org:/sources/paparazzi co paparazzi3
This will download all of the code and install it into <tt>paparazzi3/</tt>

If you cannot use the CVS install, dayly updated tarballs can also be fetched from the [[Downloads|Downloads]] page.

== Launching the Software ==

If you are using the <tt>paparazzi-bin</tt> package or the Live-CD, just launch the <tt>paparazzi</tt> binary application and you will be guided through the installation of your personal configuration files.

If you are using the source code, the first step is to compile it. From the <tt>paparazzi3</tt> directory (<tt>cd paparazzi3</tt>), run

make

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

./paparazzi

From the [[Paparazzi_Center|Paparazzi Center]] interface, select the ''MJ5'' aircraft, select the ''sim'' target and ''Build'' it. Then ''Execute'' the ''Simulation'' session.

If ('''and only if''') you want to directly launch some Paparazzi agents (the ''Tools'' of the [[Paparazzi_Center|Paparazzi Center]]), 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|/home/your_username/.bashrc|
export PAPARAZZI_HOME<nowiki>=</nowiki>''your paparazzi3 directory''
export PAPARAZZI_SRC<nowiki>=</nowiki>''your paparazzi3 directory''
}}
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:
export PAPARAZZI_HOME=`pwd`;export PAPARAZZI_SRC=`pwd`
Verify that your variables are set correctly with the following command:
env | grep PAPARAZZI
which should return the following:
PAPARAZZI_HOME<nowiki>=</nowiki>''your paparazzi3 directory''
PAPARAZZI_SRC<nowiki>=</nowiki>''your paparazzi3 directory''

== Setting access rights for USB download ==

This may be required to flash the Paparazzi-boards directly thru USB. For flashing details, see [[Compiling]].

Default linux rights may not allow standard (non root) users to directly access the USB bus. You will need to make yourself a member of the plugdev "group" and then create a "rule", associated with that "group". <br>
Make yourself a member of the ''plugdev'' group:

sudo adduser <your login> plugdev

Logout and login again. Then add the appropriate rule (available ine fhe file ''10-paparazzi.rules'') to the USB handler. Simply copy as root <tt>$PAPARAZZI_HOME/conf/system/udev/rules/10-paparazzi.rules</tt> to <tt>/etc/udev/rules.d/</tt>

sudo cp $PAPARAZZI_HOME/conf/system/udev/rules/10-paparazzi.rules /etc/udev/rules.d/

== Software Updates ==
Paparazzi is a very rapidly evolving project and as such, you will find that variables and functions are frequently added, changed, or removed. 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. Your airframe file will not be updated by the CVS system and therefore any new or modified variable names will need to be added manually. The compiler will usually identify the problem variables at which point you can look at some of the most recent airframe files on the CVS to find the proper syntax. See the [[Compiling]] page for more help if needed.
<br>
That said, keeping your software up to date is easy with the CVS system. The system will compare all source code files with the server and update any that are needed, automatically merging any minor changes that you have incorporated along the way.

To download and automatically merge any updated source files, run the following command from your Paparazzi directory
cvs update -d
where the <tt>-d</tt> is needed to get any new directories.

After any CVS update or source code modification the code can be recompiled from ''your paparazzi3 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 deleted all compiled files and recompile from scratch with the following commands:

make clean
make

See the [[Compiling]] page for more info.

Users making changes to their code structure may prefer to have more control over the updating and merging process and may wish to install and use '''tkcvs''' instead which provides highlighted comparisons of any files that differ between your code and the CVS server and allows for a file by file update.

To update your Linux distribution as well as any dependencies of Paparazzi (seldom necessary), run the following as root:
apt-get update
apt get upgrade

== LiveCd ==

The LiveCD is an easy way to test Paparazzi: no installation is required and no changes are made to your computer. Simply burn the image as a boot CD and reboot! The LiveCD includes Linux and the complete paparazzi binary package (code source, tools and cross compilers). It is intended for demonstration only and not frequently updated but it contains the complete system and can store changed files on a pen drive or compressed file on your hard drive so that it can compile, flash, and operate any aircraft, albeit slowly.

The CD image is available from the [[Downloads|Downloads]] page.

The Paparazzi demo is launchable on the Live CD from the Paparazzi icon.

Knoppix allows for all the user data to be saved on a hard disk partition (most file systems are supported) or on a removable device (typically a USB pendrive). Note that this action is not destructive: the user data tree is compressed and stored on your file system as a single file (<tt>knoppix.img</tt>).
* From the Knoppix menu (second from bottom left), choose '''Configure''', '''Create a persistent KNOPPIX disk image'''
* Choose your media (be sure to connect your USB pendrive before booting!)
* Choose if you want an encrypted filesystem (to protect your flight plan designed for the next MAV competition :-) )
* Choose the size of your home directory (100Mb is recommended)
On the next reboot, this saved state will be automatically located and loaded.

Using this persistent feature, the Paparazzix Live CD can really be used to configure, simulate and fly an aircraft with the Paparazzi system.

The Live CD can also be used to install a Debian system on the hard disk, using the <tt>knoppix-installer</tt> command. Be sure to backup the hard disk before trying ...

[[Image:Lightscribe_CD_Cover_1.JPG|thumb|320px|LightScribe CD Cover]] A LiveCD needs some looks... In color or in LightScribe format, your CD will always look cool.
* Get the PDF version for download here [http://paparazzi.enac.fr/wiki_images/Lightscribe_CD_Cover_1.pdf LightScribe CD Cover 1].

* The LightScribe version is in Nero Cover Design format (.ncd) and it's here for download [http://paparazzi.enac.fr/wiki_images/Lightscribe_CD_Cover_1.zip LightScribe CD Cover 1]

* Better is ofcourse to use it on an OpenSource OS, some Linux software to be found here: [http://www.lightscribe.com/downloadSection/linux/index.aspx?id=815]

Installation/Linux

2008-09-11T21:43:28Z

Rcbrother: /* Installation from the Command Line */

Precompiled binaries can be downloaded and executed with the ''paparazzi-bin'' package but to maintain the power and flexibility of open-source code, most operations within Paparazzi involve recompilation of autopilot and/or ground station code. Therefore the typical installation requires all of the necessary C and OCaml compilers as well as some XML and [http://www.tls.cena.fr/products/ivy/ Ivy] handlers. These tools are provided by the ''paparazzi-dev'' package.

The Paparazzi sources are hosted by [http://savannah.nongnu.org/cvs/?group=paparazzi Savannah].

The Paparazzi packages are hosted at the [http://www.recherche.enac.fr/paparazzi/debian ENAC repository].

== Installation on Debian based distributions ==

Paparazzi is packaged for Debian as well as all of its dependencies. The [http://www.recherche.enac.fr/paparazzi/debian repository] hosted at ENAC holds their latest version.

=== Installation from the Command Line===
Just add the following lines to your repository list (<b>/etc/apt/sources.list</b>) and then
uncomment the line relevant to your operating system (e.g. one of etch, gutsy or hardy):

{{Box Code|/etc/apt/sources.list|
# Uncomment just _one_ of the following lines - depending on your OS version
# deb <nowiki>http://paparazzi.enac.fr/debian</nowiki> etch main
# deb <nowiki>http://paparazzi.enac.fr/ubuntu</nowiki> gutsy main
# deb <nowiki>http://paparazzi.enac.fr/ubuntu</nowiki> hardy main
}}

Note: It is not recommended to install both <tt>paparazzi-bin</tt> <b>and</b> <tt>paparazzi-dev</tt>.

Then, update your sources and '''either''' install the precompiled <b>bin</b>aries
sudo apt-get update
sudo apt-get install paparazzi-bin
<b>or</b> the dependencies needed for recompiling from the source (<b>dev</b>), and the cross-compiler (<b>arm7</b>) :
apt-get update
apt-get install paparazzi-dev
apt-get install paparazzi-arm7

As stated before it is not recommended to install both <tt>paparazzi-bin</tt> <b>and</b> <tt>paparazzi-dev</tt>. While the <b>bin</b> package is self-contained and should be sufficient for users who do not want to patch the code, the <b>dev</b> meta-package provides only the tools to compile the source code which must be separately downloaded, from an archive or the CVS repository.

==== Optional/Obsolete Packages ====
Users of older AVR based boards will also need the paparazzi-avr package.

==== Extra for Ubuntu ====

The Braille TTY driver interferes with FTDI USB Serial adapters and should be removed:

sudo apt-get remove brltty

=== Installation thru Synaptic Package Manager ===
* Launch ''Synaptic Package Manager'' (''Applications/System'' Tools Menu)
* In '''Settings/Repositories''', add a new repository on URI = '''<nowiki>http://paparazzi.enac.fr/debian</nowiki>''', Distribution = '''etch''', Section = '''main''' . For Ubuntu, replace '''debian''' by '''ubuntu''' and '''etch''' by '''gutsy''' (or '''hardy''')
* Search for <tt>paparazzi-bin</tt>, <tt>paparazzi-dev</tt>, and <tt>paparazzi-arm7</tt> packages (use the ''Search'' button)
* Mark them for installation (right-click on package names)
* Left-click on ''Apply''

== Manual Installation of Individual Packages ==
Users of other Linux flavors or anyone needing manual control of each individual package can install them independently. The list of dependencies of the Debian package is located in the [http://cvs.savannah.gnu.org/viewvc/paparazzi/paparazzi3/debian/control.etch?revision=1.16&view=markup <tt> debian/control.etch</tt>] file and may help users of other distributions.

The binary packages and some corresponding source tarballs can be downloaded from

http://paparazzi.enac.fr/debian/dists/etch/main/binary-i386/

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

For Fedora (Core8) users, you can install the following packages from standard repository:
* ocaml.i386
* ocaml-camlimages-devel.i386
* ocaml-lablgtk-devel.i386
* ocaml-xml-light-devel.i386
* boa.i386
* libgnomecanvas-devel.i386
* libusb-devel.i386
* pcre-devel.i386
* arm-gp2x-linux-gcc.i386
* arm-gp2x-linux-binutils.i386
* glade2.i386
* and gcc, make, cvs, gnuplot, imagemagik...

Then you need [http://packages.debian.org/unstable/source/alien alien] tool to convert packages from the paparazzi repository:
* ivy-c
* ivy-c-dev
* ivy-ocaml (WARNING: debian and fedora have different path for ocaml (/usr/lib/ocaml/<version> vs. /usr/lib/ocaml), so you need to move by hand the files in /usr/lib/ocaml/<version> to /usr/lib/ocaml)
* lpc21isp

== Installing the Source Code (not needed with paparazzi-bin) ==
After the <tt>paparazzi-dev</tt> package is installed the complete source code should be downloaded from the CVS repository. See the [http://savannah.nongnu.org/cvs/?group=paparazzi project page] at Savannah for more details. From the directory of your choice type:
cvs -z3 -d:pserver:anonymous@cvs.savannah.nongnu.org:/sources/paparazzi co paparazzi3
This will download all of the code and install it into <tt>paparazzi3/</tt>

If you cannot use the CVS install, dayly updated tarballs can also be fetched from the [[Downloads|Downloads]] page.

== Launching the Software ==

If you are using the <tt>paparazzi-bin</tt> package or the Live-CD, just launch the <tt>paparazzi</tt> binary application and you will be guided through the installation of your personal configuration files.

If you are using the source code, the first step is to compile it. From the <tt>paparazzi3</tt> directory (<tt>cd paparazzi3</tt>), run

make

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

./paparazzi

From the [[Paparazzi_Center|Paparazzi Center]] interface, select the ''MJ5'' aircraft, select the ''sim'' target and ''Build'' it. Then ''Execute'' the ''Simulation'' session.

If ('''and only if''') you want to directly launch some Paparazzi agents (the ''Tools'' of the [[Paparazzi_Center|Paparazzi Center]]), 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|/home/your_username/.bashrc|
export PAPARAZZI_HOME<nowiki>=</nowiki>''your paparazzi3 directory''
export PAPARAZZI_SRC<nowiki>=</nowiki>''your paparazzi3 directory''
}}
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:
export PAPARAZZI_HOME=`pwd`;export PAPARAZZI_SRC=`pwd`
Verify that your variables are set correctly with the following command:
env | grep PAPARAZZI
which should return the following:
PAPARAZZI_HOME<nowiki>=</nowiki>''your paparazzi3 directory''
PAPARAZZI_SRC<nowiki>=</nowiki>''your paparazzi3 directory''

== Setting access rights for USB download ==

This may be required to flash the Paparazzi-boards directly thru USB. For flashing details, see [[Compiling]].

Default linux rights may not allow standard (non root) users to directly access the USB bus. You will need to make yourself a member of the plugdev "group" and then create a "rule", associated with that "group". <br>
Make yourself a member of the ''plugdev'' group:

sudo adduser <your login> plugdev

Logout and login again. Then add the appropriate rule (available ine fhe file ''10-paparazzi.rules'') to the USB handler. Simply copy as root <tt>$PAPARAZZI_HOME/conf/system/udev/rules/10-paparazzi.rules</tt> to <tt>/etc/udev/rules.d/</tt>

sudo cp $PAPARAZZI_HOME/conf/system/udev/rules/10-paparazzi.rules /etc/udev/rules.d/

== Software Updates ==
Paparazzi is a very rapidly evolving project and as such, you will find that variables and functions are frequently added, changed, or removed. 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. Your airframe file will not be updated by the CVS system and therefore any new or modified variable names will need to be added manually. The compiler will usually identify the problem variables at which point you can look at some of the most recent airframe files on the CVS to find the proper syntax. See the [[Compiling]] page for more help if needed.
<br>
That said, keeping your software up to date is easy with the CVS system. The system will compare all source code files with the server and update any that are needed, automatically merging any minor changes that you have incorporated along the way.

To download and automatically merge any updated source files, run the following command from your Paparazzi directory
cvs update -d
where the <tt>-d</tt> is needed to get any new directories.

After any CVS update or source code modification the code can be recompiled from ''your paparazzi3 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 deleted all compiled files and recompile from scratch with the following commands:

make clean
make

See the [[Compiling]] page for more info.

Users making changes to their code structure may prefer to have more control over the updating and merging process and may wish to install and use '''tkcvs''' instead which provides highlighted comparisons of any files that differ between your code and the CVS server and allows for a file by file update.

To update your Linux distribution as well as any dependencies of Paparazzi (seldom necessary), run the following as root:
apt-get update
apt get upgrade

== LiveCd ==

The LiveCD is an easy way to test Paparazzi: no installation is required and no changes are made to your computer. Simply burn the image as a boot CD and reboot! The LiveCD includes Linux and the complete paparazzi binary package (code source, tools and cross compilers). It is intended for demonstration only and not frequently updated but it contains the complete system and can store changed files on a pen drive or compressed file on your hard drive so that it can compile, flash, and operate any aircraft, albeit slowly.

The CD image is available from the [[Downloads|Downloads]] page.

The Paparazzi demo is launchable on the Live CD from the Paparazzi icon.

Knoppix allows for all the user data to be saved on a hard disk partition (most file systems are supported) or on a removable device (typically a USB pendrive). Note that this action is not destructive: the user data tree is compressed and stored on your file system as a single file (<tt>knoppix.img</tt>).
* From the Knoppix menu (second from bottom left), choose '''Configure''', '''Create a persistent KNOPPIX disk image'''
* Choose your media (be sure to connect your USB pendrive before booting!)
* Choose if you want an encrypted filesystem (to protect your flight plan designed for the next MAV competition :-) )
* Choose the size of your home directory (100Mb is recommended)
On the next reboot, this saved state will be automatically located and loaded.

Using this persistent feature, the Paparazzix Live CD can really be used to configure, simulate and fly an aircraft with the Paparazzi system.

The Live CD can also be used to install a Debian system on the hard disk, using the <tt>knoppix-installer</tt> command. Be sure to backup the hard disk before trying ...

[[Image:Lightscribe_CD_Cover_1.JPG|thumb|320px|LightScribe CD Cover]] A LiveCD needs some looks... In color or in LightScribe format, your CD will always look cool.
* Get the PDF version for download here [http://paparazzi.enac.fr/wiki_images/Lightscribe_CD_Cover_1.pdf LightScribe CD Cover 1].

* The LightScribe version is in Nero Cover Design format (.ncd) and it's here for download [http://paparazzi.enac.fr/wiki_images/Lightscribe_CD_Cover_1.zip LightScribe CD Cover 1]

Airframe Configuration

2008-09-11T21:36:20Z

Rcbrother: /* Infrared */

The airframe configuration file is located in <tt>conf/airframes</tt> and contains
all the hardware and software settings for an aircraft. This is an [http://en.wikipedia.org/wiki/Xml XML] document containing some [http://en.wikipedia.org/wiki/Makefile Makefile] code at the bottom. All gains, trims, and behavior settings are defined with standard XML elements. The hardware definitions such as processor type, modem protocol, servo driver, etc. are contained in the makefile raw section.

== Selecting the Airframe File ==
Each airframe file must be assigned a name, unique ID, flight plan, etc. in [[Conf.xml|<tt>conf/conf.xml</tt>]] as follows:
<?xml version="1.0"?>
<conf>
<aircraft
name="Twin1"
ac_id="1"
airframe="airframes/twinstar1.xml"
radio="radios/mc3030.xml"
flight_plan="flight_plans/mav05_cw.xml"
telemetry="telemetry/default.xml"
gui_color="blue"
/>
<aircraft
name="Plaster"
ac_id="2"
airframe="airframes/plaster1.xml"
radio="radios/cockpitMM.xml"
telemetry="telemetry/default.xml"
flight_plan="flight_plans/dummy.xml"
/>
.
.
.
</conf>
Then, to compile and flash the airframe settings and associated flight plan to your autopilot, simply select the appropriate A/C and target in the [[Paparazzi_Center|Paparazzi Center]] or specify your airframe name in the flash command typed from the prompt:
make AIRCRAFT=<b>Twin1</b> ap.upload
More information can be found on the [[Conf.xml|conf.xml]] page

== XML Parameters ==
=== Commands ===

The <b><tt>commands</tt></b> lists the abstract commands you need to control the aircraft. In our example, we have only three:
<tt>
<commands>
<axis name="THROTTLE" failsafe_value="0"/>
<axis name="ROLL" failsafe_value="0"/>
<axis name="PITCH" failsafe_value="0"/>
</commands></tt>
Each command is associated with a failsafe value which will be used if no controller is active (during initialization for example). The range of these values is [-9600:9600]. Note that these commands do not necessarily match the servo actuators. For example, the ROLL command is typically linked to two aileron actuators.

=== Servos ===

The above commands get translated to the <b><tt>servos</tt></b> here. In this example we use two ailevons (surfaces used for both pitch and roll as on a flying wing) and a motor. These are listed in the <b><tt>servos</tt></b> section:
<tt>
<servos>
<servo name="THROTTLE" no="0" min="1000" neutral="1000" max="2000"/>
<servo name="AILEVON_LEFT" no="1" min="2000" neutral="1500" max="1000"/>
<servo name="AILEVON_RIGHT" no="2" min="1000" neutral="1500" max="2000"/>
</servos></tt>
where names are associated to the corresponding servo channel number on the autopilot and the neutral value, total range and direction are defined. Min/max/neutral values are expressed in milliseconds and the direction of travel can be reversed by exchanging min with max (as in <tt>"AILEVON_LEFT"</tt>, above). The ''standard'' travel for a hobby servo is 1000ms - 2000ms with a 1500ms neutral. Trim can be added by changing this neutral value, and absolute 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>. Note the following tips:
* Reverse the servo direction by exchanging min/max
* Trim should always be adjusted mechanically if possible to avoid asymetrical travel
* Any reduction of the total travel range should be done mechanically to maintain precision
* Many servos will respond well to values slightly outside the normal 1000-2000ms range but experiment carefully as the servo may not operate reliably outside this range and may even suffer permanent damage.

The <b><tt>servos</tt></b> are then linked to the commands in the <b><tt>command_laws</tt></b> section:
<tt>
<command_laws>
<let var="aileron" value="@ROLL * 0.3"/>
<let var="elevator" value="@PITCH * 0.7"/>
<set servo="THROTTLE" value="@THROTTLE"/>
<set servo="AILEVON_LEFT" value="$elevator + $aileron"/>
<set servo="AILEVON_RIGHT" value="$elevator - $aileron"/>
</command_laws></tt>
[[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. Ailevon 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.

=== Manual ===
The <tt>rc_command</tt> sections links the channels of the RC transmitter (defined in the [[Radio_Control|Radio Control]] file) to the <tt>commands</tt> defined above:

<rc_commands>
<set command="THROTTLE" value="@THROTTLE"/>
<set command="ROLL" value="@ROLL"/>
<set command="PITCH" value="@PITCH"/>
</rc_commands>

This example looks trivial since the channel values have the same name than the commands.

=== Auto1 ===
The next section, named <b><tt>AUTO1</tt></b>, gives the maximum roll and pitch (in radians) allowed for the augmented stability mode.
<tt>
<section name="AUTO1" prefix="AUTO1_">
<define name="MAX_ROLL" value="RadOfDeg(35)"/>
<define name="MAX_PITCH" value="RadOfDeg(35)"/>
</section>
</tt>
<br>

=== ADC ===
In the "adc" section, you will find the correspondance between arguments and their assigned pins on the autopilot board.
<section name="adc" prefix="ADC_CHANNEL_">
<define name="IR1" value="ADC_1"/>
<define name="IR2" value="ADC_2"/>
<define name="IR_TOP" value="ADC_0"/>
</section>
'''Important note''': To ''activate'' an ADC entry, a flag must be defined in the <tt>makefile</tt> section. For the previous example, we would have to write:

ap.CFLAGS += -DADC -DUSE_ADC_0 -DUSE_ADC_1 -DUSE_ADC_2

=== Infrared ===
The <b><tt>INFRARED</tt></b> section describes the configuration of the infrared sensors.

The first definitions are relative to the electronic neutral of the sensors (a sensor here is a pair of thermopiles). A perfect sensor should give 512 if it measures the same value on both sides.

<section name="INFRARED" prefix="IR_">
<define name="ADC_IR1_NEUTRAL" value="512"/>
<define name="ADC_IR2_NEUTRAL" value="512"/>
<define name="ADC_TOP_NEUTRAL" value="512"/>

These neutrals are tuned with the "cupboard test": Put the sensor in a close box (a cupboard) and read the values of the IR_SENSORS message (ir1, ir2 and vertical). Set the neutrals (they are subtracted from the measurement) to get null values. E.g. if you read 5 for the ir1 value with ADC_IR1_NEUTRAL equal to 512, change the latter to 517.

The next lines define the installation of the horizontal and vertical sensors. The vertical sensor must give a positive value when the temperature under the aircraft is higher than the temperature above. The two channels of the horizontal sensor must give positive values when it is warmer on the right side and the rear side. To adjust these signs, use the following declarations:

<define name="IR2_SIGN" value="-1"/>
<define name="TOP_SIGN" value="-1"/>

Then, define how the horizontal sensor is connected to the airframe, orientation '''aligned''' or '''tilted'''. In the aligned case, ir'''1''' is along the lateral axis and ir'''2''' along the longitudian one. In the '''tilted''' case, the sensors are tilted by 45 degrees; ir'''1''' is along rear-left -- front-right, and ir'''2''' along rear-right -- front-left. A value of "0" indicates x-y sensor is aligned with the fueslage, a value of "1" indicates a 45 deg rotation. If the airframe construction allows choose an aligned sensor orientation since this gives the best stabilization response results.

<define name="HORIZ_SENSOR_TILTED" value="0"/>

The three axis must give similar values for similar contrasts. The following factors can be used to scale these values. For example with an horizontal tilted sensor, the following ratios are usually needed:

<define name="LATERAL_CORRECTION" value="0.7"/>
<define name="LONGITUDINAL_CORRECTION" value="0.7"/>
<define name="VERTICAL_CORRECTION" value="1."/>
Default values are 1.

It may be hard to align the horizontal sensor with the aircraft. A tuning in flight will be needed to adjust the following neutrals. Adjust the roll neutral to fly straight. Adjust the pitch neutral to fly level with the desired throttle.
<define name="ROLL_NEUTRAL_DEFAULT" value="-2.5" unit="deg"/>
<define name="PITCH_NEUTRAL_DEFAULT" value="6" unit="deg"/>

Finally, an asymmetric (left/right, front/rear) correction can be added with a last set of factors.
<define name="CORRECTION_UP" value="1."/>
<define name="CORRECTION_DOWN" value="1."/>
<define name="CORRECTION_LEFT" value="1."/>
<define name="CORRECTION_RIGHT" value="1."/>
</section>
These corrections are set on the angles.

=== Gyro ===
Defines the type of gyro installed, each axis neutral, and any required temperature compensation. If the gyro has two axes, the pitch neutral is defined as well. Many gyros output their internal temperature and require a temperature-dependent linear correction be made to the neutral value. No correction is done for the temperature in this example.(<b><tt>ADC_TEMP_SLOPE=0</tt></b>).

<tt>
<section name="GYRO" prefix="GYRO_"
<define name="ADC_ROLL_COEFF" value="1"/>
<define name="ROLL_NEUTRAL" value="500"/>
<define name="ADC_TEMP_NEUTRAL" value="476"/>
<define name="ADC_TEMP_SLOPE" value="0"/>
</section>
</tt>

=== Bat ===
This section give characteristics for the monitoring of the main power battery. <b><tt>MILLIAMP_PER_PERCENT</tt></b> represents the consumption (in mA) for one percent of THROTTLE and for one time unit. It is used to compute the <tt>energy</tt> value of the <tt>BAT</tt> message.

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. This definition is optional with a default value of 12.5V.

<tt>
<section name="BAT">
<define name="MILLIAMP_PER_PERCENT" value="0.86"/>
<define name="VOLTAGE_ADC_A" value="0.0177531"/>
<define name="VOLTAGE_ADC_B" value="0.173626"/>
<define name="VoltageOfAdc(adc)" value ="(VOLTAGE_ADC_A * adc + VOLTAGE_ADC_B)"/>
<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>
</tt>

=== Horizontal Control ===
<tt>
<section name="HORIZONTAL CONTROL" prefix="H_CTL_">
<define name="COURSE_PGAIN" value="-0.4"/>
<define name="ROLL_MAX_SETPOINT" value="0.35" unit="radians"/>
<define name="ROLL_ATTITUDE_GAIN" value="-7500."/>
<define name="ROLL_RATE_GAIN" value="-1500"/>
<define name="PITCH_PGAIN" value="-8000."/>
<define name="ELEVATOR_OF_ROLL" value="1250"/>
</section>
</tt>

The outer loop acts on the route. It will produce a roll command from a course setpoint and a course measurement. The COURSE_PGAIN parameter is the factor multiplied by the course error (in radian) to get a roll setpoint (in radian). So if the plane is expected to go north (course=0) and is actually flying to 57 degrees (course=1 radian, i.e. ENE), with a gain of '''-0.4''', a roll of -0.4 (23 degrees) will be set for the lower control loop.

The ROLL_ATTITUDE_GAIN is used to compute a ROLL command from the roll error (setpoint minus measurement). If a gyro in installed, the ROLL_RATE_GAIN to keep a null roll rate. So these two gains provide a P-D controller.

===Vertical Control===

<section name="VERTICAL CONTROL" prefix="V_CTL_">

<define name="ALTITUDE_PGAIN" value="-0.1" unit="(m/s)/m"/>

<define name="ALTITUDE_MAX_CLIMB" value="3." unit="m/s"/>
These lines are associated with vertical control loops contained in ./sw/airborne/fw_v_ctl.c. These are outer loop parameters that calculate a desired climb rate based on altitude error. Here, if the altitude error is 10m, the climb setpoint will be set to 1m/s. ALTITUDE_MAX_CLIMB is a bounded value (in m/s) so that the outer loop does not calculate too large of a climb rate
<define name="AUTO_THROTTLE_NOMINAL_CRUISE_THROTTLE" value="0.65" unit="%"/>
<define name="AUTO_THROTTLE_MIN_CRUISE_THROTTLE" value=".4" unit="%"/>
<define name="AUTO_THROTTLE_MAX_CRUISE_THROTTLE" value="1" unit="%"/>
<define name="AUTO_THROTTLE_LOITER_TRIM" value="1000" unit="pprz_t"/>
<define name="AUTO_THROTTLE_DASH_TRIM" value="-2500" unit="pprz_t"/>
<define name="AUTO_THROTTLE_CLIMB_THROTTLE_INCREMENT" value="0.15" unit="%/(m/s)"/>
<define name="AUTO_THROTTLE_PGAIN" value="-0.008" unit="%/(m/s)"/>
<define name="AUTO_THROTTLE_IGAIN" value="0.25"/>
<define name="AUTO_THROTTLE_PITCH_OF_VZ_PGAIN" value="0.35" unit="rad/(m/s)"/>

These lines are associated with vertical rate control loops contained in ./sw/airborne/fw_v_ctl.c and are used by default in most cases. The default vertical control law is for the vertical rate to be managed by a combination of throttle and pitch.

<define name="AUTO_PITCH_PGAIN" value="-0.1"/>
<define name="AUTO_PITCH_IGAIN" value="0.025"/>
<define name="AUTO_PITCH_MAX_PITCH" value="0.5"/>
<define name="AUTO_PITCH_MIN_PITCH" value="-0.5"/>

These lines are associated with vertical control loops contained in ./sw/airborne/fw_v_ctl.c but are not used in default. The non-default vertical control law is for the vertical rate to be managed by the pitch.

<define name="THROTTLE_SLEW_LIMITER" value="2" unit="s"/>
THROTTLE_SLEW_LIMITER is the required time is seconds to change throttle from 0% to 100%.

=== Misc ===
<tt>
<section name="MISC">
<define name="NOMINAL_AIRSPEED" value ="12." unit="m/s">
<define name="CARROT" value="5." unit="s"/>
<define name="KILL_MODE_DISTANCE" value="(1.5*MAX_DIST_FROM_HOME)"/>
<define name="CONTROL_RATE" value"60" unit="Hz"/>
</section>
</tt>

* The "NOMINAL_AIRSPEED" is mainly used in the simulator.
* "CARROT" gives the distance (in seconds, so ground speed is taken into account) between the carrot and the aircraft.
* "KILL_MODE_DISTANCE" is the threshold distance to switch the autopilot into KILL mode (defined descent with no throttle)
* "CONTROL_RATE" is the rate of the low level control loops in Hertz (60 or 20).

== Hardware definitions - Makefile ==

The airframe file must include the description of the controller board and it's low-level settings. This is done in one <b><tt>makefile</tt></b> section starting with the autopilot model and flashing mode:
{{Box Code|conf/airframes/myplane.xml|
<makefile>
include $(PAPARAZZI_SRC)/conf/autopilot/tiny.makefile
<nowiki>FLASH_MODE=IAP</nowiki>
.
.
.
</makefile>
}}
Below this are the definintions and configuration of the peripherals and interfaces.

=== R/C ===

{{Box Code|conf/airframes/myplane.xml|
<nowiki>ap.CFLAGS += -DRADIO_CONTROL -DRADIO_CONTROL_TYPE=RC_FUTABA</nowiki>
<nowiki>ap.EXTRA_SRCS += radio_control.c $(SRC_ARCH)/ppm_hw.c</nowiki>
<nowiki>ap.CFLAGS += -DACTUATORS=\"servos_direct_hw.h\"</nowiki>
<nowiki>ap.EXTRA_SRCS += $(SRC_ARCH)/servos_direct_hw.c</nowiki>
}}

You can set RADIO_CONTROL_TYPE to RC_FUTABA, for falling edge PPM, or RC_JR for rising edge PPM. "RC_FUTABA" is for The Futaba or compatible brands, and "RC_JR" for JR (a.k.a Graupner outside of the USA) or compatible brands.

For the classix, you must specify which pins to use for PWM by adding "-DPWM_SERVO_0, etc." to the line fbw.CFLAGS. This activate the PWM channel.

<tt>wiring on classix PWM connector
connector LPC shared port
PWM1 PWM5 AD1_6 CAP1_3 P0.21
PWM2 PWM3 RXD0 EINT0 P0.1
PWM3 PWM1 TXD0 P0.0
PWM4 PWM6 RXD1 EINT3 P0.9
PWM5 PWM4 TXD1 AD1_1 P0.8
PWM6 PWM2 SSEL0 EINT2 P0.7</tt>

PWM1 and PWM6 should be safe. PWM4 and PWM5 should be OK if you're not using UART1 on the FBW processor - same for PWM2 and PWM3 if you're not using UART0 (disable FBW telemetry for that ).

=== 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 <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.

Paparazzi supports the following modem protocols:
* Standard transparent serial (pprz) - this is compatible with all modems and can be used to connect the autopilot directly to a PC for testing without a modem.
* Maxstream API protocol (xbee) - compatible with all Maxstream modems including the 9XTend and Zigbee. This protocol enables hardware addressing, allowing multiple aircraft to be managed from a single ground modem.
* Coronis Wavecard - necessary for operation with the unusual Coronis Wavecard modem.
Select the baud/protocol in the airframe file by commenting/uncommenting the appropriate section as follows:
==== Configuring The Serial Protocol ====
New users are advised to start with the standard serial protocol before attempting to setup an addressed API link. There are no real reasons for the novice user to use the xbee protocol over the standard PPRZTransport. Even if you are using a Maxstream modem you should still start out with the standard. Lastly it should be pointed out that using a single UAV there is no disadvantage and that the [http://www.engr.usu.edu/wiki/index.php/OSAM OSAM] Paparazzi Team at UAS 2008 took second place using the STANDARD protocol. The serial protocol works with virtually any modem as well as direct cable connections. The baud rates of the airborne modem, autopilot, ground modem, and PC must be configured correctly. The PC and autopilot serial ports do not need to be set to the same baud rate, i.e. when running multiple aircraft from a single ground modem, the ground modem may require a higher baud rate than any of the airborne modems in order to stream the data from multiple simultaneous sources.

{{Box Code|conf/airframes/myplane.xml|
<nowiki>
<section name="DATALINK" prefix="DATALINK_">
<define name="DEVICE_TYPE" value="PPRZ"/>
<define name="DEVICE_ADDRESS" value="...."/>
</section>
</nowiki>
}}
The above example tells the autopilot to send and recieve data in standard serial form.

{{Box Code|conf/airframes/myplane.xml - makefile section at the bottom|
# Serial modem
<nowiki>ap.CFLAGS += -DDOWNLINK -DUSE_UART0 -DDOWNLINK_TRANSPORT=PprzTransport -DDOWNLINK_FBW_DEVICE=Uart0 -DDOWNLINK_AP_DEVICE=Uart0 -DPPRZ_UART=Uart0 -DDATALINK=PPRZ -DUART0_BAUD=B57600</nowiki>
<nowiki>ap.srcs += downlink.c $(SRC_ARCH)/uart_hw.c datalink.c pprz_transport.c</nowiki>
}}
The above example configures the autopilot serial port (Uart0) to 57,600 baud and calls the serial transport protocol (pprz_transport.c). Use the "#" symbol to comment lines in this section of the airframe file.
<br>
Note:
* The autopilot and modem serial port baud rates must match at all times and also must match the ground modem rate, check your modem documentation to find the default baud rate and configure a different rate as needed.

<br style="clear:both>

Ensure that the ground station is using the same protocol and an equal or higher baud rate:
{{Box Code|conf/control_panel.xml|
<nowiki>
<session name="USB">
<program name="link">
<arg flag="-d" constant="/dev/paparazzi/ttyUSB0"/>

<arg flag="-uplink" constant=""/>
<arg flag="-s" constant="57600"/>
</program>
...
</session>
</nowiki>
}}
Use this constant /dev/paparazzi/ttyUSB0 when using either the ftdi cable or a Maxstream USB ground modem.. Otherwise use /dev/ttyUSB0 (the ttyUSB0 being the device that you are using. Note: it might not always be ttyUSB0). This paparazzi directory in the dev folder is created when setting the udev rules. [http://paparazzi.enac.fr/wiki/index.php/Installation#Setting_access_rights_for_USB_download Setting Udev rules]

==== Configuring The Maxstream API Protocol ====
The optional API protocol enables hardware addressing so that multiple aircraft can be managed from a single ground modem, or multiple aircraft and multiple ground stations can work simultaneously without interference from one another. API mode is enabled by sending an escape sequence (+++) followed by AT commands, this can be done automatically at each boot or can be permanently configured with the "ATWR" command for greater reliability.

{{Box Code|conf/airframes/myplane.xml|
<nowiki>
<section name="MISC">
...
<define name="XBEE_INIT" value="\"ATPL2\rATRN1\rATTT80\r\ATBD6\rATWR\r\""/>
<define name="NO_XBEE_API_INIT" value="FALSE"/>
...
</section></nowiki>
}}
The above example will program the Maxstream to API mode, 100mW power (ATPL2), 57600 baud (ATBD6), and permanently store the changes (ATWR). After flashing allow 30 seconds for the modem to store the changes, then disable the init string <tt><define name="NO_XBEE_API_INIT" value="<b>TRUE</b>"/></tt>, update the baud rate as needed, and re-flash the autopilot. The modem and autopilot serial port baud rates must match eachother at all times.
<br>
Notes:
* Maxtream modems are factory configured for 9600 baud, in order to change baud rates, first configure the autopilot serial port to match the modem (DUART0_BAUD=B9600), boot the system so that the baud rate change command is sent to the modem (ATBD6) and permanently saved (ATWR), allow 30 seconds for the modem configuration to complete, then reprogram the autopilot with the new baud rate (DUART0_BAUD=B57600) and disabled modem configuration string <tt><define name="NO_XBEE_API_INIT" value="<b>TRUE</b>"/> </tt>.
* The ac_id defined in <tt>conf/conf.xml</tt> is permanently programmed into the modem so this procedure would need to be re-run if the modem is moved to another plane.
* For temporary boot-time API configuration remove any baud rate changes, remove <tt>ATWR\r</tt> from the end of the string and keep "NO_XBEE_API_INIT" value="FALSE".
* Upgrade your Maxstream firmware to the latest version before attempting API mode operation.

<br style="clear:both>

{{Box Code|confAgain/airframes/myplane.xml - makefile section at the bottom|
<nowiki># Maxstream API protocol</nowiki>
<nowiki>ap.CFLAGS += -DDOWNLINK -DUSE_UART0 -DDOWNLINK_TRANSPORT=XBeeTransport -DDOWNLINK_FBW_DEVICE=Uart0 -DDOWNLINK_AP_DEVICE=Uart0 -DXBEE_UART=Uart0 -DDATALINK=XBEE -DUART0_BAUD=B57600</nowiki>
<nowiki>ap.srcs += downlink.c $(SRC_ARCH)/uart_hw.c datalink.c xbee.c</nowiki>
}}
The above example configures the autopilot serial port (Uart0) to 57,600 baud and calls the Maxstream transport protocol (xbee.c). Use the "#" symbol to comment lines in this section of the airframe file.
<br style="clear:both>

Ensure that the ground station is using the same protocol and an equal or higher baud rate:
{{Box Code|conf/control_panel.xml|
<nowiki>
<session name="USB">
<program name="link">
<arg flag="-d" constant="/dev/paparazzi/ttyUSB0"/>
<arg flag="-transport" constant="xbee"/>
<arg flag="-uplink" constant=""/>
<arg flag="-s" constant="57600"/>
</program>
...
</session>
</nowiki>
}}
Use this constant /dev/paparazzi/ttyUSB0 when using either the ftdi cable or a Maxstream USB ground modem.. Otherwise use /dev/ttyUSB0 (the ttyUSB0 being the device that you are using. Note: it might not always be ttyUSB0). This paparazzi directory in the dev folder is created when setting the udev rules. [http://paparazzi.enac.fr/wiki/index.php/Installation#Setting_access_rights_for_USB_download Setting Udev rules]
=====Alternate Method=====
This is the way it is done in funjet1.xml and has been tested to work by Danstah

{{Box Code|conf/airframes/funjet1.xml|
<nowiki>
<section name="MISC">
...
<define name="XBEE_INIT" value="\"ATPL2\rATRN1\rATTT80\r\""/>

...
</section></nowiki>
}}
Also use this
{{Box Code|conf/airframes/funjet1.xml|
<nowiki>

<section name="DATALINK" prefix="DATALINK_">
<define name="DEVICE_TYPE" value="XBEE"/>
<define name="DEVICE_ADDRESS" value="...."/>
</section>
</nowiki>
}}
And Finally use this in the makefile section
{{Box Code|conf/airframes/funjet1.xml|
<nowiki>
ap.CFLAGS += -DDOWNLINK -DUSE_UART1 -DDOWNLINK_TRANSPORT=XBeeTransport -DXBEE_UART=Uart1 -DDATALINK=XBEE -DUART1_BAUD=B9600
ap.srcs += downlink.c $(SRC_ARCH)/uart_hw.c datalink.c xbee.c
</nowiki>
}}
By reading all the information above you should be able to infer what the above does

Now keep in mind that the ground modem baud rate and airplanes modem baud rates do not have to match. The only things that need to match are the the modem on the planes baud rate and the rate defined in the airframe file. For example this planes modem is set to 9600 and this could be used with the ground modem configured above using 57600...
Also for multiple UAV's a good way to configure them is to use 9600 for the ap and use a ground modem configured to 57600 and its not a bad idea to use minimal telemetry

=== 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:

{{Box Code|conf/airframes/myplane.xml|
<nowiki>ap.CFLAGS += -DGPS -DUBX -DUSE_UART1 -DGPS_LINK=Uart1 -DUART1_BAUD=B38400</nowiki>
<nowiki>ap.srcs += gps_ubx.c gps.c</nowiki>
}}
'''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 thru the [[Compiling#USB_flashing|UART Tunnel]] and [[GPS#GPS_configuration_using_U-Center Configured with|u-center]]

=== Sensors ===

=== Control loops ===

The control loops can be divided in two largely independent groups : the vertical ones and the horizontal ones (files sw/airborne/fw_h_ctl.c and sw/airborne/fw_v_ctl.c ). Those loops can be commanded at different levels by either the R/C transmitter or the autonomous navigation routine.

First the horizontal loop:
{{Box Code|conf/airframes/funjet1.xml|
<nowiki>ap.CFLAGS += -DNAV -DAGR_CLIMB -DLOITER_TRIM
ap.srcs += nav.c fw_h_ctl.c fw_v_ctl.c
</nowiki>
}}

== Radio Control ==
The Paparazzi autpilot interfaces directly with the PWM signal from any standard hobby R/C receiver. Signal decoding configuration settings for this are stored in the [[Radio_Control|Radio Control]] file.

Airframe Configuration

2008-09-11T21:10:36Z

Rcbrother: /* R/C */

The airframe configuration file is located in <tt>conf/airframes</tt> and contains
all the hardware and software settings for an aircraft. This is an [http://en.wikipedia.org/wiki/Xml XML] document containing some [http://en.wikipedia.org/wiki/Makefile Makefile] code at the bottom. All gains, trims, and behavior settings are defined with standard XML elements. The hardware definitions such as processor type, modem protocol, servo driver, etc. are contained in the makefile raw section.

== Selecting the Airframe File ==
Each airframe file must be assigned a name, unique ID, flight plan, etc. in [[Conf.xml|<tt>conf/conf.xml</tt>]] as follows:
<?xml version="1.0"?>
<conf>
<aircraft
name="Twin1"
ac_id="1"
airframe="airframes/twinstar1.xml"
radio="radios/mc3030.xml"
flight_plan="flight_plans/mav05_cw.xml"
telemetry="telemetry/default.xml"
gui_color="blue"
/>
<aircraft
name="Plaster"
ac_id="2"
airframe="airframes/plaster1.xml"
radio="radios/cockpitMM.xml"
telemetry="telemetry/default.xml"
flight_plan="flight_plans/dummy.xml"
/>
.
.
.
</conf>
Then, to compile and flash the airframe settings and associated flight plan to your autopilot, simply select the appropriate A/C and target in the [[Paparazzi_Center|Paparazzi Center]] or specify your airframe name in the flash command typed from the prompt:
make AIRCRAFT=<b>Twin1</b> ap.upload
More information can be found on the [[Conf.xml|conf.xml]] page

== XML Parameters ==
=== Commands ===

The <b><tt>commands</tt></b> lists the abstract commands you need to control the aircraft. In our example, we have only three:
<tt>
<commands>
<axis name="THROTTLE" failsafe_value="0"/>
<axis name="ROLL" failsafe_value="0"/>
<axis name="PITCH" failsafe_value="0"/>
</commands></tt>
Each command is associated with a failsafe value which will be used if no controller is active (during initialization for example). The range of these values is [-9600:9600]. Note that these commands do not necessarily match the servo actuators. For example, the ROLL command is typically linked to two aileron actuators.

=== Servos ===

The above commands get translated to the <b><tt>servos</tt></b> here. In this example we use two ailevons (surfaces used for both pitch and roll as on a flying wing) and a motor. These are listed in the <b><tt>servos</tt></b> section:
<tt>
<servos>
<servo name="THROTTLE" no="0" min="1000" neutral="1000" max="2000"/>
<servo name="AILEVON_LEFT" no="1" min="2000" neutral="1500" max="1000"/>
<servo name="AILEVON_RIGHT" no="2" min="1000" neutral="1500" max="2000"/>
</servos></tt>
where names are associated to the corresponding servo channel number on the autopilot and the neutral value, total range and direction are defined. Min/max/neutral values are expressed in milliseconds and the direction of travel can be reversed by exchanging min with max (as in <tt>"AILEVON_LEFT"</tt>, above). The ''standard'' travel for a hobby servo is 1000ms - 2000ms with a 1500ms neutral. Trim can be added by changing this neutral value, and absolute 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>. Note the following tips:
* Reverse the servo direction by exchanging min/max
* Trim should always be adjusted mechanically if possible to avoid asymetrical travel
* Any reduction of the total travel range should be done mechanically to maintain precision
* Many servos will respond well to values slightly outside the normal 1000-2000ms range but experiment carefully as the servo may not operate reliably outside this range and may even suffer permanent damage.

The <b><tt>servos</tt></b> are then linked to the commands in the <b><tt>command_laws</tt></b> section:
<tt>
<command_laws>
<let var="aileron" value="@ROLL * 0.3"/>
<let var="elevator" value="@PITCH * 0.7"/>
<set servo="THROTTLE" value="@THROTTLE"/>
<set servo="AILEVON_LEFT" value="$elevator + $aileron"/>
<set servo="AILEVON_RIGHT" value="$elevator - $aileron"/>
</command_laws></tt>
[[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. Ailevon 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.

=== Manual ===
The <tt>rc_command</tt> sections links the channels of the RC transmitter (defined in the [[Radio_Control|Radio Control]] file) to the <tt>commands</tt> defined above:

<rc_commands>
<set command="THROTTLE" value="@THROTTLE"/>
<set command="ROLL" value="@ROLL"/>
<set command="PITCH" value="@PITCH"/>
</rc_commands>

This example looks trivial since the channel values have the same name than the commands.

=== Auto1 ===
The next section, named <b><tt>AUTO1</tt></b>, gives the maximum roll and pitch (in radians) allowed for the augmented stability mode.
<tt>
<section name="AUTO1" prefix="AUTO1_">
<define name="MAX_ROLL" value="RadOfDeg(35)"/>
<define name="MAX_PITCH" value="RadOfDeg(35)"/>
</section>
</tt>
<br>

=== ADC ===
In the "adc" section, you will find the correspondance between arguments and their assigned pins on the autopilot board.
<section name="adc" prefix="ADC_CHANNEL_">
<define name="IR1" value="ADC_1"/>
<define name="IR2" value="ADC_2"/>
<define name="IR_TOP" value="ADC_0"/>
</section>
'''Important note''': To ''activate'' an ADC entry, a flag must be defined in the <tt>makefile</tt> section. For the previous example, we would have to write:

ap.CFLAGS += -DADC -DUSE_ADC_0 -DUSE_ADC_1 -DUSE_ADC_2

=== Infrared ===
The <b><tt>INFRARED</tt></b> section describes the configuration of the infrared sensors.

The first definitions are relative to the electronic neutral of the sensors (a sensor here is a pair of thermopiles). A perfect sensor should give 512 if it measures the same value on both sides.

<section name="INFRARED" prefix="IR_">
<define name="ADC_IR1_NEUTRAL" value="512"/>
<define name="ADC_IR2_NEUTRAL" value="512"/>
<define name="ADC_TOP_NEUTRAL" value="512"/>

These neutrals are tuned with the "cupboard test": Put the sensor in a close box (a cupboard) and read the values of the IR_SENSORS message (ir1, ir2 and vertical). Set the neutrals (they are subtracted from the measurement) to get null values. E.g. if you read 5 for the ir1 value with ADC_IR1_NEUTRAL equal to 512, change the latter to 517.

The next lines define the installation of the horizontal and vertical sensors. The vertical sensor must give a positive value when the temperature under the aircraft is higher than the temperature above. The two channels of the horizontal sensor must give positive values when it is warmer on the right side and the rear side. To adjust these signs, use the following declarations:

<define name="IR2_SIGN" value="-1"/>
<define name="TOP_SIGN" value="-1"/>

Then, define the orientation of the horizontal sensor, <tt>TILTED</tt> or <tt>ALIGNED</tt>. In the <tt>ALIGNED</tt> case, ir1 is along the lateral axis and ir2 along the longitudianl one. In the <tt>TILTED</tt> case, the sensors are tilted by 45 degrees; ir1 is along rear-left -- front-right, and ir2 along rear-right -- front-left.
<define name="HORIZ_SENSOR_TILTED" value="1"/>

The three axis must give similar values for similar contrasts. The following factors can be used to scale these values. For example with an horizontal tilted sensor, the following ratios are usually needed:

<define name="LATERAL_CORRECTION" value="0.7"/>
<define name="LONGITUDINAL_CORRECTION" value="0.7"/>
<define name="VERTICAL_CORRECTION" value="1."/>
Default values are 1.

It may be hard to align the horizontal sensor with the aircraft. A tuning in flight will be needed to adjust the following neutrals. Adjust the roll neutral to fly straight. Adjust the pitch neutral to fly level with the desired throttle.
<define name="ROLL_NEUTRAL_DEFAULT" value="-2.5" unit="deg"/>
<define name="PITCH_NEUTRAL_DEFAULT" value="6" unit="deg"/>

Finally, an asymmetric (left/right, front/rear) correction can be added with a last set of factors.
<define name="CORRECTION_UP" value="1."/>
<define name="CORRECTION_DOWN" value="1."/>
<define name="CORRECTION_LEFT" value="1."/>
<define name="CORRECTION_RIGHT" value="1."/>
</section>
These corrections are set on the angles.

=== Gyro ===
Defines the type of gyro installed, each axis neutral, and any required temperature compensation. If the gyro has two axes, the pitch neutral is defined as well. Many gyros output their internal temperature and require a temperature-dependent linear correction be made to the neutral value. No correction is done for the temperature in this example.(<b><tt>ADC_TEMP_SLOPE=0</tt></b>).

<tt>
<section name="GYRO" prefix="GYRO_"
<define name="ADC_ROLL_COEFF" value="1"/>
<define name="ROLL_NEUTRAL" value="500"/>
<define name="ADC_TEMP_NEUTRAL" value="476"/>
<define name="ADC_TEMP_SLOPE" value="0"/>
</section>
</tt>

=== Bat ===
This section give characteristics for the monitoring of the main power battery. <b><tt>MILLIAMP_PER_PERCENT</tt></b> represents the consumption (in mA) for one percent of THROTTLE and for one time unit. It is used to compute the <tt>energy</tt> value of the <tt>BAT</tt> message.

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. This definition is optional with a default value of 12.5V.

<tt>
<section name="BAT">
<define name="MILLIAMP_PER_PERCENT" value="0.86"/>
<define name="VOLTAGE_ADC_A" value="0.0177531"/>
<define name="VOLTAGE_ADC_B" value="0.173626"/>
<define name="VoltageOfAdc(adc)" value ="(VOLTAGE_ADC_A * adc + VOLTAGE_ADC_B)"/>
<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>
</tt>

=== Horizontal Control ===
<tt>
<section name="HORIZONTAL CONTROL" prefix="H_CTL_">
<define name="COURSE_PGAIN" value="-0.4"/>
<define name="ROLL_MAX_SETPOINT" value="0.35" unit="radians"/>
<define name="ROLL_ATTITUDE_GAIN" value="-7500."/>
<define name="ROLL_RATE_GAIN" value="-1500"/>
<define name="PITCH_PGAIN" value="-8000."/>
<define name="ELEVATOR_OF_ROLL" value="1250"/>
</section>
</tt>

The outer loop acts on the route. It will produce a roll command from a course setpoint and a course measurement. The COURSE_PGAIN parameter is the factor multiplied by the course error (in radian) to get a roll setpoint (in radian). So if the plane is expected to go north (course=0) and is actually flying to 57 degrees (course=1 radian, i.e. ENE), with a gain of '''-0.4''', a roll of -0.4 (23 degrees) will be set for the lower control loop.

The ROLL_ATTITUDE_GAIN is used to compute a ROLL command from the roll error (setpoint minus measurement). If a gyro in installed, the ROLL_RATE_GAIN to keep a null roll rate. So these two gains provide a P-D controller.

===Vertical Control===

<section name="VERTICAL CONTROL" prefix="V_CTL_">

<define name="ALTITUDE_PGAIN" value="-0.1" unit="(m/s)/m"/>

<define name="ALTITUDE_MAX_CLIMB" value="3." unit="m/s"/>
These lines are associated with vertical control loops contained in ./sw/airborne/fw_v_ctl.c. These are outer loop parameters that calculate a desired climb rate based on altitude error. Here, if the altitude error is 10m, the climb setpoint will be set to 1m/s. ALTITUDE_MAX_CLIMB is a bounded value (in m/s) so that the outer loop does not calculate too large of a climb rate
<define name="AUTO_THROTTLE_NOMINAL_CRUISE_THROTTLE" value="0.65" unit="%"/>
<define name="AUTO_THROTTLE_MIN_CRUISE_THROTTLE" value=".4" unit="%"/>
<define name="AUTO_THROTTLE_MAX_CRUISE_THROTTLE" value="1" unit="%"/>
<define name="AUTO_THROTTLE_LOITER_TRIM" value="1000" unit="pprz_t"/>
<define name="AUTO_THROTTLE_DASH_TRIM" value="-2500" unit="pprz_t"/>
<define name="AUTO_THROTTLE_CLIMB_THROTTLE_INCREMENT" value="0.15" unit="%/(m/s)"/>
<define name="AUTO_THROTTLE_PGAIN" value="-0.008" unit="%/(m/s)"/>
<define name="AUTO_THROTTLE_IGAIN" value="0.25"/>
<define name="AUTO_THROTTLE_PITCH_OF_VZ_PGAIN" value="0.35" unit="rad/(m/s)"/>

These lines are associated with vertical rate control loops contained in ./sw/airborne/fw_v_ctl.c and are used by default in most cases. The default vertical control law is for the vertical rate to be managed by a combination of throttle and pitch.

<define name="AUTO_PITCH_PGAIN" value="-0.1"/>
<define name="AUTO_PITCH_IGAIN" value="0.025"/>
<define name="AUTO_PITCH_MAX_PITCH" value="0.5"/>
<define name="AUTO_PITCH_MIN_PITCH" value="-0.5"/>

These lines are associated with vertical control loops contained in ./sw/airborne/fw_v_ctl.c but are not used in default. The non-default vertical control law is for the vertical rate to be managed by the pitch.

<define name="THROTTLE_SLEW_LIMITER" value="2" unit="s"/>
THROTTLE_SLEW_LIMITER is the required time is seconds to change throttle from 0% to 100%.

=== Misc ===
<tt>
<section name="MISC">
<define name="NOMINAL_AIRSPEED" value ="12." unit="m/s">
<define name="CARROT" value="5." unit="s"/>
<define name="KILL_MODE_DISTANCE" value="(1.5*MAX_DIST_FROM_HOME)"/>
<define name="CONTROL_RATE" value"60" unit="Hz"/>
</section>
</tt>

* The "NOMINAL_AIRSPEED" is mainly used in the simulator.
* "CARROT" gives the distance (in seconds, so ground speed is taken into account) between the carrot and the aircraft.
* "KILL_MODE_DISTANCE" is the threshold distance to switch the autopilot into KILL mode (defined descent with no throttle)
* "CONTROL_RATE" is the rate of the low level control loops in Hertz (60 or 20).

== Hardware definitions - Makefile ==

The airframe file must include the description of the controller board and it's low-level settings. This is done in one <b><tt>makefile</tt></b> section starting with the autopilot model and flashing mode:
{{Box Code|conf/airframes/myplane.xml|
<makefile>
include $(PAPARAZZI_SRC)/conf/autopilot/tiny.makefile
<nowiki>FLASH_MODE=IAP</nowiki>
.
.
.
</makefile>
}}
Below this are the definintions and configuration of the peripherals and interfaces.

=== R/C ===

{{Box Code|conf/airframes/myplane.xml|
<nowiki>ap.CFLAGS += -DRADIO_CONTROL -DRADIO_CONTROL_TYPE=RC_FUTABA</nowiki>
<nowiki>ap.EXTRA_SRCS += radio_control.c $(SRC_ARCH)/ppm_hw.c</nowiki>
<nowiki>ap.CFLAGS += -DACTUATORS=\"servos_direct_hw.h\"</nowiki>
<nowiki>ap.EXTRA_SRCS += $(SRC_ARCH)/servos_direct_hw.c</nowiki>
}}

You can set RADIO_CONTROL_TYPE to RC_FUTABA, for falling edge PPM, or RC_JR for rising edge PPM. "RC_FUTABA" is for The Futaba or compatible brands, and "RC_JR" for JR (a.k.a Graupner outside of the USA) or compatible brands.

For the classix, you must specify which pins to use for PWM by adding "-DPWM_SERVO_0, etc." to the line fbw.CFLAGS. This activate the PWM channel.

<tt>wiring on classix PWM connector
connector LPC shared port
PWM1 PWM5 AD1_6 CAP1_3 P0.21
PWM2 PWM3 RXD0 EINT0 P0.1
PWM3 PWM1 TXD0 P0.0
PWM4 PWM6 RXD1 EINT3 P0.9
PWM5 PWM4 TXD1 AD1_1 P0.8
PWM6 PWM2 SSEL0 EINT2 P0.7</tt>

PWM1 and PWM6 should be safe. PWM4 and PWM5 should be OK if you're not using UART1 on the FBW processor - same for PWM2 and PWM3 if you're not using UART0 (disable FBW telemetry for that ).

=== 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 <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.

Paparazzi supports the following modem protocols:
* Standard transparent serial (pprz) - this is compatible with all modems and can be used to connect the autopilot directly to a PC for testing without a modem.
* Maxstream API protocol (xbee) - compatible with all Maxstream modems including the 9XTend and Zigbee. This protocol enables hardware addressing, allowing multiple aircraft to be managed from a single ground modem.
* Coronis Wavecard - necessary for operation with the unusual Coronis Wavecard modem.
Select the baud/protocol in the airframe file by commenting/uncommenting the appropriate section as follows:
==== Configuring The Serial Protocol ====
New users are advised to start with the standard serial protocol before attempting to setup an addressed API link. There are no real reasons for the novice user to use the xbee protocol over the standard PPRZTransport. Even if you are using a Maxstream modem you should still start out with the standard. Lastly it should be pointed out that using a single UAV there is no disadvantage and that the [http://www.engr.usu.edu/wiki/index.php/OSAM OSAM] Paparazzi Team at UAS 2008 took second place using the STANDARD protocol. The serial protocol works with virtually any modem as well as direct cable connections. The baud rates of the airborne modem, autopilot, ground modem, and PC must be configured correctly. The PC and autopilot serial ports do not need to be set to the same baud rate, i.e. when running multiple aircraft from a single ground modem, the ground modem may require a higher baud rate than any of the airborne modems in order to stream the data from multiple simultaneous sources.

{{Box Code|conf/airframes/myplane.xml|
<nowiki>
<section name="DATALINK" prefix="DATALINK_">
<define name="DEVICE_TYPE" value="PPRZ"/>
<define name="DEVICE_ADDRESS" value="...."/>
</section>
</nowiki>
}}
The above example tells the autopilot to send and recieve data in standard serial form.

{{Box Code|conf/airframes/myplane.xml - makefile section at the bottom|
# Serial modem
<nowiki>ap.CFLAGS += -DDOWNLINK -DUSE_UART0 -DDOWNLINK_TRANSPORT=PprzTransport -DDOWNLINK_FBW_DEVICE=Uart0 -DDOWNLINK_AP_DEVICE=Uart0 -DPPRZ_UART=Uart0 -DDATALINK=PPRZ -DUART0_BAUD=B57600</nowiki>
<nowiki>ap.srcs += downlink.c $(SRC_ARCH)/uart_hw.c datalink.c pprz_transport.c</nowiki>
}}
The above example configures the autopilot serial port (Uart0) to 57,600 baud and calls the serial transport protocol (pprz_transport.c). Use the "#" symbol to comment lines in this section of the airframe file.
<br>
Note:
* The autopilot and modem serial port baud rates must match at all times and also must match the ground modem rate, check your modem documentation to find the default baud rate and configure a different rate as needed.

<br style="clear:both>

Ensure that the ground station is using the same protocol and an equal or higher baud rate:
{{Box Code|conf/control_panel.xml|
<nowiki>
<session name="USB">
<program name="link">
<arg flag="-d" constant="/dev/paparazzi/ttyUSB0"/>

<arg flag="-uplink" constant=""/>
<arg flag="-s" constant="57600"/>
</program>
...
</session>
</nowiki>
}}
Use this constant /dev/paparazzi/ttyUSB0 when using either the ftdi cable or a Maxstream USB ground modem.. Otherwise use /dev/ttyUSB0 (the ttyUSB0 being the device that you are using. Note: it might not always be ttyUSB0). This paparazzi directory in the dev folder is created when setting the udev rules. [http://paparazzi.enac.fr/wiki/index.php/Installation#Setting_access_rights_for_USB_download Setting Udev rules]

==== Configuring The Maxstream API Protocol ====
The optional API protocol enables hardware addressing so that multiple aircraft can be managed from a single ground modem, or multiple aircraft and multiple ground stations can work simultaneously without interference from one another. API mode is enabled by sending an escape sequence (+++) followed by AT commands, this can be done automatically at each boot or can be permanently configured with the "ATWR" command for greater reliability.

{{Box Code|conf/airframes/myplane.xml|
<nowiki>
<section name="MISC">
...
<define name="XBEE_INIT" value="\"ATPL2\rATRN1\rATTT80\r\ATBD6\rATWR\r\""/>
<define name="NO_XBEE_API_INIT" value="FALSE"/>
...
</section></nowiki>
}}
The above example will program the Maxstream to API mode, 100mW power (ATPL2), 57600 baud (ATBD6), and permanently store the changes (ATWR). After flashing allow 30 seconds for the modem to store the changes, then disable the init string <tt><define name="NO_XBEE_API_INIT" value="<b>TRUE</b>"/></tt>, update the baud rate as needed, and re-flash the autopilot. The modem and autopilot serial port baud rates must match eachother at all times.
<br>
Notes:
* Maxtream modems are factory configured for 9600 baud, in order to change baud rates, first configure the autopilot serial port to match the modem (DUART0_BAUD=B9600), boot the system so that the baud rate change command is sent to the modem (ATBD6) and permanently saved (ATWR), allow 30 seconds for the modem configuration to complete, then reprogram the autopilot with the new baud rate (DUART0_BAUD=B57600) and disabled modem configuration string <tt><define name="NO_XBEE_API_INIT" value="<b>TRUE</b>"/> </tt>.
* The ac_id defined in <tt>conf/conf.xml</tt> is permanently programmed into the modem so this procedure would need to be re-run if the modem is moved to another plane.
* For temporary boot-time API configuration remove any baud rate changes, remove <tt>ATWR\r</tt> from the end of the string and keep "NO_XBEE_API_INIT" value="FALSE".
* Upgrade your Maxstream firmware to the latest version before attempting API mode operation.

<br style="clear:both>

{{Box Code|confAgain/airframes/myplane.xml - makefile section at the bottom|
<nowiki># Maxstream API protocol</nowiki>
<nowiki>ap.CFLAGS += -DDOWNLINK -DUSE_UART0 -DDOWNLINK_TRANSPORT=XBeeTransport -DDOWNLINK_FBW_DEVICE=Uart0 -DDOWNLINK_AP_DEVICE=Uart0 -DXBEE_UART=Uart0 -DDATALINK=XBEE -DUART0_BAUD=B57600</nowiki>
<nowiki>ap.srcs += downlink.c $(SRC_ARCH)/uart_hw.c datalink.c xbee.c</nowiki>
}}
The above example configures the autopilot serial port (Uart0) to 57,600 baud and calls the Maxstream transport protocol (xbee.c). Use the "#" symbol to comment lines in this section of the airframe file.
<br style="clear:both>

Ensure that the ground station is using the same protocol and an equal or higher baud rate:
{{Box Code|conf/control_panel.xml|
<nowiki>
<session name="USB">
<program name="link">
<arg flag="-d" constant="/dev/paparazzi/ttyUSB0"/>
<arg flag="-transport" constant="xbee"/>
<arg flag="-uplink" constant=""/>
<arg flag="-s" constant="57600"/>
</program>
...
</session>
</nowiki>
}}
Use this constant /dev/paparazzi/ttyUSB0 when using either the ftdi cable or a Maxstream USB ground modem.. Otherwise use /dev/ttyUSB0 (the ttyUSB0 being the device that you are using. Note: it might not always be ttyUSB0). This paparazzi directory in the dev folder is created when setting the udev rules. [http://paparazzi.enac.fr/wiki/index.php/Installation#Setting_access_rights_for_USB_download Setting Udev rules]
=====Alternate Method=====
This is the way it is done in funjet1.xml and has been tested to work by Danstah

{{Box Code|conf/airframes/funjet1.xml|
<nowiki>
<section name="MISC">
...
<define name="XBEE_INIT" value="\"ATPL2\rATRN1\rATTT80\r\""/>

...
</section></nowiki>
}}
Also use this
{{Box Code|conf/airframes/funjet1.xml|
<nowiki>

<section name="DATALINK" prefix="DATALINK_">
<define name="DEVICE_TYPE" value="XBEE"/>
<define name="DEVICE_ADDRESS" value="...."/>
</section>
</nowiki>
}}
And Finally use this in the makefile section
{{Box Code|conf/airframes/funjet1.xml|
<nowiki>
ap.CFLAGS += -DDOWNLINK -DUSE_UART1 -DDOWNLINK_TRANSPORT=XBeeTransport -DXBEE_UART=Uart1 -DDATALINK=XBEE -DUART1_BAUD=B9600
ap.srcs += downlink.c $(SRC_ARCH)/uart_hw.c datalink.c xbee.c
</nowiki>
}}
By reading all the information above you should be able to infer what the above does

Now keep in mind that the ground modem baud rate and airplanes modem baud rates do not have to match. The only things that need to match are the the modem on the planes baud rate and the rate defined in the airframe file. For example this planes modem is set to 9600 and this could be used with the ground modem configured above using 57600...
Also for multiple UAV's a good way to configure them is to use 9600 for the ap and use a ground modem configured to 57600 and its not a bad idea to use minimal telemetry

=== 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:

{{Box Code|conf/airframes/myplane.xml|
<nowiki>ap.CFLAGS += -DGPS -DUBX -DUSE_UART1 -DGPS_LINK=Uart1 -DUART1_BAUD=B38400</nowiki>
<nowiki>ap.srcs += gps_ubx.c gps.c</nowiki>
}}
'''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 thru the [[Compiling#USB_flashing|UART Tunnel]] and [[GPS#GPS_configuration_using_U-Center Configured with|u-center]]

=== Sensors ===

=== Control loops ===

The control loops can be divided in two largely independent groups : the vertical ones and the horizontal ones (files sw/airborne/fw_h_ctl.c and sw/airborne/fw_v_ctl.c ). Those loops can be commanded at different levels by either the R/C transmitter or the autonomous navigation routine.

First the horizontal loop:
{{Box Code|conf/airframes/funjet1.xml|
<nowiki>ap.CFLAGS += -DNAV -DAGR_CLIMB -DLOITER_TRIM
ap.srcs += nav.c fw_h_ctl.c fw_v_ctl.c
</nowiki>
}}

== Radio Control ==
The Paparazzi autpilot interfaces directly with the PWM signal from any standard hobby R/C receiver. Signal decoding configuration settings for this are stored in the [[Radio_Control|Radio Control]] file.

Conf.xml

2008-09-02T17:29:51Z

Rcbrother:

The <tt><b>conf/conf.xml</b></tt> document associates the flight plan and various hardware/software configuration files with a partticular aircraft, identified by <tt>name</tt> and <tt>ac_id</tt>. The values in this document are set and handled by the [[Paparazzi_Center|Paparazzi Center]] so it is usually not needed to edit the configuration document manually.

== Syntax ==
<tt>
<aircraft
name="Plaster"
ac_id="7"
airframe="airframes/plaster1.xml"
radio="radios/cockpitMM.xml"
flight_plan="flight_plans/generic.xml"
telemetry="telemetry/default.xml"
settings="settings/basic.xml"
gui_color="red"
/></tt>

where:
* <tt>name</tt> is the name of the aircraft which will appear in different places in the [[GCS|GCS]]
* <tt>ac_id</tt> is a unique integer (between 1 and 255) identifying the aircraft (especially needed in the communication messages)
* <tt>airframe</tt> is the file name containing the parameters of the aircraft
* <tt>radio</tt> is the file name containing the description of the RC transmitter
* <tt>flight_plan</tt> is the sequence of actions and waypoints describing the desired trajectory
* <tt>telemetry</tt> is the file name containing the set of messages sent over the telemetry link
* <tt>settings</tt> is the file name containing the set of parameters that can be configured through the telemetry link
* <tt>gui_color</tt> is the color assigned to this aircraft in the GCS

All these attributes are required except the last two (<tt>settings</tt> and <tt>gui_color</tt>) which are optional.

The following sections describe these xml documents:
* [[Radio_Control|Radio Control]]
* [[Airframe_Configuration|Airframe]]
* [[Flight_Plans|Flight plans]]
* [[Telemetry|Telemetry]]
* [[Settings]]

Conf.xml

2008-09-02T17:27:51Z

Rcbrother: /* Syntax */

The <tt><b>conf/conf.xml</b></tt> file associates the flight plan and various hardware/software configuration files with a partticular aircraft, identified by <tt>name</tt> and <tt>ac_id</tt>. This file is handled by the [[Paparazzi_Center|Paparazzi Center]] so it is usually not needed to edit it by hand.

== Syntax ==
<tt>
<aircraft
name="Plaster"
ac_id="7"
airframe="airframes/plaster1.xml"
radio="radios/cockpitMM.xml"
flight_plan="flight_plans/generic.xml"
telemetry="telemetry/default.xml"
settings="settings/basic.xml"
gui_color="red"
/></tt>

where:
* <tt>name</tt> is the name of the aircraft which will appear in different places in the [[GCS|GCS]]
* <tt>ac_id</tt> is a unique integer (between 1 and 255) identifying the aircraft (especially needed in the communication messages)
* <tt>airframe</tt> is the file name containing the parameters of the aircraft
* <tt>radio</tt> is the file name containing the description of the RC transmitter
* <tt>flight_plan</tt> is the sequence of actions and waypoints describing the desired trajectory
* <tt>telemetry</tt> is the file name containing the set of messages sent over the telemetry link
* <tt>settings</tt> is the file name containing the set of parameters that can be configured through the telemetry link
* <tt>gui_color</tt> is the color assigned to this aircraft in the GCS

All these attributes are required except the last two (<tt>settings</tt> and <tt>gui_color</tt>) which are optional.

The following sections describe these xml documents:
* [[Radio_Control|Radio Control]]
* [[Airframe_Configuration|Airframe]]
* [[Flight_Plans|Flight plans]]
* [[Telemetry|Telemetry]]
* [[Settings]]

Airframe Configuration

2008-09-02T17:20:36Z

Rcbrother:

The airframe configuration file is located in <tt>conf/airframes</tt> and contains
all the hardware and software settings for an aircraft. This is an [http://en.wikipedia.org/wiki/Xml XML] document containing some [http://en.wikipedia.org/wiki/Makefile Makefile] code at the bottom. All gains, trims, and behavior settings are defined with standard XML elements. The hardware definitions such as processor type, modem protocol, servo driver, etc. are contained in the makefile raw section.

== Selecting the Airframe File ==
Each airframe file must be assigned a name, unique ID, flight plan, etc. in [[Conf.xml|<tt>conf/conf.xml</tt>]] as follows:
<?xml version="1.0"?>
<conf>
<aircraft
name="Twin1"
ac_id="1"
airframe="airframes/twinstar1.xml"
radio="radios/mc3030.xml"
flight_plan="flight_plans/mav05_cw.xml"
telemetry="telemetry/default.xml"
gui_color="blue"
/>
<aircraft
name="Plaster"
ac_id="2"
airframe="airframes/plaster1.xml"
radio="radios/cockpitMM.xml"
telemetry="telemetry/default.xml"
flight_plan="flight_plans/dummy.xml"
/>
.
.
.
</conf>
Then, to compile and flash the airframe settings and associated flight plan to your autopilot, simply select the appropriate A/C and target in the [[Paparazzi_Center|Paparazzi Center]] or specify your airframe name in the flash command typed from the prompt:
make AIRCRAFT=<b>Twin1</b> ap.upload
More information can be found on the [[Conf.xml|conf.xml]] page

== XML Parameters ==
=== Commands ===

The <b><tt>commands</tt></b> lists the abstract commands you need to control the aircraft. In our example, we have only three:
<tt>
<commands>
<axis name="THROTTLE" failsafe_value="0"/>
<axis name="ROLL" failsafe_value="0"/>
<axis name="PITCH" failsafe_value="0"/>
</commands></tt>
Each command is associated with a failsafe value which will be used if no controller is active (during initialization for example). The range of these values is [-9600:9600]. Note that these commands do not necessarily match the servo actuators. For example, the ROLL command is typically linked to two aileron actuators.

=== Servos ===

The above commands get translated to the <b><tt>servos</tt></b> here. In this example we use two ailevons (surfaces used for both pitch and roll as on a flying wing) and a motor. These are listed in the <b><tt>servos</tt></b> section:
<tt>
<servos>
<servo name="THROTTLE" no="0" min="1000" neutral="1000" max="2000"/>
<servo name="AILEVON_LEFT" no="1" min="2000" neutral="1500" max="1000"/>
<servo name="AILEVON_RIGHT" no="2" min="1000" neutral="1500" max="2000"/>
</servos></tt>
where names are associated to the corresponding servo channel number on the autopilot and the neutral value, total range and direction are defined. Min/max/neutral values are expressed in milliseconds and the direction of travel can be reversed by exchanging min with max (as in <tt>"AILEVON_LEFT"</tt>, above). The ''standard'' travel for a hobby servo is 1000ms - 2000ms with a 1500ms neutral. Trim can be added by changing this neutral value, and absolute 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>. Note the following tips:
* Reverse the servo direction by exchanging min/max
* Trim should always be adjusted mechanically if possible to avoid asymetrical travel
* Any reduction of the total travel range should be done mechanically to maintain precision
* Many servos will respond well to values slightly outside the normal 1000-2000ms range but experiment carefully as the servo may not operate reliably outside this range and may even suffer permanent damage.

The <b><tt>servos</tt></b> are then linked to the commands in the <b><tt>command_laws</tt></b> section:
<tt>
<command_laws>
<let var="aileron" value="@ROLL * 0.3"/>
<let var="elevator" value="@PITCH * 0.7"/>
<set servo="THROTTLE" value="@THROTTLE"/>
<set servo="AILEVON_LEFT" value="$elevator + $aileron"/>
<set servo="AILEVON_RIGHT" value="$elevator - $aileron"/>
</command_laws></tt>
[[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. Ailevon 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.

=== Manual ===
The <tt>rc_command</tt> sections links the channels of the RC transmitter (defined in the [[Radio_Control|Radio Control]] file) to the <tt>commands</tt> defined above:

<rc_commands>
<set command="THROTTLE" value="@THROTTLE"/>
<set command="ROLL" value="@ROLL"/>
<set command="PITCH" value="@PITCH"/>
</rc_commands>

This example looks trivial since the channel values have the same name than the commands.

=== Auto1 ===
The next section, named <b><tt>AUTO1</tt></b>, gives the maximum roll and pitch (in radians) allowed for the augmented stability mode.
<tt>
<section name="AUTO1" prefix="AUTO1_">
<define name="MAX_ROLL" value="RadOfDeg(35)"/>
<define name="MAX_PITCH" value="RadOfDeg(35)"/>
</section>
</tt>
<br>

=== ADC ===
In the "adc" section, you will find the correspondance between arguments and their assigned pins on the autopilot board.
<section name="adc" prefix="ADC_CHANNEL_">
<define name="IR1" value="ADC_1"/>
<define name="IR2" value="ADC_2"/>
<define name="IR_TOP" value="ADC_0"/>
</section>
'''Important note''': To ''activate'' an ADC entry, a flag must be defined in the <tt>makefile</tt> section. For the previous example, we would have to write:

ap.CFLAGS += -DADC -DUSE_ADC_0 -DUSE_ADC_1 -DUSE_ADC_2

=== Infrared ===
The <b><tt>INFRARED</tt></b> section describes the configuration of the infrared sensors.

The first definitions are relative to the electronic neutral of the sensors (a sensor here is a pair of thermopiles). A perfect sensor should give 512 if it measures the same value on both sides.

<section name="INFRARED" prefix="IR_">
<define name="ADC_IR1_NEUTRAL" value="512"/>
<define name="ADC_IR2_NEUTRAL" value="512"/>
<define name="ADC_TOP_NEUTRAL" value="512"/>

These neutrals are tuned with the "cupboard test": Put the sensor in a close box (a cupboard) and read the values of the IR_SENSORS message (ir1, ir2 and vertical). Set the neutrals (they are subtracted from the measurement) to get null values. E.g. if you read 5 for the ir1 value with ADC_IR1_NEUTRAL equal to 512, change the latter to 517.

The next lines define the installation of the horizontal and vertical sensors. The vertical sensor must give a positive value when the temperature under the aircraft is higher than the temperature above. The two channels of the horizontal sensor must give positive values when it is warmer on the right side and the rear side. To adjust these signs, use the following declarations:

<define name="IR2_SIGN" value="-1"/>
<define name="TOP_SIGN" value="-1"/>

Then, define the orientation of the horizontal sensor, <tt>TILTED</tt> or <tt>ALIGNED</tt>. In the <tt>ALIGNED</tt> case, ir1 is along the lateral axis and ir2 along the longitudianl one. In the <tt>TILTED</tt> case, the sensors are tilted by 45 degrees; ir1 is along rear-left -- front-right, and ir2 along rear-right -- front-left.
<define name="HORIZ_SENSOR_TILTED" value="1"/>

The three axis must give similar values for similar contrasts. The following factors can be used to scale these values. For example with an horizontal tilted sensor, the following ratios are usually needed:

<define name="LATERAL_CORRECTION" value="0.7"/>
<define name="LONGITUDINAL_CORRECTION" value="0.7"/>
<define name="VERTICAL_CORRECTION" value="1."/>
Default values are 1.

It may be hard to align the horizontal sensor with the aircraft. A tuning in flight will be needed to adjust the following neutrals. Adjust the roll neutral to fly straight. Adjust the pitch neutral to fly level with the desired throttle.
<define name="ROLL_NEUTRAL_DEFAULT" value="-2.5" unit="deg"/>
<define name="PITCH_NEUTRAL_DEFAULT" value="6" unit="deg"/>

Finally, an asymmetric (left/right, front/rear) correction can be added with a last set of factors.
<define name="CORRECTION_UP" value="1."/>
<define name="CORRECTION_DOWN" value="1."/>
<define name="CORRECTION_LEFT" value="1."/>
<define name="CORRECTION_RIGHT" value="1."/>
</section>
These corrections are set on the angles.

=== Gyro ===
Defines the type of gyro installed, each axis neutral, and any required temperature compensation. If the gyro has two axes, the pitch neutral is defined as well. Many gyros output their internal temperature and require a temperature-dependent linear correction be made to the neutral value. No correction is done for the temperature in this example.(<b><tt>ADC_TEMP_SLOPE=0</tt></b>).

<tt>
<section name="GYRO" prefix="GYRO_"
<define name="ADC_ROLL_COEFF" value="1"/>
<define name="ROLL_NEUTRAL" value="500"/>
<define name="ADC_TEMP_NEUTRAL" value="476"/>
<define name="ADC_TEMP_SLOPE" value="0"/>
</section>
</tt>

=== Bat ===
This section give characteristics for the monitoring of the main power battery. <b><tt>MILLIAMP_PER_PERCENT</tt></b> represents the consumption (in mA) for one percent of THROTTLE and for one time unit. It is used to compute the <tt>energy</tt> value of the <tt>BAT</tt> message.

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. This definition is optional with a default value of 12.5V.

<tt>
<section name="BAT">
<define name="MILLIAMP_PER_PERCENT" value="0.86"/>
<define name="VOLTAGE_ADC_A" value="0.0177531"/>
<define name="VOLTAGE_ADC_B" value="0.173626"/>
<define name="VoltageOfAdc(adc)" value ="(VOLTAGE_ADC_A * adc + VOLTAGE_ADC_B)"/>
<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>
</tt>

=== Horizontal Control ===
<tt>
<section name="HORIZONTAL CONTROL" prefix="H_CTL_">
<define name="COURSE_PGAIN" value="-0.4"/>
<define name="ROLL_MAX_SETPOINT" value="0.35" unit="radians"/>
<define name="ROLL_ATTITUDE_GAIN" value="-7500."/>
<define name="ROLL_RATE_GAIN" value="-1500"/>
<define name="PITCH_PGAIN" value="-8000."/>
<define name="ELEVATOR_OF_ROLL" value="1250"/>
</section>
</tt>

The outer loop acts on the route. It will produce a roll command from a course setpoint and a course measurement. The COURSE_PGAIN parameter is the factor multiplied by the course error (in radian) to get a roll setpoint (in radian). So if the plane is expected to go north (course=0) and is actually flying to 57 degrees (course=1 radian, i.e. ENE), with a gain of '''-0.4''', a roll of -0.4 (23 degrees) will be set for the lower control loop.

The ROLL_ATTITUDE_GAIN is used to compute a ROLL command from the roll error (setpoint minus measurement). If a gyro in installed, the ROLL_RATE_GAIN to keep a null roll rate. So these two gains provide a P-D controller.

===Vertical Control===

<section name="VERTICAL CONTROL" prefix="V_CTL_">

<define name="ALTITUDE_PGAIN" value="-0.1" unit="(m/s)/m"/>

<define name="ALTITUDE_MAX_CLIMB" value="3." unit="m/s"/>
These lines are associated with vertical control loops contained in ./sw/airborne/fw_v_ctl.c. These are outer loop parameters that calculate a desired climb rate based on altitude error. Here, if the altitude error is 10m, the climb setpoint will be set to 1m/s. ALTITUDE_MAX_CLIMB is a bounded value (in m/s) so that the outer loop does not calculate too large of a climb rate
<define name="AUTO_THROTTLE_NOMINAL_CRUISE_THROTTLE" value="0.65" unit="%"/>
<define name="AUTO_THROTTLE_MIN_CRUISE_THROTTLE" value=".4" unit="%"/>
<define name="AUTO_THROTTLE_MAX_CRUISE_THROTTLE" value="1" unit="%"/>
<define name="AUTO_THROTTLE_LOITER_TRIM" value="1000" unit="pprz_t"/>
<define name="AUTO_THROTTLE_DASH_TRIM" value="-2500" unit="pprz_t"/>
<define name="AUTO_THROTTLE_CLIMB_THROTTLE_INCREMENT" value="0.15" unit="%/(m/s)"/>
<define name="AUTO_THROTTLE_PGAIN" value="-0.008" unit="%/(m/s)"/>
<define name="AUTO_THROTTLE_IGAIN" value="0.25"/>
<define name="AUTO_THROTTLE_PITCH_OF_VZ_PGAIN" value="0.35" unit="rad/(m/s)"/>

These lines are associated with vertical rate control loops contained in ./sw/airborne/fw_v_ctl.c and are used by default in most cases. The default vertical control law is for the vertical rate to be managed by a combination of throttle and pitch.

<define name="AUTO_PITCH_PGAIN" value="-0.1"/>
<define name="AUTO_PITCH_IGAIN" value="0.025"/>
<define name="AUTO_PITCH_MAX_PITCH" value="0.5"/>
<define name="AUTO_PITCH_MIN_PITCH" value="-0.5"/>

These lines are associated with vertical control loops contained in ./sw/airborne/fw_v_ctl.c but are not used in default. The non-default vertical control law is for the vertical rate to be managed by the pitch.

<define name="THROTTLE_SLEW_LIMITER" value="2" unit="s"/>
THROTTLE_SLEW_LIMITER is the required time is seconds to change throttle from 0% to 100%.

=== Misc ===
<tt>
<section name="MISC">
<define name="NOMINAL_AIRSPEED" value ="12." unit="m/s">
<define name="CARROT" value="5." unit="s"/>
<define name="KILL_MODE_DISTANCE" value="(1.5*MAX_DIST_FROM_HOME)"/>
<define name="CONTROL_RATE" value"60" unit="Hz"/>
</section>
</tt>

* The "NOMINAL_AIRSPEED" is mainly used in the simulator.
* "CARROT" gives the distance (in seconds, so ground speed is taken into account) between the carrot and the aircraft.
* "KILL_MODE_DISTANCE" is the threshold distance to switch the autopilot into KILL mode (defined descent with no throttle)
* "CONTROL_RATE" is the rate of the low level control loops in Hertz (60 or 20).

== Hardware definitions - Makefile ==

The airframe file must include the description of the controller board and it's low-level settings. This is done in one <b><tt>makefile</tt></b> section starting with the autopilot model and flashing mode:
{{Box Code|conf/airframes/myplane.xml|
<makefile>
include $(PAPARAZZI_SRC)/conf/autopilot/tiny.makefile
<nowiki>FLASH_MODE=IAP</nowiki>
.
.
.
</makefile>
}}
Below this are the definintions and configuration of the peripherals and interfaces.

=== R/C ===

{{Box Code|conf/airframes/myplane.xml|
<nowiki>ap.CFLAGS += -DRADIO_CONTROL -DRADIO_CONTROL_TYPE=RC_FUTABA</nowiki>
<nowiki>ap.EXTRA_SRCS += radio_control.c $(SRC_ARCH)/ppm_hw.c</nowiki>
<nowiki>ap.CFLAGS += -DACTUATORS=\"servos_direct_hw.h\"</nowiki>
<nowiki>ap.EXTRA_SRCS += $(SRC_ARCH)/servos_direct_hw.c</nowiki>
}}

You can set RADIO_CONTROL_TYPE to RC_FUTABA, for falling edge PPM, or RC_JR for rising edge PPM.

For the classix, you must specify which pins to use for PWM by adding "-DPWM_SERVO_0, etc." to the line fbw.CFLAGS. This activate the PWM channel.

<tt>wiring on classix PWM connector
connector LPC shared port
PWM1 PWM5 AD1_6 CAP1_3 P0.21
PWM2 PWM3 RXD0 EINT0 P0.1
PWM3 PWM1 TXD0 P0.0
PWM4 PWM6 RXD1 EINT3 P0.9
PWM5 PWM4 TXD1 AD1_1 P0.8
PWM6 PWM2 SSEL0 EINT2 P0.7</tt>

PWM1 and PWM6 should be safe. PWM4 and PWM5 should be OK if you're not using UART1 on the FBW processor - same for PWM2 and PWM3 if you're not using UART0 (disable FBW telemetry for that ).

=== 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 <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.

Paparazzi supports the following modem protocols:
* Standard transparent serial (pprz) - this is compatible with all modems and can be used to connect the autopilot directly to a PC for testing without a modem.
* Maxstream API protocol (xbee) - compatible with all Maxstream modems including the 9XTend and Zigbee. This protocol enables hardware addressing, allowing multiple aircraft to be managed from a single ground modem.
* Coronis Wavecard - necessary for operation with the unusual Coronis Wavecard modem.
Select the baud/protocol in the airframe file by commenting/uncommenting the appropriate section as follows:
==== Configuring The Serial Protocol ====
New users are advised to start with the standard serial protocol before attempting to setup an addressed API link. There are no real reasons for the novice user to use the xbee protocol over the standard PPRZTransport. Even if you are using a Maxstream modem you should still start out with the standard. Lastly it should be pointed out that using a single UAV there is no disadvantage and that the [http://www.engr.usu.edu/wiki/index.php/OSAM OSAM] Paparazzi Team at UAS 2008 took second place using the STANDARD protocol. The serial protocol works with virtually any modem as well as direct cable connections. The baud rates of the airborne modem, autopilot, ground modem, and PC must be configured correctly. The PC and autopilot serial ports do not need to be set to the same baud rate, i.e. when running multiple aircraft from a single ground modem, the ground modem may require a higher baud rate than any of the airborne modems in order to stream the data from multiple simultaneous sources.

{{Box Code|conf/airframes/myplane.xml|
<nowiki>
<section name="DATALINK" prefix="DATALINK_">
<define name="DEVICE_TYPE" value="PPRZ"/>
<define name="DEVICE_ADDRESS" value="...."/>
</section>
</nowiki>
}}
The above example tells the autopilot to send and recieve data in standard serial form.

{{Box Code|conf/airframes/myplane.xml - makefile section at the bottom|
# Serial modem
<nowiki>ap.CFLAGS += -DDOWNLINK -DUSE_UART0 -DDOWNLINK_TRANSPORT=PprzTransport -DDOWNLINK_FBW_DEVICE=Uart0 -DDOWNLINK_AP_DEVICE=Uart0 -DPPRZ_UART=Uart0 -DDATALINK=PPRZ -DUART0_BAUD=B57600</nowiki>
<nowiki>ap.srcs += downlink.c $(SRC_ARCH)/uart_hw.c datalink.c pprz_transport.c</nowiki>
}}
The above example configures the autopilot serial port (Uart0) to 57,600 baud and calls the serial transport protocol (pprz_transport.c). Use the "#" symbol to comment lines in this section of the airframe file.
<br>
Note:
* The autopilot and modem serial port baud rates must match at all times and also must match the ground modem rate, check your modem documentation to find the default baud rate and configure a different rate as needed.

<br style="clear:both>

Ensure that the ground station is using the same protocol and an equal or higher baud rate:
{{Box Code|conf/control_panel.xml|
<nowiki>
<session name="USB">
<program name="link">
<arg flag="-d" constant="/dev/paparazzi/ttyUSB0"/>

<arg flag="-uplink" constant=""/>
<arg flag="-s" constant="57600"/>
</program>
...
</session>
</nowiki>
}}
Use this constant /dev/paparazzi/ttyUSB0 when using either the ftdi cable or a Maxstream USB ground modem.. Otherwise use /dev/ttyUSB0 (the ttyUSB0 being the device that you are using. Note: it might not always be ttyUSB0). This paparazzi directory in the dev folder is created when setting the udev rules. [http://paparazzi.enac.fr/wiki/index.php/Installation#Setting_access_rights_for_USB_download Setting Udev rules]

==== Configuring The Maxstream API Protocol ====
The optional API protocol enables hardware addressing so that multiple aircraft can be managed from a single ground modem, or multiple aircraft and multiple ground stations can work simultaneously without interference from one another. API mode is enabled by sending an escape sequence (+++) followed by AT commands, this can be done automatically at each boot or can be permanently configured with the "ATWR" command for greater reliability.

{{Box Code|conf/airframes/myplane.xml|
<nowiki>
<section name="MISC">
...
<define name="XBEE_INIT" value="\"ATPL2\rATRN1\rATTT80\r\ATBD6\rATWR\r\""/>
<define name="NO_XBEE_API_INIT" value="FALSE"/>
...
</section></nowiki>
}}
The above example will program the Maxstream to API mode, 100mW power (ATPL2), 57600 baud (ATBD6), and permanently store the changes (ATWR). After flashing allow 30 seconds for the modem to store the changes, then disable the init string <tt><define name="NO_XBEE_API_INIT" value="<b>TRUE</b>"/></tt>, update the baud rate as needed, and re-flash the autopilot. The modem and autopilot serial port baud rates must match eachother at all times.
<br>
Notes:
* Maxtream modems are factory configured for 9600 baud, in order to change baud rates, first configure the autopilot serial port to match the modem (DUART0_BAUD=B9600), boot the system so that the baud rate change command is sent to the modem (ATBD6) and permanently saved (ATWR), allow 30 seconds for the modem configuration to complete, then reprogram the autopilot with the new baud rate (DUART0_BAUD=B57600) and disabled modem configuration string <tt><define name="NO_XBEE_API_INIT" value="<b>TRUE</b>"/> </tt>.
* The ac_id defined in <tt>conf/conf.xml</tt> is permanently programmed into the modem so this procedure would need to be re-run if the modem is moved to another plane.
* For temporary boot-time API configuration remove any baud rate changes, remove <tt>ATWR\r</tt> from the end of the string and keep "NO_XBEE_API_INIT" value="FALSE".
* Upgrade your Maxstream firmware to the latest version before attempting API mode operation.

<br style="clear:both>

{{Box Code|confAgain/airframes/myplane.xml - makefile section at the bottom|
<nowiki># Maxstream API protocol</nowiki>
<nowiki>ap.CFLAGS += -DDOWNLINK -DUSE_UART0 -DDOWNLINK_TRANSPORT=XBeeTransport -DDOWNLINK_FBW_DEVICE=Uart0 -DDOWNLINK_AP_DEVICE=Uart0 -DXBEE_UART=Uart0 -DDATALINK=XBEE -DUART0_BAUD=B57600</nowiki>
<nowiki>ap.srcs += downlink.c $(SRC_ARCH)/uart_hw.c datalink.c xbee.c</nowiki>
}}
The above example configures the autopilot serial port (Uart0) to 57,600 baud and calls the Maxstream transport protocol (xbee.c). Use the "#" symbol to comment lines in this section of the airframe file.
<br style="clear:both>

Ensure that the ground station is using the same protocol and an equal or higher baud rate:
{{Box Code|conf/control_panel.xml|
<nowiki>
<session name="USB">
<program name="link">
<arg flag="-d" constant="/dev/paparazzi/ttyUSB0"/>
<arg flag="-transport" constant="xbee"/>
<arg flag="-uplink" constant=""/>
<arg flag="-s" constant="57600"/>
</program>
...
</session>
</nowiki>
}}
Use this constant /dev/paparazzi/ttyUSB0 when using either the ftdi cable or a Maxstream USB ground modem.. Otherwise use /dev/ttyUSB0 (the ttyUSB0 being the device that you are using. Note: it might not always be ttyUSB0). This paparazzi directory in the dev folder is created when setting the udev rules. [http://paparazzi.enac.fr/wiki/index.php/Installation#Setting_access_rights_for_USB_download Setting Udev rules]
=====Alternate Method=====
This is the way it is done in funjet1.xml and has been tested to work by Danstah

{{Box Code|conf/airframes/funjet1.xml|
<nowiki>
<section name="MISC">
...
<define name="XBEE_INIT" value="\"ATPL2\rATRN1\rATTT80\r\""/>

...
</section></nowiki>
}}
Also use this
{{Box Code|conf/airframes/funjet1.xml|
<nowiki>

<section name="DATALINK" prefix="DATALINK_">
<define name="DEVICE_TYPE" value="XBEE"/>
<define name="DEVICE_ADDRESS" value="...."/>
</section>
</nowiki>
}}
And Finally use this in the makefile section
{{Box Code|conf/airframes/funjet1.xml|
<nowiki>
ap.CFLAGS += -DDOWNLINK -DUSE_UART1 -DDOWNLINK_TRANSPORT=XBeeTransport -DXBEE_UART=Uart1 -DDATALINK=XBEE -DUART1_BAUD=B9600
ap.srcs += downlink.c $(SRC_ARCH)/uart_hw.c datalink.c xbee.c
</nowiki>
}}
By reading all the information above you should be able to infer what the above does

Now keep in mind that the ground modem baud rate and airplanes modem baud rates do not have to match. The only things that need to match are the the modem on the planes baud rate and the rate defined in the airframe file. For example this planes modem is set to 9600 and this could be used with the ground modem configured above using 57600...
Also for multiple UAV's a good way to configure them is to use 9600 for the ap and use a ground modem configured to 57600 and its not a bad idea to use minimal telemetry

=== 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:

{{Box Code|conf/airframes/myplane.xml|
<nowiki>ap.CFLAGS += -DGPS -DUBX -DUSE_UART1 -DGPS_LINK=Uart1 -DUART1_BAUD=B38400</nowiki>
<nowiki>ap.srcs += gps_ubx.c gps.c</nowiki>
}}
'''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 thru the [[Compiling#USB_flashing|UART Tunnel]] and [[GPS#GPS_configuration_using_U-Center Configured with|u-center]]

=== Sensors ===

=== Control loops ===

The control loops can be divided in two largely independent groups : the vertical ones and the horizontal ones (files sw/airborne/fw_h_ctl.c and sw/airborne/fw_v_ctl.c ). Those loops can be commanded at different levels by either the R/C transmitter or the autonomous navigation routine.

First the horizontal loop:
{{Box Code|conf/airframes/funjet1.xml|
<nowiki>ap.CFLAGS += -DNAV -DAGR_CLIMB -DLOITER_TRIM
ap.srcs += nav.c fw_h_ctl.c fw_v_ctl.c
</nowiki>
}}

== Radio Control ==
The Paparazzi autpilot interfaces directly with the PWM signal from any standard hobby R/C receiver. Signal decoding configuration settings for this are stored in the [[Radio_Control|Radio Control]] file.

Sensors/GPS

2008-09-01T20:07:33Z

Rcbrother: /* Standalone GPS Module from CVS */

{| align=right
|-
| __TOC__
|}

==Overview==
[[Image:U-blox_color_warm_60.gif|100px]]

Paparazzi autopilots are designed around the popular [http://www.u-blox.com u-blox] brand of receivers.

*Features:
**Small size
**Excellent performance
**4Hz position update rate

The '''[[Tiny]]''' features an onboard LEA series GPS receiver and patch antenna, while '''[[Classix]]''' and '''[[Previous_Autopilots|AVR-based]]''' boards require an external receiver+antenna such as the [[#Paparazzi_Stand-alone_GPS_Receivers|Paparazzi GPS]] or [[#u-Blox_SAM-LS_GPS_Smart_Antenna|SAM-LS]]. Please note that the receivers must be configured (prior to use with the autopilot) as indicated below. Both modules have proven reliable and robust.

{|align = center
|-
|[[Image:Lea big.jpg|200px|thumb|center|u-blox LEA GPS Receiver]]
|[[Image:Ublox_SAM-LS.jpg|200px|thumb|center|u-blox SAM-LS GPS receiver (w/built-in Smart Antenna)]]
|}

'''Note:''' The proprietary UBX protocol is used as it offers more information and efficiency than the universal NMEA protocol. The protocol is parsed in <tt>sw/airborne/gps_ubx.c</tt>. Other GPS brands would require a similar parsing file to be written for NMEA or other proprietary protocols.

==GPS Receivers==

===u-Blox LEA Series Receivers===
[[Image:Lea big.jpg|100px|thumb|right|u-blox LEA]]
The '''[[Tiny]]''' and Paparazzi stand-alone GPS currently use the [http://www.u-blox.com/products/lea_4p.html u-blox LEA-4P] featuring [http://www.u-blox.com/technology/antaris4/index.html Antaris-4] technology and uBlox's more efficient UBX binary protocol. This module is a surface mount package which is soldered directly onto the PCB (Tiny or Paparazzi GPS). An external battery backup (capacitor) is used to enable the GPS to retain data while powered off for significantly faster signal re-aquisition. Any of the LEA-4x series receivers can be used including the less expensive LEA-4A and 4S models as the special boot configuration code required for these models is already written.

*4Hz Position update rate
*Supports active or passive antennas
*Supports [http://en.wikipedia.org/wiki/DGPS DGPS], [http://en.wikipedia.org/wiki/WAAS WAAS], [http://en.wikipedia.org/wiki/EGNOS EGNOS], and [http://en.wikipedia.org/wiki/MSAS MSAS]

[[Image:TINY_1.3_MCU_BOTTOM.JPG|thumb|center|250px|LEA-4P installed on the Tiny]]
<br style="clear:both">

===Paparazzi Stand-alone GPS Receivers===
There are currently two (LEA-based) stand-alone, GPS receiver + antenna, prototype boards in development; the first one is based on the Sangshin 13mm patch antenna. The second is based on the Sarantel helix antenna. Drawings for both are available from the [http://cvs.savannah.gnu.org/viewcvs/paparazzi/paparazzi3/hw/ CVS]
Another alternative is the NAVILOCK NL-507TTL u-blox TTL Modul 60416 which is availible for 28€ (amazon.de).

===u-Blox SAM-LS GPS Smart Antenna===
[[Image:Ublox_SAM-LS.jpg|100px|thumb|right|u-blox SAM-LS]]
The '''[[Classix]]''' and '''[[Previous_Autopilots|AVR-based]]''' boards use a stand alone module from u-blox called the SAM-LS. It is an integrated TIM-LP module with a ceramic patch antenna. This processor also runs on 4hz and must be configured to use the UBX protocol. With battery backup (3V watch battery) they show hot starts of around a couple seconds. The LEA-LA processor weighs a couple grams and the complete the SAM-LS module with antenna and shielding weighs about 20grams.

'''Note:''' Effective 12/2006 u-blox has begun to phase out the SAM-LS product. No replacement will be offered.

====Connecting external receivers to Classix, 1.2.1, Lite, and RoboStix boards====

The u-blox receivers require 3.3v power and all current models have 5V tolerant data lines. The best way to connect to the SAM-LS is to remove the bottom case and solder the 4 wires directly to the TIM-LL module (GND (pin 1) ,VCC (pin 2),TX (Pin 5),RX (pin 4)) check the TIM-LL datasheet for pinout diagrams. The Classix and Lite boards feature a 3.3V regulator to power the GPS.

===Sourcing from u-blox===

u-blox keeps tight control over the distribution of their products. They must be obtained DIRECTLY from their own reseller offices. These offices may not be available in your area, for example Canada does not have a reseller. Sample quantities can be obtained from uBlox but overnight or 2 day shipping is required which drives the cost up considerably. While it is a large hassle obtaining these devices, it is undoubtedly worth it.

Talking with ublox sale for two years, Confirmed, that Order is possiable Directly from ublox, by knowing what project it was for & how was it to be use. After long reply waiting time, the answer was: - YES, but at least 2K-3K in volume, otherwise they're not interested. Like to share the order ? It is 500pcs/Roll.

===Other potential source of u-blox GPS===

There seems to be a few alternative source of u-blox GPS out there. They are considerably cheaper then the samples u-blox offers (at least in america). We didn't buy from these sources yet. Do not take this as a recommandation, we do not know the level of service they offer, etc.

If you do order from any of them, please update this page with your feedback.

Here's a few link worth exploring:
*http://www.rfdesign.co.za/pages/5645456/Products/GPS-Products/Antaris-4-Modules.asp
*http://www.comet.srl.ro/shop/info.html?ID=6195 ( Link error )
*http://www.expedienttech.com/product.htm ( Singapore )
*http://shop.halfbase.com/index.php/cPath/22?osCsid=414472d5a544b080f9ae153fdc323798 ( B2B- min.10pcs @ $38 )

===Standalone GPS Module from CVS===
The Version 1 (V1) BOM is here.. Please post any pics you might have and check this for accuracy<br>
[http://paparazzi.enac.fr/wiki_images/Gps_13_BOM.xls V1 BOM]<br>
[http://paparazzi.enac.fr/wiki_images/TinygpsBOM.txt Eagle Parts List Output]<br>

[[Image:LEA5HExternalModulePinout.jpg|250px|thumb|right|LEA-5H Full Board Pinout]]

If this needs fixing don't be shy, fix away.

==GPS configuration using U-Center==

[[Image:U-center_screencap.jpg|thumb|u-center configuration software]]
[http://www.u-blox.com/products/u_center.html U-Center] is a very comprehensive freeware program intended for the configuration and evaluation of u-blox receivers.
* [http://www.u-blox.com/products/u_center.html Download u-center]

* Note: You must [[Compiling#USB_flashing|install the UART tunnel]] to enable direct access to the built-in GPS on the [[Tiny|Tiny]].
* Note: You can run u-center on Linux by installing "wine" ([http://www.winehq.org/site/download-deb Installation of Wine]) and setting up com1 as /dev/ttyUSB0 See Info on wine for "dosdevices" setup. Just download the u-setup.exe and run it with wine, follow prompts. This has been tested with Ubuntu7.10 so far.
* Note: You will need a driver for your FTDI cable if you run u-center on Windows, which can be found [http://www.ftdichip.com/Drivers/D2XX.htm here].
The u-blox and Tiny UARTs both operate at 3.3V TTL levels and are 5V TTL tolerant. You must use a level shifter such as the common MAX232 to connect these devices to a standard PC serial port. The easiest and most recommended method is to connect to a USB port instead of serial with the $20 [http://www.ftdichip.com/Products/EvaluationKits/TTL-232R.htm FTDI USB-TTL converter cable] available from Digikey, Mouser, or direct from FTDI. Other similar converters are available from [http://www.pololu.com/products/pololu/0391/ pololu] / [http://www.sparkfun.com/commerce/product_info.php?products_id=199 sparkfun] or [http://shop.halfbase.com/product_info.php/products_id/54 Halfbase]. A stand-alone GPS such as the SAM-LS will require clean 3.3V/50mA power and a common ground with the TTL converter.

* U-blox occasionally releases firmware updates. Log on to the u-blox website using ''paparazzi'' for username & password to view or download the latest firmware images. There have 'never' been any updates released for the Antaris-4 series used in the Tiny.

Start U-center and choose your com port from the pull down list under the connect button near the top left corner of the window. Choose your baudrate from the pull down box to the right of the connect button or select the auto-baud button to the right of that. U-blox default is 9600 baud. This must be changed to 19200 or higher to accomodate the 4Hz update rate.
<br>[[Image:U-center_buttons.jpg|connect, baud, and autobaud buttons]]
<br style="clear:both">

===Uploading the Configuration File===
Download the appropriate configuration file below and use u-center to load in onto your receiver. Under the ''Tools'' menu, choose ''GPS configuration''. Be sure the box 'Store configuration into BBR/Flash' is checked and hit the button ''File>>GPS''. A few errors and retries are normal, but a significant number of errors may indicate a poor connection and the software will notify you if it is unable to send all the data successfully.
* [[Media:Tiny_LEA-4P-v6.zip|LEA-4P]]
* [[Media:Tim-LL-V5.zip|TIM-LL]]
* [http://paparazzi.enac.fr/wiki_images/Tiny_LEA-5H-v5.zip LEA-5H (For Use w/ Firmware V5 ONLY!)]

===Manual Configuration===
If you prefer to setup your receiver manually or have a model not listed above, here are instructions to configure your receiver in u-center.
Open the message window (menu View->messages view) to start the configuration process by changing the following settings:

====LEA-4P====

1. Right Click on the '''NMEA''' Icon and choose '''disable child'''
2. Choose UBX->CFG->NAV2(Navigation 2) - set it to use '''Airborne 4G''' (tells the Kalman filter to expect significant changes in direction)
3. UBX->CFG->PRT - set '''USART1''' to '''38400bps''' (must match the value in your [[Airframe_Configuration#Hardware_definitions_-_Makefile|Airframe file]])
4. Change the baudrate of U-Center to 38400bps if the connection is lost at this point
5. UBX->CFG->RXM(Receiver Manager) - change '''GPS Mode''' to '''3 - Auto''' (Enabling faster bootup only if signal levels are very good)
6. UBX->CFG->RATE(Rates) - change the '''Measurement Period''' to '''250ms''' (4 Hz position updates)
7. UBX->CFG->SBAS : '''Disable''' (SBAS appears to cause occasional severe altitude calcuation errors)
8. UBX->NAV (not UBX->CFG->NAV): double click on '''POSUTM, SOL, STATUS, SVINFO, VELNED.''' They should change from grey to black
9. UBX->CFG->CFG : '''save current config''', click '''"send"''' in the lower left corner to permanently save these settings to the receiver

====LEA-5H====

1. Right Click on the '''NMEA''' Icon and choose '''disable child'''
2. Choose UBX->CFG->NAV5(Navigation 5) - set it to use '''Airborne 8 >4G''' (tells the Kalman filter to expect significant changes in direction)
3. UBX->CFG->PRT - set '''USART1''' to '''38400bps''' (must match the value in your [[Airframe_Configuration#Hardware_definitions_-_Makefile|Airframe file]])
4. Change the baudrate of U-Center to 38400bps if the connection is lost at this point
5. UBX->CFG->RATE(Rates) - change the '''Measurement Period''' to '''250ms''' (4 Hz position updates)
6. UBX->CFG->SBAS : '''Disable''' (SBAS appears to cause occasional severe altitude calcuation errors)
7. UBX->NAV (not UBX->CFG->NAV): double click on '''POSLLH, SOL, STATUS, SVINFO, VELNED.''' They should change from grey to black
(add the flag -DGPS_USE_LATLONG in your [[Airframe_Configuration#Hardware_definitions_-_Makefile|Airframe file]])
8. UBX->CFG->CFG : '''save current config''', click '''"send"''' in the lower left corner to permanently save these settings to the receiver

* Cycle the power and verify that the new configuration was saved
* To reset the receiver to the factory defaults go to ''UBX->CFG->CFG'', select 'Revert to default configuration', and click ''Send'' at the bottom left corner. To permanently save these values choose 'Save current configuration' and click ''Send''.
* To backup the configuration to a file on your PC: under the tools menu, choose GPS configuration, then click GPS>>file. This file can be re-loaded in a similar manner to configure additional identical receivers. Be sure the box 'Store configuration into BBR/Flash' is checked when reloading a configuration file to make the changes permanent.
* To update the firmware on a LEA-5H get u-center >= 5.03, revert the GPS receiver to the default configuration, get an appropriate image from u-blox (fitting your receivers serial number), find the flash identification flash.txt file in the u-center install directory and be prepared to wait a long time.

#NOTE: If you have a Tiny with LEA-5H module you must use u-center and manually setup the parameters as shown above (at least switch to 38400 baud manually before transferring the configuration file).
#NOTE: POSUTM is not available on LEA-5H. Instead, use POSLLH. Additionally, add the flag -DGPS_USE_LATLONG in the makefile section of the airframe xml file.

===Reset to Default Settings===
The GPS module can be reset to its original default settings by pulling BOOT_INT high(3.3V) during a power cycle ([http://www.u-blox.com/customersupport/gps.g4/ANTARIS4_Modules_SIM(GPS.G4-MS4-05007).pdf Antaris Manual, p. 122]). It may be required after a wrong firmware upgrade or a bad configuration change.

===DGPS (Differential GPS)===
Differential GPS is any method of improving GPS accuracy by comparing the GPS-indicated position of a nearby location to the known value and transmitting any error to the mobile unit. DGPS was originally created as a means of bypassing the deliberately introduced inaccuracies in civilian GPS signals. The original method used low frequency ground radios to relay correction data to the mobile unit and is still used today at airports, shipping ports, and even individual farms. Satellite Based Augmentation System (SBAS) is a modern form of DGPS where the ground stations relay correction data to a GEO-Stationary satellite, which then relays it to the mobile unit on standard GPS frequencies eliminating the need for a separate radio reciever. SBAS is currently available in 3 regions, [http://www.environmental-studies.de/Precision_Farming/EGNOS_WAAS__E/3E.html WAAS, EGNOS, and MSAS] though only WAAS is officially operational. U-blox receivers support all common varieties of DGPS [http://www.u-blox.com/customersupport/gps.g3/ENGOS_Issues(GPS.G3-CS-04009).pdf read the u-blox SBAS application note].
* It is important to note that DGPS methods only improve the ''accuracy'' of the position calculation, not the ''precision''. Since Paparazzi navigation is typically performed relative to the power-on location, any static error that could be corrected with DGPS is irrelevant.

====WAAS issues====
WAAS has been officially operational and "suitable for safety-of-life applications" since 2003. The default setting of all u-blox receivers ignores WAAS correction data and only uses the WAAS satellites for regular navigation like any other satellite. U-blox recommends further limiting this setting to exclude any stray EGNOS/MSAS satellites in North America, and completely disabling all SBAS functions for use outside North America. In 2006 one formerly reliable Paparazzi aircraft began having great GPS problems and displaying very erratic altitude calculations, disabling WAAS immediately resolved the issue and this phenomenon was recreated several times for verification. Turns out a new WAAS satellite was being added to the system and the others were being moved that week for better distribution. Our advice is to completely disable WAAS.

====EGNOS issues====
EGNOS is officially in "testing mode" and no claims of reliability are made. The [http://www.u-blox.com/customersupport/faq_antaris u-blox FAQ] states the following:
* "Do you see issues with EGNOS?"
*:"Yes. Although the data transmitted by the EGNOS satellites are usually good and valuable (e.g. during the solar storms in autumn 2003), they can sometimes be very unreliable, for example when system tests are performed. As an example, u-blox has noticed erroneous range information (up to three hundred kilometers) on various EGNOS satellite over the last few months [2006]."

===Further Reading===

The u-blox [http://www.u-blox.com/customersupport/antaris4_doc.html System Integration Manual] covers a lot of GPS theory as well as product specific topics.

== Antenna options for the Tiny and Paparazzi GPS units ==

The '''[[Tiny|Tiny 1.1]]''' features a 28mm square ground plane intended to be centered below the [[#Sangshin_13mm_Patch|Sangshin 13mm patch antenna]]. Much better performance has been seen with the 18mm antennas and an augmented ground plane. The ground plane is a critical part of the antenna affecting not only the gain and polarization characteristics but also the center frequency of the system. Users are advised to expand the ground plane to approximately 36mm square, centered on the ceramic portion of the antenna (not the pin). This can be done with copper foil soldered to the vias of the existing ground plane.
[[image:gps_antenna_comparison.jpg|thumb|500px|left|SAM-LS 25mm / Emtac 20mm / Emtac 18mm / Sangshin 18mm / Sangshin 13mm / Sarantel P2]]
<br style="clear:both">

=== Sangshin 18mm Patch ===
[[image:Sangshin_18mm.jpg|thumb|Sangshin 18mm x 4mm 1580Mhz]]
The Sangshin KSA-ST1580MS18 antenna has proven to offer the best performance of the currently available options. These are available from any Sanshin distributor such as [http://www.rfmw.com rfmw] ([http://www.rfmw.com/PortalProductDetail.aspx?ProdId=232436&fmt=1 here]) and cost approximately $6.50/ea. in small quantities.

<br style="clear:both">

=== EMTAC 18mm Patch ===
[[image:Emtac_18mm.jpg|thumb|Emtac 18mm x 4mm 1580Mhz]]
Offering identical performance to the Sangshin in a less attractive package is the Emtac 18mm antenna. The part number for the standard 1580MHz 18x18x4mm is ANA1580T18D40 and is not listed on their website. Other frequencies are available on a special order basis and the 1584Mhz has proven to outperform all other frequencies when used with a 36mm ground plane and no radome. The use of a radome (any material covering the antenna) or a larger ground plane should theoretically favor even higher frequencies.

'''Availability'''

* [http://www.transplantgps.com/modules.html TransplantGPS] in MN, USA. The 1580Mhz models are usually available at a cost of $3.55ea but there may be a minimum order requirement of ~$50 USD.
* [http://www.onefastdaddy.com/catalog/product_info.php?products_id=43 PPZUAV] ~$10.00 USD (no min. order requirement)
<br style="clear:both">

=== Sangshin 13mm Patch ===

[[image:Sangshin_13mm_onboard.jpg|thumb|Sangshin 13mm x 4mm 1580Mhz]]
Part of interest: '''[http://www.sangshinec.com/eng/patch_spec.htm KSA-ST1580MS13]'''

The Tiny 0.99 (not 0.9) and 1.1 were designed around this antenna but users are advised to install 18mm units for better performance.

Size: 13 x 13 mm<br/>
Center Frequency: 1580 MHz<br/>
Bandwidth: 5 MHz<br/>
@Fo: -15 dB<br/>
GAIN (dBi): 0 dBi<br/>
Ground Plane: 50 x 50 mm<br/>

'''Available From'''

[http://www.systroninc.com/ Systronic INC.] - Alberta, Canada
<br style="clear:both">

=== Emtac 20mm Patch ===

[[image:Salvaged_20mm_onboard.jpg|thumb|Emtac 20mm x 4mm]]
The Tiny 0.9 was designed around this 1583Mhz antenna and performed extremely well. Emtac has replaced this with an 18mm model that they claim offers even better performance.

* Obsolete
<br style="clear:both">

=== Sarantel GeoHelix-P2 ===

[[image:Geohelix-p2.jpg|thumb|Sarantel Geohelix P-2 1575Mhz]]

This antenna is popular among UAV designers due to it's natural rejection of other radio frequencies such as those originating from the modem or video system as well as it's improved rejection of signals reflected from the ground. U-blox recommends this antenna and features it in their [http://www.u-blox.com/news/sarantel.html reference design]. Frequency and polarization are not dependent upon ground plane geometry so this antenna is sold only in the true GPS frequency of 1575Mhz.
The geometry makes this antenna very inconvenient to mount, especially in an airplane. Some very non-scientific testing has been done with one of these antennas connected to a Tiny with a short length of 50 Ohm coax above a 120mm square of ungrounded aluminum foil and performance was adequate. The helical design should theoretically outperform a patch in the air, but not on the ground, so any organized comparison will be difficult. Possibly the most important aspect of this antenna is it's natural RFI filtering, which should be evaluated further.

* [http://www.sarantel.com/products/geohelix-p2 GeoHelix-P2] Passive GPS Antenna [[http://www.sarantel.com/downloads/specifications/geohelix-p2.pdf datasheet]]

'''Availability'''

* Sarantel @ cost of approx $18 USD each (active versions available for ~$40)
<br style="clear:both">
* [http://www.onefastdaddy.com/catalog/product_info.php?products_id=40&osCsid=709e839698120c5cd324072b77d67cc1 PPZUAV]

Sensors/GPS

2008-09-01T20:06:06Z

Rcbrother: /* Standalone GPS Module from CVS */

{| align=right
|-
| __TOC__
|}

==Overview==
[[Image:U-blox_color_warm_60.gif|100px]]

Paparazzi autopilots are designed around the popular [http://www.u-blox.com u-blox] brand of receivers.

*Features:
**Small size
**Excellent performance
**4Hz position update rate

The '''[[Tiny]]''' features an onboard LEA series GPS receiver and patch antenna, while '''[[Classix]]''' and '''[[Previous_Autopilots|AVR-based]]''' boards require an external receiver+antenna such as the [[#Paparazzi_Stand-alone_GPS_Receivers|Paparazzi GPS]] or [[#u-Blox_SAM-LS_GPS_Smart_Antenna|SAM-LS]]. Please note that the receivers must be configured (prior to use with the autopilot) as indicated below. Both modules have proven reliable and robust.

{|align = center
|-
|[[Image:Lea big.jpg|200px|thumb|center|u-blox LEA GPS Receiver]]
|[[Image:Ublox_SAM-LS.jpg|200px|thumb|center|u-blox SAM-LS GPS receiver (w/built-in Smart Antenna)]]
|}

'''Note:''' The proprietary UBX protocol is used as it offers more information and efficiency than the universal NMEA protocol. The protocol is parsed in <tt>sw/airborne/gps_ubx.c</tt>. Other GPS brands would require a similar parsing file to be written for NMEA or other proprietary protocols.

==GPS Receivers==

===u-Blox LEA Series Receivers===
[[Image:Lea big.jpg|100px|thumb|right|u-blox LEA]]
The '''[[Tiny]]''' and Paparazzi stand-alone GPS currently use the [http://www.u-blox.com/products/lea_4p.html u-blox LEA-4P] featuring [http://www.u-blox.com/technology/antaris4/index.html Antaris-4] technology and uBlox's more efficient UBX binary protocol. This module is a surface mount package which is soldered directly onto the PCB (Tiny or Paparazzi GPS). An external battery backup (capacitor) is used to enable the GPS to retain data while powered off for significantly faster signal re-aquisition. Any of the LEA-4x series receivers can be used including the less expensive LEA-4A and 4S models as the special boot configuration code required for these models is already written.

*4Hz Position update rate
*Supports active or passive antennas
*Supports [http://en.wikipedia.org/wiki/DGPS DGPS], [http://en.wikipedia.org/wiki/WAAS WAAS], [http://en.wikipedia.org/wiki/EGNOS EGNOS], and [http://en.wikipedia.org/wiki/MSAS MSAS]

[[Image:TINY_1.3_MCU_BOTTOM.JPG|thumb|center|250px|LEA-4P installed on the Tiny]]
<br style="clear:both">

===Paparazzi Stand-alone GPS Receivers===
There are currently two (LEA-based) stand-alone, GPS receiver + antenna, prototype boards in development; the first one is based on the Sangshin 13mm patch antenna. The second is based on the Sarantel helix antenna. Drawings for both are available from the [http://cvs.savannah.gnu.org/viewcvs/paparazzi/paparazzi3/hw/ CVS]
Another alternative is the NAVILOCK NL-507TTL u-blox TTL Modul 60416 which is availible for 28€ (amazon.de).

===u-Blox SAM-LS GPS Smart Antenna===
[[Image:Ublox_SAM-LS.jpg|100px|thumb|right|u-blox SAM-LS]]
The '''[[Classix]]''' and '''[[Previous_Autopilots|AVR-based]]''' boards use a stand alone module from u-blox called the SAM-LS. It is an integrated TIM-LP module with a ceramic patch antenna. This processor also runs on 4hz and must be configured to use the UBX protocol. With battery backup (3V watch battery) they show hot starts of around a couple seconds. The LEA-LA processor weighs a couple grams and the complete the SAM-LS module with antenna and shielding weighs about 20grams.

'''Note:''' Effective 12/2006 u-blox has begun to phase out the SAM-LS product. No replacement will be offered.

====Connecting external receivers to Classix, 1.2.1, Lite, and RoboStix boards====

The u-blox receivers require 3.3v power and all current models have 5V tolerant data lines. The best way to connect to the SAM-LS is to remove the bottom case and solder the 4 wires directly to the TIM-LL module (GND (pin 1) ,VCC (pin 2),TX (Pin 5),RX (pin 4)) check the TIM-LL datasheet for pinout diagrams. The Classix and Lite boards feature a 3.3V regulator to power the GPS.

===Sourcing from u-blox===

u-blox keeps tight control over the distribution of their products. They must be obtained DIRECTLY from their own reseller offices. These offices may not be available in your area, for example Canada does not have a reseller. Sample quantities can be obtained from uBlox but overnight or 2 day shipping is required which drives the cost up considerably. While it is a large hassle obtaining these devices, it is undoubtedly worth it.

Talking with ublox sale for two years, Confirmed, that Order is possiable Directly from ublox, by knowing what project it was for & how was it to be use. After long reply waiting time, the answer was: - YES, but at least 2K-3K in volume, otherwise they're not interested. Like to share the order ? It is 500pcs/Roll.

===Other potential source of u-blox GPS===

There seems to be a few alternative source of u-blox GPS out there. They are considerably cheaper then the samples u-blox offers (at least in america). We didn't buy from these sources yet. Do not take this as a recommandation, we do not know the level of service they offer, etc.

If you do order from any of them, please update this page with your feedback.

Here's a few link worth exploring:
*http://www.rfdesign.co.za/pages/5645456/Products/GPS-Products/Antaris-4-Modules.asp
*http://www.comet.srl.ro/shop/info.html?ID=6195 ( Link error )
*http://www.expedienttech.com/product.htm ( Singapore )
*http://shop.halfbase.com/index.php/cPath/22?osCsid=414472d5a544b080f9ae153fdc323798 ( B2B- min.10pcs @ $38 )

===Standalone GPS Module from CVS===
The Version 1 (V1) BOM is here.. Please post any pics you might have and check this for accuracy<br>
[http://paparazzi.enac.fr/wiki_images/Gps_13_BOM.xls V1 BOM]<br>
[http://paparazzi.enac.fr/wiki_images/TinygpsBOM.txt Eagle Parts List Output]<br>
If this needs fixing don't be shy, fix away.

[[Image:LEA5HExternalModulePinout.jpg|250px|thumb|left|LEA-5H Full Board Pinout]]

==GPS configuration using U-Center==

[[Image:U-center_screencap.jpg|thumb|u-center configuration software]]
[http://www.u-blox.com/products/u_center.html U-Center] is a very comprehensive freeware program intended for the configuration and evaluation of u-blox receivers.
* [http://www.u-blox.com/products/u_center.html Download u-center]

* Note: You must [[Compiling#USB_flashing|install the UART tunnel]] to enable direct access to the built-in GPS on the [[Tiny|Tiny]].
* Note: You can run u-center on Linux by installing "wine" ([http://www.winehq.org/site/download-deb Installation of Wine]) and setting up com1 as /dev/ttyUSB0 See Info on wine for "dosdevices" setup. Just download the u-setup.exe and run it with wine, follow prompts. This has been tested with Ubuntu7.10 so far.
* Note: You will need a driver for your FTDI cable if you run u-center on Windows, which can be found [http://www.ftdichip.com/Drivers/D2XX.htm here].
The u-blox and Tiny UARTs both operate at 3.3V TTL levels and are 5V TTL tolerant. You must use a level shifter such as the common MAX232 to connect these devices to a standard PC serial port. The easiest and most recommended method is to connect to a USB port instead of serial with the $20 [http://www.ftdichip.com/Products/EvaluationKits/TTL-232R.htm FTDI USB-TTL converter cable] available from Digikey, Mouser, or direct from FTDI. Other similar converters are available from [http://www.pololu.com/products/pololu/0391/ pololu] / [http://www.sparkfun.com/commerce/product_info.php?products_id=199 sparkfun] or [http://shop.halfbase.com/product_info.php/products_id/54 Halfbase]. A stand-alone GPS such as the SAM-LS will require clean 3.3V/50mA power and a common ground with the TTL converter.

* U-blox occasionally releases firmware updates. Log on to the u-blox website using ''paparazzi'' for username & password to view or download the latest firmware images. There have 'never' been any updates released for the Antaris-4 series used in the Tiny.

Start U-center and choose your com port from the pull down list under the connect button near the top left corner of the window. Choose your baudrate from the pull down box to the right of the connect button or select the auto-baud button to the right of that. U-blox default is 9600 baud. This must be changed to 19200 or higher to accomodate the 4Hz update rate.
<br>[[Image:U-center_buttons.jpg|connect, baud, and autobaud buttons]]
<br style="clear:both">

===Uploading the Configuration File===
Download the appropriate configuration file below and use u-center to load in onto your receiver. Under the ''Tools'' menu, choose ''GPS configuration''. Be sure the box 'Store configuration into BBR/Flash' is checked and hit the button ''File>>GPS''. A few errors and retries are normal, but a significant number of errors may indicate a poor connection and the software will notify you if it is unable to send all the data successfully.
* [[Media:Tiny_LEA-4P-v6.zip|LEA-4P]]
* [[Media:Tim-LL-V5.zip|TIM-LL]]
* [http://paparazzi.enac.fr/wiki_images/Tiny_LEA-5H-v5.zip LEA-5H (For Use w/ Firmware V5 ONLY!)]

===Manual Configuration===
If you prefer to setup your receiver manually or have a model not listed above, here are instructions to configure your receiver in u-center.
Open the message window (menu View->messages view) to start the configuration process by changing the following settings:

====LEA-4P====

1. Right Click on the '''NMEA''' Icon and choose '''disable child'''
2. Choose UBX->CFG->NAV2(Navigation 2) - set it to use '''Airborne 4G''' (tells the Kalman filter to expect significant changes in direction)
3. UBX->CFG->PRT - set '''USART1''' to '''38400bps''' (must match the value in your [[Airframe_Configuration#Hardware_definitions_-_Makefile|Airframe file]])
4. Change the baudrate of U-Center to 38400bps if the connection is lost at this point
5. UBX->CFG->RXM(Receiver Manager) - change '''GPS Mode''' to '''3 - Auto''' (Enabling faster bootup only if signal levels are very good)
6. UBX->CFG->RATE(Rates) - change the '''Measurement Period''' to '''250ms''' (4 Hz position updates)
7. UBX->CFG->SBAS : '''Disable''' (SBAS appears to cause occasional severe altitude calcuation errors)
8. UBX->NAV (not UBX->CFG->NAV): double click on '''POSUTM, SOL, STATUS, SVINFO, VELNED.''' They should change from grey to black
9. UBX->CFG->CFG : '''save current config''', click '''"send"''' in the lower left corner to permanently save these settings to the receiver

====LEA-5H====

1. Right Click on the '''NMEA''' Icon and choose '''disable child'''
2. Choose UBX->CFG->NAV5(Navigation 5) - set it to use '''Airborne 8 >4G''' (tells the Kalman filter to expect significant changes in direction)
3. UBX->CFG->PRT - set '''USART1''' to '''38400bps''' (must match the value in your [[Airframe_Configuration#Hardware_definitions_-_Makefile|Airframe file]])
4. Change the baudrate of U-Center to 38400bps if the connection is lost at this point
5. UBX->CFG->RATE(Rates) - change the '''Measurement Period''' to '''250ms''' (4 Hz position updates)
6. UBX->CFG->SBAS : '''Disable''' (SBAS appears to cause occasional severe altitude calcuation errors)
7. UBX->NAV (not UBX->CFG->NAV): double click on '''POSLLH, SOL, STATUS, SVINFO, VELNED.''' They should change from grey to black
(add the flag -DGPS_USE_LATLONG in your [[Airframe_Configuration#Hardware_definitions_-_Makefile|Airframe file]])
8. UBX->CFG->CFG : '''save current config''', click '''"send"''' in the lower left corner to permanently save these settings to the receiver

* Cycle the power and verify that the new configuration was saved
* To reset the receiver to the factory defaults go to ''UBX->CFG->CFG'', select 'Revert to default configuration', and click ''Send'' at the bottom left corner. To permanently save these values choose 'Save current configuration' and click ''Send''.
* To backup the configuration to a file on your PC: under the tools menu, choose GPS configuration, then click GPS>>file. This file can be re-loaded in a similar manner to configure additional identical receivers. Be sure the box 'Store configuration into BBR/Flash' is checked when reloading a configuration file to make the changes permanent.
* To update the firmware on a LEA-5H get u-center >= 5.03, revert the GPS receiver to the default configuration, get an appropriate image from u-blox (fitting your receivers serial number), find the flash identification flash.txt file in the u-center install directory and be prepared to wait a long time.

#NOTE: If you have a Tiny with LEA-5H module you must use u-center and manually setup the parameters as shown above (at least switch to 38400 baud manually before transferring the configuration file).
#NOTE: POSUTM is not available on LEA-5H. Instead, use POSLLH. Additionally, add the flag -DGPS_USE_LATLONG in the makefile section of the airframe xml file.

===Reset to Default Settings===
The GPS module can be reset to its original default settings by pulling BOOT_INT high(3.3V) during a power cycle ([http://www.u-blox.com/customersupport/gps.g4/ANTARIS4_Modules_SIM(GPS.G4-MS4-05007).pdf Antaris Manual, p. 122]). It may be required after a wrong firmware upgrade or a bad configuration change.

===DGPS (Differential GPS)===
Differential GPS is any method of improving GPS accuracy by comparing the GPS-indicated position of a nearby location to the known value and transmitting any error to the mobile unit. DGPS was originally created as a means of bypassing the deliberately introduced inaccuracies in civilian GPS signals. The original method used low frequency ground radios to relay correction data to the mobile unit and is still used today at airports, shipping ports, and even individual farms. Satellite Based Augmentation System (SBAS) is a modern form of DGPS where the ground stations relay correction data to a GEO-Stationary satellite, which then relays it to the mobile unit on standard GPS frequencies eliminating the need for a separate radio reciever. SBAS is currently available in 3 regions, [http://www.environmental-studies.de/Precision_Farming/EGNOS_WAAS__E/3E.html WAAS, EGNOS, and MSAS] though only WAAS is officially operational. U-blox receivers support all common varieties of DGPS [http://www.u-blox.com/customersupport/gps.g3/ENGOS_Issues(GPS.G3-CS-04009).pdf read the u-blox SBAS application note].
* It is important to note that DGPS methods only improve the ''accuracy'' of the position calculation, not the ''precision''. Since Paparazzi navigation is typically performed relative to the power-on location, any static error that could be corrected with DGPS is irrelevant.

====WAAS issues====
WAAS has been officially operational and "suitable for safety-of-life applications" since 2003. The default setting of all u-blox receivers ignores WAAS correction data and only uses the WAAS satellites for regular navigation like any other satellite. U-blox recommends further limiting this setting to exclude any stray EGNOS/MSAS satellites in North America, and completely disabling all SBAS functions for use outside North America. In 2006 one formerly reliable Paparazzi aircraft began having great GPS problems and displaying very erratic altitude calculations, disabling WAAS immediately resolved the issue and this phenomenon was recreated several times for verification. Turns out a new WAAS satellite was being added to the system and the others were being moved that week for better distribution. Our advice is to completely disable WAAS.

====EGNOS issues====
EGNOS is officially in "testing mode" and no claims of reliability are made. The [http://www.u-blox.com/customersupport/faq_antaris u-blox FAQ] states the following:
* "Do you see issues with EGNOS?"
*:"Yes. Although the data transmitted by the EGNOS satellites are usually good and valuable (e.g. during the solar storms in autumn 2003), they can sometimes be very unreliable, for example when system tests are performed. As an example, u-blox has noticed erroneous range information (up to three hundred kilometers) on various EGNOS satellite over the last few months [2006]."

===Further Reading===

The u-blox [http://www.u-blox.com/customersupport/antaris4_doc.html System Integration Manual] covers a lot of GPS theory as well as product specific topics.

== Antenna options for the Tiny and Paparazzi GPS units ==

The '''[[Tiny|Tiny 1.1]]''' features a 28mm square ground plane intended to be centered below the [[#Sangshin_13mm_Patch|Sangshin 13mm patch antenna]]. Much better performance has been seen with the 18mm antennas and an augmented ground plane. The ground plane is a critical part of the antenna affecting not only the gain and polarization characteristics but also the center frequency of the system. Users are advised to expand the ground plane to approximately 36mm square, centered on the ceramic portion of the antenna (not the pin). This can be done with copper foil soldered to the vias of the existing ground plane.
[[image:gps_antenna_comparison.jpg|thumb|500px|left|SAM-LS 25mm / Emtac 20mm / Emtac 18mm / Sangshin 18mm / Sangshin 13mm / Sarantel P2]]
<br style="clear:both">

=== Sangshin 18mm Patch ===
[[image:Sangshin_18mm.jpg|thumb|Sangshin 18mm x 4mm 1580Mhz]]
The Sangshin KSA-ST1580MS18 antenna has proven to offer the best performance of the currently available options. These are available from any Sanshin distributor such as [http://www.rfmw.com rfmw] ([http://www.rfmw.com/PortalProductDetail.aspx?ProdId=232436&fmt=1 here]) and cost approximately $6.50/ea. in small quantities.

<br style="clear:both">

=== EMTAC 18mm Patch ===
[[image:Emtac_18mm.jpg|thumb|Emtac 18mm x 4mm 1580Mhz]]
Offering identical performance to the Sangshin in a less attractive package is the Emtac 18mm antenna. The part number for the standard 1580MHz 18x18x4mm is ANA1580T18D40 and is not listed on their website. Other frequencies are available on a special order basis and the 1584Mhz has proven to outperform all other frequencies when used with a 36mm ground plane and no radome. The use of a radome (any material covering the antenna) or a larger ground plane should theoretically favor even higher frequencies.

'''Availability'''

* [http://www.transplantgps.com/modules.html TransplantGPS] in MN, USA. The 1580Mhz models are usually available at a cost of $3.55ea but there may be a minimum order requirement of ~$50 USD.
* [http://www.onefastdaddy.com/catalog/product_info.php?products_id=43 PPZUAV] ~$10.00 USD (no min. order requirement)
<br style="clear:both">

=== Sangshin 13mm Patch ===

[[image:Sangshin_13mm_onboard.jpg|thumb|Sangshin 13mm x 4mm 1580Mhz]]
Part of interest: '''[http://www.sangshinec.com/eng/patch_spec.htm KSA-ST1580MS13]'''

The Tiny 0.99 (not 0.9) and 1.1 were designed around this antenna but users are advised to install 18mm units for better performance.

Size: 13 x 13 mm<br/>
Center Frequency: 1580 MHz<br/>
Bandwidth: 5 MHz<br/>
@Fo: -15 dB<br/>
GAIN (dBi): 0 dBi<br/>
Ground Plane: 50 x 50 mm<br/>

'''Available From'''

[http://www.systroninc.com/ Systronic INC.] - Alberta, Canada
<br style="clear:both">

=== Emtac 20mm Patch ===

[[image:Salvaged_20mm_onboard.jpg|thumb|Emtac 20mm x 4mm]]
The Tiny 0.9 was designed around this 1583Mhz antenna and performed extremely well. Emtac has replaced this with an 18mm model that they claim offers even better performance.

* Obsolete
<br style="clear:both">

=== Sarantel GeoHelix-P2 ===

[[image:Geohelix-p2.jpg|thumb|Sarantel Geohelix P-2 1575Mhz]]

This antenna is popular among UAV designers due to it's natural rejection of other radio frequencies such as those originating from the modem or video system as well as it's improved rejection of signals reflected from the ground. U-blox recommends this antenna and features it in their [http://www.u-blox.com/news/sarantel.html reference design]. Frequency and polarization are not dependent upon ground plane geometry so this antenna is sold only in the true GPS frequency of 1575Mhz.
The geometry makes this antenna very inconvenient to mount, especially in an airplane. Some very non-scientific testing has been done with one of these antennas connected to a Tiny with a short length of 50 Ohm coax above a 120mm square of ungrounded aluminum foil and performance was adequate. The helical design should theoretically outperform a patch in the air, but not on the ground, so any organized comparison will be difficult. Possibly the most important aspect of this antenna is it's natural RFI filtering, which should be evaluated further.

* [http://www.sarantel.com/products/geohelix-p2 GeoHelix-P2] Passive GPS Antenna [[http://www.sarantel.com/downloads/specifications/geohelix-p2.pdf datasheet]]

'''Availability'''

* Sarantel @ cost of approx $18 USD each (active versions available for ~$40)
<br style="clear:both">
* [http://www.onefastdaddy.com/catalog/product_info.php?products_id=40&osCsid=709e839698120c5cd324072b77d67cc1 PPZUAV]

File:LEA5HExternalModulePinout.jpg

2008-09-01T20:00:48Z

Rcbrother: LEA 5H pinout for connection to TWOG

LEA 5H pinout for connection to TWOG

Main Page

2008-08-30T21:26:15Z

Rcbrother:

__NOTOC__
__NOEDITSECTION__

{|style="border-spacing:8px;margin:0px -8px" class="MainPageBG" style="width:100%;border:1px solid #9999bf;background-color:#f5fffa;vertical-align:top;color:#000; text-align: left;"
|-
|align="center" colspan="2"| <h2 style="margin:0;background-color:#82add9;font-size:150%;font-weight:bold;border:1px solid #a3bfb1;text-align:center;color:#ffffff;padding:0.2em 0.4em;">Welcome To Paparazzi</h2>
|-valign="top"
|
<h3 style="-moz-border-radius-topright: 1em;-moz-border-radius-topleft: 1em;
background:#cedff2;margin:-2px;padding:4px;">
[[Image:favicon32.png|32px]] [[General|General]]
</h3>
<div style="padding:6px;">
{{General}}
</div>
<h3 style="-moz-border-radius-topright: 1em;-moz-border-radius-topleft: 1em;
background:#cedff2;margin:-2px;padding:4px;">
[[Image:favicon32.png|32px]] [[Hardware|Hardware]]
</h3>
<div style="padding:6px;">
{{Hardware}}
</div>
<h3 style="-moz-border-radius-topright: 1em;-moz-border-radius-topleft: 1em;
background:#cedff2;margin:-2px;padding:4px;">
[[Image:favicon32.png|32px]] [[Software|Software]]
</h3>
<div style="padding:6px;">
{{Software}}
</div>
<h3 style="-moz-border-radius-topright: 1em;-moz-border-radius-topleft: 1em;
background:#cedff2;margin:-2px;padding:4px;">
[[Image:favicon32.png|32px]] [[Miscellaneous|Miscellaneous]]
</h3>
<div style="padding:6px;">
{{Miscellaneous}}
</div>

| class="MainPageBG" style="width:70%;border:1px solid #cedff2;background-color:#f5faff;vertical-align:top"|
{|width="100%" cellpadding="2" cellspacing="5" style="vertical-align:top;background-color:#f5fffa"
|-valign="top"
| <h2 style="margin:0;background-color:#cef2e0;font-size:120%;font-weight:bold;border:1px solid #a3bfb1;text-align:left;color:#000;padding:0.2em 0.4em;">The Paparazzi Project</h2>
|-
|style="color:#000"|[http://www.nongnu.org/paparazzi Paparazzi] is a free and open-source hardware and software project intended to create an exceptionally powerful and versatile autopilot system by allowing and encouraging input from the community. The project includes not only the airborne hardware and software, from voltage regulators and GPS receivers to [http://en.wikipedia.org/wiki/Kalman_filtering Kalman filtering] code, but also a powerful and ever-expanding array of ground hardware and software including modems, antennas, and a highly evolved user-friendly ground control software interface.
|-
|All hardware and software is open-source and freely available to anyone under the [http://www.gnu.org GNU] licencing agreement. [[Get_Hardware| Several vendors]] are currently producing and selling Paparazzi autopilots and popular accessories, making the system easy and affordable to all.
|-
|The key feature of the paparazzi autopilot is its unique combination of infrared thermopiles and inertial measurement for attitude sensing, providing a robust and accurate attitude estimate that requires no ground calibration and can recover from any launch attitude.
|-
| <h2 style="margin:0;background-color:#cef2e0;font-size:120%;font-weight:bold;border:1px solid #a3bfb1;text-align:left;color:#000;padding:0.2em 0.4em;">The Paparazzi project at ENAC</h2>
|-
|The Paparazzi mini UAV project is now being used and developed at [http://www.enac.fr/ ENAC University].
|-
|style="color:#000"|
* A [http://www.debian.org debian] [http://www.recherche.enac.fr/paparazzi/debian repository] containing some packages not in the official distribution and required to run Paparazzi.
* PaparazziX [http://www.knoppix.net/ Knoppix] based live CD is available from the [http://www.recherche.enac.fr/paparazzi/paparazzix paparazzix directory].
* Nightly and release [http://www.recherche.enac.fr/paparazzi/tarball tarballs].
|-
{| width="100%" cellpadding="2" cellspacing="5" style="vertical-align:top;background-color:#faf5ff;border:1px solid #ddcef2; text-align: justify;"
| <h2 style="margin:0;background-color:#ddcef2;font-size:120%;font-weight:bold;border:1px solid #afa3bf;text-align:left;color:#000;padding:0.2em 0.4em;">News</h2>
|-
|<h3>June 23, 2008</h3>
|-
| style="color:#000"| [[Image:Targets auvsi 08.JPG|thumb|left]]
The [http://www.engr.usu.edu/wiki/index.php/OSAM OSAM] Paparazzi team took 2nd place in the Sixth Annual Student Unmanned Aerial Systems Competition! The event is sponsored by AUVSI (Association for Unmanned Vehicle Systems International) and was held at Webster Field, St. Inigoes, Maryland. It should also be noted that this was Paparazzi's and the OSAM Paparazzi team's first time at the competition.<br>
[http://www.navair.navy.mil/pma263/seafarers/default.htm Link to competition]
<br>
[http://hjnews.townnews.com/articles/2008/07/12/news/news01.txt News Story]

|-
|<h3>June 13, 2008</h3>
|-
| style="color:#000"| [[Image:Twog_v1-00_top_side_3.jpg|thumb|left|'''T'''iny '''W'''ith'''O'''ut '''G'''ps]]
The new baby autopilot is born.<br>
His name is TWOG, he weighs 8 grams and is 40.2 x 30.5mm long. He' in good health and looks a lot like his mother Tiny v2, except for the GPS receiver.<br>
The proud parents invite you to visit the [[Twog_v1|pictures and technical information album]]...

|-
|<h3>March 26, 2008</h3>
|-
| style="color:#000"| [[Image:Heli_deck.jpg|thumb|left|Funjet on the helicopter deck]]
Scientists from the [http://web.gfi.uib.no/index_e.html Geophysical Institute of the University of Bergen/Norway] flew Paparazzi controlled [[media:Funjet_spitsbergen.jpg|Funjet]] aircrafts equipped with meteorological sensors in the Arctic sea around Spitsbergen only with the help of a RC safety pilot and no Paparazzi team member nearby. They took off and landed on the helicopter deck of the Norwegian icebreaking coast guard vessel [http://www.jtashipphoto.dk/JTA-W303%20Svalbard.htm KV Svalbard] for one week and set a new Paparazzi low temperature record by flying at around -20°C and 15m/s wind in altitudes up to 1500m. For another two weeks they also collected data on Spitsbergen near Longyearbyen. See pictures in the gallery and a [http://www.youtube.com/watch?v=VWEa_4Hlm2s video].

|-
|<h3>March 15, 2008</h3>
|-
| style="color:#000"| [[Image:Tiny_v2-1_3D_top.jpg|thumb|left|Tiny 2.11]]
A number of vendors are now offering assembled and unassembled autopilots, sensors and accessories. The software is written, the hardware is built, what are you waiting for? Getting started has never been easier! More details on the [[Get_Hardware|Get Hardware]] page.

|-
|<h3>February 6, 2008</h3>
|-
| style="color:#000"| [[Image:eeePC.jpg|thumb|left|Paparazzi running on eeePC]]
Looking for a small, light and cheap ground station ? Paparazzi runs on the [http://eeepc.asus.com ASUS eeePC] out of the box (after installing the Debian Paparazzi packages). Tested on the pre-installed Xandros distribution, on a standard Ubuntu and on the preconfigured [http://wiki.eeeuser.com/ubuntu:eeexubuntu:home eeeXubuntu].

|-
|<h3>January 27, 2008</h3>
|-
| style="color:#000"| [[Image:StormTV.jpg|thumb|left|Paparazzi's Storm on TV in Turkey]] [http://www.showtvnet.com/haber/playerd.asp?ptype=haber&product=/270108/ucak.wmv Storm on TV], A Paparazzi aircraft is featured on the biggest Television station in Turkey. (Sorry, the audio is only in Turkish...)

|-
|<h3>[[News Archives]]</h3>
|-
| style="color:#000"|
[[Image:One_Small_Step.jpg|thumb|left|[[News Archives]]]] [[News Archives|Browse the archives]] for a look back at the earlier days of Paparazzi.
|-

|}
|}
|}

Modems

2008-08-30T21:08:00Z

Rcbrother: /* Maxstream XBee Pro XSC 900Mhz */

The Paparazzi autopilot features a 5V tolerant 3V TTL serial port to interface with any common radio modem. The bidirectional link provides real-time telemetry and in-flight tuning and navigation commands. The system is also capable overlaying the appropriate protocols to communicate thru non-transparent devices such as the Coronis Wavecard or Maxstream API-enabled products, allowing for hardware addressing for multiple aircraft or future enhancements such as data-relaying, inter-aircraft communication, RSSI signal monitoring and automatic in-flight modem power adjustment. Below is a list of some of the common modems used with Paparazzi, for details on configuring your modem see the [[Airframe_Configuration#Modem|Airframe Configuration]] page.

== Maxstream XBee Pro 2.4GHz (802.15.4, "Series 1") ==

These relatively cheap and light modules implement the [http://www.zigbee.org/en/index.asp ZigBee/IEEE 802.15.4] norm. They allow up to 1.6km (1 mile) range (Paparazzi tested to 2.5km (1.5 miles)). The main drawback of using such 2.4Ghz modules for datalink is that it will interfere with the 2.4Ghz analog video transmitters and a inevitable decrease in range when in proximity to any wifi devices.

{|
|-valign="top"
|[[Image:Xbee_Pro_USB_RF_Modem.jpg|thumb|left|XBee Pro USB Stand-alone Modem (XBP24-PKC-001-UA)]]
|
* Frequency Band 2.4Ghz
* Output Power 100mW (Xbee Pro)
* Sensitivity -100 dBm
* RF Data Rate Up to 250 Kbps
* Interface data rate Up to 115.2 Kbps
* Power Draw (typical) 214 mA TX / 55 mA RX
* Supply Voltage 3.3v
* Range (typical, depends on antenna & environment) Up to 1500m line-of-sight
* Dimensions 24 x 33mm
* Weight 4 grams
* Interface 20-pin mini connector
* Chip antenna, ¼ monopole integrated whip antenna or a U.FL antenna connector (3 versions)
* price : ~32$
|
[[Image:XBee_pro.jpg|thumb|left|XBee Pro OEM Modem]]
|}

=== Pinout ===

[[Image:Maxstream_Xbee_pinout.jpg|left|thumb|Maxstream XBee pinout]]
<br style="clear:both">

{|border="1"
|-valign="top"
||''Xbee 20-pin Header''||''Name''||''Notes''||''Suggested Color''||
|-
|1
| +3.3v
| Power
|Red
|-
|2
|DOUT
|Tx output - connect to Autopilot Rx
|Green
|-
|3
|DIN
|Rx input - connect to Autopilot Tx
|Blue
|-
|10
|GND
| Ground
|Black
|}

=== Documentation ===

* [http://www.maxstream.net/products/xbee/xbee-pro-oem-rf-module-zigbee.php product page]
* [http://www.maxstream.net/products/xbee/datasheet_XBee_OEM_RF-Modules.pdf datasheet]
* [http://www.maxstream.net/products/xbee/product-manual_XBee_OEM_RF-Modules.pdf user manual]

== Maxstream XBee Pro XSC 900Mhz ==

Maxstream has recently announced a promising new line of modems combining the small size and low cost of their popular Xbee line with the long range and 2.4Ghz video compatibility of their high end 900Mhz models. Sounds like the perfect modem for anyone who can use 900Mhz. Give them a try and post your results here!
{|
|-valign="top"
|[[Image:xbeeproxsc-rpsma.jpg|thumb|left|Maxstream XBee Pro XSC]]
|
* Frequency Band 900Mhz
* Output Power 100mW
* Sensitivity -100 dBm
* Data Rate: 9600 bps
* Range (typical, depends on antenna & environment) Up to 24km (15 miles) line-of-sight
* Interface 20-pin mini connector (Xbee compatible pinout)
* RPSMA, integrated whip antenna or U.FL antenna connector (3 versions)
* price : ~75 USD
|
|}
=== Documentation ===
* [http://www.digi.com/products/wireless/point-multipoint/xbee-pro-xsc.jsp http://www.digi.com/products/wireless/point-multipoint/xbee-pro-xsc.jsp]

== Maxstream 9XTend ==

These larger units have been tested on the 900Mhz band, but are also available in 2.4Ghz. They are a bit on the heavy side, about 20 grams, but give good performance at range. They have adjustable power settings from 100mW to 1W. Testing has shown range up to 3.2km (2 miles) with 100mW.

{|
|-valign="top"
|
[[Image:XTend_USB_RF_Modem.jpg|frame|left|9XTend USB Modem]]
|
* Frequency Band 900Mhz and 2.4Ghz (2 versions)
* Output Power 1mW to 1W software selectable
* Sensitivity -110 dBm (@ 9600 bps)
* RF Data Rate 9.6 or 115.2 Kbps
* Interface data rate up to 230.4 Kbps
* Power Draw (typical) 730 mA TX / 80 mA RX
* Supply Voltage 2.8 to 5.5v
* Range (typical, depends on antenna & environment) Up to 64km line-of-sight
* Dimensions 36 x 60 x 5mm
* Weight 18 grams
* Interface 20-pin mini connector
* RF connector RPSMA (Reverse-polarity SMA) or MMCX (2 versions)
* price : ~179 USD
|
[[Image:Xtend_module.jpg|frame|left|9XTend OEM Modem]]
|}

=== Pinout ===

[[Image:Maxstream_9XTend_Pinout.gif|thumb|left|Maxstream 9XTend Pinout]]

{| border="1"
|-valign="top"
||'''''9XTend 20-pin Header'''''||'''''Name'''''||'''''Tiny Serial-1 Header'''''||'''''Notes'''''
|-
||1||GND||1 (GND)||Ground
|-
||2||VCC||N/A (requires 5V)||5V power (150mA - 730mA Supplied from servo bus or other 5V source)
|-
||5||RX||8 (TX)||3-5V TTL data input - connect to Tiny TX
|-
||6||TX||7 (RX)||5V TTL data output - connect to Tiny RX
|-
||7||Shutdown||N/A (requires 5V)||Permanently connect this pin to the 5V bus for normal operation
|}
Notes:<br>
* 9XTend can run on voltages as low as 2.8V but users are strongly advised against connecting any modem (especially high power models) to the sensitive 3.3V bus supplying the autopilot processor and sensors.
<br style="clear:both">

=== Documentation ===

* [http://www.maxstream.net/products/xtend/oem-rf-module.php product page]
* [http://www.maxstream.net/products/xtend/datasheet_XTend_OEM_RF-Module.pdf datasheet]
* [http://www.maxstream.net/products/xtend/product-manual_XTend_OEM_RF-Module.pdf user manual]

== Aerocomm ==
Aerocomm's API mode is not yet implemented. Therefore they are used in transparent mode. Users are reporting these modems cause more interference with GPS reception then the Maxstream modem.

How to use this modem on ground station side? [http://paparazzi.enac.fr/wiki/index.php/User:SilaS#SDK-AC4868-250_ground_modem_part]

{|
|
=== AC4868-250 ===
* Frequency Band 868MHz (For Europe).
* Output Power (w/ 2dBi antenna) 250 mW
* Sensitivity (@ full RF data rate) -103 dB
* RF Data Rate Up to 28.8 Kbps
* INterface Data Rate Up to 57.6 Kbps
* Power Draw (typical) 240 mA TX / 36 mA RX
* Supply Voltage 3.3v & 5V or 3.3v only
* Range (typical, depends on antenna & environment) Up to 15 kilometers line-of-sight
* Dimensions 49 x 42 x 5mm
* Weight < 21 grams
* Interface 20-pin mini connector
* Antenna MMCX jack Connector
* price : ~80$
|
[[Image:ConnexLink_USB_RF_Modem.jpg|thumb|Aerocomm USB Stand-alone Modem]]
|-
|

=== AC4790-200 ===
* Frequency 902-928MHz (North America, Australia, etc).
* Output Power 5-200mW
* Sensitivity (@ full RF data rate) -110dB
* RF Data Rate up to 76.8 Kbps
* INterface Data Rate Up to Up to 115.2 Kbps
* Power Draw (typical) 68 mA
* Supply Voltage 3.3v & 5.5V
* Range (typical, depends on antenna & environment) Up to 6.4 kilometers line-of-sight
* Dimensions 42 x 48 x 5mm
* Weight < 20 grams
* Interface 20-pin mini connector
* Antenna MMCX jack Connector or internal
* price : ~80$
|
[[Image:ac4868_transceiver.jpg|thumb|left|AC4868 OEM Modem]]
|
|-
|

=== AC4790-1000 ===
* Frequency 902-928MHz (North America, Australia, etc).
* Output Power 5-1000mW
* Sensitivity (@ full RF data rate) -99dB
* RF Data Rate up to 76.8 Kbps
* INterface Data Rate Up to Up to 115.2 Kbps
* Power Draw (typical) 650 mA
* Supply Voltage 3.3V only
* Range (typical, depends on antenna & environment) Up to 32 kilometers with high-gain antenna
* Dimensions 42 x 48 x 5mm
* Weight < 20 grams
* Interface 20-pin mini connector
* Antenna MMCX jack Connector
* price : ~80$
|}

=== Pinout ===

[[Image:Aerocomm_AC4868_pinout.jpg|thumb|left|Aerocomm AC4868 modem pinout]]
[[Image:Aerocomm_AC4490-200_wired.jpg|thumb|left|Aerocomm AC4490 wiring example]]
<br style="clear:both">

{| border="1"
|+ Wiring the Aerocomm AC4868 to the Tiny
|-valign="top"
||'''''AC4868 20-pin Header'''''||'''''Name'''''||'''''Color'''''||'''''Tiny Serial-1'''''||'''''Notes'''''
|-
||2||Tx||green||7||''(Note 1)''
|-
||3||Rx||blue||8||''(Note 1)''
|-
||5||GND||black||1|| -
|-
||10+11||VCC||red||2||+3.3v
|-
||17||C/D||white||3||Low = Command High = Data
|}
''Note 1 : names are specified with respect to the AEROCOMM module''

=== Documentation ===
* [http://www.aerocomm.com/rf_transceiver_modules/ac4790_mesh-ready_transceiver.htm AC4790 product page]
* [http://www.aerocomm.com/docs/Datasheet_AC4790_HI.pdf AC4790 Datasheet]
* [http://www.aerocomm.com/docs/User_Manual_AC4790.pdf AC4790 Manual]
* [http://www.aerocomm.com/rf_transceiver_modules/ac4868_868mhz_rf_transceiver.htm AC4848 product page]
* [http://www.aerocomm.com/docs/Datasheet_AC4868_HI.pdf AC4868 Datasheet]
* [http://www.aerocomm.com/docs/User_Manual_AC4868.pdf AC4868 user manual]

== Radiotronix ==
These Radiotronix modems are used in transparent mode. Use the WI232EUR Evaluation Software for configuring the modems for the set speed. Connect /CMD and CTS for programming. The DTS version for the US market might cause severe interference with GPS reception, it is not recommended. For a nice ground station modem just add a FTDI232 USB->serial cable, a 3.3V regulator with 100nF capacitors from supplies to ground, solder a SMA cable/connector and put it in a nice case. Make sure you only connect RTS to /CMD if you want to reprogram the modem with the Evaluation software (see the open jumper connection in the picture, green wire) and leave it floating otherwise. The ANT-GXD105-FME/F from [http://www.roundsolutions.com Roundsolutions] was used as a ground station antenna at many competitions.
{|
|
=== WI232EUR ===
* Frequency Band 868MHz (for Europe)
* Output Power 32 mW
* RF Data Rate Up to 76.8 kbps
* Interface Data Rate up to 115.2 kbps
* Power Draw (typical) 65 mA TX / 20 mA RX
* Supply Voltage 3.3v
* Range (typical, depends on antenna & environment) 500 meters line-of-sight
* Dimensions 24 x 21 x 4mm
* Weight ~2 grams
* Interface solder connector
* Antenna solder connector
* price : ~25$
|
[[Image:Wi232eur_wiring.jpg|thumb|WI232EUR Modem]]
|-
|

=== Pinout ===

<br style="clear:both">

{| border="1"
|+ Wiring the WI232EUR to the Tiny
|-valign="top"
||'''''WI232 pins'''''||'''''Name'''''||'''''Tiny Serial-1'''''||'''''Notes'''''
|-
||6||TxD||7||''(Note 1)''
|-
||5||RxD||8||''(Note 1)''
|-
||15-18||GND||1|| -
|-
||19||VCC||2||+3.3v
|-
||4||/CMD||-||''(Note 2)''
|-
||7||CTS||-||''(Note 3)''
|}
''Note 1 : names are specified with respect to the Radiotronix module''

''Note 2 : connect to RTS to program device with Evaluation software''

''Note 3 : connect to CTS to program device with Evaluation software''

|
[[Image:Wi232eur_bopla.jpg|thumb|WI232EUR Modem in BOPLA case]]
|-
|
|}
=== Documentation ===
* [http://www.radiotronix.com/datasheets/new/eur_um.pdf WI232EUR data sheet]
* [http://www.radiotronix.com/datasheets/new/rk-eur_um.pdf WI232EUR user's manual]
* [http://www.radiotronix.com/downloads/software/EUR/setup.exe Evaluation software]

== Bluetooth ==
These modems do not give you a great range but Bluetooth can be found in a lot of recent laptops built-in. Maybe not useful for fixed wing aircrafts it might be used for in-the-shop testing or quadcopters. Make sure you get a recent Class 1 EDR 2.0 stick if you buy one for your computer.
{|
|
=== "Sparkfun" Roving Networks (WRL-08497) ===
* Frequency Band 2.4GHz
* Output Power 32 mW
* RF Data Rate up to ~300 kbps in SPP
* Interface Data Rate up to 921 kbps
* Power Draw (typical) 50 mA TX / 40 mA RX
* Supply Voltage 3.3v
* Range (typical, depends on antenna & environment) 100 meters line-of-sight
* Dimensions 26 x 13 x 2mm
* Weight ~1.5 grams
* Interface solder connector
* price : ~45$
|
[[Image:roving_nw_wiring.jpg|thumb|Roving Networks modem wiring]]
|-
|

To connect to it, get the MAC address of the bluetooth modem

me@mybox:~$ hcitool scan
Scanning ...
00:06:66:00:53:AD FireFly-53AD

and make a virtual connection to a Bluetooth serial port

sudo rfcomm bind 0 00:06:66:00:53:AD

now you can use Bluetooth as /dev/rfcomm0 with the Paparazzi 'link'. You might need to restart 'link' in case you get out of range and it disconnects (tbd). Set the Tiny serial speed to 115200 as the modules come preconfigured to that.
|}

== Coronis WaveCard ==

These relatively inexpensive and light modules implement a Coronis proprietary protocol. Low power consumption - high latency - I would not recommend these modules mostly because of the low quality of the distribution and support. The documentation is rather poor and not easily available.

'''Suport for these modems has been removed from the airborne code on Dec 10th, 2007.'''
{|
|-valign="top"
|
* Frequency Band 400MHz, 868Mhz and 915MHz (3 versions)
* Output Power 25mW and 500mW (2 versions)
* Sensitivity -110 dBm (@ 9600 bps)
* Data Rate 100 Kbps
* Power Draw (typical) 45mA (25mW), 450mA (500mW) TX / 15 mA RX
* Supply Voltage ...
* Range (typical, depends on antenna & environment) Up to 1km (25mW) , 5km (500mW) line-of-sight
* Dimensions 30 x 28 x 7mm (25mW), 37 x 30 x 7mm (500mW)
* 50 ohm RF port for antenna connection
|
[[Image:wavecard.jpg|Coronis Wavecard]]
|}

=== Documentation ===

* [http://www.coronis-systems.com/produit.php?lang=EN&id=WCA www.coronis-systems.com]
* [[Media:CS-COM-SPRD-WAVECARD-E03B.pdf|Wavecard datasheet]]

== Video Transmitter Telemetry ==

[[Image:video_tx_small.jpg|thumb|2.4GHz Video Transmitter]]
In order for the UAV to transmit video from an onboard camera, a video transmitter is needed. The paparazzi AP sends all telemetry data down with the video on the audio channel portion of the transmitter. This means that the transmitter must have an audio channel. These vary in power, and thus range, and run normally on 2.4Ghz. Small UAVs can get about 600m of range from the 50mW version, and extended range can be achieved using units up to 1W. Weight for these units varies from a couple grams to about 30 for the 1W with shielding. Please check for your countries regulations on 2.4Ghz transmission, as each is different.
<br style="clear:both">

== Antennas ==

Here are some examples of lightweight and efficient 868MHz antennas developped by the RF laboratory at ENAC.
[[Image:868mhz_twinstar_antenna_1.jpg|thumb|left|868MHz copper foil antenna attached to the aircraft tail]]
[[Image:868mhz_twinstar_antenna_2.jpg|thumb|left|868MHz copper foil antenna bottom view]]
[[Image:868mhz_ground_antenna.jpg|thumb|left|868MHz ground antenna]]
<br style="clear:both">

Modems

2008-08-30T21:07:42Z

Rcbrother: /* Maxstream 9XTend */

The Paparazzi autopilot features a 5V tolerant 3V TTL serial port to interface with any common radio modem. The bidirectional link provides real-time telemetry and in-flight tuning and navigation commands. The system is also capable overlaying the appropriate protocols to communicate thru non-transparent devices such as the Coronis Wavecard or Maxstream API-enabled products, allowing for hardware addressing for multiple aircraft or future enhancements such as data-relaying, inter-aircraft communication, RSSI signal monitoring and automatic in-flight modem power adjustment. Below is a list of some of the common modems used with Paparazzi, for details on configuring your modem see the [[Airframe_Configuration#Modem|Airframe Configuration]] page.

== Maxstream XBee Pro 2.4GHz (802.15.4, "Series 1") ==

These relatively cheap and light modules implement the [http://www.zigbee.org/en/index.asp ZigBee/IEEE 802.15.4] norm. They allow up to 1.6km (1 mile) range (Paparazzi tested to 2.5km (1.5 miles)). The main drawback of using such 2.4Ghz modules for datalink is that it will interfere with the 2.4Ghz analog video transmitters and a inevitable decrease in range when in proximity to any wifi devices.

{|
|-valign="top"
|[[Image:Xbee_Pro_USB_RF_Modem.jpg|thumb|left|XBee Pro USB Stand-alone Modem (XBP24-PKC-001-UA)]]
|
* Frequency Band 2.4Ghz
* Output Power 100mW (Xbee Pro)
* Sensitivity -100 dBm
* RF Data Rate Up to 250 Kbps
* Interface data rate Up to 115.2 Kbps
* Power Draw (typical) 214 mA TX / 55 mA RX
* Supply Voltage 3.3v
* Range (typical, depends on antenna & environment) Up to 1500m line-of-sight
* Dimensions 24 x 33mm
* Weight 4 grams
* Interface 20-pin mini connector
* Chip antenna, ¼ monopole integrated whip antenna or a U.FL antenna connector (3 versions)
* price : ~32$
|
[[Image:XBee_pro.jpg|thumb|left|XBee Pro OEM Modem]]
|}

=== Pinout ===

[[Image:Maxstream_Xbee_pinout.jpg|left|thumb|Maxstream XBee pinout]]
<br style="clear:both">

{|border="1"
|-valign="top"
||''Xbee 20-pin Header''||''Name''||''Notes''||''Suggested Color''||
|-
|1
| +3.3v
| Power
|Red
|-
|2
|DOUT
|Tx output - connect to Autopilot Rx
|Green
|-
|3
|DIN
|Rx input - connect to Autopilot Tx
|Blue
|-
|10
|GND
| Ground
|Black
|}

=== Documentation ===

* [http://www.maxstream.net/products/xbee/xbee-pro-oem-rf-module-zigbee.php product page]
* [http://www.maxstream.net/products/xbee/datasheet_XBee_OEM_RF-Modules.pdf datasheet]
* [http://www.maxstream.net/products/xbee/product-manual_XBee_OEM_RF-Modules.pdf user manual]

== Maxstream XBee Pro XSC 900Mhz ==

Maxstream has recently announced a promising new line of modems combining the small size and low cost of their popular Xbee line with the long range and 2.4Ghz video compatibility of their high end 900Mhz models. Sounds like the perfect modem for anyone who can use 900Mhz. Give them a try and post your results here!
{|
|-valign="top"
|[[Image:xbeeproxsc-rpsma.jpg|thumb|left|Maxstream XBee Pro XSC]]
|
* Frequency Band 900Mhz
* Output Power 100mW
* Sensitivity -100 dBm
* Data Rate: 9600 bps
* Range (typical, depends on antenna & environment) Up to 24km (15 miles) line-of-sight
* Interface 20-pin mini connector (Xbee compatible pinout)
* RPSMA, integrated whip antenna or U.FL antenna connector (3 versions)
* price : ~75$
|
|}
=== Documentation ===
* [http://www.digi.com/products/wireless/point-multipoint/xbee-pro-xsc.jsp http://www.digi.com/products/wireless/point-multipoint/xbee-pro-xsc.jsp]

== Maxstream 9XTend ==

These larger units have been tested on the 900Mhz band, but are also available in 2.4Ghz. They are a bit on the heavy side, about 20 grams, but give good performance at range. They have adjustable power settings from 100mW to 1W. Testing has shown range up to 3.2km (2 miles) with 100mW.

{|
|-valign="top"
|
[[Image:XTend_USB_RF_Modem.jpg|frame|left|9XTend USB Modem]]
|
* Frequency Band 900Mhz and 2.4Ghz (2 versions)
* Output Power 1mW to 1W software selectable
* Sensitivity -110 dBm (@ 9600 bps)
* RF Data Rate 9.6 or 115.2 Kbps
* Interface data rate up to 230.4 Kbps
* Power Draw (typical) 730 mA TX / 80 mA RX
* Supply Voltage 2.8 to 5.5v
* Range (typical, depends on antenna & environment) Up to 64km line-of-sight
* Dimensions 36 x 60 x 5mm
* Weight 18 grams
* Interface 20-pin mini connector
* RF connector RPSMA (Reverse-polarity SMA) or MMCX (2 versions)
* price : ~179 USD
|
[[Image:Xtend_module.jpg|frame|left|9XTend OEM Modem]]
|}

=== Pinout ===

[[Image:Maxstream_9XTend_Pinout.gif|thumb|left|Maxstream 9XTend Pinout]]

{| border="1"
|-valign="top"
||'''''9XTend 20-pin Header'''''||'''''Name'''''||'''''Tiny Serial-1 Header'''''||'''''Notes'''''
|-
||1||GND||1 (GND)||Ground
|-
||2||VCC||N/A (requires 5V)||5V power (150mA - 730mA Supplied from servo bus or other 5V source)
|-
||5||RX||8 (TX)||3-5V TTL data input - connect to Tiny TX
|-
||6||TX||7 (RX)||5V TTL data output - connect to Tiny RX
|-
||7||Shutdown||N/A (requires 5V)||Permanently connect this pin to the 5V bus for normal operation
|}
Notes:<br>
* 9XTend can run on voltages as low as 2.8V but users are strongly advised against connecting any modem (especially high power models) to the sensitive 3.3V bus supplying the autopilot processor and sensors.
<br style="clear:both">

=== Documentation ===

* [http://www.maxstream.net/products/xtend/oem-rf-module.php product page]
* [http://www.maxstream.net/products/xtend/datasheet_XTend_OEM_RF-Module.pdf datasheet]
* [http://www.maxstream.net/products/xtend/product-manual_XTend_OEM_RF-Module.pdf user manual]

== Aerocomm ==
Aerocomm's API mode is not yet implemented. Therefore they are used in transparent mode. Users are reporting these modems cause more interference with GPS reception then the Maxstream modem.

How to use this modem on ground station side? [http://paparazzi.enac.fr/wiki/index.php/User:SilaS#SDK-AC4868-250_ground_modem_part]

{|
|
=== AC4868-250 ===
* Frequency Band 868MHz (For Europe).
* Output Power (w/ 2dBi antenna) 250 mW
* Sensitivity (@ full RF data rate) -103 dB
* RF Data Rate Up to 28.8 Kbps
* INterface Data Rate Up to 57.6 Kbps
* Power Draw (typical) 240 mA TX / 36 mA RX
* Supply Voltage 3.3v & 5V or 3.3v only
* Range (typical, depends on antenna & environment) Up to 15 kilometers line-of-sight
* Dimensions 49 x 42 x 5mm
* Weight < 21 grams
* Interface 20-pin mini connector
* Antenna MMCX jack Connector
* price : ~80$
|
[[Image:ConnexLink_USB_RF_Modem.jpg|thumb|Aerocomm USB Stand-alone Modem]]
|-
|

=== AC4790-200 ===
* Frequency 902-928MHz (North America, Australia, etc).
* Output Power 5-200mW
* Sensitivity (@ full RF data rate) -110dB
* RF Data Rate up to 76.8 Kbps
* INterface Data Rate Up to Up to 115.2 Kbps
* Power Draw (typical) 68 mA
* Supply Voltage 3.3v & 5.5V
* Range (typical, depends on antenna & environment) Up to 6.4 kilometers line-of-sight
* Dimensions 42 x 48 x 5mm
* Weight < 20 grams
* Interface 20-pin mini connector
* Antenna MMCX jack Connector or internal
* price : ~80$
|
[[Image:ac4868_transceiver.jpg|thumb|left|AC4868 OEM Modem]]
|
|-
|

=== AC4790-1000 ===
* Frequency 902-928MHz (North America, Australia, etc).
* Output Power 5-1000mW
* Sensitivity (@ full RF data rate) -99dB
* RF Data Rate up to 76.8 Kbps
* INterface Data Rate Up to Up to 115.2 Kbps
* Power Draw (typical) 650 mA
* Supply Voltage 3.3V only
* Range (typical, depends on antenna & environment) Up to 32 kilometers with high-gain antenna
* Dimensions 42 x 48 x 5mm
* Weight < 20 grams
* Interface 20-pin mini connector
* Antenna MMCX jack Connector
* price : ~80$
|}

=== Pinout ===

[[Image:Aerocomm_AC4868_pinout.jpg|thumb|left|Aerocomm AC4868 modem pinout]]
[[Image:Aerocomm_AC4490-200_wired.jpg|thumb|left|Aerocomm AC4490 wiring example]]
<br style="clear:both">

{| border="1"
|+ Wiring the Aerocomm AC4868 to the Tiny
|-valign="top"
||'''''AC4868 20-pin Header'''''||'''''Name'''''||'''''Color'''''||'''''Tiny Serial-1'''''||'''''Notes'''''
|-
||2||Tx||green||7||''(Note 1)''
|-
||3||Rx||blue||8||''(Note 1)''
|-
||5||GND||black||1|| -
|-
||10+11||VCC||red||2||+3.3v
|-
||17||C/D||white||3||Low = Command High = Data
|}
''Note 1 : names are specified with respect to the AEROCOMM module''

=== Documentation ===
* [http://www.aerocomm.com/rf_transceiver_modules/ac4790_mesh-ready_transceiver.htm AC4790 product page]
* [http://www.aerocomm.com/docs/Datasheet_AC4790_HI.pdf AC4790 Datasheet]
* [http://www.aerocomm.com/docs/User_Manual_AC4790.pdf AC4790 Manual]
* [http://www.aerocomm.com/rf_transceiver_modules/ac4868_868mhz_rf_transceiver.htm AC4848 product page]
* [http://www.aerocomm.com/docs/Datasheet_AC4868_HI.pdf AC4868 Datasheet]
* [http://www.aerocomm.com/docs/User_Manual_AC4868.pdf AC4868 user manual]

== Radiotronix ==
These Radiotronix modems are used in transparent mode. Use the WI232EUR Evaluation Software for configuring the modems for the set speed. Connect /CMD and CTS for programming. The DTS version for the US market might cause severe interference with GPS reception, it is not recommended. For a nice ground station modem just add a FTDI232 USB->serial cable, a 3.3V regulator with 100nF capacitors from supplies to ground, solder a SMA cable/connector and put it in a nice case. Make sure you only connect RTS to /CMD if you want to reprogram the modem with the Evaluation software (see the open jumper connection in the picture, green wire) and leave it floating otherwise. The ANT-GXD105-FME/F from [http://www.roundsolutions.com Roundsolutions] was used as a ground station antenna at many competitions.
{|
|
=== WI232EUR ===
* Frequency Band 868MHz (for Europe)
* Output Power 32 mW
* RF Data Rate Up to 76.8 kbps
* Interface Data Rate up to 115.2 kbps
* Power Draw (typical) 65 mA TX / 20 mA RX
* Supply Voltage 3.3v
* Range (typical, depends on antenna & environment) 500 meters line-of-sight
* Dimensions 24 x 21 x 4mm
* Weight ~2 grams
* Interface solder connector
* Antenna solder connector
* price : ~25$
|
[[Image:Wi232eur_wiring.jpg|thumb|WI232EUR Modem]]
|-
|

=== Pinout ===

<br style="clear:both">

{| border="1"
|+ Wiring the WI232EUR to the Tiny
|-valign="top"
||'''''WI232 pins'''''||'''''Name'''''||'''''Tiny Serial-1'''''||'''''Notes'''''
|-
||6||TxD||7||''(Note 1)''
|-
||5||RxD||8||''(Note 1)''
|-
||15-18||GND||1|| -
|-
||19||VCC||2||+3.3v
|-
||4||/CMD||-||''(Note 2)''
|-
||7||CTS||-||''(Note 3)''
|}
''Note 1 : names are specified with respect to the Radiotronix module''

''Note 2 : connect to RTS to program device with Evaluation software''

''Note 3 : connect to CTS to program device with Evaluation software''

|
[[Image:Wi232eur_bopla.jpg|thumb|WI232EUR Modem in BOPLA case]]
|-
|
|}
=== Documentation ===
* [http://www.radiotronix.com/datasheets/new/eur_um.pdf WI232EUR data sheet]
* [http://www.radiotronix.com/datasheets/new/rk-eur_um.pdf WI232EUR user's manual]
* [http://www.radiotronix.com/downloads/software/EUR/setup.exe Evaluation software]

== Bluetooth ==
These modems do not give you a great range but Bluetooth can be found in a lot of recent laptops built-in. Maybe not useful for fixed wing aircrafts it might be used for in-the-shop testing or quadcopters. Make sure you get a recent Class 1 EDR 2.0 stick if you buy one for your computer.
{|
|
=== "Sparkfun" Roving Networks (WRL-08497) ===
* Frequency Band 2.4GHz
* Output Power 32 mW
* RF Data Rate up to ~300 kbps in SPP
* Interface Data Rate up to 921 kbps
* Power Draw (typical) 50 mA TX / 40 mA RX
* Supply Voltage 3.3v
* Range (typical, depends on antenna & environment) 100 meters line-of-sight
* Dimensions 26 x 13 x 2mm
* Weight ~1.5 grams
* Interface solder connector
* price : ~45$
|
[[Image:roving_nw_wiring.jpg|thumb|Roving Networks modem wiring]]
|-
|

To connect to it, get the MAC address of the bluetooth modem

me@mybox:~$ hcitool scan
Scanning ...
00:06:66:00:53:AD FireFly-53AD

and make a virtual connection to a Bluetooth serial port

sudo rfcomm bind 0 00:06:66:00:53:AD

now you can use Bluetooth as /dev/rfcomm0 with the Paparazzi 'link'. You might need to restart 'link' in case you get out of range and it disconnects (tbd). Set the Tiny serial speed to 115200 as the modules come preconfigured to that.
|}

== Coronis WaveCard ==

These relatively inexpensive and light modules implement a Coronis proprietary protocol. Low power consumption - high latency - I would not recommend these modules mostly because of the low quality of the distribution and support. The documentation is rather poor and not easily available.

'''Suport for these modems has been removed from the airborne code on Dec 10th, 2007.'''
{|
|-valign="top"
|
* Frequency Band 400MHz, 868Mhz and 915MHz (3 versions)
* Output Power 25mW and 500mW (2 versions)
* Sensitivity -110 dBm (@ 9600 bps)
* Data Rate 100 Kbps
* Power Draw (typical) 45mA (25mW), 450mA (500mW) TX / 15 mA RX
* Supply Voltage ...
* Range (typical, depends on antenna & environment) Up to 1km (25mW) , 5km (500mW) line-of-sight
* Dimensions 30 x 28 x 7mm (25mW), 37 x 30 x 7mm (500mW)
* 50 ohm RF port for antenna connection
|
[[Image:wavecard.jpg|Coronis Wavecard]]
|}

=== Documentation ===

* [http://www.coronis-systems.com/produit.php?lang=EN&id=WCA www.coronis-systems.com]
* [[Media:CS-COM-SPRD-WAVECARD-E03B.pdf|Wavecard datasheet]]

== Video Transmitter Telemetry ==

[[Image:video_tx_small.jpg|thumb|2.4GHz Video Transmitter]]
In order for the UAV to transmit video from an onboard camera, a video transmitter is needed. The paparazzi AP sends all telemetry data down with the video on the audio channel portion of the transmitter. This means that the transmitter must have an audio channel. These vary in power, and thus range, and run normally on 2.4Ghz. Small UAVs can get about 600m of range from the 50mW version, and extended range can be achieved using units up to 1W. Weight for these units varies from a couple grams to about 30 for the 1W with shielding. Please check for your countries regulations on 2.4Ghz transmission, as each is different.
<br style="clear:both">

== Antennas ==

Here are some examples of lightweight and efficient 868MHz antennas developped by the RF laboratory at ENAC.
[[Image:868mhz_twinstar_antenna_1.jpg|thumb|left|868MHz copper foil antenna attached to the aircraft tail]]
[[Image:868mhz_twinstar_antenna_2.jpg|thumb|left|868MHz copper foil antenna bottom view]]
[[Image:868mhz_ground_antenna.jpg|thumb|left|868MHz ground antenna]]
<br style="clear:both">

Modems

2008-08-30T21:05:48Z

Rcbrother: /* Maxstream XBee Pro XSC 900Mhz */

The Paparazzi autopilot features a 5V tolerant 3V TTL serial port to interface with any common radio modem. The bidirectional link provides real-time telemetry and in-flight tuning and navigation commands. The system is also capable overlaying the appropriate protocols to communicate thru non-transparent devices such as the Coronis Wavecard or Maxstream API-enabled products, allowing for hardware addressing for multiple aircraft or future enhancements such as data-relaying, inter-aircraft communication, RSSI signal monitoring and automatic in-flight modem power adjustment. Below is a list of some of the common modems used with Paparazzi, for details on configuring your modem see the [[Airframe_Configuration#Modem|Airframe Configuration]] page.

== Maxstream XBee Pro 2.4GHz (802.15.4, "Series 1") ==

These relatively cheap and light modules implement the [http://www.zigbee.org/en/index.asp ZigBee/IEEE 802.15.4] norm. They allow up to 1.6km (1 mile) range (Paparazzi tested to 2.5km (1.5 miles)). The main drawback of using such 2.4Ghz modules for datalink is that it will interfere with the 2.4Ghz analog video transmitters and a inevitable decrease in range when in proximity to any wifi devices.

{|
|-valign="top"
|[[Image:Xbee_Pro_USB_RF_Modem.jpg|thumb|left|XBee Pro USB Stand-alone Modem (XBP24-PKC-001-UA)]]
|
* Frequency Band 2.4Ghz
* Output Power 100mW (Xbee Pro)
* Sensitivity -100 dBm
* RF Data Rate Up to 250 Kbps
* Interface data rate Up to 115.2 Kbps
* Power Draw (typical) 214 mA TX / 55 mA RX
* Supply Voltage 3.3v
* Range (typical, depends on antenna & environment) Up to 1500m line-of-sight
* Dimensions 24 x 33mm
* Weight 4 grams
* Interface 20-pin mini connector
* Chip antenna, ¼ monopole integrated whip antenna or a U.FL antenna connector (3 versions)
* price : ~32$
|
[[Image:XBee_pro.jpg|thumb|left|XBee Pro OEM Modem]]
|}

=== Pinout ===

[[Image:Maxstream_Xbee_pinout.jpg|left|thumb|Maxstream XBee pinout]]
<br style="clear:both">

{|border="1"
|-valign="top"
||''Xbee 20-pin Header''||''Name''||''Notes''||''Suggested Color''||
|-
|1
| +3.3v
| Power
|Red
|-
|2
|DOUT
|Tx output - connect to Autopilot Rx
|Green
|-
|3
|DIN
|Rx input - connect to Autopilot Tx
|Blue
|-
|10
|GND
| Ground
|Black
|}

=== Documentation ===

* [http://www.maxstream.net/products/xbee/xbee-pro-oem-rf-module-zigbee.php product page]
* [http://www.maxstream.net/products/xbee/datasheet_XBee_OEM_RF-Modules.pdf datasheet]
* [http://www.maxstream.net/products/xbee/product-manual_XBee_OEM_RF-Modules.pdf user manual]

== Maxstream XBee Pro XSC 900Mhz ==

Maxstream has recently announced a promising new line of modems combining the small size and low cost of their popular Xbee line with the long range and 2.4Ghz video compatibility of their high end 900Mhz models. Sounds like the perfect modem for anyone who can use 900Mhz. Give them a try and post your results here!
{|
|-valign="top"
|[[Image:xbeeproxsc-rpsma.jpg|thumb|left|Maxstream XBee Pro XSC]]
|
* Frequency Band 900Mhz
* Output Power 100mW
* Sensitivity -100 dBm
* Data Rate: 9600 bps
* Range (typical, depends on antenna & environment) Up to 24km (15 miles) line-of-sight
* Interface 20-pin mini connector (Xbee compatible pinout)
* RPSMA, integrated whip antenna or U.FL antenna connector (3 versions)
* price : ~75$
|
|}
=== Documentation ===
* [http://www.digi.com/products/wireless/point-multipoint/xbee-pro-xsc.jsp http://www.digi.com/products/wireless/point-multipoint/xbee-pro-xsc.jsp]

== Maxstream 9XTend ==

These larger units have been tested on the 900Mhz band, but are also available in 2.4Ghz. They are a bit on the heavy side(~20grams) but give good performance at range. They have adjustable power settings from 100mW to 1W. Testing has shown range up to 2 miles with 100mW.

{|
|-valign="top"
|
[[Image:XTend_USB_RF_Modem.jpg|frame|left|9XTend USB Modem]]
|
* Frequency Band 900Mhz and 2.4Ghz (2 versions)
* Output Power 1mW to 1W software selectable
* Sensitivity -110 dBm (@ 9600 bps)
* RF Data Rate 9.6 or 115.2 Kbps
* Interface data rate up to 230.4 Kbps
* Power Draw (typical) 730 mA TX / 80 mA RX
* Supply Voltage 2.8 to 5.5v
* Range (typical, depends on antenna & environment) Up to 64km line-of-sight
* Dimensions 36 x 60 x 5mm
* Weight 18 grams
* Interface 20-pin mini connector
* RF connector RPSMA (Reverse-polarity SMA) or MMCX (2 versions)
* price : ~179$
|
[[Image:Xtend_module.jpg|frame|left|9XTend OEM Modem]]
|}

=== Pinout ===

[[Image:Maxstream_9XTend_Pinout.gif|thumb|left|Maxstream 9XTend Pinout]]

{| border="1"
|-valign="top"
||'''''9XTend 20-pin Header'''''||'''''Name'''''||'''''Tiny Serial-1 Header'''''||'''''Notes'''''
|-
||1||GND||1 (GND)||Ground
|-
||2||VCC||N/A (requires 5V)||5V power (150mA - 730mA Supplied from servo bus or other 5V source)
|-
||5||RX||8 (TX)||3-5V TTL data input - connect to Tiny TX
|-
||6||TX||7 (RX)||5V TTL data output - connect to Tiny RX
|-
||7||Shutdown||N/A (requires 5V)||Permanently connect this pin to the 5V bus for normal operation
|}
Notes:<br>
* 9XTend can run on voltages as low as 2.8V but users are strongly advised against connecting any modem (especially high power models) to the sensitive 3.3V bus supplying the autopilot processor and sensors.
<br style="clear:both">

=== Documentation ===

* [http://www.maxstream.net/products/xtend/oem-rf-module.php product page]
* [http://www.maxstream.net/products/xtend/datasheet_XTend_OEM_RF-Module.pdf datasheet]
* [http://www.maxstream.net/products/xtend/product-manual_XTend_OEM_RF-Module.pdf user manual]

== Aerocomm ==
Aerocomm's API mode is not yet implemented. Therefore they are used in transparent mode. Users are reporting these modems cause more interference with GPS reception then the Maxstream modem.

How to use this modem on ground station side? [http://paparazzi.enac.fr/wiki/index.php/User:SilaS#SDK-AC4868-250_ground_modem_part]

{|
|
=== AC4868-250 ===
* Frequency Band 868MHz (For Europe).
* Output Power (w/ 2dBi antenna) 250 mW
* Sensitivity (@ full RF data rate) -103 dB
* RF Data Rate Up to 28.8 Kbps
* INterface Data Rate Up to 57.6 Kbps
* Power Draw (typical) 240 mA TX / 36 mA RX
* Supply Voltage 3.3v & 5V or 3.3v only
* Range (typical, depends on antenna & environment) Up to 15 kilometers line-of-sight
* Dimensions 49 x 42 x 5mm
* Weight < 21 grams
* Interface 20-pin mini connector
* Antenna MMCX jack Connector
* price : ~80$
|
[[Image:ConnexLink_USB_RF_Modem.jpg|thumb|Aerocomm USB Stand-alone Modem]]
|-
|

=== AC4790-200 ===
* Frequency 902-928MHz (North America, Australia, etc).
* Output Power 5-200mW
* Sensitivity (@ full RF data rate) -110dB
* RF Data Rate up to 76.8 Kbps
* INterface Data Rate Up to Up to 115.2 Kbps
* Power Draw (typical) 68 mA
* Supply Voltage 3.3v & 5.5V
* Range (typical, depends on antenna & environment) Up to 6.4 kilometers line-of-sight
* Dimensions 42 x 48 x 5mm
* Weight < 20 grams
* Interface 20-pin mini connector
* Antenna MMCX jack Connector or internal
* price : ~80$
|
[[Image:ac4868_transceiver.jpg|thumb|left|AC4868 OEM Modem]]
|
|-
|

=== AC4790-1000 ===
* Frequency 902-928MHz (North America, Australia, etc).
* Output Power 5-1000mW
* Sensitivity (@ full RF data rate) -99dB
* RF Data Rate up to 76.8 Kbps
* INterface Data Rate Up to Up to 115.2 Kbps
* Power Draw (typical) 650 mA
* Supply Voltage 3.3V only
* Range (typical, depends on antenna & environment) Up to 32 kilometers with high-gain antenna
* Dimensions 42 x 48 x 5mm
* Weight < 20 grams
* Interface 20-pin mini connector
* Antenna MMCX jack Connector
* price : ~80$
|}

=== Pinout ===

[[Image:Aerocomm_AC4868_pinout.jpg|thumb|left|Aerocomm AC4868 modem pinout]]
[[Image:Aerocomm_AC4490-200_wired.jpg|thumb|left|Aerocomm AC4490 wiring example]]
<br style="clear:both">

{| border="1"
|+ Wiring the Aerocomm AC4868 to the Tiny
|-valign="top"
||'''''AC4868 20-pin Header'''''||'''''Name'''''||'''''Color'''''||'''''Tiny Serial-1'''''||'''''Notes'''''
|-
||2||Tx||green||7||''(Note 1)''
|-
||3||Rx||blue||8||''(Note 1)''
|-
||5||GND||black||1|| -
|-
||10+11||VCC||red||2||+3.3v
|-
||17||C/D||white||3||Low = Command High = Data
|}
''Note 1 : names are specified with respect to the AEROCOMM module''

=== Documentation ===
* [http://www.aerocomm.com/rf_transceiver_modules/ac4790_mesh-ready_transceiver.htm AC4790 product page]
* [http://www.aerocomm.com/docs/Datasheet_AC4790_HI.pdf AC4790 Datasheet]
* [http://www.aerocomm.com/docs/User_Manual_AC4790.pdf AC4790 Manual]
* [http://www.aerocomm.com/rf_transceiver_modules/ac4868_868mhz_rf_transceiver.htm AC4848 product page]
* [http://www.aerocomm.com/docs/Datasheet_AC4868_HI.pdf AC4868 Datasheet]
* [http://www.aerocomm.com/docs/User_Manual_AC4868.pdf AC4868 user manual]

== Radiotronix ==
These Radiotronix modems are used in transparent mode. Use the WI232EUR Evaluation Software for configuring the modems for the set speed. Connect /CMD and CTS for programming. The DTS version for the US market might cause severe interference with GPS reception, it is not recommended. For a nice ground station modem just add a FTDI232 USB->serial cable, a 3.3V regulator with 100nF capacitors from supplies to ground, solder a SMA cable/connector and put it in a nice case. Make sure you only connect RTS to /CMD if you want to reprogram the modem with the Evaluation software (see the open jumper connection in the picture, green wire) and leave it floating otherwise. The ANT-GXD105-FME/F from [http://www.roundsolutions.com Roundsolutions] was used as a ground station antenna at many competitions.
{|
|
=== WI232EUR ===
* Frequency Band 868MHz (for Europe)
* Output Power 32 mW
* RF Data Rate Up to 76.8 kbps
* Interface Data Rate up to 115.2 kbps
* Power Draw (typical) 65 mA TX / 20 mA RX
* Supply Voltage 3.3v
* Range (typical, depends on antenna & environment) 500 meters line-of-sight
* Dimensions 24 x 21 x 4mm
* Weight ~2 grams
* Interface solder connector
* Antenna solder connector
* price : ~25$
|
[[Image:Wi232eur_wiring.jpg|thumb|WI232EUR Modem]]
|-
|

=== Pinout ===

<br style="clear:both">

{| border="1"
|+ Wiring the WI232EUR to the Tiny
|-valign="top"
||'''''WI232 pins'''''||'''''Name'''''||'''''Tiny Serial-1'''''||'''''Notes'''''
|-
||6||TxD||7||''(Note 1)''
|-
||5||RxD||8||''(Note 1)''
|-
||15-18||GND||1|| -
|-
||19||VCC||2||+3.3v
|-
||4||/CMD||-||''(Note 2)''
|-
||7||CTS||-||''(Note 3)''
|}
''Note 1 : names are specified with respect to the Radiotronix module''

''Note 2 : connect to RTS to program device with Evaluation software''

''Note 3 : connect to CTS to program device with Evaluation software''

|
[[Image:Wi232eur_bopla.jpg|thumb|WI232EUR Modem in BOPLA case]]
|-
|
|}
=== Documentation ===
* [http://www.radiotronix.com/datasheets/new/eur_um.pdf WI232EUR data sheet]
* [http://www.radiotronix.com/datasheets/new/rk-eur_um.pdf WI232EUR user's manual]
* [http://www.radiotronix.com/downloads/software/EUR/setup.exe Evaluation software]

== Bluetooth ==
These modems do not give you a great range but Bluetooth can be found in a lot of recent laptops built-in. Maybe not useful for fixed wing aircrafts it might be used for in-the-shop testing or quadcopters. Make sure you get a recent Class 1 EDR 2.0 stick if you buy one for your computer.
{|
|
=== "Sparkfun" Roving Networks (WRL-08497) ===
* Frequency Band 2.4GHz
* Output Power 32 mW
* RF Data Rate up to ~300 kbps in SPP
* Interface Data Rate up to 921 kbps
* Power Draw (typical) 50 mA TX / 40 mA RX
* Supply Voltage 3.3v
* Range (typical, depends on antenna & environment) 100 meters line-of-sight
* Dimensions 26 x 13 x 2mm
* Weight ~1.5 grams
* Interface solder connector
* price : ~45$
|
[[Image:roving_nw_wiring.jpg|thumb|Roving Networks modem wiring]]
|-
|

To connect to it, get the MAC address of the bluetooth modem

me@mybox:~$ hcitool scan
Scanning ...
00:06:66:00:53:AD FireFly-53AD

and make a virtual connection to a Bluetooth serial port

sudo rfcomm bind 0 00:06:66:00:53:AD

now you can use Bluetooth as /dev/rfcomm0 with the Paparazzi 'link'. You might need to restart 'link' in case you get out of range and it disconnects (tbd). Set the Tiny serial speed to 115200 as the modules come preconfigured to that.
|}

== Coronis WaveCard ==

These relatively inexpensive and light modules implement a Coronis proprietary protocol. Low power consumption - high latency - I would not recommend these modules mostly because of the low quality of the distribution and support. The documentation is rather poor and not easily available.

'''Suport for these modems has been removed from the airborne code on Dec 10th, 2007.'''
{|
|-valign="top"
|
* Frequency Band 400MHz, 868Mhz and 915MHz (3 versions)
* Output Power 25mW and 500mW (2 versions)
* Sensitivity -110 dBm (@ 9600 bps)
* Data Rate 100 Kbps
* Power Draw (typical) 45mA (25mW), 450mA (500mW) TX / 15 mA RX
* Supply Voltage ...
* Range (typical, depends on antenna & environment) Up to 1km (25mW) , 5km (500mW) line-of-sight
* Dimensions 30 x 28 x 7mm (25mW), 37 x 30 x 7mm (500mW)
* 50 ohm RF port for antenna connection
|
[[Image:wavecard.jpg|Coronis Wavecard]]
|}

=== Documentation ===

* [http://www.coronis-systems.com/produit.php?lang=EN&id=WCA www.coronis-systems.com]
* [[Media:CS-COM-SPRD-WAVECARD-E03B.pdf|Wavecard datasheet]]

== Video Transmitter Telemetry ==

[[Image:video_tx_small.jpg|thumb|2.4GHz Video Transmitter]]
In order for the UAV to transmit video from an onboard camera, a video transmitter is needed. The paparazzi AP sends all telemetry data down with the video on the audio channel portion of the transmitter. This means that the transmitter must have an audio channel. These vary in power, and thus range, and run normally on 2.4Ghz. Small UAVs can get about 600m of range from the 50mW version, and extended range can be achieved using units up to 1W. Weight for these units varies from a couple grams to about 30 for the 1W with shielding. Please check for your countries regulations on 2.4Ghz transmission, as each is different.
<br style="clear:both">

== Antennas ==

Here are some examples of lightweight and efficient 868MHz antennas developped by the RF laboratory at ENAC.
[[Image:868mhz_twinstar_antenna_1.jpg|thumb|left|868MHz copper foil antenna attached to the aircraft tail]]
[[Image:868mhz_twinstar_antenna_2.jpg|thumb|left|868MHz copper foil antenna bottom view]]
[[Image:868mhz_ground_antenna.jpg|thumb|left|868MHz ground antenna]]
<br style="clear:both">

Modems

2008-08-30T21:04:00Z

Rcbrother: /* Maxstream XBee Pro 2.4GHz (802.15.4, "Series 1") */

The Paparazzi autopilot features a 5V tolerant 3V TTL serial port to interface with any common radio modem. The bidirectional link provides real-time telemetry and in-flight tuning and navigation commands. The system is also capable overlaying the appropriate protocols to communicate thru non-transparent devices such as the Coronis Wavecard or Maxstream API-enabled products, allowing for hardware addressing for multiple aircraft or future enhancements such as data-relaying, inter-aircraft communication, RSSI signal monitoring and automatic in-flight modem power adjustment. Below is a list of some of the common modems used with Paparazzi, for details on configuring your modem see the [[Airframe_Configuration#Modem|Airframe Configuration]] page.

== Maxstream XBee Pro 2.4GHz (802.15.4, "Series 1") ==

These relatively cheap and light modules implement the [http://www.zigbee.org/en/index.asp ZigBee/IEEE 802.15.4] norm. They allow up to 1.6km (1 mile) range (Paparazzi tested to 2.5km (1.5 miles)). The main drawback of using such 2.4Ghz modules for datalink is that it will interfere with the 2.4Ghz analog video transmitters and a inevitable decrease in range when in proximity to any wifi devices.

{|
|-valign="top"
|[[Image:Xbee_Pro_USB_RF_Modem.jpg|thumb|left|XBee Pro USB Stand-alone Modem (XBP24-PKC-001-UA)]]
|
* Frequency Band 2.4Ghz
* Output Power 100mW (Xbee Pro)
* Sensitivity -100 dBm
* RF Data Rate Up to 250 Kbps
* Interface data rate Up to 115.2 Kbps
* Power Draw (typical) 214 mA TX / 55 mA RX
* Supply Voltage 3.3v
* Range (typical, depends on antenna & environment) Up to 1500m line-of-sight
* Dimensions 24 x 33mm
* Weight 4 grams
* Interface 20-pin mini connector
* Chip antenna, ¼ monopole integrated whip antenna or a U.FL antenna connector (3 versions)
* price : ~32$
|
[[Image:XBee_pro.jpg|thumb|left|XBee Pro OEM Modem]]
|}

=== Pinout ===

[[Image:Maxstream_Xbee_pinout.jpg|left|thumb|Maxstream XBee pinout]]
<br style="clear:both">

{|border="1"
|-valign="top"
||''Xbee 20-pin Header''||''Name''||''Notes''||''Suggested Color''||
|-
|1
| +3.3v
| Power
|Red
|-
|2
|DOUT
|Tx output - connect to Autopilot Rx
|Green
|-
|3
|DIN
|Rx input - connect to Autopilot Tx
|Blue
|-
|10
|GND
| Ground
|Black
|}

=== Documentation ===

* [http://www.maxstream.net/products/xbee/xbee-pro-oem-rf-module-zigbee.php product page]
* [http://www.maxstream.net/products/xbee/datasheet_XBee_OEM_RF-Modules.pdf datasheet]
* [http://www.maxstream.net/products/xbee/product-manual_XBee_OEM_RF-Modules.pdf user manual]

== Maxstream XBee Pro XSC 900Mhz ==

Maxstream has recently announced a promising new line of modems combining the small size and low cost of their popular Xbee line with the long range and 2.4Ghz video compatibility of their high end 900Mhz models. Sounds like the perfect modem for anyone who can use 900Mhz. Give them a try and post your results here!
{|
|-valign="top"
|[[Image:xbeeproxsc-rpsma.jpg|thumb|left|Maxstream XBee Pro XSC]]
|
* Frequency Band 900Mhz
* Output Power 100mW
* Sensitivity -100 dBm
* Data Rate: 9600 bps
* Range (typical, depends on antenna & environment) Up to 15 miles line-of-sight
* Interface 20-pin mini connector (Xbee compatible pinout)
* RPSMA, integrated whip antenna or U.FL antenna connector (3 versions)
* price : ~75$
|
|}
=== Documentation ===
* [http://www.digi.com/products/wireless/point-multipoint/xbee-pro-xsc.jsp http://www.digi.com/products/wireless/point-multipoint/xbee-pro-xsc.jsp]

== Maxstream 9XTend ==

These larger units have been tested on the 900Mhz band, but are also available in 2.4Ghz. They are a bit on the heavy side(~20grams) but give good performance at range. They have adjustable power settings from 100mW to 1W. Testing has shown range up to 2 miles with 100mW.

{|
|-valign="top"
|
[[Image:XTend_USB_RF_Modem.jpg|frame|left|9XTend USB Modem]]
|
* Frequency Band 900Mhz and 2.4Ghz (2 versions)
* Output Power 1mW to 1W software selectable
* Sensitivity -110 dBm (@ 9600 bps)
* RF Data Rate 9.6 or 115.2 Kbps
* Interface data rate up to 230.4 Kbps
* Power Draw (typical) 730 mA TX / 80 mA RX
* Supply Voltage 2.8 to 5.5v
* Range (typical, depends on antenna & environment) Up to 64km line-of-sight
* Dimensions 36 x 60 x 5mm
* Weight 18 grams
* Interface 20-pin mini connector
* RF connector RPSMA (Reverse-polarity SMA) or MMCX (2 versions)
* price : ~179$
|
[[Image:Xtend_module.jpg|frame|left|9XTend OEM Modem]]
|}

=== Pinout ===

[[Image:Maxstream_9XTend_Pinout.gif|thumb|left|Maxstream 9XTend Pinout]]

{| border="1"
|-valign="top"
||'''''9XTend 20-pin Header'''''||'''''Name'''''||'''''Tiny Serial-1 Header'''''||'''''Notes'''''
|-
||1||GND||1 (GND)||Ground
|-
||2||VCC||N/A (requires 5V)||5V power (150mA - 730mA Supplied from servo bus or other 5V source)
|-
||5||RX||8 (TX)||3-5V TTL data input - connect to Tiny TX
|-
||6||TX||7 (RX)||5V TTL data output - connect to Tiny RX
|-
||7||Shutdown||N/A (requires 5V)||Permanently connect this pin to the 5V bus for normal operation
|}
Notes:<br>
* 9XTend can run on voltages as low as 2.8V but users are strongly advised against connecting any modem (especially high power models) to the sensitive 3.3V bus supplying the autopilot processor and sensors.
<br style="clear:both">

=== Documentation ===

* [http://www.maxstream.net/products/xtend/oem-rf-module.php product page]
* [http://www.maxstream.net/products/xtend/datasheet_XTend_OEM_RF-Module.pdf datasheet]
* [http://www.maxstream.net/products/xtend/product-manual_XTend_OEM_RF-Module.pdf user manual]

== Aerocomm ==
Aerocomm's API mode is not yet implemented. Therefore they are used in transparent mode. Users are reporting these modems cause more interference with GPS reception then the Maxstream modem.

How to use this modem on ground station side? [http://paparazzi.enac.fr/wiki/index.php/User:SilaS#SDK-AC4868-250_ground_modem_part]

{|
|
=== AC4868-250 ===
* Frequency Band 868MHz (For Europe).
* Output Power (w/ 2dBi antenna) 250 mW
* Sensitivity (@ full RF data rate) -103 dB
* RF Data Rate Up to 28.8 Kbps
* INterface Data Rate Up to 57.6 Kbps
* Power Draw (typical) 240 mA TX / 36 mA RX
* Supply Voltage 3.3v & 5V or 3.3v only
* Range (typical, depends on antenna & environment) Up to 15 kilometers line-of-sight
* Dimensions 49 x 42 x 5mm
* Weight < 21 grams
* Interface 20-pin mini connector
* Antenna MMCX jack Connector
* price : ~80$
|
[[Image:ConnexLink_USB_RF_Modem.jpg|thumb|Aerocomm USB Stand-alone Modem]]
|-
|

=== AC4790-200 ===
* Frequency 902-928MHz (North America, Australia, etc).
* Output Power 5-200mW
* Sensitivity (@ full RF data rate) -110dB
* RF Data Rate up to 76.8 Kbps
* INterface Data Rate Up to Up to 115.2 Kbps
* Power Draw (typical) 68 mA
* Supply Voltage 3.3v & 5.5V
* Range (typical, depends on antenna & environment) Up to 6.4 kilometers line-of-sight
* Dimensions 42 x 48 x 5mm
* Weight < 20 grams
* Interface 20-pin mini connector
* Antenna MMCX jack Connector or internal
* price : ~80$
|
[[Image:ac4868_transceiver.jpg|thumb|left|AC4868 OEM Modem]]
|
|-
|

=== AC4790-1000 ===
* Frequency 902-928MHz (North America, Australia, etc).
* Output Power 5-1000mW
* Sensitivity (@ full RF data rate) -99dB
* RF Data Rate up to 76.8 Kbps
* INterface Data Rate Up to Up to 115.2 Kbps
* Power Draw (typical) 650 mA
* Supply Voltage 3.3V only
* Range (typical, depends on antenna & environment) Up to 32 kilometers with high-gain antenna
* Dimensions 42 x 48 x 5mm
* Weight < 20 grams
* Interface 20-pin mini connector
* Antenna MMCX jack Connector
* price : ~80$
|}

=== Pinout ===

[[Image:Aerocomm_AC4868_pinout.jpg|thumb|left|Aerocomm AC4868 modem pinout]]
[[Image:Aerocomm_AC4490-200_wired.jpg|thumb|left|Aerocomm AC4490 wiring example]]
<br style="clear:both">

{| border="1"
|+ Wiring the Aerocomm AC4868 to the Tiny
|-valign="top"
||'''''AC4868 20-pin Header'''''||'''''Name'''''||'''''Color'''''||'''''Tiny Serial-1'''''||'''''Notes'''''
|-
||2||Tx||green||7||''(Note 1)''
|-
||3||Rx||blue||8||''(Note 1)''
|-
||5||GND||black||1|| -
|-
||10+11||VCC||red||2||+3.3v
|-
||17||C/D||white||3||Low = Command High = Data
|}
''Note 1 : names are specified with respect to the AEROCOMM module''

=== Documentation ===
* [http://www.aerocomm.com/rf_transceiver_modules/ac4790_mesh-ready_transceiver.htm AC4790 product page]
* [http://www.aerocomm.com/docs/Datasheet_AC4790_HI.pdf AC4790 Datasheet]
* [http://www.aerocomm.com/docs/User_Manual_AC4790.pdf AC4790 Manual]
* [http://www.aerocomm.com/rf_transceiver_modules/ac4868_868mhz_rf_transceiver.htm AC4848 product page]
* [http://www.aerocomm.com/docs/Datasheet_AC4868_HI.pdf AC4868 Datasheet]
* [http://www.aerocomm.com/docs/User_Manual_AC4868.pdf AC4868 user manual]

== Radiotronix ==
These Radiotronix modems are used in transparent mode. Use the WI232EUR Evaluation Software for configuring the modems for the set speed. Connect /CMD and CTS for programming. The DTS version for the US market might cause severe interference with GPS reception, it is not recommended. For a nice ground station modem just add a FTDI232 USB->serial cable, a 3.3V regulator with 100nF capacitors from supplies to ground, solder a SMA cable/connector and put it in a nice case. Make sure you only connect RTS to /CMD if you want to reprogram the modem with the Evaluation software (see the open jumper connection in the picture, green wire) and leave it floating otherwise. The ANT-GXD105-FME/F from [http://www.roundsolutions.com Roundsolutions] was used as a ground station antenna at many competitions.
{|
|
=== WI232EUR ===
* Frequency Band 868MHz (for Europe)
* Output Power 32 mW
* RF Data Rate Up to 76.8 kbps
* Interface Data Rate up to 115.2 kbps
* Power Draw (typical) 65 mA TX / 20 mA RX
* Supply Voltage 3.3v
* Range (typical, depends on antenna & environment) 500 meters line-of-sight
* Dimensions 24 x 21 x 4mm
* Weight ~2 grams
* Interface solder connector
* Antenna solder connector
* price : ~25$
|
[[Image:Wi232eur_wiring.jpg|thumb|WI232EUR Modem]]
|-
|

=== Pinout ===

<br style="clear:both">

{| border="1"
|+ Wiring the WI232EUR to the Tiny
|-valign="top"
||'''''WI232 pins'''''||'''''Name'''''||'''''Tiny Serial-1'''''||'''''Notes'''''
|-
||6||TxD||7||''(Note 1)''
|-
||5||RxD||8||''(Note 1)''
|-
||15-18||GND||1|| -
|-
||19||VCC||2||+3.3v
|-
||4||/CMD||-||''(Note 2)''
|-
||7||CTS||-||''(Note 3)''
|}
''Note 1 : names are specified with respect to the Radiotronix module''

''Note 2 : connect to RTS to program device with Evaluation software''

''Note 3 : connect to CTS to program device with Evaluation software''

|
[[Image:Wi232eur_bopla.jpg|thumb|WI232EUR Modem in BOPLA case]]
|-
|
|}
=== Documentation ===
* [http://www.radiotronix.com/datasheets/new/eur_um.pdf WI232EUR data sheet]
* [http://www.radiotronix.com/datasheets/new/rk-eur_um.pdf WI232EUR user's manual]
* [http://www.radiotronix.com/downloads/software/EUR/setup.exe Evaluation software]

== Bluetooth ==
These modems do not give you a great range but Bluetooth can be found in a lot of recent laptops built-in. Maybe not useful for fixed wing aircrafts it might be used for in-the-shop testing or quadcopters. Make sure you get a recent Class 1 EDR 2.0 stick if you buy one for your computer.
{|
|
=== "Sparkfun" Roving Networks (WRL-08497) ===
* Frequency Band 2.4GHz
* Output Power 32 mW
* RF Data Rate up to ~300 kbps in SPP
* Interface Data Rate up to 921 kbps
* Power Draw (typical) 50 mA TX / 40 mA RX
* Supply Voltage 3.3v
* Range (typical, depends on antenna & environment) 100 meters line-of-sight
* Dimensions 26 x 13 x 2mm
* Weight ~1.5 grams
* Interface solder connector
* price : ~45$
|
[[Image:roving_nw_wiring.jpg|thumb|Roving Networks modem wiring]]
|-
|

To connect to it, get the MAC address of the bluetooth modem

me@mybox:~$ hcitool scan
Scanning ...
00:06:66:00:53:AD FireFly-53AD

and make a virtual connection to a Bluetooth serial port

sudo rfcomm bind 0 00:06:66:00:53:AD

now you can use Bluetooth as /dev/rfcomm0 with the Paparazzi 'link'. You might need to restart 'link' in case you get out of range and it disconnects (tbd). Set the Tiny serial speed to 115200 as the modules come preconfigured to that.
|}

== Coronis WaveCard ==

These relatively inexpensive and light modules implement a Coronis proprietary protocol. Low power consumption - high latency - I would not recommend these modules mostly because of the low quality of the distribution and support. The documentation is rather poor and not easily available.

'''Suport for these modems has been removed from the airborne code on Dec 10th, 2007.'''
{|
|-valign="top"
|
* Frequency Band 400MHz, 868Mhz and 915MHz (3 versions)
* Output Power 25mW and 500mW (2 versions)
* Sensitivity -110 dBm (@ 9600 bps)
* Data Rate 100 Kbps
* Power Draw (typical) 45mA (25mW), 450mA (500mW) TX / 15 mA RX
* Supply Voltage ...
* Range (typical, depends on antenna & environment) Up to 1km (25mW) , 5km (500mW) line-of-sight
* Dimensions 30 x 28 x 7mm (25mW), 37 x 30 x 7mm (500mW)
* 50 ohm RF port for antenna connection
|
[[Image:wavecard.jpg|Coronis Wavecard]]
|}

=== Documentation ===

* [http://www.coronis-systems.com/produit.php?lang=EN&id=WCA www.coronis-systems.com]
* [[Media:CS-COM-SPRD-WAVECARD-E03B.pdf|Wavecard datasheet]]

== Video Transmitter Telemetry ==

[[Image:video_tx_small.jpg|thumb|2.4GHz Video Transmitter]]
In order for the UAV to transmit video from an onboard camera, a video transmitter is needed. The paparazzi AP sends all telemetry data down with the video on the audio channel portion of the transmitter. This means that the transmitter must have an audio channel. These vary in power, and thus range, and run normally on 2.4Ghz. Small UAVs can get about 600m of range from the 50mW version, and extended range can be achieved using units up to 1W. Weight for these units varies from a couple grams to about 30 for the 1W with shielding. Please check for your countries regulations on 2.4Ghz transmission, as each is different.
<br style="clear:both">

== Antennas ==

Here are some examples of lightweight and efficient 868MHz antennas developped by the RF laboratory at ENAC.
[[Image:868mhz_twinstar_antenna_1.jpg|thumb|left|868MHz copper foil antenna attached to the aircraft tail]]
[[Image:868mhz_twinstar_antenna_2.jpg|thumb|left|868MHz copper foil antenna bottom view]]
[[Image:868mhz_ground_antenna.jpg|thumb|left|868MHz ground antenna]]
<br style="clear:both">