Open v4hn opened 2 years ago
phew, now you are opening a can of worms. "Yes" to introducing moveit
as a general namespace. We could definitely do some cleanup here looking at the grepped list. I like the idea of grouping the monitors, but then we could maybe just go with moveit::ros
to indicate that these are ros runtime components. moveit::ros::interface
could then include the client interface parts (somewhat long, though). Likewise, I think it wouldn't be a bad idea to group plugins in moveit::plugins
.
We have quite a lot of namespaces in our code bases. I'm not saying this is bad, but we could definitely rethink some of them and adapt them to make more sense.
The main question is whether we want to have a
moveit
namespace for everything. We do not at the moment, but I would definitely support it. Instead we have amoveit::core
namespace for theJoint/LinkModel
,RobotModel
andRobotState
classes, but aplanning_scene
namespace for thePlanningScene
(which is arguably as much core as the prior classes).The
PlanningSceneMonitor
(the core structure to maintain a scene) is inplanning_scene_monitor
, together withCurrentStateMonitor
,LockedPlanningSceneRO/RW
and theTrajectoryMonitor
. I would argue thatmoveit::monitor::
might be a better term here (and whetherLockedPlanningScene*
should even exist is a different matter).These are just some examples, the following grep gives a rather good insight into the current mess: