第二十届全国大学生智能车竞赛新增的地瓜机器人智慧医疗挑战赛很多人问我到底值不值得参加、技术门槛高不高、备赛周期大概多久。这篇我用参赛队伍第一视角把赛项规则、技术栈选型、实战踩坑、调试策略从头到尾拆一遍尽量把文档里没写透的东西讲明白。1. 赛项定位与核心机制拆解1.1 智慧医疗赛项到底在比什么先说结论这不是单纯比谁车跑得快而是比谁能在模拟医院场景里把“识别—路径规划—抓取—投放”这条完整任务链做得更稳、更快、更准。第二十届智能车竞赛新增的地瓜机器人智慧医疗挑战赛核心设定是让小车在仿真的病房/护士站场景里完成药品或物资的自动配送。场地里会有模拟病人床位、药品暂存点、障碍物、区域标识线等元素车需要从起点出发识别任务卡或视觉标识确认目标然后规划路径、避开障碍、在指定位置完成物资取放。相比传统竞速组这个赛项有三个明显不同的考核维度它不是跑圈计时赛而是任务制比的是任务完成度、成功率和综合用时视觉识别权重极高场地元素识别错一个后续动作全崩机械结构同样重要抓取机构的设计直接决定你能不能稳定取放物资说白了这是把“智能车”从线控竞速往“自主移动机器人”方向推的一个赛项。1.2 赛制与评分逻辑解读根据公开规则和参赛队伍反馈赛制通常采用两轮机会取最好成绩或排位赛决赛的形式每轮比赛有固定时间上限常见8分钟超时直接终止并只计算已得分。评分结构大致围绕以下几块评分维度常见分值占比说明任务完成度40%~50%成功取送物资数量、是否到达正确床位运行效率20%~30%总用时越短加分越高提前完成有奖励分技术评判10%~20%现场答辩、设计文档、创新点失误扣分负向碰撞障碍、压线、物资掉落、需要人工干预等这里最容易被忽略的是技术评判。很多队伍车跑得很好但文档写得稀烂、答辩讲不清楚设计思路最终总分被拉开。后面我会专门讲文档和答辩怎么准备。1.3 与往届赛项的核心差异如果你参加过往届的节能组、摄像头组或者越野组你会明显感受到智慧医疗赛项的差异从赛道到场地不再依赖固定宽度的赛道和电磁线场地是开放式的相当于把“轨道思维”彻底废掉从竞速到任务速度不是唯一指标稳定完成多步任务才是关键策略优先级完全不同从单车到系统需要车体、机械臂/推杆、视觉算法、调度逻辑四个子系统协同工作从处理到决策程序框架从“传感器数据→控制输出”变成“环境感知→任务规划→动作执行→异常恢复”这几点直接决定了备赛思路不能沿用老一套必须有系统级规划。2. 技术栈选型与开发环境搭建2.1 主控平台怎么选地瓜机器人 RDK X3 还是传统MCU地瓜机器人作为本赛项的联合主办方和指定硬件平台之一推荐使用其 RDK X3 系列开发套件如 RDK X3、RDK X3 Module 等。这款板子的核心优势是内置 BPU脑处理单元可以本地运行轻量化神经网络模型做目标检测、图像分类、关键点检测这些视觉任务不需要依赖云端算力。RDK X3 系列的主要参数四核 ARM Cortex-A53 处理器5 TOPS 算力的 BPU伯努利架构支持 HDMI 显示输出方便调试可视化兼容 Ubuntu 系统ROS/ROS2 生态完善支持 Python/C 开发接口选型逻辑非常清晰比赛现场的网络环境不靠谱所有识别推理必须板端本地完成。RDK X3 的 5 TOPS 算力跑 YOLO 系列轻量模型完全够用而且官方提供了大量适配好的模型转换工具和示例代码省去很多从零移植的苦工。如果队伍里有老队员特别熟 STM32 或者 Infineon 系列 MCU也不算冲突——常见的方案是**“MCU做底层运动控制 RDK X3做上层视觉/决策”**两者通过串口或CAN通信。这种双芯片架构在实际比赛中特别稳因为底层控制实时性好上层任务调度又足够灵活。2.2 开发环境搭建步骤我建议直接把 RDK X3 刷成官方 Ubuntu 镜像开发调试体验最好。流程大致是准备一张 16GB 以上的 microSD 卡推荐 Class 10 / A1 以上在官方文档下载对应板卡的镜像文件用 balenaEtcher 或 Rufus 烧录插入 SD 卡上电启动通过 HDMI 接显示器或通过串口/网口 SSH 登录执行sudo apt update sudo apt upgrade做系统更新安装必要的开发工具git、pip3、ssh、vim等安装 ROS2如果计划用 ROS 框架建议 Humble 版本资料多、社区活跃在板端或者 PC 端安装 dora-rs 或其他官方推荐的消息中间件视官方文档而定这里有个经验之谈开发调试一定优先用 SSH VSCode Remote 方式不要老是接显示器。因为跑视觉程序时板子温度容易上来加上场地调试时根本不可能带显示器提前养成远程开发习惯后面能省大量时间。2.3 视觉推理框架选择RDK X3 官方支持两种主流推理方式ONNX Runtime OpenCV在板端直接加载 ONNX 格式模型适合轻量级、快速验证bpu_py / dnn 推理接口官方封装的 BPU 加速推理接口性能最优适合正式比赛部署我的建议是前期用 ONNX Runtime 快速验证算法可行性中后期迁移到 BPU 推理接口做性能优化。这样既保证开发效率又不至于在正式比赛时因为帧率太低翻车。以 YOLO 目标检测为例官方也提供了模型转换工具可以把 PyTorch 训练好的模型转成 RDK X3 能跑的格式。转换时需要注意输入分辨率、量化精度这些参数直接影响板端推理速度和检测精度。3. 视觉识别方案底层原理与实战配置3.1 场地元素识别药品、床位、标识、障碍物智慧医疗赛项里的视觉识别对象常见的有四类任务卡/二维码告诉车当前要送什么、送到哪床位标识不同编号或颜色代表不同目标点药品/物资模型可能是特定颜色的小盒子也可能带有图案障碍物/边界线需要避让的区域或路线边界目标检测模型比较通用的做法是训练一个 YOLOv5/YOLOv8 检测模型一次性输出所有对象的类别和位置。但要注意训练数据非常关键比赛场地的光照、镜头视角、物体大小都跟网上开源数据集差别很大所以必须自己采集场地数据做数据增强重新微调模型。数据采集的实操策略把车固定在几个典型高度和角度录制视频从视频中抽帧每帧做标注标注工具可以用 LabelImg 或 Labelme每类目标至少准备 300~500 张有效图片越多越好做随机亮度、对比度、翻转、模糊等数据增强划分训练集、验证集、测试集比例约 7:2:1注意不要只拍理想光照条件下的图片比赛场地灯光变化非常影响检测效果一定要把偏暗、偏亮、反光的场景都采集进去。3.2 没有训练条件怎么办备用识别方案不是每个队伍都有 GPU 服务器也不是人人都熟练模型训练。这里提供两个可落地的替代方案方案一颜色阈值 形状特征识别。如果场地里的物资盒、床位标识颜色区分度足够高完全可以用 HSV 颜色空间做分割配合轮廓检测和形状匹配矩形度、宽高比、面积来识别目标。这个方案不需要训练开发周期短鲁棒性在光照稳定的室内场地完全够用。方案二ArUco 码 / AprilTag 识别。在场地标识物上贴 ArUco 码或 AprilTag用 OpenCV 的aruco.detectMarkers()接口直接识别。这个方案的优势是识别速度快、定位精度高还能同时输出 ID 和位姿特别适合床位编号这种“只需要知道是几号床”的场景。我当时在正式比赛方案里就做了双路融合用 YOLO 做粗检测有什么目标、大概在哪再用 ArUco 码做精确定位这是几号床、中心点在哪。粗检测负责大局精识别负责细节两者配合既不牺牲速度又大幅提升稳定性。3.3 模型迁移与部署从 yolov5 到 ONNX 再到 BPU如果你打算在 RDK X3 上用 BPU 加速推理那模型转换流程基本是PyTorch 训练好的.pt模型导出为.onnx用官方工具如 hb_mapper进行模型转换得到 RDK X3 可加载的.bin模型在板端用 Python/C 加载模型并推理这个过程中最容易踩的坑是输入尺寸不要随意改动转换时用固定尺寸如 640×640不要动态输入BPU 对动态 shape 支持不好算子和版本要兼容不是所有 ONNX 算子 BPU 都支持如果转换报错优先在模型结构里替换掉不支持的算子比如某些上采样方式量化精度损失BPU 默认用 int8 量化模型可能会有精度损失。如果检测掉点明显尝试用量化感知训练QAT或者在转换时指定校准数据集如果不想折腾模型转换直接用 ONNX Runtime 在 CPU 上跑轻量模型也完全可行只是帧率会低一些。对于比赛这种不需要实时视频流的场景3~5 FPS 的检测速度其实已经够用了。3.4 识别与定位的坐标系换算识别到目标后接下来要解决“目标在图像里”到“目标在地图上”的换算问题。这里我推荐用相机标定 单应性变换用棋盘格对相机做内参标定得到焦距、主点、畸变系数标定后用cv2.undistort()去除图像畸变在场地平面上放置已知尺寸的棋盘格或标定板计算图像坐标到场地平面坐标的单应矩阵 H后续检测到的目标点只需要通过 H 矩阵变换到场地坐标系实操时注意相机要固定得足够牢哪怕几毫米的松动都会让 H 矩阵失效。我见过有队伍把相机支架用胶带缠跑几圈位置偏了识别定位全乱套。这种低级问题一定要避免。4. 运动控制与机械结构设计4.1 底盘构型选择麦克纳姆轮还是差速轮智慧医疗赛项的场地空间通常不大需要频繁转弯、窄路通行、精准对准所以底盘构型的选择很关键。差速轮底盘结构简单控制逻辑成熟直线和转弯性能稳定但无法横向平移对准抓取点时需要多次调整姿态。麦克纳姆轮底盘可以实现全向移动平移、斜行、原地旋转对准和取放物资时效率极高但控制模型复杂一点对路面平整度要求高。我的建议是如果场地有平滑地面且允许用麦克纳姆轮果断用麦克纳姆轮。比赛时省下的姿态调整时间非常可观尤其在“取物资→送物资”这种高频对准场景里全向移动的优势太明显了。但要注意麦克纳姆轮底盘有个天然弱点容易打滑。加速度和速度的控制必须做平滑处理我用的是梯形加减速 闭环 PID配合编码器反馈实测稳定性比开环控制高出一大截。4.2 抓取机构设计从方案选型到避坑机械结构是整个赛项里最容易“翻车”的部分。常见的抓取方案有夹爪式两个手指夹取物资盒适合规则方形物体结构简单控制容易推杆式用推杆把物资从存储区推到目标区域结构最简单但适用场景有限吸盘式用真空吸盘吸取物体适合表面平整光滑的物资速度快但容易受物体材质影响升降平移式通过丝杆或导轨把物资托举到指定高度再平移放下我给的建议是夹爪式是综合表现最稳的选择。它既不挑物体材质又能适应一定尺寸变化调试难度适中。机械加工方面如果学校有 3D 打印机最好用 PLA 或 PETG 打印夹爪、支架、连接件都很方便。没有的话也可以买现成的铝合金型材搭建注意整体重量控制在合理范围内不然会拖慢车速和转向响应。4.3 运动控制逻辑框架运动控制部分我建议直接搭一个“状态机”来控制整个执行流程而不是写死的线性脚本状态列表 1. 启动/初始化 2. 前往任务卡识别区 3. 识别任务卡解析目标 4. 规划路径前往物资区 5. 识别物资盒执行抓取 6. 携带物资前往目标床位 7. 对准床位放下物资 8. 返回起点/继续下一个任务状态机的好处是每一个状态都有明确的进入条件和退出条件任何一个环节出错都可以单独处理而不是整个程序崩掉。比如抓取失败可以回到“识别物资盒”状态重试而不是直接终止。在实际编码中我把状态机做成一个while True循环每次循环根据当前状态调用对应的处理函数然后根据返回值决定下一个状态。边界条件用超时保护防止死循环卡死。5. 路径规划与调度策略的工程化实现5.1 地图构建与坐标管理从图纸到代码比赛场地虽然是开放的但通常会提供场地平面图。我的做法是把场地图纸数字化在代码里定义坐标系统以场地中心为原点单位为厘米预先标注关键点出发点、任务卡区、物资区、每个床位区、障碍物区域把这些关键点写成一个KEY_POINTS字典方便代码里随时调用如果官方不提前提供图纸也没关系可以到现场后用卷尺测量再在代码里修改参数。重点是坐标系统要统一不要图省事用图片像素坐标直接当场地坐标那样误差会非常大。5.2 基于栅格的 A* 路径规划实现因为场地是结构化环境障碍物位置已知用经典的 A* 算法做全局路径规划非常合适。步骤是将场地栅格化每格对应实际 2cm × 2cm 的区域精度可根据场地大小调整障碍物区域标记为不可通行栅格起点为当前位置栅格终点为目标点栅格用 A* 算法搜索最短可行路径得到一连串路径点对路径点做平滑处理如贝塞尔曲线或 B 样条优化运行轨迹A* 算法的核心公式是F G H其中 G 是起点到当前点的实际代价H 是当前点到终点的启发式预估代价。我用的是欧几里得距离作为 H效果比曼哈顿距离更符合实际运动特性。5.3 局部避障红外/超声波传感器补盲全局路径规划能避开静态障碍物但如果场地里有人或其他队伍的车临时挡路就需要局部避障。我在车头加了两个超声波传感器和一个红外传感器当检测到前方 15cm 内有障碍物时会触发局部避障逻辑立即减速停车左右传感器对比判断障碍物偏哪边向无障碍的一侧微调方向绕过障碍后回到全局路径注意超声波传感器有探测盲区和反射死角不要单独依赖它务必与全局路径规划配合使用否则很容易在墙角或斜面处“撞墙”。5.4 多任务调度策略先易后难还是按路线最优化如果一场比赛要求送多个物资调度顺序可以直接决定胜负。常见策略有先近后远路程最短优先代码简单但不是最优路线最优化把所有目标点和当前点抽象成 TSP旅行商问题用贪心算法或动态规划求近似最优顺序任务优先级优先如果任务卡上明确了优先级先做高优先级任务我推荐用“路线最优化 异常兜底”的组合正常情况按 TSP 贪心顺序执行如果某个物资抓取失败两次就跳过它先做后面的任务最后再尝试一次。这样能最大限度保证得分不会因为一个失败卡死全盘。6. 备赛时间线规划与团队协作模式6.1 全周期备赛节奏安排根据往年参赛经验我建议把备赛周期拉到 4~6 个月分为四个阶段阶段时间核心任务基础搭建期第 1~4 周熟悉 RDK X3 平台搭建底盘和机械结构跑通基本运动控制视觉开发期第 5~10 周采集数据、训练模型、部署推理实现目标识别和定位系统集成期第 11~14 周整合视觉、运动控制、机械抓取完成状态机调试整体任务链赛前冲刺期第 15~16 周模拟比赛流程优化速度与稳定性准备技术文档和答辩这个节奏的核心思想是先打通闭环再追求性能。很多队伍死在第二阶段就急于优化速度结果基础功能都没跑通最后比赛时到处出问题。6.2 团队分工控制、视觉、机械、文档四线并进建议队伍保持 3~5 人分工如下1 人负责主控与运动控制掌握 RDK X3 上的程序框架、串口通信、PID 调试1~2 人负责视觉算法数据采集、标注、模型训练、部署测试1 人负责机械结构与抓取机构3D 打印、装配、机械调校1 人负责文档与答辩整理设计报告、画系统框图、做 PPT同时兼职比赛现场的后勤与应急这里必须强调文档负责人不是打杂的而是要写进总分的。设计报告的评分比重不比代码和机械低很多技术排名靠前的队伍最后输在答辩上非常可惜。6.3 开发中的协作工具与版本管理多人在同一辆车上开发代码版本管理不能靠 U 盘传来传去。建议:用 Gitee 或 GitHub 建私有仓库代码统一推拉机械图纸STL/STEP 文件单独建仓库方便回溯测试数据视频、图片、标注文件存在网盘或 NAS注意数据量比较大要有心理准备每周至少一次线下联调所有代码和硬件变更必须当场验证7. 常见问题与排错实录7.1 RDK X3 启动异常与网络连接问题问题现象板子插电后 HDMI 无画面或 SSH 连接不上。排查步骤检查 SD 卡是否烧录正确重新插拔或换一张卡试确认电源功率是否足够RDK X3 建议使用 5V/3A~4A 的电源功率不足会间歇性死机确认网线或 WiFi 配置是否正确很多情况下是 IP 变了导致 SSH 连不上用串口调试线连接板子的调试串口看 boot 日志输出定位卡在哪个启动阶段心得备赛期间一定要准备一根 USB 转串口调试线这个工具在板子出问题时价值极大没有它排查问题全靠猜。7.2 视觉识别不准或漏检怎么处理问题现象模型在电脑上测试效果不错但部署到 RDK X3 后漏检率飙升。主要原因转换模型时输入分辨率被改动与训练时不匹配int8 量化导致精度下降板端帧率过低画面运动模糊严重现场光照与训练数据分布差异大解决思路保持训练、验证、部署三代数据同分布现场拍摄后回补训练量化校准阶段提供足够多样的校准图片如果帧率过低降低推理分辨率或改用更轻量的模型结构比赛前预留半天到现场做快速数据采集用现场数据做一次小规模微调7.3 机械抓取失败率高的原因与对策我见过太多次夹爪接近目标后就是“抓不住”的情况。常规原因和对策如下夹爪开合行程不够改设计增大行程或换更大的舵机/电机夹取位置偏移视觉识别输出坐标有误差加入反馈闭环用接近传感器做二次定位物资表面摩擦系数低夹爪内侧贴硅胶垫或海绵垫夹爪运动速度过快导致物体被弹开降低夹取速度增加末端缓冲结构抓取动作必须单独写一个子函数支持“失败重试”机制。比如连续检测到夹爪闭合后物资没有离地就松开重夹一次最多三次。这个逻辑虽然简单但对得分稳定性的提升非常明显。7.4 比赛现场突发状况应急预案比赛当天总会出各种幺蛾子总结几条高压线级别注意事项提前准备备用 SD 卡烧录好完整的可用镜像防止现场 SD 卡损坏带齐所有工具螺丝刀、扎带、热熔胶枪、3D 打印备用件、充电宝、多口插座电池电量管理至少准备 3 块充满电的电池每轮比赛前检查电压提前到现场踩点尽量同角度拍场地照片评估光照和场地材质做一次“冷启动测试”把车完全断电再上电看能否自动进入正常启动状态。很多队伍就是现场冷启动时程序跑飞把所有自启动逻辑都提前跑顺8. 技术文档与现场答辩准备8.1 设计报告框架与评分点设计报告是技术评判环节的重要载体评分老师主要看这几块系统总体方案设计有没有全局思维方案是否合理关键技术实现视觉、控制、机械的创新点与难度实验数据与结果分析有没有真实数据支撑还是纯“感觉”创新性与工程实践能力你比别的队多做了哪些工作建议报告控制在 20~30 页图文并茂多用系统框图、流程图、实物照片、实测数据图表。千万不要只堆代码老师不看也看不懂。8.2 答辩现场的高分表达技巧答辩时间通常 5~10 分钟要讲清楚“这辆车为什么这么设计”。我总结几个高分套路开场用一句话讲清系统架构“我们的车分为感知、决策、执行三层感知用视觉模型识别目标和位置决策用状态机调度任务执行用麦克纳姆轮底盘和夹爪完成取放动作。”每页 PPT 只讲一个核心点配合实物演示或现场视频效果远好于满屏文字和数据提前预演评委可能问的问题比如“为什么选 YOLO 而不是传统图像处理”“麦克纳姆轮和差速轮相比优势在哪”“如果现场光照变化很大你的系统怎么应对”不会的问题不要硬答坦诚说明并补充你的取舍思路比胡编显得专业得多再补充一个小技巧答辩演示用的视频要短而精建议 30~60 秒完整跑通一次任务链即可不要放长视频。评委注意力有限短平快最容易拿印象分。8.3 我踩过的文档与代码对齐的坑备赛后期最头疼的一件事是代码状态和文档描述对不上。你报告里写了“采用 A* 路径规划”结果现场代码跑的是固定路径脚本评委一旦深挖印象分直接崩塌。所以从第二阶段开始就要求文档负责人和代码负责人保持同步每周至少一次文档与代码同步检查。每个模块的代码注释里要写明设计思路和参数含义文档里引用的数据必须来自真实测试记录不要编造。9. 参赛价值与经验沉淀9.1 竞赛对技术成长的真实帮助不吹不黑智慧医疗赛项的备赛强度确实高但收获也足够大。我自己最大的感受是这个赛项涵盖了嵌入式开发、Linux 系统、ROS、视觉算法、机械设计、运动控制、项目管理多个方向的知识完整走一遍相当于一个学期的综合实践课程而且是完全以解决问题为导向的。更关键的是这种赛项逼着你在真实环境下做系统级调试。实验室环境跑得好不算数场地光照一变、地面摩擦一变、隔板位置微调所有问题都会暴露。这种“环境变化驱动系统鲁棒性”的训练是课堂里完全学不到的。9.2 优秀作品可转化的科研与项目方向我注意到不少获奖队伍的方案后续都直接继承到了实验室的纵向项目或者大创项目里。比如基于视觉的医疗物资管理机器人病房巡视与配送一体化移动平台轻量化目标检测在嵌入式设备上的部署研究这些题目放在保研、考研复试、求职简历里都是非常亮眼的项目经历。9.3 对第二十一届备赛队伍的一点建议如果你们准备参加下一届比赛不管规则怎么变我建议提前做好三件事提前吃透上一届规则和技术报告把基础平台和通用代码先搭好提前组队并明确分工不要让任何人负责“所有事”提前储备机械设计能力和 3D 打印资源机械迭代是最费时间的环节越早启动越有优势竞赛成绩是一方面备赛过程中锻炼出的问题拆解能力、跨模块协同能力和现场应急能力才是这项比赛带给参赛者最长久的东西。 
长河君 · 2026/9/19 11:01:59 · 阅读 1.2k 智能车竞赛智慧医疗赛项备赛指南：从技术栈选型到实战避坑
第二十届全国大学生智能车竞赛新增的地瓜机器人智慧医疗挑战赛很多人问我到底值不值得参加、技术门槛高不高、备赛周期大概多久。这篇我用参赛队伍第一视角把赛项规则、技术栈选型、实战踩坑、调试策略从头到尾拆一遍尽量把文档里没写透的东西讲明白。1. 赛项定位与核心机制拆解1.1 智慧医疗赛项到底在比什么先说结论这不是单纯比谁车跑得快而是比谁能在模拟医院场景里把“识别—路径规划—抓取—投放”这条完整任务链做得更稳、更快、更准。第二十届智能车竞赛新增的地瓜机器人智慧医疗挑战赛核心设定是让小车在仿真的病房/护士站场景里完成药品或物资的自动配送。场地里会有模拟病人床位、药品暂存点、障碍物、区域标识线等元素车需要从起点出发识别任务卡或视觉标识确认目标然后规划路径、避开障碍、在指定位置完成物资取放。相比传统竞速组这个赛项有三个明显不同的考核维度它不是跑圈计时赛而是任务制比的是任务完成度、成功率和综合用时视觉识别权重极高场地元素识别错一个后续动作全崩机械结构同样重要抓取机构的设计直接决定你能不能稳定取放物资说白了这是把“智能车”从线控竞速往“自主移动机器人”方向推的一个赛项。1.2 赛制与评分逻辑解读根据公开规则和参赛队伍反馈赛制通常采用两轮机会取最好成绩或排位赛决赛的形式每轮比赛有固定时间上限常见8分钟超时直接终止并只计算已得分。评分结构大致围绕以下几块评分维度常见分值占比说明任务完成度40%~50%成功取送物资数量、是否到达正确床位运行效率20%~30%总用时越短加分越高提前完成有奖励分技术评判10%~20%现场答辩、设计文档、创新点失误扣分负向碰撞障碍、压线、物资掉落、需要人工干预等这里最容易被忽略的是技术评判。很多队伍车跑得很好但文档写得稀烂、答辩讲不清楚设计思路最终总分被拉开。后面我会专门讲文档和答辩怎么准备。1.3 与往届赛项的核心差异如果你参加过往届的节能组、摄像头组或者越野组你会明显感受到智慧医疗赛项的差异从赛道到场地不再依赖固定宽度的赛道和电磁线场地是开放式的相当于把“轨道思维”彻底废掉从竞速到任务速度不是唯一指标稳定完成多步任务才是关键策略优先级完全不同从单车到系统需要车体、机械臂/推杆、视觉算法、调度逻辑四个子系统协同工作从处理到决策程序框架从“传感器数据→控制输出”变成“环境感知→任务规划→动作执行→异常恢复”这几点直接决定了备赛思路不能沿用老一套必须有系统级规划。2. 技术栈选型与开发环境搭建2.1 主控平台怎么选地瓜机器人 RDK X3 还是传统MCU地瓜机器人作为本赛项的联合主办方和指定硬件平台之一推荐使用其 RDK X3 系列开发套件如 RDK X3、RDK X3 Module 等。这款板子的核心优势是内置 BPU脑处理单元可以本地运行轻量化神经网络模型做目标检测、图像分类、关键点检测这些视觉任务不需要依赖云端算力。RDK X3 系列的主要参数四核 ARM Cortex-A53 处理器5 TOPS 算力的 BPU伯努利架构支持 HDMI 显示输出方便调试可视化兼容 Ubuntu 系统ROS/ROS2 生态完善支持 Python/C 开发接口选型逻辑非常清晰比赛现场的网络环境不靠谱所有识别推理必须板端本地完成。RDK X3 的 5 TOPS 算力跑 YOLO 系列轻量模型完全够用而且官方提供了大量适配好的模型转换工具和示例代码省去很多从零移植的苦工。如果队伍里有老队员特别熟 STM32 或者 Infineon 系列 MCU也不算冲突——常见的方案是**“MCU做底层运动控制 RDK X3做上层视觉/决策”**两者通过串口或CAN通信。这种双芯片架构在实际比赛中特别稳因为底层控制实时性好上层任务调度又足够灵活。2.2 开发环境搭建步骤我建议直接把 RDK X3 刷成官方 Ubuntu 镜像开发调试体验最好。流程大致是准备一张 16GB 以上的 microSD 卡推荐 Class 10 / A1 以上在官方文档下载对应板卡的镜像文件用 balenaEtcher 或 Rufus 烧录插入 SD 卡上电启动通过 HDMI 接显示器或通过串口/网口 SSH 登录执行sudo apt update sudo apt upgrade做系统更新安装必要的开发工具git、pip3、ssh、vim等安装 ROS2如果计划用 ROS 框架建议 Humble 版本资料多、社区活跃在板端或者 PC 端安装 dora-rs 或其他官方推荐的消息中间件视官方文档而定这里有个经验之谈开发调试一定优先用 SSH VSCode Remote 方式不要老是接显示器。因为跑视觉程序时板子温度容易上来加上场地调试时根本不可能带显示器提前养成远程开发习惯后面能省大量时间。2.3 视觉推理框架选择RDK X3 官方支持两种主流推理方式ONNX Runtime OpenCV在板端直接加载 ONNX 格式模型适合轻量级、快速验证bpu_py / dnn 推理接口官方封装的 BPU 加速推理接口性能最优适合正式比赛部署我的建议是前期用 ONNX Runtime 快速验证算法可行性中后期迁移到 BPU 推理接口做性能优化。这样既保证开发效率又不至于在正式比赛时因为帧率太低翻车。以 YOLO 目标检测为例官方也提供了模型转换工具可以把 PyTorch 训练好的模型转成 RDK X3 能跑的格式。转换时需要注意输入分辨率、量化精度这些参数直接影响板端推理速度和检测精度。3. 视觉识别方案底层原理与实战配置3.1 场地元素识别药品、床位、标识、障碍物智慧医疗赛项里的视觉识别对象常见的有四类任务卡/二维码告诉车当前要送什么、送到哪床位标识不同编号或颜色代表不同目标点药品/物资模型可能是特定颜色的小盒子也可能带有图案障碍物/边界线需要避让的区域或路线边界目标检测模型比较通用的做法是训练一个 YOLOv5/YOLOv8 检测模型一次性输出所有对象的类别和位置。但要注意训练数据非常关键比赛场地的光照、镜头视角、物体大小都跟网上开源数据集差别很大所以必须自己采集场地数据做数据增强重新微调模型。数据采集的实操策略把车固定在几个典型高度和角度录制视频从视频中抽帧每帧做标注标注工具可以用 LabelImg 或 Labelme每类目标至少准备 300~500 张有效图片越多越好做随机亮度、对比度、翻转、模糊等数据增强划分训练集、验证集、测试集比例约 7:2:1注意不要只拍理想光照条件下的图片比赛场地灯光变化非常影响检测效果一定要把偏暗、偏亮、反光的场景都采集进去。3.2 没有训练条件怎么办备用识别方案不是每个队伍都有 GPU 服务器也不是人人都熟练模型训练。这里提供两个可落地的替代方案方案一颜色阈值 形状特征识别。如果场地里的物资盒、床位标识颜色区分度足够高完全可以用 HSV 颜色空间做分割配合轮廓检测和形状匹配矩形度、宽高比、面积来识别目标。这个方案不需要训练开发周期短鲁棒性在光照稳定的室内场地完全够用。方案二ArUco 码 / AprilTag 识别。在场地标识物上贴 ArUco 码或 AprilTag用 OpenCV 的aruco.detectMarkers()接口直接识别。这个方案的优势是识别速度快、定位精度高还能同时输出 ID 和位姿特别适合床位编号这种“只需要知道是几号床”的场景。我当时在正式比赛方案里就做了双路融合用 YOLO 做粗检测有什么目标、大概在哪再用 ArUco 码做精确定位这是几号床、中心点在哪。粗检测负责大局精识别负责细节两者配合既不牺牲速度又大幅提升稳定性。3.3 模型迁移与部署从 yolov5 到 ONNX 再到 BPU如果你打算在 RDK X3 上用 BPU 加速推理那模型转换流程基本是PyTorch 训练好的.pt模型导出为.onnx用官方工具如 hb_mapper进行模型转换得到 RDK X3 可加载的.bin模型在板端用 Python/C 加载模型并推理这个过程中最容易踩的坑是输入尺寸不要随意改动转换时用固定尺寸如 640×640不要动态输入BPU 对动态 shape 支持不好算子和版本要兼容不是所有 ONNX 算子 BPU 都支持如果转换报错优先在模型结构里替换掉不支持的算子比如某些上采样方式量化精度损失BPU 默认用 int8 量化模型可能会有精度损失。如果检测掉点明显尝试用量化感知训练QAT或者在转换时指定校准数据集如果不想折腾模型转换直接用 ONNX Runtime 在 CPU 上跑轻量模型也完全可行只是帧率会低一些。对于比赛这种不需要实时视频流的场景3~5 FPS 的检测速度其实已经够用了。3.4 识别与定位的坐标系换算识别到目标后接下来要解决“目标在图像里”到“目标在地图上”的换算问题。这里我推荐用相机标定 单应性变换用棋盘格对相机做内参标定得到焦距、主点、畸变系数标定后用cv2.undistort()去除图像畸变在场地平面上放置已知尺寸的棋盘格或标定板计算图像坐标到场地平面坐标的单应矩阵 H后续检测到的目标点只需要通过 H 矩阵变换到场地坐标系实操时注意相机要固定得足够牢哪怕几毫米的松动都会让 H 矩阵失效。我见过有队伍把相机支架用胶带缠跑几圈位置偏了识别定位全乱套。这种低级问题一定要避免。4. 运动控制与机械结构设计4.1 底盘构型选择麦克纳姆轮还是差速轮智慧医疗赛项的场地空间通常不大需要频繁转弯、窄路通行、精准对准所以底盘构型的选择很关键。差速轮底盘结构简单控制逻辑成熟直线和转弯性能稳定但无法横向平移对准抓取点时需要多次调整姿态。麦克纳姆轮底盘可以实现全向移动平移、斜行、原地旋转对准和取放物资时效率极高但控制模型复杂一点对路面平整度要求高。我的建议是如果场地有平滑地面且允许用麦克纳姆轮果断用麦克纳姆轮。比赛时省下的姿态调整时间非常可观尤其在“取物资→送物资”这种高频对准场景里全向移动的优势太明显了。但要注意麦克纳姆轮底盘有个天然弱点容易打滑。加速度和速度的控制必须做平滑处理我用的是梯形加减速 闭环 PID配合编码器反馈实测稳定性比开环控制高出一大截。4.2 抓取机构设计从方案选型到避坑机械结构是整个赛项里最容易“翻车”的部分。常见的抓取方案有夹爪式两个手指夹取物资盒适合规则方形物体结构简单控制容易推杆式用推杆把物资从存储区推到目标区域结构最简单但适用场景有限吸盘式用真空吸盘吸取物体适合表面平整光滑的物资速度快但容易受物体材质影响升降平移式通过丝杆或导轨把物资托举到指定高度再平移放下我给的建议是夹爪式是综合表现最稳的选择。它既不挑物体材质又能适应一定尺寸变化调试难度适中。机械加工方面如果学校有 3D 打印机最好用 PLA 或 PETG 打印夹爪、支架、连接件都很方便。没有的话也可以买现成的铝合金型材搭建注意整体重量控制在合理范围内不然会拖慢车速和转向响应。4.3 运动控制逻辑框架运动控制部分我建议直接搭一个“状态机”来控制整个执行流程而不是写死的线性脚本状态列表 1. 启动/初始化 2. 前往任务卡识别区 3. 识别任务卡解析目标 4. 规划路径前往物资区 5. 识别物资盒执行抓取 6. 携带物资前往目标床位 7. 对准床位放下物资 8. 返回起点/继续下一个任务状态机的好处是每一个状态都有明确的进入条件和退出条件任何一个环节出错都可以单独处理而不是整个程序崩掉。比如抓取失败可以回到“识别物资盒”状态重试而不是直接终止。在实际编码中我把状态机做成一个while True循环每次循环根据当前状态调用对应的处理函数然后根据返回值决定下一个状态。边界条件用超时保护防止死循环卡死。5. 路径规划与调度策略的工程化实现5.1 地图构建与坐标管理从图纸到代码比赛场地虽然是开放的但通常会提供场地平面图。我的做法是把场地图纸数字化在代码里定义坐标系统以场地中心为原点单位为厘米预先标注关键点出发点、任务卡区、物资区、每个床位区、障碍物区域把这些关键点写成一个KEY_POINTS字典方便代码里随时调用如果官方不提前提供图纸也没关系可以到现场后用卷尺测量再在代码里修改参数。重点是坐标系统要统一不要图省事用图片像素坐标直接当场地坐标那样误差会非常大。5.2 基于栅格的 A* 路径规划实现因为场地是结构化环境障碍物位置已知用经典的 A* 算法做全局路径规划非常合适。步骤是将场地栅格化每格对应实际 2cm × 2cm 的区域精度可根据场地大小调整障碍物区域标记为不可通行栅格起点为当前位置栅格终点为目标点栅格用 A* 算法搜索最短可行路径得到一连串路径点对路径点做平滑处理如贝塞尔曲线或 B 样条优化运行轨迹A* 算法的核心公式是F G H其中 G 是起点到当前点的实际代价H 是当前点到终点的启发式预估代价。我用的是欧几里得距离作为 H效果比曼哈顿距离更符合实际运动特性。5.3 局部避障红外/超声波传感器补盲全局路径规划能避开静态障碍物但如果场地里有人或其他队伍的车临时挡路就需要局部避障。我在车头加了两个超声波传感器和一个红外传感器当检测到前方 15cm 内有障碍物时会触发局部避障逻辑立即减速停车左右传感器对比判断障碍物偏哪边向无障碍的一侧微调方向绕过障碍后回到全局路径注意超声波传感器有探测盲区和反射死角不要单独依赖它务必与全局路径规划配合使用否则很容易在墙角或斜面处“撞墙”。5.4 多任务调度策略先易后难还是按路线最优化如果一场比赛要求送多个物资调度顺序可以直接决定胜负。常见策略有先近后远路程最短优先代码简单但不是最优路线最优化把所有目标点和当前点抽象成 TSP旅行商问题用贪心算法或动态规划求近似最优顺序任务优先级优先如果任务卡上明确了优先级先做高优先级任务我推荐用“路线最优化 异常兜底”的组合正常情况按 TSP 贪心顺序执行如果某个物资抓取失败两次就跳过它先做后面的任务最后再尝试一次。这样能最大限度保证得分不会因为一个失败卡死全盘。6. 备赛时间线规划与团队协作模式6.1 全周期备赛节奏安排根据往年参赛经验我建议把备赛周期拉到 4~6 个月分为四个阶段阶段时间核心任务基础搭建期第 1~4 周熟悉 RDK X3 平台搭建底盘和机械结构跑通基本运动控制视觉开发期第 5~10 周采集数据、训练模型、部署推理实现目标识别和定位系统集成期第 11~14 周整合视觉、运动控制、机械抓取完成状态机调试整体任务链赛前冲刺期第 15~16 周模拟比赛流程优化速度与稳定性准备技术文档和答辩这个节奏的核心思想是先打通闭环再追求性能。很多队伍死在第二阶段就急于优化速度结果基础功能都没跑通最后比赛时到处出问题。6.2 团队分工控制、视觉、机械、文档四线并进建议队伍保持 3~5 人分工如下1 人负责主控与运动控制掌握 RDK X3 上的程序框架、串口通信、PID 调试1~2 人负责视觉算法数据采集、标注、模型训练、部署测试1 人负责机械结构与抓取机构3D 打印、装配、机械调校1 人负责文档与答辩整理设计报告、画系统框图、做 PPT同时兼职比赛现场的后勤与应急这里必须强调文档负责人不是打杂的而是要写进总分的。设计报告的评分比重不比代码和机械低很多技术排名靠前的队伍最后输在答辩上非常可惜。6.3 开发中的协作工具与版本管理多人在同一辆车上开发代码版本管理不能靠 U 盘传来传去。建议:用 Gitee 或 GitHub 建私有仓库代码统一推拉机械图纸STL/STEP 文件单独建仓库方便回溯测试数据视频、图片、标注文件存在网盘或 NAS注意数据量比较大要有心理准备每周至少一次线下联调所有代码和硬件变更必须当场验证7. 常见问题与排错实录7.1 RDK X3 启动异常与网络连接问题问题现象板子插电后 HDMI 无画面或 SSH 连接不上。排查步骤检查 SD 卡是否烧录正确重新插拔或换一张卡试确认电源功率是否足够RDK X3 建议使用 5V/3A~4A 的电源功率不足会间歇性死机确认网线或 WiFi 配置是否正确很多情况下是 IP 变了导致 SSH 连不上用串口调试线连接板子的调试串口看 boot 日志输出定位卡在哪个启动阶段心得备赛期间一定要准备一根 USB 转串口调试线这个工具在板子出问题时价值极大没有它排查问题全靠猜。7.2 视觉识别不准或漏检怎么处理问题现象模型在电脑上测试效果不错但部署到 RDK X3 后漏检率飙升。主要原因转换模型时输入分辨率被改动与训练时不匹配int8 量化导致精度下降板端帧率过低画面运动模糊严重现场光照与训练数据分布差异大解决思路保持训练、验证、部署三代数据同分布现场拍摄后回补训练量化校准阶段提供足够多样的校准图片如果帧率过低降低推理分辨率或改用更轻量的模型结构比赛前预留半天到现场做快速数据采集用现场数据做一次小规模微调7.3 机械抓取失败率高的原因与对策我见过太多次夹爪接近目标后就是“抓不住”的情况。常规原因和对策如下夹爪开合行程不够改设计增大行程或换更大的舵机/电机夹取位置偏移视觉识别输出坐标有误差加入反馈闭环用接近传感器做二次定位物资表面摩擦系数低夹爪内侧贴硅胶垫或海绵垫夹爪运动速度过快导致物体被弹开降低夹取速度增加末端缓冲结构抓取动作必须单独写一个子函数支持“失败重试”机制。比如连续检测到夹爪闭合后物资没有离地就松开重夹一次最多三次。这个逻辑虽然简单但对得分稳定性的提升非常明显。7.4 比赛现场突发状况应急预案比赛当天总会出各种幺蛾子总结几条高压线级别注意事项提前准备备用 SD 卡烧录好完整的可用镜像防止现场 SD 卡损坏带齐所有工具螺丝刀、扎带、热熔胶枪、3D 打印备用件、充电宝、多口插座电池电量管理至少准备 3 块充满电的电池每轮比赛前检查电压提前到现场踩点尽量同角度拍场地照片评估光照和场地材质做一次“冷启动测试”把车完全断电再上电看能否自动进入正常启动状态。很多队伍就是现场冷启动时程序跑飞把所有自启动逻辑都提前跑顺8. 技术文档与现场答辩准备8.1 设计报告框架与评分点设计报告是技术评判环节的重要载体评分老师主要看这几块系统总体方案设计有没有全局思维方案是否合理关键技术实现视觉、控制、机械的创新点与难度实验数据与结果分析有没有真实数据支撑还是纯“感觉”创新性与工程实践能力你比别的队多做了哪些工作建议报告控制在 20~30 页图文并茂多用系统框图、流程图、实物照片、实测数据图表。千万不要只堆代码老师不看也看不懂。8.2 答辩现场的高分表达技巧答辩时间通常 5~10 分钟要讲清楚“这辆车为什么这么设计”。我总结几个高分套路开场用一句话讲清系统架构“我们的车分为感知、决策、执行三层感知用视觉模型识别目标和位置决策用状态机调度任务执行用麦克纳姆轮底盘和夹爪完成取放动作。”每页 PPT 只讲一个核心点配合实物演示或现场视频效果远好于满屏文字和数据提前预演评委可能问的问题比如“为什么选 YOLO 而不是传统图像处理”“麦克纳姆轮和差速轮相比优势在哪”“如果现场光照变化很大你的系统怎么应对”不会的问题不要硬答坦诚说明并补充你的取舍思路比胡编显得专业得多再补充一个小技巧答辩演示用的视频要短而精建议 30~60 秒完整跑通一次任务链即可不要放长视频。评委注意力有限短平快最容易拿印象分。8.3 我踩过的文档与代码对齐的坑备赛后期最头疼的一件事是代码状态和文档描述对不上。你报告里写了“采用 A* 路径规划”结果现场代码跑的是固定路径脚本评委一旦深挖印象分直接崩塌。所以从第二阶段开始就要求文档负责人和代码负责人保持同步每周至少一次文档与代码同步检查。每个模块的代码注释里要写明设计思路和参数含义文档里引用的数据必须来自真实测试记录不要编造。9. 参赛价值与经验沉淀9.1 竞赛对技术成长的真实帮助不吹不黑智慧医疗赛项的备赛强度确实高但收获也足够大。我自己最大的感受是这个赛项涵盖了嵌入式开发、Linux 系统、ROS、视觉算法、机械设计、运动控制、项目管理多个方向的知识完整走一遍相当于一个学期的综合实践课程而且是完全以解决问题为导向的。更关键的是这种赛项逼着你在真实环境下做系统级调试。实验室环境跑得好不算数场地光照一变、地面摩擦一变、隔板位置微调所有问题都会暴露。这种“环境变化驱动系统鲁棒性”的训练是课堂里完全学不到的。9.2 优秀作品可转化的科研与项目方向我注意到不少获奖队伍的方案后续都直接继承到了实验室的纵向项目或者大创项目里。比如基于视觉的医疗物资管理机器人病房巡视与配送一体化移动平台轻量化目标检测在嵌入式设备上的部署研究这些题目放在保研、考研复试、求职简历里都是非常亮眼的项目经历。9.3 对第二十一届备赛队伍的一点建议如果你们准备参加下一届比赛不管规则怎么变我建议提前做好三件事提前吃透上一届规则和技术报告把基础平台和通用代码先搭好提前组队并明确分工不要让任何人负责“所有事”提前储备机械设计能力和 3D 打印资源机械迭代是最费时间的环节越早启动越有优势竞赛成绩是一方面备赛过程中锻炼出的问题拆解能力、跨模块协同能力和现场应急能力才是这项比赛带给参赛者最长久的东西。