search

carla-simulator / ros-bridge

ROS bridge for CARLA Simulator
MIT License
510 stars 408 forks source link

Incorrect /tf of stationary lidars in synchronous mode #639

Open u-sj opened 1 year ago

u-sj commented 1 year ago

Using

This issue is similar to issues that claim to be fixed

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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