尊敬的华为软件精英挑战赛组委会、上合赛区评审专家：您好！我们是同济大学“恭喜以下队伍打铁”队。在2026年华为软件精英挑战赛上合赛区初赛中，我们取得了86万分的成绩。近日收到组委会关于我们代码查重异常的通知，团队对此高度重视并第一时间进行了全面复盘与自查。我们完全理解并坚决拥护组委会对学术诚信和比赛公平性的严格把控，但我们郑重声明：本团队绝对没有任何违规抄袭行为。 在此，我们诚恳地向组委会提出申诉，希望评审专家能结合我们的真实开发过程和核心策略，对我们的代码进行人工复核，以恢复我们的成绩及晋级资格。对于查重系统出现的异常，我们分析主要由以下两个客观原因叠加导致：一、 赛题底层算法的强收敛性与AI辅助开发的固有特性本道赛题属于二维不规则多边形排样的经典问题。在基础算法层面，业内公认的最优解即为闵可夫斯基和（NFP卷积）。在追求高分的前提下，底层算法选型具有高度的一致性。同时，在比赛规则允许的范围内，我们使用了大模型（ChatGPT 5.4、Claude Code）作为底层标准算法的辅助编写工具。虽然我们在提示词中严格限制了“禁止引入Clipper、Boost、CGAL等开源库或其他公开代码”，但由于大模型本身是通过学习海量公开学术论文与技术博客训练而成，其生成的标准NFP卷积、凸分解等底层算法实现，天然会与部分开源思路或标准范式产生结构性相似。这种底层算法的相似性是大模型辅助开发的正常现象，是对公开学术成果的合理参考，而非直接复制他人代码。二、 我们的核心高分壁垒：完全原创的多路线分支策略与参数调优我们能取得这样的分数，并非依赖某段标准底层算法的实现，而是基于我们完全原创的四层动态分支求解策略以及上百次的本地参数调优。这是其他队伍无法复制的核心工程量，主要体现在以下几个方面：独创的多路线分支系统： 我们摒弃了单一路线，设计了四条求解路径：路线A：精简NFP卷积（AI辅助实现）路线B：凸分解+队列式合并（AI辅助实现）路线C：最小凸包覆盖 Fallback（团队完全手写实现）路线D：完全NFP卷积（实验后已弃用）精细的动态切换逻辑： 我们通过多边形顶点数(n, m)和凹点(reflex)比例进行动态路由。例如：当 n+m <= t1 时，进入凸分解路线；否则扫描reflex点数量。若双方均为凸多边形，或 reflex比例 > w1 且 n+m >= t2，亦或 n+m >= t3，程序会直接进入我们手写的 Fallback 路线，通过牺牲极小的精度来换取极大的时间效益。大量的工程优化与实验： * 查询与I/O优化： 使用了基于 y-bucket 和矩阵哈希优化的 BVH 查表输出，并手写了基于 getchar_unlocked/fread 与 _write 的 I/O 加速。参数炼丹： 为了确定很多组黄金参数，我们进行了超过200组本地对比实验。正是这套独一无二的工程化架构和参数组合，让我们在排行榜上脱颖而出。如果是恶意抄袭，绝无可能在没有经过大量试错的情况下拼凑出这样一套严密的动态分支系统。三、 详实的开发过程证据为了证明团队工作的原创性，我们已将整个赛程的开发记录整理成附件，随时接受组委会的严格审查：提交记录： 完整展示了从基础框架搭建、多分支逻辑合并、底层优化到最终调参的演进过程。200+组本地实验记录： 包含完整的测试数据、参数调整对比及分数变化日志。团队协作证明： 包括部分每日技术讨论记录、代码评审截图。我们三名队员在过去的三周里倾注了所有的课余时间，熬过了无数个日夜才换来今天的成绩。我们非常珍惜华为软件精英挑战赛这个极具含金量的平台。恳请各位评审专家在人工复核时，重点审阅我们代码中的动态分支控制流（Fallback机制）以及相关的BVH查询优化部分。我们坚信组委会一定会秉持公平、公正、客观的原则，查明事实真相。期待您的回复！感谢各位老师在百忙之中的辛勤付出！此致敬礼！同济大学“恭喜以下队伍打铁”队队长：彭怡焱联系电话：13500754388邮箱：2451299@tongji.edu.cn2026年4月13日附件：代码查重报告截图及分析说明完整提交记录及分支演进截图200余组本地参数对比实验数据汇总表团队协作沟通记录及代码Review截图

请问何时有新一期的赛题？

最好能把评分器也一块给了，不然还要盲盒找bug，测试半天发现评分逻辑和赛题说的不一样，难顶。  吐槽一下，今年赛题为何这么水呢。

如题，评测数据是否有标准答案，给一部分也行

请问专家，简单多边形点的个数具体在什么范围可以给出吗？另外初赛正式赛的数据每例也是两个简单多边形+1w条查询吗？能否给出查询数量的范围？

如题，比赛已经结束半个多月了，还没评审完吗。另外获奖有颁发纸质或者点子版证书吗

解决方案： step1：打开终端 step2：输入sudo usermod -aG dialout orin step3：输入密码123

解决方案： RTRC 4S小车运行紧急制动程序（AEB）时（智驾模式下），使用激光测距模块检测前方障碍物距离，小于或等于制动距离，电机停止转动（正常情况）；若大于制动距离，电机就停止转动（异常情况）。 step1：当前路径下的空白处，鼠标右键打开终端，输入pwd指令，键盘回车查询路径； step2：双击打开紧急制动程序（AEB）和底盘控制两个文件，找到两个文件下定义路径的代码行，路径名字替换为pwd指令查询到的正确路径； step3：检查底盘控制代码时，可把代码替换为0.07～0.09区间值测试函数是否运行，能够实现通讯效果后，再恢复代码；step4：若还是无法通讯，检查激光测距通信接线是否正确；

昇腾AI算法挑战赛群已满加不进去！

解决方案： step1：开机后进入系统界面； step2：插拔激光雷达通信线； step3：打开一个终端，使用ls指令查询两次串口号，确定激光雷达串口号； step4：找到激光雷达ros包，launch目录下的rplidar.launch文件； step5：修改正确串口号； step6：执行命令roslaunch rplidar_ros rpliar.luanch启动激光雷达；

解决方案： 对应Jetson Nano上的引脚号进行接线，检查代码定义引脚与物理接线是否一致，若不一致就修改代码定义引脚或者接线位置，保证代码定义引脚与实际接线处一致。 step1：查看超声波代码是否正确：LEFT_TRIG_PIN=11 ，LEFT_ECHO=13 ，RIGHT_TRIG=31 ，RIGHT_ECHO_PIN=33；step2：查看超声波接线位置是否正确：左侧超声波的Trig针脚接GPIO11，Echo针脚接GPIO13，右侧超声波的Trig针脚接GPIO31，Echo针脚接GPIO33；  

解决方案： step1：若转弯时压线，则调整LKAS代码文件里draw_lines函数中描绘直线的一次函数常数项 ag_right = 0.7 * right_err + 75 和 ag_left = - 0.7 * left_err + 75 ，其范围65~85（舵机补偿值）。 step2：转弯压车道外线，舵机补偿值增大step3：转弯压车道内线，舵机补偿值减小

解决方案： step1：观察车辆在直道内行驶时整个车身是偏左还是偏右，那么调整LKAS代码文件中err_generator函数中的k = float((servo_position_range - 1500) / err_range中的常数值，这是车轮摆正的舵机数值，范围为1400~1600，出厂标定的车轮置中值为1500，舵机转向范围在（1000~2000），（1000~1500）车轮向左打，（1500~2000）车轮向右打。step2：车辆靠左行驶时，说明车辆置中值1500小了，调大后使小车向右偏移行驶在车道线中间，范围（1500~1600）step3：车辆靠右行驶时，说明车辆置中值1500大了，调小后使小车向左偏移行驶在车道线中间，范围（1400~1500）

 不是说重新评估base分嘛。。。

解决方案： step1：感兴趣区域调节是为了摄像头只检测到车道线，首先观察图像中车道线是否在感兴趣区域（蓝色区域）内。如下图：图像偏低或者肉眼发现摄像头下垂，那么就调整摄像头的高度。 step2：若调节摄像头的高度后，车道线依旧不在感兴趣区域内，或者区域太大识别到其他部分，影响到舵机控制，则调整LKAS代码文件中region_of_interest函数的vertices = np.array([[(10, imshape[0]), (imshape[1] * 5 / 34, imshape[0] * 2 / 3), (imshape[1] * 29 / 34, imshape[0] * 2 / 3), (imshape[1] - 20, imshape[0])]], dtype=np.int32)感兴趣区域四个坐标，保证车道线在感兴趣区域内或者截取掉多余区域。 左下角：(10, imshape[0])左上角：(imshape[1] * 5 / 34, imshape[0] * 2 / 3)右上角：(imshape[1] * 29 / 34, imshape[0] * 2 / 3)右下角：(imshape[1] - 20, imshape[0])连接这些点，形成一个梯形的感兴趣区域，更改这些点，改变区域的大小和形状。