Robotexi sait: http://www.robotex.ee Aeg: 24 Nov. 2006 Pildid ehitamisest ja võistluselt

Meeskonna nimeks oli Heavy Metal, mis pidi iseloomustama tõsiasja, et tegu oli tõepoolest võistluse kaugelt kõige raskema robotiga, mis koosnes tänu pneumaatikale ja raudalusele suures osas metallist.

Meeskonna koosseisuks oli:

• Sven Petai - soft, veidi ka elektroonika
• Rene Bernard - mehhaanika, veidi ka soft.
• Kalle Kebbinau - elektroonika disain.
• Tõnu Jaansoo - pildituvastuse komponendi softi parandused, elektroonika debug.

Ülesaneks on siis sisuliselt robotite vahel võrkpalli mängimine. Väljak on piiratud 20cm kõrge aiaga, “võrk” poolte vahel on 10 cm kõrge. Põhimõtteliselt kaotab siis see kelle poolel on mängu lõppedes rohkem palle, üle väljaku piirde visates saad miinuspunkti. Palliks on squashi pall, diameeter 39,5-40,5mm kaal: 23-25g. eripäraks on kehvad põrkeomadused.

Põhimõtteliselt kehvasti, ühtki palli me tulistatud ei saanud, kuid palju targemaks saime kõik küll, nii et osavõttu kindlasti ei kahetse. Nagu enamasti roboti ehitajatel ikka, sai meile saatuslikuks ajapuudus. Kui üldiselt soovitatakse alustada ehitamisega kuskil kevadel, siis meie hakkasime osavõttu arutama Septembri alguses ja reaalset ehitamist kuskil Oktoobris, kusjuures rõhuv enamus mehhaanika ja progemise tööd toimus 2 ööpäeva enne võistlust (olime ilmselt ka ainus team kes veel proges siis, kui esimesed robotid juba võistlesid !) Lisaks oli meie roboti disain ka kaugelt võistluse keerukaim, alates sellest, et olime ainsad kes kasutas pneumaatikat kuni selleni, et meie robotil oli kokku 3 protsessorit ja kogu arvutusvõimsus ületas ilmselt konkurentide oma mitmekordselt. Võitis muidugi üks lihtsamaid roboteid, mis töötas peaaegu, et puhtalt mehhaanika ja brute force põhimõtetel - ehk siis KISS põhimõtte headus leidis taaskord kinnitust.

Meie läbipõlenud põhiemaplaadi asendusplaat saabus päev enne võistlust ja sai roboti peale umbes tund enne võistluse algust ja nii ei olnud me reaalse raua peal võistluse hetkeks teinud ainsatki proovisõitu. See meile peamiselt saatuslikuks saigi, kuna eelpoolmainitud plaadil jooksev OS lihtsalt hangus juba võistlusplatsile asetamise hetkel ja seega piirdus meie robot muljetavaldav väljanägemisega. Arvestades, et enamus hilisemat võistluse kajastust meedias kasutas justnimelt meie roboti pilte, mitte võitja oma, võib ka seda heaks tulemuseks lugeda

Teises roundis suutis robot enne hangumist ka mõned cm liikuda ja ühe palli sisse tõmmata, kuid alt vedas mehhanism mis pidi palli kahurisse tõstma, pall kukkus poolel teel alla ja blokeeris sellega allatuleva lifti. Kuna kahuris enam ekstra kontrolli palli torus oleku osas ei olnud, sai siiski tehtud ka võistluse ainus lask. Ilmselt oli omamoodi ka hea et pall torusse ei jõudnud, kuna kompassi häirete tõttu oli lasu hetkel sihikul kohtunik Lasu tagasilöögi peale hangus taaskord ka põhiemaplaat ja edasi seisis robot taaskord paigal ja nägi ilus välja.

Etteruttavalt olgu öeldud ka, et pärast võistlust debugides selgus, et põhiemaplaadi hangumise põhjustas ilmselt kaamera EM väli. Niipea kui kaamera tagaosale, mis oli emaplaadi poole, alumiinium teibi tõmbasime lakkasid ka hangumised.

Kasutasime ära tõsiasja, et vahesein on 10cm madalam väljaku piirdest. Seega on kasulik konstrueerida laskemehhanism nii, et tulistataks suure jõuga maaga horisontaalselt. Sellisel juhul pole vaja eriti vaeva näha nurkade arvutamise ja hea positsioneerimisega, sest kuni suund on enamvähem õige, maandub pall vastase seljataguse seina põrkest tema poolele.

Kuna parajasti oli haripunktis mu neurobioloogia huvi sai nii riistvara, kui tarkvara disainis kasutatud sellest vallast pärit põhimõtteid ja terminoloogiat. Peamiselt väljendub see nii riist- kui ka tarkvara jagamises piirde- (sensoorsed mehhanismid, refleksid) ja kesknärvisüsteemiks (loogika ja otsused).

Loogiline vaade

Kasutada paintballi vms. balloone, keerukas koht on põhimõtteliselt gaasi doseerimine üheks lasuks, nii, et korraga tervet ballooni ära ei kütaks ja samas iga lask saaks enamvähem ühtlase tugevusega. Samas on meil oluline, et balloon oleks võimalikult pisike ja sellest saaks vähemalt ~20 lasku.

Väidetavalt sobivad selleks sprinklerite solenoidventiilid ja sellel põhimõttel tehakse maailmas palju nn. pneumaatilisi kartulipüsse.

Algselt proovisime kasutada silindreid, mis oleks siis vardaga lihtsalt palli löönud. Paraku selgus et kõik saadaolevad liikusid liialt aeglaselt ja ei suutnud seetõttu palli piisavalt kaugele visata.

Ebaõnnestusid ka esimesed katsed otse gaasi läbi solenoidventiili lastes, hiljem saime katse-eksituse meetodil aru, et probleem oli portide suuruses ehk selles, kui suure koguse gaasi klapp suutis korraga peale anda. Meie oma oli 1/8” pordiga, puht praktilised katsed näitasid et oleks vaja olnud vähemalt 1/2”.

Nii solenoidklappide, kui ka silindrite puhul oli probleemiks ka, et nad talusid ainult ~10 atm rõhku, kuid balloonist tuli välja ~150 atm. Seetõttu pidime kasutama suhteliselt kallist reduktorit ja vahepaaki. Põhimõtteliselt kulus meil pneumaatika testimiseks ja juppide üle maailma kokkuotsimiseks üle kuu ja päris suur hunnik raha. Lõpptulemusena aga avastasime oluliselt lihtsama laskmismeetodi elektroonilise paintballi püssi süsteemi näol, langes ära vajadus nii vahepaagi, solenoidklapi kui ka reduktori järele.

Mõned asjassepuutuvad lingid, mis eksirännakutel ette jäid:

HOWTO kuidas ehitada ise paintball püssi: http://www.gizmology.net/pbm.htm ja http://members.aol.com/sph911/spud/pneumatic.html

Natuke pneumaatikast:

• http://dc.ec.uiuc.edu/guide/guide4.htm
• http://www.teamdavinci.com/understanding_pneumatics.htm
• http://howto.killerhurtz.co.uk/pneumatics.htm

valmis roboti pneumaatika kit (200$): http://www.vexlabs.com/vex-robotics-pneumatic-parts.shtml

Mõned poed kust juppe saab:

• http://www.maxs-sport.com/paintball-shop/ sakslaste veebipood
• http://www.europb.com miski rootslaste pood
• http://www.fatbobspaintball.co.uk/acatalog/shop.html inglaste oma
• https://palmer-pursuit.com/ USA pood mis igasugu väga spetsiifilisi vidinaid müüb
• http://www.888paintball.com/ USA pood, ilmselt suurima valikuga
• yks eesti IRL pneumaatika pood: http://www.hydroscand.com/

Pea kõikide kaalumisel olnud laskemehhanismide puhul on vajalik pall enne laskmist maapinnalt kõrgemale tõsta. Selleks kasutame me CD-ROMi ukseavamise systeemist aretatud mehhanismi kus mootoriga osa mille kyljes on forklift moodi kahvel liigub müüda hammastega pulka yles-alla.

Kuna mingil moel on vaja pallid saada kätte ja toimetada roboti keskosas olevale tõstukile siis kasutame selleks konveierlinti. Tänu roboti teravale nina disainile peaks ta konveieri vahele suutma tõmmata palle ka nurkadest ainsaks puuduseks on, et sõita tuleb nii et pall jääks üsna täpselt kitsukese konveieri ava vahele.

Ehk siis sisuliselt kuidas teada kus oled ise, kus on vastane ja kus on pallid. Hetke plaan on kasutada pallide leidmiseks kaamerat ja vastase suuna määramiseks kompassi.

Kõige lihtsam oleks mõlemas loota pildituvastuse peale, ääreseinte ja põranda taustalt peaks olema palle hea leida kuna need on valged ja pallid mustad. Vaheseinaga on lugu keerukam kuna ka see on must, aga loota võib sellele et kui kaamera paigutada väikese nurga alt ülalt alla vaatama siis näeme me kumerusi põranda taustal, mida seina ääred ei saa põhjustada ja nii olekski pall identifitseeritud.

Enda asukoha määramiseks vastase suhtes sobib kompass, kuna me võime roboti paigutuse võistluse algul ise vabalt valida siis võime ta asetada “näoga” vastase poole. Hiljem tuleb meil laskmiseks vaid umbes algsesse suunda pöörduda - piinlik täpsus pole meie laskemehhanismi puhul kuigi oluline.

Esimene kompass millega proovi sai tehtud sulas teadmata põhjustel kokku enne, kui me ta suunanäitamisoskustest mingitki aimu saime.

Veidi paremini läks läks lugu teise kompassiga, kuid selgus et see värk on magnetväljade suhtes ülimalt tundlik ja 20cm kauguselt möödajalutav inimene kellel võtmed vms. taskus suudab näitu 10+ kraadi kallutada. Niisiis ei ole kompass just kõige töökindlam variant.

Sellest probleemist möödasaamiseks kasutavad robotite ehitajad kompasse koos güroskoopidega, kuna güroskoobi väärtused kipuvad pikema ajaperioodi vältel ujuma ja võivad mõne minutiga 10+ kraadi kaotada ei ole nad üldiselt iseseisvalt lahenduseks kuid kui kasutada kompassi pikemaajalist stabiilsust ja güroskoobi lühiajalist täpsust koos võib täitsa adekvaatse süsteemi saada.

Pood kust väikseid güroskoope saab: http://www.robotcombat.com/marketplace_rc-gyros.html

Üks võimalus on püüda asukohta määrata (meeles pidada) rattaid usaldades, kasutades siis kas steppermootoreid või peaks lisama ratastele optilised andurid ning kettad, millelt andurid samme loevad. Selle variandi nõrk külg on võimalus, et rattad libisevad.

Teiseks võiks kasutada optilisest hiirest välja kougitud süsteemi. Juhul kui optiline “silm” paigutada roboti põhja ühte nurka, peaks olema lahendatud ka pööramise mitte-tunnetamise probleem ning sellisel juhul peaks saama kaunis usaldusväärsed andmed.

Üks võimalus oleks palle otsida sonariga, see annab paraku üsna hägusa pildi ja võib tekkida probleeme kajaga nurkadest + ehk ka vastane kasutab sama sagedusega sonarit ?

Üldiselt koosneks robot VIA nano-ITX emaplaadist (Linuxiga), mille külge oleks ühendatud kaamera (USB) ja Atmeli põhisest lisaplaadist, mis on ühendatud COM porti. Atmeli plaadi ülesanne on koordineerida motoorikat ja sensoreid ja VIA plaadil tehakse pilditöötlust & võetakse vastu otsuseid kuhu minna ja mida teha.

Edaspidi nimetame VIA plaati kesknärvisüsteemiks (central nervous system) ja atmeli plaati ja kogu tema poolt kontrollitavat sensoorset/motoorset värki piirdenärvisüsteemiks (peripheral nervous system).

Peaajuks on VIA epia NL10000E mis on 1Ghz prosega. Meie poolt juurde pandud 2G CF flash ja 256M RAMi. Mõõtmed: 12x12cm

http://linitx.com/product_info.php?products_id=925

Seljaajuks on Atmeli Atmega88 ümber isedisainitud aretis, mille kontrolli all on:

• multiplexer
• h-bridge
• mootorid
• relee mille küljes on kahur
• kompass

H-bridge spec: http://www.ortodoxism.ro/datasheets/texasinstruments/l293d.pdf

Plaadi skeem:

Kommentaarid Kallelt: Nii. Seal on nüüd skeemil mõned asjad teisiti kui datasheedis oli. VCC on skeemis see mis plaadil ja kivil on märgitud VSS-ina, kuid see ei muuda asja. VDD on siis plaadil VD ehk siis see, millele annad mootorite pinge. VCC peale kivi oma.

kesk- → piirdenärvisysteem

kesk- → piirdenärvisüsteem

Kontra progemisel peab progemiskaabli kirjadega pool jääma välja.

Kogu tarkvara on bsd.ee's CVSis @ /usr/local/robobsd või siis veebiinterfacei kaudu vaadeldav @ http://bsd.ee/robobsd/cvsweb.cgi/robobsd/

Hetkel on seal järgnevad asjad:

 rmaster.py - //peaaju/kesknärvisüsteem//, mis kogu värki siduma peaks. kirjutatud Pythonis.
 vision/ - pildituvastusega seotud värk. OpenCV libra selge kirjutatud C proge.
 AVR/ - //seljaaju// peal jooksev C kood.

Pythonis kirjutatud multithreaded proge, kus iga suhtluskanali jaoks on omaette thread. Hetkel järgnevad threadid:

• vision - loeb detection protsessilt üle pipei infot lähima leitud palli / seina kohta
• peripheral - loeb seljaajult tulevat infi sensorite stateide muudatuste kohta, annab neist huvilistele teada ja tegeleb käskude kirjutamisega piirdenärvisüsteemi.
• central - põhithread, mis teeb otsuseid mida teha
• keyboard reader - thread mida kasutatakse ainult siis kui asi pole deemonina käivitatud, ehk siis testimise modeis. Võimaldab klaviatuurilt robotit juhtida.

Üks olulisemaid andmestruktuure on sensorite list, kus on kirjas iga sensori kohta tema viimane teadaolev state ja wait channel mille taha võib blokeeruda ootama antud sensori statei muutumist.

Enne wait channelil blokeerumist on mõistlik üles seada watchdog, et sensori info kadumamineku korral saaks miski aja pärast ikkagi resetida oma statei.

Puutesensorite aktiveerumise korral toimub põhimõtteliselt interrupt ja control threadi program flow kandub üle funktsiooni maneuver() mille ülesanne on robot viia taas seisu kus ükski puutesensor pole aktiivne. Sellise seisu saavutamise järel jätkub threadi töö poolelijäänud kohast.

Samalaadne interrupt toimub ka siis kui aktiveerub kas konveieri alguses või lifti peal palli olekut näitav sensor ja handleri ülesanne on sellisel juhul pall kahurisse tõsta ja välja tulistada.

OpenCV teegi ümber ehitatud pildituvastus programm, mis üritab leida palle ja vaheseina. Implemenditud on mitu tuvastusmeetodit ja ulmeline hunnik erinevaid filtreid mida saab käsurealt või graafilisest modeist klahvidega toggleda. Võistlusel kasutasime tuvastusmeetodina Hough Circles transformationit ja rakendasime pildile adaptive threshold filtrit.

• Alustada tuleb varem
• Tuleb funktsionaalsust backupida võimalikult paljudes kihtides. Näiteks VIA plaadi mittetoimimise korral (nagu meil võistlusel) oleks võinud juhtimise üle võtta atmeli plaat ja lihtsalt kas randomiga või järjest väljaku läbi sõita. Mõne palli oleks ehk ikka kätte saanud.
• Ainult kompassile navigatsioonis ei tohi loota, kuna kipub kohati aiateibaid näitama.
• Algoritme tuleks võimalikult varakult reaalse raua peal testida. Avastada et su vinge pildituvastus meetod suudab roboti plaadi peal töödelda 1 framei 5 sekundi peale pole sugugi meeldiv, eriti tund enne võistlust.

http://enos.itcollege.ee/~mernits/robot/

Meie vastuluure on leidnud järgneva konkurentide teema http://www.electro-tech-online.com/robotics-chat/23779-shooting-ball-over-wall.html

http://www.contrib.andrew.cmu.edu/~rjg/websensors/robot_sensors2.html Kõikvõimalike sensorite kirjeldused.