AirSim

AirSim includes a built-in flight controller called simple_flight which is used by default. It is a dependency-free, header-only C++11 library designed to work both in simulation and on real hardware.

Key Features:

• Zero Setup: It works out of the box without additional configuration.
• Steppable Clock: By default, it uses a clock that advances with the simulator, allowing for consistent behavior even when the simulation is paused (e.g., during debugging).
• Control Modes: It supports control via angle rate, angle level, velocity, or position through a cascaded PID controller architecture (Position $\rightarrow$ Velocity $\rightarrow$ Angle Level $\rightarrow$ Angle Rate).
• State Estimation: Currently uses simulator ground truth for state estimation.

In Computer Vision mode, AirSim functions without vehicle physics or active vehicles. This mode is designed for scene analysis and camera calibration.

Capabilities:

• Move around the scene using the keyboard.
• Use APIs to position cameras at arbitrary poses.
• Collect various sensor data including depth, disparity, surface normals, and object segmentation.

For detailed API usage regarding image data, see the image APIs documentation.

External cameras are fixed cameras (like a CCTV) that do not move with vehicles. They are defined in the ExternalCameras element.

• The key in the JSON object is the name of the camera.
• The value contains the settings (same as CameraDefaults).

To interact with these cameras via the API (e.g., capturing images or changing pose), you must pass the parameter external=True in the API call.

"ExternalCameras": {
  "CCTV_01": {
    "CameraDefaults": {
      "CaptureSettings": [
        { "ImageType": 0, "Width": 1280, "Height": 720 }
      ]
    }
  }
}

AirSim on Linux uses the following toolchain:

• Compiler: Clang 8 (the same as Unreal Engine)
• Stdlib: libc++
• CMake: Version 3.10.0 or higher.

Note: AirSim's setup.sh script automatically downloads Clang 8, libc++, and CMake if they are missing or outdated.

AirSim follows a layered architecture that separates platform-independent logic from simulator-specific implementations:

1. Client Layer: External code (Python, C++, C#) that interacts with the simulator via RPC (Remote Procedure Call) APIs.
2. AirLib (Core): A platform-independent C++ library that handles the modeling of API calls, vehicles, sensors, physics, settings, and data structures.
3. Unreal Plugin (Frontend): The Unreal Engine implementation that adapts the core logic to Unreal actors, pawns, cameras, rendering, weather, and world objects.
4. Vehicle Implementations: Connects the shared API surface to specific flight/drive controllers like multirotors, cars, Computer Vision mode, PX4, or ArduPilot.

The Flight Controller acts as the bridge between high-level commands and low-level physics.

1. Input: The Flight Controller receives a desired state (e.g., specific roll, pitch, or yaw for a quadrotor).
2. Estimation: It uses simulated sensor data (gyroscope, accelerometer) to estimate the actual state.
3. Actuation: It generates motor signals to drive actuators to minimize the error between desired and actual states.
4. Simulation Loop: The AirSim Simulator consumes these motor signals to calculate force and thrust, which the physics engine uses to update the vehicle's kinetic properties. This update generates new simulated sensor data, which is fed back to the Flight Controller.

Infrared

Infrared images are currently a grayscale map of object IDs. A mesh with object ID 42 will appear as color (42, 42, 42). You can control the segmentation IDs to change how objects appear in this mode.

Optical Flow

• OpticalFlow: Returns a 2-channel image where channel 0 is vx and channel 1 is vy.
• OpticalFlowVis: A visual RGB representation of the motion data.

The PhysicsEngineName setting controls how physics are calculated for vehicles. While cars currently only support PhysX, multirotors support two modes:

• FastPhysicsEngine: The standard high-performance physics mode.
• ExternalPhysicsEngine: Allows the drone to be controlled via setVehiclePose(). This mode keeps the drone in place until the next pose command is received, making it ideal for using an external simulator or following a pre-recorded path.