|
| 1 | +--- |
| 2 | +# Jekyll 'Front Matter' goes here. Most are set by default, and should NOT be |
| 3 | +# overwritten except in special circumstances. |
| 4 | +# You should set the date the article was last updated like this: |
| 5 | +date: 2020-12-06 # YYYY-MM-DD |
| 6 | +# This will be displayed at the bottom of the article |
| 7 | +# You should set the article's title: |
| 8 | +title: A* Implementation Guide |
| 9 | +# The 'title' is automatically displayed at the top of the page |
| 10 | +# and used in other parts of the site. |
| 11 | +--- |
| 12 | +## Introduction |
| 13 | +This wiki aims to serve as a brief introduction and implementation guideline for A* search, specifically applied to robot motion planning. This will discuss how the algorithm functions, important design aspects in the pipeline, common knobs to tune, and efficiency considerations. The specific guidance and notes will be mainly related to implementation for an Ackermann steered vehicle, but will be useful for abstracting to other systems as well. |
| 14 | + |
| 15 | +A* search is just one of many algorithms that can be used for search, but note that grid-based search methods such as this are often limited in their effectiveness when used for higher DOF systems. For those problems, it would be worthwhile to consider sampling based planning methods instead. |
| 16 | + |
| 17 | +These notes and guidance are augmented with heavy borrowing from and attribution to Maxim Likhachev’s 16-782 Planning and Decision Making in Robotics course, Fall 2020. |
| 18 | + |
| 19 | +## Overview of A* Algorithm |
| 20 | +A* is a popular search algorithm that is guaranteed to return an optimal path, and during its search for an optimal path, will provably expand the minimum number of states to guarantee optimality. Why is this useful? It allows for far less exploration, and in turn, less computation than a Dijkstra search, which is a greedy search algorithm. |
| 21 | + |
| 22 | +### Important Terms |
| 23 | +- g(s) value - cost of the shortest path from the start state (sstart) to the current state (s) so far |
| 24 | +- h(s) value - estimate of the cost-to-go from the current state (s) to the goal state (sgoal) |
| 25 | +- f(s) value - total estimated cost from the start state (sstart) to the goal state (sgoal) |
| 26 | +- Admissibility - h(s) is an underestimate of the true cost to goal |
| 27 | +- Monotonicity/Consistent - h(s) <= c(s,s’) + h(s’) for all successors s’ of s |
| 28 | +- Optimality - no path exists from the start to the goal with a lower cost within the constraints of the problem |
| 29 | + |
| 30 | +A* works by computing optimal g-values for all states along the search at any point in time. |
| 31 | + |
| 32 | + |
| 33 | + |
| 34 | +## Planning Representation |
| 35 | +When designing a planner, you first need to decide a few things about how your problem will be represented. Key questions: |
| 36 | +- What states of your robot do you care about? |
| 37 | + - Examples: X-position, Y-position. Yaw-Pose, etc… |
| 38 | +- What actions can your robot take? |
| 39 | + - Can it move in any directions unconstrained? |
| 40 | + - Are there non-holonomic constraints? |
| 41 | +- How is your environment modeled? |
| 42 | +- What is the starting configuration for your robot? |
| 43 | +- Is the environment model static or can it change dynamically? |
| 44 | +- How is cost represented in your problem? |
| 45 | + - Distance traveled by your robot? |
| 46 | + - Time taken from the start? |
| 47 | + - Proximity to specific areas within the map? |
| 48 | +- What is your desired goal configuration? |
| 49 | + - Is it a specific X and Y location? |
| 50 | + - Is it a partial goal? |
| 51 | + - This means that only SOME of the states that are represented need to match a goal configuration for the goal condition to be satisfied |
| 52 | + |
| 53 | +## Key Data Structures |
| 54 | +Priority Queues |
| 55 | +- Ordering items in the queue based on some value |
| 56 | + - Key for A* should be f(s) |
| 57 | + - Typically the items are class instances or structs that contain the state, parent, trajectory, g(s), c(s), and other information |
| 58 | + - The most efficient way to combine two sets of items into one priority queue is by merge sorting them independently and them merging the two priority queues ala merge sort |
| 59 | + - Can apply this process to the set of children generated from expanding a node |
| 60 | + |
| 61 | +## Map Representation |
| 62 | +#### Explicit: |
| 63 | +- Pros: |
| 64 | + - Offline pre-generation allows for more efficient access during online planning |
| 65 | + - Simple to implement in data structures |
| 66 | +- Cons: |
| 67 | + - Not practical for higher order planning problems, as the map can easily become too large to represent in memory |
| 68 | + |
| 69 | +#### Implicit |
| 70 | +- Pros: |
| 71 | + - More efficient for memory |
| 72 | +- Cons: |
| 73 | + - Must be generated online, adding computation |
| 74 | + - More complicated implementation |
| 75 | + |
| 76 | +## Heuristic Design |
| 77 | +In general, for the best performance of your A* planner, you would leverage domain knowledge related to your specific use case to design a heuristic function. With a poor heuristic function, your planner can either waste time exploring extra states or find a sub-optimal solution to the goal. Also, you shouldn’t use the heuristic to bias the resulting plan, rather just to speed up the search process. |
| 78 | + |
| 79 | +How does A* guarantee optimality when your heuristic is admissible and consistent? The search expands states in the order of f = g + h, which is assumed to be the estimated cost of an optimal path to the goal. |
| 80 | + |
| 81 | +##### Simple Heuristics (Mainly Used for Toy Problems): |
| 82 | +- Euclidean Distance |
| 83 | +- Diagonal/Chebychev Distance |
| 84 | +- Manhattan Distance |
| 85 | + |
| 86 | +##### More Informed Heuristics: |
| 87 | +- Create map of h-values using a backwards A* search on a lower dimensional representation of the environment, and assigning the calculated g-values as the cost-to-goal |
| 88 | + - Backwards A* swaps the start and goal configuration in the search |
| 89 | + - Lower dimensional search helps to ensure the heuristic is admissible, as it should always be an underestimate of cost-to-goal |
| 90 | + |
| 91 | +##### Weighted Heuristic Search: |
| 92 | +- Takes your heuristic estimate and applies a weight to it to bias your search towards the goal |
| 93 | +- Often makes your heuristic inadmissible, which removes optimality guarantees, but can reduce search time immensely in some circumstances. |
| 94 | + |
| 95 | +##### Final Notes of Heuristics: |
| 96 | +As your planning problem becomes more complex (many local minima, high # of DOFs, etc) your heuristic function design choices quickly become the most important thing in your search, so spend time building and leveraging your knowledge of what the important factors are in a scenario when developing your heuristics. |
| 97 | + |
| 98 | +## Motion Primitives for Ackermann Vehicles |
| 99 | +Generating motion primitives for non-holonomic vehicles can be a computationally expensive task and especially when more demanding motion primitives are desired beyond setting constant control values nearly intractable in terms of online computation time. With this in mind it is best to pre-generate sets of motion primitives for different state values such as speed and steering angle. At the same time the footprint, or all locations the robot contacts the environment, throughout the trajectory of the motion primitive should be generated and can be used for online collision checking. The following are several design suggestions/design considerations for implementing motion primitive pregeneration for non-holonomic vehicles. |
| 100 | + |
| 101 | +Some suggestions to keep in mind: |
| 102 | +- Discretize angles and velocities at the start and end of the motion primitives |
| 103 | +- Build in an efficient way to transform the motion primitive trajectory and footprint into the frame of the expanding state |
| 104 | +- Best to have the footprint of the robot over the motion primitive pre-generated as well so only the checks need to be made |
| 105 | +- Structured as a mask or list of cells relative to the expanding node frame |
| 106 | +- Motion primitives are where the motion constraints should be applied ie only feasible motion primitives should be generated and used by the A* planner |
| 107 | + |
| 108 | +## References |
| 109 | +[1] Likhachev, Maxim. “A* Planning.” 16-782 Planning and Decision-making in Robotics. 2020, www.cs.cmu.edu/~maxim/classes/robotplanning_grad/lectures/astar_16782_fall20.pdf. |
0 commit comments