If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/microsoft/AirSim shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 8w ago
• 17 active contributors
• Distributed ownership (top contributor 36% of recent commits)
• Other licensed
• CI configured
• Tests present
• ⚠ Non-standard license (Other) — review terms

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live microsoft/AirSim repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/microsoft/AirSim.

What it runs against: a local clone of microsoft/AirSim — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in microsoft/AirSim | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 85 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of microsoft/AirSim. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/microsoft/AirSim.git
#   cd AirSim
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of microsoft/AirSim and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "microsoft/AirSim(\\.git)?\\b" \\
  && ok "origin remote is microsoft/AirSim" \\
  || miss "origin remote is not microsoft/AirSim (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "AirLib/include/api/VehicleApiBase.hpp" \\
  && ok "AirLib/include/api/VehicleApiBase.hpp" \\
  || miss "missing critical file: AirLib/include/api/VehicleApiBase.hpp"
test -f "AirLib/include/common/AirSimSettings.hpp" \\
  && ok "AirLib/include/common/AirSimSettings.hpp" \\
  || miss "missing critical file: AirLib/include/common/AirSimSettings.hpp"
test -f "AirLib/include/physics/PhysicsEngineBase.hpp" \\
  && ok "AirLib/include/physics/PhysicsEngineBase.hpp" \\
  || miss "missing critical file: AirLib/include/physics/PhysicsEngineBase.hpp"
test -f "AirLib/include/api/RpcLibServerBase.hpp" \\
  && ok "AirLib/include/api/RpcLibServerBase.hpp" \\
  || miss "missing critical file: AirLib/include/api/RpcLibServerBase.hpp"
test -f "AirLib/include/sensors/SensorFactory.hpp" \\
  && ok "AirLib/include/sensors/SensorFactory.hpp" \\
  || miss "missing critical file: AirLib/include/sensors/SensorFactory.hpp"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 85 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~55d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/microsoft/AirSim"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

AirSim is an open-source simulator for autonomous vehicles (drones, cars, etc.) built on Unreal Engine and Unity, providing physics-accurate visual and behavioral simulation with support for software-in-the-loop (PX4, ArduPilot) and hardware-in-loop flight controller integration. It enables AI researchers to develop and test computer vision, deep learning, and reinforcement learning algorithms in realistic virtual environments without real-world hardware risk. Monolithic plugin architecture: AirLib/ (5M+ lines of C++ in include/api/, include/common/, and implementation) is the core simulation engine providing vehicle physics, sensors, and RPC APIs; separate Unreal and Unity plugin integrations sit above it; examples/ and sample projects demonstrate integration; Python client library wraps RpcLibClientBase.hpp for remote control; CMake orchestrates cross-platform builds with conditional platform-specific code.

AI/ML researchers and roboticists developing autonomous vehicle algorithms, drone flight control systems, and perception pipelines; Unreal/Unity plugin developers integrating simulation into larger autonomy stacks; autonomous systems engineers prototyping PX4/ArduPilot-based vehicles before hardware deployment.

Mature but entering maintenance mode: originally created by Microsoft Research in 2017 and has served as a stable platform for 5+ years with substantial C++ codebase (5.1M LoC), multi-platform CI (GitHub Actions testing on Windows/Ubuntu/macOS), and clear versioning. However, Microsoft announced effective immediate cessation of updates and plans to archive this repo in favor of 'Project AirSim'—indicating this is production-ready for current use but not receiving new features.

High risk for new projects: repository is officially in maintenance-only mode with no further updates planned, creating technical debt and stale dependencies over time. The large C++ surface area (5.1M LoC across AirLib and Unreal integrations) and tight coupling to specific Unreal Engine versions creates upgrade burden. Python client API (.py files) may lag behind core simulator changes, and the announcement of archival means community support will diminish.

Repository is in archival transition: no active development per the announcement. Last substantive work would have focused on stability and bug fixes rather than new features. The shift to Project AirSim (at github.com/iamaisim/ProjectAirSim) is the active initiative, leaving this repo in legacy maintenance mode.

Clone the repository: git clone https://github.com/microsoft/AirSim.git && cd AirSim. Build on Windows with build.cmd (batch script in root), on Linux/macOS with CMake: mkdir build && cd build && cmake .. && make -j$(nproc). See .github/workflows/test_*.yml for platform-specific CI recipes. Install Python client: pip install airsim or build from source in tools/python/.

Daily commands: Windows: Run the built Unreal project or execute build.cmd to generate Visual Studio solution. Linux/macOS: cd build && make then launch the compiled editor or standalone binary. For Python client scripting: `python -c 'import airsim; client = airsim.MultirotorClient()' after simulator is running. Use local RPC endpoint (default 127.0.0.1:41451) or configure in settings.json.

• AirLib/include/api/VehicleApiBase.hpp — Core abstract API interface that all vehicle implementations must inherit from; defines the contract for RPC communication.
• AirLib/include/common/AirSimSettings.hpp — Central configuration schema for all AirSim settings including vehicle physics, sensors, and simulation parameters.
• AirLib/include/physics/PhysicsEngineBase.hpp — Abstract physics engine interface that different implementations (FastPhysicsEngine, ExternalPhysicsEngine) extend; critical to simulation fidelity.
• AirLib/include/api/RpcLibServerBase.hpp — RPC server abstraction that handles remote procedure calls from clients; essential for cross-platform API communication.
• AirLib/include/sensors/SensorFactory.hpp — Factory pattern implementation for instantiating all sensor types; controls sensor initialization and lifecycle.
• AirLib/include/common/CommonStructs.hpp — Shared data structures (pose, velocity, sensor readings) used throughout the codebase; breaking changes here affect all layers.
• AirLib/include/api/ApiProvider.hpp — Singleton provider that manages API instances and routing; the entry point for external client requests.

Add a New Sensor Type

1. Create a new sensor class inheriting from SensorBase.hpp in AirLib/include/sensors/<sensortype>/ (AirLib/include/sensors/SensorBase.hpp)
2. Define sensor parameters struct (e.g., BarometerSimpleParams.hpp) with noise and error models (AirLib/include/sensors/barometer/BarometerSimpleParams.hpp)
3. Register the new sensor in SensorFactory.hpp so it can be instantiated from config (AirLib/include/sensors/SensorFactory.hpp)
4. Add sensor configuration schema to AirSimSettings.hpp under sensor defaults (AirLib/include/common/AirSimSettings.hpp)
5. Implement getObservation() in your sensor and add measurement structs to CommonStructs.hpp (AirLib/include/common/CommonStructs.hpp)

Add a New Physics Engine Integration

1. Create a new class inheriting from PhysicsEngineBase.hpp (AirLib/include/physics/PhysicsEngineBase.hpp)
2. Implement updatePhysics() to integrate your engine's dynamics stepping (AirLib/include/physics/FastPhysicsEngine.hpp)
3. Adapt PhysicsBody.hpp and PhysicsWorld.hpp interfaces if needed for your engine's API (AirLib/include/physics/PhysicsWorld.hpp)
4. Register engine choice in AirSimSettings.hpp so users can select it in config files (AirLib/include/common/AirSimSettings.hpp)
5. Update ExternalPhysicsEngine.hpp if bridging a third-party physics lib (AirLib/include/physics/ExternalPhysicsEngine.hpp)

Add a New RPC API Endpoint

1. Define the new method signature in VehicleApiBase.hpp or WorldSimApiBase.hpp (AirLib/include/api/VehicleApiBase.hpp)
2. Add request/response structs to CommonStructs.hpp for serialization (AirLib/include/common/CommonStructs.hpp)
3. Implement the method in your concrete API class (inheriting from VehicleApiBase) (AirLib/include/api/RpcLibAdaptorsBase.hpp)
4. Register the RPC method binding in RpcLibServerBase.hpp (AirLib/include/api/RpcLibServerBase.hpp)
5. Add corresponding client stub in RpcLibClientBase.hpp for remote calls (AirLib/include/api/RpcLibClientBase.hpp)

Add a New Safety Constraint

1. Create a new geofence class inheriting from IGeoFence.hpp or extend existing (CubeGeoFence, SphereGeoFence) (AirLib/include/safety/IGeoFence.hpp)
2. Implement isInBounds() to define the constraint boundary (AirLib/include/safety/CubeGeoFence.hpp)
3. Register your geofence in SafetyEval.hpp evaluation logic (AirLib/include/safety/SafetyEval.hpp)
4. Add geofence configuration schema to AirSimSettings.hpp (AirLib/include/common/AirSimSettings.hpp)

• C++ with header-only abstractions — Low-latency physics simulation and real-time sensor updates require compiled performance; header-only enables cross-platform plugin architecture.
• RPC over network (RpcLib) — Clients can connect from Python, C#, C++ on local/remote machines; decouples simulation engine from control code.
• Unreal Engine / Unity as rendering backend — High-fidelity photorealistic rendering for computer vision tasks; built-in physics integration (PhysX) and cross-platform deployment.
• undefined — undefined

Unreal Engine version pinning: the simulator requires a specific UE4.x version (check build.cmd or CMakeLists.txt for exact version); using a different version will cause linker errors. RPC endpoint must match between simulator and Python client (default 127.0.0.1:41451, configurable in settings.json but easy to misconfigure). settings.json in the Unreal project root is required at runtime and will silently fall back to defaults if missing—missing drone/vehicle definitions here will cause crashes. ClockBase/SteppableClock abstractions mean wall-clock time may not match simulation time; code using 'real time' for simulation ticks will diverge from expected physics. The build.cmd script regenerates Visual Studio project files; manual edits to .vcxproj files are overwritten on rebuild.

• Software-in-the-Loop (SITL) — AirSim's primary mode for testing real flight controller firmware (PX4, ArduPilot) without hardware; understanding SITL is essential to validate that your code will run on actual drones
• Remote Procedure Call (RPC) with RpcLib — AirSim communicates with Python clients and external systems via RPC protocol; understanding the RpcLibServerBase/RpcLibClientBase architecture is critical for building custom integrations
• First-Order Filter (FirstOrderFilter.hpp) — Used throughout AirSim for sensor noise modeling and motor control smoothing; essential to understand for tuning realistic sensor fidelity in physics simulation
• PID Control (PidController.hpp) — Core control primitive for vehicle stabilization and trajectory following; understanding PID tuning directly impacts how well your autonomous algorithms behave in simulation
• Quaternion-based Attitude Representation — AirSim (via VectorMath.hpp) uses quaternions instead of Euler angles for drone orientation to avoid gimbal lock; critical for understanding rotation matrices in physics updates
• Gaussian-Markov Process Noise Model (GaussianMarkov.hpp) — Simulates realistic sensor drift and noise that correlates over time, not just white noise; required for high-fidelity IMU and GPS simulation that matches real-world characteristics
• Steppable Clock abstraction (SteppableClock.hpp, ScalableClock.hpp) — AirSim decouples simulation time from wall-clock time, allowing time-scaled or frame-stepped simulation; critical gotcha for algorithms that depend on wall-clock timing

• iamaisim/ProjectAirSim — Direct successor to this repository; Microsoft's next-generation autonomous vehicle simulator with improved aerial mobility focus and commercial support
• PX4/PX4-Autopilot — Industry-standard open-source flight controller that AirSim integrates via software-in-the-loop; required for testing real autopilot firmware in simulation
• ArduPilot/ardupilot — Alternative open-source autopilot supported by AirSim's hardware-in-loop and SITL modes; critical for multi-vehicle autonomy development
• gazebosim/gz-sim — Competing robotics simulator with similar ROS integration and physics fidelity; alternative choice for users requiring ROS-native workflows
• carla-simulator/carla — Unreal-based autonomous driving simulator focused on ground vehicles rather than drones; shares similar plugin architecture and RPC API patterns

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add unit tests for AirLib/include/common/common_utils utility classes

The repo has extensive utility classes (Timer.hpp, RandomGenerator.hpp, MedianFilter.hpp, OnlineStats.hpp, etc.) but no visible test coverage in the file structure. These are core utilities used throughout AirSim and testing them would improve code reliability and make the codebase more maintainable for contributors.

• [ ] Create AirLib/test/unit/common_utils/ directory structure
• [ ] Write unit tests for Timer.hpp, RandomGenerator.hpp, and MedianFilter.hpp (highest impact utilities)
• [ ] Add test CMakeLists.txt or build configuration to compile tests
• [ ] Verify tests pass on Windows, Ubuntu, and macOS (aligning with existing .github/workflows/test_*.yml)

Add Python API integration tests in .github/workflows

The repo has test workflows for macOS, Ubuntu, and Windows but no dedicated Python client API testing workflow. Given AirSim's heavy Python usage in autonomous vehicle research, a workflow that tests the RpcLibClientBase.hpp implementations against Python bindings would catch regressions early and improve API stability.

• [ ] Create .github/workflows/test_python_api.yml workflow file
• [ ] Add test cases that exercise ApiProvider.hpp and RpcLibClientBase.hpp through Python client code
• [ ] Run on at least Ubuntu (fastest CI) to validate vehicle control APIs, sensor APIs, and state queries
• [ ] Document test execution in CONTRIBUTING.md or similar

Organize and document sensor API classes with missing header documentation

The AirLib/include/api/ directory contains core interfaces (VehicleApiBase.hpp, VehicleSimApiBase.hpp, WorldSimApiBase.hpp) but lacks inline documentation for sensor-related methods. Given this is a research simulator where sensor configuration is critical, adding comprehensive Doxygen/code comments would lower contributor friction and reduce API misuse.

• [ ] Audit VehicleApiBase.hpp and VehicleSimApiBase.hpp for undocumented sensor methods (cameras, IMU, GPS, lidar parameters)
• [ ] Add detailed Doxygen comments including parameter descriptions, return values, and usage examples for each sensor API
• [ ] Create a docs/sensor_api_guide.md explaining sensor calibration and output formats with code examples
• [ ] Run Doxygen locally to verify documentation builds without warnings

• Write integration tests for AirLib/include/common/GeodeticConverter.hpp—currently no tests visible in the file list for the GPS coordinate transformation logic, which is critical for real-world simulation validation
• Add missing docstrings to AirLib/include/api/VehicleSimApiBase.hpp and RpcLibAdaptorsBase.hpp explaining which methods block and which are async, since Python users frequently hit timeouts due to this ambiguity
• Implement example scripts in examples/ demonstrating StateReporter usage (AirLib/include/common/StateReporter.hpp) for logging vehicle telemetry—currently no clear Python example exists for this sensor data export pattern

• Medium · Use of Third-Party JSON Library Without Version Pinning — AirLib/include/common/common_utils/json.hpp. The codebase includes 'json.hpp' (likely nlohmann/json) in AirLib/include/common/common_utils/json.hpp. Without examining package management files, it's unclear if dependency versions are pinned, which could lead to unexpected behavior from library updates or known vulnerabilities in older versions. Fix: Ensure all dependencies are pinned to specific versions in package management files (CMakeLists.txt, vcpkg.json, etc.). Regularly audit and update dependencies to patch security vulnerabilities.
• Medium · Potential Memory Safety Issues in C++ Codebase — AirLib/include/api/ and AirLib/include/physics/. The codebase is written in C++ and includes physics engines, socket-based RPC communication (ApiServerBase, RpcLibServerBase), and real-time data processing. C++ is inherently prone to memory safety vulnerabilities (buffer overflows, use-after-free, etc.) if not carefully managed. Fix: Implement comprehensive static analysis using tools like clang-static-analyzer or cppcheck. Use modern C++ features (smart pointers, RAII). Conduct regular security-focused code reviews. Consider using AddressSanitizer and MemorySanitizer during testing.
• Medium · RPC API Exposure Without Apparent Authentication — AirLib/include/api/RpcLibServerBase.hpp, AirLib/include/api/RpcLibClientBase.hpp, AirLib/include/api/ApiServerBase.hpp. The presence of RpcLibServerBase, RpcLibClientBase, and ApiServerBase indicates network-exposed RPC/API interfaces. No apparent authentication or authorization mechanisms are visible in the provided file structure, which could allow unauthorized access to control autonomous vehicles. Fix: Implement strong authentication (OAuth2, API keys with rate limiting, mutual TLS). Add authorization checks. Validate and sanitize all RPC inputs. Implement request signing. Use transport-level encryption (TLS 1.2+).
• Medium · Geodetic Conversion Functionality May Have Precision/Security Implications — AirLib/include/common/GeodeticConverter.hpp, AirLib/include/common/EarthUtils.hpp. GeodeticConverter and EarthUtils handle geolocation data conversion. Improper handling could lead to GPS spoofing vulnerabilities or precision loss that could be exploited in autonomous vehicle control systems. Fix: Implement strict input validation on coordinate data. Add bounds checking. Use high-precision data types. Implement integrity checks for GPS/location data. Consider cryptographic signing of location updates.
• Low · Potential Information Disclosure via LogFileWriter — AirLib/include/common/LogFileWriter.hpp. LogFileWriter functionality is included. If logs contain sensitive data (control commands, sensor data, network traffic), inadequate file permissions or log retention could expose sensitive information. Fix: Implement secure logging practices: restrict file permissions (0600), sanitize sensitive data before logging, implement log rotation and secure deletion, avoid logging credentials or unencrypted sensor payloads.
• Low · Threading and Concurrency Vulnerability Potential — AirLib/include/common/WorkerThread.hpp, AirLib/include/common/common_utils/AsyncTasker.hpp, AirLib/include/common/common_utils/ScheduledExecutor.hpp. Multiple threading utilities present (WorkerThread, AsyncTasker, ScheduledExecutor) without visible synchronization documentation. Race conditions could lead to inconsistent vehicle state or command injection. Fix: Document all shared state access patterns. Use thread-safe primitives (mutexes, atomic variables). Implement comprehensive thread-safety analysis. Use tools like ThreadSanitizer during testing. Avoid lock-free programming unless absolutely necessary.
• Low · Missing Security Headers in GitHub Configuration — .github/ directory. While workflow files are present (.github/workflows/), there's no visible CODEOWNERS file or branch protection rules documented in the provided structure, which could allow unauthorized code modifications. Fix: Create a CODEOWNERS file restricting code review approval authority. Enable branch protection requiring code reviews. Implement signed commits. Set up automated security scanning in CI/CD pipeline.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.