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.