从Docker化求解器到运动规划算法：CommonRoad TUM竞赛项目实战解析-编程实验室

简介：本资源是面向人工智能与计算机科学方向学生及研究者的TUM CommonRoad竞赛辅助方案包，聚焦自动驾驶路径规划核心任务，适用于毕业设计、课程实践及算法复现学习。压缩包共67个文件，含26个Python脚本（涵盖MCTS变体、Lattice规划、交互式场景可视化等核心算法实现）、29张结果图（含竞赛赛道可视化、路径规划效果对比图）、5份Markdown文档（含问题记录、Docker教程、接口说明及README），另有Dockerfile、环境配置文件及Shell脚本，完整支撑本地部署与实验复现。资源已通过严格测试，所有代码可直接运行，目录结构清晰，模块划分明确，便于理解规划器整体架构与各子模块协同逻辑。目前已有73人下载学习，适合需快速切入自动驾驶决策规划领域的初学者与进阶实践者。

1. 项目概述：CommonRoad TUM竞赛与Docker化求解器

如果你关注自动驾驶决策规划算法，或者正在寻找一个能让你从理论快速走向实践、并且能写进简历的硬核项目，那么CommonRoad TUM竞赛绝对是一个绕不开的宝藏。这不仅仅是一个比赛，更是一个完整的、工业级的算法验证平台。简单来说，它提供了一个高度仿真的交通场景库（CommonRoad），要求参赛者开发一个能在这些复杂、动态环境中安全、高效行驶的自动驾驶“大脑”——也就是运动规划器（Planner）。而“common road TUM竞赛.zip”这个压缩包，很可能就是某位参赛者或团队提交的完整解决方案，其中核心部分，往往就是一个封装在Docker容器里的规划算法。

为什么Docker在这里至关重要？因为竞赛方需要确保所有参赛方案能在完全一致、纯净的环境中运行和公平比较。想象一下，评委收到几十份来自全球的代码，每份依赖的库版本、系统环境都可能千差万别。没有Docker，光是配环境就能让评测崩溃。因此，将自己的规划器、连同所有依赖，打包成一个标准的Docker镜像，是参与此类竞赛的“标准动作”。这个.zip文件，就是这份“标准答卷”的载体，里面通常包含了Dockerfile、源代码、配置文件、启动脚本以及说明文档。通过拆解和学习这样一个项目，你不仅能深入理解运动规划算法的核心（如基于搜索的A*、基于采样的RRT*，或是更前沿的优化方法），更能掌握如何将算法工程化、产品化，最终部署到一个可复现、可分发的容器中。这对于想进入自动驾驶、机器人领域的开发者来说，是一次绝佳的从算法到系统的全流程实战。

2. 核心需求解析：为什么是运动规划与容器化？

要理解这个项目包的价值，我们需要拆解其背后的两大核心需求：算法有效性与工程可靠性。

2.1 算法需求：在不确定的动态环境中寻找安全路径

CommonRoad场景并非静态地图。它包含了各种挑战：突然切入的车辆、横穿马路的行人、复杂的交通灯规则、以及各种形状的障碍物。因此，规划器（Planner）的核心算法需求非常明确：

完备性与最优性权衡：规划器必须在有限时间内找到一条从起点到终点的路径（完备性），同时尽可能追求路径短、行驶平滑、符合车辆动力学（最优性）。像A这样的确定性搜索算法能保证找到最优解，但在高维状态空间（如考虑速度和朝向）中计算量爆炸。而RRT等随机采样算法能以概率完备性为代价，更快地在复杂空间中找到可行解。
动态障碍物处理：这是与静态规划最大的不同。规划器不仅要避开当前的障碍物，还要预测它们未来的运动轨迹（如使用恒定速度模型或更复杂的预测器），并在自己的规划中预留安全裕度。这常常需要引入“时空”概念，在时间维度上进行规划。
实时性要求：自动驾驶是实时系统。规划器必须在几十到几百毫秒内给出新的轨迹，以应对环境的快速变化。这意味着算法需要有极高的计算效率，或者具备增量式规划的能力。
交通规则遵守：路径不仅要物理上可行，还必须遵守交通规则，比如车道线、停车标志、右转让左转等。这需要将规则编码为代价函数或约束条件融入规划算法。

在“common road TUM竞赛.zip”中，规划器算法就是为满足这些需求而设计的核心。参赛者可能会采用混合策略，例如，使用一个快速的全局路径规划器（如Hybrid A*）生成粗略路径，再用一个局部优化器（如模型预测控制MPC）进行精细调整和动态避障。

2.2 工程需求：一键运行与公平评测的容器化方案

再精妙的算法，如果无法稳定复现，也毫无价值。这就是Docker容器化技术登场的原因。其工程需求具体体现在：

环境隔离与一致性：确保算法在评测服务器上的运行环境，与开发者在本地笔记本上测试的环境完全一致。避免“在我机器上好好的，怎么到你那就错了”的经典问题。Docker镜像固化了一切：操作系统版本、Python解释器版本、NumPy、SciPy等科学计算库的特定版本，甚至包括一些特殊的系统依赖。
依赖管理的简化：自动驾驶算法栈依赖复杂，可能涉及ROS、CUDA、特定版本的PyTorch或TensorFlow。通过Dockerfile定义构建步骤，可以自动化完成所有依赖的安装和配置，极大降低了部署门槛。
标准化接口：竞赛通常会定义一个清晰的输入输出接口。例如，规划器容器启动后，会从一个指定的文件夹读取场景文件（CommonRoad XML格式），并将规划结果（轨迹文件）输出到另一个指定文件夹。Docker容器通过挂载宿主机目录（volume）的方式，完美实现了这种数据交换。
资源控制与可扩展性：Docker可以方便地限制容器的CPU和内存使用，确保评测的公平性。同时，容器化的规划器可以很容易地被集成到更大的仿真系统或真实车辆的中控系统中。

因此，这个.zip项目包，本质上是一个算法工程化的最佳实践范例。它展示了如何将一个研究性质的算法代码，包装成一个具有工业交付标准的、开箱即用的软件组件。

3. 项目结构深度拆解：一个典型竞赛提交包

当我们解压“common road TUM竞赛.zip”后，通常会看到一个结构清晰、职责分明的目录树。下面我们来逐一拆解每个部分的作用和设计逻辑。

commonroad-tum-planner/ ├── Dockerfile # 镜像构建蓝图，核心中的核心 ├── README.md # 项目说明、构建与运行指南 ├── requirements.txt # Python依赖包列表 ├── src/ # 规划器源代码目录 │ ├── planner.py # 规划器主类，实现算法核心逻辑 │ ├── utils/ # 工具函数（几何计算、日志、配置解析等） │ └── ... # 其他模块（预测、优化、可视化等） ├── scripts/ # 辅助脚本目录 │ ├── run.sh # 容器内部启动规划器的入口脚本 │ └── evaluate_local.sh # 本地评测脚本（非必须，但很实用） ├── config/ # 配置文件目录 │ └── planner_config.yaml # 算法参数配置文件（如采样次数、权重等） └── resources/ # 资源文件（如预训练模型、地图数据等）

Dockerfile：构建过程的灵魂这个文件定义了如何从零开始构建运行环境。一个典型的Dockerfile会遵循多层构建原则以减小最终镜像体积：

# 第一阶段：构建环境 FROM python:3.8-slim AS builder WORKDIR /app COPY requirements.txt . RUN pip install --user --no-cache-dir -r requirements.txt # 第二阶段：运行环境 FROM python:3.8-slim WORKDIR /app # 从构建阶段拷贝已安装的Python包 COPY --from=builder /root/.local /root/.local # 确保脚本可执行，并设置Python路径 ENV PATH=/root/.local/bin:$PATH # 拷贝源代码和配置文件 COPY src ./src COPY scripts ./scripts COPY config ./config # 声明容器启动时执行的命令 ENTRYPOINT ["./scripts/run.sh"]

注意：使用python:3.8-slim而非完整版，可以显著减少镜像大小（从近1GB缩减到约150MB），加快下载和加载速度。这是生产环境的最佳实践。

src/planner.py：算法核心的实现这是整个项目的“大脑”。它必须实现竞赛规定的规划器接口。通常，这个类会继承一个基类，并实现一个名为plan的核心方法。

import numpy as np from commonroad_dc.pycrccosy import CurvilinearCoordinateSystem from commonroad_planning.utility.visualization import visualize_solution class MyCompetitionPlanner: def __init__(self, config_path: str): # 加载配置文件，初始化算法参数 self.config = self._load_config(config_path) self._logger = setup_logger() # 可能初始化一些内部组件，如预测模块、优化器 self._predictor = SimpleConstantVelocityPredictor() self._optimizer = MPTOptimizer(self.config.optimizer) def plan(self, scenario, planning_problem): """ 核心规划函数。 :param scenario: CommonRoad场景对象，包含所有静态和动态障碍物 :param planning_problem: 规划问题对象，包含起点、终点、目标区域等 :return: 规划出的轨迹（Trajectory对象）或None（规划失败） """ self._logger.info("开始规划...") # 1. 预处理：提取道路中心线，转换到曲线坐标系 ref_path = self._generate_reference_path(scenario, planning_problem) clcs = CurvilinearCoordinateSystem(ref_path) # 2. 预测动态障碍物未来轨迹 dynamic_obstacles = scenario.dynamic_obstacles predictions = self._predictor.predict(dynamic_obstacles, time_horizon=5.0) # 3. 在主循环中进行时空规划 # 这里可能是A*搜索、RRT*采样或优化求解 trajectory = self._run_spatiotemporal_planning(clcs, predictions, planning_problem) # 4. 后处理：确保轨迹平滑且符合车辆动力学 if trajectory is not None: smoothed_trajectory = self._optimizer.smooth(trajectory) if self._check_collision(smoothed_trajectory, scenario): self._logger.warning("平滑后轨迹发生碰撞，返回原始轨迹。") return trajectory return smoothed_trajectory return None def _run_spatiotemporal_planning(self, clcs, predictions, planning_problem): # 这里是算法真正的核心，实现因方案而异 # 示例：采用Hybrid A*在时空状态空间搜索 pass

实操心得：在plan方法内部，一定要做好异常捕获和日志记录。因为评测系统会使用大量极端场景测试你的规划器，一个未处理的异常可能导致整个容器崩溃，从而在该场景上得零分。稳健性有时比算法尖端性更重要。

scripts/run.sh：容器的启动入口这个脚本是容器内部的“指挥官”。它负责解析外部传入的参数（如场景文件路径），调用主程序，并处理结果。

#!/bin/bash # 容器入口点脚本 # 设置环境变量，确保Python能找到我们的模块 export PYTHONPATH=/app/src:$PYTHONPATH # 通常竞赛框架会通过环境变量或命令行参数传入场景文件路径 SCENARIO_FILE=${1:-"/input/scenario.xml"} OUTPUT_FILE=${2:-"/output/trajectory.txt"} echo "开始处理场景: $SCENARIO_FILE" # 调用Python规划器 python3 -m src.planner_main --scenario "$SCENARIO_FILE" --output "$OUTPUT_FILE" # 检查输出文件是否存在，作为规划成功与否的简单标志 if [ -f "$OUTPUT_FILE" ]; then echo "规划成功，结果已保存至: $OUTPUT_FILE" exit 0 # 返回0表示成功 else echo "规划失败，未生成轨迹文件。" exit 1 # 返回非0表示失败 fi

4. 规划器算法核心实现详解

在CommonRoad这样的动态密集环境中，一个鲁棒的规划器通常不是单一算法，而是一个分层或分阶段的流水线。下面我们深入一个典型的实现方案。

4.1 参考路径生成与坐标转换

直接在全局笛卡尔坐标系下规划，对于复杂道路结构非常困难。首先需要生成一条粗略的、无碰撞的参考路径（通常沿车道中心线），然后构建一个曲线坐标系（Curvilinear Coordinate System）。

def _generate_reference_path(self, scenario, planning_problem): """使用A*算法在车道中心线图上搜索参考路径""" lanelet_network = scenario.lanelet_network start_lanelet_id = self._find_start_lanelet(planning_problem.initial_state) goal_lanelet_id = self._find_goal_lanelet(planning_problem.goal) # 使用图搜索算法（如A*）在车道线网络中寻找路径 path_lanelet_ids = a_star_search(lanelet_network, start_lanelet_id, goal_lanelet_id) # 将一系列车道线的中心点连接起来，形成参考路径 reference_path = [] for lid in path_lanelet_ids: centerline = lanelet_network.find_lanelet_by_id(lid).center_vertices reference_path.extend(centerline) return np.array(reference_path)

生成参考路径后，利用CommonRoad提供的CurvilinearCoordinateSystem，可以将任意一个全局坐标(x, y)转换到曲线坐标系下的(s, d)，其中s是沿参考路径的纵向距离，d是横向偏移。这个转换至关重要，它将复杂的二维平面规划问题，初步简化为沿“道路”方向的纵向规划和横向偏移控制。

4.2 时空状态图搜索（Hybrid A*）

对于车辆这类有动力学约束的物体，简单的位置点搜索不够。Hybrid A* 是一种在连续状态空间（x, y, θ）中进行图搜索的算法，它考虑了车辆的前向运动学和转向角度限制。

在动态环境中，我们需要将时间作为第四维，扩展为时空状态（x, y, θ, t）。每个节点代表在特定时间点的车辆状态。动作空间是离散的控制输入（如速度、前轮转角）。在扩展每个节点时，必须检查其生成的轨迹片段在对应的时空区域内是否与预测的障碍物轨迹发生碰撞。

def _hybrid_a_star_spatiotemporal(self, start_state, goal_region, predictions, clcs): """ 在时空状态空间进行Hybrid A*搜索。 """ open_set = PriorityQueue() start_node = Node(state=start_state, g_cost=0, time=0) open_set.put(start_node) while not open_set.empty(): current_node = open_set.get() # 检查是否到达目标区域（考虑时间容差） if self._is_in_goal_region(current_node.state, goal_region, current_node.time): return self._reconstruct_path(current_node) # 离散动作空间：几种速度和转向组合 for delta_v in [-1, 0, 1]: # 加速度：减速、匀速、加速 for delta_steer in [-0.3, 0, 0.3]: # 转向角变化 # 使用简化的车辆运动模型（如自行车模型）模拟下一状态 next_state, trajectory_segment = vehicle_model(current_node.state, delta_v, delta_steer, dt=0.1) next_time = current_node.time + dt # **关键步骤：时空碰撞检测** if self._check_collision_spatiotemporal(trajectory_segment, predictions, current_node.time, next_time): continue # 发生碰撞，丢弃该节点 # 计算代价：距离代价 + 时间代价 + 舒适度代价（加速度、加加速度） cost = self._calculate_cost(trajectory_segment, goal_region) new_g_cost = current_node.g_cost + cost heuristic_cost = self._heuristic(next_state, goal_region) # 启发函数，如到目标的欧氏距离 new_node = Node(state=next_state, parent=current_node, g_cost=new_g_cost, time=next_time) if not self._is_node_visited(new_node): open_set.put(new_node, new_g_cost + heuristic_cost) return None # 搜索失败

注意事项：时空碰撞检测是性能瓶颈。需要将障碍物的预测轨迹也离散化为时空体（Space-Time Volume），并使用高效的数据结构（如时空哈希表）进行快速查询。粗暴的逐时间点遍历会严重拖慢搜索速度。

4.3 轨迹优化与平滑

Hybrid A* 搜索出的路径可能比较粗糙，存在急转或速度突变。因此，需要后续的优化平滑步骤。模型预测控制（MPC）或样条优化是常用方法。

一个简单的做法是，将搜索得到的路径点作为初始猜测，构建一个优化问题：

目标函数：最小化轨迹的加速度、加加速度（舒适度），同时最小化与参考路径的横向偏差。
约束条件：
1. 动力学约束：轨迹必须符合车辆运动学模型。
2. 碰撞约束：优化后的轨迹在任何时间点都不能与障碍物相交。
3. 边界约束：车辆不能驶出道路边界。

使用如Ceres Solver或IPOPT这样的非线性优化库来求解这个问题，可以得到一条平滑、动态可行的轨迹。

def _optimize_trajectory(self, raw_path, predictions): """使用样条和优化器平滑轨迹""" # 1. 将原始路径点参数化（例如，用时间作为参数） times = np.linspace(0, len(raw_path)*0.1, len(raw_path)) # 假设每点间隔0.1秒 x_points = [s.x for s in raw_path] y_points = [s.y for s in raw_path] # 2. 拟合平滑样条曲线 x_spline = CubicSpline(times, x_points) y_spline = CubicSpline(times, y_points) # 3. 定义优化问题，调整样条控制点以最小化加速度和碰撞风险 # 这里是一个简化示例，实际使用优化库 def cost_function(control_points): # 根据控制点生成新样条 new_trajectory = generate_trajectory_from_spline(control_points) # 计算成本：平滑度成本 + 碰撞成本 smooth_cost = calculate_jerk(new_trajectory) collision_cost = calculate_collision_risk(new_trajectory, predictions) return smooth_cost + 10.0 * collision_cost # 碰撞成本权重更高 # 使用优化器（如scipy.optimize.minimize）求解 optimized_controls = minimize(cost_function, initial_guess).x return generate_trajectory_from_spline(optimized_controls)

5. Docker镜像的构建、运行与调试全流程

有了代码，下一步就是让它通过Docker在任何地方都能跑起来。这是从“代码”到“产品”的关键一步。

5.1 镜像构建与优化技巧

在项目根目录执行构建命令：

docker build -t my_commonroad_planner:latest .

这个过程会读取Dockerfile，逐层构建镜像。为了提升效率，请注意：

利用构建缓存：Dockerfile中指令的顺序影响缓存。将变化最少的层（如安装系统依赖）放在前面，将变化频繁的层（如拷贝源代码）放在最后。
使用 .dockerignore 文件：在项目根目录创建.dockerignore文件，排除不需要拷贝进镜像的文件（如__pycache__/,*.log,*.pyc,README.md, 测试数据等），可以显著减少构建上下文大小，加速构建过程。
多阶段构建：如前文Dockerfile示例所示，多阶段构建可以分离编译环境和运行环境，最终只将运行所需的文件拷贝到一个小体积的基础镜像中，使生产镜像非常精简。

5.2 本地运行与场景测试

构建成功后，可以在本地使用Docker运行规划器，测试单个场景。

# 准备输入输出目录 mkdir -p ./test_input ./test_output # 将一个CommonRoad场景XML文件放入test_input cp some_scenario.xml ./test_input/ # 运行容器，将本地目录挂载到容器内的 /input 和 /output docker run --rm \ -v $(pwd)/test_input:/input:ro \ -v $(pwd)/test_output:/output \ my_commonroad_planner:latest \ /input/some_scenario.xml \ /output/trajectory.xml

参数解释：

--rm：容器退出后自动删除，避免积累大量停止的容器。
-v $(pwd)/test_input:/input:ro：将宿主机的test_input目录以只读方式挂载到容器的/input目录。ro是关键，防止容器内程序意外修改你的原文件。
-v $(pwd)/test_output:/output：将宿主机的test_output目录挂载到容器的/output目录，用于保存结果。

运行后，检查test_output目录下是否生成了轨迹文件。你可以使用CommonRoad提供的可视化工具来查看规划结果：

from commonroad.visualization.mp_renderer import MPRenderer import matplotlib.pyplot as plt scenario = CommonRoadFileReader(‘test_input/some_scenario.xml‘).open() trajectory = CommonRoadFileReader(‘test_output/trajectory.xml‘).open() plt.figure() renderer = MPRenderer() scenario.draw(renderer) trajectory.draw(renderer) renderer.render() plt.show()

5.3 调试与日志收集

在容器内调试代码比本地复杂。以下是几种有效方法：

交互式进入容器：

docker run -it --rm \ -v $(pwd)/src:/app/src \ # 挂载源代码，方便修改 -v $(pwd)/test_input:/input:ro \ -v $(pwd)/test_output:/output \ --entrypoint /bin/bash \ # 覆盖原入口点，启动bash shell my_commonroad_planner:latest

进入容器后，你可以手动运行python -m src.planner_main ...，或者使用pdb进行调试。

日志持久化：确保你的规划器将日志不仅打印到标准输出（stdout），也写入文件。并将日志文件目录也挂载到宿主机。

docker run --rm \ -v $(pwd)/test_input:/input:ro \ -v $(pwd)/test_output:/output \ -v $(pwd)/logs:/app/logs \ # 挂载日志目录 my_commonroad_planner:latest

在代码中，配置日志同时输出到文件和stdout：

import logging logging.basicConfig( level=logging.INFO, format='%(asctime)s - %(name)s - %(levelname)s - %(message)s', handlers=[ logging.FileHandler('/app/logs/planner.log'), logging.StreamHandler() # 输出到控制台，docker logs能捕获 ] )

使用Docker日志命令：运行容器后，在另一个终端用docker logs -f <container_id>可以实时跟踪标准输出，这对排查启动问题非常有用。

6. 性能优化与高级技巧

要让规划器在竞赛中脱颖而出，除了算法正确，性能和鲁棒性至关重要。

6.1 算法层面的优化

启发函数设计：Hybrid A* 的性能极度依赖启发函数。一个好的启发函数能极大减少搜索节点数。除了欧氏距离，可以考虑在曲线坐标系下计算纵向距离s作为启发值，更贴近实际可行驶距离。
运动基元（Motion Primitives）预计算：对于固定车辆模型，可以预先计算好一组从零状态出发、在不同控制输入下、经过固定时间间隔后的状态转移（即运动基元）。在线搜索时，直接查询和应用这些基元，避免重复进行运动学积分计算，能大幅提升速度。
碰撞检测加速：
- 代理模型（Bounding Box）：用简单的矩形或圆形包络复杂的车辆形状进行快速粗检测，只有粗检测通过才进行精确的几何碰撞检测。
- 时空哈希：将整个时空区域划分为网格。每个障碍物的预测轨迹占据一系列网格。规划时，只需检查轨迹点所在的网格是否有障碍物，将O(n)的复杂度降至近似O(1)。
并行化：如果规划算法中有可以独立进行的部分（如多个候选路径的评估、多个障碍物预测的碰撞检查），可以利用Python的multiprocessing库进行并行计算。注意，Docker容器默认可以使用宿主机的所有CPU核心。

6.2 工程与配置优化

参数调优与配置文件：所有算法参数（如搜索步长、代价权重、采样数量）不应硬编码在代码中，而应放在config/planner_config.yaml这样的配置文件里。这允许你为不同类型的场景（高速公路、城市交叉口）快速切换不同的参数组，甚至可以在运行时根据场景复杂度动态加载配置。
```
# planner_config.yaml search: step_size: 0.5 max_iterations: 5000 heuristic_weight: 1.2 cost: weight_collision: 1000.0 weight_comfort: 1.0 weight_deviation: 0.5 vehicle: wheelbase: 2.65 max_steering_angle: 0.6
```
资源限制与监控：在Docker运行时，可以使用--cpus和--memory参数限制容器资源，模拟评测环境。
```
docker run --rm --cpus="2" --memory="2g" ... my_commonroad_planner ...
```
在代码中，可以集成资源监控，在日志中记录峰值内存和CPU使用率，帮助发现内存泄漏或性能热点。
优雅降级策略：不是所有场景都能规划出完美轨迹。必须设计降级策略。例如：
- 如果主规划器（如时空A*）超时，则切换到一个更快的、但能力较弱的备用规划器（如仅做纵向速度规划的Frenet方法）。
- 如果所有规划都失败，则执行一个安全的紧急停车轨迹。
- 在输出轨迹前，增加一道最终的安全检查，如果发现碰撞，则返回上一周期可行的轨迹或停车指令。

7. 常见问题排查与实战心得

在实际开发和提交过程中，你会遇到各种各样的问题。下面是一些典型问题及其解决方案。

7.1 Docker相关问题

问题1：镜像构建缓慢，特别是卡在pip install步骤。

原因：默认的PyPI源在国内访问可能很慢。

解决：在Dockerfile中使用国内镜像源加速。

RUN pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple && \ pip install --user --no-cache-dir -r requirements.txt

--no-cache-dir选项可以避免pip缓存，稍微减小镜像体积。

问题2：容器运行时报错“找不到模块”或“无法导入”。

原因：最常见的是PYTHONPATH环境变量未设置正确，或者依赖包确实未安装。
解决：
1. 在Dockerfile中明确设置ENV PYTHONPATH=/app/src:$PYTHONPATH。
2. 在run.sh入口脚本中也设置一次。
3. 仔细检查requirements.txt文件，确保所有依赖包名称和版本正确。可以使用pip freeze > requirements.txt命令在稳定的开发环境中生成准确的依赖列表。

问题3：在容器内无法写入输出目录。

原因：容器内进程的用户（默认是root）对挂载的宿主机目录没有写权限。
解决：
1. （推荐）在宿主机上提前创建好输出目录，并赋予宽松的权限（chmod 777 test_output），但这有安全风险，仅用于测试。
2. 在Dockerfile中创建一个非root用户，并用该用户运行进程。
```
RUN useradd -m -u 1000 planneruser USER planneruser WORKDIR /app COPY --chown=planneruser:planneruser . .
```

7.2 算法与逻辑问题

问题4：规划器在简单场景工作正常，但在复杂动态场景下超时。

原因：搜索空间爆炸或碰撞检测效率太低。
排查与解决：
1. 增加日志：在规划循环中记录迭代次数、开放集大小、碰撞检测调用次数和时间。
2. 性能分析：在本地运行（不使用Docker）时，使用Python的cProfile模块找出最耗时的函数。
```
python -m cProfile -o profile_stats.prof src/planner_main.py --scenario complex_scenario.xml
```
  然后用snakeviz等工具可视化分析结果。
3. 针对性优化：如果碰撞检测是瓶颈，就优化碰撞检测（如引入代理模型和时空哈希）。如果搜索节点太多，就优化启发函数或增加剪枝策略。

问题5：生成的轨迹在可视化时发生“抖动”或突然转向。

原因：可能是搜索的步长太大，或者优化器求解不稳定。
解决：
1. 减小运动基元或搜索的步长（时间步长和空间步长），但会增加计算量。
2. 检查优化问题的约束条件是否合理，特别是动力学约束是否太紧或太松。尝试调整优化器的收敛容忍度和最大迭代次数。
3. 在优化后，对轨迹进行额外的平滑滤波，如使用Savitzky-Golay滤波器。

问题6：在评测中，某些场景得分为零，但本地测试似乎没问题。

原因：这是最棘手的问题，通常是环境差异或边界条件导致。
排查清单：
1. 绝对路径与相对路径：确保代码中所有文件读取操作都基于传入的参数路径，而不是硬编码的绝对路径。
2. 随机种子：如果你的算法有随机采样（如RRT*），确保设置了固定的随机种子（如np.random.seed(42)），以保证结果可复现。评测系统可能多次运行取平均。
3. 时间限制：检查评测系统是否有严格的单场景运行时间限制（如2秒）。你的规划器可能在某些场景超时。在本地使用timeout命令模拟测试。
4. 完整性与错误处理：确保plan函数在任何情况下（包括异常）都返回一个合法的轨迹对象或None，而不是抛出未处理的异常。用try...except包裹核心逻辑，并在异常时返回一个安全轨迹（如减速停车）。