rosbridge_suite
rosbridge_suite copied to clipboard
Listing Params Fails
Description Listing params crashes.
- Library Version:
ros-galactic-rosbridge-suite/now 1.2.0-1focal.20220520.221227 arm64
- ROS Version:
ros-galactic-ros-core/now 0.9.3-2focal.20220430.175608 arm64
- Platform / OS: Docker (see Dockerfile below)
Steps To Reproduce
- Run from Dockerfile below with host networking enabled.
- Listing topics works fine (tested with
roslibpy
) and shows topics of other devices. - Listing params causes crash (log below). Test with
roslibpy
and ROS Control Center.
FROM ros:galactic-ros-core
# install ros package
RUN apt-get update && apt-get install -y \
ros-${ROS_DISTRO}-rosbridge-suite \
ros-${ROS_DISTRO}-irobot-create-msgs && \
rm -rf /var/lib/apt/lists/*
EXPOSE 9090
EXPOSE 11311
# launch ros package
CMD ["ros2", "launch", "rosbridge_server", "rosbridge_websocket_launch.xml"]
Expected Behavior Should return params and not crash.
Actual Behavior
docker_rosbridge-1 | [rosapi_node-2] Traceback (most recent call last):
docker_rosbridge-1 | [rosapi_node-2] File "/opt/ros/galactic/lib/rosapi/rosapi_node", line 330, in <module>
docker_rosbridge-1 | [rosapi_node-2] main()
docker_rosbridge-1 | [rosapi_node-2] File "/opt/ros/galactic/lib/rosapi/rosapi_node", line 321, in main
docker_rosbridge-1 | [rosapi_node-2] rclpy.spin(node)
docker_rosbridge-1 | [rosapi_node-2] File "/opt/ros/galactic/lib/python3.8/site-packages/rclpy/__init__.py", line 196, in spin
docker_rosbridge-1 | [rosapi_node-2] executor.spin_once()
docker_rosbridge-1 | [rosapi_node-2] File "/opt/ros/galactic/lib/python3.8/site-packages/rclpy/executors.py", line 712, in spin_once
docker_rosbridge-1 | [rosapi_node-2] raise handler.exception()
docker_rosbridge-1 | [rosapi_node-2] File "/opt/ros/galactic/lib/python3.8/site-packages/rclpy/task.py", line 239, in __call__
docker_rosbridge-1 | [rosapi_node-2] self._handler.send(None)
docker_rosbridge-1 | [rosapi_node-2] File "/opt/ros/galactic/lib/python3.8/site-packages/rclpy/executors.py", line 418, in handler
docker_rosbridge-1 | [rosapi_node-2] await call_coroutine(entity, arg)
docker_rosbridge-1 | [rosapi_node-2] File "/opt/ros/galactic/lib/python3.8/site-packages/rclpy/executors.py", line 372, in _execute_service
docker_rosbridge-1 | [rosapi_node-2] response = await await_or_execute(srv.callback, request, srv.srv_type.Response())
docker_rosbridge-1 | [rosapi_node-2] File "/opt/ros/galactic/lib/python3.8/site-packages/rclpy/executors.py", line 107, in await_or_execute
docker_rosbridge-1 | [rosapi_node-2] return callback(*args)
docker_rosbridge-1 | [rosapi_node-2] File "/opt/ros/galactic/lib/rosapi/rosapi_node", line 281, in get_param_names
docker_rosbridge-1 | [rosapi_node-2] response.names = params.get_param_names(self.globs.params)
docker_rosbridge-1 | [rosapi_node-2] File "/opt/ros/galactic/lib/python3.8/site-packages/rosapi/params.py", line 198, in get_param_names
docker_rosbridge-1 | [rosapi_node-2] params.extend(get_node_param_names(node, params_glob))
docker_rosbridge-1 | [rosapi_node-2] File "/opt/ros/galactic/lib/python3.8/site-packages/rosapi/params.py", line 218, in get_node_param_names
docker_rosbridge-1 | [rosapi_node-2] return _get_param_names(node_name)
docker_rosbridge-1 | [rosapi_node-2] File "/opt/ros/galactic/lib/python3.8/site-packages/rosapi/params.py", line 232, in _get_param_names
docker_rosbridge-1 | [rosapi_node-2] raise RuntimeError("Wait for list_parameters service timed out")
docker_rosbridge-1 | [rosapi_node-2] RuntimeError: Wait for list_parameters service timed out
docker_rosbridge-1 | [ERROR] [rosapi_node-2]: process has died [pid 47, exit code 1, cmd '/opt/ros/galactic/lib/rosapi/rosapi_node --ros-args -r __node:=rosapi --params-file /tmp/launch_params_hle518xg --params-file /tmp/launch_params_yssmut5v --params-file /tmp/launch_params_ofn5szvm'].
Really hitting a roadblock with this. Anything else I can do to debug?
I saw this as well, and the root cause seemed to be component containers. These show up as nodes on the ros network, but don't have parameter services like regular nodes since the loaded components have that responsibility.
At the moment, I'm not sure of what the best fix is. On my own fork I'm simply going to bypass the check which generates the exception.