toward more realistic pathfinding
Download
Skip this Video
Download Presentation
Toward More Realistic Pathfinding

Loading in 2 Seconds...

play fullscreen
1 / 92

Toward More Realistic Pathfinding - PowerPoint PPT Presentation


  • 325 Views
  • Uploaded on

Toward More Realistic Pathfinding. Authored by: Marco Pinter. Path finding. How do people find paths? Local knowledge Go downhill Follow the person in front of you Follow the scent of food Global knowledge Consider all possible paths from start to goal

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Toward More Realistic Pathfinding' - damian


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
toward more realistic pathfinding

Toward More Realistic Pathfinding

Authored by: Marco Pinter

path finding
Path finding
  • How do people find paths?
    • Local knowledge
      • Go downhill
      • Follow the person in front of you
      • Follow the scent of food
    • Global knowledge
      • Consider all possible paths from start to goal
        • Assign a cost to each leg of the path
        • Find path to goal with smallest cost

Continuous

Discrete

algorithms for path finding
Algorithms for path finding
  • Uniformed
    • You don’t have any insight other than what’s immediately before you
  • Informed
    • You have some insight, or heuristics that help you choose where to explore
path finding data structures
Path finding data structures
  • Commonly used data structures
    • Start: where the search must begin
    • Goal: where the search must terminate
    • Fringe: locations in the world that define the boundary of knowledge about the paths from Start to Goal
uniformed search uniform cost search
Uniformed search: Uniform-Cost Search
  • Always expand the lowest-path-cost node
  • Don’t evaluate the node until it is “expanded”… not when it is the result of expansion
uniform cost search
Uniform-Cost Search
  • Fringe = [S0]
  • Expand(S)  {A1, B5, C15}
uniform cost search7
Uniform-Cost Search
  • Fringe = [A1, B5, C15]
  • Expand(A) = {G11}
uniform cost search review
Uniform-Cost Search (review)
  • Fringe = [B5, G11, C15]
  • Expand(B)  {G10}
uniform cost search review9
Uniform-Cost Search (review)
  • Fringe = [G10, C15]
  • Expand(G)  Goal
best first search
Best-first Search

Uniform-cost search explored the node that was the closest

      • With disregard for how far it was from the goal
        • because we didn’t know that information

What if we knew something about the remaining distance to the goal?

      • How could we take this into account?
  • The best node on fringe to explore is one that balances cost to reach and cost to goal
evaluation function f n
Evaluation function: f(n)
  • Combine two costs
    • f(n) = g(n) + h(n)
      • g(n) = cost to get from start to n
      • h(n) = cost to get to from n to goal
heuristics
Heuristics
  • A function, h(n), that estimates cost of cheapest path from node n to the goal
    • h(n) = 0 if n == goal node
a a star search
A* (A-star) Search
  • Don’t simply minimize the cost to intermediate state on fringe… minimize the cost from start to goal…
    • f(n) = g(n) + h(n)
      • g(n) = cost to get to n from start
      • h(n) = cost to get from n to goal
  • Select node from fringe that minimizes f(n)
a is optimal
A* is Optimal?
  • A* can be optimal if h(n) satisfies conditions
    • h(n) never overestimates cost to reach the goal
      • it is eternally optimisic
      • f(n) never overestimates cost of a solution through n
a is optimal15
A* is Optimal
  • We must prove that A* will not return a suboptimal goal or a suboptimal path to a goal
    • Let G be a suboptimal goal node
      • f(G) = g(G) + h(G)
      • h(G) = 0 because G is a goal node
      • f(G) = g(G) > C* (because G is suboptimal)
a is optimal16
A* is Optimal
  • We must prove that A* will not return a suboptimal goal or a suboptimal path to a goal
    • Let G be a suboptimal goal node
      • f(G) = g(G) + h(G)
      • h(G) = 0 because G is a goal node
      • f(G) = g(G) > C* (because G is suboptimal)
  • Let n be a node on the optimal path
    • because h(n) does not overestimate
    • f(n) = g(n) + h(n) <= C*
  • Therefore f(n) <= C* < f(G)
    • node n will be selected before node G
contours
Contours
  • Because f(n) is nondecreasing
  • we can draw contours
    • If we know C*
    • We only need to explore contours less than C*
properties of a
Properties of A*
  • A* expands all nodes with f(n) < C*
  • A* expands some (at least one) of the nodes on the C* contour before finding the goal
  • A* expands no nodes with f(n) > C*
    • these unexpanded nodes can be pruned
a is optimally efficient
A* is Optimally Efficient

No other optimal algorithm is guaranteed to expand fewer nodes than A*

    • (except perhaps eliminating consideration of ties at f(n) = C*)
  • Compared to other algorithms using same heuristic
pros and cons of a
Pros and Cons of A*
  • A* is optimal and optimally efficient
  • A* is still slow and bulky (space kills first)
    • Number of nodes grows exponentially with the length to goal
      • This is actually a function of heuristic, but they all have errors
    • A* must search all nodes within this goal contour
    • Finding suboptimal goals is sometimes only feasible solution
a for video games
A* for video games
  • Is very common
  • It will find a path from start to goal
  • The world is spatially discretized
    • Produces zigzag effect between cells
    • Does not produce smooth turns
    • Does not check for “illegal moves” or for abrupt turning when a unit has a particular turning radius
removing the zigzag effect
Removing the Zigzag Effect

Can just associate a cost with each turn, but that does not solve the problem entirely. A better smoothing process is to remove as many waypoints as possible.

removing the zigzag effect23
Removing the Zigzag Effect

checkPoint = starting point of pathcurrentPoint = next point in pathwhile (currentPoint->next != NULL)   if Walkable(checkPoint, currentPoint->next)      // Make a straight path between those points:      temp = currentPoint      currentPoint = currentPoint->next      delete temp from the path   else      checkPoint = currentPoint      currentPoint = currentPoint->next

removing the zigzag effect24
Removing the Zigzag Effect

Checks path from waypoint to waypoint. If the path traveled intersects a blocked location, the waypoint is not removed. Otherwise, remove the waypoint.

Leaves “impossible” sections as is.

adding realistic turns
Adding Realistic Turns

Want to be aware of a unit’s turning radius and choose shortest route to destination, in this case the right turn will lead to the shortest route.

adding realistic turns26
Adding Realistic Turns
  • Calculate the length of the arc plus the line segment for both left and right turns. Shortest path is the one to use.
adding legal turns
Adding Legal Turns

Several Postprocess Solutions (cheats)

  • Ignore blocked tiles – obviously bad
  • Path recalculations – associate a byte with each tile, each bit denoting the surrounding tiles as legal or illegal; may invalidate legal paths from other directions = bad
  • Decrease turning radius until it is legal – bad for units with constant turning radius (e.g. truck), good for units such as people
  • Backing up – make a three point turn – good for units such as trucks, weird for people
adding legal turns28
Adding Legal Turns

Problems

  • Methods shown previously are basically cheats, except for the second one (path recalculations), which can fail to find valid paths
  • How can we make sure that paths taken are both legal and do not violate the turning radius?
directional a
Directional A*

Sometimes the only legal path that does not violate the turning radius constraints is completely different from the path that the standard A* algorithm produces. To get around this, Pinter proposes a modification known as Directional A*.

directional a30
Directional A*

First things first

  • Add an orientation associated with each node, where the orientation can be any one of the eight compass directions
  • Each node now represented by three dimensions: [x, y, orientation]
directional a31
Directional A*
  • Check the path from a parent to a child node, not just whether or not the child is a blocked tile
  • Consider the orientation at parent and child nodes as well as the turning radius and size of the unit to see if path hits any blocked tiles
  • Result: a valid path given the size and turning radius of the unit
directional a32
Directional A*

Directional A* does not go directly from a to c because it sees that an abrupt left turn would cause the unit to hit blocked tiles. Thus, waypoint b is found as the shortest legal path.

directional a33
Directional A*

Problem: adding an end orientation

  • Four common paths
directional a34
Directional A*
  • Can easily compute the four common paths and choose the shortest one
  • Can add smoothing algorithm presented earlier, with the modification of sampling points along a valid curve between two points rather than just a straight line between two points
expanding the search
Expanding the Search
  • So far, have been using a Directional-8 search
  • Some paths will fail under this method
  • Try searching more than one tile away
  • Directional-24: search two tiles away, rarely fails to find a valid path
  • Directional-48: search three tiles away, almost never fails to find a valid path
modifying the heuristic
Modifying the Heuristic
  • Standard A* measures straight line distance from start to goal
  • Modify so that it measures the shortest curve and line segment as calculated earlier, considering turn radius
  • If units can go in reverse, consider adding a cost penalty to encourage units to move in reverse only when necessary
directional a limitations
Directional A* Limitations
  • Very slow, constantly uses tables as a means to optimize it (directional table, heuristic table, hit-check table, etc)
  • Directional-48 may still possibly (though rarely) fail
  • The four common paths from origin to destination are not the only ones; there is an infinite number of paths
more optimizations
More Optimizations
  • Timeslice the search
  • Only use Directional-24 and -48 if a Directional-8 fails
  • Divide map into regions and pre-compute whether a tile in one region can reach a tile in another
  • Use two matrices to calculate intermediate search results, one for slow, timesliced searches and the other for faster searches
summary
Summary
  • Directional A* finds legal paths and realistic turns
  • Directional A* is slow
  • Examples only take into account a 2D space partitioned into a grid, but can be extended to support various partitioning methods in 2D or 3D
  • Suggest standard A* for most units and Directional A* for various large units
realistic human walking paths

Realistic Human Walking Paths

Nicholas L. Johnson

School of InformationUniversity of Michigan

David C. Brogan

Computer Science DepartmentUniversity of Virginia

motivation for walking characters
Motivation for walking characters
  • Scientific and Entertainment Applications

Helbing et al. – Escape Panic

Helbing et al. – Trails

Phantom Menace

realistic walking paths
Realistic walking paths
  • Dynamics matters!
    • Walking dynamics influence what path is generated
      • CanI cut the corner to dart down the hallway?
    • Following a path influences walking dynamics
      • I must slow down to cut the corner
  • What a character cando influences what it does
background
Background
  • Robotics, Animation, Practitioners
    • Reactive Control
      • Reynolds’ steering behaviors
    • Planning
      • Bandi and Thalmann A* method
    • Example-based
      • Choi, Lee, and Shin motion capture library
what do realistic paths look like
What do realistic paths look like?
  • An empirical question
    • 36 people performed walking experiments
      • convenience sample of passersby (unpaid)
      • Video taped and rotoscoped for path acquisition
five walking experiments
Five walking experiments
  • Carry piece of paper from A to B
  • Return to A andrepeat 3 times
  • 7 paths generated
five walking experiments46
Five walking experiments
  • No Turn
    • 7 participants
five walking experiments47
Five walking experiments
  • Wide Turn
    • 7 participants
five walking experiments48
Five walking experiments
  • Sharp Turn
    • 9 participants
five walking experiments49
Five walking experiments
  • U Turn
    • 6 participants
five walking experiments50
Five walking experiments
  • S Turn
    • 7 participants
empirical observations
Empirical Observations
  • Similar speed and acceleration profiles
  • Presence of turning constraints

Limit on turning radius

Inertia

pedestrian model outline
Pedestrian model outline
  • Discrete event simulation of Sim
    • Calculate a desired speed
      • Proximity to goal and obstacles
    • Compute desired heading
      • Obey turning constraints and avoid obstacles
    • Integrate dynamics
      • Obey inertial constraints
  • Heavily influenced by experiments
calculate desired speed
Calculate desired speed
  • Nominal desired speed: 1.36 m/s
  • Linear acceleration from start during first 1.82 m
  • Linear deceleration to goal during final 1.63 m
  • Desired speed near obstacle: 1.10 m/s
    • Linear speed modulation within 0.81 m
compute desired heading
Discretize the world

Label grid cellsConfiguration space

Compute desired heading
compute desired heading55
Heading Chart

turning radius, r = 2 m

Compute desired heading
  • Heading for each grid cell
    • A function of turning constraints
      • A function of walking dynamics
        • A function of speed
    • Shortest path to goal
      • If speed were maintained

}

r

Compute headings for multiple turning constraints

heading for each grid cell
Heading for each grid cell
  • Flood fill from goal
    • Goal heading and position is known
heading for each grid cell57
subgoal
  • All cells within +/- q can reach goal

q

  • Define subgoals d meters from goal

}

q

r

Turning radius, r

Heading for each grid cell
  • Flood fill from goal
    • Goal heading and position is known
heading for each grid cell58
Heading for each grid cell
  • Recursively flood fill fromeach subgoal
    • Heading is overwritten if betterpath is found
heading for each grid cell59
Heading for each grid cell
  • Recursively flood fill fromeach subgoal
heading for each grid cell60
Heading for each grid cell
  • Recursively flood fill fromeach subgoal
heading for each grid cell61
Heading for each grid cell
  • Recursively flood fill fromeach subgoal
heading for each grid cell62
Heading for each grid cell
  • Recursively flood fill fromeach subgoal
heading for each grid cell63
Heading for each grid cell
  • After 2p / q iterations
    • Subgoals trace a circle of radius, r
heading for each grid cell64
Heading for each grid cell
  • Recursively flood fill fromeach subgoal
heading for each grid cell65
Heading for each grid cell
  • Recursively flood fill fromeach subgoal
heading for each grid cell66
Heading for each grid cell
  • Obstacles cause shadows
heading for each grid cell67
Heading for each grid cell
  • Obstacles cause shadows

Subgoal if:

      • Adjacent to obstacle

and

      • Adjacent to unlabeled grid cell (or grid cell pointing to inferior subgoal)
heading for each grid cell68
Heading for each grid cell
  • Obstacles cause shadows
heading for each grid cell69
Heading for each grid cell
  • Obstacles cause shadows
heading for each grid cell70
Heading for each grid cell
  • Obstacles cause shadows
heading for each grid cell71
Heading for each grid cell
  • Obstacles cause shadows
heading for each grid cell72
Heading for each grid cell
  • Obstacles cause shadows
heading for each grid cell73
Heading for each grid cell
  • Obstacles cause shadows
    • Some grid cells unlabeled
      • r parameter is too high
      • Create heading charts with multiple r values
walking dynamics
Walking dynamics
  • Compute Sim turning radius, r
    • According to speed and mass
  • Look up heading from appropriate heading chart
    • Reduce speed if no specified heading for grid cell
  • Change speed according to schedules
  • Influence of inertia
  • Integrate Sim dynamics
turning radius
Turning Radius
  • To maintain constant centripetal force
    • Faster Sim requires larger r
  • Assume constant ratio between mass and force
    • Larger people exert larger forces
inertia
Inertia
  • Cannot instantly accomplish desired heading
    • Weighted average of previous heading and desired
  • cinertia and cturn tuned using experiments
validation
Validation
  • Two experimental conditions
evaluation metrics
Evaluation Metrics
  • No perfect metric
    • Distance error
      • Momentary velocity error leads to sequence of distance errors
    • Area error
      • Ignores speed errors
    • Speed error
      • Ignores dissimilarity of paths
results
Results
  • Compared to A* path planning model
    • Cell size = 0.04 m
    • 20 heading charts, turning radii 0 to 1.5 m
results80
Results
  • Compared to A* path planning model
conclusion
Conclusion
  • A method for generating realistic walking paths
    • Parameterized from observations
    • Shortest path subject to
      • Turning limitations
      • Inertia
future work
Future work
  • Better understand evaluation metrics
    • Distance is highly correlated to both area and speed errors
  • Human path planning is complex
    • Humans adjust velocity opportunistically during path
    • Humans do not strive for shortest paths
  • Computational techniques complement research from biomechanists, perceptual psychologists, and cognitive scientists
our goal
Our goal
  • Given
    • Initial position, speed, facing direction
    • Final position, speed, facing direction
    • Accurate model of world
  • Find
    • Path
      • satisfying boundary constraints
      • providing realistic walking paths
building a walking path generator
Building a walking path generator
  • What can pedestrians do?
    • Experimental evaluationof human performance
building a walking path generator85
Building a walking path generator
  • What paths suit capabilities?
    • Search for paths to goal subject to realistic walking constraints
building a walking path generator86
Building a walking path generator
  • Evaluation
    • Validate pedestrian modelwith additional experimentsand multiple metrics
participant characteristics
Participant characteristics
  • Questionnaire results
    • Age: 23 (SD 6)
    • Height: 1.8 m (SD 0.078 m)
    • Weight: 75 kg (SD 15 kg)
    • Shoulder Width: 0.25 m (SD 0.31 m)
empirical observations88
Empirical Observations
  • Similar speed profiles
    • Mean maximum speed across all tests
      • 1.36 m/s (N = 285, SD 0.162 m/s)
    • Mean speed at closest point to each obstacle
      • 1.10 m/s (N = 308, SD 0.143 m/s)
empirical observations89
Empirical observations
  • Similar acceleration profiles
    • Deceleration begins 1.63 m from goal
    • Acceleration stops at 1.82 m from start
      • Measured using Hi-Ball tracker in straight-line walking
empirical observations90
Empirical observations
  • Turning constraints

Limit on radius Inertia

pedestrian model goal
Pedestrian model goal
  • Given
    • Final position, speed, heading
    • Accurate model of world
  • Find
    • Path
      • From any initial position
      • Satisfying boundary constraints
      • Providing realistic walking paths
validation92
Validation
  • Two experimental conditions
    • Hidden camera
    • 30 participants
    • Digitized paths
ad