← MACHINES
[SYSTEMS] running 2026
← CHAPTER 05 / Where should intelligence live?

duburi_ws

SOURCE →
duburi_ws running
CATEGORY
SYSTEMS
ACTIVE
2026
STATUS MATRIX
CONTROL
VISION
PLANNER
MANAGER
SIM

TECH STACK

Python 97%
JavaScript 1%
Shell 1%
CSS 1%
[MEDIA: PENDING]
BRACU Duburi's ROS2 Humble control, mission, and simulation stack for AUV

ARCHITECTURE

YOLO11 + OC-SORTVISIONauv_manager_node/duburi/moveMISSION CLIENTS30+ VERBSBNO085YAW SOURCEPIXHAWK 2.4.8ARDUSUB 4.XNORTEK NUCLEUS 1000DVLJETSON ORIN NANO — DUBURI 4.5 + DUBOMINI 2.0

Problem

A RoboSub vehicle is a pile of sensors, actuators, and computers that have to agree on what is happening and what to do next. Without a common backbone, every subsystem talks its own dialect and the mission logic lives in nobody’s code. Duburi needed a control, mission, and simulation stack that the whole vehicle could run on.

Difficulty

The stack has to hold together three different time scales at once: the control loop that keeps the vehicle stable, the mission logic that decides what to do, and the simulation that has to approximate reality closely enough to be worth trusting. ROS2 Humble is the substrate, but the difficulty is the integration — making the same code run on the real vehicle and in simulation without lying to either.

Built

duburi_ws — BRACU Duburi’s ROS2 Humble control, mission, and simulation stack for AUV. The workspace holds 795 commits (Apr–Sep 2026) across 7 ROS 2 packages with 229 test files, MIT-licensed, and is the only repo with CI (poc-check.yml) and multi-contributor history (fh1m 750 / RakibulIslam1 9). The workspace that ties the vehicle’s control, mission, and simulation together, with topics covering ros2, auv, ardusub, robosub, and robotics.

Owned

The systems layer — the workspace structure, the node graph, and the interfaces between control, mission, and simulation. The part of the stack that has to be boring and correct so the interesting parts can be wrong safely.

Failed

The honest failure mode of a systems stack is that it works in simulation and the vehicle disagrees. That gap — between what the stack says and what the water does — is where most of the real debugging happens. It is a failure that repeats until the simulation stops lying.

Changed

The stack changed how the team develops: instead of testing ideas on the vehicle and hoping, the mission and control logic now live in code that can be run in simulation first. The vehicle became a place to confirm, not a place to experiment.

Machine-now

The stack is running — it is the backbone the current Duburi vehicle runs on, and it keeps the mission logic in one place where the team can actually reason about it.

Lesson

The systems layer is the first machine. If the interfaces between control, mission, and simulation are honest, the vehicle has a chance; if they lie, no amount of clever perception fixes it.