Companion IP addresses

Hi All

I’ve designed a TMS to manage the tether of my ardusub ROV because I want to use this ROV as a fly-out vehicle to inspect inside shipwrecks or other underwater structures where large ROVs cannot access. The Tether Management System basically pays in or out the ROV tether as required by the operator. It has cameras, lights and a system to latch or release the ROV.

The heart of the TMS is the same as for the Rov’s : a Pixhawk and raspberry (from Bluerobotics). There are 2 computers with QgroundControl : one for the ROV and the other for the TMS.

I’m using a FO switch to send both ROV and TMS ethernet signals.

I have the current IP addresses 192.168.2.1 and 192.168.2.2 for the ROV.

I’ve changed the IP addresses of the TMS to 192.168.2.5 and 192.168.2.6.

It’s working well for the video streams, but the telemetries are mixed together and both Qgroundcontrol softs are lost…

Can someone help me with this problem?

Here’s a diagram that Blue Robotics created. It helps with understanding how information is exchanged between the Pixhawk, the Raspberry Pi, and the surface laptop.

I suggest first try establishing a parallel connection in the tether to the TMS with Pymavlink first and then try it with QGroundControl. Pymavlink · GitBook This could help you with understanding how to separate the TMS Telemetry data and the other data of interest from the ROV’s.

For a system like this I would choose to utilize two sets of tethers and Fathom Interface boards, instead of one set.

Hi @Seb,

Sounds like a useful and interesting setup! :slight_smile:

If you want to run separate instances of QGroundControl on the same subnet (192.168.2.x) then you’ll need to change the telemetry port for one of them (and the device that’s sending to it). I discussed that and another alternative in some detail in this comment.

@CBW3750 that diagram is quite outdated - there’s now an up-to-date and interactive version of it in our docs: Software Components · GitBook :slight_smile:

That would also work, but an extra set of tethers and Fathom-X boards isn’t required for the desired functionality, so would be an unnecessary expense in this case.

Hi Eliot
Many thanks for your help, it works well now. I followed the ‘change sub-net, keep the ports’ method because it looks easier to add a second video stream onto the TMS RPi this way.
I’ll post some pictures on the forum once the system goes out the workshop :wink:

1 Like

Thank you Eliot for telling me about an up-to-date and interactive version of the diagram. It’s definitely is more detailed and useful for my thesis project.

1 Like