Open 130s opened 1 year ago
In my report above I noticed a new version of launch
was available so tried, but I still get his issue.
$ apt-cache policy ros-foxy-launch
ros-foxy-launch:
Installed: 0.10.10-1focal.20230306.200955
Candidate: 0.10.10-1focal.20230306.200955
Since Node
is from launch_ros
, have you tried updating ros-foxy-launch-ros
?
Since
Node
is fromlaunch_ros
, have you tried updatingros-foxy-launch-ros
?
Still NG. Btw actually I see launch-ros
was not installed, as when I apt install
ed, it's getting as a new pkg.
$ apt-cache policy ros-foxy-launch-ros
ros-foxy-launch-ros:
Installed: 0.11.7-1focal.20230317.010314
Candidate: 0.11.7-1focal.20230317.010314
Version table:
*** 0.11.7-1focal.20230317.010314 500
500 http://packages.ros.org/ros2/ubuntu focal/main amd64 Packages
100 /var/lib/dpkg/status
Have you tried reproducing with Rolling? I tried to reproduce and I couldn't, so maybe it was fixed after Foxy. I also tried to find potential PRs that fixed this and I couldn't, but I might've just missed them.
Sorry I made my post https://github.com/ros2/launch/issues/704#issuecomment-1520447328 here but it was actually about another problem.
I don't have a plan to use ROS Humble just yet :man_shrugging: so can't tell..
So this is pretty subtle, but I think what is happening here is that the name
that you are specifying in the launch file is being applied to all nodes inside of the executable. That is, both your move_group_node
and your planner_node
are being renamed to pick_place_sample2
. Since we don't really support having two nodes with the same name, you get the behavior you see here.
I have at least two suggestions:
name
argument to the Node
call in the launch file. That will give the nodes their default names, and avoid the conflict.Node
per library or executable. You can then compose them together using composable nodes, or something like that.
Issue report
Required Info:
Steps to reproduce issue
t_launch.py
(this causes the issue)Expected behavior
Actual behavior
Stdout
Additional information
Seems related answers.ros.org#344141.
Possible workaround
As mentioned answers.ros.org#344141, removing
name
inNode
instance seems to stop the issue.