Show Posts
Pages: [1]
1  Products / Arduino Due / Re: avr/prgspace error problem on: February 01, 2013, 06:41:51 pm
Success! Has anyone else been able to get things running smoothly?

I'm curious about the range of values people are getting from their sensors. When using Jeff's MPU6050_DMP6 sketch with "#define OUTPUT_READABLE_WORLDACCEL" uncommented, what do your resting values trend to?

As I understand it, these should all approach zero after perhaps 30 seconds however I get a weird response from my z-axis. Its value hovers around 3500 when placed undisturbed on the table (positive z up). It appears to have some offset to it as it doesn't tend to zero when the orientation is changed such that z is parallel with the table surface.

Is this something others are also experiencing?
2  Products / Arduino Due / Re: avr/prgspace error problem on: February 01, 2013, 04:43:10 pm
Oh wow I feel retarded. I never even noticed there were two sets of I2C pins and was using the two by AREF and GND. Apparently the Due has two I2C interfaces.

Perhaps I should trade my Due back in haha, its obviously too smart for me.

I'll try that library for the MPU-6050 later this evening hopefully and let you all know if my hack job at porting it over was successful at all.

Thanks for your help!
3  Products / Arduino Due / Re: avr/prgspace error problem on: February 01, 2013, 02:20:32 pm
So nobody has had any issues communicating over I2C? I'm having trouble getting any response using the I2C scanner but everything works just peachy using my UNO with the same connections.
4  Products / Arduino Due / Re: avr/prgspace error problem on: January 30, 2013, 02:48:08 pm
I'm also experiencing the same issue. I'll admit I'm over my head here for the most part although I was able to successfully able to implement SomeRandomGuy's improvement to address some of the issues.

I also added "#define prog_uchar uint8_t" before the "#endif" to address the "error: invalid conversion from 'const char*' to 'const uint8_t*'" errors.

It now seems to compile however I am unable to establish I2C communications with the IMU and I2CScanner ( is not recognizing it at all. Another user is also having this problem here

Have you had any luck?

EDIT: Oh, and I also commented out all the 'F' flags in the MPU6050_DMP6 sketch in the "Serial.println(F("example text"));" commands because of the error "error: 'PSTR' was not declared in this scope".
5  Using Arduino / Sensors / Re: MPU-6050 Z-axis on: January 04, 2013, 06:24:01 pm
I bought another for a sideline project that I have and it also exhibits the same behaviour which is not encouraging.

When the z is placed horizontally it reads ~3600-4200 (little change from when z is directly up) while the x and z both tend to zero after being agitated.
6  Using Arduino / Sensors / Re: MPU-6050 Z-axis on: December 08, 2012, 07:19:52 pm
Did you manage to make any progress?
7  Using Arduino / Sensors / Re: MPU-6050 Z-axis on: November 23, 2012, 12:07:20 am
Thanks for your response. I'm sorry to hear you are also having the same problem. Did you try Krodal's code that I mentioned too? How modified is your code? When I run the sketch the time interval is approximately 1ms between readings (at the default sampling rate).

Your modification to the sampling rate appears to be correct from what I can tell, however I had not ventured that far yet. The time interval between your readings indicates a 50 Hz sampling rate though, am I right?

 50 Hz = 1second / ~20 milliseconds (0.02 seconds)

So either your extra code is running too slowly and the buffer overflows before it is read again, causing the FIFO overflow, or you had the sampling rate set to something else when you recorded that output.

Does the sampling time make sense if you use setRate(99) (do you get 100 ms between samples)? The datasheet says that 4 Hz is the minimum.

I'm by no means a coding wiz but if you were unable to read the buffer in a timely manner you could check the size of the buffer and if it exceeded 1024. If so, reset it (using 'mpu.resetFIFO()') then return to the beginning of the loop without analyzing anything to read the next sample. Highly inefficient but it's an idea.
8  Using Arduino / Sensors / MPU-6050 Z-axis on: November 19, 2012, 10:56:26 pm
Hi all, glad to finally register! I would like to begin with a little background to let you know where I'm coming from.

I purchased the Sparkfun MPU-6050 breakout board a while back to use on a quadcopter which got sidelined as the school year progressed. Recently however, a school project caused me to turn to it with a new use in mind. I would like mount it to a vehicle and measure its acceleration. Using this information, I intend to integrate this into velocity after running it through a simple filter. I am aware that the output will drift with time however this is only for short term applications and I begin with a reference so it shouldn't pose any problems.

I initially tried Jeff Rowberg's libraries on GitHub and got them running smoothly (thanks Jeff for the teapot demo - made me crack a huge grin!). As I played with the different outputs however I began noticing an issue.

The vehicle in question is a tractor configured for a pulling competition . I am attempting to measure its wheel slip as it travels in a straight line down the course. I am measuring the angular velocity of the drive wheels using a hall effect sensor. This will be compared with the ground speed of the vehicle. This scenario rules out other ground speed measurements such as GPS (indoor track), radar/optical methods (the vehicle catwalks at times - also ruling out another hall sensor on the front wheels), and a trailing spring-loaded wheel (uneven ground with abrupt transverse shocks require a robust system). See below for an example (not my team but you get the idea).

I run into issues when I start looking at data output options as seen below (from MPU6050_DMP6 -


    // display initial world-frame acceleration, adjusted to remove gravity
    // and rotated based on known orientation from quaternion
    mpu.dmpGetQuaternion(&q, fifoBuffer);
    mpu.dmpGetAccel(&aa, fifoBuffer);
    mpu.dmpGetGravity(&gravity, &q);
    mpu.dmpGetLinearAccel(&aaReal, &aa, &gravity);
    mpu.dmpGetLinearAccelInWorld(&aaWorld, &aaReal, &q);

The following is what I have come to understand about the underlying processes used to generate this output. I have spent a lot of time reading through Jeff's libraries and have experimented with a number of different outputs (linear acceleration and gravity vector).

  • the attitude (as a quaternion) and the linear acceleration are combined to calculate the gravity vector
  • this is then scaled and subtracted from the linear acceleration to output acceleration solely due to motion
  • the linear acceleration along each of the axes are then rotated into the world reference frame (with gravity down)

I interpreted this from lines 533-633 of MPU6050_6Axis_MotionApps20.h found at

The first indication I had that something might be out of the ordinary was that upon running MPU6050_DMP6 when configured to output readable world acceleration, both the x and y axes converged to zero after initial start-up (15 second), but the z-axis remain at a fairly constant output of ~2400. When I invert the accelerometer so that the z-axis is pointing downwards it reads ~6000, leading me to believe that it is not correctly calibrating when it starts. See below for sample output with the z-axis pointing upwards.

aworld -3 8 2452
aworld -3 4 2458
aworld 1 2 2463
aworld 3 2 2453
aworld 9 4 2454
aworld 7 2 2451
aworld 10 0 2448
aworld 11 -3 2447
aworld 11 -1 2445
aworld 5 2 2447
aworld 0 -2 2445
aworld -2 0 2442

I modified the sketch (using the attached sketch) so that it displays linear acceleration. Experimenting with the x and y axes produced an output which ranged from approximately +-7500 to 8000 and they appeared similarly aligned with the physical axes of the sensor, however the z-axis ranged from +6400 to -10200 (not equally distributed).

I then changed the output to display the gravity vector's x, y, and z components. When I oriented the sensor so that the x-axis go to zero (horizontal to the ground), the sensor appears flat as you would expect. Likewise with the y-axis. With the z-axis however, the board is inclined approximately 15 degrees from vertical, leading me to conclude that something is awry. I repeated the test again using the linear acceleration output and arrive at the same conclusion (this is not a problem with how the gravity vector is determined).

I then repeated the tests with Krodal's sketch ( and arrived at the same conclusion, ruling out incorrect code.

My questions are:
  • can someone in possession of an MPU-6050 please run Jeff's MPU6050_DMP6 sketch and please tell me if all their axes converge to zero as the sensor calibrates itself?
  • if you print the gravity vector (see code below) and move the chip so that each of the axes go to zero, does it look to be in close agreement with what you'd expect (physical x,y, and z axes printed on the breakout board)? My z-axis appears to be ~15 degrees out of alignment.

I have attached the sketch that I used to diagnose my problem.

Sorry if my explanation omitted any detail you require. Let me know and I'll get back to you as soon as possible. I'm interested to hear all of your responses!

Pages: [1]