berndgassmann

Hi, I am not a expert in control. But in the end some kind of cascaded controller was implemented here. The outer control loop controls on the acceleration, the inner...

Hi, I found a different solution for the problem with the spawn_point by explicitly converting it to string after launch.substitution. See one of the launch files [here](https://github.com/carla-simulator/ros-bridge/pull/624/files#diff-8882441b250de2168a3be4b32a0cb6bcdcc03b918155a4cd1382bc1a269e59e5R75). Even if I...

You simply have to a pseudo.traffic_lights sensor See [SpawnObjetcts docu](https://carla.readthedocs.io/projects/ros-bridge/en/latest/carla_spawn_objects/) and e.g. [that file](https://github.com/carla-simulator/ros-bridge/blob/master/carla_ros_bridge/test/test_objects.json) as example.

Did you test the workaround from PR #641 ? At least that should work for many of the vehicles that come with CARLA 0.9.13.

ok, seems like the pseudo object in your case requires the real actor that is postponed to the next tick. So we should also postpone those... I thought it might...

Yes, I encountered the same. Now it should be robust (at least time now starting 15 times one after another all worked). I also added some notes on why this...

@joel-mb I added the frame information also to async mode, even though there the 2 frame might sill not be enough since the server can rush in the meantime and...

Hmm, maybe we can also deploy the actor.is_alive flag to get rid of this problem (for both). At least if it's getting valid if data has been received via rpc...

Alive flag is already True directly after creation at client side ... but actually the actor is not yet fully alive after creation. At least this could be an option...

@Roosstef I've just checked the markers without this fix. And they look the same (below the streetlevel). Therefore, it's a separate issue.