Most én lettem kicsit csalódott, hogy csalódott lettél...
Talán enyhülni fog ez az érzésed, ha elárulom van olyan részegység amit én terveztem.

De nagyon érdekes kérdést vetettél fel! Szavidat olvasva sokféle dolog jutott eszembe, még az is, hogy általános célú, kész elektronikus részegységek, modulok összerakása elektronika-e vagy sem. És hogy ennek kapcsán ezen a fórumon van-e a helye ennek a topiknak?! Nyilván megoszlanak a vélemények.

Meddig terjed az elektronika fogalma? Csak az áramköri tervig? Vagy rendszerszinten is annak tekinthető? Mikor az és mikor nem? Fizikai alkatrészek halmaza az, de egy szimulációs fejlesztőkörnyezet már nem? A soft technológiák hová sorolhatóak? Netán bizonyos esetekben nekünk kell nézőpontot váltani? Mit gondoltok ezekről?

Elnézésedet kérem, nem akartalak megbántani és az érdemeidet sem csökkenteni. Csupán néhány, előzőleg elejtett mondatodból jutottam a fenti következtetésre. Gyakorlatilag meg sem lenne oldható, pl. rögtön ott a motor... Teljesen igazad van, a spanyol viaszt nem kell folyton feltalálni, és méginkább nem lemásolni. Gyakorlatilag itt a szoftver lesz mindenképp, ami a rendszert működtetni fogja. De nagyon tetszik, hogy a mechanikai kialakításra is fokozott figyelmet fordítasz, így biztosan nem lesz "összehányt" a végeredmény. A részletesség néhány tudós fórumtársat talán zavar, de biztosan többen vagyunk azok, kik áhitattal olvassuk a leírt gondolataidat, okfejtéseidet. Még egyszer elnézésedet kérem a fenti hozzászólásomért és kíváncsian várom a folytatást!

Szerk.: Természetesen fogadjátok szívből jövő gratulációmat a szép eredményhez!

Nehogy már te exkluzáld magad! Sajnos az írott kommunikáció nem közvetíti az emóciókat. Így nem láthattad, hogy semmi megbántódás nincs bennem, sőt némi humort próbáltam belevinni a válaszomba. Ezen túlmenően egy pillanatig sem gondolkodtam azon, hogy máshová költöztessem a topikot. Még kevésbé volt szándékomban dicséreteket provokálni.

Azonban komolyan kíváncsi vagyok mi a véleményetek a teoretikus kérdéseimről, hiszen az elmúlt fél évszázad alatt gyökeresen megváltozott az elektronika fogalma és kiterjedési területe. (Talán mégis én szeretnék provokálni egyfajta kitérő diskurzust?!)

Valóban voltak olyan elképzeléseim, hogy jó részét a vezérlésnek én tervezem. Ám a bejegyzéseimet az élet produkálja - hogy ilyen nagy szavakat használjak- , mert az idők során simán felülbíráltam a korábbi elképzeléseimet egy jobbnak tűnő megoldás kapcsán. Így egyfajta dinamikus változásban, annak folyamatában tudom bemutatni egy elgondolás megvalósulását. Azt hiszem a project megkezdése óta eltelt időre szükség volt, mert meg kellett érnie az elgondolásnak.

Van tehát egy léptetőmotor amit RS422-es csatornán parancsokkal tudok vezérelni. Hogyan lehet ezt felhasználni a robot mozgatására? Ahhoz, hogy az elgondolás használhatóságát megállapítsam elsőként teszteket csináltam.

Néhány parancs ami a sebesség, lépés és mikrolépés beállítására szolgál:

+ <érték> - <szám> lépés előre
- <érték> - <szám> lépés hátra
M <érték> - <szám> sebesség előre
M-<érték> - <szám> sebesség hátra
M - megállás
D <0..8> - mikrolépés
Y <érték_1> <érték_2> - HOLD/RUN áram

Az első két parancs önmagáért beszél. Az „M” argumentumaként megadott érték pedig lépés/másodpercben fejezi ki a sebességet.
A mikrolépés beállításánál a „0” teljes lépést jelent – vagyis 1,8°-ot -, amely esetén az elérhető fordulatszám 6000 rpm.

A „D” parancs paramétere azt mutatja meg, hogy a teljes lépés hány részre van felbontva.
1 -1/ 2
2 -1/ 4
3 -1/ 8
.
.
8 -1/ 256
Az utolsó esetben elérhető legnagyobb fordulatszám 23 rpm.
Az „Y” paranccsal a tartó és futási áramot állíthatjuk be, amely a nyomatékkal arányos.

A következő videón látszik hogyan reagál a motor a parancsokra, amelyek sorban:

Video: MotorTest_0

+1
+5
+20
-20
M200
M1500
M2500
M50
M-150
M200
M-800
M800
M5000
M-5000
M5000
M10000
M
M8000
M

Néhány dologra felhívnám a figyelmet. Egyik az, hogy nagyobb fordulatszámoknál történő irányváltásnál jól érzékelhető a gyorsítás és lassítás. A másik ami szembetűnő, hogy az M10000 és M8000 parancs hatására a motor kiesett a szinkronizmusból és megállt. (Ez a tulajdonság akkor is fennáll, ha forgás közben túlterheljük.) Megjelent a léptetőmotor azon tulajdonsága amire már tettem említést „hátrányként” aposztrofálva. Mi történt ekkor?
A léptetőmotorok sajátossága, hogy csak meghatározott indulási sebesség alatt képesek elindulni. Ez függ többek között a motor inerciájától, terhelésétől és áramától. A látott viselkedés hasonlít ahhoz, mint amikor az aszinkron és szinkron gépek billenő nyomatékát túllépjük. Az aszinkron gépekkel szemben a szinkronizmusból való kieséskor nem éghet le a léptetőmotor. Az egyenáramú motorok indítási karakterisztikája - némi képzavarral élve – nagyságrendekkel jobb.
Hogyan lehet ezt a helyzetet kezelni a léptetőmotoroknál? Fokozott figyelmet kell szentelni a dinamikus viselkedés elemzésére, valamint a terhelt motor tehetetlenségi nyomaték/motor tulajdonságok viszonyára. A nyomaték növelésével javul a gyorsíthatósága. Egy másik lehetőség a nyomaték növelése mellett a RAMP beállítása, ami limitálja a dv/dt (vagyis gyorsulás) értékét, ezzel biztosítva a névleges fordulatszám elérését. A RAMP engedélyezése viszont korlátként jelenik meg a dinamikus viselkedés szempontjából.
A nyomaték növelésének is ára van. Értelemszerűen növekvő nyomatéknál nagyobb teljesítményigénye van a hajtásnak, ami visszahat az áramforrás kiválasztására. A felvett energia nagy része a vezérlőben és a motorban eldisszipál. Üzem közben a vezérlők hőmérséklete elérheti a 70°-ot, a motoroké egyes gyártmányoknál pedig a 80°-ot is. A disszipáció növekedésén túl a nyomaték növelésével zajossá válhat a hajtás, rezonancia léphet fel.
Mindent mérlegelve elsőre úgy tűnik, hogy a léptetőmotor alkalmas lesz a robot hajtásához a támaszkerekes esetben.

A robot mozgatását eddig stabil állapotot feltételezve vizsgáltuk. Bonyolítsuk az „alapesetet” az egyensúlyozással!

Mi a segway?
Valószínű, hogy elsőre a SEGWAY márkanévvel fémjelzett egyensúlyozó jármű jut legtöbbünk eszébe. Valójában ez a jármű egy különleges fizikai probléma működőképes megvalósítása.

A segway nem más, mint egy fordított inga. Az ingáról mindenki hallott már. Az inga stabil rendszer és egzaktul le is írható a dinamikus viselkedése. Ezzel szemben az instabil rendszerek vizsgálatának egyik legismertebb példája a fordított inga. Ez egy olyan mechanikai rendszer amelyben egy l hosszúságú merev rúd felül lévő végén lévő m tömegű test egy M tömegű kocsin rögzített tengely körül elfordulhat, amely forgásponttal a rúd köti össze. A fordított inga - instabilitásánál fogva - kedvelt témája a fizikai rendszerek irányításelméletével foglalkozó kísérleteknek.

A fordított inga szabályozásánál – egyensúlyban tartásánál – az a cél, hogy az inga alátámasztási pontját a tengelyre merőleges irányban mozgatva biztosítsuk az rúd függőleges állapotának megtartását.

Miért instabil a rendszer?
Ha rövid akarok lenni: mert eldől. Mindenki megtapasztalhatta például egy partvis vagy seprű tenyéren történő egyensúlyozását.
Pontos válaszért a mechanikai rendszer matematikai modelljével kell foglalkozni.

Az egyszerűsített fizikai modell egy a rúd felső részén elhelyezkedő m és egy a rúd alján elhelyezkedő M tömegpontból áll, ahol is a két tömegpont egy elhanyagolható tömegű l hosszúságú merev rúddal van összekötve.

62. ábra


Az általános helyzetben ábrázolt rendszerben több erő hat. A függőleges – egyensúlyi állapotnak megfelelő – helyzettől való eltérés szögét jelöljük θ-val. Az m tömegpontra ható gravitációs erő g, mely felbontható egy rúd irányú és arra merőleges irányú komponensre. A rúdra merőleges erő f iránya olyan, hogy a rúd forgástengelyen való elfordulását idézi elő (forgatónyomaték). Ez a mozgás a függőleges helyzetből való kitérés során gyorsuló.

Vizsgálva a rúd függőlegessel bezárt szögét és a szögsebességet, a modell alapján számítható az F mozgatóerő. F erővel mozgatva a kocsit biztosítható a függőlegestől való 0 szögeltérés és a 0 értékű szögsebesség. Ez az egyensúlyi állapot.

De...

A fenti mechanikai rendszert leíró matematikai modellt elemezve (az ábra alján):

A leíró függvény egy nemlineáris differenciálegyenlet. A megoldása során, linearizációval származtatott átviteli függvénye olyan elemeket tartalmaz ami bonyolítja a szabályozást.

A nélkül, hogy kifejteném: a rendszert leíró átviteli függvény olyan bonyolultságú, hogy hagyományos módon nem történhet meg az alkalmazott szabályozó paramétereinek beállítása. Mi több, az egyszerűsített modell nem képezi le teljesen a valós fizikai rendszert, csak közelíti. Ez a közelítő leírás többnyire nem elégséges a PID szabályozókkal történő rendszer szabályozáshoz.

Itt újból a fuzzy-hoz nyúlunk, amelyről már volt szó többször is. Milyen módon ad megoldást a fuzzy logika?
Felidézve a korábban leírtakat, úgy mint ahogyan partvist egyensúlyozunk a tenyerünkön! Az egyensúlyozáshoz nem feltétlenül kell a rendszer pontos leírása. Ha jobbra dől, az alátámasztást biztosító kezünkkel olyan gyorsan mozgatjuk jobbra a rudat, hogy közel nullára korrigáljuk annak a függőlegessel bezárt szögét.... Ha balra, előre, vagy hátra dől.... hasonlóan cselekszünk.

Már csak az „olyan gyorsan” értéke kérdéses!

Bizony hogy figyelünk!
Az "off" kérdesed pedig:

Idézet:
„Meddig terjed az elektronika fogalma? Csak az áramköri tervig? Vagy rendszerszinten is annak tekinthető? Mikor az és mikor nem? Fizikai alkatrészek halmaza az, de egy szimulációs fejlesztőkörnyezet már nem? A soft technológiák hová sorolhatóak? Netán bizonyos esetekben nekünk kell nézőpontot váltani? Mit gondoltok ezekről?”

Szerintem a fentiek mind besorolhatók az elektronikába, hiszen ma már szinte minden elektronikus. Ha nem hangsúlyozzuk is. Az meg, hogy bizonyos dolgokat készen vett modulokkal oldasz meg, szerintem is teljesen jó. Ha valaki külön el akar szöszölni vele, még mindig megteheti, mivel nem az egész projekt "készen vett", bármikor bármely része lebontható/megvalósítható házilag is. Legalábbis eddig. Nyilván kamerát nem fog senki magának gyártani, de olyan motorvezérlőt ami tudja a kritériumokat, bárki.
Hegyezzük a fülünket!

Köszönöm a feldobott labdát, csak erre vártam!
Önszántamból nem akartam előhozakodni ezekkel az elméleti kérdésekkel, de így már mindjárt más... Ugye?!

Előrebocsájtom, hogy a véleményem sok tekintetben szubjektív, ám az érzékeléseimen nyugszik, vagyis a környező világ benyomásain.
Azt gondolom, hogy alapjaiban megváltozott sok szakterület kiterjedése. Ez igaz az elektronikára, számítástechnikára és sorolhatnám, hogy még mire. Mégis e két szakterületet említettem, mert korábban elképzelni sem tudtuk volna azt a hihetetlen mértékű fúziót ami bekövetkezett közöttük.
Egyesek emlékeznek rá, hogy a számítástechnika korai időszakában egyes kiválasztottak privilégiuma volt „A” számítógéphez való hozzáférés és a legkevésbé sem fordították az értékes gépi időt elektronikus áramkörök fejlesztésére, tervezésére, modellezésére stb. Külön kasztot alkottak a programozók és a felhasználók. Ugyanekkor a mai rendszer integrátori feladatkör része volt a hardver tervezői, kivitelezői tevékenységnek. A hardver céláramkörök halmaza volt, és ritkán beszélhettünk szoftverről a mai értelemben.
Ám Moore törvénye működött és most ott tartunk, hogy még egy kozmetikai epilátorban is megtaláljuk a processzort. De jól van ez így!
A megváltozott körülmények magukkal hozták az alkalmazástechnikai szerepek újraosztását. A gyártók elsősorban részegységeket fejlesztenek, többnyire „univerzális” feladatra, szabványos illesztőfelülettel. A részegység tervezés már messze van a rendszer integrátori feladatoktól. Ma már elég ritka, hogy ugyanaz a csapat helyezi üzembe a berendezést, mint aki tervezte.
Az innovatív területeken már nem az elektronikáé a fő szerep, hanem az információtechnológiáé.
A szűkebben vett elektronika építőköve lett egy magasabb szervezettségű alkalmazástechnológiának.
A részegységek integráltságának növekedésével, funkcionalitásuk kiterjedt, sok esetben szoftver cserével további javításokat, bővítéseket lehet megvalósítani. A hierarchia felső szintjén meg szinte kivétel nélkül egy „univerzális gép” áll.
Vegyük észre, hogy a kor ipari technológiája már nem választható szét önálló elemekre! Egy új minőségben, egy új , magasabb szerveződési szinten jelenik meg. Az információtechnológia átszövi a különböző tudományos területeket. Megjelenik a mindennapjainkban, részévé vált és már elszakíthatatlan tőle.
Ezen gondolatok mentén a környezetünkről alkotott képünk is meg kell, hogy változzon. Már nem lehet egyedi „részecskeként” kezelni egy problémát. A feladatmegoldások már rendszerszintű gondolkodást, tervezést igényelnek.
Most persze vannak akik azt mondják: „..mit okoskodik?! Különben is mindez triviális és rég tudjuk!”

Lehetséges. De nap, mint nap nem ezt látom a környezetemben. És talán az összefoglalással más megvilágításban mutathattam rá saját motivációimra is.

Egyébként is a „szómenés” az egyik legrosszabb tulajdonságom...

Szeretnék a topikon belül egy apró kitérést tenni, ami lényegében a témához kapcsolódik. Úgy gondoltam, hogy talán más színnel írva elválaszthatnám a fővonaltól. Mit javasolsz? Mi lenne a jó megoldás?

De szépen mondtad!

Esettanulmány I.

Egy nagy szállodalánc egyik épületében, az IT rendszerek terméhez saját klímarendszert alakítottak ki. Az eredeti megvalósítás hagyományos hőmérséklet szabályozása eleget tett az IT termek igényeinek, tetemes villamos energia felhasználás árán. A nagy fajlagos energia fogyasztás csökkentése miatt kezdeményezték a hűtési rendszer átvizsgálását és optimalizálását, az üzemeltetési költségek csökkentése érdekében.

Főbb paraméterek:

- hűtőventillátor (5.5 kw)
- hűtőaggregátor (35 kw)
- szivattyúk (5 kw)

Elérendő célkitűzések:

- teljesen automatikus működés
- legalább 15-20%-os energiamegtakarítás
- illeszkedjen a már meglévő épületfelügyeleti rendszerbe
- a beruházási költségek alacsony szinten tartása
- távfelügyelet, HMI operátori felület
- adatrögzítés, hibanaplózás

S1_1. ábra

Ennek a feladatnak a megoldása egyrészt a hűtőkörök átépítésével járt, másrészt a technológiához kapcsolódó szabályozás újragondolását tette szükségessé. Jó hagyományaink szerint nem az elérendő cél határozta meg a budget-et, hanem adott volt a beruházási keret....
A tervezési fázisban sok szóba jöhető eszköz alkalmazhatósága – gondolok itt PLC-kre – mérlegelésre került, elsősorban az adott szabályozási feladatot szem előtt tartva. Több megoldás is felmerült, ám a kötött költségkereteken mind megbukott.

Javaslatom alapján egy soft plc/soft computing technológiát alkalmaztunk.

Terveink szerint több bemeneti és kimeneti változóra épített fuzzy szabályozó gondoskodik a frisslevegő ventillátor fordulatszámának, valamint a pillangószelep állásának szabályozásáról a külső levegő, a hűtő aggregátor kondenzációs körének  és az IT termek hűtőköri visszatérő ágának hőmérséklete alapján.
A technológia módosításakor már az új koncepció alapján épültek be az érzékelők és a szabályozók.
Esetünkben a szabályozás input jeleit csak hőmérséklet érzékelők adják. A kimenetek pedig egyrészt diszkrét értékű vezérlőjelek, másrészt 0-10 V tartományú analóg jelek. A szabályozás természetesen csak része a teljes technológia kiszolgálásának. A berendezésnek gondoskodnia kell a megfelelő védelmi és vezérlési funkcióról is.

Röviden a soft plc-ről: említés szintjén már jelen témánkban is szó esett erről a technológiáról. A lényege, hogy az eszközök integráltsági foka már elérte azt a szintet, hogy egy kompakt ipari számítógép kerüljön beépítésre, arra bízva a vezérlési, szabályozási és egyéb kiszolgálási (kommunikáció, SCADA, HMI, archiválás/eseménykezelés stb.) feladatokat. Így a koncepciónak megfelelően többnyire eltekintünk a hard plc alkalmazástól, a számítógép csak távoli I/O perifériákon keresztül kapcsolódik a környezetéhez. A plc funkciókat a számítógépen futó taszk valósítja meg, de nagyságrendekkel nagyobb szabadsági fokon, hiszen nem korlátozza semmi a kapcsolódó I/O eszközök, csatornák, a TAG-ek számát, nem köt a liszenc díj. E mellett egy számítógép olyan lehetőségei integrálható a feladatmegoldásba, ami konvencionális eszközökkel nem, vagy körülményesen és korlátozottan valósíthatóak meg. A logolás, archiválás és távoli hozzáférés már nem is kérdéses, hiszen minden adott hozzá.

A rendszerterv és a kivitelezés elkezdésének feltétele a pontos feladatmeghatározás. A tervezőnek pontos leírást kell adni a folyamatokról, úgymint a részegységek működési/retesz szekvenciája, fizikai paraméterek értéktartománya, a szabályozáshoz szükséges alapértékek, működési tartományok.

A működés röviden a következő: optimális energiafelhasználás akkor érhető el, ha igénybe vesszük a külső levegő hőkapacitását a hűtési folyamatban és egyidejűleg minimalizáljuk a szükséges ventilátor, hűtőaggregátor teljesítményt. Ennek érdekében a program a mindenkori külső hőmérséklet függvényében üzemmód előválasztást alkalmaz (nyári, téli és kevert). Az üzemmódválasztás nem direkt, a pillanatnyi hőmérséklet függvénye, hanem egy trend figyeléssel kombinált eljárás eredménye, amelyben egy adott időszak hűtési igényeinek és a rendelkezésre álló természetes és forszírozott hűtőkapacitás viszonya a meghatározó. Téli üzemmódban nincs szükség a hűtőaggregátorra, így a hűtőfolyadék útja más mint nyári üzemben. Ekkor a szivattyúk közvetlenül egy kis kapacitású hőcserélőn keresztül közvetlenül szállítják a léghűtőre a hőmennyiséget. A ventilátor kb 40%-os fordulatszámon üzemel és a visszakeverő szeleppel történik a szabályozás. Amikor a külső hőmérséklet változása miatt már nem elégséges a léghűtés, akkor időszakosan belép a hűtőaggregátor. Nyári üzemmódban a pillangószelep lezárja a közvetlen áramlást a léghűtő felé, ilyenkor kizárólagosan a folyadékhűtőt vesszük igénybe. A ventilátor a hűtési ciklus alatt fordulatszám szabályozással üzemel.
Rámutatnék arra a tényre, hogy nem az IT terem hőmérsékletét szabályozzuk közvetlenül! Az elsődleges szempont a rendszer optimális termodinamikai állapotának fenntartása. (A hűtőaggregátor hatásfoka egy adott - előremenő/visszatérő ág viszonylatában - hőmérsékleti tartományon belül optimális. Az alatt pazarolja az energiát, a fölött pedig túlmelegszik és leáll. A hőcserélők is egy meghatározott hőlépcsőt igényelnek az optimális működéshez stb.)

S1_2. ábra

A hűtési rendszer elkészült, feltöltötték hűtőfolyadékkal és „bedrótozták” az érzékelőket, beavatkozókat, vezérlőszekrényt. Ebben a fázisban minden egy nagy fekete dobozban végződik, amelyen belül nincs konkrét, direkt kapcsolat a részegységek között. A beépített technika nem más mint egy alkatrészhalmaz. Ami igaz is!

S1_3. ábra


A fekete doboz a számítógép, a rendszer „agya”. A programrendszer felöltését követő indításkor kerül ki csipkerózsika álmából. Esetünkben az agy szürkeállományát a háttértárolón sorakozó bitek milliárdjai képezik.

S1_4. ábra

Nagyjából 30 bemenet, 15 kimenet és 120 változó az amit a program kezel. Természetesen nem csak a fizikai input csatorna tiszta állapotváltozása hordozza az információt, hanem például egyes jellemzők változási sebessége, egymáshoz való viszonyuk stb.

A HMI felületen a technológia stilizált sémája látható, az üzemeltetéshez szükséges információk megjelenítésével. Úgymint hőmérsékleti értékek, nyomáskapcsolók státusza és üzemi állapotjelzések, hibajelzések.

A távfelügyeletre, menedzselésre, karbantartásra több csatorna áll rendelkezésre. Csak betekintésre, ellenőrzés céljából web alapú hozzáféréssel java applet-et, karbantartásra ssh tunneling-et (RSA titkosítással, 4096 bites kulccsal), más felügyeleti rendszerek felé pl. modbus emulációt használhatunk. Adatkapcsolati médiaként szinte bármi illeszthető (kis túlzással egy papírhajó is). Alapértelmezésben 3G HSDPA protokollal kapcsolódik a felügyeleti VPN-hez.

S1_5. ábra

A működéshez szükséges adatkezelésről és az archiválásról BerkeleyDB adatbázis motor gondoskodik. A mintavételi gyakoriság lehet statikus és eseményvezérelt. Az archiválási időszak pedig csak a háttértároló kapacitásától függ (akár évek..). Jelen alkalmazásban egy 64 GB-os SSD található.
A logolás/archiválás fontos eszköze egyrészt az üzembe helyezésnek, másrészt az üzemállapotok későbbi elemzésének.

S1_6. ábra

Az ábrán valós üzemi körülmények között látható az egyes paraméterek időbeli lefutása.

A bekapcsolást és üzembe helyezést követően azóta is működik, több mint 30 %-os energiamegtakarítással.

Az egyensúlyozást áttekintettük, de hogyan halad a robot?

Mint láttuk az egyensúlyozás lényege, hogy zérus legyen a robot tengelyének függőlegessel bezárt szöge és szögsebessége. Ha haladó mozgást akarunk létrehozni, akkor mesterségesen kell gondoskodni a θ>0 állapotról. Amennyiben nem nullára, hanem egy offset-el megnövelt értékre szabályozzuk a robot dinamikus helyzetét, haladó mozgást idézünk elő abban az irányban, amerre „dől” a robot függőleges tengelye. Belátható hogy a robot haladási sebessége arányos a függőlegessel bezárt szöggel, ám ez nem lehet bármekkora. Ennek megfelelően limitáljuk a maximális szöget. Az irányváltás a segway-nél egyszerű: ellenkező irányú szögeltérést kell beállítani. A robotnál csak „előre” irányú a szögelfordulás. Egy másik különbség a segway és a robot irányítása között, hogy míg az elsőnél az utas súlypontjának áthelyezése befolyásolja a jármű mozgását, addig a robot parancsok szerinti „belső kezdeményezéssel” változtatja meg saját mozgásállapotát.

Az egyensúlyozás és haladó mozgás esetében a tengelyekre leképezett elmozdulás nem más, mint irányváltó gyorsuló és lassuló tengelyforgások folyamata.

Video: MotorTest_1

Ezen folyamat kontrollálásához szükség van a robot dinamikus állapotának érzékelésére, amit egy 3D gyorsulásmérővel tehetünk meg.

Mi a gyorsulásmérő? Hogyan működik és mit mér? Hogyan jutunk el egy gyorsulásmérőtől a tengely mozgatásáig?
Az interneten több mint elég leírás található a témáról. Annyit tennék hozzá, hogy a MEMS szenzorok gyártótól és típustól függően különböző érzékenységgel és kialakításban készülnek. A tesztekhez csak digitális szenzorokat használtam. Az első amit még a topik elején említettem, az az MMA7455 Parralax gyártmányú modul. Ez egy I2C vagy SPI buszon kommunikáló eszköz. Mivel nem akartam csak a teszt miatt egy áramkört építeni, ezért most ki sem próbáltam.
A második egy RS232-es csatornán csatlakoztatható gyorsulásmérő. Két alapvető adatformátumot támogat: RAW és g-hez kalibrált. (Itt említem meg, hogy a szenzorok többnyire a gravitációs állandóhoz kalibráltan kerülnek forgalomba.) Az eszköz egy terminálfelületen át paraméterezhető és olvasható. A kimeneti jeltartománya -1 és 1 között változik koordináta tengelyenként. A bemutatott gyorsulásmérő kimenő jele vízszintes helyzetben 0, 90 fokkal elfordítva az y tengely körül 1, -90 fokkal a 0 értékhez viszonyítva -1 nagyságú. Így, a robotra rögzített szenzor elfordulás szögét -1..1 tartományban változó értékű kimenő jel mutatja, amely arányos a szöggel.

Video: AccTest_0

Aki már használt inerciális szenzorokat tapasztalhatta, hogy stabil állapotban is fluktuáció található a kimenő jelben. A zaj forrása lehet többek között tápvezetéken megjelenő zaj, mintavételi kvantálási zaj, felépítésből eredő saját zaj, vagy éppen a robot mechanika saját rezgése jelenik meg zajforrásként. Ez a felhasználás szempontjából zavaró jel, amit a feldolgozás során eliminálni kell. Amennyiben nem gondoskodunk erről, úgy az a rendszer lengését, instabilitását okozhatja és nem utolsó sorban egy hamis eredményt ad. A robot egyensúlyban tartásához zajtól, rezgésektől mentes jelre van szükség. A zaj tényén kívül még van egy másik dolog ami zavaró lehet a pontos dőlésszög meghatározásában. A legtöbb MEMS eszköz - felépítésénél fogva - az elfordulás szögével nem lineáris kimenőjelet generál. Az érzékenységük éppen 90, -90 foknál a legkisebb, ezért esetenként kiegészítő szenzorra kell támaszkodni a pontosabb eredmény elérése érdekében. Tipikus kiegészítője egy másik inerciális szenzor, a giroszkóp. A giroszkóp önállóan hasonló problémákat hordoz – főleg drift-et -, de szenzorfúzióval kombinálva a két szenzort rendkívüli pontosság érhető el.

A szenzorok jelének szűrésére, kondicionálására gyakran jelszűrést alkalmazunk. Hogyan lehet egy jel zajszintjét csökkenteni? Talán nem kellett volna feltenni a kérdést, mert sokféleképpen....
Szűrőkkel.
A digitális szűrők témaköre igen nagy, én csak két lehetőséget említek. Az egyik egy mozgó ablakos átlagolás, a másik a Kalman szűrő.
Eltekintenék a matematikai formulától, inkább működő kódokat mutatok be.

A mozgó ablakos átlagolás sok szakterületen alkalmazható, statisztikus számítási eljárás. Különféle időben zajló folyamatok tendenciáját, trendjét mutathatja meg alkalmasan megválasztott feltételek mellett. A digitális jelfeldolgozásban az átlagoló szűrő lényegében aluláteresztő szűrőként viselkedik (mert az...). Ez az egyik leggyakrabban használt lineáris szűrő.

Működésének lényege, hogy egy idősor adatait - az n-edik elemet időben megelőzően - bevonjuk a számításba, így n-2, n-1, n elem vesz részt egy három tagú átlagolásban. Az időbeliségét az biztosítja, hogy az átlagolást követően a legrégebbi elem kiesik, a legfrissebb pedig belép az adatelemek közé. Az elemszám növelésével növekszik a fluktuáció elnyomása. A mintavételi gyakoriság és az elemszám megválasztásával hangolható a szűrő.



A kódrészlet egy egyszerű átlagolást mutat be, melynek egyik hátránya, hogy az adatelemek számától függően a szűrő kimenete nagy késést mutathat a bemeneti jelhez viszonyítva. Másik hátránya, hogy egyenlő súllyal veszi figyelembe a legrégebbi és legfrissebb adatelemeket így a trendváltozások késéssel detektálhatók.
Enek kiküszöbölésére a súlyozott, exponenciális átlagolás az elterjedtebb módszer. Szinte valamennyi digitális jelfeldolgozó eszközben megjelenik. Ez annyiban különbözik az előzőtől, hogy az n-edik elemet súlyozottan vesszük figyelembe az átlag számítása során.

A következő szűrőtípus a Kalman filter. A Kalman nevével jegyzett eljárás sokkal több mint egy digitális szűrő algoritmus. Kalman dolgozta ki a diszkrét rendszerek állapotterére vonatkozó állapotbecslést, ami egyfajta statisztikai módszer. Tulajdonságai messze a leghatékonyabb eljárások sorába emelte, mert prediktív állapotbecslést valósít meg az átlagos négyzetes hiba minimalizálása mellett úgy is, ha időben hiányos az adatsor. A szűrőalgoritmus a rendszer modelljének ismerete nélkül is lehetővé teszi az időállapotok becslését.

Röviden az elmélet lényege: A „klasszikus” állapotbecslések többségében statisztikai valószínűségszámításokon alapuló interpoláció útján valósulnak meg. Ezen eljárások feltételezik az időben változatlan hibákat. A Kalman filter egyik újdonsága, hogy figyelembe veszi a rendszer hibájának időbeli változását, amihez egy időben fejlődő mátrixot alkalmaz. A bevezetett variancia (vagy szórásnégyzet) operátorok megmutatják, hogy egy-egy valószínűségi változó milyen mértékig szóródik a várható értéktől (eloszlás). A számítás során folyamatos időbeli korrekcióra kerül sor a várható érték tekintetében, a pillanatnyi mért érték és a kovariancia mátrixok állapota alapján. Az eljárást Kalman kiterjesztette 3 dimenziós terekre is.

A következő videón - az előzőhöz viszonyítva nagyobb felbontással és statikus állapotban - a gyorsulásmérő valósidejű kimeneti értéke látható. A felső idődiagram a zajjal terhelt szűretlen pillanatnyi értéket mutatja, a középső a Kalman filter kimenetét, az alsó pedig a mozgó ablakos átlagolás eredményét.

Video: Acctest_1

A képeken a szűrt és szűretlen jele idődiagramja látható 1 sec időtartamú intervallumban. Az első kép dinamikus állapotú, a második nyugalomban lévő szenzor esetében készült. Egy képen belül a felső trend a Kalman filter-t, az alsó pedig a mozgó ablakos átlagolást viszonyítja a bemeneti jelhez.

63. ábra

64. ábra

A következő kódrészlet egy egyszerűsített – egydimenziós – szűrő megvalósítását mutatja be, mely a gyakorlatban jól használható a zajok eliminálására.



A szűrő inicializálása után, minden egyes mérési ciklusban korrekció történik a várható érték előrejelzésében. A szűrő viselkedését a paraméterek megváltoztatásával lehet hangolni. (Természetesen hatással van a szűrőre a mintavételi gyakoriság, a futási idő stb.)

Nem is kérdéses, hogy melyik szűrési eljárást használom fel. A későbbiekben a Kalman filter kiterjesztett válozata is megjelenik az orientációs és lokalizációs számítások során.

Folyamatosan készülnek a leírások és közben azon gondolkodom, hogy milyen mélységig dokumentáljam a robot éledését. A programrészek más területen is hasznosak lehetnek. A kérdés az, hogy ti is így gondoljátok-e? A programok teljes forrását, a header fájlokat és telepítési útmutatókat is csatoljam? Mit javasoltok?

Szia!
Én csak érdeklődve nézem jelenleg, de ha lenne időm és felraknád, akkor szívesen nézegetném ( persze, csak ha nem sértjük az üzleti érdekeidet !) !

További jó munkát, jók a leírásaid, lehet belőle tanulni !

Nekem az a véleményem, hogy amit szerinted érdemes szóban kifejteni, azt nyugodtan fejtsd ki, a többit meg csatolhatod zip-ben is! Vétek lenne, ha bármi is elveszne

Az előzőekben utaltam a giroszkóp tulajdonságaira amire most visszatérek. De először vizsgáljuk meg miért van szükség giroszkópra! A giroszkóp 1-3 térbeli tengely mentén történő elfordulás érzékelésére alkalmas MEMS szenzor. Felépítésénél fogva a szenzor, a tengelye körüli elfordulás szögsebességével arányos jelet ad. A szögsebességet ω-val jelöljük, mértékegysége rad/sec.

Egy térbeli objektum orientációjának meghatározásához elengedhetetlen annak, egy rögzített koordináta rendszerhez történő relatív viszonyítása. A pontosság feltétele, hogy az objektum környezetéhez való viszonya numerikus értékként ismert legyen. Gyorsulásmérővel is van lehetőség orientáció meghatározásra, de több tekintetben a giroszkóp alkalmasabb erre a feladatra. A giroszkóp sokkal érzékenyebb, a gravitációs erővonalak irányától függetlenül. Ráadásul az elfordulás szögsebességével egyenesen arányos jelet szolgáltat. Ezen tulajdonságok lehetővé teszik, hogy az orientációt közvetlenül szögekben tudjuk kifejezni.

Nyugalmi helyzetben a giroszkóp kimenetén – amikor a szögsebesség nulla - egy állandó érték mérhető, melyet offset-nek nevezünk. Ezen kívül a szenzor jellemezhető egy érzékenységgel (mV/°/sec) és egy érzékelési tartománnyal (pl. 0-1000 °/sec). A kimeneti jel lehet analóg és digitális. (Megjegyezném, hogy különböző gyártmányú eszközök adatlapján változhatnak a dimenziók – sok helyen rad-ot használnak.)

A szenzor nagyon pontos szögsebesség értéket szolgáltat, de az esetek többségében szögelfordulásra van szükségünk. A szögelfordulás könnyen származtatható a szögsebességből: a szögelfordulás a szögsebesség időbeli integrálja. A szenzor alkalmazása során mégis adódik egy nehézség, ez pedig a drift.

Video: GyroTest_0

A videón tipikus jelalakokat lehet látni. Az idődiagram a szögsebességet mutatja, a compass pedig annak alapján számított szögelfordulást. A szögelfordulás előjele mutatja meg, hogy a rögzített kezdeti irányból óra járásával megegyező vagy ellentétes elfordulás útján jutott jelenlegi helyzetébe a szenzor. (Negatív előjelű a szög ha például a robot többszöri balra kanyarodással jutott jelen helyzetébe.)

65. ábra

Az ábra egy általános szögsebesség-idő diagramot szemléltet. Az 1.2 összefüggés első része megmutatja, hogy a szögelfordulás a görbe alatti terület nagyságával egyenlő. Amennyiben periodikus jelről lenne szó és/vagy ismert lenne a szögsebesség időbeli lefolyásának függvénye, számolható lenne a szög értéke. Mivel általában (vagy sohasem?!) ismert a függvény, így csak az 1.2 összefüggés második részének megfelelő diszkrét integrálást tudjuk megvalósítani. Az egyenlet szerint a görbe alatti területet felbontjuk m számú téglalapra és az egyenként számított területüket összegezzük.
Nem utalnék vissza az integrálás értelmezésére de jelzem, hogy az adott diszkrét számítási eljárás pontossága nő, ha ∆t_n tart nullához. Az ábrán jól látható az adott módszerből eredő hiba: a példa szerint ha nő az időintervallum, akkor nő a görbe és a téglalap alatti területek közötti különbség. Nagyobb meredekségnél jobban növekszik az eltérés.

Jól látható, hogy az egyes elfordulásokhoz tartozó mérési eredmények nincsenek szinkronban a szenzor valós térbeli helyzetével. Az is tapasztalható, hogy ez az eltérés sok összetevőtől függhet, így például a szögsebességtől, zavarjelektől stb. A mérés így közvetlenül nem alkalmas pontos szögelfordulás megállapítására.

De mi a helyzet a megvalósítással? Megállapíthatjuk, hogy a valós fizikai folyamatok időbeli változását csak diszkrét értékekben ismerhetjük. Ez részben az analóg-digitális átalakítás következménye. A konverziós idő végén kvantált értékek formájában áll rendelkezésünkre a „pillanatnyi” szögelfordulás. Ezt tovább rontja a szenzor és a jelfeldolgozó közötti kommunikációs folyamat. Az adatátvitel valamint a jelfeldolgozásban résztvevő programciklus futási ideje tovább növeli az egymás utáni mérések között eltelt időt. Ha figyelmesen nézzük a diagramot és az egyenletet látható, hogy a mért érték csúszása részben számítási pontatlanságból ered. Ezt egyszerűen nem tudjuk közvetlenül kiküszöbölni, bár törekedni kell a minél nagyobb pontosság elérésére. (Nagy sebességű A/D átalakító, gyors processzor, gyors adatcsatorna stb.)

A fentiek ismeretében hogyan számolhatunk szögelfordulást egy giroszkóp jeléből?
Nagyon egyszerűen!

Vezessük be a következő változókat:

gyro_data - mért érték (V)
offset - a szenzor jele nyugalmi helyzetben (V)
T - mintavételi ciklusidő (sec)
rate - az offset-hez viszonyított érték (V)
sensitivity - érzékenység (V/°/sec)
angle - szögelfordulás (°)


A drift csökkentése érdekében a változó típusok megválasztása is fontos, mert így csökkenthetjük a számábrázolási pontatlanság, kerekítési hiba befolyását - célszerű double típust használni integer helyett. A T csökkentése szintén csökkenti a hibát. Mindezek azonban nem adnak megoldást az offset problémára. A tényleges megszüntetése időszakos, vagy folytonos korrekcióval lehetséges (szenzorfúzió).

Hogyan kapcsolódik a giroszkóp a lokalizációhoz és orientációhoz? A lokalizáció nem más, mint objektumok térbeli helyzetének meghatározása – irány, távolság, magasság stb. Ezen adatokhoz pedig, az objektum időbeli orientációinak és azokhoz tartozó elmozdulásainak ismeretében jutunk.

Esettanulmány II.

Aszinkron kommunikáció

A különféle eszközök előzetes kipróbálása, tesztelése minden alkalommal felvet valamilyen adatkapcsolati kérdést. Így van ez a robot tervezésének folyamatában is, ahol minden érzékelő és részegység valamilyen digitális adatátviteli csatornán keresztül kapcsolódik a számítógéphez.
Nem tudom más hogy van vele, de nekem mindig prompt az aktuális helyzethez kellett igazodnom. Akkor kell hamarjában megvalósítani az összekapcsolást amikor az újabb eszközök kipróbálására kerül sor. Az esetek többségében az egyik oldal a számítógép. A teszt- és felhasználói programok egyediek, így a kommunikációról nekem kell gondoskodnom.
Az operációs rendszerek flexibilitása ellenére az egyedi igények miatt mindig meg kell írnom a kommunikációt kezelő programrészt. Most csináltam egy „standard”-et, ami a legtöbb felhasználáshoz megfelelő lehet.
A linux platform szellemiségének megfelelően sok esetben használok fel GPL licenszelésű programrészeket, programcsomagokat, vagy éppen ugyanazon licensszel teszem közzé a saját kódjaimat. Így van ez a serialib függvénykönyvtárral is.

A serialib soros kommunikáció kialakítását teszi lehetővé. Lehetséges a Linux, Windows, MAC OS platformok alatti felhasználása.

Két részből áll: Az első egy header fájl, a második pedig egy osztály definíció. A felhasználói programba include-álni kell a serialib.h fájlt és hozzá kell fordítani a serialib.cpp-t.

serialib.h
serialib.cpp

A mintaprogram egy alkalmazási példát mutat be, amelyben a motorvezérlőt illesztem a számítógéphez.



A serialib alkalmas bármilyen kommunikációs eszköz kezelésére, ami úgy viselkedik mint egy szabványos soros port. A port tehát lehet - a teljesség igénye nélkül - /dev/ttyS0, /dev/ttyS1 stb.; /dev/ttyUSB0, /dev/ttyUSB1 stb.; /dev/ttyACM0, /dev/ttyACM1 stb. A protokoll természetesen a mindenkori végberendezéstől függ. A porthoz csatolt busz lehet RS232, RS485, RS422 stb.

A fordítás az alábbiak szerint lehetséges:

# g++ -g -c mot.cpp serialib.cpp
# g++ -g -o mot mot.o serialib.o

A programot futtató felhasználónak dialout csoport tagnak kell lenni (vagy root-nak), hogy jogosultsága legyen az eszköz használatához.

Felhasználó hozzáadása csoporthoz:

# useradd -G dialout username

Még néhány megjegyzés: a serialib karakter típust használ a kommunikáció során, így típus konverzióra lehet szükség a további felhasználáshoz. Az olvasás h0A karakterig történik, a Split() függvény pedig levágja a felesleges karaktereket a vett adatsorból. A típuskonverziót a String_to_Float() függvény valósítja meg.

Esettanulmány III.

Szinkron kommunikáció, GPIO

Tovább gördítve az esetenkénti kommunikációs igény témakörét, nem csak aszinkron hanem szinkron adatátvitelre is szükségünk lehet, mint pl. I2C, SPI. Nevezetesen a gyorsulásmérők és giroszkópok többsége az előbb említett buszon kommunikálnak. Nem is szólva arról, hogy sokszor van szükség egy, a „polcról levehető”, könnyen kezelhető „digitális vezérlőre”. Persze mindezt úgy szeretnénk, hogy előzetesen ne barkácsoljunk egy áramkört...

Az előző okfejtés megvalósítására kiváló lehetőséget nyújtanak az FTDI chip-ek felhasználásával megépített interface áramkörök. Mint köztudott FTDI cég – többek között - USB portra csatlakoztatható periféria illesztő áramkörök gyártására szakosodott. Ezen eszközök többsége már tartalmaz egy un. MPSSE (Multi-Protocol Synchronous Serial Engine) funkcót (motort). Az MPSSE azt a lehetőséget nyújtja, hogy e kis méretű USB illesztő segítségével többféle szinkron kommunikáció legyen megvalósítható. A bitbang üzemmódon keresztül pedig az adatvonalak egyedi vezérlését is lehetővé teszik, mintegy GPIO portot biztosítva a felhasználónak.

A szemléltetésként egy C232HM kábelen alapuló alkalmazást mutatok be. (Létezik 5V-os és 3.3V-os változatban is.)

C232HM kábel

MPSSE_Basics

Mint a robot kapcsán említettem, nem volt időm, kedvem SPI interface-t építeni így a tesztekhez is ezt a interface-t használtam. Külső járulékos áramkörök nélkül illeszthettem közvetlenül számítógéphez az SPI bus-os giroszkópot. Az alábbi videó az első példája egy LED ki- bekapcsolását, a második pedig PWM vezérlését mutatja be.

Video: MPSSE_Test

Debian alapú rendszerekben a fordításhoz szükséges csomag telepítésének menete:

#apt-get install libftdi-dev

A libftdi-dev telepítésével már közvetlenül elérhetjük a bitbang üzemmódot.



A fordítás menete:
# g++ -I/usr/local/include/ -L/usr/local/lib/ -o led led.cpp -lftdi -lm




A fordítás menete:

# g++ -I/usr/local/include/ -L/usr/local/lib/ -o pwm pwm.cpp -lftdi -lm

SPI, I2C, JTAG funkciók közvetlen eléréséhez még telepítenünk kell a libftd2xx1.1.12.tar.gz csomagot.

A csomagot letöltve, kibontva és a ReadMe.txt fájl leírása szerint eljárva írhatjuk, olvashatjuk a fent említett adatbuszokat.

További példák a libftdi2xx csomag example mappájában találhatók. A ../release/build/i386/statictest programmal tesztelhetjük a számítógépünkhöz csatlakoztatott eszköz működőképességét.

Kis szünet, munka volt... de folytatom. Ott hagytam abba, hogy lokalizáció és orientációt.... Egy korábbi alkalommal már jártunk itt, de akkor teoretikusan. Most viszont konkrét megoldással közelítek újból.

Kicsit hezitáltam, hogy mivel folytassam. Aztán úgy gondoltam, hogy maradok a mozgásállapotok elemzésénél amire a robot tér érzékelése elsődleges visszahatással van. Hogyan érzékelheti a robot a környezetét? Mely módszerek hordoznak megbízható és egyben komplex információt?

Számtalan elképzelés született már az autonóm robotok térbeli helyzetének megállapítására, nyomon követésére. Csak néhány elgondolás: ultrahangos távolságmérés, lézeres letapogatás, inkrementális jeladók használata (odometria), képalkotó eljárások. Nem is sorolom.

A GiantsBot esetében – mint ahogyan már erről is esett szó - én a képalkotást választottam elsődleges szenzorként.

Mint már eddig jó pár dolgot, úgy a képalkotás mikéntjét is átformáltam ahogyan bővült az elérhető eszköztár. Mielőtt a tényleges hardver felépítését áttekintenénk, először bemutatom azon módszereket amelyek által „érzékszervekkel” ruházom fel a robotot.

Jelen esetben az orientáció és lokalizáció alavető eleme az optical flow jelenségen alapuló eljárás lesz.

Optical Flow (optikai áramlás)

Először is próbáljuk megfogalmazni a „jelenséget”! Mi az optikai áramlás? Az optikai áramlás egy olyan dologra utal, amit naponta megtapasztalhatunk. Lényegében, optikai áramlás az a látszólagos vizuális elmozdulás, ahogy a világban mozogva érzékeljük azt. Például autóvezetés közben, járművön utazva vagy sétálva a haladás irányába előretekintve a táj, a fák, az épületek stb. közelednek hozzánk, elhaladnak mellettünk. Úgy tűnik hátrafelé, mögénk mozdulnak el.

Valójában egy nagyon egyszerű, mégis összetett dologról van szó. Fizikai modellé egyszerűsítve a helyzetet egy mozgásegyenletet írhatnánk fel, amely jól definiálná a mozgás nagyságát, irányát stb. Ugyanakkor a szubjektív percepció, amely az érzékszervünkön, szemünkön keresztül képezi le az agyban mozgásunkat, összetettebb élményt nyújt. A látáson keresztül megjelenik számtalan optikai törvényszerűség, úgymint pl. a környezetünk perspektivikus leképezése.

A perspektíva, már a korai középkortól kezdődően sem csak képzőművészeti fogalom volt, hanem kiindulópontja más tudományágaknak úgymint a filozófiának és az optikának. Az előbbi elsősorban a „látott valóság agyban való leképeződését, értelmezését kísérelte meg értelmezni, míg az utóbbi a szem modelljét az optikai reflexió példája szerint próbálta megkonstruálni, az érzéki elemek matematikai projekcióra való redukciója által” ami végül is megteremtette a látás mai fogalmát. (Gottfried Boehm: Látás)

A 15. században Leonardo da Vinci már jól ismerte a geometriai alakzatok - mint például piramisok – felhasználását lineáris függvények szemléltetésére. Perspektíva tanulmányainál a lineáris arányok ábrázolására használta és megfigyeléseit így fogalmazta meg: „Minden dolog a saját képét egy vonalakból álló piramis útján továbbítja a szemnek. Vonalakból álló piramison azokat a vonalakat értem, amelyek az egyes tárgyak felületének széleiről indulnak ki, bizonyos távolságból összetartanak, és egyetlen pontban találkoznak … amely a szemben helyezkedik el.” (F. Capra: Leonardo és a tudomány)

66. ábra

Ez gyakorlatilag az egyik perspektivikus leképezési mód megfogalmazása.

Az optikai áramlás fogalmának közvetlen körvonalát kissé túlléptem, de mint látni fogjátok a későbbiekben éppen a perspektivikus projekció az egyik módszer, ami által a 3D-s teret 2D-s térbe tudjuk transzformálni.

Helyezzünk kamerát az eseménytérbe! Ha megvizsgáljuk a kamera képét azt tapasztaljuk, hogy a kép statikus környezet esetén sem állandó. Ez több okból következik. Valójában a körülöttünk lévő világ szinte sohasem abszolút mozdulatlan. Ezen túlmenően a képalkotásban megjelenik a zaj és a tömörítési eljárásokból eredő képtartalom változás stb. A kamera vagy egyéb objektumok mozgása dinamikus változást hoz létre a képtartalomban. Ezt a változást használjuk fel a környezetünk detektálására.

Válasszunk ki egy pontot valamely a környezetünkben lévő tárgyon. Redukáljuk pontszerűvé az objektumot, idealizálva a kísérletet. Mozgassuk a tárgyat „A” pontból „B” pontba. Eközben vizsgáljuk a kamera 2D-s síkjára vetített pontok helyzetét. Az látjuk, hogy a síkra vetített pont (p') a térbeli pont (p) elmozdulásával arányosan mozog. A vetítési sík koordináta tengelyeit U,V-nek nevezve felírhatóak az adott pont elmozdulás szerinti koordinátái. („A” pontnak megfelelő kiinduló pozíció: (u,v), „B” pontnak megfelelő pozíció: (u+∆u, v+∆v).) A két pontot vektorral összekötve megkapjuk a vizsgált pont elmozdulásvektorát. A kamera látómezejében mozgó pontok 2D-s síkra vetített elmozdulásvektorainak összességét mozgásmezőnek nevezzük.

67. ábra

Nézzük meg, hogy milyen általános tulajdonságokkal bír egy mozgásmező!

Világos matematikai összefüggés van az optikai áramlás nagysága és a kamera (szemlélő) objektumokhoz való viszonya között. Ha duplájára növeljük a kamera sebességét, akkor duplájára fog nőni az optikai áramlás nagysága is. Ha egy objektum kétszer közelebb kerül, akkor az objektum optikai áramlása is kétszer nagyobb lesz. Ha az objektumok egyedi pontjait vizsgáljuk azt tapasztaljuk, hogy azokra is ez a törvényszerűség érvényes. Az optikai áramlás nagy mértékben függ a haladási és az érzékelési irány által bezárt szögtől. Így például állandó sebességgel haladva nagyobb optikai áramlást tapasztalunk a haladással növekvő szöget bezáró irányok esetén. Egy általános mozgásmezőt elemezve azt látjuk, hogy a képsík széleihez közeledve növekszik a mozgásvektorok nagysága. Ezen túlmenően a látótérben találunk egy pontot, amelynek a legkisebb vagy nulla a mozgásvektora. Ezt a pontot FOE-nek (Focus of Expansion – expanziós fókusz) nevezzük. Amennyiben a kamera nem előre, hanem hátra mozog, úgy erre a pontra FOC-ként (Focus of Concentration – koncentrációs fókusz) hivatkozhatunk.

68. ábra

Máris egy fontos jellemzőt ad meg a mozgástér elemzése. Az FOE a haladási irányt jelöli ki.

Mielőtt további következtetéseket próbálunk levonni a mozgástérből, szólni kell a képfeldolgozás módszereiről, hiányosságairól.

Sokak számára biztosan ismerős fogalmak az apertúra és parallaxis. A mozgástér elemzésénél az un. apertúra probléma az egyik legjelentősebb. A képfeldolgozó algoritmusok a mérésre kiválasztott képpontok környezetének elemzésével határozzák meg a mozgásvektorokat. Olyan képi objektumok esetében ahol a haladás irányában stacionárius a képtartalom, nem jár az elmozdulás pixel intenzitás változással, ott nem lehet megbecsülni a mozgásvektor nagyságát, irányát. A másik nehézséget a mozgásparallaxis hordozza. Két pont valódi térbeli helyzetét nem lehet egyértelműen meghatározni egy nézőpontból.

De egyáltalán hogyan lehet képpont elmozdulásokat detektálni? A digitális kamerák egy stream-et állítanak elő, melynek elemi egysége a frame. Az egyes képek között eltérés tapasztalható – a korábban említett zavaró tényezőkön túl – ha a kamera és az objektumok egymáshoz képest mozognak. Állandó mozgási sebességet feltételezve két képkocka között annál nagyobb az eltérés, minél hosszabb idő telik el a két jelenet között. Tehát megfelelő rátájú mintavételezést alkalmazva hozzájutunk azokhoz a képekhez, amelyek információt hordozhatnak. A különböző képkockákon összehasonlításra kerülő képpontok kiválasztása fontos metódus. Egy n-edik képkockán kiválasztott pixel pozícióját keressük az n+1-ik képkockán. Amennyiben sikeres a képpont azonosítása számolható a mozgásvektor. Több módszer létezik, egyik leggyakrabban alkalmazott a Lucas és Kanade algoritmusa. A módszer alapja, hogy sima mozgásfüggvényt keres egy adott pont kis kiterjedésű környezetében. A simaság azt jelenti, hogy az adott pont közelében lévő pixelek esetében is hasonló mozgásvektor értékekre számít. Lényegében a mozgásgradiens differenciálhányadosával operál. A végeredmény az, hogy jó valószínűséggel becsülhetőek a kisebb elmozdulások.

Mindegyik módszernek van előnyös és kevésbé előnyös tulajdonsága. A legtöbb esetben videofelvételeken kisebb eredményességgel alkalmazhatók, mint real-time stream esetében. Ennek elsősorban az intenzitás megmaradás elvének sérülése az oka. (Legtöbb algoritmus működésének rögzített alapfeltétele, a képpontok időbeli állandó intenzitása.)

A következő filmrészlet szemlélteti egy tetszőleges stream optikai áramlás elemzését.

Video: Optical Flow

A második video csak a mozgásmezőt mutatja be.

Video: Vectors

Az optikai leképezés modelljének vizsgálatával számos következtetést tudunk levonni az optikai áramlásból. Milyen információkra van szükségünk a robot mozgását és helyzetét illetően?
A GiantsBot haladása közben ismernünk kell a a relatív, vagy kvázi abszolút pozícióját. Az előbbi alatt azt értem, hogy a kijelölt mozgástér – önkényesen rögzített koordináta rendszer - egy kitüntetett pontjához való viszonyt kell ismernünk. Az abszolút pozíció értelmezése egy globálisabb rendszerhez viszonyított helyzet, például a földi hosszúsági és szélességi koordináták szerinti pozíció.
E mellett biztosítanunk kell az akadály és ütközés elkerülést.

Lényegében minden szükséges elemet érintettem ahhoz, hogy segítségükkel biztosítani lehessen a robot navigációját.

Vizsgáljuk újra a mozgásmezőt, most már az akadálykerülés és ütközés elhárítás szempontjából.

De először megint egy kis matematika!

Mi az az összefüggés, ami alapján bármi következtetést le tudunk vonni az optikai áramlásból?

69. ábra

Az ábrán egy mozgó kamera környezetéhez való viszonyát rajzoltam le. Az O pont jelzi a kamerát. P pont vetítőernyővel párhuzamos síkjának távolsága O-tól Z. FOE – O egyenestől P pont X, p' pedig x távolságra van. P(t) – vagyis P pont t időpillanatban - δ szög alatt látszik O pontból FOE-O egyeneshez viszonyítva, ami a haladási iránnyal esik egybe.
Az előzőekből ismerve a mozgásmező tulajdonságait tudjuk, hogy a kamera mozgása közben a látószög időben változik. Ennek megfelelően P pont vetülete a Plane ernyőn elmozdul, aminek sebessége V_x. Az elmozdulás gyorsasága fordítottan arányos az objektum robottól mért távolságával. Ennek alapján 69.[1.] arányosság írható fel.

Differenciálás után a [2.] összefüggést kapjuk. Helyettesítsük x ̇ -ot V_x-el, Z ̇-ot -V₀-val, és Z-t d * cos δ-val. Ezekből kifejezve a pixel elmozdulásának sebességét (V_x) a [3.] egyenletet kapjuk. Megjegyzem, hogy x ̇ és Z ̇ bevezetése az értelmezés szempontjából volt szükséges, mivel az elmozdulás időbeli differenciálja a sebesség.

Mire jó ez az összefüggés?

Ebből az egyenletből egy olyan következtetést tudunk levonni, amely megfelelő stratégia lehet az akadálykerülésre. Nevezetesen, úgy kell a robotnak mozogni, hogy az FOE ponttól balra és jobbra lévő mozgásmezőben a pixelek horizontális elmozdulási sebességátlaga közel egyenlő legyen. Ezt a szakirodalom általában Balance Strategy-nek ( kiegyensúlyozó stratégia) nevezi. Másként leírva: haladás közben a kamera által érzékelt kép bal és jobb felén kalkulált elmozdulásvektorok nagysága attól függően változik, hogy a robothoz milyen közel kerül egy-egy objektum. Kellő távolság esetén nincs nagy különbség a két oldal pixeljeinek átlagsebessége között. Ha egy akadály kerül a robot útjába, megváltozik a két oldal optikai áramlása. A [4.] egyenlet a beavatkozó jelet fejezi ki.

Ezen összefüggés alapján csak akkor lehet vezérelni a robotot, ha egyenes a haladási irány. Egy önálló „mesterséges intelligencia” viszont szeretne „céltudatosan” haladni egy mozgástérben. Ehhez hozzátartoznak a fordulások, az ütközés elkerülések, az iránytartás és a mozgási sebesség változásai is. Ezen a feltételek alapján ki kell egészíteni a vezérlési stratégiát.

Kiegészítés nélkül gyakorlatilag analóg egy vonalkövető robot működésével. A különbség az, hogy a vonalkövetés esetén külső „kényszer” a vezérlő jel, ami direkt visszacsatolásban van a motorvezérlőhöz. A kamerával felszerelt robot viszont autonóm döntéssel irányítja a hajtást a külvilágból érkező információk feldolgozása által.

Ha valamelyikőtök kíváncsi egy általa választott videorészlet mozgásmezőjére, szívesen megcsinálom. Csak mutassátok az elérhetőségét!

Ha nem nagy kitérő, akkor pár szót vesztegethetnél arra, hogy az optical flow-ban hogyan keresed meg egy pixel új helyzetét a képen! Ez ugye akkor nehézkes, ha több azonos/hasonló szín is van a képen, ekkor hogyan döntöd el, hogy melyik melyik volt? Például a tornyházak emeletei eléggé hasonlítanak egymáshoz, pláne hogy messzi is vannak, és még zajos is.

Nem kitérő! Bármikor szívesen...

Említettem, hogy az intenzitás megmaradás feltételezése alapvető kritérium a legtöbb módszernél. Kissé kibontva azt feltételezzük, hogy két egymást követő képkockán a színek intenzitása nem változik, csak az egyes pixelek (objektumok) mozdulnak el. E mellett számtalan feltételezéssel kell élni, úgy mint pl. az objektumok alakja nem változik, nem kerülnek takarásba stb. Látható, hogy igen szigorú feltételrendszer esetén írható le olyan modell, amellyel detektálható egy kiválasztott képpont a másik képkockán. Ez a valóságban nem így van. A legtöbb feltétel valamilyen szinten sérül. Tehát a kiindulási alap az intenzitás megmaradás, melynek összefüggése az alábbi:

E(x, y, t) = E(x+u, y+v, t+1)

Ha egy (x, y) pozícióbeli pont elmozdul u, v-vel, akkor t+1 időpontban az új pozíció koordinátái (x+u, y+v) lesz.

Másként fogalmazva

E(x(t), y(t), t) = c

a c intenzitású pont pozíciója x(t) és y(t) függvények szerint változik, miközben az intenzitás állandó. Az egyenletet differenciálva c nulla lesz. Így már az egyenletből kifejezhető a képi gradiens és az optikai áramlás vektora közötti összefüggés. A kifejtéstől eltekintenék, csak megjegyzem hogy az előzőekben leírt összefüggések egy képpontra vonatkoztak. Mivel a korábban említett apertúra probléma és intenzitás fluktuáció fennáll, úgy egy meghatározott terület intenzitás átlagával számolnak (pl. 5x5-ös pontmátrix). A képfeldolgozásban igen egyszerűen megoldhatóak a pontmátrixokra vonatkozó differencia számítások, amihez gyakran konvolúciós mátrixot alkalmaznak.

Konvolúciós kódolás

Rendszerint az egymást követő képkockák különbségével végezzük a differencia számítást. Ezen megfontolások alapján keresünk olyan jól körülhatárolt ponthalmazt, amelyek esetében az intenzitás megmaradás érvényesül, vagyis azonosítható az adott pont, ezáltal az elmozdulása két egymást követő képkockán. A különböző megoldások két képkocka pontjai közötti egyezőség vizsgálatát blokkegyezés alapú algoritmusokkal – keresztkorreláció, négyzetes különbség stb. - valósítják meg. A feldolgozási sebességet jelentősen befolyásolja az ablakméret.

Még annyit tennék hozzá, hogy az ilyen összehasonlításra alkalmas pontok egy un. sarok detektáló algoritmus felhasználásával kerülnek kiválasztásra. Olyan pontokat (képpont tartományokat) választunk ki erre a célra, ahol jól detektálhatóak az objektumok sarkai.

Corner Detection

A hivatkozott Lucas-Kanade összefüggés leírása itt található:

Lucas-Kanade

A gyakorlati alkalmazás szempontjából nem feltétlenül szükséges az összefüggések kimerítő ismerete, mivel a legtöbb fejlesztői könyvtár kidolgozott függvényeket, osztályokat tartalmaz ezen feladatok megoldására (pl. OpenCV).

A robot nem egyenes vonalon mozog, hanem a megkerülő manőverek kapcsán el is fordul. Ezért a 69. ábra [4.] egyenlete módosul:

SteeringCommand = k * ((V_xR – V_xL) + Rotation)

A Rotation változó az optikai áramlás felső részéből számított átlag elmozdulásvektor. (Valójában a vektorok horizontális komponenseinek átlaga.) A k egy arányossági tényező, melyet részben a kalibrálás során használhatunk, másrészt befolyásolja a rendszer dinamikáját (erősítés). Minél nagyobb k, annál agresszívebben reagál a beavatkozójel. Miért éppen ezen terület vektoraiból számítjuk az elfordulást? Valójában az FOE pont fölötti képrészről van szó, amelyben már az akadálykerülés szempontjából nincs hasznos információ és még elég közel van az FOE ponthoz, hogy minimális legyen vektorok y komponense.

Video: Orientáció_1

A robot haladásának szempontjából egy másik fontos dolog az ütközéselkerülés. Ezt szintén az optikai áramlásból vezetjük le. Ehhez tekintsük át megint az optical flow tulajdonságait! Mint már láttuk, az FOE pontból sugárirányban a képmező széle felé növekvő expanziót tapasztalunk. Tételezzük fel, hogy a robot egy előtte elhelyezkedő akadály felé halad (ez általában egy nagyobb tárgy, fal stb.) Amennyiben relatíve közel kerül az objektumhoz, úgy az elmozdulásvektorok nagysága megnövekszik. Az ütközés elkerülésére leginkább használható képterület a képmező felső harmada. Az elfordulás detektálással szemben itt a vektorok y komponense alapján becsüljük meg az eseményt. Egy referencia értékhez hasonlítva az átlagértéket, detektálhatjuk ha a robot közel kerül az ütközéshez.

Video: Collision

A videó a GiantbBot szemszögéből mutatja környezetét. Az akadály felé közeledve megnövekszik a függőleges vektorkomponensek átlagértéke. Ezen érték időbeli változását láthatjátok CollisionLevel grafikonon, a Collision-on pedig az ütközési határ elérését.

Nincs szabály a detektálási területek pontos kijelölésére. Empirikus ismeretekre hagyatkozhatunk, minden esetben egyedileg lehet meghatározni az optimális beállítást.

Remélem sikerült válaszolnom!

Ha valahol nem érthető a leírás, vagy az egyes részek közötti összefüggés, netán kérdésetek van velük kapcsolatban, kérdezzetek! Megpróbálok válaszolni.

Köszönöm, igen!

Még nem mutattam be videón a módosított 69. ábra [4.] összefüggés alkalmazását ami most itt látható:

Video: SteeringCommand

Enyhe értelmezési presszióként azért elmondom, hogy az akadály felé közeledve a mutató jelzi a szükséges manőver irányát és intenzitását az akadálykerülés érdekében. (Óramutató járásával megegyező elfordulás "jobbra", azzal ellentétes irányú elfordulás "balra" parancsnak felel meg.)

Visszatekintve, elég sok dolog szóba került az elmúlt időszakban. De mindez elég egy robot irányításához? Esetleg ki kell egészíteni más érzékelőkkel, eljárásokkal?! Mit gondoltok erről?
Van valamilyen elképzelésetek, hogy milyen módon lehetne még „jobbá” tenni a navigációt? Működőképes egyáltalán az eddigi elképzelés? Szívesen megvitatnám veletek az ötleteiteket, észrevételeiteket!

Eddig csak ittam szavaid, próbáltam okosodni. Lehet hogy tévedek, de nem változott már az eredeti elgondoláshoz képest a koncepció? Onnan indultunk ki, hogy hogyan jutunk el A-ból B pontba. Ez már akkor is érdekes volt számomra, de gondoltam majd kiderül hogy mire gondolsz. Most már ott tartunk, hogy van egy vázad ami képes menni, képes arra hogy akadályt észleljen, és elvileg akár ki is kerüli. De a fő kérdés: Hová akar menni? Hivatkoztál egy térképre, és szépen ködbe is veszett itt minden. Idézek:

Ezzel kapcsolatban van valami fejlemény? Fentről nézed webkamerával, és böködöd hogy ide kell menni, vagy hogyan?? Most magam elé képzelem az autós videót a városban, rögtön utána pedig a ház belső terét mint eseménytér

Szerk: Továbbá volt itt sztereo látás is, ehhez képest most optical flow a robot motorja.

Bocs, közben elment a netem.. Szóval azt még oda akartam biggyeszteni, hogy nagy tisztelettel szoktam olvasni az írásaid, és remélem még sokat lesz rá alkalmam

Változott a koncepció? Nem tudok róla.… Számomra változatlanul „A” pontból „B”-be való jutás a „feladat”. Lehetséges, hogy időközben beiktattam egy kis szünetet, netán kitérőt... de valahogy még mindig az idézett cél a meghatározó. Biztosan van olyan akinek a megoldás rövidebb ideig tart, de úgy tűnik nekem több idő kell hozzá.

Érdekesnek tartom azt, hogy ismételten felbukkan egy olyan gondolat amit már egyszer elvileg körbejártunk: nevezetesen, „ ... hová akar menni?”. Talán elevenítsük fel újból! Hadd hivatkozzak én is a teljes szövegre.

http://www.hobbielektronika.hu/forum/topic_post_1029404.html#1029404

Ám a robot sehová sem akar menni! Nincs tudata, csak az utasításokat hajtja végre. A korábban megfogalmazott két pont közötti mozgás egy egyszerűnek tűnő példaként került megfogalmazásra. Mondhattam volna azt is, hogy „ugorjon le a robot az Astoriánál, egy közeli közértbe három kifliért...”. A robotot mozgató fizikai – mechanikus és elektronikus – felépítésen, a szoftvertechnológián és mindezek integrációján van a hangsúly.

Te mire gondolsz?



Kíváncsian várom a válaszod, hogy végre közös nevezőre jussunk az idézett szövegrész értelmezésében.

Térkép? Nem volt semmilyen konkrét térkép... de akár lehetne is. Készíthetnénk térképet is, lehetne az is a navigáció alapja. A hivatkozott idézet csak példaként említ egy nemlétező térképet. Webkamerával sem nézem felülről a robotot, ha ezt tenném, akkor nem beszélhetnénk autonom robotról.
Még nincs konkrét elképzelésem a pontos célmegadásra, de szerintem valami hasonlót fogok választani, mint amikor valaki megcímez egy postai küldeményt. A cím roppant rugalmas valami. Lehet utca, házszám alapú, netán hosszúsági és szélességi koordinátákkal megadott. De lehet egy tér szubjektív módon megválasztott koordinátái alapján is pontokat címezni. Ehhez valóban kell egy virtuális térkép, amiben definiálni lehet, kell a rendelkezésre álló tér kiterjedését, valamint a kiindulási és célpozíciót. Majd ennek ismeretében meg lehet adni a címet a robotnak. Hogyan? Fantázia kérdése. Akár szóban is. Mindenesetre egyelőre egyszerűbb módot választanék, például egy felhasználói interfészen keresztül egyszerűen beírom a cél koordinátáit.

Sztereó látás.... Igen, volt. Azt nem mondom, hogy marad is. Azt viszont mondhatom, hogy a szetereó látás hozadéka – mármint a térlátásból eredeztethető távolságbecslés – változatlanul szükséges.
Bővebben: A sztereó látást elsődlegesen azért vettem be a szenzorok közé, mert a robot környezetéről mélységi térképet akartam létrehozni. Talán utaltam is rá, hogy ehhez több eszköz is kinálkozik. Egy sztereó kamerapár tűnt elérhetőnek és célszerűnek az adott feladat szempontjából. Elemzése során eljutottunk odáig, hogy a képfeldolgozás eredménye egy Depth Map, és itt megálltunk. Az Optical Flow semmivel sem priorabb eljárás mint a mélységi térkép létrehozása, hanem kiegészítik egymást. Annyi történt, hogy a kérdésed két hozzászólásomat megelőzte, ti. hamarosan visszakanyarodok a Depth Map-hez. A robot működése csak a külvilággal való szoros kapcsolódás által biztosított. Különféle szenzorok helyezhetőek el rajta, de ezek önmagukban csak a külvilág érzékelését látják el, azt is speciális szempontból. Ez analóg azzal, hogy a magasabb rendű biológiai rendszerekben beszélhetünk érzékelésről és észlelésről. A külvilág szenzorokon keresztüli érzékelése még nem észlelés, az csak a mögöttes agyi működés következményeként válik percepcióvá. Kiegészíteném azzal (mint ahogyan már korábban is megtettem), hogy az előbb említett rendszerekben „szenzorfúzió” által alakul ki a végleges észlelés. Így van ez a GiantsBot-nál is.
Nos, számunkra a mélységi térkép a fontos, nem a mód ahogyan hozzájutunk.
Lesz még több dolog is amivel időlegesen elszakadok a fő iránytól, hogy valahol később egyesüljenek az oldaljáratok.

Itt a közös nevező Így már rendben vagyunk!

A kitérőkkel semmi baj nincs, valamiért azt hittem hogy kizárólag az Optical Flow lesz alkalmazva. Most hogy mondod, hogy a másikra is visszatérsz és együtt alkalmazod őket, ez is ok!

Nem akarok ám kekeckedni, csak furinak tűnt a dolog.

Hogy a feltett kérdésedre is válaszoljak, nálunk embereknél sincs sokkal több érzékszerv a közlekedéshez. Ha mélyebben bele akarunk merülni ebbe, akkor szükség lenne a helyszín, méginkább az elvárások konkrétabb definiálására. Erdőn-mezőn, Marson, városban, lépcsőn akarod járatni, esetleg ezt így mind együtt? Tudom, érintőlegesen volt már erről is szó, de nyilván a te fejedben sokkal részletesebb terv van, mint itt a topicban. Ugyebár egyenúlyozni nem kell, mert stabil a szerkezet. A látást már megoldottad, de legalábbis a hardweres részét igen. Hallásra gondolom nem lesz szüksége, ha mégis akkor is csak a parancs vételéhez. Esetleg felmerülhet hogy ha jön egy autó oldalról, akkor a hallás elindíthat egy "menekülő" algoritmust, miáltal az ütközés elkerülhető. De szerintem ez csak kitérő, max a V2.0-ás verziótól érdekes. Gravitáció szintén nem érdekes, szerkezetileg biztosított az egyensúly.
Érzésem szerint egyenlőre csak a szoftveres dolgokkal kell törődni, például a fent említett célmegadást kidolgozni.

Valóban, az "akar" szót nyilván idézőjelben értettem. Viszont az "utasítás" is pontosításra szorul! Utasítás az is, hogy bal motor két teljes fordulat előre, majd jobb motor állj! De az is, hogy menj a töltőhöz! Előbbinél elemi utasításokról beszélünk, vagyis távirányítjuk a masinát. Ezen a szinten nem beszélhetünk robotról, hiszen nem autonóm. Második esetben csak kijelöljük az elvégzendő feladatot, és a megoldás teljes egészében rá van bízva a robotra (ahogy "akarja"). Na ez már autonóm.
Én legalábbis így értelmezem a dolgokat.
Megjegyzem, hogy nem értek a témához, csak ami ragadt rám, inkább a józan paraszti hozzállás az amire képes vagyok Remélem hozzászólásaimmal nem térítelek el az útirányodtól, de ha már megvitatnál, akkor én itt vagyok!