yiliao2026/技术报告.md

一、性质

该技术报告面向2026年智能汽车竞赛的智慧医疗子项目，全称为第二十一届全国大学生智能汽车竞赛—地瓜机器人创意组智慧医疗赛项

内容要求（规则规定）

• 规则适配与系统调整情况
• 关键技术实现与工程经验总结
• 比赛过程中遇到的主要问题及解决思路

二、内容框架

1. 队伍简介

1.1 队伍成员

曾博文（大二）、郭诚（大二）、段华祺（大二）、陈有源（大三）

1.2 参赛用车及其改装

使用了origincar pro作为我们的比赛用车，拆卸了深度相机，加装了镭神N10雷达-串口版、外接扬声器、外置网卡

2. 系统架构

2.1 流程图

注：该流程图仅为示例，请兼顾常用机器人系统流程图制作规范以及美观性、可读性，利用合适的工具重新绘制一份流程图/架构图。

2.2 关键技术模块实现

2.2.1 利用雷达点云实现的四周墙壁拟合的重定位技术

解释技术关键要点、如何确定墙壁方程、如何规定前后左右语义等等

2.2.2 利用雷达点云与卡尔曼滤波实现的障碍物检测系统

在点云观测中，障碍物的外接圆拟合半径通常在4cm~6cm之间，由于场上仅有圆锥一种障碍物，因此直接将外接圆适配的目标标记为“障碍物”，并发布在/obstacles话题中

由于比赛时速度较快且雷达扫描与处理频率限制，很容易出现车移动但障碍物位置未更新的情况。于是我们将障碍物坐标建立为一个观测系统，基于一些数据……，从而能实时预测高速运动状态下的障碍物实际位置

2.2.3 基于扩展卡尔曼滤波的定位系统

解释origincar_base中如何将imu、电机编码器、雷达拟合位置融合并实现实时定位

2.2.4 二维码识别

解释qr_detection中如何识别二维码

2.2.5 图生文-vlm大模型与tts语音模块

概述

在 RDK X5 上部署视·觉语言模型推理系统，用于诊疗区（C区）观察到人形立牌时，通过大模型图生文反馈识别结果（病人状态描述），再经由 TTS 语音播报。系统由两块 RDK X5 板子协同完成：

• 服务端 (192.168.175.64): 运行 BPU 推理引擎，负责模型推理
• 客户端 (192.168.175.65): 运行 ROS2 小车控制 + 图像采集 + TTS 播报 客户端通过相机采集人形立牌图片，发送给服务端进行 VLM 推理，返回中文病人状态描述，再通过 TTS 语音模块播报。

模型选择

采用 InternVL2.5 + Qwen2.5-0.5B 组合方案： 选型依据： Qwen2.5-0.5B 是轻量级中文大模型，0.5B 参数适合 RDK X5 4GB 内存限制 Q4_0 量化格式在 ARM aarch64 上有 NEON 指令集优化，推理效率最高 ViT 模型经 hbDNN 工具链编译为 BPU int16 格式，图像编码仅需约 0.1s 医疗场景描述任务相对简单，0.5B 配合合适的 prompt 即可满足要求

架构设计

服务端采用 BPU 持久化方案，模型加载一次后常驻内存，循环等待推理请求：

服务端 (192.168.175.64)
systemd: vlm-services.service (开机自启)
  |-- llama-intern2vl-bpu-server  (BPU 持久化, -t 8)
  |-- tcp_bridge.py               (TCP :9216, 二进制协议)

客户端 (192.168.175.65)  
ROS2 launch vlm_detect
  |-- vlm_node     (订阅图片 + 触发信号, TCP 推理)
  |-- tts_server   (语音合成播报)

通信采用网线直连 + TCP 自定义二进制协议，替代 HTTP 的 JSON/base64 开销：

每帧: [0xAB 0xCD] [Flag:1B] [Length:4B BE] [Data:N bytes]
Flag: C=命令(JSON), I=图片(JPEG), R=结果(JSON)

Client --CMD(prompt+size)--> Server
Client --IMG(JPEG bytes)--> Server
Client <-RESP(answer)------ Server

VLM 推理流程

1. 小车导航至人形立牌前，racing_control 节点发布 Int32(9) 到 /sign4return
2. vlm_detect 节点收到触发信号，取最新一帧相机图片
3. 图片预处理：缩放到 96px，JPEG 质量 60 压缩（约 2KB）
4. 通过 TCP 发送图片 + prompt 到服务端
5. 服务端 BPU 推理引擎执行 ViT 图像编码 + LLM 文本生成
6. 返回中文描述到客户端，发布到 /vlm_result
7. tts_server 订阅结果，语音合成播报

为防止小车在路标点附近反复触发，加入一次性锁定机制：首次收到信号后置 _vlm_done = True，后续所有触发信号直接忽略。

性能优化

阶段	优化措施	效果
模型加载	BPU 常驻内存，不释放 hbDNN handle	消除每次推理的加载开销
上下文	llama_kv_cache_clear() 清空而非重载	支持连续多次推理
冷启动	启动脚本中加入暖启动步骤	首次推理从 22s 降至正常
线程	-t 8 线程并行推理	5.6s（最优值）
传输	网线直连 TCP，延迟 0.3ms	替代 WiFi (25-77ms)
图片	缩放到 96px，减少视觉 token	间接提升推理速度

最终推理耗时 5.6s，满足比赛实时性要求。

TTS 语音模块

tts_server 节点订阅 /vlm_result 话题，收到 VLM 推理结果后，调用语音合成引擎将中文文本转为语音播报。支持调整语速（默认 1.5x），通过外接扬声器输出。

关键参数

参数	默认值	说明
image_max_dim	96	图片最长边缩放大小
prompt_text	"请描述这个病人的状态…"	推理提示词
temperature	0.1	低温度确保输出确定性
max_tokens	30	限制输出长度
trigger_sign	9	触发信号值
tcp_host	192.168.127.1	服务端有线 IP

2.2.6 导航模块

• costmap层插件：基于/obstacles定制的一款轻量化插件，以减轻算力
• 取消重定位系统：在base的定位中已经实现实时重定位（滤波矫正），因此计算量庞大的重定位对于本项目来说没有必要
• 其它

2.3 由于规则定制的适配方案

2.3.1 墙线拟合模块

在实际比赛场地中，官方会在地图周围摆设一个矩形挡板，因此我们能够根据雷达观测到前后左右墙的位置来间接计算小车位于场地的位置

2.3.2 小车的比赛行为

由于轨迹较为固定且对时间要求较高，我们并没有采用目标+行为树的逻辑方法，而是针对比赛情况定制了一个基于多点生成轨迹与适配的恢复行为，从而在不影响比赛时长的前提下快速恢复导航

2.4 备赛时遇到的问题及解决办法

2.4.1 算力问题

初版方案是slamtoolbox+nav2进行的slam导航，结果发现开启后出现整车运行卡顿、tf常常滞后等情况，于是探索了经典的点云建图、避障的方法，优化效果微乎其微。最终通过建立二维方程的方法将重定位