Problems about the IMU Module v2


#1

i looked the code of Arduino source code version 30.0.3,in the file CMS5803_XX.cpp,it says “This library only works with the MS5803-14BA model sensor”.but in the IMU Module v2,the Schematic sees to be MS5837_30BA.i want to DIY the IMU Module v2,So i want to ask is it ok for the code or the Schematic?


#2

That is a mistakenly left in comment. There are a couple of patches applied to the code which change it to work with the 30BA, but I didn’t think about the header comments when I was working on that. That said, there are still some mysteriously occasional bad values that are reported by the sensor now and then, though it is fairly accurate 99% of the time. We’ll be conducting testing to see if we can track down the source of the random odd value bug.


#3

Thank you very much .I have just pilot my ROV,but have no IMU Module.in my country,it is hard to find the MS5837-30BA,so i want to change it to MS5803-14BA,is it working right for the Arduino Code?And another question is why we change the IMU MPU9150 to BNO055?is it the best for ROV?Do we need both of them?


#4

Shouldn’t be a problem. If you can wait a little while, I can explicitly break up the code for the two sensors. That code is worth revisiting anyway, to see if we can weed out the weirdness. If you want to get it in yourself, check out Luke Miller’s repo:

DISCLAIMER: In his code, he uses Wire.h. In the current branch of the software, we use the I2C Master library (CI2C.h/cpp). The two libraries cannot be used at the same time, so all of the Wire calls need to be changed to the appropriate CI2C calls. See our MS5803_XX code for examples.

He also has repos for the other variations as well. As far as the IMUs go, the BNO055 is somewhat more reliable, comes in an all in one package, and has a nice auto-calibration feature, among a few others. You can use either, or both, though there isn’t any code written to nicely utilize two at the same time yet.


#5

Hi, recently i am considering to combine the MPU9150 and MS5803 as a modeul and I am confused about configure the address and the call for i2c to avoid the conflict in I2C BUS. In which part of the code that i can do the configuration. I am a green hand in electronic stuff and hopefully my question is not so sily.


#6

Also, in the opensource part I can only find the schematic of the IMU/DEPTH V2, where can i get a copy of schematic of V1 ?
thanks


#7

That was an oversight on our part. We will work on getting the files up.


#8

Here is a link to the file.

Make sure to read the description and the addressing pin that is tied to ground. It is not represented in the schematic.


#9

Hi,Brian
Thanks so much for the source
So basically, the original code has the mpu9150.cpp and MS5803.cpp part, does it mean that the IMU/DEPTH part can work once it is attached to the DB25 or should i do some configuration of the timer or address in the original code ?
Thanks


#10

This version has a resistor added to address it in hardware to a set address.


#11

Both of them can use,the only thing you have to pay attention is the device address,so if you want to DIY you own IMU module,you have to look up to you chip datasheet.actully,i have completed my IMU module,using BNO055 and MS5837-14BA,it worked well.so the first thing you have to do is looking up to BNO055 datasheet and MSxxx,if you want to use MPU9150,you have also to do this ,in datasheet you can find what the pins mean,and you can choose the chip I2C address,then you can design your own schematic refers to the datasheet.i have not change any source code .that means you can design your schematic’s chips I2C address as same as the source code.


#12

Hi Brian[quote=“Brian_Grau, post:8, topic:3771”]
Make sure to read the description and the addressing pin that is tied to ground. It is not represented in the schematic.
[/quote]

Do you mean that the AD0 of the mpu9150 should tied to ground ?


#13

Yes, it should not be left floating.


#14

i am little bit confused recently. the “deap” in the cockpit does shows the accurate depth but it sometimes will jump to over 100 and then goes back to the right value. What might be the cause ?


#15

@Golden That is a result of a bug in the firmware for the depth sensor. It has been fixed in the latest version of the software. That version isn’t ready for release yet, but you can grab the code and update just that part yourself if you are feeling adventurous. It’s the 30.0.5 branch on openrov-software-arduino github repo. The correct code is now in the MS5837 files, not the MS5803 files.