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 run 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

I started Space Station OS from a simple question. What would the software stack for a space station look like if you built it the way we build modern robotics infrastructure? So I made each subsystem an independent ROS 2 node with standardised interfaces, and I kept it ready for real hardware from day one.

The architecture is modelled on the ISS. I worked on ECLSS, the thermal control system, and the electrical power system. These are not toy simulations. They follow the actual closed loop logic that the ISS uses. My goal was a platform that another engineer can 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. It 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 when thresholds are exceeded. FDIR events are 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 in the same way the real ISS systems do.

I also modelled the Sabatier reaction, where CO2 and hydrogen combine to produce water. That water feeds back into the oxygen generation cycle, so the loop is really closed and 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 this behaviour accurately. Cooling loops trigger when node temperatures exceed the 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, so you can model any thermal topology without changing the code.

FDIR events publish to /diagnostics when overheating or loop failures are detected. This 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 through 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. To swap a simulation node for a real hardware driver, you change the implementation and keep 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