Closed sea-bass closed 1 year ago
Basically, if in the YAML file you add a robot with an a_star
path planner that doesn't have an occupancy grid, there is an error message. I don't think this path was ever tested and doesn't seem to work.
When instantiating this, there should be a WorldGraph
object generated just from the nodes in the rooms/locations, where nodes are connected if there are (polygon-based) collision free paths between them. Basically, this should be the equivalent to the old create_search_graph()
function that was removed.
Before the refactor, this was added automatically as you added/removed world entities because the World
object had its internal graph structure that corresponded to the "global planner".
I could add a new WorldGraphplanner
(name subject to change)
That builds a graph from the world entities and plans on it ,
So instead of putting "astar" in the config we can specify this new planner.
Ideally the name should be something that implies it works on a static graph of the world.
Maybe StaticRoadmapPlanner
? (SrmPlanner)
WorldGraphPlanner, or VisibilityGraphPlanner, should be good!
If that's the case, then AStarGraph should be removed and there should be an error when no occupancy grid is passed into the AStar planner?
The AStarGraph
is internally used in PRM.
Things are bit weird with the graph A* since we are using the astar
package from pip and it does not really need a graph object or any other planner arguments, just the start and goal.
My ideal implementation would have a graph passed to the planner (similar to the grid) and would plan on the graph.
Not sure if the astar
package can be made to work like that.
@sea-bass
Gave this some more thought.
I think the best way to solve this would be to add a graph attribute back to the World
class and build it similar to how it was done earlier.
And then for planning, the robot position would be added to the World.graph
before search and removed after the search .
Since the Graph A* implementation only needs the start
and goal
nodes.
Similar to how it is done in the current PRM implementation
That sounds right to me -- thanks!
However, I think the behavior of the current A is not very intuitive.
The A graph implementation should take in and depend on a Graph
object and the neighbors should be found using the Graph
object rather than the Node
themselves.
eg :
Graph.get_neighbors(node)
instead of
node.get_neighbors()
This change can be done, but our Graph
implementation also needs to be modified to support this.
Should probably be the topic of separate future PR.
I just noticed this, but https://github.com/sea-bass/pyrobosim/pull/82 actually removed some old functionality in
pyrobosim
that is no longer available.This has to do with having a fully-connected roadmap graph with just the nodes included in the rooms / locations and directly doing A* search along this roadmap:
@ibrahiminfinite Could you confirm this is the case? Do you think you'd be able to restore this functionality by adding another planner that uses this directly? Right now, we only have A*