I’ve installed a micrortps agent on a Linux host communicating with a PX4 SITL running in a docker. I’ve ROS2 foxy installed on my machine (Ubuntu 20.04). Ideally, my ROS2 applications interact directly with the agent. However, it seems that the rtps_agent is a pure RTPS application, i.e. when interacting with ROS2 we need to take into account the prefixing of ROS2 (see Topic and Service name mapping to DDS). When I used the “rt” (ros-topic) namespace when running the agent, “ros2 topic list” contains the topics published by the agent, but a ROS2 subscriber in a test application does not receive messages from the agent.
In addition, I have a strange issue: when the agent is running, the command line tool “ros2 topic list” stops with a bad_alloc exception [1]. The same happens in case of the vehicle_gps_position_listener example from px4_ros_com. The problem seems to be that the ros2 daemon stops. A workaround seems to run another ROS application in parallel.
Any hints?
[1] $ ros2 topic list
terminate called after throwing an instance of ‘std::bad_alloc’
what(): std::bad_alloc
Aborted (core dumped)
The instructions on how to use the px4_ros_com microRTPS agent are provided in ROS 2 User Guide (PX4-ROS 2 Bridge) | PX4 User Guide. Although the micrortps_agent is not a ROS2 node, the code generated for in in px4_ros_com is typesupport and topic-naming compatible with ROS2. So yes, any ROS2 node can subscribe and publish from and to, respectively, the micrortps_agent application.
About the second problem, I never saw this happening before. Did you follow the documentation and have setup the environment according to the provided guidance?
Apparently, the option “-r foxy” needs to be passed to the bridge generator, but this is not the case by default when invoking “make px4_sitl_rtps”.
It is confusing (at least for me) that both PX4_Autopilot and px4_ros_com contain an RTPS bridge generator.
How do you build automatically with foxy support? (via make px4_sitl_xxx or some environment variables to set before make?). I can manually invoke the generator with foxy support, but then make fails, as Timesync_Publisher.h is not found (this file is only in px4_ros_com)
the build script “./build_ros2_workspace.bash” in px4_ros_com fails with an exception OSPL_HOME undefined (I thought, this was not critical, as I used the bridge in the PX4_Autopilot directory). Do I need to install Opensplice (in addition to eprosima) DDS?
PX4 finally works with my ROS2 application, using the micrortps_agent from the px4_ros_com package. I overlooked one detail:
px4_msgs and px4_ros_com were in the folder ~/git/px4 and not in ~/git/px4/src
When I invoked the “build_ros2_workspace.bash” script, it tried to build other packages in my ~/git folder - which contained (in addition to lots of others) an opensplice repository and failed.
=> while this was clearly my fault, it would be great if the script is more robust and detects a wrong relative location.
It would also be good if the documentation clarifies that two variants of the agent exist, one for pure RTPS and one for ROS2 (and only the one in px4_ros_com should be used in case or ROS2)
Where is it not clear in the documentation that the two variants exist? We also have two separate pages on he docs, each one focusing on each variation, to avoid that same confusion. But if you believe that is still not clear enough, please feel free to create a PR to the docs. Improvements are always welcomed.
Sorry for the late reply. I’ve seen that there are two pages. The ROS bridge pages links to the RTPS page:
The application pipeline for ROS 2 is very straightforward, thanks to the native communications middleware (DDS/RTPS). The microRTPS Bridge consists of a client running on PX4 and an agent running on the ROS computer, …
This made me think that for communication with ROS2 I basically use the RTPS bridge - despite the warning later on this page that you cannot use the same agent due to different IDL files (I was aware of the different IDL naming conventions, but not for instance of ROS2 prefixes for topics). So, while it’s mainly my fault, an earlier note that the agent part of the bridge differs in case of ROS2 would have helped me.
