Module Active Robots

This is an artifact of developing robot groups. It should be replaced by using a proper subgroup where each robot within is active.

Member BasicRRTStrategy< MPTraits >::SelectDispersedTarget (const VID _v)

This functionality can probably be moved into a dispersed extender, which we could call several times here.

Member BulletEngine::AddRobot (Robot *const _robot)

We need a way to set initial velocities for the robot.

Class BulletModel

This model can currently only support robots with revolute joints. Nonactuated and spherical joints don't work right. One problem is that bullet indexes the number of joints while pmpl uses the number of dof, so some of our joint loops don't line up. Another is that bullet only supports 3-dof spherical joints with no way to constrain them.

Class CCTracker< RoadmapType >

Add support for non-tree directed graphs. We need to use predecessor information to do this, which we now have in the roadmap graph.

The stat class tracking adds a lot of complication. Remove it once we're sure the performance is fast enough to forgo tracking.

Class CDInfo

Generalize this object to store collisions with obstacles, boundaries, and other robots in a uniform way. It should contain a vector of 'Collision' structures which describe the object type, indexes, and distance for each detected collision.

Member Cfg::operator< (const Cfg &_cfg) const

The function currently seems to check each dof in order, returning T/F immediately unless exactly equal; is this intended?

Class CollisionDetectionValidity< MPTraits >

Remove the 'GetCDMethod' function after re-implementing ObstacleClearanceValidity as a subtype of CollisionDetectionValidity.

Member DistanceMetricMethod< MPTraits >::EdgeWeight (const RoadmapType *const _r, const typename RoadmapType::CEI &_edge) noexcept

We need to make this work for group roadmaps. Probably it needs to take the roadmap as a templated parameter and not be virtual (there is really only one way to do this).

Module DOF Accessors

These should not return any single-robot values, which can always be obtained by accessing the relevant robot.

Class ExtenderMethod< MPTraits >

Local planners and Extenders represent the same concepts and should be merged into a single class with both an Extend and LocalPlan function. This will help simplify several other objects within PMPL as well, such as bi-directional RRT.

Member GMSPolyhedron::COMAdjust

This has been a major source of bugs for a long time and should be removed entirely. All polyhedrons should be bounding-box centered without exception.

Class GridOverlay

Generalize to support 2d grids as well as 3d.

Class GroupCfg

Rework so that we only need a robot group to construct this, in which case it will have all local cfgs. It should only get tied to a roadmap with SetGroupRoadmap after it has been added to one.

Member GroupCfg::GroupCfg (GroupRoadmapType *const _groupMap=nullptr, const bool _init=false)

This object does not work at all without a group map. We should throw relevant exceptions if needed.

Member GroupCfg::SetGroupRoadmap (GroupRoadmapType *const _newRoadmap) const

Fix this, it looks like it was meant to be a copy-constructor with a different roadmap. We will still need a roadmap setter in case the roadmap moves.

Class GroupLocalPlan< CfgType >

Remove the 'active robots'. All robots are always active in a group edge. We do need to retain formation data for reconstructing edges.

Remove the 'skip edge' stuff. There is no such thing as a skipped edge: the disassembly code needs to be adjusted to only use the edges they want.

Rework so that we only need a robot group to construct this, in which case it will have all local edges. It should only get tied to a roadmap with SetGroupRoadmap after it has been added to one.

Class GroupLPOutput< MPTraits >

Destroy this object and have LPs/Extenders work directly with a GroupLocalPlan.

Class GroupStrategyMethod< MPTraits >

Incorporate path constraints when generating the start and goal.

Class GroupTask

Move disassembly-specific items to a derived class specifically for disassembly tasks.

Member GroupTask::GetStartConstraintCenter (GroupCfg &_center) const noexcept

This is a hack that was needed to move the disassembly work forward before we had flushed out the tasks/groups. To be removed at the earliest opportunity.

Module Internal State

Remove m_k and m_radius - these don't apply to all NFs so it doesn't make sense to have them here. Fix design errors in SRT method which require this.

Module Internal State

Figure out how to represent this.

Module Internal State

We need a dynamically sizable matrix for this, either dlib or eigen will probably be the choice.

Class LocalPlannerMethod< MPTraits >

All local planners need to use a distance metric to set their edge weights properly; currently many of them are simply using the number of intermediate steps as a weight.

Local planners and Extenders represent the same concepts and should be merged into a single class with both an Extend and LocalPlan function. This will help simplify several other objects within PMPL as well, such as bi-directional RRT.

Class LPOutput< MPTraits >

Destroy this object and have LPs/Extenders work directly with a LocalPlan object, which should replace the DefaultWeight class as our roadmap edge.

Member MapEvaluatorMethod< MPTraits >::m_activeRobots

This is an artifact of developing robot groups. It should be replaced by using a proper subgroup where each robot within is active.

Class MinkowskiDistance< MPTraits >

Remove m_r2, which isn't part of the Minkowski difference and doesn't have any valid use.

Move the normalization option up to the base class.

Separate the computation of orientation and joint distances.

Class MPSolutionType< MPTraits >

Currently this object can represent a solution for each single robot and several robot group. It can almost support multiple of each - it just needs an interface for adding more robots/groups to the container.

Class MPStrategyMethod< MPTraits >

Incorporate path constraints when generating the start and goal.

Class MPTask

We should remove the capability here and redefine it as a constraint (since the constraints should fully define the task). The fact that a capability is or is not required should generally be discerned from the problem, while a capability constraint would more likely represent a deliberate restriction that is not strictly required (perhaps to express an operational preference). We will also eventually encounter cases where multiple capabilities are required to satsify a task.

Support the use of path constraints in the library code, which currently doesn't care about this.

Class QueryMethod< MPTraits >

Implement A* by accepting a distance metric label for the heuristic function, and expanding the SSSP functions to accept a binary functor heuristic function.

Class Rapid

There is no reason we can't support IsInsideObstacle with RAPID. This isn't really a part of PQP either - it's auxilliary code we created with a ray-shooting test. We can do the same thing here with an added 'RapidSolid' class, or by toggling the IsInsideObstacle check with a flag both here and in PQP.

Module Rendering Options

Apply these only to the selected roadmap.

Class Robot

Come up with a nice way to support both real and emulated hardware.

Class SamplerMethod< MPTraits >

The present implementation of Sample temporarily saves invalid configurations whether we will use them or not. Avoiding this extraneous retention will likely have good performance benefits in sampling-intensive applications such as proteins and manipulators where the success rate is very low.

The present layout of this class is confusing since the base method is actually generating uniform random samples which are filtered by the derived class. This does not work for many derived classes as evidenced by their overriding of Sample rather than Sampler: we should rework the design so that derived classes generate and filter their own samples. The base class can then implement its functions in terms of the generate and filter helpers.

Member SensorInterface::GetUncertainty ()=0

This should maybe be a covariance matrix instead of an uncertainty in each measured dimension.

Class std::hash< std::pair< T, U > >

Double-check that we get similar performance with differing types.

Class TogglePRMStrategy< MPTraits >

This can probably derive from BasicPRM to reduce duplication of common code.

Class TRPGoalMap< MPTraits >

What is this?

Class TRPTool< MPTraits >

insert paper name and authors