Mongla. মোংলা

Everything down here fights you.

Not as a metaphor. Each line is a force acting on a decision the software has to make, and each one is why some ordinary technique does not survive contact with the medium.

[ clear ][ murky ]

“For a successful technology, reality must take precedence over public relations, for nature cannot be fooled.”

Act one // where it learned

It learned most of what it knows from losing to water.

Mongla began as the autonomy software for a university AUV programme. It flew on that programme's vehicles. The vehicles, the team and the name stayed there; the software, and everything it had been taught, came here.

“A ship in port is safe, but that is not what ships are built for.”

Act two // opening the box

The fast loop lives where it belongs.

A companion computer cannot hold an attitude: it sits on the far side of a cable, answering at whatever rate it can manage. So the reflexes live on a board we write the firmware for, and the Pi is left to do nothing but think.

What actually crosses the cable

If the reflexes live on the board, the Pi should have almost nothing to say — and it doesn't. Here is the whole of move_forward, the most ordinary thing the vehicle is ever asked to do, exactly as it leaves the Pi. Read it left to right, the way the board does.

The first ten bytes are the envelope: where a frame starts, how long it is, who sent it, what kind of message it is. The part that means anything is three numbers — a type, a duration, a speed — and one tag that says “this is ours”. There is no thrust in it. No motor, no angle, no depth. Which thrusters spin, how hard, and how the hull holds its heading for those three seconds is the board's business; the Pi only said what it wanted.

“A complex system that works is invariably found to have evolved from a simple system that worked.”

Two long reads // the same argument, at full length

If this page is the tour, these two are the rooms.

One explains why the vehicle is split the way it is, from first principles and with no assumed background. The other lists every capability with the file or the measurement behind it, and refuses to hide the rows that are blocked. Both previews below are generated from those documents, so neither can quietly drift from what it is advertising.

A capability map that hides the blocked rows is marketing.

Play with it // the loop, in your hands

What a control loop is, if you have never written one.

A controller is a machine that answers one question, over and over: I am here, I want to be there — how hard do I push? Below is a toy hull with one axis of heading. Turn the three knobs and watch it fail in the three classic ways. Nothing here is our vehicle: it is a simulation with made-up numbers, so that the shapes are honest even though the values are not.

A controller is not clever. It is patient, five hundred times a second.

The body // 702 mm, five thrusters, one uncontrolled axis

A red machine, lit by the water it has to survive.

Drag it to turn it; take it apart with the fader, or jump to a stop. Every number below was read off the CAD geometry itself — 84,248 triangles at 0.9 mm tessellation, measured rather than quoted.

Every one of these is rendered at 2800 px from the same 84,541-triangle mesh the interactive model uses, with each part carrying its own material colour straight out of the CAD. Nothing here is a photograph, and nothing here is an artist's impression.

What the geometry says

A shell mesh cannot answer the buoyancy question, and it would be easy to pretend otherwise: the enclosed volume of this model is 1.77 L, which is the surface and not the displacement. Using it would repeat a mistake this project has already made once, and written down. The geometry here is read straight out of the CAD by pack_hull.py, which is also what builds the model above.

Every number on this hull was read off the geometry. The ones that could not be read — mass, buoyancy, drag — are left blank, not guessed.

Play with it // when the vehicle cannot do what it was asked

Ask for more thrust than exists, and the vehicle does something you never asked for.

"Forward, a little left, and turn" is three numbers. The vehicle has four horizontal thrusters, each of which can only give so much. When the sum of those demands exceeds what a motor can deliver, something has to give — and the choice of what gives is a design decision most people never make on purpose. Make the wrong one and a vehicle asked to go straight quietly turns instead.

Saturation is where a vehicle stops doing what it was told and starts doing arithmetic.

The suite // three repositories, one wire

Mongla is the soul. It does not own the body.

Four repositories, two authors, and a rule that is easy to state and hard to keep: we never commit to theirs, they never commit to ours. Anything missing at the low level is a pull request, not a workaround on our side.

“One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.”

Play with it // four switches, one observable

Only the product is visible. Two wrongs look exactly like a right.

Between "turn left" and the water there are four independent places a sign can be flipped: the axis convention the host writes, a firmware parameter that negates every axis before the mixer, a firmware revision that changed what positive yaw means, and the direction each motor was told it spins. You can only ever observe their product — which way the hull actually went. Every one of these has been wrong on this vehicle at least once, and the register of that is in BUGS.md.

Perception to propulsion // one frame, all the way down

From a photon to a thrust, in ten stops.

Follow one frame from the moment light reaches the lens to the moment a propeller should turn. Every stop carries the number measured there and the file that does the work — and the last two carry the honest word for what has not been measured yet.

Ten stops, and the only one we could not measure is the last: the water pushing back.

Play with it // one cable, and what fits down it

Telemetry is free until it isn't, and then it takes the heartbeat with it.

Everything the board says crosses one USB-C cable at 115 200 baud — about 11 520 bytes a second once the start and stop bits are paid for. Today the link runs at a measured 18.8 % of that. The temptation, always, is to add "just one more" stream; the cost is not that the new stream is slow, it is that everything already on the wire starts queueing behind it — including the heartbeat the board uses to decide whether anyone is still there.

The safety chain // what stops the vehicle, and what does not

Eight links between a mistake and a hull on the bottom of the pool. One of them is missing.

A vehicle is not made safe by one clever guard. It is made safe by a chain of dull ones, each owned by a different part of the system, each catching a failure the others cannot see. Pick a failure below and watch which link takes it. The chain is drawn as it is configured today — including the link that is switched off and the one that cannot tell two different states apart.

Safety is not the guard that catches everything. It is knowing exactly which failure each guard will not see.

One task // thought through, start to finish

What actually happens when it is told to pass a gate.

Not pseudocode and not a flowchart of boxes. This is the real sequence, with the real rates, and with the places it is allowed to give up marked as clearly as the places it succeeds.

Read that column on the right again. Every row has one, and that is the design: a verb that reports success while the vehicle does nothing is the failure mode that ends competition runs, so nothing in this stack is allowed to be quietly optimistic. The ladder ends in a refusal, not in a confident invention.

“Computing science has very convincingly shown that simplicity is a necessary precondition for reliability.”

A run, from the inside // what it sees, believes and does

Ride along inside Mongla's head for one run.

Three panes, one clock. On the left is the forward camera as the detector sees it. In the middle is what the vehicle believes — its own position, the course it was told about, and how sure it is. On the right is what it decides to do about that. Nothing here is a cartoon of the pipeline: the rates, the detection gaps, the lock ladder and the refusals are the measured ones, and the narration is a sentence the code could actually have produced.

The vehicle is never confused. It is specific about what it does not know — and that is the whole difference.

Continuity // when the detector blinks

The target does not leave. The detector does.

A neural detector on real underwater footage drops the box constantly — a reflection, a bubble, a bad angle. If control trusts only the detector, the vehicle loses a lock it never actually lost. So there is a ladder, and each rung is allowed to be wrong for a measured length of time.

The third row is the one worth staring at. Through a gap of 175 frames the detector produced nothing at all, and the vehicle still knew where the target was — because the anchor matches image structure rather than asking the network again. The fourth row matters as much: the ladder ends in a refusal, not in a confident invention. The rungs and their timeouts are described in detection-continuity.md.

A lock is a promise about the target, kept through the moments the detector cannot see it.

Play with it // the lens the water grinds for you

Water takes a third of the picture, before the first pixel is read.

A camera's field of view is a property of the lens, and every datasheet states it for air. Put the same camera behind a flat window in water and the number is simply no longer true: rays bend as they cross the glass, the cone narrows, and the edges of the world quietly leave the frame. Nothing warns you. The image is still sharp, still centred, still the same 640 pixels wide — it just contains less world.

Play with it // the sensor we could not buy

A camera pointed at the floor is a speedometer, if you know one number.

A Doppler velocity log is the instrument that tells an underwater vehicle how fast it is moving over the ground. We do not have one. What we have is a camera pointed down, and the fact that the floor slides past it — but the same pixel motion means a different speed depending on how far away the floor is.

That last row is the result worth keeping. Height is recovered independently, from h · truth / measured, and the three runs land on 0.72, 0.69 and 0.70 m against a tape that says 0.72. The scale chain closes on itself — which is the only reason to believe the speed at all.

The floor was always there. It only became a sensor when we knew how far away it was.

Play with it // the correction that arrives from the past

Every measurement is a statement about a moment that has already gone.

A camera exposes a frame, the Hailo-8 finds a prop in it, the result crosses two processes and lands in the filter — and by then the vehicle has moved. The fix is perfectly correct about where the vehicle was. Apply it to where the vehicle is and you have just pulled the estimate backwards in time, on purpose, at speed.

The simulator // 20,649 lines, thirteen courses, one purpose

A place to be wrong that costs nothing.

A second colcon workspace inside this repository: Gazebo, both competition pools, thirteen courses, both cameras, ground truth, and an operator lab. It is not a demo. It is where every recovery path in the stack got run for the first time, because a pool day is four hours long and a bug is cheaper here.

A simulator is where you are allowed to be wrong cheaply — which is only worth anything if you remember it is not the water.

The rehearsal // 4,925 synthetic frames, and the stack run over them

First, we rehearse in water we built.

Everything in this section is synthetic — frames rendered by our own simulator, scored by a detector trained on simulator imagery. It is a rehearsal, and calling it anything else would be the exact mistake this project exists to refuse. What it does prove is that the pipeline runs end to end: the true detections are handed to the same render_ui_strip() the vehicle draws with, so the operator display below is real even though the water is not.

And the honest half: across the thirteen sessions, two returned no detections at all under these weights — they are a different course with a different class set. That is a fact about the model, not about the water, and it is here because a showcase that only shows the frames where the detector performed is a showcase of nothing.

Every session carries its own meta.json, its class list, ground-truth labels from the simulator's bounding-box sensor, and the video it came from — 27 classes across both competitions.

Clean water teaches you the shape of the task. It teaches you nothing about the task.

The water // three venues, real weights, real footage

Then we find out what the water was actually like.

These are photographs. The weights are the ones trained during the 2025 season; the frames come from the 20 GB archive recorded at a pool in Mirpur and at RoboSub in Arizona. Six scenes, 3,345 real frames scanned, every frame chosen by searching its folder for the richest one — never picked by hand.

Look at the third one. The machine is not finding "a bin" — it is reading the sawfish and the shark printed on the two openings, bin_shaw_fish and bin_shark, both at 0.84. Which opening you drop into is the whole task, and that distinction is what a season was spent teaching it.

Mirpur and Arizona are not the same problem. One is hazy and even; the other is bright, with caustics that sweep the floor and look exactly like motion. A threshold tuned in one is wrong in the other — which is why every number in this stack carries the conditions it was taken under, and why the simulator above bothers to model caustics at all.

The archive is 20 GB and stays out of this repository. What ships is six stills and a manifest.json naming the exact source frame behind each one, so any figure here can be re-derived with one command.

The real footage did not make the detector look worse. It made our assumptions look worse.

Retractions // kept on purpose

The results we had to take back.

The measurement ledger holds 107 entries and 821 rows of numbers. 18 of those entries say, in their own title, that they took an earlier result back; 7 more measured an idea and the answer was to leave it off. They are kept where anyone can read them, because a project that quietly deletes its wrong answers is a project you cannot check. The full ledger is here.

“It doesn’t make any difference how beautiful your guess is… If it disagrees with experiment, it’s wrong.”

Instruments // every number with where it was taken

If it is not measured, it does not ship.

Each of these lives in a ledger with its method, its conditions and the bar it had to clear — and the tests read that file, so a number cannot drift away from the measurement that produced it without something going red.

A number without its method is a rumour.

The language // how a machine is asked to do something

A mission should read like an instruction, not a state machine.

One action, thirty verbs, two vision primitives. The vision verbs never raise — they return where and how they finished, so a mission branches on reality instead of on an exception.

# hold station on the target, then fire mid-hold — still correcting
res = mongla.vision.align(
    'hole', lat=0, yaw=0,     # centre it: signed px from frame centre
    fwd=62, fwd_mode='area',  # and hold this standoff
    hold=4.0, fire=[1, 2],    # two shots, spaced, each gated on a NEW frame
    lock_on=True, brake=False,
)

if not res.saw_target:        # never read x_px before this — NaN < n is silently False
    return search_pattern(mongla)
if res.x_px > 0:              # it ended right of centre, so recover right
    mongla.move_right(duration=0.6)

The comment on the eighth line is the whole philosophy compressed: a result that is absent must never be mistaken for a result that is zero. The full verb table is in command-reference.md; what a vision verb hands back is in vision-results.md.

A mission that cannot say what went wrong is a mission that cannot recover from it.

The last idea // and the one nobody writes down

The vehicle has no present tense. It has a stack of pasts, and it steers on all of them.

Every number the controller uses is a statement about a moment that has already gone, and each one is a different moment. The attitude is two milliseconds old. The depth is ten. The detection is eighteen at best, and during a gap it can be four seconds. Nothing in the code declares this — there is no variable called now to be wrong. The vehicle simply acts, at 500 Hz, on a picture assembled from clocks that never agreed.

Shoulders // ten voices, and the instrument each one moved

Every idea borrowed here shows up as a reading on this vehicle.

A list of influences is a bookshelf. This is a dive: each voice sits at a depth, and choosing one lights the instrument in this vehicle that it changed — with the number that instrument shows today. If an idea did not move a reading, it has no business on the page.

Further // where to go if any of this caught you

The reading behind it.

This page is one project's answer. These are the places the questions came from — and the places to go if you would rather build your own answer than read mine.

• The whole of this stack, in source

  Every number on this page traces to a file in it

  github.com/fh1m/mongla_ws

• The architecture from first principles

  Written for someone who has never seen a flight controller

  The Shift

• What is proven, and how

  Every row carries its evidence and a state — in water, on a bench, in software, blocked

  Capability map

• The firmware, the board, the ground station

  Rakibul Islam's work — the other half of the machine

  srot-control-board · srot-ground-station

• The competition this is aimed at

  The rulebooks are the specification every prop in the simulator was built from

  RoboSub · SAUVC

• Why a neural detector is a component, not an oracle

  The essay that reframes the model as something you shape rather than write

  Software 2.0

• How to think about latency at all

  Carmack, on treating every stage as somewhere to claw milliseconds back

  Latency Mitigation Strategies

• Estimation on a manifold, properly

  Barrau & Bonnabel, 2014 — the filter this stack's localization is built on

  The invariant EKF as a stable observer

• The same idea, made to walk

  Hartley, Ghaffari, Eustice & Grizzle — the clearest worked application of it

  Contact-aided invariant EKF

• Why the robot should not be clever

  The argument for deleting before adding, from someone who does it in public

  Hotz on complexity

And if you are building one of these yourself: the single most useful thing in this repository is not any algorithm. It is measured-bars.md — every shipped constant with the measurement that produced it, the conditions it was taken under, and the bar it had to clear. The entries that take a number back sit in the same file as the ones that stand. That file is the project.

“The first principle is that you must not fool yourself — and you are the easiest person to fool.”

Act three // open

Nothing here has been in water yet.

The honest list of what stands between this and a vehicle that swims:

1. The board's depth loop has never run closed two armed bench checks, then waterwater
2. Thruster health cannot tell eight healthy motors from none the firmware already computes it and drops it one line earlyone-line merge
3. Moves by measured distance are refused no such primitive on the board; refused before dispatch, never fakedpull request
4. The board cannot yet accept a velocity measurement we have one, good to 1.09 cm over 30 cm, and nowhere to send itpull request
5. The competition radio cannot reach through an aluminium hull an external antenna, not a software fixhardware
6. Three of five thrusters are populated in the CAD and the firmware's mixer is written for eighthardware
7. No mission has been flown on this platform every number on this page says bench, footage, or boardwater

None of that is hidden, because a capability map that promotes bench results to flight results is how a team finds out at the venue. The live list is ROADMAP.md — one status file, so it cannot disagree with itself.

I left on principle, and I am building this on hope rather than optimism. Hope is the decision to keep working on the better version of a thing while the current version is still broken. Pushing a technical limit is the most concrete form of that I know: every measurement that came back worse than expected is a small argument that the world is knowable, and that the next version can be better than this one.

The next act is open // the machine is still being built