Robokäden takaperinsuunnittelua

Pitkästä aikaa olen taas ihmetellyt robokäden ohjausta. Yksi iso ongelma on pitkään ollut vaikeudet sarjaporttikommunikoinnissa. Käytössä olevan palvelin-PC:n emolevyllä oleva sarjaportti osoittautui viime syksynä epäluotettavaksi, ja tilalle hommasin neljän sarjaportin USB-purkin. Se ratkaisi ongelmat robottikädeltä PC:n suuntaan yhteydessä, ja tekemäni Robot Operating System -integraatio alkoi suurinpiirtein toimia.

Tavallaan lähellä ollaan, mutta ei sitten kuitenkaan – yhä jokin kirjaimellisesti tökkii liikkeiden ohjauksessa. Robotin liikkeet ovat jotenkin nykiviä ROS:n kautta ajettuna. Debuggailun tuloksena päädyin siihen, että käskyjä robottilaitteen päässä vastaanottava koodi pyörii liian hitaasti. Tiedossa on, että C500-robottiohjaimessa on 100MHz:n 486-prosessori, joka ajaa jotain hyvin omaperäistä käyttistä joka vähän muistuttaa Unixia. Purkilla on myös kääntäjä RAPL-3 kielelle. Jo aiemmin olen yrittänyt purkaa käännettyjä ohjelmia, mutta en ole siinä onnistunut. Nyt erinäisillä testailuilla selvisi että esim. kertolasku on käännettynä ”19 F8 F8 F9” ja jakolasku ”1B F8 F8 F9”. Nuo eivät ole millään tavalla x86-käskykannan mukaisia, vaan ilmeisesti jonkinlaista tulkattavaa tavukoodia.

Mielenkiintoisesti suurin osa järjestelmän binääreistä, kuten /bin/cp ovat myös tavukoodilla tehtyjä. Lopulta huomasin /sbin/r3interp binäärin, joka nimen perusteella kuulosti tavukoodin tulkilta. Sille file sanoikin ”FreeBSD/i386 compact demand paged executable”. FreeBSD voisi tulla kyllä kyseeseen 1990-luvun lopussa tehdyssä laitteessa.

Kuitenkin laitteelta löytyvä /kernel binääri ei sisällä mitään mainintaa BSD:stä. Siinä on ylipäätänsä aika vähän stringsin löytämää tekstiä, mutta x86:n keskeytyksille löytyy mm. tekstit ”double fault exception (very bad)” ja ”invalid TSS exception”. Vertasin näitä FreeBSD:n koodiin 26 vuoden takaa, mutta FreeBSD:ssä ne ovat aina olleet muodossa double faultja ”invalid TSS fault”. Tältä pohjalta vaikuttaa ettei kyseessä ainakaan FreeBSD ole, vaikka binääriformaatti siltä vaikuttaakin.

Noh, ristikääntöympäristön virittäminen tuolle olisi luultavasti muutenkin aika työlästä, joten RAPL-3:lla mennään. Tein simppelin for-looppitestin, ja sain 174000 kierrosta sekunnissa, ja yhdessä kierroksessa on n. 6 käskyä. Eli n. 100 kellojaksoa per tavukoodin käsky.

Tähän mennessä olen käyttänyt ROS:n simple_message -protokollaa sarjaliikenteessä, mutta se vaatii jonkin verran konvertointia robottipurkin puolella. Laskin että nyt yhden paketin käsittelyyn menee n. 2000 tavukoodin käskyä, eli n. 2 millisekuntia. Tämä ei ole mitenkään kamalan hidasta kun itse paketin siirtämiseenkin sarjaväylän yli menee 5 millisekuntia.

Yksi mahdollinen syy tökkimiseen on se, että ROS:n simple_message ei lähetä seuraavaa pakettia ennen kuin edelliseen on saatu kuittaus, joka vie joitakin kymmeniä millisekunteja. Ottamalla tämän odotuksen pois liikkeet kyllä muuttuivat vähän tasaisemmiksi, mutta samalla alkoi taas olla ongelmia sarjaliikenteessä.

Ilmeisesti robottipurkin sarjaporttien vuonohjaus ei ole millään tasolla luotettava. Speksien perusteella raudassa on 16 tavun puskuri, ja vaikuttaisi että kernelissä on n. 1.7 kilotavun puskuri. Näistä huolimatta joskus aivan kesken kaiken tipahtaa tavu pois välistä, nyt siis PC->robo suunnassa:

Vuonohjausasetukset eivät muuta paljoakaan. Xon/Xoff aktivoituu kyllä ajoittain, mutta ei riitä estämään tavujen putoilua. RTS/CTS taas ei tunnu aktivoituvan lainkaan.

Täytyy vielä tarkemmin arvioida tuon tehokkuutta. Mahdollista on tehdä jokin oma protokolla, joka olisi mahdollisimman lähellä CROS:n natiiveja tietotyyppejä jotta datat voisi siirtää ilman kummempaa konvertointia robottiajurin puolelle. Täytynee tehdä myös jonkinlainen checksum & uudelleenlähetys siirtovirheiden varalle.

Höylän tuulettimen korjaus

Kesken oikohöyläyksen alkoi yhtäkkiä kuulumaan metallin kirskuntaa ja kolinaa. Ensimmäinen arvaus oli tietysti että yksi höylän teristä oli lähtenyt irti ja olisi nyt pilalla. Mutta ei kuitenkaan, terät olivat kaikki tukevasti paikallaan eikä välissä ollut mitään.

Seuraavaksi otettiin hihnakotelo auki, mutta sielläkään ei mikään ollut selvästi pielessä. Moottoria käsin pyörittämällä kuitenkin selvisi että ääni tulee sen takaosasta. Seuraavaksi siis moottori irti, ja paljastuikin että muovinen propelli oli lisääntynyt jakautumalla. Tässä höylässä on muutenkin ollut harvinaisen hauraita muoviosia, joissa kyllä lukee ”ABS” mutta käy epäilyttämään onko muottiin mennyt jotain jämämassaa tilalle.

Kaksi osaa sai helpoiten takaisin yhteen pikaliimalla, mutta pelkkä liimaus tuskin pitäisi jo hajonnutta osaa kasassa. Jyrsin CNC:llä polykarbonaatista levyn tukemaan sitä. Levyn keskireikä on sopivan kokoinen että se menee tuulettimen keskiön ympärille ja toivottavasti estää sitä halkeamasta uudelleen. Muovilevyn liimasin epoksilla kiinni tuulettimeen.

Ainakin koekäytöllä tuntui pysyvän kasassa. Antaa epoksin kovettua seuraavaan käyttökertaan saakka niin eiköhän tuo taas jonkin aikaa kestä.

Pula-ajan puutöitä

Vaikka kerhoillat onkin viraali-ilmiöiden vuoksi keskeytetty, voi kotiarkeen hakea vaihtelua avainjäsenyydellä. Tai ainakin teoriassa – pääsiäisviikonloppuna olin hacklabin oven edessä lautakuorma auton katolla, kun kortinlukija antoi pelkkää punaista valoa. Hetken päästä Milla sattui kävelemään ohi, ja tiesi kertoa että kaikilla oli sama ongelma, kun talossa oli tehty yleisten tilojen pääsyoikeuksiin joitakin muutoksia.

Onneksi Joel ja Jarno olivat muutamaa viikkoa aiemmin ahkeroineet etäohjauksen kerhon lukoille käyttöön. Pikainen puhelu Joelille, mitä seurasi oletettavasti pari riviä näpyttelyä SSH:lla kerhon palvelimelle ja ovi naksahti auki. Mainiota!

Puutyölauantai pääsi alkamaan. Tällä kertaa tarpeen oli rakentaa parvekkeelle säilytyslaatikot ja auringonottotuoli. Materiaaleiksi hain Starkista parikymmentä metriä valmiiksi höylättyä kuusilautaa, paneelia sekä pöytälevyt laatikoiden päälle.

Suunnitelman ja mitat olin hahmotellut kotona valmiiksi, vaikka hieman niitä matkan varrella tulikin vielä säädettyä.

Lautojen pätkiminen kävi katkaisusahalla nopeasti. Hieman joutui säätämään että pisimmät laudat mahtuivat puutyötilaan, mutta sopivasti vinossa ja tuolia lisätukena käyttäen tämä onnistui.

Tuolin istumalaudat on ruuvattu alta päin kiinni rimoihin, jotka puolestaan ovat sivulaudoissa kiinni. Ostin Biltemasta purkilliset sopivan pituisia ruuveja jotta ei tarvinnut miettiä että ruuvit menisivät vahingossa läpi asti.

Istumaosan alla on kalustepyörät, jotka ovat ohuemmassa puurimassa kiinni – tällä tavalla ne lukittuvat kun tuolin päällä on painoa joka painaa sivulaudat lattiaa vasten. Lisäksi selkänojassa on lovet jotka sopivat laatikoston reunaa vasten, ja joiden avulla kaltevuuden voi valita.

Puuosat tulivat päivässä valmiiksi, mutta sopivia maalaussäitä sai vielä odotella. Nyt paria viikkoa myöhemmin kokonaisuus on valmis ja aurinkokin on jo ajoittain näyttäytynyt. Pehmusteiden virkaa on toistaiseksi toimittanut lampaantalja ja tyyny.

Jyrsinkara robokäteen

Toimiakseen CNC-jyrsimenä, robokäsi tarvitsee jyrsinkaran eli terää pyörittävän moottorin kouraansa. Tässä on mielenkiintoinen tasapainottelu monen tekijän välillä:

  • Liian painava kara ylikuormittaisi robottikäden. Maksimipaino on 3 kg, mutta jo se luultavasti heikentää tarkkuutta painovoiman vääntäessä rakenteita.
  • Heikkotehoinen moottori pakottaa jyrsimään hyvin ohuissa kerroksissa, moninkertaistaen jyrsintöihin kuluvan ajan. Tehoa olisi hyvä olla vähintään muutama sata wattia.
  • Fyysisesti liian iso moottori rajoittaa pääsyä ahtaisiin rakoihin.
  • Liian pieni kierrosluku estää käyttämästä pieniä teriä. Esimerkiksi piirilevyjen jyrsintään 0.3mm terillä olisi hyvä saada kierroksia vähintään 20kRPM.
  • Liian pieni vääntömomentti estää käyttämästä isoja teriä, joilla saa nopeammin isoja upotuksia leikattua. Esimerkiksi 3mm terälle alumiinissa riittää 0.02 Nm, mutta 6mm terällä optimi olisi jo 0.3 Nm.
  • Ilmajäähdytteiset moottorit ovat äänekkäitä ja ylikuumenevat herkästi.
  • Liian pienet laakerit eivät siedä jyrsinnässä tulevia kuormia, vaan kuluvat ennenaikaisesti ja vaativat usein vaihtamista.

Onneksi nykyään on saatavilla laaja valikoima harjattomia DC-moottoreita eli BLDC-moottoreita. Ne ovat teknisesti kolmivaihemoottoreita, joissa käämit pysyvät paikallaan ja joko käämien sisällä tai ympärillä pyörii kestomagneetti. Edistyneemmillä ohjausmenetelmillä kuten FOC saavutetaan hyvä vääntö laajalla kierroslukualueella, eli moottorin nopeutta voi pudottaa ohjelmallisesti ilman että vääntö pienenee. Tämä on usein tarpeen muoveja jyrsittäessä, ne kun tuppaavat sulamaan liian isolla kierrosnopeudella.

BLDC-moottoreita ajetaan nopeudensäätimellä eli ESC:llä. ESC:ssä on yleensä kuusi fettiä, joilla se pätkii eri käämeihin meneviä jännitteitä sopivan magneettikentän saavuttamiseksi. Samalla se toimii hakkurimuuntimena jännitteelle, eli esimerkiksi 48V/10A syötöstä saadaan moottorille vaikkapa 12V/40A. Suoraan 40A syötön kuljettamiseen tarvittaisiin paksut johdot virtalähteeltä asti, mutta ESC:n kanssa paksut johtimet tarvitaan vain muutaman sentin matkalle piirilevyltä moottorille.

Olen jo muutaman vuoden ajan käyttänyt omissa sähköpyörävirityksissä avoimen lähdekoodin VESC-nopeussäädintä, jossa on FOC-ohjaus. Se jaksaa ajaa satojen wattien tehoa, ja enimmillään 50 ampeerin jatkuvaa virtaa. eBaysta löytyy hieman jatkokehitettyjä FS-ESC malleja, jotka käyttävät samaa softaa. VESC:iä voi ohjata suoraan sarjaporttikomennoilla, ja vaikuttaisi että ROS:lle löytyy pari valmistakin kommunikointitoteutusta.

BLDC-moottorien spekseissä olennaisimmat parametrit ovat KV-luku ja käämien resistanssi. KV-luku tarkoittaa RPM/volt -suhdetta, eli esimerkiksi KV=1580 moottori pyörisi 10 voltin jännitteellä 15 800 kierrosta minuutissa. Tämä on maksiminopeus, nopeussäädin voi pyörittää moottoria hitaamminkin. Käämien resistanssi puolestaan määrää paljonko hukkalämpöä milläkin virralla syntyy. Esimerkiksi 0.08 ohmin käämeissä 40 ampeerin virralla syntyy 32 W lämpöä. Maksimivirta määräytyy hukkatehon ja jäähdytyskapasiteetin mukaan. Spekseissä olevat maksimivirrat vaihtelevat villisti, koska esim. RC-autossa jäähdytys on paljon vähäisempi kuin lentävässä tuulettimessa.

Moottorien spekseissä ei yleensä kerrota juuri mitään vääntömomentista. Sen voi kuitenkin johtaa KV-luvusta, ja tuloksena on T = 8 * I / KV, missä T on vääntö Newton-metreissä ja I on virta ampeereissa. Esimerkkimoottorilla 40 ampeerin virralla saataisiin siis 0.20 Nm vääntö.

Jyrsinnässä on kaksi kriittistä parametria: kierrosluku ja syöttönopeus, eli englanniksi speed ja feed. Nämä määräävät kuinka paksun siivun materiaalia terän reuna aina kerrallaan vuolee, ja kuinka nopeasti tämä reuna liikkuu. Optimaaliset arvot riippuvat materiaalista, ja niitä voi laskea esim. FSWizard-laskurilla. Erinomaista on, mikäli CNC-jyrsin toimii hyvin laajalla nopeusalueella jotta joka tilanteessa löytyy hyvä vaihtoehto. Käytännössä mekaniikan jäykkyys ja karamoottorin teho rajoittavat tätä, ja vaativat kompromisseja myös leikkuusyvyyden kanssa. Robokädessä on hyvin mahdollisuuksia isoihinkin syöttönopeuksiin, mutta jäykkyys ei ole niin hyvä kuin jyrsimeksi suunnitellussa laitteessa.

Isoissa jyrsinkoneissa karan laakerointi on hyvinkin massiivinen, koska leikkuuvoimat kasvavat niin isoiksi. Kun meidän robokätemme ei jaksa yli 30 Newtonin voimia muutenkaan, riittävät karalle aika pienetkin laakerit. Helpointa on hyödyntää suoraan moottorin laakereita. Ne ovat varsin hyvät sivusuuntaisille voimille, mutta akselin suuntaiset ”porausvoimat” lisäävät kulumista. Jyrsinterätkään eivät kuitenkaan leikkaa poraussuunnassa kovin hyvin, joten suurin osa työstöstä tehdään sivusuunnassa jos mahdollista.

Moottorin akselin laakeroinnin lisäksi on tärkeää, että jyrsinterä on tarkasti keskellä ja tukevasti kiinni akselin päässä. Usein tähän käytetään ER-sarjan monitahoisia istukoita, jotka hoitavatkin homman erinomaisesti. Harmillisesti sarjan pieninkin ER11-istukka on halkaisijaltaan 20 mm, mikä on aika massiivinen 3 mm jyrsinterään verrattuna ja tulee jyrsiessä ajoittain tielle. eBaysta saa myös Dremel-tyylisiä kolmileukaisia istukoita, jotka muistuttavat minikokoista porakoneen istukkaa. Päätin että tämä on kokeilemisen arvoinen, vaikka epäilyttääkin mahtaako se pitää terää riittävän hyvin.

Ei ole selvää mihin asentoon moottori kannattaa asentaa robottikäteen. Intuitio sanoisi, ettei sitä kannata laittaa osoittamaan suoraan eteenpäin kiinnityslevystä, koska tällöin rannemoottorin pyörityksellä ei olisi mitään merkitystä. Toisaalta jos moottori osoittaisi 90 asteen kulmassa sivulle, tulisi ranteen mekaniikka varsin lähelle jyrsittävää kappaletta ja voisi olla tiellä. Päädyin siihen että paras lienee laittaa se jotenkin vinoon.

Alustavaksi mekaniikaksi jyrsin omalla CNC3020-jyrsimelläni alumiinista palikan, jossa moottori on 15 asteen kulmassa. Tämä oli isoin kulma johon sain sen soviteltua niin, että palikan robokäteen kiinnittävät neljä kuusiokoloruuvia nurkissa ovat vielä avattavissa ilman koko homman purkamista.

Tarkoitus on laittaa vesijäähdytysputki kulkemaan alumiinipalikan läpi parista reiästä, jolloin se samalla jäähdyttää myös palikan kylkeen pultattavan nopeussäätimen. Myös moottorin yläosan ympäri voisi kiertää muutaman kierroksen ohutta kupariputkea. Tuohon sitten eBay-special istukka kiinni ja eikun kokeilemaan.

Tässä on niin paljon arvailujen varassa, että päätin lähteä liikkeelle halvemman pään moottorilla ja muilla osilla. Sitten kun näistä on kokemusta kertynyt ja tietää ongelmakohdat, voi päivittää tarpeelliset osat jykevämpiin.

ROS-integraatio robokädelle

Robokädestä ei ole paljonkaan hyötyä, ellei sitä voi ohjata järkevästi. Robotin omat RAPL-3 kieli sekä robcomm3-ohjaussovellus tuntuvat ehkä hieman.. vanhahtavilta. Eikä niille oikein ole suoraan tukea missään nykyaikaisessa sovelluksessa, joskin kaupallinen robodk luultavasti melko pienellä vaivalla tuottaisi myös RAPL-3-ohjauskoodia.


Kuvassa robcomm3.

Sen sijaan päädyin avoimen lähdekoodin Robot Operating Systemiin. Siinä on jo valmiiksi laaja tuki robokäsien ohjaukselle ja liikepolkujen suunnittelulle. Koska labin CRS F3 on mekaanisesti sama kuin Kuka Roboticsin alkuperäinen KR3-malli, löytyi suoraan Kukan sivuilta 3D-malli robokädestä. Tätä piti vähän pyöritellä FreeCADilla ja Blenderillä jotta sen sai sopivaan muotoon ROS:lle. Lisäksi piti tehdä URDF-muotoinen speksi siitä mitkä ovat tarkat etäisyydet ja kääntökulmat eri akseleille. Nämä muutokset on pistetty pull-requestina ros-industrial projektille, joten ehkä niistä on aikanaan hyötyä myös muille tätä robottia käyttäville.

Omalla koneella 3D-malli toimikin jo mainiosti, mutta robokäden koneella robotti oli pahaenteisesti räjähtänyt jo simulaatiossa:

Pienen googlettelun jälkeen selvisi että kyse on ROS:n bugista, jossa URDF-tiedostoa luetaan vahingossa käyttäjän LC_NUMERIC-localella. Robokäden Ubuntu oli oletuksena laittanut täksi fi_FI.UTF-8, vaikka kieli muuten onkin englanti. No, tuohan on täysin käyttökelvoton locale muutenkin kun joka paikkaan tulee pilkkuja desimaalipisteiden sijaan, ja tuo pilkkuvirhe rikkoi myös URDF:n luvun ja räjäytti 3D-mallin. Locale kuntoon ja jo näytti paremmalta.

Robotin ja ROS:n välille tarvitaan kaksisuuntainen kommunikaatio: ROS antaa liikekäskyjä robotille (joint trajectory action), ja robotti lähettää jatkuvasti sen hetkistä tilaansa (robot state reporting) takaisin ROS:lle. Turvallisempi ja helpompi on lähteä ensin toteuttamaan tuota robot state reporting -puolta, koska tällöin käsi ei ainakaan lähde lapasesta.

Aluksi lähdin toteuttamaan tätä rosserial-protokollan pohjalta, jolla voi lähetellä suoraan sarjaportin yli ROS:n rosmsg-viestiformaatissa olevaa dataa. Tämä tuli toteutettua RAPL-3:lla ja koodia kertyi n. 400 riviä. No, jotain pientä ongelmaa siinä oli mutta suunnilleen toimi.

Sitten satuin kuitenkin huomaamaan, että ROS:ssa on myös erityisesti robottikäsille tarkoitettu simple_message-protokolla. Nimensä mukaisesti se on huomattavasti simppelimpi toteuttaa, ja vie vähemmän tiedonsiirtokapasiteettiakin sarjaportista. Sen toteutus kävikin parilla sadalla rivillä.

Nyt ROS näkee robotin tilan ja liikkeet:

Jotain pientä ongelmaa kuitenkin vielä on. Sarjaporttiliikenteessä robokädeltä PC:lle päin tippuu joskus tavuja pois välistä. Tämä siitä huolimatta, että periaatteessa käytössä on RTS/CTS kättely. Ja yllättävää myös siltä kannalta, ettei PC:llä pitäisi olla mitään ongelmia käsitellä 11 kilotavua dataa sekunnissa, lähetti robokäsi sitä kuinka nopeasti tahansa.

Testailun myötä vaikuttaisi että nollamodeemikaapeli on kytketty oikein ja rts/cts menevät päästä päähän ja ristiin. Sen sijaan robokäsi jättää ne tyytyväisenä huomioimatta, sarjaporttiin pystyy kirjoittamaan vaikka CTS:n laittaisi 9 voltin paristolla jatkuvasti blokkaavaan tilaan.

Ilmeisesti robokäden CROS-käyttiksessä ei jollain tavalla toimi blokkaavat kirjoitukset sarjaporttiin. Sama ongelma on avasi portin O_NONBLOCK tilassa tai synkronisena. Noh, pahimmassa tapauksessa täytyy vain tehdä jokin purkka että koodissa mdelay():lla odotellaan sopivasti että puskuri ei täyty liikaa.