Problem with IMU/Depth Module


#1

Hello,
I installed IMU / Depth sensor but MPU sensor is not working properly.
I get the error "mpu_init failed with code: -1"

MS5803-14BA Works perfectly! I get the temperature and pressure.

What could be wrong?

830-mpuerror.png (13.4 KB)

#2

It was solved after I entered "MPU.init (MPU_UPDATE_RATE, 10, 10, 40);" in MPU9150.cpp.

Now it works like a charm!


#3

Hi
I installed my IMU- unit, but do not understand completely, how to activate it. Is there a step by step guide for computer-dummys like me? I don’t know how to access the files I need to change.
Thanks for helping me!
Hub


#4

Hi Joakim,

I get the same error message "mpu_init failed with code: -1"

Whilst MS5803-14BA Works I get the temperature and pressure.

Could you kindly be describe a bit more in details how you proceeded to update the MPU9150.cpp and exactly what the syntax should be in the file.

I also notice that the compass line below states:

MPU.read();

navdata::HDGD = MPU.m_fusedEulerPose[VEC3_Z] * RAD_TO_DEGREE + 180; //need to confirm
Maybe this is the offset that needs to be changed in order to set the correct compass heading?

From viewing the file in github, I see that the current code in MPU9150.cpp goes like this;

Maybe you could insert in bold what you changed. Thanks!

---------------------------

#include "MPU9150.h"
#include "AConfig.h"
#if(HAS_MPU9150)
#include "Device.h"
#include "Settings.h"
#include <Wire.h>
//#include "I2Cdev.h"
#include "MPU9150Lib.h"
//#include "CalLib.h"
//#include "dmpKey.h"
//#include "dmpmap.h"
//#include "inv_mpu.h"
//#include "inv_mpu_dmp_motion_driver.h"
#include <EEPROM.h>
MPU9150Lib MPU; // the MPU object
// MPU_UPDATE_RATE defines the rate (in Hz) at which the MPU updates the sensor data and DMP output
#define MPU_UPDATE_RATE (10)
void MPU9150::device_setup(){
//Todo: Read calibration values from EPROM
Wire.begin();
MPU.selectDevice(1);
MPU.init(MPU_UPDATE_RATE); // start the MPU
Settings::capability_bitarray |= (1 COMPASS_CAPABLE);
Settings::capability_bitarray |= (1 ORIENTATION_CAPABLE);
}
void MPU9150::device_loop(Command command){
if (command.cmp("ccal")){
// Compass_Calibrate();
//Todo: Write calibrated values to EPROM
}
else if (command.cmp("i2cscan")){
// scan();
}
MPU.read();
navdata::HDGD = MPU.m_fusedEulerPose[VEC3_Z] * RAD_TO_DEGREE + 180; //need to confirm
navdata::PITC = MPU.m_fusedEulerPose[VEC3_X] * RAD_TO_DEGREE;
navdata::ROLL = MPU.m_fusedEulerPose[VEC3_Y] * RAD_TO_DEGREE;
navdata::YAW = MPU.m_fusedEulerPose[VEC3_Z] * RAD_TO_DEGREE;

#5

Hi Armand

You can try this file

https://github.com/covedesign/openrov-software/blob/master/arduino/...


#6

Thanks Joakim, will give it a go.

See there are some changes, hopefully that will do the trick!

#define MPU_UPDATE_RATE (10)
#define MAG_UPDATE_RATE (10)
#define MPU_MAG_MIX_GYRO_AND_MAG 10
#define MPU_LPF_RATE 40

#7

Installed the changes in the new MPU9150.cpp file, and now it works again, compass needs som calibration, but otherwise good to go. Thanks!


#8

I think the sensor i2c address was wrong and this was the fix for you.

This search for the address and set it.

int nDevices;
nDevices = 0;
Wire.begin();
Wire.beginTransmission(105);
if (Wire.endTransmission() == 0){
nDevices = 1;
}
MPU.selectDevice(nDevices);


#9

That May very well be. It worked for me. However, still experiencing some hang-ups during dives.


#10

Hi Joskim,

I too have an inop imu with working pressure/temperature. I tried your suggested file but it didn't help. Can you or anyone else give me some pointers on how best to proceed to debug the problem?

I.e. what errors should I look for and how do I access them.

PS... The heading is stationary at 180. All other angles are zero.


#11

Hi all, I also still was not able to get mine working, even after doing all the suggested changes.
I must say, that I am rather disappointed, that there ist still no stable version of software for the 2.5 board that includes the IMU- software. I have modified my Rov mechanically and am quite satisfied with that, but still have a lot of issues with the software, such as hangups and video lags. I would appreciate, if the makers of Openrov could put more effort in the software instead of selling new units.
Hub


#12

Hey Hub (et al),

I'm sorry you're having such trouble with this. So far, we've relied on the open-source community to help get software up to speed (we don't currently have any software people who work at OpenROV) and it's gone a lot slower then we'd like that way. We're trying very hard to get some more help with software, and we're also working on creating a new software image that will address some of the bugs you've described. When we started this, I thought that software would be the easiest thing to get help with from other OpenROV developers in the community, but it turns out that hardware design improvements have been able to be realized much more rapidly.

As for the inop-IMU-but-working-pressure/temp issue, we just made a discovery last week that there was a manufacturing error with all of the IMU boards we sent out which caused the I2C address to float rather then be pinned to a specific address. The IMU in these boards works, but it gets confused about what I2C address (68 or 69) to send the data too. In the next release of software that I mentioned, we've written a patch that scans for which address the IMU is talking on and uses that. My hope is that when this software comes out, it will fix the problem you guys are having.

Sorry once again about the challenges you have been having with this hardware. We're figuring a lot of this stuff out as we go, and we hope people understand the challenges we face in getting everything to work just right.

If you would like to set up a call or Google Hangout, I can try to help that way too. Email me at eric@openrov.com if you'd like to set that up.

Okay, hang in there and let me know if there is anything else I can do to help in the mean time!

Eric


#13

Thanks for the update Eric. From what I can tell, the address issue was supposedly fixed by the code snippit that Joakim spoke about above.

I.e. from MPU9150Lib.h

// selectDevice() can be called to select a device:

//
// 0 = device at address 0x68 (default)
// 1 = device at address 0x69
//
// selectDevice() must be called before init()

So the snippit finds the right nDevices to select the address

nDevices = 0 corresponds to address 68

nDevices = 1 corresponds to address 69

So there may be something else going on with Hub and I since we implemented the "fix".

Look forward to more info.


#14

The snippet that was put in place only works in one direction, the issue is that the IMU address selector is floating, so the detect logic has to be wired to flip back again to the original address. We have another update of fixed code floating around that I will reference when find it.


#15

Ok... BTW When I ran this snippit (ref):

Wire.begin();

Wire.beginTransmission(105);
if (Wire.endTransmission() == 0){
nDevices = 1;
}
MPU.selectDevice(nDevices);
Serial.print("MPU Found at ");
Serial.print(nDevices);
Serial.println(";");
nDevices found by the code was 0 (address 68). Then I forced it to use 1 (address 69) and neither case worked. So are you saying that there can be other addresses?
Also, where would I find the output from Serial.print?

#16

Hi All,

I have edited and saved MPU9150.cpp to match https://github.com/covedesign/openrov-software/blob/master/arduino/OpenROV/MPU9150.cpp, and kept the navdata as follows:

navdata::HDGD = MPU.m_fusedEulerPose[VEC3_Z] * RAD_TO_DEGREE;

navdata::PITC = MPU.m_fusedEulerPose[VEC3_X] * RAD_TO_DEGREE;

navdata::ROLL = MPU.m_fusedEulerPose[VEC3_Y] * RAD_TO_DEGREE;

navdata::YAW = MPU.m_fusedEulerPose[VEC3_Z] * RAD_TO_DEGREE;

Then I uploaded the Arduino Firmware using the button in the cockpit web interface (under the settings menu, apply new firmware...)

The IMU values displayed, after hitting the compass calibration button (under the diagnostics menu), with the ROV aligned with TRUE North, are:

pitc -173.50

roll 0.55

yaw -44.09


I decided to calibrate the heading by changing the code in MPU9150.cpp to:

navdata::HDGD = MPU.m_fusedEulerPose[VEC3_Z] * RAD_TO_DEGREE;

navdata::PITC = MPU.m_fusedEulerPose[VEC3_X] * RAD_TO_DEGREE;

navdata::ROLL = MPU.m_fusedEulerPose[VEC3_Y] * RAD_TO_DEGREE;

navdata::YAW = MPU.m_fusedEulerPose[VEC3_Z] * RAD_TO_DEGREE + 44;

Again I have to upload the Arduino Firmware.

Now, the IMU values displayed, after hitting the compass calibration button (under the diagnostics menu), with the ROV aligned with TRUE North, are:

pitc -173.84

roll 0.56

yaw -7.85

I don't know what goes wrong here, the yaw value should be closer to zero.

Further more, when I operate the thrusters, the IMU values change to:

pitc -30.24

roll 83.91

yaw 149.88

Hitting the compass calibration button changes the IMU values back for as long as the thrusters are not controlled.

Please share your views on this and/or how you calibrated your IMU values.

Thanks,

Remy


IMU Calibration (compass and tilt)
#17

Hi Remy,

We have disabled the magnetometer function of the IMU in our more recent software releases due to difficulty in calibrating and using the compass. This is still a work in progress we hope to re-enable in the future. In the meantime, we recommend running in gyro-compass only mode which holds a relative reference of North depending on which way it is facing when it is turned on.

The calibration button was added but not hooked up to the MPU9150 code in most of the releases that we have had as a result. Sorry for the confusion.

The code you are referencing is older code that has some bugs in it regarding translation of the values from the MPU-9150 library which has pitch and roll reversed.

If anyone else in the community has managed to get the code working better, by all means let us know!


#18

Hello Brian,

Thanks for your reply.

I found a more recent MPU9150 code, https://raw.githubusercontent.com/OpenROV/openrov-software-arduino/master/OpenROV/MPU9150.cpp

Could I copy this code with the below changes to run in gyro-compass only mode?

#define MPU_MAG_MIX_GYRO_ONLY 0 // just use gyro yaw
// #define MPU_MAG_MIX_MAG_ONLY 1 // just use magnetometer and no gyro yaw
// #define MPU_MAG_MIX_GYRO_AND_MAG 10 // a good mix value
// #define MPU_MAG_MIX_GYRO_AND_SOME_MAG 50 // mainly gyros with a bit of mag correction

I will try updating to a more recent software release in due time, but don't want to experiment with this just yet. I will demo the ROV to a group of secondary school kids after the New Year and preferably use a quick fix to the MPU9150 code.

Cheers, and happy holidays,

Remy


#19

hi Brian,

i struggled a lot with this in the past.

So, did i understand it right now:

i have to face my ROV i.e. the IMU direction North by starting it up in order to make the compass calibrate itself?

In my few dives up to now i experienced the compass feature is very important.

Sometimes it was laggy or even not working and i then was completely lost.

Tobias


#20

Hey Tobias,

If you are using a 2.5.0 or a 2.5.1 image of the software then yes, if you want N to point to North you have to start the ROV while it is pointed North. It is fairly trivial to change the calibrate button so that you can set North after powerup, but I am not aware of anyone making the change in code yet.

The compass lag is something that will be addressed in the 2.5.2 release. Initial tests seemed to show that we need to increase the sampling rate to counter some of the noise canceling the IMU hardware is doing. If you are comfortable in the code, changing the sample rate we are using from 20 hertz to 50 hertz is where I would start.

-Brian