简介资源为自动导引车AGV的完整三维模型工程包面向机械设计、自动化与物流工程方向的在校生及研发人员可用于理解AGV整体结构、零部件装配关系与机电一体化设计思路。压缩包内共75个文件以SolidWorks零件sldprt与装配体sldasm为主同时包含Parasolidpar、STEP通用格式stp及少量渲染图片与日志配置兼顾不同软件版本的兼容性与跨平台查看需求压缩包大小约29.73MB结构紧凑便于下载。目前已有一百六十人次浏览学习。模型覆盖了AGV的底盘、驱动轮组、导航传感器支架、顶升机构等关键模块并附有装配体约束关系与部分零件的工程配置信息可直接在SolidWorks中打开查阅各部件尺寸与装配逻辑。对于正在开展AGV相关课程设计、毕业设计或企业项目选型评估的读者这份模型能够提供直观的结构参考和元件拆解的切入点有助于快速建立对自动导引车机械系统的整体认知。1. 自动导引车AGV不是“会跑的平板车”先想清楚它解决什么问题再进场一说自动导引车AGV很多人脑子里先冒出来的是一台驮着货架在仓库里走的“机器人”。但如果你真把它当成会跑的平板车来规划项目十有八九会在上线后翻车——因为AGV的本质不是“移动”而是“在复杂现场里稳定地完成移动搬运闭环”。它同时要解决三个问题知道自己在哪里、知道该往哪里去、知道怎么在不撞车不堵路的前提下准时到达。这套闭环涉及底盘运动学、定位感知、路径规划、调度协同和现场网络任何一个环节掉链子车都会停在过道里当路障。这篇内容适合两类人一是工厂或仓储的产线规划、设备工程师正在评估要不要上AGV、怎么选型二是刚接手AGV项目、需要把调度和路径算法落到真车上的软件工程师。我会按从选型到落地再到排障的顺序把一条能走的通的路讲清楚。2. AGV选型与导航方式磁条、二维码、激光SLAM各自解决哪类现场2.1 三种主流导航方式的原理与适用边界磁条导航是最老牌的做法。地面贴磁条车底装磁传感器沿着磁条走遇到路口靠磁条编码或RFID标签决定拐弯。成本最低、实施最快但柔性也最差改路线必须重新贴磁条地面有金属碎屑或铁屑时容易干扰磁信号而且磁条磨损后车会跑偏。它适合路线非常固定、短期不改动、环境相对干净的产线。二维码导航是当前中大型项目的主流。地面按固定间距贴二维码地标车底朝下的相机读码既能获得绝对坐标又能通过二维码在视野中的偏移量做姿态修正。精度能做到±10mm级别路线调整只需要重新贴码或者更新地标坐标表柔性比磁条高一个量级。代价是地面维护要求高码脏了、破了、被叉车碾掉了车就会在下一段路程里“盲跑”。激光SLAM导航是这几年最热的方向。车顶或车体装激光雷达扫描环境特征建图运行时实时匹配当前位置。最突出的优点是柔性极高不改造场地、不贴任何标记路线改变只需在软件里重新规划。缺点是成本高、对场景动态变化敏感——环境里堆料变了、新放了一排货架、甚至下过雨后地面反射变化都可能导致定位漂移。落地时通常要配反光板或自然特征参照物做二次约束。2.2 按场景选型对号入座的判断框架我一般会先问用户三个问题路线多久改一次、对接精度要求多少、场地能不能停线改造。如果路线三年不改、精度要求不高±20mm够用、预算敏感磁条仍然是性价比之王。很多传统汽车零部件的产线一台磁条AGV用了七八年都没换过路线。如果节拍要求高、需要和自动化设备对接比如自动门、升降机、机台上下料优先考虑二维码。因为二维码导航的定位误差是可以预测且恒定的不像激光SLAM那样受环境变化影响对接机构的设计余量可以压得很小。如果场地是高位货架区、路线需要随业务波峰波谷动态调整或者后续要上多机协同柔性调度就别省激光SLAM的钱。需要提醒的是激光SLAM是“看着像没问题但一上线就出问题”的重灾区没有SLAM经验团队的情况下建议先找有成熟现场的供应商做交钥匙而不是自己从零调。2.3 选型必问的9个现场参数无论选哪种导航下表这些参数必须在技术协议里写死否则后面扯皮的地方全在这里参数项为什么必须问典型坑通道宽度决定车体尺寸和转弯半径窄通道配大车转弯直接卡死地面平整度影响定位稳定性和载具晃动地面有坡二维码相机离地高度波动读码失败率飙升对接精度决定导航方式和机械引导机构的投入标称±10mm实际对接时要±5mm差了就是硬顶充电时间窗决定电池选型和充电策略只有夜班能充电池容量不够就整个系统瘫痪节拍要求决定车速和调度并发数客户说“随便跑”上线后要求每90秒一趟调度系统直接死锁货物形态决定载具设计和重心控制液体、悬挂重物、偏心负载都会影响加减速参数环境温度影响电池、传感器和地标寿命冷库里普通二维码标签会脆裂脱落网络覆盖决定调度通信稳定性仓库死角WIFI信号差急停指令丢了车还在往前跑售后响应半径决定你选哪家供应商外地供应商调试周期拖到三个月不是新闻选型阶段还有一个常见误区只看车的载重和速度不看“到位停止精度”。AGV的到位精度由导航方式、控制算法、机械刚性共同决定同样是二维码导航不同厂商做的到位重复精度可能差一倍。所以合同里必须约定“满载、全速运行到指定工位后的停止重复精度”而且要写明验收方法连续跑50次量坐标分布。3. 搭建一台可验证AGV的最小系统从底盘到上位机的完整链路3.1 底盘与驱动差速模型下的运动学解算最常见的AGV底盘构型是差速驱动——两个主动轮分别由独立电机驱动通过两侧轮速差实现转弯。好处是结构简单、成本低、转弯半径可以做到零原地转坏处是负载能力不如舵轮重载场景容易打滑。运动学解算是AGV控制的地基。车在平面上的状态可以用三个量描述x坐标、y坐标、航向角θ。给定左右轮速vL和vR车体的线速度和角速度为import math def differential_motion(v_l, v_r, wheel_base, dt): 差速运动学解算 v_l: 左轮线速度 (m/s) v_r: 右轮线速度 (m/s) wheel_base: 左右轮距 (m) dt: 控制周期 (s) 返回: (dx, dy, dtheta) 车体坐标系下的位姿增量 v (v_l v_r) / 2.0 omega (v_r - v_l) / wheel_base dtheta omega * dt dx v * math.cos(dtheta) * dt dy v * math.sin(dtheta) * dt return dx, dy, dtheta这个函数的逻辑很直接先算平均速度得到线速度用轮速差除以轮距得到角速度然后按控制周期积分出位移和转角。注意这里用的是车体坐标系增量要让车在世界坐标系里跑还需要做一次坐标变换把dx和dy旋转到世界坐标系的方向。实际工程里控制周期dt的选择很关键。常见做法是10-20ms一个控制周期太慢车走起来一顿一顿的太快对主控性能要求高且轮速反馈来不及更新。轮距wheel_base不要直接填设计值要实测——因为轮胎的负载半径和理论半径有偏差设计值算出来的转弯半径会和实际差不少。3.2 定位模块二维码导航的落地配置二维码导航的最小配置是车底装一台工业相机地面按一定间距贴码。相机的安装高度、角度、码间距这三个参数互相制约是最容易踩坑的地方。常见做法是相机垂直朝下离地高度150-200mm二维码边长30-50mm码间距500-1000mm。码间距取决于是直线行驶还是密集转弯区——直道上可以隔1米一个码弯道和对接区必须加密到300mm以内否则车在两次读码之间纯靠惯性推算姿态漂了都不知道。读码后的数据落地逻辑如下def update_pose_from_qr(qr_data, expected_map, current_pose, threshold0.02): 二维码定位修正 qr_data: 二维码识别结果包含码ID和在图像中的偏移量(px) expected_map: 码ID - (绝对x, 绝对y, 绝对航向角) 的映射表 current_pose: 当前推算位姿 (x, y, theta) threshold: 码图中心与相机中心的允许偏差 (m)用于异常检测 返回: 修正后的位姿 if qr_data is None: return current_pose # 没读到码继续靠轮速推算 map_pose expected_map[qr_data.code_id] # 图像偏移量转实际偏移需要标定像素/毫米比例 offset_x qr_data.offset_x * qr_data.px_to_mm_ratio offset_y qr_data.offset_y * qr_data.px_to_mm_ratio # 相机安装位置到车体中心的偏移补偿 corrected_x map_pose.x offset_x CAMERA_OFFSET_X corrected_y map_pose.y offset_y CAMERA_OFFSET_Y # 防跳变如果修正量和推算量差距过大说明读码错了丢弃 diff math.hypot(corrected_x - current_pose.x, corrected_y - current_pose.y) if diff threshold: return current_pose theta map_pose.theta qr_data.yaw_offset return (corrected_x, corrected_y, theta)这个逻辑里有三个容易被忽略的细节。一个是px_to_mm_ratio不是固定值相机安装高度哪怕偏了1mm这个比例都会变。我一般会在调试现场用一张标准长度纸片放在码旁边实测。另一个是CAMERA_OFFSET_X/Y相机装的位置和车体中心不重合修正时必须把这个偏移算进去否则车每次过码都停偏。第三个是异常检测的threshold——它是我强烈建议加的逻辑因为地面脏污导致读码读错是真实存在的不加这个判断车会突然“跳”到错误位置。定位模块调试时最终要看的是重放日志里的位姿修正量每过一个码修正量应该在±10mm以内。如果修正量持续单向偏大说明轮径标定或码地图坐标有系统误差不要用加大threshold来掩盖。3.3 控制闭环用PID把“能走”变成“走得稳”运动学和定位只是给了控制器“输入”真正让车走得直、停得准的是控制闭环。最常用的套路是两层PID串联外层是位置环输入是目标点和当前位姿的偏差输出是目标线速度和角速度内层是速度环输入是期望轮速和实际轮速的偏差输出是电机PWM占空比。外部位置环 (10Hz) 内部速度环 (100Hz) 目标位姿 -- 位置偏差 -- PID -- 期望轮速 -- 轮速偏差 -- PID -- PWM -- 电机 ^ | ---------- 轮速反馈 ------ 编码器测量 -----------------------位置环PID参数整定有一套我都踩过坑的经验直接说结论class PIDController: 位置环PID控制AGV直线跟踪 p_gain: 比例增益决定响应速度先给0.5 i_gain: 积分增益消除稳态误差先给0.05 d_gain: 微分增益抑制超调先给0.2 integral_limit: 积分限幅防止积分饱和 output_limit: 输出限幅防止命令过大导致电机堵转 def __init__(self, p_gain0.5, i_gain0.05, d_gain0.2, integral_limit0.3, output_limit1.0): self.p p_gain self.i i_gain self.d d_gain self.integral 0.0 self.last_error 0.0 self.integral_limit integral_limit self.output_limit output_limit def update(self, error, dt): self.integral error * dt self.integral max(-self.integral_limit, min(self.integral_limit, self.integral)) derivative (error - self.last_error) / dt if dt 0 else 0.0 output self.p * error self.i * self.integral self.d * derivative output max(-self.output_limit, min(self.output_limit, output)) self.last_error error return output整定的顺序有讲究先只留P把车调到能走但稍微有偏差的程度再加D抑制回摆最后加I消静态误差。如果P给太大车会在目标点附近来回冲撞幅度越调越小听起来像快速“嗒嗒嗒”这时候要降P或者加大D。I不能给大否则车过弯道时会因为累计积分过多而冲过头。AGV控制里PID参数的现场调整本质上是玄学——同一台车空载和满载的PID参数几乎肯定不一样因为重心位置和惯性变了。靠谱的做法是存储多套参数按任务类型切换而不是试图找一套万能参数。4. 调度系统与AGV协同多车运行的核心逻辑与实现4.1 调度系统的三层架构单台AGV跑起来只是开始产线上真正难的是多台车不打架、不互堵、不罢工。AGV调度系统一般拆成三层来设计。任务管理层负责接收业务指令——比如MES或WMS下发“把A工位的料送到B工位”——然后把任务拆成“取货”“运输”“放货”等子任务并维护任务的优先级和超时状态。调度决策层是核心它做三件事把任务分配给合适的车、为每辆车规划路径、实时处理路权冲突。这一层的算法质量直接决定系统的吞吐量也是最容易出“死锁”的地方。执行控制层在每台车上接收调度指令执行点到点运动控制并把车的实时状态位置、速度、任务执行状态、故障码上报给调度决策层。4.2 路径规划A*算法在地图上的落地实现调度系统最常见的路径规划算法是A*。它在地图上把可行区域离散成网格图节点间有权重搜索从起点到终点代价最小的路径。AGV场景下网格尺寸一般取车体宽度的1.5-2倍太小路径看着“精细”但转角太密车走起来反而慢太大地图分辨率不够窄通道会被抹掉。给出一个可直接改参数的实现import heapq def astar(grid, start, goal, allow_diagonalTrue): grid: 2D数组0可通行1障碍 start: 起点 (row, col) goal: 终点 (row, col) allow_diagonal: 允许斜向移动 返回: 路径点列表[(row, col), ...] 或 None rows, cols len(grid), len(grid[0]) open_heap [] heapq.heappush(open_heap, (0, start)) came_from {start: None} g_score {start: 0} f_score {start: heuristic(start, goal)} DIRS [(0, 1), (0, -1), (1, 0), (-1, 0)] if allow_diagonal: DIRS [(1, 1), (1, -1), (-1, 1), (-1, -1)] while open_heap: _, current heapq.heappop(open_heap) if current goal: return reconstruct_path(came_from, current) for dr, dc in DIRS: nr, nc current[0] dr, current[1] dc if not (0 nr rows and 0 nc cols): continue if grid[nr][nc] 1: continue # 斜穿墙角的检查很重要否则路径会斜着擦过障碍角 if (dr ! 0 and dc ! 0) and (grid[current[0] dr][current[1]] 1 or grid[current[0]][current[1] dc] 1): continue step_cost 1.0 if dr 0 or dc 0 else 1.414 tentative_g g_score[current] step_cost if tentative_g g_score.get((nr, nc), float(inf)): came_from[(nr, nc)] current g_score[(nr, nc)] tentative_g f tentative_g heuristic((nr, nc), goal) heapq.heappush(open_heap, (f, (nr, nc))) return None # 路径不可达A*的核心有三点。一是启发函数设计AGV场景里普遍用曼哈顿距离或欧几里得距离优先用曼哈顿因为AGV的可行走方向大多是横平竖直的。二是斜穿墙角检查没有这个检查路径会贴着障碍物斜切过去真车走的时候要么撞墙要么为了避让停下来重新规划。三是代价函数不要只用距离可以把“转弯”的代价也叠加进去——一条少转弯但路程略长的路径实际运行时间往往比纯最短路径更短。4.3 交通管理路口占用与死锁避免路径规划出来只是理论轨迹多车运行时每辆车都走自己的“最短路径”就一定会出现两辆车同时要通过同一个路口的情况。这时候必须引入路段占用管理。最常用的机制是“锁段行驶”。把整张地图切分成互不重叠的路段每辆车出发前先向调度系统申请整条路径上所有路段的锁只有锁申请成功车才允许进入车离开一段路就释放对应的锁。这样可以保证任何路段同一时刻最多只有一辆车。class SegmentLockManager: 路段锁管理分配和释放路段的独占权 def __init__(self): self._locks {} # segment_id - vehicle_id def try_acquire(self, vehicle_id, segment_ids): 尝试为车辆一次申请多个路段锁 全部成功才分配防止部分申请造成死锁 # 检查所有路段是否空闲 for seg_id in segment_ids: if seg_id in self._locks and self._locks[seg_id] ! vehicle_id: return False # 全部空闲分配 for seg_id in segment_ids: self._locks[seg_id] vehicle_id return True def release(self, vehicle_id, segment_ids): for seg_id in segment_ids: if self._locks.get(seg_id) vehicle_id: del self._locks[seg_id]这个简单的“先检查后分配”实现里藏着一个大坑如果两辆车都先申请到了自己路径的前半段锁然后都在等对方释放后半段就死锁了。规避死锁的常见做法有三个一是“一次性申请全部路段锁”上面的代码已经体现申请不到就全放弃等待二是按固定优先级分配路权比如直行车优先于转弯车三是加超时回退机制某辆车等待超过设定时间自动停到最近的避让区让出通道。实际项目里还有一个容易忽略的参数预锁距离。我一般会设置为车前方2-3个路段太短车到了路口才临时抢锁车速降下来影响节拍太长锁占着不放全局并发度急剧下降。这个参数要靠仿真调现场改会很难受。4.4 任务编排从“单机执行”到“多车协同”有了路权管理多台车才能在一起干活。AGV协同的编排逻辑通常基于业务流程不是简单的“哪个车空就给哪个车派任务”。一张典型的任务分配伪逻辑是这样def assign_task(tasks, idle_vehicles, vehicle_position, task_position): 贪心最近距离分配简单但实用 更优做法是考虑任务截止时间和车辆剩余电量 best_vehicle None best_distance float(inf) for v in idle_vehicles: distance manhattan_distance(vehicle_position[v.id], task_position) if v.battery 20: continue # 电量不足的车辆不分配新任务引导充电 if distance best_distance: best_distance distance best_vehicle v return best_vehicle这个简单分配背后的原则是把任务给到“综合代价最小”的车而不仅仅是“距离最近”的车。考虑因素还包括剩余电量、当前任务所属区域、是否正在去充电的路上。有些团队用匈牙利算法做全局最优分配任务量大时效果更稳但绝大多数中小项目按距离优先电量阈值就够用了。协同里还有一个常见需求是车辆避让——两车在窄通道面对面了。如果地图上规划了单行道A*规划时直接把反向路段设为障碍物理上就杜绝了对顶。如果双车道那就完全依赖锁机制。我见过最稳妥的做法是把通道预设为单行配合区域禁入规则比如某区域内同时最多允许进入一辆车。这样牺牲一点柔性但现场“堵死”的概率大幅下降。AGV协同的系统联调一定要从两辆车、一条简单路径、三个工位开始跑。直接在十台车的现场搞联调出了问题连日志都难对齐——因为每台车的时钟基准都可能不一样。5. AGV落地避坑现场调试最常见的6个问题与排查5.1 车轮打滑导致定位漂移现象车在没有读码的直道上走的路线越来越歪过了几个码之后突然猛打方向“修正”。原因AGV执行直角转弯时差速驱动的车轮和地面存在滑动摩擦。如果地面有油污、水渍或者轮胎磨损了实际转过的角度比理论小航向角积分误差累积到下一个码时发现偏了一大截于是出现“猛打方向”的修正动作。解决排查顺序是先看地面有没有油污再看轮胎胎纹深度最后才调运动学参数。地面油污问题无解只能加装地面清洁策略轮胎磨损只能换件。真正能现场调整的是转弯速度——转弯时把角速度上限从默认值降一半打滑概率会显著下降。另外在转弯段前后加密二维码让定位修正兜底比任何算法优化都管用。5.2 地图被改路径全乱现象路线明明没变但某天开始所有车都在同一个路口绕圈调度系统报“路径不可达”。原因现场环境变了——货架挪了、堆了料、地面贴了新标识线。激光SLAM导航的车最怕这个因为参考地图和实时扫描的特征对不上二维码导航的车也可能因为有人把码揭了重贴到别的位置。解决没有银弹。激光SLAM可以先看粒子滤波的置信度是否持续偏低确定是环境变化就重扫地图或增加约束标识二维码地图要建立现场巡检制度每周检查一次码的完整性和位置偏移。更实用的手段是调度系统里把地图版本号纳入路径规划校验地图变了但车端地图没更新时禁止发车。在3D打印物流项目里这个问题几乎每周都出现后来我强制要求地图更新必须走版本审批流程才算安静下来。5.3 多车死锁现象两辆车在交叉路口互相对着谁都不让谁后边的车越堵越多调度系统界面上一片“等待中”。原因最常见的是“部分锁”导致的循环等待——A车占着路段1等路段2B车占着路段2等路段1。如果锁是一次性申请且不可抢占的理论上不会死锁但很多团队做了优化允许分段锁问题就来了。解决第一步看调度日志里所有车的锁申请序第二步确认是循环等待还是单点故障。循环等待就按前面说的整体申请超时回退解决给每辆车设置“等待超时”超过5秒自动撤回到最近的避让点让出锁资源。另外路口区域的路段粒度要细化把一个大交叉路口拆成4-6个独立路段让车可以更细粒度地通过死锁概率会显著降低。5.4 充电策略没设计好现象运行到下午四五点多台车同时低电量报警同时开向充电区充电区排队产线无车可用节拍直接崩了。原因所有车都在同一时段从相似的工作循环中消耗电量低电量提醒阈值设得又一样导致“集体回充”。解决充电调度要和任务调度打通。我采用的办法是每台车设置不同的低电量阈值比如1号车30%触发2号车25%触发3号车28%错峰回充。同时充电策略要支持“预约充电”而非“强制回充”——电量低于调度设定值时车会完成当前任务再回充而不是立刻抛下任务跑了。电池寿命的角度还有一个小技巧不要让电池每次都从低电量充满浅充浅放会延长锂电池寿命把充电SoC限制在20%-90%区间。5.5 网络延迟导致急停失败现象按下调度系统的急停按钮最远端的车隔了两秒才停差点撞上人。原因调度急停指令走了云端或WIFI链路WIFI覆盖在仓库深处信号弱TCP重传导致延迟不可控。解决把这个局面按“两条急停链路”拆。调度系统急停只做“软停”真正的人身安全急停必须走车端独立硬急停——车体上安物理急停按钮、红外防撞传感器、激光安全扫描仪这几个信号直接接在运动控制器上不经过网络触发立即切断电机使能。同时把调度急停的通信协议改成UDP多发几遍允许丢包但降低延迟。网络层面AGV运行区域的WIFI覆盖要做到信号强度不能低于-65dBm用商用路由器覆盖仓库必然会踩坑需要上企业级AP加漫游调优。5.6 对接精度不达标现象AGV到机台前停下准备对接但货叉和机台导向槽差了几毫米对接机构卡住报警。原因以为二维码导航绝对定位精度够了没考虑机械间隙、载货后车架变形、机台本身安装误差的叠加。二维码给的坐标是相机在码上方时的坐标对接机构在车头车越长姿态误差放大越明显。解决对接工位前加复定位机构常见做法是地面上装锥形导向销车体下装V型槽AGV粗定位到附近后用机械导向完成最后几毫米的精定位。这是最稳的方案比单纯提高导航精度便宜得多也可靠得多。如果不想加机械机构就在对接工位多贴几个加密码形成“码组”软件里用多个码的坐标拟合出更精确的位姿。6. 验证AGV系统好不好用的三个进阶手段6.1 用仿真先跑通再上真车很多团队跳过仿真直接上真车结果是把真车当调试平台撞一次修一次。AGV调度系统的核心算法——A*路径、锁管理、任务分配、死锁避免——全部可以脱离硬件先仿真验证。我在进场调试前都会要求先在仿真环境里用真实的地图尺寸、真实的通道宽度、真实的任务序列跑满8小时统计死锁次数和平均任务完成时间。仿真时有一个关键点不要用理想地图跑。把通道宽度缩窄10%在随机位置扔模拟障碍物故意让两车同时申请交叉路段这些异常注入比正常流程更能暴露调度算法的薄弱点。仿真里跑不出死锁的调度系统现实里大概率也不会出大问题但仿真里跑出死锁现场只会更难调。6.2 故障注入测试系统验收前做故障注入测试是成本最低的排雷手段。做法是故意制造异常环境观察系统行为是否符合预期。具体几类场景断掉某台车的WIFI连接看调度系统是否能在规定时间内确认车离线并重新分配任务在车前方放一个障碍物看它停车后是否能在障碍移除后自动恢复故意让一台车低电量看调度逻辑是否把它排除出新任务还有断电恢复——车跑到一半主控断电重新上电后能不能回到正确位置。我建议把故障注入测试做成标准验收项而不是可选做。因为客户现场出问题几乎都是这些故障场景的组合早测早发现晚测就是停机损失。6.3 记录并复盘运控日志最后一件事也是我在多个项目里最受益的一招让每台AGV全程记录结构化日志包括时间戳、指令目标、实时位姿、轮速、PID输出、定位修正量、路段锁申请结果和异常事件。日志格式要统一车端和调度端共用同一条时间线否则联调排障时对不上。每次现场出问题我都会先让现场人员提供问题发生前后5分钟的日志而不是拍视频发群里。从日志里看数据比看监控画面更接近真相——画面只能看到现象日志能查到原因。有次半夜调试AGV反复在一个弯道停住不走了画面看以为是避让障碍物日志一看是预锁申请超时回退逻辑和避障逻辑冲突了两分钟定位完问题。这种排障效率靠看视频是不可能达到的。这套“仿真先行、故障注入、日志复盘”的习惯我一直在所有AGV项目里坚持。AGV系统最隐蔽的坑从来不在单机运动控制里而在多车协同时的不可预期交互——所以验证思路必须围绕“逼它出错、记录错、分析错”展开。希望这些经验能帮你在AGV落地路上少踩几个我踩过的坑。本文还有配套的精品资源点击获取