← All work
Core productConnected-product researchActive R&D2023–Present

Underwater Monitoring R&D

A staged prototype and validation programme that connects physical risk, embedded control, data quality, operator software, and future AI without unsupported field claims.

Long-term research into an underwater monitoring system for shrimp farming using video, water-quality sensing, remote control, and software-assisted analysis.

Project brief

The product context, ownership, and current evidence.

Target users

Aquaculture operators, research teams, and connected-product teams investigating underwater observation, sensing, telemetry, and controlled field validation.

Intended buyer outcome

A staged prototype and validation programme that connects physical risk, embedded control, data quality, operator software, and future AI without unsupported field claims.

Owned scope

Research direction · System architecture · Software-led prototyping

Evidence status

Problem research, system architecture, and risk mapping are documented; an integrated, field-validated underwater product does not yet exist.

Problem

Aquaculture monitoring combines difficult physical constraints—waterproofing, visibility, power, communication, placement, and maintenance—with the need for understandable live data.

Approach

Explored system architecture across ESP32 and Raspberry Pi control, cameras, sensors, tethering, motor layouts, web/mobile interfaces, and future AI-assisted analysis.

Current outcome

An active research direction with documented system concepts and prototype questions. It is presented as R&D, not as a field-validated commercial system.

Maturity & lifecycle

What is complete, active, and still planned.

Problem research, system architecture, and risk mapping are documented; an integrated, field-validated underwater product does not yet exist.

Evidence reviewed

  1. Discovery

    Complete

    Aquaculture monitoring needs, imaging, sensing, communication, enclosure, power, and maintenance risks were researched.

  2. Scope & architecture

    Complete

    Software-led subsystem, control, telemetry, communication, safety, and validation boundaries were designed.

  3. Design & prototype

    In progress

    Imaging, sensors, telemetry, control, enclosure, and component questions require staged bench and tank evidence.

  4. Build & integrate

    Planned

    A sealed integrated vehicle and representative operator system follow successful subsystem evidence gates.

  5. Verify & launch

    Planned

    Repeatable tank and supervised pond trials are required before any field-performance or product-readiness claim.

  6. Handover & iterate

    Planned

    Productization requires reliability targets, safety review, specialist partners, service procedures, and field acceptance criteria.

System map

How the product boundary fits together.

  1. 01

    Observe

    Camera, controlled illumination, and water-quality sensors capture evidence under difficult pond conditions.

  2. 02

    Control

    Embedded controllers coordinate telemetry, movement concepts, safety states, and local device interfaces.

  3. 03

    Connect

    A tethered or surface-relay path carries power, commands, video, and telemetry without assuming underwater radio reliability.

  4. 04

    Interpret

    Web or mobile software presents operator evidence; computer vision follows only after representative data validation.

Claim boundary

Constraints and unresolved risks

  • Turbidity, backscatter, lighting, working distance, calibration, biofouling, and enclosure integrity can invalidate software assumptions.
  • Underwater wireless range, computer-vision accuracy, field reliability, and commercial readiness are not claimed without representative evidence.
  • Production electronics, certification, pressure-rated mechanical design, and manufacturing require appropriately qualified specialist partners.

Public evidence

What supports this case study

Research case study

Visible maturity boundaries separate researched, designed, component-level prototype questions, and planned integrated validation.

Imaging decision journal

A documented decision treats image acquisition and human readability as validation gates before computer vision.

Verified Open evidence →

Connected prototype guide

A public architecture guide connects ESP32 telemetry, command acknowledgement, realtime dashboards, and failure handling.

Open evidence →

Engineering highlights

  • ✓Aquaculture monitoring problem and stakeholder needs researched
  • ✓Camera, illumination, sensor, compute, tether, and control boundaries designed
  • ✓Turbid-water visibility and enclosure integrity treated as test gates
  • ✓Remote monitoring and AI-assisted analysis remain planned until reliable data exists

Technology and domains

ESP32Raspberry PiSensorsIoTComputer visionRoboticsAquaculture

01 / Research status

Every subsystem is labelled by maturity.

This initiative is active R&D. Architecture and risk mapping are more mature than the physical system, and no field-performance claim is made.

  1. 01.1Researched: aquaculture monitoring needs, underwater communication constraints, turbid-water imaging, sensing, and maintenance risks.
  2. 01.2Designed: software-led system boundaries for embedded control, cameras, sensors, tether or relay communication, and operator interfaces.
  3. 01.3Prototyped: component-level experiments and software concepts may be evaluated independently; they do not establish an integrated field system.
  4. 01.4Planned: sealed vehicle integration, repeatable pond trials, labelled vision data, AI-assisted monitoring, and productization evidence.

02 / Imaging and sensing

Reliable evidence comes before computer vision.

Turbidity, backscatter, working distance, lighting angle, biofouling, and sensor calibration can invalidate a model before model selection matters.

  1. 02.1Compare visible and infrared illumination experimentally instead of assuming infrared improves underwater visibility.
  2. 02.2Record camera, lighting, distance, turbidity, and enclosure conditions alongside every useful sample.
  3. 02.3Treat dissolved oxygen, temperature, pH, and other sensor choices as calibration and maintenance questions, not a feature checklist.
  4. 02.4Introduce detection or behavioural analysis only after a representative, reviewable dataset exists.

03 / Embedded and communication architecture

Safety and recoverability shape the control system.

The system must remain understandable when connectivity, power, a sensor, or a motor fails.

  1. 03.1Separate deterministic low-level control from higher-level video, storage, dashboards, and future AI workloads.
  2. 03.2Design explicit loss-of-command, low-power, leak-detection, and recovery states before autonomous behaviour.
  3. 03.3Prefer testable tether or surface-relay communication paths over unsupported claims about underwater wireless range.
  4. 03.4Log commands, acknowledgements, sensor quality, and faults so a trial can be diagnosed after recovery.

04 / Mechanical and power risks

The enclosure is a test programme, not a box around electronics.

Pressure, sealing, heat, corrosion, buoyancy, cable penetrations, serviceability, and battery safety affect every software decision.

  1. 04.1Validate dry mass, displacement, trim, centre of gravity, and recoverability before powered water trials.
  2. 04.2Pressure-test seals and penetrations incrementally with non-critical payloads and documented inspection criteria.
  3. 04.3Budget power across compute, lighting, sensors, communications, and propulsion with measurable margins.
  4. 04.4Keep custom electronics and PCB work behind verified electrical, thermal, and enclosure requirements.

05 / Validation roadmap

Progress through evidence gates.

Each stage should retire one expensive uncertainty before the next integrated build.

  1. 05.1Bench: validate sensors, camera and lighting, telemetry, command acknowledgement, logging, and fault handling.
  2. 05.2Tank: validate sealing, thermal behaviour, buoyancy, trim, visibility, controlled motion, and recovery.
  3. 05.3Pond: validate maintainability and data quality in representative water under supervised operating limits.
  4. 05.4Productization: define reliability targets, safety review, manufacturing partners, service procedures, and field acceptance criteria.

Client relevance

What this evidence can support in a product engagement.

These applications reflect demonstrated product reasoning and the stated maturity boundary—not an unsupported production or client-result claim.

Explore Connected/IoT Product Prototyping ↗
  • De-risk a connected-product idea through testable subsystem boundaries and evidence gates.
  • Connect embedded telemetry, cameras, sensors, and operator software without hiding physical constraints.
  • Design a monitoring dashboard and device protocol around explicit fault and recovery states.
  • Plan an AI or computer-vision workflow around representative data rather than speculative accuracy claims.

Related engineering notes

Related engineering notes

From ESP32 Sensor to Realtime Dashboard: A Prototype Architecture

Related engineering journal

Related engineering journal

Treat underwater imaging as a data-quality problem before computer vision2026-07-10

Have a related product problem?

Define the smallest useful next step.

Book a free consultation ↗Send a project brief