Simulation & Control Software : ProxSim

I need an environment where the physics simulation happens, and where it can send movements/receive sensor data. This is why I made my own software in C++, using MuJoCo for the physical simulation, and ImGui or the interface. MuJoCo is an open-source simulation engine that is widely used in AI Robotics at Nvidia and Google Deepmind, and ImGui is a widely used open-source library for building user interfaces in C++. Applying multiple Meganewtons of force on rotating engines and keeping the simulation stable was a difficult job.

The whole goal of "Control" is to tell the booster what to do by itself. This problem is unpredictable and it needs to work even if an engine can't start, if there is cross-wind, if a grid fin is stuck, it is a sort of sentience. As of today, a simple controller (PID) is implemented to hold the booster upright, far from the end-goal : Model Predictive Control.

Model Predictive Control (MPC) is a state representation of a system, and an optimization algorithm. Given a state X of the system, its model (A,B,C,D) (physical model like mass, inertia, response to commands), it estimates the future to reach a setpoint.

A is the free-response of the system (given no command, the booster simply falls). B is how the system behaves to commands (torque, force, fuel consumption). C is what is measurable (the position of the booster is measurable, and is a goal/setpoint of the controller. D is often 0 (the command has no direct consequences)

Hardware-in-the-Loop Architecture

For this mockup, I need both aesthetic (to be appealing to people) and be a solid work horse. The Super Heavy mockup needs to have 3 actionable grid fins, a way to measure its position relative to the Tower mockup, wireless communications, onboard compute, and be attached to the FANUC arm. I made multiple booster mockups and here is the current one Instead of a pure software simulation, the booster mock-up is physically mounted to the end of a FANUC industrial robotic arm. The arm executes the exact trajectory that the simulated catch maneuver would require, providing realistic inertial loads and kinematics.

Sensor data from the physical setup (encoders, force/torque if available) is fed back into the simulation loop. This closes the loop between the virtual vehicle dynamics and real mechanical hardware, exposing issues that pure simulation would miss.

FANUC Integration

FANUC is a global leader in Industrial Robotics manipulators, and we have two FANUC arms at Polytech : a small one for education purpose, and a large one that had no real usage yet. I planned to participate to FANUC's National Olympiads, so I needed experience with their systems anyway. I am working with a R-30iA Mate controller, with an M-10iA/12S arm (V7.70 software). However, I need to make it work so I can stream real-time positions of the Super Heavy booster from ProxSim, following the exact same trajectory, without any delay nor jerk, and this is not what industrial robots are for : they are made for pre-programmed trajectories and logic.

I found a great library : fanucpy. It gives drivers (KAREL programs) to add to the robot, directions to setup a HTTP server on the controller, and a small python program to run on a local computer. While it was a very good starting point, multiple features were missing : no continuous options as all movements were executed individually (and not chained like in a regular FANUC program), commands could start multiple seconds after they were sent, no management of user frames... So I reworked the whole library, from the low-level KAREL for the FANUC to the low-level C++ for the ProxSim library, to add a new Spline functionality. The Spline functionality is currently working on select test cases, but is yet to prove reliability once integrated into ProxSim, more testing is needed.

Here, I'm sending random positions, at random intervals to the robot, and see how it handles. Comparison between the first and the second (latest) version.

Technical details

How to have a continuous motion

The delay of multiple seconds is caused by the FANUC's own motion system. The brakes have to be released fist, and then it can move. The brakes automatically activates a few seconds after the last motion concluded. The way fanucpy works by default is with a stack approach : each instructions (position, movement type, speed) have to be processed by the KAREL server and executed from a called TP program for the next to happen. I tried to use SKIP commands, but SKIPs are always stopping the robot before proceeding. My solution : have a TP program running continuously, waiting for instructions sent from the KAREL program. To manage interrupts (when the server receives a new command while the last one is not completed, I use two memory spaces, so KAREL can work on one while the TP program is looping on the other. Once KAREL finished to process it, I make the TP program switch memory space.)

About curves

This is where I ramble about interpolation and splines, and why velocities are important compared to simple geometry, and how I made the FANUC understand what I wanted. If I asked the FANUC to reach each points every milliseconds, the server wouldn't handle it, I needed better quality on lower resolution, and it comes to interpolation : filling thr blanks. The movement of the Super Heavy is smooth (as it is a system with a large inertia), so I thought about curves. Current curves interpolation systems use Bézier cures : it is practical for geometry.

As you can see in the videos above, the results of V1 are not very smooth, at some places, the arm accelerated and decelerated suddenly. This is because Bézier curves were not meant for movement, it only is for geometry. A better alternative : Hermite curves. Instead of joining multiple points, it takes the start and end position, as well as the velocities at both points. To ensure the robot catches up with the continuous flow of commands, the position of the beginning of the movement and it speed can be the robot's. If it is late, the interpolation will push the robot faster to catch up. I then calculate in the robot, the interpolation intermediate positions/speeds, write it to PRs and sends the signal to switch memories

Finally, here is the KAREL code

KAREL

FUNCTION dothis(arg: integer):
CONST
  var1: string
BEGIN
  haha
END

TP programs are interpreted, that means I can edit PRs at run time, yes. However, FANUC's motion systems reads ahead in the program, to plan the trajectory. The "ahead" number of position depends on the movement options, an "ACC" option makes the "ahead" count increase by one, so does "CNT" when non-zero. So I keep track of the current movement index in the memory, and start the next motion as if ahead by ~2 positions. This is the secret sauce to make the trajectory butter smooth and not have small hiccups/slowdowns.

Physical mockups

The goal of this project is to reverse engineer a complex system, but also to prove to people the tech exists for revolutionary transports, I need to interest people into my project, for visitors of sciences fairs, school visits... This means I have to make a mockup both practical, easy to 3D print (this is my only available manufacturing solution), and make it appealing.

As my project evolved, so did the Super Heavy booster's real design. Accounting to usual iterations, I made 4 different versions.

It stands ~70cm high, made in three sections (actuators, logic/comms, and battery). The three parts assemble using a twist-and-lock contraption after the screws were too ugly and unreliable with heavy parts swinging around for hours.

Visual Documentation

Early visuals from the simulation environment, cell programming, and hardware setup. These assets will be replaced or expanded with higher-quality captures, diagrams, and annotated footage in later iterations.

Real-World Challenges

Integrating the simulation timestep with the physical robot’s control loop introduced timing and determinism problems. Small delays in the communication bridge could destabilize the closed-loop behavior.

Mechanical compliance in the mock-up mount, robot joint flexibility, and sensor noise all affect the fidelity of the HIL test. Safety systems and emergency stops had to be designed so that a software fault would not damage the arm or cell.

A simplified excerpt from the real-time communication bridge shows the kind of timing-sensitive C++ that had to be carefully bounded for determinism:

// Real-time bridge loop (simplified, temporary example)
void control_loop() {
    while (running) {
        auto desired = simulate_descent();

        auto start = std::chrono::steady_clock::now();

        if (!send_to_fanuc(desired)) {
            trigger_emergency_stop();
            return;
        }

        Feedback fb = receive_feedback();   // source of jitter
        apply_correction(fb);

        auto elapsed = std::chrono::steady_clock::now() - start;
        if (elapsed > std::chrono::milliseconds(12)) {
            log_determinism_violation(elapsed);
        }

        std::this_thread::sleep_until(start + std::chrono::milliseconds(10));
    }
}

Control Approach

The booster uses a combination of attitude control via grid fins / thrust vectoring and precise vertical positioning during the final meters. Early tests focus on attitude hold and descent rate tracking.

The dynamics of the booster near the catch point can be locally approximated by a linear state-space model. A simplified continuous-time representation is:

Here $\mathbf{x}$ is the state vector (attitude, rates, position, velocity),$\mathbf{u}$ contains the control inputs (thrust vectoring, grid fin deflections), and the matrices A and B are identified or derived from the simulation model. Full derivation and discretization for the flight software will be added in a future pass.

Current Status & Next Steps

The basic HIL loop is running and the arm can replay representative trajectories. Current work focuses on improving synchronization, adding better instrumentation, and validating that the flight software branch produces stable catch behavior.

Next milestones include logging full state traces, running Monte-Carlo style variations on the physical hardware, and gradually increasing the fidelity of the mock-up and sensor models.