Credit: Original guide by wambitz. I’m reposting the key steps here and layering in my own notes.

Table of Contents

1. Why This Guide?
2. Prerequisites
3. Setting Up the Environment
4. Build Unreal Engine 4 for CARLA
5. Building CARLA from Source
6. Launching the CARLA Simulator
7. Running the CARLA Client
8. My Personal Tips & Fixes

Why This Guide?

• Up-to-Date: Tailored for CARLA v0.9.15, Windows 11, and Visual Studio 2022.
• Time-Saving: Avoid pitfalls that cost me hours or days.
• Personal Fixes: Includes troubleshooting for real errors I hit beyond the original guide.

Prerequisites

System Requirements

NOTE: The build can take 5+ hours on the reference hardware below.

Software Requirements

IMPORTANT: If you have multiple Python versions installed, make sure Python 3.8 is first in your PATH. Python 3.10 will not work. Do NOT use a virtual environment for building the CARLA package.

Required tools:

⚠️ CMake Version Warning: Use CMake >= 3.15 but < 3.50. CMake 3.50+ removed backward compatibility that CARLA’s build scripts rely on and will cause cryptic errors later. Download older releases from cmake.org/files.

Ensure all tools are added to your system PATH.

Python Dependencies

pip install --upgrade pip
pip install --user setuptools
pip install --user wheel

Setting Up the Environment

Install Dependencies

Git — verify:

git --version

CMake (must be >= 3.15 and < 3.50):

cmake --version
rem Must show >= 3.15 and < 3.50

Make via Chocolatey (requires admin):

choco install make
make --version

7-Zip — download from 7-zip.org.

Python 3.8 (64-bit) — download from python.org. Add to PATH during installation:

python --version
pip --version

Install Visual Studio 2022

IMPORTANT: Do not have multiple Visual Studio versions installed simultaneously — even uninstalled remnants can cause conflicts.

Download Visual Studio 2022 and select:

Workloads:

• Desktop Development with C++
• .NET Desktop Development

Individual Components:

• Windows 10 SDK (use the latest Windows 10 SDK even on Windows 11)
• C++ CMake Tools for Windows

Complete installation and restart your computer.

Build Unreal Engine 4 for CARLA

NOTE: You need your GitHub account linked to your Epic Games account to access the CARLA UE4 fork. Follow these instructions.

Keep the path short (e.g., C:\CarlaUE4). Long paths cause errors in Setup.bat.

git clone --depth 1 -b carla https://github.com/CarlaUnreal/UnrealEngine.git CarlaUE4
cd CarlaUE4

Run the setup scripts:

NOTE: If a Windows pop-up about an incompatible framework appears, select Download.

Setup.bat
GenerateProjectFiles.bat

Compile the Engine

NOTE: This step takes several hours (5+ hours on the reference machine).

1. Open UE4.sln in C:\CarlaUE4 with Visual Studio 2022.
2. Set Configuration: Development Editor and Platform: Win64.
3. In Solution Explorer, right-click UE4 → Build.
4. After the build, verify by running Engine\Binaries\Win64\UE4Editor.exe.

Building CARLA from Source

Clone the CARLA Repository

git clone https://github.com/carla-simulator/carla.git -b 0.9.15 carla-0.9.15
cd carla-0.9.15

Download Assets

NOTE: If assets are missing at runtime, make launch-only will crash with a segmentation fault.

Before running Update.bat, you must apply two patches to fix known bugs in the script:

Patch 1 — Fix the broken download URL

The original S3 URL is dead for CARLA 0.9.15 (asset ID 20231108_c5101a5). Open C:\carla-0.9.15\Update.bat and replace:

set CONTENT_LINK=http://carla-assets.s3.amazonaws.com/%CONTENT_ID%.tar.gz

with:

set CONTENT_LINK=https://carla-assets.s3.us-east-005.backblazeb2.com/%CONTENT_ID%.tar.gz

Patch 2 — Fix the 7-Zip command path

Update.bat calls 7zip, but the actual executable is 7z.exe. Without this fix, extraction falls back to PowerShell’s Expand-Archive, which does not support .tar.gz and will throw:

Expand-Archive : .gz is not a supported archive file format.

Find the line calling 7zip x ... and replace 7zip with the full path:

"C:\Program Files (x86)\7-Zip\7z.exe" x ...

If you installed 7-Zip elsewhere, adjust the path accordingly. Alternatively, add C:\Program Files (x86)\7-Zip to your system PATH so that 7z is recognized globally.

After applying both patches, run:

Update.bat

Install Python Packages

IMPORTANT: Do NOT compile CARLA inside a virtual environment — this triggers a B2.EXE error. Use Python 3.8 system-wide.

python --version
rem Must output: Python 3.8.XX

pip install wheel
pip list
pip --version

Compile the Python API

NOTES:

• The build defaults to Visual Studio 2019. Since we’re on VS 2022, we must specify the generator explicitly.
• Python 3.8 must be the top version in your system PATH.
• This takes around 30 minutes.

❗ You CANNOT run this in a regular cmd or PowerShell terminal. You must use the x64 Native Tools Command Prompt for VS 2022, which sets up the correct compiler environment variables. Running in a regular terminal causes cryptic build failures.

How to open it: Start menu → type x64 → select “x64 Native Tools Command Prompt for VS 2022”

cd C:\carla-0.9.15
make PythonAPI GENERATOR="Visual Studio 17 2022"

🔧 Troubleshooting: Boost Linker Error (Wrong MSVC Toolset)

⚠️ Error:

LINK : fatal error LNK1104: cannot open file 'libboost_filesystem-vc142-mt-x64-1_80.lib'

Cause: Boost was compiled with MSVC 14.2 (VS 2019) but you’re using MSVC 14.3 (VS 2022).

Fix: Delete the existing Boost build and reinstall with the correct toolset:

rem Delete the current Boost installation
rm -r .\Build\boost-1.80.0-install\

rem Reinstall with the correct toolset (-j 32 = parallel jobs, adjust to your CPU)
.\Util\InstallersWin\install_boost.bat --build-dir "C:\carla-0.9.15\Build\" --toolset msvc-14.3 --version 1.80.0 -j 32

rem Rebuild the Python API
make PythonAPI GENERATOR="Visual Studio 17 2022"

🔧 Troubleshooting: b2.exe Boost Build Error (Toolset Mismatch in Scripts)

⚠️ Error:

-[install_boost]: [B2 ERROR] An error ocurred while installing using "b2.exe".

Cause: Boost 1.80’s bootstrap.bat auto-detects vc143, but CARLA’s build scripts hardcode vc141/vc142 in two places.

Fix: Update the toolset to vc143 in two files:

1. Util\BuildTools\Windows.mk — around line 75, change vc141 or vc142 to vc143.
2. Util\InstallersWin\install_boost.bat — around line 109, change the same.

Then retry:

make PythonAPI GENERATOR="Visual Studio 17 2022"

Credit: fix originally identified by ThibaultFy (Aug 2021).

🔧 Troubleshooting: zlib Download Failure (Broken URL)

⚠️ Error:

[install_zlib]: Retrieving zlib.
Exception calling "DownloadFile" ... (404) Not Found.
[install_zlib]: [CMAKE ERROR] An error ocurred while executing cmake command.

Cause: zlib.net no longer hosts the file; the backup URL returns a 301 redirect that PowerShell’s WebClient won’t follow.

Fix: Open C:\carla-0.9.15\Util\InstallersWin\install_zlib.bat, find the line with ZLIB_REPO (containing zlib.net) and replace it with:

set ZLIB_REPO=https://github.com/madler/zlib/archive/refs/tags/v%ZLIB_VERSION%.zip

Clean up the half-created folders and retry:

rmdir /s /q Build\zlib-source
rmdir /s /q Build\zlib-install
del /q Build\zlib-1.2.13.zip

make PythonAPI GENERATOR="Visual Studio 17 2022"

🔧 Troubleshooting: CMake Too New (Compatibility Error)

⚠️ Error:

Compatibility with CMake < 3.5 has been removed from CMake.
[install_zlib]: [CMAKE ERROR] An error ocurred while executing cmake command.

Cause: CMake ≥ 3.50 dropped backward compatibility that CARLA’s CMakeLists.txt requires.

Fix: Downgrade to CMake >= 3.15 and < 3.50 (e.g., 3.28.6). Verify after installing:

cmake --version
rem Must show >= 3.15 and < 3.50

Then clean up and retry make PythonAPI as above.

Compile the CARLA Server

NOTE: This step takes 2+ hours.

make CarlaUE4Editor GENERATOR="Visual Studio 17 2022"

Output files will be created at: C:\carla-0.9.15\PythonAPI\carla\dist

🔧 Troubleshooting: OSM2ODR CMake “x64” Path Error

⚠️ Error:

CMake Error: The source directory ".../Build/osm2odr-visualstudio/x64" does not exist.
Ignoring extra path from command line: "...\Build\om2odr-source""

Cause: The script passes x64 as a positional argument instead of an architecture flag, so CMake misinterprets it as the source directory.

Fix: Open C:\carla-0.9.15\Util\BuildTools\BuildOSM2ODR.bat, find the CMake configure line containing -G %GENERATOR% %PLATFORM%, and change %PLATFORM% to -A x64:

cmake -G %GENERATOR% -A x64^

Clean the broken dirs and retry:

rmdir /s /q Build\osm2odr-visualstudio
rmdir /s /q Build\osm2odr-source
rmdir /s /q Build\om2odr-source

make PythonAPI GENERATOR="Visual Studio 17 2022"

🔧 Troubleshooting: “Unreal Engine Not Detected” / UE4_ROOT Not Set

⚠️ Error:

ERROR: The system was unable to find the specified registry key or value.
-[BuildCarlaUE4]: [ERROR] Unreal Engine not detected

Cause: CARLA checks the UE4_ROOT environment variable first, then falls back to the Windows registry — which usually doesn’t exist.

Fix: Set UE4_ROOT to wherever you cloned the CARLA UE4 fork. This path varies per user — the examples below use C:\CarlaUE4, but substitute your actual install location:

rem For the current session only
set UE4_ROOT=C:\CarlaUE4

rem To persist across all terminals (run once)
setx UE4_ROOT "C:\CarlaUE4"

If you cloned UE4 to a different drive, e.g. D:\UnrealEngine\CarlaUE4:

setx UE4_ROOT "D:\UnrealEngine\CarlaUE4"

Verify it’s correct (UE4Editor.exe should be listed):

echo %UE4_ROOT%
dir "%UE4_ROOT%\Engine\Binaries\Win64\UE4Editor.exe"

UE4_ROOT must point to the root folder (the one containing Engine\), not to Engine\Binaries\Win64 itself.

Haven’t built UE4 yet? Go back to the Build Unreal Engine 4 for CARLA section. The CARLA-specific fork (-b carla) must be fully compiled before this step will succeed.

Launching the CARLA Simulator

Change the Default Map (Optional)

By default, CARLA loads Town10HD_Opt, which is large and resource-intensive. To switch to a lighter map like Town02, edit Unreal\CarlaUE4\Config\DefaultEngine.ini:

[/Script/EngineSettings.GameMapsSettings]
EditorStartupMap=/Game/Carla/Maps/Town02.Town02
GameDefaultMap=/Game/Carla/Maps/Town02.Town02
ServerDefaultMap=/Game/Carla/Maps/Town02.Town02
GlobalDefaultGameMode=/Game/Carla/Blueprints/Game/CarlaGameMode.CarlaGameMode_C
GameInstanceClass=/Script/Carla.CarlaGameInstance
TransitionMap=/Game/Carla/Maps/Town02.Town02
GlobalDefaultServerGameMode=/Game/Carla/Blueprints/Game/CarlaGameMode.CarlaGameMode_C

Launch the CARLA Server

NOTE: The first launch is slow. On my machine it took ~20 min to open the Editor and ~30 min more for shader compilation. Subsequent launches are much faster thanks to caching.

make launch-only

Click Play in the Unreal Editor to start the simulation. Use WASD + mouse to move around.

Running the CARLA Client

Create a Python Virtual Environment

IMPORTANT: Do NOT create a virtual environment until the full build is complete. Use Python 3.8.

py -3.8 -m venv .venv
.\.venv\Scripts\activate

Install the CARLA Package

cd C:\carla-0.9.15\PythonAPI\carla\dist
pip install .\carla-0.9.15-cp38-cp38-win_amd64.whl

Install Example Script Dependencies

cd C:\carla-0.9.15\PythonAPI\examples
pip install -r requirements.txt

Start the Traffic Simulation

NOTE: Ensure the CARLA server is running before executing client scripts.

python generate_traffic.py

You should now see traffic in the simulation.

My Personal Tips & Fixes

I will continue updating this section with additional workarounds and lessons learned beyond the issues already documented above.

Conclusion

You’ve now built and launched CARLA on Windows 11 using Visual Studio 2022. Whether you’re using it for research, development, or experimentation, CARLA is a powerful platform for autonomous driving simulation. Good luck, and feel free to reach out if you hit issues not covered here!

Additional Resources

A new paper titled “SoK: How Sensor Attacks Disrupt Autonomous Vehicles: An End-to-end Analysis, Challenges, and Missed Threats” aims to bridge this gap.

The Gap: From Sensor Error to Physical Impact

Existing research often focuses on compromising a single sensor or algorithm. This paper takes a step back to provide a comprehensive survey and analysis across different platforms, sensing modalities, and attack methods.

The Framework: Modeling Error Propagation

At the core of this paper is a graph-based framework designed to map the journey of an attack:

1. Injection: How attacks inject errors into the system.
2. Propagation: The conditions under which these errors travel through modules—from perception and localization to planning and control.
3. Impact: When and how these errors manifest as physical consequences.

Key Findings & Missed Threats

Through this systematic analysis, the authors uncovered significant insights:

• 8 Key Findings:
  1. Perception Sensitivity: Attacks on perception sensors often require minimal physical impact to cause system failure.
  2. Localization Drift: Localization sensors are susceptible to attacks that induce small, cumulative errors leading to significant deviations over time.
  3. Fusion Vulnerability: Attacks targeting sensor fusion modules can be highly effective by exploiting inconsistencies between different sensor modalities.
  4. Context Dependency: The propagation of sensor-induced errors is highly dependent on the AV’s operational context and environmental conditions.
  5. Redundancy Bypass: Redundancy in sensing and processing can be bypassed by sophisticated attacks that understand the system’s failover logic.
  6. ML Black-Boxes: Machine learning components within the pipeline are major targets due to their black-box nature and sensitivity to input perturbations.
  7. Indirect Control Impact: Attacks on the planning and control modules, although less direct, can cause dangerous physical actions by exploiting model inaccuracies.
  8. Testing Gaps: End-to-end testing and validation are crucial but often insufficient to uncover complex attack vectors involving multiple system components.
• 12 Missed Threats:
  1. Multi-sensor Coordination: Multi-sensor coordinated attacks that exploit cross-modal dependencies.
  2. Physical Environment: Attacks leveraging the physical environment to manipulate sensor readings (e.g., reflections, occlusions).
  3. Temporal Dynamics: Attacks exploiting the temporal dynamics of sensor data and system processing.
  4. Adversarial ML on Fusion: Adversarial machine learning attacks specifically targeting sensor fusion algorithms.
  5. Edge Cases: Attacks exploiting edge cases and corner cases in perception and planning algorithms.
  6. Communication Channels: Attacks targeting communication between AV modules or between AV and infrastructure.
  7. Subtle Degradation: Attacks that induce subtle, long-term degradation of system performance rather than immediate failure.
  8. Human Interaction: Exploitation of human-in-the-loop systems and their interaction with the AV.
  9. Side-channels: Attacks leveraging side-channel information (e.g., power consumption, EM emissions) to infer system state or inject faults.
  10. Learning Mechanisms: Attacks against the AV’s learning and update mechanisms, poisoning data or models.
  11. Multi-AV Interaction: Exploiting the interaction between multiple AVs or between AVs and other road users.
  12. Simulation Exploits: Attacks targeting simulation environments used for AV testing and a false sense of security.

This Systematization of Knowledge (SoK) serves as a critical wake-up call and a roadmap for future defense strategies, emphasizing that securing individual sensors is not enough—we must secure the entire pipeline.

Read the full paper on arXiv Download PDF

The Problem: Latency as a Weapon

Denial-of-Service (DoS) attacks on autonomous vehicles (AVs) can be catastrophic. If an AV’s perception system is delayed, even by a split second, it may fail to react to obstacles or pedestrians in time. Previous research into latency attacks has often been limited to:

• Digital-only attacks: Simulations that cannot be easily replicated in the physical world.
• Unscalable physical patches: Large, conspicuous patterns that block the camera’s view, which are easily detectable and impractical to deploy discreetly.

The challenge was to create a physically realizable attack that could overwhelm the perception pipeline without requiring massive physical alterations to the scene.

Proposed Method: Detstorm

The researchers propose Detstorm, a new attack method that exploits the computational bottlenecks in object detection pipelines.

1. Concept

Detstorm works by flooding the object detector with a massive number of “ghost” adversarial objects. By forcing the system to process hundreds of non-existent detections, the pipeline’s latency effectively creates a DoS condition.

2. Design & Methodology

To achieve this in the real world, Detstorm uses projector perturbations—light patterns projected onto the scene. Key components of the design include:

• Evading NMS (Non-Maximum Suppression): Object detectors use NMS to filter out overlapping boxes for the same object. Detstorm optimizes its adversarial objects to specifically evade this filtering, ensuring that the system keeps as many false positives as possible.
• Zone Stitching: Projecting a single coherent image that covers a large area is difficult. Detstorm uses a “zone stitching” process to recombine perturbation patterns into a single, contiguous image that can be projected physically and effectively.
• Greedy Zone Strategy: The attack segments the environment into zones containing different object classes. It then employs a greedy algorithm to maximize the number of created objects within each specific zone.

Effectiveness & Results

The paper presents rigorous evaluations in both simulated and real-world environments. The results are startling:

• 506% increase in the number of detected objects on average.
• Perception delays of up to 8.1 seconds, which is an eternity in autonomous driving contexts.
• The attack was proven to be physically realizable, capable of causing tangible consequences for real-world autonomous driving systems.

This research highlights a critical vulnerability in current perception architectures. As we move towards fully autonomous roads, defense mechanisms against not just misclassification, but pipeline overload, will be essential.

Reference: R. Muller, R. Song, C. Wang, Y. Zhan, J.-P. Monteuuis, Y. Man, M. Li, R. Gerdes, J. Petit, and Z. B. Celik, “Investigating Physical Latency Attacks Against Camera-Based Perception,” 2025 IEEE Symposium on Security and Privacy (S&P), 2025. DOI: 10.1109/SP61157.2025.00236

The Concept: Distance-Pulling Attack (DPA)

The core of this research is the Distance-Pulling Attack (DPA). The goal is simple but dangerous: deceive the drone into believing the target is further away than it actually is. This causes the drone’s control system to move closer to maintain the “correct” tracking distance, potentially leading to capture or collision.

Design: The Adversarial Umbrella

The researchers proposed a novel attack vector: an Adversarial Umbrella.

Why an umbrella?

• Deployable: It’s a common object, effectively hiding the attack in plain sight.
• Inconspicuous: Unlike obvious adversarial patches, a patterned umbrella doesn’t raise immediate suspicion.
• Control: It allows the attacker to easily manipulate the visual input presented to the drone.

Logic & Methodology

To achieve a robust attack, the system, dubbed FlyTrap, uses two key components:

1. Progressive Distance-Pulling (PDP) Strategy

Attacking a moving drone is difficult because the visual perspective changes constantly. The PDP strategy addresses this by simulating the attack’s effects under gradually decreasing distances. It uses physical modeling to estimate the distance and generates adversarial patterns that remain effective as the drone moves closer.

2. Attack Target Generator (ATG)

A major challenge in physical adversarial attacks is maintaining consistency across different viewing angles and frames (spatial-temporal consistency). The ATG solves this by explicitly encoding these constraints during the optimization process. It ensures that the generated adversarial pattern looks plausible to the drone’s tracking algorithm from multiple angles and over time, bypassing consistency-checking defenses.

Real-World Impact

The effectiveness of FlyTrap is alarming. Evaluations demonstrated that it works against real-world commercial ATT drones, including widely used models from DJI and HoverAir. The attack successfully reduced tracking distances to the point where drones could be:

• Captured: Physically grabbed by the attacker.
• Sensor Attacked: Brought close enough for other short-range attacks.
• Crashed: Tricked into colliding with the target or obstacles.

This research highlights a urgent need for robust defense mechanisms in autonomous systems, as simple visual deception can lead to physical safety risks.

Read the full paper on arXiv Download PDF

The Route

We planned our route to hit several iconic cities along the way:

1. Columbus, OH 🏁
   • Our journey began here, packing up the car and heading west on I-70.
2. St. Louis, MO
   • Our first major landmark was the Gateway Arch, standing tall over the Mississippi River.
3. Kansas City, MO
   • We stopped for some world-famous BBQ and enjoyed the vibrant atmosphere before pushing into the Great Plains.
4. Denver, CO
   • The scenery changed dramatically as we approached the Rockies. The “Mile High City” offered stunning mountain views and crisp air.
5. Las Vegas, NV
   • A dazzling stop in the Mojave Desert. The neon lights of the Strip were a surreal contrast to the miles of open road we just covered.
6. Los Angeles, CA 🌴
   • Final destination! Arriving at the Pacific Coast felt like a huge accomplishment after days of driving.

From the forests of the Midwest to the endless horizon of the plains, the towering peaks of the Rockies, and the arid beauty of the desert—this trip showed us the incredible diversity of the US landscape.