PaparazziUAV - User contributions [en]

File:LogFileParser.m.zip

2013-03-15T19:21:45Z

Avanhel: This is a log file parser that loads the all the different parameters from the log file and stores them as a struct.

This is a log file parser that loads the all the different parameters from the log file and stores them as a struct.

Flight Plans

2012-12-17T11:06:53Z

Avanhel: /* Eight */

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

== DTD and Structure ==

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

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

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

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

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

The root <tt>flight_plan</tt> element is specified with several attributes:
<tt>'''<flight_plan name lat0 lon0 ground_alt security_height 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 and in other flight procedures such as formation flight and anti-collision avoidance. Warnings are produced if you place a waypoint lower than <tt>'''security_height'''</tt> (usually the case for the landing point)
* <tt>'''home_mode_height'''</tt> (optional): this optional attribute available in master branch (after v4.1_unstable-101-gc42477d) allows to override <tt>'''security_height'''</tt> as failsafe height in home mode. If <tt>'''home_mode_height'''</tt> is set lower than <tt>'''security_height'''</tt>, the later is used. This attribute is useful if you need to return home at a high altitude rather than a low altitude.
* <tt>'''qfu'''</tt> (optional): defines the global constant <tt>QFU</tt>. It usually is the magnetic heading in degrees (north=0, east=90) of the runway, the opposite of wind direction. This constant may be used in the mission description. It is also used by the simulator as the original course of the aircraft. So if you want to take off and climb to the West you would use qfu=270.
* <tt>'''alt'''</tt>: the default altitude of waypoints ([[Altitude_definitions|Above Sea Level]]). So if your ground altitude is 400 then alt needs to be a value greater than ground altitude and above any obstructions in the flight plan.
* <tt>'''max_dist_from_home'''</tt>: the maximum allowed distance (in meters) from the HOME waypoint. Exceeding this value will trigger an exception.

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

<source lang="xml">
<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" home_mode_height="150">
</source>

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

== Waypoints ==

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

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

'''Tips'''
* Waypoints are easily adjusted with the [[Flight_Plan_Editor|flight plan editor]].
* If a waypoint name starts with an underscore, the waypoint is '''not displayed''' in the GCS, except in editor mode.
* The maximum number of waypoints is 254.
* A waypoint named <tt>HOME</tt> is required if the failsafe HOME mode procedure is used.

== Sectors ==

Flat ''Sectors'' can be described as an area defined by list of waypoint corners. Such an area will be displayed in the Ground Control Station (GCS) by colored lines.
A function is generated to check if a point, usually the aircraft itself, is ''inside'' this sector. Currently, this feature requires that the polygon is <b>convex</b> and described in a <b>clockwise</b> order. For a sector named <tt>sector</tt>. Note that sector names are not allowed to contain spaces. 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. If the flight plan is dynamically relocated, such a sector will be relocated but the display is currently not updated on the GCS. It would be great if one would help improving that part of the source code.

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

It is then possible to write a exception. For example if the aircraft for some reason flies outside this sector the airframe will fly to a standby waypoint. The exclamation mark (!) means the boolean operator <tt>NOT</tt> in this example. In regular language one would describe "If my airframe is NOT inside the Murret sector anymore then deroute it to the standby waypoint." In Flightplan "Speak" this is written like:
<source lang="xml">
<exception cond="! InsideMyCosySector(estimator_x, estimator_y)" deroute="standby"/>
</source>

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

== Includes ==

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

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

== Blocks ==

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

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

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

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

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

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

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

==== Expressions ====

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

Some examples of usable expressions are given in the next sections.
=== Initialization Blocks ===
The first three blocks of flight plan are initialization blocks.

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

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

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

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

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

=== Deroute ===

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

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

=== Loops ===

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

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

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

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

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

=== Navigation modes ===

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

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

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

The different navigation modes are detailed in the next sections.

=== Attitude ===

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

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

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

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

=== Heading ===

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

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

=== Go ===

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

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

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

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

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

=== Path ===

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

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

=== Circle ===

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

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

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

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

=== Follow ===

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

In this example, the autopilot will try to follow A/C number '''4''', staying '''50'''m behind and '''20'''m above.
<source lang="xml"><follow ac_id="4" distance="50" height="20"/></source>
Note that the <tt>traffic_info.c</tt> file is required by this feature and the <tt>TRAFFIC_INFO</tt> flag has to be set to enable it. Then, the following lines must be added in the airframe file:
<tt>ap.srcs += traffic_info.c</tt>
<tt>ap.CFLAGS += -DTRAFFIC_INFO</tt>
<tt>sim.srcs += traffic_info.c</tt>
<tt>sim.CFLAGS += -DTRAFFIC_INFO</tt>

=== Stay ===

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

=== XYZ ===

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

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

=== Set ===

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

=== Call ===

The <tt>call</tt> allows the user to define its own navigation procedures in C. The <tt>value</tt> must be a call to a boolean function which must return TRUE as long as the stage is not completed (a function which should be called only once would then return immediately FALSE).
This feature is illustrated with the '''line''' pattern:
<source lang="xml">
<call fun="nav_line_init()"/>
<call fun="nav_line(WP_1, WP_2, nav_radius)"/>
</source>
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:
<source lang="xml">
<header>
#include "nav_line.h"
</header>
</source>
These C source file and H header file must be located in the <tt>sw/airborne</tt> directory.

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

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

=== Immobilize Actuators ===

h_ctl setpoints variable are set by the h_ctl_attitude_loop() (from fw_h_ctl.c) loop) which can be disabled with the
h_ctl_disabled flag:
<source lang="xml">
<set var="h_ctl_disabled" value="TRUE"/>
<set var="h_ctl_aileron_setpoint" value="0"/>
<set var="h_ctl_elevator_setpoint" value="MAX_PPRZ/2"/>
.... waiting for a condition ...
<set var="h_ctl_disabled" value="FALSE"/>
</source>

== Procedures ==

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

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

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

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

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

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

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

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

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

== Tips and Tricks ==

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

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

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

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

Flight Plans

2012-12-17T11:06:24Z

Avanhel: /* Oval */

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

== DTD and Structure ==

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

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

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

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

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

The root <tt>flight_plan</tt> element is specified with several attributes:
<tt>'''<flight_plan name lat0 lon0 ground_alt security_height 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 and in other flight procedures such as formation flight and anti-collision avoidance. Warnings are produced if you place a waypoint lower than <tt>'''security_height'''</tt> (usually the case for the landing point)
* <tt>'''home_mode_height'''</tt> (optional): this optional attribute available in master branch (after v4.1_unstable-101-gc42477d) allows to override <tt>'''security_height'''</tt> as failsafe height in home mode. If <tt>'''home_mode_height'''</tt> is set lower than <tt>'''security_height'''</tt>, the later is used. This attribute is useful if you need to return home at a high altitude rather than a low altitude.
* <tt>'''qfu'''</tt> (optional): defines the global constant <tt>QFU</tt>. It usually is the magnetic heading in degrees (north=0, east=90) of the runway, the opposite of wind direction. This constant may be used in the mission description. It is also used by the simulator as the original course of the aircraft. So if you want to take off and climb to the West you would use qfu=270.
* <tt>'''alt'''</tt>: the default altitude of waypoints ([[Altitude_definitions|Above Sea Level]]). So if your ground altitude is 400 then alt needs to be a value greater than ground altitude and above any obstructions in the flight plan.
* <tt>'''max_dist_from_home'''</tt>: the maximum allowed distance (in meters) from the HOME waypoint. Exceeding this value will trigger an exception.

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

<source lang="xml">
<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" home_mode_height="150">
</source>

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

== Waypoints ==

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

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

'''Tips'''
* Waypoints are easily adjusted with the [[Flight_Plan_Editor|flight plan editor]].
* If a waypoint name starts with an underscore, the waypoint is '''not displayed''' in the GCS, except in editor mode.
* The maximum number of waypoints is 254.
* A waypoint named <tt>HOME</tt> is required if the failsafe HOME mode procedure is used.

== Sectors ==

Flat ''Sectors'' can be described as an area defined by list of waypoint corners. Such an area will be displayed in the Ground Control Station (GCS) by colored lines.
A function is generated to check if a point, usually the aircraft itself, is ''inside'' this sector. Currently, this feature requires that the polygon is <b>convex</b> and described in a <b>clockwise</b> order. For a sector named <tt>sector</tt>. Note that sector names are not allowed to contain spaces. 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. If the flight plan is dynamically relocated, such a sector will be relocated but the display is currently not updated on the GCS. It would be great if one would help improving that part of the source code.

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

It is then possible to write a exception. For example if the aircraft for some reason flies outside this sector the airframe will fly to a standby waypoint. The exclamation mark (!) means the boolean operator <tt>NOT</tt> in this example. In regular language one would describe "If my airframe is NOT inside the Murret sector anymore then deroute it to the standby waypoint." In Flightplan "Speak" this is written like:
<source lang="xml">
<exception cond="! InsideMyCosySector(estimator_x, estimator_y)" deroute="standby"/>
</source>

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

== Includes ==

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

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

== Blocks ==

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

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

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

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

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

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

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

==== Expressions ====

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

Some examples of usable expressions are given in the next sections.
=== Initialization Blocks ===
The first three blocks of flight plan are initialization blocks.

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

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

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

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

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

=== Deroute ===

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

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

=== Loops ===

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

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

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

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

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

=== Navigation modes ===

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

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

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

The different navigation modes are detailed in the next sections.

=== Attitude ===

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

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

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

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

=== Heading ===

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

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

=== Go ===

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

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

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

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

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

=== Path ===

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

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

=== Circle ===

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

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

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

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

=== Follow ===

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

In this example, the autopilot will try to follow A/C number '''4''', staying '''50'''m behind and '''20'''m above.
<source lang="xml"><follow ac_id="4" distance="50" height="20"/></source>
Note that the <tt>traffic_info.c</tt> file is required by this feature and the <tt>TRAFFIC_INFO</tt> flag has to be set to enable it. Then, the following lines must be added in the airframe file:
<tt>ap.srcs += traffic_info.c</tt>
<tt>ap.CFLAGS += -DTRAFFIC_INFO</tt>
<tt>sim.srcs += traffic_info.c</tt>
<tt>sim.CFLAGS += -DTRAFFIC_INFO</tt>

=== Stay ===

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

=== XYZ ===

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

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

=== Set ===

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

=== Call ===

The <tt>call</tt> allows the user to define its own navigation procedures in C. The <tt>value</tt> must be a call to a boolean function which must return TRUE as long as the stage is not completed (a function which should be called only once would then return immediately FALSE).
This feature is illustrated with the '''line''' pattern:
<source lang="xml">
<call fun="nav_line_init()"/>
<call fun="nav_line(WP_1, WP_2, nav_radius)"/>
</source>
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:
<source lang="xml">
<header>
#include "nav_line.h"
</header>
</source>
These C source file and H header file must be located in the <tt>sw/airborne</tt> directory.

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

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

=== Immobilize Actuators ===

h_ctl setpoints variable are set by the h_ctl_attitude_loop() (from fw_h_ctl.c) loop) which can be disabled with the
h_ctl_disabled flag:
<source lang="xml">
<set var="h_ctl_disabled" value="TRUE"/>
<set var="h_ctl_aileron_setpoint" value="0"/>
<set var="h_ctl_elevator_setpoint" value="MAX_PPRZ/2"/>
.... waiting for a condition ...
<set var="h_ctl_disabled" value="FALSE"/>
</source>

== Procedures ==

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

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

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

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

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

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

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

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

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

== Tips and Tricks ==

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

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

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

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

Flight Plans

2012-12-17T10:42:33Z

Avanhel:

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

== DTD and Structure ==

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

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

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

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

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

The root <tt>flight_plan</tt> element is specified with several attributes:
<tt>'''<flight_plan name lat0 lon0 ground_alt security_height 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 and in other flight procedures such as formation flight and anti-collision avoidance. Warnings are produced if you place a waypoint lower than <tt>'''security_height'''</tt> (usually the case for the landing point)
* <tt>'''home_mode_height'''</tt> (optional): this optional attribute available in master branch (after v4.1_unstable-101-gc42477d) allows to override <tt>'''security_height'''</tt> as failsafe height in home mode. If <tt>'''home_mode_height'''</tt> is set lower than <tt>'''security_height'''</tt>, the later is used. This attribute is useful if you need to return home at a high altitude rather than a low altitude.
* <tt>'''qfu'''</tt> (optional): defines the global constant <tt>QFU</tt>. It usually is the magnetic heading in degrees (north=0, east=90) of the runway, the opposite of wind direction. This constant may be used in the mission description. It is also used by the simulator as the original course of the aircraft. So if you want to take off and climb to the West you would use qfu=270.
* <tt>'''alt'''</tt>: the default altitude of waypoints ([[Altitude_definitions|Above Sea Level]]). So if your ground altitude is 400 then alt needs to be a value greater than ground altitude and above any obstructions in the flight plan.
* <tt>'''max_dist_from_home'''</tt>: the maximum allowed distance (in meters) from the HOME waypoint. Exceeding this value will trigger an exception.

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

<source lang="xml">
<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" home_mode_height="150">
</source>

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

== Waypoints ==

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

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

'''Tips'''
* Waypoints are easily adjusted with the [[Flight_Plan_Editor|flight plan editor]].
* If a waypoint name starts with an underscore, the waypoint is '''not displayed''' in the GCS, except in editor mode.
* The maximum number of waypoints is 254.
* A waypoint named <tt>HOME</tt> is required if the failsafe HOME mode procedure is used.

== Sectors ==

Flat ''Sectors'' can be described as an area defined by list of waypoint corners. Such an area will be displayed in the Ground Control Station (GCS) by colored lines.
A function is generated to check if a point, usually the aircraft itself, is ''inside'' this sector. Currently, this feature requires that the polygon is <b>convex</b> and described in a <b>clockwise</b> order. For a sector named <tt>sector</tt>. Note that sector names are not allowed to contain spaces. 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. If the flight plan is dynamically relocated, such a sector will be relocated but the display is currently not updated on the GCS. It would be great if one would help improving that part of the source code.

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

It is then possible to write a exception. For example if the aircraft for some reason flies outside this sector the airframe will fly to a standby waypoint. The exclamation mark (!) means the boolean operator <tt>NOT</tt> in this example. In regular language one would describe "If my airframe is NOT inside the Murret sector anymore then deroute it to the standby waypoint." In Flightplan "Speak" this is written like:
<source lang="xml">
<exception cond="! InsideMyCosySector(estimator_x, estimator_y)" deroute="standby"/>
</source>

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

== Includes ==

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

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

== Blocks ==

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

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

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

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

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

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

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

==== Expressions ====

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

Some examples of usable expressions are given in the next sections.
=== Initialization Blocks ===
The first three blocks of flight plan are initialization blocks.

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

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

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

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

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

=== Deroute ===

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

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

=== Loops ===

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

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

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

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

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

=== Navigation modes ===

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

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

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

The different navigation modes are detailed in the next sections.

=== Attitude ===

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

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

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

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

=== Heading ===

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

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

=== Go ===

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

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

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

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

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

=== Path ===

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

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

=== Circle ===

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

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

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

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

=== Follow ===

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

In this example, the autopilot will try to follow A/C number '''4''', staying '''50'''m behind and '''20'''m above.
<source lang="xml"><follow ac_id="4" distance="50" height="20"/></source>
Note that the <tt>traffic_info.c</tt> file is required by this feature and the <tt>TRAFFIC_INFO</tt> flag has to be set to enable it. Then, the following lines must be added in the airframe file:
<tt>ap.srcs += traffic_info.c</tt>
<tt>ap.CFLAGS += -DTRAFFIC_INFO</tt>
<tt>sim.srcs += traffic_info.c</tt>
<tt>sim.CFLAGS += -DTRAFFIC_INFO</tt>

=== Stay ===

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

=== XYZ ===

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

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

=== Set ===

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

=== Call ===

The <tt>call</tt> allows the user to define its own navigation procedures in C. The <tt>value</tt> must be a call to a boolean function which must return TRUE as long as the stage is not completed (a function which should be called only once would then return immediately FALSE).
This feature is illustrated with the '''line''' pattern:
<source lang="xml">
<call fun="nav_line_init()"/>
<call fun="nav_line(WP_1, WP_2, nav_radius)"/>
</source>
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:
<source lang="xml">
<header>
#include "nav_line.h"
</header>
</source>
These C source file and H header file must be located in the <tt>sw/airborne</tt> directory.

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

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

=== Immobilize Actuators ===

h_ctl setpoints variable are set by the h_ctl_attitude_loop() (from fw_h_ctl.c) loop) which can be disabled with the
h_ctl_disabled flag:
<source lang="xml">
<set var="h_ctl_disabled" value="TRUE"/>
<set var="h_ctl_aileron_setpoint" value="0"/>
<set var="h_ctl_elevator_setpoint" value="MAX_PPRZ/2"/>
.... waiting for a condition ...
<set var="h_ctl_disabled" value="FALSE"/>
</source>

== Procedures ==

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

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

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

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

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

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

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

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

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

== Tips and Tricks ==

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

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

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

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

Flight Plans

2012-12-17T10:26:26Z

Avanhel: /* Navigation modes */

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

== DTD and Structure ==

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

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

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

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

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

The root <tt>flight_plan</tt> element is specified with several attributes:
<tt>'''<flight_plan name lat0 lon0 ground_alt security_height 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 and in other flight procedures such as formation flight and anti-collision avoidance. Warnings are produced if you place a waypoint lower than <tt>'''security_height'''</tt> (usually the case for the landing point)
* <tt>'''home_mode_height'''</tt> (optional): this optional attribute available in master branch (after v4.1_unstable-101-gc42477d) allows to override <tt>'''security_height'''</tt> as failsafe height in home mode. If <tt>'''home_mode_height'''</tt> is set lower than <tt>'''security_height'''</tt>, the later is used. This attribute is useful if you need to return home at a high altitude rather than a low altitude.
* <tt>'''qfu'''</tt> (optional): defines the global constant <tt>QFU</tt>. It usually is the magnetic heading in degrees (north=0, east=90) of the runway, the opposite of wind direction. This constant may be used in the mission description. It is also used by the simulator as the original course of the aircraft. So if you want to take off and climb to the West you would use qfu=270.
* <tt>'''alt'''</tt>: the default altitude of waypoints ([[Altitude_definitions|Above Sea Level]]). So if your ground altitude is 400 then alt needs to be a value greater than ground altitude and above any obstructions in the flight plan.
* <tt>'''max_dist_from_home'''</tt>: the maximum allowed distance (in meters) from the HOME waypoint. Exceeding this value will trigger an exception.

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

<source lang="xml">
<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" home_mode_height="150">
</source>

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

== Waypoints ==

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

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

'''Tips'''
* Waypoints are easily adjusted with the [[Flight_Plan_Editor|flight plan editor]].
* If a waypoint name starts with an underscore, the waypoint is '''not displayed''' in the GCS, except in editor mode.
* The maximum number of waypoints is 254.
* A waypoint named <tt>HOME</tt> is required if the failsafe HOME mode procedure is used.

== Sectors ==

Flat ''Sectors'' can be described as an area defined by list of waypoint corners. Such an area will be displayed in the Ground Control Station (GCS) by colored lines.
A function is generated to check if a point, usually the aircraft itself, is ''inside'' this sector. Currently, this feature requires that the polygon is <b>convex</b> and described in a <b>clockwise</b> order. For a sector named <tt>sector</tt>. Note that sector names are not allowed to contain spaces. 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. If the flight plan is dynamically relocated, such a sector will be relocated but the display is currently not updated on the GCS. It would be great if one would help improving that part of the source code.

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

It is then possible to write a exception. For example if the aircraft for some reason flies outside this sector the airframe will fly to a standby waypoint. The exclamation mark (!) means the boolean operator <tt>NOT</tt> in this example. In regular language one would describe "If my airframe is NOT inside the Murret sector anymore then deroute it to the standby waypoint." In Flightplan "Speak" this is written like:
<source lang="xml">
<exception cond="! InsideMyCosySector(estimator_x, estimator_y)" deroute="standby"/>
</source>

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

== Includes ==

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

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

== Blocks ==

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

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

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

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

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

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

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

==== Expressions ====

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

Some examples of usable expressions are given in the next sections.
=== Initialization Blocks ===
The first three blocks of flight plan are initialization blocks.

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

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

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

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

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

=== Deroute ===

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

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

=== Loops ===

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

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

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

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

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

=== Navigation modes ===

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

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

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

The different navigation modes are detailed in the next sections.

=== Attitude ===

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

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

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

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

=== Heading ===

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

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

=== Go ===

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

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

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

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

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

=== Path ===

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

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

=== Circle ===

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

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

=== Follow ===

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

In this example, the autopilot will try to follow A/C number '''4''', staying '''50'''m behind and '''20'''m above.
<source lang="xml"><follow ac_id="4" distance="50" height="20"/></source>
Note that the <tt>traffic_info.c</tt> file is required by this feature and the <tt>TRAFFIC_INFO</tt> flag has to be set to enable it. Then, the following lines must be added in the airframe file:
<tt>ap.srcs += traffic_info.c</tt>
<tt>ap.CFLAGS += -DTRAFFIC_INFO</tt>
<tt>sim.srcs += traffic_info.c</tt>
<tt>sim.CFLAGS += -DTRAFFIC_INFO</tt>

=== Stay ===

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

=== XYZ ===

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

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

=== Set ===

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

=== Call ===

The <tt>call</tt> allows the user to define its own navigation procedures in C. The <tt>value</tt> must be a call to a boolean function which must return TRUE as long as the stage is not completed (a function which should be called only once would then return immediately FALSE).
This feature is illustrated with the '''line''' pattern:
<source lang="xml">
<call fun="nav_line_init()"/>
<call fun="nav_line(WP_1, WP_2, nav_radius)"/>
</source>
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:
<source lang="xml">
<header>
#include "nav_line.h"
</header>
</source>
These C source file and H header file must be located in the <tt>sw/airborne</tt> directory.

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

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

=== Immobilize Actuators ===

h_ctl setpoints variable are set by the h_ctl_attitude_loop() (from fw_h_ctl.c) loop) which can be disabled with the
h_ctl_disabled flag:
<source lang="xml">
<set var="h_ctl_disabled" value="TRUE"/>
<set var="h_ctl_aileron_setpoint" value="0"/>
<set var="h_ctl_elevator_setpoint" value="MAX_PPRZ/2"/>
.... waiting for a condition ...
<set var="h_ctl_disabled" value="FALSE"/>
</source>

== Procedures ==

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

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

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

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

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

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

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

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

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

== Tips and Tricks ==

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

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

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

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

Flight Plans

2012-12-16T20:04:04Z

Avanhel: /* Blocks */

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

== DTD and Structure ==

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

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

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

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

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

The root <tt>flight_plan</tt> element is specified with several attributes:
<tt>'''<flight_plan name lat0 lon0 ground_alt security_height 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 and in other flight procedures such as formation flight and anti-collision avoidance. Warnings are produced if you place a waypoint lower than <tt>'''security_height'''</tt> (usually the case for the landing point)
* <tt>'''home_mode_height'''</tt> (optional): this optional attribute available in master branch (after v4.1_unstable-101-gc42477d) allows to override <tt>'''security_height'''</tt> as failsafe height in home mode. If <tt>'''home_mode_height'''</tt> is set lower than <tt>'''security_height'''</tt>, the later is used. This attribute is useful if you need to return home at a high altitude rather than a low altitude.
* <tt>'''qfu'''</tt> (optional): defines the global constant <tt>QFU</tt>. It usually is the magnetic heading in degrees (north=0, east=90) of the runway, the opposite of wind direction. This constant may be used in the mission description. It is also used by the simulator as the original course of the aircraft. So if you want to take off and climb to the West you would use qfu=270.
* <tt>'''alt'''</tt>: the default altitude of waypoints ([[Altitude_definitions|Above Sea Level]]). So if your ground altitude is 400 then alt needs to be a value greater than ground altitude and above any obstructions in the flight plan.
* <tt>'''max_dist_from_home'''</tt>: the maximum allowed distance (in meters) from the HOME waypoint. Exceeding this value will trigger an exception.

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

<source lang="xml">
<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" home_mode_height="150">
</source>

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

== Waypoints ==

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

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

'''Tips'''
* Waypoints are easily adjusted with the [[Flight_Plan_Editor|flight plan editor]].
* If a waypoint name starts with an underscore, the waypoint is '''not displayed''' in the GCS, except in editor mode.
* The maximum number of waypoints is 254.
* A waypoint named <tt>HOME</tt> is required if the failsafe HOME mode procedure is used.

== Sectors ==

Flat ''Sectors'' can be described as an area defined by list of waypoint corners. Such an area will be displayed in the Ground Control Station (GCS) by colored lines.
A function is generated to check if a point, usually the aircraft itself, is ''inside'' this sector. Currently, this feature requires that the polygon is <b>convex</b> and described in a <b>clockwise</b> order. For a sector named <tt>sector</tt>. Note that sector names are not allowed to contain spaces. 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. If the flight plan is dynamically relocated, such a sector will be relocated but the display is currently not updated on the GCS. It would be great if one would help improving that part of the source code.

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

It is then possible to write a exception. For example if the aircraft for some reason flies outside this sector the airframe will fly to a standby waypoint. The exclamation mark (!) means the boolean operator <tt>NOT</tt> in this example. In regular language one would describe "If my airframe is NOT inside the Murret sector anymore then deroute it to the standby waypoint." In Flightplan "Speak" this is written like:
<source lang="xml">
<exception cond="! InsideMyCosySector(estimator_x, estimator_y)" deroute="standby"/>
</source>

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

== Includes ==

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

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

== Blocks ==

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

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

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

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

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

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

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

==== Expressions ====

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

Some examples of usable expressions are given in the next sections.
=== Initialization Blocks ===
The first three blocks of flight plan are initialization blocks.

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

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

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

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

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

=== Deroute ===

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

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

=== Loops ===

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

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

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

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

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

=== Navigation modes ===

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

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

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

The different navigation modes are detailed in the next sections.

=== Attitude ===

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

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

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

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

=== Heading ===

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

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

=== Go ===

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

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

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

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

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

=== Path ===

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

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

=== Circle ===

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

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

=== Follow ===

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

In this example, the autopilot will try to follow A/C number '''4''', staying '''50'''m behind and '''20'''m above.
<source lang="xml"><follow ac_id="4" distance="50" height="20"/></source>
Note that the <tt>traffic_info.c</tt> file is required by this feature and the <tt>TRAFFIC_INFO</tt> flag has to be set to enable it. Then, the following lines must be added in the airframe file:
<tt>ap.srcs += traffic_info.c</tt>
<tt>ap.CFLAGS += -DTRAFFIC_INFO</tt>
<tt>sim.srcs += traffic_info.c</tt>
<tt>sim.CFLAGS += -DTRAFFIC_INFO</tt>

=== Stay ===

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

=== XYZ ===

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

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

=== Set ===

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

=== Call ===

The <tt>call</tt> allows the user to define its own navigation procedures in C. The <tt>value</tt> must be a call to a boolean function which must return TRUE as long as the stage is not completed (a function which should be called only once would then return immediately FALSE).
This feature is illustrated with the '''line''' pattern:
<source lang="xml">
<call fun="nav_line_init()"/>
<call fun="nav_line(WP_1, WP_2, nav_radius)"/>
</source>
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:
<source lang="xml">
<header>
#include "nav_line.h"
</header>
</source>
These C source file and H header file must be located in the <tt>sw/airborne</tt> directory.

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

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

=== Immobilize Actuators ===

h_ctl setpoints variable are set by the h_ctl_attitude_loop() (from fw_h_ctl.c) loop) which can be disabled with the
h_ctl_disabled flag:
<source lang="xml">
<set var="h_ctl_disabled" value="TRUE"/>
<set var="h_ctl_aileron_setpoint" value="0"/>
<set var="h_ctl_elevator_setpoint" value="MAX_PPRZ/2"/>
.... waiting for a condition ...
<set var="h_ctl_disabled" value="FALSE"/>
</source>

== Procedures ==

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

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

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

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

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

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

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

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

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

== Tips and Tricks ==

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

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

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

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