本文基于早期工程咨询资料做公开化重构。客户身份、项目编号、商务金额、现场布局和私有接口均已删除，参数改为通用样机建议值。内容用于说明同类转运机器人从需求定义到样机验收的技术路径，不代表任何客户项目的完整交付记录。

1. 项目背景与需求回顾

室内转运机器人经常被简化成“底盘加导航”，真正落地却要同时处理载荷、地面、通道、人车混行、定位漂移、任务排队、自动充电和异常恢复。只要其中一环没有定义清楚，样机就可能出现空载导航正常、加上货架后制动距离变长，或在玻璃、强光和重复走廊中定位不稳定等问题。

本方案把需求整理为一台面向工厂、仓储、实验室和楼宇内部的低速 AMR。机器人接收上位系统任务后到指定站点取放物料，沿地图自主行驶，遇到人员或障碍物分级减速与停车，电量不足时返回充电桩。一期目标是完成可运行样机和 ROS 应用层闭环，不把电梯联动、多楼层调度和无人叉取作为默认范围。

2. 需求工程化整理

需求应先分成车体能力、导航环境、业务流程和安全边界四组。车体能力包含有效载荷、台面尺寸、整机高度、速度、坡度、续航和转弯空间；导航环境包含地面材质、通道宽度、玻璃面积、动态人流与无线网络；业务流程包含任务来源、站点编号、装卸确认、优先级和取消机制；安全边界包含急停、触边、激光防护区、声光提示和人工接管。

样机建议采用平面承载台，载荷目标按 80–250 kg 分档。差速双驱适合通道清晰、转弯空间充足的场景；双舵轮或四轮独立转向适合重载和狭窄工位，但控制、标定与成本明显增加。若物料必须自动交接，可在上层增加滚筒、顶升、牵引或机械接口，并把交接互锁独立验收。

3. 技术指标与边界

4. 系统总体架构

flowchart TD

  WMS["MES/WMS/业务系统"] --> FLEET["任务与车队调度"]

  FLEET --> NAV["ROS导航与行为树"]

  NAV --> LOC["激光SLAM/轮速/IMU定位"]

  NAV --> MOTION["运动控制器"]

  MOTION --> DRIVE["驱动轮/编码器/制动"]

  SAFE["安全激光/触边/急停"] --> SAFETY["独立安全链路"]

  SAFETY --> MOTION

  BMS["电池/BMS/充电桩"] --> POWER["电源管理"]

  POWER --> NAV

  POWER --> MOTION

机器人内部采用“计算层、实时控制层、安全层”分离。工控机或嵌入式计算平台运行 Ubuntu、ROS 2、定位、规划和任务状态机；STM32 或专用运动控制器以固定周期完成轮速闭环、电机使能、里程计和 IO；急停、触边和安全激光的停车输出尽量不依赖上层 Linux 进程，避免软件卡顿时仍保持驱动。

5. 机械结构与底盘方案

底盘采用钢板焊接或铝型材加钣金骨架。驱动轮靠近整机重心，两侧或四角布置万向支撑轮，电池放在低位并支持抽拉维护。承载台与车架之间留出称重、顶升或滚筒扩展位置，外壳分为快拆检修板和碰撞防护区。激光雷达安装高度既要看见低矮障碍物，也要避免被上层货物遮挡；必要时前后各一只安全激光，导航雷达单独布置。

设计阶段必须用满载、偏载和紧急制动三种工况校核车架。轮胎材质根据环氧地坪、瓷砖或水泥地选择，聚氨酯轮安静且耐磨，但在粉尘或水膜上附着力下降。门槛与地缝不能只看高度，还要看轮径、轴距和底盘离地间隙。线束走独立线槽，动力线、编码器线和网络线分开，转动与抽拉位置使用拖链或耐弯线。

6. 电气与硬件系统

电源链路由电池包、BMS、总保险、接触器、预充、DC/DC 和分路保护组成。48 V 系统适合较高载荷，24 V 系统便于小型平台选型。计算平台、雷达和网络设备由隔离或宽压 DC/DC 供电，电机驱动单独分路。充电口配置防反接、温度检测和充电使能，自动充电时由机器人与充电桩双向确认接触状态后再上电。

运动控制器采集左右轮编码器、驱动器故障、触边、急停、上装到位和充电状态，并通过 CANopen、EtherCAT 或 RS485 与驱动器通信。上层计算平台可选 x86 工控机或 Jetson/国产 ARM 计算模块。2D 激光雷达用于地图与定位，IMU 改善短时运动估计，深度相机用于低矮或悬空障碍补盲。所有外部接口配置 ESD、浪涌和极性保护。

安全设计采用分级减速区与保护停车区。人员进入预警区时限制速度，进入保护区立即停车；触边和急停直接切断驱动使能。恢复运行不能只凭障碍物消失，需根据场景选择自动延时恢复或人工确认。机器人同时提供蜂鸣器、方向灯和状态灯，但灯光提示不能替代物理安全链路。

7. ROS软件、调度与协议

软件建议使用 ROS 2，节点按传感器驱动、定位、地图、规划、底盘接口、任务执行、诊断和远程维护拆分。Nav2 负责全局与局部规划，AMCL 或图优化定位负责地图匹配，robot_localization 融合轮速和 IMU。任务层使用行为树或显式状态机，确保“前往取货点、等待装载、确认、前往卸货点、完成、回充”等步骤可暂停、取消与重试。

stateDiagram-v2

  [*] --> SelfCheck

  SelfCheck --> Idle: ready

  Idle --> NavigatePickup: task_received

  NavigatePickup --> WaitLoad: arrived

  WaitLoad --> NavigateDropoff: load_confirmed

  NavigateDropoff --> WaitUnload: arrived

  WaitUnload --> Idle: unload_confirmed

  Idle --> AutoCharge: low_soc

  AutoCharge --> Idle: charge_complete

  NavigatePickup --> SafeStop: obstacle_or_fault

  NavigateDropoff --> SafeStop: obstacle_or_fault

  SafeStop --> Recover: condition_cleared

  Recover --> Idle: task_replanned

调度接口应使用任务 ID 保证幂等。下发字段包含机器人、起点、终点、载荷类型、优先级、超时和回调地址；机器人上报当前位姿、SOC、运行模式、任务步骤、故障码和预计完成时间。网络中断时机器人不应盲目继续未知任务，可完成当前安全动作后停车或回到等待点，并在恢复连接后与调度端对账。

{

  "task_id": "T-20260914-001",

  "type": "material_transfer",

  "pickup": "STATION-A",

  "dropoff": "STATION-B",

  "priority": 5,

  "timeout_s": 900

}

8. 测试、验收与异常注入

异常注入至少覆盖雷达掉线、编码器异常、驱动器报警、BMS 低电、急停按下、触边、充电失败、定位丢失和任务取消。每类异常都要有明确故障码、操作提示和恢复权限，不能只在日志里打印一行错误。

9. 项目阶段与交付物

团队通常包括项目经理、机械工程师、电气工程师、嵌入式工程师、ROS 工程师、后端/调度工程师和测试工程师。基础单车样机约 10–12 周；增加自动上下料、车队调度或电梯门禁联动后，应单独安排接口联调周期。

10. 风险与产品化方向

主要风险不是“算法能否跑起来”，而是地图变化、轮胎打滑、载荷重心、无线覆盖、安全责任和维护流程。POC 阶段应先跑真实路线，不用实验室空场结果代替现场验证。产品化阶段可加入 UWB/视觉辅助定位、数字孪生调度、地图版本管理、远程诊断、OTA 灰度发布和多车交通管制。初拓可承担底盘结构、电气控制、嵌入式、ROS 导航、业务接口、样机装配及现场验收闭环。

11. 现场数据采集、参数标定与运维设计

项目启动时应形成场地数据包，而不是只拿一张平面图。数据包包括通道净宽、转角、门槛与地缝、坡度、地面摩擦情况、玻璃与镜面位置、常见动态障碍、无线信号强度、取放站点高度和消防疏散边界。地图绘制后要标记禁止区、低速区、单行区、会车区、临时等待点和人工接管点。若现场会频繁移动货架，应把可变区域与固定定位特征分开，避免地图维护成为长期隐患。

底盘标定从轮径、轮距和编码器方向开始。机器人沿直线运行并测量实际距离，再执行原地旋转与闭环路径，修正系统性误差；IMU 完成零偏、安装方向和温漂检查；激光雷达确认安装角度、扫描盲区与时间戳。满载后重新测量加速、制动和转弯，因为轮胎变形与重心变化会改变模型。参数修改应记录版本、操作者、测试路线和结果，不能在现场反复“凭感觉调到能跑”。

导航参数按速度区间分别调试。低速对接关注局部规划抖动、最小速度和停止精度；常规运输关注路径跟随、人员避让与效率；最大速度只在封闭区域验证。对窄门和对接站可配置专用行为：提前降速、切换定位源、限制横向误差、确认站点传感器，再进入机械交接。无法可靠识别的悬空障碍、透明门和黑色吸光物，需要深度相机、超声或物理改造补充。

运维端至少提供实时传感器状态、地图版本、任务队列、里程、轮胎与电池维护计数、故障码和日志导出。日志采用本地环形存储，包含任务 ID、状态变化、关键传感器、定位质量和故障前后若干秒信息。远程维护只开放必要端口，使用分级账号与操作审计；固件和地图升级先在测试车验证，再灰度到现场设备。备件建议覆盖驱动轮、支撑轮、触边、保险、充电触点和常用传感器，并给出不依赖开发人员的更换与校准步骤。

验收完成后还要明确运行责任：谁创建站点、谁能恢复急停、地图变化由谁确认、故障机器人如何拖离通道、网络中断采用什么策略。将这些操作写进班前检查表，包括外观、轮胎、急停、触边、雷达清洁、电量与充电桩周边。只有把日常维护纳入设计，AMR 才能从“能演示的样机”变成可持续运行的设备。

12. 故障模式与验收资料闭环

设计冻结前建立故障模式表，把风险落实到可检测、可保护和可恢复的动作。定位质量下降时限制速度并寻找重定位点；轮速偏差持续超限时停止任务；BMS 通信丢失时不得按旧电量继续运行；上装没有给出装载完成信号时，机器人保持等待。急停与触边通常要求现场确认，短时网络抖动则可在任务对账后自动恢复。

验收包包含冻结需求、场地图与禁行区、软硬件版本、参数清单、接口协议、原始测试记录、问题关闭表和备份恢复方法。每个指标都记录载荷、地面和速度条件，不只保留脱离场景的结果。交付时导出地图、站点、机器人参数与调度配置，并在备用设备上演练恢复。这样轮胎、电池或计算平台更换后，仍能用同一基线判断性能是否退化。

上线后的首月建议按周复盘一次急停、人工接管、定位恢复和任务超时。将高频故障对应到具体地图区域、载荷和时段，再决定修改参数、现场环境或业务流程。若只不断放宽避障和定位阈值，短期看似减少报警，实际会削弱安全与可追溯性。