Description
Hi,
I recently submitted a pull request (ros-perception/slam_gmapping#41) to the gmapping package to allow it to be run as a nodelet in addition to its current node form. The goal was to be able to run it (which consumes the /scan topic) and a nodelet like depthimage_to_laserscan (which produces the /scan topic) under the same nodelet manager, for reduced data copies and increased processing efficiency.
I began working on the move_base node (which also consumes /scan), trying to implement similar changes, but quickly found that I would need to edit a large number of adjacent classes (e.g., costmap, planner, etc.) to allow topic namespacing and remapping to work correctly.
(Currently the adjacent classes rely on a "~/name" technique for publishing their topics, but when run as a nodelet the "~" namespace resolves to the process of the nodelet manager itself, not the move_base nodelet. I believe I would need to effectively pass the move_base nodelet's private nodehandle to the adjacent classes to use for publication, so the correct namespace and remapping list would be propagated throughout.)
I figured I would check in before making a change that would effect so many classes. I was wondering if anyone has attempted making this change before, or if there is any obvious reason why it shouldn't be done. The navigation stack classes are significantly more complicated, so I don't know if there are threadding issues, for examples, that I have not foreseen that might effet the ability to convert to a nodelet.
If interested, my initial check-in for nodelet conversion of move_base can be found at my fork (https://github.com/kevincwells/navigation/tree/move_base_nodelet); it builds, but is obviously just the initial step.
Cheers,
Kevin