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.