Other Parts Discussed in Thread: DCA1000EVM, IWR6843ISK
请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
部件号： IWR6843ISK
主题中讨论的其他器件： DCA1000EVM、
尊敬的团队：
代表我们的客户发帖。
我正在使用 IWR6843ISK 和 DCA1000EVM 从事一个顶点/研究项目。 我的目标是构建主机端 Python 流水线、该流水线从 DCA1000EVM 接收原始 ADC 数据，重建雷达帧，生成距离 — 多普勒和距离-角度表示、并执行移动人员检测和多目标跟踪。
硬件/设置：
- Radar EVM：IWR6843ISK
-采集板：DCA1000EVM
操作系统: Windows
-数据路径: DCA1000 以太网 UDP 原始 ADC 流
-控制路径：CLI UART
-处理: Python 主机端流水线
-帧速率：约 10 FPS
-传感器配置:连接/链接如下
项目摘要：
我们当前的实现方案可以接收原始 ADC 数据、构建雷达立方体、生成 RDI/RAI 输出、检测移动目标以及在简单的行走场景中跟踪人员。 然而、该系统仍处于原型/研究阶段、还不够强大、无法用于类似生产的用途。
我们尝试理解的主要问题是：
-鬼或肢体相关的角度峰值
-跟踪多人或接近目标场景中的不稳定性
-将两个附近的人合并到一个检测中
-将 DCA1000 传输质量问题与实际检测/跟踪故障分开
-验证我们的中间处理阶段是否与 TI 参考处理保持一致
我们当前的管道设计：
接收 DCA1000 UDP 数据包并重建原始 ADC 帧。
2.构建雷达立方体并应用静态干扰消除。
3.生成距离多普勒图像和距离 — 角度图像。
4.使用距离多普勒 CFAR 峰值作为第一个检测锚点。
5.使用距离 — 角度信息主要用于验证和坐标细化,而不是直接信任最强的角度峰。
6、应用局部的斑点中心细化,因为最强的反射往往不是身体的中心。
7.应用候选合并/自适应 DBSCAN。
8.使用基于卡尔曼的跟踪,并结合出生抑制、软门控和显示 ID 拼接的策略。
9、记录分阶段跟踪,以便在算法更改后可以重放和比较相同的原始捕获。
问题：
1.在我们的主机端 Python 流水线中、我们使用距离多普勒 CFAR 峰值作为稳定锚，然后使用距离 — 角度信息进行验证/优化。 对于跟踪 IWR6843ISK 的人员、在什么情况下、这种 RD 优先的方法预计会失败、尤其是对于缓慢、接近静止或间隔很近的人？
2.我们观察到,收缩的距离 — 角度图有时可以选择强肢体或幻影峰,而使用与 RD 种子相关的多普勒切片则可以提供更稳定的定位。 这是合理的诊断或处理策略、还是可以隐藏 TDM-MIMO 相位补偿、虚拟天线顺序或角度处理的误差？
3.在我们的结果中,最强的反射点通常不是身体中心。 因此，我们使用局部距离 — 角度修补和加权 blob 中心估计来优化候选对象。 是否有推荐的 TI 验证场景、参考输出或评估方法来确定这种优化是否正在改进车身中心定位、而不仅仅是平滑处理错误？
4.我们在最终合并/ DBSCAN 之前添加了一个对象计数估计步骤,以防止两个附近的人被合并到一个检测中。 TI 建议采用什么验证方案来调整抑制重复虚假候选和保留两个紧密物理目标之间的权衡？
5.由于我们直接在主机上处理 DCA1000 UDP 数据包、因此我们标记了序列间隙或字节不匹配的帧、并在无效帧上阻止新的跟踪出生。 这是否是将传输质量故障与检测/跟踪故障分开的合理方法？ 在评估算法性能时、应报告哪些传输运行状况指标？
6.为了将我们的自定义 Python 流水线与 TI 参考处理进行比较、应该只比较最终点云/轨迹、还是应该比较中间伪影、例如雷达立方体一致性、RD 热图峰值、RA 热图峰值、CFAR 候选计数和跟踪器输入计数？ 哪个中间级别对调试自定义原始 ADC 处理最有意义？
我知道 TI 可能无法调试完整的自定义算法。 我主要是想确认我们的验证方法和失效分析是否合理、以及哪些 TI 参考输出或测试程序最适合将定制原始 ADC 流水线与预期行为进行比较。
链接/附件：
-传感器配置文件:
硬件/设置：
- Radar EVM：IWR6843ISK
-采集板：DCA1000EVM
操作系统: Windows
-数据路径: DCA1000 以太网 UDP 原始 ADC 流
-控制路径：CLI UART
-处理: Python 主机端流水线
-帧速率：约 10 FPS
-传感器配置:连接/链接如下
项目摘要：
我们当前的实现方案可以接收原始 ADC 数据、构建雷达立方体、生成 RDI/RAI 输出、检测移动目标以及在简单的行走场景中跟踪人员。 然而、该系统仍处于原型/研究阶段、还不够强大、无法用于类似生产的用途。
我们尝试理解的主要问题是：
-鬼或肢体相关的角度峰值
-跟踪多人或接近目标场景中的不稳定性
-将两个附近的人合并到一个检测中
-将 DCA1000 传输质量问题与实际检测/跟踪故障分开
-验证我们的中间处理阶段是否与 TI 参考处理保持一致
我们当前的管道设计：
接收 DCA1000 UDP 数据包并重建原始 ADC 帧。
2.构建雷达立方体并应用静态干扰消除。
3.生成距离多普勒图像和距离 — 角度图像。
4.使用距离多普勒 CFAR 峰值作为第一个检测锚点。
5.使用距离 — 角度信息主要用于验证和坐标细化,而不是直接信任最强的角度峰。
6、应用局部的斑点中心细化,因为最强的反射往往不是身体的中心。
7.应用候选合并/自适应 DBSCAN。
8.使用基于卡尔曼的跟踪,并结合出生抑制、软门控和显示 ID 拼接的策略。
9、记录分阶段跟踪,以便在算法更改后可以重放和比较相同的原始捕获。
问题：
1.在我们的主机端 Python 流水线中、我们使用距离多普勒 CFAR 峰值作为稳定锚，然后使用距离 — 角度信息进行验证/优化。 对于跟踪 IWR6843ISK 的人员、在什么情况下、这种 RD 优先的方法预计会失败、尤其是对于缓慢、接近静止或间隔很近的人？
2.我们观察到,收缩的距离 — 角度图有时可以选择强肢体或幻影峰,而使用与 RD 种子相关的多普勒切片则可以提供更稳定的定位。 这是合理的诊断或处理策略、还是可以隐藏 TDM-MIMO 相位补偿、虚拟天线顺序或角度处理的误差？
3.在我们的结果中,最强的反射点通常不是身体中心。 因此，我们使用局部距离 — 角度修补和加权 blob 中心估计来优化候选对象。 是否有推荐的 TI 验证场景、参考输出或评估方法来确定这种优化是否正在改进车身中心定位、而不仅仅是平滑处理错误？
4.我们在最终合并/ DBSCAN 之前添加了一个对象计数估计步骤,以防止两个附近的人被合并到一个检测中。 TI 建议采用什么验证方案来调整抑制重复虚假候选和保留两个紧密物理目标之间的权衡？
5.由于我们直接在主机上处理 DCA1000 UDP 数据包、因此我们标记了序列间隙或字节不匹配的帧、并在无效帧上阻止新的跟踪出生。 这是否是将传输质量故障与检测/跟踪故障分开的合理方法？ 在评估算法性能时、应报告哪些传输运行状况指标？
6.为了将我们的自定义 Python 流水线与 TI 参考处理进行比较、应该只比较最终点云/轨迹、还是应该比较中间伪影、例如雷达立方体一致性、RD 热图峰值、RA 热图峰值、CFAR 候选计数和跟踪器输入计数？ 哪个中间级别对调试自定义原始 ADC 处理最有意义？
我知道 TI 可能无法调试完整的自定义算法。 我主要是想确认我们的验证方法和失效分析是否合理、以及哪些 TI 参考输出或测试程序最适合将定制原始 ADC 流水线与预期行为进行比较。
链接/附件：
-传感器配置文件:
-简短的结果视频:
- GitHub 存储库: https://github.com/deepblue21zin/radar-DCA1000-refactor
-示例故障情况:即使 DCA1000 运输运行状况指标是干净的,在近距离目标/交叉场景中的两个附近的人有时也会合并到一个显示的轨道中。
感谢你的帮助。
此致、
Danilo