Próbáld megérteni az én gondolatmenetem!
Adott a feladat és annak megoldását fogom leírni a folyamatában.

Egyelőre nem létezik semmiféle robot, kocsi. A feladatmeghatározás teljesen determinálja a szakmai részt. Mozgatni kell a kocsit, kanyarodni kell tudni, érzékelni a környezetét, az érzékelt információk birtokában útirányt kell választania és nem utolsó sorban a két rögzített pont között mozogva az abszolút helyzetével is tisztában kell lennie.
Ezek alapján ide sorolható szakmai témaként egy kinetikus modell elemzése, vezérlési és szabályozási feladatok megvalósítása célszerűen választott áramkörökkel, szoftvertechnológia, számítógép architekturális kialakítása (mert ugye ide kevés pár logikai kapu), mechanikai kivitel, optika, és egy csomó matematikai apparátus... térgeometria, gráfok, lágy halmazok, neurális hálók ...hogy időlegesen én is csatlakozzam néhány előttem szóló szóhasználatához.

Ezek elég kézzelfogható feladatok egyéb környezeti tényezők ismerete nélkül is. Mivel nem extrém körülmények között kell működnie, így egyszerű vízszintes, szilárd burkolaton történő mozgásra tervezem. Nem az a cél, hogy a robot elmenjen vízért , hanem a demonstráció... Hogyan lehet megcsinálni?!

A szakmai rész például azt takarja, hogyan oldanád meg konkrétan a pozíció meghatározását a mozgó objektumnak? Milyen hardverrel, milyen programmal? Hogyan illeszkedik a meghajtáshoz, milyen logikai kapcsolaton keresztül? Természetesen tárgykódig és utolsó csavarig megvalósítva, nem elvi szinten!

Azt viszont ne várd, hogy egy hét alatt választ kapsz a kérdésekre. Ha ötleted van hallgatom, gyorsabban haladunk! Megbeszéljük, kielemezzük mit miért! De csak a konkrét ötletet. A "mi lenne ha..." elméletekből nem lehet megépíteni!

Egyetértek. Sőt azért mert ez a téma hozzám nem áll közel az nem azt jelenti, hogy én a másik szellemi tejesítményét nem értékelem. Ebből személyesen a lassan 30 év alatt kaptam eleget, sőt kapok a mai napig is.

Sajnos még ezek alapján sem egyértelmű a feladat. Ezért megint kénytelen vagyok feltételezésekbe bocsátkozni a tisztánlátás érdekében. Szerintem Te voltaképp valamilyen módszert szeretnél kidolgozni (vagy ezt a folyamatot bemutatni) az A-ból B-be való eljutásra, azaz ez tulajdonképp egy iskolapélda. Ebben az esetben a környezet és magának a robotnak a felépítése kissé háttérbe szorítható, de azért nem teljesen. Maradjunk akkor a földön, egyszerű 2D mozgással? Vehetjük-e az alapterepet pl. teljesen síknak és a robot hajtása szempontjából akadálymentesnek (pl. egy asztallap)? Ilyen terepen adott, fix akadályok érzékeléséhez tökéletesen elég egy sor megfelelően elhelyezett mechanikus érzékelő.



Mit lehet ehhez felhasználni? Adott-e legalább 2 ismert helyzetű pont a terepen? Lehet rájuk jeladót szerelni? Körbe van-e zárva az alapterep, magasabban, mint az akadályok? Mert ha igen, ezt is ki lehet használni. Vagy megengedett-e az, hogy a terepet egy négyzethálóként fogjuk fel, ezáltal "diszkretizálva" némileg a mozgást? Ahhoz, hogy legyen A és B pont, ami között a robotnak mozognia kell, muszáj léteznie valamilyen viszonyítási rendszernek, amiben e két pont helyzetét meg tudjuk adni. Mi (legyen) ez a rendszer?

Kis türelmet kérek, hamarosan folytatom!

G

Hi!
Szeretnék csinálni egy hardveres neurális hálót.
(Kísérlet képpen, tanulási céllal.) Olvastam, hogy van egy "memrisztor" nevű alkatrész, amit direkt erre találtak ki. (Egy biológiai idegsejt működését szimulálja.) Ilyet lehet kapni valahol, vagy más alkatrészekből kell összerakni, ha igen hogyan és mi kell hozzá?

Na mi van, hülyeséget kérdeztem, vagy ezt a topicot senki sem nézegeti?

Szia!

Nem szívesen szólok hozzá a témához, mivel nem vagyok otthon benne, hülyeséget meg nem akarok írni. De maradjunk annyiban, hogy szerintem bőven vannak, akik olvassák ezt a topikot. Gondolom te sem várod el, hogy mindenki egyesével beírja: ,,én nem tudom a választ".

Egyébként magáról a memrisztorról csak annyit, hogy az még csak egy tesztfázisban lévő, meglehetősen kiforratlan technika. Bár már 1971-ben kitalálták, ennek ellenére csak nemrégiben sikerült működő prototípust produkálni belőle. Gondolom ezek után mondanom sem kell, hogy ilyesmi az átlagember számára jelenleg nem elérhető, és nem is lesz az még jó darabig.

A kettőből több mint egy igaz

A szoftveres szimuláció miért nem elég?
Azzal is egészen jól el lehet lenni...

"Gondolom ezek után mondanom sem kell, hogy ilyesmi az átlagember számára jelenleg nem elérhető, és nem is lesz az még jó darabig."

Kár... Azt én is olvastam, hogy 71-ben fedezték fel, gondoltam azóta már jutottak valamire.

Ha jól tudom ez egy darab neuront szimulál, a szoftverben meg szinte bármennyi lehet. -> a szoftver olcsóbb
De ha softveresen is megoldható a dolog, akkor mire jó a memrisztor? Ez többet tud valamivel, mint a szoftver?

Hi!
Nemrég csináltam egy nagyon egyszerű példaprogit VisualBasicben, összesen 5 "neuronból" állt. Persze csak a dolog szemléltetésére, (biosz orin megmutatni) volt jó.
PIC-kel, robotvezérléssel érdemes kísérletezni ilyesmivel? Kijöhet valami működőképes konstrukció, pl ami kikerüli a tárgyakat? Kb hány virtuális neuron szükséges egy 'egyszerű' robot vezérléséhez (minimum)?

Több mint egy év telt el.... A kezdeti lelkesedésemet kissé letörte az indulatos reakciólavina, ám a szünet közvetlenül inkább annak köszönhető, hogy egyéb elfoglaltságaim kitöltötték minden időmet. Nem adtam fel az eredeti elképzelésem, hogy egy "robotot" építsek. Talán szükség is volt erre az időre, mivel időközben változtak a dolgok. Nem az ötlet, hanem a megvalósítás koncepciója.

Feleleveníteném az elképzelést:
"A célom az, hogy párhuzamosan az említett másik témakörrel, megvizsgáljuk egy konkrét feladat megoldása kapcsán, milyen nehézségekkel kell szembesülni munkánk során.
Ez a konkrét példa egy autonóm rendszer vizsgálata, egy roboté, amelyik önállóan képes a térben mozogni, tájékozódni, döntést hozni.
Hogyan lát? Hogyan mozog? Hogyan dönt? Mi a mozgatórugó?"

A fenti idézet a megnyitó gondolatokból való. A cél tehát egy olyan folyamat bemutatása, melynek végeredménye egy önállóan mozogni képes robot. Ez persze csak az egyik megoldás a sok lehetséges közül, de reményeim szerint sok olyan közbenső dologgal foglalkozhatunk amely más irányban is hasznos ismereteket nyújthat az olvasó számára.

Változatlanul csak az ötlet váza van meg, még nem tudok konkrétumokkal szolgálni. A részletek itt bontakoznak majd ki. Első lépésben megpróbálom a feladatra alkalmas modell leírását. Annak alapján - különféle mechanikai, dinamikai tulajdonságok - konkrét fizikai formába öntjük a robot megjelenését, mely a további lehetőségeit, viselkedését részben determinálja.
A koncepció változásáról pár szóban. Az eredeti halvány körvonal egy olyan robotot ábrázolt, mely egy célhardver segítségével navigál egy ismeretlen terepen. Időközben, munkáimból merítve ötleteket, kibővítettem ezt azzal, hogy egy sokkal nagyobb szabadsági fokkal kívánom ellátni a robotot. Autonóm rendszerként is képes lesz mozogni, navigálni, ám nyilvános hálózaton keresztül a "végeredmény" elérhető lesz. Egy erre a célra létrehozott web-portálon keresztül teszem elérhetővé a felhasználói felületét, mely által egy valós terepi környezetben lehet tesztelni tulajdonságait. A regisztrált felhasználó meghatározott "robotidőben" egy GUI-n keresztül követheti nyomon a robot mozgását, kamerán keresztül valós idejű képet látva a környezetéről. A GUI adta lehetőségekkel a robot mozgásába be lehet avatkozni.

Teszem ezt egyrészt a saját kedvtelésem érdekében, másrészt azért, hogy az érdeklődőknek esetleg plusz ötletet, ismeretet adhassak. Szeretném bemutatni milyen komplex feladatot képez ez az "egyszerű" művelet (A-ból, B-be jutás). Az egyes érintett részek a teljesség igénye nélkül: fizikai objektumok kinetikai viselkedése - a felépítmény függvényében milyen bonyolultságú a robot irányítása; vektoralgebra - hogyan lehet tájékozódni a térben; mozgatás - milyen hajtás szükséges; környezet érzékelés - optikai letapogatás, képanalízis; akadálykerülés - milyen döntési algoritmusok szükségesek; kommunikáció - nyilvános adatátviteli hálózatok, TCP/IP stack alkalmazása; beavatkozás, telemetria - grafikus felhasználói interfész létrehozása(GUI); egyes hardver alkotórészek integrálása - "fedélzeti számítógép" és operációs rendszere. Része lesz a leírásnak az egyes részáramkörök tervezése, programozása is.

Ami nem célja az írásomnak az, hogy elvi, filozófiai eldöntendő kérdésekben választ adjak.

Változatlanul érdeklődve és figyelemmel hallgatok meg minden barátságos hozzászólást, ötletet amely építő jellegű esetleges kritikai tartalma ellenére is. Ugyancsak szívesen válaszolok a felmerült kérdésekre, ha tudok. És persze szívesen fogadok ötleteket, amelyeket be is építhetünk, ha arra érdemesek. Végül: szeretném ha ez a topik nem csak monológ lenne részemről, hanem ehhez beszélgető társakat is találnék.

Azért ezek a területek önmagukban is nehéz emberpróbáló feladatok, melyek megtervezése, megvalósítása, leprogramozása stb. önmagukban is egész embert (embereket) ígényelnek. Méghozzá nagyon speciális szakembereket. Akiknek hetek, hónapok munkájába telne a feladatuk megvalósítása. A munkát mindvégig koordinálni kell, leginkább a részfeladatok kompatibilitása érdekében. Majd ezután lehetne összerakni a projektet. Robot elkészítése, elindítása, weblap beállítása, adatok feldolgozása, statisztika stb. Szóval ez afféle kutatóközpontba illő feladat...
Szerintem egy fórumon nehéz ezt megvalósítani.
Persze talán ha kellőképen lebontanánk a feladatokat, és sikerülne azokat konkretizálni, akkor valószinűleg minden feladatra akadna itt megfelelő szakember. Viszont az, hogy valaki koordinálja a projektet, és konkrét tevékenységeket fogalmazzon meg az elkerülhetetlen. De talán ezt már mondtuk az elején is. Én mindenesetre kíváncsian figyelem a történéseket!

Hat nem kis feladatra vallalkoztal! Minden elismeresem! Remelem sikerul is megvalositanod es publikussa is teszed a teljes fejlesztest.
En is hasonlo cipoben jarok, persze en nem vallalkoznek arra, hogy egy ilyen feladatot egyszerre megoldjak.
Nekem a tavalyi Magyarokamarson versenyfeladat ( Bővebben: Link ) tette a bogarat a fulembe. Elkezdtem gondolkodni azon hogy en hogyan is oldanam meg a feladatot. Kb. 2 eve kezdtem el a mikrovezerlokkel es a robotikaval hobbi szinten foglalkozni, es mivel nincs mernoki vegzettsegem, akkor ez meg nekem megoldhatatlan feladatot jelentett. Utanaolvasgatva a dolgoknak, fokozatosan lepesrol-lepesre haladva tanultam egyre tobbet. (Ez a folyamat kovetheto nyomon itt a Hobbielektronikan kozolt robotos cikkeimben is). Most mar azert eleg sok reszfeladatot meg tudok oldani, nehanyrol meg meg mindig fogalmam sincs.
Visszaterve a te robotodra, en ugy indulnek neki, hogy eloszor is tisztaznam hogy milyen terepen is akarod majd hasznalni, mert az egesz meghajtas es mechanika attol fog fuggeni (epuleten belul, egyszintes/tobbszintes (lepcsojarasi kepesseg?), szabadban, foldon, vizen, levegoben...).
Epitenek egy egyszeru alapot negykerek meghajtassal (4 korkorositett RC szervoval). Ez pillanatok alatt osszerakhato, es egyszeruen iranyithato.
A tajekozodashoz mindenkeppen robot visiont hasznalnek (majd ha egyszer jobban utananezek es megtenulom...). Ahol kulonfele eldetektalasi modszerekkel meghatarozhato a targyak helyzete es tavolsaga (az hogy milyen algoritmus lenne a legcelravezetobb, az megint csak a tereptol fugg).
Az alabbi linkeken nehany hasznos robotvision-nal foglalkozo rovid ismerteto talalhato (bar szerintem teneked nem fog semmi ujat mondani, de azert irom ide, hatha mast is erdekel):
Computer vision 1
Computer vision 2
Computer vision 3
A kepfeldolgozashoz kello nagy szamitasi kapacitas miatt en mindenkeppen egy kis netbook-ot hasznalnek kozponti vezerlonek. Mivel a fenti kepelemzo algoritmusok leprogramozasa nekem szinte lehetetlen feladat (informatikus vegzettsegem sincs...), en a Roborealm programmal vegeznem a kepelemzest.
Az alabbi linkeken kulonfele peldafeladatok megoldasa lathato:
Targy kikerules/erzekeles
Navigacio
Labirintus
Vonalkovetes
Targykovetes
Ha a kornyezet erzekelese mar megy, akkor jonne a terkepezes valami ehhez hasonlo algoritmussal:
Hullamfront algoritmus
Arrol hogy ezt hogyan lehetne a neten keresztul nyomonkovetni es iranyitani, na arrol halvany lila gozom sincs sajnos.
Szoval roviden en igy kozelitenem meg az altalad felvazolt problemat.

A leírás folyamata óhatatlanul is megszakad kisebb-rövidebb időre. Van úgy, hogy egy hozzászólás olyan dolgokat vet fel amelyre később szándékoztam volna rátérni. Ezáltal óhatatlanul is befolyásolhatják a leírás sorrendiségét, amely a közérthetőség miatt azt gondolom sok esetben előnyös. Amikor csak lehetőségem van rá - ha nem érinti a logikai sorrendet -, figyelembe is veszem. Mint most a két utóbbit.

Nyilvánvaló, hogy nem írás közben gondolom végig az egyes fázisokat. Legalábbis ami a főbb egységeket érinti. Így már korábban elhatároztam, hogy nem bonyolítom túl a mechanika felépítését, hiszen nem az a cél. Ennek megfelelően kerekes felépítést választottam. Az 1. ábra a lehetséges elrendezések közül mutat be néhányat. A kétkerekű változatok nem jönnek számításba.

1. ábra

A hangsúly nem az egyensúlyozáson van, hanem a struktúrán. A négykerekű változatot ugyanúgy elvetettem. Választásom egy háromkerekű elrendezésre esett, két független hajtott és egy szabadon elforduló kereket tartalmazó változatra. Számomra ez a szimpatikus és ezen változat hajtását találtam a legjobbnak a robot mozgatásához. A meghajtó kerekeket egyenáramú kommutátoros motorral egybeépített hajtómű forgatja. A független meghajtás lehetőséget ad a jó manőverezésre, a kis sugarú fordulóra és a motorok jól szabályozhatóak. A robot tesztkörnyezetét kemény, sík, csúszásmentes felület borítja majd. Egyelőre nem tervezem nehezített körülmények leküzdésére is felkészíteni (pl. lépcső, vagy kavicsos, sziklás terep).

A mechanika felépítésére több ötletem is volt az idők során. Egyik változat gyári műszerdobozok átalakításából került volna ki. Később túlléptem ezen az elképzelésen és úgy határoztam, hogy egyedi szabásminta alapján lemezből alakítom ki a hordozó mechanikát. Egy biztos: nem lesz mikro méretű... A felépítmény szempontjából meghatározó a robotra szerelt eszközök térfogata, tömege. Így az elektronika, áramellátás, hajtás, érzékelők. Egyelőre az összetevők megvalósításának konkrét módja, formája lesz az elsődleges és azok ismeretének birtokában kalkulálom a hordozó jellemzőit.

Nagy vonalakban már felvázoltam a modellt ami alapján megépül a "szerkezet". A 2. ábra az információ áramlás szempontjából a 3. ábra pedig az önálló funkcionális elemek szempontjából ábrázolja.

2. ábra

3. ábra

Az érzékelés-beavatkozás interakció lényegében modell alapú mása az organikus struktúráknak. A környezet érzékelése által, a felfogott jeleket feldolgozva, a motorikus rendszer reakciója a válasz amely visszahat a környezetre. Esetünkben a mozgás, tájékozódás szempontjából elsődlegesen az alábbi érzékelésekre van szükség:

- távolságérzékelés az ütközések elkerülése miatt
- távolságérzékelés az útvonal megállapításához, döntési stratégiához
- pozíció meghatározáshoz szükséges érzékelők jelei
- vizuális érzékelés, egyrészt a navigációhoz, másrészt a felhasználó képi tájékoztatásához

A bemeneti jelek feldolgozása után egy "fúziós" folyamat alakítja ki a robot akciója szempontjából releváns változókat. A változók alapján a mozgás generátor dönt a kimeneteket alkotó beavatkozók állapotáról. A kimeneti jel a meghajtáson keresztül realizálja a mozgásgenerátor válaszát.

A kimeneti jelek:

- bal és jobb oldali meghajtó motor vezérlő jele

A funkcionális blokkvázlat (3. ábra) bemutatja a robot "agyát". A project gondolatának megszületésekor is nyilvánvaló volt, hogy a teljes rendszer bonyolultságánál fogva nem lehet egy vezérlő elemmel kontrollálni a robotot. Akkor úgy gondoltam, hogy egy mikrokontrollerre épülő cluster architektúrát alkalmazok, melyben egy master kontroller és több slave helyezkedik el. Az egyes időkritikus feladatokat a specializált slave, a startégiai és kommunikációs feladatokat pedig a master végezi. Később ezt a gondolatot is elvetettem. Már a hozzászólók is említették, hogy a feladat összetettsége igen nagy erőforrás ráfordítással jár. Ez így is van. Éppen ezért olyan összetevőket próbálok kiválasztani amelyek kvázi "konyhakész" alkotóelemek így jelentős energiát megtakarítva. Az ábrán jól elkülöníthetőek az egyes funkcionális elemek. A külvilág felé egy WiFi csatornán kapcsolódik a robot. A belső router összeköti a rendszerbusszal (QBus) - ami etehernet típusú -, ezen a buszon pedig szabványos protokollal kommunikáló mikrokontrollerek látják el feladatukat. Az "AGY" maga a master számítógép, amely egy real-time operációs rendszer környezetben futtatja a működéshez szükséges alkalmazásokat: inet daemon, webszerver, adatbázis motor, real-time control motor, QBus kommunikációs motor stb. A szoftverek tekintetében részben szabad forráskódú összetevőket használok, a slave számítógépek teljesen egyedi fejlesztésűek a szoftverrel egyetemben. A navigációhoz is saját szoftvert fogok használni. Mint már néhány elejtett kifejezésből kiderülhetett, az operációs rendszer UNIX vagy LINUX valamely disztribúciója. Maga az "AGY" nem futtat grafikus felhasználói környezetet. Annak reprezentációja a kliens gépeken jelenik meg egy tetszőleges browser közbeiktatásával, a felületet JAVA generálja. A járulékos programok C nyelven íródnak.

A hajtómű és az említett felépítmény:

4. ábra

5. ábra

6. ábra

7. ábra

8. ábra

Szia, szerintem vagyunk jópáran akiket érdekel ez a projekt és figyelemmel követjük a sorsát. Én érdemben hozzászólni az elektronikai kérdésekhez tudok. Van konkrét elképzelésed hogy mi legyen az "agy"? Én valami ilyesmit képzeltem el (melléklet) . Ha érdekel, tudok róla bővebb információt is adni, nálunk bevált (nem robot, vezérléstechnikai alkalmazás)

Szia!
Szép projektterv. Néhány kiegészítést tennék hozzá én is. Nem látok a terveken abszolút pozíció mérésére alkalmas eljárást. Mivel a relatív pozíciómérő eszközöknek véges felbontása illetve pontossága van, valamint a számítás tulajdonságai miatt a hiba kummulálódni fog, egy idő után a számított pozíció használhatatlan lesz tényleges pozíció meghatározására. Zárt térben (viszonylag kis mérettel) jó megoldást jelenthet ultrahang adó-vevő eszközök segítségével trianguláció módszerével. Másik probléma, hogy a kerekek átmérőjének névlegestől és egymástól való eltérése, valamint a tengely hosszának és középpontjának eltérése a jármű centrumától is pozíció- és orientáció mérési hibát fog eredményezni. Ezt pl. UMBmark nevezetű eljárás segítségével lehet csökkenteni. Ezen utóbbi gondolat akkor érvényes, ha a hajtott kerekek elfordulásából számítjuk az adatokat (szenzor pl.: inkrementális adó).
Egyébként a differenciális hajtás jó gondolat, az egyik legegyszerűbb és legkönnyebben megvalósítható hajtás a mobil robotok körében.

Mielőtt tovább haladnánk a részletek kifejtésével, előzetesen tisztáznunk kell néhány fogalmat, a teljesség igénye nélkül. Valószínűleg nem fogok sok újat mondani, de talán néhányan újszerűnek találják együttesen az alábbiakat.

A robotkutatás neves résztvevői (John J. Leonard, Hugh F. Durrant-Whyte) már régen megfogalmazták azt a néhány alapvető kérdést, amelyre mindannyian keressük a megoldást, mindannyian akik robotépítésre adjuk a fejünket.

Where am I? (Hol vagyok?)

Itt elsősorban a saját pozíciónk , orientációnk a kérdés, amely lehet abszolút és relatív.

Where am I going? (Hová megyek?)

Általánosságban egy mesterséges, autonóm objektum nem öncélúan "létezik", hanem akár konkrét, akár kísérleti céllal hoztuk létre, feladata egy meghatározott tevékenységre irányul. Ez a kérdéskör a feladat meghatározást taglalja.

How should I get there? (Hogy jutok el oda?)

A harmadik kérdésre az útvonal keresések adnak feleletet. A cél meghatározása után globális és lokális útvonaltervezést követően (esetenként real-time módon) hozhatjuk működésbe a robot mozgató mechanizmusát, mely biztosítja a célba jutást.

Pozíció - a pozíció a robot azon relatív viszonya egy önkényesen megválasztott koordináta rendszerhez, ahol az objektum koordinátái egyértelműen megadják annak helyzetét.

Orientáció - a robot relatív koordináta rendszerének helyzete a referencia koordináta rendszerhez viszonyítva, annak szögelfordulása.

A 10. ábra mutatja be egy autonóm robot általános helyzetét egy inerciarendszerben.

10. ábra

Ha általánosságban beszélünk tájékozódásról akkor világunkban általában a referencia koordináta rendszer maga a Föld. Szűkebben pedig a tevékenységünk szempontjából releváns környezet. A hely és helyzet meghatározások alapvető szenzorjai:

- giroszkóp
- gyorsulás érzékelő
- irány érzékelő
- sebesség érzékelő
- távolság érzékelő
- inkrementális jeladók
stb.

A relatív pozíció módszer szerinti meghatározása lehet:

- odometrián alapuló (Az útvonal mentén történő elmozdulás mértékének mérése)
- Dead-reckoning (Klasszikus navigáció, előre tervezés)
- inerciális (INS - a szögsebesség és gyorsulás mérésén alapul)

Ezen módszerek közös jellemzője, hogy gyors és mindig tud eredményt szolgáltatni. Nem igényel külső eszközt. Hátrányuk, hogy a pozíció hiba korlátlanul növekszik, mint ahogyan ezt El_Pinyo is említette. A hiba elsősorban a mérő eszközök jelfeldolgozásának véges felbontásából és az eszközök mérési hibájából ered. A hibát tovább növelheti az adott objektum mechanikai felépítésének pontossága (pl. kerékátmérők eltérése, csúszó tengelykapcsoló stb.). Használatukhoz rendszeres pozíció korrekciót kell alkalmazni.

Abszolút hely és helyzet meghatározása lehet:

- jeladók alkalmazásával (Ismert helyeken rögzítet jeladók, Pl. GPS)
- markerek alkalmazásával (Mesterséges és/vagy természetes jelölések használata)
- modellillesztéssel (Térkép alkalmazás)

E módszerek mindegyike külső eszközök meglétét feltételezi, ezért kialakítása bonyolultabb és innováció igényes. Pontosságuk az alkalmazott technológiától függően akár <10 cm is lehet.

További fogalmak:

Globális navigáció - útvonaltervezés
Lokális navigáció - akadálykerülés
Lokalizáció - a robot, környezetéhez viszonyított helyzetének meghatározása
Térképkészítés - egy leíró modell készítése a környezet minden eleméhez
SLAM - egyidejű lokalizáció és térképkészítés

Navigációs algoritmusok (felsorolás):

Szabad tér eljárás
Navigációs gráf
Összetett gráfalapú navigáció
Markerbázisú navigáció
Térkép bázisú navigáció

A project szempontjából érintett módszereket és eszközöket később ismertetem részletesen.

A felsorolt navigációs eljárások mindegyike kapcsolódik az 10. ábrán látható összefüggésekhez. Végül bármelyik módot választom a számításoknál az ábrán látható modellt veszem figyelembe. A robot mozgását mindig egy referencia ponthoz viszonyítva végzi. A terepen kijelölt referencia pont lesz a globális koordináta rendszer origója, a (0,0) koordinátájú pont. A robot pozícióját ehhez képest kell leírni: 10. ábra 1. összefüggés

A robot pozíciója (Xi,Yi) koordináták és a relatív koordináta rendszer α elfordulási szöge a referencia koordináta rendszerhez viszonyítva.
A relatív koordináta sík (Xr,Yr), mely koordináta rendszer origóját Q bázispontnak nevezzük. A bázispont célszerű elhelyezése az alkalmazott modellünk esetében, a két hajtott kereket összekötő egyenes felezőpontja. A referencia és relatív koordinátarendszer között kapcsolatot kell teremtenünk, ha le akarjuk írni a robot mozgását. Ezt a kapcsolatot az ortogonális mátrix segítségével tesszük meg. A két koordináta rendszer között az 1. összefüggést a robot felépítményének sajátosságaira felírva az alábbi összefüggést kapjuk:

10. ábra, 2. összefüggés

Ennek megfelelően fogom a későbbiekben meghatározni a robot pozícióját.

Köszönöm az információkat. Igen, konkrét elképzelésem van az "AGY" kivitelezésével kapcsolatosan. Nem szívesen hozok szóba személyes dolgokat - mivel nem kapcsolódik a fórum jellegéhez -, de hadd mondjam el, hogy hosszú ideje többek között információtechnológiai és irányítástechnikai kutatás-fejlesztéssel foglalkozom. Ebből következik, hogy az iparban, laboratóriumokban stb. felhasználható szoftver és hardver eszközökkel elég sok tapasztalatot szereztem, amelyek már kész alapokat adhatnak későbbi projectek kiindulásához. Így van ez a robot számítógépével is. Az egyes munkák megoldására felhasznált eszközök kiválasztásánál több típusú és felépítésű számítógépet próbáltam ki. A technikai jellemzőin kívül a választásban sokat számított a szubjektív benyomás: pl. "jól néz ki", a felhasználás szempontjából könnyen kezelhető, könnyen beépíthető (kompakt felépítés, házzal együtt). E mellett természetesen a legfontosabb szempontok, hogy megfelelő környezetett biztosít-e a szoftverek számára, megfelelő teljesítményű-e, milyen kommunikációs portjai vannak. A különféle tesztek alkalmazás specifikusan létrehoztak egy tapasztalati "skálát" mely alapján jó találati valószínűséggel elsőre is ki lehet választani a célnak megfelelő eszközt és nem fejlesztés közben derül ki: kinőttük a gépet már az elején. A linux operációs rendszer részben determinálja a platformot. Az általánosan használható környezet miatt az x86 kompatibilist választottam. A nagy számítási teljesítmény és adatbázis igényhez igazodva az alábbi paraméterekkel rendelkező eszközökre esett a választásom (No és azért is, mert ezen gépeken futnak a programok....):

1.
Processzor: Intel Atom Z530 1.6GHz
RAM: 1GB
Grafikus Processzor: Intel GMA 500
Háttértároló: 160 GB SATA2
LAN: Gigabit Ethernet /10/100/1000 MBit
WiFi: 802.11 b/g
Komm. portok: 6xUSB 2.0, 1xRS232/RS485
Ház: Öntött alumínium, passzív hűtés
Tápfeszültség: 8-15V DC
Teljesítmény felvétel: 3-8W
Méret: 101x115x27 mm
Súly HDD-vel együtt: 0.37 kg

2.
Processzor: MSTI PMX-1000 1GHz
RAM: 512MB
Háttértároló: CF, SD kártya (8-16GB)
Grafikus processzor: XGI Z9S
LAN: /10/100 MBit Ethernet
WiFi: -
Komm. portok: 4xUSB 2.0, 2xRS232/RS485
Ház: Öntött alumínium, passzív hűtés
Tápfeszültség: 8-15V DC
Teljesítmény felvétel: 3-8W
Méret: 115x115x35 mm
Súly: 0.5 kg

Ezeket az ipari számítógépeket jó eredménnyel alkalmazzuk ipari és laboratóriumi szabályozási, mérés-adatgyűjtési, telemetriai célokra, SCADA és HMI feladatokra. Miért két számítógép? Végül is egy lesz a robotban, de a fejlesztési fázisban szükségem lesz a nagyobb teljesítményre. A szoftverek futtatása "üzemszerűen" már kisebb erőforrást igényel, így a 2. számítógépet építem be véglegesen.

Szia

A virtuális világunk és a fórum is el van árasztva mindenféle ötlettel és módszerrel a robotika témakörében. A saját projectemhez természetesen én is átnéztem néhány elgondolást és azok előnyét, hátrányát mérlegelve a következő kialakítást választottam az érzékelés tekintetében:

Mint már említettem a hajtás egyenáramú motorokkal működik és független vezérlésű. A robot pozicionálásáról, a hajtóművek irányfüggő vezérléséről egy neuro-fuzzy algoritmus gondoskodik. A pozíció és orientáció érzékeléshez giroszkópot, gyorsulásmérőt, optikai elmozdulás/sebesség érzékelőt használok. Az útvonaltervezéshez és a vészhelyzetek kezeléséhez (pl. ütközés veszély) ultrahangos szonárokat (min. 5 db) , és egy- vagy kétdimenziós képfeldolgozást alkalmazok. Az útvonaltervezést és akadálykerülést szintén neuro-fuzzy algoritmus felügyeli különös tekintettel a dead-lock helyzetekre. A mechanikai és vezérlési struktúra egyszerűsítése érdekében nem építek be körbeforgatható érzékelőt. Ez a funkció a robot sajátos felépítésével pótolható szükség esetén, ti. a robot képes lesz saját Q bázispontja körüli elfordulásra lényeges pozíció vesztés nélkül.

Az odometria részben optical-flow eljáráson alapul. Az elv megtalálható az optikai egerekben is. Én is egy, az egerekben használt chip-et építek be megfelelő optikai kiegészítéssel, hogy az érzékelő talajhoz viszonyított beépítési távolságát a robot belsejébe lehessen pozícionálni. A Q bázispontba kerül. Ezzel a módszerrel egy sor hibaforrást sikerül kiküszöbölni vagy kompenzálni: a hajtómű holtjátéka, a kerekek átmérőjének különbsége, megcsúszás, talajminőség befolyása stb.

Lényegében semmilyen lokális pozíció meghatározási módszer nem nyújt hiba nélküli eredményt. Mivel ez a robot leginkább egy kísérleti projectnek tekinthető, a lokalizáció pontosságát egy viszonylag kisebb térre, (max. néhányszor 10 m) terveztem. Így a project bemutatása céljára abszolút helymeghatározás nélkül is alkalmas. A GPS navigációt a nyílt szolgáltatáson keresztül <4-8 m pontossággal érhetjük el. Mivel felbontás nagyságrendje egybeesik a robot mozgásterével itt a GPS navigáció nem használható, ettől függetlenül opcionálisan csatlakoztatható.

Az abszolút pozíció meghatározását támogató lehetőségek közül a legesélyesebb a WiFi access point-ok kihasználása (mivel egyébként is szükséges a WiFi adatátvitel). Önállóan az egyes módszerek nem szolgáltatnak kielégítő pontosságot. A pontosság növelése érdekében szenzorfúziót használnak általában, így teszek én is. A fúziós eljárás része lehet a Kalman-filter is.>

Egy ideig nem volt időm írni, de mielőtt megteném megint megkérdezem - egyéb jelzés hiányában -, hogy van-e valami amire kíváncsiak vagytok, de nem eset szó róla?

Lehetséges, hogy az én logikám eltér másokétól így kihagyhatok érdekes részeket, másutt esetleg túlzottan részletekbe bocsájtkozom.

G

A korábban vázolt blokkvázlat már pontosabban bontakozik ki a 11. ábrán.

11. ábra

Kiválasztottam a konkrét alkatrészeket és pár napon belül elkészülnek a kapcsolási vázlatok. Érthető módon ez a folyamat párhuzamosan folyt az érzékelési eljárások megválasztásával. Kiválasztási szempontom volt a megfelelő észlelési tulajdonság és a rendszerbe való integrálhatóság. Szerettem volna elkerülni, hogy több típusú kommunikációs csatornát használjak, így SPI-vel kompatibilisek az érzékelők. A motorvezérlő dsPIC kontroller miatt PWM jel a kimenet. A logikai részekhez hasonlóan tagolódik a fizikai kialakítás. A lokális beavatkozást végző logika egy hordozóra épül és Ethernet-en keresztül kapcsolódik az "AGY"-hoz.

Szia!
Eddig nagyon tetszik a tervezet, csak így tovább!
Esetleg tudnál egy kicsit részletesebb leírást adni a motor szabályozásról? Gondolok itt ez alatt arra, hogyan identifikálod a motorokat, milyen típusú szabályozót használsz, hogyan határozod meg a szabályozó paramétereit és hasonló dolgokat. Van szabályozástechnika elméletben jártasságom, gyakorlatban viszont már kevesebb, így érdekelne, Te hogyan oldod meg a feladatot.
A másik kérdésem, hogy a szenzorokat itt Magyarországon szerezted be, esetleg külföldről rendelted? Főleg a giroszkóp és az ultrahang szenzor érdekelne.
Előre is köszönöm a válaszodat!

Szia,

örülök, hogy legalább egy embernek tetszik
Elnézést kérek, kissé megkésett a válasz.
Folyamatában mindenre ki fogok térni, eredetileg is szándékomban volt az egyes eljárásokat ismertetni, csak el kell jutnom odáig... A szenzorokról... a modulokat a Parallax gyártja és itthon is meg lehet rendelni a disztribútortól. Az ultrahang szenzor más gyártóktól is beszerezhető lényegesen alacsonyabb áron. Ha konkrétan érdekel a forrás, megkeresem.

M

Elkészültek a kapcsolási vázlatok.

12. ábra

13. ábra


Nézzük sorban: egy áramköri lapon kap helyet a mikrokontroller, az ethernet illesztő, a giroszkóp, a gyorsulás érzékelő és a motorvezérlő. Külön hordozóra kerül az optikai elmozdulás érzékelő, a szonár modulok és a tápegység.

A MICROCHIP dsPIC30F4013 mikrokontrollerét választottam MCU-nak. A teljesítményígény és a bonyolultság között egyensúlyoztam, enek eredménye a kevesebb lábszámú CPU. Nem csak a teljesítménye, hanem a hardver PWM csatornái is súlyozták a választást.

Microchip gyártmányú az ethernet illesztő (ENC28J60). Ezzel a kialakítással egyszerűen tudom megvalósítani a TCP/IP stack-et, melyre a kommunikációs protokoll épül. Mivel az ENC chip 3.3V-os tápfeszültség igényű, ezért aktív szintillesztő közbeiktatásával kapcsolódhat az MCU-hoz. Kiszolgálása eseményvezérelt, az INT0 megszakításon keresztül. Korábban a blokkvázlathoz mellékeltem az egyes modulok adatlapját így nem térek ki mindegyikre. Ha a későbbiekben kérdésetek lenne, akkor részletezzük.

A szonár modulok egy-egy port vonalon keresztül kapcsolódnak az MCU-hoz, vezetékekel, csatlakozókon keresztül. A modul triggerelése után a távolság információt a válaszimpulzus hossza hordozza. Ez egyszerűen mérhető, ciklikus feldolgozását TIMER megszakítás ütemezi.

A giroszkóp és gyorsulásmérő modulok SPI csatornán keresztül kommunikálnak. A modulok sajátossága, hogy kétvezetékes soros adatátvitelt alkalmaznak, így gondoskodni kel az MCU SPI buszának illesztéséről. Ezt a feladatot tri-state bufferekkel oldottam meg. Itt is ciklikus az információ feldolgozás.

Az optikai elmozdulás érzékelő tovább bonyolította a felépítést. T.i. az ADNS 2610-nek nincs CS bemenete, így az SPI buszról törtnő leválasztása körülményes lett volna. Ezt úgy kerültem el, hogy külön adatcsatornát alakítottam ki. (Megjegyezem, hogy a korábbi blokkvázlatok, a leírások és a kapcsolási vázlat nincs szinkronban, különböző chip-eket írtam felhasznált alkatrészként. Úgy tűnik, hogy a végleges változat az ADNS 2610 lesz. A korábban jelölt chip 3.3V-os, így esetében szükséges lett volna szintillesztő áramkör beépítése.)

A hajtómotorok vezérlését az ST gyártmányú L6203 DMOS teljesítmény meghajtó áramkör végzi. Teljes híd kialakítású, irány és fordulatszám vezérlési opciókkal, beépített áramszaggatóval (Chopper Current Control). Funkcionálisan az L6506 Current Controller áramkörrel teljes. Tulajdonságaik kiválóan alkalmasak DC motorok vezérlésére. Annyiban fűznék még a felépítéséhez megjegyzést, hogy a motor fordulatszámát nem a PWM jel határozza meg közvetlenül – a PWM impulzusok nem jelenek meg a hídvezérlésben –, hanem a PWM állítja elő azt a vezérlő feszültséget, melyre az L6506 szabályoz az áramérzékelő hurkon keresztül. Az árammal arányos ellenőrző jelet egy soros ellenállásról csatoljuk vissza. Talán lesz olyan, akiben felmerül a kérdés, hogy egy motorvezérlő MCU alkalmazása mellett miért esett a választásom erre az áramkörre, hiszen a teljesítmény fokozatot direkt módon az MCU is ki tudja szolgálni. Az esetleges kérdés jogos: így is van, abban az esetben, ha csak azzal a feladattal foglalkozik a processzor. Mivel szerteágazó kommunikációs és szabályozási feladatokat kell ezen kívül ellátnia, a programfutási idő csökkentése érdekében hardverre bíztam az áramszabályozást.

Ezzel áttekintettük a részegységeket.

Szia!

Latom alakul a dolog. Gondolom most jon majd az a resz ami engem szemely szerint a legjobban erdekel ebben a project-ben: a PC es a robot kozotti kommunikacio, es a PC-s adatfeldolgozas.
Biztosan sok kerdesem lesz majd ezzel kapcsolatban.
En is most irom a kovetkezo HE-s cikkemet, es epitgetem a kovetkezo robotom, igy tudom hogy mennyi idobe es energiaba kerul egy ilyen "tananyag" osszeallitasa.
Koszonet erte!

Szia,

az utolsó mondatoddal nagy elégtételt adtál nekem , Mégpedig abban az értelemben, hogy nem vagyok egyedül ezzel mert te is tudod, érzed, értékeled azt az energiát, időt amit egy-egy folyamatba kell fekteni, ha szeretnél valamit "alkotni". Biztosan mások is átélték már ezt folyamatot, csak kevesen publikálják. Most, hogy megint egyfajta filozofikus hangnem lett úrrá rajtam - bocsánat érte, de ezt is leírom - bepillantást engedek saját dillemmáimba, miközben megpróbálom mekeresni a számomra optimális (és lehetőleg a feladat számára is..) megoldást. Lehetne talán részletekbe menőnek nevezni, esetleg túl óvatosnak egy módszer melleti döntéshez és még sorolhanám a tulajdonságokat... de mindezektől függetlenül számomra minden egyes választásnak számtalan következménye van, amit végig kell gondolni és ez időbe kerül. Egy ilyen feladat már globális, rendszertechnikai szemléletet igényel, egy-egy alkatrész, módszer kiválasztása - látszólag jelentéktelen funkciója ellenére is - a későbbiekben előre beláthatatlan következményekel járhat. Az is eszembe jut időnként, hogy nehézkes vagyok... netán a gondolkodásom már nem olyan fürge... hiszen látszólag sokan egy tollvonással el tudják intézni azt, ami nekem viszonylag nagyobb átgondolást igényel.

A nélkül, hogy ismét felszítanám a kedélyeket, minden rossz szándék nélkül hadd idézzek egy jó évvel ezelőtti beszélgetésből:

Nekem konkrétan még mindíg fejtörést jelent egyes momentumok tisztázása, a felmerülő probléma megoldása.

Miről van szó? Kíváncsi lennék, ki hogyan oldaná meg az egyenes irányú haladást, iránytartást...és még nem is beszéltünk az útvonaltervezésről. Ez inkább volt költői kérdés jellegű óhaj, mintsem most bárkin is számon kérjem saját módszerét.

A giroszkóp kiválasztásánál sokáig haboztam, mit tegyek. A project megvalósítása nem kevés időbe kerül, a költségeket nem is említve. Tehát sok dologban kompromisszumot kell kötni. A LISY300 10 bites AD-t tartalmaz. Ebből kiindulva azonnal szembetűnő a rendszeres hibaforrás, amit hordoz. Ám egy nagyobb felbontású AD-t tartalmazó áramkör vagy modul más áramköri megoldásokat igényelt volna, nagyobb költséggel. Így döntöttem mégis mellette, eleve ismerve a modul hátrányait. Mi okozza a rendszeres hibát? Csak egy gyors fejszámolás.... A 10-bites felbontásból eredő hiba +/- egy bit, amely elfordulási szögre vetítve, és a modul mérési tartományát alapul véve ami 300 fok, 10 m-en megközelítően +/- 5 cm eltérést jelent a kijelölt iránytól. Vagyis ennél pontosabban ezzel az eszközzel nem lehet az irányt meghatározni, tartani. Ám a robotot más szenzorrokkal kiegészítve lehet csökkenteni ezt a hibát, ami a tesztelés alatt megtet úthosszokon nem jelent számottevő eltérést. ... ha meg tudjuk valósítani egyébként magát az iránytartást.... Nos! Szerenék látni egy erre képes logikai áramkört. Szívesen elemeznék különböző lehetséges megvalósítási ötleteket, temészetesen a kigondolójukkal együtt. Érdekes lenne párhuzamba állítani a különböző megoldások tulajdonságait.

Tudom, hogy még nem tartasz ott a projectben, hogy aktuális legyen a felvetésem, de mivel szóba került, gondoltam megemlítem, mert a későbbiekben szükséges lehet. Konkrétan a robot mozgásának "kalibrálására" szeretnék kitérni, melyet a differenciális hajtással működő robotokhoz találtak ki. Az eljárást UMBmark- nak nevezik és lehetőséget ad a különböző nem korrigálható hibákból (kerék átmérőjének eltérése a névlegestől és egymástól, a kerekek egymástól való távolságának eltérése a névlegestől, stb.) adódó pontatlanságokat csökkenteni a megtett útra és az orientációra nézve.
UMBmark

Az UMBmark egy lehetséges változata a korrekciós ejárásoknak. Valójában kogníción alapuló, geometriai megfontolásokból eredő elméletel támogatott módszer, mely alkalmazásához számtalan kezdeti feltétel szükséges. Megelőztél, mert a következő írásomban szántam szerepet ennek, nem mint módszernek, hanem inkább az általános problémafelvetésének, mégpedig éppen a véletlen és rendszeres hibák fellépése kapcsán. Alkalmazhatóságának feltétele, hogy a készülő "robot" geometriai kialakítása és az alkalmazott odometriai módszer jórészt azonos legyen a hivatkozott publikáció elemeivel és a pontosság kedvéért hozzáteszem, hogy önmagában a diffeenciál hajtás nem feltétlenül az elsődleges kritériuma. Mindebből következik, hogy nem általánosan használható eljárásról van szó. Minden egyes megvalósítás hordozhat más olyan elemeket is amelyre nem tér ki az említet eljárás. A robot felépítéséből és az alkalmazott módszerek következtében egy sor hiba okafogyottá válik. Sajnos - és természetesen - lesznek más jelegű problémák. Ettől függetlenül, ha nem bánjátok nem írom át teljesen a következő hozzászólásom és bennehagyom az idevonatkozó részt. Még annyit mondanék előljáróban, hogy én nem a kalibrációra helyezem a hangsúlyt, hanem a korrekcióra. Vagyis nem egy előzetesen tesztsorozat alapján határozom meg a kalibrációs eljárást. Az elgondlásom szerint mozgás közbeni (real-time) korrekciót fogok végezni. A tesztmérések azonban szükségszerűek, a belőlük származtatott információk az algoritmusok hatékonyságának "mérőeszközei".
Mindenképpen részletesen kitérek a szabályozási kérdésekre is, mint ahogyan a korábbi hozzászólásodban kérted. Annál is inkább mert kulcsszerepe van a robot mozgásában.

A robot mozgásának elemzéséhez vizsgáljuk meg általánosságban egy háromkerekű robot mozgásegyenleteit. Ehhez először egy idealizált modellt hozunk létre, majd annak tulajdonságaira a valós körülmények zavaró hatásait szuperponáljuk.

A 14.A. ábrán egy ideális gördülő kereket láthatunk. A kerék szabadon foroghat az Yr tengely körül, kitüntetett irányú mozgást mutat az Xr tengely irányában, valamint bizonyos fokú Wr oldalirányú csúszást. Alacsony sebességeknél a gördülő mozgás a domináns, az oldalirányú csúszás elhanyagolható.

14. ábra

A kerekek – így a robot – mozgásának leírása a kerekek közötti távolság, a kerekek sugara, a robot elmozdulás vektorának irányszöge és a kerekek szögsebessége alapján lehetséges a 14.B., 14.C. ábra szerint. A mozgásegyenletek felírásához először a robot saját koordináta rendszeréhez viszonyított mozgását kell meghatározni, majd ezt a mozgást kell megállapítani a referencia koordináta rendszerhez viszonyítva. Az alkalmazott odometriai módszer és a robot mozgása között egyszerű összefüggések teremtenek kapcsolatot. Például: kerekenként inkrementális jeladót felhasználva, a teljes körbeforduláshoz tartozó impulzusszám ismeretében tetszőlegesen (a véges nagyságú felbontás korlátainak figyelembe vételével) számítható a robot elmozdulása, szögelfordulása.

Általánosságban igazak a következő megállapítások: ha a robot két kereke azonos sebességgel azonos irányban forog, a robot az Xr tengely mentén egyenes vonalú mozgást végez. Ha a két kerék azonos szögsebességgel ellentétes irányban forog, a robot saját Q bázispontja körül forog. Általános esetben a kerekek eltérő sebességgel forognak, mikor is a robot egy referencia pont körül körpályán mozog. 14.C. ábra

15. ábra

Az 15. ábra a robot általános helyzetét mutatja be, minek alapján a robot mozgásegyenletei a következőek:

bevezetjük a következő változókat:
vr(t) - a jobboldali kerék lineáris sebessége
vl(t) - a bal oldali kerék lineáris sebessége
wr(t) - a jobb oldali kerék szögsebessége
wl(t) - a bal oldali kerék szögsebessége
r - a kerekek sugara
L - a kerekek közötti távolság
R - a pillanatnyi pályaív sugara
P’ - a pillanatnyi pályaív középpontja
R-(L/2) - a bal oldali kerék által leírt pályagörbe sugara
R+(L/2) - a jobb oldali kerék által leírt pályagörbe sugara

Az egyenletek a 16. ábrán láthatóak.

16. ábra

A robot mozgásának koordinálásához szükségünk van egy modellre, mely alapja lehet a szükséges algoritmusnak. A modell viselkedésének egyenleteit kaptuk meg a fenti levezetésben. Láthatjuk, hogy viszonylagosan összetett egyenletrendszert kaptunk. A későbbiekben ezen egyenleteket használhatjuk fel a robot pozíció és orientáció koordinálásához.

Mindez azonban csak ideális esetben teljesül. A valós körülmények zavaró tényezőkkel terheltek, melyek hibákat visznek be a számításokba, mint ahogyan a korábbiakban említettem már.
A teljesség igénye nélkül ezek rendre a következőek

Rendszeres hibák:
- a kerekek geometriai, méretbeli eltérése
- kerekek távolságának eltérése a Q bázisponttól
- kerekek tengelye nem egy vonalba esik
- kerekek eltérő kapcsolata a talajjal
- a motorok teljesítménye eltérő
- hajtómű holtjáték és áttétel eltérő
- véges jeladó felbontás és mintavételezési gyakoriság

Rendszertelen hibák:
- csúszós út miatt a kerekek állnak, de a robot mozog
- csúszós út miatt a kerekek mozognak, de a robot áll
- nagyobb sebességeknél megnő a Wr oldalirányú csúszás jelentősége
- fordulásnál sodródás következik be
- környezeti hatások, mint például ütközés tárgyakkal
- belső kényszerek (beragadó kerék)

A hibák következtében a robot referencia teszt pályán történő mozgásában a számítottól való eltérés tapasztalható.

17. ábra

A piros nyomvonal szöghibával, a kék nyomvonal pedig járulékosan kerékátmérő különbséggel terhelt eset. Akkor, ha a fentebb említet jeladókat alkalmazzuk lehetőség nyílik egy korrekciós eljárásra mely a névlegestől való eltérés ismeretében csökkenteni képes az abszolút hibát. Egyik ismertebb megoldása az UMBmark eljárás.

A robot valóságos pályagörbéje is eltér az ideális eset szerintitől, orientációjában és lokalizációjában hiba lép fel.

18. ábra


Az orientációs hiba mértéke ΔeΘ, a pozíció hiba pedig Δex, Δey.