Groundwork for Orbit: Conception to Ground Qualification of Orbital Robotic Missions
A Model-Based Design Workflow Helps DLR Test Orbital Robots Before They Leave Earth
When a robot breaks down on Earth, an engineer can drive to the facility and repair it. When one breaks down in geostationary orbit, roughly 36,000 kilometers (22,000 miles) above the planet’s surface, there is no such option.
That challenge is accelerating work on orbital servicing. Companies and research institutions around the world are racing to develop robots that can reach satellites in orbit, inspect them, refuel them, and extend their operational lives by years. The same technology could help assemble future space stations and service deep-space telescopes beyond the reach of crews.
The German Aerospace Center—known by its German initials, DLR—has been working on exactly this kind of orbital robotics since 1993, when its ROTEX experiment became the first remotely torque-controlled robot in space. Today, DLR’s Institute of Robotics and Mechatronics is developing control software for two upcoming orbital-servicing missions: GEA-RISE, funded by the European Space Agency (ESA) and scheduled for launch in 2029, and EROSS-SC, funded by the European Commission and scheduled for launch in 2030. For EROSS-SC, DLR is also developing the hardware for CAESAR (Compliant Assistance and Exploration Space Robot), a robotic arm designed specifically for orbital operations from low Earth orbit to geostationary orbit.
Graphical simulation of the six-axis robot (left) and ground control (right) from the ROTEX experiment in 1993. (Image credit: DLR)
While this requires DLR to move quickly, development speed cannot come at the cost of certainty in space. Engineers may be able to update software remotely, but they cannot simply recall the hardware or make another service visit.
“When we go from prototype to product development, there have to be very deterministic steps to follow,” said Hrishik Mishra, a research scientist who has coordinated DLR’s motion control design and cosimulation framework for orbital robotics since 2017. DLR’s answer is a Model-Based Design workflow, built using MATLAB® and Simulink®, that runs from the earliest analysis to flight-ready embedded code.
From Equation to Orbit
The pipeline has four phases, each one adding fidelity and hardware until the system is ready to fly.
In the first phase, model-in-the-loop (i.e., desktop simulation), engineers build a standalone Simulink model containing both the controller and a mathematical representation of the robotic arm and spacecraft. This happens before the hardware exists, allowing teams to ask questions that shape the mission: How much torque will the arm need? How far will the spacecraft drift when the arm moves? Is the proposed operation feasible at all?
“Even before the robot is manufactured and the details of the missions are known, we are able to get to a stage where we can analyze the feasibility of the operational requirements in a mission.”
“Even before the robot is manufactured and the details of the missions are known, we are able to get to a stage where we can analyze the feasibility of the operational requirements in a mission,” said Mishra.
As the project matures, the team adds more precise models of the spacecraft, robotic arm, sensors, and actuators. The controller remains in Simulink but connects to a third-party robotics toolbox that can simulate what cameras will see, what a lidar sensor will detect, and how the hardware will behave. The model runs at the same computational intervals expected in the eventual flight software, letting engineers refine the design under increasingly realistic conditions.
The mission lifecycle uses model-based systems engineering (MBSE) from model-in-the-loop to hardware-in-the-loop. (Image credit: DLR)
The software-in-the-loop phase integrates the Simulink controller into a broader C++ framework that adds motion generators, trajectory planners, and state machines. Simulink Coder™ generates the controller code. During processor-in-the-loop testing, that software runs on a real-time computer with a real-time operating system.
Finally, DLR moves to hardware-in-the-loop testing in its On-Orbit Servicing Simulator (OOS-SIM). Industrial robotic arms stand in for the servicing spacecraft and target satellite, while Simulink models reproduce the dynamics of operating in zero gravity. Because the controller code is generated from the model, engineers do not have to manually rewrite it in C++ whenever they tune an algorithm or add a feature.
The processor-in-the-loop phase: MATLAB and Simulink are used to generate code that is used by the DLR CI/CD pipeline to create the control software executable, which runs on the target control hardware. (Image credit: DLR)
“When control engineers need to tune the system or add functionality, we can immediately deploy the changes to the target hardware without rewriting the code,” said Martin Stelzer, DLR’s software engineering manager on one of the upcoming missions. “That is what makes us much faster.”
The physical testing facility is essential but limited, and DLR has two such facilities: OOS-SIM and the CAESAR facility. Physical tests require more setup than software simulations, and access must be shared across multiple projects. The simulation-heavy early phases let engineers catch ordinary software bugs on their computers rather than while occupying the test bed.
The workflow also makes it easier to respond when a mission’s design changes. “When the prime contractor changes a parameter, it does not take us half a year to reconstruct the simulation and provide an answer,” Stelzer said. “We can integrate the new properties relatively quickly.”
DLR’s OOS-SIM is a hardware-in-the-loop facility that validates planning/perception/control algorithms by replicating microgravity contact-driven dynamics. (Image credit: DLR)
That flexibility has become increasingly important as DLR works on two major orbital-servicing missions at once. The C++ framework is modular, allowing engineers to swap in different motion generators and control modes. The simulator can also be adapted to a different robot by changing the file describing its physical properties.
“From the model-in-the-loop to the software-in-the-loop phase,” Stelzer said, “the framework holds for many different setups. We just need to feed in the properties of the specific system.”
From the Ground Up
In space, moving the arm moves everything. With no gravity anchoring the spacecraft, any motion the robotic arm makes shifts the entire system—displacing the spacecraft, changing its orientation, and complicating the approach to a target that may itself be tumbling.
“The ease of integration allows us to build extensions that can then be used in future projects. Each project becomes a foundation for the missions that follow.”
DLR has been studying this problem since the ROTEX mission and has developed several approaches to managing it. In some scenarios, DLR controls the spacecraft and arm as a coordinated system. In others, the spacecraft remains passive while the arm compensates for the disturbance and completes the capture.
After capture, a new challenge appears. The combined mass of the servicer spacecraft, the robotic arm, and the captured satellite has different dynamics from any of those objects alone. The system must damp out any residual relative velocity between them before the docking sequence can begin.
“The moment we close the gripper,” Mishra said, “we switch the control mode to not move the arm anymore, but just to damp out the velocities, so that the combined stack comes to a relative standstill.”
Engineers design and test control modes, switching logic, and damping algorithms in Simulink. Physical testing on the ground presents a different challenge. Because the system was designed for a zero-gravity environment, it cannot support its own weight under Earth’s gravity. As a result, engineers must develop workarounds to simulate flight conditions during testing.
The CAESAR robotic arm grabs a satellite in motion. (Image credit: DLR)
DLR and the University of Duisburg-Essen built a cable robot to solve the problem. They anchored four cables to the ceiling of the lab that attach to the arm and counteract gravity just enough to let the robot move through its full range of motion. The same concept shows up in television production as camera rigs that glide over sports stadiums.
“It cancels out most of the gravity,” said Ferdinand Elhardt, a research scientist at the institute who is responsible for the gravity offloading testing facility that is used to qualify CAESAR. “That means we can perform tests in the full 3D space of the robotic arm on the ground."
DLR builds the cable robot’s controller in MATLAB and Simulink. The controller connects to Beckhoff® real-time motion hardware through a toolbox that allows Simulink models to run within the TwinCAT® software environment. A live dashboard shows engineers what the controller is doing in real time.
For government-sponsored missions in Europe, there is another layer of complexity on top of the engineering. European Cooperation for Space Standardization, or ECSS, requirements demand full traceability from a high-level mission requirement to a specific block in a Simulink model, the generated code, and the test that verified it. Stelzer described ECSS not as a box to check at the end of a project but as something that must be woven in from the beginning.
“If you don’t account for these requirements from the beginning, it increases the effort needed to comply at the end,” he said. “You may discover that requirements are missing, and the later they are introduced, the more costly they become to implement.”
Mishra said reliability is essential for space missions, and this is achieved by applying the framework to the development of DLR’s two upcoming orbital-servicing missions, GEA-RISE and EROSS-SC. DLR’s approach in orbital robotics and its prior experience in prototyping, development, and integration work ensures reliability and determinism in project deliveries.
“The ease of integration allows us to build extensions that can then be used in future projects,” Mishra said. “Each project becomes a foundation for the missions that follow.”
Read Other Stories
The Orion Spacecraft Is Headed to the Moon, with Help from the SLS Rocket
NASA’s Artemis Program Targets a Long-Term Lunar Presence
JTEKT’s Software Factory Cuts Development Time from Days to Minutes
Bringing Continuous Integration into Safety-Critical Vehicle Systems
Modernizing Robotic Laser Peening with Simulation
Industrial Automation Replaces Manual Operations
