第二十届全国大学生智能车竞赛的地瓜机器人智慧医疗挑战赛是我个人认为近几届智能车竞赛里综合度最高、也最容易让人栽跟头的赛题组。它不再是你跑得快就行而是让一辆小车在模拟病区里完成药品配送、病区巡检、紧急呼叫响应这类任务背后牵扯到视觉识别、路径规划、运动控制、任务调度一整条链路任何一个环节掉链子整车就直接趴窝。这篇文章我打算把我们从赛题拆解、硬件选型、算法落地到现场调试的完整思路摊开来写适合正在备赛的参赛队、准备带队的指导老师也适合想了解任务式智能车竞赛到底在考什么的朋友。里面所有经验都来自真实调试现场不是从规则文档里抄出来的。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系列带有专用的BPUBrain 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_speed0): 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不能给太大不然低速时会出现往复振荡车还没停到位就开始前后点头。我们最终的参数大概是Kp1.2、Ki0.05、Kd0.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站调试视频、赛区交流群这些渠道都要利用起来。地瓜机器人相关的开发者社区和官方文档也要尽早熟悉特别是模型转换工具链的坑自己摸索可能要一周看一遍别人的踩坑记录可能半天就避开了。另外强烈建议比赛前至少申请一次去别的学校场地做交流测试或者邀请其他队伍来你们场地跑一跑。不同场地条件暴露出问题的速度往往比自己闷头调试快得多。我们在交流赛中发现的一大堆问题都是在自家场地上永远复现不出来的。还有一个容易被忽略的信息差来源往届技术报告。全国大学生智能车竞赛每年都有优秀技术报告里面包含了很多队伍的技术细节和调参经验这份资料的含金量不亚于官方规则文档。备赛前期把近两年的报告都翻一遍你会发现自己很多纠结的问题前人早就踩过了。最后再分享一个小技巧比赛现场一定要准备一份快速故障排查卡上面写好常见问题对应的处理手段比如视觉启动失败→检查摄像头连接→重启视觉进程→切换备用参数。赛场上的时间是按秒算的人在紧张状态下连基本逻辑都可能想不清楚一张卡片能让你在有限时间内先稳住心态按流程走。这是我们第二次比赛时学到的教训希望后来者能少走这些弯路。