Recent Topics

MotionLabA Computer Vision Biomechanics Prototype powered by Voyager Wingman and Axelera MetisHello Spanner, hello Axelera Team!It is great to be back and to take part in another community challenge.First of all, thank you for organizing this new initiative.Due to our ongoing internal projects, we have not yet had the opportunity to work with Voyager Wingman. That is exactly why we see this challenge as the perfect opportunity to start using it on a real-world AI project and explore its capabilities.Our proposal is called MotionLab.The goal is to develop a first working prototype of a computer vision biomechanics system for sports training, athletic performance and rehabilitation.Rather than trying to build a complete commercial product within one month, we want to demonstrate how Voyager Wingman can rapidly accelerate the creation of a practical AI pipeline running on Axelera Metis.Our demonstration will focus on a simple but meaningful use case.A camera will observe an athlete perfor

Project WildGuard Protecting remote critical infrastructure, whether guarding a perimeter, securing electrical substations, or monitoring endangered wildlife reserves, requires continuous surveillance in environments with zero cloud connectivity and strict solar/battery power budgets. Project WildGuard is a fully autonomous, off-grid ambient intelligence platform. It processes up to 8 live streams of camera feeds simultaneously using edge-native vision models on the Metis hardware.Instead of straining weak satellite or radio networks by attemting to stream heavy video frames, an integrated local Small Language Model translates visual threat detection data into compressed, conversational text summaries. A ranger or tactical officer miles away can query the system over a low-bandwidth LoRA mesh network via text, receiving instant, intelligent situational updates entirely offline. Technical Architecture This project maximizes the Metis PCIe card inference power, keeping the power draw env

Project Proposal for The Prompt ChallengeI am a disabled independent researcher developing a local humanities knowledge architecture called the ∑-engine.Handling books, repeatedly rescanning pages, and correcting poor captures can be physically exhausting or sometimes impossible. Existing book scanners can capture an image, but they do not reliably determine whether a page is stable, properly illuminated, unobstructed, correctly framed, or ready for further scholarly processing.My proposed project, Edge Scriptorium, adds a privacy-first edge-AI capture and document-structuring layer to overhead book-scanning systems. It is designed for ancient texts, books, facsimiles, scholarly editions, annotated pages, and other complex page layouts.The Missing Layer Before OCREdge Scriptorium is not intended to solve OCR itself.Instead, it addresses the difficult capture-and-structure stage that comes first:detecting a page, open book, facsimile, or document; identifying page boundaries and relevan

Did you know that wingman learns from your preferences and projects?   What’s your favourite feature?  

Hi, I have a custom U-Net model with MobileNetV2 encoder running on the Axelera portenta with voyager v1.4.0. I’ve based my code for inference on the axruntime python example in the Voyager github repository, with the model being compiled by the Voyager compiler. When running inference the maximum utilization of the Metis, as shown by axmonitor, only reaches 6% on all four cores. I have tried running it with all pre-processing and post-processing commented out and a dummy input consisting of all zeroes, but utilization also did not surpass 6%. I’m wondering whether this utilization limit might be caused by the way the model is compiled, perhaps due to needing multiple iterations in the LowerTIR stage, and whether there might be more optimal compiler configs to achieve a higher utilization. I have included some logging / debug files the CLI compiler generated for an older version of my model. For my current model I’m using the API compiler but it does not generate these files, the only

I recently acquired a Metis M.2 module and was so excited to get started with it. To my horror, I installed it into a standard, modern x86 mini PC (with power disconnected, all by the books), and the system was bricked upon my first attempt to boot. At first, I thought maybe the M.2 slot on the system was not providing adequate power for the device, and to the benefit of the Metis, I decided to try another host system. HUGE mistake. The same thing happened with a LattePanda x86 SBC, confirmed to have enough power to the M-key M.2 slot. These systems are not cheap, so to say I am disappointed is an incredible understatement.  Maybe I’m just not understanding where to look for host system specs, but it doesn’t seem like this issue is warned against anywhere in your docs or on the community page here. Has anyone else had this problem? I’m down two systems, so if someone could please tell me with certainty which system I CAN reliably plug this thing into, I would be very appreciative. EDIT

We currently run the Voyager SDK + Metis AIPU on a custom Yocto image (Scarthgap 5.0.18) on x86_64 (Ryzen 5 8500G / B650M). We're migrating the base OS to Ubuntu/Debian for hardware-agnostic driver support, and want to confirm a few things before starting:Is there an officially supported/tested Ubuntu or Debian version (and kernel version range) for the Metis driver + Voyager SDK on x86_64? Do you provide a .deb package or install script for the Metis kernel driver, or does it require a manual out-of-tree module build (e.g., via dkms)? Are there any known kernel version constraints or incompatibilities (e.g., minimum/maximum kernel version, specific config options required) we should account for when picking a distro kernel package? Any existing documentation or community reference for deploying the Metis driver outside of a Yocto-based image?

Voyager v1.7 landed and, past the usual new-models-and-hardware stuff, there are a few things that change what you can actually build on Metis that I thought it was worth us all taking two minutes to look at.The one that caught my eye right away is that re-identification is now a first-class task type. ReID is what lets you say "that's the same person who walked past the front camera two minutes ago," rather than treating every camera and every frame as a fresh unknown. If you've built a Home Assistant camera notifier and ended up hand-rolling logic to (try and) stop it pinging you about the same person fifteen times (which is something I’ve been battling with a lot personally), this is the release that lets you bin that code. There's a new tracking_with_classification.py demo that chains detection to tracking to per-track classification, which is basically the skeleton of a solid smart-security pipeline. Very cool.Depth estimation from a single camera is in there too, with a FastDepth

SummaryOn a Metis dev system, ./deploy.py <model> fails at the compile step: it exits with RC=1 and writes nothing to stdout or stderr (captured 1>out.txt 2>err.txt → both empty), produces no log file, and no traceback. It reproduces on a trivial 27×30 model, so it is not model‑size related. The one time the compiler did emit an error (earlier run, attached earlier_pkl_memoize_PermissionError.md) it was a TVM .pkl_memoize_py3 PermissionError, which makes me suspect the current silent failure is the same TVM‑cache / working‑directory‑writability problem, now swallowed.EnvironmentHardware: Metis dev system — Portenta X8 on the board, host access via a Raspberry Pi acting as an adb relay over USB. SDK: Voyager container voyager-sdk-1.4.0, SDK at /home/ubuntu/voyager-sdk, venv /home/ubuntu/.cache/axelera/venvs/b4c581dc (Python 3.10, TVM backend). from axelera import compiler, runtime imports successfully (prints OK).What I'm deployingA single 1×1 Conv2d exported to ONNX (it imp

As the title suggests, I want to factory reset the board so that I can reinstall and setup the board from a clean state? How can I do it?

class FrameResult:image: Optional[types.Image] = Nonetensor: Optional[np.ndarray] = Nonemeta: Optional[AxMeta] = Nonestream_id: int = 0src_timestamp: int = 0sink_timestamp: int = 0render_timestamp: int = 0Could you explain when exactly these 3 timestamps are stamped? Our use case is we are trying to sync some telemetry samples with the exact moment the camera has recorded the frame. So it would be helpful to know what events trigger these timestamps.Thank you,

Will this ever be made available? I am interested in the 16gb version.   

Hi everyone — I'm Lorenco, a Rust/C++ compiler & real-time/kernel systems engineer (based in Italy), getting to know the Metis/Voyager stack.While reading axelera-driver I came across GitHub issue #4 — the use-after-free in axl_aipu_remove() on `modprobe -r metis`. It looks correctly root-caused: the MSI handlers dereference dma_va, but the devm-managed IRQs are only released after remove() returns, so a late MSI hits the freed DMA buffer (synchronize_irq() alone doesn't mask the vector). Quiescing DMA/MSI before the free would also unblock a clean S3 suspend path.Two questions:1. Is the GitHub repo the right place to send driver patches, or do you handle those through another channel?2. More broadly — I do low-level compiler/runtime/driver work and would be glad to contribute. Where's the best spot for someone outside the team to pick things up?Background, in case useful: I recently contributed a canonicalization fix to Tenstorrent's tt-mlir compiler (github.com/tenstorrent/tt-mli

Hi,I'm trying to deploy a custom classification model on the Metis AIPU using the Voyager SDK. The model includes a CBAM attention block, but it fails during quantization with a topological sort error that points to a Gemm node.To verify that the issue wasn't in my model, I inspected the ONNX graph before quantization. The CBAM block contains only MatMul operations and no Gemm nodes. The only Gemm nodes in the model are in the final classifier head. Because of that, the Gemm mentioned in the error doesn't actually exist in the exported ONNX graph. It looks like the compiler is creating it internally during a MatMul to Gemm fusion pass, and somehow placing it before the node that produces one of its inputs.The graph pattern that seems to trigger this consists of two parallel MatMul branches that merge into a shared Add operation. As far as I know, this is a standard CBAM channel attention structure and not an unusual graph layout.Is this a known limitation of the compiler when handling

Hey everyone,I am evaluating the Metis lineup for an edge AI project and have a specific question about multi-card architecture that I haven't found a definitive answer to in the docs or SDK references.What I understand is supported today: The Voyager SDK detects multiple Metis cards in a single host. Each card runs its own independent inference pipeline. A real-world surveillance example shows three 4-chip PCIe cards running five primary models + one secondary model in parallel across 48 AIPU cores. My question: Is there any current or planned SDK support for splitting a single neural network across multiple Metis cards (e.g., layer sharding or tensor parallelism across two M.2 cards)? Or is the architecture strictly "one model must fit entirely within a single card's memory and AIPU"?Context for my use case: I am looking at a host with dual M.2 slots (e.g., Radxa Orion O6N) and weighing whether two standard Metis M.2 cards could act as a unified 2-GB / 428-TOPS accelerator for a

I received my Metis M.2 card yesterday and tried it out on Windows 11 on an ACEMAGIC F3A AMD Ryzen AI 9 HX 370 Mini PC using the instructions in https://docs.axelera.ai/sdk/user-guides/windows-setup/.  I had some troubles with the WSL part of the setup so I decided to skip that, and got to step 5 with the driver properly installed in device manager and the Axelera Windows packages installed. The axrunmodel sample returns the following output: [libaxldev.c:419] Firmware load address 0xffffffffffffffff exceeds 32-bit address space on Metis. WARNING:axelera.runtime:Failed to load runtime stage0: C:\AxeleraDevice-1.7.0\opt\axelera\device\omega\bin\start_axelera_runtime_stage0.bin [AxeleraDevice.cpp:455] Failed to get board DDR size. WARNING:axelera.runtime:Failed to get SW throttling from device metis-0:0:0 WARNING:axelera.runtime:Failed to get HW throttling from device metis-0:0:0 WARNING:axelera.runtime:Failed to get freq downscaling from device metis-0:0:0 [utils.c:264] sysctl_get_datas

Hi, when running inference on Metis M.2 on raspberry CM5 we noticed these errors occuring after couple minutes. error log: [libtriton_linux.c:531] DMABUF_METIS_XFER failed: Input/output error [AxeleraDmaBuf.cpp:222] DMA transfer failed: Input/output error [ERROR][axeShareMemoryExecute]: Dmabuf transfer failed. [ERROR][axeCommandQueueExecuteCommandListsAsync]: Level-zero memory operation failed: 0x70010001. terminate called after throwing an instance of 'std::runtime_error' what():  axr_run_model failed with Error at zeCommandQueueExecuteCommandLists(cmdqueue, n_cmdlists, cmdlists, nullptr): cmdqueue_run_cmdlists: 319: Exit with error code: 0x70010001 : ZE_RESULT_ERROR_NOT_AVAILABLE kernel errror log: axl 0001:01:00.0: DMA error WR CH0 (ctrl 0x1) setup:  Runtime: runtime-1.5.3-1 - Voyager SDK: v1.5.2 - metis-dkms: 1.4.4 - Firmware: flash version 1.5.0 - bcver 7.1