企业官网建设流程全解析

1. 项目概述：一个被低估的ROS配置实践入口

“ros_demo系列——demo_yaml”这个标题乍看平平无奇，甚至有点像某次课后练习的临时命名，但在我带过十几期ROS实践训练营、参与过多个机器人中间件集成项目之后，越来越确信：YAML文件从来不是配角，而是ROS系统行为的“宪法性文档”。它不写逻辑，却决定逻辑如何加载；不执行动作，却规定动作在何时、以何种权限、由哪个节点触发。而“demo_yaml”这个看似简单的命名，恰恰踩中了ROS初学者最常卡壳的三个断点：不知道YAML该写什么、不知道写在哪、更不知道改了之后系统到底听没听懂。

我见过太多人卡在roslaunch报错“invalid yaml syntax”上一小时，最后发现只是少了一个空格；也见过团队在多机部署时反复调试通信延迟，最终定位到params.yaml里一个浮点数用了科学计数法（1e-3），而某版本ROS参数服务器对这种格式解析不稳定。这些都不是理论问题，是每天真实发生的、影响进度的实操断点。“ros_demo系列——demo_yaml”的价值，正在于它把这一整套隐性知识显性化、结构化、可验证化——它不是一个孤立的Demo，而是一套面向工程落地的ROS配置方法论起点。适合刚跑通turtlesim想进阶的开发者、正在从单机Demo转向真实小车调试的硬件同学、以及需要快速统一团队参数管理规范的项目负责人。它解决的不是“能不能跑”，而是“能不能稳、能不能查、能不能传”。

2. 内容整体设计与思路拆解：为什么从YAML切入ROS工程化？

2.1 不是“学YAML”，而是“用YAML重建ROS认知框架”

很多教程把YAML当作一种“数据格式”来教，这恰恰是最大的误区。在ROS语境下，YAML文件承担着三重不可替代的角色：

• 参数声明层（Declaration Layer）：定义节点运行所需的全部外部可调参数，如PID控制器的Kp、Ki值，激光雷达的range_min阈值，视觉模块的confidence_threshold。这些值一旦硬编码在C++/Python源码里，每次微调都要重新编译，完全违背ROS“松耦合、易调试”的设计哲学。

• 节点组织层（Orchestration Layer）：通过roslaunch的.launch文件引用YAML，实现节点启动顺序、命名空间（namespace）隔离、参数作用域（private vs global）的精确控制。比如一个移动底盘节点和它的导航规划器，必须在同一个命名空间下共享/tf坐标系前缀，否则/base_link永远找不到/map——这种依赖关系，靠手敲rosrun命令根本无法稳定复现。

• 环境抽象层（Abstraction Layer）：同一套算法代码，通过切换不同YAML文件，即可适配仿真环境（Gazebo）、实车测试（Jetson Nano）、甚至产线部署（工控机）。我参与过的一个AGV项目，核心导航栈代码零修改，仅靠三套YAML（sim.yaml、dev.yaml、prod.yaml）就完成了从实验室到仓库的全流程迁移，每套文件只差异12个关键参数，却规避了90%的环境适配风险。

因此，“demo_yaml”系列的设计起点，就是拒绝把YAML当静态配置文件讲，而是把它作为ROS系统行为的“控制平面”来构建。每一个Demo都对应一个真实痛点：demo_params.yaml解决参数分散难管理；demo_namespaces.yaml解决多节点命名冲突；demo_remap.yaml解决话题重映射的调试盲区；demo_include.yaml解决大型系统配置的模块化拆分。这不是语法练习，是工程思维的预演。

2.2 为什么选择“Demo”而非“Tutorial”？——降低认知负荷的刻意设计

ROS官方文档和主流教程常陷入一个陷阱：用复杂案例（如完整SLAM建图）反向推导YAML用法。结果初学者看到<param name="robot_description" command="$(find xacro)/xacro.py $(arg model)" />这种嵌套命令，第一反应是“这得学多少shell和xacro语法？”。而“demo_yaml”系列反其道而行之：每个Demo只聚焦一个YAML特性，且确保其效果能被肉眼或最简命令即时验证。

例如demo_params_simple.yaml内容只有四行：

robot: wheel_diameter: 0.15 max_velocity: 0.5 pid: kp: 1.2 ki: 0.05

配套的验证方式不是跑仿真，而是执行一条命令：

rosparam get /robot/max_velocity # 输出：0.5

这种“改一行，敲一命令，立刻见结果”的反馈闭环，把抽象的配置概念锚定在具体的操作动作上。我在某高校机器人社团带训时做过对比：使用传统教程的小组，平均需要3.2小时才能理解参数服务器机制；而采用“单点Demo+即时验证”模式的小组，平均47分钟就能独立完成参数动态调整并观察到turtlesim速度变化。工程学习的本质，是建立“操作-现象-原理”的强关联，而不是先背诵概念再碰运气。

2.3 规避常见设计陷阱：为什么不用JSON或TOML？

有开发者会问：YAML语法太灵活，缩进敏感，容易出错，为什么不用更严格的JSON？或者更现代的TOML？这个问题直指ROS生态的底层约束。答案很务实：兼容性、工具链成熟度、社区约定俗成。

• ROS 1的rosparam命令原生只支持YAML和XML，JSON需额外转换（rosparam load xxx.json会报错，必须先转YAML）；
• 所有主流ROS IDE（如RQT、Robot Operating System Dev Tools）的参数编辑器，UI默认按YAML结构渲染；
• ROS 2虽支持多种格式，但launch_ros的DeclareLaunchArgument仍以YAML为事实标准，且大量开源包（如nav2_bringup）的默认配置全为YAML。

我试过强行用TOML替代，在一个包含23个子模块的导航系统中，光是修改launch文件里的param_file路径和ros2 param load命令就花了两天，而团队其他成员因IDE不识别TOML导致参数编辑失效，调试效率反而下降。技术选型不是比谁新，而是比谁让团队80%的人能少踩坑。YAML的“不完美”，恰恰是ROS工程实践中最稳健的选择。

3. 核心细节解析与实操要点：YAML在ROS中的真实工作流

3.1 YAML语法的“安全边界”：哪些写法绝对要避开？

ROS对YAML的解析并非完全遵循YAML 1.2标准，存在若干关键限制。以下是我从ROS官方Issue、邮件列表及实际项目中总结的“高危写法清单”，每一条都对应过真实故障：

提示：以下写法在本地yamllint检查可能通过，但在ROS运行时必然失败

特别强调“科学计数法”问题：ROS参数服务器在解析浮点数时，会先尝试float()转换，而Python的float("1e-3")虽能成功，但ROS内部类型校验会失败。我曾在一个机械臂力控项目中，因force_threshold: 5e-2导致力矩传感器数据始终不触发，排查三天才发现是这个隐藏雷区。所有浮点参数，务必写成0.05而非5e-2，这是ROS开发的铁律。

3.2 参数作用域的“三维空间”：global、private、namespaced的实战区别

ROS参数服务器的命名空间机制，是初学者最易混淆的概念。它不像编程语言的变量作用域那样线性，而是呈现“三维立体结构”：

• Z轴（深度）：Parameter Server层级
  /根命名空间（global） vs/my_robot（namespaced） vs~（private，即节点私有）

• X轴（横向）：参数可见性
  rosparam list显示所有global参数；rosparam list -p /my_robot显示namespaced参数；rosparam list -p ~在节点内才有效（需rosrun时加__name:=xxx）

• Y轴（时间）：参数加载时机
  rosparam set实时生效；roslaunch加载的YAML在节点启动前注入；dynamic_reconfigure在运行时修改

一个典型故障场景：某学员写了一个motor_controller.yaml：

# motor_controller.yaml wheel_radius: 0.075 max_rpm: 120

在controller.launch中这样加载：

<launch> <node name="motor_node" pkg="motor_pkg" type="motor_node"> <param file="$(find my_robot_config)/config/motor_controller.yaml" /> </node> </launch>

结果motor_node内ros::param::get("~wheel_radius", radius)始终返回false。原因在于：<param file=...>默认将参数加载到global命名空间（/wheel_radius），而节点内~前缀访问的是/motor_node/wheel_radius。正确做法是：

<!-- 方案1：显式指定private命名空间 --> <param file="$(find my_robot_config)/config/motor_controller.yaml" ns="~" /> <!-- 方案2：在YAML内定义命名空间 --> robot: motor: wheel_radius: 0.075 max_rpm: 120 <!-- 然后在节点内 get("/robot/motor/wheel_radius") -->

我在某物流机器人项目中，曾用一张表格帮团队统一理解参数作用域：

记住一个口诀：“全局参数用斜杠开头，私有参数用波浪号开头，命名空间参数用斜杠+名字开头”。每次写YAML前，先问自己：“这个参数，是给整个系统用的？还是只给这个节点用的？还是给某个机器人子系统用的？”答案决定了它的路径写法。

3.3 Launch文件与YAML的“共生关系”：如何让配置真正活起来

很多人以为YAML是静态文件，其实它和roslaunch是深度绑定的“共生体”。一个健壮的Launch-YAML组合，必须解决三个动态问题：

问题1：参数覆盖优先级
ROS中参数加载存在明确优先级：命令行参数 > Launch文件内<param>> YAML文件 > 代码内setParam。这意味着，你可以用YAML提供默认值，用Launch文件做环境适配，用命令行做临时调试。例如navigation.launch：

<launch> <!-- 默认加载dev环境YAML --> <param file="$(find nav_config)/config/dev.yaml" ns="/move_base" /> <!-- 但允许用户用命令行覆盖 --> <arg name="local_costmap_inflation" default="0.3" /> <param name="/move_base/local_costmap/inflation_radius" value="$(arg local_costmap_inflation)" /> </launch>

启动时执行roslaunch navigation.launch local_costmap_inflation:=0.5，即可动态覆盖YAML中的值，无需修改文件。

问题2：条件化加载
大型系统常需根据硬件配置加载不同YAML。ROS 1.15+支持if和unless属性：

<launch> <arg name="use_sim_time" default="false" /> <param if="$(arg use_sim_time)" name="/use_sim_time" value="true" /> <param if="$(arg use_sim_time)" file="$(find sim_config)/config/sim_params.yaml" /> <param unless="$(arg use_sim_time)" file="$(find real_config)/config/real_params.yaml" /> </launch>

问题3：参数传递链路
YAML中的参数如何传递给C++节点？关键在NodeHandle的构造。错误写法：

// 错误：创建全局NodeHandle，只能访问/global参数 ros::NodeHandle nh; nh.getParam("/robot/wheel_diameter", diameter);

正确写法（两种）：

// 方案1：使用私有NodeHandle（推荐） ros::NodeHandle nh("~"); // ~表示private namespace nh.getParam("wheel_diameter", diameter); // 自动查找~/wheel_diameter // 方案2：显式指定完整路径 ros::NodeHandle nh_global; nh_global.getParam("/robot/wheel_diameter", diameter);

我在某无人机集群项目中，曾设计一套“三级参数覆盖”机制：基础参数（base.yaml）→ 平台参数（quadcopter.yaml）→ 任务参数（search.yaml），通过Launch文件的<include>嵌套加载，实现了“一套代码，百种配置”。这种灵活性，正是YAML与Launch深度结合的价值所在。

4. 实操过程与核心环节实现：从零构建一个可验证的demo_yaml

4.1 环境准备与最小验证集搭建

我们不从复杂仿真开始，而是构建一个脱离ROS Master也能验证的纯参数Demo。所需环境极简：

• Ubuntu 20.04 + ROS Noetic（或Ubuntu 22.04 + ROS Humble，本文以Noetic为例）
• 无需Gazebo、RViz等重量级工具
• 仅需roscore和基础命令行工具

步骤1：创建工作空间与包

mkdir -p ~/catkin_ws/src cd ~/catkin_ws/src catkin_create_pkg demo_yaml rospy std_msgs cd ~/catkin_ws catkin_make source devel/setup.bash

步骤2：编写核心YAML文件
在~/catkin_ws/src/demo_yaml/config/目录下创建demo_basic.yaml：

# config/demo_basic.yaml # 基础参数演示：全局、私有、嵌套结构 robot_info: model: "demo_bot_v1" manufacturer: "ros_demo_team" # 私有参数（供节点使用） motor: wheel_diameter: 0.15 # 单位：米 max_velocity: 0.5 # 单位：m/s pid: kp: 1.2 ki: 0.05 kd: 0.01 # 全局参数（系统级） system: log_level: "INFO" enable_monitoring: true

注意：必须手动创建config/目录，ROS不会自动创建。若忘记，roslaunch加载时会报file not found，而非语法错误，极易误导。

步骤3：创建验证用Launch文件
在~/catkin_ws/src/demo_yaml/launch/下创建verify_params.launch：

<launch> <!-- 加载YAML到global命名空间 --> <param file="$(find demo_yaml)/config/demo_basic.yaml" /> <!-- 启动一个空节点，仅用于验证参数是否加载成功 --> <node name="param_verifier" pkg="demo_yaml" type="param_verifier.py" output="screen" /> <!-- 提供交互式验证入口 --> <node name="param_shell" pkg="demo_yaml" type="param_shell.py" output="screen" /> </launch>

步骤4：编写验证脚本
在~/catkin_ws/src/demo_yaml/scripts/下创建param_verifier.py：

#!/usr/bin/env python import rospy from std_msgs.msg import String def verify_params(): rospy.init_node('param_verifier', anonymous=True) # 验证全局参数 try: model = rospy.get_param('/robot_info/model') rospy.loginfo(f"[VERIFIED] Global param '/robot_info/model' = {model}") except KeyError: rospy.logerr("[FAILED] Global param '/robot_info/model' not found!") # 验证私有参数（模拟节点私有空间） try: vel = rospy.get_param('~motor/max_velocity', 0.0) rospy.loginfo(f"[VERIFIED] Private param '~motor/max_velocity' = {vel}") except Exception as e: rospy.logerr(f"[FAILED] Private param access error: {e}") # 验证嵌套参数 try: kp = rospy.get_param('/motor/pid/kp') rospy.loginfo(f"[VERIFIED] Nested param '/motor/pid/kp' = {kp}") except KeyError: rospy.logerr("[FAILED] Nested param '/motor/pid/kp' not found!") if __name__ == '__main__': verify_params()

赋予执行权限：

chmod +x ~/catkin_ws/src/demo_yaml/scripts/param_verifier.py

验证流程：

1. 启动roscore
2. 执行roslaunch demo_yaml verify_params.launch
3. 观察终端输出，应看到三条[VERIFIED]日志
4. 手动执行rosparam list | grep robot_info，确认参数已注入

这个最小验证集的价值在于：它剥离了所有外部依赖，把YAML加载、参数读取、作用域验证这三个核心环节，压缩到10行代码和一个YAML文件中。任何环节失败，都能精准定位是YAML语法、Launch配置还是节点读取逻辑的问题。

4.2 进阶Demo：Namespaces与Remap的协同调试

当系统扩展到多个同类型节点（如双摄像头、多传感器融合），命名空间（namespace）和话题重映射（remap）成为刚需。我们构建demo_namespaces.yaml：

# config/demo_namespaces.yaml # 模拟双摄像头系统：left_cam 和 right_cam left_cam: image_topic: "/left/image_raw" camera_info_topic: "/left/camera_info" exposure_time: 10000 # 微秒 gain: 1.5 right_cam: image_topic: "/right/image_raw" camera_info_topic: "/right/camera_info" exposure_time: 10000 gain: 1.5 # 公共参数 stereo: baseline: 0.12 # 米 rectify: true

配套stereo_launch.launch：

<launch> <!-- 分别为左右摄像头设置命名空间 --> <group ns="left_cam"> <param file="$(find demo_yaml)/config/demo_namespaces.yaml" /> </group> <group ns="right_cam"> <param file="$(find demo_yaml)/config/demo_namespaces.yaml" /> </group> <!-- 启动两个仿真摄像头节点（使用rosbag模拟） --> <node name="left_sim" pkg="rosbag" type="play" args="--clock $(find demo_yaml)/bags/left.bag" /> <node name="right_sim" pkg="rosbag" type="play" args="--clock $(find demo_yaml)/bags/right.bag" /> <!-- 关键：重映射话题到stereo_manager期望的路径 --> <node name="stereo_manager" pkg="stereo_image_proc" type="stereo_image_proc"> <remap from="/left/image_raw" to="/left_cam/image_raw" /> <remap from="/right/image_raw" to="/right_cam/image_raw" /> </node> </launch>

调试技巧：

• 使用rosnode info /stereo_manager查看其订阅的话题是否已正确重映射
• 执行rosparam list | grep left_cam，确认参数在/left_cam命名空间下
• 若stereo_manager报错“no image received”，先检查rostopic list中是否有/left_cam/image_raw，再检查rosparam get /left_cam/image_topic是否匹配

我在某农业机器人项目中，曾用此模式管理6路高清摄像头（3D激光+双目+热成像+IMU+GPS+4G状态），所有参数通过一套YAML模板生成，仅靠修改ns属性和remap规则，就完成了从单机调试到田间部署的无缝切换。

4.3 生产级Demo：参数版本化与CI/CD集成

真正的工程化，要求YAML配置可追溯、可审计、可自动化。我们构建demo_ci_cd.yaml，并集成到GitLab CI流程中：

# config/demo_ci_cd.yaml # 生产环境参数，含版本信息 version: "1.2.0-prod" build_timestamp: "2023-10-15T08:30:00Z" git_commit: "a1b2c3d4e5f67890" # 安全相关参数（敏感值不直接写入，用占位符） security: auth_token: "${AUTH_TOKEN}" # CI时由secret注入 tls_enabled: true # 性能参数 performance: cpu_affinity: "0-3" # 绑定CPU核心 memory_limit_mb: 2048 log_rotation_size_mb: 100

CI配置（.gitlab-ci.yml）关键片段：

stages: - validate - deploy validate_yaml: stage: validate image: ros:noetic-ros-base script: - apt-get update && apt-get install -y python3-yaml - python3 -c "import yaml; yaml.safe_load(open('config/demo_ci_cd.yaml'))" - roslaunch demo_yaml validate_params.launch # 运行自定义验证节点 artifacts: - config/demo_ci_cd.yaml deploy_to_robot: stage: deploy image: ubuntu:20.04 before_script: - apt-get update && apt-get install -y openssh-client script: - echo "$AUTH_TOKEN" > auth_token.txt - sed -i "s/\${AUTH_TOKEN}/$(cat auth_token.txt)/g" config/demo_ci_cd.yaml - scp config/demo_ci_cd.yaml user@robot_ip:/opt/ros/noetic/share/demo_yaml/config/

关键经验：

• YAML验证必须作为CI第一关：python3 -c "import yaml; yaml.safe_load(...)"能捕获90%的语法错误，比等到roslaunch失败再排查快10倍。
• 敏感参数绝不硬编码：使用${VAR}占位符，由CI Pipeline注入，避免密钥泄露。
• 版本信息写入YAML本身：version和git_commit字段，让任意一台机器上的配置文件，都能通过rosparam get /version反查其来源分支和提交，极大提升故障定位效率。

某工业质检机器人客户曾因参数版本混乱，导致产线停机2小时。后来我们强制所有YAML必须含version字段，并在节点启动时打印rosparam get /version，从此再未发生版本误用事故。

5. 常见问题与排查技巧实录：那些年踩过的YAML深坑

5.1 “参数加载了，但节点读不到”——作用域迷宫终极指南

这是ROS开发者提问率最高的问题。我整理了一份“五步定位法”，覆盖95%的场景：

真实案例：某学员的pid_kp始终读不到，按上述步骤排查到第4步，发现Launch文件中<param>写在了<node>标签之后。ROS的执行顺序是“从上到下”，参数必须在节点启动前加载。修正后问题解决。记住：Launch文件是顺序执行的脚本，不是声明式配置。

5.2 “YAML语法没错，但roslaunch报错”——那些隐藏的解析器陷阱

ROS的YAML解析器（基于PyYAML）有若干非标准行为，以下是高频陷阱：

• null值的歧义：YAML标准中null可写作~、null、Null、NULL，但ROS只认小写null。写Null: true会被解析为字符串"Null"，而非布尔值。
• 时间戳格式：timestamp: 2023-10-15T08:30:00Z在YAML中是合法时间类型，但ROS会将其转为字符串，而非ros::Time对象。必须用字符串格式"2023-10-15T08:30:00Z"。
• 十六进制整数：addr: 0xFF会被解析为十进制255，但某些驱动要求原始十六进制字节。安全写法：addr: "0xFF"（字符串）或addr: 255（显式十进制）。

快速检测法：在终端执行rosparam dump /tmp/params.yaml，它会将当前参数服务器所有参数导出为YAML。对比你的原始YAML和导出的YAML，差异处就是解析器的“翻译结果”，一眼看出类型是否被篡改。

5.3 “参数改了，但效果没变”——缓存与动态重载的真相

ROS参数服务器本身无缓存，但节点常做两件事导致“改了没用”：

• 节点启动时一次性读取：大多数节点在onInit()中读取参数，之后不再监听变化。解决方案：使用dynamic_reconfigure或ros::param::param()的默认值机制（ros::param::param("~kp", kp_, 1.0)，第三个参数是默认值，若参数不存在则用此值）。
• 参数服务器未刷新：roslaunch加载YAML后，若手动rosparam set修改，部分节点因未注册回调而不感知。解决方案：在节点中添加参数回调：

  void paramCallback(const std::string& param_name) { double new_kp; if (ros::param::get("~kp", new_kp)) { ROS_INFO("KP updated to %f", new_kp); // 更新内部PID控制器 } } // 注册回调（需ROS 1.15+） ros::param::setParamChangeCallback(paramCallback);

我在某手术机器人项目中，曾为所有关键参数（力控阈值、运动速度）实现动态重载，医生在术中可通过触摸屏实时调节，无需重启系统。这背后，就是对参数变更机制的深度理解。

5.4 YAML与ROS 2的平滑过渡：一份配置，两套系统

ROS 2（Humble/Foxy）虽引入rclpy和rclcpp新API，但YAML配置理念完全继承。只需三处修改，即可让ROS 1的YAML在ROS 2中运行：

1. Launch文件语法：ROS 2使用Python Launch文件，YAML加载方式为：

   from launch import LaunchDescription from launch_ros.actions import Node from launch_ros.parameter_descriptions import ParameterValue def generate_launch_description(): return LaunchDescription([ Node( package='demo_yaml', executable='param_verifier', parameters=[{'/robot/motor/kp': 1.2}] # 直接传字典 # 或加载YAML文件 # parameters=[os.path.join(get_package_share_directory('demo_yaml'), 'config', 'demo_basic.yaml')] ) ])

2. 参数获取方式：ROS 2中rclpy的get_parameter()返回Parameter对象，需调用.value：

   # ROS 2 Python kp_param = node.get_parameter('motor.kp') kp_value = kp_param.value # 不是kp_param.get_parameter_value()

3. 命名空间处理：ROS 2中Node构造时指定namespace参数，YAML路径自动前缀：

   Node( namespace='left_cam', parameters=[os.path.join(pkg_dir, 'config', 'cam.yaml')] ) # YAML中的`exposure_time`将被加载为`/left_cam/exposure_time`

迁移口诀：“YAML内容零修改，Launch语法换形式，节点读取加.value”。我主导的一个ROS 1导航系统升级项目，200+个YAML文件，仅用半天就完成了ROS 2适配，核心就在于抓住了YAML作为“配置契约”的稳定性。

6. 工程实践心得：YAML之外，你真正需要掌握的三种能力

写完几十个demo_yaml，我越来越清晰：YAML本身只是载体，真正决定ROS项目成败的，是三种隐性能力。

6.1 能力一：参数接口设计能力——从“能用”到“好用”的分水岭

很多团队把YAML当记事本，参数名随意（speed,max_spd,velocity_limit混用），类型混乱（timeout: 5vstimeout_ms: 5000）。这导致新成员看不懂，跨团队协作困难。我推行的“参数接口设计规范”包括：

• 命名统一：全部小写+下划线，单位明确（wheel_diameter_m,publish_rate_hz,timeout_ms）
• 分组逻辑：按功能域分组，而非按节点名（/sensors/lidar/range_min优于/lidar_node/range_min）
• 必选/可选标注：在YAML注释中明确# REQUIRED: ...或# OPTIONAL (default: 0.1)，避免“不填就崩”
• 范围约束：在注释中注明合理区间（# [0.0, 1.0]），配合dynamic_reconfigure做运行时校验

某自动驾驶公司曾因brake_pressure_max_bar参数单位从bar误写为psi，导致实车测试时制动失效。后来他们强制所有参数必须带单位后缀，并在CI中加入正则校验，杜绝此类低级错误。

6.2 能力二：配置即代码（Configuration as Code）的工程素养

YAML不是文档，是代码。它需要版本控制、Code Review、单元测试。我们团队的实践：

• YAML文件必须通过yamllint检查（配置规则：缩进2空格、禁止tab、行末无空格、注释前空1格）
• 每个YAML文件需配test_*.py验证脚本，检查关键参数是否存在、类型是否正确、范围是否合规
• 重大参数变更必须附带影响分析：修改/motor/max_velocity，需说明对/tf发布频率、电池消耗、急停距离的影响

一次Code Review中，我发现一个camera_exposure_auto参数从true改为false，但未同步修改exposure_time_manual的默认值，导致相机黑