Open Source IMU designed for FIRST robotics

[slibert]

Originally Posted by Chadfrom308

I just bought an IMU from newegg (probably not a very good one because it was like $15, but its worth a shot). I was going to test the effect of the magnetic field of the motors vs the distance from the motors. Maybe you could test that?

Also, I was going to attach my IMU to an arduino and have it process it all there, then send the processed data via I2C to the CRIO. Im guessing this is just connected by serial to the CRIO? It wouldn't make sense to use up all the ports on the DSC for digital in.

What libraries are you including with it? Labview, C, Java? And what are the specs of the sensors? (+-3gs, +- 2000 degrees/sec)?

And last thing, does it compensate for temperature? I know that the gyro I tested drifted a whole lot, and when tuned, it would untune because the temperature effected it.

- We tested magnetic field disturbance of the NAV6 when robot was on, including at different distances from motors. As others have reported, we found that the motors running introduces significant interference to the magnetometer's ability to sense the earth's (weak) magnetic field.

However, as mentioned above, we did find the magnetometer useful for establishing absolute robot position before the motors turn on - at the beginning of the match.

Therefore, combined with the very low yaw (rotation) drift made possible by the Digital Motion Processing (DMP) it's possible to track the robot's position throughout the game.

- Yes, Nav6 is connected via RS-232 to the CRio. My personal belief is that this is a better solution, as I2C on a robot with lots of potential for electrical interference can be problematic.

- As noted above, the website at http://code.google.com/p/nav6 includes C++ code (which is based upon the WPI Library classes) to communicate with the firmware on the IMU. You should be able to adapt this to Java with relative ease, in my humble opinion.

- As to specs on the sensors, the datasheet for the MPU-6050 is available online. http://invensense.com/mems/gyro/docu...00A-00v3.4.pdf

Do note that this is a "system on a chip" that has multiple sensors in it plus the digital motion processing that does the heavy lifting to process the gyro/accelerometer data and turn it into something meaningful.

- Finally, as to temperature, this is an excellent question. The answer is "kind of". As noted above, we experienced a drift of approximately 1 degree (in the yaw, or rotation, dimension) when using the Digital Motion Processor's output.

The Digital Motion Processor (DMP) implements sophisticated algorithms (believed to be an Extended Kalman Filter) that fuse the accelerometer and gyroscope together.

Then, the DMP also implements calibration.

This calibration happens when you power the robot on, and takes about 8-10 seconds. During this time it calculates biases and gains to correct for manufacturing differences in the gyro and accelerometer sensors.

As to temperature changes, we've found the DMP algorithms are not significantly impacted by temperature changes during a match.

However, we are also looking into an enhanced version that also compensates for temperature changes by monitoring the on-chip temperature and storing/loading difference biases/gains on the fly into the DMP registers on-board the chip. We're not sure yet if this will really make much difference given the short duration of a FIRST robotics match, however.

- In summary, I'm hopeful that I"ve communicated the value of the on-board DMP processing of the MPU-6050 to offset some of the issues you mention. To my knowledge, the Invensense chips are the only ICs that have this feature, it's possible to do in software for sure and many have, but it's not simple to implement or to calibrate.

Put simply, the MPU-6050 is a different animal than most accelerometer or gyroscope ICs on the market. If you haven't looked into it previously, I think you might find it quite interesting and possibly compelling.

Cheers,

- scott