Skip to content
RS-S03Systems / HardwareApr 2026 to presentOngoing

Custom Car Vision System

I gave my car a camera view it never shipped with, and a local AI vision stack to go with it.

Overview

Off-the-shelf dashcams pushed me into building this. They are closed boxes, tied to a vendor's cloud app, and each one does exactly one job. My car (which I keep anonymous here) now carries a single self-built platform that does two things at once: it puts a live camera view on the car's own factory screen, and it runs several AI vision jobs off the same feeds, with everything processed in the car and nothing sent to anyone's cloud.

Two computers, two jobs

The build splits along a clean line. An ESP32 with an SN65HVD230 CAN transceiver handles the car side: it injects messages onto the CAN bus that feeds the head unit, which is how the factory display is persuaded to show a camera view the car never shipped with. That bus is undocumented and proprietary, so the messages have to be found by capturing and reverse engineering real traffic rather than reading a spec. On the other side, an NVIDIA Jetson Orin Nano Super (8GB, 67 TOPS, an Ampere GPU and a six-core ARM CPU) sits in the boot and runs the vision stack. It is a board built for exactly this: several concurrent vision pipelines on one small device.

The vision pipeline

The core design decision is to run inference once on the live video and pull multiple outputs from that single pass, instead of stacking single-purpose gadgets. Two USB cameras (front windscreen, rear window) feed OpenCV and GStreamer for continuous loop dashcam recording. The same frames go through YOLO-family detection models: a number-plate stage with OCR that logs plates and timestamps to a local SQLite database, and a traffic-light state detector, with the longer-term goal of a countdown display on a small dash screen (that part needs GPS and local signal-timing data, so it comes later). I deliberately started with pretrained models and treat this as an inference problem first; fine-tuning only happens if accuracy demands it. My ML background before this was API-level (Whisper, OpenAI, Claude), and half the point of the project is learning to run models on my own hardware.

The physical build

Nothing is drilled or spliced. The cameras are USB rather than CSI ribbon because the cables have to run the full length of the car; they tuck along the headliner and trim back to a powered USB hub in the boot. Storage is a 512GB-class SSD holding the rolling footage and the detection database, with older footage archived to my homelab TrueNAS box. Power is an EcoFlow River 3 in the boot, so nothing touches the car's 12V system: the car drives roughly three to four hours a day, and at night the battery comes out to recharge at home while footage offloads. The bill of materials lands around £350 to £480. I costed a Raspberry Pi 5 with a Hailo-8L accelerator at roughly £130 to £150 as a cheaper proof of concept, but the Jetson's headroom for concurrent models is what lets this work as one platform instead of several.

Built in phases

This is an ongoing build and I am doing it in deliberate stages: a bench proof of concept with one camera and a pretrained plate model, then the front camera install with a week of real driving to check accuracy and storage burn, then the rear camera and unified detection logging with the TrueNAS archival job, then the traffic-light module. Stretch goals after that: emergency vehicle detection and custom camera housings printed on my Bambu A1. Any plates in published footage get blurred, including my own.

The hardest problem

Two hard problems share one build. The first is the car's CAN bus: it is undocumented and proprietary, and the only way to find the messages that trigger the camera view on the factory display is to capture real bus traffic, work out which frames matter, and spoof them exactly. The risk is not academic. Injecting the wrong messages can fault the head unit, so the work starts from captured traffic rather than guesswork. The second problem is compute: plate detection with an OCR stage, traffic-light state detection and continuous loop recording all have to share a single 8GB edge device in real time without dropping frames. The answer there is architectural rather than brute force: run inference once on the live feed and extract every output from that one pass, instead of running a separate pipeline per feature.

Start a project

Want something built like this?

Everything on this page was designed, built and hosted by one person. Tell me what you need and I reply with scope, cost and timeline, usually within two working days.

Custom Car Vision System · Raafay Siddiqui Projects