Open Source IMU designed for FIRST robotics
 

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)

Re: Open Source IMU designed for FIRST robotics
 

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.

Re: Open Source IMU designed for FIRST robotics
 

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?

Re: Open Source IMU designed for FIRST robotics
 

- 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

Re: Open Source IMU designed for FIRST robotics
 

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?

Re: Open Source IMU designed for FIRST robotics
 

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

Re: Open Source IMU designed for FIRST robotics
 

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?

Re: Open Source IMU designed for FIRST robotics
 

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

Re: Open Source IMU designed for FIRST robotics
 

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

Re: Open Source IMU designed for FIRST robotics
 

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.

Re: Open Source IMU designed for FIRST robotics
 

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.

Re: Open Source IMU designed for FIRST robotics
 

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.

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.

Re: Open Source IMU designed for FIRST robotics
 

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?

Re: Open Source IMU designed for FIRST robotics
 

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

Re: Open Source IMU designed for FIRST robotics
 

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

Re: Open Source IMU designed for FIRST robotics
 

First-these wheels can slip and skid on stuff like the key/bump in 2012.
Second-two wheels each with two encoders on them weighs more than a pcb
Third-it's way easier to find the current heading of the robot using acceleromters and gyros. The math to figure out what the robot is doing is actually pretty tough. It can be very difficult to determine rotation of the robot vs. the robot traveling sideways.

Re: Open Source IMU designed for FIRST robotics
 

I'd buy one at $70.

Re: Open Source IMU designed for FIRST robotics
 

I'm a big fan of the eevblog. He's got some videos on design for manufacture (and panelizing)

DFM (Part 1): http://www.youtube.com/watch?v=VXE_dh38HjU
DFM (Part 2): http://www.youtube.com/watch?v=Uemr8xaxcw0
DFM (Testing): http://www.youtube.com/watch?v=2zGisPMNstI

Re: Open Source IMU designed for FIRST robotics
 

For 2015 could we get NI to loose that Accelerometer on the roborio and and put a mpu6150 in there? They do have advanced drivers available.

Re: Open Source IMU designed for FIRST robotics
 

I'm pretty sure the accelerometer is built in. But there is this space front and center that exposes the other half of the I/O capabilities, I2C, UART, and SPI via the MXP connector (the link calls it the Custom Electronics Port). I'm not sure which name is official.

What little is published is here.

This also keeps it modular.

Greg McKaskle

Re: Open Source IMU designed for FIRST robotics
 

Invensense has a driver for most operating systems. The driver includes an advanced algorithm for magnetometer. This company does not support hacker community. NI could most likely get them to assist in modifying the driver for our use. A mpu-9150 could be added to the roborio and with the driver provide a high level API for robot orientation. Having a Mag on board is probably not the best for our use. A mpu 6150 with an off board mag is probably the best solution. To make full use of the invensense excellent low cost orientation solution will require a big company to work with them. NI can do this if they are interested. Until then the Rowe and Pansenti code will have to do. The only other option for the full Motion apps code is TI. They have a board and library using these chips. To do any work with the boards requires a couple hundred dollar investment in a compiler. TI is making one of their Launch Pad boards available. However, It is not the one with the Invensense chip. TI is the other company that could make a wraped up a solution for FIRST.

Re: Open Source IMU designed for FIRST robotics
 

No, There are 4 sensors (L3G4200D ADXL345 HMC5883L BMP085) and there is not much of a description on them. It is pretty much of a gamble for me. If it works, then great. If not, then it was only $12 so it is what it is at that point. Similar sensors on sparkfun are $50 to $100.

http://goo.gl/9OdtSo
This is the link to newegg (Shortened so it's not a mile long)

It gives me the information over i2c and I am not sure if it has a Digital Motion Processor (which is why I was going to have my arduino process it and then send it to the CRIO)

Anyways, I get it today, so when I get home, I will play with it and tell you how it goes.


As for the IMU You guys designed, I would definitely buy it for $70. Would I need it? Probably not, but it is nice to have, especially when trying to drive straight or aim a turret and have it set to a position. Would these be available to buy by the beginning of the season or at the latest, 2 weeks in? If so, sign me up!

Re: Open Source IMU designed for FIRST robotics
 

Team 11 will pick up 2 at $70.

Re: Open Source IMU designed for FIRST robotics
 

Nice job! Thanks for making your project open source and releasing to the community :D

On the topic of surface mount soldering, it's is not very difficult when done via reflow at home for $20-$50. You probably still want some experience, though.

$10 for a toaster oven at a thrift store
$20 for a multimeter with thermocouple
$20 for solder paste in syringe

Results here (this is a first try). Also, note the larger of the two chips, while not perfectly square with the pads, was completing the circuit properly (we later reworked this chip).

The hard part is gauging how much solder paste to apply - we used a tooth pick to apply paste, but did apply a little too much the first time. We later applied smaller amounts with great success.

Additionally, we did not use a programmable temperature control. Rather, we found three temperature settings on the oven and changed the temperature dial according to the time in the solder paste spec sheet.

Re: Open Source IMU designed for FIRST robotics
 

The problem with home surface mount soldering is the imprecise temperature control. This is a mems device and very sensitive to stress on the package. Invensense has a very specific temperature profile for these chips. They are calibrated at the factory. Mounting stress will make these calibration values way off. Too much stress and the chip will not perform with in spec at all. In the dmp initialization the factory calibration values are read off chip, some registers are set and memory locations initialized then the factory calibration values are read back in. The Pansenti code provides a method of using user calibrated values instead of the factory ones. I have two break out boards and with the sparkfun the values are way off. The china board is very close. I believe this is soldering difference.

Re: Open Source IMU designed for FIRST robotics
 

I'd be happy to look into spinning this design to integrate into the new RoboRIO expansion connector. We'd need to get ahold of one of the Beta RoboRIOs though so it could be ready for 2015. Does that sound interesting to you?

Re: Open Source IMU designed for FIRST robotics
 

Add me to the list of interested parties for the completed unit.

Re: Open Source IMU designed for FIRST robotics
 

Great, thanks.

A production order for the nav6 IMU has been sent out; I'll keep you posted on when they'll be available. If you know of anyone else who's interested, please have them contact me at scott@kauailabs.com

Cheers,

- scott

Re: Open Source IMU designed for FIRST robotics
 

Have you looked at the CPU utilization of reading the serial port at 100hz?

Re: Open Source IMU designed for FIRST robotics
 

The nav6 continually streams the updates, so the CRio just listens and doesn't have to send any requests. The update packets are terminated with a line feed, and as I understand it the FPGA receives and buffers serial characters until the termination character is received, then the buffer is made available to the processor. So in principle this is pretty efficient. The remaining work is parsing the values into the yaw/pitch/roll/heading angles.

I don't have detailed performance metrics for this, but anecdotally we ran a prototype of this w/the same protocol in our C++ robot last year. The robot software was also servicing 4 bit-banged Avagotech absolute angle sensors to track our swerve drive steering angles, and read out angles from each of these at 50Hz. Our checks showed the total CPU load was roughly 50%. So my best guess, needs to be verified, is no more than 10% CPU on a VxWorks robot for receiving/decoding the updates.

All that said, do you think it's worth adding a configuration option to decimate the update rate?

Re: Open Source IMU designed for FIRST robotics
 

I think if you are using 10% of the cpu to keep receiving updates is a lot. I think 50Hz will be fine for pretty much anything.

My team wants to take 2 of them. But the only thing stopping me from getting them is that there is no labview code for them. I could to hook it up to an arduino and use i2c, but thats a lot of work and adds a little lag to it. The reason why we wanted to use one is because we tried gyros and they dont work or require a lot of tuning and drift a lot, so we thought it would just be easier to read the rates from this IMU, but if I have to try to work labview into it, we might have to just stick with tuning a gyro

If you can get labview code out, I will buy two

Re: Open Source IMU designed for FIRST robotics
 

cRio RS232 is done by NI VISA and does not involve the FPGA. As we (33) already do a lot of at 100hz I don't imagine RS232 adding much to it. I imagine the RS232 port is a hardware UART on the PowerPC but am not entirely sure.

Re: Open Source IMU designed for FIRST robotics
 

In order to allow any team concerned about the 100Hz update rate to choose a slower update rate, a simple option to modify the update rate (between 4 and 100Hz) has been added. This should allow anyone concerned about CPU utilization the option to make the trade off between CPU usage vs. response time.

Once we get concrete measurements on CPU usage, we'll make that information available, too.

Re: Open Source IMU designed for FIRST robotics
 

We're working on locating a partner willing to develop a LabView VI for the nav6. When that happens, I'll be sure to let you know.

We will provide a free nav6 IMU and cables ($95 value) to whomever is first to step up and agree to develop and test a LabView VI for it - as long as they're willing to allow us to make that LabView VI available to others, and to allow us to modify it to include the nav6 'advanced' modes of operation. If you know of anyone interested, please have them contact me (scott@kauailabs.com).

Re: Open Source IMU designed for FIRST robotics
 

We too are strongly considering a gyroscope "package" addition to our robot for the same reason as noted in later post: "Absolute" / persistent directionality. In that vein:
1) Have you put together that package you noted above?
2) If so, do you have a link to "high level" specifics?
3) What was the final price?
4) How do we place the order (direct or via the AndyMark website)?
5) How long after the order is placed will it be before we receive the kit?

Thanks

Re: Open Source IMU designed for FIRST robotics
 

An alternative to the Nav6 board is this "Flight controller" for $35.

I believe your code would be a straight drop in, although a minor tweak may be needed.
It has a slightly better controller (AtMega2560), same IMU6050 and HMC5883L integrated on the board already.

Thoughts?

Re: Open Source IMU designed for FIRST robotics
 

$35 is an impressive price, and I believe may be below the part costs for the ICs that are specified, which I estimate to be about $40 (at quantity 100). The Atmega2560 and the MS5611 barometer on the MultiWiiPro2 add about $10 beyond the component costs of the nav6. It cost us $35/each to get 100 nav6 board assembled in china, including the components. My best guess is the MultiWiiPro2 is being sold at cost and the vendor will make up the difference by selling other quadrocopter components (motors, servos, etc.).

Here's some thoughts on how take the various open source parts of nav6 and approach porting them to this board, and getting it running on a FRC robot:

- Based on the MultiWiiPro2 Atmega2560, MPU6050 and the HMC5883L, the nav6 open source firmware should run on this flight controller - as long as each IC''s interrupt line is connected to the Atmega microcontroller. The I2C addresses might be different, based upon the schematic.

I haven't found the schematics, but if you do find them, keep an eye out for the interrupt lines. The MultiWiiPro2 code I found supports many different gyros/accels, and doesn't appear to utilize the MPU6050's DMP (which requires interrupts to tell the microcontroller when the next chunk of filtered pose data [quaternions] and sensor data is available).

- Based on the MultiWiiPro2 code (I haven't been able to locate the schematics), serial communications is supported. I didn't see a RS-232 transceiver listed on the specs, so a different approach than interfacing to the CRio serial port, or some external circuitry for that, might be required. I did see that there's a header for I2C, so if you were to add I2C slave code, and this I2C bus was separate from the I2C bus used to communicate w/the onboard sensors, this could be an option.

- I'm not sure what kind of voltage regulation the MultiWii2 has onboard. It appears (from looking at the silkscreen of the board from photos I've found) to require require 5VDC; for nav6 we found it simplest to handle a range from 6 to 14VDC, so that the IMU can be powered directly from an unregulated output from the FRC Power Distribution Board.

- So in summary, and assuming you'd use I2C to interface to it, I believe you'd need to (a) ensure the MPU6050/HMC5883 interrupts are available to the processor, (b) adapt the nav6 firmware to add a I2C slave interface, (c) adapt the nav6 serial protocol to be command/request over the I2C bus and (d) power the board from the Digital sidecar. I recommend reviewing the digital sidecar bandwidth (CRio<-> sidecar) to ensure it's sufficient to transfer the IMU data at the update rates you want.

It's a key part of the nav6 mission to enable students to modify the firmware, circuitry, interface software, and enclosure of the nav6. All of this is available at http://code.google.com/p/nav6. So if you decide to port the nav6 firmware to this board, please let me know if there's anything I can do to help.

Aloha,

- scott

Re: Open Source IMU designed for FIRST robotics
 

- The nav6 is now for sale, for $69.99 plus shipping, at www.kauailabs.com/store.
- Full documentation, and source code for firmware, board schematics, bill of materials, and STL files to 3d-print an enclosure are on the wiki, at http://code.google.com/p/nav6.
- We will ship out the nav6 board the day after we receive the order.

If there are any questions you can contact me at scott@kauailabs.com.

Re: Open Source IMU designed for FIRST robotics
 

Thanks to all who have volunteered for this; I'm happy to report that a volunteer LabView library development effort is beginning, and we're expecting a beta to be available in approximately 4-5 weeks. I'll send out updates as things progress.

Re: Open Source IMU designed for FIRST robotics
 

Order 37 processed today, TORC.

Scott.

Re: Open Source IMU designed for FIRST robotics
 

The nav6 LabView VI library is available now, and an example LabView application that uses the library. Many thanks to our volunteer! Some documentation is currently being developed as well, and will be posted when it's ready. More details are on the nav6 wiki.

Re: Open Source IMU designed for FIRST robotics
 

Did anyone use a Nav6 in competition? What were your thoughts?

Re: Open Source IMU designed for FIRST robotics
 

We did not use an IMU in competition yet but the testing we did do last summer indicated that with a game like this years game with the heavy defense and high G impacts would have yielded less than acceptable field centric control. IMU's that are perfect for our needs are out of our price range.

Re: Open Source IMU designed for FIRST robotics
 

We're trying to match the features of sophisticated IMUs w/the Nav6. Specifically in this case of accuracy in the face of high impact events, the Nav6 combines the ability to configure the accelerometers at up to +/- 16 Gs (so they don't saturate during an impact), together with the kalman filtering which fuses the triaxial accelerometer data with the triaxial gyro data, and the high rate at which the fusion occurs (approaches taken by IMUs costing over $100 currently).

So, I'm curious what IMUs you do think are perfect for your needs, or more specifically what specifications you're shooting for. The Nav6 goal is teleop Field-oriented drive for any team that wants it, without requiring "zeroing the yaw" during the game.

Thanks for any input you may have,

- scott

Re: Open Source IMU designed for FIRST robotics
 

This nav6 thread was recently "found" by some of my students who are interested in giving this guy a shot. However, I'm concerned about its compatibility with the new roboRIO controller. Does the RS232 on the nav6 require any pins other than the RXD and TXD pins - these are the only 2 RS232 pins available on the roboRIO (other than a ground reference).

Thanks!
-Danny

Re: Open Source IMU designed for FIRST robotics
 

There will be two ways to interface the Nav6 w/the RoboRio:

- USB: using a RS-232 to USB adapter cable
- RS-232: using RX, TX signals and ground

As you noted, the RoboRio will have 3 pins for RS-232: RX, TX and ground. We're working on getting cables made for sale at the kauailabs store that we plan to have for sale before the 2015 season starts, but making a cable is pretty straightforward.

Also note that in *both* cases, you need to also provide separate power/ground. The nav6 has onboard voltage regulation, and you can feed unregulated voltage (6-16V DC) to it. The wiring will be similar to the typical CRio configuration, with the nav6 wired directly to the power distribution board.

If you'd like, checkout the Nav6 schematics, too. You can view them with Eagle PCB, which is a free download.

You may note on the nav6 schematic the DTR signal is also present on the RS-232 connector, however this signal is not required and is used only to support downloading new firmware to the nav6 from the Arduino IDE running on a PC. The DTR signal is *not* needed to communicate with the CRio or the RoboRio.

Finally, on the software side, we will be qualifying the C++, Java and Labview code w/the 2015 FRC libraries when they are available. FIRST has stated that the existing library interfaces (the nav6 uses the serial port) will be maintained, so it *should* just work :). But of course that will need to be tested and that's a top priority for us - as soon as we get ahold of the RoboRio and the libraries.

Re: Open Source IMU designed for FIRST robotics
 

The way the DTR pin worked on the cRIO caused issues. In that respect, the limited pins may be a benefit. See https://nav6.googlecode.com/svn/trun...orkarounds.pdf Based on my testing, it only affected the 8 slot cRIO.