ROS Bridge (ros1_bridge)

The bridge's core function is the real-time translation of ROS messages between the two middleware versions. It acts as a dual-language interpreter, subscribing to topics in one ROS version and publishing the semantically equivalent data on a mirrored topic in the other. This is not a simple pass-through; it involves:

• Serialization/Deserialization: Converting binary message blobs between the ROS 1 (roscpp) and ROS 2 (rclcpp/rclpy) serialization formats.
• Type Adaptation: Mapping between ROS 1 .msg types and their ROS 2 .msg or .idl equivalents, even when field names or nested structures differ slightly.
• Dynamic Bridging: Bridges can be created statically for known common types (e.g., geometry_msgs/Twist) or dynamically at runtime for custom messages using type description introspection.

Beyond simple topics, the ros1_bridge facilitates synchronous request-response communication and long-running task execution across ROS versions.

• Service Bridging: A ROS 1 client can call a service on a ROS 2 server, and vice-versa. The bridge translates the service request and response messages, managing the blocking call semantics between the asynchronous ROS 2 executor and the synchronous ROS 1 service model.
• Action Bridging: Supports the translation of ActionLib (ROS 1) and Actions (ROS 2) interfaces. This allows a ROS 2 action client to send a goal to a ROS 1 action server, receiving feedback and results during execution, which is essential for complex tasks like navigation or manipulation.

The bridge operates in two distinct modes, offering a trade-off between performance and flexibility.

• Static Bridging: Pre-compiled bridge nodes for a defined set of common message and service types (e.g., sensor_msgs/Image, nav_msgs/Odometry). This mode offers lower latency and higher throughput as no runtime type discovery is needed. It is the recommended mode for production systems with known, stable interfaces.
• Dynamic Bridging: A generic bridge process that can introspect and translate arbitrary, user-defined message types at runtime. This is invaluable for development, prototyping, and integrating systems with custom messages, but incurs the overhead of type description lookup and on-the-fly code generation for each new type encountered.

One of the most complex translation layers involves reconciling the fundamentally different communication models of ROS 1 and ROS 2 via QoS policy mapping.

• ROS 1 uses a TCPROS/UDPROS transport with simple, best-effort reliability.
• ROS 2 uses DDS with explicitly configurable QoS policies (reliability, durability, deadline, liveliness). The bridge must map between these models. For example, a ROS 2 subscription with Reliability: RELIABLE and Durability: TRANSIENT_LOCAL publishing to a ROS 1 topic requires the bridge to implement buffering and guaranteed delivery semantics that ROS 1's TCP does not natively provide. Misconfigured QoS mapping is a common source of "lost" messages across the bridge.

The bridge is deployed as one or more ROS nodes that are members of both communication graphs simultaneously.

• Dual Membership: A bridge node runs both the ROS 1 roscpp client library and the ROS 2 rclcpp library, connecting to both a ROS 1 roscore master and the ROS 2 DDS participant discovery domain.
• Network Segmentation: The bridge is the single point of connection between two otherwise isolated ROS networks. This allows for safe, incremental migration where a subsystem (e.g., perception stack) can be upgraded to ROS 2 while the control stack remains on ROS 1.
• Bridge Manager: For complex systems, multiple bridge processes can be managed via launch files to distribute load or isolate critical data flows, preventing a single point of failure from taking down all cross-version communication.

The ros1_bridge is not intended for permanent architecture but is a strategic migration tool. Its key value is enabling a phased, low-risk transition from ROS 1 to ROS 2.

• Brownfield Integration: Allows new ROS 2 components (e.g., a new NVIDIA Isaac-based perception node) to be integrated into an existing, large-scale ROS 1 system (e.g., an industrial mobile robot).
• Subsystem-by-Subsystem Upgrade: Teams can migrate individual packages or functional subsystems (e.g., from move_base to Navigation2) while the rest of the robot continues to operate on the stable ROS 1 stack. The bridge validates the new ROS 2 component's functionality before committing to a full cutover.
• Testing and Validation: Serves as a critical tool for comparative testing and validation, allowing the same sensor data or command streams to be processed by both ROS 1 and ROS 2 versions of an algorithm to verify behavioral parity.

The most common use case is facilitating a phased migration from ROS 1 to ROS 2. Instead of a risky, one-time rewrite, teams can bridge critical components one at a time.

• Strategy: Keep the majority of the system on ROS 1 while developing and testing new ROS 2 nodes (e.g., a new perception stack). The bridge allows the new ROS 2 node to subscribe to sensor data published by legacy ROS 1 drivers.
• Validation: The ROS 2 side can be validated in the live system before the corresponding ROS 1 component is decommissioned. This reduces risk and allows for parallel development.

Many specialized sensors and actuators only have mature, stable drivers available for ROS 1. The bridge allows these legacy drivers to be used within a modern ROS 2-based architecture.

• Hardware Examples: Proprietary industrial robot arms, niche LiDAR sensors, or legacy motor controllers that rely on ROS 1 rosserial.
• Architecture: The hardware-specific node runs in a ROS 1 environment, publishing data (e.g., /scan, /joint_states) or offering services. The ros1_bridge translates these messages for consumption by the core ROS 2 navigation, planning, or control stack.

Research labs and development teams often have a mix of tools; some new algorithms are developed for ROS 2, while others exist only in ROS 1. The bridge creates a hybrid research platform.

• Toolchain Compatibility: A team can use ROS 2-based simulation (e.g., Ignition Gazebo) with a ROS 1-based motion planning library (e.g., MoveIt 1).
• Evaluation: New ROS 2 packages can be benchmarked directly against established ROS 1 benchmarks by having them operate on the same bridged data streams.

In fleets containing older and newer robotic platforms, some robots may run ROS 1 and others ROS 2. The bridge enables cross-stack communication for fleet coordination.

• Orchestration: A central ROS 2-based fleet manager can send goals to and receive status from both ROS 2 and (bridged) ROS 1 robots.
• Data Aggregation: Telemetry and sensor data from all robots can be aggregated into a unified ROS 2-based monitoring or data logging system.

Developers building a new ROS 2 node can test it against a mature, full-stack ROS 1 system before a complete ROS 2 ecosystem is available.

• Workflow: A new ROS 2 controller can be tested by having it receive the robot's state from a bridged ROS 1 state estimator and send commands back to the bridged ROS 1 actuation system.
• Advantage: This provides a rich, realistic test environment without requiring a full port of the entire system to ROS 2 first.

While not its primary design goal, ros1_bridge can be part of a chain to connect to non-ROS systems. This often involves serialization bridges like rosbridge_suite.

• Pattern: A web interface using rosbridge_suite (ROS 1) communicates with a ROS 1 node. The ros1_bridge then translates relevant commands or data to/from the core ROS 2 application.
• Consideration: This adds latency and complexity. Native ROS 2 solutions (e.g., rosbridge_server for ROS 2) are preferred for new designs.

The ROS Graph is the peer-to-peer network of nodes and their communication channels. The bridge fundamentally alters and connects two separate graphs.

• Dual-Graph Topology: The ros1_bridge acts as a proxy node that exists in both the ROS 1 and ROS 2 graphs simultaneously.
• Discovery & Relay: It discovers publishers/subscribers on both sides, creates matching entities on the opposite side, and relays messages, effectively merging aspects of the two distinct computation graphs for specific message flows.

A ROS Message is a strictly typed data structure used for serialization. The bridge's core function is the bidirectional translation of these structures.

• Type Mapping: The bridge requires identical .msg definitions on both ROS 1 and ROS 2 sides for a given topic or service. It uses these definitions to generate translation code.
• Build-Time Generation: The ros1_bridge package must be built for the specific set of messages used in your system. Custom messages require the bridge to be rebuilt from source to include their translators.