ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

AGV智能搬运系统在白车身调整线的应用与调度优化

AGV智能搬运系统在白车身调整线的应用与调度优化 简介这是一篇出自《装备制造技术》2016年第12期的汽车智能制造技术文献聚焦AGV智能搬运系统在白车身调整线中的应用面向汽车焊装工艺、智能物流及移动机器人选型相关的工程师与研究人员旨在解决调整线柔性化升级中的搬运方案设计问题。文中系统对比了平板式、货叉型、牵引式、带举升装置等AGV类型的功能差异并梳理磁性引导、视觉导引、激光定位等行走方式的适用特点结合上汽通用五菱实际案例说明其在缩短生产周期、降低成本方面的成效还涉及动力、控制、安全等基本配置。压缩包共1个PDF文件大小约2.35MB图文排版工整内容涵盖AGV选型逻辑、行走方式对比及白车身调整线应用要点适合作为智能系统、系统开发方向的参考文献和专业指导资料。目前已有83人学习适合需要快速建立AGV技术认知、开展白车身调整线智能化改造方案论证的读者。1. AGV智能搬运系统在白车身调整线柔性搬运不是省人是救换型汽车焊装车间的白车身调整线是整车尺寸精度的最后关口。过去这条线大多用地拖链加滑橇节拍稳定但换型痛苦每上一个新车型轨道、限位、二次焊接工位全要动。AGV智能搬运系统在白车身调整线的应用不是把人工搬运换成机器搬运那么简单——它的价值在于把“固定节拍的流水线”变成“可编排的柔性搬运”。国内新焊装车间已经把调整线AGV当作标配老线技改也在往这个方向走一条2万平米的焊装车间调整线一般就是5到8台AGV在跑。这篇文章会从工艺痛点出发讲到调度系统、A*路径规划、三车协同再落到底层信号对接和调试避坑。适合正在做焊装输送线集成、工厂数字化改造的工程师也适合刚接手AGV项目的设备负责人照着做前期的技术方案评审。2. 白车身调整线为什么需要AGV节拍、混线与线边空间的真实约束2.1 调整线工艺内容与地拖链的固有缺陷白车身调整线主要干三件事翼子板与前门、后门的间隙面差调整整车外观表面质量的检查和返修以及部分二次焊接补焊。车身在这里要经历多次“顶升—定位—人工/机器人作业—放行”的循环。传统的地拖链加滑橇方案车身始终在一个固定的输送路径上工位间距、停止精度、举升机构全部由机械硬连接决定。地拖链最大的问题有两个。第一是混线能力弱不同车型的白车身重心位置、裙边结构不一样滑橇和支撑块得重新做第二是地面基础施工重地拖链要挖地沟、预埋轨道一旦车间工艺布局后期要调改造费用几乎等于重做一条线。换型时停线一周到两周对焊装车间来说就是产量损失。AGV进去之后滑橇这个概念还在但滑橇是背在AGV身上的。车型切换只需要换AGV上的支撑夹具或做快换支撑块地面一条磁条或一套反光板都不用动。调整线从“设备跟着车型走”变成了“车型数据跟着设备走”。2.2 节拍怎么定AGV数量与充电策略的联动计算调整线用AGV最核心的节拍参数是“单车循环时间”。白车身调整线常见的生产节拍是JPH 30到JPH 40也就是每台车身在线的生产节拍是90秒到120秒。AGV单循环时间由四段组成等待上车时间、搬运时间、停靠定位时间、返程时间。实际计算时我一般用这个公式估算AGV数量 单循环时间 / 平均生产节拍 × 1.15备用系数举一个算过的项目调整线长度约120米10个工位AGV最远搬运距离80米AGV空载速度控制在0.8m/s满载0.5m/s。单车单循环算下来是6分半生产节拍按100秒算理论需要3.9台。但这里有个很容易踩的坑电量和充电策略没算进去。如果三班倒连续生产AGV电池用磷酸铁锂按充放电比1:1.5算实际上线要配5台其中一台始终在快充位轮换。2.3 线边空间与地面条件上AGV前的四项硬预检调整线上AGV不是买了车就能跑前期有四个条件必须落实验证。第一是地面平整度AGV按±10mm的标高公差预留地面坡度要小于2度地坪漆破损严重的车间要先处理第二是无线覆盖AGV调度室、充电位、交叉路口这些位置无线信号强度要求不低于-70dBm第三是线边料架和工位器具的干涉AGV转弯半径内不能有落地式风管和电气柜第四是安全通道AGV行走路径上人员通行频繁的地方要规划安全触边加激光雷达的复合方案。这四项里地面平整度最容易被忽视。有的老车间地坪做过环氧自流平看着很平但AGV背载2吨白车身走起来驱动轮会碾出低频抖动视觉对接时相机拍出来的标定板都是糊的。建议直接做一道2米直尺检查局部不平度超过3mm的地方在AGV行走路径内都要处理。3. 调整线AGV系统架构拆解从WCS调度到单车控制器的数据链路3.1 三层控制架构与接口划分调整线AGV系统从管理到执行典型是三层最上面是车间级MES或生产管理系统中间是WCS仓库控制系统加AGV调度系统RCS最下面是AGV单机控制器。MES只管下生产订单和车型信息WCS负责拆成搬运任务AGV调度系统负责把任务分给具体某台车并做路径规划和交通管理。这里要划清一个边界很多项目扯皮就是接口没划清。MES到WCS是订单级接口走OPC UA或Webservice传的是车型、优先级、上线数量。WCS到AGV调度系统是任务级接口通过数据库或消息队列传的是“从哪个工位取车送到哪个工位”。AGV调度系统到单车控制器是执行级接口走TCP/IP私有协议或Modbus TCP下发的是路径和动作指令。调试时最容易出的问题就是越级。比如直接在MES里写死了“3号车去5号位”一旦AGV调度系统因为充电或维护把车调走了任务就直接断链。正确的做法是MES只告诉WCS要搬什么人、车、路线全部由调度系统自己决定。3.2 导航方式选型磁条、二维码与激光SLAM的取舍调整线AGV导航方式现在用得最多的是激光SLAM和二维码磁条导航在新项目中已经很少。三者的边界很清楚磁条导航成本最低地面施工简单但路径改起来要重新贴条而且磁条容易被车间铁屑和叉车碾压损坏。二维码导航精度高停止精度能到±5mm但地面二维码脏污之后识别率会往下掉调整线这种有焊渣飞溅的环境要加保护膜。激光SLAM灵活性最高不用地面标识但环境变化敏感的车间需要加反光板做辅助定位。白车身调整线我建议用激光SLAM加二维码混合方案。SLAM负责路径行走和避障二维码负责工位停靠时的二次精确定位。原因很简单调整线工位上的二次焊接会产生弧光和飞溅纯SLAM在弧光干扰下定位会有漂移二维码在关键停靠点做一个物理约束精度和稳定性都能兜住。3.3 单车控制器与PLC的IO交互信号AGV到了工位上要和工位PLC交换信号完成顶升、定位、允许作业、作业完成这一套时序。信号交互分物理IO和安全IO两层。物理IO用硬接线包括AGV到位、工位请求、顶升完成、放行允许安全IO走安全继电器回路包括AGV急停、区域扫描仪触发、联锁释放。这里给一份典型的IO信号对应关系信号名方向功能触发条件AGV到位AGV→PLC通知工位AGV已停靠二次定位完成停止精度满足工位请求PLC→AGV请求AGV等待或离开本工位作业未完成或前方工位堵塞顶升请求AGV→PLC请求顶升机构动作AGV与工位举升销对齐顶升完成PLC→AGV确认顶升到位举升到位信号返回放行允许PLC→AGV允许AGV驶离后方安全区无车、作业完毕IO信号对接里的一个常见坑是PLC程序里用了脉冲信号而AGV侧用的是电平信号。信号本身对上了但时序上差一个扫描周期偶尔丢一次放行就会造成堵车。一般做法是在PLC里做一个信号保持加上ACK确认用双握手完成一次交互。这个细节WCS联调时务必要写进测试用例。4. 三条AGV的路径规划与协同调度A*算法、锁区与死锁排除4.1 调整线栅格地图与A*算法的工程化实现AGV调度系统里路径规划最基础的算法就是A*也就是常说的“三条AGV基本A算法“的基本盘。虽然现在很多商用调度系统已经用上了更复杂的DLite或基于时间窗的规划但A在调整线这种场景仍然是最稳妥的选择——原因在于调整线路径相对规整没有太多动态障碍A完全够用。工程上落地A先要做栅格化。把调整线车间地图按0.5米分辨率的栅格划分AGV车体在地图上占2×2个栅格路径宽度按4个栅格处理。栅格代价分三档可通行是1靠近工位设备区是3禁行区直接设成无穷大。还要做一个事情把AGV转弯的代价加进去转弯栅格代价乘1.5这样A算出来的路径不会出现贴着工位频繁转向的S形轨迹。下面是调整线单机路径规划的简化A*实现import heapq def astar_path(grid, start, goal, agv_id): # 栅格代价地图 grid0可通行越大约难走-1为禁行区 open_list [] heapq.heappush(open_list, (0, start)) came_from {} cost_so_far {start: 0} while open_list: current heapq.heappop(open_list)[1] if current goal: break for dx, dy in [(-1,0),(1,0),(0,-1),(0,1),(1,1),(-1,1),(1,-1),(-1,-1)]: nxt (current[0]dx, current[1]dy) if not (0 nxt[0] grid.shape[0] and 0 nxt[1] grid.shape[1]): continue if grid[nxt[0]][nxt[1]] 0: continue move_cost grid[nxt[0]][nxt[1]] if dx ! 0 and dy ! 0: move_cost * 1.5 # 斜向转弯代价惩罚 new_cost cost_so_far[current] move_cost if nxt not in cost_so_far or new_cost cost_so_far[nxt]: cost_so_far[nxt] new_cost priority new_cost abs(nxt[0]-goal[0]) abs(nxt[1]-goal[1]) heapq.heappush(open_list, (priority, nxt)) came_from[nxt] current # 回溯路径 path [] node goal while node ! start: path.append(node) node came_from[node] path.append(start) path.reverse() return path这段代码的逻辑是标准的A*但有两个参数是调整线工程化时调出来的。栅格分辨率用0.5米而不是更细的0.1米是为了让路径平滑计算量可控斜向移动代价乘1.5是为了让AGV不会频繁斜穿工位区。代价地图上工位周边3个栅格我都设成代价10相当于一个软禁行区——车可以从旁边过但优先级很低。用这个思路三台AGV各自算路径时会天然绕开工位密集区域减少后续交通调度的冲突。4.2 单行道与锁区防止三车在交叉口互堵的工程做法调整线AGV路径另一个特点是窄很多老车间改造通道宽度只有3米左右AGV加上安全包络基本就是单行道。这意味着调度系统要有“锁区”能力。锁区就是把地图上的一段路径标记为已被某台AGV占用其他AGV在进入前必须等待释放。锁区粒度决定效率。调得太大比如一辆车占一整条通道另外两台车全部等着节拍全废调得太小两车在交叉口对头谁也走不了。我的经验是锁区按“路径段”管理不是按单个栅格。把调整线地图拆分成几十个路径段每段长度15到20米AGV在进入某段之前向调度系统申请占用驶出后释放。交叉口单独设一个特殊的锁区交叉口锁区长度覆盖整个交叉区域防止三车同时涌入。死锁在系统里表现为两车在交叉口面对面等待各自的下一段都被对方锁定。此时调度的任务不是等而是主动仲裁。常见做法是设定优先级正常生产任务优先级最高回充电位次之人工召唤最低。低优先级车辆主动倒车让行而不是等高优先级车绕路。4.3 AGV协同从任务分配到充电工位的统一编排三台AGV调度任务分配用的是“最短预计完成时间”策略也就是把新任务分配给“完成当前任务后能最早赶到起点”的车。这里要算的不是空车距离最短而是时间最短——因为有的车正在执行长距离搬运有的车正在充电还有的车路径上会路过拥堵区。AGV协同还有一个二级问题是充电管理策略。调整线是连续生产不能等电量低于20%才去充电那样会发生三车同时低电量、一起挤向充电位的情况。我在项目里用的策略是“电量阈值分级”电量高于60%正常跑任务电量在30%到60%之间任务执行完后回充电位补电电量低于30%立即终止当前任务去充电当前位置执行中的任务由调度系统重新分配给其他车。这套策略还有一个配套参数充电位最少保留一个空闲。三台AGV如果车间布局只规划了两个充电位那至少要保证任何时候有一个充电位是空闲的防止某台车紧急充电时无位可用。调整线AGV数量不多这个约束完全够用。5. AGV落地调整线的避坑清单信号、对接与节拍验证的四个血泪坑5.1 坑一视觉二次定位偶发超时白车身在工位上晃动现象AGV在工位停靠时二维码相机偶发识别失败定位超时系统报警人工介入后恢复。频次不高但一旦发生就影响节拍因为整条线都在等这一台车。原因白车身在AGV上是通过支撑块定位的AGV制动时车身惯性会往前窜一下虽然有止退销但车体晃动导致相机与地面二维码的相对角度超出了识别范围。还有一个原因是弧光干扰二次焊接工位的弧光强度高相机曝光参数固定时个别帧过曝。解决把二次定位的识别逻辑改成“连续三帧一致才算成功”不要求第一帧就出结果。同时给二维码相机加偏振片和遮光罩并把曝光模式改为自动把弧光的过曝帧跳过。视觉抓拍位置不要放在工位正中央而是放在工位前1米处先预识别一次AGV带着预识别结果进工位真正到位后再确认一次成功率能提到99.9%以上。5.2 坑二无线信号满格但AGV调度指令时断时续现象车间AP显示信号强度-60dBm手机和PDA都正常但AGV调度系统偶尔报指令超时尤其在充电位和地沟区域。原因车间里金属结构多白车身本身就是一个大反射体AP部署在立柱上AGV机身低信号被车身遮挡。还有一个隐蔽干扰源是车间变频器电缆桥架AGV走过的区域刚好平行于动力电缆电磁干扰导致TCP重传。解决AGV通信不要用普通商用Wi-Fi用支持漫游切换的工业无线模块并提前对AGV行走路径做全覆盖信号测试而不是对车间做覆盖测试。AP天线安装高度降到2.5米与AGV天线高度接近。变频器电缆桥架段改用屏蔽电缆或调整AP位置绕开。测试标准写清楚AGV行驶状态下通信丢包率要低于0.5%连续丢包不超过2帧。5.3 坑三AGV与工位PLC信号对上了但用起来偶尔丢一次放行现象单步调试信号全部正常但连续跑一个班次总有一两次AGV停在工位上不走PLC侧显示已放行AGV侧没收到。原因PLC中放行信号用的是脉冲下发脉宽200ms。AGV控制器的任务循环周期是250ms如果信号落在循环空隙直接丢失。这是典型的“逻辑对了时序错了”。解决改P LC程序放行信号用置位AGV收到后回复ACKPLC收到ACK后复位。也就是前面提到的双握手交互。这类信号时序问题在联合调试阶段建议连续空跑200个循环测试不要只测三五个循环就收工。5.4 坑四节拍验证只看单机循环时间整线节拍差一大截现象单台AGV循环时间测试是6分钟比理论计算还快但整线JPH就是上不去始终差10%左右。原因多台AGV跑起来后交叉口锁区和工位占用的等待时间加进来了。单车循环时间是理想值整个系统的实际产出等于所有AGV循环时间的最大公约数决定的而不是平均值。换句话说只要有一台车在关键堵点被卡住整线节拍就被拖住。解决节拍验证必须跑系统级仿真。用调度系统的仿真插件把三台AGV的实际路径、工位作业时间、锁区规则全部放进去跑两个小时的仿真看交叉口最大等待时间和平均等待时间。最大等待时间超过60秒的交叉口要调整锁区策略。上线后再用实际运行数据回代仿真模型校准参数。节拍优化的核心目标不是缩短单机循环时间而是消除交叉口等待的毛刺。提示调整线AGV调试时保存每一台车的完整运行日志非常关键。系统级的节拍分析、死锁复现、信号偶发问题排查全部依赖日志回放日志保留策略建议至少90天按天分文件压缩存储。6. 验证进阶用AGV运行日志做调整线节拍的数字化复盘调试验收时光看AGV跑起来正常是不够的。我习惯在WCS和AGV调度系统之间留一张任务执行明细表记录每个搬运任务的创建时间、下发时间、AGV到位时间、任务完成时间以及每次锁区等待的起止时刻。这张表就是整条调整线节拍的原始证据。验收时做一个节拍瀑布图横轴是任务序号纵轴是AGV循环时间把每个任务的等待时间标出来。你会很直观地看到哪个工位的等待时间在随着生产推进逐步变大那个位置就是隐藏瓶颈。比如我遇到过的情况是调试期间把返修工位的放行条件写成了“前方安全区清空”而正常生产时前方安全区经常被暂存车占用导致返修工位平均每次多等40秒。还有一个有用的进阶做法把AGV调度系统的运行日志和PLC的工位作业记录做时间对齐。AGV记录显示已经到位但PLC记录里工位作业还没开始多出来的这段时间差就是“人机交互等待”——操作工还没走到位。这类数据可以反过来推动现场管理优化而不只是改AGV参数。从调试第一天就明确日志字段规范别等项目快结束再补。字段至少包括任务ID、AGV编号、任务类型、起点工位、终点工位、指令下发时间、到位时间、锁区等待时长、作业完成时间、电量。这个习惯我坚持了三个项目每一次排故都靠它希望帮到你。本文还有配套的精品资源点击获取
返回列表