Build distributable CARLA releases or asset packages containing selected maps and props. It prepares content for runtime use, checks output files, supports destination changes, and preserves native ROS 2 support when explicitly enabled.
Cooks and packages CarlaUE4 into distributable tarballs under Dist/ — either the full simulator or a standalone asset package of selected maps and props for later import. ROS2=1 keeps the native ROS 2 interface in the cooked package (a plain cook silently drops it). Use when the user asks to "package CARLA", "make a Dist build", "cook the project", "export a map as a package", "package CARLA with ROS2", or needs a build with working camera and lidar sensors.
Review the instructions the agent will receive before you install.
Paths.
scripts/…andreferences/…below are relative to the directory holding this SKILL.md. Your working directory is the user's project, not that directory, so prefix them with its absolute path or the command is not found.
make package produces two different artifacts depending on --packages:
| Mode | Command | Output | Cook driven by |
|---|---|---|---|
| Release | bash scripts/package.sh | Dist/CARLA_<tag>.tar.gz | Config/DefaultGame.ini |
| Asset package | PACKAGES=<Name> bash scripts/package.sh | Dist/<Name>_<tag>.tar.gz | <Name>.Package.json |
Copy this checklist and track progress — the run is long and gated, so a skipped step usually surfaces an hour in:
Package Progress:
- [ ] Step 1: Activate the client Python env, run check_env.sh, clear FAILs
- [ ] Step 2: Cook — 2a full release, or 2b a named asset package
- [ ] Step 3: Verify the artifact exists, is the right size, and is in Dist/
- [ ] (opt-in) Run or import the build — only if asked to run/load it
The wheel stage runs python3 -m build, so have your CARLA client
environment active first — the one whose python3 imports build and
carla. Any manager works (venv, conda, system); the skill assumes none and
pins no version. If you drive this non-interactively, either activate the env
in the same shell, or point CARLA_ENV_ACTIVATE at its activate script — the
only hook the skill looks at. Only set CARLA_PY_VERSION if you
deliberately need a version-suffixed interpreter — and it must resolve inside
that env, or the wheel escapes to the wrong Python.
bash scripts/check_env.sh
Fix warnings about the wheel python and missing content before starting — both cost most of the build time before they surface.
bash scripts/package.sh 2>&1 | tee /tmp/carla_package.log
30-90 min cold, not resumable.
For distributing maps and props, or for a cheap sensor-capable build containing one town instead of thirteen.
A package is defined by a JSON found anywhere under Content/ — the package
name is the filename minus .Package.json. It needs no matching directory, so
stock maps can be exported as-is:
# define it (writes Content/Carla/Config/OneTown.Package.json)
python3 scripts/package_json.py OneTown --map Town02 --carla-materials
# cook it
PACKAGES=OneTown bash scripts/package.sh
Each map needs <MapName>.xodr under an OpenDrive/ directory somewhere in
Content/. package_json.py --check verifies this; a missing .xodr yields a
package that imports but has no road network.
scripts/package.sh already checks the expected artifact by name, size and
location, and fails loudly if it is missing — make can exit 0 having produced
nothing. Confirm independently:
ls -la "${CARLA_UE4_ROOT:?}"/Dist/
A release is several GB; low megabytes means the cook ran without content.
This is where the skill stops by default. The deliverable is the verified
artifact in Dist/ (or in PACKAGE_DEST, below). Booting or importing it is a
separate, opt-in step — do it only when the request explicitly asks to run or
load the result.
Set PACKAGE_DEST to a directory to land the artifact elsewhere. It is applied
after verification: PACKAGE_DEST_MODE=move (the default) relocates the verified
artifact and leaves no multi-GB duplicate in Dist/; PACKAGE_DEST_MODE=copy
keeps Dist/ intact. So "package CARLA into <dir>" is a move, "package CARLA and
copy it to <dir>" is a copy.
# move the release into ~/dev/Carla/packages/ (nothing left in Dist/)
PACKAGE_DEST=~/dev/Carla/packages bash scripts/package.sh
# copy instead, keeping Dist/
PACKAGE_DEST=~/dev/Carla/packages PACKAGE_DEST_MODE=copy bash scripts/package.sh
ROS2=1)ROS2=1 bash scripts/package.sh # release WITH the native ROS 2 interface
Package.sh has no ROS 2 option — support is inherited from the editor
build. But make package depends on CarlaUE4Editor, so every cook re-runs
BuildCarlaUE4.sh, which rewrites Unreal/CarlaUE4/Config/OptionalModules.ini.
Cook without ROS2=1 and that rewrite says Ros2 OFF: the package loses ROS 2
even though the checkout was built with it, with nothing in the log to say so.
Hence:
ROS2=1 appends --ros2 to the forwarded ARGS (Package.sh and
BuildPythonAPI.sh print a harmless unrecognized option '--ros2'; only
Setup.sh/BuildLibCarla.sh/BuildCarlaUE4.sh act on it).ROS2=1 from a ROS-2-built checkout warns and pauses 5 s.package.sh re-reads the ini and fails if ROS2=1 did not
end up as Ros2 ON — the staged binaries would have no ROS 2.Build/{fast-dds,cyclone-dds,zenoh}-install) are not
built yet, this cook builds them first — add that to the 30-90 min.Serve the result with [[run-carla-server]] PACKAGED=1 ROS2=1 (the runtime
--ros2 flag is separate); build-time detail in
[[build-carla-ue4]] references/ros2.md.
Only when the request asks to run or load the result (e.g. "package the engine and Town15, then run the server and load it"). Packaging on its own boots nothing.
# release: boot the packaged server, then load a town from a client
PACKAGED=1 bash ../run-carla-server/scripts/run_server.sh >/tmp/carla_pkg.log 2>&1 &
until nc -z 127.0.0.1 2000; do sleep 1; done
python -c "import carla; c=carla.Client('127.0.0.1',2000); c.set_timeout(60); \
print('loaded', c.load_world('Town15').get_map().name)"
pkill -x CarlaUE4-Linux- # NOT ...-Shipping: comm is truncated to 15 chars
# asset package: install into an extracted release first, from its ROOT
cp Dist/OneTown_TAG.tar.gz RELEASE/Import/
cd RELEASE && ./ImportAssets.sh
The packaged server process is CarlaUE4-Linux-Shipping, not UE4Editor.
Asset packages import only into a packaged release, never a source build,
and are platform-specific.
Flags (PACKAGE_CONFIG, PACKAGE_ZIP, CLEAN_INTERMEDIATE, ARCHIVE_SUFIX,
TARGET_ARCHIVE, PACKAGE_DEST, PACKAGE_DEST_MODE) and the JSON schema:
references/packaging.md.
Example 1: full release (build only)
User says: "package CARLA"
Check prerequisites, bash scripts/package.sh, verify size and location. Deliverable:
Dist/CARLA_<tag>.tar.gz, several GB. The skill stops here — nothing is booted.
Example 2: export one town
User says: "export Town02 as a package I can drop into a release"
python3 scripts/package_json.py OneTown --map Town02 --carla-materials, then
PACKAGES=OneTown bash scripts/package.sh. Result Dist/OneTown_<tag>.tar.gz
for ImportAssets.sh.
Example 3: package, then run and load (opt-in)
User says: "package the CARLA engine and Town15, then run the server and load the packaged town"
Build the release (it contains the towns) and verify, then — because the request
asked for it — boot with PACKAGED=1 and load the town from a client, per
"Optional: run the packaged build" above.
Example 4: fast iteration
User says: "I just need the staged build, skip the tarball"
PACKAGE_ZIP=0 bash scripts/package.sh leaves
Dist/CARLA_Shipping_<tag>/LinuxNoEditor runnable in place, skipping compression.
Error: No module named build.__main__
Cause: the PythonAPI.wheel prerequisite runs python3 -m build, and the
active python3 has no build module. It runs after the editor compile, before
the cook, so the compile is not wasted.
Solution: activate the env whose python3 has build (or pip install build
into it) and re-run; compiled artifacts survive. scripts/package.sh verifies
this up front and forwards no version, so the active env's python3 is used —
a hand-run make package uses whatever python3 is on PATH.
Error: Package json file not found
Cause: no <Name>.Package.json anywhere under Content/.
Solution: python3 scripts/package_json.py <Name> --map .... The name must match
the filename exactly, minus the suffix.
Error: asset package imports but the map has no roads
Cause: no <MapName>.xodr found under an OpenDrive/ directory.
Solution: place it beside the .umap, named exactly like the map. Check with
python3 scripts/package_json.py <Name> --check.
Error: package tarball absurdly large or corrupt
Cause: content packages are built with tar -rf, which appends. A stale
Dist/<Name>_*.tar from an interrupted run is added to, not replaced.
Solution: rm Dist/<Name>_*.tar and re-run. scripts/package.sh refuses to
start when one is present.
Error: release tarball is only a few MB Cause: cooked with no content. Solution: build the carla content first, then re-package.
Error: killed mid-cook, or the machine freezes Cause: OOM — the cook parallelises and each worker is memory-hungry. Solution: free RAM or add swap; there is no parallelism knob (packaging.md P3). Re-running is cheap — the cook is iterative, so cooked assets are reused.
Dist/CARLA_<tag>.tar.gz — full release (Shipping; other configs carry the
config in the name).Dist/<Name>_<tag>.tar.gz — standalone asset package.Dist/CARLA_<config>_<tag>/LinuxNoEditor — staged tree, runnable in place.<tag> is the git short SHA, suffixed -dirty when tracked files are modified.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Add a message type to CARLA's native ROS 2 interface. Create its C++ data structure, serialization code for transmission, type identity hash, registration, and tests, with Docker-based hash calculation and build checks.
Extend CARLA’s native ROS 2 interface to publish sensor data or receive vehicle commands. Covers topic implementation, registration, data connections, and verification, plus adding middleware, the communication layer used to exchange messages.
Summarize ScenarioRunner results to see which scenarios passed and which checks failed. Compare runs before and after changes, or analyze recorded driving to produce measurements and plots of vehicle distance and deviation from the lane center.
Checks a local CARLA checkout for missing API documentation, outdated references, broken links, and pages absent from navigation. Produces a grouped Markdown report without building the project or running the simulator.
Read and display CARLA object bounding boxes, then project them onto a camera image as 2D rectangles. Export an annotated PNG and box coordinates in JSON for object detection annotation work.
Builds CARLA's ue4-dev branch on Linux, producing the Unreal Engine 4.26 editor, server modules, and an installed Python client package. Fetches required content, optionally compiles native ROS 2 support, and verifies the build against a source-built server.