Hirdetés

Egy új lapka segítheti a robotok gyorsabb reakcióidejét

A robotokat régóta épít az ipar, de ezek nagy része még igen lassú, így nem minden területre alkalmasak. A problémát a mozgástervezés jeleni, ugyanis ez a robot működésének legkritikusabb pontja. A jelenség az ember számára jól megfigyelhető, mivel látható, hogy a robot a parancs kiadása után a végrehajtás előtt még időzik egy picit, majd belekezd a munkába. Az emberi mivoltunkból kiindulva ezt úgy gúnyoljuk, hogy robot gondolkodik, és tulajdonképpen nem is vagyunk annyira messzi az igazságtól, mivel maga a rendszer felvázolja azokat a lehetőségeket, amikkel végre tudja hajtani a feladatot, kikerülve az egyes akadályokat.

A mozgástervezés a robotok számára a leginkább számításigényesebb feladat és tulajdonképpen akármilyen lapkával is próbálkoztak eddig a tervezők igazán valós idejűnek ható válaszokat még nem sikerült kipréselni a rendszerekből. Utóbbi persze csak számítási teljesítmény kérdése, de meg lehet ezt közelíteni másképp is, és nem kell az általánosan programozható megoldásokra építeni. A Duke Egyetem Duke Robotics csoportja előállt egy konstrukcióval, amely a robot mozgástervezését vizsgálja, és azt nem szoftveresen, hanem hardveresen hajtja végre. Utóbbinak hála három nagyságrenddel gyorsult a feldolgozás, miközben a működéshez szükséges energia a huszadára csökkent.

A fenti videóban látható a tesztrendszer, amelyben a hardveres mozgástervezés egy FPGA-ra került implementálásra. Ebből nyilván később tervezhető ASIC is. A megfelelő vezérlés alapeleme a négy darab kamera, amely megfelelő mélységtérképet állít elő a rendszer számára. Ilyen formában egy háromdimenziós alakzatot kap az FPGA-ra implementált mozgástervező, amiből ki tudja számolni, hogy a feladatot miképp kell végrehajtani úgy, hogy ne ütközzön a robotkar az elhelyezett tárgyakkal. Az eredmény igen jónak mondható, mivel látszatra úgy néz ki, mintha egy előre betáplált mozgást végezne a kar, de valójában ezt valós időben számolja ki, ráadásul iszonyatosan gyorsan.

Persze a valós működés nem ennyire egyszerű. Egyrészt a robotkar mozgása a háromdimenziós térben igen tág térfogatot fedhet le, vagyis arra is kell figyelni, hogy a teljes kar ne ütközzön bele semmibe. Ez az amivel a legnehezebb boldogulni, így a Duke Robotics csoport is használ némi előszámítást. A rendszer elhelyezése után érdemes egy háromdimenziósan lemodellezi a teret, amiről készül egy virtuális háló. Nagyjából 150 ezer csomópont elég ahhoz, hogy megfelelően modellezni lehessen a mozgásokat, de ennyi éllel viszont nagyon nehéz számolni. Ezt leginkább ezerre érdemes csökkenteni és itt ki lehet használni, hogy a robot speciális feladatot lát el, vagyis egyáltalán nem szükséges, hogy minden csomópontot figyelembe kelljen venni. Kell tehát egy virtuális tesztelési fázis, amikor az adott virtuális hálóból eldobásra kerül a csomópontok nagyon nagy többsége. A lehetséges utakat kivizsgálva – ebből akár tízezer is lehet – felállítható egy olyan térbeli térkép, ami már csak nagyjából ezer csomópontot vesz számításba, és a tér jó részét a rendszer vagy eldobta, vagy olyan térfogati részként értékelte, ahol akadály van.

Az egész innen egyszerűvé válik, mivel minden feladatnál le kell szűkíteni a lehetőségeket a lehetséges utakra, majd a szűrőn átment utak közül kiválasztani a legrövidebbet. A konstrukció előnye innen már tényleg csak a sebesség, ugyanis az FPGA-ba épített hardveres mozgástervezés, párhuzamosan történhet, vagyis lehetőség szerint az a jó, ha mélységtérképből minél több pixel kerül a rendszerbe, ugyanis az lineárisan növeli a tervezés hatékonyságát, csökkentve a megfelelő út megtaláláshoz szükséges időt.

A Duke Robotics csoport mérései szerint a fenti rendszerrel egy pixel feldolgozása 50 ezredmásodpercbe kerül, és a fenti videóba bemutatott feladatok feldolgozásának teljes ideje nagyjából 600 mikromásodperc volt. Összehasonlításképpen ugyanezt a munkát egy 3,5 GHz-es órajelen üzemelő négymagos Intel Xeon 16 GB memóriával 800 000 mikromásodperc alatt oldotta volna meg, vagyis az előrelépés igen nagy. A gyorsulás lehetősége a feladat komplexitásának növekedésével még tovább javul, ugyanis a hardveres mozgástervezésnél a pixelekre lebontott feldolgozás ideje állandóan 50 ezredmásodperc körüli, míg a szoftveres mozgástervezésnél ez nincs így, vagyis ott akár másodpercekig is csak gondolkodik a robot, mielőtt megmozdulna.

Azóta történt