智能送餐车设计实战：差速循迹、避障状态机与联调

1. 先别急着画板子：智能送餐车到底在解决什么问题

智能送餐车这个题目看着像学生课设，实际动手做一遍就知道坑有多深。我前后参与过几轮类似的移动底盘项目，有做展览讲解的，有做餐厅端菜演示的，也有做办公楼里送文件样机的。最后发现一个规律：真正让人返工的从来不是代码写不出来，而是最开始没把"车要在什么地面上跑、要送多重的餐、一次跑多远、遇到人怎么办"这几个问题想明白。

所谓智能送餐车，说白了就是一台能自己把托盘从A点送到B点、途中不撞人、不洒汤、到地方会喊人的移动机器人。它的核心能力可以拆成四件事：沿路径走直线、识别并绕开临时障碍、知道自己走到哪了、把餐稳稳当当地端住。听起来简单，但每一件事背后都牵着一串硬件和算法的取舍。这套设计适合三类人参考：一是做嵌入式课程设计、需要完整闭环方案的同学；二是想快速验证餐厅/园区服务机器人想法的小团队；三是手里已经有底盘、但循迹老是抖、避障老是误触发，想找病根的爱好者。我会把整条链路从需求换算、器件选型、电路细节、参数整定到联调排查讲透，中间的计算过程和踩过的坑都保留下来，你照着抄作业基本能少走一遍弯路。

2. 需求拆解：把"送餐"翻译成可计算的指标

2.1 三类典型场景与对应的功能取舍

送餐这件事在不同场景下的要求差别极大，绝不是一套配置通吃。我按实际见过的三类场景分别说。

第一类是室内平整地砖的餐厅场景。地面是瓷砖或环氧地坪，反光强但基本没有坡，路径固定、拐角多、人流密集。这类场景的关键指标是转弯半径小和避障反应快，速度反而不重要，通常0.3到0.5 m/s就够了，跑快了汤会晃出来。它的技术重点是循迹精度和平滑的减速曲线。

第二类是办公楼走廊。地面以PVC地板和地毯混合为主，有些门口还有几毫米的门槛条和电梯口。这类场景最怕的是地面材质突变导致传感器读数跳变，以及地毯造成的轮子打滑、里程计累积误差。所以这里必须重视轮子材质和里程计校准，路径上还要留人工介入的兜底按钮。

第三类是园区或食堂的室外半室外场景。会有缓坡、地砖接缝、日照变化。这类场景基本不能只靠红外循迹，得配合超声波、或者直接上简单的激光测距和视觉。成本会翻倍，但只要动线设计得干净，可靠性是完全能做到可用的。

三类场景对应的取舍我用一张表说清楚，选方案前先对号入座：

这张表的用法很直接：先确定你的场地，再从中间一列往回倒推器件清单。我见过太多人上来就要装激光雷达和深度相机，结果底盘是一个塑料万向轮加两个TT电机，装上去照样抖成一团。定位方式决定的是"我知道我在哪"，避障决定的是"我不会撞"，这两件事必须分开设计，混在一起想很容易顾此失彼。

2.2 从需求到硬指标的换算过程

需求定了，接下来是把它变成能写进参数的数。这一步最能体现设计功力，也是"完整资料"里最容易缺的一环。

先算速度。假设餐厅单程送餐距离20米，客户能接受的最长等待时间是90秒，中间要停靠2次、每次10秒。那么留给行驶的时间是70秒，平均速度需求是 20 ÷ 70 ≈ 0.286 m/s。考虑起步和减速的损失，设计速度取0.4 m/s，留出30%余量。

再算轮速。假设选用直径65 mm的轮子，周长 = π × 0.065 ≈ 0.204 m。要达到0.4 m/s，轮子转速 = 0.4 ÷ 0.204 ≈ 1.96 转/秒，也就是约118 rpm。这个数决定了减速电机的选型：如果电机空载转速是6000 rpm、减速比1:30，输出轴转速是200 rpm，刚好够用还留有余量；如果减速比选1:50，输出只有120 rpm，满速跑起来就没有调速空间了，上坡会明显吃力。所以减速比宁可选小一点、留出PWM调速余量，也不要卡着临界值选。

然后是分辨率。同样是65 mm轮径、减速比1:30、编码器每圈11线、四倍频计数，输出轴转一圈的计数是 11 × 4 × 30 = 1320 个。每个计数对应的位移是 0.204 ÷ 1320 ≈ 0.155 mm。这个精度对送餐车足够了，你至少能做到厘米级的停靠判断。如果用的是霍尔编码器只有单路，那就只能测速不能判方向，倒车时里程计会反向累积，这是个隐蔽的坑。

最后是续航。假设电池12V/3Ah，容量36Wh。整车平均电流估算：两个驱动电机空载各0.15A、带载各0.6A，取平均0.5A×2=1A；主控加传感器0.15A；舵机或语音模块峰值0.3A但占空比低，折算0.05A。合计约1.2A。理论续航 = 36 ÷ 12 ÷ 1.2 = 2.5小时。但电池实际可用容量要打六折（放电截止电压、内阻损耗、低温衰减），所以按1.5小时设计比较靠谱。如果要求全天营业，那就得考虑换电设计或者大容量电池，而不是硬堆参数。

提示：这些数字请你一定要自己动手算一遍再定器件。我见过直接抄别人方案用18线编码器配1:48减速比的，结果轮子转一圈1300多计数、单片机定时器频繁溢出，速度环根本跑不起来。

3. 架构与选型：为什么最后落在"差速+循迹+超声波"这套组合上

3.1 四层架构的职责划分

整车的架构我习惯画成四层，从下往上分别是执行层、感知层、决策层、交互层。这个分法不是为了好看，而是为了出问题时能快速定位是哪一层的责任。

执行层包括电池、电源管理、电机驱动、左右驱动轮和万向轮。它的唯一职责是把电信号变成可靠的运动，凡是"车不走""车跑偏""速度上不去"的问题，九成先查这一层。

感知层包括循迹传感器、超声波测距、编码器、以及必要的碰撞开关。它负责把外界状态变成数字量，凡是"读数跳变""误触发""丢线"的问题都在这里。

决策层是主控芯片。它跑三件事：循迹PID、避障状态机、任务调度。这一层最容易出现的错误是把所有逻辑塞进一个大循环，结果超声波测距阻塞了500毫秒，PID早就发散失控了。

交互层是显示、按键、语音播报、无线指令下发。它不是必需项，但非常建议做，因为调试时你会无比感激那个能显示实时误差值的OLED屏和一键急停的物理按键。

四层之间用明确的接口隔开：执行层只接受速度和方向指令；感知层只输出结构化的测量值；决策层不直接操作寄存器，通过封装好的接口调用。分层做得清楚，后面换传感器、换电机都不用动主逻辑。

3.2 主控选型的对比与结论

主控这块，市面上常见的三种选择我都实际用过，优缺点很明显：

送餐车这个需求，我的结论是：32位M核够用，而且是最合适的。理由是它同时具备硬件定时器、多路PWM、多路ADC和多个串口，跑PID加上避障状态机绰绰有余，实时性也比Linux方案好一个量级，开机即用不用等系统。如果后期要加视觉识别菜品，那就用"MCU负责底层运动控制 + 上位板负责识别"的双核方案，中间用串口协议通信，把实时任务和计算密集任务彻底分开。

如果只做纯循迹的小车，8位机也能跑，但一旦加上编码器测速、超声波测距、OLED刷新、无线通信，定时器和RAM就吃紧了，很容易出现"加了屏幕之后循迹开始抖"这种莫名其妙的现象。所以别在这一步省。

3.3 底盘构型：差速驱动为什么是性价比之王

底盘构型上我做过对比。麦克纳姆轮能全向移动，在狭窄的餐厅过道里很香，但它对地面平整度要求极高，四个轮子必须同时着地，稍有颗粒就有一个轮子打滑，里程计立刻发散，而且辊子容易缠头发，维护成本高。阿克曼转向（像汽车那样）跑高速舒服，但转向需要额外空间，在1.2米宽的过道里掉头很痛苦。

差速驱动（左右两轮独立驱动 + 前后或中间万向轮）是我最终推荐的方案。它转弯半径理论上可以是零，结构简单、零件便宜、控制模型清晰。左右轮速度差就决定了转弯角速度，正运动学公式非常干净：车体线速度 v = (vL + vR) / 2，角速度 ω = (vR − vL) / L，其中L是左右轮距。只要你的轮距测得准，转向角速度就是可控的。

差速底盘的结构细节上有两个必须注意的地方。一是万向轮的位置，放在中间偏后会比放在最前面更稳，因为重心靠后时驱动轮的正压力足，不容易打滑；二是驱动轮必须承受足够正压力，如果电池和托盘都压在万向轮那一侧，驱动轮抓地力不足，起步就会空转，编码器读数虚高，里程计立刻跑偏。这两点在实际装配时特别容易忽略。

3.4 感知方案的组合逻辑

循迹这块，红外对管阵列和灰度传感器阵列我都试过。红外的优点是便宜、数字输出好处理，缺点是受环境光影响大，尤其是地砖反光或者射灯直射，会在黑线上误判成白。灰度传感器输出模拟量，可以设动态阈值，抗干扰强一些，但需要多路ADC。

我的做法是：用6到8路红外或灰度阵列，一字排开，横向覆盖略大于线宽。为什么要8路？因为路数决定了你能分辨多少种位置偏差。5路只能粗略判断"偏左一点/偏右一点"，8路能做出更细的偏差量化，PID的输入才不会阶梯状跳变，走线才平滑。如果只做5路又想平滑，就得自己插值，反而更麻烦。

避障用超声波是主流，但要知道它的三个硬伤：一是波束角大，约15度锥形，斜放的桌腿角度对不上就测不到；二是对软性材料（窗帘、海绵）回波弱；三是多探头同时工作会互相串扰。所以我的建议是"2到3个超声波 + 1个前向红外近距开关 + 一圈碰撞缓冲条"。超声波做中远距预警（15到60 cm），红外近距做20 cm内补充，碰撞条做最后兜底——撞上了至少能立刻停，不至于顶着人走。这个三层结构在实测中误判率能压得很低。

4. 硬件细节：电源、驱动、布线与结构

4.1 电源树的划分与电流核算

电源是整套系统里最不起眼、但最容易翻车的部分。我的习惯是画一棵电源树：12V锂电池出来分三路，一路直供电机驱动（大电流、有噪声），一路经降压模块到5V给传感器和舵机，一路再经LDO到3.3V给主控和逻辑。

为什么电机要和主控分开供电？因为电机启停瞬间的反电动势和电流突变会在电源线上造成几百毫伏的跌落，如果主控和电机共用一路，就会出现"电机一转，屏幕花屏，主控复位"的经典现象。这个坑我踩过，表现是循迹跑着跑着突然重启，一开始还以为是看门狗，查了两天才发现是电源。

电流核算要按峰值算，不能按平均值。以两个驱动电机为例，堵转电流可能到2A以上，两路加起来4A。降压模块的选型至少要留2倍余量，也就是5V/3A的模块实际只用到1.5A以下最稳妥。电感式的降压模块（开关电源）效率高、发热小，线性模块（如7805类）在大压差大电流下会烫到烫手，12V降到5V、电流1A时就有7W的功耗，必须加散热片。我推荐用开关型降压模块，体积小、效率能到90%以上。

另外两个细节：一是在电机驱动的电源入口并一个220 μF以上的电解电容，吸收启停时的电流冲击；二是在主控电源入口串一个自恢复保险丝，防止接线错误烧板子。这两个元件成本不到一块钱，但能救你一整块板。

4.2 电机驱动的选型要点与保护

驱动芯片的选择看三个参数：持续电流、峰值电流、是否支持PWM加方向控制。双路H桥是最常见的形态，注意它的持续电流额定值往往是在有散热条件的前提下给出的，实际裸奔时打个对折比较安全。如果电机堵转电流是3A，那驱动器持续电流最好选5A以上。

PWM频率也有讲究。低于1 kHz会听到明显的电机啸叫，高于20 kHz又会让开关损耗变大、驱动器发热。我一般取8到15 kHz，既避开人耳敏感区，又不至于太热。占空比分辨率至少要8位（256级），否则低速时调速很粗糙，送餐车起步会一顿一顿的。

还有一个容易忽略的点：电机线一定要和信号线分开走。我见过把编码器线和电机线绑在同一个线束里的，结果PWM的干扰直接串到编码器上，测速值每隔几毫秒就跳一个尖峰，速度环整定出来全是噪声。正确的做法是电机线双绞、信号线屏蔽或远离，交叉时垂直交叉，不要平行走长距离。

4.3 传感器布局的几何设计

传感器的物理布局直接决定测量质量，这一点在设计资料里常常一笔带过，但实际影响巨大。

循迹阵列的安装高度和间距要算。红外对管的有效检测距离通常在5到20 mm之间，太高会误判，太低会蹭地。我一般把阵列装在底盘前部、离地10 mm左右，并且做成可调高度的支架，方便在不同地面微调。阵列的横向间距要保证黑线始终至少落在两个探头之间，也就是间距略小于线宽。如果线宽20 mm，间距取12到15 mm比较合适。

超声波的安装角度更重要。它必须正对前方、水平安装，向上仰会打到桌子边缘测不到人腿，向下俯会一直探测地面造成误报。我给的经验值是：离地高度20到30 cm，探头中心略低于人膝盖位置，这样既能看到桌腿、椅子腿，也不会被地面反射干扰。如果装两个探头，左右各偏15度形成一个扇形覆盖，比并排正前方安装的覆盖面更宽。

另外记得给每个探头做一次单独的标定：正前方放一块硬纸板，从1米慢慢推近，记录读数变化，看看最小盲区有多少、最大量程到哪里。标定出来的数写进代码的常量表，比直接用数据手册靠谱得多。实测中常见的HC-SR04类模块，盲区2 cm、可靠量程20到200 cm，超过2米读数就开始乱跳了。

4.4 结构设计：防洒比防撞更难

送餐车的机械结构有两个核心诉求：托盘不能洒，车轮不能卡。

防洒的关键是减震和重心。三层托盘每层都要有防滑垫，边缘做2到3 cm的挡边。托盘不要全部刚性固定在车架上，最好在车架和托盘之间加一层薄橡胶垫或者小弹簧，把地面的高频震动吸收掉。我做过对比，加2 mm硅胶垫之后，同样速度下杯子里的水面晃动幅度能减少一半以上。

重心要尽量低、尽量靠近驱动轮轴线。电池是全车最重的部件，放在底盘最低处、两个驱动轮中间偏下，对稳定和抓地都有好处。孔位一定要留可调余量，因为第一版几乎不可能刚好平衡，后面调重心要用。

车轮这块，室内地砖用橡胶胎面、硬度中等的轮子比较合适；遇到地毯就要选宽一点的胎面降低压强，否则轮子陷入地毯，里程计就废了。万向轮建议选带轴承的，便宜的塑料万向轮在地毯上阻力极大，转弯时会拖着整车偏移。还有一个小细节：驱动轮上方加个薄挡泥板，能防止线缆或餐巾纸卷进轮轴。

5. 软件实现：从PID到状态机的落地细节

5.1 循迹PID的参数整定思路

循迹的本质是让车体中心持续对准黑线。传感器阵列返回一个位置偏差量，比如最左侧为-3、正中为0、最右侧为+3，这个偏差作为PID的输入。

我倾向于用增量式或者带积分限幅的位置式PID。增量式的好处是不需要累积误差项，切换模式时不会有突变。核心参数整定的顺序是：先把Ki和Kd置零，只加Kp，从小往大加，直到车能跟上线但开始轻微摆动；然后把Kp降到出现摆动的80%左右，再加Kd抑制摆动，Kd从Kp的3到10倍开始试；最后加一点点Ki消除稳态偏差，但要限幅，否则一旦丢线，积分项会累积到饱和，重新找到线时车会猛地甩一下。

采样周期很关键。循迹环建议10毫秒一次，也就是100 Hz。如果你的循环里有超声波测距这种阻塞操作，一定要改成非阻塞触发（发脉冲、等回波、读值分成三步，放在不同时间片），否则实际周期会飘到几十毫秒，PID参数怎么调都不对。

下面这段是循迹控制的骨架，参数是示例值，你要按自己的车重和电机重调：

#define LINE_KP 18.0f #define LINE_KD 9.0f #define LINE_KI 0.2f #define BASE_SPEED 260 // PWM 占空比基准值 #define MAX_DIFF 180 // 差速限幅，防止内轮反转 static float err_last = 0.0f, err_sum = 0.0f; void LineTrack_Update(float err, int16_t *pwm_l, int16_t *pwm_r) { err_sum += err; if (err_sum > 50.0f) err_sum = 50.0f; // 积分限幅 if (err_sum < -50.0f) err_sum = -50.0f; float diff = (err - err_last) * LINE_KD; // 微分项 float out = err * LINE_KP + err_sum * LINE_KI + diff; err_last = err; if (out > MAX_DIFF) out = MAX_DIFF; if (out < -MAX_DIFF) out = -MAX_DIFF; *pwm_l = BASE_SPEED - (int16_t)out; *pwm_r = BASE_SPEED + (int16_t)out; if (*pwm_l < 0) *pwm_l = 0; // 单边限幅，避免一侧反转 if (*pwm_r < 0) *pwm_r = 0; }

这段代码里我特意把差速做了限幅，因为实际调试中发现：如果误差大到让内侧轮PWM变成负数，驱动器会真的让电机反转，车体就会出现原地急转，托盘里的汤直接泼出去。限幅之后，最坏情况也只是内侧轮停转，车沿弧线拐过去，温和得多。

5.2 避障状态机的分层设计

避障不能写成"if 距离小于20cm 就停"，那样车会一直停着不动。正确的做法是状态机，我一般分五个状态：

这个状态机的细节在于"滞留时间"和"恢复阈值"。停车后如果障碍物一直在，你等500 ms就转绕行；绕行时只允许小幅转向，转完再测，如果还堵着就转回来。千万不要做复杂的方向决策，送餐车的场景通常只需要"等一下"或者"绕过去"，做太复杂反而容易在狭窄过道里来回打转。

另外，超声波每次读数不能直接用，要做中值滤波或者三次取中间值。我一般连续测三次，去掉最大最小取中间，再加一个"连续两次小于阈值才认定障碍"的确认机制，这样能过滤掉绝大多数误判。

5.3 里程计与位姿推算的实用做法

里程计想做准，编码器必须是双路正交输出。用左轮和右轮的累计计数差来算航向角变化：Δθ = (Δd_R − Δd_L) / L，其中L是轮距。累计位移 Δd = (Δd_R + Δd_L) / 2。把每一时刻的增量累加成(x, y, θ)，就是最基础的航迹推算。

这套算法最大的问题是误差会累加：轮径磨损1%、轮距量错2 mm，跑十米之后航向可能差出十几度。我的处理办法有三个：一是轮距不要用尺子量轮子中心，而是用"原地转一圈实测"的方式反推——让车原地转360度，记录左右轮计数差，反算等效轮距，这样能把地面打滑的影响一起补偿掉；二是每经过一个固定标志点（比如地面贴的定位标记）就重置一次坐标；三是把里程计只当作"辅助判断"而不是"绝对真值"，停靠位置主要靠地面的停靠标记线，而不是算出来的坐标。

5.4 任务调度：别让一个功能饿死其他功能

主循环怎么组织，这个细节决定了整车是"能用"还是"好用"。我推荐时间片轮询加中断配合的结构：主循环里维护几个时间标志位，每到10 ms执行一次循迹控制，50 ms执行一次超声波测距，100 ms刷新一次显示，500 ms上报一次状态。中断只负责编码器计数和串口接收，中断里绝不做复杂运算。

关键在于所有外设操作都要非阻塞。超声波测距拆成"发触发—延时等待—读回波"，等待那段用定时器或者状态机而不是死循环延时。只有这样才能保证10 ms的控制周期不被拖慢。这一点我在调试初期吃过亏：原来避障写在主循环里用死等，结果一旦进入避障流程，循迹就停了，车会沿着原来的方向直冲出去。

6. 联调实录：分阶段验证与常见故障速查

6.1 分阶段点亮的验证顺序

我强烈建议按阶段验证，一次只加一个模块，上一个模块没通过不往下走。这样做的好处是出了问题能立刻定位到刚加的那部分。

第三阶段最容易被跳过，但它其实是整个系统精度的地基。我建议的做法是：在地面量出精确的两米，让车直线跑过去，比较编码器算出的距离和实际距离，误差超过5%就去查轮径和减速比有没有填对，或者有没有丢计数。

第六阶段建议直接在托盘里放半杯水跑，这比任何参数表都直观。水面晃动的幅度是整车平顺性的最好检验，如果水一直在晃，说明加减速太急，把加速度限制调小，或者把PID的微分项再加大一点。

6.2 典型故障的排查思路

下面这几条是我自己以及周围人反复遇到的，整理成速查表：

其中"电源共地干扰"这一条要重点说说。验证方法很简单：把电机用独立的电池供电，主控用另一路，如果花屏消失，那就百分百是干扰问题。解决办法是共地处理加电容，在电机两端并一个0.1 μF陶瓷电容加一个二极管做续流，电源入口加大电容，必要时在电机线上套一个磁环。这几样加起来成本几块钱，效果立竿见影。

6.3 我踩过的几个坑和对应的经验

第一个坑：初期我把循迹阵列装得太靠前，超出车身最前端3 cm。结果车头撞上桌腿时，探头已经悬空，还在按"有线"的逻辑往前冲。后来改成阵列缩进到车体轮廓以内5 cm，效果就好多了——探头不该比车头更靠前，因为车能过去的位置才是它该探测的范围。

第二个坑：为了防止洒汤，我把速度整体调低到0.2 m/s，结果客户嫌慢，而且慢速时电机占空比只有15%左右，处于死区边缘，反而抖得更厉害。正确的做法是维持中速，但把加减速的加速度限制在0.5 m/s²以内，用"起步慢、匀速稳、减速缓"的方式来解决，而不是一味降速。

第三个坑：无线遥控指令下发时会出现丢包，车没收到急停命令。后来改成"心跳加超时"机制：上位每200 ms发一次心跳，车超过600 ms没收到就自动停车。这个兜底逻辑比任何指令验证都可靠，强烈建议加上。

第四个坑：停车靠站时用算出来的坐标去停，误差能到10 cm。后来改成在地面贴一条横向色带做停靠标记，车检测到标记就减速到爬行速度，再走固定距离停止。重复精度立刻提升到2 cm以内。这说明在低成本方案里，用物理标记换精度是最划算的买卖，不要迷信算法。

6.4 后续可以继续深挖的方向

这台车跑通之后能扩展的点其实不少，我自己列了几个优先级。第一是加称重或者到位检测，托盘放上餐之后才允许发车，取走餐之后自动返回，这个用简单的压力开关就能做。第二是把路径做成可配置的，把每个停靠点的转向序列存在EEPROM里，换场地只需要重录一遍，不用重新烧程序。第三是做多车协同，用同一频段的无线通道加编号，各车错开时间段走同一条线，这需要引入简单的预约机制，但原理不复杂。第四是把避障从"停"升级到"绕"，用侧向测距判断左右哪个方向有空间，配合一段固定的绕行轨迹，能显著减少因临时阻碍造成的等待。

我个人在实际操作中的体会是，这类项目真正的门槛不在某个高深算法，而在于每一个环节都要做到"刚好够用且留有余量"：电源留余量、PWM留余量、结构孔位留余量、代码逻辑留兜底。把每一个小决策都往"抗意外"的方向偏一点，整车最后就是可靠的；反过来，每个环节都卡着极限做，跑起来一定处处告警。