Lemppaan tähän nyt vaan pikaisesti IRCistä asiaa, muokkailen joskus fiksummaksi.
10:17 <rambo_> Helsingin joukkueeseen saa osallistua
10:17 <rambo_> roborungon lisäksi dumppasin pinon omia sensoreita, moottoriohjaimia jne laatikkoon jossa lukee HSF urpobotti
10:20 <Negatiivi> robotti hommat vois olla hauskoja jos ois joku perusosaaminen ja paljon ideoita :)
10:21 <Mokki> tarviiko ideat ja peruosaaminen olla samal jäbäl?
10:22 <Negatiivi> joo jos kyseessä on yhden ihmisen projektiryhmä ja ei jos projektiryhmän koko >1
10:23 <rambo_> laatikossa on lisäksi yksi pandaboardi koska there's no overkill
10:23 <rambo_> pikaplani on seuraava: yksi ardu hoitaa moottoriohjausta ja IMU:n (3D gyro ja 3D kiihtyvyysanturi) lukua, käytännössä korkeampi taso kertoo sille mihin suuntaan ja miten kovaa
10:24 <rambo_> sitten meillä on toinen ardu jossa kiinni 5 ultraäänianturia
10:24 <rambo_> ja kolmannella voidaan vilkuttaa LEDejä (koska separation of duties)
10:25 <Negatiivi> onks ledien vilkuttelu irrelevant feature jonka tarkoitus on vain viihdyttää katselijoita?
10:25 <rambo_> Panda on se korkeampi taso
10:27 <rambo_> ja moottoriohjausardu siis huolehtii anturoinnillaa siitä että suunta on oikea vaikka moottorit pyöris eri tahtia tai renkaat luistais
10:27 <rambo_> no siis koska mokista ei kuitenkaan voi voittaa nopeusluokassa niin pitää yrittää pärjätä arnolle kauneimman robotin kisassa
10:28 <rambo_> siksi hienoja valoja
10:28 <rambo_> laatikossa on myös yksi pixy mikäli haluaa leikkiä jotain konenäköjuttua
10:28 <rambo_> ja kyllähän pandassa pyörii OpenCVkin
10:28 <Negatiivi> :)
10:32 <rambo_> viikonloppuna on kursseja mutta vois ehkä koittaa saada aikaiseksi jotain workshoppeja sen robon tienoilta
10:33 <rambo_> Kirkkonummi on tietty aina vaihtoehto mutta ehkä vähän kaukana (siellä tosin voi yöpyä, saunoa ja kaljoitella roboilun ohessa)
10:34 <rambo_> melkolailla ekana pitäis saada aikaiseksi käyttökelpoinen harjoitusrata: https://dl.dropboxusercontent.com/u/66566045/roborally/rata.png (kremmenillä tais olla joku suunnitelma miten rakentaa semmoinen jonka saa helposti kokoon ja kasaan varastointia varten)
10:35 <Negatiivi> mites kestävä noiden seinien pitää olla vai riittääks pahvihökötys?
10:37 <Stoneman> vhs bokseista ;)
10:37 <rambo_> no softabugit voi tarkoittaa että robo painelee täysiä seinää päin
10:37 <rambo_> renkaiden pito on kyllä aika huono joten ihan kauheaa vahinkoda tuskin saa aikaan
10:38 <Stoneman> jotai vaneria
10:38 <Stoneman> eikös tollasen vanerista + liimasta sais askarreltua
10:40 <rambo_> sais, se vaan pitäis saada pieneen tilaan säilytystä varten kans
10:42 <Stoneman> no ei välttämättä tarvii liimaa jos kaivertaa kolot muille palasille
Bottia on kasaitu hiukan, se “coasteri” joka oli paketissa oli huono lähtökohtaisetikin ja nyt kun asensin moottorit “väärin päin” (because reasons…) niin se coasteripyörä on täysin käyttökelvoton, voidaan arpoa toinen coasteri tai tehdä self-balancing botti, IMU löytyy https://www.pololu.com/product/1265 sille on jopa valmis AHRS kirjasto https://github.com/pololu/minimu-9-ahrs-arduino.
Pandaboard on mallia A2 ja menee automaattisesti läbin WLANiin (tai mihin vain avoimeen WLANiiin), Avahi pyörii joten botti vastaa nimellä urpobotti.local siellä pyörii ssh ja “urpokerho” käyttäjän salasana on läbin WLANin passphrasen ensimmäinen sana. Muista ajaa siisti shutdown ennen kuin otat pandalta virrat pois (mikäli tilanne on akuutti [moottori tulessa tjsp] niin älyä toki saa käyttää).
Arduja on useampi, se jonka päällä on moottorinohjainshieldi huolehtikoon tosiaan moottoreista ja niihin lisättyjen enkooderien outputin kannattaa tuoda tälle ardulle suoraan. AHRS:sta en ole varma kannattaako ajaa tällä vai toisella (joka huolehtii ainakin Ultraääni-antureista).
Tähän projektiin siis saa todella mielellään tulla mukaan vaikka ei olisikaan suuri robottiguru (kuten ylläolevasta IRCcilokistakin näkyy). Joku taiteellisempikin hahmo olis kovasti tervetullu niin saatais robosta kauniskin (vaikka esim pandaboardin valtava koko asettaa rajoja muotoilulle).
Edit: Ainiin, Pixy:n firmware on kanssa päivitetty uusimpaan.
10:32 <•mokis> https://drive.google.com/file/d/0B1r-PL1nuu5LVnFOZVdlYkVVX3c/view
10:32 <jammi> roborata.jpg - Google Drive
10:32 <•mokis> tolta näyttää tuleva kilparata
10:32 <•mokis> Seinät on noin 21cm korkeat ja sisänurkissa on kulmaraudat, muuten alkuperäisten speksien mukaiset
10:32 <•mokis> *mukainen
10:33 <•mokis> tarkempia mittoja saa pyydettäessä
Jotain on rakennettu ja koodailtu, ehkäpä IMU/AHRS kannattaisi tehdä sittenkin ihan Pandan puolella, https://github.com/richards-tech/RTIMULib helpottanee sen kanssa (tosin Panda on 1.8V IO joten level-shifteri tarvitaan, koitan muistaa tuoda kotoa, ei ollut oikeaa chippiä mukana). Edit: shifterilauta on repussa, se että jaksanko tänään (keskiviikkona) kiertää läbi kautta on vielä auki.
NewPing toimii ihan kohtalaisesti, testailin sitä imurirobottiprojektissa. Tehtiin robotteja varten sitten kuitenkin erillinen piirilevy, johon saa kiinni 1…4 HC-SR04-anturia. Kortilla on SiLabsin F805, joka pingaa anturit itsenäisesti halutulla tahdilla ja tekee haluttaessa 5 samplen mediaanisuodatuksen kullekin. Valmiit etäisyydet cm:nä voi lukea I2C:llä rekistereistä (kortti toimii I2C-slavena). Tuotakin korttia voi käyttää, jos siitä on apua, niitä on ainakin 4 kpl kalustettuna. Samalla kortilla on kolmen langanseurantakelan vaatima analogiaelektroniikka, mutta eipä tuo haitanne.
Ultraäänianturit nyt hoidossa newpingillä toisella ardulla, koitin siirtää IMU:n pandaan mutta RTIMULib (kun sain sen ensin käännettyä) ei löydä laitosta (muutama hetki meni kanssa pohtiessa miten sen I2C väylän saa näkymään devicenä), voi olla että puuttuvat pull-up:it on ongelma, pitää katsoa skoopilla tarkemmin.
Panda on nyt kiinni koko urpobotin 5V railissa joten USB:sta ei kannata nyt koittaa poweroida mitään ardua ennen kuin irrottaa sen railista, laita virta mieluummin pandaan.
Moottoriohjaus sarjaportin yli on teoriassa olemassa mutta PID-silmukan tuunausarvot on aivan hukassa.
RTIMULibiin on tehty oma forkki tuon vanhan IMU-laudan tuen lisäämistä varten, HUOM tätä voi edistää etänäkin ihan hyvin, vaatii lähinnä datalehtien lukua jotta saa laitteiden ja rekisterien osoitteet kohdilleen. pull-up:it eivät olleet ongelma, kuten alta näkee bitti kulkee:
Lisäksi varmistin juuri äsken että Arduinoon kytkettynä tuo lauta yhä toimii joten en myöskään onnistunut kärventämään sitä missään välissä.
Tietty jos sinulta löytyy varastoistasi jo valmiiksi tuettu lauta, tai joku muu Python-bindingseillä varustettu IMU-kirjasto joka tukee ko lautaa niin molemmat kelpaa vaihtoehtoina.
Viisaampien kuten @kremmen kanssa juteltua tulimme lopputulokseen että niin harvalla pulssilla kuin mitä noista enkoodereista tulee ei ole juuri toivoa saada PID-säätöä joten palasin siihen että sarjaportin käskyistä asetetaan suoraan se mitä moottorinohjaimelle menee. Sarjaporttiin kyllä raportoidaan yhä nähdyt pulssit joista Panda voi sitten laskea jotain jos haluaa. Moottorinohjausardu on nyt kiinni suoraan portissa /dev/ttyO3 (eli UART4).
Ultranääni-ardua varten pitäisi löytää joku sopivan lötkö lyhyt kiinalainen mini-USB johto (UARTeja ei ole tarjolla nyt enempää, paitsi boottikonsoli ja se on RS232 tasoissa ja muutenkin tarpeen). Sitten pitäisi tehdä joku python kilke joka vähän suodattaa niitä tuloksia (tuntuvat olevan aika vaihtelevia, ja nollat [ei vastausta, ainakaan ajoissa] ainakin pitää hylkää) ja sitten raportoi ne edelleen jotta voidaan tehdä päätöksiä.
Tein supersimppelin Python kilkkeen jonka läpi voi ZQM:lla käskeä moottorinohjainardua.
@jssmk koitti saada BT:n yli yhteyden gamepadiin, mutta tämä ei onnistunut vaikka “Wireless controller” saatiin kyllä näkyviin skannauksessa (tämä siksi että hätätilanteessa laitetaan kamera kyytiin ja teleoperoidaan). Jos BT:tä ei saada toimimaan niin yllämainittua ZMQ interfacea voi käyttää WLANin yli ja ajetaan läppärillä jotain ohjelmaa joka tulkkaa gamepadia ja käskyttää bottia.
IMU (ao kuvassa oikealla, osittain pandan alla) on samassa vaiheessa kuin eilenkin ja tulee varmasti olemaankin jollei joku muu ™ tee asialle jotain koska itse tulen keskittymään siihen että bottia voi edes ajaa käsiohjauksella jos (kun) kaikki muu failaa (riittävän häxi kameraratkaisu löytyy jo)
Edit: Ainiin, se 3S LiPo akku on tyhjähkö, saa ladata laatikosta löytyvällä laturilla (joka ottaa esim 12V sisään) jos osaa käyttää balansoivaa akkulaturia. Ja muistetaan kytkeä se akkuvahti akkuun aina ennen kuin kytketään akku bottiin.
Pulssianturit näyttää olevan pyörän akselilla, jolloin pyörimisnopeuden PID-säädöstä ei tosiaan tule mitään. Tuo on siitä viheliäinen vaihteisto, että pulssianturia ei saa järjellisesti moottorin akselille, jonne se kuuluisi. (Tässä yksi syy, miksi kritisoin sitä, että pyörät ja moottorit oli lyöty lukkoon kisan säännöissä.)
Tuon tyyppisessä käytössä pyörimisnopeuden PID-säätö ei ole kylläkään välttämätön. Koska alusta on tasainen, pyörän voi olettaa pyörivän riittävän hyvin asetusarvon mukaisella nopeudella. Uusia asetusarvoja tulee joka tapauksessa antureilta koko ajan.
Olen joskus tehnyt viivanseurausta PID-periaatteella. SP on kiinteä (“pyri keskelle viivaa”), PV on “miten hyvin ollaan keskellä viivaa” ja CV on moottorien nopeusero. Tämän saattaisi saada toimimaan samalla periaatteella (“miten hyvin ollaan keskellä käytävää”). Jyrkät mutkat voivat kyllä olla ongelmallisia, viivassa kun oli määritelty minimi kaarevuussäde, tässä se on periaatteessa 0.
Noiden ultraääniantureiden suodatukseen mediaanisuodatus on aika toimiva, niiden tyyppiongelma on juuri tuo, että tulee sekaan isosti poikkeavia yksittäisiä mittaustuloksia. Myös nollatulokset lähtee tällä. Imurirobotissa käytin 5 samplen liukuvaa mediaania, joka on kevyt laskea ja suodattaa kokemuksen mukaan riittävän hyvin.
Tiistaihäslinissä ei saatu juuri mitään aikaiseksi, mitä nyt löysin muutaman rikkinäisen ATX-virtalähteen läbin virtalähdehyllystä. Kolmas kokeiltu toimi (kahdesta ensimmäisestä toinen oli aivan kuollut [please, vain testattuja ATX:iä läbin varastoon, testaamattomat romukiertoon] ja toinen toimi mutta flekti oli jumissa joten saimme haistella iloista sähkön tuoksua kun se ylikuumeni…) ja sillä oli hyvä latailla robotin akkua.
@guttula lupasi katsoa RTIMULibiä ja kuka vaan voisi katsoa vaikka katsoa tätä https://pypi.python.org/pypi/hidapi/ tai jotain muuta helpohkoa tapaa hanskaa HID laitteita Pythonilla, erityisesti OSX:sää mutta Linux kelpaa myös.
Saatan olla tänään menossa läbille edistämään asioita, jos jaksan. Ilmoittelen IRCissä. kun aika lähestyy.
Bluetooth saatu erinäisten taisteluiden jälkeen toimimaan, koitan jaksaa joskus HSF:n jälkeen kirjoittaa pätkän siitä miten se onnistuu. Tällä kilkkeellä saatiin myös DS4 toimimaan hienosti (tosin se pitää käyttää aina pairing-moden kautta koska bluetoothd ei tykkää jostain) ja oikeat akselien tunnisteetkin löytyivät.
Tässä on vaan sellainen ongelma että jos käyttää BT;tä railakkaasti (kuten DS4 käyttää kun se raportoi kiihtyvyysanturien ja gyrojen asentoja) niin se jossain vaiheessa tappaa wifi-puolen siitä pandan wifi+bt chipsetistä (ja ennen sitä jo aiheuttaa tahmaamista wifiin). Joten voi olla että tarttee arpoa joku USB BT dongle jotta tältä vältyttäisiin.
Pololun moottoriohjain oli liian fiksu ja rupesi valittamaan että toinen moottorimme on rikki (ehkä se ei ole elämänsä kunnossa mutta kyllä se vielä toimii), joten @chadez vaihtoi tilalle kitin “virallisen” ohjaimen.
Löytämäni random halpis-btnäppiksen mukana tullut BT-dongle ei palvellut DS4:n kanssa (vaikka muuten kyllä toimi melkolailla heittämällä Pandan kernelissä), pitänee kokeilla toista vaihtoehtoa jossa otetaan wifi-dongle verkkoa varten ja sitten BT saa tehdä pahuuksia sisäänrakennetulle wifille. Kuvittelin että minulla olisi ollut dongle mukana (koska joskus hankin niitä pinon juuri yllättävien tarpeiden varalle) mutta näköjään ei… Pitää siis tuoda kotoa.
Ultraääni-ardu kettuili jotain Pandan kanssa, vaihdoin tilalle toisen ja tein simppelin sarjaporttiparserin joten nyt sekä moottorien pulssianturit että ultraäänet raportoidaan ZMQ publish-kanavilla, moottorien ohjaus RPC-kutsuilla toimikin jo. Kun saisi sekä WiFin että BT:n toimimaan yhtäaikaa luotettavasti niin olisi jo toimiva fallback mikäli (tässä vaiheessa vahvasti kun) robottiin ei saada älyä.
RTIMULibin suhteen asiat kai edistyy ainakin @guttula kyseli IRCissä detaileja joihin koitin vastailla.
@temmi_hoo:n sairastuminen on aiheuttanut ikävän setbackin testiradan suhteen, voi olla että testejä päästään suorittamaan vasta tampereella, mutta se nyt on perinteikästä…
Kauneuskilpailussa pärjäämistä ei kukaan ole ehtinyt edes ajatella (tai jos joku onkin niin mitään konkreettisia toimia asian eteen ei ole tehnyt)
Yoda tulostettiin sattumalta kun tuli valintavirhe SD-kortin valikossa, mutta ehkä siitä saisi keulakoristeen…
Viikonloppuna jokatapauksessa homma jatkuu, ehkä huomennakin (tai sitten ei, voisin vaikka pitää yhden illan lomaa tästä projektista)
RTIMULib edistyy ihan hyvää vauhtia. Matalimman (rekisteri) tason osuus ajurista pitäis olla valmis testattavaksi, mutta varmaan joutuu odottelemaan että saan vielä korkeemman tason integraatioita tehtyä. Jotain perusasetuksia ja auto-detectiä vielä pitää lisätä ennenkun toimii ilman kikkailuja.
Jos joku voi ja haluaa niin vois buildaa ja testaa RTIMUCal testiohjelmaa botilla ja raportoida mitä virheitä esiintyy. Koodi kääntyy ja sen voi suorittaa mutta kun mulla ei ole IMU levyä niin en voi testata. Olis kiva tietää seruaavaa:
-Löytyykö I2C laite
-Tuleeko mitään dataa
-Onko datassa mitään järkeä
@guttula:n RTIMULib muutokset toimivat ja nyt meillä on ZMQ PUB kanava jolla tulee yaw,pitch ja roll. @dist teki macille DS4:sta HIDin kautta lukevan kilkkeen joka WLANin yli käskyttää ZMQ:lla moottoriohjaimia, lisäksi hänellä on työn alla sensoridatan visualisointipalikka ja jonkinsortin autonominen ajoäly.
Allekirjoittanut on puuhastelly Pixyn kanssa, libpixyusb:n kääntäminen pandalla vaati hiukan kikkailua mutta kyllä se ainakin pääosin toimii, jostain syystä Color Code tyyppisiä tunnisteita ei saada USB:n yli pandalla. Normaalit tunnisteet toimivat mutta pitäisi keksiä miten ihmeessä python bindingseillä olis tarkoitus lukea useampi signature, voi olla helpompi mennä C++:lla ja tunkea taas ZMQ PUBlishilla datat kaikkien kiinnostuneiden nähtäville.
Tänään tuli “hiukan” setbackkiä kun onnistuin rikkomaan kernelin (lisäksi käyttämämme muistikortti on rikki, kiva 3.5M/s luku ja 2M/s kirjoitus “Class 10” kortilla), no eikun mounttaamaan eri linuxissa kortti ja taistella oleelliset kansiot talteen, sitten (reilun viikon vanhasta) backupista image uudelle kortille (@dist:iltä jostain löytyny class 6 mutta se ainakin pääsi luvattuihin nopeuksiin)
Jokatapauksessa saimme RTIMULib-kuviot testattua ja @guttula rupesi lisäämään kompassineulaa ja attitude-visualisointia @dist:in sensorivisupalikkaan. Lisäksi kääntelin kokeeksi libpixyusb:n myös uudemmassa Linuxissa (ja x86:lla), sama color-code ongelma jatkui ja sitten kun menin pixyn foorumeilta kaivelemaan niin kävi ilmi että kyseessä on tunnettu bugi kahden viikon takaa (toivottavasti korjaavat pian…). Olis tietty ihan kiva jos ne foorumipostaukset tulis Googlella vastaan kun hakee aihetta mutta ilmeisesti Redmine ei vaan osaa.
Lisäksi nyt on tukipyörä edessä ettei nokka kynnä maata, taaksekin olis samanlainen mutta sitten ei enää ajopyörät yllä kunnolla Joten sahailin @heikkki:n PTFE (aka Teflon) tangosta sopivan palan, hyvin liukuu ainakin läbin maalatulla betonilla. Tiistaina hän varmaan sorvailee meille paremman ratkaisun.
Ulkonäköseikat ovat yhä täysin kakkossijalla koska varsinaisessa toiminnallisuudessakin on ollut ihan riittävästi puuhaa, mutta jos sinä olet koet olevasi kykenemätön koodaamaan itse ohjauspuolta niin korimuotoilijan paikka on yhä auki.
@dist ja @guttula ovat säätäneet IMU:n kanssa tänään, jäi hiukan auki mihin pisteeseen sen kanssa päästiin. Itse havaitsin että libpixyusb:n bugin (kts yllä) korjaus oli ilmestynyt githubiin ja käännettyäni uuden version iloisesti sain ColorCode -tietoja USB:n yli, sitten tein C++ palikan joka viskoo havaitut signaturet ZMQ:n yli kaikille kiinnostuneille ja Pythonilla esimerkin siitä miten ko dataa voi kuunnella. Arvot on Block-structin järjestyksessä, hexaksi koodattuna, paitsi CC:n osalta angle joka on desimaalilukuna. Erityisesti signaturesta on syytä CC:n kanssa syytä huomioida että se näyttäisi olevan bitfieldi. En ole ihan varma miksi structissa se on uint16_t sillä ainakin Pixymon:in kautta voi opettaa vain 7 eri väriä (ja rajansa kameran erottelukyvylläkin vaihtelevassa valaistuksessa).
Akulla pandan ajamisessa on nyt jokin ongelma, ehkä buck-hakkurimme on suuttunut siitä että ulkopuolelta on tuotu siihen jännitettä, usein jopa siten että hakkurin inputissa ei ole ollut mitään, tai sitten siitä vain loppuu teho. Laitoin varikkolaatikkoon isomman hakkurin mutta en juuri nyt muista onko se buck-boost vai boost, asia kannattaa selvittää kokeellisesti labravirtalähteen ja yleismittarin kanssa, ja tämän kanssa voisi melkein laittaa ylimääräisen tukevan diodin outputtiin (ja säätää jännite siten että se on diodin jälkeen 5V).
Lisäksi siltä varalta että pixyn kuvadataa ei saada streamattua verkon yli lykkäsin yhden analogikameran ja lähettimen sekä vastaanottimen varikkolaatikkoon. Ko kamera tosin haluaa aika kovan jännitteen joten sitä varten saattaa olla tarve siirtyä 3S akkuun (jota on ehkä syytä testata vielä tuon hakkuriongelmankin suhteen, koska tiedän että sitä pandaa on voinut ajaa ko hakkurilla ainakin 3S akusta, vaikka ei sen kyllä akun virranantokyvystä pitäisi olla kiinni).
Ajattelin, että voisin miettiä urpobotin ulkonäköä, kun en muuten ole osallistunut sen rakentamiseen.
Ensimmäinen ajatus oli dalek, mutta se tuntui liian työläältä. Etenkin, jos sen pitäisi sanoa “EX-TER-MI-NATE!” valoefektien kanssa.
MSE-6 Mouse Droid on suhteellisen yksinkertainen tehdä.
Ajattelin, että yksinkertaista olisi vain laittaa robotti kantamaan urpokerhon standaaria. Siitä luonnollisena jatkona oli ajatus ritarin kypärästä, erityisesti mustan ritarin:
Totesin, että se mitä ehdin ja osaan tehdä on neuloa jotain, joten lopputuloksena tästä pohdinnasta syntyi urpokerhon viiri:
Tosin eilen neuloessani sain ajatuksen, että joku ajoneuvokin voisi toimia. Autoista ja ledeistä tuli heti mieleen Ecto-1, joten ehkä vien tänään 3D-referenssin labille: (Tämä on netistä kaivettu random-kuva, ei 3D-referenssi.)
Nyt on yksien taikasavujen poiston jälkeen toimiva tuplaregusetti ja pandakin jaksaa boottaa pelkällä akulla.
Mainitun taikasavu-episodin vuoksi ei jäänyt aikaa minkäänsortin koodaamiseen tai tuunaamiseen joten B-suunnitelmalla varmaan päädytään loppujenlopuksi kisaamaan.
Voitto! Teleoperoitu Urpobotti (hienoisista verkko-ongelmista huolimatta) oli nopein botti HSF15:ssa.
Ohessa näkyy hiukan telemetrian visualisointia ja rakeinen analoginen videolinkki. @anacron:illa on ehkä vähän enemmän ja parempaa materiaalia itse kisasta.
Joten sahailin 
(Tämä on netistä kaivettu random-kuva, ei 3D-referenssi.)
