(PART 1) PHILOSOPHY In design, you can never choose whether you pay - - PowerPoint PPT Presentation

part 1 philosophy
SMART_READER_LITE
LIVE PREVIEW

(PART 1) PHILOSOPHY In design, you can never choose whether you pay - - PowerPoint PPT Presentation

MULTI-AGENT NAVIGATION (PART 1) PHILOSOPHY In design, you can never choose whether you pay a cost, only how you pay it. Dr. Fred Brooks University of North Carolina at Chapel Hill 2 SEANS LECTURES Oct 2 Introduction and Graph


slide-1
SLIDE 1

MULTI-AGENT NAVIGATION (PART 1)

slide-2
SLIDE 2

PHILOSOPHY

2

In design, you can never choose whether you pay a cost, only how you pay it.

  • Dr. Fred Brooks

University of North Carolina at Chapel Hill

slide-3
SLIDE 3

SEAN’S LECTURES

3

  • Oct 2 – Introduction and Graph Searches
  • Oct 7 – Intro to Menge, Git, and OpenGL
  • Assign homework 2
  • Oct 9 – Global planners
  • Oct 14 – Local Planners (part 1)
  • Oct 21 – Local Planners (part 2)
  • Assign homework 3
  • Oct 23 – Extraneous issues

University of North Carolina at Chapel Hill

slide-4
SLIDE 4

ROADMAP SURVEY

4

  • Languages
  • C/C++, Python, Java
  • Representation
  • Objects/Pointers, Adjacency List, Matrix
  • Even starting ground for next homework assignment

University of North Carolina at Chapel Hill

slide-5
SLIDE 5

MULTI-AGENT NAVIGATION

5

  • Why do it?
  • Autonomous cars
  • Robot assembly lines
  • Swarm simulation
  • Pedestrian simulation

University of North Carolina at Chapel Hill

slide-6
SLIDE 6

MULTI-AGENT NAVIGATION

6

  • Planning for multiple robots
  • Can be the same as for a single robot with

multiple parts

  • The parts need not be connected
  • Dimension grows linearly with the robots
  • For N simple 2D, translational robots, there are

2N dimensions in configuration space

  • Algorithmic complexity tends to be exponential

in dimensions (for “complete” solutions)

University of North Carolina at Chapel Hill

slide-7
SLIDE 7

MULTI-AGENT NAVIGATION

7

  • How do we do it?
  • Complete solutions are infeasible
  • “Decoupled” solutions
  • Independent solutions whose interactions are

coordinated

  • Computational necessity
  • Design decision
  • Entities are often independent

University of North Carolina at Chapel Hill

slide-8
SLIDE 8

MULTI-AGENT NAVIGATION

8

  • Skipping general multi-agent navigation
  • Path coordination
  • Pareto optimality
  • Prioritized planning
  • We’ll come back to it
  • Focus on pedestrian/crowd simulation

University of North Carolina at Chapel Hill

slide-9
SLIDE 9

PEDESTRIAN SIMULATOR ARCHITECTURE

9

  • Simulation State: obstacles (static & dynamic), agents
  • Goal Selection: High-order model of what the agent wants
  • Static Planning: Plan to reach goal vs. static obstacles
  • Local Collision Avoidance: Adapt plan because of other agents

Simulator State

University of North Carolina at Chapel Hill

Goal Selection Static Planning Goal Local Collision Avoidance

v0

slide-10
SLIDE 10

PEDESTRIAN SIMULATOR ARCHITECTURE

10

  • We’ll have two homework assignments
  • Implement static planning algorithm
  • Implement local collision avoidance

Simulator State

University of North Carolina at Chapel Hill

Goal Selection Static Planning Goal Local Collision Avoidance

v0

slide-11
SLIDE 11

STATIC PLANNING

11

  • Identifying and encoding traversable space
  • Roadmaps
  • Navigation Mesh
  • Corridor Maps
  • Guidance/potential fields
  • (We’ll talk about these in detail in a week).

University of North Carolina at Chapel Hill

slide-12
SLIDE 12

STATIC PLANNING

12

  • Graph searches
  • Many of the most common structures are,

ultimately, graphs

  • Finding paths from start to end become a basic
  • peration
  • Let’s look at path computation
  • http://www.youtube.com/watch?v=czk4xgdhdY4
  • http://www.youtube.com/watch?v=nDyGEq_ugGo

University of North Carolina at Chapel Hill

slide-13
SLIDE 13

OPTIMAL PATH

13

  • Typically, we’re looking not for any path
  • We have a sense of “optimality” and want to find the
  • ptimal path.
  • Typically distance
  • Can be other functions: e.g.,
  • Energy consumed (such as for uneven terrain)
  • Psychological comfort (avoiding “negative”

regions)

University of North Carolina at Chapel Hill

slide-14
SLIDE 14

OPTIMAL PATH

14

  • The roadmap (and all graph-based traversal

structures) encode the costs of moving from one node to another.

  • Cost of movement is the edge weight.
  • Given graph and optimality definition, how do we

compute the optimal path?

University of North Carolina at Chapel Hill

slide-15
SLIDE 15

OPTIMAL PATH

15

  • Assumptions
  • The edge weights are non-negative
  • i.e., every section of the path requires a “cost”
  • No path section provides a “gain”

University of North Carolina at Chapel Hill

slide-16
SLIDE 16

BREADTH/DEPTH-FIRST SEARCHES

16

  • Depth-first
  • Similar to wall-following algorithms
  • Breadth-first
  • Weights are ignored, the boundary of the search

space is all nodes k steps away from the source.

  • This is guaranteed to find a path if one exists
  • Only guaranteed to be optimal if it is the only path

University of North Carolina at Chapel Hill

slide-17
SLIDE 17

DJIKSTRA’S ALGORITHM

17

  • Single-source shortest-path (to all other nodes)
  • Shortest path to a specific target node is simply

an early termination

  • Djikstra’s Algorithm requires our non-negative cost

assumption

  • What is the algorithm?

University of North Carolina at Chapel Hill

Dijkstra, E. W. (1959). "A note on two problems in connexion with graphs". Numerische Mathematik 1: 269–271. doi:10.1007/BF01386390

slide-18
SLIDE 18

DJIKSTRA’S ALGORITHM

18

minDistance( start, end, nodes ) For all nodes ni, i≠ start , cost(ni) = ∞ cost( start ) = 0 unvisited = nodes \ {start} // set // difference c = start // current node while ( true ) if ( c == end ) return cost(c) For each unvisited neighbor, n, of c cost(n) = min( cost(n), cost(c) + E(c,n) ) c = minCost( unvisited ) // 1 if ( cost( c ) == ∞ ) return ∞

University of North Carolina at Chapel Hill

1) We’ll say that minCost returns ∞ if there are no nodes in the set. Why?

slide-19
SLIDE 19

DJIKSTRA’S ALGORITHM

19

  • How do we modify it to get a path?
  • What is the cost of this algorithm?

University of North Carolina at Chapel Hill

slide-20
SLIDE 20

DJIKSTRA’S ALGORITHM

20

shortestPath( start, end, nodes ) For all nodes ni, i≠ start cost(ni) = ∞ prev(ni) = Ø cost( start ) = 0 unvisited = nodes \ {start} # set difference visited = {} c = start # current node while ( true ) if ( c == end ) break For each unvisited neighbor, n, of c if ( cost(n) > cost(c) + E(c,n) ) cost(n) = cost(c) + E(c,n) prev(n) = c c = minCost( unvisited ) if ( cost( c ) == ∞ ) break if ( cost(end) < ∞ ) construct path

University of North Carolina at Chapel Hill

slide-21
SLIDE 21

DJIKSTRA’S ALGORITHM

21

  • Constructing a path

path = [ end ] p = prev[ end ] while (p != Ø) path = [ p ] + path // list concatenation p = prev[ p ] return path

University of North Carolina at Chapel Hill

slide-22
SLIDE 22

DJIKSTRA’S ALGORITHM

22

  • What is the cost of this algorithm?
  • If the graph has V vertices and E edges:
  • E * d + V * m
  • d is the cost to change a node’s cost
  • m is the cost to extract the minimum unvisited

node

  • d is typically a nominal constant
  • m depends on how we find the minimum node

University of North Carolina at Chapel Hill

slide-23
SLIDE 23

DJIKSTRA’S ALGORITHM

23

  • Minimum neighbor
  • Djikstra originally did a search through a list
  • Maintaining a sorted vector doesn’t solve the

problem

  • The cost of maintaining the sort would be the

same as simply searching

  • Cost was |E| + |V|2

University of North Carolina at Chapel Hill

slide-24
SLIDE 24

DJIKSTRA’S ALGORITHM

24

  • Minimum neighbor
  • Use a good min-heap implementation and it

becomes

  • |E| + |V| log |V|
  • (Good  Fibonnaci heap)

University of North Carolina at Chapel Hill

Fredman, Michael Lawrence; Tarjan, Robert E. (1984). "Fibonacci heaps and their uses in improved network optimization algorithms". 25th Annual Symposium on Foundations of Computer Science. IEEE. pp. 338–346. doi:10.1109/SFCS.1984.715934

slide-25
SLIDE 25

DJIKSTRA’S ALGORITHM

25

  • Good general solution
  • Guaranteed to find optimal solution
  • Not very smart
  • Why?

University of North Carolina at Chapel Hill

s g

slide-26
SLIDE 26

DJIKSTRA’S ALGORITHM

26

  • Djikstra’s algorithm expands the front uniformly
  • It extends the nearest node on the front
  • This causes the search space to inflate uniformly

University of North Carolina at Chapel Hill

slide-27
SLIDE 27

A* ALGORITHM

27

  • “Best-first” graph search algorithm
  • Uses a knowledgeable heuristic to estimate the

cost of a node

  • At any given time, the expected cost of a node,

f(x), is the sum of two terms

  • Its known cost from the start, g(x)
  • Its estimated cost to the goal, h(x)

University of North Carolina at Chapel Hill

Hart, P. E.; Nilsson, N. J.; Raphael, B. (1968). "A Formal Basis for the Heuristic Determination of Minimum Cost Paths". IEEE Transactions on Systems Science and Cybernetics SSC4 4 (2): 100–107. doi:10.1109/TSSC.1968.300136

slide-28
SLIDE 28

A* ALGORITHM

28

  • Admissible heuristics
  • h(x) ≤ D(x,goal)
  • D(x,y) actual distance from node x to y
  • i.e., it must be a conservative estimate
  • In path planning, our heuristic is usually Euclidian

distance

  • Triangle-inequality insures admissibility
  • h(x) ≤ E(x,y) + h(y)

University of North Carolina at Chapel Hill

slide-29
SLIDE 29

A* ALGORITHM

29

  • Admissible heuristics
  • Monotonic/consistent
  • h(x) ≤ E(x,y) + h(y)
  • i.e., the “best guess” for a node cannot be

beaten by the known cost to move to another node and my best guess from there

  • This applies to our Euclidian distance heuristic

University of North Carolina at Chapel Hill

slide-30
SLIDE 30

A* ALGORITHM

30

minDistance( start, end, nodes )

closed = {}

  • pen = {start}

g[ start ] = 0 f[ start ] = g[ start ] + h( start, end ) while ( ! open.isEmpty() ) c = minF( open ) if ( c == end ) return g[ c ]

  • pen = open \ {c}; closed = closed U {c}

for each neighbor, n, of c gTest = g[ c ] + E( n, c ) fTest = gTest = h( n, e ) if ( n in closed && fTest ≥ f[ n ] ) continue if ( n not in open || fTest < f[n] ) g[ n ] = gTest f[ n ] = fTest

  • pen = open U {n}

University of North Carolina at Chapel Hill

Wikipedia’s A* - assumes monotonic heuristic

slide-31
SLIDE 31

A* ALGORITHM

31

  • Closed set
  • It is (apparently) possible to visit a node but then

later need to place it back in the open set.

  • f(n) = g(n) + h(n,e)
  • h(n, e) is constant for constant n & e
  • So, to revisit n, f’(n) < f(n)  g’(n) < g(n)
  • We found a SHORTER path to that node
  • I cannot come up with a circumstance where this

happens with the distance heuristic*

University of North Carolina at Chapel Hill * Absence of proof is not proof of absence.

slide-32
SLIDE 32

A* ALGORITHM

32

minDistance( start, end, nodes )

closed = {}

  • pen = {start}

g[ start ] = 0 f[ start ] = g[ start ] + h( start, end ) while ( ! open.isEmpty() ) c = minF( open ) if ( c == end ) return g[ c ]

  • pen = open \ {c}; closed = closed U {c}

for each neighbor, n, of c if ( n in closed ) continue gTest = g[ c ] + E( n, c ) if ( gTest < g[ n ] ) g[ n ] = gTest; f[ n ] = gTest + h(n, end)

  • pen = open U {n}

University of North Carolina at Chapel Hill

Sean’s A*

slide-33
SLIDE 33

A* ALGORITHM

33

  • Notes
  • The goal node may be visited/updated multiple

times

  • There may be multiple paths to it
  • Only when the goal node is the “closest” node is it

considered final

  • Like Djikstra’s, it will still fall victim to local minima
  • But gets around them more efficiently

University of North Carolina at Chapel Hill

slide-34
SLIDE 34

A* ALGORITHM

34

  • Constructing a path
  • We add the same instrumentation
  • Record where we came from when we reduce

the cost of each node

  • Construct the path by tracing backwards from

the goal

University of North Carolina at Chapel Hill

slide-35
SLIDE 35

A* ALGORITHM

35

  • Efficient solution
  • Guaranteed to find optimal solution (for admissible

heuristic)

  • Much more optimized search space
  • Can be fooled by adversarial graph

University of North Carolina at Chapel Hill

s g

slide-36
SLIDE 36

A* ALGORITHM

36

  • Demos
  • http://www.youtube.com/watch?v=DINCL5cd_w0

University of North Carolina at Chapel Hill

slide-37
SLIDE 37

WEIGHTED A* ALGORITHM

37

  • f(n) = g(n) + εh(n)
  • ε = 0  Djikstra’s algorithm

University of North Carolina at Chapel Hill

s g

slide-38
SLIDE 38

WEIGHTED A* ALGORITHM

38

  • f(n) = g(n) + εh(n)
  • ε = 1  A* algorithm

University of North Carolina at Chapel Hill

s g

slide-39
SLIDE 39

WEIGHTED A* ALGORITHM

39

  • f(n) = g(n) + εh(n)
  • ε > 1  Strong bias straight towards goal
  • Trades optimality for speed
  • Cost of path ≤ ε * cost of optimal

University of North Carolina at Chapel Hill

s g

slide-40
SLIDE 40

D* ALGORITHM

40

  • These algorithms assume perfect a priori knowledge
  • f the environment.
  • What if our knowledge of the environment (or the

environment itself) changes over time?

  • We use an incremental search algorithm
  • D*, D*lite, etc.
  • These algorithms used in the Mars rovers and the

DARPA grand challenge winners

University of North Carolina at Chapel Hill

Stentz, Anthony (1994), "Optimal and Efficient Path Planning for Partially-Known Environments", Proceedings of the International Conference on Robotics and Automation: 3310–3317

slide-41
SLIDE 41

QUESTIONS?

41 University of North Carolina at Chapel Hill