智能叉车的调度逻辑，看起来是一套规则，实际上是一份现场经验的积累。每一个配置项的背后，往往对应着某个真实项目里遇到过的问题；每一次功能迭代，也都有具体的现场案例作为推动力。这篇文章以作业流程为主线，逐一拆解各关键功能的设计逻辑——它从哪里来、解决了什么问题、当前的实现是什么。

行走高度的调整

叉车从停靠点出发，货叉需要调整至合适的行走高度。行走高度不能为零，也不能过高，受以下约束：

1. 空载时货叉高度为零，会遮挡叉车后视侧的激光传感器，自身避障失效；同时其他叉车的激光也扫描不到它，双向感知均受影响；

2. 载货时货叉高度为零意味着货物直接贴地，无法正常行驶；

3. 行走高度过高时，载货重心偏高，稳定性下降；部分现场天花板低，高位行走存在碰撞风险。

行走过程中货叉高度的调整方向分两种：

1. 调低：取货后货叉处于高位，行走过程中需降至安全高度；

2. 调高：部分场景下叉齿识别需要货叉抬至特定高度，否则传感器扫描不到，例如叉车从停靠点出发时货叉处于低位，需边走边升至识别高度。

现场常见的三类情况及对应处理方式：

1. 场景无限制：配置机器人组的空载/载货行走高度即可，系统自动在合适点位调整；

2. 只能在前置点调整：需创建在前置点升降的运单步骤，由业务层控制货叉高度，调度层不介入；

3. 对节拍要求高、需提前升降：开启边走边升降，配置取/放货前提前升降距离，详见下节。

空载和载货对行走高度的约束不同，因此需要独立配置。早期版本只有一个行走高度参数，在需要区分两种状态的项目中无法满足需求。6.4.2版本将其拆分为空载行走高度和载货行走高度，默认值均为0.1m。

边走边升降：从单一配置到分场景独立控制

在引入边走边升降之前，叉车到达前置点后需停车等待货叉升降到目标高度，再执行取放货。前置点的停车等待是固定的效率损耗，在节拍要求高的项目中尤为突出。现场反馈：人工操作时，司机在行进途中就开始升叉，到达前置点时货叉基本已到位。这个反馈推动了边走边升降功能的开发。

边走边升降包含两个子场景：

1. 边走边升降至行走高度：取放货完成后，叉车在行进中同步将货叉调整至行走高度，无需停在前置点等待调整完成再走；

2. 取（放）货前提前升降至取放货高度：需同时开启对应边走边升降开关，且配置提前升降距离 > 0m。叉车从距前置点该距离处开始边走边升叉，目标是到达前置点时货叉已调整到位，消除在前置点升降货叉的等待时间。注意：即使提前调好，叉车到前置点仍需停下执行旋转、识别等动作。

两个子场景叠加时，若某段路径同时满足"需要边走边降至行走高度"和"需要提前升至取放货高度"，优先执行后者。

早期版本只有一个"边走边升降"配置项，空载和载货共用。实际项目中发现二者需求不同：

1. 空载时货叉轻、重心低，边走边升降风险可控；

2. 载货时（尤其重货、高位）边走边升降会提升重心，稳定性风险上升，部分客户要求在载货状态下关闭。

因此后来我们将配置项拆分为空载时边走边升降和载货时边走边升降，支持独立开关。

提前升降距离的理论计算公式：距离 = (目标高度 - 当前高度) / 货叉升降速度 × 叉车行进速度。目标货架层数越高、叉车速度越快，所需提前距离越大。该参数目前由现场实测后手动配置。

以一次取货任务为例（空载行走高度0.1m，取货start_height 2.2m，提前升降距离12m）：

• 未开启边走边升降：叉车离开停靠点后，在离开起点路段后的某个点位停下，原地调整至0.1m，保持该高度行驶至前置点，在前置点原地升叉至2.2m，再进入库位取货；

• 开启空载边走边升降、提前升降距离12m：叉车行进中同步将货叉调整至0.1m；在距库位12m处开始边走边升叉至2.2m；到达前置点时货叉已基本到位，完成最终确认后进入库位取货。

前置点：从严格限制到自动识别

货架上有横梁。堆高叉车在二层及以上取放货，如果直接在库位升降货叉，货叉会撞到横梁。前置点的存在是物理约束，不是可选设计。叉车必须在进入货架前的安全位置完成货叉高度调整，再水平插入库位。

早期对前置点有严格限制：

1. 每个库位有且只能有一个前置点；

2. 前置点必须是LM点。

在复杂项目中这两个限制频繁出问题：部分库位可从两个方向进入，需要两个前置点；密集存储巷道中AP点两两直连，中间没有LM点，无法按规范建图。限制导致建图工作量大，且很多现场布局无法适配。

因此我们取消了数量和类型的限制，调度系统自动识别规划前置点。M4不要求在地图里单独配置前置点，也不要求前置点必须是LM点；一个库位可以有多个前置点。对于密集存储巷道，同一巷道内多个库位共用一个前置点，叉车在巷道入口完成货叉调整后依次进入各目标库位。

取货：有识别与无识别两种流程

叉车到达前置点后，根据是否需要识别，取货流程分为两类。

无识别取货

货叉升至start_height后直接插入托盘，抬升至end_height完成取货。以取货高度2.2m、离架高度2.3m为例：

1. 叉车到达前置点，货叉升至start_height 2.2m；

2. 叉车移动至库位，货叉插入托盘；

3. 货叉抬升至end_height 2.3m，托盘脱离货架，取货完成。
   
   

有识别取货

识别的目的是获取货物的实际位置，修正人工摆放导致的水平偏差、角度偏差，少数情况下修正垂直方向偏差。根据rec_height的配置不同，分三种情况：

1. 不传**rec_height**：货叉升至start_height后执行识别，识别完成后直接以start_height高度插入托盘，不根据识别结果调整货叉高度，再抬升至end_height完成取货；

2. rec_height >= 0：货叉先升至start_height，再升至指定的rec_height执行识别，以rec_height高度插入托盘，再抬升至end_height完成取货；

3. rec_height = -1：货叉升至start_height执行识别，根据识别结果动态计算实际取货高度（识别高度 + 当前货叉高度），调整至该高度后插入托盘，再抬升至end_height完成取货。此配置适用于货物摆放高度存在较大不确定性的场景。

三种情况下，end_height的逻辑相同：均为货物抬离货架后货叉的最终高度，确保托盘完全脱离横梁。

取货完成的时机

取货步骤结束有两个候选时机：A、货叉将货物抬起，货物脱离货架；B、叉车退回前置点。

早期采用方案B。运行中发现：叉车退回前置点的过程中持续占用货架巷道，调度系统等待该步骤完成才能下发后续指令，主干道占用时间长，任务衔接存在等待空档。

改为方案A后：

1. 货物抬起即视为取货完成，调度系统立即开始规划后续动作；

2. 叉车退出巷道的路径可根据下一任务目标灵活选择，不强制返回原前置点；

3. 叉车在库位等待下一指令，而非停在前置点堵塞主干道。

放货步骤同理，放货完成时机定为货叉降至end_height脱离托盘的时刻。

放货流程

放货流程相对固定，不涉及识别。叉车载货到达放货前置点后：

1. 货叉升至start_height，该高度略高于目标层横梁，确保托盘能顺利推入货架；

2. 叉车移动至库位，将托盘水平推入目标位置；

3. 货叉下降至end_height，托盘落在横梁上，货叉脱离托盘，放货完成。

以放货高度2.2m为例：叉车载货到达前置点，货叉升至start_height 2.3m，移动至库位将托盘推入，货叉降至end_height 2.2m，托盘落下，叉车退出。

放货时start_height高于end_height，与取货时方向相反——取货是从低到高抬起货物，放货是从高到低放下货物。

前往下一目标：货叉需要先降到行走高度吗？

早期逻辑：完成取放货→退回前置点→降至行走高度→行驶→升至取放货高度。每次均执行完整流程。

在连续运行项目中发现，大量任务集中在同一列或相邻列货架间取放货。此时降叉再升叉是方向相反的两个多余动作。针对此问题，引入智能货叉高度调整：

1. 同一列不同层取放货（如2层取、3层放）：退出货架后，直接从取货高度调整至放货start_height，不降至行走高度；

2. 相邻列取放货：若从当前点到下一目标点的距离小于"提前升降距离"配置值，保持当前高度直接移动，跳过降叉再升叉；若货叉高度超过"货叉最大安全高度"配置值，则降至该安全高度（而非行走高度）后移动。

边走边升降：从现场需求到功能设计

早期版本：叉车到达前置点后停下，等待货叉升降至目标高度，再执行取放货。前置点的等待时间是明确的效率瓶颈，在节拍要求高的项目中尤为突出。

现场反馈：人工操作时，司机在行进途中即开始升叉，到达前置点时货叉基本已调整到位。这个反馈推动了边走边升降功能的开发。

早期只有一个"边走边升降"配置项。实际项目中发现空载和载货对边走边升降的需求不同：

1. 空载时货叉轻，边走边升降风险低，可以开启；

2. 载货时（尤其是重货、高位）边走边升降会提高重心，稳定性风险上升，部分客户要求关闭。

因此6.5.1版本将配置项拆分为空载时边走边升降和载货时边走边升降，支持独立开关。

边走边升降包含两个阶段：

1. 边走边升降至行走高度：离开取放货位置后，在行进中同步将货叉调整至行走高度，而非停在前置点等待调整完成再走；

2. 取（放）货前提前升降至取放货高度：需同时开启对应边走边升降开关，且配置提前升降距离 > 0m。系统从距前置点该距离处开始边走边抬升货叉，目标是到达前置点时货叉已调整到位。

提前升降距离的理论计算公式：距离 = (目标高度 - 当前高度) / 货叉升降速度 × 叉车行进速度。目标高度越高、叉车速度越快，所需距离越大。该参数目前由现场实测后手动配置，系统暂不自动估算。

注意：路径中如有旋转动作，货叉调整指令从旋转完成后的路径段开始下发，避免旋转过程中调整货叉。

故障处理

叉车取放货分为两个阶段：

• 第一阶段：前置点至库位的移动及库位取放货动作；

• 第二阶段：库位退回前置点的移动。

两个阶段的故障恢复方式不同：

1. 第一阶段故障（如取放货失败）：需先将货物恢复至动作开始前的状态，再执行故障重试。调度系统自动规划叉车退回前置点，无需人工移车；

2. 第二阶段故障（叉车停在退回路径上）：直接执行故障重试，叉车自行完成剩余退回动作。

风险最高的区域是前置点与库位之间的路径段——货叉处于高位，通道空间受限。叉车停在此处时，无论是等待还是恢复操作，均需严格按流程处理。

取货后任务被取消、货物仍在叉上的情况，系统触发"已取货未放货"异常处理流程，支持三种处理方式：

1. 自动送回原库位；

2. 自动送至预设异常存储区；

3. 人工指定目标库位。

三种方式均支持中途切换为人工处理，系统持续告警直至货物处置完成。

这些功能还在持续迭代

从行走高度的拆分配置，到边走边升降的分场景控制，再到前置点限制的放开、取放货时机的重新定义——每一处设计调整背后，都是真实项目的现场反馈在推动迭代。叉车调度看起来是一套固定的规则，但每个新场景都可能提出新的问题，推动这套规则继续演进。

如果你在实际使用中遇到问题或有想法，欢迎邮件给我们：m4@seer-robotics.ai。