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.
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.
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".
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.
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).
#ifdef OUTPUT_READABLE_WORLDACCEL // 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); Serial.print("aworld\t"); Serial.print(aaWorld.x); Serial.print("\t"); Serial.print(aaWorld.y); Serial.print("\t"); Serial.println(aaWorld.z); #endif
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)
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.
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).
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!