企业官网建设流程全解析

去年接广汽传祺总装车间这个项目的时候，我就知道它不会是一个“买几台AGV装上就能跑”的简单活儿。项目title写得很直白：海康AGV小车加斯普莱工业无线组网。但真正落地过程中牵扯出来的东西远不止这两块牌子——三条AGV协同作业要跑A*路径规划，车间里成千上万平方米的铁皮结构、电机变频设备给无线组网挖了一个又一个坑，再加上与MES对接、线边料架改造、二维码地图铺设……整个项目做完，我才敢说自己摸清了工业移动机器人物流系统的底。

这篇就把我们团队从方案选型、无线勘测、调度算法落地，到上线运维的完整过程捋一遍。如果你正在评估车间上AGV，或者已经在为AGV无线断连、三车互堵这些问题头疼，这篇应该能帮你少走不少弯路。

1. 传祺车间上AGV：这钱该不该花，花在哪

1.1 总装车间物料配送的运行瓶颈

传祺这个总装车间，一条主线几十个工位，零部件从卸货区、缓存区到线边的配送量非常大。原来的模式是传统的电动牵引车加拖车，司机人员分三班倒，用对讲机喊话调度。表面上看着运转正常，实际上问题一大堆。

最核心的痛点是“信息黑洞”。车在哪个位置，只有司机自己知道，组长问起来靠对讲机喊，喊不到人就只能干等。急料呼叫过来，配送员可能正卡在某条通道上，人为响应周期根本不可控。更麻烦的是夜班，原本白班还能靠经验老道的班组长压住场面，夜班人手一少，整个物料配送节奏就乱了。加上总装车间产线节拍一直在往上提，靠堆人已经解决不了问题。

同时，车间里人车混流的现象很严重。牵引车拉着长长的拖车在通道上转弯、倒车，行人避让全靠喇叭，安全隐患始终存在。厂里之前也评估过磁条导航AGV，但磁条方案有个致命问题——产线调整或工位挪动时，地面磁条要重新贴，工期长、成本高，而且磁条容易被叉车压坏，后期维护量非常大。

1.2 目标拆解：效率、柔性、可追溯

项目立项的时候，业主方给了三个核心诉求：效率、柔性、可追溯。翻译成工程语言是这样的：

• 效率：从呼叫发出到物料到达线边的时间要可量化，单趟配送时间要比人工牵引明显缩短，白夜班表现一致。
• 柔性：后续产线节拍调整、工位变化时，AGV的路径和站点可以通过软件改，不需要动地面基础设施。这一点直接否掉了磁条方案。
• 可追溯：每辆AGV的位置、状态、当前任务、历史记录都要留痕，能够对接车间MES系统，将来做物料齐套分析、配送准时率统计都有数据支撑。

另外还有一条安全底线：车间里有大量线边作业人员，AGV必须做到人车混流下的安全运行，声光报警、避障传感器、急停按钮都是标配。这里要特别提一点，AGV“能跑”只是及格线，“不出安全事故”才是验收的前提。前期方案评审时，我们把安全策略单独列了一个章节来谈，包括障碍物检测距离、减速逻辑、急停后的恢复流程，这一块一定不能省。

2. 从海康选型到场地勘测：AGV不是买来就能跑

2.1 潜伏式和牵引式之间的选择

物流机器人的形式五花八门，选型错一步，后面全盘被动。在传祺这个项目里，我们最开始同时评估过牵引式和潜伏式两个方向。

牵引式AGV的优势是改动小，直接替代原来的电动牵引车，后面拖挂料车就行，载重能力大，适合长距离大吨位转运。但缺点也很明显——它需要拖车编组，转弯半径大，在总装车间里灵活性差；而且牵引式对接料车时，如果料车的挂钩高度、刹车方式不一致，还要做一轮料车改造，工作量并不小。

潜伏式AGV是另一种逻辑：它钻到料架底部，顶升后把整个料架驮着走。优点是对接精度高、转弯灵活、运行路径短；缺点是料架本身要做标准化改造，底部要留出AGV进入的净空高度。我们最终选了潜伏式方向，因为总装线边的料架本来就要重新规范，顺势做一轮标准化改造，反而把整个现场的料架规格统一了，后续扩展性更好。

品牌选型上，考察过几家主流AGV厂商。最后选海康机器人，因素不是单一的：

• RCS调度系统成熟度：海康的机器人控制系统在行业里落地案例多，接口文档开放度高，对接MES/WMS方便。
• 导航方式匹配：海康的潜伏式AGV支持二维码加IMU加里程计融合定位，精度和成本平衡得很好。
• 本地化服务：海康在广州有成熟的售后和工程团队，项目后期驻场、响应都有保障。这一点对生产车间来说非常实际，AGV故障停线一小时，损失不是设备本身能算回来的。

2.2 二维码网格地图与站点规划

导航方案确定后，真正费时间的是地图和站点设计。我们采用的是二维码网格方案——在AGV运行通道上，按一定间距铺设二维码，每个二维码有唯一ID，AGV底部的相机识别二维码获取绝对坐标，再配合IMU和轮式里程计做短距离推算。

二维码铺设间距是经过仔细考量的。间距太大，AGV在两个码之间的定位误差累积大；间距太小，铺设成本高、维护量也大。我们最终用的是1.2米乘1.2米的网格间距，既能保证定位精度，又不至于让施工量失控。

地图坐标系以导航原点建立，所有站点、路径、避让点都落在这个坐标系里。站点类型包括：充电位、缓存区取料位、线边呼叫工位、临时避让点、维修区。这里有个经验值得分享——站点设计一定要和车间工艺流程对齐，不能光听AGV厂家的标准模板。比如线边呼叫位，要和产线工位的实际配货口一一对应，如果站点离得远，员工取料要绕路，表面上看AGV跑得挺欢，实际使用者天天抱怨。

还有一个选型阶段容易忽略的地方：转弯半径和通道宽度的匹配。我们最初按AGV车体尺寸预留通道宽度，现场勘测时发现有几处通道转弯处因为立柱和工装设备遮挡，AGV带料架转弯时空间不足。这个问题如果等设备到场再发现，返工成本极高。建议任何AGV项目，土建勘测阶段就要把“车体加最大料架”的转弯包络图画出来，和现场通道逐段核对。

3. 斯普莱工业无线：在铁皮森林里给AGV铺一条“看不见的路”

3.1 为什么普通Wi-Fi扛不住AGV车间

AGV项目里，无线网络经常是最先被轻视、最后背锅的环节。很多团队的习惯是“车间里装几个AP就够了，反正Wi-Fi哪都能用”。但AGV对无线的要求和办公场景完全是两个物种。

AGV和调度系统之间的通信是连续实时的。AGV每隔几百毫秒上报一次位置和状态，调度系统下发的停止、减速、转向指令同样要求毫秒级到达。一旦通信中断或者丢包严重，AGV的控制逻辑会判定“失联”，触发安全急停。一台车急停，后续路径被堵塞，整条物流线就瘫痪了。这个连锁反应，我在后面的故障章节会详细讲。

总装车间对无线来说是个极其恶劣的电磁环境：

• 大量钢结构立柱、货架、工装设备，无线信号反射严重，多径效应会让信号强度看着挺好，实际吞吐一塌糊涂。
• 焊机、变频器、大功率电机启动时产生宽带电磁干扰，2.4GHz频段基本是个灾难。
• AGV始终处于移动状态，需要在多个AP覆盖区之间切换，漫游时延稍微一大，调度就会断连。

所以这个项目果断上了斯普莱的工业无线整体方案，包括工业级AP、无线控制器AC、PoE交换机和配套天线。专业做工业无线的厂商和办公Wi-Fi品牌的区别，在于他们知道“移动设备的连续性”才是核心，而不是单纯的覆盖面积。

3.2 覆盖规划、信道划分与漫游调优

无线网络设计这块，我们实际上做了两轮。第一轮是按厂家提供的软件模拟出的AP点位图部署，结果AGV实测时在好几个区域出现漫游掉线。后面我们重新做了现场勘测，结合实际AGV行走路径调整点位，才算稳定下来。

覆盖规划的核心逻辑是这样的：不追求整个车间都满格，而是保证AGV所有行走路线和停靠站点上的信号连续稳定。AP布点沿着AGV主通道来，而不是按车间均匀铺。因为AGV只在特定路径上跑，把AP集中在通道上方，信号效率最高。

信道规划同样有讲究。AGV专用SSID只用5GHz频段，2.4GHz直接关闭复用。原因很简单：2.4GHz干扰源太多，蓝牙、微波炉、附近的办公Wi-Fi都在抢信道，而且2.4GHz吞吐天花板低，对AGV这种高密度小包通信不太友好。5GHz频段里还要把信道错开，相邻AP不能同频，我们用1、6、11（5GHz对应36、44、149等）错开分配，同时关闭不需要的DFS信道，避免雷达规避机制带来的周期性信道检测。

漫游优化是无线这块的重头戏。办公场景断网几秒顶多卡一下，AGV断网几秒就是急停。我们调了三个地方：

1. AP间覆盖重叠区：相邻AP的信号重叠不能太小，否则AGV还没有完成漫游，旧AP信号已经弱到不可用。重叠区留出足够的缓冲，让AGV有充足时间完成切换。
2. 漫游触发阈值：AGV网卡默认的漫游触发在-70dBm左右，但这个值受驱动策略影响。我们把阈值适当调高，让AGV在信号明显变差之前就主动切换到新AP。
3. 白名单和AP优选：在AGV工控机的无线配置里，锁定允许连接的AP列表，避免AGV连到信号强劲但信道拥挤的办公SSID上。

这套配置做完后，AGV在车间里往返跑的漫游切换时延稳定在几十毫秒级，符合调度系统的要求。

3.3 弱网丢包对AGV安全机制的连锁反应

这里想单独说说“弱网”和“丢包”的区别。信号强度弱，顶多网速慢；但只要链路还在，TCP/IP的重传机制能兜住。真正可怕的是丢包——尤其是连续丢包，AGV控制端会直接判断通信链路断裂。

我们调试期间做过一次测试，在某个AP覆盖边缘人为丢包30%，AGV的调度系统在几秒内就报了通信超时，随后车辆急停。从急停到重新联机、人工确认、恢复任务，花了将近两分钟。车间里这两分钟看起来不长，但产能节拍都是按分钟算的，一天多停几次，当天的产量指标就悬了。

所以评估AGV无线网络时，指标不是覆盖率百分之多少，而是：

• 端到端丢包率：AGV与调度系统之间的ping丢包，目标小于0.1%。
• 漫游切换时延：目标小于100毫秒，且不允许丢包超过2个。
• 并发容量：车间里同时有AGV、手持PDA、工位终端在线，要保证AGV通信不被挤占。

我建议任何AGV项目，入场调试前先和业主确认这套无线验收标准，白纸黑字写进技术协议。很多人被“无线不好调”这种话糊弄过去，最后AGV跑不稳，天天跟网络打架。

4. 三条AGV共线运行：A*只是起点，防死锁才是核心

4.1 单机导航里的A*怎么落地

三条AGV协同作业，频率最高的算法关键词其实就是“A*”。网上聊A的大部分文章止步于八数码、五子棋这类玩具场景，真实AGV项目里A的落地方式要务实得多。

简单回顾一下A*的原理：它用f(n) = g(n) + h(n)来评估每个节点。其中g(n)是从起点到当前节点的实际代价，h(n)是当前节点到目标点的启发式估计。AGV场景里最常用的启发式函数是曼哈顿距离，路径越长启发值越大，搜索不断往目标方向引导，比Dijkstra这种无方向盲搜快得多。

AGV上的A搜索对象不是自由二维空间，而是预先铺好的站点拓扑图。我把车间地面抽象成一张有向图：节点是二维码站点、转弯点、停靠点，边是AGV允许行驶的路径段，边的权重是路径长度加转向惩罚。A在这张有向图上搜索，得到从起点到目标点的路径点序列，AGV沿着路径点依次行驶。

当时的规划核心逻辑可以简化成下面这个Python伪代码，方便大家理解：

import heapq def heuristic(a, b): # 曼哈顿距离作为启发函数 return abs(a.x - b.x) + abs(a.y - b.y) def astar(start, goal, graph): open_pq = [(0, start)] came_from = {start: None} g_score = {start: 0} while open_pq: current_f, current = heapq.heappop(open_pq) if current == goal: path = [] while current: path.append(current) current = came_from[current] return path[::-1] for neighbor, cost in graph[current].items(): tentative_g = g_score[current] + cost if tentative_g < g_score.get(neighbor, float('inf')): came_from[neighbor] = current g_score[neighbor] = tentative_g heapq.heappush(open_pq, (tentative_g + heuristic(neighbor, goal), neighbor)) return None

在传祺项目里，海康的RCS调度系统已经把A*封装成了内部模块，我们不需要自己从零开发，但必须理解它的底层逻辑，因为后面调多车协同的时候，大量问题出在地图拓扑和路径权重的定义上，而不是算法本身。

4.2 路段锁、优先级与避让区

三条AGV如果各跑各的A*，不搞协同，那碰撞只是时间问题。因为A*只会给单车找一条不撞墙的最短路径，它不知道另一台车也打算走同一段路。三台车共用一个主通道的场景，光靠车头激光避障远远不够——避障只能让车停下来，不能让车学会怎么高效地让路。

我们实际采用的是“集中式调度加路段锁”的机制。RCS把整个地图的路径拆成一段段路段，每个路段同一时刻只允许一台AGV占用。AGV要进入某段路之前，必须先向RCS申请，拿到路段锁才允许进入。这个“锁”的概念特别好理解，就像单车道桥梁，同一时间只能有一个方向的车通过。

但路段锁带来一个直接问题：锁的粒度怎么划分。上线初期我们用的是长路段，因为路径段少，调度逻辑简单。结果发现一台车在交叉口等待时，另一台车明明隔着几百米，因为路径上某个长路段被锁，也只能干等，效率极低。后来重新梳理地图，把长路段拆成短路段，按车长和转弯半径细化，锁的粒度精细了，并发效率才上来。

第二个关键策略是任务优先级。AGV项目里不是所有任务都平等的：产线急料呼叫是最高优先级，正常配送次之，空车返回充电区再次之。高优先级车在申请路段锁时，可以抢占低优先级车已申请的路径，低优先级车收到抢占通知后，就近开到避让区等待。这里的一个前提是地图上要留足避让区，否则“让路”会让到角落里出不来。

第三个是循环路径设计。我们在主通道上做了一部分单向循环，AGV统一逆时针走，减少了大量对向行驶的冲突。这个思路一点不高深，但效果立竿见影——三台车的对向会车几乎被消灭，剩下的冲突集中在交叉口的交汇点，通过路段锁和优先级就能解决。

4.3 调参实战：从频繁等待到稳定节拍

系统刚上线那几天，三台AGV的整体效率一度被现场人员吐槽“不如人工”。我们从调度日志里看到，车辆大量时间处于“等待路段锁”状态，部分任务的等待时间甚至超过了实际行驶时间。

问题出在哪？日志分析显示，路段锁的粒度是主因，但还有一个隐藏因素：调度系统的路径预占策略太保守。RCS默认给每条规划路径一次性预占全链路路段，A先规划好路径，B再规划时发现整条路线被占，哪怕A离这些路段还有好几个站点，B也只能等待。优化策略是把“全链路预占”改为“逐步申请”——AGV每经过一个路段，再申请下一个路段，锁的持有时间大幅缩短，并发利用率和调度灵活性比之前好很多。

另外，我们对任务分配逻辑也做了调整。三台车中，原来固定A车服务1号线，B车服务2号线，C车服务3号线。结果1号线呼叫密集时A车忙不过来，其他线空着。改成动态任务池后，任何空闲车辆优先响应最高优先级任务，充分用足了运力。

调完这些参数，单车平均配送时间从14分钟降到9分钟，三车整体节拍稳定在项目预期之内。这个案例说明一个道理：AGV数量不多时，瓶颈往往不在A*算法本身，而在路段划分粒度、任务分配策略、预占逻辑这些工程细节上。算法再好，拓扑和策略设计不合理，照样跑不出效率。

5. 上线月里我处理过的三个典型故障

5.1 AGV运行中随机急停：无线漫游丢包的完整排查

项目上线半个月后，车间反馈一个很棘手的问题：AGV运行到B通道和C通道交叉口附近时，偶尔会报“通信超时”并急停，但几分钟后又自己恢复，完全没有规律。

这个故障极难排查，因为不是必现的，可能一两个小时才出一次。我们第一反应是无线有盲区，拿着测试电脑到现场测，信号强度显示-60dBm以上，看起来完全正常。后来在故障区域放了一个持续的ping监控，发现端到端丢包率确实偶发飙高，而且丢包发生的瞬间，正好对应一个漫游切换动作。

再深入看AGV工控机的无线日志，问题清晰了：AGV的网卡驱动并没有在信号变差之前主动触发漫游，一直守着旧AP信号到-80dBm以下才开始找新AP，切换过程又因为扫描时间太长，直接丢了几个包。调度系统连续几次收不到心跳，就判定AGV失联，触发急停。

修复方案分三路并进：

1. AC侧把覆盖该区域的AP发射功率略微调高，同时调整RSSI均衡策略，让AGV在信号衰减初期就被引导切换。
2. AGV工控机上关闭系统自动漫游，改用驱动级漫游参数，把触发阈值从默认的-75dBm提前到-65dBm，保证在新AP信号足够好的时候完成切换。
3. 把两个AP的重叠覆盖区在交叉口处特意加大，避免AGV在转弯的同时进行无线漫游。

修复后连续观察三天，漫游切换平均时延50毫秒，最大120毫秒，再也没有因为无线原因急停过。

5.2 二维码脏污与补光角度引起的定位漂移

运营一个多月后，某条线边停靠点开始出现AGV对不准料架的情况，偏差大概三四厘米。AGV顶升时如果位置不正，料架会倾斜，存在安全隐患。

排查时我先看的RCS导航日志，发现AGV在到达该停靠点前的最后一个二维码识别成功率明显偏低，几次甚至连续丢码。到现场一看，那个位置的二维码被牵引车轮胎带起的油污覆盖了薄薄一层，加上AGV底部补光灯在金属地面上形成反射眩光，相机识别率进一步下降。

处理办法是双管齐下：

• 把这批二维码更换成耐磨防污的材质，贴完后在上面覆盖一层透明保护膜，同时纳入车间5S保养清单，要求每周清洁一次。
• 调整AGV底部补光灯的亮度和安装倾角，减少地面镜面反射干扰。

另外，我们在停靠逻辑里增加了二次校验机制：AGV进入停靠区之前，连续确认两个二维码的位姿数据，取平均值作为最终停靠位姿，而不是只依赖最后一个码。改动之后，该区域再没有出现定位漂移问题。

这个故障提醒我，二维码导航方案便宜可靠，但它是有维护成本的。地面上那些小方块，看着不起眼，一旦脏污破损，AGV整个就“瞎”了。工业现场要建立二维码的巡检制度，别等出了问题再去擦。

5.3 PoE长线供电导致的AP离线

第三个故障非常有意思，排查过程给我上了一课。

上线初期，B通道一个AP总是间歇性离线，发生在每天早班和下午班开始的时段，重启后能恢复，但撑不了几个小时又掉线。按常理，AP离线一般查网络配置、查IP冲突、查AC连接。我们整天和AC、交换机、网线搏斗都没结果，直到有一次现场运维顺手测了一下AP的供电电压，才发现异常。

那个AP的网线从弱电间接出来，走线距离已经接近一百米，中间还经过了一个转接端子。PoE供电在长距离线缆上电压降很大，AP启动时瞬间电流需求高，电压直接被拉低，触发了硬件保护，AP强制重启。为什么集中在早晚班时段？因为那两个时段是AGV集中充电和出入库高峰，无线终端数量多、AP负载高，功耗上升，供电不足的问题就被放大了。

解决方法是把那台AP的供电方式改成光纤收发器加本地DC电源，网线只跑数据不跑供电，彻底绕开PoE距离限制。如果现场不想增加光纤，也可以在该位置附近加装一台PoE交换机，缩短网线长度，同时注意交换机PoE功率预算是否充足。

这个故障的教训是：工业无线前期勘测，不能只测无线信号，还要把每个AP的物理链路距离、PoE供电余量一并核清楚。网络八九十米看着能凑合，在实际负载下就是定时炸弹。

6. 最终验收与运维建议

6.1 效率、稳定性和人工变动的实测数据

项目验收的时候，我们整理了一份对比数据，其中几个数字我觉得对想上AGV的车间很有参考价值。人工牵引阶段单趟配送平均耗时12分钟，AGV上线稳定后单趟平均8分钟，缩短约三分之一。呼叫响应时间从平均15分钟降到5分钟以内，急料呼叫响应更是缩短到3分钟。配送准时率从85%左右提升到99%以上，产线停线等料的情况基本消除。

无线网络的数据是这样的：AGV运行期间端到端丢包率小于0.1%，AGV与RCS的断连次数为零，漫游切换平均时延控制在80毫秒以内。这组数据说明工业无线针对AGV场景的专项设计是有效的，不是靠运气。

人工方面，原来的牵引车司机转岗了一部分到线边配送作业，另一部分经过培训转为AGV现场管理员，负责日常点检、二维码维护、简单故障处理。AGV不是单纯减少人力，而是把人力从低价值的重复驾驶中释放出来，去做更有质量的管理工作。

6.2 给准备上AGV的车间几条建议

做完这个项目，我对AGV落地的理解比之前务实了很多。如果有朋友也在筹备类似项目，我会给出下面几条建议：

• AGV、无线网络、物流流程必须三位一体规划，任何一项单独招标、单独施工，后期都会互相扯皮。传祺项目之所以顺利，很大程度上因为无线网络从一开始就按AGV场景设计，而不是拿来一个通用Wi-Fi方案硬套。
• 多车调度别急着搞高级算法，先把地图拓扑做合理。三条AGV这个规模，A*加路段锁加优先级已经足够。如果地图上有大量不合理的交叉和长路段，再厉害的算法也救不回来。
• 无线验收标准要写进合同，丢包率、漫游切换时延、急停次数都是可量化的指标。验收不是看信号满格，而是看AGV跑一周下来急停几次。
• 二维码方案的日常维护别忽视。AGV靠地上的小码认路，码脏了、破了、磨损了，车就瞎了。建立巡检制度，把二维码维护落到班组考核里。
• 日志是最好的老师。RCS调度日志里什么都有，车辆等待时间、路段占用时长、任务响应周期，这些数据比供应商给你画饼实在得多。我在项目里很多优化决定不是拍脑袋，而是每天翻日志翻出来的。

最后分享一个小技巧吧：AGV上线后，定期导出调度日志做路径热力图分析，看哪些路段是拥堵点、哪些避让区根本用不上。传祺项目运行半年后，我们根据热力图调整了两处避让区的位置，把交叉口通行效率又提了一截。这种东西，供应商不会主动帮你做，但做了之后效果是实打实的。AGV项目从来不是交付即结束，上线后的持续调优才是真正拉开使用体验差距的地方。