L'objectif est de rétro-concevoir la commande du retour d'un propulseur de fusée, Super Heavy. Le propulseur passe par plusieurs phases lors de sa descente, avec des moyens de guidances différents dans un environnement perturbé (aérodynamiquement, erreurs de commandes et autres). Une chose aussi compliquée à expliquer bloquée derrière un écran d'ordinateur est plus que dommage, et empêche de vulgariser la science au grand public, c'est une des raisons de pourquoi je veux reproduire ma simulation à échelle humaine dans une cellule robotisée. Et enfin, utiliser cette reproduction physique pour mettre en place une simulation "hardware-in-the-loop", où j'utilise la lecture de vrais capteurs montés sur mes maquettes, pour alimenter ma simulation.

Les différentes étapes incluent :
- Descente (guidance à l'aide des grilles aérodynamiques)
- Freinage (allumage de ~13 moteurs)
- Dernière manoeuvre (retour de Super Heavy sur les bras de la tour avec 3 moteurs)

Mon étude commence à 40km d'altitude, avant que l'atmosphère ne soit assez dense pour avoir une influance sur la trajectoire du propulseur.
Actuellement, ma principale occupation est de m'assurer que mon projet est faisable, je m'occupe donc de faire fonctionner et coordonner toutes les parties du projet : un proof-of-concept. Je m'appuierais à la précision et aux très fins détails une fois tout cadencé.

ProxSim, logiciel de simulation/contrôle à distance.
Interface en développement

Voici mon environnement de simulation, avec un modèle simpliste de Super Heavy. J'ai implémenté l'export de données en CSV, mon contrôleur de vol, et une interface pour interagir avec la simulation et avec les autres composants de mon projet (maquettes, cellule robotisée FANUC).
Super Heavy pour l'instant se tient "droit"/"debout" en tournant ses moteurs (guidance par TVC, Thrust Vector Control), peu importe sa position de départ, à l'aide de simples PIDs. Cet objectif fût surtout un bon prétexte pour mettre en place une simulation contrôlée, stable et réaliste.

On peux voir au centre de l'écran, l'environnement de simulation MuJoCo, avec le propulseur. Et sur le reste de l'écran, une interface ImGui me permet de mettre en pause, relancer la simulation, modifier la caméra, modifier mes conditions initiales et relever la télémétrie importante comme l'altitude du propulseur, son accélération ou l'état de ses moteurs. Je peux aussi depuis cette interface contrôler la cellule robotisée FANUC, autant pour envoyer des commandes manuelles simples de mouvement, ou des suivis de trajectoires complexes (c.f. partie Contrôle de la cellule robotisée).

Dans mon environnement de simulation, mon cycle de contrôle s'exécutera à 50Hz. Je peux donc à la même fréquence relever la position et l'orientation du propulseur, pour l'envoyer au FANUC.
Un début fût d'utiliser la librairie Fanucpy de Agajan Torayev, et le tout fonctionnait très bien après adaptation pour le controlleur R-30iA. J'ai réécrit la librairie Python en C++, et incorporé les contrôle dans mon interface ProxSim. Mais avec la manière que fonctionnait les mouvements, le robot s'arrêtait à chaque point. Evidemment, un objet tombant du ciel ne prend pas de pause... J'ai donc modifié les drivers-robots écrits en Karel et ai refait un programme TP (nécessaire pour le mouvement) spécifique pour mon utilisation. Voici comment il fonctionne :
A chaque point reçu, le programme Karel calcule la trajectoire qui sera effectuée par le robot par petit bouts. Chaque trajectoire est coupée en ~50 positions intermédiaires sur lesquelles le robot passe en CNT100. La trajectoire est calculée selon une courbe de Bézier entre sa position actuelle et la nouvelle position reçue (sur les 6 composantes du repère WORLD), et met à jour les registres de position.
Pendant ce temps, le programme TP itère sur les registres de positions (1 à 50), et passe à un nouveau groupe de positions (registres de 51 à 100) à chaque fois qu'un point est reçu. Utiliser deux "groupes" de registres permet de ne pas écrire sur un registre en lecture par le programme TP (car concurrence entre le programme Karel et programme TP).
De plus, le controlleur FANUC fait déjà un calcul de trajectoire avec les options CNT qui lisent quelques positions en avance de la position actuelle. Ainsi la position "actuelle" pour mon calcul de trajectoire est en réalité, la prochaine sous-position.
Découper les trajectoires en suite de sous-position me permet aussi d'éviter l'utilisation d'un SKIP CONDITION, qui ralentit obligatoirement le mouvement jusqu'à une vitesse nulle.

Résultats ? Je peux envoyer la trajectoire du propulseur dans ma simulation, point par point, et le robot la reproduit à l'identique, sans appliquer de perturbations superflues sur les capteurs de mes maquettes.
La vidéo présente le robot, recevant des points aléatoires dans un plan, avec des instructions de vitesses aléatoires. Il s'arrête s'il a atteint sa dernière cible, et les mouvements sont parfois saccadés sont causés pas le point de contrôle de la courbe de Bézier : le début de la courbe de Bézier n'est pas encore aligné avec la direction que le robot se déplace, la solution est sur papier, prête à implémentation.

En utilisant différentes informations officielles de SpaceX et des centaines de clichés de journalistes/reporters, je modèlise le propulseur sur Autodesk Fusion.
Le vrai propulseur fait 69 mètres de hauteur pour 9 mètres de diamètres, ma maquette fait donc 50 centimètres de haut, assez large pour contenir une breadboard.
Vous pouvez apercevoir ces modélisation dans cet outil de visualisation rudimentaire.

Maquette Super Heavy

Intérieur de la maquette

La maquette de Super Heavy comporte une batterie 15V et alimente une ESP32 (carte logique programmable, avec communications sans-fils) ainsi que deux centrales inertielles MPU-6050.
Pour faire rentrer le propulseur dans mon imprimante 3D, je le découpe en 3 morceaux :
- La partie haute actionnera les grilles aérodynamiques, mais est vide pour l'instant
- La partie centrale, contient les cartes logiques/capteurs
- La partie basse, où repose la batterie

Le tout s'assemble uniquement avec des vis, mais se fragilise avec les acrobaties exécutées par le robot FANUC.
La partie centrale proche du centre de gravité possède aussi l'attache pour le monter sur le robot, faite aussi sur mesure.

The objective is to reproduce the return of the Super Heavy rocket booster back to its launch site. Keeping this in a simulation (while Robotics are for real-world applications) would be both a shame for an academic project (limiting myself this close) and a shame to explain it to a broader audience seeking physical interactions instead of virtual cylinders moving. This make a reason to reproduce this maneuver in a smaller scale robotic cell. (Another reason being to work with a FANUC assembler before going into FANUC competitions). And then going even further by making this a "hardware-in-the-loop" simulation, the goal is to use real sensors and actuators for the simulation : making the mockup believe it is really flying. These type of simulation are widely used in aerospace industries, offering me experience and validating my solutions' robustness in limited real world scenarios (I'm not working on a real subscaled rocket with propulsion).

During its return, the booster :
- Descends at high speeds (up to Mach4 depending on air density)
- Lights up sequentially 13 engines to decelerate
- Down to 3 engines, execute a final maneuver to rests itself on two arms mounted on the launch tower (with slight tolerences on speed and orientation).
(This is what should happen in a perfect scenario, but engines might not light up, or fail, on which case the system makes its best)

My study's context starts at 40km altitude, with the booster properly oriented before atmospheric reentry, on a ballistic trajectory a small distance short of the launch site.
I've achieved a proof-of-concept, making all the parts work and properly communicate with minimum viable solutions. I'm now into making it all more efficient, apply stress tests and researches about the final controller. (As well as presenting my project to a few visitors).

ProxSim, simulation and remote control software.
UI content is in progress

When the booster descends, it guides itself with the help of 3 (formerly 4) grid fins at the top of the structure, and by rotating them, gives the booster control of its direction and angle-of-attack.
When engines are lit, it can maneuver by rotating "all" of its engines, so my goal is to say how each engines should be oriented (2 degrees of freedom) and how much thrust they need to deliver. Here is my simulation software (ProxSim), with a simple model of Super Heavy V2. I can follow/save telemetry and implemented a small PID flight controller (allowing the booster to stay upright at all times). ProxSim is also able to communicate with my mockups (remote monitor, and control) as well as the FANUC arm (move, current positions and start custom KAREL/TP programs). Managing this simulation environment was my first steps into this project as it is crucial and complex with many parameters and a need for stability. Gimballing cylinders on which I apply multiple Meganewtons of force and keeping them still was a source of simulation instability for example, but everything is now corrected.

You can see in the user interface that I can pause, reset the simulation, follow real-time telemetry with graphs and simulation's health, change the scene's cameras, edit initial position of the booster at the start of the simulation, as well as remote manual control of the FANUC, and a custom spline program I will detail more in this page.

My future job will most likely be in manufacturing, so I need experience with real industrial machines, and my school has quite a few. I was given the green light to use the biggest of the school : the FANUC M-10iA with a R-30iA Mate controller.
The goal of the FANUC is to perfectly mimic in real time, a smooth movement that happens into my simulation. It needs precision & reactivity as deviations might pile up into my sensors readings, making their readings fundamentally wrong.

The only data I have for it are position and speed of the booster at 50Hz, that I'm able to send via network socket messaging.
I started using the Fanucpy library from Agajan Torayev (KAREL programs), allowing remote commands on the robot by the network, and it worked great after adapting it to my controller (the library is made for the R-30iB controller). But continuous real-time movement were not possible :
This library works as follows : a KAREL program uses one of the controller's servers to receive messages and send responses. To move, the KAREL program would fill a few registers (with position, velocity and options) and run a TP program using these registers. However, once a move command was sent, the KAREL program stopped until the TP move program has been completed. Making the TP program use SKIP options would interrupt the robot's movement and resume the KAREL program, still making the robot stop. So I made my own extension (the Spline program) : When started, I start a TP program that wait for a digital output to switch, and would then iterate on position registers filled with intermediate positions (between current position, and command's target). When the KAREL program receives a new target position, it calculates the Hermit curve and stores small steps into position registers, and signals the change by switching a digital output the TP program was waiting for. A rocket booster falling off the sky do not take any coffee break, and so my program doesn't either !
This is an engineer approach, that differs from buying the FANUC "Dynamic Path Modification" option at an undisclosed price. So I edited his library to make my use case work, and will be shared online as open-source in the near future.
This chapter ends with my robotic arm recreating the trajectories of my simulation.
This video shows the robot running my spline program to reach random points of a plane, at various speeds. It stops when it reached its target, and redirects into a curve if a new target in sent before reaching the previous one. The sometimes blocky movements are from a known issue, with a known solution, currently being fixed (I first implemented Bezier curves instead, and the middle control point was greatly simplified for prototyping, Hermite curves doesn't need a weird control point).

I need to model and 3D print a rocket booster and a tower, at a ~1:144 scale (so the booster is ~50cm / ~20 inch tall), and to showcase my project seriously in front of any audiences, my mockups need to look polished and detailed compared to the real booster.
The model you see in the video is my first 3D CAD project, but it's a "V2" design. I'm finishing design on a whole redesigned "V3" bringing more details, grid fins actuators, and a design made with much more CAD & 3D printing experience.
A mockup tower also need to be done, and early development of the tower main structure and catch arms "Chopsticks" are done. Making the tower is not a priority, as the electronics are already prepared, the tower will only be needed once the simulation is perfect.
Using SpaceX official information and hundreds of pictures/videos made by local reporters, I'm making my design as accurate to the real booster as possible.
While adding the rotating grid fins on the "V3" version, the real "V3" booster will get caught by the grid-fins. For my version, it is not a good idea to make sensible components structural, so the catch structure will be part of the main body, like in "V2". The scale I settled on is big enough to hold usual prototyping hardware for compute, actuation and power.

Official renders comparing Super Heavy Version 2 and 3

Super Heavy mockup

Mockup interior

My Super Heavy mockup holds a 12V battery that powers an ESP32 programmable board, two 6-axis accelerometers and 3 servo-motors.
The booster is made in four parts :
- The hot stage ring, very small, to close the top
- The grid fins area, where the grid fins are actuated and servos mounted
- The middle part, holding the breadboard and the two aligned accelerometers
- The lower part, where is situated the battery

Everything locks itself with custom "twist hooks" with stable positions, as the previous version tightened with screws was getting loose with all the acrobatics done on the FANUC. It is not yet prited, but this locking mechanism is promissing, with multiple redundency points according to the pieces masses, and tolerences playing in favor of the locking.
The middle parts have the attach point for the FANUC, as it is the nearest to the gravity/pressure center of the real booster, but the bottom bettery part is by far the heaviest.
All communications to/from the mockups are wireless, via WiFi.