简介极智嘉CEO郑勇关于机器人改变物流业的深度分享以一份PDF文档完整呈现适合智能物流从业者、机器人技术爱好者以及关注自动化趋势的读者阅读。内容以Kiva系统为例指出其并非传统AGV而是依托软件算法决策的智能机器人并系统梳理了郑勇从外企工业机器人工作、资本圈投后管理到看准物流自动化方向、组建清华技术团队并创立极智嘉Geek的完整经历。文中还结合2015年双十一在天猫超市仓库的实战落地说明了“货到人”拣选系统的研发过程与迭代思路同时客观分析了物流自动化面临的高成本、技术壁垒以及与现有仓储体系整合等挑战。此外也提及机器学习、深度学习与机器人结合将为物流行业带来更大想象空间。整份PDF共1个文件大小3.92MB便于系统阅读和存档目前已有205人学习适合用作机器人与物流交叉领域的参考资料。1. 货到人不止 Kiva机器人改变物流业的起点一个技术圈里流传甚广的判断是“Kiva 只是‘货到人’的一种机器人将改变物流业。”这句话从 Geek 郑勇的口中说出来听起来像是行业展望实际上是给整个物流自动化赛道定了边界Kiva 解决了“货架到人”的问题但它不是唯一解甚至不是所有场景下的最优解。以五年以上从业者的视角去看影响这个产业走向的并不是某家公司的某一台机器人而是“货到人”这套逻辑背后的调度算法、存储密度、任务时效与系统柔性。这篇文章会把“货到人”拆开来讲从 Kiva 的工作原理到穿梭车、机械臂、潜伏式 AMR 的对比再到自建系统时真正需要调参、写代码、踩坑的环节。理解了这些才算看懂郑勇这句话的技术分量。2. 拆开“货到人”Kiva 的位置、AMR 变体与拣选策略2.1 “人到货”和“货到人”优化目标变在哪里传统电商仓的拣选模式是“人到货”拣货员推着拣货车在巷道里走到货位前扫码、拿货、再走。这种模式下行走时间通常占拣选周期的 60% 以上而且人的行走路线受货架布局限制很难持续压缩。于是“货到人”把问题反过来——人不动货物动。拣选工位固定机器人把货架、料箱或托盘搬运到操作员面前。从数学上看这是把“拣选路径优化”问题转化为“搬运任务调度”问题。人到货的路径规划是 NP 难的车队路由问题而货到人系统中机器人的调度窗口是可以被打散的同样一批订单可以异步分配给多台机器人再通过工位合并。换句话说“货到人”真正的优化目标不是缩短人的走动而是让“货物在途等待时间”与“拣货员空闲时间”同时最小化。这也是为什么“货到人”会被当作一个系统问题而非单机问题来设计。你选择 Kiva 式货架搬运、穿梭车密集存储还是料箱机器人本质上是选择一种“搬运粒度”是一整个货架被搬过去还是一个料箱被取出来甚至是一个个商品被机械臂抓起来搬过去。2.2 Kiva 的机制货架搬运不是终点而是一种密度折中Kiva 式系统也叫货架式 AMR的基本工作流程如下WMS 下发拣选任务AMR 接到任务后行驶到指定货架下方举升整个货架然后带着货架驶向拣选工位拣货员在人机交互界面上扫描取货完成后 AMR 再把货架放回库存区。这套机制的关键指标是“货架命中率”一个被搬出来的货架能否覆盖当前订单中足够多、足够快的待拣商品。货架式方案的好处在于改造成本低、SKU 密度高。机器人不需要知道商品在货架第几层——反正整个货架都搬给你。但代价同样明显一台机器人一次只能搬运一个货架而货架重量可能达到几百公斤机器人必须把很大一部分能耗花在“举升和运输一个并不一定装满需求的货架”上。从系统设计角度看Kiva 本质是一种“以搬运换拣选”的折中。它牺牲了机器人单位时间内的搬运效率换来了人工拣选效率的大幅提升。适合的是大量 SKU、订单波次大、货架命中率高的场景。可如果订单只有几个爆款、SKU 极少货架搬来搬去反而是浪费。这里可以给出一个常见参数表便于把概念落到数字上参数Kiva 式货架搬运常见值穿梭车式密集存储常见值机器人/穿梭车速度1.5~2.0 m/s2.0~4.0 m/s轨道内单次载重300~600 kg25~50 kg料箱搬运对象整个货架料箱或托盘存储密度中等高通道极窄柔性高不依赖固定轨道低至中依赖密集货架典型投资规模中小仓到大型仓均可更适用于高密度存储场景如果你是做技术选型的第一件事不是比较机器人品牌而是先算清“我要把什么作为搬运的最小单元”。这是整个方案的分水岭。2.3 除了 Kiva穿梭车、机械臂、料箱机器人都是“货到人”“货到人”远比 Kiva 丰富。穿梭车Shuttle系统是另一条重要的技术路线。它运行在货架巷道内的轨道上可以直接驶向目标货位把料箱取出来再通过提升机送到拣选工位。相比 Kiva 的“整架搬运”穿梭车搬运的是料箱粒度更细因此存储密度和单位吞吐量可以更高。但代价是机械结构更复杂轨道的空间固定性让系统天然不如 Kiva 柔性。机械臂也正在加入这个故事。六轴机械臂在视觉引导下抓取箱内商品AGV/AMR 负责把商品送到包装位形成完整的“货到人”闭环。诸如“机器人终端执行器”和夹具设计会成为这类项目的真实技术瓶颈——你可能用吸盘抓取盒装商品但要换到袋装零食就可能整套夹具失效。还有一种被低估的变体是“混合式货到人”一部分货架由 AMR 搬运一部分高位密集存储由穿梭车处理中间用传送带或提升机衔接。这种结构正在取代单一种类的“货到人”。我在实际项目里见过最稳定的配置是“Kiva 式处理波次中的零散订单 穿梭车处理整箱出库”两种设备共用同一个 WMS 任务池通过调度层统一分配。2.4 为什么“一种”这两个字才是重点如果只把 Kiva 当作标杆很容易陷入“复制亚马逊仓库”的思维。但郑勇那句话的潜台词是机器人技术会持续改变物流作业的底层逻辑但具体形态可以百花齐放。比如不同仓库维度决定了技术路线楼层仓载荷低更倾向轻量料箱机器人高标库层高高才能塞得下穿梭车匹配的立体货架冷库场景机器人电池续航衰减快充电策略比拣选算法更影响效率门店越铺越密前置仓面积可能只有几百平方米这时候一台可原地旋转的差速驱动 AMR 比三台的调度系统更实用。因此做物流机器人项目最重要的是先把“需求形态”翻译成“搬运粒度”再考虑品牌和算法。这一步本身就筛掉了大量规格很漂亮、项目却很失败的系统。3. 自建 AMR 系统要把三件事做对地图、调度和死锁避免3.1 地图表示栅格、拓扑与车道地图无论买成品还是自研“货到人”AMR 软件的起点都是地图模型。栅格地图适合建图阶段但对实时路径规划而言计算量偏大。更常用的是拓扑地图节点代表货位、工位、交叉口边代表可行路径。如果系统要支持大量双向行驶还需要加入车道方向属性——只在单向上允许通行的边或者给路径加边权比如转弯代价和等待代价。回到 ROS2 语境下导航栈离不开 SLAM 建出的栅格地图但落地时我更建议在 SLAM 地图之上手工清理一遍标注出真正的“车道网络”。原因是建图得到的栅格地图往往包含货架底下、墙边等不可达区域机器人主体可以通行但货架抬升后可能刮蹭。地图一旦定义不干净路径规划算法再强也没有用。常见的做法是对接 VDA 5050 这类标准接口。它定义了 AGV 与调度系统之间的通信消息格式比如请求任务、报告位置、上报状态。在自研架构中即使不完整实现 VDA 5050也建议把路径规划与车辆控制解耦保持类似接口的语义这样后期更换车辆品牌时不必重写调度层。3.2 路径规划从 A* 到时间窗预留单机路径规划最稳的选择还是 A*扩展方式无外乎加权 A*、混合 A* 两轮车辆以及针对举升 AMR 的“负载/空载”双层代价地图。单机好做系统难的是多机并发下的路径冲突。一个直接可行的方法是“时间窗预留”把每条路段按时间片记录占用申请路径时检查时间窗是否冲突。比如两车要经过同一个十字路口系统为 A 车预留 2 到 4 秒、B 车预留 4.5 到 6.5 秒如果重叠就重新规划。更细化的方案是“预约式 A*”每个节点在计算代价时把未来时间占用也纳入估价函数。它的优点是不需要锁路段缺点是非常吃调度服务器的 CPU。下面是这类调度逻辑的一个极简 Python 演示只用列表模拟路段占用和冲突检测没有接真实的导航栈但能完整展示调度的核心逻辑class RoadSegment: def __init__(self, seg_id, duration): self.id seg_id self.duration duration # 通过该路段需要的时间(秒) self.booked [] # 已预定的(开始,结束)时间窗 def is_free(self, start_time): end_time start_time self.duration # 检查是否与现有时间窗重叠 for (s, e) in self.booked: if max(start_time, s) min(end_time, e): return False return True def book(self, start_time): self.booked.append((start_time, start_time self.duration)) class FleetScheduler: def __init__(self, segments): self.segments segments # 字典: 路段id - RoadSegment def plan_path(self, path_edges, request_time, robot_id): # 依次为每段路段预约时间窗 t request_time for seg_id in path_edges: seg self.segments[seg_id] if not seg.is_free(t): # 冲突顺延时间 t seg.booked[-1][1] 0.5 if not seg.is_free(t): return False, frobot {robot_id} cannot reserve {seg_id} seg.book(t) return True, frobot {robot_id} planned at {t}这里is_free检查区间是否重叠book写入占用区间。真实系统里还需要区分路径方向的单向边以及把每个路段的预留信息按时间戳定期清理否则运行几小时后的内存占用会不断膨胀。调度参数上值得手动控制两个值最小跟车距离和最小预留间隔。前者决定物理安全后者决定系统吞吐。间隔设大了车等得久设小了死锁概率会急剧上升。3.3 车队级死锁控制先分仓再调度多台 AMR 在货架巷道里相遇是很常见的事。如果路径规划全部交给全局调度器容易出现“互相等待”的环状死锁A 车要进巷道B 车堵在巷道口而 B 车要去的方向又被 C 车堵住C 车正等着 A 车让路。越是高密度存储区越容易触发。业界常用的策略有三种按实现成本递增排列区域准入控制把仓库地图划分成分区设定最大车辆数。每个分区有独立信号量车进入前必须先申请配额。单向巷道把窄巷道全部改成单行线从根上消灭对向冲突。这是最简单也最有效的操作但会拉长绕行距离。资源锁与优先级回退对每个交叉口、货架位位置等关键资源设读写锁低优先级车辆看到资源被占用时自动回退到最近的避让点。我一般建议把三种混用主干道双向 巷道单向 分区配额 关键点资源锁。这套组合在中等规模仓库里足够稳定也不需要上强化学习。3.4 计算资源配置与关键参数表对于总车辆数 50 台以内的系统调度服务器只需要 8 核 16 GB 的普通服务器瓶颈一般不在 CPU而在消息中间件的延迟与可靠性。如果使用 ROS2注意把rmw_fastrtps的双向通信超时参数调大一点物流现场 Wi-Fi 波动很容易触发节点“失联”日志刷屏但那并不代表车辆真的失联。系统设计时应留出的基础参数建议直接固化在配置中心里参数名称建议取值设置依据车速目标值2.0 m/s负载情况下急停距离要控制在 0.5 m 内最小跟车距离1.2 m空载、低成本磁导航精度下留出反应距离充电阈值20% 电量低于该值强制去充电桩排队充电桩数量车辆数的 1/6快充模式 30 分钟可补 40% 电量任务超时120 s超过则触发二次任务分配拣选工位空闲阈值5 s工位空闲超过 5 秒说明机器人任务下发滞后这套参数并不是固定的但它能保证系统在早期铺量时不至于在物理安全上翻车。真正要调的是“任务下发提前量”WMS 一旦产生拣选任务调度器可以不等机器人空闲就直接分配给某台车让车辆在执行完当前任务后立刻进入下一任务中间不产生空窗。4. 吞吐量怎么算、机器人怎么配从 Kiva 经验到替代方案4.1 用循环时间公式估算机器人数量机器人数量是“货到人”项目里第一个被老板问、第一个被销售糊弄的数字。用经验值估算其实是可行的单台机器人循环时间 空载驶向货架时间 举升时间 负载驶向工位时间 放下时间 返回时间。把这几个时间拆开单位都是秒。假设仓库平均搬运距离是 45 米机器人空载速度 2 m/s、负载速度 1.8 m/s举升和放下各 5 秒那么一个循环大约 45/2 45/1.8 5 5 55 秒。每小时产能约为 65 次循环。如果实际系统的任务目标是每小时拣选 500 个订单且平均每单需要 4 次搬运那么需要的搬运次数是 2000 次/小时机器人数至少是 2000/65 ≈ 31 台。这个初步计算忽略了充电、交通堵塞和任务分配不均衡。一种更稳妥的做法是乘上一个 1.3 到 1.5 的修正系数得出实际要部署 40~45 台。用一段简短的 Python 代码可以快速改变输入参数看结果def estimate_amr(distance_m, v_empty, v_loaded, lift_time, tasks_per_hour): empty_time distance_m / v_empty loaded_time distance_m / v_loaded cycle_time empty_time loaded_time 2 * lift_time cycles_per_hour_per_amr 3600 / cycle_time required_cycles tasks_per_hour amr_count required_cycles / cycles_per_hour_per_amr return cycle_time, amr_count * 1.4 # 加入1.4倍裕量 # 常见参数下45米平均距离2m/s空载1.8m/s负载每次举升5秒 time, count estimate_amr(45, 2.0, 1.8, 5, 2000) print(f单车循环时间: {time:.1f} 秒需要机器人: {math.ceil(count)} 台)这里的核心逻辑是先把业务侧的需求转换成“每小时搬运次数”再反推车辆数。多数选型失败都发生在这步之前业务需求还是模糊的“每天处理几万单”没有折算成峰值小时的搬运次数。峰值小时系数通常取 1.5否则按日均算出来的机器人数量在促销高峰期必然瘫痪。4.2 不同“货到人”方案的成本结构比较机器人数量只是其中一个变量。Kiva 式货到人的投资大头在机器人、货架、充电桩、调度软件和与 WMS 的接口开发。穿梭车系统则要把大量成本花在定制钢平台、轨道和提升机。机械臂拣选看起来“机器人感”最强但终端执行器和视觉调试的边际成本往往比车体更贵。做技术决策时建议把三年五年总成本拆成四块设备折旧、安装施工、软件集成、运维人员。Kiva 式的运维人员需求最低因为货架和机器人本体都属于通用设备穿梭车系统一旦巷道卡料箱需要有经验的机械背景人员机械臂视觉误抓之后要花在重新标定上的时间通常被严重低估。如果仓库面积小于 5000 平方米SKU 数量又少更合适的方案甚至算不上“货到人”——直接调整货架布局、用播种式拣选就够了。强行上机器人系统只会让单位成本难看得多。4.3 一个不被注意的效率漏洞任务波次拆分项目上线三个月后吞吐量通常会稳定在某个值这时优化重点会转向两类工作一是 WMS 里的波次策略二是调度器里的订单优先权。两者紧密相关。一个我只能在这里提醒的坑是“机器人同名任务重复搬运”。当同一波次中订单 A 和订单 B 都需要来自同一货架的商品时如果 WMS 没有把这两个拣选任务合并成同一个“货架访问任务”系统就会让机器人把那台货架搬两次。很多小型团队在自研调度器时容易忽略这个订单聚合模块。解决办法是在 WMS 下发任务前对所有待处理订单做一个商品-货架映射的聚类。把需要同一个货架的订单绑定在一起生成一个“货架任务”等货架到达工位后由拣选界面依次处理多个订单。5. 什么才是真正改变物流业用现场数据校准仿真的技巧现在回到开头的判断“机器人将改变物流业。”这句判断不是口号而是可以在日常工作中验证的工程任务。真正的技巧在于不断用现场数据校准系统模型让机器人集群的吞吐量预测与真实数据误差控制在 5% 以内。我常用的验证方法是 FIFO 数据回放从 WMS 导出最近两周的订单明细包括下单时间、商品所在货架、拣选完成时间然后把这些订单塞进离散事件仿真脚本里去跑。仿真脚本里不需要重建完整仓库三维模型只需要保留三样数据订单-货架映射、每个货架到工位的距离矩阵、机器人的循环时间分布。把真实系统里的任务时长、等待时长作为随机变量输入通过仿真看瓶颈是否落在拣选工位或充电排队上。一个简单的做法是把 WMS 的拣选流水导成 CSV用 SQL 做初步分析看看拣选间隔是否符合泊松分布假设。如果频繁出现“同一时刻堆积十个任务、下一秒任务为空”的尖峰流量这意味着调度器的负载模型不能简单按均值估算而要考虑排队论里的 M/D/1 或 M/M/c 队列。此时需要调整的不一定是机器人数量而是任务下发节流让分配曲线更平滑。具体操作上可以在调度器里增加一个标准化的指标拣选工位利用率 工位人工拣选时间 / (工位空闲时间 人工拣选时间 等待机器人时间)。当等待机器人时间占比超过 20%说明任务下达不够早当工位空闲时间超过 30%说明机器人任务池深度不足。盯住这个指标去调远比看一份日报有价值。技术的推进不会停在某一台车或某一座仓库里。既然“货到人”已经长出了 Kiva 之外的好几条分支下一步就会从“机器人搬运”走向“机器人决策”让机器人自己根据实时订单压力和自身电量调整任务优先级把充电时机与订单波谷预测绑在一起。把这条验证闭环跑通才是工程师真正参与改变物流业的地方。本文还有配套的精品资源点击获取