ROS 2 Workflow

The ROS 2 interface of SRB allows you to interact with the simulation environment using standard ROS 2 middleware interfaces. This enables you to develop and validate autonomous systems across a wide range of diverse scenarios through seamless integration with the rest of your ROS 2 or Space ROS nodes.

There are two options for using the ROS 2 interface of SRB:

1. Active ROS 2 Agent: A specific srb agent ros workflow that enables full control over the simulation through the ROS 2 middleware, including actions of robots (control commands)
2. Passive ROS 2 Interface: Any workflow can be configured to use the ROS 2 interface for publishing all available data and interacting with the simulation through services, but the actions are controlled via the selected workflow (teleoperation, random agent, RL training and evaluation, …)

1. Active ROS 2 Agent

This workflow is specifically designed for full control over the simulation, including the actions of robots (control commands). It is available via the srb agent ros command, and works with all SRB environments. Let’s try it with the peg_in_hole task and the visual sensors enabled:

srb agent ros -e peg_in_hole env.num_envs=2 'env.active_sensors=[proprioception,contact,transform,visual]'

For closed-loop controllers that compute one action from each received simulator state, run the ROS agent in synchronized mode:

srb agent ros --ros_sync -e peg_in_hole env.num_envs=2 'env.active_sensors=[proprioception,contact,transform,visual]'

Without --ros_sync, the active ROS agent samples and holds the latest received action each simulation step, while pacing the loop to the environment agent step period (env.agent_rate). This is useful for one-shot commands and teleoperation-like publishers. If the external controller publishes slower than the environment agent period, the simulator can still reuse cached actions for multiple steps. Use --ros_unthrottled only when you intentionally want the old fastest-possible sample-and-hold loop.

Action subscription topics use latest-only best-effort QoS (KEEP_LAST, depth 1). This keeps high-rate controller publishers from building a reliable backlog of stale commands.

Some tasks intentionally configure action or observation delays for policy robustness. For controller debugging, disable those explicitly, for example:

srb agent ros --ros_sync -e waypoint_navigation env.action_delay_steps=0 env.observation_delay_steps=0

List Topics

Once the simulation is running, you can open another terminal and list all available ROS 2 topics:

ros2 topic list

Hint: For Docker installation, you can use .docker/join.bash to enter the running container if you don’t have a local ROS 2 setup available.

/clock
/parameter_events
/rosout
/srb/env0/action/cmd_vel
/srb/env0/action/event
/srb/env0/cam_base/camera_info
/srb/env0/cam_base/image_depth
/srb/env0/cam_base/image_rgb
/srb/env0/cam_base/pointcloud
/srb/env0/cam_scene/camera_info
/srb/env0/cam_scene/image_depth
/srb/env0/cam_scene/image_rgb
/srb/env0/cam_scene/pointcloud
/srb/env0/cam_wrist/camera_info
/srb/env0/cam_wrist/image_depth
/srb/env0/cam_wrist/image_rgb
/srb/env0/cam_wrist/pointcloud
/srb/env0/end_effector/joint_pos
/srb/env0/end_effector/joint_states
/srb/env0/reward
/srb/env0/reward/penalty_action_rate
/srb/env0/reward/penalty_undesired_robot_contacts
/srb/env0/reward/reward_align_peg_to_hole_primary
/srb/env0/reward/reward_align_peg_to_hole_secondary
/srb/env0/reward/reward_distance_end_effector_to_obj
/srb/env0/reward/reward_distance_peg_to_hole_bottom
/srb/env0/reward/reward_distance_peg_to_hole_entrance
/srb/env0/reward/reward_grasp
/srb/env0/reward/reward_lift
/srb/env0/robot/delta_twist
/srb/env0/robot/joint_states
/srb/env0/terminated
/srb/env0/truncated
/srb/env1/...          (mirrors env0)
/srb/envs/action/cmd_vel
/srb/envs/action/event
/srb/envs/end_effector/joint_pos
/srb/envs/robot/delta_twist
/tf
/tf_static

Most topics fall under two namespaces:

• /srb/env[0-N]/...: Environment-specific topics that are unique to each environment instance
• /srb/envs/...: Global topics that apply to all environment instances

Note: With a single environment (env.num_envs=1), the env{i}/ and envs/ prefixes are omitted and topics are published directly under /srb/... (e.g. /srb/reward, /srb/action/cmd_vel).

Let’s break down the most important topics:

Subscribe to Topics

You can subscribe to topics to receive updates from the simulation. For example, you can echo the reward signal of the first environment instance:

ros2 topic echo /srb/env0/reward

data: 2.36441707611084
---
data: 2.3652756214141846
---
data: 2.36613130569458
---
data: 2.3669850826263428
---

Publish to Topics

You can also send control commands to the simulation by publishing to topics. For example, you can move robots in all environment instances by publishing a twist command:

ros2 topic pub --once /srb/envs/action/cmd_vel geometry_msgs/Twist "{linear: {z: -0.2}, angular: {z: 0.785}}"

2. Passive ROS 2 Interface

Alternatively, you can use the ROS 2 interface with any agent type by specifying the --interface ros flag. This allows you to collect sensor data and interact with the simulation instances while controlling the agent through the selected workflow. Let’s try it with the rand agent in the multi_sample_collection environment with 8 parallel instances and visual sensors enabled:

srb agent rand -e multi_sample_collection env.num_envs=8 'env.active_sensors=[proprioception,contact,transform,visual]' --interface ros

Note: The --interface X option accepts one or more interfaces, but Hydra key=value overrides placed directly after it are automatically detected and forwarded to Hydra.

Call Services

Upon listing the available services, you will see that each environment instance has a /srb/env{i}/reset service, and a global /srb/envs/reset service.

ros2 service list

You can call these services to reset a specific environment instance or all instances at once:

ros2 service call /srb/env0/reset std_srvs/srv/Empty

ros2 service call /srb/envs/reset std_srvs/srv/Empty