§ Drones & UAVs
Perception and flight control, both on the airframe.
Onboard detection on the NPU and a real-time control loop on the same module — no cloud round-trip, no separate companion computer.
§ Why edge AI
The case for running it on the asset.
Most drones still fly two computers: a flight controller and an AI companion board, joined by a serial link. E1M puts both jobs on one module. On the E1M-X V2N-M1, Linux on the quad Cortex-A55 runs camera capture and detection across the on-die DRP-AI3 and the DEEPX DX-M1 (29 TOPS combined), with the on-SoC Cortex-M33 (200 MHz) free for deterministic work. For small airframes, E1M-AEN pairs a 400 MHz Cortex-M55 control core with Ethos-U inference on one low-power module — that is where the SDK’s flight-control reference runs today. The E1M-X V2H-M1, in development, adds Cortex-R8 real-time cores on the same pads.
§ The constraint
No cellular coverage at 400 m AGL. No cloud round-trip budget when the drone is 200 ms from a power line. AI runs on the airframe or it doesn't run.
Cloud round trip
sensor → uplink → inference → downlink → action
On-module
sensor → on-module inference → action
Sensor
Onboard camera feed
On-module inference
E1M-X V2N-M1
Action
Flight decision on the airframe
01 · Capture
Cameras on 2× 4-lane MIPI CSI-2 into the Linux camera pipeline on the A55 cluster.
02 · Infer
Detection on DRP-AI3 or the DX-M1 through <alp/inference.h> — the model format picks the NPU.
03 · Decide
Mission logic on Linux; the result goes to the control core over the on-module link.
04 · Act
Attitude and motor loop on a real-time core (Cortex-M55 on AEN, Cortex-R8 on V2H-M1).
§ Where it fits
What teams build with it.
01
Inspection drones
Power-line, pipeline and roof inspection where detection has to run on the airframe because the link is the first thing to drop.
02
Detect-and-avoid
Camera-based obstacle detection feeding the flight controller on the same module, without a separate companion computer.
03
Operator HUD
Telemetry and inference overlays rendered on the ground or on the airframe display, from the same SDK the flight code uses.
04
Small airframes
E1M-AEN for weight- and power-limited airframes: Cortex-M55 control loop plus Ethos-U inference in one module.
§ Recommended modules
Pick the AI compute that fits.
E1M-X V2N-M1
Vision-heavy airframes: detection across DRP-AI3 and the DX-M1, Linux for mission logic.
- CPU
- Quad Cortex-A55 @ 1.8 GHz
- NPU
- DRP-AI3 4 TOPS + DeepX DX-M1 25 TOPS
- Temp
- −40 °C to +85 °C
Full specs →
E1M-AEN
Small, power-limited airframes: Cortex-M55 control loop plus Ethos-U inference. Runs the SDK autopilot reference.
- CPU
- 0 / 1 / 2× Arm Cortex-A32 @ 800 MHz (per SoC: E3/E4 none, E5/E6 single, E7/E8 dual)
- NPU
- 2× Arm Ethos-U55; E4/E6/E8 add 1× Arm Ethos-U85 (250 GOPS · E3/E5/E7, 454 GOPS · E4/E6/E8)
- Temp
- −40 °C to +75 °C
Full specs →
E1M-X V2H-M1
Same pads, adds Cortex-R8 real-time cores and 33 TOPS. In development.
- CPU
- Quad Cortex-A55 + 2× Cortex-R8 @ 800 MHz
- NPU
- 33 TOPS dense (8 DRP-AI3 + 25 DX-M1)
- Temp
- −40 °C to +85 °C
Learn more →
§ Inside the E1M-X V2N-M1
The module this vertical leads with.
- CPU
- Quad Cortex-A55 @ 1.8 GHz
- MCU (SoC)
- Cortex-M33 @ 200 MHz
- MCU (I/O)
- Cortex-M33 @ 216 MHz — standalone, not in the SoC
- NPU
- DRP-AI3 4 TOPS + DeepX DX-M1 25 TOPS
- RAM
- up to 8 GB LPDDR4X
- ROM
- up to 16 GB eMMC
- MIPI CSI-2
- 2× 4-lane; up to 8 cameras via MIPI virtual channels (4 per port) with an aggregator / deserializer on the carrier
- MIPI DSI
- 1× (display out)
- Ethernet
- 2× 1 GbE
- USB
- USB 3.2 + USB 2.0
- PCIe
- Gen3 x2, multiplexed between the on-module DX-M1 (default) and the carrier PCIE0 pads
- CAN-FD
- 2 channels
- Connectivity
- 2.4 / 5 / 6 GHz Wi-Fi (802.11 a/b/g/n/ac/ax, 143 Mbps) + Bluetooth 5.4 (BR/EDR/LE, 3 Mbps)
§ Reference examples from the Alp SDK
Code you can fork, with its evidence on the label.
Every example is real C/C++ in the open-source alp-sdk repo. Clone it, change the SKU in board.yaml, build. Each card says how far it has been proven (on silicon, partly, or not yet on hardware) as recorded in the example's own README and the SDK's verification ledger.
4 Not yet on hardware
drone-autopilot
Not yet on hardwareDrone autopilot
Flight-control loop on the E1M-AEN801 Cortex-M55 HP core (1 kHz), with AHRS and PID on the portable SDK surfaces.
E1M-AEN801 · Do not fly this build: PID gains, sensor scales and failsafe thresholds are starting values that need bench tuning and ground-tied throttle tests.
View on GitHub ↗
ai-object-detection-realtime
Not yet on hardwareReal-time object detection
Portable YOLOv8-tiny skeleton: camera frames in through <alp/camera.h>, inference through <alp/inference.h>, bounding boxes and an FPS counter out through <alp/display.h>.
E1M-V2M101 · Skeleton today: the checked-in M33 slice runs TFLM on the CPU. A DX-M1 run needs an A55/Yocto app, a compiled YOLOv8-tiny model and V2N-M1 hardware validation.
View on GitHub ↗
v2n-two-models
Not yet on hardwareDetection + a second model
Run two models at once — one on the DRP-AI3, one on the DX-M1 — each in its own thread, with per-NPU latency and combined FPS.
E1M-V2M103 · Each NPU has run alone on silicon; the two have not yet run together, and this app has not yet run on an E1M-V2M.
View on GitHub ↗
drone-hud
Not yet on hardwareDrone HUD
Operator heads-up display: live telemetry and inference overlays rendered with LVGL.
E1M-AEN801 · Builds on native_sim; not yet run on hardware.
View on GitHub ↗
Portable SDK headers for this vertical
These are the SDK's portable surfaces across E1M families; what each family supports underneath them is on the SDK page.
§ Getting started
From example to your board.
- 01First, scaffold a project from the reference example:
tan init --from-example peripheral-io/drone-autopilot - 02Then set
som.skuin board.yaml to your module (the example ships targetingE1M-AEN801). - 03Build with the
tanCLI or the Alp IDE extension for VS Code, and run it on an E1M EVK. - 04Before relying on a result, read the status block at the top of the example README — it says what has run on hardware and what has not.
§ Proven today, and what is ahead
Today the drone examples build and run on native_sim but have not flown: the autopilot gains are starting values, and the detection example is a skeleton until its DX-M1 path is validated on V2N-M1 hardware. DRP-AI3 has run a detector on silicon. The DX-M1 has run one during bring-up but has no verified entry in the SDK ledger yet. Running both NPUs together, and the V2H-M1 with Cortex-R8, are still ahead.
SDK verification ledger ↗§ Built for this vertical
Why E1M wins here.
- →
Cortex-R8 hard-real-time cores for the flight loop on V2H / V2H-M1 (in development)
- →
2× 4-lane MIPI CSI-2 — up to 8 cameras for stereo and 360° vision, via MIPI virtual channels (4 per port) with an aggregator / deserializer on the carrier
- →
Wi-Fi 6 + Bluetooth 5.4 telemetry, USB 3.2 to ground station
- →
IP67-ready when paired with a sealed carrier board