1 — Navigation indépendante des capteurs
L’estimateur doit pouvoir survivre à la perte temporaire d’une source et annoncer honnêtement l’augmentation de son incertitude.
BIBLE MARS — DOSSIER DE RÉFÉRENCE
Guidage, navigation et contrôle : le système nerveux d’un véhicule martien
De la première mesure d’un capteur à la commande d’un moteur, comprendre l’architecture qui permet à un véhicule de savoir, décider, agir et vérifier sans attendre la Terre.
FAIT ÉTABLIINGÉNIERIE ACTIVECHOIX PROSPECTIF
Pourquoi ce sujet mérite un dossier entier
Un véhicule spatial n’est jamais piloté par une seule formule. Il possède une chaîne complète qui transforme le monde physique en nombres, les nombres en estimation de l’état, l’état en décisions puis les décisions en actions. Cette chaîne est désignée par GNC, pour Guidance, Navigation and Control. En français, on peut parler de guidage, navigation et contrôle ou commande.
Sur Mars, cette architecture devient centrale parce que la Terre ne peut pas fermer les boucles rapides. Un atterrisseur qui descend, un rover qui évite un rocher ou un cargo qui effectue une correction de trajectoire doit décider localement en fractions de seconde ou en secondes, alors que le délai radio interplanétaire se compte en minutes.
1. Les trois mots doivent rester séparés
La navigation répond à la question « où suis-je, comment je bouge et comment je suis orienté ? ». Elle travaille avec capteurs, modèles et incertitudes. Le guidage répond à « où dois-je aller maintenant ? ». Il construit une trajectoire, une attitude cible ou une consigne. Le contrôle répond à « quelle action faut-il appliquer pour réduire l’écart ? ». Il commande roues, propulseurs, moteurs, gouvernes ou autres actionneurs.
Cette séparation n’est pas seulement pédagogique. Elle permet d’isoler une erreur. Si la trajectoire désirée est correcte mais que le véhicule agit mal, on cherche du côté du contrôle ou des actionneurs. Si l’action est correcte mais fondée sur une mauvaise estimation de position, le problème vient de navigation. Une architecture lisible facilite donc diagnostic, validation et sûreté.
2. L’état : la représentation compacte du véhicule
Un calculateur ne peut pas transporter toute la réalité physique dans sa mémoire. Il utilise un état : position, vitesse, attitude, taux de rotation, parfois masse, biais de capteurs, paramètres atmosphériques ou état des actionneurs. L’état est une représentation suffisante pour les décisions que l’algorithme doit prendre.
Chaque composante possède un repère, une unité, un instant et une incertitude. Oublier l’un de ces éléments revient à mélanger des données incompatibles. Un état fiable n’est donc pas seulement un vecteur de nombres : c’est un ensemble documenté avec conventions et qualité estimée.
3. Les capteurs ne donnent pas directement la vérité
Une IMU mesure des taux de rotation et des accélérations spécifiques ; un star tracker fournit une attitude absolue lorsque le ciel est exploitable ; une caméra observe le terrain ; la radio fournit distance ou Doppler ; un altimètre fournit une distance au sol selon sa géométrie. Aucun de ces instruments ne produit à lui seul un état parfait.
La navigation combine les observations avec un modèle dynamique. Chaque capteur a son bruit, son biais, sa cadence, sa zone de validité et ses pannes. La fusion de capteurs n’est pas une moyenne aveugle : elle utilise les incertitudes, vérifie la cohérence et rejette les mesures incompatibles.
4. De la trajectoire nominale à la consigne instantanée
Le guidage peut suivre une trajectoire précalculée ou recalculer une cible en fonction de l’état observé. Pendant une correction interplanétaire, il fournit l’attitude du vaisseau, le moment d’allumage et le delta-v souhaité. Pendant l’atterrissage, il peut adapter la cible à la vitesse, à l’altitude et aux dangers du terrain.
Une consigne ne doit jamais dépasser silencieusement les possibilités du véhicule. Le guidage doit connaître les limites : poussée disponible, angle maximal, quantité d’ergol, temps d’allumage, contraintes thermiques et zones interdites. L’optimisation mathématique reste soumise à la physique et à la sûreté.
5. Le contrôle ferme la boucle
Le contrôleur compare consigne et état estimé. Un modèle très simple utilise une erreur e = consigne - mesure puis une commande proportionnelle. Les véhicules réels ajoutent dynamique, termes dérivés ou intégrés, prédiction, saturation, allocation entre plusieurs actionneurs et protections logicielles.
Le résultat est remesuré : la roue a-t-elle réellement tourné ? Le moteur a-t-il produit le delta-v prévu ? Le véhicule oscille-t-il ? C’est cette rétroaction qui distingue une boucle fermée d’une simple commande envoyée une fois.
6. Actionneurs : l’algorithme doit finir dans le monde réel
Les roues de réaction produisent un couple interne précis mais stockent progressivement du moment ; les propulseurs fournissent un couple externe au prix d’ergol ; les moteurs principaux changent la trajectoire ; des actionneurs mécaniques orientent antennes, panneaux ou moteurs. Chacun possède résolution, délai, saturation, panne et dynamique propres.
Le logiciel doit convertir une commande abstraite en ordres réalisables : couples par roue, durée d’impulsion par propulseur, angle de gimbal, ouverture de vanne ou vitesse d’un moteur. Cette allocation devient difficile lorsqu’un équipement est indisponible ou limité.
7. Les délais sont dans la boucle, même à bord
Le délai Terre-Mars est spectaculaire, mais une boucle embarquée contient elle aussi des délais : exposition de caméra, lecture du capteur, filtrage, calcul, transmission sur le bus, réponse mécanique et nouvelle mesure. Si ces délais sont trop grands par rapport à la dynamique du véhicule, une commande excessive peut arriver trop tard et provoquer une oscillation.
La stabilité ne dépend donc pas uniquement d’un gain. Elle dépend du système complet. C’est pourquoi les simulations temporelles et les essais hardware-in-the-loop sont précieux : ils confrontent logiciel, délais et équipements réels avant le vol.
8. FDIR : détecter, isoler et récupérer
Fault Detection, Isolation and Recovery signifie détecter un comportement anormal, identifier autant que possible sa source puis reconfigurer le système. Un star tracker ébloui ne doit pas conduire à une commande absurde ; une roue de réaction saturée doit être désaturée ; un capteur incohérent peut être écarté ou mis en quarantaine.
L’autonomie martienne exige des modes dégradés explicites. Le système doit savoir ce qu’il peut encore accomplir après une panne et ce qu’il doit abandonner. « Continuer coûte que coûte » est une mauvaise philosophie : parfois la décision sûre consiste à interrompre une manœuvre, se mettre en attitude de survie et attendre.
9. Redondance : trois équipements ne valent pas trois fois la sûreté
Ajouter un capteur ou un calculateur ne suffit pas. Il faut éviter les défaillances communes : même alimentation, même logiciel, même connecteur, même environnement thermique. Deux calculateurs identiques alimentés par le même convertisseur peuvent tomber ensemble.
La redondance doit être pensée fonctionnellement. Une caméra peut parfois fournir une attitude grossière si un star tracker est perdu ; des propulseurs peuvent reprendre une partie du contrôle si des roues sont indisponibles. La diversité augmente la résilience, mais complique validation et modes de décision.
10. Validation : prouver davantage que « cela marche sur mon ordinateur »
Le GNC est vérifié dans des simulateurs Monte-Carlo, avec dispersions de masse, capteurs, atmosphère, moteurs et états initiaux. On teste les cas nominaux, les limites, les pannes, les données aberrantes et les transitions de mode. Le but est de comprendre la distribution des résultats, pas seulement un scénario parfait.
Les essais au sol incluent parfois bancs dynamiques, tables rotatives, simulateurs de ciel, injections de signaux, tests de boucle fermée et matériel réel connecté au logiciel. La qualification cherche à démontrer que les hypothèses des modèles restent valables face aux variations de fabrication et d’environnement.
11. Le GNC d’une ville martienne dépassera le vaisseau
Une colonie utilisera la même logique dans les rovers de transport, grues, drones, foreuses, véhicules pressurisés, plateformes d’atterrissage, antennes orientables et systèmes de rendez-vous. Position, attitude, consigne, action et rétroaction deviennent un langage commun de l’automatisation martienne.
Créer une référence locale de navigation, des standards de temps et des interfaces communes pourrait permettre à des machines de fabricants différents de partager cartes et états. Le GNC devient alors une infrastructure numérique de la ville, au même titre que l’énergie et les communications.
12. L’humain reste dans la boucle stratégique
Autonomie ne signifie pas absence d’humain. Les équipages et équipes terrestres définissent objectifs, limites, critères d’abandon, paramètres et procédures. Le logiciel ferme les boucles rapides et exécute dans l’enveloppe autorisée.
Cette répartition est particulièrement adaptée à Mars : la Terre garde un rôle d’expertise et de supervision différée ; les humains sur place et les automatismes gèrent le temps réel. Une gouvernance technique claire évite deux extrêmes : télécommander l’impossible ou déléguer sans contrôle.
18. Validation : du simulateur à l’essai matériel
Une loi de contrôle élégante sur ordinateur ne suffit pas. Il faut confronter les modèles aux délais de calcul, au bruit des capteurs, aux saturations, aux non-linéarités, aux erreurs de montage, aux dispersions de masse et aux pannes. Les essais peuvent progresser du modèle logiciel vers le matériel dans la boucle, puis vers des essais sur banc et des démonstrations dans un environnement aussi représentatif que possible.
La question de validation doit rester simple : quelles erreurs avons-nous injectées, quelles limites avons-nous atteintes et qu’a fait le système ? Une Bible martienne utile doit montrer que la performance nominale n’est qu’une partie de l’ingénierie. La confiance vient surtout de la compréhension documentée des marges, des modes de défaillance et des comportements hors nominal.
17. Modes dégradés, mode sûr et reprise
Un système de référence n’est pas seulement capable de fonctionner lorsque tout va bien. Il sait aussi réduire ses ambitions. Perdre un star tracker peut conduire à un mode utilisant gyroscopes et capteurs solaires. Perdre un actionneur peut imposer des limites de manœuvre. Une incohérence entre capteurs doit déclencher une stratégie de comparaison, d’isolement et éventuellement de retour à un mode sûr plutôt qu’une confiance aveugle dans la dernière valeur reçue.
Pour une base martienne, cette philosophie s’étend aux engins de surface : ralentir, s’arrêter, se mettre à l’abri, conserver l’énergie et demander une validation locale peut être préférable à poursuivre une tâche avec une navigation incertaine. Les modes dégradés doivent être conçus, simulés et testés avant la panne ; improviser le mode de secours après l’anomalie signifie que le système n’était pas réellement tolérant aux fautes.
16. Fréquences de boucle et hiérarchie temporelle
Toutes les fonctions GNC ne travaillent pas au même rythme. Une boucle interne de stabilisation peut devoir réagir des dizaines ou centaines de fois par seconde, alors qu’une planification de trajectoire stratégique se met à jour beaucoup moins souvent. Mélanger ces échelles conduit à des systèmes fragiles : une décision lente ne doit pas bloquer une correction rapide, et une fluctuation de capteur ne doit pas faire changer le plan de mission chaque milliseconde.
La conception doit donc définir qui calcule quoi, à quelle fréquence, avec quelle priorité et avec quel comportement lorsqu’une donnée arrive en retard. Cette hiérarchie devient particulièrement importante sur Mars, où des opérations locales doivent rester sûres sans attendre une réponse terrestre et où les calculateurs embarqués peuvent être limités par l’énergie, la température ou la tolérance aux radiations.
15. Actionneurs : produire réellement le couple demandé
Le contrôle d’attitude peut utiliser des roues de réaction, des propulseurs, des actionneurs aérodynamiques lorsque l’environnement le permet, ou d’autres dispositifs spécialisés. Une roue de réaction échange du moment cinétique avec le véhicule : en accélérant la roue dans un sens, le corps tourne dans l’autre. Mais la roue ne peut pas accélérer indéfiniment ; elle atteint une limite de vitesse ou de moment stocké et doit être désaturée par un couple externe.
Autour de la Terre, des magnétocoupleurs peuvent exploiter le champ magnétique ambiant sur certaines plateformes. Pour une mission interplanétaire ou martienne, l’architecture doit vérifier si le champ disponible et la dynamique de mission rendent cette solution pertinente ; elle ne peut pas être transposée automatiquement. Les propulseurs sont plus universels mais consomment du propergol et introduisent des contraintes thermiques, mécaniques et de contamination.
14. Capteurs absolus, capteurs relatifs et dérive
Un gyroscope mesure très bien une variation rapide d’orientation, mais son erreur intégrée finit par dériver. Un star tracker fournit une référence absolue très précise à partir du ciel étoilé, mais il peut être aveuglé, indisponible pendant certaines manœuvres ou limité par son champ de vue. Un capteur solaire est simple et robuste mais n’offre pas toutes les informations nécessaires. La solution n’est donc généralement pas de choisir « le meilleur capteur », mais de combiner des capteurs dont les défauts sont différents.
Le même principe vaut pour la position. Une centrale inertielle offre une continuité immédiate mais dérive ; une image du terrain, une mesure radio ou une observation orbitale peuvent recaler l’estimation. Une cité martienne qui opère rovers, drones, grues, atterrisseurs et véhicules pressurisés doit penser en termes de fusion de capteurs et de niveaux de confiance, pas en termes de coordonnées miraculeusement exactes.
13. Une architecture GNC n’est pas un « pilote automatique » unique
Dans un véhicule spatial, les fonctions de guidage, de navigation et de contrôle ne sont pas trois mots décoratifs placés dans un même sigle. La navigation estime l’état du véhicule : position, vitesse, orientation et parfois biais des capteurs. Le guidage décide quel état il faudrait atteindre ensuite. Le contrôle transforme cet écart en commandes envoyées aux actionneurs. Une défaillance peut donc provenir de trois endroits très différents : mauvaise connaissance de l’état, mauvaise consigne, ou mauvaise exécution de la consigne.
Cette séparation est essentielle pour diagnostiquer une anomalie. Si un atterrisseur croit être incliné de deux degrés alors qu’il est droit, le contrôleur peut très bien exécuter parfaitement une mauvaise correction. Si l’estimation est correcte mais qu’une roue de réaction sature, la commande demandée ne peut plus être produite. Une architecture robuste doit observer ces trois niveaux séparément et vérifier la cohérence entre capteurs, estimateurs, lois de guidage et actionneurs.
23. Glossaire opérationnel minimal
Attitude : orientation du véhicule. État : ensemble des variables nécessaires pour décrire la situation dynamique. Estimateur : algorithme qui combine modèle et mesures. Consigne : valeur que le système cherche à atteindre. Actionneur : équipement qui produit effectivement une force ou un couple. Saturation : limite au-delà de laquelle l’actionneur ne peut plus augmenter son effort.
Biais : erreur systématique qui décale une mesure. Dérive : croissance progressive d’une erreur au cours du temps. Mode sûr : configuration destinée à préserver le véhicule lorsqu’une anomalie grave apparaît. Redondance : présence de moyens alternatifs, utile seulement si une cause commune ne peut pas les neutraliser simultanément.
22. Les interfaces humaines du GNC
Même très autonome, un système doit présenter aux opérateurs une image compréhensible de son état : position estimée, attitude, vitesse, qualité de navigation, capteurs invalides, actionneurs saturés et mode actif. Afficher uniquement des coordonnées et des angles sans leur incertitude crée une fausse confiance.
Les commandes humaines doivent elles aussi être conçues contre les erreurs : confirmation des actions irréversibles, limites de sécurité, simulation de la conséquence avant exécution et journalisation. Sur Mars, l’opérateur local doit pouvoir reprendre la main sans dépendre d’une équipe terrestre située à plusieurs minutes-lumière.
21. Définir l’autorité de contrôle
L’autorité de contrôle désigne la capacité réelle d’un ensemble d’actionneurs à corriger les perturbations et suivre les consignes. Elle dépend du couple ou de la force disponibles, des bras de levier, de la masse, des moments d’inertie, du temps disponible et des limites d’utilisation. Une commande numérique de 100 % ne crée pas une capacité physique qui n’existe pas.
Les exigences doivent donc préciser les perturbations à rejeter et les manœuvres à réaliser avec marge. Pour un atterrisseur, cela peut inclure asymétries de poussée, vent et dispersions de masse ; pour un habitat mobile, dévers, adhérence et panne d’un actionneur. L’ingénierie robuste demande ce que le système peut encore contrôler après une panne plausible.
20. Cas concret : un rover rapide sur un terrain incertain
Un rover qui roule lentement peut parfois s’arrêter dès qu’un doute apparaît. Un véhicule plus rapide a besoin d’une boucle perception-navigation-guidage-contrôle suffisamment courte pour détecter une pente, estimer sa position, choisir une trajectoire et appliquer direction ou freinage avant d’avoir parcouru une distance dangereuse. Le temps de calcul devient alors une distance de sécurité.
À 10 mètres par seconde, un retard supplémentaire d’une seconde représente déjà 10 mètres parcourus avant réaction. Cette relation élémentaire suffit à comprendre pourquoi l’autonomie locale, la latence logicielle et la fréquence de mise à jour sont des paramètres de sûreté, pas de simples détails informatiques.
19. Cas concret : un véhicule de descente doit rester orienté pendant un freinage
Imaginons un véhicule qui doit freiner tout en maintenant son axe de poussée dans une direction précise. Les gyroscopes détectent les rotations rapides, un estimateur reconstruit l’attitude, le guidage fournit une consigne d’orientation et le contrôle commande les propulseurs ou les actionneurs disponibles. Si le centre de masse réel diffère du modèle, la poussée peut créer un couple imprévu ; le contrôleur doit le compenser tant qu’il reste dans son domaine d’autorité.
Ce simple scénario montre pourquoi masse, propulsion, structure et GNC ne peuvent pas être conçus séparément. Une modification de charge utile peut déplacer le centre de masse, changer les moments d’inertie et modifier la réponse dynamique. Chaque évolution matérielle importante doit donc entraîner une revalidation du modèle de contrôle et des marges d’actionnement.
COUCHE EXPERTE — ARCHITECTURE DE SYSTÈME
Concevoir un GNC martien comme un système de sûreté, pas comme un simple algorithme
Un GNC de référence doit rester compréhensible depuis le capteur jusqu’à l’actionneur. Chaque transition possède une unité, une incertitude, un délai, une limite et un comportement en cas de panne.
2 — Guidage borné par la physique
Une trajectoire ne doit pas demander une poussée, un angle ou une énergie que le véhicule ne possède pas.
3 — Contrôle avec saturation explicite
Les limites d’actionneurs sont intégrées dans la commande afin d’éviter des états internes incohérents.
4 — FDIR et modes dégradés
Chaque panne critique possède des critères de détection, une réponse et une stratégie de retour à un état sûr.
À vérifier avant de dépendre du système
- repères et temps cohérents
- capteurs calibrés avec incertitudes documentées
- simulateur dynamique validé
- modes de panne et transitions testés
- saturation des actionneurs gérée
- journalisation et traçabilité des décisions
- autorité locale définie en cas de perte Terre
Ce que cela change pour une vraie cité martienne
Pour une cité martienne, le GNC ne doit pas être traité comme un logiciel propriétaire invisible présent dans chaque machine. Les interfaces de position, temps, cartes et diagnostics gagneront à être standardisées afin qu’un rover puisse partager sa localisation avec une grue, qu’un drone puisse recevoir une zone interdite commune et qu’une équipe de secours puisse comprendre l’état d’un véhicule d’un autre constructeur.
La référence absolue ne sera pas un algorithme unique, mais une culture d’ingénierie : conventions explicites, données datées, estimation d’incertitude, validation, redondance et droit de passer en mode sûr. C’est cette culture qui transforme l’autonomie en fiabilité plutôt qu’en opacité.
Apprendre les calculs dans Space Academy
Sources institutionnelles et primaires
Approfondir avec Arcadia
Le dossier public reste autonome. Arcadia — Manuel de la première cité martienne développe ces systèmes comme une architecture intégrée de ville martienne.