从扫地机器人拆解看嵌入式全栈开发：传感器融合、SLAM与PID控制的实战全指南

开源项目看多了你会发现一个规律：越是贴近日常生活的项目，学到的工程知识反而越硬核。扫地机器人就是个典型例子，一台售价几百元的机器，里面塞着传感器融合、电机控制、路径规划、嵌入式实时系统、无线通信、App 联动——这哪是家电，分明是一套浓缩版的机器人工程全栈课程。我自己在复现了几个开源扫地机器人项目之后，最大的感受是：只要把这个项目拆透，你对“全栈工程师”的理解会比刷一年教程都深刻。

这篇内容我会从硬件、嵌入式、算法、系统集成四个层面逐一拆解，把开源扫地机器人背后的技术栈、实现难点和我实际踩过的坑都拉出来聊一遍。无论你是刚接触嵌入式的学生，还是想转行机器人方向的后端或前端工程师，都可以从里面找自己的切入点。

1. 为什么扫地机器人是最合适的全栈入门项目

机器人工程的门槛高，是因为它天然是多学科交叉的产物。机械结构涉及运动学和动力学，电子涉及电机驱动和电源管理，嵌入式涉及实时控制和资源调度，算法涉及滤波、建图、路径规划，上层还要有通信协议和可视化界面。随便挑一个方向都是独立学科，想通过读书串联起来，难度极高。

扫地机器人恰好是这些学科的“最小可行交集”。它不需要机械臂那样复杂的运动学建模，不需要自动驾驶那样海量的感知数据，但核心闭环一个不少：传感器采集环境信息，主控处理并做出决策，电机执行动作，再把状态回传。这套闭环只要你跑通一次，机器人工程的“手感”就出来了。

第二个优势是它有明确的验收标准。一个扫地机器人做得好不好，看三件事就行：漏扫面积多不多，重复扫的面积多不多，困住回不了基站的情况多不多。这比“写了一个神经网络”要好量化得多。我见过的很多初学者项目，往往死于目标模糊，而扫地机器人天然自带一套评价体系。

第三个优势是开源社区积累足够厚。从单纯的底盘驱动到完整的激光 SLAM 方案，从几百元成本的自制方案到基于 ROS 的专业框架，GitHub 上都有现成案例。这不是让你直接抄，而是给你一条从简到难的学习路径。比如你可以先实现自动回充，再实现碰撞检测避障，最后再上真正的 SLAM，每一级都有对应的开源参考。

最后一点特别有意思：扫地机器人是一个消费级产品，这意味着它的成本和体积约束非常严格。你不可能在机器人上装一台工作站跑深度学习，必须学会在有限资源下做取舍。这种“带着镣铐跳舞”的感觉，恰恰是工业级项目最常见的状态，也是课程作业里很难模拟的真实工程压力。

2. 硬件层拆解：从电机到传感器的选型逻辑

2.1 驱动方案：左右差速底盘为什么是主流

扫地机器人几乎清一色采用左右双轮差速底盘，中置的驱动轮加上前后或者侧边的万向轮，构成三点支撑。左右轮速度不同，机器就会转弯，速度差越大，转弯半径越小，极端情况下两个轮子速度相反，就能实现原地掉头。这种底盘结构简单、控制直观、室内场景灵活性足够，所以成了绝对主流。

电机选择上，最常见的是带霍尔编码器的直流减速电机。减速箱的作用是把电机的高转速降下来，同时放大扭矩，不然那个小电机根本拖动整机。霍尔编码器则用来测轮子的转速，是实现闭环速度控制的基础。选型时要关注三个参数：减速比、额定扭矩和编码器分辨率。减速比通常在 30:1 到 50:1 之间，扭矩至少要在 0.5 kg·cm 以上，编码器分辨率越高，转速测量越细腻，但对应的读取频率压力也越大。

我在一个开源项目里看到过用 30:1 减速比电机的方案，配合 11 线的霍尔编码器，轮子转一圈能输出 330 个脉冲。实测下来，速度闭环的精度大概在正负百分之五以内，这个精度拖地是够用的。但如果你想让机器人走一条笔直的墙边路径，就会发现事情没那么简单——左右电机哪怕同型号，实际转速也会有细微差异，机械结构阻尼也不完全一致，必须依赖编码器闭环来校正，这直接引出了 PID 控制的话题。

2.2 传感器组合：从碰壁反弹到环境建模的层次感

传感器方案直接决定了扫地机器人“聪明”的上限。最基础的是碰撞传感器，机器撞到障碍物后触发回弹，这种方案简单可靠但体验一般。往上一点的方案是红外测距，通过红外发射接收来判断前方是否有障碍，但这种方案容易受光照干扰，黑色的物体还会吸收红外线导致漏检。

再往上就是陀螺仪和 IMU。陀螺仪能测角速度，配合里程计可以做简单的航向推算，让机器在靠墙清扫时大致保持直线。而更高端的方案是激光雷达或 ToF 传感器，激光雷达通过旋转扫描获取周围环境点云数据，配合 SLAM 算法就能实时建图。开源项目中最常出镜的 RPLIDAR A1 系列，测距半径 12 米，采样频率 8000 次每秒，做室内定位和建图足够用。

还有一类传感器容易被忽略但非常重要：跌落传感器。扫地机器人能爬上地毯，能越过门槛，但也可能从楼梯口掉下去。跌落传感器通常就是几个朝下的红外传感器，检测到下方虚空时立刻停止前进并后退。这些传感器价格极低，一个才几块钱，但缺失了它，整个机器人就谈不上安全性。我做测试时有一次忘了装，直接把机器放在桌上让它自由跑，结果它直直地冲下了桌沿，那一瞬间你就能理解为什么这类传感器被列为安全件。

2.3 主控与供电：算力怎么分配，电源怎么稳住

主控芯片的选择很有意思。入门方案大多用 STM32F103 这种级别的 MCU，主频 72MHz，RAM 才 20KB 左右。你可能觉得这配置也太寒酸了，但在扫地机器人这里还真够用。电机控制、传感器读取、简单的避障逻辑，这些都是裸机或者 RTOS 上就能跑的任务。在上一代开源项目里，一片 STM32 同时承担了电机 PID、编码器读取、碰撞传感器扫描、红外避障和与手机 App 的串口通信，所有任务跑在 50Hz 的主循环里，稳稳当当。

但如果你要上 SLAM，情况就变了。激光雷达的测距数据每秒 8000 次，需要实时处理，建图算法涉及里程计推算、扫描匹配和地图更新，这已经不是 MCU 能扛得住的了。所以现在的常见架构是上下位机分离：下位机用 STM32 做实时电机控制和传感器读取，上位机用树莓派或者 RK3399 这类 Linux 单板跑 SLAM 和路径规划算法。两板之间通过 UART 或者 USB 通信，下位机上报里程计和传感器状态，上位机下发速度指令。这种分工本质上是“硬实时”和“复杂计算”的分离，在工业机器人里面也完全一样的套路。

供电这块有大学问。电机启动瞬间的电流脉冲非常大，如果和主控共用电源轨，电压跌落轻则导致单片机关机重启，重则损坏逻辑电路。我见过一个翻车案例：电池电压标称 7.4V，电机一启动，主控供电轨上直接被拉低到 3.2V，单片机直接进入欠压复位循环，机器一动就重启。正确做法是一定要分电源域，电机电源和控制电源之间做好隔离或者至少用好滤波电容和线性稳压。电池本身建议选 18650 锂电包或者带保护板的锂电池组，容量在 2000mAh 到 5000mAh 之间，保证一次完整清扫的电量余量在 30% 以上。

3. 嵌入式层：让代码在裸机上优雅地跑起来

3.1 控制主循环：从轮询到状态机

下位机代码的核心是一个固定的主循环。控制周期一般设在 10ms 到 20ms，也就是频率 50Hz 到 100Hz，这对运动控制来说已经足够了。LED、蜂鸣器、碰撞传感器这类低频任务，合并在主循环里做轮询，不单独占用资源。而编码器脉冲读取则需要外部中断来做计数，不管主循环多久跑一次，脉冲都不能丢，丢一个脉冲就意味着里程计产生了误差，这些误差会顺着积分过程累积，漂移就是这么来的。

主循环里最怕的就是“一个任务阻塞住所有任务”。比如你是用阻塞式延时来驱动超声波模块测距，那这几十毫秒内 MCU 全被占住了，另一个线程想读编码器都插不上手。我调试时遇到过一个非常隐蔽的问题：机器人直线走得好好的，一靠墙就开始抖，查了半天发现是超声波测距函数里有个延时会阻塞主循环，导致 PID 控制周期变成了 10ms 和 25ms 交替进行，控制器在这种不稳定周期下就开始振荡。后来把测距任务挪到了非阻塞状态机里，抖动立刻消失了。

动作逻辑这块，强烈建议上状态机。空闲、手动遥控、清扫中、回充中、充电中、低电量保护，这些状态之间要定义清晰的迁移条件。状态机的好处是让程序逻辑变得可预测，不会出现“机器人在充电时还在执行清扫任务”这种荒唐的交叉。我在代码里加过一条断言，状态迁移必须经过 Explicit 转换函数，有一次机器人出现奇怪行为，打印日志显示它在十分钟内从“清扫”跳到了“充电”再跳回“清扫”，排查到后来发现是个全局标志位被两个地方同时修改，状态机本身的保护没有防住这个问题。所以提醒一句：状态机是骨架，共享变量的互斥才是魂。

3.2 电机控制：为什么这个 PID 参数最难调

PID 控制是扫地机器人运动控制的核心。直白的说，PID 就是根据当前误差、误差的累积和误差的变化趋势，来计算出电机的控制量。你给机器人一个目标速度，编码器测出实际速度，两者做差，这个差值就是误差。P 项把误差放大成控制信号，D 项用来抑制超调，I 项用来消除稳态误差，比如电池电压下降或者地面摩擦力变化带来的偏差。

但是扫地机器人调 PID 有一个特殊的难点：机器人是双轮差速结构，左右两个轮子的响应特性并不一样。你把左右两个轮子的 PID 参数完全照搬，跑出来的轨迹却往往是歪的，因为负载不一样、电机摩擦不一样、连轮子直径都可能存在细微差异。所以实际调参时，要先分别调好左右两个轮子的速度环，然后让两个轮子以同一速度转动，对比编码器反馈的差异，再去微调机械上无法消除的部分。

我建议在代码里加一个“校准模式”，让两个轮子分别以 10Hz 频率输出当前实际转速，通过上位机或者串口绘制出来。你会很直观地看到左边的响应曲线和右边的不一致，哪边慢就微调哪边的 P 值。这个“校准模式”我一直留着，每次改装了底盘或者换了电池，都要重新跑一遍。

还要强调一点：编码器的噪声问题。霍尔编码器输出的信号在电机换向时会抖动，如果没做滤波就会出现速度数值的突然跳变。跳变会经过微分项被放大，甚至导致电机异响。我的经验是在编码器计数层做最小间隔过滤，设定一个最小有效计数值阈值，低于阈值的脉冲直接忽略，这样速度环会平滑很多。网上有些现成的 PID 调参口诀，什么“先调 P，加大到震荡再回调”，但我个人的经验是扫地机器人上，更常规的问题不是震荡，而是参数过大导致的“滴答声”和参数过小导致的“无力感”，要自己去现场听声音感受手感，这是文档里学不来的。

4. 感知与算法层：从避障到建图到底跑在什么设备上

4.1 传感器数据预处理：越准的传感器越依赖校准

很多人拿到传感器第一反应就是直接读数值，这其实是最大的坑。传感器输出的原始数据里，有偏差、噪声、失灵数据，你要先做数据清洗。比如碰撞传感器的抖动要去毛刺，红外测距传感器的读数要做一个简单的中值滤波或者滑动平均。我见过一个案例，机器在光滑瓷砖地面上频繁“误报”碰撞，检查后发现是碰撞条的振动被误判成了触发信号。后来在代码里加了一个“持续有效时长”的判断，信号必须连续超过 30ms 才算真碰撞，误报率立刻降到零。

陀螺仪也有一堆讲究。便宜的 IMU 静止的时候输出也不是零，而是有一个固定偏置，这个偏置受温度影响还会漂移。使用前要做静态校准，取开机后前几百个数据的平均值作为零偏，然后在后续数据里减掉它。我实测过一个 30 块钱的 MPU6050 模块，静态偏置在 Y 轴上的漂移可以达到每秒 0.3 度，如果不校准，十分钟的清扫下来航向角能偏出 180 度——机器人以为自己还在走直线，实际已经绕了一个大弯回了原点。校准则能把漂移降到每秒 0.02 度左右，一小时的累积误差也能控制在可接受范围内。

编码器数据是里程计的基础，但里程计天然存在累积误差。轮子打滑是最主要的误差来源，地毯上转弯、压过电线、越过门槛，都会造成轮子转动但机器人没有实际移动。所以如果用纯里程计算法，定位误差一定会越来越大。开源项目里处理这个问题有两种常规手段：一是加超声或者激光辅助校正，二是定期重新初始化。如果你的代码里有“回到充电座”这个功能，充电座上的红外信标就是最好的绝对定位锚点，机器扫完一圈回来，对准信标重新校准，里程计的累积误差就被清零了。

4.2 路径规划：从随机清扫到弓字形覆盖

扫地机器人最常见的清扫策略是弓字形，也有的叫牛耕法。机器人沿着一条直线向前清扫，扫到头，原地转弯，然后回过头来扫相邻的一条平行路径，如此反复，整个区域就被一条条平行线覆盖。这个策略看起来简单，但实现起来要考虑两个问题：第一条直线怎么确定，第二条直线怎么和第一条保持等间距。

间距的确定直接和吸尘宽度相关。如果吸尘口的宽度是 20cm，那么相邻路径的间距就应该小于 20cm，否则两条路径之间会漏出一条没扫过的缝。很多开源项目里间距设定为吸尘宽度的一半，这样中间的重复清扫区域足够大，不会漏扫，而且对路径偏差有容错。如果你用的是视觉定位而没有激光测距，间距还要再保守一点，因为定位误差相对更大。

转弯的策略也有讲究。扫地机器人掉头要用到两个轮子的差速反转，但坐标点的计算要注意轮距的参数。轮距差上 1mm，原地转 180 度后，实际朝向偏差能累积好几厘米。我在做路径规划时专门加过一个校正函数：转弯结束后，读陀螺仪确认实际转过的角度，如果偏差超过 2 度，就原地微调。这是让机器人走得“正”的关键细节。

再上一步就是基于地图的全局路径规划。先构建栅格地图，每个格子标记为已清扫、未清扫或障碍物，然后规划一条能使覆盖面积最大化的路径。这种规划的本质是寻找一个覆盖全地图且避免重复的路线，在复杂地图上是 NP 难问题，所以真正在代码里跑的都是启发式算法。开源社区里，有人用波峰法，有人用螺旋式扫描，有人用完全随机的碰撞反弹，实测下来覆盖率和清扫时长的权衡完全不同，你可以按自己的需求选择。

4.3 从简单的 DWA 到完整的 SLAM：系统的演进方向

如果你在 GitHub 上搜开源扫地机器人，会看到两类项目完全不同的技术路线。一类是纯嵌入式方案，代码量小，单颗 STM32 就能跑，成本极低，但机器人的智能程度也就是“随机碰撞+偶尔沿着墙边扫两下”。另一类是 ROS + 激光雷达方案，代码结构庞大，但真正实现了“地图构建—自主定位—路径规划”的完整闭环，机器人的决策过程是有依据的。

如果你按 ROS 那套来做，SLAM 算法有多个开源的现成实现，Gmapping 适合小场景、计算量适中，Cartographer 精度高但资源消耗大，近年还有基于图优化的方案。建图复杂度很高，但现代开源框架已经帮你处理好了大部分脏活，你要踩的坑主要在环境适配。

我从嵌入式转算法时刚开始很不适应，因为算法的环境依赖太重了。安装 ROS 依赖、编译库、配置环境变量，每一步都可能出错。有一次我在树莓派上编译 Cartographer，对着屏幕看了半小时编译输出，最后发现是缺一个 protobuf 库的版本——这种问题没有任何算法书会讲，纯粹是工程经验的积累。所以如果你要从避障转向 SLAM，请一定先做好环境配置是耗时的心理准备，同时建议从 Gmapping 这类轻量方案开始，不要一上来就挑战最重的框架。

5. 上层的“全栈”：通信链路、可视化界面与日志体系

5.1 通信协议设计：下位机和上位机之间到底传什么

下位机（STM32）和上位机（树莓派）之间必须定义一套通信协议。协议设计要直白一点，千万别搞得太花哨。最常用的是基于文本的指令帧，每一帧以帧头、数据区域、校验字和帧尾组成，每个字段用分隔符分开。比如：

!SET:V:LEFT:12.5,RIGHT:13.0*AA#

这串指令表示设置左右轮目标速度。优点是人读得懂，调试时直接拿串口助手发就能测，缺点是解析要花一点 CPU 时间。对于扫地机器人这种数据量不大、实时性要求毫秒级的场景，这完全够用。

下位机上报的数据格式建议固定成表格型的字段列表，比如里程计、当前传感器状态、电池电压、错误标志。这样上位机做可视化的时候直接做字段解析就好，不用打很多临时补丁。我调试时为了省时间，直接把 JSON 格式搬到了串口通信里，结果发现下位机上 JSON 的序列化和解析消耗了大量 CPU 时间，控制循环被拖慢了。后来还是改回了文本帧，立竿见影，主循环时间从 20ms 直接降回到 11ms。这个坑提醒你：通信协议越简单越好，工程师的时间不是拿来给每个字节做转义的。

5.2 实时可视化：像调试赛车一样调试扫地机器人

机器人“看不见摸不着”的特性决定了你必须建立一套可视化调试手段。最基础的方案是串口绘图，把速度数据、PID 输出、传感器状态以数字或简单的文本图形式输出到串口终端。更直观的方案是上位机程序通过 UDP 或者 WebSocket 接收数据，绘制出机器人的实时位置、规划的路径、传感器的实时读数。

我自己最常用的是把地图和路径画到一个网页里。上位机把栅格地图、机器人的实时位姿、清扫轨迹通过 UDP 发送到 Web 服务，网页上用 Canvas 把数据画出来。调试的时候你就能看到：机器人规划的路径和实际走的路径差了多少，哪里在重复清扫、哪里根本没走到。没有这套系统，你调避障纯粹是“盲人摸象”——机器人撞了墙你才知道避障有问题，撞了两次才知道是参数问题，第五次才搞清楚是不是传感器安装角度的偏差。有了可视化，第一次出问题就能定位到具体环节。

日志系统也是全栈里容易被低估的一块。下位机的日志要分级，ERROR 级别的要打印关键栈信息，DEBUG 级别的要能实时开关，避免日志输出占太多串口带宽。我在日志里设计了周期性的“心跳包”，每秒钟输出一条精简的传感器状态汇总，这样就算机器人没任务运行，你通过心跳日志也能快速判断它是否健康。这个习惯救过我太多次了。

5.3 遥控与 App 联动：让机器人变成可交互的产品

一个完整的开源扫地机器人项目，通常还会配套一个简单的手机 App 或者遥控器。通信方式很多：BLE、Wi-Fi、红外遥控都可以。BLE 功耗低，实现简单，适合控制指令的实时发送。Wi-Fi 适合传输更大数据量的地图和状态信息，让手机实时查看地图不漏帧。

我建议临界业务走遥控器或 App 上的实体按钮，而实时地图用 Wi-Fi 上传。这样既不破坏实时性，又能给用户一个直观的体验。这个部分的开发和编写是一个独立的小型全栈项目：前端写 Vue 或者小程序，后端跑一个轻量级的 WebSocket 服务，然后和 ROS 节点通信。做这块你会接触到：

• 如何在移动端处理低延迟通信
• 如何设计前后端 API 的请求和响应结构
• 如何让地图数据在低带宽情况下流畅更新
• 如何做权限校验，防止误操作

这些知识单独看都是“软件工程”的基础课，但当你把它们放到一个机器人产品场景中时，它们成为了整体系统的一部分。前端工程师如果第一次接触机器人项目，最容易忽略的是“响应式设计”之外的延迟问题——遥控指令如果要从云端绕一圈再回来，那种延迟足够让机器人撞墙两次了。所以连接通信链路时，一定要走局域网直连。

6. 工程化与调试实录：从原型到可复制交付

6.1 版本控制、参数配置与自动化测试

开源项目的工程化水平往往被低估。但你如果照着个人练手项目的代码风格去做半成品的搬运，后面加功能会想哭。模块化是基本要求，把传感器驱动、电机控制、算法模块、通信协议放到不同目录和组织里，每个模块保持独立接口。参数配置强烈建议用一个头文件统一管理，包括 PID 参数、速度上限、碰撞灵敏度、清扫间距、充电阈值等。我吃过一次亏：有一次机器人每天清扫到一半就趴窝，查了很久才发现是调试时改了一个充电电流阈值忘记改回来，导致电池永远充不满，永远自动进入低电量保护。后来我把所有参数集中管理，每次调试只动一个文件，这类问题彻底灭迹。

版本控制从第一天就要做。机器人调试的不确定性远高于 Web 开发，经常出现“昨天还能好好跑，今天一行代码没改就不行了”的情况。没有 Git，你很难找回那个“昨天能跑”的版本。我建议每次可运行状态都要打上 Tag，比如“v0.2-wander-ok”，这样回退版本只需要一条命令。

自动化测试听起来很重，但你至少可以做一个“跑测脚本”。写一个 Python 脚本，连接下位机的串口，发送固定指令，检查返回是否符合预期。比如发送“设置左轮 10cm/s”，等 500ms 后读取编码器值，确认速度偏差在 5% 以内。这套脚本虽然简单，但能让你每次改完代码后 5 分钟就确认核心功能没被破坏。我在重构电机驱动代码时，就是靠这个“回归测试”抓出了编码器计数的符号反转 bug。

6.2 常见问题与排查技巧速查表

调试扫地机器人，绕不开一堆稀奇古怪的问题。下面这张表是我这几年实操中总结的最典型问题、根因和对应解决办法，算是给第一次入坑的朋友一份避坑指南。

如果你遇到的是“看起来对但又不对”的模糊问题，我的经验是优先怀疑两个东西：地线和时序。地线接触不良会产生极其诡异的现象，比如传感器数据偶发抖动、电机噪音增大、单片机遇热死机。时序问题则多半和中断优先级、阻塞延时有关。这两个方向的排查路径相对固定：先用示波器或者逻辑分析仪看信号，再检查代码里阻塞的位置，通常都能找到答案。

6.3 成本核算：开源项目到底要花多少钱

很多人听到机器人工程就觉得烧钱，实际上开源扫地机器人的成本可以控制得很低。一颗 STM32F103 核心板不到 30 元，两个带编码器的直流减速电机加驱动模块合计大约 60 元，普通超声波和红外传感器杂七杂八加起来 40 元，再加上一块电池和一个底盘框架，整体物料成本在 200 到 400 元之间。如果把主控换成果汁派的树莓派 Zero 2 W，额外多出百元左右，但能跑真正的 SLAM 算法，扩展性也更强。

相比之下，买一台成品扫地机器人动辄上千元，但开源方案的意义不在于省钱，而在于你坏了哪里能修哪里，想加什么功能随时可以改。理论上，一个开源扫地机器人的硬件成本约为同价位成品机器的三分之一到一半，而这些钱换来的是你亲手拆解并重装一遍完整机器人系统的经验，这比任何课程价值都高。

我还想给一个建议：第一次做，硬件预算留点余量是值得的，尤其是电机、驱动板和主控，至少要备一份替换件。调试过程中烧掉电机驱动是家常便饭，有一次我接反了电机线，驱动模块冒烟的速度比我读引脚定义的速度还快。备用件能让你当天晚上继续调试，而不是在等快递的日子里失去全部热情。

7. 整个项目做完后，你真正得到了什么

回到标题那句话：“一台会扫地的机器，装着一整套机器人工程课程”。这句话是真的，而且我认为它的分量比看上去还要重。做完这个项目，你对机器人系统的理解不再是零散的术语，而是一条清晰的工程链路：硬件怎么选型、驱动怎么控制、数据怎么处理、算法怎么接入、通信怎么互联、产品怎么交付。

我自己的感觉是，这个项目最大的价值在于它逼着你去打通“上层算法”和“底层执行”之间的鸿沟。算法再好，电机响应不准，机器人照样跑偏；电机响应再好，地图建得稀烂，机器人照样迷路。这种“每层都要靠谱”的工程张力，正是做机器人最有吸引力的地方，也是它和纯 Web 开发、纯 App 开发最大的区别。

如果你也想动手搞一个，我给的建议路径是先在下位机上跑通最基本的“走直线—转圈圈—自动避障”三步，然后在云平台上把数据可视化做起来，最后再接入更复杂的 SLAM 算法。脚踏实地一步步来，不要一上来就想着搞出一个浑身都是激光雷达的家用全自动化神器。任何高科技的落地，都是从一台会傻乎乎地原地转圈的底盘开始的。

分享一个我最后留下的习惯：每次调试完一个功能，我会写一段“本次测试完成的标准”放在项目笔记里，例如“走直线 3 米，横向偏差不超过 5 厘米”。有了这份可以量化的标准，每一次调试都有了目标，而不是漫无目的地试参数。这些笔记积累下来，就是属于你自己的工程手册，比任何教科书都更有用。