AR Drone 2/NAV board
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.