 arm_dev
|
72353f3773
|
注释与提示信息全面中文化：源码 66 个 .py + 脚本/配置 45 个文件
背景：现场读代码的人只读中文。此前代码里的 docstring 是英文、行内注释是中文，
一半英文一半中文反而更难看懂 —— 新手打开一个 .py 不知道这个模块为什么存在。
范围（本仓库自己的代码，厂商上游不动）
src/arm_application/** 37 个文件：servo_node / perception_node / handeye_* / dh_pgea /
yolo_detector / kalman_filter / goto_ee_plane / dual_gripper …
src/arm_interfaces/** 11 个文件：paths / manifest / loader / config_guard / errors …
src/arm_control/** 5 个文件
src/arm_bringup/** 3 个 launch
scripts/** 6 个 .py + 29 个 .sh（scripts/ 是"唯一操作入口"，用户屏幕上
看到的就是这些提示，所以提示信息也一并中文化）
config/ handeye/ devices/ src/arm_*/config/ 17 个 .yaml/.xml/.xacro/.cfg
口径（写进 docs/FRAMEWORK_RULES.md 新增的 R6.5，作为长期约束）
注释、docstring、print/日志/异常里给人看的句子 = 中文；
标识符、API 名、话题名、参数名、字段名、命令名 = 保留英文原文（用 `` `` 包起来）；
单位、十六进制、协议报文、CRC 值、命令示例 = 原样保留；
src/flexiv_*/ = 厂商上游代码，不许改也不许翻译（R4.4）。
翻译保原意与原有详细程度：那些"为什么不能用另一种做法""踩过什么坑"的说明
全部完整保留 —— 它们才是这份代码里最贵的部分。
新增 scripts/check_text_only.py：只改文字时的自证工具
人工 review 靠不住（115 个文件、3000 多行 diff）。这个脚本把改动前后的源码解析成
语法树，删掉 docstring、抹平字符串常量、把 f-string 只留"插值了几次 + 插值是什么"，
再比对：完全相同 = 改动范围内没有逻辑变化。
留了一个口子：f-string 的插值按内容排序后再比 —— 因为中文语序常常要和英文反着来
（f"on {port} read {idx} failed" → f"在 {port} 上读 {idx} 失败"），只换显示顺序不该判失败；
但多插一个、少插一个、换掉被插入的表达式，立刻会报出来。
本次 66 个 .py 全部通过该闸门。
验收
改动的 66 个 .py：scripts/check_text_only.py 全部通过（零逻辑变化）
45 个非 .py 文件：去注释后与 HEAD 逐字节相同（零配置变化）
docstring 总数：没有一个文件减少（不存在"翻译时顺手删了说明"）
单测：arm_application 233 / arm_driver_flexiv 69 / arm_interfaces 46 /
arm_kinematics 24 / arm_sim_gazebo 236 = 608 passed，与改动前一致
全部 .sh：bash -n 通过；并额外实际执行了 --help 验证（见下一个提交：
bash -n 对 CRLF 脚本会漏报，只有真跑才暴露）
Co-authored-by: Cursor <cursoragent@cursor.com>
|
2026-09-23 17:40:55 +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 |
|
|
arm_dev
|
6edb8d39ab
|
chore: 框架科学优化前的完整基线
在开始'设备契约层 + 目录重构 + 通止规装配'改造之前，先钉住当前可运行状态，
使后续任何删除/重构都可回退。
本基线包含：
- 现有 ROS 2 工作区全部源码（arm_application / arm_control / arm_bringup 等）
- 官方 flexiv_ros2 栈（含 flexiv_hardware / flexiv_controllers 等符号链接）
- 设备契约层 src/arm_interfaces（新增，46 项单测通过）
- devices/ 设备选型与品牌清单（新增）
- scripts/gen_site_example.py 与由它生成的 config/site.example.yaml
按 .gitignore 排除：build/ / install/ / log/ / config/site.yaml / 模型权重二进制。
|
2026-09-23 10:53:06 +08:00 |
|