Kasutaja tarvikud

Lehe tööriistad


projektid:voistlusrobotid:robotex:2011:voistkonnad:1

Robotex 2011 võistkond "Nisu"

Liikmed

Veermik

Veermik kopeeriti Robotex 2010 prototüüprobotilt. Kasutati kolme RS-550 mootorit koos P60 reduktoriga ja Siim Viilupi disainitud omni-ratastega. Võrreldes 2010. aastaga muudeti natukene mootorite kinnitust: mootori alusplaadi külge sooviti kinnitada ka enkooder ja mootori draiver. Eesmärk oli muuta mootor koos draiveri ja tagasisidega modulaarseks. Enkoodriplaadi kinnitus tagas küll enkoodrikivile piisava täpsuse, kuid muude tõrgete tagajärjel enkoodrid eemaldati.

Rull ja löögimehhanism

Rulli mootori ja rulli võlli hammasülekanne oli 1:1. Rulli mootor oli Como Drills 944D41, mille teoreetiline kiirus 12 V juures on 2000 rpm. Kuna mootorit toideti oluliselt kõrgema pingega, oli ka mootori kiirus suurem. Prooviti kasutada ka 12 V pinget, kuid siis jäi rull liiga aeglaseks. Rull oli koonuseline, mis aitas palli suunata roboti keskele (pööramise ajal). Lahendus töötas küllalti hästi, kuid rull oli kehvasti valatud, mistõttu rulli servades tekkis soovitule vastupidine efekt.

Löögimehhanismi ajam oli printerist võetud solenoid. Printeri solenoidi kasutati, sest selle südamik on valmistatud trafoterasest, mida on Eestis pea võimatu poest saada. Võrreldes tavaterastega tekib trafoterases ca 40 korda tugevam magnetväli, tänu millele saab kasutada oluliselt väiksemaid solenoide. Solenoidi mähis keriti ise, sest printeris olev mähis oli keritud väga peenest traadist. Löögimehhanismi tagastuseks kasutati vedrusid, mis valiti nö tunde järgi.

Löögimehhanismi juhikud olid määrdevabad Igus Drylin N lineaarlaagrid. Juhikud olid väga head ja sobisid rakenduseks hästi, kuid teiste detailide valmistamise ebatäpsuse tõttu kippus mehhanism kinni kiiluma. Seetõttu tuli lahendust mitu korda ümber teha.

Üldiselt töötas löögimehhanism hästi, kuid juhikud oleksid pidanud pikemad olema. Siis oleks löömisel saanud kasutada suuremat jõudu. Kuna juhikud olid küllalt lühikesed, ei jõudnud vedrud mehhanismi piisavalt kiiresti pidurdada ja kelk kippus juhikust välja jooksma. Seetõttu tuli löögijõudu solenoidi laadimispingega piirata.

Kaamera

Tänu sponsoritele Basler AG ja Orbis OÜ oli meil võimalik kasutada tööstusliku kvaliteediga gigabit-ethernet kaamerat. Täpsemaks mudeliks siis Basler ace-ac640-100gc. Kaamera resolutsiooniks oli 658×492 pikslit ning kaadrisagedus sellel resolutsioonil 100fps, kui küsida kaamerast väiksemat pilti siis on ka suuremad kaadrisagedused võimalikud.

Antud kaameral olid olulised eelised võrreldes varasematel aastatel kasutatud PlayStation3 Eye kaameraga. Esiteks kuna kaamera ühendub arvutiga läbi gigabit-ethernet liidese siis oli meil võimalik kasutada suuri kaadrisagedusi. Õigemini kaamera ning kasutatav liides kokku võimaldasid võtta pilti 100x sekundis. PlayStation3 Eye kaamera puhul oli maksimumiks 60fps sest üle USB2.0'i (480Mbit/s) ei ole võimalik rohkem infot saata. Samuti oli kaameral ka global-shutter mis tähendab et kogu anduri info loetakse korraga ning pallid pildi peal nö laiali ei veni.

Kaamerale sai soetatud ka igati pidi reguleeritav objektiiv. Objektiivi valis meile välja Orbis OÜ ning selleks sai Tamroni M12VM412 objektiiv (link tootja lehele): sai muuta ava suurust (ehk pilti heledamaks või tumedamaks keerata), samuti sai muuta ka fookuskaugust ning suurendust.

Hüperboolpeegel

See aasta kasutasime 360 kraadi nägemist. Selle jaoks sai disainitud hüperboolpeegel mille valmistas Rantelon OÜ. Hüperboolpeegli disainimine oli küll keerukas protsess kuid töö kandis vilja ning peeglist nähtav pilt oli küllaltki hea. Isegi Tartu robotiklubi meeskond „Nasty“ (kes samuti kasutas hüperboolpeeglit) nentis et meil on võib-olla et parim optiline lahendus sellel Robotexil.

PC

Tänu Itaalia firmale SECO oli meil võimalik kasutada väga väikest ning võimast arvutit. Arvuti oli nano-ITX formaadis (12cm x 12cm). Arvutile ostsime juurde 4GB DDR3 mälu ning 16GB CompactFlash kaardi kõvaketta jaoks. Kahjuks selgus et flash kaart arvuti kõvakettana ei olnud kõige stabiilsem lahendus. Päris tihti leidsime ennast asju uuesti installimas (peamiselt graafikadraiverit). Lõpuks ostsime 32GB SSD kõvaketta ning sellega enam neid probleeme ei olnud. Kuna seda kõvaketast ei olnud aga võimalik enam kuhugile normaalselt paigutada siis tekkisid ülekuumenemise probleemid (kõvaketas kattis ära korpuse ventilatsiooniava)

Arvuti SECOnITX-ION spetsifikatsioon on järgmine:

  • CPU - Intel® Celeron® T3100 @ 1,9GHz, 1MB L2 Cache, 800MHz FSB, Dual Core, 64-bit Instruction Set
  • Chipset - NVIDIA® MMP9 embedded ION™
  • Memory - 4GB DDR3 (Kingston)
  • GPU - Integrated Graphic Controller NVIDIA® GeForce9400M, with 16x graphic cores
  • Connectivity - 6x USB 2.0 ports (standard connector + Internal Pin Headers), Gigabit Ethernet,1 x Serial Port (RS-232 / RS-485 configurable), 1 x miniPCI-express slot
  • Audio - Dual jack for HD Audio
  • Various - SM Bus Pin Header, GPIO Pin Header, 2 x 3-Pin Tachometric Fan connectors

Arvuti ja mootorite/anduride vaheline elektroonika

Mootorite juhtimiseks ning andurite lugemiseks kasutasime see aasta FPGA'd (täpsemalt Terasicu DE0-Nano plaati). Kahjuks põles plaat nädal enne võistlust maha ning tuli minna tagasi Pisi-XBEE2 plaadile.

DE0 plaadile sai disainitud ka laiendusplaat:

Laiendusplaadi skeem

Löögielektroonika

Löögielektroonika võtsime eelmise aasta roboti ChuckNorris pealt kuna enda disainitud lahendust ei saanud kohe tööle ning ei olnud ka aega sealt vigu otsida.

Löögielektroonika skeem

Arvuti toiteplaat

Kuna kasutasime see aasta 24V akusid siis arvutile oli vaja step-down impulsstoiteplaati. See sai ise disainitud ning baseerus National Semiconductori SimpleSwitcher seeria IC'l. Samuti oli plaadi peal lineaarne toiteregulaator mis tegi 12V'st 5V'i. Viimane sai valitud küll suures korpuses (TO-252 e D-PAK) ning piisava vooluga (1.5A) kuid regulaator läks ikka väga kuumaks - ligikaudu 100C. Põhjuseks arvatavasti see et kuna impulsstoite IC temperatuur oli ~60-70C siis see viis lineaarregulaatori algtemperatuuri samale tasemele ning siis tuleb juurde arvestada ~30C temperatuuritõus lineaarregulaatori poolt. Selle järgi otsustades polnud probleemiks mitte lineaarregulaatori temperatuur vaid hoopis impulsstoite IC oma. Probleemi oleks saanud lahendada parema jahutusega. Toiteplaat ise toimis ning arvuti sai ära toidetud.

Toiteplaadi skeem

Tarkvara

Mootorikontroller

Kirjutati mootorikontroller, mis oskas vastavalt soovitud suunale ja liikumiskiirusele või pöörlemisele arvutada mootorite kiirused. Algul kasutati enamasti SI ühikuid, et ei tekiks segadust ja tarkvara oleks ühtne.

Kuna mootorikontrollerid purunesid füüsiliselt pidevalt, ei saanud kasutada mootorite tagasisidet ega PID (või PI) regulaatorit mootorite kiiruste hoidmiseks. Seetõttu mindi üle dimensioonite ühikutele ehk suhtelistele kiirustele. Lisaks prooviti mootoritele anda õiged kiirused pildi tagasiside järgi. Näiteks otse sõitmiseks anti kahele esimesele rattale ühesugused kiirused ja suunda reguleeriti tagumise rattaga.

Mängualgoritm

Mängualgoritm oli sisuliselt kopeeritud Robotex 2010 Chuck Norrise roboti tarkvarast. Lisaks programmeerimiskeele erinevusele oli natukene muudetud olekute vahetamist. Olekute vahetamiseks moodustati 2-dimensiooniline massiiv ehk tabel, mille alusel valiti vastavalt kehtivale olekule ja oleku tagastustüübile uus olek.

Mängualgoritmi ei jõutud arendada, sest muude süsteemikomponentidega oli liiga palju probleeme. Üldiselt on kasutatud olekumasin kasutatav.

Pilditöötlus

Pilditöötlust tehti blob detectioni abil. Selleks kasutati http://code.google.com/p/cvblob/ libraryt mis oli piisavalt kiire. Kuna pallid ei olnud meil pildil päris ümmargused siis seda kasutada pallide tuvastamiseks kahjuks ei saanud. Samuti ei olnud väravad pildil kunagi ristküliku kujulised, vaid värava kuju sõltus roboti asukohast kust ta vaatas väravat. Palle otsiti värvide vahemike järgi. Kui vahemikud paigas olid siis oli pilditöötlus töökindel ja kiire aga probleemiks oli nende paika saamine. Kuna pilt oli 8-bitiste värvidega siis pidid kõik värvikoodid mahtuma 8 biti sisse. Piltitöötlusprogrammides on kasutusel erinevad HSL värvide üles märkimise viisid, kas H on 0-360 ja S ja V on 0-100 või on kõik värvid 0-1 jne. Meil olid kõik värvid 0-255, seega pidi tegema teisendusi. Segas ka see, et pilt ei olnud stabiilne - iga kaader mis tuli oli tänu lampide valguse muutlikkusele veidi erinev, üldiselt olid värvid muidugi samad aga ühes piirkonnas võisid väärtused ~10 ühiku võrra kõikuda. Selle tõttu oli raske valida täpseid vahemikke pallide ja väravate jaoks.

Järgmistel võistlustel peaks olema mugavam viis sobivate vahemike leidmiseks, see mis oli kulutas kõvasti aega ja ei andnud täpset tulemust.

Objektide tuvastamisel liikusid andmed järgmiselt: pilt kaamerast (YUV422) → RGB888 (Intel IPP) → HSL (OpenCV) → cvblob → palli sobivuse kontroll → pallide list → pallide list andurite moodulisse pallide mällu.

Nagu näha oli palli teekond kaamerast kuni mängualgoritmini päris pikk, see võiks olla lühem. Hea oleks ka kui erinevaid teisendusi oleks värviruumide vahel vähem aga otse YUV422 pealt ei ole võimalik tuvastada blobe, kuna seal pole võimalik eraldi töödelda üksiku pixeli andmeid.

Pilditöötlust oleks saanud veel kiiremaks teha kasutades ära graafikakaardi võimsust aga kuna polnud algul arvestanud sellega, et CUDA toetab ainult 32-bitiseid pilte siis polnud hiljem enam aega seda ümber teha. Kiirusevõidu suurus ei oleks olnud võib-olla eriti suur ka, kuna ainuke asi mida oleks saanud teha, oli erinevate värviruumide vahel teisendamine. Andmete liigutamine ühest mälust teise oleks kiirusevõidu ära kaotanud.

Mis oli hea pilditöötluse juures oli see, et robot nägi korraga palle ja mõlemaid väravaid, vajadusel oleks saanud end positsioneerida väljakul väravate asukoha järgi.

projektid/voistlusrobotid/robotex/2011/voistkonnad/1.txt · Viimati muutnud: 2016/09/03 15:43 persoon raivo.riiel