All posts
robotics gazebo simulation embedded design

How I Won My First Robotics Design Competition

AXIOM D1 — a tracked drain-cleaning robot — took first place at the Virtana × U.W.I Engineering Student Society Robotics Design Competition. Here's the engineering behind it.

Our team, Code Blooded, took first place at the Virtana × U.W.I Engineering Student Society Robotics Design Competition. This is the story of the robot that got us there — AXIOM D1, a tracked drain-cleaning robot — and the engineering decisions behind the win.

It started, as these things should, with a real problem.

The Design Problem

Clogged drains are a recurring cause of urban flooding in Trinidad and Tobago. Clearing them by hand is slow — roughly 50–100 m per worker per day — hazardous, and exposes workers directly to contaminated runoff. The competition challenge was to build something that could do the job remotely.

We started with site observations of open drains in St. Augustine and Curepe, plus published maintenance data for Trinidad and Tobago. That gave us four hard functional needs:

  1. Debris removal — physically collect solid waste from the drain floor.
  2. Algae cleaning — mechanically scrub biofilm off concrete surfaces.
  3. Shallow-water operation — function in 0–15 cm of standing water.
  4. Compact form factor — fit inside channels as narrow as 0.45 m.

The competition was framed around UN Sustainable Development Goal 6 (Clean Water & Sanitation), so the brief wasn’t “build a cool robot” — it was “solve a real sanitation problem, and justify every decision.” That second half, I think, is what won it.

Choosing the Platform

We generated three candidate concepts and ran them through a weighted Pugh matrix:

  • Concept A — wheeled robot with a gripper arm. Mechanically simple, but wheels lose traction on wet, algae-slick concrete.
  • Concept B — tracked robot with a scoop-and-conveyor collector plus rotary brushes. More complex, but handles both debris and algae.
  • Concept C — floating drone with a skimmer basket. Can’t operate in dry or very shallow sections at all.

Concept B won decisively (weighted score +0.80 vs. +0.05 and −0.55). The deciding criteria were traction on wet concrete and algae-scrubbing capability — the two we’d weighted heaviest because they map directly to the operating environment. Tracks give continuous ground contact and a wide contact patch that keeps the robot from sinking into soft sediment.

The Robot

AXIOM D1 came together as six modular subsystems:

  • Locomotion — rubber caterpillar tracks, differential skid-steer, two 12 V DC gear motors.
  • Collection — a servo-actuated front scoop feeding a rubber conveyor belt into a 5 L mesh-drained bin.
  • Cleaning — two 3000 RPM rotary nylon brushes on spring-loaded arms (9.4 m/s tip speed, comfortably above the ~5 m/s threshold for biofilm removal).
  • Sensing — two HC-SR04 ultrasonic rangefinders, an MPU6050 IMU, a resistive water-level sensor, and an onboard camera.
  • Control & comms — an ESP32-CAM running the control loop and serving MJPEG video plus WebSocket command/telemetry over its own local WiFi access point.
  • Power — a 3S2P LiPo pack on a fused, E-stop-protected 12 V bus.

The ESP32-CAM choice mattered. It put a dual-core processor, WiFi, and a camera on a single ~$10 module — Core 0 handles the WiFi stack and video streaming, Core 1 runs the 50 Hz motor control loop and safety interlocks. No internet needed; the operator’s phone connects straight to the robot’s access point.

Simulation First, with Gazebo

Before fabrication, we built a physics simulation in Gazebo Classic 11.15.1, running in Docker. The model was an SDF description of the tracked chassis (400 × 350 × 150 mm, 14 kg) with a differential drive plugin, IMU, and camera. The environment: a 10 m concrete U-channel with shallow water, an algae patch, and three debris objects.

# Launch the sim in Docker
./gazebo_sim/docker_launch.sh

# Drive the robot (inside the container)
./teleop.sh

# Capture IMU + pose telemetry during a run, then plot it
./gazebo_sim/capture_data.sh
python3 gazebo_sim/plot_sim_data.py

The Bug That Justified the Whole Approach

Here’s the moment that made simulation-first worth it.

On the first drive test, the robot wouldn’t move forward. It just oscillated sideways — shuddering left-right instead of translating.

The track links were modelled as cylinders, rotated (0, π/2, π/2) to lie flat along the chassis. I’d given their revolute joints an axis of <xyz>0 1 0</xyz> — the obvious “spin around Y” choice. But after the parent rotation, the cylinder’s spin axis no longer pointed along world-Y in the child frame. The joint was driving the track around the wrong axis entirely.

The fix was a one-line change — <xyz>0 0 1</xyz> to align the joint with the cylinder’s actual axis in the rotated child frame. The robot immediately drove straight.

That’s a mechanical-integration error. In hardware it would have meant a misaligned drivetrain, a confused afternoon with a multimeter, and possibly a re-machined part. In simulation it cost ten minutes and a diff.

What the Simulation Told Us

Once it drove properly, the numbers were reassuring:

  • Velocity tracking — the robot reached a steady-state ~0.14 m/s, about 93% of the commanded 0.15 m/s. The 7% deficit lines up almost exactly with the rolling resistance and hydrodynamic drag we’d calculated by hand.
  • IMU validation — Z-axis acceleration read 9.55 m/s², within 2.6% of true gravity. The X-axis sat at a −2.2 m/s² baseline, which corresponds to a ~6.5° forward pitch — the chassis nose-down from the scoop and conveyor mass. Y-axis stayed near zero, confirming straight-line stability.
  • Differential steering — zero-radius pivot turns executed cleanly within the 450 mm channel width.

Walking the judges through measured simulation data — and showing it matched our hand calculations — was, I think, the difference between a good design and a winning one.

What We Didn’t Solve

Honesty matters in a design report, so it matters here too. The simulation validated locomotion, steering, and sensing — but not collection. The scoop and conveyor are still fixed visual geometry in the model; debris interaction is contact-only (the robot pushes objects, it doesn’t yet collect them).

The next iteration converts the scoop into a proper revolute joint with a collision-bounded bin, so we can simulate the full sequence: tilt down, engage debris, conveyor transfer, deposit. That’s the harder articulation problem, and it’s where the project goes next.

The Stage 1 proposal scored 91/100, and AXIOM D1 went on to take first place overall. The full design report, the Gazebo models, and the simulation telemetry are all on GitHub if you want the deep technical version.

More posts