RuView 快速上手Docker 模拟、源码构建与 ESP32 硬件接入三条启动路径详解【免费下载链接】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/RuViewRuViewπ RuView / WiFi-DensePose是一个把普通 WiFi 信号CSIChannel State Information转化为空间智能与生命体征感知的开源平台无需摄像头即可完成存在检测、呼吸/心率测量、17 关键点姿态估计与环境指纹建模。本文围绕仓库中的 Codex 上手指引文档 ruview-start.md 展开系统讲解它的docker、build、hardware三条启动路径如何在无硬件时用 Docker 体验完整 UI、如何从源码构建并通过确定性证明验证、如何将 ESP32-S3/C6 固件烧录并接入实时 CSI 数据流同时明确 ESP32-C3 不支持、单节点空间分辨率有限、相机无监督姿态精度边界等关键警告。读完本文你可以独立完成从零到跑通实时 WiFi 感知的全过程并清楚每一步的验证标准与失败排查方向。一、/ruview-start是什么面向 AI Agent 的引导入口/ruview-start是 RuView 内置插件体系Claude Code 插件与 Codex prompt 镜像中的第一个入口命令其职责是帮助用户快速 onboard 到 RuView。在仓库中这套引导逻辑以 Markdown 提示词的形式维护在 plugins/ruview/codex/prompts/ 目录下共有 8 个/ruview-*命令Prompt 文件命令职责ruview-start.md/ruview-start上手指引选择 docker / build / hardware 路径ruview-flash.md/ruview-flash构建并烧录 ESP32 固件ruview-provision.md/ruview-provision写入 ESP32 节点 NVS 配置ruview-app.md/ruview-app运行感知应用presence / vitals / pose 等ruview-train.md/ruview-train训练 / 评估 / 发布模型ruview-advanced.md/ruview-advanced多基地 / 层析 / 跨视角 / 网格安全ruview-verify.md/ruview-verify测试 确定性证明 见证包ruview-rvagent.md/ruview-rvagentrvagent MCP 桥接它的调用约定非常明确/ruview-start接收一个参数$ARGUMENTS取值必须是三者之一——docker、build、hardware如果参数为空Agent 会先询问用户手头有哪些硬件再据此推荐路径。这种先问硬件、再分派路径的设计使同一个引导命令能同时服务只想体验的评估者与准备部署的开发者。在 Codex 中使用时把 plugins/ruview/codex/prompts/ 下的 prompt 文件复制到~/.codex/prompts/即可激活全部命令项目规则由 plugins/ruview/codex/AGENTS.md 承载详见 plugins/ruview/codex/README.md。这些命令本身是只读引导——它们告诉 Agent 该执行哪些命令、按什么顺序、以什么标准判定成功是理解整个项目操作流程的最佳入口。二、路径一Docker 快速体验无需任何硬件对于没有 ESP32 硬件、只想快速评估 RuView 能力的用户/ruview-start给出的第一条路径是官方 Docker 镜像docker pull ruvnet/wifi-densepose:latest docker run -p 3000:3000 ruvnet/wifi-densepose:latest # 打开 http://localhost:3000两条命令即可启动完整系统。关键设计点是Docker 镜像内置了模拟 CSIsimulated CSI数据源因此即使没有真实 WiFi 传感硬件浏览器打开http://localhost:3000后也能看到完整的 UI——存在检测、生命体征、房间状态等前端可视化全部可用。这正是项目先演示、后部署的评估路线该命令与 README.md 的 Quick Start 中 Option 1 完全一致。适用场景与边界适合功能评估验证 UI 交互、理解数据呈现方式、试用感知应用的前端逻辑适合无硬件环境CI 冒烟、教学演示、给非技术干系人展示需要注意Docker 跑的是模拟数据不代表真实 CSI 精度。真实的存在检测、生命体征、穿墙感知能力依赖 ESP32-S3 等 CSI 硬件——README 明确提示 The Docker image runs with simulated data for evaluation。三、路径二从源码构建并完成确定性验证/ruview-start的build路径面向需要阅读源码、二次开发或参与贡献的开发者核心是构建 可复现证明两步# 第一步在 v2 Rust 工作区运行完整测试跳过默认特性 cd v2 cargo test --workspace --no-default-features # 第二步运行确定性管道证明必须输出 VERDICT: PASS cd .. python archive/v1/data/proof/verify.py # 可选单 crate 健全性检查 cargo check -p wifi-densepose-train --no-default-features3.1 v2 Rust 工作区v2/是当前主代码库由 v2/Cargo.toml 定义的 workspace 管理包含数十个成员 crate与引导相关的核心 crate 包括wifi-densepose-sensing-serverAxum 实现的实时感知服务器REST WebSocket既消费 ESP32 UDP CSI 流也是--model、--embed、--build-index等模型能力入口wifi-densepose-train模型训练 crate/ruview-train的目标wifi-densepose-vitals生命体征提取呼吸 6–30 BPM、心率 40–120 BPMwifi-densepose-signal信号处理与特征提取wifi-densepose-ruvectorRuVector 融合多基地跨视角嵌入、图算法。--no-default-features的作用是避免拉入需要外部运行时如 CUDA 等的默认特性使纯 CPU 环境下也能完整编译与测试这是 CI 与无 GPU 开发机上的标准做法。3.2 信任终止开关verify.py 到底验证什么python archive/v1/data/proof/verify.py被项目称为Trust Kill Switch信任终止开关它把管道是真实可复现的这一声明变成可证伪、可度量的检验。从 verify.py 源码看其执行流程是加载公开的参考 CSI 信号sample_csi_data.json该信号由generate_reference_signal.py生成的确定性合成信号取前 100 帧约 1 秒逐帧喂给生产环境的真实管道——src.hardware.csi_extractor.CSIData与src.core.csi_processor.CSIProcessor调用preprocess_csi_data()与extract_features()而非任何测试替身脚本会打印SOURCE PROVENANCE用inspect.getfile输出实际导入模块的绝对路径供人工核对将 5 类特征amplitude_mean、amplitude_variance、phase_difference、correlation_matrix、power_spectral_density序列化为规范字节流计算 SHA-256与仓库提交的expected_features.sha256比对输出VERDICT: PASS / FAIL。实现上还有两个值得注意的细节量化精度特征在打包前会按PROOF_HASH_DECIMALS默认 6 位小数四舍五入。原因是 scipy.fft 的 pocketfft 内核在不同 CPU 微架构Intel AVX2/AVX-512 vs ARM NEON下会重排浮点约简顺序使原始哈希跨平台发散——量化 6 位小数约高出观测到的 ULP 漂移 6 个数量级同时远低于任何有信号意义的变化CSI 相位精度约 1e-3 rad。跨平台容差兜底doppler_shift特征因峰值归一化argmax在近并列峰下不稳定而被有意排除在哈希之外同时若位精确哈希因微架构差异不匹配脚本还会将全精度特征向量与提交的expected_features_reference.npz做rtol1e-4 / atol1e-6的相对容差比对两者任一通过即判定 PASS。此外verify.py --audit会扫描生产代码中是否存在np.random.*、unittest.mock、MagicMock等随机/模拟模式排除测试目录从代码考古层面佐证管道不是 mock。如果因合法的 numpy/scipy 升级导致哈希不匹配可运行python archive/v1/data/proof/verify.py --generate-hash重新生成基准前提是确认改动确实改变了数值输出。3.3 单 crate 健全性检查cargo check -p wifi-densepose-train --no-default-features用于只检查单个 crate 能否编译不做完整链接与测试是修改训练相关代码时最快的反馈回路。/ruview-verify的完整验证范围还包括cargo test -p wifi-densepose-signal --no-default-features等单 crate 测试以及bash scripts/generate-witness-bundle.sh生成的见证包dist/witness-bundle-ADR028-sha.tar.gz内含 WITNESS-LOG-028.md、ADR-028 审计、proof、Rust 测试日志、固件哈希清单等解包后bash VERIFY.sh须 7/7 PASS。四、路径三ESP32 硬件实时感知hardware路径面向有真实硬件的用户推荐组合是ESP32-S3约 $9或 ESP32-C6WiFi 6 研究节点约 $6–10。完整链路为/ruview-flash烧录固件 →/ruview-provision写入网络与感知配置 →cargo run -p wifi-densepose-sensing-server消费 UDP CSI 流。以下按顺序拆解。4.1 第一步烧录固件/ruview-flash/ruview-flash支持三种固件变体8mb默认从sdkconfig.defaults.template构建真实 WiFi CSI无 mock4mb先复制sdkconfig.defaults.4mb为sdkconfig.defaults关闭显示、经partitions_4mb.csv双 OTAheltec使用sdkconfig.defaults.heltec_n16r2。构建需 ESP-IDF v5.4 环境Windows 下注意不能用 Git Bash 直接跑idf.py会挂起应使用 Espressif Python venv 子进程并剥离MSYSTEM*环境变量。构建产物位于firmware/esp32-csi-node/build/bootloader/bootloader.bin、partition_table/partition-table.bin、esp32-csi-node.bin、ota_data_initial.bin。烧录以 Windows COM8 为例Linux/macOS 将端口改为/dev/ttyUSB0等python -m esptool --chip esp32s3 --port COM8 --baud 460800 write_flash \ 0x0 firmware/esp32-csi-node/build/bootloader/bootloader.bin \ 0x8000 firmware/esp32-csi-node/build/partition_table/partition-table.bin \ 0xf000 firmware/esp32-csi-node/build/ota_data_initial.bin \ 0x20000 firmware/esp32-csi-node/build/esp32-csi-node.bin烧录后用 pyserial 在 115200 波特率打开串口监控idf.py monitor在子进程场景会挂起确认固件启动。关键纪律不要用 mock 模式测试固件——Kconfig 回退阈值 bug 只在真实 CSI 下才会暴露/ruview-flash原话Never test in mock mode。4.2 第二步写入 NVS 配置/ruview-provision节点固件烧录后是裸的需要把 WiFi 凭据、数据接收端sink地址、感知参数写入 NVS 分区。推荐使用仓库中的 scripts/provision.pypython scripts/provision.py --port COM8 \ --ssid SSID --password PW --target-ip SINK_IP --target-port 5005 --node-id 0-255 \ [--channel N] [--filter-mac AA:BB:CC:DD:EE:FF] [--hop-channels 1,6,11 --hop-dwell 200] \ [--tdm-slot i --tdm-total n] [--edge-tier 0|1|2] [--pres-thresh 50] [--fall-thresh 15000] \ [--vital-win 300] [--vital-int 1000] [--subk-count 32] \ [--seed-url http://10.1.10.236 --seed-token bearer --zone lobby] [--swarm-hb 30] [--swarm-ingest 5] [--dry-run]核心参数取舍来自/ruview-provision的 trade-off 说明参数作用取舍--channel N固定节点到单一 WiFi 信道应设为 AP 实际信道信号更稳定固定后失去跳频带宽--hop-channels 1,6,11启用多频带跳频调度更多感知带宽借用邻居 AP 作照明源配合--hop-dwell设置每信道驻留毫秒数--filter-mac MAC只捕获指定发射器的 CSI信号更干净省略则捕获所有发射器数据更多但噪声更多--edge-tier 0/1/2关闭 / 统计 / 生命体征ADR-041越高越耗电能力越强--tdm-slot / --tdm-total多节点网格时隙编排多个 ESP32 组网时避免互相干扰--fall-thresh 15000跌倒检测阈值 ≈ 15.0 rad/s²调高可减少误报跌倒--pres-thresh 50存在检测阈值灵敏度调节--dry-run只生成 NVS 镜像不烧录上线前安全演练重要警告Issue #391烧录会重写整个csi_cfgNVS 命名空间——所有未在命令行中给出的键都会被擦除。因此对已正常工作的节点重新 provisioning 前必须三思且应一次性传全所需参数集--force-partial允许在无 WiFi 凭据的情况下写配置需明确知情。验证节点是否工作串口监控应看到adaptive_ctrl心跳与csi_collector: CSI cb #… len128 rssi… ch…行数据接收端应报告有 UDP 帧到达。若无帧按顺序排查信道不匹配、MAC 过滤过紧、--target-ip不是本机、WiFi 凭据错误。4.3 第三步运行感知服务器消费 CSIcd v2 cargo run -p wifi-densepose-sensing-server感知服务器在本地监听 UDP CSI 流默认 sink 端口 5005provision 时以--target-ip/--target-port指向运行本命令的主机解析后执行存在检测、生命体征提取等感知逻辑。多节点组网时建议 2 个以上 ESP32 节点以获得更好的空间分辨率或进一步叠加 Cognitum Seed持久向量存储 kNN 见证链。与 ESP32 配套的常用实时工具还包括node scripts/rf-scan.js --port 5006 # 实时 RF 房间扫描 node scripts/snn-csi-processor.js --port 5006 # SNN 实时学习脉冲神经网络这两个 Node 脚本分别在 5006 端口消费 CSI 流前者做房间级射频指纹/扫描后者用 SNN 做环境自适应学习——它们在 README.md 的 Full system with Cognitum Seed 方案Option 3中也被列为标准组件。五、必须知晓的边界与警告/ruview-start明确要求 Agent 在引导用户时主动警告以下事项这也是评估部署方案的硬边界ESP32-C3 与初代 ESP32 不受支持两者均为单核无法胜任 CSI 数字信号处理。硬件选型应从 ESP32-S3 / ESP32-C6 起步固件目标选择与 C6 的 HE-LTF 子载波标记、802.15.4 网格时间同步等扩展能力见 ADR-110-REVIEW-GUIDE.md 与firmware/esp32-csi-node/的 sdkconfig 变体。单节点空间分辨率有限单个 ESP32 提供的是单天线 56 子载波的 CSI 流细粒度空间信息有限。文档建议使用 2 个以上节点多基地跨视角融合对应wifi-densepose-ruvectorcrate 的跨视角机制或添加 Cognitum Seed 以获得持久记忆与更强的空间模型。相机自由姿态精度是温和的引导文档注明相机监督训练camera-supervised training可达到 92.9% PCK20ADR-079-camera-ground-truth-training.md但与此同时README 的 Beta 声明与模型权重诚实标注指出未经相机监督的实时单 ESP32 姿态模型仍属first-cut水平板上模型 PCK20 仅约 3.0%运行时路径还是confidence0的占位 stubADR-079 的目标基线是 ≥35% PCK20 且数据采集/评估阶段仍未完成。因此对纯 WiFi、无相机、实时 17 关键点姿态能力务必以 README 的诚实标注为准不要按宣传口径夸大。需要姿态精度的场景正确路径是自行采集配对数据并用/ruview-train训练。无云、无相机、无互联网依赖整套系统在边缘运行ESP32 节点 边缘主机即可构成闭环隐私设计上天然规避视频类合规问题。六、上手之后标准工作流与参考文档完成三条路径中任意一条后/ruview-start会把用户引导到后续命令与配置工作流/ruview-app运行具体感知应用。presence / vitals / pose / environment走wifi-densepose-sensing-server环境模式追加-- --model model.rvf --build-index envsleep走 examples/sleep/ 与node scripts/apnea-detector.jsmat灾难幸存者检测走wifi-densepose-matcrate 与 wifi-mat-user-guide.mdpointcloud走 mmwave_fusion_bridge.py。无硬件时回退到 Docker 演示或python examples/ruview_live.py可视化可用node scripts/csi-spectrogram.js、node scripts/csi-graph-visualizer.js。/ruview-train训练、评估、发布模型含 GCloud GPU 训练。/ruview-verify完整信任流水线——testscargo test --workspace --no-default-features要求 1400 通过、0 失败→proofverify.py输出VERDICT: PASS→bundle见证包VERIFY.sh7/7 PASS。代码变更后按 CLAUDE.md 的 pre-merge 清单逐项走查。配置工作流sdkconfig 变体选择8mb / 4mb / heltec、NVS provisioning、边缘模块edge modules、多节点网格mesh、Cognitum Seed 集成。继续深入时按需查阅以下文档均以仓库根为基准docs/user-guide.md安装、首次运行、API、硬件、训练、docs/TROUBLESHOOTING.md故障排查、docs/ADR-079-camera-ground-truth-training.md相机监督训练与姿态精度目标、plugins/ruview/README.md插件体系全貌以及 examples/ 下的环境/医疗/睡眠/压力/幸福向量等可运行示例。七、小结/ruview-start的三条路径构成了一个清晰的决策树无硬件 → Docker 模拟体验要开发/贡献 → 源码构建 Trust Kill Switch 确定性验证有 ESP32 → 烧录 → provision → 实时感知。对 AI Agent 而言这是一份可直接执行的、带明确成功判据VERDICT: PASS、串口CSI cb行、UDP 帧到达的引导协议对开发者而言它是理解整个 RuView 操作面与诚实能力边界的最佳入口。部署前请务必重读第五节的硬件与精度边界——这决定了你的感知方案能真实交付什么能力。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 RuView 快速上手：Docker 模拟、源码构建与 ESP32 硬件接入三条启动路径详解
RuView 快速上手Docker 模拟、源码构建与 ESP32 硬件接入三条启动路径详解【免费下载链接】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/RuViewRuViewπ RuView / WiFi-DensePose是一个把普通 WiFi 信号CSIChannel State Information转化为空间智能与生命体征感知的开源平台无需摄像头即可完成存在检测、呼吸/心率测量、17 关键点姿态估计与环境指纹建模。本文围绕仓库中的 Codex 上手指引文档 ruview-start.md 展开系统讲解它的docker、build、hardware三条启动路径如何在无硬件时用 Docker 体验完整 UI、如何从源码构建并通过确定性证明验证、如何将 ESP32-S3/C6 固件烧录并接入实时 CSI 数据流同时明确 ESP32-C3 不支持、单节点空间分辨率有限、相机无监督姿态精度边界等关键警告。读完本文你可以独立完成从零到跑通实时 WiFi 感知的全过程并清楚每一步的验证标准与失败排查方向。一、/ruview-start是什么面向 AI Agent 的引导入口/ruview-start是 RuView 内置插件体系Claude Code 插件与 Codex prompt 镜像中的第一个入口命令其职责是帮助用户快速 onboard 到 RuView。在仓库中这套引导逻辑以 Markdown 提示词的形式维护在 plugins/ruview/codex/prompts/ 目录下共有 8 个/ruview-*命令Prompt 文件命令职责ruview-start.md/ruview-start上手指引选择 docker / build / hardware 路径ruview-flash.md/ruview-flash构建并烧录 ESP32 固件ruview-provision.md/ruview-provision写入 ESP32 节点 NVS 配置ruview-app.md/ruview-app运行感知应用presence / vitals / pose 等ruview-train.md/ruview-train训练 / 评估 / 发布模型ruview-advanced.md/ruview-advanced多基地 / 层析 / 跨视角 / 网格安全ruview-verify.md/ruview-verify测试 确定性证明 见证包ruview-rvagent.md/ruview-rvagentrvagent MCP 桥接它的调用约定非常明确/ruview-start接收一个参数$ARGUMENTS取值必须是三者之一——docker、build、hardware如果参数为空Agent 会先询问用户手头有哪些硬件再据此推荐路径。这种先问硬件、再分派路径的设计使同一个引导命令能同时服务只想体验的评估者与准备部署的开发者。在 Codex 中使用时把 plugins/ruview/codex/prompts/ 下的 prompt 文件复制到~/.codex/prompts/即可激活全部命令项目规则由 plugins/ruview/codex/AGENTS.md 承载详见 plugins/ruview/codex/README.md。这些命令本身是只读引导——它们告诉 Agent 该执行哪些命令、按什么顺序、以什么标准判定成功是理解整个项目操作流程的最佳入口。二、路径一Docker 快速体验无需任何硬件对于没有 ESP32 硬件、只想快速评估 RuView 能力的用户/ruview-start给出的第一条路径是官方 Docker 镜像docker pull ruvnet/wifi-densepose:latest docker run -p 3000:3000 ruvnet/wifi-densepose:latest # 打开 http://localhost:3000两条命令即可启动完整系统。关键设计点是Docker 镜像内置了模拟 CSIsimulated CSI数据源因此即使没有真实 WiFi 传感硬件浏览器打开http://localhost:3000后也能看到完整的 UI——存在检测、生命体征、房间状态等前端可视化全部可用。这正是项目先演示、后部署的评估路线该命令与 README.md 的 Quick Start 中 Option 1 完全一致。适用场景与边界适合功能评估验证 UI 交互、理解数据呈现方式、试用感知应用的前端逻辑适合无硬件环境CI 冒烟、教学演示、给非技术干系人展示需要注意Docker 跑的是模拟数据不代表真实 CSI 精度。真实的存在检测、生命体征、穿墙感知能力依赖 ESP32-S3 等 CSI 硬件——README 明确提示 The Docker image runs with simulated data for evaluation。三、路径二从源码构建并完成确定性验证/ruview-start的build路径面向需要阅读源码、二次开发或参与贡献的开发者核心是构建 可复现证明两步# 第一步在 v2 Rust 工作区运行完整测试跳过默认特性 cd v2 cargo test --workspace --no-default-features # 第二步运行确定性管道证明必须输出 VERDICT: PASS cd .. python archive/v1/data/proof/verify.py # 可选单 crate 健全性检查 cargo check -p wifi-densepose-train --no-default-features3.1 v2 Rust 工作区v2/是当前主代码库由 v2/Cargo.toml 定义的 workspace 管理包含数十个成员 crate与引导相关的核心 crate 包括wifi-densepose-sensing-serverAxum 实现的实时感知服务器REST WebSocket既消费 ESP32 UDP CSI 流也是--model、--embed、--build-index等模型能力入口wifi-densepose-train模型训练 crate/ruview-train的目标wifi-densepose-vitals生命体征提取呼吸 6–30 BPM、心率 40–120 BPMwifi-densepose-signal信号处理与特征提取wifi-densepose-ruvectorRuVector 融合多基地跨视角嵌入、图算法。--no-default-features的作用是避免拉入需要外部运行时如 CUDA 等的默认特性使纯 CPU 环境下也能完整编译与测试这是 CI 与无 GPU 开发机上的标准做法。3.2 信任终止开关verify.py 到底验证什么python archive/v1/data/proof/verify.py被项目称为Trust Kill Switch信任终止开关它把管道是真实可复现的这一声明变成可证伪、可度量的检验。从 verify.py 源码看其执行流程是加载公开的参考 CSI 信号sample_csi_data.json该信号由generate_reference_signal.py生成的确定性合成信号取前 100 帧约 1 秒逐帧喂给生产环境的真实管道——src.hardware.csi_extractor.CSIData与src.core.csi_processor.CSIProcessor调用preprocess_csi_data()与extract_features()而非任何测试替身脚本会打印SOURCE PROVENANCE用inspect.getfile输出实际导入模块的绝对路径供人工核对将 5 类特征amplitude_mean、amplitude_variance、phase_difference、correlation_matrix、power_spectral_density序列化为规范字节流计算 SHA-256与仓库提交的expected_features.sha256比对输出VERDICT: PASS / FAIL。实现上还有两个值得注意的细节量化精度特征在打包前会按PROOF_HASH_DECIMALS默认 6 位小数四舍五入。原因是 scipy.fft 的 pocketfft 内核在不同 CPU 微架构Intel AVX2/AVX-512 vs ARM NEON下会重排浮点约简顺序使原始哈希跨平台发散——量化 6 位小数约高出观测到的 ULP 漂移 6 个数量级同时远低于任何有信号意义的变化CSI 相位精度约 1e-3 rad。跨平台容差兜底doppler_shift特征因峰值归一化argmax在近并列峰下不稳定而被有意排除在哈希之外同时若位精确哈希因微架构差异不匹配脚本还会将全精度特征向量与提交的expected_features_reference.npz做rtol1e-4 / atol1e-6的相对容差比对两者任一通过即判定 PASS。此外verify.py --audit会扫描生产代码中是否存在np.random.*、unittest.mock、MagicMock等随机/模拟模式排除测试目录从代码考古层面佐证管道不是 mock。如果因合法的 numpy/scipy 升级导致哈希不匹配可运行python archive/v1/data/proof/verify.py --generate-hash重新生成基准前提是确认改动确实改变了数值输出。3.3 单 crate 健全性检查cargo check -p wifi-densepose-train --no-default-features用于只检查单个 crate 能否编译不做完整链接与测试是修改训练相关代码时最快的反馈回路。/ruview-verify的完整验证范围还包括cargo test -p wifi-densepose-signal --no-default-features等单 crate 测试以及bash scripts/generate-witness-bundle.sh生成的见证包dist/witness-bundle-ADR028-sha.tar.gz内含 WITNESS-LOG-028.md、ADR-028 审计、proof、Rust 测试日志、固件哈希清单等解包后bash VERIFY.sh须 7/7 PASS。四、路径三ESP32 硬件实时感知hardware路径面向有真实硬件的用户推荐组合是ESP32-S3约 $9或 ESP32-C6WiFi 6 研究节点约 $6–10。完整链路为/ruview-flash烧录固件 →/ruview-provision写入网络与感知配置 →cargo run -p wifi-densepose-sensing-server消费 UDP CSI 流。以下按顺序拆解。4.1 第一步烧录固件/ruview-flash/ruview-flash支持三种固件变体8mb默认从sdkconfig.defaults.template构建真实 WiFi CSI无 mock4mb先复制sdkconfig.defaults.4mb为sdkconfig.defaults关闭显示、经partitions_4mb.csv双 OTAheltec使用sdkconfig.defaults.heltec_n16r2。构建需 ESP-IDF v5.4 环境Windows 下注意不能用 Git Bash 直接跑idf.py会挂起应使用 Espressif Python venv 子进程并剥离MSYSTEM*环境变量。构建产物位于firmware/esp32-csi-node/build/bootloader/bootloader.bin、partition_table/partition-table.bin、esp32-csi-node.bin、ota_data_initial.bin。烧录以 Windows COM8 为例Linux/macOS 将端口改为/dev/ttyUSB0等python -m esptool --chip esp32s3 --port COM8 --baud 460800 write_flash \ 0x0 firmware/esp32-csi-node/build/bootloader/bootloader.bin \ 0x8000 firmware/esp32-csi-node/build/partition_table/partition-table.bin \ 0xf000 firmware/esp32-csi-node/build/ota_data_initial.bin \ 0x20000 firmware/esp32-csi-node/build/esp32-csi-node.bin烧录后用 pyserial 在 115200 波特率打开串口监控idf.py monitor在子进程场景会挂起确认固件启动。关键纪律不要用 mock 模式测试固件——Kconfig 回退阈值 bug 只在真实 CSI 下才会暴露/ruview-flash原话Never test in mock mode。4.2 第二步写入 NVS 配置/ruview-provision节点固件烧录后是裸的需要把 WiFi 凭据、数据接收端sink地址、感知参数写入 NVS 分区。推荐使用仓库中的 scripts/provision.pypython scripts/provision.py --port COM8 \ --ssid SSID --password PW --target-ip SINK_IP --target-port 5005 --node-id 0-255 \ [--channel N] [--filter-mac AA:BB:CC:DD:EE:FF] [--hop-channels 1,6,11 --hop-dwell 200] \ [--tdm-slot i --tdm-total n] [--edge-tier 0|1|2] [--pres-thresh 50] [--fall-thresh 15000] \ [--vital-win 300] [--vital-int 1000] [--subk-count 32] \ [--seed-url http://10.1.10.236 --seed-token bearer --zone lobby] [--swarm-hb 30] [--swarm-ingest 5] [--dry-run]核心参数取舍来自/ruview-provision的 trade-off 说明参数作用取舍--channel N固定节点到单一 WiFi 信道应设为 AP 实际信道信号更稳定固定后失去跳频带宽--hop-channels 1,6,11启用多频带跳频调度更多感知带宽借用邻居 AP 作照明源配合--hop-dwell设置每信道驻留毫秒数--filter-mac MAC只捕获指定发射器的 CSI信号更干净省略则捕获所有发射器数据更多但噪声更多--edge-tier 0/1/2关闭 / 统计 / 生命体征ADR-041越高越耗电能力越强--tdm-slot / --tdm-total多节点网格时隙编排多个 ESP32 组网时避免互相干扰--fall-thresh 15000跌倒检测阈值 ≈ 15.0 rad/s²调高可减少误报跌倒--pres-thresh 50存在检测阈值灵敏度调节--dry-run只生成 NVS 镜像不烧录上线前安全演练重要警告Issue #391烧录会重写整个csi_cfgNVS 命名空间——所有未在命令行中给出的键都会被擦除。因此对已正常工作的节点重新 provisioning 前必须三思且应一次性传全所需参数集--force-partial允许在无 WiFi 凭据的情况下写配置需明确知情。验证节点是否工作串口监控应看到adaptive_ctrl心跳与csi_collector: CSI cb #… len128 rssi… ch…行数据接收端应报告有 UDP 帧到达。若无帧按顺序排查信道不匹配、MAC 过滤过紧、--target-ip不是本机、WiFi 凭据错误。4.3 第三步运行感知服务器消费 CSIcd v2 cargo run -p wifi-densepose-sensing-server感知服务器在本地监听 UDP CSI 流默认 sink 端口 5005provision 时以--target-ip/--target-port指向运行本命令的主机解析后执行存在检测、生命体征提取等感知逻辑。多节点组网时建议 2 个以上 ESP32 节点以获得更好的空间分辨率或进一步叠加 Cognitum Seed持久向量存储 kNN 见证链。与 ESP32 配套的常用实时工具还包括node scripts/rf-scan.js --port 5006 # 实时 RF 房间扫描 node scripts/snn-csi-processor.js --port 5006 # SNN 实时学习脉冲神经网络这两个 Node 脚本分别在 5006 端口消费 CSI 流前者做房间级射频指纹/扫描后者用 SNN 做环境自适应学习——它们在 README.md 的 Full system with Cognitum Seed 方案Option 3中也被列为标准组件。五、必须知晓的边界与警告/ruview-start明确要求 Agent 在引导用户时主动警告以下事项这也是评估部署方案的硬边界ESP32-C3 与初代 ESP32 不受支持两者均为单核无法胜任 CSI 数字信号处理。硬件选型应从 ESP32-S3 / ESP32-C6 起步固件目标选择与 C6 的 HE-LTF 子载波标记、802.15.4 网格时间同步等扩展能力见 ADR-110-REVIEW-GUIDE.md 与firmware/esp32-csi-node/的 sdkconfig 变体。单节点空间分辨率有限单个 ESP32 提供的是单天线 56 子载波的 CSI 流细粒度空间信息有限。文档建议使用 2 个以上节点多基地跨视角融合对应wifi-densepose-ruvectorcrate 的跨视角机制或添加 Cognitum Seed 以获得持久记忆与更强的空间模型。相机自由姿态精度是温和的引导文档注明相机监督训练camera-supervised training可达到 92.9% PCK20ADR-079-camera-ground-truth-training.md但与此同时README 的 Beta 声明与模型权重诚实标注指出未经相机监督的实时单 ESP32 姿态模型仍属first-cut水平板上模型 PCK20 仅约 3.0%运行时路径还是confidence0的占位 stubADR-079 的目标基线是 ≥35% PCK20 且数据采集/评估阶段仍未完成。因此对纯 WiFi、无相机、实时 17 关键点姿态能力务必以 README 的诚实标注为准不要按宣传口径夸大。需要姿态精度的场景正确路径是自行采集配对数据并用/ruview-train训练。无云、无相机、无互联网依赖整套系统在边缘运行ESP32 节点 边缘主机即可构成闭环隐私设计上天然规避视频类合规问题。六、上手之后标准工作流与参考文档完成三条路径中任意一条后/ruview-start会把用户引导到后续命令与配置工作流/ruview-app运行具体感知应用。presence / vitals / pose / environment走wifi-densepose-sensing-server环境模式追加-- --model model.rvf --build-index envsleep走 examples/sleep/ 与node scripts/apnea-detector.jsmat灾难幸存者检测走wifi-densepose-matcrate 与 wifi-mat-user-guide.mdpointcloud走 mmwave_fusion_bridge.py。无硬件时回退到 Docker 演示或python examples/ruview_live.py可视化可用node scripts/csi-spectrogram.js、node scripts/csi-graph-visualizer.js。/ruview-train训练、评估、发布模型含 GCloud GPU 训练。/ruview-verify完整信任流水线——testscargo test --workspace --no-default-features要求 1400 通过、0 失败→proofverify.py输出VERDICT: PASS→bundle见证包VERIFY.sh7/7 PASS。代码变更后按 CLAUDE.md 的 pre-merge 清单逐项走查。配置工作流sdkconfig 变体选择8mb / 4mb / heltec、NVS provisioning、边缘模块edge modules、多节点网格mesh、Cognitum Seed 集成。继续深入时按需查阅以下文档均以仓库根为基准docs/user-guide.md安装、首次运行、API、硬件、训练、docs/TROUBLESHOOTING.md故障排查、docs/ADR-079-camera-ground-truth-training.md相机监督训练与姿态精度目标、plugins/ruview/README.md插件体系全貌以及 examples/ 下的环境/医疗/睡眠/压力/幸福向量等可运行示例。七、小结/ruview-start的三条路径构成了一个清晰的决策树无硬件 → Docker 模拟体验要开发/贡献 → 源码构建 Trust Kill Switch 确定性验证有 ESP32 → 烧录 → provision → 实时感知。对 AI Agent 而言这是一份可直接执行的、带明确成功判据VERDICT: PASS、串口CSI cb行、UDP 帧到达的引导协议对开发者而言它是理解整个 RuView 操作面与诚实能力边界的最佳入口。部署前请务必重读第五节的硬件与精度边界——这决定了你的感知方案能真实交付什么能力。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考