Hello and welcome.
 
///////////////////////////////////////////////////////////////////////////////////////////////
Purpose:

This library is meant to allow the ARDrone 2.0 to be controlled at a higher level of abstraction, showcase use of the QRCodeStateEstimation library for quadrotor control and enable safe demonstration of automatic control of UAVs in a small space.

////////////////////////////////////////////////////////////////////////////////////////////////

How it works:

The library accepts messages that consistute a set of commands which are placed in a queue and executed sequentially.  The commands are recursively defined, so new commands can be defined using pre-existing commands and new commands can be built from the basic ones.

The library then takes these commands and sends the nessisary the low level commands to the ardrone_autonomy package.  Some of these commands are augmented by the QRCodeStateEstimation library to allow position holding and movement from point to point.

////////////////////////////////////////////////////////////////////////////////////////////////

Building/Dependencies:

This library is being made as part of a NC State University research project sponsored by NextGen Air Transportation (NGAT).  It isn't really the main goal of the project, so there may be so rough edges.  If you run into trouble, please either open an issue on the Github project or send me an email (crwest@ncsu.edu).

This code has been compiled/test on Ubuntu Linux.  The instructions are geared toward that platform, but contact me if you need help getting it working on a different one.

Required libraries/packages:
This is a ROS based library, so it is nessisary that ROS is installed on your platform.  The library was built/tested using ROS Indigo.

Required ROS packages:

ardrone_autonomy:
This excellent library for low level control of the AR Drone can be found at https://github.com/AutonomyLab/ardrone_autonomy

The indigo-devel branch was tested with this library.

ros-perception/vision_opencv:
This library helps convert ROS image messages into a format that can be used with opencv.  It appears to be part of the ros-perception suite and the source can be found here:
https://github.com/ros-perception/vision_opencv

Required libraries:

Zbar:
This library is used for find/reading QR codes.  It can be installed on Ubuntu using the following command:
sudo apt-get install libzbar-dev

Alternatively, it can be compiled from the source at:
http://zbar.sourceforge.net/

OpenCV:
OpenCV is a powerful library for vision processing.  It can be installed on Ubuntu by running the following commands:
sudo apt-get install libopencv-dev
sudo apt-get install libopencv-highgui-dev
sudo apt-get install libopencv-calib3d-dev

Alternatively, it can be compiled from the source at:
http://opencv.org/downloads.html

SDL:
ardrone_autonomy requires SDL, so you might want to install that in case their autoinstall functionality doesn't work.  It is currently using version 1.2.  It can be installed on Ubuntu using the following command:
sudo apt-get install libsdl1.2-dev

The ardrone_command library uses the catkin build system, so to integrate it into your system: 

1. Install the required libraries and ROS packages.
2. Clone the git repository into your catkin workspace source directory (catkin_ws/src/).  This can be be done with the following command:
git clone https://github.com/charlesrwest/ardrone_command.git 
3. Run catkin_make at the root of your workspace (catkin_ws).

////////////////////////////////////////////////////////////////////////////////////////////////
Creating a project based on ardrone_command

There are two distinct styles/ways that you can make a new ROS package that uses ardrone_command to control the quadrotor.

The traditional (for ROS) way:
ardrone_command creates a executable that can be run to make a ROS node with network interfaces.  The ardrone can then be controlled by sending ROS requests to "/ardrone_command/commandInterface" and receiving the information on what ardrone_command is doing at any given time via the information it publishes via ROS topics, as demonstrated in the ardrone_command_test package (topic details toward the end of the readme).  

Library linking way:
For really simple projects, you can link to the ardrone_command library directly and create a ARDroneControllerNode object.  This object will attempt to connect to the AR Drone (ardrone_autonomy still needs to be active) in a thread it creates and can be instructed to follow commands via the threadsafe addCommand function.  ardrone_command_test's cmake file demonstrates how to link to the library and the ardrone_command/src/exec/ardrone_application_node.cpp file has commented out examples of manually adding commands.


////////////////////////////////////////////////////////////////////////////////////////////////

Running/using the library:

//////////////////
WARNING!: Quadrotor aircraft can be dangerous and can damage themselves or others.  Be sure to have a reasonably large/clear area before doing stuff with it (at least 15'x15', with smaller possible once you have a good handle on its behavior). 

 Also, have the following command setup and ready to go so that you can make the drone land quickly if something goes wrong:

rostopic pub /ardrone/land std_msgs/Empty

QR code based commands will cause the aircraft to land quickly if tracking is lost (hopefully failsafe for demos), but bad non-QR code base commands will happily run wild.  Please be safe and be ready to stop the AR Drone if something happens.
//////////////////

To get started with ardrone_command, do the following:

1. Connect to the AR Drone 2.0's network.
2. Start ROS core to enable ROS packages to be used (run "roscore" in a terminal and leave it running)
3. Start ardrone_autonomy to get/control low level ardrone behavior (all ardrone_autonomy command interfaces and data are still available, you just may be fighting with the commands sent from the ardrone_command library).  This can be done with the following if your system is correctly configured:  

rosrun ardrone_autonomy ardrone_driver _realtime_navdata:=True _navdata_demo:=0 _realtime_video:=True

4. Start  the ardrone_command node, which will wait for commands before doing anything.  This can be done with the following command:

rosrun ardrone_command ardrone_command

5.  Start sending commands to the ardone_command node service ("/ardrone_command/commandInterface/").  This can be done by using the command class defined in command.hpp (which is not yet automatically exported, so just copy it from the project for now with attribution).  An example controlling project can be found here:

https://github.com/charlesrwest/ardrone_command_test

Alternatively, you can modify the main function of ardrone_command library directly to add a fix set of commands that the drone will do.

////////////////////////////////////////////////////////////////////////////////////////////////
Library design/Recommended command use:

The QRCodeStateEstimation used with this library was taken from another project and details on how to make good QR codes to use for position estimation can be found there.  The library was tested with a 26 in x 26 in QR code at a distance of about 3 meters.
https://github.com/charlesrwest/QRCodeStateEstimation

This library currently has a hardcoded camera calibration for the forward camera of the AR Drone.  This is defined in the main function (in case you need to change it) and was created using the OpenCV's calibration software (http://docs.opencv.org/doc/tutorials/calib3d/camera_calibration/camera_calibration.html) (using video recorded from the AR Drone's manual piloting software, found here https://projects.ardrone.org/ ).

There are two main types of commands in the library.  One type of commands alters the state machine associated with the library to make the AR Drone do some sort of behavior (such as seek a particular point in the QR Code coordinate system).  The other type of simply blocks until some condition is met, allowing the low level behaviors to do their job.  Definitions and descriptions of all of the supported commands can be found in the command.hpp header file.  New commands can be made by inheriting from the command class and adding subcommands.

Command list:

Behavior modification commands:

ClearCommandQueueCommand:
This command will clear all of the remaining commands in the command queue.

EmergencyLandingCommand:
This command will set the drone to land and clear all of the remaining commands in the command queue.

EmergencyStopCommand:
This command will set the drone to turn off all motors and clear all of the remaining commands in the command queue.

TakeoffCommand:
This command will tell the drone to takeoff.

LandingCommand:
This command will tell the drone to land.

TargetAltitudeCommand:
This commands takes the altitude to go to (measured by the ultrasonic sensor) and the library will do PID control to try to maintain the altitude.

HorizontalHeadingCommand:
This command takes the x/y direction to go in and sets the ardrone to go in that direction until told otherwise

AngularVelocityCommand:
This command takes an angular velocity and tells the ardrone to spin in that direction until told otherwise.

FlightAnimationCommand:
This command tells the AR drone to do one of several types of stunts.  Make sure you have a clear area and a high roof before using any of the flips.  You should also use a wait command to wait for the animation to finish before processing other commands.


LEDAnimationCommand:
This command makes the LED on the AR drone flash for a animation.

MaintainPositionAtSpecificQRCodePointCommand:
This command tells the AR drone to go to a point specified in a certain QR code's coordinate system (Z outward from the QR code, X left and Y up with the side of the QR code with two rectangles on the -Y side) and attempt to hover there until told otherwise.  This is a QR code based command and as such will case the AR Drone to automatically land if tracking is lost for a second or more (safety feature).  

This can be used to have the AR drone fly patterns (such as a square).  Since the points are defined in the QR code coordinate system, if the QR code is slowly rotated, the AR drone will follow. This command is usually used with MaintainOrientationTowardSpecificQRCodeCommand, so that the tag is kept in view as the AR drone moves.


CancelMaintainPositionAtSpecificQRCodePointCommand:
This command tells the AR drone to stop trying to maintain its position in the QR code coordinate system.  This means that it will no longer land if tracking is lost (if that is the only QRCode based command currently being used).


MaintainOrientationTowardSpecificQRCodeCommand:
This command tells the AR drone to rotate to keep a certain QR code at the center of its view (important if it is being used to estimate the position of the AR Drone).

CancelMaintainOrientationTowardSpecificQRCodeCommand:
This command cancels the effects of MaintainOrientationTowardSpecificQRCodeCommand.

Wait commands:

WaitCommand:
This command stops the AR drone from processing any new commands for a designated number of seconds.

WaitUntilTagIsSpottedCommand:
This command stops the AR drone from processing any new commands until either a oriented roundel tag is spotted or the designated number of seconds has passed.


WaitUntilSpecificQRCodeIsSpottedCommand:
This command stops the AR drone from processing any new commands until either certain QR code is spotted (identified by its unique identifier string) or the designated number of seconds has passed.


WaitUntilPositionAtSpecificQRCodePointReachedCommand:
This command stops the AR drone from processing any new commands until either the AR drone is within a certain distance of the currently designated target QR code point or the designated number of seconds has passed.

WaitUntilAltitudeReachedCommand:
This command stops the AR drone from processing any new commands until either the AR drone reaches a certain altitude or the designated number of seconds pass (it is often used with takeoff).

Published Services:
/ardrone_command/commandInterface/:  
Commands can be sent to ardrone_command from your application using the "/ardrone_command/commandInterface/", which expects a valid serialized_ardrone_command message and returns a "true" bool value to confirm the command was added to the queue.  The best way to utilize this interface is to link to ardrone_command and use the "command" class's serialize interface to create a serialized_ardrone_command to send.  This is demonstrated in ardrone_command_test

Published topics:
Message definitions can be found in the ardrone_command/msg folder.  You can see examples for accessing each of these types of information sources in ardrone_command_test

/ardrone_command/command_processing:
This topic publishes serialized_ardrone_command messages when the ardrone_control library starts working on that command.  This is probably the most important topic and can be used to know what (in a broad sense) the drone is currently doing.

/ardrone_command/qr_code_state_estimates:
This topic publishes qr_code_state_info messages which detail the pose information retrieved from all observed QR codes and their associated identifier/dimension.

/ardrone_command/altitude_control:
This topic publishes altitude_control_state messages which detail the current PID values which are used to control the ardrone's altitude when the QR code based commands are not enabled.

/ardrone_command/go_to_point_control:
This topic publishes qr_go_to_point_control_info messages which detail the PID values and other information which are used in go to point commands, including distance from the target point.

/ardrone_command/orientation_control:
This topic publishes qr_orientation_control_info messages which detail the PID values of the process controlling the rotation of the AR drone to track a QR code.