Kasutaja tarvikud

Lehe tööriistad


projektid:voistlusrobotid:robotex:2010:voistkonnad:4

Robotex 2010 võistkond "TTÜ Robotiklubi Chuck Norris"

Tegijad

Ülddisain

kogu robot on disainitud ühele kergendusavadega 3mm alumiinium plaadile. Plaadi alumisel poolel on mootorid omniwheelidega, PC toide, kõrgepinge toite moodul, mõlemad akud 4600mAh ja 2500mAh LiPod. Teisel kihil paikneb raam PC ja kaamera kinnituseks, liikuv rulli mehhanism, kondensaator(solenoidi 450v 3000uF), mootorite kontroller, solenoid, I/o moodul ja kaitsmete plaat. PC raamile on kinnitatud kaamera ja PC ning stardi käskude nupud. Rulliku küljes on roboti toite lülitid. Robot on kaetud mustaks värvitud plastik kestaga.

Aruanne

Tarkvara

Roboti tarkvara kirjutati C# keeles, Visual Studio 2010-ga. Tarkvara arendusega jäime veidi hiljaks, kuna algul ei osanud midagi progeda, kui polnud robotit ennast, mida progeda ja asju tegema panna. Proovisime teha algul juppe ette valmis, aga see ei läinud nii hästi kui oleks pidanud.

Pilditöötlus

Algul prooviti panna tööle eelmise aasta Printer Bobi pilditöötlust, mis võttis kaua aega ja tulemus ei olnud hea, ehk tuvastati valesi asju pallina. Mägra võistkonnas proovis Ronald ise kirjutada linescani, mis oli ka edukas aga koos otsustati võtta kasutusele AForge pilditöötluse library. Meile ei oleks linescani algoritm sobinud ka, kuna roboti konstruktsiooni tõttu tuli kaamera paigutada üles, sest löögimehanismi paigutus ei jätnud kaamerale ruumi alla, et oleks saanud panna selle palliga samale kõrgusele. AForge libraryst võtsime kasutusele blob detectioni ja lasime sel otsida ringe pallina, enne tuli filtriga muuta pilt mustvalgeks. Väravate otsimine käis samamoodi. Otsiti ristküliku kujulisi asju, mis olid õiget värvi. Väravate värvi filtreeriti pilti HSL värviruumi konverteerides. Kui palli otsimine pildilt võttis aega 20ms kaadri kohta siis väravate otsimine oli palju aeglasem, ühe kaadri töötlusele kulus umbes 80ms. Arvatavasti HSL kasutamise tõttu. Tuleks kasutada kiiremat pilditöötluse algoritmi edaspidi. Üldiselt sai see siiski hakkama, aga pilditöötluse aeglus takistas roboti kiiremaks tegemist. Kui robot liikus kiiremini, või keeras end kiiresti, siis muutusid objektid kaameras lapikuks ja ei tundnud ära palle.

Pilditöötlus jooksis eraldi threadis ja töötas kogu aeg, otsides pildilt kas palle või väravat. Pilditöötluse juures oligi see halb, et pidi valima mida otsida, mõlemat korraga ei saanud kuna palli tuvastamiseks pidi panema peale RGB filtri mis ignoreeris kõike, mis polnud valge või hall ja väravate otsimiseks filter, mis ainult sinise või punase värvi alles jätsid. Oleks hea, kui oleks pilditöötlus mis suudab otsida korraga nii palle kui väravaid, või mõne muu ülesande puhul oskaks otsida pildilt korraga erinevaid objekte. See muudaks roboti programmeerimise lihtsamaks ja pilditöötluse võib-olla ka kiiremaks. Pilditöötlus oleks olnud võib-olla ka kiirem, kui see oleks töötanud eraldi protsessis, sest ta oli küll eraldi threadis aga pole kindel, kas .net rakendused oskavad enda threade jagada protsessori tuumade vahel. Arvatavasti jooksis kogu roboti tarkvara ühel tuumal ja teine tuum seisis kasutamata. Selle jaoks oleks pidanud pilditöötlus toimuma eraldi protsessis ja suhtlus pilditöötleja ja põhitarkvara vahel oleks pidanud toimuma läbi jagatud mälu või muu sellise, mis oleks asju palju keerulisemaks teinud. Praeguse lahenduse juures uuendas iga kaadri töötlemise järel robot lihtsalt läbi eventi välja kutsumise kasutajaliideses roboti nähtavat pilti ja andis pallide ja väravate infot edasi roboti ajule.

Pilditöötlus tehti objektorienteeritult ja modulaarselt, ehk oleks saanud kasutada kaamera asemel mõnd muud asja ka kust pilte võtta mida töödelda. Oleksime saanud testimiseks kasutada näiteks kaameraga tehtud pilte, mitte vaadata ainult otse live-pilti läbi kaamera aga seda me ei teinud. Võib-olla oleks saanud täpsemini testida sedasi.

Perifeersed seadmed

Roboti PC tarkvara suhtles mootorikontrolleri ja laiendusplaadiga läbi virtuaalse jadaliidese. Jadaliidesega suhtlemiseks kirjutati universaalne alusklass, mis luges eraldi lõimes liidesest andmeid paketthaaval, kusjurues pakette eraldas reavahetusmärk. Kui teatud aja möödudes eelmisest paketist ei saabunud uut paketti või paketi sisu ei vastanud ettenähtule, anti veateade ja lõpetati suhtlus.

Laiendusplaat saatis kõikide digitaalsete ja analoog sisendite andmed arvutile korraga. Andmed töödeldi ksutatavale kujule ja saadeti sündmuste abil edasi kõigile, kellel neid vaja oli. Analoogsisenditele olid seatud teatud piirid ja kui väärtus oli neist väljaspool tõlgendati seda kui andmete puudumist. Andmed saadeti edasi mittenumbrilise väärtusena.

Võistlusalgoritm

Võistlusalgoritmi reliseerimiseks kasutati olekumasinat, kusjuures iga olek oli omaette klass. Et palju korduvat koodi ei oleks, kirjutati olekutele baasklass, millel oli abstraktne oleku tegevuste täitmise meetod ja oleku progressi näitav väli.

Olekute objekte hoiti algoritmi massiivis. Algoritm töötas tsüklina eraldi lõimes. Iga iteratsiooni alguses kontrolliti, millises olekus ollakse, kutsuti välja oleku tegevuste täitmise meetod ja kontrolliti oleku progressi. Kui olek oli edukalt lõpetatud, liiguti järgmisesse olekusse, kui oleku täitmisel tekkis viga, liiguti üldjuhul eelmisesse olekusse. Igale olekule seati erinev taimaut, mille ületamisel liiguti samuti tagasi eelmisesse olekusse.

Võistlusalgoritmile kirjutati samuti baasklass, millele oli võimalik kiiresti erinevatest olekutest kombineerida erinevaid algoritme.

Et kõikide olekute objektidel oleks sama andurite ja kaamera info, kirjutati eraldi klass nende andmete hoidmiseks. Kõikide sisendseadmete info koondus sellesse klassi. Enne andmete väljastamist, töödeldi see otse kasutatavale kujule.

Palli kauguse hindamiseks kasutati ainult palli raadiust. Palli otsimisel valiti alati lähim pall ja jäeti see meelde. Kui pallile lähenemisel, tuli kaadrisse vähemalt 25% suurem pall, valiti sihtmärgiks uus pall. Pallid jäeti meelde koos identifitseerimisnumbriga. Kui kahe järjestikusel kaadril oleva palli keskpunktide koordinaatide erinevus jäi teatud piiridesse, arvestati, et tegemist on sama palliga. Selle põhjal jäeti meelde, mitmel järjestikusel kaadril seda palli on nähtud. Pall pidi olema olnud kaadris teatud arv kordi, muidu seda palli ei valitud.

RC5 vastuvõtja info töötlemiseks kasutati tabelit, kus read tähistasid vastuvõtjaid ja veerud vastuvõetud signaali. Signaali vastuvõtmisel suurendati vastavat tabeli lahtrit, mis sümboliseeris signaali tugevust. Kui vastasvärava signaal oli tugevam kui enda värava signaal, leiti vastasvärava suund selle põhjal. Vastasel korral leiti vastasvärava suund oma värava signaal põhjal. RC5 vastuvõtja infot kasutati ainult värava poole pööramise alustamiseks, kui kaameraga väravat ei nähtud. Seega piisas suuna hindamisel 90-kraadisest sammust. Väravat sihiti ainult kaamerapildi põhjal.

Palli ja värava poole pööramisel kasutati “jõnksutamise” eemaldamiseks hüstereesi. See tähendab, et palli või värava suund pidi olema roboti otsesõidu suunast teatud kaugusel et selles suunas pöörama hakata. Kui pöörama oli juba hakatud, siis seda ei lõpetatud enne, kui palli või värava suund ühtis peaaegu roboti otsesõidu suunaga.

Üldiselt oli võistlusalgoritm rahuldava struktuuriga. Oleks ainult võinud olekute süsteemi teha mitmetasemeliseks, see tähendab, et olekutel oleks alamolekud jne, sest mõni olek läks päris keeruliseks ja raske oli juba koodi jälgida. Samuti oleks pidanud kirjutama olekud eriolukordadele, näiteks seinaäärsete pallide püüdmise jaoks.

Roboti juhtprogrammi kasutajaliides

Kasutajaliides tehti Windows Formsi kasutades. See näitas kaugusandrite andmeid, roboti logi mis näitas olekumasina olekut ja roboti kaamera pilti. Eraldi oli veel roboti hiirega juhtimiseks ala kus hiirega liigutades liikus robot määratud suunas. Läbi kasutajaliidese sai muuta ka väravate HSL ja palli otsimise RGB filtri parameetreid, mis aitasid robotexil kohapeal kiiresti leida parima filtri seadistuse.

Kasutajaliideses sai valida värava värvi, kuhu palli lüüa ja värava majaka kanalit, kuhu lööma peaks. Start ja stop nupud olid ka, kust sai käivitada juhtalgoritmi. Start seadis algoritmi algolekuse ja käivitas selle, stop seiskas roboti algoritmi. Samad nupud - värava valik ja algoritmi start ja stop olid ka roboti peal füüsiliselt nuppudena olemas lõpuks, aga tekkisid tema külge alles enne robotexi. Seni kuni nuppe polnud kasutasime kasutajaliideses olevaid roboti katsetamiseks.

Elektroonika

Sai koostatud lähtudes põhimõttest, et iga funktsionaalsus oleks realiseeritud eraldi plaadil ja rikke korral toimuks vigase ploki vahetamine võimalikult kiiresti. Võimalikult palju kasutasime valmis ja äratestitud lahendusi.

Mootorikontroller

Roboti mootorite juhtimiseks. Kasutasime Robotiklubi poolt välja töötatud lahendust. http://www.robotiklubi.ee/projektid/pisi_xbee2

Laiendusplaat

Löögimehhanismi juhtimiseks ja aduritelt tagasiside saamiseks. Jälle kasutasime valmis lahendust.

Kõrgepingemoodul

Löögimehhanismi kondensaatori laadimiseks. Boost konvetrer MC34063 kivi baasil. Töö käigus sai valmis tehtud kaks skeemi, sest esialgne plaat ei töödanud kõige paremini. Hiljem selgus, et viga polnud draiveri puudumises vaid töösagedust määrava kondensaatori ja voolu piirava takisti väärtustes. Ühesõnaga mõlemate skeemide järgi tehtud plaadid said lõpuks tööle pandud. Kondensaatori C1 väärtusega võib veel mängida, aga meile piisas. Esimese skeemi töötav lõppversioon hv1.zip ja teise skeemi töötav lõppversioon hv2.zip.

Toiteplaat

Kogu elektroonika tuli ära toita aku pealt ja eri osade kaitsmiseks sai toiteplaadile pandud eraldi kaitsmed erinevate skeemide toiteahelatele. Selline lähenemine tasus ennast ära kui katsetamise käigus kõrgepingeplaat lühisesse läks. Eelmise aasta lahendus.

Andurid

Robotil olid anduritest Sharp IR analoog kaugusandurid, lülitid stardikäskudeks, mootori tagasiside ja palli andur.

Sharp

Kasutasime kolme andurit. 80-150cm andur värava avastamiseks, asus see kaamera all 24cm kõrgusel. Kahte 10-80cm andurit seina tuvastamiseks, paiknesid nad kahel pool rullikut 10cm kaudusel roboti piiridest.

Lülitid

Stardi ja stop nupp. Ennem starti värava ja ir andu ri valikuks dip lüliti. EPIC Feil otsustavas voorus, kus lõime endale 8 väravat oli lülitite 5v kaabel plaadi küljest lahti põrunud, mistõttu ei saanud robotil muuta väravat. Idee: kasutada superatacki ja liimida kõik pistikud omavahel kokku! Lööki juhtisime laiendusplaadi väljundiga, mis oli ühendatud transistoriga ja see omakorda lülitas võimsat releed kondensaatori ja solenoidi vahel.

Palliandur

Palliandur koosnes ledist ja fototransistorist, mille väljund oli ühendatud laiendusplaadiga.

IR andur

Väravate IR vastuvõtja oli ühiselt disainitud plaat kahe IR vastuvõtjaga. Probleemidaks oli see, et sai vaadata vaid ühes suunas täpselt ja pöörata mingis suunas.

Mootorid

Tegu on BaneBots-' mootoriga 26:1, 36mm Planetary Gearmotor, RS-540 Motor. Antud mootoril on palju eeliseid võrreldes eelmisel aastal kasutatud EMG30-ga. Esiteks on tegu planetaarülekandega, mis on ühtlasi vastupidav ning ka efektiivne. Võrreldes EMG30-ga on uutelmootoritel ka tunduvalt rohkem jõudu. Kindlasti on ülekande juures tähtsaks see, et ülekande võll on 9,5 mm läbimõõduga ning võll toetub pukside asemel kuullaagritele. Tänu sellele ei tohiks rattad roboti raskuse all kaheksasse vajuda. Ülekandel on ka väga pikk(55mm) võll mis annab võimaluse ka enkoodrid lisada. Alla lisasin tabelid mootori ja ülekande andmetega.

Physical properties
Type Planetary
Reduction 26:1
Stages 3
Gear Material All Metal
Weight (Gearbox only) 7.2 oz (205g)
Weight (with motor) 12.6 oz (358g)
Length (Gearbox only) 1.9 in (49mm)
Length (with motor) 4 in (102mm)
Width (Sqaure) 1.5 in (38mm)
Shaft Diameter 0.375 in (9.525mm)
Shaft Length 2.15 in (55mm)
Shaft Key 0.125 in (3.2mm)
Shaft End Tap #8-32
Mounting Holes (12) #10-32
Calculated Performance*
Motor RS-540 (Pinion)
Operating v 4.5v - 12v
Nominal v 12v
No Load RPM 263
No Load A 1A
Stall Current 42A
Stall Torque 2527 oz-in 17843 mN-m
Kt 60.2 oz-in/A 425 mN-m/A
Kv 22 rpm/v
RPM - Peak Eff 227
Torque - Peak Eff 397.1 oz-in 2804 mN-m
Current - Peak Eff 6.6A

* - arvutused on tehtud nominaalpingega ning ei võta arvesse kadusid ülekandes

Solenoid

http://www.robotiklubi.ee/projektid/robotex_2010/prototyyp/solenoid * Prototüübiga võrreldes sai paigaldatud lineaarlaagrid ja rauast südamik, mis oli maandatud korpusesse. Solenoidi puuduseks oli peamiselt see, et seda sai liigselt katsetatud, mistõttu olid lineaar laagrid võistluseks kulunud ja pallid ei liikunud enam õiges suunad.

Ideed:

  1. solenoid peaks olema 550 keerdu 0,6 mm vasktraadist 13 mm südamikuga ent kogu mähise pikkus peab olema maksimaalselt 45mm(lühem kui hetkel).
  2. Solenoid peaks asuma palliga samal tasandil- see välistab mõttetu ülekande loomise.
  3. Solenoidi peab juhtima MOSFETiga mitte releega!!

Rullik

Mootor Speed 300 mis andis 5V juures ~3000rpm Ülekanne oli 1/3 plastik hammasratastega Rull oli algselt plaanis jätta staatiline, kuna oli valatud väga pehmest „roosast“ kummist, kuid ilmnes et parema stabiilsuse saavutamiseks tuli rull muuta liikuvaks. See tagas parema pallide hoidmise.

Korpus

Valmistatud 3mm plastikust painutades vastavasse vormi. Eeliseks see, et kogu robot oli ligi pääsetav 8 kruvi eemaldamisega 4 korpusel ja 4 PC kinnituseks.

Pildid

Roboti lähtekood chucknorris.zip

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