AR Drone 2/NAV board - Revision history

SteveB: /* Internal Measurement Unit Calibration */

2013-01-21T11:46:49Z

Internal Measurement Unit Calibration

← Older revision		Revision as of 05:46, 21 January 2013
Line 32:		Line 32:

	==Internal Measurement Unit Calibration==		==Internal Measurement Unit Calibration==
	In calibrating the Internal Measurement Unit (IMU) on the AR Drone, the Paparazzi [[ImuCalibration\|IMU Calibration]] protocol was followed.		In calibrating the Internal Measurement Unit (IMU) on the AR Drone, the Paparazzi [[ImuCalibration\|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.

	[[Category: AR Drone 2]]		[[Category: AR Drone 2]]

SteveB: /* Internal Measurement Unit Calibration */

2013-01-21T11:29:39Z

Internal Measurement Unit Calibration

← Older revision		Revision as of 05:29, 21 January 2013
Line 32:		Line 32:

	==Internal Measurement Unit Calibration==		==Internal Measurement Unit Calibration==
	In calibrating the Internal Measurement Unit (IMU) on the AR Drone, the [[ImuCalibration]] ~~Paparazzi IMU Calibration~~ protocol was followed		In calibrating the Internal Measurement Unit (IMU) on the AR Drone, the Paparazzi [[ImuCalibration\|IMU Calibration]] protocol was followed.

	[[Category: AR Drone 2]]		[[Category: AR Drone 2]]

SteveB: /* Internal Measurement Unit Calibration */

2013-01-21T11:29:08Z

Internal Measurement Unit Calibration

← Older revision		Revision as of 05:29, 21 January 2013
Line 32:		Line 32:

	==Internal Measurement Unit Calibration==		==Internal Measurement Unit Calibration==
	In calibrating the Internal Measurement Unit (IMU) on the AR Drone, the [ImuCalibration] Paparazzi IMU Calibration protocol was followed		In calibrating the Internal Measurement Unit (IMU) on the AR Drone, the [[ImuCalibration]] Paparazzi IMU Calibration protocol was followed

	[[Category: AR Drone 2]]		[[Category: AR Drone 2]]

SteveB at 11:26, 21 January 2013

2013-01-21T11:26:45Z

← Older revision		Revision as of 05:26, 21 January 2013
Line 30:		Line 30:
	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.		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.		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 [ImuCalibration] Paparazzi IMU Calibration protocol was followed

	[[Category: AR Drone 2]]		[[Category: AR Drone 2]]

Flixr: add AR Drone 2 category

2012-12-21T17:12:29Z

add AR Drone 2 category

← Older revision		Revision as of 11:12, 21 December 2012
Line 1:		Line 1:
			<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>AR Drone 2</categorytree>

	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[https://projects.ardrone.org/embedded/ardrone-api/d3/d19/ardrone__common__config_8h-source.html] 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.		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[https://projects.ardrone.org/embedded/ardrone-api/d3/d19/ardrone__common__config_8h-source.html] 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.

Line 28:		Line 30:
	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.		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.		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.

			[[Category: AR Drone 2]]

Flixr: moved NAV board AR.Drone2 to AR Drone 2/NAV board

2012-12-21T17:12:05Z

moved NAV board AR.Drone2 to AR Drone 2/NAV board

← Older revision	Revision as of 11:12, 21 December 2012
(No difference)

Bdelrue at 12:25, 15 November 2012

2012-11-15T12:25:29Z

← Older revision		Revision as of 06:25, 15 November 2012
Line 1:		Line 1:
	~~== Navigation 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[https://projects.ardrone.org/embedded/ardrone-api/d3/d19/ardrone__common__config_8h-source.html] 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.
	~~Reverse engineering~~ the ~~navigation~~ board ~~was a lot harder than~~ we ~~first thought when we began~~ the ~~project~~.
	~~At the time~~ we found ~~out~~ the device name for the motors it was ~~obvious that~~ /dev/ttyO1 ~~would have to be the navboard~~.
	In the AR.Drone SDK, which we don't use for programming, we found a file called ardrone_common_config.h[https://projects.ardrone.org/embedded/ardrone-api/d3/d19/ardrone__common__config_8h-source.html] 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:		There are at least 3 commands that seem usefull:

Bdelrue: Created page with "== Navigation board == Reverse engineering the navigation board was a lot harder than we first thought when we began the project. At the time we found out the device name for the…"

2012-11-15T12:17:22Z

Created page with "== Navigation board == Reverse engineering the navigation board was a lot harder than we first thought when we began the project. At the time we found out the device name for the…"

New page

== Navigation board ==
Reverse engineering the navigation board was a lot harder than we first thought when we began the project.
At the time we found out the device name for the motors it was obvious that /dev/ttyO1 would have to be the navboard.
In the AR.Drone SDK, which we don't use for programming, we found a file called ardrone_common_config.h[https://projects.ardrone.org/embedded/ardrone-api/d3/d19/ardrone__common__config_8h-source.html] 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.