ros2 / rviz

ROS 3D Robot Visualizer
BSD 3-Clause Clear License
293 stars 211 forks source link

rviz2 via composition #1114

Open mhubii opened 8 months ago

mhubii commented 8 months ago

From the CMake it appears rviz2 is compiled into an executable, refer

https://github.com/ros2/rviz/blob/68d9167758b651d2e4c01f4aeb74a9613110e751/rviz2/CMakeLists.txt#L44

Are there plans to provide composition in the future?

roncapat commented 8 months ago

Subscribing here. As soon as I get some free time I may give a look to evaluate the required effort to do so, but I would also like to know from the maintainers their opinion on such a possible development.

clalancette commented 8 months ago

I'm not opposed to it, but I'd like to hear what the use case is. I mean, yes, it will be more efficient to compose it with the thing it is debugging. But the "typical" deployment is to have rviz2 on a separate machine from the robot, so I'd want to hear about the cases where that is not happening.

mhubii commented 8 months ago

was just thinking that this could enable intra-process communication to rviz, although inter-process works just fine.

The rclcpp_components_register_node cmake macro https://github.com/ros2/rclcpp/blob/5d2b32b5c3e5bbf538807779a7151ac1363002d2/rclcpp_components/cmake/rclcpp_components_register_node.cmake#L25C4-L25C4 lets users compile into a component and (I think) also compiles an executable.

roncapat commented 8 months ago

@mhubii I think @clalancette is asking for a real use cases. I can propose a few to start with:

Of course, I think these are not beginner setups, but may come handy.

clalancette commented 8 months ago

OK, fair enough. I've put this on the backlog, since the core team likely won't be addressing it in the near future. But please feel free to open pull requests in that direction. Thanks!

roncapat commented 8 months ago

Here is a little assessment of what's currently going on, and how the above objective coud be achieved.

As I was expecting, here we have a Qt Application along with its own startup logic. The actual rclcpp::Node is created as an object by the application.

https://github.com/ros2/rviz/blob/68d9167758b651d2e4c01f4aeb74a9613110e751/rviz_common/include/rviz_common/ros_integration/ros_node_abstraction.hpp#L55-L64

https://github.com/ros2/rviz/blob/68d9167758b651d2e4c01f4aeb74a9613110e751/rviz_common/src/rviz_common/ros_integration/ros_node_abstraction.cpp#L46-L48

This is almost the same pattern used for example by gazebo_ros_pkgs and makes just sense. It would be too complicated to transform Rviz in an rclcpp_component with a Qt GUI. What it can become, instead, is a Qt GUI with a component_container.

Let me exaplain this. Rviz could:

Then, users could call the component manager services to do run-time composition (i.e. inject components in the Rviz instance).

I did the same locally with gazebo_ros_pkgs some time ago to circumvent point_cloud transform limitation. Useless to say, it worked very well (much faster fps).

ahcorde commented 7 months ago

Hi @roncapat,

Can you provide any pointer to your changes in gazebo_ros_pkgs ?

roncapat commented 7 months ago

Here you are @ahcorde: https://github.com/Fixit-Davide/gazebo_ros_pkgs/commit/a51a193806c3f144cba66954612f078ba1e0958b https://github.com/Fixit-Davide/gazebo_ros_pkgs/commit/b93a2f3a1738104b90388ef216a7b376066ccc5b CC: @Fixit-davide

Edit: it is unmaintained and commits may be cleaner overall, but it may serve as a starting point POC.

ahcorde commented 7 months ago

I created a draft PR https://github.com/ros2/rviz/pull/1140