Mapless Autonomous Parking
Isaac Sim · ROS 2 Humble · Autoware Universe · HuVILab
This project targets real-time parking without prebuilt pointcloud/vector maps. The stack builds local occupancy information online, plans parking motion from occupancy-only inputs, and executes low-speed forward/reverse maneuvers through a custom addon layer on top of an existing vehicle stack.
Problem
- No prebuilt parking map available.
- The addon had to fit around an existing vehicle/control stack instead of replacing the whole system.
- Parking had to work under low-speed, reverse-capable, compute-bounded conditions with practical ROS 2 timing and visualization needs.
Architecture
Perception Adapterpointcloud field/frame adaptation for occupancy-grid input
→
OGM Layeroccupancy accumulation, ROI handling, decay for stale cells
→
Planneroccupancy-only parking trajectory generation
→
Trajectory Processingresampler, filler, direction-aware preparation
→
Follower + UIparking tracking, RViz control, CLI/RViz debug
What I Built
- Addon package composition that layers autonomous parking and FAST_LIO linkage onto an existing validated stack.
- Pointcloud adapter to make LiDAR data usable by the occupancy-grid path.
- OGM accumulator for occupancy-map accumulation and post-processing.
- Parking planner driven by occupancy grid, current pose, and goal pose.
- Trajectory resampler / filler / follower for parking-specific post-processing and execution.
- RViz control path with interactive-marker-based enable/cancel UI.
- ROS 2 integration work including QoS handling, topic alignment, and launch composition around the existing vehicle stack.
Built vs Used
- Used: ROS 2 Humble, Autoware components, Isaac Sim, FAST_LIO-linked localization path, existing vehicle/control stack.
- Built: compatibility layer, occupancy accumulation path, parking planner integration, trajectory processing nodes, parking follower path, RViz control interface, launch integration.
What This Project Proves
- Autonomy-stack composition: I can work around an existing stack and add the missing layers instead of needing a blank slate.
- Geometry and runtime awareness: I care about frames, trajectories, direction changes, QoS, and operator control paths together.
- Prototype depth: this is more than a tutorial assembly; it reflects actual system wiring, message adaptation, and execution logic.
Evidence
- The addon package explicitly separates its scope from the base vehicle/control stack and documents the nodes it adds.
- The launch path wires occupancy-grid generation, planner output, trajectory processing, follower integration, and RViz interaction into one runnable parking stack.
- The public portfolio now shows the parking video directly so the project is not just described as text.
Current Limits
- This page does not yet publish a public repo or rosgraph-level artifact, so the strongest proof remains the architecture summary and demo video.
- I am describing the control layer conservatively here as a parking follower path rather than over-claiming a single named controller variant.