Incorrect /tf of stationary lidars in synchronous mode

[u-sj]

Using

• Carla version 0.9.13.
• Ros bridge e9063d9
• Ubuntu 18.04
• ROS melodic

This issue is similar to issues that claim to be fixed

• Actor creation synchronization #576
• Sensor spawn at wrong position / in wrong tf #559.

I am running the bridge in synchronous mode (default settings).
Using carla_spawn_objects with the following .json to spawn in stationary lidars:

{   
    "objects": 
    [
        {
            "type": "sensor.pseudo.objects",
            "id": "objects"
        },
        {
            "type": "sensor.pseudo.actor_list",
            "id": "actor_list"
        },
        {
            "type": "sensor.lidar.ray_cast",
            "id": "lidar0",
            "spawn_point": {"x": 1.0, "y": 2.0, "z": 3.0, "roll": 4.0, "pitch": 5.0, "yaw": 6.0},
            "range": 75,
            "channels": 64,
            "points_per_second": 10000,
            "upper_fov": 22.5,
            "lower_fov": -22.5,
            "rotation_frequency": 10,
            "noise_stddev": 0.1
        },
        {
            "type": "sensor.lidar.ray_cast",
            "id": "lidar1",
            "spawn_point": {"x": -1.0, "y": -2.0, "z": -3.0, "roll": -4.0, "pitch": -5.0, "yaw": -6.0},
            "range": 75,
            "channels": 64,
            "points_per_second": 10000,
            "upper_fov": 22.5,
            "lower_fov": -22.5,
            "rotation_frequency": 10,
            "noise_stddev": 0.1
        }
    ]
}

Expected behaviour

The /tf topic gives the same transforms as defined in the .json

Actual results

Transformations in /tf are all zeros. Sometimes the first lidar is correct. It appears that overall load of the simulation is a factor as high values in points_per_second reduces the amount of correct transforms.

Example output of rostopic echo /tf:

transforms: 
  - 
    header: 
      seq: 0
      stamp: 
        secs: 349
        nsecs: 220444330
      frame_id: "map"
    child_frame_id: "lidar0"
    transform: 
      translation: 
        x: 1.0
        y: 2.0
        z: 3.0
      rotation: 
        x: 0.0325370449297
        y: 0.0453578232483
        z: 0.0507341253023
        w: 0.997150970068
---
transforms: 
  - 
    header: 
      seq: 0
      stamp: 
        secs: 349
        nsecs: 220444330
      frame_id: "map"
    child_frame_id: "lidar1"
    transform: 
      translation: 
        x: 0.0
        y: -0.0
        z: 0.0
      rotation: 
        x: 0.0
        y: -0.0
        z: 0.0
        w: 1.0
---

[u-sj]

Currently it appears that there is a race condition somewhere as I have observed cases with 2+ sensors where more than one sensor has the correct transformation.

The incorrect transformation is placed into the ros message at line 114 in sensor.py.
The value of self.relative_spawn_pose appears to be 0 for sensors without parents when it should be relative to the map.

[berndgassmann]

Hi,
I also observe the same issue again with using a larger map. Therefore, I tried with the other proposed solution of the initial problem again. Just updated that branch with the latest master changes:
https://github.com/carla-simulator/ros-bridge/tree/sync_carla_actor_creation

Can you try if this one solves your problem?

Be aware that in the original PR #571 Joel mentioned that in respect to this solution and the leaderboard.
"...For instance, for the integration of the ROS-bridge with the leadeboard this will require doing extra ticks during the initialization of the stack...."

So I don't know if this works in conjunction with leaderboard setup.

[u-sj]

Tested with a json that has multiple stationary lidars. On the master branch I observed same broken behavior. Switching to the other branch made the issue disappear.

I don't know anything about the leaderboard, so cannot comment on that.

[berndgassmann]

Ok, thanks. So I just reopened the PR #571.

[qzhq747]

Hi, I also observe the same issue again with using a larger map. Therefore, I tried with the other proposed solution of the initial problem again. Just updated that branch with the latest master changes: https://github.com/carla-simulator/ros-bridge/tree/sync_carla_actor_creation

Can you try if this one solves your problem?

Be aware that in the original PR #571 Joel mentioned that in respect to this solution and the leaderboard. "...For instance, for the integration of the ROS-bridge with the leadeboard this will require doing extra ticks during the initialization of the stack...."

So I don't know if this works in conjunction with leaderboard setup.

I face the same problem. While switching to the branch https://github.com/carla-simulator/ros-bridge/pull/571, the issue is solved. It solve my questions.

[berndgassmann]

Hi,
in case you still encounter problems with the ROS-bridge, one alternative might be that you could try the native CARLA ROS2 support (in case you are using ROS2 ;-).
Then you might need only the tools of this repo, because the bridge isn't existing anymore see PR #728.
At least all tools that I use within our project are working fine.
Drawback: you have to compile the carla development branch on your own...

• https://github.com/CarlaUnreal/UnrealEngine/pull/23
• https://github.com/berndgassmann/carla/tree/berndgassmann/rework_ros2_step_3_refactor_ros2_support
• https://github.com/berndgassmann/ros-carla-msgs/tree/berndgassmann/carla_native_ros2_interface
  You can spot how the native support works here:
• https://github.com/berndgassmann/carla-ros2-demo/tree/adapt_to_PR7229