The A.R.Drone SDK provides the tools and resources needed to control an A.R.Drone from native applications running on all kinds of hardware platforms (PC, iPhone, iPad, Android and any host device supporting Wifi networks in ad-hoc mode).

It provides reference functionalities that you can customize and extend, plus code examples with their associated projects which allow the users to create a fully functional application in a matter of minutes.

The functions provided in the SDK allow an user application to very easily control the drone movements, retrieve navigation data like sensors measurements and video streams, and configure the drone behaviour.

Every ARDrone application built using the ARDrone SDK shares the same core architecture. The ARDrone SDK provides the key objects needed to run the application and to coordinate the handling of user input, display the camera video and handling the tags detection. Where applications deviate from one another is in how they configure these default objects and also where they incorporate custom objects to enhance their application’s user interface and behavior.

When you create your own application you should re-use the high level APIs of the SDK. As each application depends on the platform and device used, it is important to understand when it needs customization and when the high level APIs are sufficient. This chapter provides an overview of the core application architecture and the high-level APIs customization points.

Once connected to the AR.Drone, you can re-use the ARDrone SDK to initiate communication with the AR.Drone. Your application should manage the various devices (wifi connection, HMI). The AR.Drone SDK provides tools and methods to send commands, receive information from the AR.Drone and manage the video stream. To manage devices you need to understand the cycles of an AR.Drone application. The following sections describe these cycles and also provide a summary of some of the key design patterns used throughout the development of an ARDrone application.

The application life cycle is the minimum sequence of events that take place between the launch and termination of your AR.Drone application. You can compile the SDK with or without the main entry point provided with the SDK but your application must comply with the reference AR.Drone application life cycle to work correctly. The application is launched by calling it's main function. At this point, the application life cycle can be started. It initializes different user interfaces and calls custom SDK initialization objects from your application. During the event loop, the AR.Drone SDK calls the registered delegate objects. When the user performs an action that would cause your application to quit, the AR.Drone SDK notifies your application and begins the termination process.

You can register TOOL types for your application that include custom TOOL schemes. A custom TOOL scheme is a mechanism through which you customize specific code for your application and handle registering objects for the SDK.

To register a TOOL type for your application you specify the custom tool methods declared in ardrone_tool.h file which is introduced in "The application life cycle". The following list identifies some methods that you might want to implement in your application.

ardrone_tool_init_custom

ardrone_tool_update_custom

ardrone_tool_display_custom

ardrone_tool_shutdown_custom

ardrone_tool_exit

Methods for parsing command line

ardrone_tool_check_argc_custom

ardrone_tool_display_cmd_line_custom

ardrone_tool_parse_cmd_line_custom

Details about these methods are explained in more detail later in this document.

You must declare a threads table in vp_api_thread_helper.h file. You can add threads to your application and default threads implemented in the SDK. The listing of the default threads will be described later in this document.

To run and stop the threads, you declare MACRO in vp_api_thread_helper.h file. Use START_THREAD macro to run the thread and JOIN_THREAD macro to stop the thread. START_THREAD must be called in custom implemented method named ardrone_tool_init_custom which was introduced in "Implementing custom tool schemes". JOIN_THREAD is called in custom implemented method named ardrone_tool_shutdown_custom which was introduced in "Implementing custom tool schemes".

A delegate object handles your input device by implementing init, update and close methods in your application. The delegate object calls the init method when you register a new device in the SDK. During the event loop, the delegate object calls the update method. The delegate object calls shutdown method when the application exit or your application can directly call the ardrone_tool_input_remove method (declared in ardrone_tool_input.h file) to remove your device from the SDK.

This methods are embedded into input_device_t structure declared in ardrone_input.h file :

A method named ardrone_tool_input_add gives you a means to registering methods by passing the input_device object. Your application must add The method ardrone_tool_input_add in a custom method named ardrone_tool_init_custom which was introduced in "Implementing custom tool schemes". Adding the method ardrone_tool_input_add for each input device.

Listing 1.3 Implementing init, update and close methods

The Following code showing implementing methods for game pad controller.
Implementing update methods by using input methods defined in ardrone_input.h file. Methods are described in section "Methods for controlling the AR.Drone"

The ardrone_at_set_progress_cmd method enables you to pilot the AR.Drone with better control. It replaces pitch,roll,gaz and yaw commands which was introduced in the precedent section game-pad emulation. For example, you can use progressive commands to send the accelerometer values or to send radiogp commands.

A mechanism is provided to handle control commands. That implements, updating software and retrieving settings of the AR.Drone. You can register to the mechanism by implementing "start" and "end" methods. The delegate object calls the "start" method before running the event process and "end" method after that the event process was terminated, in which you know if the process is success or not. The methods are passed into ardrone_control_soft_update_event_t structure. Calling the method ardrone_control_send_event sends the event command.

Objects are declared in <ardrone_tool/Control/ardrone_control.h> file.

To control the AR.Drone you need to retrieve informations containing alert messages. The following Navdata are important to the user.

Communication Lost

Emergency landing

VBat low

Motors status

Cutout system detection

The following picture displays a control panel showing alert messages.

Navdata gives you informations about settings of the AR.Drone. The following list identifies some parameters.

Yaw speed (°/s)

Vert speed (°/s)

Trim Pitch (°)

Trim Yaw (°/s)

Tilt (°)

With these settings, you can adjust the control of the AR.Drone to your driving style. The following picture displays a settings panel.

To change the setting parameters of the AR. Drone, you must use the corresponding AT commands located in the file ardrone_api.h file. The following list identifies some methods to configure the AR.Drone.

ardrone_at_set_tilt, indicates to the enemy AR.Drone that it was hit.

ardrone_at_set_vert_speed

ardrone_at_set_manual_trim, to change in manual mode to configure trim parameters.

ardrone_at_set_max_angle

ardrone_at_set_yaw
...

The Navdata are sent periodically (15 times per second). A mechanism is provided to retrieve this data. To handle Navdata you should implement methods (init, process and release) that are embedded in the ardrone_navdata_handler_t structure declared in ardrone_navdata_client.h. A delegate object calls the init method when launching the Navdata client thread. During the event loop, the delegate object calls the process method. The delegate object calls release method when the thread exits. In order to register this method in the client, your application should define a Navdata table which was introduced in "Minimum requirement to compile your AR.Drone application". The following listing code shows an example to handle Navdata.

The client calls process method with a reference to a structure navdata_unpacked_t declared in ardrone_api.h file. This structure contains other structures. The following list identifies some structures.

navdata_demo_t navdata_demo; This structure contains alert messages, settings parameters and informations about single player mode.