PaparazziUAV - User contributions [en]

Simulation

2011-07-26T08:22:52Z

Agaeb: /* For a fixed wing aircraft: */ Example JSBSim CVS makefile element

This page describes the steps needed to run a simulated flight with an UAS.

==Compiling and starting==

From the [[Paparazzi_Center|Paparazzi Center]] select the Microjet aircraft (from the '''A/C''' combo box) which is configured with the <tt>basic.xml</tt> flight plan. From the '''Target''' combo box, select <tt>sim</tt> and click the '''Build''' button to compile the airbone code to be run on your Linux box. From the '''Session''' combo box, select <tt>Simulation</tt> entry and click '''Execute''' to start the simulation. It will start
three processes which are listed in the window below:
* '''Microjet''' is the interface of a simulator program. It runs the same code as the one for the autopilot processor plus a rudimentary flight dynamic model. it allows you to test the interactions with the UAV and the flight plan execution.
* '''GCS''' ([[GCS|Ground Control Station]]) is the main window. It displays the track of the aircraft, as well as informations about the execution of its flight plans. This program provide menus for the datalink functions and is able to edit a flight plan.
* '''Server''' is a hidden process which won't be described here (see [[Overview|the architecture of the system]])

== Start the Simulation ==

The aircraft has automatically been booted, as if the autopilot board had been powered. Its position and its flight parameters are displayed in the GCS window. If you omit the -boot option of the sim the aircraft is not automatically booted and you can first place the aircraft where you want it to start from and then boot.

The map widget is able use many map formats and display them according to many projections. To make things simple, we start by using images from [http://maps.google.com Google]. From the toolbar in the top right corner of the GCS, click the Google Earth icon ('''Google maps fill'''). The program attempts to download the required satellite images from the Google servers. If it succeeds, you should now see the nice countryside of Muret (a city close to Toulouse, France). Navigation and other features of the map are described on the [[GCS#map|GCS]] page.

The lower part of the GCS displays the flight plan in a tree view. You see that the current flight plan is composed of several ''blocks'':
* '''wait GPS''' and '''geo init''' which are instructions to run this flight plan anywhere in the world, by translating the waypoints around the current location of aircraft as soon as it is reported by the GPS.
* '''Holding point''' (it should be the current active block) which instructs the autopilot to wait for launch.
* '''Takeoff''' which will instruct the aircraft to climb full throttle to a security altitude
* '''Standby''' which is a simple circle around the '''STDBY''' waypoint.

Switch to the '''Takeoff''' block by a double click on the line or using the corresponding button (an icon figuring an airway) on the left side of the strip.

== Fly ==

In the Simulator ('''Microjet''' window), press the '''Launch''' button to simulate a hand launch or click the launch button in the GCS (the green aircraft icon). The autopilot detects the launch by monitoring the groundspeed. The flight time (in the aircraft label on the GCS) then starts to count.

Position of the aircraft is displayed on the map: the aircraft goes to the '''CLIMB''' waypoint (to the norht-west) and then around the '''STDBY''' waypoint. Current block also changes accordingly in the flight plan display.

The orange triangle (the carrot) on the map is the point that the aircraft is navigating toward.

== Line ==

Jump to this block with double-click on the <tt>Line 1-2</tt> line in the flight plan or using the corresponding button in the strip (figuring a blue line between two white points). The aircraft will try to follow a line joining the waypoints '''1''' and '''2''', doing nice U-turns at both ends.

=== Move waypoints ===

While the aircraft is flying (or here while the simulator is integrating differential equations), you can move the waypoints on the GCS interface by cliking and dragging (with the left button). When the mouse button is released, a popup window allows you to change the altitude of the waypoint. After validation, the waypoint changes are sent to the autopilot and the followed track is changed accordingly.

=== Coming back around ===

Select the '''Standby''' block (the ''home'' blue icon) to instruct the aircraft to fly around the '''STDBY''' waypoint.

== Fly too far ==

If you unzoom the map (using the PageDown key or he mouse wheel), you will see a large circle around the waypoints. This circle show the allowed flying zone that the autopilot must not leave or it will enter an emergency navigation mode and circles the '''HOME''' waypoint until the further direction is received.

Move the waypoint '''2''' out of this circle (close to the circle in the north-east corner) and switch back to the 'Line 1-2''' block to force the plane to get out of this safety zone.

The aircraft flies to the '''2''' waypoint, cross the protection enveloppe and switches to ''home'' mode: the AP mode in the aircraft strip switches from '''AUTO2''' to '''HOME'''.

To get out of this mode and switch back to the default '''AUTO2''', click on the '''AUTO2''' button in the aircraft strip. The aircraft then flies again towards '''too far''' and again swithes to '''HOME''' mode.

== Change the environment ==

Launch the '''Environment Simulator''' from the '''Tools' menu in the '''Paparazzi Center'''.

This interface (also called'''Gaia''') allows the user to change:
* The wind: Set up a wind speed of 5m/s and observe the trajectory and the speed evolution (in the aircraft strip and in the '''PFD''' page of the notebook).
* The GPS coverage: Shut down the GPS ('''GPS OFF''') and observe the resulting mode ('''NO_GPS''') and trajectory. In this mode, the autopilot uses the failsafe roll, pitch and throttle settings defined in the airframe file. Note that in a real flight, an aircraft without GPS won't be able to send its position ... The simulation is cheating here !
* The time scale: If you are in a hurry ... Do not use a time higher than 2 for this first demonstration.

== Other navigation patterns ==

Using the buttons in the strip, you can play with other navigation patterns: figure of eights, oval, survey of a rectangle (with a north-south sweeping), ''Turn around here'' (which sets a waypoint to the current location of the plane and flies a circle around).

== Landing ==

To automatically land the aircraft:
* Set the '''TD''' (Touch Down) waypoint where you want to land. Be sure that the waypoint is on the ground (185m in Muret)
* Set the '''AF''' (Approach Fix) waypoint where you want to start the final descent (the ''glide''). If you have set some wind with Gaia, you probably want to fly '''AF-TD''' upwind (an estimation of the wind experienced by the aircraft is displayed in the left-upper corner of the map).
* Switch to the '''Land right''' or the '''Land left''' block (icons in the strip) according to the direction of the last turn you want to do (for example, if '''AF''' is on the east side of '''TD''' and you want to maneuvre from the north, choose a '''Land right''')

== Multiple UAV Simulation ==

To simulate multiple aircrafts, you just have to launch a second simulator (tools->simulator, then -a yourairframe) and the server and the GCS should take care of the rest.

== View the simulation in Flight Gear ==

To view the simulation in Flight Gear, do the following:
*in your root folder:
sudo apt-get install flightgear
*go to Paparazzi
cd ~/paparazzi
./paparazzi
* In Paparazzi Center, add to the simulator command the <tt>-fg</tt> option plus the IP address of the machine running flightgear:
.../sw/simulator/launchsitl -a TJ1 -fg 127.0.0.1 -boot -norc
* Launch Flight Gear with the following command:
fgfs --fdm=null --native-gui=socket,in,30,,5501,udp

=== Why is it night in Flight Gear, if my sim is flying during the day? ===
The time that is sent to Flight Gear is hard coded into the code, so if you try to view the output of the simulation and your simulated flight is located far from France, in Flight Gear, everything may be dark. If your simulated flight is in France, then you will always have daylight in Flight Gear. To fix this, do the following (you will need to have paparazzi-dev installed to do this):

* Get the Unix time during your '''local daylight hours''' by running the following command in your terminal:
date +%s
* In the file: paparazzi/sw/simulator/fg.c find the line(line 44):
msg.cur_time = 3213092700ul;//time(NULL);
* Paste the output from "date +%s" in place of "3213092700"
* Now you will have to rebuild paparazzi, so in the terminal change to the paparazzi directory and run:
make clean
make
* In Paparazzi Center clean and rebuild your simulation
* Launch the simulation and Flight Gear, and Flight Gear should be flying in daylight.

== JSBSim ==
Paparazzi can work with [http://jsbsim.sourceforge.net/ JSBSim], a great open source flight dynamics library. For instructions on JSBSIM on Mac OS X go [http://paparazzi.enac.fr/wiki/InstallationMacOSX#Simulations_Using_JSBSim here].

==== For a fixed wing aircraft: ====

Install JSBSim. This can be done from the CVS repository as per the [[BoozSimulator]] page, or using apt-get:
$ sudo apt-get install jsbsim

In your airframe file add the following section:

<section name="SIMU">
<define name="JSBSIM_MODEL" value="&quot;Malolo1&quot;"/>
<define name="JSBSIM_IR_ROLL_NEUTRAL" value="RadOfDeg(0.)"/>
<define name="JSBSIM_IR_PITCH_NEUTRAL" value="RadOfDeg(0.)"/>
</section>

In this case, the JSBSim model used is <tt>conf/simulator/Malolo1</tt>. To create your own model make a new directory under <tt>conf/simulator</tt> and put your JSBSim model there, and adapt the <tt>"JSBSIM_MODEL"</tt> in the <tt>SIMU</tt> section accordingly.

Add another target to the <tt>"fixedwing"</tt> <tt>firmware</tt> section of your airframe file:
<code><target name="jsbsim" board="pc" /></code>

If you choose to use the CVS code, then you may have to add a <tt><makefile></tt> section to your airframe file and add the correct flags to point to the include files and libraries, depending on where you installed it.
With the default installation to <tt>/usr/local/</tt>, this would look like
<makefile location="after">
jsbsim.CFLAGS += -I/usr/local/include/JSBSim
jsbsim.LDFLAGS += -L/usr/local/lib
</makefile>

Now you can can compile the airframe for the jsbsim target. Launch the simulator as normal, but add the option <tt>-jsbsim</tt>. Note that FlightGear visualization can be used in conjunction with the JSBSim simulation, just be sure to add the <tt>-fg 127.0.0.1</tt> option as described [[Simulation#View_the_simulation_in_Flight_Gear|above]]. Using both JSBSim and FlightGear, it would be:
<code><paparazzi home directory>/sw/simulator/launchsitl -a <aircraft_name> -jsbsim -boot -norc -fg 127.0.0.1</code>

You will notice the default control parameters do not fly the Malolo1 airframe particularly well.

The Microjet aircraft can be used as an example; it has the right target and <tt>"SIMU"</tt> section added.

==== Using Optional Parameters ====

There are a few optional parameters that can be used with a JSBSim simulation.

The initial body-aligned forward speed of the aircraft in m/s can be specified in the <tt>"SIMU"</tt> section of the airframe file:

<section name="SIMU">
...
<define name="JSBSIM_LAUNCHSPEED" value="15.0"/>
...
</section>

The initial conditions for the simulation can be set with an initialization file. Add the following to the <tt>"SIMU"</tt> section of the airframe file:

<section name="SIMU">
...
<define name="JSBSIM_INIT" value="&quot;Malolo1-IC&quot;"/>
...
</section>

In this case, the initialization file for the Malolo1 used is <tt>conf/simulator/Malolo1/Malolo1-IC.xml</tt>. To create your own initialization file, use this file as an example, place the file into your JSBSim model directory, and adapt <tt>"JSBSIM_INIT"</tt> in the <tt>SIMU</tt> section accordingly.

These options are demonstrated in the jsbsim.xml example airframe file in <tt>/conf/airframes/jsbsim.xml</tt>. The control parameters in this example are much better in controlling the Malolo1 airframe.

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

WeatherStationInterface

2011-04-18T08:02:21Z

Agaeb: First version: short description and options list

= Weather Station Interface =

The weather station interface <tt>davis2ivy</tt> polls Davis VantagePro/VantagePro2 stations and broadcasts the current weather data (ambient pressure, temperature, wind speed and direction) over Paparazzi's message system.
Connect the station via a serial port.

<tt>davis2ivy</tt> may send messages with different aircraft IDs.
The simplest way is to use the ID of the actually flying aircraft, thus the messages will show up in the messages window and in the log file as if they were sent from that aircraft.
If you use another aircraft ID, you have to add the <tt>-a</tt> option to get the messages into the log file.

== Options ==
The program can be found in <tt>$PAPARAZZI_HOME/sw/ground_segment/misc</tt>.
* <tt>-a</tt> Send ALIVE message
* <tt>-b <bus></tt> Specify Ivy bus (default is 127.255.255.255:2010)
* <tt>-d <device></tt> Specify the weather station device (default is <tt>/dev/ttyUSB1</tt>)
* <tt>-i <number></tt> Specify the aircraft ID (default is 1)
* <tt>-s <number></tt> Specify the interval between station polls in seconds (default is 1)

== External Links ==
[http://www.davisnet.com/weather/products/vantage-pro-professional-weather-stations.asp| Vantage Pro2 product page]

Paparazzi Center

2011-04-18T07:41:01Z

Agaeb: /* Tools */ added weather station link

The Paparazzi Center is a graphical user interface which contains a notebook of three main pages:
* A set of selection boxes to configure an aircraft with its flight plan and build the corresponding programs to be simulated and uploaded to the airborne device.
* A Control Panel to launch the agents of the system and handle collection of programs as configurable sessions
* A page where the [[GCS]] may be embedded.

A log console is also diplayed in the configuration and control panel pages.

If you use the Paparazzi binary package (version >= 3.2), the Paparazzi Center executable is <tt>paparazzi</tt> and is included in the Applications menu. If you use the CVS code, run the <tt>./paparazzi</tt> script at the root of the distribution.

'''Options:'''
* <tt>-fullscreen</tt>

[[Image:paparazzi_center.png|Paparazzi Center]]

== Configuration ==

The left part of the configuration page is an editor for the [[Conf.xml]] file. A new aircraft can be added from the A/C menu. The current aircraft can be deleted from the A/C menu.

The editor for the configuration files is taken from the environment variable EDITOR or defaults to ''gedit''.

Note: Several setting files can be simultaneously selected for the '''Settings''' attribute (use the CRTL key in the file selector)

== Compilation ==
Compilation and flashing are done from the building panel. Targets can be added to the combo box with the New Target button. Compilation and flashing commands are shown as running agents so they can be interrupted if needed.

== Execution ==

In the Execution panel, a combo box provide a set of predefined and user ''sessions'' (collections of programs).

The Simulation session runs a server, a GCS and a simulator for the aircraft selected in the configuration panel. Note that the '''sim''' target must have been built prior to the simulation.

The launched programs can be stopped and restarted (Stop/Redo buttons). Options can also be edited (in the entry box). Automatic respawn is enabled by setting the check box (left side of the Stop/Redo button). The set of the current processes can be saved as a user ''session'' (actually in the <tt>conf/control_panel.xml</tt> configuration file) to
be restarted later (from the Session menu).

=== Tools ===
The '''Tools''' menu contains the most important programs to run everything (look also at the [[Overview]] of the system):

* ''[[GCS]]'' Ground Control Station with lots of [[GCS_Configuration#Configuration_Options| configuration options]]
* A ''server'' (logger and message dispatcher for [[GCS]])
** turn of logging: -n
* Simulators (built with the '''sim''' target in the control panel)
* ''link'' to connect to the [[Modems]]
** set baud rate: -s 57600
** set device: -d /dev/ttyUSB0
* A ''messages'' window (messages bus observer)
* The ''Environment Simulator (Gaia)'' agent (time, wind, ... simulator)
* A [[RTPlotter|Real Time Plotter]]
* A [[Plotter|Log Plotter]]
* A log re''play''er
* An [[WeatherStationInterface|interface to weather stations]]
These different agents are available from the Tools menu.

The set of running agents can be saved as a new custom session (from the Session menu). The current session can also be deleted.

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

Airframe Configuration

2011-03-23T09:21:27Z

Agaeb: /* Telemetry (Modem) */ link added

The airframe configuration file is located in <tt>conf/airframes</tt> and contains
all the hardware and software settings for an aircraft. All gains, trims, and behavior settings are defined with standard XML elements. Optionally you can also add a raw [http://en.wikipedia.org/wiki/Makefile Makefile] section.

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

Note that the airframe XML document always begins with a <!DOCTYPE airframe SYSTEM "airframe.dtd"> line--[[User:Openuas|OpenUAS]] 14:32, 22 March 2010 (CET).

== XML Parameters ==

=== Commands ===

The <b><tt>commands</tt></b> lists the abstract commands you need to control the aircraft. In our example, we have only three:
<tt>
<commands>
<axis name="THROTTLE" failsafe_value="0"/>
<axis name="ROLL" failsafe_value="0"/>
<axis name="PITCH" failsafe_value="0"/>
</commands></tt>

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

=== Servos ===

The above commands get translated to the <b><tt>servos</tt></b> here. In the example below we use two elevons and a motor. ([http://en.wikipedia.org/wiki/Elevon ''Elevons''] are surfaces used for both pitch and roll as on a flying wing.) These servos are listed in the <b><tt>servos</tt></b> section:
<tt>
<servos>
<servo name="THROTTLE" no="0" min="1000" neutral="1000" max="2000"/>
<servo name="ELEVON_LEFTSIDE" no="1" min="2000" neutral="1500" max="1000"/>
<servo name="ELEVON_RIGHTSIDE" no="2" min="1000" neutral="1500" max="2000"/>
</servos></tt>

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

Note the following important tips:
* Reverse the servo direction by exchanging min/max
* Trim should always be adjusted mechanically if possible to avoid asymmetrical travel
* Any reduction of the total travel range should be done mechanically to maintain precision
* Many servos will respond well to values slightly outside the normal 1000-2000ms range but experiment carefully as the servo may not operate reliably outside this range and may even suffer permanent damage.
* Board connector numbering starts with <b>zero (0)</b> not with one
* Servos are also known under the synonym <b>actuators</b>

The <b><tt>servos</tt></b> are then linked to the commands in the <b><tt>command_laws</tt></b> section:
<tt>
<command_laws>
<let var="aileron" value="@ROLL * 0.3"/>
<let var="elevator" value="@PITCH * 0.7"/>
<set servo="THROTTLE" value="@THROTTLE"/>
<set servo="ELEVON_LEFTSIDE" value="$elevator + $aileron"/>
<set servo="ELEVON_RIGHTSIDE" value="$elevator - $aileron"/>
</command_laws></tt>

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

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

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

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

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

=== RC commands in Auto ===
To control servos or other servo signal compatible devices by RC in Auto1 or Auto2, define them in the <auto_rc_commands> section.
If you have an airframe with a dedicated rudder (YAW channel) then it is still controllable in auto mode via RC. This is the default behavior and is equivalent to setting the YAW command in auto_rc_commands:

<auto_rc_commands>
<set command="YAW" value="@YAW"/>
</auto_rc_commands>

To disable this behavior (meaning no RC control of the rudder in auto) define an empty auto_rc_commands section:

<auto_rc_commands>
</auto_rc_commands>

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

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

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

=== ADC Generic ===

If you want to receive the value of some ADC channel, you can use the "ADC Generic" [[Modules|module]]. When activated, the aircraft sends 2 values corresponding to the selected ADC channels. They can be read from the "Messages" application.
Add the adc_generic to your modules:
<pre>
<modules>
...
<load name="adc_generic.xml">
<configure name="ADC_CHANNEL_GENERIC1" value="ADC_3"/>
<configure name="ADC_CHANNEL_GENERIC2" value="ADC_4"/>
</load>
</modules>
</pre>

In this example, the ADC channels 3 and 4 are read and sent by telemetry at 4Hz:
<message name="ADC_GENERIC" ID="18">
<field name="val1" type="uint16"/>
<field name="val2" type="uint16"/>
</message>
Only one or two channels can be defined. If only one is activated, 0 will be sent for the unused value.

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

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

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

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

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

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

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

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

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

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

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

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

An asymmetric (left/right, front/rear) correction can be added with a last set of factors.
<define name="CORRECTION_UP" value="1."/>
<define name="CORRECTION_DOWN" value="1."/>
<define name="CORRECTION_LEFT" value="1."/>
<define name="CORRECTION_RIGHT" value="1."/>
</section>
These corrections are set on the angles.
You don't have to set these as they are set to 1. per default, but adjust them if needed.

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

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

=== Bat ===
This section give characteristics for the monitoring of the main power battery. <b><tt>MILLIAMP_AT_FULL_THROTTLE</tt></b> represents the actual current (in mA) when full THROTTLE is applied. It is used to compute the <tt>energy</tt> value of the <tt>BAT</tt> message when no [[Current_sensor|Current sensor]] is mounted in the airframe. This value can also be used in flight plans. For example, if at full throttle your motor consumes 10 Amps, use a value of 10000. At 50% throttle it is likely to use about 5 Amps so the autopilot can have a better idea how much energy is remaining. You can "tweak" this number after a few flights to match the capacity of your battery. If upon landing your bat.energy messages says that you used 2500 mAh while the battery has only 2000 mAh capacity, you could reduce the MILLIAMP_AT_FULL_THROTTLE value by 20% to match your in-flight current consumption.

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

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

<tt>
<section name="BAT">
<define name="MILLIAMP_AT_FULL_THROTTLE" value="12000" unit="mA" />
<define name="VOLTAGE_ADC_A" value="0.0177531"/>
<define name="VOLTAGE_ADC_B" value="0.173626"/>
<define name="VoltageOfAdc(adc)" value ="(VOLTAGE_ADC_A * adc + VOLTAGE_ADC_B)"/>
<define name="CATASTROPHIC_BAT_LEVEL" value="6.0" unit="V"/>
<define name="CRITIC_BAT_LEVEL" value="6.5" unit="V"/>
<define name="LOW_BAT_LEVEL" value="7.0" unit="V"/>
<define name="MAX_BAT_LEVEL" value="8.4" unit="V"/>
</section>
</tt>

Find more in depth information on how to [[Current_sensor|get a separate current sensor working by clicking here]]

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

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

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

The [[Control_Loops#Fixed-wing_autopilot|graphical representation of the control loops]] can help you to visualize the effect of each gain.

===Vertical Control===

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

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

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

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

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

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

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

The [[Control_Loops#Fixed-wing_autopilot|graphical representation of the control loops]] can help you to visualize the effect of each gain.

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

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

=== Simu ===
Values from this section can be used to tweak the SITL simulation.

<tt>
<section name="SIMU">
<define name="WEIGHT" value ="1."/>
<define name="YAW_RESPONSE_FACTOR" value ="1."/>
<define name="ROLL_RESPONSE_FACTOR" value ="15."/>
</section>
</tt>

* "YAW_RESPONSE_FACTOR" adapts the aircraft's turn rate corresponding to a bank angle; a larger value increases the turn radius
* "ROLL_RESPONSE_FACTOR" is basically your aileron efficiency; a higher value increases roll agility

If you want to use JSBSim as SITL simulator, you have to make some definitions in this section as well; see [[Simulation#JSBSim|here]].

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

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

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

== Firmware and Hardware definitions ==

=== Select your Board ===
The airframe file must include the description of the controller board and it's low-level settings.
This is done in the <b><tt>firmware</tt></b> section by specifying the ''board'' attribute for the ''target'' "ap" (autopilot).

Select the appropriate board:
"twog_1.0", "tiny_2.11", "tiny_2.1", "tiny_1.1", "tiny_0.99", "booz_1.0", "lisa_l_1.0", "lisa_l_1.1", "pc"

{{Box Code|conf/airframes/myplane.xml|
<pre>
<firmware name="fixedwing">
<target name="sim" board="pc"/>
<target name="ap" board="tiny_2.11"/>
.
.
.
</firmware>
</pre>
}}

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

Proper Spektrum support is on the way.

Just specify the appropriate subsystem in your firmware section:
{{Box Code|conf/airframes/myplane.xml|
<pre>
<firmware name="fixedwing">
<target name="sim" board="pc"/>
<target name="ap" board="tiny_2.11"/>
.
.
.
<subsystem name="radio_control" type="ppm"/>
</firmware>
</pre>
}}

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

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

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

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

Just specify the appropriate subsystem in your firmware section. You can currently choose between the types '''transparent''' and '''xbee_api'''.
{{Box Code|conf/airframes/myplane.xml|
<pre>
<firmware name="fixedwing">
<target name="ap" board="tiny_2.11"/>
.
.
.
<subsystem name="telemetry" type="transparent"/>
</firmware>
</pre>
}}

The correct UART is already defined by default according to your board.
The default modem baudrate is 57600baud.

If you use different baud rate or Uart set the according parameters, e.g.
{{Box Code|conf/airframes/myplane.xml|
<pre>
<firmware name="fixedwing">
<target name="ap" board="tiny_2.11"/>
.
.
.
<subsystem name="telemetry" type="transparent">
<configure name="MODEM_BAUD" value="B9600"/>
<configure name="MODEM_PORT" value="UART1"/>
</subsystem>
</firmware>
</pre>
}}

==== Configuring The Serial Protocol ====
New users are advised to start with the standard serial protocol before attempting to setup an addressed API link. There are no real reasons for the novice user to use the xbee protocol over the standard PPRZTransport. Even if you are using a Maxstream modem you should still start out with the standard. Lastly it should be pointed out that using a single UAS there is no disadvantage and that the [http://www.engr.usu.edu/wiki/index.php/OSAM OSAM] Paparazzi Team at UAS 2008 took second place using the STANDARD protocol. The serial protocol works with virtually any modem as well as direct cable connections. The baud rates of the airborne modem, autopilot, ground modem, and PC must be configured correctly. The PC and autopilot serial ports do not need to be set to the same baud rate, i.e. when running multiple aircraft from a single ground modem, the ground modem may require a higher baud rate than any of the airborne modems in order to stream the data from multiple simultaneous sources.

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

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

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

=====Alternate Method=====
This is the way it is done in funjet1.xml and has been tested to work by Danstah

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

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

<section name="DATALINK" prefix="DATALINK_">
<define name="DEVICE_TYPE" value="XBEE"/>
<define name="DEVICE_ADDRESS" value="...."/>
</section>
</nowiki>
}}

Keep in mind that the ground modem baud rate and aircraft modem baud rate do not have to match. What does need to match however is the baud rate of your modem build into the aircraft and the rate defined in the airframe file. For example if this aircraft modem is set to 9600Baud, this modem can connect with a ground modem configured set to 57600Baud.
Also for multiple UAS, a good way to configure them is to use 9600Baud for the Autopilot board and use a ground modem configured to 57600Baud. After your aircrafts are working well, set your configuration to use minimal telemetry.

==== Set GCS baud rate ====
Set can set the baudrate for the link in the GCS by specifying ''-s 57600'' as a parameter to link. Then just save your session so you won't have to change it again next time.

You can also manually write a session:
{{Box Code|conf/control_panel.xml|
<nowiki>
<session name="USB">
<program name="link">
<arg flag="-d" constant="/dev/ttyUSB0"/>

<arg flag="-s" constant="57600"/>
</program>
...
</session>
</nowiki>
}}

Use this constant /dev/paparazzi/ttyUSB0 when using either the ftdi cable or a Maxstream USB ground modem.. Otherwise use /dev/ttyUSB0 (the ttyUSB0 being the device that you are using. Note: it might not always be ttyUSB0). This paparazzi directory in the dev folder is created when setting the udev rules. [http://paparazzi.enac.fr/wiki/Installation#Setting_access_rights_for_USB_download Setting Udev rules]

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

Just specify the appropriate subsystem in your firmware section. You can currently choose between the types '''ublox_lea5h''' and '''ublox_lea4p'''.
{{Box Code|conf/airframes/myplane.xml|
<pre>
<firmware name="fixedwing">
<target name="ap" board="tiny_2.11"/>
.
.
.
<subsystem name="gps" type="ublox_lea5h"/>
</firmware>
</pre>
}}

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

If you use different baud rates set the according parameters, e.g.
{{Box Code|conf/airframes/myplane.xml|
<pre>
<firmware name="fixedwing">
<target name="ap" board="tiny_2.11"/>
.
.
.
<subsystem name="gps" type="ublox_lea4p">
<configure name="GPS_BAUD" value="B9600"/>
</subsystem>
</firmware>
</pre>
}}

'''Note:'''
* u-blox GPS modules are factory configured for 9600 baud, 38,400 baud is recommended along with the other required changes. The GPS can be accessed directly thrugh the [[Compiling#USB_flashing|UART Tunnel]] and [[GPS#GPS_configuration_using_U-Center|Configured with u-center]]

=== Control loops ===

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

Just specify the appropriate subsystem in your firmware section. You can currently choose between no type (see below) and the types '''adaptive''' and '''new'''.
{{Box Code|conf/airframes/myplane.xml|
<pre>
<firmware name="fixedwing">
<target name="ap" board="tiny_2.11"/>
...
<subsystem name="control"/>
</firmware>
</pre>
}}

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

Common problems

2011-01-11T11:52:52Z

Agaeb: Added No GPS position item

<noinclude>
{| width="100%" style="border: solid 2px #A3B1BF; background: #F5FAFF" |
|-
|
<h2 style="background-color:#cedff2; border-bottom:0px; border: 1px solid #a3b0bf; text-align:center; padding-top:4px;">Paparazzi FAQ - Common problems and solutions
</h2></noinclude>
<br/>
__NOTOC__ __TOC__

==I only get a blank (black) GCS==
:The GCS stays blank until you get telemetry messages (either from the real aircraft or simulated) with the correct MD5 checksum meaning the autopilot has the correct and up to date flightplan/airframe/... programmed in it (in case of an MD5 problem you constantly get a lot of warnings in paparazzi center).
:'''Solution''': Probably your telemetry is not set up correctly, this is most likely a [[XBee configuration]] issue.

==I get a Failure("#of_world:no georef") when trying to load map tiles==
:You get the georef error because the location is not initialized (probably GCS still blank and no aircraft are present). You can't get map tiles for nowhere...
:'''Solution''': Set up your telemetry properly so you get messages from the aircraft OR start a simulation with the appropriate coordinates then load the map tiles.

==How do I check if my telemetry is working?==
:'''Solution''': Launch the link and messages tools in the Paparazzi Center. You should see the the messages coming in (blinking green) in the messages window.
: You might need to adjust the device and baud-rate of the link according to your setup, e.g. <tt>link -d /dev/ttyUSB0 -s 57600</tt>
: If you're stuck you can make ''link'' very verbose by setting the ''PPRZ_DEBUG'' environment variable to '' '*' ''

==No GPS position==
:'''Problem''': Your GPS seems to be working, but you cannot get a valid position fix. Speed and course are displayed correctly, though. Possibly you also see Invalid_argument("Latlong.of_utm") errors on the GCS log.

This may happen if you have configured the wrong GPS subsystem for your Tiny board.
If you have the LEA-5H module on your Tiny board, but have configured
<tt><subsystem name="gps" type="ublox_lea4p"/></tt>
in your airframe file, this will occur because the 5H module does not support UTM position.

:'''Solution''': Change the gps type to "<tt>ublox_lea5h</tt>" or add a <tt><define name="GPS_USE_LATLONG"/></tt> flag.

|}

Flight Plan Examples

2010-12-08T07:46:30Z

Agaeb: /* Takeoff */ corrected pitch attribute description

This page will detail a number of flight plan examples.

== Takeoff ==

The block of code:

<block key="t" name="Takeoff" strip_button="Takeoff" strip_icon="takeoff.png">
<set value="0" var="kill_throttle"/>
<set value="0" var="estimator_flight_time"/>
<go from="START" pitch="-10" throttle="1.0" vmode="throttle" wp="ER"/>
</block>

Below is an explanation of the code - left to right, top to bottom.

key accelerator to select the block with the keyboard (press t for takeoff)
key="t"

the name of the block
name="Takeoff"

This shows as the name when you hover your mouse over the button
strip_button="Takeoff"

The name of the icon picture shown in the GCS
strip_icon="takeoff.png"

This turns on the option to change the throttle
<set value="0" var="kill_throttle"/>

This turns on the flight time estimator
<set value="0" var="estimator_flight_time"/>

<go from="START" pitch="-10" throttle="1.0" vmode="throttle" wp="ER"/>

This says for the aircraft to go from "START" waypoint towards "ER" (end runway) waypoint with a pitch angle setpoint of -10 degrees (to keep the aircraft on the ground) and throttle at 100%.
You would also add a deroute option to change to the "CLIMB" waypoint (the waypoint that gets the aircraft up to the correct height) once the aircraft was moving above stall speed. I will add the code for this soon.

vmode="throttle" switches the vertical control into autothrottle mode; possible other values are climb, alt, xyz, or glide.

This code will work in theory, but may not in practice, especially if you only have a narrow runway or your aircraft takes a long time to get up to speed. This is because the autopilot is not exact in its estimation of where it is.

== Surveying an area ==

There are two types of survey, two waypoint survey or Polysurvey. PolySurvey can be called multiple times during a flight plan but I am not sure how to do this (SOMEONE PLEASE UPDATE).

<block name="Initialize Poly Survey">
<call fun="InitializePolygonSurvey(WP_S1, 5, 150, 45)"/>
</block>

<block name="Run Poly Survey">
<call fun="PolygonSurvey()"/>
</block>

You will notice that there are two blocks of code instead of a single block. This because when you are surveying an area you may want to stop the survey and take a closer look at something (for instance you may wish to circle something of interest). If you want to continue the survey from the point where you stopped to look closer at the thing of interest all you need to do is call the "Run Poly Survey" block.

<call fun="InitializePolygonSurvey(WP_S1, 5, 150, 45)"/>
This initializes the PolySurvey starting with Waypoint S1 and using 5 waypoints (in sequence, eg S1, S2, S3, S4, S5), with a distance between each survey line of 150 meters and an angle of survey of 45 degrees from the initial waypoint.

<call fun="PolygonSurvey()"/>
This calls the PolySurvey, you may want to call this either via a button on the GCS or by calling it in external code for example an automated IR sensor (if you are looking for a person).

=== Mission Actions ===

During the survey, polygonsurvey and the oval, mission actions can be triggered during the straight parts using the

#define LINE_START_FUNCTION
#define LINE_STOP_FUNCTION

defines in the flight plan. One example would be to start taking pictures or even limit the maximal roll angle (be careful with the roll angle limit: if the aircraft does not follow the circle very well, it might still need to turn the first part of the line: make a button to restore max_roll in case of problems). At the top of the flight plan file you can define:

<header>
#include "dc.h"
#include "fw_h_ctl.h"
#define LINE_START_FUNCTION {dc_shoot = 1; h_ctl_roll_max_setpoint = DEG2RAD(15);}
#define LINE_STOP_FUNCTION {dc_shoot = 0; h_ctl_roll_max_setpoint = H_CTL_ROLL_MAX_SETPOINT;}
</header>

== Landing your aircraft ==

<block name="final">
<exception cond="ground_alt + 10 > estimator_z" deroute="flare"/>
<go from="AF" hmode="route" vmode="glide" wp="TD"/>
</block>

Above is the final Block. This block is used to bring the aircraft towards the end of the runway (or landing area) which is the "AF".

<go from="AF" hmode="route" vmode="glide" wp="TD"/>
Fly from waypoint "AF" to waypoint "TD" and glide between them to maintain the angle between them. You may want these two waypoints to be a significant distance between them if you want the aircraft to come in on a very shallow angle.

<exception cond="ground_alt + 10 > estimator_z" deroute="flare"/>
"flare" is the deroute condition and it is implemented when the aircraft is 10 meters from the ground.

<block name="flare">
<go approaching_time="0" from="AF" hmode="route" throttle="0.0" vmode="throttle" wp="TD"/>
<attitude roll="0.0" throttle="0.0" until="FALSE" vmode="throttle"/>
</block>

You would want the aircraft to flare just before hitting the ground. If your aircraft is not very stable at low speeds you may want to make the distance above ground lower.

<attitude roll="0.0" throttle="0.0" until="FALSE" vmode="throttle"/>
This lets the aircraft fly with roll controlled at neutral (0°) and throttle off.

Flight Plan Editor

2010-12-07T16:01:54Z

Agaeb: Link to examples

The GCS can be launched with the <tt>-edit</tt> option which adds an ''Edit'' menu. A simple layout is displayed with only two parts, the map and the XML view.
See [[Flight Plan Examples|here]] for some flight plan examples.
__TOC__
[[Image:gcs_editor.png|Flight Plan Editor]]
<br style="clear:both">

The ''Edit'' menu offers to load a flight plan or to create new one from scratch. In the latter case a simple template flight plan is loaded after filling in some entries in the toolbox (geographic reference, name, etc).

[[Image:new_flight_plan_editor.png|New flight plan dialogue]]

Only one flight plan is editable at a time. It must be saved in the <tt>conf/flight_plans</tt> directory.

Note that the map displays only the waypoints and the safety area. Trajectories (circles, segments, ...) do not appear and are editable only through the XML description.

== XML editor ==

The XML window is a syntactic editor which follows the grammar of a flight plan (from the DTD description). It is divided into two columns for elements and attributes. The elements are displayed as a tree while the attributes are displayed a list of pairs name-value.

Navigation in the tree is done in the standard way. Elements can be dragged across the tree, with the constraints of the grammar (a <tt>waypoint</tt> element cannot be dragged in a <tt>block</tt>). Elements are added with a right-click which pops up a contextual menu related to the pointed element. Deletion is done with this popup menu or with the DEL key.

The attributes of the selected element are displayed in the right column. Each value is editable. Right-click also gives a popup menu containing the allowed attributes for the current element.

== Waypoints ==

Waypoints can be created from the XML editor or directly in the 2D map with CTRL-Left-Click. The waypoints are movable (click and drag) and editable (single click).

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

Flight Plan Examples

2010-12-07T15:57:24Z

Agaeb: /* Takeoff */ listed possible vmodes

This page will detail a number of flight plan examples.

== Takeoff ==

The block of code:

<block key="t" name="Takeoff" strip_button="Takeoff" strip_icon="takeoff.png">
<set value="0" var="kill_throttle"/>
<set value="0" var="estimator_flight_time"/>
<go from="START" pitch="-10" throttle="1.0" vmode="throttle" wp="ER"/>
</block>

Below is an explanation of the code - left to right, top to bottom.

key accelerator to select the block with the keyboard (press t for takeoff)
key="t"

the name of the block
name="Takeoff"

This shows as the name when you hover your mouse over the button
strip_button="Takeoff"

The name of the icon picture shown in the GCS
strip_icon="takeoff.png"

This turns on the option to change the throttle
<set value="0" var="kill_throttle"/>

This turns on the flight time estimator
<set value="0" var="estimator_flight_time"/>

<go from="START" pitch="-10" throttle="1.0" vmode="throttle" wp="ER"/>
This says for the aircraft to go from "START" waypoint towards "ER" (end runway) waypoint with a elevator pitch of -10% (to keep the aircraft on the ground) and throttle at 100%. You would also add a deroute option to change to the "CLIMB" waypoint (the waypoint that gets the aircraft up to the correct height) once the aircraft was moving above stall speed. I will add the code for this soon.

vmode="throttle" switches the vertical control into autothrottle mode; possible other values are climb, alt, xyz, or glide.

This code will work in theory, but may not in practice, especially if you only have a narrow runway or your aircraft takes a long time to get up to speed. This is because the autopilot is not exact in its estimation of where it is.

== Surveying an area ==

There are two types of survey, two waypoint survey or Polysurvey. PolySurvey can be called multiple times during a flight plan but I am not sure how to do this (SOMEONE PLEASE UPDATE).

<block name="Initialize Poly Survey">
<call fun="InitializePolygonSurvey(WP_S1, 5, 150, 45)"/>
</block>

<block name="Run Poly Survey">
<call fun="PolygonSurvey()"/>
</block>

You will notice that there are two blocks of code instead of a single block. This because when you are surveying an area you may want to stop the survey and take a closer look at something (for instance you may wish to circle something of interest). If you want to continue the survey from the point where you stopped to look closer at the thing of interest all you need to do is call the "Run Poly Survey" block.

<call fun="InitializePolygonSurvey(WP_S1, 5, 150, 45)"/>
This initializes the PolySurvey starting with Waypoint S1 and using 5 waypoints (in sequence, eg S1, S2, S3, S4, S5), with a distance between each survey line of 150 meters and an angle of survey of 45 degrees from the initial waypoint.

<call fun="PolygonSurvey()"/>
This calls the PolySurvey, you may want to call this either via a button on the GCS or by calling it in external code for example an automated IR sensor (if you are looking for a person).

=== Mission Actions ===

During the survey, polygonsurvey and the oval, mission actions can be triggered during the straight parts using the

#define LINE_START_FUNCTION
#define LINE_STOP_FUNCTION

defines in the flight plan. One example would be to start taking pictures or even limit the maximal roll angle (be careful with the roll angle limit: if the aircraft does not follow the circle very well, it might still need to turn the first part of the line: make a button to restore max_roll in case of problems). At the top of the flight plan file you can define:

<header>
#include "dc.h"
#include "fw_h_ctl.h"
#define LINE_START_FUNCTION {dc_shoot = 1; h_ctl_roll_max_setpoint = DEG2RAD(15);}
#define LINE_STOP_FUNCTION {dc_shoot = 0; h_ctl_roll_max_setpoint = H_CTL_ROLL_MAX_SETPOINT;}
</header>

== Landing your aircraft ==

<block name="final">
<exception cond="ground_alt + 10 > estimator_z" deroute="flare"/>
<go from="AF" hmode="route" vmode="glide" wp="TD"/>
</block>

Above is the final Block. This block is used to bring the aircraft towards the end of the runway (or landing area) which is the "AF".

<go from="AF" hmode="route" vmode="glide" wp="TD"/>
Fly from waypoint "AF" to waypoint "TD" and glide between them to maintain the angle between them. You may want these two waypoints to be a significant distance between them if you want the aircraft to come in on a very shallow angle.

<exception cond="ground_alt + 10 > estimator_z" deroute="flare"/>
"flare" is the deroute condition and it is implemented when the aircraft is 10 meters from the ground.

<block name="flare">
<go approaching_time="0" from="AF" hmode="route" throttle="0.0" vmode="throttle" wp="TD"/>
<attitude roll="0.0" throttle="0.0" until="FALSE" vmode="throttle"/>
</block>

You would want the aircraft to flare just before hitting the ground. If your aircraft is not very stable at low speeds you may want to make the distance above ground lower.

<attitude roll="0.0" throttle="0.0" until="FALSE" vmode="throttle"/>
This lets the aircraft fly with roll controlled at neutral (0°) and throttle off.

Control Loops

2010-11-30T10:52:02Z

Agaeb: file names

This page presents the default control loops used by the Paparazzi airborne code for navigation, guidance and control.

= General Information =

All the possible combinations of control loops might not be fully detailed.

In the following diagrams, the block '''s''' is used for the '''derivative''' function and '''1/s''' is used for the '''integrator''' function.

The variables' names are the one used in the airborne code (written in '''C'''). Most of this name can the used capitalized in the [[Airframe Configuration]] file in order to define the default value of these variables. If in capital letters in the diagrams, the value is fixed and cannot be changed using [[Settings]] mechanism.

= Fixed-wing autopilot =

== Global view ==

[[Image:Diagram_general.png|General overview]]

The elements '''servos''', '''rc_commands''', '''commands''' and '''command_laws''' correspond to specific section of the [[Airframe Configuration]] file. Most of the code located in these blocks is generated from the xml of th configuration file.

The value '''+/-9600''' correspond to '''+/-MAX_PPRZ'''. This '''pprz''' unit is used as a normalized internal unit for input and output values of the '''control_laws''' block.

== Navigation loop ==

The navigation loop is located in '''sw/airborne/nav.*'''. The navigation routines are called from the [[Flight Plans]].

== Course loop ==

[[Image:Diagram_course_loop.png|Course loop]]

The course loop is the upper stage of the horizontal control.
It is located in '''sw/airborne/firmwares/fixedwing/stabilization/stabilization_attitude.c''' (formerly fw_h_ctl.c).

== Roll loop ==

[[Image:Diagram_roll_loop.png|Roll loop]]

The roll loop is the lower stage of the horizontal control and is used for lateral attitude stabilization. It is located in '''stabilization_attitude.c'''.
If <tt>H_CTL_ROLL_ATTITUDE_GAIN</tt> is undefined, the code will fallback to a attitude-only loop, where <tt>estimator_p</tt> is disregarded and the gain for <tt>estimator_phi</tt> is <tt>H_CTL_ROLL_PGAIN</tt>.

== Altitude loop ==

[[Image:Diagram_altitude_loop.png|Altitude loop]]

The altitude loop is the upper stage of the vertical control.
It is located in '''sw/airborne/firmwares/fixedwing/guidance/guidance_v.c''' (formerly fw_v_ctl.c)

== Auto Throttle and Auto Pitch climb loops ==

Two climb loops are available. The are called from the [[Flight Plans#Navigation_modes|flight plan]] by changing the vertical navigation mode. The default mode is '''Auto Throttle'''.

[[Image:Diagram_auto_throttle_loop.png|Auto Throttle climb loop]]

[[Image:Diagram_auto_pitch_loop.png|Auto Pitch climb loop]]

The climb loop is the intermediate stage of the vertical control. It is located in '''guidance_v.c'''.

== Pitch loop ==

[[Image:Diagram_pitch_loop.png|Pitch loop]]

The pitch loop is the lower stage of the vertical control and is used for longitudinal attitude stabilization. It is located in '''stabilization_attitude.c'''.

== Control loops using Airspeed Sensor ==

Adding an airspeed sensor measures actual airspeed resulting in better throttle control and aircraft performance especially in windy conditions. The control loops using an airspeed sensor are described [[Airspeed_sensor|here]].

= Multi-rotor (Booz) autopilot =

Control Loops

2010-11-30T10:25:55Z

Agaeb: /* Roll loop */

This page presents the default control loops used by the Paparazzi airborne code for navigation, guidance and control.

= General Information =

All the possible combinations of control loops might not be fully detailed.

In the following diagrams, the block '''s''' is used for the '''derivative''' function and '''1/s''' is used for the '''integrator''' function.

The variables' names are the one used in the airborne code (written in '''C'''). Most of this name can the used capitalized in the [[Airframe Configuration]] file in order to define the default value of these variables. If in capital letters in the diagrams, the value is fixed and cannot be changed using [[Settings]] mechanism.

= Fixed-wing autopilot =

== Global view ==

[[Image:Diagram_general.png|General overview]]

The elements '''servos''', '''rc_commands''', '''commands''' and '''command_laws''' correspond to specific section of the [[Airframe Configuration]] file. Most of the code located in these blocks is generated from the xml of th configuration file.

The value '''+/-9600''' correspond to '''+/-MAX_PPRZ'''. This '''pprz''' unit is used as a normalized internal unit for input and output values of the '''control_laws''' block.

== Navigation loop ==

The navigation loop is located in '''sw/airborne/nav.*'''. The navigation routines are called from the [[Flight Plans]].

== Course loop ==

[[Image:Diagram_course_loop.png|Course loop]]

The course loop is the upper stage of the horizontal control. It is located in '''sw/airborne/fw_h_ctl.c'''.

== Roll loop ==

[[Image:Diagram_roll_loop.png|Roll loop]]

The roll loop is the lower stage of the horizontal control and is used for lateral attitude stabilization. It is located in '''sw/airborne/fw_h_ctl.c'''.
If <tt>H_CTL_ROLL_ATTITUDE_GAIN</tt> is undefined, the code will fallback to a attitude-only loop, where <tt>estimator_p</tt> is disregarded and the gain for <tt>estimator_phi</tt> is <tt>H_CTL_ROLL_PGAIN</tt>.

== Altitude loop ==

[[Image:Diagram_altitude_loop.png|Altitude loop]]

The altitude loop is the upper stage of the vertical control. It is located in '''sw/airborne/fw_v_ctl.c'''.

== Auto Throttle and Auto Pitch climb loops ==

Two climb loops are available. The are called from the [[Flight Plans#Navigation_modes|flight plan]] by changing the vertical navigation mode. The default mode is '''Auto Throttle'''.

[[Image:Diagram_auto_throttle_loop.png|Auto Throttle climb loop]]

[[Image:Diagram_auto_pitch_loop.png|Auto Pitch climb loop]]

The climb loop is the intermediate stage of the vertical control. It is located in '''sw/airborne/fw_v_ctl.c'''.

== Pitch loop ==

[[Image:Diagram_pitch_loop.png|Pitch loop]]

The pitch loop is the lower stage of the vertical control and is used for longitudinal attitude stabilization. It is located in '''sw/airborne/fw_h_ctl.c (!)'''.

== Control loops using Airspeed Sensor ==

Adding an airspeed sensor measures actual airspeed resulting in better throttle control and aircraft performance especially in windy conditions. The control loops using an airspeed sensor are described [[Airspeed_sensor|here]].

= Multi-rotor (Booz) autopilot =

Airframe Configuration

2010-08-12T14:10:11Z

Agaeb: /* Misc */

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

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

Note that the airframe XML document always begins with a <!DOCTYPE airframe SYSTEM "airframe.dtd"> line--[[User:Openuas|OpenUAS]] 14:32, 22 March 2010 (CET).

== XML Parameters ==

=== Commands ===

The <b><tt>commands</tt></b> lists the abstract commands you need to control the aircraft. In our example, we have only three:
<tt>
<commands>
<axis name="THROTTLE" failsafe_value="0"/>
<axis name="ROLL" failsafe_value="0"/>
<axis name="PITCH" failsafe_value="0"/>
</commands></tt>

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

=== Servos ===

The above commands get translated to the <b><tt>servos</tt></b> here. In the example below we use two elevons and a motor. ([http://en.wikipedia.org/wiki/Elevon ''Elevons''] are surfaces used for both pitch and roll as on a flying wing.) These servos are listed in the <b><tt>servos</tt></b> section:
<tt>
<servos>
<servo name="THROTTLE" no="0" min="1000" neutral="1000" max="2000"/>
<servo name="ELEVON_LEFTSIDE" no="1" min="2000" neutral="1500" max="1000"/>
<servo name="ELEVON_RIGHTSIDE" no="2" min="1000" neutral="1500" max="2000"/>
</servos></tt>

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

Note the following important tips:
* Reverse the servo direction by exchanging min/max
* Trim should always be adjusted mechanically if possible to avoid asymmetrical travel
* Any reduction of the total travel range should be done mechanically to maintain precision
* Many servos will respond well to values slightly outside the normal 1000-2000ms range but experiment carefully as the servo may not operate reliably outside this range and may even suffer permanent damage.
* Board connector numbering starts with zero(0) not with one

The <b><tt>servos</tt></b> are then linked to the commands in the <b><tt>command_laws</tt></b> section:
<tt>
<command_laws>
<let var="aileron" value="@ROLL * 0.3"/>
<let var="elevator" value="@PITCH * 0.7"/>
<set servo="THROTTLE" value="@THROTTLE"/>
<set servo="ELEVON_LEFTSIDE" value="$elevator + $aileron"/>
<set servo="ELEVON_RIGHTSIDE" value="$elevator - $aileron"/>
</command_laws></tt>

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

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

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

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

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

=== RC commands in Auto ===
To control servos or other servo signal compatible devices by RC in Auto1 or Auto2, define them in the <auto_rc_commands> section.
If you have an airframe with a dedicated rudder (YAW channel) then it is still controllable in auto mode via RC. This is the default behavior and is equivalent to setting the YAW command in auto_rc_commands:

<auto_rc_commands>
<set command="YAW" value="@YAW"/>
</auto_rc_commands>

To disable this behavior (meaning no RC control of the rudder in auto) define an empty auto_rc_commands section:

<auto_rc_commands>
</auto_rc_commands>

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

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

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

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

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

==== ADC Generic ====

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

=== Bat ===
This section give characteristics for the monitoring of the main power battery. <b><tt>MILLIAMP_AT_FULL_THROTTLE</tt></b> represents the actual current (in mA) when full THROTTLE is applied. It is used to compute the <tt>energy</tt> value of the <tt>BAT</tt> message when no [[Current_sensor|Current sensor]] is mounted in the airframe. This value can also be used in flight plans. For example, if at full throttle your motor consumes 10 Amps, use a value of 10000. At 50% throttle it is likely to use about 5 Amps so the autopilot can have a better idea how much energy is remaining. You can "tweak" this number after a few flights to match the capacity of your battery. If upon landing your bat.energy messages says that you used 2500 mAh while the battery has only 2000 mAh capacity, you could reduce the MILLIAMP_AT_FULL_THROTTLE value by 20% to match your in-flight current consumption.

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

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

<tt>
<section name="BAT">
<define name="MILLIAMP_AT_FULL_THROTTLE" value="12000" unit="mA" />
<define name="VOLTAGE_ADC_A" value="0.0177531"/>
<define name="VOLTAGE_ADC_B" value="0.173626"/>
<define name="VoltageOfAdc(adc)" value ="(VOLTAGE_ADC_A * adc + VOLTAGE_ADC_B)"/>
<define name="CATASTROPHIC_BAT_LEVEL" value="6.0" unit="V"/>
<define name="CRITIC_BAT_LEVEL" value="6.5" unit="V"/>
<define name="LOW_BAT_LEVEL" value="7.0" unit="V"/>
<define name="MAX_BAT_LEVEL" value="8.4" unit="V"/>
</section>
</tt>

Find more in depth information on how to [[Current_sensor|get a separate current sensor working by clicking here]]

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

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

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

===Vertical Control===

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

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

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

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

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

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

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

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

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

=== Simu ===
Values from this section can be used to tweak the SITL simulation.

<tt>
<section name="SIMU">
<define name="WEIGHT" value ="1."/>
<define name="YAW_RESPONSE_FACTOR" value ="1."/>
<define name="ROLL_RESPONSE_FACTOR" value ="15."/>
</section>
</tt>

* "YAW_RESPONSE_FACTOR" adapts the aircraft's turn rate corresponding to a bank angle; a larger value increases the turn radius
* "ROLL_RESPONSE_FACTOR" is basically your aileron efficiency; a higher value increases roll agility

If you want to use JSBSim as SITL simulator, you have to make some definitions in this section as well; see [[Simulation#JSBSim|here]].

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

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

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

== Hardware definitions - Makefile ==

The airframe file must include the description of the controller board and it's low-level settings. This is done in one <b><tt>makefile</tt></b> section starting with the autopilot model and flashing mode:
{{Box Code|conf/airframes/myplane.xml|
<makefile>
include $(PAPARAZZI_SRC)/conf/autopilot/tiny.makefile
<nowiki>FLASH_MODE=IAP</nowiki>
<nowiki>ap.CFLAGS += -DFBW -DAP -DBOARD_CONFIG=\"tiny.h\" -DLED -DTIME_LED=1"</nowiki>
.
.
.
</makefile>
}}
Please note that -DCONFIG was changed to -DBOARD_CONFIG on 18 July 2009.

Below this are the definintions and configuration of the peripherals and interfaces.

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

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

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

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

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

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

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

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

<br style="clear:both>

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

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

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

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

<br style="clear:both>

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

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

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

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

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

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

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

{{Box Code|conf/airframes/myplane.xml|
<nowiki>ap.CFLAGS += -DGPS -DUBX -DUSE_UART1 -DGPS_LINK=Uart1 -DUART1_BAUD=B38400</nowiki>
<nowiki>ap.srcs += gps_ubx.c gps.c</nowiki>
}}
'''Note:'''
* Tiny 13 v1.1 uses UART1 while Tiny 2 uses UART0 for GPS
* u-blox GPS modules are factory configured for 9600 baud, 38,400 baud is recommended along with the other required changes. The GPS can be accessed directly thrugh the [[Compiling#USB_flashing|UART Tunnel]] and [[GPS#GPS_configuration_using_U-Center|Configured with u-center]]

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

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

=== Sensors ===

=== Control loops ===

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

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

Airframe Configuration

2010-08-12T14:06:38Z

Agaeb: /* Simu */

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

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

Note that the airframe XML document always begins with a <!DOCTYPE airframe SYSTEM "airframe.dtd"> line--[[User:Openuas|OpenUAS]] 14:32, 22 March 2010 (CET).

== XML Parameters ==

=== Commands ===

The <b><tt>commands</tt></b> lists the abstract commands you need to control the aircraft. In our example, we have only three:
<tt>
<commands>
<axis name="THROTTLE" failsafe_value="0"/>
<axis name="ROLL" failsafe_value="0"/>
<axis name="PITCH" failsafe_value="0"/>
</commands></tt>

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

=== Servos ===

The above commands get translated to the <b><tt>servos</tt></b> here. In the example below we use two elevons and a motor. ([http://en.wikipedia.org/wiki/Elevon ''Elevons''] are surfaces used for both pitch and roll as on a flying wing.) These servos are listed in the <b><tt>servos</tt></b> section:
<tt>
<servos>
<servo name="THROTTLE" no="0" min="1000" neutral="1000" max="2000"/>
<servo name="ELEVON_LEFTSIDE" no="1" min="2000" neutral="1500" max="1000"/>
<servo name="ELEVON_RIGHTSIDE" no="2" min="1000" neutral="1500" max="2000"/>
</servos></tt>

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

Note the following important tips:
* Reverse the servo direction by exchanging min/max
* Trim should always be adjusted mechanically if possible to avoid asymmetrical travel
* Any reduction of the total travel range should be done mechanically to maintain precision
* Many servos will respond well to values slightly outside the normal 1000-2000ms range but experiment carefully as the servo may not operate reliably outside this range and may even suffer permanent damage.
* Board connector numbering starts with zero(0) not with one

The <b><tt>servos</tt></b> are then linked to the commands in the <b><tt>command_laws</tt></b> section:
<tt>
<command_laws>
<let var="aileron" value="@ROLL * 0.3"/>
<let var="elevator" value="@PITCH * 0.7"/>
<set servo="THROTTLE" value="@THROTTLE"/>
<set servo="ELEVON_LEFTSIDE" value="$elevator + $aileron"/>
<set servo="ELEVON_RIGHTSIDE" value="$elevator - $aileron"/>
</command_laws></tt>

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

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

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

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

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

=== RC commands in Auto ===
To control servos or other servo signal compatible devices by RC in Auto1 or Auto2, define them in the <auto_rc_commands> section.
If you have an airframe with a dedicated rudder (YAW channel) then it is still controllable in auto mode via RC. This is the default behavior and is equivalent to setting the YAW command in auto_rc_commands:

<auto_rc_commands>
<set command="YAW" value="@YAW"/>
</auto_rc_commands>

To disable this behavior (meaning no RC control of the rudder in auto) define an empty auto_rc_commands section:

<auto_rc_commands>
</auto_rc_commands>

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

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

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

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

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

==== ADC Generic ====

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

=== Bat ===
This section give characteristics for the monitoring of the main power battery. <b><tt>MILLIAMP_AT_FULL_THROTTLE</tt></b> represents the actual current (in mA) when full THROTTLE is applied. It is used to compute the <tt>energy</tt> value of the <tt>BAT</tt> message when no [[Current_sensor|Current sensor]] is mounted in the airframe. This value can also be used in flight plans. For example, if at full throttle your motor consumes 10 Amps, use a value of 10000. At 50% throttle it is likely to use about 5 Amps so the autopilot can have a better idea how much energy is remaining. You can "tweak" this number after a few flights to match the capacity of your battery. If upon landing your bat.energy messages says that you used 2500 mAh while the battery has only 2000 mAh capacity, you could reduce the MILLIAMP_AT_FULL_THROTTLE value by 20% to match your in-flight current consumption.

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

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

<tt>
<section name="BAT">
<define name="MILLIAMP_AT_FULL_THROTTLE" value="12000" unit="mA" />
<define name="VOLTAGE_ADC_A" value="0.0177531"/>
<define name="VOLTAGE_ADC_B" value="0.173626"/>
<define name="VoltageOfAdc(adc)" value ="(VOLTAGE_ADC_A * adc + VOLTAGE_ADC_B)"/>
<define name="CATASTROPHIC_BAT_LEVEL" value="6.0" unit="V"/>
<define name="CRITIC_BAT_LEVEL" value="6.5" unit="V"/>
<define name="LOW_BAT_LEVEL" value="7.0" unit="V"/>
<define name="MAX_BAT_LEVEL" value="8.4" unit="V"/>
</section>
</tt>

Find more in depth information on how to [[Current_sensor|get a separate current sensor working by clicking here]]

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

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

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

===Vertical Control===

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

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

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

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

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

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

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

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

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

=== Simu ===
Values from this section can be used to tweak the SITL simulation.

<tt>
<section name="SIMU">
<define name="WEIGHT" value ="1."/>
<define name="YAW_RESPONSE_FACTOR" value ="1."/>
<define name="ROLL_RESPONSE_FACTOR" value ="15."/>
</section>
</tt>

* "YAW_RESPONSE_FACTOR" adapts the aircraft's turn rate corresponding to a bank angle; a larger value increases the turn radius
* "ROLL_RESPONSE_FACTOR" is basically your aileron efficiency; a higher value increases roll agility

If you want to use JSBSim as SITL simulator, you have to make some definitions in this section as well; see [[Simulation#JSBSim|here]].

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

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

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

== Hardware definitions - Makefile ==

The airframe file must include the description of the controller board and it's low-level settings. This is done in one <b><tt>makefile</tt></b> section starting with the autopilot model and flashing mode:
{{Box Code|conf/airframes/myplane.xml|
<makefile>
include $(PAPARAZZI_SRC)/conf/autopilot/tiny.makefile
<nowiki>FLASH_MODE=IAP</nowiki>
<nowiki>ap.CFLAGS += -DFBW -DAP -DBOARD_CONFIG=\"tiny.h\" -DLED -DTIME_LED=1"</nowiki>
.
.
.
</makefile>
}}
Please note that -DCONFIG was changed to -DBOARD_CONFIG on 18 July 2009.

Below this are the definintions and configuration of the peripherals and interfaces.

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

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

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

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

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

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

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

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

<br style="clear:both>

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

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

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

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

<br style="clear:both>

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

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

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

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

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

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

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

{{Box Code|conf/airframes/myplane.xml|
<nowiki>ap.CFLAGS += -DGPS -DUBX -DUSE_UART1 -DGPS_LINK=Uart1 -DUART1_BAUD=B38400</nowiki>
<nowiki>ap.srcs += gps_ubx.c gps.c</nowiki>
}}
'''Note:'''
* Tiny 13 v1.1 uses UART1 while Tiny 2 uses UART0 for GPS
* u-blox GPS modules are factory configured for 9600 baud, 38,400 baud is recommended along with the other required changes. The GPS can be accessed directly thrugh the [[Compiling#USB_flashing|UART Tunnel]] and [[GPS#GPS_configuration_using_U-Center|Configured with u-center]]

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

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

=== Sensors ===

=== Control loops ===

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

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

Airframe Configuration

2010-08-12T14:03:17Z

Agaeb: /* Misc */

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

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

Note that the airframe XML document always begins with a <!DOCTYPE airframe SYSTEM "airframe.dtd"> line--[[User:Openuas|OpenUAS]] 14:32, 22 March 2010 (CET).

== XML Parameters ==

=== Commands ===

The <b><tt>commands</tt></b> lists the abstract commands you need to control the aircraft. In our example, we have only three:
<tt>
<commands>
<axis name="THROTTLE" failsafe_value="0"/>
<axis name="ROLL" failsafe_value="0"/>
<axis name="PITCH" failsafe_value="0"/>
</commands></tt>

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

=== Servos ===

The above commands get translated to the <b><tt>servos</tt></b> here. In the example below we use two elevons and a motor. ([http://en.wikipedia.org/wiki/Elevon ''Elevons''] are surfaces used for both pitch and roll as on a flying wing.) These servos are listed in the <b><tt>servos</tt></b> section:
<tt>
<servos>
<servo name="THROTTLE" no="0" min="1000" neutral="1000" max="2000"/>
<servo name="ELEVON_LEFTSIDE" no="1" min="2000" neutral="1500" max="1000"/>
<servo name="ELEVON_RIGHTSIDE" no="2" min="1000" neutral="1500" max="2000"/>
</servos></tt>

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

Note the following important tips:
* Reverse the servo direction by exchanging min/max
* Trim should always be adjusted mechanically if possible to avoid asymmetrical travel
* Any reduction of the total travel range should be done mechanically to maintain precision
* Many servos will respond well to values slightly outside the normal 1000-2000ms range but experiment carefully as the servo may not operate reliably outside this range and may even suffer permanent damage.
* Board connector numbering starts with zero(0) not with one

The <b><tt>servos</tt></b> are then linked to the commands in the <b><tt>command_laws</tt></b> section:
<tt>
<command_laws>
<let var="aileron" value="@ROLL * 0.3"/>
<let var="elevator" value="@PITCH * 0.7"/>
<set servo="THROTTLE" value="@THROTTLE"/>
<set servo="ELEVON_LEFTSIDE" value="$elevator + $aileron"/>
<set servo="ELEVON_RIGHTSIDE" value="$elevator - $aileron"/>
</command_laws></tt>

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

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

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

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

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

=== RC commands in Auto ===
To control servos or other servo signal compatible devices by RC in Auto1 or Auto2, define them in the <auto_rc_commands> section.
If you have an airframe with a dedicated rudder (YAW channel) then it is still controllable in auto mode via RC. This is the default behavior and is equivalent to setting the YAW command in auto_rc_commands:

<auto_rc_commands>
<set command="YAW" value="@YAW"/>
</auto_rc_commands>

To disable this behavior (meaning no RC control of the rudder in auto) define an empty auto_rc_commands section:

<auto_rc_commands>
</auto_rc_commands>

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

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

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

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

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

==== ADC Generic ====

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

=== Bat ===
This section give characteristics for the monitoring of the main power battery. <b><tt>MILLIAMP_AT_FULL_THROTTLE</tt></b> represents the actual current (in mA) when full THROTTLE is applied. It is used to compute the <tt>energy</tt> value of the <tt>BAT</tt> message when no [[Current_sensor|Current sensor]] is mounted in the airframe. This value can also be used in flight plans. For example, if at full throttle your motor consumes 10 Amps, use a value of 10000. At 50% throttle it is likely to use about 5 Amps so the autopilot can have a better idea how much energy is remaining. You can "tweak" this number after a few flights to match the capacity of your battery. If upon landing your bat.energy messages says that you used 2500 mAh while the battery has only 2000 mAh capacity, you could reduce the MILLIAMP_AT_FULL_THROTTLE value by 20% to match your in-flight current consumption.

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

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

<tt>
<section name="BAT">
<define name="MILLIAMP_AT_FULL_THROTTLE" value="12000" unit="mA" />
<define name="VOLTAGE_ADC_A" value="0.0177531"/>
<define name="VOLTAGE_ADC_B" value="0.173626"/>
<define name="VoltageOfAdc(adc)" value ="(VOLTAGE_ADC_A * adc + VOLTAGE_ADC_B)"/>
<define name="CATASTROPHIC_BAT_LEVEL" value="6.0" unit="V"/>
<define name="CRITIC_BAT_LEVEL" value="6.5" unit="V"/>
<define name="LOW_BAT_LEVEL" value="7.0" unit="V"/>
<define name="MAX_BAT_LEVEL" value="8.4" unit="V"/>
</section>
</tt>

Find more in depth information on how to [[Current_sensor|get a separate current sensor working by clicking here]]

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

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

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

===Vertical Control===

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

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

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

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

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

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

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

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

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

=== Simu ===
Values from this section can be used to tweak the SITL simulation.

<tt>
<section name="SIMU">
<define name="WEIGHT" value ="1."/>
<define name="YAW_RESPONSE_FACTOR" value ="1."/>
<define name="ROLL_RESPONSE_FACTOR" value ="15."/>
<define name="JSBSIM_MODEL" value ="&quot;Malolo1&quot;"/>
<define name="JSBSIM_IR_ROLL_NEUTRAL" value ="RadOfDeg(0.)"/>
<define name="JSBSIM_IR_PITCH_NEUTRAL" value ="RadOfDeg(0.)"/>
</section>
</tt>

* "YAW_RESPONSE_FACTOR" adapts the aircraft's turn rate corresponding to a bank angle; a larger value increases the turn radius
* "ROLL_RESPONSE_FACTOR" is basically your aileron efficiency; a higher value increases roll agility

If you want to use JSBSim as SITL simulator, see [[Simulation#JSBSim|here]].

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

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

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

== Hardware definitions - Makefile ==

The airframe file must include the description of the controller board and it's low-level settings. This is done in one <b><tt>makefile</tt></b> section starting with the autopilot model and flashing mode:
{{Box Code|conf/airframes/myplane.xml|
<makefile>
include $(PAPARAZZI_SRC)/conf/autopilot/tiny.makefile
<nowiki>FLASH_MODE=IAP</nowiki>
<nowiki>ap.CFLAGS += -DFBW -DAP -DBOARD_CONFIG=\"tiny.h\" -DLED -DTIME_LED=1"</nowiki>
.
.
.
</makefile>
}}
Please note that -DCONFIG was changed to -DBOARD_CONFIG on 18 July 2009.

Below this are the definintions and configuration of the peripherals and interfaces.

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

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

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

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

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

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

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

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

<br style="clear:both>

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

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

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

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

<br style="clear:both>

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

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

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

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

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

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

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

{{Box Code|conf/airframes/myplane.xml|
<nowiki>ap.CFLAGS += -DGPS -DUBX -DUSE_UART1 -DGPS_LINK=Uart1 -DUART1_BAUD=B38400</nowiki>
<nowiki>ap.srcs += gps_ubx.c gps.c</nowiki>
}}
'''Note:'''
* Tiny 13 v1.1 uses UART1 while Tiny 2 uses UART0 for GPS
* u-blox GPS modules are factory configured for 9600 baud, 38,400 baud is recommended along with the other required changes. The GPS can be accessed directly thrugh the [[Compiling#USB_flashing|UART Tunnel]] and [[GPS#GPS_configuration_using_U-Center|Configured with u-center]]

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

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

=== Sensors ===

=== Control loops ===

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

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

Logs

2009-09-04T13:49:53Z

Agaeb: Description of Matlab logviewer GUI

On each launch, the <tt>server</tt> creates a ''log'' of all the messages sent by the aircraft. This log can be used to analyse flight data and to replay the flight.

==Format==

The log files are stored in the <tt>var/logs/</tt> folder (under <tt>PAPARAZZI_HOME</tt>). A log is split into two files:
* A <tt>.log</tt> file, an XML file, which contains a copy of the whole configuration (airframes, flight plans, ...).
* A <tt>.data</tt> file, an ascii file, which contains the list of the received messages. Each message is time-stamped in seconds since the creation of the file and marked with the id of the sending aircraft.

The basename of these two files is the same and is build from the date and time at the creation.

The lines of the <tt>.data</tt> file are formatted according to the message description listed in the <tt>conf/messages.xml</tt> file. For example, the following line:
3.300 6 GPS 3 36028551 481359212 899 18500 0 -8 960 31 0
contains a <tt>GPS</tt> message received at time 3.3s, from aircraft 6. According the GPS message description:
<message name="GPS" ID="8">
<field name="mode" type="uint8" unit="byte_mask"></field>
<field name="utm_east" type="int32" unit="cm"></field>
<field name="utm_north" type="int32" unit="cm"></field>
<field name="course" type="int16" unit="decideg"></field>
<field name="alt" type="int32" unit="cm"></field>
...
</message>
UTM position is 360285.51m east, 4813592.12m north, course is 89.9° (east), altitude is 185m, ...
Note that the appropriate <tt>messages.xml</tt> description, i.e. the one which has been used while the log was created, is itself stored in the associated <tt>.log</tt> file. It may differ from the current one installed in your <tt>conf/</tt> folder.

Note: The <tt>.data</tt> files may be huge (about 4M per hour with a standard telemetry configuration). They can be efficiently compressed. The tools described in the next sections handle most of the compressed format (.zip, .gz, .bz2, ...). The bzip2 compression seems to perform better than others on these files.

==Data Plotting==

Data stored in log files can be plotted with the [[Plotter]] (<tt>sw/logalizer/plot</tt> or launchable from the [[Paparazzi Center]]). This tool can plot data from different logs in the same window and data from the same log in different windows. It also offers to export the track as a KML file for [http://earth.google.com Google Earth].

==Replay==
A flight can be replayed with the Log Flight Player (<tt>sw/logalizer/play</tt>, launchable from the [[Paparazzi Center]]). This agent then is a substitute for the Data Link agent and will send over the bus the messages which had been send by the aircraft while the log was recorded.

Note: While replaying a log, it is a good idea to disable a new log creation from the server (<tt>-n</tt> option).

When doing a log replay it is very valuable to launch the messages window (in the tools menu) as well. This allows for the use of the the real time plotter and also gives the data from the aircraft to the user.

If the user wishes to speed up a replay gaia can be used (launch from paparazzi centers tools menu) to do this by changing the time scale.

A <tt>.log</tt> file given in the command line will be loaded on startup.

===Output on a serial port===
Launched with the <tt>-o</tt> option, the player will send to a serial port all the binary messages, as they have been received through the modem during the flight. Related options:
* <tt>-s</tt> Set the baudrate (<tt>9600</tt>)
* <tt>-d</tt> Set the device (<tt>/dev/ttyUSB0</tt>)

==Load PprzLog into Matlab Workspace==
Paparazzi log file could also be converted into matrices in matlab workspace for further data processing. An example matlab script is shown in [http://paparazzi.enac.fr/wiki/Image:PprzLog2Matlab_1_0.zip PprzLog2Matlab_1_0.zip]. The example script needs the inputs of the log file name and directory. Just modify the line "fid = fopen('.\FlighLog20090321_MZN\09_03_19__15_03_14.data','r');". Eight matrices are read into matlab workspace including GPS_SOL, GPS, PPRZ_MODE, DESIRED, ATTITUDE, NAVIGATION, NAVIGATION_REF, COMMANDS. The user could also modify the code easily to add more messages they want to know.

[[Image:logviewer.png|thumb|right|The logviewer GUI]]
There is now another parser named <tt>log2struct</tt> available, see [http://lists.gnu.org/archive/html/paparazzi-devel/2009-08/msg00135.html this post on the mailing list].
It does not require code modification and can read any messages sent from any aircraft.
Usage examples can be found in the source code documentation.

A GUI built on this parser is available: [http://paparazzi.enac.fr/wiki_images/Logviewer.zip Logviewer.zip].
It is based on the GUI from <tt>sw/logalizer/matlab_log</tt> but features some improvements, e.g. in speed and reliability.
Standard plots like trajectory, attitude or speed are available for quick reviewing and Matlab's plotting tools can be accessed for plot cosmetics and printing.

File:Logviewer.png

2009-09-04T13:42:57Z

Agaeb: Screenshot of the Matlab logviewer figure.

Screenshot of the Matlab logviewer figure.

File:Logviewer.zip

2009-09-04T13:32:19Z

Agaeb: logviewer - a Matlab GUI for reviewing Paparazzi log files

logviewer - a Matlab GUI for reviewing Paparazzi log files

Logs

2009-08-29T10:15:10Z

Agaeb: Added link to the log2struct Matlab parser

On each launch, the <tt>server</tt> creates a ''log'' of all the messages sent by the aircraft. This log can be used to analyse flight data and to replay the flight.

==Format==

The log files are stored in the <tt>var/logs/</tt> folder (under <tt>PAPARAZZI_HOME</tt>). A log is split into two files:
* A <tt>.log</tt> file, an XML file, which contains a copy of the whole configuration (airframes, flight plans, ...).
* A <tt>.data</tt> file, an ascii file, which contains the list of the received messages. Each message is time-stamped in seconds since the creation of the file and marked with the id of the sending aircraft.

The basename of these two files is the same and is build from the date and time at the creation.

The lines of the <tt>.data</tt> file are formatted according to the message description listed in the <tt>conf/messages.xml</tt> file. For example, the following line:
3.300 6 GPS 3 36028551 481359212 899 18500 0 -8 960 31 0
contains a <tt>GPS</tt> message received at time 3.3s, from aircraft 6. According the GPS message description:
<message name="GPS" ID="8">
<field name="mode" type="uint8" unit="byte_mask"></field>
<field name="utm_east" type="int32" unit="cm"></field>
<field name="utm_north" type="int32" unit="cm"></field>
<field name="course" type="int16" unit="decideg"></field>
<field name="alt" type="int32" unit="cm"></field>
...
</message>
UTM position is 360285.51m east, 4813592.12m north, course is 89.9° (east), altitude is 185m, ...
Note that the appropriate <tt>messages.xml</tt> description, i.e. the one which has been used while the log was created, is itself stored in the associated <tt>.log</tt> file. It may differ from the current one installed in your <tt>conf/</tt> folder.

Note: The <tt>.data</tt> files may be huge (about 4M per hour with a standard telemetry configuration). They can be efficiently compressed. The tools described in the next sections handle most of the compressed format (.zip, .gz, .bz2, ...). The bzip2 compression seems to perform better than others on these files.

==Data Plotting==

Data stored in log files can be plotted with the [[Plotter]] (<tt>sw/logalizer/plot</tt> or launchable from the [[Paparazzi Center]]). This tool can plot data from different logs in the same window and data from the same log in different windows. It also offers to export the track as a KML file for [http://earth.google.com Google Earth].

==Replay==
A flight can be replayed with the Log Flight Player (<tt>sw/logalizer/play</tt>, launchable from the [[Paparazzi Center]]). This agent then is a substitute for the Data Link agent and will send over the bus the messages which had been send by the aircraft while the log was recorded.

Note: While replaying a log, it is a good idea to disable a new log creation from the server (<tt>-n</tt> option).

When doing a log replay it is very valuable to launch the messages window (in the tools menu) as well. This allows for the use of the the real time plotter and also gives the data from the aircraft to the user.

If the user wishes to speed up a replay gaia can be used (launch from paparazzi centers tools menu) to do this by changing the time scale.

A <tt>.log</tt> file given in the command line will be loaded on startup.

===Output on a serial port===
Launched with the <tt>-o</tt> option, the player will send to a serial port all the binary messages, as they have been received through the modem during the flight. Related options:
* <tt>-s</tt> Set the baudrate (<tt>9600</tt>)
* <tt>-d</tt> Set the device (<tt>/dev/ttyUSB0</tt>)

==Load PprzLog into Matlab Workspace==
Paparazzi log file could also be converted into matrices in matlab workspace for further data processing. An example matlab script is shown in [http://paparazzi.enac.fr/wiki/Image:PprzLog2Matlab_1_0.zip PprzLog2Matlab_1_0.zip]. The example script needs the inputs of the log file name and directory. Just modify the line "fid = fopen('.\FlighLog20090321_MZN\09_03_19__15_03_14.data','r');". Eight matrices are read into matlab workspace including GPS_SOL, GPS, PPRZ_MODE, DESIRED, ATTITUDE, NAVIGATION, NAVIGATION_REF, COMMANDS. The user could also modify the code easily to add more messages they want to know.

There is now another parser named <tt>log2struct</tt> available, see [http://lists.gnu.org/archive/html/paparazzi-devel/2009-08/msg00135.html this post on the mailing list].
It does not require code modification and can read any messages sent from any aircraft.
Usage examples can be found in the source code documentation.