Why does RRT sometimes fail where A* succeeds?

Narrow corridors require a **small** random sample to land *inside* the corridor before the tree can enter; with fixed iteration budgets or large steer steps, the probability per frame can be tiny. Lower **step size**, raise **max nodes**, or increase **goal bias** once the tree is close—this is the same narrow-passage issue that motivates **RRT*** or **Informed RRT**.

Is the yellow RRT path optimal?

No—basic RRT returns **any** feasible geometric path. The discrete **A*** path on the grid is optimal **for that graph model**, but it cannot cut diagonally through free space the way the continuous RRT can, so costs are not directly comparable cell-for-cell.

How does collision checking work here?

The edge is sampled at sub-cell spacing and each sample is mapped to the **floor** cell indices; if any sample hits a **wall** cell, the edge is rejected. It is a fast teaching check, not a continuous geometry engine with inflated obstacles.

Does Compare A* re-run when I move S or G?

The button snapshots the **current** grid and endpoints. Move markers, click **Compare A*** again to refresh the readout.

RRT Path Planner (grid)

Same 40×28 wall map as A*: random samples, nearest-neighbor steer, goal bias, collision-checked edges; grow an RRT and compare summary stats with one-click Manhattan A* baseline.

About this model

This page builds a textbook Rapidly-exploring Random Tree (RRT) on the same 40×28 wall grid used by engineering/astar-dijkstra-grid, but with continuous node coordinates in cell units so the robot can cut corners between lattice points. Each iteration samples a random free point (with optional goal bias), finds the nearest existing tree vertex in Euclidean distance, steers a fixed maximum step along the chord, and accepts the edge only if a dense segment–grid collision test clears every crossed cell center as non-wall. When a new vertex lands inside a goal capture radius around the G cell center, the search stops and the yellow polyline traces parents back to S. Because RRT is probabilistically complete rather than optimal, path length is usually larger than a discrete Manhattan A* baseline on the identical obstacles; the Compare A* button runs that baseline (4-neighbor, admissible heuristic, weighted cells cost ×5 if you paste them from the other page—here only walls are painted by default). Tune step size, bias, and iterations per frame to see the classic trade-off between aggressive exploration and tunnel-following through narrow gaps.

Who it's for: Robotics students who already played with A* on grids and want a complementary picture of sampling-based planning before RRT*, PRM, or kinodynamic variants.

Key terms

RRT
Sampling-based planning
Nearest neighbor
Steering function
Collision checking
Probabilistic completeness
Goal bias
Grid obstacles

How it works

Rapidly-exploring Random Tree on the same 40×28 wall grid as engineering/astar-dijkstra-grid: random samples, nearest-neighbor steer with collision checks, goal bias and acceptance radius. Use Compare A* for a discrete Manhattan A* baseline on identical S, G, and walls.

Frequently asked questions

Why does RRT sometimes fail where A* succeeds?: Narrow corridors require a small random sample to land *inside* the corridor before the tree can enter; with fixed iteration budgets or large steer steps, the probability per frame can be tiny. Lower step size, raise max nodes, or increase goal bias once the tree is close—this is the same narrow-passage issue that motivates RRT* or Informed RRT.
Is the yellow RRT path optimal?: No—basic RRT returns any feasible geometric path. The discrete A* path on the grid is optimal for that graph model, but it cannot cut diagonally through free space the way the continuous RRT can, so costs are not directly comparable cell-for-cell.
How does collision checking work here?: The edge is sampled at sub-cell spacing and each sample is mapped to the floor cell indices; if any sample hits a wall cell, the edge is rejected. It is a fast teaching check, not a continuous geometry engine with inflated obstacles.
Does Compare A* re-run when I move S or G?: The button snapshots the current grid and endpoints. Move markers, click Compare A* again to refresh the readout.

Continue with similar topics in this category — or all 48 in Engineering.

View category →

NewUniversity / research

Holonomic 2D Hovercraft MPC (MPPI)

Launch Simulator

Planar double integrator with ‖u‖₂ thrust cap: sampling-based MPPI steers to a draggable goal while soft-penalizing circular obstacles — rollout fan and best predicted path drawn live.

NewSchool

Maze Generators + A* (Grid)

Launch Simulator

Perfect mazes on the same 40×28 cell lattice as the pathfinding lab: recursive backtracker, Wilson, Eller, or randomized Prim; then solve with Manhattan A* (4-neighbors). Paint walls or erase passages and move S/G.

NewUniversity / research

ADC / DAC (Sampling)

Launch Simulator

Sine → samples → quantization → ZOH; Nyquist and optional aliasing demo.

NewSchool

A* / Dijkstra Pathfinding (Grid)

Launch Simulator

Interactive 40×28 grid pathfinder: A* (f=g+h), Dijkstra, or greedy best-first; Manhattan / octile / Euclidean heuristics, 4- vs 8-connectivity, paint walls + weighted cells, watch open / closed sets expand.

NewSchool

Thin-Walled Pressure Vessel Stress

Launch Simulator

Cylinder vs sphere membrane stresses: hoop σθ, longitudinal σz, von Mises stress, r/t thin-wall check, and yield safety factor.

NewSchool

Minimum Spanning Tree (Prim & Kruskal)

Launch Simulator

Random planar points, complete Euclidean-weighted graph: step through Prim from a root or Kruskal with union–find; compare total MST weight.

RRT Path Planner (grid)

About this model

How it works

Frequently asked questions

Related simulators

Holonomic 2D Hovercraft MPC (MPPI)

Maze Generators + A* (Grid)

ADC / DAC (Sampling)

A* / Dijkstra Pathfinding (Grid)

Thin-Walled Pressure Vessel Stress

Minimum Spanning Tree (Prim & Kruskal)

RRT Path Planner (grid)

About this model

How it works

Frequently asked questions