LEVIATHANDocumentation

DOC 01GETTING STARTED

Workflows

LEVIATHAN's workspaces and services are meant to be used together. This page shows how they connect for the common kinds of marine robotics work, and where each step happens.

The general loop

General LEVIATHAN workflowConfigure in Code and the Viewport, simulate, observe and capture, develop algorithms or train, evaluate in the Dashboard, then test with hardware interfaces. Configure Code · Viewport Simulate Viewport · World Observe sensors · capture Develop code · training Evaluate Dashboard Test Hardware · SITL
Figure 1.1 The general loop. Not every project uses every step, and the order is not fixed: evaluation results usually send you back to the vehicle, the sensors or the code.
  1. Open a project

    In Code, open a folder or create a project for your autonomy, perception or training code. A project can declare a run command, which the Dashboard's Training runs panel can launch. See Code.

  2. Choose the environment and vehicle

    In the Viewport, pick a scene from Scene → Ocean preset and a vehicle from Vehicle, or import your own (custom vehicles).

  3. Configure sensors

    Switch on the sensor payload in Sensors. Canonical sensors for ground truth and estimation are declared with the vehicle's catalogue model (Sensors).

  4. Run and inspect

    Watch the vehicle live in the Viewport with telemetry and overlays. For reproducible, tick-exact runs, create a World (Dashboard World panel or service) and follow it in the Viewport.

  5. Capture data

    Capture PerceptionFrames from the Viewport, or capture groups of every scheduled sensor through the service. Export them as datasets (Synthetic data and export).

  6. Run algorithms or train

    Run perception, localization or your own code against the captured data or a live World. Train policies with the learning library or a project run (Learning and evaluation).

  7. Evaluate

    Score results in the Dashboard: task suites, robustness benches, perception grades, navigation-filter error.

  8. Connect hardware

    Bring firmware and hardware in through the Hardware workspace, ArduSub SITL, ROS 2 or the remote device gateway (Hardware, HIL and interfaces).

Specialised workflows

Specialised workflowsSix workflows, each a short sequence of steps through LEVIATHAN. AUV Survey AUV Pipeline or wreck Survey cards Nav filter ROV BlueROV2 Heavy Inspection tasks Camera capture Grade suite Perception Capture frames Ground truth Run algorithm Evaluators Learning Code project Training run Policy export Grade suite Navigation World + sensors Attach ESKF Estimate in loop Score vs truth Hardware-in-the-loop Wire harness Generate firmware Emulated RP2040 Fly the vehicle
Figure 1.2 Six common paths through LEVIATHAN, each read left to right. Table 1.1 lists the parts each one uses in more detail.
Table 1.1 Specialised workflows and the parts of LEVIATHAN each uses.
WorkflowTypical path
AUV developmentTorpedo AUV, REMUS-100-class, HUGIN-class or Hovering AUV in the Pipeline, Shipwreck or Under-Ice scene → survey cards (Side-scan survey, Multibeam bathymetry) and Survey coverage and Mission planning → Nav filter for navigation error → task suites for the Hovering AUV
ROV developmentBlueROV2 Heavy or Work-class ROV → station keeping, inspection and docking tasks → camera capture for ground truth → Hardware bench and firmware emulation → ArduSub SITL with the same hull
Hull-robot developmentThe Hull workspace: hull atlas, fouling and cost, crawler cleaning plans and simulated inspection; the Viewport's Ship Hull scene for in-water views
Synthetic-data generationViewport camera capture → + Sequence → native dataset, COCO or KITTI; capture groups for camera, sonar, DVL and IMU together; motion and flow exports from the service
Perception evaluationGround truth from captures → evaluators for detection, segmentation, tracking, flow, depth and trajectories (Perception and computer vision); the External frames panel to grade predictions made outside LEVIATHAN
Reinforcement-learning trainingA Code project with a run command, or the learning library → Training runs (local, Slurm or dry run) → Policy export → Grade suite, Robustness bench, Compare runs, Regression
Navigation testingA World with a vehicle declaring IMU, DVL and optional pressure, magnetometer and USBL → attach the estimator → run with the controller on truth or on the estimate (Localization)
Hardware-in-the-loopHardware bench → generated PlatformIO project → firmware on the emulated RP2040 flying the simulated vehicle; ArduSub SITL with LEVIATHAN as physics; the ROS 2 bridge for a ROS stack
Where the stack is not joined
  • Learning environments do not run on the canonical World, so a trained policy cannot drive a World vehicle; policies are evaluated on the analytic and GPU tiers.
  • Perception algorithms run from the library and benchmarks, not as Viewport or Dashboard tools, and they do not feed the estimator at runtime.
  • Hardware integration is through emulation, SITL and middleware bridges; LEVIATHAN does not drive vehicle hardware directly.