Carla messages cannot reach Autoware

[MarioAlmelaUMH]

Hi @evshary.

I am contacting you because we have recently realized that some messages generated by Carla cannot reach Autoware. We believe that these messages are lost (probably discarded) when passing through the Zenoh-based bridge.
For example, we compared the clock messages retrieved from Carla in the "publish_clock" function of the bridge (inside the zenoh_carla_bridge/src/clock.rs file) with Autoware's /clock topic messages recorded using the ros2 bag command.
During a 20 seconds simulation, the 16% of clock messages generated by Carla could not reach Autoware. In other words, the time interval between messages on Autoware's /clock topic is not always 20 ms (our Carla tick interval setting). Every 5 messages, the time interval is 40 ms (one missing message). Sometimes the time interval is also larger than 40 ms, as more clock messages in a row cannot reach Autoware.

Currently, Carla simulations include 12 vehicles (11 plus the ego-vehicle) and the ego-vehicle is equipped with the following suite of sensors:

• 1 lidar (sensor_tick = 100 ms)
• 5 radars (sensor_tick = 50 ms)
• 5 cameras (resolution = 2560 x 1440, sensor_tick =33 ms)
• 1 GNSS (sensor_tick = 50 ms)
• 1 IMU (sensor_tick = 50 ms)

Does the bridge have any limitations in terms of max data rate or bandwidth?

We know that the same problem applies also to other types of messages (e.g., lidar pointclouds) and also for other tick interval configurations (e.g., 50 ms). Please find attached the log files of the clock and lidar pointclouds messages in both the 20 ms and 50 ms tick interval configurations.

We are running both Carla and Autoware on the same computer, a desktop pc with Intel(R) Core(TM) i9-9980XE CPU, 66GBs RAM memory, and two NVIDIA Quadro P4000 GPUs.

We would really appreciate any feedback and support from your side. Thank you for your time.

Best Regards,
Mario.

PD: The next files contain the data measurements of the /clock and /carla_pointcloud topics, as well as the timestamp measurements extracted directly from the bridge's rust files.

20 ms Test:

• Carla timestamps extracted from the lidar_callback function inside the sensor_bridge.rs file, as well as in the clock.rs file. Each row represents a timestamp generated by Carla before passing through Zenoh, associated either with a /clock measurement or with a pointcloud. The structure of these files is:

• • sec
• • nanosec
• • timestamp expressed in seconds
• • difference between a timestamp and the previous one
• • whether this difference is greater that the expected sensor_tick or not (if True, it means that a message was missing)
• • number of missing messages
    Carla_Pointcloud_Stamp_20ms.csv
    Carla_Clock_20ms.csv

• /carla_pointcloud and /clock topics recorded using ros2bag:

• • topic name
• • message ID as recorded by ros2bag
• • timestamp in seconds
• • difference between a timestamp and the previous one
• • whether this difference is greater that the expected sensor_tick or not (if True, it means that a message was missing)
• • number of missing messages
• • Percentage of missing message with respect to the total amount of messages received
    TEST20ms_Town02_07022024_CarlaPointcloud.csv
    TEST20ms_Town02_07022024_Clock.csv

50 ms Test:
Identical files as before, but tested on a 50 ms tick.
Carla_Pointcloud_Stamp_50ms.csv
Carla_Clock_50ms.csv
TEST50ms_Town02_07022024_CarlaPointcloud.csv
TEST50ms_Town02_07022024_Clock.csv