A responsive three-column image gallery.
]]>Point-LIO uses point-wise updates, updating the system state at each sampling instant. This design provides a high odometry output rate and naturally avoids the motion distortion caused by accumulating a full point-cloud frame in conventional frame-based LIO systems.
The trade-off is a substantial computational cost. Many fine-grained point-cloud matching and filtering updates require the system to repeatedly perform nearest-neighbor search, plane fitting, residual construction, and EKF updates.
Inspired by the batch-update method in Haopeng Zhang’s undergraduate thesis on Batch-LIWO at the University of Science and Technology of China, Batch-LIO changes the update granularity of Point-LIO:
LiDAR points acquired over approximately 1 ms are grouped into a batch. After motion compensation within the window, the filter performs one joint update.
The project currently provides:
Repository: github.com/Functionhx/Batch-LIO
The current experiments use sentinel-robot Livox rosbags. The test platform is an x86 computer running Ubuntu 22.04.
With the same data and parameters, the Point-LIO-style fine-grained update is enabled by setting:
batch_dt: 0.0
A 1 ms Batch-LIO update is enabled by setting:
batch_dt: 0.001
The results under ROS 2 Humble are:
| Rosbag | Point-LIO-style update | Batch-LIO 1 ms | Speedup |
|---|---|---|---|
| quick-shack | 12.42 ms | 3.51 ms | 3.5× |
| outdoor_run | 2.56 ms | 0.54 ms | 4.7× |
These values are the mean compute time per point-cloud frame.
With the current test data and parameters, the Batch-LIO trajectories are close to the Point-LIO baseline; no obvious trajectory degradation was observed.
Tests across different batch windows show that increasing the window reduces the number of filter updates and further lowers compute time. A larger window, however, also increases motion-compensation error and may affect filter stability. The current recommendation is a batch_dt of 1–2 ms.
Point-LIO is designed around point-wise updates. In practice, its implementation groups a small number of points with identical timestamps, but those groups are usually still small, so each frame requires many fine-grained updates.
Instead of grouping only points whose timestamps are exactly equal, Batch-LIO places neighboring points acquired over roughly 1 ms into the same window:
Point-LIO:
[t₀] [t₁] [t₂] [t₃] [t₄] ...
↓ ↓ ↓ ↓ ↓
many small updates
Batch-LIO:
[ t₀ to tₙ, about 1 ms ]
↓
one joint update
This substantially reduces the number of EKF updates performed for each frame.
Points in the same batch are not captured at the same instant, so they cannot be matched as though they were a simultaneous point cloud.
Batch-LIO compensates every point in the window to the sampling time of the final point.
For the $j$-th point, the time offset relative to the end of the window is:
\[\Delta t_j = t_j - t_{\mathrm{last}}, \qquad \Delta t_j \le 0\]The rotational compensation is computed from the angular velocity in the current filter state:
\[R_j = \operatorname{Exp}(\omega \Delta t_j)\]The translational compensation is:
\[T_j = R_I^\top v \Delta t_j\]The compensated LiDAR point is then:
\[p'_j = R_j p_j + T_j\]The linear velocity $v$ in the state is expressed in the world frame, whereas LiDAR motion compensation is performed in the body frame. The transformation $R_I^\top$ is therefore required; $v \Delta t_j$ cannot be used directly.
After compensating motion within the window, Batch-LIO performs the following operations for the points in the batch:
All valid measurements are then stacked, and a single EKF update is performed at the end of the window.
The main source of Batch-LIO’s speedup is therefore not a reduction in the number of points used for matching. It comes from:
The tests showed that applying OpenMP directly to Point-LIO’s small point groups can make execution slower because thread-scheduling overhead exceeds the amount of useful computation. Batch grouping increases the number of points handled in each update, allowing OpenMP to produce a clearer benefit.
The project still has several limitations:
The current results therefore demonstrate the feasibility of batch updates and the scale of the potential compute-time reduction. They do not constitute complete accuracy validation or real-robot validation.
Testing on different LiDARs, compute platforms, and real robots is welcome. Problems and improvement ideas can be reported through GitHub Issues.
The planned work is tracked in GitHub Issue #9.
While retaining Batch-LIO’s batch-update method, selected optimizations from Small Point-LIO will be explored for the voxel map, memory management, and fixed-size measurement computation.
The first CUDA back end will target a discrete GPU on x86, with the GPU handling:
The CPU will retain IMU state propagation and the small EKF solve. A CPU/GPU dispatch threshold will be evaluated according to batch size.
Drawing on ideas from FR-LIO and FAR-LIO, planned experiments include a robot-centric voxel map, adaptive point-cloud density, robust matching thresholds, and sparse GICP, while preserving Batch-LIO’s batch-measurement semantics.
After the x86 CUDA version has been validated, it will be ported to Jetson and evaluated for:
Future work also includes ROS 2 Jazzy support and more complete trajectory-accuracy, stability, and performance testing on datasets with ground truth and on real RoboMaster robots.
All subsequent optimizations will retain the original Batch-LIO comparison path.
Repository: github.com/Functionhx/Batch-LIO
The main branch currently contains the ROS 2 Humble version. The ROS 1 Noetic version is preserved under the ros1-noetic tag.
Testing with different LiDAR models, compute platforms, and real robots is welcome, as are Issues and pull requests.
[1] D. He, W. Xu, N. Chen, F. Kong, C. Yuan and F. Zhang, “Point-LIO: Robust High-Bandwidth Light Detection and Ranging Inertial Odometry,” Advanced Intelligent Systems, 2023.
[2] 张昊鹏，《高带宽轮式激光惯性里程计（Batch-LIWO）》，中国科学技术大学本科毕业设计。
[3] W. Xu and F. Zhang, “FAST-LIO: A Fast, Robust LiDAR-Inertial Odometry Package by Tightly-Coupled Iterated Kalman Filter,” IEEE Robotics and Automation Letters, 2021.
[4] W. Xu, Y. Cai, D. He, J. Lin and F. Zhang, “FAST-LIO2: Fast Direct LiDAR-Inertial Odometry,” IEEE Transactions on Robotics, 2022.
[5] HKU-MARS, Point-LIO: github.com/hku-mars/Point-LIO
[6] ACE, Small Point-LIO: github.com/Yancey2023/small_point_lio
[7] J. Liu, Y. Zhang, X. Zhao and Z. He, “FR-LIO: Fast and Robust LiDAR-Inertial Odometry by Tightly-Coupled Iterated Kalman Smoother and Robocentric Voxels,” 2023.
[8] M. Leitenstern, M. Weinmann, P. Haft, T. Lasser, D. Kulmer and M. Lienkamp, “FAR-LIO: Enabling High-Speed Autonomy through Fast, Accurate, and Robust LiDAR-Inertial Odometry,” 2026.
The Chinese original was published on the RoboMaster Community on July 22, 2026. The community edition is licensed under CC BY-NC-SA 4.0.
]]>Point-LIO 采用 point-wise 的更新方式，在每个采样时刻更新系统状态。这样的设计可以获得较高的里程计输出频率，并天然避免传统帧式 LIO 中由整帧点云累积造成的运动畸变。
但另一方面，大量细粒度的点云匹配和滤波更新也会带来较高的计算开销，系统需要频繁进行近邻搜索、平面拟合、残差构建和 EKF 更新，消耗了较多的计算资源。
Batch-LIO 参考中国科学技术大学张昊鹏学长本科毕业设计 Batch-LIWO 中的批量更新方法，对 Point-LIO 的更新粒度进行了修改：
将相邻约 1 ms 内的激光点组成一个 batch，完成窗口内运动补偿后，统一执行一次滤波更新。
目前项目已经提供：
项目地址：github.com/Functionhx/Batch-LIO
目前实验在哨兵 Livox rosbag 上进行，测试平台为 x86 计算机，操作系统为 Ubuntu 22.04。
在相同数据和参数下，通过设置：
batch_dt: 0.0
运行 Point-LIO 式细粒度更新；设置：
batch_dt: 0.001
运行 1 ms Batch-LIO。
ROS 2 Humble 下的测试结果如下：
| 数据包 | Point-LIO 式更新 | Batch-LIO 1 ms | 加速比 |
|---|---|---|---|
| quick-shack | 12.42 ms | 3.51 ms | 3.5× |
| outdoor_run | 2.56 ms | 0.54 ms | 4.7× |
这里统计的是每帧点云对应的平均计算耗时。
在当前测试数据和参数下，Batch-LIO 输出的轨迹与 Point-LIO 基线比较接近，没有观察到明显的轨迹退化。
对不同 batch 时间窗口进行测试后可以看到：随着时间窗口增大，滤波更新次数继续减少，计算耗时也会下降。但较大的时间窗口会增加运动补偿误差，并可能影响滤波器稳定性。目前建议将 batch_dt 设置在 1～2 ms。
Point-LIO 的算法设计是逐点更新。实际代码会将时间戳相同的少量点组合起来，但点组通常仍然很小，因此每帧需要执行大量细粒度更新。
Batch-LIO 不再只按照完全相同的时间戳分组，而是将相邻约 1 ms 内的点划分到同一个窗口：
Point-LIO：
[t₀] [t₁] [t₂] [t₃] [t₄] ...
↓ ↓ ↓ ↓ ↓
多次小规模更新
Batch-LIO：
[ t₀ ～ tₙ，约 1 ms ]
↓
一次联合更新
这样可以显著减少每帧执行 EKF 更新的次数。
同一个 batch 内的点并不是在同一时刻采集的，因此不能直接将它们当作同时刻点云进行匹配。
Batch-LIO 将窗口内的点补偿到最后一个点的采样时刻。
对于第 $j$ 个点，其相对于窗口末端的时间偏移为：
\[\Delta t_j = t_j - t_{\mathrm{last}}, \qquad \Delta t_j \le 0\]根据当前滤波状态中的角速度和线速度，计算旋转补偿：
\[R_j = \operatorname{Exp}(\omega \Delta t_j)\]计算平移补偿：
\[T_j = R_I^\top v \Delta t_j\]最终得到补偿后的激光点：
\[p'_j = R_j p_j + T_j\]这里需要注意，状态中的线速度 $v$ 位于世界坐标系，而激光点的运动补偿在机体坐标系中进行，因此需要通过 $R_I^\top$ 完成坐标系转换，不能直接使用 $v \Delta t_j$。
完成窗口内运动补偿后，对 batch 中的点分别进行：
随后将所有有效量测堆叠起来，在窗口末端统一执行一次 EKF 更新。
因此，Batch-LIO 的主要加速来源并不是减少参与匹配的点数，而是：
测试中发现，直接在 Point-LIO 的小点组上使用 OpenMP 反而可能变慢，因为线程调度开销超过了实际计算量。经过 batch 分组后，每次处理的点数增加，OpenMP 才能获得比较明显的收益。
当前项目仍然存在以下不足：
因此，目前结果主要用于验证批量更新方法是否可行，以及能够带来多大的计算加速，还不能代表已经完成了充分的精度和实车验证。
欢迎有条件的同学帮忙在不同雷达、计算平台或真实机器人上测试。遇到问题或者有改进想法，可以直接在 GitHub Issues 中反馈。
项目后续工作已经整理到 GitHub Issue #9。
目前计划包括：
在保留 Batch-LIO 批量更新方式的基础上，选择性吸收 Small Point-LIO 在体素地图、内存管理和固定尺寸量测计算方面的优化。
首先在 x86 独立显卡上开发 CUDA 后端，使 GPU 负责：
CPU 保留 IMU 状态传播和小尺寸 EKF 求解，并根据 batch 大小评估 CPU/GPU 分流阈值。
参考 FR-LIO、FAR-LIO 等工作的思路，实验机器人中心体素地图、自适应点云密度、鲁棒匹配阈值和稀疏 GICP，同时保留 Batch-LIO 的批量量测语义。
在 x86 CUDA 版本验证完成后，迁移至 Jetson 平台，测试：
后续还计划支持 ROS 2 Jazzy，并在带真值数据集和 RoboMaster 实车上完成更充分的轨迹精度、稳定性和性能测试。
所有后续优化都将保留原版 Batch-LIO 对照路径。
项目仓库：github.com/Functionhx/Batch-LIO
目前 main 分支为 ROS 2 Humble 版本，ROS 1 Noetic 版本保留在 ros1-noetic tag 中。
欢迎感兴趣的同学使用不同型号雷达、计算平台和真实机器人进行测试，也欢迎提交 Issue 或 PR。
[1] D. He, W. Xu, N. Chen, F. Kong, C. Yuan and F. Zhang, “Point-LIO: Robust High-Bandwidth Light Detection and Ranging Inertial Odometry,” Advanced Intelligent Systems, 2023.
[2] 张昊鹏，《高带宽轮式激光惯性里程计（Batch-LIWO）》，中国科学技术大学本科毕业设计。
[3] W. Xu and F. Zhang, “FAST-LIO: A Fast, Robust LiDAR-Inertial Odometry Package by Tightly-Coupled Iterated Kalman Filter,” IEEE Robotics and Automation Letters, 2021.
[4] W. Xu, Y. Cai, D. He, J. Lin and F. Zhang, “FAST-LIO2: Fast Direct LiDAR-Inertial Odometry,” IEEE Transactions on Robotics, 2022.
[5] HKU-MARS, Point-LIO: github.com/hku-mars/Point-LIO
[6] ACE, Small Point-LIO: github.com/Yancey2023/small_point_lio
[7] J. Liu, Y. Zhang, X. Zhao and Z. He, “FR-LIO: Fast and Robust LiDAR-Inertial Odometry by Tightly-Coupled Iterated Kalman Smoother and Robocentric Voxels,” 2023.
[8] M. Leitenstern, M. Weinmann, P. Haft, T. Lasser, D. Kulmer and M. Lienkamp, “FAR-LIO: Enabling High-Speed Autonomy through Fast, Accurate, and Robust LiDAR-Inertial Odometry,” 2026.
本文于 2026 年 7 月 22 日发布于 RoboMaster 社区；社区版本采用 CC BY-NC-SA 4.0 许可协议。
]]>Treating actions as just another kind of token, and treating control as an inconvenience that data scaling can bypass, may be the most expensive misconception in this field.
Let me begin with a disclaimer. I am not looking down on computer science, nor am I trying to create a divide between disciplines. This is simply a discussion about cognitive paradigms and real-world systems engineering.
For a long time, I held a rather naïve belief: if they were willing to study control seriously, most people coming from a pure-CS background—whether they had worked on back-end systems, programming contests, visual recognition, or large-model training—could move into robot control, autonomous-driving decision-making, or even control-theory research without much difficulty.
After intensive study of control theory, hands-on robot debugging, and countless cross-disciplinary conversations about first principles, I realized that I was wrong.
I have had to accept an uncomfortable reality. The basic way many people with pure-CS backgrounds understand the world can clash with the rigorous framework that colleagues in automation, mechanical engineering, and robotics build around “physical systems—dynamic evolution—feedback loops.” The resulting cognitive friction is real and difficult to eliminate.
In everyday discussions, they are often the ones who first bring up robotics or autonomous driving. Yet as soon as the conversation moves beyond “which model did you use, how large is the network, and what score did the dataset reach” toward system dynamics, state estimation, stability, observability, real-time constraints, and closed-loop safety, I often see the habits of pure-CS thinking begin to retreat from the problem.
To fill that gap, people instinctively reach for generalized language borrowed from paper abstracts or promotional writing, flattening the actual complexity: “end-to-end learning will discover it automatically,” “with enough data you no longer need models,” “Transformers can unify everything,” or “isn’t the controller just an MLP at the end?”
The hard technical reality is that dynamics constraints, sensor noise, actuator latency, friction, saturation, modeling error, and closed-loop stability cannot be made to disappear through narrative.
The pure-CS and internet-algorithm paradigm is built around discrete inputs, static datasets, explicit loss functions, and reproducible offline evaluation. The control-and-robotics paradigm deals with continuous time, dynamic evolution, feedback loops, physical constraints, and uncertainty everywhere. In an offline dataset, one bad prediction might lower accuracy by a fraction of a point. In a real closed-loop system, one sampling period of latency, one incorrect sign, one wrong coordinate transformation, or one overlooked actuator saturation can send the entire system directly from stable operation into divergence.
Using the mindset of static prediction to understand dynamic control is, in my view, bound to produce repeated misunderstandings.
I know this statement will draw criticism, but I still think it needs to be said. The most heavily promoted VLA work in the current wave of embodied AI often looks less like a control technology being deployed and more like a narrative tailored for fundraising.
VLA reframes “vision + language + proprioceptive state → action” as a large-scale sequence-modeling problem. The implication is that, given a large enough model and enough data, robot control can be “learned end to end” in the same way as a large language model.
The most compelling feature of this narrative is not necessarily how correct it is, but how easy it is to sell. It repackages a closed-loop control problem that control and robotics researchers have worked on for decades—and still have not fully solved—as a scaling problem that can supposedly be overcome with enough money and data. Money and compute are precisely what investors can provide. A decades-old engineering challenge is translated into a growth story that investors can understand and are willing to fund.
There are several very simple tests for distinguishing technology from rhetoric:
First, look at what it shows you. Fundraising shows edited demo videos and carefully arranged tabletop scenes in a laboratory. Deployment is about closed-loop reliability that does not fail, 24 hours a day, seven days a week. The gap between one selected successful grasp and a system that can run for a week in an open environment without collision, dropping objects, or losing stability is not a few percentage points; it is the whole discipline of control engineering. A pitch deck will almost always show the former.
Second, look at what it measures. “Action-prediction accuracy” and “task success rate” above 90% in carefully staged settings sound impressive. But the measures that actually determine whether a robot is usable—mean time between closed-loop failures, safety margins in out-of-distribution states, error accumulation over long rollouts, and whether contact forces lead to slip—are difficult, unflattering, and hard to optimize. You almost never see them in fundraising material. Selective reporting is not itself fraud, but reporting only metrics that say little about real reliability is difficult to dismiss as accidental.
Third, look at how it explains failure. Real engineering identifies a cause: state estimation drifted, actuator latency exceeded a limit, or the controller became unstable in a particular operating regime. A fundraising narrative has only one explanation: “the next model will fix it” or “one more order of magnitude of data will solve it.” Falsification is systematically postponed until after the next funding round. A technical promise that can never be falsified and always places its answer in “bigger and more” is cognitively similar to a Ponzi structure: new money is needed to preserve the credibility of the previous story.
I am not saying that everyone working on VLA is deceiving people. Most researchers are sincere, and VLA has genuinely brought open-world semantic understanding to robots at a level that was previously missing. My point is this:
When a technology that is still far from solving closed-loop reliability is packaged as a disruptive claim that “end-to-end systems will soon replace state estimation, motion planning, and feedback control,” and that claim is used to unlock enormous funding, the narrative has quietly shifted from serving robotics to serving fundraising itself.
The people most likely both to create and believe this story are often those whose intuition was trained only on static datasets and who have never been punished by divergence or collisions in a real feedback loop. Within that cognitive paradigm, “predicting accurately” and “controlling successfully” are assumed to be the same thing. That assumption is where the entire misunderstanding begins.
This cognitive friction is especially visible in the way people use the term “first principles.” When many CS and AI practitioners discuss first-principles thinking, the same associations appear: Elon Musk, breaking a problem down, end-to-end learning, and letting the model discover the rules. A concept rooted in physical modeling and axiomatic reasoning is reduced to a business method or a slogan for the era of large models.
What do first principles mean for a control system? To me, they mean starting from Newton–Euler equations, rigid-body kinematics, conservation of energy, circuit laws, and system constraints; constructing a mathematical model that can describe the real object; and then rigorously analyzing equilibrium, controllability, observability, stability, robustness, and optimality. An inverted pendulum does not balance because a neural network “understands” equilibrium. A race car does not take a corner at high speed merely because a model has seen enough turns in a dataset. Without systematic training in classical control, modern control, signals and systems, dynamics, and state estimation—and without wrestling repeatedly with Laplace transforms, state space, Lyapunov stability, and the mathematics of nonlinear systems—the claim that a model will “learn control by itself” is a structure built on the limited support of a finite data distribution.
Claims that there is no barrier between AI and robotics often confuse learning engineering tools with rebuilding one’s underlying intuition. Using PyTorch, training a perception model, changing a network architecture, and running open-source code are closer to a framework and workflow; with intensive training, a pure-CS practitioner can absolutely master them. Work at the deeper and more advanced layers—nonlinear control, model predictive control, state estimation, real-time optimization, robust control, and genuine closed-loop learning in embodied systems—requires strong intuition about system state, dynamic response, time and frequency domains, noise propagation, physical constraints, and stability margins.
That intuition needs long-term mathematical and engineering training. It may only take shape after watching real systems oscillate, overshoot, diverge, lose stability, and crash again and again. Without that training, beautiful offline metrics and sophisticated narratives may offer little help when the real problem is model mismatch, asynchronous sensors, actuator delay, tire slip, or closed-loop instability.
My disillusionment is really a correction to an earlier assumption: that someone skilled in software and algorithms can take a few control courses and naturally cross the foundational gap between “processing information” and “manipulating the physical world.”
Of course, the incompatibility runs in both directions. Someone trained only in classical control, with no systematic background in computer science, may be equally naïve when asked to design a large-scale distributed system, optimize a CUDA kernel, analyze a compiler, build a foundation model, or process data at massive scale. They may fall into their own version of “just add a PID controller.”
The rational response is neither to argue that one discipline is superior nor to deny all of VLA’s value. It is to respect the gap between paradigms and recognize their boundaries. Computer science excels at building computational systems, processing information, and scaling algorithms. Control and automation excel at describing dynamic worlds, managing feedback and constraints, and keeping systems stable under uncertainty. Different cognitive strengths should be applied where they belong, rather than using one fundraising narrative to conceal the hard constraints that another discipline has spent decades confronting.
The Chinese original was published on Zhihu on June 10, 2026, and republished on June 26, 2026 by 具身智能之心 TechDaily, the embodied-AI platform launched by 自动驾驶之心.
]]>把动作当成另一种 token，把控制当成可以靠数据 scaling 绕过的麻烦——这是这个领域最贵的一个误会。
先叠个甲，并非看不起 CS，也完全不想制造文理对立或者学科鄙视链。这只是一个关于认知范式与真实系统工程的客观讨论。
长期以来，我一直有个很天真的想法，只要愿意认真学控制，大部分纯 CS 转过来的同学，哪怕之前主要做后端、打算法竞赛、搞视觉识别甚至炼大模型，去做机器人控制、自动驾驶决策、甚至成为控制理论研究者，都是完全没问题的。
但经历过高强度的控制理论沉淀、真实机器人调试，以及无数次跨学科的底层交流后，我发现我错了。
我必须承认一个残酷的现实，很多纯 CS 背景同学认知世界的底层原理，与我和一些做自动化、机械、机器人的同学围绕“物理系统—动态演化—反馈闭环”建立起来的这套严密体系，存在着天然的、难以兼容的认知摩擦。
在日常讨论中，每次开启机器人或者自动驾驶的话题，往往是他们先挑起。但只要讨论的边界一旦从“用了什么模型、网络多大、数据集刷到多少”，推进到系统动力学、状态估计、稳定性、可观测性、实时性、闭环安全，我观察到绝大多数纯 CS 同学的思维惯性就会开始被动回避。
为了填补这种认知空白，他们会本能地调用一些论文摘要式或者营销号式的泛化文字，去粗暴地抹平其中的复杂性——“端到端可以自动学出来”“数据够多就不需要建模”“Transformer 能统一解决一切”“控制器不就是最后接个 MLP 嘛”。
但技术硬核的地方在于，动力学约束、传感器噪声、执行器延迟、摩擦、饱和、建模误差和闭环稳定性，是绝对不能仅靠叙事消除的。
纯 CS 和互联网算法的范式，是离散输入、静态数据集、明确的损失函数、可复现的离线评测。控制与机器人的范式，是连续时间、动态演化、反馈闭环、物理约束与无处不在的不确定性。在离线数据集里，预测错一次无非是 accuracy 掉零点几个点；但在真实闭环系统里，一个采样周期的延迟、一个符号写反、一个坐标系变换搞错，甚至一个没人考虑的执行器饱和，都可能让整个系统从稳定直接走向发散。
用静态预测的思维去理解动态控制，在我看来必然导致高频的误解。
我知道这句话会被喷，但还是得说：这一轮具身智能里被吹得最凶的 VLA，与其说是一项落地中的控制技术，不如说是一套为融资量身定制的叙事。
VLA 的思路是把“视觉 + 语言 + 本体状态 → 动作”重新表述成一个大规模序列建模问题，言下之意是：只要模型够大、数据够多，机器人控制就能像大语言模型一样被“端到端学出来”。
这套叙事最迷人的地方，恰恰不在于它有多对，而在于它有多好卖。它把一个控制和机器人学界辛苦了几十年、至今没有彻底解决的闭环控制难题，重新包装成了一个“只要钱够多、数据够多就能解决”的 scaling 问题——而钱和算力，正好是投资人能提供的东西。一个几十年的工程硬骨头，被翻译成了一个投资人听得懂、也愿意为之买单的增长故事。
判断一个东西是技术还是话术，有几个非常朴素的检验标准：
第一，看它拿什么给你看。 融资看的是剪辑过的 demo 视频和实验室里布置好的桌面场景；落地看的是 7×24 小时不出事的闭环可靠性。一段挑出来的成功抓取，和一个能在开放环境里连续运行一周不撞、不掉、不失稳的系统，之间隔着的不是几个百分点，而是整个控制工程。Pitch deck 里永远是前者。
第二，看它报什么指标。 “动作预测准确率”“任务成功率”在精心布置的场景里刷到 90%+，听上去很唬人。但真正决定机器人能不能用的指标——闭环平均无故障时间、分布外状态下的安全边界、长时序滚动的误差累积、接触力是否导致滑移——这些既难看又难刷的数字，你几乎从不会在融资材料里见到。报喜不报忧本身不是骗局，但只报那个和真实可靠性几乎无关的指标，就很难说是无心。
第三，看它怎么解释失败。 真正的工程会告诉你失败的根因：是状态估计漂了、执行器延迟超了，还是控制器在某个工况下失稳了。而融资叙事解释失败永远只有一句话——“下一代模型就好了”“数据再多一个数量级就解决了”。它把证伪系统性地推迟到了下一轮融资之后。一个永远不可证伪、永远把答案押在“更大更多”上的技术承诺，和庞氏结构在认知形态上是高度同构的：都需要新的钱进来，才能维持上一轮叙事的体面。
我不是说做 VLA 的人都在骗。绝大多数研究者是真诚的，VLA 本身也确实给机器人带来了过去极度缺乏的开放世界语义理解能力。我说的是：
当一项还远没解决闭环可靠性的技术，被包装成“端到端即将取代状态估计、运动规划和反馈控制”的颠覆叙事，并以此撬动天量融资时，这套叙事服务的对象，已经从机器人悄悄变成了融资本身。
而最容易制造、也最容易相信这套叙事的，恰恰是那些只在静态数据集里训练过直觉、从没在真实闭环里被发散和撞车毒打过的纯 CS 背景。因为在他们的认知范式里，“预测得准”和“控制得住”本来就是一回事——而这，正是整个误会的起点。
这种认知摩擦，在第一性原理这个词上展现得淋漓尽致。现在很多 CS 和 AI 从业者聊到第一性原理，脑子里蹦出的关键词永远只有那几个：马斯克、拆解问题、端到端、让模型自己发现规律。他们把一个源于物理建模和公理化推演的概念，降维简化成了一种商业方法论或者大模型时代的技术口号。
真正面向控制系统的第一性原理是什么？我认为是从牛顿—欧拉方程、刚体运动学、能量守恒、电路定律、系统约束这些东西出发，先建立一个能描述真实对象的数学模型，再去严密讨论平衡点、可控性、可观测性、稳定性、鲁棒性与最优性。一个倒立摆能立住，不是因为神经网络“理解”了平衡；一辆赛车能高速过弯，也不是因为模型在数据集里见过足够多的弯道。如果没有系统学习过经典控制、现代控制、信号与系统、动力学和状态估计，没有被拉普拉斯变换、状态空间、Lyapunov 稳定性和非线性系统的数学推导反复毒打过，所谓的“让模型自己学会控制”，不过是建立在有限数据分布上的空中楼阁。
很多人鼓吹的 AI 与机器人之间没有壁垒，其实混淆了工程工具的掌握与底层直觉的重塑。调 PyTorch、训感知模型、改网络结构、跑通开源代码，这更像是一种框架与流程的规范，纯 CS 同学通过高强度训练完全可以胜任。但涉及底层与前沿，比如非线性控制、模型预测控制、状态估计、实时优化、鲁棒控制，以及具身系统真正的闭环学习，这需要对系统状态、动态响应、时域与频域、噪声传播、物理约束、稳定裕度拥有极强的技术直觉。
这种直觉需要长期的数理与工程训练来做支撑，甚至需要在真实系统上一次次振荡、超调、发散、失稳、撞车之后，才能慢慢建立起来。缺乏这种训练，在面对模型失配、传感器异步、执行器延迟、轮胎打滑、闭环不稳定时，再漂亮的离线指标、再高级的叙事文字，也可能无能为力。
我的这种幻灭，是对一个假设的修正——以为一个擅长软件和算法的人，补几门控制课，就能自然跨越从“处理信息”到“操纵物理世界”的底层范式鸿沟。
当然，这种不兼容是双向的。如果让一个只会经典控制、从没受过系统计算机训练的人，去设计大规模分布式系统、优化 CUDA Kernel、分析编译器、构建基础模型、处理亿级数据，他同样可能陷入“加个 PID 就好了”式的自鸣得意。
理性的解法，不是争论哪个专业更高级，也不是否定 VLA 的全部价值，而是尊重思维范式的鸿沟，承认两种范式各有边界——CS 擅长构建计算系统、处理信息、扩展算法规模，控制与自动化擅长描述动态世界、处理反馈与约束、让系统在不确定环境里稳定运行——然后把不同的认知带宽，释放在正确的生态位上，而不是用一套融资叙事去掩盖另一套范式几十年都没绕开的硬约束。
本文于 2026 年 6 月 10 日发布于知乎，后于 2026 年 6 月 26 日由自动驾驶之心推出的「具身智能之心 TechDaily」转载。
]]><iframe src="/assets/plotly/demo.html" title="Plotly demo"></iframe>
<iframe src="/assets/plotly/demo.html" title="Plotly demo"></iframe>