Vision Pilot: an Apache-2.0 L2 ADAS stack that runs on one front camera and no HD map
Free and fully open-source L2 ADAS stack powered by End-to-End AI technology
At a glance
- What is it?
- Vision Pilot packages ACC, AEB, LKAS and single-lane hands-free highway autopilot into a C++ codebase with ONNX Runtime inference and an optional ROS2 interface. The interesting design decision is a hybrid end-to-end architecture that runs perception models and end-to-end models in parallel, and the interesting constraint is that the repository is built for OEM and Tier-1 integration, not for a weekend retrofit.
- Who is it for?
- Vision Pilot is aimed at automotive OEMs and Tier-1 suppliers integrating L2 features into series production passenger cars, with optional bus and truck use cases, and at researchers who want open model weights for end-to-end driving experiments.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 4 days ago.
- What is it written in?
- Mainly C++, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Vision Pilot actually covers, and the camera it assumes
Vision Pilot is a C++ L2 ADAS stack from the Autoware Foundation, released under Apache-2.0. The README lists the features it targets: ACC (adaptive cruise control), FCW (forward collision warning), AEB (automatic emergency braking), LKAS (lane keep assist), LDW (lane departure warning), ISA (intelligent speed assist), and a single-lane hands-free highway autopilot mode. That is the entry tier of L2, not a general driving automation platform. The sensor specification is deliberately narrow: one front-facing monocular camera with 52 to 55 degrees horizontal field of view and 1MP to 2MP resolution. No radar, no lidar, no second camera is mentioned. The README also states that Vision Pilot does not require 3D high definition maps and operates in a mapless mode to follow the road in real time. The stated audience is automotive OEMs and Tier-1 suppliers doing series production passenger cars, with optional adoption for buses and trucks in transport and logistics. Read that audience statement carefully, because it shapes every build and integration decision in the repository.
The hybrid end-to-end split, and why it is two paths and not one
The architecture is described as a Hybrid End-to-End AI Architecture in which data is processed in parallel by perception AI models for safety and end-to-end AI models for performance. That parallelism is the load-bearing idea. A pure end-to-end network maps pixels to control, which makes the intermediate reasoning hard to inspect. Vision Pilot instead keeps a perception path that can be checked and an end-to-end path that carries the driving behaviour, and the README frames the split explicitly as safety versus performance. Three open-source models from the Autoware Foundation supply the intelligence: AutoSpeed for closest in-path object detection, AutoSteer for ego path future waypoint detection, and AutoDrive for end-to-end distance and in-path object presence detection plus road curvature estimation. The model boundaries tell you where the interfaces sit. AutoSpeed answers what is in my lane and how far away, AutoSteer answers where my path goes next as waypoints, AutoDrive answers presence and curvature end to end. The documentation does not state how the two paths are arbitrated or which one wins when they disagree, and that is the question an integrator should ask before trusting the safety argument.
Building Vision Pilot from source with ONNX Runtime and CMake
The README gives three build routes. The first is from source. Clone the repository, then download ONNX Runtime from the Microsoft releases page, then configure with CMake pointing at the runtime root. The documented sequence is a mkdir build and cd build, followed by cmake -DONNXRUNTIME_ROOT=<ONNX_RUNTIME_ROOT_PATH> ../ and then make, which produces a VisionPilot executable inside the build directory. Two optional flags change what gets compiled. Adding -DENABLE_ROS2_INTERFACE=ON builds the ROS2 interface. Adding -DENABLE_OCCUPANCY=ON enables an optional Occupancy BEV window, described as a heuristic 3D or bird's-eye panel beside the HUD, off by default, with orbit, pan and zoom controls documented in VisionPilot/modules/visualization/README.md. For CPU-only builds the README pairs -DGPU=OFF with the ONNX Runtime root flag. Debian packaging uses cpack -G DEB after the build. Note the ONNX Runtime version is not pinned in the material; you supply the path, so the version you download is your choice and your risk.
Running the OpenLane sample and the config keys that matter
Open-loop testing uses sample data from a Google Drive folder containing video assembled from OpenLane sequences plus vehicle speed data extracted from the dataset. Configuration happens in two files. In vision_pilot.conf inside the config directory, set source.mode = video. In vision_pilot_test.conf, set source.input_video to the video file path and source.input_vehicle_speed to the speed file path. The README adds a note that when VisionPilot is built from source, the config files should be updated before the build, which is unusual and worth respecting: the configuration is read at build time in that workflow, so editing after make may not take effect. Execution is then ./VisionPilot from inside the build directory. There is also a pre-built Debian package route, which the README recommends when a new system installation is needed and CUDA dependencies are not yet installed. The material is truncated before the package install command completes, so treat the exact install invocation as something to confirm on the releases page.
What the repository does not settle: arbitration, hardware and certification
Several things a production integrator needs are absent from the supplied material. The README claims a productionizable and safety certifiable implementation, but certification is a process outcome, not a property of source code, and no certificate, safety case or ISO reference appears here. There is no stated target compute platform, no latency budget, no frame rate, and no memory footprint, so you cannot size an ECU from this README. The parallel safety and performance paths are described but not resolved: the documentation does not say how a disagreement between the perception models and the end-to-end models is handled, and that is exactly the failure mode a safety reviewer will probe. The mapless design is a real advantage for coverage, since it removes the HD map from the cost and maintenance equation, but it also means the system's behaviour depends entirely on what the camera sees, with no prior map to fall back on in ambiguous geometry. And the camera window of 52 to 55 degrees horizontal is narrow; the README does not discuss what happens outside it.
How this differs from Autoware's own full-stack autonomous driving
The obvious comparison is Autoware itself, the broader project this repository sits under. Autoware's autonomous driving stack is built around a full sensor suite, typically lidar, cameras and radar, with localization against a map, and it targets higher levels of automation including urban driving. Vision Pilot inverts several of those choices. It runs on one monocular camera, it explicitly does not require HD maps, and it stops at L2 features with a single-lane hands-free highway mode. The model set is also different in kind: AutoSpeed, AutoSteer and AutoDrive are end-to-end learned components, whereas a classical Autoware pipeline is assembled from modular perception, prediction and planning nodes with explicit interfaces. The trade is coverage and cost against verifiability. A camera-only mapless stack is cheaper to deploy and works where maps are stale or absent, but it gives a safety engineer far fewer independent signals to cross-check than a lidar-plus-map stack does. If your requirement is urban autonomy, Vision Pilot is the wrong tool, and the README does not claim otherwise.
Licence, maintenance and the cost of following three model repositories
The codebase is Apache-2.0, which the README describes as permissive and usable for commercial and research purposes, and it states that the AI model weights are included in the open release. Apache-2.0 covers the repository's code and carries the usual patent grant and notice obligations; it does not automatically settle the terms attached to model weights hosted in other repositories, and AutoSpeed, AutoSteer and AutoDrive live in three separate Autoware Foundation repositories. Check those licences separately. On maintenance, the release cadence visible here is fast: v1.0 in July 2026, v1.1 later that month, v1.2 in August 2026, with repository activity continuing into September 2026. Three releases in roughly two months is healthy for a young project and also a signal that interfaces and config keys may still move. The upgrade cost is concentrated in two places: the ONNX Runtime version you pin, since the build takes an explicit root path and no version, and the config file format, since keys like source.mode and source.input_video are read from files you maintain per deployment. Budget for re-validating model behaviour, not just recompiling, on each version bump.
Editorial conclusion
Vision Pilot is aimed at automotive OEMs and Tier-1 suppliers integrating L2 features into series production passenger cars, with optional bus and truck use cases, and at researchers who want open model weights for end-to-end driving experiments. It is not the right starting point if you want a driver-assistance feature running on a dashcam or a dev board this week: the build assumes ONNX Runtime is fetched and pointed at manually, the documented sample data is a Google Drive folder of OpenLane video, and the README's own claim of being safety certifiable is a design intent, not a certificate you can ship against. Before adopting it, verify three things in the repository itself: whether the ONNX Runtime version you download matches what the C++ inference code expects, whether the ROS2 interface build (ENABLE_ROS2_INTERFACE=ON) covers the messages your vehicle bus needs, and whether the model weights for AutoSpeed, AutoSteer and AutoDrive come with the terms your legal team requires, since the weights are hosted in three separate repositories.
Community notes