Home        Store        Docs        Blog

Proposed Distributed Sub-Surface ROV Control Platform

(Andrew) #1

Background
Back in February I was undertaking preliminary sea trials of the first deployment of the DeepSouth ROV. I later also integrated on the bench the Ping 1D when it was released and ran the whole lot over web based mobile phone interface.

While the trials were successful, towards the end I noticed some control issues and later determined the CPU on the single Raspberry PI (that was controlling everything) was heating up to 90 degrees centigrade. This is well beyond recommended and likely cause of the issues. This led to a re-design…

Design Considerations
The design considerations were roughly as follows:

  • Minimise load on CPU and add passive and active cooling

  • Allow for multiple cameras with minimal latency by using dedicated CPU

  • Allow for multiple sensors if desired including the possibility of on board (multiple) Ping 1D processing for navigation / obstacle avoidance - without the possibility of impacting on cameras or motion control

  • Off load PWM control to a dedicated controller with plenty of expansion capability (ESC, Lights, Gripper, Camera Orientation)

  • Simplify power provisioning and cabling as much as possible - i.e. off the shelf rather than custom

Design
The design is roughly as follows:

Non-Blue Robotics Parts

Build
The build is in progress…

1 Like

(Gwa Gwa) #2

IMU and control is something routinely handled by an 8bit microcontroller. Have you measured the relative CPU usage? I think a whole PI for that is overkill. I think video encoding is probably the major source of CPU work here. Could this problem not be better solved by an ethernet camera module with onboard H.264/5 encoding and a small ethernet switch bottom-side?

0 Likes

(Andrew) #3

The “sensor controller” Raspberry Pi does not just manage GPS and IMU - which as you say are light on CPU, but also the other sensors such as depth and ping.

You can see a need in an autonomous scenario for the ROV to be undertaking its own sonar navigation and obstacle avoidance - potentially with many ping type devices working together. This is going to be much more CPU intensive.

The approach suggested can also easily allow the CPU load to be shared across other Raspberry PI controllers with capacity at slack times. There are many options for clustered Raspberry Pi computing software (e.g. picocluster). The extra 12 USB ports provided are also potentially quite handy for additional cameras and pings!

The overall goal is to get as much compute power onboard the ROV as possible, as cheaply as possible. The distributed computing platform can easily be expanded into additional payload enclosures to suit the application just by adding more clustered Raspberry Pis. As it stands, there is much more CPU capacity and potential future capability available than the current standard BlueROV2 in the same enclosure space while still allowing for same hardware management such as ESCs etc. (no disrespect to the great BlueROV2 package and Blue Robotics team!)

0 Likes

(James) #4

If you’re trying to get more computing power onboard the ROV wouldn’t you be better off with some more powerful SBCs such as: nVidia Jetson Nano or ones with a more powerful SoC e.g. RK3399 on the NEO4?

I just imagine space becoming a premium for all the Raspberry Pis and it may prove more economical to have fewer, more powerful SBCs rather than the expense (and drag) of adding extra enclosures.

0 Likes

(Andrew) #5

Thanks James.

This was also suggested to me privately in a PM from @Bjarte.

This looks like a really good option but I am nervous that the existing python libraries for the various hardware components are too Raspberry specific and don’t migrate well.

I use 3rd party libraries for:

  • Camera image [probably not an issue]
  • PWM control (lights, thruster, gripper, and camera tilt) [probably not an issue]
  • IMU (heading, pitch, roll)
  • GPS
  • Internal Temp / Pressure
  • External Depth / Temp
  • Ping

Also heat is a significant factor…the Jetson looks heat intesive…

0 Likes

(bx10) #6

I know you want to use the phone as the interface but why not put the other raspberry pis (or even a laptop) on land where they are less fragile, easier to work on, etc. All of these things would give you access to the best of modern compute horsepower while still providing you with a simple way to bridge control to your phone. I will PM you a project we worked on.

0 Likes

(Andrew) #7

Hi bx10

You are right that I could use a laptop to boost computing power on the surface but my solution drives everything from a web server hosted directly on the ROV.

This means that from a control and management perspective, it does not matter whether I am using a phone, laptop, or desktop at the surface (or for that matter what make, model, or software installation I am using).

I am trying to boost computing power under the water rather than on the surface as if the ROV is in autonomous mode, it won’t have access to the surface resources for real-time processing.

0 Likes

(bx10) #8

Moved to PM

0 Likes