Ez egy részletes bemutató arról, hogyan lehet megvalósítani a robotot a semmiből, és lehetőséget ad arra, hogy önállóan navigáljon egy ismeretlen környezetben.
A robotikával kapcsolatos összes tipikus érv a következőkre terjed ki: mechanika , elektronika és programozás .
Az egész robotot úgy tervezték, hogy bárki otthon készítsen profi (vagyis drága) eszközöket és eszközöket.
Az agyi fórum (dsNav ) egy kódoló és motorvezérlő képességekkel rendelkező Microchip dsPIC33 DSC alapú. A pozíciót odometria (kódoló) segítségével számítják ki külső referencia (halott számítás) nélkül.
A végső változatban néhány más vezérlőt használnak az érzékelők (Arduino) vezérlésére és analóg érzékelők (PSoC) kezelésére.
kellékek:
1. lépés: Az alapplatform
Példa arra, hogy miként lehet felépíteni egy nagyon egyszerű robotfelületet, melynek alkatrészei és alkatrészei könnyen megtalálhatók mindenhol, professzionális eszközök és felszerelések nélkül, és a mechanikai munkákkal kapcsolatos speciális készségek nélkül.
A bázis mérete lehetővé teszi a robotkategóriák különböző kategóriáiban való használatát: Explorer, Line Follower, Can Collector, stb.
2. lépés: Mit akarunk megszerezni? és hogyan?
Ez a robot, mivel a hobbisták által épített robotok többsége differenciális kormányzási rendszeren alapul, lehetővé teszi számunkra, hogy minden pillanatban megismerjük a robot pozíciókoordinátáit, egyszerűen tudva, hogy az egyes keretek által lefedett terület elegendő időközönként elegendő.
Ezt a halott számítási navigációs rendszert a halmozott hiba befolyásolja; a mérési pontosságnak magasnak kell lennie ahhoz, hogy hosszú út után kis hibahatár legyen. Tehát, miután jó eredményeket értünk el a házi kódolókkal, úgy döntöttem, hogy valami jobbat használok: egy pár 12V-200 fordulat / perc sebességű motorok, amelyek egy pár 300 gróf fordulatszám (Cpr) kódolóhoz csatlakoznak, mindkettő elérhető számos internetes robotika üzletben.
Alapelvek
Ahhoz, hogy a 300 cpr kódoló által generált összes impulzus egy 3000 fordulat / perc motoron 4x dekódolási módszerrel (120 kHz) elkapjon, minden kódolóhoz külön hardver szükséges (QEI = Quadrature Encoder Interface). Kettős PIC18F2431-es kísérletezés után megállapítottam, hogy a helyes frissítés dsPIC. Kezdetben két dsPIC30F4012 motorvezérlő volt a kerekek pozíciójának és sebességének szabályozására, odometria elvégzésére és a két motor adataira egy dsPIC30F3013-ra. Ez az általános célú DSC elég erős ahhoz, hogy adatokat gyűjtsön, végezzen néhány trigonometriát, hogy kiszámítsa a pozíciókoordinátákat, és tárolja az érintett útvonalhoz kapcsolódó adatokat annak érdekében, hogy egy mezőtérképet kapjon, mindegyik nagyon magas sebességgel.
Amikor a tábla és a programok majdnem befejeződtek, a Microchip egy új, erőteljes 28-tűs SPDIP-et hozott létre a dsPIC33F sorozatban mind a motorvezérlő (MC), mind az általános célú (GP) változatokhoz. Ezek lényegesen gyorsabbak, mint a dsPIC30F, sokkal több rendelkezésre álló programmemóriát és RAM-ot (hasznosak a terepi leképezéshez), kevesebb energiát igényelnek (akkumulátoros működtetésű robot), és ezek DMA-képességei leegyszerűsítik az I / O műveleteket.
A legfontosabb, hogy ezek az első Microchip motorvezérlők, amelyek két QEI-vel rendelkeznek ugyanazon a chipen. Indítsuk újra az új portot! A logikai blokkdiagram hasonló az előző táblához , de a hardver és a szoftver sokkal egyszerűbb Csak egy háromdimenziós DSC-t használhatok . A navigációs paraméterek cseréjéhez nincs szükség nagy sebességű kommunikációra a felügyelő és a motorvezérlők között. Minden folyamat egyszerűen szinkronizálható, mert ugyanazon a chipen van. A dsPIC33F sorozat perifériás pálca kiválasztási képessége tovább egyszerűsíti a PCB-t, lehetővé téve a perifériák belső csatlakozását és nagyobb rugalmasságot.
Ez a „dsPIC alapú navigációs vezérlőkártya” -hoz vezet dsNavCon röviden. Ezt a táblát egy összetettebb rendszer részeként tervezték. Egy teljes felfedező robotban más táblák ellenőrzik a hangot, a fényt, a gázérzékelőket, valamint a lökhárítót és az ultrahangos távolságmérőket, hogy megtalálják a célokat és elkerüljék az akadályokat.
Önálló fórumként dsNavCon egy egyszerű „vonalkövető” robothoz is használható, valami bonyolultabb robothoz, mint egy odometriás és halott számítási versenyhez, vagy egy úgynevezett „can can robot” -hoz (a versenyek gyűjtéséhez). Még mindig rengeteg szabad programmemória van ahhoz, hogy kódokat adjon hozzá az ilyen feladatokhoz. Kisebb vagy semmilyen változás nélkül a szoftverben, önállóan is használható egy távvezérelt járműhöz, a kétirányú RF modem használatával valamilyen intelligens távirányítóval. Ez a távirányító olyan komplex parancsokat küldhet, mint a „FWD 1m mozgatása”, „forduljon 15 ° -kal balra”, „futtassa az FWD-t 50 cm / s sebességgel”, „menjen az X, Y koordinátákba”, vagy valami hasonlóra.
A táblát és a robotot is úgy tervezték, hogy bárki otthon készítsen professzionális eszközöket és eszközöket.
3. lépés: A nyílt forráskódú hardver
Blokk diagramm
A navigációs vezérlő alrendszer a dsNav mint a rendszer „intelligens” kártyája és egy L298-as kettős H-hídlemez a 12V-os motorok vezérlésére (Hsiang Neng HN-GH12-1634TR). A mozgás-visszajelzés egy pár 300 cpr kódolóból (US digital e4p-300-079-ht) származik.
A külső világgal való kommunikáció a két UART soros interfészen keresztül történik; az egyik a telemetria és a másik az adatok érzékelőkről történő beszerzése. Az XBee modul csatlakoztatható az UART1 vagy UART2-hez JP1 és JP2 jumpereken keresztül. A J1 és J16 aljzatok más csatlakozásokhoz is rendelkezésre állnak. A COMM1 port (J16) is használható az I2C kommunikációhoz a dsPIC33F sorozat perifériás pin kiválasztási képességének köszönhetően.
Az Eagle formátumban található eredeti vázlatos diagram itt található:
http://www.guiott.com/Rino/dsNavCon33/dsNavCon33_Eagle_project/DsPid33sch.zip
Amint láthatod, a vázlat olyan egyszerű, hogy egy tökéletes táblán végrehajtható, mint én. Ha nem akarja használni ezt a rendszert, és nem szeretné megvalósítani saját PCB-jét, az eredeti munkám alapján működő kereskedelmi fórum, amely teljes mértékben kompatibilis a nyílt forráskódú szoftveremmel, a következő címen érhető el: http: //www.robot-italy .com / product_info.php? products_id = 1564
4. lépés: A nyílt forráskódú szoftver
A szoftvert MPLAB® free IDE-vel fejlesztették ki és MPLAB® C30 fordítóval írták (akár ingyenes vagy hallgatói változatban is), mindkettő (természetesen) a Microchip által:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=81
Az egész projekt nyílt forráskódként elérhető a Google-kódban
http://code.google.com/p/dspid33/
Kérjük, olvassa el a legfrissebb verziót, megjegyzést, leírást stb.
A programot lépésről lépésre írják le a kódon belül. Annak érdekében, hogy magas szintű kommentálást és olvashatóbb kódot kapjunk, minden jelentős ponton zárójelben van egy szám (pl .: 7), mint egy külső fájl (azaz: descrEng.txt) az MPLAB projektben .
Az ábra a dsNav tábla vezérlési eljárásainak és a projekt alapján alkalmazott navigációs stratégiák átfogó felépítését mutatja.
A motorvezérlők fekete dobozokként láthatók, amelyek gondoskodnak a kerekek sebességéről. A program felügyeleti része elküldi a referenciasebességet (VeldDesX: kívánt sebesség). A mikrokontroller bemeneti rögzítő moduljai impulzusokat kapnak a motor tengelyéhez csatlakoztatott kódolókból, és kiszámítják a motorok fordulatszámát (VelMesX: mért sebesség). Az egyes 1 ms-os értékek kombinálása a PID vezérlés "Speed PID" -jében a megfelelő PWM-értéket kapjuk, hogy megtartsuk az egyes kerekek kívánt sebességét.
A QEI (Quadrature Encoder Interface) modulok megkapják az A és B impulzusokat a kódolóktól, és visszaadják a felügyelőnek az utazás irányát és az impulzusok számát 4x módban (az A jel és a B jel emelkedő és leeső szélének számítása: 2 x 2 = 4).
Az impulzusok számát megszorozzuk egy K-vel, amely jelzi az egyes kódolóimpulzusok által megtett helyet, és a jobb és bal kerekek által megtett távolságot minden 10 ms-ban kapjuk meg. A felügyelő ötvözi ezt az utazási információt és alkalmazza a halott számítási eljárást annak érdekében, hogy megkapja a bot mért pozíciókoordinátáit: Xmes, Ymes, θMes (tájolási szög).
A felügyelő külső navigációs parancsot kap a soros interfész (telemetria) segítségével.
Különböző stratégiák alkalmazhatók:
A - adott sebességgel utazni egy adott irányban (VelDes, θDes).
B - az XDes, YDes koordinátákkal egy adott pont felé utazni.
C - egy adott távolságon egy adott irányban (DistDes, θDes) utazni.
A mód : az 1. pozícióban lévő "logikai vezérlő kapcsolók" esetén a felügyeleti funkciók csak a "Szög PID" vezérlőt használják. Ez a kívánt angleDes szöget és a mérési szöget θMesometria módszerrel kiszámított szöggel ötvözi annak érdekében, hogy a függőleges tengely körüli ω forgási szögsebesség értékét az orientációs hiba kijavításához szükséges.
A DeltaV értéke arányos a ω-val. Ez hozzáadódik a VelDes-hez, hogy megkapja a bal oldali kerék sebességét, és kivonja a VelDes-be, hogy megkapja a jobb kerék sebességét, hogy megtartsa a θDes értéknek megfelelő címet, míg a robot középpontja még mindig VelDes sebességgel halad.
B mód : a "logikai vezérlőkapcsolók" a 2. pozícióban a kívánt sebesség VelDes-t a "Dist PID" PID vezérléssel számítják ki, és az A. módban használják. Ennek a PID-nek (DistMes) mért bemenete a következő: az aktuális koordinátákat és a cél koordinátákat. A kívánt angleDes tájolási szög ugyanazt az eljárást is eredményezi, és a referencia bemenetként használja a "Szög PID" -et. A "Dist PID" referencia bemenete 0, ami azt jelenti, hogy elérjük a célállomást. A rendelkezésre álló ω és VelDes esetén a kerekek fordulatszám-szabályozása az A. üzemmódban fut.
C mód : a "logikai vezérlőkapcsolók" a 2. pozícióban az Xdes, Ydes rendeltetési helyek koordinátái az elején kerülnek kiszámításra a DistDes, θDes bemeneti paraméterek függvényében. Ezután minden olyan, mint a B módban
5. lépés: A szoftver részletei: sebességszabályozás és egyéb alapvető funkciók
A program tele van megszakított meghajtású . Az indításkor az inicializálás után a program egy nagyon egyszerű főhurokba lép, amely állami gépként működik. A főhurokban a program ellenőrzi a külső események által engedélyezett jelzéseket, és az értékeiknek megfelelően a relatív állapotba lép.
Mivel ez egy nagyon egyszerű szövetkezet.Valós idejű operációs rendszer , "minden egyes rutint a lehető legrövidebb időn belül kell végrehajtani, felszabadítva a rendszert, hogy vigyázzon a nagyon gyakori megszakításokra.
Nincs „várakozás” és nincs késés a kódban. Amikor csak lehetséges, megszakításokat használnak, különösen a lassú műveletekhez, mint például a karakterláncok átvitele vagy fogadása. Az UART-kommunikáció a dsPIC33F DMA-képességeinek előnyeit használja a CPU-idő megtakarítására a hardveres "piszkos" munka elvégzésében.
A dsPIC33FJ128MC802 rendszeren használt perifériák:
- QEI-k az utazott útvonal kiszámításához.
- Input Capture (IC) a sebesség kiszámításához.
- A / D átalakítók motoráram olvasásához.
- Továbbfejlesztett PWM-ek a motorok meghajtásához.
- UART-ok a külső világgal való kommunikációhoz
QEI modulok arra használják, hogy tudják, hogy a kerekek mennyi utazottak és milyen irányban. Ezt az értéket 1 ms-onként változóan kumuláljuk, és kérésére elküldi a felügyelő funkcióinak. Az érték elküldése után a változók visszaállnak.
A sebességet minden kódoló impulzusán mérjük, az alábbiakban leírtak szerint. Minden 1 ms-ban kiszámítja az átlagsebességet a minták átlagolásával, végrehajtja a PID algoritmust, és korrigálja a motor fordulatszámát az eredményével, a PWM munkaciklusának megváltoztatásával. A C30 PID könyvtár alkalmazás részletes leírását lásd: Mikrochip kód példa: CE019 - Proporcionális integrált származékos (PID) vezérlők használata zárt hurkú vezérlőrendszerekben. http://ww1.microchip.com/downloads/en/DeviceDoc/CE019_PID.zip
A motorok sebességváltozásai zökkenőmentesek, gyorsulnak vagy lassulnak egy emelkedő vagy lejtő ferde rámpával, hogy elkerülhető legyen a nehéz mechanikai feszültség és a kerékcsúszás, amely hibákat okozhat az odometriában. A lassulás gyorsabb, mint a gyorsulás, hogy elkerülje a fékezés során az ütközések akadályait.
IC , a bemeneti rögzítő modulokat arra használják, hogy mérjék a kódoló által generált két impulzus között eltelt időt, ami azt jelenti, hogy a kerekek jól ismert rögzített mennyiségű térben utaztak (állandó) SPACE_ENC ). A QEA-val párhuzamosan csatlakoztatva (a DSPIC33F Perifériás Pin Kiválasztási képességének köszönhetően a DSC-hez belül), az eltelt időt a jeladók jelek emelkedő szélén rögzítik. A TIMER2 szabadon futó üzemmódban használható. Minden IC-megszakításnál a TMR2 aktuális értéke tárolódik, és az előző értékét levonják belőle; ez az impulzusidő. Ezután az aktuális érték lesz az előző érték, várva a következő megszakítást. A TMR2 zászlóját ellenőrizni kell, hogy megtudja, hogy a 16-bites regiszterben történt-e túlcsordulás. Ha igen, a 0xFFFF és az előző minta közötti különbséget hozzá kell adni az aktuális értékhez. A mintákat algebrai módon adjuk hozzá IcPeriod változó szerint _UPDN bit, hogy meghatározza a sebesség irányát is. Ez az egyik javasolt módszer A Microchip alkalmazási megjegyzés: AN545 .
A változó IcIndx tartalmazza a hozzáadott minták számát IcPeriod .
Minden 1 mp-ben az átlagos sebességet úgy számítjuk ki, mint V = Tér / Idő
hol Space = SPACE_ENC • IcIndx
(= egy kódoló impulzus által lefedett terület • impulzusok száma)
és Idő = Harmadik országok • IcPeriod
(= egyetlen TMR időszak • az időszakok összegzése).
Single_TMR_period = hozzájárulni egyes = 1 / deviza (órajel gyakorisága).
Így V = KVEL • (IcIndx / IcPeriod)
hol KVEL = SPACE_ENC • deviza sebessége m / s.
A váltás 15 bit maradt KVEL const ( KvelLong = KVEL << 15 ) a sebességet már frakcionális formátumban számítják ki (akkor is, ha csak egész változókat használnak), amelyek a PID rutinban való használatra készek. Részletesebb leírást az MPLAB projekt „descrEng.txt” fájljában talál.
A / D átalakítók folyamatosan mérje meg a motorok áramát, tárolja az értékeket a 16 pozícióban lévő ADCBUF pufferekben. Ha a pufferek megteltek, akkor megszakítás történik, és az átlagos értéket minden 1 ms-onként számítják ki.
UART a külsõ parancsok fogadására és a mérések eredményeinek visszaküldésére szolgálnak. A program kommunikációs része állapotgépként működik. Az állapotváltozókat a műveletek sorrendben történő végrehajtására használják. A nagyon egyszerű és gyors megszakítási szolgáltatás rutinok (ISR) minden egyes bájtot hoznak létre vagy helyeznek el egy pufferből, és beállítják a megfelelő jelzőket, hogy a megfelelő funkciót végrehajtsák.
Ha bármilyen hiba lép fel a fogadás során (UART, ellenőrző összeg, elemzési hibák), akkor az állapotváltozó negatív számra van állítva, és a piros LED bekapcsolva külsőleg kommunikálja ezt a hibaállapotot. Az esetleges hibák teljes listáját az MPLAB projekt „descrEng.txt” fájlja tartalmazza.
A kézfogáshoz használt protokoll fizikai réteg független , és az I2C vagy RS485 buszon is használható kommunikációhoz.
A első réteg a dsPIC perifériás interfész vezérli. A keret vagy a túlterhelési hibák (UART) vagy ütközések (I2C) a hardver által észleltek, a megfelelő jelzőtáblával.
A második réteg az ISR-rutinok kezelik. Az RX-puffert az interfészektől kapott bájtokkal töltik meg. Azt is felismerték a puffer túlcsordulását és a túlterhelést.
Az UartRx vagy az UartRx2 funkciók kezelik a harmadik réteg . Amint már leírtuk (lásd még az áramlási diagramokat), ezek a rutinok állami gépként működnek, bájtokat kapnak a pufferből és dekódolják a parancsláncot.
A bájtokat egy második és harmadik réteg között (ISR és UartRx függvény) cseréljük körkörös pufferen keresztül. Az ISR bájtot kap, egy tömbben tárolja, és egy mutatót növekszik a tömbre, ha a mutató eléri a tömb végét, amelyet újra elindít. Az UartRx függvénynek saját mutatója van, hogy ugyanazt a tömböt olvassa, növekszik (körkörös módon is), amint a bájt az aktuális RX állapotban dekódolódik. A főhurok az UartRx funkciót hívja meg, amikor az "in" mutató eltér a "out" mutatótól.
Minden parancscsomagot a következők alkotnak:
0 - Fejléc @
1 - ID 0-9 ASCII
2 - Cmd A-Z ASCII
3 - CmdLen N = 1-MAX_RX_BUFF következő bájt (ellenőrző összeg)
4 - Adatok …
…
N-1 - Adatok
N - Ellenőrzőösszeg 0-255, amelyet egyszerűen egy 8 bites változó összeadásával kaptunk meg, az üzenetet alkotó összes bájtot (maga az ellenőrző összeg kizárt).
Ez a réteg szabályozza az időtúllépés és az ellenőrző összeg hibáit, valamint a csomagkonzisztenciát (helyes fejléc, helyes hossz). Ha minden rendben van, lehetővé teszi a Parser rutin (negyedik réteg ) az üzenet dekódolására és a szükséges művelet végrehajtására. Ez a rutin beállítja a megfelelő hibajelzőt, ha a kapott üzenetkód nem ismert.
TMR1 1000 Hz-es időzítőt generál - a program szívverése. Minden TMR1 megszakításánál a belső időzítők frissülnek, az őrszem törlődik, és egy jelző van beállítva, hogy engedélyezze az utazott térértéket kérő funkciót. Minden 10 ms-os „All_Parameters_Ask” funkció (sebesség, pozíció, áram) engedélyezve van.
6. lépés: A szoftver részletei: Odometria és Field Mapping = Hol vagyok?
Amint megvan az információ az egyes kerekek által megtett távolságról egy diszkrét időbeli frissítésben (odometria), akkor a robot pozíciókoordinátáit ugyanazzal a gyakorisággal becsülhetjük külső referencia nélkül (halott számítás).
Néhány elméleti hátteret az odometriával végzett halott számításokról Johann Borenstein könyvében talál:
"Hol vagyok? - A mobil robot pozícionálásának érzékelői és módszerei"
és az alábbi weboldalakon:
http://www.seattlerobotics.org/encoder/200010/dead_reckoning_article.html
Az általános módszer matematikai háttere és mély magyarázata megtalálható a G.W. Lucas papírja A bemutató és elemi trajektormodell a robotkerék-hajtóművek differenciálművezető rendszeréhez, elérhető az interneten:
http://rossum.sourceforge.net/papers/DiffSteer/DiffSteer.html
Néhány egyszerűsített algoritmus ugyanabban a dokumentációban is megtalálható, így a dsPIC33F sorozat matematikai (trigonometrikus) képessége alapján lehetséges a pontos kompromisszum elérése a pontosság és a kidolgozás sebessége között.
A pozíció kiszámításához használt matematika leírása megtalálható az ehhez a lépéshez csatolt képeken. Az első a szimbólumok jelentését mutatja, a második a szimbólumokkal használt képleteket mutatja. Az egyes számítási lépések melletti négyzetekre kattintva rövid leírás látható.
Végül tudjuk, hogy a robot milyen mértékben mozgott az időintervallumban az orientáció delta, az X tengely delta és az Y tengely delta a kartheses referencia mezőben.
Az egyes delta-értékeket saját változójában összegyűjtjük, ismerjük a platform aktuális koordinátáit (pozícióját és tájolását).
A számítási hibák (szétválasztás nullával) és a vezérlési idő pazarlásának elkerülése érdekében előzetesen ellenőrizni kell mind az Sr, mind a Sl változókat. A kvázi-nulla érték meghatározása, amely gondoskodik a minimális mechanikai és számítási megközelítésekről, egyszerűsíthetjük a képleteket, ha a robot egyenes vonalban halad (a jobb oldali kerék által lefedett terület szinte megegyezik a bal kerék keresztezett térével) vagy ha elfordul a függőleges tengelye körül (a jobb oldali kerék által lefedett terület szinte megegyezik a bal oldali kerék által mozgott térrel, hanem ellenkező irányban), ahogy az utolsó képen látható folyamatábrán látható.
Ez a videó egy példa arra, hogy milyen pontossággal szerezhetünk be:
http://www.youtube.com/watch?v=d7KZDPJW5n8
Terepi térképezés
Az előző funkciókkal kiszámított adatokkal egy mező leképezést hajt végre.
Minden Xms, az aktuális pozíció kidolgozását követően, egy terepi leképezést hajt végre, amely az ismeretlen mezőt egy 10 x 10 cm-es cellarácsban osztja el. Az 5 x 5 m-es maximális mezőméret meghatározásával 50 x 50 = 2500 sejt mátrixot kapunk. Mindegyik cellát definiáltuk, összesen 1250 bájtnyi memóriával. Minden cellára tizenhat különböző érték rendelhető:
n = 00 ismeretlen sejt
n = 01 - 10 sejt látogatott n-szer
n = 11 talált akadály
n = 12 gázcél található
n = 13 könnyű célpont található
n = 14 hangjelzés található
A robot bármelyik pozícióból indulhat; ezek a referencia-rendszer referencia-koordinátái (0,0) lesznek.
A terepi térképezés hasznos egy ismeretlen területen a legjobb feltárási stratégia megtalálásához. A robot a mező kevésbé feltárt részéhez irányíthatja (alacsonyabb „n” érték), időt takaríthat meg, ha már nem talál meg kétszer egy már felfedezett célt, megtalálja a legjobb utat, hogy elérje az adott koordinátát, és így tovább.
7. lépés: Távoli konzol
Annak érdekében, hogy könnyen kezelhető legyen, és bármilyen operációs rendszerben jól működhessen, írva van Feldolgozás nyelv:
http://www.processing.org/
A program forráskódja nyílt forráskódként is elérhető a Google Code-on:
http://code.google.com/p/dsnavconconsole/
A … val fő panel (első képek) telemetriát végezhetünk úgy, hogy a rácson a robot által követett útvonalat (az odometria alapján becsült) egy konfigurálható méretmezőben és néhány más fontos értéket olvasunk a dsNav .
A mérők a mért értékeket mutatják:
- A sebesség a +/- 500 mm / s tartományban, a két kerék sebességének középértéke (a platform középpontjának sebessége).
- Mérési áram mA-ban (a két motor áramának összege).
- Mérési szög, amelyet a kilométer-mérés kiterjeszt.
Más paneleket használnak a robot paramétereinek konfigurálására és egy meghatározott útvonal követésére a robotba (ha szükséges). Egy fontos panel, legalábbis a robot fejlesztése során, a részletes panel (második kép), amely az egyes kerekek sebességét mutatja valós időben, nagyon hasznos minden paraméter kalibrálásához.
A központi rács nézet a webkamera nézetével vezérelhető, még akkor is, ha a nézet szerint a robot követ.
Ebben a videóban egy gyakorlati példa erre a konzolra:
http://www.youtube.com/watch?v=OPiaMkCJ-r0
