Files
FT542-WCS/.trae/documents/实现“调度阻挡车避让”的优化方案.md
2026-01-07 13:30:08 +08:00

2.5 KiB
Raw Permalink Blame History

优化避让策略:优先调度阻挡车避让

针对您提出的 "让B小车(障碍物)避让" 的合理建议,我设计了如下优化后的调度逻辑。新逻辑将优先尝试移开挡路车,只有在无法移开时才让当前车自己避让。

核心逻辑流程

当小车 A (当前调度车辆) 路径规划失败时,按以下步骤处理:

  1. 识别阻挡者 (Find Blocker)

    • 构建一张纯净的静态地图 (忽略所有小车位置)。
    • 在静态地图上为 A 规划一条理想路径。
    • 沿着理想路径检查,找到第一辆占据路径的小车 B。
  2. 判断阻挡者状态 (Check Blocker Status)

    • 如果 B 正在执行任务 (Busy):
      • 说明 B 只是暂时路过或正在工作。
      • 策略:A 小车暂时等待 (本次不生成指令),等待 B 自行移开。
    • 如果 B 空闲 (Idle):
      • 说明 B 停在路上挡住了 A。
      • 策略:调度 B 去避让。
  3. 执行避让调度 (Execute Avoidance)

    • 场景 1:调度 B 避让 (优先)
      • 为 B 寻找一个最近的避让点 (Cache Point)。
      • 关键条件:避让点不能在 A 的理想路径上 (防止 B 躲到 A 的下一步去)。
      • 生成一条给 B 的移动任务 (点到点移动)。
      • A 小车保持等待,直到 B 移开。
    • 场景 2:A 自己避让 (兜底)
      • 如果 B 无法移动 (例如 B 也被堵死,或找不到合适的避让点),则回退到原有的逻辑:A 自己去避让点,并在之后生成后续任务回来。

代码实现计划

将在 BaseSRgvThread.java 中现有的避让逻辑前插入新的判断块:

  1. 新增 helper 方法:
    • getStaticMap(): 获取不含动态障碍物的地图。
    • isAgvIdle(String agvCode): 检查某小车是否空闲。
  2. 修改 sendPointToPointTask:
    • 在路径规划失败后,先执行 "寻找阻挡车并调度其避让" 的逻辑。
    • 如果成功调度了 B,则 return false (结束本次 A 的调度)。
    • 如果未成功,则继续执行原有的 "A 去避让" 逻辑。

预期效果

  • 更智能:不再傻傻地让正在干活的车去绕路,而是把闲置的挡路车移开。
  • 防止死锁:通过主动疏通路径,减少多车拥堵的概率。
  • 兼容性:保留了原有的 A 避让逻辑作为兜底方案,确保任何情况下都有路可走。