Difference between revisions of "AR Drone 2"
(GPS info on AR_Drone_2/GPS page) |
|||
| Line 99: | Line 99: | ||
== GPS == | == GPS == | ||
To fly autonomous to a certain geo coordinate a GPS is needed. Although it is theoretically possible to use | To fly autonomous to a certain geo coordinate a GPS is needed. 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. | ||
[[ | See [[AR_Drone_2/GPS]] for details. | ||
== Installation == | == Installation == | ||
Revision as of 13:10, 4 August 2015
Introduction
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.
Easy
When you have finished you autonomous flight with paparazzi and want to fly with the standard ARDrone2 apps, 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
Fly high. Fly fast. Far away from the ground.
- 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 GPS is needed. 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.
See AR_Drone_2/GPS 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 '&&'
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_sdk 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 ARDrone2 Flight 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
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
<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.
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.
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!
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).
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
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
http://forum.parrot.com/ardrone/en/viewtopic.php?id=5331
Repairing Firmware
If your ARdrone2 is bricked, work to be done so far no one managed to flash the firmware with external opensource tools.
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:
- 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)+'
- 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/
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 :-)
- https://projects.ardrone.org/documents/show/19
- https://projects.ardrone.org/documents/show/18
- https://projects.ardrone.org/documents/show/20
- 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:
- 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
- https://wiki.paparazziuav.org/wiki/AR_Drone_2/Motor_driver
- https://wiki.paparazziuav.org/wiki/AR_Drone_2/NAV_board
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
- https://wiki.paparazziuav.org/wiki/AR_Drone_2/GPS
Past interesting projects
As an honor to the developers some links still here what all was achieved in the past:
- https://wiki.paparazziuav.org/wiki/TU_Delft_-_Search_and_Rescue_with_AR_Drone_2
- https://wiki.paparazziuav.org/wiki/TU_Delft_-_Lasergame_with_Autonomous_AR_Drone
- https://wiki.paparazziuav.org/wiki/AR_Drone_2/Multidirectional_distance_measurement
- https://wiki.paparazziuav.org/wiki/AR_Drone_2/Mapping
- https://wiki.paparazziuav.org/wiki/OLSR
Links
- https://play.google.com/store/apps/details?id=com.parrot.freeflight&hl=en
- https://itunes.apple.com/us/app/ar.race-2/id547160291
- AR.Drone 2.0 Blog http://blog.parrot.com/category/ar-drone/