Autonomous Robot Navigation
A* path planning and postprocessing, implementation of pure pursuit for a TurtleBot and control and localisation for a simulated quadcopter. ROS2 and C++.
- Context
- Robotics course, National University of Singapore, exchange semester, spring 2026
- Team size
- 3, this page covers only my parts
- Status
- Completed
Planning on the TurtleBot
A* itself didn't return optimal results, even though it is supposed to. This is because those results are optimal only with respect to the 8-connected grid it operates on.
That grid only moves in 45° steps, so the paths come out as zigzags: Optimal on the grid, but not the straight lines the robot could drive. So I added a post-processing pass: walk the path, and wherever two nodes have line of sight, delete everything between them and refill the straight segment by line rasterisation.
The rasterisation is a supercover variant of Bresenham — it flags every cell the straight line touches rather than a one-cell-wide trace, so a shortcut cannot slip diagonally between two obstacle cells. A teammate wrote that part.
Teammates implemented Theta* and ran the evaluation: A* with post-processing gave slightly longer paths at a much lower runtime. The pure-pursuit controller and the obstacle inflation came from the course.
On the physical robot
The lab maze is roughly 5 × 5 m of cardboard, mapped by driving the TurtleBot through it under keyboard control and saving the SLAM map. The demo in the video at the top runs plain A*, not the post-processed planner.
That choice was deliberate: with corridors as narrow as 40 cm and a robot about 20 cm across, there is hardly any open space for a line-of-sight shortcut to cut across. The post-processed path comes out nearly identical to the grid path, so the demo gained nothing from it and the time went into the planner code instead. The gains in the figure above are real, but they are gains in open space.
Simulated quadcopter
PID control and localisation with a plain linear Kalman filter, not an extended one. The plots below are the tuning.
What I would do differently
Line-of-sight smoothing is a repair applied after the search. The cleaner answer is to let the search consider straight-line connections in the first place — which is Theta*, and exactly the trade-off my teammates measured.