Cockpit software 2.5rc2


#1

I just uploaded the latest cockpit software. The cockpit worked rightaway, I had only to try a couple of times to upload the arduino. Now everything seeems to work fine!
Thank you so much Brian, for all the work you do!!!
I can’t wait to do my first dive with the new software. Just have to find out, how to calibrate the compass. It seems to work, but is not always pointing to north. Probably my fault.
Hub


#2

Hi Hub,

In the current release, I have the mag disabled. So you get relative orientation from the gyros + accelerometer but not correction for compass. Walt has a work around, to simply power up the ROV while it faces North and the gyros do an impressive job of holding that heading. There is slight drift, but not that you would really notice during a normal dive.

The reason the mag has been disabled is

1) that we have to finalize the correction to the reference frames used by the different sensors so that the 9-axis fusion of data works correctly.

2) that we ensure we have the right instructions for how to move the ROV around during calibration.

That said, we welcome help from anyone that wants to take some time dialing it in! If you want to enable the magnetometer it is only 2 line change in the firmware:

https://github.com/OpenROV/openrov-software/blob/v2.5.0-rc1/arduino...

https://github.com/OpenROV/openrov-software/blob/v2.5.0-rc1/arduino...

There is an orientation matrix in the MPU library: https://github.com/OpenROV/openrov-software/blob/v2.5.0-rc1/arduino.... The default orientation, has the IMU positioned sideways to the body of the ROV, which is not how we have been mounting them to date. If you do mount the IMU any way except the default, you will have to modify the code to also rotate the mag raw data before the 9-axis fusion. That should take place here: https://github.com/OpenROV/openrov-software/blob/v2.5.0-rc1/arduino.... You just need to multiply the calibrated mag vector by the same rotation matrix used by the gyro.

I think our preference (and a ton of thank to Walt for spending the day dialing in a lot of this!), is to change the code to have a new standard mounting orientation with the vents of the IMU towards the front of the vehicle and facing down. That is a roll of 180 degrees and yaw of -90 from the default orientation of the code. So the rotation matrix should be:

[ 0, -1, 0

-1, 0, 0

0, 0, -1 ]

I have all of this in BETA code right now with the intent of releasing it in a couple weeks as it all gets dialed in.

So, to finally answer your question! When you click the calibration button, the compass on the display in the background will jump to 359 and start to tick down towards 0. That is how you know you are in calibration mode. While that takes place you need to rotate the ROV around so that it can sense all of the high and low mag measurements around it. I had thought you basically needed to rotate in all directions along all axis, but I've still been getting "odd" zones in the compass when doing it that way. This calibration technique needs a little more work.

Finally, and I will add this to the errant list, once you correct orientation and dial in everything else, the yaw and pitch end up being swapped in the current code: https://github.com/OpenROV/openrov-software/blob/v2.5.0-rc1/arduino.... Pitch should be using the Y portion of the Euler vector.

Good luck to anyone that wants to work on dialing this in, and please be sure to share with the community!

-Brian


#3

Hi Hubertus:

In this software drop, we have the magnetometer part of the compass turned off by default- it works only as a gyrocompass.

If you align the ROV with north when you boot it up, it will read correctly. It will very slowly drift away, as there is no magnetometer to update the gyro.

We should have more to say about the compass next week.

-W


#4

Hi All:

Here's my summary of the coordinate system stuff that Brian mentioned above.

This software release (as well as all the previous ones as well) had messed up coordinate axes for the IMU, since we didn't really understand how the chip and its software library were oriented. Although the MPU-9150 datasheet is clear that the accel/gyro and the magnetometer have different coordinate systems, it turns out that the MPU9150Lib library has yet a third coordinate system. What a mess!

So we figured all this out, and then came up with a standardized way of defining and mounting things:

1.) We're assuming that the IMU is mounted upside-down (vents down), and with the vents forward and the wires aft.

2.) The ROV coordinate axes are defined as follows: X= Roll, Y=pitch, Z=yaw (heading). This matches the (forward, right wing, down) coordinate system that is used in aircraft and in inertial navigation systems.

3.) To get the IMU axes to conform to (1) and (2) above, you need to make two code changes in Arduino. These changes will be included in the next build:

a.) In the file MPU9150.cpp, at the very end (lines 222 and 223 I believe), edit the lines so that PITC is coming from [VEC3_Y] and ROLL is coming from [VEC3_X]

b.) In the file MPU9150Lib.cpp, edit the gyro_orientation matrix (Line 78?) to be the following:

[ 0, -1, 0

-1, 0, 0

0, 0, -1 ]

After you do these steps, reload the Arduino code. The behavior of the pitch and roll axes of the IMU, and the behavior of the head-up display (HUD), should now be correct.

-W


#5

Tracking roll/pitch swapped bug here: https://github.com/OpenROV/openrov-software/issues/234


#6

Hi Brian

I have been playing around a little bit trying to figure out how to tweak the Roll & Pitch to zero them out because my sensor is not perfectly aligned.

Is there an offset in the MPU9150lib.cpp file that I can do this.


#7

In theory, the right way to do this would be to set the ROV level and then infer the right rotation matrix needed to zero all of the current values and then use that as the new rotation matrix. That is important as it feeds the orientation in to the 6-axis fusion on the DMP in the 9150.

You might also be able to find a way to set some bias settings that "zero" the reading that come from the IMU before they are fed out. You could hook the MPU9150.cpp file's device_loop with a new command just like the calibration command and inside of that you can manage any biasing that needs to take place. You could then apply the biases to the outputs at the bottom of the file before the values go out.

Does that help?

-Brian