机器人及控制柜型号确认

机器人及控制柜的型号是控制器软件与实际硬件的一种连接，控制器软件通过识别机器人和控制柜的型号来加载不同的配置（aubo_description/conf 文件夹），比如机器人的关节角度范围限制、速度限制、加速度限制等。机器人和控制柜的型号不能出现差错，否则会导致机器人运动超限或者界面显示模型不对。

机器人及控制柜型号确认

用户可以通过以下几种方式来确认机器人型号

1. 示教器界面显示

显示的型号与真实型号一般来说是对应的，但是在部分OEM中，允许用户自定义机器人和控制柜型号

点击机器人模型右上角的三横杠按钮，可以查看机器人和控制柜的型号

2.SDK调用接口获取

getRobotType: 获取机器人主型号
getRobotSubType: 获取机器人子型号

getControlBoxType: 获取控制柜型号

3. 分析日志

1) 可以通过算法接口被调用时产生的日志获取

2) 可以通过SDK调用 getRobotType ``getRobotSubType``getControlBoxType的返回值确认

在客户端调用getRobotType ``getRobotSubType``getControlBoxType函数，用于获取机器人主型号/子型号/控制柜型号：

调用结果可以在终端或者日志result中查看：

4. 分析诊断文件

诊断文件中一般都会有机器人的型号 (如文件 rob1_20240821225924.csv)

机器人型号的来源

1) .robot_type 文件: 仅用于上电前猜测机器人型号使用，用于机器人的型号（序列码）一般都存储在底座中，因此在上电前软件是不知道机器人的具体型号的。为了在上电前能够对机器人模型进行显示，软件会缓存机器人的型号（最后一次上电读取到的机器人型号），用于在上电前返回初始化机器人型号。一旦机器人上电成功，来源于 .robot_type 文件的机器人型号就会被覆盖（比如来源于序列号）

2) 老协议: aubo_control.conf 配置 > 接口板自动解析（接口板会根据关节的配比来猜测机器人的型号并返回字符串到硬件抽象层，硬件抽象层会根据接口板返回的字符串进行重新适配，使之能够在 aubo_description/conf 文件夹中搜索到）
新协议: aubo_control.conf 配置 > 序列号解析 > 硬件抽象层猜测

3) 存在一种情况: 通过aubo_control.conf 配置指定或者序列号解析出来机器人型号的主型号存在但是子型号不存在时，型号会退化为主型号，比如 aubo_i5_77 型号不存在，控制器会将型号蜕化为 aubo_i5

4) 控制柜的型号一般由接口板自己确认，因为接口板会一直处于上电状态，控制柜的序列号也会写在接口板中

常见问题

1. 显示的机器人型号与实际机器人不符合

一般情况是因为在 aubo_control.conf 指定了机器人型号，且此型号与机器人的实际型号不一致

比如在/root/arcs_ws/config文件夹中 aubo_control.conf 指定了机器人型号为aubo_i10

示教器显示型号也为aubo_i10，但其实际型号为aubo_i5；由于实际存在aubo_i10型号，所以示教器并没有报错，从而导致显示的机器人型号与是实际机器人型号不符合

2. 导入新的机器人型号时 aubo_control 服务崩溃（直接表现就是示教器连不上控制器了）

一般情况为新导入的型号缺失了配置文件或者配置文件格式错误，可通过分析日志来排查问题，或者终端重启 aubo_control, 看机器人崩溃在哪了

比如在aubo_control.conf中指定机器人型号为aubo_i1000，实际并不存在该型号

由于aubo_i1000并不存在，示教器会提示接入机器人失败，从而连接不上控制器

在日志中可以找出错误型号和实际正确型号