Extend ROS2 support Step 3: Rework ROS2 handling #9451
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Introduced a fine grained ServerSynchronization mechanism, where each synchonization participant is treated independently and interacts with the synchronization of the carla-server individually. If a client is disconnected (or dies) the synchronization state of all participants registered via that client are dropped, i.e. the server will continue running in case the participants of that client were the only ones demanding synchronous mode. The synchronization interface provides means of a time window, up to which the server is allowed to run. Like this, every client can prevent the carla-server to run too fast depending on their individual speed. There is no sync-master anymore. Every client decides for its own if it requires synchronization or not. Drawback of this change: some existing code might have to be changed (see removal of synchronous_master in generate_traffic.py).
Update RPC lib version for windows build Ensure tick calls are ignored if sync mode is not active. And prevent client changes of fixed_delta_seconds triggering warning message.
berndgassmann
force-pushed
the
mai/ue4-extend-ros2-step3
branch
from
99dfc13 to
26a6111
Compare
Contributor
Author
|
Rebased to the (hopefully) fixed step2 commit. |
on non synchronous mode
This commit is extending the built-in ROS2 support of CARLA:
- the internal interface is simplified and object oriented to allow
easier ROS2 extensions in future and reduce code duplication
- the sensor/actor stream existing for the TCP counterparts are used
in a shared manner, which results in lower processing overhead and
requires little individual code changes for ROS2 within UE-sensors
- enable Boost and Asio exceptions for FastDDS to ensure properly
- additional service interfaces are provided to control CARLA directly
from ROS2 (Map, Blueprint and Episode handling, Spawn/DestroyObject)
- convenient interfaces previously available via carla_ros_bridge are
provided (e.g. pseudo sensors, object messages, traffic light/sign,
actor/sensor lists)
- new interfaces like e.g. CarlaVehicleTelemetryData, V2X,
SynchronizationWindow,...
- get detailed vehicle meshes as exact ground truth for e.g. LiDAR
perception
- Vehicle publisher implements a variety of individual publishers to
mimick also old ROS-bridge convenient publisher:
+ CarlaVehicleInfo
+ CarlaVehicleControlStatus
+ Speed
+ Odometry
+ Object
+ ObjectWithCovariance
+ VehicleTelemetryData
- Vehicle subscribers:
+ VehicleControlSubscriber
+ AckermannControlSubscriber,
+ SetTransformSubscriber
- use of c++17 to support std::sample() usage
- Dynamic switching on ROS visibility is possible for all actors now
- Default startup behavior is selectable by ROS2TopicVisibility
parameter in DefaultGame.ini: If true, then all and every topic that
is currently offered by the implementation is visible from the
beginning. If false, then only the sensors/actors created via the
Client- or ROS-Interface are visible by defaults. Others can be
activated via EnableForRos() calls (this allows for disabling
interfaces e.g. for leaderboard)
- ensure multiple service calls at once are working:
+ qos history kind eprosima::fastdds::dds::KEEP_ALL_HISTORY_QOS
+ qos reliablility kind
eprosima::fastdds::dds::RELIABLE_RELIABILITY_QOS
+ qos durability kind
eprosima::fastdds::dds::TRANSIENT_LOCAL_DURABILITY_QOS
for reader, writer, topic
- add set_transform() call to RGB Cameras
- add odometry publisher to walkers
- filter out invalid bounding boxes observed on a few traffic signs
using bounding box transmission within object data
berndgassmann
force-pushed
the
mai/ue4-extend-ros2-step3
branch
from
26a6111 to
3de7c09
Compare
Update telemetry data of VehiclePublisher within process messages step This ensures that the vehicle/wheel data in the engine can not be updated while gathering the data Improve object classification to match existing base-class blueprint patterns. Reduce some ROS2 log output severity
Contributor
Author
|
When this is merged, also the updated carla_msgs should be merged into the dev branch Then we should create also dev branch within the ros-bridge repository that we don't mess up the master with the development changes. After the carla_msgs have been merged I can update the ros-bridge PR with the correct carla_msgs commit here: |
MarcelPiNacy-CVC
added a commit
that referenced
this pull request
Dec 10, 2025
MarcelPiNacy-CVC
added a commit
that referenced
this pull request
Dec 10, 2025
berndgassmann
added a commit
to Motor-Ai/carla-simulator-carla
that referenced
this pull request
Jan 2, 2026
* Extend ROS2 support Step 2: Fine grained ServerSynchronization (carla-simulator#9450) * Extend ROS2 support Step 2: Fine grained ServerSynchronization Introduced a fine grained ServerSynchronization mechanism, where each synchonization participant is treated independently and interacts with the synchronization of the carla-server individually. If a client is disconnected (or dies) the synchronization state of all participants registered via that client are dropped, i.e. the server will continue running in case the participants of that client were the only ones demanding synchronous mode. The synchronization interface provides means of a time window, up to which the server is allowed to run. Like this, every client can prevent the carla-server to run too fast depending on their individual speed. There is no sync-master anymore. Every client decides for its own if it requires synchronization or not. Drawback of this change: some existing code might have to be changed (see removal of synchronous_master in generate_traffic.py). * Fix Windows build and smoke tests Update RPC lib version for windows build Ensure tick calls are ignored if sync mode is not active. And prevent client changes of fixed_delta_seconds triggering warning message. * Client needs to wait for next tick on non synchronous mode * Fix libpng (see carlagx's carla-simulator#9469 and berndgassmann's carla-simulator#9451). (carla-simulator#9477) * Fix issues with running the cosmos transfer server docker image due to outdate dependencies (carla-simulator#9456) * fix dockerfile for changes to vllm and transformers (carla-simulator#229) nvidia-cosmos/cosmos-transfer1#229 nvidia-cosmos/cosmos-transfer1#210 * fix for outdated packages, use new commit hash * Fix docker error due to issues regarding the current working directory. (carla-simulator#9484) --------- Co-authored-by: MarcelPiNacy-CVC <169088301+MarcelPiNacy-CVC@users.noreply.github.com> Co-authored-by: 0graph <50416380+0graph@users.noreply.github.com>
Instead of /carla/map /carla/world_info is published as was done in original ROS bridge since quite some time. Ensure, that the map data is quieried within ProcessMessages() Limit history size to 1
Make publisher transient local
Because it's too large AND incorrect for animated vehicles. Would require more sophisticated handling to make it proper published in a separate topic. Ensure vehicle telemetry publisher publishes updates. Add carla_version to CarlaWorldInfo. Add trigger_volume to TrafficLightPublisher and fix publishing of wrong entry in TrafficLightsPublisher
This reverts commit c9087a7.
Fix: Always publish TFs of sensors Previously TFs of sensors were only published if subscribers were connected, because TF publishing for sensors relied on active sensor streams. Moved sensor handling code from ROS2 class to UeWorldPublisher to be able to publish TFs of sensors while updating the actors when required. Fix: Consider rotation on ROS2 SpawnObject calls Fix: Ensure topics (i.e. rarely updated with transient local) are actually published at DDS level, even if no subscribers are connected at publishing time Fix: Publish also the sensor data with transient local to be most compatible with any receiver configuration. I.e. ensure receivers are able to apply a history size to prevent from frame drops on high system loads. Fix: Internal order on object publishing: first update the object data, then publish (previously data of the last frame were published) Fix: Consider ros_frame_id and ros_publish_tf blueprint parameters Added Verbose Logging and moved logs recurring on every frame to verbose Added publishing of EnvironmentObjects. Allow more flexible Object publishing to support dynamic objects, barely changing dynamic objects (traffic signs, lights) as well as static Environment Objects. Replaced publishing of object data of individual traffic_lights/signs by a grouped object publisher for those (commented the old individual publishing behavior by #ifdef) and removed the covariance object publishing version of these. Expand CarlaActorInfo.msg data to give the user more insights into actor configuration. Expand CarlaEgoVehicleTelemetryData.msg to transport the vehicles light state flags
Already register the sensor-actors when collecting the sensor information to ensure respective parent sensors are already registered at construction time of the actual sensor publisher. This can happen if sensors are nested in some hierarchy. Fix emulated actor name definition of EnvironmentObject that the base_type reflects the type of the object (car, traffic_light, etc.) instead of the object_type. Now it is identical to the other actors.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Extend ROS2 support Step 3: Rework ROS2 handling
This commit is extending the built-in ROS2 support of CARLA:
easier ROS2 extensions in future and reduce code duplication
in a shared manner, which results in lower processing overhead and
requires little individual code changes for ROS2 within UE-sensors
from ROS2 (Map, Blueprint and Episode handling, Spawn/DestroyObject)
provided (e.g. pseudo sensors, object messages, traffic light/sign,
actor/sensor lists)
SynchronizationWindow,WeatherControl
perception
mimick also old ROS-bridge convenient publisher:
parameter in DefaultGame.ini: If true, then all and every topic that
is currently offered by the implementation is visible from the
beginning. If false, then only the sensors/actors created via the
Client- or ROS-Interface are visible by defaults. Others can be
activated via EnableForRos() calls (this allows for disabling
interfaces e.g. for leaderboard)
eprosima::fastdds::dds::RELIABLE_RELIABILITY_QOS
eprosima::fastdds::dds::TRANSIENT_LOCAL_DURABILITY_QOS
for reader, writer, topic
using bounding box transmission within object data
Where has this been tested?
Possible Drawbacks
Some features of the old ros-brigde which are client only code are not yet implemented (lane invasion sensor, enable_autopilot) at server side, but are kept available by the carla_ros_client node which deploys a tiny subset of the former carla_ros_bridge to provide the ros2 interfaces via the carla python client.
Did not recognize any other interface that might be missing yet.
This change is