fix sensor msgs deps

[brandonho667]

Description

Adds service_msgs as a dep of sensor_msgs to make dependency explicit (ensure it builds first and is linked in properly).

Is this user-facing behavior change?

Yes, fixes microxrcedds build.

Did you use Generative AI?

No

Additional Information

I was getting errors for ServiceEventInfo symbol not being linked (building microxrcedds typesupport).

Error: Could not load library libsensor_msgs__rosidl_typesupport_microxrcedds_c.so: 
dlopen error: ~/microros_ws/install/sensor_msgs/lib/libsensor_msgs__rosidl_typesupport_microxrcedds_c.so: undefined symbol: 
rosidl_typesupport_microxrcedds_c__get_message_type_support_handle__service_msgs__msg__ServiceEventInfo, at ./src/shared_library.c

Found that sensor_msgs wasn't linked to libservice_msgs__rosidl_typesupport_microxrcedds_c.so even though it existed.

$ ldd install/sensor_msgs/lib/libsensor_msgs__rosidl_typesupport_microxrcedds_c.so | grep libservice_msgs__rosidl_typesupport
libservice_msgs__rosidl_typesupport_fastrtps_c.so => ~/microros_ws/install/service_msgs/lib/libservice_msgs__rosidl_typesupport_fastrtps_c.so (0x0000726fbf805000) 

$ ls install/service_msgs/lib/ | grep libservice_msgs__rosidl_typesupport 
libservice_msgs__rosidl_typesupport_cpp.so 
libservice_msgs__rosidl_typesupport_c.so 
libservice_msgs__rosidl_typesupport_fastrtps_cpp.so 
libservice_msgs__rosidl_typesupport_fastrtps_c.so 
libservice_msgs__rosidl_typesupport_introspection_cpp.so
libservice_msgs__rosidl_typesupport_introspection_c.so 
libservice_msgs__rosidl_typesupport_microxrcedds_cpp.so 
libservice_msgs__rosidl_typesupport_microxrcedds_c.so

Rebuilt only sensor_msgs in my workspace (while keeping service_msgs) and the link showed up fine. Looks like it was just a build order thing.

[christophebedard]

This seems weird to me. This would mean that all packages defining services need to depend on service_msgs, which isn't currently the case AFAIK. Our own "Creating custom msg and srv files" tutorial doesn't even include it: https://docs.ros.org/en/rolling/Tutorials/Beginner-Client-Libraries/Custom-ROS2-Interfaces.html

Are you only having this problem with sensor_msgs?

[fujitatomoya]

@christophebedard your point makes sense! I may have been too quick to accept the PR's premise...

This could be specifically a micro-XRCE-DDS typesupport issue, not a general ROS 2 issue?
The standard typesupports (fastrtps, cyclonedds) likely handle the transitive dependency chain correctly, but the micro-XRCE-DDS typesupport generator may have a bug in how it resolves dependencies?

Does this issue occur with standard DDS implementations? (FastDDS, CycloneDDS) - If not, this would not be a sensor_msgs bug.

[fujitatomoya]

more information required.

[christophebedard]

This could be specifically a micro-XRCE-DDS typesupport issue, not a general ROS 2 issue?
The standard typesupports (fastrtps, cyclonedds) likely handle the transitive dependency chain correctly, but the micro-XRCE-DDS typesupport generator may have a bug in how it resolves dependencies?

Yeah, service_msgs was created to support service introspection (ros2/rcl_interfaces#143), so maybe rosidl_typesupport_microxrcedds_* hasn't been updated yet?

[asymingt]

Hello @brandonho667 👋

We have specific logic in our cmake modules that automatically appends sensor_msgs or action_msgs as needed for specific interfaces (actions and services). Adding sensor_msgs to a specific package like this is not a scalable solution, because this sets the wrong precedent: we'd need to go back and add it to hundreds of other packages that offer services or actions.

The takeaway is that in a standard ROS 2 cmake workspace this should be handled automatically for you. It seems like this is a Micro-ROS issue when used with micro-XRCE-DDS. I think that you opening up an issue here was the right thing to do.

I'm going to close this issue. If you feel I have done this prematurely, feel free to open it up again.