Pavel on AsyncAPI

Appearance

ROS 2 Server Binding v0.1.0 ​

The ROS 2 server binding defines how AsyncAPI servers map to ROS 2 system configurations. This binding allows you to specify domain IDs for network isolation and middleware implementations for communication handling.

Overview ​

ROS 2 server bindings configure the underlying communication infrastructure for your robotics system. They define:

  • Domain ID: Network isolation for different robot groups
  • Middleware Implementation: The RMW (ROS Middleware) implementation to use
  • System Configuration: Global settings that affect all nodes in the system

Properties ​

PropertyTypeRequiredDescription
bindingVersionstringNoThe version of this binding. If omitted, 'latest' MUST be assumed.
domainIdintegerNoDomain ID for network isolation (0-231, default: 0)
rmwImplementationstringNoROS 2 middleware implementation to use

bindingVersion ​

The version of this binding. If omitted, 'latest' MUST be assumed.

Type: string
Enum: ["0.1.0"]
Required: No

domainId ​

All ROS 2 nodes use domain ID 0 by default. To prevent interference between different groups of computers running ROS 2 on the same network, a group can be set with a unique domain ID.

Type: integer
Range: 0-231
Default: 0
Required: No

Usage:

  • Use domain ID 0 for default ROS 2 behavior
  • Use different domain IDs (1-231) to isolate robot groups on the same network
  • Each domain ID creates a separate communication space

rmwImplementation ​

Specifies the ROS 2 middleware implementation to be used. This determines the underlying middleware implementation that handles communication.

Type: string
Required: No

Common Values:

  • rmw_fastrtps_cpp: Default DDS implementation (FastRTPS)
  • rmw_cyclonedds_cpp: Alternative DDS implementation (CycloneDDS)
  • rmw_opendds_cpp: OpenDDS implementation
  • rmw_connextdds: RTI Connext DDS implementation

Examples ​

Basic Configuration ​

yaml
servers:
  ros2Server:
    url: ros2://localhost
    protocol: ros2
    bindings:
      ros2:
        bindingVersion: "0.1.0"
        domainId: 0
        rmwImplementation: "rmw_fastrtps_cpp"

Multi-Robot System ​

yaml
servers:
  robotGroup1:
    url: ros2://robot1.local
    protocol: ros2
    bindings:
      ros2:
        bindingVersion: "0.1.0"
        domainId: 1
        rmwImplementation: "rmw_fastrtps_cpp"
  
  robotGroup2:
    url: ros2://robot2.local
    protocol: ros2
    bindings:
      ros2:
        bindingVersion: "0.1.0"
        domainId: 2
        rmwImplementation: "rmw_cyclonedds_cpp"

Custom Middleware ​

yaml
servers:
  customRos2Server:
    url: ros2://custom.local
    protocol: ros2
    bindings:
      ros2:
        bindingVersion: "0.1.0"
        domainId: 10
        rmwImplementation: "rmw_connextdds"

Use Cases ​

Network Isolation ​

  • Development vs Production: Use different domain IDs to separate development and production environments
  • Multi-Robot Systems: Isolate different robot groups to prevent interference
  • Testing: Use separate domain IDs for testing different configurations

Middleware Selection ​

  • Performance: Choose middleware based on your performance requirements
  • Compatibility: Select middleware that works with your existing systems
  • Features: Different middleware implementations offer different features

System Configuration ​

  • Global Settings: Configure system-wide parameters that affect all nodes
  • Network Setup: Define how ROS 2 nodes communicate across the network
  • Infrastructure: Set up the underlying communication infrastructure

Best Practices ​

Domain ID Management ​

  • Use domain ID 0 for default behavior
  • Choose domain IDs 1-231 for isolation
  • Document domain ID assignments for your system
  • Avoid conflicts in multi-robot deployments

Middleware Selection ​

  • Test different middleware implementations for your use case
  • Consider performance characteristics of each middleware
  • Ensure compatibility with your ROS 2 distribution
  • Monitor resource usage of different implementations

Configuration Management ​

  • Version control your server configurations
  • Use environment-specific domain IDs
  • Document middleware choices and rationale
  • Test configurations in your target environment