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
B
A
C
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

Path smoothing
B




C
A
Raven_PathPlanner::SmoothPathEdges
Can check adjacent edges (quicker)
Or all edge combinations (slower but more
precise)
bool Raven_Bot::canWalkBetween
(Vector2D from, Vector2D to)
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 timesliced 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
Time-Sliced Search
Hierarchical Search
2.
3.
Pre-Calculated Paths

Dynamic programming
A
A
B
C
D
E
B
C
B
B
C
D
C
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)


Can also have pre-calculated costs


Returns a 2-D Vector of ints
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