Skip to content
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

Open
SergeyFabric opened this issue Dec 6, 2023 · 9 comments
Open

No /opt/ros/${ROS_DISTRO} directory. #1079

SergeyFabric opened this issue Dec 6, 2023 · 9 comments

Comments

@SergeyFabric
Copy link

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 ?

@robwoolley
Copy link
Collaborator

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,
Rob

@SergeyFabric
Copy link
Author

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:
Development Environment: A Docker container with full ROS2 Humble built with docker buildx to support arm32v7 architecture for compilation.
Target Robot: An (STM32MP153) arm32v7-based robot running ROS2 Humble, installed via Yocto and meta-ros branch kirkstone-next.

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
raise UnsupportedTypeSupport(pkg_name)
rosidl_generator_py.import_type_support_impl.UnsupportedTypeSupport: Could not import 'rosidl_typesupport_c' for package 'my_interfaces'

@jiaxshi
Copy link
Contributor

jiaxshi commented Apr 22, 2024

Hi @robwoolley
I have implemented mechanism of installing ROS 2 binaries to /opt/ros/xxx. And I'm going to raise a PR for this feature. Do you have any comments for this?

@robwoolley
Copy link
Collaborator

robwoolley commented Apr 22, 2024

@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:

inherit ros_opt_prefix
Adding the same inherit line to meta-ros2/classes/ros2_distro.bbclass should produce the same effect.

@johannesschrimpf
Copy link
Contributor

johannesschrimpf commented Apr 22, 2024

Would it be possible to rather add a variable, so that the default behavior can be changed, for example a ROS_PREFIX ?= /opt/ros/... ?

Edit:
It seems that can be done anyways:

ros_prefix ?= "${base_prefix}/opt/ros/${ROS_DISTRO}"

@jiaxshi
Copy link
Contributor

jiaxshi commented Apr 23, 2024

Agree, we can leverage ros_opt_prefix.bbclass. But it cannot work properly with simply inherit ros_opt_prefix.bbclass.

@SergeyFabric
Copy link
Author

Tnx @jiaxshi what do you suggest to do in my case? @jiaxshi can I use your branch to test it also in my machine?

@jiaxshi
Copy link
Contributor

jiaxshi commented May 10, 2024

Hi @SergeyFabric I'll submit PR in some days. Then you can have a try.

@jiaxshi
Copy link
Contributor

jiaxshi commented May 20, 2024

@SergeyFabric You can try with #1149.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants