Difference between revisions of "AR Drone 2"

From PaparazziUAV
Jump to navigation Jump to search
 
(31 intermediate revisions by 3 users not shown)
Line 1: Line 1:
= AR.Drone 2.0 Paparazzidized =
{|align=right
|-
|<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>AR Drone 2</categorytree>
|}


= Introduction =
== Introduction ==
 
[[File:Ardrone2_snow.gif|320pxleft|AR.Drine 2.0]]


[[File:800px-Parrot_AR.Drone_2.JPG|thumb|300px|Parrot's AR Drone 2]] [[File:ARdrone_exploded.jpg|thumb|300px|Exploded view of the AR Drone 2.]]
[[File:800px-Parrot_AR.Drone_2.JPG|thumb|300px|Parrot's AR Drone 2]] [[File:ARdrone_exploded.jpg|thumb|300px|Exploded view of the AR Drone 2.]]
Line 9: Line 14:
Replace the current AR.Drone 2.0 brain by uploading paparazzi in current ARM chip and use the aready available sensors. Connect a GPS on the USB port, use Wifi for telemetry and optional manal control.
Replace the current AR.Drone 2.0 brain by uploading paparazzi in current ARM chip and use the aready available sensors. Connect a GPS on the USB port, use Wifi for telemetry and optional manal control.


No soldering or other modifications in the electronics to make. Only PPZ software makes it possible to let the AR.Drone 2.0 fly autonomous missions under spectacular better control than the original onboard control.
No soldering or other modifications in the electronics to make. Only with Paparazzi software and a GPS receiver it is possible to let the AR.Drone 2.0 fly autonomous missions under spectacular better control than the original onboard control.


...as simple as that, now go and try it for yourself...  
...as simple as that, have fun and try it for yourself...  


== Help ==
=== Help ===


Paparazzi is a very mature project that has existed since 2003. So your questions concerning paparazzi have possibly already been asked and answered on the mailing list. So please first read the [http://lists.gnu.org/archive/html/paparazzi-devel/ mailinglist ]. If the answer is not there please ask your question on the mailinglist or IRC channel [http://paparazzi.enac.fr/wiki/Main_Page icons on the top of main page]. You will find your question is likely addressed within minutes or hours. Paparazzi is a global project so in most cases somewhere in the world someone is reading your email/question and will reply.
Paparazzi is a very mature project that has existed since 2003. So your questions concerning paparazzi have possibly already been asked and answered on theso called "mailing list". It would be best to first read through the [http://lists.gnu.org/archive/html/paparazzi-devel/ mailinglist ]. If the answer is not there please ask your question on this mailinglist or maybe even via the IRC channel [http://paparazzi.enac.fr/wiki/Main_Page icons on the top of main page]. You will find your question is likely addressed within hours or days. Paparazzi is a global project so in most cases somewhere in the world someone is reading your email/question and will reply.


== History ==
=== History ===


On September 3rd 2012 two Delft University of Technology student teams started a new UAV robotics project under the guidance of [mailto:microuav@gmail.com ing. ir. B. D. W. Remes]. Both teams shared a similar objective, namely getting the AR Drone v2.0 to fly autonomously using the advanced opensource Paparazzi Software.
On September 3rd 2012 two Delft University of Technology student teams started a new UAV robotics project under the guidance of [mailto:microuav@gmail.com ing. ir. B. D. W. Remes]. Both teams shared a similar objective, namely getting the AR Drone v2.0 to fly autonomously using the advanced opensource Paparazzi Software.
Line 23: Line 28:
{{#ev: youtubehd|oX423smmPEc}}
{{#ev: youtubehd|oX423smmPEc}}


== Easy ==
=== Easy ===


When you have finished you autonomous flight with paparazzi and want to fly with the standard [http://ardrone2.parrot.com/apps/| ARDrone2 apps], just unplugging and re-plugging the battery will make your drone a standard ARDrone2 again.
When you have finished you autonomous flight with paparazzi and want to fly with the standard [http://ardrone2.parrot.com/apps/| ARDrone2 apps] again, just unplugging and re-plugging the battery will make your drone a standard ARDrone2 again.


= The Hardware =
== The Hardware ==
 
[[File:Ardrone2_snow.gif|320pxleft|AR.Drine 2.0]]


First some generic information about the airframe hardware just to satisfy curiosity.
First some generic information about the airframe hardware just to satisfy curiosity.


== HD Video recording ==
=== HD Video recording ===


Get high definition live video streaming to your smartphone or tablet as you are flying. See a clean, sharp image just as if you were in the pilot seat.
Get high definition live video streaming to your smartphone or tablet as you are flying. See a clean, sharp image just as if you were in the pilot seat.
Line 45: Line 48:
* Video storage on the fly with Wi-Fi directly on your remote device or on a USB key
* Video storage on the fly with Wi-Fi directly on your remote device or on a USB key


== Robust structure  ==
=== Robust structure  ===


Trying your most daring tricks won’t even challenge this cutting edge design which is made to last.
Trying your most daring tricks won’t even challenge this cutting edge design which is made to last.
Line 56: Line 59:
* Fully reparable: All parts and instructions for repairing available on the internet
* Fully reparable: All parts and instructions for repairing available on the internet


== Electronic assistance ==
=== Electronic assistance ===


AR.Drone 2.0 on-board technology gives you extreme precision control and automatic stabilization features.
AR.Drone 2.0 on-board technology gives you extreme precision control and automatic stabilization features.
Line 72: Line 75:
* 60 fps vertical QVGA camera for ground speed measurement
* 60 fps vertical QVGA camera for ground speed measurement


== Motor ==
=== Motor ===
 
Fly high. Fly fast. Far away from the ground.


* 4 brushless inrunner motors. 14.5W 28,500 RMP
* 4 brushless inrunner motors. 14.5W 28,500 RMP
Line 88: Line 89:
* Water resistant motor’s electronic controller
* Water resistant motor’s electronic controller


= Autopilot =
== Autopilot ==


[[File:ardrone2_mainboard.jpg|320pxleft|AP Mainboard]]
[[File:ardrone2_mainboard.jpg|320pxleft|AP Mainboard]]
Line 94: Line 95:
The main board in the AR.Drone 2.0 '''IS''' the autopilot
The main board in the AR.Drone 2.0 '''IS''' the autopilot


= GPS =
== GPS ==
 
To fly autonomous to a certain geo coordinate a GPS is needed. Although it is theoretically possible to use the original orange Parrot GPS it is not advised, the performance is just not good enough for autonomous flights. The solution that *is* advised is to use an uBlox GPS.
 
{TODO IMG}
 
== Connecting GPS ==
 
{TODO IMG}


A FTDI TTL 232R 3V3 WE cable is used, where - WE stans for wire ended. 3V3 operates at +3.3V levels (signals only, VCC= +5V)
To fly autonomous to a certain geo coordinate a GNSS receiver device is needed. GNSS stands for Global Navigation Satellite System, and is the standard generic term for satellite navigation systems that provide autonomous geo-spatial positioning with global coverage. This term includes e.g. the GPS, GLONASS, Galileo, Beidou and other regional systems


[[Image:HowtoConnectUSBHelixGPSForParrotARDrone2.jpg|thumb|left|How to connect USB to uBlox Helix GPS for Parrot ARDrone2]]
Although it is theoretically possible to use the original orange Parrot GPS dongle it is not advised, the performance is just not good enough for great autonomous flights. The solution that '''is advised''' is to use an '''uBlox GPS''' module.
To connect a uBlox with Helix antenna via a USB to serial cable that you can just plug into your ARdrone 2
<br style="clear:both;" />


Example of a via USB connected uBlox Helix GPS for Parrot ARDrone2
* Take a look on the [[AR_Drone_2/GPS| Howto add a GNSS device to your ARDrone 2]] page for details.


=== Pinout colors ===
== Installation ==


TTL - 232R - 5V, TTL - 232R - 3V3 Connector color coding
=== Prerequisites ===
 
[[File:Ftdi_ttl_232r_3v3_we_color_coding.jpg|320pxleft|FTDI TTL 232R 3v3 WE color coding]]
 
||1 ||Black ||BK ||
||2 ||Brown ||BN ||
||3 ||Red ||RD ||
||4 ||Orange ||OG ||
||5 ||Yellow ||YE ||
||6 ||Green ||GN ||
 
=== How the connector is prepared ===
 
#A sharp knive deep in the outer end, the part where the wire come out, this will damage the first part of the wires, but that is OK, it will be cut of and not be used.
#Cut a along the whole wire till the USB connector begin
#Peel ot the wires in the begin
#Grab all the wires of the cable end stringly in your hand
#With one continuous pull, pull the wires out of the black outer plastic. With a cut alone the line this shoud go, just apply force.
# You are done!
 
IMPORTANT LINK:
http://forum.parrot.com/ardrone/en/viewtopic.php?id=5331
http://www.dronetec.co.uk/quadmod.html
 
= Installation =
 
== Prerequisites ==


To be able to fly your AR.Drone 2.0 you need '''ARDrone2 firmware v2.4.8''' or higher on your ARDrone. And for your Paparazzi GCS laptop it's best to have Ubuntu Linux v14.04 LTS or higher installed
To be able to fly your AR.Drone 2.0 you need '''ARDrone2 firmware v2.4.8''' or higher on your ARDrone. And for your Paparazzi GCS laptop it's best to have Ubuntu Linux v14.04 LTS or higher installed
Line 150: Line 115:
Note: the above is simply one long command to the Linux command interpreter. The && are simply saying if the command to the left returns successful return code then run the command on the right .. and so on. So if the command fails the rest of the commands to the right will not be executed. It maybe helpful then to simply copy/paste each command one at a time. Just grab between the '&&'
Note: the above is simply one long command to the Linux command interpreter. The && are simply saying if the command to the left returns successful return code then run the command on the right .. and so on. So if the command fails the rest of the commands to the right will not be executed. It maybe helpful then to simply copy/paste each command one at a time. Just grab between the '&&'


==== Error on ubuntu 13.10 ====
=== Ubuntu 16.04 LTS and later ===


You might encounter an error during the build of paparazzi. It might as for gcc-arm-none-eabi, saying that it can't find the package. This is because the terry.guo repository doesn't provide a version for this distribution. In order to resolve this issue just follow the instructions [http://wiki.paparazziuav.org/wiki/Installation/Linux#gcc-arm-none-eabi_as_Ubuntu_package here].
With Ubunutu 16.04 and later, the ARM-Linux toolchain provided by the operating system is too recent. Compiling the code is still possible, but running it on the Parrot AR.Drone2 would result of an error message:
FATAL: kernel too old
Segmentation fault


= Autonomy =
In order to compile with the proper libraries, it is needed to download the toolchain provided by Parrot on their [https://github.com/Parrot-Developers/toolchains Github Developpers] page and get the 2012.03 Debian package file: https://github.com/Parrot-Developers/toolchains/raw/master/parrot-tools-linuxgnutools-2012.03_1.0.0-1_i386.deb. After downloading it, install the package with:
sudo dpkg -i parrot-tools-linuxgnutools-2012.03_1.0.0-1_i386.deb
 
The toolchain will be installed in your file system in '''/opt/arm-2012.03''' directory. Then you need to tell which compiler should be used for your AR.Drone2 by adding to the firmware section of your airframe file the following line:
<configure name="PREFIX" value="/opt/arm-2012.03/bin/arm-none-linux-gnueabi"/>
 
Now, the program should compile and run normally. You can check that the correct GCC is used in the Paparazzi center terminal:
GCC version:
arm-none-linux-gnueabi-gcc (Sourcery CodeBench Lite 2012.03-57) 4.6.3
 
== Autonomy ==


[[Image:GCSParrotardroneandpaparazzi.jpg|Right|570px|GCS for Paparazzi Parrot AR.Drone 2.0]]
[[Image:GCSParrotardroneandpaparazzi.jpg|Right|570px|GCS for Paparazzi Parrot AR.Drone 2.0]]
Line 179: Line 156:
At this moment it is important that you have an ARDrone2 that has it's GPS device connected and has established a Wifi connection with your computer. You can now continue uploading the Autopilot to the ARDrone2.
At this moment it is important that you have an ARDrone2 that has it's GPS device connected and has established a Wifi connection with your computer. You can now continue uploading the Autopilot to the ARDrone2.


# At Paparazzi Center select ''ardrone2_sdk'' at the "A/C" drop-down box  
# At Paparazzi Center select ''ardrone2'' at the "A/C" drop-down box  


[[Image:2_choose_ardrone2_sdk_from_ac_dropdown.png|Choose ardrone2_sdk from A/C selection]]
[[Image:2_choose_ardrone2_sdk_from_ac_dropdown.png|Choose ardrone2 from A/C selection]]


# Make sure "ap" (Autopilot) is set as Target
# Make sure "ap" (Autopilot) is set as Target
Line 188: Line 165:
[[Image:3_press_upload.png|Press Upload]]
[[Image:3_press_upload.png|Press Upload]]


# now in In the Paparazzi control center Select ''ARDrone2 Flight'' as session  
# now in In the Paparazzi control center Select ''Flight UDP/Wifi'' as session  


[[Image:4_select_ardrone_flight_session.png|Select "ARDrone2 Flight" as session]]
[[Image:4_select_ardrone_flight_session.png|Select "Flight UDP/Wifi" as session]]


# Press the [Execute] button
# Press the [Execute] button
Line 196: Line 173:
[[Image:5_press_execute.png|Press Execute]]
[[Image:5_press_execute.png|Press Execute]]


= Flying =
== Flying ==


Take your AR Drone and laptop outside. A clear view of the sky is essential for GPS to work properly.  A good GPS position signal is necessary for optimal autonomous flight. However GPS is only accurate to within  several meters, so make sure you have enough of free space around to let it fly without bumping into something.
Take your AR Drone and laptop outside. A clear view of the sky is essential for GPS to work properly.  A good GPS position signal is necessary for optimal autonomous flight. However GPS is only accurate to within  several meters, so make sure you have enough of free space around to let it fly without bumping into something.
Line 214: Line 191:
If no Wifi connection is availabe from your laptop to the ARDRone2, you will have a blank screen. That is perfectly normal. Just make sure you make a Wifi connection to your AR drone first.
If no Wifi connection is availabe from your laptop to the ARDRone2, you will have a blank screen. That is perfectly normal. Just make sure you make a Wifi connection to your AR drone first.


== Takeoff==
=== Takeoff===


# Press the [Takeoff] button and keep a good eye on where your Drone flies.
# Press the [Takeoff] button and keep a good eye on where your Drone flies.
Line 222: Line 199:
When all worked out well the drone took off, followed a line back and forth and landed again, congratulations you made your first autonomous flight!
When all worked out well the drone took off, followed a line back and forth and landed again, congratulations you made your first autonomous flight!


== Move waypoints==
=== Move waypoints===


To have some fun with your AR.Drone 2.0 in flight, one could move the ''standby'' waypoint to another location close by.
To have some fun with your AR.Drone 2.0 in flight, one could move the ''standby'' waypoint to another location close by.


== Home==
=== Home ===
Home: Let the ARDrone come back where you took off
Home: Let the ARDrone come back where you took off


[[Image:GCSParrotardroneandpaparazziHome.jpg|200|Home Paparazzi Parrot AR.Drone 2.0]]
[[Image:GCSParrotardroneandpaparazziHome.jpg|200|Home Paparazzi Parrot AR.Drone 2.0]]


== Land==
=== Land ===
Land: Land the drone where you took off
Land: Land the drone where you took off


[[Image:GCSParrotardroneandpaparazziLAnd.jpg|200px|LAnd Paparazzi Parrot AR.Drone 2.0]]
[[Image:GCSParrotardroneandpaparazziLAnd.jpg|200px|LAnd Paparazzi Parrot AR.Drone 2.0]]


= Next steps =
== Next steps ==


Now that your Parrot AR.Drone 2.0 flew autonomously you can dive deeper into the world Paparazzi and it's [[Flight_Plans]]. Just browse around this Wiki and read and try things that interest you the most, have fun!
Now that your Parrot AR.Drone 2.0 flew autonomously you can dive deeper into the world Paparazzi and it's [[Flight_Plans]]. Just browse around this Wiki and read and try things that interest you the most, have fun!


= Experts=
== Experts==


After you have now experienced your first feeling of quite some autonomous flights with your Paparazzi controlled UAV you might want to become an expert on the  AR.Drone 2.0.
After you have now experienced your first feeling of quite some autonomous flights with your Paparazzi controlled UAV you might want to become an expert on the  AR.Drone 2.0.
Read on below to be able learn, change and create great new things...
Read on below to be able learn, change and create great new things...


= Sign conventions =
== Sign conventions ==


This section will show the sign conventions used by the SDK of the Parrot AR.Drone 2.0. One can read these values directly from the AR.Drone software. This is a good refference also fro the PPRZ version.
This section will show the sign conventions used by the SDK of the Parrot AR.Drone 2.0. One can read these values directly from the AR.Drone software. This is a good refference also fro the PPRZ version.


== Body axis ==
=== Body axis ===


[[File:body axis convention.jpg|thumb|right|350px|Body axis convention]]
[[File:body axis convention.jpg|thumb|right|350px|Body axis convention]]
Line 259: Line 236:
* Position in z (altitude [mm])
* Position in z (altitude [mm])


== Angles ==
=== Angles ===


[[File:roll convention.jpg|150px|Roll convention]]
[[File:roll convention.jpg|150px|Roll convention]]
Line 274: Line 251:
<br>
<br>


= Simulation =
== Simulation ==


== Introduction ==
=== Introduction ===


This page will guide you through the creation of the mechanical model with JSBSim for Paparazzi.
This page will guide you through the creation of the mechanical model with JSBSim for Paparazzi.


== Setting up the simulation environment ==
=== Setting up the simulation environment ===


See [[Setting up simulation environment]].
See [[Setting up simulation environment]].


== Creating the mechanical model ==
=== Creating the mechanical model ===


Not every feature of the JSMSim model is needed for Paparazzi. Below is a list of features that should be included in the .xml file.
Not every feature of the JSMSim model is needed for Paparazzi. Below is a list of features that should be included in the .xml file.
Line 294: Line 271:
* Propulsion
* Propulsion


== Example .xml file ==
=== Example .xml file ===


This section displays a standard .xml file, with some added comments per segment. For a more extensive guide on JSBSim read the extensive [http://jsbsim.sourceforge.net/JSBSimReferenceManual.pdf JSBSim manual]
This section displays a standard .xml file, with some added comments per segment. For a more extensive guide on JSBSim read the extensive [http://jsbsim.sourceforge.net/JSBSimReferenceManual.pdf JSBSim manual]
Line 305: Line 282:
   ''' </fileheader> '''
   ''' </fileheader> '''


=== Metrics ===
==== Metrics ====
Metrics
Metrics


Line 333: Line 310:
     '''</metrics>'''
     '''</metrics>'''


=== Mass balance ===
==== Mass balance ====




Line 351: Line 328:
     '''</mass_balance>'''
     '''</mass_balance>'''


=== Ground reactions ===
==== Ground reactions ====


This section creates contact points with the ground for the AR.Drone 2.0. The ground reactions were designed with aircraft wheels in mind. Therefore, the specifications and locations of the ground reactions do not really matter, due to the vertical take-off the quadrotor.   
This section creates contact points with the ground for the AR.Drone 2.0. The ground reactions were designed with aircraft wheels in mind. Therefore, the specifications and locations of the ground reactions do not really matter, due to the vertical take-off the quadrotor.   
Line 424: Line 401:
The full configuration and Flight Dynamics Model (FDM) files to fly the AR.Drone autonomously in JSBsim. A very thorough [http://jsbsim.sourceforge.net/JSBSimReferenceManual.pdf JSBSIM reference manual] can be found on the JSBSIM documentation page, in creating the .xml configuration file the team followed this manual closely.  
The full configuration and Flight Dynamics Model (FDM) files to fly the AR.Drone autonomously in JSBsim. A very thorough [http://jsbsim.sourceforge.net/JSBSimReferenceManual.pdf JSBSIM reference manual] can be found on the JSBSIM documentation page, in creating the .xml configuration file the team followed this manual closely.  


== AR.Drone.xml ==
=== AR.Drone.xml ===


'''FileHeader'''
'''FileHeader'''
Line 841: Line 818:
  '''</aerodynamics>'''
  '''</aerodynamics>'''


== AR.Drone-set.xml ==
=== AR.Drone-set.xml ===
The set .xml file is used by Flightgear for the simulation of the aircraft and sees no further use by JSBSIM for the creation of the FDM. All variables and settings within this particular .xml file are implemented in the drone simulation (e.g. sounds, sights, systems, etc.). A CAD model of the drone is also used herein for visual representation. The model was animated in the [http://www.blender.org/ Blender] open-source 3D computer graphics software. Therein it was imported as a .stl file from a CAD editor and exported as a .ac file which Flightgear could implement as a visual during simulation. At the time of writing this was the most straightforward method for importing and exporting the model although it required the implementation of an additional python script. These import and export features will soon be default in Blender distributions.
The set .xml file is used by Flightgear for the simulation of the aircraft and sees no further use by JSBSIM for the creation of the FDM. All variables and settings within this particular .xml file are implemented in the drone simulation (e.g. sounds, sights, systems, etc.). A CAD model of the drone is also used herein for visual representation. The model was animated in the [http://www.blender.org/ Blender] open-source 3D computer graphics software. Therein it was imported as a .stl file from a CAD editor and exported as a .ac file which Flightgear could implement as a visual during simulation. At the time of writing this was the most straightforward method for importing and exporting the model although it required the implementation of an additional python script. These import and export features will soon be default in Blender distributions.


Line 928: Line 905:
  </nasal>
  </nasal>


= View ARDrone 2 live video =
== Flightgear ==


== Option 1: Simple low quality MJPEG over RTP ==
This section will explain the installation of FlightGear and the creation of an visual model for Flightgear.


Add the '''video_stream_rtp.xml''' module to your airframe file. (you can save higher quality frames by clicking on the snapshot setting in the ground-station)
[[Image:Flightgear Screenshot indoor.png|thumb|right|400px|An example AR.Drone flying in FlightGear]]


Make a text file with extension .sdp and add the following content [https://github.com/tudelft/ardrone2_gstreamer/blob/master/sdp/x86_config-mjpeg.sdp link]
=== Download FlightGear ===


  v=0
FlightGear can be downloaded from http://www.flightgear.org/download/ . Installation should be self-explanatory. The aircraft models will be located in: (...\FlightGear\Data\Aircraft).
  m=video 5000 RTP/AVP 26
  c=IN IP4 0.0.0.0


Open the SDP file with VLC or another video viewer while the code with module is running on the drone.
=== Visual model ===


== Option 2: Use the precompiled gstreamer with MP4 encoding on the DSP ==
Flightgear uses .ac files from the AC3D program, a 3D design program by Inivis[http://www.inivis.com/]. A free alternative is Blender[http://www.blender.org/], which can export its files to the .ac format with a plugin[http://wiki.blender.org/index.php/Extensions:2.4/Py/Scripts/Export/AC3D] (instructions on how to install also found in link).


  git clone https://github.com/tudelft/ardrone2_gstreamer.git
Our minor group used an existing model[http://grabcad.com/library/ar-drone-parrot], (registering required), which we exported to .stl in Autodesk. Then we imported the .stl files with Blender, and exported them again in the required .ac format.


Once connected to the ARDrone2 you can upload gstreamer to the ARDrone using (make sure you did not already add a lot of data to the drone like pictures etc because gstreamer will need all normally available free space):
==== Moving parts ====


  cd ardrone2_gstreamer/
To use animated moving parts in the model, all the moving parts have to be exported individually. All parts are linked together by the model's set file.
  make drone  (or manually untar arm_light.tgz and mount and start dsp images: see ardrone.py script for details: reboot drone if starting dsp mp4 images fails)


Before you start encoding video on ARDrone2 the DSP inside the OMAP, it must still load the proper binaries (see todo/basescript.sh for an alternative)
== Setting up the folder ==
Inside your aircraft folder (...\FlightGear\Data\Aircraft\"Aircraft name"), a .xml file is needed to enable Flightgear to load the model. This file should be named as: "Aircraft name"-set.xml. Inside, it links to main visual model file. All visual model files should go into the "Models" folder of the aircraft:  (...\FlightGear\Data\Aircraft\"Aircraft name"\Models). The main .xml file should indicate the lay-out of the model (see Example files).


  ./ardrone2.py startvideo  (this step must be repeated every time you reboot the drone)
==== Clarification of the .xml files ====
main.xml:


After this you can use gstreamer on the drone: telnet to the drone and run for instance:  
The .ac file contains the body model of the quadrotor:
<path>myquadrotor.ac</path>


  telnet 192.168.1.1
The 4 <model> nodes contain information about the location and orientation of the propellors. The <path> links to the location of the engine file. The <offsets> manually places the propellors in (about) the right place. This has no consequences for the performance of the aircraft. For the FlightGear coordinate system, see: [http://www.city-gallery.com/knoblock/projects/flightgear/Docs/coords.html]. The <pitch/yaw/roll-deg> can be used if the imported file has the wrong orientation.
  gst-launch v4l2src device=/dev/video1 ! videorate ! 'video/x-raw-yuv,framerate=15/1' ! videoscale ! video/x-raw-yuv, width=320, height=240 ! dspmp4venc ! rtpmp4vpay config-interval=2 ! udpsink host=192.168.1.255 port=5000


(to open video1, downrate, downsample, MP4-encode on dsp, add RTP protocol, UDP stream to IP:port)
  <model>
 
<!-- LF -->
and view and save the stream on your PC using the opposite chain:
  <name>Engine1</name>
  <path>Aircraft/myquadrotor/Models/engine1.xml</path>
  <offsets>
    <x-m>0.3</x-m>
    <y-m>-0.2</y-m>
    <z-m>0.0</z-m>
    <pitch-deg>0</pitch-deg>
  </offsets>
  </model>


   gst-launch-0.10 udpsrc uri=udp://0.0.0.0:5000  caps = 'application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)MP4V-ES, payload=(int)96' ! rtpmp4vdepay ! ffdec_mpeg4 ! ffmpegcolorspace ! tee name=split ! ximagesink split. ! queue ! ffmpegcolorspace ! ffenc_mpeg4 ! avimux ! filesink location=video.avi
Using <offsets> the orientation of the model was corrected:
    
  <offsets>
  <heading-deg>270</heading-deg>
  </offsets>


=== don't have gstreamer on your PC yet? ===


Install gstreamer with codecs on unbuntu: make install should achieve this
engine1.xml:


  sudo apt-get install gstreamer0.10-ffmpeg
Contains the model of the rotor:
<path>rotor.ac</path>


device=/dev/video1 is front camera
<Animation> is used for the animation of the propeller. You can declare the type of animation (spin), the center of the animation, around which axis to spin and in which direction (clockwise or ccw).  
device=/dev/video2 is bottom camera
   <animation>
 
  <type>spin</type>
Other way to video client in ubuntu:
  <object-name>propeller</object-name>
e.g.:
  <property>engines/engine[0]/rpm</property>
   gst-launch-0.10 -vvv playbin uri=file:///home/YOURNAME_AND_SUBFOLDER/ardrone2_gstreamer/sdp/x86_config-mp4.sdp
  <factor>1</factor> 
or see https://github.com/tudelft/ardrone2_gstreamer/blob/master/sdp/Makefile for options
  <centre>
    <x-m>0</x-m>
    <y-m>0</y-m>
    <z-m>0</z-m>
  </centre>
  <axis>
    <x>0</x>
    <y>0</y>
    <z>-1</z>
  </axis>
  </animation>


if the above command fails for Ubuntu 12.04 users, you can try this
=== Example files ===
  gst-launch-0.10 udpsrc uri=udp://0.0.0.0:5000  caps = 'application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)MP4V-ES, payload=(int)96' ! rtpmp4vdepay ! ffdec_mpeg4 ! ffmpegcolorspace ! ximagesink
main.xml file:
 
<PropertyList>
5) if you want to kill your video on the drone
   <path>myquadrotor.ac</path>
   telnet 192.168.1.1
   killall -9 gst-launch
   <model>
 
<!-- LF -->
 
  <name>Engine1</name>
= Making Gstreamer Plugins for the ARDrone =
  <path>Aircraft/myquadrotor/Models/engine1.xml</path>
 
  <offsets>
To combine your own vision with efficient exising gstreamer functions (like dspmp4encode) you should create a plugin and add it to the gstreamer chain:
    <x-m>0.3</x-m>
 
    <y-m>-0.2</y-m>
== Install ==
    <z-m>0.0</z-m>
 
    <pitch-deg>0</pitch-deg>
We first must install the framework on your development PC. We assume you already have installed the Paparazzi sourcecode. If not, please do that first, then come back to this page.
  </offsets>
 
   </model>
  git clone https://github.com/tudelft/ardrone2_vision.git
   cd ardrone2_vision
   <model>
  make install  (install some tools needed; scratchbox2 and qemu)
<!-- RB -->
   make
  <name>Engine2</name>
 
  <path>Aircraft/myquadrotor/Models/engine2.xml</path>
If you need to change your cross compiler:
  <offsets>
 
    <x-m> -0.3</x-m>
  gedit ./ardrone2_gstreamer/Makefile
    <y-m>0.2</y-m>
 
    <z-m> 0.0</z-m>
And add edit the path to your ardrone crosscompiler and '''make install''' again to setup sb2
    <pitch-deg>0</pitch-deg>
 
  </offsets>
Make your own vision plugin
  </model>
 
  ./create_new_plugin.py
 
= OpenCV 3 =
 
Here the description on how to get OpenCV 3 on your AR.Drone 2.0. If there is not so much text of explanation here... it is your turn to extend this Wikipage with your knowledge please.
   
   
[http://docs.opencv.org/doc/tutorials/introduction/crosscompilation/arm_crosscompile_with_cmake.html]
  <model>
 
<!-- RF -->
= Tips and Tricks=
  <name>Engine3</name>
 
  <path>Aircraft/myquadrotor/Models/engine3.xml</path>
== Transfer files ==
  <offsets>
    <x-m>-0.3</x-m>
    <y-m>-0.2</y-m>
    <z-m> 0.0</z-m>
    <pitch-deg>0</pitch-deg>
  </offsets>
  </model>
  <model>
<!-- LB -->
  <name>Engine4</name>
  <path>Aircraft/myquadrotor/Models/engine4.xml</path>
  <offsets>
    <x-m> 0.3</x-m>
    <y-m> 0.2 </y-m>
    <z-m> 0.0</z-m>
    <pitch-deg>0</pitch-deg>
  </offsets>
  </model>
  <offsets>
  <heading-deg>270</heading-deg>
  </offsets>
</PropertyList>


For transferring files the File Transfer Protocol (FTP) used in this project, was FileZilla. When you installed FileZilla, it will be pretty easy to transfer files.
engine1.xml file:


First you need to connect to the AR.Drone 2, by entering the ip-address of the AR.Drone 2 which is by default "192.168.1.1". Leave all other settings of FileZilla the same and press connect. When you are connected to the AR.Drone 2, keep in mind that programs need to be transferred in binary mode which can be set in the FileZilla Settings.
<PropertyList>
  <path>rotor.ac</path>
  <animation>
  <type>spin</type>
  <object-name>propeller</object-name>
  <property>engines/engine[0]/rpm</property>
  <factor>1</factor> 
  <centre>
    <x-m>0</x-m>
    <y-m>0</y-m>
    <z-m>0</z-m>
  </centre>
  <axis>
    <x>0</x>
    <y>0</y>
    <z>-1</z>
  </axis>
  </animation>
</PropertyList>


== Into the Brain ==
== View ARDrone 2 live video ==


=== login to console on AR.Drone2 via telnet ===
=== Option 1: Simple low quality MJPEG over RTP ===
To connect to AR.Drone2 you need a telnet client, so that you can connect with the busybox telnet server on the AR.Drone2.
When your computer is connected trough wifi with the the AR.Drone2, the drone's IP-address defaults to 192.168.1.1.


You can now connect by typing:
Add the '''video_stream_rtp.xml''' module to your airframe file. (you can save higher quality frames by clicking on the snapshot setting in the ground-station)


$ telnet 192.168.1.1
Make a text file with extension .sdp and add the following content [https://github.com/tudelft/ardrone2_gstreamer/blob/master/sdp/x86_config-mjpeg.sdp link]


A busybox welcome message will show when you connect.
  v=0
  m=video 5000 RTP/AVP 26
  c=IN IP4 0.0.0.0


It is convenient to make a hosts definition so you can type:
Open the SDP file with VLC or another video viewer while the code with module is running on the drone.


$ telnet ardrone2
=== Option 2: Use the precompiled gstreamer with MP4 encoding on the DSP ===


You do this by adding <code>192.168.1.1 ardrone2</code> to /etc/hosts
  git clone https://github.com/tudelft/ardrone2_gstreamer.git


== Change WiFi channel ==
Once connected to the ARDrone2 you can upload gstreamer to the ARDrone using (make sure you did not already add a lot of data to the drone like pictures etc because gstreamer will need all normally available free space):


Sometimes it is nice to be able to change a Wifi channel in an area where there a lot of Wifi devices are in one place. Do it via:
  cd ardrone2_gstreamer/
  make drone  (or manually untar arm_light.tgz and mount and start dsp images: see ardrone.py script for details: reboot drone if starting dsp mp4 images fails)


  # iwconfig ath0 channel X commit
Before you start encoding video on ARDrone2 the DSP inside the OMAP, it must still load the proper binaries (see todo/basescript.sh for an alternative)


== Connect via a router ==
  ./ardrone2.py startvideo  (this step must be repeated every time you reboot the drone)


To have a more flexible network setting the drone to use a router would be a good device to use. [[ardrone2userouter | This page explains how to use a router icw a AR.Drone 2.0]]
After this you can use gstreamer on the drone: telnet to the drone and run for instance:


== Debugging ==
  telnet 192.168.1.1
  gst-launch v4l2src device=/dev/video1 ! videorate ! 'video/x-raw-yuv,framerate=15/1' ! videoscale ! video/x-raw-yuv, width=320, height=240 ! dspmp4venc ! rtpmp4vpay config-interval=2 ! udpsink host=192.168.1.255 port=5000


=== Serial Console Cable ===
(to open video1, downrate, downsample, MP4-encode on dsp, add RTP protocol, UDP stream to IP:port)


Via the bottom USB port
and view and save the stream on your PC using the opposite chain:


Debugging is much easier if we have a console cable. For this your USB to serial terminal cable is connected on /dev/ttyUSB0, found via e.g.
  gst-launch-0.10 udpsrc uri=udp://0.0.0.0:5000  caps = 'application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)MP4V-ES, payload=(int)96' ! rtpmp4vdepay ! ffdec_mpeg4 ! ffmpegcolorspace ! tee name=split ! ximagesink split. ! queue ! ffmpegcolorspace ! ffenc_mpeg4 ! avimux ! filesink location=video.avi


$ dmesg
==== don't have gstreamer on your PC yet? ====


To login to the drone in your regular Linux terminal use:
Install gstreamer with codecs on unbuntu: make install should achieve this


$ screen /dev/ttyUSB0 115200
  sudo apt-get install gstreamer0.10-ffmpeg


== Repair firmware via serial connection ==
device=/dev/video1 is front camera
device=/dev/video2 is bottom camera


Sometime your drone is so messed up since you e.g .deleted some crucial files needed to boot u the drone. You need to have a serial cable
Other way to video client in ubuntu:
e.g.:
  gst-launch-0.10 -vvv playbin uri=file:///home/YOURNAME_AND_SUBFOLDER/ardrone2_gstreamer/sdp/x86_config-mp4.sdp
or see https://github.com/tudelft/ardrone2_gstreamer/blob/master/sdp/Makefile for options


http://forum.parrot.com/ardrone/en/viewtopic.php?id=5331
if the above command fails for Ubuntu 12.04 users, you can try this
  gst-launch-0.10 udpsrc uri=udp://0.0.0.0:5000  caps = 'application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)MP4V-ES, payload=(int)96' ! rtpmp4vdepay ! ffdec_mpeg4 ! ffmpegcolorspace ! ximagesink
 
5) if you want to kill your video on the drone
  telnet 192.168.1.1
  killall -9 gst-launch


== Repairing Firmware ==


If your ARdrone2 is bricked, work to be done so far no one managed to flash the firmware with external opensource tools.
== Making Gstreamer Plugins for the ARDrone ==


== Downgrade firmware ==
To combine your own vision with efficient exising gstreamer functions (like dspmp4encode) you should create a plugin and add it to the gstreamer chain:


If you would like to downgrade, upgrade, or re-install firmware you can do so at your own risk by using these files and instructions.
=== Install ===


Abbreviated instructions:
We first must install the framework on your development PC. We assume you already have installed the Paparazzi sourcecode. If not, please do that first, then come back to this page.


* Download the version you want below. (Don’t change the filename.)
  git clone https://github.com/tudelft/ardrone2_vision.git
* Power up your AR.Drone
  cd ardrone2_vision
* Connect your computer to the AR.Drone’s network
  make install  (install some tools needed; scratchbox2 and qemu)
* Open a telnet session to 192.168.1.1
  make
* type the following: echo “1.1.1″ > /firmware/version.txt
 
* press enter
If you need to change your cross compiler:
* type the following:  echo “1.1.1″ > /update/version.txt
* Connect an FTP client to 192.168.1.1 Port: 5551
* Upload the downloaded plf file to the FTP server (AR.Drone)
* Disconnect your computer from the AR.Drone
*  Disconnect the battery from the AR.Drone
* Reconnect the battery
* Wait about 5 minutes while the upgrade completes, leave your drone switched on=


== GDB ==
  gedit ./ardrone2_gstreamer/Makefile


The Drone has GDB (GNU Debugger) installed by default
And add edit the path to your ardrone crosscompiler and '''make install''' again to setup sb2


Connect to GDB via: {TODO}
Make your own vision plugin


= Boot sequence =
  ./create_new_plugin.py


Note that this section of the page is a work in progress, lease add more info if you have discovered more infrmation.
== OpenCV 3 ==


http://omappedia.org/wiki/Bootloader_Project
Here the description on how to get OpenCV 3 on your AR.Drone 2.0. If there is not so much text of explanation here... it is your turn to extend this Wikipage with your knowledge please.
[http://docs.opencv.org/doc/tutorials/introduction/crosscompilation/arm_crosscompile_with_cmake.html]


The drone 2.0 is based on a Texas Instruments OMAP3630, modified of course.
== Tips and Tricks==


v1 process (it's similar but not the same, and there is no "load from USB" bootloader available for the 2.0 like there was for the v1):
=== Transfer files ===
http://embedded-software.blogspot.co.uk
 
For transferring files the File Transfer Protocol (FTP) used in this project, was FileZilla. When you installed FileZilla, it will be pretty easy to transfer files.


How the boot process works:
First you need to connect to the AR.Drone 2, by entering the ip-address of the AR.Drone 2 which is by default "192.168.1.1". Leave all other settings of FileZilla the same and press connect. When you are connected to the AR.Drone 2, keep in mind that programs need to be transferred in binary mode which can be set in the FileZilla Settings.
* http://omappedia.org/wiki/Bootloader_Project


Parrot has modified it with their own bootloader(s) though.
=== Into the Brain ===


Tools to load a different bootloader over UART:
=== login to console on AR.Drone2 via telnet ===
* http://projects.goldelico.com/p/gta04-m … erialBoot/
To connect to AR.Drone2 you need a telnet client, so that you can connect with the busybox telnet server on the AR.Drone2.
When your computer is connected trough wifi with the the AR.Drone2, the drone's IP-address defaults to 192.168.1.1.


Note that you won't be able to use his s-boot.bin, it's for a different board of course.
You can now connect by typing:


You can make the drone look for a bootloader over UART by plugging a device into the USB port. It might also work if you connect pin 2 to a 5v supply (I think this is VUSB in). You'll know it is working because the drone will wait for 2 seconds before you see the "Parrotboot" message.
$ telnet 192.168.1.1


Unlike the v1 there is no "flash via USB/UART" bootloader made available by Parrot, so you will have to make your own. There are 3630 configs for x-loader floating around on the web, but none will work out of the box. You need to modify it to set up the Parrot hardware correctly. And mae sure you set the required config for x-loader to make it ask for a 2nd stage bootloader over UART instead of USB. Maybe check out http://barebox.org too. Some hardware config info might be found in Parrot's GPL kernel modifications.
A busybox welcome message will show when you connect.


You might be able to use similar tools to load bootloaders from USB instead of UART (i.e. similarly to the tools available for the v1), but I personally have not managed to get as far with USB connection as others in this thread. Maybe my pins are broken.
It is convenient to make a hosts definition so you can type:


Some complications you will run into:
$ telnet ardrone2


# I found that even though I could upload a first stage bootloader via UART and the drone would try to execute it, the "regular" boot never stopped so it was hard to see what was going on. I also think I was getting errors on the upload, checksums failing etc.
You do this by adding <code>192.168.1.1 ardrone2</code> to /etc/hosts
# The serial number of your drone hardware is embedded in the NAND flash filesystem. When the Parrot kernel boots and tries to run, it checks this. So overwriting the system partition with one from a working drone will not work. You would need to reverse engineer this process somehow.


If you are were willing to spend another 6 weeks on it, try this:
=== Change WiFi channel ===


# Get a bootloader working - x-loader, u-boot, barebox etc
Sometimes it is nice to be able to change a Wifi channel in an area where there a lot of Wifi devices are in one place. Do it via:
# Try to get installer.plf to execute. Maybe it will ask for ardrone2_update.plf and execute it. If you're lucky, your broken files will be amongst those updated.
# If that fails, try to get to the point where you can mount the NAND filesystem, and modify it by hand.


http://embedded-software.blogspot.nl/2010/12/ar-drone-usb.html
  # iwconfig ath0 channel X commit


= AR.Drone 1.0 =
=== Connect via a router ===


Some information on the AR.Drone 1.0 is still relevand for the AR.Drone 2.0
To have a more flexible network setting the drone to use a router would be a good device to use. [[ardrone2userouter | This page explains how to use a router icw a AR.Drone 2.0]]
'+ BELOW FOR AR-DRONE 1 (ONE)+'


* http://awesome-drone.blogspot.nl/2011/01/ardrone-mainboard-overview.html
=== Eclipse Post-build steps ===
* http://arsmash.blogspot.nl/2011/04/watchdog-command.html
* http://blog.perquin.com/blog/ar-drone-gpio/


== Boot sequence 1.0 ==
While developing with the arm [toolchain] to create some test applications for AR.Drone2 we used a post-build step to quickly upload the file from development computer to the AR.Drone2.


A.R. Drone's boot sequence
publish.sh
 
echo "Release script"
In order to be able to flash a custom kernel to A.R. Drone, it is necessary to understand it's boot sequence:
 
# first call a telnet script that stops the test program
    After reset, the program counter starts at the beginning P6 internal ROM. In this internal ROM, some kind of pre-bootloader exists that evaluates external pins and selects the corresponding boot mode (e.g. boot over USB, NAND, IIC, UART, ... ). Depending on the selected mode, the peripherals are set-up and it is tried to boot over this peripheral.
/home/dhensen/telnet_stop_script.sh | telnet
        Boot over NAND: The pre-bootloader starts the memory controller, copies the bootloader from NAND to internal RAM and sets the program counter to the address in internal RAM which basically starts the bootloader.
        Boot over USB: The pre-bootloader listens to USB and waits for the "Hello P6" command. If received, it replies and awaits an image (the usb_bootloader.bin). The received data is copied to internal RAM and the program counter is changed to the internal RAM address wich in effect starts the bootloader.
# requires having 192.168.1.1 ardrone2 in /etc/hosts
ftp ardrone2 <<END_SCRIPT
# type an arbitrary username on the next line
dhensen
# change the source and target dir to fullfill your needs
put /home/dhensen/workspace/test/Release/test /bin/test
quit
END_SCRIPT
# lastly call a telnet script that gives the test program the right permissions
/home/dhensen/telnet_permission.sh | telnet
exit 0


    Depending on the started bootloader, either the UBI partitions are "mounted" and the kernel image is read or the bootloader waits until the kernel image is sent over USB.
telnet_stop_script.sh
    If the installer.plf (which is basically a kernel image) is booted over USB, the "init" command of this image awaits the actual firmware (ardrone_update.plf) over USB and installs the content to NAND.
#!/bin/sh
host=ardrone2
port=23
login=notneeded
passwd=notneeded
cmd="killall -9 test"
echo open ${host} ${port}
sleep 0.1
echo ${cmd}
sleep 0.1
echo exit


== Custom firmware ==
telnet_permission.sh
#!/bin/sh
host=ardrone2
port=23
login=notneeded
passwd=notneeded
cmd="chmod 777 /data/video/bin/test"
echo open ${host} ${port}
sleep 0.1
echo ${cmd}
sleep 0.1
echo exit


Reading navigation data directly from Navboard
You can use publish.sh in eclipse by opening Project Properties -> C/C++ Build -> Settings -> Build Steps.
On A.R. Drones navigation board, the following sensors exist:
Then in the Post-build steps section in the Command field type: /<your_path_to_file>/publish.sh while replacing your_path_to_file with the path where you saved publish.sh.


    IDG-500 (Dual-axis gyroscope)
After building this script will now push your program called <code>test</code> to the AR.Drone2 automatically. This saves a lot of time, but you still have to run it yourself or adapt the script above to run it automatically. We did not require an automatic run script so we left it out here.
    XV-3500CB (Z-axis gyroscope)
    BMA150 (3-axis accelerometer)
    Some ultrasonic stuff


For handling these sensors, a PIC24 is used. This device does the A/D conversion of the gyroscope data and the I2C communication with the BMA150.
[[Category: AR Drone 2]]
Periodically, the sensor data is sent over UART to the mainboard where it is used by program.elf to control the Drone.


So... how to get this data without using program.elf?
=== Console Fixing ===


First, start the sensor acquisition by calling:
==== The traditional pinout ====


echo -e -n "\1" > /dev/ttyPA2
[[File:Ardrone2_hw1.jpg]]


Now, periodically, the nav boards sends a 0x2E sized frame to UART2.. so read it with:
==== Hardware V2 ====


dd if=/dev/ttyPA2 count=1 bs=46 | hexdump -C
The new 6 pin of 2013 PCB design. '''Warning''', mind pin 1, there is the full 12V battery voltage! Access the port via /dev/ttyO3


The data seems to have the following format:
[[File:ArDrone2_SerialConsoleNewPinout2013.jpg]]


struct nav_data_tag
==== View Printf ====
{
  u16 size;                /* +0x00 Size of the following data (0x2C) */
  u16 sequence;            /* +0x02 Sequence number */
  u16 raw_accs[3];        /* +0x04 Raw data of the accelerometers*/
  u16 raw_gyros[3];        /* +0x0A Raw data for the gyros */
  u16 raw_gyros_110[2];    /* +0x10 4.5x Raw data (IDG) */
  u16 uk_0x14;            /* +0x14 Unkown. Maybe accs temperature */
  u16 gyro_temp;          /* +0x16 Gyro temperature (IDG) */
  u16 vrefEpson;          /* +0x18 Gyro v_ref (Epson) */
  u16 vrefIDG;            /* +0x1A Gyro v_ref (IDG) */
  u16 uk_0x1C;            /* Unkown */
  u16 checksum;            /* +0x1E Checksum */
  u16 us_debut_echo;      /* +0x20 Ultrasonic parameter */
  u16 us_fin_echo;        /* +0x22 Ultrasonic parameter */
  u16 us_association_echo; /* +0x24 Ultrasonic parameter */
  u16 us_distance_echo;    /* +0x26 Ultrasonic parameter */
  u16 us_courbe_temps;    /* +0x28 Ultrasonic parameter */
  u16 us_courbe_valeur;    /* +0x2A Ultrasonic parameter */
  u16 us_courbe_ref;      /* +0x2C Ultrasonic parameter */
}


I haven't figured out much yet, but here are my first analysis results:
First upload from paparazzi center, then telenet into you Drone's brain:
 
$ telnet 192.168.1.1
 
On the Drone to show all running processed:
 
# ps -aux
 
To kill AP process:


    size: always 0x2C
# killall -9 ap.elf
    sequence: increases every update
    raw_accs: seems to contain the BMA values left-shifted by 2
    raw_gyros: 12-bit A/D converted voltage of the gyros
    raw_gyros_110: gyro values wieth another resolution (see IDG-500 datasheet)
    gyro_temp: 12-bit A/D converted voltage of IDG's temperature sensor
    vrefEpson: 12-bit A/D converted reference voltage of the Epson sensor
    vrefIDG: as vrefEpson, but for IDG sensor
    checksum: checksum (have to figure out how to calculate..
    all others haven't yet figured out what they mean


Posted by es at 8:33 PM 9 comments
To restart the main autopilot PPRZ process:
Email ThisBlogThis= Share to TwitterShare to Facebook
Labels: A.R. Drone
Wednesday, January 19, 2011
Creating, testing (and flashing -- TBD) a custom kernel
In my last post, I announced that creating and uploading a custom kernel works. Now I will explain how this can be done.


Thanks to MAPGPS from http://www.ardrone-flyers.com for testing my tools.
# cd /data/video/paparazzi
# ./ap.elf


You need:
=== Debugging ===


- Linux= I used Ubuntu 10.10
==== Serial Console Cable ====
- ARDrone linux kernel source (get it from [1])
- ARDrone linux kernel config (get it from [2])
- The Sourcery G++ toolchain (get it from [3] or [4] )
- My plftool, usb_flash tool (see below)
- The old parrot flash tool (for ardrone_usb_bootloader.bin)
- libusb-0.1 (linux) or libusb-win32 (windows)
- zlib


Via the bottom USB port


Getting & Compiling plftool + usb_flash tool
Debugging is much easier if we have a console cable. For this your USB to serial terminal cable is connected on /dev/ttyUSB0, found via e.g.


These tools are not yet released. Thus I will not provide binaries for windows, instead you have to compile them by yourself. For windows, you need to use mingw32.
$ dmesg


Getting the sources
To login to the drone in your regular Linux terminal use:


The sources are stored at my google code project. In order to get them, you need to install a svn client. For linux you then call something like this:
$ screen /dev/ttyUSB0 115200


svn checkout http://ardrone-tool.googlecode.com/svn/projects/libplf/trunk libplf
=== Repair firmware via serial connection ===
svn checkout http://ardrone-tool.googlecode.com/svn/projects/usb_flash/trunk usb_flash
svn checkout http://ardrone-tool.googlecode.com/svn/projects/plftool/trunk plftool


Compiling
Sometimes your AR.Drone 2.0 is quite messed up since you e.g .deleted some crucial files needed to boot your drone. You need to have a serial cable


Now that you got the sources, you need to compile them. First start with libplf as this is needed by all projects. The library contains the code to read and write .plf files.
http://forum.parrot.com/ardrone/en/viewtopic.php?id=5331


$ cd libplf
=== Repairing Firmware ===
$ make
$ cd ..


When compiling with mingw32 call "make -f Makefile.w32" instead.
If your ARdrone2 is really inaccessible, a.k.a. bricked, there is work for you to be done, sice so far no one managed to flash the firmware with external opensource tools. Theoretically possible, just n one ever managed.


If libplf was compiled succesfully you should get either a libplf.so or libplf.dll file.
=== Downgrade firmware ===
Next compile plftool and usb_flash:


  $ cd plftool
  If you would like to downgrade, upgrade, or re-install firmware you can do so at your own risk by using these files and instructions.
$ make
$ cd ..
$ cd usb_flash
$ make
$ cd ..


When compiling with mingw32, call "make -f Makefile.w32" instead.
Abbreviated instructions:


This should create plftool(.exe) and usb_flash(.exe).
* Download the version you want below. (Don’t change the filename.)
* Power up your AR.Drone
* Connect your computer to the AR.Drone’s network
* Open a telnet session to 192.168.1.1
* type the following:  echo “1.1.1″ > /firmware/version.txt
* press enter
* type the following:  echo “1.1.1″ > /update/version.txt
* Connect an FTP client to 192.168.1.1 Port: 5551
* Upload the downloaded plf file to the FTP server (AR.Drone)
* Disconnect your computer from the AR.Drone
*  Disconnect the battery from the AR.Drone
* Reconnect the battery
* Wait about 5 minutes while the upgrade completes, leave your drone switched on=


For Linux, if you do not want to install the libplf.so file, you need to call plftool and usb_flash with LD_LIBRARY_PATH=<path_to_the_folder_where_libplf.so_is_located>  prefix.
=== GDB ===


E.g.
The Drone has GDB (GNU Debugger) installed by default


LD_LIBRARY_PATH=/home/$USER/projects/ardrone/tools/libplf plftool
Connect to GDB via: {TODO}


For Windows, you need to add the folder where libplf.dll is located to your PATH variable before calling usb_flash or plftool.
== Boot sequence ==


Patching the kernel
Note that this section of the page is a work in progress, lease add more info if you have discovered more infrmation.


As Parrot's published source code does not match the kernel delivered with firmware > 1.3.3, a patch is required to ensure correct behaviour. This patch mainly affects p6_sdhci.c.
http://omappedia.org/wiki/Bootloader_Project


You can get the patch from here. To apply it, just call:
The drone 2.0 is based on a Texas Instruments OMAP3630, modified of course.


$ cd linux-2.6.27
v1 process (it's similar but not the same, and there is no "load from USB" bootloader available for the 2.0 like there was for the v1):
$ patch -p1 < p6_sdhci-patch1.patch
http://embedded-software.blogspot.co.uk


Compiling the kernel
How the boot process works:
Now as the kernel is patched, you should use Parrot's original config [2] and cross-compile the sources with Sourcery G++. Basically you need to do something like this (don't forget to add the Sourcery' bin directory to your PATH):
* http://omappedia.org/wiki/Bootloader_Project


$ cp ARDrone_Version_20100809_1_2-busybox.config .config
Parrot has modified it with their own bootloader(s) though.
$ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- zImage


After a few minutes (or hours) make informs you that the zImage file is available:
Tools to load a different bootloader over UART:
* http://projects.goldelico.com/p/gta04-m … erialBoot/


Kernel: arch/arm/boot/Image is ready
Note that you won't be able to use his s-boot.bin, it's for a different board of course.
Kernel: arch/arm/boot/zImage is ready


Creating a kernel.plf file
You can make the drone look for a bootloader over UART by plugging a device into the USB port. It might also work if you connect pin 2 to a 5v supply (I think this is VUSB in). You'll know it is working because the drone will wait for 2 seconds before you see the "Parrotboot" message.


If you got your zImage, it is time to build a kernel.plf file from it. This is done by plftool. plftool expects a build-ini file that describes the plf file. A sample ini file can be found at plftool/samples/kernel. Using the sample kernel.ini, you only have to modify the "File=" parameters in section "[zImage]" and "[BootParams]" so they point to the zImage file and to a text file, the boot parameters are located in (e.g. called bootparams.txt).
Unlike the v1 there is no "flash via USB/UART" bootloader made available by Parrot, so you will have to make your own. There are 3630 configs for x-loader floating around on the web, but none will work out of the box. You need to modify it to set up the Parrot hardware correctly. And mae sure you set the required config for x-loader to make it ask for a 2nd stage bootloader over UART instead of USB. Maybe check out http://barebox.org too. Some hardware config info might be found in Parrot's GPL kernel modifications.


To create the kernel.plf from the kernel.ini, just call:
You might be able to use similar tools to load bootloaders from USB instead of UART (i.e. similarly to the tools available for the v1), but I personally have not managed to get as far with USB connection as others in this thread. Maybe my pins are broken.


$ plftool -b kernel.ini -o kernel.plf
Some complications you will run into:


The tool should output something similar to this and create the kernel.plf file.
# I found that even though I could upload a first stage bootloader via UART and the drone would try to execute it, the "regular" boot never stopped so it was hard to see what was going on. I also think I was getting errors on the upload, checksums failing etc.
# The serial number of your drone hardware is embedded in the NAND flash filesystem. When the Parrot kernel boots and tries to run, it checks this. So overwriting the system partition with one from a working drone will not work. You would need to reverse engineer this process somehow.


Creating kernel.plf based on this config:
If you are were willing to spend another 6 weeks on it, try this:
File [HdrVersion: 11 EntryPoint: 0x40800000; Version: 0.0.0
TargetPlat=4, TargetAppl=78, HwCompat=0, LangZone=0]
  zImage    @ 0x40800000 (zImage)
  initrd    @ ---------- (no initrd)
  bootparams @ 0x40700000 (bootparams.txt)


*** kernel.plf created ***
# Get a bootloader working - x-loader, u-boot, barebox etc
# Try to get installer.plf to execute. Maybe it will ask for ardrone2_update.plf and execute it. If you're lucky, your broken files will be amongst those updated.
# If that fails, try to get to the point where you can mount the NAND filesystem, and modify it by hand.


Testing the kernel.plf file
http://embedded-software.blogspot.nl/2010/12/ar-drone-usb.html
If  kernel.plf file was created, it is time to test this file. First inspect it with plftool:


$ plftool -d -i kernel.plf
== AR.Drone 1.0 ==


Have a look at dwFileType, dwEntryPoint and Section->LoadAddr.
Some information on the AR.Drone 1.0 is still relevand for the AR.Drone 2.0
'+ BELOW FOR AR-DRONE 1 (ONE)+'


If it looks okay, it is time to start (not flash= ) the kernel:
* http://awesome-drone.blogspot.nl/2011/01/ardrone-mainboard-overview.html
* http://arsmash.blogspot.nl/2011/04/watchdog-command.html
* http://blog.perquin.com/blog/ar-drone-gpio/


# Copy ardrone_usb_bootloader.bin to the folder of usb_flash
=== Boot sequence 1.0 ===
# Connect the drone to your PC via USB (the LED should be RED)
# Connect the BATTERY to your drone (the LED becomes GREEN)
# Check if the device was found (with lsusb)
# Start usb_flash in TEST mode:


usb_flash -t kernel.plf
A.R. Drone's boot sequence


This will load (NOT flash) the kernel over USB. In general, it is helpful to observe A.R. Drone's serial port, as the whole boot sequence is shown there. usb_flash outputs on success:
In order to be able to flash a custom kernel to A.R. Drone, it is necessary to understand it's boot sequence:


...
    After reset, the program counter starts at the beginning P6 internal ROM. In this internal ROM, some kind of pre-bootloader exists that evaluates external pins and selects the corresponding boot mode (e.g. boot over USB, NAND, IIC, UART, ... ). Depending on the selected mode, the peripherals are set-up and it is tried to boot over this peripheral.
        Boot over NAND: The pre-bootloader starts the memory controller, copies the bootloader from NAND to internal RAM and sets the program counter to the address in internal RAM which basically starts the bootloader.
        Boot over USB: The pre-bootloader listens to USB and waits for the "Hello P6" command. If received, it replies and awaits an image (the usb_bootloader.bin). The received data is copied to internal RAM and the program counter is changed to the internal RAM address wich in effect starts the bootloader.


Mode: kernel test
    Depending on the started bootloader, either the UBI partitions are "mounted" and the kernel image is read or the bootloader waits until the kernel image is sent over USB.
    If the installer.plf (which is basically a kernel image) is booted over USB, the "init" command of this image awaits the actual firmware (ardrone_update.plf) over USB and installs the content to NAND.


*** VERIFICATION ***
=== Custom firmware ===
Verifying ardrone_usb_bootloader.bin
Verifying test_kernel.plf


Reading navigation data directly from Navboard
On A.R. Drones navigation board, the following sensors exist:


*** DOWNLOADING USB BOOTLOADER ***
    IDG-500 (Dual-axis gyroscope)
Try [00/10] to connect to VID: 0x19cf PID: 0x1000
    XV-3500CB (Z-axis gyroscope)
Found a possible device:
    BMA150 (3-axis accelerometer)
- Manufacturer: Parrot SA
    Some ultrasonic stuff
- Product: P6 USB Stage1
 
- Serialnumber: ?
For handling these sensors, a PIC24 is used. This device does the A/D conversion of the gyroscope data and the I2C communication with the BMA150.
- Number of configurations: 1
Periodically, the sensor data is sent over UART to the mainboard where it is used by program.elf to control the Drone.
Sending bootloader (0x5b20 bytes)
 
- Send Hello P6 (0xA3)
So... how to get this data without using program.elf?
Success===
 
First, start the sensor acquisition by calling:


Checksum returned: 0x5256 Expected: 0x5256 => OK
echo -e -n "\1" > /dev/ttyPA2
Starting the bootloader...


*** INSTALLER DOWNLOAD ***
Now, periodically, the nav boards sends a 0x2E sized frame to UART2.. so read it with:
Closing usb connection...
Try [00/10] to connect to VID: 0x19cf PID: 0x1000
Found a possible device:
- Manufacturer: Parrot SA
- Product: P6 USB Stage1
- Serialnumber: ?
- Number of configurations: 1
loading installer
Uploading file: test_kernel.plf
Error Code returned: 0x00000000  ==> OK
*** INSTALLATION DONE ***


If everything works, the kernel boots up, WiFi ist started and you should be able to connect to the drone with telnet.
dd if=/dev/ttyPA2 count=1 bs=46 | hexdump -C


Check the kernel version with
The data seems to have the following format:


uname -a
struct nav_data_tag
 
{
If the default kernel starts without problems, you can now begin to modify the kernel config.
  u16 size;                /* +0x00 Size of the following data (0x2C) */
Flashing the kernel to NAND works but I still need to modify the plftool.. so stay tuned.
  u16 sequence;            /* +0x02 Sequence number */
 
  u16 raw_accs[3];        /* +0x04 Raw data of the accelerometers*/
Happy hacking :-)
  u16 raw_gyros[3];        /* +0x0A Raw data for the gyros */
 
  u16 raw_gyros_110[2];    /* +0x10 4.5x Raw data (IDG) */
# https://projects.ardrone.org/documents/show/19
  u16 uk_0x14;            /* +0x14 Unkown. Maybe accs temperature */
# https://projects.ardrone.org/documents/show/18
  u16 gyro_temp;          /* +0x16 Gyro temperature (IDG) */
# https://projects.ardrone.org/documents/show/20
  u16 vrefEpson;          /* +0x18 Gyro v_ref (Epson) */
# http://www.codesourcery.com/sgpp/lite/arm/portal/release858
  u16 vrefIDG;            /* +0x1A Gyro v_ref (IDG) */
Posted by es at 2:23 AM 7 comments
  u16 uk_0x1C;            /* Unkown */
Email ThisBlogThis= Share to TwitterShare to Facebook
  u16 checksum;            /* +0x1E Checksum */
Labels: A.R. Drone, Custom Kernel, Flashing
  u16 us_debut_echo;      /* +0x20 Ultrasonic parameter */
Tuesday, January 11, 2011
  u16 us_fin_echo;        /* +0x22 Ultrasonic parameter */
Creating + Flashing Custom Kernel
  u16 us_association_echo; /* +0x24 Ultrasonic parameter */
Yeah...
  u16 us_distance_echo;    /* +0x26 Ultrasonic parameter */
  u16 us_courbe_temps;    /* +0x28 Ultrasonic parameter */
  u16 us_courbe_valeur;    /* +0x2A Ultrasonic parameter */
  u16 us_courbe_ref;      /* +0x2C Ultrasonic parameter */
}


Creating a kernel.plf file from zImage+initrd --> WORKS=
I haven't figured out much yet, but here are my first analysis results:
Booting this kernel.plf file over USB --> WORKS=
Flashing this kernel.plf to NAND --> to be done...


More will follow soon :-)
    size: always 0x2C
Posted by es at 11:53 PM 1 comments
    sequence: increases every update
    raw_accs: seems to contain the BMA values left-shifted by 2
    raw_gyros: 12-bit A/D converted voltage of the gyros
    raw_gyros_110: gyro values wieth another resolution (see IDG-500 datasheet)
    gyro_temp: 12-bit A/D converted voltage of IDG's temperature sensor
    vrefEpson: 12-bit A/D converted reference voltage of the Epson sensor
    vrefIDG: as vrefEpson, but for IDG sensor
    checksum: checksum (have to figure out how to calculate..
    all others haven't yet figured out what they mean
 
Posted by es at 8:33 PM 9 comments
Email ThisBlogThis= Share to TwitterShare to Facebook
Email ThisBlogThis= Share to TwitterShare to Facebook
Labels: A.R. Drone, Custom Kernel, Flashing
Labels: A.R. Drone
Sunday, January 9, 2011
Wednesday, January 19, 2011
Tools for A.R. Drone
Creating, testing (and flashing -- TBD) a custom kernel
I finally released some tools for A.R. Drone:
In my last post, I announced that creating and uploading a custom kernel works. Now I will explain how this can be done.
 
Thanks to MAPGPS from http://www.ardrone-flyers.com for testing my tools.


    libplf - A library to read / write plf files
You need:
    plf_inst_extract - A tool to extract and patch a ardrone_installer.plf from a given ardrone_update.plf
    usb_flash - A tool to flash a ardrone_update.plf over USB. This tool requires:
        ardrone_update.plf - the firmware to flash
        ardrone_installer.plf - can be obtained from ardrone_update.plf with plf_inst_extract
        ardrone_usb_bootloader.bin - was delivered with the old flash tool. I will probably write an open-source boot loader sooner or later.


Have a look at my goolge code project:
- Linux=  I used Ubuntu 10.10
- ARDrone linux kernel source (get it from [1])
- ARDrone linux kernel config (get it from [2])
- The Sourcery G++ toolchain (get it from [3] or [4] )
- My plftool, usb_flash tool (see below)
- The old parrot flash tool (for ardrone_usb_bootloader.bin)
- libusb-0.1 (linux) or libusb-win32 (windows)
- zlib


http://code.google.com/p/ardrone-tool
Getting & Compiling plftool + usb_flash tool
Posted by es at 2:17 AM 0 comments
Email ThisBlogThis= Share to TwitterShare to Facebook
Labels: A.R. Drone, Flashing, USB
A.R. Drone's boot sequence
In order to be able to flash a custom kernel to A.R. Drone, it is necessary to understand it's boot sequence:


    After reset, the program counter starts at the beginning P6 internal ROM. In this internal ROM, some kind of pre-bootloader exists that evaluates external pins and selects the corresponding boot mode (e.g. boot over USB, NAND, IIC, UART, ... ). Depending on the selected mode, the peripherals are set-up and it is tried to boot over this peripheral.
These tools are not yet released. Thus I will not provide binaries for windows, instead you have to compile them by yourself. For windows, you need to use mingw32.
        Boot over NAND: The pre-bootloader starts the memory controller, copies the bootloader from NAND to internal RAM and sets the program counter to the address in internal RAM which basically starts the bootloader.
        Boot over USB: The pre-bootloader listens to USB and waits for the "Hello P6" command. If received, it replies and awaits an image (the usb_bootloader.bin). The received data is copied to internal RAM and the program counter is changed to the internal RAM address wich in effect starts the bootloader.


    Depending on the started bootloader, either the UBI partitions are "mounted" and the kernel image is read or the bootloader waits until the kernel image is sent over USB.
Getting the sources
    If the installer.plf (which is basically a kernel image) is booted over USB, the "init" command of this image awaits the actual firmware (ardrone_update.plf) over USB and installs the content to NAND.


= Flightgear =
The sources are stored at my google code project. In order to get them, you need to install a svn client. For linux you then call something like this:


This section will explain the installation of FlightGear and the creation of an visual model for Flightgear.
svn checkout http://ardrone-tool.googlecode.com/svn/projects/libplf/trunk libplf
svn checkout http://ardrone-tool.googlecode.com/svn/projects/usb_flash/trunk usb_flash
svn checkout http://ardrone-tool.googlecode.com/svn/projects/plftool/trunk plftool


[[Image:Flightgear Screenshot indoor.png|thumb|right|400px|An example AR.Drone flying in FlightGear]]
Compiling


== Download FlightGear ==
Now that you got the sources, you need to compile them. First start with libplf as this is needed by all projects. The library contains the code to read and write .plf files.


FlightGear can be downloaded from http://www.flightgear.org/download/ . Installation should be self-explanatory. The aircraft models will be located in: (...\FlightGear\Data\Aircraft).
$ cd libplf
$ make
$ cd ..


== Visual model ==
When compiling with mingw32 call "make -f Makefile.w32" instead.


Flightgear uses .ac files from the AC3D program, a 3D design program by Inivis[http://www.inivis.com/]. A free alternative is Blender[http://www.blender.org/], which can export its files to the .ac format with a plugin[http://wiki.blender.org/index.php/Extensions:2.4/Py/Scripts/Export/AC3D] (instructions on how to install also found in link).
If libplf was compiled succesfully you should get either a libplf.so or libplf.dll file.
Next compile plftool and usb_flash:


Our minor group used an existing model[http://grabcad.com/library/ar-drone-parrot], (registering required), which we exported to .stl in Autodesk. Then we imported the .stl files with Blender, and exported them again in the required .ac format.
$ cd plftool
$ make
$ cd ..
$ cd usb_flash
$ make
$ cd ..


=== Moving parts ===
When compiling with mingw32, call "make -f Makefile.w32" instead.


To use animated moving parts in the model, all the moving parts have to be exported individually. All parts are linked together by the model's set file.
This should create plftool(.exe) and usb_flash(.exe).


== Setting up the folder ==
For Linux, if you do not want to install the libplf.so file, you need to call plftool and usb_flash with LD_LIBRARY_PATH=<path_to_the_folder_where_libplf.so_is_located> prefix.
Inside your aircraft folder (...\FlightGear\Data\Aircraft\"Aircraft name"), a .xml file is needed to enable Flightgear to load the model. This file should be named as: "Aircraft name"-set.xml. Inside, it links to main visual model file. All visual model files should go into the "Models" folder of the aircraft: (...\FlightGear\Data\Aircraft\"Aircraft name"\Models). The main .xml file should indicate the lay-out of the model (see Example files).


=== Clarification of the .xml files ===
E.g.
main.xml:


The .ac file contains the body model of the quadrotor:
  LD_LIBRARY_PATH=/home/$USER/projects/ardrone/tools/libplf plftool
  <path>myquadrotor.ac</path>


The 4 <model> nodes contain information about the location and orientation of the propellors. The <path> links to the location of the engine file. The <offsets> manually places the propellors in (about) the right place. This has no consequences for the performance of the aircraft. For the FlightGear coordinate system, see: [http://www.city-gallery.com/knoblock/projects/flightgear/Docs/coords.html]. The <pitch/yaw/roll-deg> can be used if the imported file has the wrong orientation.
For Windows, you need to add the folder where libplf.dll is located to your PATH variable before calling usb_flash or plftool.


  <model>
Patching the kernel
<!-- LF -->
  <name>Engine1</name>
  <path>Aircraft/myquadrotor/Models/engine1.xml</path>
  <offsets>
    <x-m>0.3</x-m>
    <y-m>-0.2</y-m>
    <z-m>0.0</z-m>
    <pitch-deg>0</pitch-deg>
  </offsets>
  </model>


Using <offsets> the orientation of the model was corrected:
As Parrot's published source code does not match the kernel delivered with firmware > 1.3.3, a patch is required to ensure correct behaviour. This patch mainly affects p6_sdhci.c.
 
  <offsets>
  <heading-deg>270</heading-deg>
  </offsets>


You can get the patch from here. To apply it, just call:


engine1.xml:
$ cd linux-2.6.27
$ patch -p1 < p6_sdhci-patch1.patch


Contains the model of the rotor:
Compiling the kernel
<path>rotor.ac</path>
Now as the kernel is patched, you should use Parrot's original config [2] and cross-compile the sources with Sourcery G++. Basically you need to do something like this (don't forget to add the Sourcery' bin directory to your PATH):


<Animation> is used for the animation of the propeller. You can declare the type of animation (spin), the center of the animation, around which axis to spin and in which direction (clockwise or ccw).  
$ cp ARDrone_Version_20100809_1_2-busybox.config .config
  <animation>
$ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- zImage
  <type>spin</type>
  <object-name>propeller</object-name>
  <property>engines/engine[0]/rpm</property>
  <factor>1</factor> 
  <centre>
    <x-m>0</x-m>
    <y-m>0</y-m>
    <z-m>0</z-m>
  </centre>
  <axis>
    <x>0</x>
    <y>0</y>
    <z>-1</z>
  </axis>
  </animation>


== Example files ==
After a few minutes (or hours) make informs you that the zImage file is available:
main.xml file:
 
<PropertyList>
Kernel: arch/arm/boot/Image is ready
  <path>myquadrotor.ac</path>
Kernel: arch/arm/boot/zImage is ready
 
  <model>
Creating a kernel.plf file
<!-- LF -->
 
  <name>Engine1</name>
If you got your zImage, it is time to build a kernel.plf file from it. This is done by plftool. plftool expects a build-ini file that describes the plf file. A sample ini file can be found at plftool/samples/kernel. Using the sample kernel.ini, you only have to modify the "File=" parameters in section "[zImage]" and "[BootParams]" so they point to the zImage file and to a text file, the boot parameters are located in (e.g. called bootparams.txt).
  <path>Aircraft/myquadrotor/Models/engine1.xml</path>
 
  <offsets>
To create the kernel.plf from the kernel.ini, just call:
    <x-m>0.3</x-m>
 
    <y-m>-0.2</y-m>
  $ plftool -b kernel.ini -o kernel.plf
    <z-m>0.0</z-m>
 
    <pitch-deg>0</pitch-deg>
The tool should output something similar to this and create the kernel.plf file.
  </offsets>
 
  </model>
Creating kernel.plf based on this config:
File [HdrVersion: 11 EntryPoint: 0x40800000; Version: 0.0.0
  <model>
TargetPlat=4, TargetAppl=78, HwCompat=0, LangZone=0]
  <!-- RB -->
   zImage    @ 0x40800000 (zImage)
  <name>Engine2</name>
   initrd    @ ---------- (no initrd)
  <path>Aircraft/myquadrotor/Models/engine2.xml</path>
  bootparams @ 0x40700000 (bootparams.txt)
  <offsets>
 
    <x-m> -0.3</x-m>
*** kernel.plf created ***
    <y-m>0.2</y-m>
 
    <z-m> 0.0</z-m>
Testing the kernel.plf file
    <pitch-deg>0</pitch-deg>
If kernel.plf file was created, it is time to test this file. First inspect it with plftool:
  </offsets>
 
   </model>
  $ plftool -d -i kernel.plf
 
   <model>
Have a look at dwFileType, dwEntryPoint and Section->LoadAddr.
<!-- RF -->
 
  <name>Engine3</name>
If it looks okay, it is time to start (not flash= ) the kernel:
  <path>Aircraft/myquadrotor/Models/engine3.xml</path>
 
  <offsets>
# Copy ardrone_usb_bootloader.bin to the folder of usb_flash
    <x-m>-0.3</x-m>
# Connect the drone to your PC via USB (the LED should be RED)
    <y-m>-0.2</y-m>
# Connect the BATTERY to your drone (the LED becomes GREEN)
    <z-m> 0.0</z-m>
# Check if the device was found (with lsusb)
    <pitch-deg>0</pitch-deg>
# Start usb_flash in TEST mode:
  </offsets>
 
  </model>
usb_flash -t kernel.plf
   
 
  <model>
This will load (NOT flash) the kernel over USB. In general, it is helpful to observe A.R. Drone's serial port, as the whole boot sequence is shown there. usb_flash outputs on success:
  <!-- LB -->
 
  <name>Engine4</name>
...
  <path>Aircraft/myquadrotor/Models/engine4.xml</path>
 
  <offsets>
Mode: kernel test
    <x-m> 0.3</x-m>
    <y-m> 0.2 </y-m>
    <z-m> 0.0</z-m>
    <pitch-deg>0</pitch-deg>
  </offsets>
  </model>
  <offsets>
  <heading-deg>270</heading-deg>
  </offsets>
</PropertyList>


engine1.xml file:
*** VERIFICATION ***
Verifying ardrone_usb_bootloader.bin
Verifying test_kernel.plf


<PropertyList>
  <path>rotor.ac</path>
  <animation>
  <type>spin</type>
  <object-name>propeller</object-name>
  <property>engines/engine[0]/rpm</property>
  <factor>1</factor> 
  <centre>
    <x-m>0</x-m>
    <y-m>0</y-m>
    <z-m>0</z-m>
  </centre>
  <axis>
    <x>0</x>
    <y>0</y>
    <z>-1</z>
  </axis>
  </animation>
</PropertyList>


== Eclipse Post-build steps ==
*** DOWNLOADING USB BOOTLOADER ***
 
Try [00/10] to connect to VID: 0x19cf PID: 0x1000
While developing with the arm [toolchain] to create some test applications for AR.Drone2 we used a post-build step to quickly upload the file from development computer to the AR.Drone2.
Found a possible device:
 
- Manufacturer: Parrot SA
publish.sh
- Product: P6 USB Stage1
echo "Release script"
- Serialnumber: ?
- Number of configurations: 1
# first call a telnet script that stops the test program
Sending bootloader (0x5b20 bytes)
/home/dhensen/telnet_stop_script.sh | telnet
- Send Hello P6 (0xA3)
Success===
# requires having 192.168.1.1 ardrone2 in /etc/hosts
ftp ardrone2 <<END_SCRIPT
# type an arbitrary username on the next line
dhensen
# change the source and target dir to fullfill your needs
put /home/dhensen/workspace/test/Release/test /bin/test
quit
END_SCRIPT
# lastly call a telnet script that gives the test program the right permissions
/home/dhensen/telnet_permission.sh | telnet
exit 0


telnet_stop_script.sh
Checksum returned: 0x5256 Expected: 0x5256 => OK
#!/bin/sh
Starting the bootloader...
host=ardrone2
 
port=23
*** INSTALLER DOWNLOAD ***
login=notneeded
Closing usb connection...
passwd=notneeded
Try [00/10] to connect to VID: 0x19cf PID: 0x1000
cmd="killall -9 test"
Found a possible device:
- Manufacturer: Parrot SA
echo open ${host} ${port}
- Product: P6 USB Stage1
sleep 0.1
- Serialnumber: ?
echo ${cmd}
- Number of configurations: 1
sleep 0.1
loading installer
  echo exit
Uploading file: test_kernel.plf
Error Code returned: 0x00000000 ==> OK
*** INSTALLATION DONE ***
 
If everything works, the kernel boots up, WiFi ist started and you should be able to connect to the drone with telnet.


telnet_permission.sh
Check the kernel version with
#!/bin/sh
 
host=ardrone2
uname -a
port=23
 
login=notneeded
If the default kernel starts without problems, you can now begin to modify the kernel config.
passwd=notneeded
Flashing the kernel to NAND works but I still need to modify the plftool.. so stay tuned.
cmd="chmod 777 /data/video/bin/test"
 
Happy hacking :-)
echo open ${host} ${port}
 
sleep 0.1
# https://projects.ardrone.org/documents/show/19
echo ${cmd}
# https://projects.ardrone.org/documents/show/18
sleep 0.1
# https://projects.ardrone.org/documents/show/20
echo exit
# http://www.codesourcery.com/sgpp/lite/arm/portal/release858
Posted by es at 2:23 AM 7 comments
Email ThisBlogThis= Share to TwitterShare to Facebook
Labels: A.R. Drone, Custom Kernel, Flashing
Tuesday, January 11, 2011
Creating + Flashing Custom Kernel
Yeah...
 
Creating a kernel.plf file from zImage+initrd --> WORKS=  
Booting this kernel.plf file over USB --> WORKS=  
Flashing this kernel.plf to NAND --> to be done...
 
More will follow soon :-)
Posted by es at 11:53 PM 1 comments
Email ThisBlogThis= Share to TwitterShare to Facebook
Labels: A.R. Drone, Custom Kernel, Flashing
Sunday, January 9, 2011
Tools for A.R. Drone
I finally released some tools for A.R. Drone:
 
    libplf - A library to read / write plf files
    plf_inst_extract - A tool to extract and patch a ardrone_installer.plf from a given ardrone_update.plf
    usb_flash - A tool to flash a ardrone_update.plf over USB. This tool requires:
        ardrone_update.plf - the firmware to flash
        ardrone_installer.plf - can be obtained from ardrone_update.plf with plf_inst_extract
        ardrone_usb_bootloader.bin - was delivered with the old flash tool. I will probably write an open-source boot loader sooner or later.
 
Have a look at my google code project:
 
http://code.google.com/p/ardrone-tool
Posted by es at 2:17 AM 0 comments
Email ThisBlogThis= Share to TwitterShare to Facebook
Labels: A.R. Drone, Flashing, USB
A.R. Drone's boot sequence
In order to be able to flash a custom kernel to A.R. Drone, it is necessary to understand it's boot sequence:
 
    After reset, the program counter starts at the beginning P6 internal ROM. In this internal ROM, some kind of pre-bootloader exists that evaluates external pins and selects the corresponding boot mode (e.g. boot over USB, NAND, IIC, UART, ... ). Depending on the selected mode, the peripherals are set-up and it is tried to boot over this peripheral.
        Boot over NAND: The pre-bootloader starts the memory controller, copies the bootloader from NAND to internal RAM and sets the program counter to the address in internal RAM which basically starts the bootloader.
        Boot over USB: The pre-bootloader listens to USB and waits for the "Hello P6" command. If received, it replies and awaits an image (the usb_bootloader.bin). The received data is copied to internal RAM and the program counter is changed to the internal RAM address wich in effect starts the bootloader.
 
    Depending on the started bootloader, either the UBI partitions are "mounted" and the kernel image is read or the bootloader waits until the kernel image is sent over USB.
    If the installer.plf (which is basically a kernel image) is booted over USB, the "init" command of this image awaits the actual firmware (ardrone_update.plf) over USB and installs the content to NAND.


You can use publish.sh in eclipse by opening Project Properties -> C/C++ Build -> Settings -> Build Steps.
== Datainterchange with other electronics ==
Then in the Post-build steps section in the Command field type: /<your_path_to_file>/publish.sh while replacing your_path_to_file with the path where you saved publish.sh.


After building this script will now push your program called <code>test</code> to the AR.Drone2 automatically. This saves a lot of time, but you still have to run it yourself or adapt the script above to run it automatically. We did not require an automatic run script so we left it out here.
THe Ardrone 2 has various options:


[[Category: AR Drone 2]]
# Use debug serial port
# USB to serial FTDI cable
# Extra Wifi dongle
# USB to Ethernet cable
# LED to PWM in


== Console Fixing ==
== Odroid XU ==


=== The traditional pinout ===
=== Hardware ===


[[File:Ardrone2_hw1.jpg]]
1x FTDO


=== Hardware V2 ===
=== Option ===


The new 6 pin of 2013 PCB design. '''Warning''', mind pin 1, there is the full 12V battery voltage!
== The past ==
 
<pre style="color:red; font-weight:bold;">
Pinout seems wrong for GND: I have it on pin 3 (end 5V on pin 2).
 
It would be good to check it again and that the author of the image update it accordingly (Gautier 6/6/14).
</pre>
 
[[File:ArDrone2_SerialConsoleNewPinout2013.jpg]]
 
=== View Printf ===
 
First upload from paparazzi center
 
telnet 192.168.1.1
ps
killall -9 ap.elf
cd /data/video/raw
./ap.elf
 
= The past =


Some info on older documentation but in certain cases very useful.
Some info on older documentation but in certain cases very useful.


== Reversing ==
=== Reversing ===


Here info of a part of how the electronics where revered to make it possible to run PPRZ
Here info of a part of how the electronics where revered to make it possible to run PPRZ
Line 1,695: Line 1,692:
* https://wiki.paparazziuav.org/wiki/AR_Drone_2/NAV_board
* https://wiki.paparazziuav.org/wiki/AR_Drone_2/NAV_board


== The "SDK" mode ==
=== The "SDK" mode ===


The SDK mode is a thing from the past, '''no real reason to use it''', the links below are left as a reference.
The SDK mode is a thing from the past, '''no real reason to use it''', the links below are left as a reference.


* https://wiki.paparazziuav.org/wiki/AR_Drone_2/AT_Commands
* https://wiki.paparazziuav.org/wiki/AR_Drone_2/AT_Commands
* https://wiki.paparazziuav.org/wiki/AR_Drone_2/GPS


== Past interesting projects ==
=== Past interesting projects ===


As an honor to the developers some links still here what all was achieved in the past:
As an honor to the developers some links still here what all was achieved in the past:
Line 1,712: Line 1,708:
* https://wiki.paparazziuav.org/wiki/OLSR
* https://wiki.paparazziuav.org/wiki/OLSR


= Links =
== Links ==


* [http://ardrone2.parrot.com  Manufacturer's site with all info about AR.Drone2 (Parrot)]
* [http://ardrone2.parrot.com  Manufacturer's site with all info about AR.Drone2 (Parrot)]
* [[http://embedded-software.blogspot.com/2011/01/ar-drones-boot-sequence.html Boot sequence]]
* [http://embedded-software.blogspot.com/2011/01/ar-drones-boot-sequence.html Boot sequence]


* https://play.google.com/store/apps/details?id=com.parrot.freeflight&hl=en
* https://play.google.com/store/apps/details?id=com.parrot.freeflight&hl=en
* https://itunes.apple.com/us/app/ar.race-2/id547160291
* https://itunes.apple.com/us/app/ar.race-2/id547160291


* AR.Drone 2.0 Blog http://blog.parrot.com/category/ar-drone/
* [http://blog.parrot.com/category/ar-drone/ AR.Drone 2.0 Blog]
 
* [http://ardrone2.parrot.com/photos/photo-album/ Press photos]
* [[http://ardrone2.parrot.com/photos/photo-album/ | Press photos]]
* [[AR.Drone 2.0 reviews]]


* [[SDK http://ardrone.parrot.com/parrot-ar-drone/dev/developers | Parrot's own developer zone not PPRZ related]]
* [http://ardrone.parrot.com/parrot-ar-drone/dev/developers Parrot's own developer zone not PPRZ related but sometime handy]
* [[https://projects.ardrone.org/wiki/ardrone-api/Gpl | Open source Software Licences]]
* [https://projects.ardrone.org/wiki/ardrone-api/Gpl Open source Software Licenses]


* [[http://ardrone2.parrot.com/ar-drone-academy/ | AR.Drone Academy]]
* [http://ardrone2.parrot.com/ar-drone-academy/ AR.Drone Academy]


* [[http://www.parrotshopping.com/fr/p_parrot_listing.aspx?f=3377 | Spare parts]]
* [http://www.parrotshopping.com/fr/p_parrot_listing.aspx?f=3377 Spare parts]
* [[http://www.youtube.com/playlist?list=PLDB67195526DEEE63&feature=plcp | Repair videos]]
* [http://www.youtube.com/playlist?list=PLDB67195526DEEE63&feature=plcp Repair videos]


[[Category:AR Drone 2]]
[[Category:AR Drone 2]]

Latest revision as of 06:23, 8 September 2017

Introduction

AR.Drine 2.0

Parrot's AR Drone 2
Exploded view of the AR Drone 2.

So you have this nice Parrot AR.Drone 2.0 and would like to let it perform autonomous flights; You came to the right place. The only thing you need beside an AR.Drone 2.0, is an accurate GPS receiver and a laptop with Ubuntu Linux OS installed.

Replace the current AR.Drone 2.0 brain by uploading paparazzi in current ARM chip and use the aready available sensors. Connect a GPS on the USB port, use Wifi for telemetry and optional manal control.

No soldering or other modifications in the electronics to make. Only with Paparazzi software and a GPS receiver it is possible to let the AR.Drone 2.0 fly autonomous missions under spectacular better control than the original onboard control.

...as simple as that, have fun and try it for yourself...

Help

Paparazzi is a very mature project that has existed since 2003. So your questions concerning paparazzi have possibly already been asked and answered on theso called "mailing list". It would be best to first read through the mailinglist . If the answer is not there please ask your question on this mailinglist or maybe even via the IRC channel icons on the top of main page. You will find your question is likely addressed within hours or days. Paparazzi is a global project so in most cases somewhere in the world someone is reading your email/question and will reply.

History

On September 3rd 2012 two Delft University of Technology student teams started a new UAV robotics project under the guidance of ing. ir. B. D. W. Remes. Both teams shared a similar objective, namely getting the AR Drone v2.0 to fly autonomously using the advanced opensource Paparazzi Software.

EmbedVideo does not recognize the video service "youtubehd".

Easy

When you have finished you autonomous flight with paparazzi and want to fly with the standard ARDrone2 apps again, just unplugging and re-plugging the battery will make your drone a standard ARDrone2 again.

The Hardware

First some generic information about the airframe hardware just to satisfy curiosity.

HD Video recording

Get high definition live video streaming to your smartphone or tablet as you are flying. See a clean, sharp image just as if you were in the pilot seat.

  • HD Camera. 720p 30fps
  • Wide angle lens : 92° diagonal
  • H264 encoding base profile
  • Low latency streaming
  • Video storage on the fly with the remote device
  • JPEG photo
  • Video storage on the fly with Wi-Fi directly on your remote device or on a USB key

Robust structure

Trying your most daring tricks won’t even challenge this cutting edge design which is made to last.

  • Carbon fiber tubes : Total weight 380g with outdoor hull, 420g with indoor hull
  • High grade 30% fiber charged nylon plastic parts
  • Foam to isolate the inertial center from the engines’ vibration
  • EPP hull injected by a sintered metal mold
  • Liquid Repellent Nano-Coating on ultrasound sensors
  • Fully reparable: All parts and instructions for repairing available on the internet

Electronic assistance

AR.Drone 2.0 on-board technology gives you extreme precision control and automatic stabilization features.

  • 1GHz 32 bit ARM Cortex A8 processor with 800MHz video DSP TMS320DMC64x
  • Linux 2.6.32
  • 1Gbit DDR2 RAM at 200MHz
  • USB 2.0 high speed for extensions
  • Wi-Fi b,g,n
  • 3 axis gyroscope 2000°/second precision
  • 3 axis accelerometer +-50mg precision
  • 3 axis magnetometer 6° precision
  • Pressure sensor +/- 10 Pa precision
  • Ultrasound sensors for ground altitude measurement
  • 60 fps vertical QVGA camera for ground speed measurement

Motor

  • 4 brushless inrunner motors. 14.5W 28,500 RMP
  • Micro ball bearing
  • Low noise Nylatron gears for 1/8.75 propeller reductor
  • Tempered steel propeller shaft
  • Self-lubrificating bronze bearing
  • Specific high propelled drag for great maneuverability
  • 8 MIPS AVR CPU per motor controller
  • 3 elements 1000 mA/H LiPo rechargeable battery (Autonomy: 12 minutes)
  • Emergency stop controlled by software
  • Fully reprogrammable motor controller
  • Water resistant motor’s electronic controller

Autopilot

AP Mainboard

The main board in the AR.Drone 2.0 IS the autopilot

GPS

To fly autonomous to a certain geo coordinate a GNSS receiver device is needed. GNSS stands for Global Navigation Satellite System, and is the standard generic term for satellite navigation systems that provide autonomous geo-spatial positioning with global coverage. This term includes e.g. the GPS, GLONASS, Galileo, Beidou and other regional systems

Although it is theoretically possible to use the original orange Parrot GPS dongle it is not advised, the performance is just not good enough for great autonomous flights. The solution that is advised is to use an uBlox GPS module.

Installation

Prerequisites

To be able to fly your AR.Drone 2.0 you need ARDrone2 firmware v2.4.8 or higher on your ARDrone. And for your Paparazzi GCS laptop it's best to have Ubuntu Linux v14.04 LTS or higher installed

Go to the Operating System and Paparazzi Installation page to follow instructions to install the operating system and Paparazzi.

If you followed the Operating System and Paparazzi Installation page you now have a working fresh install of Ubuntu v12.04 or v14.04 operating system on your Wifi enabled laptop. Newer versions of Ubuntu might work as well, only are never tried at the time of writing.

Note: the above is simply one long command to the Linux command interpreter. The && are simply saying if the command to the left returns successful return code then run the command on the right .. and so on. So if the command fails the rest of the commands to the right will not be executed. It maybe helpful then to simply copy/paste each command one at a time. Just grab between the '&&'

Ubuntu 16.04 LTS and later

With Ubunutu 16.04 and later, the ARM-Linux toolchain provided by the operating system is too recent. Compiling the code is still possible, but running it on the Parrot AR.Drone2 would result of an error message:

FATAL: kernel too old
Segmentation fault

In order to compile with the proper libraries, it is needed to download the toolchain provided by Parrot on their Github Developpers page and get the 2012.03 Debian package file: https://github.com/Parrot-Developers/toolchains/raw/master/parrot-tools-linuxgnutools-2012.03_1.0.0-1_i386.deb. After downloading it, install the package with:

sudo dpkg -i parrot-tools-linuxgnutools-2012.03_1.0.0-1_i386.deb

The toolchain will be installed in your file system in /opt/arm-2012.03 directory. Then you need to tell which compiler should be used for your AR.Drone2 by adding to the firmware section of your airframe file the following line:

<configure name="PREFIX" value="/opt/arm-2012.03/bin/arm-none-linux-gnueabi"/>

Now, the program should compile and run normally. You can check that the correct GCC is used in the Paparazzi center terminal:

GCC version:
arm-none-linux-gnueabi-gcc (Sourcery CodeBench Lite 2012.03-57) 4.6.3

Autonomy

GCS for Paparazzi Parrot AR.Drone 2.0

To give your ARDrone2 the autonomy essential for autonomous flight, the Paparazzi Control Center needs to be started by clicking on the paparazzi icon on your desktop (see installing paparazzi Wiki details).

Paparazzi installed.png

Terminal at the terminal, just cut 'n paste the line below, in your terminal command prompt, then press enter

~/paparazzi/paparazzi

Paparazzi Center will launch for the very first time and show you a screen like this:

Paparazzi Center first start

Now that you have Paparazzi Center running grab your ARDrone2 to set it up for autonomous flight:

  1. Insert the GPS module into your ARDrone2 and power it up by connecting the battery.
  2. Establish a Wifi connection between the ARDrone2 and your laptop

Select ardrone2_v2.4.3 in Wireless Network List Your AR.Drone2 is now connected

At this moment it is important that you have an ARDrone2 that has it's GPS device connected and has established a Wifi connection with your computer. You can now continue uploading the Autopilot to the ARDrone2.

  1. At Paparazzi Center select ardrone2 at the "A/C" drop-down box

Choose ardrone2 from A/C selection

  1. Make sure "ap" (Autopilot) is set as Target
  2. Press the [Upload] button (NOTE: It will show 3 ignored errors, that's fine, don't worry...)

Press Upload

  1. now in In the Paparazzi control center Select Flight UDP/Wifi as session

Select "Flight UDP/Wifi" as session

  1. Press the [Execute] button

Press Execute

Flying

Take your AR Drone and laptop outside. A clear view of the sky is essential for GPS to work properly. A good GPS position signal is necessary for optimal autonomous flight. However GPS is only accurate to within several meters, so make sure you have enough of free space around to let it fly without bumping into something.

After waiting for about a minute a GPS signal will be found. The ARDrone2 location should now appear in your GCS map

GCS for Paparazzi Parrot AR.Drone 2.0

When you fly the first time on this spot you need to download the Google map tiles on to your laptop. Connect your wifi to your wireless router, when you have connection click on the black GCS map. Once downloaded the tiles are saved so you will not need an Internet connection next time. You can also run the GCS in advance, get the tiles, and later fly without an Internet connection.

GCS for Paparazzi Parrot AR.Drone 2.0

and press the keyboard key combination [CTRL+G]. You will see the map appear. When you are done downloading the tiles re-connect to you drone.

GCS for Paparazzi Parrot AR.Drone 2.0

If no Wifi connection is availabe from your laptop to the ARDRone2, you will have a blank screen. That is perfectly normal. Just make sure you make a Wifi connection to your AR drone first.

Takeoff

  1. Press the [Takeoff] button and keep a good eye on where your Drone flies.

Takeoff Paparazzi Parrot AR.Drone 2.0

When all worked out well the drone took off, followed a line back and forth and landed again, congratulations you made your first autonomous flight!

Move waypoints

To have some fun with your AR.Drone 2.0 in flight, one could move the standby waypoint to another location close by.

Home

Home: Let the ARDrone come back where you took off

Home Paparazzi Parrot AR.Drone 2.0

Land

Land: Land the drone where you took off

LAnd Paparazzi Parrot AR.Drone 2.0

Next steps

Now that your Parrot AR.Drone 2.0 flew autonomously you can dive deeper into the world Paparazzi and it's Flight_Plans. Just browse around this Wiki and read and try things that interest you the most, have fun!

Experts

After you have now experienced your first feeling of quite some autonomous flights with your Paparazzi controlled UAV you might want to become an expert on the AR.Drone 2.0. Read on below to be able learn, change and create great new things...

Sign conventions

This section will show the sign conventions used by the SDK of the Parrot AR.Drone 2.0. One can read these values directly from the AR.Drone software. This is a good refference also fro the PPRZ version.

Body axis

Body axis convention

Relevant units:

  • Velocities in x,y,z (Vx, Vy, Vz [mm/s])
  • Accelerations in x,y,z (Ax, Ay, Az [mg])
  • Position in z (altitude [mm])

Angles

Roll convention Pitch convention Yaw convention

Relevant units:

  • Angles psi (yaw), phi (roll), theta (pitch) [mdeg]
  • Rates p (roll rate), q (pitch rate), r (yaw rate) [deg/s]




Simulation

Introduction

This page will guide you through the creation of the mechanical model with JSBSim for Paparazzi.

Setting up the simulation environment

See Setting up simulation environment.

Creating the mechanical model

Not every feature of the JSMSim model is needed for Paparazzi. Below is a list of features that should be included in the .xml file.

  • Header
  • Metrics
  • Mass balance
  • Ground reactions
  • Propulsion

Example .xml file

This section displays a standard .xml file, with some added comments per segment. For a more extensive guide on JSBSim read the extensive JSBSim manual

   <fileheader>
       <author> "Name of author" </author>
       <filecreationdate> "Date of creation" </filecreationdate>
       <version> "Version" </version>
       <description> "Description" </description>
   </fileheader> 

Metrics

Metrics

   <metrics>
       <wingarea unit="IN2"> 0 </wingarea>
       <wingspan unit="IN"> 0 </wingspan>
       <chord unit="IN"> 0 </chord>
       <htailarea unit="FT2"> 0 </htailarea>
       <htailarm unit="FT"> 0 </htailarm>
       <vtailarea unit="FT2"> 0 </vtailarea>
       <vtailarm unit="FT"> 0 </vtailarm>
       <location name="AERORP" unit="IN">
           <x> 0 </x>
           <y> 0 </y>
           <z> 0 </z>
       </location>
       <location name="EYEPOINT" unit="IN">
           <x> 0 </x>
           <y> 0 </y>
           <z> 0 </z>
       </location>
       <location name="VRP" unit="IN">
           <x> 0 </x>
           <y> 0 </y>
           <z> 0 </z>
       </location>
   </metrics>

Mass balance

   <mass_balance>
       <ixx unit="SLUG*FT2"> 0.1 </ixx>
       <iyy unit="SLUG*FT2"> 0.1 </iyy>
       <izz unit="SLUG*FT2"> 0.2 </izz>
       <ixy unit="SLUG*FT2"> 0. </ixy>
       <ixz unit="SLUG*FT2"> 0. </ixz>
       <iyz unit="SLUG*FT2"> 0. </iyz>
       <emptywt unit="LBS"> 1 </emptywt>
       <location name="CG" unit="M">
           <x> 0 </x>
           <y> 0 </y>
           <z> 0 </z>
       </location>
   </mass_balance>

Ground reactions

This section creates contact points with the ground for the AR.Drone 2.0. The ground reactions were designed with aircraft wheels in mind. Therefore, the specifications and locations of the ground reactions do not really matter, due to the vertical take-off the quadrotor.

  <ground_reactions>
       <contact type="STRUCTURE" name="CONTACT_FRONT">
           <location unit="M">
               <x>-0.15 </x>
               <y> 0 </y>
               <z>-0.1 </z>
           </location>
           <static_friction>  0.8 </static_friction>
           <dynamic_friction> 0.5 </dynamic_friction>
           <spring_coeff unit="N/M"> 500 </spring_coeff>
           <damping_coeff unit="N/M/SEC"> 100 </damping_coeff>
           <damping_coeff_rebound type="SQUARE" unit="N/M2/SEC2"> 1000 </damping_coeff_rebound>
           <max_steer unit="DEG"> 0.0 </max_steer>
           <brake_group> NONE </brake_group>
           <retractable>0</retractable>
       </contact>

       <contact type="STRUCTURE" name="CONTACT_BACK">
           <location unit="M">
               <x> 0.15</x>
               <y> 0   </y>
               <z>-0.1 </z>
           </location>
           <static_friction>  0.8 </static_friction>
           <dynamic_friction> 0.5 </dynamic_friction>
           <spring_coeff unit="N/M"> 500 </spring_coeff>
           <damping_coeff unit="N/M/SEC"> 100 </damping_coeff>
           <damping_coeff_rebound type="SQUARE" unit="N/M2/SEC2"> 1000 </damping_coeff_rebound>
           <max_steer unit="DEG"> 0.0 </max_steer>
           <brake_group> NONE </brake_group>
           <retractable>0</retractable>
       </contact>

       <contact type="STRUCTURE" name="CONTACT_RIGHT">
           <location unit="M">
               <x> 0.  </x>
               <y> 0.15</y>
               <z>-0.1 </z>
           </location>
           <static_friction>  0.8 </static_friction>
           <dynamic_friction> 0.5 </dynamic_friction>
           <spring_coeff unit="N/M"> 500 </spring_coeff>
           <damping_coeff unit="N/M/SEC"> 100 </damping_coeff>
           <damping_coeff_rebound type="SQUARE" unit="N/M2/SEC2"> 1000 </damping_coeff_rebound>
           <max_steer unit="DEG"> 0.0 </max_steer>
           <brake_group> NONE </brake_group>
           <retractable>0</retractable>
       </contact>

       <contact type="STRUCTURE" name="CONTACT_LEFT">
           <location unit="M">
               <x> 0.  </x>
               <y>-0.15</y>
               <z>-0.1 </z>
           </location>
           <static_friction>  0.8 </static_friction>
           <dynamic_friction> 0.5 </dynamic_friction>
           <spring_coeff unit="N/M"> 500 </spring_coeff>
           <damping_coeff unit="N/M/SEC"> 100 </damping_coeff>
           <damping_coeff_rebound type="SQUARE" unit="N/M2/SEC2"> 1000 </damping_coeff_rebound>
           <max_steer unit="DEG"> 0.0 </max_steer>
           <brake_group> NONE </brake_group>
           <retractable>0</retractable>
       </contact>
   </ground_reactions>


The full configuration and Flight Dynamics Model (FDM) files to fly the AR.Drone autonomously in JSBsim. A very thorough JSBSIM reference manual can be found on the JSBSIM documentation page, in creating the .xml configuration file the team followed this manual closely.

AR.Drone.xml

FileHeader

The configuration file will be prefixed with a FileHeader that includes information such as author, contact information, notes, dates, descriptions, and references.

   <fileheader> 
       <author> "Name of author" </author>
       <filecreationdate> "Date of creation" </filecreationdate>
       <version> "Version" </version>
       <description> "Description" </description>
   </fileheader> 

Metrics

The start of the configuration file will be the physical characteristics of the AR.Drone2, in essence, those static measurements of the aircraft (e.g. weight, wing area, control surface arms, etc.). The values for the wing area and wingspan were measured off of the actual model, measured using a CAD model of the drone, and using official figures found online. It was concluded that all of these values were the same thus it was fairly certain that the figures found were correct.

   <metrics>
       <wingarea unit="IN2"> 0 </wingarea>
       <wingspan unit="IN"> 0 </wingspan>
       <chord unit="IN"> 0 </chord>
       <htailarea unit="FT2"> 0 </htailarea>
       <htailarm unit="FT"> 0 </htailarm>
       <vtailarea unit="FT2"> 0 </vtailarea>
       <vtailarm unit="FT"> 0 </vtailarm>
       <location name="AERORP" unit="IN">
           <x> 0 </x>
           <y> 0 </y>
           <z> 0 </z>
       </location>
       <location name="EYEPOINT" unit="IN">
           <x> 0 </x>
           <y> 0 </y>
           <z> 0 </z>
       </location>
       <location name="VRP" unit="IN">
           <x> 0 </x>
           <y> 0 </y>
           <z> 0 </z>
       </location>
   </metrics>

Mass Balance

Building upon the metrics of the aircraft, the Mass Balance sections is where the center of gravity and moment of inertia are defined.

   <mass_balance>
       <ixx unit="SLUG*FT2"> 0.1 </ixx>
       <iyy unit="SLUG*FT2"> 0.1 </iyy>
       <izz unit="SLUG*FT2"> 0.2 </izz>
       <ixy unit="SLUG*FT2"> 0. </ixy>
       <ixz unit="SLUG*FT2"> 0. </ixz>
       <iyz unit="SLUG*FT2"> 0. </iyz>
       <emptywt unit="LBS"> 1 </emptywt>
       <location name="CG" unit="M">
           <x> 0 </x>
           <y> 0 </y>
           <z> 0 </z>
       </location>
   </mass_balance>

Ground Reactions

The points of contact which the aircraft has with the ground are defined in the Ground Reactions section of the configuration file.

  <ground_reactions>
       <contact type="STRUCTURE" name="CONTACT_FRONT">
           <location unit="M">
               <x>-0.15 </x>
               <y> 0 </y>
               <z>-0.1 </z>
           </location>
           <static_friction>  0.8 </static_friction>
           <dynamic_friction> 0.5 </dynamic_friction>
           <spring_coeff unit="N/M"> 500 </spring_coeff>
           <damping_coeff unit="N/M/SEC"> 100 </damping_coeff>
           <damping_coeff_rebound type="SQUARE" unit="N/M2/SEC2"> 1000 </damping_coeff_rebound>
           <max_steer unit="DEG"> 0.0 </max_steer>
           <brake_group> NONE </brake_group>
           <retractable>0</retractable>
       </contact>

       <contact type="STRUCTURE" name="CONTACT_BACK">
           <location unit="M">
               <x> 0.15</x>
               <y> 0   </y>
               <z>-0.1 </z>
           </location>
           <static_friction>  0.8 </static_friction>
           <dynamic_friction> 0.5 </dynamic_friction>
           <spring_coeff unit="N/M"> 500 </spring_coeff>
           <damping_coeff unit="N/M/SEC"> 100 </damping_coeff>
           <damping_coeff_rebound type="SQUARE" unit="N/M2/SEC2"> 1000 </damping_coeff_rebound>
           <max_steer unit="DEG"> 0.0 </max_steer>
           <brake_group> NONE </brake_group>
           <retractable>0</retractable>
       </contact>

       <contact type="STRUCTURE" name="CONTACT_RIGHT">
           <location unit="M">
               <x> 0.  </x>
               <y> 0.15</y>
               <z>-0.1 </z>
           </location>
           <static_friction>  0.8 </static_friction>
           <dynamic_friction> 0.5 </dynamic_friction>
           <spring_coeff unit="N/M"> 500 </spring_coeff>
           <damping_coeff unit="N/M/SEC"> 100 </damping_coeff>
           <damping_coeff_rebound type="SQUARE" unit="N/M2/SEC2"> 1000 </damping_coeff_rebound>
           <max_steer unit="DEG"> 0.0 </max_steer>
           <brake_group> NONE </brake_group>
           <retractable>0</retractable>
       </contact>

       <contact type="STRUCTURE" name="CONTACT_LEFT">
           <location unit="M">
               <x> 0.  </x>
               <y>-0.15</y>
               <z>-0.1 </z>
           </location>
           <static_friction>  0.8 </static_friction>
           <dynamic_friction> 0.5 </dynamic_friction>
           <spring_coeff unit="N/M"> 500 </spring_coeff>
           <damping_coeff unit="N/M/SEC"> 100 </damping_coeff>
           <damping_coeff_rebound type="SQUARE" unit="N/M2/SEC2"> 1000 </damping_coeff_rebound>
           <max_steer unit="DEG"> 0.0 </max_steer>
           <brake_group> NONE </brake_group>
           <retractable>0</retractable>
       </contact>
   </ground_reactions>

Propulsion

Each of the four motors is defined in the Propulsion section.

<propulsion>
 <engine file="eng_150w" name="front left">
  <location unit="M">
   <x> -0.2 </x>
   <y>  0.2 </y>
   <z>  0.0 </z>
  </location>
  <orient unit="DEG">
   <pitch> 90.00 </pitch>
   <roll>   0.00 </roll>
   <yaw>    0.00 </yaw>
  </orient>
  <feed>0</feed>
  <thruster file="18x8">
   <location unit="M">
    <x> -0.2   </x>
    <y>  0.2   </y>
    <z>  0.025 </z>
   </location>
   <orient unit="DEG">
    <pitch> 90.00 </pitch>
    <roll>   0.00 </roll>
    <yaw>    0.00 </yaw>
   </orient>
   <sense> 1 </sense>
   <p_factor> 10 </p_factor>
  </thruster>
 </engine>
 <engine file="eng_150w" name="front right">
  <location unit="M">
   <x> 0.2 </x>
   <y> 0.2 </y>
   <z> 0.0 </z>
  </location>
  <orient unit="DEG">
   <pitch> 90.00 </pitch>
   <roll>   0.00 </roll>
   <yaw>    0.00 </yaw>
  </orient>
  <feed>0</feed>
  <thruster file="18x8">
   <location unit="M">
    <x> 0.2   </x>
    <y> 0.2   </y>
    <z> 0.025 </z>
   </location>
   <orient unit="DEG">
    <pitch> 90.00 </pitch>
    <roll>   0.00 </roll>
    <yaw>    0.00 </yaw>
   </orient>
   <sense> 1 </sense>
   <p_factor> 10 </p_factor>
  </thruster>
 </engine>
 <engine file="eng_150w" name="rear left">
  <location unit="M">
   <x> -0.2 </x>
   <y> -0.2 </y>
   <z>  0.0 </z>
  </location>
  <orient unit="DEG">
   <pitch> 90.00 </pitch>
   <roll>   0.00 </roll>
   <yaw>    0.00 </yaw>
  </orient>
  <feed>0</feed>
  <thruster file="18x8">
   <location unit="M">
    <x> -0.2   </x>
    <y> -0.2   </y>
    <z>  0.025 </z>
   </location>
   <orient unit="DEG">
    <pitch> 90.00 </pitch>
    <roll>   0.00 </roll>
    <yaw>    0.00 </yaw>
   </orient>
   <sense> -1 </sense>
   <p_factor> 10 </p_factor>
  </thruster>
 </engine>
 <engine file="eng_150w" name="rear right">
  <location unit="M">
   <x>  0.2 </x>
   <y> -0.2 </y>
   <z>  0.0 </z>
  </location>
  <orient unit="DEG">
   <pitch> 90.00 </pitch>
   <roll>   0.00 </roll>
   <yaw>    0.00 </yaw>
  </orient>
  <feed>0</feed>
  <thruster file="18x8">
   <location unit="M">
    <x>  0.2   </x>
    <y> -0.2   </y>
    <z>  0.025 </z>
   </location>
   <orient unit="DEG">
    <pitch> 90.00 </pitch>
    <roll>   0.00 </roll>
    <yaw>    0.00 </yaw>
   </orient>
   <sense> -1 </sense>
   <p_factor> 10 </p_factor>
  </thruster>
 </engine>
 <tank type="FUEL" number="0">
    <location unit="M">
      <x>   0.00 </x>
      <y>   0.00 </y>
      <z>  -0.07 </z>
    </location>
    <capacity unit="KG"> 0.480 </capacity>
    <contents unit="KG"> 0.480 </contents>
 </tank>
</propulsion>


Flight Control

<flight_control name="FCS: quad-copter">
 <channel name="Control Input">
  <summer name="Pitch Command Sum">
	<input>fcs/elevator-cmd-norm</input>
   <input>fcs/pitch-trim-cmd-norm</input>
   <clipto>
    <min>-1</min>
    <max>1</max>
   </clipto>
  </summer> 
  <summer name="Roll Command Sum">
   <input>fcs/aileron-cmd-norm</input>
   <input>fcs/roll-trim-cmd-norm</input>
   <clipto>
    <min>-1</min>
    <max>1</max>
   </clipto>
  </summer>
  <summer name="Yaw Command Sum">
   <input>fcs/rudder-cmd-norm</input>
   <input>fcs/yaw-trim-cmd-norm</input>
   <clipto>
    <min> -1 </min>
    <max>  1 </max>
   </clipto>
  </summer>
 </channel>
 <channel name="Power">
  <fcs_function name="Power FWD">
   <function>
    <sum>
     <product>
      <property>fcs/throttle-cmd-norm[0]</property>
      <value>0.58</value>
     </product>
     <product>
      <property>fcs/roll-command-sum</property>
      <value>0.0</value>
     </product>
     <product>
      <property>fcs/pitch-command-sum</property>
      <value>-0.28</value>
     </product>
     <product>
      <property>fcs/yaw-command-sum</property>
      <value>-0.14</value>
     </product>
    </sum>
    <clipto>
     <min>0</min>
     <max>1</max>
    </clipto>
   </function>
   <output>fcs/throttle-pos-norm[0]</output>
  </fcs_function>
  <fcs_function name="Power Aft">
   <function>
    <sum>
     <product>
      <property>fcs/throttle-cmd-norm[1]</property>
      <value>0.58</value>
     </product>
     <product>
      <property>fcs/roll-command-sum</property>
      <value>0.0</value>
     </product>
     <product>
      <property>fcs/pitch-command-sum</property>
      <value>0.28</value>
     </product>
     <product>
      <property>fcs/yaw-command-sum</property>
      <value>-0.14</value>
     </product>
    </sum>
    <clipto>
     <min>0</min>
     <max>1</max>
    </clipto>
   </function>
   <output>fcs/throttle-pos-norm[1]</output>
  </fcs_function>
  <fcs_function name="Power Left">
   <function>
    <sum>
     <product>
      <property>fcs/throttle-cmd-norm[2]</property>
      <value>0.58</value>
     </product>
     <product>
      <property>fcs/roll-command-sum</property>
      <value>-0.28</value>
     </product>
     <product>
      <property>fcs/pitch-command-sum</property>
      <value>0.0</value>
     </product>
     <product>
      <property>fcs/yaw-command-sum</property>
      <value>0.14</value>
     </product>
    </sum>
    <clipto>
     <min>0</min>
     <max>1</max>
    </clipto>
   </function>
   <output>fcs/throttle-pos-norm[2]</output>
  </fcs_function>
  <fcs_function name="Power Right">
   <function>
    <sum>
     <product>
      <property>fcs/throttle-cmd-norm[3]</property>
      <value>0.58</value>
     </product>
     <product>
      <property>fcs/roll-command-sum</property>
      <value>0.28</value>
     </product>
     <product>
      <property>fcs/pitch-command-sum</property>
      <value>0.0</value>
     </product>
     <product>
      <property>fcs/yaw-command-sum</property>
      <value>0.14</value>
     </product>
    </sum>
    <clipto>
     <min>0</min>
     <max>1</max>
    </clipto>
   </function>
   <output>fcs/throttle-pos-norm[3]</output>
  </fcs_function>
 </channel>
</flight_control>


Aerodynamics

<aerodynamics>
 <axis name="LIFT">
 </axis>
 <axis name="DRAG">
   <function name="aero/coefficient/CD0">
      <description>Overall Drag</description>
      <product>
          <property>aero/qbar-psf</property>
          <property>metrics/Sw-sqft</property>
          <value>1</value>
      </product>
   </function>
 </axis>
 <axis name="SIDE">
 </axis>
 <axis name="ROLL">
 </axis>
 <axis name="PITCH">
 </axis>
 <axis name="YAW">
 </axis>
</aerodynamics>

AR.Drone-set.xml

The set .xml file is used by Flightgear for the simulation of the aircraft and sees no further use by JSBSIM for the creation of the FDM. All variables and settings within this particular .xml file are implemented in the drone simulation (e.g. sounds, sights, systems, etc.). A CAD model of the drone is also used herein for visual representation. The model was animated in the Blender open-source 3D computer graphics software. Therein it was imported as a .stl file from a CAD editor and exported as a .ac file which Flightgear could implement as a visual during simulation. At the time of writing this was the most straightforward method for importing and exporting the model although it required the implementation of an additional python script. These import and export features will soon be default in Blender distributions.

Simulation and Visuals

An autopilot system is used during the simulation; the autopilot system is from the Malolo1 DIY Drones ArduPlane repository on Google Code, it can be found in full here. The code for the Malolo1 is distributed, free of costs, under the GNU General Public License. It was implemented in the Flightgear simulation of the AR.Drone2 as a reliable autopilot system to maintain stable flight. When implementing it in your own code take special care to ensure that all paths and directories are appropriate for your own project.

<sim>
 <description> Parrot AR.Drone 2.0 </description>
 <author> Author </author>
 <aircraft-version> 0.0 </aircraft-version>
 <status> beta version </status> 
 <flight-model>jsb</flight-model>
 <aero>AR.Drone</aero>
 <systems>
  <autopilot>
   <path>Aircraft/Malolo1/Systems/110-autopilot.xml</path>
  </autopilot>
  <electrical>
   <path>Aircraft/Malolo1/Systems/electrical.xml</path>
  </electrical>
 </systems>
 <sound>
  <path>Aircraft/Generic/generic-sound.xml</path>
 </sound>
 <panel>
  <visibility archive="n">false</visibility>
 </panel>
 <model>
  <path archive="y">Aircraft/AR.Drone/Models/visualmodels.xml</path>
 </model>
 <view>
  <internal archive="y">true</internal>
  <config>
    <x-offset-m archive="y">0.0</x-offset-m>
    <y-offset-m archive="y">0.15</y-offset-m>
    <z-offset-m archive="y">0.90</z-offset-m>
    <pitch-offset-deg>0</pitch-offset-deg>
  </config>
 </view>
       <chase-distance-m archive="y" type="double">-5.5</chase-distance-m>
 <help>
   <title> Parrot AR.Drone </title>
 </help>
</sim>

Controls, Consumables, Payload, and Nasal

<controls>
 <flight>
  <aileron-trim>0.00</aileron-trim>   
  <elevator-trim>0.00</elevator-trim> 
 </flight>
</controls>
<consumables>
 <fuel>
  <tank n="0">
   <level-gal_us>0.1667</level-gal_us>
  </tank>
 </fuel>
</consumables> 
<payload>
 <weight>
  <name type="string">Payload</name>
  <weight-lb alias="/fdm/jsbsim/inertia/pointmass-weight-lbs[0]"/>
  <min-lb type="double">0.0</min-lb>
  <max-lb type="double">1.0</max-lb>
 </weight>
</payload> 
<nasal>
 <AR.Drone>
  <script>
    setlistener("/sim/signals/fdm-initialized", func {
        var left  = screen.display.new(20, 10);
        left.add("/fdm/jsbsim/fcs/throttle-pos-norm[0]");
        left.add("/fdm/jsbsim/fcs/throttle-pos-norm[1]");
        left.add("/fdm/jsbsim/fcs/throttle-pos-norm[2]");
        left.add("/fdm/jsbsim/fcs/throttle-pos-norm[3]");
        left.add("/orientation/pitch-deg");
        var right = screen.display.new(-250, 20);
        right.add("/fdm/jsbsim/moments/l-prop-lbsft");
        right.add("/fdm/jsbsim/moments/m-prop-lbsft");
        right.add("/fdm/jsbsim/moments/n-prop-lbsft");
    });
  </script>
 </AR.Drone>
</nasal>

Flightgear

This section will explain the installation of FlightGear and the creation of an visual model for Flightgear.

An example AR.Drone flying in FlightGear

Download FlightGear

FlightGear can be downloaded from http://www.flightgear.org/download/ . Installation should be self-explanatory. The aircraft models will be located in: (...\FlightGear\Data\Aircraft).

Visual model

Flightgear uses .ac files from the AC3D program, a 3D design program by Inivis[1]. A free alternative is Blender[2], which can export its files to the .ac format with a plugin[3] (instructions on how to install also found in link).

Our minor group used an existing model[4], (registering required), which we exported to .stl in Autodesk. Then we imported the .stl files with Blender, and exported them again in the required .ac format.

Moving parts

To use animated moving parts in the model, all the moving parts have to be exported individually. All parts are linked together by the model's set file.

Setting up the folder

Inside your aircraft folder (...\FlightGear\Data\Aircraft\"Aircraft name"), a .xml file is needed to enable Flightgear to load the model. This file should be named as: "Aircraft name"-set.xml. Inside, it links to main visual model file. All visual model files should go into the "Models" folder of the aircraft: (...\FlightGear\Data\Aircraft\"Aircraft name"\Models). The main .xml file should indicate the lay-out of the model (see Example files).

Clarification of the .xml files

main.xml:

The .ac file contains the body model of the quadrotor:

<path>myquadrotor.ac</path>

The 4 <model> nodes contain information about the location and orientation of the propellors. The <path> links to the location of the engine file. The <offsets> manually places the propellors in (about) the right place. This has no consequences for the performance of the aircraft. For the FlightGear coordinate system, see: [5]. The <pitch/yaw/roll-deg> can be used if the imported file has the wrong orientation.

 <model>
  <name>Engine1</name>
  <path>Aircraft/myquadrotor/Models/engine1.xml</path>
  <offsets>
   <x-m>0.3</x-m>
   <y-m>-0.2</y-m>
   <z-m>0.0</z-m>
   <pitch-deg>0</pitch-deg>
  </offsets>
 </model>

Using <offsets> the orientation of the model was corrected:

 <offsets>
  <heading-deg>270</heading-deg>
 </offsets>


engine1.xml:

Contains the model of the rotor:

<path>rotor.ac</path>

<Animation> is used for the animation of the propeller. You can declare the type of animation (spin), the center of the animation, around which axis to spin and in which direction (clockwise or ccw).

 <animation>
  <type>spin</type>
  <object-name>propeller</object-name>
  <property>engines/engine[0]/rpm</property>
  <factor>1</factor>   
  <centre>
   <x-m>0</x-m>
   <y-m>0</y-m>
   <z-m>0</z-m>
  </centre>
  <axis>
   <x>0</x>
   <y>0</y>
   <z>-1</z>
  </axis>
 </animation>

Example files

main.xml file:

<PropertyList>
 <path>myquadrotor.ac</path>

 <model>
  <name>Engine1</name>
  <path>Aircraft/myquadrotor/Models/engine1.xml</path>
  <offsets>
   <x-m>0.3</x-m>
   <y-m>-0.2</y-m>
   <z-m>0.0</z-m>
   <pitch-deg>0</pitch-deg>
  </offsets>
 </model>

 <model>
  <name>Engine2</name>
  <path>Aircraft/myquadrotor/Models/engine2.xml</path>
  <offsets>
   <x-m> -0.3</x-m>
   <y-m>0.2</y-m>
   <z-m> 0.0</z-m>
   <pitch-deg>0</pitch-deg>
  </offsets>
 </model>

 <model>
  <name>Engine3</name>
  <path>Aircraft/myquadrotor/Models/engine3.xml</path>
  <offsets>
   <x-m>-0.3</x-m>
   <y-m>-0.2</y-m>
   <z-m> 0.0</z-m>
   <pitch-deg>0</pitch-deg>
  </offsets>
 </model>

 <model>
  <name>Engine4</name>
  <path>Aircraft/myquadrotor/Models/engine4.xml</path>
  <offsets>
   <x-m> 0.3</x-m>
   <y-m> 0.2 </y-m>
   <z-m> 0.0</z-m>
   <pitch-deg>0</pitch-deg>
  </offsets>
 </model>

 <offsets>
  <heading-deg>270</heading-deg>
 </offsets>
</PropertyList>

engine1.xml file:

<PropertyList>

 <path>rotor.ac</path>

 <animation>
  <type>spin</type>
  <object-name>propeller</object-name>
  <property>engines/engine[0]/rpm</property>
  <factor>1</factor>   
  <centre>
   <x-m>0</x-m>
   <y-m>0</y-m>
   <z-m>0</z-m>
  </centre>
  <axis>
   <x>0</x>
   <y>0</y>
   <z>-1</z>
  </axis>
 </animation>

</PropertyList>

View ARDrone 2 live video

Option 1: Simple low quality MJPEG over RTP

Add the video_stream_rtp.xml module to your airframe file. (you can save higher quality frames by clicking on the snapshot setting in the ground-station)

Make a text file with extension .sdp and add the following content link

 v=0
 m=video 5000 RTP/AVP 26
 c=IN IP4 0.0.0.0

Open the SDP file with VLC or another video viewer while the code with module is running on the drone.

Option 2: Use the precompiled gstreamer with MP4 encoding on the DSP

 git clone https://github.com/tudelft/ardrone2_gstreamer.git

Once connected to the ARDrone2 you can upload gstreamer to the ARDrone using (make sure you did not already add a lot of data to the drone like pictures etc because gstreamer will need all normally available free space):

 cd ardrone2_gstreamer/
 make drone   (or manually untar arm_light.tgz and mount and start dsp images: see ardrone.py script for details: reboot drone if starting dsp mp4 images fails)

Before you start encoding video on ARDrone2 the DSP inside the OMAP, it must still load the proper binaries (see todo/basescript.sh for an alternative)

 ./ardrone2.py startvideo  (this step must be repeated every time you reboot the drone)

After this you can use gstreamer on the drone: telnet to the drone and run for instance:

 telnet 192.168.1.1
 gst-launch v4l2src device=/dev/video1 ! videorate ! 'video/x-raw-yuv,framerate=15/1' ! videoscale ! video/x-raw-yuv, width=320, height=240 ! dspmp4venc ! rtpmp4vpay config-interval=2 ! udpsink host=192.168.1.255 port=5000

(to open video1, downrate, downsample, MP4-encode on dsp, add RTP protocol, UDP stream to IP:port)

and view and save the stream on your PC using the opposite chain:

 gst-launch-0.10 udpsrc uri=udp://0.0.0.0:5000  caps = 'application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)MP4V-ES, payload=(int)96' ! rtpmp4vdepay ! ffdec_mpeg4 ! ffmpegcolorspace ! tee name=split ! ximagesink split. ! queue ! ffmpegcolorspace ! ffenc_mpeg4 ! avimux ! filesink location=video.avi

don't have gstreamer on your PC yet?

Install gstreamer with codecs on unbuntu: make install should achieve this

 sudo apt-get install gstreamer0.10-ffmpeg

device=/dev/video1 is front camera device=/dev/video2 is bottom camera

Other way to video client in ubuntu: e.g.:

 gst-launch-0.10 -vvv playbin uri=file:///home/YOURNAME_AND_SUBFOLDER/ardrone2_gstreamer/sdp/x86_config-mp4.sdp

or see https://github.com/tudelft/ardrone2_gstreamer/blob/master/sdp/Makefile for options

if the above command fails for Ubuntu 12.04 users, you can try this

 gst-launch-0.10 udpsrc uri=udp://0.0.0.0:5000  caps = 'application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)MP4V-ES, payload=(int)96' ! rtpmp4vdepay ! ffdec_mpeg4 ! ffmpegcolorspace ! ximagesink

5) if you want to kill your video on the drone

 telnet 192.168.1.1
 killall -9 gst-launch


Making Gstreamer Plugins for the ARDrone

To combine your own vision with efficient exising gstreamer functions (like dspmp4encode) you should create a plugin and add it to the gstreamer chain:

Install

We first must install the framework on your development PC. We assume you already have installed the Paparazzi sourcecode. If not, please do that first, then come back to this page.

 git clone https://github.com/tudelft/ardrone2_vision.git
 cd ardrone2_vision
 make install   (install some tools needed; scratchbox2 and qemu)
 make

If you need to change your cross compiler:

 gedit ./ardrone2_gstreamer/Makefile 

And add edit the path to your ardrone crosscompiler and make install again to setup sb2

Make your own vision plugin

 ./create_new_plugin.py

OpenCV 3

Here the description on how to get OpenCV 3 on your AR.Drone 2.0. If there is not so much text of explanation here... it is your turn to extend this Wikipage with your knowledge please.

[6]

Tips and Tricks

Transfer files

For transferring files the File Transfer Protocol (FTP) used in this project, was FileZilla. When you installed FileZilla, it will be pretty easy to transfer files.

First you need to connect to the AR.Drone 2, by entering the ip-address of the AR.Drone 2 which is by default "192.168.1.1". Leave all other settings of FileZilla the same and press connect. When you are connected to the AR.Drone 2, keep in mind that programs need to be transferred in binary mode which can be set in the FileZilla Settings.

Into the Brain

login to console on AR.Drone2 via telnet

To connect to AR.Drone2 you need a telnet client, so that you can connect with the busybox telnet server on the AR.Drone2. When your computer is connected trough wifi with the the AR.Drone2, the drone's IP-address defaults to 192.168.1.1.

You can now connect by typing:

$ telnet 192.168.1.1

A busybox welcome message will show when you connect.

It is convenient to make a hosts definition so you can type:

$ telnet ardrone2

You do this by adding 192.168.1.1 ardrone2 to /etc/hosts

Change WiFi channel

Sometimes it is nice to be able to change a Wifi channel in an area where there a lot of Wifi devices are in one place. Do it via:

 # iwconfig ath0 channel X commit

Connect via a router

To have a more flexible network setting the drone to use a router would be a good device to use. This page explains how to use a router icw a AR.Drone 2.0

Eclipse Post-build steps

While developing with the arm [toolchain] to create some test applications for AR.Drone2 we used a post-build step to quickly upload the file from development computer to the AR.Drone2.

publish.sh

echo "Release script"

# first call a telnet script that stops the test program
/home/dhensen/telnet_stop_script.sh | telnet

# requires having 192.168.1.1 ardrone2 in /etc/hosts
ftp ardrone2 <<END_SCRIPT
# type an arbitrary username on the next line 
dhensen
# change the source and target dir to fullfill your needs
put /home/dhensen/workspace/test/Release/test /bin/test
quit
END_SCRIPT

# lastly call a telnet script that gives the test program the right permissions
/home/dhensen/telnet_permission.sh | telnet

exit 0

telnet_stop_script.sh

#!/bin/sh
host=ardrone2
port=23
login=notneeded
passwd=notneeded
cmd="killall -9 test"

echo open ${host} ${port}
sleep 0.1
echo ${cmd}
sleep 0.1
echo exit

telnet_permission.sh

#!/bin/sh
host=ardrone2
port=23
login=notneeded
passwd=notneeded
cmd="chmod 777 /data/video/bin/test"

echo open ${host} ${port}
sleep 0.1
echo ${cmd}
sleep 0.1
echo exit

You can use publish.sh in eclipse by opening Project Properties -> C/C++ Build -> Settings -> Build Steps. Then in the Post-build steps section in the Command field type: /<your_path_to_file>/publish.sh while replacing your_path_to_file with the path where you saved publish.sh.

After building this script will now push your program called test to the AR.Drone2 automatically. This saves a lot of time, but you still have to run it yourself or adapt the script above to run it automatically. We did not require an automatic run script so we left it out here.

Console Fixing

The traditional pinout

Ardrone2 hw1.jpg

Hardware V2

The new 6 pin of 2013 PCB design. Warning, mind pin 1, there is the full 12V battery voltage! Access the port via /dev/ttyO3

ArDrone2 SerialConsoleNewPinout2013.jpg

View Printf

First upload from paparazzi center, then telenet into you Drone's brain:

$ telnet 192.168.1.1

On the Drone to show all running processed:

# ps -aux

To kill AP process:

# killall -9 ap.elf

To restart the main autopilot PPRZ process:

# cd /data/video/paparazzi
# ./ap.elf

Debugging

Serial Console Cable

Via the bottom USB port

Debugging is much easier if we have a console cable. For this your USB to serial terminal cable is connected on /dev/ttyUSB0, found via e.g.

$ dmesg

To login to the drone in your regular Linux terminal use:

$ screen /dev/ttyUSB0 115200

Repair firmware via serial connection

Sometimes your AR.Drone 2.0 is quite messed up since you e.g .deleted some crucial files needed to boot your drone. You need to have a serial cable

http://forum.parrot.com/ardrone/en/viewtopic.php?id=5331

Repairing Firmware

If your ARdrone2 is really inaccessible, a.k.a. bricked, there is work for you to be done, sice so far no one managed to flash the firmware with external opensource tools. Theoretically possible, just n one ever managed.

Downgrade firmware

If you would like to downgrade, upgrade, or re-install firmware you can do so at your own risk by using these files and instructions.

Abbreviated instructions:

  • Download the version you want below. (Don’t change the filename.)
  • Power up your AR.Drone
  • Connect your computer to the AR.Drone’s network
  • Open a telnet session to 192.168.1.1
  • type the following: echo “1.1.1″ > /firmware/version.txt
  • press enter
  • type the following: echo “1.1.1″ > /update/version.txt
  • Connect an FTP client to 192.168.1.1 Port: 5551
  • Upload the downloaded plf file to the FTP server (AR.Drone)
  • Disconnect your computer from the AR.Drone
  • Disconnect the battery from the AR.Drone
  • Reconnect the battery
  • Wait about 5 minutes while the upgrade completes, leave your drone switched on=

GDB

The Drone has GDB (GNU Debugger) installed by default

Connect to GDB via: {TODO}

Boot sequence

Note that this section of the page is a work in progress, lease add more info if you have discovered more infrmation.

http://omappedia.org/wiki/Bootloader_Project

The drone 2.0 is based on a Texas Instruments OMAP3630, modified of course.

v1 process (it's similar but not the same, and there is no "load from USB" bootloader available for the 2.0 like there was for the v1): http://embedded-software.blogspot.co.uk

How the boot process works:

Parrot has modified it with their own bootloader(s) though.

Tools to load a different bootloader over UART:

Note that you won't be able to use his s-boot.bin, it's for a different board of course.

You can make the drone look for a bootloader over UART by plugging a device into the USB port. It might also work if you connect pin 2 to a 5v supply (I think this is VUSB in). You'll know it is working because the drone will wait for 2 seconds before you see the "Parrotboot" message.

Unlike the v1 there is no "flash via USB/UART" bootloader made available by Parrot, so you will have to make your own. There are 3630 configs for x-loader floating around on the web, but none will work out of the box. You need to modify it to set up the Parrot hardware correctly. And mae sure you set the required config for x-loader to make it ask for a 2nd stage bootloader over UART instead of USB. Maybe check out http://barebox.org too. Some hardware config info might be found in Parrot's GPL kernel modifications.

You might be able to use similar tools to load bootloaders from USB instead of UART (i.e. similarly to the tools available for the v1), but I personally have not managed to get as far with USB connection as others in this thread. Maybe my pins are broken.

Some complications you will run into:

  1. I found that even though I could upload a first stage bootloader via UART and the drone would try to execute it, the "regular" boot never stopped so it was hard to see what was going on. I also think I was getting errors on the upload, checksums failing etc.
  2. The serial number of your drone hardware is embedded in the NAND flash filesystem. When the Parrot kernel boots and tries to run, it checks this. So overwriting the system partition with one from a working drone will not work. You would need to reverse engineer this process somehow.

If you are were willing to spend another 6 weeks on it, try this:

  1. Get a bootloader working - x-loader, u-boot, barebox etc
  2. Try to get installer.plf to execute. Maybe it will ask for ardrone2_update.plf and execute it. If you're lucky, your broken files will be amongst those updated.
  3. If that fails, try to get to the point where you can mount the NAND filesystem, and modify it by hand.

http://embedded-software.blogspot.nl/2010/12/ar-drone-usb.html

AR.Drone 1.0

Some information on the AR.Drone 1.0 is still relevand for the AR.Drone 2.0 '+ BELOW FOR AR-DRONE 1 (ONE)+'

Boot sequence 1.0

A.R. Drone's boot sequence

In order to be able to flash a custom kernel to A.R. Drone, it is necessary to understand it's boot sequence:

   After reset, the program counter starts at the beginning P6 internal ROM. In this internal ROM, some kind of pre-bootloader exists that evaluates external pins and selects the corresponding boot mode (e.g. boot over USB, NAND, IIC, UART, ... ). Depending on the selected mode, the peripherals are set-up and it is tried to boot over this peripheral.
       Boot over NAND: The pre-bootloader starts the memory controller, copies the bootloader from NAND to internal RAM and sets the program counter to the address in internal RAM which basically starts the bootloader.
       Boot over USB: The pre-bootloader listens to USB and waits for the "Hello P6" command. If received, it replies and awaits an image (the usb_bootloader.bin). The received data is copied to internal RAM and the program counter is changed to the internal RAM address wich in effect starts the bootloader.
   Depending on the started bootloader, either the UBI partitions are "mounted" and the kernel image is read or the bootloader waits until the kernel image is sent over USB.
   If the installer.plf (which is basically a kernel image) is booted over USB, the "init" command of this image awaits the actual firmware (ardrone_update.plf) over USB and installs the content to NAND.

Custom firmware

Reading navigation data directly from Navboard On A.R. Drones navigation board, the following sensors exist:

   IDG-500 (Dual-axis gyroscope)
   XV-3500CB (Z-axis gyroscope)
   BMA150 (3-axis accelerometer)
   Some ultrasonic stuff

For handling these sensors, a PIC24 is used. This device does the A/D conversion of the gyroscope data and the I2C communication with the BMA150. Periodically, the sensor data is sent over UART to the mainboard where it is used by program.elf to control the Drone.

So... how to get this data without using program.elf?

First, start the sensor acquisition by calling:

echo -e -n "\1" > /dev/ttyPA2

Now, periodically, the nav boards sends a 0x2E sized frame to UART2.. so read it with:

dd if=/dev/ttyPA2 count=1 bs=46 | hexdump -C

The data seems to have the following format:

struct nav_data_tag {

 u16 size;                /* +0x00 Size of the following data (0x2C) */
 u16 sequence;            /* +0x02 Sequence number */
 u16 raw_accs[3];         /* +0x04 Raw data of the accelerometers*/
 u16 raw_gyros[3];        /* +0x0A Raw data for the gyros */
 u16 raw_gyros_110[2];    /* +0x10 4.5x Raw data (IDG) */
 u16 uk_0x14;             /* +0x14 Unkown. Maybe accs temperature */
 u16 gyro_temp;           /* +0x16 Gyro temperature (IDG) */
 u16 vrefEpson;           /* +0x18 Gyro v_ref (Epson) */
 u16 vrefIDG;             /* +0x1A Gyro v_ref (IDG) */
 u16 uk_0x1C;             /* Unkown */
 u16 checksum;            /* +0x1E Checksum */
 u16 us_debut_echo;       /* +0x20 Ultrasonic parameter */
 u16 us_fin_echo;         /* +0x22 Ultrasonic parameter */
 u16 us_association_echo; /* +0x24 Ultrasonic parameter */
 u16 us_distance_echo;    /* +0x26 Ultrasonic parameter */
 u16 us_courbe_temps;     /* +0x28 Ultrasonic parameter */
 u16 us_courbe_valeur;    /* +0x2A Ultrasonic parameter */
 u16 us_courbe_ref;       /* +0x2C Ultrasonic parameter */ 

}

I haven't figured out much yet, but here are my first analysis results:

   size: always 0x2C
   sequence: increases every update
   raw_accs: seems to contain the BMA values left-shifted by 2
   raw_gyros: 12-bit A/D converted voltage of the gyros
   raw_gyros_110: gyro values wieth another resolution (see IDG-500 datasheet)
   gyro_temp: 12-bit A/D converted voltage of IDG's temperature sensor
   vrefEpson: 12-bit A/D converted reference voltage of the Epson sensor
   vrefIDG: as vrefEpson, but for IDG sensor
   checksum: checksum (have to figure out how to calculate..
   all others haven't yet figured out what they mean

Posted by es at 8:33 PM 9 comments Email ThisBlogThis= Share to TwitterShare to Facebook Labels: A.R. Drone Wednesday, January 19, 2011 Creating, testing (and flashing -- TBD) a custom kernel In my last post, I announced that creating and uploading a custom kernel works. Now I will explain how this can be done.

Thanks to MAPGPS from http://www.ardrone-flyers.com for testing my tools.

You need:

- Linux= I used Ubuntu 10.10 - ARDrone linux kernel source (get it from [1]) - ARDrone linux kernel config (get it from [2]) - The Sourcery G++ toolchain (get it from [3] or [4] ) - My plftool, usb_flash tool (see below) - The old parrot flash tool (for ardrone_usb_bootloader.bin) - libusb-0.1 (linux) or libusb-win32 (windows) - zlib

Getting & Compiling plftool + usb_flash tool

These tools are not yet released. Thus I will not provide binaries for windows, instead you have to compile them by yourself. For windows, you need to use mingw32.

Getting the sources

The sources are stored at my google code project. In order to get them, you need to install a svn client. For linux you then call something like this:

svn checkout http://ardrone-tool.googlecode.com/svn/projects/libplf/trunk libplf svn checkout http://ardrone-tool.googlecode.com/svn/projects/usb_flash/trunk usb_flash svn checkout http://ardrone-tool.googlecode.com/svn/projects/plftool/trunk plftool

Compiling

Now that you got the sources, you need to compile them. First start with libplf as this is needed by all projects. The library contains the code to read and write .plf files.

$ cd libplf 
$ make
$ cd ..

When compiling with mingw32 call "make -f Makefile.w32" instead.

If libplf was compiled succesfully you should get either a libplf.so or libplf.dll file. Next compile plftool and usb_flash:

$ cd plftool
$ make
$ cd ..
$ cd usb_flash
$ make
$ cd ..

When compiling with mingw32, call "make -f Makefile.w32" instead.

This should create plftool(.exe) and usb_flash(.exe).

For Linux, if you do not want to install the libplf.so file, you need to call plftool and usb_flash with LD_LIBRARY_PATH=<path_to_the_folder_where_libplf.so_is_located> prefix.

E.g.

LD_LIBRARY_PATH=/home/$USER/projects/ardrone/tools/libplf plftool 

For Windows, you need to add the folder where libplf.dll is located to your PATH variable before calling usb_flash or plftool.

Patching the kernel

As Parrot's published source code does not match the kernel delivered with firmware > 1.3.3, a patch is required to ensure correct behaviour. This patch mainly affects p6_sdhci.c.

You can get the patch from here. To apply it, just call:

$ cd linux-2.6.27
$ patch -p1 < p6_sdhci-patch1.patch

Compiling the kernel Now as the kernel is patched, you should use Parrot's original config [2] and cross-compile the sources with Sourcery G++. Basically you need to do something like this (don't forget to add the Sourcery' bin directory to your PATH):

$ cp ARDrone_Version_20100809_1_2-busybox.config .config
$ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- zImage 

After a few minutes (or hours) make informs you that the zImage file is available:

Kernel: arch/arm/boot/Image is ready Kernel: arch/arm/boot/zImage is ready

Creating a kernel.plf file

If you got your zImage, it is time to build a kernel.plf file from it. This is done by plftool. plftool expects a build-ini file that describes the plf file. A sample ini file can be found at plftool/samples/kernel. Using the sample kernel.ini, you only have to modify the "File=" parameters in section "[zImage]" and "[BootParams]" so they point to the zImage file and to a text file, the boot parameters are located in (e.g. called bootparams.txt).

To create the kernel.plf from the kernel.ini, just call:

$ plftool -b kernel.ini -o kernel.plf 

The tool should output something similar to this and create the kernel.plf file.

Creating kernel.plf based on this config: File [HdrVersion: 11 EntryPoint: 0x40800000; Version: 0.0.0 TargetPlat=4, TargetAppl=78, HwCompat=0, LangZone=0]

 zImage     @ 0x40800000 (zImage)
 initrd     @ ---------- (no initrd)
 bootparams @ 0x40700000 (bootparams.txt)
*** kernel.plf created ***

Testing the kernel.plf file If kernel.plf file was created, it is time to test this file. First inspect it with plftool:

$ plftool -d -i kernel.plf

Have a look at dwFileType, dwEntryPoint and Section->LoadAddr.

If it looks okay, it is time to start (not flash= ) the kernel:

  1. Copy ardrone_usb_bootloader.bin to the folder of usb_flash
  2. Connect the drone to your PC via USB (the LED should be RED)
  3. Connect the BATTERY to your drone (the LED becomes GREEN)
  4. Check if the device was found (with lsusb)
  5. Start usb_flash in TEST mode:

usb_flash -t kernel.plf

This will load (NOT flash) the kernel over USB. In general, it is helpful to observe A.R. Drone's serial port, as the whole boot sequence is shown there. usb_flash outputs on success:

...

Mode: kernel test

      • VERIFICATION ***

Verifying ardrone_usb_bootloader.bin Verifying test_kernel.plf


      • DOWNLOADING USB BOOTLOADER ***

Try [00/10] to connect to VID: 0x19cf PID: 0x1000 Found a possible device: - Manufacturer: Parrot SA - Product: P6 USB Stage1 - Serialnumber: ? - Number of configurations: 1 Sending bootloader (0x5b20 bytes) - Send Hello P6 (0xA3) Success===

Checksum returned: 0x5256 Expected: 0x5256 => OK Starting the bootloader...

      • INSTALLER DOWNLOAD ***

Closing usb connection... Try [00/10] to connect to VID: 0x19cf PID: 0x1000 Found a possible device: - Manufacturer: Parrot SA - Product: P6 USB Stage1 - Serialnumber: ? - Number of configurations: 1 loading installer Uploading file: test_kernel.plf Error Code returned: 0x00000000 ==> OK

      • INSTALLATION DONE ***

If everything works, the kernel boots up, WiFi ist started and you should be able to connect to the drone with telnet.

Check the kernel version with

uname -a

If the default kernel starts without problems, you can now begin to modify the kernel config. Flashing the kernel to NAND works but I still need to modify the plftool.. so stay tuned.

Happy hacking :-)

  1. https://projects.ardrone.org/documents/show/19
  2. https://projects.ardrone.org/documents/show/18
  3. https://projects.ardrone.org/documents/show/20
  4. http://www.codesourcery.com/sgpp/lite/arm/portal/release858

Posted by es at 2:23 AM 7 comments Email ThisBlogThis= Share to TwitterShare to Facebook Labels: A.R. Drone, Custom Kernel, Flashing Tuesday, January 11, 2011 Creating + Flashing Custom Kernel Yeah...

Creating a kernel.plf file from zImage+initrd --> WORKS= Booting this kernel.plf file over USB --> WORKS= Flashing this kernel.plf to NAND --> to be done...

More will follow soon :-) Posted by es at 11:53 PM 1 comments Email ThisBlogThis= Share to TwitterShare to Facebook Labels: A.R. Drone, Custom Kernel, Flashing Sunday, January 9, 2011 Tools for A.R. Drone I finally released some tools for A.R. Drone:

   libplf - A library to read / write plf files
   plf_inst_extract - A tool to extract and patch a ardrone_installer.plf from a given ardrone_update.plf
   usb_flash - A tool to flash a ardrone_update.plf over USB. This tool requires:
       ardrone_update.plf - the firmware to flash
       ardrone_installer.plf - can be obtained from ardrone_update.plf with plf_inst_extract
       ardrone_usb_bootloader.bin - was delivered with the old flash tool. I will probably write an open-source boot loader sooner or later.

Have a look at my google code project:

http://code.google.com/p/ardrone-tool Posted by es at 2:17 AM 0 comments Email ThisBlogThis= Share to TwitterShare to Facebook Labels: A.R. Drone, Flashing, USB A.R. Drone's boot sequence In order to be able to flash a custom kernel to A.R. Drone, it is necessary to understand it's boot sequence:

   After reset, the program counter starts at the beginning P6 internal ROM. In this internal ROM, some kind of pre-bootloader exists that evaluates external pins and selects the corresponding boot mode (e.g. boot over USB, NAND, IIC, UART, ... ). Depending on the selected mode, the peripherals are set-up and it is tried to boot over this peripheral.
       Boot over NAND: The pre-bootloader starts the memory controller, copies the bootloader from NAND to internal RAM and sets the program counter to the address in internal RAM which basically starts the bootloader.
       Boot over USB: The pre-bootloader listens to USB and waits for the "Hello P6" command. If received, it replies and awaits an image (the usb_bootloader.bin). The received data is copied to internal RAM and the program counter is changed to the internal RAM address wich in effect starts the bootloader.
   Depending on the started bootloader, either the UBI partitions are "mounted" and the kernel image is read or the bootloader waits until the kernel image is sent over USB.
   If the installer.plf (which is basically a kernel image) is booted over USB, the "init" command of this image awaits the actual firmware (ardrone_update.plf) over USB and installs the content to NAND.

Datainterchange with other electronics

THe Ardrone 2 has various options:

  1. Use debug serial port
  2. USB to serial FTDI cable
  3. Extra Wifi dongle
  4. USB to Ethernet cable
  5. LED to PWM in

Odroid XU

Hardware

1x FTDO

Option

The past

Some info on older documentation but in certain cases very useful.

Reversing

Here info of a part of how the electronics where revered to make it possible to run PPRZ

The "SDK" mode

The SDK mode is a thing from the past, no real reason to use it, the links below are left as a reference.

Past interesting projects

As an honor to the developers some links still here what all was achieved in the past:

Links