从物理引擎到实时遥测：登月着陆闭环仿真系统的设计与调优

把“Apollo-11”当成项目代号来用，大概率每个人都会想到那台登月着陆器。我手上这套系统，虽然名字起得挺有情怀，内核倒不是什么航天工程，而是一套完整的登月着陆闭环仿真与实时遥测演示系统。你可以把它理解成：在浏览器里模拟一艘着陆器从高空下降、减速、悬停直到安全触月，同时把高度、速度、剩余燃料、发动机推力这些关键变量实时打点记录下来，供后续分析。项目最初的诉求很朴素，想验证“一套仿真物理引擎 + 一套自动控制器 + 一套可视化仪表盘”到底能不能在纯前端跑得稳，于是就有了这套代号为 Apollo-11 的模块化着陆仿真平台。

这套系统很适合三类人参考：一是想搞懂数字仿真和积分器原理的学生，二是想练习 PID 控制参数整定的开发者，三是对前端实时可视化感兴趣、想找一个大项目练练手的前端爱好者。我尽量把原理、代码和踩坑过程都写透，里面有大量可以直接“抄作业”的配置和参数，也有不少常规文档里不会写清楚的教训。

1. 项目定位与整体设计思路拆解

1.1 为什么叫 Apollo-11，它到底解决什么问题

先说名字。叫“Apollo-11”不是为了冒充真实航天项目，而是借了“登月”这个意象来定义产品的边界：一切围绕着陆器从入轨高度下降到月面触地这条链路展开。项目中“11”这个数字也暗藏一个具体含义——我把整个系统拆成了 11 个独立模块，比单文件堆逻辑要清爽得多，也方便不同人各自负责一块。

这类项目最常见的错误，是一上来就奔着“画面好看”去，结果物理全瞎编。我那套系统的目标反而很克制：物理模型够用、控制通道可调、遥测数据完整、回放方便。核心解决的是三个问题：

• 真实感：着陆器受重力、推力和燃料消耗影响，运动方程必须像一个真实物理对象。
• 可控性：既要能手动操作，也要能切到自动着陆，观察控制器如何分阶段调节推力。
• 可观测性：每次飞行结束，能拿到一条完整的遥测曲线，知道它是在哪个高度段出了问题。

换句话说，这套东西的本质是一台“会飞的数据生成器”，画面只是辅助，数据才是主角。这一定位决定了后续所有技术选型。

1.2 11 个模块是怎么拆出来的

模块划分是项目启动时最重要的事。

当时我把整个软件链路走查了一遍：从用户输入指令开始，到物理引擎算出新状态，到控制器决定推力，到渲染器画出画面，再到状态记录器写入日志，最后还要有统计模块对飞行结果打分。按照这条链路，我拆出了 11 个模块：

这 11 个模块之间的依赖关系被严格限制成单向流：输入 → 控制器 → 动力 → 物理 → 渲染/记录。事件总线只负责传递“着陆成功”“燃料耗尽”这类系统级事件，业务数据都走接口返回值。这样做的好处很直接：任何一个模块都可以被替换掉而不影响其他模块，后来我想把 JavaScript 物理引擎换成 WebAssembly 版本时，只动了 M3 内部，其他地方一行没改。

1.3 技术栈与架构选型背后的取舍

技术栈主要就三样：JavaScript 写渲染和交互，负责仿真主循环；物理计算用 JavaScript 实现，但在数值敏感部分采用“半隐式欧拉”而不是普通欧拉；遥测存储用内存数组加 CSV 导出。为什么不直接上重型框架？因为这个项目最吃资源的部分是高频物理更新，前端框架在渲染层帮不了太多，反而会增加状态同步的复杂度。

我的实测结果是：用原生 Canvas 绘制 HUD，在 60Hz 刷新率下毫无压力；物理循环跑在独立的 requestAnimationFrame 通道里，每帧最多推进 4 个物理子步，保证燃料消耗和推力的积分不跳变。如果每帧只更新一次物理状态，在帧率波动时着陆器会出现明显的“一顿一顿”，这在实际操作中是很难接受的。

另一个关键取舍是：仿真参数全部走配置中心，而不是写死在代码里。月球重力常数、初始高度、初始速度、最大推力、燃料容量全部放在一个 JSON 配置文件中。这让我在调参时不需要重启进程，刷新页面就能套用新配置，大大缩短了实验周期。

2. 核心细节解析与实操要点

2.1 物理引擎核心：重力、推力与积分器

物理引擎是整个系统的地基。如果你把着陆器当成一个质点来处理，它的受力非常简单：竖直向下的重力，加上发动机沿机体轴线产生的推力。但“简单”不代表“容易”，因为推力和燃料消耗耦合在一起，而燃料质量变化又会反过来影响加速度。

我采用的动力学模型是这样：

• 质量 m(t) = m_empty + fuel(t)，燃料以固定速率消耗，消耗速率正比于当前推力百分比。
• 竖直方向受力：F_gravity = m * g，推力竖直分量 F_thrust_y = thrust * cos(姿态角)。
• 水平方向受力：F_thrust_x = thrust * sin(姿态角)。
• 加速度：a = F / m，然后积分得到速度，再积分得到位置。

这里最考验功底的是积分器选型。标准欧拉法实现最简单，但它在能量上不保守，长时间模拟会出现明显的漂移，表现为着陆器明明关了发动机，高度却慢慢“自己涨上去”，非常反直觉。我换成了半隐式欧拉（也叫 symplectic Euler）：先更新速度，再用新速度去更新位置。这样即使时间步长取到 0.01 秒，也不会出现能量爆炸的问题，实现在代码里只差一行顺序，效果却天差地别。

另一个容易翻车的地方是单位。我踩过一次坑：把推力写成了牛顿，把燃料消耗速率写成了千克/秒，但质量用的是吨，结果比推力加速度小了三个数量级，着陆器直接“脸着地”。后来我设置了一条硬性约定：所有物理量一律使用国际单位制，长度用米，质量用千克，时间用秒，推力用牛顿，这条约定直接写进配置中心的注释里，谁改谁负责。

2.2 自动控制通道：主减速、悬停、落月三个阶段

自动控制器是整个项目的大脑。一开始我天真地以为，只要对着速度偏差用 PID 输出推力就够了。实测下来完全不是那么回事，着陆器会在高空疯狂消耗燃料，到了低空又发现速度压不下来，最后摔得很难看。后来我看了大量公开的着陆控制资料，发现工程上普遍采用“分阶段控制”的思路，于是把自动着陆拆成了三个阶段：

• 主减速段：从初始高度开始，以最大推力减速，直到下降速度低于某个安全阈值（例如 15m/s）。
• 悬停搜点段：垂直速度目标设为 0，水平漂移目标设为 0，维持在一个相对高度上，等水平速度归零后再继续下降。
• 触月段：以固定的小下降率（例如 1.5m/s）下沉，触月时推力立即归零，保证接触速度不超过设计上限。

每个阶段用独立的 PID 控制器工作。主减速段用大比例项，悬停段用比例加积分，触月段用较小的比例加前馈，因为此时燃料已经不多，需要避免推力震荡。

我在调试时发现一个典型现象：只靠 PID 往往会出现“过冲”，也就是高度还没到目标点，推力就已经减到很小，导致下降速度重新增大。解决这个问题有两个窍门。第一，给控制器输出加一个“推力变化率限制”，让它不能瞬间从 100% 掉到 10% 以下，模拟真实发动机响应速度；第二，引入交叉判断，同时看“当前高度”和“当前下降速度”，用高度除以期望剩余时间得到的期望速度，再去和实际速度做偏差。这个方法被称作“路径规划式控制”，实际用下来比单纯靠误差积分要稳得多。

2.3 手动模式与输入调度

自动控制做完了，我又加了一个手动模式，用来对照体验“自动了这么多，人力到底行不行”。手动模式的操作映射很简单：方向键控制左右倾斜，空格键或上箭头控制主发动机点火，但推力大小不是按键瞬间就满的，而是有一个加载曲线，模拟涡轮泵从低转速爬到全功率的过程。

手动模式的价值不仅仅在于“好玩”，它还能帮你诊断自动控制器的问题。比如通过手动操作，你能感受到“如果推力和重力完全平衡，着陆器是悬浮的”，从而验证重力加速度和推力参数是否合理。我在一次手动飞行中发现，把按键按到底，着陆器竟然能向上爬升，这让我意识到最大推力比重力大太多，白白浪费了燃料；把这个参数调低后，自动控制器的工作区间也变得更合理了。

输入调度上有一个很小的细节：事件监听不能直接改物理变量，而是把输入写到一个“控制请求对象”里，物理循环每帧去消费这个对象。这样即使浏览器窗口失去焦点导致事件丢失，物理循环也不会引用未定义的状态，顺手避免了连续按键产生的重复触发。

2.4 HUD 和遥测记录

HUD 可视化是观感最直观的部分。我用 Canvas 绘制了一个经典布局：中央是着陆器的侧视图，左上角是高度显示，右下角是垂直速度仪表，底部是燃料条。最关键的视觉元素是“目标圈”——在地面标记出允许着陆的圆形区域，HUD 同步显示当前水平投影点与目标圈的距离。这个距离是自动控制器的核心输入之一，在 HUD 里画出来之后，控制器状态和画面表现就能对上号。

遥测记录是这 11 个模块里最容易被忽略但实际价值最高的部分。我设计了一个后台环形缓冲队列，每 100ms 记录一帧，内容包括：时间戳、高度、垂直速度、水平速度、燃料、推力百分比、控制模式、姿态角。飞行结束之后，这些数据可以一键导出 CSV 文件。脚本里面只有十几行代码，但配合 Python 或 Excel 可以画出完整的着陆曲线，还能看到 PID 控制器的每个微小抖动。

3. 实操过程与核心环节实现

3.1 环境搭建与项目骨架

先说环境。整套项目不依赖任何框架，直接一个 HTML 文件加两个 JS 文件就能跑：一个负责物理和控制，一个负责渲染和 UI。如果你在本地调试，也可以用 Vite 或 Webpack 做开发服务器，但我个人推荐先零依赖跑通，再加构建工具，省得在装环境阶段劝退。

建议的项目结构：

apollo11/ index.html src/ config.js # 所有仿真参数 physics.js # 物理引擎与积分器 controller.js # 自动控制器 manualInput.js # 手动输入映射 telemetry.js # 遥测记录 renderer.js # HUD 渲染 main.js # 主循环与模块组装 assets/ terrain.png

第一步可以在index.html里放一个 Canvas 画布和一个简单的速度表占位，然后让main.js输出一行“Apollo-11 初始化完毕”。看到这行输出，说明模块加载已经正常，接下来逐步把物理状态跑起来。

3.2 仿真循环实现

仿真主循环是我全项目里最小心的地方，因为所有实时性都在这一环上决定。核心代码如下：

function simulationStep(dt) { // 1. 读取当前控制请求 const control = controlBus.getRequest(); // 2. 计算当前总质量 const fuelPerSecond = maxFuelRate * control.throttle; const newFuel = Math.max(0, lander.fuel - fuelPerSecond * dt); const actualFuel = newFuel > 0 ? newFuel : lander.fuel; const mass = lander.emptyMass + actualFuel; // 3. 计算推力 const thrust = maxThrust * control.throttle; const thrustX = thrust * Math.sin(lander.attitude); const thrustY = thrust * Math.cos(lander.attitude); // 4. 半隐式欧拉：先速度后位置 const ax = thrustX / mass; const ay = (thrustY - moonGravity) / mass; lander.vx += ax * dt; lander.vy += ay * dt; lander.x += lander.vx * dt; lander.y += lander.vy * dt; // 5. 燃料消耗 lander.fuel = actualFuel; }

这里有两个细节值得说。第一，我把重力放进了加速度计算里，而不是独立减少速度分量。这样质量变化会自动影响重力加速度的效果，避免“燃料烧完了加速度还是那么大”的隐性问题。第二，半隐式欧拉要求“先更新速度，再用新速度更新位置”，代码里严格保持了这一顺序。

主循环的调度我放在requestAnimationFrame里，但物理步长固定为 0.01 秒，用累积器控制：

const PHYSICS_DT = 0.01; let accumulator = 0; function frame(timestamp) { const frameDt = (timestamp - lastTime) / 1000; lastTime = timestamp; accumulator += frameDt; while (accumulator >= PHYSICS_DT) { simulationStep(PHYSICS_DT); telemetry.push(PHYSICS_DT); accumulator -= PHYSICS_DT; } renderer.draw(lander); requestAnimationFrame(frame); }

固定步长的好处是：物理结果不依赖浏览器帧率，不管你是 30Hz 还是 120Hz 刷新，仿真世界的钟是恒定的。代价是如果某个时刻帧率骤降，累积器可能堆积多帧，物理循环要跑好几遍，导致一瞬间“时间加速”。我的对策是给累积器一个上限，超过 0.2 秒就不再累积，宁可丢弃一点时间，也不能让系统进入追赶循环。

3.3 控制逻辑与边界处理

控制器我重点写自动着陆的逻辑。朴素的 PID 很难处理“推力只往一个方向给”的本质约束。着陆器发动机只能提供朝机体方向的推力，没有反向喷口，所以制动力只能靠“让推力向上”。当你同时需要水平减速和垂直减速时，发动机必须先倾斜一个角度，让推力同时有水平和竖直分量。

这个姿态解算在代码里是对推力方向做向量分解：

function computeAttitude(errorX, errorVx) { // 水平方向的目标是让位置偏差和速度偏差同时归零 const desiredAccelX = kpX * errorX + kvX * errorVx; // 垂直方向的目标是让下降速度趋近于安全下降率 const desiredAccelY = kpY * (targetVy - lander.vy) + moonGravity; // 姿态角则根据两个方向加速度的比例反算 const attitude = Math.atan2(desiredAccelX, desiredAccelY); return clampAttitude(attitude, maxTilt); }

这里moonGravity被加进垂直加速度里，是因为发动机必须在克服重力之后还能加速。如果漏掉这一项，控制器会把需要“抵抗重力的那一部分推力”忘掉，结果就是在空中慢悠悠地飘着，眼睁睁往下掉。

边界处理是我在调试中被反复教育的重点。推力百分比必须 clamp 到 0 和 1 之间，燃料消耗超过剩余燃料时直接按 0 计算，姿态角限制在 -30° 到 +30° 之间，避免着陆器倒扣过来导致推力方向错乱。这些限制让仿真在极端情况下也能稳定输出，不会产生天外飞仙的物理数据。

3.4 实时展示与数据落盘

渲染层我用了最简单的 Canvas 2D 接口。核心控件包括：

• 高度读数：显示在画面右上角，保留一位小数。
• 下降速度表：用垂直条表示，超过安全值由绿色变红色。
• 燃料条：宽度随剩余燃料变化，低于 20% 时闪烁提示。
• 目标圈：在月面用半透明圆环表示可着陆区域。

数据落盘更实用。当飞行状态变为“已触月”或“坠毁”时，遥测模块自动把环形缓冲区的数据整理成 CSV 字符串，并提供一个下载按钮。CSV 格式非常简单，就是八列数据加一个表头：

timestamp,altitude,vy,vx,fuel,throttle,mode,attitude 0.00,1200.0,-15.0,0.0,500.0,1.0,AUTO,0.0

拿到 CSV 之后，我习惯在 Python 里画曲线看趋势。有一个很有意思的现象：自动控制模式下，推力曲线经常会出现高频抖动，频率大概在 5Hz 左右。这是因为 PID 的 D 项对速度噪声敏感，数控模拟里的微小误差会被放大成推力波动。解决方法是给 D 项加低通滤波，或者干脆把 D 系数降到很小，只保留 PI 就够用了。

4. 常见问题与排查技巧实录

4.1 仿真发散、变量变 NaN

数值发散是仿真项目最经典的问题。现象就是飞着飞着，高度变成负数，速度变成数千上万，然后所有数字变成 NaN。我遇到的第一类原因是单位错误，比如推力写成 100 而质量只有 3，加速度直接爆表。第二类是积分器步长过大，在接近月面时速度变化太快，欧拉法追不上真实曲线，导致位置跑到月面以下，然后控制逻辑又尝试把位置拉回来，形成振荡。

排查方法很简单：在物理引擎最外层加一个数据守卫。每一步计算结束后，检查所有状态量是否为有限数值，如果发现 NaN 或绝对值超过预设上限，立即停止仿真并在控制台上打印最后十帧的遥测数据。有了这个守卫，定位问题只要看最后十帧的异常变化趋势就行。

4.2 减速不足或燃料过剩

这个问题的表现是：自动着陆时燃料消耗特别快，最后在几十米高度燃料归零，着陆器直直坠落。我检查了遥测曲线，发现控制器从一开始就给出 100% 推力，一直烧到 20 秒后燃料耗尽，速度却始终压不住。为什么 100% 推力还压不住速度？因为初始高度太高，按 100% 推力持续减速也需要一段时间，如果初始高度是 5000 米、初始速度是 -100m/s，那么即使全力反推，也要先减速很久才能逆转运动趋势。

这引出一个重要的认知：着陆过程本质上是“燃料预算 + 高度测量 + 速度控制”三者的平衡。解决方案是在开始时计算理论需求：如果从当前高度按最大加速度能安全刹停，就不需要全力推，而是按“需要多少推多少”的原则输出。我写了一个简化函数，在每一帧计算“当前速度在目标高度内能否被刹住”，如果能，就逐步减小推力，保持最低安全下降率。这个逻辑上线之后，燃料消耗降低了大概 30%，而且触地速度更一致。

4.3 前端卡顿与日志爆炸

前端卡顿有时候不是渲染压力，而是数据堆积。我最初记录遥测的间隔是 10ms，一次 3 分钟飞行就会产生 18000 条数据，JavaScript 数组虽然扛得住，但 Canvas 重绘时如果也把这些数据全部扫一遍，就必然掉帧。

优化办法是把数据记录与渲染解耦：遥测数据最大保留最近 5000 个点，用环形数组覆盖写入，渲染只显示最近 100 个点。下载 CSV 时再把环形数组转线性数组导出。另一个隐藏问题是 Canvas 的阴影效果，Canvas 阴影在频繁重绘时极吃性能，我把 HUD 的阴影全部改成了普通描线，整体帧率提升了一倍不止。

4.4 排查工具与对策速查表

我最推荐的工具组合是浏览器开发者工具加一个自定义绘图库。在控制台里，开发工具能打出每一帧的数据摘要；自定义绘图库则可以把遥测曲线直接叠加在 HUD 上，相当于“控制器的可视大脑”。比如你可以画出“期望速度变化率”和“实际速度变化率”两条曲线，两者吻合就说明控制逻辑没问题，不吻合就要去查动力学模型。

5. 扩展空间与个人心得

5.1 把纯仿真往真实硬件方向扩展

这套纯软件项目做完之后，我一度觉得不过瘾，开始琢磨怎么把仿真和物理世界连接起来。最简单的扩展是加一个“数据回放 + 真实传感器模拟”的假模块：利用真实地形高程数据生成月面高度场，让着陆器在起伏地形里选择着陆点。这个扩展对算法能力要求一下子上来了，因为你需要实时判断地形坡度并调整落点，而不是对着一个平坦的圆环着陆。

更进一步的硬件扩展方案是接一个惯性测量单元（IMU），把仿真的姿态替换成真实传感器的读数，这样整个系统就变成了一个“半物理仿真平台”。我在调研时甚至给这套系统规划过串口通信模块，让遥测数据直接喂给真实的下位机控制板，闭环控制实验就能脱离浏览器独立运转。虽然最后没有完全落地，但架构上因为从一开始就是模块隔离的，想接什么硬件都能用很低的成本接入，这是我前期做了充分模块化设计的最大红利。

5.2 踩过坑之后我的几条体会

现在回头复盘，这套系统里最值钱的东西不是代码，而是对“闭环反馈”这件事的理解。

第一，物理仿真里没有免费的稳定。任何声称“零配置稳定”的控制器都是因为它的物理模型太简单，或者你的目标速度刚好避开了问题区域。要想让系统稳定，必须在每个阶段都做状态约束，该 clamp 就 clamp，该限制变化率就限制变化率。

第二，数据永远是调试的第一现场。没有遥测记录，就没有一切。我第一次调试 PID 时为了省事只盯着画面看，觉得“差不多稳了”，结果一导 CSV 发现推力在 200ms 内来回切换了几十次，这种高频摆动肉眼根本看不出来，但它会严重影响燃料消耗和设备寿命。数据曲线能让你看到肉眼看不到的高频现象。

第三，参数调优是一个系统性问题，不是单个 P、I、D 的事。你调整重力参数会影响阶段划分，调整阶段划分会影响 PID 输出范围，调整输出范围又影响燃料消耗。最有效的方式是先固定其他变量，只动一个参数，记录一次飞行，再对比曲线。我在这套项目上大概做了 200 多次参数实验，每次只改一个值，最终才得到一组满意的控制器参数。

5.3 后续这一步怎么继续玩

如果你也想做一个类似的仿真系统，我建议按这个顺序来：先跑通最简单的欧拉积分，让着陆器能下落和触地；然后加手动控制，体会一下什么叫“危险”；再加入自动控制器，让软件替你接管最难的部分。刚起步时不要追求画面精细度，一个速度表和一根高度条足够诊断所有问题。

等基础闭环稳定了，再加入重力梯度、地形高度场、传感器噪声这些“真实世界的麻烦”。这些麻烦才是真正区分“玩具项目”和“工程项目”的分水岭。我个人接下来的计划，是把物理引擎搬到 WebAssembly 上，然后用同一套遥测协议对接固定翼飞行器的真实传感器数据，把 Apollo-11 从一个仿真玩具慢慢变成控制算法的试验床。这个方向能不能走通，我还在验证，但至少有一点是确定的：只要物理模型和数据记录这两块地基够扎实，这套系统就能一直在新的场景里焕发出新的生命力。