micro-ROS / micro_ros_setup

Support macros for building micro-ROS-based firmware.
Apache License 2.0
365 stars 133 forks source link

can't echo /microROS/ping , RMW_implementation breaking the build? #703

Closed badmanwillis closed 3 months ago

badmanwillis commented 4 months ago

Issue template

Steps to reproduce the issue

Follow tutorial steps for my First micro-ROS Application on Linux

Install and build, Create & build firmware workspace, create_firmware_ws.sh [RTOS] [Platform], Create & build micro-ros agent.

Run micro-ros agent, node, and attempt to echo the /microROS/ping topic

Expected behavior

Run ping_pong demo, expect to be able to list & echo /microROS/ping topic.

Actual behavior

When running ros2 topic echo /microROS/ping i get the result

WARNING: topic [/microROS/ping] does not appear to be published yet Could not determine the type for the passed topic

Then if i attempt to colcon build the workspace, I get a failure trying to build > rclc

Starting >>> rclc --- stderr: rclc
CMake Error at /opt/ros/iron/share/rmw_implementation_cmake/cmake/get_default_rmw_implementation.cmake:60 (message): Could not find ROS middleware implementation 'rmw_microxrcedds'. Choose one of the following: rmw_fastrtps_cpp Call Stack (most recent call first): /opt/ros/iron/share/rmw_implementation/cmake/rmw_implementation-extras.cmake:19 (get_default_rmw_implementation) /opt/ros/iron/share/rmw_implementation/cmake/rmw_implementationConfig.cmake:41 (include) /opt/ros/iron/share/rcl/cmake/ament_cmake_export_dependencies-extras.cmake:21 (find_package) /opt/ros/iron/share/rcl/cmake/rclConfig.cmake:41 (include) CMakeLists.txt:31 (find_package)


Failed <<< rclc [2.43s, exited with code 1]

If i run through the tutorials again, I get warnings when running ros2 run micro_ros_setup build_firmware.sh (after deleting the firmware folder)

Compiling for host environment: not cleaning path

Building firmware for host platform generic [3.432s] WARNING:colcon.colcon_core.package_selection:Some selected packages are already built in one or more underlay workspaces: 'microcdr' is in: /home/warhorse/microros_ws/install/microcdr 'rosidl_typesupport_microxrcedds_c' is in: /home/warhorse/microros_ws/install/rosidl_typesupport_microxrcedds_c If a package in a merged underlay workspace is overridden and it installs headers, then all packages in the overlay must sort their include directories by workspace order. Failure to do so may result in build failures or undefined behavior at run time. If the overridden package is used by another package in any underlay, then the overriding package in the overlay must be API and ABI compatible or undefined behavior at run time may occur.

If you understand the risks and want to override a package anyways, add the following to the command line: --allow-overriding microcdr rosidl_typesupport_microxrcedds_c

This may be promoted to an error in a future release of colcon-override-check. Starting >>> microcdr Finished <<< microcdr [0.53s]
Starting >>> rosidl_typesupport_microxrcedds_c Finished <<< rosidl_typesupport_microxrcedds_c [2.11s]

Summary: 2 packages finished [5.35s] [2.603s] WARNING:colcon.colcon_core.package_selection:Some selected packages are already built in one or more underlay workspaces: 'rosidl_typesupport_microxrcedds_cpp' is in: /home/warhorse/microros_ws/install/rosidl_typesupport_microxrcedds_cpp 'rosidl_typesupport_microxrcedds_c' is in: /home/warhorse/microros_ws/install/rosidl_typesupport_microxrcedds_c 'microcdr' is in: /home/warhorse/microros_ws/install/microcdr If a package in a merged underlay workspace is overridden and it installs headers, then all packages in the overlay must sort their include directories by workspace order. Failure to do so may result in build failures or undefined behavior at run time. If the overridden package is used by another package in any underlay, then the overriding package in the overlay must be API and ABI compatible or undefined behavior at run time may occur.

If you understand the risks and want to override a package anyways, add the following to the command line: --allow-overriding microcdr rosidl_typesupport_microxrcedds_c rosidl_typesupport_microxrcedds_cpp

This may be promoted to an error in a future release of colcon-override-check. Starting >>> microcdr Finished <<< microcdr [0.49s]
Starting >>> rosidl_typesupport_microxrcedds_c Finished <<< rosidl_typesupport_microxrcedds_c [1.40s]
Starting >>> rosidl_typesupport_microxrcedds_cpp Finished <<< rosidl_typesupport_microxrcedds_cpp [2.13s]

Summary: 3 packages finished [5.92s] [2.639s] WARNING:colcon.colcon_core.package_selection:Some selected packages are already built in one or more underlay workspaces: 'geometry_msgs' is in: /home/warhorse/microros_ws/install/geometry_msgs, /opt/ros/iron 'statistics_msgs' is in: /home/warhorse/microros_ws/install/statistics_msgs, /opt/ros/iron 'unique_identifier_msgs' is in: /home/warhorse/microros_ws/install/unique_identifier_msgs, /opt/ros/iron 'lifecycle_msgs' is in: /home/warhorse/microros_ws/install/lifecycle_msgs, /opt/ros/iron 'sensor_msgs' is in: /home/warhorse/microros_ws/install/sensor_msgs, /opt/ros/iron 'nav_msgs' is in: /home/warhorse/microros_ws/install/nav_msgs, /opt/ros/iron 'service_msgs' is in: /home/warhorse/microros_ws/install/service_msgs, /opt/ros/iron 'diagnostic_msgs' is in: /home/warhorse/microros_ws/install/diagnostic_msgs, /opt/ros/iron 'sensor_msgs_py' is in: /home/warhorse/microros_ws/install/sensor_msgs_py, /opt/ros/iron 'visualization_msgs' is in: /home/warhorse/microros_ws/install/visualization_msgs, /opt/ros/iron 'action_msgs' is in: /home/warhorse/microros_ws/install/action_msgs, /opt/ros/iron 'test_msgs' is in: /home/warhorse/microros_ws/install/test_msgs 'std_msgs' is in: /home/warhorse/microros_ws/install/std_msgs, /opt/ros/iron 'std_srvs' is in: /home/warhorse/microros_ws/install/std_srvs, /opt/ros/iron 'type_description_interfaces' is in: /opt/ros/iron, /home/warhorse/microros_ws/install/type_description_interfaces 'rosgraph_msgs' is in: /home/warhorse/microros_ws/install/rosgraph_msgs, /opt/ros/iron 'rcl_interfaces' is in: /home/warhorse/microros_ws/install/rcl_interfaces, /opt/ros/iron 'composition_interfaces' is in: /home/warhorse/microros_ws/install/composition_interfaces, /opt/ros/iron 'common_interfaces' is in: /home/warhorse/microros_ws/install/common_interfaces, /opt/ros/iron 'example_interfaces' is in: /home/warhorse/microros_ws/install/example_interfaces, /opt/ros/iron 'trajectory_msgs' is in: /home/warhorse/microros_ws/install/trajectory_msgs, /opt/ros/iron 'builtin_interfaces' is in: /home/warhorse/microros_ws/install/builtin_interfaces, /opt/ros/iron

If a package in a merged underlay workspace is overridden and it installs headers, then all packages in the overlay must sort their include directories by workspace order. Failure to do so may result in build failures or undefined behavior at run time. If the overridden package is used by another package in any underlay, then the overriding package in the overlay must be API and ABI compatible or undefined behavior at run time may occur.

If you understand the risks and want to override a package anyways, add the following to the command line: --allow-overriding action_msgs builtin_interfaces common_interfaces composition_interfaces diagnostic_msgs example_interfaces geometry_msgs lifecycle_msgs nav_msgs rcl_interfaces rosgraph_msgs sensor_msgs sensor_msgs_py service_msgs statistics_msgs std_msgs std_srvs test_msgs trajectory_msgs type_description_interfaces unique_identifier_msgs visualization_msgs

I'm not confident in taking the risk to use the --allow-overriding option If let the workspace finish building, and I don't run the export RMW_IMPLEMENTATION=rmw_microxrcedds command, the ping_pong demo still doesn't work (as expected) but the workspace can still be built.

Which implies that the command export RMW_IMPLEMENTATION=rmw_microxrcedds is part of the issue. Would using --allow-overriding microcdr rosidl_typesupport_microxrcedds_c rosidl_typesupport_microxrcedds_cpp be the safe / smart thing to try next?

Additional information

I'm confident that I'm not making basic mistakes; that I'm in the right workspace, sourcing for each new terminal tab etc. Additionally, I'm wondering if this is an issue I can sidestep for running microros on a microcontroller device, as I see no mention of the export RMW... command for the "First micro-ROS Application on FreeRTOS / Zephyr" Tutorials

badmanwillis commented 3 months ago

fixed!

All of the warnings mentioned above are normal, & to be expected; both for building the ROS workspace, and the uROS firmware (create, config, build).

When first learning ROS2, the tutorial Configuring environment asks the user to export a ROS_DOMAIN_ID variable, and suggests adding the export to the bashrc file.

echo "export ROS_DOMAIN_ID=" >> ~/.bashrc

For reasons I sort-of-get but don't fully understand, the domain ID variable clashes with the uROS application. This means the ping_pong App will run, but won't be visible to the ROS system. Commenting or removing the line of code from the bashrc file will remove the problem.

I recommend the Devs amend the tutorial First micro-ROS Application on Linux to include a note on the Domain ID, ideally with an explanation of the issue.

billynugrahas commented 3 months ago

Hey, @badmanwillis. I am also facing the same issues.

I'm unable to echo the /microROS/ping, also I don't see that topic. I am only see these two topic: /parameter_events /rosout

I tried set ROS_DOMAIN_ID and also remove it, seems the problem still occurs.

Do you have any idea?