Extend ROS2 support Step 3: Rework ROS2 handling#9451
Open
berndgassmann wants to merge 44 commits intocarla-simulator:ue4-devfrom
Open
Extend ROS2 support Step 3: Rework ROS2 handling#9451berndgassmann wants to merge 44 commits intocarla-simulator:ue4-devfrom
berndgassmann wants to merge 44 commits intocarla-simulator:ue4-devfrom
Conversation
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.
carla_fastdds library didn't set the server definitions Make foonathan_memory provider compilation more robust (v1.3.2 introduced FOONATHAN_MEMORY_FORCE_VENDORED_BUILD parameter which is not present in v1.3.1). In some cases didn't checkout the sources.
In a previous commit where the Quaternions were introduced to support ROS conversion later on, the Rotator rotations were adapted to perform left-handed rotations to match the behavior of Quaternions in a left-handed system in a mathematical manner. But the original CARLA code from 0.9.16 was totally correct on performing rotations using the Rotator, since Unreal Rotator has a very special definition of rotation directions: performing left-handed rotation for yaw component, but right-handed rotations for the other two axis. This commit reverts the behavior of the Rotator and adapts the Quaternion <-> Rotator conversion: roll and pitch have to be negated when converting Rototar to Quaternion and vice-versa. To ensure geom::Rotator and geom::Quaternion behave exactly as their Unreal counterparts, the unit test have been expanded and the expected results within taken over from Unreal calculation results. The rotation matrix rotations are verified within that test, too.
In the previous commit on fixing the Fix Quaternion <-> Rotator conversion within CARLA, on the ROS2 branch one intermediate file slipped in introducing wrong roll conversions. Reverting to the previous state.
Since in most cases sensor relative transforms are static, these are published to the /tf_static topic to reduce the load on /tf topic.
This enables the service call to wait with the (success) response until the new episode was actually started which finally allows callers to postpone further actions until the game is running as expected.
Transport upper 32 bit of the environment object ID via Object.msg classification_age member to allow alignment with the CarlaActorList actor-id.
Mainly configure writer and reader QoS and keep the topic and publisher QoS to their defaults. On KEEP_ALL_HISTORY_QOS adapt the DDS recource limits instead of the history.depth parameter to have an effect. Services use KEEP_LAST_HISTORY_QOS and volatile durability; the writer pushlishes in sync mode to ensure the service responses are passed immediately to the middleware and have precedence over sensor data. Some smaller fixes.
using fastcdr 2.3 and fastddsgen 3.3.2
Especially publish first TF, then clock followed by the rest. Ensure some publisher write in synchronous mode to prevent from publishing delays because of buffering. Ensure all TF data is published, before the sensor data.
Contributor
Author
|
The latest commits were switching to a more stable FastDDS version (the latest 2.x release from last week) which is fully compatible with Humble, Jazzy, Iron, Kilted. The above is running at our site stable under Humble (Ubuntu 22.04) as well as Kilted (Ubuntu 24.04 -- needs an additional commit -- see draft #9478). Should also run without any problems under Jazzy (see #9551) and most probably also Iron (at least I used Iron with 2.14.4 quite some time ago). In addition, the latest commits were mainly targeting stable and deterministic runs even under heavy system load by |
Add missing speed component to the message.
Vehicle and Walker publisher publish their odometry-twist in local coordinate frame and cannot just reuse the data from object publisher. Furthermore, the IMU angular velocity is in radians while the actor dynamic state provide it in degrees. Therefore, the ROS2 type support considers such now: - Postpone conversion to ROS values on output side to allow correct rotations within CARLA coordinate frame for realtive values - Explicitly differentiate between absolute and relative ROS values - Explicitly differentiate degree and radian input - Merge Speed/Twist into AcceleratedMovement interface Make vehicle info wheel positions relative, as it's published only once at the startup. Due to the relative nature of this it is good to keep the frame_id to the vehicle-frame (carla_ros_bridge had this set to "map"). Also the acceleration then makes sense to select the relative one (carla_ros_bridge had that one in map-frame). As an exception to this, the orientation is still in respect to the map, otherwise pretty useless being zero.
If the server-queries on additional sensor data is perfomred within the ProcessMessages() step, the simulation did not yet tick, therefore the states from the last frame are quieried. Moving these to the UpdateSensorDataPreAction() step accesses the data after the current physics step was performed.
Synchonize the publishing of UePublisher::Publish() calls to ensure that the data was properly updated before at UpdateSensorDataPostAction() and check after sensor data update if late publishing has to be performed.
Reduce the time CARLA is blocking the rendering thread and locking Unreal resources by moving the calls for streaming the data into a background thread.
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
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