arm_dev
a89250d05d
在此之前，仓库里所有 Gazebo 相关的东西都是"声明"而非"事实"： arm.gazebo.xacro 零引用、stack.launch.py 的 isaac 分支只打印日志、 没有 world 文件、devices/sim/gazebo 下的目录全是空占位。 更关键的是：**这台机器上根本没装 Gazebo**，而 ROS 在 conda 里，没有 /opt/ros， apt 的 ros-humble-gazebo-* 装了也不会被 conda 的 ROS 认到。 环境（与真机环境物理隔离） - 新建 conda 环境 ros_gz_sim，**不碰能跑真机的 ros_flexiv**。 仿真要往环境里塞 Gazebo 及 protobuf/ignition/渲染一整条链， 和真机环境混装随时可能把它弄坏，代价远大于仿真带来的便利。 - 频道组合照抄 ros_flexiv 的安装记录（robostack-staging + conda-forge）， 那是本机已经证明可用的搭配。 两个实测踩到的坑（都写进了脚本注释，避免下次重踩） 1. empy 版本：conda 默认给 empy 4.x，而 Humble 的 rosidl_adapter 用的是 3.x 的 API。症状是构建自定义消息包时报 `_interpreter.shutdown()` 的 AttributeError， 报错点在 rosidl_adapter 内部，完全看不出跟 empy 有关。必须钉 empy=3.3.4。 2. conda 激活是**堆叠**的：同一 shell 里从 ros_gz_sim 切到 ros_flexiv 后， `which python` 指向 ros_flexiv，但 `python -m pip` 却解析到 ros_gz_sim 的 pip， 导致 colcon --symlink-install 报 "option --editable not recognized"。 这个报错和真实原因毫无关系，极易误判成"环境被搞坏了"。 现在 scripts/lib/conda_switch.sh 会在切换前退到 base，两个 env 脚本共用。 仿真用独立构建产物 - build_sim/ + install_sim/（scripts/build_sim.sh）。工作区只有一份源码， 若仿真也写 install/，就会覆盖真机的构建产物。 - 排除 11 个真机专属包（flexiv_hardware 需要 Flexiv RDK C++ SDK，根本装不上； 另有真机驱动/GPIO/MoveIt 配置/真机 bringup），每个都在脚本里写了理由。 已验证（不是只看退出码） - Gazebo Fortress 6.16 无头启动正常，物理初始化完成 - /clock 桥接到 ROS 成功收到仿真时间；ros_gz_sim create 成功往世界里建物 - 真机构建 18 包通过、233 项测试通过，build/ install/ 时间戳未变（没被覆盖） - 仿真侧 7 包构建通过；两环境互切后各自都能正常构建 注：Humble 配的是 Gazebo Fortress（ignition-gazebo6，命令行 `ign gazebo`）， 不是现代的 gz-sim —— 后者要 libprotobuf>=6.31，与 RoboStack Humble 钉住的 5.29.3 解不开依赖。Fortress 属于新 Gazebo 家族（非已 EOL 的 Classic）， 且是 Humble 的官方配对版本。 Co-authored-by: Cursor <cursoragent@cursor.com>
scripts — 唯一操作入口
实现细节在 docs/WORKSPACE.md 和 docs/。
每天： run_real.sh · run_camera_d405.sh · run_visual_servo_rt.sh · go_home.sh
三阶段串联： run_all.sh --arm 89 [--hole k2] [--skip-stage1]（run_pipeline.sh 是它的旧名别名）
手眼： run_handeye.sh（teach / merge / calibrate / show）
夹爪： run_gripper.sh --arm 89|91 · run_dual_gripper.sh
入孔： run_hole_detect.sh --arm … [--preview]
触觉： run_tactile.sh [--cli]
权重： weights.sh（list / labels / convert / doctor / show）
- 转换：
weights.sh convert <文件> --name <模型名>—— PT→ONNX→TensorRT，自动改名归位 + 固化标签 - 标签：
weights.sh labels <模型名>看，--set "工件,通止规"改 - 体检：
weights.sh doctor --check-engines（能查出 engine 与 TensorRT 版本不匹配这类静默失效） - 规则写在 models/README.md。
export_yolo_trt.sh现在是它的兼容转发壳。 配置：show_site_config.sh·lib/export_site_env.py
环境：env.sh·build_all.sh
RDK：test_rdk_python.sh·rdk_switch_tool.sh·rdk_drag_bridge.py
搁置未用：fetch_isaac_flexiv.sh（拉 Flexiv 的 Isaac Sim / RDK 源码到thirdparty/；Isaac 路线目前搁置，Gazebo 是选定平台）
lib/parse_arm_args.sh 解析 --arm 89|91。
lib/load_site_config.sh 把 config/site.yaml 变成 SITE_*。
排查脚本卡住时的常识
几个脚本开头会等外部条件（控制器 ACTIVE、相机出图、触觉就绪）。正确的判活顺序是
先 ros2 service list / ros2 topic list 看目标在不在，再去 call / echo：
# 对：服务不存在时立刻返回
timeout 3 ros2 service list | grep -q '^/controller_manager/list_controllers$' || exit 1
timeout 3 ros2 service call /controller_manager/list_controllers ...
# 错：服务不存在时每次 call 都要耗满超时才返回，
# 30 次循环 = 白等两三分钟（实测 63s），看起来就像脚本卡死了
for _i in $(seq 1 30); do timeout 5 ros2 service call ... ; done
run_all.sh / run_stage2_locate.sh / run_stage3_search.sh 已按正确顺序改过；
run_handeye.sh 一开始就是对的。