 keita
|
ddd8127753
|
记录厂商答复: 该吊舱不允许二次开发
含义: 不能改固件让它输出表4或接受外部距离; 但表2-1控制指令仍开放,
吊舱仍可作传感器+执行末端。实际损失只有吊舱侧白送的目标坐标,而这部分
本就该由我方自算,故对本项目影响小于预期。选型结论: 不必为二次开发换型号。
|
2026-10-09 10:24:23 +08:00 |
|
|
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 |
|
|
keita
|
a2ca8bee0c
|
纠正说法: 0x0F自动锁定是常驻模式, 0x0E只停当前跟踪
实测: 按u后并未放弃自动锁定, 只是目标丢失无法锁定, 目标重新入画仍会自动锁定,
无需重发0x07/0x0F/0x10; 只有0x08关识别才真正退出。同步修正脚本按键说明、
面板提示与部署文档§10/§10.1, 并据此下调自动解锁的副作用风险评级
|
2026-09-28 16:50:19 +08:00 |
|
|
keita
|
fc364656ec
|
记录0x0E解除锁定有效; 自动解锁判据转为待定项
实测0x0E停止跟踪后bit2复位(厂商软件锁定框同步消失); --auto-unlock 的触发判据
(表4超时)对本设备存疑(无激光时表4可能根本不发→一锁定就误解锁), 已在代码标注
风险并在部署文档新增§10.1列出待确认项与5种候选判据。全量351条通过
|
2026-09-28 16:20:07 +08:00 |
|
|
keita
|
d255d22fc9
|
激光门控改为可配置, 本设备(无激光)置false
链路: 新增link.require_laser_valid(默认true, 有激光机型的锁定位置位粘滞兜底);
本吊舱厂商确认不含激光测距 → pod_bridge.json 置false, 并加部署配置回归测试。
文档新增§10记录设备特性(无激光/锁定位置位丢失后不复位/脱靶量无无效标志位)。
全量351条通过(新增3条激光门控用例)
|
2026-09-28 15:22:14 +08:00 |
|
|
keita
|
7e43e6302d
|
部署文档补内核控制台坑: 仅关getty不够
实测: printk legacy console [ttyS0] 未清时内核日志混入吊舱协议流, 表现为
收几帧后 OSError errno 5; 补充 cmdline.txt 清理步骤与串口静默后三连验证
|
2026-09-28 09:31:00 +08:00 |
|
|
keita
|
50372e6623
|
新增吊舱串口监听诊断脚本listen_pod.py
台架工具: 统计表2-2/表4帧数、打印首帧关键状态、按60Hz标称80%判读链路,
--center可下发归中验证下行; 打桩冒烟测试通过(帧解析/统计/判读/退出码)。
部署文档§7第3步改为引用该脚本
|
2026-09-24 15:19:51 +08:00 |
|
|
keita
|
ccd31effee
|
锁定mavsdk<4: v4为全新原生API与经典gRPC API不兼容
树莓派实测mavsdk 4.0.0无mavsdk.offboard/System/telemetry(LegacyModuleError),
且其原生库libcmavsdk.so有libstdc++符号问题; 3.x(最新3.17.4, aarch64 wheel可用)
为gRPC架构内嵌mavsdk_server, 无此问题。同步更新两份requirements与部署文档§2/§3
|
2026-09-24 10:08:06 +08:00 |
|
|
keita
|
642b8bf224
|
修正mavsdk自检方式: 4.x无mavsdk_server可执行文件
改为直接加载libcmavsdk.so(构造offboard设定点复现加载点)+ldd链接检查,
并注明单测全绿不证明mavsdk已装(测试已打桩脱钩)
|
2026-09-24 09:52:18 +08:00 |
|
|
keita
|
e179aa322a
|
部署文档目标系统回改为Raspberry Pi OS官方镜像
用户在Ubuntu镜像上遇串口问题换回官方镜像: §1改Bookworm(3.11)/Trixie(3.13)
口径, §3补libstdc++符号说明(GCC12+官方镜像均满足), §4恢复raspi-config与
/dev/serial0指引, §7注明单测已与原生库脱钩
|
2026-09-23 18:00:30 +08:00 |
|
|
keita
|
477ad5f5de
|
新增pod_bridge吊舱桥接中间件(树莓派4B部署)
- pod_bridge: 协议G版编解码/地理位置引导律/PX4网关/串口链路/闭环主循环
- 含三项安全修复: position_time_ms拆分、表2-2锁定门控、run()异常护栏
- 测试92条全绿; 附树莓派4B(Ubuntu 24.04)部署注意事项与最小依赖清单
|
2026-09-23 14:38:23 +08:00 |
|