Source-linked AI summary
mjorbit: A Simulation Framework for Space Robotics
John Z. Zhang, Joris Verhagen, Fausto Vega, Patrick McKeen, Zachary Manchester
TL;DR
Space-robot simulation must combine orbital motion with articulated multibody contact, which existing simulators tend to address separately. mjorbit couples orbital dynamics to MuJoCo-based robotics simulation and supplies CPU and GPU backends. Its orbital-physics comparison shows better long-horizon capture performance than zero-g MuJoCo.
Problem
Existing astrodynamics and robotics simulators typically lack, respectively, multibody contact dynamics or orbital mechanics and environmental effects.
Source: §I · p. 1Method
mjorbit couples orbital dynamics to MuJoCo-based robotics simulation, with a low-latency CPU implementation and a high-throughput GPU implementation.
Source: §I · p. 1Results
2.2 ± 1.2° final-window error with orbital physics versus 30.2 ± 15.3° with zero-g MuJoCo, which failed on 4 of 5 runs.
Source: C. Capture and Nadir Pointing · p. 7Takeaways & Limitations
Capturing orbital physics that naive simulators ignore directly improves long-horizon task performance in the demonstrated capture and nadir-pointing task.
Source: C. Capture and Nadir Pointing · p. 7Each world has one reference orbit, so the conditioning assumes proximity-operations scale; GPU single-precision clocks also lose timing accuracy for time-keyed models over multi-hour rollouts.
Source: §VII · p. 7
Abstract
from arXiv · showhide
This paper presents a general framework for simulating multi-body space robots with contact. We bring efficient, large-scale robot simulation to in-space servicing, assembly, and manufacturing applications. First, we perform an empirical trade study of methods for coupling orbit propagation with existing robotics simulation frameworks. Next, we present mjorbit, a general, flexible, and performant framework built on the MuJoCo engine widely used in robotics, to which we add key spacecraft dynamics, actuators, and sensors. We provide a low-latency C++ CPU backend and a high-throughput GPU backend behind a simple Python API. We demonstrate mjorbit by solving several realistic on-orbit case studies with both model-predictive control and reinforcement learning. Open-source code and examples are available at: https://johnzhang3.github.io/mjorbit/
I. INTRODUCTION
Space-robot tasks couple orbital motion, articulated dynamics, actuation, sensing, and contact, while existing astrodynamics and robotics simulators cover complementary subsets. mjorbit couples orbital dynamics with robotics simulation and provides backends and examples for control and policy training.
A. Astrodynamics and Spacecraft Simulation
- Astrodynamics tools support orbit, attitude, environmental, and flight-software simulation but typically lack multibody contact, while robotics simulators provide articulated contact dynamics without orbital mechanics.Source: §I · p. 1
I. INTRODUCTION
- mjorbit couples orbital dynamics to robotics simulation in a framework designed for accurate long-horizon physics and policy learning and control.It builds on MuJoCo and its GPU-optimized variant, MJWarp.Source: §I · p. 1
- The framework adds orbital perturbations and spacecraft actuators and sensors to support space-robot simulation.Supported perturbations include J2, atmospheric drag, solar radiation pressure, and magnetic torques; devices include thrusters, reaction wheels, control-moment gyros, magnetic torque coils, magnetometers, and sun sensors.Source: §I · p. 1
- Its C++ CPU backend targets low-latency simulation, while its GPU backend targets high-throughput data generation, with examples for real-time control and policy training.Source: §I · p. 1
A. Astrodynamics and Spacecraft Simulation
- Existing coupled systems show that orbital and multibody simulation can be combined, but are closed-source, mission-specific, and not high-throughput robotics engines.Source: A. Astrodynamics and Spacecraft… · p. 2
- Microgravity-configured robotics simulators support contact-rich space tasks but omit environmental forces and torques that accumulate over orbital timescales.Source: A. Astrodynamics and Spacecraft… · p. 2
B. Robotics Simulation for Learning and Control
Robotics simulators provide mature, high-performance tools for articulated dynamics, contact, control, and learning, including GPU-parallel simulation. Simulators coupling these engines to orbital dynamics and environmental perturbations remain underexplored.
B. Robotics Simulation for Learning and Control
- Robotics simulators offer mature, high-performance implementations of articulated rigid-body dynamics and contact that support reinforcement learning, controller synthesis, and verification.Source: B. Robotics Simulation for Learning… · p. 2
- Fast CPU and massively parallel GPU simulators have accelerated real-time control and sim-to-real reinforcement learning, including for low-gravity robotics.Source: B. Robotics Simulation for Learning… · p. 2
- Coupling orbit dynamics and external environmental perturbations with robotics engines remains underexplored; Fig. 2 contrasts bounded orbit-coupled motion with unbounded zero-g drift over one reference orbit.Source: B. Robotics Simulation for Learning… · p. 2, Figure 2 · p. 2
A. Orbital Dynamics and Reference Frames
The section defines the orbital reference frames and gravity terms used to describe spacecraft motion, then states the articulated-body dynamics used for contact simulation.
A. Orbital Dynamics and Reference Frames
- ECI is inertial, OF translates with the reference orbit while retaining ECI-parallel axes, and LVLH additionally rotates with the orbit.In LVLH, the radial axis follows the reference position, the cross-track axis follows the position–velocity cross product, and the in-track axis completes the triad.Source: A. Orbital Dynamics and Reference Frames · p. 2
- Practical orbit models can augment point-mass gravity with perturbations such as J2, while nearby bodies in OF also experience non-gravitational acceleration.The section denotes point-mass acceleration by g0, the central body’s gravitational parameter by μ, and specific non-gravitational forces by aext.Source: A. Orbital Dynamics and Reference Frames · pp. 2–3
B. Multibody Dynamics with Contact
- An articulated rigid-body system uses configuration q on a manifold and generalized velocity v as a tangent vector related to q-dot by a configuration-dependent map.The configuration dimension nq can exceed the velocity dimension nv when q includes attitude, typically represented by a unit quaternion.Source: B. Multibody Dynamics with Contact · p. 3
- The manipulator equation balances mass-matrix and Coriolis terms against direct actuation and Jacobian-mapped body, contact, and joint-constraint forces.The stacked wrench f is mapped into generalized force by J(q)⊤.Source: B. Multibody Dynamics with Contact · p. 3
IV. METHODOLOGY
The methodology shows why orbit-coupled simulation matters over long external-operation horizons and examines numerical conditioning across gravity formulations and frame choices. Encke’s formulation avoids direct subtraction of large gravity vectors, while the frame comparison shows differing precision behavior.
A. Orbit-Coupled Simulation
- After about 0.2 hours, zero-g and orbit-coupled collision trajectories diverge: the zero-g boxes drift apart, while the orbit-coupled boxes oscillate around each other every half orbit.The trajectories are indistinguishable during and immediately after impact.Source: A. Orbit-Coupled Simulation · p. 3
B. Improving Conditioning with Encke’s Method
- Jointly simulating thousand-kilometer orbits and meter-scale contact dynamics is ill-conditioned, especially with single-precision GPU computation.The paper addresses this with cancellation-resistant differential gravity and a choice of multibody reference frame.Source: B. Improving Conditioning with Encke’s… · p. 3
- In Fig. 3, RK4 is submillimeter-accurate in all frames in double precision, but only local frames stay accurate over orbital time scales in single precision.The implicit integrator achieves submillimeter accuracy only in the orbit-following frame.Source: Figure 3 · p. 3
- At 400 km LEO, naive differencing loses about 6.8 of roughly 7.2 single-precision significant digits; Encke’s exact form avoids literal subtraction of the large gravity vectors.The differential gravity is about 10^-6 m s^-2, buried in rounding noise after naive differencing.Source: B. Improving Conditioning with Encke’s… · pp. 3–4
C. Frame Choices for Multibody Simulation
The frame choices differ in how they represent position and which accelerations must be supplied to the simulator. Although mathematically equivalent, their numerical properties differ in finite precision.
C. Frame Choices for Multibody Simulation
- ECI carries absolute position, OF carries a translated position in ECI axes, and LVLH carries a position in the rotating reference-orbit frame.The compared placements are a global inertial frame, a translating frame, and a rotating frame.Source: C. Frame Choices for Multibody… · p. 4
- ECI needs no frame correction, OF needs translational compensation, and LVLH additionally requires Coriolis, centrifugal, and Euler-frame terms.The simulator treats its world frame as inertial, so non-inertial accelerations are supplied externally per body.Source: C. Frame Choices for Multibody… · p. 4
- OF and LVLH evaluate differential point-mass gravity through Encke’s form, whereas ECI integrates full point-mass acceleration at the absolute position.The ECI expression integrates r = rc + ρI under point-mass gravity plus external acceleration; all three formulations are mathematically equivalent but differ numerically in finite precision.Source: C. Frame Choices for Multibody… · p. 4
D. Integrator Structure and Symplecticity
The orbit-following (OF) frame combines local coordinates and position-only acceleration, preserving the structure needed for symplectic low-order integration. Across the tested frames, it gives the most robust accuracy, especially for single-precision simulation and first-order integration.
D. Integrator Structure and Symplecticity
- The OF frame’s position-only conservative acceleration preserves a separable translational Hamiltonian, making semi-implicit Euler symplectic with typically bounded, oscillatory error.LVLH’s Coriolis term breaks the simple separable structure; ECI requires the multibody engine to carry absolute orbital-scale positions.Source: D. Integrator Structure and… · p. 4, Figure 4 · p. 4
E. Empirical Frame Comparison
- Frame comparisons use a free-floating LEO rigid body without added environmental forces or torques, integrating at 0.1 s against a Basilisk reference.The 0.1 s step matches the paper’s 10 Hz control and throughput-relevant regime; contact-rich examples instead use finer MuJoCo steps such as 10^-2 s.Source: E. Empirical Frame Comparison · pp. 4–5
- In single precision, the OF frame reaches millimeter-level accuracy with a first-order integrator, while ECI has large errors even with RK4.In double precision, RK4 remains accurate through 3 orbits across frames, but the implicit integrator is stable and sub-millimeter accurate only in OF.Source: E. Empirical Frame Comparison · p. 5
- The OF frame is strictly preferable in the study: it needs no rotational compensation, preserves low-order symplecticity, and matches other frames’ accuracy under higher-order integration.The paper therefore defaults to OF and the implicit integrator; in OF, its position-only translational update coincides with symplectic Euler.Source: E. Empirical Frame Comparison · p. 5
V. MJORBIT
mjorbit extends MuJoCo with orbit state, spacecraft components, and environmental effects while retaining its articulated-body and contact capabilities. It couples a central-body orbit propagator to MuJoCo dynamics using an orbit-following frame and a moving origin that tracks modeled-system non-gravitational acceleration.
A. Design and Scope
- mjorbit adds orbit state variables, spacecraft actuators and sensors, and passive environmental forces and torques while retaining MuJoCo’s articulated-body dynamics, constraint solver, MJCF models, and control interfaces.The approach is described as applicable to any simulator exposing articulated-body states and generalized force inputs.Source: A. Design and Scope · p. 5
B. Reference Orbit and State Representation
- mjorbit couples a central-body orbit propagator to MuJoCo’s articulated rigid-body dynamics, storing the reference orbit in a planet-centered inertial frame and MuJoCo bodies in an orbit-following frame.Translational quantities are converted between SI and kilometer-based orbit units at the MuJoCo–orbit boundary.Source: B. Reference Orbit and State… · p. 5
- The reference orbit’s feedback acceleration is the mass-weighted average of modeled bodies’ non-gravitational accelerations, so the origin tracks the system’s center-of-mass motion.A matching fictitious force cancels this origin motion in the absolute state; internal contact impulses are excluded.Source: B. Reference Orbit and State… · p. 5
C. Body Wrenches and Multibody Coupling
mjorbit represents body-level environmental and actuator effects as external wrenches assembled in the orbit-following world frame and passed to MuJoCo. The same wrench formulation covers free, articulated, and contact-coupled systems, with contact impulses handled internally by MuJoCo.
C. Body Wrenches and Multibody Coupling
- Each body’s translational load combines differential gravity, compensation for origin acceleration, and body-level environmental and actuator forces.Differential gravity uses the Encke form, with the J2 difference added when enabled; inertially aligned world axes avoid Coriolis, centrifugal, and Euler-frame terms.Source: C. Body Wrenches and Multibody Coupling · p. 5
- Drag and solar radiation pressure use per-surface geometry and force the resulting center-of-pressure moment into the body torque.Sun direction and magnetic field are cached at the reference state, while atmospheric density and eclipse are evaluated at each surface’s position.Source: C. Body Wrenches and Multibody Coupling · p. 6
- Rotational wrenches collect gravity-gradient, magnetic, reaction-wheel and CMG, and thruster torques, then map body loads into generalized forces through body Jacobians.This formulation applies to free bodies, articulated spacecraft, and contact-coupled systems; contact impulses remain internal to MuJoCo and are excluded from reference feedback acceleration.Source: C. Body Wrenches and Multibody Coupling · p. 6
D. Simulation Procedure
mjorbit advances orbit and constrained multibody dynamics through a shared simulation pipeline, exposed through a model/data API. Its CPU and GPU backends preserve the same coupling convention while targeting low-latency control and parallel rollouts, respectively.
D. Simulation Procedure
- Each simulation step assembles passive body loads, solves and integrates constrained multibody dynamics, advances actuator and reference-orbit states, then refreshes environment caches.The CPU implements the pipeline as a MuJoCo engine plugin, while the GPU realizes the same stages as fused MJWarp kernels.Source: D. Simulation Procedure · p. 6
E. API Design and Backends, and Throughput
- A mutable specification compiles once into a shared immutable model, while each rollout owns data containing its evolving multibody, orbit, actuator, sensor, and coupling states.The CPU backend targets low-latency closed-loop control across host threads; mjorbit-warp targets many parallel worlds for learning, evaluation, and dataset generation, with minimal backend-switching changes.Source: E. API Design and Backends, and… · p. 6
- Both mjorbit backends deliver orders of magnitude higher throughput than Basilisk on the bimanual free-flying manipulator benchmark.Figure 5 also compares maximum relative body-position error under RK4 and implicitfast for the fp64 CPU and fp32 GPU backends.Source: Figure 5 · p. 6
F. Trade-offs between Simulation Accuracy and Throughput
mjorbit’s CPU and GPU backends trade simulation accuracy against throughput, and four on-orbit examples exercise them in control and policy learning. The examples include arm-driven bus reorientation, autonomous docking, and gravity-gradient-assisted nadir pointing.
F. Trade-offs between Simulation Accuracy and Throughput
- CPU mjorbit reproduces the Basilisk reference trajectory to ∼10−7 m relative body-position error, while single-precision mjorbit-warp floors near ∼10−3 m; implicitfast drifts to ∼1 m regardless of precision.At eight threads, CPU throughput is ∼0.55 million steps/s with RK4 and ∼1.6 million with implicitfast; mjorbit-warp reaches ∼1.7 to ∼6.5 million steps/s on an RTX 3080, versus Basilisk’s ∼103 steps/s.Source: F. Trade-offs between Simulation… · p. 6
VI. EXAMPLES
- Four scenarios in ∼400 km LEO use CPU model-predictive control for three examples and GPU simulation across thousands of parallel worlds for reinforcement learning.The three model-predictive examples use mjorbit’s splineknot MPPI planner in closed loop on the CPU.Source: §VI · p. 7
A. Multibody Attitude Control
- An arm-only MPPI planner slews the unactuated bus through 60° about the (1, 1, 1) axis in roughly 30–40 s, then manages momentum against residual environmental torques.The planner uses 128 rollouts over a 14 s horizon, replanned at ∼3 Hz; a joint-rate penalty and clearance barrier shape motion.Source: A. Multibody Attitude Control · p. 7
B. Autonomous Docking
- A 7,000 kg chaser docks with a passive 420,000 kg target, latching at separation below 0.2 m and attitude error below 5° within a 120 s episode.Large commanded slews need horizons long enough to brake with the wheels’ ∼0.005 rad/s² authority; shorter horizons leave attitude limit-cycling.Source: B. Autonomous Docking · p. 7
C. Capture and Nadir Pointing
- Across five seeds, orbit-coupled MPPI holds the captured stack at nadir with final-window error 2.2 ± 1.2°, while zero-g MuJoCo fails on 4 of 5 runs (30.2 ± 15.3°).The planner reorients the captured stack to nadir and holds it only by exploiting passive gravity-gradient torque through arm motion.Source: C. Capture and Nadir Pointing · p. 7
D. Astrobee Grasping
The Astrobee example uses GPU-parallel simulation to train a policy for grasping and holding a drifting cargo module. The paper also identifies framework and validation limits, including proximity-scale conditioning, incomplete perception sensing, and the need for hardware and on-orbit testing.
D. Astrobee Grasping
- The GPU-trained Astrobee policy achieves an 88% grasp-and-hold success rate across 1,024 worlds after 60 s of training.Episodes last 600 steps at 10 Hz; the task includes detumbling, flying to a drifting cargo module, grasping its handle, and station-keeping while holding it.Source: D. Astrobee Grasping · p. 7
VII. CONCLUSIONS AND LIMITATIONS
- mjorbit provides accurate long-horizon simulation under single-precision GPU arithmetic, with low-latency CPU and high-throughput GPU backends demonstrated on space-robot control tasks.The paper presents the framework as a way to leverage robotics simulation engines for space robotics.Source: §VII · p. 7
- Each world has one reference orbit, so the conditioning assumption ∥ρI∥≪∥rc∥ applies at proximity-operations scales; GPU single-precision clocks also lose timing accuracy in multi-hour time-keyed environment models.The orbital layer adds per-body wrench assembly linear in body count, while articulated and contact-dynamics scaling is inherited from MuJoCo.Source: §VII · p. 7
- The framework lacks first-class camera and lidar sensors, considers only first-order integrators, and has sim-to-sim rather than hardware or on-orbit policy validation.The authors identify richer perception sensors and variational integration schemes as future work, and say policies should be validated in hardware tests and on orbit.Source: §VII · pp. 7–8