Bridging the Basilisk Astrodynamics Framework with ROS 2 for Modular Spacecraft Simulation and Hardware Integration

AI summary

Overview

Research area: Space robotics and astrodynamics simulation tooling — specifically, interoperability between a high-fidelity orbital dynamics simulator (Basilisk) and the Robot Operating System 2 (ROS 2) middleware.

Technical level: Intermediate. The paper is readable by anyone familiar with robotics middleware, but the formation control section assumes prior exposure to orbital mechanics (Hill frame, Clohessy-Wiltshire equations) and nonlinear model predictive control (NMPC).

Scope in one sentence: The paper presents an open-source, non-invasive ZeroMQ-based communication bridge that connects Basilisk simulations to ROS 2 nodes, and validates it by running the identical NMPC formation-flying controller in both Basilisk and on the KTH ATMOS planar microgravity testbed.

What This Paper Is About

Spacecraft autonomy development needs both high-fidelity orbital dynamics (which general robotics simulators like Gazebo and Isaac Sim lack) and modular, reusable control software (which Basilisk does not natively provide in the ROS 2 ecosystem). The paper's goal is to remove the friction between these two worlds by building a lightweight bridge that lets autonomy stacks run as ordinary ROS 2 nodes while Basilisk handles the physics, without editing Basilisk's core. The authors then check that a single, unmodified control implementation behaves comparably in simulation and on real hardware.

Key Contributions

1. A lightweight, scalable communication interface connecting ROS 2 nodes to Basilisk simulations without modifying Basilisk's internal architecture.
2. A demonstration in a leader-follower spacecraft formation flying scenario using Nonlinear Model Predictive Control, fully implemented as ROS 2 nodes.
3. Comparative validation in both simulation and hardware using the KTH ATMOS free-flyers, showing consistent control performance across platforms.

The authors also release three open-source repositories: BSK-ROS2-Bridge, bsk-msgs (ROS 2 message definitions generated from Basilisk's native message types), and bsk-ros2-mpc (the demo MPC).

Main Findings

• Bridge architecture: The bridge consists of a ROS 2 node plus a Basilisk-side Python handler module. They exchange JSON-formatted byte messages over ZeroMQ on three ports — receive, transmit, and heartbeat (used for monitoring connection health). Basilisk's simulation time is published to ROS 2 on the /clock topic, keeping all ROS 2 nodes synchronized in both real-time and accelerated simulation modes.
• Topic convention: Message routing is registered programmatically in the Basilisk script, using topics of the form /[ns]/bsk/[direction]/[topic], where [direction] is in (ROS 2 to Basilisk) or out (Basilisk to ROS 2). A single bridge-handler pair can manage any number of spacecraft with namespace-aware topics.
• Formation tracking accuracy: Followers maintained formation within 0.17 m in simulation and 0.35 m on hardware. On the ATMOS platforms a steady-state offset appeared across all agents, attributed to unmodeled disturbances such as floor unevenness and actuation asymmetries.
• Controller transferability: Without changes to the controller implementation or architecture, the same ROS 2-based control nodes operated in both high-fidelity simulation and hardware. The transition to ATMOS required only substituting Basilisk topics with those used by PX4, a remapping the authors note can be automated.
• Communication performance (AMD Ryzen 5 5600X, Ubuntu 24.04): At nominal load the bridge sustained 100 Hz per agent with low jitter (standard deviation 1.3 ms for one spacecraft, 6.5 ms for 100 spacecraft). Single-agent high-load tests reached about 4,390 Hz at 1x speed and 4,270 Hz at 100x speed when targeting 10,000 Hz. With 100 spacecraft and a 1,000 Hz target under 100x speed, it saturated near 270 Hz per agent with 2.4 ms standard deviation. The similarity of limits under 100x accelerated simulation indicates CPU-bound throughput rather than timing constraints.

Methodology in Plain English

The authors built a translator, not a modification. On the Basilisk side, a handler module follows the standard Python module structure and is imported into a simulation script like any other module; it uses Basilisk's existing ZeroMQ support (the same messaging protocol the Vizard visualization tool relies on). On the other side, a ROS 2 node joins the ROS 2 network like any other node and needs no manual topic configuration. Data flows both ways as JSON messages, and simulation time is broadcast on /clock so every node stays in step with the simulation.

To test the bridge, the team set up a formation flying task with one leader and two followers. Each agent runs its own decentralized NMPC, solved in real time with the ACADOS solver over a prediction horizon of N = 30 steps with a timestep of 0.2 s. Controllers ran at 5 Hz, each producing a 13-dimensional state (relative position, velocity, unit quaternion, angular velocity) and a 6-dimensional control input (body-frame force and torque). The cost penalizes position, velocity, attitude and angular-velocity error, plus control effort, with terminal weighting P = 20 Q. Each agent shares its predicted trajectory each control step so others can enforce pairwise collision-avoidance separation constraints — predictive conflict resolution without centralized planning.

The leader follows a cyclic waypoint sequence, transitioning every 20 s; followers hold fixed offsets of −1.0 m in the Hill-frame x-axis and ±0.3 m in the Hill-frame y-axis relative to the leader, while aligning attitude with it. In simulation, three spacecraft are placed in a near-circular Low-Earth orbit with semi-major axis a = 6778.0 km, eccentricity e = 0.001, inclination i = 45°, right ascension of the ascending node Ω = 270°, and argument of periapsis ω = 90°.

The hardware and simulation share parameters: each spacecraft has a mass of 17.8 kg and moment of inertia J_zz = 0.315 kg m², with the simulation assuming J_xx = J_yy = J_zz for simplicity. Each ATMOS free-flyer has eight solenoid thrusters using compressed air for holonomic 3-degree-of-freedom motion (planar x, y, and yaw θ_z), while the simulation expands this to twelve symmetrically arranged thrusters for full 6-degree-of-freedom actuation in 3D. Because the hardware is thruster-only, reaction wheels are excluded in both. Maximum thrust is 3.0 N in the body x and y axes, and maximum torque about body yaw is 0.51 N m. Thrusters are actuated by pulse width modulation at 10 Hz, each producing approximately 1.5 N when active; the simulation enforces a minimum on-time of 1 ms to mimic hardware limits.

Why This Matters

Research impact: The bridge decouples control logic from the simulation engine, letting researchers iterate on autonomy algorithms in ROS 2 while retaining orbital dynamics fidelity that general-purpose robotics simulators do not offer. It also gives the space robotics community a route to reproducible workflows: the same code that runs in simulation can run on a testbed, which strengthens the link between published results and hardware verification.

Real-world applications:

• Formation flying and distributed spacecraft missions, which require precise relative control and coordination (demonstration missions cited include PRISMA and PROBA-3, with recent efforts targeting sub-meter accuracy).
• Ground-based hardware-in-the-loop testing of planning and control algorithms in microgravity-analog facilities.
• Free-flying robotic platforms aboard orbital stations, in the lineage of NASA's Astrobee free-flyers on the ISS.
• Future contact-dynamics work such as spacecraft docking, articulated manipulators, deployable structures, and flexible appendages, which the authors name as candidates for the bridge plus Basilisk's module library.

Industry relevance: ROS 2 has become the standard for modular, real-time robotics software, and Space ROS is a safety-focused fork developed by NASA and collaborators for mission-critical space robotics. A bridge that keeps Basilisk's core untouched and works with existing Basilisk message infrastructure lowers the barrier for teams already fluent in robotics middleware to adopt high-fidelity astrodynamics simulation, and helps avoid maintenance overhead tied to specific message definitions or ROS 2 versions — a problem the authors attribute to earlier tightly coupled integrations.

Future Directions

1. Software-in-the-loop and hardware-in-the-loop pipelines. The current setup was executed in open-loop configuration, with no SIL or HIL feedback between Basilisk and the hardware; the authors state the bridge architecture inherently supports closed-loop setups and call enabling them a promising avenue.
2. Scaling to larger constellations. The formation demo was intentionally constrained to a planar 2D setting with one leader and two followers. Bridge stress tests already probed 100 spacecraft, but larger, more realistic formations remain to be exercised end to end.
3. Contact dynamics and articulated systems. Leveraging Basilisk's broader module library — realistic sensors, actuator models, environmental disturbances, flight software architectures — for docking, manipulators, deployable structures, and flexible appendages.
4. Automating topic remapping. The authors note that the Basilisk-to-PX4 topic substitution performed manually for the ATMOS deployment could be easily automated.

Target Audience

Spacecraft autonomy and controls engineers who already work in ROS 2 and want high-fidelity orbital dynamics without rewriting their stacks inside a simulator; astrodynamics researchers who need to test flight-software-style control architectures; testbed operators running planar or microgravity-analog facilities; and robotics researchers generally interested in how to bridge domain-specific physics engines with general-purpose middleware. Readers looking for new NMPC theory or new orbital dynamics formulations will not find them here — the controller formulation is standard, and the contribution is the integration layer and its cross-platform validation.

Authors’ abstract

Integrating high-fidelity spacecraft simulators with modular robotics frameworks remains a challenge for autonomy development. This paper presents a lightweight, open-source communication bridge between the Basilisk astrodynamics simulator and the Robot Operating System 2 (ROS 2), enabling real-time, bidirectional data exchange for spacecraft control. The bridge requires no changes to Basilisk's core and integrates seamlessly with ROS 2 nodes. We demonstrate its use in a leader-follower formation flying scenario using nonlinear model predictive control, deployed identically in both simulation and on the ATMOS planar microgravity testbed. This setup supports rapid development, hardware-in-the-loop testing, and seamless transition from simulation to hardware. The bridge offers a flexible and scalable platform for modular spacecraft autonomy and reproducible research workflows.