企业官网建设流程全解析

RuView ADR-063 解读：60 GHz mmWave 雷达与 WiFi CSI 融合的端侧传感架构

【免费下载链接】RuViewπ RuView turns commodity WiFi signals into real-time spatial intelligence, vital sign monitoring, and presence detection — all without a single pixel of video.项目地址: https://gitcode.com/GitHub_Trending/wi/RuView

导读

本文以 RuView 仓库中的 ADR-063-mmwave-sensor-fusion.md 为骨架，讲解将60 GHz mmWave 雷达（如 Seeed MR60BHA2）与WiFi CSI 被动感知融合为"穿墙覆盖 + 临床级生命体征"双模传感系统的架构决策、UART 自动探测协议、三种部署模式、融合算法与 48 字节融合数据包设计。读完本文，你将掌握：mmWave 传感器在 ESP32 固件中的自动探测与能力注册原理、边缘侧与 RuVector/RuvSense 软件栈的接入点，以及源码中已经落地的加权融合实现与测试验证方式。

背景：为什么 WiFi CSI 需要第二种感知模态

RuView 目前以 WiFi CSI 感知环境——这是一种被动技术，通过分析人体存在与运动对 WiFi 信号造成的扰动来识别活动。其天然优势是穿墙、无需视距（Line of Sight, LoS）。但 CSI 衍生的生命体征（呼吸率、心率）本质上有噪声：它们依赖从多径丰富的 WiFi 信道中做相位提取，因此精度有限。

互补模态是60 GHz mmWave 雷达模块：以主动 FMCW 雷达工作，直接测量呼吸与心率，标称可达临床级精度。这类模块廉价（如 MR60BHA2 约 $15），可用 ESP32-C6/C3 驱动，并直接通过 UART 输出结构化生命体征。

ADR-063 引用了真实的硬件串口日志（COM4，2026-03-15，ESP32-C6 + ESPHome 驱动 MR60BHA2），展示了模块原始输出形态：

[D][sensor:093]: 'Real-time respiratory rate': Sending state 22.00000 [D][sensor:093]: 'Real-time heart rate': Sending state 92.00000 bpm [D][sensor:093]: 'Distance to detection object': Sending state 0.00000 cm [D][sensor:093]: 'Target Number': Sending state 0.00000 [D][binary_sensor:036]: 'Person Information': Sending state OFF [D][sensor:093]: 'Seeed MR60BHA2 Illuminance': Sending state 0.67913 lx

说明：ADR-063 状态为Proposed（提出建议），但从仓库源码看，其中的核心设计已大量落地到固件（firmware/esp32-csi-node/main/下存在mmwave_sensor.c/.h、mmwave_detect.h，并在edge_processing.c中实现了 48 字节 fused vitals 数据包），本文会一并给出实现层面的印证。

融合后的能力对比

ADR-063 用一个对比表论证"1+1 > 2"的机会窗口，这是理解整个架构价值的钥匙：

上述精度数值、覆盖距离与成本均为 ADR 文本中给出的设计预期，应视为该决策文档的论证数据而非仓库已实测的出厂指标。

决策：给固件与感知管线增加 mmWave 雷达支持

ADR-063 的正式决策是：为 RuView 固件与感知管线增加 60 GHz mmWave 雷达支持，具备自动探测与按设备能力注册。

其目标系统架构（融合引擎为核心）如下：

┌─────────────────────────────────────────────────────────┐ │ Sensing Node │ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌────────────┐ │ │ │ ESP32-S3 │ │ ESP32-C6 │ │ Combined │ │ │ │ WiFi CSI │ │ + MR60BHA2 │ │ S3 + UART │ │ │ │ (COM7) │ │ 60GHz mmWave │ │ mmWave │ │ │ │ │ │ (COM4) │ │ │ │ │ │ Passive │ │ Active radar │ │ Both modes │ │ │ │ Through-wall │ │ LoS, precise │ │ │ │ │ └──────┬───────┘ └──────┬───────┘ └─────┬──────┘ │ │ │ │ │ │ │ └────────┬───────────┘ │ │ │ ▼ │ │ │ ┌────────────────┐ │ │ │ │ Fusion Engine │◄──────────────────────┘ │ │ │ │ │ │ │ • Kalman fuse │ Vitals packet (extended): │ │ │ • Cross-validate│ magic 0xC5110004 │ │ │ • Ground-truth │ + mmwave_hr, mmwave_br │ │ │ calibration │ + mmwave_distance │ │ │ • Fall confirm │ + mmwave_target_count │ │ └────────────────┘ + confidence scores │ └─────────────────────────────────────────────────────────┘

三种部署模式

固件落地的自动探测协议（源码级）

ADR 提出固件启动时自动探测 mmWave 模块的三步协议：UART 探测 → 协议识别 → 能力注册。这一设计已完整实现在 firmware/esp32-csi-node/main/mmwave_sensor.c 中。

UART 探测：校验整个帧，而非匹配头字节

mmwave_sensor.c的probe_at_baud()会先在115200 波特率（MR60BHA2）探测，失败后切换256000 波特率（LD2410）。关键的健壮性细节（源码注释中明确标注了 issue #1107 与 #1135）是：绝不因看到裸的帧头字节就判定检测成功——空闲悬空的 UART 线上，噪声本身就包含大量0x01（MR60 SOF）或0xF4F3F2F1（LD2410 帧头），旧实现因此出现过"幽灵探测"。

探测判定因此收紧为：

• MR60BHA2：要求通过头校验和~XOR(bytes 0..6) == byte 7，且帧类型落在已知集合(type >> 8) == 0x0A || type == 0x0F09，连续命中 ≥3 个有效头才判定为 MR60BHA2；
• LD2410：调用 firmware/esp32-csi-node/main/mmwave_detect.h 中的纯函数mmwave_ld2410_valid_at()，要求"帧头F4F3F2F1+ 合理帧长（1~64）+ 完整匹配帧尾F8F7F6F5"，连续命中 ≥2 帧才判定为 LD2410。

这个"校验整个帧"的谓词被打包进一个无 ESP-IDF 依赖的头文件，以便宿主机直接单测。对应的 firmware/esp32-csi-node/test/test_mmwave_detect.c 验证了五个场景：合法 basic 帧（len=13）与 engineering 帧（len=35）被接受；只有帧头无帧尾的噪声被拒绝（#1135 幽灵场景）；帧长过大的畸形帧被拒绝；纯噪声被拒绝。

支持的多传感器家族

ADR 文档列出的支持矩阵如下（成本为文档论证值）：

固件目前已落地 MR60BHA2 与 LD2410 两条解析路径，并把传感器类型建模为枚举mmwave_type_t（NONE/MR60BHA2/LD2410/MOCK），详见 mmwave_sensor.h。

能力注册：mmwave_state_t 状态结构

ADR 用 C 结构体定义了能力注册与最新读数共享状态；源码mmwave_sensor.h用能力位掩码 + 状态快照的等价形式落地：

/* ---- Capability flags ---- */ #define MMWAVE_CAP_HEART_RATE (1 << 0) #define MMWAVE_CAP_BREATHING (1 << 1) #define MMWAVE_CAP_PRESENCE (1 << 2) #define MMWAVE_CAP_DISTANCE (1 << 3) #define MMWAVE_CAP_FALL (1 << 4) #define MMWAVE_CAP_MULTI_TARGET (1 << 5) /* ---- Shared mmWave state (updated by background task) ---- */ typedef struct { mmwave_type_t type; /**< Detected sensor type. */ uint16_t capabilities; /**< Bitmask of MMWAVE_CAP_* flags. */ bool detected; /**< True if sensor responded on UART. */ float heart_rate_bpm; /**< Heart rate in BPM (0 if unavailable). */ float breathing_rate; /**< Breathing rate in breaths/min. */ bool person_present; /**< True if person detected. */ float distance_cm; /**< Distance to nearest target in cm. */ uint8_t target_count; /**< Number of detected targets. */ uint32_t frame_count; /**< Total parsed frames since boot. */ uint32_t error_count; /**< Parse errors / CRC failures. */ int64_t last_update_us; /**< Timestamp of last valid frame. */ } mmwave_state_t;

探测成功后按传感器家族写入对应能力位（MR60BHA2 → 心率|呼吸|存在|距离；LD2410 → 存在|距离），随后启动一个FreeRTOS 后台任务（mmwave_uart_task）持续喂字节给对应解析器，并把结果更新进共享状态。公共 API 为：

• esp_err_t mmwave_sensor_init(int uart_tx_pin, int uart_rx_pin)——初始化时探测 UART，-1表示使用默认引脚（TX=17 / RX=18）；
• bool mmwave_sensor_get_state(mmwave_state_t *state)——线程安全的快照拷贝；
• const char *mmwave_type_name(mmwave_type_t type)——类型名。

在 main.c 中，main会以mmwave_sensor_init(-1, -1)尝试初始化，并根据返回值打印mmWave sensor: MR60BHA2 (caps=0x...)...或No mmWave sensor detected (CSI-only mode)——即 mmWave 为可选增强，探测不到时整机自动退回纯 CSI 模式。

QEMU Mock 路径

在CONFIG_CSI_MOCK_ENABLED（QEMU 测试构建）下，mmwave_sensor.c会用mock_mmwave_task以1 Hz（与真实 MR60BHA2 上报频率一致）合成带正弦波动的 HR≈72、BR≈16 生命体征，并支持在固定 tick 区间模拟"人员离开"场景——让无硬件的 CI/宿主机也能打通融合管线测试。

协议解析原理

MR60BHA2 采用 Seeed mmWave 帧协议，源码中给出了字节级格式：

[0] SOF = 0x01 [1-2] Frame ID (uint16, big-endian) [3-4] Data Length (uint16, big-endian) [5-6] Frame Type (uint16, big-endian) [7] Header Checksum = ~XOR(bytes 0..6) [8..N] Payload (N = data_length) [N+1] Data Checksum = ~XOR(payload bytes)

解析器按状态机推进（MR60_WAIT_SOF → MR60_READ_HEADER → MR60_READ_DATA → MR60_READ_DATA_CKSUM），帧类型与含义对应：

• 0x0A13Phase /0x0A14呼吸率（payload 内 float32，范围校验 0~60 BPM）
• 0x0A15心率（float32，范围校验 0~250 BPM）
• 0x0A16距离（首 4 字节为 range flag，非 0 才有效）
• 0x0F09presence（payload[0] 非 0 即有人）

LD2410 的普通上报帧则解析target_state / moving_dist / moving_energy / static_dist / static_energy / detect_dist，并据target_state在运动/静止距离之间选择distance_cm。

融合算法设计

ADR-063 定义了四类融合算法，它们决定了融合引擎的语义：

1. 生命体征融合（Kalman 滤波）

mmWave HR (high confidence, 1 Hz) ─┐ ├─► Kalman fuse → fused HR ± confidence CSI-derived HR (lower confidence) ─┘

在固件实现中，edge_processing.c 采用等价但更轻量的加权平均方案（Kalman 化的工程近似）：当 mmWave 与 CSI 心率都有效时fused_hr = mmwave * 0.8 + csi * 0.2，fusion_confidence = 90；只有 mmWave 时直接用其读数（confidence 85）；仅 CSI 时回退到 CSI 读数（confidence 50）。呼吸率同理。

2. 跌倒检测（双确认）

CSI phase accel > thresh ──────┐ ├─► AND gate → confirmed fall (near-zero false positives) mmWave range-velocity pattern ─┘

双确认的前提是"两个独立传感器同时断言"，这也是 ADR 宣称"近零误报"的逻辑基础。

3. 存在检测（加权投票）

CSI adaptive threshold ────┐ ├─► Weighted vote → robust presence mmWave target count > 0 ──┘

CSI 侧已有的存在检测本身带自适应阈值校准与迟滞（见 edge_processing.h 中EDGE_PRESENCE_HYST_RATIO、EDGE_PRESENCE_CLEAR_FRAMES及 60s 环境学习EDGE_CALIB_FRAMES）；mmWave 提供了独立的 target count 证据参与投票。

4. 训练校准

mmWave ground-truth vitals → train CSI BVP extraction model mmWave distance → calibrate CSI triangulation mmWave micro-Doppler → label CSI activity patterns

这为 RuVector 的 BVP/呼吸提取模块提供真值参考信号。

Vitals 数据包扩展：从 32 字节到 48 字节

既有 32 字节 vitals 包（magic0xC5110002）

固件 Tier 2 的既有生命体征包格式定义在 edge_processing.h 中（edge_vitals_pkt_t，_Static_assert校验为 32 字节），字段包括：magic / node_id / flags(Bit0=presence,Bit1=fall,Bit2=motion) / breathing_rate(BPM*100) / heartrate(BPM*10000) / rssi / n_persons / motion_energy / presence_score / timestamp_ms。

新的 48 字节 fused vitals 包（magic0xC5110004）

ADR-063 设计在其后追加 16 字节 mmWave 字段，形成 48 字节的edge_fused_vitals_pkt_t：

typedef struct __attribute__((packed)) { /* First 32 bytes match edge_vitals_pkt_t layout */ uint32_t magic; /* EDGE_FUSED_MAGIC = 0xC5110004 */ uint8_t node_id; uint8_t flags; /* Bit0=presence, Bit1=fall, Bit2=motion, Bit3=mmwave_present */ uint16_t breathing_rate; /* Fused BPM * 100 (CSI + mmWave) */ uint32_t heartrate; /* Fused BPM * 10000 */ int8_t rssi; uint8_t n_persons; uint8_t mmwave_type; /* mmwave_type_t enum */ uint8_t fusion_confidence; /* 0-100 fusion quality score */ float motion_energy; float presence_score; uint32_t timestamp_ms; /* mmWave extension (16 bytes) */ float mmwave_hr_bpm; /* Raw mmWave heart rate */ float mmwave_br_bpm; /* Raw mmWave breathing rate */ float mmwave_distance; /* Distance to nearest target (cm) */ uint8_t mmwave_targets; /* Target count from mmWave */ uint8_t mmwave_confidence; /* mmWave signal quality 0-100 */ uint16_t reserved3; uint32_t reserved4; /* Pad to 48 bytes for alignment */ } edge_fused_vitals_pkt_t; _Static_assert(sizeof(edge_fused_vitals_pkt_t) == 48, "fused vitals must be 48 bytes");

该结构体已完整落地于 edge_processing.h。关键设计是前 32 字节与既有edge_vitals_pkt_t布局完全一致，服务端解析器可以向后兼容地读取；差异点在于reserved字段被复用为mmwave_type与fusion_confidence。

发送路径（源码级）

在 edge_processing.c 的 vitals 发送函数中，逻辑是：

1. 查询mmwave_sensor_get_state(&mw)；
2. 若 mmWave 已检测且活跃，则组装 fused 包：拷贝 32 字节基座字段，flags加上Bit3=mmwave_present（fpkt.flags |= 0x08），写入加权融合后的heartrate / breathing_rate，再把原始 mmWave 读数（mmwave_hr_bpm / mmwave_br_bpm / mmwave_distance / mmwave_targets）一并放入以便服务端做离线分析；
3. mmwave_confidence依据已解析帧数粗略打分：frame_count > 10 ? 80 : 40；
4. 无 mmWave 时照常发送标准 32 字节包。

服务端解析支持

Rust 侧解析器 v2/crates/wifi-densepose-hardware/src/esp32_parser.rs 已经登记了全部 magic 号，其中RUVIEW_FUSED_VITALS_MAGIC = 0xC5110004被注释明确标注为 "ADR-063 fused-vitals packet (multi-sensor fusion)"，命名映射函数返回"ADR-063 fused vitals"。这意味着服务端按 magic 分发已具备识别 fused 包的能力，正是 ADR Consequence 中"48 字节包需要服务端解析器更新"一节的实现证据。

NVS 配置与预置参数

ADR 给出了新的预置参数草案（provision.py风格）：

python provision.py --port COM7 \ --mmwave-uart-tx 17 --mmwave-uart-rx 18 \ # UART pins for mmWave module --mmwave-type auto \ # auto-detect, or: mr60bha2, ld2410, etc. --fusion-mode kalman \ # kalman, vote, mmwave-primary, csi-primary --fall-dual-confirm true # require both CSI + mmWave for fall alert

其中--fusion-mode的可选策略（kalman / vote / mmwave-primary / csi-primary）与 ADR 的三种融合语义一一对应。固件侧 mmWave UART 默认引脚与 ADR 草案一致（TX=17 / RX=18，见mmwave_sensor.c的mmwave_sensor_init中对负值的默认处理）。ADC 状态也体现在 main.c 的启动横幅中，会列出mmWave=active/off。

RuVector 与 RuvSense 的接入点

ADR-063 将 mmWave 视为既有软件栈的"高质量参考信号源"，而非孤立的新外设。

RuVector v2.0.4 融合接入（ADR-016 已集成）

仓库中可找到对应信号处理模块，例如v2/crates/wifi-densepose-ruvector/src/signal/bvp.rs与v2/crates/wifi-densepose-signal/src/bvp.rs承载 BVP/呼吸/心率的滤波估计，是上述"被 mmWave 真值校准"的直接对象。

RuvSense 多基地管线接入（ADR-029）

"提前 100-200ms 检出预动作"为 ADR 的设计论述数据，非仓库实测基准。

Cross-Viewpoint 融合扩展

视角融合管线（ruvector/src/viewpoint/）同样自然延伸：mmWave range 作为 attention 机制中新的"视角"（attention.rs）；mmWave 锥形几何计入 Fisher Information / Cramer-Rao 界（geometry.rs）；mmWave 相位相干性校验 WiFi phasor 相干性（coherence.rs）；mmWave 节点以带自身领域事件的多基地阵列成员加入（fusion.rs）。

实现阶段与影响分析

ADR-063 规划的落地阶段（供 roadmap 参考）：

对照源码可以看到，Phase 1 的 MR60BHA2/LD2410 解析 + 自动探测、Phase 2 的 48 字节 fused 包与加权融合均已落地（含 QEMU mock 测试路径）；Phase 4 之后（MR60FDA1/MR24HPC1/LD2450 家族、服务端融合）目前仍停留在 ADR 规划层面。

正面影响

• 跌倒检测双确认 → 近零误报；
• 有 mmWave 时获得临床级生命体征，CSI 作为回退；
• 用 mmWave 真值实现 CSI 管线自校准；
• 向后兼容——既有纯 CSI 节点无需改动即可工作；
• 增量成本低（每模块约 $3-15）；
• 自动探测让受支持传感器零配置；
• RuVector attention/solver/temporal-tensor 模块获得高质量参考信号。

负面影响

• 固件复杂度增加（mmWave 状态 + UART 缓冲约 2-3 KB RAM）；
• mmWave 需要视距（是对 CSI 的补充而非替代）；
• 需要维护多套 UART 协议（Seeed、HLK 家族）；
• 48 字节 fused 包要求服务端解析器更新（仓库中esp32_parser.rs已登记0xC5110004即对应处理）。

中性影响

• ESP32-C6（单核 RISC-V）无法跑完整 CSI 管线，但可作专用 mmWave 桥接节点；
• mmWave 模块每节点增加约 15 mA 功耗。

落地证据清单

延伸阅读

• 生命体征提取链路与边缘处理说明：firmware/esp32-csi-node/README.md
• 相关决策：RuvSense 多基地模式 ADR-029、Coherent Human Channel Imaging ADR-042、边缘智能 ADR-039、生命体征提取 ADR-021

【免费下载链接】RuViewπ RuView turns commodity WiFi signals into real-time spatial intelligence, vital sign monitoring, and presence detection — all without a single pixel of video.项目地址: https://gitcode.com/GitHub_Trending/wi/RuView