LEVIATHANDocumentation

DOC 01GETTING STARTED

What is LEVIATHAN

LEVIATHAN is a development environment for marine robotics: AUVs, ROVs, surface vessels and hull-working robots. You simulate a vehicle, its sensors and the water it works in, compare what the sensors saw with what was actually there, estimate the vehicle's state, train and grade its behaviour, and bring in firmware and hardware interfaces, all before anything goes in the water.

A work-class ROV hovering among the legs and horizontal bracing of an offshore platform jacket, with the telemetry readout at top left and light caustics on the seabed.
Figure 1.1 A work-class ROV inside the jacket of the Offshore oil rig scene. The platform is a detailed structure model; the telemetry readout reports the vehicle's live depth, altitude, heading and speed.

What it does

LEVIATHAN is organised as a stack, from the world and its physics up to autonomy and hardware. Every layer shares one vehicle model, one ocean and one set of conventions.

  • Vehicle and ocean simulation. Six-degree-of-freedom dynamics for remotely operated vehicles, autonomous underwater vehicles, a surface vessel and a glider. Thrusters, control fins, added mass and damping are modelled, along with currents, eddies, tides, waves and seabed terrain. This is the FAB Engine.
  • Sensor simulation. Optical, acoustic, navigation and oceanographic sensors, from a radiometric underwater camera and a forward-looking imaging sonar to DVL, IMU, USBL, LBL, GPS, CTD and ADCP. See Sensors.
  • Ground truth. The simulator knows what each pixel and sonar cell actually saw. That includes range and depth, surface normals, labels, object identity, how surfaces moved between frames, and which surfaces produced each sonar return. See Perception ground truth.
  • Synthetic data. Captures export as LEVIATHAN native datasets and as COCO, KITTI, depth and optical-flow formats. See Synthetic data and export.
  • Perception algorithms. Classical and learned vision, sonar detection and tracking, and camera–sonar association, each evaluated against ground truth and graded by evidence. See Perception and computer vision.
  • Localization. An error-state Kalman filter that estimates vehicle state from IMU, DVL, pressure, magnetometer and USBL measurements and can drive the controllers in a closed loop. See Localization.
  • Evaluation. A suite of control tasks with stage-attributed verdicts, robustness sweeps and domain randomisation. See Learning and evaluation.
  • Development workspaces. A code editor with terminals and language tooling for your own robot software, alongside hull fouling and cleaning analysis, an electronics harness and firmware bench that runs firmware on an emulated microcontroller, and hydrographic survey processing.

Core capabilities

Table 1.1 What LEVIATHAN provides today, where you use it, and how each part is characterised. The labels are defined in the next section.
AreaWhat existsUsed fromCharacter
Vehicle dynamicsFossen 6-DOF equations of motion, RK4 integration, thruster allocation, fins, surface hydrostaticsViewport, Dashboard, serviceAnalytic Reference-checked
GPU-batched dynamicsThe same equations for thousands of environments in parallel, checked against the CPU modelLearning toolsReference-checked
OceanCurrents with depth shear, eddies, harmonic tides, Airy and JONSWAP waves, wind, seabed grids, sound-speed profiles, seawater absorptionViewport, DashboardAnalytic
ScenesNine built-in scenes with 3D structure models and matched analytic environmentsViewportContent
VehiclesNine built-in vehicles; URDF, SDFormat and MJCF import; CAD hull uploadViewport, DashboardPreset parameters
CameraOpenCV pinhole camera with optional Brown–Conrady distortion, underwater radiometry and per-pixel ground truthViewport → Sensors → CameraCanonical
Imaging sonarSampled forward-looking sonar with a relative-return model, per-cell contributors and validity codes; CPU reference and bit-identical GPU backendSimulation serviceCanonical Reference-checked
Navigation sensorsFour-beam DVL, strap-down IMU, pressure, magnetometer and USBL measured from World snapshots, with optional keyed noiseSimulation serviceCanonical
Other sensorsSide-scan, multibeam bathymetry, USBL, LBL, GPS, CTD, ADCP, pressure, compass, LiDAR, stereo, depth, thermal and event cameras, radarViewport, DashboardAnalytic
Motion and track ground truthSurface correspondence, optical flow, scene displacement, instantaneous motion field, object tracksSimulation service, exportCanonical
Camera–sonar ground truthExact-time contributor ground truth and sonar observability queries between a camera and a sonarSimulation serviceCanonical
Perception algorithmsFeature matching, two-view geometry, visual odometry, depth, detection, segmentation, tracking, flow, restoration, sonar detection and tracking, camera–sonar association, with evaluators and frozen benchmarksPython library, benchmarksGraded per capability
LocalizationError-state Kalman filter on canonical IMU and DVL, with pressure, magnetometer and USBL aiding; estimate-driven closed-loop control on the WorldSimulation service, libraryValidated in simulation
EvaluationTask suites, stage verdicts, robustness bench, domain randomisation, comparison and regressionDashboardAnalytic
Reinforcement learningGymnasium environments, PPO, SAC, TD3 and offline learners, observation and actuator fault modelsScripts and serviceLibrary
HullHull atlas, fouling growth, drag and fuel cost, crawler cleaning plans, simulated inspectionHull workspaceAnalytic
HardwareHarness wiring and checks, PlatformIO project generation, RP2040 firmware emulation against simulated sensorsHardware workspaceEmulation
External interfacesROS 2 bridge, MAVLink / ArduSub SITL connection, OpenUSD scene exchangeDashboard panels, serviceInterface
Code workspaceProjects, file editing, integrated terminals, language servers, project run commands launched as training runsCodeTooling
AccountsOptional or required sign-in, single sign-on, sessions and API keysApplication, serviceTooling
HydrographyCUBE-class gridding, motion and patch-test corrections, tide reduction, survey pipelineDashboard, serviceAnalytic

How capabilities are characterised

LEVIATHAN contains models of very different kinds, and the documentation labels them so that a result can be read correctly.

Table 1.2 Labels used throughout this documentation.
LabelMeaning
CanonicalProduced from an immutable snapshot of the canonical World. Results are content-addressed: the same inputs and seed give the same identity hash, and every channel declares its units and frame.
AnalyticA closed-form or low-order physical model evaluated directly by the simulation service. Fast and broad, with the assumptions stated in each section.
Reference-checkedAn accelerated or alternative implementation tested against LEVIATHAN's own CPU reference. This is agreement between implementations, not validation against real-world measurements.
Validated in simulationTested against simulated truth over seeded, held-out scenarios, including faults and noise. No real-world evidence.
Partial, BaselineWorks in part with a key limit open, or exists with minimal evaluation. Used for perception algorithms.
LegacyStill available for compatibility, but superseded by a canonical product. The page says which product replaces it.
InterfaceAn adapter to external software such as ROS 2 or ArduSub SITL. It works only when that software is installed.
Preset parametersNumbers chosen for simulation, with their provenance recorded. They are not manufacturer-verified specifications unless stated.

Scope

A few boundaries are worth knowing from the start.

  • Simulation is not field validation. LEVIATHAN's models are physically based and tested against closed-form results and its own references. Agreement with a specific real vehicle, sonar or camera is not claimed unless a page reports it.
  • Sonar intensities are relative. The canonical imaging sonar computes a physically modelled return relative to the source. It is not a calibrated received level. See Imaging sonar.
  • Perception performance is demonstrated in simulation. LEVIATHAN includes perception algorithms and training code, but no trained weights ship, and transfer to real imagery has been measured on one dataset only, where it is weak. See Real data.
  • Reinforcement learning and the canonical World are separate. The learning environments run on the analytic and GPU tiers. A vehicle in the canonical World is driven by the built-in controllers, on true or estimated state, not by a trained policy. See System architecture.
  • No mapping or SLAM system. LEVIATHAN estimates vehicle state but does not build maps from it. See Mapping and navigation.

Where to go next