简介本资源是一套基于SUMO平台的多策略自适应交通信号控制系统实现面向智能交通系统研究者、强化学习初学者及城市交通工程实践者聚焦于缓解交叉口拥堵、提升通行效率的核心问题。压缩包共54个文件含37个Python核心模块涵盖DQN/DDPG智能体训练、韦氏算法调度、最大压力策略实现及自组织控制逻辑、5个Shell脚本用于环境配置、模型训练与结果生成、4张性能对比图表如hp.png、travel_time.png以及SUMO网络配置文件.sumocfg/.net.xml和完整项目文档README.md、LICENSE等整体仅1.35MB轻量易部署。已有1321人学习下载提供从仿真环境搭建、算法复现到结果可视化的一站式代码支持尤其适合开展交通信号控制算法对比实验、课程设计或科研原型验证。 很多做交通仿真的朋友应该都有过这种体验跑SUMO自带的交通灯算例时默认的固定配时方案在车流量变化后排队长度肉眼可见地往上堆。光调绿灯时长就得反复试调完这组路口旁边路口又开始堵。后来我接触到自适应信号控制才意识到问题核心不在于你配时配得好不好而在于固定配时根本没有“感知”能力。这个项目就是把目前主流的几种自适应控制算法——DQN、DDPG、韦氏Webster、最大压力Max Pressure和自组织交通灯——全部在SUMO里实现并放在一起横向对比用Python写控制逻辑用Shell脚本一键完成仿真、训练和结果汇总。无论你是刚接触SUMO的交通专业学生还是想在企业项目里落地强化学习信号控制的研究人员这套框架都能让你少走很多弯路。整个项目解决了一个很具体的问题同样的路口、同样的车流量不同的信号控制策略到底差多少固定配时、经典配时公式、无模型强化学习、以及完全分布式的自组织策略这五条技术路线放在同一套仿真环境里公平对比从排队长度、平均等待时间、吞吐量三个维度给出量化结果。我把整个项目的设计思路、算法原理、代码结构、运行流程和排障经验整理成文希望能帮你快速把环境跑起来并且真正理解每种控制策略的适用场景。1. 项目整体设计与技术选型思路1.1 为什么选择SUMO作为统一仿真平台市面上的交通仿真工具很多VISSIM、TransModeler、MATSim各有优势但我个人始终觉得SUMO是跑强化学习信号控制最合适的平台没有之一。原因有三点第一SUMO完全开源免费没有License限制批量跑实验不用心疼授权费第二TraCI接口提供了非常细粒度的控制能力你不仅能读到每辆车的实时位置、速度、加速度还能直接修改交通灯的相位和持续时间这对强化学习训练来说是刚需第三SUMO原生支持在线交互模式仿真过程中Python脚本可以实时读取状态、执行动作、获取奖励天然适配RL的env-loop结构。这个项目里所有算法都跑在SUMO 1.8.0以上的版本。之所以选这个版本线是因为1.8之后TraCI的接口命名规范了很多比如traci.trafficlight.getControlledLinks、traci.vehicle.getAccumulatedWaitingTime这些API都趋于稳定网上资料也最多遇到问题基本都能搜到解法。另外SUMO提供了sumo-gui可视化界面调试阶段我会开着GUI观察车辆是否真的按照预期逻辑在路口排队和放行确认逻辑无误后再切到sumo命令行模式批量跑数据。1.2 五种算法的选型逻辑与应用场景这个项目最核心的设计决策就是把三种完全不同范式的控制策略放在同一套评估体系下横向比较。DQN和DDPG属于强化学习路线。DQN解决的是离散动作空间的问题通常把信号相位组合离散成几个固定动作比如直行绿灯、左转绿灯、全红清空等DDPG则面向连续控制场景虽然交通灯本身是离散的但DDPG可以输出连续的压力值或者绿灯延长时间再通过映射函数转换到实际相位。在工程落地中DQN更适合路口相位组合固定、动作空间有限的场景训练相对稳定DDPG适合需要精细调节绿灯延时时长的场景但对超参更敏感调起来更费劲。韦氏公式是经典的解析配时方法。它基于车辆到达率和饱和流率通过最小化平均延误计算最优周期时长和绿灯时间分配。这个算法在低饱和度的交叉口表现很好计算简单、工程上容易实现国内很多早期信号机项目用的就是韦氏配时或者它的改良版本。它的问题在于模型假设是稳态到达实际交通流是时变的一旦流量波动大配时就会逐渐失配。最大压力算法则是一种分布式控制策略它的核心思路是对每个相位计算“压力”——即当前相位对应的车道内车辆数与下游可用空间之间的差值然后优先放行压力最大的相位。这种算法有严格的理论保证在很多文献里被证明在过饱和路网下能够稳定网络流量而且不需要预测未来流量只需要当前时刻的状态部署成本极低。自组织交通灯走的是另一条路。它借鉴了物理系统中的自组织临界性思想绿灯时间不是预设的而是根据车流的实际到达情况自动延长或切换。具体实现时通常设定一个最小绿灯时间和一个最大绿灯时间只要检测到当前相位仍有连续车辆到达且未超最大绿灯时间就持续保持该相位绿灯。这个策略特别适合车流量间歇性很强的路口能大幅减少空放时间。1.3 项目目录结构与模块划分代码仓库的目录结构设计得比较清晰拿到压缩包解压后你第一眼能看到的是src、nets、results和run_all.sh这几个核心部分。nets目录存放SUMO路网文件我默认放了一个经典的四向十字路口和一个六路口的小型路网前者用来快速验证算法逻辑后者用来测试多路口协调场景。src目录下按算法划分了dqn_agent.py、ddpg_agent.py、webster_controller.py、max_pressure_controller.py、self_organizing_controller.py五个主控文件外加一个env_sumo.py负责封装SUMO的TraCI交互一个evaluate.py用于统一定义评估指标。所有控制器的接口是统一的都实现了choose_action(state)和update(state, action, reward, next_state)这两个方法。这样设计的好处是评估脚本完全不需要关心具体算法内部怎么实现只需要按固定顺序调用接口、收集数据、写日志。如果你以后想加入新的控制算法比如POMDP或者MPC只需新建一个文件并实现这两个方法其他代码完全不用改动。这个接口设计思路强烈建议保持因为它直接决定了后续实验迭代的效率。2. SUMO仿真环境搭建与项目配置文件解析2.1 环境安装与版本匹配建议使用Linux系统跑这个项目Windows当然也能跑但Shell脚本的兼容性和SUMO的进程管理在Linux下要省心很多。安装部分我用的是Ubuntu 20.04直接通过apt安装SUMOsudo apt update sudo apt install sumo sumo-tools sumo-doc安装完成后检查一下版本确保TraCI接口可用sumo --version输出里会出现SUMO Version 1.8.0这样的信息。如果版本低于1.8部分API可能不兼容建议升级。Python端需要安装traci库SUMO自带的Python工具包通常位于/usr/share/sumo/tools你需要把它加到PYTHONPATH环境变量中export SUMO_HOME/usr/share/sumo export PYTHONPATH$SUMO_HOME/tools:$PYTHONPATH如果你习惯用虚拟环境建议用python3 -m venv sumo_env创建独立环境再在activate脚本里写死这两行环境变量避免每次手动导出。我早期没有做这步换了个终端环境跑代码结果import traci直接报ModuleNotFoundError排查半天才发现是环境变量丢了。2.2 路网文件与流量配置的核心参数路网文件是整个仿真实验的地基。项目里默认的四向十字路口结构是每条方向有两个车道左转和直行共用一个车道组没有单独设置右转专用道符合国内大部分城市交叉口的典型特征。信号相位设置为四相位固定序南北直行、南北左转、东西直行、东西左转每个相位之间插入3秒黄灯。流量配置我写成了两种模式固定流量和随机流量。固定模式下四条道路各方向的车辆到达率是常量比如每小时600辆随机模式下我用SUMO的flow模块生成泊松分布的随机到达序列。这里有个重要参数需要重点关注就是vehsPerHour的取值。单向车流量低于300pcu/h时固定配时和自适应算法的差距并不大因为路口根本不会拥堵但车流量超过600pcu/h后固定配时的排队长度会快速上升这时自适应算法的优势会被放大。建议调试阶段先跑低流量验证逻辑正式对比实验再用高流量。nets目录下的.net.xml文件里信号灯组的定义是关键。SUMO用tlLogic标签定义信号控制器里面每个phase标签代表一个相位。你需要确保代码里读取的相位ID与路网文件中的id完全一致否则TraCI调用时你会拿到一堆空返回值。最常见的错误是大小写不匹配路网文件中定义的是tl_0代码里写成了TL_0导致traci.trafficlight.setPhase没有生效。2.3 Shell脚本一键化运行设计run_all.sh是整个项目的总入口它的设计目标是让任何人拿到代码后输入一行命令就能完成全部五组实验。脚本逻辑分为四个阶段检查环境、启动仿真、训练/控制算法、汇总结果。核心部分用bash实现配合wait命令并行处理多个独立实验大幅缩短总运行时间。#!/bin/bash # 阶段1: 检查环境 which sumo /dev/null 21 if [ $? -ne 0 ]; then echo sumo not found in PATH exit 1 fi # 阶段2: 依次运行各算法 for algo in webster max_pressure self_organizing dqn ddpg; do python3 src/main.py --algo $algo --config nets/cross_4way.sumocfg logs/${algo}.log 21 done wait这段脚本的关键点是wait命令它让五个算法并行跑实测中比串行节省了大约60%的时间。不过要注意并行跑需要确保每个SUMO实例使用不同的端口默认的TraCI端口是8813同一时刻只能有一个实例占用。我在main.py里通过--port参数控制不同实验使用不同端口对应关系在Shell脚本里用数组维护declare -a ports(8813 8814 8815 8816 8817)这个细节如果不处理并行执行时后启动的算法会直接报connection refused或者端口被占用的错误非常容易踩坑。3. 五种信号控制算法的原理与Python实现3.1 DQN: 基于值函数的离散相位决策DQN的建模思路比较直观把信号控制看作一个马尔可夫决策过程状态是当前路口的交通状态动作是选择一个信号相位奖励是控制效果的反馈。这个项目里状态向量的设计是当前各车道的排队长度单位辆、当前各车道的平均等待时间单位秒、当前相位编号、当前相位已持续时长。这四类信息拼接起来向量维度是4个方向×2条车道×2种信息2个相位信息18维足够表达一个单路口的短时交通态势。动作空间设计为四个离散相位即南北直行、南北左转、东西直行、东西左转每次决策时智能体选择一个相位并持续执行10秒然后再次做出决策。这样的设计把连续时间问题离散化强化学习智能体不需要每一秒都做决策大幅降低训练难度。如果每1秒就决策一次状态转移的随机性太强训练很难收敛10秒一个决策粒度既保留了响应实时性又让每个动作的奖励信号更稳定。DQN的网络结构用的是三层全连接网络隐藏层维度分别是256和128激活函数用ReLU。经验回放缓冲区大小设为10000每次训练从缓冲区随机采样128条经验。这里有两个关键超参需要重点调整学习率初始值设为0.001如果训练过程中奖励曲线震荡太剧烈就把学习率降到0.0005探索率epsilon采用线性衰减策略从1.0衰减到0.05衰减步数设为20000步确保前期充分探索、后期充分利用。核心代码逻辑如下class DQNAgent: def __init__(self, state_dim, action_dim): self.q_net self._build_q_network(state_dim, action_dim) self.target_net self._build_q_network(state_dim, action_dim) self.replay_buffer deque(maxlen10000) self.epsilon 1.0 self.batch_size 128 def choose_action(self, state): if np.random.rand() self.epsilon: return np.random.choice(self.action_dim) q_values self.q_net.predict(state.reshape(1, -1), verbose0) return np.argmax(q_values[0])这里有个细节容易被忽略目标网络不能每一步都从训练网络直接复制权重否则训练会不稳定。我采用软更新策略每次训练后让目标网络权重以0.01的比例向训练网络靠拢而不是硬拷贝。这个做法来自DQN的改进版本实测下来训练曲线平滑很多收敛速度也快了不少。3.2 DDPG: 连续绿灯延长时间策略DDPG在信号控制领域用得比DQN少但处理可变的绿灯时间这种柔性决策任务DDPG的连续输出特性是有优势的。这个项目里的DDPG不是直接选择离散相位而是输出一个绿灯延长时间值范围限制在5秒到30秒之间。原本的逻辑是当前相位先执行最小绿灯时间5秒然后DDPG根据当前交通状态决定是否延长绿灯、延长多少秒。状态空间和DQN基本一致区别在于动作空间从离散的四选一变成了连续的一维数值。Actor网络输出层的激活函数用tanh将输出映射到[-1, 1]再线性变换到[5, 30]区间。Critic网络输入是状态和动作的拼接向量输出一个Q值。DDPG训练中最常见的问题是Q值估计发散。我加了两个机制来解决第一是目标策略平滑正则化在目标Q值的计算中对动作加上正态分布噪声抑制过估计第二是Critic网络的学习率降到0.0002低于Actor的0.0001保持稳定。噪声在训练前期设为0.3每5000步衰减0.05最低到0.05。推理阶段关闭所有探索噪声直接用Actor网络输出原生动作。def choose_action(self, state): state np.expand_dims(state, axis0) action self.actor.predict(state)[0] if self.training: noise np.random.normal(0, self.noise_std) action np.clip(action noise, -1, 1) green_extension (action 1) / 2 * 25 5 return green_extensionDDPG在这个场景中的实际表现是在中等流量下比DQN更能适应突发的交通流变化。原因在于绿灯延长是可以连续变化的交通流量大时就延长得久一些流量小时就尽快结束相位这种柔性能力是离散动作难以做到的。3.3 韦氏公式: 经典配时方法的工程化实现韦氏配时方法不是强化学习但在信号控制领域地位极高。它通过两个公式计算最优信号周期和绿灯时间首先根据交叉口总流量与饱和流量的比值计算流量比Y然后代入韦氏最优周期公式得到周期时长C0最后按各相位流量比分配绿灯时间。具体计算过程如下项目里的四向路口假设南北直行流量为500pcu/h、左转200pcu/h东西直行400pcu/h、左转150pcu/h进口道饱和流率取1800pcu/h/lane。各相位流量比为车流量除以饱和流率乘以车道数Y_NS直 500 / (1800 * 2) 0.139 Y_NS左 200 / (1800 * 1) 0.111 Y_EW直 400 / (1800 * 2) 0.111 Y_EW左 150 / (1800 * 1) 0.083总流量比Y 0.444。韦氏最优周期公式为C0 (1.5L 5) / (1 - Y)其中L为总损失时间假设每个相位损失3秒四相位共12秒则C0 (1.5×125)/(1-0.444) 41.4秒。再按各相位流量比分配有效绿灯时间。这个周期长度在低流量下是合理的但如果流量上升到800pcu/h计算得到周期可能超过90秒此时行人过街就面临很大的等待压力。韦氏公式的Python实现并不复杂核心就是把上述公式翻译成代码def calculate_timing(flows, saturation1800, lost_time3): lane_count [2, 1, 2, 1] # 各相位进口车道数 y_values [f / (saturation * lc) for f, lc in zip(flows, lane_count)] Y sum(y_values) if Y 0.95: return None # 交叉口过饱和韦氏方法失效 total_lost 4 * lost_time cycle (1.5 * total_lost 5) / (1 - Y) greentime [] for y in y_values: ge (cycle - total_lost) * (y / Y) if Y 0 else 0 greentime.append(round(ge, 1)) return cycle, greentime注意当Y值超过0.95时韦氏公式的分母趋近于0算出的周期会达到几百秒没有任何实际意义。代码里做了容错处理直接返回None这是必须加的判断。我在调试时第一次没加这个判断流量设置失误导致Y0.98算出来周期270秒仿真跑起来一片红。3.4 最大压力控制: 分布式决策与网络稳定性最大压力算法在学术界被称为Backpressure算法它最吸引人的特性是理论上可以稳定所有不超过网络容量的流量矩阵不需要流量预测。项目实现的单路口版本中每个相位对应一组车道和下游车道压力定义为上游排队长度与下游可用容量之差。以南北直行相位为例压力值 该相位方向车道上的车辆总数 - 下游对应车道的可用空间。如果下游车道几乎满了压力值就会变小甚至为负这意味着即使上游排了很多车放行进去只是换了个地方堵着这时候切换到其他相位更合理。多个相位计算完压力后控制器选择压力最大的相位执行且执行时间固定为10秒不动态调整。这里有一个实现上的细节SUMO的TraCI接口读取车辆数并不是直接拿车道上的车辆列表而是根据车辆的lane_position来判断该车正在排队还是正在行驶。排队长度我取了车道最后5米内的车辆数压力用排队长度而不是总车辆数来计算。原因是这些车已经接近饱和状态直接决定路口是否溢出。def get_pressure(traci, phase_links): pressure 0 for upstream_lane, downstream_lane in phase_links: queue_up sum(1 for veh in traci.lane.getLastStepVehicleIDs(upstream_lane) if traci.vehicle.getLanePosition(veh) length - 5) queue_down sum(1 for veh in traci.lane.getLastStepVehicleIDs(downstream_lane) if traci.vehicle.getLanePosition(veh) 5) pressure queue_up - queue_down return pressure最大压力算法在实际运行中表现出的特点是低流量下它的表现不如韦氏因为它对每个相位的放行时间都一样不会根据流量比例优化绿信比但高流量过饱和场景下它几乎是五套方案里最不容易死锁的因为压力值的负反馈机制天然避免了向堵塞的下游继续放行。这个特性在小型路网实验里非常明显多路口串联时固定配时很容易出现上游放行、下游堵死的情况而最大压力算法会动态避让。3.5 自组织交通灯: 无需参数的响应式控制自组织交通灯的思路和前面四种完全不同它不做任何优化计算也不学习任何模型只依靠局部车辆到达信息做出反应。算法逻辑很简单每个相位有一个最小绿灯时间比如8秒和最大绿灯时间比如40秒。当相位进入绿灯后先执行最小绿灯时间之后每来一辆车如果距上一辆车到达的时间间隔小于设定的阈值比如3秒就把绿灯时间延长一个步长比如5秒如果连续超过3秒没有车辆到达或者绿灯时长已经到达最大限制就切换相位。这个规则模拟的是自然界中的自组织行为类似于行人过马路时按需等待的逻辑——有车就放行没车就切换。它的优势在于完全不需要标定参数不需要流量检测器的历史数据对任何方向性不均匀的交通流都很敏感。比如早晚高峰时某个方向车流明显大于其他方向自组织交通灯会自动把大部分绿灯时间分配给主方向而固定配时和韦氏配时做不到这种动态响应。实现上需要监听相位切换的状态def choose_action(self, traci, tl_id, current_phase_id, elapsed_time): if elapsed_time self.min_green: return current_phase_id, 0 # 保持当前相位 if elapsed_time self.max_green: return next_phase_id, 0 # 强制切换 # 检测当前相位车道是否有新到达车辆 recent_arrival self.latest_arrival_time.get(current_phase_id, 0) gap traci.simulation.getTime() - recent_arrival if gap self.switch_threshold: return next_phase_id, 0 else: return current_phase_id, self.extension_time这个算法的一个隐性问题是在连续车流的饱和状态下它可能永远不切换直到触达最大绿灯时间。因此最大绿灯时间的设定很关键项目里设40秒是为了保证其他方向的车不至于等太久。你可以根据实际路口的服务水平调整这个上限。实测中自组织交通灯在流量波动大的场景下平均等待时间比固定配时低30%到45%而且完全没有训练成本部署极其轻量。4. 实验评估体系与关键指标对比4.1 评估指标定义与数据采集方法五套算法到底谁好谁坏不能靠肉眼观察仿真动画得出结论必须有统一的量化指标。项目里定义了三个核心评估维度平均排队长度、平均等待时间和交叉口吞吐量。平均排队长度通过TraCI每10秒采样一次各进口道的排队车辆数求时间平均和空间平均。具体实现时要注意SUMO的getPendingCars返回的才是真正停在路口等待的车getLastStepVehicleNumber只是当前时刻通过检测器的车辆数两者语义完全不同。平均等待时间用getAccumulatedWaitingTime累加所有车辆的等待秒数再除以车辆数。吞吐量则是统计仿真结束时已经通过路口的车辆总数。数据采集有一个关键注意事项仿真启动后的前300秒属于加载阶段车辆刚开始生成路网还没充满这时候采集的数据没有统计意义。项目里统一做了一件事前300秒只让交通流加载不计算指标从300秒到仿真结束才算正式统计。这个细节直接影响最终的对比结论我见过不少论文里的仿真对比图前段数据噪声大到根本看不出规律基本都是没做稳态预热的。4.2 低流量场景下的算法表现对比低流量场景设置为各方向平均流量400pcu/h车辆到达较为稀疏。实验结果中最显著的现象是自组织交通灯的平均等待时间最低韦氏次之DQN和DDPG相对较差最大压力居中。自组织交通灯在这个场景下表现出色原因很直观流量稀疏意味着车流的到达间隙大自组织策略能在没车时快速切换到其他方向几乎不会产生空放时间。韦氏公式作为经典方法在低流量时也能给出相对合理的绿信比但因为它是根据平均流量做的静态配时无法响应随机到达的短时波动所以稍逊一筹。DQN和DDPG这时亏在训练过程中学到了一个偏向保守的策略经常倾向于延长当前相位绿灯因为训练数据里切换到新相位后短时间内没有车辆到达会被给予较低的奖励期望导致智能体产生了“继续延长绿灯也能获得奖励”的错觉。还有一个观察值得注意低流量场景下固定配时方案的平均等待时间只比DQN高出大约10%。这说明在流量稀疏时花大量成本训练强化学习模型的收益并不高。实际项目中如果路口饱和度低于0.5直接用韦氏或自组织策略更务实。4.3 高流量与过饱和场景下的对比结果把流量提升到各方向平均700pcu/h时实验结果发生了显著翻转。最大压力算法开始占据优势其次是DDPG、DQN、自组织韦氏配时排名垫底。韦氏配时在这个流量区间失守的直接原因是周期长度急剧增加。根据公式计算周期达到80到100秒这意味着每个方向都要等待很长时间才能轮到绿灯路口总排队长度快速累积。DDPG和DQN通过训练学到了一些应对策略在相位切换时更加积极但训练过程中偶尔出现严重的“连锁反应”——一个路口堵了反向的车辆就堵住前一个路口强化学习智能体在处理这种跨相位耦合时并不是很好。最大压力算法凭借压力值天然具备的流量感知能力在高流量下始终让压力最大的方向优先通过形成了一个稳定的放行节奏最终平均排队长度比韦氏低约40%比DQN低约18%。在过饱和场景下流量超过900pcu/h最大压力算法的优势更加明显。因为流量接近路网容量上限时任何一个错误决策都会造成不可逆的拥堵扩散而最大压力策略本质上是在每个决策时刻最大化“消除拥堵”的即时收益这种贪心策略在过饱和情况下非常有效。4.4 各算法综合对比结果汇总下面这个表格整理了五套算法在实验中的综合表现维度对比。需要注意表中的数据是项目默认场景的实测结果不同路网结构、不同流量矩阵下数值会有变化但大趋势是稳定的。算法训练/调参成本低流量表现高流量表现部署复杂度实时响应能力DQN高需数小时训练中中较高需维护模型和buffer中等DDPG高训练不稳定中低中高较高需调多个超参中等韦氏低只需流量参数高低极低纯解析公式无最大压力无中高低仅需排队长度高自组织无很高中极低纯规则高综合来看如果你追求的是稳定性、可解释性和免训练最大压力和自组织是首选。如果你更关注在复杂路网上的长期优化表现DQN、DDPG这类强化学习算法确实有潜力但要在状态设计、奖励函数和训练稳定性上投入大量时间。这个项目最大的价值就是帮你把五套方案放在起跑线一致的环境里跑一遍自己判断在不同交通条件下哪种策略最适合你的场景。5. 实战排障: 运行过程中最常见的15个问题5.1 环境与依赖类问题问题一import traci报错ModuleNotFoundError这个问题的根源几乎都是PYTHONPATH没有包含SUMO的tools目录。你需要在运行前执行export SUMO_HOME/usr/share/sumo export PYTHONPATH$SUMO_HOME/tools:$PYTHONPATH如果发现/usr/share/sumo下没有tools目录说明SUMO是通过apt安装的非完整版本需要额外安装sumo-tools包。问题二SUMO版本与代码不兼容项目代码用了一些较新的TraCI API比如vehicle.getAccumulatedWaitingTime这个接口在SUMO 1.8.0之前并不存在。如果你用的是更老的版本报错信息通常是AttributeError: module traci._vehicle has no attribute getAccumulatedWaitingTime。解决方案是升级SUMO版本或者在代码中做一个API兼容封装检测到旧版本时自动使用getWaitingTime代替。问题三Shell脚本执行时报Permission denied拿到项目压缩包后解压出来的Shell脚本默认没有可执行权限。运行前先执行chmod x run_all.sh或者直接用bash run_all.sh调用后者不需要可执行权限。5.2 SUMO与TraCI交互问题问题四TraCI连接被拒这个问题的典型报错是TraCI server connection refused或could not connect to port 8813。最常见的原因是端口被占用。一个SUMO实例只能被一个TraCI客户端连接如果你上一次运行程序没有正常退出残留的SUMO进程会继续占用端口。先执行pkill -f sumo清理掉残留进程再重新运行。问题五setPhase设置后信号灯状态没有变化这在调试时非常容易让人抓狂。原因通常是tlLogic的phase ID或subkey设置错误。在SUMO路网文件中每个信号灯的每个相位有一个duration属性TraCI的setPhase需要传入的是相位的索引数字而不是phase的name字符串。我的env_sumo.py里有一段辅助代码专门映射相位名称到索引比如用字典{NS_STRAIGHT: 0, NS_LEFT: 1, ...}这样代码可读性更高同时避免了索引错乱。问题六读取排队车辆数返回0如果你调用lane.getLastStepVehicleNumber读到的数值一直是0别急着怀疑代码逻辑。先检查车辆是否已经进入检测区域或者车辆是否因为仿真启动前的预热阶段还没生成到道路上。建议在读取前加一行调试输出打印simulation.getTime()确认仿真时间确实在车辆产生之后。5.3 强化学习训练与稳定性问题问题七DQN训练时奖励曲线发散Loss值飙升DQN的损失值飙升一般由两个原因引起奖励尺度不稳定或者目标网络更新频率过高。我第一版代码里奖励直接用了-1 * total_queue_length当拥堵加剧时奖励从-5降到-50Q值估计很容易爆炸。改进方法是对奖励做归一化或压缩比如-tanh(queue_length / 20)把奖励压缩到[-1, 0]区间训练稳定性显著提升。另一个改进是目标网络延迟更新每隔500步才同步一次权重而不是每步都同步。问题八DDPG训练时动作总是落在边界值DDPG的动作接近边界比如一直输出最高值30秒延长时间通常说明Critic网络对高动作值的评价偏高或者探索噪声太小导致策略缺乏多样性。解决方法增大探索噪声标准差到0.3强制策略去探索不同的绿灯延长时间同时检查Critic网络是否加入了L2正则化我在实现时给Critic加了一层weight_decay1e-5能有效抑制过拟合。问题九经验回放缓冲区里旧经验污染新策略特别是在交通流分布变化后比如从均匀流量切换到定向流量旧经验与当前交通态势差别很大。如果不做处理模型的训练效果会倒退。我在代码里加了一个简单机制当流量生成模式发生改变时清空重放缓冲区让模型只基于新环境数据训练。你也可以用更平滑的方式比如给旧经验设置更低的采样权重。问题十训练速度太慢一个周期要跑很久如果你每次训练都需要一两个小时的仿真时间检查一下SUMO启动时是否开启了--gui模式GUI渲染会大幅降低仿真速度。批量实验时应使用--no-warnings和--start参数将SUMO切换到无界面模式。另外仿真步长默认是1秒可以在sumocfg中把步长调为0.5秒但要注意这会影响控制决策的精度建议保持在1秒以内。5.4 数据与结果分析的问题问题十一多次运行同一算法的结果波动很大交通仿真中的随机流量由随机种子决定。项目里每次运行前会重新生成随机流量文件导致相同参数下的结果完全不同。要保证可重复性需要在sumo启动参数中固定--seed字段或者在配置文件中固定随机种子。我的实验脚本里默认从[2025, 2026, 2027]中依次取种子每种算法跑三次取平均这样结果的可信度和稳定性都好很多。问题十二车辆平均等待时间统计偏小如果你发现统计的平均等待时间比其他文章里报道的低得多先检查你的统计范围。SUMO的getAccumulatedWaitingTime计算的是一辆车在速度低于0.1m/s时的累计时间车辆在正常巡航时等待时间不累加所以这个指标更接近“停车延误”不包括减速延误和加速延误。如果你想统计完整的控制延误需要对每辆车的理想行程时间做基准差计算这个计算量比较大但对结果的分析更有意义。问题十三跑DDPG时显存或内存溢出DDPG的Actor和Critic网络虽然不大但经验回放缓冲区里的数据会持续累积。项目里设了maxlen50000的经验池每条数据包括18维状态、1维动作、奖励和下一状态大约占用几MB内存。如果跑大规模路网还同时并行多个实验内存就会吃紧。建议把经验池上限降到10000或者使用优先经验回放时只保存重要的高TD-error样本。问题十四多路口路网中一个信号控制器被重复控制traci.trafficlight.setPhase会作用于整个SUMO路网中所有匹配该ID的信号灯组。如果你的多路口路网中两个信号灯有相同的ID就会导致所有路口同时被设置成同一个相位。这在路网文件中很容易被忽略因为SUMO默认会为每个路口生成唯一ID但如果你手工修改了.net.xml就可能引入重复ID。排查方式是用traci.trafficlight.getIDList()打印所有信号灯ID确认没有重复项。问题十五SUMO启动时提示文件路径找不到.sumocfg文件中引用的.net.xml和.rou.xml文件路径是相对路径如果你的Shell脚本从别的路径下调用SUMO相对路径就会失效。我在脚本里统一做了处理确定工作目录后再启动SUMO——cd $(dirname $0) sumo -c nets/cross_4way.sumocfg$(dirname $0)表示脚本所在目录保证无论在哪个目录下执行run_all.sh都能正确定位配置文件。6. 实操心得: 从调通到复现完整实验的过程记录6.1 跑通第一步: 从固定配时到接入TraCI控制刚拿到项目代码的时候建议第一步不要直接跑强化学习而是先跑通最简单的韦氏控制器。原因是韦氏控制器不涉及训练过程逻辑简单能帮你快速验证SUMO环境、TraCI连接、数据读取整条链路是否正常。我当时的操作是先启动sumo-gui打开路网文件再手动运行python3 src/main.py --algo webster --gui true看到GUI里信号灯按预设的周期切换车辆正常排队和放行这时候你的环境才算是真正通了。固定配时作为对照组也很重要它提供了所有自适应算法的性能基线。在项目里src/fixed_time_controller.py实现了固定配时逻辑用来生成对照数据。我建议你每次跑算法实验时都把固定配时跑一遍因为它的结果是你判断其他算法是否有效的门槛——如果某一组算法的结果甚至不如固定配时那这个配置大概率是有问题的。6.2 调参过程与实验记录调试强化学习算法的过程中我深刻体会到两个原则的重要性第一每次只能改一个变量第二每次实验必须记录超参和结果。我吃过一次亏同时修改了学习率和奖励函数结果训练效果突然变好完全无法判断是哪个改动引起的。之后我写了个实验记录表把所有超参、流量配置、评估结果都记下来后来复盘和复现实验都省了很多力气。以下是DQN在默认四路口中比较稳定的一组关键参数可以作为初始配置参考参数值说明学习率0.001Adam优化器批量大小128每次从经验池采样经验池容量10000超出后丢弃旧经验探索衰减步数20000epsilon从1.0衰减到0.05目标网络软更新系数0.01每步向训练网络靠近1%决策间隔10秒每10秒决策一次奖励函数-(queue_len/20)tanh压缩后的负排队长度训练总步数50000约对应24小时仿真时间这组参数在默认场景下训练到20000步左右时奖励曲线开始收敛后续虽然仍有波动但整体趋势稳定。如果你的场景与默认差别较大优先加大探索衰减步数强化学习在信号控制中探索不足是最常见的问题宁可多探索也不能过早收敛到次优策略。6.3 结果图与数据分析工具项目里除了跑实验还附带了一个plot_results.py脚本用来生成三张核心图表平均排队长度时间线、平均等待时间箱线图、吞吐量累积曲线。画图用的库是matplotlib和seaborn运行前确保已安装pip install matplotlib seaborn pandas我之前画结果图时踩过一个坑SUMO记录的日志里时间戳是浮点数但采集的间隔不完全均匀直接画折线图会看到锯齿状。后来在plot_results.py里加了重采样逻辑把数据按10秒间隔重新对齐再画图曲线立刻平滑很多。如果你要分析自己的实验结果建议也做这一步。对于多路口路网单看平均排队长度不够直观建议额外输出一个排队热力图用matplotlib的imshow按时间步画路口排队矩阵你能一眼看出拥堵的是哪个方向的哪个路段这比看数字定位问题快得多。7. 基于实际经验的扩展建议7.1 算法选型决策树根据我在不同场景下的实测经验给你一个算法选型的参考逻辑。如果你的目标很明确是学术研究要强调创新性可以在DQN或DDPG的基础上改进状态表示或奖励函数如果你的目标是将信号控制部署到真实工程系统中韦氏和最大压力是最稳妥的选择因为它们不依赖复杂的训练过程且逻辑可解释如果你的路口交通流有明显的潮汐特征自组织交通灯几乎是最划算的选择——零训练、零调参效果却能比固定配时提升一个档次。具体到工程落地还需要考虑计算资源的限制。强化学习控制器需要实时运行神经网络推理即使网络只有三层全连接在低功耗的边缘设备上每次推理仍有几毫秒到几十毫秒的耗时对实时控制是一个负担。而最大压力和自组织只需要读取车辆检测器的数据做简单算术运算任何PLC或嵌入式控制器都能轻松完成。7.2 从单路口扩展到多路口协调项目自带的六路口小型路网是一个多路口协调的实验台。多路口场景的最大挑战不是某个单路口的优化而是相邻路口之间的联动。我在跑多路口实验时发现如果每个路口独立运行最大压力算法不做任何协调路口间的信号会出现相位差漂移导致车辆在一个路口刚通过绿灯到了下一个路口刚好赶上红灯形成“一路红灯”效应。解决这个问题有两种思路一种是用强化学习训练一个集中式控制器输入是整个路网所有路口的排队状态输出所有路口的相位另一种是在最大压力算法的基础上增加上游下游的压力传播机制把下游的压力加权纳入当前路口的决策中。前者精度高但训练维度爆炸六个路口就有上百维状态后者工程实现简单压力传播的权重系数需要调节但效果好、可解释性强。如果你考虑在项目基础上做扩展建议先试第二种用一两天的调参成本换一个稳定的多路口协调策略性价比很高。7.3 仿真到实地部署的鸿沟最后想聊一个很多人忽略的问题仿真里表现优秀的算法搬到现实中并不一定能复制效果。仿真环境里检测器数据是完美的没有丢失、没有噪声现实中地感线圈和视频检测器都有检测误差视频检测还会受天气和光照影响。最大压力算法对这种误差的容忍度很高因为压力本来就是相对值少量误差不会改变排序但DQN和DDPG对状态噪声就比较敏感训练时如果状态输入没有加噪声部署后性能会明显下降。我的建议是如果你打算把强化学习模型真正部署到路口的信号机上在仿真训练阶段就要给状态向量注入高斯噪声模拟真实检测器的读数误差。这是很多仿真到部署项目之间被忽视的一环却往往是决定项目能否稳定运行的关键。这个项目留给你的扩展方向非常多无论是把算法换成更先进的PPO、SAC还是把场景换成真实的城市级路网都能在这个底座上快速起步。希望这份梳理能帮你在自己的实验里少踩几个坑把更多时间花在有价值的算法研究和工程落地上。本文还有配套的精品资源点击获取 SUMO交通仿真中五种自适应信号控制算法实战对比
简介本资源是一套基于SUMO平台的多策略自适应交通信号控制系统实现面向智能交通系统研究者、强化学习初学者及城市交通工程实践者聚焦于缓解交叉口拥堵、提升通行效率的核心问题。压缩包共54个文件含37个Python核心模块涵盖DQN/DDPG智能体训练、韦氏算法调度、最大压力策略实现及自组织控制逻辑、5个Shell脚本用于环境配置、模型训练与结果生成、4张性能对比图表如hp.png、travel_time.png以及SUMO网络配置文件.sumocfg/.net.xml和完整项目文档README.md、LICENSE等整体仅1.35MB轻量易部署。已有1321人学习下载提供从仿真环境搭建、算法复现到结果可视化的一站式代码支持尤其适合开展交通信号控制算法对比实验、课程设计或科研原型验证。 很多做交通仿真的朋友应该都有过这种体验跑SUMO自带的交通灯算例时默认的固定配时方案在车流量变化后排队长度肉眼可见地往上堆。光调绿灯时长就得反复试调完这组路口旁边路口又开始堵。后来我接触到自适应信号控制才意识到问题核心不在于你配时配得好不好而在于固定配时根本没有“感知”能力。这个项目就是把目前主流的几种自适应控制算法——DQN、DDPG、韦氏Webster、最大压力Max Pressure和自组织交通灯——全部在SUMO里实现并放在一起横向对比用Python写控制逻辑用Shell脚本一键完成仿真、训练和结果汇总。无论你是刚接触SUMO的交通专业学生还是想在企业项目里落地强化学习信号控制的研究人员这套框架都能让你少走很多弯路。整个项目解决了一个很具体的问题同样的路口、同样的车流量不同的信号控制策略到底差多少固定配时、经典配时公式、无模型强化学习、以及完全分布式的自组织策略这五条技术路线放在同一套仿真环境里公平对比从排队长度、平均等待时间、吞吐量三个维度给出量化结果。我把整个项目的设计思路、算法原理、代码结构、运行流程和排障经验整理成文希望能帮你快速把环境跑起来并且真正理解每种控制策略的适用场景。1. 项目整体设计与技术选型思路1.1 为什么选择SUMO作为统一仿真平台市面上的交通仿真工具很多VISSIM、TransModeler、MATSim各有优势但我个人始终觉得SUMO是跑强化学习信号控制最合适的平台没有之一。原因有三点第一SUMO完全开源免费没有License限制批量跑实验不用心疼授权费第二TraCI接口提供了非常细粒度的控制能力你不仅能读到每辆车的实时位置、速度、加速度还能直接修改交通灯的相位和持续时间这对强化学习训练来说是刚需第三SUMO原生支持在线交互模式仿真过程中Python脚本可以实时读取状态、执行动作、获取奖励天然适配RL的env-loop结构。这个项目里所有算法都跑在SUMO 1.8.0以上的版本。之所以选这个版本线是因为1.8之后TraCI的接口命名规范了很多比如traci.trafficlight.getControlledLinks、traci.vehicle.getAccumulatedWaitingTime这些API都趋于稳定网上资料也最多遇到问题基本都能搜到解法。另外SUMO提供了sumo-gui可视化界面调试阶段我会开着GUI观察车辆是否真的按照预期逻辑在路口排队和放行确认逻辑无误后再切到sumo命令行模式批量跑数据。1.2 五种算法的选型逻辑与应用场景这个项目最核心的设计决策就是把三种完全不同范式的控制策略放在同一套评估体系下横向比较。DQN和DDPG属于强化学习路线。DQN解决的是离散动作空间的问题通常把信号相位组合离散成几个固定动作比如直行绿灯、左转绿灯、全红清空等DDPG则面向连续控制场景虽然交通灯本身是离散的但DDPG可以输出连续的压力值或者绿灯延长时间再通过映射函数转换到实际相位。在工程落地中DQN更适合路口相位组合固定、动作空间有限的场景训练相对稳定DDPG适合需要精细调节绿灯延时时长的场景但对超参更敏感调起来更费劲。韦氏公式是经典的解析配时方法。它基于车辆到达率和饱和流率通过最小化平均延误计算最优周期时长和绿灯时间分配。这个算法在低饱和度的交叉口表现很好计算简单、工程上容易实现国内很多早期信号机项目用的就是韦氏配时或者它的改良版本。它的问题在于模型假设是稳态到达实际交通流是时变的一旦流量波动大配时就会逐渐失配。最大压力算法则是一种分布式控制策略它的核心思路是对每个相位计算“压力”——即当前相位对应的车道内车辆数与下游可用空间之间的差值然后优先放行压力最大的相位。这种算法有严格的理论保证在很多文献里被证明在过饱和路网下能够稳定网络流量而且不需要预测未来流量只需要当前时刻的状态部署成本极低。自组织交通灯走的是另一条路。它借鉴了物理系统中的自组织临界性思想绿灯时间不是预设的而是根据车流的实际到达情况自动延长或切换。具体实现时通常设定一个最小绿灯时间和一个最大绿灯时间只要检测到当前相位仍有连续车辆到达且未超最大绿灯时间就持续保持该相位绿灯。这个策略特别适合车流量间歇性很强的路口能大幅减少空放时间。1.3 项目目录结构与模块划分代码仓库的目录结构设计得比较清晰拿到压缩包解压后你第一眼能看到的是src、nets、results和run_all.sh这几个核心部分。nets目录存放SUMO路网文件我默认放了一个经典的四向十字路口和一个六路口的小型路网前者用来快速验证算法逻辑后者用来测试多路口协调场景。src目录下按算法划分了dqn_agent.py、ddpg_agent.py、webster_controller.py、max_pressure_controller.py、self_organizing_controller.py五个主控文件外加一个env_sumo.py负责封装SUMO的TraCI交互一个evaluate.py用于统一定义评估指标。所有控制器的接口是统一的都实现了choose_action(state)和update(state, action, reward, next_state)这两个方法。这样设计的好处是评估脚本完全不需要关心具体算法内部怎么实现只需要按固定顺序调用接口、收集数据、写日志。如果你以后想加入新的控制算法比如POMDP或者MPC只需新建一个文件并实现这两个方法其他代码完全不用改动。这个接口设计思路强烈建议保持因为它直接决定了后续实验迭代的效率。2. SUMO仿真环境搭建与项目配置文件解析2.1 环境安装与版本匹配建议使用Linux系统跑这个项目Windows当然也能跑但Shell脚本的兼容性和SUMO的进程管理在Linux下要省心很多。安装部分我用的是Ubuntu 20.04直接通过apt安装SUMOsudo apt update sudo apt install sumo sumo-tools sumo-doc安装完成后检查一下版本确保TraCI接口可用sumo --version输出里会出现SUMO Version 1.8.0这样的信息。如果版本低于1.8部分API可能不兼容建议升级。Python端需要安装traci库SUMO自带的Python工具包通常位于/usr/share/sumo/tools你需要把它加到PYTHONPATH环境变量中export SUMO_HOME/usr/share/sumo export PYTHONPATH$SUMO_HOME/tools:$PYTHONPATH如果你习惯用虚拟环境建议用python3 -m venv sumo_env创建独立环境再在activate脚本里写死这两行环境变量避免每次手动导出。我早期没有做这步换了个终端环境跑代码结果import traci直接报ModuleNotFoundError排查半天才发现是环境变量丢了。2.2 路网文件与流量配置的核心参数路网文件是整个仿真实验的地基。项目里默认的四向十字路口结构是每条方向有两个车道左转和直行共用一个车道组没有单独设置右转专用道符合国内大部分城市交叉口的典型特征。信号相位设置为四相位固定序南北直行、南北左转、东西直行、东西左转每个相位之间插入3秒黄灯。流量配置我写成了两种模式固定流量和随机流量。固定模式下四条道路各方向的车辆到达率是常量比如每小时600辆随机模式下我用SUMO的flow模块生成泊松分布的随机到达序列。这里有个重要参数需要重点关注就是vehsPerHour的取值。单向车流量低于300pcu/h时固定配时和自适应算法的差距并不大因为路口根本不会拥堵但车流量超过600pcu/h后固定配时的排队长度会快速上升这时自适应算法的优势会被放大。建议调试阶段先跑低流量验证逻辑正式对比实验再用高流量。nets目录下的.net.xml文件里信号灯组的定义是关键。SUMO用tlLogic标签定义信号控制器里面每个phase标签代表一个相位。你需要确保代码里读取的相位ID与路网文件中的id完全一致否则TraCI调用时你会拿到一堆空返回值。最常见的错误是大小写不匹配路网文件中定义的是tl_0代码里写成了TL_0导致traci.trafficlight.setPhase没有生效。2.3 Shell脚本一键化运行设计run_all.sh是整个项目的总入口它的设计目标是让任何人拿到代码后输入一行命令就能完成全部五组实验。脚本逻辑分为四个阶段检查环境、启动仿真、训练/控制算法、汇总结果。核心部分用bash实现配合wait命令并行处理多个独立实验大幅缩短总运行时间。#!/bin/bash # 阶段1: 检查环境 which sumo /dev/null 21 if [ $? -ne 0 ]; then echo sumo not found in PATH exit 1 fi # 阶段2: 依次运行各算法 for algo in webster max_pressure self_organizing dqn ddpg; do python3 src/main.py --algo $algo --config nets/cross_4way.sumocfg logs/${algo}.log 21 done wait这段脚本的关键点是wait命令它让五个算法并行跑实测中比串行节省了大约60%的时间。不过要注意并行跑需要确保每个SUMO实例使用不同的端口默认的TraCI端口是8813同一时刻只能有一个实例占用。我在main.py里通过--port参数控制不同实验使用不同端口对应关系在Shell脚本里用数组维护declare -a ports(8813 8814 8815 8816 8817)这个细节如果不处理并行执行时后启动的算法会直接报connection refused或者端口被占用的错误非常容易踩坑。3. 五种信号控制算法的原理与Python实现3.1 DQN: 基于值函数的离散相位决策DQN的建模思路比较直观把信号控制看作一个马尔可夫决策过程状态是当前路口的交通状态动作是选择一个信号相位奖励是控制效果的反馈。这个项目里状态向量的设计是当前各车道的排队长度单位辆、当前各车道的平均等待时间单位秒、当前相位编号、当前相位已持续时长。这四类信息拼接起来向量维度是4个方向×2条车道×2种信息2个相位信息18维足够表达一个单路口的短时交通态势。动作空间设计为四个离散相位即南北直行、南北左转、东西直行、东西左转每次决策时智能体选择一个相位并持续执行10秒然后再次做出决策。这样的设计把连续时间问题离散化强化学习智能体不需要每一秒都做决策大幅降低训练难度。如果每1秒就决策一次状态转移的随机性太强训练很难收敛10秒一个决策粒度既保留了响应实时性又让每个动作的奖励信号更稳定。DQN的网络结构用的是三层全连接网络隐藏层维度分别是256和128激活函数用ReLU。经验回放缓冲区大小设为10000每次训练从缓冲区随机采样128条经验。这里有两个关键超参需要重点调整学习率初始值设为0.001如果训练过程中奖励曲线震荡太剧烈就把学习率降到0.0005探索率epsilon采用线性衰减策略从1.0衰减到0.05衰减步数设为20000步确保前期充分探索、后期充分利用。核心代码逻辑如下class DQNAgent: def __init__(self, state_dim, action_dim): self.q_net self._build_q_network(state_dim, action_dim) self.target_net self._build_q_network(state_dim, action_dim) self.replay_buffer deque(maxlen10000) self.epsilon 1.0 self.batch_size 128 def choose_action(self, state): if np.random.rand() self.epsilon: return np.random.choice(self.action_dim) q_values self.q_net.predict(state.reshape(1, -1), verbose0) return np.argmax(q_values[0])这里有个细节容易被忽略目标网络不能每一步都从训练网络直接复制权重否则训练会不稳定。我采用软更新策略每次训练后让目标网络权重以0.01的比例向训练网络靠拢而不是硬拷贝。这个做法来自DQN的改进版本实测下来训练曲线平滑很多收敛速度也快了不少。3.2 DDPG: 连续绿灯延长时间策略DDPG在信号控制领域用得比DQN少但处理可变的绿灯时间这种柔性决策任务DDPG的连续输出特性是有优势的。这个项目里的DDPG不是直接选择离散相位而是输出一个绿灯延长时间值范围限制在5秒到30秒之间。原本的逻辑是当前相位先执行最小绿灯时间5秒然后DDPG根据当前交通状态决定是否延长绿灯、延长多少秒。状态空间和DQN基本一致区别在于动作空间从离散的四选一变成了连续的一维数值。Actor网络输出层的激活函数用tanh将输出映射到[-1, 1]再线性变换到[5, 30]区间。Critic网络输入是状态和动作的拼接向量输出一个Q值。DDPG训练中最常见的问题是Q值估计发散。我加了两个机制来解决第一是目标策略平滑正则化在目标Q值的计算中对动作加上正态分布噪声抑制过估计第二是Critic网络的学习率降到0.0002低于Actor的0.0001保持稳定。噪声在训练前期设为0.3每5000步衰减0.05最低到0.05。推理阶段关闭所有探索噪声直接用Actor网络输出原生动作。def choose_action(self, state): state np.expand_dims(state, axis0) action self.actor.predict(state)[0] if self.training: noise np.random.normal(0, self.noise_std) action np.clip(action noise, -1, 1) green_extension (action 1) / 2 * 25 5 return green_extensionDDPG在这个场景中的实际表现是在中等流量下比DQN更能适应突发的交通流变化。原因在于绿灯延长是可以连续变化的交通流量大时就延长得久一些流量小时就尽快结束相位这种柔性能力是离散动作难以做到的。3.3 韦氏公式: 经典配时方法的工程化实现韦氏配时方法不是强化学习但在信号控制领域地位极高。它通过两个公式计算最优信号周期和绿灯时间首先根据交叉口总流量与饱和流量的比值计算流量比Y然后代入韦氏最优周期公式得到周期时长C0最后按各相位流量比分配绿灯时间。具体计算过程如下项目里的四向路口假设南北直行流量为500pcu/h、左转200pcu/h东西直行400pcu/h、左转150pcu/h进口道饱和流率取1800pcu/h/lane。各相位流量比为车流量除以饱和流率乘以车道数Y_NS直 500 / (1800 * 2) 0.139 Y_NS左 200 / (1800 * 1) 0.111 Y_EW直 400 / (1800 * 2) 0.111 Y_EW左 150 / (1800 * 1) 0.083总流量比Y 0.444。韦氏最优周期公式为C0 (1.5L 5) / (1 - Y)其中L为总损失时间假设每个相位损失3秒四相位共12秒则C0 (1.5×125)/(1-0.444) 41.4秒。再按各相位流量比分配有效绿灯时间。这个周期长度在低流量下是合理的但如果流量上升到800pcu/h计算得到周期可能超过90秒此时行人过街就面临很大的等待压力。韦氏公式的Python实现并不复杂核心就是把上述公式翻译成代码def calculate_timing(flows, saturation1800, lost_time3): lane_count [2, 1, 2, 1] # 各相位进口车道数 y_values [f / (saturation * lc) for f, lc in zip(flows, lane_count)] Y sum(y_values) if Y 0.95: return None # 交叉口过饱和韦氏方法失效 total_lost 4 * lost_time cycle (1.5 * total_lost 5) / (1 - Y) greentime [] for y in y_values: ge (cycle - total_lost) * (y / Y) if Y 0 else 0 greentime.append(round(ge, 1)) return cycle, greentime注意当Y值超过0.95时韦氏公式的分母趋近于0算出的周期会达到几百秒没有任何实际意义。代码里做了容错处理直接返回None这是必须加的判断。我在调试时第一次没加这个判断流量设置失误导致Y0.98算出来周期270秒仿真跑起来一片红。3.4 最大压力控制: 分布式决策与网络稳定性最大压力算法在学术界被称为Backpressure算法它最吸引人的特性是理论上可以稳定所有不超过网络容量的流量矩阵不需要流量预测。项目实现的单路口版本中每个相位对应一组车道和下游车道压力定义为上游排队长度与下游可用容量之差。以南北直行相位为例压力值 该相位方向车道上的车辆总数 - 下游对应车道的可用空间。如果下游车道几乎满了压力值就会变小甚至为负这意味着即使上游排了很多车放行进去只是换了个地方堵着这时候切换到其他相位更合理。多个相位计算完压力后控制器选择压力最大的相位执行且执行时间固定为10秒不动态调整。这里有一个实现上的细节SUMO的TraCI接口读取车辆数并不是直接拿车道上的车辆列表而是根据车辆的lane_position来判断该车正在排队还是正在行驶。排队长度我取了车道最后5米内的车辆数压力用排队长度而不是总车辆数来计算。原因是这些车已经接近饱和状态直接决定路口是否溢出。def get_pressure(traci, phase_links): pressure 0 for upstream_lane, downstream_lane in phase_links: queue_up sum(1 for veh in traci.lane.getLastStepVehicleIDs(upstream_lane) if traci.vehicle.getLanePosition(veh) length - 5) queue_down sum(1 for veh in traci.lane.getLastStepVehicleIDs(downstream_lane) if traci.vehicle.getLanePosition(veh) 5) pressure queue_up - queue_down return pressure最大压力算法在实际运行中表现出的特点是低流量下它的表现不如韦氏因为它对每个相位的放行时间都一样不会根据流量比例优化绿信比但高流量过饱和场景下它几乎是五套方案里最不容易死锁的因为压力值的负反馈机制天然避免了向堵塞的下游继续放行。这个特性在小型路网实验里非常明显多路口串联时固定配时很容易出现上游放行、下游堵死的情况而最大压力算法会动态避让。3.5 自组织交通灯: 无需参数的响应式控制自组织交通灯的思路和前面四种完全不同它不做任何优化计算也不学习任何模型只依靠局部车辆到达信息做出反应。算法逻辑很简单每个相位有一个最小绿灯时间比如8秒和最大绿灯时间比如40秒。当相位进入绿灯后先执行最小绿灯时间之后每来一辆车如果距上一辆车到达的时间间隔小于设定的阈值比如3秒就把绿灯时间延长一个步长比如5秒如果连续超过3秒没有车辆到达或者绿灯时长已经到达最大限制就切换相位。这个规则模拟的是自然界中的自组织行为类似于行人过马路时按需等待的逻辑——有车就放行没车就切换。它的优势在于完全不需要标定参数不需要流量检测器的历史数据对任何方向性不均匀的交通流都很敏感。比如早晚高峰时某个方向车流明显大于其他方向自组织交通灯会自动把大部分绿灯时间分配给主方向而固定配时和韦氏配时做不到这种动态响应。实现上需要监听相位切换的状态def choose_action(self, traci, tl_id, current_phase_id, elapsed_time): if elapsed_time self.min_green: return current_phase_id, 0 # 保持当前相位 if elapsed_time self.max_green: return next_phase_id, 0 # 强制切换 # 检测当前相位车道是否有新到达车辆 recent_arrival self.latest_arrival_time.get(current_phase_id, 0) gap traci.simulation.getTime() - recent_arrival if gap self.switch_threshold: return next_phase_id, 0 else: return current_phase_id, self.extension_time这个算法的一个隐性问题是在连续车流的饱和状态下它可能永远不切换直到触达最大绿灯时间。因此最大绿灯时间的设定很关键项目里设40秒是为了保证其他方向的车不至于等太久。你可以根据实际路口的服务水平调整这个上限。实测中自组织交通灯在流量波动大的场景下平均等待时间比固定配时低30%到45%而且完全没有训练成本部署极其轻量。4. 实验评估体系与关键指标对比4.1 评估指标定义与数据采集方法五套算法到底谁好谁坏不能靠肉眼观察仿真动画得出结论必须有统一的量化指标。项目里定义了三个核心评估维度平均排队长度、平均等待时间和交叉口吞吐量。平均排队长度通过TraCI每10秒采样一次各进口道的排队车辆数求时间平均和空间平均。具体实现时要注意SUMO的getPendingCars返回的才是真正停在路口等待的车getLastStepVehicleNumber只是当前时刻通过检测器的车辆数两者语义完全不同。平均等待时间用getAccumulatedWaitingTime累加所有车辆的等待秒数再除以车辆数。吞吐量则是统计仿真结束时已经通过路口的车辆总数。数据采集有一个关键注意事项仿真启动后的前300秒属于加载阶段车辆刚开始生成路网还没充满这时候采集的数据没有统计意义。项目里统一做了一件事前300秒只让交通流加载不计算指标从300秒到仿真结束才算正式统计。这个细节直接影响最终的对比结论我见过不少论文里的仿真对比图前段数据噪声大到根本看不出规律基本都是没做稳态预热的。4.2 低流量场景下的算法表现对比低流量场景设置为各方向平均流量400pcu/h车辆到达较为稀疏。实验结果中最显著的现象是自组织交通灯的平均等待时间最低韦氏次之DQN和DDPG相对较差最大压力居中。自组织交通灯在这个场景下表现出色原因很直观流量稀疏意味着车流的到达间隙大自组织策略能在没车时快速切换到其他方向几乎不会产生空放时间。韦氏公式作为经典方法在低流量时也能给出相对合理的绿信比但因为它是根据平均流量做的静态配时无法响应随机到达的短时波动所以稍逊一筹。DQN和DDPG这时亏在训练过程中学到了一个偏向保守的策略经常倾向于延长当前相位绿灯因为训练数据里切换到新相位后短时间内没有车辆到达会被给予较低的奖励期望导致智能体产生了“继续延长绿灯也能获得奖励”的错觉。还有一个观察值得注意低流量场景下固定配时方案的平均等待时间只比DQN高出大约10%。这说明在流量稀疏时花大量成本训练强化学习模型的收益并不高。实际项目中如果路口饱和度低于0.5直接用韦氏或自组织策略更务实。4.3 高流量与过饱和场景下的对比结果把流量提升到各方向平均700pcu/h时实验结果发生了显著翻转。最大压力算法开始占据优势其次是DDPG、DQN、自组织韦氏配时排名垫底。韦氏配时在这个流量区间失守的直接原因是周期长度急剧增加。根据公式计算周期达到80到100秒这意味着每个方向都要等待很长时间才能轮到绿灯路口总排队长度快速累积。DDPG和DQN通过训练学到了一些应对策略在相位切换时更加积极但训练过程中偶尔出现严重的“连锁反应”——一个路口堵了反向的车辆就堵住前一个路口强化学习智能体在处理这种跨相位耦合时并不是很好。最大压力算法凭借压力值天然具备的流量感知能力在高流量下始终让压力最大的方向优先通过形成了一个稳定的放行节奏最终平均排队长度比韦氏低约40%比DQN低约18%。在过饱和场景下流量超过900pcu/h最大压力算法的优势更加明显。因为流量接近路网容量上限时任何一个错误决策都会造成不可逆的拥堵扩散而最大压力策略本质上是在每个决策时刻最大化“消除拥堵”的即时收益这种贪心策略在过饱和情况下非常有效。4.4 各算法综合对比结果汇总下面这个表格整理了五套算法在实验中的综合表现维度对比。需要注意表中的数据是项目默认场景的实测结果不同路网结构、不同流量矩阵下数值会有变化但大趋势是稳定的。算法训练/调参成本低流量表现高流量表现部署复杂度实时响应能力DQN高需数小时训练中中较高需维护模型和buffer中等DDPG高训练不稳定中低中高较高需调多个超参中等韦氏低只需流量参数高低极低纯解析公式无最大压力无中高低仅需排队长度高自组织无很高中极低纯规则高综合来看如果你追求的是稳定性、可解释性和免训练最大压力和自组织是首选。如果你更关注在复杂路网上的长期优化表现DQN、DDPG这类强化学习算法确实有潜力但要在状态设计、奖励函数和训练稳定性上投入大量时间。这个项目最大的价值就是帮你把五套方案放在起跑线一致的环境里跑一遍自己判断在不同交通条件下哪种策略最适合你的场景。5. 实战排障: 运行过程中最常见的15个问题5.1 环境与依赖类问题问题一import traci报错ModuleNotFoundError这个问题的根源几乎都是PYTHONPATH没有包含SUMO的tools目录。你需要在运行前执行export SUMO_HOME/usr/share/sumo export PYTHONPATH$SUMO_HOME/tools:$PYTHONPATH如果发现/usr/share/sumo下没有tools目录说明SUMO是通过apt安装的非完整版本需要额外安装sumo-tools包。问题二SUMO版本与代码不兼容项目代码用了一些较新的TraCI API比如vehicle.getAccumulatedWaitingTime这个接口在SUMO 1.8.0之前并不存在。如果你用的是更老的版本报错信息通常是AttributeError: module traci._vehicle has no attribute getAccumulatedWaitingTime。解决方案是升级SUMO版本或者在代码中做一个API兼容封装检测到旧版本时自动使用getWaitingTime代替。问题三Shell脚本执行时报Permission denied拿到项目压缩包后解压出来的Shell脚本默认没有可执行权限。运行前先执行chmod x run_all.sh或者直接用bash run_all.sh调用后者不需要可执行权限。5.2 SUMO与TraCI交互问题问题四TraCI连接被拒这个问题的典型报错是TraCI server connection refused或could not connect to port 8813。最常见的原因是端口被占用。一个SUMO实例只能被一个TraCI客户端连接如果你上一次运行程序没有正常退出残留的SUMO进程会继续占用端口。先执行pkill -f sumo清理掉残留进程再重新运行。问题五setPhase设置后信号灯状态没有变化这在调试时非常容易让人抓狂。原因通常是tlLogic的phase ID或subkey设置错误。在SUMO路网文件中每个信号灯的每个相位有一个duration属性TraCI的setPhase需要传入的是相位的索引数字而不是phase的name字符串。我的env_sumo.py里有一段辅助代码专门映射相位名称到索引比如用字典{NS_STRAIGHT: 0, NS_LEFT: 1, ...}这样代码可读性更高同时避免了索引错乱。问题六读取排队车辆数返回0如果你调用lane.getLastStepVehicleNumber读到的数值一直是0别急着怀疑代码逻辑。先检查车辆是否已经进入检测区域或者车辆是否因为仿真启动前的预热阶段还没生成到道路上。建议在读取前加一行调试输出打印simulation.getTime()确认仿真时间确实在车辆产生之后。5.3 强化学习训练与稳定性问题问题七DQN训练时奖励曲线发散Loss值飙升DQN的损失值飙升一般由两个原因引起奖励尺度不稳定或者目标网络更新频率过高。我第一版代码里奖励直接用了-1 * total_queue_length当拥堵加剧时奖励从-5降到-50Q值估计很容易爆炸。改进方法是对奖励做归一化或压缩比如-tanh(queue_length / 20)把奖励压缩到[-1, 0]区间训练稳定性显著提升。另一个改进是目标网络延迟更新每隔500步才同步一次权重而不是每步都同步。问题八DDPG训练时动作总是落在边界值DDPG的动作接近边界比如一直输出最高值30秒延长时间通常说明Critic网络对高动作值的评价偏高或者探索噪声太小导致策略缺乏多样性。解决方法增大探索噪声标准差到0.3强制策略去探索不同的绿灯延长时间同时检查Critic网络是否加入了L2正则化我在实现时给Critic加了一层weight_decay1e-5能有效抑制过拟合。问题九经验回放缓冲区里旧经验污染新策略特别是在交通流分布变化后比如从均匀流量切换到定向流量旧经验与当前交通态势差别很大。如果不做处理模型的训练效果会倒退。我在代码里加了一个简单机制当流量生成模式发生改变时清空重放缓冲区让模型只基于新环境数据训练。你也可以用更平滑的方式比如给旧经验设置更低的采样权重。问题十训练速度太慢一个周期要跑很久如果你每次训练都需要一两个小时的仿真时间检查一下SUMO启动时是否开启了--gui模式GUI渲染会大幅降低仿真速度。批量实验时应使用--no-warnings和--start参数将SUMO切换到无界面模式。另外仿真步长默认是1秒可以在sumocfg中把步长调为0.5秒但要注意这会影响控制决策的精度建议保持在1秒以内。5.4 数据与结果分析的问题问题十一多次运行同一算法的结果波动很大交通仿真中的随机流量由随机种子决定。项目里每次运行前会重新生成随机流量文件导致相同参数下的结果完全不同。要保证可重复性需要在sumo启动参数中固定--seed字段或者在配置文件中固定随机种子。我的实验脚本里默认从[2025, 2026, 2027]中依次取种子每种算法跑三次取平均这样结果的可信度和稳定性都好很多。问题十二车辆平均等待时间统计偏小如果你发现统计的平均等待时间比其他文章里报道的低得多先检查你的统计范围。SUMO的getAccumulatedWaitingTime计算的是一辆车在速度低于0.1m/s时的累计时间车辆在正常巡航时等待时间不累加所以这个指标更接近“停车延误”不包括减速延误和加速延误。如果你想统计完整的控制延误需要对每辆车的理想行程时间做基准差计算这个计算量比较大但对结果的分析更有意义。问题十三跑DDPG时显存或内存溢出DDPG的Actor和Critic网络虽然不大但经验回放缓冲区里的数据会持续累积。项目里设了maxlen50000的经验池每条数据包括18维状态、1维动作、奖励和下一状态大约占用几MB内存。如果跑大规模路网还同时并行多个实验内存就会吃紧。建议把经验池上限降到10000或者使用优先经验回放时只保存重要的高TD-error样本。问题十四多路口路网中一个信号控制器被重复控制traci.trafficlight.setPhase会作用于整个SUMO路网中所有匹配该ID的信号灯组。如果你的多路口路网中两个信号灯有相同的ID就会导致所有路口同时被设置成同一个相位。这在路网文件中很容易被忽略因为SUMO默认会为每个路口生成唯一ID但如果你手工修改了.net.xml就可能引入重复ID。排查方式是用traci.trafficlight.getIDList()打印所有信号灯ID确认没有重复项。问题十五SUMO启动时提示文件路径找不到.sumocfg文件中引用的.net.xml和.rou.xml文件路径是相对路径如果你的Shell脚本从别的路径下调用SUMO相对路径就会失效。我在脚本里统一做了处理确定工作目录后再启动SUMO——cd $(dirname $0) sumo -c nets/cross_4way.sumocfg$(dirname $0)表示脚本所在目录保证无论在哪个目录下执行run_all.sh都能正确定位配置文件。6. 实操心得: 从调通到复现完整实验的过程记录6.1 跑通第一步: 从固定配时到接入TraCI控制刚拿到项目代码的时候建议第一步不要直接跑强化学习而是先跑通最简单的韦氏控制器。原因是韦氏控制器不涉及训练过程逻辑简单能帮你快速验证SUMO环境、TraCI连接、数据读取整条链路是否正常。我当时的操作是先启动sumo-gui打开路网文件再手动运行python3 src/main.py --algo webster --gui true看到GUI里信号灯按预设的周期切换车辆正常排队和放行这时候你的环境才算是真正通了。固定配时作为对照组也很重要它提供了所有自适应算法的性能基线。在项目里src/fixed_time_controller.py实现了固定配时逻辑用来生成对照数据。我建议你每次跑算法实验时都把固定配时跑一遍因为它的结果是你判断其他算法是否有效的门槛——如果某一组算法的结果甚至不如固定配时那这个配置大概率是有问题的。6.2 调参过程与实验记录调试强化学习算法的过程中我深刻体会到两个原则的重要性第一每次只能改一个变量第二每次实验必须记录超参和结果。我吃过一次亏同时修改了学习率和奖励函数结果训练效果突然变好完全无法判断是哪个改动引起的。之后我写了个实验记录表把所有超参、流量配置、评估结果都记下来后来复盘和复现实验都省了很多力气。以下是DQN在默认四路口中比较稳定的一组关键参数可以作为初始配置参考参数值说明学习率0.001Adam优化器批量大小128每次从经验池采样经验池容量10000超出后丢弃旧经验探索衰减步数20000epsilon从1.0衰减到0.05目标网络软更新系数0.01每步向训练网络靠近1%决策间隔10秒每10秒决策一次奖励函数-(queue_len/20)tanh压缩后的负排队长度训练总步数50000约对应24小时仿真时间这组参数在默认场景下训练到20000步左右时奖励曲线开始收敛后续虽然仍有波动但整体趋势稳定。如果你的场景与默认差别较大优先加大探索衰减步数强化学习在信号控制中探索不足是最常见的问题宁可多探索也不能过早收敛到次优策略。6.3 结果图与数据分析工具项目里除了跑实验还附带了一个plot_results.py脚本用来生成三张核心图表平均排队长度时间线、平均等待时间箱线图、吞吐量累积曲线。画图用的库是matplotlib和seaborn运行前确保已安装pip install matplotlib seaborn pandas我之前画结果图时踩过一个坑SUMO记录的日志里时间戳是浮点数但采集的间隔不完全均匀直接画折线图会看到锯齿状。后来在plot_results.py里加了重采样逻辑把数据按10秒间隔重新对齐再画图曲线立刻平滑很多。如果你要分析自己的实验结果建议也做这一步。对于多路口路网单看平均排队长度不够直观建议额外输出一个排队热力图用matplotlib的imshow按时间步画路口排队矩阵你能一眼看出拥堵的是哪个方向的哪个路段这比看数字定位问题快得多。7. 基于实际经验的扩展建议7.1 算法选型决策树根据我在不同场景下的实测经验给你一个算法选型的参考逻辑。如果你的目标很明确是学术研究要强调创新性可以在DQN或DDPG的基础上改进状态表示或奖励函数如果你的目标是将信号控制部署到真实工程系统中韦氏和最大压力是最稳妥的选择因为它们不依赖复杂的训练过程且逻辑可解释如果你的路口交通流有明显的潮汐特征自组织交通灯几乎是最划算的选择——零训练、零调参效果却能比固定配时提升一个档次。具体到工程落地还需要考虑计算资源的限制。强化学习控制器需要实时运行神经网络推理即使网络只有三层全连接在低功耗的边缘设备上每次推理仍有几毫秒到几十毫秒的耗时对实时控制是一个负担。而最大压力和自组织只需要读取车辆检测器的数据做简单算术运算任何PLC或嵌入式控制器都能轻松完成。7.2 从单路口扩展到多路口协调项目自带的六路口小型路网是一个多路口协调的实验台。多路口场景的最大挑战不是某个单路口的优化而是相邻路口之间的联动。我在跑多路口实验时发现如果每个路口独立运行最大压力算法不做任何协调路口间的信号会出现相位差漂移导致车辆在一个路口刚通过绿灯到了下一个路口刚好赶上红灯形成“一路红灯”效应。解决这个问题有两种思路一种是用强化学习训练一个集中式控制器输入是整个路网所有路口的排队状态输出所有路口的相位另一种是在最大压力算法的基础上增加上游下游的压力传播机制把下游的压力加权纳入当前路口的决策中。前者精度高但训练维度爆炸六个路口就有上百维状态后者工程实现简单压力传播的权重系数需要调节但效果好、可解释性强。如果你考虑在项目基础上做扩展建议先试第二种用一两天的调参成本换一个稳定的多路口协调策略性价比很高。7.3 仿真到实地部署的鸿沟最后想聊一个很多人忽略的问题仿真里表现优秀的算法搬到现实中并不一定能复制效果。仿真环境里检测器数据是完美的没有丢失、没有噪声现实中地感线圈和视频检测器都有检测误差视频检测还会受天气和光照影响。最大压力算法对这种误差的容忍度很高因为压力本来就是相对值少量误差不会改变排序但DQN和DDPG对状态噪声就比较敏感训练时如果状态输入没有加噪声部署后性能会明显下降。我的建议是如果你打算把强化学习模型真正部署到路口的信号机上在仿真训练阶段就要给状态向量注入高斯噪声模拟真实检测器的读数误差。这是很多仿真到部署项目之间被忽视的一环却往往是决定项目能否稳定运行的关键。这个项目留给你的扩展方向非常多无论是把算法换成更先进的PPO、SAC还是把场景换成真实的城市级路网都能在这个底座上快速起步。希望这份梳理能帮你在自己的实验里少踩几个坑把更多时间花在有价值的算法研究和工程落地上。本文还有配套的精品资源点击获取