CSCI 4310Lecture 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 Paths2. Time-Sliced Search3. Hierarchical Search

Pre-Calculated Paths Dynamic programming

A B C D E

A B B

B C C

C

D

E

A path from BTo D shouldFirst Go ToNode C

Need to storeBoth sides ifWe are usingA directed NavGraph

(A to B mayBe different thanB 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

http://www.frc.ri.cmu.edu/~axs/

Navigating Problems Determine when you are blocked

No forward progress

Or

Elapsed Time > (Destination.cost / Bot.maxSpeed) + Margin of Error