ros2/ros1_bridge

ROS2-side server bridge stays open after the server is destroyed

Closed this issue · 3 comments

Bug report

Required Info:

  • Operating System:

    • Ubuntu Focal
  • Installation type:

    • From source
  • Version or commit hash:

  • DDS implementation:

    • Fast-RTPS
  • Client library:

    • rclcpp and rclpy

Steps to reproduce issue

Launch a ROS1 master:

# Shell A:
. <ros-install-dir>/setup.bash
roscore -p 11311

Launch the dynamic_bridge:

# Shell B:
. <ros-install-dir>/setup.bash
. <ros2-install-dir>/setup.bash
export ROS_MASTER_URI=http://localhost:11311
ros2 run ros1_bridge dynamic_bridge

Launch a server on the ROS2-side:

# Shell C:
. <ros2-install-dir>/setup.bash
ros2 run demo_nodes_py add_two_ints_server

Now, stop the server in shell C (Ctrl+C) and run a server on the ROS1-side:

# Shell D:
. <ros-install-dir>/setup.bash
export ROS_MASTER_URI=http://localhost:11311
rosrun rospy_tutorials add_two_ints_server

Launch a client on the ROS2 side:

# Shell C (continued):
ros2 run demo_nodes_py add_two_ints_client

The service won't be found by the client and you'll see the message service not available, waiting again....

In my experience, the dynamic_bridge has to be restarted before I can start a service with the same service name.

You can try going in the other direction: start with a service on ROS1 before trying a service on ROS2 and it should work. Notice that on the bridge, it says Created 2 to 1 bridge for service /add_two_ints when the server is created and then Removed 2 to 1 bridge for service /add_two_ints when the server is stopped. On the ROS2 side, the bridge is created, but the bridge is not removed when the service is stopped. I have found this to be true for both the C++ and Python examples.

Expected behavior

That I'm able to create a server with the same name on either the ROS1-side or ROS2-side, close that server, and then create the server on the other side.

Actual behavior

I'm not able to discover the server created on the ROS1-side of the bridge after it has been created and the node has been deleted on the ROS2-side. It seems that this is because the bridge for the ROS2 server is never removed.

@audrow It would be great if you could test this case again with the two proposed patches and confirm that is solves the problem.

@dirk-thomas Will do.

@dirk-thomas I can confirm that the two patches solve the problem.