Tesla a présenté son nouveau Roadster : la tech derrière son kickflip

Près de neuf ans après sa première présentation, le nouveau Roadster de Tesla a été dévoilé le 15 octobre, sur un site d'essais de SpaceX au Texas. Le lieu n'a rien d'anodin : sur scène, Elon Musk a présenté la voiture comme le fruit du travail main dans la main des ingénieurs de Tesla et de SpaceX.

Les images ne vous ont probablement pas échappé : la voiture a grimpé une rampe incurvée jusqu'à se retrouver la tête en bas, puis y est restée suspendue, défiant les lois de la physique (en apparence du moins : un système de succion active par ventilateurs aspirait l'air sous son plancher pour la plaquer contre la paroi). Elle s'est ensuite décrochée, retournée en l'air, et posée en douceur dans le panache blanc de ses propulseurs.

Pour sa seconde démo, le Roadster a sauté par-dessus une rangée de Tesla, dont un camion Semi de la marque, tout en faisant un tour complet sur lui-même : le fameux kickflip à la Rocket League.

Personne à bord pendant ces démos : la voiture était techniquement autonome pour l'occasion, "pour s'assurer de ne tuer personne", a précisé Musk sur scène.

Je ne sais pas vous, mais impossible pour moi de ne pas regarder ça avec des yeux d'enfant : la voiture volante, on me la promet comme le futur depuis que je suis gamin, et en voir une qui décolle pour de vrai, ça fait quand même quelque chose.

Évidemment, on pense ce qu'on veut de Musk, mais sa méthode ne change pas : prendre la science-fiction au pied de la lettre, quitte à visser des propulseurs de fusée sur une voiture de sport.

Ces propulseurs, Elon Musk les promettait déjà en 2018, dans un pack d'options SpaceX qui en comptait une dizaine, répartis tout autour de la voiture. Huit ans plus tard, les voilà.

Sur scène, il a également décrit l'architecture de l'engin : des propulseurs de contrôle d'attitude et des propulseurs principaux à l'arrière, de quoi voler comme une fusée.

Une filiation que Tesla assume : SpaceX utilise des propulseurs pour orienter ses engins spatiaux depuis des décennies, mais les faire fonctionner dans une voiture plutôt que dans le vide a demandé une nouvelle approche au niveau matériel et système.

Même famille de problèmes, donc, et tout porte à croire que la manière de les résoudre, dans le code, est largement la même : Tesla n'a pas (encore) communiqué sur le sien, mais chez SpaceX, on a déjà raconté comment on s'y prenait sur les fusées.

Un air de famille

Les initiés n'auront évidemment pas manqué de reconnaître la famille des propulseurs à gaz froid de SpaceX : même principe et même type de réservoirs, éprouvés (parfois jusqu'à l'explosion 👀) depuis des années.

Le premier étage de Falcon 9, la fusée de SpaceX, a d'ailleurs lui aussi droit à son propre flip : juste après la séparation, des propulseurs à gaz froid le retournent pour préparer son retour.

Rien ne brûle dans ces propulseurs : le gaz sous pression s'échappe par une buse et pousse l'engin dans l'autre sens.

Sur Falcon 9, ce gaz, c'est de l'azote, tout comme sur le nouveau Roadster, dont les dix tuyères puisent dans deux réservoirs totalisant 600 litres, selon Lars Moravy, responsable ingénierie chez Tesla.

Les réservoirs sont des COPV, des bouteilles légères à paroi fine enveloppée de fibre de carbone, conçues pour encaisser des pressions énormes. Tesla indique avoir logé un COPV dans chaque recoin disponible de la voiture : plus de gaz comprimé à bord, c'est mathématiquement plus de temps de vol possible.

Ces bouteilles, SpaceX les connaît plutôt bien. Sur Falcon 9, elles ne stockent pas que l'azote des propulseurs : d'autres, remplies d'hélium, maintiennent sous pression les réservoirs de kérosène et d'oxygène liquide pendant le vol.

En juin 2015, le support de l'une d'elles cède dans le réservoir d'oxygène liquide du second étage, et la Falcon 9 de la mission CRS-7 se disloque en vol. Rebelote en septembre 2016 : de l'oxygène s'infiltre sous la fibre de carbone d'une autre bouteille d'hélium et s'enflamme, et la fusée explose sur son pas de tir, avec le satellite qu'elle embarquait.

Le même type de réservoir, poussé dans ses retranchements sur les fusées, se retrouve aujourd'hui dans une voiture de sport.

Dix tuyères à ouvrir au bon moment

Quel que soit l'engin, la logique de base est celle qu'un ingénieur logiciel de SpaceX résumait en 2020 : presque tout peut s'exprimer comme une boucle de contrôle temps réel.

On lit les capteurs, on prend une décision à partir de leurs mesures et de l'état précédent, puis on envoie le résultat au matériel. Et on recommence, de (très) nombreuses fois par seconde.

Sur un engin spatial, la vanne d'un propulseur à gaz froid est en général ouverte ou fermée. Pour doser la poussée, le logiciel joue donc sur la durée et l'espacement de ses impulsions.

C'est le principe de la modulation de largeur d'impulsion (PWM), celle qui fait varier l'intensité d'une LED sur un Arduino, ou de sa cousine la PWPF, qui joue aussi sur leur fréquence. Tesla évoque des actionneurs électriques capables de micro-ajustements en une fraction de seconde, sans préciser si ses vannes savent s'ouvrir à moitié.

Pour faire pivoter l'engin, le freiner ou le soulever, le logiciel doit par la même occasion choisir quelles tuyères allumer et dans quelle proportion : c'est l'allocation de commande, déjà un petit sujet d'optimisation en soi.

À mesure que le réservoir se vide, la pression baisse, et la poussée avec elle. Dans un système non régulé, le logiciel devrait compenser, par exemple en allongeant ses impulsions selon la pression mesurée.

Gérer une réserve qui s'épuise, sans pouvoir recommencer une manœuvre ratée en plein vol, c'est exactement le genre de casse-tête que SpaceX a dû résoudre pour poser ses fusées (au moteur principal cette fois, les propulseurs à gaz froid ne servant qu'à l'orienter).

Calculer plus vite que son ombre

Bien que l'équipe logicielle de SpaceX ne soit pas en mesure de détailler ses algorithmes d'atterrissage, Lars Blackmore, qui a dirigé ces travaux, en a dit davantage dans un article de la National Academy of Engineering.

Pour se poser, le premier étage doit atteindre une vitesse nulle exactement à altitude nulle. Trop bas, il s'écrase. Trop haut, il se met à remonter, et il ne reste plus qu'à couper les moteurs : la fusée retombe, et le résultat est le même.

Il faut donc calculer à bord, en une fraction de seconde, une trajectoire jusqu'à la cible : sans solution à temps, c'est le crash, et une solution sous-optimale peut épuiser le carburant avant l'arrivée.

La parade s'appelle l'optimisation convexe. Ce qu'on cherche, c'est la trajectoire qui consomme le moins de carburant parmi toutes celles possibles. On peut se la représenter comme le point le plus bas d'un paysage mathématique, où chaque point est une trajectoire et son altitude le carburant qu'elle consomme.

Quand le problème est convexe, ce paysage ne compte qu'une seule vallée, sans creux secondaire où se faire piéger, et les algorithmes en atteignent le fond, à la précision voulue près, en un nombre d'étapes qu'on peut borner à l'avance.

C'est cette garantie qui permet de promettre une réponse avant que la fusée ne touche le sol.

Sauf qu'au départ, l'atterrissage d'une fusée n'est pas un problème convexe, ne serait-ce que parce qu'un moteur-fusée ne peut pas descendre sous un certain seuil de poussée. Des chercheurs du JPL ont cependant montré qu'on pouvait le reformuler en problème convexe sans rien perdre.

Blackmore cosigne leur algorithme pour Mars, G-FOLD. Sur Terre, où l'atmosphère est cent fois plus dense, le problème change, mais SpaceX le résout elle aussi par optimisation convexe, calculée à bord.

Pour que ce calcul tienne dans la fraction de seconde disponible, SpaceX utilise CVXGEN, un outil de Stanford qui génère un solveur en C sur mesure à partir de la description mathématique du problème. Le code produit est simple, sans bibliothèque externe et presque sans branchement, donc très prévisible à l'exécution.

Le papier de CVXPYgen, un générateur open source cosigné par Stephen Boyd, cocréateur de CVXGEN, l'écrit noir sur blanc, en citant Blackmore : SpaceX utilise CVXGEN pour générer son code de vol.

Pour tester le principe chez vous, un pip install cvxpygen suffit (désolé, la fusée n'est pas fournie).

Pas de malloc en plein vol

En 2020, l'équipe logicielle de SpaceX a détaillé sa stack : C++ pour les systèmes de contrôle des véhicules, Python pour les outils et les tests, HTML, JavaScript et CSS pour les écrans (ceux de Crew Dragon tournent dans Chromium).

Les ordinateurs de bord des fusées et des capsules de SpaceX tournent soit sous Linux avec le patch PREEMPT_RT, qui rend les temps de réponse du noyau bien plus prévisibles, soit sur des microcontrôleurs en bare metal, sans système d'exploitation.

Les priorités des processus et des threads du noyau sont réglées pour éviter les inversions de priorité, quand une tâche critique se retrouve bloquée par une tâche secondaire.

En 1969, c'est déjà un tri par priorités qui avait sauvé l'alunissage d'Apollo 11 : surchargé pendant la descente, l'ordinateur du module lunaire avait abandonné ses tâches secondaires pour se consacrer à celles dont dépendait l'atterrissage.

La plupart des logiciels de contrôle de SpaceX tournent sur un seul thread, pour éviter les surprises de la synchronisation. L'équipe évite aussi d'allouer de la mémoire en cours d'exécution comme d'écrire des boucles sans borne.

L'entreprise dit également appliquer une bonne partie des règles du Power of 10, dix commandements du code critique rédigés au JPL de la NASA.

Pour encaisser les pannes, plusieurs ordinateurs calculent la même chose et votent sur le résultat : si l'un d'eux flanche, les autres prennent le relais. La NASA exige de Crew Dragon qu'il tolère deux pannes.

Même si Tesla n'a rien communiqué à ce jour sur le sujet, tout cela aurait bien sûr sa place dans la voiture présentée au Texas : une boucle de contrôle qui dose chaque tuyère à la volée, une répartition de l'effort entre dix propulseurs, une trajectoire à calculer avant le retour au sol, et un code assez déterministe pour tenir ce rythme.

Tesla affirme que le matériel et le système de contrôle sont nouveaux, et la tech d'une fusée n'est de toute évidence pas celle d'une voiture. Difficile pourtant de croire que rien du code que SpaceX exploite sur ses fusées n'ait servi au Roadster : la collaboration revendiquée entre les deux entreprises en est d'ailleurs le meilleur indice.

Un code fiable ne fait pas pour autant une voiture sûre, et Musk l'a reconnu lui-même : le Roadster présenté n'est pas forcément optimisé pour la sécurité.

Les détracteurs n'ont pas tardé à voir dans cette démo davantage un coup marketing qu'une prouesse technique. D'autant que la version qui vole, baptisée Rocket (une monoplace, commandable sur invitation seulement), n'est pas homologuée pour la route, et ne pourra probablement jamais l'être.

La Thrust, avec ses propulseurs arrière uniquement, est présentée comme une voiture de circuit, et seule la Performance, sans propulseurs, devrait être homologuée pour rouler sur la voie publique.

Reste qu'une voiture qui décolle, tourne sur elle-même et se repose toute seule, en direct, dit assez bien où en est la technologie aujourd'hui.

Quant à sa date de sortie, annoncée cette fois pour 2028, c'est un problème pour lequel aucun solveur ne peut encore garantir une solution en temps borné.