Closed SergeyFabric closed 5 days ago
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/
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
Regards, Rob
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'
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?
@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: https://github.com/ros/meta-ros/blob/b7a64c811de122a3b11aa59b2103008329853d77/meta-ros1/classes/ros1_distro.bbclass#L6 Adding the same inherit line to meta-ros2/classes/ros2_distro.bbclass should produce the same effect.
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:
Agree, we can leverage ros_opt_prefix.bbclass. But it cannot work properly with simply inherit ros_opt_prefix.bbclass.
Tnx @jiaxshi what do you suggest to do in my case? @jiaxshi can I use your branch to test it also in my machine?
Hi @SergeyFabric I'll submit PR in some days. Then you can have a try.
@SergeyFabric You can try with https://github.com/ros/meta-ros/pull/1149.
The opt_ros_prefix changes have been merged into the -next branches. Closing as completed.
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 ?