尧图网页设计 
简介这是一份源于省TI杯大学生电子设计竞赛的AGV自动化物流系统完整设计说明面向电子设计竞赛参赛者、物流自动化方向学习者及工程开发人员。文档围绕自动导向车AGV的自动装载、搬运、卸载与智能充电展开系统由多功能AGV与监控中心构成可执行预定路线、定位停车适用于汽车、家电等自动化装配及立体仓库场景。内容涵盖设计任务与总体方案中央处理器、动力转向、引导方式、障碍物检测等关键模块的选型论证装货卸货模块、黑白线信息采集、循迹控制、智能充电、声光报警等硬件电路设计以及主控流程、装卸货与充电程序的软件设计最后给出系统测试方案与结果。资源共1个doc文档包体大小889KB已有97人学习浏览适合需要快速了解AGV物流系统完整设计流程、用于课程设计或竞赛方案参考的读者。1. 一套AGV自动化物流系统设计说明先回答四个问题再动笔拿到《基于AGV的自动化物流系统设计说明.doc》这个标题别急着打开空白文档画拓扑图。产线扩容、仓储改造老板丢来一个文档名就让你出方案这类活儿我在集成商和甲方两头都干过最怕的就是把设计说明写成了产品宣传册。这份文档真正要回答的是四个问题为什么用AGV、用几台、走什么路、坏了怎么办。这四个问题对应的是需求分析、数量计算、路径规划、调度与故障恢复缺一个方案到现场就是翻车现场。这篇笔记就按这个顺序把一份能施工、能验收、能复现的AGV自动化物流系统设计讲透读者是物流规划工程师、项目经理以及刚入行做AGV集成的朋友。2. 需求与总体架构把节拍计算书写在导航选型前面2.1 从物料流量反推AGV数量先写计算书再画拓扑设计说明的第一页不应该是系统架构图而应该是节拍计算书。AGV数量错了后面所有路径规划都是白做。常见的计算方法是把每日物料流量拆成单循环时间需求量 Q托/天单次搬运循环时间 T分钟/趟单台车每趟可搬运 U 托可用工时 H小时/天综合效率 η数量 N 的公式是N (Q × T) / (60 × U × H × η)举个实际例子某电子厂总装线每天需要从立体库往产线送 1200 托物料单趟循环取货、行驶、卸货、返回实测 12 分钟一台车一趟搬 1 托两班制 16 小时效率系数取 0.85那么 N (1200 × 12) / (60 × 1 × 16 × 0.85) 17.6向上取整就是 18 台。注意这个 0.85 不是拍脑袋它包含充电等待、交通拥堵、人工干预折算我一般把这个系数拆成充电系数 0.95、交通系数 0.9、异常系数 0.9 再相乘写进设计说明里更能说服甲方。这套计算书还要留 15% 到 20% 的余量因为节拍是波动的。别听销售说“最高可达”要按「平均节拍 峰值系数」来算。峰值系数看行业电商仓储取 1.3产线配送取 1.15。把计算过程写进文档而不是只写结论这是设计说明和PPT的区别。抄作业的时候把公式里的参数换成自己现场的量测值拿秒表跟着车跑三趟取平均值别用厂家给的标称速度。2.2 AGV导航方式选型磁条、二维码、激光SLAM怎么选AGV技术栈的第一层就是导航方式选错后面全得返工。这里做一个对比表设计说明里最好也放一张同款导航方式定位精度地面改造柔性典型成本适用场景磁条导航±10mm需贴磁条低改路径要重贴低产线固定路径、环境干净的制造车间二维码导航±5mm需贴码/画码中重新标定即可中仓储、半固定路径且要求精度高的场景激光SLAM±10mm无需改造高地图重绘即可高路径频繁调整、人车混行、立体库周边选型逻辑不是“越先进越好”而是看路径改不改、精度够不够。磁条车成本低、调试快但产线工艺调整的时候重贴磁条就是一场灾难我在一个汽配厂见过产线移位 3 米十几条磁条全部重贴停产两天。如果甲方说“未来三年工艺大概率调整”直接引导他上二维码或激光SLAM别省这个钱。激光SLAM最贵但它有一个隐藏优势是另外两种给不了的不需要地面标识。在仓储场景里地面叉车、液压车来回跑磁条和二维码都会被压坏。我见过一个冷库项目凌晨零下 18 度磁条胶带直接脆裂换二维码贴纸也是半个月一换最后全换了激光车。设计说明里要把这个“地面标识存活率”写进去很多甲方根本没想到。2.3 系统架构分层调度层、车控层、设备层缺一不可AGV系统不是“车 软件”是一套分层架构设计说明里要把这三层之间的关系画清楚调度层AGV调度系统负责任务分配、路径规划、交通管理、死锁避免。这是多车系统的灵魂只有一台车的时候感受不到它的存在车一多就全看它了。车控层车载控制器负责导航计算、避障执行、速度控制、状态上报。每台车都是一个独立智能体但只对本车的运动负责。设备层执行机构与外围设备地面输送线、提升机、电梯、卷帘门、充电桩、人工呼叫终端。AGV要和这些设备握手才能完成物料交接。这一层叫法各厂不一样有的叫“上位机系统”有的叫“WCS”但职责边界是一致的。我推荐用“调度层 / 车控层 / 设备层”这个口径因为写设计说明时每一层的接口、协议、故障域是独立的——调度层挂了车应该原地停车等待车控层挂了调度层要能感知并重新派单。把这三层写清楚后面写接口规范才有据可依。3. 路径规划与多车调度从一台车的A*到多车共线不死锁3.1 栅格地图与A*算法先让一台车跑起来多车调度的地基是单机路径规划。常见做法是把场地地图栅格化每个栅格标记为可通行或障碍物然后跑A算法找最短路径。A是启发式搜索评价函数 f(n) g(n) h(n)g 是起点到当前点的实际代价h 是当前点到终点的估计代价。工程上用曼哈顿距离或欧式距离做 h 都行曼哈顿距离在栅格地图里更常用。用最小代码实现一个看得见的A*方便理解参数import heapq def astar(grid, start, goal): # grid: 二维列表0可通行1障碍 # start/goal: (row, col) open_set [] heapq.heappush(open_set, (0, start)) came_from {} g_score {start: 0} f_score {start: heuristic(start, goal)} while open_set: _, current heapq.heappop(open_set) if current goal: return reconstruct_path(came_from, current) for neighbor in get_neighbors(grid, current): tentative_g g_score[current] 1 # 每个格子代价1 if tentative_g g_score.get(neighbor, float(inf)): came_from[neighbor] current g_score[neighbor] tentative_g f_score[neighbor] tentative_g heuristic(neighbor, goal) heapq.heappush(open_set, (f_score[neighbor], neighbor)) return None # 无可行路径代码里最关键的两个参数是get_neighbors里的邻接方式四邻域还是八邻域和heuristic的选择。AGV通常不允许斜穿因为车体运动学约束是差速或舵轮斜行路径很难跟轨迹所以用四邻域。tentative_g g_score[current] 1这个 1 是每格的基础代价但真实项目里不能所有格子都一视同仁你需要给转弯、倒车、经过狭窄通道这些动作加权重否则A*会给出贴着障碍物走的路径现场看着就危险。给栅格地图做的另一个重要预处理是“障碍物膨胀”把障碍物栅格向外扩展 AGV 半径的像素量这样路径规划出来就不会擦墙。膨胀半径至少是车宽的一半除以栅格尺寸再留 100mm 安全余量。很多方案翻车就是忘了膨胀仿真里贴着墙走现场一跑就撞托盘腿。3.2 多车调度时间窗预留法是工程首选单机路径规划解决“从A到B怎么走”多车调度解决“三台车同时走会不会打架”。热搜里常提“三条AGV基本A算法”但真要管理三条车同时跑A本身不管用——它只管一条路不管道路占用。工程上最常见的可靠做法是时间窗预留法每台车申请路径时不是只申请“走哪条路”而是申请“哪条路、从什么时间到什么时候占用”。每条路段占用的时间窗计算def time_window(segment_length, speed, accel_time, intersection_reserve3.0): # 路段长度(米)、最大速度(m/s)、加减速时间(s) cruise_time segment_length / speed return { enter_time: 0.0, # 进入路段的时间点由调度器动态分配 exit_time: cruise_time 2 * accel_time intersection_reserve, segment_id: segment_id }时间窗要算的不是匀速行驶时间而是“从进入路段开始到车尾完全离开路口并留出安全距离”的时间。加减速时间在AGV里通常不小差速车 2 到 3 秒舵轮车 1 到 2 秒速度越快加速时间越长。intersection_reserve是我习惯加的路口净空时间默认 3 秒意思是前车离开路口后后车还要等 3 秒才允许进入给调度系统一个反应缓冲。调度器把每段路的占用时间写在时间窗表格里新任务来的时候按时间顺序倒查这段路有没有重叠占用有重叠就计算等待是否会导致整个任务超时如果等待小于阈值就把任务排队如果等待过长就重新规划一条绕行路径。这个策略在工业界极成熟不是因为算法漂亮而是因为它“可解释”操作员看到车停在那里能明确知道它在等哪条路段的哪个时间窗而不是面对一个黑匣子。3.3 死锁与多车共线的三个必调参数多车系统最大的坑是死锁。现象是两台车在交叉路口面对面停住谁也走不了。原因是两台车各自规划了路径互相把对方的必经之路占住了。死锁的常见处理有三个手段写设计说明时我会把这三个手段都写进去而不是只写一个一是单向循环地图。把车流行驶路线设计成顺时针或逆时针单行线从根本上消灭对向冲突。这是最土也最有效的手段但它增加行驶距离适合通道比较窄的老厂房改造。二是在线死锁检测调度器维护一个有向资源图检查是否存在环路发现环路就指定其中一台车后退让路。三是看门狗超时车在路口停留超过设定时间我一般设 30 秒长距离大车设 60 秒触发管理器介入强制重新规划或人工介入。必调参数还有两个路径规划超时时间和任务取消策略。A*在复杂地图里计算量会爆炸特别是地图尺寸超过 500×500 栅格的时候建议把单次规划超时设为 200ms超时就返回当前局部最优路径而不是干等。任务取消策略是当等待超过节拍允许时间调度器要把这个任务置为“延误”并提示人工介入千万别让系统无限排队。多车调度调试的血泪经验先加车后加路。把地图上的路径逐步加密而不是一次性把所有可达路径都放进去。路径越多A*可选空间越大但死锁概率也越高。我见过一个项目把所有库位都做了双向联通结果调度器每到高峰期就死锁还不好排查。4. 核心模块与数据流调度中心、通信协议、接口规范怎么定4.1 调度中心的功能拆解与任务状态机调度中心是这套系统的黑匣子但黑匣子不能真的“黑”它要对外暴露明确的任务状态。一个AGV任务的生命周期至少要包含这几个状态我用状态机来定义{ task_id: TASK-20250101-001, state: CREATED, state_flow: [ CREATED, // 任务已创建等待调度 DISPATCHED, // 已指派给某台车 MOVING, // 车辆正在执行路径 LOADING, // 正在对接输送线/装卸货 COMPLETED, // 已完成可释放资源 FAILED // 执行失败需人工处理 ] }状态流转规则里最重要的一条任务在 MOVING 和 LOADING 之间可以穿插“WAITING”状态即等待交通放行、等待设备握手。WAITING 不能无限挂起必须带一个 waiting_reason 字段写清楚在等什么。调度界面上的任务卡住时操作员看到 waiting_reason 是“waiting_for_time_window: segment_12_13”就能立刻定位是哪条路段堵了而不是面对一个“处理中”的假状态。我在这个状态机上吃过亏早期设计没加 waiting_reason现场堵车只能通过抓包去查后来全部补上故障定位时间从半小时降到两分钟。4.2 车-地通信协议先定报文帧格式再谈选型AGV调度系统和车载控制器之间的通信到底走什么协议Wi-Fi 是企业项目里最常见的选项但不是唯一解。先看实时性要求位置上报周期一般 100ms 到 500ms调度指令下发的端到端延迟要求小于 200ms。Wi-Fi 漫游会丢包这在AGV场景里很致命车在行进中丢失调度指令可能直接越过了安全边界。我一般这样定产线内固定路线且范围小5000平米内用 Wi-Fi 5 以上频段加厂内独立AP足够大面积仓储、有金属货架遮挡的地方使用私有射频或工业级 Mesh。通信协议用 TCP 长连接不要用 MQTT为什么虽说 MQTT 是现在物联网的名词但AGV领域讲究的是报文可追踪、帧格式固定更适合用底层的长度校验的自定义协议来保证实时性和可调试性。一份可落地的报文帧格式如下序号字段长度说明1帧头2B固定 0xAA 0x55用于同步2消息类型1B0x01 任务下发、0x02 状态上报、0x03 心跳3数据长度2B小端模式标明数据域字节数4数据域N B业务数据如坐标、速度、任务号5CRC162B数据域循环冗余校验防错帧心跳报文 500ms 发一次连续丢失 3 次即 1.5 秒无心跳判定该车失联调度器标记“comm_lost”。AGC运行安全性不能只靠车上的避障雷达通信活着是系统活着的前提。设计说明里我会把这一段写进“接口规范”章节让电气和软件工程师按帧对接。4.3 与WCS/ERP/MES的接口点位的命名是文档里最容易被无视的细节AGV不是孤岛它上面要接WCS仓库控制系统再往上接MES或ERP。接口怎么定最常见做法是 HTTP/RESTful 或 WebSocket 走 JSON。设计说明里要给一套点位编码规范这是最容易在实施中被忽视、后期改动最疼的地方。库位编码我推荐用“区域-排-列-层”的结构例如A-01-03-02代表 A 区域第 01 排第 03 列第 02 层。充电位用CHG-01缓存位用ST-05。任务下发的 JSON 示例{ task: MOVE, pickup: A-01-03-02, dropoff: CHG-01, priority: 1, deadline: 2025-01-01 14:30:00 }点位命名规范要写入设计说明的附件并强调两点第一点位一旦发布不许重命名只能停用后新增第二所有点位必须关联地图坐标不能只给一个名字。这两条是我被坑出来的教训——上个项目里甲方改了一次库位编码所有车辆的任务列表全部要重新映射底层硬件通讯里的坐标和上层WCS的编码不一致查了两天才发现是编码规则里有大小写混用。5. 仿真验证与常见问题排查现场翻车点集中在这五处5.1 先信仿真用离散事件仿真把系统瓶颈找出来设计说明写到这个阶段系统应该已经具备“可仿真”的能力。常见的仿真手段有商用 Plant Simulation、AnyLogic以及自写 Python 事件驱动仿真。无论用什么仿真要回答的问题是18 台AGV同时跑总任务周期能不能达到节拍要求交叉路口最大等待时间是多少充电桩的配置够不够仿真的步骤不复杂但要严格按顺序做先单机仿真验证一辆车的循环时间能不能达到设计值然后多机空载仿真看车辆之间的等待情况最后带载仿真加入装卸时间、充电时间、异常停车事件。很多项目跳过单机验证直接跑全套结果分不清瓶颈在车还是在调度。仿真参数要跟设计计算书的参数保持一致车速、加速度、装卸时间、充电曲线这些参数从厂家设备参数表里拿别拍脑袋。仿真结果输出三张曲线就够用了任务完成时间分布图、车辆利用率柱状图、路段占用热力图。路段占用热力图能让你一眼看出哪些路段是瓶颈提前改地图布局比现场改路由省钱太多。5.2 定位跳变不是玄学先查地面标识再做地图校准现场最容易翻车的一个现象AGV跑着跑着突然报定位偏差过大原地急停。排查的第一步不是调算法而是去查地面。二维码沾了油污、磁条被叉车压断、激光SLAM场景里有反光物体比如新放的铁皮货架、施工用的反光锥桶都会导致定位跳变。我处理过最快的一单客户说车经常在同一个位置报错跑过去一看那个点上方的顶灯换成了大功率LED反光板正好被直射激光导航直接懵了。定位跳变还有一个隐蔽原因地图标定误差。激光SLAM建图时如果地图里的坐标系和实际物理位置的偏差超过 2cm车辆在路过这个区域时会持续修正表现为“蛇形走位”。解决方法是原地重采地图别只是加几个特征点硬凑。二维码地图则要检查二维码贴的间距是否均匀间距差 10% 以上车速一快积分误差就会被放大。这个坑的设计文档应对策略在“维护说明”章节里明确写清——每周检查一遍地面标识脏污就换每季度做一次地图质量巡检用手持设备跑一趟看定位残差。AGV系统的稳定性一半靠设备一半靠现场环境纪律。5.3 通信延迟把车“卡”在路口心跳超时的坑多车系统在路径交叉口最容易因为通信抖动出问题。现象调度器显示两车在一个十字路口附近互相等待一直等不到超时释放。每辆车都正常但整体死锁屡次复现。原因看似是死锁检测没有触发实际呢是车和调度器之间的心跳延迟导致状态快照不一致调度器以为车已经通过了路口而实际上车还在路口等。解决第一步把通信心跳周期从 500ms 调到 200ms并且把“通信超时判死”的阈值从 1.5 秒放宽到 3 秒。为什么放宽因为通信抖动造成的误判死车比真死车还难处理——系统会把它标记为故障车然后其他车重新规划路径绕过它但这个绕过路径又可能占用它的待行区引发二次死锁。放宽阈值允许短暂掉线后的状态自动对齐反而更稳。如果调完参数还卡就检查 AP 覆盖和信道干扰。厂里的金属货架是最大的 Wi-Fi 天敌货架区的车地通信要单独加 AP不能指望角落那台企业路由。这是一个当年调试两周没解决的问题后来技术总监到现场转了一圈说“货架那一排信号动静不对”一测信号强度果然在临界值上加了天线就好了。5.4 电量计算错误导致半路趴窝AGV只剩 20% 电时应该去充电但有的项目跑着跑着车停在了过道中央SOC 归零。排查原因往往是放电模型参数太理想只算了行走消耗没算载重、转向、举升、待机空调有些车有人机交互屏能耗也不小。解决方法是给设计说明里的电量参数补一条“按最恶劣工况计算”即满载 频繁转向 长时间低速排队用这个工况去算续航余量。充电策略建议采用“机会充电”每次经过充电站如果当前电量低于 85% 就补 5 分钟而不是等电量低到 20% 再专门去充。机会充电能显著减少专门充电产生的空驶里程这个策略在连续运行的项目里是省时利器。5.5 安全避障误触发导致系统反复停摆激光避障传感器对灰尘、飘带、透明物体特别敏感仓库里常见。现象是车上报“前方障碍物”急停但去看现场什么都没有过一会儿又好了。原因是灰尘影响了传感器的反射判断或阳光从门窗直射造成的干扰。解决办法不是调低传感器灵敏度——那是拿命开玩笑——而是调整安装角度将传感器下压 5 到 10 度避开水平阳光和飘带同时在软件里设置“障碍物持续 3 秒才触发急停”过滤瞬时闪断。这个 3 秒要谨慎考虑最高车速下最短制动距离是否覆盖得住。6. 进阶强化学习调度之前先把A*基线和时间窗跑成仿真环境多AGV路径规划发展到现在用强化学习方法做调度的论文和开源项目不少热搜词里也经常看到“多AGV路径规划强化学习”。但直接上手强化学习之前有一条更实际的路先把传统方案跑成基线再谈强化学习能改善什么。怎么理解这件事强化学习调度的产物不是“一条路径”而是“一个调度策略”它学会的是在每台车提出需要通过路口申请时决定允许谁先通过、谁等待以减少整体任务完成时间。传统时间窗法用的是固定优先级或先到先得强化学习尝试用累积经验去替代这些人工规则。我建议的做法是把第 3 节的 A* 路径规划器和时间窗冲突检测做成一个 Gym 风格的环境每次调度决策定义为“在路口 A允许车辆 X 先通过还是车辆 Y 先通过”奖励函数用三项——任务总完成时间越短越好、死锁次数越少越好、车辆空驶率越低越好。然后跑一版经典强化学习算法做对比。做这个实验不是让你立刻替换生产系统核心价值有两个一是验证你的现有系统中哪些瓶颈是规则导致的、哪些瓶颈是资源不足导致的二是给实车系统一个可解释的升级说辞。在自动化物流这个领域能跑起来的强化学习调度器通常是在这个仿真环境里表现超群然后才走向产线试点。这个进阶思路最后落到一个具体验证指标上写出“强化学习调度 vs 时间窗调度”的对比表关注平均任务完成时间、最大等待时间、死锁次数三个指标。如果强化学习的收益小于 5%项目里就用时间窗法因为维护和排查难度完全不同如果收益超过 15%才值得进一步花资源去做实车验证。这是我自己做技术选型的一个工作习惯任何新算法先在没有真车风险的仿真实体上证明它值得再碰现场。希望这篇笔记能帮你把手中的AGV方案设计得更有底气也少在调试现场熬几个通宵。本文还有配套的精品资源点击获取 AGV自动化物流系统设计实战：从节拍计算到多车调度
简介这是一份源于省TI杯大学生电子设计竞赛的AGV自动化物流系统完整设计说明面向电子设计竞赛参赛者、物流自动化方向学习者及工程开发人员。文档围绕自动导向车AGV的自动装载、搬运、卸载与智能充电展开系统由多功能AGV与监控中心构成可执行预定路线、定位停车适用于汽车、家电等自动化装配及立体仓库场景。内容涵盖设计任务与总体方案中央处理器、动力转向、引导方式、障碍物检测等关键模块的选型论证装货卸货模块、黑白线信息采集、循迹控制、智能充电、声光报警等硬件电路设计以及主控流程、装卸货与充电程序的软件设计最后给出系统测试方案与结果。资源共1个doc文档包体大小889KB已有97人学习浏览适合需要快速了解AGV物流系统完整设计流程、用于课程设计或竞赛方案参考的读者。1. 一套AGV自动化物流系统设计说明先回答四个问题再动笔拿到《基于AGV的自动化物流系统设计说明.doc》这个标题别急着打开空白文档画拓扑图。产线扩容、仓储改造老板丢来一个文档名就让你出方案这类活儿我在集成商和甲方两头都干过最怕的就是把设计说明写成了产品宣传册。这份文档真正要回答的是四个问题为什么用AGV、用几台、走什么路、坏了怎么办。这四个问题对应的是需求分析、数量计算、路径规划、调度与故障恢复缺一个方案到现场就是翻车现场。这篇笔记就按这个顺序把一份能施工、能验收、能复现的AGV自动化物流系统设计讲透读者是物流规划工程师、项目经理以及刚入行做AGV集成的朋友。2. 需求与总体架构把节拍计算书写在导航选型前面2.1 从物料流量反推AGV数量先写计算书再画拓扑设计说明的第一页不应该是系统架构图而应该是节拍计算书。AGV数量错了后面所有路径规划都是白做。常见的计算方法是把每日物料流量拆成单循环时间需求量 Q托/天单次搬运循环时间 T分钟/趟单台车每趟可搬运 U 托可用工时 H小时/天综合效率 η数量 N 的公式是N (Q × T) / (60 × U × H × η)举个实际例子某电子厂总装线每天需要从立体库往产线送 1200 托物料单趟循环取货、行驶、卸货、返回实测 12 分钟一台车一趟搬 1 托两班制 16 小时效率系数取 0.85那么 N (1200 × 12) / (60 × 1 × 16 × 0.85) 17.6向上取整就是 18 台。注意这个 0.85 不是拍脑袋它包含充电等待、交通拥堵、人工干预折算我一般把这个系数拆成充电系数 0.95、交通系数 0.9、异常系数 0.9 再相乘写进设计说明里更能说服甲方。这套计算书还要留 15% 到 20% 的余量因为节拍是波动的。别听销售说“最高可达”要按「平均节拍 峰值系数」来算。峰值系数看行业电商仓储取 1.3产线配送取 1.15。把计算过程写进文档而不是只写结论这是设计说明和PPT的区别。抄作业的时候把公式里的参数换成自己现场的量测值拿秒表跟着车跑三趟取平均值别用厂家给的标称速度。2.2 AGV导航方式选型磁条、二维码、激光SLAM怎么选AGV技术栈的第一层就是导航方式选错后面全得返工。这里做一个对比表设计说明里最好也放一张同款导航方式定位精度地面改造柔性典型成本适用场景磁条导航±10mm需贴磁条低改路径要重贴低产线固定路径、环境干净的制造车间二维码导航±5mm需贴码/画码中重新标定即可中仓储、半固定路径且要求精度高的场景激光SLAM±10mm无需改造高地图重绘即可高路径频繁调整、人车混行、立体库周边选型逻辑不是“越先进越好”而是看路径改不改、精度够不够。磁条车成本低、调试快但产线工艺调整的时候重贴磁条就是一场灾难我在一个汽配厂见过产线移位 3 米十几条磁条全部重贴停产两天。如果甲方说“未来三年工艺大概率调整”直接引导他上二维码或激光SLAM别省这个钱。激光SLAM最贵但它有一个隐藏优势是另外两种给不了的不需要地面标识。在仓储场景里地面叉车、液压车来回跑磁条和二维码都会被压坏。我见过一个冷库项目凌晨零下 18 度磁条胶带直接脆裂换二维码贴纸也是半个月一换最后全换了激光车。设计说明里要把这个“地面标识存活率”写进去很多甲方根本没想到。2.3 系统架构分层调度层、车控层、设备层缺一不可AGV系统不是“车 软件”是一套分层架构设计说明里要把这三层之间的关系画清楚调度层AGV调度系统负责任务分配、路径规划、交通管理、死锁避免。这是多车系统的灵魂只有一台车的时候感受不到它的存在车一多就全看它了。车控层车载控制器负责导航计算、避障执行、速度控制、状态上报。每台车都是一个独立智能体但只对本车的运动负责。设备层执行机构与外围设备地面输送线、提升机、电梯、卷帘门、充电桩、人工呼叫终端。AGV要和这些设备握手才能完成物料交接。这一层叫法各厂不一样有的叫“上位机系统”有的叫“WCS”但职责边界是一致的。我推荐用“调度层 / 车控层 / 设备层”这个口径因为写设计说明时每一层的接口、协议、故障域是独立的——调度层挂了车应该原地停车等待车控层挂了调度层要能感知并重新派单。把这三层写清楚后面写接口规范才有据可依。3. 路径规划与多车调度从一台车的A*到多车共线不死锁3.1 栅格地图与A*算法先让一台车跑起来多车调度的地基是单机路径规划。常见做法是把场地地图栅格化每个栅格标记为可通行或障碍物然后跑A算法找最短路径。A是启发式搜索评价函数 f(n) g(n) h(n)g 是起点到当前点的实际代价h 是当前点到终点的估计代价。工程上用曼哈顿距离或欧式距离做 h 都行曼哈顿距离在栅格地图里更常用。用最小代码实现一个看得见的A*方便理解参数import heapq def astar(grid, start, goal): # grid: 二维列表0可通行1障碍 # start/goal: (row, col) open_set [] heapq.heappush(open_set, (0, start)) came_from {} g_score {start: 0} f_score {start: heuristic(start, goal)} while open_set: _, current heapq.heappop(open_set) if current goal: return reconstruct_path(came_from, current) for neighbor in get_neighbors(grid, current): tentative_g g_score[current] 1 # 每个格子代价1 if tentative_g g_score.get(neighbor, float(inf)): came_from[neighbor] current g_score[neighbor] tentative_g f_score[neighbor] tentative_g heuristic(neighbor, goal) heapq.heappush(open_set, (f_score[neighbor], neighbor)) return None # 无可行路径代码里最关键的两个参数是get_neighbors里的邻接方式四邻域还是八邻域和heuristic的选择。AGV通常不允许斜穿因为车体运动学约束是差速或舵轮斜行路径很难跟轨迹所以用四邻域。tentative_g g_score[current] 1这个 1 是每格的基础代价但真实项目里不能所有格子都一视同仁你需要给转弯、倒车、经过狭窄通道这些动作加权重否则A*会给出贴着障碍物走的路径现场看着就危险。给栅格地图做的另一个重要预处理是“障碍物膨胀”把障碍物栅格向外扩展 AGV 半径的像素量这样路径规划出来就不会擦墙。膨胀半径至少是车宽的一半除以栅格尺寸再留 100mm 安全余量。很多方案翻车就是忘了膨胀仿真里贴着墙走现场一跑就撞托盘腿。3.2 多车调度时间窗预留法是工程首选单机路径规划解决“从A到B怎么走”多车调度解决“三台车同时走会不会打架”。热搜里常提“三条AGV基本A算法”但真要管理三条车同时跑A本身不管用——它只管一条路不管道路占用。工程上最常见的可靠做法是时间窗预留法每台车申请路径时不是只申请“走哪条路”而是申请“哪条路、从什么时间到什么时候占用”。每条路段占用的时间窗计算def time_window(segment_length, speed, accel_time, intersection_reserve3.0): # 路段长度(米)、最大速度(m/s)、加减速时间(s) cruise_time segment_length / speed return { enter_time: 0.0, # 进入路段的时间点由调度器动态分配 exit_time: cruise_time 2 * accel_time intersection_reserve, segment_id: segment_id }时间窗要算的不是匀速行驶时间而是“从进入路段开始到车尾完全离开路口并留出安全距离”的时间。加减速时间在AGV里通常不小差速车 2 到 3 秒舵轮车 1 到 2 秒速度越快加速时间越长。intersection_reserve是我习惯加的路口净空时间默认 3 秒意思是前车离开路口后后车还要等 3 秒才允许进入给调度系统一个反应缓冲。调度器把每段路的占用时间写在时间窗表格里新任务来的时候按时间顺序倒查这段路有没有重叠占用有重叠就计算等待是否会导致整个任务超时如果等待小于阈值就把任务排队如果等待过长就重新规划一条绕行路径。这个策略在工业界极成熟不是因为算法漂亮而是因为它“可解释”操作员看到车停在那里能明确知道它在等哪条路段的哪个时间窗而不是面对一个黑匣子。3.3 死锁与多车共线的三个必调参数多车系统最大的坑是死锁。现象是两台车在交叉路口面对面停住谁也走不了。原因是两台车各自规划了路径互相把对方的必经之路占住了。死锁的常见处理有三个手段写设计说明时我会把这三个手段都写进去而不是只写一个一是单向循环地图。把车流行驶路线设计成顺时针或逆时针单行线从根本上消灭对向冲突。这是最土也最有效的手段但它增加行驶距离适合通道比较窄的老厂房改造。二是在线死锁检测调度器维护一个有向资源图检查是否存在环路发现环路就指定其中一台车后退让路。三是看门狗超时车在路口停留超过设定时间我一般设 30 秒长距离大车设 60 秒触发管理器介入强制重新规划或人工介入。必调参数还有两个路径规划超时时间和任务取消策略。A*在复杂地图里计算量会爆炸特别是地图尺寸超过 500×500 栅格的时候建议把单次规划超时设为 200ms超时就返回当前局部最优路径而不是干等。任务取消策略是当等待超过节拍允许时间调度器要把这个任务置为“延误”并提示人工介入千万别让系统无限排队。多车调度调试的血泪经验先加车后加路。把地图上的路径逐步加密而不是一次性把所有可达路径都放进去。路径越多A*可选空间越大但死锁概率也越高。我见过一个项目把所有库位都做了双向联通结果调度器每到高峰期就死锁还不好排查。4. 核心模块与数据流调度中心、通信协议、接口规范怎么定4.1 调度中心的功能拆解与任务状态机调度中心是这套系统的黑匣子但黑匣子不能真的“黑”它要对外暴露明确的任务状态。一个AGV任务的生命周期至少要包含这几个状态我用状态机来定义{ task_id: TASK-20250101-001, state: CREATED, state_flow: [ CREATED, // 任务已创建等待调度 DISPATCHED, // 已指派给某台车 MOVING, // 车辆正在执行路径 LOADING, // 正在对接输送线/装卸货 COMPLETED, // 已完成可释放资源 FAILED // 执行失败需人工处理 ] }状态流转规则里最重要的一条任务在 MOVING 和 LOADING 之间可以穿插“WAITING”状态即等待交通放行、等待设备握手。WAITING 不能无限挂起必须带一个 waiting_reason 字段写清楚在等什么。调度界面上的任务卡住时操作员看到 waiting_reason 是“waiting_for_time_window: segment_12_13”就能立刻定位是哪条路段堵了而不是面对一个“处理中”的假状态。我在这个状态机上吃过亏早期设计没加 waiting_reason现场堵车只能通过抓包去查后来全部补上故障定位时间从半小时降到两分钟。4.2 车-地通信协议先定报文帧格式再谈选型AGV调度系统和车载控制器之间的通信到底走什么协议Wi-Fi 是企业项目里最常见的选项但不是唯一解。先看实时性要求位置上报周期一般 100ms 到 500ms调度指令下发的端到端延迟要求小于 200ms。Wi-Fi 漫游会丢包这在AGV场景里很致命车在行进中丢失调度指令可能直接越过了安全边界。我一般这样定产线内固定路线且范围小5000平米内用 Wi-Fi 5 以上频段加厂内独立AP足够大面积仓储、有金属货架遮挡的地方使用私有射频或工业级 Mesh。通信协议用 TCP 长连接不要用 MQTT为什么虽说 MQTT 是现在物联网的名词但AGV领域讲究的是报文可追踪、帧格式固定更适合用底层的长度校验的自定义协议来保证实时性和可调试性。一份可落地的报文帧格式如下序号字段长度说明1帧头2B固定 0xAA 0x55用于同步2消息类型1B0x01 任务下发、0x02 状态上报、0x03 心跳3数据长度2B小端模式标明数据域字节数4数据域N B业务数据如坐标、速度、任务号5CRC162B数据域循环冗余校验防错帧心跳报文 500ms 发一次连续丢失 3 次即 1.5 秒无心跳判定该车失联调度器标记“comm_lost”。AGC运行安全性不能只靠车上的避障雷达通信活着是系统活着的前提。设计说明里我会把这一段写进“接口规范”章节让电气和软件工程师按帧对接。4.3 与WCS/ERP/MES的接口点位的命名是文档里最容易被无视的细节AGV不是孤岛它上面要接WCS仓库控制系统再往上接MES或ERP。接口怎么定最常见做法是 HTTP/RESTful 或 WebSocket 走 JSON。设计说明里要给一套点位编码规范这是最容易在实施中被忽视、后期改动最疼的地方。库位编码我推荐用“区域-排-列-层”的结构例如A-01-03-02代表 A 区域第 01 排第 03 列第 02 层。充电位用CHG-01缓存位用ST-05。任务下发的 JSON 示例{ task: MOVE, pickup: A-01-03-02, dropoff: CHG-01, priority: 1, deadline: 2025-01-01 14:30:00 }点位命名规范要写入设计说明的附件并强调两点第一点位一旦发布不许重命名只能停用后新增第二所有点位必须关联地图坐标不能只给一个名字。这两条是我被坑出来的教训——上个项目里甲方改了一次库位编码所有车辆的任务列表全部要重新映射底层硬件通讯里的坐标和上层WCS的编码不一致查了两天才发现是编码规则里有大小写混用。5. 仿真验证与常见问题排查现场翻车点集中在这五处5.1 先信仿真用离散事件仿真把系统瓶颈找出来设计说明写到这个阶段系统应该已经具备“可仿真”的能力。常见的仿真手段有商用 Plant Simulation、AnyLogic以及自写 Python 事件驱动仿真。无论用什么仿真要回答的问题是18 台AGV同时跑总任务周期能不能达到节拍要求交叉路口最大等待时间是多少充电桩的配置够不够仿真的步骤不复杂但要严格按顺序做先单机仿真验证一辆车的循环时间能不能达到设计值然后多机空载仿真看车辆之间的等待情况最后带载仿真加入装卸时间、充电时间、异常停车事件。很多项目跳过单机验证直接跑全套结果分不清瓶颈在车还是在调度。仿真参数要跟设计计算书的参数保持一致车速、加速度、装卸时间、充电曲线这些参数从厂家设备参数表里拿别拍脑袋。仿真结果输出三张曲线就够用了任务完成时间分布图、车辆利用率柱状图、路段占用热力图。路段占用热力图能让你一眼看出哪些路段是瓶颈提前改地图布局比现场改路由省钱太多。5.2 定位跳变不是玄学先查地面标识再做地图校准现场最容易翻车的一个现象AGV跑着跑着突然报定位偏差过大原地急停。排查的第一步不是调算法而是去查地面。二维码沾了油污、磁条被叉车压断、激光SLAM场景里有反光物体比如新放的铁皮货架、施工用的反光锥桶都会导致定位跳变。我处理过最快的一单客户说车经常在同一个位置报错跑过去一看那个点上方的顶灯换成了大功率LED反光板正好被直射激光导航直接懵了。定位跳变还有一个隐蔽原因地图标定误差。激光SLAM建图时如果地图里的坐标系和实际物理位置的偏差超过 2cm车辆在路过这个区域时会持续修正表现为“蛇形走位”。解决方法是原地重采地图别只是加几个特征点硬凑。二维码地图则要检查二维码贴的间距是否均匀间距差 10% 以上车速一快积分误差就会被放大。这个坑的设计文档应对策略在“维护说明”章节里明确写清——每周检查一遍地面标识脏污就换每季度做一次地图质量巡检用手持设备跑一趟看定位残差。AGV系统的稳定性一半靠设备一半靠现场环境纪律。5.3 通信延迟把车“卡”在路口心跳超时的坑多车系统在路径交叉口最容易因为通信抖动出问题。现象调度器显示两车在一个十字路口附近互相等待一直等不到超时释放。每辆车都正常但整体死锁屡次复现。原因看似是死锁检测没有触发实际呢是车和调度器之间的心跳延迟导致状态快照不一致调度器以为车已经通过了路口而实际上车还在路口等。解决第一步把通信心跳周期从 500ms 调到 200ms并且把“通信超时判死”的阈值从 1.5 秒放宽到 3 秒。为什么放宽因为通信抖动造成的误判死车比真死车还难处理——系统会把它标记为故障车然后其他车重新规划路径绕过它但这个绕过路径又可能占用它的待行区引发二次死锁。放宽阈值允许短暂掉线后的状态自动对齐反而更稳。如果调完参数还卡就检查 AP 覆盖和信道干扰。厂里的金属货架是最大的 Wi-Fi 天敌货架区的车地通信要单独加 AP不能指望角落那台企业路由。这是一个当年调试两周没解决的问题后来技术总监到现场转了一圈说“货架那一排信号动静不对”一测信号强度果然在临界值上加了天线就好了。5.4 电量计算错误导致半路趴窝AGV只剩 20% 电时应该去充电但有的项目跑着跑着车停在了过道中央SOC 归零。排查原因往往是放电模型参数太理想只算了行走消耗没算载重、转向、举升、待机空调有些车有人机交互屏能耗也不小。解决方法是给设计说明里的电量参数补一条“按最恶劣工况计算”即满载 频繁转向 长时间低速排队用这个工况去算续航余量。充电策略建议采用“机会充电”每次经过充电站如果当前电量低于 85% 就补 5 分钟而不是等电量低到 20% 再专门去充。机会充电能显著减少专门充电产生的空驶里程这个策略在连续运行的项目里是省时利器。5.5 安全避障误触发导致系统反复停摆激光避障传感器对灰尘、飘带、透明物体特别敏感仓库里常见。现象是车上报“前方障碍物”急停但去看现场什么都没有过一会儿又好了。原因是灰尘影响了传感器的反射判断或阳光从门窗直射造成的干扰。解决办法不是调低传感器灵敏度——那是拿命开玩笑——而是调整安装角度将传感器下压 5 到 10 度避开水平阳光和飘带同时在软件里设置“障碍物持续 3 秒才触发急停”过滤瞬时闪断。这个 3 秒要谨慎考虑最高车速下最短制动距离是否覆盖得住。6. 进阶强化学习调度之前先把A*基线和时间窗跑成仿真环境多AGV路径规划发展到现在用强化学习方法做调度的论文和开源项目不少热搜词里也经常看到“多AGV路径规划强化学习”。但直接上手强化学习之前有一条更实际的路先把传统方案跑成基线再谈强化学习能改善什么。怎么理解这件事强化学习调度的产物不是“一条路径”而是“一个调度策略”它学会的是在每台车提出需要通过路口申请时决定允许谁先通过、谁等待以减少整体任务完成时间。传统时间窗法用的是固定优先级或先到先得强化学习尝试用累积经验去替代这些人工规则。我建议的做法是把第 3 节的 A* 路径规划器和时间窗冲突检测做成一个 Gym 风格的环境每次调度决策定义为“在路口 A允许车辆 X 先通过还是车辆 Y 先通过”奖励函数用三项——任务总完成时间越短越好、死锁次数越少越好、车辆空驶率越低越好。然后跑一版经典强化学习算法做对比。做这个实验不是让你立刻替换生产系统核心价值有两个一是验证你的现有系统中哪些瓶颈是规则导致的、哪些瓶颈是资源不足导致的二是给实车系统一个可解释的升级说辞。在自动化物流这个领域能跑起来的强化学习调度器通常是在这个仿真环境里表现超群然后才走向产线试点。这个进阶思路最后落到一个具体验证指标上写出“强化学习调度 vs 时间窗调度”的对比表关注平均任务完成时间、最大等待时间、死锁次数三个指标。如果强化学习的收益小于 5%项目里就用时间窗法因为维护和排查难度完全不同如果收益超过 15%才值得进一步花资源去做实车验证。这是我自己做技术选型的一个工作习惯任何新算法先在没有真车风险的仿真实体上证明它值得再碰现场。希望这篇笔记能帮你把手中的AGV方案设计得更有底气也少在调试现场熬几个通宵。本文还有配套的精品资源点击获取