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.

• Resolved

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

Part Number: IWR1642BOOST

Hello.

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?

Thanks.

• 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

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.

• In reply to koji fukumoto:

Supplement.
The parameters passed to gtrack_create are as follows.

[config.stateVectorType = 1]
[config.verbose = 0]
[config.maxNumPoints = 250]
[config.maxNumTracks = 20]
[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:

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

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").
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.

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.

• In reply to koji fukumoto:

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

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.
• In reply to koji fukumoto:

Bump