This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

IWR6843LEVM: How to support clutter removal functionality?

Part Number: IWR6843LEVM
Other Parts Discussed in Thread: IWR6843

Tool/software:

Hi TI,

  The 3D people tracking example seems not support clutter removal functionality in IWR6843. Can you please help to support this?

mmWaveSDK: v03_05_00_04

Radar Tool box: v2_00_00_06

Thanks.

  • Hi

    Thanks for your query. Please allow us a couple of days to respond

    Regards

  • Hello, 

    I'm very sorry for the delayed response here. Greatly appreciate your patience. 

    The 3D people tracking demo uses Capon beam forming based detection chain as compared to the traditional, a.k.a Bartlett, beam forming used in the out of box demo detection chain. It is necessary to enable clutter removal in Capon beam forming in order to be able to get the peaks in the range-angle heatmap, otherwise the heatmap looks like noise with no sharp peaks and hence no detected objects.

    Since it is not possible to disable clutter removal in this processing chain, it is always enabled in code and no option is provided for it on the CLI for the same reasons.

    Best Regards,

    Josh

  • Hi Josh,

      I have a little confused about your reply "it is always enabled in code and no option is provided for it on the CLI for the same reasons".

    From 3D_people_tracking_demo_implementation_guide.pdf, it mentions "The static clutter removal is performed by function RADARDEMO_aoaEst2DCaponBF_clutterRemoval(). 

    From the source code, this function will do nothing since it's not defined RADARDEMO_AOARADARCUDE_RNGCHIRPANT in 3D people tracking.

    Can you please help to check it again?

    Thanks.

  • Hello, 

    RADARDEMO_AOARADARCUDE_RNGCHIRPANT is defined in RADARDEMO_aoaEst2DCaponBF.h

    {RADAR_TOOLBOX_INSTALL}\source\ti\dpu\capon3d\modules\DoA\CaponBF2D\api

    Best Regards,

    Josh

  • Hi Josh,

      I can see the doppler value of point cloud is zero in my experiment. Can you please help to explain this result?

    Thanks.

  • Hi, 

    Can you provide more details about your experiment? Also please let me know if you have modified the example code or configuration.

    Best Regards,

    Josh

  • Hi Josh,

      The experiment is only put mmWave sensor in the desktop and record the point clouds information.

    Thanks.

  • Hi Josh,

      Do you find the reason?

    Thanks.

  • Hello, 

    Sorry for the delayed response here.

    Are you using the prebuilt binary files and which configuration are you using? 

    If you could provide more information about the data captured in your screenshot it would be helpful. For example, how are you capturing and parsing the data from the device? It appears that there are >27000 rows in the data that you are showing, am I correct to assume that all of these are detected points in the point cloud and only ~15 points have a doppler value of 0? Also, since the points seem to have 0 for azimuth and range I am wondering if these are even valid detections or if there is some issue with the parsing/corrupt data/something else. I'll keep looking into this to see if this issue of invalid points is a known issue and get back to you with my findings in the next couple of days.

    Best Regards,

    Josh

  • Hi Josh,

      Let's clarify the environment setup in my experiment first. 

      

    Device: IWR6843-ODS

    Example: 3D People tracking

    Radar firmware: prebuilt binary file 3D_people_track_6843_demo.bin in radar_toolbox_2_00_00_06\source\ti\examples\People_Tracking\3D_People_Tracking\prebuilt_binaries ) 

    Radar config:  ODS_6m_default.cfg in radar_toolbox_2_00_00_06\source\ti\examples\People_Tracking\3D_People_Tracking\chirp_configs

    Steps:

    1. Modify parseTLVs.py in radar_toolbox_2_00_00_06\tools\visualizers\Applications_Visualizer\common to save point clouds information.

       The change is only add save point clouds inforamtion to file in parseCompressedSphericalPointCloudTLV()

    2. Run gui_main.py in radar_toolbox_2_00_00_06\tools\visualizers\Applications_Visualizer\Industrial_Visualizer

    3. Start mmWave sensor

    4. Put the mmWave sensor in desktop and monitor point clouds information.

    I do the experiment again in this morning and get the same result. There are 7 points with zero doppler value. 

    Can you please help to check it?

    I attached the full point clouds information for your reference.

    20240925-095316.csv

    There are some questions about this detection layer flow chart.

    1. Are the flow A and flow B use in this 3D People tracking?

        If yes, is it possible to remove flow B?

    -----

    2. Is the flow A enable clutter removal by default?

        Is it possible to change the setting?

    -----

    3. Is the flow B disable clutter removal by default?

        Is it possible to change the setting?

    Thanks.

  • Hi Josh,

      Do you have any findings?

    Thanks

  • Hello, 

    Sorry for the delayed response. And thanks for the additional information about your experiment. I'm still trying to check if this is a known issue. 

    Regarding the detection layer flowchart questions, the processing in A removes the static clutter, this is not configurable and is required for the Capon algorithm. 

    The processing in B is the static scene processing mentioned in section 2.1.7 of the same document, this is optional processing which can be enabled via CLI configuration but it is disabled by most of the default configuration files. The command to enable this is processing as well as the applicable trade offs can be found in section 3.2.4. 

    Best Regards,

    Josh

  • Hi, 

    Thank you for your patience. After checking further this issue has been reported before but it is rare and believed to be a UART transmission error. Does this seem to make sense with your tests? If it is only a few points out of tens of thousands of points captured then I believe it could be a possibility.

    If you have the raw UART streams saved you can retry manually parsing in the data and check for the possibility of some bit error. 

    Best Regards,

    Josh