1. 一台“老电脑”如何在火星上跑出自动驾驶新纪录毅力号火星车最近又刷新了一项纪录在一次长途行驶中超过90%的行程由自主导航系统完成地面团队几乎没有进行任何干预。这个数字放在地球上的自动驾驶领域也许不算惊人但放在火星上意义完全不同。火星与地球之间的通信延迟少则几分钟多则二十多分钟这意味着火星车每走一步都等地面指令效率会低到令人发指。它必须自己“看路”、自己“判断”、自己“决策”。更让人意外的是完成这一壮举的计算机硬件性能远不如你手里那台千元手机。它的主处理器是一颗已有二十多年历史的抗辐射芯片主频只有200MHz左右内存也小得可怜。用这样一套“老古董”配置在数亿公里外的陌生星球上实现高比例自主行驶背后的工程思路值得每一个做嵌入式、机器人或自动驾驶的人认真琢磨。这篇文章不打算复述新闻而是想从技术实现的角度拆解几个核心问题毅力号的自主导航到底是怎么工作的为什么用这么老的硬件还能跑出90%的自主率它的软件架构做了哪些取舍以及这些经验对地面上的机器人项目有什么可借鉴之处。无论你是做嵌入式开发、机器人导航还是对自动驾驶的工程落地感兴趣相信都能从中拿到一些能直接用的思路。2. 火星自动驾驶的真实难点不是算力是“不确定性”2.1 通信延迟把“遥控”变成了“放权”地球到火星的单程通信延迟最近距离时大约3到4分钟最远时超过20分钟。这意味着地面团队看到火星车传回的图像时那个画面已经是几分钟甚至二十几分钟前的状态。如果火星车每走一米都要等地面确认那它一天也走不了几米。更麻烦的是火星车在行驶过程中会遇到各种突发情况前方突然出现松软的沙地、一块尖锐的岩石、一个陡坡这些都需要在几秒内做出判断。等地面指令回来车可能已经陷进去了。所以毅力号的自主导航不是“锦上添花”的功能而是“没有它任务就干不下去”的刚需。地面团队的角色从“驾驶员”变成了“任务规划师”——他们告诉火星车“今天去那个区域大概走这条路线”剩下的具体怎么走、遇到障碍怎么绕全交给车自己决定。2.2 硬件限制倒逼软件架构做减法毅力号的主计算机被称为“RAD750”这是一款专门为航天环境设计的抗辐射处理器。它的核心频率只有200MHz内存大约256MB存储空间也相当有限。对比一下你手机里的处理器主频动辄2GHz以上内存8GB起步。也就是说毅力号的算力大概只有你手机的百分之一甚至更低。但火星环境不允许用商用芯片。宇宙射线会把普通芯片的电路打乱导致计算错误甚至永久损坏。RAD750经过特殊加固能承受高辐射环境代价就是性能大幅落后。这就逼着软件团队必须做极致的优化算法不能太复杂内存占用要精打细算每一帧图像的处理时间都要控制在毫秒级。2.3 感知、规划、控制必须在本地闭环在地球上做自动驾驶你可以把大量计算放到云端或者用大模型做复杂的场景理解。但在火星上所有计算都必须在车上完成而且要在极短的时间内完成。毅力号的自主导航系统需要实时完成以下任务用导航相机拍摄前方地形生成三维点云或深度图识别可通行区域和障碍物规划一条安全的局部路径生成转向和速度指令控制车轮执行这个闭环必须在几秒内完成否则车就会停下来等效率大打折扣。而这一切都要在200MHz的处理器上跑起来。3. 拆解毅力号的自主导航链路从“看”到“走”的每一步3.1 视觉里程计与地形建模用双目相机“看懂”火星表面毅力号身上有一套专门的导航相机系统通常安装在桅杆高处由两个或多个相机组成通过双目立体视觉来感知三维地形。它的工作原理和人的双眼类似左右相机拍摄同一场景通过视差计算出每个像素点的距离从而生成一张深度图。这张深度图会被转换成“地形网格”或“代价地图”每个格子代表一小块区域格子里标注着“可通行”“障碍”“未知”等状态。可通行区域通常是平坦的、没有大石块的沙地或岩石表面障碍则是陡坡、大石头、深坑等未知区域则是相机看不到或看不清的地方系统会保守地将其视为不可通行。这里有一个关键细节火星表面的纹理非常单调到处都是类似的沙土和岩石这给立体匹配带来了很大挑战。地球上的双目视觉算法可以依赖丰富的纹理特征来匹配左右图像但在火星上很多区域看起来几乎一模一样。毅力号的软件团队为此专门优化了匹配算法加入了边缘检测和区域分割等辅助手段确保在低纹理环境下也能生成可靠的地形图。3.2 局部路径规划在“看得见”的范围内找一条最稳的路有了地形图之后下一步就是规划路径。毅力号采用的是一种“局部规划”策略它不会一次性规划出几公里外的完整路线而是只关注前方几十米范围内的地形在这个范围内找一条从当前位置到下一个目标点的安全路径。这种策略的好处是计算量小、响应快。局部规划算法通常基于“代价地图”做搜索比如用A或D算法在网格上找一条总代价最低的路径。代价的计算会考虑多种因素距离目标的远近、地形的坡度、地面的粗糙程度、与障碍物的距离等。系统会倾向于选择平坦、开阔、远离障碍的路线即使这意味着绕一点远路。这里有一个工程上的取舍如果规划得太保守火星车会频繁绕路行驶效率降低如果太激进又可能陷入危险地形。毅力号的团队通过大量地面测试和火星实际运行数据不断调整代价函数的权重才找到了一个相对平衡的点。3.3 运动控制与执行把路径变成车轮的转动规划出路径之后控制系统需要把路径转换成具体的车轮转速和转向角度。毅力号有六个轮子每个轮子都可以独立驱动和转向这给了它很强的机动能力。控制系统会根据当前位姿和目标路径计算出每个轮子应该转多快、转多少角度然后通过电机驱动器执行。这里的一个难点是“打滑”问题。火星表面的沙地很软车轮容易打滑导致实际行驶轨迹和规划轨迹出现偏差。毅力号通过视觉里程计实时估计自己的实际位置并与规划位置对比如果偏差太大就会重新规划路径。这种“感知-规划-控制”的闭环每隔几秒就运行一次确保火星车始终在安全的路线上。4. 为什么“老电脑”能跑出高自主率软件工程的极致取舍4.1 算法复杂度与实时性的平衡在200MHz的处理器上跑自主导航最大的挑战是算法复杂度。如果算法太复杂计算时间就会超过控制周期导致火星车走走停停。毅力号的软件团队在算法选择上做了大量取舍立体匹配没有用深度学习而是用了传统的块匹配加后处理计算量可控路径规划没有用全局优化而是用了局部搜索牺牲了全局最优性换取实时性地形分类没有用复杂的语义分割而是用了基于几何特征的简单分类器这些选择看起来“落后”但在火星环境下是最务实的。深度学习模型虽然效果好但推理时间长、内存占用大在RAD750上根本跑不起来。传统算法虽然精度稍低但计算量小、可预测性强更适合实时控制。4.2 代码层面的优化每一毫秒都要抠除了算法选择代码实现也做了大量优化。比如用定点数代替浮点数减少计算开销用查表法代替实时计算把常用函数的结果预先算好用内存池管理代替动态分配避免内存碎片和分配延迟用多级流水线并行处理图像提高吞吐量这些优化手段在地球上的嵌入式开发中也很常见但毅力号的团队把它们用到了极致。据说整个自主导航软件的代码量并不大但每一行都经过反复审查和测试确保在极端环境下也能稳定运行。4.3 冗余与容错不怕出错怕的是出错后不知道火星车一旦出错地面团队很难快速修复。所以毅力号的软件设计了多层冗余和容错机制关键数据有多份副本定期校验每个控制周期都有超时检测如果某个模块没按时完成系统会降级运行如果自主导航完全失效火星车会停下来等待地面指令不会盲目乱走这种“安全第一”的设计哲学是火星任务和地面机器人项目最大的区别。地面机器人出错了可以重启火星车出错了可能整个任务就结束了。5. 从火星到地球哪些经验可以直接搬进你的机器人项目5.1 局部规划比全局规划更实用很多地面机器人项目一上来就想做全局路径规划结果发现计算量大、响应慢遇到动态障碍就傻眼了。毅力号的思路是先做局部规划保证在看得见的范围内能安全行驶全局规划只作为参考。这个思路在地面机器人上同样适用尤其是算力有限的嵌入式平台。你可以这样操作把全局路径分成若干段每段只关注前方几米到十几米的范围用局部规划算法生成具体路径。全局路径只用来决定大方向局部规划负责避障和调整。这样既能保证实时性又能完成长距离导航。5.2 感知要“够用就好”不要追求完美毅力号的感知系统并不追求识别所有物体它只关心“能不能走”。这种“够用就好”的思路可以大幅降低感知算法的复杂度。在地面机器人上你也可以这样做不需要识别出前方是猫还是狗只需要判断“这个区域是否可通行”。用简单的几何特征加分类器往往比复杂的深度学习模型更实用。5.3 容错设计要从第一天就做很多地面机器人项目在开发阶段不考虑容错等到实际部署时才发现各种问题。毅力号的经验是容错设计要从第一天就做每个模块都要有超时检测、数据校验和降级策略。比如如果视觉里程计失效系统应该能切换到轮式里程计如果局部规划失败系统应该能停下来等待指令而不是继续乱走。5.4 测试要覆盖极端场景火星车在地面测试时团队会模拟各种极端场景沙地、岩石、陡坡、低纹理区域、光照变化等。这些测试帮助发现了大量软件问题。地面机器人项目也应该这样做在实验室里搭建各种地形用不同光照条件测试记录每次失败的原因然后针对性修复。6. 实测中的意外与应对火星自动驾驶的“坑”与解法6.1 沙地打滑导致里程计漂移毅力号在火星上遇到过多次沙地打滑的情况。车轮陷进松软沙地后实际行驶距离远小于轮子转过的距离导致轮式里程计严重漂移。视觉里程计虽然能纠正一部分但在低纹理沙地上也会失效。团队的应对策略是当检测到打滑时降低行驶速度增加视觉里程计的更新频率同时用惯性测量单元辅助估计位姿。这个经验对地面机器人同样有用如果你的机器人在沙地或湿滑地面行驶一定要有打滑检测和补偿机制。可以用轮速和实际速度的比值来判断打滑程度然后调整控制策略。6.2 低纹理区域导致立体匹配失败火星表面很多区域纹理非常单调立体匹配算法找不到足够的特征点导致深度图出现大片空洞。毅力号的团队通过引入边缘检测和区域分割在低纹理区域也能生成可用的地形图。具体做法是先用边缘检测找出岩石和沙地的边界然后用区域分割把图像分成若干块每块内部假设深度连续从而填补空洞。这个思路在地面机器人上也可以借鉴如果你的双目视觉在白色墙壁或纯色地板上失效可以加入边缘检测和区域分割用几何约束来辅助深度估计。6.3 通信窗口有限导致任务规划受限火星车每天能跟地面通信的时间窗口有限通常只有一两次每次几十分钟。这意味着地面团队必须在有限的时间内上传指令、下载数据。如果自主导航系统在通信窗口之外出现问题火星车只能自己处理。毅力号的应对策略是在通信窗口内尽量上传详细的规划指令同时让自主导航系统有足够的自主权在窗口外也能安全行驶。这个经验对地面机器人项目也有启发如果你的机器人需要在通信受限的环境下工作比如地下管道、深海一定要让机器人有足够的自主能力不能完全依赖远程控制。7. 个人经验从火星车学到的嵌入式导航设计原则我在实际做嵌入式机器人项目时经常想起毅力号的这些设计思路。有一次做一个室外巡检机器人算力平台是一块主频几百兆的嵌入式板子跑复杂的视觉算法根本跑不动。后来参考了毅力号的思路把感知算法简化成“可通行区域检测”用传统的图像处理方法代替深度学习结果在低算力平台上也能跑到10Hz以上的控制频率实际运行效果比预想的好很多。另一个体会是容错设计真的不能省。我见过太多项目在演示时跑得很好一到实际环境就各种崩溃。后来我在每个模块都加了超时检测和降级策略比如视觉模块超时就切换到里程计规划模块失败就停下来重新初始化。这些改动看起来增加了开发工作量但实际部署时省下的调试时间远超预期。最后分享一个小技巧如果你也在做低算力平台的导航项目可以试试把常用的计算做成查表。比如三角函数的计算结果预先算好存成数组运行时直接查表能省下不少计算时间。这个技巧在毅力号的软件里也有用到虽然简单但在资源受限的环境下非常有效。 
长河君 · 2026/10/24 7:07:00 · 阅读 1.2k 毅力号火星车200MHz老芯片实现90%自主导航的工程启示
1. 一台“老电脑”如何在火星上跑出自动驾驶新纪录毅力号火星车最近又刷新了一项纪录在一次长途行驶中超过90%的行程由自主导航系统完成地面团队几乎没有进行任何干预。这个数字放在地球上的自动驾驶领域也许不算惊人但放在火星上意义完全不同。火星与地球之间的通信延迟少则几分钟多则二十多分钟这意味着火星车每走一步都等地面指令效率会低到令人发指。它必须自己“看路”、自己“判断”、自己“决策”。更让人意外的是完成这一壮举的计算机硬件性能远不如你手里那台千元手机。它的主处理器是一颗已有二十多年历史的抗辐射芯片主频只有200MHz左右内存也小得可怜。用这样一套“老古董”配置在数亿公里外的陌生星球上实现高比例自主行驶背后的工程思路值得每一个做嵌入式、机器人或自动驾驶的人认真琢磨。这篇文章不打算复述新闻而是想从技术实现的角度拆解几个核心问题毅力号的自主导航到底是怎么工作的为什么用这么老的硬件还能跑出90%的自主率它的软件架构做了哪些取舍以及这些经验对地面上的机器人项目有什么可借鉴之处。无论你是做嵌入式开发、机器人导航还是对自动驾驶的工程落地感兴趣相信都能从中拿到一些能直接用的思路。2. 火星自动驾驶的真实难点不是算力是“不确定性”2.1 通信延迟把“遥控”变成了“放权”地球到火星的单程通信延迟最近距离时大约3到4分钟最远时超过20分钟。这意味着地面团队看到火星车传回的图像时那个画面已经是几分钟甚至二十几分钟前的状态。如果火星车每走一米都要等地面确认那它一天也走不了几米。更麻烦的是火星车在行驶过程中会遇到各种突发情况前方突然出现松软的沙地、一块尖锐的岩石、一个陡坡这些都需要在几秒内做出判断。等地面指令回来车可能已经陷进去了。所以毅力号的自主导航不是“锦上添花”的功能而是“没有它任务就干不下去”的刚需。地面团队的角色从“驾驶员”变成了“任务规划师”——他们告诉火星车“今天去那个区域大概走这条路线”剩下的具体怎么走、遇到障碍怎么绕全交给车自己决定。2.2 硬件限制倒逼软件架构做减法毅力号的主计算机被称为“RAD750”这是一款专门为航天环境设计的抗辐射处理器。它的核心频率只有200MHz内存大约256MB存储空间也相当有限。对比一下你手机里的处理器主频动辄2GHz以上内存8GB起步。也就是说毅力号的算力大概只有你手机的百分之一甚至更低。但火星环境不允许用商用芯片。宇宙射线会把普通芯片的电路打乱导致计算错误甚至永久损坏。RAD750经过特殊加固能承受高辐射环境代价就是性能大幅落后。这就逼着软件团队必须做极致的优化算法不能太复杂内存占用要精打细算每一帧图像的处理时间都要控制在毫秒级。2.3 感知、规划、控制必须在本地闭环在地球上做自动驾驶你可以把大量计算放到云端或者用大模型做复杂的场景理解。但在火星上所有计算都必须在车上完成而且要在极短的时间内完成。毅力号的自主导航系统需要实时完成以下任务用导航相机拍摄前方地形生成三维点云或深度图识别可通行区域和障碍物规划一条安全的局部路径生成转向和速度指令控制车轮执行这个闭环必须在几秒内完成否则车就会停下来等效率大打折扣。而这一切都要在200MHz的处理器上跑起来。3. 拆解毅力号的自主导航链路从“看”到“走”的每一步3.1 视觉里程计与地形建模用双目相机“看懂”火星表面毅力号身上有一套专门的导航相机系统通常安装在桅杆高处由两个或多个相机组成通过双目立体视觉来感知三维地形。它的工作原理和人的双眼类似左右相机拍摄同一场景通过视差计算出每个像素点的距离从而生成一张深度图。这张深度图会被转换成“地形网格”或“代价地图”每个格子代表一小块区域格子里标注着“可通行”“障碍”“未知”等状态。可通行区域通常是平坦的、没有大石块的沙地或岩石表面障碍则是陡坡、大石头、深坑等未知区域则是相机看不到或看不清的地方系统会保守地将其视为不可通行。这里有一个关键细节火星表面的纹理非常单调到处都是类似的沙土和岩石这给立体匹配带来了很大挑战。地球上的双目视觉算法可以依赖丰富的纹理特征来匹配左右图像但在火星上很多区域看起来几乎一模一样。毅力号的软件团队为此专门优化了匹配算法加入了边缘检测和区域分割等辅助手段确保在低纹理环境下也能生成可靠的地形图。3.2 局部路径规划在“看得见”的范围内找一条最稳的路有了地形图之后下一步就是规划路径。毅力号采用的是一种“局部规划”策略它不会一次性规划出几公里外的完整路线而是只关注前方几十米范围内的地形在这个范围内找一条从当前位置到下一个目标点的安全路径。这种策略的好处是计算量小、响应快。局部规划算法通常基于“代价地图”做搜索比如用A或D算法在网格上找一条总代价最低的路径。代价的计算会考虑多种因素距离目标的远近、地形的坡度、地面的粗糙程度、与障碍物的距离等。系统会倾向于选择平坦、开阔、远离障碍的路线即使这意味着绕一点远路。这里有一个工程上的取舍如果规划得太保守火星车会频繁绕路行驶效率降低如果太激进又可能陷入危险地形。毅力号的团队通过大量地面测试和火星实际运行数据不断调整代价函数的权重才找到了一个相对平衡的点。3.3 运动控制与执行把路径变成车轮的转动规划出路径之后控制系统需要把路径转换成具体的车轮转速和转向角度。毅力号有六个轮子每个轮子都可以独立驱动和转向这给了它很强的机动能力。控制系统会根据当前位姿和目标路径计算出每个轮子应该转多快、转多少角度然后通过电机驱动器执行。这里的一个难点是“打滑”问题。火星表面的沙地很软车轮容易打滑导致实际行驶轨迹和规划轨迹出现偏差。毅力号通过视觉里程计实时估计自己的实际位置并与规划位置对比如果偏差太大就会重新规划路径。这种“感知-规划-控制”的闭环每隔几秒就运行一次确保火星车始终在安全的路线上。4. 为什么“老电脑”能跑出高自主率软件工程的极致取舍4.1 算法复杂度与实时性的平衡在200MHz的处理器上跑自主导航最大的挑战是算法复杂度。如果算法太复杂计算时间就会超过控制周期导致火星车走走停停。毅力号的软件团队在算法选择上做了大量取舍立体匹配没有用深度学习而是用了传统的块匹配加后处理计算量可控路径规划没有用全局优化而是用了局部搜索牺牲了全局最优性换取实时性地形分类没有用复杂的语义分割而是用了基于几何特征的简单分类器这些选择看起来“落后”但在火星环境下是最务实的。深度学习模型虽然效果好但推理时间长、内存占用大在RAD750上根本跑不起来。传统算法虽然精度稍低但计算量小、可预测性强更适合实时控制。4.2 代码层面的优化每一毫秒都要抠除了算法选择代码实现也做了大量优化。比如用定点数代替浮点数减少计算开销用查表法代替实时计算把常用函数的结果预先算好用内存池管理代替动态分配避免内存碎片和分配延迟用多级流水线并行处理图像提高吞吐量这些优化手段在地球上的嵌入式开发中也很常见但毅力号的团队把它们用到了极致。据说整个自主导航软件的代码量并不大但每一行都经过反复审查和测试确保在极端环境下也能稳定运行。4.3 冗余与容错不怕出错怕的是出错后不知道火星车一旦出错地面团队很难快速修复。所以毅力号的软件设计了多层冗余和容错机制关键数据有多份副本定期校验每个控制周期都有超时检测如果某个模块没按时完成系统会降级运行如果自主导航完全失效火星车会停下来等待地面指令不会盲目乱走这种“安全第一”的设计哲学是火星任务和地面机器人项目最大的区别。地面机器人出错了可以重启火星车出错了可能整个任务就结束了。5. 从火星到地球哪些经验可以直接搬进你的机器人项目5.1 局部规划比全局规划更实用很多地面机器人项目一上来就想做全局路径规划结果发现计算量大、响应慢遇到动态障碍就傻眼了。毅力号的思路是先做局部规划保证在看得见的范围内能安全行驶全局规划只作为参考。这个思路在地面机器人上同样适用尤其是算力有限的嵌入式平台。你可以这样操作把全局路径分成若干段每段只关注前方几米到十几米的范围用局部规划算法生成具体路径。全局路径只用来决定大方向局部规划负责避障和调整。这样既能保证实时性又能完成长距离导航。5.2 感知要“够用就好”不要追求完美毅力号的感知系统并不追求识别所有物体它只关心“能不能走”。这种“够用就好”的思路可以大幅降低感知算法的复杂度。在地面机器人上你也可以这样做不需要识别出前方是猫还是狗只需要判断“这个区域是否可通行”。用简单的几何特征加分类器往往比复杂的深度学习模型更实用。5.3 容错设计要从第一天就做很多地面机器人项目在开发阶段不考虑容错等到实际部署时才发现各种问题。毅力号的经验是容错设计要从第一天就做每个模块都要有超时检测、数据校验和降级策略。比如如果视觉里程计失效系统应该能切换到轮式里程计如果局部规划失败系统应该能停下来等待指令而不是继续乱走。5.4 测试要覆盖极端场景火星车在地面测试时团队会模拟各种极端场景沙地、岩石、陡坡、低纹理区域、光照变化等。这些测试帮助发现了大量软件问题。地面机器人项目也应该这样做在实验室里搭建各种地形用不同光照条件测试记录每次失败的原因然后针对性修复。6. 实测中的意外与应对火星自动驾驶的“坑”与解法6.1 沙地打滑导致里程计漂移毅力号在火星上遇到过多次沙地打滑的情况。车轮陷进松软沙地后实际行驶距离远小于轮子转过的距离导致轮式里程计严重漂移。视觉里程计虽然能纠正一部分但在低纹理沙地上也会失效。团队的应对策略是当检测到打滑时降低行驶速度增加视觉里程计的更新频率同时用惯性测量单元辅助估计位姿。这个经验对地面机器人同样有用如果你的机器人在沙地或湿滑地面行驶一定要有打滑检测和补偿机制。可以用轮速和实际速度的比值来判断打滑程度然后调整控制策略。6.2 低纹理区域导致立体匹配失败火星表面很多区域纹理非常单调立体匹配算法找不到足够的特征点导致深度图出现大片空洞。毅力号的团队通过引入边缘检测和区域分割在低纹理区域也能生成可用的地形图。具体做法是先用边缘检测找出岩石和沙地的边界然后用区域分割把图像分成若干块每块内部假设深度连续从而填补空洞。这个思路在地面机器人上也可以借鉴如果你的双目视觉在白色墙壁或纯色地板上失效可以加入边缘检测和区域分割用几何约束来辅助深度估计。6.3 通信窗口有限导致任务规划受限火星车每天能跟地面通信的时间窗口有限通常只有一两次每次几十分钟。这意味着地面团队必须在有限的时间内上传指令、下载数据。如果自主导航系统在通信窗口之外出现问题火星车只能自己处理。毅力号的应对策略是在通信窗口内尽量上传详细的规划指令同时让自主导航系统有足够的自主权在窗口外也能安全行驶。这个经验对地面机器人项目也有启发如果你的机器人需要在通信受限的环境下工作比如地下管道、深海一定要让机器人有足够的自主能力不能完全依赖远程控制。7. 个人经验从火星车学到的嵌入式导航设计原则我在实际做嵌入式机器人项目时经常想起毅力号的这些设计思路。有一次做一个室外巡检机器人算力平台是一块主频几百兆的嵌入式板子跑复杂的视觉算法根本跑不动。后来参考了毅力号的思路把感知算法简化成“可通行区域检测”用传统的图像处理方法代替深度学习结果在低算力平台上也能跑到10Hz以上的控制频率实际运行效果比预想的好很多。另一个体会是容错设计真的不能省。我见过太多项目在演示时跑得很好一到实际环境就各种崩溃。后来我在每个模块都加了超时检测和降级策略比如视觉模块超时就切换到里程计规划模块失败就停下来重新初始化。这些改动看起来增加了开发工作量但实际部署时省下的调试时间远超预期。最后分享一个小技巧如果你也在做低算力平台的导航项目可以试试把常用的计算做成查表。比如三角函数的计算结果预先算好存成数组运行时直接查表能省下不少计算时间。这个技巧在毅力号的软件里也有用到虽然简单但在资源受限的环境下非常有效。