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.

AWR6843AOPEVM: 3D People Counting: The heatmap data arrangement of static scene beamforming

Part Number: AWR6843AOPEVM

Hi, TI team,

It seems to be different heatmap data arrangement between function codes and the description in document while computing the static scene Azimuth-Elevation Bartlett beamforming.

(The source codes are imported from project: "C:\ti\mmwave_industrial_toolbox_4_11_0\labs\People_Counting\3D_People_Counting\src\68xx\68xx_3D_people_count_dss.projectspec".)

(The source codes are in lines 119~177 in RADARDEMO_aoaEstimationBFSinglePeak_static() function in RADARDEMO_aoaEstimationBFSinglePeak_staticHeatMapEst.c file. And "RADARDEMO_aoaEstimationBFSinglePeak_static()" is called by RADARDEMO_aoaEst2DCaponBF_static_run() while "processingStepSelector == 0". )

。In codes: Using 2 for loops which process all elevation index (in inner loop) according to each azimuth index (outer loop), then change to next azimuth index to keep processing:

   => The arrangement become: [azimIdx_0; elevIdx_0 ~ elevIdx_End], [azimIdx_1; elevIdx_0 ~ elevIdx_End], ... [azimIdx_End, elevIdx_0 ~ elevIdx_End]

。In "3D_people_counting_demo_implementation_guide" document description(figure 34 in p.51), the data should be arranged in all azimuth indexes then all elevation indexes for following Azimuth-Elevation CFAR detection process:

I think both arrangement are quite different, which leads to different CFAR detection results!

 

Shihyu.

  • Shihyu,

    Are you finding that the format is not what you expect? In the function description, it states:

     *               Output azimuth-elevation heatmap per range bin, length of number of angle bins, arranged in [elev][azim] format.
    Best,
    Nate
  • Hi Nate,

    The heatmap data was indeed arranged in [elev][azim] format, and it conform to the behavior of the codes.

    => For my understanding, and to embody the [elev][azim] format is:

    (The 0 indexes of azimuth and elevation are at the bottom since it follows the "heatMapPtr" which starts from end of the buffer, and step-by-step count down; see codes above, in line 151.)

    But my confusion was this did not conform to the figure 34, it was arranged in [azim][elev]. The data might be re-arranged to fit the figure.

    Did I miss any information in codes or my understanding was incorrect?

    Thanks

    Shihyu.

  • Hi Shihyu,

    Figure 34 shows [elev][azim] format. If you move down from top to bottom, the azimuth varies first, then the elevation. An array organized in [elev][azim] format would also vary first in azimuth, then in elevation. Your picture shows [azim][elev] format because moving downward (or upward in your case), you vary in elevation first, then in azimuth.

    Best,

    Nate

  • Hi Nate,

    After reading the content of implementation guide literature and reviewing the codes again, There is a misunderstanding.

    Thus, following 2 lists are my current comprehension about the heatmap data arrangement, and corresponding process meaning of CFAR in both dynamic and static-scene detection parts.

    Please correct me if anything goes wrong and give me the guidance.

    1. In ceil-mount case of Capon beamforming process:

    • The 2D angle steering vectors(raHeatMap_handle->steeringVec) were initialized in [elev][azim] order: (see line 221~238 in RADARDEMO_aoaEst2DCaponBF_create() function in RADARDEMO_aoaEst2DCaponBF.c)

    • The heatmap(rangeAzimuthHeatMap) will then be computed in same [elev][azim] order using steering vectors: See line 1162 in RADARDEMO_aoaEst2DCaponBF_raHeatmap() function in RADARDEMO_aoaEst2DCaponBF_heatmapEst.c. Which use the outer-most for loop to compute each AngleBins.

    • Thus, after these 2D angle Capon beamforming computation of ceil-mount case, the heatmap and corresponding data arrangement fit the [elev][azim] format just like figure 34.
    • Finally, CFAR detects peaks using this heatmap for detection in range-domain then in azimuth-domain (ignore several Angle Index cross different elevation-domain.)

    2. For static scene 2D angle Bartlett beamforming process: (lines 119~177 in RADARDEMO_aoaEstimationBFSinglePeak_static() function in RADARDEMO_aoaEstimationBFSinglePeak_staticHeatMapEst.c)

    • Which use 2 for loops process all elevation index (in inner loop; line 138) according to each azimuth index (outer loop; in line 121). That is to say, in [azim][elev] order(Thus the data were arranged in [azim][elev] format just like the figure draw by myself.)

    • Finally, the CFAR detects peaks using this heatmap for detection in range-domain then in elevation-domain!

    (Another clue is that in line 1402 of RADARDEMO_detectionCFAR_raCAAll() function in RADARDEMO_detectionCFAR_priv.c, the annotate denotes "with elevation domain local max confirmation" if the enableSecondPassSearch == 0, which is the static scene setting.)

    So, I can say that each case listed above detect peaks through CFAR in its major angle domain (focus on the second-pass in CFAR); first one, ceil-mount case, major in azimuth-domain; while second one, static scene, major in elevation-domain.

    (Since Figure 34 is the description for ceil-mount dynamic scene detection, and also is the only visualization for CFAR, I was misled that all data in heatmap should be arranged in same format.)

    Do all these algorithms behavior and my understanding correct? Need your guidance.

    Thanks a lot.

    Shihyu.

  • Hi Shihyu,

    Give me a day or two to investigate this. I'll get back to you as soon as I can.

    Best,

    Nate

  • Hi Shihyu,

    What you're saying here aligns with my understanding. I cannot really confirm your understanding, but I can't see anything written that is noticeably incorrect. If there is a specific question to answer here I'd be happy to help, but otherwise I will close this thread.

    Best,

    Nate

  • Hi,

    I think it's clear enough for me!

    Thanks a lot of the effort.

    Shihyu.