CSCI 4310 Lecture 8: Path Planning

Book Buckland Ch. 8

Navigation How to represent the areas that an agent can occupy in the world. Navigation Graph (NavGraph) Some More Sophisticated Methods

Nav Graph Works in 2 or 3 dimensions Trade-off Coarsely granulated Easier to manage Less space / time Finely granulated Can become unwieldy Necessary? Think of Grand Theft Auto style worlds But, allows a more realistic ‘feel’

Finely granulated Prevents some backtracking Smoother paths

Path smoothing Required with inverse proportion to granularity of the nav graph With a course graph, we may go backwards to find the nearest “source” node This looks unrealistic

Path smoothing Dijkstra or A* returns A-B-C because there is no A-C link in the underlying Nav Graph Our agent is not precisely constrained by the Nav Graph, So… if A-C is feasible (we don’t hit any obstacles) take it A B C

Path smoothing Raven_PathPlanner::SmoothPathEdges Can check adjacent edges (quicker) Or all edge combinations (slower but more precise) bool Raven_Bot::canWalkBetween (Vector2D from, Vector2D to) A B C

Nav Graph Can select a data structure that allows additional information at nodes or edges “Cost” of traversing the edge, to bias A* or Dijkstra Crossing water is more expensive, so choose a slightly longer path that avoids water Books refers to this as annotation Can also use information to determine state of player (swimming, running, etc.)

Spatial Partitioning Often need to know… Which node is closest to me Which node is closest to my destination Which health pack is closest to me Etc. Track each entity or track each location Spatial partition tracks entities at each location

Raven Path Planning Details Raven_PathPlanner class 1. Find the closest node to the bot’s current location 2. Find the closest node to the desired location (or item) 3. Use a search algorithm to find the least cost path between the two. * notice we did not say shortest

Dijkstra vs. A* If we have a good heuristic, A* works well When plotting a path from source to destination, we usually have a good distance estimate If no heuristic, can save some overhead with Dijkstra Such as when searching for the nearest power-up. We may not know where it is

Raven Details Request a path // Given an item type, this method determines the closest reachable graph node // to the bot's position and then creates a instance of the time-sliced // Dijkstra's algorithm, which it registers with the search manager bool RequestPathToItem(unsigned int ItemType); // Given a target, this method first determines if nodes can be reached from // the bot's current position and the target position. If either end point // is unreachable the method returns false. // // If nodes are reachable from both positions then an instance of the time- // sliced A* search is created and registered with the search manager. the // method then returns true. bool RequestPathToPosition(Vector2D TargetPos);

Implementation A* is exponential in worst case And requires significant storage Depends on heuristic used

Implementation Book has several search speed-ups Given fixed cycles for path planning per game loop iteration 1. Pre-Calculated Paths 2. Time-Sliced Search 3. Hierarchical Search

Pre-Calculated Paths Dynamic programming ABCDE ABB BCC C D E A path from B To D should First Go To Node C Need to store Both sides if We are using A directed Nav Graph (A to B may Be different than B to A)

Pre-Calculated Paths in Raven Methods to call to build tables CreateAllPairsTable(const graph_type& G) Returns a 2-D Vector of ints Can also have pre-calculated costs Useful in goal evaluation in Chapter 9 Pre-calculated paths time space tradeoff

Time-Sliced Path Planning Modify search algorithm to allow a single iteration Call as many iterations as time allows Can incrementally request search paths to reduce burden on CPU

Hierarchical Path Planning High level course nav graph Plot general path Move to more detailed nav graph Good for large environments

Deformable Terrain Dynamically changing Nav Graph Destroying A Bridge Knocking Down a Wall

Deformable Terrain Requires a modifiable Nav Graph Fully deformable terrain has not come about yet because No pre-calculated paths can be generated (or they can, but many more are required and must be tied to state of the world) Increases in time for path request

Deformable Terrain Tony Stentz of Carnegie Mellon D* or Dynamic A* algorithm Useful under dynamic terrain

Navigating Problems Determine when you are blocked No forward progress Or Elapsed Time > (Destination.cost / Bot.maxSpeed) + Margin of Error