GO — Healthy across the board

• Last commit 4w ago
• 24+ active contributors
• Distributed ownership (top contributor 35% of recent commits)
• Apache-2.0 licensed
• Tests present
• ⚠ No CI workflows detected
• ⚠ Scorecard: default branch unprotected (0/10)

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests, cross-checked against OpenSSF Scorecard}

Apollo is a production-grade autonomous driving platform that integrates perception, planning, control, and vehicle communication into a unified stack. It provides a complete self-driving solution tested on real vehicles (Lincoln MKZ) with hardware-accelerated perception (CUDA 11.8), real-time planning, and by-wire vehicle control—not just simulation or a library, but a deployable system. Monorepo structure: collection/ subdirectories organize modules (canbus/, calibration/, common-msgs/, audio/, bridge/) each with Starlark BUILD files and cyberfile.xml configs. Build system uses Bazel (WORKSPACE root config) with C++ as core (23.7 MB), Python (1.7 MB) for tooling/scripts, and TypeScript (1.8 MB) for web frontends. Proto messages in common-msgs/ define inter-module contracts.

Autonomous vehicle engineers and platform developers who need to build, test, and deploy end-to-end self-driving stacks on real hardware. This includes perception engineers tuning neural models, planning specialists implementing motion algorithms, and integration engineers configuring production vehicles with Apollo's control modules.

Actively developed and production-ready: the codebase shows recent major upgrades (November 2024 CUDA 11.8 bump for Ada Lovelace GPUs), multi-version support (18.04, 20.04, 22.04 Ubuntu), and strong infrastructure (Bazel build system, Docker containerization, CI via TeamCity). The 23.7 MB of C++ code and comprehensive module structure (canbus, planning, perception, calibration) indicate mature, deployed systems.

Significant complexity and hardware coupling: the platform requires specific NVIDIA drivers (≥520.61.05) or AMD ROCm, tight GPU dependencies (LibTorch 1.11.0 arm64 vs 1.7.0 x86_64), and multi-version state management (breaking changes noted in 2024-11 prerequisites requiring cache wipes). Vehicle safety-critical code (brake-by-wire, steering) demands rigorous testing; the reliance on external hardware (Lincoln MKZ) limits reproducibility in CI.

Active 2024 maintenance: CUDA upgraded to 11.8 for modern GPU support, LibTorch version harmonization across platforms (1.11.0 arm64), Docker container refresh, and deprecation of older driver versions. CI infrastructure uses TeamCity (.teamcity/) with coverage tracking (coverage_diff.py, coverage_lines.py), indicating ongoing regression prevention.

# Clone and initialize
git clone https://github.com/ApolloAuto/apollo.git
cd apollo
# Build via Bazel (see WORKSPACE and BUILD)
bazel build //...
# Run in Docker container (recommended)
./docker/scripts/dev_start.sh
./apollo.sh build

Daily commands:

# In Apollo dev container (post docker/scripts/dev_start.sh)
./apollo.sh build          # Build all modules via Bazel
./apollo.sh test           # Run test suite
./apollo.sh run_simulation # Launch simulator (if available)
# Or specific Bazel targets:
bazel run //path/to/module:target

• WORKSPACE — Defines the Bazel workspace and all external dependencies; critical for understanding build configuration and dependency management across the autonomous driving platform.
• BUILD — Root-level Bazel build configuration that orchestrates compilation of all major modules (perception, planning, control, localization).
• collection/cyber/BUILD — Cyber framework is Apollo's core message-passing middleware; this BUILD file exposes the RPC and pub/sub infrastructure used by all autonomous modules.
• .bazelrc — Bazel runtime configuration; contains compiler flags, sanitizers, and platform-specific settings essential for reproducible builds across different hardware.
• CPPLINT.cfg — Code style enforcement configuration; enforces naming conventions and coding standards that all C++ contributors must follow.
• apollo.sh — Main entry point script for building and running Apollo; orchestrates the entire development workflow including Docker setup and Bazel invocation.
• collection/perception/BUILD — Perception module BUILD file; critical for understanding the sensor fusion and object detection pipeline in the autonomous stack.

Add a new perception algorithm

1. Create a new detector subdirectory in collection/perception/ with your algorithm implementation (collection/perception/BUILD)
2. Define the perception message proto in collection/common-msgs/ for your detector output (collection/common-msgs/BUILD)
3. Implement the Cyber component that subscribes to sensor inputs (camera/lidar) and publishes detection results (collection/cyber/BUILD)
4. Register your detector in the perception pipeline manager within the perception module (collection/perception/BUILD)
5. Add visualization hooks in Dreamview to display your detection outputs in the web dashboard (collection/dreamview/BUILD)

Add a new planning algorithm

1. Create a new planner class in collection/planning/ implementing the motion planning interface (collection/planning/BUILD)
2. Subscribe to perception outputs, prediction trajectories, and localization via Cyber pub/sub (collection/cyber/BUILD)
3. Publish trajectory and path messages using message definitions from collection/common-msgs/ (collection/common-msgs/BUILD)
4. Register your planner in the planning module's configuration and task manager (collection/planning/BUILD)
5. Add planning visualizations (path, trajectory, decision states) to Dreamview (collection/dreamview/BUILD)

Add a new vehicle driver/CAN interface

1. Create vehicle-specific driver implementation in collection/drivers/ for your vehicle model (collection/drivers/BUILD)
2. Implement CAN message protocol handlers for your vehicle in collection/canbus/ (collection/canbus/BUILD)
3. Define vehicle control proto messages in collection/common-msgs/ (steering, throttle, brake) (collection/common-msgs/BUILD)
4. Register your driver in the driver factory and add hardware initialization in collection/drivers/BUILD (collection/drivers/BUILD)
5. Add vehicle health status publishing to collection/monitor/ for real-time monitoring (collection/monitor/BUILD)

Add a new data collection or calibration tool

1. Create your tool implementation in collection/calibration/ or collection/external-command/ (collection/calibration/BUILD)
2. Implement Cyber components to subscribe to raw sensor data streams (collection/cyber/BUILD)
3. Integrate with smart-recorder for data capture and playback support (collection/smart-recorder/BUILD)
4. Add UI controls in Dreamview for tool configuration and execution (collection/dreamview/BUILD)

• Bazel Build System — Supports hermetic, reproducible builds across heterogeneous hardware (x86, ARM); enables fine-grained dependency tracking critical for safety-critical autonomous systems.
• Cyber Middleware (RPC/Pub-Sub) — Low-latency, deterministic message passing required for real-time sensor fusion and actuation loops; decouples modules for independent testing and deployment.
• Protocol Buffers — Language-agnostic message serialization for interoperability across C++, Python, and visualization layers; compact binary format essential for high-frequency sensor data.
• C++ Core Stack — Performance-critical perception, planning, and control loops require low latency and predictable memory management; mature ecosystem for autonomous driving (OpenDRIVE, sensor SDKs).
• Web-based Dashboard (Dreamview) — Real-time monitoring and debugging without heavyweight IDE; enables remote operation and vehicle state visualization for engineers and safety operators.

• Modular pub/sub architecture over tightly-coupled components

  • Why: Enables independent development and testing of perception, planning, and control modules; allows hot-swapping algorithms.
  • Consequence: Introduces message latency and potential data consistency issues across asynchronous module boundaries; requires careful synchronization logic.

• Cyber RPC for inter-module calls instead of direct C++ function calls

  • Why: Supports distributed deployment across multiple machines; allows module isolation for safety and fault containment.
  • Consequence: Higher serialization overhead and network latency compared to in-process function calls; adds complexity to debugging.

• Bazel + Starlark scripting for build automation

  • Why: Reproducible builds and precise dependency resolution; scales to 600+ files with clear module boundaries.
  • Consequence: Steeper learning curve for contributors familiar only with CMake or Make; Starlark syntax unfamiliar to many C++ developers.

• HD map-based localization and planning instead of pure vision/LiDAR SLAM

  • Why: Enables precise lane-level control and deterministic behavior; reduces computational load on embedded hardware.
  • Consequence: Requires pre-built HD maps for all deployment regions; reduces adaptability to unmapped environments.

• Does not implement end-to-end learning (neural network training pipeline) — perception modules use classical CV and LiDAR algorithms, not DNNs for core detection
• Does not provide real-time Linux kernel or hardware-in-

GPU driver pinning: NVIDIA driver ≥520.61.05 or ROCm ≥5.1 is mandatory; older drivers cause silent CUDA errors. LibTorch version mismatch: arm64 uses 1.11.0, x86_64 uses 1.7.0; mixing breaks inference. Bazel cache invalidation: CUDA/LibTorch changes require rm -rf /apollo/.cache/{bazel,build,repos} before rebuild—easy to miss. Hardware-in-loop: many tests assume Lincoln MKZ or compatible by-wire vehicle; CAN protocols are vehicle-specific, not portable. Docker GPU access: NVIDIA Container Toolkit must be installed separately; omitting causes GPU-only code to silently fall back to CPU. Starlark build files: cyberfile.xml and BUILD files use custom rules; syntax is less documented than CMake.

• Sensor Fusion — Apollo integrates multiple sensor streams (LiDAR, camera, radar) into unified perception; understanding multi-sensor calibration and synchronization is core to the platform.
• Motion Planning (Path + Speed Trajectories) — Apollo's planning modules generate both spatial path and temporal speed profiles; understanding reference line-based planning is critical for contributing to motion control.
• CAN Bus Protocol — Vehicle control in Apollo is achieved via CAN frames sent to by-wire systems; understanding frame IDs, DBC files, and message semantics is essential for canbus/ module work.
• CUDA Kernel Optimization for Perception — 428 MB of CUDA code in the repo accelerates perception; understanding GPU memory management and kernel launches is needed for performance tuning.
• Protobuf Message Serialization — Apollo uses Protocol Buffers for inter-module contracts; understanding proto versioning, field numbering, and backward compatibility is essential for schema evolution.
• Bazel Build System (Starlark Rules) — Apollo's entire 23.7 MB C++ codebase and dependencies are orchestrated via Bazel; understanding BUILD rules and WORKSPACE is mandatory for compilation and debugging.
• Real-Time Vehicle Control Loops — Apollo must close perception-planning-control loops at fixed rates (typically 10-100 Hz) with deterministic latency; understanding thread synchronization and message queue patterns is critical for safety.

• openPilot/openpilot — Alternative open-source autonomous driving stack; similar end-to-end approach but emphasizes camera-only perception versus Apollo's multi-sensor fusion.
• carla-simulator/carla — Open-source simulator widely used by Apollo developers for testing planning and control without real vehicles; essential companion for CI/validation.
• ApolloAuto/apollo-planning — Standalone planning algorithm library; extracted from Apollo core for easier reuse and testing in isolation.
• bazel-contrib/bazel-skylib — Bazel standard library used by Apollo's build system; understanding it helps debug BUILD file issues and custom Starlark rules.
• grpc/grpc — RPC framework likely used for inter-module communication in Apollo's distributed architecture; understanding proto + gRPC is essential for module integration.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for collection modules (audio, canbus, control, drivers)

The collection/ directory contains multiple autonomous driving subsystems (audio, canbus, control, drivers, etc.) with BUILD files and cyberfile.xml configs, but no visible test files in the provided structure. These are critical safety-adjacent modules. New contributors could add unit tests for core collection modules to improve code reliability and catch regressions early.

• [ ] Audit collection/canbus/ and collection/control/ for existing test coverage (look for *_test.cc files)
• [ ] Create collection/canbus/canbus_driver_test.cc with tests for message parsing and vehicle command handling
• [ ] Create collection/control/control_module_test.cc with tests for trajectory execution and feedback loops
• [ ] Create collection/drivers/driver_base_test.cc with tests for driver initialization and error handling
• [ ] Update collection/*/BUILD files to include cc_test targets that run these tests in CI

Implement missing GitHub Actions workflow for automated Bazel builds on pull requests

The repo uses Bazel (evident from .bazelrc, .bazelignore, WORKSPACE files) and has TeamCity CI config (.teamcity/run_ci.sh), but there's no GitHub Actions workflow visible for PR checks. Modern open-source projects need GitHub Actions for quick feedback to contributors before code review.

• [ ] Create .github/workflows/bazel-build.yml with steps to: install Bazel, run 'bazel build //' on changed packages
• [ ] Create .github/workflows/bazel-test.yml to run 'bazel test //...' with timeout limits to catch failing tests early
• [ ] Configure both workflows to run only on relevant file changes (skip on docs-only changes using path filters)
• [ ] Add GitHub Actions status badges to README.md once workflows pass

Add missing README.md documentation for cyber framework and common-msgs protocol definitions

collection/cyber/ and collection/common-msgs/ have README.md files but their content is not shown; these are foundational layers for the entire Apollo platform (message passing, data types). New contributors should document: supported message types, cyber bus architecture, how to define custom messages, and troubleshooting guide.

• [ ] Expand collection/common-msgs/README.md with: list of core message types (proto definitions), example of defining custom messages, cross-reference to proto file locations
• [ ] Expand collection/cyber/README.md with: cyber RT framework overview, how modules communicate, subscribing/publishing examples, execution model docs
• [ ] Add code examples showing how to: register a new cyber node, publish/subscribe to messages, and handle message serialization
• [ ] Link both READMEs from the root README.md 'Architecture' section for discoverability

• Add TypeScript type definitions for proto message enums in collection/common-msgs/; the 1.8 MB TypeScript codebase likely relies on loosely-typed protobuf JSON, causing frontend bugs.
• Expand CPPLINT.cfg coverage to collection/canbus/ CAN frame definitions; vehicle safety code deserves stricter linting than current rules enforce.
• Create GitHub Actions CI workflows as alternatives to .teamcity/ TeamCity setup; the current CI is proprietary and hard for external contributors to test locally before PR.

The Apollo autonomous driving platform demonstrates moderate security posture based on available file structure. Strengths include presence of code quality tooling, CI/CD pipeline structure, and modular architecture. Critical weaknesses include: (1) lack of visibility into dependency management and potential vulnerable libraries, (2) CI/CD configuration files that may contain secrets, (3) insufficient Docker security hardening visibility, (4) shell scripts and configuration files that commonly contain hardcoded credentials, and (5) complex build system configuration prone to supply chain attacks. For a safety-critical autonomous driving platform, comprehensive security scanning, SCA tools

• Medium · Bazel Build System Configuration Exposure — .bazelrc, WORKSPACE, .bazelignore. The presence of .bazelrc and WORKSPACE files indicates Bazel build system usage. These files may contain sensitive build configurations, paths, or credentials if not properly secured. The .bazelignore file suggests selective ignoring of paths which could mask security-critical files. Fix: Review .bazelrc for any hardcoded credentials or sensitive paths. Ensure build artifacts are not committed to version control. Use Bazel's remote execution features securely with proper authentication.
• Medium · CI/CD Pipeline Configuration Visibility — .teamcity/run_ci.sh, ci.yml, .github/. The presence of .teamcity/run_ci.sh, ci.yml, and .github workflows indicates CI/CD pipeline scripts that may contain secrets, API tokens, or deploy credentials if not properly managed. Fix: Ensure all CI/CD scripts use environment variables or secret management systems (GitHub Secrets, TeamCity credentials) rather than hardcoded values. Audit scripts for credential leaks and implement secret scanning in the pipeline.
• Medium · Docker Configuration Lack of Detail — .dockerignore. While .dockerignore exists, there is no visible Dockerfile in the provided file structure. For an autonomous driving platform, Docker security is critical. Missing Dockerfile visibility makes it difficult to assess base image security, privilege escalation risks, and layer vulnerabilities. Fix: Ensure Dockerfile uses minimal base images (alpine/distroless), runs as non-root user, and implements security best practices. Scan Docker images with tools like Trivy or Snyk regularly.
• Low · Code Format and Linting Configuration Present — .clang-format, CPPLINT.cfg, .prettierrc.json. The presence of .clang-format, CPPLINT.cfg, and .prettierrc.json indicates code quality tooling. However, these are security-adjacent rather than direct security controls. Fix: Extend linting and static analysis to include security-focused tools like clang-analyzer, cppcheck with security flags, or LLVM's AddressSanitizer.
• Low · Limited Visibility Into Dependency Management — Root directory and collection/ subdirectories. No package.json, requirements.txt, pom.xml, or go.mod files are visible in the provided structure. This makes it impossible to assess third-party dependency vulnerabilities for this autonomous driving platform. Fix: Implement Software Composition Analysis (SCA) tools like OWASP Dependency-Check, Snyk, or Black Duck to monitor dependencies. Regularly update and audit all third-party libraries, especially for critical domains like autonomous driving.
• Medium · Potential Hardcoded Credentials in Scripts — collect_pre.sh, .teamcity/*.py. Shell scripts like collect_pre.sh and .teamcity/coverage*.py files are present but content is not provided. These script files commonly contain hardcoded credentials, API keys, or configuration secrets in autonomous driving projects. Fix: Audit all shell scripts and Python files for hardcoded secrets. Use tools like TruffleHog, detect-secrets, or git-secrets to prevent credential commits. Implement pre-commit hooks to catch secrets before they enter the repository.
• Low · Workspace and Build Configuration Complexity — WORKSPACE, WORKSPACE.source. Multiple WORKSPACE files (WORKSPACE, WORKSPACE.source) suggest complex build configurations. This increases the attack surface for supply chain attacks through compromised dependencies or build-time injection. Fix: Document and audit the purpose of multiple workspace files. Implement workspace locking to ensure reproducible builds. Use Bazel's built-in security features like restricted visibility and sandboxed builds.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/ApolloAuto/apollo shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live ApolloAuto/apollo repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/ApolloAuto/apollo.

What it runs against: a local clone of ApolloAuto/apollo — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in ApolloAuto/apollo | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 58 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of ApolloAuto/apollo. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/ApolloAuto/apollo.git
#   cd apollo
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of ApolloAuto/apollo and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "ApolloAuto/apollo(\\.git)?\\b" \\
  && ok "origin remote is ApolloAuto/apollo" \\
  || miss "origin remote is not ApolloAuto/apollo (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "WORKSPACE" \\
  && ok "WORKSPACE" \\
  || miss "missing critical file: WORKSPACE"
test -f "BUILD" \\
  && ok "BUILD" \\
  || miss "missing critical file: BUILD"
test -f "collection/cyber/BUILD" \\
  && ok "collection/cyber/BUILD" \\
  || miss "missing critical file: collection/cyber/BUILD"
test -f ".bazelrc" \\
  && ok ".bazelrc" \\
  || miss "missing critical file: .bazelrc"
test -f "CPPLINT.cfg" \\
  && ok "CPPLINT.cfg" \\
  || miss "missing critical file: CPPLINT.cfg"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 58 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~28d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/ApolloAuto/apollo"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.