List of breaking changes from ros_control to ros2_control about ros2_control HOT 3 CLOSED

Thanks for starting this. I just wanted to highlight though that I explicitly chose back in 2017 to not straight up migrate ros_control to ros2, but rather have it as a complete re-write from scratch. This gives us the liberty to not only introduce as many API changes as needed, but also to really feature some of the new concepts in ROS2. I also think we should actually come up with a design document in the style of design.ros2.org before really starting to migrate all the missing things from ROS1.

One of these ROS2 features which is already a breaking design change:

• Every controller (inheriting from a ControllerInterface) has a rclcpp_lifecycle::LifecycleNode. That implicitly gives each controller the functionality of a state machine to easily start/stop/reconfigure the controller.

The things I would love to have and hopefully get soon some time to properly write them in a design doc:

• The controller manager could in my opinion be replaced by a ROS2 component manager. There is some read-up here: https://ubuntu.com/blog/components-vs-plugins-in-ros-2. But essentially, the controller manager is really just the host container for controller plugins, which could be loaded as components. This also gives all the command line tools for free: https://index.ros.org/doc/ros2/Tutorials/Composition/
• As a follow-up to the components, one could force each component to leverage the intra-process communication. This could potentially avoid JointStateHandles or JointCommandHandles all together as with the intra process communication, we really, just like the handles, only share message pointers around.
• The controller manager should have a more sophisticated execution management. I am thinking here to provide an API similar to rclcpp which allows to start the controller manager with an executor (which is currently already the case). This executor can then be configured such that all controllers are update()d in a specific order or frequency. This would allow to achieve controller chaining, concatenation and variable frequencies.

from ros2_control.

* As a follow-up to the components, one could force each component to leverage the intra-process communication. This could potentially avoid `JointStateHandles` or `JointCommandHandles` all together as with the intra process communication, we really, just like the handles, only share message pointers around.

yes.

This is what I also had in mind when I wrote ros-controls/roadmap#2 (comment).

from ros2_control.

We have started a migration guide section over at https://github.com/ros-controls/control.ros.org/

from ros2_control.