• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 1266 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

IWR6843: Adding gtrack to the demo project

Stefan Cubic
Prodigy 70 points
Part Number: IWR6843

I have been trying to add tracking to the SDK 3.4.0.3 demo project so that, in addition to the detection point cloud, target tracking information will be output.  As a tracking example, I have been using the Overhead 3D people counting demo.  In this example, the detections are made available in polar coordinates and since the tracker expects its inputs in Polar format, that works. 

In the out-of-box demo, detections are in Cartesian format.  Adding a tracker to this project has proven to be very complicated.  Apart from having to convert the detection format, the lab and demo project architectures are very different and integrating functions such as the tracker configuration (DPU_TrackerProc_config) is hard to do, since it does not easily fit into the demo structure.

What is the project structure philosophy that should be followed?  The gtrack library is included in SDK 3.4.0.3, but I see no examples of how it is to be used and the demo project's Cartesian format detections make it difficult to implement.  Which architecture will be supported in future?  Should I start with the 3D people counting lab and stick to it as a starting point?  It seems that those Industrial Toolbox lab examples do not persist for very long, while the SDK demo is evolving over time.  I would prefer to stick with an architecture that TI is also following because over time I'd like to upgrade parts of the project as a new SDK is released.  I'm looking for a recommendation for which project to use as a starting point if I want to develop a people tracking application for the IWR6843.  Or some tips on how to add the provided tracking library to the SDK demo.  I currently have the IWR6843 ODS device but would like to migrate to the AOP with ES2.0 silicon  

Thank you.

  • 0
    TI__Mastermind 30405 points

    Hi Stefan,

    Please refer to the Long Range People Detection Demos in Industrial Toolbox. We have both the 68xx (i.e. R4F + HWA + DSP) and 64xx (i.e. R4F + HWA only) versions as given below. These demos use the 68xx or 64xx OOB demo DPC and integrate the gtrack algorithm to realize a long range people detection and tracking solution.

    68xx/64xx Long Range People Detection demo

    We developed a custom DPU called the TrackerProc DPU which provides the DPU infrastructure around the gTrack lib. You can refer to the CCS projectspec to understand the directory structure but as a quick note, the code for the TrackerProc DPU and the corresponding object detection and tracking DPC developed for this demo is available in the following directory structure:

    68xx DPC: C:\ti\mmwave_industrial_toolbox_4_3_2\labs\common\src\dpc\objectdetectionandtracking\objdetdsp (DSP version)

    64xx DPC: C:\ti\mmwave_industrial_toolbox_4_3_2\labs\common\src\dpc\objectdetectionandtracking\objdethwa

    TrackerProc DPU: C:\ti\mmwave_industrial_toolbox_4_3_2\labs\common\src\dpu\trackerproc

    Regards

    -Nitin

  • 0 in reply to Nitin Sakhuja
    TI__Mastermind 30405 points

    Note that the same OOB demo + Tracker processing chain I mentioned above is also used in Traffic Monitoring Demos available in Industrial Toolbox, with different chirp configurations tuned for traffic monitoring use-case:

    68xx/18xx Traffic Monitoring Demo

    Regards

    -Nitin

  • 0 in reply to Nitin Sakhuja
    Prodigy 70 points

    Thank you for the reply, Nitin.  This Long Range People Detection lab project's architecture seems to be closer to the demo design in the SDK and the outputs are quite similar to those from the overhead people counting lab.

    1) This demo requires the Long Range Antenna Board.  You say the code is based on the OOB design, but for which board?  In the OOB lab, I see AOP and ODS designs, on which is this one based?  I'd like to migrate the design to the IWR6843 AOP and I assume there are some configuration setup commands that are different, but it seems that there are some hard-coded antenna geometry settings also.  Can you please indicate to me which of those need to be modified when moving from ODS to AOP?  Maybe there is no simple answer, but any information will help.  I realize that the long range will not work on the AOP, but we have  a short range indoor application.

    2) In the OOB folder I see a 68xx_aop_mmwave_sdk_hwa folder.  On the 6843, does HWA always refer to the R4F mss?  Just trying to understand the naming convention.

    3) Are the OOB lab designs what is actually programmed into shipped boards or is it the demo project in the SDK?  I do not understand the relationship between the SDK and what is in the OOB design and though they use the same GUI, the code is different.  I have been able to run the SDK demo using the CCS debugger.  But which one of those is the best starting point for new projects?  Are they related or maintained independently?  I know these sensors are new and I see new Toolbox and SDK releases from TI with improvements, so I would like to follow and incorporate those, but I can't see which one (OOB or SDK) is best to follow.

    4) I see that the DSP result in the Long Range People Detection lab now contains detections in both Spherical and Cartesian formats (in the overhead people counting lab only spherical was there).  So this must be a specific DSP configuration (different from the OOB).  And my guess is that this is necessary for tracking.  Maybe I am wrong with this goal, but I would like to keep my user modifications in the R4F mss only so that any new TI developments in the DSP can just be used.  Is this a bad strategy?

    5) A compiler option TRACKERPROC_ON_DSP allows for the gtrack library tracker to run in the DSP or on the MSS.  Is there an advantage to placing it in the DSP?  Resources or efficiency?

    Thank you.

  • 0 in reply to Stefan Cubic
    TI__Mastermind 30405 points

    1) This demo requires the Long Range Antenna Board.  You say the code is based on the OOB design, but for which board?  In the OOB lab, I see AOP and ODS designs, on which is this one based?  I'd like to migrate the design to the IWR6843 AOP and I assume there are some configuration setup commands that are different, but it seems that there are some hard-coded antenna geometry settings also.  Can you please indicate to me which of those need to be modified when moving from ODS to AOP?  Maybe there is no simple answer, but any information will help.  I realize that the long range will not work on the AOP, but we have  a short range indoor application.

    [NS]: The required module is listed (and hyperlinked) in the Hardware Requirements section of the demo user guide. This demo requires the IWR6843ISK standard antenna module (i.e. non-ODS) available here: https://www.ti.com/tool/IWR6843ISK. This demo is not targeted towards the AOP antenna module due to difference antenna geometries (both RX and TX). 

    2) In the OOB folder I see a 68xx_aop_mmwave_sdk_hwa folder.  On the 6843, does HWA always refer to the R4F mss?  Just trying to understand the naming convention.

    [NS]: We use _hwa in the names of the demos which use the Hardware Accelerator (HWA) and Cortex R4F only. The DSP is not used in these demos. The HWA refers to the Radar Hardware Accelerator. MSS refers to the Master Sub-System which contains the Cortex R4F core and various peripheral interfaces. 

    3) Are the OOB lab designs what is actually programmed into shipped boards or is it the demo project in the SDK?  I do not understand the relationship between the SDK and what is in the OOB design and though they use the same GUI, the code is different.  I have been able to run the SDK demo using the CCS debugger.  But which one of those is the best starting point for new projects?  Are they related or maintained independently?  I know these sensors are new and I see new Toolbox and SDK releases from TI with improvements, so I would like to follow and incorporate those, but I can't see which one (OOB or SDK) is best to follow.

    [NS]: Please refer to this thread for this question: IWR6843: Differences between demo in the SDK and OOB in the industrial toolbox

    4) I see that the DSP result in the Long Range People Detection lab now contains detections in both Spherical and Cartesian formats (in the overhead people counting lab only spherical was there).  So this must be a specific DSP configuration (different from the OOB).  And my guess is that this is necessary for tracking.  Maybe I am wrong with this goal, but I would like to keep my user modifications in the R4F mss only so that any new TI developments in the DSP can just be used.  Is this a bad strategy?

    [NS]: The OOB detection chain outputs Cartesian co-ordinates, but the tracker requires spherical co-ordinates which is why it is necessary to convert the OOB detection chain output to spherical co-ordinates before sending to the tracker. I would re-commend you to look at the 64xx version of the long range people tracking demo which is available in Industrial Toolbox 4.4.0 and above. The Cartesian to spherical conversion is done on the MSS (i.e. R4F) only before calling the tracker after the detection chain output.

    5) A compiler option TRACKERPROC_ON_DSP allows for the gtrack library tracker to run in the DSP or on the MSS.  Is there an advantage to placing it in the DSP?  Resources or efficiency?

    [NS]: This was an internal/development-only code and not a supported and maintained configuration. This will be removed this in the future versions of the demo. In this demo, the tracker is run on R4F to achieve the required memory and processing efficiency (as the DSP runs the bulk of the physical layer detection chain).

    Thanks

    -Nitin

  • 0 in reply to Nitin Sakhuja
    Prodigy 70 points

    Thank you for your answers, Nitin.  That helps.  In terms of the Long Range People Detection design not running on the AOP device: I noticed that between Industrial Toolbox 4.4.0 and 4.4.1 the Overhead People Counter demo has been re-targeted to also support the AOP device by only modifying the .cfg commands.  By only modifying the chirp and antenna geometry and such commands, can the Long Range People counter design also run on the AOP device?  Not to track long range, but for short range?  Or are there intrinsic design aspects that lock that design to the IWR6843ISK?

    Thank you.

  • 0 in reply to Stefan Cubic
    TI__Mastermind 30405 points

    Hi Stefan,

    The ability to configure antenna geometry using CLI commands is built into the Overhead People Counting Demo but it's not available in the Long Range People Detection Demo which is based on the OOB demo. 

    -Nitin