 arm_dev
|
c1cd862eea
|
真机落地前的仿真补齐：夹持/腕力/真值位姿，让仿真能验证 S07–S09
这批是 09-24 那轮仿真工作的收尾，一直没提交。内容按目的分四块：
1) 仿真真能「夹住」工件
sim_grasp_lock：给规与夹爪之间加接触锁（默认关，run_gauge_assembly --sim 才开）。
没有它时仿真里规只靠摩擦，S08 棘轮一转就滑出指间，于是把「仿真不真」误读成
「力判据不对」。新增 test_sim_grasp_lock.py。
2) 腕部力传感器进仿真
sim_wrist_ft（+ config/wrist_ft.yaml）：S07 的首选判据是腕部 FT 的轴向突变，
而仿真里以前根本没有腕部力，S07 只能退到触觉兜底，两套判据从没在同一场景下比过。
现在两条通道都在，接触判定可对照。
3) 真值位姿可查（不再靠猜）
sim_live_pose / sim_pose_service：把 Gazebo 里刚体的实测位姿发布出来，
stage2 的真值路径按**实测**位姿算孔位，而不是按场景文件里的标称位姿。
顺带把真值孔位的推导（truth_holes）独立出来并补测。
4) 工具几何成为可配置项
config/sim_tool_geometry.yaml + stage2 的 tool_tip_below_flange_m 启动参数：
仿真里规会在指间下滑，工具长每次装夹都不同（实测见过 243/254mm），
悬停高度与 S07 下探预算必须按实测值算，不能再写死。
应用层同时跟进：gauge_fsm / gauge_config 把「悬停时工具尖端入没入工件」的判据
（hover_z_guard）与拖件判定（drag_verdict）收成纯函数并补测；stage3 搜孔、
site 导出、run_gauge_assembly 与若干文档同步。
新增 test_gauge_exit_lift / test_gauge_gripper_client / test_node_handler_collisions。
测试：全仓库 1085 passed。
|
2026-09-28 10:17:06 +08:00 |
|
|
arm_dev
|
aed5d326a0
|
仿真环境串味根治：清残留路径 + 补 conda lib + 修入口脚本 shebang
症状一（最隐蔽）：同一 shell 里先 source 过真机环境（scripts/env.sh）再
source 仿真环境，install/ 与 ros_flexiv 的路径不会被 conda deactivate 撤掉，
长在 install_sim/ 前面：
- PYTHONPATH 里真机那份 arm_msgs 压住仿真那份 → 消息类型混用
- LD_LIBRARY_PATH 里没有 $CONDA_PREFIX/lib → sim_tactile_adapter 订阅
ros_gz_interfaces/Contacts 时抛
Type support not from this implementation ...
cannot open shared object file
而库其实就在 conda 里、ldd 全齐。整条触觉链静默死掉（话题不发）。
症状二：setuptools 写 console_scripts 用的是**构建那一刻**的 python。
若在真机环境里跑过 build_sim.sh，install_sim/ 里 7 个入口脚本的 shebang
会指向 ros_flexiv —— 而 ros2 run 是照 shebang 执行的，于是**仿真节点一直
跑在真机 conda 环境里**。两个环境都是 Humble+py3.11，所以"居然能跑"，
只有偶发 dlopen / 反序列化怪错。
修法：
- conda_switch.sh 新增 path_drop_patterns：按 glob 从冒号列表里删条目
- sim_env.sh 清掉真机残留 + 末尾补 $CONDA_PREFIX/lib（优先级最低）
- 新增 lib/fix_shebangs.sh，build.sh / build_sim.sh 收尾各扫一遍（幂等）
Co-authored-by: Cursor <cursoragent@cursor.com>
|
2026-09-24 14:42:50 +08:00 |
|
|
arm_dev
|
a89250d05d
|
P5c-1：把 Gazebo 仿真环境真正装起来（独立 conda 环境），并固化安装/构建流程
在此之前，仓库里所有 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>
|
2026-09-23 13:52:04 +08:00 |
|