GPS Integration on the drone

This project uses embedded GPS chip. We chose to use a micro-controller to interface the GPS with the drone, as this solution allows us to plug other devices via the micro-controller. The µC communicates with the AR.Drone system via an FTDI chip and USB master port that is in the drone, next to the battery stack.

Update: we developed and use an other solution. It uses a TLL cable and a program to configure the gps chip. Follow the instruction on this page and then go to GPS configuration.

System Configuration

To achieve this, we first need to install some modules (drivers) on the drone, to make possible the USB communication.

Note : this is generic if you want to communicate via USB with a serial device using a TTL chip as the FTDI RS232 USB-TTL converter chip.

Download kernel sources

Download and untar the linux kernel sources from this link (download linux.tar.gz): https://devzone.parrot.com/projects/list_files/oss-ardrone2

Compile modules

Step 1 : Install an ARM compiler

The compiler is provided by Mentor Graphics (previously Code Sourcery). You can download it from here: http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/editions/lite-edition/arm-gnu-linux (you'll need to register) Install (as root):

chmod +x arm-2012.03-57-arm-none-linux-gnueabi.bin
./arm-2012.03-57-arm-none-linux-gnueabi.bin

Install the compiler under /opt/Codesourcery/ and not in /root/Codesourcery/ as the installer defaults to.

Step 2 : Change kernel version

Get your drone kernel version: connect to the drone and open a telnet, to run uname on it

telnet 192.168.1.1

once connected (it shows you a little welcome message)

uname -a

The kernel version number looks like this : 2.6.32.9-gbb4d210

Edit the Makefile at the root of the linux directory. Four first lines are VERSION (2), PATCHLEVEL (6), SUBLEVEL (32) et EXTRAVERSION (.9). Change "EXTRAVERSION = .9" for "EXTRAVERSION = .9-gbb4d210" to match the exact kernel version number given by uname.

Step 3 : Configure Kernel

cd linux
cp kernel.config .config
make ARCH=arm menuconfig

In menuconfig, go into "Device Drivers>USB Support". Mark as a module (M) the line "USB Serial Converter support" with space bar, then enter to see drivers. Mark as module (M) the lines "USB FTDI Single Port Serial Driver", "USB Modem (CDC ACM) support".

Step 4 : Compile

Still from linux/ directory, run the compilation command:

make ARCH=arm CROSS_COMPILE=/opt/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/bin/arm-none-linux-gnueabi- modules

Set-up the drone

Step 5 : Upload to the drone

Compiled modules are in linux/drivers/usb/serial/ ftp to the drone and send usbserial.ko, ftdi_sio.ko and cdc-acm.ko.

Step 6 : test

I recommend you to test the installation of the module on the drone. Open a telnet, cd into /data/video (that's where ftp writes) and install your modules, in this order:

insmod usbserial.ko
insmod ftdi_sio.ko
insmod cdc-acm.ko

Check the installation with lsmod, the 3 modules should appear. If not, there is an issue. Check the configuration of the makefile, ask Google... good luck ;)

You can plug a serial device (with ftdi) that send data through it (there are some sample codes provided by arduino which do this) and do cat /dev/ttyUSB0 (it could be /dev/ttyACM0, depending on your arduino chip). You should see the output on the screen. If the device /dev/ttyUSB0 does not exists, you can wait a few seconds, or reboot the drone, with the arduino pluged.

Step 7 : Configure for permanent use

AR.Drone system does not provide an easy way to initialize modules. Firstly, we will create a script in /data/video where we will call insmod and launch the TCP server.

modules_path="/data/video"
port_gps=4567
device="/dev/ttyUSB0"

insmod $modules_path/usbserial.ko
insmod $modules_path/ftdi_sio.ko
insmod $modules_path/cdc-acm.ko

nc -l -l -p $port_gps -e cat $device &

Add execution rights to the script:

chmod +x launch.sh

Then, we will modify the file /etc/init.d/rcS and add a call to this script. At the end of the rcS file, add:

if [ -f /data/video/launch.sh ];then   
        /data/video/launch.sh
fi

Congrats, your done!

reboot the drone, you can open a netcat to see if yout TCP communication is okay. On your PC, in a terminal, run netcat 192.168.1.1 4567, it will output the data from the arduino.

On the station

We now need to set-up some software on the station, so that it can compute GPS data from the drone. We will use a chain of software that will get our data to our main application.

Step 8: install an launch gpsd

gpsd is a standard linux driver for gps. It understands NMEA strings and convert them to more convenient format for other softwares. gpsd is available on most standard repositories (including ubuntu), so you just have to sudo apt-get install gpsd

Now, launch gpsd. You can use it with the {gps+arduino} or {gps + TLL/USB converter} directly connected to your computer. Be sure that you have rw access to the device, or you will need to launch gpsd as root. The command is gpsd /dev/ttyUSB0 (USB0 is standard name for most USB devices, you may have different name like ACM0 for some arduino). gpsd is a deamon, so it won't display any information. Run a client, as gpsmon, to see data. (sudo apt-get install gpsd-clients) gpsd can be connected to a remote GPS via TCP or UDP. The command is gpsd tcp://adress:port. So, with our settings from previous paragraphs, it becomes gpsd tcp://192.168.1.1:4567

tip : you can run gpsd with some of this option for debugging: -N : don't deamonize; -D N : set debug level display option to N; -n : don't wait for client connection to poll GPS.

Step 9: ROS interface

First install libgps-dev, which is a dependency of this package (apt-get install libgps-dev). Then do the following:

cd ~/fuerte_workspace #or wherever you want in your workspace
#choose the corresponding branch, here it's the fuerte version of the package
git clone -b fuerte_released https://github.com/ktossell/gps_umd.git
rosstack profile && rospack profile
rosws set gps_umd
#re-source your setup.bash
rosmake gps_umd

It's now ready to use. The nodes we will use are gpsd_client/gpsd_client and gps_common/utm_to_odometry. The first listens to gpsd and publishes sensor_msgs/NavSatFix that the second subscribes and convert to nav_msgs/Odometry. You can find information about these nodes at http://wiki.ros.org/gps_umd.

###Troubleshooting ####No GPS position GPS chip can have difficulties detecting a GPS signal, particurlarly indoor. The GPS chip can take up to 10 minutes to initialize the position (refer to specific GPS documentation if you're curious about that). A solution to reduce this time is to add a battery to the GPS to avoid cold-starting it every time (refer to GPS chip documentation) ####What are the meaning of the values published by utm_to_odometry node? They are UTM positions. See the Wikipedia article. There is also converters for converting latitude/longitude to UTM, like this