roslaunch Python arg substitution finds wrong package folder path?
I've recently played around with Python expressions as substitution args in launch files (on 16.04 AMD64/Kinetic/current .debs). I encountered a curious problem during doing so.
When trying to generalize this line:
<param name="site_description" command="$(find xacro)/xacro --inorder '$(find wrs2018_scenario_description)/urdf/scenario.xacro'" />
the following expression works:
<param name="site_description" command="$(eval find('xacro') + '/xacro.py --inorder ' + find(scenario_name + '_description') + '/urdf/scenario.xacro')" />
However, it has to be noted that I have to use the deprecated xacro.py
here, as the xacro
executable is not found. Investigating further I noted that
$(find xacro)
returns /opt/ros/kinetic/lib/xacro
as a path, where also the xacro
executable is located.
In contrast to this
$(eval find('xacro'))
returns /opt/ros/kinetic/share/xacro
as a path, where only the xacro.py
executable is located.
My expectation was that both calls to find should work identically, but apparently, this is not the case. My questions hence are:
- Is this expected behavior or a bug?
- Is there some other way to get to the "right" folder with the
xacro
executable while using Python substitution args in roslaunch?
This reads like a bug. If you have an easy to reproduce case, then I would suggest reporting it over at ros/xacro/issues. Robert is typically very responsive.
The
eval
version might be using the wrong find pkg functionality internally.Wouldn't filing against ros_comm (containing roslaunch functionality) be more appropriate? While the issue popped up using xacro, the eval logic likely at fault is part of roslaunch, right?
That's true, but you encountered the issue while working with
xacro
. If/when the maintainers of that diagnose this as an issue withrospkg
and/orroslaunch
, then I believe they should either forward you toros_comm
or open an issue there themselves.I don't yet see an advantage of using $(eval) vs. $(find) directly yet. Where is the generalization?
See the answer here. I want to use nested args. This would be possible in a somewhat clean way using Python substitution args.