⚡ electrical engineering

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

Ce document présente une workflow de conteneurisation basée sur Docker pour le cadre d'astrodynamique Basilisk, garantissant des environnements de simulation GN&C reproductibles et portables sur des systèmes hétérogènes, démontrée à travers une progression de scénarios de plus en plus complexes, allant de la dynamique orbitale à l'analyse de contrôle d'attitude par méthode de Monte Carlo.

Auteurs originaux : Anubhav Gupta

Publié 2026-05-13

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Anubhav Gupta

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous êtes ingénieur spatial tentant de construire un jumeau numérique d'un satellite. Vous souhaitez tester sa façon de voler, de piloter et de réagir à la gravité. Pour ce faire, vous utilisez un outil logiciel puissant et open source appelé Basilisk.

Cependant, Basilisk est comparable à un moteur de course haute performance. Il est incroyable, mais aussi incroyablement sensible. Si vous tentez de l'exécuter sur votre ordinateur portable, sur le bureau de votre collègue et sur un serveur universitaire, vous pourriez rencontrer un cauchemar : « Ça marche sur ma machine, mais pas sur la vôtre ! » Cela se produit parce que chaque ordinateur possède des versions logicielles, des bibliothèques et des paramètres légèrement différents.

Ce papier présente une solution à ce casse-tête : Docker.

L'analogie de la « boîte à lunch »

Considérez le logiciel Basilisk et toutes ses dépendances (les outils supplémentaires dont il a besoin pour fonctionner) comme un sandwich complexe à plusieurs couches.

Le problème : Si vous essayez d'envoyer ce sandwich à un ami, le pain pourrait être écrasé, la laitue pourrait se flétrir, ou l'ami pourrait ne pas avoir le bon couteau pour le manger. En termes informatiques, il s'agit de la « gestion des dépendances ».
La solution (Docker) : Les auteurs placent l'intégralité du sandwich dans une boîte à lunch scellée et autonome (un conteneur Docker). À l'intérieur de cette boîte à lunch, le pain est frais, les outils sont inclus et la température est parfaite. Peu importe que votre ami se trouve dans une cuisine chaude, un bureau froid ou un sous-sol humide ; lorsqu'il ouvre la boîte à lunch, le sandwich est exactement le même que lorsque vous l'avez emballé.

Ce que fait réellement le papier

Le papier fournit une « recette » (un ensemble d'instructions appelé Dockerfile) pour construire cette boîte à lunch. Voici le flux de travail qu'ils décrivent, décomposé simplement :

1. Construction du conteneur (la boîte à lunch)
Les auteurs ont créé une recette spécifique qui télécharge le logiciel Basilisk, installe tous les outils nécessaires (comme les compilateurs Python et C++) et configure l'environnement exactement comme il doit l'être. Ils ont verrouillé les versions logicielles afin que la « boîte à lunch » ne change jamais, garantissant que si vous la construisez aujourd'hui, elle sera identique à celle construite dans cinq ans.

2. La connexion « magique » (montages liés)
Habituellement, si vous placez des fichiers à l'intérieur d'une boîte à lunch, vous ne pouvez pas les modifier facilement depuis l'extérieur. Les auteurs ont résolu cela en créant une « fenêtre magique » (appelée montage lié). Cela vous permet d'écrire votre code de simulation sur votre propre ordinateur, et le conteneur voit instantanément ces modifications. Vous obtenez la cohérence de la boîte à lunch avec la flexibilité de votre propre espace de travail.

3. Exécution des simulations (les scénarios)
Le papier vous guide à travers trois niveaux de complexité, comme un tutoriel de jeu vidéo :

Niveau 1 : Le rocher flottant. Un script simple qui place simplement un vaisseau spatial dans la simulation pour s'assurer que le moteur fonctionne.
Niveau 2 : L'orbite terrestre. Un script plus complexe qui ajoute la gravité, la Terre et les lois de la physique (y compris les oscillations subtiles de la gravité terrestre) pour observer l'orbite du satellite.
Niveau 3 : Le système Soleil-Terre. Le script le plus complexe, qui utilise une base de données massive de positions planétaires (appelée SPICE) pour simuler le mouvement du satellite entre le Soleil et la Terre.

4. Le framework « BSKSim » (le kit LEGO)
Pour des tests simples, vous pouvez écrire un script long. Mais pour des missions vastes et complexes, cela devient désordonné. Les auteurs introduisent un framework appelé BSKSim.

Analogie : Imaginez construire avec des LEGO. Au lieu de coller chaque brique ensemble pour former un seul bloc géant, BSKSim vous fournit des briques préfabriquées et réutilisables (modules pour la dynamique, les capteurs et le logiciel de contrôle). Vous pouvez assembler ces briques de différentes manières pour construire différentes missions sans avoir à reconstruire les briques à chaque fois.

5. La machine « Et si... » (analyse de Monte Carlo)
Enfin, le papier montre comment exécuter la simulation 100 fois de suite, mais avec de légères modifications aléatoires à chaque fois (par exemple : « Et si le satellite était 10 kg plus lourd ? » ou « Et si la position de départ était décalée de quelques mètres ? »). Cela aide les ingénieurs à comprendre la fiabilité de leur conception face aux incertitudes.

Pourquoi cela compte (selon le papier)

Reproductibilité : Si un chercheur déclare : « J'ai exécuté cette simulation et obtenu ce résultat », n'importe qui d'autre peut télécharger cette « boîte à lunch », exécuter exactement le même code et obtenir exactement le même résultat. Fini les excuses du type « ça marche sur ma machine ».
Facilité d'utilisation : Les nouveaux étudiants ou ingénieurs n'ont pas besoin de passer des semaines à essayer d'installer le logiciel. Ils exécutent simplement une commande, et l'environnement est prêt.
Visualisation : Le système se connecte à un outil 3D appelé Vizard (qui ressemble à un moteur de jeu vidéo) afin que vous puissiez réellement voir le satellite voler dans l'espace 3D, plutôt que de simplement regarder des chiffres.

Le revers de la médaille (limitations)

Le papier est honnête quant aux inconvénients :

Taille : La « boîte à lunch » est lourde. Parce qu'elle inclut tout le code compilé et les outils, le fichier est volumineux et prend du temps (15 à 20 minutes) à construire la première fois.
Graphismes : Si vous souhaitez regarder l'animation 3D en temps réel, votre ordinateur doit disposer d'une carte graphique compatible avec le conteneur. Sinon, vous devez enregistrer la vidéo et la regarder plus tard.
Mises à jour : Comme le logiciel Basilisk est constamment mis à jour, la « recette » de la boîte à lunch doit être mise à jour occasionnellement pour rester compatible.

En résumé, ce papier est un guide pour envelopper un outil complexe de simulation spatiale dans un package portable et incassable, le rendant facile à utiliser, à partager et à faire confiance pour tout le monde, indépendamment de l'ordinateur utilisé.

Résumé technique : Basilisk et Docker pour une simulation GN&C reproductible

Énoncé du problème
Les simulations de guidage, navigation et contrôle (GN&C) pour les véhicules spatiaux sont essentielles à la conception et à la validation des missions, mais l'établissement d'environnements de simulation cohérents et portables reste un défi majeur. Le framework open-source Basilisk (BSK), bien que flexible et efficace sur le plan computationnel, nécessite une gestion complexe des dépendances impliquant des systèmes d'exploitation spécifiques, des chaînes d'outils de compilation, des environnements Python, des configurations de paquets Conan et des bibliothèques externes (par exemple, les noyaux SPICE, les outils de visualisation). Les variations entre les machines de développement entraînent souvent des incohérences dans l'installation, le comportement du logiciel et les flux de travail d'exécution, ce qui nuit à la reproductibilité et à la collaboration.

Méthodologie
L'article présente un flux de travail de conteneurisation basé sur Docker conçu pour encapsuler l'environnement de construction complet de Basilisk, les dépendances et l'infrastructure de simulation au sein d'une image de conteneur portable. La méthodologie comprend :

Construction du conteneur : Un Dockerfile basé sur Ubuntu 22.04 et Python 3.10 est utilisé pour définir l'environnement de construction. Il installe les bibliothèques système nécessaires, gère les dépendances Python via pip et compile Basilisk à partir d'un commit source spécifique (87cb4116e09694ddf6587f61a7f4196d2e720c43) en utilisant conanfile.py. Cela garantit l'inclusion de l'interface de visualisation Vizard et la récupération de fichiers de support volumineux (par exemple, les noyaux SPICE) via git-lfs.
Orchestration : Docker Compose gère les propriétés d'exécution, en utilisant des montages liés (bind mounts) pour synchroniser le répertoire du projet de l'hôte avec /app/workspace du conteneur. Cela permet aux ingénieurs de modifier les scripts de simulation sur l'hôte tout en les exécutant dans un environnement conteneurisé cohérent.
Flux de travail de simulation : L'article démontre le flux de travail à travers une progression de complexité croissante :
- Scripts autonomes : Scénarios Python simples configurant des conteneurs de simulation, des processus et des tâches pour la dynamique spatiale de base et des scénarios d'orbite terrestre avec des perturbations $J_2$ .
- Cadre BSKSim : Une architecture orientée objet séparant les modèles de dynamique, le logiciel de vol (FSW) et la configuration des scénarios. Cela inclut une hiérarchie de classes (BSKSim et BSKScenario) qui gère l'enregistrement des processus, le cycle de vie des modules et l'enregistrement des données.
- Scénarios avancés : Mise en œuvre de la dynamique d'attitude, du contrôle par rétroaction MRP et des simulations du système Soleil-Terre utilisant des éphémérides SPICE.
- Analyse de Monte Carlo : Utilisation du MonteCarloController natif de Basilisk pour exécuter des ensembles de simulations avec des dispersions de paramètres randomisées (par exemple, masse, position initiale) au sein du conteneur.

Contributions clés
L'article fournit une référence d'implémentation autonome pour les ingénieurs et chercheurs en GN&C, contribuant spécifiquement à :

Déploiement reproductible : Une configuration Docker vérifiée qui élimine la variabilité spécifique à l'environnement, garantissant que les versions des dépendances, les chaînes d'outils de compilation et les configurations de bibliothèques restent fixes sur des systèmes hétérogènes.
Détails de l'architecture BSKSim : Une description détaillée de la hiérarchie de classes BSKSim, incluant la séparation des modèles de dynamique et de FSW, les cycles de vie d'exécution des modules (SelfInit, Reset, Update) et l'utilisation de messages de passerelle pour connecter les composants FSW.
Progression du flux de travail : Un guide structuré allant des scripts autonomes simples aux simulations modulaires complexes impliquant le contrôle d'attitude et l'analyse statistique (Monte Carlo).
Intégration de la visualisation : Documentation sur l'intégration de Vizard (basé sur Unity) pour le rendu interactif 3D des états et de la télémétrie des véhicules spatiaux, y compris la gestion de la lecture hors ligne pour les environnements conteneurisés dépourvus de passage direct de GPU.

Résultats
Le flux de travail a été validé par l'exécution de scénarios de simulation allant de la dynamique orbitale de base au contrôle d'attitude avec analyse de Monte Carlo. L'environnement conteneurisé a réussi à :

Construire le framework Basilisk et ses dépendances de manière cohérente.
Exécuter des simulations avec des perturbations $J_2$ et des éphémérides basées sur SPICE (DE430).
Faciliter l'exécution d'ensembles de Monte Carlo de 100 exécutions avec des conditions initiales et des propriétés de masse randomisées.
Permettre l'enregistrement de données et le post-traitement à l'aide d'outils Python standards (NumPy, Matplotlib) et la visualisation via Vizard.
Le processus de construction nécessite généralement 15 à 20 minutes pour la construction initiale de l'image, les reconstructions ultérieures étant nettement plus rapides grâce à la mise en cache des couches Docker.

Signification
L'article affirme que ce flux de travail répond aux défis pratiques du développement de simulations GN&C distribuées en rendant l'environnement de simulation contrôlable par version, auditable et reconstructible à partir d'une seule commande. Il soutient que la conteneurisation simplifie l'intégration des nouveaux membres de l'équipe, réduit la complexité de l'installation de logiciels dans les contextes éducatifs et favorise le prototypage rapide en recherche. En découplant l'infrastructure de simulation des scripts développés par l'utilisateur via des montages liés, l'approche permet une exécution cohérente tout en maintenant la flexibilité dans le développement de scripts. Ce travail étend une présentation antérieure d'atelier en fournissant des détails d'implémentation plus profonds sur le cadre BSKSim et les capacités de Monte Carlo, servant de référence fondamentale pour le déploiement de Basilisk dans des environnements portables et reproductibles.

L'analogie de la « boîte à lunch »

Ce que fait réellement le papier

Pourquoi cela compte (selon le papier)

Le revers de la médaille (limitations)

Articles similaires