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 - i2cdevlib/Arduino/MPU6050 at master · jrowberg/i2cdevlib · GitHub):
#define OUTPUT_READABLE_WORLDACCEL
#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)
I interpreted this from lines 533-633 of MPU6050_6Axis_MotionApps20.h found at i2cdevlib/Arduino/MPU6050 at master · jrowberg/i2cdevlib · GitHub.
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 (Arduino Playground - MPU-6050) 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!
MPU6050_DMP6_DIAGNOSIS.ino (3.62 KB)