Open Source IMU designed for FIRST robotics

[slibert]

Team 2465 (Kauaibots) has completed initial development of the Nav6 Open source IMU. This project includes:

- Open source hardware (Eagle PCB file, Bill of Materials)
- Open source hardware (Arduino-compatible source code)
- Software to integrate the IMU into a C++-based CRio robot project

The "nav6" inertial measurement unit (IMU) was developed to provide sophisticated inertial navigation capabilities easily available to student robotics teams, including the FIRST Robotics Challenge (FRC). This low-cost circuit board enables a 4-wheel omni-directional drive robot to be driven in "field-oriented" drive mode by accurately measuring the robots "pose" - the amount of tip, tilt and rotation - relative to the field. Additionally, the nav6 can be used to implement robot balancing algorithms.

The nav6 features the powerful Invensense MPU-6050 IC which includes a 3-axis accelerometer, a 3-axis gyroscope and an on-chip digital motion processor. The nav6 employs sophisticated motion processing algorithms provided by the "Digital Motion Processor" (DMP) included with the MPU-6050. The result: highly accurate tip/tilt, and accurate yaw that exhibits minimal drift of approximately 1 degree per minute. The sensor provides a 200Hz update rate, excellent for use in robotic systems.

The nav6 also includes a Honeywell HMC5883L 3-axis magnetometer. Although the magnetometer compass readings are unreliable when robot motors are energized, it is useful for establishing absolute orientation at the beginning of a competition. Combined with the nav6 "pose" and this initial orientation, a robot's absolute orientation throughout a competition match can be maintained.

The nav6 has been designed specifically to enable easy integration into a FRC robotics control system: it's power connection connects directly to an unregulated 12V output on the Power Distribution Board and it's data connection connects directly to the cRio serial port. Additionally, source code for easy integration into the FRC cRio controller is also provided.

As an added bonus, the nav6 is Arduino-compatible, and can be re-programmed by anyone via the free Arduino Integrated Development Environment (IDE).

Links to the open source hardware/software project, and the CRio software to interface with this IMU, are at: https://code.google.com/p/nav6/

Advanced soldering skills are required if you want to build it, but I'd be happy to indicate where you can get the board fabricated and provide some guidance on how assemble it with a minimum of tools. I'm also open to having some assembled for a low cost if there's enough interest.

As an alternative, it should also be possible to adapt the firmware to run on open-source boards w/the MPU-6050 and the HMC5883L, these can be found at Sparkfun. The ArduIMU +V3 (https://www.sparkfun.com/products/11055) is $79.95 and features almost identical ICs, however it doesn't have the on-board RS-232 IC/connector so you'd need to take care of that detail.

If you have any questions, please let me know.

Cheers,

- scott

Scott Libert
Control System Mentor
Team 2464 (Kauaibots)

[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.

[gpetilli]

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 purchased a $15 9DOF IMU on ebay. It is a GY-85 and it has a single I2C interface for all three sensors, which we connected to the DSC. It does not have a processor, but we have implemented Java code on the cRIO for all three sensors. Is the IMU on newegg also a GY-85?

[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

[otherguy]

Looks pretty nice. Congrats on completing the design and thanks for making your work available to the community.

Does your team plan on selling these boards?
If so at what price range, and would you consider selling it as a kit (bare PCB + components) to reduce cost?

[Deetman]

Giving a rough estimate using two PCB fabrication houses I am familiar with:

BOM Cost = $24.98 (no quantity price breaks)
PCB Cost = $33 (Qty 1)
         = $3.4375 each (Qty 32)
Assembly = Student learning experience! (Free)

TOTAL = $57.98 or $28.42

[slibert]

Originally Posted by otherguy

Looks pretty nice. Congrats on completing the design and thanks for making your work available to the community.

Does your team plan on selling these boards?
If so at what price range, and would you consider selling it as a kit (bare PCB + components) to reduce cost?

Thanks! It's been quite a journey....

I've got two thoughts on the assembly/cost:

1) I've got a quote for fully-assembled units for about $35 each at a quantity of 100. I'm willing to front the money for this, but want to make sure there's enough interest out there for it.

There would still be additional cost on top of that for boxing/shipping (est. $7).

In exchange for the support we'd also be giving to people, I think a fair return would be a markup that would be a fundraiser for the team.

So to me this means a price somewhere around $70 ea, fully assembled and shipped. That's a lower price than similar units on Sparkfun, and it'd include the code and RS-232 IC to simplify integration w/the CRio.

If we couldn't get demand for 100 units, that'd cause the price to go up a bit.

2) Your idea for a kit is interesting. Here's the challenge I see: surface-mount soldering skills are required. Two of the ICs (the MPU-6050, and the Honeywell Magnetometer) are Quad-Flat-No-lead and this can be very challenging. There are no through-hole variants for these ICs available on the market.

Now, we could redesign the board to make most of the parts through-hole thus requiring a lower soldering skill, but that would mean a month of redesign, and even so some there'd still need to be some assembly by a third party for the through-hole parts.

Could you give me an idea of the soldering skill and the cost per board that makes sense to you?

[Michael Hill]

Originally Posted by slibert

Thanks! It's been quite a journey....

I've got two thoughts on the assembly/cost:

1) I've got a quote for fully-assembled units for about $35 each at a quantity of 100. I'm willing to front the money for this, but want to make sure there's enough interest out there for it.

There would still be additional cost on top of that for boxing/shipping (est. $7).

In exchange for the support we'd also be giving to people, I think a fair return would be a markup that would be a fundraiser for the team.

So to me this means a price somewhere around $70 ea, fully assembled and shipped. That's a lower price than similar units on Sparkfun, and it'd include the code and RS-232 IC to simplify integration w/the CRio.

If we couldn't get demand for 100 units, that'd cause the price to go up a bit.

2) Your idea for a kit is interesting. Here's the challenge I see: surface-mount soldering skills are required. Two of the ICs (the MPU-6050, and the Honeywell Magnetometer) are Quad-Flat-No-lead and this can be very challenging. There are no through-hole variants for these ICs available on the market.

Now, we could redesign the board to make most of the parts through-hole thus requiring a lower soldering skill, but that would mean a month of redesign, and even so some there'd still need to be some assembly by a third party for the through-hole parts.

Could you give me an idea of the soldering skill and the cost per board that makes sense to you?

I'd say just keep it all surface mount for pick & place. How many can you throw on a panel?

[slibert]

Originally Posted by Michael Hill

I'd say just keep it all surface mount for pick & place. How many can you throw on a panel?

Honestly, I'm not sure about panelization. I've only had them fabricated individually in the past.

Board dimensions are 2.5x1.9

In case it's helpful, I've attached the quote for fab/assembly of 100 units. Parts are provided by the assembly company to lessen overall shipping costs.

Note that this is for a variant we're working on that uses the single MPU-9150 IC rather than the separate MPU-6050 and HMC5883L ICs that are on the Nav 6. But the dimensions and overall quote should be the same.

- scott

[magnets]

Originally Posted by slibert

Thanks! It's been quite a journey....

I've got two thoughts on the assembly/cost:

1) I've got a quote for fully-assembled units for about $35 each at a quantity of 100. I'm willing to front the money for this, but want to make sure there's enough interest out there for it.

There would still be additional cost on top of that for boxing/shipping (est. $7).

In exchange for the support we'd also be giving to people, I think a fair return would be a markup that would be a fundraiser for the team.

So to me this means a price somewhere around $70 ea, fully assembled and shipped. That's a lower price than similar units on Sparkfun, and it'd include the code and RS-232 IC to simplify integration w/the CRio.

If we couldn't get demand for 100 units, that'd cause the price to go up a bit.

2) Your idea for a kit is interesting. Here's the challenge I see: surface-mount soldering skills are required. Two of the ICs (the MPU-6050, and the Honeywell Magnetometer) are Quad-Flat-No-lead and this can be very challenging. There are no through-hole variants for these ICs available on the market.

Now, we could redesign the board to make most of the parts through-hole thus requiring a lower soldering skill, but that would mean a month of redesign, and even so some there'd still need to be some assembly by a third party for the through-hole parts.

Could you give me an idea of the soldering skill and the cost per board that makes sense to you?

I'd recommend not selling them as kits. Surface mount parts (especially the QFN ones) are pretty tough to solder. This is actually really cool, and I'm pretty certain that there will be teams willing to pay more for a fully assembled board that they can easily interface with the cRIO. The compatibility and support that teams will be able to get with this will make it really cool.

[mman1506]

Originally Posted by slibert

Honestly, I'm not sure about panelization. I've only had them fabricated individually in the past.

Board dimensions are 2.5x1.9

In case it's helpful, I've attached the quote for fab/assembly of 100 units. Parts are provided by the assembly company to lessen overall shipping costs.

Note that this is for a variant we're working on that uses the single MPU-9150 IC rather than the separate MPU-6050 and HMC5883L ICs that are on the Nav 6. But the dimensions and overall quote should be the same.

- scott

You might want to keep the HMC5883L and put it on a optional separate board (mouse bites/tabs). I know the ArduCopter project uses those ICs with that method so they can move it to a spot away from the motors and ESC's (The top of your robot for example) with a large reduction in EMI.

[otherguy]

Originally Posted by slibert

Thanks! It's been quite a journey....
So to me this means a price somewhere around $70 ea, fully assembled and shipped.

I think $70 shipped is a fair price. We would be in for one at that cost.
That said, unless we NEED an IMU to play this years game (unlikely), it's unlikely this board would be put to use on the 2014 robot. It will likely be put off until the off-season for further investigation.

Your idea for a kit is interesting. Here's the challenge I see: surface-mount soldering skills are required.

I realize the surface mount components won't make sense for a lot of teams. My main reason for asking was simply to bring the price down a bit. I believe our team could populate this board in house. I've worked surface mount components by hand numerous times, but would likely temporarily set up a reflow oven/hot plate for this one to make things a little easier on us. I wouldn't recommend redesigning the board this close to the season starting, especially if you plan on trying to sell these in support of the 2014 season.

[Joe Ross]

Originally Posted by slibert

- 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.

Did Invensense finally publically release a description of the DMP and interface specs, or are you using what other people reverse engineered a while ago?

[slibert]

Originally Posted by Joe Ross

Did Invensense finally publically release a description of the DMP and interface specs, or are you using what other people reverse engineered a while ago?

Joe, this is a great question.

The current Nav6 software version we've made available includes the I2CDev library version of the Invensense code that was reverse-engineered by Jeff Rowberg.

However, Invensense released about a year ago source code for a driver that improved that situation. This is referred to as the Embedded Motion Driver, version 5.1. This 5.1 driver no longer requires the "reverse engineered" approach that is utilized in the current code that we use in the Nav6, which is at http://code.google.com/p/nav6.

The Motion Driver v. 5.1 has been ported to the Arduino and am currently testing it, it appears to work. I even asked Invensense if they wanted the arduino-compatible code, but they declined, likely they didn't want to have the support burden.

Note that this Invensense-provided source code does not fully document the DMP registers, but it does provide a vendor-supported way (including source code) to use the MPU-6050/MPU-9150 without requiring any reverse engineering. And there's definite clues as the DMP registers and their use that can be derived from the source code.

Invensense has another library (the MotionApps library) that so far I haven't been able to talk them into giving me the source code for, it's only distributed as a binary and not for the ATMEGA platform.

Moving forward with Nav6, the plan is to provide an update that uses the Motion Driver v 5.1, as well as hopefully some enhanced calibration code, and release that code open-source. However, given the limited RAM on the Atmega328 that's on the Nav6, the current challenge is to get it all to fit along with the code the implements the protocol to communicate with the cRio.

Since we've found the reverse-engineered code works well for our needs, for now we're using the older reverse-engineered code.

Cheers,

- scott

[slibert]

Originally Posted by yash101

I don't see why we use gyros and accelerometers! Just have two free-wheeling castors with two encoders (one speed, the other rotation) on each. That should report where you are, even if you are pushed around!

The main reason we developed Nav6 was that we wanted field-oriented drive capabilities for the two omnidirectional drive systems (Mecanum, and Crab) we have developed. In field-oriented drive, when the driver moves the joystick forward, the robot goes forward (relative to the driver / the field, not relative to the current orientation of the robot).

This allows us to get more students involved in the driving without requiring them to have the somewhat advanced skill of "putting their head in the robot" while driving.

There are some other capabilities an IMU can provide (like measuring tip/tilt so you can balance the robot like in the 2012 game) as well.

But for sure you can build a great robot without an IMU.

Cheers,

- scott