Finally I found some time to post my experiences with implementing a library in native C# that allows to pilot the ARDrone. In stead of explaining what the ARDrone exactly is I like just to point to the product site itself which can be found at: http://ardrone.parrot.com/parrot-ar-drone/usa/.
It basically is a programmable remotely controlled quadricopter. Communication happens via Wi-Fi. The out of the box API support focuses on development on iPhone, although it is possible to take the existing C SDK and compile it for use on other platforms. You can find plenty of examples when you look on the web. I took a slightly different approach in that I did not use the existing SDK (except for research on how it all works) but created a completely managed C# library from scratch.
This is the first post of the following series of articles:
- .NET DroneController – Introduction
- .NET DroneController – How To Part 1
- .NET DroneController – How To Part 2
- .NET DroneController – WPF Multitouch
- .NET DroneController – Path Designer
- .NET DroneController – Looking at the code (coming)
The purpose of this article is not to go into much detail on the actual code, this is an effort I will maybe take up gradually at a later time, but to stay pragmatic and explain how the library can be used in real life.
This is a picture that shows the high level composition of the .NET DroneController:
The important parts of the DroneController library are:
DroneControllerConfiguration: When a new DroneController is created you can use the DroneControllerConfiguration to configure it.
Communication Center: This is the heart of the DroneController, it provides the actual communication between the internals of the DroneController and the ARDrone. The Communication Center spawns for each communication channel a new thread on which it sets up a UDP or TCP session. Currently four communication channels are supported:
- The Navigation Data channel: This channel receives information from the ARDrone like status, positional parameters, tag detection info and so on. (UDP)
- The VideoStream channel: This channel receives the raw data coming from the two video cameras. (UDP)
- The ATCommands channel: This channel is used to send the commands to the ARDrone. (UDP)
- The Control channel: This channel is use to send/receive control information to and from the ARDrone. (TCP)
Command Center: This is the place where commands are sent to. These commands are formatted according to the rules defined by the ARDrone and put on a command queue. The Communication Center empties this queue on a predefined interval.
DroneProxy: This represents the ARDrone in the DroneController. Information about the ARDrone is stored at this level. Getting information from the DroneProxy is like getting information from the actual ARDrone.
IDroneCommander: This is the contract that allows consumers to interact with the DroneController. It defines the methods supported by the ARDrone like: Takeoff, Land, SteFlatTrim, PlayLedAnimation and so on. The DroneController implements this contract.
IInputProvider: This is the contract that has to be implemented by device controllers. The contract defines an entry point for the IDroneCommander. In this way can the device controller pass commands to the DroneController.
What does the DroneController support:
- Pilot the ARDrone via the supported commands (look for further info on the official developer support site of Parrot)
- Make video recordings of the frames captured by the ARDrone cameras. The output format is WMV.
- Save the current video frame as pictures. The output format is JPEG.
- Subscribe to several events that provide vital information (video, connection status, health status, ARDrone info, Tag detection info, …)
- Several input providers are supported including Wiimote. Additional ones can be easily created by implementing the IInputProvider interface.
What’s in the related projects:
- A sample of a simple WPF interface using the DroneController.
- A more advance sample using multitouch features of .NET 4.0 and Windows 7.
- An experimental extension that uses a Workflow metaphor to design automated flights.
- Experimental follow me procedure that makes the ARDrone follow a coloured tag (this is something that still needs some redesign and refinement)
The DroneController is written completely in C#, the video recording and wlan connectivity part in it and the Wilke.Interactive.Drone.InputProviders assembly rely on following third party libraries:
- Managed Wifi API – (http://managedwifi.codeplex.com/)
- WiimoteLib.dll – (http://wiimotelib.codeplex.com/) provides interfacing with Wiimote.
- SlimDX.dll – (http://slimdx.org/) managed DirectX wrapper used for interfacing with Joystick.
- WindowsMediaLab.dll – (http://windowsmedianet.sourceforge.net/) managed Windows Media wrapper used for recording/encoding WMV videos.
- Microsoft.WindowsAPICodePack.dll – (http://code.msdn.microsoft.com/WindowsAPICodePack) used for interfacing with Flexis JM Badge Board.
- Microsoft.WindowsAPICodePack.Sensors.dll – (http://code.msdn.microsoft.com/WindowsAPICodePack) used for interfacing with Flexis JM Badge Board.
This is the version info found on the ARDrone (telnet 192.168.1.1 and then type cat /data/config.ini) :
- num_version_config = 1
- num_version_mb = 17
- num_version_soft = 1.0.4
- soft_build_date= 2010-07-16 15:12
I did not update to the latest firmware since I read on the forum about some instabilities. This might or might not be the case but I did want to avoid extra complications. According to the latest official documentation no major changes have taken place on the level of AT Commands between the two last firmware updates so the DroneController should work fine with it. If people using the latest firmware do have issues please let me know.
In the next part I will talk about how to use the ARDrone controller.