批判式学习和批判式实践素材，必须严厉批判之后才能掌握真正需要的技能，给出材料需要火眼金睛。

就如同下面的话语：

可能有误，请核实

可能有误，请核实

---

从Lyrical到Indigo所有LTS长期支持版本全部试用从基础命令，图形化工具调试，三维可视化rviz，机器人模型仿真，导航巡逻，物品抓取放置，扩展第三方各类外设，综合实践等，博客全部涉及且全部公开，但需要批判式学习和实践，出考题用，可以测评学生具体掌握情况。

---

2026：

大纲：

《ROS 机器人程序设计》课程教学大纲-2026- kinetic-lyrical

必须批判学习的基础理论

何时开启 ROS 2 Lyrical Luth 之旅最为合适？_ros2lyrical支持-CSDN博客

ROS 2 Lyrical Luth 第1章 系统入门教程

ROS 2 Lyrical 第2章 ROS 2系统架构与核心概念

ROS 2 Lyrical 第3章 可视化与系统调试工具

ROS 2 Lyrical 第4章 URDF机器人建模与Gazebo Garden仿真

ROS 2 Lyrical 第5章 导航前置：TF坐标变换、传感器、里程计与SLAM建图

ROS 2 Lyrical 第6章 Nav2自主导航完整配置与实操

ROS 2 Lyrical 第7章 MoveIt 2机械臂运动规划与抓取仿真实操

ROS 2 Lyrical 第8章 传感器与执行器集成-CSDN博客

ROS 2 Lyrical 第9章 计算机视觉与摄像头应用

ROS 2 Lyrical 第10章 点云处理与 PCL 库集成

ROS 2 Lyrical 全栈技术体系硬核综述与进阶展望

样题：

《ROS 机器人程序设计》课程习题资料-2026-lyrical

必须批判实践的项目案例

ROS2 Lyrical实验1系统入门

ROS2 Lyrical实验2架构与核心

ROS2 Lyrical实验3工具进阶

ROS2 Lyrical实验4机器人模型

ROS2 Lyrical实验5导航Nav2

ROS2 Lyrical实验6机械臂MoveIt2

ROS2 Lyrical实验7外设与回顾

---

2014-2016：

Ubuntu ROS Arduino Gazebo学习镜像iso说明（indigo版）

ROS机器人程序设计（原书第2版）学习镜像分享及使用说明

ROS机器人程序设计（原书第2版）补充资料 （零） 源代码、资料和印刷错误修订等

2017-2021：

ROS2机器人个人教程博客汇总（2021共6套）

---

本文强调批判式学习在ROS机器人开发教学中的核心地位，指出从ROS1 Indigo到ROS2 Lyrical的12年演进中，虽底层机器人原理一脉相承，但架构、工具链与API已发生根本性变革。所有公开教程素材均需“可能有误，请核实”警示，学生须以火眼金睛识别仿真隐含假设（如理想物理参数、无噪声通信、完整TF树），剥离版本绑定代码，推演真实硬件故障，并重构工程化方案。课程测评应聚焦跨版本迁移能力、缺陷分析与修正能力，杜绝照搬旧代码，真正实现从“跑通仿真”到“掌握工程落地”的跃迁。

---

ROS2 Lyrical 总结篇，回溯 ROS1 Indigo（批判式学习增强完整版）

定位：从 ROS1 Indigo（2014）到 ROS2 Lyrical（2026），横跨 12 年机器人开源框架演进。本总结适合课程复习、期末综述，完整列出全系列 LTS 版本谱系，重点突出底层架构差异、工具链变迁、仿真 / 导航 / 机械臂软件栈对比，系统标注教程素材里的隐含假设、典型坑点，适配批判式学习与课程测评出题。

ROS 全系列 LTS 版本清单（ROS1 → ROS2，按时间顺序）

LTS = Long Term Support，长期支持版；非 LTS 短期版本不列入。

ROS1 LTS

1. Indigo Igloo（2014.07），Ubuntu14.04 Trusty，维护至 2019-04，ROS1 首个 LTS
2. Kinetic Kame（2016.05），Ubuntu16.04 Xenial，维护至 2021-05
3. Melodic Morenia（2018.05），Ubuntu18.04 Bionic，维护至 2023-05
4. Noetic Ninjemys（2020.05），Ubuntu20.04 Focal，维护至 2025-05，ROS1 最后一个 LTS，ROS1 终点

ROS2 LTS

1. Dashing Diademata（2019.05），Ubuntu18.04 Bionic，维护至 2021-05
2. Foxy Fitzroy（2020.06），Ubuntu20.04 Focal，维护至 2023-05
3. Humble Hawksbill（2022.05），Ubuntu22.04 Jammy，维护至 2027-05（ROS2 最广泛使用 LTS）
4. Iron Irwini（2023.05），Ubuntu22.04 Jammy，维护至 2028-05
5. Jazzy Jalisco（2024.05），Ubuntu24.04 Noble，维护至 2029-05
6. Lyrical Luth（2026.05），Ubuntu26.04，维护至 2031-05，当前最新 ROS2 LTS

批判学习要点：

1. ROS1 所有 LTS 版本均已 EOL（停止维护），仅用于原理学习，禁止直接用于新项目开发；
2. ROS2 各 LTS 之间 API、插件、配置文件存在大量破坏性变更，不能跨版本直接复制代码；
3. 博客素材横跨 Indigo 到 Lyrical，很多案例是旧版本遗留代码，直接复制到 Lyrical 极易报错，必须带着火眼金睛甄别。

---

一、ROS1 Indigo Igloo 回顾（2014，ROS 第一代首个 LTS）

发布：2014.07，绑定 Ubuntu14.04 Trusty，ROS1 第一个 LTS 版本，维护至 2019 年 4 月 构建系统：catkin（逐步淘汰老 rosbuild），包编译 CMake+package.xml，Python2.7 为主 通信核心：Master 中心化架构（roscore）。所有节点启动必须依赖 master；master 一旦崩溃，全系统通信瘫痪，单点故障是最大硬伤。 仿真：Gazebo 2.x（也可手动升级 Gazebo5），gazebo_ros插件；RViz 作为可视化工具。

核心软件栈

• 导航：move_base + AMCL + costmap_2d；全局规划器global_planner，局部规划器base_local_planner。
• TF：TF1 库，tf_prefix处理多机器人；TF 缓存容易溢出、长时间运行内存持续上涨、卡顿。
• 机械臂：MoveIt!（ROS1 时代成熟），基于 MoveGroup，控制器ros_control。
• 记录工具：rosbag，仅基础记录回放，缺少 QoS 机制，图像、点云等高带宽传感器数据包极易丢包。

局限（批判要点，考试重点）

1. 无原生实时性，不支持工业硬实时控制；
2. 无 QoS 机制，话题数据不分优先级，大数据包容易丢包；
3. 原生面向单机，多机分布式通信调试门槛高、稳定性差；
4. Python2 生命周期终止，现代系统下编译、第三方依赖库大面积失效；
5. 全部 ROS1 版本 EOL，不再接收 bug 修复与安全更新，仅用于历史原理学习、老旧设备维护。

Indigo 的历史意义：奠定 ROS 在高校机器人教学、科研小车、机械臂抓取领域普及的基础。绝大多数经典教程、博客案例起源于 Indigo 时代，直接照搬 Indigo 代码到 Lyrical 会大面积报错，这正是批判式学习的核心切入点。

---

二、ROS2 Lyrical Luth 综述（2026，ROS2 最新 LTS）

发布：2026.05，LTS，支持周期到 2031 年 5 年维护；Tier1 平台 Ubuntu26.04 amd64/arm64、Windows11；配套仿真推荐 Gazebo Jetty LTS 底层架构：去中心化 DDS 通信，无 master。节点之间直接点对点通信，消除单点故障；RMW 抽象层，可切换不同 DDS/Zenoh 传输后端。 构建系统：ament_cmake，替代 catkin；colcon build编译工作空间。 语言：Python3.12，C++17，支持异步节点 AsyncNode（rclpy），Executor 执行器模型（EventsCBGExecutor 新特性）。

核心工具栈（完全匹配博客素材体系）

1. 模型描述：URDF/Xacro，robot_state_publisher，frame_prefix替代 ROS1 tf_prefix；check_urdf仅校验 XML 语法拓扑，不能校验 Gazebo 动力学参数（批判高频考点）
2. 可视化：RViz2，替换 RViz；支持多 TF 树、动态参数热更新。
3. 仿真：Gazebo Jetty，gz_*系列插件，ros2_control统一硬件 / 仿真控制器抽象，一套控制逻辑可同时适配仿真环境与实体硬件。
4. 导航栈：Nav2（替代 ROS1 move_base）
   • 全局规划器：PlannerServer，支持多种规划器插件切换
   • 局部规划器：DWB、ControllerServer；支持全向机器人holonomic_robot参数
   • AMCL2 定位，Lifecycle 生命周期节点，支持动态启停、重置定位。
5. 机械臂抓取：MoveIt2，Setup Assistant 生成 SRDF；ros2_control + JointTrajectoryController；基于 Action 接口完成长时抓取任务。
6. 数据记录：rosbag2，支持 MCAP/db3 存储、循环录制、消息丢失监控、自动带时间戳分段命名。
7. 通信原语：Topic、Service、Action（ROS1 无原生 Action）、Lifecycle 节点、参数服务、QoS（核心特性，每个话题独立配置可靠性、历史消息保留、超时策略）。

Lyrical 核心新特性

1. rclcpp 新增 Callback Group Events Executor，更好分离回调组，提升多线程实时性；
2. rclpy AsyncNode，原生支持 asyncio 异步编程；
3. rosbag2 增强：循环录制、消息丢失观测、分段文件名自带时间戳；
4. 参数 yaml 支持类型注解、数组参数范围校验；
5. Gazebo Jetty 支持 Zenoh 传输，提升仿真跨进程通信性能。

---

三、ROS1 Indigo ↔ ROS2 Lyrical 横向对比（批判式考点汇总）

表格

项目	ROS1 Indigo	ROS2 Lyrical	批判学习要点
通信架构	roscore 中心化，单点故障	DDS 去中心化，无 master	Indigo 代码依赖 master，移植 ROS2 必须移除所有 roscore 相关逻辑
构建系统	catkin_make / catkin build	colcon build + ament_cmake	CMakeLists.txt、package.xml 语法完全不同，无法直接复制
TF 变换	TF1，长期运行内存泄漏	TF2，tf2_ros，frame_prefix	TF1 代码不能直接迁移；时间戳处理逻辑完全重构
导航框架	move_base（单进程大模块）	Nav2，模块化 Server 组件	move_base 不可直接移植；Nav2 强依赖完整 TF 树，TF 断裂直接失效
机械臂控制	MoveIt! + ros_control	MoveIt2 + ros2_control	ros2_control 为全新架构，控制器 yaml、接口全部重写
通信质量	无 QoS，一刀切	QoS 策略，话题独立配置	Indigo 旧代码不考虑丢包，Lyrical 必须按传感器类型配置 QoS
通信接口	Topic / Service	Topic / Service / Action / Lifecycle	Action 是 ROS2 独有，导航、抓取这类长任务优先选用 Action
仿真环境	Gazebo2.x，gazebo_ros 插件	Gazebo Jetty，gz_ros2	插件命名空间、spawn 节点调用方式完全改写
Python 版本	Python2.7	Python3.12	语法、库大量不兼容，print、异常、编码坑点繁多

拓展批判考点：ROS2 内部多个 LTS 之间（Foxy→Humble→Jazzy→Lyrical），同样存在插件更名、参数废弃、API 破坏性变更，Humble 的 yaml 配置不能直接复制到 Lyrical。

四、从 Indigo 到 Lyrical，工程思维变迁（论述大题素材）

ROS1 Indigo：科研原型优先

Indigo 时代目标是快速验证机器人算法，适配高校论文、原型小车开发。工程层面短板突出：不考虑实时性、多机协同、安全与产品化。大量教学教程为简化理解，刻意隐藏工程缺陷：写死参数、硬编码 frame_id、随便填写惯性矩阵、默认理想环境。这就是博客素材必须批判式阅读的根源。

批判点：Indigo 大量示例代码仅在单机仿真环境稳定运行；放到真实硬件、多机器人、长时间连续运行场景，极易失效。

ROS2 Lyrical：面向工程落地

ROS2 整体设计目标面向工业移动机器人、机械臂、多机协同、实时控制、产品交付。模块化架构、生命周期管理、QoS、DDS 安全策略，支持节点动态启停。

批判点：Lyrical 配套博客示例仍然带有大量仿真环境隐含假设：惯性参数为仿真凑数、里程计采用纯速度积分（长期漂移）、Gazebo 插件仅适配仿真，硬件驱动需要重新开发。仿真一键跑通 ≠ 实体机器人可用。

五、迁移与学习的批判式总结（核心，适配课程测评）

1. 不能直接把 Indigo 经验平移到 Lyrical 很多 Indigo 时代形成的思维惯性：依赖 roscore、TF1、move_base、catkin_make，放到 ROS2 环境会完全失效。学生最常见踩坑：直接复制老博客代码，仅修改少量名称，期望直接运行。
2. 跨版本通用底层知识（可复用，不受 ROS 版本限制） URDF/Xacro 机器人模型原理、连杆关节拓扑、TF 坐标变换数学原理、代价地图原理、A * 全局规划、DWA 局部规划、机械臂运动学（KDL）、激光 SLAM 概率模型。

原理一脉相承，变化的只是 API、工具、配置文件。课程学习核心：掌握机器人底层理论，而不是死记某一个 ROS 版本 API。

1. 批判式学习四步法（火眼金睛，测评核心能力） 拿到任意博客素材（无论 Indigo/Humble/Lyrical），强制按四步分析： ① 识别隐含假设：是否仅仿真可用、版本锁定、传感器 / 物理环境理想化； ② 剥离知识：区分通用机器人理论 和 版本绑定的 API / 工具代码； ③ 缺陷推演：分析仿真掩盖了哪些问题，部署到真实硬件会出现什么故障； ④ 工程修正：重构代码、修改配置，适配目标硬件，编写可测评工程代码。

六、课程复习思考题（可直接追加到试卷，批判式）

1. ROS1 Indigo 依赖 roscore，ROS2 Lyrical 无 master 架构，请分析两种架构优缺点，以及 roscore 单点故障会带来哪些实际场景问题？
2. Indigo 的 move_base 和 Lyrical Nav2 在架构上有什么本质区别？Nav2 采用多 Server 模块化带来哪些优势，又增加哪些工程复杂度？
3. 同一段 URDF 模型，在 Indigo Gazebo2 仿真正常，迁移到 Lyrical Gazebo Jetty 出现模型穿透、无重力，请列举至少 3 个可能的原因。
4. 简述 TF1（Indigo）和 TF2（Lyrical）的差异；frame_prefix相比tf_prefix解决了什么问题？
5. 批判论述：Indigo 时代大量开源教程为简化教学，刻意简化动力学参数与里程计模型。把这类示例直接迁移到 Lyrical 仿真，再部署到真实机器人，会遇到哪些典型工程问题？
6. 拓展题（新增，跨 LTS）：ROS2 不同 LTS 版本（Humble、Jazzy、Lyrical）之间，为什么不能直接复制导航 yaml、MoveIt2 插件配置？举例说明版本迁移时的典型破坏性变更。

七、一句话总览

ROS1 Indigo 开启机器人开源原型时代；历经 Kinetic、Melodic、Noetic，ROS1 完成历史使命；ROS2 从 Dashing、Foxy、Humble、Iron、Jazzy 一路演进到 Lyrical，转向工程落地。底层机器人原理一脉相承，但框架架构、工具链持续重构；学习切忌直接复制旧版本案例，坚持批判式学习，分清仿真假设与真实硬件边界。

---

ROS1 Indigo → ROS2 Lyrical 批判式学习材料总览（教学测评版）

核心思想：教程可以复现仿真 ≠ 可直接用于真实硬件；仿真示例存在大量隐性假设，学习者必须主动识别假设、找出局限、修正缺陷，才算真正掌握机器人开发，而不是复制粘贴跑通仿真。所有博客示例均标注：可能有误，请核实，学生需要带着火眼金睛阅读、复现、排错、修正，用于课堂作业、实验报告、期末测评。

一、版本谱系总览：从 ROS1 Indigo（2014）到 ROS2 Lyrical（2026）

横跨 12 年 LTS 演进：ROS1 Indigo(2014) → Kinetic → Melodic → Noetic → ROS2 Humble → Lyrical(2026)。 整套公开博客素材完整覆盖：基础命令行工具、调试工具链、RViz/RViz2 三维可视化、URDF/Xacro 机器人建模、Gazebo 全版本仿真、TF/TF2 坐标变换、SLAM 建图、自主导航巡逻、MoveIt/MoveIt2 机械臂抓取放置、第三方外设驱动扩展、移动操作臂综合项目实践。

重要共性提醒：

1. ROS1 全部版本已经停止官方维护，仅用于历史原理学习，禁止直接在新项目中照搬 ROS1 Indigo/Kinetic 代码；
2. ROS2 Lyrical 为新一代 5 年长期支持版本，适配 Ubuntu26.04，但博客示例大量继承仿真环境预设条件，不能不加修改直接移植实体机器人；
3. 不管 ROS1 还是 ROS2，底层机器人理论（URDF 模型原理、TF 坐标变换、代价地图、运动学、碰撞检测）是通用的；但是 API、构建系统、通信架构、插件接口随版本发生巨大变化，代码不可直接拷贝迁移。

二、素材清单（分大类，全部带有批判式阅读标记）

每一份材料阅读前置提醒：可能有误，请核实。仿真环境存在隐含假设，复现后必须分析仿真与真实硬件差异。

2026 ROS2 Lyrical 系列（新版主教材，第 4‑7 章：建模‑导航‑机械臂抓取）

1. 课程大纲总览

《ROS 机器人程序设计》课程教学大纲-2026- kinetic-lyrical_ros2机器人应用开发工程师网盘下载-CSDN博客

批判阅读提示：大纲给出完整学习路径，但大纲只描述理想学习结果，没有列出每个知识点的坑点、边界条件，学生需要自己补充 “什么场景这套方案会失效”。

2. 必须批判式学习的基础理论（建模、TF、里程计、导航前置、MoveIt2 基础）

共性问题：全部示例在 Gazebo 仿真环境调通；大量物理参数为仿真凑数；忽略真实硬件噪声、延迟、丢包；很多代码省略异常捕获、边界判断。 何时开启 ROS 2 Lyrical Luth 之旅最为合适？_ros2lyrical支持-CSDN博客 ROS 2 Lyrical Luth 第1章 系统入门教程-CSDN博客 ROS 2 Lyrical 第2章 ROS 2系统架构与核心概念_ros2 架构文档-CSDN博客 ROS 2 Lyrical 第3章 可视化与系统调试工具_ros2 日志系统与调试工具-CSDN博客 ROS 2 Lyrical 第4章 URDF机器人建模与Gazebo Garden仿真-CSDN博客 ROS 2 Lyrical 第5章 导航前置：TF坐标变换、传感器、里程计与SLAM建图-CSDN博客 ROS 2 Lyrical 第6章 Nav2自主导航完整配置与实操_ros2 导航开发-CSDN博客 ROS 2 Lyrical 第7章 MoveIt 2机械臂运动规划与抓取仿真实操-CSDN博客 ROS 2 Lyrical 第8章 传感器与执行器集成-CSDN博客 ROS 2 Lyrical 第9章 计算机视觉与摄像头应用_ros2能识别的usb摄像头-CSDN博客 ROS 2 Lyrical 第10章 点云处理与 PCL 库集成_ros2 lyrical-CSDN博客 ROS 2 Lyrical 全栈技术体系硬核综述与进阶展望-CSDN博客

共性批判要点（可直接用于考题）

1. URDF/Xacro 章节：check_urdf只能校验 XML 语法拓扑，无法校验 collision、inertial 惯性矩阵、mesh 文件路径、gazebo 插件正确性；示例惯性参数为仿真随手填写，真实机器人需要实测质量与惯性张量。
2. TF2 与里程计章节：手写速度积分里程计天然存在时间累积漂移；仿真中没有传感器噪声；实体机器人必须增加 IMU 融合、异常时间差保护；示例代码缺少异常捕获。
3. Nav2 导航章节：yaml 参数完全适配仿真小车；footprint、膨胀半径、速度加速度不能直接复制到实物；Nav2 强依赖完整 TF 树，仿真 TF 永远不会断裂，硬件场景极易出现 TF 超时、变换丢失。
4. MoveIt2 章节：demo 虚拟控制器仅做运动学预览，不能对接 Gazebo / 真实硬件；示例抓取逻辑没有力反馈、没有物体检测，仿真依靠理想物理接触，现实极易抓取失败。

3. 测评样题参考（出题范式参考，用于试卷、实验报告）

《ROS 机器人程序设计》课程习题资料-2026-lyrical-CSDN博客

批判阅读提示：样题给出现成题干，教师使用时，应当增加批判类设问：找出示例代码隐患、分析仿真假设、给出硬件修改方案。

4. 必须批判实践的项目案例（仿真项目，移动机器人、移动机械臂、抓取放置）

共性：全部项目可以一键在 Lyrical+Gazebo Garden 复现；但是全部属于仿真理想条件，忽略硬件驱动、通信延迟、传感器噪声、电机限幅、网络 DDS QoS 问题。 ROS2 Lyrical实验1系统入门-CSDN博客 ROS2 Lyrical实验2架构与核心-CSDN博客 ROS2 Lyrical实验3工具进阶-CSDN博客 ROS2 Lyrical实验4机器人模型-CSDN博客 ROS2 Lyrical实验5导航Nav2-CSDN博客 ROS2 Lyrical实验6机械臂MoveIt2-CSDN博客 ROS2 Lyrical实验7外设与回顾-CSDN博客

项目类共性批判设问（测评学生掌握程度）

1. 指出该仿真项目 3 条以上的仿真隐含假设；
2. 如果把这套项目部署到真实实体机器人，需要修改哪些模块、配置、代码？
3. 仿真不会出现哪些硬件常见故障？给出排查流程与修复方案。

2014‑2016 ROS1 Indigo 时代经典素材（历史版本，用于对比迁移学习）

⚠️ 全部基于 Ubuntu14.04 + Python2.7 + roscore 中心化架构，代码不能直接运行在 ROS2，用于理解历史渊源，对比架构差异，做版本迁移练习。 Ubuntu ROS Arduino Gazebo学习镜像iso说明（indigo版）_ubuntu ros arduinogazebo学习镜像iso 百度云-CSDN博客 ROS机器人程序设计（原书第2版）学习镜像分享及使用说明_ros机器人程序设计(原书第2版)-CSDN博客 ROS机器人程序设计（原书第2版）补充资料 （零） 源代码、资料和印刷错误修订等 2017年02月22日更新_ros机器人程序设计第二版 pdf-CSDN博客

ROS1 Indigo 素材共性批判点

1. 依赖 roscore 单点 master，master 崩溃整个系统通信瘫痪；ROS2 DDS 去中心化彻底移除 master 概念。
2. 基于 catkin_make /roslaunch XML，ROS2 使用 colcon + Python Launch，构建、启动文件语法完全重构。
3. TF1 存在内存泄漏，长时间运行卡顿；没有 QoS，传感器大数据极易丢包。
4. move_base 单进程大模块，Nav2 拆分为多 Server 模块化架构。
5. Python2.7 已经 EOL，库大量失效，只能阅读原理，不建议真机复现。

2017‑2021 ROS1 Kinetic‑Noetic 过渡时代素材

承接 ROS1 后期版本，向 ROS2 过渡，可用于对比 ROS1/ROS2 异同，做迁移训练。 ROS2机器人个人教程博客汇总（2021共6套）_ros2教程百度云-CSDN博客

该阶段素材共性批判点

1. 依然是 roscore 架构，部分代码已经出现向 ROS2 移植的尝试；
2. 大量工具、消息接口名称相似，但底层实现不同，容易造成学生 “看起来差不多直接复制” 的误区；
3. Gazebo、moveit、navigation 的参数配置和 ROS2 存在大量细节差异，不可直接照搬 yaml。

三、跨版本共性批判框架（通用答题模板，考试 / 实验通用，突出共性）

无论阅读 ROS1 Indigo 还是 ROS2 Lyrical 的博客示例，都强制学生按照下面四步开展批判式学习，这是测评核心能力，区分 “跑通仿真” 和 “真正懂机器人开发”。

步骤 1：识别隐含仿真假设（火眼金睛第一步）

逐条列出教程中没有明说、但是代码 / 配置依赖的理想条件，常见共性假设包括：

1. 通信永远正常，无延迟、无丢包，DDS/QoS 问题不存在；
2. 传感器无噪声、无数据丢失，话题频率稳定；
3. 物理参数理想化：惯性、质量随便填写，不会出现动力学异常；
4. TF 坐标变换永远稳定，不会超时、不会变换丢失；
5. 电机、驱动器响应无限快，没有限幅、没有滞后；
6. 系统时钟完美同步，时间戳不会错乱。

步骤 2：区分【通用理论知识】与【版本绑定代码】

• ✅通用，跨 ROS1/ROS2 都能用的原理知识：URDF 模型逻辑、连杆‑关节拓扑、TF 坐标变换数学原理、代价地图原理、A‑star/DWA 规划算法、机械臂运动学正逆解、碰撞检测逻辑、SLAM 概率模型。
• ❌版本绑定，不能直接复制：构建系统命令、launch 格式、节点 API、消息头文件、插件文件名、yaml 参数、工具命令（rospack / ament_index_get_resource，catkin_make / colcon build）。

测评考点：要求学生从一段 ROS1 Indigo 旧代码中，剥离通用原理，指出哪些代码是 ROS1 专属，在 ROS2 Lyrical 中必须重写。

步骤 3：推演：假设脱离仿真环境，会出现什么故障现象？

共性故障推演方向：

1. 里程计长时间运行发生漂移；
2. 定位粒子云发散，AMCL 定位失效；
3. 规划器报No valid plan无法生成路径；
4. MoveIt 规划成功，但硬件机械臂完全不动；
5. 话题消息丢失，传感器数据断断续续。

步骤 4：给出修正方案（配置修改 / 代码补全异常捕获 / 硬件适配改造）

要求不只是定性描述，需要写出关键参数修改、代码片段、排查命令。

四、典型通用测评题型（突出共性，不局限单一章节）

可直接用于作业、试卷，全部贯彻批判式学习。

判断题（必须写出批判理由，只写对错不得分）

1. ROS1 Indigo 的 URDF 模型原理完全一样，所以可以直接把 Indigo 完整 URDF 文件复制到 ROS2 Lyrical 直接用于 Gazebo 仿真。（）
2. check_urdf校验通过，就代表 Gazebo 仿真一定可以正常完成动力学仿真。（）
3. 仿真中可以跑通的 Nav2 全套 yaml 参数，直接拷贝给真实物理机器人就可以完成导航。（）
4. ROS1 move_base 和 ROS2 Nav2 实现的导航功能类似，所以 move_base 的配置文件可以直接在 Nav2 使用。（）

简答‑批判分析题（通用）

1. 对比 ROS1 Indigo 中心化 roscore 架构和 ROS2 Lyrical 去中心化 DDS 架构，分别写出各自优势、缺陷；写出 roscore 单点故障在真实项目中会引发哪些现象。
2. 很多教程给出的里程计示例采用单纯速度积分，无论 ROS1 还是 ROS2 仿真都可以跑通，请批判该方案的固有缺陷；仿真环境掩盖了哪些问题？真实硬件如何缓解该缺陷？
3. MoveIt/MoveIt2 的 demo 虚拟演示模式可以完成轨迹规划，但是不能直接用于 Gazebo 或者实体机械臂，请说明仿真示例的隐含假设，要对接硬件必须补充哪些配置？

综合论述题

论述：大量 ROS 博客示例，从 ROS1 Indigo 到 ROS2 Lyrical，都可以在仿真一键复现，但是到真实硬件就大量报错。请从：机器人模型参数、TF 与里程计、导航参数、机械臂控制器四个维度分析共性的仿真假设，并说明硬件环境如何修正。

五、教学使用注意（批注给教师）

1. 全部博客资源都要给学生前置提示：可能有误，请核实，不允许学生直接把博客代码当作标准答案；
2. 测评打分重点不在于 “能不能把仿真跑通”，而在于能不能识别出材料的局限、隐含假设，并且给出修正思路；
3. 鼓励学生横向对比 ROS1 Indigo 老案例与 ROS2 Lyrical 新案例，分辨原理不变、接口改变的部分，锻炼跨版本迁移能力；
4. 仿真是验证工具，不是最终产品环境，批判式学习的目标就是打破 “仿真即现实” 的思维误区。

---

ROS2 Lyrical 批判式学习测评试题（基于 4‑7 章素材）

说明：本套题目要求学生不能直接照搬博客示例代码，必须识别素材里的假设、坑点、版本依赖缺陷、工程隐患，先批判找出问题，再给出修正方案，侧重工程实操排错能力，适合课后作业 / 实验考核。 批判式答题范式：①指出原文素材隐含假设 / 错误 / 局限；②说明为什么会出问题；③给出修改后的配置 / 代码 / 操作步骤。

一、判断题（必须写出批判理由，只写对错不得分）

1. 在 ROS2 Lyrical 中，只要写好 URDF 的<visual>标签，直接用 Gazebo Garden 就可以完成动力学仿真，碰撞和惯性参数可以省略。（）
2. Xacro 可以在 launch 文件中通过Command(["xacro ", model])实时解析，不需要提前手动执行xacro命令生成中间 urdf 文件，该方式是工程上推荐的做法。（）
3. Nav2 运行的硬性条件：只要有差速底盘接收/cmd_vel，就算没有完整 TF2 树，也可以正常完成自主导航。（）
4. AMCL2 粒子云一直高度发散，只需要把min_particles参数调得更小就可以解决定位漂移问题。（）
5. MoveIt2 的 demo.launch.py 虚拟控制器模式，可以直接对接 Gazebo 物理仿真执行抓取 pick‑place 任务，不需要 ros2_control 和 JointTrajectoryController 配置。（）

二、选择题（多选，每小题需要简单写出批判依据）

1. 某同学直接复制博客中四轮小车 URDF，在 Gazebo Garden 仿真发现小车直接穿透地面、不受重力，可能的原因有（）【多选】 A. link 缺少<collision>碰撞标签 B. link 缺少<inertial>惯性质量与惯性矩阵 C. joint 全部设置为fixed，车轮没有使用continuous关节 D. gazebo 标签缺失，没有设置 link 材质
2. 关于 TF2 坐标树，Nav2 导航必须的完整坐标变换链，下面正确的是（） A. map → odom → base_footprint → laser_link B. odom → map → base_footprint → laser_link C. base_link → odom → map → laser_link D. map → base_footprint → odom → laser_link
3. 运行 Nav2，下发 2D Nav Goal 之后，规划器提示No valid plan无有效路径，下面哪些是常见诱因（）【多选】 A. footprint轮廓设置过大，机器人被膨胀代价地图完全包围 B. inflation_radius障碍物膨胀半径设置过大 C. AMCL 定位粒子云严重发散，机器人在地图中位姿错误 D. 全局代价地图static_map设置为 true，但是 map_server 没有成功加载地图
4. MoveIt2 使用 Setup Assistant 生成配置包，下面说法存在工程风险的是（）【多选】 A. 自碰撞矩阵采样次数越大越准确，但会增加 SRDF 文件生成耗时 B. 移动底盘上的机械臂，虚拟关节必须配置，父 frame 设置为odom C. Planning Groups 规划群组只需要把夹爪关节加入arm群组，不需要单独建立gripper群组 D. 末端执行器 end effector 配置，父连杆选择机械臂底座 base_link

三、简答‑批判分析题（核心，考察火眼金睛，识别博客素材中的隐含假设）

答题格式：①批判素材的局限 / 隐含前提；②风险后果；③工程修正方案。

1. 素材第四章给出check_urdf robot1.urdf校验 URDF 模型。 批判问题：check_urdf校验成功，是否代表 Gazebo 仿真一定正常？说明理由，列举 3 个 check_urdf 无法检测出来但是会造成仿真异常的问题点。
2. 第五章手写里程计代码，采用速度积分方式计算x,y,th发布/odom话题。 批判问题：纯积分里程计有什么天然缺陷？在长时间仿真或者真实机器人运行会出现什么现象？Nav2 导航中如何缓解该问题？。
3. 博客示例 DWB 局部规划器配置：

DWBLocalPlanner:
 max_vel_x: 0.2
 min_vel_x: 0.05
 max_vel_theta: 0.15
 min_vel_theta: -0.15
 acc_lim_x: 2.5
 acc_lim_theta: 3.2
 holonomic_robot: false

批判问题：如果把这套差速小车 yaml 直接拷贝给麦克纳姆轮全向移动机器人使用，会发生什么现象？应该修改哪一个关键参数，为什么？。

1. MoveIt2 编程示例，直接使用setPoseTarget()设置一个末端笛卡尔位姿然后调用plan()。 批判问题：写出 2 种即使位姿在工作空间范围，仍然规划失败的现实场景（不考虑代码语法错误）。

四、排错实操题（模拟学生复现博客代码踩坑场景，写出排查步骤 + 修复代码 / 配置）

1. 场景：复现第四章 Gazebo 小车仿真，Xacro、launch 文件完全复制示例。现象：RViz2 中 RobotModel 小车显示正常；Gazebo 里面 spawn 机器人之后，机器人通体纯白色，激光雷达插件不输出/robot/scan话题。 请分析全部可能原因，并给出修复片段。
2. 场景：Nav2 全套启动成功，map_server 成功加载地图，RViz2 可以看到静态地图；执行2D Pose Estimate(P)给出初始位姿后，AMCL 粒子云迅速全部消失。请给出排查流程，列出 3 个最可能原因以及参数调整方案。
3. 场景：MoveIt2 Gazebo 抓取仿真，move_group 规划轨迹成功，RViz2 预览绿色轨迹完全正常；但是 Gazebo 中机械臂一动不动，完全不执行轨迹。 批判排查：从 ros2_control、controller、joint_trajectory_controller 角度分析，给出至少 3 个故障点。

五、综合编程‑改错题（找出代码 bug，注释标出，写出修正后完整片段）

5‑1 里程计发布节点片段（来自第五章素材，存在多处隐患）

void timer_cb()
{
 rclcpp::Time curr = this->get_clock()->now();
 double dt = curr - last_time_;
 last_time_ = curr;
 double dx = vx_ * cos(th_) * dt;
 double dy = vx_ * sin(th_) * dt;
 double dth = vth_ * dt;
 x_ += dx; y_ += dy; th_ += dth;

 geometry_msgs::msg::TransformStamped t;
 t.header.frame_id = "odom";
 t.child_frame_id = "base_footprint";
 t.transform.translation.x = x_;
 t.transform.translation.y = y_;
 t.transform.rotation = tf2::toMsg(tf2::Quaternion(tf2::Vector3(0,0,th_),0));
 tf_broad_->sendTransform(t);

 nav_msgs::msg::odom_msg;
 odom_msg.header.frame_id = "odom";
 odom_msg.child_frame_id = "base_footprint";
 odom_msg.pose.pose.position.x = x_;
 odom_msg.pose.pose.position.y = y_;
 odom_msg.pose.pose.orientation = t.transform.rotation;
 odom_msg.twist.twist.linear.x = vx_;
 odom_msg.twist.angular.z = vth_;
 odom_pub_->publish(odom_msg);
}

任务：找出代码中语法 bug + 工程隐患，标注行号，写出修复代码。

5‑2 Nav2 Action 客户端发送导航目标（第六章素材）

void send_goal(double x, double y, double yaw)
{
 if (!client_->wait_for_action_server(std::chrono::seconds(5))) {
 RCLCPP_ERROR(get_logger(), "Nav2 Action服务器未启动");
 return;
 }
 NavigateToPose::Goal goal;
 goal.pose.header.frame_id = "map";
 goal.pose.pose.position.x = x;
 goal.pose.pose.position.y = y;
 goal.pose.pose.orientation.w = cos(yaw/2);
 goal.pose.pose.orientation.z = sin(yaw/2);
 auto send_future = client_->async_send_goal(goal);
}

批判点：代码功能上存在什么工程缺陷？只发送 goal，没有处理 future，会带来什么问题？如何完善代码。

六、拓展论述题（批判式总结）

博客教程给出的整套 4‑7 章案例，可以一键复制粘贴在 Ubuntu26.04 + ROS2 Lyrical 复现，但是放到真实硬件机器人上面会有大量不适用的地方，请从下面 4 个维度，批判分析博客示例的仿真环境隐含假设，并写出真实硬件需要修改哪些部分：

1. URDF/Xacro 模型（link 惯性、joint 类型、传感器插件）
2. TF2 与里程计
3. Nav2 代价地图、规划器参数
4. MoveIt2 ros2_control 控制器与抓取逻辑

---

参考答案（简要版，供教师阅卷）

一、判断

1. ×；批判：Gazebo 动力学仿真必须 collision、inertial，visual 仅管渲染；缺失会重力异常、穿透地面。
2. √；批判：该方式为 ROS2 官方推荐，launch 内部调用 xacro 命令实时解析，不需要磁盘输出中间 urdf。
3. ×；批判：Nav2 四大硬性条件之一就是完整 TF2 树，坐标链断裂，代价地图、AMCL 无法工作。
4. ×；批判：粒子发散应当增大 min_particles，检查激光 /odom 数据、2D Pose Estimate 初始化；调小粒子数量会加剧定位失效。
5. ×；批判：demo 是虚拟仿真，不连接 Gazebo 硬件接口；物理仿真必须配置ros2_control+JointTrajectoryController。

二、多选

1. A、B；C 错误，车轮 joint 为 fixed 只会模型外观正常，不会造成穿透地面；D 材质缺失只会纯白，不影响重力。
2. A
3. A B C D
4. C D；C 夹爪建议独立 gripper 群组；D 末端执行器父连杆应当是腕部 tool_link，不是底座 base_link。

三简答批判分析

1. check_urdf仅校验 XML 语法、父子 link 关节拓扑；不校验 collision/inertial 参数、gazebo 插件语法、mesh 文件路径有效性、joint 限位参数合法性。这些全部语法合法但仿真报错。
2. 速度积分里程计：误差随时间累积漂移；长时间运行 x/y/ 角度和真实位置偏离；缓解：仿真可以依赖 Gazebo 输出 odom；实体机器人用 IMU + 编码器融合；导航依赖 AMCL 利用激光定期修正 odom 漂移。
3. holonomic_robot: false代表非全向差速轮；麦克纳姆轮必须改为true；如果不改，DWB 规划不会生成横向平移速度，全向机器人无法横移。
4. 示例：①机械臂存在自碰撞；②目标位姿处于奇异点；③规划场景里面存在障碍物，虽然笛卡尔坐标在工作空间，但是路径被障碍物阻断。

四排错实操

1. 现象：Gazebo 模型纯白，激光无话题

• 原因 1：缺少<gazebo>标签设置 link 材质，渲染纯白；
• 原因 2：Xacro 中激光雷达 gazebo 插件文件名写错（库文件名错误）；
• 原因 3：spawn_entity 启动时 topic、entity 名称错误，没有正确加载完整带 gazebo 插件的 URDF。

1. AMCL 粒子云直接消失

• ①激光话题/scanframe_id 与 TF 的 laser_link 不匹配；
• ②laser_max_beams参数不合理；
• ③地图坐标系 map 和 odom 变换异常，TF 树断裂。

1. MoveIt 规划成功，Gazebo 机械臂不动

• ①ros2_control插件没有正确加载进 Gazebo；
• ②yaml 控制器里面 joint 名字和 URDF 关节名大小写 / 名字不一致；
• ③moveit 控制器配置没有映射到 JointTrajectoryController Action 接口。

五改错题

5‑1 里程计

bug1：double dt = curr - last_time_;，时间相减得到 rclcpp::Duration 对象，不能直接赋值 double；改为double dt = (curr - last_time_).seconds(); bug2：nav_msgs::msg::odom_msg; 变量声明语法错误，应当nav_msgs::msg::Odometry odom_msg; 隐患：没有做 dt>0 保护，节点刚启动 dt=0 会出现计算异常。

5‑2 Nav2 send_goal

缺陷：async_send_goal返回 future 没有保存，无法获取目标执行结果，不知道导航成功 / 失败；工程上需要保存 future，注册回调监听 goal 响应与执行结果。

六论述题（仿真 vs 真实硬件批判）

1. URDF：博客惯性参数为仿真凑数，真实机器人需要实际称重计算惯性矩阵；Gazebo 插件不能在真实硬件运行，需要替换真实驱动。
2. TF2：仿真 odom 由 gazebo 插件输出；实体机器人需要编码器 + IMU 融合发布 odom；TF 需要确认传感器实际安装位置。
3. Nav2 参数：仿真的 footprint、max 速度、inflation_radius 是仿真小车参数；真实机器人需要按照实物尺寸重调；真实机器人噪声大，需要调整 AMCL 激光模型噪声参数。
4. MoveIt2：仿真ros2_control是 Gazebo 模拟硬件；实体机器人对接真实电机驱动；抓取在仿真中物体附加到夹爪，真实硬件需要做力反馈检测判断是否抓取成功。