4 Commits
Author SHA1 Message Date
keita 5e7e0d9713 钉死结论: 锁定后仍无表4,并补协议级硬证据
复测(--detect person --auto-lock, 60s): 表3 1200帧@20Hz, 表2-2 3599帧@60Hz,
首次锁定 0.13s 且全程保持, 表4 仍 0 帧。→ 排除「没锁定所以不解算」。

协议级硬证据: 激光测距字段只存在于表2-2(吊舱→控制器); 表2-1/表3 均无距离
输入字段, 故即便 stereo_ranger 算出距离也无法回灌让吊舱解算 —— 连补救通道都没有。

架构走向: 目标经纬度改由我方自算(视觉测距+载机GPS/姿态+吊舱框架角),
吊舱退化为伺服指向+脱靶量传感器。附待改点 bridge.py:169 / guidance.py 输入。
唯一翻盘途径: 问厂商无激光配置下表4是否设计上就不输出。
2026-10-09 10:01:40 +08:00
keita f17005a020 文档澄清: --json 后是输出产物路径,非预置输入文件
phase1.json 只在 sim_fc.py 跑完后才生成,仓库内本就不该有。
统一改用绝对路径 ~/pod_logs/phase1.json,避免相对路径落在 utils/ 后找不到;
补充 §8.1.1 说明落盘结构(args/summary/samples)与 samples 为空的含义。
2026-10-08 10:26:51 +08:00
keita 257721e035 实测记录: 无激光时吊舱不输出表4(目标经纬度)
20Hz喂伪造表3(lat39.9042/lon116.4074/rel_alt50m),只收到约60Hz表2-2,
表4一帧都没有。判读: 吊舱目标地理解算依赖激光测距,无斜距即不解算。

架构影响:
- guidance.py 引导律在本设备上永久刹车(bridge.py:169 target_valid 依赖表4),
  安全方向正确但吊舱侧不再提供目标坐标
- 目标距离/坐标必须改由自有链路 stereo_yolo -> stereo_ranger 提供
- --auto-unlock 实测禁用: pod_console.py:232 把 last_tgt_s is None 当超时,
  会一锁定就误解锁并与 0x0F 常驻自动重锁循环震荡
- 阶段2/阶段3 精度实验取消(前提不成立)

保留两种待排除可能: 未真锁定、表3时戳/有效性要求,给出复测命令。
2026-10-08 10:04:04 +08:00
keita e1dbf081ab 新增sim_fc.py: 模拟飞控喂表3验证吊舱解算(第1阶段)
- 伪造载机姿态/位置/时戳持续喂表3,单进程收发一体观测表2-2/表4
- 回答Q1(无激光是否仍解算表4)/Q2(表4实际频率)/Q3(丢失后行为)
- 自动判读「目标贴地」假设: 表4相对高度是否约等于喂入的载机高度
- 退出码0/1/2/3便于脚本串测; --json落逐帧采样供阶段2聚类分析
- 默认参数已敲定: lat=39.9042 lon=116.4074 rel-alt=50 rate=20Hz
- 纯软单测21条(注入fake serial), 全量回归372 passed
2026-09-29 14:39:26 +08:00