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.

CCS/IWR6843: How to add Gtrack (3D) to Area Scanner

Part Number: IWR6843
Other Parts Discussed in Thread: MMWAVEICBOOST,

Tool/software: Code Composer Studio

Hi dear Support Team !

I work with mmWaveICBOOST and IWR6843ISK antenna.

I use Area Scanner project because I need a 3D Point Cloud and I've arleady made some minor modification in it . Now, I'd like to add Gtrack 3D to my project , how can I do it?

Moreover, could it be possible to change the output of the project to perform 2D tracking instead of 3D tracking  also?

Thanks in advance for your help !

Best Regards,

Quentin.

 

  • Former Member
    0 Former Member
    Hello Quentin,

    The gtrack source code is located in the mmWave SDK at C:/ti/mmwave_sdk_03_02_00_00/packages/ti/alg/gtrack/
    There is a doxygen for the 2D and 3D gtrack lib (../docs/doxygen2D/html/index.html) that gives details on implementing the library. I would also recommend that you refer to the Overhead People counting demo source code (the MSS project) dev.ti.com/.../node which implements a 3D gtrack lib on top of the out of box processing chain.

    The gtrack lib can be compiled for either 2D or 3D using the compile flag. The precompiled libraries are included in the SDK.

    In addition to the device code you would want to modify the area scanner visualizer to parse the GTRACK output instead of the SDK OOB output that it is currently expecting.

    Best,
    Amanda
  • Hello Amanda !

    Thank you for your fast and complete answer !

    I had a look to GTrack doxygen and Overhead People Counting.
    As you said, I noticed that this lab have an MSS and a DSS project. I assume DSS manage Range/Static Clutter/Doppler/CFAR/AoA processes on DSP and then send those Data to MSS to perform tracking.
    Until now I worked with Area Scanner Lab and Range/S.C./... processes were performed by HWA.
    Does this difference could change the way GTrack has to be added/will work in my project ?
    Is DSP used in the out of box processing chain?
    I ask you this because I wonder if I can continue working with Area Scanner MSS project or if I should work now with Overhead People Counting project in order to use 3D Gtrack (even if I'll have to port my modification to the new project).

    I try to make my own visualizer. So, to parse GTrack output I could directly use Overhead People Counting Visualizer's Code, right ? Is it possible in the visualizer to parse GTrack 3D output, 3D Point Cloud and Range Azimuth Heat Map ?

    Thanks again for your help,
    Have a good day !
    Quentin

  • Former Member
    0 Former Member in reply to Quentin BAJOT

    Quentin BAJOT said:

    As you said, I noticed that this lab have an MSS and a DSS project. I assume DSS manage Range/Static Clutter/Doppler/CFAR/AoA processes on DSP and then send those Data to MSS to perform tracking.

    Yes that's correct.

    Quentin BAJOT said:

    Until now I worked with Area Scanner Lab and Range/S.C./... processes were performed by HWA.
    Does this difference could change the way GTrack has to be added/will work in my project ?
    Is DSP used in the out of box processing chain?

    I ask you this because I wonder if I can continue working with Area Scanner MSS project or if I should work now with Overhead People Counting project in order to use 3D Gtrack (even if I'll have to port my modification to the new project).

    For the current 68xx OOB the demo does not make any use of the DSP. The GTRACK lib is provided for the R4F and the DSP. You could implement on either without changing the implementation since Gtrack takes point cloud as input without concern for how the point cloud processing is implemented. Selecting between point cloud processing on DSP vs HWA will be dependent on your overall plan and how that affects the resource allocation. If you plan for additional algorithms to run on the DSP it would make sense to use the HWA based OOB but if you need maximal point cloud processing performance the DSP based chain could be better but then you leave the HWA resources unused. In general unless you are requiring very high doppler resolution the HWA point cloud processing performance should be sufficient.

    Quentin BAJOT said:


    I try to make my own visualizer. So, to parse GTrack output I could directly use Overhead People Counting Visualizer's Code, right ? Is it possible in the visualizer to parse GTrack 3D output, 3D Point Cloud and Range Azimuth Heat Map ?



    Yes - you can refer to the people counting visualizer source code for the TLV parsing example. The current people counting labs only output point cloud and gtrack target outputs. There is no range azimuth output. This could be an advantage of building off the out of box demo if you want to maintain the ability to output the range profile or heatmaps. However a big concern with the heatmaps will be that with the UART interface the data transmit time is quite long. This limits the frame rate of the chirps to <5fps which is not ideal for accurate gtrack. You could consider a scheme that on some frames you output pt cloud and gtrack data and periodically on some other frames you only output heatmap.

    Amanda

  • Hi Amanda !

    Thanks for this such complete answer !

    AmandaN said:
    For the current 68xx OOB the demo does not make any use of the DSP. The GTRACK lib is provided for the R4F and the DSP. You could implement on either without changing the implementation since Gtrack takes point cloud as input without concern for how the point cloud processing is implemented. Selecting between point cloud processing on DSP vs HWA will be dependent on your overall plan and how that affects the resource allocation. If you plan for additional algorithms to run on the DSP it would make sense to use the HWA based OOB but if you need maximal point cloud processing performance the DSP based chain could be better but then you leave the HWA resources unused. In general unless you are requiring very high doppler resolution the HWA point cloud processing performance should be sufficient.

    Ok, I understand much better ! Gtrack is totally free of hardware architecture, all that matters is giving it a pointcloud. I'll use structure of the Peoplecount Overhead Lab so. Thanks !

    AmandaN said:
    The current people counting labs only output point cloud and gtrack target outputs. There is no range azimuth output.

    Even if there is no range azimuth ouput currently, because it's a "low-level" data I won't have to do more computation, am I right ?

    AmandaN said:
    This limits the frame rate of the chirps to <5fps which is not ideal for accurate gtrack. You could consider a scheme that on some frames you output pt cloud and gtrack data and periodically on some other frames you only output heatmap.

    Sure, I noticed this major limit with OOB demo. I tought to send the heat map only when some event would occurred depending on gtrack output, but outputting the heat map periodically could be simpler and as efficient way. Thanks a lot !

    Best Regards,

    Quentin.