1 / 23

CSCI 4310

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

garran
Download Presentation

CSCI 4310

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CSCI 4310 Lecture 8: Path Planning

  2. Book • Buckland Ch. 8

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

  4. 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’

  5. Finely granulated • Prevents some backtracking • Smoother paths

  6. 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

  7. 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 B C A

  8. 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) B C A

  9. 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.)

  10. 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

  11. 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

  12. 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

  13. 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);

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

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

  16. Pre-Calculated Paths • Dynamic programming 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)

  17. 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

  18. 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

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

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

  21. 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

  22. Deformable Terrain • Tony Stentz of Carnegie Mellon • D* or Dynamic A* algorithm • Useful under dynamic terrain • http://www.frc.ri.cmu.edu/~axs/

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

More Related