项目 on Zesean 的博客

聆行 VoxDrive — 分布式车载智能座舱（RK3588 + Jetson Orin 双板）

Fri, 04 Sep 2026 23:50:00 +0800

项目概述

聆行 VoxDrive 是一套跑在真实硬件上的双 SoC 分布式车载智能座舱：

RK3588（LubanCat-4）= 媒体 + 端侧语音节点：摄像头采集 → MPP 硬件编码 → MP4 循环存储 / RTMP 推流，NPU 跑行人/车辆检测做事件锁录；流式 ASR（fp16 三模型 NPU 分载）与 TTS 合成（SummerTTS）也都落在这块板；
Jetson Orin Nano = 中心 AI 节点：LLM / RAG / 意图路由 / 画面问答 / Qt 数字座舱，全离线、不上云；
两板以太网互联：视频走 RTMP，控制与事件走 ZeroMQ。语音可以控制录像、查状态、抓拍，还能直接问"画面里有什么"（VLM 看行车画面作答）；
麦克风与音箱是接在 RK 上的同一 USB 设备：说话本板识别、跨板查询、应答本板播报，播报期自动静音防"自己听到自己"（回灌）。

设计原则：数据密集走专用加速器（RK 的 VPU/RGA/NPU），模型密集走中心算力（Jetson 的 GPU）；实时敏感、算力可承担的小模型（ASR/TTS）下沉边缘，大模型（LLM/VLM）留中心。

双板实物

左上 Jetson Orin Nano（带散热扇），右侧 RK3588 LubanCat-4，两板经路由器以太网互联；左下 7 寸 DSI 触摸屏接 RK，正在运行座舱 UI 的桌面会话；麦克风/音箱 USB 组合设备接 RK 侧：

系统架构

flowchart LR
 subgraph RK ["RK3588 · 媒体节点 + 语音推理节点"]
 CAM["IMX415
MIPI CSI"] --> ISP["rkisp
NV12 1080p"]
 ISP --> ENC["MPP H.264 硬编
VBR · 零 CPU 软编"]
 ENC --> MP4["MP4 分段循环存储
水位覆盖 · 事件锁录"]
 ENC --> RTMP["RTMP 推流
断流自动重连"]
 NPU["RKNPU
YOLOv5s INT8"] -->|"行人/车辆检测"| MP4
 SVC["recorder_service
REP :6700 / PUB :6701"]
 MP4 --- SVC
 RTMP --- SVC
 MIC["USB 组合设备
麦克风+音箱"] --- VS
 VS["voice_service
NPU×3 流式解码"] -->|"识别文本"| ROUTER
 TN["tts_node
SummerTTS 多核
本板播报"] -.->|"合成请求"| TTS
 end
 subgraph JS ["Jetson Orin · 中心算力节点"]
 MM["mediamtx
RTMP/RTSP/HLS"] --> UI["Qt 数字座舱
预览 · 状态 · 告警"]
 VLMQ["画面问答"] -.->|"vlm 直通"| VLM["vlm_service
Qwen2-VL-2B"]
 VLM -.->|"抓帧 :6700"| SVC
 ROUTER["意图路由"] --> LLM["LLM
Qwen2.5-1.5B"]
 ROUTER --> RAG["RAG
真实车主手册"]
 ROUTER --> TB["Tool Bus"]
 TB --> TTS["TTS 网关
REQ :6720"]
 LLM --> TB
 end
 RTMP -->|"视频流"| MM
 TB <-->|"REQ :6700
状态/抓拍/开关 (RTT 2ms)"| SVC
 SVC -->|"PUB :6701
水位/断流/检测事件"| UI

两个平面刻意分开：视频大流量不进控制面，控制面单条消息只有几百字节——跨板工具往返实测 0.73-2ms。语音链同理：音频采集、识别、合成、播报都在 RK 本板，跨板只传识别文本与应答文本两条轻量通道。

真机实拍（RK3588 7 寸触摸屏，真屏拍摄）

行车记录页：左侧 mediamtx 拉流的实时预览（断流自动重连），右侧状态卡轮询 RK（帧率/段数/磁盘水位环）+ 实时事件日志，底部按钮经 tool_bus 直控真设备；语音气泡「你：打开行车记录」是刚说完一句语音导航后 UI 的回显：

主页磁贴：录像状态横条（30.0fps / 138 段 / 5.8GB 可用）与四张磁贴的数据全部来自跨板实时链路，无一张静态图：

行车记录仪原始画质参考（IMX415 直出 1080p 快照，RK 端 NV12→JPEG、跨板抓拍约 0.15s）：

车控页 + 语音上屏（Jetson 侧实例同款界面）：问"现在录着吗"走真实链路（识别 → 路由 → 跨板查询 → LLM 组织 → TTS），底栏字幕是用户原话、气泡是基于真实工具应答生成的播报：

行车记录视频链路（RK3588）

flowchart LR
 A["IMX415
RAW Bayer"] -->|MIPI CSI-2| B["rkcif → rkisp
3A/格式"]
 B -->|NV12| C["V4L2 用户态
mmap 4 缓冲 + DMA-BUF"]
 C --> D["MPP H.264
NV12 直入 · VBR"]
 D --> E["Mp4SegmentSink
I 帧边界滚动分段"]
 D --> F["RtmpSink
flv + extradata"]
 C -.每 30 帧.-> G["最新帧槽"]
 G --> H["RGA → RKNN
YOLOv5s INT8 · NPU"]
 H -->|"命中行人/车辆"| E

几个值得说的实现细节：

NV12 同制式直入 MPP：ISP 出的 NV12 不做格式转换直接编码（全链路 CPU ~2.8%），RGA 只用于检测前处理的缩放；
MP4 分段的坑：movenc 不代转 Annex-B，需逐 NAL 转 AVCC 并手工组装 avcC；NAL 边界 off-by-one 的症状是"时长正常但解码全错"——验收判据用逐段全量解码而非 duration；
事件锁录：检测线程经"最新帧槽"旁路挂接（忙时覆盖、不反压主管线），命中即给当前段加 LOCK_ 前缀，循环覆盖天然豁免，另有配额防锁段吃满磁盘；
rkisp 残留态：boot 残留下 S_FMT 原样传回会得到行距矛盾的布局（SEGV/无帧），修复=清零强制重算 + 读回几何校验。

端侧语音闭环（推理与音频 I/O 都在 RK，LLM 留 Jetson）

语音链的形态一句话：音频不出板，跨板只传文本。麦克风/音箱（同一 USB 设备）接 RK——voice_service 进程内采集 16k PCM → kaldi-native-fbank 特征（与 sherpa C++ 前端逐位一致）→ zipformer 三模型 fp16 NPU 三核分载流式解码 → 识别文本 REQ 回 Jetson 意图路由 → 应答文本回到 RK 的 tts_node（SummerTTS 多核合成）→ 本板播报。

防回灌：麦克风和音箱是同一块硬件，播报期做事件驱动静音，解除须等 play_end 后麦克风连续 1s 真实静音（+超时兜底）；
ASR 选 fp16 而非 int8：INT8 全套量化精度分析实测不满足流式精度（状态累积崩溃），fp16 零量化损失且 RTF 0.3 以内；TTS 评估 matcha RKNN 路线后放弃（声码器输出 STFT 谱需宿主 ISTFT，NPU 图不适用），改用 SummerTTS 引擎源码上板编译——真麦声学自环实测识别逐字正确、无循环。

Jetson 侧保留三个关键架构决策：

真设备域确定性直通。1.5B 小模型在 7 个工具间选择实测不可靠（“关闭预览"被选成关车窗、“还剩多少存储"选成编数），改为关键词命中即直达跨板工具、LLM 只把真实结果组织成播报——控制类链路降到 0.43s。
语义双路路由。规则通路兜底 + 语义通路（离线意图中心余弦，阈值留出探针校准）：关键词全 miss 的改述问句直接走 RAG 快路径，9.4s → 1.2s；语义通路故障自动退化为规则单路。
推理位置按实时性分层。ASR/TTS 下沉边缘 NPU/CPU，LLM/RAG 留中心——判据是"实时敏感 × 算力可承担”，不是无脑把模型搬到一块板。

RAG 语料是真实车主手册（官网 PDF → 三级过滤 → 577 块向量库，板上构建），召回阈值 0.48 由"手册内改述句 vs 手册外噪声"的相似度实测分界定出。

座舱 UI 双端部署（RK 触摸屏）

同一套 dashboard 代码不改一行，配置切换跑在两种形态：

Jetson 桌面与 RK 7 寸 DSI 触摸屏（1024×600，Goodix 触摸）各跑一个实例，双端同时在线、订阅同一套 ZMQ 数据源——UI 是纯客户端，换屏只是多一个实例，服务端拓扑零变化；
小屏自适应：可用几何过小时自动最大化 + X 级缩放 1.5625× 到 1600×938 逻辑设计尺寸（Qt 自带 QT_SCALE_FACTOR 在本板组合上首帧后冻结，实测弃用）；
真机闭环已验证：说"打开行车记录”→ RK 触摸屏切页并自动拉起 RTSP 预览，画面色彩正确、跨屏数据实时。

实测数据

所有数字可复述测量方法，无估算值：

指标	实测值
采集（IMX415 → NV12 1080p）	30.0fps，max 帧间距 33ms（驱动时间戳，120 帧）
MPP H.264 硬编	延迟 avg 4.8 / max 8.5ms，全链路 CPU ~2.8%（单核）
跨板拉流（RK→Jetson mediamtx）	1080p30 全量解码零错误（30.2s），静态场景 VBR 下探 0.71Mbps
跨板控制面（ZMQ REQ）	RTT 2ms（路由器组网）；直连组网复测 avg 0.73ms（0.64-0.83，n=20）；抓拍 143ms（含 JPEG 编码 + 183KB base64 跨板）
RKNN 事件锁录检测	推理 25.3ms ewma（NPU core0），检测线程挂接下录像 30fps 无损；连续 1.5h+ 录像 ewma 26.2ms / 5154 次
语音闭环全程（文本入口→播报结束）	3.55-5.47s（LLM 组织 0.86-1.07s 为大头，跨板工具仅 2-10ms）；修复回灌级联后干净口径：router 应答 1.49-4.14s，→播报结束 7.0-17.9s（=答复文本+合成+实时音频时长，随答复长度自洽）
ASR 推理（RK NPU fp16 三模型分核）	RTF 0.26-0.30（10.1s 中英混复测 0.296），线上流式转写与 Jetson ORT fp32 贪心逐字一致；前端特征与 sherpa C++ 逐位一致（对拍 maxabs=0）
TTS 合成（RK SummerTTS 多核 CPU）	RTF 0.22-0.27（7 字句 0.63s、28 字句 1.47s），合成 PCM 回传播放时长精确吻合
VLM 画面问答（Qwen2-VL-2B，按需换出 llm）	应答与画面实测一致；周期=快照 0.35s+推理 4.7s+恢复 14.9s（冷启动 ~25-30s）；GPU 铁律=共存 OOM/须 evict 页缓存/ctx 2048+图降采样 960×540
真麦声学闭环（USB 组合设备）	播命令→空气→麦克风→NPU 识别逐字正确→真数据应答→本板播报+防回灌静音→无循环
LLM	Qwen2.5-1.5B Q4_K_M，22.8 token/s（首测）；第三轮复测 20.5-21.0 token/s（llama.cpp 纯生成口径 ×3，全栈在线）
长稳	16min 双板联跑 fps 稳定 30.00、29417 帧零异常；故障注入 5s 精确超时自愈；第三轮复测时已连续录像 1.5h+（154k 帧） 30.001fps、RTMP 零写错误
回归验证	2026-09-06 第二轮全量验证全绿：RK 5/5 + Jetson selftest 8/8 + 回归 4/4×2 + E2E 抽查（RTSP 90 帧零错误/色度中性、HLS、跨板语音查询含真实值 rtt 1.6-2.2s、跨板抓拍 123ms）；同日傍晚第三轮性能复测（跨板 RTT/LLM/RAG 208-280ms/ASR/TTS/E2E 全栈在线全项重测）

五个实战排障叙事

比数字更有意思的是踩坑（每条都有一手证据链）：

RKNN「流式状态发散」— 症状像量化精度，根因是内存布局。zipformer 转 RKNN 后流式解码首块全对、之后结构性错乱（值集不变、位置全乱），INT8/fp16 同症状——直觉会怪量化或图编译。真因是 RKNN 对 4D 图输入的布局约定：缓存张量必须按 transpose(0,2,3,1) 预转置喂入。定位：探针模型 chunk 级逐张量对账 → 周期标记指纹排除数值精度 → 4D 直通 tiny 图暴力解出唯一转置；修复后转写与 fp32 逐字一致。教训：多输入非图像模型上 NPU，先做直通等价自测。
ZMQ linger 默认无限：对端进程死亡时，客户端析构带着未投递消息永久阻塞，工具总线整体楔死。没有 gdb 条件，靠 /proc/<pid>/wchan + 残留 context 线程定位；修复 linger=0 + EINTR 重试后，故障注入 5s 精确超时、恢复即自愈。
1.5B 选错工具：LLM 自由选工具实测不可靠（关预览→关车窗），改成"关键词直通执行 + LLM 仅组织结果"——把确定性还给代码，把语言能力留给模型。
rkisp 残留态：S_FMT 原样传回残留行距，驱动照收但布局自相矛盾，症状是段错误 + 无帧。教训：不信任驱动的"照单全收"，写入前清零重算、读回后几何校验。
防回灌静音窗口被"事件语义差"击穿：E2E 对账发现播报结束时间异常，排查见扬声器播的回答被自家麦克风识别、级联出新查询。根因是跨板事件语义差：Jetson 的 play_end 是"合成+写入完成"（12s 音频 2.9s 就发出），而播报在 RK 实时进行——静音在"写完"后 0.6s 就解除，长答复播到一半麦克风听到自己的声音。修复=静音期顺带能量观测，解除改为 play_end 后麦克风连续 1s 真实静音；同场景对比级联 3 次 → 0 次。教训：跨板系统的"同名词事件"未必同语义，端到端对账日志是最好的透视镜。

与站内其他项目的关系

车载 AI 语音助手（Jetson）：本项目的 Jetson 侧前身，七服务架构与音频链路由它收编重构而来；
X 射线焊缝检测下位机：另一条嵌入式线（STM32 + FreeRTOS）。

可穿戴导盲辅助系统（智辅盲行）

Tue, 01 Sep 2026 13:00:00 +0800

项目概述

「智辅盲行」是一套面向视力障碍者的可穿戴式出行辅助装置，为本团队参加第二十一届中国研究生电子设计竞赛「通感算智融合与数智化应用」专项赛的参赛作品。

传统导盲工具（盲杖、导盲犬）难以感知红绿灯、远处来车等语义信息。本系统以 RK3588 边缘计算平台为核心，融合摄像头、毫米波雷达、IMU 与 GPS 多源传感器，在端侧完成目标检测与场景理解，并通过分级语音/触觉提醒帮助使用者规避风险，实现全天候（夜间、雨雾、逆光均可工作）的独立出行辅助。

系统组成

flowchart LR
 subgraph SENSE["感知端"]
 CAM["IMX415 摄像头"]
 RADAR["毫米波雷达"]
 IMU["ICM20948 IMU"]
 GPS["NEO6M GPS"]
 ESP["ESP32-S3 采集节点"]
 end
 subgraph COMPUTE["计算端：RK3588 边缘网关"]
 RKNN["RKNN NPU 推理
YOLOv8n 目标检测"]
 FUSION["多源融合
时空对齐"]
 GUIDE["导盲决策引擎
风险分级"]
 end
 subgraph FEEDBACK["反馈端"]
 SPK["功放喇叭 · 紧急播报"]
 BC["骨传导耳机 · 常规提示"]
 VIB["震动马达 · 触觉告警"]
 end
 CAM -->|MIPI| RKNN
 RADAR -->|UART| ESP
 IMU -->|I2C| ESP
 GPS -->|UART| ESP
 ESP -->|UART| FUSION
 RKNN --> FUSION
 FUSION --> GUIDE
 GUIDE --> SPK
 GUIDE --> BC
 GUIDE --> VIB

整机采用胸包式佩戴：RK3588 与电池组置于胸前硬壳包内，摄像头从包顶朝前，传感器节点固定于腰带，续航 3 小时以上。

多传感器融合策略

传感器	职责	频率	兜底逻辑
摄像头 + RKNN	目标检测：行人/车辆/障碍/红绿灯/斑马线	30fps	—
毫米波雷达	测距测速测角；夜间/雨雾/逆光兜底	10Hz	纯视觉失效时接管
IMU	坡道/坑洼检测、步态分析、跌倒检测	200Hz	GPS 辅助姿态
GPS	全局定位、远程监护	1Hz	基站定位降级

视觉与雷达互为冗余是本系统的核心设计：白天以视觉语义为主，摄像头失效的夜间与恶劣天气场景由毫米波雷达接管，保证感知链路无死角。

分级提醒策略

不同距离与场景对应不同的置信度要求和提醒强度，避免过度打扰：

场景	提醒方式
< 0.8m 障碍（雷达+视觉双确认）	喇叭强播「停！前方障碍」+ 震动马达
0.8~2m 车辆逼近	喇叭播报「注意车辆靠近」
2~5m 行人	骨传导耳机「前方 3 米有人」
红绿灯 / 斑马线识别	骨传导耳机「红灯停，检测到斑马线」
下坡 / 路面坑洼（IMU）	骨传导耳机「注意下坡，路面不平」

软件架构

全 C++ 模块化实现，按 camera / radar / imu / gps / fusion / guide / voice / comm 划分模块，配置与规则（距离阈值、播报模板）全部外置为 YAML/JSON，便于现场调整：

推理：RKNN NPU 上运行 YOLOv8n 通用检测，预留红绿灯、斑马线专用模型
融合：GPS UTC 时间戳 + 系统时钟做时空对齐，完成多源目标关联
决策：场景理解 → 风险分级 → 播报策略三级流水
语音：Piper 离线 TTS 实时合成常规提示 + 预录 WAV 零延迟播放紧急告警的混合方案，播报队列支持优先级打断

项目状态

竞赛作品已完成整机集成与多场景实测（室内避障、逆光/雨雾、复杂路口、夜间、坑洼路面），目前仍在持续迭代识别精度与佩戴体验。

个人博客（本站）

Tue, 01 Sep 2026 13:05:00 +0800

项目概述

你现在看到的这个网站，就是我的第一个完整独立部署的 Web 项目。

从域名备案、服务器采购，到站点搭建、HTTPS 证书、自动化部署，全流程独立完成。除了站点本身，还为它写了一套配套的本地工具：notes-ui 笔记工作台——把「写完的 Markdown 笔记 → 线上文章」的全流程做成了浏览器界面，拖拽上传、自动处理图片、分步构建部署。

架构

flowchart LR
 UI["notes-ui 本地笔记工作台
（Flask · 127.0.0.1）"] -->|"解析 / 图片归位 / 元数据"| SRC["本地 Markdown 源码
（本仓库）"]
 SRC -->|"hugo 构建（毫秒级）"| BUILD["静态 HTML / CSS / JS"]
 BUILD -->|"tar 打包 + scp 上传 + 原子替换"| SRV["腾讯云服务器
Nginx 托管"]
 SRV -->|"Let's Encrypt HTTPS"| USER["访客
zeseanblog.top"]

技术栈

组件	选择	说明
静态站点生成器	Hugo	单二进制，构建速度极快
主题	Stack	卡片式设计，简洁美观
Web 服务器	Nginx	HTTP/2、gzip、静态资源缓存
HTTPS	Let’s Encrypt	免费证书，certbot 自动续期
部署	自研脚本	构建 → 打包 → 上传 → 原子替换
本地工具	notes-ui（Flask）	笔记上传 / 图片处理 / 分步发布 / 文章管理

配套工具：notes-ui 笔记工作台

写笔记在本地编辑器，发布却要手工做一堆机械活：建目录、拷图片、改路径、拼 front matter、构建、部署、提交。notes-ui 把这条链路做成了只监听本机的 Web 界面：

导入：拖拽 .md 文件或整个笔记文件夹（图片自动带上），也可直接粘贴文本；自动剥离笔记自带的 front matter 并预填表单
图片处理：按正文引用自动匹配、拷入页面包 images/、统一改写路径，缺失的图片列清单可补传
发布流水线：生成页面包 → 构建验证 → 部署上线（二次确认、原子替换可回滚）→ 线上抽查（页面与图片 200 检查）→ git 提交，每步独立日志、可停在中途
文章管理：列出全部文章，支持编辑元数据、草稿开关、改 slug、本地预览（托管 hugo server -D）、删除进回收站
工程细节：零前端框架的原生单页界面；slug 实时查重；分类/标签全站自动补全；发布时间自动与最新文章错开

技术上是一个单文件 Flask 应用（Python 标准库风格，唯一的第三方依赖就是 Flask 本身），通过 subprocess 编排 hugo / 部署脚本 / git，前端为原生 HTML/JS/CSS 单页，无构建步骤。

项目状态

已上线并稳定运行，持续更新学习笔记中；笔记发布日常已通过 notes-ui 完成。

车载 AI 语音助手（Jetson Orin Nano）

Tue, 01 Sep 2026 14:00:00 +0800

项目概述

基于 NVIDIA Jetson Orin Nano 的端侧车辆 AI 语音助手：说话→听懂→思考→执行→回答全链路在车端本地完成，不依赖云端。集成 ASR-TTS 语音交互、意图路由、RAG 车辆知识库、LLM/Tool 调用与 QT 数字座舱界面，实现车辆知识问答、车控工具调用与 GUI 展示。

各服务模块采用 ZeroMQ 轻量级通信框架，实现松耦合的分布式多服务架构。

系统架构

系统拆分为 ASR、Intent Router、RAG、LLM、Tool Bus、TTS、QT UI 七个模块，模块间通过 ZMQ 的 REQ/REP + PUB/SUB 组合，实现请求应答、状态广播、状态同步三种通信模式。

以一句「帮我把空调调到 24 度」为例的完整链路：

flowchart LR
 MIC["麦克风"] --> VAD["VAD / 关键词唤醒"]
 VAD --> ASR["ASR 语音识别
sherpa-onnx zipformer"]
 ASR --> IR["意图路由
语义分类 + 规则分类"]
 IR -->|"车控意图"| LLM["LLM
Qwen2.5-3B Q4_K_M"]
 IR -->|"知识问答"| RAG["RAG 检索
车辆手册向量库"]
 RAG --> LLM
 LLM -->|"tool_call JSON"| TOOL["Tool Bus
车控工具执行"]
 LLM -->|"respond JSON"| TTS["TTS 播报
SummerTTS"]
 TOOL -->|"状态同步"| UI["QT 座舱 UI"]
 TTS --> OUT["扬声器"]

关键技术点

AI 语音交互：ASR 使用 sherpa-onnx 部署 zipformer 模型，TTS 基于 SummerTTS；设计了 ASR 与 TTS 的同步机制，避免 TTS 播放期间语音回灌误识别；构建 VAD 与关键词唤醒
意图路由：语义分类 + 规则分类双通路融合的意图识别，编排 5 类服务调用，按意图选择 RAG 检索、LLM 调用、直接语音回复或 Tool 调用的组合
RAG 车辆知识库：基于 sentence-transformers 将车辆手册向量化，余弦相似度 + Top-K 检索，端侧全离线完成知识问答
LLM 部署与 Tool 调用：llama.cpp 部署 Qwen2.5-3B 的 GGUF Q4_K_M 量化模型；通过 prompt 强约束让模型只输出两类 JSON——respond 交给 TTS 播放，tool_call 驱动车控工具执行
QT 车载座舱 GUI：数字座舱界面，实时展示空调、车窗、天窗、摄像头与传感器等车辆状态

核心 API 与接口设计

服务端口与通信原语

服务	端口	协议
Intent Router	:6666	ZMQ REQ/REP
RAG Service	:6667	ZMQ REQ/REP
LLM Service	:6668	ZMQ REQ/REP
Tool Bus	:6669	ZMQ REQ/REP
状态广播	:6670 / :6671	ZMQ PUB/SUB
TTS Server	:7777	音频流
llama-server（GGUF 推理后端）	:8080	HTTP

C++ 侧封装了 ZmqServer / ZmqClient（REQ/REP 请求应答）与 ZmqPub / ZmqSub（状态广播）两组通用组件，各服务只依赖消息契约、不依赖彼此实现。

意图路由：五分类多分支

Router 对每句输入做语义分类 + 规则分类双通路融合，输出五类意图并按类型路由到不同服务链：

意图	链路	典型时延
EMERGENCY（紧急事项）	RAG → TTS	~0.5s
FACTUAL（手册事实问答）	RAG → TTS	~0.5s
EXPLICIT_CMD（明确车控指令）	Tool Bus → TTS	~0.5s
COMPLEX（复杂查询）	RAG → LLM → TTS	秒级
CREATIVE（闲聊/生成）	LLM → TTS	秒级
LLM + Tool 闭环	LLM ↔ Tool → LLM → TTS	秒级

LLM 双模式 JSON 契约

通过 Prompt 强约束 LLM 只输出两类 JSON，这是「语音语义 → 车辆动作」的核心契约：

1
2
3
4
5
6
7


{"action": "respond", "content": "好的，已为您将空调调到 24 度"}

{"action": "tool_call",
 "tool": "ac",
 "tool_action": "set_temperature",
 "params": {"value": 24},
 "reason": "用户要求把空调调到 24 度"}

respond → 直接送 TTS 播报
tool_call → Tool Bus 侧做参数归一化与校验（例如从口语化文本中提取「24 度」的数值），执行后通过 PUB 通道把车辆状态同步给 QT 座舱，并把执行结果回灌 LLM 生成自然语言回复
无法归一化的输出会降级为 respond 兜底，保证任何情况下用户都能得到语音反馈

RAG 检索接口

车辆手册切片后经 sentence-transformers 编码为 768 维向量入库；查询时同模型编码 query → 余弦相似度 Top-K 检索 → 命中文档拼接进 LLM 上下文，全部在端侧离线完成。

项目状态

全链路已在 Jetson Orin Nano 上跑通，端侧离线完成语音到车控的闭环。

基于人脸识别的视觉门禁系统（RK3588）

Tue, 01 Sep 2026 14:05:00 +0800

项目概述

面向区域门禁的边缘侧视觉安防系统，防止异常访客进入。在 RK3588 上完成视频编解码、多模型 NPU 推理、视频推流的系统集成，实现「识别 → 比对 → 开门」的任务闭环，同时保证库内人脸识别准确度。

系统链路

flowchart LR
 CAM["4 路 RTSP 摄像头"] --> PULL["FFmpeg 拉流"]
 PULL --> DEC["MPP 硬解码
1080p@30fps"]
 DEC --> BUF["共享缓冲区
生产者-消费者队列"]
 BUF --> RGA["RGA 预处理
零拷贝"]
 RGA --> NPU["NPU 多模型推理
YOLO11 · RetinaFace · FaceNet"]
 NPU --> CMP{"人脸比对
SQLite 5k+ 特征库"}
 CMP -->|"命中 > 98%"| DOOR["GPIO 继电器开门
延迟 < 1s"]
 DEC --> ENC["H.264 封装"]
 ENC --> RTMP["RTMP 推流"]

解码、推理、推流之间采用生产者-消费者队列隔离，端到端延迟 < 200ms，长时间连续运行无内存泄漏。

关键技术点

多媒体采集处理：FFmpeg 实现 4 路 RTSP 视频流拉流；Rockchip MPP 完成 H.264 硬件解码；共享缓冲区保证帧数据的线程安全；解码后封装 H.264 经 RTMP 推流供远程查看
多模型 NPU 推理调度：RKNN-Toolkit2 完成三模型 INT8 量化部署——YOLO11（人体检测）、RetinaFace（人脸检测）、FaceNet（人脸识别）；量化精度分析后对敏感层做混合量化提升精度，单帧 NPU 推理耗时 < 35ms
工程优化：解码零拷贝输出 Buffer 直入 RGA 做图像预处理，显著降低 CPU 负载
人脸识别管理：本地人脸库管理，SQLite 存储 5000+ 人脸特征，库内验证命中率 > 98%；编写 GPIO 子系统驱动门禁继电器，识别通过到开门 < 1s

核心模块与接口设计

多媒体链路模块

模块	接口	职责
`stream_loader`	FFmpeg `avformat_open_input / av_read_frame`	4 路 RTSP 拉流接入
`mpp_decoder`	Rockchip MPP 硬解接口	H.264 → NV12，1080p@30fps
`rga_func`	`imresize / imcvtcolor`（零拷贝 DMA）	缩放与色彩空间转换
`mpp_encoder` + `streaming_manager`	H.264 编码 + RTMP 封装推流	远程实时查看
`detection_fusion_manager`	多模型结果融合	检测/识别结果汇总

三级级联推理（RKNN C API）

人体 → 人脸 → 特征三级模型逐级过滤，只有命中上一级的候选才进入下一级，显著降低 NPU 平均负载：

1
2
3
4


rknn_init(&ctx, model_data, model_size, 0, nullptr); // 加载 INT8 量化 .rknn 模型
rknn_inputs_set(ctx, 1, &in); // 送入 RGA 预处理后的帧
rknn_run(ctx, nullptr);
rknn_outputs_get(ctx, 1, &out, nullptr); // 检测框 / 人脸特征输出

级联	模型	输出
1	YOLO11（INT8）	人体检测框
2	RetinaFace（INT8）	人脸框 + 关键点
3	FaceNet（INT8，敏感层混合量化）	人脸特征向量

人脸比对接口

特征比对走 SQLite 特征库 + 余弦相似度：sqlite3_prepare / step 逐条读取库内 5000+ 人脸特征，与现场提取的特征做余弦相似度计算，超过阈值即判定命中——库内验证命中率 > 98%。命中后经 GPIO 子系统写寄存器拉起门禁继电器，识别通过到开门 < 1s。

线程与队列模型

解码、推理、推流三个环节以生产者-消费者队列隔离：共享缓冲区 + 互斥锁/条件变量保证帧数据线程安全，单路阻塞不拖垮全局链路，端到端延迟 < 200ms，长时间运行无内存泄漏。

项目状态

系统已完成集成与闭环联调，各项指标（识别耗时、端到端延迟、命中率、开门时延）均达标。

冷阴极 X 射线源球壳钛合金焊缝检测装置（下位机）

Tue, 01 Sep 2026 22:30:00 +0800

项目概述

国家重点研发项目子课题：冷阴极 X 射线源球壳钛合金焊缝检测装置的运动控制系统（下位机部分）。

装置通过 X 射线源与平板探测器沿弧形轨道协同扫查，对球壳钛合金焊缝成像检测。下位机负责对 X 射线源、探测器的协同控制与远程控制：配合 QT 上位机调整射线源与探测器的速度与动作，完成单段焊缝、截面焊缝两种检测模式，并实时上报系统状态。

系统组成

flowchart TB
 PC["QT 上位机"] <-->|"RS485 自定义协议帧
UART 中断+DMA · 字节状态机 · 环形缓冲"| MCU["STM32F429 下位机
FreeRTOS 多任务"]
 MCU -->|"Modbus RTU + CRC16"| SERVO["禾川伺服电机驱动器"]
 SERVO --> AXIS["弧形轨道多电机协同"]
 AXIS --> DEV["X 射线源 + 平板探测器"]

整机实拍：左侧为提升立柱与弧形齿轮轨道，右侧为探测器载滑车，地面为多路禾川伺服驱动器与供电线缆。

软件分层与模块

软件分为两层：APP 应用层承载对外协议、运动语义与任务调度；驱动层提供寄存器级能力（Modbus 协议模板与 CRC、电机寄存器配置序列、OLED/菜单/按键、FLASH 参数存储）。

模块	职责
`app_conf.h`	全部可调参数集中管理：协议常量、超时、限幅、软限位、任务栈与优先级、RS485 开关
`host_proto.h/.c`	RS485/USART6 二进制协议栈：TX DMA + 环形缓冲 + 组包 CRC；RX IDLE+DMA + 环形缓冲 + 字节状态机解析；命令分发回调；心跳时间戳；收发统计
`motion_api.h/.c`	统一运动控制接口：轴状态机（IDLE/READY/MOVING/FAULT）、方向（速度符号）/速度（±3000 限幅）/动作时序（松闸稳定→运动→清速减速→抱闸）、编码器事务三重校验、软限位、安全关断收敛入口、故障复位
`dev_task.h/.c`	四大逻辑任务：motionTask（动作执行+ACK）、statusTask（50ms 状态轮询+100ms 状态帧）、monitorTask（心跳超时/故障沿上报/IWDG 喂狗点）、装配函数 `APP_TasksInit()`

软件架构

数据流（下行指令 → 上行状态）

flowchart TB
 PC["上位机"] -->|"A5 5A 协议帧"| RX["USART6 RX
IDLE 中断 + DMA 批量入环形缓冲"]
 RX --> PARSE["parseTask（AboveNormal）
7 态字节状态机 + CRC16 查表校验"]
 PARSE -->|"CRC 通过"| Q["motionQueue
8 深消息队列削峰"]
 Q --> MOTION["motionTask（High）
动作时序执行 + ACK 上行"]
 MOTION -->|"轴级互斥锁串行化"| MB["UART4/5 RS485
Modbus RTU"]
 MB --> DRIVE["禾川伺服驱动器
速度环 + 电流环硬件闭环"]
 DRIVE --> AXIS["弧形轨道双轴电机"]

 STATUS["statusTask（Normal · 50ms）
编码器轮询 + 软限位检查"] --> MB
 STATUS -->|"100ms 状态帧 0x82
TX 环形缓冲 + DMA"| PC
 MON["monitorTask（Normal · 100ms）
心跳超时 / 故障沿 / IWDG"] -->|"SafeShutdown + 0x8F 上报"| MOTION

任务划分

任务	CMSIS 优先级	栈	阻塞点	职责
parseTask	AboveNormal	2KB	线程标志（50ms 超时）	协议解析（状态机+CRC）
motionTask	High	2KB	消息队列（100ms 超时）	动作执行 + 定时动作截止判定
statusTask	Normal	2KB	osDelay(50)	编码器轮询 + 状态反馈
monitorTask	Normal	1.5KB	osDelay(100)	心跳超时/故障沿/安全关断触发
oledShowMenuTask	Low	512B	事件标志	菜单显示（按键扫描定时器 10ms）
defaultTask	Normal	512B	osDelay(1000)	LED 心跳

两个关键的执行体设计：

协议解析与动作执行分离：解析出指令后经 8 深消息队列投递给 motionTask 按序执行，队列削峰保证解析节奏不受动作耗时拖累；
编码器轮询放在任务而非软件定时器中：定时器回调与任务可能并发访问同一 Modbus 通道，统一到任务上下文并配合轴级互斥锁后，「请求-应答」事务被彻底串行化。

任务优先级设计依据

优先级不是按“功能重要性”排的，而是按三条工程准则：

截止期与后果：动作执行（清速/抱闸/安全关断）有硬时序且后果不可逆 → 最高应用优先级；
阻塞特性：事件驱动型任务平时全部阻塞在同步原语上，高优先级只影响唤醒延迟，不产生 CPU 争抢；
依赖方向：数据流上游不能被下游长时间阻塞（parse 喂 motion 的队列；status 的编码器数据被 motion 的轴锁依赖）。

完整优先级谱系（NVIC 中断优先级与任务优先级是两套量纲，勿混）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


NVIC 中断 (任何 ISR 可抢占任何任务)
 ├─ UART4/5/6/8 抢占优先级=5（恰好等于 FreeRTOS 可调用 API 的阈值，
 │ ISR 内允许 FromISR API；只做批量入环形缓冲 + flagsSet，µs 级）
任务 (FreeRTOS 原生优先级，抢占式 + 同级时间片轮转)
 ├─ 38 High motionTask ← 安全动作的执行权最高
 ├─ 31 AboveNormal parseTask ← 必须高于周期型任务，否则状态轮询可推迟命令解析
 ├─ 23 Normal statusTask / monitorTask / defaultTask
 ├─ 8 Low oledShowMenuTask（人机界面，空闲余量处理）
 ├─ 2 Timer Service（按键扫描定时器，CubeMX 默认值）
 └─ 0 Idle

几个关键取舍：

为什么 motion(38) > parse(31)：命令队列已削峰（8 深），解析晚 1–2ms 不影响正确性；反之若 parse 更高，解析长帧期间到达的停止/安全命令会被推迟执行——安全动作的执行权高于协议的解析权。
status/monitor 同级 Normal：两者都是周期型软实时（50ms/100ms），判定窗口（软限位/心跳 500ms）远大于调度延迟；它们持锁时间短（单次 Modbus 事务约 6ms），motion 高优先级被轴锁阻塞时由互斥量优先级继承临时提升持锁任务，消除优先级反转。
关中断快照 vs 互斥量：跨任务读轴状态用 __disable_irq() 短临界区（µs 级、无反转风险）；锁只用于必须串行化的 Modbus 事务（同一 UART 的请求-应答配对）。
一个已知限制：定时器守护任务优先级为 CubeMX 默认值 2，低于所有应用任务——当前成立的条件是所有任务都有周期阻塞点，定时器总能在间隙运行；若未来把安全逻辑放进软件定时器（如限位去抖），必须提高该优先级。
Realtime(47) 刻意留空：为硬实时扩展预留（5–20ms 节拍的位置环、限位 EXTI 的紧急处理链）。

轴状态机

stateDiagram-v2
 [*] --> IDLE
 IDLE --> READY: InitAll（伺服参数+原点捕获+松闸）
 READY --> MOVING: SetSpeed / MoveTimed
 MOVING --> READY: Stop（清速→等减速→抱闸）
 READY --> FAULT: Safe_Shutdown（异常保护）
 MOVING --> FAULT: Safe_Shutdown
 FAULT --> READY: FaultReset（重初始化+重捕获原点+松闸）

任何异常都收敛到单一安全关断入口 MOTION_SafeShutdown()：清速 → 等 150ms（驱动器 100ms 减速斜坡完成，避免高速抱闸冲击）→ 断抱闸继电器 → 锁定 FAULT + 故障码 → monitorTask 沿检测上报。恢复必须显式故障复位指令。

上位机帧协议

帧格式

1
2
3
4


┌──────┬──────┬─────┬──────┬─────────────┬─────────────┬──────────────┐
│ 0xA5 │ 0x5A │ SEQ │ LEN │ CMD │ DATA[LEN] │ CRC16_LO/HI │
└──────┴──────┴─────┴──────┴─────────────┴─────────────┴──────────────┘
 帧头1 帧头2 序号 载荷长 命令字 0~64B 小端 查表 CRC16，低字节先

双帧头 A5 5A：误同步率 1/65536；A5/5A 位翻转丰富，示波器上可辨；
SEQ 序号：下行主机自增（ACK 回显 → 去重/丢帧检测），上行设备独立自增；
LEN 显式变长：状态机据此收数，天然支持命令扩展；
CRC16 覆盖 SEQ..DATA（不含帧头与自身），算法与 Modbus 完全一致（同一张查表），全协议栈一套 CRC；
帧开销 7 字节；载荷中可能出现假帧头，由 CRC 兜底丢弃（更高可靠场景可选 COBS 变长编码）。

命令集

CMD	方向	载荷	语义
0x01	下行	轴号 + 开关	抱闸控制
0x02	下行	轴号 + rpm(int16)	速度指令（符号=方向，±3000 限幅）
0x03	下行	轴号 + rpm + 时长(100ms 单位)	定时动作（动作时序演示）
0x04	下行	轴号（0xFF=全轴）	停止
0x05	下行	seq 回显	心跳（200ms 周期，不回 ACK）
0x06	下行	轴号（0xFF=全部）	故障复位
0x07	下行	无	立即请求状态帧（回 0x82）
0x81	上行	回显命令/序号 + status	命令应答（OK/BUSY/REJECT/BAD_ARG）
0x82	上行	状态字×2 + 双轴速度 + 故障码	周期状态帧（100ms）
0x8F	上行	故障码 + 轴号 + 保留	故障上报（故障沿触发一次）

实例帧（CRC 实算，可直接用于联调）

帧	字节
轴1 速度 -500rpm	`A5 5A 01 03 02 01 FE 0C 55 D7`
轴2 800rpm 转 3.0s	`A5 5A 02 04 03 02 20 03 1E FD CE`
心跳	`A5 5A 03 01 05 5A D2 CB`
状态帧（READY/MOVING，sp1=1500，fault=0x0001）	`A5 5A 10 08 82 01 02 DC 05 00 00 01 00 97 A8`
故障帧（驱动器无应答，轴1）	`A5 5A 11 05 8F 02 00 01 00 00 E2 F4`

解析鲁棒性（7 态状态机 + 三重防护）

LEN > 64 → 丢弃回找头（防超长帧打爆缓冲）；
帧内字节间隔 > 50ms → 强制回找头（防半帧卡死）；
CRC 失败 → 丢当前帧回找头（假同步自愈）；RX 环满 → 丢最新并计数上报统计。

接收链路硬件侧使用 UART 中断 + DMA 不定长接收，以 IDLE 总线空闲事件判帧：

1
2


__HAL_UART_ENABLE_IT(&huart6, UART_IT_IDLE);
/* 帧长 = 接收缓冲区大小 - __HAL_DMA_GET_COUNTER(&hdma_usart6_rx) */

ISR 只做批量搬移入环形缓冲（SPSC 免锁）+ 置线程标志，解析全部在 parseTask 完成——ISR 保持极短是实时性的关键：若在中断里做逐字节处理甚至打印，9600 波特率下一帧即可阻塞几十 ms。

统一运动控制 API

对上层屏蔽多电机与 Modbus 细节，全部运动能力收敛为一组 MOTION_* 接口：

API	语义
`MOTION_InitAll()`	伺服参数写入 + 原点捕获 + 松闸（任务上下文）
`MOTION_SetSpeed(ax, rpm)`	方向=符号；自动先松闸再设速
`MOTION_MoveTimed(ax, rpm, dur)`	速度 + 截止期（定时动作）
`MOTION_Stop(ax)`	清速 → 150ms 减速等待 → 抱闸
`MOTION_Brake(ax, open)`	手动抱闸（运动中拒绝）
`MOTION_Tick()`	定时动作到期判定（100ms 粒度）
`MOTION_PollFeedback()`	双轴编码器轮询 + 无应答计数 + 软限位
`MOTION_GetSnapshot(ax, &s)`	状态/速度/位置/故障原子快照
`MOTION_SafeShutdown(ax, fault)`	安全关断唯一入口
`MOTION_FaultReset(ax)`	FAULT → READY：重初始化 + 重捕获原点 + 松闸

底层由一组寄存器级驱动接口支撑：

1
2
3
4


Motor_Init(MOTOR1); // 初始化：Modbus 链路建立 + 驱动器寄存器配置
openMotor(MOTOR1); // 电机使能
speed_set(MOTOR1, speed); // 速度模式设定：负速度转补码写入，±3000rpm 软件限幅
closeMotor(MOTOR1); // 去使能（配合抱闸继电器安全停机）

Modbus RTU 驱动器接口

功能码	用途
0x03	读保持寄存器（状态/速度回收）
0x06	写单寄存器（速度设定等）
0x10	写多寄存器（批量参数下发）

帧结构：地址(1B) + 功能码(1B) + 数据(NB) + CRC16(2B，低字节在前)
CRC16 参数：多项式 0x8005（反射 0xA001）、初值 0xFFFF，实现查表法与逐位法两种等价算法——上位机协议栈的 CRC 直接复用同一张表
实例帧：01 06 03 03 05 DC → CRC = 7B 47
错误应答识别：功能码 + 0x80
编码器读事务做功能码 + 长度 + CRC 三重校验，连续无应答即触发单轴安全关断

异常保护体系

保护	触发条件	动作
心跳丢失	500ms 无任何合法帧（首帧后生效）	全轴 SafeShutdown + 0x8F 上报
驱动器失联	连续 3 次编码器读无应答/校验失败	单轴 SafeShutdown
软限位	位置超出 ±170°（可配）且运动中	单轴 SafeShutdown
硬限位	EXTI 接口预留（硬件常闭开关已具备）	后续接入 SafeShutdown 链
CRC 错帧	校验失败	丢帧 + 收发统计
IWDG	喂狗点已置于 monitorTask（启用为编译开关）	复位兜底
抱闸 failsafe	硬件特性：断电即抱死	物理兜底

关于伺服三环控制的工程结论

电流环/速度环/位置环要不要在 MCU 里做？——不需要，这是伺服系统的标准级联结构：

位置环（软件，按曲线节拍）→ 速度环（驱动器硬件闭环）→ 电流环（驱动器硬件闭环，µs 级带宽）；
若强行在 MCU 做三环：RS485 半双工往返 + RTOS 任务抖动，内环带宽根本撑不起来，反而劣化性能；
本项目 MCU 只做位置外环：协议与运动接口预留位置指令扩展，速度/电流环交给禾川驱动器。

轨迹跟踪业务层的实现方案：双电机按 FLASH 中的 1000 点位置/速度曲线做 S 曲线协同跟踪——位置 PID + 速度前馈 + 双电机交叉耦合补偿，位置环输出直接写驱动器速度寄存器；上位机经 LoRa 链路完成曲线分块下传（块号 ACK 隐含重传）、误差曲线回读、前馈/耦合系数在线整定与点动控制；限位开关走 EXTI 硬件链路。

已知限制与后续项

驱动器应答等待仍为固定 5ms 盲等，改进方向是信号量 + 超时；
IWDG 未启用（喂狗点与启用步骤已就位，编译开关打开即用）；
硬限位 EXTI 尚未接入软件保护链（常闭开关硬件与 EXTI 驱动已具备，接入方案：ISR 直接抱闸 + 通知任务走 SafeShutdown）；
USART6 波特率 9600，协议帧建议提升到 115200；
printf 复用上位机串口，正式版应以编译开关关闭或改用独立调试口；
位置闭环当前为速度模式的接口预留，轨迹跟踪按上文 S 曲线方案扩展。

项目状态

下位机软件已完成「RS485 协议栈 + 统一运动接口 + 四大逻辑任务 + 多级异常保护」的完整架构实现；驱动层经整机联调实测，Modbus 通信、双轴运动控制、上位机链路稳定工作，支撑完成单段焊缝与截面焊缝检测流程。