DOCS ros2 multicast
Support# ROS 2 Support in Bauxite Mesh
Bauxite Mesh supports ROS 2 deployments across distributed networks by providing a centralized FastDDS Discovery Server on the mesh interface. Implemented in the `bauxite-citadel` crate via `RosProvider` and `ZenohProvider`.
## How it works
ROS 2's default discovery mechanism (Simple Discovery Protocol) relies on UDP multicast, which is often blocked or unsupported over WANs. Bauxite Mesh provides an alternative discovery path:
1. **Discovery Server**: On startup (with the `ros` feature), Bauxite spawns the `fastdds` discovery server as a child process on the mesh virtual IP (default port `11811`). The `RosProvider` injects `ROS_DISCOVERY_SERVER` and `ROS_DOMAIN_ID=42` environment variables when spawning ROS processes, directing nodes to use the centralized server instead of multicast.
2. **Domain Isolation**: All ROS processes spawned through Bauxite use `ROS_DOMAIN_ID=42` to prevent conflicts with local LAN ROS traffic.
3. **Zenoh DDS Bridge** (optional): Bauxite can also spawn the external `zenoh-bridge-dds` binary on the mesh IP as an alternative DDS bridge. Bauxite only handles process spawning and binary availability checks — the bridge's behavior is governed by the `zenoh-bridge-dds` tool itself.
## ROS 2 Bridging with Zenoh
Bauxite Mesh can spawn the external `zenoh-bridge-dds` binary as an alternative to the standard FastDDS Discovery Server. Bauxite spawns the process via `ZenohProvider::start_bridge()` with the endpoint `-e tcp/{mesh_ip}:7447`.
### Requirements:
- The `zenoh-bridge-dds` binary must be available in the system's `PATH`.
- Bauxite checks for binary availability via `ProcessSpawner::check_available()` before attempting to spawn it.
> **Note**: Performance claims about Zenoh (zero-copy, scalability, minification) refer to the `zenoh-bridge-dds` tool itself, not capabilities Bauxite provides. Bauxite's role is limited to process lifecycle management.
## Enabling ROS 2 Support
To use ROS 2 features, the Bauxite Agent must be built with the `ros` feature flag:
```bash
cargo build --features ros
```
> **Note**: The `ros` feature depends on `bauxite-citadel` (`dep:bauxite-citadel`), which provides the `RosProvider`, `ZenohProvider`, and `ProcessSpawner` abstractions.
## External Requirements
- **FastDDS**: The `fastdds` discovery server binary must be installed and available in `PATH`. Bauxite verifies this at startup via `fastdds --version`.
- **zenoh-bridge-dds** (optional): The `zenoh-bridge-dds` binary must be installed if using the Zenoh DDS bridge. Bauxite checks for it via `zenoh-bridge-dds --help`.
- **Configuration**: The agent reads ROS configuration from `config.toml`:
- `discovery_server_id` (default: `0`)
## Using ROS 2 Discovery Server
When active, the Bauxite Agent acts as a Discovery Server for your local ROS 2 environment.
1. Start the agent with ROS support enabled.
2. Note the connection string provided in the output (format: `<mesh_ip>:<discovery_port>`).
3. On your local machine, export the discovery server address:
```bash
export ROS_DISCOVERY_SERVER=10.42.0.1:11811
```
4. Start your ROS 2 nodes as usual. They will discover other nodes via the centralized server, provided all participating nodes are connected to the Bauxite mesh and use the FastDDS Discovery Server protocol (not default multicast discovery).