2 Commits

Author	SHA1	Message	Date
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
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