skipping old frame at sync mode, RGB sensors arrive at different frames and ignored

[crabiner]

Getting warning of skipping frames

I am running carla ros bridge with the following parameters: fixed_delta_seconds = 0.005 (200hz) synchronous_mode = True synchronous_mode_wait_for_vehicle_control_command = False Imu sensor "sensor_tick": 0.01 (100hz) RgbCamera x4 "sensor_tick": 0.05 (20hz)

thus I expect that for simulation running at 200fps I should get IMU reading every 2 frames and RGB reading every 10 frames

when runing carla-ros-bridge I see the following

1. all 4 RGB frames arrive at frame 12
2. RGB sensor 1 arrive at frame 22, RGB sensors 2,3,4 arrived at frame 23. no warning so far, but this is already an issue that the RGB sensors are not synced
3. RGB sensor 1 that arrived at 22 now arrived at frame 32 ros-bridge skips this frame and says expected 33, and RGB sensors 2,3,4 arrived at frame 33, finally ros-bridge says that RGB sensor 1 frame 33 did not arrive and ignores that it did arrive at 32 .

[carla_ros_bridge]: RgbCamera(381): skipping old frame 32, expected 33

btw: I found that if I run the simulation in a higher rate this issue disappears (for example fixed_delta_seconds = 0.001 (1000hz)

In the image below you also see a print I added to _callback_sensor_data printing the carla_sensor_data.frame

[crabiner]

I have worked around the two issues encountered at the post above.

1. first issue is that the RGB (and IMU) sensors were not spawned at the same tick, this is solved by adding sleep of two seconds time.sleep(2) at the ros bridge bridge.py at the first line _synchronous_mode_update so that carla_spawn_objects thread will finish its work and everything is spawned and created in bridge at the same tick

as seen in the picture above now all RGB cameras sensor listen arrive at the same tick however RGB frames will still be dropped due to a second issue since the timestamp is a float number the number 9 places after the decimal point is wrong and as a result a frame can arrive a tick late for example next expected is 1.88499331772327 but the expected tick timestamp is 1.88499331660569 so the frame will be assigned to the next tick

2. to work around the second issue I added an epsilon of 1e-8 to the timestamp compared to next_data_expected_time at sensor.py _update_synchronous_sensor changed the condition to self.next_data_expected_time < timestamp + 1e-8 this results in all frames being processed although sometime they may arrive in a different frame than expected, After the two fixes I am able to get all the RGB frames in a sync manner I think that Carla should change the timestamp to int sec+nanosec instead of double since it leads to innacurate timings

I only got one warning per sensor (that has no real effect) and after that no more warnings :)