ASA Robot Path Planning

ASA Robot Path Planning is a research and simulation project about one simple question: how should a robot choose a path when the field is full of obstacles?

The project was built for an Analisis dan Strategi Algoritma paper, but it grew into more than a document. It became a small research system: Python experiments, CSV results, visual figures, a full paper, and an interactive React report where the algorithms can be inspected directly.

The setting is a humanoid robot soccer field. The robot starts on one side, the goal is on the other, and the path between them is blocked by circles, walls, and narrow gaps. That makes the problem easy to understand visually, but still rich enough to expose the trade-offs between search strategies.

The problem

Path planning can sound abstract until it is placed inside a field. A robot does not only need to find any route. It needs a route that is valid, efficient, and computable within a reasonable amount of time.

In this project, the field is modeled as a 60 x 40 two-dimensional space with static obstacles. The robot is simplified as a point, with a fixed start and goal position. Every algorithm has to produce a collision-free path from start to goal.

The interesting part is that “best” is not a single metric.

• Path cost asks whether the route is short.
• Runtime asks whether the route can be found quickly.
• Processed count asks how much search work the algorithm performs.
• Success rate asks whether the algorithm still works when the field gets harder.

A method can be fast but less optimal. Another can be optimal but explore too much. A sampling method can be flexible but sensitive to randomness. The project is about reading those trade-offs carefully.

The system

The project compares five algorithms across the same family of soccer-field scenarios:

• Brute Force - enumerates bounded waypoint combinations as a baseline.
• UCS - searches the grid using actual accumulated cost.
• GBFS - follows the heuristic direction toward the goal.
• A* - combines actual cost and heuristic distance.
• RRT* - grows and rewires a sampling tree in continuous space.

Each scenario changes the shape and density of the obstacles. There are easier maps with sparser circles, medium maps with partial walls, difficult maps with forced detours, and dense maps where free space becomes narrow.

The implementation is split into two layers. The Python side runs the reproducible experiments and exports the research data. The React/Vite side turns the paper into an interactive report with charts, downloads, and a browser simulator.

Why robot soccer

Robot soccer gives the algorithms a physical story. A path is not just a line on a graph. It becomes the route a robot would take to move through the field.

That matters because the visual context makes algorithm behavior easier to read. GBFS feels fast because it points itself toward the goal. UCS feels exhaustive because it expands outward by cost. A* feels more disciplined because it keeps the optimal grid cost while using the heuristic to avoid unnecessary exploration. RRT* feels different because it does not think in grid cells at all.

The soccer field turns algorithm analysis into something you can see.

Experiment design

The main experiment runs four scenarios across ten feasible map seeds. Each algorithm is measured on path cost, runtime, processed count, and success rate. Additional sweeps test grid resolution and obstacle density so the result does not depend only on one hand-picked map.

That structure was important. A single path comparison can be convincing visually, but it can also hide randomness or lucky geometry. Repeating across seeds makes the comparison more honest.

The project also keeps the research artifacts visible:

• raw per-seed CSV results,
• summary CSV files with averages and standard deviations,
• generated figures for the paper,
• a final PDF and DOCX paper,
• and an interactive web version of the report.

What the results show

The clearest result is that A* keeps the same path cost as UCS on every feasible grid scenario while processing fewer nodes. In the easier scenario, the processed count drops dramatically. In harder maps, the reduction is smaller but still meaningful.

GBFS is usually the fastest method, but it pays for that speed with weaker path quality. It follows the goal aggressively, which is useful when speed matters, but it does not carry the same optimality guarantee as UCS or A*.

RRT* is useful because it works in continuous space instead of being tied to the grid. But its behavior depends more on sampling, iteration limits, radius, and seed. It is powerful, but less predictable in this controlled comparison.

Brute Force is helpful as a baseline because it is easy to reason about. It tries bounded waypoint combinations and checks whether the segments are valid. But as obstacle layouts become more complex, its reliability drops quickly.

Interactive report

The web report was built so the project would not live only as a static paper. It lets the reader inspect the algorithms, open the same “paper mode” scenario used in the figure, compare paths, read metrics, and download the research files.

That changed the feel of the project. Instead of asking someone to trust a table, the page lets them move between explanation, visualization, and data.

The simulation is not trying to be a full robot physics engine. It is a focused research interface: enough interaction to make the comparison understandable, but not so much that the algorithmic question gets buried.

What I learned

The biggest lesson was that algorithm comparison is not only about picking a winner. It is about defining what “better” means in the shape of the problem.

For this grid-based model, A* is the most balanced choice because it preserves UCS path quality while reducing exploration. But that conclusion has a boundary. If the robot model changes, the obstacles move, or continuous motion constraints matter more, the answer can change too.

That is what made the project interesting. The code finds paths, but the research is about reading trade-offs: cost, speed, reliability, representation, and the gap between a clean algorithm and the messy field it has to move through.