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

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.

Amanda

 

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?

Thanks.

Supplement.
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)]

Koji,

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.

Amanda

Thank you for your reply.

Using GtrackLib in SDK 02.00.00.04, 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"?

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.

Amanda

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.

Thanks.

Koji,

This is a difference in the gtrack libs. Previously the allocation parameters were hardcoded and static. In the newer version the allocation parameters are adaptive and thus if points appear in x and y the gating boundary will also grow.

Amanda

Hi Amanda
Thank you for your reply.

I understood the following.
------------------------------
The old GtrackLib (which is in mmwave_sdk_0 2 _ 00 _ 00 _ 0 4) has allocation parameters hard-coded,
The new GtrackLib (it is in mmwave_sdk_ 03 _ 00 _ 00 _ 08)) is adaptive as it is not hard-coded.
------------------------------

However, looking at "C: \ ti \ mmwave_sdk_02 _ 00 _ 00 _ 04 \ packages \ ti \ alg \ gtrack \ src \ gtrack_create.c", "allocationParams" is not hard-coded and adopts the value specified from the top.
Actually, changing the allocation parameters with tm_play will change the size of the bubble.

"Logic with less constraint in Y direction" That is, "hard-coded description" is
(1) Which file
(2) Which function
Is it in?
(I thought that (1) is "gtrack_unit_score.c" (2) is "gtrack_gateCreateLim." However, it seems not to be)
I am very happy if you give a detailed explanation of the number of lines in the file.

Thanks, Have a Good Year.

Bump

Hello Koji,

By hardcoded I mean predetermined/set at beginning of runtime by specifying the values.

In opposition, in the newer version as the code is running the values can adapt.

Amanda