基于DDPG深度强化学习的自适应巡航控制设计与训练实践

1. 项目思路与问题定义

先说结论：用深度强化学习里的DDPG算法去控制车辆的纵向运动，实现自适应巡航，这件事之所以值得做，是因为它把“跟车距离控制”从一个经典的标定问题，变成了一个“端到端学习”问题。搞过ACC开发的工程师都知道，传统ACC的控制逻辑说白了就是一个分层架构：上层根据前车距离和相对速度算期望加速度，下层再用PID或者MPC去跟踪这个加速度。这个架构本身很成熟，但痛点也很明显，就是标定工作量巨大，尤其面对复杂路况时，那些跟车距离阈值、舒适性参数、加减速权重，全靠工程师一点点试出来。

用DDPG来解决ACC问题，本质上是想绕过大量人工规则，让算法自己从环境反馈中学习出“什么时候加速、什么时候制动、什么时候保持匀速”的策略。这个思路不是说标定工程师没用，而是说DDPG能给出一条不同的路径：通过奖励函数的设计，把“安全、舒适、跟车效率”这些需求量化成数值，让控制器自己去权衡。最终要交付的东西，就是一个输入是传感器信息（相对距离、相对速度、自车速度等），输出是油门/制动指令的神经网络控制器。

适合看这篇文章的人，我觉得有两类。一类是刚接触强化学习、想在车辆控制领域落地的学生或研究人员，另一类是做传统控制但想了解强化学习方案效果与代价的工程师。如果你已经有PID或MPC做ACC的基础，会发现DDPG在问题建模上很多地方是相通的，但在训练和调试上完全是另一套玩法。

2. 为什么选择DDPG而不是其他方案

选算法这件事，不能因为“DDPG听着高级”就拍脑袋定，得看问题本身的约束。ACC的纵向控制有一个非常鲜明的特点：动作空间是连续的。你需要输出的不是“加速/制动/巡航”这样的离散挡位，而是一个连续的控制量，小到0.1的油门开度变化都会影响乘坐体验。这样一来，像DQN这类只能输出离散动作的算法，从根上就不太适合。

连续动作空间的控制任务，主流方案大致有三类：DDPG、PPO、TD3。最开始我确实纠结过要不要直接上TD3，毕竟它是DDPG的“改良版”，理论上能缓解DDPG的过估计问题，训练稳定性也更好。但考虑到这个项目的定位是做一个ACC控制器设计的完整流程验证，不是刷一个最强的SOTA指标，DDPG在结构上更简单，核心代码量更少，而且DDPG作为Actor-Critic架构的经典代表，折腾一遍之后对策略梯度、Q函数、目标网络这些概念的理解会更扎实。另一个实际问题是DDPG对算力和环境的适配经验更丰富，网上踩坑资料也多，对刚上手的人更友好。

而且从控制角度看，DDPG的框架本身也很有吸引力：Actor网络学的是一个确定性策略，输入车辆状态观测，直接输出确定性动作，这在部署上比随机策略方便得多，也不需要在推理时额外做采样。另外DDPG有独立的Critic网络，用Q值来评判“当前状态下这个控制动作有多好”，这就相当于你同时训练了一个评价器，后续想换SAC或者做多目标扩展时也能平滑过渡。

当然，DDPG的短板也得很直白地说：它对超参数敏感，训练不稳定，容易收敛到很差的局部策略或者干脆发散。这是我在这篇文章里会花大篇幅讲的部分，因为算法选型只是第一步，真正的时间和精力全耗在让它稳定收敛上。

3. 状态空间、动作空间与奖励函数设计

这是整个设计里最关键的一环。很多人在做RL控制项目时，模型结构抄个现成的，环境拿来就跑，但状态到底该放什么、奖励怎么组合才是合理的，反而没想清楚。ACC场景里，我最终采用的状态空间是三维的，不要贪多。

3.1 状态空间构建的原则

状态量我选了相对距离、相对速度、自车速度。为什么只选这三个，不把前车加速度也放进去？原因有两方面：一是传感器层面，前车加速度在真实量产方案里很难直接拿到，一般还是通过相对速度微分估计，噪声大，不如不给；二是从训练角度讲，状态量太多会让探索空间急剧膨胀，收敛难度成倍增长。真实工程里能用最少的状态量解决任务，就绝不多加。

相对距离需要做归一化处理。一个常见的做法是用自车速度乘以一个期望时距（比如1.5秒或2.2秒），得到一个动态的期望跟车距离，然后把实际的相对距离减去期望跟车距离，再除以一个固定常数映射到[-1, 1]附近。这样做的好处是，控制器学到的不是“绝对距离保持多少米”，而是“相对当前车速，我该留多少余量”，这更符合人类驾驶习惯。

相对速度则反映前车是在靠近还是远离，归一化可以按最大相对速度处理，比如±15 m/s映射到[-1, 1]。自车速度的归一化就更简单了，直接除以道路限速或车辆最大速度。如果追求更精细的控制效果，后轮加速度和横向稳定性指标也可以加进状态里，但作为第一版DDPG控制器，三个维度完全够用，而且效果已经能跑出来，后续再逐步扩展即可。

3.2 动作空间定义与车辆接口

动作这个维度我踩过两个坑，很有必要展开讲讲。

一开始我把动作直接定义为期望加速度，范围比如[-4 m/s², 3 m/s²]，想着这样最直观。训练结果确实也能收敛，但问题在于期望加速度和车辆真实响应之间隔着一个执行器环节。真实车辆的油门和制动执行器响应有延迟、有饱和特性，你给一个3 m/s²的期望加速度，车辆实际可能只能输出2.3，而且动态延迟能达到200毫秒以上。算法在仿真里学了“给3的期望加速度”，到实车上发现给相同指令得不到相同响应，整个策略就没法迁移。

所以我最终把DDPG网络的输出定义为期望加速度的一个“修正增量”，也就是说RL策略输出的是一个层叠控制里的上层目标，下层由一个简单的执行器模型负责映射到油门开度和制动压力。这里要用上车辆动力学仿真环境，它内部有完整的逆纵向动力学模型，能精准计算驱动扭矩和制动压力。从算法角度，动作空间变成了一个相对平滑的连续区间，有效避免了策略输出剧烈抖动的问题。

另外要注意，动作空间一定要做范围裁剪，不能指望RL自己学会不超限。我设定的动作输出范围加上裁剪逻辑后，训练初期的安全性明显好了很多。动作上下限的选取依据不像状态那样有理论公式可循，更多是靠经验和对ACC场景的理解，比如最大制动加速度在舒适模式下取-3.5左右，急刹场景靠上层逻辑兜底，这也是工程上的常态做法。

3.3 奖励函数：安全优先、效率适度、舒适兜底

奖励函数是整个DDPG设计里最需要“调味道”的地方。我用的是加权组合式奖励，大致分三块。

第一块是安全项。相对距离小于设定的最小安全距离时，给予一个比较大的负奖励，奖励值可以设为-1甚至更大，具体要看奖励尺度。这里的关键点是不能像倒立摆那样给“到达目标给正奖励”，而是要使用“威胁程度连续惩罚”的思路，也就是让惩罚随距离缩短而平滑变大，这样可以避免策略在边界附近产生跳变式的恐惧行为。

第二块是跟车效率项。控制器的目的是跟住前车、保持期望时距，所以要把相对距离误差作为一项连续的惩罚。我采用的形式是归一化距离误差的平方，乘上一个较小的权重。用平方而不是绝对值，是为了让小偏差几乎无惩罚、大偏差受到明显惩罚，这样策略会更倾向于保持稳定跟随，而不是来回纠结。

第三块是舒适性项。把动作的幅度变化和控制器输出的播种量纳入惩罚。也就是不能让策略频繁加减速、不能输出高频抖动。这一项在仿真里可能觉得无所谓，但在实车上乘坐体验会非常典型，训练时忽略它，后面部署就是灾难。

整体奖励函数的形式如下：

reward = -w1 * (min_safety_penalty) - w2 * (distance_error**2) - w3 * (action_change**2) + w4 * (speed_progress)

补充说明一下speed_progress，它是在前方没车或者车速保持合理时给一点小奖励，鼓励车辆尽快达到设定巡航速度。权重我会在下面调参部分说具体怎么调。

4. 仿真环境与车辆动力学建模

没有环境就没法训练强化学习。这个项目的环境是分层设计的，训练效率和控制可信度兼顾。从下往上依次是：车辆纵向动力学模块、仿真场景逻辑模块、RL交互接口模块。

4.1 车辆纵向动力学模型

车辆纵向动力学建模，本质上就是把外力算清楚：驱动力、制动力、滚动阻力、空气阻力、坡度阻力。公式不复杂，但每一项的量级和实现方式决定了控制器的“手感”。我用简单的一阶惯性环节来描述动力总成响应特性，而不是直接让加速度瞬间到达目标值。如下图代码（省略具体公式）：

# 简化纵向动力学方程 accel = (drive_force - brake_force - rolling_resist - aero_drag - grade_force) / vehicle_mass

实际仿真里我会用Carsim或者Prescan这类商业软件做动力学响应，但在强化学习的快速迭代阶段，更建议用一个简化的自建模型，因为训练要跑几十万步采样，每一次都让Carsim算动力学会严重拖慢训练速度。工程上一个比较普遍的做法是：先自建简化的纵向动力学模型用来探索算法和调通训练流程，选一个典型场景跑稳之后，再接入高精度动力学做二次验证。

4.2 场景定义：接近、跟随、切出与巡航

训练场景决定了策略的泛化能力。我设计了四种典型工况：

• 前车匀速行驶，自车从后方逐渐靠近，要求最终稳定跟随
• 前车周期性地加速和减速，自车要调整车速以保持期望时距
• 前车突然切入本车道，距离骤减，自车需要紧急制动
• 前方无车，自车以设定巡航速度行驶

每个场景都会在仿真环境里初始化不同的相对距离和相对速度，确保训练的样本分布覆盖充分。另外，前车的速度变化曲线在每轮训练里都要随机生成，可避免算法记住固定模式。

4.3 Gym接口封装

标准的RL训练需要环境满足“输入动作、输出反馈”的循环接口。我按Gym环境风格封装了整个交互：

# 环境交互接口关键逻辑 obs = env.reset() while not done: action = agent.select_action(obs) obs_next, reward, done, info = env.step(action) agent.store_transition(obs, action, reward, obs_next, done) obs = obs_next

这里有两个细节。第一个是“截断”与“终止”的区分，如果因为时间步数耗完而要结束仿真，要和因为碰撞或距离过近而结束严格区分开，这会影响终止状态的Q值计算，处理不好会让价值网络混乱；第二是训练的随机种子要保留好，同一个场景种子可以在调参后稳定复现问题，这对debug非常有帮助。

5. DDPG网络结构与核心代码实现

网络结构遵循Actor-Critic架构，整体框架不复杂。Actor和Critic各自包含目标网络，目标网络参数的更新方式采用软更新。

我采用的Actor网络设计是三层全连接：输入层节点数等于状态维度，两个隐藏层分别为256和256，输出层是一个节点，通向动作空间。注意到输入层后面接一个批归一化会让训练稳定性提升一个档次，因为ACC的状态量虽然做过归一化，但实际分布仍然会随车速变化发生偏移。在输出层使用Tanh激活函数，把原始输出映射到[-1, 1]，再根据动作范围映射到实际物理量区间。

Critic网络稍微复杂一点，因为它要把“状态-动作”作为联合输入。我用的也是两层全连接，不过在第一个隐藏层之后把动作向量拼接进特征向量，而不是在输入层直接拼接，这个细节从实践中验证会更稳定。Q网络的输出就是单个Q值，代表对于给定状态和动作的回报期望。

整个训练框架代码如下（节选）：

# DDPG训练主循环 if len(replay_buffer) > batch_size: batch = replay_buffer.sample(batch_size) state, action, reward, next_state, done = batch # 计算目标Q值 target_q = reward + gamma * (1 - done) * critic_target(next_state, actor_target(next_state)) # 更新Critic critic_loss = F.mse_loss(critic(state, action), target_q.detach()) # 更新Actor actor_loss = -critic(state, actor(state)).mean() # 软更新 tau = 0.001

代码本身网上多的是，真正花时间的是一些“隐形设置”。接下来要讲的是我觉得更重要的板块：训练过程中遇到的那些坑和调参经验。讲真，这个项目让我最头疼的不是算法理论，而是“怎么让它稳住、收敛、不崩”。

6. 训练中的关键调参经验与稳定性优化

把DDPG训练稳定是一件极考验耐心的事。好多次眼看Q值曲线开始上涨，结果几百个episode之后突然断崖式下跌，然后彻底坏掉。经过反复折腾，我梳理出了一套比较有效的调参顺序和经验。

6.1 先调惩罚比重，再调网络与学习率

做ACC奖励函数里几个权重的初始量级，我的参考值大概是：安全距离惩罚权重2.0，距离误差权重0.3，动作平滑权重0.1，速度目标奖励权重0.5。但直接拿这一组去调试很难收敛，所以我的习惯是先把安全权重拉大，其他权重全部缩到很小，让算法能稳定避开碰撞，建立起一个“谨慎驾驶”的初始策略。等训练稳定不撞了，再把跟车效率权重慢慢抬上去，最后再来调舒适性权重。

这样分层调的原因在于，安全和不碰撞是强约束，如果一开始就追求“又不撞、又跟得紧、又舒适”，那算法会面对极其复杂的多目标优化，训练初期非常容易陷入无法长出任何有效策略的困境。反而先让它学会“不撞”，再在这个安全策略基础上去优化性能指标，效率高很多。

6.2 探索噪声与动作抖动

DDPG训练期通常依赖在动作上叠加随机噪声来鼓励探索。一般用OU噪声，并且噪声的幅值需要随训练逐步衰减。这个过程中有个典型的问题：训练中后期，噪声强度没降下来，算法明明已经有不错的策略表现了，但Q值还是不稳定。我是按照训练总步数的比例线性衰减噪声幅值，从初始0.3左右降到最终0.05，这个节奏比较合适。

然后就是动作抖动问题。很多DDPG训练出来之后控制动作一抖一抖的，这表面上是动作平滑权重不够，但深层原因是Critic网络在Q函数拟合上不够平滑，导致Actor在相邻状态搜索时找到的最优动作差异很大。缓解办法一个是增加Critic网络容量和正则化，另一个是我发现把奖励里的动作变化惩罚从动作差值改成动作变化率差值效果更好，就是不仅惩罚这次动作与上次的差，还要惩罚变化速度的差。

6.3 经验回放池的批次与采样策略

标准的经验回放池是均匀采样，但这在ACC场景里有个问题：靠近跟车边界的危险样本占的比例很少，算法学不到足够的边界知识。我试验过后，改用了一种简单的优先采样策略：平衡因子让靠近安全的样本有更高的概率被抽到。

priority = abs(q_target - q_current) + epsilon

就是计算TD误差的绝对值，按误差大小排序采样。这样能把训练焦点集中在“策略还没搞明白”的状态上，收敛速度有明显改善。这个改动没有增加多少代码量，但对稳定性的提升是一个可感知的量级。

6.4 关于目标网络更新速率

DDPG里的tau值，也就是目标网络软更新的速率，我一开始用的tau=0.01，结果训练初期Q值波动极大。后来按照经验下调到0.001之后，整个训练过程明显平滑下来。原因在于目标网络更新太快，相当于目标也在随时移动，价值网络很难稳定追逐。ACC这类任务不是要极速响应变化的游戏环境，而是需要平稳的缓变目标，所以tau尽量小一点。

7. 训练结果与常见问题排查实录

总算是聊到结果和坑了。我把训练过程中的现象和一些排查思路整理成表格，每个问题都踩得肉疼，写出来供参考。

训练过程选取一段典型表现来看，前5000步Q值还是负一片，策略明显在乱试；到10000步之后，车辆开始能维持一定车距，但偶尔会在前车急减速场景里刹不住；到30000步时，基础的跟车场景已经能稳定完成，但切车场景还是会偶发碰撞；最终在80000步左右，几个场景全部通过，动作输出也比较平滑了。这个进度是肉眼可见的阶段式提升，而不是平滑曲线的感觉，如果你遇到类似阶梯式提升，说明策略正在学会不同场景的处理逻辑，这是正常现象。

有一个案例我必须单独讲讲。某次尝试里，前车切入场景的表现总是不稳定，每次训练结果差异极大。排查后发现，问题出在动作输出的执行器延迟参数上。不同场景下我设置了不同的延迟，导致网络学到的策略在不同环境里切换时产生混乱。解决办法是统一所有场景的执行器延迟参数，或者把延迟也作为状态变量输入到网络中，让策略学会“带着响应延迟做决策”。这个经验是我在这一项目里最深刻的一个体会，往往算法本身没问题，而是环境建模的自洽性出了问题。

8. 一种更稳妥的落地路径：从仿真到实车的过渡建议

强化学习项目的通病就是“仿真里很猛，实车上就废”。DDPG做ACC控制器同样逃不开这个坎。我从一开始就意识到最终目标不能直接拿仿真网络部署到实车，于是设计了一条过渡路径。

第一步是在仿真环境里加入高精度的车辆动力学模型和传感器噪声，反复验证策略在噪声下的表现；第二步是把DDPG输出的控制量送给一个下层已验证的ACC跟踪控制器，让RL主要负责决策上层目标加速度，而真正执行刹车和油门的任务交给传统控制器；第三步是设置安全监控层，一旦RL策略输出的加速度超出安全包络，就切换到传统控制策略兜底。

这条路径本质上不是让RL替代一切，而是让RL和传统控制做配合，把RL最擅长的“场景决策”优势和传统控制最擅长的“精确执行”优势结合起来。如果你后续要推动落地，我建议一定要保留这个“安全监控”逻辑，这在ACC这种安全件里不是可选项，而是必选项。

9. 写在最后：从项目里学到的几个朴素道理

回看这个项目，DDPG的核心数学其实不复杂，但真正考验人的是理解“在训练过程中，系统的性能为什么是这样的”。我个人的体会有三条。

第一条，状态和动作的规范化处理再怎么强调都不为过。RL对数值尺度极度敏感，任何未归一化的特征都会破坏优化，这点上多做一步，训练时长能少一半。第二条，奖励函数设计不是玄学，而是一个可以逐步Debug的系统工程，把每个需求拆成对应的奖励项，再分优先级调权值，整个过程完全可推理、可迭代。第三条，仿真环境的“自洽性”往往比复杂度更关键，而这个问题通常只在策略无法泛化的时候才会暴露出来，建议在做环境时就把延迟、噪声这些执行器特性和场景初始化统一规划好。

回头想，这个坑踩得值。DDPG调通的那一刻，看到自车在仿真里顺滑地跟着前车加减速，那种成就感确实是写PID时体会不到的。如果你也要折腾ACC的强化学习方案，记住别急着上大网络，也别迷信完美奖励函数，先把训练稳定性和安全冗余机制打扎实，后面会顺很多。

按我个人最后的建议，第一版不要指望DDPG直接端到端输出油门刹车，而是输出期望加速度交给下层执行。等模型稳定了、验证充分了，再考虑一步步放松耦合。这样既快又稳，也符合工程上“逐步解耦、逐层验证”的原则。