PaparazziUAV - User contributions [en]

Tunnel

2017-11-22T18:46:25Z

IHaveADrone: XML coloring

{| align=right
|-
|<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Firmware</categorytree>
|}

The Tunnel is serial-to-serial pass-through. It connects an autopilot serial port, e.g. from the GPS, directly to the modem serial port or a USB-to-serial connection. This I/O in turn can go to your development PC for example. There are other uses no doubt, but this in the most common use.

The Tunnel completely replaces the normal autopilot code, leaving the USB bootloader intact). Use this for example to gain direct access to the GPS for debugging or testing. Also for configuration with [[GPS#GPS_configuration_using_U-Center|U-Center]] it will be quite useful.

You can either use a serial UART tunnel or USB tunnel:

You have to add the tunnel targets to your airframe file. The tunnel targets must be part of a firmware section of <code>name="setup"</code>. If it doesn't already exist in your airframe file, just add it.

An example on a Lisa M autopilot board

<source lang="xml">
<firmware name="setup">
<target name="tunnel" board="lisa_m_2.0" />
<target name="usb_tunnel_0" board="lisa_m_2.0" />
</firmware>
</source>

Note, that you must replace the value of <code>board</code> with your board name.

At the current state of the code only '''UART1''' goes to '''UART2''' and Vice versa and is sadly not configurable. Due to the opensource nature of PPRZ this can be made so ofcourse, you are welcomed to enhance the arch/uart_tunnel.c to add more and better functionality flexible tunnel port configuration.

Note that UART1 TX has no simple Physical connection on a Lisa/M

== UART tunnel ==

Use this if you have a serial cable to connect. The LEDs will blink when data is transferred. Type the following command from your paparazzi folder, substituting the name of your airframe and paying attention to case sensitivity:
make AIRCRAFT=''myplane'' tunnel.upload
Connect the USB cable and power on the autopilot to receive the code.

This can be done without the USB bootloader by appending ''FLASH_MODE=ISP'' to the command line (specifying ISP serial loading). This will require a serial cable connection (i.e. FTDI USB-to-TTL). '''WARNING!''' Installing tunnel code with the ISP method will erase any USB bootloader code. Make sure you are able to install a bootloader yourself.

== USB tunnel ==

This can be done without a serial cable just by having USB. The LEDs will blink when data is transferred. It can connect to either serial port on the autopilot (for Tiny 2.11: uart0=gps, uart1=modem). To connect USB to the gps type the following command from your paparazzi folder, substituting the name of your airframe and paying attention to case sensitivity:
make AIRCRAFT=''myplane'' usb_tunnel_0.upload
Connect the usb cable and power on the autopilot to receive the code. The code will switch the USB to emulate a serial port that you can access at '''/dev/ttyACMx'''. Windows user can extract the usbser.sys file from .cab file in C:\WINDOWS\Driver Cache\i386 and store it somewhere (C:\temp is a good place) along with the [[Media:Usbser.zip|usbser.inf]] file. Windows then creates an extra COMx port that you can use in a terminal program or with ucenter.
To use the USB tunnel make sure you first power the autopilot before connecting USB not to end up in the USB bootloader.

Required Cables:
<ol>
<li>USB cable
<li>USB to 8-pin Molex Picoblade Male-connector cable (optional, can use wireless link)
</ol>
Steps:
<ol>
<li>Connect USB Cable + 8-pin Molex adapter to USB on your laptop
<li>Connect 8-pin Molex Connector on the Adapter cable to "usb" on Tiny2.11
<li>Power on Tiny2.11
<li>Enter this command in a terminal: make AIRCRAFT=Twinjet tunnel.upload
</ol>
<p>Success will show this in the last lines of the terminal window</p>
<pre>
Found USB device
BootROM code: 2.12
Part ID: 0x0402FF25 (LPC2148, 512k Flash, 32k+8k RAM)
BootLoader version: 1.3
#
Starting software at 0x00004000
</pre>
<p>Now your Tiny2.11 will tunnel UART1 from the GPS direct to the serial connector on the board. So, using the 8-pin Molex to FTDI cable adapter (or use the wireless link e.g. XBee) you can use your computer to interact with the GPS module. One example is using u-blox u-center program to configure your GPS module. Like the bootloader if you bought your Tiny2.11 assembled check with your 3rd party vendors configured your GPS. Good chance you won't need to use the tunnel or configure the GPS module.</p> The required cable may included with 3rd party vendors!

[[Category:Firmware]] [[Category:User_Documentation]]

AspirinIMU

2017-07-11T15:58:41Z

IHaveADrone: /* Downloads */ fixed github link

<div style="float: right; width: 45%; overflow: hidden">[[Image:Aspirin_2.1_imu_front.jpg|right|200px|Aspirin V2.1 top view]]</div>
__TOC__

== Aspirin IMU ==

The next generation flat multi degree of freedom inertial measurement unit. It uses digital 3-axis sensors which allow for a very small size and price. Other features include onboard voltage regulators, EEPROM for storing calibration data and extra sensors such as a barometer.

== Hardware Revision History ==

{|border="1" cellspacing="0" style="text-align:center" cellpadding="6"
!''Version #''!!''Release Date''!!''Release Notes''
|-
|v2.2(current)||09/2012||2nd Gen Revision
|-
|v2.1r1||08/2012||2nd Gen Minor Revision
|-
|v2.1||03/2012||2nd Gen Production Release
|-
|v2.0||11/2011||2nd Gen Prototype
|-
|v1.5||04/2011||Updated Production Release
|-
|v1.4||03/2011||Prototype Update
|-
|v1.3||08/2010||Initial Production Release
|-
|v1.2||07/2010||Prototype Update
|-
|v1.1||07/2010||Prototype Update
|-
|v1.0||07/2010||Initial Prototype
|}

== Features ==

* 3-axis accelerometer
* 3-axis gyroscope
* 3-axis magnetometer
* Onboard voltage regulation
* Onboard I2C EEPROM
* Onboard barometer (''v2.1'')
* Standard footprint across versions
* Single PCB flat form-factor
* Fits directly onto [[Lisa/M]], carriers for [[Booz]] and [[Lisa/L]], or for [[Autopilots|LPC21xx]] integration

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''Aspirin Feature Matrix'''
!width="6%"|''Version''!!width="10%"|''Accelerometer''!!width="10%"|''Gyroscope''!!width="10%"|''Magnetometer''!!width="10%"|''Barometer''!!width="15%"|''Regulators''!!width="10%"|''EEPROM''!!''Comments''
|-
|v2.2||MPU-6000||MPU-6000||HMC5883||MS5611||1x 3.3V (LP2992)||yes||MS5611 is connected directly to the SPI bus
|-
|v2.1||MPU-6000||MPU-6000||HMC5883||MS5611||1x 3.3V (LP2992)||yes||MS5611 is connected to the aux I2C of the MPU6000
|-
|v2.0||MPU-6000||MPU-6000||HMC5883||none||1x 3.3V (LP2992)||yes||
|-
|v1.5||ADXL345||IMU-3000||HMC5883||none||2x 3.3V (LP2992)||yes||
|-
|v1.4||ADXL345||IMU-3000||HMC5883||none||2x 3.3V (LP2992)||yes||
|-
|v1.3||ADXL345||ITG-3200||HMC5843||none||2x 3.3V (LP2992)||yes||
|-
|v1.2||ADXL345||ITG-3200||HMC5843||none||2x 3.3V (LP2992)||yes||
|-
|v1.1||ADXL345||ITG-3200||HMC5843||none||2x 3.3V (LP2992)||yes||
|-
|v1.0||ADXL345||ITG-3200||HMC5843||none||2x 3.3V (LP2992)||yes||Also has SC18IS600 SPI-I2C interface
|}

'''Note:''' Aspirin 2.1 comes in several population versions. The current version available at http://transition-robotics.com has the MPU-6000, HMC5843, and MS5611-01BA03 mounted. You can find the list of fitted sensors on Aspirin 2.1 in the eeprom block 4.

<gallery widths=170px heights=120px>
Image:Aspirin imu front.jpg|Aspirin V1.3 IMU front

Image:Aspirin imu back.jpg|Aspirin V1.3 IMU back
Image:Aspirin imu on carrier.JPG|Aspirin V1.3 IMU on [[Lisa/L]] compatible carrier board
Image:LisaL_Aspirin_Flat_Carrier.jpg|Aspirin flat carrier board for [[Lisa/L]] (without IMU mounted)
</gallery>

<gallery widths=220px heights=150px>
Image:Aspirin_2.1_bottom.jpg|Aspirin IMU 2.1 bottom side
Image:Aspirin_2.1_top.jpg|Aspirin IMU 2.1 top side
Image:Aspirin_2.1_nobaro_top.jpg|Aspirin IMU 2.1 top side no barometer mounted
Image:Aspirin_2.1_nomag_nobaro_top.jpg|Aspirin IMU 2.1 top side no barometer and no magnetometer mounted
</gallery>

== Pinout ==

Note that Aspirin uses a standard footprint and pinout across all versions, with certain exceptions. The chip select (CS) and interrupt (Int) pins are not always assigned to the same devices. A good example is with the introduction of the MPU-6000 device. Check the schematics for details.

'''Warning:''' When mounting Aspirin on Lisa/M note that the pin labeled GND on Aspirin (in the right upper corner on the following picture) is connected on Lisa/M to GYRO_SS. To prevent a software error induced shorting of the Lisa/M GYRO_SS pin to ground, remove the castellation or remove the connection on that pad.

In the v2.1r1 versions of Aspirin ("R1" silkscreened onto PCB) the right upper GND pad was changed to Not Connected, (marked RESV in the below image), resolving the issue.

[[Image:Aspirin IMU documented.jpg|300px|Aspirin IMU with documented IO connections.]]
[[Image:Aspirin_booz_carrier_legend.jpg|300px|Aspirin IMU on booz/breakout carrier with documented IO connections.]]
[[Image:Aspirin_flat_carrier_legend.jpg|300px|Aspirin IMU on flat carrier with documented IO connections.]]

Note that the 12-pin connector pinout of the Booz/breakout carrier (center) is reversed with respect to the Lisa/L flat carrier (right). This is because the Booz carrier mounts to Lisa/L with the Aspirin underneath the carrier (e.g., Z axis pointing toward Lisa/L), and the flat carrier mounts to Lisa/L with the Aspirin on top (e.g., Z axis pointing away from Lisa/L).

=== Breakout board ===

In case you have some Aspirin lying around and you want to use the on a non Lisa Board, like the TWOG, here pictures of how to patch the breakoutboard. Then connect to TWOG and add the correct defines to your airframe configuration document.

<gallery>
Image:Aspirin_v1.5_via_AsCa_v1.0_to_TWOG_03.jpg |Aspirin v1.5 via AsCa v1.0 to TWOG
Image:Aspirin_v1.5_via_confboard_to_TWOG_01.jpg |Aspirin v1.5 via confboard to TWOG
Image:Aspirin_v1.5_via_confboard_to_TWOG_02.jpg |Aspirin v1.5 via confboard to TWOG bottom
Image:Aspirin_v1.5_via_Patching_the_Breakout_Board.jpg |Aspirin v1.5 via Patching the Breakout Board
Image:Aspirin_v1.5_Connector_To_TWOG_Board.jpg |Aspirin v1.5 Connector To TWOG Board
</gallery>

== Block Diagrams ==

<gallery widths=300px heights=300px>
Image:Aspirin-1_x-stm32-block_diagram.png|Aspirin 1.x to STM32 protocol connections
Image:Aspirin-2_x-stm32-slave_i2c-block_diagram.png|Aspirin 2.x to STM32 default protocol connections (MPU-6000 slave I2C)
Image:Aspirin-2_x-stm32-direct_i2c-block_diagram.png|Aspirin 2.x to STM32 alternative protocol connections (STM32 direct I2C)
</gallery>

== Schematics ==

Schematics are available under {{CC-BY-SA-3.0}} license. For additional intermediate schematics see [[AspirinIMU#Downloads|Downloads]].

<gallery widths=200px heights=137px>
Image:Aspirin_imu_schematic_V1_3.png|Aspirin IMU V1.3 schematic
Image:Aspirin_imu_schematic_V1_5.png|Aspirin IMU V1.5 schematic
Image:Aspirin_imu_schematic_V2_1.png|Aspirin IMU V2.1 schematic
Image:Aspirin_imu_schematic_V2_2.png|Aspirin IMU V2.2 schematic
</gallery>

== Drivers and Support ==

Please see the [[Subsystem/imu|IMU subsystem]] page for details on configuring Paparazzi for using an Aspirin IMU.

The drivers for this IMU are available in the [https://github.com/paparazzi/paparazzi/blob/master/sw/airborne/subsystems/imu/imu_aspirin.c Paparazzi GitHub repository].

== PCB and assembled boards suppliers ==

Aspirin IMU is available in the [http://thequadshot.com/collections/all Transition Robotics/Quadshot Online Shop].

There are three options of Aspirin IMU:
* [http://thequadshot.com/products/aspirin-imu Without a carrier board]
* [http://thequadshot.com/products/aspirin-imu With Booz carrier board]
* [http://thequadshot.com/products/aspirin-imu With next generation flat carrier board]
** [http://thequadshot.com/products/lisa-l-aspirin-flat-carrier The flat carrier board can be purchased separately as well]

== Mechanical Dimensions ==

[[Image:Aspirin_top_mechanical.png|500px|Aspirin Footprint Mechanical Dimensions]]

The overall height of the board is about 3mm.

== Downloads ==

'''Source files'''
:*download available on GitHub: ''[https://github.com/paparazzi/paparazzi-hardware/tree/master/sensors/imu/aspirin Aspirin IMU and Carrier Board Cadsoft Eagle 6 Design]''
'''Gerber & Drill files'''
:*download ''NOT YET AVAILABLE'' Need generated gerbers and drill files
'''Assembly files'''
:*download ''NOT YET AVAILABLE'' Need Aspirin Components layouts (pdf)
:*download ''NOT YET AVAILABLE'' Need Aspirin Bill Of Material

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

Rotorcraft Configuration

2017-04-26T18:36:14Z

IHaveADrone: /* Motor Mixing */ XML "

<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Airframe_Configuration</categorytree>
This page describes configuration options <span style="color:red"><b>specific to the rotorcraft firmware</b></span> in the [[Airframe_Configuration|airframe file]].

== Firmware and Hardware definitions ==

This is one example of a pretty standard quadcopter firmware definition:
{{Box Code|conf/airframes/myrotorcraft.xml|
<source lang="xml">
<firmware name="rotorcraft">
<target name="nps" board="pc">
<subsystem name="fdm" type="jsbsim"/>
</target>
<target name="ap" board="lisa_m_1.0"/>

<subsystem name="radio_control" type="ppm"/>
<subsystem name="telemetry" type="transparent"/>
<subsystem name="actuators" type="mkk"/>
<subsystem name="imu" type="aspirin_v1.5"/>
<subsystem name="gps" type="ublox"/>
<subsystem name="ahrs" type="int_cmpl_quat"/>
<subsystem name="stabilization" type="int_quat"/>
</firmware>
</source>
}}

=== Select your Board ===
Make sure you use the <b>rotorcraft [[Airframe_Configuration#Firmware|firmware]]</b> and choose the correct board, e.g.

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

The ap board name can be found in /conf/boards.

=== Actuators ===
You have to specify which ESCs you have by adding the appropriate [[Subsystem/actuators|actuators subsystem.]]
{{Box Code|conf/airframes/myrotorcraft.xml|
<source lang="xml">
<firmware name="rotorcraft">
<target name="ap" board="booz_1.0"/>
...
<subsystem name="actuators" type="mkk"/>
</firmware>
</source>
}}

=== Control Loops ===
See the [[Subsystem/stabilization|stabilization subsystem]] page to choose which attitude control algorithm to use and how to configure them.

The [[Control Loops]] page has some diagrams.

=== INS ===
The INS (Integrated Navigation System) subsystem contains estimations filter to e.g. fuse GPS and IMU data for better position and speed estimates.
The INS subsystem is optional in <= v4.2.

Since v4.9x the INS subsystem is mandatory, to use the same as in v4.2 omit the type.
{{Box Code|conf/airframes/myrotorcraft.xml|
<source lang="xml">
<firmware name="rotorcraft">
<target name="ap" board="booz_1.0"/>
...
<subsystem name="ins"/>
</firmware>
</source>
}}
You can also compensate for GPS lag in hff (horizontal filter float) if it is known (in seconds):
{{Box Code|conf/airframes/myrotorcraft.xml|
<source lang="xml">
<firmware name="rotorcraft">
<target name="ap" board="booz_1.0"/>
...
<subsystem name="ins" type="hff">
<define name="GPS_LAG=0.2"/>
</subsystem>
</firmware>
</source>
}}

== Motor Arming ==
By default the motors are armed with zero-throttle and full yaw. The motors are never started if AHRS is not aligned (disable it with AUTOPILOT_DISABLE_AHRS_KILL).

Other arming sequences can be configured:
* USE_KILL_SWITCH_FOR_MOTOR_ARMING defined (to 1):
** switch kill switch off to arm the motors
** if kill switch is off during startup, you need to kill again first, then unkill to start
** throttle needs to be down, other sticks centered to start motors
** need to be in manual mode to start the motors

* USE_THROTTLE_FOR_MOTOR_ARMING defined (to 1):
** automatically start motors when applying throttle
** if throttle was not down at startup, you need to put throttle down again first
** other sticks need to be centered to start motors
** need to be in manual mode to start the motors

== Autopilot modes ==
For rotorcrafts we have a lot of different modes that can be mapped to your 3-position switch (Manual, Auto1, Auto2).
The horizontal and vertical mode can be set differently as the following possible modes indicate (in parenthesis are the abbreviations displayed in the [[GCS#Strips|GCS]] strip).

'''Limiting max thrust via RC'''<br>
Modes with 'automatic' thrust control (e.g. x_Z_HOLD and NAV) let you limit the maximum thrust via RC by default. So you should push your throttle stick up after entering such a mode so the vertical controller has some "room" to stabilize the altitude. Should something weird happen you can limit the max thrust by taking throttle back.<br> You can turn this behavior off by defining '''NO_RC_THRUST_LIMIT'''

; AP_MODE_FAILSAFE (SAFE) :
This is a failsafe mode that gets triggered if:
* RC signal is lost (and you are not in KILL or NAV mode)
* GPS and RC is lost in NAV mode
The standard behaviour is that autopilot will level the rotorcraft out (setpoints to zero pitch and roll angles) and descend at 0.5m/s downwards. But this behavior can also be changed to something else ofcourse.

; AP_MODE_KILL (KILL) :
Motors are simply switched off.

; AP_MODE_RATE_DIRECT (RATE) :
This is basically the "most" manual mode you can get. You control not the attitude (roll and pitch angles) but the rotation rate. You also set the throttle directly with your RC.

; AP_MODE_ATTITUDE_DIRECT (ATT) :
You control the attitude (roll, pitch and yaw angles), but the throttle is directly proportional to your stick position.

; AP_MODE_RATE_RC_CLIMB (R_RCC) :
You control the rotation rate and the vertical speed according to your throttle stick position.<br>If you have your throttle stick in the middle position, the altitude is kept, down goes down at a speed proportional to your stick position (same for up). In this mode it makes sense to mount the spring for your throttle stick so it can recenter itself.

; AP_MODE_ATTITUDE_RC_CLIMB (A_RCC) :
You control the attitude (roll, pitch and yaw angles) and the vertical speed according to your throttle stick position.<br>If you have your throttle stick in the middle position the altitude is kept, if you move the stick down it goes down at a speed proportional to your stick position (same for up). In this mode it makes sense to mount the spring for your throttle stick so it recenter itself.

; AP_MODE_ATTITUDE_CLIMB (ATT_C) :
You control the attitude (roll, pitch and yaw angles) and the vertical speed. The vertical speed is set via fms (e.g. joystick).

; AP_MODE_RATE_Z_HOLD (R_ZH) :
You control the rotation rate and it holds the altitude you were at when entering this mode.<br>Your throttle stick position still limits the max throttle authority unless disabled with NO_RC_THRUST_LIMIT.

; AP_MODE_ATTITUDE_Z_HOLD (A_ZH) :
You control the attitude (roll, pitch and yaw angles) and it holds the altitude you were at when entering this mode.<br>Your throttle stick position still limits the max throttle authority unless disabled with NO_RC_THRUST_LIMIT.

; AP_MODE_HOVER_DIRECT (HOVER) :
The rotorcraft hovers at the horizontal position you were at when entering this mode (position control). You still set the throttle directly with your RC. Yaw command on the RC allows for heading change. If USE_SPEED_REF=1 then pitch and roll commands in the RC control speed according to max speed set with REF_MAX_SPEED in the GUIDANCE_H section of airframe file.

; AP_MODE_HOVER_CLIMB (HOV_C) :
The rotorcraft hovers at the position you were at when entering this mode (position control). RC commands work the same as in HOVER mode. The vertical speed is set via fms (e.g. joystick).

; AP_MODE_HOVER_Z_HOLD (H_ZH):
The rotorcraft hovers at the 3D position you were at when entering this mode (position and altitude control). RC commands work the same as in HOVER mode. <br>Your throttle stick position still limits the max throttle authority unless disabled with NO_RC_THRUST_LIMIT.

; AP_MODE_NAV (NAV) :
Full navigation mode. The rotorcraft follows your flightplan.<br>If you have a valid RC signal, your throttle stick position still limits the max throttle authority unless disabled with NO_RC_THRUST_LIMIT.

; AP_MODE_RC_DIRECT (RC_D) :
Safety pilot direct commands for helicopter.

; AP_MODE_CARE_FREE_DIRECT (CF):
Same as AP_MODE_ATTITUDE_DIRECT, but the roll and pitch commands are based on the yaw angle when entering this mode.

== XML Parameters ==

=== Mode ===
In the mode section you can set the autopilot modes associated with your 3-way mode switch on your RC.
{{Box Code|conf/airframes/myrotorcraft.xml|
<source lang="xml">
<section name="MODE" prefix="MODE_">
<define name="MANUAL" value="AP_MODE_ATTITUDE_DIRECT" />
<define name="AUTO1" value="AP_MODE_ATTITUDE_Z_HOLD" />
<define name="AUTO2" value="AP_MODE_NAV" />
</section>
</source>
}}

=== Commands ===

The <b><tt>commands</tt></b> lists the abstract commands you need to control the aircraft. For most multicopter you just need:
{{Box Code|conf/airframes/myrotorcraft.xml|
<source lang="xml">
<commands>
<axis name="PITCH" failsafe_value="0"/>
<axis name="ROLL" failsafe_value="0"/>
<axis name="YAW" failsafe_value="0" />
<axis name="THRUST" failsafe_value="0"/>
</commands>
</source>
}}

Each command is also associated with a failsafe value which will be used if no controller is active, for example during initialization of the autopilot board.

=== Motor Mixing ===

This section describes the "mixing" used for your particular multirotor configuration. This section is needed for all ESCs except "asctec_v1" wich do their mixing themselves.

<div class="toccolours mw-collapsible mw-collapsed" style="width:800px">
Used since '''v5.0''', for previous version see [[Rotorcraft_Configuration#Supervision|Supervision]].
<div class="mw-collapsible-content">Differences with the older supervision (used prior to '''v4.9_devel-164-gdb0d004'''):
* names: SUPERVISION -> MOTOR_MIXING
* independent of the actuators, needs to be loaded in the subsystems and call in the command_laws section
* internal values have '''pprz''' format (int16, between [-9600; 9600])
* min and max are not needed, coming from the servos definition
* trim are renamed with more explicit names
</div></div>

This subsystem takes ''roll'', ''pitch'', ''yaw'' and ''thrust'' commands as inputs and "mixes" them to get the final commands for your individual motors according to the layout of them. See [[RotorcraftMixing]] for the details behind this.

Note that after mixing the separate motor commands can "saturate", meaning you can't simply give negative thrust or more than the maximum. If a saturation is reached (desired motor command outside of possible MIN_MOTOR/MAX_MOTOR range), a saturation offset is applied to all motors in order to give attitude commands a higher priority than thrust. This offset is limited to ''MOTOR_MIXING_MAX_SATURATION_OFFSET'' (default is 10% of maximum command).

See also [https://github.com/paparazzi/paparazzi/issues/385 issue #385].

In '''firmware''' section:
{{Box Code|conf/airframes/myrotorcraft.xml|
<source lang="xml">
<firmware name="rotorcraft">
...
<subsystem name="motor_mixing"/>
...
</firmware>
</source>
}}

Configuration of the motor mixing:
{{Box Code|conf/airframes/myrotorcraft.xml|
<source lang="xml">
<section name="MIXING" prefix="MOTOR_MIXING_">
<define name="TRIM_ROLL" value="0"/>
<define name="TRIM_PITCH" value="0"/>
<define name="TRIM_YAW" value="0"/>
<define name="MAX_SATURATION_OFFSET" value="MAX_PPRZ/10"/>
<define name="NB_MOTOR" value="4"/>
<define name="SCALE" value="256"/>
<define name="ROLL_COEF" value="{ 0 , 0, 256, -256 }"/>
<define name="PITCH_COEF" value="{ 256, -256, 0, 0 }"/>
<define name="YAW_COEF" value="{ -256, -256, 256, 256 }"/>
<define name="THRUST_COEF" value="{ 256, 256, 256, 256 }"/>
</section>
</source>
}}

; ''TRIM_ROLL'' : trim added to roll command
; ''TRIM_PITCH'' : trim added to pitch command
; ''TRIM_YAW'' : trim added to yaw command
; ''MAX_SATURATION_OFFSET'' : set at "MAX_PPRZ/10" by default
; x''_COEF'' : roll/pitch/yaw/thrust coefficients, see [[RotorcraftMixing]] for details or the examples below

In '''command_laws''' section (placed after section MIXING):
{{Box Code|conf/airframes/myrotorcraft.xml|
<source lang="xml">
<command_laws>
<call fun="motor_mixing_run(autopilot_motors_on, FALSE, values)"/>
<set servo="FRONT" value="motor_mixing.commands[0]"/>
<set servo="BACK" value="motor_mixing.commands[1]"/>
<set servo="RIGHT" value="motor_mixing.commands[2]"/>
<set servo="LEFT" value="motor_mixing.commands[3]"/>
</command_laws>
</source>
}}

==== Mixing Examples ====

Hint: If your rotors are spinning '''opposite''' to the '''direction''' shown in the picture, '''reverse signs''' in the YAW_COEF line.

; Plus Cross : [[Image:cross_plus_simple.png|200px]]
Assuming that the order of motors, described in the "servos" section is FRONT, RIGHT, BACK, LEFT.
<source lang="xml">
<section name="MIXING" prefix="MOTOR_MIXING_">
<define name="NB_MOTOR" value="4"/>
<define name="SCALE" value="256"/>
<define name="ROLL_COEF" value="{ 0, -256, 0, 256 }"/>
<define name="PITCH_COEF" value="{ 256, 0, -256, 0 }"/>
<define name="YAW_COEF" value="{ -128, 128, -128, 128 }"/>
<define name="THRUST_COEF" value="{ 256, 256, 256, 256 }"/>
</section>
</source>
This is equivalent to (available since v5.5_devel-602-g0129d3e):
<source lang="xml">
<section name="MIXING" prefix="MOTOR_MIXING_">
<define name="TYPE" value="QUAD_PLUS"/>
</section>
</source>

; Time Cross : [[Image:cross_time_simple.png|200px]]
Assuming that the order of motors, described in the "servos" section is NW, NE, SE, SW.
<source lang="xml">
<section name="MIXING" prefix="MOTOR_MIXING_">
<define name="NB_MOTOR" value="4"/>
<define name="SCALE" value="256"/>
<define name="ROLL_COEF" value="{ 181, -181, -181, 181 }"/>
<define name="PITCH_COEF" value="{ 181, 181, -181, -181 }"/>
<define name="YAW_COEF" value="{ 128, -128, 128, 128 }"/>
<define name="THRUST_COEF" value="{ 256, 256, 256, 256 }"/>
</section>
</source>
This is equivalent to (available since v5.5_devel-602-g0129d3e):
<source lang="xml">
<section name="MIXING" prefix="MOTOR_MIXING_">
<define name="TYPE" value="QUAD_X_CCW"/>
</section>
</source>
This is equivalent to (available since v5.9_devel):
<source lang="xml">
<section name="MIXING" prefix="MOTOR_MIXING_">
<define name="TYPE" value="QUAD_X"/>
<define name="REVERSE" value="true"/>
</section>
</source>

; Hex (Time Cross) : [[Image:Hex_cross_layout.png|200px]]
Assuming that the order of motors, described in the "servos" section is FRONT_LEFT, FRONT_RIGHT, RIGHT, BACK_RIGHT, BACK_LEFT, LEFT.
<source lang="xml">
<section name="MIXING" prefix="MOTOR_MIXING_">
<define name="NB_MOTOR" value="6"/>
<define name="SCALE" value="256"/>
<define name="ROLL_COEF" value="{ 128, -128, -256, -128, 128, 256 }"/>
<define name="PITCH_COEF" value="{ 222, 222, 0, -222, -222, 0 }"/>
<define name="YAW_COEF" value="{ -128, 128, -128, 128, -128, 128 }"/>
<define name="THRUST_COEF" value="{ 256, 256, 256, 256, 256, 256 }"/>
</section>
</source>
This is equivalent to (available since v5.5_devel-602-g0129d3e):
<source lang="xml">
<section name="MIXING" prefix="MOTOR_MIXING_">
<define name="TYPE" value="HEXA_X"/>
</section>
</source>

; Octo (time cross): [[Image:octo.jpg|border|200px]]
<source lang="xml">
<section name="MIXING" prefix="MOTOR_MIXING_">
<define name="NB_MOTOR" value="8"/>
<define name="SCALE" value="256"/>
<define name="ROLL_COEF" value="{ 98, -98, -237, -237, -98, 98, 237, 237 }"/>
<define name="PITCH_COEF" value="{ 237, 237, 98, -98, -237, -237, -98, 98 }"/>
<define name="YAW_COEF" value="{ -128, 128, -128, 128, -128, 128, -128, 128 }"/>
<define name="THRUST_COEF" value="{ 256, 256, 256, 256, 256, 256, 256, 256 }"/>
</section>
</source>
This is equivalent to (available since v5.5_devel-602-g0129d3e):
<source lang="xml">
<section name="MIXING" prefix="MOTOR_MIXING_">
<define name="TYPE" value="OCTO_X"/>
</section>
</source>

; Octo (plus cross): [[Image:Octo_plus_motor_layout.png|border|200px]]
<source lang="xml">
<section name="MIXING" prefix="MOTOR_MIXING_">
<define name="NB_MOTOR" value="8"/>
<define name="SCALE" value="256"/>
<define name="ROLL_COEF" value="{ 0, -181, -256, -181, 0, 181, 256, 181 }"/>
<define name="PITCH_COEF" value="{ 256, 181, 0, -181, -256, -181, 0, 181 }"/>
<define name="YAW_COEF" value="{ -128, 128, -128, 128, -128, 128, -128, 128 }"/>
<define name="THRUST_COEF" value="{ 256, 256, 256, 256, 256, 256, 256, 256 }"/>
</section>
</source>
This is equivalent to (available since v5.5_devel-602-g0129d3e):
<source lang="xml">
<section name="MIXING" prefix="MOTOR_MIXING_">
<define name="TYPE" value="OCTO_PLUS"/>
</section>
</source>

If you want to compute mixing for a special configuration, please see the [[RotorcraftMixing]] page.

=== Supervision ===
<div class="toccolours mw-collapsible mw-collapsed">
Prior to '''v5.0''' motor mixing was called supervision. Click expand to see the details.
<div class="mw-collapsible-content">
Valid before '''v4.9_devel-164-gdb0d004'''

<source lang="xml">
<section name="SUPERVISION" prefix="SUPERVISION_">
<define name="STOP_MOTOR" value="0"/> 
<define name="MIN_MOTOR" value="3"/>
<define name="MAX_MOTOR" value="200"/>
<define name="TRIM_A" value="0"/>
<define name="TRIM_E" value="0"/>
<define name="TRIM_R" value="0"/>
<define name="NB_MOTOR" value="4"/>
<define name="SCALE" value="256"/>
<define name="ROLL_COEF" value="{ 0 , 0, 256, -256 }"/>
<define name="PITCH_COEF" value="{ 256, -256, 0, 0 }"/>
<define name="YAW_COEF" value="{ -256, -256, 256, 256 }"/>
<define name="THRUST_COEF" value="{ 256, 256, 256, 256 }"/>
</section>
</source>

; ''STOP_MOTOR'' : actuator specific command value to stop the motors
; ''MIN_MOTOR'' : actuator specific command value for idling motors
; ''MAX_MOTOR'' : actuator specific command value for maximum power
; ''TRIM_A'' : trim added to roll command
; ''TRIM_E'' : trim added to pitch command
; ''TRIM_R'' : trim added to yaw command
; x''_COEF'' : roll/pitch/yaw/thrust coefficients, see [[RotorcraftMixing]] for details or the examples in the above Motor Mixing section
</div>
</div>

=== Guidance ===
There are two sets of parameters for guidance: vertical (altitude) and horizontal (position).

==== vertical guidance ====
{{Box Code|conf/airframes/myrotorcraft.xml|
<source lang="xml">
<section name="GUIDANCE_V" prefix="GUIDANCE_V_">
<define name="HOVER_KP" value="150"/>
<define name="HOVER_KD" value="80"/>
<define name="HOVER_KI" value="20"/>


<define name="NOMINAL_HOVER_THROTTLE" value="0.5"/>
<define name="ADAPT_THROTTLE_ENABLED" value="TRUE"/>
<define name="REF_MIN_ZD" value="-3.0" unit="m/s"/>
<define name="REF_MAX_ZD" value="3.0" unit="m/s"/>
<define name="MAX_RC_CLIMB_SPEED" value="-3.0" unit="m/s"/>
<define name="MAX_RC_DESCENT_SPEED" value="3.0" unit="m/s"/>
</section>
</source>
}}

; ''HOVER_K''x : PID parameters for vertical hover control loop
; ''NOMINAL_HOVER_THROTTLE'' : expected throttle percentage needed for hovering (default is 0.4 = 40%)
; ''ADAPT_THROTTLE_ENABLED'' : enable adaptive nominal hover throttle estimation (default is TRUE, set to FALSE to disable)
; ''REF_MIN_ZD'' : vertical speed reference lower limit (since z-down is positive -> max speed upwards) (default -3.0m/s)
; ''REF_MAX_ZD'' : vertical speed reference upper limit (since z-down is positive -> max speed downwards) (default 3.0m/s)
; ''MAX_RC_CLIMB_SPEED'' : climb speed at max RC input in RC_CLIMB mode (default is ''REF_MIN_ZD'')
; ''MAX_RC_DESCENT_SPEED'' : descent speed at max RC input in RC_CLIMB mode (default is ''REF_MAX_ZD'')

==== horizontal guidance ====
{{Box Code|conf/airframes/myrotorcraft.xml|
<source lang="xml">
<section name="GUIDANCE_H" prefix="GUIDANCE_H_">
<define name="PGAIN" value="50"/>
<define name="DGAIN" value="100"/>
<define name="IGAIN" value="20"/>


<define name="AGAIN" value="0"/>
<define name="VGAIN" value="0"/>

<define name="MAX_BANK" value="20" unit="deg"/>
<define name="USE_SPEED_REF" value="TRUE"/>
<define name="REF_MAX_SPEED" value="5.0" unit="m/s"/>
<define name="REF_MAX_ACCEL" value="5.66" unit="m/s2"/>
<define name="REF_OMEGA" value="67" unit="deg"/>
<define name="REF_ZETA" value="0.85"/>
<define name="REF_TAU" value="0.5"/>
<define name="APPROX_FORCE_BY_THRUST" value="FALSE"/>
</section>
</source>
}}

; [PID]''GAIN'' : PID gains for horizontal control
; ''AGAIN'' : acceleration feedforward gain (default 0)
; ''VGAIN'' : velocity feedforward gain (default 0)
; ''MAX_BANK'' : maximum roll/pitch angle that is set from horizontal guidance (default 20deg, max 40deg)
; ''USE_SPEED_REF'' : since v5.1, give velocity commands via RC in GUIDANCE_H_MODE_HOVER (default: TRUE)
; ''REF_MAX_SPEED'' : maximum reference horizontal speed in m/s (default 5.0m/s)
; ''REF_MAX_ACCEL'' : maximum reference horizontal acceleration in m/s² (default tanf(RadOfDeg(30.))*9.81 = 5.66)
; ''REF_OMEGA'' : second order model natural frequency
; ''REF_ZETA'' : second order model damping
; ''REF_TAU'' : first order time constant
; ''APPROX_FORCE_BY_THRUST'' : try to better approximate force commands by taking thrust into account (default FALSE, set to TRUE to use it)

=== Simulation ===
See [[NPS]] (New Paparazzi Sim).

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

Rotorcraft Configuration

2017-04-26T18:22:39Z

IHaveADrone: /* Commands */ XML syntax typo

<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Airframe_Configuration</categorytree>
This page describes configuration options <span style="color:red"><b>specific to the rotorcraft firmware</b></span> in the [[Airframe_Configuration|airframe file]].

== Firmware and Hardware definitions ==

This is one example of a pretty standard quadcopter firmware definition:
{{Box Code|conf/airframes/myrotorcraft.xml|
<source lang="xml">
<firmware name="rotorcraft">
<target name="nps" board="pc">
<subsystem name="fdm" type="jsbsim"/>
</target>
<target name="ap" board="lisa_m_1.0"/>

<subsystem name="radio_control" type="ppm"/>
<subsystem name="telemetry" type="transparent"/>
<subsystem name="actuators" type="mkk"/>
<subsystem name="imu" type="aspirin_v1.5"/>
<subsystem name="gps" type="ublox"/>
<subsystem name="ahrs" type="int_cmpl_quat"/>
<subsystem name="stabilization" type="int_quat"/>
</firmware>
</source>
}}

=== Select your Board ===
Make sure you use the <b>rotorcraft [[Airframe_Configuration#Firmware|firmware]]</b> and choose the correct board, e.g.

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

The ap board name can be found in /conf/boards.

=== Actuators ===
You have to specify which ESCs you have by adding the appropriate [[Subsystem/actuators|actuators subsystem.]]
{{Box Code|conf/airframes/myrotorcraft.xml|
<source lang="xml">
<firmware name="rotorcraft">
<target name="ap" board="booz_1.0"/>
...
<subsystem name="actuators" type="mkk"/>
</firmware>
</source>
}}

=== Control Loops ===
See the [[Subsystem/stabilization|stabilization subsystem]] page to choose which attitude control algorithm to use and how to configure them.

The [[Control Loops]] page has some diagrams.

=== INS ===
The INS (Integrated Navigation System) subsystem contains estimations filter to e.g. fuse GPS and IMU data for better position and speed estimates.
The INS subsystem is optional in <= v4.2.

Since v4.9x the INS subsystem is mandatory, to use the same as in v4.2 omit the type.
{{Box Code|conf/airframes/myrotorcraft.xml|
<source lang="xml">
<firmware name="rotorcraft">
<target name="ap" board="booz_1.0"/>
...
<subsystem name="ins"/>
</firmware>
</source>
}}
You can also compensate for GPS lag in hff (horizontal filter float) if it is known (in seconds):
{{Box Code|conf/airframes/myrotorcraft.xml|
<source lang="xml">
<firmware name="rotorcraft">
<target name="ap" board="booz_1.0"/>
...
<subsystem name="ins" type="hff">
<define name="GPS_LAG=0.2"/>
</subsystem>
</firmware>
</source>
}}

== Motor Arming ==
By default the motors are armed with zero-throttle and full yaw. The motors are never started if AHRS is not aligned (disable it with AUTOPILOT_DISABLE_AHRS_KILL).

Other arming sequences can be configured:
* USE_KILL_SWITCH_FOR_MOTOR_ARMING defined (to 1):
** switch kill switch off to arm the motors
** if kill switch is off during startup, you need to kill again first, then unkill to start
** throttle needs to be down, other sticks centered to start motors
** need to be in manual mode to start the motors

* USE_THROTTLE_FOR_MOTOR_ARMING defined (to 1):
** automatically start motors when applying throttle
** if throttle was not down at startup, you need to put throttle down again first
** other sticks need to be centered to start motors
** need to be in manual mode to start the motors

== Autopilot modes ==
For rotorcrafts we have a lot of different modes that can be mapped to your 3-position switch (Manual, Auto1, Auto2).
The horizontal and vertical mode can be set differently as the following possible modes indicate (in parenthesis are the abbreviations displayed in the [[GCS#Strips|GCS]] strip).

'''Limiting max thrust via RC'''<br>
Modes with 'automatic' thrust control (e.g. x_Z_HOLD and NAV) let you limit the maximum thrust via RC by default. So you should push your throttle stick up after entering such a mode so the vertical controller has some "room" to stabilize the altitude. Should something weird happen you can limit the max thrust by taking throttle back.<br> You can turn this behavior off by defining '''NO_RC_THRUST_LIMIT'''

; AP_MODE_FAILSAFE (SAFE) :
This is a failsafe mode that gets triggered if:
* RC signal is lost (and you are not in KILL or NAV mode)
* GPS and RC is lost in NAV mode
The standard behaviour is that autopilot will level the rotorcraft out (setpoints to zero pitch and roll angles) and descend at 0.5m/s downwards. But this behavior can also be changed to something else ofcourse.

; AP_MODE_KILL (KILL) :
Motors are simply switched off.

; AP_MODE_RATE_DIRECT (RATE) :
This is basically the "most" manual mode you can get. You control not the attitude (roll and pitch angles) but the rotation rate. You also set the throttle directly with your RC.

; AP_MODE_ATTITUDE_DIRECT (ATT) :
You control the attitude (roll, pitch and yaw angles), but the throttle is directly proportional to your stick position.

; AP_MODE_RATE_RC_CLIMB (R_RCC) :
You control the rotation rate and the vertical speed according to your throttle stick position.<br>If you have your throttle stick in the middle position, the altitude is kept, down goes down at a speed proportional to your stick position (same for up). In this mode it makes sense to mount the spring for your throttle stick so it can recenter itself.

; AP_MODE_ATTITUDE_RC_CLIMB (A_RCC) :
You control the attitude (roll, pitch and yaw angles) and the vertical speed according to your throttle stick position.<br>If you have your throttle stick in the middle position the altitude is kept, if you move the stick down it goes down at a speed proportional to your stick position (same for up). In this mode it makes sense to mount the spring for your throttle stick so it recenter itself.

; AP_MODE_ATTITUDE_CLIMB (ATT_C) :
You control the attitude (roll, pitch and yaw angles) and the vertical speed. The vertical speed is set via fms (e.g. joystick).

; AP_MODE_RATE_Z_HOLD (R_ZH) :
You control the rotation rate and it holds the altitude you were at when entering this mode.<br>Your throttle stick position still limits the max throttle authority unless disabled with NO_RC_THRUST_LIMIT.

; AP_MODE_ATTITUDE_Z_HOLD (A_ZH) :
You control the attitude (roll, pitch and yaw angles) and it holds the altitude you were at when entering this mode.<br>Your throttle stick position still limits the max throttle authority unless disabled with NO_RC_THRUST_LIMIT.

; AP_MODE_HOVER_DIRECT (HOVER) :
The rotorcraft hovers at the horizontal position you were at when entering this mode (position control). You still set the throttle directly with your RC. Yaw command on the RC allows for heading change. If USE_SPEED_REF=1 then pitch and roll commands in the RC control speed according to max speed set with REF_MAX_SPEED in the GUIDANCE_H section of airframe file.

; AP_MODE_HOVER_CLIMB (HOV_C) :
The rotorcraft hovers at the position you were at when entering this mode (position control). RC commands work the same as in HOVER mode. The vertical speed is set via fms (e.g. joystick).

; AP_MODE_HOVER_Z_HOLD (H_ZH):
The rotorcraft hovers at the 3D position you were at when entering this mode (position and altitude control). RC commands work the same as in HOVER mode. <br>Your throttle stick position still limits the max throttle authority unless disabled with NO_RC_THRUST_LIMIT.

; AP_MODE_NAV (NAV) :
Full navigation mode. The rotorcraft follows your flightplan.<br>If you have a valid RC signal, your throttle stick position still limits the max throttle authority unless disabled with NO_RC_THRUST_LIMIT.

; AP_MODE_RC_DIRECT (RC_D) :
Safety pilot direct commands for helicopter.

; AP_MODE_CARE_FREE_DIRECT (CF):
Same as AP_MODE_ATTITUDE_DIRECT, but the roll and pitch commands are based on the yaw angle when entering this mode.

== XML Parameters ==

=== Mode ===
In the mode section you can set the autopilot modes associated with your 3-way mode switch on your RC.
{{Box Code|conf/airframes/myrotorcraft.xml|
<source lang="xml">
<section name="MODE" prefix="MODE_">
<define name="MANUAL" value="AP_MODE_ATTITUDE_DIRECT" />
<define name="AUTO1" value="AP_MODE_ATTITUDE_Z_HOLD" />
<define name="AUTO2" value="AP_MODE_NAV" />
</section>
</source>
}}

=== Commands ===

The <b><tt>commands</tt></b> lists the abstract commands you need to control the aircraft. For most multicopter you just need:
{{Box Code|conf/airframes/myrotorcraft.xml|
<source lang="xml">
<commands>
<axis name="PITCH" failsafe_value="0"/>
<axis name="ROLL" failsafe_value="0"/>
<axis name="YAW" failsafe_value="0" />
<axis name="THRUST" failsafe_value="0"/>
</commands>
</source>
}}

Each command is also associated with a failsafe value which will be used if no controller is active, for example during initialization of the autopilot board.

=== Motor Mixing ===

This section describes the "mixing" used for your particular multirotor configuration. This section is needed for all ESCs except "asctec_v1" wich do their mixing themselves.

<div class="toccolours mw-collapsible mw-collapsed" style="width:800px">
Used since '''v5.0''', for previous version see [[Rotorcraft_Configuration#Supervision|Supervision]].
<div class="mw-collapsible-content">Differences with the older supervision (used prior to '''v4.9_devel-164-gdb0d004'''):
* names: SUPERVISION -> MOTOR_MIXING
* independent of the actuators, needs to be loaded in the subsystems and call in the command_laws section
* internal values have '''pprz''' format (int16, between [-9600; 9600])
* min and max are not needed, coming from the servos definition
* trim are renamed with more explicit names
</div></div>

This subsystem takes ''roll'', ''pitch'', ''yaw'' and ''thrust'' commands as inputs and "mixes" them to get the final commands for your individual motors according to the layout of them. See [[RotorcraftMixing]] for the details behind this.

Note that after mixing the separate motor commands can "saturate", meaning you can't simply give negative thrust or more than the maximum. If a saturation is reached (desired motor command outside of possible MIN_MOTOR/MAX_MOTOR range), a saturation offset is applied to all motors in order to give attitude commands a higher priority than thrust. This offset is limited to ''MOTOR_MIXING_MAX_SATURATION_OFFSET'' (default is 10% of maximum command).

See also [https://github.com/paparazzi/paparazzi/issues/385 issue #385].

In '''firmware''' section:
{{Box Code|conf/airframes/myrotorcraft.xml|
<source lang="xml">
<firmware name="rotorcraft">
...
<subsystem name="motor_mixing"/>
...
</firmware>
</source>
}}

Configuration of the motor mixing:
{{Box Code|conf/airframes/myrotorcraft.xml|
<source lang="xml">
<section name="MIXING" prefix="MOTOR_MIXING_">
<define name="TRIM_ROLL" value="0"/>
<define name="TRIM_PITCH" value="0"/>
<define name="TRIM_YAW" value="0"/>
<define name="MAX_SATURATION_OFFSET" value="MAX_PPRZ/10"/>
<define name="NB_MOTOR" value="4"/>
<define name="SCALE" value="256"/>
<define name="ROLL_COEF" value="{ 0 , 0, 256, -256 }"/>
<define name="PITCH_COEF" value="{ 256, -256, 0, 0 }"/>
<define name="YAW_COEF" value="{ -256, -256, 256, 256 }"/>
<define name="THRUST_COEF" value="{ 256, 256, 256, 256 }"/>
</section>
</source>
}}

; ''TRIM_ROLL'' : trim added to roll command
; ''TRIM_PITCH'' : trim added to pitch command
; ''TRIM_YAW'' : trim added to yaw command
; ''MAX_SATURATION_OFFSET'' : set at "MAX_PPRZ/10" by default
; x''_COEF'' : roll/pitch/yaw/thrust coefficients, see [[RotorcraftMixing]] for details or the examples below

In '''command_laws''' section (placed after section MIXING):
{{Box Code|conf/airframes/myrotorcraft.xml|
<source lang="xml">
<command_laws>
<call fun="motor_mixing_run(autopilot_motors_on, FALSE, values)"/>
<set servo="FRONT" value="motor_mixing.commands[0]/>
<set servo="BACK" value="motor_mixing.commands[1]/>
<set servo="RIGHT" value="motor_mixing.commands[2]/>
<set servo="LEFT" value="motor_mixing.commands[3]/>
</command_laws>
</source>
}}

==== Mixing Examples ====

Hint: If your rotors are spinning '''opposite''' to the '''direction''' shown in the picture, '''reverse signs''' in the YAW_COEF line.

; Plus Cross : [[Image:cross_plus_simple.png|200px]]
Assuming that the order of motors, described in the "servos" section is FRONT, RIGHT, BACK, LEFT.
<source lang="xml">
<section name="MIXING" prefix="MOTOR_MIXING_">
<define name="NB_MOTOR" value="4"/>
<define name="SCALE" value="256"/>
<define name="ROLL_COEF" value="{ 0, -256, 0, 256 }"/>
<define name="PITCH_COEF" value="{ 256, 0, -256, 0 }"/>
<define name="YAW_COEF" value="{ -128, 128, -128, 128 }"/>
<define name="THRUST_COEF" value="{ 256, 256, 256, 256 }"/>
</section>
</source>
This is equivalent to (available since v5.5_devel-602-g0129d3e):
<source lang="xml">
<section name="MIXING" prefix="MOTOR_MIXING_">
<define name="TYPE" value="QUAD_PLUS"/>
</section>
</source>

; Time Cross : [[Image:cross_time_simple.png|200px]]
Assuming that the order of motors, described in the "servos" section is NW, NE, SE, SW.
<source lang="xml">
<section name="MIXING" prefix="MOTOR_MIXING_">
<define name="NB_MOTOR" value="4"/>
<define name="SCALE" value="256"/>
<define name="ROLL_COEF" value="{ 181, -181, -181, 181 }"/>
<define name="PITCH_COEF" value="{ 181, 181, -181, -181 }"/>
<define name="YAW_COEF" value="{ 128, -128, 128, 128 }"/>
<define name="THRUST_COEF" value="{ 256, 256, 256, 256 }"/>
</section>
</source>
This is equivalent to (available since v5.5_devel-602-g0129d3e):
<source lang="xml">
<section name="MIXING" prefix="MOTOR_MIXING_">
<define name="TYPE" value="QUAD_X_CCW"/>
</section>
</source>
This is equivalent to (available since v5.9_devel):
<source lang="xml">
<section name="MIXING" prefix="MOTOR_MIXING_">
<define name="TYPE" value="QUAD_X"/>
<define name="REVERSE" value="true"/>
</section>
</source>

; Hex (Time Cross) : [[Image:Hex_cross_layout.png|200px]]
Assuming that the order of motors, described in the "servos" section is FRONT_LEFT, FRONT_RIGHT, RIGHT, BACK_RIGHT, BACK_LEFT, LEFT.
<source lang="xml">
<section name="MIXING" prefix="MOTOR_MIXING_">
<define name="NB_MOTOR" value="6"/>
<define name="SCALE" value="256"/>
<define name="ROLL_COEF" value="{ 128, -128, -256, -128, 128, 256 }"/>
<define name="PITCH_COEF" value="{ 222, 222, 0, -222, -222, 0 }"/>
<define name="YAW_COEF" value="{ -128, 128, -128, 128, -128, 128 }"/>
<define name="THRUST_COEF" value="{ 256, 256, 256, 256, 256, 256 }"/>
</section>
</source>
This is equivalent to (available since v5.5_devel-602-g0129d3e):
<source lang="xml">
<section name="MIXING" prefix="MOTOR_MIXING_">
<define name="TYPE" value="HEXA_X"/>
</section>
</source>

; Octo (time cross): [[Image:octo.jpg|border|200px]]
<source lang="xml">
<section name="MIXING" prefix="MOTOR_MIXING_">
<define name="NB_MOTOR" value="8"/>
<define name="SCALE" value="256"/>
<define name="ROLL_COEF" value="{ 98, -98, -237, -237, -98, 98, 237, 237 }"/>
<define name="PITCH_COEF" value="{ 237, 237, 98, -98, -237, -237, -98, 98 }"/>
<define name="YAW_COEF" value="{ -128, 128, -128, 128, -128, 128, -128, 128 }"/>
<define name="THRUST_COEF" value="{ 256, 256, 256, 256, 256, 256, 256, 256 }"/>
</section>
</source>
This is equivalent to (available since v5.5_devel-602-g0129d3e):
<source lang="xml">
<section name="MIXING" prefix="MOTOR_MIXING_">
<define name="TYPE" value="OCTO_X"/>
</section>
</source>

; Octo (plus cross): [[Image:Octo_plus_motor_layout.png|border|200px]]
<source lang="xml">
<section name="MIXING" prefix="MOTOR_MIXING_">
<define name="NB_MOTOR" value="8"/>
<define name="SCALE" value="256"/>
<define name="ROLL_COEF" value="{ 0, -181, -256, -181, 0, 181, 256, 181 }"/>
<define name="PITCH_COEF" value="{ 256, 181, 0, -181, -256, -181, 0, 181 }"/>
<define name="YAW_COEF" value="{ -128, 128, -128, 128, -128, 128, -128, 128 }"/>
<define name="THRUST_COEF" value="{ 256, 256, 256, 256, 256, 256, 256, 256 }"/>
</section>
</source>
This is equivalent to (available since v5.5_devel-602-g0129d3e):
<source lang="xml">
<section name="MIXING" prefix="MOTOR_MIXING_">
<define name="TYPE" value="OCTO_PLUS"/>
</section>
</source>

If you want to compute mixing for a special configuration, please see the [[RotorcraftMixing]] page.

=== Supervision ===
<div class="toccolours mw-collapsible mw-collapsed">
Prior to '''v5.0''' motor mixing was called supervision. Click expand to see the details.
<div class="mw-collapsible-content">
Valid before '''v4.9_devel-164-gdb0d004'''

<source lang="xml">
<section name="SUPERVISION" prefix="SUPERVISION_">
<define name="STOP_MOTOR" value="0"/> 
<define name="MIN_MOTOR" value="3"/>
<define name="MAX_MOTOR" value="200"/>
<define name="TRIM_A" value="0"/>
<define name="TRIM_E" value="0"/>
<define name="TRIM_R" value="0"/>
<define name="NB_MOTOR" value="4"/>
<define name="SCALE" value="256"/>
<define name="ROLL_COEF" value="{ 0 , 0, 256, -256 }"/>
<define name="PITCH_COEF" value="{ 256, -256, 0, 0 }"/>
<define name="YAW_COEF" value="{ -256, -256, 256, 256 }"/>
<define name="THRUST_COEF" value="{ 256, 256, 256, 256 }"/>
</section>
</source>

; ''STOP_MOTOR'' : actuator specific command value to stop the motors
; ''MIN_MOTOR'' : actuator specific command value for idling motors
; ''MAX_MOTOR'' : actuator specific command value for maximum power
; ''TRIM_A'' : trim added to roll command
; ''TRIM_E'' : trim added to pitch command
; ''TRIM_R'' : trim added to yaw command
; x''_COEF'' : roll/pitch/yaw/thrust coefficients, see [[RotorcraftMixing]] for details or the examples in the above Motor Mixing section
</div>
</div>

=== Guidance ===
There are two sets of parameters for guidance: vertical (altitude) and horizontal (position).

==== vertical guidance ====
{{Box Code|conf/airframes/myrotorcraft.xml|
<source lang="xml">
<section name="GUIDANCE_V" prefix="GUIDANCE_V_">
<define name="HOVER_KP" value="150"/>
<define name="HOVER_KD" value="80"/>
<define name="HOVER_KI" value="20"/>


<define name="NOMINAL_HOVER_THROTTLE" value="0.5"/>
<define name="ADAPT_THROTTLE_ENABLED" value="TRUE"/>
<define name="REF_MIN_ZD" value="-3.0" unit="m/s"/>
<define name="REF_MAX_ZD" value="3.0" unit="m/s"/>
<define name="MAX_RC_CLIMB_SPEED" value="-3.0" unit="m/s"/>
<define name="MAX_RC_DESCENT_SPEED" value="3.0" unit="m/s"/>
</section>
</source>
}}

; ''HOVER_K''x : PID parameters for vertical hover control loop
; ''NOMINAL_HOVER_THROTTLE'' : expected throttle percentage needed for hovering (default is 0.4 = 40%)
; ''ADAPT_THROTTLE_ENABLED'' : enable adaptive nominal hover throttle estimation (default is TRUE, set to FALSE to disable)
; ''REF_MIN_ZD'' : vertical speed reference lower limit (since z-down is positive -> max speed upwards) (default -3.0m/s)
; ''REF_MAX_ZD'' : vertical speed reference upper limit (since z-down is positive -> max speed downwards) (default 3.0m/s)
; ''MAX_RC_CLIMB_SPEED'' : climb speed at max RC input in RC_CLIMB mode (default is ''REF_MIN_ZD'')
; ''MAX_RC_DESCENT_SPEED'' : descent speed at max RC input in RC_CLIMB mode (default is ''REF_MAX_ZD'')

==== horizontal guidance ====
{{Box Code|conf/airframes/myrotorcraft.xml|
<source lang="xml">
<section name="GUIDANCE_H" prefix="GUIDANCE_H_">
<define name="PGAIN" value="50"/>
<define name="DGAIN" value="100"/>
<define name="IGAIN" value="20"/>


<define name="AGAIN" value="0"/>
<define name="VGAIN" value="0"/>

<define name="MAX_BANK" value="20" unit="deg"/>
<define name="USE_SPEED_REF" value="TRUE"/>
<define name="REF_MAX_SPEED" value="5.0" unit="m/s"/>
<define name="REF_MAX_ACCEL" value="5.66" unit="m/s2"/>
<define name="REF_OMEGA" value="67" unit="deg"/>
<define name="REF_ZETA" value="0.85"/>
<define name="REF_TAU" value="0.5"/>
<define name="APPROX_FORCE_BY_THRUST" value="FALSE"/>
</section>
</source>
}}

; [PID]''GAIN'' : PID gains for horizontal control
; ''AGAIN'' : acceleration feedforward gain (default 0)
; ''VGAIN'' : velocity feedforward gain (default 0)
; ''MAX_BANK'' : maximum roll/pitch angle that is set from horizontal guidance (default 20deg, max 40deg)
; ''USE_SPEED_REF'' : since v5.1, give velocity commands via RC in GUIDANCE_H_MODE_HOVER (default: TRUE)
; ''REF_MAX_SPEED'' : maximum reference horizontal speed in m/s (default 5.0m/s)
; ''REF_MAX_ACCEL'' : maximum reference horizontal acceleration in m/s² (default tanf(RadOfDeg(30.))*9.81 = 5.66)
; ''REF_OMEGA'' : second order model natural frequency
; ''REF_ZETA'' : second order model damping
; ''REF_TAU'' : first order time constant
; ''APPROX_FORCE_BY_THRUST'' : try to better approximate force commands by taking thrust into account (default FALSE, set to TRUE to use it)

=== Simulation ===
See [[NPS]] (New Paparazzi Sim).

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

Modems/xbee

2017-02-08T17:48:51Z

IHaveADrone: ttttttypo

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

== Introduction ==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

=== Flashing the airborne module ===
# Connect your XBee, start X-CTU, click READ
# Select the function set '''ZIGBEE END DEVICE AT''' (or ZIGBEE ROUTER AT).
# Set the PAN ID to any number, must be the same as the pan id of the coordinator (Ground Station).
# Set the Node Identifier (NI) to your aircraft name or any other appropriate name.
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.
# Then write the firmware to the module.

=== Flashing the ground station module ===
# Connect your XBee, start X-CTU, click READ
# Select the function set '''ZIGBEE COORDINATOR AT'''.
# Set the PAN ID to any number, must be the same as the pan id of the end device (aircraft).
# Set the Node Identifier (NI) to PPRZ_GROUND or any other appropriate name.
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.
# Then write the firmware to the module.

=== Pairing your Modems ===

For maximum performance you can pair the ground modem to the airborne modem. Set the "DH - Destination Address High" and "DL - Destination Address Low" to the unique serial number "SH - Serial Number High" and "SL - Serial Number Low" of the other modem. Do so both on the ground modem and on the airborne modem. Failing to properly pair your modems will likely result in poor throughput and data loss between your airframe and your ground control station. If this is the case you may see errors on the Paparazzi Center console like <tt>Failure("Pprz.values_of_payload, wrong argument: 00 08 ")</tt> or <tt>Failure("Pprz.values_of_payload, too many bytes in message PONG: 00 03 02 2a 00 00 00 00 00 00 00 00 00 00 00 00 ")</tt>. Pairing does help and the error messages will disappear.

=== Reviving a non-responding Xbee Pro ===

To bring an apparently dead XBee Pro Series 2 back to life, do the following:

#Connect the USB device that holds the XBee to your laptop/desktop (without the XBee connected).
#Open X-CTU.
#In the tab used to program the device, select the proper modem (normally you would do a READ to get the values).
#Choose the option you want to program (i.e., "END DEVICE" or "COORDINATOR") as if you were programming it.
#With the XBee not in the device, click "WRITE". It will hang, timeout, and bring up a dialog box.
#Before you click OK to the dialog box, plug in the XBee module (carefully).
#Click OK to clear the message and it should start programming automatically.

=== Other tutorials ===

[http://pixhawk.ethz.ch/tutorials/how_to_configure_xbee PixHawk: HowTo configure XBee]

[http://wiki.openpilot.org/display/Doc/Configure+Xbee+via+Linux openpilot: XBee RF modems]

== XBee Pro ZNet 2.5 (AT command set) ==
These are legacy modems and not recommended/sold by Digi anymore.
It is recommended to upgrade these to XBee Pro ZB with the [ftp://ftp1.digi.com/support/images/ZNet%202.5%20to%20ZB%20Conversion%20Kit.zip ZNet 2.5 to ZB Conversion Kit] from Digi.
<br/>
If you want to use ZNet 2.5 feature set nevertheless, here is how to configure it:

=== Flashing the airborne module ===
# Connect your XBee, start X-CTU, click READ
# Select the function set '''ZNET 2.5 ROUTER/END DEVICE AT'''.
# Set the PAN ID to any number, must be the same as the pan id of the coordinator (Ground Station).
# Set the Node Identifier (NI) to your aircraft name or any other appropriate name.
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.
# Then write the firmware to the module.

=== Flashing the ground station module ===
# Connect your XBee, start X-CTU, click READ
# Select the function set '''ZNET 2.5 COORDINATOR DEVICE AT'''.
# Set the Destination Address Low (DL) to FFFF.
# Set the PAN ID to any number, must be the same as the pan id of the end device (aircraft).
# Set the Node Identifier (NI) to PPRZ_GROUND or any other appropriate name.
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.
# Then write the firmware to the module.

=== Setup ===

For the ZigBee ZNet 2.5 and ZB modules to work one of the modules has to be flashed with the coordinator firmware. All the others in the same PAN can either run as routers or end-devices.
* Flash one module (ground station) with the coordinator AT firmware
* Flash aircraft module with router or end-device AT firmware
To allow modules to join any PAN set the PAN ID to zero (default setting). Then the coordinator will generate a random PAN ID and routers and end-devices will join the first PAN they find.

If you operate in an environment with multiple zigbee PANs it is recommended to set the PAN ID explicitly:
* Set PAN ID to some unique (but same) ID on both modules
* Set a Node Identifier for each module (e.g. ground, aircraft)
<br/>

== XBee Pro DigiMesh / 802.15.4 ("Series 1") ==

=== Flashing the airborne module ===
# Connect your XBee, start X-CTU, click READ
# Leave the function set on '''XBEE PRO 802.15.4'''.
# Set the PAN ID to any number, must be the same as the pan id of the coordinator (Ground Station).
# Set the Node Identifier (NI) to your aircraft name or any other appropriate name.
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.
# Then write the firmware to the module.

=== Flashing the ground station module ===
# Connect your XBee, start X-CTU, click READ
# Leave the function set on '''XBEE PRO 802.15.4'''.
# '''Set Coordinator Enable to "1 - COORDINATOR".'''
# Set the PAN ID to any number, must be the same as the pan id of the end device (aircraft).
# Set the Node Identifier (NI) to PPRZ_GROUND or any other appropriate name.
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.
# Then write the firmware to the module.

(Tested on XBP24 Firmwareversion 10E6)

== XBee Pro 868 MHZ ==

=== Getting Them Working ===
Even with the xbee868.xml telemetry file, XBee868s will not last over 6 minutes. There is a special 868 build flag (in slayer1.xml), and matching option for the datalink but I could not get this to work. Eventually, I got them to work for about 20 minutes, which happily is the flight endurance of a heavily overloaded GWS Formosa.

I did this using a command window, but you could use X-CTU if you are a wuss or have Windows handy.

#Attach Xbee and start serial comm program (I use <code>screen /dev/ttyUSB0 <baud rate, just a number, no angled brackets></code>, you can also use pico- or microcom)
#Type AT and enter. You should get an OK back.
#ATMT and enter. You should get a number—this represents the number of extra times each packet will be broadcast. We now need to change this to zero.
#ATMT0 and enter => OK
#ATRR and enter. This number is the number of retries that will be sent if an ACK is not received. Disabling this will also have the side effect of disabling ACKs, giving us more packets to play with.
#ATRR0 and enter => OK
#Type ATWR to store the new stuff in the firmware. You should get an OK.
#Set the datalink to transparent mode both in your airframe file and on the datalink.

You may also want to drop the power level to 1mW for testing, or it won't actually work - they are just too damn powerful to talk to each other at a range of a couple of feet. I also used 1mW for flying - never lost the link, even after a mile. Didn't get round to range testing them though.

You probably want to do this to both XBees (at least I did). I personally had the baud rate at 57600 for legacy reasons, but it should work just as well at any other baud rate. '''Thanks to CheBuzz for this info''', and for helping me work all this out at 11pm the night before EMAV09.

== XBee 868LF ==

These relatively new modems use the whole spectrum allowed in your country to avoid Duty Cycle restrictions.

== XBee Pro XSC (900MHZ) ==

== Configuring XBee API mode (xbee protocol) ==

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

New Gaia

2017-01-05T21:12:38Z

IHaveADrone: spelling

(Webpage currently incomplete)

New Gaia is an update of the current gaia agent.

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

= Presentation =

== Functionalities ==

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

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

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

== The project ==

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

= How to get New Gaia ? =

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

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

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

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

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

= How to use New Gaia ? =

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

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

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

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

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

=== Thermal Columns ===

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

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

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

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

=== Vertical Profile ===

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

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

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

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

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

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

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

=== Turbulences ===

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

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

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

= About us =

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

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

Lisa/M v2.0

2017-01-05T18:50:43Z

IHaveADrone: pin naming fix

<div style="float: right; width: 15%"><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Autopilots</categorytree></div>
<div style="float: right; width: 45%; overflow: hidden">[[Image:LisaM_V2_0_TopView.JPG|right|500px|Lisa/M V2.0 top view]]</div>
<div style="float: right; width: 40%">__TOC__</div>

Lisa/M is a small, general purpose autopilot designed with flexibility across multiple applications in mind. Small weight and size, with (optional) integrated [[AspirinIMU | Aspirin IMU]] and full size 0.1" servo headers make the Lisa/M suitable for both fixed-wing and rotorcraft vehicles. This autopilot is based on a STM32 processor for extensive peripheral connection and faster processing.

A number of tutorials are being prepared for getting started with Lisa/M:
* [[Lisa/M/Tutorial/FixedWing|Fixedwing tutorial]]
* [[Lisa/M/Tutorial/RotorCraft|Rotorcraft tutorial]]

Please join us in our quest to make the getting started information even more, eh... informative, by adjusting those pages with your own improvements.

== Features ==

Lisa/M is based on the 64 pins STM32F105RCT6 [http://www.st.com/internet/mcu/product/221023.jsp connectivity line family] processor featuring 64k of RAM and 256k of FLASH. All the pins are exposed, providing access to the complete set of the STM32 peripherals.
NOTE: This MCU is different from LISA/L. Lisa/L is based on the 64 pins STM32F103RE processor featuring 64k of RAM and 512k of FLASH, which is part of the [http://www.st.com/internet/mcu/product/164485.jsp high-density performance line family].

* STM32 microcontroller [http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00220364.pdf STM32F105RCT6 datasheet] with 256kB flash and 64kB RAM
* Pressure sensor [http://www.bosch-sensortec.com/content/language1/html/3477.htm BMP085] (optional as of 08/2012)
* 7 x Analog input channels
* 3 x Generic digital in-/out-puts
* 2 x 3.3V TTL UART (5V tolerant)
* 8 x Servo PPM outputs (only 6 if second I2C (I2C1) bus in use)
* 1 x CAN bus
* 1 x [http://en.wikipedia.org/wiki/Serial_Peripheral_Interface SPI] bus
* 1 x [http://en.wikipedia.org/wiki/I2c I<sup>2</sup>C] bus (2 x when using only the first 6 Servo PPM outputs)
* 1 x Micro USB
* 4 x status LEDs with attached test point
* 10.8 grams (0.4 oz) (with Aspirin IMU mounted)
* 9.9 grams (0.35 oz) (without Aspirin IMU mounted)
* ~34mm x ~60mm x ~10mm
* 4 layers PCB design

With mounted Aspirin IMU has the following additional sensors on board:

* 3 Axis Gyroscope
* 3 Axis Accelerometer
* 3 Axis Magnetometer
* Barometer MS5611 (as of Aspirin v2.1)

NOTE:
'''Lisa/M has pads for the BMP085 pressure sensor. Lias/M 2 boards made before August 2012 had the BMP085 sensor mounted. Boards made after August 2012 do not have the sensor mounted as they are designed to be used with Aspirin 2.1 which has the new MS5611-01BA03 barometric pressure sensor.'''

So, except for a GPS unit you have all necessary sensors for full attitude and altitude stabilization in an extremely small package.

<gallery widths=200px heights=200px>
Image:LisaM_V2_0_TopView.JPG|Lisa/M V2.0 top view
Image:LisaM_V2_0_BottomView.JPG|Lisa/M V2.0 bottom view
</gallery>

== Pinout ==
Pins Name and Type are specified with respect to the Autopilot Board.

<div style="float: right; width: 100%">
[[Image:LisaM_V2_0_top_labeled.png|900px]]
[[Image:LisaM_warning_label.png|200px]]
</div>

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''SERVO1/2/3/4/5/6/7/8'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||SERVOx||OUT||Servo signal (PWM)(See Note 1 below)||style="background:Yellow; color:black"|Yellow
|-
|2||SV||PWR||Servo Bus Voltage Rail (conf w/ JP1)||style="background:red; color:white"|Red
|-
|3||GND||PWR||common ground||style="background:black; color:white"|Black
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''JTAG'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||N/A||N/A||JTAG Debug Header (Pin 1 is +3V3)||style="background:white; color:black"|None
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''UART3'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2||V_IN||PWR||UART Voltage (conf w/ JP6 and JP7)||style="background:Red; color:white"|Red
|-
|3||TX||OUT||USART3 Serial Output (3.3V level)||style="background:Yellow; color:black"|Yellow
|-
|4||RX||IN||USART3 Serial Input (3.3V level)(Pullup to Pin 2 voltage)(5V tolerant)||style="background:Orange; color:white"|Orange
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''UART1/5'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3V3||PWR||3.3V Rail from autopilot (conf w/ JP8 and JP9)||style="background:Red; color:white"|Red
|-
|3||RX1||IN||USART1 Serial Input (3.3V level)(Pullup to Pin 2 voltage)(5V tolerant)||style="background:Orange; color:white"|Orange
|-
|4||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|5|| +3V3||PWR||3.3V Rail from autopilot (conf w/ JP8 and JP9)||style="background:Red; color:white"|Red
|-
|6||RX5||IN||UART5 Serial Input (3.3V level)(Pullup to Pin 5 voltage)(5V tolerant)||style="background:Orange; color:white"|Orange
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''GPIO'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3V3||PWR||3.3V Rail from autopilot||style="background:Red; color:white"|Red
|-
|4||PC12||I/O||GPIO, connected to PC12 (5V tolerant)||style="background:#FDC579; color:black"|Dark Tan
|-
|5||TRST||I/O||JTAG_TRST (also connected to LED1 cathode)||style="background:#FED6B1; color:black"|Light Tan
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''ANALOG2'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3V3||PWR||3.3V Rail from autopilot||style="background:Red; color:white"|Red
|-
|3|| +5V||PWR||5V Rail from autopilot||style="background:Red; color:white"|Red
|-
|4||ADC4||I/O||by default connected to LED_4 cathode (Remove LED/resistor to use as ADC4)||style="background:magenta; color:white"|Magenta
|-
|5||ADC6||I/O||by default connected to LED_3 cathode (Remove LED/resistor to use as ADC6)||style="background:#FFA1B2; color:black"|Pink
|-
|6||BOOT0||I/O||BOOT0||style="background:grey; color:black"|Grey
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''USB'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||N/A||N/A||USB (The USB connections are also available as 0.05" (1.27mm) through hole pads underneath the GPIO header)||style="background:white; color:black"|None
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''I2C1 CAN'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| V_BATT||PWR||V_BATT Bus on autopilot, voltage divider for V_BAT_MEAS, (conf w/ JP2 to connect to V_IN)||style="background:Red; color:white"|Red
|-
|3|| V_IN||PWR||Connected to autopilot voltage regulator inputs (conf w/ JP1, JP2 and JP3)||style="background:Red; color:white"|Red
|-
|4||CANL||I/O||CANL (5V level)||style="background:orange; color:white"|Orange
|-
|5||CANH||I/O||CANH (5V level)||style="background:yellow; color:black"|Yellow
|-
|6||SCL||I/O||SCL (5V level)(See Note 1 below)||style="background:green; color:white"|Green
|-
|7||SDA||I/O||SDA (5V level)(See Note 1 below)||style="background:blue; color:white"|Blue
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''SPI1'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3V3||PWR||3.3V Rail from autopilot||style="background:Red; color:white"|Red
|-
|3||MOSI||Out||MOSI||style="background:orange; color:white"|Orange
|-
|4||MISO||In||MISO||style="background:yellow; color:black"|Yellow
|-
|5||SCK||Out||SCK||style="background:green; color:white"|Green
|-
|6||SS||Out||SS||style="background:blue; color:white"|Blue
|-
|7||DRDY||I/O||DRDY||style="background:#FDC579; color:black"|Dark Tan
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''ANALOG1'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3V3||PWR||3.3V Rail from autopilot||style="background:Red; color:white"|Red
|-
|3|| +5V||PWR||5V Rail from autopilot||style="background:Red; color:white"|Red
|-
|4||ADC1||In||ADC1 (or LED_6 if populated)||style="background:green; color:white"|Green
|-
|5||ADC2||In||ADC2 (or LED_7 if populated)||style="background:blue; color:white"|Blue
|-
|6||ADC3||In||ADC3 (or LED_8 if populated)||style="background:#FED6B1; color:black"|Light Tan
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''UART2'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3V3||PWR||UART Voltage (conf w/ JP4 and JP5)||style="background:Red; color:white"|Red
|-
|3||TX||OUT||USART2 Serial Output (3.3V level)||style="background:Yellow; color:black"|Yellow
|-
|4||RX||IN||USART2 Serial Input (3.3V level)('''NOT 5V TOLERANT''')(Pullup to Pin 2 voltage)||style="background:Orange; color:white"|Orange
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''I2C2'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3V3||PWR||3.3V Rail from autopilot||style="background:Red; color:white"|Red
|-
|3||SCL||I/O||SCL (3.3V level)||style="background:green; color:white"|Green
|-
|4||SDA||I/O||SDA (3.3V level)||style="background:blue; color:white"|Blue
|}

'''NOTE 1''': SERVO7 and SERVO8 are directly connected to I2C1_SCL and I2C1_SDA lines. Therefore one has to choose, either use SERVO7 and SERVO8 '''OR''' have the I2C1 bus available, if that one needs to be used for whatever reason alongside the I2C2 bus. To use the servos 7 and 8 just set the <define name="USE_SERVOS_7AND8"/> in your airframe file and you are good to go. For this to work one must make sure to have the latest Paparazzi sourcecode.

=== LEDs ===
Lisa/M 2.0 has 5 LEDS (+1 power LED). There are 3 additional LEDs (LED_6, LED_7, LED_8) that are not populated by default (in favor of using ADC1-3 on the ANALOG1 connector).
By default the LEDs are use for:
; LED_1, red: ''SYS_TIME_LED'': blinks with 1Hz
; LED_2, green : ''AHRS_ALIGNER_LED'': blinks until the AHRS is aligned (gyro bias initialized) and then stays on
; LED_3, green : ''GPS_LED'': blinking if trying to get a fix, on if 3D fix
; LED_4, red : ''RADIO_CONTROL_LED'': on if RC signal is ok
; LED_5, green : not set to anything by default

=== Jumper Configuration ===
There are a number of jumpers on Lisa/M used to configure voltage levels and power input.

The default configuration is UART3 VCC at V_IN, UART1/2/5 VCC at +3V3, with the V_SERVO servo voltage rail NOT connected to the autopilot V_IN rail, allowing one to power the autopilot and servos separately. The +5V regulator is NOT bypassed, allowing a regulated +5V on listed headers and for the CAN transceiver and I2C level shifter. The V_BATT connector is NOT connected to V_IN, so one can attach a battery voltage to the V_BATT pin to measure the battery voltage, if so desired.

<gallery widths=380px heights=205px>
Image:LisaM_V2_0_top_jumpers_and_leds.png | Lisa/M v2.0 Top Jumpers and LEDs
Image:LisaM_V2_0_bottom_jumpers.png | Lisa/M v2.0 Bottom Jumpers
</gallery>
<br style="clear:both">

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''Power Jumper Configuration'''
!width="7%"|''Jumper''!!width="20%"|''Bus Connection''!!width="7%"|''Default''!!''Description''
|-
|JP1||SERVO_BUS to V_IN||OPEN||If closed then connects servo header voltage rail SERVO_BUS to autopilot input voltage V_IN rail
|-
|JP2||V_BATT to V_IN||OPEN||If closed then connects I2C1/CAN rail V_BATT to autopilot input voltage V_IN rail
|-
|JP3||V_IN to +5V||OPEN||If closed then connects autopilot input voltage V_IN rail to autopilot +5V rail, bypassing onboard 5V supply
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''UART3 VCC Configuration'''
!width="7%"|''Jumper''!!width="20%"|''Bus Connection''!!width="7%"|''Default''!!''Description''
|-
|JP6||UART3_VCC to V_IN||style="background:black; color:white"|CLOSED||Connects UART3 connector VCC to autopilot input voltage V_IN rail
|-
|JP7||UART3_VCC to +3V3||OPEN||If closed then connects UART3 connector VCC to autopilot +3V3 rail
|}
'''WARNING: UART3 GPS Connector is connected to V_IN, check your GPS input voltage before connecting!!!'''

'''WARNING: DO NOT CLOSE BOTH JP6 AND JP7 SIMULTANEOUSLY!!!'''

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''UART2 VCC Configuration'''
!width="7%"|''Jumper''!!width="20%"|''Bus Connection''!!width="7%"|''Default''!!''Description''
|-
|JP4||UART2_VCC to V_IN||OPEN||If closed then connects UART2 connector VCC to autopilot input voltage V_IN rail '''SEE WARNING BELOW'''
|-
|JP5||UART2_VCC to +3V3||style="background:black; color:white"|CLOSED||If closed then connects UART2 connector VCC to autopilot +3V3 rail
|}
'''WARNING: UART2 RX is NOT 5V TOLERANT. Thus, while possible to connect UART2_VCC to V_IN, DO NOT ATTEMPT THIS. Only use JP5 (the default).

'''WARNING: DO NOT CLOSE BOTH JP4 AND JP5 SIMULTANEOUSLY!!!'''

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''UART1 and UART5 VCC Configuration'''
!width="7%"|''Jumper''!!width="20%"|''Bus Connection''!!width="7%"|''Default''!!''Description''
|-
|JP8||UART1&5_VCC to V_IN||OPEN||If closed then connects UART1 and UART5 connector VCC to autopilot input voltage V_IN rail
|-
|JP9||UART1&5_VCC to +3V3||style="background:black; color:white"|CLOSED||If closed then connects UART1 and UART5 connector VCC to autopilot +3V3 rail
|}
'''WARNING: DO NOT CLOSE BOTH JP8 AND JP9 SIMULTANEOUSLY!!!'''

There are additional jumpers on the board for expert or developer configurations, please see [[Lisa/M_v20#Schematic|schematic]] and [[Lisa/M_v20#Downloads|layout]] for more information.

=== Powering the Board ===

[[Image:LisaM_warning_label.png|right|200px]]

The 3.3V regulator on Lisa/M is a [http://www.micrel.com/page.do?page=/product-info/products/mic5209.shtml MIC5209-3.3YM] capable of delivering up to 500mA. While it is possible to power this regulator with up to 16V, '''DO NOT''' do this. By default, the UART3 RX pin is pulled up to the input voltage V_IN. For this reason, 5V is the maximum input voltage. Note that the UART3 GPS Connector is connected to V_IN, check your GPS input voltage before connecting. If one desires to have V_IN at a higher voltage, the jumpers should be adjusted accordingly. As noted, this regulator can handle up to 16V, though experience has shown that this regulator can become very hot in operation with high input voltages, resulting in potential thermal shutdown while in flight. Depending on the expected current draw, it is best to power this regulator with a lower voltage. 5V is the perfect choice.

The onboard 5V regulator on Lisa/M is a [http://www.national.com/pf/LP/LP2992.html LP2992], a low-noise, low-dropout linear regulator capable of delivering up to 250mA. This regulator can be bypassed with JP3, connecting the autopilot V_IN bus directly to the autopilot 5V bus if, for example, one is using an external 5V regulated supply, and a higher current is needed. Unless external use of 5V is required on the ANALOG1 and ANALOG2 headers, the only 5V usage onboard is for the CAN transceiver and the I2C1 level shifter.

When measuring the supply voltage of a battery with the V_BATT pin (could be connected to V_IN through JP2), it is important to note the maximum voltage limit. The voltage divider on the board for measuring with a 3.3V ADC is --'''V_BAT'''--/\/\'''10k'''/\/\--'''V_BAT_MEAS'''--/\/\'''2k2'''/\/\--'''GND'''--. This means that the maximum allowable voltage on V_BATT is

<math>V\_BAT_{max} = 3.3V*\frac{10k}{2.2k} = 15V</math>

If a higher voltage measurement is desired, another voltage divider is required off-board. Alternatively, one could modify the existing voltage divider (e.g. change 10k resistor to 22k to get 33V maximum). When checking if voltage exceeds the maximum, make sure to consider maximum battery voltage, not nominal voltage (e.g. 4.22V or so for a single lithium cell, not 3.7V nominal, so the maximum number of cells in series is 3, like a 3S LiPo pack).

== Schematic ==
<gallery widths=250px heights=168px>
Image:Lisa_m_v2_0_sheet_1.png | LisaM V2.0 Schematic Sheet 1/3
Image:Lisa_m_v2_0_sheet_2.png | LisaM V2.0 Schematic Sheet 2/3
Image:Lisa_m_v2_0_sheet_3.png | LisaM V2.0 Schematic Sheet 3/3
</gallery>
<gallery widths=250px heights=168px>
Image:Lisa_m_v2_1_r3_sheet_1.png | Lisa/M V2.1 R3 Schematic Sheet 1/2
Image:Lisa_m_v2_1_r3_sheet_2.png | Lisa/M V2.1 R3 Schematic Sheet 1/2
</gallery>
<br style="clear:both">

== Examples of Airborne Equipment Electrical Connections ==

=== Quadrocopter, Spektrum Satellite Receivers, PWM Motor Controllers (ESC) and dedicated avionics Battery Elimination Circuit (BEC) ===

[[File:LisaM_V2_0_wiring_quadrocopter_spektrum_bec_pwmesc.png|700px]]

This is a recommended powering configuration. It eliminates the balancing issues of the built in BECs into the ESCs.

The dotted lines from the BEC show the alternative wiring that does not require closing the VS jumper on the Lisa/M. The disadvantage is that you have to wire/crimp the BEC output wires into the picoblade molex connector providing the battery voltage reference. Usually it is easier to just use the existing "servo" connector on the BEC and closing the jumper instead.

=== Quadrocopter, Spektrum Satellite Receivers and PWM Motor Controllers (ESC) ===

[[File:LisaM_v2_0_wiring_quadrocopter_spektrum_pwmesc.png|700px]]

This configuration assumes the ESCs have a battery eliminator circuit (BEC) function and provide 5 volts on their 5V pins. Closing JP1 powers Lisa/M and the attached accessories.

<span style="color:red">Warning:</span> The built in BECs on the ESCs are usually linear voltage regulators, they are fairly inefficient compared to dedicated BECs that are usually implemented as switching DC/DC converters.

<span style="color:red">Warning:</span> Due to manufacturing differences of BECs, connecting more then one BEC in parallel will likely cause one of the BECs to take majority of the load and dissipate most of the drop down voltage. ([https://en.wikipedia.org/wiki/Linear_regulator Read on how linear voltage regulators work.]) As in this example the BECs are part of the ESCs, one of the ESCs will get warmer than the others, which in turn may lead to reliability issues.

[[File:LisaM_V2_0_wiring_quadrocopter_spektrum_pwmesc_shunts.png|700px]]

<span style="color:green">Tip:</span> To improve balancing between the ESC built in BECs you can add a 1Ohm resistor in the +5V line coming from the motor controller. This will cause some pre-loading of the voltage regulator and improve the load sharing between the BECs while decreasing the efficiency of the supply.

When using cheap ATMega or SiLabs-based PWM motor controllers consider replacing their firmware with either [https://github.com/sim-/tgy Simon Kirby] or [https://github.com/bitdump/BLHeli BLHeli] firmware respectively to get useful performance of your multicopter! You can find a firmware compatibility list [https://docs.google.com/spreadsheet/ccc?key=0AhR02IDNb7_MdEhfVjk3MkRHVzhKdjU1YzdBQkZZRlE here].

=== Quadrocopter, Spektrum Satellite Receivers and I2C Motor Controllers (ESC) ===

[[File:LisaM_V2_0_quadrocopter_spektrum_i2c_esc_wiring.png|700px]]

This diagram "should" be the same for AscTec as well as Mikrokopter motor controller based airframes.

=== Fixedwing, Spektrum Satellite Receivers and Elevons Only ===

[[File:LisaM_V2_0_wiring_fixedwing_spektrum_elevons.png|700px]]

This configuration assumes the ESC has a BEC and provides 5 volts on its 5V pin. Closing JP1 powers Lisa/M and the attached accessories.

=== Fixedwing, Spektrum Satellite Receivers ===

[[File:LisaM_V2_0_wiring_fixedwing_spektrum.png|700px]]

This configuration assumes the ESC has a BEC and provides 5 volts on its 5V pin. Closing JP1 powers Lisa/M and the attached accessories.

=== Transitioning [http://wiki.thequadshot.com Quadshot] Using Spektrum Receivers ===

[[File:LisaM_V2_0_wiring_quadshot_spektrum.png|700px]]

The ESCs have BECs and provide 5 volts on their 5V pins. Closing JP1 powers Lisa/M and the attached accessories.

Still need: Large Fixed-wing with advanced power system and/or IC engine, PPM example

== R/C Receivers ==

One can use [[Subsystem/radio_control#Spektrum|Spektrum]] DSM2 or compatible receivers as well as traditional PPM receivers. It is even possible to [[Subsystem/radio_control#Spektrum|connect two Spectrum or compatible satellite receivers]] for better redundancy or to improve RC signal reception. Connecting a RC receiver for flying your aircraft in manual mode during setup and test phase is 99% of the cases a must. Therefore the Paparazzi team made it easy to connect one.

=== Using a Spektrum DSM receiver ===

==== Physically connecting ====

Wiring up a Spektrum or compatible satellite receiver is not all to difficult to do. Note however that it is very important to make absolutely sure the connectors are properly made. Not being precise in this step can mean full RC loss and loss of airframe in the first tuning testflights.

A spektrum satellite receiver should be connected to the UART1 connector on the autopilot board. Make sure the voltage on the AP board UART1 + pin is not to high, or to low for your receiver.

Steps:
# Connect the minus(-) of the receiver to GND of UART1
# The receiver plus(+) to the UART1 Plus(+)
# Data out signal of the receiver to the RX pin on the UART1

==== Binding ====

To get a receiver and transmitter to work together you must perform a binding process.

It is important to '''bind''' your Spectrum DSM receiver to your transmitter '''via''' your '''Lisa board''', not in any other way!

The way to bind is by temporary connecting via fiddly small molex pins.
It is advised to make a small bind plug out of a molex connector for this purpose.
Before you start make sure you have your airframe configuration already uploaded either via USB or a JTAG cable.

The bind procedure:

# On the connector '''ANALOG1''' have a wire between the GND and ADC1 pin, located in the middle of the board
# Power up your autopilot board
# Hold the bind button on your '''transmitter''', while '''keeping it pressed''' switch on your transmitter
#:Wait...! All lights of the receiver blink and then go steady
# Let go of your transmitter bind button
# Power off your Lisa Board
# Remove the wire connecting the GND and ADC1 pins on the ANALOG1 connector
# Repower your board, if you have servos connected and wiggle the RC transmitter sticks some servos should move

That is all, you are done.
The bind procedure only needs to be done '''once''' for your receiver.

=== Using a CPPM receiver ===

Using a CPPM receiver, a so called '''PPM sum stream''' input is possible. [[RC_Receivers_and_Radios#PPM_Based_Systems | To make it work, you need a CPPM a.k.a. PPM sum, stream out capable receiver. Find out more following this link]]

==== Connecting ====

Connect the CPPM out signal to the RX pin of UART1.

Make sure put this in your airframe file in your AP target section.
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
<subsystem name="radio_control" type="ppm">
<configure name="RADIO_CONTROL_PPM_PIN" value="UART1_RX"/>
</subsystem>
...
</firmware>
</source>

===== Alternative =====

However if in the case you want to use the UART1 port for something else, there is an option to connect the receiver to a servo pin. Yes, that's right, a servo connector is used for receiving a CPPM stream '''input'''. If you want to walk that path, the default pin number to capture the CPPM datastream is via servo connector SERVO6

If you connect the CPPM out capable receiver that way make sure to put this in your airframe file in your AP target section:

<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
<subsystem name="radio_control" type="ppm">
<configure name="RADIO_CONTROL_PPM_PIN" value="SERVO6"/>
</subsystem>
...
</firmware>
</source>

If you do not have or cannot modify a receiver to a ''CPPM out'' able receiver, a [[PPM_Encoder | PPM encoder board]] can be used to avoid opening your receiver for PPM out modification. However with the very low prices of Spectrum DSMX CPPM out, lat time we looked you could have one starting from EUR 10,-

===Using a S-Bus receiver===

There is a third option, connect a receiver with S-Bus signal output. For this with regular Futaba receiver an inverter my be needed.

== Extras ==

=== UART I/O ===

UART pins can also be used as general purpose I/O, this might come in handy in case all other inputs or your AP board are in use.

=== USB as UART1TX + hardware flow control===

[[File:Lisam-usb-uart1.jpg]]

The USB_VBUS on the Lisa/M 2.0 can be used as UART1 TX. To do this, a diode has to be removed. Make sure to include a series resistor of 100-3000 Ohm to protect the microcontroller from overcurrents. The 2nd and 3th pin of the USB pads are CTS and RTS respectively. It is recommended to include a series resistor in the RTS line, as this is an outgoing line.

If you want to enable flow control in the software, but don't want to use flow control when no cable is connected to the CTS/RTS, a pulldown resistor of 10 kOhm has to be added between the CTS and the GND. If you do this, take care when connecting UART devices that have a large series resistor in their RTS line. The combination of the pulldown resistor and the series resistor might cause the high-level voltage to drop under the high-level threshold of the microcontroller, causing strange behaviour.

For Example the RTS , mostly a purple wire, is the '''pin 10''' on the Xtend module when set in the module with Hardware flow control (use X-CTU)
CTS, most blue, on pin 9 of the Xtend

<gallery widths=380px heights=205px>
Image:Lisam-diode.JPG | Remove this diode. After removing this diode you can not power the board via USB anymore.
Image:Lisam-gpio-usb.JPG | Take care of the small distance between the GPIO pins and the USB pads.
</gallery>

== PCB ==

=== Gerber & Drill Files ===

'''''Download Lisa/M v2.0 gerber & drill files (zip)''''' ''[[Lisa/M_v2.0#Get the design|Get the design]]''

== Assembly ==

To create and assemble a board oneself is possible. It takes some skills however.

For the Lisa/m v2.0 without the Aspirin sensor board a good soldering iron is enough.(smallest components are 0402) For the Aspirin Sensor board you need a hot air soldering station.

In case you wan to follow that path you need the design. You came to the right place here is the info to get the needed files;

===Components Layout===

''[[Lisa/M_v2.0#Get the design|Get the design]]''

Need some top and bottom of board images and line drawings here.

=== Bill Of Material ===

'''''Download Lisa/M v2.0 Bill Of Material (zipped .xls file)''''' ''[[Lisa/M_v2.0#Get the design|Get the design]]''

Open .sch File in Eagle, execute UPL --> bom.ulp , save as .txt

== PCB and assembled boards suppliers ==

To difficult to create your own AP board, understandable, thus pre made board available via [[Get_Hardware|Get Hardware]] page... hopefully :)

== Mechanical Dimensions ==

[[Image:LisaM_V2_0_top_mechanical.png|500px|Lisa/M v2.0 Mechanical Dimensions]]

The overall height of the board including the servo connectors is 10mm. Note that the overall length includes the USB connector. The mounting holes are nominal 2mm diameter (with a bit of clearance).
Beware that in version 2.1 of the Lisa/MX the mounting holes are for m3 screws.

== Get the design ==

'''Source files'''
:*download available on GitHub: ''[https://github.com/paparazzi/paparazzi-hardware/tree/master/controller/lisa_m/v2.0 Lisa/M v2.0 Cadsoft Eagle 6 Design]''
'''Gerber & Drill files'''
:*download ''NOT YET AVAILABLE'' Need generated gerbers and drill files
'''Assembly files'''
:*download ''NOT YET AVAILABLE'' Need Lisa/M v2.0 Components layouts (pdf)
:*download ''NOT YET AVAILABLE'' Need Lisa/M v2.0 Bill Of Material

== Uploading new software ==
New onboard software for the Lisa/M v2.0 can uploaded by connecting your PC via a micro-USB port to the autopilot board. For this the board need to contain the [[Luftboot]] bootloader. All Lisa/M 2.0 and Lisa/M 2.1 from [[1BitSquared]] come with luftboot already in the board.

An alternative to get your firmware in the board is by using a Black Magic Probe JTAG/SWD debugger and programmer connected via the 10-pin JTAG/SWD Samtec connector that is on the board.

See the [[FirmwareFlashing]] page for an overview of different methods to upload new software to your autopilot.

=== Using luftboot ===
'''This is the default FLASH_MODE for Lisa/M v2.0 and v2.1''', it could be explicitly selected by adding
:<source lang="xml"><configure name="FLASH_MODE" value="DFU"/></source>
to the firmware section of your airframe file. Make sure to set Lisa/M 2.0 or 2.1 as it's target board.

Once USB is plugged in, the board automatically goes to bootloader mode and the status LEDs cycle up and down:

[[File:Luftboot.gif|320px]]

If you have trouble entering the bootloader mode or want to upload/update the bootloader itself, see the [[Luftboot]] page.

On Lisa/M V2.1 if you plug in the usb connector the board should go into bootloader mode automatically, older versions of the board come with a bootloader that has to be explicitly entered. If you have trouble with any part of the process, make a github account and click on the chat button in the lower right corner on this page.

=== Using JTAG ===
You still can use a [[JTAG|JTAG adapter]] for [[FirmwareFlashing#JTAG|flashing]] and [[DevGuide/JTAG-Debug|debugging]] your paparazzi firmware. To use [[FirmwareFlashing#JTAG|JTAG flashing]] configure the ''FLASH_MODE'' in your firmware section:
:<source lang="xml"><configure name="FLASH_MODE" value="JTAG"/></source>

It is recommended to use the Black Magic Probe as your JTAG adapter. This avoids issues that result from using OpenOCD software. See more details [[JTAG#Black_Magic_Probe|here]]

Using JTAG will not overwrite the bootloader by default. To overwrite the luftboot bootloader configure
:<source lang="xml"><configure name="NO_LUFTBOOT" value="1"/></source>

Then press upload as normal...

=== Serial Firmware Upload ===
Firmware upload using the factory integrated bootloader can be useful e.g. if you have overwritten [[Luftboot]] accidentally and don´t have access to [[JTAG]].<br/>
Either set the flash mode in the target section of the airframe configuration:
:<source lang="xml"><configure name="FLASH_MODE" value="SERIAL"/></source>
or add it to the commandline invocation:
make AIRCRAFT=<aircraftname> ap.upload FLASH_MODE=SERIAL

Due to hardware constraints, the board has to be modified to make use of the bootloader, which is only accessible on UART1:
# Diode D3 has to be removed (the bigger black brick next to the USB connector). Attention, no more powering via USB after that.
# BOOT1 has to be set to GND by connecting ACC_DRDY(unused) to GND at the Aspirin pads

Now a boot sequence works as follows:
#BOOT0 has to be set to 3.3V by use of a jumper cable
#Connect a 3.3V serial cable (FTDI, MAX232...) to UART1, the TX pin is USB_VBUS (accessible were the previously mentioned diode was located)
#Power the board and activate the bootloader program

=== Prevent board from going into bootloader mode ===

Normally, if you power up the board with the USB cable connected to a PC it will automatically go into bootloader mode. If you want the board to power up normally with the cable connected you can ground the ADC2 in the ANALOG1 connector.

== Detailed Hardware Revision History ==

=== Changes Between LISA v1.1 and v2.0 ===

* Lots of silkscreen improvements
* Added attributes to all parts to make the usage of bom-ex ulp possible.
* Improved routing to allow teardropping
* Fixed stm32f1, f2 and f4 compatibility circuit. (has to jump to ground not to 3v3)
* Connected existing UART RX pullups to the respective connector power pins instead of 3v3. To prevent connecting 5V over IO pin to the 3v3 power rail.
* Added pullups on all UART RX lines to prevent undesired floatation.
* LED's are connected to 3v3 now. To make sure we don't have an issue with voltage tolerance on the gpio pins.
* ...

== Hardware Change Requests ==

If you have a Lisa/M 2.0 and in the process of using it you come up with something you find annoying, dangerous, or restricting, add your hardware update requests here. Better still, modify the Lisa schematics yourself and show your new improvements if you are skilled enough to do this.

* REQ: Replace BMP085 with MS5611 (the MS5611 seems to be better in performance then the BMP but it is more expensive and seems to be more difficult to obtain.
** A: Using a MS5611 is possible through using a Aspirin v2.1 board

* REQ: Replace 7 Pin CAN with molex with something less risky to be inserted in 7 Pin SPI in relation to powering the board via CAN molex.

* REQ: Separate spot for external power if powered via separate battery. Realizing we can via Servo ports by Bridge J1 but still like to measure board voltage then and have a way to add power without mistakenly insert I2CCAN Molex conector into SPI Molex on board connector. Thus a separate CAN and Power plug. Power on regular four pin molex with GND, V+5, , V_BATT, V_I (Current sense). Option to have thicker wire to be soldered to the board, for power hungry setups and other issues connectors for power are not a good idea.

* REQ: Replace Aspirin IMU board with InvenSense MPU-9150 and bring the MS5611 back onto the Lisa/M board to reduce footprint, mass, and manufacturing cost once the 9150 becomes readily available(if at al with SPI) and is tested to perform well.

== Lisa/Lia F4 ==
Lisa/Lia autopilot can be easily converted to a much more powerful controller, based on STM32F405RGT6 chip [http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1577/LN1035/PF252144]. The chip has the same dimensions (LQFP64 10x10mm package) with the exact same pinout as the original STM32F105RCT6 chip. The main advantage of the f4 chip is:

* 168MHz CPU speed, 1MB flash and 192kb RAM
* FPU (fast floating point computations)
* configurable DMA streams (more peripherals can use DMA)
* multiplexed IO pins (peripherals can be mapped to various IO pins)
* CPU usage only about 5% with standard rotorcraft flight configuration

STM32F405RGT6 chip can be ordered for example [http://cz.mouser.com/ProductDetail/STMicroelectronics/STM32F405RGT6/?qs=Z8%252beY1k3TIKgj7QWsYGpQw== here]. To replace the chip a good soldering station with microscope and enough light is recommended. After replacing the chip, jumpers CMP1 and CMP2 have to be opened.
<gallery widths=300px heights=200px>
[[File:F4_digikey.jpg]]
Image:F4_digikey.jpg|DigiKey part number for F4 chip
Image:F4_on_board.jpg|Lia F4 with the new chip
</gallery>

=== Programming ===
The STM32F4 can be flashed via SWD/JTAG (e.g. with the BlackMagicProbe) or via [[DFU#Native_DFU_bootloader_.28embedded_in_ROM.29|DFU-UTIL]].
[[Luftboot|Luftboot]] currently supports only F1xx chips.

'''To program via DFU-UTIL:'''

[[File:LisaMX v2_0_DFU.jpg|500px]]

[[DFU#Native_DFU_bootloader_.28embedded_in_ROM.29|First, install DFU-UTIL as shown here.]]<br>
The two pairs of pins circled in red should be shorted (VERY CAREFULLY), eg with tweezers, as shown, i.e.:<br>
1) The Boot0 and VDD pins on the STM32F4 should be shorted together.<br>
2) The ACC_DRDY (Boot1) and GND pins should be shorted together on the Aspirin mounting pads. (This can be done even if an aspirin IMU is mounted).<br>
The USB connector should then be plugged in. This action also powers the board. Do not connect any additional source of power.<br>
Remove the shorts. The board should now be in bootloader mode. Only one green LED should be lit.<br>
The board can then be flashed using DFU-UTIL.<br>
Tested functional on a [http://transition-robotics.com/products/lisa-m-f4-with-10dom-aspirin-imu TRI Lisa/MX v2.0] using Paparazzi Master branch on 18 Nov 2014.<br><br>

'''A guide how to flash the F4 chip from Eclipse can be found in [[RT_Paparazzi|RT_Paparazzi]].'''

[[Category:Lisa]] [[Category:User_Documentation]] [[Category:Autopilots]]

Advanced Navigation Routines

2016-10-27T15:51:06Z

IHaveADrone: /* Bungee Takeoff */

= Introduction =

The flight plan standard navigation functions are very flexible. However sometimes one needs to perform a very specific task, and the basic functions are not enough to accomplish a special mission. In that case you can use additional modules functions in the flight plan. By adding a navigation capability to your airframe. The flight plan now has extra functionality that can be used.

= Available navigation modules =

== Navigation Routines (Prev.OSAM) ==

Thanks to Team OSAM's contribution these navigation capabilities have been added.

To use these navigation routines, you need to change the navigation subsystem type to extra in your airframe file. The navigation extra subsystem includes extra navigation routines like OSAMnav, spiral, poly_survey_advanced, nav_cube, etc.

<source lang="xml">
<subsystem name="navigation" type="extra"/>
</source>

Also include OSAMNav.h in your flight plan:

<source lang="xml">
#include "subsystems/navigation/OSAMNav.h"
</source>

== Flower ==
[[Image:FlowerScreenShot.png|thumb|Screen shot of flower routine]]
The flower navigation routine flies the aircraft in a flower pattern defined by two waypoints. The center waypoint defines the center of the flower and the altitude the plane flies at. The edge waypoint defines the radius of the flower.

In our example the waypoints are called "Center" and "Edge":

{{Box Code|conf/flight_plans/myflightplan.xml|
<source lang="xml">
<waypoint name="Center" x="-20.0" y="-160.0"/>
<waypoint name="Edge" x="-10.0" y="-60.0"/>
</source>
}}

Then you can add flower to your flight plan:

{{Box Code|conf/flight_plans/myflightplan.xml|
<source lang="xml">
<block name="Flower">
<call fun="InitializeFlower(WP_Center,WP_Edge)"/>
<call fun="FlowerNav()"/>
</block>
</source>
}}

Note that in the function InitializeFlower the waypoints need the prefix "WP_".

== Bungee Takeoff ==

The bungee takeoff routine helps to automate takeoff by turning the throttle on after the bungee has been release from the hook. The only waypoint you need for this routine is the position of where the bungee is pegged to the ground. Using this waypoint, a line is drawn from the position of the aircraft to the bungee waypoint. This line is called the launch line and will stop updating once the speed of the plane exceeds the MinSpeed. This allows the user to initialize the routine, move the plane and launch it without having to reinitialize. Once the plane is launched, it will follow the launch line until it crosses the throttle line. The throttle line is a line perpendicular to the launch line at a distance d from the bungee waypoint (see the diagram below). When the plane crosses the throttle line and the speed of the aircraft is greater than MinSpeed, the throttle comes on. After the throttle comes on, the plane keeps going straight until it reaches a specified speed and altitude above the bungee waypoint altitude. When it reaches the takeoff speed and takeoff altitude, the next block in the flight plan is executed. The takeoff speed, takeoff altitude, MinSpeed and the distance d from the bungee waypoint are specified in the airframe file. You will need to add those values to your airframe file like this...

{{Box Code|conf/airframes/myAircraft.xml|
<source lang="xml">
<section name="Takeoff" prefix="Takeoff_">
<define name="Height" value="30" unit="m"/>
<define name="Speed" value="15" unit="m/s"/>
<define name="Distance" value="3" unit="m"/>
<define name="MinSpeed" value="5" unit="m/s"/>
</section>
</source>
}}

You can add the bungee takeoff routine to your flight plan like so...

{{Box Code|conf/flight_plans/myflightplan.xml|
<source lang="xml">
<block name="Takeoff" strip_button="Takeoff (wp CLIMB)" strip_icon="takeoff.png">
<call fun="InitializeBungeeTakeoff(WP_Bungee)"/>
<call fun="BungeeTakeoff()"/>
</block>
</source>
}}

To get this routine to work consistently, you will need to tune the values in the airframe config file. If the prop doesn't automatically turn on when it crosses the throttle line, it could be because the Distance and/or the MinSpeed are too big. If it turns on to early, it could be because the Distance and/or MinSpeed are too small.

<span style="color:#ff0000"> ***Precaution should be taken while tuning the auto takeoff with electrical plane. If the MinSpeed is too low, the prop could turn on while holding the aircraft!***</span>

<gallery>
Image:BungeeTakeoffDiagram.png|Bungee takeoff diagram
Image:BungeeTakeoffInit.png|After bungee takeoff initialization
Image:BungeeTakeoffThrottleOn.png|After crossing the throttle line
</gallery>

== Polygon Survey ==
=== Explanation ===
With this navigation routine, an aircraft can survey the area of any [http://en.wikipedia.org/wiki/Convex_polygon convex polygon] given an entry point, the number of waypoints which define the polygon, the sweep width and the desired orientation of the sweeps.

The entry point is the first corner of the polygon and the point at which the aircraft will begin surveying the area. When in the entry state, the aircraft will circle around the entry point in order to smoothly transition into the first sweep. The aircraft will also keep circling around the entry point until it gets to the waypoint altitude. After the first sweep is made, the direction of the next sweep is determined by the distance of the entry point to the edges of the polygon. If there is more area above the first sweep, the aircraft will sweep up. If there is more area below the first sweep, the aircraft will sweep down.

The aircraft will keep sweeping back and forth until it reaches the end of the polygon. At this point, the aircraft will sweep back up/down the polygon halfway in between the sweeps previously made by the aircraft (just like the rectangle survey function). The aircraft will keep sweeping up and down the polygon unless the user manually exits the block or unless an exception is used ([[#Exceptions|see below]]).

The orientation of the sweeps can ranges from north south to east west and any where in between (-90 <-> 90 degrees respectively). The side of the polygon the aircraft starts on (ex. north or south) is determined by the side of the polygon the entry point is located.

<gallery>
Image:PolySurveySweepDef.png|Sweep Definition
Image:PolySurveyEntryPic.png|Entry Point
Image:PolySurveySweepBack.png|Sweeping Back
</gallery>

==== Implementation ====

You can add this navigation routine in your flight plan like so...

{{Box Code|conf/flight_plans/myflightplan.xml|
<source lang="xml">
<block name="Poly Survey">
<call fun="InitializePolygonSurvey(WP_S1, NumOfCorners, SweepWidth, Orientation)"/>
<call fun="PolygonSurvey()"/>
</block>
</source>
}}

The parameters are the entry waypoint, the number of waypoints in the polygon, the sweep width (meters), and the desired orientation of the sweeps (degrees). The maximum number of waypoints a polygon can have is currently ten (can be changed in the code). If the number of waypoints in the polygon exceeds the maximum number, the routine will exit and move to the next block in the flight plan. The routine will also exit if the orientation is not between -90 and 90 degrees.

Here is an example of how you should declare each of the corners of the polygon.

{{Box Code|conf/flight_plans/myflightplan.xml|
<source lang="xml">
<waypoint alt="1453.0" name="S1" x="-546.2" y="297.4"/>
<waypoint alt="1453.0" name="S2" x="-129.8" y="744.1"/>
<waypoint alt="1553.0" name="S3" x="1030.5" y="535.5"/>
<waypoint alt="1453.0" name="S4" x="523.0" y="-236.7"/>
<waypoint alt="1453.0" name="S5" x="-285.9" y="-255.7"/>
</source>
}}

S1 is the entry waypoint and the first corner. The other corners should be in order clockwise or counter clockwise around the polygon. Even though this group of waypoints must be declared together, where the group appears in the list of waypoints doesn't matter.

If you want the edges of the polygon to show up on the GCS, you can also declare the polygon as a sector. This is not required to run the routine.

{{Box Code|conf/flight_plans/myflightplan.xml|
<source lang="xml">
<sectors>
<sector name="PolySector">
<corner name="S1"/>
<corner name="S2"/>
<corner name="S3"/>
<corner name="S4"/>
<corner name="S5"/>
</sector>
</sectors>
</source>
}}

<gallery caption="A Range of Different Sweep Orientations">
Image:PolySurvey0DegreeEx.png|0 Degrees
Image:PolySurvey30DegreeEx.png|30 Degrees
Image:PolySurvey65DegreeEx.png|65 Degrees
Image:PolySurvey90DegreeEx.png|90 Degrees
</gallery>

==== Alternative configurations ====

If you are wanting to start and stop the Poly Survey this is possible by splitting the Poly Survey code above into the initialization routine and the execution routine. You might want to do this if you are searching for something inside the Poly Survey, think you have found it and then realized you haven't, so you want to continue the survey (not restart it). Using the example above, but with the initialisation and execution code separate:

{{Box Code|conf/flight_plans/myflightplan.xml|
<source lang="xml">
<block name="Init Poly Survey">
<call fun="InitializePolygonSurvey(WP_S1, NumOfCorners, SweepWidth, Orientation)"/>
</block>

<block name="Execute Poly Survey">
<call fun="PolygonSurvey()"/>
</block>
</source>
}}

==== Exceptions ====
There are a couple of built in variables which can be used to exit the routine with an exception. PolySurveySweepNum gives the number of sweeps the aircraft has made and PolySurveySweepBackNum gives the number of times the aircraft has gotten to the bottom of the polygon and swept back. The first example would deroute the aircraft to standby after the aircraft made it's second sweep. The second example would deroute the aircraft to standby before it starts to sweep back up the polygon for the first time.

{{Box Code|conf/flight_plans/myflightplan.xml|
<source lang="xml">
<block name="Poly Survey">
<exception cond="PolySurveySweepNum >= 2" deroute="Standby"/>
<call fun="InitializePolygonSurvey(WP_S1, 5, 200, 45)"/>
<call fun="PolygonSurvey()"/>
</block>

<block name="Poly Survey">
<exception cond="PolySurveySweepBackNum >= 1" deroute="Standby"/>
<call fun="InitializePolygonSurvey(WP_S1, 5, 200, 45)"/>
<call fun="PolygonSurvey()"/>
</block>
</source>
}}

=== Flight Line ===
The Flight Line Routine allows the user to map/follow one dimensional areas of interest like roads and rivers. Given two waypoints, the routine will automatically transition into the flight line to ensure full coverage between the waypoints. In addition, distances before and after the flight line can be used to add extra security to the coverage.

[[Image:OSAMFlightLineDiagram.png|Flight Line Diagram]]

To use this navigation routine, you need to include OSAMNav.h in your flight plan and OSAMNav.c to your airframe file. Then add this navigation routine in your flight plan like so...

{{Box Code|conf/flight_plans/myflightplan.xml|
<source lang="xml">
<block name="Map River">
<call fun="FlightLine(WP_R1,WP_R2,nav_radius,distance_before,distance_after)"/>
</block>
</source>
}}

Multiple flight lines can be daisy chained by reusing waypoints as shown below...

{{Box Code|conf/flight_plans/myflightplan.xml|
<source lang="xml">
<block name="Map River">
<call fun="FlightLine(WP_R1,WP_R2,nav_radius,100,100)"/>
<call fun="FlightLine(WP_R2,WP_R3,nav_radius,100,100)"/>
<call fun="FlightLine(WP_R3,WP_R4,nav_radius,100,100)"/>
<call fun="FlightLine(WP_R5,WP_R6,nav_radius,100,100)"/>
<deroute block="Standby"/>
</block>
</source>
}}

However, the previous block can also be implemented using the FlightLineBlock function. The FlightLineBlock function works the same as the FlightLine function except it automatically steps through the waypoints between the given waypoints. Make sure the waypoints are declared in order or else it won't work!

{{Box Code|conf/flight_plans/myflightplan.xml|
<source lang="xml">
<block name="Map River">
<call fun="FlightLineBlock(WP_R1,WP_R6,nav_radius,100,100)"/>
<deroute block="Standby"/>
</block>
</source>
}}

<gallery>
Image:OSAMFlightLineExample.jpg |Multiple Flight Line Example
</gallery>

== misc ==

=== Border line ===

border_line is a nav-routine pretty similar to the nav-line-routine. You can use this nav-routine whenever you want to take care your plane stays on a defined site of a border.
For example you can use this routine to fly along a mountain and always turn away from the mountain ridge wall. Or use it fly along a border road without penetrating the other side of the border.

Use "extra" navigation subsystem with:
<source lang="xml">
<subsystem name="navigation" type="extra"/>
</source>

If you want to use waypoint 1 and 2 you can add border_line in your flight plan like this:
* Include header in "header" section at the beginning
#include "subsystems/navigation/border_line.h"
* Add function in a flight plan block:

{{Box Code|conf/flight_plans/myflightplan.xml|
<source lang="xml">
<block group="extra_pattern" name="border line">
<call fun="border_line_init()"/>
<call fun="border_line(WP_1, WP_2, -nav_radius)"/>
</block>
</source>
}}

<gallery caption="example">
Image:border_line.png|Screen shot of border_line
Image:border_line2.png|Screen shot of border_line2
Image:border_line3.png|Screen shot of border_line3
</gallery>

=== GLS ===

GLS or '''G'''lobal Navigation Satellite System (GNSS) '''L'''anding '''S'''ystem adds advanced landing functions to your flightplan

It add the following capabilities:

# Fly via defined glide path angle
# In flight changeable landing direction without loosing the glide path angle!
# Smooth intercept, independent of approach angle or wind
# Separation of '''a'''pproach '''f'''ix, '''s'''tart '''d'''ecent and '''t'''op '''o'''f '''d'''ecent
# With fixed target speed (in airspeed mode only)

====GLS related abbreviations====

* GLS = '''G'''lobal Navigation Satellite System (GNSS) '''L'''anding '''S'''ystem
* TOD = '''t'''op '''o'''f '''d'''ecent
* AF = '''A'''pproach '''Fix'''
* SD = '''S'''tart '''D'''ecend
* TD = '''T'''ouch '''D'''own point, The spot where the plane should touch the ground for landing

====Configure====

What to add to your airframe.

{{Box Code|conf/flight_plans/myflightplan.xml|
<source lang="xml">
<section name="GLS_APPROACH" prefix="APP_">
<define name="ANGLE" value="5" unit="deg"/>
<define name="INTERCEPT_RATE" value="0.624" unit="m/s/s"/>
<define name="DISTANCE_AF_SD" value="20" unit="m"/>
<define name="TARGET_SPEED" value="14" unit="m/s"/>
</section>
</source>
}}

ANGLE - angle from TOD to TD

DISTANCE_AF_SD - minimum distance (meter) between AF and SD to allow the plane to self stabilize before the intercept starts (e.g. for speed reduction)

You can set the landing direction by moving the approach fix (AF) in relation to the touch down point (TD).
If you try to set the AF close to the TD you will see how the top of decent (TOD) and start decent (SD) is calculated and if necessary the AF is moved backwards.
(please try in simulation)

TARGET_SPEED - desired airspeed from AF to TD

INTERCEPT_RATE -

e.g. no wind: TARGET_SPEED = 14m/s and ANGLE = 10 --> desired decent rate 2.5 m/s (speed * tan(ANGLE))

with an INTERCEPT_RATE of 0.624 m/s/s it will take 4s to intercept the final approach path (desired decent rate / intercept_rate)

the idea is that the INTERCEPT_RATE is unique to each plane and will not change with different approach angles

to find an appropriate value you can start with a lower (to match 8s for example) and increase it until the intercept will be made from above

in general: bigger plane - smaller value!

how to setup your flightplan.xml:

<source lang="xml">
<waypoints>
<waypoint height="150" name="AF" x="-260.6" y="-344.6"/>
<waypoint name="SD" x="-1600." y="-36."/>
<waypoint name="TOD" x="-1600." y="-36."/>
<waypoint height="0.0" name="TD" x="-27.2" y="-243.5"/>
<waypoint height="266.0" name="_BASELEG" x="-1652.1" y="-113.5"/>
</waypoints>

<block name="land">
<call fun="gls_init(WP_AF,WP_SD, WP_TOD, WP_TD)"/>
<call fun="nav_compute_baseleg(WP_AF, WP_TD, WP__BASELEG, nav_radius)"/>
<circle radius="nav_radius" until="NavCircleCount() > 0.5" wp="_BASELEG"/>
<circle radius="nav_radius" until="And(NavQdrCloseTo(DegOfRad(baseleg_out_qdr)-(nav_radius/fabs(nav_radius))*10),
10 > fabs(GetPosAlt() - WaypointAlt(WP__BASELEG)))" wp="_BASELEG"/>
</block>

<block name="final">
<exception cond="ground_alt + 10 > estimator_z" deroute="flare"/>
<call fun="gls(WP_AF,WP_SD, WP_TOD, WP_TD)"/>
</block>
</source>

those pictures match the old gls routine! anyway - the new one is not much different... (POS I = SD)
<gallery caption="theory">
Image:gls1.png|side view
Image:gls2.png|from above
Image:gls3.png|screen shot of flight test
</gallery>

== Multi-UAV ==
For TCAS (Traffic Collision Avoidance System) see the [[MultiUAV]] page.

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

= Create a navigation module =

Creating a navigation module is not to complex. Have said that, it is not very likely to need to create one module oneself. The already available functions are very flexible and powerful. Before you set of to create and additional navigation module, make sure you understand all current modules and their capabilities. After you investigated current modules and came to the conclusion, there is no way to solve you flightplan mission by creating a new module, go ahead and plz share your work with the community. The more people test the new module, the faster it will reach a stable state.

Advanced Navigation Routines

2016-10-27T15:47:20Z

IHaveADrone: xml box code

= Introduction =

The flight plan standard navigation functions are very flexible. However sometimes one needs to perform a very specific task, and the basic functions are not enough to accomplish a special mission. In that case you can use additional modules functions in the flight plan. By adding a navigation capability to your airframe. The flight plan now has extra functionality that can be used.

= Available navigation modules =

== Navigation Routines (Prev.OSAM) ==

Thanks to Team OSAM's contribution these navigation capabilities have been added.

To use these navigation routines, you need to change the navigation subsystem type to extra in your airframe file. The navigation extra subsystem includes extra navigation routines like OSAMnav, spiral, poly_survey_advanced, nav_cube, etc.

<source lang="xml">
<subsystem name="navigation" type="extra"/>
</source>

Also include OSAMNav.h in your flight plan:

<source lang="xml">
#include "subsystems/navigation/OSAMNav.h"
</source>

== Flower ==
[[Image:FlowerScreenShot.png|thumb|Screen shot of flower routine]]
The flower navigation routine flies the aircraft in a flower pattern defined by two waypoints. The center waypoint defines the center of the flower and the altitude the plane flies at. The edge waypoint defines the radius of the flower.

In our example the waypoints are called "Center" and "Edge":

{{Box Code|conf/flight_plans/myflightplan.xml|
<source lang="xml">
<waypoint name="Center" x="-20.0" y="-160.0"/>
<waypoint name="Edge" x="-10.0" y="-60.0"/>
</source>
}}

Then you can add flower to your flight plan:

{{Box Code|conf/flight_plans/myflightplan.xml|
<source lang="xml">
<block name="Flower">
<call fun="InitializeFlower(WP_Center,WP_Edge)"/>
<call fun="FlowerNav()"/>
</block>
</source>
}}

Note that in the function InitializeFlower the waypoints need the prefix "WP_".

== Bungee Takeoff ==

The bungee takeoff routine helps to automate takeoff by turning the throttle on after the bungee has been release from the hook. The only waypoint you need for this routine is the position of where the bungee is pegged to the ground. Using this waypoint, a line is drawn from the position of the aircraft to the bungee waypoint. This line is called the launch line and will stop updating once the speed of the plane exceeds the MinSpeed. This allows the user to initialize the routine, move the plane and launch it without having to reinitialize. Once the plane is launched, it will follow the launch line until it crosses the throttle line. The throttle line is a line perpendicular to the launch line at a distance d from the bungee waypoint (see the diagram below). When the plane crosses the throttle line and the speed of the aircraft is greater than MinSpeed, the throttle comes on. After the throttle comes on, the plane keeps going straight until it reaches a specified speed and altitude above the bungee waypoint altitude. When it reaches the takeoff speed and takeoff altitude, the next block in the flight plan is executed. The takeoff speed, takeoff altitude, MinSpeed and the distance d from the bungee waypoint are specified in the airframe file. You will need to add those values to your airframe file like this...

{{Box Code|conf/flight_plans/myflightplan.xml|
<source lang="xml">
<section name="Takeoff" prefix="Takeoff_">
<define name="Height" value="30" unit="m"/>
<define name="Speed" value="15" unit="m/s"/>
<define name="Distance" value="3" unit="m"/>
<define name="MinSpeed" value="5" unit="m/s"/>
</section>
</source>
}}

You can add the bungee takeoff routine to your flight plan like so...

{{Box Code|conf/flight_plans/myflightplan.xml|
<source lang="xml">
<block name="Takeoff" strip_button="Takeoff (wp CLIMB)" strip_icon="takeoff.png">
<call fun="InitializeBungeeTakeoff(WP_Bungee)"/>
<call fun="BungeeTakeoff()"/>
</block>
</source>
}}

To get this routine to work consistently, you will need to tune the values in the airframe config file. If the prop doesn't automatically turn on when it crosses the throttle line, it could be because the Distance and/or the MinSpeed are too big. If it turns on to early, it could be because the Distance and/or MinSpeed are too small.

<span style="color:#ff0000"> ***Precaution should be taken while tuning the auto takeoff with electrical plane. If the MinSpeed is too low, the prop could turn on while holding the aircraft!***</span>

<gallery>
Image:BungeeTakeoffDiagram.png|Bungee takeoff diagram
Image:BungeeTakeoffInit.png|After bungee takeoff initialization
Image:BungeeTakeoffThrottleOn.png|After crossing the throttle line
</gallery>

== Polygon Survey ==
=== Explanation ===
With this navigation routine, an aircraft can survey the area of any [http://en.wikipedia.org/wiki/Convex_polygon convex polygon] given an entry point, the number of waypoints which define the polygon, the sweep width and the desired orientation of the sweeps.

The entry point is the first corner of the polygon and the point at which the aircraft will begin surveying the area. When in the entry state, the aircraft will circle around the entry point in order to smoothly transition into the first sweep. The aircraft will also keep circling around the entry point until it gets to the waypoint altitude. After the first sweep is made, the direction of the next sweep is determined by the distance of the entry point to the edges of the polygon. If there is more area above the first sweep, the aircraft will sweep up. If there is more area below the first sweep, the aircraft will sweep down.

The aircraft will keep sweeping back and forth until it reaches the end of the polygon. At this point, the aircraft will sweep back up/down the polygon halfway in between the sweeps previously made by the aircraft (just like the rectangle survey function). The aircraft will keep sweeping up and down the polygon unless the user manually exits the block or unless an exception is used ([[#Exceptions|see below]]).

The orientation of the sweeps can ranges from north south to east west and any where in between (-90 <-> 90 degrees respectively). The side of the polygon the aircraft starts on (ex. north or south) is determined by the side of the polygon the entry point is located.

<gallery>
Image:PolySurveySweepDef.png|Sweep Definition
Image:PolySurveyEntryPic.png|Entry Point
Image:PolySurveySweepBack.png|Sweeping Back
</gallery>

==== Implementation ====

You can add this navigation routine in your flight plan like so...

{{Box Code|conf/flight_plans/myflightplan.xml|
<source lang="xml">
<block name="Poly Survey">
<call fun="InitializePolygonSurvey(WP_S1, NumOfCorners, SweepWidth, Orientation)"/>
<call fun="PolygonSurvey()"/>
</block>
</source>
}}

The parameters are the entry waypoint, the number of waypoints in the polygon, the sweep width (meters), and the desired orientation of the sweeps (degrees). The maximum number of waypoints a polygon can have is currently ten (can be changed in the code). If the number of waypoints in the polygon exceeds the maximum number, the routine will exit and move to the next block in the flight plan. The routine will also exit if the orientation is not between -90 and 90 degrees.

Here is an example of how you should declare each of the corners of the polygon.

{{Box Code|conf/flight_plans/myflightplan.xml|
<source lang="xml">
<waypoint alt="1453.0" name="S1" x="-546.2" y="297.4"/>
<waypoint alt="1453.0" name="S2" x="-129.8" y="744.1"/>
<waypoint alt="1553.0" name="S3" x="1030.5" y="535.5"/>
<waypoint alt="1453.0" name="S4" x="523.0" y="-236.7"/>
<waypoint alt="1453.0" name="S5" x="-285.9" y="-255.7"/>
</source>
}}

S1 is the entry waypoint and the first corner. The other corners should be in order clockwise or counter clockwise around the polygon. Even though this group of waypoints must be declared together, where the group appears in the list of waypoints doesn't matter.

If you want the edges of the polygon to show up on the GCS, you can also declare the polygon as a sector. This is not required to run the routine.

{{Box Code|conf/flight_plans/myflightplan.xml|
<source lang="xml">
<sectors>
<sector name="PolySector">
<corner name="S1"/>
<corner name="S2"/>
<corner name="S3"/>
<corner name="S4"/>
<corner name="S5"/>
</sector>
</sectors>
</source>
}}

<gallery caption="A Range of Different Sweep Orientations">
Image:PolySurvey0DegreeEx.png|0 Degrees
Image:PolySurvey30DegreeEx.png|30 Degrees
Image:PolySurvey65DegreeEx.png|65 Degrees
Image:PolySurvey90DegreeEx.png|90 Degrees
</gallery>

==== Alternative configurations ====

If you are wanting to start and stop the Poly Survey this is possible by splitting the Poly Survey code above into the initialization routine and the execution routine. You might want to do this if you are searching for something inside the Poly Survey, think you have found it and then realized you haven't, so you want to continue the survey (not restart it). Using the example above, but with the initialisation and execution code separate:

{{Box Code|conf/flight_plans/myflightplan.xml|
<source lang="xml">
<block name="Init Poly Survey">
<call fun="InitializePolygonSurvey(WP_S1, NumOfCorners, SweepWidth, Orientation)"/>
</block>

<block name="Execute Poly Survey">
<call fun="PolygonSurvey()"/>
</block>
</source>
}}

==== Exceptions ====
There are a couple of built in variables which can be used to exit the routine with an exception. PolySurveySweepNum gives the number of sweeps the aircraft has made and PolySurveySweepBackNum gives the number of times the aircraft has gotten to the bottom of the polygon and swept back. The first example would deroute the aircraft to standby after the aircraft made it's second sweep. The second example would deroute the aircraft to standby before it starts to sweep back up the polygon for the first time.

{{Box Code|conf/flight_plans/myflightplan.xml|
<source lang="xml">
<block name="Poly Survey">
<exception cond="PolySurveySweepNum >= 2" deroute="Standby"/>
<call fun="InitializePolygonSurvey(WP_S1, 5, 200, 45)"/>
<call fun="PolygonSurvey()"/>
</block>

<block name="Poly Survey">
<exception cond="PolySurveySweepBackNum >= 1" deroute="Standby"/>
<call fun="InitializePolygonSurvey(WP_S1, 5, 200, 45)"/>
<call fun="PolygonSurvey()"/>
</block>
</source>
}}

=== Flight Line ===
The Flight Line Routine allows the user to map/follow one dimensional areas of interest like roads and rivers. Given two waypoints, the routine will automatically transition into the flight line to ensure full coverage between the waypoints. In addition, distances before and after the flight line can be used to add extra security to the coverage.

[[Image:OSAMFlightLineDiagram.png|Flight Line Diagram]]

To use this navigation routine, you need to include OSAMNav.h in your flight plan and OSAMNav.c to your airframe file. Then add this navigation routine in your flight plan like so...

{{Box Code|conf/flight_plans/myflightplan.xml|
<source lang="xml">
<block name="Map River">
<call fun="FlightLine(WP_R1,WP_R2,nav_radius,distance_before,distance_after)"/>
</block>
</source>
}}

Multiple flight lines can be daisy chained by reusing waypoints as shown below...

{{Box Code|conf/flight_plans/myflightplan.xml|
<source lang="xml">
<block name="Map River">
<call fun="FlightLine(WP_R1,WP_R2,nav_radius,100,100)"/>
<call fun="FlightLine(WP_R2,WP_R3,nav_radius,100,100)"/>
<call fun="FlightLine(WP_R3,WP_R4,nav_radius,100,100)"/>
<call fun="FlightLine(WP_R5,WP_R6,nav_radius,100,100)"/>
<deroute block="Standby"/>
</block>
</source>
}}

However, the previous block can also be implemented using the FlightLineBlock function. The FlightLineBlock function works the same as the FlightLine function except it automatically steps through the waypoints between the given waypoints. Make sure the waypoints are declared in order or else it won't work!

{{Box Code|conf/flight_plans/myflightplan.xml|
<source lang="xml">
<block name="Map River">
<call fun="FlightLineBlock(WP_R1,WP_R6,nav_radius,100,100)"/>
<deroute block="Standby"/>
</block>
</source>
}}

<gallery>
Image:OSAMFlightLineExample.jpg |Multiple Flight Line Example
</gallery>

== misc ==

=== Border line ===

border_line is a nav-routine pretty similar to the nav-line-routine. You can use this nav-routine whenever you want to take care your plane stays on a defined site of a border.
For example you can use this routine to fly along a mountain and always turn away from the mountain ridge wall. Or use it fly along a border road without penetrating the other side of the border.

Use "extra" navigation subsystem with:
<source lang="xml">
<subsystem name="navigation" type="extra"/>
</source>

If you want to use waypoint 1 and 2 you can add border_line in your flight plan like this:
* Include header in "header" section at the beginning
#include "subsystems/navigation/border_line.h"
* Add function in a flight plan block:

{{Box Code|conf/flight_plans/myflightplan.xml|
<source lang="xml">
<block group="extra_pattern" name="border line">
<call fun="border_line_init()"/>
<call fun="border_line(WP_1, WP_2, -nav_radius)"/>
</block>
</source>
}}

<gallery caption="example">
Image:border_line.png|Screen shot of border_line
Image:border_line2.png|Screen shot of border_line2
Image:border_line3.png|Screen shot of border_line3
</gallery>

=== GLS ===

GLS or '''G'''lobal Navigation Satellite System (GNSS) '''L'''anding '''S'''ystem adds advanced landing functions to your flightplan

It add the following capabilities:

# Fly via defined glide path angle
# In flight changeable landing direction without loosing the glide path angle!
# Smooth intercept, independent of approach angle or wind
# Separation of '''a'''pproach '''f'''ix, '''s'''tart '''d'''ecent and '''t'''op '''o'''f '''d'''ecent
# With fixed target speed (in airspeed mode only)

====GLS related abbreviations====

* GLS = '''G'''lobal Navigation Satellite System (GNSS) '''L'''anding '''S'''ystem
* TOD = '''t'''op '''o'''f '''d'''ecent
* AF = '''A'''pproach '''Fix'''
* SD = '''S'''tart '''D'''ecend
* TD = '''T'''ouch '''D'''own point, The spot where the plane should touch the ground for landing

====Configure====

What to add to your airframe.

{{Box Code|conf/flight_plans/myflightplan.xml|
<source lang="xml">
<section name="GLS_APPROACH" prefix="APP_">
<define name="ANGLE" value="5" unit="deg"/>
<define name="INTERCEPT_RATE" value="0.624" unit="m/s/s"/>
<define name="DISTANCE_AF_SD" value="20" unit="m"/>
<define name="TARGET_SPEED" value="14" unit="m/s"/>
</section>
</source>
}}

ANGLE - angle from TOD to TD

DISTANCE_AF_SD - minimum distance (meter) between AF and SD to allow the plane to self stabilize before the intercept starts (e.g. for speed reduction)

You can set the landing direction by moving the approach fix (AF) in relation to the touch down point (TD).
If you try to set the AF close to the TD you will see how the top of decent (TOD) and start decent (SD) is calculated and if necessary the AF is moved backwards.
(please try in simulation)

TARGET_SPEED - desired airspeed from AF to TD

INTERCEPT_RATE -

e.g. no wind: TARGET_SPEED = 14m/s and ANGLE = 10 --> desired decent rate 2.5 m/s (speed * tan(ANGLE))

with an INTERCEPT_RATE of 0.624 m/s/s it will take 4s to intercept the final approach path (desired decent rate / intercept_rate)

the idea is that the INTERCEPT_RATE is unique to each plane and will not change with different approach angles

to find an appropriate value you can start with a lower (to match 8s for example) and increase it until the intercept will be made from above

in general: bigger plane - smaller value!

how to setup your flightplan.xml:

<source lang="xml">
<waypoints>
<waypoint height="150" name="AF" x="-260.6" y="-344.6"/>
<waypoint name="SD" x="-1600." y="-36."/>
<waypoint name="TOD" x="-1600." y="-36."/>
<waypoint height="0.0" name="TD" x="-27.2" y="-243.5"/>
<waypoint height="266.0" name="_BASELEG" x="-1652.1" y="-113.5"/>
</waypoints>

<block name="land">
<call fun="gls_init(WP_AF,WP_SD, WP_TOD, WP_TD)"/>
<call fun="nav_compute_baseleg(WP_AF, WP_TD, WP__BASELEG, nav_radius)"/>
<circle radius="nav_radius" until="NavCircleCount() > 0.5" wp="_BASELEG"/>
<circle radius="nav_radius" until="And(NavQdrCloseTo(DegOfRad(baseleg_out_qdr)-(nav_radius/fabs(nav_radius))*10),
10 > fabs(GetPosAlt() - WaypointAlt(WP__BASELEG)))" wp="_BASELEG"/>
</block>

<block name="final">
<exception cond="ground_alt + 10 > estimator_z" deroute="flare"/>
<call fun="gls(WP_AF,WP_SD, WP_TOD, WP_TD)"/>
</block>
</source>

those pictures match the old gls routine! anyway - the new one is not much different... (POS I = SD)
<gallery caption="theory">
Image:gls1.png|side view
Image:gls2.png|from above
Image:gls3.png|screen shot of flight test
</gallery>

== Multi-UAV ==
For TCAS (Traffic Collision Avoidance System) see the [[MultiUAV]] page.

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

= Create a navigation module =

Creating a navigation module is not to complex. Have said that, it is not very likely to need to create one module oneself. The already available functions are very flexible and powerful. Before you set of to create and additional navigation module, make sure you understand all current modules and their capabilities. After you investigated current modules and came to the conclusion, there is no way to solve you flightplan mission by creating a new module, go ahead and plz share your work with the community. The more people test the new module, the faster it will reach a stable state.

Advanced Navigation Routines

2016-10-27T15:30:29Z

IHaveADrone: /* Flower */ xml box code

= Introduction =

The flight plan standard navigation functions are very flexible. However sometimes one needs to perform a very specific task, and the basic functions are not enough to accomplish a special mission. In that case you can use additional modules functions in the flight plan. By adding a navigation capability to your airframe. The flight plan now has extra functionality that can be used.

= Available navigation modules =

== Navigation Routines (Prev.OSAM) ==

Thanks to Team OSAM's contribution these navigation capabilities have been added.

To use these navigation routines, you need to change the navigation subsystem type to extra in your airframe file. The navigation extra subsystem includes extra navigation routines like OSAMnav, spiral, poly_survey_advanced, nav_cube, etc.
<subsystem name="navigation" type="extra"/>

Also include OSAMNav.h in your flight plan:

#include "subsystems/navigation/OSAMNav.h"

== Flower ==
[[Image:FlowerScreenShot.png|thumb|Screen shot of flower routine]]
The flower navigation routine flies the aircraft in a flower pattern defined by two waypoints. The center waypoint defines the center of the flower and the altitude the plane flies at. The edge waypoint defines the radius of the flower.

In our example the waypoints are called "Center" and "Edge":

{{Box Code|conf/flight_plans/myflightplan.xml|
<source lang="xml">
<waypoint name="Center" x="-20.0" y="-160.0"/>
<waypoint name="Edge" x="-10.0" y="-60.0"/>
</source>
}}

Then you can add flower to your flight plan:

{{Box Code|conf/flight_plans/myflightplan.xml|
<source lang="xml">
<block name="Flower">
<call fun="InitializeFlower(WP_Center,WP_Edge)"/>
<call fun="FlowerNav()"/>
</block>
</source>
}}

Note that in the function InitializeFlower the waypoints need the prefix "WP_".

== Bungee Takeoff ==

The bungee takeoff routine helps to automate takeoff by turning the throttle on after the bungee has been release from the hook. The only waypoint you need for this routine is the position of where the bungee is pegged to the ground. Using this waypoint, a line is drawn from the position of the aircraft to the bungee waypoint. This line is called the launch line and will stop updating once the speed of the plane exceeds the MinSpeed. This allows the user to initialize the routine, move the plane and launch it without having to reinitialize. Once the plane is launched, it will follow the launch line until it crosses the throttle line. The throttle line is a line perpendicular to the launch line at a distance d from the bungee waypoint (see the diagram below). When the plane crosses the throttle line and the speed of the aircraft is greater than MinSpeed, the throttle comes on. After the throttle comes on, the plane keeps going straight until it reaches a specified speed and altitude above the bungee waypoint altitude. When it reaches the takeoff speed and takeoff altitude, the next block in the flight plan is executed. The takeoff speed, takeoff altitude, MinSpeed and the distance d from the bungee waypoint are specified in the airframe file. You will need to add those values to your airframe file like this...

<section name="Takeoff" prefix="Takeoff_">
<define name="Height" value="30" unit="m"/>
<define name="Speed" value="15" unit="m/s"/>
<define name="Distance" value="3" unit="m"/>
<define name="MinSpeed" value="5" unit="m/s"/>
</section>

You can add the bungee takeoff routine to your flight plan like so...

<block name="Takeoff" strip_button="Takeoff (wp CLIMB)" strip_icon="takeoff.png">
<call fun="InitializeBungeeTakeoff(WP_Bungee)"/>
<call fun="BungeeTakeoff()"/>
</block>

To get this routine to work consistently, you will need to tune the values in the airframe config file. If the prop doesn't automatically turn on when it crosses the throttle line, it could be because the Distance and/or the MinSpeed are too big. If it turns on to early, it could be because the Distance and/or MinSpeed are too small.

<span style="color:#ff0000"> ***Precaution should be taken while tuning the auto takeoff with electrical plane. If the MinSpeed is too low, the prop could turn on while holding the aircraft!***</span>

<gallery>
Image:BungeeTakeoffDiagram.png|Bungee takeoff diagram
Image:BungeeTakeoffInit.png|After bungee takeoff initialization
Image:BungeeTakeoffThrottleOn.png|After crossing the throttle line
</gallery>

== Polygon Survey ==
=== Explanation ===
With this navigation routine, an aircraft can survey the area of any [http://en.wikipedia.org/wiki/Convex_polygon convex polygon] given an entry point, the number of waypoints which define the polygon, the sweep width and the desired orientation of the sweeps.

The entry point is the first corner of the polygon and the point at which the aircraft will begin surveying the area. When in the entry state, the aircraft will circle around the entry point in order to smoothly transition into the first sweep. The aircraft will also keep circling around the entry point until it gets to the waypoint altitude. After the first sweep is made, the direction of the next sweep is determined by the distance of the entry point to the edges of the polygon. If there is more area above the first sweep, the aircraft will sweep up. If there is more area below the first sweep, the aircraft will sweep down.

The aircraft will keep sweeping back and forth until it reaches the end of the polygon. At this point, the aircraft will sweep back up/down the polygon halfway in between the sweeps previously made by the aircraft (just like the rectangle survey function). The aircraft will keep sweeping up and down the polygon unless the user manually exits the block or unless an exception is used ([[#Exceptions|see below]]).

The orientation of the sweeps can ranges from north south to east west and any where in between (-90 <-> 90 degrees respectively). The side of the polygon the aircraft starts on (ex. north or south) is determined by the side of the polygon the entry point is located.

<gallery>
Image:PolySurveySweepDef.png|Sweep Definition
Image:PolySurveyEntryPic.png|Entry Point
Image:PolySurveySweepBack.png|Sweeping Back
</gallery>

==== Implementation ====

You can add this navigation routine in your flight plan like so...

<block name="Poly Survey">
<call fun="InitializePolygonSurvey(WP_S1, NumOfCorners, SweepWidth, Orientation)"/>
<call fun="PolygonSurvey()"/>
</block>

The parameters are the entry waypoint, the number of waypoints in the polygon, the sweep width (meters), and the desired orientation of the sweeps (degrees). The maximum number of waypoints a polygon can have is currently ten (can be changed in the code). If the number of waypoints in the polygon exceeds the maximum number, the routine will exit and move to the next block in the flight plan. The routine will also exit if the orientation is not between -90 and 90 degrees.

Here is an example of how you should declare each of the corners of the polygon.

<waypoint alt="1453.0" name="S1" x="-546.2" y="297.4"/>
<waypoint alt="1453.0" name="S2" x="-129.8" y="744.1"/>
<waypoint alt="1553.0" name="S3" x="1030.5" y="535.5"/>
<waypoint alt="1453.0" name="S4" x="523.0" y="-236.7"/>
<waypoint alt="1453.0" name="S5" x="-285.9" y="-255.7"/>

S1 is the entry waypoint and the first corner. The other corners should be in order clockwise or counter clockwise around the polygon. Even though this group of waypoints must be declared together, where the group appears in the list of waypoints doesn't matter.

If you want the edges of the polygon to show up on the GCS, you can also declare the polygon as a sector. This is not required to run the routine.

<sectors>
<sector name="PolySector">
<corner name="S1"/>
<corner name="S2"/>
<corner name="S3"/>
<corner name="S4"/>
<corner name="S5"/>
</sector>
</sectors>

<gallery caption="A Range of Different Sweep Orientations">
Image:PolySurvey0DegreeEx.png|0 Degrees
Image:PolySurvey30DegreeEx.png|30 Degrees
Image:PolySurvey65DegreeEx.png|65 Degrees
Image:PolySurvey90DegreeEx.png|90 Degrees
</gallery>

==== Alternative configurations ====

If you are wanting to start and stop the Poly Survey this is possible by splitting the Poly Survey code above into the initialization routine and the execution routine. You might want to do this if you are searching for something inside the Poly Survey, think you have found it and then realized you haven't, so you want to continue the survey (not restart it). Using the example above, but with the initialisation and execution code separate:

<block name="Init Poly Survey">
<call fun="InitializePolygonSurvey(WP_S1, NumOfCorners, SweepWidth, Orientation)"/>
</block>

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

==== Exceptions ====
There are a couple of built in variables which can be used to exit the routine with an exception. PolySurveySweepNum gives the number of sweeps the aircraft has made and PolySurveySweepBackNum gives the number of times the aircraft has gotten to the bottom of the polygon and swept back. The first example would deroute the aircraft to standby after the aircraft made it's second sweep. The second example would deroute the aircraft to standby before it starts to sweep back up the polygon for the first time.

<block name="Poly Survey">
<exception cond="PolySurveySweepNum >= 2" deroute="Standby"/>
<call fun="InitializePolygonSurvey(WP_S1, 5, 200, 45)"/>
<call fun="PolygonSurvey()"/>
</block>

<block name="Poly Survey">
<exception cond="PolySurveySweepBackNum >= 1" deroute="Standby"/>
<call fun="InitializePolygonSurvey(WP_S1, 5, 200, 45)"/>
<call fun="PolygonSurvey()"/>
</block>

=== Flight Line ===
The Flight Line Routine allows the user to map/follow one dimensional areas of interest like roads and rivers. Given two waypoints, the routine will automatically transition into the flight line to ensure full coverage between the waypoints. In addition, distances before and after the flight line can be used to add extra security to the coverage.

[[Image:OSAMFlightLineDiagram.png|Flight Line Diagram]]

To use this navigation routine, you need to include OSAMNav.h in your flight plan and OSAMNav.c to your airframe file. Then add this navigation routine in your flight plan like so...

<block name="Map River">
<call fun="FlightLine(WP_R1,WP_R2,nav_radius,distance_before,distance_after)"/>
</block>

Multiple flight lines can be daisy chained by reusing waypoints as shown below...

<block name="Map River">
<call fun="FlightLine(WP_R1,WP_R2,nav_radius,100,100)"/>
<call fun="FlightLine(WP_R2,WP_R3,nav_radius,100,100)"/>
<call fun="FlightLine(WP_R3,WP_R4,nav_radius,100,100)"/>
<call fun="FlightLine(WP_R5,WP_R6,nav_radius,100,100)"/>
<deroute block="Standby"/>
</block>

However, the previous block can also be implemented using the FlightLineBlock function. The FlightLineBlock function works the same as the FlightLine function except it automatically steps through the waypoints between the given waypoints. Make sure the waypoints are declared in order or else it won't work!

<block name="Map River">
<call fun="FlightLineBlock(WP_R1,WP_R6,nav_radius,100,100)"/>
<deroute block="Standby"/>
</block>

<gallery>
Image:OSAMFlightLineExample.jpg |Multiple Flight Line Example
</gallery>

== misc ==

=== Border line ===

border_line is a nav-routine pretty similar to the nav-line-routine. You can use this nav-routine whenever you want to take care your plane stays on a defined site of a border.
For example you can use this routine to fly along a mountain and always turn away from the mountain ridge wall. Or use it fly along a border road without penetrating the other side of the border.

Use "extra" navigation subsystem with:
<subsystem name="navigation" type="extra"/>

If you want to use waypoint 1 and 2 you can add border_line in your flight plan like this:
* Include header in "header" section at the beginning
#include "subsystems/navigation/border_line.h"
* Add function in a flight plan block:
<block group="extra_pattern" name="border line">
<call fun="border_line_init()"/>
<call fun="border_line(WP_1, WP_2, -nav_radius)"/>
</block>

<gallery caption="example">
Image:border_line.png|Screen shot of border_line
Image:border_line2.png|Screen shot of border_line2
Image:border_line3.png|Screen shot of border_line3
</gallery>

=== GLS ===

GLS or '''G'''lobal Navigation Satellite System (GNSS) '''L'''anding '''S'''ystem adds advanced landing functions to your flightplan

It add the following capabilities:

# Fly via defined glide path angle
# In flight changeable landing direction without loosing the glide path angle!
# Smooth intercept, independent of approach angle or wind
# Separation of '''a'''pproach '''f'''ix, '''s'''tart '''d'''ecent and '''t'''op '''o'''f '''d'''ecent
# With fixed target speed (in airspeed mode only)

====GLS related abbriviations====

* GLS = '''G'''lobal Navigation Satellite System (GNSS) '''L'''anding '''S'''ystem
* TOD = '''t'''op '''o'''f '''d'''ecent
* AF = '''A'''pproach '''Fix'''
* SD = '''S'''tart '''D'''ecend
* TD = '''T'''ouch '''D'''own point, The spot wherethe plane should touch the ground for landing

====Configure====

What to add to your airframe.

<section name="GLS_APPROACH" prefix="APP_">
<define name="ANGLE" value="5" unit="deg"/>
<define name="INTERCEPT_RATE" value="0.624" unit="m/s/s"/>
<define name="DISTANCE_AF_SD" value="20" unit="m"/>
<define name="TARGET_SPEED" value="14" unit="m/s"/>
</section>

ANGLE - angle from TOD to TD

DISTANCE_AF_SD - minimum distance (meter) between AF and SD to allow the plane to self stabilize before the intercept starts (e.g. for speed reduction)

You can set the landing direction by moving the approach fix (AF) in relation to the touch down point (TD).
If you try to set the AF close to the TD you will see how the top of decent (TOD) and start decent (SD) is calculated and if necessary the AF is moved backwards.
(please try in simulation)

TARGET_SPEED - desired airspeed from AF to TD

INTERCEPT_RATE -

e.g. no wind: TARGET_SPEED = 14m/s and ANGLE = 10 --> desired decent rate 2.5 m/s (speed * tan(ANGLE))

with an INTERCEPT_RATE of 0.624 m/s/s it will take 4s to intercept the final approach path (desired decent rate / intercept_rate)

the idea is that the INTERCEPT_RATE is unique to each plane and will not change with different approach angles

to find an appropriate value you can start with a lower (to match 8s for example) and increase it until the intercept will be made from above

in general: bigger plane - smaller value!

how to setup your flightplan.xml:

<waypoints>
<waypoint height="150" name="AF" x="-260.6" y="-344.6"/>
<waypoint name="SD" x="-1600." y="-36."/>
<waypoint name="TOD" x="-1600." y="-36."/>
<waypoint height="0.0" name="TD" x="-27.2" y="-243.5"/>
<waypoint height="266.0" name="_BASELEG" x="-1652.1" y="-113.5"/>
</waypoints>

<block name="land">
<call fun="gls_init(WP_AF,WP_SD, WP_TOD, WP_TD)"/>
<call fun="nav_compute_baseleg(WP_AF, WP_TD, WP__BASELEG, nav_radius)"/>
<circle radius="nav_radius" until="NavCircleCount() > 0.5" wp="_BASELEG"/>
<circle radius="nav_radius" until="And(NavQdrCloseTo(DegOfRad(baseleg_out_qdr)-(nav_radius/fabs(nav_radius))*10),
10 > fabs(GetPosAlt() - WaypointAlt(WP__BASELEG)))" wp="_BASELEG"/>
</block>

<block name="final">
<exception cond="ground_alt + 10 > estimator_z" deroute="flare"/>
<call fun="gls(WP_AF,WP_SD, WP_TOD, WP_TD)"/>
</block>

those pictures match the old gls routine! anyway - the new one is not much different... (POS I = SD)
<gallery caption="theory">
Image:gls1.png|side view
Image:gls2.png|from above
Image:gls3.png|screen shot of flight test
</gallery>

== Multi-UAV ==
For TCAS (Traffic Collision Avoidance System) see the [[MultiUAV]] page.

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

= Create a navigation module =

Creating a navigation module is not to complex. Have said that, it is not very likely to need to create one module oneself. The already available functions are very flexible and powerful. Before you set of to create and additional navigation module, make sure you understand all current modules and their capabilities. After you investigated current modules and came to the conclusion, there is no way to solve you flightplan mission by creating a new module, go ahead and plz share your work with the community. The more people test the new module, the faster it wll reach a stable state.

Input2Ivy

2016-09-15T17:00:31Z

IHaveADrone: spelling

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

'''Input2Ivy''' is an [[Ivy]] agent written in Ocaml/C used to read inputs coming from [[Joystick|joysticks or joypads]] and to send Ivy messages accordingly.

= Compiling Input2Ivy =

The program is located in <tt>sw/ground_segment/joystick</tt>. It should already be compiled with the top level make, you also can explicitly build it with <tt>make</tt> in <tt>sw/ground_segment/joystick</tt>

* the C library sdl_stick (using SDL)
* input2ivy (ocaml main program that uses sdl_stick)
* test_stick (a small C test program that display raw values of your joystick)

= Configuration and use =

== Xml configuration file ==

Input2Ivy reads the configuration of your input device in a xml file located in <tt>conf/joystick</tt>. The format is as follow:
<source lang="xml">
<joystick>
</source>
Start with the node 'joystick', no DTD yet.

<source lang="xml">
<input>
<axis index="0" name="roll"/>
<axis index="1" name="pitch"/>
<axis index="2" name="throttle"/>
...
<button index="0" name="shoot"/>
<button index="1" name="button1"/>
<button index="2" name="button2"/>
...
</input>
</source>

In this section, all the axis and buttons are described with an index and a name. Both have to be unique.
* the index is the actual axis or button number of your input device (you can use 'test_stick' to determine each index)
* the name is chosen by the user

<source lang="xml">
<variables>
<var name="mode" default="0"/>
<set var="mode" value="0" on_event="button1"/>
<set var="mode" value="1" on_event="button2 && shoot"/>
...
</variables>
</source>
The section 'variables' allows to declare local variables to the program, those value can be changed based on inputs event. First you need to declare the variable with a default value (integer) and then each event is describe with the 'set' node. It is possible to use logical "C-like" expression for the event (&&, ||, <, >, ...).

<source lang="xml">
<messages period="0.1">
<message class="datalink" name="RC_4CH" send_always="true">
<field name="mode" value="mode"/>
<field name="throttle" value="Bound(0-ly,0,127)"/>
<field name="roll" value="roll"/>
<field name="yaw" value="yaw"/>
<field name="pitch" value="pitch"/>
</message>
<message class="ground" name="JUMP_TO_BLOCK" on_event="shoot && button1"/>
<field name="block_id" value="IndexOfBlock('land')"/>
</message>
<message class="ground" name="DL_SETTING" on_event="button2">
<field name="index" value="IndexOfSetting(kill_throttle)"/>
<field name="value" value="1"/>
</message>
...
</messages>
</source>
The 'messages' section describes the messages sent to [[Ivy]].
* the 'period' attribute define the period for sending the messages. A message is send only the at least one of its field has changed since last sending. Only messages with 'send_always="true"' are always sent.
* the 'message' node attributes are:
** class: the class of the message (defined in conf/messages.xml) (mandatory)
** name: the name of the message (defined in conf/messages.xml) (mandatory)
** send_always: always send message the 'period' frequency if set to "true" (optional)
* the 'messages' children are the field of the message as describe in conf/messages.xml, except for the field 'ac_id' that is automatically set if needed.
* the 'field' node attributes are:
** name: the name of the field (mandatory)
** value: the value to be sent (here, expressions can be used, see below) (mandatory)
<source lang="xml">
</joystick>
</source>
Close 'joystick' node.

== Expressions and functions ==

* parenthesis: (, )
* operators: +, -, *, % (divide, / is not allowed)
* logical, comparator: &&, ||, <, >
* functions:
** Scale(x, min, max): scale the value in the given bounds (input bounds are [-127, 127]
** Fit(x, min, max, min_input, max_input): some as 'Scale' with custom input bounds
** Bound(x, min, max): bound the value between [min,max]
** PprzMode(x): returns '''0''' if input is less than -127/2, '''2''' if greater than 127/2, '''1''' otherwise
** JoystickId(): returns the joystick ID

== Trims ==
First calibrate your joystick as described on the [[Joystick]] page.

In flight trimming is to be done...

= Usage =

$ ./sw/ground_segment/joystick/input2ivy [options] config_file.xml

The options are:
* -ac <AC name> the name of your aircraft (mandatory)
* -b <ivy_bus> the an ivy bus address (default address used if not set)
* -d <device_index> set the SDL device index (default is 0)
** for paparazzi versions older than v4.2 use: -d <device_name> set the device name (default is /dev/input/js0))
* -v verbose mode (can also be used to identify the channels)
* -id set the joystick ID (in range [0,255], a random value is chosen if not set)
Do not forget the configuration file name after the options.

Example invocation on Mac OS X using a SNES gamepad configuration as input:

$ ./sw/ground_segment/joystick/input2ivy -b 224.255.255.255:2010 -ac Teensy_Fly_Quad_Elle0_v1_2_214 -d 0 snes_gamepad.xml

Input2Ivy can be launched from the Paparazzi Center if your conf/control_panel.xml have the correct 'program' entry. (See conf/control_panel.xml.example)

[[Category:Tools]]

Joystick

2016-09-15T16:57:52Z

IHaveADrone: spelling

=Introduction=

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

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

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

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

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

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

<gallery>
File:Nes_gamepads.jpg|NES gamepads via USB
</gallery>

Also supported are USB based Nintendo gamepad controllers useful when flying in NAV/GUIDED modes

=Quick test=

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

$ dmesg

Although the message is a little different for every joystick type, it should display something like this in last lines:

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

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

$ sudo apt-get install joystick jstest-gtk

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

$ jstest-gtk

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

$ sudo jscal-store /dev/input/js0

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

==OSX==

Whether you are running on Mac OS X or Linux, the ''test_stick'' tool provides the ability to profile a joystick device.

<nowiki>
$ ./sw/ground_segment/joystick/test_stick -h
Usage:
./test_stick <option> [<option>...]
Options:
-d <string> device name
-h display this help</nowiki>

The default ''device name'' is set to 0 if the ''-d'' option is not specified.

Here's a snippet of the tool output when a single USB enabled SNES gamepad is connected.

<nowiki>
$ ./sw/ground_segment/joystick/test_stick

Available button: 11 (0xb)
Available hats: 0 (0x0)
Available axes: 2 (0x2)
Axis 0 : parameters = [-32768,32768]
Axis 1 : parameters = [-32768,32768]
Input device name: "2Axes 11Keys Game Pad" on SDL device "0"
buttons 0 0 0 0 0 0 0 0 0 0 0 | hat 0 | axes -1 -1
buttons 0 0 0 0 0 0 0 0 0 0 0 | hat 0 | axes -1 -1
buttons 0 0 0 0 0 0 0 0 0 0 0 | hat 0 | axes -1 -1
...</nowiki>

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

User:Spammer

2016-07-21T17:48:42Z

IHaveADrone: spammer

spam account, please ban.

Developer Guide

2016-07-15T19:20:30Z

IHaveADrone: /* MISRA-C Rules */ removed random spaces inside of words

==Introduction==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

==[[MISRA-C Rules]]==
And guidelines.

=== Directive 4.3 ===
Assembly language shall be encapsulated an isolated

Where assembly language instructions are used they shall be encapsulated and isolated in:
* Assembly language functions;
* C functions ( inline functions preferred for C99 );
* C macros.

==== Rationale ====
For reasons of efficiency it is sometimes necessary to embed simple assembly language instructions in-line, for example to enable and disable interrupts. If this is necessary, then it is recommended that it be achieved by using macros, or for C99, inline functions.
Encapsulating assembly language is beneficial because:
* It improves readability;
* The name, and documentation, of the encapsulating macro or function makes the intent of the assembly language clear;
* All uses of assembly language for a given purpose can share the same encapsulation which improves maintainability;
* The assembly language can easily be substituted for a different target or for purposes of static analysis.
Note: the use of in-line assembly language is an extension to standard C, and therefore violates Rule 1.2.

==== Example ====
<source lang="c">
#define NOP asm(" NOP")
</source>

=== Directive 4.10 ===
Precautions shall be taken in order to prevent the contents of a header file being included more than once
==== Rationale ====
When a translation unit contains a complex hierarchy of nested header files, it is possible for a particular header file to be included more than once. This can be, at best, a source of confusion. If this multiple inclusion leads to multiple or conflicting definitions, then this can result in undefined or erroneous behaviour.

==== Example ====

<source lang="c">
/* file.h */
#ifndef FILE_H
/* Non-co mpliant - does not #define FILE_H */
#endif
</source>

In order to facilitate checking, the contents of the header should be protected from being included more than once using one of the following two forms:

<source lang="c">
#if !defined ( identifier )
#define identifier
/* Contents of file */
#endif
</source>

<source lang="c">
#ifndef identifier
#define identifier
/* Contents of file */
#endif
</source>

Note: the identifier used to test and record whether a given header file has already been included shall be unique across all header files in the project.
Note: comments are permitted anywhere within these forms.

=== Rule 3.1 ===
The character sequences /* and // shall not be used within a comment

==== Rationale ====
If a comment starting sequence, /* or //, occurs within a /* comment, is it quite likely to be caused by a missing */ comment ending sequence.
If a comment starting sequence occurs within a // comment, it is probably because a region of code has been commented-out using //.

==== Exception ====
The sequence // is permitted within a // comment.

==== Example ====
Consider the following code fragment:

<source lang="c">
/* some comment, end comment marker accidentally omitted
>
Perform_Critical_Safety_Function( X );
/* this comment is non-compliant */
</source>

In reviewing the page containing the call to the function, the assumption is that it is executed code. Because of the accidental omission of the end comment marker, the call to the safety critical function will not be executed.
In the following C99 example, the presence of // comments changes the meaning of the program:

<source lang="c">
x = y // /*
+ z
// */
;
</source>

This gives x = y + z; but would have been x = y; in the absence of the two // comment start sequences.
See Also Dir 4.4

=== Rule 3.2 ===
Line splicing shall not be used within // comments.

==== Amplification ====
Line-splicing occurs when the \ character is immediately followed by a new-line character. If the source file contains multibyte characters, they are converted to the source character set before any splicing occurs.

==== Rationale ====
If the source line containing a // comment ends with a \ character in the source character set, the next line becomes part of the comment. This may result in unintentional removal of code.
Note: line-splicing is described in Section 5.1.1.2(2) of both C90 and C99.

==== Example ====
In the following non-compliant example, the physical line containing the if keyword is logically part of the previous line and is therefore a comment.

<source lang="c">
extern bool_t b;
void f ( void )
{
uint16_t x = 0; // comment
if ( b )
{
++x; /* This is always executed */
}
}
</source>

See Also Dir 4.4

=== Rule 4.1 ===
Octal and hexadecimal escape sequences shall be terminated

==== Amplification ====
An octal or hexadecimal escape sequence shall be terminated by either:
* The start of another escape sequence, or
* The end of the character constant or the end of a string literal.

==== Rationale ====
There is potential for confusion if an octal or hexadecimal escape sequence is followed by other characters. For example, the character constant '\x1f' consists of a single character whereas the character constant '\x1g' consists of the two characters '\x1' and 'g'. The manner in which multi-character constants are represented as integers is implementation-defined.
The potential for confusion is reduced if every octal or hexadecimal escape sequence in a character constant or string literal is terminated.

==== Example ====
In this example, each of the strings pointed to by s1, s2 and s3 is equivalent to "Ag".

<source lang="c">
const char *s1 = "\x41g"; /* Non-compliant */
const char *s2 = "\x41" "g"; /* Compliant - terminated by end of literal */
const char *s3 = "\x41\x67"; /* Compliant - terminated by another escape */
int c1 = '\141t'; /* Non-compliant */
int c2 = '\141\t'; /* Compliant - terminated by another escape */
</source>

See Also C90: Section 6.1.3.4, C99: Section 6.4.4.4

=== Rule 5.1 ===
External identifiers shall be distinct

==== Amplification ====
This rule requires that different external identifiers be distinct within the limits imposed by the implementation.
The definition of distinct depends on the implementation and on the version of the C language that is being used:
* In C90 the minimum requirement is that the first 6 characters of external identifiers are significant but their case is not required to be significant;
* In C99 the minimum requirement is that the first 31 characters of external identifiers are significant, with each universal character or corresponding extended source character occupying between 6 and 10 characters.
In practice, many implementations provide greater limits. For example it is common for external identifiers in C90 to be case-sensitive and for at least the first 31 characters to be significant.

==== Rationale ====
If two identifiers differ only in non-significant characters, the behaviour is undefined.
If portability is a concern, it would be prudent to apply this rule using the minimum limits specified in The Standard.
Long identifiers may impair the readability of code. While many automatic code generation systems produce long identifiers, there is a good argument for keeping identifier lengths well below this limit.
Note: In C99, if an extended source character appears in an external identifier and that character does not have a corresponding universal character, The Standard does not specify how many characters it occupies.

==== Example ====
In the following example, the definitions all occur in the same translation unit. The implementation in question supports 31 significant case-sensitive characters in external identifiers.

<source lang="c">
/* 1234567890123456789012345678901********* Characters */
int32_t engine_exhaust_gas_temperature_raw;
int32_t engine_exhaust_gas_temperature_scaled; /* Non-compliant */
/* 1234567890123456789012345678901********* Characters */
int32_t engine_exhaust_gas_temp_raw;
int32_t engine_exhaust_gas_temp_scaled; /* Compliant */
</source>

In the following non-compliant example, the implementation supports 6 significant case-insensitive characters in external identifiers. The identifiers in the two translation units are different but are not distinct in their significant characters.

<source lang="c">
/* file1.c */
int32_t abc = 0;

/* file2.c */
int32_t ABC = 0;
</source>

See also: Dir 1.1, Rule 5.2, Rule 5.4, Rule 5.5

=== Rule 5.2 ===
Identifiers declared in the same scope and name space shall be distinct

==== Amplification ====
This rule does not apply if both identifiers are external identifiers because this case is covered by Rule 5.1.
This rule does not apply if either identifier is a macro identifier because this case is covered by Rule 5.4 and Rule 5.5.
The definition of distinct depends on the implementation and on the version of the C language that is being used:
* In C90 the minimum requirement is that the first 31 characters are significant;
* In C99 the minimum requirement is that the first 63 characters are significant, with each universal character or extended source character counting as a single character.

==== Rationale ====
If two identifiers differ only in non-significant characters, the behaviour is undefined.
If portability is a concern, it would be prudent to apply this rule using the minimum limits specified in The Standard.
Long identifiers may impair the readability of code. While many automatic code generation systems produce long identifiers, there is a good argument for keeping identifier lengths well below this limit.

==== Example ====
In the following example, the implementation in question supports 31 significant case-sensitive characters inidentifiers that do not have external linkage.
The identifier engine_exhaust_gas_temperature_local is compliant with this rule. Although it is not distinct from the identifier engine_exhaust_gas_temperature_raw, it is in a different scope. However, it is not compliant with Rule 5.3.

<source lang="c">
/* 1234567890123456789012345678901********* Characters */
extern int32_t engine_exhaust_gas_temperature_raw;
static int32_t engine_exhaust_gas_temperature_scaled; /* Non-compliant */

void f ( void )
{
/* 1234567890123456789012345678901********* Characters */
int32_t engine_exhaust_gas_temperature_local; /* Compliant */
}

/* 1234567890123456789012345678901********* Characters */
static int32_t engine_exhaust_gas_temp_raw;
static int32_t engine_exhaust_gas_temp_scaled; /* Compliant */
</source>

See also Dir 1.1, Rule 5.1, Rule 5.3, Rule 5.4, Rule 5.5

=== Rule 5.3 ===
An identifier declared in an inner scope shall not hide an identifier declared in an outer scope.

==== Amplification ====
An identifier declared in an inner scope shall be distinct from any identifier declared in an outer scope.
The definition of distinct depends on the implementation and the version of the C language that is being used:
* In C90 the minimum requirement is that the first 31 characters are significant;
* In C99 the minimum requirement is that the first 63 characters are significant, with each universal character or extended source character counting as a single character.

==== Rationale ====
If two identifiers differ only in non-significant characters, the behaviour is undefined.
If an identifier is declared in an inner scope but is not distinct from an identifier that already exists in an outer scope, then the inner-most declaration will “hide” the outer one. This may lead to developer confusion.
Note: An identifier declared in one name space does not hide an identifier declared in a different name space.
The terms outer and inner scope are defined as follows:
* Identifiers that have file scope can be considered as having the outermost scope;
* Identifiers that have block scope have a more inner scope;
* Successive, nested blocks, introduce more inner scopes.

==== Example ====
<source lang="c">
void fn1 ( void )
{
int16_t i; /* Declare an object "i" */
{
int16_t i; /* Non-compliant - hides previous "i " */
i = 3; /* Could be confusing as to which "i" this refers */
}
}

struct astruct
{
int16_t m;
};

extern void g ( struct astruct *p );

int16_t xyz = 0; /* Declare an object "xyz" */

void fn2 ( struct astruct xyz ) /* Non-compliant - outer "xyz" is
* now hidden by parameter name */
{
g ( &xyz );
}

uint16_t speed;

void fn3 ( void )
{
typedef float32_t speed; /* Non-compliant - type hides object */
}
</source>

See also: Rule 5.2, Rule 5.8

[[Category:Developer_Documentation]]

Logs

2016-07-08T17:02:03Z

IHaveADrone: spelling

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 milliseconds since the creation of the file and marked with the ID of the sending aircraft.

The first part before the type of file 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:
<source lang="xml" >
<message name="GPS" ID="8">
<field name="mode" type="uint8" unit="byte_mask"/>
<field name="utm_east" type="int32" unit="cm"/>
<field name="utm_north" type="int32" unit="cm"/>
<field name="course" type="int16" unit="decideg"/>
<field name="alt" type="int32" unit="cm"/>
...
</message>
</source>

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>) which can be started from the [[Paparazzi Center]] (from tools menu to start alone, or from the '''session''' selection box to start a complete replay session with GCS, server and player tool). 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 a<tt>.log</tt> file is added behind the replay command on the command line, this log will be loaded on startup immediately.

TIP: If one want to speed up a replay with 4x speedup of the time [[Simulation#Change_the_environment|Environment Simulator agent, Gaia]] can be used. Launch it from Paparazzi center tools menu "[[Simulation#Change_the_environment|Environment Simulator]]". Then changing the time scale with the slider or add a commandline option e.g. ''./gaia -t 4''

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

==NMEA log output==
NMEA output is useful for [[Kinomap]], for example. Do not confuse this with the application ''ivy2nmea'' live NMEA stream out.

Two methods exist for generating an NMEA gps log from the paparazzi logs:
: 1- convert the .kml to .nmea by use of gpsbabel application (available on windows and linux)
: 2- convert the .data to .nmea by use of perl script in sw/in_progress/log_parser/log2nmea.pl (also works on windows and linux)

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

AR Drone 2/Mapping

2016-07-08T15:55:19Z

IHaveADrone: spelling etc.

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

<span style="color:red">'''Mapping has not been integrated with paparazzi due to lack of time. Yet, all components have been tested and are working properly.'''</span>

One of the functions that the AR.Drone2 should have is to be able to map a certain area (starting off with a room). In order to do this the AR.Drone2 needs to be able to: measure distance to objects, keep track of it's own position and heading, store a map efficiently and avoid crashing into objects. The first two things are needed to create a map from measurements during flight, the third is to use a map and still be able to go through all the control loops of paparazzi, the fourth is to maintain flight. It would also be useful to make an algorithm for the AR.Drone2 to explore the area and store the map in the most efficient way.

== Storing the map==

For storing the map, at first we believed [http://octomap.sf.net/ Octomap] ([http://ais.informatik.uni-freiburg.de/publications/papers/wurm10octomap.pdf paper]) to be a good solution. It's a datastructure using an [http://en.wikipedia.org/wiki/Octree OcTree] to store a 3D map that is updateable, flexible and compact. However, since we want to fly in a 2D manner, it's not very useful. You'd have to retrieve a 2D slice of the map at a certain hight (for which there is no build-in function) every iteration which would take a lot of unnecessary time.

Since we liked the flexibility of the Octomap, we created our own 2D version of it: a quadmap so to speak. Instead of an octree, it uses a quadtree to store information about the map. This way we represent the map as a square instead of a cube, like the Octomap does. The rest is pretty much the same: we keep a record of all the occupied, free and unknown cells and we can update the map by casting rays from a startingpoint towards an endpoint (with endpoint being occupied or not).

== Exploring the area==

Since the AR.Drone2 will only have point measurement sensors to measure distance to objects, it is pretty much impossible to create a 3D map. Flying on the same hight all the time, will make a 2D map sufficient for the job. We're using [http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=613851 Frontier-Based Exploration] for this purpose. With this approach you start with a map filled with unknown cells. Then, by scanning the surroundings of the robot, you fill in the unknown cells: occupied or unoccupied. Next, you search all the frontiers (the border between unoccupied and unknown cells) and pick the frontier with the optimum of being the largest and with the least travel distance. Subsequently you take that frontier as your next destination and upon arrival you scan again. There are also variations for 3D ([http://www.informatik.uni-freiburg.de/~ki/papers/dornhege_etal_ssrr11.pdf paper]). But this is based on a wide range sensor (kinect for example) and therefore not suited for our AR.Drone2.

As explained, Frontier-Based Exploration consists out of a few steps that will be repeated until the whole area is explored:
* Scan
* Search for frontiers
* Pick best frontier
* Travel

We can use these steps to create a statemachine. Since paparazzi needs to go through its control loops to keep the drone in the air (and because it's a single threaded system), we need to execute the mapping algorithm in smaller steps and thus keep track of what state we are.

[[Image:statediagram_mapping.png|thumb|center|700px|Statediagram of Frontier-Based Exploration with the AR.Drone2]]

As you can see, some of the steps of Frontier-Based Exploration have been split up into smaller substates. This way we can see more easily what the program is supposed to do while keeping the operation time per iteration to a minimum. Note however that, while true for some, not all states shift to the next after one iteration. In some cases, FIND_PATHS for example, it will take a few iterations before it will shift.

=== Init===
Inside the mapping algorithm, we not only keep track of the state, we also keep track of other things like indexes, iterator positions etc. In the init state, all these fields are set to their respective starting values, after which the algorithm enters the next state.

=== Scanning===
Some robots can scan entire areas while moving with wide range sensors. Our Ar.Drone2 is limited to point measurement sensors and therefore has to have an explicit step "Scan". Seeing as our drone will have 4 horizontally placed sensors in a + sign, a 360 degrees scan can be made by making a 45 degrees turn. By keeping track of our rotation and position, with the use of internal sensors, we can deduct where the scanned points are in our selfmade map.

=== Search for frontiers===
In "Search for frontiers", we obviously search for frontiers. As the paper of Frontier-Based Exploration explains, we will use these frontiers to deduct our next goal to travel to. As can be seen in the statediagram, we created substates for "Search for frontiers" (DELETE_FRONTIERS, FIND_FRONTIER_NODES, BUILD_FRONTIERGRID and CLUSTER_FRONTIERS) for reasons explained earlier.

==== DELETE_FRONTIERS====
In the mapping algorithm, we maintain a list of frontierpoints (2D points to represent position) for the sake of speed. That way, we only have to check the area, obtained during state Scanning, for new frontiers instead of going over the whole map. But because of that, we also need to remove any frontierpoints when they´re not frontiers anymore. DELETE_FRONTIERS is the state where every frontierpoint in the list is checked, to see whether it's still a frontier or not.

==== FIND_FRONTIER_NODES====
When all the outdated frontiers are deleted, we need to add the newly created frontiers. This happens in FIND_FRONTIER_NODES. Because the area that got updated in Scanning is the only area that got updated, we only have to search for new frontierpoints in there. Those frontierpoints will then be added to the list.

==== BUILD_FRONTIERGRID====
With the frontierpoint list we build a 2D grid representation of the map and fill it with frontiers on their respected positions (positions without frontiers are null pointers). This grid will be used in the next state to cluster them all together.

==== CLUSTER_FRONTIERS====
In this state, the frontiers will be clustered together using a [http://en.wikipedia.org/wiki/Disjoint-set_data_structure Union-Find Algorithm]. With the list of frontierpoints, we can check the surrounding tiles of that position within the frontiergrid to find neighbouring frontiers. These neighbours are then clustered together. When the size of a cluster reaches a certain threshold, it is added to a list of clustered frontiers. The threshold has two advantages. One of them is that the drone will never visit frontiers that are too small to be of any use. The other advantage is to keep the amount of checks for redundant clusters in the list low. You see, when two clusters, that aren't the same, have been added to the list and later on these two clusters have formed 1 cluster, you'll have two of the same cluster in the list and one will have to be removed. With the threshold it will happen less often that two clusters inside the list will be unified.

=== Pick best frontier===
Having obtained several clusters of frontiers, we can now use these to deduct our next goal location. By normalizing the size of the frontiers and traveling distance towards them, we can pick the frontier with the optimum of small traveling distance and large size. However, before we can know the traveling distance towards a frontier we need to know the path towards it. For this we apply pathfinding in the FIND_PATHS state using the [http://www.policyalmanac.org/games/aStarTutorial.htm A* algorithm], we choose this algorithm mainly for it's simplicity. To make travelling along the path easier, we trim the found paths to a set of waypoints (not tile by tile). After all the paths have been found, the best frontier will be picked in the FIND_BEST_FRONTIER state.

=== Travel===
Now knowing where the drone should be headed to, we can start following the path we calculated earlier. Since the path exists out of waypoints, the easiest way of traveling is by turning towards the waypoint (TURN_TO_WAYPOINT), followed by moving forward until waypoint is reached (TRAVEL_TO_WAYPOINT). When the waypoint is reached you take the next waypoint and travel to that one, until there are no more waypoints left and you should have arrived at the goal.

== Integration with Paparazzi==

Since we had a hard time to get the AR.Drone2 flying, we ended up with too little time to integrate the mapping algorithm with Paparazzi. We did however work out how we wanted to integrate it. Our ideas will be explained in this section, just keep in mind that most of it is speculation.

For the mapping algorithm to work with Paparazzi, we need to be able to do a few things:
* Keep track of position and heading
* Pilot the AR.Drone2
* Read out the [[AR_Drone_2/Multidirectional_distance_measurement| distance sensor data]]
* Let Paparazzi call the algorithm in an iterative way

The first and third bullets are necessary to be able to know which maptiles to update. Keeping track of position and heading is also important for being able to calculate the next action to be taken by the drone (it's hard to figure out how to get somewhere if you don't know where you are). The second bullet is needed to be able to fly to where we want, how we want. The last thing we need is to execute the mapping algorithm, since Paparazzi is the main program, it will have to execute the mapping algorithm (and not the other way around).

=== Keep track of position and heading===
Paparazzi itself keeps track of a position and heading according to gps (this is all located in sw/airborne/state.h). Although the heading is no problem (you can keep the map pointed north that way), it's hard to convert gps coordinates into map coordinates. But there's another solution to this: if we take the starting position as [0, 0] we can then update the position by integrating the velocity every iteration. Although the outcome won't be 100% correct, the error will be kept to a minimum with a high enough update rate. In case velocity isn't updated fast enough we can also try using the acceleration from the accelerometers to update position.

=== Pilot the AR.Drone2===
Flying with Paparazzi currently works in two different ways: autonomous with a [[Flight_Plans| flight plan]] or on radio control with support of the autopilot until a certain degree. Flight plan based will mean that we'd have to be able to update the flight plan while flying from within the mapping algorithm. This is a hard thing to do since the flight plan is located in the ground station and the mapping algorithm will be working on the AR.Drone2 (the airborne part). Though it would be very nice and would also take away the first problem of keeping track of your own position (the flight plan can cooperate with relative x and y values).

The second option is a lot easier to implement, although more prone to errors in the positioning. When using radio control, Paparazzi sends the radio control values from the ground station to the airborne. There, a struct gets filled with the values, which in turn gets handled by the autopilot. By using the right [[Rotorcraft_Configuration#Autopilot_modes| autopilot mode]] we can fly stable to the locations we want (AP_MODE_HOVER_Z_HOLD for yawing and AP_MODE_ATTITUDE_Z_HOLD for moving). Note however that by using the radio control struct you can only use 3 different autopilot modes (these are described in the [[Rotorcraft_Configuration| airframe]]).

=== Read out the distance sensor data===
To keep it simple, we wanted to directly access the data from the sensors. It is of course possible to integrate the sensors with Paparazzi as well, but Paparazzi itself has no need for distance measurement.

=== Let Paparazzi call the algorithm in an iterative way===
To let Paparazzi use the mapping algorithm, we can implement mapping as a [[Subsystem| subsystem]]. That way mapping can be added optionally to the airframe (just like gps is optional). Since the mapping algorithm is to be called in an iterative way, we can tell the main control loop to call the algorithm and we're done.

[[Category: AR Drone 2]]

Other Infrared Sensors

2016-07-08T15:47:39Z

IHaveADrone: spelling

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

= FMA Direct Co Pilot Sensor Boards =
The [http://www.fmadirect.com FMA Direct] horizontal (X-Y) and vertical (Z) sensors are inexpensive, readily available, and perfectly suited for use with all versions of the Paparazzi autopilot. These sensors are only available direct from FMA ''Direct''.<br>
Purchase both the X-Y sensor: [http://www.fmadirect.com/detail.htm?item=1778&section=20 CPD4SENUNIT] and Z sensor: [http://www.fmadirect.com/Detail.htm?item=1888&section=49 FS8ZS] for optimum performance. The sensor boards are coated with a very thick lacquer that is difficult to penetrate while soldering. Do not remove more coating than necessary as it prevents the very high value resistors from drifting with humidity changes.

{|
|-
|[[Image:fmairsensor.jpg|thumb|right|FMA X-Y Sensor [http://www.fmadirect.com/detail.htm?item=1778&section=20 CPD4SENUNIT]]]
|[[Image:fmavertsensor.gif|thumb|right|FMA Z-sensor [http://www.fmadirect.com/Detail.htm?item=1888&section=49 FS8ZS]]]
|}

== Pinouts and Optional Gain Adjustment ==

The FMA sensors were designed to operate from a 5V source but are typically powered in Paparazzi installations with 3.3V, ensuring that the sensor's analog output does not exceed the 3.3V limit of the ADC inputs on the ARM7 microprocessor. The sensors work well at 3.3V but their amplifier gain is effectively increased by a factor of 5/3.3.
* If the gain is too high and/or the airfield contrast is also too high, the sensor could saturate (reach it's maximum possible reading) well before the aircraft has pitched/rolled 90 degrees, resulting in a tendency for the plane to underbank/underpitch and drift off course.
* If the gain is too low and/or the contrast is too low, the noise and neutral-offset of the sensor can become dominant, resulting in a tendency for the aircraft to be out of trim and potentially overbank/overpitch in one direction and crash.

Either extreme is bad, of course, but it should be noted that these are only extremes. For reference, a stock FMA sensor run on 3.3V will saturate when flying over black asphalt on a very hot, dry Arizona day, a modified sensor will not. Similarly, a modified sensor will show more signs of neutral-offset when operated in cloudy weather or other low contrast situations. It is suggested that sensors only be modified if needed for very high contrast locales.

'''Make sure that the IR1 output from the XY sensor goes to IR1 input of the Tiny and that the IR2 output from the XY sensor goes to the IR2 input of the tiny board.'''

* '''XY sensors from FMA have the plug connected as:'''
* 1) Gnd;
* 2) +3.3v;
* 3) IR1;
* 4) IR2;

* '''But on the tiny board the plug is connected as:'''
* 1) Gnd;
* 2) +3.3v;
* 3) IR2;
* 4) IR1.

=== Horizontal Sensor Modification ===
{|
|[[Image:FMA_IR_OPAMP_OVR.jpg|thumb|left|300px|IR Sensor Board Bottom]]
|[[Image:FMA_IR_TOP_OVR.jpg|thumb|left|290px|IR Sensor Board Top]]
|}

The stock FMA resistors R2/R3 and R5/R6 (0603 0.8 Mohm/0603 510 ohm) set the op amp gain to approximately 1600. Since this unit is designed to run on 5V and we are running it on 3.3V, we can change R3 and R6 from 510 ohm to 1K ohm to reduce the gain to around 800. Another option is to replace R2 and R5 with 560 Kohm resistors, generating an output gain of approximately 1100; a gain which is practically identical to that of the Paparazzi board.

''a suitable resistor from mouser is [http://www.mouser.com/search/productdetail.aspx?R=RK73H1JTTD5623Fvirtualkey66000000virtualkey660-RK73H1JTTD5623F here]''

{|
|R1
|200 ohm
|-
|R2
|0.8 Mohm
|-
|R3
|510 ohm
|-
|R4
|200 ohm
|-
|R5
|0.8 Mohm
|-
|R6
|510 ohm
|-
|R7
|600 ohm
|-
|R8
|600 ohm
|-
|C1
|0.026 uF
|-
|C2
|0.026 uF
|-
|C3
|0.026 uF
|-
|C4
|0.026 uF
|-
|C5
|0.01 uF
|-
|C6
|0.026 uF
|}

=== Vertical Sensor Modification ===

{|
|[[Image:Fma_ir_single_bottom.jpg|thumb|left|300px|IR Vertical Sensor Board Bottom]]
|[[Image:Fma_ir_single_up.jpg|thumb|left|290px|IR Vertical Sensor Board Top]]
|}

The same operation can be done with the vertical sensor by changing R3 from 510 ohm to a 1K ohm.

''a suitable resistor from mouser is [http://www.mouser.com/search/productdetail.aspx?R=RK73H1JTTD1001Fvirtualkey66000000virtualkey660-RK73H1JTTD1001F here]''

= Attopilot Sensor Boards =

The Attopilot horizontal (X-Y) and vertical (Z) sensors are an alternative sensor pair for the Paparazzi autopilot. They come without molex connector already soldered if you are lucky. The molex connector on the board is bigger and different from the Paparazzi IR board. It is advised to solder the Paparazzi molex on the board, with a little soldering skill this is doable.

== Pinouts and Optional Gain Adjustment ==

{TODO}

= Alternative sensor schematic from MyResearch =

This is [http://www.myresearch.lt/blog/servo180/servo180.phtml MyResearch.lt] open source data. The sensor is presented as a replacement for a servo potentiometer. It can be used in a same way as the FMA Direct Co Pilot Sensor. The resistors 4k7 are not needed if it is not connected to a servo directly.

[[Image:Ir_ckt.jpg]]

[[Image:Ir_pcb.gif]]
[http://www.myresearch.lt/blog/servo180/pcb.tif PCB]

[[Image:Ir1.jpg]]

[http://www.youtube.com/watch?v=abZbt1Vm7iw VIDEO]

Such a servomechanism is usable for controlling the bank of the aircraft or the inclination of the camera. You'll be able to control the inclination of the camera; the neutral position will conform to the horizon line. In addition, it is possible to control the ailerons of the aircraft and to incline the aircraft to the desired angle in respect of the horizon. If the horizon line is not symmetric, a bank of the aircraft appears. A signal of the sensor is applied to an ordinary servomechanism instead of the internal potentiometer. The potentiometer of the servomechanism is connected to the negative terminal, to the reference voltage and has one output (3 conductors); the infrared sensor is connected in the same way.

[[Category:Hardware]] [[Category:Sensors/IR]]

Redundant Communication

2016-06-30T15:33:00Z

IHaveADrone: /* Hardware */ Tx pin locations

<div style="float: right; width: 15%"><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Tools</categorytree></div>
<div style="float: right; width: 45%; overflow: hidden">[[Image:link_page.png|center|397px|Link Page in GCS]]</div>
<div style="float: right; width: 40%">__TOC__</div>

This goal of this project is to allow multiple radio modems or other links be used between the aircraft and the ground station in a redundant fashion so that even if one link is lost, communication can be maintained. So far, the aircraft to ground component has been created and tested in the lab. The ground to aircraft component has not been created yet.

===Reasons to Use Redundant Links===
Communication from the aircraft to the ground is called telemetry. This communication allows the status of the aircraft such as location, altitude, airspeed, battery level, current flight block, and much more to be monitored in real time. Communication from the ground to the aircraft is called datalink. This communication allows commands to be sent to the aircraft from the ground. This includes telling the aircraft what navigation to perform: fly to a waypoint, start the search area, come in for a landing. If a single link is used, as was always the case before this project, then if the aircraft goes out of range, or that link is otherwise lost, no telemetry information can be displayed in the GCS and commands sent from the GCS won't be received by the aircraft. Using the following redundant link system allows multiple links to be used in an effort to avoid this. Typically, you would introduce diversity when adding links. For example:
* If you have an on-board computer, you could tunnel messages through Wi-Fi over UDP in addition to a traditional 900 MHz XBee radio modem.
* You could use a satellite modem for long-range monitoring in addition to a radio modem.
* You could use a cellular modem in addition to a radio modem.
* With additional ground infrastructure, you could have radio modems located at different locations.
* You could use radio modems at different frequencies or with different antenna gains or orientations.
* You could use this system to evaluate different types of radio modems or antenna placements - you'll get real time info on each such as the ping time, received messages rate, and more information could easily be added.

There are undoubtedly many more possibilities.

== Aircraft to Ground ==

===Compatibility===
This project was made to be fully backwards compatible and support the awesome functionality that Paparazzi already has. This includes:
* Completely backwards compatible - includes aircraft configuration files, previous flight logs, existing sessions, etc...
* Logging and replay - if multiple links are used, data received through either link is recorded. Also, replays will include the status of each link as it was during the flight.
* Link features such as USB-serial, audio, UDP, different transport layers, etc...
* Multi-aircraft sessions - also, you can use redundant links for one aircraft, but not for another if desired.
* Multiple aircraft connected to the same link - such as might come up in a mesh configuration where one aircraft relays data from another aircraft.

===Features===
Enabling redundant communication from the aircraft to the ground enables the following features:
* Redundancy - as long as one link is receiving data, it will be logged and displayed on the GCS.
* Monitoring - the status, ping time, and rate of receiving messages for each link is shown (this makes it useful even if you're only using one link).
* Alerts - new alerts are added to the console in the GCS to alert you when a link has been connected for the first time, lost, or re-gained.

===Future Improvements===
Several different improvements can be made to this system to improve it's performance and help satisfy future needs that may arise:
* Additional information can easily be added to the Link page of the GCS for each link. For example: errors, % uptime, or a scrolling graph of Rx messages/s.
* The ability to mark different links as either critical or backup. The idea here is that not all links should necessarily be treated equal. Maybe only one link is able to send datalink data to the aircraft (actually, this is the case right now) and so that link should be considered critical. If any other link is lost, then the overall telemetry can be counted as OK. But if the critical link is lost, then the GCS should change the link indicator light to red and start counting up even if the other link(s) are OK.
* The Link Combiner algorithm currently employs a simple circular buffer. This could be improved on by adding a time-stamp to each element of the buffer and only counting two buffer elements to be the same if their timestamps are close enough (say within 2 seconds - this could be configured)
* The Link Combiner algorithm could be improved by making the buffer size adjust automatically with the ping time and Rx messages/s rate. Or if the timestamp improvement is implemented, then the maximum time difference could be adjusted.
* A performance and resource use analysis could be done to optimize the Link Combiner. The circular buffer is currently implemented using Python lists which could probably be improved upon. Also, significantly more ivy messages are sent and received. This might make optimizations to the regex or other parts of the ivybus worthwhile.

===How to Use===

For an example using two USB-serial adaptors, see the '''Flight USB-serial Redundant''' session saved in the example control_panel.xml configuration (on master branch, once the pull request has been accepted).

For the details, keep reading:
In order to implement redundant links using this code, there are three simple steps to follow:

* Connect the hardware - on the airborne side, connect the Rx pin of the autopilot's UART port to multiple radio modems or whatever other device which will get the information to the ground. On the ground side, connect multiple modems as normal (using USB to serial adapters, a UDP connection, or whatever). (note: Once the ground to aircraft redundancy has been implemented, you won't have to split the Rx signal and can just plug each modem into a UART port)
* Launch a Link agent for each modem (in Paparazzi Center, select it from the tools menu). Configure the agents as you would have before (serial port, baud rate, UDP, etc...). None of these features have been modified or removed. Then, use two new command line arguments: -redlink and -id. The -redlink flag tells Link that it's one of multiple links. The -id flag lets you specify an integer number as the id of that particular link.
* Launch the Link Combiner agent (again, from the tools menu). This agent listens to all of the Link agents that have their -redlink set and combines the data.

The following screenshot shows a session with two links, connected to serial ports ttyUSB0 and ttyUSB1, and with id's 1 and 2:

[[File:redundant_session.png|alt=Agents in Redundant Link Session|700px|thumb|center|The Agents Running in a Redundant Link Setup]]
<br style="clear:both">

* Test the system and make sure that it works correctly under all circumstances. Do this before flying. In particular, make sure that the buffer size if appropriate. Take a look at the [[#Algorithm Considerations|Algorithm Considerations]] section for details.

===Interface===
Once the redundant link system is started (even if only one Link is used), several changes appear in the GCS. This is achieved by the new message LINK_STATUS which is sent by the Link Combiner. These new features are designed to allow closer monitoring and better management of the link(s) between the aircraft and the ground station.

The following screenshot clearly shows these changes:
[[File:redundant_link_gcs.png|alt=Changes to the GCS when redundant links are used|1000px|thumb|center|Screenshot of the GCS with multiple links]]
<br style="clear:both">

Firstly, we can see that there is a new page in the notebook named Link. This page contains critical information for each link. More information can easily be added, but for now, it shows the status of the link (just like the main Link status indicator in the strip), the current ping time, and the rate of received messages. So if one link is lost, it's status indicator will turn red and start counting up just like link 2 in the above screenshot.

Next, we can see that the main Link status indicator that's located in the strip has been modified slightly. It now shows the ratio of connected links to the total number of links. I.e. 3/4 means that there are four links and one of them has been lost. Furthermore, the indicator will be green if all links are connected, yellow if one or more are lost, and red if all links are lost. Once all links are lost, the indicator will count up just like before.

Lastly, alerts have been added to the console. Whenever a link is lost or reconnected, a message will appear in the console stating so. Messages also appear when a new link is added.

===Design===
====Implementation====
Here's a block diagram showing how the aircraft talks to the various ground segment programs (also known as agents) when not using the redundant link system:

[[File:ground_segment_block_diagram.png|alt=Block diagram of agents in the ground segment|500px|thumb|center|Paparazzi Ground Segment]]
<br style="clear:both">

The ivy bus lets the programs talk to each other through the use of short messages. Pay close attention to the coloured arrows, which show the main flow of these messages. Next we have a block diagram of the redundant link system:

[[File:redundant_links_block_diagram.png|alt=Block diagram of agents in the ground segment when redundant links are used|800px|thumb|center|Paparazzi Ground Segment with Redundant Links]]
<br style="clear:both">

Here we can see the new agent, the Link Combiner. We also see multiple occurrences of the Link agent. When operating in redundant mode, each occurrence of Link transmits the data it receives from the aircraft to the Link Combiner instead of the Server. It does this by transmitting the received telemetry messages within the TELEMETRY_MESSAGE message which the Server doesn't listen to. The Link Combiner on the other hand does. TELEMETRY_MESSAGE messages are sent by each link and include the id of that link. The Link Combiner listens to all of them and then transmits a single set of messages to the Server with the combined data. This results in the Server and all other ground segment agents (such as Messages and the Real Time Plotter) getting their telemetry data from Link Combiner as if it was coming from a single occurrence of Link.

====Link Combiner====
The Link Combiner agent is written in Python. It receives messages from all of the Links (when they're in redundant mode: -redlink), and outputs messages to the Server and other ground segment agents. There is a bit involved however since the Server and GCS shouldn't be sent identical messages. I.e. if the aircraft sends a message and it's received successfully by more than one link, then that particular message should only sent by Link Combiner once. This is a somewhat tricky requirement since there is no guarantee that the message will be received by all of the links, and it's possible that the aircraft actually sends a second message that's exactly the same as the first. No extra info (such as a time-stamp or counter) is added to the messages sent from the aircraft to the ground, so the Link Combiner employs an algorithm to detect duplicate messages. Testing has shown that for typical links, this algorithm performs extremely well.

The algorithm gives each link a circular buffer to store the last N messages. When a new message comes in on a particular link, the algorithm first checks if it's already in that link's buffer. If it is, then it's obviously a new message, so its removed from all of the other buffers if it's in any of them. Then, the message is sent to the other agents. If the message isn't already in the link's buffer, then it's added to the buffer. After that, all of the other link's buffers are checked for the message. If it's in any of them, then the message was already received by another link, so isn't sent. If it's not in any of them, then the message is sent. The following flowchart depicts this algorithm:

[[File:link_combiner_flowchart.png|alt=Flowchart of the Link Combiner|500px|thumb|center|Algorithm to prevent duplicate messages]]
<br style="clear:both">

====Algorithm Considerations====
As the aircraft sends various messages, possibly with the exact same data, and the links gain and lose connection, there is no guarantee that this algorithm will do a perfect job of filtering out identical and only identical messages. However, in typical operation, it seems to work very well. And for the application of displaying aircraft data, the occasional missing or duplicate message is acceptable. There are only a few scenarios where the Link Combiner won't produce perfect results, and they should come up infrequently:

* A message will be sent twice if the buffer size is too small to hold all of the messages received from one link between that link receiving the message and another link receiving the identical message. When the second link receives the message that has already been received, if the original isn't in the buffer anymore, than the algorithm won't know it's a duplicate message. This scenario should be considered whenever implementing a redundant link system. Partly because it is the most likely to come up, but also because if it does occur, then all messages will be duplicated. In order to avoid this scenario, you can set the buffer size as a command line argument of Link Combiner. To know what a good value would be, you can observer the Ping time and Rx messages/s of the links in the new Link page of the notebook. Calculate the minimum buffer size by taking the difference between the largest ping time and the smallest ping time and multiplying it by the largest Rx messages/s. Then apply a safety factor when setting the buffer size - 10 times the calculated value should be good.
* A message won't be sent when it should be if the autopilot sends a message that's the same as one it already sent (same name and exact same values) AND one or more links were lost between the first message and the second AND the link that's receiving the second message doesn't have the first message in it's buffer still. That's three conditions. If this happens, then the Link Combiner will see the second message as a duplicate of the first and will skip it. Only this one message will be missed though - it won't start happening to all messages. Also, the data will have been data that was already received. So if it's for example the battery voltage message, then it's not a big deal to miss it. As long as there aren't links rapidly being lost and gained, then this shouldn't happen often. Note that as the buffer size is increased, it is believed that this becomes more likely to happen.

== Ground to Aircraft ==

This part of the redundant communication system hasn't been implemented yet. All information here is what it is envisioned to look like.

===Features===
* Enable multiple datalink links to be used for communicating with the autopilot.
* Let different telemetry be sent out each link.
* Let the choice of what telemetry is sent be moved from the settings page of the GCS to the Link page, since it can be different for each link.
* Add a link status indicator (this is the light that turns red when the link is lost) for the datalink to the Link page. This will allow better monitoring of the links by not assuming that if one direction is good, the other direction is good as well.
* Let each link be configured as telemetry only, datalink only, or by-directional.

===Compatibility===
Communication in the autopilot is enabled with the ground by including the telemetry subsystem in the airframe file. For example:
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
<subsystem name="telemetry" type="transparent"/>
</firmware>
</source>
}}

In order to use multiple links, changes should be made to allow a telemetry subsystem for each link. Related to this, would it be advantageous to have multiple instances be supported for each different subsystem? Once the design for this is determined, would actual support for each subsystem have to be added one at a time? Because of the logic for how multiple subsystems should behave together is dependent on the subsystem, this might be the case. The telemetry subsystem for example should default to sending telemetry out each one and combining the telemetry received.

===Hardware===
Unlike aircraft to ground redundancy, ground to aircraft redundancy requires multiple UART ports in the hardware of the autopilot. The author is not particularly familiar with this, but believes that there are ways to get multiple UART ports for this purpose:
* Telemetry can be sent out over USB by specifying the telemetry type to be "transparent_usb".
* For the Lisa/M, the USB port can actually be used as a UART port with some hardware modifications.
* Using an I2C GPS instead of a UART one can free up a UART port on most autopilots.
* For the Lisa/M, can UART 1 and 5 be used if Spektrum Satellite receivers aren't used? The board needs to be modified to access UART1_Tx see [[Lisa/M_v2.0#USB_as_UART1TX_.2B_hardware_flow_control|here]]. UART5_Tx is PC12 on the GPIO connector.

In addition, future hardware designs could includes more UART ports for redundant communications or any other purpose.

===Design===
Unlike the aircraft to ground communication, for ground to aircraft communication it is not acceptable to have the same message be acted on twice. This could cause the aircraft to behave unexpectedly. In order to implement a 100% guaranteed link combiner for the aircraft, the author proposes a system that adds a counter to each message sent to the aircraft. This would allow the autopilot to easily ignore identical messages - they'll have the same value for the counter. Also, since minimal data is sent from the ground to the aircraft, adding the extra bytes to the payload will have a minimal impact on performance - this is not the case for the telemetry.

The challenging part of this design will be integrating it properly into the existing systems.

[[Category:Tools]]

RT Paparazzi

2016-06-27T14:45:23Z

IHaveADrone: spelling

= Real Time (RT) Paparazzi =
== ICUAS 2016 An Open-Source Real-Time UAS Flight Control Prototyping and Testing Platform with Fractional-Order Horizontal Controller Example ==
The code is available [https://github.com/AggieAir/pprz-icuas2016 here]

== Introduction ==

the '''RT Paparazzi''' initiative is a step towards extended flexibility for the core autopilot. In a real time operating system (RTOS) [http://en.wikipedia.org/wiki/Real-time_operating_system] multiple threads are available, which are doing specific jobs e.g. a telemetry thread, a radio thread, a failsafe thread, at a defined rate. Unlike ''bare-metal'' application which uses interrupt driven timers for timing tasks, real time OS has a kernel which takes care of scheduling and running the threads. Having a kernel, it is possible to set priority of each thread, how much memory it takes etc.etc. which gives the developer more control over timing and resource management.

Besides kernel, a typical RTOS also has a hardware abstraction layer (HAL) which stands between user application and actual hardware, so the core autopilot developer doesn't have to worry to much about writing drivers for the sensor to use.

One of the strengths of Paparazzi is it's modularity - combining this with precise timing, scheduling and resource management a RTOS brings along, Paparazzi is now in a position to exceed even the leading commercial closed-source UAs autopilots.

= Paparazzi with ChibiOS/RT =

RT Paparazzi is based on ChibiOS/RT [http://chibios.org/dokuwiki/doku.php]. ChibiOS/RT supports basically all architectures that standard Paparazzi does (see [http://chibios.org/dokuwiki/doku.php?id=chibios:architectures]), which makes both systems compatible. Since RTOS makes handling multiple I/O easier, but comes with some extra overhead (context switching, kernel code), it gives most leverage to to STM32 F1xx and F4xx based autopilots ([[Apogee/v1.00]],[[Lisa/M_v20]], [[Lisa/S]], [[STM32F4_Discovery]], [[KroozSD]]...).

The development of RT Paparazzi with ChibeOS was started by the AggieAir team [http://aggieair.usu.edu/] at Utah State University.

== Getting the sourcecode ==

First version of functional RT paparazzi code (which comes with other perks such as SD card logging) is already available in the ''[https://github.com/paparazzi/paparazzi master]'' branch, thanks to [https://github.com/gautierhattenberger gautierhattenberger]. The code is continually improving, so stay tuned.

== Debugging with an Eclipse IDE ==
'''NOTE: As of June 2016 and ChibiOS 3.0+ SWD debugging with Black Magic Probe doesn't work under Eclipse (you get segmentation faults). The debugging works normally in terminal (arm-none-eabi-gdb), but I suspect there is some bug in how Eclipse is handling the debugging commands. Older versions of Eclipse (before Mars 2.0) and ChibiOS 2.6 work together perfectly.'''

Having a good development and debugging environment is a must for developing RT embedded system. The steps of setting up Eclipse IDE are described here [http://wiki.chibios.org/dokuwiki/doku.php?id=chibios:guides:eclipse1] and here [http://wiki.chibios.org/dokuwiki/doku.php?id=chibios:guides:eclipse2].

An alternative guide is for example here [http://embeddedprogrammer.blogspot.com/2012/09/stm32f4discovery-development-with-gcc.html]

Another great tutorial for setting up Eclipse is done by [http://docs.armstrap.org/en/latest/getting-started-eclipse-development-tools.html| armstrap].<br/>
With blacmagic probe integration, without Eclipse Arm Plugin.

Just a few notes to the process:
* it is preferred to switch-off compiler optimization for debugging (use ''-O0'' in compiler settings in Makefile for given architecture)
* install GCC Arm Embedded toolchain [https://launchpad.net/~terry.guo/+archive/gcc-arm-embedded] (recommended anyway for Paparazzi since v 5.0)
* get Black Magic probe from Blacksphere [http://www.blacksphere.co.nz/main/blackmagic], it will make your life easier
* in '''Creating a GDB Debug Configuration''' use the following commands for Black Magic Probe:
target extended-remote /dev/ttyACM0
monitor jtag_scan
attach 1
monitor vector_catch disable hard
set mem inaccessible-by-default off
monitor option erase
set print pretty
(for [[Lisa/M_v2.0#Lisa.2FLia_F4 | Lisa/Lia F4]] board use '' swdp_scan'' instead of ''jtag_scan'')
* if you are using luftboot, don't forget to add image offset into the debug configuration:
[[File:Rt_paparazzi_eclipse_setup_2.png]]
* don't forget in "Eclipse->Window->Preferences->Run/Debug->Launching->Default Launchers->GDB Hardware Debugging" set preferred launcher to "Standard GDB" (otherwise the ChibiOS/RT plugin won't work, tested in Eclipse Kepler Service Release 1):
[[File:Rt_paparazzi_eclipse_setup_1.png]]

=== ChibiOS Eclipse plugin ===

ChibiStudio plugin is officially supported for Windows only (write to the [http://www.chibios.com/forum/ ChibiOS forum] if you would like Linux support too), but since it is in Java it works under Linux too. If you want to test it yourself, here is the HOWTO:

* Get the latest eclipse (Version: Mars.2 Release (4.5.2))
* Install C/C++ Hardware Debugging as described [[wiki.chibios.org/dokuwiki/doku.php?id=chibios:guides:eclipse1#eclipse|here]]
* Make sure you have gcc-arm-none-eabi installed (v.4.9)
* Download latest ChibiStudi (preview 17) from [https://sourceforge.net/projects/chibios/files/ChibiStudio/ here] extract it and from ''ChibiStudio/eclipse/plugins'' Copy these libraries into your Eclipse/plugins directory:
org.chibios.chibistudio.branding_1.0.0.jar
org.chibios.tools.eclipse.config_1.9.1.201603121101.jar
org.chibios.tools.eclipse.debug.chibiosrt2_1.2.0.201603121101.jar
org.chibios.tools.eclipse.debug.chibiosrt3_1.0.1.201603121101.jar
org.chibios.tools.eclipse.debug.chibiosrt4_1.0.0.201603121101.jar
* Restart Eclipse - now you will see the ChibiOs plugings under ''Help->Installation Details->Plugins''
* Enable the plug-in while in the "Debug" view under: Window->Show View->Other...->ChibiOS/RT->ChibiOS/RT" (see [http://forum.chibios.org/phpbb/viewtopic.php?f=3&t=140] for details)

Now you can use ChibiStudio plugin to view your threads memory usage, available stack, trace buffer etc. depending on the debugging options you enabled.

=== ChibiOS Tutorials ===
Related videos about setting up Eclipse with ChibiOS plugins (called together ChibiStudio) are available [https://www.youtube.com/playlist?list=PLpDawCIUjDFFXjRFUT9tFcUuuvNb6iT1A here]

= Compiling Paparazzi code in Eclipse =
Moved to [[DevGuide/CodeEditors#Eclipse_2|DevGuide/CodeEditors]]

Builds/Tests

2016-06-14T13:29:11Z

IHaveADrone: spelling

= Automated testing =

There are a number of automated tests that can be run from the command line from the top level Paparazzi directory:

* <code>make test</code>: runs test_math and test_examples
* <code>make test_math</code>: test math lib
* <code>make test_examples</code>: test compiles all aircrafts/targets in conf/conf_tests.xml
* <code>make test_all_confs</code>: test compiles all confs, i.e. all aircrafts found in all conf files found by <code>find_confs.py</code>

To test compile all aircrafts in one specific conf file:<br />
<code>CONF_XML=conf/conf_personal.xml prove tests/aircrafts/</code><br />
See [https://github.com/paparazzi/paparazzi/blob/master/tests/aircrafts/01_compile_all_aircrafts.t tests/aircrafts/01_compile_all_aircrafts.t] for more details.

If you require more verbose output of the results run the command <code>make test TEST_VERBOSE=1</code>

The test results can also be generated in JUnit format adding the option <code>JUNIT=1</code> to the command line i.e. <code>make test JUNIT=1</code> or <code>make test TEST_VERBOSE=1 JUNIT=1</code>

JUnit formatting of test results requires that the Perl module <code>TAP::Formatters::JUnit</code> is installed on the machine that the tests are run on. Please see [[Builds/Tests#Installing Perl Modules| installing Perl modules]] for more details

= Hardware tests =
The hardware testing is executed using the Perl test framework.

To implement the hardware testing we need do the following
* Build the firmware
* Upload the firmware to the target board noting that multiple boards may be connected to the same computer
* Start up the '''server''' program
* Start up the '''link''' program
* Run the test suite by reading and writing data to the Ivy bus.
* Stop the '''server''' and '''link''' processes

The Perl module <code>IO::Socket::Multicast</code> is required to be installed to be able to execute the hardware tests. Please see [[Builds/Tests#Installing Perl Modules| installing Perl modules]] for more details

To execute the hardware tests run the command <code>make test TEST_HARDWARE=1</code>

= Installing Perl modules =
On Ubuntu/Debian simply
apt-get install libio-socket-multicast-perl libtap-formatter-junit-perl

To install Perl modules directly from CPAN the following procedure can be run.

# sudo perl -MCPAN -e shell
# install <module name>

This should install all of the required modules. note that errors may be reported during the installation process so you should pay attention to what is happening.

[[Category:Testing]]

Installation/MacOSX-legacy

2016-06-10T15:55:37Z

IHaveADrone: spelling

= Intro =
This page contains the different installation approaches that did work on past versions of Mac OS X. They are currently not working any more on the newest versions of Mac OS X. They still might be useful as information sources for those that either want to install on a legacy mac os x or want to resurrect one of the installation approaches.

= Basic Install (Binary Installer) =
Depending on the version of Mac OS you have installed on your computer the installation process will vary slightly. Also this install process is only recommended for beginners. If you want to be able to use more up to date Paparazzi and be able to track the development more closely, you should consider installing Paparazzi tools using the source solution described in the next chapter.

== Installation Video Tutorials (On OS X 10.9.* '''Mavericks''') ==

{{#ev:youtubehd|s5KFZqxqAr4}} {{#ev:youtubehd|lXB1y0Dv2y0}}

== Basic Install (Binary Installer) (On OS X 10.9.* '''Mavericks''') ==
If your Apple Mac operation system is OSX Mavericks or newer then the easiest way to get started with Paparazzi on your Apple Mac is to start with the following Basic install. If you have an older version you want to follow the slightly longer Basic install, below.

The steps you need to take to enjoy Paparazzi are:
# Install XQuartz from [http://xquartz.macosforge.org MacOSForge]. (You can alternatively use the X11.app if it is available for your version of Mac OS X.)
# Open the Terminal.app
# Install the command line tools by executing: <source lang="bash">xcode-select --install</source> and clicking on the "Install" button in the dialog that will pop up.
# Install the Paparazzi Tools installer for your OS version from [http://download.paparazziuav.org/darwin/ paparazziuav.org]
## You might get an error saying: "paparazzi-tools-xxxxxx.mpkg can't be opened because it is from an unidentified developer." To get rid of this error you will need to:
### Open "System Preferences"->"Security&Privacy" and change the "Allow apps downloaded from:" setting to "Anywhere". (The option might be greyed out. To activate the selection you will need to authenticate yourself as system administrator. Click on the lock in the left lower corner of the "System Preferences" window, to open the authentication window.)
# Set up your environment variables and Python appropriately using the pprz-env-set script:
## Get the script: <source lang="bash">curl https://raw.githubusercontent.com/paparazzi/paparazzi-portability-support/master/darwin/install/Contents/Resources/pprz-env-set >~/Desktop/pprz-env-set</source>
## Move script to right location: <source lang="bash">sudo mv ~/Desktop/pprz-env-set /opt/paparazzi/bin/pprz-env-set</source>
## Change script permissions: <source lang="bash">sudo chmod 755 /opt/paparazzi/bin/pprz-env-set</source>
## Run the script: <source lang="bash">sudo /opt/paparazzi/bin/pprz-env-set</source>
## Close the terminal. (Do that before you try to move on to the next step. Otherwise the newly set environment will not take effect and you will end up with compilation errors.)
# That's it! To run Paparazzi you need to open the Terminal app and build and run Paparazzi.
## In spotlight type Terminal and then open the Terminal App
## then type: <source lang="bash">cd ~/paparazzi && make && ./paparazzi</source> (The first time you start paparazzi it might take several minutes to show a window. It is because GTK is indexing the fonts the first time it starts up.) (If you get the error: "Fatal error: exception Gtk.error("GtkMain.init: initialization failed ml_gtk_init: initialization failed")" the most likely source of the issue is the lack of X11 server. Install either X11.app or XQuartz as mentioned in step 1.)

Notes:
* the binary installer will check if ~/paparazzi exists on your system. If it does, then the installer does nothing. If this directory does NOT already exist, the installer will automatically clone the Paparazzi Git repository into that directory.
* the binary installer will add a few lines to your ~/.profile for PATH modification and for default PAPARAZZI_HOME and PAPARAZZI_SRC env vars. If you have something other than the default ~/paparazzi installation, please edit your ~/.profile and comment out the env var exports.
* the binary installer creates a symbolic link between the available /opt/paparazzi/bin/python2.7 and /opt/paparazzi/bin/python. Combined with the PATH modification, this will cause <source lang="bash">python something.py</source> to call /opt/paparazzi/bin/python2.7 instead of any system pythons.

== Basic Install (Binary Installer) (Support: 10.7.* '''Lion''', 10.8.* '''Mountain Lion''') ==
If your Apple Mac operation system is OSX Snow Leopard or Lion or newer then the easiest way to get started with Paparazzi on your Apple Mac is to start with the Basic install.

The steps you need to take to enjoy Paparazzi are:
# Install XQuartz from [http://xquartz.macosforge.org MacOSForge]. (You alternatively can install the X11.app from Apple. If it is available for your version of Mac OS X.)
# Install the latest available [http://itunes.apple.com/us/app/xcode/id448457090?mt=12 Xcode] development tool for your OS, we had good success with [http://itunes.apple.com/us/app/xcode/id448457090?mt=12 Xcode] v4.2 on Snow Leopard and v4.3.2 on Lion. For Snow Leopard, Xcode 3.2.6 also works and is still available as a [https://developer.apple.com/downloads/ free download] with an Apple ID (search for ''xcode 3.2.6'').
## With Xcode 4.3 and above you need to install the command line tools. Xcode --> Preferences --> Downloads --> Components --> Command line tools
## Check that the correct version of Xcode is being used for compilation <source lang=bash>/usr/bin/xcodebuild -version</source> It should return the version of Xcode that has been installed, e.g. 4.2. In the rare case you need to change your XCode version run the following command in your terminal: <source lang=bash>sudo /usr/bin/xcode-select -switch /Applications/Xcode.app/Contents/Developer</source>
# Install the Paparazzi Tools installer for your OS version from [http://download.paparazziuav.org/darwin/ paparazziuav.org]
# Set up your environment variables and Python appropriately using the pprz-env-set script:
## Get the script: <source lang="bash">curl https://raw2.github.com/paparazzi/paparazzi-portability-support/master/darwin/install/Contents/Resources/pprz-env-set > ~/Desktop/pprz-env-set</source>
## Move script to right location: <source lang="bash">sudo mv ~/Desktop/pprz-env-set /opt/paparazzi/bin/pprz-env-set</source>
## Change script permissions: <source lang="bash">sudo chmod 755 /opt/paparazzi/bin/pprz-env-set</source>
## Run the script: <source lang="bash">sudo /opt/paparazzi/bin/pprz-env-set</source>
## Close the terminal. (Do that before you try to move on to the next step. Otherwise the newly set environment will not take effect and you will end up with compilation errors.)
# That's it! To run Paparazzi you need to open the Terminal app and build and run Paparazzi.
## In spotlight type Terminal and then open the Terminal App
## then type: <source lang="bash">cd ~/paparazzi && make && ./paparazzi</source> (The first time you start paparazzi it might take several minutes to show a window. It is because GTK is indexing the fonts the first time it starts up.) (If you get the error: "Fatal error: exception Gtk.error("GtkMain.init: initialization failed ml_gtk_init: initialization failed")" the most likely source of the issue is the lack of X11 server. Install either X11.app or XQuartz as mentioned in step 1.)

Notes:
* the binary installer will check if ~/paparazzi exists on your system. If it does, then the installer does nothing. If this directory does NOT already exist, the installer will automatically clone the Paparazzi Git repository into that directory.
* the binary installer will add a few lines to your ~/.profile for PATH modification and for default PAPARAZZI_HOME and PAPARAZZI_SRC env vars. If you have something other than the default ~/paparazzi installation, please edit your ~/.profile and comment out the env var exports.
* the binary installer creates a symbolic link between the available /opt/paparazzi/bin/python2.7 and /opt/paparazzi/bin/python. Combined with the PATH modification, this will cause <source lang="bash">python something.py</source> to call /opt/paparazzi/bin/python2.7 instead of any system pythons.

== Basic Uninstall ==
In the case you would like to uninstall Paparazzi after completing a basic installation, one must type the following in your terminal prompt:

'''Warning''' This first step removes your paparazzi source code, including any changes you may have made yourself locally. If you want to keep your git repository intact, skip this first step and only use the following two steps.

<source lang="bash">rm -rf ~/paparazzi</source>

<source lang="bash">
sudo pprz-env-set -u
</source>

<source lang="bash">
sudo rm -rf /opt/paparazzi
</source>

Note that pprz-env-setup -u removes the entry from ~/.profile and also removes the /opt/paparazzi/bin/python symlink.

== Using Luftboot and PyUSB ==

'''UPDATE:''' The latest binary installer should have PyUSB included by default, no need to install it separately.

If you are planning on loading code onto a Luftboot-equipped STM32 board, you will need to have a Python version on your machine that is active and with [http://sourceforge.net/apps/trac/pyusb/ PyUSB] installed for that version.

To install PyUSB, execute
<source lang="bash">
sudo python setup.py install
</source>
from inside the unzipped PyUSB source directory.

To test which Python version is the default and whether this Python version can find the PyUSB module, in Terminal simply type:
<source lang="bash">
python
</source>
To start the default Python. At the Python prompt (>>>) type:
<source lang="bash">
import usb
</source>
If another prompt line comes up, PyUSB is installed correctly and you will be able to use Luftboot. If an error is thrown, then your configuration is not correct.

== MacPorts and PyUSB ==
If you have MacPorts installed, you can install either <code>py26-pyusb</code>, <code>py26-pyusb-devel</code> or <code>py27-pyusb-devel</code>, depending on which Python(s) you have installed already, or wish to install. For example:
<source lang="bash">
sudo port selfupdate
sudo port install py27-pyusb-devel
</source>

To find out what versions of Python are available on your system (via MacPorts):
<source lang="bash">
port select --list python
</source>
Default Apple Python versions have a -apple ending.

Select a different version of python to be the active version if desired. For example:
<source lang="bash">
sudo port select --set python python27
</source>

A good, working configuration would be to have MacPorts installed, and install <code>py27-pyusb-devel</code>, then ensure that python27 is the active version.

== Adjusting your PATH and Troubleshooting ==

There are sometimes path issues with OS X if you have MacPorts or a similar (Homebrew, Fink) system installed. The reason for this is there may be multiple copies of a binary required for Paparazzi in different places, and depending on the path, the desired instance is not correctly called. This often presents itself as an error when building the main Paparazzi source code. A typical error may involve the <code>pkg-config</code> program. This can often be corrected by checking and adjusting your PATH environment variable.

To check the currently configured default PATH:
<source lang="bash">
echo $PATH
</source>
Ideally, the Paparazzi binary paths (<code>/opt/paparazzi/bin</code> and <code>/opt/paparazzi/sbin</code>) should come first. To move the Paparazzi paths to the highest search priority:
<source lang="bash">
export PATH=/opt/paparazzi/bin:/opt/paparazzi/sbin:$PATH
</source>
This will only be active in the current terminal session. If you wish to manually modify the path permanently, you can edit ~/.profile and add the above line to the bottom of the file.

= Installing from source (MacPorts) =
Note: This is known to work for Mac OS X MountainLion. For newer Mac OS versions you should try the Homebrew based install.

The tools that are required to work with paparazzi on a Mac are installed from MacPorts. All of the commands are given by terminal commands, please open your terminal first.

In case you '''already have MacPorts installed''', it is advised to run the following steps before proceeding:

# check that /opt/local/bin is the first entry in your PATH, easy to check by giving the following command <source lang="bash">echo $PATH</source>
# Then give the following command to make sure your ports are up-to-date <source lang="bash">sudo port selfupdate && sudo port upgrade outdated</source>
..great, you now can run the installation steps starting from step '''4''' below.

If you don't already have MacPorts installed run the following steps:

# Install the latest [http://itunes.apple.com/us/app/xcode/id448457090?mt=12 XCode]. If you are using 10.9 (Mavericks) or newer you just need to run <source lang="bash">xcode-select --install</source>
# If you are using Mountain Lion, X11 is no longer included by default, use the [http://xquartz.macosforge.org/landing/ XQuartz project] to install it.
# Install [http://www.macports.org/install.php MacPorts]
# Edit the file <source lang="bash">/opt/local/etc/macports/sources.conf</source> and above the <source lang="bash">rsync://...</source> line add <source lang="bash">rsync://rsync.paparazziuav.org/macports/ports/</source> It is important that this line comes before the path to the standard ports as some of the Paparazzi ports are intended to replace the standard versions. The file is write protected so it will be necessary to be root in order to edit it. The simplest way is to open a terminal window and use nano thus: <source lang="bash">sudo nano /opt/local/etc/macports/sources.conf</source>
# Now update the available ports with the command: <source lang="bash">sudo port selfupdate</source>
# To install all of the paparazzi prerequisites: <source lang="bash">sudo port install paparazzi-tools</source>
# ...Then go and have lunch, get a coffee, get some sleep. This will probably take a long time.
# After installation, we need to set the correct python to override the default OS X python: <source lang="bash">sudo port select --set python python27</source>
# You can also [[#Changing the GTK look and feel|change the GTK theme]]

Now you can follow the generic instructions for [[Installation|installing the paparazzi source]].

'''NOTE:''' If you had previously used MacPorts to install Paparazzi, you may need to manually uninstall arm-none-eabi-binutils, arm-none-eabi-gcc-linaro, and arm-none-eabi-gdb prior to upgrading paparazzi-tools. libcmsis, libopenstm32 and libopencm3 ports may need to be uninstalled as well. For example:
<source lang="bash">sudo port uninstall -f libcmsis libopenstm32 libopencm3 arm-none-eabi-gdb arm-none-eabi-gcc-linaro arm-none-eabi-binutils</source>

== Lion and XCode 4.3 or newer notes ==

After installing Xcode 4.3 you will need to install the command line tools by opening the XCode preferences pane, Downloads and selecting Command Line Tools for installation. Otherwise you will not find GCC in your unix path.

Also if macports is complaining about xcodebuild and that you should run

<source lang="bash"> sudo xcode-select -switch /Applications/Xcode.app </source>

You should actually run

<source lang="bash"> sudo xcode-select -switch /Applications/Xcode.app/Contents/Developer</source>

so that xcodebuild can find the needed executables for you.

== Troubleshooting ==
If you continually experience problems installing paparazzi or paparazzi-tools then it may be that you have some other conflicting software installed. i.e. an old version of a library in /usr.

One way to work around issues relating to prior MacPort installs that has been found is to clean out everything MacPorts has installed and install from scratch using the latest MacPorts
# <source lang="bash">sudo port -f uninstall installed</source>
# <source lang="bash">sudo port clean --all uninstalled</source>
# <source lang="bash">sudo port selfupdate</source>
# <source lang="bash">sudo port install paparazzi-tools</source>
This was in fact the process used to check that the code installed on a clean machine.

== Upgrading to Lion ==
If you already have MacPorts and Paparazzi installed and running and you then upgrade to Lion you'll probably find that some things are broken. (make can't be found for example)
To remedy this situation you need to do the following:
# Upgrade Xcode to the Lion version. (App Store --> Search for Xcode and install)
# Install the Lion version of [http://www.macports.org/install.php MacPorts]
# <source lang="bash">sudo port -f uninstall installed</source>
# <source lang="bash">sudo port clean --all uninstalled</source>
# <source lang="bash">sudo port selfupdate</source>

Now here you have the opportunity to use the binary installer method detailed above or if installing from source then Macports can be used to build from source thus:

# <source lang="bash">sudo port install paparazzi-tools</source>

If you use a USB to serial converter that isn't based on the FTDI chipset then you may also find that your USB to Serial driver needs to be updated.
# Start console
# Plug in your USB to serial converter
You may get a message similar to this <source lang="bash">Jul 26 23:14:48 Bernies com.apple.kextd[10]: Can't load /System/Library/Extensions/osx-pl2303.kext - no code for running kernel's architecture.</source>

If you are fortunate enough to have a USB to serial converter that is using the PL2303 chipset then the [http://www.prolific.com.tw/eng/downloads.asp?id=31 Prolific] driver should sort you out. Installation instructions are included in the readme.txt and are well worth following.

== Keeping source files for debugging ==
If you wish to debug code using the source install then you'll find that many of the source files for the libraries are missing.

This is because MacPorts cleans up the build artifacts and source files after the installation is complete. This behaviour can be changed by adding the -k option to the port command.

For example:
sudo port -k install paparazzi-tools
This will result in all of the source and build artefact files being left on the hard disk.

Should you later wish to clean up these files you can do so with the clean command.

For example:
sudo port clean installed

== Mavericks Notes ==

'''Q:''' Can not find the command line tools package in XCode any more.

'''A:''' Since Mavericks (10.9) it is not necessary to install xcode to install the command line tools package that is needed for macports and paparazzi. Just run in the command line:
xcode-select --install

'''Q:''' libgcc is not compiling with error:
:info:build The directory that should contain system headers does not exist:
:info:build /usr/include

'''A:''' You probably upgraded from older OS X and are using old command line tools. Make sure to run '''xcode-select --install''' command. This should fix the libgcc compilation error.

DevGuide/CodeEditors

2016-06-10T15:50:07Z

IHaveADrone: spelling

== Introduction ==

So you want to adjust the sourcecode to your wishes, get rid of some bugs that bother you and help to improve the code, great! While theoretically it all an be done with VI and command line instructions, learning to code for Paparazzi this way is a little cumbersome. Therefore it is a good idea to set up an IDE Integrated Development Environment.

As you may have noticed, this page is far from finished, it really would be great if you help to improve this page with even a small improvement.

== IDE for OCAML ==

We start of with OCAML IDE's first

=== EMACS ===
Tuareg is a really nice mode for Emacs. On Ubuntu/Debian just '''apt-get install tuareg-mode'''.

http://www.emacswiki.org/emacs/TuaregMode

=== Netbeans ===

==== Installation ====
First install a reasonable new Netbeans, e.g. v6.8 via the synaptic package manager in Ubuntu or use the commandline

==== OCAML Plugin ====

http://ocamlplugin.loki-a.com/index.php?title=Main_Page

# Start netbeans IDE
# Go to Netbean menu -Tools - Plugins

# Select tab - Settings
# Click the Add button

Name: Ocaml from Loki a
URL: http://ocamlplugin.loki-a.com/ocamlplugin/updates/updates.xml

# Then click the tab "Available plugins"
# Select for install from the list the "Ocaml Plugin"
# Click Install
# Click Install Then Next
# If you see "Signed but not trusted, ignore the message just click "continue"
# If it all worked, you will see "Install completed successfully, just click "Finish"

==== Syntax Highlighting ====

=== Eclipse ===

* [http://www.algo-prog.info/ocaide/ OcaIDE]
* [http://ocamldt.free.fr/ ODT: OCaml Development Tools]

OcaIDE seems to be the best option for Eclipse. Note that OcaIDE requires eclipse to run under Java 7.
No release of ODT since November 2013.

== IDE for Python ==

[http://www.jetbrains.com/pycharm/ PyCharm] is a great Python IDE with awesome completion, code assistance, debugger and git integration and much more...

== IDE for C and CPP ==

Next are the IDE's for C development

=== Netbeans ===
=== Eclipse ===

* [http://eclipse.org/cdt/ Eclipse CDT]

=== Code::Blocks ===

== Debugging tools ==

===GDB===
GDB can be used for quite effective Paparazzi debugging. Debugging [[RT_Paparazzi#Debugging_with_an_Eclipse_IDE|guide]] with Eclipse IDE was already described for [[RT_Paparazzi]], but the exact same steps can be used for classic Paparazzi. The guide is [[RT_Paparazzi#Debugging_with_an_Eclipse_IDE|here]]:

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

Sensors/GPS

2016-06-08T14:22:02Z

IHaveADrone: /* Tips */ sp

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

<br style="clear:both;" />

=GPS Receivers=

An overview of GPS receivers used in combination with Paparazzi. The list is by far not complete. A lot more devices will work flawlessly with Paparazzi. If you have a GPS receiver you have used with Paparazzi that is not listed here, it would be great if you could add that information to this page.
<br style="clear:both;" />

=[http://1bitsquared.com 1BitSquared] [http://1bitsquared.com/products/g0-gps G0 GPS]=

[[Image:G0_GPS_V1_1_Top_with_skirt.jpeg|240px|thumb|left|G0 GPS]]

[http://1bitsquared.com 1BitSquared] sells a Paparazzi UAV compatible GPS module called [[G0]]. It is designed to neatly fit on top of the [[Elle0]] autopilot. It can also be used with any other Paparazzi UAV compatible hardware. [[G0]] GPS module features a large ground plane with optional ground plane skirt, as well as RF shielding on the back of the module.

The large ground plane improves the directionality of the unit helping reject multi-path. When using the [[G0]] GPS unit on a multi-copter it results in less drift when taking off the ground, and improves GPS lock when flying from waypoint to waypoint.

The EMI shielding on the back of the unit decreases the amount of noise injected from the aircraft avionics into the GPS unit, improving the noise to signal ratio. An increased signal results in a more robust satellite lock, and more reliable fully autonomous and guided flight operations.

[[G0]] GPS module is using a U-Blox that is providing very fast speed updates that are crucial for accurate navigation within Paparazzi UAV. Additionally Paparazzi UAV supports the binary U-Blox protocol that is very efficient to parse compared to the very vaguely defined NMEA text protocol. Just enable the UCenter Module in your airframe file and Paparazzi will configure the module for best performance without the need for user interaction.

For more information go to the [[G0|G0 GPS wiki page]].

<br style="clear:both;" />

=[http://swiftnav.com/ Swiftnav] Piksi=

A very special receiver is the OpenSource (almost all...) Swiftnav Piksi GPS receiver. How to use this device with Paparazzi is described on the a specific page
[[Image:Piksi_GPS_back.jpg|200px|thumb|left|Swiftnav Piksi]]
<br style="clear:both;" />

=LS20031 GPS Receiver=

[[Image:ls20031.jpg|170px|thumb|left|LS20031]]
Sparkfun sells the LS20031 GPS module which uses NMEA (Paparazzi support for NMEA is BETA right now.) This Locosys GPS module supports WAAS (U.S. DGPS), EGNOS (EU DGPS), and MSAS (Japanese DGPS).

More information on configuring the GPS via PMTK can be found [http://dallasmakerspace.org/wiki/LS20031_GPS here]
<br style="clear:both;" />

=Globalsat BU 353=

[[Image:BU-353_gps_receiver.jpg|thumb|left|170px|BU-353 GPS receiver]]

USB US Globalsat GPS-Mouse

Typical Uses:

* Parrot AR Drone 2.0
* Ground Station GPS (direct support with Linux / gpsd)

''Not appropriate for many airborne applications due to extra USB-serial circuitry and weight of housing and internal magnet''

Basic compatibility with Windows, Mac and Linux.<br/>
More information at the [[GPS/BU_353]] site.
<br style="clear:both;" />

=uBlox=

[[Image:U-blox_color_warm_60.gif|100px]]
[http://www.u-blox.com uBlox is a Swiss technology company] that develops very good positioning modules. They are the recommended GPS modules for use with Paparazzi autopilots. Note that u-Blox produces the modules only. They do not sell complete boards to end users. These are sold by a multitude of vendors.

Why uBlox:
*Low cost ([[Sensors/GPS#u-blox_NEO-6M|i.e. NEO6-M]])
*Small size
*Excellent performance (u-Blox 7 and 8 series)
*Up to 10Hz update rate
*5V tolerant UART
*Works out of the box with Paparazzi's u-Blox [[Module/GPS_UBlox_UCenter|auto-configuration module]]

The '''[[Tiny]]''' series features an onboard LEA series GPS receiver and patch antenna, while most other boards boards require an external receiver+antenna such as the [[#Paparazzi_Stand-alone_GPS_Receivers|Paparazzi GPS]] or [[#u-Blox_SAM-LS_GPS_Smart_Antenna|SAM-LS]].

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

'''Note:''' The proprietary UBX protocol is used as it offers more information and efficiency than the universal NMEA protocol. For details take a look at the code in <tt>sw/airborne/subsystems/gps/gps_ubx.c</tt>.

==u-Blox LEA Series Receivers==


[[Image:Lea5htiny13.jpg|thumb|left|200px|LEA-5H installed on the Tiny]]
The '''[[Lisa]]''' series, '''[[Twog_v1|TWOG]]''', '''[[Classix]]''' and '''[[Previous_Autopilots|AVR-based]]''' boards require an external GPS module and antenna. The '''[[Tiny]]''' features an integrated receiver and antenna. Either type is designed for [http://www.u-blox.com/ u-blox] 4, 5 and 6 series GPS receivers and the proprietary UBX binary protocol. An external battery or capacitor is typically used to enable the GPS to retain data while powered off for significantly faster signal re-acquisition. Any of the LEA-4, LEA-5 and LEA-6 series receivers can be used including the less expensive LEA-4A, 4S, 5A and 5S and similar low cost 6-series models as the special boot configuration code required for these models is already written as a [[Module/GPS_UBlox_UCenter|module]].

<source lang="xml">

<load name="gps_ubx_ucenter.xml" />
</source>

*4Hz Position update rate
*Supports active or passive antennas
*Supports [http://en.wikipedia.org/wiki/DGPS DGPS], [http://en.wikipedia.org/wiki/WAAS WAAS], [http://en.wikipedia.org/wiki/EGNOS EGNOS], and [http://en.wikipedia.org/wiki/MSAS MSAS]
*Low position noise figure

<br style="clear:both">

==Paparazzi Stand-alone uBlox GPS Receivers==

<gallery>
Image:Ppzgps13med01.jpg|Top
Image:Ppzgps13_lrg_02.jpg|Bottom
</gallery>
<p>Paparazzi source provides a design for an external GPS board. An external GPS board is required for other boards like Lisa, TWOG, Elle0 and Classix.
Programming it is similar to the Tiny2.11 GPS configuration. If you build your own you will want to upload the latest u-blox firmware before you configure. See [[Get Hardware]] for sources of assembled boards.</p>
<p>
The Paparazzi design in https://github.com/paparazzi/paparazzi-hardware/tree/master/sensors/gps/gps_13. The board is very small and light as it has only the components required. It is powered from the 5v line on the "downloads" connector of a TWOG. Also note it is a 4-layer PCB that means better noise resistance. The board has pins for USB connection but requires a different cable and a solder jumper to be move from the ground (default) to 3.3v input to enable the USB port on the module.
</p>
<p>
[http://paparazzi.enac.fr/wiki_images/Gps_13_BOM.xls V1 BOM.xls]<br>
[http://paparazzi.enac.fr/wiki_images/TinygpsBOM.txt Eagle Parts List Output.txt]<br>
See [[Get_Hardware|Get Hardware]] page for suppliers.
</p>

===Wiring Diagram===

{|align = none
|-
|[[Image:TWOG to GPS.jpg|200px|thumb|center|TWOG to Standalone GPS Cable Schematic]]
|[[Image:gps13v09FTDIcable.jpg|200px|thumb|center|GPS13 v0.9 Ucenter cable (ftdi)]]
|[[Image:booz gps.jpg|200px|thumb|center|BoozGPS (quadrotor gps V1.1 2009/5) Ucenter cable (ftdi)]]
|}

===uBlox to ARdrone 2===

[[Image:HowtoConnectUSBHelixGPSForParrotARDrone2.jpg|thumb|left|How to connect USB to uBlox Helix GPS for Parrot ARDrone2]]
To connect a uBlox with Helix antenna via a USB to serial cable that you can just plug into your ARdrone 2
<br style="clear:both;" />

==3rd Party u-blox Reference Design Boards==

<p>
[[Image:LEA5HExternalModulePinout.jpg|thumb|left|LEA-5H Full Board Pinout]]
The only other GPS board in use seems to be u-blox reference designs or similar to it. They have LEA-4H, LEA-5H and LEA-6H (typically) and several interfaces. Often a larger antenna as well.
</p>
<p>
The board in the photo is a [http://www.rfdesign.co.za/pages/5645456/Products/GPS-Products/Receiver-Boards.asp RF DESIGN] LEA-5H-SMART.
</p>
<p>
The jumpers adjacent to the TTL interface connectors need to be closed with low value resistors for paparazzi uart port use. Also a [http://nz.element14.com/jsp/search/productdetail.jsp?SKU=1514218 battery] has to be added with an appropriate charging resistor to enable RTC functionality.
</p>

<br style="clear:both;" />

==NAVILOCK NL-507ETTL==

[[Image:Navilock NL-507ETTL.jpg|thumb|left|NAVILOCK NL-507TTL]]
The NAVILOCK NL-507TTL u-blox TTL Modul 60416 features an LEA-4 series receiver and 25mm patch antenna on a 30mm x 30mm board.
* Datasheet: [http://www.navilock.de/download/Dokumente_SLASH_Sonstiges/60415_-_Datenblatt_u-blox_GPS_Module/481 http://www.navilock.de/download/Dokumente_SLASH_Sonstiges/60415_-_Datenblatt_u-blox_GPS_Module/481]
* Purchase: Available for 28€ at [http://www.amazon.de/Navilock-NL-507TTL-u-blox-TTL-Modul/dp/B0011E6VQG www.amazon.de]
<br style="clear:both;" />

==SPK GS407==

[[Image:GS407.jpg|thumb|left|SPK GS407]]
[https://www.sparkfun.com/products/11466 This] is the model Sparkfun recommends as a replacement for the old GS406. It's essentially the same, but uses the newer 6-series receiver, and is not using a ribbon cable as an interface. It uses [http://www.sarantel.com/products/sl1206 Sarantels] SL1206 active antenna.
It's recommended to buy [https://www.sparkfun.com/products/574 This extension cable] to use with it.
<br style="clear:both;"/>

==u-blox NEO-6M==

[[Image:Hk neo gps.jpg|thumb|left|Hobbyking NEO 6M back]]
This is the cheapest GPS module with antenna for ~13€ at [http://www.hobbyking.com/hobbyking/store/__31135__NEO_6M_GPS_Module.html Hobbyking].

They come with different (sized) patch antenna, mounted on a separate PCB. The main PCB and antenna PCB are fixed with hot glue together and can be separated by hand.
<br style="clear:both;"/>

==Navilock NL-652ETTL==

Nice module with u-blox 6 chip and without the annoying cable that the HK NEO-6m has.
[http://www.navilock.de/produkte/G_61846/merkmale.html?setLanguage=en Navilock NL-652ETTL]

==u-Blox C04-6H Reference Design==

[[Image:abavimage.jpg|thumb|left|u-blox C04-5H]]
u-Blox sells a complete module with antenna for around $200 and will also provide complete schematics, BOM, and PCB files for free if you wish to make your own. Two versions are offered, one with an 18mm patch antenna and the other with the Sarantel P2 helical antenna.
See [http://www.ublox.com/en/evaluation-tools-a-software/reference-designs/for-gps-chips/c04-6h.html http://www.ublox.com/en/evaluation-tools-a-software/reference-designs/for-gps-chips/c04-6h.html] for more info.
<br style="clear:both;" />

==Drotek Boards==
[http://www.drotek.com Drotek's] u-Blox GPS boards work well and are not expensive.

==uBlox GPS configuration==

===using U-Center===

''Note: Before attempting manual configuration consider using the [[Module/GPS_UBlox_UCenter|u-blox UCenter module]] instead. If automatic configuration does not work with more recent modules you should report it to the mailing list or the Gitter chat and may attempt the manual procedure below. But be aware that a wrong configuration can cause Paparazzi not acquiring any GPS lock for sometimes hard to find reasons.''

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

* Note 1: You must [[tunnel|install the UART tunnel firmware]] to enable direct access to the built-in GPS on the [[Tiny|Tiny]].

* Note 2: You will need a driver for your FTDI cable if you run u-center on Windows, which can be found [http://www.ftdichip.com/Drivers/D2XX.htm here].

* Note 3: You can run u-center on Linux by installing "Wine" ([http://www.winehq.org/site/download-deb Installation of Wine]) and set up COM1 as /dev/ttyUSB0. You need to create a symbolic link from the COM device to TTY like this (assuming your serial device is /dev/ttyUSB0):
mkdir -p ~/.wine/dosdevices
ln -s /dev/ttyUSB0 ~/.wine/dosdevices/COM1

or what worked in Ubuntu 9.10

ln -s /dev/ttyUSB0 ~/.wine/dosdevices/com1

This command will create the symbolic link from ttyUSB0 to COM1. See Info on Wine for "dosdevices" setup. Just download the u-setup.exe and run it with Wine, follow prompts. This has been tested with Ubuntu7.10 and Ubuntu 8.04 so far.

''Depending on your connection method and your udev configuration your serial device may have a different path. Just look it up using <code>dmesg</code> or <code>tail -f /var/log/syslog</code> after plugging in.''

The u-blox and Tiny UARTs both operate at 3.3V TTL levels and are 5V TTL tolerant. You must use a level shifter such as the common MAX232 to connect these devices to a standard PC serial port. The easiest and most recommended method is to connect to a USB port instead of serial with an [http://www.ftdichip.com/Products/EvaluationKits/TTL-232R.htm FTDI USB-TTL converter cable] available from Digikey, Mouser, or direct from FTDI. You can also use the [[UU0]] adapter designed and manufactured by [[1BitSquared]]. Instead of a cable it has a USB-A connector directly on the board. Other similar converters are available from [http://www.pololu.com/products/pololu/0391/ pololu] / [http://www.sparkfun.com/commerce/product_info.php?products_id=199 sparkfun]. A stand-alone GPS such as the SAM-LS will require clean 3.3V/50mA power and a common ground with the TTL converter.

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

Start U-center and choose your com port from the pull down list under the connect button near the top left corner of the window. Choose your baudrate from the pull down box to the right of the connect button or select the auto-baud button to the right of that. U-blox default is 9600 baud. This must be changed to 19200 or higher to accommodate the 4Hz update rate. It needs to match whatever your module is configured to (if you configured it with the U-blox U-Center or the [[Module/GPS_UBlox_UCenter|u-blox UCenter module]]).
<br>[[Image:U-center_buttons.jpg|connect, baud, and autobaud buttons]]
<br style="clear:both">

===Uploading the Configuration File===

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

===Automatic Configuration at Startup===

You can also use the [[Module/GPS_UBlox_UCenter|u-blox UCenter module]] which will take over the task of initializing the GPS for you when you power your autopilot.

===Manual Configuration===

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

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

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

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

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

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

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

====LEA-6H====

We use the same configuration as for version 5

# Right Click on the '''NMEA''' Text on top of the tree and choose '''disable child messages'''
# Choose UBX->CFG->NAV5(Navigation 5) - set it to use '''Airborne 8 <4G'''. This tells the Kalman filter to expect significant changes in direction. <p> Note that this setting is only good for faster moving airplanes. For a fixed position hovering heli, 'pedestrian' setting is better </p>
# UBX->CFG->PRT - set '''USART1''' to '''38400bps''' (must match the value in your [[Airframe_Configuration#GPS|Airframe file]])
# Change the baudrate of U-Center to 38400bps if the connection is lost at this point
# UBX->CFG->RATE(Rates) - change the '''Measurement Period''' to '''250ms''' This gives a 4 Hz position update since 4 x 250ms is one second.
# UBX->CFG->SBAS : '''Disable''' (SBAS appears to cause occasional severe altitude calculation errors)
# UBX->NAV (not UBX->CFG->NAV): double click on '''POSLLH, SOL, STATUS, SVINFO, VELNED.''' They should change from grey to black
# UBX->CFG->CFG : '''save current config''', click '''"send"''' in the lower left corner to permanently save these settings to the receiver.<p> Make sure you activate '''"2 - I2C-EEPROM"''' if using a ROM-based NEO chipset with external EEPROM (like [http://www.hobbyking.com/hobbyking/store/__31135__neo_6m_gps_module.html HK 31135])</p>

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

==uBlox Tips==

===Reset to Default Settings===

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

===Invalid argument===

Problem: I keep getting this error with my nice shiny Tiny v2.1 with a LEA-5H: Invalid_argument ("Latlong.of_utm")
Solution: Select the correct [[Subsystem/gps|GPS subsystem]].

===WAAS issues===

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

The default used by the [[Module/GPS_UBlox_UCenter|u-blox UCenter module]] keeps SBAS enabled.

===Assist Now===
u-Blox modules that have a flash memory can keep the almanac correction data for up to 35 days into the future. That will give you a 3d GPS fix within seconds. [https://www.u-blox.com/en/assistnow-lock-your-position-instantly AssitNow] Offline data can be uploaded to the module while it is connected to the u-center application. To use this feature you need to provide a u-Blox account credentials that you can receive from the [https://www.u-blox.com/en/assistnow-service-registration-form u-Blox registration site].

===Antenna options for the Tiny and Paparazzi GPS units===
See [[GPS/Antenna]].

=Tips=

There is a huge amount of good information on the Internet about GPS specifics that gives some good insight into GPS. This Paparazzi wiki is not intended to repeat already available information, some is added here.

==EGNOS==

EGNOS augments the GPS satellite navigation system and makes it suitable for safety critical UAS applications. EGNOS became operational on 1 October 2009. ESA claims that it can determine position to within 2 meters compared with about 20 meters for GPS alone. Note that the service is currently provided only in western Europe. For further information take a look on the [http://www.esa.int/esaNA/egnos.html ESA EGNOS website].

For the latest update about functionality of EGNOS please check the website: [http://www.gsa.europa.eu European GNSS Supervisory Authority]"

==DGPS (Differential GPS)==

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

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

Sensors/GPS

2016-06-08T14:20:28Z

IHaveADrone: spelling

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

<br style="clear:both;" />

=GPS Receivers=

An overview of GPS receivers used in combination with Paparazzi. The list is by far not complete. A lot more devices will work flawlessly with Paparazzi. If you have a GPS receiver you have used with Paparazzi that is not listed here, it would be great if you could add that information to this page.
<br style="clear:both;" />

=[http://1bitsquared.com 1BitSquared] [http://1bitsquared.com/products/g0-gps G0 GPS]=

[[Image:G0_GPS_V1_1_Top_with_skirt.jpeg|240px|thumb|left|G0 GPS]]

[http://1bitsquared.com 1BitSquared] sells a Paparazzi UAV compatible GPS module called [[G0]]. It is designed to neatly fit on top of the [[Elle0]] autopilot. It can also be used with any other Paparazzi UAV compatible hardware. [[G0]] GPS module features a large ground plane with optional ground plane skirt, as well as RF shielding on the back of the module.

The large ground plane improves the directionality of the unit helping reject multi-path. When using the [[G0]] GPS unit on a multi-copter it results in less drift when taking off the ground, and improves GPS lock when flying from waypoint to waypoint.

The EMI shielding on the back of the unit decreases the amount of noise injected from the aircraft avionics into the GPS unit, improving the noise to signal ratio. An increased signal results in a more robust satellite lock, and more reliable fully autonomous and guided flight operations.

[[G0]] GPS module is using a U-Blox that is providing very fast speed updates that are crucial for accurate navigation within Paparazzi UAV. Additionally Paparazzi UAV supports the binary U-Blox protocol that is very efficient to parse compared to the very vaguely defined NMEA text protocol. Just enable the UCenter Module in your airframe file and Paparazzi will configure the module for best performance without the need for user interaction.

For more information go to the [[G0|G0 GPS wiki page]].

<br style="clear:both;" />

=[http://swiftnav.com/ Swiftnav] Piksi=

A very special receiver is the OpenSource (almost all...) Swiftnav Piksi GPS receiver. How to use this device with Paparazzi is described on the a specific page
[[Image:Piksi_GPS_back.jpg|200px|thumb|left|Swiftnav Piksi]]
<br style="clear:both;" />

=LS20031 GPS Receiver=

[[Image:ls20031.jpg|170px|thumb|left|LS20031]]
Sparkfun sells the LS20031 GPS module which uses NMEA (Paparazzi support for NMEA is BETA right now.) This Locosys GPS module supports WAAS (U.S. DGPS), EGNOS (EU DGPS), and MSAS (Japanese DGPS).

More information on configuring the GPS via PMTK can be found [http://dallasmakerspace.org/wiki/LS20031_GPS here]
<br style="clear:both;" />

=Globalsat BU 353=

[[Image:BU-353_gps_receiver.jpg|thumb|left|170px|BU-353 GPS receiver]]

USB US Globalsat GPS-Mouse

Typical Uses:

* Parrot AR Drone 2.0
* Ground Station GPS (direct support with Linux / gpsd)

''Not appropriate for many airborne applications due to extra USB-serial circuitry and weight of housing and internal magnet''

Basic compatibility with Windows, Mac and Linux.<br/>
More information at the [[GPS/BU_353]] site.
<br style="clear:both;" />

=uBlox=

[[Image:U-blox_color_warm_60.gif|100px]]
[http://www.u-blox.com uBlox is a Swiss technology company] that develops very good positioning modules. They are the recommended GPS modules for use with Paparazzi autopilots. Note that u-Blox produces the modules only. They do not sell complete boards to end users. These are sold by a multitude of vendors.

Why uBlox:
*Low cost ([[Sensors/GPS#u-blox_NEO-6M|i.e. NEO6-M]])
*Small size
*Excellent performance (u-Blox 7 and 8 series)
*Up to 10Hz update rate
*5V tolerant UART
*Works out of the box with Paparazzi's u-Blox [[Module/GPS_UBlox_UCenter|auto-configuration module]]

The '''[[Tiny]]''' series features an onboard LEA series GPS receiver and patch antenna, while most other boards boards require an external receiver+antenna such as the [[#Paparazzi_Stand-alone_GPS_Receivers|Paparazzi GPS]] or [[#u-Blox_SAM-LS_GPS_Smart_Antenna|SAM-LS]].

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

'''Note:''' The proprietary UBX protocol is used as it offers more information and efficiency than the universal NMEA protocol. For details take a look at the code in <tt>sw/airborne/subsystems/gps/gps_ubx.c</tt>.

==u-Blox LEA Series Receivers==


[[Image:Lea5htiny13.jpg|thumb|left|200px|LEA-5H installed on the Tiny]]
The '''[[Lisa]]''' series, '''[[Twog_v1|TWOG]]''', '''[[Classix]]''' and '''[[Previous_Autopilots|AVR-based]]''' boards require an external GPS module and antenna. The '''[[Tiny]]''' features an integrated receiver and antenna. Either type is designed for [http://www.u-blox.com/ u-blox] 4, 5 and 6 series GPS receivers and the proprietary UBX binary protocol. An external battery or capacitor is typically used to enable the GPS to retain data while powered off for significantly faster signal re-acquisition. Any of the LEA-4, LEA-5 and LEA-6 series receivers can be used including the less expensive LEA-4A, 4S, 5A and 5S and similar low cost 6-series models as the special boot configuration code required for these models is already written as a [[Module/GPS_UBlox_UCenter|module]].

<source lang="xml">

<load name="gps_ubx_ucenter.xml" />
</source>

*4Hz Position update rate
*Supports active or passive antennas
*Supports [http://en.wikipedia.org/wiki/DGPS DGPS], [http://en.wikipedia.org/wiki/WAAS WAAS], [http://en.wikipedia.org/wiki/EGNOS EGNOS], and [http://en.wikipedia.org/wiki/MSAS MSAS]
*Low position noise figure

<br style="clear:both">

==Paparazzi Stand-alone uBlox GPS Receivers==

<gallery>
Image:Ppzgps13med01.jpg|Top
Image:Ppzgps13_lrg_02.jpg|Bottom
</gallery>
<p>Paparazzi source provides a design for an external GPS board. An external GPS board is required for other boards like Lisa, TWOG, Elle0 and Classix.
Programming it is similar to the Tiny2.11 GPS configuration. If you build your own you will want to upload the latest u-blox firmware before you configure. See [[Get Hardware]] for sources of assembled boards.</p>
<p>
The Paparazzi design in https://github.com/paparazzi/paparazzi-hardware/tree/master/sensors/gps/gps_13. The board is very small and light as it has only the components required. It is powered from the 5v line on the "downloads" connector of a TWOG. Also note it is a 4-layer PCB that means better noise resistance. The board has pins for USB connection but requires a different cable and a solder jumper to be move from the ground (default) to 3.3v input to enable the USB port on the module.
</p>
<p>
[http://paparazzi.enac.fr/wiki_images/Gps_13_BOM.xls V1 BOM.xls]<br>
[http://paparazzi.enac.fr/wiki_images/TinygpsBOM.txt Eagle Parts List Output.txt]<br>
See [[Get_Hardware|Get Hardware]] page for suppliers.
</p>

===Wiring Diagram===

{|align = none
|-
|[[Image:TWOG to GPS.jpg|200px|thumb|center|TWOG to Standalone GPS Cable Schematic]]
|[[Image:gps13v09FTDIcable.jpg|200px|thumb|center|GPS13 v0.9 Ucenter cable (ftdi)]]
|[[Image:booz gps.jpg|200px|thumb|center|BoozGPS (quadrotor gps V1.1 2009/5) Ucenter cable (ftdi)]]
|}

===uBlox to ARdrone 2===

[[Image:HowtoConnectUSBHelixGPSForParrotARDrone2.jpg|thumb|left|How to connect USB to uBlox Helix GPS for Parrot ARDrone2]]
To connect a uBlox with Helix antenna via a USB to serial cable that you can just plug into your ARdrone 2
<br style="clear:both;" />

==3rd Party u-blox Reference Design Boards==

<p>
[[Image:LEA5HExternalModulePinout.jpg|thumb|left|LEA-5H Full Board Pinout]]
The only other GPS board in use seems to be u-blox reference designs or similar to it. They have LEA-4H, LEA-5H and LEA-6H (typically) and several interfaces. Often a larger antenna as well.
</p>
<p>
The board in the photo is a [http://www.rfdesign.co.za/pages/5645456/Products/GPS-Products/Receiver-Boards.asp RF DESIGN] LEA-5H-SMART.
</p>
<p>
The jumpers adjacent to the TTL interface connectors need to be closed with low value resistors for paparazzi uart port use. Also a [http://nz.element14.com/jsp/search/productdetail.jsp?SKU=1514218 battery] has to be added with an appropriate charging resistor to enable RTC functionality.
</p>

<br style="clear:both;" />

==NAVILOCK NL-507ETTL==

[[Image:Navilock NL-507ETTL.jpg|thumb|left|NAVILOCK NL-507TTL]]
The NAVILOCK NL-507TTL u-blox TTL Modul 60416 features an LEA-4 series receiver and 25mm patch antenna on a 30mm x 30mm board.
* Datasheet: [http://www.navilock.de/download/Dokumente_SLASH_Sonstiges/60415_-_Datenblatt_u-blox_GPS_Module/481 http://www.navilock.de/download/Dokumente_SLASH_Sonstiges/60415_-_Datenblatt_u-blox_GPS_Module/481]
* Purchase: Available for 28€ at [http://www.amazon.de/Navilock-NL-507TTL-u-blox-TTL-Modul/dp/B0011E6VQG www.amazon.de]
<br style="clear:both;" />

==SPK GS407==

[[Image:GS407.jpg|thumb|left|SPK GS407]]
[https://www.sparkfun.com/products/11466 This] is the model Sparkfun recommends as a replacement for the old GS406. It's essentially the same, but uses the newer 6-series receiver, and is not using a ribbon cable as an interface. It uses [http://www.sarantel.com/products/sl1206 Sarantels] SL1206 active antenna.
It's recommended to buy [https://www.sparkfun.com/products/574 This extension cable] to use with it.
<br style="clear:both;"/>

==u-blox NEO-6M==

[[Image:Hk neo gps.jpg|thumb|left|Hobbyking NEO 6M back]]
This is the cheapest GPS module with antenna for ~13€ at [http://www.hobbyking.com/hobbyking/store/__31135__NEO_6M_GPS_Module.html Hobbyking].

They come with different (sized) patch antenna, mounted on a separate PCB. The main PCB and antenna PCB are fixed with hot glue together and can be separated by hand.
<br style="clear:both;"/>

==Navilock NL-652ETTL==

Nice module with u-blox 6 chip and without the annoying cable that the HK NEO-6m has.
[http://www.navilock.de/produkte/G_61846/merkmale.html?setLanguage=en Navilock NL-652ETTL]

==u-Blox C04-6H Reference Design==

[[Image:abavimage.jpg|thumb|left|u-blox C04-5H]]
u-Blox sells a complete module with antenna for around $200 and will also provide complete schematics, BOM, and PCB files for free if you wish to make your own. Two versions are offered, one with an 18mm patch antenna and the other with the Sarantel P2 helical antenna.
See [http://www.ublox.com/en/evaluation-tools-a-software/reference-designs/for-gps-chips/c04-6h.html http://www.ublox.com/en/evaluation-tools-a-software/reference-designs/for-gps-chips/c04-6h.html] for more info.
<br style="clear:both;" />

==Drotek Boards==
[http://www.drotek.com Drotek's] u-Blox GPS boards work well and are not expensive.

==uBlox GPS configuration==

===using U-Center===

''Note: Before attempting manual configuration consider using the [[Module/GPS_UBlox_UCenter|u-blox UCenter module]] instead. If automatic configuration does not work with more recent modules you should report it to the mailing list or the Gitter chat and may attempt the manual procedure below. But be aware that a wrong configuration can cause Paparazzi not acquiring any GPS lock for sometimes hard to find reasons.''

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

* Note 1: You must [[tunnel|install the UART tunnel firmware]] to enable direct access to the built-in GPS on the [[Tiny|Tiny]].

* Note 2: You will need a driver for your FTDI cable if you run u-center on Windows, which can be found [http://www.ftdichip.com/Drivers/D2XX.htm here].

* Note 3: You can run u-center on Linux by installing "Wine" ([http://www.winehq.org/site/download-deb Installation of Wine]) and set up COM1 as /dev/ttyUSB0. You need to create a symbolic link from the COM device to TTY like this (assuming your serial device is /dev/ttyUSB0):
mkdir -p ~/.wine/dosdevices
ln -s /dev/ttyUSB0 ~/.wine/dosdevices/COM1

or what worked in Ubuntu 9.10

ln -s /dev/ttyUSB0 ~/.wine/dosdevices/com1

This command will create the symbolic link from ttyUSB0 to COM1. See Info on Wine for "dosdevices" setup. Just download the u-setup.exe and run it with Wine, follow prompts. This has been tested with Ubuntu7.10 and Ubuntu 8.04 so far.

''Depending on your connection method and your udev configuration your serial device may have a different path. Just look it up using <code>dmesg</code> or <code>tail -f /var/log/syslog</code> after plugging in.''

The u-blox and Tiny UARTs both operate at 3.3V TTL levels and are 5V TTL tolerant. You must use a level shifter such as the common MAX232 to connect these devices to a standard PC serial port. The easiest and most recommended method is to connect to a USB port instead of serial with an [http://www.ftdichip.com/Products/EvaluationKits/TTL-232R.htm FTDI USB-TTL converter cable] available from Digikey, Mouser, or direct from FTDI. You can also use the [[UU0]] adapter designed and manufactured by [[1BitSquared]]. Instead of a cable it has a USB-A connector directly on the board. Other similar converters are available from [http://www.pololu.com/products/pololu/0391/ pololu] / [http://www.sparkfun.com/commerce/product_info.php?products_id=199 sparkfun]. A stand-alone GPS such as the SAM-LS will require clean 3.3V/50mA power and a common ground with the TTL converter.

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

Start U-center and choose your com port from the pull down list under the connect button near the top left corner of the window. Choose your baudrate from the pull down box to the right of the connect button or select the auto-baud button to the right of that. U-blox default is 9600 baud. This must be changed to 19200 or higher to accommodate the 4Hz update rate. It needs to match whatever your module is configured to (if you configured it with the U-blox U-Center or the [[Module/GPS_UBlox_UCenter|u-blox UCenter module]]).
<br>[[Image:U-center_buttons.jpg|connect, baud, and autobaud buttons]]
<br style="clear:both">

===Uploading the Configuration File===

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

===Automatic Configuration at Startup===

You can also use the [[Module/GPS_UBlox_UCenter|u-blox UCenter module]] which will take over the task of initializing the GPS for you when you power your autopilot.

===Manual Configuration===

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

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

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

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

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

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

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

====LEA-6H====

We use the same configuration as for version 5

# Right Click on the '''NMEA''' Text on top of the tree and choose '''disable child messages'''
# Choose UBX->CFG->NAV5(Navigation 5) - set it to use '''Airborne 8 <4G'''. This tells the Kalman filter to expect significant changes in direction. <p> Note that this setting is only good for faster moving airplanes. For a fixed position hovering heli, 'pedestrian' setting is better </p>
# UBX->CFG->PRT - set '''USART1''' to '''38400bps''' (must match the value in your [[Airframe_Configuration#GPS|Airframe file]])
# Change the baudrate of U-Center to 38400bps if the connection is lost at this point
# UBX->CFG->RATE(Rates) - change the '''Measurement Period''' to '''250ms''' This gives a 4 Hz position update since 4 x 250ms is one second.
# UBX->CFG->SBAS : '''Disable''' (SBAS appears to cause occasional severe altitude calculation errors)
# UBX->NAV (not UBX->CFG->NAV): double click on '''POSLLH, SOL, STATUS, SVINFO, VELNED.''' They should change from grey to black
# UBX->CFG->CFG : '''save current config''', click '''"send"''' in the lower left corner to permanently save these settings to the receiver.<p> Make sure you activate '''"2 - I2C-EEPROM"''' if using a ROM-based NEO chipset with external EEPROM (like [http://www.hobbyking.com/hobbyking/store/__31135__neo_6m_gps_module.html HK 31135])</p>

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

==uBlox Tips==

===Reset to Default Settings===

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

===Invalid argument===

Problem: I keep getting this error with my nice shiny Tiny v2.1 with a LEA-5H: Invalid_argument ("Latlong.of_utm")
Solution: Select the correct [[Subsystem/gps|GPS subsystem]].

===WAAS issues===

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

The default used by the [[Module/GPS_UBlox_UCenter|u-blox UCenter module]] keeps SBAS enabled.

===Assist Now===
u-Blox modules that have a flash memory can keep the almanac correction data for up to 35 days into the future. That will give you a 3d GPS fix within seconds. [https://www.u-blox.com/en/assistnow-lock-your-position-instantly AssitNow] Offline data can be uploaded to the module while it is connected to the u-center application. To use this feature you need to provide a u-Blox account credentials that you can receive from the [https://www.u-blox.com/en/assistnow-service-registration-form u-Blox registration site].

===Antenna options for the Tiny and Paparazzi GPS units===
See [[GPS/Antenna]].

=Tips=

There is a huge amount of good information on the internet about GPS specifics that gives some good insight into GPS. This Paparazzi wiki is not intended to repeat already available information, some is added here.

==EGNOS==

EGNOS augments the GPS satellite navigation system and makes it suitable for safety critical UAS applications. EGNOS became operational on 1 October 2009. ESA claims that it can determine position to within 2 meters compared with about 20 meters for GPS alone. Note that the service is currently provided only in western Europe. For further information take a look on the [http://www.esa.int/esaNA/egnos.html ESA EGNOS website].

For the latest update about functionality of EGNOS please check the website: [http://www.gsa.europa.eu European GNSS Supervisory Authority]"

==DGPS (Differential GPS)==

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

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

STLink

2016-06-08T14:14:31Z

IHaveADrone: spelling

<div style="float: right; width: 20%">
<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Firmware Flashing</categorytree>
</div>

<div style="float: right; width: 60%">
[[Image:St-link.jpg|right|450px]]
</div>
__TOC__

Every STM discovery / eval board comes with a [http://www.st.com/web/catalog/tools/FM146/CL1984/SC724/SS1677/PF251168 ST-Link V2] on board, with one exception; the STM32VL version comes with a ST-Link V1.

==SWD Header==

[[Image:swd_header_discovery_board.png|250px|Pinout with Apogee connector]]

==Install Software==

The ''st-flash'' and ''st-util'' tools are needed, provided by [https://github.com/texane/stlink texane]

Download and compile
$ cd /opt
$ git clone git://github.com/texane/stlink.git stlink
$ cd stlink
$ ./autogen.sh
$ ./configure
$ make

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

Add udev rules
$ sudo cp /opt/stlink/49-stlinkv*.rules /etc/udev/rules.d
$ sudo udevadm control --reload-rules

ST-LinkV1 requires a bit different treatment, read the [https://github.com/texane/stlink/blob/master/README Readme.txt]

==Airframe.xml setup==

Connect the ST-Link to the MCU.
If a complete STM32Fx-Discovery board is used, CN3 jumpers need to be set. To program a external MCU, remove CN3 jumpers and connect the external MCU with the SWD header.

To use SWD via STLink as default:<br/>
Set '''FLASH_MODE=STLINK'''<br/>

==Update the ST-Link to blackmagic probe==

The STM32F103 (STLink MCU) can be flashed with the blackmagic's firmware.<br/>

===Two STLinkV2 Method===

Use one STLink to flash another

Hardware Setup:
One STLinkV2 (connected via USB) is programming the other one. Change the 4 Solder jumpers on the bottom of the target STLinkV2 from "DEFAULT" to "REVERSED".<br/>

Connections between the two STLinks
{|border="1" cellspacing="0" style="text-align:center" cellpadding="6"
|+'''Connections [Header-Pin]'''
!''Use''!!''From Programmer''!!''To Target''
|-
|5V||P2-5V||P2-5V
|-
|SWDIO||CN2-4||CN3-2
|-
|SWDCLK||CN2-2||CN3-3
|-
|GND||CN2-3||CN3-4
|}

Download and build the Firmware
git clone https://github.com/blacksphere/blackmagic
cd blackmagic
git submodule init
git submodule update
make
cd src
make clean
make PROBE_HOST=stlink

Remove the readout protection, erase and flash
openocd -f interface/stlink-v2.cfg -f target/stm32f1x_stlink.cfg -c "init" -c "halt" -c "stm32f1x unlock 0" -c "shutdown"
st-flash erase
st-flash --reset write blackmagic.bin 0x8002000
st-flash write blackmagic_dfu.bin 0x8000000

====Documentation====

[http://esden.net/2014/12/29/black-magic-discovery Black Magic Discovery from Esden] <-- This also describes how to remove the read out protection. <br/>
[http://embdev.net/articles/STM_Discovery_as_Black_Magic_Probe embdev.net page]

===BMP Method===

Use a BMP to flash a STLink

Transfer the solder jumpers from "Default" to "Reversed" and build the firmware as described above.<br/>
Connect the BMP to the CN2 header (see Pinout above).

Start gdb, erase the option bytes and flash BMP
(gdb) target extended-remote /dev/ttyACM0
(gdb) mon swdp_scan
(gdb) att 1
(gdb) mon option erase
(gdb) load /dir/to/blackmagic
(gdb) load /dir/to/blackmagic_dfu
(gdb) detach

The option bytes do not cover the Readout Protection (RDP), but the RDP is disabled anyhow...

'''Error at loading a new image after removing RDP'''

Error erasing flash with vFlashErase packet
If this occurs powercycle the target (disconnect and reconnect the 3V3 connection), swd scan, attach and try loading the image again. Usually the reset of the RDP requires a flash erase (done by mon option erase) and reset.

Probably this can also be done via gdb.

==Clones==

There are also a lot of different Chinese clones out there. Most with an identical MCU as the original STLinkV2, some with an STM32F101.

It seems that each clone has its own programming pinout, so better double check (continuity tester) than to release the magic smoke...

Most (all?) should work with the "stlink" target from Blackmagic Probe, since they probably use the same firmware from the original STLinkV2.

===Red PCB===

Seems to work with the standard stlink BMP image.

[[Image:stlinkv2_clone_red_front.jpg|250px]]
[[Image:stlinkv2_clone_red_back.jpg|250px]]

* STM32F103C8T6

Programming header (1.27mm, populated on the images) from the Mini USB to the Pin header (right to left on the image), used for programming the onboard MCU.

# SWDIO
# GND
# SWDCLK
# 3V3

Some Images and details about this hardware can be found at[https://www.mikrocontroller.net/articles/IRMP_auf_STM32_-_Bauanleitung]

===Blue PCB===
NOT TESTED YET
[[Image:stlinkv2_clone_blue_front.jpg|250px]]
[[Image:stlinkv2_clone_blue_back.jpg|250px]]

* STM32F103C8T6

Programming header (2.54mm, unpopulated on the images) from the USB to the Pin header (left to the right on the images), used for programming the onboard MCU.

# GND
# 5V
# USART1 RX (PA10)
# USART1 TX (PA9)

Bootloader header (2.54mm, unpopulated on the images), from the USB to the Pin header (left to the right on the images), used for USART bootloader activation

# 3V3
# BOOT0 (pin 44)

The 3V3/5V switch selects the input voltage for the onboard MCU.

===Aluminium housing===
NOT TESTED YET
[[Image:stlinkv2_clone_aluminium.jpg|250px]]
[[Image:stlinkv2_clone_aluminium_front.jpg|250px]]
[[Image:stlinkv2_clone_aluminium_back.jpg|250px]]

* STM32F101C8T6

Programming header (1.27mm, unpopulated on the images) from the USB to the Pin header (left to the right on the images), used for programming the onboard MCU.

# SWDIO (PA13)
# GND
# SWDCLK(PA14)
# VDD, VBAT

To disassemble pull the aluminium housing towards the USB connector.

This has not the same hardware as https://github.com/blacksphere/blackmagic/issues/62 , but the same MCU, seems that this has just an other PCB.

[[Category:Firmware Flashing]] [[Category:Developer_Documentation]]

Subsystem/ahrs

2016-06-08T13:53:50Z

IHaveADrone: minor spelling

<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages hideprefix=always>Subsystems</categorytree>
== AHRS subsystem ==
The '''A'''ttitude and '''H'''eading '''R'''eference '''S'''ystem subsystem specifies which attitude estimation filter you are using.

Currently possible AHRS subsystem types are:

{| class="wikitable" style="text-align:center" border="1"
! Type !! Point type !! Firmwares !! Notes
|-
|'''[[Subsystem/ahrs#Complementary_Quaternion_.28fixed_point.29|int_cmpl_quat]]''' || fixed || all ||
|-
|'''[[Subsystem/ahrs#Complementary_Quaternion.2FRotation_Matrix_.28floating_point.29|float_cmpl]]''' || floating || all ||
|-
|'''[[Subsystem/ahrs#DCM_.28floating_point.29|float_dcm]]''' || floating || fixedwing ||
|-
|'''[[Subsystem/ahrs#Complementary_Euler_.28fixed_point.29|int_cmpl_euler]]''' || fixed || rotorcraft ||
|-
|'''[[Subsystem/ahrs#Kalman_Filter_Quaternion|float_mlkf]]''' || floating || rotorcraft ||
|-
| '''[[Subsystem/ahrs#Infrared|infrared]]''' || || fixedwing? ||
|}

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

== Implementations ==

There is a test program ( sw/airborne/test/ahrs/compare_ahrs.py ) to compare different AHRS implementations on simple test cases.

<span style="color:#FF0000">'''Caution!'''</span> '''Please also see [https://github.com/paparazzi/paparazzi/issues/93 issue 93] about proper handling of BODY_TO_IMU in all AHRS algorithms.'''

=== Complementary Quaternion (fixed point) ===

To measure attitude angles, gyrometers measurements are integrated. The result of integration is accurate for short term, but gyro bias is accumulated, which results in long term errors (drift).
On the other hand, accelerometers can be used to measure angles directly, but they suffer from noise due to vibrations. The measurement is then only accurate when averaged over a long term. Also, accelerometers alone are unable to give accurate angles when the vehicle is accelerating.
Complementary filter takes advantage of both sensors, using a low-pass filter on accelerometer readings and high pass filter on gyrometers readings, to estimate attitude angles.
* No danger of [http://en.wikipedia.org/wiki/Gimbal_lock gimbal lock], since quaternions are used.
* The arithmetic is [http://en.wikipedia.org/wiki/Fixed-point_arithmetic fixed point] and is thus suitable if the processor (on your board) has no [http://en.wikipedia.org/wiki/Floating_point_unit FPU].
* Estimates the gyro bias.
* For rotorcrafts: uses magnetometer for heading. Needs calibration!<br/>You can add <source lang="xml" enclose="none"><configure name="USE_MAGNETOMETER" value="TRUE"/></source> to be explicit about it.
* Also suitable for fixedwings, but you need GPS.
** Compensation of centrifugal force via GPS speed (to fly in circles with a fixedwing).<br/>Enabled with AHRS_GRAVITY_UPDATE_COORDINATED_TURN which is set by default for a fixedwing firmware.
** For fixedwing firmware, GPS course is used for heading estimation by default (and magnetometer disabled), add <source lang="xml" enclose="none"><configure name="USE_MAGNETOMETER" value="FALSE"/></source> if you want to be explicit.
** To use magnetometer for heading: <source lang="xml" enclose="none"><configure name="USE_MAGNETOMETER" value="TRUE"/></source> and <source lang="xml" enclose="none"><configure name="AHRS_USE_GPS_HEADING" value="FALSE"/></source>

Other flags of interest are:
*AHRS_PROPAGATE_LOW_PASS_RATES : apply a low pass filter on rotational velocity
*AHRS_MAG_UPDATE_ALL_AXES : use mag to also update roll/pitch and not only yaw (not recommended in most cases)

* NEW since [https://github.com/paparazzi/paparazzi/commit/b40da0ae56e861e088017c01426d0c4ed7c43350 v5.1_devel-455-gb40da0a]:
** Proper scaling of corrections for 100Hz fixedwing or 500Hz for rotorcraft.
** Allow tuning of the accel and mag correction natural frequency and damping.
** Tunable gravity_heuristic_factor to reduce accelerometer influence only when the vehicle is accelerating (norm of ax,ay,az ~ 9,81 m/s2).

* Flags of interest in master branch are:
** AHRS_PROPAGATE_FREQUENCY: IMU gyrometer reading frequency ( Hz, depend on IMU subsystem used and its configuration)
** AHRS_CORRECT_FREQUENCY: IMU accelerometer reading frequency (Hz)
** AHRS_MAG_CORRECT_FREQUENCY: IMU magnetometer reading frequency (Hz)
** AHRS_ACCEL_OMEGA: Complementary filter accelerometer cut-off frequency (rd/s). Default is 0.063 rd/s, the accelerometer reading are "averaged" over 100 seconds (= 2*pi/0.063) to correct gyro bias. Lower the cut-off frequency reduce the influence of accelerometers. WARNING: if ACCEL_OMEGA is set at a lower frequency, the gyro bias variations may not be corrected fast enough. As a result, the computed attitude may show significant static (or low frequency) errors. If accel_omega is set higher, the gyro bias will be well corrected and the static accuracy of the computed angle will be very good, but the dynamic error of the computed angle may be bad.
** AHRS_ACCEL_ZETA: Complementary filter accelerometer damping. Default is 0.9
** AHRS_MAG_OMEGA:Complementary filter magnetometer cut-off frequency (rd/s). Default is 0.04 rd/s. Acts the same as accelerometer but on the yaw axis.
** AHRS_MAG_ZETA:Complementary filter magnetometer damping. Default is 0.9
** AHRS_GRAVITY_HEURISTIC_FACTOR: Default is 30. Reduce accelerometer cut-off frequency when the vehicle is accelerating: norm(ax,ay,az) ~ 9,81 m/s2. WARNING: when the IMU is not well damped, the norm of accelerometers never equals to 9,81 m/s2. As a result, the GRAVITY_HEURISTIC_FACTOR will reduce the accelerometer bandwith even if the vehicle is not accelerating. Set AHRS_GRAVITY_HEURISTIC_FACTOR = 0 in case of vibrations.
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
<subsystem name="ahrs" type="int_cmpl_quat"/>
</firmware>

<section name="AHRS" prefix="AHRS_">
<define name="H_X" value=" 0.51562740288882"/>
<define name="H_Y" value="-0.05707735220832"/>
<define name="H_Z" value=" 0.85490967783446"/>
</section>
</source>
}}

Also see the [[Subsystem/ahrs#Local_Magnetic_Field|Local Magnetic Field]] section.

To use '''int_cmpl_quat''' for fixedwings without magnetometer (GPS based heading estimation instead):
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing">
...
<subsystem name="ahrs" type="int_cmpl_quat"/>
<configure name="USE_MAGNETOMETER" value="FALSE"/>
</firmware>
</source>
}}

=== Complementary Quaternion/Rotation Matrix (floating point) ===
* Estimates the gyro bias.
* By default uses magnetometer for heading for rotorcrafts.
* Choose either ''type="float_cmpl_rmat"'' or ''type="float_cmpl_quat"'', which define ''AHRS_PROPAGATE_RMAT'' or ''AHRS_PROPAGATE_QUAT'' respectively to select if the propagation is done in rotation matrix or quaternion representation.
* For fixedwings:
** Compensation of centrifugal force via GPS speed (to fly in circles with a fixedwing).<br/>Enabled with AHRS_GRAVITY_UPDATE_COORDINATED_TURN which is set by default for a fixedwing firmware.
** GPS based heading estimation: https://github.com/paparazzi/paparazzi/issues/130
Other flags of interest are:
* AHRS_PROPAGATE_LOW_PASS_RATES : apply a low pass filter on rotational velocity
* AHRS_MAG_UPDATE_ALL_AXES : use mag to also update roll/pitch and not only yaw (not recommended in most cases)
* AHRS_GRAVITY_HEURISTIC_FACTOR: Default is 30. Reduce accelerometer cut-off frequency when the vehicle is accelerating: norm(ax,ay,az) ~ 9,81 m/s2. WARNING: when the IMU is not well damped, the norm of accelerometers never equals to 9,81 m/s2. As a result, the GRAVITY_HEURISTIC_FACTOR will reduce the accelerometer bandwith even if the vehicle is not accelerating. Set AHRS_GRAVITY_HEURISTIC_FACTOR = 0 in case of vibrations

{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="rotorcraft or fixedwing">
...
<subsystem name="ahrs" type="float_cmpl_quat">
</subsystem>
</firmware>

<section name="AHRS" prefix="AHRS_">
<define name="H_X" value=" 0.51562740288882"/>
<define name="H_Y" value="-0.05707735220832"/>
<define name="H_Z" value=" 0.85490967783446"/>
</section>
</source>
}}

Also see the [[Subsystem/ahrs#Local_Magnetic_Field|Local Magnetic Field]] section.

<p>
No danger of [http://en.wikipedia.org/wiki/Gimbal_lock gimbal lock], since quaternions are used.
<br/>
Suitable for fixedwings. Needs GPS!
<br/>
Suitable for rotorcraft if the magnetometer is calibrated.
<br/>
The arithmetic is [http://en.wikipedia.org/wiki/Floating_point floating point] and is thus '''not''' suitable if the processor (on your board) has '''no''' [http://en.wikipedia.org/wiki/Floating_point_unit FPU].
</p>

=== DCM (floating point) ===
* No direct gyro bias estimation, but also compensates for attitude drift.
* Uses GPS speed for heading.
* Compensation of centrifugal force via GPS speed (to fly in circles with a fixedwing).
* '''Careful, it doesn't handle all BODY_TO_IMU rotations (mounting positions) correctly!'''

The algorithm was developed by William Premerlani and Paul Bizard. The theory can be found here: [[Media:DCMDraft2.pdf|DCMDraft2.pdf]] The algorithm is also used in the AHRS systems of the AdruIMU.
The name DCM for the algorithm is really a misnomer, as that just means that the orientation is represented as a '''D'''irection'''C'''osine'''M'''atrix (rotation matrix). But since people already know it under that name, we kept it.

Other flags of interest are:
*USE_MAGNETOMETER : use magnetometer to update yaw (UNTESTED. The magnetometer code has to be improved, since ferromagnetic materials affect the magnetic field. This is currently not implemented.)
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing">
...
<subsystem name="ahrs" type="float_dcm"/>
</firmware>
</source>
}}

=== Complementary Euler (fixed point) ===
* Not recommended for fixedwings, as this filter doesn't compensate for centrifugal force when flying turns.
* Magnetometer is always only used for heading (yaw).
* '''Does not handle the accel and mag updates correctly if BODY_TO_IMU is used for more than just adjustment by a few degrees.'''
* In general, rather use ''[[Subsystem/ahrs#Complementary_Quaternion_.28fixed_point.29|int_cmpl_quat]]''

Optional flags/defines are:
* FACE_REINJ_1 : defaults to 1024
* IMU_MAG_OFFSET : offset to subtract from the heading calculated by the magnetometer
* USE_NOISE_FILTER : apply a simple filter on the rate and accel inputs
* USE_NOISE_CUT : cut rate input at 1 rad/s and accel input at 20m/s²

{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="rotorcraft">
...
<subsystem name="ahrs" type="int_cmpl_euler"/>
</firmware>

<section name="MISC">
<define name="FACE_REINJ_1" value="1024"/> 
</section>
</source>
}}

<p>
Possible danger of [http://en.wikipedia.org/wiki/Gimbal_lock gimbal lock], since quaternions are not used.
<br/>
Repeat from above: '''Not''' suitable for fixedwings.
<br/>
Suitable for rotorcraft. The magnetometer is used to determine the yaw and needs to be calibrated.
Recommended replacement: [[Subsystem/ahrs#Complementary_Quaternion_.28fixed_point.29|int_cmpl_quat]]
<br/>
The arithmetic is [http://en.wikipedia.org/wiki/Fixed-point_arithmetic fixed point] and is thus suitable if the processor (on your board) has no [http://en.wikipedia.org/wiki/Floating_point_unit FPU].
</p>

=== Kalman Filter Quaternion ===
Multiplicative Linearized [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter] in quaternion formulation.
* Available in v5.0 and later
* Estimates the gyro bias.
* Uses magnetometer to update all 3 axes.
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="rotorcraft">
...
<subsystem name="ahrs" type="float_mlkf"/>
</firmware>

<section name="AHRS" prefix="AHRS_">
<define name="H_X" value=" 0.51562740288882"/>
<define name="H_Y" value="-0.05707735220832"/>
<define name="H_Z" value=" 0.85490967783446"/>
</section>
</source>
}}

Also see the [[Subsystem/ahrs#Local_Magnetic_Field|Local Magnetic Field]] section.

<p>
No danger of [http://en.wikipedia.org/wiki/Gimbal_lock gimbal lock], since quaternions are used.
<br/>
'''Not''' suitable for fixedwings!
<br/>
Suitable for rotorcraft. The magnetometer is used and needs to be well calibrated.
Estimates attitude and heading. Does not use GPS.
<br/>
The arithmetic is [http://en.wikipedia.org/wiki/Floating_point floating point] and is thus '''not''' suitable if the processor (on your board) has '''no''' [http://en.wikipedia.org/wiki/Floating_point_unit FPU].
</p>

=== Infrared ===
For use with infrared sensors that detect aircraft attitude and the [[Module/infrared| infrared module]].

== Local Magnetic Field ==
[[Image:Noaa_mag_data.png|thumb|right|200px|Screenshot of noaa page]]
[[Image:Normalised_mag_fields.png|thumb|right|200px|Screenshot of scilab page]]
'''This is needed if the magnetometer should be used !'''<br/>
Take also a look at [[ImuCalibration#Calibrating_for_the_Earth_magnetic_field| magnetometer calibration]] which should be done to increase accuracy !

First the values of the local magnetic field vector are needed. They can be found at the states geological institute.

USA [http://www.ngdc.noaa.gov/geomag-web/#igrfwmm ngdc.noaa.gov]

Needed values are:
* north component (x)
* east component (y)
* vertical component (z)

The vector components are in nanotesla (nT) but AHRS needs these values as a unit vector (the length of a unit vector is 1), so they need to be normalized.

'''Convert them:'''

Copy the north(x), east(y), and vertical(z) component values into scilab and execute "X/norm(X)" or run this in ipython:

<source lang=python>
import numpy as np
x = np.array([20875.1, 8480.2, -51279.8])
x/np.linalg.norm(x)
</source>

or enter this into [http://wolframalpha.com Wolfram Alpha]:
<source lang=python>
Normalize[{20875.1, 8480.2, -51279.8}]
</source>

Lastly, enter the results into your airframe file as H_X, H_Y, and H_Z:
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<section name="AHRS" prefix="AHRS_">
<define name="H_X" value="0.372692"/>
<define name="H_Y" value="0.151401"/>
<define name="H_Z" value="-0.915521"/>
</section>
</source>
}}

=== Update geomagnetic field vector based on GPS ===
You can also add the [http://docs.paparazziuav.org/latest/module__geo_mag.html geo_mag.xml module], which will update the normalized magnetic field at startup using GPS fix:
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<modules>
<load name="geo_mag.xml"/>
</modules>
</source>
}}

== Enabling External Sensors ==

By default the AHRS algorithms will utilize onboard sensors. Paparazzi currently has support for external Magnetometers. In order to use an external sensor you must specify the ABI Message ID of the sensor.

{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<subsystem name="ahrs" type="float_cmpl_quat">
<define name="AHRS_FC_MAG_ID" value="MAG_HMC58XX_SENDER_ID"/>
</subsystem>
</source>
}}

{| class="wikitable" style="text-align:center" border="1"
! Type !! AHRS_XXX_MAG_ID
|-
|'''[[Subsystem/ahrs#Complementary_Quaternion_.28fixed_point.29|int_cmpl_quat]]''' || AHRS_ICQ_MAG_ID
|-
|'''[[Subsystem/ahrs#Complementary_Quaternion.2FRotation_Matrix_.28floating_point.29|float_cmpl]]''' || AHRS_FC_MAG_ID
|-
|'''[[Subsystem/ahrs#DCM_.28floating_point.29|float_dcm]]''' || AHRS_DCM_MAG_ID
|-
|'''[[Subsystem/ahrs#Complementary_Euler_.28fixed_point.29|int_cmpl_euler]]''' || AHRS_ICE_MAG_ID
|-
|'''[[Subsystem/ahrs#Kalman_Filter_Quaternion|float_mlkf]]''' || AHRS_MLKF_MAG_ID
|}

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

Sensors/IMU

2016-06-08T13:50:51Z

IHaveADrone: spelling

<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Sensors</categorytree>
__TOC__
'''See the [[Subsystem/imu|IMU subsystem]] page for the software drivers.'''
== Terminology ==
* '''IMU''': inertial measurement unit: only measures the accelerations and rotation rates (and magnetic field)
* '''AHRS''': attitude and heading reference system: uses IMU data + extra (airspeed/GPS/baro/...) to do sensor fusion and provide pitch and roll
* '''INS''': integrated navigation system: uses IMU + Navigation sensor(s) (e.g. GPS) + even more complex algorithms that besides pitch and roll also interpolates positions and velocities using the attitude corrected acceleration measurements.

== Paparazzi IMUs ==

=== Booz IMU v 1.01 ===

*High quality analog devices sensors
*16bit ADC capable of 200 000 samples per second
*Special attention to clean power with onboard linear supplies
*Efficient high-speed SPI for minimal microcontroller overhead and ultra-low latency (=better controller performance).
*Fits on Booz, Lisa AND Tiny/TWOG autopilots.

While originally designed for use with rotorcrafts, code is now available for use with fixed wing.

[[Image:IMU001.jpg|240px]]

The hardware description is [[BoozIMU|here]].

Available at [https://mini.ppzuav.com/osc/product_info.php?cPath=15&products_id=122&osCsid=bq9cget2u5c7ksa6kd9ssdf03lisuksq PPZUAV].

=== YAI v1.0 ===

Why "yet another imu" while there are already so many out there?

[[Image:yai_assemb.jpg|240px]]

*Designed to be completely compatible with original booz IMU and its code
*Cheaper sensors (lower bias stability)
*Higher resolution (16bits) and frequency (200ksps) and cleaner onboard power supply, better grounding and shielding than compared with e.g. external sparkfun breakout boards
*Fast low latency SPI communication (no uart as the tiny/twog miss uarts)
*The most important part of attitude determination is proper kinematic compensation using for instance GPS, pressure sensors etc etc. When using IMU with external processors there is often less flexibility. Things as timing for instance are as important as the quality of the gyros themselves.

Board, BOM -> [ http://svn.savannah.nongnu.org/viewvc/paparazzi-hardware/trunk/sensors/yai/?root=paparazzi Hardware Repository]

=== Aspirin IMU ===

[[Image:Aspirin_imu_front.jpg|240px]]

[[AspirinIMU|Next generation flat imu.]] This little imu with latest generation of integrated high rate high resolution gyros's moreover has very low noise and stable power supplies and outputs all sensors interrupt pins for optimal performance.

Note: while the main intended use is the very low latency high performance spi+i2c+interrupts connection (e.g. on lisa/M), please note that aspirin v2 can also be used with any tiny/twog for fixedwing aircraft with the same 4-wire interface and identical software as the PPZUAV-IMU. (connect Aspirin-SCK and aspirin-SCL to the I2C-SCL, aspirin-mosi and aspirin-SDA to I2C-SDA, Vcc to 5V (preferably linear), aspirin-gnd and aspirin-miso to GND, and aspirin-CS to 3.3V.)

Detailed information about the [[AspirinIMU|Aspirin IMU]] is available [[AspirinIMU|here.]]

=== KroozSD ===

The KroozSD has it's IMU(MPU6050(Gyro/Accel), HMC5883(Mag), MS5611(Baro) already on the board. The Files for the Krooz IMU are currently only in the "Kooz port of the paparazzi master branch" available. [https://github.com/softsr/paparazzi|softsr's port of the master branch]

== 3rd Party IMU ==

'''Loose Terminology Note:''' Like the sparkfun website, the following text incorrectly equates the term "degree-of-freedom" with sensor measurement. Unless we're talking about articulated arms (which paparazzi to date isn't involved with), a body can only have 6 physical DOFs and that would correspond to translation and rotations in the x,y,z Cartesian directions of 3D space. If the vehicle state vector includes positions and velocities for each degree of freedom, the state vector would have a dimension of 6 x 2 = 12 states. The goal is to reconstruct these vehicle states using sensor measurements, as once the states can be obtained with reasonable certainty, a control algorithm can have a shot at controlling the system. Using various filtering techniques, multiple sensor types can be combined to estimate these states.

IMU's measure rotation rates, acceleration (6DOF) and some also magnetic fields (9DOF). This data is used by an autopilot to estimate the state of the aircraft. They that can be used with a Paparazzi autopilot based UAS. If you happen to have such a device, we really would love to see that you share your IMU paparazzi autopilot integration projects information on this Wiki.

=== PPZUAV IMU 9DOF ===

<gallery>
Image:Ppz9dofimu.jpg|9DOM IMU
Image:Ppz9dofimumed.jpg|Example Wiring to Tiny2.11
Image:Ppz9domschematic.jpg|Schematic
</gallery>

<p>
Another IMU based around the ITG-3200, ADXL345 and HMC5843.<br>
Features: I2C out 5v input. Interrupts .<br>
PCBs available from PPZUAV (assemblies soon). Schematic open, design is Altium Designer, gerbers available.<br>
</p>

A sample airframe illustrating all calibration issues and reading and merging the sensor at 100Hz with minimal control delays is in the repository to get you started:

airframe: PPZUAV/fixedwing/tiny_imu.xml
settings: tuning_basic_ins.xml
telemetry: default_fixedwing_imu.xml

Credit and thanks go out to Christophe for making the code and testing.
</p>
<p>Media
YouTube: http://www.youtube.com/watch?v=OaMTyJ-s-PU
<br style="clear:both">

=== Ryan Mechatronics CHIMU AHRS ===

Very nice product: using the ultra high speed ultra low latency 200Hz SPI-slave mode (even 200Hz innerloop control of fixedwing is possible) or simple 4-wire connection via serial port to any TWOG/TINY/LISA/YAPA.

Don't want to spend time testing AHRS filters? Nor calibrating IMU? This module with molex connector can be bought calibrated and does all the filtering internally.

Use it with highspeed SPI on LPC-based boards: http://www.youtube.com/watch?v=mxx-f3Ur0L8

<modules>
<load name="ins_chimu_spi.xml" />
</modules>

...

<subsystem name="spi_slave_hs"/>

Use CHIMU with simple uart connection on both lisa or tiny/twog

<modules>
<load name="ins_chimu_uart.xml">
<configure name="CHIMU_UART_NR" value="0"/>
</load>
</modules>

=== SparkFun Razor 6DOF IMU ===

'''This product has been discontinued by the manufacturer ! '''

[[Image:RazzorIMU.jpg|thumb|left|Razor IMU (top) with the tiny13 autopilot]]

[[Image:RazzorIMUb.jpg|thumb|left|Razor IMU in the tiny13 autopilot box]]

[http://www.sparkfun.com/commerce/product_info.php?products_id=10010 Official website]

6DOF - Ultra-Thin IMU

Very cheap, currently 62-72 Euro. [http://www.watterott.com/de/Sensoren/IMU Shop in Europe]

Has been integrated in Paparazzi by implementing the DCM algorihm from William Premerlani and Paul Bizard by Hochschule Bremen, Germany.

Remove the high pass filters of the RazorIMU to get better results.

For the Twog and Tiny 2.2 autopilots you have also remove the resistors to GND and the series resistors to the MC of the 5V analog inputs. The code to fly normal plane is currently in the repository. Christoph is working on improvements look here: http://paparazzi.enac.fr/wiki/User:Christoph

[[Media:Wiring_Razor_IMU.pdf|Connections and wiring to the tiny13]]

<br style="clear:both">

=== Drotek 6DOF (MPU6050) ===

[[Image:drotek1.jpg|thumb|left|component side]]
[[Image:drotek2.jpg|thumb|left|solder side]]

IMU Drotek MPU6050 6 Degrees of Freedom Invensens MPU6050

[http://www.drotek.fr/shop/en/42-mpu6050-gyro-accelerometer.html drotek.fr shop]

Tiny, very low cost 12 € , 5V and 3.3V input, I2C interface.

Note that this sensor use the alternative I2C address. Correct is in the driver file. It is a low cost and precise solution for normal aircraft.

Similar chinese breakout boards can be found on ebay starting at 2€.

<br style="clear:both">

=== Drotek 10DOF (MPU6050-HMC5883-MS5611) ===

[[Image:drotek3.jpg|thumb|left|component side]]
[[Image:drotek4.jpg|thumb|left|solder side]]

IMU Drotek MPU6050 - 10 Degrees of Freedom

[http://www.drotek.fr/shop/en/62-imu-10dof-mpu6050-hmc5883-ms5611.html drotek.fr shop]

Tiny, low cost 23€, 5V and 3.3V input (onboard voltage regulator), I2C interface.
It is a low cost and precise solution for normal aircraft with a excellent baro sensor.

By default the axes orientation should be as printed on the pcb, meaning z-axis pointing down if ICs are facing down. The orientation can be switched so that the IMU can be mounted ICs facing up by defining IMU_DROTEK_2_ORIENTATION_IC_UP.#

Maybe setting a different I2C address is required.

{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<subsytem name="imu" type="drotek_10dof_v2">
...
<configure name="DROTEK_2_I2C_DEV" value="i2c0"/>

<define name="IMU_DROTEK_2_ORIENTATION_IC_UP" value="1" />
</subsystem>
</source>
}}

To read the baro use the separate [[Module/Meas_Spec_MS5611_I2C| baro_ms5611 module]].

Similar chinese breakout boards (different pinout/pcb size) can be found on ebay starting at 12€.

<br style="clear:both">

=== SparkFun SEN-10121 ===

[[Image:SEN-10121.jpg|thumb|left|SEN-10121]]

IMU Digital Combo Board - 6 Degrees of Freedom ITG3200/ADXL345

http://www.sparkfun.com/products/10121

Tiny, ADXL345 accelerometer, ITG-3200 gyro, 3.3V input, I2C interface.

This IMU has been tested and flown with Tiny v2.11 and TWOG. It is very similar to the PPZUAV IMU.

Details of [[IMU/SEN-10121|configuration]].

<br style="clear:both">

=== Pololu MinIMU-9 ===

'''This product has been discontinued by the manufacturer !'''

[[Image:MinIMU9.jpg|thumb|left|MinIMU-9]]

IMU Digital Combo Board - 9 Degrees of Freedom L3G4200/LSM303

http://www.pololu.com/catalog/product/1265

Tiny, LSM303 accelerometer and magnetometer, L3G4200 gyro, 3.3V input, I2C interface.

This IMU has been tested and flown with TWOG.

Details of [[IMU/MinIMU-9|configuration]].

<br style="clear:both">

=== Cloudcap Crista IMU ===

[[Image:crista_sensorhead.jpg|thumb|left|Christa IMU]]

[http://www.cloudcaptech.com/crista_sensorhead.shtm Official website / Site not found !]

More infos soon.

<br style="clear:both">

== 3rd Party INS ==

INS measure rates with their sensors and run algorithms to estimate the state on their own. They give this information the the autopilot (e.g. Euler angles) that can then use it for navigation.

===[http://diydrones.com/profiles/blogs/arduimu-v2-flat-now-available|DIYDrones ArduIMU+ V2 (Flat)] ===
[[Image:ArduIMU.jpg|thumb|left|ArduIMU]]

[http://code.google.com/p/ardu-imu/wiki/HomePage?tm=6 Official website]

[[ArduIMU|Paparazzi Wiki Page]]

* 3 axis accelerometer + 3 axis gyroscope
* Low cost
* Has been integrated in Paparazzi by ZHAW, Winterthur, Switzerland.
* A magnetometer has been integrated in the software to compensate drift in yaw.
* GPS data from the Tiny is passed over I2C to the AHRS on the IMU.
* Is sold by [http://www.sparkfun.com/products/9956 Sparkfun] and [http://store.diydrones.com/ProductDetails.asp?ProductCode=KT-ArduIMU-20 DIYDrones Store].
<br style="clear:both">

=== Vector-Nav VN-100 ===
[[Image:VN-100.jpg|thumb|left|Vector-Nav VN-100]]

[http://www.vectornav.com/vn-100-features Official website]

There is a [[Modules|module]] for this AHRS (ins_vn100.xml for fixedwings).

<br style="clear:both">

=== Vectornav VN-200 ===
[[File:Vn-200-rugged.png|thumb|left|VN-200 Rugged version]]
[[File:Vn-200-smd.gif|thumb|left|VN-200 SMD version]]

[http://www.vectornav.com/products/vn200-rugged Official website Rugged version]
[http://www.vectornav.com/products/vn200-smd Official website SMD version]

Vectornav VN-200 is a relatively new (2015) INS solution. In our tests it outperforms GX2/3 and has similar performance as MTI-G (see white paper ''A Comparison of Flight Data from 5 Small Low-cost IMUs'' from Nathan V. Hoffer, Calvin Coopmans, Austin M. Jensen, AggieAir at the Utah Water Research Laboratory) at roughly half price.

The code is available, use it as an INS subsystem (ins_vectornav). Comes with recommended configuration target (setup_vectornav) so it can be easily configured. Another option is to use the Windows configuration tool from Vectornav.

<br style="clear:both">

=== MicroStrain 3DM-GX2/3 ===
[[Image:3DM-GX2.jpg|thumb|left|MicroStrain 3DM-GX2]]

[http://www.microstrain.com/3dm-gx2.aspx Official website GX2]
[http://www.microstrain.com/inertial/3DM-GX3-25-OEM Official website GX3]

GX3 AHRS (ahrs_gx3.xml) available for both fixedwing and rotorcraft. Can be used for GX2 too, since the commands and packets are identical (GX2 has slower update rate).

<br style="clear:both">

=== Xsens MTi and MTi-G (with GPS) ===
[[Image:MTi.jpeg|thumb|left|Xsens MTi]]

[[Image:MTi-G.jpeg|thumb|left|Xsens MTi-G (with GPS)]]

[http://www.xsens.com/en/general/mti Official website MTi]

[http://www.xsens.com/en/general/mti-g Official website MTi-G]

In sensor fusion, calibration and timing are crucial. If you want latency compensated ADXRS gyro integrated attitude done by an efficient and optimized Blackfin DSP you need an XSens. For rotorcraft the 100Hz is a bit slow, but for fixedwing it's perfect. Directly compatible with [[Yapa]] and [[Lisa]] and all needed code in paparazzi.

<br style="clear:both">

=== MemSense MAG3 ===

MAG3 - 6 DOF Analog IMU with Triaxial Magnetometer

[http://www.memsense.com/index.php/Product-Pages/mag3-worlds-smallest-analog-inertial-measurement-unit.html Official website mag3]

== The Very Short Essential Introduction To Inertial Attitude Estimation ==

The only physical entity related to attitude (pitch and roll) is the earth gravity vector (unless you use a multi-antenna phase-measuring GPS... $$$$). Unfortunately, the sensors that measure gravity (=accelerometers) also measure so-called kinematic accelerations or in other words: changes in speed: like centrifugal forces, Coriolis forces, linear accelerations etc... The sum of all these litteraly is "what you feel" and is called [http://en.wikipedia.org/wiki/Specific_force "specific force"].

so

accelerometer_value (specific force) = earth_gravity + change in velocity (linear accelerations) + velocity times turn rate (centrifugal etc)

or

A = B + C + D

You measure A and want to know B. What all "gyroscopes and accelerometer only" AHRS projects are doing in some way or another is to neglect the last 2 (C and D). In many situations this is not bad: for instance: when testing the AHRS attached to your computer: it can not accelerate for a very long time (at most a few meters: so if you accelerate to the left, then you need to accelerate to the right directly after so the average is zero) and can not rotate to much either (or your cable gets strangled). This is why all AHRS videos on Youtube look perfect. And on the desk they are perfect: you neglected 2 terms in the equation that in that situation are perfectly neglect-able. Also with a quadrotor that hovers and keeps its nose in the same direction all the time, these neglected terms are small.

Now what about the gyroscopes you might ask. I deliberately keep them only second as gyroscopes (turn rate or rotation speed sensors) do NOT give you attitude but ONLY HELP TO SOLVE SHORT TERM errors in the previous part. If gyroscopes would measure turn-rate perfectly, then they would help more but all MEMS/PIEZZO sensors are more or less sensitive to 1) temperature, 2) turnrate, 3) vibrations, 4) accelerations, 5) radiation, 6) power supply quality 7) non-linearity 8) ADC-quality 9) dynamic range and saturation problems, ... so if you integrate gyroscopes, sooner or later errors build up (drift). I put this list here so you know what to pay attention for: if using gyroscopes: always try to keep the temperature as constant as possible or let the temperature settle, reduce vibrations (dampers), use better ADC (e.g. 10bit ADC with +/- 1200 deg/sec gyros have a resolution of 2.4 degrees/s per ADC tick, so your phi/theta might drift 1.2deg/sec without noticing) and power supply filtering and shielding etc to start with. All of these define for how long (seconds!/minutes?) gyroscope integration is useful.

If you convert the accelerometer directly to attitude and plot it, it will vibrate a lot and will show errors when you accelerate the AHRS on your desk. During a coordinated turn of a fixedwing plane, the force you feel is perpendicular to the plane (not pointing to earth). The accelerometer only clearly is insufficient to know your attitude. One solution is to use gyroscopes that are so good that you can predict for many minutes (then the average acceleration during several turns would still point to earth). But if your gyros can only help for shorter terms (like all MEMS sensors of less than 500euro/each) then extra information is required. E.g: if you add GPS data or airspeed data however, from the flightpath you can quite accurately reconstruct the missing C and D terms. Together with the accelerometer you can know "where the earth is" even when you keep accelerating and turning. Here questions like latency, update rate, noisy derivatives (linear acceleration) are of importance.

Finally there is the heading... GPS ground-track is not the same as nose direction. Gyroscopes measure how much the nose has been turning, so using GPS to correct it induces errors that increase with crosswind. Magnetometers can help here, and become necessary whenever you do not move enough anymore (hovering). This situation can also occur in plane flying in very strong winds.

See the [[Subsystem/ahrs|AHRS subsystem]] page for an overview of some algorithm implementations.

[[Category:Sensors]]

Modules

2016-06-06T18:32:15Z

IHaveADrone: spelling

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

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

=== Available modules ===

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

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

=== Make your own ===

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

=== In the airframe file ===

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

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

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

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

=== In the module file ===

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

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

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

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

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

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

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

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

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

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

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

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

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

=== In the airborne code ===

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

=== Starting / stopping a module ===

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

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

=== Telemetry ===

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

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

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

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

Installation/Linux

2016-05-10T16:48:43Z

IHaveADrone: spelling

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

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

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

== Introduction ==

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

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

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

===For the impatient===

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

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

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

== Installation video Tutorials ==

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

== Installation of dependencies ==

=== Ubuntu ===
'''Binary packages for Ubuntu are available for the ''i386'', ''amd64'' and ''armhf'' architectures.'''

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

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

=== Debian ===
'''Binary packages for Debian are available for the ''i386'' and ''amd64'' architectures. ''armhf'' packages seem to be currently not supported by the OpenSUSE build service.'''

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

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

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

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

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

== ARM embedded toolchain ==

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

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

'''This is the recommended method'''

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

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

You can list the available versions with <tt>apt-cache policy gcc-arm-none-eabi</tt>

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

'''This is the recommended toolchain'''

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

!!! If you are using Ubuntu 14.04 and later, please be careful because there are packages with same name but produced by Debian and inherited by Ubuntu.
Check available versions after adding the PPA with

apt-cache policy gcc-arm-none-eabi

To install a specific version (the one from terry.guo PPA) specify the version explicitly, e.g.
sudo add-apt-repository ppa:terry.guo/gcc-arm-embedded
sudo apt-get update
sudo apt-get install gcc-arm-none-eabi=4.9.3.2015q3-1trusty1
Meanwhile we are working with Debian to consolidate and unify this toolchain.

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

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

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

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

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

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

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

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

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

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

== Optional Packages ==

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

sudo apt-get install lpc21isp openocd

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

== Installing and running Paparazzi ==

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

== Udev rules ==

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

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

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

== Troubleshooting ==

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

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

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

Logout and login again.

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

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

=== arm-linux-gnueabi-gcc cross-compiler not found ===

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

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

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

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

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

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

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

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

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

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

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

sudo apt-get remove brltty

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

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

make clean && make

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

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

Modems/xbee

2016-05-10T16:46:00Z

IHaveADrone: spelling

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

== Introduction ==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

=== Flashing the airborne module ===
# Connect your XBee, start X-CTU, click READ
# Select the function set '''ZIGBEE END DEVICE AT''' (or ZIGBEE ROUTER AT).
# Set the PAN ID to any number, must be the same as the pan id of the coordinator (Ground Station).
# Set the Node Identifier (NI) to your aircraft name or any other appropriate name.
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.
# Then write the firmware to the module.

=== Flashing the ground station module ===
# Connect your XBee, start X-CTU, click READ
# Select the function set '''ZIGBEE COORDINATOR AT'''.
# Set the PAN ID to any number, must be the same as the pan id of the end device (aircraft).
# Set the Node Identifier (NI) to PPRZ_GROUND or any other appropriate name.
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.
# Then write the firmware to the module.

=== Pairing your Modems ===

For maximum performance you can pair the ground modem to the airborne modem. Set the "DH - Destination Address High" and "DL - Destination Address Low" to the unique serial number "SH - Serial Number High" and "SL - Serial Number Low" of the other modem. Do so both on the ground modem and on the airborne modem. Failing to properly pair your modems will likely result in poor throughput and data loss between your airframe and your ground control station. If this is the case you may see errors on the Paparazzi Center console like <tt>Failure("Pprz.values_of_payload, wrong argument: 00 08 ")</tt> or <tt>Failure("Pprz.values_of_payload, too many bytes in message PONG: 00 03 02 2a 00 00 00 00 00 00 00 00 00 00 00 00 ")</tt>. Pairing does help and the error messages will disappear.

=== Reviving a non-responding Xbee Pro ===

To bring an apparently dead XBee Pro Series 2 back to life, do the following:

#Connect the USB device that holds the XBee to your laptop/desktop (without the XBee connected).
#Open X-CTU.
#In the tab used to program the device, select the proper modem (normally you would do a READ to get the values).
#Choose the option you want to program (i.e., "END DEVICE" or "COORDINATOR") as if you were programming it.
#With the XBee not in the device, click "WRITE". It will hang, timeout, and bring up a dialog box.
#Before you click OK to the dialog box, plug in the XBee module (carefully).
#Click OK to clear the message and it should start programming automatically.

=== Other tutorials ===

[http://pixhawk.ethz.ch/tutorials/how_to_configure_xbee PixHawk: HowTo configure XBee]

[http://wiki.openpilot.org/display/Doc/Configure+Xbee+via+Linux openpilot: XBee RF modems]

== XBee Pro ZNet 2.5 (AT command set) ==
These are legacy modems and not recommended/sold by Digi anymore.
It is recommended to upgrade these to XBee Pro ZB with the [ftp://ftp1.digi.com/support/images/ZNet%202.5%20to%20ZB%20Conversion%20Kit.zip ZNet 2.5 to ZB Conversion Kit] from Digi.
<br/>
If you want to use ZNet 2.5 feature set nevertheless, here is how to configure it:

=== Flashing the airborne module ===
# Connect your XBee, start X-CTU, click READ
# Select the function set '''ZNET 2.5 ROUTER/END DEVICE AT'''.
# Set the PAN ID to any number, must be the same as the pan id of the coordinator (Ground Station).
# Set the Node Identifier (NI) to your aircraft name or any other appropriate name.
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.
# Then write the firmware to the module.

=== Flashing the ground station module ===
# Connect your XBee, start X-CTU, click READ
# Select the function set '''ZNET 2.5 COORDINATOR DEVICE AT'''.
# Set the Destination Address Low (DL) to FFFF.
# Set the PAN ID to any number, must be the same as the pan id of the end device (aircraft).
# Set the Node Identifier (NI) to PPRZ_GROUND or any other appropriate name.
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.
# Then write the firmware to the module.

=== Setup ===

For the ZigBee ZNet 2.5 and ZB modules to work one of the modules has to be flashed with the coordinator firmware. All the others in the same PAN can either run as routers or end-devices.
* Flash one module (ground station) with the coordinator AT firmware
* Flash aircraft module with router or end-device AT firmware
To allow modules to join any PAN set the PAN ID to zero (default setting). Then the coordinator will generate a random PAN ID and routers and end-devices will join the first PAN they find.

If you operate in an environment with multiple zigbee PANs it is recommended to set the PAN ID explicitly:
* Set PAN ID to some unique (but same) ID on both modules
* Set a Node Identifier for each module (e.g. ground, aircraft)
<br/>

== XBee Pro DigiMesh / 802.15.4 ("Series 1") ==

=== Flashing the airborne module ===
# Connect your XBee, start X-CTU, click READ
# Leave the function set on '''XBEE PRO 802.15.4'''.
# Set the PAN ID to any number, must be the same as the pan id of the coordinator (Ground Station).
# Set the Node Identifier (NI) to your aircraft name or any other appropriate name.
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.
# Then write the firmware to the module.

=== Flashing the ground station module ===
# Connect your XBee, start X-CTU, click READ
# Leave the function set on '''XBEE PRO 802.15.4'''.
# '''Set Coordinator Enable to "1 - COORDINATOR".'''
# Set the PAN ID to any number, must be the same as the pan id of the end device (aircraft).
# Set the Node Identifier (NI) to PPRZ_GROUND or any other appropriate name.
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.
# Then write the firmware to the module.

(Tested on XBP24 Firmwareversion 10E6)

== XBee Pro 868 MHZ ==

=== Getting Them Working ===
Even with the xbee868.xml telemetry file, XBee868s will not last over 6 minutes. There is a special 868 build flag (in slayer1.xml), and matching option for the datalink but I could not get this to work. Eventually, I got them to work for about 20 minutes, which happily is the flight endurance of a heavily overloaded GWS Formosa.

I did this using a command window, but you could use X-CTU if you are a wuss or have Windows handy.

#Attach Xbee and start serial comm program (I use <code>screen /dev/ttyUSB0 <baud rate, just a number, no angled brackets></code>, you can also use pico- or microcom)
#Type AT and enter. You should get an OK back.
#ATMT and enter. You should get a number—this represents the number of extra times each packet will be broadcast. We now need to change this to zero.
#ATMT0 and enter => OK
#ATRR and enter. This number is the number of retries that will be sent if an ACK is not received. Disabling this will also have the side effect of disabling ACKs, giving us more packets to play with.
#ATRR0 and enter => OK
#Type ATWR to store the new stuff in the firmware. You should get an OK.
#Set the datalink to transparent mode both in your airframe file and on the datalink.

You may also want to drop the power level to 1mW for testing, or it won't actually work - they are just too damn powerful to talk to each other at a range of a couple of feet. I also used 1mW for flying - never lost the link, even after a mile. Didn't get round to range testing them though.

You probably want to do this to both XBees (at least I did). I personally had the baud rate at 57600 for legacy reasons, but it should work just as well at any other baud rate. '''Thanks to CheBuzz for this info''', and for helping me work all this out at 11pm the night before EMAV09.

== XBee 868LF ==

These relatively new modems use the whole spectrum allowed in your country to avoid Duty Cycle restrictions.

== XBee Pro XSC (900MHZ) ==

== Configuring XBee API mode (xbee protocol) ==

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

Installation

2016-04-05T17:45:10Z

IHaveADrone: typo

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

== Introduction ==

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

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

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

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

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

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

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

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

== OS Specific Instructions ==

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

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

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

=== Virtual Machines ===

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

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

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

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

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

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

make

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

./paparazzi

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

=== Environment Variables ===

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

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

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

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

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

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

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

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

=== Quick'n dirty description ===

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

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

make

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

make clean
make

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

make test

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

== Using the Live CD ==

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

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

Flight Plans

2016-02-09T21:17:57Z

IHaveADrone: spelling

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

== DTD and Structure ==

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

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

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

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

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

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

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

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

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

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

== Waypoints ==

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

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

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

== Sectors ==

=== Static sectors (default) ===

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

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

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

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

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

=== Dynamic sectors ===

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

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

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

== Variables ==

'''Available since v5.9'''

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

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

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

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

== Includes ==

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

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

== Blocks ==

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

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

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

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

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

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

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

==== Expressions ====

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

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

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

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

=== Exceptions ===

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

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

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

=== Deroute ===

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

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

=== Return ===

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

=== Loops ===

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

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

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

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

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

=== Navigation modes ===

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

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

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

The different navigation modes are detailed in the next sections.

=== Attitude ===

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

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

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

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

=== Heading ===

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

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

=== Go ===

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

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

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

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

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

=== Path ===

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

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

=== Circle ===

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

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

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

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

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

=== Follow ===

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

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

=== Stay ===

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

=== XYZ ===

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

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

=== Set ===

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

=== Call ===

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

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

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

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

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

=== Pre Call ===

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

=== Post Call ===

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

== Procedures ==

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

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

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

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

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

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

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

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

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

== Internal Variables in Flight Plans ==

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

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

== Advanced Examples ==

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

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

=== Gains on the fly ===

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

=== Dynacmically adjustable maximum speed ===

=== Immobilize Actuators ===

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

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

== Tips and Tricks ==

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

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

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

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

Modules

2016-02-04T15:07:12Z

IHaveADrone: spelling

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

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

=== Available modules ===

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

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

=== Make your own ===

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

=== In the airframe file ===

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

=== In the module file ===

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

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

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

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

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

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

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

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

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

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

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

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

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

=== In the airborne code ===

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

=== Starting / stopping a module ===

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

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

=== Telemetry ===

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

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

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

Airframe Configuration

2016-01-15T15:16:25Z

IHaveADrone: minor spelling

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

== About ==

The airframe file is the most important configuration file and contains all the hardware and software settings for your airframe. It describes what hardware you have and which firmware, sensors, algorithms, etc. you want to use and also holds your configuration parameters. All gains, trims, and behavior settings are defined with standard XML elements.

The XML airframe configuration file is located in <tt>conf/airframes/<yourairframe>.xml</tt> and always begins with a <!DOCTYPE airframe SYSTEM "airframe.dtd"> line and should look like this
{{Box Code|conf/airframes/<yourairframe>.xml|<source lang="xml">
<!DOCTYPE airframe SYSTEM "airframe.dtd">
<airframe name="yourairframe">

</airframe>
</source>}}

<b>Also see the wiki pages for [[Fixedwing_Configuration|fixedwing specific configuration]] and [[Rotorcraft_Configuration|rotorcraft specific configuration]].</b>

== Creating a new Aircraft ==

While the airframe file is where you configure most aspects of your aircraft, a fully specified aircraft needs several XML configuration files:
* Airframe (what this page is about)
* [[Flight_Plans|Flight Plan]]
* [[Settings]]
* [[Radio_Control|Radio]] (if you use a PPM based R/C system)
* [[Telemetry]]
* [[settings_modules]]
Each aircraft is assigned a name, unique ID and the associated configuration files in [[Conf.xml|<tt>conf/conf.xml</tt>]]. To create a new Aircraft, click new in the menu A/C in the [[Paparazzi_Center|Paparazzi Center]] and select your new airframe file, etc. (or specify it by hand in [[Conf.xml|<tt>conf/conf.xml</tt>]]).

== Firmware and Hardware definitions ==
First you should specify which firmware you want to use, that is if you have a <tt>[[Fixedwing_Configuration|fixedwing]]</tt> aircraft or a <tt>[[Rotorcraft_Configuration|rotorcraft]]</tt>:
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
</firmware>
</source>
}}

=== Select your Board ===

To specify autopilot hardware you are using and it's low-level settings you have to add a ''target''-tag.
Each ''target'' has two attributes, which are ''name'' and a corresponding ''board'' attribute.
The ''name'' attribute is either "ap" (autopilot) or "sim/jsbsim/nps" (simulation).

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

==== Simulation targets ====

target name="sim","jsbsim","nps"<br/>
board="pc"<br/>

More Information at [[Simulation]].

==== Board targets ====

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

All targets can be found in /conf/boards.

==== Direct Makefile ====

Optionally you can also add a raw [http://en.wikipedia.org/wiki/Makefile Makefile] section. This is only needed in very advanced setups. For example when testing newly developed hardware.

=== LEDs ===

You can configure the LEDs on the autopilot to be used for different status indicators:
; ''SYS_TIME_LED'': blinks with 1Hz
; ''AHRS_ALIGNER_LED'': blinks until the AHRS is aligned (gyro bias initialized) and then stays on
; ''GPS_LED'': blinking if trying to get a fix, on if 3D fix
; ''RADIO_CONTROL_LED'': on if RC signal is ok
; ''BARO_LED'' : only on booz and navgo boards: blinks until baro offset is initialized and then stays on

Depending on your board some of the LEDs on it are already assigned to some indicators by default, check the appropriate autopilot board makefile for the defaults.

To reconfigure the default assignment, assign the indicator to an other value. Use ''none'' if indicator should not be assigned to any LED.

{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
<configure name="SYS_TIME_LED" value="1"/>
<configure name="RADIO_CONTROL_LED" value="2"/>
<configure name="GPS_LED" value="none"/>
</firmware>
</source>
}}

Beware that you can only assign '''one''' indicator to a LED number. So if the LED you want to use is already in use because another indicator is set to that number by default you have to disable that other indicator by setting it to ''none'' or reconfigure it to an other LED.

== Subsystems ==

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

=== IMU ===

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

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

=== AHRS ===

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

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

=== Radio Control ===

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

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

=== Telemetry (Modem) ===

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

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

Just specify the appropriate [[Subsystem/telemetry|telemetry subsystem]] in your firmware section. You can currently choose between the types ''transparent'', ''transparent_usb'' and ''xbee_api''.

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

=== GPS ===

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

Just specify the appropriate [[Subsystem/gps|gps subsystem]] in your firmware section. You can currently choose between the types '''ublox''' and '''ublox_utm''' for the older series 4 modules which still provide a UTM message.
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
<subsystem name="gps" type="ublox"/>
</firmware>
</source>
}}

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

If you need to set different baud rates or UART see the [[Subsystem/gps]] page for the options.

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

== XML Parameters ==

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

=== Commands ===

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

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

=== Servos ===

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

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

The attribute <b><tt>driver</tt></b> for <b><tt>servos</tt></b> node tells which actuators' driver is associated to the listed servos. After the version '''v4.9_devel-164-gdb0d004''', multiple servos sections can be defined and used together, if the correct [[Subsystem/actuators| actuators subsystems]] are loaded. Some boards are automatically loading a default driver, the one used when no <b><tt>driver</tt></b> attribute is specified.

Note the following important tips:
* Reverse the servo direction by exchanging min/max
* Trim should always be adjusted mechanically if possible to avoid asymmetrical travel
* Any reduction of the total travel range should be done mechanically to maintain precision
* Many servos will respond well to values slightly outside the normal 1000-2000µs range but experiment carefully as the servo may not operate reliably outside this range and may even suffer permanent damage.
* Board connector numbering starts with <b>zero (0)</b> not with one
* Servos are also known under the synonym <b>actuators</b>
* (after version '''v4.9_devel-164-gdb0d004''') For I2C based motor speed control using the [[Rotorcraft_Configuration#Motor_Mixing|motor mixing]]:
** min: command to stop the motor
** neutral: motor idle command
** max: max thrust command

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

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

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

After '''v4.9_devel-164-gdb0d004''', the <b><tt>command_laws</tt></b> section is mandatory for both fixedwing and rotorcraft firmwares, only for fixedwing otherwise.

=== Battery ===

This section gives characteristics for monitoring the main power battery.

<b><tt>MILLIAMP_AT_FULL_THROTTLE</tt></b> represents the actual current (in mA) when full THROTTLE is applied. Note that when flying the current typically is significantly lower than in static tests at home on your workbench. <b><tt>MILLIAMP_AT_FULL_THROTTLE</tt></b> is used to compute the <tt>energy</tt> value of the <tt>BAT</tt> message when no [[Current_sensor|Current sensor]] is mounted in the airframe. This value can also be used in flight plans. For example, if at full throttle your motor consumes 10 Amps, use a value of 10000. You can "tweak" this number after a few flights to match the capacity of your battery. If upon landing your bat.energy messages says that you used 2500 mAh while the energy recharged into the battery is only 2000 mAh, you could reduce the <b><tt>MILLIAMP_AT_FULL_THROTTLE</tt></b> value by 20% to match your in-flight current consumption. This tweaking is most precise if you fly full throttle only (respectively no throttle to glide down again).

The <b><tt>CURRENT_ESTIMATION_NONLINEARITY</tt></b> can be added to tweak the energy estimation for non full throttle cruise. As the current consumption is nonlinear, at 50% throttle it is likely to be substantially less than 50%. A superellipse is used to approximate this nonlinearity. The default setting is 1.2 and is used if the <b><tt>CURRENT_ESTIMATION_NONLINEARITY</tt></b> is not defined in your airframe file. A value 1 corresponds to linear behaviour, 1.5 corresponds to strong nonlinearity. The tweaking is done same as described above for <b><tt>MILLIAMP_AT_FULL_THROTTLE</tt></b>, but only partial throttle (cruise throttle) should be applied in flight.

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

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

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

{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing">
...
<define name="ADC_CHANNEL_VSUPPLY" value="ADC_4" />
</firmware>
...
<section name="BAT">
<define name="MILLIAMP_AT_FULL_THROTTLE" value="12000" unit="mA" />
<define name="CATASTROPHIC_BAT_LEVEL" value="6.0" unit="V"/>
<define name="CRITIC_BAT_LEVEL" value="6.5" unit="V"/>
<define name="LOW_BAT_LEVEL" value="7.0" unit="V"/>
<define name="MAX_BAT_LEVEL" value="8.4" unit="V"/>
</section>
</source>
}}

The conversion of ADC measurements to Voltage is already defined for the different autopilot boards, if you need to override these defaults you can use the <b><tt>VoltageOfAdc(adc)</tt></b> define and also specify offsets or anything else you might need, e.g.:

{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<section name="BAT">
...
<define name="VOLTAGE_ADC_SCALE" value="0.0177531"/>
<define name="VOLTAGE_OFFSET" value="0.5" unit="V"/>
<define name="VoltageOfAdc(adc)" value="(VOLTAGE_ADC_SCALE * adc + VOLTAGE_OFFSET)"/>
</section>
</source>
}}

Calculating '''VOLTAGE_ADC_SCALE''':

<math>VOLTAGE\_ADC\_SCALE=\frac{Vref}{ADCresolution-1}\div\frac{R2}{R1+R2}</math>

*Vref - Voltage reference for the ADC (will be 3.3V in most cases, can be found in mcu/adc datasheet)
*ADCresolution - ADC bit depth (e.g. 2^12=4096 for a 12 bit ADC)
*R1 - Resistor between battery and ADC input pin of MCU
*R2 - Resistor between ADC input pin of the MCU and GND

It is also a good idea to measure the actual voltage of the battery with a precision voltage meter, compare it with the calculated value from the autopilot (e.g. via [[Paparazzi_Center#Messages]]) and edit the vales for ADC scaling. Since the resistors have a tolerance, this can fine tune the measurement.

=== Modules ===

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

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

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

=== GCS ===

[[Image:ac_icon_multi_uav.png|thumb|Various A/C icons demonstrated on a multi UAV simulation session]]

[[Image:Icons_Theme_Default.png|thumb|Default Theme]]

[[Image:Icons_Theme_Flat.png|thumb|Flat Theme]]

Use this <b>optional</b> section to help customize parts of the GCS for a specific airframe:
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<section name="GCS">
...
<define name="ICONS_THEME" value="flat_theme"/>
<define name="ALT_SHIFT_PLUS_PLUS" value="30"/>
<define name="ALT_SHIFT_PLUS" value="5"/>
<define name="ALT_SHIFT_MINUS" value="-5"/>
<define name="SPEECH_NAME" value="Quad"/>
<define name="AC_ICON" value="flyingwing"/>
</section>
</source>
}}

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

==== Custom Icons Theme Support ====

A custom icons theme is supported through the use of the '''ICONS_THEME''' attribute. Set the '''ICONS_THEME''' attribute ''value'' to the path of your custom icons theme directory and the given aircraft will now display your custom icons. Note that the path is relative to the default GCS icons path root: ''$PAPARAZZI_HOME/data/pictures/gcs_icons''

{{Box Code|code snippet|
<source lang="xml">
<section name="GCS">
<define name="ICONS_THEME" value="myawesome_icons"/>
</section>
</source>
}}

The directory that contains your custom icons, in this example named ''myawesome_icons'', is located at ''$PAPARAZZI_HOME/data/pictures/gcs_icons''.

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

Modems

2016-01-07T16:12:13Z

IHaveADrone: typos etc

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

==General comparison==
'''This is ONLY a comparison between modules on this page'''

All modules listed here work without issue and are generally available.
{| border="1" cellspacing="0" style="text-align:center" cellpadding="2%"
| align="center" style="background:#f0f0f0;"|'''Feature'''
| align="center" style="background:#f0f0f0;"|'''[[Modems#Digi_XBee_Pro_DigiMesh_.2F_802.15.4_.28.22Series_1.22.29|XBee Series 1]]'''
| align="center" style="background:#f0f0f0;"|'''[[Modems#Digi_XBee_Pro_DigiMesh_.2F_802.15.4_.28.22Series_1.22.29|XBee Pro Series 1]]'''
| align="center" style="background:#f0f0f0;"|'''[[Modems#Digi_XBee_Pro_ZB_.2F_ZNet_2.5_.28.22Series_2.22.29|XBee Series 2]]'''
| align="center" style="background:#f0f0f0;"|'''[[Modems#Digi_XBee_Pro_ZB_.2F_ZNet_2.5_.28.22Series_2.22.29|XBee Pro Series 2]]'''
| align="center" style="background:#f0f0f0;"|'''[[Modems#Digi_XBee_868LP|XBee 868LP]]'''
| align="center" style="background:#f0f0f0;"|'''[[Modems#Digi_XBee_Pro_900HP|XBee Pro 900HP]]'''
| align="center" style="background:#f0f0f0;"|'''[[Modems#Digi_XBee_Pro_XSC_900MHz|XBee Pro XSC 900]]'''
| align="center" style="background:#f0f0f0;"|'''[[Modems#Digi_9XTend|Digi 9XTend]]'''
| align="center" style="background:#f0f0f0;"|'''[[Modems#SiLabs_Si1000_SoC_based_modems|SiLabs Si1000]]'''
| align="center" style="background:#f0f0f0;"|'''[[Modems#AC4790-200|Aerocom AC4790-200]]'''
| align="center" style="background:#f0f0f0;"|'''[[Modems#AC4790-1000|Aerocom AC4790-1000]]'''
| align="center" style="background:#f0f0f0;"|'''[[Modems#Laird_RM024|Laird RM024 50mW]]'''
| align="center" style="background:#f0f0f0;"|'''[[Modems#Laird_RM024|Laird RM024 125mW]]'''
| align="center" style="background:#f0f0f0;"|'''[[Modems#RN-41_Bluetooth_module.28Sparkfun.27s_WRL-08497.29|RN-41 Bluetooth]]'''
|-
| style="background:#f0f0f0;"|'''frequency'''||2,4GHz||2,4GHz||2,4GHz||2,4GHz||868MHz||900MHz||900MHz||900MHz, 2.4GHz||240-960MHz||900MHz||900MHz||2,4GHz||2,4GHz||2,4GHz
|-
| style="background:#f0f0f0;"|'''output power'''||1mW||63mW (US) 10 mW (Int'l)||2mW||63mW||5mW||250mW||250mW||1mW-1W||max 100mW||5-200mW||5-1000mW||2,5-50mW||2,5-125mW||32mW
|-
| style="background:#f0f0f0;"|'''RF speed'''||250kbps||250kbps||250kbps||250kbps||10kbps, 80kbps||10 or 200kbps||10, 20kbps||9.6, 115.2kbps|| ||76.8kbps||76.8kbps||280, 500kbps||280, 500kbps||300kbps
|-
| style="background:#f0f0f0;"|'''antenna'''||chip, wire, rpsma, u.fl||chip, wire, rpsma, u.fl||chip, wire, rpsma, u.fl||chip, wire, rpsma, u.fl||external required||wire, rpsma, u.fl||wire, rpsma, u.fl||rpsma, MMCX||external required||MMCX, internal Antenna||MMCX||u.fl, chip, both||u.fl, chip, both||pcb trace
|-
| style="background:#f0f0f0;"|'''pinout'''||XBee||XBee||XBee||XBee||SMD||XBee||XBee||20 pin 2,54mm/USB||SMD (42 pin LGA)||20 pin mini connector||20 pin mini connector||XBee/SMD||XBee/SMD||SMD
|-
| style="background:#f0f0f0;"|'''price'''||16€||26€||14€||28€||18€||32€||32€||150€||4€||52€||64€||30€||30€||20€
|-
| style="background:#f0f0f0;"|'''for Country'''||Worldwide||Worldwide||Worldwide||Worldwide||Europe||North America, Australia||North America, Australia||Worldwide||Worldwide||North America, Australia||North America, Australia||Europe||North America||Worldwide
|}

== Frequencies ==

Analog and digital signals (video and data/modem) can not be transmitted over the same frequency band since the analog signal will "block" the digital one. (Attention ! the common 2.4 or 5.8GHz frequencies have multiple channels, if the analog and digital transmitter/receiver modules are set up to different channels/frequencies, they should work (even on 2.4GHz)).

You may want to inform yourself about your countries laws ! Different countries allow different frequencies at different power. <br/>
Sending on a wrong frequency or with too much power may end in a serious lawsuit !

Digi: [http://www.digi.com/technology/rfmodems/agencyapprovals Government Agency Certifications]

== HAM / CEPT Licence ==

If possible, consider making a HAM radio (amateur radio) licence. (e.g. CEPT, depends on your locality)

You will learn about the radio technology, operational technology and legislation.<br/>
With a HAM radio licence, you can also use other frequencies or transmit on a higher power. (e.g. In some countries, the 5.8GHz video transmission is for non licenced people restricted to 10mW!)<br/>

'''Licence Pros'''
* You will be informed well about the (local and international) legislations.
* You can transmit on a higher power (depends on frequency).
* You will learn a lot about the techniques and be more than a standard "consumer" of radio electronic products.
* It will be easier to find faults in your radio systems.
* You can build (if you want) high gain/focused antennas which can give you a better signal, wider range and won't disturb anyone else.
* Well educated people respecting the legislation just looks much better in looks to UAV's :)

'''Licence Cons'''
* You will need to learn for the test (can be compared with a diverce licence).
* The certificate and books will cost about 70€ (total, can vary !).
* Maybe some costs (per year) for your call sign.

=== CEPT Licence in Austria ===

A short description about getting the CEPT 1 (not the CEPT Novice !) licence in Austria.

You will need the appropriate books which cost 50€ (70€ if you want them with the ask catalog and answers which can be helpful) and rough 18€ for the exam and certificate. The ÖVSV offers also some courses, but you can also learn everything with the books.

The are (regularly?) HAM licence courses at the https://metalab.at/ in Vienna.

To be continued...

=== Links ===

[http://www.oevsv.at/ Austrian ÖVSV]<br/>
[http://www.darc.de/ German DARC]

== Digi XBee modules ==

Digi (formerly Maxstream) offers an increasing variety of Zigbee protocol modems well suited for Paparazzi in 2.4 GHz, 900MHz and 868Mhz frequencies. The "Pro" series are long range, up to 40km! Standard series are slightly smaller/lighter/lower power consumption and very short range. All versions are all pin compatible and weigh around 2 grams with wire antennas. All Digi modems can be operated in transparent mode (as a serial line replacement) or in "API mode" with hardware addressing, managed networking, and RSSI (signal strength) data with the Paparazzi "Xbee" option.

Four antenna options are offered: RP-SMA, U-FL, wire antenna, chip antenna

* XBee (PRO) ZB (the current series)
* XBee (PRO) ZNet 2.5 (formerly Series 2) (only legacy -> use XBee-PRO ZB)
The XBee & XBee-PRO ZB share hardware (ember stack) with XBee & XBee-PRO ZNet 2.5. As a result, modules can be "converted" from one platform to another by loading different firmware onto a given module.

These two also share the same hardware and can be converted from one to another by flashing a different firmware:
* XBee-PRO 802.15.4 (formerly Series 1)
* XBee-PRO DigiMesh 2.4

'''Note: Modules based on Freescale chipset (formerly Series 1) are not compatible with Ember chipset based modules (Series 2).'''

If only point to point or point to multipoint communication is required 802.15.4 will do the job. These are designed for high data rates and low latency.<br/>
Modules with Zigbee firmware are needed for mesh functionality(communication between the UAV's)

See the [[XBee_configuration|XBee Configuration]] page. This [http://pixhawk.ethz.ch/tutorials/how_to_configure_xbee tutorial] is also good to configure and get started with XBee Pro.

=== Module Comparison ===
{|border="1"
|-valign="top"
||'''Module'''||'''Point-to-Multipoint'''||'''ZigBee/Mesh'''||'''Chipset'''|||'''Software stack'''||'''Frequency'''||'''TX Power normal/PRO'''||'''Notes'''
|-
|'''XBee ZB'''
|
|yes
|Ember
|EmberZNet PRO 3.1 (ZigBee 2007)
|2.4 GHz
|2mW/50mW
|coordinator needed
|-
|'''XBee ZNet 2.5'''
|
|yes
|Ember
|EmberZNet 2.5 ZigBee
|2.4 GHz
|2mW/50mW
|(only legacy -> use XBee-PRO ZB) coordinator needed
|-
|'''XBee DigiMesh 2.4'''
|
|yes
|Freescale
|
|2.4 GHz
|
|all nodes equal (no special coordinators/routers/end-devices)
|-
|'''XBee 802.15.4'''
|yes
|
|Freescale
|
|2.4 GHz
|
|
|-
|'''XBee-PRO 868'''
|yes
|
|?
|
|868 MHz
|500mW
|Only High Power Frequency allowed in the UK. 2.4GHz limited to 10mW
|}

==== Pinout ====

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

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

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

Note : DTR and RTS need to be wired for upgrading firmware

=== GCS Adaptation ===

There are several vendors of hardware to connect the ground XBee radio modem to the GCS computer.<br/>
More information about general USB-Serial adapters can be found on the [[Serial_Adapter]] page.

====Adafruit====

[[Image:xbeeadapter_LRG.jpg|thumb|left|Adafruit XBee adapter board]][[Image:xbeeadapterftdi_LRG.jpg|thumb|Adafruit XBee adapter with FTDI cable]]
[http://www.adafruit.com/index.php?main_page=product_info&cPath=29&products_id=126 Adafruit] offers a great adapter board kit for the Xbee modules that includes a 5-3.3V voltage regulator, power and activity LEDs, and pins to connect directly to your FTDI cable for $10! Some assembly required.

<br style="clear:both">

====Droids====

[[Image:XBee_Simple_Board.jpg|thumb|left|XBee Simple Board]]

[[Image:XBee_USB_Board.jpg|thumb|left|XBee USB Board]]

[http://www.droids.it/cmsvb4/content.php?143-990.001-XBee-Simple-Board XBee Simple Board]

Simple breakout board with voltage regulator.

[http://www.droids.it/cmsvb4/content.php?152-990.002-XBee-USB-Board XBee USB Board]

Adapter with FTDI chip for direct USB connection.

<br style="clear:both">

====PPZUAV====

[[Image:FTDI_Utility_Board.jpg|thumb|left|FTDI Utility Board 1.0‎]]

[https://www.ppzuav.com/osc/product_info.php?products_id=111 ppzuav.com product link]<br/>
More information at the [[Serial_Adapter#FTDI_utility_Board]] page.

FTDI Utility Board 1.0 with FTDI232RL<br/>
On board XBEE connector and Molex Picoblade connectors.

<br style="clear:both">

====Sparkfun====

[[Image:XBee_Explorer_USB.jpg|thumb|left|XBee Explorer USB]]

[http://www.sparkfun.com/products/8687 sparkfun.com]

XBee Explorer USB with FTDI232RL

<br style="clear:both">

=== Digi XBee Pro DigiMesh / 802.15.4 ("Series 1") ===
*Note: Products based on XBee ZNet 2.5 (formerly Series 2) modules do not communicate with products based on XBee DigiMesh / 802.15.4 (formerly Series 1) modules.

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

{|
|-valign="top"
|[[Image:Xbee_Pro_USB_RF_Modem.jpg|thumb|left|XBee Pro USB Stand-alone Modem (XBP24-PKC-001-UA)]]
|
* Frequency Band 2.4GHz
* Output Power 100mW (Xbee Pro)
* Sensitivity -100 dBm
* RF Data Rate Up to 250 Kbps
* Interface data rate Up to 115.2 Kbps
* Power Draw (typical) 214 mA TX / 55 mA RX
* Supply Voltage 3.3v
* Range (typical, depends on antenna & environment) Up to 1500m line-of-sight
* Dimensions 24 x 33mm
* Weight 4 grams
* Interface 20-pin mini connector
* Chip antenna, ¼ monopole integrated whip antenna or a U.FL antenna connector (3 versions)
* Price: 16€, Pro 26€
|
[[Image:XBee_pro.jpg|thumb|left|XBee Pro OEM Modem]]
|}
Mouser: [http://au.mouser.com/Search/ProductDetail.aspx?qs=sGAEpiMZZMtJacPDJcUJYzVn8vIv7g2fIpf5DCzJqko%3d 888-XBP24-PKC-001-UA]<br>
NOTE: If you wish to use this unit with another XBee type other than the 802.15.4 (i.e. XBee-PRO ZB) then purchase a modem with the U.fl connector.

==== Documentation ====

* [http://www.maxstream.net/products/xbee/xbee-pro-oem-rf-module-zigbee.php product page]
* [http://www.maxstream.net/products/xbee/datasheet_XBee_OEM_RF-Modules.pdf datasheet]
* [http://www.maxstream.net/products/xbee/product-manual_XBee_OEM_RF-Modules.pdf user manual]
* To program your Xbee you need X-CTU you can download it [http://www.digi.com/support/productdetl.jsp?pid=3352&osvid=57&tp=5&s=316 here]. (only windows)
* explanation on X-CTU [http://www.ladyada.net/make/xbee/configure.html here].
* [http://ftp1.digi.com/support/firmware/update/xbee/ Drivers for XB24 and XBP24 modules]

=== Digi XBee Pro ZB / ZNet 2.5 ("Series 2") ===

The low-power XBee ZB and extended-range XBee-PRO ZB use the ZigBee PRO Feature Set for advanced mesh networking.

{|
|-valign="top"
|[[Image:XBee_Pro_2SB.jpg|thumb|left|Digi XBee Pro ZB]]
|
* Low-cost, low-power mesh networking
* Interoperability with ZigBee PRO Feature Set devices from other vendors*
* Support for larger, more dense mesh networks
* 128-bit AES encryption
* Frequency agility
* Over-the-air firmware updates (change firmware remotely)
* ISM 2.4 GHz operating frequency
* XBee: 2 mW (+3 dBm) power output (up to 400 ft RF LOS range)
* XBee-PRO: 50 mW (+17 dBm) power output (up to 1 mile RF LOS range)
* RPSMA connector, U.FL connector, Chip antenna, or Wired Whip antenna
* price : 14€, Pro 28€
|
|}
These are available from Mouser:<br>
[http://au.mouser.com/Search/Refine.aspx?Keyword=888-XBP24-Z7WIT-004 888-XBP24-Z7WIT-004] XBee-PRO ZB with whip antenna<br>
[http://au.mouser.com/Search/Refine.aspx?Keyword=XBP24-Z7SIT-004 888-XBP24-Z7SIT-004] XBee-PRO ZB with RPSMA

See [[XBee_configuration|XBee Configuration]] for setup.

==== Documentation ====
* [http://www.digi.com/products/wireless/zigbee-mesh/xbee-zb-module.jsp http://www.digi.com/products/wireless/zigbee-mesh/xbee-zb-module.jsp]

=== Digi XBee Pro 868 ===

'''WARNING - THESE MODEMS HAVE A 10% DUTY CYCLE, AND CURRENTLY HAVE SEVERE ISSUES WITH PAPARAZZI'''

868MHz is a limited band. Please read the [[868MHz Issues]]

XBee-PRO 868 modules are long range embedded RF modules for European applications. Purpose-built for exceptional RF performance, XBee-PRO 868 modules are ideal for applications with challenging RF environments, such as urban deployments, or where devices are several kilometers apart.

{|
|-valign="top"
|[[Image:xbeeproxsc-rpsma.jpg|thumb|left|Maxstream XBee Pro 868]]
|
* 868 MHz short range device (SRD) G3 band for Europe
* Software selectable Transmit Power
* 40 km RF LOS w/ dipole antennas
* 80 km RF LOS w/ high gain antennas (TX Power reduced)
* Simple to use peer-to-peer/point-to-mulitpoint topology
* 128-bit AES encryption
* 500 mW EIRP
* 24 kbps RF data rate
* price : ~70 USD
|
|}

See [[XBee_configuration#XBee_Pro_868_MHZ|XBee Configuration]] for setup.

==== Documentation ====
* [http://www.digi.com/products/wireless/point-multipoint/xbee-pro-868.jsp http://www.digi.com/products/wireless/point-multipoint/xbee-pro-868.jsp]

=== Digi XBee 868LP ===

XBee 868LP modules are a low-power 868 MHz RF module for use in Europe. The range is shorter than it's brother the XBee PRO-868, but it can use the 868 G4 band with hopping which does not have restrictions on it's duty cycle. This is a big advantage if one want to have a good stream of telemetry data

{|
|-valign="top"
|[[Image:868lp.jpg|thumb|left|XBee 868LP]]
|
* 868 MHz short range device (SRD) G4 band for Europe
* 4 km RF LOS w/ u.fl antennas
* 5 mW EIRP
* 10 or 80 kbps RF data rate
* price : 18€
|
|}

==== Documentation ====
* [http://www.digi.com/products/wireless-wired-embedded-solutions/zigbee-rf-modules/zigbee-mesh-module/xbee-868lp#overview http://www.digi.com/products/wireless-wired-embedded-solutions/zigbee-rf-modules/zigbee-mesh-module/xbee-868lp#overview]

==== Trial ====

With a quickly crafted and not optimal positioned antenna on the airframe we managed to get the advertised 4000 meter range. Data throughput was not high and the Iridium Telemetry XML configuration document was therefore used. All in all, cheap, easy to setup, pin compatible with regular modules and quite a range and usable in Europe without hassle.

=== Digi XBee Pro 900HP ===
* Frequency band 900Mhz
* RF rate 10 or 200 kbps
* up to 250mW output power
* 5 to 8 grams
* price: 32€

==== Documentation ====
[http://ftp1.digi.com/support/documentation/90002173_H.pdf http://ftp1.digi.com/support/documentation/90002173_H.pdf]

=== Digi XBee Pro XSC 900MHz ===

Maxstream has recently announced a promising new line of modems combining the small size and low cost of their popular Xbee line with the long range and 2.4 GHz video compatibility of their high end 900 MHz models. Sounds like the perfect modem for anyone who can use 900 MHz. Give them a try and post your results here!
{|
|-valign="top"
|[[Image:xbeeproxsc-rpsma.jpg|thumb|left|Maxstream XBee Pro XSC]]
|
* Frequency Band 900 MHz
* Output Power 100 mW (+20 dBm)
* Sensitivity -100 dBm
* RF Rate: 10 or 20 kbps
* Range (typical, depends on antenna & environment) Up to 24km (15 miles) line-of-sight
* Interface 20-pin mini connector (Xbee compatible pinout)
* RPSMA, integrated whip antenna or U.FL antenna connector (3 versions)
* price : 32€
|
|}

==== Documentation ====
* [http://www.digi.com/products/wireless/point-multipoint/xbee-pro-xsc.jsp http://www.digi.com/products/wireless/point-multipoint/xbee-pro-xsc.jsp]

==== Trials ====
Tested one today and it worked great. Going to try a multiUAV test with it soon
--Danstah
<br>
<br>
MultiUAV tests concluded this is probably not the best module to use. Even though it says you can change the baudrate inside x-ctu that is not the case, it is fixed at 9600 bps. This is a great modem however for single UAV's and I do recommend.
--Danstah
<br>
<br>
Why would the European (868 MHz) be good to 24kbps and this only to 9600? When I was altering my XBees (2.4Ghz Pro's) I had this problem altering baud rates until I read you have to send a "commit and reboot" type command after setting the baud rate. Could this be the case? --GR

=== Digi 9XTend ===

These larger units have been tested on the 900Mhz band, but are also available in 2.4Ghz. They are a bit on the heavy side, about 20 grams, but give good performance at range. They have adjustable transmit power settings from 100mW to 1W. Testing has shown range up to 5.6km (3.5 Miles) with XTend set to 100mW with small 3.1dB dipole antenna.

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

==== Pinout ====

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

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

==== Documentation ====

* [http://www.maxstream.net/products/xtend/oem-rf-module.php product page]
* [http://www.maxstream.net/products/xtend/datasheet_XTend_OEM_RF-Module.pdf datasheet]
* [http://www.maxstream.net/products/xtend/product-manual_XTend_OEM_RF-Module.pdf user manual]

==== Configuration ====

These modems need to be carefully configured based on your usage scenario to obtain the best possible range and link quality. In addition, it is always good to make sure the firmware is up to date.

Some typical configurations that may work well, but can still depend your particular situation, are given below. For further details, be sure to consult the XTend users manual. Your application may need a different or modified configuration. The radiomodems do not need identical settings and can in fact be optimized with different settings. A good example is delays and retries: if each radio has the same number of retries and no delay, when a collision occurs each will continuously try to re-transmit, locking up the transmission for some time with no resolution or successful packet delivery. Instead, it is best to set the module whose data should have a lower latency to have no delay and a lower number of retries, while the other module has a delay set (RN > 0) and a greater number of retries. See acknowledged mode example below.

* Acknowledged Polling Mode ('''Recommended'''):
** This causes one radio to be the base and the other(s) to be the remote(s). It eliminates collisions because remotes do not send data unless requested by the base. It can work in acknowledged mode (RR>0), basic reliable mode (MT>0) or in basic mode (no acknowledgement or multiple packets). It is recommended that the lower latency and/or higher data rate side be configured as the base (i.e. if you are sending lots of telemetry then the air module configured as the base is probably a good idea, but if you are using datalink joystick control, the ground side might be better as the base. It may require some experimentation).
* Acknowledged Point-to-(Multi)Point Mode:
** Each radio sends a packet and requests and acknowledgement that the packet was sent from the receiving side. The retries and delays must be set appropriately to ensure packet collisions are dealt with appropriately. It can also work without acknowledgements in basic reliable mode (MT>0) without any acknowledgements (RR=0, MT=0). Some experimentation may be required.

{| border="1"
|-valign="top"
||'''''Setting Name'''''||colspan="2"|'''''Acknowledged Mode'''''||colspan="2"|'''''Polling Mode (Acknowledged)'''''||'''''Notes'''''
|-
|| ||'''''Airside Module'''''||'''''Groundside Module'''''||'''''Base Module'''''||'''''Remote Module'''''||
|-
||BD||6||6||6||6||Adjust to match your configured autopilot and ground station baud rates (default for these is 57600bps)
|-
||DT||default||default||0x02||0x01||Can be adjusted if consistency maintained across addressing functionalities (see manual)
|-
||MD||default||default||3 (0x03)||4 (0x04)||
|-
||MT||0||0||0||0||Use this to enable Basic Reliable transmission, link bandwidth requirement increases (see manual)
|-
||MY||default||default||0x01||0x02||Can be adjusted if consistency maintained across addressing functionalities (see manual)
|-
||PB||default||default||0x02||default||Can be adjusted if consistency maintained across addressing functionalities (see manual)
|-
||PD||default||default||default||default||Can be adjusted to increase polling request rate and DI buffer flush timeout (see manual)
|-
||PE||default||default||0x02||default||Can be adjusted if consistency maintained across addressing functionalities (see manual)
|-
||PL||default||default||default||default||''Transmit power level should be reduced for lab testing!!''
|-
||RN||0 (0x00)||8 (0x08)||default||default||
|-
||RR||6 (0x06)||12 (0x0C)||6 (0x06)||12 (0x0C)||
|}

'''Note:''' All settings are assumed to be default except those listed. Those listed are in decimal unless hex 0x prefix included. Depending on your firmware version, slight modifications may be necessary.

Here is some additional information and alternative instructions to configure the polling mode from the Digi site: [http://www.digi.com/support/kbase/kbaseresultdetl?id=2178 Polling Mode for the 9XTend Radio Modem]

== SiLabs Si1000 SoC based modems ==

The Si1000 radio System on Chip (SOC) produced by SiLabs is found in a number of radio modules, for example the cheap and widely used HopeRf module. There is [https://github.com/RFDesign/SiK open source firmware] for these radios which makes them suitable for use in MAVs.

The latest SiK firmware supports also mesh topologies.

Online documentation for the Sik firmware shows how to configure it for various jurisdictions. The firmware supports 433 MHz, 470 MHz, 868 MHz and 900 MHz radios. The new RFD868 also orks in the European spectrum licences (868 MHz)

Note: When using a SiK firmware radio with paparazzi, you should set "ATS6=0" (MavLink packing off) and configure paparazzi for transparent serial mode. Better still create a special module to na=make full use of the RFDxxx modem

[http://www.rfdesign.com.au/index.php/rfd900 This module] is well proven and supports antenna diversity. A combination of 6dbi Yagi plus a dipole on the ground station, with a pair of orthogonality oriented dioples in the airframe, has been extensively tested and proven reliable at >8km range (theoretical range of > ~40km).

Alternatively, for shorter range a pair of cheap generic HopeRF-based modems [http://rctimer.com/index.php?gOo=goods_details.dwt&goodsid=815 such as these]

The RFD900 can be paired with cheap generic (single front-end) modules, if for example you use a small short range airframe with a ground station that's also used for long range operations.

== Laird (ex Aerocom) ==
Lairds's API mode is already implemented but some system integration is required. Full API more with addressed packets works well and was tested with AC4790-1x1 5mW low power modules. Maximim range achieved with a whip quater-wave antenna was 1Km.

How to use this modem on ground station side? [http://paparazzi.enac.fr/wiki/index.php/User:SilaS#SDK-AC4868-250_ground_modem_part]

See folder paparazzi3 / trunk / sw / aerocomm. It has all the required files to use this modem on the airborne and ground station side. The link.ml file is a direct replacement of the "main" link.ml file of the ground sttaion and will be merged into it in the future.. or you can do it as well.

{|
|
=== AC4790-200 ===
* Frequency 902-928MHz (North America, Australia, etc).
* Output Power 5-200mW
* Sensitivity (@ full RF data rate) -110dB
* RF Data Rate up to 76.8 Kbps
* INterface Data Rate Up to Up to 115.2 Kbps
* Power Draw (typical) 68 mA
* Supply Voltage 3.3v & 5.5V
* Range (typical, depends on antenna & environment) Up to 6.4 kilometers line-of-sight
* Dimensions 42 x 48 x 5mm
* Weight < 20 grams
* Interface 20-pin mini connector
* Antenna MMCX jack Connector or internal
* price : 52€
|
[[Image:ac4868_transceiver.jpg|thumb|left|AC4868 OEM Modem]]
|
|-
|
=== AC4790-1000 ===
* Frequency 902-928MHz (North America, Australia, etc).
* Output Power 5-1000mW
* Sensitivity (@ full RF data rate) -99dB
* RF Data Rate up to 76.8 Kbps
* INterface Data Rate Up to Up to 115.2 Kbps
* Power Draw (typical) 650 mA
* Supply Voltage 3.3V only
* Range (typical, depends on antenna & environment) Up to 32 kilometers with high-gain antenna
* Dimensions 42 x 48 x 5mm
* Weight < 20 grams
* Interface 20-pin mini connector
* Antenna MMCX jack Connector
* price : 64€
|}

=== Pinout ===

[[Image:Aerocomm_AC4868_pinout.jpg|thumb|left|Laird AC4868 modem pinout]]
[[Image:Aerocomm_AC4490-200_wired.jpg|thumb|left|Laird AC4490 wiring example]]
<br style="clear:both">

{| border="1"
|+ Wiring the Laird AC4868 to the Tiny
|-valign="top"
||'''''AC4868 20-pin Header'''''||'''''Name'''''||'''''Color'''''||'''''Tiny v1.1 Serial-1'''''||'''''Tiny v2.11 Serial'''''||'''''Notes'''''
|-
||2||Tx||green||7||7||''(Note 1)''
|-
||3||Rx||blue||8||8||''(Note 1)''
|-
||5||GND||black||1||1|| -
|-
||10+11||VCC||red||2||3||+3.3v ''(Note 2)''
|-
||17||C/D||white||3||?||Low = Command High = Data
|}
''Note 1 : names are specified with respect to the AEROCOMM module''

''Note 2 : AC4790-1000 needs pins 10 and 11 jumped to work properly''

=== Laird RM024 ===
[[Image:Laird_LT2510_RM024-P125-C-01-side.jpg|thumb|RM024 P125]]
[[Image:Lt2510_prm123.jpg|thumb|LT2510 Modem]]
The RM024 replaces the discontinued LT2510 (they are backwards compatible).

General features:
* Frequency Band 2.4GHz
* Output Power 2,5mW - 125mW
* Sensitivity -98dbm @ 280kbps/-94 dBm @ 500kbps
* RF Data Rate 280/500 kbps
* UART up to 460800 baud
* Power Draw 90mA - 180mA TX / 10mA RX
* Supply Voltage 3.3v
* Range up to 4000m
* Dimensions 26 x 33 x 4mm
* Weight 4 grams
* Interface 20-pin mini connector (smd solder pad or XBee compatible pin header)
* Chip antenna, U.FL antenna connector or both
* Price: 29-31€ @ mouser (SMD / XBEE header)

Two different mounting/pinuts are available:<br/>
* smd version: can be soldered on a pcb<br/>
* pin header: standard XBEE pinout (this is the SMD version mounted on a seperate pcb with male pin headers)

Available in two different output power versions:
{|border="1"
|-valign="top"
||''value''||''50mW version''||''125mW version''
|-
|output power
| 2,5 mW - 50 mW
| 2,5 mW - 125 mW
|-
|output power dbm
|4 dbm - 17 dbm
|4 dbm - 21 dbm
|-
|TX drain
|90mA
|<180mA
|-
|max range (280kbps with 2 dbi antenna)
|2400m
|4000m
|-
|approval
|CE for EU, FCC/IC for USA,
Canada PRM122/123 also for Japan
|FCC/IC for USA, Canada
|}

The RM024 uses frequency hopping (FHSS) which needs a client/server model. That means that one modem (most appropriately the ground station modem) needs to be set to server mode. It will transmit a beacon message and have all client modems synchronize to that in a time and frequency hopping scheme manner. For that all modems need to have the same channel (in fact the hopping scheme) and system-id. Clients can be set to auto-channel and auto-system-id to follow any/the first visible server.

====Documentation====
[http://www.lairdtech.com/WorkArea/DownloadAsset.aspx?id=2147488576 RM024 User Manual]<br/>
[http://www.lairdtech.com/WorkArea/linkit.aspx?LinkIdentifier=id&ItemID=4379 LT2510 User Manual]<br/>
[http://www.lairdtech.com/zips/Developer_Kit.zip Windows configuration tool]

'''Setup'''

Look at the [[Laird_RM024_setup page]]

== Bluetooth ==
These modems do not give you a great range but Bluetooth can be found in a lot of recent laptops built-in. Maybe not useful for fixed wing aircrafts it might be used for in-the-shop testing or quadcopters. Make sure you get a recent Class 1 EDR 2.0 stick if you buy one for your computer.
{|
|
=== RN-41 Bluetooth module(Sparkfun's WRL-08497) ===
* Frequency Band 2.4GHz
* Output Power 32 mW
* RF Data Rate up to ~300 kbps in SPP
* Interface Data Rate up to 921 kbps
* Power Draw (typical) 50 mA TX / 40 mA RX
* Supply Voltage 3.3v
* Range (typical, depends on antenna & environment) 100 meters line-of-sight
* Dimensions 26 x 13 x 2mm
* Weight ~1.5 grams
* Interface solder connector
* price : 20€
|
[[Image:roving_nw_wiring.jpg|thumb|Roving Networks modem wiring]]
|-
|

To connect to it, get the MAC address of the bluetooth modem

me@mybox:~$ hcitool scan
Scanning ...
00:06:66:00:53:AD FireFly-53AD

either make a virtual connection to a Bluetooth serial port each time you connect

sudo rfcomm bind 0 00:06:66:00:53:AD

or configure it once in /etc/bluetooth/rfcomm.conf

rfcomm0 {
bind yes;
device 00:06:66:00:53:AD;
}

now you can use Bluetooth as '''/dev/rfcomm0''' with the Paparazzi 'link'. You might need to restart 'link' in case you get out of range and it disconnects (tbd). Set the Tiny serial speed to 115200 as the modules come preconfigured to that.
|}

== WiFi ==

== ESP8266 Chip Module ==

[[File:ESP8266.jpg|thumbnail|left|ESP8266 WiFi module]]

To have a simple connection from your GCS to your autopilot, one can use your GCS computer built-in WiFi to establish a dataconnection. THe only thing you need is a WiFimodule connected to your Autopilot dataport and a laptop or other GCS device with Wifi.

Flash the Wifimodule with [https://github.com/beckdac/ESP8266-transparent-bridge transparent bridge firwmware] using [https://github.com/themadinventor/esptool esptool]. When connected through WiFi, you can use telnet to set the baud rate.

telnet 192.168.4.1
+++AT BAUD 57000

To use with paparazzi GCS, the TCP signals need to be tunnelled to a virtual serial device. This was accomplished with the "socat" command

$ socat -d -d PTY,link=/dev/mywifi TCP:192.168.4.1:23

Satar up Paparazzi Center and make line like:

<br style="clear:both">

== Telemetry via Video Transmitter==

[[Image:video_tx_small.jpg|thumb|2.4GHz Video Transmitter]]
In order for the UAV to transmit video from an onboard camera, an analog video transmitter can be used. These vary in power, and thus range, and run normally on 2.4Ghz. Small UAVs can get about 600m of range from the 50mW version, and extended range can be achieved using units up to 1W. Weight for these units varies from a couple grams to about 30 for the 1W with shielding. Please check for your countries regulations on 2.4Ghz transmission, as each is different.

It is possible to use the audio channel to send simple telemetry data to the groundstation. Uploading telemetry not possible via analog audio transmitter only.
<br style="clear:both">

== Antennas ==

Here are some examples of lightweight and efficient 868MHz antennas developped by the RF laboratory at ENAC.
[[Image:868mhz_twinstar_antenna_1.jpg|thumb|left|868MHz copper foil antenna attached to the aircraft tail]]
[[Image:868mhz_twinstar_antenna_2.jpg|thumb|left|868MHz copper foil antenna bottom view]]
[[Image:868mhz_ground_antenna.jpg|thumb|left|868MHz ground antenna]]
<br style="clear:both">

This wiki page might give some ideas about antennas: http://en.wikipedia.org/wiki/Dipole_antenna

[[Category:Hardware]]

Connectors and Wiring

2016-01-07T15:00:49Z

IHaveADrone:

The Hirose DF13 series look pretty similar to the Molex Picoblade, although they have a different form factor and may not fit! <br/>
Check the type of connector before ordering (3D Robotics and HK/Chinese manufacturers may use one of these connector types).

== Molex PicoBlade™ 1.25mm (.049") Pitch Connector System ==

[[Image:molex_plug.gif|thumb|Molex plug]]

Paparazzi autopilots use [http://www.molex.com/cgi-bin/bv/molex/jsp/family/intro.jsp?BV_SessionID=@@@@1727607529.1210263742@@@@&BV_EngineID=cccdadedmmeeehecflgcehedffgdfmk.0&oid=-10261&channel=Products&familyOID=-10261&frellink=Introduction&chanName=family&pageTitle=PicoBlade%20|%20Overview 1.25mm Molex PicoBlade™] headers for all connections. Users must make their own wiring harnesses by either crimping the molex terminal pins onto their wiring or soldering pre-crimped wires to their peripherals.
* Be sure to order plenty of 1.25mm [[Media:molex-female-510210200_sd.pdf|Molex plugs]] (female)
* Current: 1.0A
* Wires are available (post sources) with pins already crimped - simply trim and solder these to your peripherals and assemble them into the Molex plugs. Try [http://www.farnell.com/ Farnell] Part number 112-5276 or 112-5274, RS-Components [http://uk.rs-online.com/web/search/searchBrowseAction.html?method=searchProducts&searchTerm=279-9516&x=0&y=0 279-9516] or [http://uk.rs-online.com/web/search/searchBrowseAction.html?method=searchProducts&searchTerm=279-9544&x=30&y=20 279-9544]. In the US Newark has them. Part number [http://www.newark.com/jsp/search/productdetail.jsp?sku=93K4876 93K4876] ~$10 for 10 300mm wires with a socket on each end.

=== 1.25mm (0.049") Pitch PicoBlade Receptacle (Female) ===

[[Image:Molex_crimp.jpg|thumb|Inserting a Molex crimp]]

These are the connector housings, used in the wiring harness and not the PCB

* [http://www.mouser.com/search/ProductDetail.aspx?R=51021-0200virtualkey53810000virtualkey538-51021-0200 51021-0200] 1.25mm Molex PicoBlade Receptacle 2pos
* [http://www.mouser.com/search/ProductDetail.aspx?R=51021-0300virtualkey53810000virtualkey538-51021-0300 51021-0300] 1.25mm Molex PicoBlade Receptacle 3pos
* [http://www.mouser.com/Search/ProductDetail.aspx?qs=ILqg114nvd6Z%252bmZXFEtu8g%3d%3d 51021-0400] 1.25mm Molex PicoBlade Receptacle 4pos
* [http://www.mouser.com/search/ProductDetail.aspx?R=51021-0500virtualkey53810000virtualkey538-51021-0500 51021-0500] 1.25mm Molex PicoBlade Receptacle 5pos
* [http://www.mouser.com/Search/ProductDetail.aspx?qs=hSmm4fxMIuNmj4UzNb1XZA%3d%3d 51021-0700] 1.25mm Molex PicoBlade Receptacle 7pos
* [http://www.mouser.com/search/ProductDetail.aspx?R=51021-0800virtualkey53810000virtualkey538-51021-0800 51021-0800] 1.25mm Molex PicoBlade Receptacle 8pos
* [http://www.mouser.com/search/ProductDetail.aspx?R=51021-1000virtualkey53810000virtualkey538-51021-1000 51021-1000] 1.25mm Molex PicoBlade Receptacle 10pos

=== 1.25mm (0.049") Female Crimp Terminals ===

The 1.25mm terminals are extremely small and ''cannot and should not be soldered, crimped with pliers, or attached by any tool other than the genuine Molex crimper.'' Remember that if a wire comes loose, any wire, the plane will crash!

* [http://www.mouser.com/search/ProductDetail.aspx?R=50058-8000virtualkey53810000virtualkey538-50058-8000 Mouser 50058-8000] 28-32 tape ($0.04-0.07 USD based on qty)
* [http://www.mouser.com/search/ProductDetail.aspx?R=50079-8000virtualkey53810000virtualkey538-50079-8000 Mouser 50079-8000] 26-28 tape ($0.03-0.07 USD based on qty)

or

* [http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=WM1142CT-ND Digi-Key WM1142CT-ND] 26-28 AWG
* [http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=WM1775-ND Digi-Key WM1775-ND] 28-32 AWG

[[Image:molex_pin.gif|thumb|Molex pin]]

=== Crimpers ===

[[Image:molex_crimper.jpg|thumb|Molex Crimper]]

Crimpers are available from Mouser or Digi-Key for approximately $200 USD and will prove worthwhile for most users. The fact that Wire-to-Wire Plugs are available should make this Crimper an even more worthwhile investment.

* Strip Length should be between 1.40 to 1.90mm
* Wire Insulation Range should be < 1.0mm with the 28-32AWG Terminals and < 1.04mm with the 26-28AWG Terminals

* [http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=WM9984-ND Digi-Key WM9984-ND] for 26-32 AWG wire
* [http://www.mouser.com/search/refine.aspx?Ntt=63811-0300 P/N# 63811-0300] for 28-26 AWG wire (obsolete)
* [http://www.mouser.com/search/refine.aspx?Ntt=63811-0200 P/N# 63811-0200] for 32-28 AWG wire (obsolete)

=== 1.25mm (0.049") Pitch PicoBlade Plug (Male, Wire-to-wire) ===

These Plugs are for Wire-to-Wire connections and they are not required. Their reference here is for convenience only.

* [http://www.mouser.com/search/ProductDetail.aspx?R=51047-0200virtualkey53810000virtualkey538-51047-0200 51047-0200] 1.25mm Molex PicoBlade Plug 2pos
* [http://www.mouser.com/search/ProductDetail.aspx?R=51047-0300virtualkey53810000virtualkey538-51047-0300 51047-0300] 1.25mm Molex PicoBlade Plug 3pos
* [http://www.mouser.com/search/ProductDetail.aspx?R=51047-0400virtualkey53810000virtualkey538-51047-0400 51047-0400] 1.25mm Molex PicoBlade Plug 4pos
* [http://www.mouser.com/search/ProductDetail.aspx?R=51047-0500virtualkey53810000virtualkey538-51047-0500 51047-0500] 1.25mm Molex PicoBlade Plug 5pos
* [http://www.mouser.com/search/ProductDetail.aspx?R=51047-0600virtualkey53810000virtualkey538-51047-0600 51047-0600] 1.25mm Molex PicoBlade Plug 6pos
* [http://www.mouser.com/search/ProductDetail.aspx?R=51047-0700virtualkey53810000virtualkey538-51047-0700 51047-0700] 1.25mm Molex PicoBlade Plug 7pos
* [http://www.mouser.com/search/ProductDetail.aspx?R=51047-0800virtualkey53810000virtualkey538-51047-0800 51047-0800] 1.25mm Molex PicoBlade Plug 8pos
* [http://www.mouser.com/search/ProductDetail.aspx?R=51047-0900virtualkey53810000virtualkey538-51047-0900 51047-0900] 1.25mm Molex PicoBlade Plug 9pos
* [http://www.mouser.com/search/ProductDetail.aspx?R=51047-1000virtualkey53810000virtualkey538-51047-1000 51047-1000] 1.25mm Molex PicoBlade Plug 10pos

=== 1.25mm (0.049") Male Crimp Terminals ===

These Crimp Terminals are for Wire-to-Wire connections and they are not required. Their reference here is for convenience only.

* [http://www.mouser.com/search/ProductDetail.aspx?R=50133-8000virtualkey53810000virtualkey538-50133-8000 50133-8000] 28-32 tape
* [http://www.mouser.com/search/ProductDetail.aspx?R=50125-8000virtualkey53810000virtualkey538-50125-8000 50125-8000] 26-28 tape

<br style="clear:both;"/>

=== Pre-Crimped Connectors from eBay China (Molex Picoblade) ===

(These are the standard Molex Picoblade connector)

You can find 10pcs female crimp terminals with 10cm wire and and 10 male terminals in a bundle for around 5€
Search for: "mini/micro jst 10pcs"

This is very nice if you do not have a crimp tool and want the cheapest connectors with wires on the market.
Note: the male terminals in 1.25mm pitch and are trough hole technology
Be careful, most SMD male terminals are 1mm pitch and can't be used on the [[Lisa/M]] which has 1.25mm pitch.

== Power Supply ==
For reference, Matthew Currie is assembling his Tiny(s) with WS Deans Micro 2R connectors for power as they are a commonly available R/C connector and are of high quality and durability. They do not have a positive lock mechanism but insert under a lot of pressure. They do not require any special crimping tools and withstand up to 15A.

[[Image:Wsdm3007.png]]

== Wiring ==
Wiring is a critical part of any autonomous vehicle and the importance of high quality reliable wiring cannot be stressed enough. The Molex connectors work best with 0.4mm (26AWG) wire though can also be used with 0.3mm (29AWG) on extremely lightweight models. Larger sizes will not fit. High strand-count wire is strongly advised as it is much less prone to failure from fatigue. The insulation type is critical: silicone is extremely flexible and heat resistant but easily cut or torn, teflon is extremely heat and abrasion resistant but not very flexible. Either choice is good though teflon is more durable and readily available. Standard plastic/vinyl insulated wire does not solder well (insulation melts) and does not crimp well - the vinyl insulation provides little or no strength and wires tend to break at the solder or crimp joints. Some recommended wire sources are:
*Alpha 19 strand Teflon insulated 26AWG wire: [http://www.mouser.com/search/refine.aspx?Ntt=2843%2f19 Mouser P/N: 2843/19]
*[http://www.rdswire.com/ RDS Wire] sells very high strand count (66 strands!) 26AWG and 29AWG silicone wire for around $0.60 to $1 per foot in quantity but they mostly deal with very large production orders and may or may not have small quantities available for a reasonable price. Call them for details.
*[http://www.hobby-lobby.com/hobby-wire.htm Hobby-Lobby] has a great selection of larger silicone wire at great prices but this wire is only useful for motors and batteries. The 0.5mm wire they offer has ''very thick'' silicone insulation and will not fit into the Molex connectors.
*A convenient female USB mini-B receptacle ( [http://www.mouser.com/search/refine.aspx?Ntt=500075-0517 Mouser P/N: 500075-0517]) permits soldering directly without a PCB

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

Developer Guide

2016-01-07T14:54:06Z

IHaveADrone: typo

Lisa

2016-01-07T14:51:45Z

IHaveADrone: typo

<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Autopilots</categorytree>
__TOC__
Lisa ( the Lost Illusions Serendipitous Autopilot) is a range of autopilots based on [http://www.st.com/mcu/inchtml-pages-stm32.html STM32] microcontrollers ( CortexM3@72Mhz ) designed to run Paparazzi.
There's no such thing as a perfect autopilot, only autopilots adapted to a particular purpose. This is the reason why the Lisa autopilots come in different styles for different uses.

The first members of the family are:

*Lisa/L, a design where the STM32 is associated to a gumstix [http://www.gumstix.net/Setup-and-Programming/cat/Overo-Setup-and-Programming/111.html Overo].
*Lisa/M, a design focusing on cost and simplicity.
*Lisa/S, a design focusing on size and weight.

==Lisa/L==

=== Description ===

[[Lisa/L]] is a dual processor board autopilot designed to allow for the possibility of using Linux for Paparazzi airborne code.

[[Image:lisa_l_bloc_diag_simple.png|360px]]
[[Image:lisa_l_top.png|360px]] [[Image:lisa_l_bot.png|360px]]

=== Documentation ===

The documentation for Lisa/L is broken into several parts due to board complexity and Gumstix [[Overo]] integration.
* [[Lisa/L|Main Documentation]] - primary hardware documentation and intro to software
* [[Dev/LisaL|Additional Developer Documentation]] - additional advanced hardware and software documentation and notes
* [[LisaL_Gallery|Lisa/L Photo Gallery]] - pictures of [[Lisa/L]]
* [[User/LisaL/Tutorial/Quadrocopter|Unfinished Rotorcraft Tutorial]] - rotorcraft tutorial, needs considerable work
* [[User/LisaL/Tutorial/FixedWing|Unfinished Fixedwing Tutorial]] - fixedwing tutorial, needs considerable work
* [[OMAP|Gumstix Integration Intro]] - intro and documentation listing for integrating a Gumstix Overo with [[Lisa/L]], including for USB devices and cameras

== Lisa/M ==

=== Description ===

[[Lisa/M]] is a great general purpose small-footprint autopilot. There are currently two versions that have been produced. Detailed documentation can be found here:
* [[Lisa/M_v2.0|Lisa/M v2.0 (current) Documentation]]

[[Image:LisaM_V2_0_TopView.JPG|360px|Lisa/M v2.0 Top View]]

* [[Lisa/M_v1.0|Lisa/M v1.0 Documentation]]

[[Image:lisa_m_top_small.png|360px|Lisa/M v1.0 Top View]]

=== Usage scenarios ===

There are many potential applications for the small, relatively inexpensive and flexible [[Lisa/M]]. For regular Autopilot boards a fully equip [[Lisa/M]] board is needed. For some scenarios just a basic [[Lisa/M]] without an [[Inertial_Measurement_Units|IMU]] and barometric pressure sensor is needed, which reduces the board cost. Here are some ideas (not all have yet to be implemented):

* As a basic Autopilot
** To use the [[Lisa/M]] as an autopilot, you need to attach a GPS receiver. A nice [[GPS#u-Blox_LEA_Series_Receivers|uBlox LEA-5H]] or newer will perform great.
* As an advanced Autopilot
** Additional sensors for measuring airspeed, current, etc. would enhance a fixed-wing airframe.
* As a servo extender
** Sometimes being able to control seven actuators is just not enough. Large airframes may require flaps or an airbrake and automatic landing facilities. Maybe special ACL/Nav lights, or four cameras with zoom. By using a coupled second basic [[Lisa/M]] and connecting this to the master Autopilot board we can extend the amount of servos. Large airframes can also benefit from remote and/or redundant servo drivers.
* As a Safety Pilot Device
** To provide an extra safety level required in some UAS challenges. A second [[Lisa]] board can make it easy to adhere to the rules for such a challenge.
* As a Data Logger
** Maybe you have a need only to log all kinds of data, like temperature, volts, amps, height, airspeed, and not control the aircraft. For this we can setup a [[Lisa/M]] board. Collecting this data can be to a storage medium like on a micro SD card. Sometimes there is no need for real-time data collection through telemetry but just for storing a huge dataset.
* As a Camera controller
** On some models that do not require many servos (for example - flying wing with only 3 channels used), spare channels can be used for camera control. In addition, it could be used as an independent pan-tilt unit (PTU) controller.
* As a Airframe Tracker
** Tracking an airframe for an antenna or camera on a tripod is one of the many optional uses for a [[Lisa/M]] Board.

== Lia ==

Lia is a lower-cost variant of Lisa/M 2.0. The microcontroller, basic layout, servo outputs, and mounting holes are the same. Major differences:
* 0.1" through-hole connections for non-servo I/O instead of Molex picoblade
** PCB size increased slightly to (58x34mm) to accommodate throughholes
* CAN transceiver removed on initial units; populated on later units (see [http://paparazzi.enac.fr/wiki/Lia documentation])
* barometer removed
* I2C level shifter removed
* 5V voltage regulator removed
* Added provisions for multiple BEC input balancing on servo connectors

[[Image:Lia_1.1_top.jpg|360px|Lia v1.1 Top View]]

[[Lia|Lia documentation]]

== Lisa/S ==

Lisa/S is very small autopilot board. The focus for this design is size, weight and power consumption. It's an autopilot suited for the smallest airframes.

[[Image:Lisa_S_V0_1_r2_on_finger.jpg|360px]]

* [[Lisa/S|Lisa/S Documentation]]

[[Category:Lisa]] [[Category:User_Documentation]] [[Category:Autopilots]]

Lisa/S/Tutorial/Nano Quadcopter

2015-12-29T15:04:27Z

IHaveADrone: more spelling errors

<div style="float: right; width: 20%">__TOC__</div>

So you've received your Lisa/S Nano Quadcopter kit, what do you do next...

The following is an example set of instructions on how to put together your new Lisa/S Nano Quadcopter kit. As with all things open source there's always more than one way to do it. So feel free to deviate from the instructions where you feel the need. Of course if you see errors or improvement please feel free to update them.

{{#ev:youtube|7lLxFDNiywM|400}}

== Step 1 - Check the parts and tools ==

First we need to check that we have everything that we need.

The kit contains:
* 1 x Lisa/S
* 1 x Superbit USBRF Dongle
* 2 x CyRF Modules (one mounted on Lisa/S, and one mounted on USBRF dongle)
* 2 x 2.4GHz U.FL whip antennas
* 1 x Cortex JTAG connector to 4 pin SWD connector adapter
* 1 x TTL level UART adapter
* 1 x motor connector adapter kit with battery pigtail
* 2 x 0.05" pitch 10 pin headers
* 1 x 0.05" pitch 4 pin header
* 1 x 120mm class quadcopter frame (brushed motors and propellers included)
* 1 x set of replacement propellers
* 1 x 1S LiPo 230mAh battery
* 1 x battery charger with USB cable
* 1 x 10mm x 10mm GPS patch antenna (optional, only included in the "With GPS Antenna" variant)
* 1 x Black Magic Probe with JTAG and Serial cables (optional, only included in the "With Black Magic Probe" variant)

Other tools:
* A small phillips head screw driver
* A fine tipped soldering iron and solder, flux, etc... (Required if you selected the some soldering required option)
* A multimeter

Useful tools
* A desk vice
* Some 2 mm diameter round toothpicks sanded down to tightly fit the mounting holes of the Lisa/S

== Step 2 - Soldering ==

If you selected the Some Soldering Required option now we need to do that soldering.

* The 4 x 2 pin Molex PicoBlade connectors to the motor adaptor kit PCB
* The battery pig tale to the motor adaptor kit PCB [[File:Soldering.JPG|thumb|none|Soldering]]
* Using the multimeter check that there is '''<u>no</u>''' continuity between the pins of the battery and motor connectors. If there is then you have a solder bridge causing a short which needs to be fixed.
* Check that there is continuity between the positive (red) lead of the battery and the outside pin of the connectors.
* Wash off any flux with flux wash
* Place a tiny amount of solder on the pads on the bottom of the motor adaptor opt PCB where it connects to the Lisa/S. Tip use a solder sucker to suck most of the solder off again. You just want the pads tinned.
* Solder one of the 0.05" pitch 10 pin headers to the Lisa/S CAN, UART, SWD pads
* Alight the motor adaptor PCB with the Lisa/S PCB using the 2 mm toothpicks and solder the 6 pads [[File:Solder_Adaptor_to_LisaS.jpg|thumb|none|Soldering the motor adaptor to the Lisa/S]]
* Wash off any flux with flux wash
* Inspect the PCB to ensuring that all solder joints are wet and no drops of solder have be been left on the board causing shorts.
* Dry the PCB thoroughly with your wife/girlfriends hair dryer while she's out. Remember to put it back as you found it so she doesn't suspect a thing.

Now that you've got this far sit back and bask in the glory of soldering the tiny little joint. You might like to ponder as I did on your decision to opt for the pre soldered kit...

== Step 3 - Assemble the aircraft ==

Now that the fiddly bit has been completed, lets put everything together

* Place a small square of double sided tape on the back of the GPS antenna. [[File:Double_sided_tape.JPG|thumb|none|Double sided tape on the back of the GPS antenna]]
* Attach the GPS antenna to the GPS antenna connector on the Lisa/S
* Attach the CYRF antenna to the CYRF antenna connector [[File:ConnectAntennas.JPG|thumb|none|Antennas connected]]
* Stick the GPS antenna to the back of the CYRF radio PCB [[File:GPS_antenna_stuck_to_CYRF_back.JPG|thumb|none|GPS fixed]]
* Unscrew the 4 screws on the body of the airframe [[File:Airframe_pre-assembly.jpeg|thumb|none|Airframe disassembled]] [[File:LisaS_NanoQ_Assembly_Legend.jpg|thumb|none|Assembly Legend]]
* Insert the 4 arms with attached motors to the body
* Place the Lisa/S on the rubber mounts on the body in your desired orientation and secure with the 4 screws [[File:LisaS_mounted.jpeg|thumb|none|Lisa/S mounted]]
* Connect the 4 motors to the connectors [[File:Motors_connected.jpeg|thumb|none|Motors connected]]

== Step 4 - Install Paparazzi and other tools ==

If you don't already have [http://www.paparazziuav.org/ Paparazzi] installed on a computer now is the time to do so.

Follow the instructions at http://wiki.paparazziuav.org/wiki/Installation.

Tip: If you are installing on Mac OS X we recommend installing using the Source installation method instead of the basic. Some packages in the binary installer might be outdated and cause problems if you decide to use the Basic installation route. With Source installation you guarantee to have the newest packages that are much more likely to work on your version of Mac OS X and XCode.

== Step 5 - Flash the USBRF ==

The superbitrf firmware source code is hosted on Github. Additional information regarding the flashing firmware instructions can be found on the wiki page https://github.com/esden/superbitrf-firmware/wiki.
The flashing firmware instructions are the following:

1. Open your OS terminal window
2. Clone the superbitrf-firmware repository by typing in your terminal command
<code>git clone https://github.com/esden/superbitrf-firmware.git</code>
3. Change directory into the superbitrf-firmware directory via
<code>cd superbitrf-firmware</code>
4. to make sure you have the latest and greatest of supporting source code of libopencm3
<code>git submodule init && git submodule update</code>
5. Now build this code via
<code>make</code>
6. Plug in your Superbit USBRF dongle '''while holding "the button"''' on the Superbit USBRF dongle, into your laptop.
You will see a red and yellow LED blink in turn, indicating that the module is ready to receive and update to the latest firmware you just build.

7. To start the firmware update a.k.a. Flashing your firmware type:
<code>make flash</code>

Wait... and your are done with the update

== Step 6 - Build and upload the Lisa/S firmware ==

While we go through the initial process it would be a good idea to charge the flight battery. You can do this with the [[Lisa/S_Nano_Quadcopter_Kit/BatteryCharger|supplied charger]] or your own battery charger.

Now lets get to building the firmware for the Quadcopter.

# Start Paparazzi Centre by running <code>./paparazzi</code> from a terminal window
# From the A/C menu select <code>LadyLisa</code>
# In the Airframe section check that you have the <code>ladybird_lisa_s.xml</code> airframe file
# In the <code>Target</code> drop down list select <code>ap</code>
# Click the <code>Build</code> button. If everything goes to plan the code will be built and there will not be any errors shown.
# Plug the <code>Serial Wire Debug</code> board into the ribbon cable
# Plug the other end of the ribbon cable into the BlackMagic board
# Plug the USB cable into the BlackMagic board
# Plug the <code>Serial Wire Debug</code> board into the Lisa/S SWD pins
# Plug the other end of the USB cable into a vacant USB port on the computer.
# Connect a fully charged battery to the Lisa/S
# From the <code>Flash mode</code> drop down list select <code>BlackMagic Probe (SWD)</code>
# Click the <code>Upload</code> button. You should see the LEDs of the Lisa/S go out and only the Power LED remains lit while the upload takes place. Once complete the other LEDs will light.

If using the Black Magic Probe use the [http://1bitsquared.com/collections/all-products/products/jtag-idc-cable "JTAG SWD Cable"] with [http://1bitsquared.com/collections/all-products/products/jtag-swd-adapter "JTAG SWD Adapter] and connect to the 4pin SWD header on the [http://1bitsquared.com/collections/autopilots/products/lisa-s Lisa/S] with the adapter facing away from the Lisa/S. [[File:swd.JPG|thumb|none|Connect the 4pin SWD header with the Lisa/S]]

If you are using Mac OS-X, then you have to create a symbolic link for the BlackMagic to be seen as <code>ttyACM0</code>. Plug your BlackMagic board into a USB port on the computer and write " ls -l /dev/*usb* /dev/*USB* " command in a terminal window in order to see the device name. Use the first appearing name which should be something like /dev/cu.usbmodemE3BBA8B7. Then create a sym link with "sudo ln -s /dev/cu.usbmodemE3BBA8B7 /dev/ttyACM0 " command. Check the sym link by "ls -l /dev/ttyACM0 " command. Now the flashing should work.

== Step 7 - Binding your transmitter to the Superbit USBRF dongle ==

1) Plug the Superbit USBRF dongle into one of your computers USB ports
<br>

2) Press "the button" on the Superbit USBRF dongle
<br>''The orange LED on the dongle should have lit up now...''
<br>''NOTE: Sometimes the binding is '''not successful''' on the first try, you might need to '''retry to bind''' before the dongle recognizes your transmitter and the orange LED turns off''
<br>

3) Put your transmitter into binding mode, on most transmitters turn on your transmitter while holding the bind button.
<br>''If the binding with your transmitter was successful the orange LED on the USBRF dongle will turn off''

4) Get your transmitter out of bind mode, most of the time just simply release the bind button on your transmitter
<br>''After few seconds the orange LED will turn off while another LED will light up. This indicates that the transmitter is connected to your dongle and receiving packets from your transmitter''
<br>
<br>
<sub>''Note: for more information how to turn on your transmitter in bind mode refer to your transmitter documentation. This varies a lot depending on the version and make of the transmitter. Spektrum DX6I and Orange TX transmitters you just hold the Trainer switch while you power it on. Others have a dedicated bind button on the back of the transmitter that you hold while turning on your transmitter. Some have a TX menu item for this.''</sub>

== Step 8 - Binding your transmitter to Lisa/S ==

1) Press the bind button on the Lisa/S board and while '''holding it pressed power on the Lisa/S autopilot board''', difficult but doable if you pre-position your battery connector then connect the battery
<br>''The Radio LED should be blinking in short blinks once a second, sometimes hard to notice''

2) Put your '''transmitter into binding mode''', for most most transmitters, just turn on your transmitter while holding the bind button of your transmitter
<br>''The Radio LED on the Lisa/s should stop blinking, this can take even upto 40 seconds, be patient''

[[Category:Lisa]] [[Category:User_Documentation]] [[Category:Tutorial]]

Micro logger

2015-08-18T14:50:04Z

IHaveADrone: typos

=Introduction=

The micro logger is simply a memory chip (S25FL128S or S25FL256S) connected to one SPI port of your autopilot.

===Advantages===
* very light (hard to do lighter)
* no bad connexions (the memory needs to be soldered)

===Disadvantages===
* hard to remove
* slower than other loggers

===Capability===
This logger is capable of logging the entire IMU (9 axis) on 32 bits values at 512Hz. This is possible when you erase completely the memory at the beginning of the log (ERASE_MEMORY_AT_START set to 1).

In case of buffer overflow, the reading tool is capable of "rebuilding" the missed values. It is going to put zeros where we missed values.

=How to use it=
==Configuration of the module==
To configure the messages you want to log, you will need to edit the module c file in : sw/airborne/modules/loggers/high_speed_logger_direct_memory.c. At the top of the file you will have a section containing all the parameters that you can change. Among those you got :
* ERASE_MEMORY_AT_START : if set to 1 the memory will be erased completly when starting a new log. This will take a little bit less than a minute, but afterwards you will be able to log values at a higher rate than if you didn't do it. If you let it to 0, the module is going to erase the memory block by block of 4K when needed.

* SIZE_OF_LOGGED_VALUES : the number of Bytes that each value logged must be (in memory). You can write a 4 Bytes values in a 2 Bytes slots, you just need to be certain that you don't have any overflows.

* NBR_VALUES_TO_LOG : the number of messages you want to log. This value is equivalent to the size of the values_to_log array.

* SKIP_X_CALLS_BETWEEN_VALUES : you might want to slow down the logger instead of losing values (because of buffer overflows). if that value is set to 0, a new value of every logged messages will be added to the buffer. If set to 2, we will wait two calls to the module, then during the third one we will write the values to the buffer. By default this modules is called at 512Hz.

Then you have two arrays :

* values_to_log : containing the pointer to the values to log.
* name_of_the_values : the name of the messages logged. This is simply an aesthetic configuration, for you to know which message were logged.

==Logging values==
To use the micro logger you simply need to load the module "'''high_speed_logger_direct_memory'''" in your airframe file. You might want to be certain of the frequency at which the module is called by loading it like that :

<modules main_freq="512">
<load name="high_speed_logger_direct_memory.xml"/>
</modules>

Then you are going to have to add the GUI to your GCS by adding to your settings the file : "'''settings/modules/high_speed_logger_direct_memory.xml'''".

[[File:GCS mem.png]]

Then in the GCS you can go in the tab settings, then logger. In this tab you will have only one command to change the status of the module.

At the start the module is in idle mode. To start logging you will need to prepare the memory first. To do that simply select the initialize mode and validate. The module will work. To test if the module have completed it's work you can click on the value to the left of the drop down menu. Once completed the status will be back to idle.

Then you can start actually logging values by selecting the "start log" mode and validating.

Once you are done with your log you need to select the "stop log" mode and validate.

==Reading the values back==

[[File:Micro logger.png]]

WARNING !!! : On some boards the UART port is used also by the GPS. The soft behind the GPS might read all the values on the port instead of the logger module. To solve that issue you simply need to use an other UART port for the logger module (configured in : conf/modules/high_speed_logger_direct_memory.xml). The other solution is to move the GPS in you board makefile.

For this operation you will need to get the reader application available [http://karlito139.github.io/lisa_s_logger_reader/ here]. The source code is available [https://github.com/karlito139/lisa_s_logger_reader here].

To read the values back you simply need to connect to your autopilot using a serial connexion. Then start the micro logger application, at the top right of the interface you get a drop down menu containing all the serial ports available on your computer, select the one corresponding to your autopilot. Then simply click on the "Dump memory" button. The application is going to fetch all the values stored in the memory (warning this operation might be slow, up to 40 minutes if you used the entire memory).

Finally you can click on the export button at the bottom of the window to save the values in a csv file.

Lisa/M v2.0

2015-08-13T18:37:17Z

IHaveADrone: typos

<div style="float: right; width: 15%"><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Autopilots</categorytree></div>
<div style="float: right; width: 45%; overflow: hidden">[[Image:LisaM_V2_0_TopView.JPG|right|500px|Lisa/M V2.0 top view]]</div>
<div style="float: right; width: 40%">__TOC__</div>

Lisa/M is a small, general purpose autopilot designed with flexibility across multiple applications in mind. Small weight and size, with (optional) integrated [[AspirinIMU | Aspirin IMU]] and full size 0.1" servo headers make the Lisa/M suitable for both fixed-wing and rotorcraft vehicles. This autopilot is based on a STM32 processor for extensive peripheral connection and faster processing.

A number of tutorials are being prepared for getting started with Lisa/M:
* [[Lisa/M/Tutorial/FixedWing|Fixedwing tutorial]]
* [[Lisa/M/Tutorial/RotorCraft|Rotorcraft tutorial]]

Please join us in our quest to make the getting started information even more, eh... informative, by adjusting those pages with your own improvements.

== Features ==

Lisa/M is based on the 64 pins STM32F105RCT6 [http://www.st.com/internet/mcu/product/221023.jsp connectivity line family] processor featuring 64k of RAM and 256k of FLASH. All the pins are exposed, providing access to the complete set of the STM32 peripherals.
NOTE: This MCU is different from LISA/L. Lisa/L is based on the 64 pins STM32F103RE processor featuring 64k of RAM and 512k of FLASH, which is part of the [http://www.st.com/internet/mcu/product/164485.jsp high-density performance line family].

* STM32 microcontroller [http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00220364.pdf STM32F105RCT6 datasheet] with 256kB flash and 64kB RAM
* Pressure sensor [http://www.bosch-sensortec.com/content/language1/html/3477.htm BMP085] (optional as of 08/2012)
* 7 x Analog input channels
* 3 x Generic digital in-/out-puts
* 2 x 3.3V TTL UART (5V tolerant)
* 8 x Servo PPM outputs (only 6 if second I2C (I2C1) bus in use)
* 1 x CAN bus
* 1 x [http://en.wikipedia.org/wiki/Serial_Peripheral_Interface SPI] bus
* 1 x [http://en.wikipedia.org/wiki/I2c I<sup>2</sup>C] bus (2 x when using only the first 6 Servo PPM outputs)
* 1 x Micro USB
* 4 x status LEDs with attached test point
* 10.8 grams (0.4 oz) (with Aspirin IMU mounted)
* 9.9 grams (0.35 oz) (without Aspirin IMU mounted)
* ~34mm x ~60mm x ~10mm
* 4 layers PCB design

With mounted Aspirin IMU has the following additional sensors on board:

* 3 Axis Gyroscope
* 3 Axis Accelerometer
* 3 Axis Magnetometer
* Barometer MS5611 (as of Aspirin v2.1)

NOTE:
'''Lisa/M has pads for the BMP085 pressure sensor. Lias/M 2 boards made before August 2012 had the BMP085 sensor mounted. Boards made after August 2012 do not have the sensor mounted as they are designed to be used with Aspirin 2.1 which has the new MS5611-01BA03 barometric pressure sensor.'''

So, except for a GPS unit you have all necessary sensors for full attitude and altitude stabilization in an extremely small package.

<gallery widths=200px heights=200px>
Image:LisaM_V2_0_TopView.JPG|Lisa/M V2.0 top view
Image:LisaM_V2_0_BottomView.JPG|Lisa/M V2.0 bottom view
</gallery>

== Pinout ==
Pins Name and Type are specified with respect to the Autopilot Board.

<div style="float: right; width: 100%">
[[Image:LisaM_V2_0_top_labeled.png|900px]]
[[Image:LisaM_warning_label.png|200px]]
</div>

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''SERVO1/2/3/4/5/6/7/8'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||SERVOx||OUT||Servo signal (PWM)(See Note 1 below)||style="background:Yellow; color:black"|Yellow
|-
|2||SV||PWR||Servo Bus Voltage Rail (conf w/ JP1)||style="background:red; color:white"|Red
|-
|3||GND||PWR||common ground||style="background:black; color:white"|Black
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''JTAG'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||N/A||N/A||JTAG Debug Header (Pin 1 is +3V3)||style="background:white; color:black"|None
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''UART3'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2||V_IN||PWR||UART Voltage (conf w/ JP6 and JP7)||style="background:Red; color:white"|Red
|-
|3||TX||OUT||USART3 Serial Output (3.3V level)||style="background:Yellow; color:black"|Yellow
|-
|4||RX||IN||USART3 Serial Input (3.3V level)(Pullup to Pin 2 voltage)(5V tolerant)||style="background:Orange; color:white"|Orange
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''UART1/5'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3V3||PWR||3.3V Rail from autopilot (conf w/ JP8 and JP9)||style="background:Red; color:white"|Red
|-
|3||RX1||IN||USART1 Serial Input (3.3V level)(Pullup to Pin 2 voltage)(5V tolerant)||style="background:Orange; color:white"|Orange
|-
|4||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|5|| +3V3||PWR||3.3V Rail from autopilot (conf w/ JP8 and JP9)||style="background:Red; color:white"|Red
|-
|6||RX5||IN||UART5 Serial Input (3.3V level)(Pullup to Pin 5 voltage)(5V tolerant)||style="background:Orange; color:white"|Orange
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''GPIO'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3V3||PWR||3.3V Rail from autopilot||style="background:Red; color:white"|Red
|-
|4||PC12||I/O||GPIO, connected to PC12 (5V tolerant)||style="background:#FDC579; color:black"|Dark Tan
|-
|5||TRST||I/O||JTAG_TRST (also connected to LED1 cathode)||style="background:#FED6B1; color:black"|Light Tan
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''ANALOG2'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3V3||PWR||3.3V Rail from autopilot||style="background:Red; color:white"|Red
|-
|3|| +5V||PWR||5V Rail from autopilot||style="background:Red; color:white"|Red
|-
|4||ADC4||I/O||by default connected to LED_4 cathode (Remove LED/resistor to use as ADC4)||style="background:magenta; color:white"|Magenta
|-
|5||ADC6||I/O||by default connected to LED_3 cathode (Remove LED/resistor to use as ADC6)||style="background:#FFA1B2; color:black"|Pink
|-
|6||BOOT0||I/O||BOOT0||style="background:grey; color:black"|Grey
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''USB'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||N/A||N/A||USB (The USB connections are also available as 0.05" (1.27mm) through hole pads underneath the GPIO header)||style="background:white; color:black"|None
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''I2C1 CAN'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| V_BATT||PWR||V_BATT Bus on autopilot, voltage divider for V_BAT_MEAS, (conf w/ JP2 to connect to V_IN)||style="background:Red; color:white"|Red
|-
|3|| V_IN||PWR||Connected to autopilot voltage regulator inputs (conf w/ JP1, JP2 and JP3)||style="background:Red; color:white"|Red
|-
|4||CANL||I/O||CANL (5V level)||style="background:orange; color:white"|Orange
|-
|5||CANH||I/O||CANH (5V level)||style="background:yellow; color:black"|Yellow
|-
|6||SCL||I/O||SCL (5V level)(See Note 1 below)||style="background:green; color:white"|Green
|-
|7||SDA||I/O||SDA (5V level)(See Note 1 below)||style="background:blue; color:white"|Blue
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''SPI1'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3V3||PWR||3.3V Rail from autopilot||style="background:Red; color:white"|Red
|-
|3||MOSI||Out||MOSI||style="background:orange; color:white"|Orange
|-
|4||MISO||In||MISO||style="background:yellow; color:black"|Yellow
|-
|5||SCK||Out||SCK||style="background:green; color:white"|Green
|-
|6||SS||Out||SS||style="background:blue; color:white"|Blue
|-
|7||DRDY||I/O||DRDY||style="background:#FDC579; color:black"|Dark Tan
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''ANALOG1'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3V3||PWR||3.3V Rail from autopilot||style="background:Red; color:white"|Red
|-
|3|| +5V||PWR||5V Rail from autopilot||style="background:Red; color:white"|Red
|-
|4||ADC1||In||ADC1 (or LED_6 if populated)||style="background:green; color:white"|Green
|-
|5||ADC2||In||ADC2 (or LED_7 if populated)||style="background:blue; color:white"|Blue
|-
|6||ADC3||In||ADC3 (or LED_8 if populated)||style="background:#FED6B1; color:black"|Light Tan
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''UART2'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3V3||PWR||UART Voltage (conf w/ JP4 and JP5)||style="background:Red; color:white"|Red
|-
|3||TX||OUT||USART2 Serial Output (3.3V level)||style="background:Yellow; color:black"|Yellow
|-
|4||RX||IN||USART2 Serial Input (3.3V level)('''NOT 5V TOLERANT''')(Pullup to Pin 2 voltage)||style="background:Orange; color:white"|Orange
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''I2C2'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3V3||PWR||3.3V Rail from autopilot||style="background:Red; color:white"|Red
|-
|3||SCL||I/O||SCL (3.3V level)||style="background:green; color:white"|Green
|-
|4||SDA||I/O||SDA (3.3V level)||style="background:blue; color:white"|Blue
|}

'''NOTE 1''': SERVO7 and SERVO8 are directly connected to I2C1_SCL and I2C1_SDA lines. Therefore one has to choose, either use SERVO7 and SERVO8 '''OR''' have the I2C1 bus available, if that one needs to be used for whatever reason alongside the I2C2 bus. To use the servos 7 and 8 just set the <define name="USE_SERVOS_7AND8"/> in your airframe file and you are good to go. For this to work one must make sure to have the latest Paparazzi sourcecode.

=== LEDs ===
Lisa/M 2.0 has 5 LEDS (+1 power LED). There are 3 additional LEDs (LED_6, LED_7, LED_8) that are not populated by default (in favor of using ADC1-3 on the ANALOG1 connector).
By default the LEDs are use for:
; LED_1, red: ''SYS_TIME_LED'': blinks with 1Hz
; LED_2, green : ''AHRS_ALIGNER_LED'': blinks until the AHRS is aligned (gyro bias initialized) and then stays on
; LED_3, green : ''GPS_LED'': blinking if trying to get a fix, on if 3D fix
; LED_4, red : ''RADIO_CONTROL_LED'': on if RC signal is ok
; LED_5, green : not set to anything by default

=== Jumper Configuration ===
There are a number of jumpers on Lisa/M used to configure voltage levels and power input.

The default configuration is UART3 VCC at V_IN, UART1/2/5 VCC at +3V3, with the V_SERVO servo voltage rail NOT connected to the autopilot V_IN rail, allowing one to power the autopilot and servos separately. The +5V regulator is NOT bypassed, allowing a regulated +5V on listed headers and for the CAN transceiver and I2C level shifter. The V_BATT connector is NOT connected to V_IN, so one can attach a battery voltage to the V_BATT pin to measure the battery voltage, if so desired.

<gallery widths=380px heights=205px>
Image:LisaM_V2_0_top_jumpers_and_leds.png | Lisa/M v2.0 Top Jumpers and LEDs
Image:LisaM_V2_0_bottom_jumpers.png | Lisa/M v2.0 Bottom Jumpers
</gallery>
<br style="clear:both">

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''Power Jumper Configuration'''
!width="7%"|''Jumper''!!width="20%"|''Bus Connection''!!width="7%"|''Default''!!''Description''
|-
|JP1||SERVO_BUS to V_IN||OPEN||If closed then connects servo header voltage rail SERVO_BUS to autopilot input voltage V_IN rail
|-
|JP2||V_BATT to V_IN||OPEN||If closed then connects I2C1/CAN rail V_BATT to autopilot input voltage V_IN rail
|-
|JP3||V_IN to +5V||OPEN||If closed then connects autopilot input voltage V_IN rail to autopilot +5V rail, bypassing onboard 5V supply
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''UART3 VCC Configuration'''
!width="7%"|''Jumper''!!width="20%"|''Bus Connection''!!width="7%"|''Default''!!''Description''
|-
|JP6||UART3_VCC to V_IN||style="background:black; color:white"|CLOSED||Connects UART3 connector VCC to autopilot input voltage V_IN rail
|-
|JP7||UART3_VCC to +3V3||OPEN||If closed then connects UART3 connector VCC to autopilot +3V3 rail
|}
'''WARNING: UART3 GPS Connector is connected to V_IN, check your GPS input voltage before connecting!!!'''

'''WARNING: DO NOT CLOSE BOTH JP6 AND JP7 SIMULTANEOUSLY!!!'''

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''UART2 VCC Configuration'''
!width="7%"|''Jumper''!!width="20%"|''Bus Connection''!!width="7%"|''Default''!!''Description''
|-
|JP4||UART2_VCC to V_IN||OPEN||If closed then connects UART2 connector VCC to autopilot input voltage V_IN rail '''SEE WARNING BELOW'''
|-
|JP5||UART2_VCC to +3V3||style="background:black; color:white"|CLOSED||If closed then connects UART2 connector VCC to autopilot +3V3 rail
|}
'''WARNING: UART2 RX is NOT 5V TOLERANT. Thus, while possible to connect UART2_VCC to V_IN, DO NOT ATTEMPT THIS. Only use JP5 (the default).

'''WARNING: DO NOT CLOSE BOTH JP4 AND JP5 SIMULTANEOUSLY!!!'''

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''UART1 and UART5 VCC Configuration'''
!width="7%"|''Jumper''!!width="20%"|''Bus Connection''!!width="7%"|''Default''!!''Description''
|-
|JP8||UART1&5_VCC to V_IN||OPEN||If closed then connects UART1 and UART5 connector VCC to autopilot input voltage V_IN rail
|-
|JP9||UART1&5_VCC to +3V3||style="background:black; color:white"|CLOSED||If closed then connects UART1 and UART5 connector VCC to autopilot +3V3 rail
|}
'''WARNING: DO NOT CLOSE BOTH JP8 AND JP9 SIMULTANEOUSLY!!!'''

There are additional jumpers on the board for expert or developer configurations, please see [[Lisa/M_v20#Schematic|schematic]] and [[Lisa/M_v20#Downloads|layout]] for more information.

=== Powering the Board ===

[[Image:LisaM_warning_label.png|right|200px]]

The 3.3V regulator on Lisa/M is a [http://www.micrel.com/page.do?page=/product-info/products/mic5209.shtml MIC5209-3.3YM] capable of delivering up to 500mA. While it is possible to power this regulator with up to 16V, '''DO NOT''' do this. By default, the UART3 RX pin is pulled up to the input voltage V_IN. For this reason, 5V is the maximum input voltage. Note that the UART3 GPS Connector is connected to V_IN, check your GPS input voltage before connecting. If one desires to have V_IN at a higher voltage, the jumpers should be adjusted accordingly. As noted, this regulator can handle up to 16V, though experience has shown that this regulator can become very hot in operation with high input voltages, resulting in potential thermal shutdown while in flight. Depending on the expected current draw, it is best to power this regulator with a lower voltage. 5V is the perfect choice.

The onboard 5V regulator on Lisa/M is a [http://www.national.com/pf/LP/LP2992.html LP2992], a low-noise, low-dropout linear regulator capable of delivering up to 250mA. This regulator can be bypassed with JP3, connecting the autopilot V_IN bus directly to the autopilot 5V bus if, for example, one is using an external 5V regulated supply, and a higher current is needed. Unless external use of 5V is required on the ANALOG1 and ANALOG2 headers, the only 5V usage onboard is for the CAN transceiver and the I2C1 level shifter.

When measuring the supply voltage of a battery with the V_BATT pin (could be connected to V_IN through JP2), it is important to note the maximum voltage limit. The voltage divider on the board for measuring with a 3.3V ADC is --'''V_BAT'''--/\/\'''10k'''/\/\--'''V_BAT_MEAS'''--/\/\'''2k2'''/\/\--'''GND'''--. This means that the maximum allowable voltage on V_BATT is

<math>V\_BAT_{max} = 3.3V*\frac{10k}{2.2k} = 15V</math>

If a higher voltage measurement is desired, another voltage divider is required off-board. Alternatively, one could modify the existing voltage divider (e.g. change 10k resistor to 22k to get 33V maximum). When checking if voltage exceeds the maximum, make sure to consider maximum battery voltage, not nominal voltage (e.g. 4.22V or so for a single lithium cell, not 3.7V nominal, so the maximum number of cells in series is 3, like a 3S LiPo pack).

== Schematic ==
<gallery widths=250px heights=168px>
Image:Lisa_m_v2_0_sheet_1.png | LisaM V2.0 Schematic Sheet 1/3
Image:Lisa_m_v2_0_sheet_2.png | LisaM V2.0 Schematic Sheet 2/3
Image:Lisa_m_v2_0_sheet_3.png | LisaM V2.0 Schematic Sheet 3/3
</gallery>
<gallery widths=250px heights=168px>
Image:Lisa_m_v2_1_r3_sheet_1.png | Lisa/M V2.1 R3 Schematic Sheet 1/2
Image:Lisa_m_v2_1_r3_sheet_2.png | Lisa/M V2.1 R3 Schematic Sheet 1/2
</gallery>
<br style="clear:both">

== Examples of Airborne Equipment Electrical Connections ==

=== Quadrocopter, Spektrum Satellite Receivers, PWM Motor Controllers (ESC) and dedicated avionics Battery Elimination Circuit (BEC) ===

[[File:LisaM_V2_0_wiring_quadrocopter_spektrum_bec_pwmesc.png|700px]]

This is a recommended powering configuration. It eliminates the balancing issues of the built in BECs into the ESCs.

The dotted lines from the BEC show the alternative wiring that does not require closing the VS jumper on the Lisa/M. The disadvantage is that you have to wire/crimp the BEC output wires into the picoblade molex connector providing the battery voltage reference. Usually it is easier to just use the existing "servo" connector on the BEC and closing the jumper instead.

=== Quadrocopter, Spektrum Satellite Receivers and PWM Motor Controllers (ESC) ===

[[File:LisaM_v2_0_wiring_quadrocopter_spektrum_pwmesc.png|700px]]

This configuration assumes the ESCs have a battery eliminator circuit (BEC) function and provide 5 volts on their 5V pins. Closing JP1 powers Lisa/M and the attached accessories.

<span style="color:red">Warning:</span> The built in BECs on the ESCs are usually linear voltage regulators, they are fairly inefficient compared to dedicated BECs that are usually implemented as switching DC/DC converters.

<span style="color:red">Warning:</span> Due to manufacturing differences of BECs, connecting more then one BEC in parallel will likely cause one of the BECs to take majority of the load and dissipate most of the drop down voltage. ([https://en.wikipedia.org/wiki/Linear_regulator Read on how linear voltage regulators work.]) As in this example the BECs are part of the ESCs, one of the ESCs will get warmer than the others, which in turn may lead to reliability issues.

[[File:LisaM_V2_0_wiring_quadrocopter_spektrum_pwmesc_shunts.png|700px]]

<span style="color:green">Tip:</span> To improve balancing between the ESC built in BECs you can add a 1Ohm resistor in the +5V line coming from the motor controller. This will cause some pre-loading of the voltage regulator and improve the load sharing between the BECs while decreasing the efficiency of the supply.

When using cheap ATMega or SiLabs-based PWM motor controllers consider replacing their firmware with either [https://github.com/sim-/tgy Simon Kirby] or [https://github.com/bitdump/BLHeli BLHeli] firmware respectively to get useful performance of your multicopter! You can find a firmware compatibility list [https://docs.google.com/spreadsheet/ccc?key=0AhR02IDNb7_MdEhfVjk3MkRHVzhKdjU1YzdBQkZZRlE here].

=== Quadrocopter, Spektrum Satellite Receivers and I2C Motor Controllers (ESC) ===

[[File:LisaM_V2_0_quadrocopter_spektrum_i2c_esc_wiring.png|700px]]

This diagram "should" be the same for AscTec as well as Mikrokopter motor controller based airframes.

=== Fixedwing, Spektrum Satellite Receivers and Elevons Only ===

[[File:LisaM_V2_0_wiring_fixedwing_spektrum_elevons.png|700px]]

This configuration assumes the ESC has a BEC and provides 5 volts on its 5V pin. Closing JP1 powers Lisa/M and the attached accessories.

=== Fixedwing, Spektrum Satellite Receivers ===

[[File:LisaM_V2_0_wiring_fixedwing_spektrum.png|700px]]

This configuration assumes the ESC has a BEC and provides 5 volts on its 5V pin. Closing JP1 powers Lisa/M and the attached accessories.

=== Transitioning [http://wiki.thequadshot.com Quadshot] Using Spektrum Receivers ===

[[File:LisaM_V2_0_wiring_quadshot_spektrum.png|700px]]

The ESCs have BECs and provide 5 volts on their 5V pins. Closing JP1 powers Lisa/M and the attached accessories.

Still need: Large Fixed-wing with advanced power system and/or IC engine, PPM example

== R/C Receivers ==

One can use [[Subsystem/radio_control#Spektrum|Spektrum]] DSM2 or compatible receivers as well as traditional PPM receivers. It is even possible to [[Subsystem/radio_control#Spektrum|connect two Spectrum or compatible satellite receivers]] for better redundancy or to improve RC signal reception. Connecting a RC receiver for flying your aircraft in manual mode during setup and test phase is 99% of the cases a must. Therefore the Paparazzi team made it easy to connect one.

=== Using a Spektrum DSM receiver ===

==== Physically connecting ====

Wiring up a Spektrum or compatible satellite receiver is not all to difficult to do. Note however that it is very important to make absolutely sure the connectors are properly made. Not being precise in this step can mean full RC loss and loss of airframe in the first tuning testflights.

A spektrum satellite receiver should be connected to the UART1 connector on the autopilot board. Make sure the voltage on the AP board UART1 + pin is not to high, or to low for your receiver.

Steps:
# Connect the minus(-) of the receiver to GND of UART1
# The receiver plus(+) to the UART1 Plus(+)
# Data out signal of the receiver to the RX pin on the UART1

==== Binding ====

To get a receiver and transmitter to work together you must perform a binding process.

It is important to '''bind''' your Spectrum DSM receiver to your transmitter '''via''' your '''Lisa board''', not in any other way!

The way to bind is by temporary connecting via fiddly small molex pins.
It is advised to make a small bind plug out of a molex connector for this purpose.
Before you start make sure you have your airframe configuration already uploaded either via USB or a JTAG cable.

The bind procedure:

# On the connector '''ANALOG1''' have a wire between the GND and ADC1 pin, located in the middle of the board
# Power up your autopilot board
# Hold the bind button on your '''transmitter''', while '''keeping it pressed''' switch on your transmitter
#:Wait...! All lights of the receiver blink and then go steady
# Let go of your transmitter bind button
# Power off your Lisa Board
# Remove the wire connecting the GND and ADC1 pins on the ANALOG1 connector
# Repower your board, if you have servos connected and wiggle the RC transmitter sticks some servos should move

That is all, you are done.
The bind procedure only needs to be done '''once''' for your receiver.

=== Using a CPPM receiver ===

Using a CPPM receiver, a so called '''PPM sum stream''' input is possible. [[RC_Receivers_and_Radios#PPM_Based_Systems | To make it work, you need a CPPM a.k.a. PPM sum, stream out capable receiver. Find out more following this link]]

==== Connecting ====

Connect the CPPM out signal to the RX pin of UART1.

Make sure put this in your airframe file in your AP target section.
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
<subsystem name="radio_control" type="ppm">
<configure name="RADIO_CONTROL_PPM_PIN" value="UART1_RX"/>
</subsystem>
...
</firmware>
</source>

===== Alternative =====

However if in the case you want to use the UART1 port for something else, there is an option to connect the receiver to a servo pin. Yes, that's right, a servo connector is used for receiving a CPPM stream '''input'''. If you want to walk that path, the default pin number to capture the CPPM datastream is via servo connector SERVO6

If you connect the CPPM out capable receiver that way make sure to put this in your airframe file in your AP target section:

<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
<subsystem name="radio_control" type="ppm">
<configure name="RADIO_CONTROL_PPM_PIN" value="SERVO6"/>
</subsystem>
...
</firmware>
</source>

If you do not have or cannot modify a receiver to a ''CPPM out'' able receiver, a [[PPM_Encoder | PPM encoder board]] can be used to avoid opening your receiver for PPM out modification. However with the very low prices of Spectrum DSMX CPPM out, lat time we looked you could have one starting from EUR 10,-

===Using a S-Bus receiver===

There is a third option, connect a receiver with S-Bus signal output. For this with regular Futaba receiver an inverter my be needed.

== Extras ==

=== UART I/O ===

UART pins can also be used as general purpose I/O, this might come in handy in case all other inputs or your AP board are in use.

=== USB as UART1TX + hardware flow control===

[[File:Lisam-usb-uart1.jpg]]

The USB_VBUS on the Lisa/M 2.0 can be used as UART1 TX. To do this, a diode has to be removed. Make sure to include a series resistor of 100-3000 Ohm to protect the microcontroller from overcurrents. The 2nd and 3th pin of the USB pads are CTS and RTS respectively. It is recommended to include a series resistor in the RTS line, as this is an outgoing line.

If you want to enable flow control in the software, but don't want to use flow control when no cable is connected to the CTS/RTS, a pulldown resistor of 10 kOhm has to be added between the CTS and the GND. If you do this, take care when connecting UART devices that have a large series resistor in their RTS line. The combination of the pulldown resistor and the series resistor might cause the high-level voltage to drop under the high-level threshold of the microcontroller, causing strange behaviour.

For Example the RTS , mostly a purple wire, is the '''pin 10''' on the Xtend module when set in the module with Hardware flow control (use X-CTU)
CTS, most blue, on pin 9 of the Xtend

<gallery widths=380px heights=205px>
Image:Lisam-diode.JPG | Remove this diode. After removing this diode you can not power the board via USB anymore.
Image:Lisam-gpio-usb.JPG | Take care of the small distance between the GPIO pins and the USB pads.
</gallery>

== PCB ==

=== Gerber & Drill Files ===

'''''Download Lisa/M v2.0 gerber & drill files (zip)''''' ''[[Lisa/M_v2.0#Get the design|Get the design]]''

== Assembly ==

To create and assemble a board oneself is possible. It takes some skills however.

For the Lisa/m v2.0 without the Aspirin sensor board a good soldering iron is enough.(smallest components are 0402) For the Aspirin Sensor board you need a hot air soldering station.

In case you wan to follow that path you need the design. You came to the right place here is the info to get the needed files;

===Components Layout===

''[[Lisa/M_v2.0#Get the design|Get the design]]''

Need some top and bottom of board images and line drawings here.

=== Bill Of Material ===

'''''Download Lisa/M v2.0 Bill Of Material (zipped .xls file)''''' ''[[Lisa/M_v2.0#Get the design|Get the design]]''

Open .sch File in Eagle, execute UPL --> bom.ulp , save as .txt

== PCB and assembled boards suppliers ==

To difficult to create your own AP board, understandable, thus pre made board available via [[Get_Hardware|Get Hardware]] page... hopefully :)

== Mechanical Dimensions ==

[[Image:LisaM_V2_0_top_mechanical.png|500px|Lisa/M v2.0 Mechanical Dimensions]]

The overall height of the board including the servo connectors is 10mm. Note that the overall length includes the USB connector. The mounting holes are nominal 2mm diameter (with a bit of clearance).
Beware that in version 2.1 of the Lisa/MX the mounting holes are for m3 screws.

== Get the design ==

'''Source files'''
:*download available on GitHub: ''[https://github.com/paparazzi/paparazzi-hardware/tree/master/controller/lisa_m/v2.0 Lisa/M v2.0 Cadsoft Eagle 6 Design]''
'''Gerber & Drill files'''
:*download ''NOT YET AVAILABLE'' Need generated gerbers and drill files
'''Assembly files'''
:*download ''NOT YET AVAILABLE'' Need Lisa/M v2.0 Components layouts (pdf)
:*download ''NOT YET AVAILABLE'' Need Lisa/M v2.0 Bill Of Material

== Uploading new software ==
New onboard software for the Lisa/M v2.0 can uploaded by connecting your PC via a micro-USB port to the autopilot board. For this the board need to contain the [[Luftboot]] bootloader. All Lisa/M 2.0 from Transition Robotics Inc. come with luftboot already in the board.

An alternative to get your firmware in the board is by using a JTAG connector connected via the 10-pin Samtec connector that is available on the board.

See the [[FirmwareFlashing]] page for an overview of different methods to upload new software to your autopilot.

=== Using luftboot ===
'''This is the default FLASH_MODE for Lisa/M v2.0''', it could be explicitly selected by adding
:<source lang="xml"><configure name="FLASH_MODE" value="DFU"/></source>
to the firmware section of your airframe file. Make sure to set Lisa/M 2.0 as it's target board.

Once USB is plugged in, the board automatically goes to bootloader mode and the status LEDs cycle up and down:

[[File:Luftboot.gif|320px]]

If you have trouble entering the bootloader mode or want to upload/update the bootloader itself, see the [[Luftboot]] page.

=== Using JTAG ===
You still can use a [[JTAG|JTAG adapter]] for [[FirmwareFlashing#JTAG|flashing]] and [[DevGuide/JTAG-Debug|debugging]] your paparazzi firmware. To use [[FirmwareFlashing#JTAG|JTAG flashing]] configure the ''FLASH_MODE'' in your firmware section:
:<source lang="xml"><configure name="FLASH_MODE" value="JTAG"/></source>

It is possible to use an advanced adapter called Black Magic Probe. See more details [[here|JTAG#Black_Magic_Probe]]

Using JTAG will not overwrite the bootloader by default. To overwrite the luftboot bootloader configure
:<source lang="xml"><configure name="NO_LUFTBOOT" value="1"/></source>

Then press upload as normal...

=== Serial Firmware Upload ===
Firmware upload using the factory integrated bootloader can be useful e.g. if you have overwritten [[Luftboot]] accidentally and don´t have access to [[JTAG]].<br/>
Either set the flash mode in the target section of the airframe configuration:
:<source lang="xml"><configure name="FLASH_MODE" value="SERIAL"/></source>
or add it to the commandline invocation:
make AIRCRAFT=<aircraftname> ap.upload FLASH_MODE=SERIAL

Due to hardware constraints, the board has to be modified to make use of the bootloader, which is only accessible on UART1:
# Diode D3 has to be removed (the bigger black brick next to the USB connector). Attention, no more powering via USB after that.
# BOOT1 has to be set to GND by connecting ACC_DRDY(unused) to GND at the Aspirin pads

Now a boot sequence works as follows:
#BOOT1 has to be set to 3.3V by use of a jumper cable
#Connect a 3,3V serial cable (FTDI, MAX232...) to UART1, the TX pin is USB_VBUS
#Power the board and activate the bootloader program

=== Prevent board from going into bootloader mode ===

Normally, if you power up the board with the USB cable connected to a PC it will automatically go into bootloader mode. If you want the board to power up normally with the cable connected you can ground the ADC2 in the ANALOG1 connector.

== Detailed Hardware Revision History ==

=== Changes Between LISA v1.1 and v2.0 ===

* Lots of silkscreen improvements
* Added attributes to all parts to make the usage of bom-ex ulp possible.
* Improved routing to allow teardropping
* Fixed stm32f1, f2 and f4 compatibility circuit. (has to jump to ground not to 3v3)
* Connected existing UART RX pullups to the respective connector power pins instead of 3v3. To prevent connecting 5V over IO pin to the 3v3 power rail.
* Added pullups on all UART RX lines to prevent undesired floatation.
* LED's are connected to 3v3 now. To make sure we don't have an issue with voltage tolerance on the gpio pins.
* ...

== Hardware Change Requests ==

If you have a Lisa/M 2.0 and in the process of using it you come up with something you find annoying, dangerous, or restricting, add your hardware update requests here. Better still, modify the Lisa schematics yourself and show your new improvements if you are skilled enough to do this.

* REQ: Replace BMP085 with MS5611 (the MS5611 seems to be better in performance then the BMP but it is more expensive and seems to be more difficult to obtain.
** A: Using a MS5611 is possible through using a Aspirin v2.1 board

* REQ: Replace 7 Pin CAN with molex with something less risky to be inserted in 7 Pin SPI in relation to powering the board via CAN molex.

* REQ: Separate spot for external power if powered via separate battery. Realizing we can via Servo ports by Bridge J1 but still like to measure board voltage then and have a way to add power without mistakenly insert I2CCAN Molex conector into SPI Molex on board connector. Thus a separate CAN and Power plug. Power on regular four pin molex with GND, V+5, , V_BATT, V_I (Current sense). Option to have thicker wire to be soldered to the board, for power hungry setups and other issues connectors for power are not a good idea.

* REQ: Replace Aspirin IMU board with InvenSense MPU-9150 and bring the MS5611 back onto the Lisa/M board to reduce footprint, mass, and manufacturing cost once the 9150 becomes readily available(if at al with SPI) and is tested to perform well.

== Lisa/Lia F4 ==
Lisa/Lia autopilot can be easily converted to a much more powerful controller, based on STM32F405RGT6 chip [http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1577/LN1035/PF252144]. The chip has the same dimensions (LQFP64 10x10mm package) with the exact same pinout as the original STM32F105RCT6 chip. The main advantage of the f4 chip is:

* 168MHz CPU speed, 1MB flash and 192kb RAM
* FPU (fast floating point computations)
* configurable DMA streams (more peripherals can use DMA)
* multiplexed IO pins (peripherals can be mapped to various IO pins)
* CPU usage only about 5% with standard rotorcraft flight configuration

STM32F405RGT6 chip can be ordered for example [http://cz.mouser.com/ProductDetail/STMicroelectronics/STM32F405RGT6/?qs=Z8%252beY1k3TIKgj7QWsYGpQw== here]. To replace the chip a good soldering station with microscope and enough light is recommended. After replacing the chip, jumpers CMP1 and CMP2 have to be opened.
<gallery widths=300px heights=200px>
[[File:F4_digikey.jpg]]
Image:F4_digikey.jpg|DigiKey part number for F4 chip
Image:F4_on_board.jpg|Lia F4 with the new chip
</gallery>

=== Programming ===
The STM32F4 can be flashed via SWD/JTAG (e.g. with the BlackMagicProbe) or via [[DFU#Native_DFU_bootloader_.28embedded_in_ROM.29|DFU-UTIL]].
[[Luftboot|Luftboot]] currently supports only F1xx chips.

'''To program via DFU-UTIL:'''

[[File:LisaMX v2_0_DFU.jpg|500px]]

[[DFU#Native_DFU_bootloader_.28embedded_in_ROM.29|First, install DFU-UTIL as shown here.]]<br>
The two pairs of pins circled in red should be shorted (VERY CAREFULLY), eg with tweezers, as shown, i.e.:<br>
1) The Boot0 and VDD pins on the STM32F4 should be shorted together.<br>
2) The ACC_DRDY (Boot1) and GND pins should be shorted together on the Aspirin mounting pads. (This can be done even if an aspirin IMU is mounted).<br>
The USB connector should then be plugged in. This action also powers the board. Do not connect any additional source of power.<br>
Remove the shorts. The board should now be in bootloader mode. Only one green LED should be lit.<br>
The board can then be flashed using DFU-UTIL.<br>
Tested functional on a [http://transition-robotics.com/products/lisa-m-f4-with-10dom-aspirin-imu TRI Lisa/MX v2.0] using Paparazzi Master branch on 18 Nov 2014.<br><br>

'''A guide how to flash the F4 chip from Eclipse can be found in [[RT_Paparazzi|RT_Paparazzi]].'''

[[Category:Lisa]] [[Category:User_Documentation]] [[Category:Autopilots]]

Tuning

2015-08-13T18:27:25Z

IHaveADrone: typo

== Intro ==

This page provides guidelines for tuning a new aircraft and additional practical tips. Be sure to familiarize yourself with the theory of [[Theory_of_Operation#PID|PID Controllers]] before you begin tuning your airframe. Use of the [[RTPlotter|real time plotter]] may help to visualize and understand the behavior of the control loops. Review [http://paparazzi.enac.fr/w/images/Users_manual.pdf User Manual] as well. Also reading [http://www.av8n.com/how/ See How It Flies, by John S. Denker] is very beneficial to get your airframe tuned well.

==Energy Control==

If you came to this page and want to learn about how to perform your [[Tuning_energy_control_loops | Energy control tuning]], this is '''not''' the page to read, go to [[Tuning_energy_control_loops | tuning energy control loops]].

==Quickstart==

'''Here is the sub-minimal ultra-quick-start guide: note that point 1 and 3 should ALWAYS be performed every time you reflash your plane!!!'''

# Before take-off [[Tuning#Directions|check]] (beware: do not skip a test as it is not because 2 are good that the third will also be good)
## RC-left is aileron-left and up is up in [[AutopilotModes|MANUAL]].
## RC-left is aileron-left and up is up in [[AutopilotModes|AUTO1]].
## [[Tuning#Directions|turning the plane-left is aileron-right]] and nose-up is elevator-down with RC in neutral in [[AutopilotModes|AUTO1]]. (to check the [[GCS#PFD|Artificial horizon]] in the [[GCS|GCS]]: use the words: right wing sees the ground to not mess up left and right if uncertain.)
# Fly manual
## [[Tuning#Neutrals|trim your plane]]
## check [[Fixedwing_Configuration#Servos|servo deflections]] are good (sufficient but not aerobatic)
## remember the cruise throttle. (and max/min throttle if you will use aggressive-climb)
# On the ground, after trimming:
## Check with plane flat/cruise attitude on the ground that the ailerons/elevator do not move when you switch from MANUAL to AUTO1. This checks your IMU/Thermopiles are properly aligned and that [[Tuning#Trim|your trim values are in the airframe file and not the RC-transmitter]]
# Test [[Tuning#Auto_1|try AUTO1]]
## When entering AUTO1, make sure you try to turn before your plane is too far away since [[Fixedwing_Configuration#Auto1|AUTO1 circles are usually much larger than manual circles]].
## Make a [[RTPlotter|graph]] on the groundstation of DESIRED->phi/theta and ATTITUDE-phi/theta to see if they match.
## When flying with IMU pay special attention here if after several left turns the plane still turns right too. Plot the IMU_ACC->ax,ay,az to see the average vibration in your plane. If the vibration level is lower than half of gravity (5m/s2) than usually you are OK. If it is much more, you should dampen your IMU more. (in foam, or mounted on your heavy battery, ...)
# Only when AUTO1 works fine you can [[Tuning#Auto_1|go to AUTO2]]
## check that your throttle is not killed (RED) in the groundstation
## check that your cruise throttle is correct if you have a powerful motor
## if tuning the altitude loop seems difficult try the [[Tuning#Sample.2FSimple_Altitude_and_Throttle_Loop|simple 3 gain auto_throttle_loop]]

== Sensors ==

=== IMU / Sensors ===
You may want to look at the [[ImuCalibration]]. <br/>
While some Sensors can be operated with factory calibration (MPU6050 or 6000) other, for example Magnetometers require a calibration to the earth magnetic field and UAV radiated magnetic field to work satisfactory.

=== Directions ===
* Reverse any servos and make sure no mechanical binding occurs at the limits of travel in Manual mode.
* Take the plane outside and engage AUTO1. Bank and pitch the plane and verify that the controls respond in the correct direction AND that the PFD in the notebook responds correctly. Note that your body will have a tremendous impact on the measured angles if using IR sensors. If using an IMU, there is no need to be outside. See note.
* Verify that AUTO1 stick movements respond in the correct direction - important! See note.
* Move the plane rapidly to ensure the gyro response resists motion - increase the gain if needed for better visualization.
NOTE: If the PFD responds in the wrong direction to the motion, you should adjust parameters in the INFRARED or IMU parts of the airframe file. If the control surfaces respond in the wrong direction to counteract motion (stabilize the aircraft, bring it back to neutral), reverse the servos in the airframe file. If the manual input from R/C causes the control surfaces to respond in the wrong direction (want them to force motion, not counteract motion), then you must reverse the channel on the R/C transmitter. Be sure to recheck surface neutrals and endpoints after doing such modifications. Also double check the gain signs, make sure none are positive that should be negative.

== R/C, Modem, and GPS ==
* Make sure the GPS signal is strong (outdoors) - you should have a 3-D fix in less than 1 minute and at least some satellite signals above 40dB. The plane should not drift on the map by more than 10 meters.
* Perform a range test of R/C and modem signals.
* Ensure that two way communications are in place. Check that the motor starts up when launch is commanded or move a waypoint and check that it's updated in the autopilot.

== Trim ==
<b>Important: You must never keep any trim, mixers, or rates in your R/C transmitter.</b> R/C trim can be applied in flight but must be corrected and removed on the ground before attempting autonomous flight. Exponential can be useful and will not adversely affect AUTO1 flight but if "low rates" are needed they should be programmed on the same transmitter switch with AUTO1 so that you always have full travel in AUTO1.
* Fly the plane at what you feel is a suitable "cruise" throttle setting and set the trims. Note that setting in the GCS and try to return to that exact setting in subsequent tests. Enter that throttle setting in your airframe file.
* Check maximum pitch and roll response and adjust the mixer parameters or mechanical linkages after landing.
* Land and adjust the linkages. If necessary, the PPM values can be read from the GCS and servo neutrals adjusted electronically, but manual adjustment will produce far better results.
* Fly again to verify trim and control response. If satisfactory, check for any significant throttle-dependent roll. Again, this is best to correct mechanically but can be addressed with the ''AILERON_OF_THROTTLE'' mixer in the autopilot. Check also for any odd behavior at full throttle.
* Make sure that GPS and modem data is reliable during these test flights. Note particularly any tendency for the aircraft to appear to fly sideways on the map - this is an indication of weak GPS signals.

== Auto 1 ==
* Engage Auto1 and ''immediately'' make sure you can turn both left and right!
* Fly at your "cruise" throttle and adjust the ''ROLL_PGAIN'' until the plane doesn't quite oscillate
* Adjust the IR roll neutral as needed
* Verify adequate pitch response and adjust PITCH_PGAIN as needed
* Experiment with different throttle settings and tune P and D gains as needed

If you are alone in the field while tuning, setting values via your RC transmitter may come in handy, see [[Telemetry#R.2FC_Transmitter_Data_Uplink|RC receiver data uplink]]

== Auto 2 ==
* Engage [[AutopilotModes|AUTO2]] and you're done! Make sure you keep a finger on the Mode switch to take over just in case.

==Alternate Tuning Procedure==
Danstah wrote up a tuning procedure on this website http://www.engr.usu.edu/wiki/index.php/OSAMtuning

==Sample/Simple Altitude and Throttle Loop==

The dash button changes the NOMINAL_CRUISE_THROTTLE to the MAX_CRUISE_THROTTLE while the loiter button changes it to MIN_CRUISE_THROTTLE.

This makes it easy to suddenly make the UAV fly a bit slower or a bit faster. However, when changing the throttle, you also need to change the elevator trim in order not to climb/descend too much. This it what AUTO_THROTTLE_LOITER_TRIM and AUTO_THROTTLE_DASH_TRIM are for. (I think the unit is MAX_PPRZ = 9600 = full deflection?)

The auto-throttle loop is actually the most difficult loop to tune as it has both the speed and altitude that are correlated. Controlling both speed and altitude with high performance is very hard. It is way easier to control 1 entity (e.g. altitude) with higher performance and let the speed change a bit, or have an airspeed controller but then do the altitude slowly...

Sample altitude controller:
---------------------

Step1: outerloop: if altitude is not good -> compute a climb/descend rate. (including ALTITUDE_MAX_CLIMB)

climb_command = altitude_error x alt_pgain

e.g. 10 m too low x 0.1 alt gain = climb_command at 1 m/s
e.g. 50 m too low x 0.1 alt gain = climb at 5 m/s > ALTITUDE_MAX_CLIMB(2) -> climb_command = 2m/s

---------------------

Step2: innerloop: [many many options here, but since you ask for simple I'll only give one robust and simple:]

too low -> pitch up and extra throttle (if you only apply throttle, airspeed will increase and might even start to dive with full throttle if the nose is a bit heavy, if you only apply pitch airspeed will decrease and could lead to stall, with proper tuning you can get a pretty constant speed even while climbing and descending)

pitch_command = climb_command x pitch_of_vz
throttle_command = nominal_cruise_trim_throttle + climb_command x throttle_climb_increment

e.g. climb_command at 1 m/s x pitch_of_vz 0.15 = 0.15 radians pitch = 9 degrees pitch up

e.g. climb_command at 1 m/s x throttle_climb_increment 0.25 with nominal_cruise_trim_throttle 0.5 = 75% throttle

-------------------

If you use AGRESSIVE_CLIMB then if the altitude error is larger than the chosen threshold a precomputed pitch and throttle will be applied.

AUTO_PITCH is for constant throttle and control height with elevator only

auto_throttle_p/i/d_gains are to regulate the climb rate more precisely

==Other Misc things before flying==

It's very important to address the issue of low voltage cut-off before flying (LVC).
There's a good chance that the LVC will kick in on the brushless ESC before the Paparazzi detects it.
If this happens, the ESC cut's off throttle, and there's no way the autopilot knows this, the plane keeps loosing altitude,
the autopilot tries to increase throttle, but the ESC does not respond, almost always leading to a mishap.
To avoid this, either turn off the LVC on the ESC, OR, make sure the autopilot kills throttle first,
by programming the CATASTROPHIC_BAT_LEVEL to something higher than the ESC LVC.
For example, set CATASTROPHIC_BAT_LEVEL to 9.5V, and the ESC LVC at 9V.
Don't ask how we know, it was a safe landing into a small tree :) No damage. BUT you cant get lucky always!

Have a look at the [[Failsafe|failsafe]] and [[Airframe_Configuration#Battery|battery configuration]] for more details.

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

FAQ

2015-08-13T18:13:18Z

IHaveADrone: come on guys, at least get the spelling of the project name right (misc. typos)

__TOC__

==Is it possible to do XYZ?==
:Yes, sure! The beauty Paparazzi is that it is fully opensource'ed - '''Any''' feature or function you want '''can be added''' to the software and even the hardware.

==How can I contribute?==
:See the [[Contributing| how to contribute]] wiki page.

==How do I check which Paparazzi Version I'm using==
: Run ./paparazzi_version from you paparazzi directory.
: This simple script will run ''git describe'' to find the next reachable tag and print something like ''v5.1.1_testing-43-ge060371''.
: The output contains the most recent reachable tag, number of commits since then, SHA1 of that commit and whether the working directory was dirty.
: If you have an older version of Paparazzi that does not contain that script you can just run <tt>git describe --match "v[0-9].[0-9]*" --dirty --always --long</tt>

==What equipment and components are suggested==
# Linux (Debian or Ubuntu) compatible or Apple Macintosh notebook computer, preferably with a very bright screen for outdoor use.
# Most any airframe that will accommodate a Paparazzi Autopilot and some extra weight and wiring - ''brushless motors are strongly suggested.'' See the [[Gallery|User's Gallery]] for some airframe examples.
# One of the [[Autopilots]] from one of the [[Get_Hardware|Paparazzi vendors]] or build your own from the downloadable plans/gerbers
# If it is not already included with the AP a external [[IMU]]
# A 2.4 GHz R/C Transmitter and Receiver with a 3-position switch and PPM output for selecting Manual/Stabilized/Auto.
# A pair of [[Modems]] along with any enclosures and antennas
# A [[Serial_Adapter|USB <-> UART]] adapter for connecting the modem to your USB port and/or for serial flashing of bootloader code or tunnel access to the GPS receiver
# A standard Mini-B and Micro-B USB cable
# Lots of [[Other_Hardware#Wiring|very durable wire, crimpers, and molex pins or pre-crimped wire.]]

==Are internal combustion engines supported?==
:Yes, not relying solely on inertial measurement, the Paparazzi system is very well suited for aircraft with high vibration levels. Care must be taken to prevent oily exhaust residue buildup on the IR sensors and a simple variable must be added to properly address the special idle/kill needs of an IC engine.

==Can Paparazzi fly a glider?==
:Sure. Paparazzi uses throttle and pitch to control climb rate by default. You can fit an airspeed sensor and adjust your airframe configuration to maintain airspeed instead.

==Will the autopilot provide enough 5V power for many/large/digital servos as well as a modem, video TX, etc.?==
:Depends on the Autopilot, compare the maximum output of the AP and the needed power
:The [[Tiny]] includes a high capacity and high efficiency switching voltage regulator intended to power servos, modems, video systems and other payloads. This regulator should be preferred to power the servos rather than a linear regulator. While linear regulators may be rated for several amps, they require a great deal of cooling and can easily overheat with only a few hundred milliamps of continuous current without cooling. By comparison, the switching regulator included on the Tiny can work continuously at 2A with little or no cooling. Be careful using high power or digital servos consuming a lot of current. If you use four or more of them on your airframe it is recommended to supply them separately. It is important to realize that the servos in any stabilized aircraft will operate continuously. Therefore a power supply that powers the servos reliably in manual flight may easily overheat or produce critical voltage drops in autonomous flight.

==Do I need a separate battery or regulator to isolate the autopilot, servos, video, modem, etc. from one another?==
:The autopilot processor and sensors are powered by a 3.3V regulator and therefore are rather isolated from voltage fluctuations on the battery or 5V bus.

==Can I use a Sirf, Trimble, etc. instead of the u-Blox GPS receiver?==
:Yes, but it would require a tremendous amount of work as some of the navigation code is dependent on some of the UBX messages. NMEA does not provide messages in the desired form and substantial calculation would be required for conversion. Any of the other proprietary protocols would work but you would need to write your own protocol handler. u-Blox (Hobbyking's costs <14€) offers great performance, size, and speed as well as the ability to easily configure the internal Kalman filter parameters to expect significant acceleration in 3-D space - a very important feature.

==Does Paparazzi use DGPS, WAAS, EGNOS, or MSAS?==
:Most modern GPS receivers have the ability to process serial data sent from an external DGPS receiver, but the advent of WAAS/EGNOS has made the early ground-based DGPS transmitters nearly obsolete. The u-Blox GPS receiver supports all common SBAS systems (WAAS, EGNOS, and MSAS), as well as any standard form of external DGPS. It's important to understand that DGPS merely improves the ''accuracy'' of the position estimate by subtracting any static error. The only way to improve the ''precision'' of the GPS is by improving the antenna or the GPS module itself. See [http://en.wikipedia.org/wiki/Accuracy_and_precision Wikipedia:Accuracy and Precsion] for a detailed explanation of these terms.

==How does the R/C receiver interface with the autopilot?==
:Standard hobby R/C transmitters multiplex up to 9 channels of PWM servo data into a single PPM signal which is encoded onto an FM wave for transmission, this signal is then decoded by the RF section of the R/C receiver back into the original PPM signal containing 9 servo position PWM values. This signal is normally then sent to a demultiplexer (i.e. 4017) where it is separated into 9 individual servo signals on 9 individual pins. The Paparazzi autopilot intercepts the signal between the RF section and the demultiplexer and does its own demultiplexing, filtering, and processing before multiplexing the manual or autonomous servo commands back into a single signal and passing them to the 4017 to be distributed to the servos.

==Why does Paparazzi tap directly into the R/C receiver instead of using individual servo signals?==
:By connecting directly to the RF section of the R/C receiver we are able to obtain up to 9 channels of R/C servo data from a small, lightweight inexpensive 4 channel receiver with only 3 wires needed to connect the components. Furthermore, the autopilot then has direct access to the raw R/C signal where it can be filtered, evaluated, and assessed for quality. The autopilot can then alert the user of any loss of R/C signal as well as perform any pre-configured autonomous commands in response to a loss of signal.

==Are PCM or 2.4GHz R/C systems compatible with Paparazzi?==
:Yes. Most good 2.4Ghz receivers can directly output a PPM signal on one servo pin. A general rule of thumb is that if you see any type of demultiplexer on your R/C receiver, you can look up the data sheet for it and likely tap into the input pin with success. Some information on compatible R/C receivers and how to find the PPM signal of your own receiver is given in the [[Other_Hardware#R.2FC_Receiver|RC receiver]] section.

:If that's not possible, you can use the available PPM encoder board, to re-multiplex the servo channels into one PPM signal. This seems to be a common solution.

==What R/C transmitters are compatible?==
:No mixing or programming is done in the transmitter so even the simplest models will suffice but one important requirement is a 3-position switch to select among the three autopilot modes: manual, stabilized only, and fully autonomous. Those handy with electronics can replace a dial with a switch and resistor if needed. The transmitter's PPM values need to be recorded and the channel used to control the autopilot mode must be stated. Some commonly used transmitter configuration files are provided in the [http://cvs.savannah.gnu.org/viewvc/paparazzi/paparazzi3/conf/radios/ conf/radios] folder and the syntax of these files is easy to follow for those using other brands or models.

==Can a gamepad/joystick be used to control the aircraft through the modem?==
:Yes, the code to do this was written some time ago though it was not tested in flight due to latency concerns with the primitive [[Modems#Coronis_WaveCard|Coronis]] modems used at the time. Any of the [[modems]] currently recommended should work well in this manner but the theoretical reliability is still questionable due to the fact that no interrupt or prioritization structure exists for the telemetry data so any manual control inputs would be lumped in with the rest of the data to be lost or delayed as needed.

==What do MANUAL/AUTO1/AUTO2 stand for?==

:Those are the three modes that Paparazzi can operate in. Confer to [[AutopilotModes]] for more information.

==What Electronic Speed Controllers (ESC) are compatible?==
:Any controller can be used, the exact PWM value that is sent to the controller for 0-100% throttle is completely configurable in the airframe file so all controllers are compatible and any controller will arm properly with or without the use of an R/C transmitter. Upon each boot, the autopilot immediately sends whatever you have defined as 0% throttle (typically around 1200μs) and maintains that signal until a manual or autonomous command is given. Most modern controllers are "auto calibrating" which is an undesirable feature for R/C pilots and even more so for autonomous systems but can be dealt with. The calibration is done by defining the PWM value at boot to be 0% power and then defining some initial arbitrary mid-range value such as 1500μs to be 100% until a higher value is seen. The net result of this behavior is that the motor is given full power at any command above 50% throttle until 100% throttle has actually been commanded at least once. This is not an issue for planes that routinely take off at 100% throttle but can disrupt the throttle tuning and altitude control on any flights where 100% throttle has never been commanded. [http://www.castlecreations.com/products/products_fly.html Castle Creations Electronic Speed Controllers] can be configured for "fixed endpoints" so the ESC does not need to "learn" the endpoints at first takeoff this providing a consistent and predictable throttle response. By default this range 1250-1850μs but can be set at different values where needed.

: For quadrocopters a ESc with a very low latency is highly recommended. That can be a cheap standard ESC with a upgraded firmware (which uses I2C as input) or a high quality esc (mocrocopter ESC)

==Can traditional throttle stick programming be done on the ESC once connected to the autopilot?==
:Yes. If the transmitter is on with the throttle at full or whatever is required for your ESC when the autopilot is first booted, the autopilot will immediately see the manual control signal and the throttle position and pass that along to the ESC as the first value, triggering the programming mode.

==Does Paparazzi support digital servos?==
:Of course. Digital servos use exactly the same electrical interface as their analog counterparts, the only difference being in the way they control the motor. Analog servos use a '''P'''roportional feedback loop, meaning the voltage sent to the motor is proportional to the difference between the measured and intended position of the arm. Digital servos use a '''P'''roportional + '''D'''erivative ('''PD''') feedback loop. The derivative term considers the current speed and direction of the servo as well as the speed and direction of the pilot's stick command. The derivative term will increase power to the motor if the servo is moving the wrong direction (providing faster direction changes) and will reduce/reverse power if the servo is near it's desired position but moving too fast (reducing overshoot). The net effect of this is that a digital servo can use a much stronger '''P''' term without risk of oscillation and overshoot because the '''D''' term is there to intelligently dampen it as needed and boost it whenever it can.
:How does the inclusion of a '''D''' term make an analog servo become digital? Analog servos use a simple opamp to linearly relate the motor voltage to the difference between the potentiometer reading and PWM signal, whereas digital servos use a microprocessor to analyze the potentiometer position and velocity as well as the current and recent PWM signals to calculate the optimum voltage to send to the motor.
:'''Important:''' Please be aware that autonomous flight involves ''continuous'' movement of all servos. Make sure your power supply is capable of handling this and that your servos are capable of continuous operation without overheating - especially if you use digital servos.

==Can I solder wires directly to the autopilot instead of using the molex connectors?==
:Sure, only for some board it is easier to do than for others. Tiny: All of the molex headers are thru-hole and you can easily solder small gauge wire directly to the pins that protrude from these headers on the back of the board. It's important to note that '''standard servo wire cannot be soldered reliably''' in this fashion - you must use only high-grade wire intended for soldering (no vinyl insulation!). Direct soldering is not recommended, but it is possible ofcourse. See the [[Other_Hardware#Wiring|Wiring]] section for suggested wire types and sources. If you want to go the direct soldering path, be sure to you have '''excellent soldering skills''' and use high quality wiring.

==What are the paparazzi failsafe features and how do I configure them?==
The basic autopilot already has several built-in failsafe features ranging from lowlevel to highlevel and from implied to optional. For more details take a look on the [[Failsafe]] page.

==Why do I only get a blank (black) GCS==
:The GCS stays blank until you get telemetry messages (either from the real aircraft or simulated) with the correct MD5 checksum meaning the autopilot has the correct and up to date flightplan/airframe/... programmed in it (in case of an MD5 problem you constantly get a lot of warnings in paparazzi center).
:'''Solution''': Probably your telemetry is not set up correctly, this is most likely a [[XBee configuration]] issue.[[Subsystem/telemetry#Configure_Options|Configure the baudrate for your XBee connected to the autopilot]] and [[Subsystem/telemetry#Set_GCS_baud_rate|set the baudrate for the link to the one the ground XBee uses]] (They don't need to be the same). Also make sure your xbee cable is correct, transmit (tx) of xbee goes to receive (rx) on the autopilot and vice versa.

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

==How do I check if my telemetry is working?==
:'''Solution''': Launch the link and messages tools in the Paparazzi Center. You should see the the messages coming in (blinking green) in the messages window.
: If you get an the error ''Failure("Error opening modem serial device : fd < 0 (/dev/ttyUSB0)")'' from ''link'', your modem is either not connected at all, or just available under a different device name. Check if you set the [[Installation#Setting_access_rights_for_USB_download|udev rules]] and if your modem becomes available under the device you set.
: You might need to adjust the device and baud-rate of the link according to your setup, e.g. <tt>link -d /dev/ttyUSB0 -s 57600</tt>
: If you're stuck you can make ''link'' very verbose by setting the ''PPRZ_DEBUG'' environment variable to '' '*' ''

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

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

:'''Solution''': Make sure your GPS is [[GPS#GPS_configuration_using_U-Center|configured]] correctly and change the gps type to "<tt>ublox</tt>" if applicable.

==Why do I get a CRITICAL **: murrine_style_draw_box: assertion `width >= -1' failed error message on starting the GCS==
:'''Solution''': This error is not critical at all and can be safely ignored.
It is triggered by a bug in the Murrine GTK engine in combination with the default theme which Ubuntu uses, as detailed here:
https://bugs.launchpad.net/ubuntu/+source/light-themes/+bug/538499

==Do Paparazzi autopilots support onboard datalogging with an uSD or SD card?==
:Currently, writing to an SD card takes a considerable amount of processor resources, enough to significantly impact critical timings and autopilot performance. For this reason, no onboard datalogging is supported on current autopilots. If logging is needed on the aircraft (say for use without a datalink) then a second board that "sniffs" the datalink telemetry is needed. Support for this is available in Paparazzi. For information, see [[Data Logger]].

==Telemetry not working==
:If you are receiving the error "Failure("Error opening modem serial device : fd < 0 (/dev/ttyUSB0)")"
:'''Solution''': You might need to add your user to the modems group (dialout), then log out and in again.
:write in terminal:$ sudo adduser <user> dialout
:it will be effective after your next login or simply write:
:$newgrp dialout

[[Category:User_Documentation]]

Reference/bootloader

2015-07-14T20:02:18Z

IHaveADrone: typos

{| align=right
|-
|<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Firmware Flashing</categorytree>
|}

==Adding a bootloader==

[[Lpc21BootloaderUpload|If you just want to know how to add a bootloader to the LPC]]

==Hardware boot sector==

Each board can be programmed with a serial number and additional board
information (board type, board version, hw options like the type of GPS
receiver used, manufacturer, mfd date, ...) in a flash sector. This
hardware sector is written once when the board is programmed for the
first time and will not be changed (or only if hardware changes are
done, e.g. GPS changed). The bootloader and the autopilot software can
read the hw sector.

==Software boot sector==

The software boot sector is rewritten each time a new autopilot software
is flashed to the device. It contains the hash value for the build,
build date, the aircraft (ID and name) it was built for and other
useful configuration information.

It can contain various ways to protect the software from running on an
incompatible hardware. The simplest way is to give a hardcoded value
for the serial number. The bootloader will at least report a warning if
someone tries to flash a software into a hardware that contains the
wrong serial number. The sw boot sector could contain a specific
hardware type, version and sub information that the software is built
for. The bootloader will refuse to flash if this does not fit.

Another way would be to configure the autopilot software "on the fly" if
possible. Example: The hw sector contains the type, speed and the serial
port (0/1) that the GPS is connected to. The ap software reads this
information and configures itself. That way one software elf image
could run on almost all hardwares of a type, e.g. Tiny. There are still
some hard-to-see limitations, for example if a modem is connected to a
serial LPC port that does not have handshake lines but the software
requires that. Long and buggy lists would be the result...

==Make==

The board serial number can be mentioned in the makefile for the
aircraft to make sure that it only runs on that board. The board and
board version could be in there. It would be a lot of work and an
additional build system to mention the necessary hardware in each .c
file, maybe not useful.

I think it would be cool to not have any '#ifdef' switches any more. The
software can read the configuration and react to that. If there are
limitations there could be a a minimum board version (e.g. > V1.1)
could be given. If future versions get "too" incompatible, a new board
type or board major version is issued.

==Sectors==

The sectors are "C" structures. All entries are n * 32bit/4bytes long.
They start with the ASCII word for "PPRZ" followed by the 32bit value
for the maximum overall length. The third value points to the last
valid entry in the sector. This value increases each time the structure
is enhanced. Entries can be added but must be downwards compatible - it
is not allowed to remove values. The last valid word of the sector is a
32bit CRC. The meaning of values is defined through a "C" header or XML
file.

==On board software==

The bootloader should make sure that a valid hw sector exists when
flashing new ap software. Nevertheless is could happen that the ap
software realizes it could not start due to a crc fail, non valid
values or similar. We need a safety procedure what to do then.

[[Category:Firmware Flashing]] [[Category:Developer_Documentation]]

Subsystem/ins

2015-07-13T15:23:41Z

IHaveADrone: typo

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

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

Currently possible INS subsystem types are:

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

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

== Implementations ==

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

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

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

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

'''Parameters'''

USE_BAROMETER - Enables the use of barometric data

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

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

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

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

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

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

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

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

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

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

'''Parameters'''

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

=== ardrone2 ===
simple INS with float vertical filter for use with ardrone2_sdk

=== float_invariant ===
attitude and speed estimation for fixedwings via invariant filter

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

Flight Plans

2015-07-10T14:36:41Z

IHaveADrone: typo

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

== DTD and Structure ==

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

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

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

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

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

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

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

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

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

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

== Waypoints ==

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

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

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

== Sectors ==

=== Static sectors (default) ===

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

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

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

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

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

=== Dynamic sectors ===

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

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

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

== Includes ==

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

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

== Blocks ==

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

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

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

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

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

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

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

==== Expressions ====

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

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

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

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

=== Exceptions ===

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

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

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

=== Deroute ===

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

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

=== Return ===

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

=== Loops ===

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

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

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

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

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

=== Navigation modes ===

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

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

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

The different navigation modes are detailed in the next sections.

=== Attitude ===

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

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

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

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

=== Heading ===

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

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

=== Go ===

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

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

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

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

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

=== Path ===

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

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

=== Circle ===

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

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

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

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

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

=== Follow ===

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

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

=== Stay ===

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

=== XYZ ===

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

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

=== Set ===

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

=== Call ===

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

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

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

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

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

=== Pre Call ===

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

=== Post Call ===

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

== Procedures ==

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

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

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

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

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

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

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

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

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

== Advanced Examples ==

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

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

=== Gains on the fly ===

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

=== Dynacmically adjustable maximum speed ===

=== Immobilize Actuators ===

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

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

== Tips and Tricks ==

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

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

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

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

Category:Autopilots

2015-07-02T16:28:40Z

IHaveADrone: typo

[[Autopilots_Chinese|Chinese 中文]]
__NOTOC__
__NOEDITSECTION__

{|style="border-spacing:8px;margin:0px -8px" class="MainPageBG" style="width:100%;border:1px solid #9999bf;background-color:#f5fffa;vertical-align:top;color:#000; text-align: left;"
|-valign="top"
|
<h3 style="-moz-border-radius-topright: 0.7em;
background:#cedff2;margin:-2px;padding:4px;">
[[Image:favicon32.png|32px]] Autopilots
</h3>
<div style="padding:6px;">
{{Autopilots}}
</div>

| class="MainPageBG" style="width:70%;border:1px solid #cedff2;background-color:#f5fffa;vertical-align:top"|
{|width="100%" cellpadding="2" cellspacing="5" style="vertical-align:top;background-color:#f5fffa"
|-valign="top"
| <h2 style="margin:0;background-color:#cef2e0;font-size:120%;font-weight:bold;border:1px solid #a3bfb1;text-align:left;color:#000;padding:0.2em 0.4em;">Paparazzi Autopilots</h2>
|-
|Hardware support for Autopilot versions currently in use.
|-
|[[Image:tiny13_family_top_sm.jpg|center|400px|Tiny 1.1 autopilots on the "assembly line"]]
|-
|One of the great advantages of Paparazzi is support for multiple hardware designs. The old Paparazzi board where based around ATMega MCUs. The current autopilots are designed around two primary processors:
*STM32 series microcontrollers
*LPC21xx series microcontrollers
There are active and current autopilots designs using both architectures. Not all autopilots have the same capabilities, peripherals or features, but each has advantages in different applications.

Currently, boards are designed around the STM32F1 series, but there is future upgrade path capabilities to the F2 and F4 series, giving way to feature rich processors with a variety of peripherals and speeds. Architecture-dependent firmware code is supported in part by [http://www.libopencm3.org libopencm3]. The [[Lisa]] , [[Krooz]] and [[LinAM]] autopilots use the STM32.

The LPC21xx based boards use the LPC2148 and have been flying fixed wing and multi-rotors for many years. This architecture is more mature but at the expense of speed and extra ports available on the newer STM32 series processors. The [[Tiny]] series, [[Booz]], [[TWOG/v1.0 | TWOG]], [[YAPA]], [[Umarim_Lite_v2 | Umarim]] and [[NavGo_v3 | NavGo]] autopilots all use the LPC2148.

Some autopilots have also been designed for close integration with small single-board computers, particularly those based on [[OMAP]] processors such as the [http://www.gumstix.com/ Gumstix] [https://www.gumstix.com/store/index.php?cPath=33 Overo] series. The [[Lisa/L]] and [[Classix]] boards are designed with this in mind, though other autopilots can be easily interfaced. Further information can be found [[OMAP|here]].

A basic feature comparison table is presented to help in the autopilot hardware selection process. Stable tried tested LPC or more cutting edge STM32.

For information regarding architecture and firmware compatibility of various subsystems and modules, please see the appropriate [[Subsystems]] overview and [[Modules_list|Modules List]] pages.

NOTE: The accuracy of this table '''may not be 100% correct''', the best resource is always hardware and software source files and individual autopilot pages.

{| border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="100%"
|+'''Autopilot<sup>1</sup> Feature Matrix'''
| align="center" width="16%" style="background:#f0f0f0;"|'''Feature'''
| align="center" width="7%" style="background:#f0f0f0;"|'''[[Lisa/L|Lisa/L v1.1]]'''
| align="center" width="7%" style="background:#f0f0f0;"|'''[[Lisa/M_v20|Lisa/M v2.0]]'''
| align="center" width="7%" style="background:#f0f0f0;"|'''[[Lisa/S]]'''
| align="center" width="7%" style="background:#f0f0f0;"|'''[[LinAM V4]]'''
| align="center" width="7%" style="background:#f0f0f0;"|'''[[NavStik|NavStik]]'''
| align="center" width="7%" style="background:#f0f0f0;"|'''[[KroozSD|KroozSD]]'''
| align="center" width="7%" style="background:#f0f0f0;"|'''[[Apogee/v1.00|Apogee v1.00]]'''
| align="center" width="7%" style="background:#f0f0f0;"|'''[[Umarim_v10|Umarim v1.0]]'''
| align="center" width="7%" style="background:#f0f0f0;"|'''[[Umarim_Lite_v2|Umarim Lite v2]]'''
| align="center" width="7%" style="background:#f0f0f0;"|'''[[NavGo_v3|NavGo v3]]'''
| align="center" width="7%" style="background:#f0f0f0;"|'''[[Tiny/v2.11|Tiny v2.11]]'''
| align="center" width="7%" style="background:#f0f0f0;"|'''[[TWOG/v1.0|TWOG v1.0]]'''
| align="center" width="7%" style="background:#f0f0f0;"|'''[[YAPA/v2.0|YAPA v2.0]]'''
| align="center" width="7%" style="background:#f0f0f0;"|'''[[HBmini/v2.0]]'''
|-
|style="background:#f0f0f0;"| || align="center" colspan="13"|'''MCU'''
|-
| style="background:#f0f0f0;"|'''Part'''||<small>STM32F103RE</small>||<small>STM32F105RCT6</small>||<small>STM32F103REY6</small>||<small>STM32F405RGT6</small>||<small>STM32F415RG</small>||<small>STM32F405RGT6</small>||<small>STM32F405RGT6</small>||LPC2148||LPC2148||LPC2148||LPC2148||LPC2148||LPC2148||LPC2148
|-
| style="background:#f0f0f0;"|'''Clock'''||72MHz||72MHz||72MHz||168MHz||168MHz||168MHz||168MHz||60MHz||60MHz||60MHz||60MHz||60MHz||60MHz||60MHz
|-
| style="background:#f0f0f0;"|'''Flash'''||512kB||256kB||512kB||1024kB||1024kB||1024kB||1024kB||512kB||512kB||512kB||512kB||512kB||512kB||512kB
|-
| style="background:#f0f0f0;"|'''RAM<sup>2</sup>'''||64kB||64kB||64kB||192kB||192kB|||128 & 64kB||128 & 64kB||32kB & 8kB||32kB & 8kB||32kB & 8kB||32kB & 8kB||32kB & 8kB||32kB & 8kB||32kB & 8kB
|-
|style="background:#f0f0f0;"| || align="center" colspan="13"|'''Onboard Sensors<sup>3</sup>'''
|-
| style="background:#f0f0f0;"|'''MEMS IMU'''||no||aspirin||yes||yes||yes||krooz/ext||yes||yes||yes||yes||no||no||no||yes
|-
| style="background:#f0f0f0;"|'''Magnetometer'''|| || ||yes||yes||yes||yes||yes||no||no||yes||no||no||no||yes
|-
| style="background:#f0f0f0;"|'''Barometer'''||yes||yes||yes||yes||yes||yes||yes||yes||no||yes||no||no||no||yes
|-
| style="background:#f0f0f0;"|'''Diff Pressure'''||yes||no||no||yes||optional||no||no||no||no||no||no||no||no||no
|-
| style="background:#f0f0f0;"|'''GPS'''||no||no||yes||yes||optional||no||no||no||no||no||yes||no||no||no
|-
|style="background:#f0f0f0;"| || align="center" colspan="13"|'''Input/Output<sup>4</sup> & Communication Interfaces'''
|-
| style="background:#f0f0f0;"|'''UART'''||3 & 1RX||2 & 2RX||1 & 1RX||1 & 2RX||4<sup>9</sup>||3||3 & 1Rx||2||2||2||1||2||2||2
|-
| style="background:#f0f0f0;"|'''I2C'''||2||1 + 1<sup>5</sup>||1<sup>8</sup>||1||2<sup>9</sup>||2||2||2||1||2||1||1||1||2
|-
| style="background:#f0f0f0;"|'''SPI'''||2||1||0||0||1<sup>9</sup>||1||1||1||1||1||1||1||1||1
|-
| style="background:#f0f0f0;"|'''ADC'''||3 (12bit)||3 + 2 (12bit)<sup>5</sup>||0||3 (12bit)||2<sup>9</sup>||4 + 1 (12bit)<sup>5</sup>||0 + 3 (12bit)||0 + 4 (10bit)||8<sup>6</sup>||0 + 4 (10bit)<sup>6</sup>||0 + 1 (10bit)<sup>6</sup>||8 (10bit)||6 (10bit)||8 (10bit)(16bit)
|-
| style="background:#f0f0f0;"|'''PWM'''||6||6 + 2<sup>5</sup>||6||8||6<sup>9</sup>||10 + 1<sup>5</sup>||6 + 1||6||6||0 + 1<sup>5</sup>||8||8||10||10
|-
| style="background:#f0f0f0;"|'''PPM Output'''||no||no||no||no||no||no||no||no||no||no||1||1||no||
|-
| style="background:#f0f0f0;"|'''PPM Capture'''||1||0 + 1<sup>5</sup>||1||6<sup>9</sup>||1||1||1 + 1<sup>5</sup>||1 + 1<sup>5</sup>||1 + 1<sup>5</sup>||1||1||1||1
|-
| style="background:#f0f0f0;"|'''R/C serial'''|| ||2||1||1<sup>9</sup>||1|| ||1 (standard & S.BUS)|| || || || || || ||
|-
| style="background:#f0f0f0;"|'''GPIO<sup>7</sup>'''||?||1||0||4||?||2 + 1<sup>5</sup>||0 + 4||0 + 4<sup>6</sup>||0 + 4<sup>6</sup>||0 + 2<sup>6</sup>||2||2||1||11
|-
| style="background:#f0f0f0;"|'''Onboard LEDs'''||8||5||4||5||3||3||4||2||2||4||3||3||3||2
|-
| style="background:#f0f0f0;"|'''USB Peripheral'''||Onboard USB JTAG + UART||bootloader||no||DFU bootloader||DFU bootloader||bootloader||DFU bootloader + USB storage||bootloader||bootloader||bootloader||bootloader||bootloader||bootloader||bootlader
|-
| style="background:#f0f0f0;"|'''CAN'''||1||1||1||1||no||no||no||no||no||no||no||no||no||
|-
| style="background:#f0f0f0;"|'''MODEM connector'''||no||no||no||no|| ||Xbee||no||no||no||no||no||no||Xbee||
|-
|style="background:#f0f0f0;"| || align="center" colspan="13"|'''Onboard Peripherals'''
|-
| style="background:#f0f0f0;"|'''SD card/interface'''||no||no||no||no||yes/SPI||yes/SPI||yes/SDIO + USB storage||no||no||no||no||no|| ||
|-
| style="background:#f0f0f0;"|'''RTC'''||no||no||no||no||no||no||yes + backup cap.||no||no||no||no||no|| ||
|-
| style="background:#f0f0f0;"|'''Others'''||Overo w/ I/O incl. USB Host||Aspirin footprint, JTAG header|| || ||Overo, 16Mb SPI Flash, HDMI with JTAG+2xUART||On-board micro-USB B header||On-board mini-USB B header|| ||On-board mini-USB B header|| || || ||RS232 options||Buzzer
|-
|style="background:#f0f0f0;"| || align="center" colspan="13"|'''Program & Debug Interface'''
|-
| style="background:#f0f0f0;"|''' '''||USB (luftboot)+ JTAG + UART||USB (luftboot)+ JTAG + UART|| SWD + UART|| SWD + USB || USB + JTAG(HDMI) + UART || ||USB(DFU) + SWD||USB (pprz bootloader)||USB (pprz bootloader)||USB (pprz bootloader)||USB (pprz bootloader)||USB (pprz bootloader)||USB (pprz bootloader)||JTAG
|-
|style="background:#f0f0f0;"| || align="center" colspan="13"|'''Power Management'''
|-
| style="background:#f0f0f0;"|'''Supply Input'''||6.1V - 18V||5V - 16V||2.3V - 5.5V||7V - 32V||3.5V - 14V<sup>9</sup>||7V - 32V||5.5V - 17V||5.5V - 17V||5.5V - 17V||5.5V - 16V||6.1V - 18V||6.1V - 18V||6.1V - 18V||6.1-18V
|-
| style="background:#f0f0f0;"|'''Supply Output'''||2.25@5V, 2.25A@3.3V, Other||500mA@3.3V, 250mA@5V||1A@3.3V||1A@5V||3.3V ?||1.5A@3.3V, 5A@5V||1A@3.3V, 1.5A@5V||1A@3.3V, 1.5A@5V||1A@3.3V, 1.5A@5V||1A@3.3V, 1.5A@5V||1A@3.3V, 2.25A@5V||1A@3.3V, 2.25A@5V||2x 1A@3.3V, 2.25A@5V||1A@3.3V, 2.25A@5V
|-
| style="background:#f0f0f0;"|'''Software Switch'''||2||no||1||1 (5V)||4||no||1 (5V)||no||no||no||1||1||1||4
|-
|style="background:#f0f0f0;"| || align="center" colspan="13"|'''Mechanical'''
|-
| style="background:#f0f0f0;"|'''Size'''||~100mm x ~50mm||34mm x 60mm x 10mm||20mm x 20mm x 5mm||65mm x 45mm x 10mm||?<sup>9</sup>||50mm x 60mm x 10mm||53 x 25 x 9mm (shares the same external dimensions as UmarimLite)||56mm x 25mm||53mm x 25mm||35mm x 35mm||70.8mm x 40mm||40.2mm x 30.5mm||80.0mm x 40.0mm?||57x30mm
|-
| style="background:#f0f0f0;"|'''Weight'''||?||9.9g - 10.8g||2g||20g||?<sup>9</sup>||20g - 40g||10g||9g||8g||?||24g||8g||23g w/ XBee?||30
|-
| style="background:#f0f0f0;"|'''Connector Style'''||Picoblade||Picoblade & 0.1" Servo||0.05" header||0.1" Servo||?<sup>9</sup>||Picoblade & 0.1" Servo||Picoblade||Picoblade||Picoblade||Picoblade||Picoblade||Picoblade||0.1" Headers||Picoblade & 0.1" Servo
|-
| style="background:#f0f0f0;"|'''PCB Style'''||4-layer||4-layer||6-layer||6-layer||?||2-layer||4-layer||4-layer||4-layer||4-layer||2-layer||2-layer||2-layer||4-layer
|-
| style="background:#f0f0f0;"|'''Mounting Holes'''||4x M3||4x 2mm||no||4x M2||4x ?||4x M3||4x 2mm (shares the same mounting points as UmarimLite)||4x 2mm||4x 2mm||4x 2mm||no||no||4x M3||4xM2
|-
|style="background:#f0f0f0;"| || align="center" colspan="12"|'''Comments'''
|-
| style="background:#f0f0f0;"|'''Comments'''||IMU and Overo Mount Location, Many Features|| || ||Cortex™-M4 168MHz processor with FPU unit,onboard IMU,GPS,Baro,Airspeed ||Overo can be mount, Cortex™-M4 168MHz processor with FPU unit, onboard IMU, microSD card slot, 16Mb SPI Flash, onboard GPS, onboard speed sensor||High speed Cortex™-M4 168MHz processor with FPU unit, IMU, microSD card slot, OSD, onboard XBee connector||Cortex-M4 MCU, 9DOF IMU + Baro, Hi-speed microSD logging + USB storage mode, S.BUS compatible, small and lightweight ||Small Dimensions, narrow fuselage form factor, IMU||Smallest Dimensions, IMU, basic version of Umarim||Small Dimensions, IMU, magnetometer & high sensitivity Barometer; designed for small rotorcraft||Onboard u-blox GPS, designed for easy DIY assembly (same as TWOG)||Basic, no onboard sensors (all external for expandability)||Specially designed to work with rs232 sensors such as XSens Mit-G/Crossbow NAV420/ig500/3DM-GX3/DMS-SGP02/MGL-sp-5. Onboard XBee connector|| can use mpu6050 or mpu6000
|-
| style="background:#f0f0f0;"|'''Typical Usage'''||Advanced payload and controls development using Gumstix; fixed-wing or rotorcraft||Small, general purpose w/ IMU; fixed-wing or rotorcraft|| ||High integrated and performance, rotorcraft or fixed-wing|| ||High integrated, high productivity board w/ IMU, microSD card, OSD and XBee; rotorcraft or fixed-wing||Small and powerful general purpose ;fixed-wing||Small, general purpose w/ IMU; fixed-wing||Small, general purpose w/ IMU; fixed-wing||Small, general purpose w/ IMU; rotorcraft||Small, general purpose w/ GPS; fixed-wing with external IR or IMU||Small, general purpose; fixed wing with all external sensors||0.1" headers means easier wiring, at the cost of weight||For all kind of aircraft
|-
| style="background:#f0f0f0;"|'''Date Introduced'''||Summer 2010||Winter 2012||Summer 2013||Summer 2015||Summer 2013||Spring 2013||Summer 2013||Fall 2011||Summer 2012||Summer 2012||Fall 2007||Spring 2008||Spring 2011||Winter 2012
|-
| style="background:#f0f0f0;"|'''Previous Versions'''||[[Lisa/L]] v1.0||[[Lisa/M_v10|Lisa/M v1.0]]|| ||[[LinAM]] v3 ||[[Krooz|Krooz]]|| || || || ||[[Tiny/v1.1|Tiny v1.1]], [[Tiny/v0.99|Tiny v0.99]]|| ||[[YAPA/v1.0|YAPA v1.0]]||
|}

'''Notes:'''

'''1.''' Only the newest revisions of the more commonly used autopilots are listed

'''2.''' The extra 8kB of RAM on the LPC2148 shared with the USB DMA

'''3.''' The onboard sensors are almost always supplemented with external sensors. For example, TWOG can use an external IMU or IR sensors, and also needs an external GPS.

'''4.''' Input/Outputs listed are generally those easily accessible on regular autopilot connectors, customization/hacks can modify available I/O, for example free an extra I2C on Tiny and TWOG

'''5., 6.''' Some features use shared resources - denoted by X + Y where Y is shared - and cannot be used simultaneously

'''5.''' Lisa/M v2.0 shared resources include: one I2C is shared with 2 PWM outputs, two ADCs are shared with LEDs, one RX only UART is shared with the PPM capture

'''6.''' Umarim v1.0 shared resources include: 4 ADCs are shared with 4 GPIOs

'''7.''' Usually other unused pins can be used for additional GPIO with some code modifications

'''8.''' Many of the pins have multiple purposes. Servo 5&6 can be used for i2c even though there is no dedicated connector.

'''9.''' Depending on the breakout board on the autopilot which outputs/inputs are made available.

|-
|<h2>Schematics, CAD files, Gerber files, BOM release strategy</h2>
|-
|<h3>About the hardware development and release process.</h3>

[https://github.com/paparazzi/paparazzi-hardware Files needed to create the hardware can be found here]. It is always good to remind oneself of the email Antoine once wrote in the mailing list before you want to start producing your own PCB's.

<P>8 June 2011 13:25:47 Antoine Drouin wrote on the mailing list:</P>

I've started this project together with Pascal 8 years ago and since then I have dedicated my time to try and make it successful. I'm utterly convinced of the benefits of open source, but observing how Paparazzi grew over time, I came to the conclusion that hardware is a bit different than software... "gcc tiny.brd" is not going to make a board magically appear on your desktop.

I'll list here some of my arguments in favor of releasing CAD files after the board is mature.

# Unlike software, where an unskilled user can type make and get a piece of complex software to successfully build, assembling hardware requires tools and skills. Providing gerbers and BOM have lured a bunch of new users into believing otherwise and has created tons of frustration. I've myself fixed a number of badly assembled boards and I even recall that while helping debugging a board (so after assembly), discovering that the person had manufactured two layers PCBs instead of four layers. As the technology of the autopilot increases, this problem becomes more and more important.
# The success of the project depends on the availability of affordable hardware. The price of hardware is directly and exponentially dependent on the number of manufactured units. If ten persons manufacture 10 boards each, the cost will be much higher than if one person manufactures 100.
# Last and not least, the quality of assembly also depends very much on the number of manufactured units. Good quality can only be achieved through the use of automated placing and soldering, and those processes can only be used if the number of units reach a certain amount.

|}
|}

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

Get Hardware

2015-07-02T14:30:39Z

IHaveADrone: spelling (Firefox can spell check the edit box, this is awesome)

As an open-source project, all source code and hardware plans are [https://github.com/paparazzi/paparazzi-hardware freely available on GitHub] for anyone to produce, use, modify, and redistribute in accordance with the [http://www.gnu.org/licenses/gpl.txt GPL License Agreement] which requires only that the open-source nature of the project be maintained by all who redistribute it.

<hr>

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

=Autopilots=

== [[File:1bitsquared_logo.png|100px|link=http://1bitsquared.com]] 1 BIT SQUARED ==
<br>
Paparazzi UAV, development, production and consulting company. Manufacturers and distributors of [[Lisa/S]] nano autopilot.

<hr>

== [[File:Ppzuav.jpg|100px|link=https://www.ppzuav.com/osc]] PPZUAV ==
[[Image:ApogeeV1_img01sm.JPG|thumb|100px|ApogeeV1]]
<p>Assembling hardware for Paparazzi based projects since 2007.</p>
<p>We are a USA based company that makes the Open Sourced Paparazzi Hardware available around the World. If you need fully assembled or just PCBs we can help.</p>

<p>If you do not see what you need please do not hesitate to contact us via eMail to: sales@ppzuav.com for details.
Visit the [https://www.ppzuav.com/osc Web Store] to see the latest offerings.</p>
<br><br><br>
<hr>
<hr>
<p>
NOTE: PPZUAV will be closed for vacation Sept 2014 to Jan 2015.
</p>
<br style="clear:both">
<br style="clear:both">

== [http://transition-robotics.com [[Image:Transition_Robotics_Logo.png|100px]] Transition Robotics Inc.] [[Image:LisaM_V2_0_TopView.JPG|thumb|Lisa/M V2.0 top view]][[Image:LisaM_V2_0_BottomView.JPG|thumb|Lisa/M V2.0 bottom view]] ==

Transition Robotics Inc. is a young company developing new solutions for and with the Paparazzi UAV platform. Their core product is the [[Image:Quadshot_Logo.jpg|100px|link=http://thequadshot.com|Quadshot]], a VTOL transitioning aircraft.

Beside the Quadshot itself they develop and provide hardware and software that is especially optimized for Paparazzi, such as the Lisa Autopilots, Aspirin IMUs and associated accessories.

They have a shop on their [http://transition-robotics.com Quadshot product page].

As of February 2012, Transition Robotics, Inc. has acquired all IP and Paparazzi related inventory from Joby Robotics. We are thankful to Joby Robotics for their important and faithful support of Paparazzi related hardware projects, and hope to carry on this tradition. Hardware formerly supplied by Joby Robotics may now be purchased at the [http://transition-robotics.com/collections/all Transition Robotics/Quadshot webstore.]

The [http://transition-robotics.com/collections/all TRI/Quadshot Webstore] also stocks pre-crimped Molex Picoblade wires and connector housings.

<hr>
<br><br><br>
== [[File:Luftfotos24.jpg|250px|link=http://www.luftfotos24.de/de/]] Luftfotos24 ==
<p>We produce ready-to-fly paparazzi systems for everyone.</p>
<p>We are a company based in germany and deliver around the world. We create our own hardware and a groundstation that includes the rc transmitter and video rx. Complete paparazzi systems are available at: [http://shop.luftfotos24.de Shop Luftfotos24]</p>
<br><br><br>
<hr>

<br style="clear:both">

= Other =

==[http://www.sparkfun.com Sparkfun]==
Sparkfun is a great source of miscellaneous electronics like:
* Development boards
* GPS
* Gyros
* Accelerometers
* Pressure sensors
* Ultrasonic distance sensors
* Temperature/humidity sensors
* USB to Serial converters (XBEE adapter)
* LEDs
* Etc.

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

'''Sparkfun distributors in Europe'''

Incomplete list.
*http://www.lipoly.de/index.php?main_page=index&cPath=880_883&language=en
*http://www.watterott.com/en/SparkFun

==Mouser==

Electronic distributor, sells all kinds of electronic parts or modules.
Free shipping as of 60€.

== [https://store.diydrones.com/ DIYDrones] ==
Mainly focused on ArduPilot hardware. But carries Paparazzi compatible Telemetry and sensor boards.

'''DIYDrones distributors in Europe'''
*http://www.lipoly.de/index.php?main_page=index&cPath=880_1912 [DE]
*http://www.unmannedtechshop.co.uk/ [UK]
*http://www.buildyourowndrone.co.uk/ [UK]

==u-Blox GPS receivers==

* [http://www.navilock.de/produkte/gruppen/13/Boards_und_Module navilock.de] (also available on [http://www.amazon.de Amazon.de])
* [http://www.rfdesign.co.za/pages/5645456/Products/GPS-Products/Antaris-4-Modules.asp rfdesign.co.za] (Also [http://www.rfdesign.co.za/pages/5645456/Products/GPS-Products/u-blox-5-Modules.asp u-blox 5] and [http://www.rfdesign.co.za/pages/5645456/Products/GPS-Products/u-blox-6-Modules.asp u-blox 6] modules avialable)
* [http://www.expedienttech.com/ expedittech.com]
* [http://www.csgshop.com/category.php?id_category=16 csgshop.com US UBLOX MAX-6Q] ( Lithuania )
* [https://www.ppzuav.com/osc/product_info.php?cPath=13&products_id=75 ppzuav.com GPS13] (USA)
* [http://www.hobbyking.com/hobbyking/store/__31135__neo_6m_gps_module.html hobbyking.com NEO-6M] 18$ / 14€

==Airspeed Sensors==

Eagle Tree Systems makes a small standalone airspeed sensor that can be connected via i2c. They also sell pitot tubes standalone for other differential pressure sensors.
*[http://www.eagletreesystems.com/Standalone/standalone.htm Eagle Tree Systems] (Also available from a number of distributors)

== DIGI XBee telemetry modules ==
For detailed shopping guide see [Modems]
*http://www.watterott.com/en/Digi (DE EU)
*https://store.diydrones.com/ (US See above for local distributors)
*http://unmannedtechshop.co.uk/UAV-Components/UAV-telemetry (UK)
*http://mouser.com/ (AU and other regions)

=PCB=
==[https://www.ppzuav.com/osc/index.php?cPath=1 PPZUAV]==
Paparazzi specific bare and already assembled PCB's.

==[http://www.seeedstudio.com/service/index.php?r=site/pcbService Seeedstudio Fusion PCB]==
Very cheap 1, 2 and 4 layer boards from china. (perfect for bigger volumes and a low price)<br/>
Shipping from china takes some time. Minimum order is 5 pcs.

==[http://oshpark.com/ OSH Park]==
Fast high quality 2 and 4 layer boards.(perfect for high requirements, but they're not the cheapest)<br/>
Free worldwide shipping. Minimum order is 3 pcs.

==[http://PCBShopper.com/ PCBShopper]==
A hobbyist-created site for finding the cheapest PCB manufacturer. Enter the size, layers, and quantity of the board you designed, and PCBShopper will give you prices and delivery time from several different manufacturers.

= Old vendors =

Here is a list of former paparazzi hardware vendors for reference. They were providing a great service to the Paparazzi community.

* [http://chebuzz.com/paparazzi Chebuzz Pprz] had to move back to US and close his store, [http://aerofu.com/ AeroFu] is carrying on his business.
* [http://jobyrobotics.com Joby Robotics] stock and IP was bought by [http://transition-robotics.com Transition Robotics] that is carrying on their business.

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

Sensors/Airspeed

2015-07-02T14:25:45Z

IHaveADrone: pesky spelling

<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Sensors</categorytree>
== Introduction ==
By default, in the airborne code, airspeed is estimated by measuring the GPS ground speed. The related control loops are described [[Control_Loops|here]]. This gives reasonable results particularly in calm weather conditions. Adding an airspeed sensor measures actual airspeed resulting in better throttle control and aircraft performance especially in windy conditions. It is possible to build your own airspeed sensor by using pressure sensors. To start with adding airspeed sensors it is easier to buy pre-build calibrated airspeeds sensors. This page is currently mainly about how to do just that.

== How does it work internally ==

The altitude and airspeed loops are separated as shown in the diagram below. Basically the throttle and pitch are controlled independently and are not coupled in the control loops. Of course one affects the other but the control loops are independent. Please see the [[Control_Loops#Control_loops_using_Airspeed_Sensor|control loops]] for a more detailed block diagram. The airspeed is controlled by two cascaded Proportional–Integral (PI) loops. The first loop is used to regulate the ground speed and the second the airspeed. This is done just to ensure that if the ground speed drops below a certain value the airspeed will be increased to compensate in order to maintain a valid GPS heading. If you happen to have a 3axis magnetometer build in your airframe for getting the heading values, maintaining a certain GPS speed for getting a heading is not needed.

[[Image:Airspeed.png|left|800px]]
<br style="clear:both">
The following plot is from an actual test flight after spending some time setting the loop gains Here the possibility to perform real-time tuning through the GCS is a real time saver. In the test, the an airplane was flying circles at a constant altitude, except in the end of the flight. The wind was about 5 m/s, judging from the ground speed variations. In the middle there is an example of what happens when the ground speed falls below the setpoint. Finally the altitude setpoint was changed to verify that the airspeed will be maintained while climbing.
[[Image:PlotAS2.png|left|600px]]
<br style="clear:both">
The benefits of the airspeed hold are obvious in this example. The throttle adjusts to keep the airspeed close to the setpoint.
[[Image:09_10_04__17_50_27_as1.png|left|600px]]
<br style="clear:both">

== Measuring ==

Sometimes it is very helpful for tuning your aircraft that you only measure the airspeed without controlling you aircraft behavior. This can be accomplished in the following way:

Replace the '''USE_AIRSPEED''' define with '''MEASURE_AIRSPEED'''.
If you want to get sensor information as it is acquired without delay through the PERIODIC_SEND_ telemetry mechanism, please set '''SENSOR_SYNC_SEND''' instead. Note that defining MEASURE_AIRSPEED and not USE_AIRSPEED results in the normal AIRSPEED message containing rather useless information (it is simply four copies of estimator_airspeed, which is not updated by the airspeed sensor, though appears to be updated a very low rate '''FIX THIS?'''). Since the airspeed control loops are not active, one can vary the frequency of the raw measurements by adjusting the rate at which the airspeed_ets module is called in conf/modules/airspeed_ets.xml in the periodic function frequency.

= Airspeed sensors =

== EagleTree Airspeed Sensor ==

=== Connecting an EagleTree Airspeed Sensor ===

The [http://www.eagletreesystems.com/Standalone/standalone.htm EagleTree Airspeed Sensor] is a low cost module and comes with a very good pitot tube (Prandtl style, pitot-static tube) that includes static and dynamic ports, it's resolution is 0.45 m/s and it's max speed is 156 m/s. It has an [http://en.wikipedia.org/wiki/I²C I²C] interface that connects directly to the Autopilot I²C port. The paparazzi autopilot code is able to regulate the throttle in order to keep the airspeed constant (and a minimum ground speed).

When you buy the airspeed sensor it is set to operate in the default mode. Make sure you did not set it somehow to 3rd party mode.

First, connect the sensor directly to the TWOG, Tiny or Lisa/M autopilot board via the I²C connector. The connector is J6 on the TWOG and Tiny and I2C on Lisa board. The wires coming from the sensor module have the following layout:

Red wire: 5V
White wire: Ground
Yellow wire: SDA
Brown wire: SCL

'''See the [[Module/Airspeed_ETS|airspeed_ets module]] page for configuration.'''

=== EagleTree sensor in 3rd party mode ===

While it is possible to use the sensors in a mode where values are the real values measured a.k.a. 3rd party mode, for regular use with the autopilot it has no specific advantage. Since the paparazzi already contain code to convert values to real speed values. Using the default setting is even a simpler if you have an eagletree logger and inbetween do some measurement with it, you do not need to reprogram the sensors if you connect them to the Autopilot board again.

==== Direct mode ====

Optionally if you have a special requirement and want to use the ''direct mode'', it is possible. For this at the moment one needs to use the Eagletree software under Windows. [[Image:SetSensorFor3rPartyModeRealValues.jpg|240px]]

Regardless that his software runs fine under Linux Wine, using is not possible since the USB port is used in HID mode and as of Wine v1.2 using the USB bus under wind this way is not possible yet. There is however work done and on its way that USB ports do work under Wine for HID device.

== Sensortechnics Airspeed Sensor ==

[http://www.sensortechnics.com Sensortechnics] provides a lot of solution for pressure measurements, absolute or differential, using analog or digital (i2c) outputs.

For airspeed measurements on low speed MAVs, a good choice is the [http://www.sensortechnics.com/en/products/pressure-sensors-and-transmitters/amplified-pressure-sensors/lba/ LBA series], especially the [http://www.sensortechnics.com/cms/upload/appnotes/AN_LBA_E_11162.pdf LBAS500UF6S].

This sensor can be used with the generic [http://paparazzi.github.com/docs/latest/module__airspeed_adc.html '''airspeed_adc''' module]. Note that it may be necessary to use a divisor bridge to adapt the 5V output of the sensor to the 3.3V ADC input of the autopilot.

== MS45xx ==

[[Image:MS4525DO.jpg|200px]]

A MS4525DO based sensor use could benefit from build in temperature compensation.

Application notes to accompany this product:

# [http://www.meas-spec.com/downloads/MS45xx_Series_Application_Note.pdf MS45xx Series Application Notes]
# [http://www.meas-spec.com/downloads/Interfacing_to_MEAS_Digital_Pressure_Modules.pdf Interfacing to MEAS Digital Pressure Modules]
# [http://www.meas-spec.com/downloads/Configuration,_POR_and_Power_Consumption.pdf Configuration, POR and Power Consumption.]

[http://www.digikey.com/catalog/en/partgroup/ms4525do/29060 One can buy one here at digikey]

To use MS4525 you can load the [http://docs.paparazziuav.org/latest/module__airspeed_ms45xx_i2c.html airspeed_ms45xx_i2c.xml module], e.g. put these lines in the modules section of your airframe file:
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<modules>
<load name="airspeed_ms45xx_i2c.xml">
<define name="MS45XX_I2C_DEV" value="i2c1"/>
<define name="MS45XX_PRESSURE_RANGE" value="1"/>
<define name="MS45XX_OUTPUT_TYPE" value="0"/>
<define name="MS45XX_PRESSURE_OFFSET" value="8549.0"/> 
</load>
</modules>
</source>
}}

== Duo MS5611 ==

Two MS5611 working in cooperation. see http://blueflyvario.blogspot.de/2013/06/air-speed-from-two-ms5611.html

== [[Sensors/AMSYS|AMS 5812-0003 / AMS 5812-0001]]==

[http://www.amsys.info/drucksensor/differenzdrucksensor.htm EU distributor]
[http://www.servoflo.com/product-guide-downloads/low-pressure-guide/download/398/847/17.html US Distributor]

The biggest advantage of the -0001 is its resolution, at a loiter airspeed of 8.5 m/s, the resolution of the -0001 is about 0,0038 m/s whereas the resolution of the MS4525 would be 0,082 m/s (using the data provided by 3DR).
This advantage gets smaller, the faster the aircraft travels. At 25 m/s the resolution is about 0,0013m/s and 0,028 m/s. Both resolutions should be more then enough at that speed.

Maximum speed for the -0001 is about 41 m/s, for the -0003 about 58 m/s

= Future =

Just as with everything in the UAS world, lots of improvements are still possible.

'''What could be improved:'''

# Maybe revert to GPS measurements only if the airspeed sensor fails.
# Detect Swap of static/dynamic port at pre-flight test

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

Subsystem/actuators

2015-06-26T13:48:53Z

IHaveADrone: anchor tag links and spelling

<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Subsystems</categorytree>
This subsystem only needs be explicitly specified for rotorcrafts where there are several different actuators implementations and you have to add the correct one depending on the ESCs you use.

Currently possible actuators subsystems are
* ''[[Subsystem/actuators#MKK|mkk]]''
* ''[[Subsystem/actuators#MKK_v2|mkk_v2]]''
* ''[[Subsystem/actuators#Asctec_v1|asctec]]''
* ''[[Subsystem/actuators#Asctec_v2|asctec_v2]]''
* ''[[Subsystem/actuators#PWM|pwm]]''
* ''[[Subsystem/actuators#Dual_PWM|dualpwm]]''
* ''skiron''
* ''heli''
* ''ardrone2''

== MKK ==
Mikrokopter ESCs
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="rotorcraft">
...
<subsystem name="actuators" type="mkk">
<configure name="MKK_I2C_SCL_TIME" value="50"/> 
<configure name="ACTUATORS_MKK_I2C_DEV" value="i2c1"/>
</subsystem>
<define name="I2C_TRANSACTION_QUEUE_LEN" value="10"/> 
</firmware>
</source>
}}

* ''MKK_I2C_SCL_TIME'' is specific to LPC21x based boards (e.g. booz) and has no effect for STM32 based boards (e.g. Lisa/M/L)

=== XML configuration ===

{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<section name="ACTUATORS_MKK" prefix="ACTUATORS_MKK_">
<define name="NB" value="4"/>
<define name="ADDR" value="{ 0x52, 0x54, 0x56, 0x58 }"/>
</section>
<servos driver="mkk">
<servo name="FRONT" no="0" min="0" neutral="2" max="200"/>
<servo name="RIGHT" no="1" min="0" neutral="2" max="200"/>
<servo name="BACK" no="2" min="0" neutral="2" max="200"/>
<servo name="LEFT" no="3" min="0" neutral="2" max="200"/>
</servos>
</source>
}}

The order of addresses in the list defines the numbering of motors! Warn on this during motor mixing!

You also need the matching [[Rotorcraft_Configuration#Motor_Mixing|Motor Mixing section]].
For Paparazzi versions older than 5.0 MKK specific values for SUPERVISION defines:
* ''STOP_MOTOR'' : 0, optional, as the default is already 0
* ''MIN_MOTOR'' : 3
* ''MAX_MOTOR'' : 200
The ''STOP|MIN|MAX_MOTOR'' define are not needed in version 5.0 and above.

== MKK v2 ==

Similar to the above, this is version 2 of the MKK ESCs. The configuration is the same as above, just change mkk to mkk_v2 and MKK to MKK_V2.

This also works with ESCs that have the SimonK firmware and that have I2C support. Very limited documentation is available at [https://github.com/sim-/tgy/ the github page]. It should be noted that you will need to compile and load the firmware for each motor as you will need to change the I2C address for each one to match the ADDR define. If you have success with this please post some more info here.

== Asctec v1 ==
These controllers already to the mixing themselves, so the [[Rotorcraft_Configuration#Motor_Mixing|Motor Mixing section]] section is not needed.
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="rotorcraft">
...
<subsystem name="actuators" type="asctec"/>
</firmware>
</source>
}}

== Asctec v2 ==
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="rotorcraft">
...
<subsystem name="actuators" type="asctec_v2"/>
</firmware>
</source>
}}
=== XML configuration ===
You need the matching [[Rotorcraft_Configuration#Motor_Mixing|Motor Mixing section]].

== PWM ==
Only for stm32 based autopilot boards (eg. Lisa/M, Lisa/L)
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="rotorcraft">
...
<subsystem name="actuators" type="pwm">
<define name="SERVO_HZ" value="400"/>
</subsystem>
</firmware>
</source>
}}

The define ''SERVO_HZ'' sets a higher update frequency for the pwm controllers which is needed for good response times on some ESCs. Some newer ESCs are said to work better with lower frequencies. More information should be added here.
=== XML configuration ===
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<servos min="0" neutral="0" max="0xff">
<servo name="FRONT" no="0" min="1000" neutral="1000" max="2000"/>
<servo name="BACK" no="1" min="1000" neutral="1000" max="2000"/>
<servo name="LEFT" no="2" min="1000" neutral="1000" max="2000"/>
<servo name="RIGHT" no="3" min="1000" neutral="1000" max="2000"/>
</servos>
</source>
}}
You also need the matching [[Rotorcraft_Configuration#Motor_Mixing|Motor Mixing section]].

== Dual PWM ==
This driver allows you to generate dual pulses to control for example double servos like those :

[[File:Dual linear servos.jpg]]

The signal we want to generate look like that :

[[File:Dual_pulse.png]]

During the time of a regular pwm pulse (20ms) we got two parts :
* the first 1 with a total period of 4ms. During that part we generate the first pulse that is going to control for example the first servo.
* the first 2 with a total period of 16ms. During that part we generate the second pulse that is going to control for example the second servo.

=== How to use the driver ===

<span style="color:#FF0000">'''CAUTION!'''</span> <b>This module is only implemented on the lisa M and lisa S boards at the time of writing this documentation (28 mars 2014)</b>

First of all you are going to need to add the subsystem that is going to generate those pulses :

{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing">
<target name="ap" board="lisa_s_0.1">
...
</target>

...

<subsystem name="actuators" type="dualpwm">
<define name="DUAL_PWM_ON"/>
</subsystem>

</firmware>
</source>
}}

=== XML configuration ===
Then we will be able to add a servo block into the airframe file (in the same way we would for regular servos). But we have to specify the driver that we are using for those servos :

{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
...
<servos driver="DualPwm">
<servo name="SWITCH" no="3" min="1100" neutral="1500" max="1900"/>
<servo name="pitchator" no="2" min="1100" neutral="1500" max="1900"/>
</servos>
...
</source>
}}

<span style="color:#FF0000">'''CAUTION!'''</span> <b>The tricky part about this module is that it requires the use of the full timer (that was previously shared between multiple regular pwm). In order to reduce the wast of pins we can only put that type of servos on specifics pins :
* lisa S (version 0.1) : on the servos 2 and 3 (as shown above). The dual PWM will then but outputted on the 5th pin (yes that is not logical).
* lisa M (version 2.0) : on the servos 4 and 5. The dual PWM will be outputted on the 4th pin.
</b>

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