BorgCube ROV

Had chance to stick the ROV in the tank and work out the final ballast. For neutral buoyancy the total extra weight was 3 lb & 3 oz (1.42kg in proper money). Here's the final beastie sitting just under the surface, happy as you like.

The various pieces of ballast arrived. The scuba weights I ordered were uncoated lead; it was cheap. But because I don't feel entirely okay with having exposed lead around (it's toxic after all) I coated all the weights with Rust-Oleum enamel paint. Below you can see the clear-coated weights. I've attached the main 3 lbs but wont be able to dial in the exact ballast until early next week.

Back in the tank today to work out how much extra weight I need to achieve neutral buoyancy. I bought a few 1 pound scuba weights so I could quickly approximate what's needed. Popping the ROV in the tub and then putting these on it, I found I need between 3 lbs (it just floats) and 4 lbs (it just sinks) to achieve neutral buoyancy. I'll buy some finer, more permanent, weights so I can dial it in and zip tie them to the frame.

There is a long documented bug on all version of the Raspberry Pi (including the new v3 apparently) whereby the I2C bus doesn't work to spec. For those that don't know, the I2C bus supports the notion of "clock stretching" which allows either the master of slave device to slow down communications if one end cannot keep up. Most I2C devices don't use this because they can keep up just fine, but the BNO055 device does use clock stretching, and the Raspberry Pi doesn't deal with this well.

The upshot of this in my ROV is that sometimes I get bad data from the IMU. This bad data appears to manifest itself in two ways: 1 - I just get back 0's; and 2 - the last bit of a 16-bit read is set to 1 when it should be 0. Unfortunately, for whatever reason, immediately re-reading the data doesn't usually result in a good data; which makes me think the BNO055 is busy internal and can't talk properly right now ... but who really knows.

In an ideal world I'd come up with a solution to make the I2C bus work correctly on the Raspberry Pi, but until that happens I need to deal with this error infested data. My first plan had been to simply discard these bad readings. Fortunately they're easy to spot because a reading of all 0's for pitch, heading and roll is very unlikely to occur, and the high-bit being set will put the radian value larger than 2*pi. Unfortunately these errors occur often enough that I end up with large gaps in the data stream, which won't make balancing the ROV easy.

At least when working in radians, the device only needs to return 14-bits worth of signed data for roll, pitch and heading. After some experimenting it appears that the Raspberry Pi can at least get this much data before any errors occur. If I just use these 14-bits, the data stream is almost perfect (the random sets of 0's still occur, but are infrequent enough to be ignored).

Still, I'd rather have the Raspberry Pi run the I2C protocol correctly. Fingers crossed they fix this one day; but I'm not hopeful.

Today I added an additional IMU to the front of the ROV. I'm not yet sure whether having two means I get a better average idea of what's going on, or whether the mis-quote "man with one IMU knows which way is up, man with two IMUs never sure" will apply.

The second IMU is just one I bought from Adafruit and is mounted in the forward tube on the same support structure for the camera. Electrically and magnetically it's in a very different place. It sits on the I2C bus using its the alternative address.

Today's other lesson is that you can't just average angles and expect to get the right thing. For example, if you do a simple arithmetic average of 359 and 1, you get 180 when the actual angle you were hoping for is 0. A quick bit of wiki-reading and it turns out that to average angles you should do it using vectors (see https://en.wikipedia.org/wiki/Mean_of_circular_quantities), which the code now does.

A functioning IMU is essential to the BorgCube because I intend to use it to maintain the craft's balance. However, the IMU I'm using will often loose calibration at unexpected moments. Oddly this is particularly prone to happen when I turn on the lights! Looking over my PCB design, the 12V track which powers the lights passes within 10mm of the IMU. I haven't seen any design notes from Bosch regarding device placement, but it seems that this is too close.

More experimentation is required, but I intend a place an addition IMU in the forward capsule containing the cameras. We'll see how they do working together.

So here is it, the fully assembled robot in a tub of water. As you can see from the pictures, it floats, which is not what we want. I will need to get and add some weight to fix this (not sure how much). But, besides this, everything checks out and all the electrical work!

Behold! I have run out of excuses - below is the fully assembled BorgCube ROV. Tomorrow I will put it in the water and see if it sinks or swims - bother figuratively and literally. Fingers crossed.

Pictured below is the new battery container. The original one was made from a 2 inch tube from Blue Robotics. The new one is a 3 inch tube from Blue Robotics. The batteries barely fit into the old tube, and once various other bits of connecting hardware were added, the fit became tighter than I was comfortable with - hence the new tube. Otherwise it's functionally equivalent.

Put the fully assembled ROV on the scale today and it weights in at 20lbs. Not sure what I was expecting. By far the heaviest pieces are the batteries, aluminum endcaps, and the potted ESCs. Will do a fully assembled immersion test latest this week and, if it still floats like it did last time, I will have to increase the weight to make it neutrally buoyant.