A mechanikája elég egyszerű, csupán a mikrokapcsolók és a szervó motorok összehangolása igényelt sziszfuszi munkát.

A programozásával jó néhány napot eltöltöttem.  Az Android app és a robot Bluetoothos,  vezeték nélküli kapcsolaton keresztül, két irányban kommunikál egymással. Korábban már készítettem hasonló rendszert, de a mostani annyival bonyolultabb volt, hogy az Arduino  program állandóan futó részét (ez az ún. loop, azaz hurok) és a  kétirányú kommunikációt biztosító ciklusokat kellett összehangolni. Már-már majdnem feladtam, de aztán végül támadt egy ötletem, így sikerült a problémás programrészeken urrá lenni. 

A videó narrációjához néhány kiegészítés:

• Ha valaki nagyon figyel, az tapasztalhatja, hogy minden tornagyakorlat 5-ször ismétlődő mozgásból áll, a ventilátor pedig 5 másodpercig  forog. 

• A felállástól a leülésig a közbenső gyakorlatok sorrendje tetszőleges.

• Hogy a tornász mikor izzad meg, az véletlenszerűen következik be a harmadik és a nyolcadik gyakorlat között. 

A program által random módon generált nyitókódot kell kitaláln, és az ennek hatására kinyíló ajtó mögött véletlen elhelyezkedésű szenzort megérintve visszacsukni.

Vagyis ők csak a szövegfelolvasó és hangfájl rögzítő alkalmazás szintetikus hangjai. Az audio player révén szólalnak meg , és egymást felváltva mondják el a videóban, hogy hogy is működnek.

Így ez a készülék kicsit hajaz az ismert adomára, mely szerint építettek egy oszlopot, hogy rátegyenek egy lámpát, nehogy valaki nekimenjen az oszlopnak...

A videóban megadtam a működés megértéséhez szükséges alapvető információkat. 

Kiegészítés képpen azoknak a Kedves Olvasóimnak, akiket érdekel a  robot és a vezérlő applikáció közötti kommunikácó, néhány szóban összefoglalom ennek lényegét. 

Ahogy a videóból is kiderül, a mért adatok a ciklus végén egyszerre jelennek meg az Androidos telefon kijelzőjén. Ez azt jelenti, hogy a robot (illetve annak programja) menet közben tárolja az adatokat, és amikor már mindegyik megvan, azokból egy stringet, vagyis karakterláncot képez. Jelen esetben 8 féle adat van, melyek közé szeparátorként egy-egy "|" karaktert tesz, majd ezt a karakterláncot elküldi a bluetooth portra.

Az Android applikáció 0,1 másodpercenként  figyeli, érkezett-e a bluetooth kapcsolaton keresztül adat. Ha igen, akkor "dekódolja" a beérkező stringet, vagyis a szeparátorokkal elválasztott karaktereket a layout megfelelő rubrikáiban jeleníti meg. Például: a hőmérséklet értéke a 2. számmezőbe íródik, ami azt jelenti, hogy ezt a mezőt a string 2 sz. indexéhez kellett hozzárendelni az applikáció programozásakor, mivel a robot ezt méri másodikként.

Ennél a verziónál sem lefelé fordított memóriakártyák helyzetét és az azokon lévő ábrákat lehet memorizálni, hanem a 10 db, LED mátrixon megjelenített grafikai alakzatot és azok egyedi azonosítóit. Az ábrákat ezek révén lehet összepárosítani. A nagyobb hűség kedvéért viszont a LED mátrixok  előre és hátra billennek, így szimulálva a memóriakártyák fel-, vagy lefordítását. Ezt a mozgatást szervómotorok végzik.

A játékhoz készítettem egy Android app-ot, mellyel bizonyos folyamatokat lehet elindítani és nagy szerepe van az egyedi azonosítók bevitelében is. 

A többi kiderül a videóból.

Így született meg ez a robot, amely- ahogy az a videóban is látható - bizonyítja a feltett kérdésre adott választ, azaz, hogy mindig érdemes az első tippet megváltoztatni, 

Az állítás igazát egyébként egy egyszerű táblázattal is alátámaszthatjuk. Ez- és a többi elméleti fejtegetés - megtalálható a https://hu.wikipedia.org/wiki/Monty_Hall-paradoxon weboldalon.

A  videóban látható és olvasható információkat kiegészítendő, itt egy kicsit részletesebben taglalom az ún. Compass modult, ami lényegében egy elektronikus iránytű. Nem tévesztendő össze a Gyroval, az elektronikus pörgettyűvel. 

Ez az eszköz 3 tengely mentén méri a mágneses térerőt és a térbeli szöghelyzetét. Ebben a robotban a daru "középhelyzetének" meghatározása és az elfordulásának limitálása céljából építettem be, mivel ezt a mozgatást egy egyszerű DC motor végzi, melynek nincs visszacsatolt szöghelyzete, így a program nem tudja nyomon követni a pillanatnyi elfordulásának a mértékét.  Viszont a Compass modulét igen, de csak akkor képes a középhelyzethez és a elfordulásokhoz tartozó szöget megállapítani, ha azokat a szerkezet tájolásához viszonyítjuk. Ezért kell az eszközt indításkor kalibrálni. Magyarul: ha az egész robotot elfordítanánk, akkor ahhoz más szögértékek tartoznának. 

A futómacskát (görgős szán) és az  emelő "csigát" egy-egy encoder motor hajtja, melyek szögelfordulásának mértékét (és sebességét) a program közvetlenül vezérelni tudja. 

Hogy mi az alapelv és hogy az hogyan valósul meg, az a videóban olvasható magyarázó szövegből illetve a példákból kiderül.

Itt csak néhány szó az Arduino programról. A 4 x 2 beszkennelt színt, pontosabban azok kódját a beolvasás sorrendjében tárolja a program, miközben számolja az azonos színűeket. Ezt követően a kódok átíródnak egy olyan 3 x 3-as mátrixba, amely a forgóasztal alaphelyzetéhez igazodik. A középső helyre az a színkód kerül, amelyből a széleken összesen csak 2 db van.

A vezérlésre és az eredmény kijelzésére szolgáló Android alkalmazás a Bluetooth kapcsolat felépítése után a Start gomb megnyomására egyrészt narancssárga alapszínre váltja a kijelző mátrixot, fehér sorszámokkal látva el a négyzeteket, kivéve a középsőt, mely vörös színű, másrászt elindítja a szkennelést.

Amikor egy ciklus lefutott, a robot átküldi az alkalmazásnak Bluetooth kapcsolaton keresztül a mátrixban tárolt kódokat, mire a kis négyzetek színei a hasábokkal megegyezőek lesznek az alaphelyzetnek megfelelően. (A sárga négyzetek sorszámai a jobb olvashatóság érdekében feketére váltanak.) A végeredményül kapott, kiszínezett mátrix  egészen a következő, értelem szerűen már egy másik hasáb elrendezéshez kötődő ciklus indításáig látható. 

Felfedeztem ugyanis, hogy az MIT App Inventorban találhatók olyan vezérlő blokkok, amelyeket ha egy "nyomógombhoz "rendelünk, akkor azok csak addig működtetnek egy folyamatot, amíg a gombot "lenyomva" tartjuk. Természetesen ez megköveteli az Android App és a robot működtető programjának összhangját.

A nagy felfedezésen  felbuzdulva építettem meg ezt a robotkart. A három működtető motorja tehát csak addig forog, illetve mozgatja a kart a megfelelő irányba, amíg a megfelelő gomb lenyomott (touch down) állapotban van. Természetesen a motorok sebességét az Arduino programban kell beállítani, de nincs szükség járulékos paraméterek megadására, mint pl. szögelfordulás vagy időtartam (késleltetés), melyek egy "normál klikkelős" nyomógomb esetén elengedhetetlenek.

Itt jegyzem meg, hogy van még szabad motorom és a meghajtó áramkörökön szabad csatlakozó port is, úgyhogy nem kizárt, hogy a szerkezetet (illetve a szabadsági fokok számát) még bővíteni fogom...

Egy menet során a Játékos az Androidos telefonon választja ki a saját alakzatát, az Auriga pedig véletlenszerűen. A két. egymás mellett megálló alakzat dönti el, hogy ki kapja az 1 pontot. (Döntetlen nem kizárt.)

A játék addíg folytatódik, amíg valamelyik résztvevő el nem éri a 10 pontot. A végeredménynél sem kizárt a döntetlen. 

A többit lásd a videóban!

Itt még csak annyit, hogy az Android applikáció programozásánál számomra az jelentette az újdonságot, hogy a robot által Bluetooth kapcsolaton keresztül átküldött pontszámokat elkülönítsem egymástól úgy, hogy a telefon megfelelő mezőjében kerüljenek kiíratásra. Hiába, a jó pap holtáig tanul...