Open Source IMU designed for FIRST robotics

[magnets]

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!

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.

[MrRoboSteve]

I'd buy one at $70.

[Michael Hill]

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

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

[Gdeaver]

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.

[Greg McKaskle]

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

[Gdeaver]

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.

[Chadfrom308]

Originally Posted by gpetilli

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?

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!

[wmarshall11]

Team 11 will pick up 2 at $70.

[protoserge]

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

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.

[Gdeaver]

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.

[slibert]

Originally Posted by Gdeaver

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.

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?

[tr6scott]

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

[slibert]

Originally Posted by wmarshall11

Team 11 will pick up 2 at $70.

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

[Joe Ross]

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

[slibert]

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?