Electronics | Jellybot

01

Overview

The major contributions of the electronics subsystem this semester are:

Custom BlueOS Docker Extension over I²C for the pneumatic actuation of Jellybot
Custom BlueOS Docker Extension for capturing still images
Custom BlueOS Docker Extension for 3D orientation visualisation of Jellybot
Python script for PS4 controller interface
Camera characterisation to quantify optical distortion and underwater image quality
Calibration of Jellybot's sensors and components

02

Hardware

The electronics subsystem of Jellybot is built around the Blue Robotics Navigator Flight Controller HAT, mounted on a Raspberry Pi 4 Model B^[3]. Unlike a conventional ROV where the flight controller directly drives motors, the Navigator in this project serves exclusively as a sensor and attitude data source. Motor and solenoid control is handled by a separate custom system.

2.1 Sensors and Actuators

The listed components form the core sensing and control framework of Jellybot, each selected to fulfill a specific design feature and specification.

To achieve directional and surface control, the Playstation 4 Controller was selected.
To step down voltage, the Blue Robotics Power Sense Module was selected.
To ensure connection between the Ground Control System and Jellybot, a 5m ethernet cable was selected.
To provide orientation, the Blue Robotics Flight Navigator was selected.
To provide real-time visual feedback for monitoring and analysis, the Blue Robotics Low-Light USB Camera was selected.
To measure depth, the Blue Robotics Bar02 Sensor was selected.
To coordinate communication between all onboard sensors, the Raspberry Pi 4 was selected.

Jellybot hardware architecture diagram — Figure 1 — Jellybot Hardware Architecture

Component	Model / Detail	Role
Main Computer	Raspberry Pi 4 Model B	Runs BlueOS and Docker extensions
Flight Controller	Blue Robotics Navigator HAT	IMU, ADC, I²C hub
PWM Expander	PCA9685	Drives all 4 motor/solenoid channels
Motor Drivers	2× Dual H-Bridge	Independently drives motor + solenoid
Pump Motors	2× DC Pump Motors	Pressurises silicone flaps
Solenoid Valves	2× 3-Way Solenoid Valves	Controls inflation and venting
Depth/Pressure Sensor	Blue Robotics Bar02	Depth sensing
Camera	Blue Robotics 1080P USB Camera	Live video feed
Power Sense Module	Blue Robotics Power Sense	12V to 5V step-down voltage regulation
Battery	12V 20,000 mAh Li-Ion	Powers motors and Navigator
Controller	PS4 DualShock 4	Wired operator input via Ground Control System

Table 1 — Hardware Component Overview

03

Software Stack

Jellybot's software stack is organised into three distinct layers.

At the bottom, the Flight Controller Board runs ArduSub 4.5.3 STABLE. It is the autopilot firmware responsible for sensor fusion, attitude estimation, and depth sensing.
Above it, the Onboard Computer (Raspberry Pi 4) runs BlueOS, a Docker-based operating system that orchestrates services, manages custom extensions^[2], and bridges communication between layers using the MAVLink protocol.
At the top, the Ground Control Station runs Cockpit for the pilot interface and QGroundControl for sensor calibration and parameter configuration, communicating with the vehicle over Ethernet.

BlueOS software stack architecture diagram — Figure 2 — BlueOS Software Stack Architecture

Layer	Component	Role
Firmware	ArduSub 4.5.3 STABLE	Sensor fusion, attitude estimation, depth sensing
OS / Middleware	BlueOS (Docker-based)	Service orchestration, web UI, extension management
Protocol Bridge	MAVLink2REST^[8]	Translates MAVLink binary → HTTP/JSON (port 6040)
Message Routing	MAVLink Router	Routes MAVLink between ArduSub and network clients
Ground Control Station	Cockpit	Pilot interface, video feed, telemetry widgets
Calibration	QGroundControl	Sensor calibration, parameter configuration

Table 2 — Software Stack Summary

3.1 Motor Control Extension (`blueos-motori2c-extension`)

The Problem

The Navigator HAT's PWM outputs are managed by ArduPilot, which configures them as servo PWM signals at a 50 Hz protocol with 1000–2000 µs pulses designed for ESCs and servo motors^[3]. This format encodes position or throttle, not raw duty cycle, making it incompatible with H-bridge motor drivers which require a variable duty cycle PWM signal to control motor speed and direction.

To overcome this limitation, this custom BlueOS Docker extension communicates directly with the PCA9685 over I²C Bus 6 using smbus2, configuring it at 1 kHz with a full 0–100% duty cycle range, translating linearly to 0–12V motor output.

The full code for this extension can be accessed here.

How it works

The controller.py script runs on the operator-side and reads PS4 button inputs. When a button is pressed, it sends an HTTP POST request to the Flask API running inside the Docker container on port 8084 of the Pi. The Flask server receives the request and calls set_pwm(), which writes the corresponding duty cycle to the PCA9685 register for that channel over I²C. If the I²C write fails due to motor electrical noise, the function automatically retries up to 3 times at 10 ms intervals before raising an error.

System Architecture

Jellybot Motor Architecture Diagram — Figure 3 — Motor Architecture Diagram

Verification with Multimeter

Video 1 — Motor Control Extension Testing

Prior to attaching the system to the silicone flaps, a multimeter was used to verify the output voltages, confirming that the PCA9685 was correctly driving the motor drivers. The voltage readings shown are below 12V as the PWM duty cycle was not set to 100% during testing.

Key API Endpoints

Endpoint	Method	Function
`/motor/<ch>/speed`	POST	Set channel speed (0–100%)
`/motor/status`	GET	Check PCA9685 connection status

Table 3 — Motor Control Extension API Endpoints

3.2 Camera Capture Extension (`blueos-capture-extension`)

How it works

A second BlueOS Docker extension captures still images from the live underwater camera stream, exposing a simple HTTP endpoint for triggering image saves.

The full code for this extension can be accessed here.

Camera capture extension UI showing Status: READY and Capture Image button — Figure 4 — Camera Capture Extension UI (blueos.local:8080)

Data Flow

BlueOS Camera → H264 UDP Stream (127.0.0.1:5600)
    → GStreamer Pipeline (avdec_h264 decode)
    → OpenCV (buffer latest frame in background thread)
    → Flask /capture endpoint (port 8080)
    → Saves .jpg to /userdata/ (volume-mounted to Pi filesystem)

Figure 5 — Camera Capture Extension Data Flow

Implementation

This extension was used to capture the raw checkerboard images used in Camera Characterisation Scenario 1.

3.3 Pneumatic Actuation & Controller Interface

How it works

The controller.py script runs on the topside Ground Control Unit and sends HTTP POST requests to the Flask API on the Pi, which in turn drives the PCA9685 over I²C to control two DC pump motors and two 3-way solenoid valves. Each flap pair has an independent motor (pressurisation) and solenoid (direction control), allowing coordinated or per-flap operation.

The system operates across two independent channels: left and right. Each channel has its own motor and solenoid, allowing coordinated or individual flap operation.

The full code for this extension can be accessed here.

PS4 Controller Button Mappings

Button	Action
L1	Pulse Flap Channel 1 (0.7 s)
R1	Pulse Flap Channel 2 (0.7 s)
Square	Activate Channel 1 (1 s)
Triangle	Activate Channel 2 (1 s)
X	Activate both Channels simultaneously (1 s)
L2	(Trap air) — Channel 1: motor runs 1 s then off, solenoid holds
R2	(Trap air) Channel 2: motor runs 1 s then off, solenoid holds
O	Emergency Stop — valve release + motor cutoff, resets all locks

Table 4 — PS4 Controller Button Mappings^[5]

The L2/R2 trap-air sequence engages a one-press lock that holds the solenoid closed. The lock can only be reset by pressing O.

Safety

Valve release on emergency stop is instantaneous and mechanical with no software delay.

04

Component Configuration

4.1 AHRS Orientation & Accelerometer Calibration

The Problem

Unlike conventional ROVs, Jellybot does not have a dedicated nose as the front. Additionally, ArduPilot's IMU assumes the board is mounted face-up. Mounting it vertically means gravity is sensed on the wrong axis, making all attitude readings incorrect by default.

Because Jellybot is a vertical cylinder, the Navigator is not oriented in its default horizontal orientation assumed by ArduPilot.

Overcoming the Problem

ArduPilot provides the AHRS_ORIENTATION parameter to remap IMU axes. After determining the Navigator's installed orientation, this was set to Pitch90 (value 25), correcting for the 90° pitch offset^[1].

Accelerometer Calibration

Performed via QGroundControl's Sensors tab (6-position procedure). The GPIO pins on the Navigator were used as a fixed reference point for identifying the "nose" direction during each step.

4.2 Bar02 Depth/Pressure Sensor Integration

The Bar02 connects to one of the two I²C ports on the Navigator via JST GH cable.

Zeroing Behaviour

At every power-on, ArduPilot records the current atmospheric pressure as the 0 m reference. Powering on indoors introduces an offset equal to the indoor-to-surface pressure difference.

Calibration Procedure during Testing

Float Jellybot at the water surface and run Barometer calibration in QGroundControl.

Known Limitation — Depth Sensor Spiking

During pool testing, the Bar02 reading spiked erratically when submerged rather than giving a stable depth reading. This is likely caused by dynamic pressure from wave action and water turbulence hitting the sensor face directly. The sensor cannot distinguish between static water pressure and the sudden impact pressure from moving water.

Additional remarks: The sensor was placed to complement Jellybot's orientation instead of being in its default placement.

05

Camera System Characterisation

5.1 Introduction & Motivation

Jellybot's camera system consists of a Blue Robotics USB Low-Light Camera sealed behind a clear acrylic dome port. The dome introduces a refractive air–glass–water interface that can distort imagery.

For a system whose core task is visual inspection of coral bleaching, uncharacterised optical distortion poses a direct risk to detection reliability. Three objectives structure this work:

Quantify geometric distortion introduced by the dome port, in air and underwater.
Characterise spatial sharpness degradation across the field of view (centre, edges, corners).
Evaluate colour visibility and underwater image quality.

The full code for this extension can be accessed here.

Geometric Distortion Coefficients

Radial distortion is modelled using three coefficients:

k1 is the primary radial term that determines whether the lens exhibits barrel distortion (k1 < 0) or pincushion distortion (k1 > 0).
k2 and k3 are higher-order corrections that refine distortion at the extreme periphery of the image.

All three are computed by OpenCV's calibrateCamera function using the checkerboard images.

In Scenario 1, all three coefficients (k1, k2, k3) are reported to compare the full distortion profile between the no-dome and dome conditions in air.
In Scenario 2, only k1 is reported as the primary indicator of the water-induced distortion effect. Δk1 value directly quantifies how much additional barrel distortion is introduced when the dome is submerged.

Scenario	Environment	Focus	Status
1	Air	Dome optics baseline (distortion + sharpness)	✓ Complete
2	Water	Dome optics underwater (distortion + sharpness)	✓ Complete
3	Water	Colour visibility (colour accuracy, UCIQE)^[4]	✓ Complete

Table 5 — Camera Characterisation Scenarios

5.2 Scenario 1 — Dome Optics on Land (Air Baseline)

Hypothesis

The dome port will introduce barrel distortion and a reduction in sharpness. However, the effects should be minimal as the medium (air) remains constant.

Purpose

Establish a baseline characterisation of the optical distortions introduced by the dome in air. This serves as the reference condition for direct comparison with Scenario 2 (in water).

Objective

Quantify geometric distortion and sharpness degradation caused by the dome by using a structured checkerboard target and OpenCV camera calibration.

Subject

Printed and laminated A4 checkerboard: 9×6 inner corners, 30 mm squares (OpenCV standard).

Comparison

Checkerboard image captured with and without the acrylic dome, in air.

Metrics

Geometric distortion (radial + tangential distortion coefficients via OpenCV calibrateCamera)^[10]
Sharpness/resolution (Laplacian variance across the FOV)^[12]

Testing Set-Up

The Camera was mounted onto a stand and positioned 0.6m away from the target. For every position, 2 pictures are taken (one without the dome and the other with the dome). In total, 30 pictures were used with varying angles as required from OpenCV^[6][11].

The gallery of photos taken can be assessed here.

The complete photo set for Scenario 1 can be accessed here.

Figure — Scenario 1 Set-Up — Figure 6 — Scenario 1 Set-Up

Sample Comparison

These two photos are taken with the target in the centre of the frame. Visually, the dome effect is not noticeable.

Checkerboard without dome — No Dome (Baseline)

Figure 7 — Checkerboard Comparison: No Dome vs With Dome (Air, 0.6 m)

Results

Condition	k1	k2	k3
No dome (baseline)	−0.006172	0.049733	−0.032124
With dome	−0.006274	0.071756	−0.062122
Δ (dome effect)	−0.000102	+0.022023	−0.029998

Table 6 — Distortion Coefficients (Scenario 1)

Distortion vector field showing pixel displacement during undistortion with dome — Figure 8 — Distortion Vector Field (With Dome, Air)

The distortion vector field [Figure 8] above plots the pixel displacement that OpenCV's undistortion algorithm applies to correct each point in the image. The arrows point in the direction each pixel is moved during correction, with arrow length proportional to displacement magnitude. The field confirms the k1 result where displacement is negligible across the centre and mid-frame and grows significantly only at the periphery. This peripheral concentration is driven by the higher-order radial coefficients k2 (0.071756) and k3 (−0.062122), which cause distortion to grow non-linearly with distance from the optical centre.

Zone	Sharpness Reduction
Centre	30%
Edges	39%
Corners	58%

Table 7 — Scenario 1 Spatial Sharpness Results

Analysis

The result obtained supports the hypothesis. In the same medium (air), the dome introduced minimal distortion (Δk1 = −0.0001, negligible). This is expected because the Blue Robotics Camera is already low-distortion in design. What was surprising was the degree of sharpness loss introduced by the dome. Approximately 30% at the centre, 39% at the edges, and 58% at the corners[Table 7]. For Jellybot, having the target (coral reef) positioned at the centre of the frame would be optimal, and a 30% reduction is acceptable.

5.3 Scenario 2 — Dome Optics in Water

Hypothesis

In a different medium (water), refraction becomes a new contributing factor. The greater refractive index difference between water and the acrylic dome compared to air is expected to increase geometric distortion and further degrade sharpness relative to the air baseline established in Scenario 1.