Pololu Robotics & Electronics
My account Comments or questions? About Pololu Contact Ordering information Distributors

Understanding data output from gyro


Hi, I am using the LPY510AL and reading it with a Wixel.
I have created a test harness, with a Maestro to contol a servo and the LPY510AL mounted on the servo arm.
The Wixel reads the gyro in a tight loop and outputs to the virtual com port the gyro readings X and Z and a time stamp.
I can then capture the output with a terminal program and graph the results in Excel.
What I see is not what I would expect.

The Maestro is running this simple script:

# gyro testbed begin 2000 8000 0 servo delay 2000 3840 0 servo delay repeat
So the servo swings right pauses then left pauses and repeats. At zero speed and zero acceleration.
I would expect from this motion to get values above resting a pause then values below resting and a pause.
I let the capture run for 10 times through the loop. I expect a graph to look more like a sine wave.
Can you explain this data?
The Wixel code is longer and much is commented out to remove any outside the gyro issues.

/* wireless_gyro_tracker app:
 * James Graham Software Specialites
 * Allows you to make a wireless pan tilt tracker using two Wixels,
 *  and a gyro
 * One Wixel should be running the wireless_maestro_link app and be
 * connected to a Maestro via serial.  The other Wixel should be running this app,
 * and be connected to the gyro.
 * The Maestro is connected to a Pan servo on 0 and a Tilt servo on 1
 * == Pinout ==
 * P0_1 = Gyro Z analog input
 * P0_2 = Gyro X analog input
 * == Parameters ==
 * param_radio_channel 

#include <wixel.h>
#include <usb.h>
#include <usb_com.h>
#include <radio_com.h>
#include <radio_link.h>
#include <math.h>
#include <stdio.h>

#define TX_INTERVAL 10 // time between transmissions (ms)

void updateLeds()

void txGyroState()
    static uint8 lastTx = 0;
	static uint16 lastPan = 6000;
	static uint16 lastTilt = 6000;
 	//uint8 servo;
    //uint16 target;
	uint16 fx, fz;

    fx = adcRead(2);
    fz = adcRead(1);

	if (usbComTxAvailable() >= 30)
		uint8 XDATA report[30];
		uint8 reportLength;
		reportLength = sprintf(report, "%1u,%1u,%1lu\r\n", fx, fz, getMs());
		usbComTxSend(report, reportLength);
    if ((uint8)(getMs() - lastTx) > TX_INTERVAL )
		target = lastPan;		
		servo = 0;
		if(fx > 850)
			target = 7200;
		else if(fx < 670)
			target = 4800;
		if (target != lastPan)
			lastPan = target;
			if (radioComTxAvailable() >= 4) // thanks David
				radioComTxSendByte(0x84);  // command byte: Set Target.
				radioComTxSendByte(servo); // channel number.
				radioComTxSendByte(target & 0x7F); //  byte holds the lower 7 bits of target.
				radioComTxSendByte((target >> 7) & 0x7F); // byte holds the bits 7-13 of target.
		target = lastTilt;		
		servo = 1;
		if(fz > 850)
			target = 7200;
		else if(fz < 670)
			target = 4800;
		if (target != lastTilt)
			lastTilt = target;
			if (radioComTxAvailable() >= 4) // thanks David
				radioComTxSendByte(0x84);  // command byte: Set Target.
				radioComTxSendByte(servo); // channel number.
				radioComTxSendByte(target & 0x7F); //  byte holds the lower 7 bits of target.
				radioComTxSendByte((target >> 7) & 0x7F); // byte holds the bits 7-13 of target.
		lastTx = getMs();

*  listen for data returning from Maestro
*  not implemented as nothing is requested 
*  will read and echo to com port
*  future use includes position data from servos
void rxMaestro()
	uint8 readBytes;
	readBytes = 0;
    while(radioComRxAvailable() && usbComTxAvailable())
	if((usbComTxAvailable() > 2) && (readBytes > 0))
		usbComTxSendByte(13);	// \r
		usbComTxSendByte(10);	// \n

void main()
	radioComRxEnforceOrdering = 0;
    //disable pull-ups on inputs hooked to Gyro outputs
    setDigitalInput(1, HIGH_IMPEDANCE);
    setDigitalInput(2, HIGH_IMPEDANCE);

		//rxMaestro();  // not in use yet no data expected


I get the same data with or without the commented code executing.
I am attaching the log file from Terminal and the graph from Excel.
Gyro test harness capture.zip (114 KB)
960-2000-0-2.zip (12.9 KB)


Hello, the data you gave us has some large gaps in it; for example there is no data between time=6364 to time=11806. This makes me think there is something wrong with your Wixel code or (more likely) the way you are using your terminal program.

At rest, I would expect the X and Z outputs of the gyro to both be equal to VRef (1.23 V) which means their digital value should be about 2048*1.23/3.3 = 763. Your reading for Z at rest is pretty close to that, but your reading for X at rest is only 130. I would inspect the connection between the Wixel’s P0_2 and the Gyro’s X output and try to figure out what is going wrong. I would try measuring all the outputs of gyro with a multimeter while the Wixel is disconnected and while it is connected. You could try a different pin on the Wixel or try a different X output on the gyro.

How is everything wired together? How is everything powered? Is the gyro oriented correctly? (A picture would help us check some of these things.)

I plotted one part of your data and it looked like this:



Hi David,
Thanks for the response.
The Wixel is powered by USB, the gyro is powered from the Wixel 3.3 output and the Maestro is powered by 4 D cells with the jumper for VSR=VIN.

I ran four tests and two have a gap which I did not notice.
This could be the window terminal program capture issue my laptop is old and slow.
I have transitioned to Mac and have only older Win machines around.

The 130 value was a mistake I had the connector on the wrong pin.
So that was a disconnected pin I was reading as 130.
Photo I took shows this mistake it is corrected and now I am getting the expected value of 756.

The terminal program missing data and the cable on the wrong pin do not change the issue of the readings being not what I would expect.
I expect that as the servo is moving the gyro clockwise I should get relatively stable readings above resting and converse when moving counter clockwise. Instead I see values indicating that during the period while the servo is moving the gyro that it is moving rapidly clockwise then counter clock wise.
Or high values then low values when I expect all high values a pause then all low values a pause and repeat.
More like a square wave with a slow period.

As for coding issues on the Wixel. I posted the code. I do not see in code a reason for the data to be this way.
Some of the motions are completely lost, data is sent but it is near resting values when it should show movement.


I am attempting to post images saved on flickr.
at flickr.com/photos/softwaresp … 790941637/



In the code that you posted, you expect the X axis data from the gyro to be on ADC channel 2 and the Z axis to be on ADC channel 1, but your picture seems to show the X axis (green) going to P0_1 and the Z axis (yellow) going to P0_0, which correspond with ADC channels 1 and 0, respectively.

You mentioned correcting a connection, so maybe you have already fixed this. Just to be certain, though, are you sure the wires are connected to the channels you are actually reading from, and that you don’t have X and Z reversed? (Check that you are disabling the correct pull-ups as well.)

- Kevin


Thanks Kevin I should have been clearer.
I did have the connector at the Wixel on P0_0 and P0_1 this has been corrected.
Now the yellow wire is Z and connected to P0_1 and green wire is X and connected to P0_2.
The Ohm meter reads short from Gyro pins at the board to Wixel pins at the board with out USB connection for both X and Z pins. All pins and solder joints have been inspected and metered. I get 3.28v at the vin to gnd on the gyro.

I will run another set of tests tonight and post results.
When I first got the gyro I tested it on the Maestro with the gyro in my hand, using a different cable harness, just to move two servos based on gyro X and Z values as a crude quick test. While it did work it was not consistent. Not always moving the servo on gyro movement. I thought that it was the lack of code depth in the stack oriented Maestro and my project expects the gyro to communicate with the Wixel so I moved to the C platform and more complex code with diagnostics. This was when I confirmed something was not as per my expectation.

The mistake in the connection does not explain the difference between expected data and actual.
To recap the gyro is moving in a flat plane on the Z axis. Riding on top of a servo wheel that is controlled by the Maestro a simple script moves the servo at full speed to the right pauses 500 delay then to left pauses 500 delay and repeats.

How would the expected result from this test harness appear as a graph?

I am expecting something like the red line.

My crude timing estimate is less than one second to move and delay, we know the delay. I predicted that this standard servo at full speed would cover 3/4 of its range in less than 350 ms. The graph does suggest about about 300 ms of movement.



New Pic with the corrected cable connection.
Thanks Ben for the posting pics tip.



As you can see, GIF is a poor format for photos. It only allows 256 different colors. I recommend using JPG instead, as you have done on Flickr. For diagrams and charts, GIF is ok but PNG looks nicer because it is lossless. Also, I think you don’t need to post multiple sizes of the same photo; I was confused at first until I realized that’s what you had done.

Your latest pictures and explanation of your setup all look good. The red line you drew on the graph looks good. However, the blue line is incorrect because I made it based on data from your first post where you had the wiring wrong. (I think the blue line in that graph is actually the reading on the X axis, not the Z axis; I would expect to see random looking noise like that on the X axis but I’m not sure about the magnitude.)

Now that you have fixed your wiring, could you try again and post the new data? Please post readings from both the X and the Z axes. I don’t have Microsoft Excel; if you just post a CSV file that would be fine.

If the new data doesn’t look good, you could try taking the Wixel and Maestro out of the system and just measure the gyro outputs with a multimeter while turning the gyro with your hand. We have some general trouble-shooting tips in this post: Read Before You Post: General Advice for Getting Help.



Did some tuning on this old dos laptop but still cannot get a complete capture.
Terminal captures about two seconds of data then writes to the drive and losses about 3 seconds of data, before comping back from the disk I/O.
So all I can get is the cycle (pause, move, pause) of reliable data.
You are right the graph from before was only the noise on the X axis, which is very high.

Attached is the capture file from tonight as discussed it has gaps.

Here is the first two seconds of that data graphed, I adjust the time to make it easier to read the chart.
I do this by subtracting the start time from all time values.

I am going to move the testing to the Mac so I can have the power needed for better captures.
Next tests will be to add a second servo for tilt. Attach the Gyro to a pan and tilt platform controlled by the Maestro so we can see both axis in motion at the same time.


Great, I’m glad things are working better for you now.

The graph you posted looks pretty good. The Z axis data looks great. There is a lot of noise on the X axis, but it only happens while the servo is moving, so somehow the movement of the servo must be causing it. I think it’s most likely that your platform vibrates along the X axis while it is turning, but I can’t say for sure.

Were you going to do anything with the data from the X axis?



The project is head tracking to drive pan and tilt servos.
This will be applied to several applications.
A camera pan tilt controlled by head movement for AP in my RC aircraft.
A nerf turret with wireless video controlled by head tracker (requested by my 9 yr old buddy).
A head controlled mouse for disabled.
A talking head that is controlled by an actor (Halloween).

All will use both X and Z.
Currently I attempting to capture values during controlled movement (attached to servos) to give me an idea of how the data will look under different conditions.

I plan to start testing soon on both axis and at different speeds and travel distances.
Then from the data I hope to develop the algorithm that will translate the gyro data to actual position.


Those all sound like really cool projects. Let us know how they go!

A gyro would be good for detecting specific gestures (like when some turns their head suddenly clockwise), and that might be good enough for the Halloween project, but to accurately keep track of the head’s orientation of long periods of time I think you will also need an accelerometer and a compass.

We sell some sensors that might work for you but they are more expensive than what you’re working with now:

CHR-6dm Attitude and Heading Reference System
CHR-UM6 Orientation Sensor




Note that the sensors David linked to are more complete solutions. If you want to save money by implementing something yourself, you could consider using something like our LSM303DLH compass and accelerometer carrier to track the absolute orientation of the head.

- Ben


For 200.00 to 300.00 I can get plug and play solutions from the hobby industry.
Such as this one http://hobbywireless.com/cart/index.php?main_page=product_info&cPath=31&products_id=544
There are many gyros on the market for RC hobbies that can easily be adapted to head tracking.
But out of the box solutions do not always appeal to us DIY types that like to code and tinker with the electronics.
I am learning alot about gyros.


I have added the item to my next purchase wishlist.
I knew that I would need an accelerometer for the next steps.
I was not sure which sensitivity I needed in a gyro and thought I would buy one and start experimenting.
I am having fun and learning.
I am going to work on a low pass filter in code to remove noise.
Here is a data capture of Z motion at a speed of 30.

I mounted the test harness to a project box and weighed it down to minimize motion noise transfer to the non moving axis.



You may be interested in seeing my head panning demo using a RobotZone pan platform: