IWR1843: 基于IWR1843的雷达用于交通车辆监测的问题

请问使用的是哪个版本的toolbox? 我们需要咨询一下产品线工程师。

您好，

可以的，可以将交通监控代码的跟踪器部分移植到中距离雷达源。 需要移植的四个 TLV 是球面坐标、TargetID、TargetList 和 Target Height。当目标数量不匹配时，您看到的是什么？可以举个例子或者给一个屏幕截图。 另外，当可视化工具卡住时，是否会遇到错误？ 由于灵敏度过低，传感器可能会崩溃，进而会导致检测次数过多。

1、使用的是radar_toolbox_1_00_01_07。

2、我们发现medium_range_radar是在DSP上实现点云聚类和轨迹跟踪的(但是没有给目标分配ID），可否在此medium_range_radar基础上增加代码实现给目标分配ID和实现跟踪管理功能？

3、Traffic_Monitoring的跟踪器功能是在ARM实现的，如果将交通监控代码的跟踪器部分移植到中距离雷达，也是移植到ARM里面实现吗？如果我们要实现同时检测和输出128个汽车目标，ARM的性能是否能满足要求？

4、对于以上2和3两种实现给目标分配ID和跟踪管理功能的方法，哪种方法更容易实现，效果更好？你们更推荐使用哪种？

5、测试medium_range_rada目标数量不匹配，意思是当有2辆或更多汽车开过来时，会有些汽车目标在可视化工具上没有棱形、方形聚类和跟踪目标标记，只有一个点在移动。

6、测试Traffic_Monitoring的demo，当可视化工具卡住时，没有提示出现错误。当汽车数量较少，能正常运行，如果汽车数量较多或者有大卡车时，点云数量激增，此时就会容易出现可视化工具卡住；如果重新启动可视化工具，还可以正常运行。

使用的是radar_toolbox_1_00_01_07。

典型场景。

如上图1，左边车辆显示跟踪目标标记，右边车辆只显示一个点。

如上图2，远处卡车只显示一个点，近端小车有跟踪标记。

如果在可视化工具上设置不显示点云数据，只显示跟踪目标，那这会导致有漏检车辆。要如何解决这个问题？

我们跟进给工程师看下。

可以从交通监控中的跟踪器着手，目前可以100%确信，通过调整跟踪器 CFG 参数，可以获得更好的距离分辨率来区分两辆不同的汽车，还可以使 SNR 较低的更远距离的汽车仍被视为赛道。 使用的跟踪器算法与用于3D 人员计数的算法相同。 该实验仅适用于6843，但涵盖跟踪器层参数的文档仍然相同，因此请从这里着手： 尝试更改 stateParam 和 allocationParam，以使跟踪器更敏感，更适合您的环境。 默认配置用于跟踪70米附近的车辆，我们可以看到，使用当前配置难以跟踪120米处的车辆。

当可视化工具卡住时，器件是否仍在进行线性调频脉冲？ 您可以通过 PuTTY 或 TeraTerm 等应用程序进行串行通信来确定这一点。 我们需要更多信息来确定具体是整个器件都崩溃还是只有可视化工具会卡住。

chun liu 说：

可否在此medium_range_radar基础上增加代码实现给目标分配ID和实现跟踪管理功能？

可以，但需要做一些工作。 如果在 MRR demo中对其进行了所有点云处理，跟踪器可能会在 DSP 内核上运行。 请问下您为什么需要更改中距离雷达以添加跟踪，而不仅仅是使用交通监控？

1、如果将交通监控中的跟踪器移植到medium_range_radar，除了上面提到需要移植的四个 TLV 是球面坐标、TargetID、TargetList 和 Target Height之外，还需要注意哪些函数和参数的移植以达到数据和接口的匹配？

2、用于交通监控中需要给监测到的车辆分配ID，同样的ID一直跟踪着同一辆车直到车辆消失在雷达探测范围。如下图，我们想要ID：1和ID：2一直跟着同一辆车。目前MRR demo已经可以输出检测的车辆，如果要在此基础上给车辆增加 ID和跟踪车辆直至车辆消失，能否实现？要如何实现？

chun liu 说：

1、如果将交通监控中的跟踪器移植到medium_range_radar，除了上面提到需要移植的四个 TLV 是球面坐标、TargetID、TargetList 和 Target Height之外，还需要注意哪些函数和参数的移植以达到数据和接口的匹配？

需要移动跟踪算法本身，其中包括 trackingproc 文件和 gtrack 文件。 

chun liu 说：

2、用于交通监控中需要给监测到的车辆分配ID，同样的ID一直跟踪着同一辆车直到车辆消失在雷达探测范围。如下图，我们想要ID：1和ID：2一直跟着同一辆车。目前MRR demo已经可以输出检测的车辆，如果要在此基础上给车辆增加 ID和跟踪车辆直至车辆消失，能否实现？要如何实现？

交通监控中的跟踪器算法已经为每个轨迹提供了一个轨迹 ID (tid)，但并未被可视化。 您可以在Understanding UART Output TLV guide中了解可以输出的所有内容：

https://dev.ti.com/tirex/explore/node?a=1AslXXD__1.00.01.07&node=A__AB9hZpEHkevINfCz6VJgQw__radar_toolbox__1AslXXD__1.00.01.07

该链接涵盖了工业演示 TLV，没有 MRR 1，但有四个（工作方式相同）。 您可以在 MSS_main.c 中看到 MRR 的 TLV。"CAN_MESSAGE_MMWDEMO_RICED_objects"具有 MRR 用户指南中列出的值，对于每个附带的 TLV，您可以为其提供索引。 

可以添加 MRR 和交通监控，虽然最终结果的构建方式非常不同，但这两者之间并不容易相互转换，因此需要移植代码。 这两个demo中的跟踪算法也不同。 

所以您更推荐将Traffic_Monitoring的跟踪器移植到medium_range_radar，而不建议在medium_range_radar的基础上增加代码来实现ID和跟踪，是吗？

Traffic_Monitoring和medium_range_radar两个使用的跟踪算法，哪个更优？

https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1133615/awr1843-performance-of-mrr-and-beam-steering-mrr

我看了其它相关帖子的回复说medium_range_radar可以在Extended_Kalman_Filter_xyz.c上增加创建/维护/更新ID，实现跟踪轨迹的效果。此方法是否可行？如果可行，具体要怎么实现？

感谢回复和指导。

还有个疑问，见上面回复的截图。如果将Traffic_Monitoring的跟踪器移植到MRR，那是不是需要将跟踪器所需的TLV和MRR的TLV的数据格式相匹配？这能实现数据的匹配吗？

我们需要和工程师确认下，应该会在下周工作日给到答复。

请问有进展吗？

我们的工程师外出了，最晚这周内应该会给到您答复的。

非常感谢。