Projects
Representative Projects
Four projects covering solver design, real-vehicle autonomy integration, field telemetry runtime, and analysis-tool construction. If you want the summary first, start from Capabilities.
ballistic-solver (C/C++ · Python · Unity/C#)
Simulate-first intercept optimizer for moving targets under gravity and quadratic drag (+ optional wind). It integrates nonlinear projectile dynamics (RK4) and solves launch angles (θ, φ) using an auxiliary-solution-induced residual with Levenberg–Marquardt, line search, and Broyden-style Jacobian refinement.
What I built
- Dynamics: fixed-step RK4 with quadratic drag (+ wind as air-velocity)
- Residual method: drag-inclusive miss transformed through an auxiliary vacuum ballistic response
- Numerical optimization: auxiliary residual → LM (damped least squares) + line-search/lambda tries
- Speed: Broyden-style Jacobian refinement to reduce full re-linearizations
- Robust outputs: explicit status/message + best-effort solution even on non-ideal convergence
- Deployment: stable C ABI (FFI-ready), PyPI package with prebuilt binaries, Unity/C# via P/Invoke
Mapless Autonomous Parking (Hyundai Ioniq · ROS 2 Humble · Autoware Universe · FAST-LIO)
Real-vehicle mapless autonomous parking on a Hyundai Ioniq without prebuilt pointcloud/vector maps: FAST-LIO odometry → C++ LiDAR occupancy-grid updates → RViz goal-pose planning → delay-aware trajectory following → Ioniq CAN command path.
What I built
- Real-vehicle integration: connected the parking system to an existing Hyundai Ioniq research platform
- FAST-LIO bridge: LiDAR-inertial odometry aligned into the vehicle localization and TF path
- Autoware compatibility layer: pointcloud fields/frame adaptation + self-cropping + ground filtering
- Occupancy mapping: native C++ pointcloud occupancy-grid updates with timestamp pairing, log-odds sparse tiles, and decay back to unknown for stale cells
- Compute-bounded replanning: occupancy tiling + sliding-window ROI updates to reduce cell count and keep replanning tractable
- Planning without vector maps: custom node using Autoware freespace planning algorithms from occupancy-only + vehicle constraints
- Trajectory processing: resampling / filling and continuous-reference preparation for low-speed forward/reverse maneuver tracking
- Execution layer: delay-aware follower using measured steering/longitudinal response delay for pose prediction, velocity prediction, and separate reference preview
- Ioniq vehicle interface: Autoware-compatible command output connected to the vehicle CAN interface
- Real-time engineering & debugging: timing/backlog tuning, RViz2 visualization (occupancy grid/trajectory/vehicle), and CLI status reporting
Racing Telemetry Stack (Python · Raspberry Pi · ZED-F9R · RTK/NTRIP · Cloudflare Worker)
Car-side telemetry runtime for racing data collection, built around a Raspberry Pi and u-blox ZED-F9R GPS/IMU receiver. The system configures the receiver at startup, collects high-rate UBX GPS/IMU messages, injects RTCM correction data from an NTRIP caster, writes buffered CSV/UBX logs, and publishes live debug state to a browser dashboard through a Cloudflare Worker + Durable Object + SSE pipeline.
What I built
- Raspberry Pi runtime: systemd-managed Python collector with boot persistence, automatic restart, environment-based configuration, and pre-start ZED-F9R configuration
- Receiver configuration: automated UART/UBX setup for 20 Hz measurement, NAV-PVT, HPPOSLLH, RAWX, ESF-RAW, MON-HW/RF, and RTCM3 input
- RTK correction flow: NTRIP connection, periodic GGA injection, RTCM queueing, retry handling, and fallback behavior under poor correction availability
- Robust field logging: date-foldered drive logs, GPS/IMU merged CSV output, optional raw UBX capture, buffered writes, and post-processing helpers
- Fault tolerance: serial retry, idle timeout detection, invalid GPS jump/speed filtering, frame/PVT timeout handling, and optional receiver reconfiguration
- Remote monitoring: Raspberry Pi posts live debug packets to Cloudflare Worker; Durable Object stores latest state and streams updates to browser clients using SSE with Leaflet map visualization
- Wireless operations: Git/SSH/Tailscale-based update workflow for deploying package changes to the Raspberry Pi
Racing Analyze GUI (MATLAB · Telemetry Analysis · Driver Coaching)
Segment-based racing telemetry analysis workbench for comparing multiple logged runs, visualizing driver/vehicle behavior, and supporting coaching-oriented inspection for circuit driving. Developed and used together with the telemetry collection workflow for Luxon Racing Team in the GTA class of the O-NE SUPERRACE CHAMPIONSHIP.
What I built
- Fast track/core build: GPS-fix-based track core / segment reference generation for repeated run comparison
- Fast multi-log workflow: efficient loading and caching of multiple logged runs, enabling quick switching across segments after a single analysis pass
- Segment-wise comparison: gate/segment-based run slicing across All / S0 / S1..Sn / S(n+1) for aligned comparison of the same track region
- Interactive replay: time-slider-based replay with play / pause / stop / speed control and pane-aware marker updates
- Flexible visualization modes: XY, TS, MAP, POLAR, KDE, GG views for telemetry inspection from multiple perspectives
- Sensor-channel flexibility: arbitrary logged channels can be assigned to x / y / color, enabling broad exploratory analysis across vehicle states and driver inputs
- Signal conditioning: smoothing and abnormal-data interpolation support for more stable visualization and comparison
- Pane-level workflow tools: per-pane rerender and pop-out windows for focused inspection without rebuilding the full workspace
- Metrics extraction: segment-level metrics such as segment time, velocity statistics, and acceleration-related indicators for quick run ranking and review
- Practical use case: supports visualization assistance and coaching workflow for real racing data analysis