TU Delft - Search and Rescue with AR Drone 2

Introduction

The highly maneuverability and stability of a quadrotor inspired us to make an autonomous search and rescue vehicle. For this the AR Drone 2 was used. The goal of this project is thus to further develop the AR Drone2 in a robot capable of performing an autonomous search mission. All the steps taken are described on this page.

In order to achieve this goal we decided to work with raw data. The data was obtained by creating drivers capable of extracting and interpreting sensor data from the AR Drone2. In order to get the quadrotor flying paparazzi was used. For simulation JSBSim was used, which was then visualized using Flight Gear. The final section of the page will concern with the subject of making the quadrotor autonomous.

How all the data was obtained is presented in chapter 2. In chapter 3 it is described how to get paparazzi working on the drone. Next in chapter 4 we present how simulation was done and finally the proces of making the drone autonomous is described in chapter 5.

Data acquisition

So as explained in the introduction, firstly the raw data had to be extracted from the AR Drone2. So this data could be fed to paparazzi. So we started with trying to connect and to pass files to the AR Drone2, which is desribed in the connecing section. The exact details of the extraction of the data is described in the NAV board section. Next the data from paparazzi had to be passed on to our actuators correctly. This is described in the drivers section. To be able to perform better in our autonomous mission a GPS was added to the AR Drone2. The details of this are described in the GPS section.

Conecting

For our project the operating system Ubuntu was used, so all the steps described here are for an Ubuntu operating system. But it's a free operating system, so if you want to retrace our steps you can simply download it and access it from your current operating system using virtual box for example.

Telnet

The actual connecting was done using Telnet. After installing Telnet a connecting can be established in the following manner: (dino of iemand andners, kan je dit aanvullen?)

FTP

For transferring files the File Transfer Protocol (FTP) used in this project, was FileZille. Files can be transferred to the AR Drone2 as described next: (dino of iemand andners, kan je dit aanvullen?)

NAV board

Throughout this project, on several different occasions, it will be apparent that the AR Drone2 was never rally meant to be used as we inteded to. In addition to this, Parrot SA has a vested interest in maintaining the exclusivity of its product, rightfully so. So with what little information is publicly available, reverse engineering the navigation board was a lot harder than we first thought when we began the project.

However AR.Drone2 looks a lot like the AR.Drone1, its predecessor, for which a lot of reverse engineering has allready been done by other people. Ofcourse there are differences and this is where we started reverse engineering the bits and pieces for the NAV board.

At the time we found out the device name for the motors it was obvious that /dev/ttyO1 would have to be the navboard. In the AR.Drone SDK, which we don't use for programming, we found a file called ardrone_common_config.h[1] in which the navboard command numbers are listed. This list does not give a lot of information, but does give us an indication to get started.

There are at least 3 commands that seem usefull:

00032   ADC_CMD_STARTACQ                = 1,  // to start the acquisition
00033   ADC_CMD_STOPACQ                 = 2,  // to stop the acquisition
00034   ADC_CMD_RESYNC                  = 3,  // to restart the acquisition

After starting the acquisition and performing a hexdump on the data read from /dev/ttyO1 we could see the data flowing in:

echo -e -n "\1" > /dev/ttyO1
dd if=/dev/ttyO1 count=1 bs=60 | hexdump -C

Returns a part of a stream that looks like this:

00000000  3a 00 85 2c fc 07 e8 07  e8 09 d8 ff 3e 00 fc ff  |:..,........>...|
00000010  9b 00 d7 d9 6c 03 00 00  00 00 ae 0e 00 00 00 00  |....l...........|
00000020  00 00 00 00 01 00 ca 25  30 00 06 00 01 00 93 80  |.......%0.......|
00000030  00 00 6c e6 0c 00 fe ff  1a 00 14 c0 3a 00 86 2c  |..l.........:..,|
00000040  fc 07 e8 07 e8 09 d9 ff  3c 00 fb ff 9b 00 d3 d9  |........<.......|
00000050  6c 03 00 00 00 00 ae 0e  00 00 00 00 00 00 00 00  |l...............|
00000060  01 00 ca 25 30 00 06 00  01 00 93 80 00 00 6c e6  |...%0.........l.|
00000070  0c 00 fe ff 1a 00 0f c0  3a 00 87 2c fc 07 e8 07  |........:..,....|
...

The stream of data consisted of 60 byte long sequences of which the first byte always seemed to be 3a = 58. This number is the size of the payload, which are the bytes after 3a 00. We do not know the purpose of the 00 after 3a.

After this we realized that it would be hard to find the offsets of the sensor data by just looking at the stream above. We built a driver that logged the data in a tabular way. By doing this we could then rotate the AR.Drone2 around one axis and then look what values were changing in the log file. For acceleration and gyroscope data we used a simmilar technique.

GPS

The GPS we use with the AR.Drone2 is the BU-353 GPS. To make good use of this GPS we had to create our own driver for it. That way we could extract the received data from the GPS and output it in our preferred format. To create our own driver, we first needed to know how to retrieve the data from the GPS. We downloaded the Linux USB Driver and learned from the readme that you could use the GPS with the following commando:

su root

stty -F /dev/ttyUSB0 ispeed 4800 && cat < /dev/ttyUSB0

With this we found out that we needed to create a program that opens the /dev/ttyUSB0 device and reads it at a baud rate of 4800. We had to pick a datatype since working with several datatypes at the same time would be confusing. Therefore we had to extract the right datatype string from the data strings output by the GPS and format that string into useful information.

Paparazzi on Drone

Now the necessary raw data ould be obtained and the actuators could be controlled, it's time to integrate

Integrating drone in Paparazzi

""Paparazzi Autopilot System"" Throughout this project, on several different occasions, it will be apparent that the AR.Drone was never meant to be used in this fashion. In addition to this, Parrot SA has a vested interest in maintaining the exclusivity of its product, rightfully so. With what little information is publicly available it is the team's objective to load the open-source autopilot system, Paparazzi onto an otherwise copyright protected piece of hardware. In order to do so a few steps had to be taken to get Paparazzi onto the AR.Drone 2.

• Reverse engineering the AR.Drone2

Simulation

JSBSim

Creating A Flight Dynamics Model

In order to control the otherwise highly active dynamic nature of the quadrotor, an autopilot system will be necessary because the reaction time of the pilot will, otherwise, not be sufficient to maintain stable flight. The autopilot system will be created in Paparazzi for which a prerequisite is a proper flight dynamics model (FDM). To create the FDM the team will use JSBSIM, an open-source, platform-independent, flight-dynamics and control software library. Installing JSBSIM is covered for several different operating systems on the Paparazzi Wiki, Installing JSBSIM.

Once JSBSim had been installed, the actual work could begin. Flight Dynamics and the creation of an individual model for an aircraft is essentially a case study regarding its control, stability, and performance. To model those three dynamics aspects is essentially what JSBSIM was used for but before work could begin, JSBSIM would first need to be fed a configuration file. The configuration file is written in a .xml format and, naturally, is unique to each aircraft. Although not applicable to this project, it is worth mentioning in the event that the reader of this page is not following the instruction exactly and is using it more for reference, there is a tool on the JSBSIM page called Aeromatic, which is a capable .xml configuration file generator. For those following this project closely, a link will follow for creating a suitable JSBSIM .xml configuration file for the AR.Drone2.

• Creating a JSBSIM .xml Configuration File for AR.Drone2

Flightgear

Without actually using the drone itself, and only the previously developed JSBSIM configuration file, a simulated drone can be flown in Flightgear. To do so, a CAD model of the drone is implemented to give a visualization to the simulated model. Flightgear is the preeminent open-source flight simulator backed by a large community of active users. More on the software can be found on the Flightgear website.

Creating an airframe

From the Paparazzi GCS we need to add an aircraft and attach an airframe, flightplan, settings, radio and telemetry files.