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)

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.

Other simulators in this category — or see all 31.

View category →

NewSchool

Differential Drive Odometry

ω_L, ω_R → v, ω with two-wheel kinematics; integrate pose and watch dead-reckoning drift from biased wheel radii / track and noisy rate readings.

Launch Simulator

NewUniversity / research

Holonomic 2D Hovercraft MPC (MPPI)

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.

Launch Simulator

NewUniversity / research

3-Link 3D Arm Inverse Kinematics (CCD)

Continuation of two-link-arm-ik into 3D: 3 revolute joints (yaw + 2 pitches) solved with constrained Cyclic Coordinate Descent. Drag target in 3D or follow a helix / lemniscate / figure-8 trajectory.

Launch Simulator

NewUniversity / research

Bicycle Model & Stanley Controller

Kinematic bicycle (rear-axle): δ = θ_e + atan2(k_e·e, v) Stanley path-following law. Pick oval, race-track, lemniscate, sine-road or S-curve and tune k_e, v, L; live cross-track e(t) and steering δ(t).

Launch Simulator

NewSchool