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 fault” ja ”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.