Support Status
What you get, at which version, tested how hard — the analogue of
Rust’s platform-support page. Version strings on this page are
parsed from nros-sdk-index.toml and rust-toolchain.toml (the
pinning SSoTs), so they cannot drift from what nros setup
actually installs.
CI tiers — what “supported” means
| Tier | Lane | Runs | Guarantee |
|---|---|---|---|
| 1 | ci (every change) | Host-native builds + native fixtures, all gates | The logic and the seams are sound. Says nothing about embedded targets. |
| 2 | ci-matrix (when core/codegen/cmake move) | 1-wise cover: every platform, language, RMW, and kind appears at least once (~28 % of the coordinate space) | Each axis value builds and runs somewhere — but pairings are NOT covered. |
| 2-nightly | ci-matrix-nightly | Pairwise cover (~70 %) | Platform×language and RMW×language interactions surface here, within a day. |
| 3 | ci-full (pre-release) | The whole matrix | Everything the tree claims, verified together. |
Per-board support levels are generated on their own page: Board Support Levels. The procurement view, including parts with no board package, is Supported Boards.
RTOS / platform source pins
nros setup <board> fetches exactly these (shared store
${NROS_HOME:-~/.nros}/sdk):
| Component | Pinned version | Used by |
|---|---|---|
| FreeRTOS kernel | 10.6.2 | FreeRTOS boards (QEMU MPS2-AN385, overlays) |
| lwIP | 2.2.0 | FreeRTOS networking |
| ThreadX | 6.4.1 | ThreadX (Linux sim + QEMU RISC-V64) |
| NetX Duo | 6.4.x | ThreadX networking |
| NuttX kernel | 12.13.0 | NuttX (QEMU armv7a / rv32) |
| Zephyr SDK | 0.16.8 (+ 1.0.1 for the 4.4 rolling line) | Zephyr module builds |
| mbedTLS | 3.x | zenoh TLS transport |
These pins are decisions, not lags — they move only with a reason, tested together (see Integrating into a Vendored Tree).
RMW backends — versions and interop pairing
| Backend | Client side (pinned) | Host side | Pairing rule |
|---|---|---|---|
| Zenoh | zenoh-pico 1.10.1 (vendored submodule) | Router = the one ROS ships: ros2 run rmw_zenoh_cpp rmw_zenohd — nano-ros deliberately vendors no router | zenoh-pico’s wire protocol is stable across zenoh 1.x, so the pinned client interops with a newer ROS-shipped router |
| XRCE-DDS | Micro-XRCE-DDS client 3.0.1 + Micro-CDR 2.0.2 | Agent 2.4.3-nros1 (installed by nros setup … --rmw xrce) | Client and agent are pinned independently and are NOT the same upstream release; they meet at the DDS-XRCE wire protocol |
| Cyclone DDS | fork 0.10.5-nros1 — upstream 0.10.5 + carried patches (fork delta) | Talks RTPS directly to rmw_cyclonedds_cpp | Pinned to the Cyclone ROS ships (ros-humble-cyclonedds 0.10.5) — upstream 11.x is deliberately NOT a rebase target until a distro migration |
Per-feature coverage across the three backends: Per-RMW Feature Matrix.
ROS 2 editions
| Edition | Feature / flag | Status | Notes |
|---|---|---|---|
| Humble | ros-humble (default) | Supported | TypeHashNotSupported key expressions, XCDR1. No rmw_zenoh_cpp apt package — zenoh interop on Humble needs a source overlay, or use Cyclone DDS. |
| Iron | ros-iron | Supported | RIHS01 type hashes. Same zenoh-apt caveat as Humble. |
| Jazzy | ros-jazzy | Supported | RIHS01; ships ros-jazzy-rmw-zenoh-cpp — the zenoh-interop reference edition. A default Jazzy peer encodes XCDR1/FINAL, which nano-ros speaks; per-type XCDR2 (@appendable) is not enabled. |
Pick the edition of the ROS system you interop with — mismatched editions discover nothing (different key expressions).
Supported means WIRE interop, not API parity. nano-ros’s API is
compared against Humble and Jazzy — Jazzy from pinned upstream
sources, since it cannot be installed beside Humble
(how the comparison runs). Iron is not compared on its own; what it added and Jazzy kept is
covered there. Jazzy’s additions over Humble are each RULED, not each implemented:
matched/incompatible-type events, timer call info,
the small rclcpp accessors,
count_clients/count_services, the client GID and
event_type_is_supported are implemented;
BEST_AVAILABLE QoS is implemented,
resolved at creation against the discovered graph;
dynamic typesupport, service introspection and the
~/get_type_description service are declined on RAM/flash grounds;
rmw_discovery_options_t is answered by the session locator and
localhost_only. Type hashes (RIHS01) are on the wire today.
Toolchains
| Tool | Pinned version |
|---|---|
| Rust | 1.99.0 channel (rust-toolchain.toml); pinned cross targets: thumbv7m-none-eabi, thumbv7em-none-eabihf, armv7r-none-eabi, armv7r-none-eabihf, armv8r-none-eabihf, riscv32imc-unknown-none-elf, riscv64gc-unknown-none-elf, aarch64-unknown-none, armv7a-none-eabi, armv7a-none-eabihf, thumbv7em-none-eabi, thumbv8m.main-none-eabi, thumbv8m.main-none-eabihf, i686-unknown-linux-gnu, x86_64-unknown-none, thumbv6m-none-eabi. rustfmt runs on nightly (nightly-only options). |
Arm GCC (arm-none-eabi) | 13.2-nros5 |
RISC-V GCC (riscv-none-elf) | 14.2-nros1 |
| QEMU (patched, Arm) | 11.0.0-nros8 |
| Corrosion (CMake↔Cargo) | 0.6.1-nros1 (≥ 0.6.0 required — older versions share one build dir across workspace roots and break the mixed link) |
| OpenOCD | 0.12.0-nros2 |
| sccache | 0.17.0-nros1 |
-nros<N> suffixes mark builds re-packaged (or patched) for the SDK
store; the base version is the upstream release.
Related
- Install — how these get onto
a machine (
nros setup, prebuilt-vs-source rules) - Per-RMW Feature Matrix
- Board Support Levels (generated) · Supported Boards (procurement view)
- Integrating into a Vendored Tree — pinning and upgrading these from a company tree