AZARELThe previous post argued that underwater robots have a real but narrow role after an event like the Nepal floods of August 2026: flooded powerhouse tunnels, new barrier lakes, scoured bridge piers, standing water that has to be searched. It also argued that the limiting factor is almost never the vehicle. It is that nobody has flown one in that water.
That is a training problem, and training problems are what simulators are for. This post is about what a simulator actually has to model before it earns the right to be used that way — including the parts Leviathan does not model yet.
Why the practice cannot happen in the real thing
Ordinary marine robotics has a fallback: go to the harbour, put the vehicle in, try it. Flood response removes that. The water only exists for a few weeks, it is somewhere the road no longer reaches, it is full of things that will destroy a vehicle, and the moment it exists is the moment the work has to already be happening. There is no rehearsal window. Whatever competence the operator and the autonomy have on arrival is all they will have.
Everything else in marine robotics can be learned progressively in benign water and then stretched. This cannot. It is the clearest case we know of for training in simulation, and it is also the case simulators are worst at, because almost all of them were built to model open ocean.
What the scenario actually demands
Turbidity as the default, not a setting
In flood water the camera is not degraded, it is useless. Suspended sediment at those concentrations means the optical payload returns backscatter and nothing else. A simulator that models turbidity as a slider going from clear to slightly murky is modelling a different problem. What matters is the regime past the point where vision stops contributing at all, and whether the autonomy notices and stops relying on it.
Leviathan models water optically with attenuation and scattering, and turbidity is a controllable scene parameter. What we have not done is validate the model at the far end of that range, because the far end is exactly where nobody has good reference imagery. That is an honest gap.
Acoustics carrying the whole navigation load
When vision goes, everything comes from sound: imaging sonar for obstacles, DVL for velocity over ground, and acoustic positioning where a surface unit can be deployed. Each of those degrades in its own way in flood conditions — a DVL loses bottom lock over soft fresh silt, sonar returns get cluttered by suspended material and by debris that is itself moving, and multipath in a concrete tunnel is nothing like multipath in open water.
This is where a sonar model that is honest about its own failure modes matters more than a pretty one. Our multibeam tier produces side lobes, range ambiguity and speckle deliberately, because a perception stack trained on clean synthetic sonar learns to trust returns it should not.
Geometry nobody has surveyed
Every marine environment preset we ship assumes a seabed. A flooded powerhouse has a floor, a ceiling, walls, machinery and an unknown volume of silt that has changed all four. The closest analogue we have already built is the under-ice environment, which is the only one where the vehicle plans against a ceiling as well as a floor. A tunnel is that problem with the ceiling much closer and the walls added.
Current that is going somewhere
Open-ocean current models assume broadly coherent flow. River and tunnel flow is neither coherent nor steady: it accelerates through constrictions, separates around obstructions and reverses in eddies behind them. A vehicle holding station beside a pier is being pushed differently on its port and starboard sides at the same instant. Six-degree-of-freedom dynamics with off-diagonal added mass gets you the vehicle response; the flow field is the part that has to be right for that response to mean anything.
The tether, which is usually what ends the dive
Ask anyone who has flown an ROV in a wreck or a tunnel what actually goes wrong and they will say the tether. In clean water it is a nuisance. In a flooded structure full of rebar and broken machinery it is the primary risk, and it is the reason a vehicle does not come back. We model tethers as lumped-mass cable with seabed touchdown, which is the right machinery for the job, but snag modelling against arbitrary structure geometry is a genuinely hard problem and we do not claim to have solved it.
What you would actually train
Not a fully autonomous flood-response robot. That is not the near-term goal and anyone offering one should be asked hard questions. The realistic targets are narrower and more useful:
- Operator hours. Flying a tunnel on sonar alone, with the tether behaving, before the day it matters. This is the single highest-value output and it needs no autonomy at all.
- Station keeping in unsteady flow. A controller tuned in a harbour will not hold position beside a scoured pier. That can be tuned and tested against a simulated flow field.
- Sonar-only obstacle handling. Stopping for a return the vehicle cannot interpret, rather than driving into it.
- Perception on synthetic acoustic data. There is no labelled dataset of flooded powerhouse interiors, and there is not going to be one. Generated data with per-pixel class labels is the only route.
- Graded practice. A scored task with per-seed results tells a team whether a week of training changed anything, which subjective practice does not.
Why we are writing this down
Leviathan is in development and not generally available. We are not in a position to hand a disaster-response team a tool this week, and the honest thing to say about the Nepal floods is that our software played no part in them whatsoever.
What we can say is that the capability gap in that response is legible from where we sit, and it is not a hardware gap. Vehicles capable of the tunnel and barrier-lake work already exist and are affordable. What is missing is the hours, the trained perception, and the confidence to send a vehicle somewhere nobody has flown one before. Those are simulation problems.
If you work on disaster response or riverine robotics and think this framing is wrong — particularly if you have flown in conditions like these and we have mischaracterised them — we would rather hear it than not. hello@azarel.com.
Previously