View Single Post
  #14   Spotlight this post!  
Unread 10-12-2013, 21:09
slibert slibert is offline
Software Mentor
AKA: Scott Libert
FRC #2465 (Kauaibots)
Team Role: Mentor
 
Join Date: Oct 2011
Rookie Year: 2005
Location: Kauai, Hawaii
Posts: 343
slibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud of
Re: Open Source IMU designed for FIRST robotics

Quote:
Originally Posted by Joe Ross View Post
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