IWR1843BOOST: Clarification required to understand how the tracking id is generated?

Hello,

Please see the allocationParam documentation in the following document for more information on the track allocation thresholds.

3D_people_counting_tracker_layer_tuning_guide.pdf

If you are using the default CFG file, then only 3 points are needed for allocation. But maybe the minimum SNR threshold is not being met. I would try reducing the SNR threshold and increasing the points threshold to see if it helps generate tracks at longer distances and reduce duplicate tracks at short distances.

Regards,

Jackson

Hi Jackson Thomas ,

Thanks for the replay.

My question is related to  Industrial Toolbox 4.10.1, Traffic Monitoring for 18xx sensor ( IWR1843BOOST).
Is the document you shared apply to this also?

Mainly,

We are facing difficulties

1. To get the targetid of vehicles using the sensor, when the range is >40m.
2. The targetid assigned to the vehicle changes frames to frame when range is <40m

Any documents or articles related to fine-turning the result or a little information about how Ti cluster the cloud point to generate targetid would be really helpful.

Hello Asha,

Yes the document also applies to that lab. All the same fields might not be exaclty the same, but the tracker configuration will work the same. Did you try decreasing the SNR threshold and increasing the numPoints in the allocationParam command?

Regards,

Jackson

Hi Jackson Thomas,

Sorry for the late reply, I was experimenting with the devices. When I increased <pointsThres> in allocationParam according to the document shared 

allocationParam 60 50 1 3 5 50.0 , There were fewer targetid was getting in tm_visualizer and when I decreased it the targetid association was better

However I have come across following issues,

ISSUES

• In the tm_visualizer I could see 2 targetid 3 and 4 being associated
• When I checked log file corresponding to the framenumber 132
  • None of the 54 points has targetid as 3,  51 points have targetid 254, 2 points have targetid 4, 1 point has targetid 255
  • according to allocationParam , <pointThre> is 3  But targetid 4 has only 2 points. How the algorithm were able to associate this targetid to 4?
  • There are no points which has targetid 3 but in UI targetId  3 is being shown

Please let me know what I'm missing and help me understand how Ti is clustering/ associating poits and generating the target id .

Hello,

The allocation param <pontsThresh> only limits the creation of the track. For frames after the track is created, there is other logic than just number of points to keep the track alive. Actually just 1 points is typically needed. This is where the stateParam command is used. The stateParam changes how long a track will stay in a certain state. You may want to change the active2free or static2free thresholds to remove this track faster.

However, I would look at the data and look for the first frame that TID3 appears. Then you can look at the associations and see how many of the points are associated with TID3 during track allocation.

Regards,

Jackson

Hi Jackson Thomas

I'm very new in working with sensor,  So may I ask what is TID3?

Also could you please explain a bit more about how to check number of points associated? 

From your explanation and reading the document what I understood that stateParam changes the state of track depends on the configuration provided. But I didnt understand how it is related to Issues mentioned in above thread ( sensor being able to associate a tracking id 3 in UI but the log doesn't show it. and second issue is being able to associate point clouds to tracking id even when number of points associated is less than <pointThres> as in allocationParam

Appreciate if you can elaborate a bit.

In a single frame, checking the log file it gives N points as shown in the Pt Clound in tm_visualizer.

Some points are associated with valid target ids and many points are associated with 254.

How does Ti classify/ group these points to a specific target id ? What parameters from the log file are considered for associating a point from a frame to a target id?

Hello,

Please make sure you have read the bottom section of the traffic monitor lab user's guide that explains the data format of the UART coming out of the device. There will be point cloud, track info with target ID (TID), and target index which maps the point cloud to a specific track.

Index 253,254, and 255 are different forms of not associated to any target. The other points should have an association to one of the tracks (also called target ID or TID). Based on the settings in stateParam, some tracks can stay active for many frames without any points being associated. This can help tracking objects that are not moving much. If you do not want this behavior, you can modify the stateParam values and the tracks will disappear instantly.

For much more detailed info about the tracking algorithm, you can see the following document.

Tracking_radar_targets_with_multiple_reflection_points.pdf

Regards,

Jackson

Jackson Thomas

Thanks for the explanation. 

Jackson Thomas said:

Based on the settings in stateParam, some tracks can stay active for many frames without any points being associated. This can help tracking objects that are not moving much.

" tm_visualizer view for frame number 132 as shown above is showing the track of object from earlier frames (TID3). But in the log corresponding to the frame number 132 there is no target id 3 "

Does this means GUI of tm_visualiser is not 1-1 correspondence with sensor log generated , and GUI use some algorithm to continue to show the TID3 based on earlier frames from log file? 

• If so , what is the exact parameter to change in stateParam inorder to get 1-1 correspondence with TID generated on tm_visualizer and log file? 
• Can you suggest any documents which tell more idea about like how many frames need to have TID in logs for tm_visualizer to show in GUI ?

Hi Asha,

It should be 1:1 with the GUI and data, as the GUI just displays the output of the sensor, it doesn't do any more calculations to find tracks or pointcloud. Is there a TID3 reported in the previous frame? Can you send me your data and config file? I can take a look and see what might be happening.

Thanks,

Jackson

Hi Jackson Thomas

I'm confused now.

If tm_visualizer is having 1-1 correspondence with log data, then I don't understand why TID3 in tmvisualizer GUI has sown above has no corresponding data for the same frame number 132. And yes some of previous frames have detected TID3. 

Attaching the parsed log file in text format

parseredlog.txt

and converted log file in csv format ( for more readability)

parsed_converted_data.csv

If you check the log corresponding to framenumber 132 for whioch tm_visualizer view is shared previously you can see that 

• None of the 54 points has targetid as 3,  51 points have targetid 254, 2 points have targetid 4, 1 point has targetid 255

if tm_visualiser GUI view and log data view is having 1-1 correspondence then I am expecting TID 3 in the frame number 132

The config params are as follows

sensorStop
flushCfg
dfeDataOutputMode 1
channelCfg 15 5 0
adcCfg 2 1
adcbufCfg -1 0 1 1 1
profileCfg 0 77 8 7 28 0 0 20 1 256 12500 0 0 48
chirpCfg 0 0 0 0 0 0 0 1
chirpCfg 1 1 0 0 0 0 0 4
frameCfg 0 1 64 0 50 1 0
lowPower 0 0
guiMonitor -1 1 0 0 0 0 0
cfarCfg -1 0 2 8 4 3 0 10 0
cfarCfg -1 1 0 4 2 3 1 12 0
multiObjBeamForming -1 1 0.5
clutterRemoval -1 1
calibDcRangeSig -1 0 -5 8 256
extendedMaxVelocity -1 1
bpmCfg -1 0 0 1
lvdsStreamCfg -1 0 0 0
compRangeBiasAndRxChanPhase 0.0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0
measureRangeBiasAndRxChanPhase 0 1.5 0.2
CQRxSatMonitor 0 3 5 121 0
CQSigImgMonitor 0 127 4
analogMonitor 0 0
aoaFovCfg -1 -90 90 -90 90
cfarFovCfg -1 0 0 80
cfarFovCfg -1 1 -30 30.00
staticBoundaryBox -40 40 20 70 -3 3
boundaryBox -50 50 10 80 -3 3
gatingParam 20 15 15 15 200
stateParam 15 10 10 1000 10 1000
allocationParam 60 50 1 3 5 50.0
maxAcceleration 50 50 0.1
trackingCfg 1 2 250 20 135 422 50
sensorPosition 2 0 0
presenceBoundaryBox -3 3 2 6 0.5 2.5
sensorStart

Please note:

the sensor recordings are based on actual moving car. there was only one car being used in the experiment.

Thank you Jackson Thomas,

It really helped me understand it concept. Thank you so much for the continued support and help. Really appreciate your efforts .