2 Commits

Author	SHA1	Message	Date
arm_dev	6922b18187	仿真夹爪适配器：服务接口对齐真机，开口按正运动学换算成真毫米 ... 为什么 ------ 应用层只认 arm_msgs/srv/GripperExecute（开口毫米），真机与仿真必须同一套接口。 但 GN01 的 URDF 里 <mimic> 是**线性近似**：直接按线性系数下发 finger_width_joint， "命令开 20 mm"在 Gazebo 里量出来是 21.75 mm —— 抓不住工件，而且看起来像算法问题。 实测（2026-09-24，Gazebo 内量两指尖间距）： 线性下发 20 mm → 实际 21.74 mm（偏差 1.74 mm，超 2 mm 抓取容差的前半步） 走 FK 反解 → 实际 20.00 mm（≤0.5 mm） 怎么改 ------ - 新增 sim_gripper_kin.py：解析 URDF 正运动学，算出"主关节值 ↔ 真实开口 mm"的 单调曲线，反解用二分。曲线非单调/零行程时**主动报错**，不静默退化成线性。 - sim_gripper.py：开口换算全部走该曲线；容差统一改成毫米。 - sim_gripper_adapter.py：反馈改取**从动关节**（见下）；is_gripped 按毫米判定。 - 新增 check_sim_gripper.py：三层验收（服务/开口一致/指尖真实几何行程 + 对称性）。 踩到的坑 -------- - finger_width_joint 挂在无质量的 unused_finger_width_link 上，与手指**没有机械 连接**：命令到 0.100，它的 /joint_states 恒为 1.4e-08，6 个从动关节才准到 0.7854。反馈若取它，/gripper/status 会永远报"开口 0 mm"。 - 残留进程会伪造出"代码写错了"的现场：旧 sim_gripper_adapter 与新实例抢话题， 验收读到"指尖间距 0.03 mm"（真实 127 mm）；孤儿 static_transform_publisher 用 latched /tf_static 把旧相机外参按在新仿真上。 → 新增 scripts/lib/sim_procs.sh；run_sim_gz.sh 用 setsid 独立进程组， PGID 记进 log_sim/sim.pgid，stop 时整组 kill；启动前预检拒绝带病启动。 - 验收脚本自己也错过两次（把 TF 的米当毫米比 → 127 mm 显示成 0.13 mm； 用会转动指垫的中点漂移判对称 → 必然位移 16 mm）。判据改成"两侧各走多远"， 单位只在 _dist_mm 里换算一次。 验证 ---- python3 -m pytest src/arm_sim_gazebo/test/ -q → 307 passed python3 scripts/check_sim_gripper.py → 三层全过 第 2 层：请求/反馈开口最大偏差 < 0.5 mm 第 3 层：期望行程 vs 实际行程、左右行程差，均 < 1.5 mm bash scripts/stop_sim_gz.sh --list → 整组列出（含 static tf） 文档 ---- - 仿真手册：新增 §4.4（开口 mm 怎么换算）、坑 12（宽度关节不动、 反馈必须取从动关节）；停止一节改写成进程组语义。 - FRAMEWORK_RULES：新增 R4.11（残留进程会伪造现场）、R4.12（验收判据要挑 与实现无关的物理量）；R4.9 表补夹爪；清单补 13/14 两条。 - HANDBOOK：新增 §3.4「在仿真里开合夹爪」，补 §4.4 的两条新教训。 Co-authored-by: Cursor <cursoragent@cursor.com>	2026-09-24 09:46:09 +08:00
arm_dev	01940f54e7	P5c-3 仿真启动器跑通：Gazebo + spawn + 两个控制器 active ... 端到端验收（headless，本机无显示器）： ign 加载 Physics/UserCommands/SceneBroadcaster/Sensors + gz_ros2_control 机械臂 spawn 进 assembly 世界，7 个 sim_joint 全在 /joint_states joint_state_broadcaster 与 rizon_arm_controller 双双 active world → sim_tcp 可查，且末端位姿 3 秒内不变（重力下站住） 网格解析报错 0 条 新增： scripts/run_sim_gz.sh 此前**不存在**，却被 install_sim_env.sh 与 build_sim.sh 的提示语引用 arm_sim_gazebo/robot_description.py 展开 + 归一化，launch 与 CLI 共用一份 arm_sim_gazebo/gazebo_sim_launcher.py 薄壳：准备描述后转发给 launch 文件 launch/gazebo_sim.launch.py 起 gz → 发归一化 URDF → spawn → 拉控制器 test/test_robot_description.py 含"仓库里这份 world 必须过守卫"的测试 接线过程中实测踩到并修掉的三个坑，共同特征是**每一步看起来都成功**： 1) urdf_normalize 在 Python 路径下静默失效（我自己引入的，最严重） xacro 的输出格式在不同环境里不一样：真机环境的 CLI 缩进成多行，而仿真环境 走 xacro.process_file().toxml() 时全挤在一行。归一化的正则要求标签之间必须有 \n，于是**仿真路径下它什么都没做**（报告"包裹 0 处"），而 CLI 路径下正常 —— 之前那次"已修好"的验证走的就是 CLI，所以看起来过了。 后果是 Gazebo 会丢掉整条机械臂，正是这个归一化本来要防的事。 已改成对空白格式零假设，并加回归测试锁住。 2) world 里声明了 <plugin> 会把默认系统挤掉 只要 world 声明任何一个 <plugin>，Gazebo 就不再加载 server.config 的 Physics/UserCommands/SceneBroadcaster。缺 UserCommands → /world/<名>/create 服务不存在 → ros_gz_sim create 调服务超时后回退发 topic、 没人收 → **模型从未进入 Gazebo**，而 create 节点仍打印 "OK creation of entity"，控制器则永远卡在 "waiting for service"。 已在这三个系统在 assembly.world 里显式声明，并加纯文本守卫 check_base_plugins()，让"加了插件忘了补基础系统"在启动前就被指出。 3) gz 的插件与资源搜索路径缺 $CONDA_PREFIX/lib gz_ros2_control 报 "Failed to load system plugin [libgz_ros2_control-system.so] : couldn't find shared library"，而 ldd 全齐、 库就在 $CONDA_PREFIX/lib 下。原因是 gz 的 SystemLoader 先在搜索路径里找文件， 找不到就直接放弃，不去 dlopen 裸文件名（所以 conda 二进制的 RPATH 兜不住）； 而 ros_gz_sim 只把 LD_LIBRARY_PATH 拼进搜索路径，conda 激活并不往那里加。 同一原因导致 mesh 的 model:// 也解析不了（视觉报错很吵，但更要紧的是 **碰撞网格也加载不出来**，会让后续装配的接触判据失效）。 由于 gz_sim.launch.py 用 `from os import environ` 在生成 launch 描述时就读 进程环境，这些变量**必须在 ros2 launch 之前**设好，因此放在 sim_env.sh —— 在 launch 文件里用 SetEnvironmentVariable 补是无效的，会被它自己算的那份 字典覆盖。 Co-authored-by: Cursor <cursoragent@cursor.com>	2026-09-23 14:48:16 +08:00