You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 a moveit::core namespace for the Joint/LinkModel, RobotModel and RobotState classes, but a planning_scene namespace for the PlanningScene (which is arguably as much core as the prior classes).
The PlanningSceneMonitor (the core structure to maintain a scene) is in planning_scene_monitor, together with CurrentStateMonitor, LockedPlanningSceneRO/RW and the TrajectoryMonitor. I would argue that moveit::monitor:: might be a better term here (and whether LockedPlanningScene* should even exist is a different matter).
These are just some examples, the following grep gives a rather good insight into the current mess:
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 a
moveit::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:
The text was updated successfully, but these errors were encountered: