arm_dev
83c7a89731
三条独立的坑，前两条都在"看起来完全正常"的表象下静默失效：
1) 夹爪在仿真里是死的（关节级）
夹爪只有 finger_width_joint 是真关节（effort=80），其余 6 个手指关节
全是 mimic、effort="0"（上游语义：靠机械耦合跟随，不由电机驱动）。
而 sdformat 转 SDF 时**直接丢弃 <mimic>**（实测生成 SDF 里 "mimic"
出现 0 次），gz-sim 也没有任何 mimic 实现，SDF 规范里就没有这个元素。
于是 7 个关节在 Gazebo 里互相独立、谁都不跟随谁。
2) 补了 effort 才有用（力度）
gz_ros2_control 的 position 接口是"位置误差 → 力"
（实测 position_proportional_gain=0.1），力被 effort 上限夹到 0 →
永远出不了力。症状极隐蔽：接口 [claimed]、控制器 active、话题有订阅、
命令也发得出去，但手指一动不动，只是自由地被重力拽着漂。
对照实验：同一套链路下 sim_joint1 收到 0.2 rad 后精确到位（0.19998），
所以链路本身没问题，差别只在这 6 个关节的 effort=0。
3) 描述与 Gazebo 的事实不一致（语义）
robot_state_publisher 支持 mimic，会用主关节的值覆盖从动关节；而 Gazebo
里它们是独立被驱动的。实测当前 RSP 没有应用 mimic（TF 跟随真实值），
所以碰巧一致 —— 但这是实现细节，它一变 TF 就静默退回闭合位。
改动：
- ros2_control 增加夹爪 7 个关节的接口（含 load_gripper 开关）
- controllers.yaml 增加 gripper_controller（JointGroupPositionController）
- 启动器 spawn 它；并重命名归一化第三条修复
- urdf_normalize 第三条修复：被 mimic 关节补 effort=80、删除 <mimic>
并记录耦合关系；新增 mimic_relations() 供适配器在归一化前读取
（信息只是搬家，不能丢）
- 新增 6 项单测锁定上述行为
验收（实测）：命令 width 0→0.1，指尖间距 27.1mm → 127.0mm（约 100mm 行程，
与真机 GRAV 规格吻合），7 个关节实测值均命中命令值，TF 与之一致。
Co-authored-by: Cursor <cursoragent@cursor.com>
devices/ —— 设备与外部文件总目录
这个目录存在的唯一目的：把「换个硬件」从改代码变成改配置。
设计原则（务必先读）
1. 选型与数值分离
| 关注点 | 放在哪 | 谁改 |
|---|---|---|
| 用哪个品牌的哪个驱动 | devices/registry.yaml |
集成工程师（很少改） |
| 设备号 / 速度 / 阈值 / 悬高 | config/site.yaml |
现场操作人员（经常改） |
devices/ 下不允许出现任何现场数值。 数值只有 config/site.yaml 一个来源。
这样可以避免现在这种「同一个值三处定义、改了不生效」的问题。
2. 目录约定
devices/
├── registry.yaml # 选型开关（唯一入口）
├── robots/ # 机械臂：RDK + 适配器
├── grippers/ # 夹爪
├── sensors/
│ └── orisys/ # ★ 视触觉核心，长期迭代，单独占一个大文件夹
├── cameras/ # 相机
└── sim/ # 仿真平台（当前 Gazebo）
每个品牌一个子目录，子目录内固定结构：
<类别>/<品牌>/
├── manifest.yaml # 我是谁 / 支持什么能力 / 需要哪些配置 / 外部文件放哪
├── driver/ # 适配器（把厂商 API 翻译成框架接口）
└── <厂商物料>/ # 如 rdk/、sdk/，原样放置，不要改名
3. 一个新品牌要接进来，只需要四步
- 丢物料：把厂商的 RDK / SDK / 驱动包放进
<类别>/<品牌>/下对应文件夹 （格式和命名要求写在该类别的README.md里，必须按它要求放）。 - 填 manifest：复制同类别的
manifest.yaml改四个字段（id / label / driver.package / config_schema）。 - 写适配器：在
driver/下实现框架的接口契约（见src/arm_interfaces/）。 这一步的工作量取决于厂商 —— 如果厂商本来就提供符合契约的 ROS 2 驱动，这一步几乎为零。 - 改一行选型：把
registry.yaml里对应类别的值改成新品牌 id。
诚实说明：第 3 步无法完全避免。Flexiv 的 RDK 是 C++/Python 库而不是 ROS 2 驱动， 所以它外面永远需要一层薄适配器。框架能做的是把这层适配器写到最薄（只做 API 翻译， 不含任何业务逻辑），而不是让你零代码接入。
4. 启动时的校验
框架启动会依次读 registry.yaml → 各 manifest.yaml → config/site.yaml，
校验三件事：
- 选中的品牌目录存在，且
manifest.yaml可解析； - manifest 里
assets声明的必需物料文件都在； config_schema里标记required: true的配置键，在site.yaml里都有值。
任何一项不满足立即报错并明确指出该去哪个文件补什么，不允许静默降级。
这是替代现在「run_handeye.sh 传了 5 个节点没声明的参数、调参静默失效」那类问题的机制。