AR Drone 2

From PaparazziUAV
Revision as of 07:55, 10 July 2015 by Openuas (talk | contribs) (New AR.Drone 2.0 page)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

outcome

a Parrot AR Drone 2 quadcopter, no soldering or other modifications in the electronic to make it possible to let the Psi fly autonomous missions.

{TODO

The plan

Replace the current AR Drone 2 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 manal control.

...as simple as that, now go and fly...

See http://paparazzi.enac.fr/wiki/AR_Drone_2/getting_started

The Base

== 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 *IS* the autopilot

Parrot GPS

The orange Parrot

Ublox GPS

{TODO IMG}

Connecting GPS

{TODO IMG}

A FTDI TTL 232R 3V3 WE cable is used, where - WE stans for wire ended. 3V3 operates at +3.3V levels (signals only, VCC= +5V)

{TODO IMG} Example of a via USB connected uBlox Helix GPS for Parrot ARDrone2

Pinout colors

TTL - 232R - 5V, TTL - 232R - 3V3 Connector color coding

{TODO IMG}

||1 ||Black ||BK || ||2 ||Brown ||BN || ||3 ||Red ||RD || ||4 ||Orange ||OG || ||5 ||Yellow ||YE || ||6 ||Green ||GN ||


How the connector is prepared

  1. A sharp knive deep in the outer end, the part where the wire come out, this will damage the first part of the wires, but that is OK, it wil not be used
  2. Cut a along the whole wire till the USB connector begin
  3. Peel ot the wires in the begin
  4. Grab all the wires of the cable end stringly in your hand
  5. With one continuous pull, pull the wires out of the black outer plastic. With a cut alone the line this shoud go, just apply force.

You are done!

IMPORTANT LINK: http://forum.parrot.com/ardrone/en/viewtopic.php?id=5331 http://www.dronetec.co.uk/quadmod.html

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

GDB

The Drone has GDB installed by default

Connect to GDB via: {TODO}


AR2 Boot sequence

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

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

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

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


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

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=

AR drone

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/

= Use a router

To have a more flexible networ setting the drone to use aroute would be good. This plage explains how to do just that


'+ BELOW FOR AR-DRONE 1 (ONE)+'

= Boot sequence

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

[1] https://projects.ardrone.org/documents/show/19 [2] https://projects.ardrone.org/documents/show/18 [3] https://projects.ardrone.org/documents/show/20 [4] http://www.codesourcery.com/sgpp/lite/arm/portal/release858 Posted by es at 2:23 AM 7 comments Email ThisBlogThis= Share to TwitterShare to Facebook Labels: A.R. Drone, Custom Kernel, Flashing Tuesday, January 11, 2011 Creating + Flashing Custom Kernel Yeah...

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

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

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

Have a look at my goolge 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.


Links

Generic

Boot sequence

Apps


News

AR.Drone 2.0 Blog http://blog.parrot.com/category/ar-drone/

Press

[| Press photos] AR.Drone 2.0 reviews

Parrot Dev

Developer -Zone [| Open source Software Licences]

Academy

[| AR.Drone Academy]

Repair

[| Spare parts] [| Repair videos]