Skip to main content

Feature Request Pipeline

Filter by Status

Filter by Type

28 Posts

Lidar based Object Detection ModelNew

Project IdeaLidar based perception is very common for autonomous driving applications. While it has become relatively easy to achieve high accuracy with large and complex CNN architectures, deploying on resource constrained edge AI devices presents a whole new realm of challenges.Models have to be almost always converted to reduced precision FP16 or INT8 that often results in significant accuracy loss. Furthermore, several conversion tools frequently produce fragmented computation graphs with a significant portion of the model running on CPU, thereby increasing inference latency.This project aims to experiment and illustrate the capabilities of the Axelera AI accelerator together with the Voyager Wingman AI pipeline generator to deploy a trained CNN for object detection using bird’s eye view (BEV) images of lidar point clouds.The architecture is a custom CNN built specifically for fast inference using BEV inputs and has been validated and published in a peer-reviewed paper.https://ieeexplore.ieee.org/abstract/document/9564490https://arxiv.org/pdf/2104.10780A simplified and updated version of this will be used.The inference latency and accuracy will be benchmarked against FP32 model on other edge AI device such as Nvidia Orin and Nvidia Xavier AGX devices.The small form factor of the  Dell XE5 with a 16GB Axelera Edge 130p is perfect for installing in test vehicles for perception tasks. Deliverables:A live demo (recorded and/or live) fully integrated with ROS to simulate real sensor data processing in autonomous vehicleswingman prompts github repo with complete source code and trained model benchmark data against other edge AI computers List of key observations and findings about the overall setup - accelerator, SDK, AI toolsNot covered:Since this is a personal project, deployment in an actual test vehicle is not included. However, the ROS integrated pipeline makes it trivial to integrated in a real car.  About meI have several years of experience in the automotive domain specializing in designing, training and deployment of edge AI models for perception on embedded targets.Therefore I have worked with several tools and workflows before that follow the general pipeline of train - export - quantize - compile - deploy.A sample of my work in this domain can be found at:https://www.hackster.io/sm_1991/hardware-accelerated-real-time-perception-in-3d-harp-3d-fde0c0In this project I deployed a trained model on an entry level FPGA and won the 2nd prize in the segment.However, using an AI tool as a wingman to create the deployment pipeline is new to me and is therefore very exciting. It greatly simplifies the process of creating deployment pipeline which is often quite cumbersome, under-documented and difficult to get exactly correct.Since I already have a custom made CNN that is validated on embedded devices, I do not expect any significant obstructions to the project completion. Therefore, I believe, if selected and granted a development kit, I can produce a useful, honest set of artifacts demonstrating both the strengths and the friction points of the Axelera Metis accelerator and the Voyager Wingman assistant. Looking forward to some exciting weeks of building with the Axelera Metis accelerator and the Wingman AI assistant!

BN-Twin: Deterministic Digital Twin & High-Precision Control powered by Voyager WingmanNew

Hey Axelera team and community! 👋I saw the Prompt Challenge ad on my phone screen back on July 23, 2026, and it got me really excited enough to dig back into an old, paused concept I'd been sitting on BN-Twin and finally turn it into a working software demo.Now, I want to take this working engine and supercharge it on real Axelera hardware using Voyager Wingman!💡 What BN-Twin DoesBN-Twin is a single deterministic engine designed for two Industry 5.0 needs: Trustworthy Cobot Investment Decisions: Running transparent, non-black-box simulations comparing manual, automatic, and collaborative production lines. High-Precision Robotic Control: Controlling robotic arms with 50-digit precision kinematics while while damping motion instabilities at singularities instead of letting control corrections spike.Instead of just logging errors, it calculates the real-time joint-angle correction needed to close the loop, the actual control math, ready to be wired to real actuators once hardware integration begins. 🖼️ Current Working UI & Features (Screenshots attached) Robotic Arm Console: Live kinematics visualization, 50-digit precision (mpmath), singularity damping status (SAFE), and live joint correction signals ($\Delta\theta$). Production Line Dashboard: Multi-criteria decision engine comparing Manual vs. Full Auto vs. Collaborative 5.0 (analyzing throughput, OEE, cost per unit, and ergonomics). Cryptographic Proof: Every run generates a green TWIN SYNC HASH at the bottom to guarantee 100% reproducible results, paired with Fernet+PBKDF2 encryption for IP security. 🛠️ The Mission with Voyager Wingman & MetisSince the core software logic is already running, my goal during the build month is to port and accelerate it on Axelera silicon: Metis Pipeline Setup: I will use Voyager Wingman prompts to automatically generate, wire, and optimize the Metis execution pipeline on the Dell XE5 setup without writing complex YAML configurations manually. Upgrading to Live Vision: Right now, the arm module uses simulated virtual sensors. I plan to prompt Wingman to help integrate a real-time computer vision pipeline via the Voyager SDK, replacing virtual sensors with camera feedback to track actual physical end-effector positions. 🚀 Why This Proposal?Having a working software baseline means zero time wasted starting from scratch. I can jump straight into testing Voyager Wingman, generating pipelines, and benchmarking performance on real Axelera hardware from day one.Excited to see how fast Wingman can take this project to the next level. Let me know what you think! 🚀 below link github :https://github.com/BenNugraha/DT-BN_TWIN_Tech 

img2linux - convert a picture to an operating systemNew

𝕋ℍ𝔼 ℙ𝕀𝕋ℂℍ:   Take a photo of a computer. Get back a fully custom Linux system — hardware identified, every device mapped, a complete validated build, and a desktop that already knows what it's running on the moment you log in. No board notes, no digging through datasheets, no hand-assembling BitBake layers. With img2linux, its easy as shoot n boot. How it works• See it: A photo runs through a component-detection pipeline that locates the SoC, RAM, connectors, M.2 slots, and add-on cards, then OCRs the actual part numbers and board names printed on the silkscreen. That's the real identification signal — visual shape alone isn't trustworthy for chips that look alike — so every guess gets confirmed against a hardware database and, once the board boots, against what the board itself reports.• Map it: Once the base board is known, img2linux pulls the real device tree source for it - the same file the kernel uses to understand its own buses, addresses, and pins - and folds every other piece of detected hardware into that map as an overlay. An Axelera Metis card, a camera, an NVMe drive: all of it becomes one structured picture of the whole machine, rendered as an interactive block diagram.• Cook it: With the hardware side settled, img2linux searches the Yocto/OpenEmbedded ecosystem — plus Axelera's own meta-axelera layer and BSP releases - for the board support package and machine definition that fits, folds in the kernel version and OS features requested, and assembles the full BitBake build.• Prove it: Before it spends an hour on a real build, img2linux parse-checks the recipe, runs static compatibility checks over the whole device map, and boot-tests it in a virtual machine. If anything fails, it redesigns the recipe and tries again - automatically - until the virtual boot passes clean.• Build it: Once it passes, img2linux kicks off the real build and hands over a finished image, ready to flash.• Show it: Every image it builds ships with one more thing: a desktop that renders the exact block diagram it built for that machine, with every device as a live tile - temperature, clock speed, memory, utilization - updating itself the instant something changes, no polling. Where the hardware allows it, settings can be edited right from the desktop, safely, because the same compatibility rules that built the recipe are the ones gating what's allowed to change. With img2linux, you photograph a computer, get a bespoke, working Linux distribution back, complete with a desktop that already understands its own hardware - needs zero technical explanation to land. Non-experts get it instantly. And underneath the "wow," every stage is real, deterministic engineering: known device trees, indexed BSPs, a database that won't let the model guess its way into an incompatible build, and a validation loop that only ships what's provably going to work.It's also a genuinely live, on-Metis demo in two places, not just a batch job: the photo-to-hardware-ID stage is a real vision pipeline running on the Metis card, and the desktop dashboard reads live telemetry: clocks, temperature, utilization - straight off the Metis card through its own device APIs while it's running. What we're not claiming:img2linux doesn't invent board support for hardware nobody's ever built a BSP for - bootloader and DDR bring-up for genuinely new silicon isn't something that can be responsibly automated from a datasheet. If a photographed board has no indexed BSP, img2linux says so plainly instead of guessing. It's a generator built on real, existing embedded-Linux infrastructure - not a silicon bring-up wizard.*img2linux will only use free and publicly available software. $THE PROMPT$Ok Wingman, ive got a *special* objective today  and i need YOUR help. Lets build a system that takes a photo (or description) of a piece of hardware and produces a validated, ready-to-boot custom Linux image for it, and even includes a live desktop canvas that displays and lets you edit the hardware it's running on. Build it in these stages:1. Hardware ID (vision). Take a photo or video showing all components of a target system. Run a component-detection pipeline (a fine-tuned YOLO-family model) over the image to locate the SoC package, RAM, connectors, M.2 slots, PMICs, camera modules, and any add-ons. Run OCR over each detected region to read board names, revisions, and IC part numbers off the silkscreen and package markings - and treat this as the real identification signal, since visual appearance alone is unreliable for SoC packages that might look alike. Look up the OCR identifiers and compare against a hardware knowledge database, falling back to web/datasheet lookup for anything not already indexed. Surface the result as a candidate identification for me to confirm, and once the board is actually running, cross-check it against live probing (lspci, device tree, /proc/cpuinfo).2. Device tree resolution. Once the base board is identified, pull its authoritative device tree source (DTS) from its BSP rather than inferring one from photos or datasheets - the DTS is the real machine map: buses, peripheral base addresses, interrupts, clocks, pinmux. Parse it into a graph model of the base machine.3. Full-system composition. Add every other piece of hardware detected in the photo - including an Axelera Metis card, cameras, storage, or other accessories - into that graph as device tree overlays, so the graph represents the complete system as built, not just the base board.4. Block diagram. Render the completed machine graph as an interactive block diagram of the whole system: every device, its connections, and where it sits in the machine. This will serve as the absolute identity from which all the following steps build upon.5. BSP and recipe resolution. Search the OpenEmbedded Layer Index plus Axelera-specific sources (meta-axelera, Metis Compute Board BSP release notes, supported kernel versions, Voyager SDK runtime dependencies) for the BSP and MACHINE definition matching the identified hardware, preferring Yocto layers wherever one exists. Only generate a configuration for hardware with a known, indexed BSP layer — if nothing matches, tell me clearly rather than attempting to invent bootloader or DDR-init support from datasheets alone.6. Kernel and distro assembly. Using the user-specified kernel version and desired distro features, resolve the full set of recipes and companion layers needed, confirming every layer's compatible Yocto release agrees with the others as a deterministic database check, not a guess. Assemble the complete BitBake configuration — machine, distro, layers including meta-axelera, and the DISTRO_FEATURES/IMAGE_INSTALL lines - as a kas YAML.7. Virtualized validation loop. Before any real build, validate the whole recipe virtually: parse-check the generated config (bitbake -p / bitbake -n), run static checks over the device tree graph for bus conflicts, address overlaps, pinmux collisions, and power budget, and boot-test the result in QEMU where a machine model exists. If anything fails, revise the recipe and re-test until the virtual path passes clean. Tell me plainly that Metis-specific and other vendor peripherals still need hardware-in-the-loop confirmation once the board is in hand — don't claim the virtual pass covers that.8. Build. Once validated, run the real build and hand me the finished artifact — a bootable image or ISO for the target device.9. A living desktop. Every image you produce should include one more recipe: a desktop canvas that renders the block diagram from step 4, with each device as a live widget. Build this as a small event-driven system service that owns the machine graph and subscribes to the hardware's own event sources - udev/netlink hotplug events, sysfs attribute changes, D-Bus signals already broadcast by things like UPower and NetworkManager - instead of polling, with a lazy-refresh fallback only for the few attributes that don't emit change events. Widgets should be pure clients of that service's D-Bus API, with zero direct hardware access. Where a device supports it - including the Metis card, through its axdevice and tracer interfaces for clocks, temperature, memory, and MVM utilization - let the widget edit the setting directly, but gate every write behind the same compatibility checks used to build the recipe, so nothing lets me set a value the hardware doesn't actually support, and journal changes so the service can tell desired state from actual state after a reboot. Render it as one full-canvas application rather than separate floating widgets, so it works consistently across desktop environments and on the target board's own display output.Walk me through each stage as you build it, and ask me directly if anything about the target hardware or desired features is ambiguous before generating the recipe. 

Monocular 3D Object Detection on Metis at 24.5 FPS — full pipeline, single core, realtimeNew

Sharing my first project on Axelera Metis: end-to-end monocular 3D object detection running at 24.5 FPS on a single AIPU core, with a CPU host and no GPU anywhere in the pipeline.What it does Takes a single camera image and predicts 3D bounding boxes for every car, pedestrian and cyclist in the scene  position, dimensions and orientation , in real time. Built on MonoCon (CVPR 2022) with a DLA-34 backbone, evaluated on KITTI driving sequences.How it is split The model had to be divided at a hard compiler boundary. AttnBatchNorm2d contains a ReduceMean op that Voyager cannot quantize, so the pipeline is:AIPU: backbone + neck + fused HeadConv1 (64 to 576 channels, single output tensor) CPU host: AttnBatchNorm2d + ReLU + 1x1 convs, implemented in hand-written C++ PerformanceStage Time Preprocess + Quantize 1.4 ms AIPU inference 31 ms Dequantize 6.5 ms Head (C++) 22 ms Decode + NMS 1 ms Sequential total 62 ms / 16 FPS Pipelined throughput 41 ms / 24.5 FPS Pipelined throughput uses a two-thread producer-consumer design: the AIPU processes frame N+1 while the CPU decodes frame N concurrently.Key findings during deployment A few things that are not in the documentation and took real time to figure out: per_tensor_histogram (default) silently clips HeadConv1 activations — true range is roughly -1350 to +1200, the histogram scheme covers only -250 to +250. Zero detections until switching to per_tensor_min_max. Multi-output graphs get their outputs sorted alphabetically by the compiler. Discovered by comparing per-tensor statistics against a PyTorch reference. Fixed by fusing all nine head convs into one 64 to 576 conv with a single output tensor. axrArgument.fd must be -1 for host-pointer mode. Setting it to 0 silently produces zero output with AXR_SUCCESS returned. The first 2-3 inference calls return stale output regardless of input. Warm-up with dummy frames is required before trusting results. ONNXRuntime was taking 55ms on a 24,000-parameter subgraph , not because of arithmetic but because of per-node dispatch overhead across ~150 ops. Replaced with a preallocated C++ implementation: 55ms to 22ms. Repo Everything is open source: PyTorch model, ONNX export scripts,Voyager compile script, C++ inference library with 3D box and bird's-eye view visualization.https://github.com/sanket-pixel/monocon-metisHappy to answer questions on any part of the deployment.Bonus discussion point :Running the backbone+neck+HeadConv1 graph alone via axrunmodel hits 90 FPS on four cores and 40 FPS on a single core. The compiled model in this project uses aipu_cores_used=1, resources_used=0.25,  straightforward but not necessarily optimal. There is likely headroom in the compiler configuration that this project has not fully explored: tiling depth, DFS search constraints, IMC double buffer pipelining, and grouping IFDW tasks are all knobs that affect how efficiently the compiler maps the graph onto the MVM array. If anyone has found configurations that push closer to the axrunmodel ceiling on a similarly sized graph, would be very interested to hear what worked. Happy to discuss.  

Andred7New

Design me the following with the name ANDRED7 on all.1. An hybrid drone that is equipped with a sonar, a very good day and night video camera for streaming live video feeds to head office, a solar that can run for 7 days, get go's coordination and send info via satellite to head office and other hybrid equipment and the drone should be able to communicate and give orders to other hybrids. 2. The vessel that is equipped with the follow: 5 skimmer boats attached to both sides of the vessel. The skimmer boats are released by the vessel and on its return with the help of sensors positions itself perfectly so that the vessel can attach it. The skimmer boats are controlled by a pyp that can extract and pull back, the pyp is switched on by the vessel that sucks up the oil. The boom. It can extract and be pulled back in. The lengIs is given by the drone. The boom has sensors that helps to navigate the skimmers and to firm a dam around the oil.. The crain, it is used to attach its arms to a submarine and a big pyp. On top of the crain is a good day and night video camera for streaming live video to head office. The submarine is equipped with a sensor, Good day and night video camera for streaming live video. The submarine is used to find any damage to the vessel that made the spill and weld the damages plus the arms of the submarine can also attach a long pyp to sunken ships that contain oil in order to suck op the oil. All equipment on the vessel all have solar, can communicate to each other and head office plus be able to attach itself to a charging port and detach itself.Once the vessel is full off oil the vessel returns to the port where it positions itself under a crain with the help of sensors. The crains arms attach a pyp to the vessel and pumps out the oil into containers. The crain also has a solar, can work with sensors that's on the vessel and the containers. 

windows drivers scriptNew

#Get-MetisDrivers.ps1## normally bcd edit allow unsigned drivers ... on github  Voyager SDK  every reboot ... kills bitlocker secboot.. etc... ### required wdk winget install Microsoft.WindowsSDK.10.0.22621#Requires -RunAsAdministrator<#.SYNOPSIS    Downloads, unpacks, and test-signs Axelera Metis M.2 AIPU drivers locally..DESCRIPTION    Step 1 of Axelera Metis driver installation:      - Downloads MetisDriver and optionally Switchtec-kmdf archives      - Extracts to a staging directory      - Generates a self-signed test certificate (if not already present)      - Signs all .sys/.cat/.inf driver files with the local cert      - Enables TESTSIGNING boot mode if not already active.PARAMETER DestDir    Directory where archives and unpacked drivers will be staged.    Default: $env:USERPROFILE\MetisDrivers.PARAMETER IncludeSwitchtec    Switch to also download the Switchtec-kmdf driver (required only for    the 4-Metis PCIe board, not needed for single M.2 Metis)..PARAMETER CertSubject    Subject name for the generated test-signing certificate.    Default: "MetisTestSign".EXAMPLE    # Single M.2 Metis (most common homelab case)    .\Get-MetisDrivers.ps1.EXAMPLE    # 4-port PCIe board    .\Get-MetisDrivers.ps1 -IncludeSwitchtec.EXAMPLE    # Custom staging directory    .\Get-MetisDrivers.ps1 -DestDir D:\Drivers\Metis -IncludeSwitchtec#>[CmdletBinding()]param(    [string]$DestDir        = "$env:USERPROFILE\MetisDrivers",    [switch]$IncludeSwitchtec,    [string]$CertSubject    = "MetisTestSign")Set-StrictMode -Version Latest$ErrorActionPreference = "Stop"# ---------------------------------------------------------------------------# Helpers# ---------------------------------------------------------------------------function Write-Step([string]$Msg) {    Write-Host "`n==> $Msg" -ForegroundColor Cyan}function Write-OK([string]$Msg) {    Write-Host "    [OK] $Msg" -ForegroundColor Green}function Write-Warn([string]$Msg) {    Write-Host "    [!!] $Msg" -ForegroundColor Yellow}# ---------------------------------------------------------------------------# URLs# ---------------------------------------------------------------------------$BaseUrl   = "https://software.axelera.ai/artifactory/axelera-win/driver/1.3.x"$Downloads = [ordered]@{    "MetisDriver-1.3.1.zip"         = "$BaseUrl/MetisDriver-1.3.1.zip"    "switchtec-kmdf-0.7_2019.zip"   = "$BaseUrl/switchtec-kmdf-0.7_2019.zip"}# ---------------------------------------------------------------------------# 0. Preflight# ---------------------------------------------------------------------------Write-Step "Preflight checks"# Ensure WDK signtool is available (ships with Windows SDK / WDK)$SignTool = (Get-Command signtool.exe -ErrorAction SilentlyContinue)?.Sourceif (-not $SignTool) {    # Fallback: search common SDK paths    $CandidatePaths = @(        "${env:ProgramFiles(x86)}\Windows Kits\10\bin\*\x64\signtool.exe"        "${env:ProgramFiles}\Windows Kits\10\bin\*\x64\signtool.exe"    )    $SignTool = Resolve-Path $CandidatePaths -ErrorAction SilentlyContinue |                Sort-Object -Descending |                Select-Object -First 1 -ExpandProperty Path}if (-not $SignTool) {    Write-Warn "signtool.exe not found. Install the Windows SDK / WDK."    Write-Warn "  winget install Microsoft.WindowsSDK.10.0.22621"    Write-Warn "Continuing — signing step will be skipped."}else {    Write-OK "signtool: $SignTool"}# Makecert / New-SelfSignedCertificate availability$HasPKI = [bool](Get-Command New-SelfSignedCertificate -ErrorAction SilentlyContinue)Write-OK "New-SelfSignedCertificate available: $HasPKI"# ---------------------------------------------------------------------------# 1. Create staging directory# ---------------------------------------------------------------------------Write-Step "Creating staging directory: $DestDir"$null = New-Item -ItemType Directory -Force -Path $DestDir$ArchiveDir  = Join-Path $DestDir "archives"$ExtractDir  = Join-Path $DestDir "extracted"$null = New-Item -ItemType Directory -Force -Path $ArchiveDir, $ExtractDirWrite-OK "Directories ready."# ---------------------------------------------------------------------------# 2. Download archives# ---------------------------------------------------------------------------Write-Step "Downloading driver archives"$ToDownload = @("MetisDriver-1.3.1.zip")if ($IncludeSwitchtec) { $ToDownload += "switchtec-kmdf-0.7_2019.zip" }foreach ($FileName in $ToDownload) {    $Url        = $Downloads[$FileName]    $OutFile    = Join-Path $ArchiveDir $FileName    if (Test-Path $OutFile) {        Write-Warn "$FileName already present — skipping download."        continue    }    Write-Host "    Downloading $FileName ..." -NoNewline    try {        $ProgressPreference = 'SilentlyContinue'   # dramatically faster Invoke-WebRequest        Invoke-WebRequest -Uri $Url -OutFile $OutFile -UseBasicParsing        $ProgressPreference = 'Continue'        Write-Host " done." -ForegroundColor Green    }    catch {        Write-Host " FAILED." -ForegroundColor Red        Write-Warn "Could not download $FileName : $_"        Write-Warn "Download manually from: $Url"    }}# ---------------------------------------------------------------------------# 3. Extract archives# ---------------------------------------------------------------------------Write-Step "Extracting archives"Get-ChildItem -Path $ArchiveDir -Filter "*.zip" | ForEach-Object {    $Zip     = $_.FullName    $Target  = Join-Path $ExtractDir $_.BaseName    if (Test-Path $Target) {        Write-Warn "$($_.Name) already extracted — skipping."        return    }    Write-Host "    Expanding $($_.Name) ..."    Expand-Archive -Path $Zip -DestinationPath $Target -Force    Write-OK "Extracted to: $Target"}# ---------------------------------------------------------------------------# 4. Create / retrieve test-signing certificate# ---------------------------------------------------------------------------Write-Step "Test-signing certificate"$CertStore  = "Cert:\LocalMachine\My"$ExistingCert = Get-ChildItem $CertStore |                Where-Object { $_.Subject -like "*$CertSubject*" } |                Select-Object -First 1if ($ExistingCert) {    Write-OK "Re-using existing cert: $($ExistingCert.Thumbprint)"    $Cert = $ExistingCert}elseif ($HasPKI) {    Write-Host "    Creating self-signed certificate '$CertSubject' ..."    $Cert = New-SelfSignedCertificate `        -Subject        "CN=$CertSubject" `        -Type           CodeSigningCert `        -CertStoreLocation $CertStore `        -KeySpec        Signature `        -HashAlgorithm  SHA256 `        -NotAfter       (Get-Date).AddYears(10)    # Also install into Trusted Publishers + Root so Windows trusts test-signed drivers    $CertPEM = Export-Certificate -Cert $Cert -FilePath (Join-Path $DestDir "$CertSubject.cer") -Type CERT    Import-Certificate -FilePath $CertPEM.FullName -CertStoreLocation "Cert:\LocalMachine\Root"          | Out-Null    Import-Certificate -FilePath $CertPEM.FullName -CertStoreLocation "Cert:\LocalMachine\TrustedPublisher" | Out-Null    Write-OK "Certificate created and installed. Thumbprint: $($Cert.Thumbprint)"}else {    Write-Warn "Cannot create certificate (New-SelfSignedCertificate unavailable)."    Write-Warn "Signing step will be skipped."    $Cert = $null}# ---------------------------------------------------------------------------# 5. Sign drivers# ---------------------------------------------------------------------------Write-Step "Signing driver files"if ($SignTool -and $Cert) {    $DriverFiles = Get-ChildItem -Path $ExtractDir -Recurse -Include "*.sys","*.cat","*.dll" |                   Where-Object { -not $_.PSIsContainer }    if ($DriverFiles.Count -eq 0) {        Write-Warn "No signable driver files found in $ExtractDir"    }    else {        foreach ($File in $DriverFiles) {            Write-Host "    Signing: $($File.Name) ..."            & $SignTool sign `                /sha1  $Cert.Thumbprint `                /fd    sha256 `                /tr    "http://timestamp.digicert.com" `                /td    sha256 `                /v     $File.FullName 2>&1 | ForEach-Object { "      $_" }            if ($LASTEXITCODE -ne 0) {                Write-Warn "signtool returned $LASTEXITCODE for $($File.Name) — check output above."            }            else {                Write-OK $File.Name            }        }    }}elseif (-not $SignTool) {    Write-Warn "Skipping signing: signtool.exe not found."}elseif (-not $Cert) {    Write-Warn "Skipping signing: no certificate available."}# ---------------------------------------------------------------------------# 6. Enable TESTSIGNING boot mode# ---------------------------------------------------------------------------Write-Step "Boot configuration — TESTSIGNING"$BcdOutput  = & bcdedit /enum '{current}' 2>&1$IsTestSign = $BcdOutput -match "testsigning\s+Yes"if ($IsTestSign) {    Write-OK "TESTSIGNING already enabled."}else {    Write-Host "    Enabling TESTSIGNING ..."    & bcdedit /set testsigning on | Out-Null    if ($LASTEXITCODE -eq 0) {        Write-OK "TESTSIGNING enabled. A reboot is required before installing the driver."    }    else {        Write-Warn "bcdedit failed (LASTEXITCODE=$LASTEXITCODE). Run as Administrator?"    }}# Also disable Secure Boot enforcement for test-signed drivers (Disable Integrity Checks)# Only uncomment if you are on a non-Secure-Boot system / dev machine:# & bcdedit /set nointegritychecks on# ---------------------------------------------------------------------------# 7. Summary# ---------------------------------------------------------------------------Write-Step "Summary"Write-Host ""Write-Host "  Staging root   : $DestDir"                           -ForegroundColor WhiteWrite-Host "  Archives       : $ArchiveDir"                        -ForegroundColor WhiteWrite-Host "  Extracted      : $ExtractDir"                        -ForegroundColor Whiteif ($Cert) {Write-Host "  Cert thumbprint: $($Cert.Thumbprint)"               -ForegroundColor White}Write-Host ""Write-Host "  Next steps:"                                         -ForegroundColor YellowWrite-Host "    1. Reboot if TESTSIGNING was just enabled."        -ForegroundColor YellowWrite-Host "    2. In Device Manager, right-click the Metis"       -ForegroundColor YellowWrite-Host "       device -> Update driver -> Browse my computer"  -ForegroundColor YellowWrite-Host "       -> point at: $ExtractDir\MetisDriver-1.3.1"    -ForegroundColor Yellowif ($IncludeSwitchtec) {Write-Host "    3. Repeat for the Switchtec controller using:"     -ForegroundColor YellowWrite-Host "       $ExtractDir\switchtec-kmdf-0.7_2019"           -ForegroundColor Yellow}Write-Host ""

VitoEnsign

Nema-Medbot-MikyRobotNew

AXELERA CHALLENGE – PROJECT UPDATEWe are progressing on the development of NEMA–MedBot–Miky, a modular robotic platform for assistance, human–robot interaction, and embodied edge AI experimentation.NEMA is our proprietary artificial intelligence, developed in-house, designed to orchestrate perception, reasoning, and action across our robotic systems.Recent progress:Hardware integration of Axelera Metis2 on Orange Pi 5 Plus via PCIe Successful device enumeration on the PCIe bus Voyager SDK installation in progress to enable accelerated on-device inferenceThe architecture we are building is edge-first:Orange Pi handles ROS2, sensors, actuators, and control logic Metis2 is dedicated to neural inference (vision, perception, multimodal models) NEMA coordinates AI pipelines and decision-makingThis approach enables low latency, efficient resource usage, and a scalable, industrial-grade architecture.NEMA–MedBot–Miky is not a maker project.We are a real startup building a platform with commercial and industrial objectives.Part of the codebase will remain proprietary. We are open to strategic and commercial partnerships.Next steps:First accelerated inference on Metis2 Vision → AI → ROS → motor pipeline Head movement and interaction testsWe thank Axelera for supporting the edge AI ecosystem and for the opportunity to participate in the challenge.MINI TECHNICAL REPORTNEMA–MedBot–Miky – Technical Progress UpdateAbstractNEMA–MedBot–Miky is a modular edge-AI robotic platform for assistance, human–robot interaction, and embodied intelligence research. The system combines Orange Pi 5 Plus for control and ROS2 with the Axelera Metis2 accelerator for neural inference. A proprietary AI engine (NEMA) orchestrates perception, reasoning, and action. The architecture is designed for low latency, modularity, and scalability, targeting real-world industrial and assistive applications.Hardware StatusOrange Pi 5 Plus operational Axelera Metis2 installed via PCIe Metis2 device enumerated on PCIe bus USB Bluetooth dongle and external speaker integratedSoftware StatusArmbian Linux running on Orange Pi ROS2 workspace initialized Neural TTS (Piper) operational Automatic audio routing and Bluetooth reconnection implemented Voyager SDK installation in progressSystem ArchitectureOrange Pi → ROS2, sensors, actuators, control Metis2 → accelerated neural inference NEMA → AI orchestration and decision layerCurrent CapabilitiesVoice output with neural TTS Automatic startup greeting Modular software structureNext Steps (24–72h)Complete Voyager SDK installation Run first inference demos on Metis2 Integrate vision output with ROS2 Enable head motor controlNotes on IP and Commercial StrategyReal startup project Partial proprietary codebase Focus on commercial and industrial partnerships

VitoEnsign

Project Update: NEMA AI Integration on MedBot and Early Miky Robot PrototypingNew

Project Update – MedBot / Miky RobotWe are currently testing our proprietary artificial intelligence, NEMA, and adapting some of its capabilities to the MedBot project.In particular, we are integrating NEMA on Orange Pi together with the Metis accelerator board by Axelera, with the goal of equipping MedBot with a new layer of intelligence dedicated to assistance, interaction, and user support.The same NEMA AI is also being integrated into Miky Robot, conceived as a humanoid interface for MedBot.At this early stage, we are working on the first hardware components and their integration with artificial intelligence.Current Status of Hardware DevelopmentWe are 3D printing the first parts of the robot, especially the head and some structural components.We are performing printing iterations and mechanical tests.In parallel, we are testing the integration between NEMA and the Axelera hardware platform.We have also started developing the case for the monitor that will host the Axelera mainboard, but currently only some parts of the case are in the prototyping phase.Realistic Goals by the End of FebruaryBy the end of February, we expect to have:an initial working integration of NEMA on MedBot;a partial prototype of Miky Robot, likely including:the head with AI capabilities and sensors,some structural components,and, if possible, an early preliminary version of arms and hands;a first partial version of the mainboard case, not yet complete.This is therefore an early prototyping phase, focused on validating the integration between AI and hardware rather than delivering a complete system.We can share some work-in-progress images of the 3D printing phases and hardware components currently under development, to show the real status of the project.We will continue sharing updates as the system evolves from an initial prototype toward a more integrated solution.Best regards,Vito Traversa 

Problem with axdevice --refresh causing NVMe drives to be stopped on a running systemImplemented

Putting this up for folk who may hit a similar issue.If you have a machine which has a single root PCIe device, where the output of lspci -tv looks something like this;alsutton@svr204:~$ lspci -tv-[0000:00]-+-00.0 Intel Corporation 8th Gen Core Processor Host Bridge/DRAM Registers +-02.0 Intel Corporation CoffeeLake-S GT2 [UHD Graphics 630] +-08.0 Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th/8th Gen Core Processor Gaussian Mixture Model +-14.0 Intel Corporation Cannon Lake PCH USB 3.1 xHCI Host Controller +-14.2 Intel Corporation Cannon Lake PCH Shared SRAM +-16.0 Intel Corporation Cannon Lake PCH HECI Controller +-1b.0-[01]----00.0 Micron/Crucial Technology P2 [Nick P2] / P3 / P3 Plus NVMe PCIe SSD (DRAM-less) +-1f.0 Intel Corporation B360 Chipset LPC/eSPI Controller +-1f.3 Intel Corporation Cannon Lake PCH cAVS +-1f.4 Intel Corporation Cannon Lake PCH SMBus Controller +-1f.5 Intel Corporation Cannon Lake PCH SPI Controller \-1f.6 Intel Corporation Ethernet Connection (7) I219-VYou need to be very careful running `axdevice --refresh`.I’ve got two machines that, by default, present the pci device tree in this way, and running `axdevice --refresh` triggered the NVMe drive to be disconnected from the system, resulting in filesystem corruption, which put the whole system into a read-only mode.It would be awesome if someone could update the axdevice script to only affect Axelera devices, and yes, this is a machine with the card installed, it just hasn’t been detected.

LattePanda Sigma works with Metis M.2!New

Hi all! I wanted to contribute a little bit about my experience bringing up the Metis M.2 in my LattePanda Sigma. Im an EE who is self taught, I have worked for Harley Davidson, Span.io, Enel X NA, and I’ve done several consulting projects on synthesizers and drum machines. My interest in AI is hobby and curiosity based, not professional. Software engineering is a new skill Im creating.I first tried to run Metis on the Windows 11 operating system that came with LattePanda Sigma, and following the instructions on the git was extremely confusing. I have ADD, and some other learning differences, but that wasn’t the reason installing was so hard on Windows. It’s because there isn’t a single page with coherent instructions telling the user how to bring up the hardware in a simple step by step format. Having the user click between git pages on firmware, installation of drivers, wsl, putting Windows into test mode, using multiple programming environments, etc is painful and makes installing the hardware on Windows a miserable, confusing, and difficult experience.I’ll probably make my own step by step guide for Windows at some point since the instructions on git are confusing.I then tried to do the install on an old version of Ubuntu (support 24.04 please!) and I had much less trouble. I HIGHLY RECOMMEND using Ubuntu 22.04 to run the hardware and software over Windows. The instructions to install the Voyager-SDK on Ubuntu 22.04 actually worked pretty well. I was surprised.I ran into an issue at one point after installing the SDK: I couldn’t detect the Metis M.2 card. I couldn’t really figure out how to install the driver from the instructions for Ubuntu installation, so I had to download the .deb driver and install it similar to the “instructions for installing Voyager-SDK using Docker” to get the driver installed. Once the driver is installed, and the clunky SDK is installed and running, the demos with YOLO worked great, with the Metis M.2 card barely breaking a sweat doing inferences.