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.

IWRL6432: Demo selection for application

Part Number: IWRL6432
Other Parts Discussed in Thread: MMWAVE-L-SDK

Hi

I am using a TI mmwave radar on a moving platform. The objective is to detect both moving and static objects, but the platform is moving as well. I want to detect all sorts of objects, and I am interrested in the position as well. Therefore, the output from the sensor will be the point cloud. I dont really care about the velocity of the object.

I am currently deciding between Motion and Presence detection demo (MPD) and the mmwave demo (OOB). I see the MPD runs CFAR using range and azimuth, but OOB demo runs CFAR on range and velocity.

Can you explain which demo you recommend and the reasoning behind the different approaches in the detection layers?

  • Although knowing exactly how fast the object is going may not be the most important for your application, using doppler to differentiate dynamic (person walking) and stationary (person standing) objects from static ones (furniture, walls, etc) can be very beneficial for detecting all kinds of objects. With Radar on a moving platform, the ideal case is for the Radar to be fed odometry information by an IMU in the system. This way the radar sensor's data gets context on whether it itself is moving or if everything around it is moving. In an ideal scenario with no memory nor interface limitations, it would be good to use both range-azimuth-elevation heatmap AND range-doppler heatmap as they are good at isolating objects under different scenarios and using both provides full coverage of what radar could detect. If you have to choose only one, I would say range-doppler should be used while the sensor is static and range-angle while in motion.

    Best Regards,

    Pedrhom

  • Thank you for your reply. I have a couple of questions related to this:

    1) Let's say I can feed very accurate odometry information (2d) to the radar, then where in the processing chain would this information be used and do you have any implementation examples? If it is solely used for post processing the data, I can just do the post processing on my controller.

    2) Currently I transmit the point cloud with side info. So essentially this can be translated into both of the heatmaps, correct? As for each point I can get the distance and velocity, but I can also get distance, azimuth and elevation? Can you explain how you would use the heatmaps? Thanks.

  • Hello,

    Using the common automotive implementation as a use case, they get the raw Radar data (complex I/Q) from the front end directly and do the processing on an external central controller. This method is the easiest for combining information across several pieces of hardware. The alternative is getting the point cloud off of the sensor while enabling clutter removal and setting the point cloud CFAR and velocity based thresholds very low. Then doing an extra level of filtering based off of the IMU and whatever other properties you'd like.

    Below is a diagram from the MMWAVE-L-SDK's User Guide for the Motion and Presence Demo:

    The heatmap is the detection matrix and is a pre-requisite step for point cloud generation. It does not make sense to take the pointcloud and inversely get the matrix from that and you should just interface with the matrix directly for the heatmap. If you enable the heatmap via guiMonitor within the configuration file sent to start the sensor, you can get the range-azimuth one with no changes to the existing SDK

    Best Regards,

    Pedrhom