AR Drone 2

Introduction

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

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.

Take a look on the Howto add a GNSS device to your ARDrone 2 page for details.

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

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

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:

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

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

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 at the "A/C" drop-down box

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

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

Press the [Execute] button

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

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.

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.

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

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

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

Land

Land: Land the drone where you took off

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

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

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

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:

http://omappedia.org/wiki/Bootloader_Project

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

Tools to load a different bootloader over UART:

http://projects.goldelico.com/p/gta04-m … erialBoot/

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:

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.

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

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.

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:

Copy ardrone_usb_bootloader.bin to the folder of usb_flash
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

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

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:

Use debug serial port
USB to serial FTDI cable
Extra Wifi dongle
USB to Ethernet cable
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.

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

Past interesting projects

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

Links

AR.Drone Academy