First Impressions About AR.Drone 2.0

I got an AR.Drone 2.0 some weeks ago and have been getting in touch with it, mostly studying its basic flight behaviour. My first impressions are mainly positive - AR.Drone is a well-finished product that works out of the box and is versatile and amazingly robust.

Control and Video Recording

The drone acts as a WiFi access point to provide a control link. The controller can be any Android or iOS device, such as a phone or a tablet, which requires a special flight control app. I normally use Galaxy Tab 10.1, which runs Android.

The flight control is very similar to some first-person shooter games for touch devices, with control pads for both thumbs. By pressing with the left thumb, you enable tilt, so that it tilts and moves to that direction as you tilt the controller. There are two control modes - relative and absolute. In the relative mode, tilting forward tilts the drone forward in its forward direction, while in absolute mode the drone uses compass to tilt in the same absolute direction as the device. The right thumb controls altitude and direction. The interface requires some getting used to and I can't say it's great, but it works.

There's a launch/landing button, as well as an emergency shutdown that stops the drone immediately. There's also a button to switch between the main camera and the ground camera. Behind a configuration menu, there are various settings, such as for altitude and tilt limits, and the control mode. The drone can also do flips, which are fun for about one time.

To record video you just tap a button in the control interface. It normally stores the video on the control device, but the drone also has a built-in USB connector to store the video on a USB memory. Using the USB store is usually better, because when using the WiFi connection, it can often lose the connection momentarily (or longer), as can be seen in the following video when the drone almost flies away.

The video is 720p and reasonably good quality, at least on good weather. It's a bit shaky and not quite production quality, but hey, for the price it's quite enough. On snow it's probably more jerky than on a surface with more texture, as the visual stabilizer makes rather erratic corrections.

The biggest issue is that the main camera is leveled horizontally and can not be tilted. So, to get angled shots, you have to fly the drone to tilt it. It is possible to tilt the camera head with a knife and some glue, and get great results with just some 5° tilt.

The video quality can be greatly enhanced by attaching a better camera to the drone. I have a GoPro HD HERO2, so I'll have to try that soon. The GoPro weighs some 100 grams, and the drone can carry it without much effort. However, the rugged camera cover weighs another 100 grams, so it is too heavy to be used. The legs need to be extended to keep the lens away from the ground. And fly carefully.

Indoor and Outdoor Hulls and Build Quality

The drone came with both an indoor and an outdoor protective hull. The purpose of the indoor hull is to protect the rotor blades if and when the drone bumps into a wall, as well as the walls themselves. The blades are incredibly flexible and, amazingly, they have lasted dozens of contacts with various objects. The drone has a safety feature that it makes an instant emergency stop if the blades hit something, which seems to prevent most damage.

It is worth to note that the indoor hull does not help almost at all when colliding against branches, so when the drone hits a branch, it almost always crashes. As the fall distance outdoors is often rather high, typically over two meters, it is usually enough to break the rims of the indoor hull. So, the purpose of the outdoor hull is mainly to preserve the indoor hull from breaking into a hundred pieces.

The motors and the small electronic boards of their speed controllers are completely exposed. Fortunately, even though the drone has crashed in wet snow many times, the electronics haven't short-circuited.

Apparently, the parts do break sometimes, as all the parts are available as spare parts. They are a bit expensive though, and building a drone from the separate parts is more than twice as expensive.

Flight Stability

The drone has a number of sensors to maintain its position, level, and direction:

• 3-axis accelerometer
• ultrasonic range finder at the bottom for altitude stability (up to 6 meters)
• barometric pressure sensor for altitude stability (at 6+ meters)
• secondary ground camera for visual stabilization
• 3-axis gyroscope 
• 3-axis magnetometer (compass)

The magnetometer is especially nice, as coupled with the magnetometer of the controlled device, it allows absolute direction control, so that tilting the controller causes the drone to fly to the same direction.

Unfortunately, even all the sensors are not always sufficient to maintain the position properly. The ground camera is only useful if there's enough light for it (see the problems later) and the ground has enough texture to stabilize on. The ultrasonic sensor doesn't seem to do its work quite properly, and the drone's altitude sometimes changes uncontrollably, for example by climbing to the roof.

I would expect that the next version gets a GPS module for better long-range stability. With that, it could have homing feature, as well as planned flight routes. Most of the more expensive drones already have that.

Flying Away

There's one thing that I learned quite well. The WiFi range is rather limited, just about 40 or so meters, and once it gets out of the range, it won't land immediately. So, it will fly away with the wind (1, 2, etc).

So, when trying it out at night, I lifted it up to some 40 meters...at which point it lost the connection and I couldn't control it any longer. As it didn't have any visual stabilization in the dark, it started slowly drifting away over the treetops into the night, and I soon lost sight of it.

So, a rescue effort was launched, combing the forest in a 10-meter grid. The forest was covered in 30 cm deep snow, so I had a good opportunity to practice skiing with my Altai Hoks.

After many hours of searching on two days, it was finally found in the snow some 200 meters into the forest. The indoor frame was stuck in a tree, and came down later after some windier days. Had the drone been stuck up in a 30 meters high pine tree, it would have been almost impossible to find.

To make the search easier if it ever flies away again, I taped the drone with plenty of reflecting tape so that it shines brightly from over 100 meters away when illuminated with a headlamp.

The main issue, however, is the limited range of the WiFi link. It's specified to be some 50 meters, some claim 80 meters, but it depends on the controller. With my Galaxy Tab 10.1 it seems to be around 40 meters. Some people have used directional antenna to extend the range, some even up to 2.25 km!

Logging In

The fun part about AR.Drone is that its on-board controller is a Linux computer and you can log into over the wireless network with Telnet.

First, I found out the network, then guessed that the device is .1 in the subnet:

magi@vaire:~$ ifconfig
wlan0     Link encap:Ethernet  HWaddr c0:18:85:70:65:48 
          inet addr:192.168.1.3  Bcast:192.168.1.255  Mask:255.255.255.0
...

magi@vaire:~$ telnet 192.168.1.1
Trying 192.168.1.1...
Connected to 192.168.1.1.
Escape character is '^]'.

BusyBox v1.14.0 () built-in shell (ash)
Enter 'help' for a list of built-in commands.

# ls
bin       dev       factory   home      licenses  proc      sbin      tmp       usr
data      etc       firmware  lib       mnt       root      sys       update    var

There are a number of TCP ports open. The port 23 is for Telnet and 21 is for FTP. I assume that it uses FTP for updating the firmware. Then there's a number of ports in range 5551-5559, I suppose those are the control links. The video could be transmitted over UDP to allow losing frames on bad connection instead of piling them up.

# netstat -l -t
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       
tcp        0      0 0.0.0.0:5551            0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:5553            0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:5555            0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:5557            0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:23              0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:5559            0.0.0.0:*               LISTEN      

There were at least couple of interesting-looking processes:

# ps
...
  806 root     77672 S    /bin/program.elf -360p.slices 0 -live.tcp 
  896 root      1540 S    /bin/parrotauthdaemon 
...

There also seems to be at least one AR-related kernel module:

# cat /proc/modules
ov7670 9943 1 - Live 0xbf083000
soc1040 20292 2 - Live 0xbf079000
omap3_isp 95899 9 - Live 0xbf056000
ar6000 278079 0 - Live 0xbf000000

And various memory devices:

# mount
rootfs on / type rootfs (rw)
ubi1:system on / type ubifs (rw,relatime)
tmp on /tmp type tmpfs (rw,relatime)
proc on /proc type proc (rw,relatime)
dev on /dev type tmpfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
sys on /sys type sysfs (rw,relatime)
none on /proc/bus/usb type usbfs (rw,relatime)
ubi0:factory on /factory type ubifs (ro,relatime)
ubi2:update on /update type ubifs (rw,sync,relatime)
ubi2:data on /data type ubifs (rw,relatime)

The UBIFS is some sort of Flash memory filesystem.

Well, nothing very interesting. The control applications seem to be closed binaries, both in the kernel and user-space, and it's a big question if it is possible to hook custom on-board applications to do something interesting.

The main development APIs are for using over the remote link. I haven't yet looked at those, but will at some point.