Pith. sign in

REVIEW 4 major objections 6 minor 1 cited by

PyGemini: Unified Software Development towards Maritime Autonomy Systems

T0 review · 4 major / 6 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read PyGemini's claim: one configuration file can specify a maritime autonomy application and act as its automated acceptance test.

desk verdict PyGemini is a genuinely useful maritime autonomy framework with a real integration story, but its CDD acceptance testing is golden-master regression, not requirement verification, and the paper overmarkets it. read the letter →

arxiv 2506.06262 v1 pith:XQZQPS3C submitted 2025-06-06 cs.RO cs.SEcs.SYeess.SY

Kjetil Vasstein , Christian Le , Simon Lerv{aa}g Breivik , Trygve Maukon Myhr , Annette Stahl , Edmund F{o}rland Brekke This is my paper
classification cs.ROcs.SEcs.SYeess.SY
keywords maritimeautonomyConfiguration-DrivenDevelopment(CDD)Entity-Component-System(ECS)Behavior-Driven(BDD)containerizationautonomoussurfacevesselssimulationandvalidationdataaugmentation
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

PyGemini argues that maritime autonomy development is fragmented across incompatible tools for simulation, communication, and monitoring, and that this fragmentation blocks the assurance cases insurers and regulators demand. The paper's central proposal is Configuration-Driven Development (CDD): an application is defined entirely in a declarative configuration file written in the vocabulary of an Entity-Component-System architecture, and that same file doubles as the application's automated acceptance test, so user intent stays embedded in the software lifecycle. If CDD works as claimed, researchers and engineers get a unified, Python-native toolchain where defining an application and getting its regression tests are the same act, with every contribution to the open repository growing the pool of ready-made, tested applications. The paper demonstrates the approach through a suite of maritime tools, including 3D scene generation, scenario generation for autonomy validation, and generative pipelines for image augmentation.

What carries the argument

The central object is the configuration file as a triple-use artifact: it is the build specification, the user entry point, and the acceptance test. The file is written in ECS vocabulary, with commands that create entities, attach components with attribute values, and wire processors that move data between components, and it may include initializer functions that fetch large assets such as meshes or Gaussian splats. The test system works by hashing the binary data of every component attribute on every entity at every iteration with SHA-256, logging only changed states, so an acceptance test is a small, reproducible snapshot suited for version control. The load-bearing move is that these hashed states define user requirements satisfied: unchanged hashes mean nothing affecting the user has changed, while changed hashes force the developer to decide whether the change is intentional (update the test with the user) or a bug (fix it before merging).

What would settle it

Record a baseline application state from a configuration that contains a deliberately wrong behavior, for example the lidar simulator with an erroneous beam equation that systematically under-reports returns, and submit it as the acceptance test. Running the test suite will pass, because the buggy output is the reference state; this would demonstrate that CDD enforces regression against the recorded run rather than satisfaction of the user's actual requirements.

Watch

Extended reading notes

Core claim

On its own terms, the paper claims that Configuration-Driven Development makes maritime autonomy software modular, maintainable, and scalable by fusing three established ideas: Behavior-Driven Development (which aligns users and developers around a shared language), Entity-Component-System architecture (which composes behavior from independent data and logic units), and containerization (which makes deployments reproducible). The ubiquitous language of BDD is realized as configuration files that declaratively list the entities, components, processors, and initializers of an application; these files are simultaneously the specification of what is built, the entry point for new users, and the user requirement against which the code is tested. When a user submits the configuration as an acceptance test, PyGemini records the SHA-256 hash of every component attribute on every entity at every iteration, so any change to the application's state after a code update flags a potential breaking change for the developer. The paper further shows that the ECS data layout lets processors be swapped to modulate simulation fidelity without touching component data, allowing the same application to run headless in the cloud or with full visualization locally.

Load-bearing premise

The acceptance test treats a SHA-256 snapshot of the application's recorded state as the definition of requirements satisfied, so it can only prove that behavior has not changed since the recording, and it cannot catch requirements that were never correctly implemented in the first place.

Editorial extensions

If this is right

  • A contributor can submit a new configuration file with its back-end code; once approved, that file becomes both a ready-made example for new users and a permanently enforced acceptance test, so each contribution increases the repository's tested surface.
  • Because acceptance tests are hashed application states, they are small enough to live in version control and run in continuous integration, giving maritime autonomy projects regression testing without a separate test-authoring step.
  • The same configuration can run stand-alone, as a cloud service, or embedded as a library, and processors near leaf nodes can be commented out or swapped to change sensor fidelity, such as disabling a debug camera for headless cloud deployment, without altering component data.
  • Processor reuse across applications, with a shared set of rendering, trajectory, and rosbag processors serving most of the demonstrated tools, means new maritime applications inherit tested building blocks rather than duplicating code.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The core CDD idea is not maritime-specific: the paper states that it should transfer to aerospace, robotics, and smart infrastructure, and that transfer is plausible precisely because the mechanism, a declarative specification doubling as a regression test, depends only on the ECS data layout and not on any vessel-specific component.
  • The hashed-state test guarantees change detection, not correctness: a requirements violation present in the original recorded run will keep passing forever, so pairing CDD with external verification, such as the contract-based assurance approaches the paper cites, would be a natural next step that the paper leaves implicit.
  • A testable extension would benchmark the claimed performance advantage: measuring end-to-end throughput of a GPU-intensive sensor pipeline, camera plus lidar, under PyGemini's shared-memory ECS design versus a message-passing platform like ROS would settle whether the data-oriented design actually removes the CPU-GPU transfer bottleneck the paper asserts.
  • The fidelity-modulation mechanism, swapping processors while preserving component data, could be validated quantitatively by comparing downstream task performance, for example target-tracking metrics, across renderers of different fidelity, a comparison the paper motivates but does not run.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. The paper introduces PyGemini, a Python-native, permissively licensed framework for maritime autonomy development built on an Entity-Component-System (ECS) architecture. Its central contribution is a proposed Configuration-Driven Development (CDD) process in which declarative configuration files define application behavior and also serve as acceptance tests, combining ideas from Behavior-Driven Development (BDD), data-oriented design, and containerization. The authors demonstrate the framework through several use cases: 3D Gaussian Splatting reconstruction from images and rosbags, interactive trajectory planning, target tracking simulation, image rendering, automatic image labeling, and generative image augmentation. The paper compares PyGemini qualitatively with existing platforms and engine extensions, presents processor-reuse tables, and discusses limitations and future work.

Significance. If the CDD mechanism worked as claimed, the paper would offer a genuinely useful open-source systems contribution: a unified, Python-native toolchain that bridges simulation, data generation, and validation for maritime autonomy. The framework demonstrably runs, and the use-case figures show real outputs from 3DGS reconstruction, lidar-based tracking, and diffusion-based augmentation. The openly licensed asset repository and the emphasis on reproducible containerized deployment are concrete strengths. However, the central novelty, CDD as a requirements-enforcing fusion of BDD and ECS, is currently supported only by a self-referential golden-master test mechanism. The paper's broader claims about maintainability, scalability, and unmatched development experience are asserted rather than measured. With a reframed or strengthened evaluation, the framework could still be a valuable platform paper; as written, the load-bearing methodological claim needs substantial revision.

major comments (4)
  1. [Section III-D] The acceptance-test mechanism is a golden-master snapshot, not a requirements check. The test records SHA-256 hashes of every component attribute for every entity and iteration (Table II) and compares future runs against this recorded state. Any bug or unmet requirement present at recording time is frozen into the expected state and will pass indefinitely; for example, a processor that never updates the Time component would produce a stable, self-consistent state that passes. Consequently, the statement that 'if all acceptance tests succeed, there have been no changes in the code that would affect user requirements' is not supported. This also severs the claimed connection to BDD (Section III): BDD executable specifications encode desired behavior independently of the implementation, whereas here 'requirements' are defined as whatever the current code happens to produce. To support the CDD claim, the paper must either describe an independent oracle for the acceptance criteria or explicitly reframe the mechanism as regression testing rather than requirements enforcement.
  2. [Sections IV and V.C] The maintainability and scalability claims are supported only by Table III (processor reuse) and qualitative narrative. There is no comparative evaluation against ROS, OSP, or game-engine extensions, no user study, no effort or complexity metrics, and no benchmark of configuration-file growth. The statement in Section V.C that PyGemini offers a 'development experience unmatched by current alternatives' is an unsupported assertion. Please add a quantitative or structured comparative evaluation, or temper the claims to describe observed internal reuse rather than an unmatched experience.
  3. [Sections V.A and V.E.1] The claimed performance advantages of 'GPU-GPU data pipelines' and 'shared-memory communication' are not measured. Table I marks these as present for PyGemini, but the only evidence offered is the use of Python libraries such as PyTorch and NumPy. The paper itself concedes in Section V.E.1: 'Despite PyGemini's design allowing for faster communication and use of libraries that can optimize performance, this has yet to be shown.' A benchmark comparing PyGemini's data throughput with ROS message passing, or an explicit statement that these are architectural capabilities rather than measured performance, is needed to avoid overstating the comparison in Table I.
  4. [Section IV.B] The claim that adding rosbag data 'significantly improve[s] SfM performance' and increases registered images from 18% to 81% is presented without the experimental setup needed to evaluate it. No details are given about the dataset, the number of sequences, the baseline method, or the variability across runs. Since this is one of the few quantitative results in the paper, it should be either fully documented or clearly labeled as a single illustrative observation.
minor comments (6)
  1. [Abstract and Section I] The phrase 'new novel Configuration-Driven Development' is redundant; also 'we presentPyGemini' is missing a space. These should be corrected.
  2. [Section II.C] The sentence 'In addtion of providing reprodusability across divserse system' contains several typos and is grammatically incomplete; it should be rewritten, e.g., 'In addition to providing reproducibility across diverse systems, containerization with Docker creates unified work environments...'.
  3. [Table I] The table would benefit from an explicit legend for the check-mark/red-green color coding and for the asterisk footnote. In the PDF, the colors convey meaning, but the table should be readable without color.
  4. [Section IV.E.2] The phrase 'several concepts' is vague; it should be clarified which concepts are novel versus standard, since the rest of the subsection describes well-known software-engineering principles.
  5. [Section V.D.4] The limitation about configuration complexity is acknowledged, but the proposed future work (linting, autocompletion, schema-aware plugins) could be described as a near-term requirement rather than future work, because without schema validation the CDD workflow's usability at scale is in question.
  6. [Appendix A] The lidar simulation equations are presented clearly, but the link between the radar equation and lidar intensity should be explained more carefully, as the paper refers to 'the radar equation' while applying it to lidar; a sentence justifying this analogy would help.

Circularity Check

1 steps flagged · score 6.0 of 10

CDD acceptance tests define 'user requirements' as the application's own hashed output, so requirement validation is self-comparison, not BDD.

  1. self definitional [Section III-D (Test system), with the requirements-as-acceptance-tests claim in Section III (intro bullet list) and CDD workflow step 5 in Section III-E.]
    "After a user is satisfied with their application, the configuration file can optionally be submitted as an acceptance test ... From PyGeminis standpoint, the configuration now becomes user requirements that must be met for any future update ... The test is generated by logging binary data from every component attribute on every entity for every iteration in the application ... If all acceptance tests succeed, there have been no changes in the code that would affect user requirements specified by the configuration files."

    By construction, the acceptance test's expected state is an output of the very application under test: 'user requirements' are defined as the hashed component-attribute state recorded from a previous run of this same code. 'No changes in the code that would affect user requirements' therefore reduces to 'current output equals the code's own past output.' The oracle is self-generated, with no independent specification consulted, so this is a golden-master change detector rather than a BDD-style requirements verification. Any behavioral bug present when the state was recorded (e.g., a processor that never updates Time, a tracker that ignores measurements) is frozen into the 'expected' baseline and passes indefinitely; the test cannot falsify the baseline itself.

full rationale

PyGemini's headline novelty is CDD: configuration files 'serve as user requirements to PyGemini, manifested as acceptance tests' (Section III). The acceptance-test mechanism (Section III-D) defines those requirements as the hashed application state recorded from a run of the application itself, so verifying that 'there have been no changes in the code that would affect user requirements' means comparing current output with the code's own past output. That is a self-generated oracle and a genuine self-definitional reduction: the target property (requirements satisfied) is defined in terms of the measured quantity (application state). A baseline bug is frozen into the expected state and passes forever. The paper partly acknowledges the fragility in its failure-analysis bullet ('the user's requirement was based on false premises') and in Section V-E4 ('the test system can detect which components are affected by changes, but it offers little insight into the origin of bugs'), but no independent oracle is ever described, so the BDD claim is not rescued. Other potential circularity items were examined and rejected: the Autoferry Gemini lineage citations are background context and not load-bearing; the lidar intensity model (Appendix A) imports standard, parameter-free physics from external references (Gaussian beam divergence, radar/lidar equation, Lambertian and Oren-Nayar BRDFs); the empirical claims (e.g., registered-image percentage rising from 18% to 81% with rosbag priors) are external observations; and the ECS/container architecture plus the 3DGS, inpainting, and tracking use cases stand on independent engineering content. Because the circular reduction affects the paper's central novelty claim while substantial independent content remains, the score is 6: partial circularity with a constructionally forced 'prediction'.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

No fitted values are introduced; the numbers in the configuration example and lidar model are illustrative or inherited from cited equations. The main assumptions are engineering choices in the design of CDD: state-snapshot testing, ECS as a maintainability mechanism, and portability via containers. The paper introduces no new physical entities.

assumptions (4)
  • ad hoc to paper SHA-256 hashed component-state snapshots are a valid proxy for user requirements
    Section III-D defines acceptance tests as logged binary states of every component attribute; the test passes only if the new state matches. This treats exact state reproduction as necessary and sufficient for requirement satisfaction.
  • domain assumption ECS composition provides modularity and maintainability for maritime autonomy applications
    Section III-A adopts the ECS paradigm and Section V-C states it promotes maintainability; this is an engineering assumption from game development, not demonstrated by measured outcomes.
  • domain assumption Containerization and Python-native bindings give portability across local, cloud, ROS, and headless environments without performance bottlenecks
    Section IV-H and V-A argue this; shared-memory and GPU-GPU gains are asserted, not benchmarked.
  • standard math Lidar intensity model uses cited Gaussian-beam divergence, radar equation, and BRDF formulas
    Appendix A applies equations from [29], [63], [64], and [65]; assumed correct as cited.

how reviews work

0 comments
Cite this review

Pith. "Pith review of PyGemini: Unified Software Development towards Maritime Autonomy Systems." pith.science (2026). https://pith.science/paper/XQZQPS3C

@misc{pith2026250606262,
  author       = {Pith},
  title        = {Pith review of: PyGemini: Unified Software Development towards Maritime Autonomy Systems},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/XQZQPS3C}},
  note         = {Machine review of arXiv:2506.06262}
}
read the original abstract

Ensuring the safety and certifiability of autonomous surface vessels (ASVs) requires robust decision-making systems, supported by extensive simulation, testing, and validation across a broad range of scenarios. However, the current landscape of maritime autonomy development is fragmented -- relying on disparate tools for communication, simulation, monitoring, and system integration -- which hampers interdisciplinary collaboration and inhibits the creation of compelling assurance cases, demanded by insurers and regulatory bodies. Furthermore, these disjointed tools often suffer from performance bottlenecks, vendor lock-in, and limited support for continuous integration workflows. To address these challenges, we introduce PyGemini, a permissively licensed, Python-native framework that builds on the legacy of Autoferry Gemini to unify maritime autonomy development. PyGemini introduces a novel Configuration-Driven Development (CDD) process that fuses Behavior-Driven Development (BDD), data-oriented design, and containerization to support modular, maintainable, and scalable software architectures. The framework functions as a stand-alone application, cloud-based service, or embedded library -- ensuring flexibility across research and operational contexts. We demonstrate its versatility through a suite of maritime tools -- including 3D content generation for simulation and monitoring, scenario generation for autonomy validation and training, and generative artificial intelligence pipelines for augmenting imagery -- thereby offering a scalable, maintainable, and performance-oriented foundation for future maritime robotics and autonomy research.

Figures

Figures reproduced from arXiv: 2506.06262 by the authors.

Figure 1
Figure 1. Typical layer setup in platform-based systems. Platform and applica [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Example of a PyGemini configuration file to the left, and the resulting data pipeline to the right. Regular rectangles are components, while rounded [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figure 3
Figure 3. Flowchart illustrating the Configuration-Driven Development process [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗
Figures from the paper (10 more)
Figure 4
Figure 4. Figure 4: Overview of processes involved in creating a 3DGS model from [PITH_FULL_IMAGE:figures/full_fig_p008_4.png]
Figure 5
Figure 5. Figure 5: Generated 3DGS models of maritime vessels. [PITH_FULL_IMAGE:figures/full_fig_p009_5.png]
Figure 6
Figure 6. Figure 6: Overview of "3DGS from images" service (upper) and it’s improve [PITH_FULL_IMAGE:figures/full_fig_p010_6.png]
Figure 7
Figure 7. Figure 7: An overview of the Scenario Generation module. The Trajectories [PITH_FULL_IMAGE:figures/full_fig_p010_7.png]
Figure 8
Figure 8. Figure 8: Target tracking scene in Open3D making use of the lidar measure [PITH_FULL_IMAGE:figures/full_fig_p011_8.png]
Figure 9
Figure 9. Figure 9: Top to bottom: A scenario visualized in various formats and [PITH_FULL_IMAGE:figures/full_fig_p011_9.png]
Figure 10
Figure 10. Figure 10: Automatic bounding box generation for target boats from a 3DGS [PITH_FULL_IMAGE:figures/full_fig_p012_10.png]
Figure 11
Figure 11. Figure 11: Overview of the Stable Diffusion pipelines in PyGemini. [PITH_FULL_IMAGE:figures/full_fig_p012_11.png]
Figure 12
Figure 12. Figure 12: Higher-order data pipelines showcasing how the applications can [PITH_FULL_IMAGE:figures/full_fig_p013_12.png]
Figure 13
Figure 13. Figure 13: Lidar simulation with emitted intensity values and lidar textures for [PITH_FULL_IMAGE:figures/full_fig_p018_13.png]

Discussion (0). Sign in to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Viser: Imperative, Web-based 3D Visualization in Python

    cs.CV 2025-07 accept novelty 5.0 of 10

    The paper describes Viser, an open-source imperative, web-based 3D visualization library for Python with scene and GUI primitives.

Reference graph

Works this paper leans on

68 extracted references · 48 canonical work pages · cited by 1 Pith paper

  1. [1]

    Modular assurance of an Autonomous Ferry using Contract-Based Design and Simulation-based Verification Principles,

    J. A. Glomsrud, S. Kemna, C. Vasanthan, L. Zhao, D. McGeorge, T. Arne Pedersenet al., “Modular assurance of an Autonomous Ferry using Contract-Based Design and Simulation-based Verification Principles,”Journal of Physics: Conference Series, vol. 2867, no. 1, p. 012043, oct 2024. [Online]. Available: https://dx.doi.org/10.1088/ 1742-6596/2867/1/012043

    work page 2024

  2. [2]

    Towards contract-based verification for autonomous vessels,

    T. R. Torben, Ø. Smogeli, J. A. Glomsrud, I. B. Utne, and A. J. Sørensen, “Towards contract-based verification for autonomous vessels,” Ocean Engineering, vol. 270, p. 113685, 2023. [Online]. Available: https://www.sciencedirect.com/science/article/pii/S0029801823000690

    work page 2023

  3. [3]

    Autoferry Gemini: A Real-Time Simulation Platform for Electromagnetic Radiation Sensors on Autonomous Ships,

    K. Vasstein, E. F. Brekke, R. Mester, and E. Eide, “Autoferry Gemini: A Real-Time Simulation Platform for Electromagnetic Radiation Sensors on Autonomous Ships,”IOP Conference Series: Materials Science and Engineering, vol. 929, 2020. [Online]. Available: https://doi.org/10.1088/1757-899x/929/1/012032

    work page doi:10.1088/1757-899x/929/1/012032 2020

  4. [4]

    Evaluation Simulator Platform for Extended Collision Risk of Autonomous Surface Vehicles,

    A. Vagale, “Evaluation Simulator Platform for Extended Collision Risk of Autonomous Surface Vehicles,”Journal of Marine Science and Engineering, vol. 10, 05 2022. [Online]. Available: https: //doi.org/10.3390/jmse10050705

    work page doi:10.3390/jmse10050705 2022

  5. [5]

    Hellinger Metrics for Validating High Fidelity Simulators Using Target Tracking,

    K. Vasstein, Ø. K. Helgesen, and E. F. Brekke, “Hellinger Metrics for Validating High Fidelity Simulators Using Target Tracking,” inModelling and Simulation for Autonomous Systems. Cham: Springer International Publishing, 2023, pp. 25–43. [Online]. Available: http://doi.org/10.1007/978-3-031-31268-7_2

    work page doi:10.1007/978-3-031-31268-7_2 2023

  6. [6]

    Analysis of human errors in Human-autonomy collaboration in autonomous ships operations through shore control experimental data,

    T. Cheng, E. Veitch, I. Utne, M. Ramos, A. Mosleh, O. Alsos et al., “Analysis of human errors in Human-autonomy collaboration in autonomous ships operations through shore control experimental data,” Reliability Engineering & System Safety, vol. 246, p. 110080, 03 2024. [Online]. Available: https://doi.org/10.1016/j.ress.2024.110080

    arXiv 2024

  7. [7]

    Human-centred risk assessment for a land-based control interface for an autonomous vessel,

    Å. Hoem, E. Veitch, and K. Vasstein, “Human-centred risk assessment for a land-based control interface for an autonomous vessel,”WMU Journal of Maritime Affairs, vol. 21, 06 2022. [Online]. Available: http://doi.org/10.1007/s13437-022-00278-y

    work page doi:10.1007/s13437-022-00278-y 2022

  8. [8]

    Human-Centered Explainable Artificial Intelligence for Marine Autonomous Surface Vehicles,

    E. Veitch and O. Alsos, “Human-Centered Explainable Artificial Intelligence for Marine Autonomous Surface Vehicles,”Journal of Marine Science and Engineering, vol. 9, p. 1227, 11 2021. [Online]. Available: https://doi.org/10.3390/jmse9111227

    work page doi:10.3390/jmse9111227 2021

Show all 68 references
  1. [9]

    Boredom, vigilance, and repetition during remote control room work for autonomous ships,

    E. Veitch and O. A. Alsos, “Boredom, vigilance, and repetition during remote control room work for autonomous ships,”Journal of Physics: Conference Series, vol. 2867, no. 1, p. 012024, oct 2024. [Online]. Available: https://dx.doi.org/10.1088/1742-6596/2867/1/012024

    2024 doi

  2. [10]

    MARUS - A Marine Robotics Simulator,

    I. Lon ˇcar, J. Obradovi ´c, N. Kraševac, L. Mandi ´c, I. Kvasi ´c, F. Ferreiraet al., “MARUS - A Marine Robotics Simulator,” in OCEANS 2022, Hampton Roads, 2022, pp. 1–7. [Online]. Available: http://doi.org/10.1109/OCEANS47191.2022.9976969

    2022

  3. [11]

    milliAmpere: An Autonomous Ferry Prototype,

    E. F. Brekke, E. Eide, B.-O. H. Eriksen, E. F. Wilthil, M. Breivik, E. Skjellauget al., “milliAmpere: An Autonomous Ferry Prototype,” Journal of Physics: Conference Series, vol. 2311, no. 1, p. 012029, jul

  4. [12]

    The Autonomous Urban Passenger Ferry milliAmpere2: Design and Testing,

    E. Eide, M. Breivik, E. F. Brekke, B.-O. H. Eriksen, E. Wilthil, Ø. K. Helgesenet al., “The Autonomous Urban Passenger Ferry milliAmpere2: Design and Testing,”Journal of Offshore Mechanics and Arctic Engineering, vol. 147, no. 3, p. 031409, 01 2025. [Online]. Available: https:...

    2025 doi

  5. [13]

    NTNU Shore Control Lab: Designing shore control centres in the age of autonomous ships,

    O. A. Alsos, E. Veitch, L. Pantelatos, K. Vasstein, E. Eide, F.-M. Petermannet al., “NTNU Shore Control Lab: Designing shore control centres in the age of autonomous ships,”Journal of Physics: Conference Series, vol. 2311, no. 1, p. 012030, jul 2022. [Online]. Available: https...

    2022 doi

  6. [14]

    Hunting Vulnerabilities in the Maritime Domain: A Domain Wide Cybersecurity Vulnerability Analysis,

    A. Zafar and A. Amro, “Hunting Vulnerabilities in the Maritime Domain: A Domain Wide Cybersecurity Vulnerability Analysis,” in Computer Security. ESORICS 2024 International Workshops. Cham: Springer Nature Switzerland, 2025, pp. 382–402. [Online]. Available: https://doi.org/10...

    2024 doi

  7. [15]

    Multitarget Tracking With Multiple Models and Visibility: Derivation and Verification on Maritime Radar Data,

    E. F. Brekke, A. G. Hem, and L.-C. N. Tokle, “Multitarget Tracking With Multiple Models and Visibility: Derivation and Verification on Maritime Radar Data,”IEEE Journal of Oceanic Engineering, vol. 46, no. 4, pp. 1272–1287, 2021. [Online]. Available: https://doi.org/10.1109/JO...

    2021

  8. [16]

    Stereo Camera-based Free Space Estimation for Docking in Urban Waters,

    T. A. Nygård, N. Dalhaug, R. Mester, E. Brekke, and A. Stahl, “Stereo Camera-based Free Space Estimation for Docking in Urban Waters,” Modeling, Identification and Control, vol. 45, no. 2, pp. 51–63, 2024. [Online]. Available: http://doi.org/10.4173/mic.2024.2.2

    2024 doi

  9. [17]

    Docker: lightweight Linux containers for consistent development and deployment,

    D. Merkel, “Docker: lightweight Linux containers for consistent development and deployment,”Linux J., vol. 2014, no. 239, Mar. 2014. [Online]. Available: http://dl.acm.org/doi/10.5555/2600239.2600241

    2014

  10. [18]

    Serious Game Architecture and Design: Modular Component-Based Data-Driven Entity System Framework to Support Systemic Modeling and Design in Agile Serious Game Developments,

    B. C. Ibañez, “Serious Game Architecture and Design: Modular Component-Based Data-Driven Entity System Framework to Support Systemic Modeling and Design in Agile Serious Game Developments,” Ph.D. dissertation, Université Pierre et Marie Curie (Paris 6), Paris, France, 2013, [O...

    2013

  11. [19]

    A Study of the Characteristics of Behaviour Driven Development,

    C. Solis and X. Wang, “A Study of the Characteristics of Behaviour Driven Development,” in2011 37th EUROMICRO Conference on Software Engineering and Advanced Applications, 2011, pp. 383–387. [Online]. Available: http://doi.org/10.1109/SEAA.2011.76

    2011 doi

  12. [20]

    PyGemini Dataset and Asset Repository,

    K. Vasstein, “PyGemini Dataset and Asset Repository,” https://www.itk. ntnu.no/milliampere-data/gemini, 2024, accessed: 2025-05-21

    2024

  13. [21]

    ROS: an open-source Robot Operating System,

    M. Quigley, K. Conley, B. Gerkey, J. Faust, T. Foote, J. Leibset al., “ROS: an open-source Robot Operating System,” inICRA Workshop on Open Source Software, vol. 3, 01 2009. [Online]. Available: https://ai.stanford.edu/~ang/papers/icraoss09-ROS.pdf

    2009

  14. [22]

    Nested autonomy for unmanned marine vehicles with MOOS-IvP,

    M. R. Benjamin, H. Schmidt, P. M. Newman, and J. J. Leonard, “Nested autonomy for unmanned marine vehicles with MOOS-IvP,” Journal of Field Robotics, vol. 27, no. 6, pp. 834–875, 2010. [Online]. Available: https://onlinelibrary.wiley.com/doi/abs/10.1002/rob.20370

    2010 doi

  15. [23]

    The LSTS toolchain for networked vehicle systems,

    J. Pinto, P. S. Dias, R. Martins, J. Fortuna, E. Marques, and J. Sousa, “The LSTS toolchain for networked vehicle systems,” in 2013 MTS/IEEE OCEANS - Bergen, 2013, pp. 1–9. [Online]. Available: https://doi.org/10.1109/OCEANS-Bergen.2013.6608148

    2013

  16. [24]

    Experience from Hardware-In-the-Loop Testing of Drilling Control Systems,

    T. Pedersen and Ø. Smogeli, “Experience from Hardware-In-the-Loop Testing of Drilling Control Systems,” inSPE/IADC Drilling Conference and Exhibition, vol. SPE/IADC Drilling Conference, 03 2013, pp. SPE– 163 509–MS. [Online]. Available: https://doi.org/10.2118/163509-MS

    2013 doi

  17. [25]

    Third Party HIL Testing of Safety Critical Control System Software on Ships and Rigs,

    Ø. Smogeli and T. Augustson, “Third Party HIL Testing of Safety Critical Control System Software on Ships and Rigs,” inInternational 17 Conference on Offshore Mechanics and Arctic Engineering, vol. V olume 1: Offshore Technology, 07 2012, pp. 839–845. [Online]. Available: http...

    2012 doi

  18. [26]

    Adversarial AI Testcases for Maritime Autonomous Systems,

    M. Walter, A. Barrett, D. Walker, and K. Tam, “Adversarial AI Testcases for Maritime Autonomous Systems,”AI, Computer Science and Robotics Technology, vol. 0, no. 0, Apr. 2023. [Online]. Available: https://doi.org/10.5772/ACRT.15

    2023 doi

  19. [27]

    Open Simulation Platform – An Open-Source Project for Maritime System Co-Simulation,

    Ø. Smogeli, K. Ludvigsen, L. Jamt, B. Vik, H. Nordahl, L. Kyllingstad et al., “Open Simulation Platform – An Open-Source Project for Maritime System Co-Simulation,” in19th International Conference on Computer and IT Applications in the Maritime Industries, 08 2020. [Online]. A...

    2020

  20. [28]

    The Functional Mockup Interface for Tool independent Exchange of Simulation Models,

    T. Blochwitz, M. Otter, M. Arnold, C. Bausch, C. Clauß, H. Elmqvist et al., “The Functional Mockup Interface for Tool independent Exchange of Simulation Models,” inProceedings of the 8th International Modelica Conference, 03 2011, pp. 105–114. [Online]. Available: https://dx.d...

    2011 doi

  21. [29]

    Radiometric calibration of small-footprint full-waveform airborne laser scanner measurements: Basic physical concepts,

    W. Wagner, “Radiometric calibration of small-footprint full-waveform airborne laser scanner measurements: Basic physical concepts,”ISPRS Journal of Photogrammetry and Remote Sensing, vol. 65, no. 6, pp. 505–513, 2010, iSPRS Centenary Celebration Issue. [Online]. Available: htt...

    2010

  22. [30]

    3D Gaussian Splatting for Real-Time Radiance Field Rendering,

    B. Kerbl, G. Kopanas, T. Leimkühler, and G. Drettakis, “3D Gaussian Splatting for Real-Time Radiance Field Rendering,”ACM Transactions on Graphics, vol. 42, no. 4, July 2023. [Online]. Available: https://repo-sam.inria.fr/fungraph/3d-gaussian-splatting/

    2023

  23. [31]

    Exploiting GPUDirect RDMA in Designing High Performance OpenSHMEM for NVIDIA GPU Clusters,

    K. Hamidouche, A. Venkatesh, A. A. Awan, H. Subramoni, C.-H. Chu, and D. K. Panda, “Exploiting GPUDirect RDMA in Designing High Performance OpenSHMEM for NVIDIA GPU Clusters,” in2015 IEEE International Conference on Cluster Computing, 2015, pp. 78–87. [Online]. Available: http...

    2015 doi

  24. [32]

    Nerfstudio: A Modular Framework for Neural Radiance Field Development,

    M. Tancik, E. Weber, E. Ng, R. Li, B. Yi, T. Wanget al., “Nerfstudio: A Modular Framework for Neural Radiance Field Development,” in ACM SIGGRAPH 2023 Conference Proceedings, ser. SIGGRAPH ’23. New York, NY , USA: Association for Computing Machinery, 2023. [Online]. Available:...

    2023

  25. [33]

    Open3D: A Modern Library for 3D Data Processing,

    Q.-Y . Zhou, J. Park, and V . Koltun, “Open3D: A Modern Library for 3D Data Processing,”arXiv:1801.09847, 2018. [Online]. Available: https://doi.org/10.48550/arXiv.1801.09847

    2018 doi arXiv

  26. [34]

    Vico: An entity-component-system based co-simulation framework,

    L. I. Hatledal, Y . Chu, A. Styve, and H. Zhang, “Vico: An entity-component-system based co-simulation framework,”Simulation Modelling Practice and Theory, vol. 108, p. 102243, 2021. [Online]. Available: https://doi.org/10.1016/j.simpat.2020.102243

    2021

  27. [35]

    Towards Building AI-CPS with NVIDIA Isaac Sim: An Industrial Benchmark and Case Study for Robotics Manipulation,

    Z. Zhou, J. Song, X. Xie, Z. Shu, L. Ma, D. Liuet al., “Towards Building AI-CPS with NVIDIA Isaac Sim: An Industrial Benchmark and Case Study for Robotics Manipulation,” in2024 IEEE/ACM 46th International Conference on Software Engineering: Software Engineering in Practice (IC...

    2024

  28. [36]

    Unity Simulation Manual,

    Unity Technologies, “Unity Simulation Manual,” 2023, unity Simulation is deprecated as of December 2023 and is no longer available. [Online]. Available: https://docs.unity3d.com/Simulation/

    2023

  29. [37]

    Unity CEO Refocuses on Video Games after Metaverse Detour,

    C. D’Anastasio, “Unity CEO Refocuses on Video Games after Metaverse Detour,”Bloomberg, October 2024. [On- line]. Available: https://www.bloomberg.com/news/articles/2024-10-17/ unity-ceo-refocuses-on-video-games-after-metaverse-detour

    2024

  30. [38]

    Exclusive: Unity Software to cut 25% of staff in ‘company reset’ continuation,

    A. Tong, “Exclusive: Unity Software to cut 25% of staff in ‘company reset’ continuation,”Reuters, January

  31. [39]

    UUVSim: Intelligent Modular Simulation Platform for Unmanned Underwater Vehicle Learning,

    Z. Zhang, J. Xu, J. Du, W. Mi, Z. Wang, Z. Liet al., “UUVSim: Intelligent Modular Simulation Platform for Unmanned Underwater Vehicle Learning,” in2024 International Joint Conference on Neural Networks (IJCNN), 2024, pp. 1–8. [Online]. Available: https://doi.org/10.1109/IJCNN6...

    2024

  32. [40]

    An open source tool for simulation and supervision of underwater intervention missions,

    M. Prats, J. Pérez, J. J. Fernández, and P. J. Sanz, “An open source tool for simulation and supervision of underwater intervention missions,” in2012 IEEE/RSJ International Conference on Intelligent Robots and Systems, 2012, pp. 2577–2582. [Online]. Available: https://doi.org/...

    2012

  33. [41]

    Stonefish: An Advanced Open-Source Simulation Tool Designed for Marine Robotics, With a ROS Interface,

    P. Cie ´slak, “Stonefish: An Advanced Open-Source Simulation Tool Designed for Marine Robotics, With a ROS Interface,” inOCEANS 2019 - Marseille, Jun. 2019. [Online]. Available: https://doi.org/10. 1109/OCEANSE.2019.8867434

    2019

  34. [42]

    Stonefish: Supporting Machine Learning Research in Marine Robotics,

    M. Grimaldi, P. Cieslak, E. Ochoa, V . Bharti, H. Rajani, I. Carlucho et al., “Stonefish: Supporting Machine Learning Research in Marine Robotics,” 2025. [Online]. Available: https://arxiv.org/abs/2502.11887

    2025 arXiv

  35. [43]

    Evaluation of open source licensing models for a company developing mass market software,

    M. Välimäki and V . Oksanen, “Evaluation of open source licensing models for a company developing mass market software,”Proceeding (375) Law and Technology, 01 2002. [Online]. Available: https://www. researchgate.net/publication/246111944_Evaluation_of_open_source_ licensing_m...

    2002

  36. [44]

    The role of software licenses in open architecture ecosystems,

    T. Alspaugh, H. Asuncion, and W. Scacchi, “The role of software licenses in open architecture ecosystems,”First International Workshop on Software Ecosystems (IWSECO-2009), 01 2009. [Online]. Available: https://ceur-ws.org/V ol-505/iwseco09-3AlspaughAcunsionScacchi.pdf

    2009

  37. [45]

    Changes in free and open source software licenses: managerial interventions and variations on project attractiveness,

    C. D. dos Santos, “Changes in free and open source software licenses: managerial interventions and variations on project attractiveness,” Journal of Internet Services and Applications, vol. 8, no. 1, p. 11,

  38. [46]

    UNav-Sim: A Visually Realistic Underwater Robotics Simulator and Synthetic Data-generation Framework,

    A. Amer, O. Álvarez-Tuñón, H. ˙I. U˘gurlu, J. L. F. Sejersen, Y . Brodskiy, and E. Kayacan, “UNav-Sim: A Visually Realistic Underwater Robotics Simulator and Synthetic Data-generation Framework,” in2023 21st International Conference on Advanced Robotics (ICAR). IEEE, 2023, pp....

    2023

  39. [47]

    HoloOcean: An Underwater Robotics Simulator,

    E. Potokar, S. Ashford, M. Kaess, and J. G. Mangelson, “HoloOcean: An Underwater Robotics Simulator,” in2022 International Conference on Robotics and Automation (ICRA), 2022, pp. 3040–3046. [Online]. Available: https://doi.org/10.1109/ICRA46639.2022.9812353

    2022

  40. [48]

    SAM 2: Segment Anything in Images and Videos,

    N. Ravi, V . Gabeur, Y .-T. Hu, R. Hu, C. Ryali, T. Maet al., “SAM 2: Segment Anything in Images and Videos,”arXiv preprint arXiv:2408.00714, 2024. [Online]. Available: https://arxiv.org/abs/2408. 00714

    2024 arXiv

  41. [49]

    Short-Term Trajectory Planning for a Non-Holonomic Robot Car: Utilizing Reinforcement Learning in Conjunction with a Predefined Vehicle Model,

    H. Fjellheim, “Short-Term Trajectory Planning for a Non-Holonomic Robot Car: Utilizing Reinforcement Learning in Conjunction with a Predefined Vehicle Model,” Master’s thesis, NTNU, 2023. [Online]. Available: https://ntnuopen.ntnu.no/ntnu-xmlui/handle/11250/3097369

    2023

  42. [50]

    Scenic: a language for scenario specification and data generation,

    D. Fremont, E. Kim, T. Dreossi, S. Ghosh, X. Yue, A. Vincentelliet al., “Scenic: a language for scenario specification and data generation,” Machine Learning, vol. 112, pp. 1–45, 02 2022. [Online]. Available: https://doi.org/10.1007/s10994-021-06120-5

    2022 doi

  43. [51]

    NeRF: representing scenes as neural radiance fields for view synthesis,

    B. Mildenhall, P. P. Srinivasan, M. Tancik, J. T. Barron, R. Ramamoorthi, and R. Ng, “NeRF: representing scenes as neural radiance fields for view synthesis,”Commun. ACM, vol. 65, no. 1, p. 99–106, Dec. 2021. [Online]. Available: https://doi.org/10.1145/3503250

    2021 doi

  44. [52]

    High-Resolution Image Synthesis with Latent Diffusion Models,

    R. Rombach, A. Blattmann, D. Lorenz, P. Esser, and B. Ommer, “High-Resolution Image Synthesis with Latent Diffusion Models,” in2022 IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR), 2022, pp. 10 674–10 685. [Online]. Available: http://doi.org/10.1109/CVPR5...

    2022

  45. [53]

    Adding Conditional Control to Text-to-Image Diffusion Models,

    L. Zhang, A. Rao, and M. Agrawala, “Adding Conditional Control to Text-to-Image Diffusion Models,” 2023. [Online]. Available: https://arxiv.org/abs/2302.05543

    2023 arXiv

  46. [54]

    Array programming with NumPy,

    C. R. Harris, K. J. Millman, S. J. van der Walt, R. Gommers, P. Virtanen, D. Cournapeauet al., “Array programming with NumPy,” Nature, vol. 585, no. 7825, pp. 357–362, Sep. 2020. [Online]. Available: https://doi.org/10.1038/s41586-020-2649-2

    2020 doi

  47. [55]

    PyTorch 2: Faster Machine Learning Through Dynamic Python Bytecode Transformation and Graph Compilation,

    J. Ansel, E. Yang, H. He, N. Gimelshein, A. Jain, M. V oznesensky et al., “PyTorch 2: Faster Machine Learning Through Dynamic Python Bytecode Transformation and Graph Compilation,” inProceedings of the 29th ACM International Conference on Architectural Support for Programming ...

    2024

  48. [56]

    Numba: a LLVM-based Python JIT compiler,

    S. K. Lam, A. Pitrou, and S. Seibert, “Numba: a LLVM-based Python JIT compiler,” inProceedings of the Second Workshop on the LLVM Compiler Infrastructure in HPC, ser. LLVM ’15. New York, NY , USA: Association for Computing Machinery, 2015. [Online]. Available: https://doi.org/...

    2015

  49. [57]

    gsplat: An Open-Source Library for Gaussian Splatting,

    V . Ye, R. Li, J. Kerr, M. Turkulainen, B. Yi, Z. Panet al., “gsplat: An Open-Source Library for Gaussian Splatting,”Journal of Machine Learning Research, vol. 26, no. 34, pp. 1–17, 2025. [Online]. Available: http://jmlr.org/papers/v26/24-1476.html

    2025

  50. [58]

    Diffusers: State-of-the-art diffusion models,

    P. von Platen, S. Patil, A. Lozhkov, P. Cuenca, N. Lambert, K. Rasul et al., “Diffusers: State-of-the-art diffusion models,” https://github.com/ huggingface/diffusers, 2022

    2022

  51. [59]

    Behaviour driven development: A systematic mapping study,

    L. P. Binamungu and S. Maro, “Behaviour driven development: A systematic mapping study,”Journal of Systems and Software, vol. 203, 18 p. 111749, 2023. [Online]. Available: https://www.sciencedirect.com/ science/article/pii/S0164121223001449

    2023

  52. [60]

    Adapting Behavior Driven Development (BDD) for large-scale software systems,

    M. Irshad, R. Britto, and K. Petersen, “Adapting Behavior Driven Development (BDD) for large-scale software systems,”Journal of Systems and Software, vol. 177, p. 110944, 2021. [Online]. Available: https://www.sciencedirect.com/science/article/pii/S0164121221000418

    2021

  53. [61]

    Structure-from-Motion Revisited,

    J. L. Schönberger and J.-M. Frahm, “Structure-from-Motion Revisited,” in2016 IEEE Conference on Computer Vision and Pattern Recognition (CVPR), 2016, pp. 4104–4113. [Online]. Available: https://doi.org/10. 1109/CVPR.2016.445

    2016

  54. [62]

    T. I. Fossen,Handbook of Marine Craft Hydrodynamics and Motion Control, 2nd ed. Chichester, UK: John Wiley & Sons Ltd., 2021. [Online]. Available: https://www.fossen.biz/publications/books.php

    2021

  55. [63]

    Laser and Gaussian Beam Propagation and Transformation,

    J. Alda, “Laser and Gaussian Beam Propagation and Transformation,” Encyclopedia of Optical Engineering, 01 2003. [Online]. Available: https://sites.unimi.it/aqm/wp-content/uploads/JAlda-2003.pdf

    2003

  56. [64]

    Generalization of Lambert’s reflectance model,

    M. Oren and S. K. Nayar, “Generalization of Lambert’s reflectance model,” inProceedings of the 21st Annual Conference on Computer Graphics and Interactive Techniques, ser. SIGGRAPH ’94. New York, NY , USA: Association for Computing Machinery, 1994, p. 239–246. [Online]. Availa...

    1994

  57. [65]

    Correction of terrestrial LiDAR intensity channel using Oren–Nayar reflectance model: An application to lithological differentiation,

    D. Carrea, A. Abellan, F. Humair, B. Matasci, M.-H. Derron, and M. Jaboyedoff, “Correction of terrestrial LiDAR intensity channel using Oren–Nayar reflectance model: An application to lithological differentiation,”ISPRS Journal of Photogrammetry and Remote Sensing, vol. 113, p...

    2016

  58. [2017]

    Available: https://doi.org/10.1186/s13174-017-0062-3

    [Online]. Available: https://doi.org/10.1186/s13174-017-0062-3

    doi

  59. [2022]

    Available: https://dx.doi.org/10.1088/1742-6596/2311/ 1/012029

    [Online]. Available: https://dx.doi.org/10.1088/1742-6596/2311/ 1/012029

    doi

  60. [2024]

    Available: https://www.reuters.com/technology/ unity-software-cutting-25-staff-company-reset-continuation-2024-01-08/

    [Online]. Available: https://www.reuters.com/technology/ unity-software-cutting-25-staff-company-reset-continuation-2024-01-08/

    2024

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.