-
Notifications
You must be signed in to change notification settings - Fork 251
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No /opt/ros/${ROS_DISTRO} directory. #1079
Comments
Hi @SergeyFabric, Thanks for reporting this issue. The previous maintainers chose to merge the ROS2 libraries and executables into the filesystem to conform list the Filesystem Hierarchy Standard. They documented this on the wiki (https://github.com/ros/meta-ros/wiki/Superflore-OE-Recipe-Generation-Scheme) as "Layer version 1 installs packages built with catkin under /opt/ros/<ROS_DISTRO>. Continue this in layer version 2 for melodic even though they're installed under /usr for ROS 2 distros until a decision is made as to which prefix will be used for both ROS versions." What errors do you see regarding not finding rosidl_typesupport_c? I assume it it complaining when you try to launch the executable. Can you provide the command you are using? (eg. ros2 topic echo ) What output to do see if you run the "ldd" command on the executable that fails? (eg. ldd ros2) Regards, |
Thanks @robwoolley for the replay its a great answer!!! The error is that C++ node that reads UART and publishes custom messages is running fine but ros2 topic echo with this topic crushes. because of that, I thought the problem was with the meta-ros build but you changed my mind thanks for that. Setup: Workflow: I compile using colcon build in the Docker container. I then transfer the install directory to the robot. On the robot, I execute source install/setup.bash of my build and run the nodes. Issue: A C++ node works perfectly. However, I encounter errors with Python nodes or ROS2 commands (e.g., ros2 topic echo /topic_name). These nodes utilize custom ROS messages. Error Message: File "/usr/lib/python3.10/site-packages/rosidl_generator_py/import_type_support_impl.py", line 48, in import_type_support |
Hi @robwoolley |
@jiaxshi I am in support of using /opt/ros/ as it will make it consistent with the other platforms and allow people to follow the same steps found in documentation and tutorials. It seems that switching to /opt was part of the plan described in "Phase 4" here: https://github.com/ros/meta-ros/wiki/Superflore-OE-Recipe-Generation-Scheme#phase-4 My only comment is that I noticed that there is a bbclass that did this for the ROS 1 distros: https://github.com/ros/meta-ros/blob/master/meta-ros-common/classes/ros_opt_prefix.bbclass For ROS 1, this is done by inheriting the class here:
|
Would it be possible to rather add a variable, so that the default behavior can be changed, for example a Edit:
|
Agree, we can leverage ros_opt_prefix.bbclass. But it cannot work properly with simply inherit ros_opt_prefix.bbclass. |
Hi @SergeyFabric I'll submit PR in some days. Then you can have a try. |
@SergeyFabric You can try with #1149. |
Description:
I have successfully added ROS2 Humble distribution to my custom Yocto-based STM32mp1 project. The integration process went smoothly, and I was able to run example code with pub-sub nodes effectively. However, I've noticed that the ROS2 code is distributed across various directories, with some components residing in /usr/share/ and /usr/lib/. The environment variable $AMENT_PREFIX_PATH only points to /usr.
this what i added to my image :
inherit ros2_image
inherit ros_distro_humble
IMAGE_INSTALL:append = "
ros-base
ros-core
"
Environment:
Operating System: openstlinux
ROS Distribution: Humble
Yocto Project Version: Kirkstone
the problem occurs when I transfer my cross-compiled code to this yocto base device.it seems not to find the rosidl_typesupport_c when I subscribe to the topic and I think it is because the path to the libraries that meta-ros built is pointing to /usr.
Or I missing something else ?
The text was updated successfully, but these errors were encountered: