Kahdessa edellisessä osassa kerroin robottiauton tarinan tähän asti. Tällä kertaa leikittelen ideoilla sen tulevaisuuden suhteen.
Autokaupoille
Wild Thumper 4WD
Kenellekään testiajovideota katsoneelle ei varmasti jäänyt epäselväksi, että nykyinen alusta on todella hidas. Juurikin tuosta hitaudesta johtuen jouduin lisäämään kompassin, mitä kenties muuten ei olisi tarvittu. Tahdon ehdottomasti nopeamman alustan niin pian kuin se on mahdollista. Bongasin houkuttelevan kandidaatin Robomaan sivuilta, mutta liki 300 euron hinta on opiskelijalle liian suolainen. Youtube-videot nelivetomallin kuusipyöräisen isoveljen prototyypin koeajosta kuitenkin vakuuttivat kirjoittajan perinpohjaisesti. Toivotaan, että ensi kesänä pääsen sen verran hyväpalkkaisiin hommiin, että Wild Thumperiin on varaa. Suosittelen lämpimästi katsomaan alla olevan videon, mistä kyseisen robottialustan suorituskyky käy selväksi.
Samalla kun siirryn servoista DC-moottoreihin, myös ajologiikan voi pistää kokonaan uusiksi. Tilakone on varmasti parempi tapa toteuttaa tällainen projekti, sillä nyt suurin osa ajasta vietetään servoja odotellessa. DC-moottorien kanssa tarvitsee vain muuttaa ohjauspulssin leveyttä ja siirtyä koodissa eteenpäin siten vapauttaen resursseja muuhun toimintaan. Miinuksena voidaan pitää sitä, että DC-moottoreita varten tarvitsee robottiin lisätä erilliset moottorinohjauspiirit, joista neljän vetävän moottorin tapauksessa koituu kymmenien eurojen lisäkustannukset uuden auton hinnan päälle.
Kontrollifriikki
Projektin ollessa alkuvaiheessa keskustelin sen toteuttamisesta erään ystäväni kanssa. Hänen kommenttinsa kuului kutakuinkin "Eihän tuossa ole mitään hauskaa, jos et voi Google Mapsista klikata koordinaatteja ja käskeä autoa ajamaan sinne." Hän oli oikeassa. Vielä silloin ajattelin automaattisesti miniläppäriä robotin ohjausvälineenä, mutta sittemmin olen päättänyt toteuttaa sen kännykällä. Nykyisissä Android-puhelimissa kun on Google Maps ja minulla on hieman jopa kokemusta ohjelmien kirjoittamisesta Androidille. Siksipä tilasin Seeed Studiosta edullisen Bluetooth-moduulin, millä aion yhdistää kännykän robottiin. Valitettavasti moduuli ei taida ehtiä perille ennen kun lähden vanhempien luokse viettelemään joulun pyhiä. Minulla on jo tosin yksi projekti varattuna joulun ajaksi, mutta siitä kuulette myöhemmin.
Bluetooth Bee, XBee-kantaans sopiva Bluetooth-moduuli.
Kun kerran robottiin asennetaan kaksisuuntaiseen tietoliikenteeseen kykenevä radiolaite, niin tietenkin hakkerin mielikuvitus alkaa laukkaamaan. Miten vaikeaa olisi pistää robotti lähettämään videokuvaa puhelimeen? Alla video kaupallisesta neliroottorisesta helikopterilelusta, mitä ohjataan Iphonella samalla kun laite lähettää suoraa videokuvaa toisella kahdesta videokamerasta. Ehkä uskomattominta kopterissa on sille messuilla lupailtu 200 dollarin jälleenmyyntihinta.
Standardin 2.0 mukaisen laitteen pitäisi pystyä käytännössä jopa 250kB/s siirtonopeuksiin, joten kyllä siinä pitäisi teoriassa pitäisi ehtiä lähettämään useampiakin kuvia sekunnissa.
Sensoroitu
Melko alkuvaiheessa aloin pohtimaan, josko autoon voisi implementoida jonkunlaista esteiden väistämistä. Suoraan ajeleva robotti kun on hieman tylsä. Ensimmäisenä tietenkin aloin miettimään etäisyysantureita. Niitä voisi laittaa autoon kiinteänä asennuksena kolme, tai vaihtoehtoisesti yhden servon nokkaan skannaamaan ympäristöä. Tilasin koulun piikkiin pari infrapunalla toimivaa 30-150 cm alueen etäisyyssensoria, mutta en ole vielä keksinyt siistiä tapaa kiinnittää niitä kunnolla autoon. Ehkä koulun uusi 3d-tulostin (juttu tulossa myöhemmin) voisi auttaa asiaa.
Toki konenäön voi toteuttaa muullakin tavalla, varsinkin jos laskentateho ei ole ongelma. Viime viikkojen hitiksi hakkereiden piirissä noussut Microsoftin Kinect oli mielestäni oikein hauska idea, joskin mikro-ohjainten resurssien ulottumattomissa.
Kiitän lukijoita mielenkiinnosta tätä juttusarjaa kohtaan. Erityisesti kiitän Lauri Jämsää, joka oli nostanut tarinointini Ruuvipenkin etusivulle. Jos teillä on jotain kysyttävää tai kommentoitavaa, niin voitte tehdä sen Ruuvipenkin foorumista löytyvässä ketjussa tai blogin kommenteissa. Etenkin ideat auton kehittämiseksi ovat tervetulleita. Auton kehityksestä aion jatkossakin raportoida täällä blogissa sitä mukaa, kun edistystä tapahtuu.
Edellisessä osassa kerroin GPS-robottiautoprojektin rautapuolesta. Tällä kertaa käsitellään softaa ja sen kirjoittamisen aikana vastaan tulleita haasteita.
Missä mennään?
Päätin aloittaa projektin yhdistämällä Garminin GPS-vastaanottimen Arduinoon. Garminin mukana tuli perinteinen DE-9-sarjaliikennekaapeli, joten arvelin sen liittämisen olevan helppoa. Yllättävksi ongelmaksi osoittautui pinnijärjestyksen selvittäminen, mistä ei tuntunut löytyvän minkäänlaista yhteisymmärrystä googlauksen perusteella. Ainoastaan maapinni tuntui olevan kaikilla suunnilleen samassa paikassa. Koululla oli varastossa DE-9-liittimen vastakappaleita, joten otin sellaisen ja päätin selvittää oikeat pinnit kokeilemalla. Noin puolen tunnin askartelun jälkeen sain luettua sarjaliikennedataa Arduinoon.
Datan lukeminen luotettavasti olikin sitten eri juttu. Minulla meni pitkään kirjoittaa sellainen sarjaliikenteenlukualgoritmi, mikä ei yli- tai alivuotaisi jossain vaiheessa.
Seuraavaksi oli vuorossa datan parsiminen. Otin jälleen googlen kauniiseen käteen ja aloin selvittämään olemassa olevia implementaatioita Arduinolle. Pian selvisi, että alan de facto on NMEA, mutta siinä oli kuitenkin minun sovelluksen kannalta useita ongelmia.
useita viestilauseita parsittavaksi, 8-13 laitteesta riippuen
lauseet sisältävät päällekkäistä dataa
eri laitteet lähettävät eri lausekokoelmaa
saadakseni kaiken haluamani tiedon minun pitäisi parsia ainakin kolmea eri lausetta
lauseiden pituus vaihtelee datan sisällön mukaan
Vaihtoehdoksi NMEA:lle löysin Garminin oman Text Out -moodin. Vaikka tuntui arveluttavalta tehdä parseri tietyn valmistajan omalle viestimuodolle, mikä välttämättä ei olisi siirrettävissä laitteesta toiseen, niin Garminin Text Outin edut olivat kiistattomat. Ensinnäkin lauseita oli vain yksi ja se alkaa @-merkillä, mikä teki lauseen alun etsimisestä helppoa ja tuo yksi lause sisälsi kaiken tarvitsemani tiedon. Toiseksi lauseet olivat taatusti aina 52 merkkiä pitkiä, mikä sekin helpotti niiden lukemista. Kolmanneksi data päivittyi kerran sekunnissa, toisin kuin NMEA mikä päivittyi vain kahden sekunnin välein. Jos saisin nopean auton, niin tällä voisi olla merkitystä.
Parserin kirjoittaminen tämän jälkeen oli melko suoraviivainen homma, joskin yhteen mielenkiintoiseen ongelmaan törmäsin matkalla. Päätin tallentaa luokan sisällä koordinaatit long-tyyppiseen muuttujaan muotoon (d)ddmmmmm siten, että kolme viimeistä numeroa ovat minuuttien desimaaliosa.
Huomaa rivillä viisi, miten luku 10000 pitää pakottaa long-tyyppiseksi. Muuten jos siinä indeksissä oleva numero on suurempi kuin kolme, niin tapahtyy int-muuttujan ylivuoto ja koorinaatit menevät sekaisin. Tämän kanssa jouduin painiskelemaan hyvän tovin ennen kun se löytyi. Debuggeriahan ei Arduino IDE:n mukana tule.
Ollaanko perillä jo?
Maapallo (taiteilijan näkemys)
Koordinaattien välisten etäisyyksien laskeminen osoittautui mielenkiintoiseksi ongelmaksi. Kuvaa katsomalla helposti ymmärtää, että vaikka leveyspiirit ovat melko lailla saman mittaisia sijainnista riippumatta, niin pituuspiirien pituus vaihelee suuresti riippuen siitä miten kaukana päiväntasaajasta ollaan. Wikipedia on omistanut kokonaisen artikkelin erilaisten algoritmien esittelemiseen ongelman ratkaisemiseksi. Ne ovat kuitenkin mikroprosessoreilla melko raskaita, eivätkä silti kovin tarkkoja. Pohdin ongelmaa ääneen jollain Arduino-aiheisella IRC-kanavalla ja sain mielenkiintoisen kommentin. Muistista vapaasti suomentamalla sen sisältö oli suunnilleen "Tässä taas nähdään ero fyysikon ja insinöörin välillä. Fyysikko yrittää tehdä yhden lauseen, millä voisi ratkaista ongelman koko maapallon tapauksessa ja mielivaltaisilla etäisyyksillä, kun insinööri vain yksinkertaisesti laskee pituuspiirin pituuden määränpään läheisyydessä ja laskee siitä Pythagoraan lauseen avulla. Se on tarpeeksi tarkka, jos etäisyys ei ole suuri.".
Kommentoija osui naulan kantaan. Olinhan entinen fysiikan opiskelija ja vasta aloittanut opiskelemaan insinööritieteitä ja siksi ajattelumallini oli todellakin väärä. Vastauksen ei tarvitse olla yleispätevä eikä pedantti, kunhan se toimii sovelluksen tapauksessa riittävän hyvin. Wikipediasta löytyi yksinkertainen kaava pituuspiirin mitan laskemiseksi ja sen jälkeen etäisyyden laskeminenkin muuttui peruskoulumatematiikaksi.
Minne nenä näyttää?
Nyt robottini tiesi missä se on ja milloin se on perillä. Seuraavaksi pitäisi tietää mihin suuntaan pitää kääntyä, että oltaisiin menossa oikeaan suuntaan. Tämä oli ehkä koko projektin haastavin probleema. Aluksi olin ajatellut laskea nopeuden GPS:n antamasta datasta. Sen mukana tuli kaksi nopeuskomponenttia desimetrin sekuntivauhdin tarkkuudella. Siitä trigonometriaa soveltamalla saisi helposti suunnan laskettua. Teoriassa. Osoittautui, että robottiautoalustani ei ollut nopeimmasta päästä. Sen nopeus on vain pari senttiä sekunnissa, joten GPS:n antaman nopeuden erottelutarkkuus ei riittänyt suunnan laskemiseen. Seuraavaksi päätin laskea suunnan auton liikkuessa koordinaattien muutoksesta. GPS-paikkatiedon kohina oli kuitenkin aivan liian suuri ja mittavien tutkimusten jälkeen tulin siihen tulokseen, että luotettavan suutatiedon saamiseksi robotin olisi pitänyt ajaa aina samaan suuntaan minuuttitolkulla kerrallaan. En olisi halunnut hankkia erillistä kompassimodulia, koska se lisäisi koko auton kompleksisuutta sekä rauta- että softapuolella, muuta näytti siltä, että vaihtoehdot olivat vähissä.
Hitachi HM55B -kompassimoduli
Tilasin koulun piikkiin Hitachin HM55B-kompassimodulin ja aloin etsimään sille ajuria. Käyttäjä nimeltä kiilo oli julkaissut Arduino-saitilla artikkelin kyseisen modulin käyttämisestä Arduinon kanssa, joten otin hänen koodinsa oman ajurini pohjaksi. Pian selvisi, että kompassin kohina oli jotain aivan käsittämätöntä. Välillä mittasin jopa 60° heittoja sen antamassa signaalissa kun robotti oli paikallaaan pöydällä. En ymmärtänyt ihan täysin kiilon kirjoittamaa koodia, joten vian etsiminen oli melko epätoivoista. Toisaalta muut käyttäjät kertoivat saaneensa omansa toimimaan samalla koodilla modulin kalibroinnin jälkeen. Kalibointi vaati kuitenkin Windowsin käyttämistä, joten en harkinnut sitä vakavissani. Turhauduin kuukausiksi kompassin epäluotettavuuden vuoksi. Palasin aina tauon jälkeen tuoreilla silmillä tarkastelemaan koodia ja etsimään vikaa. Huomasin, että kompassin koodi toimi erillisenä ohjelmana melko hyvin, mutta yhdistettynä auton koodiin se meni sekaisin. Lopulta tulin siihen tulokseen, että kyse on pakko olla jostain ajoituksista. Turhautuneena päätin vain alkaa mukiloimaan auton ja kompassin koodia muuttelemalla viiveitä kunnes kompassi alkaisi toimia. Hämmästyksekseni metodi toimi. Sitten aloin poistamaan tekemiäni muutoksia yksi kerrallaan selvittääkseni, mikä oli se maaginen rivi, mikä sen korjasi. Lopulta olin mielestäni poistanut kaikki muutokset, mutta kompassi toimi silti! Edessä oli koeajo.
Tätä juttua varten päätin siistiä ja julkaista kaiken autoon kirjoittamani koodin. Se on nyt kaikkien ihailtavissa Gitorious-repossani.
Keväällä 2009 aloin suunnittelemaan GPS-robottiautoa harrastusprojektiksi. Tavoitteena oli saada aikaiseksi auto, mikä osaa ajaa annettuja koordinaatteja kohti ja päätellä milloin se on perillä.
Rautakaupoille
Ensimmäisenä piti tietenkin tehdä hieman tutkimustyötä ja selvitää optimaalista rautapolitiikkaa. Vaikka koulu oli lupautunut maksamaan opiskelijoiden harrasteprojektien viulut, silti halusin pitää kulut mahdollisimman pieninä. Mikrokontrolleriperheen valinta ei ollut vaikeaa. Suurena avoimen lähdekoodin kannattajana olin lukenut Arduino-projektista ja se oli Linux-käyttäjälle itsestään selvä valinta. Arduino tarjoaa Linux-käyttäjille kokonaisen IDE:n ja sen voi ohjelmoida tavallisella USB-kaapelilla ostamatta erillistä ohjelmointilaitetta. Arduino IDE pohjimmiltaan käyttää avr-gcc-kääntäjää ja avrdude-ohjelmaa ohjelmien polttamiseksi mikro-ohjaimeen. Periaatteessa Arduino käyttää omaa C:n kaltaista ohjelmointikieltään. Se on kuitenkin aika kevyt rakennelma, joka on rakennettu avr-gcc:n päälle ja se koostuu lähinnä määritellyistä vakioista sekä esikääntäjästä, mikä muuttaa käyttäjän koodin C:ksi avr-gcc:tä varten. Avr-gcc tukee myös C++:aa, mikä mahdollistaa omien olioiden käyttämisen ulkoisten kirjastojen muodossa.
GPS-vastaanottimen valinta ei ollut yhtä helppoa. Koululla oli varastossa jonkun valmistajan GPS-moduleita, mutta ne eivät osanneet keskustella suoraan Arduinon rauta-UART:in kanssa, joten hylkäsin ne pienen testailun jälkeen. Lopulta päädyin käyttämään geokätköilyyn hankkimaani Garminin eTrex Legend -vastaanotinta. Sen mukana tuli sarjaliikennekaapeli, minkä arvelin saavani keskustelemaan kohtuullisen helposti Arduinon kanssa.
Kanadalaisen vedättäjäfirman MaxSerial.
Erityisominaisuutena väärin päin nimetyt RX- ja TX-pinnit.
Arvelin leikkiväni Arduinolla enemmänkin vapaa-aikanani, joten päätin tilata sellaisen omaan laskuuni. Pitkällisten googlaustuntien jälkeen päädyin tilaamaan kanadalaisesta verkkokaupasta DE-9-liittimellä varsutetun Arduino MaxSerial -mallin. Kun lankku saapui postilaatikkoon, huomasin harmistuksekseni, että liitin oli samanmerkkinen kuin Garminin sarhaporttikaapelissa. Kaiken lisäksi lankun ohjelmointi sarjaväylän kautta lakkasi toimimasta noin kahden tunnin leikkimisen jälkeen. Kanadalainen nimeltä mainitsematon verkkokauppa ei ottanut vastuuta laitteen kätkytkuolemasta, vaan jätti ensimmäisen tiedusteluni jälkeen sujuvasti vastaamatta muihin viesteihini. Tätä juttua varten kävin katsastamassa kaupan sivut ja näyttäisi siltä, että huono asiakaspalvelu on kostautunut ja kauppa on onneksi lopettanut toimintansa viime vappuna. Sain kuitenkin puhallettua MaxSerialiin eloa käyttämällä koulusta lainattua ISP-ohjelmoijaa ja AVR Studiota Windows XP -virtuaalikoneessa, mutta sillä tavalla työskenteleminen osoittautui liian vaivalloiseksi. Tilasin pari viikkoa myöhemmin Kiinasta Duemilanoven, mikä on palvellut minua uskollisesti siitä lähtien.
Budget Robotics Rigel 4WD
Viimeisenä oli jäljellä robottiautoalustan valitseminen. Pian kävi selväksi, että autot ovat sen verran hintavia, että opiskelijabudjetilla sellaista ei saa hommattua. En myöskään halunnut tuhlata ylettömästi rakkaan opinahjoni varoja, koska koin sen tuovan ylimääräisiä onnistumispaineita jos projektiin on jouduttu sijoittamaan satoja euroja. Edullisia robottiautoalustoja on toki viljalti, mutta projektini luonteesta johtuen tarvitsin sellaisen, mikä selviäisi myös ulkona. Sisätiloissa kun tuo GPS-signaali on kovin heikko. Lopulta valinta osui kalifornialaisen Budget Roboticsin Rigel. Sen etuihin lukeutuivat huokean hinnan lisäksi houkkutelevalta kuulostava neljän servon vetosysteemi. Servot sopivat projektiini mainiosti, sillä ne eliminoivat erillisen moottorinohjauspiirin tarpeen ja tekisivät kokonaiskytkennästä yksinkertaisemman.
Myöhemmin selviävistä syistä jouduin hankkimaan myös kompassimodulin. Ainoa edullinen vaihtoehdo oli Hitachin HM55B, joka sekin oli niin hintava, että tilautin sen koulun piikkiin.
Tähän väliin laitetaan pari suttuista kännykkäkamerakuvaa robotin tämänhetkisestä kokoonpanosta.
Seuraavalla kerralla kerron robottiauton koodaamiseen liittyvistä haasteista.
