Open Source   ROS 2   Space Infrastructure

Open-source software
for the next
space station

A modular ROS 2 platform that simulates and controls the critical systems of a space station. Life support, thermal regulation, and electrical power — all running as independent, hardware-ready nodes.

ROS 2
Middleware
3
Core subsystems
ISS
Architecture reference
NU Press
Featured Feb 2026
Press Northeastern University — Open-source software for next-generation space stations February 2026
System demo
SSOS subsystem integration demo   ROS 2   C++ and Python
What this is

A software-defined
space station

Space Station OS started as a question: what would it look like if you designed the software stack for a space station the way you design modern robotics infrastructure? Each subsystem as an independent ROS 2 node. Standardised interfaces. Hardware-ready from day one.

The architecture is modelled on the ISS. I worked on ECLSS, the thermal control system, and the electrical power system — not as toy simulations, but as systems that mirror the actual closed-loop logic the ISS uses. The goal was a platform another engineer could pick up, extend, and eventually run on real hardware.

The project was featured by Northeastern University in February 2026.

Subsystems

Three critical systems.
One unified platform.

ECLSS
Life Support
Closed-loop air revitalisation, oxygen generation via electrolysis, and water recovery from waste streams. Mirrors the ISS CDRA, OGS, and WPA architecture with full ROS 2 service and action server interfaces.
Operational
TCS
Thermal Control
RK4-based thermal node simulation across avionics, tanks, and equipment. Cooling loops activate dynamically when thresholds are exceeded. FDIR events published to diagnostics in real time.
Operational
EPS
Electrical Power
Solar array tracking, 24 battery ORU management, bus switching via MBSU, and regulated DC conversion through BCDU. DDCU in progress.
DDCU in progress
ECLSS in depth

Keeping humans
alive in orbit

The ECLSS models the three core processes: scrubbing CO2 from cabin air, generating fresh oxygen through electrolysis, and recovering clean water from wastewater. Each one is a separate ROS 2 node. They talk to each other over topics and services exactly the way the real ISS systems do.

The Sabatier reaction is modelled too — CO2 and hydrogen combine to produce water, which feeds back into the oxygen generation cycle. It is a genuinely closed loop, not a toy approximation.

ECLSS closed loop
Cabin Air ──CO₂──► ARS / CDRA ──stored──► Sabatier ──H₂O──► WRS

↑ H₂ feed ↓ product water

Cabin Air ◄──O₂── OGS ◄──clean H₂O── WRS / WPA ◄──waste Crew
  • ARS publishes CO2 storage telemetry and handles scrubbing failure modes
  • OGS models electrolysis and Sabatier, integrated with ARS and WRS
  • WRS implements multi-stage purification and grey water handling
  • All subsystems expose ROS 2 action servers and services
Thermal control

Managing heat
at the extremes

In low Earth orbit the station cycles between +120°C in sunlight and -160°C in shadow every 90 minutes. The TCS simulation uses RK4 integration over a graph of configurable thermal nodes and links to model that dynamic accurately. Cooling loops trigger when node temperatures exceed configured thresholds.

Nodes represent equipment with temperature, heat capacity, and internal power dissipation. Links define conduction between adjacent nodes. The whole system is configured from YAML — you can model any thermal topology without changing code.

FDIR events publish to /diagnostics when overheating or loop failures are detected, which lets a ground control GUI or a monitoring node respond in real time.

+85°C
Avionics Bay
+42°C
Propellant Tank
+21°C
Crew Module
−18°C
External Radiator
Electrical power

Power from the
sun to the rack

The EPS models the full ISS power chain from solar tracking through battery storage, bus switching, and regulated DC conversion. Each component is a ROS 2 node. The BCDU coordinates parallel battery charging and discharging via an action server, monitors voltage bounds, and enters safe mode on fault. MBSU routes power from healthy channels. DDCU is in progress.

☀️
SARJ
Solar array tracking, publishes voltage
🔋
Battery ORUs
24 units, charge and discharge managed
⚙️
BCDU
Action server, parallel ops, safe mode on fault
🔀
MBSU
Routes healthy channels, averages bus voltage
🔌
DDCU
Regulated 124.5V output  In progress
🛰
Station Loads
ECLSS, TCS, avionics, crew
Architecture

Hardware-ready
from day one

Every subsystem follows the same ROS 2 interface pattern: a telemetry topic for continuous state publishing, a service for synchronous requests, an action server for long-running operations, and a diagnostics topic for FDIR events. Swapping a simulation node for a real hardware driver requires changing the implementation, not the interface.

ROS 2 interface pattern per subsystem
Subsystem Node
├─ /telemetry topic publish state continuously
├─ /request service synchronous data requests
├─ /control action long-running operations
└─ /diagnostics topic FDIR fault events
  • C++ and Python nodes coexist in the same ROS 2 workspace
  • PyQt5 GUI panels for crew and mission control views
  • Docker-based setup for reproducibility across contributors
  • GitHub maintained with documentation and issue tracking