projects:robotex.2006 [...]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
{{http://bsd.ee/~hadara/robot/robot_final_small.jpg}}


====== Üldine ======
Robotexi sait: http://www.robotex.ee
Aeg: 24 Nov. 2006
[[http://hacks.bsd.ee/gallery2/main.php?g2_itemId=15|Pildid ehitamisest ja võistluselt]]

==== Meeskond ====
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.
  * [[http://kivimae.ee/~kalle|Kalle Kebbinau]] - elektroonika disain.
  * [[http://bsd.ee/~chain/|Tõnu Jaansoo]] - pildituvastuse komponendi softi parandused, elektroonika debug.

==== Reeglid ====
Ü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.

==== Kuidas läks ? ====
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.

==== Plaan ====

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.

===== Kontseptsioon =====
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).

{{http://bsd.ee/~hadara/robot/robot2.png}}

Loogiline vaade



====== Laskemehhanism ======

=== Suruõhukahur ===
== Plaan ==
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.

== Teostus ==
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.

== Viited ==
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/

==== Tõstukid ====
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.

====== Etteandja ======
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.

====== Navigatsioon ======
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. 

==== Kaamera ====
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.

==== Kompass ====
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.

[[http://www.sparkfun.com/commerce/product_info.php?products_id=761|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 [[http://www.active-robots.com/products/sensors/sensors-details-6.shtml|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 [[http://www.seattlerobotics.org/encoder/200311/brown/building_a_directional_gyro.html|süsteemi saada]].

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

==== Positsioneering ====
Ü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.

==== Sonar ====
Ü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 ?


====== Elektroonika ======
Ü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).

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

{{http://www2.multithread.co.uk/images/epia_nl_large.jpg}}

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

==== Piirdenärvisüsteem =====
Seljaajuks on Atmeli Atmega88 ümber isedisainitud aretis, mille kontrolli all on:
  * multiplexer
  * h-bridge
  * mootorid
  * relee mille küljes on kahur
  * kompass

{{http://bsd.ee/~hadara/robot/seljaaju.png}}

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

Plaadi skeem: 

{{http://bsd.ee/~hadara/robot/skeem.png}}

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- ja piirdenärvisüsteemi vaheline protokoll ====
kesk- -> piirdenärvisysteem

^cmd    ^args              ^meaning                                      ^
|l      |0-100 (action intensity in percentages)|turn bot left                                |
|r      |0-100 --,,--      |turn bot right                               |
|f      |0-100 --,,--      |go forward                                   |
|b      |0-100 --,,--      |go backwards                                 |
|s      |None              |stop engines                                 |
|x      |None              |stop conveyer                                |
|X      |None              |stop conveyer                                |
|c      |None              |fire the cannon                              |
|u      |None              |lift up                                      |
|d      |None              |lift down                                    |
|S      |None              |stop lift (for debug)                        |

kesk- -> piirdenärvisüsteem

^cmd     ^args            ^meaning                            ^
|POWERON |Noe             |atmeli plaat l[litati sisse        |
|SX      |val (double)    |value of sensor X changed to val   |
|<int>   |None            |degrees from compass               |

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

====== SOFT ======
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:
<code>
 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.
</code>

====== Kesknärvisüsteem ======
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.

===== Vision =====
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.

====== Rahakulu ======
^desc    ^sum    ^where    ^
|EPIA NL 10000 Nano ITX    |281 EUR  | http://www.nano-itx.de |
|pico PSU, 6-26V, 60/80W Peak, DC-DC ATX |56 EUR | http://www.nano-itx.de |
|CF adapter, 44Pin IDE |16 EUR | http://www.nano-itx.de |
|IDE adapter IDE->44 pin mini IDE |9 EUR |http://www.nano-itx.de |
|CF 2G |49 EUR | http://www.nano-itx.de |
|servod 2tk |40 EUR | Kullo mudelitehnika pood |
|rattad     |11 EUR | http://www.active-robots.com |
|patareide hoidjad |5 EUR | http://www.active-robots.com |
|kuulveermikud |11 EUR | http://www.active-robots.com |
|kompass |22 EUR |http://www.sparkfun.com |
|pneumaatika jupid |220 EUR |http://www.palmers-pursuit.com |
|co2 balloonid |58EUR |maxxis ?|
|sum of shipping costs |22+18+10 EUR | various |
|kõikvõimalik pisi elektroonikakola |200+EUR |http://tevalo.ee http://www.oomipood.ee|
|total |1028 | EUR |

====== Õppetunnid ======
  * 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.

====== Links ======
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.