追赶天门山的云——复旦大学CodeWisdom 战队世界 AI 竞速锦标赛纪实

点击蓝字

关注我们

复旦大学软件工程实验室 

CodeWisdom智能汽车战队

🏁 HITCH OPEN

00

前言

在复旦的秋天，风不会轻易说话，但它会把某些消息送得很远——我们要带着一套在电脑里跑得完美的自动驾驶系统，驶向张家界天门山的真实赛道。这是 HitchOpen 世界 AI 竞速锦标赛 的决赛：10.77 公里、99 道弯、三条隧道，从仿真到实车，一切都重新开始。

湖南省张家界市天门山99道弯赛道

我们是软件工程的实践者，却要在山里解决信号漂移、雷达反射、雨雾干扰、电路受潮这些“物理世界的 Bug”。当 GNSS 从厘米级精度跌落到米级、当惯导失准、当雷达被雾气蒙住眼，我们才明白——真正的挑战，不是让算法更聪明，而是让系统在不完美中继续呼吸。

这篇纪实记录的是一次“学习”的旅程：从仿真器的确定性，走进山的随机性；从键盘敲击，到扳手的金属声；从追求完美，到学会与不确定共处。这是一次从仿真到现实的跋涉，是技术细节与人物经验交错的纪实，也是一段年轻团队学习“被现实打磨”的长篇见证。

01

起程：仿真到现实的触碰

9月的早晨漂浮着暑气和秋意。江湾校区的梧桐叶尚未变黄，路灯下的水珠受着风的鼓动。一辆货车把PIX HOOKE2.0底盘缓缓放下到我们实验室的车库里。底盘下放的动作被细心安排成一种仪式：几位师兄赤手空拳，配着小心翼翼的手势，将一件复杂的工程系统从运输车厢“唤醒”到地面。

PIX HOOKE 2.0底盘到达校园

对我们的团队成员来说，那一声“咔哒”比任何一个版本号的发布还要响亮。长期生活在仿真器窗口的我们，突然被现实的金属质感和机械拥抱——那不是代码输出的冷静，而是物理世界的厚重。有人把手放在车身上，像给机体做一个早安的问候；有人把手伸进底盘的缝隙，摸到的是刚做完防锈处理的冷漠金属和几片印着条码的电缆。

实验室里一片忙乱：有人把配件手册展开有人在电脑上急切地拉出用户手册，有人翻看着CAN协议的文档，有人对着遥控器的英文说明展开讨论。我们把那一刻拍成了许多照片，嘴里却没几个能说出“激动”的字眼——可能是因为工程师的情绪更偏向确认：每一根线、每一条协议、每一个电源都要被核对。然而谁也掩饰不住那种初见实车时的兴奋感：软件工程师第一次闻到轮胎的橡胶味，像是听到代码之外的外部中断。

当晚我们聚在车库的白板边，像在准备一次专业的学术会议。白板上写着六个模块：Perception、Sensing、Localization、Planning、Control、Driver。每个模块下面都插着若干任务卡片：雷达驱动、点云过滤、FusionEngine解析、ENU坐标管理、global_path导入、CAN信号编码。我们在白板上画出数据流和话题（topics），像在绘制一张管线图：从传感器到控制器，从控制器到执行器，每一步都有延迟、噪声和潜在的失灵点。

那一晚，师兄们反复讲述底盘的保养与操作注意事项：如何安全接电、如何避免CAN总线短路、在现场如何触发底盘的紧急停止。我们的导师叮嘱我们：“这不是仿真器，车会反抗你的假设，带着敬畏去沟通它。”那句简单的话在我们耳中像警钟：敬畏现实，尊重每一个物理边界。

我们随即建立了GitHub仓库 HitchOpen-Final-FDU，把这辆车当作一个新的“分支”。头几天，团队分成若干小组：有的写雷达驱动，有的搭建ROS2消息桥，有的撰写CAN映射，还有的同学开始在Carmaker里搭建天门山的仿真模型。那个模型在屏幕上像一条银蛇，弯曲盘绕，带着斜坡和每一处护栏。

基于Python可视化的仿真路径分析

仿真里的道路是可预见、可控制的；现实则不是。正当我们把精力投入到仿真与代码布局中时，没有人能预料到，这种对“可控”的信心，会在将来的几周里被几次无法预见的变量切割成学习的碎片。

02

从屏幕到车轮：重构一个“会跑到系统”

在校园里，我们习惯于把一切问题拆成小问题，然后用模块化的方法逐个击破。搭建这个“会跑的系统”恰是如此：我们的设计体现了软件工程师对复杂性的本能经验——划分边界、定义接口、建立测试用例。

代码仓一开始就有严格的目录结构和CI（持续集成）脚本。每一次 commit 都触发单元测试、静态检查。有人戏称我们是“把实验室的严谨带到了草地上”，但事实上，这种严谨正是把我们从“做实验”推向“能实战”的唯一通路。

实验室内的系统构建过程

Perception （感知）队员的工作从接入 Seyond W60 激光雷达到写一整套点云预处理管线：先做畸变补偿，再做高度滤波与噪声剔除，最后将点云投影到XOY平面作聚类。我们写的边界检测算法基于几何与统计结合：用栈式的空间分割（voxel grid）降低点云密度，再应用基于RANSAC的局部线性拟合求出最可能的道路边界。为了实时性，我们对算法做了大量工程优化——把一些计算提前做成缓存，把聚类算法改成近邻搜索的增量版本，从而保证在NVIDIA Jetson Orin/Thor 上也能以大于 10Hz 的频率运行。

Sensing 和 Localization （传感定位）队员的挑战更多是工程而非数学。我们需要解析 PON Atlas Duo 的 FusionEngine 协议包，它通过 UDP 发来一串二进制数据，里面嵌着GNSS、IMU、RTK以及状态字。我们定义了一套自有的ROS2消息类型，把这些生硬的数据包翻译成更友好的话题（ROS2 topics）：/sensing/enu、/sensing/rtk_status、/sensing/imu。最初我们还纠结于一个设计抉择：ENU 坐标原点是固定（例如某一 GPS 经纬度）还是动态（每次启动时以惯导的初始位置作为原点）？我们最终选择了动态原点，因为在实验室里更灵活，更容易避免不同车辆与不同会话之间的坐标对齐问题。不过也有人担忧：动态原点会在不同实验间引入不一致。团队辩论后，我们写了完整的转换器，并在日志中记录每次启动时的原点经纬度与时间戳，便于赛后回溯。

Planning 与 Control （规划控制）是我们的自信的部分，因为我们有大量的仿真经验。我们采用了分层规划：先用全局路径文件（global_path）确定一条“竞速优先”的理想路线，再基于实时雷达点云做局部路径（local_path）修正。纵向与横向控制采用的是 PID 与模型预测控制（MPC）的混合方案：横向以纯追踪（Pure Pursuit）为核心，加上一个对曲率敏感的前瞻距离调度；纵向用一个简化的动力学模型做速度规划，来避免在下坡段过度制动或在平面路段失速。

Driver （驱动）模块把高层的速度与转向命令映射为真实世界的 CAN 信号。这里的重难点在于把 ROS2 的 float 信息安全地序列化并写进 CAN 帧，要考虑到报文的周期性、校验和意外超出范围的保护策略。我们编写了一套“安全网”：当指令超出某些阈值，Driver 会先把命令降频并触发预警，否则会以“最低安全参数”让车停在最安全位置。

在仿真中，这套系统表现近乎完美：我们在 Carmaker 中复现了天门山的弯道曲率，车辆能稳定以 6 m/s 做急转弯，控制轨迹和我们设想的误差范围内重合。同时，这套松耦合的系统使得我们能预留足够多的模块化接口，以扩展我们的智驾竞速仓库。

但有一样东西我们没怎么测试过：山上的GNSS遮挡与多路径效应。在校园里，卫星信号很好，RTK 做起来仿佛只需叫一声“确定”；在山间，这一切不再简单。

03

第一次呼吸：算法从仿真中苏醒

紧锣密鼓的前期开发初步完成，当 Seyond W60 的第一帧点云在 RViz 中绽开，我们像围观烟花那样鼓掌。那帧点云记录下了实验室外那条并不惊艳的柏油路，但对我们而言，它像极了一本新生的便签本：每一颗点都代表着与现实世界的第一次接触。我们花了几天时间为它写“注释”——贴标签、标志障碍、标注道路边界，建立起从原始点云到行动决策的映射。

边界检测的点云数据可视化

边界检测的实现细节值得一提：我们先用一个自定义的 voxel grid 把高程上相近的点聚合，降低计算量。之后在每一列（径向方向）做投影，求取最可能的路沿曲线。为避免被路面上方的树叶或过路人的点云污染，我们对 z 轴应用了多层滤波——把可能的悬浮点剔除。然后我们使用一种带权的 DBSCAN 聚类，结合史诗级的鲁棒拟合（RANSAC + 二次曲线拟合）来获得道路边界线段。该方法在多数弯道场景下表现良好，能识别出曲率突变点（如护栏末端或突出的路沿），这些点会触发减速与轨迹重规划。

定位这一块的“戏剧性”很早就埋下伏笔。PON Atlas Duo 惯导设备在实验室里给出的全局定位数据精确到厘米，这让我们一度沉迷于“全局定位为主”的设计哲学：只要位置对了，规划就能做到最优。但我们在本地封闭场地拿到的“光滑而可靠”的轨迹数据，并不能代表天门山那种复杂的电磁环境与卫星视角遮挡。在仿真里，IMU 的噪声、GNSS 的丢包是被可控随机数模拟出来的（甚至被忽略）；在真实世界，这些噪声是有脾性的，它们会根据地形、天气及施工信号变化而生气或休眠。

仿真和校园的测试很好地证明了规划与控制在理想输入下的能力，我们在仿真里做了大量参数敏感性分析，生成了参数矩阵与热图，并把这些作为初始参数投放到实车。

校内道路与车控测试

那时的我们仍抱持一种工程师式的浪漫：如果控制器够优秀，世界会按我们设想的轨道运动。在仿真复赛中，我们对于可靠来源数据的精准分析和软件控制，为我们斩获了冠军，因此我们对于这种方法论深信不疑。我们相互鼓励、互相调侃，把重要的 commit 都命名成“mountain-ready”、“tunnel-safe”这种像是仪式感的标签。我们把大量心血倾注在代码覆盖率、日志完整性和可追溯性上。仿真为我们建立了信心，但它也在悄悄蒸发着我们对“传感器失效”的敬畏。

04

出发：秋雨中的意外

在任何一次长途出征前，团队都会有一种临战的气氛：行李打包、设备核对、最后一次集体审查。10月7日是我们在上海的最后一夜，像外科手术室那样有条不紊。我们决定做一次全系统的速度测试，想看看在最激进的参数下，底盘到底还有多少余量。

当车辆在最后一次 7 m/s 的弯道测试中右后轮撞上矮路沿，我们都愣住了。那一声闷响像是现实给我们的一记回马枪——提醒我们，车在真实的世界里有质量、惯性和脆弱性。检查的结果不乐观：右后轮的“羊角”出现形变，导致轮胎倾斜。那个部件看上去不像是能在短时间内做完修复的“轻伤”，而是一条必须更换的关键件。

对于一个比赛团队而言，设备在出发前受损是最糟糕的事情之一：时间是不可逆的，零件的运输成本是不菲的。我们立刻决定把底盘带上货车，把损坏的部件一起运往天门山的服务点去修理。那一晚，一部分人留在车库做修复准备，另一部分人收拾设备，准备随车前往湖南。

在这样的时刻，团队的情绪很复杂。有人烦闷，有人焦虑，但更多是自我调侃式的乐观：“幸好不是发动机坏了，发动机坏了我们就真的‘跑’不了了。” 话虽如此，大家都明白这次出行已经不再是一次简单的“带着代码去旅行”，而是一次在极限条件下的工程实践。我们要把实验室的方法论带上山，但更重要的是学会在突发情况下保持冷静，优先保证整体运作的连贯性。

那天我们把底盘安放在货车上，轮胎的橡胶味在封闭的车厢里混合成一种奇异的安稳。

竞赛底盘准备发往天门山

05

试剑天门山：雾中的起点

对于赛车底盘而言，天门山的第一印象不是雄伟，而是粘连的湿度。我们团队到达张家界时已是深夜，薄雾层层覆盖在城市上空。车队穿过城市，逐渐沿着山路蜿蜒而上，车窗外的景色从人造的霓虹变成了野生的黑。越往上走，云越厚，像一层白色的被单，把山、路和车都裹住。

PIX HOOKE 2.0初见天门山

第二天早上，我们第一次真正站在“99道弯”的山头上。弯道在雾中若隐若现，像被时间压折的丝带。路旁是陡峭的岩壁、偶尔裸露的灰色石面，空气里有泥土与青苔的气味，那是初秋微凉的问候语。

比赛场地布置在“曲径通天”的路线上：从山顶的“云霄车库”出发，一路向下，最后抵达山脚的终点。它比任何一个我们在仿真里构建的赛道都要复杂：长达 10.77 公里、99 个弯道，其中不少弯道的半径极小，坡度陡，且在某些路段上方悬崖峭壁直接压在车辆之上。3 个隧道穿插其间，隧道内没有 GNSS 信号，只能靠惯导与激光感知支持短暂的定位。

天门山99道弯赛道

车库里各队都在进行最后的准备。我们看到湖南大学战队的车辆已经全副武装，武汉理工大学的同学们坐在车旁严谨地思考，场面里透着一种竞技的互助感。比赛的气场不像职业赛那么冷酷，更多是一种学术会议式的热烈与互助——大家都知道，若能让整个比赛在极端条件下顺利进行，那么对每一方都是学习与实践的加分。

云霄车库战队旗帜

我记得第一天的雷达路测——我们把 Seyond W60 的数据打包成 ROS bag，沿山路跑了一个完整的回合。点云在山体之间翻滚，树影和护栏折射出复杂的阴影。那次测验的结果让我们既兴奋又担忧：雷达感知在大多数开阔弯道表现很好，但当路两侧被高大岩壁遮挡时，点云出现稀疏与异常反射。更让人吃惊的是，PON Atlas Duo 的惯导在某些路段开始出现米级漂移——这种漂移在我们校园实验里从未见过。最初我们还安慰自己：或许是天线摆放或标定问题。可当海南大学也反映类似现象，我们不得不面对现实：山中的 GNSS 信号本身就可能因为地形、信息安全因素与机场电磁干扰而随机发生退化。

赛道雷达数据采集

那一刻，理想的“全局定位为主”策略被现实的随机性划出一条红线。我们感受到从信任到怀疑的过程，像是在向一个旧朋友突然发现他有好几个陌生身份那样痛快又不安。团队里的讨论变得更频繁，也更焦虑：我们需要更多设备，需要重写某些模块，需要迅速找一个替代方案。正是在那几天，我们第一次真真切切意识到“仿真世界的稳定”并不能自动地映射到“山地环境的复杂”。

06

信号迷雾：从厘米到米的坠落

定位模块在我们整个系统中扮演的是类似钟表机芯的角色：微小的误差能在几分钟内放大，最后导致输出变得十万八千里之外的荒诞。当 PON Atlas Duo 惯导设备在校园能带来厘米级精度时，我们曾把它当成一种接近完美的“外部真理”。在天门山，我们才发现这种真理有多脆弱。

第一次看到惯导数据产生米级偏差是在一次普通的下坡路段。当时我们的RViz里显示的车位突然像溜冰一样滑走了几米。控制层还在按先前计算的轨迹输出转向与速度，车却在视觉上明显偏离应有的车道边缘。那一刻仿佛时间被延长，车内的心跳都跟着数据刷新频率在跳动。我们暂停了测试，把记录下来的bag包回放、放慢、对比。后来才发现：在某些弯道上方，大量的岩壁导致了卫星信号的遮挡，多路径反射变得极为严重，卫星解算器给出的伪距观测在短时间里出现剧烈跳变；当车辆靠近护栏、倾斜角度发生微小变化时，天线姿态的相对变化进一步放大了观测误差；当游客高峰期出现时，附近电子设备、人群和临时信号源也会对 GNSS 信号造成不可预测的干扰。

惯导设备的“定位漂移”现象

这些因素结合在一起，使得我们从“厘米级信任”坠落到“米级怀疑”。每出现一次这样的漂移，我们就不得不重新跑一次标定、重写一次坐标转换逻辑、或暂时依靠雷达的局部边界修正来补救。好在海南大学给我们借了他们多余的一台华测 CHC430 惯导设备，CHC430 在多次测试后表现更稳定一点，但也并非铁板一块：它的输出有更好的短期稳定性，但在长期漂移上的表现依然受制于惯导初值和GNSS的突发抖动。

这种漂移带来的直接后果非常现实：局部规划模块依赖于当前的位置信息来生成路径。如果位置信息错了几米，局部路径会被错误地映射到护栏外侧或对向车道，控制器就会输出让人类司机几乎不会做出的极端修正。我们在一天的测试里遇到过好几次这样的情况：控制器为了“追踪”一个错误的local_path，输出一个在现实中会让车轮突破摩擦上限的转向角。幸好我们设计了Driver层面的“安全限幅”，避免了实际的事故。

在车库的那些夜晚，我们不得不围绕定位模块做“火速复盘”。有人负责和设备厂商沟通，试图解析 CHC430 和 PON 在底层解算逻辑上的差异；有人回归坐标系转换的数学推导，验证一行行代码是否在某处做了 sign 错误或单位换算错误；还有人重写了定位的健康度评估策略，引入了一个实时“置信度”指标，让规划层在低置信度时自动触发“保守模式”——降低速度、扩大安全边界、并增加对雷达边界认定的依赖。

深夜与凌晨的代码调试

那段时间，我们像一群打捞信号的潜水员，时时准备把错误拉回到水面。每当我们找到并修复一个bug，夜里都会有人去楼下买两杯茶颜悦色，然后在酒店里吃泡面庆祝。工程师的快乐往往很小，但真实：看到rviz中位姿箭头偶尔恢复平滑的时候，比任何颁奖都能让人笑出声来。

07

调试三日：在山风里重写系统

当车辆还在修理厂里等待维修，我们并没有闲着。车库成了一个临时指挥所：白板上贴满了纸条和流程图，桌上堆着各型号的线缆、替换天线、焊接工具和一盘盘写有“备用”的 microSD 卡。团队像一支短期但高度协同的军队，被时间与任务分成若干班次。

我们的主要任务之一是把系统从 PON Atlas Duo 惯导设备切换到华测 CHC430。表面上这只是设备替换，但工程深度远超想象：协议包结构不同、时间戳的精度与编码方式不同、RTK 修正频率不同，甚至连默认坐标系的定义都不尽相同。我们写了一个“适配器”中间件，把华测的输出一一映射成我们原先定义的 ROS2 消息，这个适配器还包含了若干容错逻辑：如果 GNSS 精度低于阈值就自动切换到“惯导主导模式”；如果 IMU 数据出现漂移则触发重投影与零偏估计。

技术之外，最考验人的是“时间压力与次生故障”。10 月 13 日早上，车库的工业路由器和一台用于收集与分析的笔记本同时出现了严重故障——插板进水和车库电压不稳联合导致主板烧毁。我们曾经在模拟环境里写过“当主机崩溃时系统如何自恢复”的文档，可现实中的硬件损坏是不可被模拟的。我们不得不从零开始配置新的路由器，替换损坏的笔记本，并把所有的日志恢复到云端。这个过程看似琐碎，却是保证后续调试不会“迷失”的基础。

调试的每一步都像在缝补一件大衣：缝一针，试一试，再缝下一针。在和湖南大学团队的深度讨论之后——我们对Localization做了多处改进：

时间同步策略：把所有设备的时间源统一到 PTP（Precision Time Protocol）上，修复了多个因为时间戳错位导致的点云与GNSS不同步的问题。置信度评估：建立了一个多因子置信度模型，结合 GNSS 卫星数、RTK 固定状态、IMU 方差以及雷达点云一致性，为每一帧位姿打分。该置信度直接影响局部规划的权重分配。坐标冗余保存：每次启动时记录多个原点候选，并把它们写入持久化日志，以便发生漂移时可以做离线回溯与对齐。快速热修策略：建立一套“热补丁”流程，使团队能够在现场快速编译并部署核心修复，而不影响其余模块的运行。我们把编译时间从 20 分钟压缩到 5 分钟，以满足山地现场的快速迭代需求。

团队与湖南大学交流车辆定位策略

这些改进并非完全出于技术上的完美主义，而更多是面对现实的妥协——工程不是靠纯净的理论，而是靠对故障链的理解。团队成员在这几天里几乎没有睡觉：有人夜里去采购备用电缆，有人趴在车下测线路的接触情况，有人半夜还在写一个用来可视化置信度变化的 RViz 插件。长线作战，大家的身体虽然疲惫，精神上对于代码的严谨性却丝毫不减。

08

雨中合奏：动力的复苏

雨越下越密，把山顶的世界切割成一片片水色。10 月 14 日，我们的 PIX 底盘终于修好并返回车库。然而天意弄人，山上的雨把我们的调试带进了更复杂的局面：电路湿度增加、线缆接触不良的概率上升、甚至灰尘与水滴会在雷达的防护罩上形成微小的水膜，影响点云的反射特性。底盘的电池也因为长时间暴露于过分潮湿的环境下而出现绝缘故障，偶尔失去动力。

PIX HOOKE 2.0驶向潮湿的山路

我们在一种湿冷的协作状态里度过了一整天。每个步骤都被放慢以求谨慎：重新拧螺丝、加固防水塑料、用吹风机快速烘干接口；同时我们也在软件层面做了应对雨天的策略调整：增加对点云异常帧的短期降权、放宽连续匹配的门槛、在速度控制中引入路面湿滑的安全因子。所有这些步骤看似零碎，但在比赛现场，它们能决定车辆是否能在雨天继续前进。电池掉电的关键时刻，同学们也会协力推车，推出坚持的重量。

同学们在雨中推车

10 月 15 日的资格赛，我们限速到 10 km/h，最终以“保守但安全”的策略通过了 88 道弯的资格赛。那一刻，车从最后一个弯出来，大家也松了一口气。不是因为速度，也不是因为技术的华丽，而是因为在极端条件下生存到了下一刻的喜悦。

然而喜悦很短暂。我们在回放日志时发现了多处定位漂移的例子，这些漂移在靠近岩壁、穿过树荫或隧道入口时尤为明显。漂移一旦出现，局部规划就会依据错误的位置生成路径，从而导致控制器输出错误的方向调整。对软件团队来说，这是最深的噩梦——你所有的控制策略可能在几秒钟内因外部输入错误而变得危险。

赛后的午后，团队再一次围坐在车辆底盘前。我们做的第一个决定是引入一种“感知优先”模式：在 GNSS 置信度下降到阈值以下时，系统会自动把雷达对道路边界的识别提升为主导。换言之，在全局定位不可依赖时，我们让“眼睛”——激光雷达来代替“记忆”——GNSS 的角色。技术实现不复杂，但工程难点在于实时性的保证：雷达处理、聚类拟合、曲线拟合需要在几十毫秒级别完成，否则车辆会因为等待数据而迟滞。

通过资格赛后的代码复盘

那天晚上，我们做了若干次验证测试，成功地在几段路段实现了“感知纠偏”的效果：当GNSS轻微漂移时，雷达拟合出的道路边界将局部位姿调整回护栏线内，使控制器的输出保持在安全范围内。这个临时解决方案并不能完全替代激光SLAM，但它至少给了我们在比赛窗口里继续测试的时间和希望。

在那之后的每一次调试都像是一场合奏：有的人在调试网络链路，有的人在优化雷达滤波算法，有的人在讨论车辆的机械健康状态。我们学会了如何把各个看似微小的改进，像一层一层薄薄的油漆一样涂在系统上。我们曾在山雨之中推车上山，我们曾在夜晚的星辰之下静静编码。最终，我们靠着这种“雨中合奏”获得了继续试验的机会，但我们也清晰地知道：若要在天门山这样的环境中争夺名次，单靠后期抢救式的修补不是长久之计，真正的解决方案应该是在赛前就采纳更为稳健的定位策略（如激光SLAM）与更充足的冗余传感器与算力，然而我们的时间已经不能允许我们转移工作的重心，我们必须坚持下去。

09

赛道尽头：当算法被山拒绝

那场雨似乎下了三天。雨停的时候，天门山的云像一条刚醒来的龙，从山腰缓缓散开。地面湿滑，雾气在弯道间翻涌，像一层薄薄的幻觉。我们的车辆在出发区静静地待命。

正式比赛开始，我们排在中段发车。起点附近的空气带着油和电的味道，风声像白噪音在车身周围环绕。车辆启动后，一切仿佛重新变得简单：速度、方向、转角、反馈。控制器在低速区表现平稳，MPC 的输出在日志里干净利落。雷达感知像一双冷静的眼睛，在数据流中切割着真实世界。

可当车辆进入第一个急弯道，所有的数据瞬间黯淡了一瞬，雷达的线缆也同步损坏——GNSS 信号归零，置信度跌至最低值。惯导开始独自承担定位责任，但惯导没有情绪，它只知道积分。积分的误差在黑暗中发酵，像发霉的面包。十几秒后，车辆的位置在 RViz 里偏移了将近 3 米。

控制器仍然忠诚地执行轨迹，激光雷达却因为数据丢包开始报告“障碍物在前”。规划层陷入短暂的冲突：全局路径要求“直行”，感知模块却警告“前方危险”。我们看不见这些内部斗争，只看到一辆缓慢但倔强的车在雾里爬行，并撞向道路的边栏。

车辆轨迹异常而终止

损坏的激光雷达线缆

那一刻我们意识到：算法不是被山打败的，而是被山“拒绝”了。山的信号、湿度、岩壁反射、温度漂移，每一个变量都在提醒我们，这里不是一个为工程师准备的实验场，而是大自然的考场。我们提前写好的容错逻辑、权重系数、紧急制动策略——都在这个真实环境里显露出人性的局限。

比赛当天的终点，我们并未以名次赢得掌声，但所有人都心照不宣地笑了。那种笑不是自嘲，而是一种解脱：我们终于理解了“系统工程”真正的含义——不仅是算法能跑，更是整个系统能在不完美中继续运转。

10

夜谈：复盘的仪式

比赛结束的那晚，大家的讨论持续到深夜。我们像往常一样打开电脑，读取日志。那成百上千兆的数据包，是我们全部努力的见证。有人负责分析定位误差的时间序列；有人画出曲率变化与速度控制之间的相关图；有人统计 PID 在弯心区域的超调比例。雷达点云的回放在屏幕上跳动，每一个异常反射都像一次呼吸停顿。复盘最令人印象深刻的，是当我们发现“算法没有错”，但行为仍然“错了”。那是一种哲学式的讽刺：所有模块都在按预期运作，却因为外部世界不再满足预期而产生系统性偏差。于是我们在白板上写下三个字母：R R R —— Robustness、Redundancy、Resilience。稳健性、冗余性、恢复力。它们是系统真正的底色，而不是“跑通”那么简单。

隧道内的复盘与测试

我们初步提出了以后赛事的一系列改进方向：

最佳实践应是引入激光SLAM或VINS（视觉惯导融合）作为可靠的局部定位来源；增设惯导初值重置机制，结合地形匹配减少累计漂移；通过雷达点云匹配实现道路特征回环检测；构建自研“动态置信度”模块，使系统在不同环境下自动切换感知主导模式。

复盘不是惩罚，而是一种仪式。它让我们记得，这次上山并不是为了比赛排名，而是为了验证系统能否在“非理想世界”生存。那晚，雨后天门山的空气比咖啡还清醒。我们都在沉默中写总结，键盘声和外面的虫鸣交织成一种几乎神圣的韵律。这一次，我们可以做的还有很多。机会，一直在以后的每一次出发中等待。

11

算法的性格：日志的真相

一天后，我们开车下山。山路在窗外倒退，像一段段时间轴。坐在车里的每个人都在翻看日志。我们共带回约 300GB 的数据：点云、IMU、GNSS、CAN、相机帧、系统话题。那是一部沉默的史诗。

有人说算法其实像人：有逻辑，也有脾气。Perception 像那个一丝不苟的学生，总在怀疑输入的正确性；Localization 像一个自信过头的导航员，相信地图永远不会错；Planning 像理想主义者，总希望路径能最优；Control 则像个脾气古怪的司机，一旦数据迟到就容易暴躁。我们整个比赛都在思考如何让算法“学会妥协”。所谓妥协，不是降低精度，而是学会在信息不完美时“活下去”。这是一种系统哲学：当数据变坏，系统不崩溃；当模块失败，系统不瘫痪。真正的智能不是完美执行，而是知道何时退一步。在这一次，我们重新审视了每个模块的交互边界。我们意识到：很多失败不是单个算法的错误，而是接口定义的不够宽容。我们后来重构了消息结构，使得每个模块在输入异常时能“暂存”状态而非立即报错。例如，控制器如果一帧丢失，就自动插值而不是急停；规划模块若收到低置信度定位，就切换到雷达边界拟合模式。这些改进让系统的“性格”变得更成熟——不再是那种非黑即白的理科生，而更像一个懂得随机应变的赛车手。

我们发现，在某个的出弯口，IMU 的 Z 轴加速度在短时间内出现尖峰，随即GNSS信号中断；某道弯时，惯导积分误差累积 1.7 米；某道弯，雷达误将护栏外的岩壁识别为路沿。所有这些微小的“物理事实”，在代码层面被转译成一连串冷冰冰的数字。于是我们开始重新理解“真实世界”：风是噪声的一部分，雨是误差的来源，太阳角度会影响点云强度，岩壁形状会影响雷达反射。我们把这些现象一一注释进系统文档，让未来的算法学会“读懂”环境的语言。整理日志的过程，也是一种心理重建。每一个bug背后，都有当时那段混乱的努力。我们学会不再恐惧错误，而是感谢它。数据是诚实的，它不说谎。它告诉我们：算法没有感情，但它会把每一次人类的疏忽都忠实记录下来。

毕竟现实不是拍摄《飞驰人生》，没有那么多“努力就能逆转”的剧本。同学们经历的所有烦闷、欣喜、痛苦与欢乐，最终都被轮胎碾进了路面纹理：每一次急刹在刹车片上留下温度，每一次误差在转向拉杆里存成了间隙；那些情绪沉到天门山的沥青里，渗进每一颗碎石，成为我们此后说起“工程”两个字时默默的底色。

12

赛后共识：从竞争到共建

赛后，我们和海南大学、武汉理工大学在车库做了一次“复盘圆桌”。从总体迹象看，想在这条赛道短时间内跑出稳定而优秀的成绩，激光 SLAM 是最优解——它不是“锦上添花”，而是“地基重浇”。武汉理工把他们构建的激光 SLAM 点云地图无保留地分享给我们：数据、参数、注意事项，一条条写在白板上。竞技之外，是学术共同体的气质：希望彼此都更好，下一次一起把极限再往前推出一步。

没能完赛的根本原因其实不复杂：我们没有在赛前“真正理解现实与仿真的差异性”。我们把大量精力压在规划与控制上，却对现实中最容易出问题的外部输入——感知与定位——准备不足。结果就像让一个训练有素的短跑选手戴上眼罩去跑台阶：肌肉是好的，步频是对的，但“看不见”会把一切优势抵消。

更现实的限制也摆在那：实车经验有限、设备有限、时间窗狭窄；作为计算机学院的首次大规模实战，上来就遇到山地、电磁、天气等多重“敌意场景”，在意料之外，也在情理之中。值得庆幸的是，算法“内功”本身没有明显问题，问题主要在实现策略与系统取舍——我们本应更早把激光 SLAM、传感器融合引入架构，用“局部可验证的稳定”替代“全局可能不稳的同步”，用“高速稳健融合”替代“实时苛刻配合”。再加上突发的硬件与天气事件，留给我们收敛系统的时间确实不够充足。

13

别样风景：天门山的另一面

高能与高海拔之外，天门山还有自己的幽默感。夜里调试，原生“山猫”蹲在我们三脚架旁当监考官。这位“原住民”似乎也对AI充满了兴趣。

我们团队还和海南大学交换了队服，穿着彼此的颜色去攀天门洞。

隧道内，我们的剪影被专业的摄影团队拍出了电影感。

13

启示：系统的温度

这一次，我们学到的最重要一课，不是算法，而是“温度”。系统不是冷冰冰的机器堆叠，而是一群人赋予它性格的集合体。每一行代码都带着写下它时的心情，每一次调试都藏着某种坚持。我们在报告里写下这样一句话： 工程不是证明算法有效，而是让算法在无数不确定的夜里依然能跑。这句话后来被引用在实验室的总结会上，成了我们的精神徽章。 

回望这过去的一个月，我们讲述了一个精彩纷呈的故事：我们是一支非汽车学院的师生组成的队伍，包括激光雷达、底盘、惯导等所有的设备都是临时租用的，代码仓也是从零开始编写的。我们在一片充满理想的地基上第一次搭起了属于CodeWisdom的里程碑，将我们一直熟知的软件和仿真思想注入了它的灵魂。我们的代码跳跃在闷热的车库、忙碌的行程、校园的午后所拼接而成的每一寸光阴之中。

朴素、闷热但完备的开发环境

前往天门山路上争分夺秒的调试

当我们再谈天门山，语气里不再有技术的焦虑，而是一种透彻。山并没有打败我们，它只是让我们学会尊重不可控。真正的智慧不是征服自然，而是与自然共处——用计算理解世界，而不是企图取代它。 风从车库门口吹进来，带起几页测试报告。那一刻，所有人都安静了。仿佛那场天门山的旅程还在继续，只是换了另一种形式。

追赶天门山的云，其实不是为了追上它，而是为了在路上变成更好的自己。 Carmaker仿真器里的车辙走向现实，慢慢延伸，像一道连接过去与未来的曲线。

复旦大学软件工程实验室CodeWisdom战队合影

14

结语：感谢与展望

我们非常感谢HitchOpen组委会的专业与包容——即便像我们这样车辆基础并不厚实的团队，也能在开放的平台上快速生长，走上键盘指尖上的赛道。

我们非常感谢海南大学、湖南大学、武汉理工大学的通力协作与雪中送炭，我们建立了深厚而纯粹的友谊，科研路上各个大学相互交流、解决难题、共同探索，良师益友即无孤陋寡闻。

我们还要感谢各个赞助方的努力，将整个比赛举办成了一次真真正正的“开源共享，以赛促研、以赛兴产、以赛求学”的精彩赛事。从天门山回望高速极限场景的 AI 与自动驾驶，我们更笃定了方向：以 稳健性（Robustness） 为纲，把感知与定位的“最坏情况”前置进设计；以 冗余（Redundancy） 为椽，GNSS/IMU/激光/视觉多源互证，允许单点失败；以 恢复力（Resilience） 为魂，故障链不断裂、控制律不暴躁、系统能在不完美里持续运行。即便是汉密尔顿和维斯塔潘，也需要从驾照起步，这是我们的全新开始。

当下一次云在山腰打褶，我们希望自己的车不再被雾气“拒绝”，而是与山达成一种默契：用计算去理解世界，而不是假定世界必然温柔。等我们再次驶上 99 道弯，那些嵌在沥青里的情绪会被新的车辙覆盖——不是遗忘，而是继续向前。

END

复旦大学软件工程实验室（暨CodeWisdom团队）介绍

复旦大学软件工程实验室（暨CodeWisdom研究团队）隶属复旦大学计算与智能创新学院，团队现有教授2名（彭鑫、赵文耘）、副教授6名（陈碧欢、吴毅坚、沈立炜、沙朝锋、李敏波、董震）、讲师1名（李弋），负责人是彭鑫教授。团队研究工作聚焦国家战略性需求和产业共性问题，主要围绕智能化时代的软件工程与系统软件技术展开，具体包括软件智能化开发与运维方法与技术（AI4SE）以及面向智能化系统的工程化方法与技术（SE4AI）两个方面。前者关注于将大模型与Agent等智能化技术应用于复杂软件的开发、测试与运维之中，后者关注于智能汽车、智能制造、自主无人系统等新型智能化系统中的基础软件支撑与开发测试方法以及新型AI原生系统的构建与质量保障。

研究工作得到科技部重点研发计划项目、自然科学基金重点/面上项目支持，与重点企业共建校企联合实验室，研究成果在多家重点企业和重点行业应用，获华为优秀技术成果奖。在ICSE、FSE、ASE、ISSTA、CCS、WWW、TOSEM、TSE以及中国科学、软件学报等国内外高水平会议与期刊上发表论文100余篇。发表在软件工程领域国际旗舰期刊《 IEEE Transactions on Software Engineering》上的论文获得该期刊首次颁发的年度最佳论文奖。此外还获得ACM SIGSOFT及IEEE TCSE杰出论文等国际期刊/会议优秀论文奖10余次。

团队编写的教材《现代软件工程基础》入选教育部软件工程教指委推荐教材，获2022年教育部-华为“智能基座”优秀教材奖、优秀课件奖。编写的专著《软件开发大数据分析研究与实践》入选工业和信息化部“十四五”规划专著。     彭鑫教授获得复旦大学本科毕业生 “我心目中的好老师”以及复旦大学“研究生心目中的好导师”称号，入选2023年教育部-华为“智能基座”优秀教师，同时担任IEEE软件工程知识体系（SWEBOK）3.0和4.0版编委会成员。赵文耘教授担任教育部软件工程教指委委员。

团队承办IEEE全球化软件工程国际会议（ICGSE 2014）、IEEE软件维护与演化国际会议（ICSME 2017）、2022年与2023年CCF中国软件大会等国内外重要学术会议。彭鑫教授担任中国计算机学会软件工程专委会副主任、中国汽车工程学会基础软件分会副主任、SCI期刊《Journal of Software: Evolution and Process》联合主编，以及TOSEM、EMSE、软件学报等多个期刊编委。团队成员常年担任ICSE、FSE、ASE、ISSTA等软件工程顶级国际会议程序委员。彭鑫教授创办智能化软件开发沙龙，依托沙龙微信群举办了40期线上微访谈活动，反响热烈。团队微信公众号CodeWisdom已形成较大影响力，多篇关于大模型时代软件智能化开发的公众号文章受到广泛关注。

团队围绕智能化软件工程与系统开展研究，具体包括9个研究方向及相应的研究组，即：程序分析与测试、软件供应链风险治理、软件分析与挖掘、软件智能化开发、AI原生与云原生系统、人机物融合系统软件、机器人软件工程、人工智能系统工程、智能汽车与工业软件。目前，团队已围绕相关研究形成良好的产学研合作关系，并瞄准软件智能化开发与维护、开源软件生态治理、AI原生软件应用与系统、人机物融合泛在计算、智能汽车与智能制造基础软件等国家信息产业发展的重大战略需求进行布局。

CodeWisdom欢迎学院的本科生参与后续的竞赛！