TU Delft - Lasergame with Autonomous AR Drone
Introduction
Our focus in the development of the autonomous AR.Drone is focused on the lasergaming industry. In this field our goal is to implement the AR.drone as a observing and later on in the project participating member of the game. We feel that there is quite a lot of potential for an implementation of the quad rotor, because we believe that using it we can create a new dimension in laser gaming. With its manoeuvrability it will be able to easily get around the laser game obstacle course and its futuristic looks will integrate perfectly with the laser game environment.
In our project we have chosen to work with the Standard Development Kit (SDK), which is already present on the AR.Drone. To get this done we needed to combine Paparazzi with the programs JSBSim and FlightGear.
Github
For this project we used a repository, Github. Developers often use a repository for developing their software projects. When using a repository, developers can upload and download the code developed for the project. This allows multiple people to work on the same project at the same time without getting in eachother's way. It is in this case very useful and we will use Github, a populair open source repository site. For beginners, please read the manual to setup Github for Ubuntu:
Our git repository is at Github RoboticaTUDelft in the "minor2" branch. You can change to this branch bij executing the following command "git checkout minor2". Because most of the work inside paparazzi between our implementation and the one from "minor1" is the same, it can be possible that some parts aren't merged between the two branches.
The Laser Gaming Setup
The exact way in which we are going to implement the AR.Drone in the laser gaming industry will be decided later on in the process. We currently have four options, varying in difficulty and achievability:
- Enemy: The AR.Drone will be used as an interactive, shooting player that can be shot as well, possibly working in teams of multiple quad rotors
- Scout: The AR.Drone will survey a certain area streaming back its video, allowing players to know where enemies are
- Mine-deployer: To allow for a more fast-paced game the AR.Drone will find a player and hover around its position. It will then begin counting down, which means the player needs to move or risk getting hit by the virtual explosion of the AR.Drone
- Observer: As there are nearly always people waiting while other people are playing, the AR.Drone can be used as a tool to live-stream the current game to a beamer for everyone to see. Games could also be taped and watched by the players after the game is over, and could even be sold
Implementation
During the test phase we want to have an adjustable system that we can tweak while working. This is the reason that we made a PIC based design. For testing we are going to use a system based on the RC-5 protocol by Phillips. The RC-5 protocol is used for remote controls. We are going to use it for sending and receiving information about the players.
Simulation
Model
- Setting up FlightGear such that it loads your model. See AR.Drone_2_-_Flightgear.
Combining Paparazzi with FlightGear and JSBSim
To get the AR.Drone to fly autonomously a model of the system is required. This can be created using paparazzi combined with JSBSim and FlightGear. The following steps will guide you through the process of setting up an environment to simulate the AR.Drone 2 controlled by Paparazzi. This will describe how to set up the simulation environment in Linux. It has been tested using Ubuntu, but it should work under any recent distro.
- Install the ground station. See Installation.
- Install JSBSim. See JSBSim.
- Install FlightGear and link it to Paparazzi. See Simulation#View_the_simulation_in_Flight_Gear.
Getting information
Getting Started
This project is developed by using Linux, ubuntu. We don't support information for other linux distributions, but feel free to try it out.
- Follow the instructions described in the "Getting the cross-compiler".
- Get the source from our github which is explained in the section above.
- Build the paparazzi source (for more information: [1])
- You are ready to develop with our project.
The cross-compiler
- Download the cross-compiler from [2]
- Open the terminal and direct to your home directory.
- Type the following commands (without the $):
$ sudo chmod +x codesetup.sh $ sudo ./codesetup.sh
Wait a few minutes and you're done!
AT Commands
The AR.Drone 2 has a self made protocol for controlling the AR.Drone 2 remotly over wifi. More information can be found at AT Commands AR.Drone 2.
The AR.Drone 2 also has a self made protocol for sending navdata to the client over wifi. More information can be found at Navdata AR.Drone 2.
GPS signals
To let our AR.Drone 2 communicate with Paparazzi an external BU-353 GPS is used. For the implementation see GPS Driver AR.Drone2.
Telnet
The AR.Drone 2 has a telnet interface that opens a root shell on the AR.Drone 2, which is needed to test and install software. More information can be found at Telnet AR.Drone2.
FTP
The AR.Drone 2 also has a FTP server running, which makes it possible to upload files like programs to the AR.Drone 2. More information can be found at FTP AR.Drone2.
Programming
AR.Drone 2 internal communication
We use internal communcation to control the AR.Drone 2 and recieve the navigation data from the AR.Drone 2. This is done by using the AT commands and the navdata with a socket connection to "localhost". The control and navigation data run in seperate threads inside paparazzi, to make sure that both connections are kept alive. The navigation data thread sends all the information is has to paparazzi each update. The control thread waits for paparazzi to send commands and keeps the connection alive by sending a dummy command every second(because the timeout is 2 seconds).
Using the GPS signals
We will use an external GPS reciever which will be connected to the AR.Drone 2 usb or telnet usb port. We still have to figure out if it is possible to adjust the default driver for the USB port on the AR.Drone 2, because this is configured as an external disk which is accesable with FTP. When we have figured out if this is possible, the default usb-connector of the GPS reciever doesn't need to be modified to fit the telnet usb port at the bottom of the AR. Drone 2.
Because of the great support of GPS modules inside paparaazi, we don't have to implement the GPS module inside paparazzi ourself.
Wifi implementation inside paparazzi
Paparazzi doesn't support wifi connection with the base station by default. We are implementing this by creating a socket connection between the AR.Drone 2 and the base station and send the communication packets using a self-created protocol.