简介这份PDF资料围绕极智嘉CEO郑勇的创业经历与行业洞察展开面向物流自动化从业者、机器人方向研究者及关注智能仓储的读者帮助理解“货到人”模式的本质与物流机器人的落地路径。资源共1个PDF文件压缩包约3.92MB内容为完整的访谈与案例正文便于通读与引用。资料从Kiva被亚马逊收购切入梳理郑勇从ABB、圣戈班到新天域资本再到2014年组建清华技术团队创立Geek的历程并详解极智机器人拣选系统在2015年双十一天猫超市仓库的实战应用。文中还讨论了机器人系统与仓储管理体系的整合、复杂环境下的稳定性、算法与软件迭代等技术壁垒以及硬件成本、维护升级等现实难题并涉及机器学习、深度学习与物流自动化结合的前景。目前已有205人学习适合作为物流机器人方向的专业参考与案例素材。1. 从一份 2017 年的访谈 PDF 说起Kiva 只是“货到人”的一种如果你手里正攥着一份《Geek 郑勇Kiva只是“货到人”的一种机器人将改变物流业.pdf》大概率不是来读人物故事的。做智能物流、AGV 调度、仓储自动化的人真正想从这份材料里挖的是三件事Kiva 模式到底特殊在哪、Geek 当年凭什么把“货到人”跑通、以及这套逻辑放到今天的 AGV 路径规划和多机调度里还成不成立。这份 PDF 是 2017 年《机器人产业》杂志的一篇深度访谈主角是极智嘉创始人郑勇内容覆盖了他从 ABB、圣戈班到新天域资本再到 2014 年底组建团队、2015 年双十一在天猫超市仓库落地第一代拣选机器人的完整过程。它适合三类人正在做仓储机器人选型的集成商、研究多 AGV 调度算法的学生、以及想搞清楚“货到人”和传统 AGV 边界的产品经理。下面我不按文章顺序复述而是把它拆成能直接对照自己项目用的技术笔记。2. 拆解 Kiva 式“货到人”和传统 AGV 的本质分界在哪2.1 为什么说 Kiva 不是 AGV而是带算法的机器人系统原文里郑勇有一句话很关键“Kiva 并不是传统的 AGV而是依托于软件系统算法的智能机器人。”这句话如果只当口号看就浪费了。传统 AGV 的典型工作方式是沿固定路线磁条、二维码、激光反射板来回搬运路径是预先写死的车与车之间基本不做全局协商。而 Kiva 式系统里机器人只是执行末端真正决定效率的是上层的订单分配、货架热力图、路径规划和交通管制算法。换句话说传统 AGV 卖的是“车”Kiva 卖的是“车 调度大脑”。这个分界直接决定了你的项目该往哪个方向投入。如果你只是要把料车从 A 点送到 B 点固定路径 AGV 就够了成本低、实施快。但如果你面对的是电商仓那种 SKU 长尾、订单碎片化、大促期间波峰波谷剧烈的场景固定路径就会崩——因为货位是动态的拣选员的位置是动态的机器人数量也是动态的。原文提到 Geek 系统“可以通过机器人数量的增减动态灵活地应对大促期的高峰物流问题”这背后就是调度算法在支撑而不是硬件本身。从技术栈角度看一套“货到人”系统至少包含四层机器人本体驱动、举升、避障传感器、通信层WiFi 或专用无线、心跳与任务下发、调度层任务分配、路径规划、死锁避免、业务层WMS 对接、拣选站交互、播种墙电子标签。原文里 Geek 团队“先从系统软件着手差不多一年之后才从软件转到硬件”这个顺序很值得注意——很多团队一上来先造车结果车能跑但系统跑不通最后卡在调度上。2.2 从订单到货架一次“货到人”拣选的完整数据流把原文描述的拣选过程翻译成工程语言一次典型的“货到人”作业大致是这样的# 伪代码货到人拣选的一次任务闭环 # 1. 订单池聚合把多个订单中相同 SKU 合并减少搬运次数 def aggregate_orders(order_pool): sku_map {} for order in order_pool: for sku, qty in order.items: sku_map.setdefault(sku, []).append((order.id, qty)) return sku_map # {sku: [(order_id, qty), ...]} # 2. 货架选择优先选离拣选站近、且命中多个订单的货架 def select_pod(sku_map, pod_positions, station_pos): candidates [p for p in pod_positions if p.sku in sku_map] # 代价 距离 命中订单数的倒数命中越多越优先 return min(candidates, keylambda p: dist(p, station_pos) / len(sku_map[p.sku])) # 3. 任务下发机器人去货架下方举升搬运到拣选站 def dispatch_task(robot, pod, station): robot.move_to(pod.position) # 空载行驶 robot.lift(pod) # 举升货架 robot.move_to(station.position) # 载货行驶 station.notify_arrival(pod) # 通知拣选员 # 4. 拣选完成货架回库或直接去下一个站 def after_pick(pod, next_task): if next_task: dispatch_task(next_task.robot, pod, next_task.station) else: pod.return_to_storage()这段伪代码里真正影响效率的是第 1 步和第 2 步。订单聚合做得好一次搬运能命中更多订单行货架选择做得好机器人空驶和载货行驶的里程都会下降。原文提到“单个仓库每日的拣货量最高可达到 50000 件”“单个分区机器人数量最多 50 台”在 50 台这个量级下路径冲突和死锁就会开始出现调度层必须做交通管制否则机器人会在通道里互相堵死。提示如果你在复现类似系统先用仿真跑通 20 台以下的调度再逐步加量。50 台不是简单线性放大冲突概率会非线性上升。2.3 机器人本体参数30cm 高度和避障能力意味着什么原文提到 Geek 机器人在细节上“高度压缩在 30cm 以下运行速度标准化以及避障能力”。这几个参数不是随便写的。30cm 以下的高度决定了机器人能钻到货架底部举升货架底部净空必须大于这个值否则举升会撞架。运行速度标准化意味着不同批次的机器人速度一致否则调度算法里按统一速度算的到达时间会失准导致路口抢占判断错误。避障能力则关系到安全——原文说“24 小时工作”人机混场时避障是底线。如果你在做选型或自研这几个参数要写进验收标准举升高度、举升重量、空载/满载速度、最小转弯半径、避障传感器类型激光雷达还是超声红外、电池续航与充电策略。原文没有给出具体数值但给出了方向——高度要低、速度要统一、避障要可靠。3. 把访谈里的经验落到工程调度、仿真与成本核算3.1 多 AGV 路径规划从 A* 到冲突消解原文没有展开算法细节但“货到人”系统的核心就是多机调度。常见做法是分层底层用 A* 或 Dijkstra 算单车最短路径上层做冲突检测和消解。下面是一个简化的时间窗冲突检测示例# 基于时间窗的多 AGV 冲突检测简化版 # 每台机器人提交自己的路径和时间戳检查是否有重叠 def detect_conflict(paths): # paths: {robot_id: [(node, t), ...]} occupancy {} # {(node, t): robot_id} conflicts [] for rid, path in paths.items(): for node, t in path: key (node, t) if key in occupancy and occupancy[key] ! rid: conflicts.append((rid, occupancy[key], node, t)) occupancy[key] rid return conflicts # 消解策略优先级高的先走低的等待或重规划 def resolve_conflict(conflicts, robots): for r1, r2, node, t in conflicts: if robots[r1].priority robots[r2].priority: robots[r2].wait_at_current(t) # 低优先级等待 else: robots[r1].wait_at_current(t)这段代码的关键参数是时间粒度。粒度太粗冲突检测不准粒度太细计算量大。工程上一般按机器人走一个格子的时间作为最小单位。另外等待策略要有超时否则低优先级机器人可能永远等下去形成活锁。注意A* 只解决单车最优多车场景下局部最优不等于全局最优。实际系统里常用“预约表”或“令牌环”方式做路口管制简单但有效。3.2 用仿真验证调度策略别直接上真车原文提到 Geek 在清华 FIT 楼楼道里测试原型被物业赶来赶去。那是硬件原型阶段的无奈。今天做调度算法完全没必要先上真车。常见做法是用 ROS 2 Gazebo 或者专门的物流仿真软件搭一个仓库模型把货架、通道、拣选站、机器人数量都参数化先跑通逻辑再上硬件。如果你用 ROS 2大致流程是建仓库地图 → 导入机器人模型URDF→ 配置导航栈Nav2→ 写调度节点 → 用 rosbag 记录运行数据 → 分析拥堵点和任务完成时间。仿真里能复现的问题真车上大概率也会遇到仿真里跑不通的真车一定跑不通。3.3 成本账为什么“机器换人”不是简单替换原文提到郑勇从机械臂转向物流机器人的一个理由是机械臂核心零部件依赖国外品牌成本高而物流机器人对精度要求低很多零部件可以从国内供应链买到。这个成本逻辑今天依然成立。一套“货到人”系统的成本不只是机器人单价还包括货架改造、地面处理平整度、二维码/反光板铺设、充电桩、网络覆盖、WMS 对接开发、运维人力。原文说“单个仓库每日拣货量最高 50000 件”如果按这个量算机器人数量、拣选站数量、充电策略都要匹配否则会出现机器人排队等充电或者拣选员等货架的情况。成本项传统人工仓货到人系统备注拣选人力高随订单量线性增长低拣选员固定在站台大促期间差距更明显机器人无按分区数量配置可租赁或分期地面与货架改造低中高一次性投入系统对接无中WMS 接口开发运维低中需要技术人员这张表不是让你直接抄而是提醒你算账要算全生命周期不能只比机器人单价和人工工资。4. 避坑与排查复现“货到人”系统时最容易翻车的五件事4.1 现象机器人到了货架下面却举升失败原因货架底部净空不够或者机器人停位偏差超过举升机构容差。原文提到机器人高度压缩在 30cm 以下但货架底部如果变形、地面不平实际净空可能不够。 解决验收时用塞尺检查每个货架底部净空地面平整度按机器人厂商要求施工停位精度靠二维码或激光定位保证。4.2 现象多台机器人在路口互相等待谁也不走原因冲突消解策略没有超时机制或者优先级设置不合理导致活锁。 解决给等待加超时超时后强制重规划或者用集中式调度器统一分配路口通行权而不是让机器人自己协商。4.3 现象大促期间系统响应变慢任务下发延迟原因订单池聚合算法复杂度太高或者通信层带宽不够。原文提到双十一“订单压力”波峰时任务量可能是平时的数倍。 解决订单聚合做增量计算不要每次全量重算通信层用专用频段或 5G避免和办公 WiFi 抢带宽。4.4 现象机器人避障太灵敏频繁急停效率下降原因避障传感器阈值设置过保守或者人机混场时人走动触发误判。 解决根据场景调整避障距离和减速策略拣选站附近可以设低速区而不是急停区。4.5 现象WMS 和机器人系统对接后库存对不上原因任务完成信号和库存扣减不同步或者异常任务如拣选取消没有回滚。 解决设计幂等接口每个任务有唯一 ID完成和取消都要回调对账程序定期比对库存和任务记录。5. 进阶从“货到人”到整仓智能化的验证方法原文最后提到 Geek 的中长远规划是“围绕仓储的智能设备研发机械手、智能叉车等”这说明“货到人”只是起点。如果你现在要验证一个仓储智能化方案是否靠谱我一般会走这三步。第一步用历史订单数据回放。拿客户过去一个月的订单流水在仿真系统里跑一遍看机器人数量、拣选站数量、充电策略是否匹配。重点看波峰时段的任务完成率和机器人利用率。如果仿真里波峰就崩真车一定崩。第二步小规模实地试点。选一个分区部署 10 到 20 台机器人跑真实订单但保留人工备份。记录每个环节的耗时机器人到货架、举升、搬运、拣选、回库。找出瓶颈工位。原文提到 Geek 第一代产品在双十一实地使用本质上就是一次大规模试点但那是被逼出来的正常项目应该先小规模验证。第三步压力测试和故障注入。故意让部分机器人离线、让网络抖动、让充电桩排队看系统能不能降级运行。很多系统平时跑得好一遇到机器人故障就全仓瘫痪就是因为没有做故障注入测试。# 仿真环境压力测试示例ROS 2 # 启动 50 台机器人仿真 ros2 launch warehouse_sim multi_robot.launch.py robot_count:50 # 注入网络延迟 tc qdisc add dev eth0 root netem delay 100ms # 记录任务完成时间 ros2 topic echo /task_completion_time --csv stress_test.csv这段命令的意思是先在仿真里拉起 50 台机器人然后用tc注入 100ms 网络延迟模拟无线抖动同时记录任务完成时间。跑完后分析 CSV看延迟对完成率的影响。如果 100ms 延迟就导致大量任务超时说明调度层对通信的容错不够需要加本地缓存或重试机制。提示故障注入要在仿真里做够不要等真车出问题再补。真车停线的成本远高于仿真跑几轮。从那以后我每次评估仓储机器人方案都强制走一遍“历史数据回放 → 小规模试点 → 故障注入”这三步缺一步都不敢下结论。希望帮到你。本文还有配套的精品资源点击获取