第二十一届全国大学生智能车竞赛
讯飞组赛项"智慧工厂" — 多团队任务拆解方案
报名日期：2026年5月1日 - 2026年8月1日
场地：5m×6m 智慧工厂场景
核心技术：讯飞星火大模型 Spark X2 + 多模态感知融合 + Gazebo虚实协同
一、整体架构
┌─────────────────────────────────────┐
│ 总技术负责人 / PM │
│ (指导老师或最靠谱的学生) │
│ 统筹进度 + 跨组协调 + 系统联调 │
└──────────────┬──────────────────────┘
│
┌─────────┬───────┼───────┬────────┬──────────┐
│ │ │ │ │ │
①导航组 ②视觉组 ③决策组 ④语音组 ⑤硬件组 ⑥仿真组
- 建议6个分组，每组3-4人
- 各组并行开发，通过ROS接口对接
- 每组设组长，参加每周跨组对齐会
- 总负责人专注于协调和联调，不写或少写代码
二、各组任务清单
① 导航与运动控制组（底盘层）
使命：让车动起来、跑得稳、不撞东西
任务清单
| 序号 |
任务 |
说明 |
| 1 |
SLAM建图 |
用激光雷达对5m×6m场地建图，输出地图文件 |
| 2 |
实时定位 |
AMCL或其他方案，定位精度≤10cm |
| 3 |
全局路径规划 |
A*/Dijkstra，从P点到各目标点 |
| 4 |
局部避障 |
DWA或TEB，应对8-10个随机锥桶 |
| 5 |
麦克纳姆轮控制 |
PID调参，实现精准停泊（3轮进框） |
| 6 |
导航API封装 |
提供ROS Service供其他组调用 |
交付接口
| 接口 |
类型 |
说明 |
/go_to_pose |
Service |
输入目标坐标，返回到达/失败 |
/nav_status |
Topic |
IDLE / MOVING / ARRIVED / ERROR |
| 场地坐标系文档 |
文档 |
P点原点、A/B/C仓库坐标、二维码区坐标 |
技术栈
ROS Navigation Stack, move_base/Nav2, TF坐标变换
验收标准
- 在模拟场地中从P点导航到指定仓库，3轮停泊
- 不碰随机摆放的锥桶
- 停泊精度：3个轮及以上在框内
核心难点
锥桶随机摆放（抽签决定位置和数量），局部避障必须可靠
人数建议：3-4人，需有ROS基础
② 视觉感知组（眼睛层）
使命：看懂场地里的一切标志
任务清单
| 序号 |
任务 |
说明 |
| 1 |
二维码识别 |
识别3个二维码，解析URL，获取JSON返回（{"code":200, "result":"苹果"}），封装为ROS Service |
| 2 |
厂区标识牌识别 |
识别"食品加工车间/日用品加工车间/电子产品生产车间"，需自建数据集 |
| 3 |
交通灯状态识别 |
识别自制红绿灯的四种状态（红灯/直行/左转/右转），需与硬件组协调规格，提前采集训练数据 |
| 4 |
视觉巡线 |
提取地面巡线，输出偏移量给导航组；识别三条巡线路径及岔路口 |
交付接口
| 接口 |
类型 |
说明 |
/scan_qrcodes |
Service |
返回3个货品名称列表 → 给决策组 |
/traffic_light |
Topic |
灯状态：RED / STRAIGHT / LEFT / RIGHT → 给决策组 |
/line_offset |
Topic |
巡线偏差量（偏移+角度）→ 给导航组 |
/sign_recognition |
Topic |
厂区标识牌识别结果 → 给决策组 |
技术栈
OpenCV, PyTorch（轻量分类模型）, zbar/pyzbar（二维码）
验收标准
- 二维码3秒内识别完毕，JSON解析正确
- 交通灯四种状态识别准确率 > 95%
- 巡线在模拟光照变化下稳定运行
- 厂区标识牌识别准确率 > 95%
核心难点
- 光照变化鲁棒性（场地为喷绘刀刮布，光照不均）
- 自制红绿灯的识别数据集需自己采集和标注
人数建议：3-4人
③ 大模型与决策组（大脑层）
使命：货品分类推理 + 全局任务调度（全队指挥中枢）
任务清单
| 序号 |
任务 |
说明 |
| 1 |
星火Spark X2 API封装 |
封装ROS节点，接收货品列表+目标大类，构建Prompt查询，解析返回结果，异常重试 |
| 2 |
全局任务状态机 |
5个子任务的状态流转管理 + 异常分支处理 |
| 3 |
决策逻辑 |
子任务1货品→仓库映射；子任务4交通灯→巡线入口选择 |
状态机设计
INIT
→ TASK1_LISTEN (等待语音指令)
→ TASK1_SCAN_QRCODE (识别二维码)
→ TASK1_INFER (大模型推理)
→ TASK1_REPORT (语音播报分类结果)
→ TASK2_NAV (导航穿越生产区)
→ TASK2_PARK (精准停泊目标仓库)
→ TASK2_REPORT (语音播报入库)
→ TASK3_SIGNAL (发送仿真就绪信号)
→ TASK3_WAIT (等待仿真完成)
→ TASK3_REPORT (语音播报仿真完成)
→ TASK4_DETECT_LIGHT (识别交通灯)
→ TASK4_DECIDE (决策巡线方向)
→ TASK5_LINE_FOLLOW (巡线行驶)
→ TASK5_PARK (终点停泊)
→ TASK5_REPORT (播报"任务完成")
→ DONE
每个状态需设计超时机制和异常恢复分支。
交付接口
| 接口 |
类型 |
说明 |
/classify_product |
Service |
输入货品名+大类，返回匹配结果+目标仓库 |
/task_state |
Topic |
当前状态机状态（全局可见） |
/decision |
Topic |
决策输出（导航目标、巡线方向等） |
Prompt工程要点
- 输入：语音指令的目标大类 + 二维码识别出的3个货品名
- 要求大模型判断哪个货品属于目标大类
- 必须稳定解析返回，格式异常时有兜底逻辑
- 测试覆盖：食品类（苹果/猪肉...）、日用品类（毛巾/T恤...）、电子类（手机/电脑...）
技术栈
Python, ROS, SMACH / BehaviorTree, Requests
验收标准
- 大模型调用成功率 > 95%（含重试机制）
- 状态机覆盖率测试：每个状态正确进入和退出
- Prompt在不同货品组合下都能正确分类
- 全链路Demo：模拟5个任务顺序走通
核心难点
- Prompt工程的稳定性（模型回复格式不可控）
- 状态机的异常处理完备性（网络超时、识别失败、播报失败）
- 比赛规则要求"必须实际调用API，技术欺诈直接取消成绩"
人数建议：3人（需全队最强的编程能力）
④ 语音交互组（耳朵和嘴巴）
使命：听懂指令、说出结果
任务清单
| 序号 |
任务 |
说明 |
| 1 |
语音唤醒 |
实现"小飞小飞"唤醒词检测 |
| 2 |
语音识别（ASR） |
解析唤醒后的完整指令，提取目标货品大类和仿真货品大类 |
| 3 |
语音播报（TTS） |
按规定格式输出5处播报（见下方） |
| 4 |
6麦阵列配置 |
声源定位+降噪，应对赛场噪声 |
五处语音播报格式
| 序号 |
时机 |
格式 |
| 1 |
子任务1完成 |
"取得[货品名称]属于[目标大类]应放置在[目标仓库]，仿真环境中取得[货品名称]属于[目标大类]应放置在[目标仓库]" |
| 2 |
子任务2完成 |
"已将[货品名称]放入[仓库类别]" |
| 3 |
子任务3完成 |
"仿真任务已完成，已将[货品名称]放入[仓库类别]" |
| 4 |
子任务4决策 |
左转 / 右转 / 直行 / 停止 |
| 5 |
子任务5完成 |
"任务完成"（停稳后10秒内开始，30秒内完成） |
交付接口
| 接口 |
类型 |
说明 |
/voice_command |
Topic |
解析后的指令结构体 → 给决策组 |
/speak |
Service |
输入文本，执行TTS播报，播报完成后返回 |
/wake_status |
Topic |
唤醒状态 |
技术栈
讯飞语音SDK, Python, ALSA/audio
验收标准
- 唤醒词3米内识别率 > 95%
- 指令解析准确率 > 90%
- TTS播报清晰，格式完全符合规则
- 播报完成有回调确认（不能播一半就继续下一步）
核心难点
- 赛场噪声干扰（观众、其他设备）
- 指令中货品名称的自然语言理解
- 播报格式必须一字不差，否则该任务不计分
人数建议：2-3人
⑤ 硬件与电路组（红绿灯 + 车模改装）
使命：自制合规红绿灯 + 车模维护（必须最早启动）
A. 电子红绿灯（竞赛硬性要求）
| 序号 |
任务 |
规格要求 |
| 1 |
PCB设计 |
原理图→PCB布局→打样 |
| 2 |
主控芯片 |
聆思科技 CSK5062（必须用此芯片，不可用其他MCU） |
| 3 |
显示屏 |
WS2812/WS2812B LED点阵，宽高≤20cm或直径≤20cm，分辨率≤256 |
| 4 |
单板设计 |
电源管理+MCU+驱动电路全在一块PCB上（屏幕除外） |
| 5 |
四种状态 |
直行/左转/右转（绿色灯光）、红灯 |
| 6 |
语音控制 |
通过CSK5062语音控制灯状态切换 |
| 7 |
结构设计 |
整体高度≤40cm，宽度≤50cm，外观可拆卸（需检查丝印） |
| 8 |
PCB丝印 |
丝印层加队伍名称，不加其他厂商LOGO（加工厂编号和LED屏幕除外） |
| 9 |
供电 |
电池供电 |
| 10 |
联调协调 |
提前告知视觉组红绿灯显示规格，方便采集识别训练数据 |
B. 车模改装与维护
| 序号 |
任务 |
说明 |
| 1 |
合规性检查 |
底盘垂直投影≥342×256mm，高度≤172mm |
| 2 |
电机 |
空载转速≤320±10%rpm |
| 3 |
传感器安装标定 |
摄像头角度、激光雷达位置、IMU固定 |
| 4 |
电池管理 |
比赛全程供电充足 |
| 5 |
赛前检录 |
准备检录材料，验证所有参数合规 |
技术栈
Altium Designer / KiCad（PCB）, C/C++（CSK5062固件）, SolidWorks（结构）
验收标准
- 红绿灯通过官方检录
- 四种状态显示清晰，语音控制响应正常
- 车模所有参数在合规范围内
核心难点
- CSK5062资料少（非主流芯片），需查聆思官方文档
- PCB打样周期长（至少2-3周），必须最早启动
- WS2812驱动+语音控制集成在单板上
人数建议：3-4人（需有电子工程背景）
⑥ 仿真与通信组（虚实协同）
使命：搭建Gazebo仿真环境 + 实现虚实通信
任务清单
| 序号 |
任务 |
说明 |
| 1 |
Gazebo环境搭建 |
复刻5m×6m场地（仓储区/生产区/停车区），放置锥桶、标识牌、巡线 |
| 2 |
虚拟机器人模型 |
URDF/Xacro建模，需有机械臂 |
| 3 |
虚拟机器人任务脚本 |
子任务3触发后：巡检→拾取→避障→放置（预设路径或简单自主规划） |
| 4 |
虚实通信协议 |
实体车→仿真发就绪信号；仿真→实体车发完成信号 |
| 5 |
联调测试 |
实体车停泊→发信号→仿真启动→仿真完成→实体车收到信号 |
交付接口
| 接口 |
类型 |
说明 |
/sim_trigger |
Service |
实体车调用，触发仿真任务 |
/sim_complete |
Topic |
仿真发布完成信号 |
| Gazebo场景文件 |
文件 |
场景.world + 虚拟机器人URDF |
技术栈
Gazebo, URDF/Xacro, ROS, Python
验收标准
- 仿真任务在收到触发后30秒内完成
- 通信可靠，无丢包
- 仿真环境与真实场地布局一致
核心难点
- Gazebo环境精度（锥桶位置、标识牌朝向）
- 虚拟机器人机械臂控制
- 虚实通信的网络配置（仅大模型调用和任务领取允许联网）
人数建议：2-3人
三、团队间接口定义总表
| 接口名称 |
提供方 |
使用方 |
类型 |
说明 |
/go_to_pose |
①导航组 |
③决策组 |
Service |
导航到目标点 |
/nav_status |
①导航组 |
③决策组 |
Topic |
导航状态 |
/line_offset |
②视觉组 |
①导航组 |
Topic |
巡线偏差量 |
/scan_qrcodes |
②视觉组 |
③决策组 |
Service |
二维码货品列表 |
/traffic_light |
②视觉组 |
③决策组 |
Topic |
交通灯状态 |
/sign_recognition |
②视觉组 |
③决策组 |
Topic |
厂区标识牌 |
/classify_product |
③决策组 |
全局 |
Service |
大模型分类 |
/task_state |
③决策组 |
全局 |
Topic |
状态机状态 |
/voice_command |
④语音组 |
③决策组 |
Topic |
语音指令解析 |
/speak |
④语音组 |
③决策组 |
Service |
TTS播报 |
/wake_status |
④语音组 |
③决策组 |
Topic |
唤醒状态 |
/sim_trigger |
⑥仿真组 |
③决策组 |
Service |
触发仿真 |
/sim_complete |
⑥仿真组 |
③决策组 |
Topic |
仿真完成信号 |
四、时间线建议（倒排计划）
假设比赛日为 T，建议按以下里程碑倒排：
T-10周：各组独立开发
| 组别 |
里程碑 |
| ⑤硬件组 |
PCB打样完成，开始CSK5062固件开发（最早启动） |
| ①导航组 |
SLAM建图 + 基础导航跑通 |
| ②视觉组 |
二维码识别 + 巡线算法原型 |
| ③决策组 |
星火API封装 + 状态机框架搭建 |
| ④语音组 |
唤醒 + ASR + TTS基本功能 |
| ⑥仿真组 |
Gazebo环境搭建 + 虚拟机器人建模 |
T-6周：组间两两联调
| 联调组合 |
目标 |
| ①导航 × ②视觉 |
巡线导航联调 |
| ③决策 × 大模型 |
Prompt测试 + 状态机走通 |
| ④语音 × ③决策 |
指令解析对接 |
| ⑤硬件 |
红绿灯原型可演示 |
T-3周：全系统集成
- 5个子任务全链路走通（即使慢、即使有bug）
- ⑥仿真 × ③决策：虚实通信联调
- ⑤硬件红绿灯接入 ②视觉识别
- 完整流程跑通一遍
T-1周：实战演练
- 模拟比赛（30分钟全流程，2次机会）
- 扣分点专项排查：压线、碰锥桶、播报格式、抢跑
- 异常恢复预案演练
- 准备检录材料
五、人员分配建议
假设总共约20人：
| 组别 |
人数 |
能力要求 |
优先级 |
| ①导航组 |
4人 |
ROS基础、C++/Python、控制理论 |
最高 |
| ②视觉组 |
3-4人 |
OpenCV、深度学习、图像处理 |
高 |
| ③决策组 |
3人 |
全队最强编程能力、Python、系统架构 |
最高 |
| ④语音组 |
2-3人 |
讯飞SDK、音频处理、NLP |
中 |
| ⑤硬件组 |
3-4人 |
电子工程、PCB设计、嵌入式C |
高（最早启动） |
| ⑥仿真组 |
2-3人 |
Gazebo、URDF、ROS |
中 |
关键角色
- 总负责人（PM）：不写代码或少量写代码，专注跨组协调、接口对齐、进度跟踪
- 每组组长：参加每周跨组对齐会，负责本组进度和对外接口
- 硬件组提前2周启动：PCB打样+固件开发周期最长
六、风险清单与应对
| 风险 |
影响 |
应对措施 |
| CSK5062开发受阻（资料少） |
红绿灯无法完成=无法参赛 |
T-12周即开始调研芯片文档，联系聆思技术支持QQ群 |
| 大模型API现场网络波动 |
子任务1失败→连锁崩盘 |
本地缓存常见分类结果作为兜底（但必须实际调用API） |
| 锥桶随机摆放导致避障失败 |
碰锥桶扣分，超30秒终止 |
充分测试DWA/TEB参数，准备多套场景 |
| 巡线选错入口 |
子任务5不可逆失败 |
交通灯识别反复验证，岔路口决策双重确认 |
| 播报格式不合规 |
对应任务不计分 |
播报内容模板化，状态机中硬编码格式 |
| 30分钟内2次都失败 |
无有效成绩 |
第1次策略偏保守，确保基础分；第2次追求完整流程 |
七、资料下载
