• State TI Thinks Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 113 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

IWR6843AOP: Timing Details for IWR6843AOP Radar Data Processing and Integration with ROS

TI-CSC
Genius 11765 points
Part Number: IWR6843AOP

Tool/software:

Hello E2E Experts,

Good day.

I plan to work with the IWR6843AOP radar sensor and planning to use its ROS driver for data integration. I have a few questions regarding its timing characteristics:

  1. Data latency: How long does it typically take for the radar to process the reflected electromagnetic waves and send the processed data to the computer? I understand that this involves the onboard computation time of the radar. Is there an average or estimated value for this delay?

  2. ROS timestamps: When using the ROS driver for the IWR6843AOP, does the driver assign the computer’s clock timestamp to the messages (e.g., when reading from the serial/USB port)? If so, I guess then that timestamps do not reflect the "real" timestamps of data arrival. Is there an average or estimated value for this delay?

  3. IMU synchronization: I want to hardware-trigger the radar in sync with an IMU. Is there any guidance or best practice for achieving precise synchronization in such a setup, considering the potential processing and communication latencies of the radar?

Any insights into the average radar processing time and the behavior of the ROS driver regarding timestamps would be greatly appreciated!

Regards,

TICSC

  • 0
    TI__Intellectual 2390 points

    Hi,

    We are looking into your query. Please allow us a couple of days to respond.

    Regards,

    Sharan

  • 0 in reply to Sharan S S
    TI__Mastermind 19147 points

    Hello,

    1. For delay, it's in milliseconds but it changes substantially based on what demo is running and thus what processing and outputs are being computed. If you want an exact time measurement for your example + config, I recommend setting a print line in your application code, running it in debug mode, and checking time stamp to see the amount of time processing takes. We use the same methodology internally, for example for determining machine learning model on-chip time elapsed.

    2. In ROS, the time stamp seen in the radar_scan msg is currently the computer's clock. If you want the Radar chip's time stamp, it is sent in the header part of each frame right after frameNumber and right before numDetectedObj. I am not sure if you are using ROS1 or ROS2 so the notation will be different, but something along the lines of changing radarscan.header.stamp = nodeHandle->now(); to radarscan.header.stamp = mmwData.header.timeCpuCycles;

    3. You can use the SYNC_IN pin if it must be a hardware based trigger. Unfortunately on the IWR6843AOPEVM the SYNC_IN pin is only accessible after a board change, fortunately it is one very small change. https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/750656/iwr6843-sync_in-hardware-trigger

    Best Regards,

    Pedrhom