IWR6843ISK: Traffic monitoring lab from industrial toolbox 4.8

Hello,

The gui is throwing this error. It seems that the cfg default matches the CLI command in the source code. Check the gui cfg parser function, it may not have been updated with the latest tracker. The device is expecting 6 parameters. I don't think this would cause too many issues, as the tracker would use default parameters, but tracks might not disappear at the right times.

Look at the parseBytes_TM.m file for how to parse the data. This function will parse the UART stream into the TLVs you listed. You will need to add another function to take this data and save it to a file. It will need to be run from matlab source code. Please let me know if you have other questions.

Regards,

Jackson

Hi Jackson,

thanks very much for helping me. I did a few traffic measurements with radar mounted next to the road at 4 m height, tilted down by 10 degrees, with 0 yaw in azimuth. Working with the lab as is, I recorded a number of reasonable tracks but observed that the tracker performs weird sometimes by producing ghost tracks and extrapolating the target tracks in a strange way. Firstly I was using the default 2D configuration, then I modified the tracker parameters, namely sensor position (4 0 0 instead original 2 0 0, is this height / tilt / yaw?) and then the GUI stopped tracking anything, it was only visualizing point clouds.

Could you look through the original configuration below and correct the parameters where necessary so that the device accepts all of them without errors? Many thanks in advance.

Parsing the data will be the next challenge.

Best,

Timofey

68xx_traffic_monitoring_70m_MIMO_2D.cfg

% Range Resolution(m):0.366
% Maximum unambiguous Range(m):75.0
% Maximum Radial Velocity(m/s):17.36
% Radial velocity resolution(m/s):0.5425
% Frame Duration(msec):50
% ***************************************************************

% *****************STANDARD MMWAVE SDK COMMANDS******************
sensorStop
flushCfg
dfeDataOutputMode 1
channelCfg 15 5 0
adcCfg 2 1
adcbufCfg -1 0 1 1 1
profileCfg 0 60 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 4 63 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

% *****************TRACKING COMMANDS*****************************
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 113 355 50
sensorPosition 2 0 0
presenceBoundaryBox -3 3 2 6 0.5 2.5

% *****************SENSOR START*********************
sensorStart

Hello, the issue is probably the boundary box, or if you modified the wrong tilt in sensor position. Please look at the following document for info on the tracking parameters.

3D_people_counting_tracker_layer_tuning_guide.pdf

Regards,

Jackson

Hello,

1. Azimuth tilt is still not implemented.
2. You are correct, this is not how the cfg file should be. Z height should be in world coordinates from ~0 - 3, or other area of interest.
3. presenceBoundaryBox can be reconfigured. This is just a holdover from the peopleCounting applications
4. max acceleration is set just to not limit detection
5. it is an absolute value parameter, so -40 to 40, as tracks will be allocated in either direction
6. The 3D cfg file has an extra chirpCfg parameter that enables the third antenna for elevation estimation. The 2D config only sets up a chirp profile that resolves 2D data.
7. You can see this in the tracker_utils.c function for that trackerConfig function from CLI. However, these are just default values, so when you provide the entire configuration, the values from this pre-defined set get overwritten.
8. The latest version is linked above.

Regards,

Jackson

Hi,

in spite of the small presenceBoundaryBox in the demo the tracker was marking vehicles as tracked from Y=5 to 25m, which means that box is not crucial, right? Looking into G-track's C-code I find more presenceParams than described in the guide and given in the lab, more specifically

presenceParams.pointsThre
presenceParams.velocityThre
presenceParams.on2offThre

Can you shed light on how to define these?

Thanks,

Timofey

Hello,

You are correct, the presence boundary box does not limit tracking performance at all. You can see in the tracker tuning guide that this is separate from the tracker and will only provide a preliminary indication of presence.  If you look more at the source code, there should be the logic for using these values to determine a presence indication. They are just the threshold values (similar to the tracker thresholds) to indicate a presence.

Regards,

Jackson

Hi,

in the source code I see 3 interesting parameters in the output structure for each target

1) tracking unit identifier - uid

2) target identifier - tid

3) confidenceLevel

In case of one simulated target which gets tracked correctly I am getting uid = 0, tid = 1, confidenceLevel = 1.0.

In case of two simulated targets I am getting uid = 8, tid = 9, confidenceLevel = 0.45 for example.

Should I keep only the targets with uid = 0 and confidenceLevel = 1.0 ???

Thank you.

BR

Timofey

Hello Timofey,

I don't understand what you mean by simulated targets. Are you running the tracker with simulated input pointcloud? Or are you just trying to understand from theoretical examples?

--Jackson

Yes, we compiled the latest G-track in Matlab and I am feeding it with simulated point clouds to tune its input parameters and output target structures. Firstly, I simulated one vehicle with a bit randomized (R,V,azimuth) plus the SNR proportional to 1/R^4, and received a nice track with confidence 1. Then I added another vehicle in the adjacent lane and the tracker gives me at certain instances more than 2 active tracks...

I see. I think both of those should be ok. Anything output by the tracker should be considered 'valid', you could filter based on confidence level from there. However, if the tracker determines one target is behind another object, it will set the max confidence level to 50%, which is likely why you see lower confidence in the 2 object case. You can see more of the details in the following document, search for confidence level.

Tracking_radar_targets_with_multiple_reflection_points.pdf

Regards,

Jackson

Thanks! I am still working with that and will keep this thread open for a while in case of new questions.