20 理论课-AI 协同开发：AI 大模型在 Gazebo 仿真开发中的应用

- AI 协同开发：AI 大模型在 Gazebo 仿真开发中的应用

关联：索引

术语约定（本讲统一口径）：

  1. 场景提问：如果 AI 给你生成了一个分拣场景 world，打开后苹果“穿透传送带”、机械臂抓不住、画面卡顿延迟巨大，你应该先做哪三件事？

  2. 场景方案设计（从需求到结构）

  3. 建模代码生成（从结构到 SDF/配置）

  1. 报错分析（从日志到修复）
  1. 参数优化（从现象到参数建议）

1. 提示词的“工程结构”（推荐模板）

把提示词固定为 7 个字段，减少歧义：

角色：你是 Gazebo Fortress（Ignition Gazebo 6）+ ROS2 Humble 的仿真工程师

目标：为工业分拣产线生成 SDF 1.8 代码片段/或完整 world，并保证可运行与可验证

输入（场景需求）：
- 设备：传送带、UR5e（已存在模型/或仅留接口）、分拣箱、物料（苹果）
- 关键约束：尺寸单位为米；坐标系采用 world: x 前、y 左、z 上；yaw 绕 z
- 物理需求：苹果在传送带上不明显打滑、不穿透；允许轻微弹性；抓取接触要稳定
- 数据交互：相机/关节状态要能进入 ROS2（允许使用 ros_gz_bridge）

输出要求：
- 输出必须是 SDF 1.8（XML），给出完整可复制代码块
- 代码必须包含：model/link/inertial/collision/visual（物料至少一个）
- 所有 name 必须唯一且语义化；不要引用外部不可用资源

代码规范（必须遵守）：
- 不要写“可能/大概”，遇到不确定请给出两种可选写法并说明选择条件
- 给出 3 条命令用于验收：SDF 校验、启动仿真、查看关键现象（例如 topic 或日志关键字）

自检：
- 在输出末尾列“你自己检查过的点”（SDF 结构、单位、碰撞、惯量、参数兼容）

逐段解释（学生要能说明“每段在防什么坑”）：

3. 示例提示词：生成“苹果物料（含碰撞属性）”SDF 片段

你是 Gazebo Fortress（Ignition Gazebo 6）仿真工程师。请生成一个 SDF 1.8 的 model 片段：model 名为 apple_01。

需求：
1）几何：近似为球体，半径 0.04m；视觉可用简单材质；碰撞必须存在
2）质量：0.18kg；惯量按均匀实心球计算并写入 inertial
3）接触：目标是在传送带上不明显打滑、不穿透、接触稳定
4）请在 collision 的 surface 中给出 ODE 参数（mu/mu2、slip、kp/kd、min_depth），并解释每个参数影响的现象
5）输出后给出 2 条验证命令：一条校验 SDF 语法，一条启动仿真并观察现象（可用 ign 或 gz 的二选一写法）

1. 验证的最小闭环：先证明“能加载、能运行、现象可观察”

常用验证命令（按你机器可用二选一）：

# 1）SDF 结构校验：发现标签不闭合、字段放错层级、版本不匹配
ign sdf -k sorting_ai_demo.world
gz sdf -k sorting_ai_demo.world

逐行解释：

# 2）启动仿真并打开详细日志：优先用日志定位资源/插件/解析失败
ign gazebo -r -v 4 sorting_ai_demo.world
gz sim -r -v 4 sorting_ai_demo.world

逐行解释：

# 3）最短证据：列出 Gazebo 内部 topic，证明传感器/系统确实在发数据（可选）
ign topic -l
gz topic -l

逐行解释：

  1. 先最小化：把 world 缩成“地面+传送带+一个苹果”，先把接触稳定性调到可接受，再扩展到机械臂与传感器。
  2. 一次只改一个变量：每次只改一个参数（或一组强耦合参数），并记录“参数→现象→证据”。
  3. 先对齐现象，再追求性能：稳定性达标后，再做性能优化（加大步长/降低迭代/降低数据量）。

快问快答（用证据说话）：

  1. 你如何用命令证明一个 world “可加载且在运行”？（至少一条 SDF 校验命令 + 一条启动命令）
  2. AI 生成的 SDF 片段里，为什么必须包含 inertial 与 collision？缺了会出现什么现象？

1. 先定“场景需求”，再定“指标”，最后才是“参数”

2. 参数迭代策略（推荐流程）

Step 0：先固定“时间步长与求解基线”
  - 优先用 max_step_size 与求解迭代（例如 iters）把稳定性跑出来；real_time_factor/real_time_update_rate 更偏向“速度目标”，不要和“精度”混为一谈

Step 1：先解决“穿透/抖动”再解决“打滑”
  - 穿透/抖动通常与步长、迭代、接触刚度/阻尼相关
  - 打滑通常与摩擦系数、接触模型、碰撞几何相关

Step 2：以现象为准，逐项调整，并记录证据
  - 每次只改一个参数（或强耦合组），对比同一段复现实验

Step 3：稳定后做性能回收
  - 逐步增大步长/降低迭代/降低碰撞复杂度，找“刚好够用”的点

3. 物理引擎参数调优参考表（分拣场景常用）

说明：不同引擎/版本参数体系不完全一致，表格用于“现象-参数”的思考框架；以你的仿真日志与实际现象为准。

|---|---|---|---|---|
| 物体穿透地面/传送带 | 步长过大、接触求解不足、碰撞几何太薄 | 减小 max_step_size；提高 solver 迭代 iters；增大接触刚度 kp/合理 min_depth | 仿真变慢（CPU 占用上升） | 对比视频 + 日志无穿透告警 |
| 接触抖动/弹簧感强 | kp/kd 量级不合理、阻尼不足、迭代不足 | 降低 kp 或提高 kd；提高迭代；降低 contact_max_correcting_vel | 太“软”会下陷或滑动 | 同一初始条件下抖动幅度下降 |
| 苹果明显打滑 | 摩擦不足、collision 形状不合理、slip 过大 | 提高 mu/mu2；减小 slip1/slip2；简化且贴合的 collision | 摩擦过大可能导致卡顿/非真实粘连 | 10s 滑移距离对比 |
| 物体弹跳过度 | 恢复系数过大、接触模型不稳 | 降低 restitution_coefficient；提高阻尼；减小步长 | 过度耗能导致“太黏” | 落下后弹跳次数减少 |
| 仿真速度慢、RTF < 1 | 计算量过大（步长太小/迭代太多/碰撞过复杂/传感器过重） | 适当增大 max_step_size；降低 iters；简化 collision；降低传感器分辨率/频率 | 精度与稳定性下降 | real_time_factor 接近 1 的截图 |

4. 示例：苹果 collision 的“接触/摩擦”片段（用于 AI 生成后的人工校对）

<model name="apple_01">
  <pose>0 0 0.2 0 0 0</pose>
  <link name="link">
    <inertial>
      <mass>0.18</mass>
      <inertia>
        <ixx>0.0001152</ixx>
        <ixy>0.0</ixy>
        <ixz>0.0</ixz>
        <iyy>0.0001152</iyy>
        <iyz>0.0</iyz>
        <izz>0.0001152</izz>
      </inertia>
    </inertial>

    <collision name="collision">
      <geometry>
        <sphere>
          <radius>0.04</radius>
        </sphere>
      </geometry>
      <surface>
        <friction>
          <ode>
            <mu>1.0</mu>
            <mu2>1.0</mu2>
            <slip1>0.0</slip1>
            <slip2>0.0</slip2>
          </ode>
        </friction>
        <bounce>
          <restitution_coefficient>0.05</restitution_coefficient>
          <threshold>0.1</threshold>
        </bounce>
        <contact>
          <ode>
            <kp>100000</kp>
            <kd>1</kd>
            <max_vel>0.1</max_vel>
            <min_depth>0.001</min_depth>
          </ode>
        </contact>
      </surface>
    </collision>
  </link>
</model>

逐段解释（用来审计 AI 输出是否“可解释”）：

1. 延迟先分解：你优化的是哪一段

把端到端延迟拆成四段（便于定位瓶颈）：

1）传感器生成：相机/IMU 等在 Gazebo 内部的 update_rate、分辨率、渲染负载

2）桥接与传输：Gazebo Transport → ros_gz_bridge → ROS2 DDS

3）ROS2 中间件：QoS、队列深度、可靠性策略、网络

4）节点处理：回调执行时间、图像解码/推理耗时、线程模型

2. 最小测量方法：用消息时间戳估算接收延迟（示例代码）

说明：以 sensor_msgs/msg/Image 为例，使用 header.stamp 与当前节点时间做差，得到“从发布到接收”的近似延迟（包含桥接与 DDS）。

import rclpy
from rclpy.node import Node
from rclpy.qos import qos_profile_sensor_data
from rclpy.time import Time
from sensor_msgs.msg import Image

class ImageDelayProbe(Node):
    def __init__(self) -> None:
        super().__init__("image_delay_probe")
        self.create_subscription(
            Image,
            "/camera/image_raw",
            self._on_image,
            qos_profile_sensor_data,
        )

    def _on_image(self, msg: Image) -> None:
        now = self.get_clock().now()
        stamp = Time.from_msg(msg.header.stamp)
        delay_ms = (now - stamp).nanoseconds / 1e6
        self.get_logger().info(f"image_delay_ms={delay_ms:.1f}")

def main() -> None:
    rclpy.init()
    node = ImageDelayProbe()
    try:
        rclpy.spin(node)
    finally:
        node.destroy_node()
        rclpy.shutdown()

逐段解释：

运行提示（任选一种口径，按你们工程实际）：

# 若你把该脚本做成 ROS2 节点：建议在启动时显式启用仿真时间
ros2 run sorting_ai_tools image_delay_probe --ros-args -p use_sim_time:=true

逐行解释：

3. 延迟优化的工程手段（按优先级）

1）先减数据量（最有效且最安全）

降低分辨率 / 降低帧率（update_rate） / 降低图像编码开销（尽量减少不必要的转换）

解释：

2）优化 QoS（避免“可靠性导致的排队”）

ros2 topic hz --qos-profile sensor_data /camera/image_raw

逐行解释：

3）减少桥接开销与链路层级

4）优化节点处理路径（避免回调阻塞）

把“能跑”升级到“可用”，通常需要人工做 5 类适配：

  1. 资源与路径：把 AI 写的外部 mesh/material 替换为本地可用资源；必要时先用基本几何体验证逻辑。
  2. 坐标与尺度：统一 world 原点与设备坐标；所有尺寸以米为单位；关节/传感器 pose 与产线布局一致。
  3. 物理可信：补全 inertial，校对质量/惯量量级；确保 collision 与 visual 一致；把“过度理想”的参数调回合理范围。
  4. 性能与延迟：在满足稳定性前提下回收性能；对传感器流做节流与 QoS 调整，形成可解释的延迟预算。

工坊 A：提示词设计与代码生成（教师演示，学生记录）

生成 UR5e 机械臂适配分拣场景的 SDF/或 spawn 配置方案，并生成一个苹果物料的 SDF 模型（含碰撞与摩擦参数）。

要求：
- 明确你采用 Gazebo Fortress（ign gazebo）还是 gz sim，并给出相应启动命令
- 苹果模型必须含 inertial + collision + surface 参数，并解释每个参数影响的现象
- 给出最小可验收验证命令：SDF 校验 + 启动 + 观察证据（日志关键字/现象）

工坊 B：常见问题分析与人工优化（小组讨论）

每组从以下问题中选 2 个讨论，并输出“修复策略 + 验证证据”：

工坊 C：物理引擎调参迭代思路分享（难点突破）

每组提交一张“参数迭代路线图”（手绘或文字均可）：

  1. 记录 AI 协同仿真开发的应用场景与提示词设计技巧（至少给出 1 个你们组可复用的提示词模板）。

  2. 梳理物理引擎参数调优与交互延迟优化的方法（用“现象-原因-参数-证据”四列总结）。

  3. 结合自身仿真场景，列出 AI 生成代码需优化的关键点，制定修改计划（至少 5 条，标注优先级）。

  4. 生成 AI 协同仿真开发的提示词模板（场景设计、代码生成、报错分析），要求含“输出格式 + 自检清单 + 验证命令”。

  5. 生成物理引擎参数调优参考表（适配分拣场景），要求含“现象→参数→副作用→证据”。

  6. 针对学生列出的代码优化点，给出修改建议与优化方向，并按优先级排序（先稳定性，再性能，再体验）。

课后作业

参考与延伸（建议）