Sea-Terrain Analysis ROV - An Open Development Project

[EliotBR (Eliot)]

Hi everyone

As many of you may be aware, my role at Blue Robotics is focused on helping our community to flourish and grow. The primary methods for that are through direct product support, theoretical discussions on marine robotics development, and improving the content and accessibility of our documentation and website so that it’s as easy as possible to get started with and work with our equipment. As a part of that I need to continually keep up to date with our software and products, so that I’m well-positioned to answer questions and support development of new and interesting applications.

Coming into the role, one of my ideas for how to effectively bring those components together was through an open-development project that showcases the versatility of designing with and using our products, while forcing me to use our available documentation and resources, and work my way through using and modifying each major component of our software stack. Doing this will allow me to dig deep into the user experience with our products, while determining which important information is missing or hard to find in our available resources, and fixing that as I go. Keeping the development process open has the added benefit that those of you who are new to robotics design can get some sense of how to turn design requirements into a specification, and from there make implementation decisions that match those aims.

Today I’m excited to announce the official start of project StaROV - a back-packable ROV for sea-terrain analysis, which I’ll be documenting here and storing files for on GitHub. For now I’m presenting just the initial requirements that I’ve come up with, along with a couple of very rough initial concepts. I’ll be making relatively regular updates, which will cover design progress as well as notable additions and improvements to our documentation/website that come about because of this project.

Questions are welcome, but response threads that get too long will be moved to separate topics to make the project progress easier to follow. As major sections occur I’ll try to keep an up-to-date table of contents in this post.

Contents

1. Preliminary Requirements (2021/Oct/01)
2. Initial Concepts (2021/Oct/01)
3. Technical Reference (2021/Oct/01)
4. Mass Capacity Estimation (2021/Oct/14; finalised 2021/Nov/16)
5. Companion and Docs Structural Changes (2021/Nov/16)

---

Preliminary Requirements

Primary Project Aims

1. Find and fix documentation/examples that are incomplete/missing in the Blue Robotics
   website/guides/docs/software, particularly those which are important/essential to
   doing practical design and integration work with our equipment/products
2. Improve and consolidate understanding of the full stack of Blue Robotics products,
   including electronics and software

Desired Qualitative Outcomes

1. Provide a useful reference for a detailed design project on our forums, complete
   with relevant reasoning and calculations
2. Inspire existing and prospective users with an interesting project and a better
   understanding of how our components can be integrated together in a custom system
3. Encourage more frequent ‘marine robotics’ design and development discussion,
   beyond product support and announcements

Design Requirements

Product Statement

Design a small ROV for sea-floor inspection, capable of being transported in a 35L
backpack, together with all necessary control and communication hardware.

Physical

• Must fit inside a backpack, with accompanying control and communication hardware
• A fit adult should be able to ride with it on a bicycle
• Total setup (excluding backpack) must be ≤ 15kg, should be ≤ 10kg, and could be ≤ 7kg
• Must be deployable and controllable by a single operator
• Tether must be ≥ 30m, should be 50m, and could be 100m
• Depth rating must be ≥ 10m, should be ≥ 30m, and could be ≥ 50m

Functionality

• Sonar sea-floor scanning/imaging is required
• ‘Terrain-hold’ (constant altitude above sea-floor) functionality is required
• Forward-facing and downward-facing cameras are required
• Cameras facing the rear (tether) and above are desired
• Simultaneous multi-camera streaming is required
• Single camera stream recording is required, multi-camera desired
• Real-time object detection capability is desired
• Detected object/obstacles video overlay is desired
• Mapping scanned area is desired, ideally with location-tagged object detections

Modelling

• All major components must be modelled in mechanical CAD, including at least their
  mass, center of mass, and displaced water volume (for ‘wet’ components)
• Center of mass and center of buoyancy must be simple to recalculate when components
  are moved
• All major electronics must be modelled in ECAD, including at least the ports expected
  to be useful in an ROV context (e.g. USB required, HDMI not required)
• Linked MCAD and ECAD models is desired
• Wires modelled in MCAD is desired, including with expected colouring
• Modelled components must be in source control, and openly available

Component Selection

• Blue Robotics components preferred where reasonable, but justification still desired,
  including comparison to similar/competing products where relevant
• Components should be selected for low cost at small volumes
• Selected components should be readily available, by purchase or at least source files
  (i.e. cannot use unreleased components that would prevent the project from being shared)

Design Methods + Software

• Open source software and freely available resources are preferred where possible
• Design decisions should be explicitly justified where possible, ideally with a
  decision tree displaying attempted branches alongside alternatives that have been
  dismissed or not yet explored
• Calculations should be documented and explained

Cost

• Final product components (excluding tether, lights, and scanning sonar) must be less
  than the BlueROV2, should be less than 90%, could be less than 80%
• Software used should be readily available for free/at a low cost to at least hobbyists
  and research institutes/organisations, preferably everyone
• Manufacturing costs outside those for purchased components should be minimised

Timeline

• ROV must meet requirements and be usable within 2 years, should be within 1 year,
  could be within 6 months
• Project as a whole has no required completion date (could be an ongoing development)
• Progress summaries must be reported monthly in the Blue Robotics forum ‘build’
  category, could be reported fortnightly
• Dive logs should be posted at least every two months once relevant, preferably every
  month

---

Initial Concepts

[EliotBR (Eliot)]

Technical Reference

@EliotBR

All major components must be modelled in mechanical CAD, including at least their
mass, center of mass, and displaced water volume (for ‘wet’ components)

In considering this requirement, I’ve found that while many of our products already have CAD models available it can be difficult to access several models quickly, and the same applies to datasheets and major product properties that could be used for comparison.

To help address that I’ve started compiling a Technical Reference guide on our website, which will contain tables that reference the main properties of our major products for quick reference and access.

At this stage it’s very much incomplete, and will likely be a work in progress over the next few weeks at least. In the spirit of openness it seems reasonable to share it now, because the information that has already been linked may be of use to some of you, and it provides an avenue for feedback on which components and properties are most relevant to include, and how to make the page as useful as we practically can

Please direct any relevant feedback to the Technical Reference topic

[richard-rickett (Richard)]

Excellent project, looking forward to seeing it flourish

[pforperry (Jason Perry)]

G’day Eliot,

You have my attention!

Kind regards
Jason

[EliotBR (Eliot)]

Mass Capacity Estimation

One of the simplest checks for concept viability is the mass capacity. If the form-factor isn’t capable of supporting the required components then it’s not a valid design, so this is a reasonable check to perform early on in the process.

Concept Constraints

The two current concepts are both based on cylindrical enclosures, which are sized based on what is already available in the BR store (as a reasonable starting point, and to make use of the costs that are reduced by scale-production). The first concept uses parallel 4" tubes in a catamaran structure, whereas the second one uses a 4" tube inside an 8" tube, forming a donut. It’s conceivable that a catamaran-style ROV could instead use 3" tubes, but the donut tube diameters are relatively fixed by the thruster size and the requirement to have at least some space for the electronics and batteries inside.

Mass Minimisation

Since this design isn’t intended as a highly modular platform for others to build off, it makes sense to try to avoid material that’s only there for buoyancy or ballast purposes. Additional buoyancy can be achieved by lengthening the tubes, which in turn provides extra space for the contents and wiring. If extra mass is desired then likely more batteries can be included.

Avoiding buoyancy material/ballast also helps to minimise the overall mass of the vehicle, which is beneficial for efficient motion. Adding buoyancy foam still adds to the total mass and drag, which takes more energy to accelerate than a smaller total mass, particularly given the fixed thruster size.

Wet vs Dry Mass

From a buoyancy standpoint, it can be helpful to consider “wet mass” and “dry mass”. Components inside the enclosure don’t contribute to the buoyancy, so their total (dry) mass is considered. Components outside the enclosure do partially contribute to the buoyancy, so it can be helpful to consider them by the equivalent mass of their gravity force minus their buoyancy force (so-called “wet mass”). If this wet mass is known, the overall buoyancy balance can be considered as buoyancy from the total enclosed volume, minus the dry mass of everything inside enclosures and the wet mass of everything outside it/them, which is a convenient simplification.

Neutral Buoyancy Calculation

The buoyancy force of a given volume in a fluid is calculated by the displaced fluid volume, multiplied by the fluid density and gravitational acceleration:

\begin{align} F_{buoyancy} &= V\cdot\rho\cdot g\\ &= m_{displaced} \cdot g \end{align}

If we aim for neutral buoyancy, we want

\begin{align} F_{buoyancy} &= F_{gravity}\\ m_{displaced} \cdot g&= m_{total}\cdot g\\ \rightarrow m_{total} &= m_{displaced}\\ \rightarrow m_{capacity} &= m_{displaced} - m_{required} \end{align}

where m_{required} is an optional offset for the mass of the known components (e.g. thrusters, end caps, tube material per unit length, sonars), leaving the ‘capacity’ as the mass of the unknowns/variable inputs (electronics, cables, batteries, etc).

Applied Calculations

In the interest of simplicity, and a conservative estimate for capacity, the displaced water is assumed to be pure, with a density of 1\text{g/cm}^3.

The catamaran volume is roughly determined by two cylinders of equal length

\begin{align} V_{catamaran} &= 2\cdot\pi r_c^2l_c \end{align}

The donut volume is determined by the outer cylinder minus the inner cylinder

\begin{align} V_{donut} &= \pi (r_o^2 - r_i^2)l \end{align}

From the relevant technical details:

\begin{align} r_c &\approx 57mm\\ r_i &\approx 50.6mm\\ r_o &\approx 108mm\\ \rightarrow V_{catamaran} &\approx 2\pi \cdot 57^2\cdot l_c\\ &\approx 20414.07\cdot l_c &[mm^3]\\ \rightarrow m_{displaced-catamaran} &\approx 204.14 &[g/cm]\\ \rightarrow V_{donut} &\approx \pi(108^2-50.6^2)l\\ &\approx 28599.93\cdot l &[mm^3]\\ \rightarrow m_{displaced-donut} &\approx 286.00 &[g/cm] \end{align}

For the expected mass:

item	dry mass	wet volume	wet mass (fresh)
4" flange	144 g	6 mm	83 g
4" dome	82 g	~275 \text{cm}^3	-193 g
4" 10 hole end cap	159 g	6 mm	98g
4" tube	25.7 g/cm	-	-
8" flange	690 g	6 mm	470g
8" acrylic end cap	564 g	13 mm	88g
8" tube	50.2 g/cm	-	-
T200 thruster	-	-	156 g
Ping360	-	-	175 g
Ping Sonar	-	-	55 g

Each concept design includes 3 thrusters and one of each sonar (3\times 156 + 175 + 55 \approx 700g).

In addition, the catamaran design includes 2 4" domes, 4 4" flanges, and 2 4" 10 hole end caps (~140g). The donut design includes 2 4" flanges, 2 8" flanges, and 2 8" acrylic end caps with a hole in the middle (~1245g).

Accordingly,

\begin{align} m_{capacity-catamaran} &\approx (204.14 - 2\cdot 25.7)\cdot l_c - (700 + 140)\\ &\approx 152.74 \cdot l_c - 840\\ m_{capacity-donut} &\approx (286.00 - (25.7 + 50.2))\cdot l - (700 + 1245)\\ &\approx 210.10\cdot l - 1945 \end{align}

Those expressions can be plotted as follows:

The main remaining weight is from batteries and internal electronics (e.g. companion computer, autopilot board, ESCs, mounting hardware). Taking a 1163g Blue Robotics Battery as a rough upper limit of battery weight, and (conservatively) assuming a similar weight for the combined electronics and mounting, both designs would be neutrally buoyant with a tube length of somewhere around 20cm. That doesn’t seem unreasonable as an initial size estimate, so both designs are considered feasible for now, and can continue to be evaluated.

[Mark-Belbin]

Awesome ROV concept Eliot! Interested to see how the multi-camera streaming works out. In the past I’ve accomplished this with gStreamer, sending multiple camera streams to different ports on the same IP address (ex: an operator laptop).

[EliotBR (Eliot)]

@Mark-Belbin

Awesome ROV concept Eliot!

Thanks @Mark-Belbin!

@Mark-Belbin

Interested to see how the multi-camera streaming works out. In the past I’ve accomplished this with gStreamer, sending multiple camera streams to different ports on the same IP address (ex: an operator laptop).

Haha, so have I, a couple of times now

The harder part is more on having a properly convenient way of displaying/recording the different streams, preferably integrated into the main control software rather than requiring separate applications/code for control vs extra videos.

[Mark-Belbin]

That’s the camera stream holy grail right there, at least it was for my robotics team when I was a MATE competitor!

@EliotBR

Haha, so have I, a couple of times now

The harder part is more on having a properly convenient way of displaying/recording the different streams, preferably integrated into the main control software rather than requiring separate applications/code for control vs extra videos.

[EliotBR (Eliot)]

Quite a brief update this time - I’ve just got around to completing the Applied Calculations from my previous update on mass capacity estimation.

Companion and Docs Changes

Since the previous update we’ve released BlueOS Beta (replacement Companion software) for testing, which the software team has been working very hard on for the past several months. Incidentally BlueOS supports multi-camera streaming out of the box, and more generally it will simplify and improve the robustness of any development work that project StaROV requires in the Companion computer as it progresses further.

For others interested in development, I’ve made a post on External Integrations/Extensions which outlines our current intent for how BlueOS extensions will be managed, and opens the floor for discussion of things you’d like to be able to do in BlueOS, and how we’re best able to facilitate them.

At the same time, I’ve been working with @patrickelectric to get a new documentation system up and running that will end up replacing the current ardusub.com. The new docs system will be easier for us to maintain, and will also support software versioning, so that we’re better able to document and separate upcoming/developmental features from stable ones and old deprecated ones, which should be helpful for everybody who wants to work or develop with Blue Robotics software.