速度规划配置总览：一个典型配置文件的骨架

做速度规划这几年，我见过太多团队把配置写成「天书」。几百行的 YAML，没人敢改，改了也不知道会出什么问题。说白了，配置不是堆参数，而是把你的规划策略「翻译」成机器能读懂的规则。

今天我们就拆一个典型的速度规划配置文件。我会告诉你每个字段是干什么的，哪些是核心，哪些是坑。

顶层字段解析：配置文件的骨架

一个成熟的速度规划配置，通常包含 5 个顶层字段。我习惯把它们分成「策略层」和「参数层」两类。

顶层字段	类型	作用	我的建议
profile	策略层	定义规划模式（舒适/运动/经济）	至少保留 3 种预设
constraints	参数层	车辆物理极限（加速度、 jerk 等）	从实车标定数据反推
weights	参数层	优化目标权重（效率/舒适/能耗）	先归一化再调参
safety	策略层	安全冗余与异常处理	永远放在第一位
debug	工具层	日志、可视化、回放开关	开发阶段全开，量产阶段全关

模块化配置思想：为什么我坚持拆文件

早期我做项目时，所有配置塞在一个文件里。结果呢？每次改个加速度限值，都要翻几百行。后来我学乖了——按功能拆成独立模块。

一个典型的模块化配置结构长这样：

config/
├── profile/
│   ├── comfort.yaml      # 舒适模式
│   ├── sport.yaml        # 运动模式
│   └── eco.yaml          # 经济模式
├── constraints/
│   ├── vehicle.yaml      # 车辆物理参数
│   ├── road.yaml         # 道路条件参数
│   └── env.yaml          # 环境参数（雨雪等）
├── weights/
│   ├── default.yaml      # 默认权重
│   └── custom.yaml       # 用户自定义
├── safety/
│   ├── emergency.yaml    # 紧急制动策略
│   └── fallback.yaml     # 降级策略
└── debug/
    └── logging.yaml      # 日志配置

这样做的好处很明显：

• 职责单一：每个文件只管一件事，改起来不慌
• 复用性强：舒适模式可以继承默认约束，只覆盖权重
• 团队协作：算法工程师改 weights，标定工程师改 constraints，互不干扰

一个完整的配置示例

下面是一个简化但完整的配置文件。我拿舒适模式举例：

# comfort.yaml
profile:
  name: "comfort"
  description: "城市工况舒适模式"
  inherit: "base"          # 继承基础配置

constraints:
  max_accel: 2.0           # m/s²
  max_decel: -3.0          # m/s²
  max_jerk: 1.5            # m/s³
  max_speed: 60.0          # km/h

weights:
  efficiency: 0.3
  comfort: 0.5
  energy: 0.2

safety:
  emergency_decel: -5.0    # 紧急制动减速度
  min_time_gap: 1.5        # 最小跟车时距（秒）
  collision_check: true

debug:
  log_level: "info"
  save_trajectory: false

模块化配置的核心逻辑

我画了一张图，帮你理解模块之间怎么协作：

你看，配置加载器就像个「调度员」。它从各个模块文件里读取参数，按优先级合并，最后输出一份完整的规划器输入。这样做的好处是——改舒适模式，你只需要动 profile/comfort.yaml，其他文件完全不用碰。

配置继承与覆盖：少写重复代码

模块化之后，还有个问题：不同模式之间有很多重复参数。比如舒适模式和运动模式，车辆物理极限是一样的，只是权重不同。

我的解决方案是「继承 + 覆盖」：

# base.yaml（基础配置）
constraints:
  max_accel: 3.0
  max_decel: -4.0
  max_jerk: 2.0

# comfort.yaml（继承 base，只覆盖权重）
inherit: "base"
weights:
  comfort: 0.6
  efficiency: 0.2
  energy: 0.2

# sport.yaml（继承 base，覆盖约束和权重）
inherit: "base"
constraints:
  max_accel: 4.5    # 覆盖为更激进的加速
weights:
  comfort: 0.1
  efficiency: 0.6
  energy: 0.3

配置验证：上线前的最后一道关

配置写好了，怎么保证不出错？我每次上线前都会跑一遍验证脚本：

• 范围检查：加速度不能超过车辆物理极限
• 一致性检查：舒适模式的 jerk 不能比运动模式还大
• 完整性检查：所有必填字段都有值
• 冲突检测：安全层和策略层不能有矛盾（比如安全要求减速 5m/s²，但约束只允许 3m/s²）

说白了，配置就是代码。你写代码会做单元测试，配置也一样需要验证。别等到实车测试才发现问题——那时候改起来成本就高了。