Autopilot Notes: A Chinese-Language Self-Driving Curriculum Held Together by Shell Scripts
自动驾驶笔记,以解析各模块知识点、整合行业优秀解决方案进行阐述,以帮助自己及有需要的读者;包含深度学习、deeplearning、无人驾驶、BEV、Transformer、ADAS、CVPR、特斯拉AI DAY、大模型、chatgpt等内容.
At a glance
- What is it?
- gotonote/Autopilot-Notes is a documentation repository covering the autonomous driving stack from coordinate systems to VLA models, with a daily industry digest regenerated by automation. It is a reading resource, not a library, and its value depends on whether you read Chinese and whether you accept a single maintainer's curation.
- Who is it for?
- Adopt it as a reading list if you read Chinese and want a map of the autonomous driving stack before committing to papers or code. Do not adopt it if you need executable reference implementations, English material, or a stable interface you can pin a build to.
- 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 1 day ago.
- What is it written in?
- Mainly Shell, 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
The gap Autopilot Notes tries to fill: a map, not a library
Autonomous driving knowledge is scattered across conference papers, vendor keynotes, and internal engineering blogs that never get published. Someone entering the field has to reconstruct the stack from fragments. Autopilot Notes positions itself against that problem: the README describes the repository as a systematic summary and sharing of autonomous driving technical solutions, intended to help developers go from beginner to advanced. The audience is Chinese-reading engineers and students, plus anyone preparing for interviews or trying to understand why a planning module behaves the way it does. The repository is not a framework and not a dataset. It is prose, tables, directory trees, and links, organized into ten chapters. That distinction matters for adoption: you cannot import it, you can only read it. The README's own framing, a knowledge base for systematic learning, is honest about this. What it does not say is how deep any given note goes, and the directory listing alone cannot tell you whether a chapter is a paragraph or a full tutorial.
How the content is organized: chapters, a stack diagram, and a paradigm table
The repository layout follows the standard autonomous driving pipeline. Chapter 1 covers foundations: coordinate systems, camera intrinsics and extrinsics, Kalman filtering, image transforms, 3D reconstruction including NeRF, datasets, Transformer, NLP, neural architecture search, and reinforcement learning. Chapter 2 covers hardware: sensors, compute units, auxiliary units, and sensor calibration. Chapter 3 covers perception: 2D detection, 3D detection, BEV, Occupancy Network, and a section on end-to-end driving and VLA. Chapters 4 through 6 cover localization (SLAM, HD maps, multi-sensor fusion, GNSS-INS), planning (prediction, route planning, trajectory planning), and control (PID, LQR, MPC). Chapter 7 covers products: ADAS vendor comparisons, autonomous driving chips, and DMS. Chapter 8 covers tooling: visualization, simulation (with a CARLA subsection described as covering installation, the Python API, sensor configuration, scenario construction, and worked examples), and deployment acceleration. Chapter 9 covers vendor programs, and Chapter 10 is the daily digest. The README also includes two tables that do real explanatory work. One maps each stack layer to the problem it solves and the chapter that addresses it. The other contrasts modular, end-to-end, and VLA architectures, naming Tesla FSD V13, Huawei ADS 4.0, Li Auto MindVLA, and Waymo EMMA as representatives. That second table is the most opinionated artifact in the repository, because it asserts a shift in industry practice rather than describing a fixed curriculum.
The daily digest and the Shell automation behind it
Chapter 10 is the only part of the repository that behaves like software. The README states that a technology digest is pushed automatically at 19:00 on workdays, covering vendor programs, engineering practice, frontier tracking, and product analysis, with entries older than seven days archived to ch10_每日前沿/archive/. The homepage index is generated between HTML comment markers, BEGIN_HOME_INDEX and END_HOME_INDEX, which means a script rewrites that block rather than a human editing the table. The repository's primary language is listed as Shell, which is consistent with that arrangement: the notes are Markdown, and the Shell code exists to assemble and publish the index and archive. The visible digest entries for September 2026 carry keyword lists rather than summaries, spanning topics like VLA deployment, occupancy networks, Robotaxi operations, and chip names. That format is useful for scanning and weak for learning, because a keyword row tells you a topic was mentioned without telling you what was concluded. If you want the digest to be more than a headline feed, you have to open the linked file. The README does not document the automation script itself, so anyone forking the repository to run their own digest is working from the index markers and the archive path, not from a described pipeline.
Getting it running: there is nothing to install
There is no package, no build step, and no runtime. The README's quick start section is a learning path diagram, not a command sequence: stage 1 foundations, stage 2 hardware, stage 3 perception, stage 4 localization, stage 5 planning, stage 6 control, stage 7 product, stage 8 tooling. That is the entire onboarding. To use the repository you clone it and open Markdown files. The one place where commands would normally appear is the CARLA simulation subsection under ch08_工具/8.2 仿真, which the directory listing describes as covering installation and configuration, but the README excerpt does not include the actual installation commands, so this review cannot state what they are. The same applies to the deployment acceleration material implied by the tensorrt topic tag: the tag exists, the chapter exists, the commands are not in the material available here. If you are evaluating this repository as an engineering resource, that absence is the finding. It is a curriculum, and the executable parts live in the projects it points at, not in the repository itself.
Where it breaks down: single-maintainer curation and no versioning
The repository has no releases. The README's badge row advertises daily updates on workdays, but the only durable signal is the last push date, and there is no changelog, no versioned snapshot, and no way to pin the content you read today against the content that exists in six months. For a knowledge base that is a real cost: a note on BEV methods that was accurate when written can quietly become a description of superseded work, and nothing in the repository flags that. The second limitation is depth variance. A directory tree listing 1.1 坐标系 and 3.3 BEV as siblings says nothing about relative effort, and the README gives no per-chapter scope statement beyond the top-level table. The third is language. All content is in Chinese, including the digest, so an English-only reader gets the directory structure and the tables and nothing else. The fourth is that the vendor-program chapter is inherently perishable. Tables comparing ADAS vendor approaches and autonomous driving chips age faster than the mathematics chapters, and the repository does not separate the two by stability. None of these are defects in the writing. They are consequences of the format, and they should shape how much weight you put on any single page.
What to compare it against, and why the comparison is not close
The obvious alternative is the Apollo documentation set from Baidu, which the README itself names as a representative modular architecture. The difference in approach is structural. Apollo ships a runnable stack: modules, configuration files, a build system, and documentation tied to a specific release. Autopilot Notes ships explanation with no executable artifact. If your goal is to run a planning module and inspect its output, Apollo is the tool and this repository is background reading. If your goal is to understand why the field moved from modular pipelines toward end-to-end and VLA architectures before you pick a direction, the README's paradigm table and the 3.5 chapter are the kind of orientation material that a code repository does not provide, because code repositories document what they do, not what the field is arguing about. A second comparison point is the English-language survey literature: papers and course notes cover the same stack with citations. Autopilot Notes generally does not show citation apparatus in the material available, which makes it easier to read and harder to verify. That trade is the whole character of the project.
Licence, maintenance, and what a fork actually costs
The repository is Apache-2.0. For a documentation project that is a permissive choice: you can reuse and adapt the text, including commercially, provided you keep the licence and attribution notices and state significant changes. Apache-2.0 also includes an explicit patent grant, which is unusual for pure documentation and mostly relevant if you extract diagrams or tables into a product. This is a description of the licence text, not legal advice; if you plan to republish chapters, read LICENSE directly. Maintenance cost is the more practical question. The digest automation implies a recurring job that must keep running for the daily index to stay current, and if it stops, the README's homepage index simply freezes at the last successful run. For a reader, that failure is silent. For a forker who wants to run the same pipeline, the missing piece is documentation of the script itself, which the available material does not include. Upgrading is not a concept here, because there is no version to upgrade from. The realistic maintenance model is pull-based: you read what is there, you check the last push date, and you decide whether the freshness claim still holds.
Editorial conclusion
Adopt it as a reading list if you read Chinese and want a map of the autonomous driving stack before committing to papers or code. Do not adopt it if you need executable reference implementations, English material, or a stable interface you can pin a build to. Before relying on it, open ch10_每日前沿/archive/ to confirm the digest is actually being produced, check whether the 3.5 端到端自动驾驶与VLA notes have been updated since the last push, and read LICENSE to confirm the Apache-2.0 terms match how you intend to reuse the text.
Community notes