Is it possible to obtain the gravity component of acceleration from the LSM303DLHC. I successfully interfaced the gyro thats on the MinIMU-9 board but after reading the datasheet for the accelerometer, I suspect this might not be possible. Am I right??
BTW, I am trying to build a balance robot using a complimentary filter. The complementary filter requires that I get the low frequency component of gravity.
Thanks in advance.
As Einstein famously stated, it is impossible to separate the acceleration due to the Earth’s attraction on an object (gravity) from any other component of the total acceleration experienced by the object.
If you have not already, I suggest looking at our MinIMU-9 + Arduino AHRS program, which demonstrates how to combine the output of the three sensors on the IMU to calculate its orientation. Another customer has made a similar program using a different algorithm as well.
The algorithms used by these programs approximate the direction of gravity with the acceleration vector, using it as a reference to correct for gyro drift in the pitch and roll directions, which sounds like what you are trying to do. However, to prevent non-gravitational acceleration from skewing the calculated orientation too much, the MinIMU9AHRS program weights the correction so that it is weaker the farther the magnitude of the acceleration vector is from 1 g. Similarly, it appears the Pololu_Open_IMU program only performs the correction if the acceleration magnitude is between 0.5 and 1.5 g.
Thanks Kevin. I actually got it to work. The 2’s compliment and the 12 bit value was the culprit.
Sorry to take over someone else’s thread, but I have a question related to the topic. I’ve been able to get the MinIMU-9 v2 working with my Baby Orangutan and the Python GUI. The output looks pretty neat and makes for a fun demo. My kids liked it.
What I’ve noticed is that the roll, pitch, and yaw seem to be in reference to the orientation of the IMU’s startup position and not to the down of gravity. I verified this by restarting the robot in different orientations and it always displays the orientation on the screen as flat and level and then correctly tracks motion relative to this.
For a balance bot you want to use the down of gravity to set the initial orientation, and then track how far of the robot is drifting to apply correction via the wheels. I suppose I could turn the robot on in the upright position, but unless I was really accurate balance might be compromised.
Any pointers to the place in the code to tweak in order to set the initial orientation?
The MinIMU-9 + Arduino AHRS program was designed so that you have to have the board in a level position at startup. It uses that assumption at the beginning and takes some readings of the Gyro and Accelerometer in order to calculate offsets for each. To modify the code to not behave that way, you would have to study how the AN_OFFSET array is used, and modify the code in the setup() function of MinIMU9AHRS.ino that sets AN_OFFSET. Basically you don’t want to pay any attention to the accelerometer readings at startup because they could be anything, and the components of the AN_OFFSET array that represent the accelerometers offset should probably be zero. However, you will need to study the code to make sure.
Have you calibrated your magnetometer by running the Calibrate example in the LSM303 library and then inputting those numbers into the AHRS sketch?
David, thanks for the pointer to the calibration program. I haven’t done that yet and will.
I will study that section of code you pointed to and try to understand the initialization. I’m a bit rusty on some of the mathematics involved, but I’m sure I can figure it out eventually with a Google search and some reading.
What I might do is initially focus on learning to use the accelerometer on a stationary robot to try and determine where down is via the acceleration of gravity. Parallax’s dual access accelerometer is fairly easy to use in this mode, so understanding that is likely the place to start. I could then use the AHRS program to determine the dynamically changing orientation of the robot.
This IMU seems pretty useful on any sort of robot, not just a balance bot. If you couple it with dead reckoning via wheel encoders you can zero out the accumulated error in your heading. For an all terrain bot you can use it to avoid climbing steep inclines as well.