Three requests for next version of IMU/Depth module


#1

First of all, the MPU9150's I2C default address is 0x68 which it turns out is the same as the very common DS1307 clock and every other RTC I've looked at. Please change the address to 0x69 or at least break out AD0 to a solder jumper on the bottom.

Secondly, I have found that many (all?) of the more advanced libraries for using data from the IMU rely on the INT pin being broken out to signify that the FIFO buffer is full.

See http://playground.arduino.cc/Main/MPU-6050 (Note that the MPU6050 is just a six axis version of the MPU9150 used by the OpenROV device.)

and

https://github.com/jrowberg/i2cdevlib/tree/77a81085f6fdf22cdd924b8d1f9afb74338d4ee2/Arduino/MPU6050

I can get the raw data, but it looks tricky to turn it into something useful.

Finally, it would be great if Jeff Rowberg or someone else, could add the MS5803 to the list of devices supported by his i2cdevlib project.


#2

Hi Ryan:

The address of the MPU9150 on OpenROV is 0x69- for exactly the reason you stated- we want to keep the ability to add an RTC to the peripheral mix.

Right now there's an issue we're fighting, due to a defective run of IMU boards- The I2C address line was left floating, and some of the boards would come out as 68, and some as 69. Brian has made a patch for the next release of software that will look at both 68 and 69 for the IMU. This will keep the IMU working, but will prevent installation of an RTC if you have a board from this run.

The IMU boards that are shipping now have the issue fixed, and should be firmly attached to address 0x69.

With regards to the INT pin, that can be added on the next rev of the of the circuit board, but I suspect that won't be for many months. Also note that, for the current IMU, you'd have to bring the wire in through the endcap back to the Controller board for this to be useful.

If you're familiar with the MPU9150, please consider getting a GitHub account and submitting patches to the compass code. This code still has a lot of issues, but the few programmers we have right now are working on fixing other issues.

-W


#3

Walt,

Thanks for the reply. I got my IMU board not too long ago, but it seems to be a 0x68 version (IMUv.9) : (

I didn't notice the address conflict until I was having crazy things happen to my scheduler, which came down to the MPU9150 conflicting with the RTC's seconds register. That took a long time to figure out. I think I'm going to try the DS3234 RTC which has a built in crystal and is SPI so no address conflicts.

I'm 90% done on an arduino library for the MS5803 which works with the i2cdevlib.

The MPU library I'm using is the basic one form the i2ddevlib. There is a very in depth library which looks great, but it requires the INT pin. The basic library is working for me, but strangely, only when I turn on low level I2C debugging. Motion data is not very important to my application and so is kind of low priority for me. Unlike the 1000 other things due yesterday.

I just designed and ordered a SPI breakout board just for the MS5803. I want to pot it in some sort of threaded housing. With the mega I'm using, I can easily spare pins for SPI. Also, there's no need to stick the MPU9150 out in the salt water (even if well potted) so I can put it right on my shield.

Regards,

-Ryan


#4

Hi Ryan:

If you need the 0x68 address spot for your ROV, why don't you drop David an e-mail (info@openrov.com) and reference this forum thread. Maybe we can arrange a swap with one of the IMUs we have on our lab ROVs. We're not using RTCs on any of our ROVs, so there would be no conflict in the address space for us.

-W