IWR1642BOOST: Method of finding the size of the vehicle from the tracking result

Part Number: IWR1642BOOST


I'd like to make a judgment as to whether the vehicle detected by tracking is a large car or a small car.
(For example, if the length of the vehicle is 8 m or more, I would like to judge it as a large car)

Can I calculate the size (length, width) of the detected vehicle from the tracking result using GtrackLib?
If you can not ask for, how do you guess the size?


7 Replies

  • Hello Koji,

    It is possible to estimate the dimensions of a tracked object you can either

    A) implement it in your application using the information provided by gtrack. If you examine the Target Index TLV it reports if and to which Target ID each point in the point cloud is assigned to. From there you can extract the point cloud of each target and then calculate the general dimensions of the point cloud to estimate the size of the target.

    B) A method to estimate the dimensions of a target has been implemented in the updated version of gtrack. If you download, mmWave SDK version 3.0.8 and examine this updated version of the gtrack lib there is a function gtrack_calcDim that implements a size estimation. You can either update your application to use this newer gtrack or use the source code as reference.



  • In reply to AmandaN:

    Hi, Amanda
    Thank you very much for your reply.

    I tried GtrackLib of the latest version of SDK.
    We also modified the MEX function.
    As a result of step processing, we were able to confirm that "dim" can be acquired.

    However, I doubt that the value is reasonable.

    The figure below shows the tracking result of the 38th frame of "fHistRT_0001.mat".

    The bubble is horizontally long. (Conventionally it was lengthwise long)
    Also, "dim" at this time is as follows.
    dim =

      3 × 2 single matrix

        0.4948 1.1330
        2.3353 3.3838
        0.9192 0.4728
    I think that the first row is the length of the vehicle and the second row is the width of the vehicle.
    I think that the unit is "meter"
    The length is too short.

    · Issues that the bubble is horizontally long
    · Problems in which the width of the vehicle is reported short
    Is there anything I should check about these issues?


  • In reply to koji fukumoto:

    The parameters passed to gtrack_create are as follows.

    [config.stateVectorType = 1]
    [config.verbose = 0]
    [config.maxNumPoints = 250]
    [config.maxNumTracks = 20]
    [config.initialRadialVelocity = -5.000000]
    [config.maxRadialVelocity = 7.515934]
    [config.radialVelocityResolution = 0.469746]
    [config.maxAcceleration[0] = 0.000000]
    [config.maxAcceleration[1] = 4.000000]
    [config.maxAcceleration[2] = 0.000000]
    [config.deltaT = 0.050000]
    [gatingParams->volume = 12.000000]
    [gatingParams->limits.width = 4.000000]
    [gatingParams->limits.depth = 8.000000]
    [gatingParams->limits.height = 0.000000]
    [gatingParams->limits.vel = 0.000000]
    [gatingParams->limitsArray[0] = 4.000000]
    [gatingParams->limitsArray[1] = 8.000000]
    [gatingParams->limitsArray[2] = 0.000000]
    [gatingParams->limitsArray[3] = 0.000000]
    [allocationParams->snrThre = 60.000000]
    [allocationParams->snrThreObscured = 60.000000]
    [allocationParams->velocityThre = 1.000000]
    [allocationParams->pointsThre = 3]
    [allocationParams->maxDistanceThre = 2.800000]
    [allocationParams->maxVelThre = 2.000000]
    [stateParams->det2actThre = 3]
    [stateParams->det2freeThre = 10]
    [stateParams->active2freeThre = 20]
    [stateParams->static2freeThre = 2000]
    [stateParams->exit2freeThre = 10]
    [variationParams->widthStd = 0.433000]
    [variationParams->depthStd = 1.150000]
    [variationParams->heightStd = 0.000000]
    [variationParams->dopplerStd = 1.000000]
    [sceneryParams.numBoundaryBoxes = 1(-2.000000,15.000000, 10.000000,75.000000, 0.000000,5.000000)]
    [sceneryParams.numStaticBoxes = 1(1.250000,11.000000, 20.000000,50.000000, 0.000000,5.000000)]
  • In reply to koji fukumoto:


    The data in fhistRT_0001.mat may not be ideal for determining the dimension of the object.

    The dimension is based on the point cloud as you can see in the left side of the plot, there are very few point clouds and thus gtrack is not robust to determine the dimensions of from 1 or 2 points.

    The original aim of the TM testing and data collection did not involve being able to dimension the object.

    I would suggest that it would be better to adjust the CFAR to achieve more points and collect new fhist data files to test the ability to dimension vehicles.

  • In reply to AmandaN:

    Thank you for your reply.

    Using GtrackLib in SDK, a vertically long bubble will be displayed even for the same data (38th frame of "fHistRT_0001.mat").
    Please see the figure below.
    Why is this?
    Does the old GtrackLib incorporate "a vertically oriented algorithm"?

  • In reply to koji fukumoto:

    Hello Koji,

    The sides of the bubbles are related to the gating parameters - not the dimension of the tracked objects. This would require modification to tm_play for the visualization.

    In the original tm_play and gtrack the gating parameters are less constrained in the Y direction because we expect vehicles to move along and span that axis and less so along the x axis.

  • In reply to AmandaN:

    Hi Amanda.

    I understood that the old GtrackLib has "logic that reduces constraints in the Y direction (that is, the logic in which the bubble becomes longer vertically)" is incorporated.
    The doubt has been resolved. Thank you very much.

    Please tell me only one more thing.
    I'd like to port the "logic that reduces constraints in the Y direction" to the new GtrackLib.
    Where is that logic?
    Please tell me the name of the function etc.