TIDEP-01017: Radar SDK usecases issue

Hi, Piyali

I try to create the calibration file, and i put it into SD card.

Then I can watch point cloud from GUI, but two issues were happened.

1. The radar will crash, if i change GUI output option to "1 1 0 0 1".

2. When the GUI output setting is "1 1 0 0 0", the radar can work.(fig.1)

But the frame lost issue was happened.(fig.2)

Could you give me advice?

Thanks 

Morris

fig.1

fig.2

Hi, Piyali

I use the Ethernet monitor software to get the TCP and UDP packages of this demo.

I use the static IP, and Radar's IP is '192.168.33.200'.

The PC's IP is '192.168.33.30'.

When the demo is running, i find a problem.

At the beginning, i can receive the correct UDP package. (fig.1).

I receive the wrong UDP package when the demo is running for some time(fig.2).

The TFDTP header is wrong, because the total seq and offset over the buffer's boundary.

Could you give me advice?

Thanks 

Morris

fig1.

fig2.

Hi

I am not sure I follow:

When you mention "The TFDTP header is wrong, because the total seq and offset over the buffer's boundary.", which buffer are you referring to here?

The offset is actually calculated based on the total size of the frame being transmitted in chunks. 

Thanks and Regards

Piyali

Hi, Piyali

The buffer is dataArraay of "radar_cascade_demo.m", and the size is 65536 bytes(fig.1).

When the offset and total size of frame are wrong, the data will be out of the boundary of dataArray.

Can you check the UDP packages?

Thanks.

Morris

fig.1

Hi Morris,

Are you sure the data is not getting accumulated or something? I am yet to look into the details, but we need to check if the tfdtp buffer is flushed after the transaction so that redundant data is not transferred. I am assuming the 65k buffer size which you mentioned is not just any arbitrary large number and is some limit which is agreed upon from both ends. Let me check these pointers internally and get back to you. I really doubt this is a TFDTP bug. 

Hi, Piyali and Anand

I try to use the Processor SDK 3.08, and i still get the issue.

So I change the GUI output options to test each output option.

Then, I  found some issue.

1. Although the frame size of udp package is over 65536, it is correct except the Point Cloud and Noise Profile options.

2. The Point Cloud is not correct because the size of package  always increases.

According the message header in figure 1 (Blue line), number of the detection objects is 28 (0x1C).

But the data length of pointer cloud (Green line) is 759168 (0xB9580), it is about 17253 points (size of one point is 44 bytes).

I think the Radar does not clear the data buffer of point cloud.

Can you check these issue?

Thanks.

Morris

fig.1

Hi Morris,

I will ask a radar expert to look into this.

Hi, Stanley

I follow your describe to edit the file, then the package size of point cloud is correct.

Now, I find a new problem.

When i take a corner reflector leaving the radar, i can watch the object  leaving on GUI.

When i take a corner reflector approaching the radar, I can't see the object approaching on GUI at the far end(>2m).

Please find attached video  for reference.

Could you give me advice?

Thanks 

Morris

Video 1

Hi Morris,

Could you try using SDK 3.8 release and see if the result is better?

We fixed an issue with signal integrity when configuring radar front end. Please do the calibration again after moving to 3.8 release.

However, the point cloud issue is not fixed in SDK 3.8 release so the workaround is still required for point cloud.

Regards,
Stanley

Hi, Stanley

I have already used the SDK 3.8, and do the calibration again.

Then the result is the same.

Please give me advice.

Thanks.

Morris

Morris

Do you continue to face issues here? Are you able to see the object in the range - doppler heat map or the range profile? If yes, then this may be a tuning parameter of the CFAR peak detection for positive Doppler bins.

Thanks and Regards

Piyali

Hi, Piyali

I can see the object in the range-Doppler heat map, and it is correct. (video 1)

Then, I try to tune parameter of the CFAR, and I watch the point cloud again.

When I take a corner reflector leaving the radar, I can watch the object  leaving on GUI. (Video 2)

When I take a corner reflector approaching the radar, I can see the object approaching on GUI.(Video 2)

But it is not stable.

I think the reason of this issue is not CFAR, because the amplitude of the object is the same in the same range.

Could you give me advice?

Thanks 

Morris

video 1

video 2

The way to debug this would be to capture the ADC frame and the intermediate outputs of the FFT, and CFAR detection for the case when the object is moving closer to the radar sensor. I believe the object is very clearly identified when it is stationary at a given distance is that right?

Also, can you try setting the test source data of the object moving closer to the radar and see if the processing chain in your case is able to detect the objects clearly. If that is creating an issue, then it becomes eaiser to debug what could be going wrong, without real world data capture..

Like you rightly see in the FFT heat map the amplitude is very clear in the case when the object is coming closer to the radar.. 

The instability could only indicate that the CFAR somehow is not detecting the peaks consistently for every radar frame, hence getting the data capture and comparing frame by frame to see when the CFAR stops detecting the points would be interesting.

Thanks and Regards

Piyali

Hi, Piyali

Thank you for your suggestion.

First, we can see the approaching target and leaving target with the same RCS at the Doppler-Range heat map from the first video.

So we think the process before the FFT is correct.

But the approaching target is not shown clearly compared to the leaving target as we observe the result of the Doppler-Range plot from the second video.

We are so confused by the difference between the result from these two video.

We guess maybe there is something wrong in the CFAR process.

Please help us to figure out this problem.

Thank you so much.

Hi Morris,

The logic of CFAR is in the function: AlgorithmFxn_RadarDspCfar_caall in the file: C:\PROCESSOR_SDK_VISION_03_08_00_00\vision_sdk\apps\src\rtos\radar\src\alg_plugins\alg_fxns\radardspcascademimo\priv\radarDspCascadeMimoCfar_priv.c

The different steps in this API are:

1. Log Magnitude calculation of the FFT output - if the log magnitude is being used. Note opBufEnergySum is arranged as Range Bins x Doppler bins as a 1D array. (R0D0, R1D0, R2D0, ..... RnD0, R0D1, R1D1, R2D1, ..... RnD1 and so on)

2. Then we loop through all the doppler bins and first try and find the peak in the range dimension through the function: mmwavelib_cfarfloat_caall. This function is defined in C:\PROCESSOR_SDK_VISION_03_08_00_00\ti_components\algorithms\mmwave_sdk_01_02_00_05\packages\ti\alg\mmwavelib\src\detection\mmwavelib_cfarcaall_float.c

First thing to check would be in the data you are generating are you able to detect the peak in the right range bins as the output of this function. In order to do this, start by bringing the corner reflector from a far distance to a near by distance. Have CCS connectivity to the board.

Connect to the DSP1 and set a breakpoint at mmwavelib_cfarfloat_caall call in C:\PROCESSOR_SDK_VISION_03_08_00_00\vision_sdk\apps\src\rtos\radar\src\alg_plugins\alg_fxns\radardspcascademimo\priv\radarDspCascadeMimoCfar_priv.c

It would be good to build the DSP in the debug profile to help step through the code. Make sure to load the symbols from the DSP, if you are booting the board through SD card.

Once you have the code hit the breakpoint in mmwavelib_cfarfloat_caall, step over the function and check the output of tempRangeIndex and tempDetected. If you find that the range is detected correctly based on the FFT output, then we can move on to debugging only the detection in the Doppler range. If the range is not detected correctly then we need to step through the mmwavelib_cfarfloat_caall 

3. The doppler index around which the peak is detected is calculated next with a doppler search window:

An example to understand the for loops in the code is as below:

Assume:

Then the indices will look as below:

Graphically the search window moves as shown below:

The red cell is the cell (or full range) under test and the green cells are the ranges against which the Cell is compared for every detected range point.

If you see that the range indexes are showing correctly, please step through the code to see if the doppler indexes are showing up correctly or not when the object seems to disappear.

One other quick experiment to isolate whether the range CFAR detection is a problem or doppler is to disable enableSecondPassSearch. Set the enableSecondPassSearch to 0 in C:\PROCESSOR_SDK_VISION_03_08_00_00\vision_sdk\apps\src\rtos\radar\src\usecases\cascade_radar_object_detect\chains_cascadeRadarOd.c

If you see the data is stable then you would know that the range detection is stable and the doppler detection for CFAR has some issues. Once this is established, you can step through the doppler code to see what causes the doppler search to dismiss a peak.

If you find the object is still missing when the enableSecondPassSearch is 0, then you can step through the range search to check what is going wrong in your setup.

Thanks and Regards,

Piyali