PaparazziUAV - User contributions [en]

Apogee/v1.00

2018-08-02T13:22:21Z

Dianzhichong: /* Where to Buy */

{| align=right
|-
|<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Autopilots</categorytree>
|}
<div style="float: right; width: 65%">
[[Image:Apogee_v100_top.jpg|260px|Apogee v1.00 bottom side]]
[[Image:Apogee_v100_bottom_1E.jpg|400px|Apogee v1.00 top side]]
</div>
__TOC__

== Overview ==

* STMicroelectronics STM32F405RGT6 Cortex M4 168MHz processor featuring a Floating point unit (FPU), up to 192k of RAM and 1024k of FLASH.
* 9(6) DOF integrated IMU MPU-9150(6050) based
* 1 x Barometer/altimeter MPL3115A2 (I2C, MPU slave capability)
* 1 x MicroSD card slot, 4 bit SDIO interface (high speed data logging)
* 1 x USB : DFU mode (download) or USB storage (direct access to MicroSD card)
* 6 x Servo PWM outputs
* 1 x R/C receiver PPM frame input
* 1 x R/C receiver serial input with inverter (Futaba S.BUS, Spektrum, etc.)
* 3 x UART
* 2 x [http://en.wikipedia.org/wiki/I2c I<sup>2</sup>C] bus
* 1 x [http://en.wikipedia.org/wiki/Serial_Peripheral_Interface SPI] bus
* RTC with backup capacitor
* SWD(ARM download/debug interface)
* 4 x Auxiliary I/O (General Purpose and/or ADC and/or servo PWM)
* 5v / 1.5A switching power supply (input voltage range 5.5V min → 17.0v max)
* 3.3v / 1A linear regulator
* 1 x 5v / 500mA power switch
* 4 x status LEDs
* 10.4 grams (0.37 oz)
* 53 x 25mm (2.1" x 0.98"), shares the same external dimensions and mounting points as UmarimLite
* 4 layers PCB design

== Hardware Revision History ==

{|border="1" cellspacing="0" style="text-align:center" cellpadding="6"
!''Version #''!!''Release Date''!!''Release Notes''
|-
|v1.00||07/2013||Initial release of Apogee
|}

== Detailed Features ==

=== SDIO (MicroSD card) ===

* software support available with '''v5.2''' and above
* hi-cap power designed to give enough time to cleanly save buffer and close file(s) when power outage detected
* USB-storage mode when plugging an USB cable after startup

=== 6 or 9 DOF IMU ===

Apogee v1.00 PCB offer two [http://www.invensense.com/ Invensense] IMU chip options:
* [http://www.invensense.com/mems/gyro/mpu6050.html MPU-6050] : 6 DOF, 3 axis Accelerometer + 3 axis Gyroscope
* [http://www.invensense.com/mems/gyro/mpu9150.html MPU-9150] : 9 DOF, 3 axis Accelerometer + 3 axis Gyroscope + 3 axis Magnetometer

=== USB Modes ===

* usb plugged before autopilot is powered : enter DFU mode to be flashed
* usb plugged after autopilot is powered : stop ap task, enter usb storage mode to made sdcard content easily avalaible, after the host has mounted;copied;dismounted storage;unplugged usb, ap restart

=== SWD: Serial Wire Debug ===
permits flash and source level debugging via swd part of cheap discovery card, or via more capable, fastest, more expensive probe like black magic probe

=== R/C Serial ===

In addition to the classic PPM input, that mostly require receiver modification, one pin of the R/C connector is routed to the MCU UART2 receive input through a '''controlled inverter'''.<br>
This new feature allow '''direct connection''' (3 pin) of several brand off-the-shelf receivers '''without hardware modification''' or external encoder board.
* '''RX2_POL(PB13) = 0''' => R/C serial (Rx2) is '''non-inverted''' : allow use standard polarity serial receivers (Spektrum, FlyElectric...)
* '''RX2_POL(PB13) = 1''' => R/C serial (Rx2) is '''inverted''' : allow use of S.BUS protocol compatible receivers (Futaba, FrSky,...)
(see [[RC_Receivers_and_Radios | R/C Receivers and Radios page]] for serial compatible receiver)

=== Real Time Clock ===
supercap powered rtc, permit to associate correct time and date on sdcard log files, when ap is unpowered between flights

=== Power Switch ===

'''5V''' power output pin on '''AUX connector''' ("5Vaux",#2) '''can be switched ON and OFF''' on demand using APSW (MCU GPIO output PB12).
* APSW = 0 => 5V Aux OFF
* APSW = 1 => 5V Aux ON (default)
The internal switch TPS2051B is designed to withstand 500mA continuous current and is '''short-circuit and thermally protected'''.<br>
(see [http://www.ti.com/product/tps2051b TPS2051B] datasheet for recommended operation conditions)

== Pictures ==

<gallery>
Image:Apogee_v100_3D_bottom.png|Apogee v1.00 3D bottom view
Image:Apogee_v100_3D_top.png|Apogee v1.00 3D top view
Image:Apogee_v100_bottom.JPG|Apogee v1.00 bottom view
Image:Apogee_v100_top_1E.JPG|Apogee v1.00 top view
Image:Apogee&UmarimLitePCBs.JPG|Apogee v1.00 and Umarim-Lite<br>footprint comparison
</gallery>

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

[[Image:Apogee_v100_pinout.png]]

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''SRV0/1/2/3/4/5'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''
|-
|1||style="background:black; color:white"|GND||PWR||common ground
|-
|2||style="background:Orange; color:white"|+5V||PWR||5V Rail from autopilot
|-
|3||SRVx||OUT||Servo signal (PWM)
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''R/C'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''
|-
|1||style="background:black; color:white"|GND||PWR||common ground
|-
|2||style="background:Orange; color:white"|+5v||PWR||5V Rail from autopilot
|-
|3||style="background:white; color:black"|PPM in||IN||PPM Stream from R/C Receiver (5V tolerant)
|-
|4||style="background:green; color:white"|RX2||IN||UART2 Serial Input (5V Tolerant) through [[#R/C Serial|controlled inverter]]
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''UART1/4/6'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''
|-
|1||style="background:black; color:white"|GND||PWR||common ground
|-
|2||style="background:Orange; color:white"|+5V||PWR||5V Rail from autopilot
|-
|3||style="background:Red; color:white"|+3.3V||PWR||3.3V Rail from autopilot
|-
|4||style="background:green; color:white"|RX1/4/6||IN||UART1/4/6 Serial Input (3.3V level, UART1 and UART6 are 5V tolerant, UART4 '''IS *NOT* 5V''' tolerant)
|-
|5||style="background:blue; color:white"|TX1/4/6||OUT||UART1/4/6 Serial Output (3.3V level)
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''I2C1/2'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="12%"|''Type''!!''Description''
|-
|1||style="background:black; color:white"|GND||PWR||common ground
|-
|2||style="background:Orange; color:white"|+5V||PWR||5V Rail from autopilot
|-
|3||style="background:red; color:white"|+3.3V||PWR||3.3V Rail from autopilot
|-
|4||style="background:sienna; color:white"|SDA1/2||Open Drain I/O<br>(1.5k pull-up)||I2C1/2 bus Serial DAta
|-
|5||style="background:blue; color:white"|SCL1/2||Open Drain I/O<br>(1.5k pull-up)||I2C1/2 bus Serial CLock
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''USB'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''
|-
|1||style="background:black; color:white"|GND||PWR||common ground
|-
|2||style="background:green; color:white"|USB+||I/O||USB bidirectional D+ line
|-
|3||style="background:white; color:black"|USB-||I/O||USB bidirectional D- line
|-
|4||style="background:orange; color:white"|VBUS||IN||Indicates the presence of USB bus power (5V level), DFU or USB storage Mode selection
|}
''Note: MiniUSB and Molex USB connectors are in parallel, only one can be connected at a time.''

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''SPI1'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''
|-
|1||style="background:black; color:white"|GND||PWR||common ground
|-
|2||style="background:Orange; color:white"|+5V||PWR||5V Rail from autopilot
|-
|3||style="background:red; color:white"|+3.3V||PWR||3.3V Rail from autopilot
|-
|4||style="background:sienna; color:white"|CS1||OUT||Slave Select. Selects the SPI slave (PB9)
|-
|5||style="background:Grey; color:white"|MOSI1||I/O||SPI1 Master Out Slave In. Data output from master / data input to slave
|-
|6||style="background:Green; color:white"|MISO1||I/O||SPI1 Master In Slave Out. Data input to master / data output from slave
|-
|7||style="background:Yellow; color:black"|SCK1||I/O||SPI1 Serial clock. Clock output from master or input to slave
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''AUX'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Port!!''Description''
|-
|1||style="background:black; color:white"|GND||PWR||||common ground
|-
|2||style="background:Orange; color:white"|+5Vaux||PWR||||5V from autopilot through [[#Power Switch | Power Switch]]
|-
|3||style="background:Red; color:white"|+3.3V||PWR||||3.3V Rail from autopilot
|-
|4||AUX1||I/O||PB1||General Purpose I/O #1 or ADC_1 Input or PWM6
|-
|5||AUX2||I/O||PC5||General Purpose I/O #2 or ADC_2 Input
|-
|6||AUX3||I/O||PC4||General Purpose I/O #3 or ADC_3 Input
|-
|7||AUX4||I/O||PB15||General Purpose I/O #4 (also spektrum bind pin)
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''SWD'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''
|-
|1||style="background:black; color:white"|GND||PWR||common ground
|-
|2||style="background:red; color:white"|+3.3V||PWR||3.3V Rail from autopilot
|-
|3||style="background:white; color:black"|RST||IN||MCU Reset
|-
|4||style="background:blue; color:white"|SWCLK||IN||Serial Wire Clock
|-
|5||style="background:sienna; color:white"|SWDIO||I/O||Serial Wire Data Input/Output
|}

== Schematic ==
[[Image:Apogee_v100_schematic.png|left|900px|Apogee v1.00 Schematic]]
<br style="clear:both">

== PCB ==

=== Gerber & Drill Files ===

PCB design [http://www.eurocircuits.com/images/stories/ec09/ec-classification-english-1-2010-v2.pdf Eurocircuits 6-C class] compliant:

'''''[[Media:Apogee_v100_gerber_files.zip|Download Apogee v1.00 gerber & drill files (zip)]]'''''

RS274X, units = Inches, format = 2:5

:*Apogee_v100_Silkscreen_TOP.GBR (Top Component Print Layer)
:*Apogee_v100_Soldermask_Top.GBR (Top Solder Mask)
:*Apogee_v100_Paste_Mask_Top.GBR (Top Paste Mask, stencil)
:*Apogee_v100_Signal_Top.GBR (Top Copper Layer)
:*Apogee_v100_Internal_Plane_1.GBR (Internal Copper Layer GND)
:*Apogee_v100_Internal_Plane_2.GBR (Internal Copper Layer +3.3V)
:*Apogee_v100_Signal_Bottom.GBR (Bottom Copper Layer)
:*Apogee_v100_Paste_Mask_Bottom.GBR (Bottom Paste, stencil)
:*Apogee_v100_Soldermask_Bottom.GBR (Bottom Solder Mask)
:*Apogee_v100_Outline.GBR (Board Outline)
:*Apogee_v100_Drill.GBR (NC XY coordinates & Drill tools sizes)

== Assembly ==

===Components Layout===

<gallery>
Image:Apogee_v100_2D_bottom_components.png|Apogee v1.00 bottom components Layout
Image:Apogee_v100_2D_top_components.png|Apogee v1.00 top components Layout
Image:Apogee_v100_bottom_components.png|Apogee v1.00 bottom components detail
Image:Apogee_v100_top_components.png|Apogee v1.00 top components detail
</gallery>

=== Bill Of Material ===

'''''[[Media:Apogee_v100_BoM.zip|Download Apogee v1.00 Bill of Material (zipped .xls file)]]'''''
<br>
<br>

=== PCB and assembled boards suppliers ===

Check availability on [[Get_Hardware|Get Hardware]] page

== Mechanical Dimensions ==
[[Image:Apogee_v100_top_mechanical_dimensions.png|500px|Apogee v1.00 Top Mechanical Dimensions]]
[[Image:Apogee_v100_side_mechanical_dimensions.png|500px|Apogee v1.00 Side Mechanical Dimensions]]

== Programming ==
Apogee autopilot can reprogrammed in two different ways:

* using the MCU native (embedded in rom) DFU USB bootloader over the on-board USB header (so pre-loading an "external" bootloader is useless)
** required hardware : usb cable with usb-mini connector
** required software : dfu_util tool (present in ubuntu repository)
* using the SWD (Serial Wire Debug) connector
** required hardware : usb cable with usb-mini connector, molex to 2.54mm pitch pin cable, swd part of a cheap stm32 evaluation board (any discovery board, start @ 8$)
** required software : st_flash and st_util, have to be compiled from source (https://github.com/texane/stlink)

==On-board Data Logging==

It is possible to write data on the embedded SD card from the main autopilot program. In order to cope with a real-time constraints of the autopilot, a light RTOS called [http://http://www.chibios.org ChibiOS] is used to split the logging task from the rest of the system. Two modules are necessary to enable the logging system: the driver of the SD card system that also handle the file system (using FATFS) and a dynamic memory allocation system called TLSF.
In order to enable this features for your apogee board, you need to select the correct board type and add the required modules to the firmware section of your airframe file (logging is currently only available for '''fixedwing''' firmware):

<firmware name="firmware">
...
<target name="ap" board="apogee_1.0_chibios">
...
</target>
...
<module name="tlsf"/>
<module name="logger" type="sd_chibios"/>
</firmware>

This will active the automatic opening of a new log file (30 seconds) after each startup of the autopilot. Then you can freely write ASCII or binary data into this file (see a simple example logging for [https://github.com/paparazzi/paparazzi/blob/master/sw/airborne/modules/meteo/mf_ptu.c meteorological data logging]).
The file is '''automatically''' closed upon battery disconnection, no need to press any button to stop the logging.

To recover the data on the SD card, just power up the board '''without''' the USB plugged (otherwise it will enter in DFU boot mode), then plus the USB cable to the board and to your computer. This will stop the main autopilot program and will mount the SD card as a regular mass storage with a FAT file system. The log files are placed in a PPRZ folder. Unplugging the USB will reset the autopilot.

In addition to this, you can also load a [http://docs.paparazziuav.org/latest/module__flight_recorder.html '''flight recorder''' module] (it also needs the '''pprzlog''' module for supporting the specific paparazzi binary log format).

<firmware>
...
<module name="pprzlog"/>
<module name="flight_recorder"/>
...
</firmware>

with the appropriate telemetry file (conf/telemetry/fixedwing_flight_recorder.xml). This will automatically open a second file where telemetry messages described in the FlightRecorder section of the telemetry file will be logged in [[Data_Logger#Storage_format|binary format]]. The files are store in a separated FR folder on the SD card. The decoding procedure is the same than [[Openlog#Decoding|OpenLog]] and is using the '''sd2log''' tool:

~/paparazzi/sw/logalizer/sd2log [log_file] [optinal_output_dir]

This will produce 3 files: a ''.log'' and a ''.data'' files similar to the normal [[Logs|ground station log]] and ''.tlm'' file that is a simple copy of the binary file (but rename with the same base name than the two others).

==Debugging==

===Debugging with STM Discovery ST-LINK/V2 embedded debug tool===

[[Image:SWD_Discovery_to_Apogee.png|Apogee debugging with Discovery dev board]]

===Debugging with [[CricketProbe/v1.00 | CricketProbe]]===

[[Image:SWD_CricketProbe_to_Apogee.png|800px|Apogee debugging with CricketProbe]]

===Debugging with Black Magic Probe===

[[Image:SWD_BlackMagicProbe_to_Apogee.png|700px|Apogee debugging with Black Magic Probe]]

== Source Files ==

''[[Media:Apogee_v100_Protel_Design.zip|Apogee v1.00 hardware design (zipped Protel99SE SP6 database file)]]''

== Source code ==

Available in latest git master branch

== Where to Buy ==

You can purchase Apogee V1.00 from one of the following stores:
* [http://www.drotek.com/shop/en/home/739-apogee-paparazzi-flight-controller.html Drotek]
* [http://www.droneasy.com/index.php/electronics/flight-controllers-2/paparazzi-apogee.html EasyDrone]
* [http://www.goodluckbuy.com/ppz-paparazzi-apogee-uav-stm32f405-flight-control-for-fpv-quadcopter.html GoodluckBuy (xD)]
* [https://www.alibaba.com/product-detail/paparazzi-apogee-UAV-Flight-Control-ppz_60277228722.html Alibaba]
* [https://item.taobao.com/item.htm?spm=a230r.1.14.19.74a52fefYM2t2B&id=40105908067&ns=1&abbucket=19#detail.html TaoBao]
[[Category:Autopilots]]

Links

2018-07-21T09:50:49Z

Dianzhichong: /* Paparazzi teams/users/contributors */

== Paparazzi Blog ==
There is a blog about Paparazzi and related things at [http://blog.paparazziuav.org blog.paparazziuav.org].

== Paparazzi Youtube and Other Video Site Links ==

http://www.youtube.com/user/USUOSAM

http://www.youtube.com/user/aerovistapunktch

http://www.youtube.com/user/PPZUAV

== Paparazzi teams/users/contributors ==

http://www.caughey.com/uavblog/news.php?id=1

http://www.miraterre.com/index.html

http://mecano.gme.usherb.ca/~vamudes/

http://pfump.org

http://www.akaflieg.hs-bremen.de/

http://www.engr.usu.edu/wiki/index.php/OSAM

http://www.techhopups.com/

http://pixhawk.ethz.ch

http://www.rcgroups.com/forums/showthread.php?t=851820

http://www.rcgroups.com/forums/showthread.php?t=1000937

http://www.mannberg.co.uk/paparazzi/

http://www.rcgroups.com/forums/showthread.php?t=1183008

http://www.ppz-uav.com

http://www.openuas.org/

http://vrhome.net/vassilis/category/paparazzi/

http://y-uav.com

http://www.umars.ch

== WikiNode ==

Related wiki are, as always, listed on the [[WikiNode]].

[[Category:User_Documentation]]

User:Dianzhichong

2015-01-26T15:14:53Z

Dianzhichong:

Name: dianzhichong
Location: China (HeNan)
Reason for starting: I'm model aircraft enthusiasts, found that after the paparazzi in 2011, I was crazy about him! I hope to build up a, he will let my fixed wing aircraft automatic flight, at that time, I began to learn crazy knowledge until now!

Projects: First Project:
In March 2012 I started building his own pterodactyl plane, solve problems PCB, after making a circuit board to factory orders and purchasing electronic components. Now complete welding, neutral adjustment, sensitivity. umarim 1.0 are still in progress......

http://v.youku.com/v_show/id_XNzA2OTEyNzEy.html

ImuCalibration

2014-07-29T00:35:49Z

Dianzhichong: /* Calibrating the Magnetometer */

== Theory ==

Accelerometer and Magnetometer calibration is critical to AHRS performance and can be performed using no special hardware. For Gyrometer calibration you need a very good turnable. For the magnetometer, it is very important that the calibration be performed in the fully assembled vehicle, with all systems powered on. This is called hard-iron calibration and will allow us to compensate for any constant parasitic magnetic fields generated by the vehicle.
The calibration process consists of finding a set of neutrals and scale factors for each sensor, such as

<math>
\begin{pmatrix}physical\_value_x\\physical\_value_y\\physical\_value_z\end{pmatrix} = \begin{pmatrix}sf_x&0&0\\0&sf_y&0\\0&0&sf_z\end{pmatrix} * (\begin{pmatrix}sensor_x\\sensor_y\\sensor_z\end{pmatrix}-\begin{pmatrix}n_x\\n_y\\n_z\end{pmatrix})
</math>

The principle of the calibration is the following: an accelerometer, on a vehicle at rest, measures a constant vector (the opposite of gravity) in the earth frame, expressed in the vehicle frame.

<math>
DCM * \begin{pmatrix}0\\0\\-9.81\end{pmatrix} =
\begin{pmatrix}sf_x&0&0\\0&sf_y&0\\0&0&sf_z\end{pmatrix} * (\begin{pmatrix}sensor_x\\sensor_y\\sensor_z\end{pmatrix}-\begin{pmatrix}n_x\\n_y\\n_z\end{pmatrix})
</math>

DCM is a rotation matrix that converts between earth frame and body frame. It will change when we change the orientation of the vehicle. Nevertheless, a rotation conserves the norm of a vector. We can thus obtain the following scalar equation that doesn't depend on the vehicle orientation :

<math>
9.81^2 = ( sf_x(sensor_x-n_x) )^2 + (sf_y(sensor_y-n_y) )^2 + (sf_z(sensor_z-n_z) )^2
</math>

Where 9.81 is earths average gravity value

We can then record an important number of measurements in different orientations and find the set of scale factors and neutrals giving the norm closest to the average gravity value

=== How It Works ===

* It first makes an initial guess using min and max, i.e. for each axis
** neutral = 0.5 * (max + min)
** sensitivity = 0.5*(max - min)

*It then uses a data fitting algorithm to optimize the initial guess.

Screenshot of Scilab version.
[[Image:calibAccel.png|240px]]

== Calibration Script Installation==
Vital scripts and places:
# Python script to calibrate the accelerometers and magnetometer. The application can be found in the Paparazzi directory under: sw/tools/calibration/calibrate.py
# Before you start calibrating clear log directory (PAPARAZZI_HOME/var/logs), it will greatly simplify log file search process.

For the application to work, however, you need additional Python libraries. If you already have the package '''paparazzi-dev''' installed, the needed libraries were already installed as dependencies.
If this is not the case you need to install '''python-scipy''' and '''python-matplotlib'''. This can be done via Synaptic Package Manager or via the command-line of Ubuntu.

$ sudo apt-get install python-scipy
$ sudo apt-get install python-matplotlib

== How to Calibrate Your IMU ==
Basic procedure:

# Flash the board with your normal AP firmware (if it is not already on it.)
# Switch to the "raw sensors" telemetry mode via ''[[GCS#Settings|GCS->Settings]]->Telemetry'' and launch "server" to record a [[Logs|log]].[[Image:MakeSureToSetRAWsensors.jpg|right|Set RAW Messages]]
# Move your IMU/airframe into different positions to record relevant measurements for each axis.
#* It is important that you get the min/max sensor values on each axis!
# Stop the server so it will write the [[Logs|log file]] (to ''var/logs'').
# Run the Python script on it to get your calibration coefficients and add them to your airframe file.
#* See details/examples for specific sensors below.
#* If you have data from more than one aircraft in your logfile, you will need to specify the aircraft id via the ''--id'' option.<br/>It can be found in the [[Paparazzi_Center|Paparazzi Center]] upper left side. (first comes A/C name, and then id value)

'''Run the script with ''--help'' to list available options:'''
''sw/tools/calibration/calibrate.py --help

=== Calibrating the Accelerometers ===

<div style="float: right; width: 500px; overflow: hidden"><gallery widths=200px heigths=200px>
Image:Aspirin_imu_front_small.jpg|The front of IMU is marked as X axis. Warning! Aspirin 1.5 has x and y silkscreen swapped.
Image:Acc_cailbration.jpg|Orientations during accelerometer calibration
</gallery></div>

TIP: Since accelerometers are very sensitive to vibration distortions, strap your IMU board tight to some heavy object like a big battery. It will help keep the board steady while rotating.

Once your decided to calibrate; take the steps with great care. If not done as precise as you possibly can, than factory calibration values are even better than a poorly calibrated accelerometer.

To calibrate the accelerometers turn and hold the IMU on all six sides of the 'cube' for about 10 seconds per IMU axis:

# upright
# inverted
# on the nose
# on the tail
# on the right side
# on the left side

Please note that we talk about the '''IMU axes''' here, and '''not''' the '''airframe axes'''.<br>So if you have your IMU mounted under a specific angle in your aircraft; make very sure you align the axis of the IMU and '''not''' the '''aircraft axes''' with earth's gravity. Also for the accelerometer calibration the IMU can, but does not need to be mounted inside the airframe. Only the calibration of a magnetometer must be performed while in your aircraft.

You can also take some measurements banking 45 degrees.<br>Try to get a homogeneous distribution of your measurements. It is better to let the aircraft rest while measuring an axis to avoid inaccuracies from shaking the IMU in your hand.

Then stop the server so it will write the log file which must containing the needed '''IMU_ACCEL_RAW''' message values. Then run the Python script using the just newly generated log data as the source to get your calibration coefficients:

Open a terminal window and run:

''<nowiki>sw/tools/calibration/calibrate.py -s ACCEL var/logs/YY_MM_DD__hh_mm_ss.data</nowiki>''

Where YY_MM_DD__hh_mm_ss.data is the name of the log data file that was just generated.

=== Calibrating the Magnetometer ===
First of all it is important to know that all ferromagnetic materials near the mag distort the measurements. So preferably you do the mag calibration with the mag/autopilot mounted in your frame and as far away from metal and magnets as possible.

==== Calibrating for the Earth magnetic field ====

The most crucial part for the magnetometer calibration:

'''Steps:'''

# Slowly spin your aircraft around all axes

Ideally you would '''spin''' it '''around all axes''' until you have densely covered the '''whole sphere''' with magnetometer measurements. Take a look at figure MAG2 on how that would look like.

'''Optional method'''
If this rotation of your whole airframe is to hard to do: One could also just make sure to really get the min/max on each axis by aligning the magnetometer axes along the local magnetic field vector:
# Calculate the inclination and declination of the magnetic field where you live that can be looked up [http://www.ngdc.noaa.gov/geomag-web/#igrfwmm here]. Just put in zip/country+city/coordinates & date to get proper degrees. See MAG1 figure.
# Now point the each mag axis in the direction you got from previous step.

<gallery widths=200px heigths=200px>
Image:Mag_london_inc-dec.jpg|fig. MAG1 - An example for London
</gallery>

TIP:
It can also be convenient to [[RTPlotter|plot]] the ''IMU_MAG_RAW'' values to see when you get the maximum on each axis.
# Launch [[Paparazzi_Center|Paparazzi Center]]->Tools->Realtime_Plotter and Tools->Messages
# Drag&Drop each axis of the ''IMU_MAG_RAW'' message to the Plotter canvas.

After you took all measurements, stop the server so it will write the log file and run the Python script on it to get your calibration coefficients:
''<nowiki>sw/tools/calibration/calibrate.py -s MAG var/logs/YY_MM_DD__hh_mm_ss.data -vp</nowiki>''

Where YY_MM_DD__hh_mm_ss.data is the name of the log data file that was just generated.

The ''-v'' parameter turns on verbose mode, ''-p'' turns on 3D plotting of the results. You can omit them if you don't want this.

This basically does a hard-iron (i.e. offset of the sphere) and soft-iron (i.e. distortion to an ellipsoid) calibration. You can see an example result in Figure MAG2.

<gallery widths=200px heigths=200px>
Image:Mag_fit_3d.png|fig. MAG2 - Measurements fitted to ellipsoid
</gallery>

The magnetic field strength and axis are different depending on where you are in the world, because of this you have to [[Subsystem/ahrs#Local_Magnetic_Field|set the local magnetic field]] of the location you intend to fly. Only if you are using the [[Subsystem/ahrs#Complementary_Euler_.28fixed_point.29|older euler filter]] you have to recalibrate your magnetometer to fly somewhere else on the planet.

==== Calibrating for Current ====

When your aircraft flies, currents are flowing through all the electrical wires in your aircraft. These '''currents induce a magnetic field'''. This can create an offset in the measurement of the magnetic north. That is not what we like to have. Luckily we can compensate for this unwanted side-effect by adding current compensation values to the airframe file. This calibration is mainly interesting if you have an aircraft with electric engine.

TIP: This interference effect can also be reduced by putting the magnetometer somewhere away from power wires and by twisting power wires together.

Before doing this calibration, it is important to disengage any autopilot autonomous control and put it in RC control only mode.

'''Steps:'''
# Set up a current sensor in Paparazzi, or define MILLIAMP_AT_FULL_THROTTLE in your airframe file to enable a current estimation.
# '''Switch to''' telemetry message "'''mag_current_calibration'''" [[Image:MagCurrentCalibrationb_message.jpg|500px|right|Set the message for magneto current calibration]]
# Put your aircraft on the ground and hold it steady
# Slowly ramp up the throttle
# Stop the server

Now the log data is written to log file and we need to do someting with it

Open a terminal and just run the script by entering:

''<nowiki>sw/tools/calibration/calibrate_mag_current.py var/logs/YY_MM_DD__hh_mm_ss.data</nowiki>''

Add the resulting output values from this script to the airframe file in the section IMU, for ''example'':

...

<section name="IMU" prefix="IMU_">

<define name= "MAG_X_CURRENT_COEF" value="0.0591913538739"/>
<define name= "MAG_Y_CURRENT_COEF" value="-0.132912120794"/>
<define name= "MAG_Z_CURRENT_COEF" value="-0.0724604582039"/>

...

Re-compile and upload your airframe again.

You can check if the calibration worked by watching the psi angle as you ramp up the motors while holding your UA steady. Be sure to do this without the control system active.

Note that a '''change''' in you airframe '''configuration''', e.g. other gains make the motors spin faster, or the '''wiring''' will require a full new '''current calibration'''!

=== Calibrating the Gyrometer ===
To [[ImuCalibration/Gyroscopes|calibrate the gyrometer]] you '''need''' a '''turntable''', [[ImuCalibration/Gyroscopes| take a look here]] to see how such a setup would look like and which steps are involved. There is a [[ImuCalibration/Gyroscopes| dedicated page]] for this procedure since the steps are not trivial to perform.

Note that gyrometer neutrals a.k.a. ''bias'', are usually not a problem, since they are set by the AHRS aligner at each startup and some [[Subsystem/ahrs|AHRS algorithms]] continuously estimate the bias during flight.

=== Calibrating Infrared Sensors ===

Put the aircraft in a styrofoam container or completely seal the IR sensors with styrofoam or similar blocks and get a reading of the neutrals for each axis. Also take the gyro neutrals at this time. Update your airframe file, flash the AP and re-check the neutrals.

Using the roll gyro as a worked example: Run up your GCS and ensure it
is communicating with your airframe. Make sure your airframe is roughly
level and that it cannot move. Now run the Messages Tool and the [[RTPlotter|real time plotter]] tool. The messages tool will have lots of flashing lights
indicating when it receives various telemetry packets. In the Messages
tool, Click on Gyro Rates and you should see a list of variables. Click
on Roll_ADC and drag and drop in onto the main window of the Real Time plotter. Now give it a while to build a stable graph.

Once things have been running this way for a while, in the Real Time
Plotter, click on Curves in the menu and select the
1:telemetry:GYRO_RATES:Roll_ADC entry. As you select it, you should see
the average and standard deviation values. We need the average value.
Jot down the number you have. I have -24.536.

Now go edit your airframe file and look for the ADC_ROLL_NEUTRAL value.
In my airframe file the value is 520. As my average value from the Plotter is a
negative figure, it indicates that the roll Neutral is too high, subtract the average value from the present setting. So I edited my airframe file to be 495.464 (520-24.536).

Recompile and reflash (Don't worry about restarting the GCS, The
messages program or the other running processes - they will catch up just
fine after flashing). Once the Board is back up and the plotter continues, reset it from the menu to get rid of the average. Watch it for a while and check that the line and acculmulated average is on or around 0. You are done. Use the same process for the IR sensors!

== Finding and Checking Signs ==

'''For [[Subsystem/imu|supported IMUs]], the correct default signs are already defined in the code.'''

If using a new IMU or sign for yours are not in the code yet, here is the way to find them.

We're calibrating everything relative to the IMU frame - Paparazzi has a parameter to define the orientation of the IMU with respect to the body of the vehicle that we'll use later, once you'll have decided of a good mechanical mounting.

Paparazzi uses North East Down (NED) frame, that is positive x is pointing to the front, positive y to the right and positive z down.

===Accelerometer:===
An accelerometer measures the non gravitational acceleration, that is <math>\ddot{x} - g</math>. <math>g</math> is pointing down, so <math>-g</math> is pointing up. So stop moving, disregard earth rotation and you'll measure <math>-g</math>.

*When your IMU is level you should see x=0 y=0 z=-9.81
*When pitching up -g is aligning with x, so you should see x>0, y=0 and z<0
*When banking left -g is aligning with y, so you should see x=0, y>0 and z<0

===Magnetometer:===
A magnetometer measures the Earth's magnetic field. In the northern hemisphere, this points north and down and in the Southern hemisphere north and up.

Thus in the northern hemisphere:
*When you align your IMU with the direction of north, you should see x>0, y=0, z>0.
*When pitching the IMU down, the magnetic vector is aligning with x, so x should increase and z should decrease to zero.
*If yawing your IMU to the left, the magnetic vector is aligning with y, so y should be positive, x should decrease to zero and z stay positive.

And in the southern hemisphere:
*When you align your IMU with the direction of north, you should see x>0, y=0, z<0
*When pitching the IMU up, the magnetic vector is aligning with x, so x should increase and z should increase towards zero.
*If yawing your IMU to the left, the magnetic vector is aligning with y, so y should be positive, x should decrease to zero and z stay negative.

===Gyrometer:===
You need some turntable to calibrate the scale factors of your gyros. For signs, the definition of the frame gives the following properties:

*When rolling right, <math>p</math> should be positive.
*When pitching up, <math>q</math> should be positive.
*When yawing to the right, <math>r</math> should be positive.

===Verification:===
Switch to AHRS telemetry mode and look for the fields that are prefixed with imu_

*Bank right should give positive phi
*Pitch up should give positive theta
*Yaw right should give increasing psi

*The value you'll see after letting the IMU rest will end up being the "measure" (that is accelerometer and magnetometer.) If those are wrong, the problem is in the calibration of your sensors.
*The values you get while moving the IMU are influenced by the gyros. If what you see is the value going crazy when you move and then stabilizing to something good after you stop moving, the problem is in your gyros.

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

ImuCalibration

2014-07-28T03:06:19Z

Dianzhichong: /* How It Works */

== Theory ==

Accelerometer and Magnetometer calibration is critical to AHRS performance and can be performed using no special hardware. For Gyrometer calibration you need a very good turnable. For the magnetometer, it is very important that the calibration be performed in the fully assembled vehicle, with all systems powered on. This is called hard-iron calibration and will allow us to compensate for any constant parasitic magnetic fields generated by the vehicle.
The calibration process consists of finding a set of neutrals and scale factors for each sensor, such as

<math>
\begin{pmatrix}physical\_value_x\\physical\_value_y\\physical\_value_z\end{pmatrix} = \begin{pmatrix}sf_x&0&0\\0&sf_y&0\\0&0&sf_z\end{pmatrix} * (\begin{pmatrix}sensor_x\\sensor_y\\sensor_z\end{pmatrix}-\begin{pmatrix}n_x\\n_y\\n_z\end{pmatrix})
</math>

The principle of the calibration is the following: an accelerometer, on a vehicle at rest, measures a constant vector (the opposite of gravity) in the earth frame, expressed in the vehicle frame.

<math>
DCM * \begin{pmatrix}0\\0\\-9.81\end{pmatrix} =
\begin{pmatrix}sf_x&0&0\\0&sf_y&0\\0&0&sf_z\end{pmatrix} * (\begin{pmatrix}sensor_x\\sensor_y\\sensor_z\end{pmatrix}-\begin{pmatrix}n_x\\n_y\\n_z\end{pmatrix})
</math>

DCM is a rotation matrix that converts between earth frame and body frame. It will change when we change the orientation of the vehicle. Nevertheless, a rotation conserves the norm of a vector. We can thus obtain the following scalar equation that doesn't depend on the vehicle orientation :

<math>
9.81^2 = ( sf_x(sensor_x-n_x) )^2 + (sf_y(sensor_y-n_y) )^2 + (sf_z(sensor_z-n_z) )^2
</math>

Where 9.81 is earths average gravity value

We can then record an important number of measurements in different orientations and find the set of scale factors and neutrals giving the norm closest to the average gravity value

=== How It Works ===

* It first makes an initial guess using min and max, i.e. for each axis
** neutral = 0.5 * (max + min)
** sensitivity = 0.5*(max - min)

*It then uses a data fitting algorithm to optimize the initial guess.

Screenshot of Scilab version.
[[Image:calibAccel.png|240px]]

== Calibration Script Installation==
Vital scripts and places:
# Python script to calibrate the accelerometers and magnetometer. The application can be found in the Paparazzi directory under: sw/tools/calibration/calibrate.py
# Before you start calibrating clear log directory (PAPARAZZI_HOME/var/logs), it will greatly simplify log file search process.

For the application to work, however, you need additional Python libraries. If you already have the package '''paparazzi-dev''' installed, the needed libraries were already installed as dependencies.
If this is not the case you need to install '''python-scipy''' and '''python-matplotlib'''. This can be done via Synaptic Package Manager or via the command-line of Ubuntu.

$ sudo apt-get install python-scipy
$ sudo apt-get install python-matplotlib

== How to Calibrate Your IMU ==
Basic procedure:

# Flash the board with your normal AP firmware (if it is not already on it.)
# Switch to the "raw sensors" telemetry mode via ''[[GCS#Settings|GCS->Settings]]->Telemetry'' and launch "server" to record a [[Logs|log]].[[Image:MakeSureToSetRAWsensors.jpg|right|Set RAW Messages]]
# Move your IMU/airframe into different positions to record relevant measurements for each axis.
#* It is important that you get the min/max sensor values on each axis!
# Stop the server so it will write the [[Logs|log file]] (to ''var/logs'').
# Run the Python script on it to get your calibration coefficients and add them to your airframe file.
#* See details/examples for specific sensors below.
#* If you have data from more than one aircraft in your logfile, you will need to specify the aircraft id via the ''--id'' option.<br/>It can be found in the [[Paparazzi_Center|Paparazzi Center]] upper left side. (first comes A/C name, and then id value)

'''Run the script with ''--help'' to list available options:'''
''sw/tools/calibration/calibrate.py --help

=== Calibrating the Accelerometers ===

<div style="float: right; width: 500px; overflow: hidden"><gallery widths=200px heigths=200px>
Image:Aspirin_imu_front_small.jpg|The front of IMU is marked as X axis. Warning! Aspirin 1.5 has x and y silkscreen swapped.
Image:Acc_cailbration.jpg|Orientations during accelerometer calibration
</gallery></div>

TIP: Since accelerometers are very sensitive to vibration distortions, strap your IMU board tight to some heavy object like a big battery. It will help keep the board steady while rotating.

Once your decided to calibrate; take the steps with great care. If not done as precise as you possibly can, than factory calibration values are even better than a poorly calibrated accelerometer.

To calibrate the accelerometers turn and hold the IMU on all six sides of the 'cube' for about 10 seconds per IMU axis:

# upright
# inverted
# on the nose
# on the tail
# on the right side
# on the left side

Please note that we talk about the '''IMU axes''' here, and '''not''' the '''airframe axes'''.<br>So if you have your IMU mounted under a specific angle in your aircraft; make very sure you align the axis of the IMU and '''not''' the '''aircraft axes''' with earth's gravity. Also for the accelerometer calibration the IMU can, but does not need to be mounted inside the airframe. Only the calibration of a magnetometer must be performed while in your aircraft.

You can also take some measurements banking 45 degrees.<br>Try to get a homogeneous distribution of your measurements. It is better to let the aircraft rest while measuring an axis to avoid inaccuracies from shaking the IMU in your hand.

Then stop the server so it will write the log file which must containing the needed '''IMU_ACCEL_RAW''' message values. Then run the Python script using the just newly generated log data as the source to get your calibration coefficients:

Open a terminal window and run:

''<nowiki>sw/tools/calibration/calibrate.py -s ACCEL var/logs/YY_MM_DD__hh_mm_ss.data</nowiki>''

Where YY_MM_DD__hh_mm_ss.data is the name of the log data file that was just generated.

=== Calibrating the Magnetometer ===
First of all it is important to know that all ferromagnetic materials near the mag disort the measurements. So preferably you do the mag calibration with the mag/autopilot mounted in your frame and as far away from metal and magnets as possible.

==== Calibrating for the Earth magnetic field ====

The most crucial part for the magnetometer calibration:

'''Steps:'''

# Slowly spin your aircraft around all axes

Ideally you would '''spin''' it '''around all axes''' until you have densely covered the '''whole sphere''' with magnetometer measurements. Take a look at figure MAG2 on how that would look like.

'''Optional method'''
If this rotation of your whole airframe is to hard to do: One could also just make sure to really get the min/max on each axis by aligning the magnetometer axes along the local magnetic field vector:
# Calculate the inclination and declination of the magnetic field where you live that can be looked up [http://www.ngdc.noaa.gov/geomag-web/#igrfwmm here]. Just put in zip/country+city/coordinates & date to get proper degrees. See MAG1 figure.
# Now point the each mag axis in the direction you got from previous step.

<gallery widths=200px heigths=200px>
Image:Mag_london_inc-dec.jpg|fig. MAG1 - An example for London
</gallery>

TIP:
It can also be convenient to [[RTPlotter|plot]] the ''IMU_MAG_RAW'' values to see when you get the maximum on each axis.
# Launch [[Paparazzi_Center|Paparazzi Center]]->Tools->Realtime_Plotter and Tools->Messages
# Drag&Drop each axis of the ''IMU_MAG_RAW'' message to the Plotter canvas.

After you took all measurements, stop the server so it will write the log file and run the Python script on it to get your calibration coefficients:
''<nowiki>sw/tools/calibration/calibrate.py -s MAG var/logs/YY_MM_DD__hh_mm_ss.data -vp</nowiki>''

Where YY_MM_DD__hh_mm_ss.data is the name of the log data file that was just generated.

The ''-v'' parameter turns on verbose mode, ''-p'' turns on 3D plotting of the results. You can omit them if you don't want this.

This basically does a hard-iron (i.e. offset of the sphere) and soft-iron (i.e. distortion to an ellipsoid) calibration. You can see an example result in Figure MAG2.

<gallery widths=200px heigths=200px>
Image:Mag_fit_3d.png|fig. MAG2 - Measurements fitted to ellipsoid
</gallery>

The magnetic field strength and axis are different depending on where you are in the world, because of this you have to [[Subsystem/ahrs#Local_Magnetic_Field|set the local magnetic field]] of the location you intend to fly. Only if you are using the [[Subsystem/ahrs#Complementary_Euler_.28fixed_point.29|older euler filter]] you have to recalibrate your magnetometer to fly somewhere else on the planet.

==== Calibrating for Current ====

When your aircraft flies, currents are flowing through all the electrical wires in your aircraft. These '''currents induce a magnetic field'''. This can create an offset in the measurement of the magnetic north. That is not what we like to have. Luckily we can compensate for this unwanted side-effect by adding current compensation values to the airframe file. This calibration is mainly interesting if you have an aircraft with electric engine.

TIP: This interference effect can also be reduced by putting the magnetometer somewhere away from power wires and by twisting power wires together.

Before doing this calibration, it is important to disengage any autopilot autonomous control and put it in RC control only mode.

'''Steps:'''
# Set up a current sensor in Paparazzi, or define MILLIAMP_AT_FULL_THROTTLE in your airframe file to enable a current estimation.
# '''Switch to''' telemetry message "'''mag_current_calibration'''" [[Image:MagCurrentCalibrationb_message.jpg|500px|right|Set the message for magneto current calibration]]
# Put your aircraft on the ground and hold it steady
# Slowly ramp up the throttle
# Stop the server

Now the log data is written to log file and we need to do someting with it

Open a terminal and just run the script by entering:

''<nowiki>sw/tools/calibration/calibrate_mag_current.py var/logs/YY_MM_DD__hh_mm_ss.data</nowiki>''

Add the resulting output values from this script to the airframe file in the section IMU, for ''example'':

...

<section name="IMU" prefix="IMU_">

<define name= "MAG_X_CURRENT_COEF" value="0.0591913538739"/>
<define name= "MAG_Y_CURRENT_COEF" value="-0.132912120794"/>
<define name= "MAG_Z_CURRENT_COEF" value="-0.0724604582039"/>

...

Re-compile and upload your airframe again.

You can check if the calibration worked by watching the psi angle as you ramp up the motors while holding your UA steady. Be sure to do this without the control system active.

Note that a '''change''' in you airframe '''configuration''', e.g. other gains make the motors spin faster, or the '''wiring''' will require a full new '''current calibration'''!

=== Calibrating the Gyrometer ===
To [[ImuCalibration/Gyroscopes|calibrate the gyrometer]] you '''need''' a '''turntable''', [[ImuCalibration/Gyroscopes| take a look here]] to see how such a setup would look like and which steps are involved. There is a [[ImuCalibration/Gyroscopes| dedicated page]] for this procedure since the steps are not trivial to perform.

Note that gyrometer neutrals a.k.a. ''bias'', are usually not a problem, since they are set by the AHRS aligner at each startup and some [[Subsystem/ahrs|AHRS algorithms]] continuously estimate the bias during flight.

=== Calibrating Infrared Sensors ===

Put the aircraft in a styrofoam container or completely seal the IR sensors with styrofoam or similar blocks and get a reading of the neutrals for each axis. Also take the gyro neutrals at this time. Update your airframe file, flash the AP and re-check the neutrals.

Using the roll gyro as a worked example: Run up your GCS and ensure it
is communicating with your airframe. Make sure your airframe is roughly
level and that it cannot move. Now run the Messages Tool and the [[RTPlotter|real time plotter]] tool. The messages tool will have lots of flashing lights
indicating when it receives various telemetry packets. In the Messages
tool, Click on Gyro Rates and you should see a list of variables. Click
on Roll_ADC and drag and drop in onto the main window of the Real Time plotter. Now give it a while to build a stable graph.

Once things have been running this way for a while, in the Real Time
Plotter, click on Curves in the menu and select the
1:telemetry:GYRO_RATES:Roll_ADC entry. As you select it, you should see
the average and standard deviation values. We need the average value.
Jot down the number you have. I have -24.536.

Now go edit your airframe file and look for the ADC_ROLL_NEUTRAL value.
In my airframe file the value is 520. As my average value from the Plotter is a
negative figure, it indicates that the roll Neutral is too high, subtract the average value from the present setting. So I edited my airframe file to be 495.464 (520-24.536).

Recompile and reflash (Don't worry about restarting the GCS, The
messages program or the other running processes - they will catch up just
fine after flashing). Once the Board is back up and the plotter continues, reset it from the menu to get rid of the average. Watch it for a while and check that the line and acculmulated average is on or around 0. You are done. Use the same process for the IR sensors!

== Finding and Checking Signs ==

'''For [[Subsystem/imu|supported IMUs]], the correct default signs are already defined in the code.'''

If using a new IMU or sign for yours are not in the code yet, here is the way to find them.

We're calibrating everything relative to the IMU frame - Paparazzi has a parameter to define the orientation of the IMU with respect to the body of the vehicle that we'll use later, once you'll have decided of a good mechanical mounting.

Paparazzi uses North East Down (NED) frame, that is positive x is pointing to the front, positive y to the right and positive z down.

===Accelerometer:===
An accelerometer measures the non gravitational acceleration, that is <math>\ddot{x} - g</math>. <math>g</math> is pointing down, so <math>-g</math> is pointing up. So stop moving, disregard earth rotation and you'll measure <math>-g</math>.

*When your IMU is level you should see x=0 y=0 z=-9.81
*When pitching up -g is aligning with x, so you should see x>0, y=0 and z<0
*When banking left -g is aligning with y, so you should see x=0, y>0 and z<0

===Magnetometer:===
A magnetometer measures the Earth's magnetic field. In the northern hemisphere, this points north and down and in the Southern hemisphere north and up.

Thus in the northern hemisphere:
*When you align your IMU with the direction of north, you should see x>0, y=0, z>0.
*When pitching the IMU down, the magnetic vector is aligning with x, so x should increase and z should decrease to zero.
*If yawing your IMU to the left, the magnetic vector is aligning with y, so y should be positive, x should decrease to zero and z stay positive.

And in the southern hemisphere:
*When you align your IMU with the direction of north, you should see x>0, y=0, z<0
*When pitching the IMU up, the magnetic vector is aligning with x, so x should increase and z should increase towards zero.
*If yawing your IMU to the left, the magnetic vector is aligning with y, so y should be positive, x should decrease to zero and z stay negative.

===Gyrometer:===
You need some turntable to calibrate the scale factors of your gyros. For signs, the definition of the frame gives the following properties:

*When rolling right, <math>p</math> should be positive.
*When pitching up, <math>q</math> should be positive.
*When yawing to the right, <math>r</math> should be positive.

===Verification:===
Switch to AHRS telemetry mode and look for the fields that are prefixed with imu_

*Bank right should give positive phi
*Pitch up should give positive theta
*Yaw right should give increasing psi

*The value you'll see after letting the IMU rest will end up being the "measure" (that is accelerometer and magnetometer.) If those are wrong, the problem is in the calibration of your sensors.
*The values you get while moving the IMU are influenced by the gyros. If what you see is the value going crazy when you move and then stabilizing to something good after you stop moving, the problem is in your gyros.

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

Users

2014-02-27T09:55:12Z

Dianzhichong: /* Asia */

Please add yourself to this list if you wish to share who you are and what you are doing with Paparazzi

== Wiki User Pages ==

{| class="wikitable" style="text-align:center;background:black; color:blue"
|+ User Pages
|-
|- style="background:bisque; color:black"
|[http://paparazzi.enac.fr/wiki/User:Dconger Dconger]
|[http://paparazzi.enac.fr/wiki/User:MarcusWolschon MarcusWolschon]
|[http://paparazzi.enac.fr/wiki/User:Alfamyke Alfamyke]
|[http://paparazzi.enac.fr/wiki/User:Danstah Danstah]
|[http://paparazzi.enac.fr/wiki/User:Martinmm Martinmm]
|- style="background:bisque; color:black"
|[http://paparazzi.enac.fr/wiki/User:John_Burt John Burt]
|[http://paparazzi.enac.fr/wiki/User:SilaS SilaS]
|[http://paparazzi.enac.fr/wiki/User:Mecevans Mecevans]
|[http://paparazzi.enac.fr/wiki/User:CSU-FCUAV CSU-FCUAV]
|[http://paparazzi.enac.fr/wiki/User:GPH Pierre-Selim]
|- style="background:bisque; color:black"
|[http://paparazzi.enac.fr/wiki/User:Martinpi martinpi]
|[http://paparazzi.enac.fr/wiki/User:VAMK VAMK]
|[http://paparazzi.enac.fr/wiki/User:EldenC Elden_Crom]
|[http://paparazzi.enac.fr/wiki/User:Rbdavison Bernard Davison]
|[http://paparazzi.enac.fr/wiki/User:jvs84 U of Arizona Autonomous Glider]
|- style="background:bisque; color:black"
|[http://paparazzi.enac.fr/wiki/User:Marc Marc]
|[http://paparazzi.enac.fr/wiki/User:Bu5hm4nn Bu5hm4nn]
|[http://paparazzi.enac.fr/wiki/User:HWal HWal]
|[http://paparazzi.enac.fr/wiki/User:Aerodolphin Rui Costa]
|[http://paparazzi.enac.fr/wiki/User:Scdwyer Stephen Dwyer]
|- style="background:bisque; color:black"
|[http://paparazzi.enac.fr/wiki/User:PaulCox Paul Cox]
|[http://paparazzi.enac.fr/wiki/User:Bruzzlee Bruzzlee]
|[http://paparazzi.enac.fr/wiki/User:Stspies Stspies]
|[http://paparazzi.enac.fr/wiki/User:Mzr Mzr]
|[http://brquad.blogspot.com AGRESSiVA]
|- style="background:bisque; color:black"
|add yourself here
|[http://paparazzi.enac.fr/wiki/User:Martial Martial Châteauvieux]
|[http://paparazzi.enac.fr/wiki/User:Christoph Christoph]
|
|
|}

== Developers ==
See [[Developers]]

== Paparazzi Users sorted geographically ==

===Asia===
{| class="wikitable" style="text-align:center;background:black; color:blue"
|+ Asia
|-
! Name !! Location !! Hardware !! Joined !! Current activities / project status
|- style="background:bisque; color:black"
| [mailto:wzxwyvippt@126.com WANGYAO]|| China || UMARIM,twog,tiny2.11 lisa/m2.0 ||| 2008|| fly with lisa/m2.0 now, fully auto takeoff and landing
|- style="background:bisque; color:black"
| [mailto:zhaojinhust@gmail.com ZHAOJin]|| China || Tiny2.11 ||| 2011|| Just Finished my hand-soldered Tiny2.11 board. Welcome to my blog: freikorps.blogcn.com (CHINESE中文)
|- style="background:bisque; color:black"
| [mailto:laizzb@126.com dianzhichong]|| China || Umarim,apogee ||| 2011|| fly with apogee now,Fixed-wing autonomous flight. Establish QQ group (group No. 5436583) and technology sharing
|- style="background:bisque; color:black"
| [mailto:wangcfan@163.com Wangcfan]|| China || Tiny2.11 ||| 2008 || The beginning, is now in learning phase;Learning in Tiny2.11 using the method of IMU!
|- style="background:bisque; color:black"

| [mailto:mnwxiaobao@gmail.com MNW]|| China || Tiny2.11 ||| 2009 || Just starting,having troubles with parts.
|- style="background:bisque; color:black"
| [mailto:shubhamearly@gmail.com Shubham]|| India || Tiny2.11 ||| 2009 || Writing the configuration code for airframe
|- style="background:bisque; color:black"
| [mailto:mundhra@gmail.com M Mundhra] || India || Tiny 1.3 ||| 2007 || Gain tuning on a flying wing configuration airframe
|- style="background:bisque; color:black"
| [mailto:ngkiangloong_at_hopetechnik.com Jianlun]|| Singapore || TWOG V1 ||| 2008 || trying to get TWOG onto an EasyStar. very much a newbie!
|- style="background:bisque; color:black"
| [mailto:praxmail@gmail.com prashanth] || India || Tiny 2.11 ||| 2008 || 6 autonomous flights till now, currently build a new wing like funjet
|- style="background:bisque; color:black"
| [mailto:spencerpangborn@gmail.com spencer] || Taipei, Taiwan || none ||| 2009 || research for now, hope to take aerial photos of Taipei City soon
|- style="background:bisque; color:black"
| [mailto:benybeejz@gmail.com benybee] || Bandar Lampung, Indonesia || Tiny13 1.1 ||| 2010 || trying to get wing dragon fully autonomous, for aireal photograph and research
|- style="background:bisque; color:black"
| [mailto:iman.shirdareh@gmail.com Iman Shirdareh]|| Iran || YAPA V2,TWOG ||| 2010 || Many flight in AUTO2 by different aircraft(1.7-21Kg)
|- style="background:bisque; color:black"
| [mailto:anilvanjare83@gmail.com Anil vanjare] || India || TWOG, Tiny v2.1,Umarim v10 ||| 2011 || ,Umarim board assembled and tested all are ok on ground, now building a MAV to do test flight using UMARIM, with prashant
|}

===Europe===
{| class="wikitable" style="text-align:center;background:black; color:blue"

! Name !! Location !! Hardware !! Joined !! Current activities / project status

|- style="background:lightgreen; color:black"
|Austria

|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:NeoFromMatrix NeoFromMatrix] || Lower Austria/Vienna, Austria || STM32F4-discovery, LisaMV2 || 2013 || wiki doc, testing with low cost/high performance hardware
|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:Martinpi Martin Piehslinger] || Vienna, Austria || Tiny 2.11 || 2008 || just starting

|- style="background:bisque; color:black"
| [mailto:st.jr_at_gmx.at TomS] || Graz, Austria || Tiny 2.11 ||| 2008 || Starting to complete the wiring for the tiny and then trying to apply it to my TwinStar II.

|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:Mbina Markus Bina] || Lower Austria/Vienna, Austria || LisaMV2 || 2013 || wiki doc, testing with low/medium cost hardware

|- style="background:lightgreen; color:black"
|France

|- style="background:bisque; color:black"
| [mailto:x-microdrones@2007.polytechnique.org X-MicroDrones] || Paris, France || Tiny 2.11, Quad-Tilt-Rotor VTOL ||| 2008 || Wiring completed, first flights soon... We're trying to adapt Paparazzi to a Quad-Tilt-Rotor VTOL able to perform both airplane-like and helicopter-like flights. Working on inertial measurement units implementation.

|- style="background:bisque; color:black"
| [mailto:pvol_at_club.fr Philippe Volivert] || Paris, France || TWOG 2.12, EasyGlider, MPX3030 ||| July 2009 || Working on pan/tilt/roll camera

|- style="background:bisque; color:black"
| [mailto:thibaut.bergal@estaca.eu ESTACA Modélisme] || Paris, France || TWOG 2.11, Swift 2, MC22 ||| January 2010 || Starting

|- style="background:bisque; color:black"
| [mailto:limaiem@gmail.com Imed Limaiem] || Paris, France || TWOG 2.11, EPP-CF FPV ||| January 2010 || flight test; Town pollution measurement;

|- style="background:bisque; color:black"
| [mailto:pauldanielcox_at_gmail_dot_com Paul Cox]
| Toulouse
| Tiny v2.11 || Nov. 2008 || GWS Slow Stick flying in AUTO2 reliably. Starting on stabilized video and payload drops Skype: pauldanielcox Gtalk: [use email]

|- style="background:bisque; color:black"
| [mailto:charles-edmond.bichot@ec-lyon.fr Charles-Edmond Bichot] || Lyon, France || Tiny/YAPA, IR+GPS, XBee/smartphone ||| September 2009 || Teaching projects, solar cells, object detection in video / image

|- style="background:lightgreen; color:black"
|Germany

|- style="background:bisque; color:black"
| [mailto:maik.hoepfel_at_web.de Maik Hoepfel] || Berlin, Germany || TWOG, Borjet Maja, Futaba 9C 35 Mhz ||| August 2009 || Have flown different airframes and am flying a Borjet Maja right now; built a more rugged case and connecting board for PPRZ; taking surveying pictures

|- style="background:bisque; color:black"
| [[User:MarcusWolschon|Marcus Wolschon]] || Freiburg, Germany || Gumstix, Paraplane ||| 2008 || Porting Paparazzi to Linux-Userland with UDP-communication using mesh-networking.
UDP-Downlink working, GPS via GPSD working, Pararazzi in Linux working, Hardware still RC-only due to sensor-soldering-issues

|- style="background:bisque; color:black"
| [[User:Flixr|Felix Ruess]] || Munich, Germany || Lisa/M, Lisa/L, Booz, Twog ||| 2008 || coding more than flying.... unfortunately

|- style="background:bisque; color:black"
| [[User:Christoph|Christoph Niemann]] || Hamburg, Germany || Mini-Quadrotor with HBMini ||| 2010 || Several successful AUTO2-Flights.

|- style="background:bisque; color:black"
| [[User:Martial|Martial Châteauvieux]] || Munich, Germany || Bormatec/Maja with TWOG and IR ||| 2011 || Next test in January 2012, as soon as the weather permits. Hopefully I can switch in AUTO2.
|- style="background:bisque; color:black"
| [[User:Stspies|Steffen Spies]] || Wolfsburg, Germany || Multiplex TwinStar with Tiny V2.11 and IR ||| 2010 || Awaiting first flight.

|- style="background:bisque; color:black"
| [[User:Tobi|Tobias M]] || Germany || Multiplex TwinStar II TWOG v1 and IR/imu ||| 2007 || about 120h of flight tests in Auto2 with IR - coding and testing a new vertical control with airspeed - just changed from IR to Aspirin imu - about 3h Auto2 in that configuration

|- style="background:bisque; color:black"
| [[User:RoN|Rolf N]] || Bremen, Germany || TWOG, YAPA2, analog airspeed, imu ||| 2010 || many AUTO2 flights

|- style="background:bisque; color:black"
| [mailto:rijo1011_at_gmail.com Jochen Rieger] || Karlsruhe, Germany || Bormatec Maja, Lisa/L ||| 2011 || I hope the first flight is coming soon.

|- style="background:lightgreen; color:black"
| Portugal

|- style="background:bisque; color:black"
| [mailto:azoreanuav_at_gmail.com Rui Costa] || Azores, Portugal || Outrunner Twinstar II with Tiny 2.11, Aerocomm datalink, 1W video tx ||| 2008 || Only ground test and software configuration.

|- style="background:bisque; color:black"
| [mailto:muralha_at_gmail.com Nuno Guedes] || Lamego, Portugal || Tiny 2.11 || 2008 || Starting

|- style="background:lightgreen; color:black"
|Switzerland

|- style="background:bisque; color:black"
| [mailto:markggriffin_at_gmail.com MarkG] || Geneva, Switzerland || Modified Tiny v2.11, TWOG v1, EeePC as GCS, Multiplex FunJet & EasyStar ||| 2008 || Many successful flights.

|- style="background:bisque; color:black"
| [mailto:spam1_at_marzer.com CedricM] || Geneva, Switzerland || Tiny 2.11, Multiplex FunJet with video camera ||| 2008 || Many successful flights working on an osd module and weather probes.

|- style="background:bisque; color:black"
| [mailto:reto.buettner_at_gmail.com RetoB] || Meilen, Switzerland || TWOG, Tiny 2.11, Cougar, eHawk, Y-UAV, EzOSD, Scherrer UHF ||| 2010 || Many successful flights. See [http://www.aerovista.ch/news.html www.aerovista.ch] and [http://www.y-uav.com www.y-uav.com] for current status.

|- style="background:bisque; color:black"
| [mailto:schmiemi_at_students.zhaw.ch EmilioS] || Winterthur, Switzerland || Tiny 2.11 incl. ArduIMU, Borjet Maja, UMARS||| 2010 || Many successful flights. See [http://www.imes.zhaw.ch/de/engineering/imes/projekte/leichtbautechnik/umars/projektbeschreibung.html UMARS] for current status.

|- style="background:bisque; color:black"
| [mailto:enso@zhaw.ch Oliver E] || Winterthur, Switzerland || Tiny 2.11 incl. ArduIMU, Kyosho Calmato, UMARS||| 2010 || Many Successful flights. A lot of experience as savety pilot. Experience with pich based speed control (best you can have). No programming skills unfortuanatley.

|- style="background:bisque; color:black"
| [mailto:samuelbryner_gmx.ch Samuel B.] || Winterthur, Switzerland || Tiny 2.11, Multiplex Easyglider ||| 2010 || Just starting. No flight so far :/

|- style="background:bisque; color:black"
| [mailto:sjwilks_at_gmail.com Simon W.] || Aarau, Switzerland || TWOG with ArduIMU in Jamara Roo, TWOG on a Telink Tempest flying wing, YAPA2 on a Bormatec Maja, Lisa/L on a Droidworx AD-8 HL ||| 2010 || Many successful flights. See [http://sites.google.com/site/paparazziuav/ http://sites.google.com/site/paparazziuav/].

|- style="background:lightgreen; color:black"
| UK

|- style="background:bisque; color:black"
| [mailto:et@onyxnet.co.uk Alan K] || Middlesbrough, England || Tiny 2.11 & MaxStream ||| 2008 || Just starting.

|- style="background:bisque; color:black"
| [[User:G R|Gareth R]] || Sheffield, UK || Tiny 2.11, video, bunch of helicopters, Multiplex Mentor, Multiplex Funjet, Multiplex Fox, GWS Formosa ||| 2008 || Came 4th in EMAV09 (although won the Golden Balls award for courage in the face of adversity and exceptional partying). Many AUTO2 flights with a camera and XBee868s. Current main airframe is a GWS Formosa (they are so cheap!).

|- style="background:lightgreen; color:black"
| Other

|- style="background:bisque; color:black"
| [mailto:silas_at_silas.hu SilaS] || Budapest || Tiny 1.3,2.11, Twog 1.0 ||| 2007 || Applied tiny to GWS Estarter, finished long travels in AUTO2. Now transfert it to a Twinstar and working on pairing tiny with FPV. Successfull. Now using it on large gliders and jets.

|- style="background:bisque; color:black"
| [mailto:hendrix@gmail.gr| Chris Efstathiou] || Piraeus Hellas || tiny 2.11 on a Mpx EasyGlider, TWOG 1.3 on a Boomerang turbine jet, and my newest toy a X8 with a on camera ||| 2008 || The Easyglider is fully operational, still working on the jet which had his first flight with the TWOG at 25/1/2009

|- style="background:bisque; color:black"
| [[User:openuas|OpenUAS]] || Amsterdam, The Netherlands || TWOG, Tiny, Lisa/L and various airframes || 2007 || Quite a few AUTO2 flights. Improving airspeed, IMU and strong wind integration

|- style="background:bisque; color:black"
| [mailto:sanarlab@yandex.ru Andrew Saenko] || Russia, St-Petersburg || Tiny 1.13, Tiny 2.11, two own hardware designs, 5 kg aerial photo plane, 2.5 kg survelliance uav, Easystar ||| 2007 || Use modified autopilot and GCS in professional tasks, add self desidned IMU

|- style="background:bisque; color:black"
| [mailto:chebuzz_at_gmail.com David "Buzz" Carlson] || Cyprus || Tiny 2.11, Lynx EDF & GWS SloStick, 9XTend datalink ||| 2008 || Quite a few AUTO2 flights. Plane currently grounded due to a TX run-in with a 1 year-old. Currently working on getting new TX and completing CBP store setup.

|- style="background:bisque; color:black"
| [mailto:kostalexis@ece.upatras.gr AneMos-Group] || Patras, Greece || Tiny 2.11, Quadrotor VTOL ||| 2008 || Working on IMU, Trying to implement Constrained Control for the quadrotor trajectory flight

|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:VAMK Allan Ojala (VAMK)] || Vaasa, Finland || TWOG, with AC4790 radio and LEA-5H GPS ||| 2009 || Ditched the SIG Kadet. Built a new big plane TaigaCam. Self-build model made out of EPP and a plastic tube.

|- style="background:bisque; color:black"
| [mailto:alexandru.panait@ral.ro Phineas] || Bucharest, Romania || Tiny2.11 (PPZUAV) ||| November 2009 || Just started to set-up

|- style="background:bisque; color:black"
| [mailto:lukeiron@hotmail.com Luke] || Torino, Italy || TWOG ||| December 2009 || Close to mount the AP on my Mentor
|

|- style="background:bisque; color:black"
| [mailto:helgewal@gmail.com Helge] || Bergen, Norway || TWOG ||| 2009 || First Auto2 flight with Twinstar2 in October 2010
|}

===North America===
{| class="wikitable" style="text-align:center;background:black; color:blue"
|-
! Name !! Location !! Hardware !! Joined !! Current activities / project status

|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:Mcurrie Matthew Currie] || Nanaimo, BC Canada || Tiny 13 v1.1 (Self-built) ||| November 2006 || Funjet + XBee

|- style="background:bisque; color:black"
| [mailto:quill_at_u.washington.edu John Burt] [http://paparazzi.enac.fr/wiki/User:John_Burt wiki page]|| Portland, Oregon || Tiny v2.11 + LEA-4H (PPZUAV), Multiplex Cularis/Easystar, 9Xtend modem, T7CAP TX, ground station: EEE PC701 and/or Nokia N810 ||| Jan 2009 || Initial flight tests w/ Easystar in AUTO1 & AUTO2.

|- style="background:bisque; color:black"
| [mailto:ogar0007@umn.edu Pat O'Gara] || St. Paul, MN || Tiny 2.11 and TWOG (PPZUAV) |||Oct. 2008 || Completed and flown FunJet and Minimag in Auto 2. Currently rebuilding MiniMag as an improved development platform.

|- style="background:bisque; color:black"
| [mailto:kochesj@gvsu.edu John Koches] || Muskegon, Michigan || Tiny 2.11 (PPZUAV) ||| 2007 || currently flying a 48 inch zagi, 80 inch under construction.

|- style="background:bisque; color:black"
| [mailto:Stdeguir@gmail.com Steve Deguir] || New York, New York || Tiny2.11+LEA-5H (PPZUAV), XbeePro 2.4, Berg4L, JR FMA ||| Feb 2009 ||

|- style="background:bisque; color:black"
| [mailto:bmw330i@me.com David Conger] || San Diego (Ramona), California || Tiny1.3 (PPZUAV) ||| Sept 2007 || Flying Wing MAV with onboard video. Test platform for the new 900mhz XBPro 900 RF modems.

|- style="background:bisque; color:black"
| [mailto:mecevans@gmail.com Michael Evans] || Seaside(Monterey Bay), California || Tiny2.11 (PPZUAV) ||| Feb 2009 ||http://www.rcgroups.com/forums/showthread.php?t=1000937.

|- style="background:bisque; color:black"
| USU AggieAir Remote Sensing || Logan, UT || TWOG (PPZUAV) ||| January 2009 || Building 72" Flying Wings which will be used for remote sensing. Routine autonomous flight.

|- style="background:bisque; color:black"
| [http://www.engr.usu.edu/wiki/index.php/OSAM USU OSAM-UAV] || Logan, UT || TWOG (PPZUAV) ||| June 2007 || 2x72" 5x48" 1x60" Flying Wings. Research backyard for AggieAir Remote Sensing. Routine autonomous flight.

|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:CSU-FCUAV CSU Fuel Cell UAV] || Fort Collins, Co || Tiny 2.11 + LEA-5H (PPZUAV), 2.4Ghz XBPro ||| Mar 2009 || Maiden flight complete Feb 28. New Airframe in development.

|- style="background:bisque; color:black"
| [mailto:armz12@gmail.com Armen Gharibans] || La Jolla, California || Tiny2.11 (PPZUAV) ||| March 2009 || UCSD Project with Multiplex Mentor. Completed August 2, 2009. Several Successful Auto2 Flights. A LOT of help from David Conger.

|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:EldenC Elden Crom] || Tucson, AZ || Twog 1.0 ||| July 2009 || Multiplex Twinstar, XBee Pro. Several Successful Auto2 Flights. Working toward precise Auto-Takeoff and Auto-Land

|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:jvs84 U of Arizona Autonomous Glider] || Tucson, AZ || None, will use TWOG 1.0 ||| December 2009 || Super Dimona, Aerocomm. No Flight test. Working toward setting waypoints within Paparazzi code

|- style="background:bisque; color:black"
| [Reegan] || Lubbock, TX || Planning on Tiny 2.11 (PPZUAV), 900mhz XBPro |||Dec. 2009 || Gaining info to begin a collegiate project

|- style="background:bisque; color:black"
| Team UAV UALR Caleb Tenberge || Little Rock, AR || Using TWOG 1.0 ||| Feb 2010 || Using a Telemaster, we are learning the GCS and building our plane.

|- style="background:bisque; color:black"
| [mailto:changho.nam@asu.edu Arizona State University POLY - Capstone Team: Development of UAV /w surveillance System] || Mesa, AZ || Using TINY 2.1 - 2.4GHz Modem, CCD Camera /w 900 MHz Video Transmitter ||| March 2010 || 4-lbs Flying Wings. We made successful autonomous flights.

|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:Scdwyer Stephen Dwyer] || Edmonton, AB, CAN || Nothing Yet ||| Jan 2011 || Obtaining Hardware

|- style="background:bisque; color:black"
| [mailto:muratagenc@yahoo.com Murat A. Genc] || New York, NY || not decided yet ||| May 2011 || just started

|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/UAlberta_UASGroup University of Alberta UAS Group] || Edmonton, AB, CAN || TWOG 1.0, Asprin IMU ||| Aug 2011 || Completing tuning flights in Auto 1 on a Senior Telemaster with 26cc gas engine. Working towards a stable platform for research.

|- style="background:bisque; color:black"
| [mailto:piotr@esden.net Piotr Esden-Tempski] || Santa Cruz, CA || Lisa/L, Lisa/M, Aspirin, Quadshot, Rotorcraft ||| 2009 || Software and Hardware development as well as [http://thequadshot.com The Quadshot]

|- style="background:bisque; color:black"
| [http://clubs.asua.arizona.edu/~mavclub University of Arizona MAV] || Tucson, AZ || Lisa/M 2.0, Aspirin v2.0, uBlox MAX-6Q, XBee 900 Pro/868LP, Mini-Vertigo ||| 2005 || University of Arizona Micro Air Vehicle Club (competing in IMAVs with Paparazzi since 2003.)

|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:Cwozny Chris Wozny] || Nashua, New Hampshire || Lisa/M, Aspirin ||| 2008 || Currently building quadcopter around Lisa/M 2.0 platform.

|- style="background:bisque; color:black"
| New User || 1 || 2 ||| 3 || 4
|}

===Central America===
{| class="wikitable" style="text-align:center;background:black; color:blue"
! Name !! Location !! Hardware !! Joined !! Current activities / project status
|- style="background:bisque; color:black"
| [mailto:joschau@comcast.net Joekadet] || David Panama' || Tiny v2.11/LEA-4P, RF Modems XBee Pro 2.4 GHz (PPZUAV). Multiplex Mentor ||| 2008 || Seven flights now. Flights 6 & 7 in Auto2. Now only a matter of fine tuning.
|- style="background:bisque; color:black"
| New User || 1 || 2 ||| 3 || 4
|}

===South America===
{| class="wikitable" style="text-align:center;background:black; color:blue"
! Name !! Location !! Hardware !! Joined !! Current activities / project status
|- style="background:bisque; color:black"
| [mailto:gustavoviolato@gmail.com Gustavo Violato] || São José dos Campos, Brasil || Tiny v2.11/LEA-4P, Modem XBee Pro 2.4 GHz Swift II ||| 2009 || Flying autonomously and enjoying it. Planning to use the system for flight test data acquisition and aircraft parameter recognition.
|- style="background:bisque; color:black"
| [mailto:agressiva@hotmail.com Eduardo Lavratti] || Porto Alegre - RS, Brasil || TWOG / BOOZ / LISA-M, UBLOX, Xbee900 60mw||| 2011 || Working with geoprocessing - developping new modules and sensors to paparazzi. [http://brquad.blogspot.com ACCENT AERiALS]
|- style="background:bisque; color:black"
| New User || 1 || 2 ||| 3 || 4
|}

===Australia===
{| class="wikitable" style="text-align:center;background:black; color:blue"
|-
! Name !! Location !! Hardware !! Joined !! Current activities / project status
|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:RH1N0 RH1N0] || Brisbane, QLD || TWOG, Multiplex Easystar, PPZGPS, H.264 live digital video, Ubiquiti modems ||| May 2011 || Multiple AUTO2 flights up to 40 min. Currently testing PPZIMU.
|- style="background:bisque; color:black"
| [mailto:todd_soaring@yahoo.com.au Todd Sandercock] || Adelaide, SA || Tiny v2.11, Multiplex Twinjet, 9Xtend modems ||| Jan 2008 || Completed successful flight testing. Now designing new airframe.
|- style="background:bisque; color:black"
| [mailto:reubenb87@gmail.com Reuben Brown]|| Gawler, SA || Tiny v2.11 ||| May 2009 || Getting the autopilot set up
|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:Rbdavison Bernard Davison] || Neutral Bay, NSW || Tiny v2.11, Vertical + Horizontal IR sensors, XBee PRO modems, Futaba T6EXAP TX, Futaba R136F RX, Funjet, MacBook laptop ||| August 2008 || Several flights in Auto1
|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:Rufus Chris Gough] || Canberra || TWOG v2.11, EZ* || September 09 || not yet airborn
|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:Adam.A Adam Amos] || Sydney, NSW || TWOG, IMU, BORJET MAJA || March 2010 || see [http://www.rescuerobotics.com.au www.rescuerobotics.com.au] for current status
|}

===Africa===
{| class="wikitable" style="text-align:center;background:black; color:blue"
! Name !! Location !! Hardware !! Joined !! Current activities / project status
|- style="background:bisque; color:black"
| [mailto:w1_th@yahoo.com W1th] || South Africa KZN || TWOG V1 ,LEA-5H GPS , RF Modems XBee Pro 868 (CheBuzz) ||| July 2009 || Got TWOG,GPS etc interfacing with Laptop and working , Have not done anything to it recently but...Made a website [http://sites.google.com/site/scarfclub/paparazi-uav SCARF Paparazzi-UAV] of my struggle ...
|- style="background:bisque; color:black"
| [mailto:willie.smit@nwu.ac.za Willie Smit] || South Africa NW || Tiny v2.11, LEA-4P GPS, RF Modems XBee Pro ||| April 2010 || We are currently doing test flights. Also doing research on obstacle avoidance.
|- style="background:bisque; color:black"
|}

==Need help adding your information?==
To have your information added by another paparazzi user, please send me an [http://www.rcgroups.com/forums/showpost.php?p=6575288&postcount=1 EMAIL] at with the
following:

*Name
*Email
*Location
*Hardware
*Join date
*Current activities / project status

[[Category:Community]]

Advanced Navigation Routines

2013-12-16T07:40:17Z

Dianzhichong: /* Bungee Takeoff */

= Introduction =

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

= Available navigation modules =

== Navigation Routines (Prev.OSAM) ==

Thanks to Team OSAM contribution these navigation capabilities are 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":

<waypoint name="Center" x="-20.0" y="-160.0"/>
<waypoint name="Edge" x="-10.0" y="-60.0"/>

Then you can add flower to your flight plan:

<block name="Flower">
<call fun="InitializeFlower(WP_Center,WP_Edge)"/>
<call fun="FlowerNav()"/>
</block>

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:

# Defined glide path angle
# In flight changeable landing direction without loosing the glide path angle!
# Smooth intercept, independent of approach angle or wind
# Seperation of approach fix, start decent and top of decent
# With fixed target speed (in airspeed mode only)

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"/>
<define name="DISTANCE_AF_SD" value="20"/>
<define name="TARGET_SPEED" value="14"/>
</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.

Advanced Navigation Routines

2013-12-16T07:32:21Z

Dianzhichong: /* Bungee Takeoff */

= Introduction =

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

= Available navigation modules =

== Navigation Routines (Prev.OSAM) ==

Thanks to Team OSAM contribution these navigation capabilities are 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":

<waypoint name="Center" x="-20.0" y="-160.0"/>
<waypoint name="Edge" x="-10.0" y="-60.0"/>

Then you can add flower to your flight plan:

<block name="Flower">
<call fun="InitializeFlower(WP_Center,WP_Edge)"/>
<call fun="FlowerNav()"/>
</block>

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

# Defined glide path angle
# In flight changeable landing direction without loosing the glide path angle!
# Smooth intercept, independent of approach angle or wind
# Seperation of approach fix, start decent and top of decent
# With fixed target speed (in airspeed mode only)

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"/>
<define name="DISTANCE_AF_SD" value="20"/>
<define name="TARGET_SPEED" value="14"/>
</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.

Tuning

2013-05-06T05:20:43Z

Dianzhichong: /* Sample/Simple Altitude and Throttle Loop */

This page provides some tips and guidelines for tuning a new aircraft. Be sure to familiarize yourself with the theory of [[Theory_of_Operation#PID|PID Controllers]] before you begin. 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.

'''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 MANUAL.
## RC-left is aileron-left and up is up in AUTO1.
## [[Tuning#Directions|turning the plane-left is aileron-right]] and nose-up is elevator-down with RC in neutral in 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 ==

=== Neutrals ===
* Put the aircraft in a styrofoam container or completely seal the IR sensors with styrofoam or similar blocks and get a reading of the neutrals for each axis. Also take the gyro neutrals at this time. Update your airframe file, flash the AP and re-check the neutrals.

Using the roll gyro as a worked example: Run up your GCS and ensure it
is communicating with your airframe. Make sure your airframe is roughly
level and that it cannot move. Now run the Messages Tool and the [[RTPlotter|real time plotter]] tool. The messages tool will have lots of flashing lights
indicating when it receives various telemetry packets. In the Messages
tool, Click on Gyro Rates and you should see a list of variables. Click
on Roll_ADC and drag and drop in onto the main window of the Real Time plotter. Now give it a while to build a stable graph.

Once things have been running this way for a while, in the Real Time
Plotter, click on Curves in the menu and select the
1:telemetry:GYRO_RATES:Roll_ADC entry. As you select it, you should see
the average and standard deviation values. We need the average value.
Jot down the number you have. I have -24.536.

Now go edit your airframe file and look for the ADC_ROLL_NEUTRAL value.
In my airframe file the value is 520. As my average value from the Plotter is a
negative figure, it indicates that the roll Neutral is too high, subtract the average value from the present setting. So I edited my airframe file to be 495.464 (520-24.536).

Recompile and reflash (Don't worry about restarting the GCS, The
messages program or the other running processes - they will catch up just
fine after flashing). Once the Board is back up and the plotter continues, reset it from the menu to get rid of the average. Watch it for a while and check that the line and acculmulated average is on or around 0. You are done. Use the same process for the IR sensors!

=== 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 reveiver data uplink]]

== Auto 2 ==
* Engage 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 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 > 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!

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

Users

2013-04-01T08:47:15Z

Dianzhichong: /* Asia */

Please add yourself to this list if you wish to share who you are and what you are doing with Paparazzi

== Wiki User Pages ==

{| class="wikitable" style="text-align:center;background:black; color:blue"
|+ User Pages
|-
|- style="background:bisque; color:black"
|[http://paparazzi.enac.fr/wiki/User:Dconger Dconger]
|[http://paparazzi.enac.fr/wiki/User:MarcusWolschon MarcusWolschon]
|[http://paparazzi.enac.fr/wiki/User:Alfamyke Alfamyke]
|[http://paparazzi.enac.fr/wiki/User:Danstah Danstah]
|[http://paparazzi.enac.fr/wiki/User:Martinmm Martinmm]
|- style="background:bisque; color:black"
|[http://paparazzi.enac.fr/wiki/User:John_Burt John Burt]
|[http://paparazzi.enac.fr/wiki/User:SilaS SilaS]
|[http://paparazzi.enac.fr/wiki/User:Mecevans Mecevans]
|[http://paparazzi.enac.fr/wiki/User:CSU-FCUAV CSU-FCUAV]
|[http://paparazzi.enac.fr/wiki/User:GPH Pierre-Selim]
|- style="background:bisque; color:black"
|[http://paparazzi.enac.fr/wiki/User:Martinpi martinpi]
|[http://paparazzi.enac.fr/wiki/User:VAMK VAMK]
|[http://paparazzi.enac.fr/wiki/User:EldenC Elden_Crom]
|[http://paparazzi.enac.fr/wiki/User:Rbdavison Bernard Davison]
|[http://paparazzi.enac.fr/wiki/User:jvs84 U of Arizona Autonomous Glider]
|- style="background:bisque; color:black"
|[http://paparazzi.enac.fr/wiki/User:Marc Marc]
|[http://paparazzi.enac.fr/wiki/User:Bu5hm4nn Bu5hm4nn]
|[http://paparazzi.enac.fr/wiki/User:HWal HWal]
|[http://paparazzi.enac.fr/wiki/User:Aerodolphin Rui Costa]
|[http://paparazzi.enac.fr/wiki/User:Scdwyer Stephen Dwyer]
|- style="background:bisque; color:black"
|[http://paparazzi.enac.fr/wiki/User:PaulCox Paul Cox]
|[http://paparazzi.enac.fr/wiki/User:Bruzzlee Bruzzlee]
|[http://paparazzi.enac.fr/wiki/User:Stspies Stspies]
|[http://paparazzi.enac.fr/wiki/User:Mzr Mzr]
|[http://brquad.blogspot.com AGRESSiVA]
|- style="background:bisque; color:black"
|add yourself here
|[http://paparazzi.enac.fr/wiki/User:Martial Martial Châteauvieux]
|[http://paparazzi.enac.fr/wiki/User:Christoph Christoph]
|
|
|}

== Developers ==
See [[Developers]]

== Paparazzi Users sorted geographically ==

===Asia===
{| class="wikitable" style="text-align:center;background:black; color:blue"
|+ Asia
|-
! Name !! Location !! Hardware !! Joined !! Current activities / project status
|- style="background:bisque; color:black"
| [mailto:wzxwyvippt@126.com WANGYAO]|| China || UMARIM,twog,tiny2.11 lisa/m2.0 ||| 2008|| fly with lisa/m2.0 now, fully auto takeoff and landing
|- style="background:bisque; color:black"
| [mailto:zhaojinhust@gmail.com ZHAOJin]|| China || Tiny2.11 ||| 2011|| Just Finished my hand-soldered Tiny2.11 board. Welcome to my blog: freikorps.blogcn.com (CHINESE中文)
|- style="background:bisque; color:black"
| [mailto:laizzb@126.com dianzhichong]|| China || Umarim ||| 2011|| Fixed-wing autonomous flight. Establish QQ group (group No. 5436583) and technology sharing
|- style="background:bisque; color:black"
| [mailto:wangcfan@163.com Wangcfan]|| China || Tiny2.11 ||| 2008 || The beginning, is now in learning phase;Learning in Tiny2.11 using the method of IMU!
|- style="background:bisque; color:black"

| [mailto:mnwxiaobao@gmail.com MNW]|| China || Tiny2.11 ||| 2009 || Just starting,having troubles with parts.
|- style="background:bisque; color:black"
| [mailto:shubhamearly@gmail.com Shubham]|| India || Tiny2.11 ||| 2009 || Writing the configuration code for airframe
|- style="background:bisque; color:black"
| [mailto:mundhra@gmail.com M Mundhra] || India || Tiny 1.3 ||| 2007 || Gain tuning on a flying wing configuration airframe
|- style="background:bisque; color:black"
| [mailto:ngkiangloong_at_hopetechnik.com Jianlun]|| Singapore || TWOG V1 ||| 2008 || trying to get TWOG onto an EasyStar. very much a newbie!
|- style="background:bisque; color:black"
| [mailto:praxmail@gmail.com prashanth] || India || Tiny 2.11 ||| 2008 || 6 autonomous flights till now, currently build a new wing like funjet
|- style="background:bisque; color:black"
| [mailto:spencerpangborn@gmail.com spencer] || Taipei, Taiwan || none ||| 2009 || research for now, hope to take aerial photos of Taipei City soon
|- style="background:bisque; color:black"
| [mailto:benybeejz@gmail.com benybee] || Bandar Lampung, Indonesia || Tiny13 1.1 ||| 2010 || trying to get wing dragon fully autonomus, for aireal photograph and research
|- style="background:bisque; color:black"
| [mailto:anilvanjare83@gmail.com Anil vanjare] || India || TWOG, Tiny v2.1,Umarim v10 ||| 2011 || ,Umarim board assembled and tested all are ok on ground, now building a MAV to do test flight using UMARIM, with prashant
|}

===Europe===
{| class="wikitable" style="text-align:center;background:black; color:blue"

! Name !! Location !! Hardware !! Joined !! Current activities / project status

|- style="background:lightgreen; color:black"
|Austria

|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:Martinpi Martin Piehslinger] || Vienna, Austria || Tiny 2.11 || 2008 || just starting

|- style="background:bisque; color:black"
| [mailto:st.jr_at_gmx.at TomS] || Graz, Austria || Tiny 2.11 ||| 2008 || Starting to complete the wiring for the tiny and then trying to apply it to my TwinStar II.

|- style="background:lightgreen; color:black"
|France

|- style="background:bisque; color:black"
| [mailto:x-microdrones@2007.polytechnique.org X-MicroDrones] || Paris, France || Tiny 2.11, Quad-Tilt-Rotor VTOL ||| 2008 || Wiring completed, first flights soon... We're trying to adapt Paparazzi to a Quad-Tilt-Rotor VTOL able to perform both airplane-like and helicopter-like flights. Working on inertial measurement units implementation.

|- style="background:bisque; color:black"
| [mailto:pvol_at_club.fr Philippe Volivert] || Paris, France || TWOG 2.12, EasyGlider, MPX3030 ||| July 2009 || Working on pan/tilt/roll camera

|- style="background:bisque; color:black"
| [mailto:thibaut.bergal@estaca.eu ESTACA Modélisme] || Paris, France || TWOG 2.11, Swift 2, MC22 ||| January 2010 || Starting

|- style="background:bisque; color:black"
| [mailto:limaiem@gmail.com Imed Limaiem] || Paris, France || TWOG 2.11, EPP-CF FPV ||| January 2010 || flight test; Town pollution measurement;

|- style="background:bisque; color:black"
| [mailto:pauldanielcox_at_gmail_dot_com Paul Cox]
| Toulouse
| Tiny v2.11 || Nov. 2008 || GWS Slow Stick flying in AUTO2 reliably. Starting on stabilized video and payload drops Skype: pauldanielcox Gtalk: [use email]

|- style="background:bisque; color:black"
| [mailto:charles-edmond.bichot@ec-lyon.fr Charles-Edmond Bichot] || Lyon, France || Tiny/YAPA, IR+GPS, XBee/smartphone ||| September 2009 || Teaching projects, solar cells, object detection in video / image

|- style="background:lightgreen; color:black"
|Germany

|- style="background:bisque; color:black"
| [mailto:maik.hoepfel_at_web.de Maik Hoepfel] || Berlin, Germany || TWOG, Borjet Maja, Futaba 9C 35 Mhz ||| August 2009 || Have flown different airframes and am flying a Borjet Maja right now; built a more rugged case and connecting board for PPRZ; taking surveying pictures

|- style="background:bisque; color:black"
| [[User:MarcusWolschon|Marcus Wolschon]] || Freiburg, Germany || Gumstix, Paraplane ||| 2008 || Porting Paparazzi to Linux-Userland with UDP-communication using mesh-networking.
UDP-Downlink working, GPS via GPSD working, Pararazzi in Linux working, Hardware still RC-only due to sensor-soldering-issues

|- style="background:bisque; color:black"
| [[User:Flixr|Felix Ruess]] || Munich, Germany || Lisa/M, Lisa/L, Booz, Twog ||| 2008 || coding more than flying.... unfortunately

|- style="background:bisque; color:black"
| [[User:TheJJ|Jonas Jelten]] || Augsburg, Germany || just our airframe ||| 2010 || "P-Seminar" for the new G8 at our Gymnasium ([http://www.solarflugzeug.de.tc solarflugzeug.de.tc])

|- style="background:bisque; color:black"
| [[User:Christoph|Christoph Niemann]] || Bremen, Germany || Reely Condor with TWOG and Sparkfun Razor-IMU ||| 2010 || Several successful AUTO2-Flights.

|- style="background:bisque; color:black"
| [[User:Martial|Martial Châteauvieux]] || Munich, Germany || Bormatec/Maja with TWOG and IR ||| 2011 || Next test in January 2012, as soon as the weather permits. Hopefully I can switch in AUTO2.
|- style="background:bisque; color:black"
| [[User:Stspies|Steffen Spies]] || Wolfsburg, Germany || Multiplex TwinStar with Tiny V2.11 and IR ||| 2010 || Awaiting first flight.

|- style="background:bisque; color:black"
| [[User:Tobi|Tobias M]] || Germany || Multiplex TwinStar II TWOG v1 and IR/imu ||| 2007 || about 120h of flight tests in Auto2 with IR - coding and testing a new vertical control with airspeed - just changed from IR to Aspirin imu - about 3h Auto2 in that configuration

|- style="background:bisque; color:black"
| [[User:RoN|Rolf N]] || Bremen, Germany || TWOG, YAPA2, analog airspeed, imu ||| 2010 || many AUTO2 flights

|- style="background:bisque; color:black"
| [mailto:rijo1011_at_gmail.com Jochen Rieger] || Karlsruhe, Germany || Bormatec Maja, Lisa/L ||| 2011 || I hope the first flight is coming soon.

|- style="background:lightgreen; color:black"
| Portugal

|- style="background:bisque; color:black"
| [mailto:azoreanuav_at_gmail.com Rui Costa] || Azores, Portugal || Outrunner Twinstar II with Tiny 2.11, Aerocomm datalink, 1W video tx ||| 2008 || Only ground test and software configuration.

|- style="background:bisque; color:black"
| [mailto:muralha_at_gmail.com Nuno Guedes] || Lamego, Portugal || Tiny 2.11 || 2008 || Starting

|- style="background:lightgreen; color:black"
|Switzerland

|- style="background:bisque; color:black"
| [mailto:markggriffin_at_gmail.com MarkG] || Geneva, Switzerland || Modified Tiny v2.11, TWOG v1, EeePC as GCS, Multiplex FunJet & EasyStar ||| 2008 || Many successful flights.

|- style="background:bisque; color:black"
| [mailto:spam1_at_marzer.com CedricM] || Geneva, Switzerland || Tiny 2.11, Multiplex FunJet with video camera ||| 2008 || Many successful flights working on an osd module and weather probes.

|- style="background:bisque; color:black"
| [mailto:reto.buettner_at_gmail.com RetoB] || Meilen, Switzerland || TWOG, Tiny 2.11, Cougar, eHawk, Y-UAV, EzOSD, Scherrer UHF ||| 2010 || Many successful flights. See [http://www.aerovista.ch/news.html www.aerovista.ch] and [http://www.y-uav.com www.y-uav.com] for current status.

|- style="background:bisque; color:black"
| [mailto:schmiemi_at_students.zhaw.ch EmilioS] || Winterthur, Switzerland || Tiny 2.11 incl. ArduIMU, Borjet Maja, UMARS||| 2010 || Many successful flights. See [http://www.imes.zhaw.ch/de/engineering/imes/projekte/leichtbautechnik/umars/projektbeschreibung.html UMARS] for current status.

|- style="background:bisque; color:black"
| [mailto:enso@zhaw.ch Oliver E] || Winterthur, Switzerland || Tiny 2.11 incl. ArduIMU, Kyosho Calmato, UMARS||| 2010 || Many Successful flights. A lot of experience as savety pilot. Experience with pich based speed control (best you can have). No programming skills unfortuanatley.

|- style="background:bisque; color:black"
| [mailto:samuelbryner_gmx.ch Samuel B.] || Winterthur, Switzerland || Tiny 2.11, Multiplex Easyglider ||| 2010 || Just starting. No flight so far :/

|- style="background:bisque; color:black"
| [mailto:sjwilks_at_gmail.com Simon W.] || Aarau, Switzerland || TWOG with ArduIMU in Jamara Roo, TWOG on a Telink Tempest flying wing, YAPA2 on a Bormatec Maja, Lisa/L on a Droidworx AD-8 HL ||| 2010 || Many successful flights. See [http://sites.google.com/site/paparazziuav/ http://sites.google.com/site/paparazziuav/].

|- style="background:lightgreen; color:black"
| UK

|- style="background:bisque; color:black"
| [mailto:et@onyxnet.co.uk Alan K] || Middlesbrough, England || Tiny 2.11 & MaxStream ||| 2008 || Just starting.

|- style="background:bisque; color:black"
| [[User:G R|Gareth R]] || Sheffield, UK || Tiny 2.11, video, bunch of helicopters, Multiplex Mentor, Multiplex Funjet, Multiplex Fox, GWS Formosa ||| 2008 || Came 4th in EMAV09 (although won the Golden Balls award for courage in the face of adversity and exceptional partying). Many AUTO2 flights with a camera and XBee868s. Current main airframe is a GWS Formosa (they are so cheap!).

|- style="background:lightgreen; color:black"
| Other

|- style="background:bisque; color:black"
| [mailto:silas_at_silas.hu SilaS] || Budapest || Tiny 1.3,2.11, Twog 1.0 ||| 2007 || Applied tiny to GWS Estarter, finished long travels in AUTO2. Now transfert it to a Twinstar and working on pairing tiny with FPV. Successfull. Now using it on large gliders and jets.

|- style="background:bisque; color:black"
| [mailto:hendrix@gmail.gr| Chris Efstathiou] || Piraeus Hellas || tiny 2.11 on a Mpx EasyGlider, TWOG 1.3 on a Boomerang turbine jet, and my newest toy a X8 with a on camera ||| 2008 || The Easyglider is fully operational, still working on the jet which had his first flight with the TWOG at 25/1/2009

|- style="background:bisque; color:black"
| [[User:openuas|OpenUAS]] || Amsterdam, The Netherlands || TWOG, Tiny, Lisa/L and various airframes || 2007 || Quite a few AUTO2 flights. Improving airspeed, IMU and strong wind integration

|- style="background:bisque; color:black"
| [mailto:sanarlab@yandex.ru Andrew Saenko] || Russia, St-Petersburg || Tiny 1.13, Tiny 2.11, two own hardware designs, 5 kg aerial photo plane, 2.5 kg survelliance uav, Easystar ||| 2007 || Use modified autopilot and GCS in professional tasks, add self desidned IMU

|- style="background:bisque; color:black"
| [mailto:chebuzz_at_gmail.com David "Buzz" Carlson] || Cyprus || Tiny 2.11, Lynx EDF & GWS SloStick, 9XTend datalink ||| 2008 || Quite a few AUTO2 flights. Plane currently grounded due to a TX run-in with a 1 year-old. Currently working on getting new TX and completing CBP store setup.

|- style="background:bisque; color:black"
| [mailto:kostalexis@ece.upatras.gr AneMos-Group] || Patras, Greece || Tiny 2.11, Quadrotor VTOL ||| 2008 || Working on IMU, Trying to implement Constrained Control for the quadrotor trajectory flight

|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:VAMK Allan Ojala (VAMK)] || Vaasa, Finland || TWOG, with AC4790 radio and LEA-5H GPS ||| 2009 || Ditched the SIG Kadet. Built a new big plane TaigaCam. Self-build model made out of EPP and a plastic tube.

|- style="background:bisque; color:black"
| [mailto:alexandru.panait@ral.ro Phineas] || Bucharest, Romania || Tiny2.11 (PPZUAV) ||| November 2009 || Just started to set-up

|- style="background:bisque; color:black"
| [mailto:lukeiron@hotmail.com Luke] || Torino, Italy || TWOG ||| December 2009 || Close to mount the AP on my Mentor
|

|- style="background:bisque; color:black"
| [mailto:helgewal@gmail.com Helge] || Bergen, Norway || TWOG ||| 2009 || First Auto2 flight with Twinstar2 in October 2010

|- style="background:bisque; color:black"
| [mailto:kepler0@gmail.com Joaquín] || Málaga, Spain|| TWOG v1, Trex600, Cockpit SX, ArduImuV2, HMC5843 ||| September 2009 || Finished integration (navigation, control, actuators). Missing to realize an automatic engine control.
|}

===North America===
{| class="wikitable" style="text-align:center;background:black; color:blue"
|-
! Name !! Location !! Hardware !! Joined !! Current activities / project status

|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:Mcurrie Matthew Currie] || Nanaimo, BC Canada || Tiny 13 v1.1 (Self-built) ||| November 2006 || Funjet + XBee

|- style="background:bisque; color:black"
| [mailto:quill_at_u.washington.edu John Burt] [http://paparazzi.enac.fr/wiki/User:John_Burt wiki page]|| Portland, Oregon || Tiny v2.11 + LEA-4H (PPZUAV), Multiplex Cularis/Easystar, 9Xtend modem, T7CAP TX, ground station: EEE PC701 and/or Nokia N810 ||| Jan 2009 || Initial flight tests w/ Easystar in AUTO1 & AUTO2.

|- style="background:bisque; color:black"
| [mailto:ogar0007@umn.edu Pat O'Gara] || St. Paul, MN || Tiny 2.11 and TWOG (PPZUAV) |||Oct. 2008 || Completed and flown FunJet and Minimag in Auto 2. Currently rebuilding MiniMag as an improved development platform.

|- style="background:bisque; color:black"
| [mailto:kochesj@gvsu.edu John Koches] || Muskegon, Michigan || Tiny 2.11 (PPZUAV) ||| 2007 || currently flying a 48 inch zagi, 80 inch under construction.

|- style="background:bisque; color:black"
| [mailto:Stdeguir@gmail.com Steve Deguir] || New York, New York || Tiny2.11+LEA-5H (PPZUAV), XbeePro 2.4, Berg4L, JR FMA ||| Feb 2009 ||

|- style="background:bisque; color:black"
| [mailto:bmw330i@me.com David Conger] || San Diego (Ramona), California || Tiny1.3 (PPZUAV) ||| Sept 2007 || Flying Wing MAV with onboard video. Test platform for the new 900mhz XBPro 900 RF modems.

|- style="background:bisque; color:black"
| [mailto:mecevans@gmail.com Michael Evans] || Seaside(Monterey Bay), California || Tiny2.11 (PPZUAV) ||| Feb 2009 ||http://www.rcgroups.com/forums/showthread.php?t=1000937.

|- style="background:bisque; color:black"
| USU AggieAir Remote Sensing || Logan, UT || TWOG (PPZUAV) ||| January 2009 || Building 72" Flying Wings which will be used for remote sensing. Routine autonomous flight.

|- style="background:bisque; color:black"
| [http://www.engr.usu.edu/wiki/index.php/OSAM USU OSAM-UAV] || Logan, UT || TWOG (PPZUAV) ||| June 2007 || 2x72" 5x48" 1x60" Flying Wings. Research backyard for AggieAir Remote Sensing. Routine autonomous flight.

|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:CSU-FCUAV CSU Fuel Cell UAV] || Fort Collins, Co || Tiny 2.11 + LEA-5H (PPZUAV), 2.4Ghz XBPro ||| Mar 2009 || Maiden flight complete Feb 28. New Airframe in development.

|- style="background:bisque; color:black"
| [mailto:armz12@gmail.com Armen Gharibans] || La Jolla, California || Tiny2.11 (PPZUAV) ||| March 2009 || UCSD Project with Multiplex Mentor. Completed August 2, 2009. Several Successful Auto2 Flights. A LOT of help from David Conger.

|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:EldenC Elden Crom] || Tucson, AZ || Twog 1.0 ||| July 2009 || Multiplex Twinstar, XBee Pro. Several Successful Auto2 Flights. Working toward precise Auto-Takeoff and Auto-Land

|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:jvs84 U of Arizona Autonomous Glider] || Tucson, AZ || None, will use TWOG 1.0 ||| December 2009 || Super Dimona, Aerocomm. No Flight test. Working toward setting waypoints within Paparazzi code

|- style="background:bisque; color:black"
| [Reegan] || Lubbock, TX || Planning on Tiny 2.11 (PPZUAV), 900mhz XBPro |||Dec. 2009 || Gaining info to begin a collegiate project

|- style="background:bisque; color:black"
| Team UAV UALR Caleb Tenberge || Little Rock, AR || Using TWOG 1.0 ||| Feb 2010 || Using a Telemaster, we are learning the GCS and building our plane.

|- style="background:bisque; color:black"
| [mailto:changho.nam@asu.edu Arizona State University POLY - Capstone Team: Development of UAV /w surveillance System] || Mesa, AZ || Using TINY 2.1 - 2.4GHz Modem, CCD Camera /w 900 MHz Video Transmitter ||| March 2010 || 4-lbs Flying Wings. We made successful autonomous flights.

|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:Scdwyer Stephen Dwyer] || Edmonton, AB, CAN || Nothing Yet ||| Jan 2011 || Obtaining Hardware

|- style="background:bisque; color:black"
| [mailto:muratagenc@yahoo.com Murat A. Genc] || New York, NY || not decided yet ||| May 2011 || just started

|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/UAlberta_UASGroup University of Alberta UAS Group] || Edmonton, AB, CAN || TWOG 1.0, Asprin IMU ||| Aug 2011 || Completing tuning flights in Auto 1 on a Senior Telemaster with 26cc gas engine. Working towards a stable platform for research.

|- style="background:bisque; color:black"
| [mailto:piotr@esden.net Piotr Esden-Tempski] || Santa Cruz, CA || Lisa/L, Lisa/M, Aspirin, Quadshot, Rotorcraft ||| 2009 || Software and Hardware development as well as [http://thequadshot.com The Quadshot]

|- style="background:bisque; color:black"
| [http://clubs.asua.arizona.edu/~mavclub University of Arizona MAV] || Tucson, AZ || Lisa/M 2.0, Aspirin v2.0, uBlox MAX-6Q, XBee 900 Pro/868LP, Mini-Vertigo ||| 2005 || University of Arizona Micro Air Vehicle Club (competing in IMAVs with Paparazzi since 2003.)

|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:Cwozny Chris Wozny] || Nashua, New Hampshire || Lisa/M, Aspirin ||| 2008 || Currently building quadcopter around Lisa/M 2.0 platform.

|- style="background:bisque; color:black"
| New User || 1 || 2 ||| 3 || 4
|}

===Central America===
{| class="wikitable" style="text-align:center;background:black; color:blue"
! Name !! Location !! Hardware !! Joined !! Current activities / project status
|- style="background:bisque; color:black"
| [mailto:joschau@comcast.net Joekadet] || David Panama' || Tiny v2.11/LEA-4P, RF Modems XBee Pro 2.4 GHz (PPZUAV). Multiplex Mentor ||| 2008 || Seven flights now. Flights 6 & 7 in Auto2. Now only a matter of fine tuning.
|- style="background:bisque; color:black"
| New User || 1 || 2 ||| 3 || 4
|}

===South America===
{| class="wikitable" style="text-align:center;background:black; color:blue"
! Name !! Location !! Hardware !! Joined !! Current activities / project status
|- style="background:bisque; color:black"
| [mailto:gustavoviolato@gmail.com Gustavo Violato] || São José dos Campos, Brasil || Tiny v2.11/LEA-4P, Modem XBee Pro 2.4 GHz Swift II ||| 2009 || Flying autonomously and enjoying it. Planning to use the system for flight test data acquisition and aircraft parameter recognition.
|- style="background:bisque; color:black"
| [mailto:agressiva@hotmail.com Eduardo Lavratti] || Porto Alegre - RS, Brasil || TWOG / BOOZ / LISA-M, UBLOX, Xbee900 60mw||| 2011 || Working with geoprocessing - developping new modules and sensors to paparazzi. [http://brquad.blogspot.com ACCENT AERiALS]
|- style="background:bisque; color:black"
| New User || 1 || 2 ||| 3 || 4
|}

===Australia===
{| class="wikitable" style="text-align:center;background:black; color:blue"
|-
! Name !! Location !! Hardware !! Joined !! Current activities / project status
|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:RH1N0 RH1N0] || Brisbane, QLD || TWOG, Multiplex Easystar, PPZGPS, H.264 live digital video, Ubiquiti modems ||| May 2011 || Multiple AUTO2 flights up to 40 min. Currently testing PPZIMU.
|- style="background:bisque; color:black"
| [mailto:todd_soaring@yahoo.com.au Todd Sandercock] || Adelaide, SA || Tiny v2.11, Multiplex Twinjet, 9Xtend modems ||| Jan 2008 || Completed successful flight testing. Now designing new airframe.
|- style="background:bisque; color:black"
| [mailto:reubenb87@gmail.com Reuben Brown]|| Gawler, SA || Tiny v2.11 ||| May 2009 || Getting the autopilot set up
|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:Rbdavison Bernard Davison] || Neutral Bay, NSW || Tiny v2.11, Vertical + Horizontal IR sensors, XBee PRO modems, Futaba T6EXAP TX, Futaba R136F RX, Funjet, MacBook laptop ||| August 2008 || Several flights in Auto1
|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:Rufus Chris Gough] || Canberra || TWOG v2.11, EZ* || September 09 || not yet airborn
|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:Adam.A Adam Amos] || Sydney, NSW || TWOG, IMU, BORJET MAJA || March 2010 || see [http://www.rescuerobotics.com.au www.rescuerobotics.com.au] for current status
|}

===Africa===
{| class="wikitable" style="text-align:center;background:black; color:blue"
! Name !! Location !! Hardware !! Joined !! Current activities / project status
|- style="background:bisque; color:black"
| [mailto:w1_th@yahoo.com W1th] || South Africa KZN || TWOG V1 ,LEA-5H GPS , RF Modems XBee Pro 868 (CheBuzz) ||| July 2009 || Got TWOG,GPS etc interfacing with Laptop and working , Have not done anything to it recently but...Made a website [http://sites.google.com/site/scarfclub/paparazi-uav SCARF Paparazzi-UAV] of my struggle ...
|- style="background:bisque; color:black"
| [mailto:willie.smit@nwu.ac.za Willie Smit] || South Africa NW || Tiny v2.11, LEA-4P GPS, RF Modems XBee Pro ||| April 2010 || We are currently doing test flights. Also doing research on obstacle avoidance.
|- style="background:bisque; color:black"
|}

==Need help adding your information?==
To have your information added by another paparazzi user, please send me an [http://www.rcgroups.com/forums/showpost.php?p=6575288&postcount=1 EMAIL] at with the
following:

*Name
*Email
*Location
*Hardware
*Join date
*Current activities / project status

[[Category:Community]]

Users

2013-04-01T08:46:28Z

Dianzhichong: /* Asia */

Please add yourself to this list if you wish to share who you are and what you are doing with Paparazzi

== Wiki User Pages ==

{| class="wikitable" style="text-align:center;background:black; color:blue"
|+ User Pages
|-
|- style="background:bisque; color:black"
|[http://paparazzi.enac.fr/wiki/User:Dconger Dconger]
|[http://paparazzi.enac.fr/wiki/User:MarcusWolschon MarcusWolschon]
|[http://paparazzi.enac.fr/wiki/User:Alfamyke Alfamyke]
|[http://paparazzi.enac.fr/wiki/User:Danstah Danstah]
|[http://paparazzi.enac.fr/wiki/User:Martinmm Martinmm]
|- style="background:bisque; color:black"
|[http://paparazzi.enac.fr/wiki/User:John_Burt John Burt]
|[http://paparazzi.enac.fr/wiki/User:SilaS SilaS]
|[http://paparazzi.enac.fr/wiki/User:Mecevans Mecevans]
|[http://paparazzi.enac.fr/wiki/User:CSU-FCUAV CSU-FCUAV]
|[http://paparazzi.enac.fr/wiki/User:GPH Pierre-Selim]
|- style="background:bisque; color:black"
|[http://paparazzi.enac.fr/wiki/User:Martinpi martinpi]
|[http://paparazzi.enac.fr/wiki/User:VAMK VAMK]
|[http://paparazzi.enac.fr/wiki/User:EldenC Elden_Crom]
|[http://paparazzi.enac.fr/wiki/User:Rbdavison Bernard Davison]
|[http://paparazzi.enac.fr/wiki/User:jvs84 U of Arizona Autonomous Glider]
|- style="background:bisque; color:black"
|[http://paparazzi.enac.fr/wiki/User:Marc Marc]
|[http://paparazzi.enac.fr/wiki/User:Bu5hm4nn Bu5hm4nn]
|[http://paparazzi.enac.fr/wiki/User:HWal HWal]
|[http://paparazzi.enac.fr/wiki/User:Aerodolphin Rui Costa]
|[http://paparazzi.enac.fr/wiki/User:Scdwyer Stephen Dwyer]
|- style="background:bisque; color:black"
|[http://paparazzi.enac.fr/wiki/User:PaulCox Paul Cox]
|[http://paparazzi.enac.fr/wiki/User:Bruzzlee Bruzzlee]
|[http://paparazzi.enac.fr/wiki/User:Stspies Stspies]
|[http://paparazzi.enac.fr/wiki/User:Mzr Mzr]
|[http://brquad.blogspot.com AGRESSiVA]
|- style="background:bisque; color:black"
|add yourself here
|[http://paparazzi.enac.fr/wiki/User:Martial Martial Châteauvieux]
|[http://paparazzi.enac.fr/wiki/User:Christoph Christoph]
|
|
|}

== Developers ==
See [[Developers]]

== Paparazzi Users sorted geographically ==

===Asia===
{| class="wikitable" style="text-align:center;background:black; color:blue"
|+ Asia
|-
! Name !! Location !! Hardware !! Joined !! Current activities / project status
|- style="background:bisque; color:black"
| [mailto:wzxwyvippt@126.com WANGYAO]|| China || UMARIM,twog,tiny2.11 lisa/m2.0 ||| 2008|| fly with lisa/m2.0 now, fully auto takeoff and landing
|- style="background:bisque; color:black"
| [mailto:zhaojinhust@gmail.com ZHAOJin]|| China || Tiny2.11 ||| 2011|| Just Finished my hand-soldered Tiny2.11 board. Welcome to my blog: freikorps.blogcn.com (CHINESE中文)
|- style="background:bisque; color:black"
| [mailto:laizzb@126.com dianzhichong]|| China || Umarim ||| 2011|| Fixed-wing autonomous flight.Establish QQ group (group No. 5436583) and technology sharing
|- style="background:bisque; color:black"
| [mailto:wangcfan@163.com Wangcfan]|| China || Tiny2.11 ||| 2008 || The beginning, is now in learning phase;Learning in Tiny2.11 using the method of IMU!
|- style="background:bisque; color:black"

| [mailto:mnwxiaobao@gmail.com MNW]|| China || Tiny2.11 ||| 2009 || Just starting,having troubles with parts.
|- style="background:bisque; color:black"
| [mailto:shubhamearly@gmail.com Shubham]|| India || Tiny2.11 ||| 2009 || Writing the configuration code for airframe
|- style="background:bisque; color:black"
| [mailto:mundhra@gmail.com M Mundhra] || India || Tiny 1.3 ||| 2007 || Gain tuning on a flying wing configuration airframe
|- style="background:bisque; color:black"
| [mailto:ngkiangloong_at_hopetechnik.com Jianlun]|| Singapore || TWOG V1 ||| 2008 || trying to get TWOG onto an EasyStar. very much a newbie!
|- style="background:bisque; color:black"
| [mailto:praxmail@gmail.com prashanth] || India || Tiny 2.11 ||| 2008 || 6 autonomous flights till now, currently build a new wing like funjet
|- style="background:bisque; color:black"
| [mailto:spencerpangborn@gmail.com spencer] || Taipei, Taiwan || none ||| 2009 || research for now, hope to take aerial photos of Taipei City soon
|- style="background:bisque; color:black"
| [mailto:benybeejz@gmail.com benybee] || Bandar Lampung, Indonesia || Tiny13 1.1 ||| 2010 || trying to get wing dragon fully autonomus, for aireal photograph and research
|- style="background:bisque; color:black"
| [mailto:anilvanjare83@gmail.com Anil vanjare] || India || TWOG, Tiny v2.1,Umarim v10 ||| 2011 || ,Umarim board assembled and tested all are ok on ground, now building a MAV to do test flight using UMARIM, with prashant
|}

===Europe===
{| class="wikitable" style="text-align:center;background:black; color:blue"

! Name !! Location !! Hardware !! Joined !! Current activities / project status

|- style="background:lightgreen; color:black"
|Austria

|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:Martinpi Martin Piehslinger] || Vienna, Austria || Tiny 2.11 || 2008 || just starting

|- style="background:bisque; color:black"
| [mailto:st.jr_at_gmx.at TomS] || Graz, Austria || Tiny 2.11 ||| 2008 || Starting to complete the wiring for the tiny and then trying to apply it to my TwinStar II.

|- style="background:lightgreen; color:black"
|France

|- style="background:bisque; color:black"
| [mailto:x-microdrones@2007.polytechnique.org X-MicroDrones] || Paris, France || Tiny 2.11, Quad-Tilt-Rotor VTOL ||| 2008 || Wiring completed, first flights soon... We're trying to adapt Paparazzi to a Quad-Tilt-Rotor VTOL able to perform both airplane-like and helicopter-like flights. Working on inertial measurement units implementation.

|- style="background:bisque; color:black"
| [mailto:pvol_at_club.fr Philippe Volivert] || Paris, France || TWOG 2.12, EasyGlider, MPX3030 ||| July 2009 || Working on pan/tilt/roll camera

|- style="background:bisque; color:black"
| [mailto:thibaut.bergal@estaca.eu ESTACA Modélisme] || Paris, France || TWOG 2.11, Swift 2, MC22 ||| January 2010 || Starting

|- style="background:bisque; color:black"
| [mailto:limaiem@gmail.com Imed Limaiem] || Paris, France || TWOG 2.11, EPP-CF FPV ||| January 2010 || flight test; Town pollution measurement;

|- style="background:bisque; color:black"
| [mailto:pauldanielcox_at_gmail_dot_com Paul Cox]
| Toulouse
| Tiny v2.11 || Nov. 2008 || GWS Slow Stick flying in AUTO2 reliably. Starting on stabilized video and payload drops Skype: pauldanielcox Gtalk: [use email]

|- style="background:bisque; color:black"
| [mailto:charles-edmond.bichot@ec-lyon.fr Charles-Edmond Bichot] || Lyon, France || Tiny/YAPA, IR+GPS, XBee/smartphone ||| September 2009 || Teaching projects, solar cells, object detection in video / image

|- style="background:lightgreen; color:black"
|Germany

|- style="background:bisque; color:black"
| [mailto:maik.hoepfel_at_web.de Maik Hoepfel] || Berlin, Germany || TWOG, Borjet Maja, Futaba 9C 35 Mhz ||| August 2009 || Have flown different airframes and am flying a Borjet Maja right now; built a more rugged case and connecting board for PPRZ; taking surveying pictures

|- style="background:bisque; color:black"
| [[User:MarcusWolschon|Marcus Wolschon]] || Freiburg, Germany || Gumstix, Paraplane ||| 2008 || Porting Paparazzi to Linux-Userland with UDP-communication using mesh-networking.
UDP-Downlink working, GPS via GPSD working, Pararazzi in Linux working, Hardware still RC-only due to sensor-soldering-issues

|- style="background:bisque; color:black"
| [[User:Flixr|Felix Ruess]] || Munich, Germany || Lisa/M, Lisa/L, Booz, Twog ||| 2008 || coding more than flying.... unfortunately

|- style="background:bisque; color:black"
| [[User:TheJJ|Jonas Jelten]] || Augsburg, Germany || just our airframe ||| 2010 || "P-Seminar" for the new G8 at our Gymnasium ([http://www.solarflugzeug.de.tc solarflugzeug.de.tc])

|- style="background:bisque; color:black"
| [[User:Christoph|Christoph Niemann]] || Bremen, Germany || Reely Condor with TWOG and Sparkfun Razor-IMU ||| 2010 || Several successful AUTO2-Flights.

|- style="background:bisque; color:black"
| [[User:Martial|Martial Châteauvieux]] || Munich, Germany || Bormatec/Maja with TWOG and IR ||| 2011 || Next test in January 2012, as soon as the weather permits. Hopefully I can switch in AUTO2.
|- style="background:bisque; color:black"
| [[User:Stspies|Steffen Spies]] || Wolfsburg, Germany || Multiplex TwinStar with Tiny V2.11 and IR ||| 2010 || Awaiting first flight.

|- style="background:bisque; color:black"
| [[User:Tobi|Tobias M]] || Germany || Multiplex TwinStar II TWOG v1 and IR/imu ||| 2007 || about 120h of flight tests in Auto2 with IR - coding and testing a new vertical control with airspeed - just changed from IR to Aspirin imu - about 3h Auto2 in that configuration

|- style="background:bisque; color:black"
| [[User:RoN|Rolf N]] || Bremen, Germany || TWOG, YAPA2, analog airspeed, imu ||| 2010 || many AUTO2 flights

|- style="background:bisque; color:black"
| [mailto:rijo1011_at_gmail.com Jochen Rieger] || Karlsruhe, Germany || Bormatec Maja, Lisa/L ||| 2011 || I hope the first flight is coming soon.

|- style="background:lightgreen; color:black"
| Portugal

|- style="background:bisque; color:black"
| [mailto:azoreanuav_at_gmail.com Rui Costa] || Azores, Portugal || Outrunner Twinstar II with Tiny 2.11, Aerocomm datalink, 1W video tx ||| 2008 || Only ground test and software configuration.

|- style="background:bisque; color:black"
| [mailto:muralha_at_gmail.com Nuno Guedes] || Lamego, Portugal || Tiny 2.11 || 2008 || Starting

|- style="background:lightgreen; color:black"
|Switzerland

|- style="background:bisque; color:black"
| [mailto:markggriffin_at_gmail.com MarkG] || Geneva, Switzerland || Modified Tiny v2.11, TWOG v1, EeePC as GCS, Multiplex FunJet & EasyStar ||| 2008 || Many successful flights.

|- style="background:bisque; color:black"
| [mailto:spam1_at_marzer.com CedricM] || Geneva, Switzerland || Tiny 2.11, Multiplex FunJet with video camera ||| 2008 || Many successful flights working on an osd module and weather probes.

|- style="background:bisque; color:black"
| [mailto:reto.buettner_at_gmail.com RetoB] || Meilen, Switzerland || TWOG, Tiny 2.11, Cougar, eHawk, Y-UAV, EzOSD, Scherrer UHF ||| 2010 || Many successful flights. See [http://www.aerovista.ch/news.html www.aerovista.ch] and [http://www.y-uav.com www.y-uav.com] for current status.

|- style="background:bisque; color:black"
| [mailto:schmiemi_at_students.zhaw.ch EmilioS] || Winterthur, Switzerland || Tiny 2.11 incl. ArduIMU, Borjet Maja, UMARS||| 2010 || Many successful flights. See [http://www.imes.zhaw.ch/de/engineering/imes/projekte/leichtbautechnik/umars/projektbeschreibung.html UMARS] for current status.

|- style="background:bisque; color:black"
| [mailto:enso@zhaw.ch Oliver E] || Winterthur, Switzerland || Tiny 2.11 incl. ArduIMU, Kyosho Calmato, UMARS||| 2010 || Many Successful flights. A lot of experience as savety pilot. Experience with pich based speed control (best you can have). No programming skills unfortuanatley.

|- style="background:bisque; color:black"
| [mailto:samuelbryner_gmx.ch Samuel B.] || Winterthur, Switzerland || Tiny 2.11, Multiplex Easyglider ||| 2010 || Just starting. No flight so far :/

|- style="background:bisque; color:black"
| [mailto:sjwilks_at_gmail.com Simon W.] || Aarau, Switzerland || TWOG with ArduIMU in Jamara Roo, TWOG on a Telink Tempest flying wing, YAPA2 on a Bormatec Maja, Lisa/L on a Droidworx AD-8 HL ||| 2010 || Many successful flights. See [http://sites.google.com/site/paparazziuav/ http://sites.google.com/site/paparazziuav/].

|- style="background:lightgreen; color:black"
| UK

|- style="background:bisque; color:black"
| [mailto:et@onyxnet.co.uk Alan K] || Middlesbrough, England || Tiny 2.11 & MaxStream ||| 2008 || Just starting.

|- style="background:bisque; color:black"
| [[User:G R|Gareth R]] || Sheffield, UK || Tiny 2.11, video, bunch of helicopters, Multiplex Mentor, Multiplex Funjet, Multiplex Fox, GWS Formosa ||| 2008 || Came 4th in EMAV09 (although won the Golden Balls award for courage in the face of adversity and exceptional partying). Many AUTO2 flights with a camera and XBee868s. Current main airframe is a GWS Formosa (they are so cheap!).

|- style="background:lightgreen; color:black"
| Other

|- style="background:bisque; color:black"
| [mailto:silas_at_silas.hu SilaS] || Budapest || Tiny 1.3,2.11, Twog 1.0 ||| 2007 || Applied tiny to GWS Estarter, finished long travels in AUTO2. Now transfert it to a Twinstar and working on pairing tiny with FPV. Successfull. Now using it on large gliders and jets.

|- style="background:bisque; color:black"
| [mailto:hendrix@gmail.gr| Chris Efstathiou] || Piraeus Hellas || tiny 2.11 on a Mpx EasyGlider, TWOG 1.3 on a Boomerang turbine jet, and my newest toy a X8 with a on camera ||| 2008 || The Easyglider is fully operational, still working on the jet which had his first flight with the TWOG at 25/1/2009

|- style="background:bisque; color:black"
| [[User:openuas|OpenUAS]] || Amsterdam, The Netherlands || TWOG, Tiny, Lisa/L and various airframes || 2007 || Quite a few AUTO2 flights. Improving airspeed, IMU and strong wind integration

|- style="background:bisque; color:black"
| [mailto:sanarlab@yandex.ru Andrew Saenko] || Russia, St-Petersburg || Tiny 1.13, Tiny 2.11, two own hardware designs, 5 kg aerial photo plane, 2.5 kg survelliance uav, Easystar ||| 2007 || Use modified autopilot and GCS in professional tasks, add self desidned IMU

|- style="background:bisque; color:black"
| [mailto:chebuzz_at_gmail.com David "Buzz" Carlson] || Cyprus || Tiny 2.11, Lynx EDF & GWS SloStick, 9XTend datalink ||| 2008 || Quite a few AUTO2 flights. Plane currently grounded due to a TX run-in with a 1 year-old. Currently working on getting new TX and completing CBP store setup.

|- style="background:bisque; color:black"
| [mailto:kostalexis@ece.upatras.gr AneMos-Group] || Patras, Greece || Tiny 2.11, Quadrotor VTOL ||| 2008 || Working on IMU, Trying to implement Constrained Control for the quadrotor trajectory flight

|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:VAMK Allan Ojala (VAMK)] || Vaasa, Finland || TWOG, with AC4790 radio and LEA-5H GPS ||| 2009 || Ditched the SIG Kadet. Built a new big plane TaigaCam. Self-build model made out of EPP and a plastic tube.

|- style="background:bisque; color:black"
| [mailto:alexandru.panait@ral.ro Phineas] || Bucharest, Romania || Tiny2.11 (PPZUAV) ||| November 2009 || Just started to set-up

|- style="background:bisque; color:black"
| [mailto:lukeiron@hotmail.com Luke] || Torino, Italy || TWOG ||| December 2009 || Close to mount the AP on my Mentor
|

|- style="background:bisque; color:black"
| [mailto:helgewal@gmail.com Helge] || Bergen, Norway || TWOG ||| 2009 || First Auto2 flight with Twinstar2 in October 2010

|- style="background:bisque; color:black"
| [mailto:kepler0@gmail.com Joaquín] || Málaga, Spain|| TWOG v1, Trex600, Cockpit SX, ArduImuV2, HMC5843 ||| September 2009 || Finished integration (navigation, control, actuators). Missing to realize an automatic engine control.
|}

===North America===
{| class="wikitable" style="text-align:center;background:black; color:blue"
|-
! Name !! Location !! Hardware !! Joined !! Current activities / project status

|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:Mcurrie Matthew Currie] || Nanaimo, BC Canada || Tiny 13 v1.1 (Self-built) ||| November 2006 || Funjet + XBee

|- style="background:bisque; color:black"
| [mailto:quill_at_u.washington.edu John Burt] [http://paparazzi.enac.fr/wiki/User:John_Burt wiki page]|| Portland, Oregon || Tiny v2.11 + LEA-4H (PPZUAV), Multiplex Cularis/Easystar, 9Xtend modem, T7CAP TX, ground station: EEE PC701 and/or Nokia N810 ||| Jan 2009 || Initial flight tests w/ Easystar in AUTO1 & AUTO2.

|- style="background:bisque; color:black"
| [mailto:ogar0007@umn.edu Pat O'Gara] || St. Paul, MN || Tiny 2.11 and TWOG (PPZUAV) |||Oct. 2008 || Completed and flown FunJet and Minimag in Auto 2. Currently rebuilding MiniMag as an improved development platform.

|- style="background:bisque; color:black"
| [mailto:kochesj@gvsu.edu John Koches] || Muskegon, Michigan || Tiny 2.11 (PPZUAV) ||| 2007 || currently flying a 48 inch zagi, 80 inch under construction.

|- style="background:bisque; color:black"
| [mailto:Stdeguir@gmail.com Steve Deguir] || New York, New York || Tiny2.11+LEA-5H (PPZUAV), XbeePro 2.4, Berg4L, JR FMA ||| Feb 2009 ||

|- style="background:bisque; color:black"
| [mailto:bmw330i@me.com David Conger] || San Diego (Ramona), California || Tiny1.3 (PPZUAV) ||| Sept 2007 || Flying Wing MAV with onboard video. Test platform for the new 900mhz XBPro 900 RF modems.

|- style="background:bisque; color:black"
| [mailto:mecevans@gmail.com Michael Evans] || Seaside(Monterey Bay), California || Tiny2.11 (PPZUAV) ||| Feb 2009 ||http://www.rcgroups.com/forums/showthread.php?t=1000937.

|- style="background:bisque; color:black"
| USU AggieAir Remote Sensing || Logan, UT || TWOG (PPZUAV) ||| January 2009 || Building 72" Flying Wings which will be used for remote sensing. Routine autonomous flight.

|- style="background:bisque; color:black"
| [http://www.engr.usu.edu/wiki/index.php/OSAM USU OSAM-UAV] || Logan, UT || TWOG (PPZUAV) ||| June 2007 || 2x72" 5x48" 1x60" Flying Wings. Research backyard for AggieAir Remote Sensing. Routine autonomous flight.

|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:CSU-FCUAV CSU Fuel Cell UAV] || Fort Collins, Co || Tiny 2.11 + LEA-5H (PPZUAV), 2.4Ghz XBPro ||| Mar 2009 || Maiden flight complete Feb 28. New Airframe in development.

|- style="background:bisque; color:black"
| [mailto:armz12@gmail.com Armen Gharibans] || La Jolla, California || Tiny2.11 (PPZUAV) ||| March 2009 || UCSD Project with Multiplex Mentor. Completed August 2, 2009. Several Successful Auto2 Flights. A LOT of help from David Conger.

|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:EldenC Elden Crom] || Tucson, AZ || Twog 1.0 ||| July 2009 || Multiplex Twinstar, XBee Pro. Several Successful Auto2 Flights. Working toward precise Auto-Takeoff and Auto-Land

|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:jvs84 U of Arizona Autonomous Glider] || Tucson, AZ || None, will use TWOG 1.0 ||| December 2009 || Super Dimona, Aerocomm. No Flight test. Working toward setting waypoints within Paparazzi code

|- style="background:bisque; color:black"
| [Reegan] || Lubbock, TX || Planning on Tiny 2.11 (PPZUAV), 900mhz XBPro |||Dec. 2009 || Gaining info to begin a collegiate project

|- style="background:bisque; color:black"
| Team UAV UALR Caleb Tenberge || Little Rock, AR || Using TWOG 1.0 ||| Feb 2010 || Using a Telemaster, we are learning the GCS and building our plane.

|- style="background:bisque; color:black"
| [mailto:changho.nam@asu.edu Arizona State University POLY - Capstone Team: Development of UAV /w surveillance System] || Mesa, AZ || Using TINY 2.1 - 2.4GHz Modem, CCD Camera /w 900 MHz Video Transmitter ||| March 2010 || 4-lbs Flying Wings. We made successful autonomous flights.

|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:Scdwyer Stephen Dwyer] || Edmonton, AB, CAN || Nothing Yet ||| Jan 2011 || Obtaining Hardware

|- style="background:bisque; color:black"
| [mailto:muratagenc@yahoo.com Murat A. Genc] || New York, NY || not decided yet ||| May 2011 || just started

|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/UAlberta_UASGroup University of Alberta UAS Group] || Edmonton, AB, CAN || TWOG 1.0, Asprin IMU ||| Aug 2011 || Completing tuning flights in Auto 1 on a Senior Telemaster with 26cc gas engine. Working towards a stable platform for research.

|- style="background:bisque; color:black"
| [mailto:piotr@esden.net Piotr Esden-Tempski] || Santa Cruz, CA || Lisa/L, Lisa/M, Aspirin, Quadshot, Rotorcraft ||| 2009 || Software and Hardware development as well as [http://thequadshot.com The Quadshot]

|- style="background:bisque; color:black"
| [http://clubs.asua.arizona.edu/~mavclub University of Arizona MAV] || Tucson, AZ || Lisa/M 2.0, Aspirin v2.0, uBlox MAX-6Q, XBee 900 Pro/868LP, Mini-Vertigo ||| 2005 || University of Arizona Micro Air Vehicle Club (competing in IMAVs with Paparazzi since 2003.)

|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:Cwozny Chris Wozny] || Nashua, New Hampshire || Lisa/M, Aspirin ||| 2008 || Currently building quadcopter around Lisa/M 2.0 platform.

|- style="background:bisque; color:black"
| New User || 1 || 2 ||| 3 || 4
|}

===Central America===
{| class="wikitable" style="text-align:center;background:black; color:blue"
! Name !! Location !! Hardware !! Joined !! Current activities / project status
|- style="background:bisque; color:black"
| [mailto:joschau@comcast.net Joekadet] || David Panama' || Tiny v2.11/LEA-4P, RF Modems XBee Pro 2.4 GHz (PPZUAV). Multiplex Mentor ||| 2008 || Seven flights now. Flights 6 & 7 in Auto2. Now only a matter of fine tuning.
|- style="background:bisque; color:black"
| New User || 1 || 2 ||| 3 || 4
|}

===South America===
{| class="wikitable" style="text-align:center;background:black; color:blue"
! Name !! Location !! Hardware !! Joined !! Current activities / project status
|- style="background:bisque; color:black"
| [mailto:gustavoviolato@gmail.com Gustavo Violato] || São José dos Campos, Brasil || Tiny v2.11/LEA-4P, Modem XBee Pro 2.4 GHz Swift II ||| 2009 || Flying autonomously and enjoying it. Planning to use the system for flight test data acquisition and aircraft parameter recognition.
|- style="background:bisque; color:black"
| [mailto:agressiva@hotmail.com Eduardo Lavratti] || Porto Alegre - RS, Brasil || TWOG / BOOZ / LISA-M, UBLOX, Xbee900 60mw||| 2011 || Working with geoprocessing - developping new modules and sensors to paparazzi. [http://brquad.blogspot.com ACCENT AERiALS]
|- style="background:bisque; color:black"
| New User || 1 || 2 ||| 3 || 4
|}

===Australia===
{| class="wikitable" style="text-align:center;background:black; color:blue"
|-
! Name !! Location !! Hardware !! Joined !! Current activities / project status
|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:RH1N0 RH1N0] || Brisbane, QLD || TWOG, Multiplex Easystar, PPZGPS, H.264 live digital video, Ubiquiti modems ||| May 2011 || Multiple AUTO2 flights up to 40 min. Currently testing PPZIMU.
|- style="background:bisque; color:black"
| [mailto:todd_soaring@yahoo.com.au Todd Sandercock] || Adelaide, SA || Tiny v2.11, Multiplex Twinjet, 9Xtend modems ||| Jan 2008 || Completed successful flight testing. Now designing new airframe.
|- style="background:bisque; color:black"
| [mailto:reubenb87@gmail.com Reuben Brown]|| Gawler, SA || Tiny v2.11 ||| May 2009 || Getting the autopilot set up
|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:Rbdavison Bernard Davison] || Neutral Bay, NSW || Tiny v2.11, Vertical + Horizontal IR sensors, XBee PRO modems, Futaba T6EXAP TX, Futaba R136F RX, Funjet, MacBook laptop ||| August 2008 || Several flights in Auto1
|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:Rufus Chris Gough] || Canberra || TWOG v2.11, EZ* || September 09 || not yet airborn
|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:Adam.A Adam Amos] || Sydney, NSW || TWOG, IMU, BORJET MAJA || March 2010 || see [http://www.rescuerobotics.com.au www.rescuerobotics.com.au] for current status
|}

===Africa===
{| class="wikitable" style="text-align:center;background:black; color:blue"
! Name !! Location !! Hardware !! Joined !! Current activities / project status
|- style="background:bisque; color:black"
| [mailto:w1_th@yahoo.com W1th] || South Africa KZN || TWOG V1 ,LEA-5H GPS , RF Modems XBee Pro 868 (CheBuzz) ||| July 2009 || Got TWOG,GPS etc interfacing with Laptop and working , Have not done anything to it recently but...Made a website [http://sites.google.com/site/scarfclub/paparazi-uav SCARF Paparazzi-UAV] of my struggle ...
|- style="background:bisque; color:black"
| [mailto:willie.smit@nwu.ac.za Willie Smit] || South Africa NW || Tiny v2.11, LEA-4P GPS, RF Modems XBee Pro ||| April 2010 || We are currently doing test flights. Also doing research on obstacle avoidance.
|- style="background:bisque; color:black"
|}

==Need help adding your information?==
To have your information added by another paparazzi user, please send me an [http://www.rcgroups.com/forums/showpost.php?p=6575288&postcount=1 EMAIL] at with the
following:

*Name
*Email
*Location
*Hardware
*Join date
*Current activities / project status

[[Category:Community]]

User:Dianzhichong

2012-09-06T09:09:53Z

Dianzhichong:

User:Dianzhichong

2012-05-31T02:30:09Z

Dianzhichong:

User:Dianzhichong

2012-05-30T10:05:27Z

Dianzhichong: Created page with "Name: dianzhichong Location: China (HeNan) Reason for starting: Projects: First Project:"

Name: dianzhichong
Location: China (HeNan)
Reason for starting:

Projects: First Project: