GitHub repository  |  Sampling-based motion planning with GPU acceleration

Overview

This project implements and benchmarks sampling-based motion planning algorithms — PRM, RRT, and RRT* — with CUDA-accelerated variants for the computationally expensive distance and collision-checking steps. The goal is to speed up path planning in environments ranging from simple open spaces to procedurally generated obstacle fields.

The pipeline builds a configuration-space graph by randomly sampling points, connecting nearby nodes, and checking edges for collisions against rectangular and polygonal obstacles. Once a path from start to goal is found, the planner returns the route and its cost.

Algorithms and environments

The project supports four algorithm modes and four environment types:

• Algorithms: RRT, RRT*, RRT (GPU), RRT* (GPU)
• Edge types: Straight-line or Dubins curves (for non-holonomic vehicles)
• Environments:
  • Simple — Two rectangular obstacles in an open space.
  • Complex — Seven obstacles with tighter passages.
  • Complex pro — Procedurally generated convex-hull obstacles with random start/goal pairs. Supports obstacle merging for denser layouts.
  • Blocked — A single large obstacle for stress-testing replanning.

Example usage:

python CPP.py --alg rrt_star --env complex

GPU acceleration

The CUDA variants offload the most expensive operations — pairwise Euclidean distance computation and collision checking across large batches of sampled points — to the GPU using Numba CUDA kernels. This is especially beneficial in the complex pro environment, where hundreds or thousands of iterations are needed to find a feasible path through dense, randomly generated obstacle fields.

The project logs per-iteration timing and total planning time, and can export results to Excel for benchmarking across seeds, environments, and algorithm choices.

Connection to agriculture

Path planning is not just a robotics exercise — it sits at the center of autonomous field operations. In precision agriculture, a robot or implement needs to navigate row crops, avoid obstacles (trees, rocks, irrigation equipment), and reach specific locations in the field efficiently. Sampling-based planners like RRT* are well-suited to this because fields are semi-structured but not perfectly predictable: rows provide general direction, but local conditions (wet spots, fallen branches, terrain variation) create dynamic obstacles.

GPU acceleration matters here because agricultural machines often need to replan in real time. A sprayer or scout robot that detects a new obstacle — or receives an updated target location — cannot wait seconds for a CPU-only planner to converge. Faster planning means the machine can react to changing field conditions without stopping.

Weed identification → path planning → actuation

A concrete pipeline I have been building toward connects perception, planning, and action in the field:

1. Perception — Weed identification. I previously built WeedNet, a self-supervised classifier pretrained on millions of plant images from iNaturalist, deployed as a REST API (WeedId) for field-level weed species identification from photos. Given a camera image, the model returns the weed class and a confidence score.
2. Localization. The detected weed location is mapped to GPS or local field coordinates (via the robot's camera extrinsics and a field map).
3. Path planning. A motion planner — like the CUDA-accelerated RRT* in this project — computes a collision-free route from the robot's current position to the weed target, respecting row geometry, turn radius (Dubins edges), and static obstacles.
4. Actuation. The robot follows the planned path and triggers a spot-spray or mechanical removal at the target location, treating only the identified weed rather than broadcasting chemicals across the entire field.

This "identify → plan → act" loop is the same pattern as the VLA driving agents in my other playground projects, but applied to real agricultural machinery. Perception tells you what and where; path planning tells you how to get there; actuation closes the loop.

The CUDA path planning work provides the planning layer of that stack. By benchmarking GPU vs. CPU planners across environment complexities, I can choose the right trade-off between planning speed and path quality for field deployment — where replanning latency directly affects how quickly a robot can treat newly detected weeds.

Future work

• Integrate Dubins-curve planning for non-holonomic field robots (tractors, row-followers).
• Feed live weed detection coordinates from WeedNet into the planner for end-to-end field demos.
• Benchmark replanning latency under simulated field conditions (row corridors, dynamic obstacles).
• Explore multi-target planning: given a set of detected weeds, compute an efficient treatment tour.

Back to home