Closed fujitatomoya closed 3 months ago
as it shows, endpoint discovery works okay so that we can see one publisher is online to the topic.
root@tomoyafujita:~/docker_ws/ros2_humble# ros2 topic info -v /kachaka/layout/locations/list
Type: kachaka_interfaces/msg/LocationList
Publisher count: 1
Node name: _NODE_NAME_UNKNOWN_
Node namespace: _NODE_NAMESPACE_UNKNOWN_
Topic type: kachaka_interfaces/msg/LocationList
Endpoint type: PUBLISHER
GID: 01.0f.00.12.7f.8c.9d.d0.01.00.00.00.00.00.7d.03.00.00.00.00.00.00.00.00
QoS profile:
Reliability: RELIABLE
History (Depth): UNKNOWN
Durability: TRANSIENT_LOCAL
Lifespan: Infinite
Deadline: Infinite
Liveliness: AUTOMATIC
Liveliness lease duration: Infinite
Subscription count: 0
but cannot see the node,
root@tomoyafujita:~/docker_ws/ros2_humble# ros2 node list
any thoughts?
https://github.com/pf-robotics/kachaka-api/issues/66 is similar issue, no topic data is on the transport...
ROS_DOMAIN_ID and ROS_LOCALHOST_ONLY What are the values of
Would adding ROS_LOCALHOST_ONLY to .env improve the situation?
You are running the client as root, can you run it as the same user as bridge?
@fujitatomoya Thank you for your rapid Kachaka API prototyping.
I would like to separate the Docker problem and the Kachaka API problem. Could you follow the procedure to run the ROS 2 bridge without the Docker. https://speakerdeck.com/youtalk/jia-ting-yong-zi-lu-yi-dong-robotuto-katiyaka-nokai-fa-zhe-apigong-kai-to-ros-2intahueisushi-zhuang?slide=28
If it's OK, it's a Docker networking problem.
ROS_DOMAIN_ID
never set, this affects DDS multicast port offset. do not think this is related.
ROS_LOCALHOST_ONLY
never set, this constraints communication only in localhost address. i did bind network interfaces to the containers with --net=host
, so actually this is already in effect since all applications (bridge and ros2 workspace) running in the same host.
You are running the client as root, can you run it as the same user as bridge?
why this is related? could you elaborate a bit?
Could you follow the procedure to run the ROS 2 bridge without the Docker.
i would try this later. (kinda inclined to do so, since i do not want to install those packages in the host system but docker... besides, official procedure tells me to start up the bridge via docker compose that creates container.)
IMO, is this something that multicast issue for network environment that i (user) have, cz it expects that network support multicast as requirement? but some home network router and environment, intentionally disabled multicast. in that case, this produce does not work as expected? i would try some experimental test for this. if this turns out, probably it would be better to instantiate the discovery server in the procedure.
Do you mount IPC and pid?
like here.
In my experience, it is necessary to do so when running dockers on the same host.
Do you mount IPC and pid?
tried --ipc=host --pid=host
, but it does not work either.
In my experience, it is necessary to do so when running dockers on the same host.
There was an issue for the PID before (3 years ago), since PID is used to generate DDS Participant GUID. But it's been fixed with https://github.com/eProsima/Fast-DDS/pull/1637, that added random value along with PID, so even in the container runtime, GUID will be unique in DDS participant.
i do not think, binding ipc
and pid
namespace would work for this case...
rather, i think it should bind /dev/shm
since it runs rmw_fastrtps
that said Fast-DDS
is running under the hood. in default it enables shared memory transport and data sharing those will use /dev/shm
if the same DDS locator comes in. as you can see below, it ties to use /dev/shm
to buildin discovery and user data payload transport.
I have no name!@tomoyafujita:/$ ls -lt /dev/shm
total 2924
-rw-r--r-- 1 root root 52400 Dec 22 05:23 fastrtps_port7421
-rw-r--r-- 1 root root 0 Dec 22 05:23 fastrtps_port7421_el
-rw-r--r-- 1 root root 549408 Dec 22 05:23 fastrtps_3991a3dbaa29d797
-rw-r--r-- 1 root root 0 Dec 22 05:23 fastrtps_3991a3dbaa29d797_el
-rw-r--r-- 1 root root 32 Dec 22 05:23 sem.fastrtps_port7421_mutex
-rw-r--r-- 1 1000 1000 549408 Dec 22 05:13 fastrtps_c8d3d3df62c5ffef
-rw-r--r-- 1 1000 1000 0 Dec 22 05:13 fastrtps_c8d3d3df62c5ffef_el
-rw-r--r-- 1 1000 1000 52400 Dec 22 05:13 fastrtps_port7419
-rw-r--r-- 1 1000 1000 0 Dec 22 05:13 fastrtps_port7419_el
-rw-r--r-- 1 1000 1000 32 Dec 22 05:13 sem.fastrtps_port7419_mutex
-rw-r--r-- 1 1000 1000 549408 Dec 22 05:13 fastrtps_262841554a0fb871
-rw-r--r-- 1 1000 1000 0 Dec 22 05:13 fastrtps_262841554a0fb871_el
-rw-r--r-- 1 1000 1000 52400 Dec 22 05:13 fastrtps_port7417
-rw-r--r-- 1 1000 1000 0 Dec 22 05:13 fastrtps_port7417_el
-rw-r--r-- 1 1000 1000 32 Dec 22 05:13 sem.fastrtps_port7417_mutex
-rw-r--r-- 1 1000 1000 549408 Dec 22 05:13 fastrtps_5f2fdbde0cedc093
-rw-r--r-- 1 1000 1000 0 Dec 22 05:13 fastrtps_5f2fdbde0cedc093_el
-rw-r--r-- 1 1000 1000 52400 Dec 22 05:13 fastrtps_port7413
-rw-r--r-- 1 1000 1000 0 Dec 22 05:13 fastrtps_port7413_el
-rw-r--r-- 1 1000 1000 32 Dec 22 05:13 sem.fastrtps_port7413_mutex
-rw-r--r-- 1 root root 549408 Dec 22 05:08 fastrtps_ac905f18bde423f9
-rw-r--r-- 1 root root 0 Dec 22 05:08 fastrtps_ac905f18bde423f9_el
unfortunately, with the following patch (binding host /dev/shm
to container can be the security risk), it still does not work.
diff --git a/tools/ros2_bridge/docker-compose.yaml b/tools/ros2_bridge/docker-compose.yaml
index c309638..3ef6e66 100644
--- a/tools/ros2_bridge/docker-compose.yaml
+++ b/tools/ros2_bridge/docker-compose.yaml
@@ -14,6 +14,8 @@ services:
- USER_ID
- GROUP_ID
user: "${USER_ID}:${GROUP_ID}"
+ volumes:
+ - /dev/shm:/dev/shm
command: >
ros2 launch kachaka_grpc_ros2_bridge grpc_ros2_bridge.launch.xml server_uri:=${API_GRPC_BRIDGE_SERVER_URI}
kachaka_follow:
what is strange for me is,
tomoyafujita@~/DVT >docker exec -it b43a5775c0eb /bin/bash
groups: cannot find name for group ID 1000
I have no name!@tomoyafujita:/$ source /opt/ros/humble/setup.bash
I have no name!@tomoyafujita:/$ ros2 node list
I have no name!@tomoyafujita:/$ ros2 topic list
/goal_pose
/kachaka/front_camera/camera_info
/kachaka/front_camera/image_raw
/kachaka/front_camera/image_raw/compressed
/kachaka/imu/imu
/kachaka/layout/locations/list
/kachaka/layout/shelves/list
/kachaka/lidar/scan
/kachaka/manual_control/cmd_vel
/kachaka/mapping/map
/kachaka/object_detection/result
/kachaka/odometry/odometry
/kachaka/robot_info/version
/kachaka_description/joint_states
/kachaka_description/robot_description
/parameter_events
/rosout
/tf
/tf_static
ros2 node list
returns empty even within the kachaka-grpc-ros2-bridge
container which is docker-composed? i believe that it is expected that some nodes running and discovered in this container at least. or i might be mistaken on somthing...
this has been a while, and i do not have any plan to dig deeper at this moment. and nobody else is tracking or working on this, so i will go ahead to close this issue, feel free to reopen.
I am experiencing the same issue reported by @fujitatomoya when trying to run a ROS 2 workspace inside another Docker container. The ROS 2 workspace works fine if built on the host system outside the Docker container. Any new thoughts/ideas to solve this?
In the end, I built kachaka-grpc-ros2-bridge
in my own custom Docker image so that I don't need to run multiple Docker images by following the instructions provided by @youtalk-pfr: https://speakerdeck.com/youtalk/jia-ting-yong-zi-lu-yi-dong-robotuto-katiyaka-nokai-fa-zhe-apigong-kai-to-ros-2intahueisushi-zhuang?slide=28
I can provide more details if someone else is interested in such a Docker deployment.
Setup Procedure
ros2 topic echo
Expected Behavior
should print the
kachaka_interfaces/msg/LocationList
.