Basilisk and Docker for Reproducible GN&C Simulation: A Workflow Reference

Imagine you are a space engineer trying to build a digital twin of a satellite. You want to test how it flies, how it steers, and how it reacts to gravity. To do this, you use a powerful, open-source software tool called Basilisk.

However, Basilisk is like a high-performance racing engine. It's amazing, but it's also incredibly sensitive. If you try to run it on your laptop, your colleague's desktop, and a university server, you might run into a nightmare: "It works on my machine, but not yours!" This happens because every computer has slightly different software versions, libraries, and settings.

This paper presents a solution to that headache: Docker.

The "Lunchbox" Analogy

Think of the Basilisk software and all its dependencies (the extra tools it needs to run) as a complex, multi-layered sandwich.

• The Problem: If you try to send this sandwich to a friend, the bread might get squished, the lettuce might wilt, or the friend might not have the right knife to eat it. In computing terms, this is "dependency management."
• The Solution (Docker): The authors put the entire sandwich inside a sealed, self-contained lunchbox (a Docker container). Inside this lunchbox, the bread is fresh, the tools are included, and the temperature is perfect. It doesn't matter if your friend is in a hot kitchen, a cold office, or a humid basement; when they open the lunchbox, the sandwich is exactly the same as it was when you packed it.

What the Paper Actually Does

The paper provides a "recipe" (a set of instructions called a Dockerfile) for building this lunchbox. Here is the workflow they describe, broken down simply:

1. Building the Container (The Lunchbox)
The authors created a specific recipe that downloads the Basilisk software, installs all the necessary tools (like Python and C++ compilers), and sets up the environment exactly the way it needs to be. They locked the software versions down so that the "lunchbox" never changes, ensuring that if you build it today, it will be identical to one built five years from now.

2. The "Magic" Connection (Bind Mounts)
Usually, if you put files inside a lunchbox, you can't edit them easily from the outside. The authors solved this by creating a "magic window" (called a bind mount). This allows you to write your simulation code on your own computer, and the container instantly sees those changes. You get the consistency of the lunchbox with the flexibility of your own workspace.

3. Running Simulations (The Scenarios)
The paper walks you through three levels of complexity, like a video game tutorial:

• Level 1: The Floating Rock. A simple script that just puts a spacecraft in the simulation to make sure the engine is running.
• Level 2: The Earth Orbit. A more complex script that adds gravity, the Earth, and the rules of physics (including subtle wobbles in Earth's gravity) to see the satellite orbit.
• Level 3: The Sun-Earth System. The most complex script, which uses a massive database of planetary positions (called SPICE) to simulate the satellite moving between the Sun and Earth.

4. The "BSKSim" Framework (The LEGO Kit)
For simple tests, you can write one long script. But for big, complex missions, that gets messy. The authors introduce a framework called BSKSim.

• Analogy: Imagine building with LEGO. Instead of gluing every brick together into one giant block, BSKSim gives you pre-made, reusable bricks (modules for dynamics, sensors, and control software). You can snap these bricks together in different ways to build different missions without having to rebuild the bricks every time.

5. The "What-If" Machine (Monte Carlo Analysis)
Finally, the paper shows how to run the simulation 100 times in a row, but with slight random changes each time (e.g., "What if the satellite is 10kg heavier?" or "What if the starting position is off by a few meters?"). This helps engineers understand how reliable their design is under uncertainty.

Why This Matters (According to the Paper)

• Reproducibility: If a researcher says, "I ran this simulation and got this result," anyone else can download this "lunchbox," run the exact same code, and get the exact same result. No more "it works on my machine" excuses.
• Ease of Use: New students or engineers don't need to spend weeks trying to install the software. They just run one command, and the environment is ready.
• Visualization: The system connects to a 3D tool called Vizard (which looks like a video game engine) so you can actually see the satellite flying in 3D space, rather than just looking at numbers.

The Catch (Limitations)

The paper is honest about the downsides:

• Size: The "lunchbox" is heavy. Because it includes all the compiled code and tools, the file is large and takes time (15–20 minutes) to build the first time.
• Graphics: If you want to watch the 3D animation in real-time, your computer needs to have a graphics card that plays nice with the container. If not, you have to save the video and watch it later.
• Updates: Since the Basilisk software is always being updated, the "recipe" for the lunchbox needs to be updated occasionally to stay compatible.

In short, this paper is a guidebook for wrapping a complex space simulation tool in a portable, unbreakable package, making it easy for anyone to use, share, and trust, regardless of what computer they are using.