Closed evan-palmer closed 4 months ago
I am not fully sold on migrating to ros2_control
yet as that project is still working on maturing (at the time of writing, it is a massive pain in the butt to integrate ros2_control with Gazebo Garden). I'm also not sure whether the lifecycle node structure will apply super well when integrating with the manager or ArduSub. These are some things that will need to be considered when refactoring the architecture.
I've just made a new repo to work on this here. Right now, I just envision that repo being a collection of controllers for AUVs/ROVs. Then each user can implement their own hardware interfaces (like ros2_control does)
Feature Type
Changing existing functionality in the BlueROV2 driver
Problem Description
The current implementation for developing and using custom controllers is custom, but still implements a structure similar to what one would expect within ros2_control. The main reason for the initial design is ultimately that I'm on a time crunch and didn't have the time to fidget with setting up the hardware interfaces and custom controllers.
Feature Description
Migrate the existing controller implementation over to ros2_control. This will improve the maintainability of the implementation and will also improve the integration of the project into the ROS ecosystem down the line (e.g., integrating MoveIt2).
Alternative Solutions
The existing approach could be preserved; however, I think that, if possible, it would ultimately be better to switch over to ros2_control.
Additional Context
No response