This thread has been locked.

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.

AWR1843BOOST: Azimuth angle for moving object is NOT calculated

Part Number: AWR1843BOOST
Other Parts Discussed in Thread: AWR1843

Hi,I found a similar phenomenon.

 Environment:

1). AWR1843 EVB

2).lab0007_medium_range_radar(USRR subframe only)

We used pedestrians as obstacles to test in the open area outdoors, and pedestrians walked back and forth in front of the radar.and the angle difference of the target detected is around 3° between the pedestrian is far away from the radar and the pedestrian approaches the radar.

There is another problem at the same time,the approaching pedestrian is divided into two targets with great height difference (for example, at a distance of 15m from the radar, the height of one target is greater than 1.5m, and the height of the other target is less than - 1.5m), and the horizontal angle difference between the two targets is about 10 °

But we didn't find this problem when we only used MRR subframe。

  • We just changed the output mode of the target in MSS (from UART output to can output, using our own PC to display)

  • Hi,

    I think the reason behind this is that MRR uses clustering and tracking. Do you see multiple points for the same pedestrian in MRR pointcloud itself? It could be that the clustering/tracking creates a single target output for them.

    Regards,

    Aayush

  • Hi,If it's true as you said, the phenomenon of moving away from and close to the target should be similar。

    In fact, in the video, we only output cloudpoint of usrr, not trackingpoint and clusterpoint

    /**! @brief The multi-mode Radar mode of operation. */
    //#define SUBFRAME_CONF_MRR_USRR /* Two subframes, MRR followed by USRR20. */
    /**! @brief The USRR only mode of operation. */
    #define SUBFRAME_CONF_USRR /* One subframe USRR20. */
    /**! @brief The MRR only mode of operation. */
    //#define SUBFRAME_CONF_MRR /* One subframe MRR80. */

  • Hi,

    I understand that you are only working with the pointcloud. 

    Could you clarify the following for me: 

    when you say you don't see this problem in the MRR subframe, is it at the same distance as the distance for which you see the issue in the USRR frame?

    Also, do you mean that you don't see this issue in the MRR pointcloud itself? Because the clustering and tracking outputs work on clusters, so it is possible that the MRR clustering/tracking output is not split in two.

    Also, I'm not really sure what I'm looking at in the video you shared. Is this a single person walking towards and away from the radar? At the 5 second mark, are there multiple people in the scene?

    Regards,

    Aayush

  • In my test, a pedestrian first moves away from the radar position to the front of the radar, and then approaches the radar in the same way.

    when you say you don't see this problem in the MRR subframe, is it at the same distance as the distance for which you see the issue in the USRR frame?

    Also, do you mean that you don't see this issue in the MRR pointcloud itself? Because the clustering and tracking outputs work on clusters, so it is possible that the MRR clustering/tracking output is not split in two.

    -------MRR did not have any problems during the test,both trackingpoint and cloudpoint are normal during the test, and the trajectory of the target point is consistent when it is far away from the radar and close to the radar, and there is no splitti.

    Also, I'm not really sure what I'm looking at in the video you shared. Is this a single person walking towards and away from the radar? At the 5 second mark, are there multiple people in the scene?-----Sorry, I'll explain it in detail in the screenshot

  • Hi,

    I have had a talk with the developer of the lab. He says it is likely that there may be a bug in the doppler compensation code in the lab. It compensates for positive velocities correctly, but doesn't do so for negative velocities, which causes a single object to be seen as a smear of multiple objects.

    I will talk to the team internally to see how this issue may be fixed, but I don't think there will be a quick resolution to this.

    Regards,

    Aayush

  • Thanks for your reply and look forward to your solution.

  • Hi,

    We are not sure if this is a bug. The developer of the lab tells me that this could also occur in the USRR subframe if the object velocity is close to the max velocity, which is relatively low for the USRR frame. If not, this might be a bug in the doppler compensation logic.

    I am going to close this thread for now and investigate if this is a possible bug. I will not be able to provide a response for this in the same thread however.

    Regards,

    Aayush