One command surface
The turbo CLI brings build, run, test, deploy, migrate, and benchmark workflows into one tool.
An add-on runtime for ROS 2
Keep the ecosystem.
Change the ceiling.
ROSPlus gives new robotics code a high-performance path while existing ROS 2 nodes continue to run unmodified.
Add-on layer. Stock ROS 2 stays intact.
supervisor online
transport: DDSNative modevision_pipeline
Rust · 0 missed/camera/frame
Legacy modenav2_controller
rclcpp · stock executorHEARTBEATOK
MESSAGES12.8k/s
SAFETYARMED
Illustrative interface. Values shown are demonstrative.
Architecture
One supervisory layer.
Two ways to run.
ROSPlus manages both paths through a common command surface while nodes communicate over the same transport.
Native mode
The faster lane for new code
Rust nodes run inside the ROSPlus executor with scheduling, shared-memory, and allocation controls designed for deterministic workloads.
turbo run perception --nativeLegacy mode
Your existing ROS 2 graph
Standard rclpy and rclcpp nodes run as supervised subprocesses on stock ROS 2. Existing packages require no ROSPlus-specific rewrite.
turbo run nav2 --legacyDDS by default
Zenoh for fleets
Safety monitor Runtime metrics Unified CLI
Product surface
A more direct way
to build with ROS 2
Progressive disclosure keeps the first run approachable while giving experienced teams access to code, metrics, and configuration.
Two execution paths
ABI-v1 C and Rust plugins run through the native path. Existing Python and C++ nodes keep stock ROS 2 behavior.
Independent safety rail
A separate watchdog process monitors the runtime and supports simulated GPIO during development.
Visible system health
Structured logs, Prometheus metrics, node status, and missed-deadline tracking surface runtime behavior.
Linux validation · September 2026
Software paths tested.
Hardware proof remains.
ROSPlus now has repeatable Linux evidence across native and legacy execution, migration scenarios, and executor-linked safety monitoring. Physical motor cutoff and production-scale validation are still required before safety or real-time claims can be made.
Current checkpointSoftware validatedPhysical safety pending
Stall → simulated E-Stop66.547 ms100 ms software limit
Verified in the Linux test environment
What passes today
- 01Runtime & supervision
Native C/Rust plugins, stock C++/Python nodes, restarts, logs, metrics, and per-runtime progress monitoring.
- 02Migration compatibility
Recorded bag replay, custom message interfaces, C++, action sequencing with feedback, TF, timers, parameters, and services.
- 03Executor-linked safety
A stalled callback triggered the simulated, latched E-Stop in 66.547 ms—inside the 100 ms software acceptance limit.
- 04Repository quality gates
Rust tests, clippy, formatting, Go race tests, Python tests, frontend build, and all 14 OpenAPI paths passed.
Open validation and engineering work
What remains
- 01Physical safety chain
Verify target controller GPIO/PWM, independent watchdog wiring, relay or motor power cutoff, and measurement equipment.
- 02Broader ROS compatibility
Automate C++, actionlib, and TF conversion; expand custom services/actions, nested interfaces, simulated time, nodelets, and dynamic reconfigure.
- 03Native runtime depth
Add arbitrary message, service, and action types; multi-endpoint plugins; process-shared pools; and protection from callbacks that never return.
- 04Production validation
Run larger workspaces and recorded bags, descendant-heavy process trees, prescribed hardware benchmarks, and the complete acceptance suite.
Status reflects repository test artifacts generated on Linux. The 66.547 ms result uses simulated GPIO; it does not verify a physical relay or motor power cutoff.
Engineering targets
The standard
the native path must meet
Targets from the requirements document. These are acceptance criteria for future hardware testing, not published benchmark results.
ROSPlus / Carter Warrens