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.

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!

Team 11 will pick up 2 at $70.

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

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.

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.

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?

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

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 [email protected]

Cheers,

  • scott

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

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?

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

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.

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.

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 ([email protected]).

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

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?

$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 Google Code Archive - Long-term storage for Google Code Project Hosting.. 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

If there are any questions you can contact me at [email protected].

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.

Order 37 processed today, TORC.

Scott.