Skip to content

Update ROS2 Example - #9672

Merged
LuisPovedaCano merged 2 commits into
ue4-devfrom
luis/update_ros_example
Apr 17, 2026
Merged

Update ROS2 Example#9672
LuisPovedaCano merged 2 commits into
ue4-devfrom
luis/update_ros_example

Conversation

@LuisPovedaCano

@LuisPovedaCano LuisPovedaCano commented Apr 14, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Summary

  • Replaces the hardcoded osrf/ros:humble-desktop image and rmw_cyclonedds_cpp middleware in the ROS2 RViz example with configurable --distro and --rmw arguments.
  • Adds a unified parametrized Dockerfile that builds the correct image for any supported distro/RMW combination
  • Supported distros: humble, jazzy
  • Supported middlewares: fastdds, cyclonedds

Usage

Default: humble + fastdds

./PythonAPI/examples/ros2/run_rviz.sh

Explicit combination

./PythonAPI/examples/ros2/run_rviz.sh --distro=jazzy --rmw=cyclonedds

Each distro/RMW combination builds and caches a separate image (carla-rviz--), so switching between them doesn't require a rebuild.

Related Issues:
During the testing of the new example I've noticed 3 issues

@JesusAnaya have you ever seen any of these?

This change is Reviewable

@LuisPovedaCano
Added --distro and --rmw arguments to run_rviz.sh to be able to
1e2e9c8 
run the example with ROS2 distros `Humble` and `Jazzy` and RMW `FastDDS`
and `CycloneDDS`
@LuisPovedaCano
LuisPovedaCano requested a review from joel-mb April 14, 2026 14:50
@LuisPovedaCano LuisPovedaCano self-assigned this Apr 14, 2026
@LuisPovedaCano
LuisPovedaCano requested a review from a team as a code owner April 14, 2026 14:50
@update-docs

update-docs Bot commented Apr 14, 2026

Copy link
Copy Markdown

Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would update our CHANGELOG.md based on your changes.

This was referenced Apr 14, 2026
Closed
Closed
Closed
@JArmandoAnaya

JArmandoAnaya commented Apr 14, 2026

Copy link
Copy Markdown
Contributor

Hello, I didn't see the issues before. I can take a look and see how to address them.

@JArmandoAnaya

JArmandoAnaya commented Apr 15, 2026

Copy link
Copy Markdown
Contributor

@LuisPovedaCano One question. Should we change the param --dds-middleware= to --rmw= in Carla to select the ROS2 middleware and ensure consistency in param names? Probably this name is more standard.

@LuisPovedaCano LuisPovedaCano changed the title Added --distro and --rmw arguments to run_rviz.sh to be able to Update ROS2 Example Apr 16, 2026
@LuisPovedaCano
LuisPovedaCano merged commit 7fd91eb into ue4-dev Apr 17, 2026
2 checks passed
JArmandoAnaya added a commit to JArmandoAnaya/carla that referenced this pull request May 27, 2026
@JArmandoAnaya @LuisPovedaCano
feat(examples/ros2): build the rviz image with ROS 2 distro selection
593ecd3 
Align the ue5-dev ROS 2 rviz launcher with ue4-dev. run_rviz.sh now
builds a versioned Docker image from a local Dockerfile and accepts a
--distro argument (humble or jazzy) instead of pulling a hardcoded
osrf/ros:humble-desktop image, and the Dockerfile it builds from is
added.

This is the FastDDS-only slice of the upstream change; the CycloneDDS
RMW selection (--rmw) and its cyclonedds.xml profile are deferred to a
later change. The example vehicle stays vehicle.lincoln.mkz, as the
ue4-dev mkz_2017 blueprint is not shipped here.

Upstream commit:

  Update ROS2 Example (carla-simulator#9672)

  * Added `--distro` and `--rmw` arguments to `run_rviz.sh` to be able to
  run the example with ROS2 distros `Humble` and `Jazzy` and RMW `FastDDS`
  and `CycloneDDS`

  * add udp transport to cyclonedds config file

(adapted from ue4-dev 7fd91eb)

Co-Authored-By: Luis Poveda Cano <luispovedacano@gmail.com>
JArmandoAnaya added a commit to JArmandoAnaya/carla that referenced this pull request May 27, 2026
@JArmandoAnaya @LuisPovedaCano
feat(examples/ros2): build the rviz image with ROS 2 distro selection
c5676fb 
Align the ue5-dev ROS 2 rviz launcher with ue4-dev. run_rviz.sh now
builds a versioned Docker image from a local Dockerfile and accepts a
--distro argument (humble or jazzy) instead of pulling a hardcoded
osrf/ros:humble-desktop image, and the Dockerfile it builds from is
added.

This is the FastDDS-only slice of the upstream change; the CycloneDDS
RMW selection (--rmw) and its cyclonedds.xml profile are deferred to a
later change. The example vehicle stays vehicle.lincoln.mkz, as the
ue4-dev mkz_2017 blueprint is not shipped here.

Upstream commit:

  Update ROS2 Example (carla-simulator#9672)

  * Added `--distro` and `--rmw` arguments to `run_rviz.sh` to be able to
  run the example with ROS2 distros `Humble` and `Jazzy` and RMW `FastDDS`
  and `CycloneDDS`

  * add udp transport to cyclonedds config file

(adapted from ue4-dev 7fd91eb)

Co-Authored-By: Luis Poveda Cano <luispovedacano@gmail.com>
@JArmandoAnaya JArmandoAnaya mentioned this pull request May 27, 2026
Open
JArmandoAnaya added a commit to JArmandoAnaya/carla that referenced this pull request Jun 6, 2026
@JArmandoAnaya @LuisPovedaCano
feat(examples/ros2): build the rviz image with ROS 2 distro selection
e5fd8aa 
Align the ue5-dev ROS 2 rviz launcher with ue4-dev. run_rviz.sh now
builds a versioned Docker image from a local Dockerfile and accepts a
--distro argument (humble or jazzy) instead of pulling a hardcoded
osrf/ros:humble-desktop image, and the Dockerfile it builds from is
added.

This is the FastDDS-only slice of the upstream change; the CycloneDDS
RMW selection (--rmw) and its cyclonedds.xml profile are deferred to a
later change. The example vehicle stays vehicle.lincoln.mkz, as the
ue4-dev mkz_2017 blueprint is not shipped here.

Upstream commit:

  Update ROS2 Example (carla-simulator#9672)

  * Added `--distro` and `--rmw` arguments to `run_rviz.sh` to be able to
  run the example with ROS2 distros `Humble` and `Jazzy` and RMW `FastDDS`
  and `CycloneDDS`

  * add udp transport to cyclonedds config file

(adapted from ue4-dev 7fd91eb)

Co-Authored-By: Luis Poveda Cano <luispovedacano@gmail.com>
JArmandoAnaya added a commit to JArmandoAnaya/carla that referenced this pull request Jul 7, 2026
@JArmandoAnaya @LuisPovedaCano
feat(examples/ros2): build the rviz image with ROS 2 distro selection
3d69aeb 
Align the ue5-dev ROS 2 rviz launcher with ue4-dev. run_rviz.sh now
builds a versioned Docker image from a local Dockerfile and accepts a
--distro argument (humble or jazzy) instead of pulling a hardcoded
osrf/ros:humble-desktop image, and the Dockerfile it builds from is
added.

This is the FastDDS-only slice of the upstream change; the CycloneDDS
RMW selection (--rmw) and its cyclonedds.xml profile are deferred to a
later change. The example vehicle stays vehicle.lincoln.mkz, as the
ue4-dev mkz_2017 blueprint is not shipped here.

Upstream commit:

  Update ROS2 Example (carla-simulator#9672)

  * Added `--distro` and `--rmw` arguments to `run_rviz.sh` to be able to
  run the example with ROS2 distros `Humble` and `Jazzy` and RMW `FastDDS`
  and `CycloneDDS`

  * add udp transport to cyclonedds config file

(adapted from ue4-dev 7fd91eb)

Co-Authored-By: Luis Poveda Cano <luispovedacano@gmail.com>
@JArmandoAnaya JArmandoAnaya mentioned this pull request Jul 8, 2026
Draft
Blyron pushed a commit that referenced this pull request Jul 14, 2026
@JArmandoAnaya @grimmmbo
@berndgassmann @LuisPovedaCano
fix(nav): [8/8] guard against null traffic light in WalkerManager (#9758
39c4fda 
)

* feat(sensor): add V2X sensor family (CAM service, path-loss, CustomV2X, V2I)

Port the V2X sensor family to ue5-dev: the CAM sensor (sensor.other.v2x)
with ETSI CAM generation via CaService, the custom-payload sensor
(sensor.other.v2x_custom) carrying a fixed binary blob, the PathLossModel
propagation engine, and owner-less V2I (infrastructure) sensors. Adds the
engine-agnostic LibCarla message model (LibITS ITS types, CAMData /
CustomV2XData containers, V2X serializers, CustomV2XBytes RPC type), wires
both sensors into the SensorRegistry, exposes the client send() RPC path,
and adds the actor-definition builders, Python bindings, and docs.

V2X is a client-streamed sensor: data flows sensor -> SensorRegistry
serializer -> stream -> Python listen() callback. No DDS publisher is
added here, matching upstream; the data model is the foundation a future
ROS 2 publisher would consume.

Plain C++ models (CaService, PathLossModel) are owned via std::unique_ptr
so teardown frees them after UE clears ownership; the static actor maps
are cleared in EndPlay so a destroyed sensor leaves no dangling AActor*
key. CustomV2XBytes is zero-initialized.

Coverage: GTest round-trip for the serializers and the binary blob;
manual smoke test for CAM generation, custom send/receive, and V2I.

Upstream subjects and bodies (verbatim):

v2x 2nd try

Extend ROS2 support Step 1: V2XSensor (#9435)

- V2XSensor allows selection of virtual communication channels via
  sensors 'channel_id ' attribute.
- V2XCustomSensor sends bytes instead of std::string to support
  binary data blobs
- V2XCustomSensor allows multiple messages to be sent at once
  supporting individual larger messages
- Allow V2X-sensors without an owner if these are placed within the
  infrastructure (V2I communication)
- Removed the extra height on the PathLossModel after switching the
  actor to the sensor's actor instance. Therefore, the considered
  position is always the position of the sensor itself which can
  be defined when spawning/attaching
- Updated V2X docu

(adapted from ue4-dev c7cfdad, 8f33324)

Co-Authored-By: Daniel Grimm <daniel.grimm@kit.edu>
Co-Authored-By: berndgassmann <bernd.gassmann@motor-ai.com>

* fix(sensor): harden V2X sensor family init, path-loss, and CAM wire types

Address correctness and robustness issues in the V2X sensor family:

- CaService: initialize mGenCamLowDynamicsLimit (and its counter) so the
  CAM low-dynamics fallback rate is deterministic instead of reading
  uninitialized memory; seed PrevLocation/PrevDeltaTime in the vehicle
  init path so the first acceleration estimate does not read uninitialized
  FVector components or divide by a zero delta time (mirrors
  AInertialMeasurementUnit, driving the first reading to ~0).
- PathLossModel: make Frequency_GHz/Frequency/lambda per-instance fields.
  They were static, so two sensors configured with different frequencies
  clobbered each other globally and corrupted the path-loss math; clamp
  the propagation distance to the FSPL reference distance before any
  log10/division so co-located actors no longer feed -inf/NaN into the
  received-power computation.
- CAM wire type: store PathPoint::pathDeltaTime inline with an availability
  flag instead of a raw pointer. The message is copied byte-for-byte onto
  the sensor data stream, so a server-side pointer must never travel on the
  wire.
- V2X/CustomV2X sensors: skip senders with no queued message (front() on an
  empty list is undefined behaviour) and look up sender queues with
  find-or-skip instead of map::at, which would throw if a sender dropped out
  of the map between the simulate and retrieval passes.
- Python set_bytes: size the copy from the buffer's byte length rather than
  its element count, so a buffer with itemsize > 1 (e.g. a NumPy int32
  array) is copied in full.
- Fix two user-visible/comment typos.

Add unit coverage for the inline CAM path-delta-time wire type
(value-not-pointer, trivially copyable, serializer round-trip) and a smoke
test that exercises set_bytes with a multi-byte-itemsize buffer.

* fix(nav): guard against null traffic light in WalkerManager

WalkerManager::GetAllTrafficLightWaypoints collected every traffic light
affecting a pedestrian route by static_pointer_cast-ing each candidate to
TrafficLight and dereferencing it without a null check, so an actor that
reported the traffic-light type but did not resolve to a TrafficLight caused
a null dereference. Iterate World::GetActors() (the same episode actor set),
filter on the type id, dynamic_pointer_cast to TrafficLight and guard the
result before reading its stop waypoints. Also drop the dead per-actor
GetActorSnapshot query whose result was never used.

Add a smoke test that drives a controller.ai.walker so the reworked gather
and the AI routing path run end to end without taking the server down.

From upstream "Extend ROS2 support Step 2: Serializer and RPC (#9449)":
  - nav/WalkerManager: prevent from using nullptr

(adapted from ue4-dev 1146277)
Co-Authored-By: berndgassmann <bernd.gassmann@motor-ai.com>

* fix(client): wait for the server instead of ticking it in asynchronous mode

World::ApplySettings drove the fixed_delta_seconds settling loop with an
unconditional Tick(), which sends a tick cue and synchronizes to that frame.
In asynchronous mode the server free-runs and only waits on a client tick cue
in synchronous mode (CarlaEngine's frame loop gates on bSynchronousMode), so
the client should wait for the next server-produced frame rather than drive
one. Call Tick() only in synchronous mode and WaitForTick() otherwise. Pair
the SyncSmokeTest teardown to tick only when the restored settings keep
synchronous mode active.

From upstream "Extend ROS2 support Step 2: Fine grained ServerSynchronization (#9450)":
  - Ensure tick calls are ignored if sync mode is not active.
  - Client needs to wait for next tick on non synchronous mode

(adapted from ue4-dev aa9c92b)
Co-Authored-By: berndgassmann <bernd.gassmann@motor-ai.com>

* docs(changelog): summarize the ROS 2 enhancement port series

Add a consolidated CHANGELOG entry for the ROS 2 enhancement port series: the
publisher and subscriber template rework with an Ackermann control subscriber,
the new geom velocity, acceleration and quaternion types with the pitch and
roll rotation fix, the ROS2TopicVisibility startup flag, the V2X sensor
family, the IMU compass yaw and actor disposal-order fix, and the pedestrian
navigation null-dereference hardening.

* feat(examples/ros2): build the rviz image with ROS 2 distro selection

Align the ue5-dev ROS 2 rviz launcher with ue4-dev. run_rviz.sh now
builds a versioned Docker image from a local Dockerfile and accepts a
--distro argument (humble or jazzy) instead of pulling a hardcoded
osrf/ros:humble-desktop image, and the Dockerfile it builds from is
added.

This is the FastDDS-only slice of the upstream change; the CycloneDDS
RMW selection (--rmw) and its cyclonedds.xml profile are deferred to a
later change. The example vehicle stays vehicle.lincoln.mkz, as the
ue4-dev mkz_2017 blueprint is not shipped here.

Upstream commit:

  Update ROS2 Example (#9672)

  * Added `--distro` and `--rmw` arguments to `run_rviz.sh` to be able to
  run the example with ROS2 distros `Humble` and `Jazzy` and RMW `FastDDS`
  and `CycloneDDS`

  * add udp transport to cyclonedds config file

(adapted from ue4-dev 7fd91eb)

Co-Authored-By: Luis Poveda Cano <luispovedacano@gmail.com>

---------

Co-authored-by: Daniel Grimm <daniel.grimm@kit.edu>
Co-authored-by: berndgassmann <bernd.gassmann@motor-ai.com>
Co-authored-by: Luis Poveda Cano <luispovedacano@gmail.com>
germanros1987 pushed a commit that referenced this pull request Aug 19, 2026
@JArmandoAnaya @LuisPovedaCano @germanros1987
docs(ros2): port the rviz example with --distro and --rmw switches
2216c4e 
Reconcile the rviz example with the runtime middleware selection: add
--distro=<humble|jazzy> and --rmw=<fastdds|cyclonedds> to run_rviz.sh,
build a per-combination image via a new Dockerfile, set the matching RMW
environment variables, and add the CycloneDDS UDP transport config.
Document the usage in the example README.

Upstream commit message:

  Update ROS2 Example (#9672)

  * Added `--distro` and `--rmw` arguments to `run_rviz.sh` to be able to
  run the example with ROS2 distros `Humble` and `Jazzy` and RMW `FastDDS`
  and `CycloneDDS`

  * add udp transport to cyclonedds config file

(adapted from ue4-dev 7fd91eb)

Co-Authored-By: Luis Poveda Cano <luispovedacano@gmail.com>
(cherry picked from commit 6474e05)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@joel-mb joel-mb joel-mb approved these changes

Assignees

@LuisPovedaCano LuisPovedaCano

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@LuisPovedaCano @JArmandoAnaya @joel-mb