noether
noether copied to clipboard
Making a ROS-agnostic repo?
I'm sure there's been some internal discussion on these lines but rather than ping you all privately I thought why not open a thread for public discussion. What is everyone's thoughts on turning this into pure CMake packages for use in ROS1 and ROS2 systems? What would the roadmap for that effort look like and what concrete work would need to be done?
@Levi-Armstrong @jrgnicho @marip8 @mpowelson @DavidMerzJr @marrts would be interested to hear your thoughts. Thanks!
I am onboard with this. We have already converted some the packages to be ROS-agnostic.
The initial steps towards this would be porting the core functionality. vtk_viewer & noether_filtering are both ROS independent. The other packages that we will need to remove ROS dependencies from will be tool_path_planner, path_sequence_planner, and mesh_segmenter. Pending further discussions, the ros dependent packages noether, noether_examples, noether_msgs, and noether_conversions may be blacklisted/ignored in a ROS agnostic environment.
To remove the ros dependency in tool_path_planner, the input types of meshes will need to change from shape_msgs::mesh. This input type is currently being cast to a PCL polygon mesh immediately, so expecting a PCL type should not be a significant change within the library.
To remove the ros dependency in tool_path_planner, the input types of meshes will need to change from shape_msgs::mesh. This input type is currently being cast to a PCL polygon mesh immediately, so expecting a PCL type should not be a significant change within the library.
Since it already has a dependency on PCL, I see no issues with switching to PCL type versus a message type.
While we had internally agreed to remove ROS functions from noether_conversions, I realized that all but 1 function contained within are ROS interfaces. The 1 exception is only used in tool_path_planner, so I have moved it into tool_path_planner utilities file. With noether_conversions being ROS dependent, I am moving the to<path_planner> methods there, since they are converting.
Closing; addressed in refactor effort described in #147