
§ Robotics
See, learn, move — on one SoM.
ROS 2 perception on the NPU, real-time motion control on the Cortex-M33, RPMsg between them on the same die.
§ Why edge AI
The case for running it on the asset.
Robots have always lived in two minds: a real-time controller for joints and motion, and a Linux computer for perception. The E1M-X V2N-M1 puts both on one module: Yocto Linux and ROS 2 on the quad Cortex-A55, Zephyr on the Cortex-M33, and RPMsg between them in shared memory — no fieldbus hop between seeing and moving. Perception gets 29 TOPS across the on-die DRP-AI3 and the DEEPX DX-M1; the plain E1M-X V2N runs the same split on DRP-AI3 alone. The E1M-X V2H-M1, in development, is the upgrade on the same pads, adding Cortex-R8 real-time cores and 33 TOPS. One firmware project, one pinout, one SDK.
§ The constraint
Latency-sensitive perception (collision avoidance, manipulation) can't round-trip to a cloud. Determinism matters: motors don't care about your 99th percentile.
Cloud round trip
sensor → uplink → inference → downlink → action
On-module
sensor → on-module inference → action
Sensor
Camera and sensor input
On-module inference
E1M-X V2N-M1
Action
Motion command to actuators
01 · Sense
Cameras on MIPI CSI-2 plus IMU and power telemetry, published as ROS 2 topics on the A55.
02 · Perceive
Detection on the DX-M1, falling back to DRP-AI3 on a plain V2N — same source, swap som.sku.
03 · Hand off
Commands cross to the Cortex-M33 over RPMsg in shared memory, or as ROS 2 topics via micro-ROS.
04 · Move
Zephyr on the M33 runs the motion loop toward the actuators; CAN FD and PWM are on the module.
§ Where it fits
What teams build with it.
01
Mobile robots and AMRs
ROS 2 perception on the A55 + NPU, wheel and safety control on the M33 — one module instead of a PC plus a motor controller.
02
Pick-and-place cells
Vision-guided manipulation where detection and the motion loop share memory over RPMsg instead of a fieldbus hop.
03
micro-ROS actuators
micro-ROS on the real-time core, so joints and sensors appear as ordinary ROS 2 topics. The M33 side boots on silicon; the topic round-trip is still being proven.
04
Two-model perception
Detection on one NPU and a second model (tracking, segmentation, pose) on the other, without sharing a single accelerator.
§ Recommended modules
Pick the AI compute that fits.

E1M-X V2N-M1
Perception-heavy robots: 29 TOPS across two NPUs, ROS 2 on Linux, control on the M33.
- 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-X V2N
Lighter perception on DRP-AI3 with the same dual-OS split and the same pinout.
- CPU
- Quad Cortex-A55 @ 1.8 GHz
- NPU
- DRP-AI3 4 TOPS (dense), 15 TOPS (sparse)
- Temp
- −40 °C to +85 °C
Full specs →

E1M-X V2H-M1
Adds Cortex-R8 real-time cores and 33 TOPS on the same pads. 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.
1 Run on silicon · 1 Partly on silicon · 3 Not yet on hardware
v2n-m1-ros-perception
Not yet on hardwareROS 2 perception node
ROS 2 node publishing IMU, power, image and detection topics. Detection targets the DX-M1 and falls back to DRP-AI3 on a plain V2N — same source, swap som.sku.
E1M-V2M101 · Builds against a Yocto SDK with ROS 2; hardware bring-up is still gated. The DEEPX DX-M1 path has no silicon-verified row in the SDK ledger yet.
View on GitHub ↗
microros-ros2-v2n
Partly on siliconmicro-ROS on the Cortex-M33
A micro-ROS node on the M33 (Zephyr) publishes to ROS 2 on the A55 (Yocto) through a custom XRCE-DDS transport over RPMsg, with an unmodified micro-ROS agent.
E1M-V2N101 · The M33 image booted on an E1M-V2M103 (2026-10-07) and published its resource table; a ROS 2 topic round-trip with a micro-ROS agent is not yet proven.
View on GitHub ↗
rpmsg-v2n
Run on siliconA55 ↔ M33 RPMsg link
Yocto Linux on the Cortex-A55 cluster and Zephyr on the Cortex-M33 of the same RZ/V2N, talking over OpenAMP RPMsg.
E1M-V2N101 · The raw A55 ↔ M33 transport is bench-proven on E1M-X V2N-M1 silicon: attach and echo round-trips (1/4/16/64 B) pass end to end.
View on GitHub ↗
v2n-two-models
Not yet on hardwareTwo models, two NPUs
One model on the on-die DRP-AI3 and one on the DEEPX 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 ↗
heterogeneous-offload
Not yet on hardwareYocto + Zephyr compute offload
Linux on the A55 delegates a 1024-point FFT to Zephyr on the M33 over RPMsg and reads back the spectrum — both halves from one board.yaml.
E1M-V2N101 · Builds against the V2N memory map; hardware bring-up not yet run.
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 multicore/rpmsg-v2n - 02Then set
som.skuin board.yaml to your module (the example ships targetingE1M-V2N101). - 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
Proven on silicon today: the A55 ↔ M33 RPMsg transport on V2N-M1 hardware, and a DRP-AI3 detector through <alp/inference.h>. Still ahead: the micro-ROS topic round-trip, the full ROS 2 perception node on hardware, and a verified DX-M1 entry in the SDK ledger.
SDK verification ledger ↗§ Built for this vertical
Why E1M wins here.
- →
Deterministic dual-OS architecture (Yocto + Zephyr) on a single module
- →
Up to 8 cameras on 2× 4-lane MIPI CSI-2, via MIPI virtual channels (4 per port) with an aggregator / deserializer on the carrier
- →
CAN FD for industrial actuator buses, 2× 1 Gbps Ethernet
- →
DRP-AI3 + DX-M1 = 29 TOPS dense for ROS 2 perception on V2N-M1 (33 TOPS on V2H-M1, in development)