Repository navigation
feat(autoware_carla_interface): do not spawn cameras while rendering is off - #13450
Merged
Max-Bin merged 2 commits intoOct 1, 2026
Conversation
github-actions
Bot
added
type:documentation
|
Thank you for contributing to the Autoware project! 🚧 If your pull request is in progress, switch it to draft mode. Please ensure:
|
hakuturu583
force-pushed
the
feat/carla-interface-reject-cameras-without-renderer
branch
from
October 1, 2026 02:25
ee4d59f to
92636b2
Compare
hakuturu583
added
the
run:build-and-test-differential
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #13450 +/- ##
=======================================
Coverage 37.44% 37.44%
=======================================
Files 2030 2030
Lines 142134 142134
=======================================
Hits 53217 53217
Misses 88917 88917
*This pull request uses carry forward flags. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
hakuturu583
force-pushed
the
feat/carla-interface-reject-cameras-without-renderer
branch
from
October 1, 2026 02:47
92636b2 to
2197707
Compare
hakuturu583
changed the title
…is off `no_rendering_mode` turns the scene rendering off, yet the camera sensors in the sensor mapping were still spawned in CARLA, where they can only ever return an empty image. Worse, the same flag describes the case that matters: a CARLA server started without a renderer (`CarlaUnreal.sh -nullrhi`) **segfaults as soon as a camera sensor is spawned on it**. Every call the bridge makes afterwards fails with an opaque `RuntimeError: std::exception`, so the logs point at whatever RPC came next rather than at the camera. The ray-cast LiDAR needs no renderer and keeps producing points, which makes such a server otherwise useful for headless LiDAR-only closed-loop runs. A client cannot detect a renderer-less server: its world settings, blueprint library and sensor attributes are byte-for-byte identical to a rendering one (verified by diffing a full client-side dump of both), and probing by spawning a test camera is what kills it. So follow `no_rendering_mode` and leave the cameras out of the CARLA spawn list, naming the skipped sensors once in a warning. Every sensor that works without rendering is spawned as before, the same sensor mapping now works with and without rendering, and the behaviour with rendering on is unchanged. Verified on CARLA 0.10 `-nullrhi` with the full 9-sensor mapping (6 RGB cameras) and `no_rendering_mode:=True`: all six cameras are named in the warning and skipped, the ego spawns, LiDAR publishes at 10.0 Hz, the camera topics stay silent, and the CARLA server stays up - where previously it segfaulted (exit 139). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Masaya Kataoka <cld-masaya.kataoka@tier4.jp>
hakuturu583
force-pushed
the
feat/carla-interface-reject-cameras-without-renderer
branch
from
October 1, 2026 02:52
2197707 to
970adf1
Compare
Max-Bin
enabled auto-merge (squash)
October 1, 2026 09:53
paulsohn-github-app Bot
pushed a commit
to paulsohn/autoware_universe_planning_2
that referenced
this pull request
Oct 1, 2026
…is off (autowarefoundation/autoware_universe#13450) `no_rendering_mode` turns the scene rendering off, yet the camera sensors in the sensor mapping were still spawned in CARLA, where they can only ever return an empty image. Worse, the same flag describes the case that matters: a CARLA server started without a renderer (`CarlaUnreal.sh -nullrhi`) **segfaults as soon as a camera sensor is spawned on it**. Every call the bridge makes afterwards fails with an opaque `RuntimeError: std::exception`, so the logs point at whatever RPC came next rather than at the camera. The ray-cast LiDAR needs no renderer and keeps producing points, which makes such a server otherwise useful for headless LiDAR-only closed-loop runs. A client cannot detect a renderer-less server: its world settings, blueprint library and sensor attributes are byte-for-byte identical to a rendering one (verified by diffing a full client-side dump of both), and probing by spawning a test camera is what kills it. So follow `no_rendering_mode` and leave the cameras out of the CARLA spawn list, naming the skipped sensors once in a warning. Every sensor that works without rendering is spawned as before, the same sensor mapping now works with and without rendering, and the behaviour with rendering on is unchanged. Verified on CARLA 0.10 `-nullrhi` with the full 9-sensor mapping (6 RGB cameras) and `no_rendering_mode:=True`: all six cameras are named in the warning and skipped, the ego spawns, LiDAR publishes at 10.0 Hz, the camera topics stay silent, and the CARLA server stays up - where previously it segfaulted (exit 139). Signed-off-by: Masaya Kataoka <cld-masaya.kataoka@tier4.jp> Co-authored-by: Masaya Kataoka <cld-masaya.kataoka@tier4.jp> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Max-Bin <vborisw@gmail.com>
shmpwk
pushed a commit
to tier4/pilot_auto_system
that referenced
this pull request
Oct 5, 2026
…is off (autowarefoundation/autoware_universe#13450) `no_rendering_mode` turns the scene rendering off, yet the camera sensors in the sensor mapping were still spawned in CARLA, where they can only ever return an empty image. Worse, the same flag describes the case that matters: a CARLA server started without a renderer (`CarlaUnreal.sh -nullrhi`) **segfaults as soon as a camera sensor is spawned on it**. Every call the bridge makes afterwards fails with an opaque `RuntimeError: std::exception`, so the logs point at whatever RPC came next rather than at the camera. The ray-cast LiDAR needs no renderer and keeps producing points, which makes such a server otherwise useful for headless LiDAR-only closed-loop runs. A client cannot detect a renderer-less server: its world settings, blueprint library and sensor attributes are byte-for-byte identical to a rendering one (verified by diffing a full client-side dump of both), and probing by spawning a test camera is what kills it. So follow `no_rendering_mode` and leave the cameras out of the CARLA spawn list, naming the skipped sensors once in a warning. Every sensor that works without rendering is spawned as before, the same sensor mapping now works with and without rendering, and the behaviour with rendering on is unchanged. Verified on CARLA 0.10 `-nullrhi` with the full 9-sensor mapping (6 RGB cameras) and `no_rendering_mode:=True`: all six cameras are named in the warning and skipped, the ego spawns, LiDAR publishes at 10.0 Hz, the camera topics stay silent, and the CARLA server stays up - where previously it segfaulted (exit 139). Signed-off-by: Masaya Kataoka <cld-masaya.kataoka@tier4.jp> Co-authored-by: Masaya Kataoka <cld-masaya.kataoka@tier4.jp> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Max-Bin <vborisw@gmail.com>
shmpwk
pushed a commit
to tier4/pilot_auto_localization_map
that referenced
this pull request
Oct 14, 2026
…is off (autowarefoundation/autoware_universe#13450) `no_rendering_mode` turns the scene rendering off, yet the camera sensors in the sensor mapping were still spawned in CARLA, where they can only ever return an empty image. Worse, the same flag describes the case that matters: a CARLA server started without a renderer (`CarlaUnreal.sh -nullrhi`) **segfaults as soon as a camera sensor is spawned on it**. Every call the bridge makes afterwards fails with an opaque `RuntimeError: std::exception`, so the logs point at whatever RPC came next rather than at the camera. The ray-cast LiDAR needs no renderer and keeps producing points, which makes such a server otherwise useful for headless LiDAR-only closed-loop runs. A client cannot detect a renderer-less server: its world settings, blueprint library and sensor attributes are byte-for-byte identical to a rendering one (verified by diffing a full client-side dump of both), and probing by spawning a test camera is what kills it. So follow `no_rendering_mode` and leave the cameras out of the CARLA spawn list, naming the skipped sensors once in a warning. Every sensor that works without rendering is spawned as before, the same sensor mapping now works with and without rendering, and the behaviour with rendering on is unchanged. Verified on CARLA 0.10 `-nullrhi` with the full 9-sensor mapping (6 RGB cameras) and `no_rendering_mode:=True`: all six cameras are named in the warning and skipped, the ego spawns, LiDAR publishes at 10.0 Hz, the camera topics stay silent, and the CARLA server stays up - where previously it segfaulted (exit 139). Signed-off-by: Masaya Kataoka <cld-masaya.kataoka@tier4.jp> Co-authored-by: Masaya Kataoka <cld-masaya.kataoka@tier4.jp> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Max-Bin <vborisw@gmail.com>
shmpwk
pushed a commit
to tier4/pilot_auto_localization_map
that referenced
this pull request
Oct 14, 2026
…is off (autowarefoundation/autoware_universe#13450) `no_rendering_mode` turns the scene rendering off, yet the camera sensors in the sensor mapping were still spawned in CARLA, where they can only ever return an empty image. Worse, the same flag describes the case that matters: a CARLA server started without a renderer (`CarlaUnreal.sh -nullrhi`) **segfaults as soon as a camera sensor is spawned on it**. Every call the bridge makes afterwards fails with an opaque `RuntimeError: std::exception`, so the logs point at whatever RPC came next rather than at the camera. The ray-cast LiDAR needs no renderer and keeps producing points, which makes such a server otherwise useful for headless LiDAR-only closed-loop runs. A client cannot detect a renderer-less server: its world settings, blueprint library and sensor attributes are byte-for-byte identical to a rendering one (verified by diffing a full client-side dump of both), and probing by spawning a test camera is what kills it. So follow `no_rendering_mode` and leave the cameras out of the CARLA spawn list, naming the skipped sensors once in a warning. Every sensor that works without rendering is spawned as before, the same sensor mapping now works with and without rendering, and the behaviour with rendering on is unchanged. Verified on CARLA 0.10 `-nullrhi` with the full 9-sensor mapping (6 RGB cameras) and `no_rendering_mode:=True`: all six cameras are named in the warning and skipped, the ego spawns, LiDAR publishes at 10.0 Hz, the camera topics stay silent, and the CARLA server stays up - where previously it segfaulted (exit 139). Signed-off-by: Masaya Kataoka <cld-masaya.kataoka@tier4.jp> Co-authored-by: Masaya Kataoka <cld-masaya.kataoka@tier4.jp> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Max-Bin <vborisw@gmail.com>
shmpwk
pushed a commit
to tier4/pilot_auto_localization_map
that referenced
this pull request
Oct 14, 2026
…is off (autowarefoundation/autoware_universe#13450) `no_rendering_mode` turns the scene rendering off, yet the camera sensors in the sensor mapping were still spawned in CARLA, where they can only ever return an empty image. Worse, the same flag describes the case that matters: a CARLA server started without a renderer (`CarlaUnreal.sh -nullrhi`) **segfaults as soon as a camera sensor is spawned on it**. Every call the bridge makes afterwards fails with an opaque `RuntimeError: std::exception`, so the logs point at whatever RPC came next rather than at the camera. The ray-cast LiDAR needs no renderer and keeps producing points, which makes such a server otherwise useful for headless LiDAR-only closed-loop runs. A client cannot detect a renderer-less server: its world settings, blueprint library and sensor attributes are byte-for-byte identical to a rendering one (verified by diffing a full client-side dump of both), and probing by spawning a test camera is what kills it. So follow `no_rendering_mode` and leave the cameras out of the CARLA spawn list, naming the skipped sensors once in a warning. Every sensor that works without rendering is spawned as before, the same sensor mapping now works with and without rendering, and the behaviour with rendering on is unchanged. Verified on CARLA 0.10 `-nullrhi` with the full 9-sensor mapping (6 RGB cameras) and `no_rendering_mode:=True`: all six cameras are named in the warning and skipped, the ego spawns, LiDAR publishes at 10.0 Hz, the camera topics stay silent, and the CARLA server stays up - where previously it segfaulted (exit 139). Signed-off-by: Masaya Kataoka <cld-masaya.kataoka@tier4.jp> Co-authored-by: Masaya Kataoka <cld-masaya.kataoka@tier4.jp> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Max-Bin <vborisw@gmail.com>
shmpwk
pushed a commit
to tier4/pilot_auto_common
that referenced
this pull request
Oct 14, 2026
…is off (autowarefoundation/autoware_universe#13450) `no_rendering_mode` turns the scene rendering off, yet the camera sensors in the sensor mapping were still spawned in CARLA, where they can only ever return an empty image. Worse, the same flag describes the case that matters: a CARLA server started without a renderer (`CarlaUnreal.sh -nullrhi`) **segfaults as soon as a camera sensor is spawned on it**. Every call the bridge makes afterwards fails with an opaque `RuntimeError: std::exception`, so the logs point at whatever RPC came next rather than at the camera. The ray-cast LiDAR needs no renderer and keeps producing points, which makes such a server otherwise useful for headless LiDAR-only closed-loop runs. A client cannot detect a renderer-less server: its world settings, blueprint library and sensor attributes are byte-for-byte identical to a rendering one (verified by diffing a full client-side dump of both), and probing by spawning a test camera is what kills it. So follow `no_rendering_mode` and leave the cameras out of the CARLA spawn list, naming the skipped sensors once in a warning. Every sensor that works without rendering is spawned as before, the same sensor mapping now works with and without rendering, and the behaviour with rendering on is unchanged. Verified on CARLA 0.10 `-nullrhi` with the full 9-sensor mapping (6 RGB cameras) and `no_rendering_mode:=True`: all six cameras are named in the warning and skipped, the ego spawns, LiDAR publishes at 10.0 Hz, the camera topics stay silent, and the CARLA server stays up - where previously it segfaulted (exit 139). Signed-off-by: Masaya Kataoka <cld-masaya.kataoka@tier4.jp> Co-authored-by: Masaya Kataoka <cld-masaya.kataoka@tier4.jp> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Max-Bin <vborisw@gmail.com>
shmpwk
pushed a commit
to tier4/pilot_auto_vehicle
that referenced
this pull request
Oct 14, 2026
…is off (autowarefoundation/autoware_universe#13450) `no_rendering_mode` turns the scene rendering off, yet the camera sensors in the sensor mapping were still spawned in CARLA, where they can only ever return an empty image. Worse, the same flag describes the case that matters: a CARLA server started without a renderer (`CarlaUnreal.sh -nullrhi`) **segfaults as soon as a camera sensor is spawned on it**. Every call the bridge makes afterwards fails with an opaque `RuntimeError: std::exception`, so the logs point at whatever RPC came next rather than at the camera. The ray-cast LiDAR needs no renderer and keeps producing points, which makes such a server otherwise useful for headless LiDAR-only closed-loop runs. A client cannot detect a renderer-less server: its world settings, blueprint library and sensor attributes are byte-for-byte identical to a rendering one (verified by diffing a full client-side dump of both), and probing by spawning a test camera is what kills it. So follow `no_rendering_mode` and leave the cameras out of the CARLA spawn list, naming the skipped sensors once in a warning. Every sensor that works without rendering is spawned as before, the same sensor mapping now works with and without rendering, and the behaviour with rendering on is unchanged. Verified on CARLA 0.10 `-nullrhi` with the full 9-sensor mapping (6 RGB cameras) and `no_rendering_mode:=True`: all six cameras are named in the warning and skipped, the ego spawns, LiDAR publishes at 10.0 Hz, the camera topics stay silent, and the CARLA server stays up - where previously it segfaulted (exit 139). Signed-off-by: Masaya Kataoka <cld-masaya.kataoka@tier4.jp> Co-authored-by: Masaya Kataoka <cld-masaya.kataoka@tier4.jp> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Max-Bin <vborisw@gmail.com>
shmpwk
pushed a commit
to tier4/pilot_auto_vehicle
that referenced
this pull request
Oct 14, 2026
…is off (autowarefoundation/autoware_universe#13450) `no_rendering_mode` turns the scene rendering off, yet the camera sensors in the sensor mapping were still spawned in CARLA, where they can only ever return an empty image. Worse, the same flag describes the case that matters: a CARLA server started without a renderer (`CarlaUnreal.sh -nullrhi`) **segfaults as soon as a camera sensor is spawned on it**. Every call the bridge makes afterwards fails with an opaque `RuntimeError: std::exception`, so the logs point at whatever RPC came next rather than at the camera. The ray-cast LiDAR needs no renderer and keeps producing points, which makes such a server otherwise useful for headless LiDAR-only closed-loop runs. A client cannot detect a renderer-less server: its world settings, blueprint library and sensor attributes are byte-for-byte identical to a rendering one (verified by diffing a full client-side dump of both), and probing by spawning a test camera is what kills it. So follow `no_rendering_mode` and leave the cameras out of the CARLA spawn list, naming the skipped sensors once in a warning. Every sensor that works without rendering is spawned as before, the same sensor mapping now works with and without rendering, and the behaviour with rendering on is unchanged. Verified on CARLA 0.10 `-nullrhi` with the full 9-sensor mapping (6 RGB cameras) and `no_rendering_mode:=True`: all six cameras are named in the warning and skipped, the ego spawns, LiDAR publishes at 10.0 Hz, the camera topics stay silent, and the CARLA server stays up - where previously it segfaulted (exit 139). Signed-off-by: Masaya Kataoka <cld-masaya.kataoka@tier4.jp> Co-authored-by: Masaya Kataoka <cld-masaya.kataoka@tier4.jp> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Max-Bin <vborisw@gmail.com>
shmpwk
pushed a commit
to tier4/pilot_auto_visualization
that referenced
this pull request
Oct 14, 2026
…is off (autowarefoundation/autoware_universe#13450) `no_rendering_mode` turns the scene rendering off, yet the camera sensors in the sensor mapping were still spawned in CARLA, where they can only ever return an empty image. Worse, the same flag describes the case that matters: a CARLA server started without a renderer (`CarlaUnreal.sh -nullrhi`) **segfaults as soon as a camera sensor is spawned on it**. Every call the bridge makes afterwards fails with an opaque `RuntimeError: std::exception`, so the logs point at whatever RPC came next rather than at the camera. The ray-cast LiDAR needs no renderer and keeps producing points, which makes such a server otherwise useful for headless LiDAR-only closed-loop runs. A client cannot detect a renderer-less server: its world settings, blueprint library and sensor attributes are byte-for-byte identical to a rendering one (verified by diffing a full client-side dump of both), and probing by spawning a test camera is what kills it. So follow `no_rendering_mode` and leave the cameras out of the CARLA spawn list, naming the skipped sensors once in a warning. Every sensor that works without rendering is spawned as before, the same sensor mapping now works with and without rendering, and the behaviour with rendering on is unchanged. Verified on CARLA 0.10 `-nullrhi` with the full 9-sensor mapping (6 RGB cameras) and `no_rendering_mode:=True`: all six cameras are named in the warning and skipped, the ego spawns, LiDAR publishes at 10.0 Hz, the camera topics stay silent, and the CARLA server stays up - where previously it segfaulted (exit 139). Signed-off-by: Masaya Kataoka <cld-masaya.kataoka@tier4.jp> Co-authored-by: Masaya Kataoka <cld-masaya.kataoka@tier4.jp> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Max-Bin <vborisw@gmail.com>
shmpwk
pushed a commit
to tier4/pilot_auto_simulation
that referenced
this pull request
Oct 14, 2026
…is off (autowarefoundation/autoware_universe#13450) `no_rendering_mode` turns the scene rendering off, yet the camera sensors in the sensor mapping were still spawned in CARLA, where they can only ever return an empty image. Worse, the same flag describes the case that matters: a CARLA server started without a renderer (`CarlaUnreal.sh -nullrhi`) **segfaults as soon as a camera sensor is spawned on it**. Every call the bridge makes afterwards fails with an opaque `RuntimeError: std::exception`, so the logs point at whatever RPC came next rather than at the camera. The ray-cast LiDAR needs no renderer and keeps producing points, which makes such a server otherwise useful for headless LiDAR-only closed-loop runs. A client cannot detect a renderer-less server: its world settings, blueprint library and sensor attributes are byte-for-byte identical to a rendering one (verified by diffing a full client-side dump of both), and probing by spawning a test camera is what kills it. So follow `no_rendering_mode` and leave the cameras out of the CARLA spawn list, naming the skipped sensors once in a warning. Every sensor that works without rendering is spawned as before, the same sensor mapping now works with and without rendering, and the behaviour with rendering on is unchanged. Verified on CARLA 0.10 `-nullrhi` with the full 9-sensor mapping (6 RGB cameras) and `no_rendering_mode:=True`: all six cameras are named in the warning and skipped, the ego spawns, LiDAR publishes at 10.0 Hz, the camera topics stay silent, and the CARLA server stays up - where previously it segfaulted (exit 139). Signed-off-by: Masaya Kataoka <cld-masaya.kataoka@tier4.jp> Co-authored-by: Masaya Kataoka <cld-masaya.kataoka@tier4.jp> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Max-Bin <vborisw@gmail.com>
shmpwk
pushed a commit
to tier4/pilot_auto_evaluation
that referenced
this pull request
Oct 14, 2026
…is off (autowarefoundation/autoware_universe#13450) `no_rendering_mode` turns the scene rendering off, yet the camera sensors in the sensor mapping were still spawned in CARLA, where they can only ever return an empty image. Worse, the same flag describes the case that matters: a CARLA server started without a renderer (`CarlaUnreal.sh -nullrhi`) **segfaults as soon as a camera sensor is spawned on it**. Every call the bridge makes afterwards fails with an opaque `RuntimeError: std::exception`, so the logs point at whatever RPC came next rather than at the camera. The ray-cast LiDAR needs no renderer and keeps producing points, which makes such a server otherwise useful for headless LiDAR-only closed-loop runs. A client cannot detect a renderer-less server: its world settings, blueprint library and sensor attributes are byte-for-byte identical to a rendering one (verified by diffing a full client-side dump of both), and probing by spawning a test camera is what kills it. So follow `no_rendering_mode` and leave the cameras out of the CARLA spawn list, naming the skipped sensors once in a warning. Every sensor that works without rendering is spawned as before, the same sensor mapping now works with and without rendering, and the behaviour with rendering on is unchanged. Verified on CARLA 0.10 `-nullrhi` with the full 9-sensor mapping (6 RGB cameras) and `no_rendering_mode:=True`: all six cameras are named in the warning and skipped, the ego spawns, LiDAR publishes at 10.0 Hz, the camera topics stay silent, and the CARLA server stays up - where previously it segfaulted (exit 139). Signed-off-by: Masaya Kataoka <cld-masaya.kataoka@tier4.jp> Co-authored-by: Masaya Kataoka <cld-masaya.kataoka@tier4.jp> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Max-Bin <vborisw@gmail.com>
shmpwk
pushed a commit
to tier4/pilot_auto_autoware_api
that referenced
this pull request
Oct 14, 2026
…is off (autowarefoundation/autoware_universe#13450) `no_rendering_mode` turns the scene rendering off, yet the camera sensors in the sensor mapping were still spawned in CARLA, where they can only ever return an empty image. Worse, the same flag describes the case that matters: a CARLA server started without a renderer (`CarlaUnreal.sh -nullrhi`) **segfaults as soon as a camera sensor is spawned on it**. Every call the bridge makes afterwards fails with an opaque `RuntimeError: std::exception`, so the logs point at whatever RPC came next rather than at the camera. The ray-cast LiDAR needs no renderer and keeps producing points, which makes such a server otherwise useful for headless LiDAR-only closed-loop runs. A client cannot detect a renderer-less server: its world settings, blueprint library and sensor attributes are byte-for-byte identical to a rendering one (verified by diffing a full client-side dump of both), and probing by spawning a test camera is what kills it. So follow `no_rendering_mode` and leave the cameras out of the CARLA spawn list, naming the skipped sensors once in a warning. Every sensor that works without rendering is spawned as before, the same sensor mapping now works with and without rendering, and the behaviour with rendering on is unchanged. Verified on CARLA 0.10 `-nullrhi` with the full 9-sensor mapping (6 RGB cameras) and `no_rendering_mode:=True`: all six cameras are named in the warning and skipped, the ego spawns, LiDAR publishes at 10.0 Hz, the camera topics stay silent, and the CARLA server stays up - where previously it segfaulted (exit 139). Signed-off-by: Masaya Kataoka <cld-masaya.kataoka@tier4.jp> Co-authored-by: Masaya Kataoka <cld-masaya.kataoka@tier4.jp> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Max-Bin <vborisw@gmail.com>
shmpwk
pushed a commit
to tier4/pilot_auto_autoware_api
that referenced
this pull request
Oct 14, 2026
…is off (autowarefoundation/autoware_universe#13450) `no_rendering_mode` turns the scene rendering off, yet the camera sensors in the sensor mapping were still spawned in CARLA, where they can only ever return an empty image. Worse, the same flag describes the case that matters: a CARLA server started without a renderer (`CarlaUnreal.sh -nullrhi`) **segfaults as soon as a camera sensor is spawned on it**. Every call the bridge makes afterwards fails with an opaque `RuntimeError: std::exception`, so the logs point at whatever RPC came next rather than at the camera. The ray-cast LiDAR needs no renderer and keeps producing points, which makes such a server otherwise useful for headless LiDAR-only closed-loop runs. A client cannot detect a renderer-less server: its world settings, blueprint library and sensor attributes are byte-for-byte identical to a rendering one (verified by diffing a full client-side dump of both), and probing by spawning a test camera is what kills it. So follow `no_rendering_mode` and leave the cameras out of the CARLA spawn list, naming the skipped sensors once in a warning. Every sensor that works without rendering is spawned as before, the same sensor mapping now works with and without rendering, and the behaviour with rendering on is unchanged. Verified on CARLA 0.10 `-nullrhi` with the full 9-sensor mapping (6 RGB cameras) and `no_rendering_mode:=True`: all six cameras are named in the warning and skipped, the ego spawns, LiDAR publishes at 10.0 Hz, the camera topics stay silent, and the CARLA server stays up - where previously it segfaulted (exit 139). Signed-off-by: Masaya Kataoka <cld-masaya.kataoka@tier4.jp> Co-authored-by: Masaya Kataoka <cld-masaya.kataoka@tier4.jp> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Max-Bin <vborisw@gmail.com>
shmpwk
pushed a commit
to tier4/pilot_auto_planning
that referenced
this pull request
Oct 14, 2026
…is off (autowarefoundation/autoware_universe#13450) `no_rendering_mode` turns the scene rendering off, yet the camera sensors in the sensor mapping were still spawned in CARLA, where they can only ever return an empty image. Worse, the same flag describes the case that matters: a CARLA server started without a renderer (`CarlaUnreal.sh -nullrhi`) **segfaults as soon as a camera sensor is spawned on it**. Every call the bridge makes afterwards fails with an opaque `RuntimeError: std::exception`, so the logs point at whatever RPC came next rather than at the camera. The ray-cast LiDAR needs no renderer and keeps producing points, which makes such a server otherwise useful for headless LiDAR-only closed-loop runs. A client cannot detect a renderer-less server: its world settings, blueprint library and sensor attributes are byte-for-byte identical to a rendering one (verified by diffing a full client-side dump of both), and probing by spawning a test camera is what kills it. So follow `no_rendering_mode` and leave the cameras out of the CARLA spawn list, naming the skipped sensors once in a warning. Every sensor that works without rendering is spawned as before, the same sensor mapping now works with and without rendering, and the behaviour with rendering on is unchanged. Verified on CARLA 0.10 `-nullrhi` with the full 9-sensor mapping (6 RGB cameras) and `no_rendering_mode:=True`: all six cameras are named in the warning and skipped, the ego spawns, LiDAR publishes at 10.0 Hz, the camera topics stay silent, and the CARLA server stays up - where previously it segfaulted (exit 139). Signed-off-by: Masaya Kataoka <cld-masaya.kataoka@tier4.jp> Co-authored-by: Masaya Kataoka <cld-masaya.kataoka@tier4.jp> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Max-Bin <vborisw@gmail.com>
isamu-takagi
pushed a commit
to tier4/pilot_auto_system
that referenced
this pull request
Nov 6, 2026
…is off (autowarefoundation/autoware_universe#13450) `no_rendering_mode` turns the scene rendering off, yet the camera sensors in the sensor mapping were still spawned in CARLA, where they can only ever return an empty image. Worse, the same flag describes the case that matters: a CARLA server started without a renderer (`CarlaUnreal.sh -nullrhi`) **segfaults as soon as a camera sensor is spawned on it**. Every call the bridge makes afterwards fails with an opaque `RuntimeError: std::exception`, so the logs point at whatever RPC came next rather than at the camera. The ray-cast LiDAR needs no renderer and keeps producing points, which makes such a server otherwise useful for headless LiDAR-only closed-loop runs. A client cannot detect a renderer-less server: its world settings, blueprint library and sensor attributes are byte-for-byte identical to a rendering one (verified by diffing a full client-side dump of both), and probing by spawning a test camera is what kills it. So follow `no_rendering_mode` and leave the cameras out of the CARLA spawn list, naming the skipped sensors once in a warning. Every sensor that works without rendering is spawned as before, the same sensor mapping now works with and without rendering, and the behaviour with rendering on is unchanged. Verified on CARLA 0.10 `-nullrhi` with the full 9-sensor mapping (6 RGB cameras) and `no_rendering_mode:=True`: all six cameras are named in the warning and skipped, the ego spawns, LiDAR publishes at 10.0 Hz, the camera topics stay silent, and the CARLA server stays up - where previously it segfaulted (exit 139). Signed-off-by: Masaya Kataoka <cld-masaya.kataoka@tier4.jp> Co-authored-by: Masaya Kataoka <cld-masaya.kataoka@tier4.jp> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Max-Bin <vborisw@gmail.com>
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
no_rendering_modeturns the scene rendering off, yet the camera sensors in the sensor mappingwere still spawned in CARLA, where they can only ever return an empty image.
Worse, the same flag describes the case that actually matters: a CARLA server started without
a renderer (
CarlaUnreal.sh -nullrhi) segfaults as soon as a camera sensor is spawned onit. Every call the bridge makes afterwards fails with an opaque
RuntimeError: std::exception,so the logs point at whatever RPC came next rather than at the camera — in one run here it
surfaced 20 s later (the client's RPC timeout) as a complaint about the ego vehicle's light
state, and the process eventually aborted with
exit -6.The ray-cast LiDAR, by contrast, needs no renderer and keeps producing points, which makes a
renderer-less server a practical way to run LiDAR-only closed-loop tests without a display. The
camera crash is the only thing standing in the way.
A client cannot detect such a server. Dumping everything visible from the client side on a
-nullrhiserver and on a-RenderOffScreenone — world settings, blueprint library, everysensor.camera.rgbattribute,get_names_of_all_objects,get_environment_objects,get_level_bbs, weather, the wholeworldAPI — produces identical output. Probing byspawning a test camera is self-defeating, since that is the thing that kills the server.
Fix
Follow
no_rendering_modeand leave the cameras out of the CARLA spawn list, naming the skippedsensors once in a warning:
and without rendering, and
no_rendering_modeis already forwarded byautoware_launch'se2e_simulator.launch.xml.cameras keep their topics advertised, just silent.
renderer earlier are untouched.
Verification
On CARLA 0.10 started with
CarlaUnreal.sh -nullrhi, using the full 9-sensor mapping (6 RGBcameras),
no_rendering_mode:=True:/sensing/camera/CAM_FRONT/image_rawstays silentPlus
pytest simulator/autoware_carla_interface/test— 27 passed.🤖 Generated with Claude Code