search

robotology / yarp-devices-ros2

Plugins, devices and network wrappers for Yarp-ROS2 interoperation
http://www.yarp.it
10 stars 8 forks source link

ros2 interface list not showing yarp msgs #63

Open TheArmega opened 9 months ago

TheArmega commented 9 months ago

Hi, I've experienced some problems after installing the yarp-devices-ros2 repository. When trying to use the yarp_control_msgs I've seen that ros2 wasn't able to find them. At the end I had to copy the files into the ros humble folder, as it follows: sudo cp -r yarp_control_msgs/* /opt/ros/humble/ After this I used the 'ros2 interface list' and was able to find them and use them.

traversaro commented 9 months ago

Hi @TheArmega, how did you installed the repo? With the first or second procedure described in https://github.com/robotology/yarp-devices-ros2#installation ?

TheArmega commented 9 months ago

Hi @traversaro, I installed it as it says in the first procedure, but after it didn't work for me I did this:

cd yarp-devices-ros2
colcon build
cd ros2_interfaces_ws/src/yarp_control_msgs/install
cp -r yarp_control_msgs/* /opt/ros/humble/
traversaro commented 9 months ago

Probably if you followed the first procedure, we should remove the --packages-select map2d_nws_ros2_msgs argument of colcon build to ensure that yarp_control_msgs is built as well? @randaz81 @elandini84

traversaro commented 9 months ago

Can you try (in a clean environment) with the commands modified as in https://github.com/robotology/yarp-devices-ros2/pull/64 ? Or otherwise, you could try with the "Build with pure CMake commands" instruction.

PeterBowman commented 2 weeks ago

It worked for me when following the "Build with ROS msgs compiled in separate colcon workspace" section:

https://github.com/robotology/yarp-devices-ros2/blob/02e3835b894fd4aa96eece49a44f1d817a5ae309/README.md#L33-L46

Unless I'm missing something, the install dirs of YARP plugins and ROS packages should never be mixed, which was happening in the first procedure. In that case, either ROS packages would be installed to /usr/local (not aligned with the usual practice), or YARP plugins would be copied to the directory pointed at by -DCMAKE_INSTALL_PREFIX (then, some env var magic would be needed to make sure that YARP finds them).

In contrast, it feels more natural to build the ROS packages first in their own workspace, source that workspace, and then build the YARP plugins using the "system" dependencies as detailed in the above instructions. Should this be the preferred (or even only) approach?

traversaro commented 2 weeks ago

Unless I'm missing something, the install dirs of YARP plugins and ROS packages should never be mixed, which was happening in the first procedure.

I guess it is a matter of taste/habit, but what is the problem in installing YARP plugins and ROS packages in the same install prefix?

In that case, either ROS packages would be installed to /usr/local (not aligned with the usual practice),

I think this depends on where do you set CMAKE_INSTALL_PREFIX . I typically highly discourage users to use /usr/local, unless they are in a Docker container, as it is highly probably that they lose track of what they installed in /usr/local and they do not know how to uninstall it.

or YARP plugins would be copied to the directory pointed at by -DCMAKE_INSTALL_PREFIX (then, some env var magic would be needed to make sure that YARP finds them).

Isn't this the case for any repo installing YARP plugins? Either you install it in the same installation prefix of YARP and you do not set YARP_DATA_DIRS, or you need to add ${CMAKE_INSTALL_PREFIX}/share/yarp to YARP_DATA_DIRS.

traversaro commented 2 weeks ago

In contrast, it feels more natural to build the ROS packages first in their own workspace, source that workspace, and then build the YARP plugins using the "system" dependencies as detailed in the above instructions. Should this be the preferred (or even only) approach?

I think this really depends on the background of the user. For example, to me it feel really strange (and more complicated/error prone) to use two different ways to build C++ projects, manually if they do not use ROS, and via colcon if they use ROS. If you want to use colcon, why do not build also the main root project of this repo (i.e. yarp-devices-ros2) via colcon as well?

Having said that, I think it is quite common for ROS 2 users to consider project that use ROS 2 as kind of "special" CMake projects that must be build with colcon and not just regular CMake projects (that is kind of recurring theme in ROS Discourse, see https://discourse.ros.org/t/ros2-build-tools-systems/35173 or https://discourse.ros.org/t/migrating-ros-ros2-off-of-catkin-colcon-towards-pure-cmake/12104 and these are just the first discussion I found), so any suggestion on how the documentation can be improved would be really welcome!

PeterBowman commented 2 weeks ago

Those are very good points, @traversaro. I admit being used to shoving everything into the default /usr/local path for the sake of avoiding further tweaks, and then being very careful with any upgrades/overwrites (the YCM's uninstall target is a must, and one has to keep in mind any leftovers as you pointed out). It's been a time since I last worked with YARP_DATA_DIRS, which happens to be the only env var needed for this project, but others might also require setting PATH and LD_LIBRARY_PATH, for instance.

I think the changes you have just submitted in https://github.com/robotology/yarp-devices-ros2/pull/71 express the intent more clearly, thanks!