Skip to content

Middleware Compatibility Reference / Rev. 2025.03

Adasens sensor stacks drop into your existing ROS 2 and AUTOSAR environments — without middleware rewrites.

The matrix below enumerates every ROS 2 distribution and AUTOSAR version verified against in-house reference hardware in Boulder, Colorado and Stuttgart, Germany. Signed compatibility reports ship with every production kit.

Document type
Middleware compatibility matrix
Reference hardware
Boulder, CO · Stuttgart, DE
Last verified
Q1 2025
Four-modality Adasens sensor stack prototype on a lab bench.
Fig. 01 — Reference sensor stack, Boulder integration lab.
  • Supported platforms 19/ ROS 2 + AUTOSAR Humble → Kilted · Classic 4.2 → R22-11
  • Middleware rewrites 0/ REQUIRED Message-passing shims only
  • Avg. integration time 14/ WK TO PROD vs. 11-mo industry baseline
  • Sensor-fusion latency −68/ % VS. 2023 Verified across 240+ deployed units, 2024

§ 02 / Supported middleware versions

Supported middleware versions

Every row below is verified against in-house reference hardware in Boulder and Stuttgart and ships with a signed compatibility report on request. Badges indicate in-house test coverage at the noted revision.

01

ROS 2 distributions

5 distros · LTS + interim
  • Humble Hawksbill LTS · Ubuntu 22.04 · EOL May 2027
    VERIFIED
  • Iron Irwini Non-LTS · Ubuntu 22.04 · EOL Nov 2024
    VERIFIED
  • Jazzy Jalisco LTS · Ubuntu 24.04 · EOL May 2029
    VERIFIED
  • Kilted Kaiju Non-LTS · Ubuntu 24.04 · EOL Nov 2026
    VERIFIED
  • Rolling Ridley Development · rolling tag · best-effort
    BETA
Driver packages adasens_ros2_driver v3.2.1
02

AUTOSAR versions

6 releases · Classic + Adaptive
  • Classic 4.2 Reference impl · OSEK / OS
    VERIFIED
  • Classic 4.4 Multi-core · secure onboard comm
    VERIFIED
  • Classic 4.6 Current production target
    VERIFIED
  • R20-11 Adaptive platform · ara::com
    VERIFIED
  • R21-11 Adaptive · manifest v2.1
    VERIFIED
  • R22-11 Latest adaptive · phased roll-out
    BETA
BSW modules adasens_bsw_if v2.8.0 · AR4.6

§ 03 / Integration philosophy

How integration actually works.

Every Adasens sensor kit ships as a complete working artifact tree: reference sensor driver packages, deterministic launch files, calibrated URDFs, and signed firmware images keyed to the host ECU's secure boot chain. You drop the package into your existing workspace, point your middleware at the message-passing shim, and the perception pipeline starts publishing.

There is no proprietary bus, no replacement scheduler, no fork of the ROS 2 or AUTOSAR kernel. Latency budgets are documented per modality — currently 4.1 ms p99 for LiDAR, 2.7 ms p99 for mmWave, 5.8 ms p99 for ToF — and verified on each commit against the Boulder and Stuttgart reference racks before a signed firmware image is cut. Firmware artifacts carry an Ed25519 signature anchored to Adasens' public root, so your secure boot loader can refuse tampered images at boot.

  • Reference driver tree, deterministic launch files, calibrated URDFs
  • Signed firmware images with Ed25519 chain-of-trust
  • Documented per-modality latency budgets, p99 verified per commit
  • Compatibility report co-signed by Boulder and Stuttgart engineering

§ 04 / Next step

Map your middleware stack to a sensor configuration.

Book a 30-minute technical consultation with an Adasens solutions engineer. Bring your ROS 2 / AUTOSAR version, your ECU's power envelope, and your target perception latency — we'll return a signed compatibility report and a proposed sensor configuration, on the call, for your specific stack.

Typical response
within 1 business day
Engineer on call
Boulder / Stuttgart
Deliverable
signed compatibility report