DEV Community

Matthew Hill
Matthew Hill

Posted on

Show Dev: I built an on-prem AI parking spot monitor to replace $400 in-ground sensors

#showdev #python #computervision #vue

If you've ever looked into tracking parking lot or driveway occupancy, the hardware solutions out there are surprisingly primitive and expensive:

  • In-ground magnetic sensors: Cost $200–$500 per space, require drilling into asphalt, run on batteries that die, and frequently get torn apart by snowplows and resurfacing crews.
  • Proprietary overhead indicators: Cost thousands per lane and lock you into a single vendor's proprietary cameras.

I wanted a clean, software-defined alternative that runs directly on hardware people already have: standard IP security cameras and RTSP streams.

So I built Lot Vulture -- an on-premises, edge-accelerated parking lot intelligence system.

How It Works

  1. Connect Existing Cameras: Hook up any RTSP, ONVIF, or snapshot IP camera (Hikvision, Dahua, Axis, Ubiquiti, etc.).
  2. Draw Parking Zones: Use an interactive visual polygon canvas to map the four corners of each space in seconds.
  3. Real-Time Edge Inference: An on-device C++ ONNX engine tracks occupancy and streams live status over WebSockets to a dashboard.
  4. Trigger Automations: Stream occupancy to Home Assistant, digital signage, or relays via MQTT and Webhooks.

Lot Vulture Demo

The Tech Stack

  • Frontend: Vue 3, Vuetify, and Vue-Konva (for high-precision polygon drawing on live camera frames).
  • Backend: Python 3.12, FastAPI, SQLAlchemy, SQLite + LMDB blob storage for historical video snapshots.
  • Inference Engine (vulturevision): C++ ONNX Runtime with native DirectML on Windows and CUDA on Linux, with optimized CPU fallback.
  • Deployment: Standalone Windows native installer (.exe) + Docker / Docker Compose.

The Vision Pipeline: Single-Pass FPN vs. Naive YOLO

When people think about parking detection, the instinctive approach is to grab YOLO or crop every parking space and run 50 separate classifications. In production, that falls apart quickly:

  1. The Overlap Problem: A tall truck or SUV parked in spot #1 casts a bounding box that overlaps spot #2, tricking standard object detectors into marking the adjacent empty spot as occupied.
  2. Perspective Distortion: Real-world security cameras shoot at steep, oblique angles. Real parking spots are skewed quadrilaterals, not neat axis-aligned bounding boxes.
  3. Inference Overhead: Cropping and running 50 to 100 individual space crops per frame crushes CPU performance.

Instead of cropping or relying on loose bounding boxes, Lot Vulture runs a single-pass Feature Pyramid Network (FPN) over the full image.

The network extracts multi-scale feature maps across the entire scene in one forward pass. The engine then samples features directly within your custom user-drawn polygon ROIs (Regions of Interest).

This means inference time stays virtually flat whether a camera is monitoring 5 spaces or 150 spaces, while remaining immune to adjacent-vehicle bounding box bleed.

Eliminating False Flickers (Hysteresis)

One of the biggest issues with naive computer vision in outdoor surveillance is lighting shifts: passing tree shadows, rain, or transient car headlights will make a parking space "flicker" between occupied and vacant every few seconds.

To solve this, Lot Vulture implements dual-threshold hysteresis:

  • A space must exceed a high confidence threshold (e.g., >85%) to transition from Vacant to Occupied.
  • It must drop below a separate low threshold (e.g., <20%) to transition back to Vacant.

This ensures rock-solid, sticky transitions even during dusk, downpours, or snow.

Visual Timeline Scrubbing

Instead of just spitting out binary logs, Lot Vulture keeps a visual history. You can scrub back through every minute of the day with second-by-second precision to see the exact snapshot when a vehicle arrived or vacated a space—making parking dispute resolution trivial.

Try It / Star It

The Community Edition is free and source-available for on-prem CPU monitoring. A commercial tier is available for facilities needing GPU acceleration and high-accuracy models.

I'd love to hear feedback from other developers on the architecture, hysteresis logic, or features you'd like to see added!

Top comments (0)