Extend ROS2 support Step 2: Fine grained ServerSynchronization #9450
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
berndgassmann
commented
Nov 21, 2025
berndgassmann
force-pushed
the
mai/ue4-extend-ros2-step2-synchronization
branch
from
4ee3dc7 to
3b4177a
Compare
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).
berndgassmann
force-pushed
the
mai/ue4-extend-ros2-step2-synchronization
branch
from
93fc3c9 to
db05b30
Compare
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-step2-synchronization
branch
from
db05b30 to
3f80b69
Compare
Contributor
Author
|
Rebased, fixed windows build and smoke test runs. |
on non synchronous mode
Contributor
Author
|
Sorry, forgot to rebuild of PythonAPI after changing the client code and overlooked that the client has at least to wait for the next tick in non-sync-mode to receive the updated settings value... |
MarcelPiNacy-CVC
approved these changes
Dec 2, 2025
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
This is one of the second steps of the ROS2 extension series.
This one requires #9431 to be merged; until then it's listed as a draft.
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).
Where has this been tested?
Possible Drawbacks
This change is