msg: urtps: change the topic Data Type name to match expected on ROS2

[TSC21]

Describe problem solved by this pull request
This change allows that our micro-RTPS agent communicates with ROS 2 Dashing (Eloquent not tested yet).

Describe your solution
Most of the problem was presented and followed in eProsima/Fast-DDS#829. The issue is that the topic data type name that is generated by fastrtpsgen, set in the <msg_name>PubSubTypes.cpp files, doesn't match the expected type name of the ROS 2 participant topics. So the solution taken was to directly "reset" the type naming on both Publisher and Subscriber source code.

Thumbs up for @ldg810 for finding and pointing https://answers.ros.org/question/319723/use-ros2-fastrtps-with-standalone-fastrtps-programs/ in eProsima/Fast-DDS#829, which allowed me to fix this. Thanks @ldg810!

Describe possible alternatives
If we find a way of adjusting the naming being set here by an argument passed through the generator, this could be used instead of the default scopedname.

@richiware is this possible by any means? I understand that the scope is built based on the directory structure, but rosidl_generate_interfaces() puts the generated IDL's under px4_msgs/msg/, while this wasn't a problem for rosidl_generate_dds_interfaces(), since the generated IDL's where put under px4_msgs/msg/dds_fastrtps, which in return would get you the right scope name.

If the above is not possible, one way I am seeing is to create a temp dir and copy the IDL files for it so to generate the code with the right scope.

Test data / coverage
Tested with px4_ros_com and SITL with UDP.

FYI @thomasgubler @jkflying.

[jkflying]

Awesome. Is there some way to get this into a simple unit test or something, just to make sure it doesn't get broken now that we have a working state?

[TSC21]

Awesome. Is there some way to get this into a simple unit test or something, just to make sure it doesn't get broken now that we have a working state?

Yes they are under the px4_ros_com CI (just need to reactivate it again).

[TSC21]

@jkflying this solution for now is acceptable. I was trying to play with moving build paths in px4_msgs so to understand if generates the IDL files in a different path, but with no luck. What I am considering as a definite solution is to have PX4 Firmware generate its IDL files, as it already does, and deploy them to px4_msgs every time these get updated. Then, we can use rosidl_generate_interfaces() to generate the interfaces from the IDL files, instead of from the msg files (or not, optional), but we would have the IDL files generated from outr tools and available to be used directly by fastrtpsgen when generating the code for the agent on px4_ros_com.

[hamishwillee]

@TSC21 What's the plan to update our docs (and setup scripts) for Dashing support? Also for FastRTPS, since as you know the current docs are a bit out of date.

[TSC21]

@TSC21 What's the plan to update our docs (and setup scripts) for Dashing support? Also for FastRTPS, since as you know the current docs are a bit out of date.

It's on my TODO. I need to update the CI first and the docs are on my priority.