Önálló laboratórium dokumentáció Fémgolyó irányítása játéktáblán neuroheadset segítségével
Készítette: Trásy Tamás BJ1E43 Konzulens: Mészáros Tamás A feladat, és annak módosítása Az eredeti elképzelés szerint egy fémgolyó mozog a játéktáblán. A mozgás irányát a headset által vett parancsok adják. A játéktábla egy vékony, műanyag (vagy fa) lap, alatta egy mágnest mozgat egy szerkezet tetszőleges x-y koordinátákba. A lap fölött a golyó kényszerűen követi a neki kijelölt útvonalat, a mágnes vonzása mindig a mágnes fölé görgeti. A feladat megvalósítása során két komoly problémába ütköztem. Az első az volt, hogy a mechanika speciális alkatrészeket igényel. A mágnes mozgatását úgy képzeltem el, hogy egy H alakú keret középső sínje függőleges irányban mozog a másik két sínen; és a középső sínen jobbra-balra mozog a fej, amin a mágnes van.
Kép forrása: 8linx.com [7] A síneket úgy kell megvalósítani, hogy kis súrlódással mozogjanak rajta a kocsik, és ne legyen játéka. A motorok forgó mozgását lineárisra kell átalakítani, és viszonylag messzire továbbítani. A képen látható megoldás erre csavarmeneteket használ, ami a mi esetünkben lassú lett volna. Lehetne még bordásszíjjal, fogasléccel, de ezek pontos ellendarabokat igényelnek. Az adott méretű fogaskerék nem biztos, hogy felrakható a léptetőmotor tengelyére. A két léptetőmotorról, amivel dolgoztam, le se lehetett szedni a gyárilag felrakott fogaskereket. Így egy hozzá illeszkedő fogasléc
keresése nem lett volna egyszerű. Felvetődhet az ötlet, hogy nyomtatóból, szkennerből lehetne kibontani a fejeket; de jobban végiggondolva nem nagyon van olyan eszköz, ami két lineáris tengely mentén tud mozogni. A nyomtató egy lineárisan mozgó fejet használ, és alatta forgó mozgással továbbítja a papírt. Egy nyomtató fejét egy szkenner olvasófejére rögzíteni úgy, hogy működjön - az nem sokkal egyszerűbb, mint egy teljesen új szerkezetet megépíteni.
Kép forrása: jovoplaza.hu [8] Itt jutott eszembe a képen látható gyerekjáték. A két oldalon golyókkal húzhatjuk a madzagokat, amik középen egy V-alakban belógatott kocsit mozgatnak. A fakorong közepén egy lyuk van, amiben a golyó ül. Ha a golyó a táblába fúrt lyukak fölé ér, akkor átesik a táblán. Ennek a gépesítése jóval egyszerűbb. A két madzagot kell feltekerni a léptetőmotorokra rögzített dobokra. A másik, talán komolyabb probléma az volt, hogy a négy irányba mozgatáshoz négy különálló parancsot kell megtanítani a headset szoftverének. Nekem kettőt sem sikerült teljesen megbízhatóan megtanítani. A gond valószínűleg az volt, hogy nem tudtam hosszabb ideig ugyanazt a gondolati mintát tartani. Talán kissé türelmetlen is voltam. Ha már egy ideje próbáltam tanítani egy parancsot, és a szoftver nem ismerte fel pár másodperc után, akkor elkezdtem gondolkodni, hogy vajon miért nem működik. Ez viszont már nem az a minta, amit a headset vár, így természetesen nem ismerte fel. Ennek az ellentéte is gyakran előfordult. Amikor végre felismerte a kiadott parancsot, úgy megörültem neki, hogy egyből megváltoztattam a mintát, így elejtette az utasítást. A mintáknak ráadásul időben nem szabad változniuk. Nekem sokszor előfordult, hogy elképzeltem egy betanítandó mintát, de a szoftver valószínűleg a mintának nem arra a részére tanult rá, amit én a lényeges tulajdonságnak tekintettem. Vegyük például azt az esetet, hogy elképzelem, ahogy egy nehéz dolgot tolok előre, és közben látom az ujjaimat, ahogy a tolt tárgyon fekszenek. Később próbálom előhívni a képet, de közben nem képzelem el az ujjaimat; esetleg elképzelem, csak más fényviszonyok között, akkor már jelentősen változhat a minta. Lehet, hogy a headset éppen akkor tanult rá, amikor épp az volt a fejemben, hogy a tolás közben a vállam, karom megfeszül. Később aztán amikor próbálom visszaidézni, akkor lábammal a talajnak feszülésre fektetek nagyobb hangsúlyt. Közben a monitoron lévő kockára is figyelek, míg az első tanításoknál nem érdekelt annyira. Ezek jelentősen megváltoztatják a headset által vett jeleket. A fentiekben mind a tolást gondoltam a művelet legfontosabb részének, de az agyam közben mindig más részletre fókuszált, apró részleteket megváltoztatott. Lehet, hogy hosszabb tanítás után sikerült volna a programnak felismernie, hogy mi az, ami mindegyik képben közös volt. Én is biztos sokat fejlődtem volna az egymásra jobban hasonlító minták előállításában.
Így azonban sokszor olyankor érzékelte az egyik irányparancsot, amikor nem akartam vezérelni a programot. Legalább ilyen gyakran másik irányt érzékelt, mint amire gondoltam; sokszor pedig hiába koncentráltam, nem indult egyáltalán semerre. Ezek a jellegű bizonytalanságok egy irányítási rendszerben megengedhetetlenek. Ha a golyó éppen egy lyuk mellett áll, és az ellenkező irányra koncentrálunk, és pont ennek hatására megy bele a lyukba, az felettébb frusztráló. Konzulensemmel, Mészáros Tamás tanár úrral abban állapodtunk meg, hogy ha az explicit iránymegadás megbízhatatlan, akkor inkább próbálkozzunk az agyi jelek alapján mozgatással, de szabadabb asszociációban. Tehát a játék valamilyen mozgást végez az agyi jelek hatására, de a pontos irány nem fontos. Így golyót irányítani nem praktikus; tehát inkább rajzoljon a szerkezet. A feladat innentől tehát egy plotter, ami az agyi jelek alapján rajzol - hasonlóan az EEG-hez. A megvalósítandó lépések
A feladatot felbonthatjuk egy pár különálló lépésre. A lánc egyik végén a headset áll, a másikon a rajzoló fejet mozgató mechanika. A headset a jeleit a számítógépnek az USB-s vevőn keresztül juttatja el, majd az Emotiv saját szoftvere értelmezi a kapott jeleket. Az eddigiek adottak; ezekkel nem kell foglalkoznunk. A plotter vezérléséhez meg kell írnunk egy szoftvert, ami az Emotiv API-n keresztül lekérdezi a már értelmezett adatokat, jeleket. Ezek alapján kialálja, hogy milyen irányba kell elindítani a mozgatást, milyen sebességgel. Ezeket a jeleket kiküldi a számítógépen kívül található elektronikának. Az elektronika fogadja a szoftver vezérlőjeleit, és felerősíti a logikai jeleket olyan szintre, hogy a motorokat meg lehessen hajtani vele. A motorok meghajtják a mechanikát, ami a kívánt irányba mozgatja a rajzoló fejet. Nézzük a lépéseket részletesebben!
Szoftveres feldolgozás
A szoftver megírásakor a windowsos környezet adott volt, hiszen a headset saját szoftvere ott működik. Így egy konzolos win32 alkalmazás írása mellett döntöttem. Így nem kellett foglalkoznom a grafikus felület írásával. A rendszer adatait folyamatosan tudtam a konzolba írni. Ha valamilyen új, vagy ideiglenes információt akartam kiíratni, akkor nem kellett új szövegdobozt, kijelzési mezőt létrehoznom a grafikus felületen. A programprototípusok fejlesztése közben a konzol általában meglehetősen hasznos. A program nyelve C. A C++, illetve az objektumorientált megközelítés általában nagyon jót tesz egy kód áttekinthetőségének, és minőségének, de én elsősorban a működő állapotot szerettem volna elérni. A kód nem is lett túl átlátható, rengeteg javítanivaló van rajta. A headsettel való kommunikációra az Emotiv API-t használtam. Ebbe nem nagyon ástam bele magam, az egyik mintaprogram kódját értettem meg, és átemeltem belőle a nekem hasznos részeket. A perifériák kezelése a windows API-ján, illetve könyvtári függvényeken keresztül történt. A randomszámgenerálás (diagnosztikai célú rajzoláshoz) és a képernyőre írás a C nyelv könyvtári függvényeivel történt. Az időzítés, a többszálas futás, billentyűzetkezelés és a soros kommunikáció a windows saját függvényeinek hívásával került megvalósításra. A tesztek közben hibaként jelentkezett, hogy időnként a kontroller felé megszakadt a soros kapcsolat. Ennek okát nem sikerült kiderítenem, valószínűleg a windowsban a soros port konfigurálásánál rontottam el valamit. Elhárítása nem egyszerű; a kontrollert ki kell húzni a számítógépből, a programot leállítani, majd visszadugni és elindítani őket. Ennél kevesebb beavatkozásra nem oldódott meg a probléma. Ennek javítása fontos feladat.
A rajzolás irányítása
Határbeállítások: Manuális irányítás: X-Y irányítás:
T R G F W S E D U H J L
A mozgató programrész kétfajta mozgatási módot ismer. Az első teljesen manuális, mindenféle konverziótól mentes. Itt a lenyomott gombokkal közvetlenül megadhatjuk a két motornak, hogy eressze ki, vagy húzza be a madzagokat. A másik üzemmód az x-y koordinátarendszerbeli mozgást próbálja imitálni. Ha felfelé, lefelé parancsokat adunk ki, a két motor egyszerre ereszti, illetve húzza be a madzagokat. A jobbra-balra mozgásnál az egyik motor kifelé engedi, a másik befelé húzza a felfüggesztést; a rajzoló kocsi így közelítőleg oldalirányba mozog. Az automata rajzolás közben a program a másodikat használja, csak a parancsokat nem a billentyűzetről olvassa be, hanem az aktuális koordináták és a headset jelei alapján dönti el, hogy merre haladjon tovább a vonal. Az automatikus rajzoláshoz a szoftvernek ismernie kell a rajztér határait. Ezt a program indítása után egy egyszerű kalibrációval végezzük el. Az első mozgatási üzemmódban, a motorok direkt vezérlésénél a program nem ellenőrzi, hogy átléptük-e a határokat. Ezzel bemozgatjuk a tollat a rajztér közepére, majd egy billenytűvel rögzítjük azt. Ezután a felső és alsó határok beállítása következik, majd a lap egyik szélére elmozogva a vízszintes határbeállítás. Ezt csak az egyik oldalra kell elvégezni, a program feltételezi, hogy a másik irányba is ugyanennyit lehet kitérni. Vízszintes irányban ez jól működik; függőlegesen viszont nem. Ugyanis a lap teteje felé egy egységnyi függőleges lépés jóval nagyobb, mint a lap aljánál. Így a lap közepét szemre meghatározva a szoftver koordinátarendszerében messze nem a középpontot határoztuk meg. Így szükség van az alsó és felső határ külön megadására. A mozgások a mechanika felépítése miatt nem lineárisak; sajátos köríves torzítást figyelhetünk meg az egyenesnek szánt mozgásoknál. Emiatt a szoftveresen adott vízszintes eltérítés a lap alján okozza a legnagyobb fizikai eltérést a középvonaltól. Ezért az oldalhatárokat praktikusan az alsó végállásban állítjuk be. A határok beállítása után a második vezérlőmódban, a jobbra-balra-le-fel módban nem tudjuk elhagyni a rajzterületet. Ez érvényes az automata rajzolásra is, az sem tud kilépni belőle. A direkt vezérléssel azonban továbbra is el tudjuk hagyni azt.
A jelek kijuttatása a számítógépből Az elektronika és a pc közötti kapcsolattartáshoz valamelyik porton ki kell adni a motorok vezérlőjeleit. A léptetőmotorok vezérléséhez nagyon jó lehetőség lett volna a párhuzamos port, ugyanis annak elég lábát lehet le- és felkapcsolgatni ahhoz, hogy ne kelljen soros-párhuzomos átalakítást elvégezni a számítógépen kívül. Sok projekthez használják a gépnek ezt a kimenetét. Pár egyszerű FET-tel vagy tranzisztorral kapcsolgathatjuk a motorok tekercseire a tápfeszültséget, így vezérelve azokat. Így a számítógépen kívül megspórolhatjuk az esetleges jelátalakításokat, mikrokontrollereket. A megoldás hatalmas előnye az egyszerűség, és alacsony alkatrészigény, tehát költség is. Párhuzamos port azonban nincs sok mai számítógépen; és mégiscsak elegánsabb valamilyen modernebb perifériát használni. A soros port használatának ötlete felvetődhet még; azonban ebben az esetben már mindenképpen szükséges valamilyen elektronika, ami átalakítja a soros jeleket párhuzamossá. A soros port jelszintjei sem kompatibilisek az érzékeny kontrollerek bemeneteivel. Ha már úgyis szükségünk van külső logikára, akkor nem nagy ugrás az USB port használata. Ez minden mai gépen megtalálható, és még nagyon sokáig meghatározó periféria lesz.
Kép forrása: logsys.mit.bme.hu [1] Az első motorvezérlési próbálkozásaimat a tanszéki FPGA-kártyával vittem végbe. Ezeket a beágyazott és ambiens rendszerek laboratórium tárgy házi feladataihoz kaptuk kölcsön. A kártya egy, a Spartan-3E családba tartozó, Xilinx gyártmányú IC-t használ központi vezérlőként. Pontos típusa XC3S250E-4TQ144C. Az chip bekapcsoláskor a kártyán található flash memóriából olvassa be a programot. Saját, belső programtárolásra nem képes, azonban ezzel a megoldással nem kell minden bekapcsoláskor számítógépről feltölteni a kódot. A kártyán található perifériák között van hétszegmenses kijelző, ledes pontmátrix, nyomógombok, DIP-kapcsolók, és ledek. Ezek közül én csak a ledeket használtam. A 8 led a léptetőmotor lábaira adott feszültségeket jelezte vissza, így ránézéssel meg lehetett állapítani, hogy merre próbálja hajtani a motorokat, van-e a kimenetén jel, illetve hány pólust hajt meg egyszerre. Az FPGA nem tartalmaz dedikált hardveres UART támogatást, így a protokollt nekem kellett megvalósítani. A számítógépen futó szoftver egy bájtnyi információt küld ki az USB porton. A nyolc bit a két léptetőmotor lábaira adandó jeleket kódolja. A chip a GPIO (general purpose input/output) lábakra rakta ki a nyolc beérkezett bitet. Miután az FPGA-kártya tudta vezérelni a léptetőmotorokat, elkezdett zavarni, hogy feleslegesen nagy teljesítményű, és értékű hardvert használok erre az egyszerű feladatra. Utánanéztem, hogy milyen olcsóbb, egyszerűbb megoldások vannak a problémára. Kézenfekvő ötlet volt valamilyen mikrokontroller használata.
A mikrokontrollerek nagy része támogatja hardveresen az UART protokollt; az USB viszont csak a komolyabb modellekbe van beépítve. Lehet kapni USB-UART átalakító IC-t, körülbelül 800-900 forintos áron. Az Atmel kontrollerjei között találhatjuk még meg például az ATmega8U2 chipet, ami beépített USB vezérlővel rendelkezik. Bolti ára körülbelül 1200 forint. Ehhez persze még hozzáadódik a programozó ára.
Kép forrása: Texas Instruments [2] A megfelelő megoldás keresése közben találtam rá a Texas Instruments MSP430-as családjához készített fejlesztőkártyára, a Launchpad-re. A kártya közepén egy DIP foglalat található, ebbe az MSP430G2 család tagjait helyezhetjük. A csomaghoz két kontrollert kapunk, az MSP430G2553-as az erősebbik, 20 lábbal; és egy kisebbet, a G2452-est, 14 kivezetéssel. A csomag ára Amerikában 4.3 dollárról indult; a tavasszal felemelték 10 dollárra. Én itthon 1900 forintért tudtam megvenni egy elektronikai boltban. Ez nagyon kevés pénz egy fejlesztőkártyáért. Sok mikrokontrollerhez csak a programozó ennek a többszörösébe kerül. Az illusztrációtól eltérően az én változatomra gyárilag felforrasztottak két apa csatlakozósort, amire a kontroller lábai voltak kivezetve. A csomagban van anya foglalatsor is. Azzal talán egy fokkal egyszerűbb lenne a kezdők számára a projektek bekötése; ugyanis a foglalatba bele lehet dugni a drótot, míg a tüskére feltekerni, vagy megbízhatóan rögzíteni nem olyan egyszerű úgy, hogy közben ne érjen hozzá a szomszédos tüskékhez. A korábbi modelleket anya foglalattal szállították; a fórumokon látható a vevők elégedetlensége a váltás miatt. A kártyán két led van, egy zöld és egy vörös. Két gomb van a nyákon; ezek közül azonban csak az egyiket programozhatjuk, a másik a reset gomb. A kevés periféria azonban nem komoly hátrány, a kontrollernek ugyanis az összes lába ki van vezetve, és az előbb említett perifériákat jumperrel leválaszthatjuk a lábakról. Így például a ledek leválasztása után bemenetnek is felprogramozhatjuk az adott vonalakat. A kártya felső részén látható szaggatott vonal mentén a gyártó szerint elvághatjuk az áramköri lapot. Így a kontrollernek egy kényelmesen használható foglalatot kapunk, a két leddel és nyomógombbal ellátva. A tápot ilyenkor a kártya jobb alsó sarkában lévő tüskéken át adhatjuk a kártyára. Ha később szükségünk lenne a kontroller átprogramozására, a két felet egymás mellé helyezve jumperekkel újra összeköttetésbe hozhatjuk. A csomagban kapunk még egy külső oszcillátort is. A nyákon ennek a helye üresen van hagyva; a csomagban találhatótól eltérő frekvenciájú kristályt is beépíthetünk. A kontrollerek a saját kategóriájukban az alacsony fogyasztásukkal járnak az élen. A hasonló árú Atmel és Microchip modelleknél kisebb áramot vesznek fel alvó állapotban, működő időzítő mellett. A számítógépre fel kell ugyan telepíteni a drivereket (a Windows XP legalábbis nem ismerte fel magától), de utána egyszerű USB soros eszközként tudunk kommunikálni az eszközzel.
A kártya felső részén látható IC-k a beérkező USB jeleket UART-tá alakítják, és az elválasztóvonalon lévő jumperek orientációjától (és persze a kontroller programozásától) függően a chip hardveres vagy szoftveres UART kommunikációját tudjuk használni. Én a hardveres kezelést választottam, azzal jóval egyszerűbb lett a kód. A mikrokontroller programja a következőképpen néz ki: #include <msp430.h> extern void CSL_init(void); int main(void) { CSL_init(); P1OUT&=~BIT4; P2OUT&=~BIT0; P2OUT&=~BIT1; P2OUT&=~BIT2; P1OUT&=~BIT7; P2OUT&=~BIT5; P2OUT&=~BIT4; P2OUT&=~BIT3; P1OUT|=BIT6; P1OUT&=~BIT0; __bis_SR_register(LPM0_bits + GIE); }
Az include a kontrollerspecifikus makrók, függvények, konstansok használatát teszi lehetővé. A CSL_init() a hardvert inicializáló függvény, erről később lesz még szó. A main függvény elindítja az inicializációt, majd a motorvezérlésre használt kimenetek közül mindent lekapcsol. Az utolsó, két különálló bit-állítás a piros led lekapcsolása, és a zöld led felkapcsolása. Ezzel jelzi az üzemkész állapotot. Ezután a kontrollert alvó állapotba küldjük, onnan interrupttal lehet kihozni. void USCI0RX_ISR(void) { unsigned char ch=UCA0RXBUF; // // // //
ch0 ch1 ch2 ch3
-
p1.4 p2.0 p2.1 p2.2
// // // //
ch4 ch5 ch6 ch7
-
p1.7 p2.5 p2.4 p2.3
unsigned char p1=0; unsigned char p2=0; if if if if
(ch&BIT0) (ch&BIT1) (ch&BIT2) (ch&BIT3)
p1|=BIT4; p2|=BIT0; p2|=BIT1; p2|=BIT2;
if if if if
(ch&BIT4) (ch&BIT5) (ch&BIT6) (ch&BIT7)
p1|=BIT7; p2|=BIT5; p2|=BIT4; p2|=BIT3;
// 10010000 P1OUT=(P1OUT&(~0x90))|(p1&0x90); // 00111111 P2OUT=(P2OUT&(~0x3f))|(p2&0x3f); if (ch){ P1OUT|=BIT0; P1OUT&=~BIT6; } else { P1OUT|=BIT6; P1OUT&=~BIT0; }
while (!(IFG2&UCA0TXIFG)); UCA0TXBUF = UCA0RXBUF;
// USCI_A0 TX buffer ready? // TX -> RXed character
}
Ez az UART interruptot kezelő függvény. A beérkező bájt bitjeit átrendezi, és a kimenet megfelelő lábaira kiteszi. Ha van a kimeneten aktív jel, akkor a piros led világít, ha nincs, akkor a zöld. Így a kártyára pillantva egyből látni lehet, hogy áram alatt van-e valamelyik motortekercs. Ez akkor hasznos, amikor valamilyen kommunikációs vagy szoftveres gond miatt a kommunikáció megszűnik, és feszültség alatt marad valamelyik motor. Ez nagyon ritkán fordult elő; ettől függetlenül egy fontos fejlesztési feladat az automata lekapcsolás megoldása. Ehhez egy időzítőt kell felprogramozni, ami a számítógép felől érkező utasítás megérkezésekor nullázza magát, és egy adott érték elérésekor lekapcsolja a kimenetet. Ezzel a szoftveres hiba esetén el lehet kerülni a motorok felesleges melegedését. Az utolsó két sor a beérkezett bájtot visszaküldi a számítógépnek. Ez egyszerű hibaellenőrzésre alkalmas. Ha a program visszakapja azt a bájtot, amit kiküldött, akkor a kártya megkapta, és feldolgozta azt. Ennek a szoftveres implementálása még nem történt meg. A motorok meghajtása, tápegység A mikrokontroller kimenetei nyilvánvalóan nem elég erősek a motorok tekercseinek meghajtásához. Valamilyen módon erősíteni kell a kimenetüket. A két motor, amit a projekthez használtam, 24 voltos feszültségről működnek az adatlapjuk szerint. Ezt nyilvánvalóan valamilyen külső tápegységnek kell szolgáltatnia, az USB-ről ekkora feszültséget (és a hozzá tartozó teljesítményt) levenni nagyon körülményes, ha nem lehetetlen. Feszültségsokszorozóval, töltéspumpával lehetne próbálkozni, de a maximális áramerősségből adódó teljesítmény, amit a számítógép a fejlesztőkártyának kioszt, valószínűleg kisebb, mint a motor teljesítményszükséglete. Ez nem biztos, hogy így van; a motor névleges feszültsége 24 V, áramfelvétele 216 mA. Ez körülbelül 5 Watt teljesítmény. Az USB 2.0 szabvány szerint az egységnyi terhelés 100 mA, a maximális (5 egységnyi) 500 mA. Az 5 V-os buszon ez 2,5 Watt leadott teljesítmény lenne, ami a motor kisebb feszültségen és sebességen való forgatásához valószínűleg elég. A maximális teljesítményt az USB buszon azonban szoftveresen kell kérni; ez esetünkben a kártya USB vezérlőjéhez való hozzáférés hiányában esélytelen. Lehetne még egyszerre több portról áramot venni; ez azonban már feleslegesnek tűnő bonyolultságot hoz a rendszerbe. Sokkal egyszerűbb a külső tápegység használata. (Attól a kivételtől eltekintve, ha a berendezést
konnektortól távol akarják használni, a laptop energiáját használva. Erre a jelen konfiguráció nem alkalmas.) Az első kísérleteknél egy régi számítógép-tápegység 12 voltos kimenetét használtam. A motorokat elvileg 24 voltról kéne táplálni, de ennek a feléről is használhatóan működtek. A kisebb feszültség hátránya a kisebb nyomaték, és az alacsonyabb elérhető maximális fordulatszám. Szerencsére egyiket sem kellett maximálisan kihasználni. A számítógép-tápegység használatának egy komoly hátránya van. Kimenete nem földfüggetlen, így a 0 kimenet potenciálja eltérhet a fejlesztőkártya (azaz az USB port) nulla szintjétől. Ez valószínűleg nem okoz komoly gondot, de extrém esetekben előfordulhat a berendezések károsodása. A nulla vezetékek ellenállása a táp felé ugyanis alacsony, hogy a rajta átfolyó áram ne emelje meg a potenciált. Így minimális feszültségeltérésnél is komoly áramok folyhatnak. Eltérő konnektorokba vagy elosztókba dugott nyomtató és számítógép között láttam már szikrázást az USB csatlakozón minden egyes ki- és bedugásnál. Hasonló jelenség lépett fel akkor is, amikor egy terminált akartam soros porton keresztül csatlakoztatni a számítógépemhez. A különböző elosztók miatt akkora volt a feszültség a két csatlakozó között, hogy bedugáskor szintén szikrázott. Komoly csípéseket okozott, ha az ujjam egyszerre ért hozzá a csatlakozó és a kábel köpenyéhez. A megoldás a közös elosztó használata volt. Az általam használt tápegység földje azonban azonos elosztóba dugva is eltérő potenciálon volt a fejlesztőkártyához képest. A multiméter egy pár voltos eltérést jelzett; hogy emögött mekkora elérhető áramerősség volt, azt nem volt kedvem kipróbálni; valamilyen más megoldást kellett keresni. Optikai leválasztásokat kezdtem keresni az alkatrészboltok honlapjain. A fejlesztőkártya-USB leválasztásnak sok értelme nem lett volna, ugyanis a kommunikációhoz hozzátartozik az egyenfeszültségek, ellenállások által jelentett információ is. Ezt a leválasztás két oldalán rekonstruálni bonyolult lett volna. Járhatóbb út a mikrokontroller és a jelerősítő közötti leválasztás. Azonban ez sem egyszerű; az optikai csatolók jellemzően csak pár csatornásak, nekünk pedig nyolcat kell átvinni. Nyolccsatornásat nem találtam, a kétszer négyes is már komoly költségekkel járt volna. Arról nem beszélve, hogy a mikrokontroller kimenete és a csatolóledek közé valamilyen korlátozó ellenállást kellett volna beépíteni; így plusz két IC-vel és nyolc ellenállással már jelentősen növelte volna a megoldás a hardver bonyolultságát. Végül a hardver bonyolítása helyett a probléma megkerülését választottam. Azok a fali transzformátorok, amiken nem látunk érintkezőket a védőföldelésnek, földfüggetlenek. Ugyanis a berendezés a két bemenő érintkező közötti feszültséget látja csak; hogy ezek a földhöz képest hogyan alakulnak, azt nem tudja. Következésképpen nem tudhatja, hogy melyik a fázis, így nem rögzítheti egyik érintkezőhöz sem a földet. Ha véletlenül a fázishoz rögzítené, az a kimeneten életveszélyes feszültséget jelentene. A választásom tehát egy régi szkenner fali transzformátorára esett. Kimenete 12 voltos, 1 A terhelhetőségű. Ez a két 5 W maximális teljesítményű motort bőven kiszolgálja, ráadásul azok csak a névleges feszültség felén üzemelnek, így a felvett teljesítményük is leesik. A mikrokontroller jeleinek erősítése, fejlesztőpanel A tápegység tehát megvolt; az erősítés módját kellett kitalálnom. Megoldhattam volna diszkrét alkatrészekkel, de az optikai leválasztáshoz hasonlóan jelentősen bonyolította volna az áramkört. Ugyanis legegyszerűbb esetben is nyolc darab tranzisztorról vagy FET-ről beszélünk. A motorok tekercsének induktív visszalökését is érdemes elfojtani. Egészen magas feszültségeket is elérhet a lökés csúcsa, a digitális áramkörök pedig érzékenyek ezekre. A megoldást az ULN2803-as IC jelentette. Ez egy tokban pont nyolc csatornát erősít Darlingtonkapcsolásban. A kimeneteket az induktív lökéseket elnyelő diódák védik; tehát erre a problémára tökéletes megoldás.
Kép forrása: Toshiba [4] Egy csatorna kapcsolási rajza a fenti ábrán látható. A szaggatott vonalas diódák nem diszkrét elemek, azok a félvezetők parazita-diódái. Az induktív lökéseket a common pinre kötött dióda nyeli el. A bemeneten lévő 2,7 kOhmos ellenállás helyén a 2804-es változatben 10,5 kOhmos ellenállás található. Az a magasabb feszültségű logikák kimenetét tudja fogadni, 6-15 V között. Az általam használt 2803-ast 5 voltos bemeneti feszültségre tervezték. Az MSP430G2553 kimenetei 3,3 voltosak, az erősítő már 3 voltnál teljesen kinyit. Így a névlegesnél alacsonyabb feszültség nem jelent problémát. Tokozásban választhattam még az APG és AFWG változatok között. Az AFWG felületszerelt, és terhelhetősége is kisebb. Így egyértelmű volt a választás, az ULN2803APG-t vettem meg. A DIP tokozás azért is volt kényelmes, mert így breadboardon tudtam kialakítani a kapcsolást.
A végleges implementáció blokkvázlata A fejlesztőkártya és a breadboard közötti összeköttetést számítógépből kibontott vezetékekkel oldottam meg. Ezeknek a vége eredetileg az alaplap tüskéire csatlakozott; a fejlesztőkártyának ugyanilyen kivezetései vannak. A drótok belseje azonban vékony, sokszálas alumínium. Ez a breadboardba dugásnál könnyen elhajlik. Forrasztóónnal befuttatva már nem, de úgy meg tud törni. Így az ónozott drótokat sorkapocsba kötöttem, ahonnan tömör rézvezetékek mentek a breadboardba. Azok jobban bírják a ki-be dugdosást, oldalirányú erőket.
A mechanika első megvalósítása
A képen az első változat látható. A léptetőmotorok át vannak fúrva a farostlemezen, és csavarokkal vannak rögzítve arra. A felső sarkokba két szöget ütöttem be, ezeken fordul a cérna a kocsi felé. A tábla mellett baloldalt a breadboardot láthatjuk, benne az erősítő IC-vel, és mellette fejlesztőkártyát. Meglepő módon a kocsi megfelelő kialakítása volt a legnagyobb kihívás. Két, egymásnak ellentétes követelmény van a tábla dőlésszögével, és a tollra nehezedő súllyal kapcsolatban. A tollat viszonylag erősen rá kell nyomni a papírra, hogy megfelelően írjon. Ezzel azonban megnöveljük a súrlódási erőt a papír és a toll között, illetve a toll hajlamosabb lesz az akadozásra, ugrálásra. Ha a tábla nagyon közel van a vízszinteshez, a súrlódási erő már olyan nagy, hogy a gravitáció nem húzza ki feszesre a felfüggesztő cérnákat, a rajzolás nem működik jól. Ha a tábla közelebb van a függőlegeshez, a toll súrlódása kisebb, a mozgatás működik, a rajz viszont halvány lesz. További problémát jelent, hogy a tollat nem tudjuk pontosan a hegyénél mozgatni, így minden irányba mozgatásnál egy kis erőkar jön létre, ami a tollat igyekszik felborítani. Ezért megfelelő kitámasztásra van szükség. Ezt az első változatnál a tollhoz gumival rögzített drótkeret jelentette. Így három ponton érintkezett a kocsi a papírral, ezek közül a legfelső a toll hegye volt. A kocsi súlyát meg kell annyira növelni, hogy megfelelő nyomóerőt adjon a tollnak, és elősegítse a cérna lefelé húzását. A toll felfogatási pontja a cérnán a papírhoz a lehető legközelebb van. Ha ennél a magasságnál nagyobb pontban van a szerkezet súlypontja, akkor a meredekhez közeli helyzetekben a kialakuló forgatónyomaték miatt akár el is emelheti a tollat a papírról. Jó lett volna tehát a papírhoz minél közelebb elhelyezni a súlypontot, azonban ez a vas anyacsavarok relatíve kicsi sűrűsége miatt nem lehetséges; ennél tömörebb anyag pedig nem nagyon található háztartásban. A képen látható elrendezésben a két alsó, kitámasztó lábra is tekintélyes súly jut. Igazából az előbb tárgyalt forgatónyomaték miatt a súly nagy része ezekre jut, a tollra jóval kevesebb. Ezért az oldalirányú mozgásnál a tollat a cérna kényszerűen a helyes pályán mozgatta, de a súrlódás miatt a két alsó kitámasztó láb próbált ellenállni a mozgásnak. Ennek hatására a kocsi megdőlt, majd amikor a dőlés nem volt tovább tartható, hirtelen ugrással esett az alja a toll után. A papír széle felé az egyik cérna mindenképpen lelazul. Ha a cérnában ható kötélerő a tapadó súrlódás által kifejtett erő alá csökken, akkor az adott cérnát hiába engedjük tovább, a kocsi nem mozdul, csak a felfüggesztés lazul be egyre jobban. A motorok által keltett vibráció miatt azonban még hirtelen mindig megindulhat, de ilyenkor nem a szoftver által kiszámolt pályán jut a kívánt pontba, hanem ahogy sikerül. Ez a többi vonaltól elütő, átlós hibákat visz a rajzba. Ezeknek a hibáknak a kiküszöbölésével próbálkoztam a második próbálkozásnál.
Második változat
Az előző változat problémáinak kiküszöbölése egyszerűen a rajztábla méretének megnövelésével történt. A képen az eredeti táblát látjuk a nagyobb mögé rögzítve. A két cérnát a falemez szélére csiptetett iratkapcsok vezetik a megfelelő irányba. Ez a cérnák szögét jóval kisebb tartományban használja; a függőlegeshez soha nem kerülnek olyan közel, mint az előző esetben. Így nem állhat elő az az eset, mint az előző megvalósításnál, hogy az egyik cérnában ébredő erő jelentősen lecsökken, majd beesik a kocsi súrlódási ereje alá. A felfüggesztés tehát folyamatosan feszes marad, így az ugrálás megszűnt. A kocsi is eltért az előzőtől. A Merkúr nevű építőkészletből raktam össze, így maga a kitámasztás adta a súly nagy részét, nem kellett magas súlypontot eredményező plusz nehezékeket rögzítenem rá. Ennek, és a nagyobb kötélterhelés miatt lecsökkentett tábla-dőlésszögnek köszönhetően a tollat elemelő forgatónyomaték is megszűnt. Azonban ez sem tökéletes; a cérnák nem pontosan a toll hegyénél fogják a szerkezetet, hanem valamivel kijjebb lévő pontokon. Így a jobbra, és balra történő mozgatásoknál a toll hossztengelye körül elforgatják a kocsit. A másik fellépő hatás, hogy a kitámasztás három pontos, és a toll a két felső között van félúton. Ahhoz azonban, hogy hozzáérjen a papírhoz, a hegynek kell a papírhoz legközelebb lévő pontnak lenni, tehát a négy pont egyszerre nem tud leérni a papírra. Ez főleg vízszintes irányváltásoknál egy átbillenést eredményez az egyik három pontból a másik hárommal történő érintkezésbe. E két utóbbi hatás minimálisan, de látszik a rajzon. Azonban az így kialakított plotter már egészen használható rajzokat volt képes létrehozni.
Eredmények
A két kép a plotter által rajzolt minták beszkennelésével készült. A toll a jobb alsó sarokból indul, és ingázva ér fel a bal felső sarokba. Az ingázás közben négyszögjeleket rajzol, amelyek nagysága arányos a headset által vett agyi aktivitással. A headset szoftverének görbéi közül a short term excitement adta az értékeket. A legkisebb és legnagyobb jel a headset által szolgáltatott tartománynak csak egy részét fogja át, így a minimumszint alatt lévő értékeknél 0-t ír a plotter, illetve a legnagyobb érték felett is különböző értékeket vesz még fel a jel, ami a papíron mind maximumként jelentkezik. Enélkül a négyszögjelek nem tértek volna el látványosan egymástól. Látszik, hogy ahol elindul a felvétel, még közepesen erős agyi aktivitást mért a headset. Ez a felvétel indítása utáni gyors ellenőrzés következménye, majd utána megpróbáltam elcsendesíteni az agyamat. Ez mindkét esetben elég jól sikerült. Ezután felváltva próbáltam lazítani, illetve magas agyi aktivitást mutatni. Ezt gyors, izgalmas élmények fejben átpörgetésével, fejben számolással, erős koncentrációval és hasonlók gyors váltogatásával tudtam elérni. Az amplitúdó váltakozását jól lehet követni az ábrákon. Fejlesztési lehetőségek A mikrokontroller programjának tárgyalásakor megemlítettük a biztonsági időzítőt, ami egy idő után lekapcsolja a motorra adott feszültséget, ha nem érkezik eltérő utasítás a számítógéptől. Ennek implementálása egy fontos biztonsági funkció. A vezérlőszoftver kódja meglehetősen átláthatatlan, nagy része jól újragondolt újraírást igényel. A soros kapcsolat megszakadását okozó - valószínűleg portkonfigurációs - hibát meg kell szüntetni. Új funkcióként be lehetne vinni a koordináták megfelelő transzformációját; azaz a rajzfelületen képes legyen egyenes vonalakat húzni. Ehhez az is szükséges, hogy a két motor eltérő sebességgel is képes legyen forogni. A jelenlegi változat csak ugyanolyan ütemezéssel tudja váltani a két motor elfordulását. A rajzolt minta lehetne egy kicsit fantáziadúsabb, a négyszögjeles EEG elég triviális megoldás. Valami bonyolultabb, de könnyen értelmezhető mintákat előállító algoritmus nagy előrelépés lenne.
Kép forrása: jovoplaza.hu [8] Meg lehetne valósítani a képen látható gyerekjátékot, ami közelebb lenne az eredeti feladathoz. A probléma, ami miatt a plotteres irányba indultam, az volt, hogy nem tudtam négy, megbízhatóan elkülönülő parancsot betanítani a headsettel. Ezt hosszas gyakorlás után valószínűlet meg lehet valósítani, de egy teljesen új felhasználónak valószínűleg sok frusztrációt okoznánk vele. Ehelyett a vezérlési séma lehetne az, hogy a headset giroszkópjainak jelét kiolvasva érzékeljük a felhasználó fejmozgásainak irányát. Egy kis fejrántás balra azt jelenti, hogy a golyót a bal irányba akarja mozgatni. Ezután egy jól betanított parancs aktiválásával (vagy az agyi aktivitás, így az erős koncentráció figyelésével) engedélyezzük az adott irányú mozgást. Ha ennek megvalósítása megoldható, akkor a mechanika gondos megtervezésével és megfelelő alkatrészellátással innen már csak egy lépés az eredeti feladatkiírás megoldása. Annak az az előnye, hogy a játéktér vízszintes, így tetszőleges akadályokat fel lehet pakolni a pályára, esetleg azokkal kölcsönhatásba is léphet a golyó. (Fémcsíkokon áthaladva fények gyulladnak ki, megfelelően kialakított akadályokat adott helyekre tologatni, stb.) Irodalomjegyzék [1] Logsys FPGA kártya dokumentáció, kép http://logsys.mit.bme.hu/sites/default/files/page/2009/09/LOGSYS_SP3E_FPGA_Board.pdf [2] Texas Instruments MSP-EXP430G2 Launchpad dokumentáció, szoftverek http://www.ti.com/ww/en/launchpad/msp430_head.html [3] Mitsumi M43SP-5 léptetőmotor adatlap
http://www.mitsumi.co.jp/latest/Catalog/pdf/motor_m42sp_5_e.pdf [4] Toshiba ULN2803APG adatlap http://www.semicon.toshiba.co.jp/info/docget.jsp?type=datasheet&lang=en&pid=ULN2803APG [5] Emotiv API dokumentációja http://emotiv.com/developer/SDK/UserManual.pdf [6] Windows-függvények dokumentációja http://msdn.microsoft.com [7] Az xy-plotter képe (Forgalmazó: 8linx.com, a foamlinx.com LLC leányvállalata; ismeretlen tervező) http://www.8linx.com/cnc/day6.htm [8] A fagolyós gyerekjáték képe (Forgalmazó: Magyar Shop, Jövő pláza) http://jovoplaza.hu/magyarshop/Asztali_labirintus_WOODY_90668-termekID-35414 (A linkek 2013. májusi állapotot tükröznek.)
