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

Stel je voor dat je een ruimte-ingenieur bent die probeert een digitale tweeling van een satelliet te bouwen. Je wilt testen hoe het vliegt, hoe het stuurt en hoe het reageert op zwaartekracht. Hiervoor gebruik je een krachtige, open-source softwaretool genaamd Basilisk.

Echter, Basilisk is als een hoogpresterende racemotor. Het is geweldig, maar ook ongelooflijk gevoelig. Als je probeert het uit te voeren op je laptop, het bureaublad van je collega en een universiteitsserver, loop je mogelijk tegen een nachtmerrie aan: "Het werkt op mijn machine, maar niet op de jouwe!" Dit gebeurt omdat elke computer iets andere softwareversies, bibliotheken en instellingen heeft.

Dit artikel presenteert een oplossing voor die hoofdpijn: Docker.

De "Lunchbox"-analogie

Stel je de Basilisk-software en al zijn afhankelijkheden (de extra tools die het nodig heeft om te draaien) voor als een complexe, meerlagige sandwich.

• Het probleem: Als je probeert deze sandwich naar een vriend te sturen, kan het brood platgedrukt worden, kan de sla verwelken, of heeft de vriend misschien niet het juiste mes om het te eten. In computertermen is dit "afhankelijkheidsbeheer".
• De oplossing (Docker): De auteurs plaatsen de hele sandwich in een verzegelde, zelfstandige lunchbox (een Docker-container). Binnenin deze lunchbox is het brood vers, zijn de tools inbegrepen en is de temperatuur perfect. Het maakt niet uit of je vriend zich in een hete keuken, een koud kantoor of een vochtige kelder bevindt; wanneer ze de lunchbox openen, is de sandwich exact hetzelfde als toen jij hem inpakte.

Wat het artikel eigenlijk doet

Het artikel biedt een "recept" (een reeks instructies genaamd een Dockerfile) voor het bouwen van deze lunchbox. Hier is de werkstroom die ze beschrijven, eenvoudig opgesplitst:

1. De container bouwen (De lunchbox)
De auteurs hebben een specifiek recept gemaakt dat de Basilisk-software downloadt, alle benodigde tools installeert (zoals Python- en C++-compilers) en de omgeving precies zo instelt als nodig is. Ze hebben de softwareversies vastgezet zodat de "lunchbox" nooit verandert, waardoor gegarandeerd wordt dat als je het vandaag bouwt, het identiek zal zijn aan een exemplaar dat over vijf jaar wordt gebouwd.

2. De "magische" verbinding (Bind Mounts)
Normaal gesproken kun je bestanden die je in een lunchbox stopt, niet makkelijk bewerken van buitenaf. De auteurs hebben dit opgelost door een "magisch raam" te creëren (een bind mount). Hiermee kun je je simulatiecode op je eigen computer schrijven, en ziet de container die wijzigingen direct. Je krijgt de consistentie van de lunchbox met de flexibiliteit van je eigen werkruimte.

3. Simulaties uitvoeren (De scenario's)
Het artikel neemt je mee door drie niveaus van complexiteit, zoals een videogame-tutorial:

• Niveau 1: De drijvende rots. Een eenvoudig script dat gewoon een ruimtetuig in de simulatie plaatst om te controleren of de motor draait.
• Niveau 2: De Aarde-omloopbaan. Een complexer script dat zwaartekracht, de Aarde en de regels van de fysica toevoegt (inclusief subtiele wiebelingen in de zwaartekracht van de Aarde) om de omloopbaan van de satelliet te zien.
• Niveau 3: Het Zon-Aarde-systeem. Het meest complexe script, dat een enorme database met planetaire posities (genaamd SPICE) gebruikt om de satelliet te simuleren die tussen de Zon en de Aarde beweegt.

4. Het "BSKSim"-kader (De LEGO-set)
Voor eenvoudige tests kun je één lang script schrijven. Maar voor grote, complexe missies wordt dat rommelig. De auteurs introduceren een kader genaamd BSKSim.

• Analogie: Stel je voor dat je bouwt met LEGO. In plaats van elke steen aan elkaar te lijmen tot één groot blok, geeft BSKSim je voorafgemaakte, herbruikbare stenen (modules voor dynamica, sensoren en besturingssoftware). Je kunt deze stenen op verschillende manieren aan elkaar klikken om verschillende missies te bouwen zonder dat je de stenen elke keer opnieuw hoeft te bouwen.

5. De "Wat-zou-er-als"-machine (Monte Carlo-analyse)
Tot slot laat het artikel zien hoe je de simulatie 100 keer achter elkaar kunt uitvoeren, maar elke keer met lichte willekeurige veranderingen (bijvoorbeeld: "Wat als de satelliet 10 kg zwaarder is?" of "Wat als de startpositie een paar meter afwijkt?"). Dit helpt ingenieurs te begrijpen hoe betrouwbaar hun ontwerp is onder onzekerheid.

Waarom dit belangrijk is (volgens het artikel)

• Reproduceerbaarheid: Als een onderzoeker zegt: "Ik heb deze simulatie uitgevoerd en dit resultaat verkregen", kan iedereen anders deze "lunchbox" downloaden, exact dezelfde code draaien en exact hetzelfde resultaat krijgen. Geen "het werkt op mijn machine"-excuses meer.
• Gebruiksgemak: Nieuwe studenten of ingenieurs hoeven niet wekenlang software te proberen te installeren. Ze voeren gewoon één opdracht uit en de omgeving is klaar.
• Visualisatie: Het systeem maakt verbinding met een 3D-tool genaamd Vizard (die eruitziet als een videogamemotor) zodat je de satelliet daadwerkelijk kunt zien vliegen in de 3D-ruimte, in plaats van alleen naar cijfers te kijken.

De adder onder het gras (Beperkingen)

Het artikel is eerlijk over de nadelen:

• Grootte: De "lunchbox" is zwaar. Omdat het alle gecompileerde code en tools bevat, is het bestand groot en duurt het tijd (15–20 minuten) om het de eerste keer te bouwen.
• Grafiek: Als je de 3D-animatie in real-time wilt bekijken, moet je computer een grafische kaart hebben die goed samenwerkt met de container. Zo niet, dan moet je de video opslaan en later bekijken.
• Updates: Omdat de Basilisk-software altijd wordt bijgewerkt, moet het "recept" voor de lunchbox af en toe worden bijgewerkt om compatibel te blijven.

Kortom, dit artikel is een handleiding voor het verpakken van een complexe ruimte-simulatietool in een draagbaar, onbreekbaar pakket, waardoor het voor iedereen makkelijk is om het te gebruiken, te delen en te vertrouwen, ongeacht welke computer ze gebruiken.