# \`bosun\_call\` experimental tool and spec for simulator orchestration

**URL:** <https://forum.oceansoft.org/t/bosun-call-experimental-tool-and-spec-for-simulator-orchestration/55>\
**Category:** Simulation\
**Created:** [September 29, 2026, 2:42pm UTC](https://forum.oceansoft.org/t/bosun-call-experimental-tool-and-spec-for-simulator-orchestration/55 "2026-09-29T14:42:24Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![cst0](https://yyz2.discourse-cdn.com/flex008/user_avatar/forum.oceansoft.org/cst0/32/48_2.png) [@cst0](https://forum.oceansoft.org/u/cst0)\
**Post date:** [September 29, 2026, 2:42pm UTC](https://forum.oceansoft.org/t/bosun-call-experimental-tool-and-spec-for-simulator-orchestration/55/1 "2026-09-29T14:42:24Z")

</div>

Hi all, many of us had some really interesting chats at OCEANS on marine simulation. To summarize:

- Robot simulation environments are important for our testing, development, and experimentation; this is especially true for the marine autonomy space where deployments are more costly and involved.
- With so many different simulation tools in the space for so many different use-cases, the community has become fractured across different simulation approaches (e.g., gazebo based, game-engine based, others).
- It is challenging to get many of these simulators running, which presents another barrier
- As a consequence, it is challenging recreate each others experimental results, benchmarking is not consistent, and effort is fractured.

Many of us have suggested that these are simulation problems, but I’d like to suggest that it’s actually a toolchain problem. These simulators exist for different purposes, and that’s OK; the problem is that we can’t recreate other people’s experiments on our hardware/software. A solution I proposed is to borrow from the concept of cross-compilation: one set of config files and assets that can be compiled and deployed to a number of different targets (simulators).

I’ve been playing with that idea since OCEANS, and released a beta version of:

- a language-agnostic [spec](https://git.whoi.edu/cthierauf/bosun_call/-/blob/master/spec.md?ref_type=heads)
- an implementation of the [proposed CLI tool](https://git.whoi.edu/cthierauf/bosun_call/-/tree/master/bosun_call?ref_type=heads), `bosun`
- a [demo](https://git.whoi.edu/cthierauf/bosun_call/-/tree/master/demo?ref_type=heads)

All in the same repository ([this one](https://git.whoi.edu/cthierauf/bosun_call)) and also available via `pip install bosun_call` (requires python 3.10+).

The command line tool provides a utility to fetch simulation tools (simplified by running them in docker, but other approaches are conceptually supported), and then a runner that takes a simulator-agnostic configuration file to launch them as set up. Using it, I was able to demonstrate that I could fetch MuJoCo and DAVE, create a trackline follower experiment, and then recreate my experiment in a custom toy point-mass sim, then transfer to MuJoCo, then transfer to DAVE. Additionally, a manifest is created with each run, so the exact experimental details can be recreated.

If other folks are able to recreate on their end, I’d love to hear about it, and any/all other feedback is welcome. The implementation currently assumes Ubuntu 20.04+ but isn’t locked to that.