build(LibCarla, BuildTools): upgrade Fast-DDS to 2.14.6 LTS - #9789
Merged
Blyron merged 2 commits intoJun 17, 2026
Merged
Conversation
CARLA's native ROS 2 integration bundled eProsima Fast-DDS v2.11.2. This moves it to the v2.14.6 LTS release, the Jazzy-era long-term-support line, so the simulator builds against a maintained Fast-DDS with several years of fixes over the previous pin. The notable consequence of the jump is that Fast-DDS 2.14 ships Fast-CDR 2.x instead of 1.x, a breaking serialization API change. CARLA serializes its ROS 2 message structs to CDR by hand, so the migration stays contained: the serializer now requests the classic XCDRv1 encoding explicitly, because Fast-CDR 2.x otherwise defaults to XCDRv2, which adds member headers and would break compatibility with current ROS 2 distributions, and it uses the renamed serialized-length accessor. The generic FastDDS type support also gains the data-representation-aware serialize and size overloads that Fast-DDS 2.13 and later may invoke, each delegating to the existing path so the writer always reaches our serializer. The wire format stays classic CDR, little-endian, so published topics remain byte-compatible with every ROS 2 distribution. A new unit test pins the exact serialized bytes of a known message to guard the encoding against any future drift. Only the ue4-dev branch is changed; the ue5-dev pin is left untouched.
Contributor
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
Updates CARLA’s ROS 2 serialization and FastDDS integration to stay compatible after moving to the Fast-DDS 2.14.x LTS line, while guarding the classic XCDRv1 wire format.
Changes:
- Bump bundled Fast-DDS to v2.14.6 in build setup.
- Pin Fast-CDR serialization/deserialization to XCDRv1 and update API calls for Fast-CDR 2.x.
- Add a “golden bytes” unit test to detect wire-format drift.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| Util/BuildTools/Setup.sh | Updates Fast-DDS version/tag used during setup to v2.14.6. |
| LibCarla/source/carla/ros2/types/CdrSerialization.h | Forces XCDRv1 and updates serialized-length API to match newer Fast-CDR. |
| LibCarla/source/carla/ros2/middleware/fastdds/GenericCdrPubSubType.h | Uses XCDRv1 and adds FastDDS “data-representation-aware” overloads. |
| LibCarla/source/test/server/test_ros2_middleware.cpp | Adds a byte-exact golden test to catch encoding changes. |
| CHANGELOG.md | Documents the Fast-DDS upgrade and serialization compatibility intent. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
In the XCDRv1 golden-bytes test, check the exact serialized size before comparing the full buffer so a failed or short serialization produces a targeted size mismatch instead of a noisy full-vector diff.
Blyron
approved these changes
Jun 16, 2026
germanros1987
pushed a commit
that referenced
this pull request
Aug 19, 2026
Introduce the middleware-neutral type layer of the ROS 2 middleware decoupling series, ported from ue4-dev: - types/msg/*.h: 31 plain C++ structs, one per ROS 2 message type, no DDS dependency, standard library headers only, all members value-initialized (upstream ue4-dev #9612). - types/CdrSerialization.h: serialize_to_cdr(), deserialize_from_cdr() and cdr_serialized_size() for all msg::* types using Fast-CDR (classic CDR, little-endian, DDS encapsulation header). The buffers are wire-compatible with every ROS 2 distribution and can be handed directly to FastDDS write() paths or CycloneDDS dds_writecdr(), removing the need for per-vendor generated type files. A kMaxCdrSequenceElements cap rejects hostile sequence lengths during deserialization (upstream ue4-dev #9643). - types/CdrTopicInfo.h: per-type type_name(), REP-2011 RIHS01 type hash and max_serialized_size(); the hashes let ROS 2 Iron and newer RMWs parse the type hash CARLA advertises via USER_DATA (upstream ue4-dev #9681). - types/UserDataFormat.h: build_user_data() / build_user_data_for<T>() helpers producing the REP-2016 "typehash=RIHS01_<hex>;" key-value payload (upstream ue4-dev #9681). UE5 adaptation: ue5-dev pins FastDDS 2.11.2 with bundled Fast-CDR 1.x, so CdrSerialization.h keeps the Fast-CDR 1.x spellings (eprosima::fastcdr::Cdr::DDS_CDR, getSerializedDataLength()) instead of the Fast-CDR 2.x forms the ue4-dev tip carries since its Fast-DDS 2.14.6 upgrade (ue4-dev #9789). Five lines differ; the wire format is identical either way and is pinned by the golden-bytes test added in the follow-up test commit. The FastDDSConversions.h / FastDDSTypeMap.h files from #9612 are deliberately not ported; they were superseded by unified CDR upstream. The new headers are not referenced by any build target yet; they start compiling when the middleware abstraction lands in the next PR of the series. (adapted from ue4-dev 542959a) (adapted from ue4-dev f53144c) (adapted from ue4-dev c64e8f4) (adapted from ue4-dev b865088) (cherry picked from commit 5d0d578)
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
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
CARLA's native ROS 2 integration bundled eProsima Fast-DDS v2.11.2. This pull request moves it to the v2.14.6 LTS release, the Jazzy-era long-term support line, so the simulator builds against a maintained Fast-DDS that incorporates several years of fixes over the previous pin.
One consequence of the jump that reaches the code is that Fast-DDS 2.14 ships Fast-CDR 2.x instead of 1.x, which is a breaking change to the serialization API. Because CARLA serializes its ROS 2 message structs to CDR by hand rather than through generated type code, the migration stays small and contained. The serializer now explicitly requests the classic XCDRv1 encoding, since Fast-CDR 2.x otherwise defaults to XCDRv2, which inserts member headers and would break compatibility with current ROS 2 distributions, and it uses the renamed serialized-length accessor. The generic FastDDS type support also gains data-representation-aware serialize and size overloads that FastDDS 2.13 and later may call, each delegating to the existing path so that the writer always reaches the same serializer.
The wire format stays classic CDR, little-endian, so every published topic remains byte-compatible with all ROS 2 distributions. To make that guarantee explicit and durable, a new unit test pins the exact serialized bytes of a known message, which catches any future drift back to XCDRv2 or to a different endianness.
This change applies only to the
ue4-devbranch. Theue5-devpin is left at its current version and can be upgraded separately.Where has this been tested?
Validation performed:
make check.LibCarla ARGS="--ros2": all server and client unit tests pass, including the new byte-exact XCDRv1 wire-format test and the existing CDR round-trip tests.make package ARGS="--python-version=3.12 --ros2 ...": the full ROS 2 package builds successfully against Fast-DDS 2.14.6 and Fast-CDR 2.2.7.--ros2, an external ROS 2 Humble node discovered every native topic with the correct type and decoded live data for Clock, Imu, NavSatFix, CameraInfo and TFMessage, confirming the classic XCDRv1 format is preserved end to end.Possible Drawbacks
The CycloneDDS and Zenoh backends share the same hand-written CDR serializer, so they inherit the same encoding and wire-format guarantees. Windows continues to build only the FastDDS backend, as before. No behavior change is expected for existing users: this is a dependency upgrade with the wire format intentionally held constant.
This change is