Multibeam T500 rov build for wreck and reef surveys

Build/Make DIY ROVs
1

Hi there.

We are trying to put together a T500 rov. We just threw ourselves in and ordered the parts we thought we’d have use of together with a complete BlueROV2 to make acquaintance with the architecture and to use on inspection jobs.

We are a company supporting the foundation VOTO, Voice of the ocean who wants to:

  1. Support science.
  2. Visualize the past.
  3. Create engagement.

It is all about the sea, have a look at: https://voiceoftheocean.org/. VOTO shares a lot of high-resolution oceanographic data for all scientists to take part of and might support your research in other areas. Recently involved with an unmanned sail drone project in Hudson Bay.

Back to the vehicle, it is to be custom made to carry a relatively big echosounder our R2 Sonic 2024 (+16kg) and a SprintNAV mini. Positioning will be from HiPap.

The frame machined out of PP plastic is in the making and should arrive shortly.

AssemblyRev5 v8
AssemblyRev5 v81920×1068 91.7 KB

It is also planned for a fibre mux to be able to handle the data and run on a thin tether.

We intend to go for two battery pods containing two batteries each like the Mega battery. Pods will still be light in water and are stacked in the top.

Its not a vehicle made for pipeline survey but smaller grids of work like shipwrecks or reefs. Possibly it could be refitted/ rebuilt for photo, photogrammetry or film later.

The best would be if the batteries could be connected into one big battery, thinking of making a power hub where batteries join and the ESC:s are housed and then thrusters connect to. Possibly moving the Pie in together with the mux.

The first idea was to use a 400mm 4" bottle and just change out the 200-ESCs, but even if we removed the dome and added another flange for connectors, yea I’m not sure. Maybe better to move the Pie and just run a cable with signals to the ESCs.

Another idea is to put (four and four) ESCs with the batteries. Its not as straight forward of how to (evenly) supply the rest of the vehicle with power then.

Its not going to be a perfectly executed plan, but the intension is to get a prototype up and running. A home made ROV built on T200s (top side powered though) managed to pull of a survey with this MBES last year.

I have a lot of questions. I am trying not to spend too much time on issues like heat dissipation or tether entanglement around the trusters just yet. No, it can’t even sit on deck like that, but staying slick would not create unnecessary drag, it can sit in a crib. Plenty of space to manufacture buoyancy in the top.

It is hard to dimensioning things out. Cabling can’t be dimensioned for running all thrusters at full speed simultaneously (43x8 Amps). The initial idea was to use 500s for their efficiency. Verts just running on idle while on site just to maintain depth. Probably could have gone with just two 500s or four T200, still can. Thrusters should be able to limit in the software, add fuses to that.

It would be preferable to seize up in dimension battery cables going to a power hub, I haven’t found any good connectors for more than 50 Amps. To hardwire one cable with two conductors through a gland would save some end cap space. I am all ears for solutions and parts.

Robin Claesson - Midocean

2

Is there a reason that your using a 2024 vs a lighter MB like a Norbit IWbms or Winghead depending on your resolution requirements. Just a thought. Looks like a cool project.

3

We hope that we could interpret the multispectral backscatter if I’ve understood things right. So we could possibly look at other things in the returns than just seabed or not. If the data could be interpreted so one could find a certain coral in the signature for example. I am no expert in this MBES.

4

We built it.

Sensors are up and running. I think we managed to get the SprintNav to be navigational sensor for the vehicle as well. The top frame is getting new and more pieces to make it stronger. But it is fine as it is for lifting in calm conditions.

Battery pods got heavier than planned with additional components. So yes it feels top heavy. More lead, more bouancy or a complete frame re-design, we will see.

It seem to fly reasonable in the tank, but we need more water. Waiting for some boat time.

Yea it can’t sit by its own on the floor, it needs a cradle. I wanted a slim construction with as little drag as possible. You wouldn’t really put this vehicle on the seabed with down trim anyways.

Tether is 3,5 or 4,6mm fiber optic from Linden. The idea is still a “patch tether” of like 40-60 metres to a poor mans TMS, the bullit of our survey winch which has got an fiberoptic interface…

20260113_081308
20260113_0813081920×1081 465 KB

20260113_081258
20260113_0812581920×1081 498 KB

5

Hi @IntoTheBlue -
Chiming in here rather than the dual batteries thread on your power approach.

If you’ve co-located the ESCs with the batteries in your two side enclosures, then the high current has a nice short, “dry” path from the batteries to the ESCs, and you only need 1 ground and signal wires for each ESC connected to the flight controller in your center housing. You could have a single set of power wires making your two pods batteries be in parallel - only small currents would flow down this cable, if any at all, caused by thrusters on one half working harder than the opposite - as those batteries voltage went lower, a bit of current from the other side would be sourced. Does that make sense?
The center enclosure, if only the flight controller, INS and communications won’t pull much power - you could connect it to either battery pod, and “balance” current would come to that sides batteries via the paralleling cable.

A very cool ROV! Best of luck

6

Thanks for showing interest!

Yes the co-location off batteries, ESCs and thruster outputs gathered saved me from finding high current cables out in the water. Now I can stick to original cables.

We did have it like that during one early test dive. I paralleled them through a big resistor for leveling out differencies before connecting them. I was of course easy on the stick.

But what if some cells on one side fails? Wouldn’t the draw want to travel “the longer way” then?

No the center enclosure should have like a maximum of 100W with echosounder, gyro, Pi, lights, camera etc. There are some losses of DC/DC regulators and such.

Now we are trying to tweak parameters making it fly as its best. All ears for similar set up threads.

Thanks.

7

Hi @IntoTheBlue
I’m a bit confused on the resistor- it’s better to charge the batteries to full to equalize.
It’s highly unusual for cells to fail, and would likely only occur if over-discharged or dead-shorted?

8

I can not say that I know too well what I am doing, so I am thinking better safe than sorry and try to be careful. At the moment we do not parallel the two battery pods, they run separate circuits with a common ground.

And so far, discharge level in between the bottles have been very similar.

9

There have been progress, some stars aligned.

Proper tests has been comenced.

My idea was that this was going to be more of a building thread, but here we are, as built instead.

We have a project planned for some PhD students in a few weeks, I hope that we can have a platform that can have a chance to deliver some bathy for them.

(Take note of the little speed craft under the sub, mil spec ops! =))

20260324_151530
20260324_1515301920×1081 362 KB

We have been out to a common calibration spot trying to achieve a patch test for the MBES. This we are doing while trying to set up the vehicle for the first time, I am just saying…

In the navigational screen, the blue bathy is old data as a picture as a background the more green yellow data is fresh out from what our vehicle has covered. The orange box is the calibration target. The white figure the boat. ROV symbol, small and black.

HiPap for USBL.

20260327_124838
20260327_1248381920×1081 523 KB

Unfortunately a very shallow spot, just 20 metres and we ran with 7 metres altitude, small margins, very stressful. I didn’t want to make the sub heavy these first dives either.

The sub behaved quite well at times but usually degraded in performance over time, at least it was how it felt.

We have the SprintNav mini string in for the sub to have a better compass. This drops out sometimes and disarms, complains about “Compass performance degraded” It is rock solid though. If someone know about a parameter to adjust for this not to be too sensitive it would be very hepful.

We have the 12 sattelites indicator, but position hold is not applicable. Not sure where to start looking for a fix to this. The dashboard in the SprintNav extension is fully populated.

Another thing that did not work so well is the depth hold, I have not involved the sprintNav here but was running on the Baro30 as sensor. A lot of the time the sub races towards surface while giving a manual rotational command, trying to alter heading, while in depth hold, yes alt hold. Sometimes not but these were exceptions. This while not doing speed through water, just being still, trying to adjust heading carefully. It happend both with the sprintNav and the internal gyro.

I have tried to visulize thruster commands for the individual thruster. I haven’t produced a finnished product there. I know that these values can be found in that diagnostic tool in Qground control. I need to get these into the pilot screen to learn how the autos acts and to see my own commands. I may think that i am pointing the little joystick forward, probably strafing a bit at all times though..

Overall not too far away from the truth, it seem to be a platform that can behave steady and the battery bank is enough. Hopefully this week I can have access to seawater and tweak the system.

10

Hi Robin! Glad you’ve reached the field testing stage!

I believe “12 satellites” is indication of low performance / trust of the acoustic navigational source. I’ve seen 20+ in my own tests with the Cerulean Omnitrack. If you could share a .bin vehicle log file, we could dig into this a bit futher. Knowing how you’re bringing in the data from the SprintNav mini would be helpful too - via serial2 udpin, or the NMEA forwarder, or BlueOS extension? How fast have you configured it to provide position updates? 10hz is the minimum recommended… You can modify your failsafe parameter to prevent disarming when the source isn’t trusted. To do so, set FS_EKF_ACTION to 1 (warn only).
By “not applicable” do you mean the vehicle refuses to go into position hold mode? I imagine guided and auto modes are also refusing if so - which would mean the autopilot isn’t receiving good navigational data… does it show up in a map widget at a position that you’d expect?

This sounds like it s a problem with the Bar30, and potentially where it is located in the frame relative to high velocity water movement. If it is in fast moving water, it will detect a lower pressure, and the vehicle will ascend? The sprintNav and gyro are not used for depth hold (relative to pressure.)

This is possible with BlueOS already! Simply load the PWM outputs page - it will warn you the vehicle is armed, but you can see the signals each thruster is receiving in the left region. You could also use Cockpit plotter widget to visualize the numerical throttle outputs for each thruster channel. It’s unlikely you’re sending pilot input unless you’re physically moving the sticks - if so your controller could be damaged? You can adjust the deadband in Cockpit to make it less sensitive, and even set up exponential throttle response.

11

Thanks for a super quick reply.

The Sprint nav is on the same network, so it is talking via UDP through the Sonardyne extension. The HNAV has been fed with 10Hz from the SprintNav, we can increase that.

To graphicly map it in Cockpit we did not look at while at site, but when we started it up now while longside our last position was from the site we were at, so I guess that it knew its position that day as well.

20260331_133537
20260331_1335371920×1081 596 KB

Could a great difference in between the external and internal gyro cause a disbelief in the primary system to the extent that it doesn’t have faith and rate it lower? The calibration level of internal sensor was bad. (We spun a telephone cord of the tether while hanging out in its head hold…) I’ve big vehicle/ quick calibrated it now.

Who decides or simulates the sattelite indicator? Because the SprintNav have been in hybrid mode, its highest state, if it is the Sonardyne extensions task to mark its quality it should have been full. I will investigare HNAV error quality levels further…

I have set the FS_EKF_ACTION to Warn only, great!

Will have a look for bin-files tomorrow, got interupted today.

By not applicable I mean that it refuses to enter Position hold when trying, I can not remember exactly what it says, but it bounches back to Manual.

Bar30 sensor sits straight into the back of the mid-bottle more protected than in the BlueROV2, far away of thruster wash, there will not be any turbulent water there, thrusters sits a level below. It is quite new and gives reasonable measures all the time. Could the pwms to ESCs get disturbed by induction, not likely while going forward is fine… More testing before I change the sensor. I shall also try to if possible to display on screen the locked at depth value setpoint.

20260331_130552
20260331_1305521920×1081 399 KB

I will try to put the PWM outputs in a separate window. I did run it in exponential, I think the gamepad was calibrated, there is barely any noise on those axis anyways.

Lets continue tomorrow! Thanks!

12

An update. Some more progress. I hope Tony @tony-white have the time for some well needed feed back.

Fun things first. We did further calibration of the MBES on this wreck. You can see some non straight bread crums, me flying in stabilize mode. (Data before calibrations.)

20260415_141305 (2)
20260415_141305 (2)1920×1081 624 KB

.bin files, I found them in another place with content, my bad.

Have been allowed to enter position hold now. Did a barrel roll.

Back to basics. The EKF uses its internal instruments as reference as I understand. It seem to be something fishy with AK09915, it’s not represented in the compass rose in blueOS Compass page. Possibly to bad calibration level? (The pi and navigator is mounted with a roll of 90 just like in the BR"2 and it is set up as Roll90.)

Took the vehicle apart in order to be able to do a full calibration (not just Big vehicle) with just the electronics bottle.

Accellerometer, Level Horizon and Gyro checked out ok. Compass calibration though, we never get to start. “MAV_CDM(42424) command failed” in QGC (latest version, just noticed that v.4.2.8 was mentioned as good, but this was year 2024)

When trying compass calib. in BlueOS: “Calibration failed, Error: Unexpected response MAV_RESULT_FAILED” Picture below, the error message vary slightly in between tries.

20260416_152252
20260416_1522521920×1416 620 KB

(Battery voltage was 24V from an AC/DC converter)

Could we have a faulty AK09915? In the assembly guide it is set as primary, and the MMC5883 secondary. Ours have got the other way around and we are not allowed to swap them.

I know that there is a parameter for how sensitive the EKF shall be when comparing input with its internal sensors, we haven’t touched that one yet.

Here is the Sonardyne integration guide, refered to in other posts with faulty URL, this is the updated adress.

Thanks beforehand!

13

Continuing the discussion from Multibeam T500 rov build for wreck and reef surveys:

It seem to have been a software issue. After flashing a fresh BlueOS on the SD-card the compasses came to life. Hopefully systems will come together better now.

14

Proof of concept, check. :saluting_face:

We pulled of 2.8 boxes like this, 100 by 100m. at plus 80m waterdepth. 100% overlap. Black bread crumbs ROV track. Marks in the seabed trawl scours.

Vehicle kept depth flawlessly, held heading very nicely and easy to adjust on the fly. No nodding with the pitch while making speed ahead. Position hold came in as well, didn’t play around with that though.

b24886cc-ec97-45bd-9646-4f9b4c4c8518
b24886cc-ec97-45bd-9646-4f9b4c4c85182048×1664 340 KB

Something fishy though with the Pie/ navigator or its SD-card is what we suspect.

While doing the third box we lost coms. We assumed that the tether had snatched but we managed to retreive the sub carefully and tether was intact and it had power. Sub booted nicely after cycling power.

But something was a bit off. We did not have internal compass sensors coming in, we did not see the extensions in BlueOS left frame, nor got the installed ones to show up in the left frame. We flashed the SD with a new BlueOS again. But it did not feel reliable. The plan now is to change out the Pie, Navigator and SD. Awaiting parts to arrive.

I’d be happy for some input.

Hopefully in a few days we will run this setup on a 17th century wreck.

Added a feel good picture:

b0410851-3418-47f8-b551-3634bc510929
b0410851-3418-47f8-b551-3634bc5109292048×1153 400 KB

15

Hi @IntoTheBlue -

Wow, great data! Were those transects navigated in Auto mode?

Did yo u happen to save any .BIN logs from the dive where things went awry, before re-flashing the SD card? It would be interesting to review those and BlueOS System logs to see what may have gone wrong… but if you didn’t save before hand, the “Black Box recorder” has been destroyed!

16

Fail of us not to save that .bin, we were in a hurry. Should have that in the shut down procedure to always store .bin:s top side.

The transects were flewn in Auto depth, the result is more than good enough. I know there is this feature for the auto-pilot but we use Quinsy for navigation. We did not have time to play around.

Would it have been more stable in Position hold and me over riding with forward thrust, would the position hold avoided a drift off sideways?

If I change EK3_SRC1_POSZ (from Baro?) to GPS or external sensor, can I lock on to an offset to the seabed instead of the present depth in Depth mode? Seabed here was fairly flat, but maybe not next time.

If so I tink theat I’d try to set up another flight mode that is not in use into a clone of Depth hold but with the altitude functionality…

17

Hi @IntoTheBlue -

It may not be necessary on every shut down, but probably a good idea to back things up before a brain wipe - it will prevent you having to calibrate the vehicle again!

I assume by “Auto depth” you mean altitude hold flight mode? This uses the barometer to maintain the same water depth based on pressure.

Surf-track mode uses an altitude source like ping sonar or DVL to maintain the same separation from the bottom as the user drives around. I would not recommend changing EK3_SRC1_POSZ, that would not have the affect you describe.

Driving around in position hold may result in better transects, but setting up an auto mission with waypoints is likely to result in the best possible line following from the autopilot and vehicle.

There is no such thing as a “flight mode that is not in use” - ArduSub has flight modes that exist, if you’d like to add another one you would need to modify the firmware. I think you’re saying that SurfTrack would be a better flight mode for your operations - if the autopilot is getting valid rangefinder distances, this will work! The Surftrack-fixit extension can help setup your vehicle parameters to work properly in this mode.

18

Right, thank you.

There has not been any progress with the build but further confirmation of the proof of concept.

On a site that requires permission for diving we’ve run both MBES but also the more mass appealing instrument of photogrammetry. This a very early quickly processed reperesentation of a side of the vessel from the 17th century.

20260514_082242
20260514_0822421920×1081 414 KB

20260514_145036_2
20260514_145036_21749×1178 561 KB

We just took off the MBES and bolted on this rig, connected it to the switch. As always short of time and no proper time for testing. Not a perfect fit but it worked very well.

I am impressed.

19

An idea for a new revision of the battery pods.

Components:

Custom battery, 60Ah

ESC, 4 in 1 flying drone ESC

Daly Smart BMS, not sure which one

image
image810×872 36.6 KB

Just a quick diagram of my thoughts. The empty box is a DC/DC converter, there are plenty more of those.

My thinking is to use the BMS as a power switch to be able to turn the sub off an on. Also where I get the SOC from each battery.

This ESCs spec seem to be enough of running the T500s carefully. It also can be set up for bi directional and to take PWMs as an input. It might want a fan.

At present our ROV has two 35Ah batteries with a simpel BMS each, it is a mess. There is a big contactor as a power switch and I need to take things apart for charging. Here I can just have the power and balancing cable connected to a bulkhead.

Excluding the BMS the battery pack will take up about 23cm of an 50cm 5 inch bottle, so there is plenty of space left.

Happy to hear what you think.