From autonomy modules to a work cycle
Apollo 11.0’s most revealing feature is not a new detector or planner. Its release notes describe a complete operational cycle: vehicle preparation, route planning, autonomous driving, task execution, anomaly handling or takeover, and return-to-depot parking. The target scenarios—delivery, street sweeping, security patrol, and campus shuttles—are constrained enough to deploy but complex enough to expose the difference between a driving demo and a working product.
This reframes open source. A repository is useful not because every algorithm is state of the art, but because interfaces allow a team to replace perception, planning, control, or hardware without rebuilding the entire toolchain. Apollo’s CyberRT runtime, Dreamview tooling, package structure, calibration, maps, and scenario workflows are the less glamorous assets that make experiments repeatable.
자율주행 모듈에서 작업 사이클로
Apollo 11.0에서 가장 중요한 특징은 새 검출기나 플래너가 아니다. 릴리스 노트는 차량 준비, 경로 계획, 자율주행, 작업 실행, 이상 처리 또는 인계, 차고 복귀 주차로 이어지는 완전한 운영 사이클을 설명한다. 배송, 도로 청소, 보안 순찰, 캠퍼스 셔틀은 배포할 만큼 제한적이면서도 주행 데모와 작동하는 제품의 차이를 드러낼 만큼 복잡하다.
이 변화는 오픈소스를 다시 정의한다. 저장소는 모든 알고리즘이 최고 수준이라서가 아니라 인터페이스를 통해 인지·계획·제어·하드웨어를 전체 툴체인 재구축 없이 교체할 수 있을 때 유용하다. Apollo의 CyberRT 런타임, Dreamview 도구, 패키지 구조, 캘리브레이션, 지도, 시나리오 워크플로는 화려하지 않지만 실험을 반복 가능하게 만드는 자산이다.
Architecture reading: where I would instrument first
Apollo 11.0 upgrades multi-sensor localization with RTK, SLAM, vision, and wheel odometry, and adds BEV plus occupancy perception integrated with Baidu’s AI computing platform. For a functional vehicle, I would instrument four boundaries first: sensor timestamp to fused pose, fused pose to obstacle and occupancy output, prediction to selected trajectory, and trajectory to actuator command.
At each boundary, average latency is insufficient. We need tail latency, dropped-frame behavior, uncertainty calibration, and the system response when one modality is stale. Planning and control should be replayed with recorded perception outputs so a trajectory regression can be isolated from a perception change. For a sweeper driving close to a curb, centimeters matter; for a hill start, torque delay and rollback matter; for automatic recovery, state-machine transitions matter.
아키텍처 읽기: 먼저 계측할 지점
Apollo 11.0은 RTK, SLAM, 비전, 휠 오도메트리를 결합한 다중 센서 위치추정을 강화하고 Baidu AI 컴퓨팅 플랫폼과 통합된 BEV 및 occupancy 인지를 추가했다. 기능형 무인차라면 나는 네 경계를 먼저 계측한다. 센서 타임스탬프에서 융합 자세까지, 융합 자세에서 장애물·occupancy 출력까지, 예측에서 선택 궤적까지, 궤적에서 액추에이터 명령까지다.
각 경계에서 평균 지연만으로는 부족하다. 꼬리 지연, 프레임 드롭 시 행동, 불확실성 보정, 한 센서가 오래된 정보를 줄 때의 시스템 반응이 필요하다. 인지 변경과 궤적 회귀를 분리할 수 있도록 기록된 인지 출력으로 Planning과 Control을 재생해야 한다. 연석 가까이 달리는 청소차에는 센티미터가 중요하고, 언덕 출발에는 토크 지연과 밀림이 중요하며, 자동 복구에는 상태기계 전이가 중요하다.
The limit of the repository
Apollo’s own documentation is careful about commercialization. Open code does not provide a complete safety case, secure update process, operational monitoring team, sensor-cleaning strategy, or vehicle-specific failure analysis. A student can learn the architecture and reproduce modules, but should not mistake successful playback for road readiness.
My preferred learning project would select one narrow behavior—such as curb-following for a low-speed service vehicle—define an ODD, add temporal and localization faults, compare two planning methods, and publish both the reproducible scenario set and failure envelope. That is a better demonstration of engineering maturity than simply launching Dreamview. Apollo is most valuable as scaffolding for disciplined questions.
저장소가 제공하지 않는 것
Apollo 문서는 상용화에 대해 신중하다. 공개 코드는 완전한 안전 논증, 안전한 업데이트 과정, 운영 모니터링 조직, 센서 청소 전략, 차량별 고장 분석을 제공하지 않는다. 학생은 아키텍처를 배우고 모듈을 재현할 수 있지만 재생 성공을 도로 주행 준비와 혼동해서는 안 된다.
내가 선호하는 학습 프로젝트는 저속 서비스 차량의 연석 추종처럼 좁은 행동 하나를 고르고, ODD를 정의하며, 시간·위치추정 오류를 추가하고, 두 Planning 방법을 비교한 뒤 재현 가능한 시나리오 집합과 실패 범위를 함께 공개하는 것이다. Dreamview를 실행하는 것보다 훨씬 좋은 엔지니어링 성숙도 증거다. Apollo의 가장 큰 가치는 규율 있는 질문을 위한 골격에 있다.