Using Librux With ROS 2
Librux does not require a robot system to remove ROS 2.
The supported boundary is explicit. Either expose ROS 2 through a Librux-managed interface subsystem, or keep the client outside the native runtime and use Host Control WebSocket.
The ROS 2 Interface Subsystem is ordinary subsystem code that uses the Librux
SDK and a ROS 2 client library in the same Linux process boundary. It declares
the Librux Spec surfaces exposed to the rest of the robot system and translates
between those surfaces and the local ROS 2 graph.
The WebSocket path is different. It is for browser, cloud, desktop, or non-Librux clients that should observe or control a Librux host without joining native runtime transport.
Different Architectural Layers
ROS 2 is commonly used as a node graph and integration ecosystem. Librux is an execution runtime boundary for software-defined robot systems.
| ROS 2 concept | Librux concept |
|---|---|
| Node graph | Subsystem runtime |
| Topic/service/action graph | Declared Event / Control / Procedure / Operation surfaces |
| DDS/RMW transport selection | Runtime-owned local transport and federation |
| Launch files and node composition | Managed packages and resource leases |
| Package ecosystem | Contracted subsystem execution boundary |
The comparison is not adversarial. A system can use ROS 2 inside a subsystem while using Librux to govern how that subsystem is launched, observed, timed, federated, and exposed to the rest of the robot system.
Common Patterns
ROS 2 inside a device gateway
A sensor or actuator stack can remain ROS 2 internally. A ROS 2 interface
subsystem publishes the product-facing Librux state and control contract.
Librux wrapper around an existing ROS 2 application
An existing ROS 2 graph can be treated as one subsystem and launched through a
managed package with CPU, NIC, CAN, or serial claims.
ROS 2 simulation interface
A simulator or ROS 2 simulation stack can expose selected state through a
Librux interface subsystem so the same downstream subsystem contracts are used
in simulation and hardware deployment.
Runtime boundary for product integration
ROS 2 remains useful inside the subsystem. Librux becomes the layer that
coordinates multi-host federation, timing acceptance, resource admission, and
external operations surfaces.
External observation and control
A non-Librux tool can use Host Control WebSocket to observe Events and invoke
Procedure or Operation calls. This is the correct path for browser frontends,
cloud tools, Windows/macOS applications, and other clients that should stay
outside native runtime transport.
Boundary Rule
Keep ROS 2 graph details inside the subsystem boundary when the rest of the robot does not need to know them.
Expose Librux contracts at the boundary when another subsystem, host, UI, or product service needs stable access.
When ROS 2 code must participate in native Librux timing, resource, and federation semantics, implement it as a ROS 2 interface subsystem. When the client is external to the runtime, use Host Control WebSocket.
This keeps local experimentation and existing ROS 2 packages usable while giving the deployed robot a clearer runtime contract.
Scope
This page is about integration boundaries. Communication measurement and comparison methodology belong to the Performance section.