PaparazziUAV - User contributions [en]

Media

2008-06-11T15:12:57Z

SergeLeHuitouze: /* Paparazzi in the News */

{|width="100%" cellpadding="12" cellspacing="5"
|-valign="top"
| style="width:50%"|
== Paparazzi in the News ==

* [http://www.flightglobal.com/articles/2008/04/03/222680/cots-uav-makes-arctic-debut.html Flight International: COTS UAV makes arctic debut] - April 3, 2008
*:A Norwegian university has flown an autonomous unmanned air vehicle equipped with meteorological sensors over the Spitzbergen/Svalbard island in the arctic circle in temperatures of -20 degrees C (-4 degrees F), winds up to 15m/s (50ft/s) and at an altitude of 4,900ft (1,500m). The Multiplex Funjet UAV was modified with electronics for open-source Paparazzi autopilot software…


* [http://diydrones.com/profiles/blog/show?id=705844%3ABlogPost%3A29982 DIY DRONES: Interview: Martin Müller and the Paparazzi Project (now less DIY!)] - March 25, 2008
*:DIY DRONES has been following the Paparazzi autopilot project with interest for several years. It's a European open source technology initiative that has created both thermopile (infrared sensor) and gyro-based autopilot hardware, along with quite sophisticated software to run it…


* [http://www.spiegel.de/wissenschaft/mensch/0,1518,525696,00.html SPIEGEL Online: Projekt "Paparazzi": Bau dir deinen fliegenden Spion] - December 28, 2007
*:Unbemannte Mini-Flugzeuge werden derzeit vor allem von Militärs genutzt. Doch eine Drohne, die selbständig vorgegebene Routen abfliegt, lässt sich auch selbst bauen. Für etwa 1000 Euro bekommt man ein Flugzeug, das sich bequem per Software dirigieren lässt.
*:Der Flieger macht nicht, was er soll: Plötzlich dreht er um 180 Grad und kehrt zum Startpunkt zurück. "Alles ist unter Kontrolle", sagt Antoine Drouin und die Zuhörer auf dem Chaos Communication Congress in Berlin lachen…


* [http://www.golem.de/0712/56728.html golem.de: 24C3: Paparazzi - Open-Source-Autopilot für Modellflugzeuge] - December 28, 2007
*:Demo von Flugplanänderungen zweier autonomer Modellflieger über Netzwerke
*:Auf dem derzeit in Berlin stattfindenden 24. Chaos Communication Congress (24C3) zeigten Martin Müller und Antoine Drouin von der Ecole Nationale de l'Aviation Civile (ENAC) vor versammeltem Hacker-Publikum wie ein wenig kostenintensiver GPS-basierter Autopilot aussieht. Mit der ebenfalls dafür entwickelten Software lassen sich mit einem Netzwerk sogar mehrere Flugzeuge an verschiedenen Standorten verwalten…


* [http://www.hackaday.com/2007/12/27/24c3/ HACK A DAY: 24C3 Build your own UAV] - December 27, 2007
*:The 24th annual Chaos Communications Congress in Berlin is already off to a great start. The first talk we attended was [Antoine Drouin] and [Martin Müller] presenting Paparazzi - The Free Autopilot. Paparazzi is an open source hardware and software project for building autonomous unmanned aerial vehicles. The main hardware board has an ARM processor and GPS. It uses inertial and infrared sensors to determine orientation and altitude. The four infrared thermopiles measure the air temperature. The ground is warmer than the sky and if you compare the temperature in the direction of each wing tip your can tell what angle the airplane is at. It's really that simple…


* [http://www.elektor-electronics.co.uk/Default.aspx?tabid=27&art=53265&PN=On Elector Electronics: "Flying Robots"] - Feb 2007
*:As processors become ever more powerful we are witnessing the rise of more ’intelligent’ systems. We now look to sophisticated robots to assist or even replace us in difficult or hazardous environments. This is particularly true of military hardware where we have seen on our TV screens the use of unmanned aircraft and vehicles in some recent conflicts. The basic idea however is not so new; we take a look into the world of ‘drones’…

* [http://www.auvsi.org//members/FeaturedArticles/NovDec06/NovDec06.pdf MAV Student Competition] - Nov/Dec 2006
*:The Air Force Research Laboratory Munitions Directorate and AUVSI’s Emerald Coast Chapter hosted the 2nd US-European Competition & Workshop on Micro Air Vehicles, MAV06, Oct. 29-Nov. 2. See page 23.

* [http://www.flightglobal.com/Articles/2006/11/03/210365/US+Army+battle+laboratory+studies+hand-launched+Dragon+Slayer+micro+UAV+for+battlefield.html "Flight International: Dragon Slayer"] - November 3, 2006
*:The US Army battle laboratory is to buy several prototypes of the Miraterre Flight Systems Dragon Slayer hand-launched micro unmanned air vehicle (UAV) to develop it into a low-cost, expendable surveillance tool for soldiers...

* [http://www.recherche.enac.fr/paparazzi/cache/sherbrooke.html Compétition internationale d'avions espions miniatures: Un succès qui suscite un intérêt international] - ([http://www.recherche.enac.fr/paparazzi/cache/sherbrooke.html cached])- October 5, 2005 
*:5 octobre 2005 – Une équipe de cinq étudiants en génie de l'Université de Sherbrooke est arrivée première dans 4 catégories et 7e au cumulatif lors d'une importante compétition internationale d'avions espions miniatures, à Garmish-Partenkirchen, en Allemagne.
*:L'événement nommé US-European Micro-Aerial Vehicle Technology Demonstration and Assessment a accueilli du 19 au 22 septembre 17 équipes provenant de partout à travers le monde. Chacune devait présenter un petit véhicule conçu par les membres et capable d'effectuer de la surveillance aérienne durant 30 minutes afin de détecter un terroriste dans un rayon de 500 m...

* [http://www.flightglobal.com/Articles/2005/10/04/201895/French+school+to+go+it+alone.html Flight International: "French School To Go It Alone"] - ([http://www.recherche.enac.fr/paparazzi/cache/fi2.html cached]) October 4, 2005 
*:French national civil aviation school ENAC plans to demonstrate autonomous formation flight with two micro air vehicles in November. Two 1.4m (4.6ft)-wingspan, electrically powered Twin Star model aircraft are being fitted with GPS receivers and radio transmitters for the tests, in which they will fly about 10m apart, one following the other...

* [http://www.flightglobal.com/Articles/2005/09/27/Navigation/251/201713/Teams+chase+MAV+prize.html Flight International: "Teams chase MAV prize"] - ([http://www.recherche.enac.fr/paparazzi/cache/fi.html cached]) - September 27, 2005 
*:Open-source software, the foam-like material Depron and tiny infrared attitude controllers were common design elements among the 16 teams competing at the first US-European Micro Aerial Vehicle (MAV) Technology Demonstration and Assessment event, held in Garmisch-Partenkirchen, Germany last week...

* [http://www.flightglobal.com/Articles/2005/10/25/202326/DOWN+SIZING.html "Flight International: Down Sizing"] - September 26, 2005 
*:As the first generation of micro-scale UAVs, exemplified by the remote-control Wasp, reaches the hands of military users, the US Army’s MAV competition in Garmisch-Partenkirchen provided a glimpse of the future. The winning University of Arizona team’s fixed-wing MAV transmitted video while flying autonomously via GPS waypoints using an open-source flight-control software package, called Paparazzi, originally developed by France’s national aviation school Enac.

* [http://www.flightglobal.com/blogs/flight-international/2005/09/from-fallujah-to-garmischparte.html "Flight International Blog: From Fallujah to Garmisch-Partenkirchen"] - September, 2005 
*:Robots are often used in the media to instil fear with Frankenstein like stories of the scientist and corporation having gone to far with a humanoid machine destroying all before it. But on today's battlefield, and for this US Army sponsored event, and for the war of tomorrow the robots will, apparently, look more like model planes.

|

== Design Reports ==

* [http://www.iop.org/EJ/article/1755-1315/1/1/012014/ees8_1_012014.pdf SUMO: A small unmanned meteorological observer for atmospheric boundary layer research] (751k, PDF) - May 2008
*: Paper describing the meteorological campaigns on Iceland and Spitsbergen. Also available from the [http://www.iop.org/EJ/abstract/1755-1315/1/1/012014 IOP conference site]

* [http://www.recherche.enac.fr/paparazzi/papers_2008/ENAC_MAV08.pdf YAP - Yet Another Paparazzi] (4M, PDF) - March 2008
*: Technical paper of the ENAC entry at [http://www.nal.res.in/MAV08 MAV08]

* [http://www.recherche.enac.fr/paparazzi/papers_2007/easyDrone.pdf "easyDrone - La nouvelle interface de pilotage de drone (french)"] (8.1M, PDF) - March 2007
*:This report describres a proposal for a new kind of GCS, highly dynamic (no more static flight plan) and using modern interactions (gesture recognition, ...)

* [http://www.recherche.enac.fr/paparazzi/papers_2006/mav06_paparazzi.pdf "The Paparazzi Solution"]-[http://www.recherche.enac.fr/paparazzi/papers_2006/mav06_paparazzi_slides.pdf (slides)] (4.6MB pdf) - September 2006
*:This paper describes the Paparazzi project approach: The complete and integrated design of hardware, software, and airframe into a robust and reliable system, proven by formal analytical methods and thousands of flight hours.
*:Best Oral / Technical Presentation - MAV-06
*:''Brisset, Drouin, Gorraz, Huard, Tyler''

* [http://www.recherche.enac.fr/paparazzi/papers_2005/jpo_2005.pdf "Présentation JPO" (French)] (8MB pdf) - October 2005
*:A brief presentation of Paparazzi@Enac
*:''Drouin, Brisset''

* [[Media:rapport_co_ihm.pdf|"Systémes Interactifs du Drone Paparazzi" (French)]] (1MB pdf) - Feburary 2005
*:Study of the ground control station interface
*:''Doscot, Mansouri, Poupard''

* [http://www.recherche.enac.fr/paparazzi/papers_2004/drones_et_micro_drones.pdf "Drones et micro-drones" (French)] (10.5MB pdf) - 2004
*:Introduction to UAVs; presentation of the Paparazzi project
*:''Drouin, Brisset''

* [[Media:paparadziy.pdf|"PaparaDzIY : do-it-yourself UAV"]] (800K pdf) - 2004
*:Guidelines and tools for amateur UAVs
*:''Drouin, Brisset''

* [http://www.recherche.enac.fr/paparazzi/papers_2004/rapport_a_matthieu.pdf "Traitement de la video" (French)] (2.7MB pdf) - 2004
*:Video data processing
*:''Matthieu Tobie''

* [[Media:PaparazziBenchmark11_paper.pdf|"PapaBench : A Free Real-Time Benchmark"]] (365K pdf)
*:This paper presents PapaBench, a free real-time benchmark and compares it with the existing benchmark suites. It is designed to be valuable for experimental works in WCET computation and may be also useful for scheduling analysis. This benchmark is based on the Paparazzi project that represents a real-time application, developed to be embedded on different Unmanned Aerial Vehicles (UAV).
*:''Fadia Nemer, Hugues Cassé, Pascal Sainrat, Jean-Paul Bahsoun and Marianne De Michiel''

* [[Media:infrared_calib_paper.zip|"Calibration d’un récepteur Infra-Rouge pour Micro Drone" (French)]] (800K zip) - January 2004
*:Hybridization of GPS and infrared data
*:En fonctionnement normal le filtre de Kalman propose un meilleur fonctionnement que la régression linéaire.
*:Dans le cas de conditions changeantes, sans panne, le filtre de Kalman s’adapte mieux que la régression linéaire.
*:Par contre dans le cas d’une panne, le filtre de Kalman ne l’a détecte pas et provoque une dérive du drone.
*:Hybridization of GPS and infrared data
*:''Sébastien BINAS, Sylvain DEPLANCHE, Aurélien HADIDA, (IENAC01L)''


== Manuals ==
* [[Media:users_manual.pdf|"User's Manual"]] (1.5M, pdf) - February 2008
*:This document is a quick guide to use the Paparazzi system. It is divided into two parts. In the first part an extensive procedure, which can also be used as a check-list, is given to prepare a flight, to operate the UAV and to analyze the results. The procedure is described for a given flight plan and a pre-programmed and tuned aircraft. The second part gives a description of the different components and tools of the system.
*:''ENAC''

|-
|}

== Other Sites of Interest ==
[[Image:2g Autonomous Glider.jpg|thumb|300px|Complete autonomous glider weighs only 2 grams including LiPo battery, I2C optic flow sensor for optical obstacle avoidance, stereo microphones for locating the source of audio signals, 200V power supply, and piezoelectric actuators.]]
* [http://robotics.eecs.berkeley.edu/~ronf/PAPERS/iecon05.pdf "Design, Fabrication and Initial Results of a 2g Autonomous Glider"] (900K, PDF) - July 2007
*:Utilizing the core technologies of emerging microrobotic structures, the rapid design and prototyping of a passive micro air vehicle with the final goal of locating an audio source while avoiding hazardous obstacles is presented. The airfoil and control surfaces are optimized empirically to maximize lift and maneuverability while minimizing drag. Bimorph piezoelectric bending cantilevers actuate the control surfaces. Since such actuators require high voltages, an efficient boost circuit is presented along with appropriate high voltage electronics. To locate audio sources, a pair of acoustic sensors is designed and prototyped using a phase detection algorithm while a custom optic flow sensor is developed to avoid obstacles and give estimates of object distances and velocities. Finally, each subsystem is demonstrated and the complete glider is integrated to demonstrate initial open loop control performance.

Media

2008-06-11T15:09:40Z

SergeLeHuitouze: /* Paparazzi in the News */

{|width="100%" cellpadding="12" cellspacing="5"
|-valign="top"
| style="width:50%"|
== Paparazzi in the News ==

* [http://www.flightglobal.com/articles/2008/04/03/222680/cots-uav-makes-arctic-debut.html Flight International: COTS UAV makes arctic debut] - April 3, 2008
*:A Norwegian university has flown an autonomous unmanned air vehicle equipped with meteorological sensors over the Spitzbergen/Svalbard island in the arctic circle in temperatures of -20 degrees C (-4 degrees F), winds up to 15m/s (50ft/s) and at an altitude of 4,900ft (1,500m). The Multiplex Funjet UAV was modified with electronics for open-source Paparazzi autopilot software…


* [http://diydrones.com/profiles/blog/show?id=705844%3ABlogPost%3A29982 Interview: Martin Müller and the Paparazzi Project (now less DIY!)] - March 25, 2008
*:DIY DRONES has been following the Paparazzi autopilot project with interest for several years. It's a European open source technology initiative that has created both thermopile (infrared sensor) and gyro-based autopilot hardware, along with quite sophisticated software to run it…


* [http://www.spiegel.de/wissenschaft/mensch/0,1518,525696,00.html SPIEGEL Online: Projekt "Paparazzi": Bau dir deinen fliegenden Spion] - December 28, 2007
*:Unbemannte Mini-Flugzeuge werden derzeit vor allem von Militärs genutzt. Doch eine Drohne, die selbständig vorgegebene Routen abfliegt, lässt sich auch selbst bauen. Für etwa 1000 Euro bekommt man ein Flugzeug, das sich bequem per Software dirigieren lässt.
*:Der Flieger macht nicht, was er soll: Plötzlich dreht er um 180 Grad und kehrt zum Startpunkt zurück. "Alles ist unter Kontrolle", sagt Antoine Drouin und die Zuhörer auf dem Chaos Communication Congress in Berlin lachen…


* [http://www.golem.de/0712/56728.html golem.de: 24C3: Paparazzi - Open-Source-Autopilot für Modellflugzeuge] - December 28, 2007
*:Demo von Flugplanänderungen zweier autonomer Modellflieger über Netzwerke
*:Auf dem derzeit in Berlin stattfindenden 24. Chaos Communication Congress (24C3) zeigten Martin Müller und Antoine Drouin von der Ecole Nationale de l'Aviation Civile (ENAC) vor versammeltem Hacker-Publikum wie ein wenig kostenintensiver GPS-basierter Autopilot aussieht. Mit der ebenfalls dafür entwickelten Software lassen sich mit einem Netzwerk sogar mehrere Flugzeuge an verschiedenen Standorten verwalten…


* [http://www.hackaday.com/2007/12/27/24c3/ HACK A DAY: 24C3 Build your own UAV] - December 27, 2007
*:The 24th annual Chaos Communications Congress in Berlin is already off to a great start. The first talk we attended was [Antoine Drouin] and [Martin Müller] presenting Paparazzi - The Free Autopilot. Paparazzi is an open source hardware and software project for building autonomous unmanned aerial vehicles. The main hardware board has an ARM processor and GPS. It uses inertial and infrared sensors to determine orientation and altitude. The four infrared thermopiles measure the air temperature. The ground is warmer than the sky and if you compare the temperature in the direction of each wing tip your can tell what angle the airplane is at. It's really that simple…


* [http://www.elektor-electronics.co.uk/Default.aspx?tabid=27&art=53265&PN=On Elector Electronics: "Flying Robots"] - Feb 2007
*:As processors become ever more powerful we are witnessing the rise of more ’intelligent’ systems. We now look to sophisticated robots to assist or even replace us in difficult or hazardous environments. This is particularly true of military hardware where we have seen on our TV screens the use of unmanned aircraft and vehicles in some recent conflicts. The basic idea however is not so new; we take a look into the world of ‘drones’…

* [http://www.auvsi.org//members/FeaturedArticles/NovDec06/NovDec06.pdf MAV Student Competition] - Nov/Dec 2006
*:The Air Force Research Laboratory Munitions Directorate and AUVSI’s Emerald Coast Chapter hosted the 2nd US-European Competition & Workshop on Micro Air Vehicles, MAV06, Oct. 29-Nov. 2. See page 23.

* [http://www.flightglobal.com/Articles/2006/11/03/210365/US+Army+battle+laboratory+studies+hand-launched+Dragon+Slayer+micro+UAV+for+battlefield.html "Flight International: Dragon Slayer"] - November 3, 2006
*:The US Army battle laboratory is to buy several prototypes of the Miraterre Flight Systems Dragon Slayer hand-launched micro unmanned air vehicle (UAV) to develop it into a low-cost, expendable surveillance tool for soldiers...

* [http://www.recherche.enac.fr/paparazzi/cache/sherbrooke.html Compétition internationale d'avions espions miniatures: Un succès qui suscite un intérêt international] - ([http://www.recherche.enac.fr/paparazzi/cache/sherbrooke.html cached])- October 5, 2005 
*:5 octobre 2005 – Une équipe de cinq étudiants en génie de l'Université de Sherbrooke est arrivée première dans 4 catégories et 7e au cumulatif lors d'une importante compétition internationale d'avions espions miniatures, à Garmish-Partenkirchen, en Allemagne.
*:L'événement nommé US-European Micro-Aerial Vehicle Technology Demonstration and Assessment a accueilli du 19 au 22 septembre 17 équipes provenant de partout à travers le monde. Chacune devait présenter un petit véhicule conçu par les membres et capable d'effectuer de la surveillance aérienne durant 30 minutes afin de détecter un terroriste dans un rayon de 500 m...

* [http://www.flightglobal.com/Articles/2005/10/04/201895/French+school+to+go+it+alone.html Flight International: "French School To Go It Alone"] - ([http://www.recherche.enac.fr/paparazzi/cache/fi2.html cached]) October 4, 2005 
*:French national civil aviation school ENAC plans to demonstrate autonomous formation flight with two micro air vehicles in November. Two 1.4m (4.6ft)-wingspan, electrically powered Twin Star model aircraft are being fitted with GPS receivers and radio transmitters for the tests, in which they will fly about 10m apart, one following the other...

* [http://www.flightglobal.com/Articles/2005/09/27/Navigation/251/201713/Teams+chase+MAV+prize.html Flight International: "Teams chase MAV prize"] - ([http://www.recherche.enac.fr/paparazzi/cache/fi.html cached]) - September 27, 2005 
*:Open-source software, the foam-like material Depron and tiny infrared attitude controllers were common design elements among the 16 teams competing at the first US-European Micro Aerial Vehicle (MAV) Technology Demonstration and Assessment event, held in Garmisch-Partenkirchen, Germany last week...

* [http://www.flightglobal.com/Articles/2005/10/25/202326/DOWN+SIZING.html "Flight International: Down Sizing"] - September 26, 2005 
*:As the first generation of micro-scale UAVs, exemplified by the remote-control Wasp, reaches the hands of military users, the US Army’s MAV competition in Garmisch-Partenkirchen provided a glimpse of the future. The winning University of Arizona team’s fixed-wing MAV transmitted video while flying autonomously via GPS waypoints using an open-source flight-control software package, called Paparazzi, originally developed by France’s national aviation school Enac.

* [http://www.flightglobal.com/blogs/flight-international/2005/09/from-fallujah-to-garmischparte.html "Flight International Blog: From Fallujah to Garmisch-Partenkirchen"] - September, 2005 
*:Robots are often used in the media to instil fear with Frankenstein like stories of the scientist and corporation having gone to far with a humanoid machine destroying all before it. But on today's battlefield, and for this US Army sponsored event, and for the war of tomorrow the robots will, apparently, look more like model planes.

|

== Design Reports ==

* [http://www.iop.org/EJ/article/1755-1315/1/1/012014/ees8_1_012014.pdf SUMO: A small unmanned meteorological observer for atmospheric boundary layer research] (751k, PDF) - May 2008
*: Paper describing the meteorological campaigns on Iceland and Spitsbergen. Also available from the [http://www.iop.org/EJ/abstract/1755-1315/1/1/012014 IOP conference site]

* [http://www.recherche.enac.fr/paparazzi/papers_2008/ENAC_MAV08.pdf YAP - Yet Another Paparazzi] (4M, PDF) - March 2008
*: Technical paper of the ENAC entry at [http://www.nal.res.in/MAV08 MAV08]

* [http://www.recherche.enac.fr/paparazzi/papers_2007/easyDrone.pdf "easyDrone - La nouvelle interface de pilotage de drone (french)"] (8.1M, PDF) - March 2007
*:This report describres a proposal for a new kind of GCS, highly dynamic (no more static flight plan) and using modern interactions (gesture recognition, ...)

* [http://www.recherche.enac.fr/paparazzi/papers_2006/mav06_paparazzi.pdf "The Paparazzi Solution"]-[http://www.recherche.enac.fr/paparazzi/papers_2006/mav06_paparazzi_slides.pdf (slides)] (4.6MB pdf) - September 2006
*:This paper describes the Paparazzi project approach: The complete and integrated design of hardware, software, and airframe into a robust and reliable system, proven by formal analytical methods and thousands of flight hours.
*:Best Oral / Technical Presentation - MAV-06
*:''Brisset, Drouin, Gorraz, Huard, Tyler''

* [http://www.recherche.enac.fr/paparazzi/papers_2005/jpo_2005.pdf "Présentation JPO" (French)] (8MB pdf) - October 2005
*:A brief presentation of Paparazzi@Enac
*:''Drouin, Brisset''

* [[Media:rapport_co_ihm.pdf|"Systémes Interactifs du Drone Paparazzi" (French)]] (1MB pdf) - Feburary 2005
*:Study of the ground control station interface
*:''Doscot, Mansouri, Poupard''

* [http://www.recherche.enac.fr/paparazzi/papers_2004/drones_et_micro_drones.pdf "Drones et micro-drones" (French)] (10.5MB pdf) - 2004
*:Introduction to UAVs; presentation of the Paparazzi project
*:''Drouin, Brisset''

* [[Media:paparadziy.pdf|"PaparaDzIY : do-it-yourself UAV"]] (800K pdf) - 2004
*:Guidelines and tools for amateur UAVs
*:''Drouin, Brisset''

* [http://www.recherche.enac.fr/paparazzi/papers_2004/rapport_a_matthieu.pdf "Traitement de la video" (French)] (2.7MB pdf) - 2004
*:Video data processing
*:''Matthieu Tobie''

* [[Media:PaparazziBenchmark11_paper.pdf|"PapaBench : A Free Real-Time Benchmark"]] (365K pdf)
*:This paper presents PapaBench, a free real-time benchmark and compares it with the existing benchmark suites. It is designed to be valuable for experimental works in WCET computation and may be also useful for scheduling analysis. This benchmark is based on the Paparazzi project that represents a real-time application, developed to be embedded on different Unmanned Aerial Vehicles (UAV).
*:''Fadia Nemer, Hugues Cassé, Pascal Sainrat, Jean-Paul Bahsoun and Marianne De Michiel''

* [[Media:infrared_calib_paper.zip|"Calibration d’un récepteur Infra-Rouge pour Micro Drone" (French)]] (800K zip) - January 2004
*:Hybridization of GPS and infrared data
*:En fonctionnement normal le filtre de Kalman propose un meilleur fonctionnement que la régression linéaire.
*:Dans le cas de conditions changeantes, sans panne, le filtre de Kalman s’adapte mieux que la régression linéaire.
*:Par contre dans le cas d’une panne, le filtre de Kalman ne l’a détecte pas et provoque une dérive du drone.
*:Hybridization of GPS and infrared data
*:''Sébastien BINAS, Sylvain DEPLANCHE, Aurélien HADIDA, (IENAC01L)''


== Manuals ==
* [[Media:users_manual.pdf|"User's Manual"]] (1.5M, pdf) - February 2008
*:This document is a quick guide to use the Paparazzi system. It is divided into two parts. In the first part an extensive procedure, which can also be used as a check-list, is given to prepare a flight, to operate the UAV and to analyze the results. The procedure is described for a given flight plan and a pre-programmed and tuned aircraft. The second part gives a description of the different components and tools of the system.
*:''ENAC''

|-
|}

== Other Sites of Interest ==
[[Image:2g Autonomous Glider.jpg|thumb|300px|Complete autonomous glider weighs only 2 grams including LiPo battery, I2C optic flow sensor for optical obstacle avoidance, stereo microphones for locating the source of audio signals, 200V power supply, and piezoelectric actuators.]]
* [http://robotics.eecs.berkeley.edu/~ronf/PAPERS/iecon05.pdf "Design, Fabrication and Initial Results of a 2g Autonomous Glider"] (900K, PDF) - July 2007
*:Utilizing the core technologies of emerging microrobotic structures, the rapid design and prototyping of a passive micro air vehicle with the final goal of locating an audio source while avoiding hazardous obstacles is presented. The airfoil and control surfaces are optimized empirically to maximize lift and maneuverability while minimizing drag. Bimorph piezoelectric bending cantilevers actuate the control surfaces. Since such actuators require high voltages, an efficient boost circuit is presented along with appropriate high voltage electronics. To locate audio sources, a pair of acoustic sensors is designed and prototyped using a phase detection algorithm while a custom optic flow sensor is developed to avoid obstacles and give estimates of object distances and velocities. Finally, each subsystem is demonstrated and the complete glider is integrated to demonstrate initial open loop control performance.

Lustre

2007-07-18T12:00:33Z

SergeLeHuitouze: /* Lustre : a synchronous declarative programming language */

'''Lustre implementation of critical code''' 
As robustness is the priority of the Paparazzi project, a hardware/software fail-safe is implemented on AVR and Classix autopilots by processing all critical code on a dedicated microcontroller, independent from the navigation, communication, and payload processor. As the role of this processor is absolutely critical, source code must be certified. Typical industry practice is to certify only ''methods'' of programming, not ''source code''. In the Paparazzi project, we make this code safer by writing clear specifications in reference to which we can prove safety properties. The operational code in C is then automatically generated from these specifications.

== Lustre : a synchronous declarative programming language ==
Lustre is a data-flow programming language, which means that all precedent values of the variables are known. Lustre is also a synchronous language, meaning all instructions are considered to be executed simultaneously.

Lustre functions are referred to as nodes, operating on input streams to compute the output streams. A Lustre program has a cyclic behavior - on the nth execution cycle of the program, all involved streams take their nth value. A node defines one or several output parameters as functions of one or more input parameters.

Operators used to write statements in a node operate on the entire stream. This means that if you write X=Y, then the nth value of X will always be equal to the nth value of Y, for all n.

Read more at [http://www-verimag.imag.fr/SYNCHRONE/index.php?page=lang-design Verimag.imag.fr]

== Lustre modelling of all variables ==
The natural way to write proven code is to write Lustre statements between state variables. The problem is that Lustre proposed types are limited to bool, int and float. To produce code for a µC, we had to specify custom types used on the µC, such as uint16_t (unsigned 16-bits integer) or uint8_t (unsigned 8-bits integer). 
As defining custom types is not possible in Lustre, we use the natural Lustre types, specifying how our types can be represented with natural types. We then redefine common operators to preserve modularity. For instance, uint16_t is a modular integer type. This method allows simulations of the code with Lustre tools (luciole for example).

Lustre generated code can not be used on the µC. Our definitions preserve modularity on state variables, but the internal variables managed by Lustre generated code are not aware of µC limitations. Consequently, generated code cannot be executed on a real µC. For instance, some tests are always true or false due to range limitations of data types, and ignored by the code generator.

== Lustre specifications with C types ==
From a practical standpoint, we prefer to use only C-defined types. Lustre can manage this type, but every operator must be defined as Lustre can not create operators for unknown types. This method gives good results with generated code that is ready to execute on the µC but there is a problem. As Lustre is not aware of C types, the Lustre tools cannot prove anything in this form and any potential benefits are lost.

== Separating the proof code from the execution code ==
The method we use combines the best attributes of the above mentioned strategies. We write the operational code using C-defined types, which gives us ready-to-use code, and the proof is done only with Lustre code. The only remaining work is to ensure that the C-code and the Lustre-code of the operators are equivalent, a trivial task since operators are very simple functions/nodes (usually defined by macros in C).

== How to use the Lustre-generated code ==
Currently only PPM decoding is implemented using the Lustre code. This Lustre description of PPM decoding provides safety by defining precisely what type of PPM frame is to be accepted and what should be rejected. Hardware testing has proven that Lustre implemented PPM decoding outperforms hand written C implemented decoding as we occasionally see valid PPM frames lost with hand written code, but not with Lustre code.

Lustre generated code is not yet entirely generic. It works only with the CockpitMM R/C transmitter used during our hardware tests. Efforts are underway to make it selectable from the configuration file. If you use the CockpitMM transmitter you can use Lustre code - simply go to the lustre directory in Paparazzi tree, compile, and upload the program to the µC.

cd $PAPARAZZI_HOME/sw/airborne/fly_by_wire/lustre_version
make clean_all
make load

Tuning

2007-07-18T08:21:15Z

SergeLeHuitouze:

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.

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

=== 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. Note that your body will have a tremendous impact on the measured angles.
* Verify that AUTO1 stick movements respond in the correct direction - important!
* Move the plane rapidly to ensure the gyro response resists motion - increase the gain if needed for better visualization.

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

== Trim ==
Important: You must never keep any trim, mixers, or rates in your R/C transmitter. 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

== Auto 2 ==
* Engage Auto2 and you're done!

Compiling

2007-07-18T08:10:45Z

SergeLeHuitouze: /* Environment Variables */

Flight plans, tuning and configuration settings are compiled into a single binary image and transferred to the microcontroler flash rom through USB. Most tuning and flight plan parameters can be changed in-flight but after each power cycle, the autopilot reverts to the original settings. Permanent changes must be made in the source files, compiled, and uploaded to the autopilot.
== Environment Variables ==
Before compiling you must have the Paparazzi source and home environment variables set correctly in your shell. These variables can be automatically set in your shell by adding the following lines to your .bashrc file:
{{Box Code|/home/''your_username''/.bashrc|
export PAPARAZZI_HOME<nowiki>=</nowiki>/home/''your_username''/paparazzi
export PAPARAZZI_SRC<nowiki>=</nowiki>/home/''your_username''/paparazzi
}}
To manually set the env variables (i.e. when compiling a backup copy of your code in a different folder) execute the following command from the folder you wish to set as your active paparazzi folder:
export PAPARAZZI_HOME=`pwd`;export PAPARAZZI_SRC=`pwd`
You may wish to verify that your variables are set correctly with the following command:
env | grep PAPARAZZI

== USB flashing ==
[[Image:Tiny_test_wiring.jpg|thumb|Example wiring for programming and telemetry]]
If the autopilot senses a connected USB cable during power-on, it will wait to receive a firmware image rather than booting normally. The firmware can be compiled and flashed by several means, the most common being:
make AIRCRAFT=''myplane'' clean_ac ap.upload
(where ''myplane'' is the name of your airframe as defined in <tt>conf/conf.xml</tt>)

This command erases any compiled autopilot code from the PC, recompiles everything from scratch, and then sends it to the autopilot.
Variations include:
* make AIRCRAFT=''myplane'' sim
*: Compiles your code for use in the simulator - note that "clean_ac" will remove this code, so the simulator code must be rebuilt each time a clean has been performed.
* make AIRCRAFT=''myplane'' fbw.upload
*: This is needed when configuring the separate "fly by wire" MCU on the [[Classix]] autopilot.
* make AIRCRAFT=''myplane'' ap
*: This will simply build the portions of autopilot code that have changed since the last compile without attempting to flash. Note: this method may not detect certain changes (i.e. changes to the airframe makefile section or CVS updated code).
* make AIRCRAFT=''myplane'' ap.upload FLASH_MODE=IAP
*: Specifies USB flashing. This should be specified at the top of the makefile section of your airframe file but can be overridden here. Use FLASH_MODE=IAS for serial flashing.
* make AIRCRAFT=''myplane'' tunnel.upload
*: This will replace the normal autopilot code with a simple serial-to-serial tunnel that connects the GPS serial port directly to the modem serial port. This is useful when testing/configuring the GPS with [[GPS#GPS_configuration_using_U-Center|U-Center]]
=== Installing the USB Bootloader ===

The USB bootloader should only need to be installed once. It is loaded through the serial interface UART0 (Serial1) by holding pin P0.14 low during power-up. If you were supplied with a Tiny Autopilot it may have already had the USB bootloader installed, please check with your supplier.

You will need to convert the PC's RS232 Serial with voltage levels of +/-13V to 3.3V (or 5V) TTL in order to communicate directly with the device. This can be accomplished in multiple ways. The easiest and most convenient method is to purchase or build a USB -> Serial 3.3V adapter similar to this one [http://www.ftdichip.com/Products/EvaluationKits/TTL-232R-3V3.htm TTL-232R-3V3]
Here's a few other examples:
[http://www.sparkfun.com/commerce/product_info.php?products_id=199]
[http://www.sparkfun.com/commerce/product_info.php?products_id=718]
[http://www.pololu.com/products/pololu/0391/]
[http://www.hvwtech.com/products_view.asp?CatID=166&SubCatID=183&SubSubCatID=0&ProductID=409]
Users are strongly urged to use FTDI usb-serial converters as they are well supported by default in the linux kernel and since the Paparazzi ground station software is configured to look for modems on FTDI ports by default, the converter can likely serve as a modem interface after it's use in programming.

Make up a wiring harness similar to the following. You may vary the details however this is a working solution:

TINY RXD0 <-- PC SERIAL TX (5V or 3.3V) 
TINY TXD0 --> PC SERIAL RX (5V or 3.3V) 
TINY RESET --> ''optional'' wired to ground through a pushbutton so you can reset 
TINY P0.14 (SERIAL1-5) --> attach to ground, or wire through a pushbutton to ground 
TINY GND --> PC SERIAL ADAPTER GND 

Once this wiring is ready you will be ready to send the USB Bootloader to the Tiny from the PC.

To prepare the Tiny to accept programming over its serial port you must have pin P0.14 LOW for at least 3mS while it is powering up or resetting. While it is still powered up it is ready to accept code over serial. Proceed now to instructions to load it via software.

'''In Linux'''

From your paparazzi3 folder in linux, type:

make upload_bl PROC=GENERIC

This will begin compiling your USB Bootloader and then attempt to transfer it to the Autopilot. This will also assume you are using a USB -> Serial adapter for the connection. It uses /dev/ttyUSB0 by default. If your adapter is mapped to a different tty, you will need to modify the Makefile accordingly.

'''In Windows'''

If for some reason you need to program your Tiny's USB Bootloader in windows grab a copy of LPC2000 Flash Utility V2.2.3 or later. You will then prepare the Tiny and boot it into the ISP bootloader as mentioned above but program it with this utility. You will need to copy your compiled bl.hex file from Linux of course.

== Troubleshooting ==
As a rapidly evolving open-source project, on occasion your software may fail to compile after a [[Installation#CVS_Update|CVS Update]]. This is most likely due to a new or changed variable name that is now required in your airframe, flight plan, etc. Since the user-configured files are not updated automatically you may need to view the most recently changed sample airframe or flight plan files to find the required changes. 
See the [[Software_Troubleshooting|Software Troubleshooting]] page for help with common compiliation errors.

Airframe Configuration

2007-07-18T08:08:56Z

SergeLeHuitouze: /* Horizontal Control */

The airframe configuration file is located in <tt>conf/airframes/</tt> and contains all the hardware and software settings for a particular aircraft. This is a hybrid file containing [http://en.wikipedia.org/wiki/Xml xml] in the first half with [http://en.wikipedia.org/wiki/Makefile C Makefile] code at the bottom. All gains, trims, and behavior settings are in the top XML section and the hardware definitions such as processor type, modem protocol, servo driver, etc. are contained in the makefile.

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

== XML Parameters ==
=== Commands ===

The <tt>commands</tt> lists the servo commands you need to control the aircraft. In our example, we have only three:
<tt>
<commands>
<axis name="THROTTLE" failsafe_value="0"/>
<axis name="ROLL" failsafe_value="0"/>
<axis name="PITCH" failsafe_value="0"/>
</commands></tt>
Each command is associated with a failsafe value which will be used if no controller is active (during initialization for example). The range of these values is [-9600:9600].

=== Servos ===

The above commands get translated to the <tt>servos</tt> here. In this example we use two ailevons (surfaces used for both pitch and roll as on a flying wing) and a motor. These are listed in the <tt>servos</tt> section:
<tt>
<servos>
<servo name="THROTTLE" no="0" min="1000" neutral="1000" max="2000"/>
<servo name="AILEVON_LEFT" no="1" min="2000" neutral="1500" max="1000"/>
<servo name="AILEVON_RIGHT" no="2" min="1000" neutral="1500" max="2000"/>
</servos></tt>
where names are associated to the corresponding servo channel number on the autopilot and the neutral value, total range and direction are defined. Min/max/neutral values are expressed in milliseconds and the direction of travel can be reversed by exchanging min with max (as in <tt>"AILEVON_LEFT"</tt>, above). The ''standard'' travel for a hobby servo is 1000ms - 2000ms with a 1500ms neutral. Trim can be added by changing this neutral value, and absolute travel limits can be increased or reduced with the min/max values. The <tt>"THROTTLE"</tt> servo typically has the same value for the <tt>neutral</tt> and <tt>min</tt>. Note the following tips:
* Reverse the servo direction by exchanging min/max
* Trim should always be adjusted mechanically if possible to avoid asymetrical travel
* Any reduction of the total travel range should be done mechanically to maintain precision
* Many servos will respond well to values slightly outside the normal 1000-2000ms range but experiment carefully as the servo may not operate reliably outside this range and may even suffer permanent damage.

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

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

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

=== ADC ===
In the "adc" section, you will find the correspondance between arguments and their assigned pins on the autopilot board.
 

=== Infrared ===
The <tt>INFRARED</tt> section describes the configuration of the infrared sensors. It is necessary to calibrate them in order to obtain the neutral values. As the X-Y sensor pairs are usually installed with a 45 degree rotation, combining roll and pitch we have a formula to separate roll from pitch and adjust the output accordingly:

<tt>
<linear name="RollOfIrs" arity="2" coeff1="-0.7" coeff2="0.7"/>
<linear name="PitchOfIrs" arity="2" coeff1="-0.7" coeff2="-0.7"/>
</tt>

Pitch and roll directions are defined here with the "-" sign on some of the 4 <tt>coeff</tt> values. Some trial and error is usually needed to get the directions correct.

Note that the roll angle is positive when the right wing low while pitch is positive when the nose is up.
 

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

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

=== Bat ===
This section for the monitoring the main power battery. The allowed voltage range for this aircraft is 9-12.5V. <tt>MILLIAMP_PER_PERCENT</tt> represents the consumption (in mA) for one percent of THROTTLE and for one time unit. The <tt>LOW_BATTERY</tt> value defines the voltage at which the autopilot will lock the throttle at 0% in autonomous mode.

<tt>
<section name="BAT">
<define name="MILLIAMP_PER_PERCENT value "0.86"/>
<define name="VOLTAGE_ADC_A" value="0.0177531"/>
<define name="VOLTAGE_ADC_B" value="0.173626"/>
<define name="VoltageOfAdc(adc)" value ="(VOLTAGE_ADC_A * adc + VOLTAGE_ADC_B)"/>
<define name="LOW_BATTERY" value"9.3" unit="V"/>
</section>
</tt>

=== Horizontal Control ===
<tt>
<section name="HORIZONTAL CONTROL" prefix="H_CTL_">
<define name="COURSE_PGAIN" value="-0.4"/>
<define name="ROLL_MAX_SETPOINT" value="0.35" unit="radians"/>
<define name="ROLL_PGAIN" value="5000."/>
<define name="AILERON_OF_THROTTLE" value="0.0"/>
<define name="PITCH_PGAIN" value="-8000."/>
<define name="ELEVATOR_OF_ROLL" value="1250"/>
</section>
</tt>

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

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

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

== Hardware definitions - Makefile ==

The airframe file must include the description of the controller board and it's low-level settings. This is done in one <tt>makefile</tt> section starting with the autopilot model and flashing mode:
{{Box Code|conf/airframes/myplane.xml|
<makefile>
include $(PAPARAZZI_SRC)/conf/autopilot/tiny.makefile
<nowiki>FLASH_MODE=IAP</nowiki>
.
.
.
</makefile>
}}
Below this are the definintions and configuration of the peripherals and interfaces.

=== R/C ===

{{Box Code|conf/airframes/myplane.xml|
<nowiki>ap.CFLAGS += -DRADIO_CONTROL</nowiki>
<nowiki>ap.EXTRA_SRCS += radio_control.c $(SRC_ARCH)/ppm_hw.c</nowiki>
<nowiki>ap.CFLAGS += -DACTUATORS=\"servos_direct_hw.h\"</nowiki>
<nowiki>ap.EXTRA_SRCS += $(SRC_ARCH)/servos_direct_hw.c</nowiki>
}}

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

Paparazzi supports the following modem protocols:
* Standard transparent serial (pprz) - this is compatible with all modems and can be used to connect the autopilot directly to a PC for testing without a modem.
* Maxstream API protocol (xbee) - compatible with all Maxstream modems including the 9XTend and Zigbee. This protocol enables hardware addressing, allowing multiple aircraft to be managed from a single ground modem.
* Coronis Wavecard - necessary for operation with the unusual Coronis Wavecard modem.
Select the baud/protocol in the airframe file by commenting/uncommenting the appropriate section as follows:
==== Configuring The Serial Protocol ====
Users are advised to start with the standard serial protocol before attempting to setup an addressed API link. The serial protocol works with virtually any modem as well as direct cable connections. The baud rates of the airborne modem, autopilot, ground modem, and PC must be configured correctly. The PC and autopilot serial ports do not need to be set to the same baud rate, i.e. when running multiple aircraft from a single ground modem, the ground modem may require a higher baud rate than any of the airborne modems in order to stream the data from multiple simultaneous sources.

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

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

 

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

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

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

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

 

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

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

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

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

=== Sensors ===

=== Control loops ===

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

First the horizontal loop:
{{Box Code|conf/airframes/myplane.xml|
<nowiki>ap.srcs += fw_h_ctl.c</nowiki>
}}

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