Multibeam T500 rov build for wreck and reef surveys

Build 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

1 Like
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

3 Likes
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.

3 Likes
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

It creates *.bin files but they are empty, strange no? Same now when I started it up.

bin zero
bin zero1862×835 95.8 KB

Files free for download for whom it might interest:

The error message when trying to enter poshold is “Flight mode change failed POSHOLD”

Not enough staff for long side sea trials with USBL this week unfortunately.