帮助中心
帮助中心主页
API
TCP/IP API
机器人状态API
实现调度

1. 信道

本协议涉及两类通信信道

1.1 请求应答信道

机器人做 TCP 服务端,调度做 TCP 客户端。调度串行发送任务,机器人应答。串行的意思是,调度在发出并收到响应前,不会发送下一条任务。

1.2 机器人数据上报信道

机器人做 TCP 服务端,调度做 TCP 客户端。当调度通过此信道连接到机器人时,机器人即按照指定的频率,主动向调度推送机器人的数据和状态。

2. 通信协议

2.1 下发导航任务给机器人

端口:19206。此端口属于请求应答信道。

API编号:3066

2.2 查询导航任务的状态

端口:19204。此端口属于请求应答信道。

请求编号: 1110

2.3 控制权

获取和释放机器人控制权,在端口: 19207,该端口属于请求应答信道。

获取控制权

请求编号:4005

释放控制权

请求编号:4006

查询机器人控制权,在端口:19204,该端口属于请求应答信道。

请求编号:1060

2.4 机器人运行时主动上传数据

端口: 19301,该端口属于主动上报信道。

调度连接机器人该端口时,该端口就会开始自动上传机器人运行时的数据和状态。

响应编号:19301

2.5 配置机器人主动上报数据的频率和内容

端口: 19207,该端口属于请求应答信道。

关于 2.4 节,机器人上报的字段列表,如果请求中带有 excluded_fields**,则排除列表中的字段;否则,如果请求中带有 **included_fields,则只上报这些字段;否则,上报默认字段。

在19301端口,上报的默认频率是 10Hz,即 100ms 上报一次。

注意: include_fieldsexclude_fields 不可以同时设置

设置当前连接

请求编号:9300

设置全局

请求编号:4091

针对当前连接注意优先级:设置当前连接 > 设置全局

2.6 暂停和继续

端口:19206,该端口属于请求应答信道。

使用 "暂停(3001)" 和 "继续(3002)" 来控制机器人暂停和继续任务。

2.7 清除错误

端口:19207,该端口属于请求应答信道。

请求编号:4009

使用该端口,可以清除机器人当前所有错误状态。注意,对于实际上未恢复的错误或故障,清除后将再次出现。

2.8 取消任务

端口:19206,该端口属于请求应答信道。

请求编号:3067

取消当前正在执行的任务,以及 "已经下发,但机器人尚未执行" 的后续任务。

3. 通信逻辑

3.1 常规任务流程

常规流程下,机器人满足如下条件,调度可以下发"路径导航"的任务:

  1. 网络连接正常
  2. 拥有机器人控制权
  3. 状态上报正常(非离线)
  4. 状态中无 emergency、fatals、errors
  5. 机器人无报错代码 54004, 54025, 54013
  6. 对于叉车,fork_auto_flag 为 true
  7. 机器人的位置可控,在任务相应的路径上(包括在路径的端点,或者在路径上),或者在前序未完成任务的路径上。

一个“路径导航”的请求中,可以包含多个任务,即批量发任务。其特点包括:

  1. 任务数组中的每个任务有 task_id。任务的 task_id 是宇宙唯一的。
  2. 批量发出的一组任务应是连续的,每个任务的目标点,是下一个任务的起点。每个任务的起点和目标点,都存在路径直连。(当目标点是机器人当前位置时除外)
  3. 机器人将按照下发任务的顺序,依次执行。机器人不会出现任务数组中的第二个任务失败,第三个任务却成功的情况。如果第 N 个任务失败,在当前时刻,后面任务都将被机器人自动取消。
  4. 对于批量发送的一组任务,调度可按照发送时的顺序依次查询每个任务状态。调度也可以通过 RBK 19301 端口里所提供的 task_status_package 对象,来查询任务状态。

调度向机器人的请求中,必须包含的字段有:

  1. "task_id",字符串,任务的宇宙唯一识别码;
  2. "id",字符串,目标站点名称,当要去的目标位置不是一个站点,而是机器人当前位置(即原地不动时),其值固定为 "SELF_POSITION"
  3. "source_id",字符串,起始站点名称,当起始位置不在一个站点上,而是机器人当前位置时,其值固定为 "SELF_POSITION"
  4. "operation" 字段,若出现将必须为有效值,否则将不允许出现该字段。

3.2 异常处理

3.2.1 重发

  1. "重发"的概念,是指调度对已经发送过的任务,使用原 "task_id",再次发送。rbk 收到已存在 "task_id" 的任务时,并且该任务已经完成或者正在运行、或者正挂起、或者正在等待执行时,就不再重复处理。
  2. 只有当任务的状态处于 "NotFound"(404)时,且机器人满足3.1条件时,调度可以重发任务。调度按原 task_id 重发此任务及后续任务。
  3. 重发任务,是为了处理因网络异常而导致的"连续的查询超时"、或者"机器人 rbk 关闭并在原地重启后任务数据丢失"等情况。

3.2.2 任务失败(Failed)或取消(Canceled):

  1. 在 rbk 内,如果一个任务执行失败、或者被取消,那么在此刻rbk 的任务队列中,该任务后续的任务,都应被取消
  2. 对于指定 task_id 的任务,完成、失败、取消都是终态,任务一旦达到终态,其状态就再也无法改变。
  3. 当遇到失败或者取消的任务,则进入调度层面的异常处理逻辑。例如:
    1. 在某些条件下(如拍急停导致的任务失败),错误恢复后,机器人可以继续执行,需要用新 task_id 发此任务及后续任务
    2. 如果调度认为,在某些条件下,机器人应当去执行其他业务,则发送新的任务给机器人

     1. 如果下发的任务解析失败(比如任务的格式问题,下发地图中没有的点),那么此任务的 task_id,以及后续任务的 task_id,都不会存到任务历史状态的队列中。

  1. 如果 rbk 任务失败并且保持在 Error 状态,那么接下来调度下发的任务,都会变成取消状态。直到Error被清除。
  2. 当人为确定机器人已清除错误或者故障,但机器人仍显示报错代码时,可以使用 2.9 节所述的“清除错误”API,来清除机器人的错误代码。然后再发任务给机器人。

3.3 控制权逻辑

机器人的控制权逻辑:

  1. 当一方获取控制权时,即独占机器人的控制权,其他方均无权控制(但可以查询机器人的状态)。
  2. 当一方获取控制权时,其他方可以调用获取控制权的 API,抢占控制权。
  3. 当一方获取控制权时,只有控制方自身可以释放控制权(其他方不可以代其释放,但可以抢占)。
  4. 当机器人没有被任何一方独占控制权时,可以被任何一方控制。注意,这可能产生控制冲突

对调度而言,如需控制机器人,需先抢占机器人的控制权。建议,

  1. 当机器人无人控制时,调度可以通过手动或者自动的方式,抢占其控制权。
  2. 当机器人有人控制时,调度可以通过人工确认的方式,抢占其控制权。
最近更新 2022/11/28
文章内容
  1. 信道

1.1 请求应答信道

1.2 机器人数据上报信道

  1. 通信协议

2.1 下发导航任务给机器人

2.2 查询导航任务的状态

2.3 控制权

2.4 机器人运行时主动上传数据

2.5 配置机器人主动上报数据的频率和内容

2.6 暂停和继续

2.7 清除错误

2.8 取消任务

  1. 通信逻辑

3.1 常规任务流程

3.2 异常处理

3.2.1 重发

3.2.2 任务失败(Failed)或取消(Canceled):

3.3 控制权逻辑