Autoware 2.0 makes learned planning a selectable component Autoware 2.0 makes learned planning a selectable component

A planner boundary comes first

Autoware’s architecture separates trajectory generation from choosing the trajectory sent to vehicle control. A generator can be a conventional planner using maps and perception, or a learned model producing candidate paths. The intended selector checks proposals against constraints and ranks them. In the delivered configuration, the launch setting chooses between rule-based planning and the Diffusion Planner. The learned path runs through a trajectory modifier, which processes candidates and forwards the first to the planning validator. The rule-based path also reaches that validator. This gives developers a defined integration point for changing how a path is proposed while keeping the downstream control connection.

A model package solves a different problem

NVIDIA’s August 4 Alpamayo 2 Super documentation describes a model-centered alternative for autonomous-driving development. Its reasoner processes camera video, language context and prior motion; a diffusion-based Action Expert converts the representation into a future trajectory. The model can also produce reasoning traces, high-level maneuvers, grounded scene answers and training labels. NVIDIA describes uses as an offline teacher, evaluation critic and data engine, alongside customization. Its AlpaSim workflow repeatedly applies actions and generates new observations, exposing effects that recorded-scene comparisons miss. These are different starting points: Autoware organizes a vehicle software system, while Alpamayo supplies learned behavior and development outputs around a model.

The upgrade includes model housekeeping

The 2.0.0 release moves Foundation models and datasets to Hugging Face, with fixed versions downloaded through the artifacts installation role. Model variants now occupy separate directories. Existing files downloaded for version 1.9.0 or earlier do not match the new launch layout and need downloading again. The package also removes setup-dev-env.sh in favor of its Ansible installation flow. These changes make model provenance part of the software upgrade, not an unrelated folder copied between workstations. A reproducible experiment needs both the launch configuration and the actual model bundle that configuration expects.

Workspaces carry their own dependency record

The Autoware Index offers a second assembly layer for additional community packages. Its CLI or browser builder writes a repository manifest from a selection, including registered dependencies. A normal source installation does not require it. The documentation specifies Jazzy as the only registered distribution at the 2.0.0 release. Its check command compares the composed workspace with the registry and validation results, reporting failed packages, changed registrations or removed entries. Imported repositories can contain unselected packages, so the documented build can be scoped to the selected package and its dependencies. This is useful integration evidence: it records what was assembled and whether the registered components passed their software checks.

A vehicle blueprint adds operating assumptions

Reference Designs pair a deployment profile with a software stack. The profile records the vehicle, operating conditions and use case; the stack identifies modules, model versions and parameters. The privately owned vehicle guidance describes a phased progression from single-camera assistance toward a Level 4 target. Low-speed guidance covers indoor and outdoor platforms with configurable hardware. Separating these records matters because a successful software build says nothing about whether its sensors, actuators and operating environment match another vehicle. The same planner name can sit inside substantially different systems. For an integrator, the reproducible unit is therefore the configuration plus its operating assumptions, not just the neural-network checkpoint.