added path planning details#6
Open
smriti-kumar wants to merge 3 commits into
Open
Conversation
There was a problem hiding this comment.
Pull request overview
This PR adds a "Path Planning" subsection to the driving logic chapter of the IGVC report, describing the team's local A* planner on a Nav2 costmap with LiDAR input, future integrations (lane segmentation, FSM/behavior tree), and spline-based waypoint generation feeding the MPC.
Changes:
- Adds a new
\subsection*{Path Planning}describing the perception costmap input and A* planner. - Documents goal selection heuristics and future FSM-driven improvements.
- Describes spline smoothing of A* output and downstream MPC handoff.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
lucaslibshutz
requested changes
May 18, 2026
lucaslibshutz
left a comment
lucaslibshutz
left a comment
Contributor
There was a problem hiding this comment.
great work!! imo I think you should add some mathematical depth to show what is actually being computed and why we are doing so, but otherwise this looks pretty good! Also, might be worth trimming down a bit, as I'm not sure whether @JaidenAGrimminck might have overlapping stuff. not worth discussing immediately, but something to keep in mind.
|
|
||
| The perception pipeline publishes a Nav2 occupancy costmap representing nearby obstacles detected by the LiDAR sensor. Occupied territories are marked as high cost cells which correspond to obstacles like barrels, cones, potholes, and so on, while free space cells represent parts of the road that the car is allowed to travel on. This costmap serves as the primary input to the local planner. While the current version of the costmap contains only obstacle clusters from the LiDAR, in the future, it will be integrated with the outputs generated by lane segmentation, marking the boundaries of the current lane as an object, as well as using the centerline of the current lane as part of the goal for A* to target. | ||
|
|
||
| The local planner uses the A* search algorithm to compute a path through the environment. The algorithm first finds a cell near the center of the local costmap which represents the car’s current position that doesn’t contain any obstacles and marks this as the starting position. Then, to find a goal destination for A* to generate a path for, the planner searches for cells some target distance ahead in the forward direction and chooses a destination cell without obstacles that meets this criteria. This method is used rather than having a globally fixed coordinate since we’re unaware of the obstacles placed on the track in some of the driving challenges, and the obstacles might change each lap, so searching for a goal that is obstacle free in the general direction of movement is preferable. |
Contributor
There was a problem hiding this comment.
some formulas here would be helpful for some mathematical clarity imo
|
|
||
| The A* algorithm, to find a path, looks at neighboring cells using a cost function determined by both traversal distance and occupancy cost. Cells with obstacle costs above a threshold are treated as non-traversable, while lower cost cells, such as the inflation layer of the costmap, are still available for the car to travel on but are penalized according to their occupancy value. This encourages the planner to maintain safe clearance from nearby obstacles instead of driving directly along obstacle boundaries. | ||
|
|
||
| Once a valid path is generated from the start cell to the destination cell, the path of grid points is converted into world frame coordinates using the Nav2 costmap metadata. To extract waypoints from the A* path, a spline is fitted through the path, since raw A* output can contain sharp corners and uneven motion. The spline is generated using SciPy interpolation tools and produces a set of waypoints that can be used to control the car. The spline output represents the car’s local path trajectory and is published as a ROS topic. These waypoints generated by the spline will then be inputted into the MPC, which will generate the steering and throttle commands necessary to ensure the car can physically travel in the intended path. |
Contributor
There was a problem hiding this comment.
also some detail on how waypoints are sampled and at what frequency would be nice as well
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
didnt write about ekf since i saw lucas covered that