1. 项目背景与核心痛点为什么智能仓储机器人需要重新思考计算架构先聊个真实的场景。去年我参与过一个电商仓的AGV项目改造现场300多台机器人核心诉求其实就三个能自己导航、能看懂货物、能实时和调度系统保持通信。听起来不复杂但真正落地的时候问题一个接一个地冒出来。当时团队一开始用的是传统的ARM开发板方案就是那种把CPU、内存、接口都固定在一块板子上的设计。前期做原型验证还挺顺利等到真要往量产走麻烦就来了。第一批试产50台光是接口不匹配导致的硬件改版就折腾了快两个月每改一次板子底层驱动、系统镜像、固件全部要跟着调一遍研发同学加班加到头秃。更头疼的是客户中途提出要加一个视觉避障模块主控板的算力直接不够用了整个方案推倒重来成本和周期全部失控。这个案例其实是行业里非常典型的一个缩影。智能仓储机器人虽然是机器人但它跟传统的工业机械臂完全是两个物种。机械臂固定在工位上算力需求相对稳定而仓储机器人是在一个几千平米的库房里到处跑环境动态变化任务随机到达还要跟几十上百台同类设备协同作业。这就对计算平台提出了几个传统开发板很难满足的要求算力要有余量但不能功耗失控接口要能灵活扩展但不能频繁改板供货要稳定但又要能跟上技术迭代的速度。COM板卡这种形态本质上就是为解决这一类问题而生的。它的核心思路特别简单把整个系统分成两部分一块是Core Module核心板把所有和计算强相关的部件CPU、内存、eMMC存储、供电管理全部集成在一个巴掌大的板卡上。另一块是Carrier Board载板负责把核心板的接口引出来做成电机驱动接口、传感器接口、通信接口这些跟具体业务相关的部分。这个拆分的价值等到你真正做产品的时候才会体会得特别深。核心板是标准化、量产化的选型一次就固定了而载板可以根据不同项目、不同客户的需求灵活定制两者通过标准化的金手指或板对板连接器对接。本文主要面向的是智能物流设备研发工程师、AGV/AMR整机设计人员以及正在从传统嵌入式方案转向模块化架构的团队。接下来我会把COM板卡在仓储机器人里的选型思路、硬件设计要点、软件适配方法和实际部署经验一次讲清楚。2. 方案选型与架构设计COM板卡落地的关键考量2.1 算力分级Lite版就够用还是必须上Pro版COM板卡的算力跨度非常大从低端的双核A53到高端的十二核A78、X86系都有对应产品。仓储机器人项目里第一步要做的就是根据你的机器人承担的任务类型来划定算力需求区间这一步不能拍脑袋。我自己习惯把仓储机器人分成三档来看。第一档是纯交通型AMR只负责搬运导航靠反光板或磁条这种场景一颗四核A55级别的SoC就完全够用Linux系统跑个导航算法和运动控制CPU占用率基本能控制在40%以内。第二档是视觉导航型AGV需要跑SLAM算法要实时处理激光雷达数据和深度相机点云这个就算力需求直接翻了几倍至少需要六核以上的处理器而且最好带GPU或NPU加速单元。第三档是复合机器人既要搬运又要抓取机械臂运动规划加上视觉识别放在同一个平台里这种就必须上旗舰级的算力了。有个很实在的经验可以参考就是算力需求按算法模块往上叠加比如SLAM加视觉识别加运动控制加调度通信每个模块在选型阶段先评估出峰值占用率然后总和乘上1.5到2倍的余量系数这个系数是给系统升级和算法优化留的缓冲很多人会忽略这一层结果就是上线半年后想加个新功能发现性能捉襟见肘。2.2 接口矩阵把机器人的神经末梢一次列全算力确定了之后紧接着就要梳理接口。这块特别容易出错因为仓储机器人身上的外设种类实在太多了而且每种外设的接口协议还不一样。我做一个项目时会把外设接口清单拉成一张矩阵表比如激光雷达一般走以太网口USB或者串口也都有深度相机现在主流是USB3.0或者走MIPI-CSI直连电机驱动器大多用CAN总线或EtherCAT安全触边和急停按钮是IO输入状态灯和蜂鸣器是IO输出跟调度系统通信需要Wi-Fi或4G/5G模块这个一般走PCIe或USB。还有一点容易被忽略就是给设备做远程调试和维护用的调试串口以及给售后人员用的USB口这些虽然不起眼但在部署现场非常关键。COM板卡的优势在这个环节就体现出来了。核心板上的CPU引脚通过高密度连接器全部引到载板上你在载板上想做成USB3.0还是做成PCIe想复用成UART还是I2C都在原理图阶段就能灵活配置不用重新选核心板。这就相当于你把所有外设的接口方案固定在了载板设计里核心板换下一代产品时只要引脚定义不变载板几乎不用动。2.3 连接器标准COM Express、Qseven、SMARC怎么选目前市面上主流的COM板卡连接器标准主要有三大家COM Express、Qseven、SMARC选哪个直接影响后续的整个设计流程。COM Express是历史最久、生态最成熟的标准引脚数量最多支持PCIe通道也最充裕适合需要大量高速外设的场景。但它有个短板是模块尺寸大金手指也长整机对空间有要求的项目用起来不太灵活。Qseven是典型的紧凑型标准MXM接口体积小适合对尺寸敏感的产品但PCIe通道数相对有限。SMARC是后起之秀针对低功耗嵌入式场景优化得很到位引脚定义比Qseven更合理载板设计难度低一些而且持继性好几个主流芯片平台都有对应的SMARC模块。仓储机器人项目里怎么选我给个比较实用的建议。如果机器人本体空间比较充裕而且外设接口数量很多比如有五六路以太网、三四路USB3.0、两路PCIe优先考虑COM Express扩展性最省心。如果是小型潜伏式AMR车体本身就是一个扁平的盒子内部空间极其有限Qseven或者SMARC就是更合适的选择板子整体高度可以控制在很薄的范围内。我自己做潜伏顶升式AGV的时候用的是SMARC做大型叉车AGV的时候用的是COM Express各有各的道理。2.4 宽温与供电工业场景下COM板卡的生存条件这个细节最容易被刚入行的朋友忽视但恰恰是仓储现场最容易出问题的环节。仓储库房虽然有顶棚但很多仓库其实是半开放式的冬天和夏天温差极大再加上AGV充电时电池发热、电机控制器产生的热量都会堆积在车体内部板卡处的环境温度往往比环境温度还要高10到15度。普通的商业级板卡工作温度范围一般在0到60度常温下没问题但夏天仓库里40度高温车体内部可能就55度甚至更高这时候商业级板卡随时可能宕机。工业级COM板卡的标准工作温度是零下40度到正85度选型时务必确认板卡是宽温设计而非仅仅是商业级。另外还要关注供电设计仓储机器人的电源系统是电池直接供给电池电压从满电到亏电会有一个明显的波动区间比如48V电池组充满时可能到54V放完电时低到40VCOM板卡的前端必须能承受这个电压波动范围同时板卡本身的DC-DC转换效率要够高。我实测过一款SMARC板卡待机功耗做到3瓦以下满载功耗控制在12瓦左右整机厂在设计电池容量和充电策略的时候这部分功率预算非常关键。还有电容的选型宽温固态电容比普通的电解电容在低温下的表现好太多零下20度冷启动的时候劣质电容直接会影响供电纹波导致系统不稳定。3. 核心硬件细节与载板设计实操3.1 核心板选型清单看懂SoC、内存与存储的匹配逻辑核心板选型有几个硬指标要卡死SoC的架构和核心数、内存的频率和容量、存储的规格、以及板卡的视频输出能力这些直接决定机器人的大脑好不好使。业界在这类项目中主流选型有两种路线一种是基于瑞芯微RK3588的ARM核心板八核架构四颗A76大核加四颗A55小核带6 TOPS算力的NPU做视觉检测和轻量级AI识别绰绰有余。另一种是高通的QCS系列或者NXP的i.MX8系列前者在图形和AI算力上更强后者在工业稳定性和供货周期上更有保障。内存这块要注意的是仓储机器人的SLAM导航算法建图时内存消耗非常大跑一套激光SLAM加视觉里程计的组合方案内存占用很容易就上到4GB以上如果再叠加多个相机和点云数据的缓存8GB内存是起步配置建议直接选16GB版本成本差异不大但余量充足得多。存储方面核心板上的eMMC容量32GB起步因为Ubuntu系统镜像加ROS环境加大型地图数据就已经吃掉不少空间了。有条件的话尽量选带NVMe SSD接口的载板设计方案地图和日志的读写速度会快一个量级。3.2 载板原理图设计的六个关键检查点载板设计是整个项目里最能体现工程师功力的环节。核心板像是一个标准件谁都能买但载板设计水平直接决定了这套硬件在机器人上能不能稳定运行。我把设计过程中最关键的六个检查点列出来。第一是电源树设计。从机器人主电池进来的电压要先经过一级隔离DCDC再分配给核心板、电机驱动、传感器、通信模块几个支路。每个支路的电流余量至少要留30%特别是核心板供电这一路启动瞬间的电流峰值可能是稳态的2倍电容要有足够的储能。第二是连接器引脚走线的等长控制COM板卡的PCIe、USB3.0这些高速信号走线必须做阻抗匹配差分对等长误差尽量控制在5mil以内这个不过关会导致高速通信时随机丢包。第三是ESD防护所有引到机身外部的接口USB、网口、天线都要加TVS管或者ESD保护器件仓储机器人经常在库房里跑来跑去静电累积严重没有防护的话雷雨天或者干燥季节故障率会直线上升。第四是看门狗和电源管理载板上最好设计一个独立的硬件看门狗电路万一系统死机可以自动重启另外像系统休眠、软关机、电源按键这些功能都要在载板上设计好。第五是信号的上下拉配置COM模块有很多引脚是复用功能的载板上要根据实际使用场景配置好默认电平避免上电瞬间外设误动作比如电机驱动器的使能引脚必须默认拉低不然机器人一上电电机就转起来这在现场是要出安全事故的。第六是调试接口至少留两路调试串口和一路JTAG系统启动出问题的时候这点太救命了我见过很多项目在实验室里好好的一上现场就拉垮如果连调试串口都没预留排查问题会痛苦到怀疑人生。3.3 通信与实时性设计CAN、EtherCAT和5G/Wi-Fi的共存策略仓储机器人对通信的依赖程度非常高既要和调度系统保持实时通信又要和车上的电机驱动器、传感器进行实时交互还要处理大量的图像和点云数据。这些通信链路在物理层和协议层面要互不干扰设计上就得做好规划。运动控制这条链路对实时性要求最高电机驱动器通常走CANopen或者EtherCAT协议。CAN总线的波特率设到500Kbps甚至1Mbps对于大多数AGV场景已经够用了数据量不大但实时性非常高。EtherCAT的优势在于同步性和拓扑灵活性多轴控制时各轴的同步抖动可以控制在微秒级。我这边实际项目里普通的差速驱动AGV用CAN就足够了但四驱或者带液压舵轮的叉车AGV建议直接用EtherCAT同步性不是一个量级的。调度通信链路走Wi-Fi或者5G这个要注意的是天线布局和频段干扰问题。载板上设计天线接口时天线要尽量远离电机驱动器的功率线和CAN总线电磁干扰会导致无线通信的丢包率显著上升。实测经验是天线位置和功率线之间至少保持10厘米以上的距离如果空间实在有限加屏蔽罩是必须的。另外Wi-Fi的频段选择和信道规划也很重要仓库里往往有几十台AGV同时在网2.4GHz频段拥挤不堪尽量用5GHz频段有条件就上Wi-Fi 6。视觉和点云数据的传输链路如果相机是USB3.0接口要注意USB3.0的信号完整性线缆长度控制在1米以内超过的话要加redriver。如果是GigE工业相机走千兆以太网口载板上的网口变压器和PHY芯片布局就变得很关键。每一条链路都有各自的物理层设计要遵守把通信矩阵和物理设计一起规划不然等项目上线了再发现干扰问题改动成本非常高。4. 软件环境搭建与系统适配把COM板卡的性能真正发挥出来4.1 从开发板到量产镜像系统构建的最佳实践很多团队拿到COM板卡的第一反应是直接用厂商提供的开发板SDKUbuntu系统跑起来能出图就开始写业务代码了。这套流程做原型没问题但到量产阶段是完全行不通的。从开发板模式切换到量产模式有几个关键步骤必须走完。第一步是裁剪内核。SOC厂商的SDK默认内核包含了所有外设驱动和大量用不到的模块一个内核镜像可能三四百兆这些东西在量产阶段都是系统开销和安全隐患。要把内核配置精简到只剩这个项目实际用到的功能比如去掉蓝牙协议栈如果设备用不到、去掉不需要的音频驱动、去掉调试接口相关的内核模块。裁剪完之后内存占用能降低10%到15%系统启动时间能快3到5秒这在仓储机器人这种对响应速度有要求的场景里很可观。第二步是系统分区规划。量产系统的eMMC分区一般要有这样几个区域bootloader分区、内核分区、根文件系统分区、用户数据分区、日志分区。日志分区一定要单独划分出来因为仓储机器人跑起来之后系统日志和业务日志量巨大如果日志写满根分区系统会直接卡死。我遇到过日志分区满了导致系统崩溃的现场事故从那之后所有项目的日志分区都做了独立划分和自动轮转。第三步是构建OTA升级通道。AGV产品上线后固件升级是经常的事OTA方案要提前设计好。常用的做法是A/B分区无缝升级系统运行在A分区的时候新版本下载到B分区校验完了之后切换启动分区重启完成升级整个过程业务不中断。COM板卡出厂配置一般都支持这种方案关键是要在系统构建阶段就按这个分区布局来做。4.2 实时性优化让机器人响应不再慢半拍仓储机器人的运动控制对系统实时性有硬性要求尤其是安全相关的逻辑比如急停响应、避障检测这些必须在确定的毫秒级时间内完成。标准的Linux发行版在这个场景下表现是不合格的必须做实时性改造。目前主流的做法有两种。一种是用PREEMPT_RT补丁把Linux内核变成实时内核这种方案实现成本低社区支持好时效性可以做到几百微秒到毫秒级对大多数AGV应用已经足够。另一种是引入独立的MCU来承担硬实时任务COM板卡上的Linux系统只负责非实时的业务逻辑电机控制、安全逻辑、IO响应这些全部下放到MCU侧通过SPI或UART和主控通信。我更加推荐第二种方案虽然硬件上多了一颗MCU的成本但系统的稳定性和安全性上了一个台阶。原因很简单Linux再怎么做实时优化也还是一个分时操作系统一旦发生OOM或者内核panic系统就是不可控的。有独立MCU兜底即使主控完全死机机器人的急停和碰撞检测功能依然能正常工作这是安全等级要求的底线。实际项目中我用的是STM32系列的MCU做运动控制和IO逻辑主控通过一个高速串口和MCU通信这套架构在多个项目中验证下来非常稳定。4.3 容器化部署与远程运维提升开发效率的隐藏技巧当我第一次在AGV的COM板卡上跑Docker容器时团队里不少人有顾虑觉得在嵌入式设备上引入容器会不会太消耗资源。但实际用下来容器化的收益远大于那一点点性能损耗尤其是对产线部署和远程运维来说。容器化带来的最直接的改变是软件部署变成了一键操作。传统的嵌入式开发流程里更新一个应用软件就要重新烧写整个eMMC镜像几台还好几十台机器人同时要更新软件光烧录就要花掉大半天时间。用Docker之后业务应用全部打包成镜像推送到仓库机器人端拉取镜像切换版本整个过程可以在十分钟内完成。另一个我特别看重的点是环境隔离。仓储机器人的软件开发通常会分成导航组、视觉组、上层业务组几个组在开发阶段经常用到的依赖库版本不一致在裸机上部署就会互相冲突。容器化之后每个模块跑在各自的容器里依赖隔离得干干净净版本升级互不影响。资源开销方面容器本身只占用几十兆内存和少量CPU在8GB内存的板卡上跑四五个业务容器完全没压力。远程运维这块也方便了非常多。AGV在客户现场出了问题传统做法是工程师出差到现场接串口排查来回一趟成本极高。配合容器化部署和远程SSH通道大部分软件问题都能远程定位解决。不过这里有一个注意点远程通道的安全加固要做好密钥认证、最小权限、操作审计这些一个都不能少仓储客户对数据安全的要求都很高。5. 整机联调与现场部署从实验室到仓库的最后一公里5.1 实验室验证清单在进现场之前把问题拦下来无论COM板卡选得有多好载板设计得有多完善最终都要到整机上去验证。这个环节如果做得粗糙问题带到客户现场代价会成倍放大。我整理了一份自己在每个项目量产前都要走完的实验室验证清单分享出来供参考。第一项是长时间压力测试。机器人整机在满载状态下连续运行至少72小时过程中要同时跑导航算法、视觉识别、运动控制和通信交互重点观察板卡温度、系统内存占用、CPU占用率和进程稳定性。我这边一个项目曾经在第60小时左右出现内存缓慢泄漏的迹象内存占用从3GB慢慢升到7GB差点就要上线了幸好压力测试跑得久才暴露出来。第二项是断电和上下电冲击测试。模拟现场充电桩反复接通和断开的场景验证系统在异常断电后能正常启动文件系统不会损坏这个测试要跑至少200个循环部分供电设计有缺陷的板卡会在30个循环以内就出问题。第三项是EMC电磁兼容预测试。仓库现场环境比较复杂电机驱动器启停瞬间会产生较大的电磁干扰整机要在实验室测一下辐射发射和传导发射的余量如果你的设计里天线离功率线太近在EMC测试阶段就容易暴露出来。第四项是整机功耗测试。用功率计记录机器人在待机、空载行驶、满载搬运、充电等各个状态下的整机功耗跟电池容量和充电策略做匹配分析判断充电频次是否满足客户一个班次的运行时长需求。5.2 现场部署的三大教训部署比设计更容易翻车就算实验室测试全过了到客户现场还是会遇到各种意料之外的问题这是行业常态。我分享三个自己在仓储项目现场踩过的坑和对应的解决思路。第一个坑是网络环境的兼容性问题。实验室里用的是开发部门的Wi-Fi路由器现场用的是客户仓库的工业无线AP认证方式、VLAN划分、IP分配策略完全不一样。COM板卡上的Wi-Fi模块和系统网络管理器如果配置不当在切换网络环境后会出现断网重连失败的情况。解决方法是提前跟客户拿到现场网络的技术参数在实验室搭一套模拟环境提前适配同时系统里配置好网络自动重连与断线重启机制双保险。第二个坑是地图构建与场地变化的匹配。AGV在部署现场的第一件事通常是构建地图但仓库是动态环境货架位置会变地面可能新增临时堆放区域这会导致建好的地图失效。COM板卡的算力足够的情况下建议直接用带有动态障碍物检测能力的SLAM方案激光雷达的数据叠加上视觉信息就算地图局部过期机器人也能根据实时感知绕开变化区域。第三个坑是售后维护的可操作性。仓储现场的AGV数量多、分布散出问题的时候运维人员可能连不上板卡。我在所有交付项目里都会做一件事情就是在载板上预留一个物理维护按键和状态指示灯长按按键进入维护模式系统会自动开启SSH服务并播报设备当前IP地址。这个设计在后期维护中帮了很大的忙现场人员不用拿电脑挨个扫IP按一下就知道该连哪台设备。5.3 从单机到集群调度系统对机器人计算平台的新要求智能仓储项目里机器人从来都不是单机作战而是几十台甚至上百台组成一个集群由中央调度系统统一管理。这个集群化的运行方式对每台机器人上的COM计算平台提出了很多单机时代没有的要求。首先是任务上下文的频繁切换。中央调度系统会给每台AGV分配不同的任务从取货到搬运再到放货流程不断切换这就要求机器人本地软件架构具备良好的任务编排能力。本地系统要能快速响应调度指令、暂停当前任务、切换执行新任务同时保持导航、避障、通信这些基础服务不中断。COM板卡的多核架构在这里很有优势可以把导航、业务逻辑、通信各分配到不同的核心上逻辑上彼此独立一个任务卡住不会影响其他模块。其次是对多机通信的支撑。几十台机器人在同一张Wi-Fi网络上工作数据信道会变得异常拥挤。除了网络基础设施本身的规划机器人端的通信模块也要做优化比如采用MQTT协议进行指令消息的发布订阅、实现断线重连和消息重发机制、对通信数据进行压缩传输。COM板卡的以太网接口如果有双网口设计可以一个接Wi-Fi桥接用于调度通信一个接有线以太网用于维护调试逻辑隔离也让排障更加方便。最后是数据采集与上报。集群运维需要每台机器人上报大量的运行状态数据包括位置信息、电池电量、任务状态、故障码、传感器数据。这些数据如果都实时上报对通信带宽的压力非常大。一个实用的做法是在机器人本地做边缘计算状态数据在本地先做聚合和过滤只上报关键事件和周期性摘要遇到异常情况再全量上传详细日志。COM板卡的算力对付这种轻量级边缘计算任务非常轻松同时也有效保护了整个集群的通信资源。6. 常见问题与排查技巧实录6.1 启动失败类问题速查COM板卡上电后没反应或者启动过程中卡住是现场反馈量最大的一类问题。我整理了排查优先级最高的几个方向。首先是确认电源是否真正到达了核心板。很多人上来就怀疑板卡坏了其实很多时候是载板的供电电路出了问题。先用万用表测量核心板连接器上的各路电源电压是否在规格范围内尤其是3.3V、5V、VCC_CPU这样的关键电源轨再检查上电时序是否符合COM模块的要求有些SoC对电源轨的上电顺序有严格要求先上后上的顺序搞反了系统就无法启动。其次是确认bootloader是否正常启动接上调试串口看启动日志如果串口完全没输出大概率是bootloader所在的启动介质损坏或者引导配置被改坏了。如果bootloader起来但内核没起来多半是设备树配置跟载板实际硬件不匹配导致的比如DRAM配置错误、某个外设的地址冲突、设备树的GPIO复用配置有误。最后确认根文件系统的完整性尤其是在经历过异常断电之后文件系统损坏导致启动卡在挂载根分区的场景非常常见量产镜像做只读根分区或者带自动修复机制的方案都有必要评估。6.2 通信异常类问题排查通信问题分两类一类是通信完全不通另一类是通信时好时坏。完全不通的问题相对好排查按物理层到协议层的顺序来。先用示波器量通信接口的波形比如CAN总线看差分信号的幅值和电平网口看差分对的信号质量和link状态。如果物理层正常就检查协议配置CAN的波特率、终端的匹配电阻、以太网的IP和子网掩码、串口的波特率数据位停止位这些配置错一个都会导致通信失败。时好时坏的问题就比较考验耐心了通常指向三个方向一是信号完整性相关的硬件设计问题比如差分线间距不够、阻抗不匹配、连接器虚焊二是电源纹波对通信接口的影响电机启动瞬间总线电压跌落会导致通信瞬间异常三是软件层面的资源竞争比如多个线程同时访问同一个串口设备导致数据互相覆盖。排查这类问题的时候习惯性的做法是先抓现场日志把异常时刻的通信数据和系统日志关联起来分析比盲目改硬件设计高效得多。6.3 散热与降频问题排查有个项目现场反馈机器人运行一段时间后导航精度明显下降排查到最后发现是主控SoC因为温度过高触发了降频保护。仓储机器人车体内部是一个封闭空间COM板卡和电机驱动器、电池安装在一起热量散不出去芯片温度一高SoC自动降低运行频率来控制发热算力下降之后SLAM算法的计算延迟变大导航精度自然就受了影响。这类问题的解决思路是多管齐下。先看散热设计是否合理COM板卡的CPU散热器有没有和车体的金属结构件形成导热路径导热垫的厚度和导热系数选型是否正确风道设计能不能形成有效的气流循环。再看负载分配是否均衡是不是业务模块把CPU某个核心的负载拉满了其他核心却闲着这种时候可以通过调整线程的CPU亲和性把负载分散到多个核心上。最后看软件层面的功耗管控比如把非关键任务的调度优先级降下来、在空闲时主动让SoC进入低功耗状态、动态调整视觉算法的分辨率或帧率来平衡算力消耗。解决好散热问题降频自然就消失了。6.4 避坑技巧与注意事项总结最后把我这几年在COM板卡和仓储机器人项目里踩过的坑和积累的经验梳理成几条避坑指南。第一选型阶段不要只盯着CPU性能参数要重点考察板卡厂商的技术支持和供货能力。COM板卡是长期供货的工业级产品厂商如果能提供至少五到七年的供货保证产品在客户现场的生命周期管理会轻松很多。第二载板设计的过程中至少要留出20%的GPIO余量不要把所有引脚都规划满。仓储机器人的功能需求变化非常快客户今天说要加个货架检测传感器明天说要加个语音播报模块没有余量就要改版。第三系统软件层面一定要有完整的日志记录设计日志的等级要能动态调整日志内容要包含时间戳和模块标识日志文件的持久化和轮转机制要提前做好。第四别跳过环境可靠性测试环节高温高湿、低温启动、盐雾、振动这些测试都要做现场运行一年以后才会看到环境测试的回报不做这些测试的产品在恶劣环境下故障率会成倍增加。第五产品交付的时候除了使用手册外至少给客户配套一份故障排查手册把启动异常、通信异常、定位漂移这些典型问题的初步排查步骤写清楚很多时候客户现场的基础运维就能搞定的事情就不需要厂家派人出差了。