1. 从"能跑起来"到"送对桌"：智能送餐车真正的难点在哪

先把话撂这儿：如果你在网上搜智能送餐车的资料，九成会看到一段视频——小车沿着贴好的黑线稳稳跑一圈，托盘上放瓶水不洒，然后配一段"基于XX算法实现自主导航"的说明。但真把车推到餐厅后厨门口，地面有水渍、椅子乱摆、服务员端着热汤横穿、客人突然伸出一条腿，这台车大概率走不出五米。智能送餐车这个题目，真正的技术门槛从来不在"让轮子转起来"，而在于在一个人来人往、地面材质不统一、无线信号还不稳定的半开放环境里，把餐送到准确的桌号，并且不撞人、不洒汤、不卡死。

这个项目适合谁看？如果你是做毕设的学生、做样机的创业者、或者公司里被安排"搞一台送餐机器人"的工程师,这套内容能帮你把从机械到电控、从定位到调度的整条链路捋顺。我不打算只给你一堆模块名词,而是把每个关键选择背后的账算给你看:为什么选差速两轮而不是四轮全向、为什么激光雷达装在那个高度、电池容量到底怎么估、联调时该按什么顺序排雷。这些是你在论文和产品手册里看不到、但决定项目能不能落地的东西。

需要先说明的是，本文涉及的具体参数是基于常见中小型室内送餐车（整备质量 30~50kg、载重 10~20kg、最高速度 0.8~1.2m/s）的通行实践给出的，你自己做的时候要按实际重量、场地坡度和续航要求重新核算，我会把公式和取值逻辑都摆出来，方便你代入调整。

1.1 演示场景和真实场景的差距清单

很多人做这个项目的第一步是买套件，第二步是跑通官方 Demo，第三步就卡住了。卡住的根本原因不是技术不够，而是需求没定义清楚。官方 Demo 的隐含假设是：地面平整无障碍、光照恒定、没有其他人、单车运行、路线固定。而真实餐厅至少有这几个变量：

• 地面从抛光瓷砖到防滑地胶无缝切换，反光率和摩擦系数差一大截，激光雷达在强反光地面上测距会飘，轮子在打蜡地面上会打滑导致里程计漂移；
• 桌椅是每天重新摆的，地图每周都在变，纯靠预先建图 + 固定路径的方案很快就失效；
• 高峰时段人流量大，服务员、客人、儿童都可能突然出现在车前 0.5m 范围内；
• 电梯、闸机、门禁这些"非标设备"需要额外联动，而这往往是最容易被低估的工作量。

所以我的建议是：在动手做硬件之前，先写一份"场景约束清单"，把地面材质、最窄通道宽度、最大坡度、电梯类型、是否多车、是否需要跨楼层、单次配送最远距离全部列出来。这份清单直接决定了后面的机械方案、传感器配置和导航路线选择，比着急买零件重要得多。

1.2 三个必须先钉死的核心指标

抛开所有花哨功能，一台能用的送餐车只需要把三个指标钉死，其余都是锦上添花：

这三个数字一旦确定，机械尺寸、电池规格、导航方案的选型空间就被压缩了一大半。我见过不少项目做到一半推翻重来，基本都是因为一开始把车宽定在 600mm，装完激光雷达和防撞条之后变成 680mm，结果过不去卡座之间的通道，最后只能改结构。

1.3 整车模块是怎么切分的

把整车拆开看，无非是四层：机械承载层、实时控制层、感知决策层、业务交互层。机械层负责装得稳、走得动；实时控制层负责电机闭环、编码器读取、急停响应，这一层对时序要求硬，必须放在 MCU 上跑；感知决策层负责建图、定位、路径规划、避障，算力需求大，放在单板机上；业务层负责订单、桌号、语音播报、和后台服务器通信。

这四层之间通过串口或以太网通信，边界一定要划清楚。最常见的翻车方式是：把所有逻辑都塞进单板机，用一个进程跑控制 + 导航 + 通信，结果导航算法一卡顿，电机控制延迟 200ms，车就开始画龙。反过来，如果把导航也塞进 MCU，算力根本不够。所以上下位机分离不是"高级做法"，是这个项目的必选项。

2. 轮系与载物仓：机械结构决定了后面 80% 的软件难度

先讲一个很多人不愿意承认的事实：送餐车的导航精度上限，很大程度上是机械决定的。里程计漂移、过坎打滑、转弯甩尾，这些看起来是算法问题，根子都在轮系和重心上。软件补偿能做，但代价是指数级上升的调试时间。

2.1 差速两轮 + 万向轮为什么成了绝对主流

室内送餐车的底盘方案基本就三种：差速两驱 + 前后万向轮、四轮麦克纳姆、四轮独立转向。我实测下来，中小型送餐车选两轮差速驱动 + 前后各一到两个万向轮是最优解，理由有三条：

第一，运动学模型最简单。差速模型只有线速度和角速度两个控制量，正逆解都是解析式，MCU 上几十行代码就能算完，不用做矩阵运算。第二，成本和控制难度低。两个带编码器的减速电机就够，转矩需求也能算清楚。第三，越障能力和贴边能力平衡得最好——万向轮可以做得比驱动轮小一点、软一点，过门槛时冲击小。

麦轮的优势是能横移，在狭窄空间掉头很有用，但代价是四个电机、四个编码器、四个闭环，辊子磨损快，而且在瓷砖地面上横移时打滑严重，里程计误差反而更大。全向轮同理。所以除非你的场地真的窄到没法原地转，否则别上麦轮。

2.2 轮径、减速比、编码器分辨率的手算过程

这一段是实打实的干货，很多人选电机就靠"卖家说够用"，结果装上去发现跑不动或者定位精度不够。我们把账算一遍。

假设整车满载 40kg（车身 28kg + 餐品 12kg），要求最大速度 1.0m/s，加速度 0.5m/s²，场地最大坡度 3°（约 0.052 rad），滚动阻力系数取 0.03。

总牵引力 F = m·a + m·g·sinθ + μ·m·g = 40×0.5 + 40×9.8×0.052 + 0.03×40×9.8 ≈ 20 + 20.4 + 11.8 ≈52.2N

两个驱动轮平分，单轮需要 26.1N。选轮径 150mm，半径 0.075m，则单轮所需驱动扭矩 T = 26.1 × 0.075 ≈1.96 N·m。工程上乘 1.5 倍安全系数（应对过坎冲击和轮胎磨损），取3 N·m。

选减速比 30、传动效率 0.7 的减速箱，则电机输出轴扭矩需求 = 3 / (30 × 0.7) ≈0.143 N·m。这个数值很多 37mm 规格的直流减速电机在额定电压下都能达到，选型时看铭牌上的"额定扭矩"要大于这个值，别只看堵转扭矩。

再看转速。1.0m/s 对应的轮转速 = 1.0 / (π × 0.15) ≈ 2.12 r/s ≈127 rpm，乘减速比 30 得到电机转速约3815 rpm。所以选额定转速在 4000~6000 rpm 区间的电机比较合适，留出调速余量。

编码器分辨率这样算：如果电机编码器是 11 线霍尔，四倍频后每转 44 个计数，乘减速比 30，输出轴每转 1320 个计数。轮周长 = π × 0.15 ≈ 0.471m，那么每个计数对应 0.357mm 的位移分辨率。这个精度做里程计完全够用，配合激光雷达做扫描匹配，实际定位误差能压到厘米级。

提示：如果你用的是光电编码器（比如 500 线），四倍频后每转 2000 计数，经减速比 30 后分辨率会高很多，但要注意 MCU 的定时器编码器接口频率上限，速度高的时候可能溢出。

2.3 载物仓：重心、防洒、减震三个反直觉细节

机械结构里最容易被敷衍、又最容易出事的就是载物仓。分享几个踩过的坑：

重心一定要压低、前移一点点。托盘装在车身正上方时，重心偏高，急刹车时餐品惯性前冲，车容易点头。我的做法是把电池和主控放在底盘最下层靠近驱动轮轴线的位置，载物仓底板离地控制在 350mm 以内。前移一点是为了让驱动轮承受更大正压力，减少打滑，但前移过多会让万向轮承重不足，过门槛时容易翘头，一般重心落在驱动轴前后 20mm 内比较稳。

托盘要做防滑 + 挡边，别指望算法。再怎么平滑加减速，减速带和门槛的瞬时冲击是躲不掉的。托盘表面贴 3mm 硅胶防滑垫，四周做 15mm 高的挡边，杯托用下沉式圆槽。我试过纯平面托盘，第一周就洒了两次汤。

减震不是加弹簧就完事。有人给载物仓加四个弹簧，结果车一加速仓体就前后晃，反而更不稳。正确做法是底盘和载物仓之间用橡胶减震柱 + 限位，允许 3~5mm 的垂向形变但不允许横向位移，且只在轮系和底盘之间做一次减震，不要在仓体上做第二次，否则会形成两级共振。

3. 电气架构与主控选型：把一堆外设塞进有限的 IO 和预算里

电气部分是整个项目里最枯燥、最容易埋雷、又最不能省事的环节。我见过太多项目机械做得漂亮、算法跑得通，最后因为电机一启动串口就乱码、或者电池电压一掉就复位，硬生生拖了一个月。

3.1 上下位机的职责边界怎么切

我的分工方式是这样的：

切分原则很简单：凡是需要在确定时间内给出响应的，全部放下位机；凡是算力吃紧、允许几十毫秒抖动的，放上位机。上位机死机的时候，下位机还应该能靠"通信超时即停车"这条逻辑把车停下来，这是最基本的安全兜底。

通信协议推荐用自定义的二进制帧，帧头 + 长度 + 命令字 + 载荷 + CRC16，波特率 115200 起步，如果数据量大（比如每 10ms 上传一次里程计和 IMU），可以提到 460800 或者直接用以太网。别用 ASCII 明文协议，解析开销大还容易因为粘包出问题。

3.2 电源树与干扰：电机一转串口就乱码的真实原因

这个问题我敢说 90% 的队伍都会遇到。现象是：静止时一切正常，电机一加速，串口收到的数据就开始出现乱码，IMU 数据跳变，严重时 MCU 直接复位。

根因通常有三个，按出现概率排序：

第一，电机和逻辑共用一路电源，没有做隔离。有刷直流电机换向时会产生大量尖峰，通过电源线倒灌进 MCU。解决办法是逻辑电源和动力电源从电池端就分开走线，动力线单独一路经过保险和继电器，逻辑侧加 LC 滤波 + 大电容（建议 470μF 以上电解并联 0.1μF 陶瓷）。

第二，地线走成了环路。编码器地、电机地、MCU 地在不同位置汇合，形成地环路，电机电流在地线上产生的压降直接叠加到信号上。正确做法是单点接地：所有模块的地线汇到一个公共接地点，动力地和信号地在这个点汇合，别在半路随便搭接。

第三，信号线没有屏蔽、走线贴着动力线。编码器 A/B 相和 PWM 线平行走 30cm，串扰就足以让计数错乱。至少做到信号线远离动力线 5cm 以上，交叉时垂直交叉，长距离传输用双绞线。

另外提醒一句：急停按钮一定要做成硬件切断动力电源，不能只在软件里判断。软件判断在 MCU 死机时等于没有，这是底线。

3.3 电池容量和续航：别靠"感觉够用"

续航估算的公式很简单，但取值容易被高估：

续航时间 h = 电池可用能量 Wh × 放电深度 / 平均功耗 W

以 24V 20Ah 锂电池为例，标称能量 480Wh，实际可用放电深度取 0.8（保护板会在低压时切断，且深度放电伤电池），可用 384Wh。平均功耗按场景拆：

• 驱动平均功率：平地巡航时约 60~80W（峰值爬坡能到 200W 以上，但占比小）；
• 单板机 + 激光雷达 + 相机：约 15~20W；
• 显示屏 + 灯带 + 语音：约 8W；
• 待机损耗：约 3W。

加权平均按 75W 估，续航 ≈ 384 / 75 ≈5.1 小时。如果只在用餐高峰跑 4 小时，这个配置是够的；如果要全天 8 小时，要么上 24V 30Ah，要么设计成可换电池。

注意：电机启动瞬间电流能到额定的 3~5 倍，电池保护板的持续放电电流要留足余量，建议按峰值电流的 1.5 倍选型，否则爬坡时保护板会误触发断电。

4. 定位导航的三条路线：预算决定方案，场地决定成败

这一节是整个项目最花钱、也最容易走弯路的地方。室内送餐车的定位导航方案，本质上是三种技术路线的选择，各有各的适用边界，没有一种能通吃。

4.1 磁条 / 二维码 / 色带：便宜可靠，但被施工成本拖死

这是最"土"但最稳的方案：地面贴磁条或者二维码标签，车底装磁导航传感器或下视相机读标签。优点是定位绝对可靠，不受人流遮挡影响，算法简单到几十行代码，单车成本能压到几百块。

但它的问题不在技术，在施工和维护。磁条要开槽埋入地面或者用高强度胶带贴，餐厅每天拖地、推车碾压，三个月就得补；二维码标签被油污盖住就识别不了；最致命的是路线完全固定，桌椅一改就得重新贴。我见过一个食堂场景，改一次布局要停业半天，最后运营方直接放弃了这个方案。

所以这个方案只在一种情况下推荐：场地布局半年以上不变、地面可以施工、预算极低。会议室的茶水配送、固定车间的物料转运，用这套没问题。

4.2 2D 激光雷达 SLAM：通用性最好，翻车点也最多

主流方案。车上装一个单线 2D 激光雷达（扫描半径 8~12m，角分辨率 1° 以内），配合轮式里程计和 IMU 做多传感器融合，跑 SLAM 建图（常见开源方案有 Gmapping、Cartographer、Hector 这类），建好图之后用自适应蒙特卡洛定位做位姿跟踪，再用代价地图 + 局部规划器（DWA 或 TEB）做路径规划。

这套东西的坑我列一下：

• 雷达安装高度。装太低会打到地面杂物、地毯边缘、地插，装太高会漏掉低矮障碍（比如趴着的小孩、地上的包）。实测 200~250mm 是比较好的折中，这个高度能扫到桌椅腿，又不会扫到地面纹理。但如果场地里有大量低于 200mm 的障碍（如托盘、地台），就必须补一个低位的超声波或深度相机。
• 玻璃和镜面是重灾区。激光穿过玻璃，会在玻璃后面"看到"虚假空间，建图直接出错；镜面会产生镜像障碍。解决方案是在地图里手工标注玻璃区域屏蔽掉，或者在玻璃上贴一条磨砂膜。
• 动态障碍导致的定位丢失。人站在车前面挡住雷达，扫描匹配会失效。所以必须有"定位置信度"判断，一旦匹配得分低于阈值就降速甚至停车，等障碍离开再恢复，别硬着头皮往前冲。
• 地图版本管理。餐厅会调整桌子位置，如果地图不更新，车会觉得自己在一个不存在的世界里。建议做一个简单的重新建图流程，或者用"局部地图 + 固定锚点"的方式减少全图重建频率。

4.3 UWB 与视觉标记：多车场景下的取舍

UWB（超宽带）基站方案的优势是全局绝对定位，不依赖环境特征，在多车调度场景下特别香——每台车都知道自己在全局坐标里的位置，调度器可以统一规划。缺点是需要在场地部署 4 个以上基站（要连电源或者电池供电），标定耗时，金属环境多径效应严重，精度在 10~30cm 波动，单独用不足以精确到桌。

视觉标记（贴在天花板或墙上的反光板/ArUco 码）是另一种思路：成本低，单目相机加标记就能算出位姿，适合天花板上能方便施工的场景。缺点是标记一旦被遮挡或光照变化就失效，必须和里程计做融合。

我的实践建议是混合：激光雷达做主力定位，UWB 或视觉标记做修正和跨区域重定位，成本增加不多，鲁棒性提升明显。

5. 避障与安全链路：撞一次，项目就结束了

送餐车和工业 AGV 最大的区别是：它的工作环境里全是人。技术再炫，只要撞到一次人，这个项目在运营方那里就判死刑了。所以安全设计必须是多层冗余，任何单一环节失效都不能导致碰撞。

5.1 三层防护该怎么搭

第一层是规划层的主动避障：局部代价地图把障碍物膨胀一定半径（按车的轮廓加 100~200mm 安全距离），规划器自动绕开。这一层负责"优雅地避开"，但依赖感知数据的正确性。

第二层是传感器的紧急制动区：在车头前方设定一个 600mm 的硬性制动区，任何传感器在这个区域内检测到障碍，直接触发减速到 0，不经过规划器。这一层用超声波或者深度相机的近距检测，响应时间控制在 100ms 以内。

第三层是物理防护：车头装防撞条（带微动开关或压力传感），一旦被碰到立刻断电停机；车身四周做圆角、软包边，避免尖角伤人；急停按钮放在车体两侧和后部，方便任何人按下。

三层是"与"的关系，不是"或"——任何一层触发都要能停车。

5.2 超声波、红外、深度相机的实测表现

我踩过的最大的坑是超声波互扰：多台车同时工作，A 车发的超声波被 B 车收到，导致误报停车。解决办法是给每台车的超声波触发加随机抖动（比如 ±5ms），或者干脆用不同的触发周期错开。

另一个坑是深色地毯和黑色桌腿。超声波对这类物体反射弱，测距会偏大；红外对黑色几乎无反应；深度相机在纯黑吸光材质上也会丢点。所以单一传感器一定会漏检，必须组合。

5.3 声光提示：让人知道你要去哪

这一条经常被忽略，但在实际运营里非常关键。车要转弯、要倒退、要靠边停，都需要提前告诉周围的人。我的做法是：转向时对应侧的灯带流水闪烁，倒车时播放短促提示音，正常行驶时保持低速安静（别一直响，会很烦）。音量要可调，夜间模式降到最低。

还有一个细节：车头屏幕显示当前目的地桌号，这样服务员远远看到就知道这车是给哪桌送的，能主动让路或者协助取餐。这个小功能对实际运营效率的提升，比我预想的要大得多。

6. 点餐、调度与电梯联动：单车跑通只是开始

车能自己在场地里跑一圈，恭喜你完成了 40%。剩下的 60% 全在"业务逻辑"上，这部分没有标准答案，也是最考验工程能力的地方。

6.1 任务状态机：把异常都列出来

一台送餐车的任务流程看起来很简单：接单 → 去取餐点 → 等待装餐 → 送到目标桌 → 等待取餐 → 返回。但每一个箭头之间都藏着一堆异常分支，必须用状态机把这些都覆盖到：

• 接单后目标点被占用（有人站在那儿）→ 等待 N 秒后重新规划，超时则通知后台；
• 到达取餐点但没人装餐 → 语音提示，超时（比如 3 分钟）后返回待命区或通知服务员；
• 送餐途中电量低于阈值 → 完成任务后自动返回充电，或者中途请求换车；
• 到达桌位但餐没被取走 → 停留 5 分钟后自动返程，同时上报后台；
• 定位丢失 → 原地停车、语音提示、上报，等待人工干预，绝对不能盲目移动。

状态机的每个状态都要有超时保护和异常出口，这是我在实际项目里被教育得最狠的一点。Demo 里可以假设一切顺利，真实场景里 30% 的任务都会走到异常分支。

6.2 多车调度：路口堵死是怎么发生的

两台以上车就要考虑调度。最简单的做法是中央调度器分配任务 + 每台车自己做局部避障，但这样会出现一个经典问题：两台车在窄通道里迎面相遇，互相避让，结果一起卡住。

解决方案分两个层次。静态层面：在地图里把窄通道标记为"单行区"或者"互斥区"，同一时间只允许一台车进入，用信号量锁住，其他车在区域外等待。这个做法简单有效，代价是通行效率降低。动态层面：给每台车设置优先级（比如载餐的车优先于空车返回），优先级低的主动退让到最近的避让点。避让点要提前在地图里标好，不能临时找地方。

还有一个隐藏问题：多车同时用同一套 Wi-Fi 通信，信道拥塞导致指令延迟。工程上的解法是把心跳包和指令包分开，心跳用 UDP 高频发（丢了无所谓），指令用 TCP 保证到达，同时控制单包大小。如果车辆数量超过 5 台，建议单独拉一个 AP 专用信道。

6.3 电梯和闸机的联动：最容易被低估的工作量

跨楼层送餐必须联动电梯。这件事的难度不在于技术，在于设备不归你管。常见的做法有几种：

• 通过电梯厂家的开放接口（如果有）下发呼梯和楼层指令，这是最理想的；
• 加装外挂模块，模拟按键信号，或者通过轿厢内的控制板串口通信，这需要和设备方协调；
• 用机械臂按按钮，最土但最通用，缺点是慢且容易坏。

闸机同理，要么对接门禁系统的继电器干接点，要么用 UWB/蓝牙做靠近自动开门。不管哪种方式，都要设计降级方案：联动失败时车停在电梯厅等待并通知人工，不能一直原地重试。

6.4 交互终端：越简单越好

车身上的交互界面，我建议只保留三样东西：当前任务状态（去哪、还剩多久）、一个"到达/取餐"确认按钮、一个求助按钮。别做复杂的点餐菜单，那不是车的活。真正的点餐入口在客人的手机上，车只是个执行终端。界面做得越简单，出故障的概率越低，清洁和维护也越方便。

7. 联调实测：从"能跑一圈"到"跑一百圈不出事"

到了这一步，硬件装好了，代码也写完了，最痛苦的部分来了。我把联调的顺序和典型故障整理成一套可执行的流程，你可以直接拿去用。

7.1 分层联调，绝不跳步

联调最忌讳的就是"全都接上跑一遍看看"。正确顺序是：

1. 单电机空载测试：只接一个电机，给定固定 PWM，看转速是否稳定，编码器计数是否线性增长。这一步能筛掉 80% 的接线错误。
2. 双电机直线测试：两个轮子装车，给定相同的目标速度，看车能不能走直线。走偏说明两个电机的实际转速有差异，需要做 PID 参数整定或者加前馈补偿。
3. 里程计标定：让车沿直线跑 5m，测量实际距离和里程计读数，算出比例系数；再原地转 10 圈，标定角速度系数。这一步不做，后面的建图和定位全是歪的。
4. 传感器单独验证：雷达数据可视化看是否正常，IMU 静止时漂移多大，超声波对着墙和对着人分别测距。
5. 静态建图：手动遥控车绕场一周建图，检查地图是否有重影、闭环是否成功。
6. 单点导航：给定一个目标点，看车能不能规划出来并到达，先不装餐、不载人、速度降到 0.3m/s。
7. 多点连续导航 + 动态避障：安排人在路径上走动，看避障是否平滑。
8. 业务全流程：接单、取餐、送达、返航，跑通完整链路。
9. 压力测试：连续跑 4 小时，记录每次异常。

7.2 典型故障排查表

7.3 现场部署的几条硬经验

第一，首日一定要有人跟车。不管测试跑得多好，第一次进真实场景一定会遇到没预料到的情况，有人跟着能第一时间处理，也能收集到最有价值的反馈。

第二，给运营方留一个"人工接管"的手段。一个手柄、一个手机遥控页面都行，让他们在车卡住的时候能自己解决，而不是等你到场。这一点极大影响项目的口碑。

第三，日志要存本地也要传云端。出问题的时候，现场日志是唯一的真相来源。建议记录：时间戳、位姿、速度指令、传感器关键值、状态机当前状态、异常事件。日志量控制好，别把存储写满。

第四，预留 OTA 升级通道。部署之后改需求是必然的，能远程升级能省下大量跑现场的时间。

最后分享一个我觉得最实用的心得：在车身上贴一张"故障代码速查表"，把最常见的 10 个异常状态和对应的处理动作印上去，服务员看一眼就知道该怎么办，比如"闪红灯 3 次 = 定位丢失，请把车推到空旷处按复位键"。这个土办法解决了我项目里 60% 的现场求助电话。

这套方案我从机械算到调度，链路是完整的，但真做起来，每个环节都还有得磨。我的建议是先把最小可跑版本（能遥控、能单点导航、能停住）做出来，再往上叠功能，别一上来就追求全自动多车调度。毕竟送餐车这个事，能稳定送一百趟不出事，比能炫技送一趟重要得多。