企业官网建设流程全解析

第二十届全国大学生智能车竞赛的地瓜机器人智慧医疗挑战赛，是我个人认为近几届智能车竞赛里综合度最高、也最容易让人栽跟头的赛题组。它不再是你跑得快就行，而是让一辆小车在模拟病区里完成药品配送、病区巡检、紧急呼叫响应这类任务，背后牵扯到视觉识别、路径规划、运动控制、任务调度一整条链路，任何一个环节掉链子，整车就直接趴窝。这篇文章我打算把我们从赛题拆解、硬件选型、算法落地到现场调试的完整思路摊开来写，适合正在备赛的参赛队、准备带队的指导老师，也适合想了解任务式智能车竞赛到底在考什么的朋友。里面所有经验都来自真实调试现场，不是从规则文档里抄出来的。

1. 智慧医疗挑战赛到底考什么：赛题逻辑和任务场景拆解

1.1 从赛道竞速到任务式挑战：能力考察点的迁移

传统智能车竞赛的经典组别，核心逻辑是"谁在最短时间内跑完赛道"，车的控制目标非常单一：循迹、加速、过弯。你在单片机上调好一套串级PID，再做好电磁或者摄像头循迹，基本就能拿个不错的成绩。但智慧医疗挑战赛完全换了一套逻辑，赛道变成了任务场景，车能不能跑快反而成了次要指标，能稳定完成多少项医疗任务才是核心。

这意味着整个技术栈的重心从"运动控制"转移到了"感知-决策-执行的完整闭环"。车必须知道自己在哪、要去哪、目标长什么样、到了之后该干什么，这一整套流程以前往往被拆成多个组别分别考察，现在被塞进了同一个赛题里。对参赛队来说，最大的挑战不是某一个技术点有多难，而是如何把视觉、规划、控制、调度这些模块整合到一辆小车上，并且让它在比赛那几分钟里不出岔子。

我在给队员做技术分工时，经常说一句话：竞速赛考的是单项冠军，任务赛考的是全能王。全能王的难点不在于每一项都能做到99分，而在于每一项都得稳定到80分以上，并且模块之间不能互相拖后腿。

1.2 赛题任务场景的常见构成与评分逻辑

虽然每届规则会微调，但智慧医疗挑战赛的任务场景通常由几个模块化任务组合而成，我按我们备赛时的理解梳理一下常见构成：

• 药品/物资识别配送：病区内分布着若干科室或床位，小车需要识别指定药品或物资标签，将其从药房区域运送到目标床位，这是最核心的得分任务。
• 病区巡检：小车按一定顺序经过多个病房/床位，记录状态信息，考察路径规划的完整性和巡线/导航能力。
• 紧急呼叫响应：模拟病人按铃，赛场上某个区域亮起指示灯或出现标识，小车需要从当前位置规划新路径过去，考察动态任务响应能力。
• 避障与窄道通行：模拟病区通道中的障碍物、轮椅、病床等，小车需要识别并绕开，同时不能压线或触碰障碍物。

评分逻辑通常由三个维度组成：任务完成数量、总用时、违规扣分项。我的体感是，任务完成数量的权重远大于用时，也就是说，你宁可慢一点把所有任务做完，也不要为了追求速度导致某个任务失败或者撞到障碍物。很多强队翻车就是贪快，一个配送任务没对准，重新来一遍的时间反而把优势全部亏掉。

1.3 规则之外的隐性考察点：可靠性大于峰值性能

这类任务式赛题跟竞速赛还有一个关键区别：竞速赛可以允许试跑几次取最好成绩，但任务赛往往是一锤定音或者最多两次机会。所以赛场上真正拼的不是车的上限性能，而是下限稳定性。我们试过在实验室里跑20次成功19次，自以为稳了，结果到了赛场因为灯光色温和实验室不一样，视觉识别当场失效，连跑3次都栽在同一个地方。

所以把规则吃透之后，第一优先级永远是可靠性设计：识别要能抗光照变化，控制要能抗地面差异，任务调度要能处理意外情况。规则文档里写的都是明面上的考察点，但评委真正在看的，是你这辆车在不可控的现场环境下还能不能把任务链完整走下来。

2. 硬件平台选型与整车架构：地瓜机器人平台的用武之地

2.1 主控算力评估：为什么这个赛题需要边缘AI加速

前几届跑竞速赛，主控用STM32F4或者TC264这类MCU就完全够用，因为传感器数据量小、控制周期快，MCU的实时性和稳定性反而是优势。但到了智慧医疗挑战赛，光靠MCU是撑不起来的——目标检测、药品标签识别、病区标识读取这些任务，要么用OpenCV跑传统视觉，要么用深度学习模型跑推理，MCU的算力远远不够。

地瓜机器人这个平台之所以适合这个赛题，核心就在于它主控开发板（比如RDK X3系列）带有专用的BPU（Brain Processing Unit）神经网络加速单元，同时配了不错的CPU算力。简单类比一下，MCU就像一个只会做加减乘除的算盘，处理单线循迹够了；而RDK X3这种带NPU/BPU的板子，像是一台装了独立显卡的电脑，既能跑常规逻辑，又能并行处理神经网络推理。

我们的主力方案是主控用RDK X3系列跑视觉和任务调度，底层运动控制仍然交给一个MCU（我们用的STM32F407）来执行闭环控制。两个芯片之间通过串口通信，主控下发目标速度和转角，MCU负责封装成PWM驱动电机并回传编码器数据。这套架构的好处是职责清晰：Linux系统跑复杂算法，单片机跑实时控制，两边互不干扰。我们刚开始也试过全部用主控直接驱动电机，结果发现Linux系统调度的实时性不够稳定，偶尔会丢控制周期，车身就抖动。

2.2 传感器配置：摄像头、雷达、编码器怎么组合

传感器方案我们的配置可以做个参考：

• 摄像头（主视觉）：放在车体前方约15-20cm高度，俯仰角下压10-15度，保证既能看清远处路况，又能看清近距离的标签和标识。
• 单线激光雷达（可选）：放在车顶前部，用于实时避障和局部路径规划，扫描频率建议10Hz以上，测距半径8-12米就够。
• 编码器：左右驱动轮各配一个，用于里程计计算和闭环控制反馈。编码器线数建议不低于500线，不然低速下的速度反馈会抖动。
• 惯性测量单元（IMU）：放在底盘中心，辅助航向角推算，特别是当车轮打滑导致里程计漂移时，IMU的航向数据能帮忙纠偏。

这里我想特别说一下摄像头的选型。我们第一版图便宜用了USB免驱摄像头，结果在赛场高亮度灯光下出现严重的过曝和拖影，目标标签上的小字根本看不清。后来换成了支持手动调曝光和增益的工业相机模组，并且把自动白平衡关掉、固定参数，识别率才稳定下来。这是一笔不能省的钱，也是很多队伍容易忽略的细节。

2.3 底盘与机械结构：医疗场景对稳定性的隐藏要求

机械结构是很多软件出身的队伍最容易忽视的部分，但恰恰是最影响得分的一环。智慧医疗挑战赛的模拟病区通常有地毯、地贴、拼接板等不同地面，还有门槛或轻微坡度，如果底盘减震做得不好，摄像头画面会抖动，视觉识别就没法稳定工作。

我们的底盘方案用的是四轮差速，前两轮作为驱动轮，后两轮作为从动轮，离地间隙控制在1.5cm左右，防止过障碍时托底。悬挂方面不建议做太软，任务车的速度本身不高，太软的悬挂反而容易在转向时侧倾，导致摄像头视角晃动。另外，车体的重心尽量放低放中，电池和主控板不要堆在车尾，否则急停和转弯时车头会翘。

还有一个很实际的经验：所有线束必须做防拉扯固定。赛场上我们见过不止一次因为线束松动导致摄像头黑屏或者电机突然停转，全队当场傻眼。在实验室跑车没问题不代表到赛场没问题，运输过程中的震动能让看似牢固的接头全都松动，发车前必须做一次全车紧固检查。

3. 医疗场景感知：从药品识别到目标定位的工程化落地

3.1 目标识别方案选型：深度学习与传统视觉的边界

医疗场景的目标识别，常见的选项有三个：纯OpenCV传统视觉、DNN深度学习模型、混合方案。很多队伍一上来就想着跑YOLO做目标检测，觉得高大上、泛化性好，但忽略了一个事实：竞赛场景是高度可控的，药品标签、床位编号、病区标识都是打印出来的固定样式，颜色和形状都非常规整。这种场景下，纯传统视觉往往更稳、更快、更容易调试。

我们队里最初分了两个方案组去PK：一组用YOLOv5s跑标签识别，一组用HSV色彩分割加轮廓匹配做识别。实测下来，在固定光照条件下，传统视觉的识别率达到98%以上，单帧处理时间不到10ms；而YOLO方法虽然有更高的泛化性，但需要准备大量训练数据，转换到地平线BPU上推理还需要做量化校准，单帧推理时间也到了30-50ms，对运动中的实时性是个挑战。

最终我们采用的是混合策略：像"识别这是不是目标药瓶"这种需要语义理解的任务用深度学习模型，而"定位目标在图像中的坐标"和"读取病区标识颜色/形状"用传统视觉。这个方案兼顾了泛化能力和实时性。如果你队伍里没人熟悉深度学习模型训练部署，前期完全可以全部用传统视觉先保证能跑通，后期再按需引入深度学习，千万不要一步到位把自己卡死在模型训练上。

3.2 模型训练与部署：从数据集到BPU推理的完整流程

如果确实需要跑深度学习模型（比如要识别不同药品名称、不同标签文字），地瓜机器人平台的模型部署流程大概是这个链路：准备数据集→训练模型→模型转换与量化→板端推理。

先说数据集。竞赛用的标签种类通常不多，但每个类别最好准备300-500张不同角度、不同距离、不同光线的图片。我们当时为了凑数据，在实验室用摄像头录了十几分钟视频，然后按帧抽图，再用LabelImg做矩形框标注。这个环节很枯燥，但数据质量直接决定模型上线后的表现，一定要舍得花时间。

训练方面，我们用YOLOv5s作为基础模型，在Google Colab和本地RTX 3060上都训练过，50个epoch左右就能收敛，因为类别少、背景相对单一。训练完成后，最关键的一步是把PyTorch模型转换成地瓜工具链支持的格式。流程上需要先导出为ONNX，再通过地瓜提供的模型转换工具做量化，量化精度选INT8，因为BPU对INT8推理效率最高。量化后一定要在板端重新验证精度，有些模型量化后mAP会掉得比较厉害，如果掉太多，可以考虑用混合量化或者单独保留某些对精度敏感的层为FP16。

部署上，地瓜的开发环境提供了Python和C++两套推理API。对于比赛来说，Python API足够用，而且调试迭代快，但要注意推理耗时。我们当时做了一个简单的性能测试，同一模型用Python API跑推理大约需要12ms，换成C++ API能压到7-8ms，如果你的控制周期很紧，这5ms的差距就可能决定任务超不超时。前期用Python快速跑通，后期如果需要再考虑C++优化。

3.3 坐标转换与多目标管理：识别出来只是第一步

很多队伍在视觉上会掉进一个陷阱：模型识别出了目标，框画出来了，精确率也挺高，结果车就是开不到目标面前。原因是识别只是在图像坐标系里画了一个框，要把这个框变成车该往哪转、往哪走、什么时候停，需要一套完整的坐标转换链路。

我们是这么做坐标映射的：先把摄像头标定好内参矩阵和畸变系数，然后设定一个"地平面假设"——把地面上所有目标都近似为平面上的点，通过单应性变换矩阵，把图像坐标映射到车体坐标系下的二维坐标。这个矩阵不需要高深的数学推导，OpenCV里直接计算单应性矩阵即可，关键是标定时要在实际场地上放置若干已知坐标的标记点，然后用这些点对求解矩阵。标定一次后基本稳定，除非摄像头位置发生移动。

多目标管理是另一个容易出问题的地方。赛场上画面里同时出现三四个目标，包括障碍物、药品标签、病区标识，如果每帧重新识别一次并直接作为全局信息，很容易出现误检和抖动。我们的做法是做一个简单的目标状态列表：每次识别后按置信度过滤，并跟踪每个目标的出现帧数，只有连续5帧以上都稳定出现的才认为是一个可靠目标；同时维护目标对应的世界坐标和历史位置，用于后续路径规划。这套打补丁式的"目标追踪器"效果显著，误检率直接降低了一个量级。

4. 路径规划与运动控制：让车在狭窄病区里稳得住、停得准

4.1 底盘运动模型与里程计：先搞清楚车是怎么走的

把车开去医院送货，前提是知道自己当前位置。任务赛不像竞速赛有连续赛道线可以循迹，更多时候车需要在模拟病区的场地里自主移动到指定点位，里程计推算就是定位的基础。

我们用的是四轮差速底盘，运动模型可以简化为两轮差速模型。里程计的核心公式不长：左右轮编码器分别测出Δt时间内的位移，平均一下就是车体前进距离，左右轮位移差除以轮距就是航向变化量。把这个公式在每个控制周期里累加，就能推算出车体相对起点的坐标和航向。

但里程计最大的敌人是打滑和累计误差。地面材质变化、起步瞬间电机加速过猛、急转弯时的滑动，都会导致编码器读数不等于实际位移。我们的经验是起步和刹车用梯形加减速曲线，不要一下把PWM给满；同时融合IMU的航向角数据，做简单的互补滤波或者卡尔曼滤波，用IMU的角速度积分修正轮式里程计的航向漂移。即便这样，跑完整个病区场地后位置误差可能到10cm以上，所以长距离导航不能只靠里程计，必须依靠视觉/雷达做绝对位置修正。

4.2 巡线与自由导航结合：比单纯一种策略稳得多

在实际备赛中我们发现，纯靠里程计自由导航到目标点，存在累积误差，而纯靠循迹呢，又没法处理动态任务和避障。所以最后的策略是两种方式结合，按任务阶段切换：

• 道段巡线模式：在场地有明确引导线（地贴、色带等）的路段，用摄像头识别线的位置偏差，做PD跟踪，让车稳定沿线路行驶。这个模式适合长距离移动，不依赖精确的全局定位。
• 自主导航模式：当需要从当前位置移动到某个指定床位、或者响应紧急呼叫时，切换到自由导航。先通过识别目标标签确定目标点在世界坐标系的坐标，然后规划出一条从当前位置到目标点的路径，底层用PID控制闭环跟踪。

两种模式切换的时机很重要。我们的做法是给每个任务定义一个状态机，比如"去药房""取药""去病房""送达"等状态，每个状态下明确使用哪种控制模式，以及退出条件。比如"去药房"状态下一旦检测到药房标识且距离小于阈值，就切换到减速进港模式，避免过冲。

4.3 定点停靠与对接：精度才是拿分关键

任务类赛题里，我没见过哪个队死在"跑太慢"上，倒是见过很多队死在"停不准"上。药品送到床位，结果车离目标标识差了8cm，视觉判定为未送达或者停靠失败，这个任务分就没了。

定点停靠本质上是两级控制：粗定位与精定位。粗定位阶段用视觉或雷达引导车体靠近目标区域，当距离小于某个阈值（比如30cm）时进入精定位阶段，这时候车速要降下来，最好控制在5-10cm/s，同时用摄像头持续测量目标标识在画面中的位置，调整车头朝向，让标识保持在图像中心，直到前向距离达到停靠阈值。

这里有个细节容易被忽视：车体停稳瞬间会有惯性前冲，如果直接把目标距离设为目标位置，停下来的实际位置往往超出了。我们是在控制里做了停车距离补偿，根据实测车速和刹车加速度，预估刹车滑行距离，提前减速并在目标点前约2-3cm处发送停车指令。这个补偿值不是拍脑袋定的，是在不同速度下做了多次实测，拟合出一条停车距离-速度曲线才标定出来的。

如果你们队伍用的也是PID控制器做速度环，可以帮大家把伪代码贴在下面做个参考：

class SpeedPID: def __init__(self, kp, ki, kd, target_speed=0): self.kp = kp self.ki = ki self.kd = kd self.target_speed = target_speed self.last_error = 0 self.integral = 0 def update(self, current_speed, dt): error = self.target_speed - current_speed self.integral += error * dt derivative = (error - self.last_error) / dt output = self.kp * error + self.ki * self.integral + self.kd * derivative self.last_error = error return output

实测下来，速度环PID的Ki不能给太大，不然低速时会出现往复振荡，车还没停到位就开始前后"点头"。我们最终的参数大概是Kp=1.2、Ki=0.05、Kd=0.1，但这只是我们车体的标定结果，不同底盘要重新调。

5. 调试现场的真实排障记录：那些规则文档永远不会告诉你的事

5.1 阳光下和灯光下识别率差一半：光照问题的完整排查链路

我们第一次带着视觉方案去别的学校场地做交流测试，当场就翻车了。实验室里识别得好好的药品标签，在场地上十次有四五次识别不到。刚开始我们怀疑是模型过拟合，回实验室重新训练了一版加数据增强的模型，结果换个室内场地依旧不稳定。

后来我们收敛思路，开始逐项排查。第一步，把摄像头输出的原始画面直接保存下来，离线去看，发现场地灯光下画面明显偏黄，标签的蓝色边缘变成了墨绿色，HSV色相偏移了不少。第二步，检查摄像头参数，发现自动白平衡一直在小幅波动，导致同一场景下的色相值都在跳。第三步，我们手动固定了白平衡、曝光时间和增益，同时在做颜色识别时动态计算色相偏移量，用标签贴纸的已知色值做校准。

修复之后识别率恢复到98%以上。这个案例让我深刻认识到：视觉系统在实验室调好不算好，必须拿到比赛场地同等光照条件下做鲁棒性测试。如果赛前不能去现场，那就至少准备多种色温光源模拟，并且在算法层面加抗光照处理，比如把颜色识别从单纯的RGB阈值改成HSV空间加动态范围，或者使用灰度纹理特征辅助识别。

5.2 停不准与过冲：里程计漂移的根因追踪

还有一个让我们折腾了一周的bug：车在长距离导航后，经常停靠位置偏右或者偏左大约5-8cm。起初我们怀疑是打滑，但换了新轮胎、降低了加速度，问题依然存在。

排查链路是这样的。第一排查的是里程计标定——左右轮编码器的脉冲数到底对应多少距离，如果轮径算错了，车跑直线没问题，但转角就会系统性偏差。我们把车架起来转轮子，实测100个脉冲对应多少距离，发现右轮轮径的有效值比左轮小了约1.2mm，这就是左右轮里程不一致导致的车体跑偏。

第二个排查的是安装几何——左右轮轮距的真实值，这个参数直接影响航向角推算。我们用游标卡尺反复量了多组位置取平均，修正了轮距参数。

第三个排查的是IMU方向——IMU安装角度哪怕偏一度，融合后的航向角都会引入系统性偏差。我们用已知直线往返跑测试，记录航向角在去程和回程是否相差180度，把IMU安装角度偏差补偿进了程序。

三轮排查做完，停靠精度终于从±8cm稳定到了±2cm以内。这个过程没有任何玄学，就是一步一步做变量排除。如果你的车也出现"总停歪一点点"的规律性偏差，建议先检查里程计标定，而不是急着改PID参数。

5.3 任务超时与系统死锁：用状态机和超时机制兜底

任务赛最大的噩梦不是某一步做得不好，而是整个流程卡死在某一步。比如视觉识别线程异常退出、串口通信丢帧导致主控持续等待、或者状态机卡在"正在取药"分支里再也出不来，这几分钟就眼睁睁浪费了。

我们的防御办法是给每个状态加了超时看门狗。在主控制循环里维护一个状态间最大允许耗时，比如"去药房"最长30秒，一旦超过就强制切换到一个恢复状态，重新规划路径或者直接跳过该任务。同时，所有跟视觉、雷达的交互都设置读取超时，不能无限期等下去。

另一个很重要的做法是分模块日志。我们每次跑车都会把主控日志、视觉日志、运动控制日志按时间戳对齐存下来，哪一步出了问题，回放日志一看就知道。调试效率的提升非常大，很多现场几十秒看不出来的问题，在日志回放里一目了然。

6. 备赛节奏、团队分工与信息差

6.1 从零到冲刺：五个月的备赛节奏建议

智能车竞赛的备赛周期，按照第二年暑假国赛来算，从当年寒假开始有大约五到六个月。我们的节奏大致是这样的：

• 第1-2个月（方案期）：研读规则，确定技术路线和硬件选型，搭建最小系统，让车能动起来，视觉能识别出一个目标。这个阶段以"跑通"为唯一目标，不要过度优化。
• 第3-4个月（集成期）：把视觉、导航、运动控制、任务调度全部整合起来，完整跑通一个模拟比赛场景。这一阶段会暴露大量模块接口问题，是debug最频繁的时候。
• 第5个月（稳定性期）：反复跑完整任务流程，记录成功率，针对失败场景迭代优化。同时开始做抗干扰测试，模拟赛场不同的光照、地面和干扰情况。

需要特别强调的是，方案期一定不要花太久。我们见过有队伍在硬件选型上纠结了一个月，等板子到手只剩一个月调试，最后成绩很不理想。竞赛比的不是方案的绝对最优，而是给定时间内谁的工程化能力更强。

6.2 团队分工：算法、电控、机械怎么协同

一支标准参赛队建议至少4-5人：视觉算法、运动控制、机械结构、系统集成/文档，各1人以上，另外需要一个能做好进度管理的人。很多队伍的分工问题是各做各的，到最后集成时接口对不上。

我们队的做法是每周开两次短会，每次大家对进度、当前阻塞点，更重要的是，每周必须有一个"整车可运行"的版本。哪怕功能还很简单，也要集成起来跑一次，避免最后一个月才第一次把代码拉到一起。这个习惯救了我们很多次，很多接口问题在早期就被暴露和解决了。

机械、电控、算法三个角色之间最容易扯皮的是"这个问题该谁改"。我们的原则是：谁改动成本最低，谁改。比如发现车体震动导致视觉识别不稳，硬件和算法都可以改，但调摄像头减震的改动成本显然低于重写一套稳定算法，那就优先改硬件。

6.3 资料获取与信息差：让信息差变成你的优势

智能车竞赛圈子的信息差是真实存在的。规则文档、往届技术报告、开源代码、B站调试视频、赛区交流群，这些渠道都要利用起来。地瓜机器人相关的开发者社区和官方文档也要尽早熟悉，特别是模型转换工具链的坑，自己摸索可能要一周，看一遍别人的踩坑记录可能半天就避开了。

另外，强烈建议比赛前至少申请一次去别的学校场地做交流测试，或者邀请其他队伍来你们场地跑一跑。不同场地条件暴露出问题的速度，往往比自己闷头调试快得多。我们在交流赛中发现的一大堆问题，都是在自家场地上永远复现不出来的。

还有一个容易被忽略的信息差来源：往届技术报告。全国大学生智能车竞赛每年都有优秀技术报告，里面包含了很多队伍的技术细节和调参经验，这份资料的含金量不亚于官方规则文档。备赛前期把近两年的报告都翻一遍，你会发现自己很多纠结的问题前人早就踩过了。

最后再分享一个小技巧：比赛现场一定要准备一份"快速故障排查卡"，上面写好常见问题对应的处理手段，比如"视觉启动失败→检查摄像头连接→重启视觉进程→切换备用参数"。赛场上的时间是按秒算的，人在紧张状态下连基本逻辑都可能想不清楚，一张卡片能让你在有限时间内先稳住心态，按流程走。这是我们第二次比赛时学到的教训，希望后来者能少走这些弯路。