Roboter trenger mer enn TOPS

Når en ny robot skal utvikles, er det lett å fokusere på prosessorytelse. Hvor mange TOPS kan KI-akseleratoren levere? Hvor mange kamerastrømmer kan systemet håndtere? Hvor raskt kan nevrale nettverk kjøres?

I praksis er det imidlertid sjelden selve beregningsytelsen som bestemmer hvor lang tid det tar å få en autonom robot i produksjon. Utfordringen ligger i integrasjonen rundt prosessoren: kameraer, IMU-er, dybdesensorer, motorstyring, kommunikasjonsgrensesnitt, strømforsyning og ikke minst programvaren som binder det hele sammen.

Det er bakgrunnen for at AMD og Analog Devices (ADI) har gått sammen om en utviklingsplattform for robotikk, der målet er å levere en større del av systemet ferdig integrert.

Fra distribuerte mikrokontrollere til sentralisert databehandling

Tradisjonelle robotsystemer har ofte vært bygget opp rundt en rekke mikrokontrollere. Én prosessor kan ha håndtert motorstyring, en annen sensorer, mens ytterligere kontrollere har tatt seg av kommunikasjon og andre delsystemer.

Denne arkitekturen forsvinner ikke, men stadig mer av intelligensen flyttes til en sentralisert beregningsplattform. Moderne autonome roboter må kunne behandle store mengder sensordata samtidig som de kjører maskinlæringsmodeller, navigasjon, lokalisering og bevegelsesplanlegging.

AMD Kria AI Robotics Developer Platform er utviklet med denne arkitekturen som utgangspunkt. I sentrum står et Kria AI System-on-Module (SOM) med CPU, integrert GPU, NPU og felles minne. Et FPGA-basert grensesnittlag kompletterer beregningsdelen.

Programvarestakken er basert på et Linux-miljø med blant annet ROS 2, PyTorch, TensorFlow og Docker, samt maskinvareakselererte biblioteker for persepsjon.

For robotutviklere er ROS 2 spesielt interessant. Robot Operating System 2 har i praksis blitt en viktig programvareplattform for utvikling av autonome systemer, men det kan være betydelig arbeid å få hver enkelt sensor og aktuator til å fungere korrekt i ROS 2-miljøet.

Kameraene er bare begynnelsen

Et moderne autonomt kjøretøy eller en mobil robot kan ha fire, seks eller flere kameraer. Da oppstår det raskt problemer som ikke har noe med KI-algoritmene å gjøre.

Kameradataene må overføres med tilstrekkelig båndbredde og lav latenstid. Samtidig må signalene tidsjusteres, kameraene forsynes med strøm og kablingen integreres mekanisk i roboten.

AMD og ADI benytter derfor GMSL (Gigabit Multimedia Serial Link), en teknologi som blant annet er etablert i bilindustrien. GMSL kan overføre høyhastighetsdata over relativt lange koaksialkabler og gjør det mulig å samle flere kameraforbindelser uten å trekke separate høyhastighetsgrensesnitt hele veien tilbake til hovedkortet.

Dette illustrerer et viktig poeng: Et robotsystem trenger ikke bare en rask prosessor. Det trenger et fysisk grensesnitt mot verden som prosessoren kan håndtere.

IMU-en får en viktigere rolle

Kameraer og LiDAR er sentrale sensorer for robotens persepsjon, men de fungerer ikke like godt under alle forhold. Lite lys, reflekterende overflater, støv eller korridorer med få visuelle kjennetegn kan gjøre visuell lokalisering vanskelig.

Her kommer treghetssensorer inn. En IMU måler blant annet akselerasjon og rotasjon og kan dermed gi informasjon om robotens bevegelse også når de optiske sensorene har problemer.

I plattformen inngår ADIs ADIS16607, en høyytelses IMU. Poenget er imidlertid ikke bare å legge til enda en sensor. IMU-dataene må tidsstemples og synkroniseres med kamera- og andre sensordata før de kan brukes effektivt i sensorfusjon.

Kombinasjonen av visuelle data og treghetsdata kan gi en mer robust lokalisering enn bruk av én enkelt sensortype. Det er særlig relevant når roboten skal fungere utenfor kontrollerte demonstrasjonsmiljøer.

Dybdedata krever betydelig prosessering

Dybdekameraer og andre 3D-sensorer produserer store datamengder. Før informasjonen kan brukes til navigasjon og planlegging, må dataene blant annet filtreres, justeres og kombineres med informasjon fra andre sensorer.

Dersom all denne behandlingen utføres på CPU-en, konkurrerer den direkte med andre oppgaver som navigasjon, planlegging og kontroll.

Derfor er maskinvareakselerasjon viktig. FPGA-en i plattformen kan brukes til bestemte, deterministiske dataprosesser og dermed avlaste den generelle prosessoren og AI-akseleratorene.

Det er også her begrepet TOPS blir litt misvisende som mål på en robots reelle ytelse. En robot kjører ikke bare nevrale nettverk. Den må også håndtere klassiske algoritmer, numerisk optimalisering, kalibrering, sensorfusjon og kontrollsløyfer med krav til forutsigbar latenstid.

Motorstyring er en egen disiplin

Det samme gjelder robotens aktuatorer. Å sende en hastighetskommando til en motor er enkelt. Å bygge et system som styrer mange motorer presist og sikkert under varierende belastning, temperatur og vibrasjon, er noe helt annet.

Plattformen har derfor grensesnitt for blant annet CAN-FD og RS-485, samt utvidelsesmuligheter for motorstyring. Isolerte kommunikasjonsgrensesnitt og tilbakemelding fra enkodere og strømsensorer er viktige elementer i et slikt system.

For større roboter kommer også strømforsyningen inn i bildet. AMD og ADI peker på referansedesign og grensesnitt for batterisystemer opp mot 48 V.

Den skjulte kostnaden: ROS 2

En av de største tidskostnadene i robotprosjekter kan være det som skjer etter at maskinvaren er valgt.

Hver sensor trenger en driver. Maskinvaren må eksponeres for Linux. Deretter skal det utvikles ROS 2-noder, meldingsformater og grensesnitt. Timing må kontrolleres, og hele kjeden må testes under realistiske forhold.

Med standardkomponenter og egenutviklede kretskort må mye av dette gjøres fra bunnen av.

Det er nettopp denne delen AMD og ADI forsøker å redusere. Kria-plattformen kombinerer et SOM med en robotorientert carrier-konstruksjon og et ferdig programvaremiljø der ADI-drivere og de relevante grensesnittene allerede er integrert.

Et åpent alternativ

En interessant del av arkitekturen er bruken av en modulær SOM-løsning. Beregningsmodulen kan skiftes når ytelseskravene endres, mens resten av systemarkitekturen i større grad kan beholdes.

Det kan være viktig i robotprosjekter med lang utviklingstid. En prototype som bygges med dagens prosessor, trenger ikke nødvendigvis samme beregningsplattform når produktet går i serie.

Samtidig forsøker AMD å unngå en klassisk leverandørbinding gjennom en programvarestakk basert på etablerte verktøy som Linux, ROS 2, PyTorch, TensorFlow og Docker.

Fra utviklingskort til robot

Den viktigste endringen er dermed ikke nødvendigvis at roboten får mer beregningskraft. Det er at flere av subsystemene er tenkt som én sammenhengende utviklingsplattform.

For robotprodusenten kan det bety at tiden som normalt brukes på bærerkort-design, driverutvikling, kameraintegrasjon, sensorkalibrering og ROS 2-tilpasning, reduseres.

Det er en pragmatisk tilnærming til et problem som har blitt stadig tydeligere etter hvert som autonome roboter har beveget seg fra forskningslaboratorier til lager, fabrikker og logistikkmiljøer.

En moderne robot er i realiteten et distribuert sanntidssystem med svært forskjellige typer arbeidsbelastninger. KI-inferens er bare én av dem. Like viktig er evnen til å hente inn, tidsjustere og behandle sensordata, kontrollere aktuatorer og holde hele systemet deterministisk og robust.

Det er derfor mulig at den viktigste spesifikasjonen for neste generasjon robotplattformer ikke blir antall TOPS, men hvor mye utviklingsarbeid som allerede er gjort når ingeniøren kobler inn strømmen.