PaparazziUAV - User contributions [en]

Papers

2013-03-19T19:26:14Z

Balazs: new publications

__NOTOC__

Some publications about Paparazzi.

===2013===

* ''Multi-Lifting-Device UAV Autonomous Flight at Any Transition Percentage'', Christophe De Wagter, Dirk Dokter, Guido de Croon, Bart Remes. Accepted for publication. EuroGNC2013
* ''Unmanned aircraft system measurements of the atmospheric boundary layer over Terra Nova Bay, Antarctica'', Knuth, S. L., J.J. Cassano, J.A. Maslanik, P.D. Herrmann, P.A. Kernebone, R.I. Crocker, and N.J. Logan; 2013Earth Sys. Sci. Data, accepted, pending revisions
* ''Open Source Autopilot for Academic Research – The Paparazzi System'', Paparazzi Community, Balazs Gati; Proceeding of the American Control Conference 2013, 17-19. Juni 2013, Washington, USA; accepted, under publication

===2012===

* ''Multi-point optimization of a propulsion set as applied to a multi-tasking MAV'', Murat Bronz, Jean-Marc Moschetta, and Gautier Hattenberger. In proceedings of the International Micro Aerial Vehicle Conference and Competition, Germany, July 2012
* ''A "no-flow-sensor" wind estimation algorithm for unmanned aerial systems'', Mayer, Hattenberger, Brisset, Jonassen and Reuder. In International Journal of Micro Air Vehicles, Volume 4, N°1, March 2012
* ''Sub-sampling: Real-time vision for micro air vehicles, Robotics and Autonomous Systems'', G.C.H.E. de Croon, C. De Wagter, B.D.W. Remes, R. Ruijsink; Volume 60, Issue 2, February 2012, Pages 167-181, ISSN 0921-8890

===2011===

* ''Compact helical ring antenna for iridium communication on UAV'',Morlaas, Chabory, Souny and Hattenberger. In proceedings of ETTC 2011, European Test and Telemetry Conference, 14-16 June 2011, Toulouse, France
* ''Seven-Sensor Fast-Response Probe for Full-Scale Wind Turbine Flowfield Measurements'', M. Mansour, G. Kocer, C. Lenherr, N. Chokani and R. S. Abhari,J.; Eng. Gas Turbines Power 133(8), 081601 (Apr 05, 2011)
* ''Differential Flatness and Control of Nonlinear Systems'', Antoine Drouin, Sebastião Simões Cunha, Alexandre C. Brandão Ramos, Felix Mora-Camino; Proceedings of the 30th Chinese Control Conference, July 22-24, 2011, Yantai, China

===2010===

* ''Flying Autonomously to Corsica : A long Endurance Mini-UAV System'', Murat Bronz, Jean-Marc Moschetta and Pascal Brisset. In proceedings of the International Micro Air Vehicle Conference and Flight Competition (IMAV2010) Braunschweig, Germany, 2010
* ''Flight Autonomy of Micro-drone in indoor Environments using LIDAR Flash Camera'', Bertrand Vandeportaele, Aaron Montoya, Simon Lacroix and Gautier Hattenberger. In proccedings of the International Micro Air Vehicle Conference and Flight Competition (IMAV2010) Braunschweig, Germany, 2010
* ''Wintertime observations of an Antarctic polynya with unmanned aerial systems'', Cassano, J.J., J.A. Maslanik, C.J. Zappa, A.L. Gordon, R.I. Cullather, and S.L. Knuth; 2010, EOS, 91, 245-246.
* ''Roll-channel fractional order controller design for a small fixed-wing unmanned aerial vehicle'', Haiyang Chao, Ying Luo, Long Di, Yang Quan Chen; Control Engineering Practice, Volume 18, Issue 7, July 2010, Pages 761-772, ISSN 0967-0661
* ''A 'no-flow-sensor' wind estimation algorithm for Unmanned Aerial Systems'', Mayer, S., G. Hattenenberger, P. Brisset, M. Jonassen, and J. Reuder; 2010, International Journal of Micro Air Vehicles, 4, 1, 19-25.

===2009===

* ''Towards a Long Endurance MAV'', Murat Bronz, Jean-Marc Moschetta, Pascal Brisset and Michel Gorraz. IJMAV Volume 1 – Number4, 2009
* ''Planification de mission pour une patrouille de micro-drones'', P.S. Huard. Phd Thesis. Institut supérieur de l'aéronautique et de l'espace. Toulouse, France, 18 décembre 2009
* ''Planification de mission pour une patrouille de micro-drones'', P.S. Huard, N. Barnier, P.Brisset, and G. Verfaillie. In Proceedings Journées Francophones Planification Décision Apprentissage (JFPDA 2009), Paris, France, 2009
* ''Online mission planning for a swarm of fixed-wing MAV'', P.S. Huard, N. Barnier, P.Brisset, and G. Verfaillie. In Proceedings of the 4rd US-European Competition and Workshop on Micro Air Vehicle (IMAV09), Floride, 2009

===2008===

* ''Multi-UAV control with the Paparazzi system'', P. Brisset and G. Hattenberger. In proceedings of the Conference on Human Operating Unmanned Systems (HUMOUS'08), Brest (France), 2008
* ''SUMO: A Small Unmanned Meteorological Observer for atmospheric boundary layer research'',J. Reuder, P. Brisset, M. Jonassen, M. Müller, and S. Mayer;2008 IOP Conf. Ser.: Earth Environ. Sci. 1 012014
* ''Waypoint Navigation, Stabilization and Sensor Drift'', Antoine Drouin, Andreas Kleinert, Heinrich Warmers; EMAV2008, Braunschweig, Germany

===2007===

* ''Automated mission planning for a fleet of micro air vehicle'', P.S. Huard, N. Barnier, and C. Pralet. In Proc. of the 3rd US-European Competition and Workshop on Micro Air Vehicle and 7th European Micro Air Vehicle Conference and Flight Competition (MAV07), Toulouse, France, 2007
* ''Paparazzi - The Free Autopilot. Build your own UAV'', Antoine Drouin, Martin Muller. In the 24th Chaos Communication Congress, Berlin, 27-30 december 2007
* ''Reengineering the Paparazzi autopilot navigation system'', Brisset, Drouin, Jestin. In proceedings of IAV 2007, Toulouse, 3-5 september 2007
* ''Rotorcraft trajectory tracking by non linear inverse control'', Drouin, Mora Camino, Branda Ramos. In 6th brazilian conference on dynamics, control and their applications, Campus de Sao José do Rio, avril 2007

===2006===

* ''The Paparazzi Solution'', Brisset, Drouin, Gorraz, Huard et Tyler, MAV06, 2006. [http://www.recherche.enac.fr/paparazzi/papers_2006/mav06_paparazzi.pdf Article], [http://www.recherche.enac.fr/paparazzi/papers_2006/mav06_paparazzi_slides.pdf Slides]

===2005===

* ''Systèmes interactifs du drone Paparazzi'', Doscot, Masouri et Poupart, ENAC, 2005. [http://www.recherche.enac.fr/paparazzi/papers_2005/rapport_co_ihm.pdf Report (french)]
* ''Drones'', Brisset et Drouin, journées portes ouvertes ENAC, 2005. [http://www.recherche.enac.fr/paparazzi/papers_2005/jpo_2005.pdf Slides (french)]

===2004===

* ''Création d'une photo aérienne large à partir d'un flux vidéo enregistré par un mini-drone'' M. Tobie, ENAC, 2004. [http://www.recherche.enac.fr/paparazzi/papers_2004/rapport_a_matthieu.pdf Report (french)]
* ''PaparaDzIY : do-it-yourself UAV'' Brisset et Drouin, Journées Micro Drones, Toulouse, 2004. [http://www.recherche.enac.fr/paparazzi/papers_2004/paparadziy.pdf Slides]
* ''Drones et micro-drones'' Brisset et Drouin, CENA, 2004. [http://www.recherche.enac.fr/paparazzi/papers_2004/drones_et_micro_drones.pdf Slides (french)]

===2003===

* ''Calibration d’un capteur IR pour micro drone'' Binas, Deplanche, Hadida, ENAC, 2003. [http://www.recherche.enac.fr/paparazzi/papers_2003/infrared_calib_paper.doc Report (french)] [http://www.recherche.enac.fr/paparazzi/papers_2003/infrared_calib_slides.ppt Slides (french)]

[[Category:Developer_Documentation]] [[Category:Community]]

Failsafe

2012-06-07T06:16:56Z

Balazs: Receiver own failsafe modes and paparazzi

Paparazzi has several built-in failsafe features ranging from lowlevel to highlevel and from implied to optional.

On the lowest level, precise timing of the transmitter pulses creates safety that goes beyond traditional switches enabling safer use of old RC equipment.
On the highest level, the [[Flight_Plans#Exceptions|exceptions]] feature of the flight-plans allow for very flexible custom built failsafe features.

== FBW (Fly By Wire) ==

=== 'Failsafe Switch' ===

The lowest level of paparazzi is the FBW (Fly By Wire) controller that reads the RC, reads the autopilot commands and drives the servo's based on the lowlevel failsafe options.

This is the 'switch' between '''manual''' or '''automatic''' modes. Therefor there is no need for an other failsafe board. Indeed, the paparazzi FBW has evolved with so much intelligence that it is certainly safer than some and probably at least as safe as any other failsafe switches. This is amongst others (besides the highlevel validated code, separated process, ...) because paparazzi FBW unlike generic switches is given precise remote control information in it's RC.xml. If you use a wrong type of transmitter (e.g. not the right amount of channels, or not the correct interval or sync pulse length) than even when on the same frequency the FBW will not listen to the commands. Also, when 2 transmitters should be on the same frequency, then the chance of both signals together still being read as valid is very small. (This does NOT mean you can fly with 2 planes on the same frequency however. This only means that in this catastrophic scenario paparazzi does a pretty good job in delaying disaster from happening. )

* be aware that there exist many failsafe switches that use a pulse of the RC (e.g. channel 5) to switch
between autopilot or RC. When using analog RC equipment or any equipment that does not have correctly
programmed failsafe servo values this is very unsafe as whenever the RC is out of range the switch will
start switching back and forth putting the UAV out of control even if the autpilot is perfectly OK.

CAUTION! Common receivers today (especially 2.4GHz receivers) has own failsafe mode(s). Three mode are used in most cases:
1. No failsafe: the receiver will switch off servo sinals in case of RC connection lost.
Paparazzi own failsafe will be activated in case of RC connection lost.
2. Last position: the receiver will keep the last valid servo positions in case of RC connection lost.
Paparazzi own failsafe will NOT be activated. (The autopilot will not have information on RC signal lost.)
3. Preset servo positions: the receiver will switch servo sinals to a preset value in case of RC connection lost.
This values should be set directly in the receiver. (Read manual.) Paparazzi own failsafe will not be activated.
BUT! If you set the failsafe value of the channel used for Mode control(Manual/Auto1/Auto2) to the value which commands Auto2,
then paparazzi will switch automaticaly to Auto2 mode in case of RC connection lost.

=== FBW logic ===

-RC GOOD: listen to the MODE switch on the Transmitter
(this means whenever the remote control is close enough the pilot has the final word)
-RC BAD: go to automatic mode (see further on for handling of automatic modes)
-RC BAD AND AUTOPILOT DATA TIMEOUT: failsafe command values from airframe configuration XML
(do not omit to fill in useful failsafe values in the command section; usually slight pitch up for minimal speed,
ailerons neutral in order not to roll inverted and of course throttle down: it is not recommended to try to make
turns here with aileron deflections. A small rudder deflection on the other hand is recommended when available )

== AP (AutoPilot) ==

=== Home mode ===

The HOME mode is a failsafe mode where the standard navigation (own flightplan) is suspended and the aircraft
flies a circle around the HOME waypoint at a safe altitude (''security_height'' attribute in your flight-plan). This mode is triggered on different events.
Leaving this mode is done by clicking on the red HOME text in the GCS.

==== Too far from HOME ====

Home mode is triggered if the distance to the HOME waypoint is greater than a threshold ('''max_dist_from_home''' attribute) set in the
fight-plan (displayed as a circle on the GCS map).

==== RC link failure while manual or AUTO1 ====

Home mode is triggered if RC uplink is lost in '''MANUAL''' or '''AUTO 1''' modes.

* When '''MANUAL''' the manual mode is restored as soon as RC link is restored as expected.
* However: In '''AUTO 1''' mode, one must manually leave the HOME mode using the GCS

! Word of caution with respect to '''AUTO1''':
When flying auto1 with a lot of RC interference (which is not recommended anyway), be prepared that the plane might enter HOME mode.
Also, do not be tempted to fly far away in auto1 mode (possibly out of RC range) without a fully tuned auto2 autopilot or sufficient visual contact to allow manual control. As soon as you are so far that RC packets get lost, paparazzi will switch to HOME and will stay in HOME until you choose MANUAL of re-enable AUTO1 on the GCS !

===== Setting RC lost mode =====

By default when RC is lost (in Manual or Auto1) HOME mode is triggered, you can change this behaviour by setting the RC_LOST_MODE:

<define name="RC_LOST_MODE" value="PPRZ_MODE_AUTO2"/>

In this example RC_LOST_MODE is set to AUTO2, which can be useful if you experience glitches on your RC on the mode channel and want the aircraft to continue the mission instead of triggering HOME mode. '''BUT''' only use this if you have AUTO2 navigation set up properly and everything is initialized correctly! An other scenario to set this value if you will fly out of your RC range in a long range mission.

You can disable HOME mode locking by adding the following line in your airframe file:

<define name="UNLOCKED_HOME_MODE" value="TRUE"/>

Then you can restore from HOME mode using the RC and do not need to do this on the GCS if in AUTO1.

'''Caution:''' Use these two settings with care, as they might deteriorate the failsafe security of your aircraft.

=== Kill mode ===

In this mode the throttle is killed (this is the default mode when switching on the autopilot). You can enter this mode manually with the kill button (with confirmation). Kill mode is also triggered in the following cases:

==== Catastrophic battery level ====

If the battery level goes under the catastrophic low level (defined in the airframe file)

==== Way too far from HOME ====

The plane goes into kill mode if it is too far away from the HOME waypoint. You can configure this '''KILL_MODE_DISTANCE''' in your airframe file:

<section name="MISC">
...
<define name="KILL_MODE_DISTANCE" value="(1.5*MAX_DIST_FROM_HOME)"/>
...
</section>

In this example it is set to 1.5 times the '''max_dist_from_home''' (attribute set in your flight plan).

=== GPS signal lost ===

In this mode, the autopilot uses the failsafe roll, pitch and throttle settings defined in the airframe file. It is recommended to disable throttle and make a shallow turn at low flight speed. When barometric information is available and compass heading information, it is recommended to disable this safety mode and train the GCS operator to bring the plane home on heading and altitude only.

Do not mix up the <commands> failsafe_value and the <section name="FAILSAFE" prefix="FAILSAFE_"> default values. The first result in fixed servo positions with the plane totally out of control, while the latter still involve the innerloop to stabilize the plane.

=== Lost datalink communication (optional) ===

This can be done via the a flight-plan exception, e.g. go to the Standby block after 30 seconds:
<exceptions>
...
<exception cond="datalink_time > 30" deroute="Standby"/>
</exceptions>
You also need to include the ''datalink.h'' header file in the header section of your flight plan.

=== Outside mission boundary (optional) ===

Also use exceptions and/or [[Flight_Plans#Call|function calls]] for this.

For an example see ''EMAV2009_safety.xml'' in the directory ''conf/flight_plans'' is an example of a safety procedure that can be included in other flight-plans.
It uses two [[Flight_Plans#Sectors|sectors]] defined in ''EMAV2009_data.xml'', a smaller Green "soft boundary" and a hard boundary defined by the Red sector.
<pre>
<procedure>
<exceptions>
<exception cond="Or(! InsideGreen(GetPosX(), GetPosY()), GetPosAlt() > ground_alt + 150)" deroute="Center"/>
</exceptions>

<blocks>
<block name="Center" pre_call="if (!InsideRed(GetPosX(), GetPosY())) NavKillThrottle();">
<circle wp="_CENTER" radius="DEFAULT_CIRCLE_RADIUS"/>
</block>
</blocks>

</procedure>
</pre>
The first exception deroutes the plane to the Center block below it, if it is outside the Green [[Flight_Plans#Sectors|sector]] or higher than 150m over ground.
While in the Center block the statement in the pre_call function gets evaluated each time, if the plane is now also outside of the Red sector throttle is killed.

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

Sensors/Current

2012-05-21T08:04:57Z

Balazs:

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

It is very easy to get the Paparazzi system working with a current sensor.

Examples are the one from Sparkfun (AttoPilot Voltage and Current Sense Breakout [http://www.sparkfun.com/commerce/product_info.php?products_id=9028 Current sensor]) or a linear hall-effect device such as the Allegro ACS755 or ACS715. The [http://www.teamnovak.com/products/data_logger/2000_sentry/index.html Novak Sentry current sensor] is based on the ACS755LCB-100 hall-effect sensor and has a range of 100A. The smaller and lighter [http://www.pololu.com/catalog/product/1186 Pololu Current Sensor Carrier] is based on the ACS715 with a current of up to 30A.

== Hardware ==

[[Image:Example.jpg|thumb|right|float|Current sensor connected to the TWOG v1]]
Typically, the current sensor is used to measure the current flowing through the main battery (rather than the motor). Connect the + and - pole of the sensor through the battery red lead. The + and - have to be soldered directly.

On the Sparkfun breakout board, a wire is connected to the "VI" pin. It must have a voltage between 0 and 3.3V. On a TWOG v1 or Tiny v2 board, the current sense output wire ("IA" on the Sparkfun sensor) is connected to the ADC_3 (or ADC_4) pin.

On the Novak Sentry current sensor, the red wire is connected to +5 volts. The black wire is ground. The yellow wire is the output (40mV/amp. 0.6v=0amps, 5.0v=110amps) and is connected to the ADC_3 (or ADC_4) pin. [[Image:NovakCurrentSensor.jpg|thumb|right|float|Novak 100A current sensor]]

== Airframe integration ==

In the FIRMWARE section of the airframe file add these lines:

<define name="USE_ADC"/>
<define name="USE_ADC_3"/> 

In the BAT section of the airframe file add these lines:

<define name="ADC_CHANNEL_CURRENT" value="ADC_3" />
<define name="MilliAmpereOfAdc(adc)" value="(88*adc)"/>

and remove the line:
<define name="MILLIAMP_AT_FULL_THROTTLE" value="12000" unit="mA"/>

The correct multiplier for the raw measurement conversion depends on the current sensor. The Sparkfun sensor returns a linear voltage of 0 V - 3.3 V and at 90.15 A it reaches the maximum of 3.3 V. The TWOG v1 or Tiny v2 have a A/D converter with 10-bit precision (1024 different values) to represent the voltage. So you can calculate the multiplier with the following formula:

'''1000 / precision * A_at_max_voltage'''

For the Sparkfun sensor, the precision is 1024 and A_at_max_voltage is 90.15 => 1000/1024*90.15 = 88.037

For the ACS755LCB-100 sensor, there is a 0.6 volts offset. At 3.3v, the current is 67.5A. The formula is thus: value="(80.55*(adc-185))"

== Display on Ground Control Station (GCS) ==

Use the Messages application to show it.

The total energy consumed during the flight (in mAh) is sent in the "BAT" message.

The actual current flowing through the sensor (in mA) is sent in the "fbw_status" message.

You can display the energy or current on the GCS by just dragging and dropping them on the 2d map.

== Voltage Sensor ==

If you would like to install the autopilot on a bigger airframe, you can face the problem, that the nominal voltage of the accupack is higher then allowed for the autopilot. (i.e. 6 cell LiPo and TWOG ) But if you use a voltage regulator, then the autopilot has no information on the real voltage of the accupack. The GCS will show the autopilot input voltage, which is irrelevant regarding the remaining capacity of the accupack. Fortunately the Sparkfun Attopilot Current Sensor provides a voltage signal scaled down to 3.3V, too. This can be connected to a general analog input of the autopilot (for example ADC_4) similar to the current signal. If you configure the airframe file in the following way, the autopilot will provide all of the warnings (i.e. Battery Low) and calculations (i.e. power consumption) as it does in case of a direct connection between autopilot and accupack.

Firmware section:
<firmware name="fixedwing">
.
<define name="USE_ADC"/>
<define name="USE_ADC_4"/> 
<define name="ADC_CHANNEL_VSUPPLY" value="ADC_4"/>
.

Then in Battery section:
<section name="BAT">
.
<define name="VOLTAGE_ADC_A" value="0.05"/>
<define name="VOLTAGE_ADC_B" value="1"/>
<define name="VoltageOfAdc(adc)" value ="(VOLTAGE_ADC_A * adc + VOLTAGE_ADC_B)"/>
.

You don't need to load special module for this purpose (i.e. adc_generic )!

(The above method was tested with Sparkfun Attopilot Current Sensor and TWOG.)

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