Nasty Circuits Team Description Paper

Allikas: Digilabor

Meeskond Nasty Circuits osales Robotexil 2010.

Selles artiklis on veidi kirjeldatud meie roboti ehitust.


Meeskond vasakult: Johu, Mihkel, Tuule, Sander, Vahur
Logitech sponsoreeris meid tasuta kaameraga
TKTK sponsoreeris meid peegli freesimisega
Pilt meie roboti 'seljaajust' meeskonna särgilt.

Sisukord

Mehaanika

Kogu mehaanika on disainitud Solidworks 2010-s ja enamus selles on valmistatud Sanderi poolt TÜTI-s. Vahelduva eduga aitasid ka kõik teised meeskonnaliikmed, Team Helina ja TKTK-st Tavo ja Co. Enamus detaile on valmistatud 8, 4 või 2 millimeetrisest polücarbonaadist, põhi ja kaas on komposiit[1] materjalist ning on ka kasutatud alumiiniumi, terast ja messingut.

Üldine paigutus

Roboti vanker on 300 mm läbimõõduga ümar ketas, kus peal asetsevad 60, 180 ja 300 kraadi all kolm veomehhanismi [2]. Roboti eesotsas on palli käsitlemiseks triblamismehhanism ja löömiseks on pikki roboti y-telge löögimehhanism. Roboti 60-180 kraadi sektorisse jääb enamus elektroonikast, juhtmetest ja roboti peamine energia allikas, 11,1V-ne liitiumpolümeer aku. Roboti 180-300 kraadi sektorisse jääb löögimehhanismi kondensaator ja ASUS Eee aku. Kaane küljes on elektroonika lähistel kontrollpaneel. Kaane peal on kaamerakonstruktsioon.

Märkusi:

  • Juhtmelahenduse peale tuleb juba eos mõelda - Johu

Veomehhanism

Mootor koos omniratta ja kinnitustega.

... on üks olulisemaid asju meie roboti juures, sest see liigutab teda punktist A punkti B. Tegemist on "igasuunalise" (inglise keeles omnidirectional) liikumis süsteemiga, mis kasutab ratastena omniwheel'e. Rattad on saadud juhendajate käest ja on täiesti standartsed netist ostetavad[3]. Mootoritena kasutasime BDSG-37-40-12V-5000-R10 mootoreid. Tagant järgi tarkusena saame öelda, et tegemist ei olne kõige parema valikuga, sest antud mootorid on esiteks veidi nõrgad ja teiseks ei ole nad üldse kvaliteetsed. Mootori võlli küljes on messingust telg, mille peale toetub ratas. Telje teine ots on kinnitatud laagriga polücarbonaaadist puki sisse. Telje otsa sees on väike magnet, et saaks magnetanduriga lugeda mitu kraadi telg on pöördunud. Hiljem sai lisatud ka messingust spacer, et ratas telje peal edasi-tagasi ei liiguks.

Märkusi:

  • Täpsemaks liikumiseks tuleks teha rattad ise.
  • Kvaliteetsed mootorid on tähtsad. (Sealjuures lühikesed) (+ jõud on parem kui kiirus täpseks sõiduks - Johu)

Löögimehhanism

... koosneb kolmest olulisest osast: mähis, löökraud ja tagasitõmbemehhanism. Mähist keerasime kokkuvõttes 5 korda. Kõigist kordadest õppisime midagi ja saime targemaks. Laias laastus järgisime mähise keeramise how tod. Mähis ise on keeratud u 0.8 mm traadist. Mähise pikkus on u 60 mm, siseläbimõõt u 12 mm ja välisläbimõõt u 25. Paremaks tsentreerimiseks on mähise mõlemas otsas mähist keerates jäetud aste. Et mähise effektiivsust tõsta on tal ümber u 2,5 mm terasest toru ja otstes sama paksust terasest seibid. Löökraud koosneb samuti mitmest osast: plungeri terasest osa, alumiiniumist osa ja alumiiniumist löögipea. Löökraud libiseb kahe plast seibi peal, mis asetsevad mähise otstes olevates astmetes. Lisaks, et löögipea viltu ei vajuks libiseb ka see kahe paralleelse teflonist risttahuka peal. Tagasitõmbemehhanismiks on lihtsalt tavaline kummi riba. Lisaks on löökraua tagumises otsas suurem metallseib ja kummist seib, et pidurdada ja pehmendada lööki, et see robotit ei lõhuks ja löökraud lihtsalt otsast välja ei lendaks.

Vaata ka Sise:Pallidega tegelemine

Märkusi:

  • Kui teha tugeva löögiga coilgun, siis tuleb teha mehaanika, mis selle löögi all ei purune. !!!
  • Viia läbi korralik uurimine coilgun'i teemal[4]

Triblamismehhanism

Triblamimehhanismi üldine kontseptsioon.

... on sel aastal liikuv. Triblamisrull on samast lateksi laadsest kummist, mis on valatud messingust teljele. Rulli läbimõõt on u 20 mm ja pikkus u 70 mm. Telje ja mootori vahel on rihmülekanne, mille ülekande tegur on 5:1. Kogu triblamismehhanism toetub kahele laagrile, mis lubavad sellel liikuda edasi-tagasi.

Märkusi:

  • Kindlasti kiirem mootor. Praeguse teoreetilise 2000 rpm'i asemel võiks olla 12000-15000 rpm.
  • Rull ise veidi pehmemast materjalist. TTÜ-l oli sarnane nagu meil, kuid palju pehmem (roosa).

Kaamera konstruktsioon

Tegemist on kaamerasüsteemiga, mis kasutab hüperboolpeeglit ja näeb igas suunas. Peegel on polücarbonaadist detaili küljes, peegeldav pind all pool, toestatud kolme alumiiniumist L-profiilist jalaga. Peegli all on peegli poole vaatav Logitechi C910 webcam, millega Logitech sponsoreeris.

Märkusi:

  • Kõrgemale, suurema läbimõõduga peegel.

Peegel

Palli ligikaudse nurksuuruse arvutamine peegli kujutisel. Interaktiivne versioon
Solidworksi mudel renderdatult.

Kaamera meie robotil vaatas otse üles hüperbolpeeglile. Nõnda näeb robot igasse suunda samal ajal. Võrrandi koostasime võtsime arvesse järgmisi asjaolusid:

  • kaamera vaaternurk - et maximaalselt piksleid asuks peeglil, mitte selle taga laes
  • kaamera fookussügavust - et saaks tervet platsi korraga fokuseerida
  • platsi suurust pildil - mida teravam hüperbool, seda väiksem on roboti kujutis ja hästi valitud serva nurga korral ei näe robot üle väljaku vaid võimalikult suur on väljaku kujutis
  • kaamera ja peegli võimalikke asukohti roboti küljes - mehaanika ja võistluse reeglid seavad omad piirangud

Soovitud tulemuse saavutamiseks koostas Johu eraldi analüütlise mudeli peegeldusest sõltuvana objekti ja kaamera asukohast. Valitud võrrandit sai kontrollida SolidWorksis SolidCam plugin'i abil.

PEEGLI VALMISTAMISEST

Esimene pildike poleerimisjärgus peeglilt
Sandri nägu peegeldab, mis ta sellest peeglist arvab

Elektroonika

Elektroonika loomisel võtsime eesmärgiks teha võimalikult palju vajaminevast ise ning kasutada võimalikult vähe valmislahendusi. Sellest tulenevalt saime omal nahal tunda, mida tähendab eelnevalt katsetamata plaadiga robotit ehitada, kuna nii seljaaju kui ka coilguni plaadiga tekkisid töö käigus probleeme, mis olid tingitud vigasest disainist.

Algse idee järgi koosnes elektroonika kahest iseseisvast plaadist: seljaajust ning coilguni plaadist. Hiljem lisandus seljaajule veel eraldi mootorite draiverite plaat, millel olid õige pinoutiga draiverid.

MCU aka seljaaju

Seljaaju skeem
Seljaaju layout

Seljaajul olid mikrokontroller, milleks valisime AT90USB647, kuna oli üks vähestest meile saadaolevatest Atmeli kividest, millel USB. Lisaks olid idee järgi seal ka mootorite draiverid (A3950SLP, mis hiljem küll eraldi plaadi peale liigutatud said, kuna Eagles tehtud näpuka tõttu olid draiverite ühe poole jalad peegelpildis ning lihtsam oli draiverid mujale viia kui plaadil häkke teha. Põhiliselt baseerus meie seljaaju mootorite plaadil ning Tõnu Samueli tehtud plaadil. Samuti paiknes plaadil kogu pinge reguleerimise ning aku pinge mõõtmise osa, mis liiga madala pinge korral buzzeriga sellest teada andis. Pesadena kasutasime tavaliste pinheaderite asemel Molexeid, mis säästis tõenäoliselt hulga peavalu, kuna ei pidanud polaarsuse pärast muretsema. Lisaks olid seljaajul ka SPI-pesad coilguni ja magnetanduritega (Magnetandurid MLX90316KDC-SPI) suhtlemiseks.

Töö käigus selgusid mõned vead/puudujäägid, milles suurima probleemi tekitasid kindlasti vale pinoutiga draiverid, kuid lisaks neile oli plaadil ka üleliigseid pesasid (algselt mõeldud lülitite jaoks, kuid need said hiljem teisiti lahendatud). Samuti selgus, et hoolimata tehasest kaasatulevas bootloaderist, on mõistlik lisaks ka tavaline programmeerimispistik panna, kuna bootloader ei toeta fusede programmeerimist, mida meil korduvalt vaja läks. Samuti võiks olemas olla ka JTAGi pesa, et debuggida.

Coilguni laadija

Coilguni plaat kasutas kondensaatori laadimiseks LT3750 kivi, mis trafo (DA2034-ALB) abil tõstis pinge 12V pealt 250V peale, laadimise ja suhtluse kontrollimiseks oli veel ka ATmega88. Kuna plaadil oli müraprobleeme ning USB-ühendus kippus laadimisel katkema, tuli seljaaju ning coilguni elektroonikaplaatide vahele terasplaat, hulgaga kondensaatoreid plaadile ning ferriitrõngad toitejuhtmetele. Lisaks tuli põhjalikult ära shieldida kondensaatorisse jooksvad juhtmed ja kondensaator ise ning sellele kõigele lisaks veel 2 kihti hõbepaberit emaplaadi alla.

Võistlusel kasutatud coilguni plaadi kood on siin. Skeemi leiab koos teistega siit

Ideed edaspidiseks

  • Elektroonika peab olema kas moodulitena, sest siis lihtne mittetöötavaid osasid välja vahetada ja debuggida või eelnevalt põhjalikult läbikatsetatud tervikplaat
  • Juhtmete ühendamine kahe korruse vahel võib keeruliseks minna ja selle peale tuleb mõelda ENNE kui robotit valmistama hakata
  • Juhtmed võtavad ruumi. Palju.
  • Akudele ligipääsetavus tuleb 3 korda läbi mõelda ja ei ole mingit kompromisside tegemist selles osas
  • Ei tohi kasutada haruldasi komponente, mille läbipõlemine võib tähendada mitmepäevast delayd. Igat komponenti peab varuks olema
  • Mehaanika peab olema nii kasutatav, et kui nt üks inimene tegeleb sõitmisega, saaks teine samal ajal nt coilguniga mängida ja selle löögitugevust kalibreerida(migni pleksist lisakorpus vms). Sama ka nt kaamera moundi kohta.
  • Alati tuleb kasuks lihtne debugimisplaat, mis kindlalt töötab ja mille peal on võimalik lihtsalt erinevaid suhtlusvahendeid katsetada(SPI, I2C jt), et koodi saaks paralleelselt kirjutada.
  • Kuhjaga progremispistikuid ja ka debugimiseks pesad
  • Peab olema mugav ots, kust GND kätte saada et ossiga debuggida
  • Elektroonika ligipääsetav igas konfis
  • Kui teha konstantse löögitugevusega coilgun, peaks olema võimalik ilma koodi muutamata löögitugevust reguleerida. A la poteka vms abil

Tarkvara

Nii roboti mehaaniline olemus, riistvara kui meeskonna tööjaotus soosis tarkavara jagamise mitmeks iseseisvaks komponendiks. Kui coilgun'i juhtelektroonika välja jätta, siis jagasime ülesanded kahele platvormile, mida nimetasime seljaajuks ja ajuks. Esimese realiseerisime elketroonika osas kirjeldatud viisil Atmega kivil ja selle ülesandeks oli tegelda roboti refleksidega: genereerida mootirtele pwm, suhelda magnetandurte, coili ja ajuga, kuulata nuppe roboti korpuse küljes. Veidi keerulisem ülesanne oli seljaajul ajult saadud liikumisvektorite arvutamine PWM'iks nii, et robot reaalselt enamvähem sinna ka sõidaks, arvestades süsteemi mitteideaalsusega ja samal ajal magnetandurite mõõtmiste järgi jälgida ja korrikeerida roboti asukohta ja kiirust. Aju ülesandeks oli pilditöötlus ja sõiduloogika. Mõlemas osas tuli realiseerida ka USB suhtlus.

Aju platvormiks kasutasime Asus EeePC 900 emaplaati ja operatsioonisüsteemina Arch linux'it. Mihkel kirjutas openCV madalat taset kasutades C's pilditöötluse ja Johu korraldas linuxi, usb suhtluse ja sõiduloogika.

Märkusi:

  • Tarkvara jäigi meie roboti kõige nõrgemaks küljeks. Mehaanika ja elektroonika valmistamise planeerimisel ei tohi alahinnata rohkeid tõrkeid, mis teel tekkivad ja tarkvara jaoks peab arvestama rohkesti aega - ükski korraliku tarkvaraga robot pole veel feilinud!
  • See on tõsi, et varakult tuleb arvestada sellega, et projekt kasvab suureks. Tehes vastav algus, on hiljem kõvasti lihtsam ja efektiivsem.

Linuxi võimalused

WiFi

Pikemalt wifi artiklis.

Kasutasime ära mitmed linuxi mugavused. Kui roboti aju ja seljaaju toide sisse lülitada siis umbes 20 sekundi pärast pani Arch automaatselt püsti WiFi adhoc võrgu. Selleks kasutasime Archi sisse ehitatud võimalusi /etc/rc.conf/wireless ja /etc/rc.conf skriptide confimise läbi. Tuli parandadus teha ka network daemonis, mis ei arvestanud võimalusega, kasutaja soovib wireless scriptis mode parameetrit muuta, milleks peab liides varemat olema ifconfigiga välja lülitatud. Vastavad näidised on wifi artiklis.

dfu-programmer

Kuna meie seljaaju kivi at90usb647 oli sisse ehitatud USB kontrolleriga, kasutasime sellel DFU bootloaderite, et seda üle USB'i progeda. Meil on pisike script, mis järjest tegi ära dfu-programmer at90usb647 reset (seljaaju funktsionaalsuselt bootloaderisse), make, dfu-programmer at90usb647 flash, dfu-programmer at90usb647 start. Sama asja võib lisada ka Makefile funktsionaalsusesse. Lisaks oli meil vahepeal kasutusel, et automaatselt alustaks ka seljaajult tulnud info logimisega, aga tuli kasutusel udev rules.

udev reeglid

Udev reeglite abil on võimalik vastavalt erinevatele parameetritele ära tunda arvutiga ükskõik mis moel ühendatud seadmeid ja muuta operatsioonisüsteemi käitumist vastavate sündmuste korral. Meie uurisime seda eelkõige seetõttu, et coiliga laskmise hetkel võis USB suhtluses tekkida nii suur häire, et arvuti nagu ühendaks USB uuesti ära. Idee järgi võinuks siis automaatselt jätkuda võistlusprogramm. Vanalt kohalt jätkamise realiseemine tundus üsna keerukas ja asi jäi lõpuni realiseerimata. Küll aga sai ära kasutatud võimalus muuta seadmete nimesid /dev kaustas (kui näiteks kaamera uuesti ühendada, võib juhtuda, et nime lõpus muutub näiteks number, sest vana nime kannab veel zombi... sellisel juhul ei saa sa aru, miks robot palle ei näe... näiteks).

Udev reeglite - TODO artiklis on mõned minu tehtud reeglid näidisteks ja natuke pikemalt kirjeldatud kasulikke töövõtteid reeglite koostamisel.

failisüsteem ja kasutajad

Linuxi ülesehitus soodustas meeskonnatööks mugava failisüsteemi ülesehitust. Igal robootikul oli oma kasutaja ja seega oma home, kus võis teha, mida tahtis. Meie roboti koodid ise asusid /robot/arendus ja /robot/võistlus kaustades (millel olid muidugi users grupile kirjutamise õigused). Ühes olid ka vastavad lähtekoodid, teises jälle sciptid vastvalt strateegile väljakul ja võistluslogid. Arenduse all olid teemade kaupa alamkatalogid, mis eraldasi atmega koodi, pilditöötluse ja juhtloogika. Terve arenduskaust oli svn-is, mis on HEA ASI! Kasutage seda. Ainult svn up, svn ci ja ongi sinu igapäevased käsud ja koodi tagavara olemas. Nõnda oli võimalik vahest koodida kodus või loengus, kui koodi viimane versioon, oli kõigile meeskonnas igal ajal kättesaadav. Vajalikke alamkaustu linkisin mina otse enda kodukausta, et töö mugavamini sujuks.

torud ja modulaarsus/ülesehitus

süsteemi modulaarsuse ehitasime üles torude (pipe) ja FIFO-de abil. Kuna tarkvara arendamine jäi nätuke hilja peale, jäi see osa korraliult läbimõtlemata ja välja ei kukkunud kõige elegantsem lahendus võimalikest, aga meie tegime nii: võistlemiseks käivitasime loogika koodi, mis kuulas USB'i ja pilditöötlusele vajaliku info pani FIFO-se mille nime, sai pilditöötlus käivitamise käsus parameetrina ning pilditöötluse stdout pipesime jällegi võistlusprogrammile, kes luges sellest pallide koordinaate ja muid pilditöötluse andmeid. Esialgu piltitöötlus roboti oleku kohta infot ei vajanud ja siis tundus antud lahendus veel kena küll. Loogika programm suhtles USB'ga all toodud viisil.

Juhtkood

Olemuselt juhtis roboti tööd tervikuna pythonis kirjutatud 'vase mehe olekumasin'. Ehk siis pseudo paraleelarvutus toimis kiiresti kordival main loopil, mis kontrollis olekute 'time-out'-e ning seljaaju või kaamera infot puhvris. Kui puhvris leidub infot, loetakse see kõik üles ja kui saadakse kokku infoühik, siis seda töödeldakse ja kutsutakse callback, mis omakorda on 'event handler' rollis. Sõltuvalt sellest, mis olek robotil parasjagu on, käsitletakse infot erinevalt.

Sõiduloogika kondikava

Alati, kui pall peaks olema triblajas tuleb sellega tegeleda - mõnda aega üritada väravale suunata ja selle ebaõnnestumise korral tuleb natuke ringi sõita. Kui palli parasjagu ei ole otsitakse lähim pall. Kui see on alla teatud piiri, siis suunatakse sellele ja minnaks üle pimesi lähenemise resiimi, mis toimub 'timeout'i või palli kättesaamiseni. Kui pall on kaugemal, siis rallitakse sobivasse kohta, kust võimalikult kiirelt saaks ära teha pimesi lähenemise. Kui kohapeal seistes palli ei nähta, siis sõidetakse natukene ringi.

USB suhtlus

USB suhtluse olime üles ehitanud jadasuhutluse (serial) matkimisena. Linux pidas USB seadet mingiks standartseks modemiks. Käske sai saata otse /dev/ttyACM0 faili kirjutades, aga väheke korralikum ja võimalusterohkem lahendus oli kasutada pySerial teeki. Viimane võimaldas ka faili lugemise ja kirjutamisega tegelda mitteplokeeruvas (nonblocking) resiimis.

Non-blocking lugemine pilditöötluse pipe'ist

See oli üks probleemidest, mille lahendamisega tuli natuke vaeva näha. Juhin tähelepanu, et stdin viitab üldjuhul terminali tüüpi objektile, aga pipe ei ole seda mitte (stdin.isatty()). Pipe on linuxis teatud eriline file[5].

old_settings = fcntl.fcntl(stdin, fcntl.F_GETFL)
fcntl.fcntl(stdin, fcntl.F_SETFL, old_settings | os.O_NONBLOCK)
while 1:
   c = stdin.read(1)
   if (c!=''):
      videoBuf.append(c)
fcntl.fcntl(stdin, fcntl.F_SETFL, old_settings)

Liikumiskood

Meie mudeli järgi takistab roboti liikumist veermiku hõõrdejõud (iga ratta puhul) ja põhimõtteliselt ühe omniwheeli lohistamiseks kuluv jõud. Ühte neist mõõtsime roboti keerutamisega ümber oma telje ja teise saime kätte, kui robotil lasime ühes väljavalitud suunas sõita. Sirgete tõus PWM - Velocity graafikul määrab ära hõõrdumise. Kui me igale rattale kiiruse välja arvutame, siis arvestame ainult veermiku koormusega. Pärast seda tuleb ühe ratta lohistamiseks täiendav vajalik PWM liita vastavalt mootorite asenditele igale mootorile. Ehk siis veermik + osaline ühe ratta lohistamine.

Kõige tähtsam osa toimus timeri katkestustel. 100Mhz peal küsiti round-robini põhimõttel kõiki andureid. Meil oli kolm magnetandurit ja iga magnetanduri järel toimus üks kindrel tagasisidefunktsioon:

  1. positionLoop // taastab soovitud positsiooni
  2. velocityLoop // taastab soovitud kiirust
  3. navigate // kui kõigil kolmel anduril on inf antud, siis arvutame sellest uues asukoha

Vaata Mall seljaaju algoritmi kirjeldus.

Pallide löömine

asdf

Pilditöötlus

Hüpepoloidpeegel

Sai tuletatud valem leidmaks mis kohta mingi piksel hüperboloidi peegeldusest näeb. Valemit rakendasime pildi "sirgeks tõmbamiseks" ehk väljaku pinna perspektiivi teisendamiseks, et selle järgi timmida parameetreid. Võistluskoodis genereeriti nende timmitud parameetrite abil massivid hinnanguga iga piksli kauguse, asimuudi ja poolarnurga, horisontaalse ja vertikaalse nurksuuruse ja ruuminurga jaoks.

Tuvastamine

Tuvastamiseks oli tehtud värvikaart, ehk 256*256*256 massiiv kus oli iga võimaliku piksli tooni kohta kirjas kas ta võiks olla: väljak, pall, punane värav, sinine värav, vastase robot, või muu. Antud kaarte sai salvestada erinevaid ja need sai valmis teha kas realajas või salvestatud videos vajutades vastavatele värvidele. Nende värvide põhjal sai jagatud iga kaader ühendatud ühtevärvi aladeks ja ühendatud värvialadeks (kõik ühtevärvi alad ja kõik ühendatud värvialad väljaku värvi taustal) ja selle käigus kogutud nende alade kohta statistika: suurus, minimaalsed ja maksimaalsed kordinaadid nii ristkordinaadistikus kui ka polaarkordinaadistikus, ümbermõõt, ruuminurk, lähima punkti asukoht, kaugeima punkti asukoht, ja mõned statistilised momendid. Kasutades seda infot sai siis otsustada millele iga laik vastata võiks. Veel sai pildi pealt tuvastatud kolme suurima ühendatud värvilise ala servad, millest siis kõige tsentraalsem osa vastab väljaku ja vastase roboti servale.

Kaardistamine

Kaamera sätted

Raskused

Varia

Koostöö

Ilusate särkidega noormehed ilusa roboti juures pead murdmas.(pilt: Mihkel Pajusalu)

Kõrvalt vaataja pilgu läbi sujus koostöö võistkonna liikmete vahel edukalt. Väiksemaid ebakõlasid närvilistel hetkedel küll tekkis, kuid need paistsid ühise eesmärgi nimel lahenevat. Üksteisele oma tegevuse selgitamine saaks veel sagedamini või põhjalikumalt toimuda, mis võiks kaasa aidata ka konstruktiivsemale tegutsemisele.

Kleebised, särgid

Lasime kleebised robotile printida Reklaamikompaniis, enamik tulid ka sobivad välja. Robotile said lõpuks peale matile valgele kilele prinditud Tartu Ülikooli ja Logitechi logod ning roboti nimi. Lisaks sai teistele Logitechi kaameraid kasutavatele tiimide jagatud vastavalt soovile kas läbipaistvale või valgele kilele prinditud firma logosid.

Võistkonna eristamiseks ostsime Tartu Ülikooli tumesinised suveniirsärgid, mille seljale lasime reklaamibürool Feiss trükkida meie mootorite plaadi skeemi, võistkonna nime ja toetajate logod. Et pilt tuli esitada vektorgraafikas, siis oli sellega omajagu probleeme, kuid lõpuks sai see mure Johu õe, Maarja, abiga lahendatud.

Kokkuvõte ja järeldused

Võib öelda, et eesmärki täitvalt said valmis:

  • Mehaanika - robot sõitis, triblas palli ja oli üpris ilus
  • Peegel ja selle kinnitus - saime kaamera pildist kenast aru ja matemaatika klappis vajalikul määral
  • Elektroonika - vool jõudis punktist A punkti B
  • Coil
  • Atmega kood - robot sõitis magnetandurit järgi ja täpselt, kusjuures kiiruse ja kiirenduse paranadamist me ei kasutanudki.
  • USB suhtlus
  • Suur osa pilditöötlusest - pallid leiti üles ja koordinaadid leiti. Samas jäi suur osa potensiaalist realiseerimata. Lõpuni debugimatta jäi asukoha leidmine väravatest ja platsi servadest ning pallide kinemaatiline otsimine pildilt.

Peaaegu täielikult jäi realiseerimata potensiaal loogika osas. Kiiruga kirjutatud algeline oleku-masin ja selle bugid oli see, misläbi avaldus meie pidev ajaplaanidest maha jäämine. Just see osa oli võistlusel kõige puudulikum.

Johu 7. detsember 2010, kell 08:09 (UTC)

Johu mõtteid ajast

Nii ei tohiks välja näha seis tallinnas.

Viskasin blogile pilgu peale. Kokkuvõtvalt:

  • 1. juuli olime juba mõnda aega roboti disainist mõelnud ja juuni alguses jätkasime juppide otsimisega ja peeglite ja kaamerate uurimisega.
  • 16. august liitus Mihkel ja paar päeva hiljem osteti alles pleksi tükid. Plaan oli ehitama hakata juba augusti alguses!
  • 2. september on Mihkel käe külge pannud pilditöötlusele ja Sander saab ratta välimised kinnitused valmis. Plaan oli septemberi alguses omada vankrit! Paremal juhul liikuvat mootorite ja driveritega.
  • 26. september on meil olemas kaamera ja peegli võrrand. Oleks võinud olla varem.
  • 30. september sai coil enamvähem testitud. Võinuks teha juba suvel.
  • 11. oktoober sai MCU joodetud. Paar päeva hiljem tuli välja, et driverite osa on vigane. Elektroonika varem valmimist takistas roheliste plaatide tellimuse ootamine. Vankri liigutamine pidi toimuma juba kuu aega tagasi.
  • 20. oktoober Linuxsis progeda üle USB
  • 30. oktoober tulid mingid magnetanduri näidud USBst arvutisse
  • 2. november hakkasid magnetandurid tööle. Robotexini aega 1 kuu!!!
  • 8. november valmis peegel ja päev hiljem sõitis robot magnetandurite järgi täpselt. Meil oli alles täpne vanker, aga vaja oleks progeda juba käitumist väljakul.
  • 12.-18. november oli prose põlenud. 10 päeva hold-up ja hea et niigi hästi läks. Edaspidi varuosad peavad olema!
  • 24. november coili testimine robotil. Oleks võinud toimuda septembri lõpus/oktoobri alguses, kui ootasime alles seljaaju plaati.
  • 29. november sai peegel õige kinnitusega paika
  • 4. detsember oli robotex. Alles päev enne sai coiliga lasta ja samal ajal juhtida robotit.

Vähem kui kuu aega oli aega mihkli pimesi kirjutatud kood peeglil realiseerida. 2 nädalat oli võimalik Mihkli koodi debugimise kõrvalt natukenegi roboti loogikat progeda. Nende asjadega jäime otsutavalt hiljapeale. Kui 11. oktoober - poolteist kuud enne robotexi joodame alles MCU peale rääkimata debugimisest, siis ei olegi vist väga reaalne valmis saada nii keerukate asjadega. Alguses püstitatud tähtajad saada vanker veerema septembri alguses tunduvad tagantjärgi väga vajalikud. Miskipärast tuli tookord neid tähtaeg alati seada 3 korda varasemaks jättes kolmandiku ajast varuks ja kolmandiku debugimiseks ja siis ei täitnud me neist ühtegi. Hindasime aega väga valesti.

Jääb mulje, et tõsine töö algas alles oktoobis. Novembri alguses tundus asi juba ulmeliselt graafikust maas. Tõesti oleks võinud suvel hakata tõsisemalt tööle.

Viited ja märkused

  1. Komposiit koosneb kolmest kihist: 1mm alumiinium, 2mm plastik ja 1mm alumiinium. Tegemist on päris tugeva aga kõvasti kergema materjaliga kui 4mm teras või alumiinium.
  2. Nurk telje ja tema kõrval oleva telje vahel on mõlemal pool 120 kraadi.
  3. Omniwheel.com nimetab neid küll transwheel'ideks, aga põhimõte on sama.
  4. Optimizing a solenoid for a Robocup kicker - Väga põhjalik uurimus. Hea eeskuju.
  5. python doc - pipes

Vaata ka

Personaalsed tööriistad
Navigeerimine
Käsitöö