AR Drone 2/NAV board

From PaparazziUAV
Jump to: navigation, search


At the time we were investingating the NAV board we were also looking into drivers for the motor. From that research we found that the device name for the motors was /dev/ttyO1. Next in the AR.Drone SDK, which we don't use for programming, we found a file called ardrone_common_config.h[1] in which the navboard command numbers are listed. This list does not give a lot of information, but does give us an indication to get started.

There are at least 3 commands that seem usefull:

00032   ADC_CMD_STARTACQ                = 1,  // to start the acquisition
00033   ADC_CMD_STOPACQ                 = 2,  // to stop the acquisition
00034   ADC_CMD_RESYNC                  = 3,  // to restart the acquisition

After starting the acquisition and performing a hexdump on the data read from /dev/ttyO1 we could see the data flowing in:

echo -e -n "\1" > /dev/ttyO1
dd if=/dev/ttyO1 count=1 bs=60 | hexdump -C

Returns a part of a stream that looks like this:

00000000  3a 00 85 2c fc 07 e8 07  e8 09 d8 ff 3e 00 fc ff  |:..,........>...|
00000010  9b 00 d7 d9 6c 03 00 00  00 00 ae 0e 00 00 00 00  |....l...........|
00000020  00 00 00 00 01 00 ca 25  30 00 06 00 01 00 93 80  |.......%0.......|
00000030  00 00 6c e6 0c 00 fe ff  1a 00 14 c0 3a 00 86 2c  |..l.........:..,|
00000040  fc 07 e8 07 e8 09 d9 ff  3c 00 fb ff 9b 00 d3 d9  |........<.......|
00000050  6c 03 00 00 00 00 ae 0e  00 00 00 00 00 00 00 00  |l...............|
00000060  01 00 ca 25 30 00 06 00  01 00 93 80 00 00 6c e6  |...%0.........l.|
00000070  0c 00 fe ff 1a 00 0f c0  3a 00 87 2c fc 07 e8 07  |........:..,....|
...

The stream of data consisted of 60 byte long sequences of which the first byte always seemed to be 3a = 58. This number is the size of the payload, which are the bytes after 3a 00. We do not know the purpose of the 00 after 3a.

After this we realized that it would be hard to find the offsets of the sensor data by just looking at the stream above. We built a driver that logged the data in a tabular way. By doing this we could then rotate the AR.Drone2 around one axis and then look what values were changing in the log file. For acceleration and gyroscope data we used a simmilar technique.

Internal Measurement Unit Calibration

In calibrating the Internal Measurement Unit (IMU) on the AR Drone, the Paparazzi IMU Calibration protocol was followed. Once these steps have been followed, having already initialized a ground control station, the AR Drone can produce an accurate Primary Flight Display (PFD) through Paparazzi. Issues that arise can stem from too slow a refresh rate and thusly a lagging PFD. This leads to a greater problem, namely, a reaction rate that is simply too slow; If the current state refreshes too slowly, naturally, the drone will react slowly and in most cases be very unstable. While moving the AR Drone through the air, by hand, the PFD will display these movements, albeit slowly; when placed back on the ground, or any other surface, the PFD will eventually display the corresponding attitude of the AR Drone.