Robotino XT. Hovedprosjekt i Informasjonsteknologi. Høgskolen i Oslo og Akershus. Prosjektgruppe 37. Lars Øyvind Hagland Ole Andreas Røsok

Transkript

1 Robotino XT Hovedprosjekt i Informasjonsteknologi Høgskolen i Oslo og Akershus Prosjektgruppe 37 Lars Øyvind Hagland Ole Andreas Røsok

2 Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo Telefon: Telefaks: HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL Robotino XT PROSJEKT NR. TILGJENGELIGHET Tilgjengelig DATO ANTALL SIDER / BILAG PROSJEKTDELTAKERE Lars Øyvind Hagland, s Ole Andreas Røsok, s INTERN VEILEDER Alfred Bratterud OPPDRAGSGIVER HIOA KONTAKTPERSON Alfred Bratterud SAMMENDRAG Prosjekt utført på Robotino XT, en Robot fra Festo. Inneholder dokumentasjon av Robotino, C++-rammeverket Brain for å forenkle kontrollen av Robotino, samt applikasjonen Fetch som demonstrerer rammeverket. 3 STIKKORD Robotino XT C++ Robot

3 Forord Dette er prosjektrapporten til Robotino XT, som er et hovedprosjekt ved Høgskolen i Oslo og Akershus våren Formålet med oppgaven har vært å dokumentere Robotino og utvikle rammeverket Brain, som forenkler videre utvikling av applikasjoner for Robotino. Vår generasjon opplever en rivende utvikling. På nittitallet var en mobiltelefon som fikk plass i lommen imponerende. I dag har de fleste mobiltelefoner datakraft som overgår nittitallets datamaskiner. Ny teknologi krever mer kraft - og sofistikert teknologi. Det er forskjell på å styre vaskeprogrammet i en vaskemaskin og analysere bilskiltene på forbipasserende biler. Robotino er utstyrt med et tradisjonelt pc-operativsystem og kan kontrolleres via et API skrevet i C++. Det betyr at vi, som informasjonsteknologistudenter, kan skrive et system som kontrollerer roboten i en kontekst av en omfattende infrastruktur og med tilnærmet ubegrensede systemressurser. Med et kovensjonellt programmeringsspråk er det enkelt å koble Robotino f.eks til en Kinect, eller til en tjeneste på internett.

4 Innholdsoversikt Del 1 Prosess Del 2 Rapport Del 2.1 Robotino Del 2.2 Kinect Del 2.3 Brain Del 2.4 Fetch

5 Prosessrapport Prosess Side 1 av 27

6 Prosessrapport Innholdsfortegnelse 1 Innledning Involverte parter Oppdragsgiver Veileder Prosjektgruppen Mål og krav Kravspesifikasjon Beskrivelse Ordliste Krav/forutsetninger Elementer Funksjonsbeskrivelser Kinect Kommunikasjon Data Robotino Ordforklaring Formål Planlegging og arbeidsmetode Styringsdokumenter Prosjektlogg Fremdriftsplan Ukesrapporter Risikoplan Kravspesifikasjon Verktøy Git Google Docs Symphonical Utviklingsmetode Om Scrum Scrum i prosjektet Faser Utviklingsprosessen POC - Proof of Concept Generellt om POC POC Mål Teknisk løsning POC Mål POC Mål POC Mål...13 Side 2 av 27

7 Prosessrapport 3.2 Faser Fase 0 - Oppstartfase Hovedpunkter Robotino Vurderinger Infrastruktur Dokumentasjon Ekstraturstyr Fase 1 - Testfase POC POC Kinect Fase 2 - Designfase Fase 3 - Utviklingsfase Måling av avvik under kjøring i forskjellige modi Fase 4 - Utviklingsfase Fase 5 - Dokumentasjonsfase Utfordringer under utviklingen Feil i RobotinoAPI Feil i Robotino Daemons Manglende dokumentasjon av NITE Kinect Begrenset dokumentasjon av RobotinoAPI Event- vs interrupt-basert Avvik på odometri og rekalibrering Deteksjon av tilkoblet utstyr C Oppsummering av prosjektet Erfaringer Robotino i samfunnet...24 Side 3 av 27

8 Prosessrapport 1 Innledning Prosjektet om Robotino XT er et prosjekt i tre deler: 1. Dokumentasjon av Robotino 2. Rammeverket Brain 3. Applikasjonen Fetch - en demonstrasjon av Brain. Robotino XT er en robot utviklet av Festo Didactics. Robotino XT kan kjøre i alle retinger og har en robotarm påmontert. I tillegg finnes et sett sensorer og akuatorer som kan anvendes til styring. Prosjektet om Robotino XT var et naturlig steg videre fra kurset Bionic Engineering der begge prosjektdeltakerene deltok semesteret før hovedprosjektet. Bionic Engineering omhandler bruk av prinsipper funnet i naturen i design og utvikling. Robotinos Compact Bionic Handling Assistant er et eksempel på biomimikk 1, da den i svært stor grad er inspirert av en elefantsnabel. Fingrene i kloen har sin inspirasjon fra en fiskehale, på den måten at den, når den møter motstand, vil bøye seg rundt og dermed gripe objektet den presses mot. Som en del av Bioinc Engineering-faget ble det gjennomført et prosjekt på Robotino XT, som ankom HIOA i oktober Disse erfaringene fra dette faget med videre i planleggingen av hovedprosjektet. 1.1 Involverte parter Oppdragsgiver Prosjektet er utført for Høgskolen i Oslo og Akershus innenfor det internasjonale samarbeidet Robotino XT Research Cooperation2, som er en organisasjon stiftet av Festo Didactics Veileder Veileder er høgskolelektor Alfred Bratterud ved Høgskolen i Oslo og Akershus. 1 Biomimikk (fritt utledet fra engelske biomimicry ), studien av modeller i naturen og bruk av disse for å løse tekniske problemer. 2 Side 4 av 27

9 Prosessrapport Prosjektgruppen Prosjektgruppen består av Lars Øyvind Hagland og Ole Andreas Røsok, begge avgangsstudenter ved Bachelorstudium i Informasjonsteknologi. 1.2 Mål og krav Roboter er tradisjonelt kontrollert av mikrokontrollere. Robotino XT er i midlertid kontrollert via et C++-basert API. Dette muliggjør styring ved hjelp av et fullverdig programmeringsspråk. Prosjektets mål er å i så stor grad som mulig utnytte de funksjonaliteter som ligger i Robotino. For å vise dette er det laget en kravspesifiksjon som inkluderer de fleste av Robotinos funksjoner Kravspesifikasjon Beskrivelse Følgende kravspesifiksjon definerer en funksjon, sammensatt av flere delfunksjoner, som Robotino skal utføre basert på inputdata og analyser. Robotino skal stå på et gitt punkt i rommet. En forsøksperson står også i rommet, og holder et objekt. Forsøkspersonen blir observert av Kinect, som rapporterer et punkt i rommet samsvarende med personens aktive hånd. Når forsøkspersonen senker hånden med objektet ned til bakkenivå skal Robotino kjøre bort til personen, motta og gripe objektet og deretter returnere til sitt opprinnelige startpunkt. Når Robotino er tilbake i sin utgangsposisjon skal forsøkspersonen igjen senke hånden mot bakkenivå og Robotino skal returnere gjenstanden til forsøkspersonen. Underveis i kjøringen for å hente eller levere objektet skal Robotino være i stand til å oppfatte om forsøkspersonen flytter seg. For å motvirke avvik i Robotinos odometri skal Robotino, hver gang Robotinos arm berøres av får problemer med odometrisk avvik, og derfor ikke klarer å navigere helt frem til forsøkspersonen skal forsøkspersonen, utføre en dynamisk rekalibrering av odometrien mot punktet fra Kinect tilsvarende forsøkspersonens hånd Ordliste 1. Robotino: Her menes Robotino XT inkludert kjøresystemet som kontrollerer denne 2. Objekt: En fysisk gjenstand som egner seg til formålet, f.eks en ball eller et brilleetui 3. Dynamisk rekalibrering: Kalibrering ved hjelp av en berøring av Robotino fra forsøkspersonens hånd som er tracket av Kinect Side 5 av 27

10 Prosessrapport 4. Kinect: Hardware som ved hjelp av kameraer kan tracke f.eks en hånds posisjon i rommet Krav/forutsetninger 1. Objektet må ikke være tyngre enn Robotino kan løfte (600 gram) 2. Objektet må ha en form som Robotino klarer å holde 3. Forsøkspersonen må befinne seg innenfor Kinect virkeområde 4. Robotinos utgangsposisjon må være gitt i forhold til Kinect Elementer 1. Robotino skal kunne 1. Kjøre i rommet 2. Bevege arm 3. Lukke arm ved deteksjon av objekt 2. Kinect skal kunne 1. Detektere forsøkspersons hånd 2. Levere koordinater, x,y,z for hånden. 3. Forsøksperson skal 1. Kunne kontrollere systemet ved hjelp av sin hånds posisjon detektert av Kinect 2. Bevege sin hånd mot bakkenivå for å trigge apporten 3. Legge objektet i Robotinos griper Funksjonsbeskrivelser (F = Funksjonellt krav) Kinect Kinect skal detektere og levere koordinatene til forsøkspersonens hånd. Koordinatene er grunnlaget for å kunne detektere forsøkspersonens posisjon samt fungere som en triggermekansisme for å starte apporten. Kinect sender koordinatene over til Robotino Kommunikasjon F1: Kinect starter en socket-tjeneste som Robotinos kontroll-server kobler seg til for å motta koordinater Data F2: Kinect leverer koordinater som 32-bits flyttall. F3: Rekkefølgen på koordinatene er X,Y, Z, hvor X er avstanden fra Kinect, Y er lengden til siden og Z er høyden. Koordinatene er relative til Kinects posisjon. F4: Koorindatene separeres med komma. Eksempel: ,0.0000, F5: Et koordinatsett sendes på en linje, og etterfølges av linjeskift \n. Eksempel: ,0.0000,0.0000\n F6: Standardiserte bevegelser registrert av Kinect sendes som tekst med etterfølgende linjeskift. Eksempel: Click\n. Side 6 av 27

11 Prosessrapport Robotino Robotino styres av en datamaskin via trådløst nettverk (wifi). Datmaskinen kobler seg opp til Kinect via en socket-klient og leser av koordinater. Koordinatene blir så analysert. F7: Når Z nærmer seg bakkenivå skal Robotino kjøre bort til forsøkspersonen. F8: Når Robotino er kommet frem skal den stanse med en avstand slik at Robotinos gripeklo er så nær forsøkspersonens hånd som mulig. F9: Robotino skal lukke gripperen når den detekterer at et objekt, basert på bevegelser i armen. F10: Robotino skal oppdatere sin posisjon basert på en rekalibrering som er en sideveis bebegelse av armen. F11: Robotino skal returnere til utgangsposisjonen. 1.3 Ordforklaring Liste over begreper og teknologier som benyttes i rapporten: Festo Didactics Festo er en stor aktør innen industriell automatisering med pneumatikk og elektroniske styresystemer. Openrobotino.org Er Festos online nettsted for Robotino. Her finnes en Wiki og diskusjonsforum, i tillegg til kildekode. API - Application Programming Interface Et API er et grensesnitt mot en tjeneste som lar utviklere benytte seg av funksjonalitetene i tjenesten. CBHA - Compact Bioinc Handling Assistant Er Robotino XTs arm. C++ 11 Programmeringsspråket koden er skrevet i. C++ er et rammeverk skrevet i C som tillater objektorientert utvikling. C++ 11 er den nyeste versjonen av C++. Denne tilbyr en ny måte å skrive multithreading på, som er benyttet i prosjektet. Perl Scriptspråk1 mye brukt i Unix-verdenen. Brukt i prosjektet til å skrive socketservere2 som er brukt under testing av kode. Bash 1 Et script er et program eller en serie kommandoer som i stedet for å forhåndskompileres til maskinkjørbare kode tolkes og kjøres direkte fra tekst. 2 En socket er en logisk nettverksforbindelse mellom to datamaskiner Side 7 av 27

12 Prosessrapport En kommando-tolker brukt som standard tekstbasert shell1 av de fleste Unix-lignende operativsystemer tilgjengelige i dag. Bash har funksjonalitet som også gjør det til et fullverdig scriptspråk. Odometri Posisjonering ved å kontinuerlig registrere bevegelse i drivverk. Pneumatikk Er utnyttelse av energi ved hjelp av komprimering og ekspandering av gasser2. Komprimering skjer ved å bruke en kompressor. Robotinos CBHA bruker pneumatikk med luft til bevegelse av armen. Scrum Rammeverk laget med henblikk på å utvikle komplekse informasjonssystemer3 uten å på forhånd måtte deltaljdefinere systemet. PLC - Programmable Locical Controller På norsk også kjent som PLS - Programmerbar Logisk Styring. Kjernepunktet i elektronikkinnstallasjoner. 1.4 Formål Målet med oppgaven er å gjennomgå Robotinos funksjonalitet, dokumentere denne og deretter utvikle et rammeverk, Brain, som gjør det enklere å utvikle applikasjoner som kontrollerer Robotino. 1. For utnytte få oversikt over funksjonaliteten i Robotino har prosjektgruppen gjennomgått og dokumentert de ulike delene av Robotino. 2. Prosjektgruppen har så utviklet rammeverket Brain, som forenkler programmering mot Robotino. 3. For å demonstrere Brain er applikasjonen Fetch utviklet basert på Brain. Det er også vår intensjon, og Høgskolen i Oslo og Akershus ønske, at fremtidige studentarbeider med Robotino vil ha nytte av dokumentasjonen og rammeverket. 1 Et shell gir en bruker av et operativsystem tilgang til opearativsystemets funksjonalitet og programmer Side 8 av 27

13 Prosessrapport 2 Planlegging og arbeidsmetode Planlegging er viktig i ethvert prosjekt. Her presenteres styringsdokumentene for prosjektet, samt en gjennomgang av prosjektverktøy og valg av utviklingsmetode. 2.1 Styringsdokumenter Prosjektlogg Prosjektgruppen har ført en prosjektlogg på daglig basis Fremdriftsplan Fremdriftsplanen er et overordnet styringsdokument som har blitt brukt for å beskrive de store linjene i prosjektet. På grunn av oppstartfasen med mye usikkerhet rundt Robotinos funksjonalitet ble fremdriftsplanen satt på hold frem til usikkerhetsmomentene ble avklart og kravspesifikasjonen ble skrevet Ukesrapporter Det foreligger ukesrapporter for våre ukentlige møter med veileder Risikoplan Risikoplanen definerer problemer som kan oppstå underveis, konsekvensene av disse, samt våre tiltak for å forhindre at en eller flere risiki skal skade prosjektets fremgang Kravspesifikasjon Kravspesifikasjonen definerer en oppgave Robotino skal løse. Kravspesifikasjonen er ment som en overordnet oppgave prosjektet skal løse for å vise bruken av rammeverket Brain. Punktene i kravspesifikasjonen ble trukket sammen til å utgjøre de fire Proof of Concepts gruppen har gjennomført. 2.2 Verktøy En oversikt over de verktøy og tjenester som har blitt benyttet i arbeidet med oppgaven Git Git er et kildekoderevisjonssytem, som brukes for å holde kontroll på kildekode Google Docs Google Docs er Googles producitivity suite for online redigering av dokumenter. Et viktig element med Google Docs er muligheten for å samarbeide i skrivingen Symphonical Symphonical.com tilbyr en tjeneste for organisering av samarbeid. Symphonical har blitt anvendt som en oppgavefordelingstjeneste hvor oppgaver blir opprettet som en virtuell post- Side 9 av 27

14 Prosessrapport it, som så fordeles på gruppemedlemmene, rangeres på viktighet og gis en dato for når den skal være utført. Figur 1, Symphonical.com notes 2.3 Utviklingsmetode Prosjektgruppen har tidligere arbeidet i prosjekter med utviklingsmetodikken Scrum, og blir også benyttet i dette prosjektet Om Scrum Scrum er en utviklingsmetodikk laget for smidig utvikling. Scrum1 baserer seg på at man deler arbeidet som skal gjennomføres opp i oppgaver, tasks, og gjennomfører iterasjoner, kjent som sprinter, hvor man løser en eller flere tasks. I Scrum er det flere roller: 1. Produkteieren eier visjonen og representerer interessentene. 2. Scrum-master er ansvarlig for utviklingsteamet og samkjører prosessen mellom utviklingsteamet og produkteieren. 3. Utviklingsteamet kan være tverrfaglig, og har som oppgave å løse de arbeidsoppgaver som foreligger i prosjektet. I større prosjekter er utviklingsteamet ofte tverrfaglig, og innehar den kompetansen som er nødvendig for å utvikle produktet. Det er også mulig å bytte ut medlemmer i teamet avhengig av hvilken kompetanse som trengs på de forskjellige stadier. Under en sprint holdes hver morgen den daglige scrum. Her gir alle medlemmer av prosjektet gi uttrykk for følgende tre forhold2: 1. Hva er gjort siden forrige scrum-møte? 2. Hva skal gjøres før neste møte? 3. Hva har (eventuellt) vært til hinder for at gruppemedlemmet var effektiv i implementasjonen av funksjonalitet? Disse møtene holdes ofte stående, og skal være ferdige iløpet av et kvarter Side 10 av 27

15 Prosessrapport Når en sprint er ferdig, holder teamet et møte hvor sprinten blir evaluert, dette kalles ofte for sprint-review, samt et tilbakeblikkmøte, kalt sprint retrospective Scrum i prosjektet Prosjektgruppen har hatt møte med veileder hver fredag, og referer til dette som sprintmøter. Under sprintmøtene har prosjektgruppen også gjenomgått den forrige sprinten. Her ble ukens arbeid evaluert, veileder har kommet med innspill og neste sprint har blitt planlagt. En sprint har tilsvart fem arbeidsdager. Grunnlaget for vår sprintplanlegging har ikke vært de tradisjonelle brukerhistoriene, men et utvalg funksjonalitet fra kravspesifikasjonen som ble satt sammen til en proof of concept. Oppgavene er delt inn inn i punkter og tildelt et gruppemedlem via Symphonical. Vektingen av hver enkelt oppgave er gjort basert på et forsiktig anslag av arbeidsmengden i antall kodelinjer, kombinert med kompleksiteten. En oppgave skal være så enkel at en eller begge gruppemedlemmer kan løse denne oppgaven innenfor en eller to arbeidsdager. Den daglige scrum har vært basert på den faste diskusjonsbolken gruppemedlemmene har kjørt hver morgen. Da prosjektmedlemmene ikke har noen kaffemaskin å stå foran ble et par lenestoler hentet fra gis bort på finn.no. Akseptansetesting er en viktig del av Scrum. Denne delen har vært gjennomført som en demonstrasjon av de ulike POCene, eventuellt delfunksjonalitet av disse. I den grad en demonstrasjon har vært visuell, har demonstrasjonen blitt filmet Faser Utviklingsprosessen er delt opp i faser, som representerer de forskjellige stadiene i prosjektet. Hver fase har en beskrivelse i tittel som illustrerer fasens hovedfokus. I fremdriftsplanen er fasene benyttet som milepæler. Fasenes lengde har blitt justert der det har vært nødvendig Fase 0 - Oppstartfase Fase 1 - Testfase Fase 2 - Designfase Fase 3 - Utviklingsfase Fase 4 - Utviklingsfase Fase 5 - Dokumentasjonsfase Side 11 av 27

16 Prosessrapport 3 Utviklingsprosessen 3.1 POC - Proof of Concept Generellt om POC Proof of concept, POC, er en demonstrasjon av et konsept hvor hensikten er å vise at et konseptet er gjennomførbart i praksis. Videoer av POCer er publiserti prosjektets innleveringsmappe, Våre proof of concept er basert på kravspesifikasjonen. En POC er en enkel implementasjon av en eller flere deler av kravspesifikasjonen. Prosjektgruppen fant det mest hensiktsmessig å dele kravspesifikasjonen opp i flere deler, hvor en eller flere deler blir løst i en POC. Etter at alle POCer er gjennomført blir alle løsningene reimplementert i den endelige løsningen, Brain. Der koden i en POC kan beskrives som en hack vil den samme koden bli vesentlig raffinert under reimplementasjonen i Brain. Generellt kan våre POCer anses som sekvensielle hardkodede enkeltstående løsninger. Under følger en oversikt over de POC-ene som er blitt laget POC Mål Vise at kontrolleren Kinect kan benyttes til å styre Robotinos arm på en slik måte at Robotino etterlikner bevegelsen til forsøkspersonen. Side 12 av 27

17 Prosessrapport Figur 2, Viser forsøkspersonens hånd med fire mulige bevegelsesretninger, samt Robotinos gripeklo sett forfra. Bevegelse i forsøkspersonens hånd overføres til gripekloen Teknisk løsning For å oppnå dette må koordinatene generert av Kinect leses av i et program som styrer Robotino. Programmet må konvertere koordinatene fra Kinect til en skala som passer RobotinoAPI POC Mål Vise at Robotinos arm kan reagere på direkte interaksjon. I dette tilfellet ved å gripe når armen presses ned av at et objekt plasseres i gripekloen. Kloen skal også slippe objektet når dette løftes opp. Side 13 av 27

18 Prosessrapport Figur 3, Viser Robotinos gripeklo, ved trykk ned går den til lukket posisjon, ved trykk opp går den tibake til åpen posisjon Teknisk løsning For å oppnå dette må programmet som styrer Robotino registrere endringer i armens potmetere og aksjonere når gitte tilstander opptrer. I dette tilfellet når armen skyves opp eller ned POC Mål Kunne kjøre til et oppgitt koordinat uten at ytterligere instruksjoner gis. Teknisk løsning Ved å kontinuerlig lese av Robotinos odometri kan de hastigheter på kjøring og retningsendring kalkuleres. Kontinuerlig oppdatering av hastigheter gjøres og hastigheten redusers automatisk når målpunktet nærmer seg, for å så stoppe når målet er nådd POC Mål Kombinere løsningene fra POC1, POC2 og POC3 på en slik måte at Robotino kan hente et objekt på et punkt, lest fra Kinect, og så returnere til sin startposisjon. Utførelsen skal aktiveres når forsøkspersonens hånd holdes nært gulvet. Side 14 av 27

19 Prosessrapport Figur 4, Viser forsøkspersonen som holder objekt nært bakkenivå. Dette utløser Robotino som kjører til punktet. Teknisk løsning Lese koordinater fra Kinect, for å deretter kjøre til den angitte posisjonen når høydekoordinatet fra Kinect er under 40 cm over gulvet. Her skal løsningen fra POC2 benyttes for å gripe objektet. Så skal Robotino returnere til startposisjon. På startposisjonen skal objektet legges ned. 3.2 Faser Fase 0 - Oppstartfase Hovedpunkter 1. Etablere dokumentasjon 2. Oppnå kommuikasjon og funksjonalitet med Robotino via RobotinoAPI2 3. Etablere lokaler og nødvendig infrastruktur Robotino HIOA mottok Robotino XT i oktober Det ble først gjort noen forsøk på å kontrollere roboten basert på den medfølgende instruksjonsmanualen, noe som ikke lyktes. Prosjektets første prioritet ble derfor å finne ut hvorfor den beskrevede kontrollmåten ikke fungerte, for å deretter endre konfigurasjonen på Robotino slik at denne kunne benyttes slik det i følge manualen er beskrevet. På nettsiden openrobotino.org er det publisert flere forskjellige disk images1 som kan leses over på det medfølgende Compact Flash-kortet. På denne måten kan operativsystemet som kjører på Robotino oppgraderes uten behov for å koble Robotino til internett. 1 Et disk image er en bit-for-bit 1-1 kopi av en hel disk, inkludert partisjonstabell og alle partisjoner. Side 15 av 27

20 Prosessrapport Per januar 2013 var følgende images tilgjengelige: 1. Robotino_CF_Image_V24_ dd.gz 2. Robotino_CF_Image_V24_ _4GB.dd.gz 3. Robotino_CF_Image_V24_ _4GB_gnome_desktop.dd.gz 4. RobotinoXT_CF_Image_V24_ _1GB Det ble derfor startet en gjennomgang av de forskjellige imagene. Da de forskjellige imagene hadde forskjellig eksempelkode, forskjellig versjon av API og forskjellig nettverksoppsett var det ikke mulig å gjøre eksakt samme testene på de forskjellige versjonene. Generellt ble fremgangsmåten følgende: 1. Lese imaget over på Compact Flash-kortet 2. Starte Robotino og undersøke oppsettet 3. Kompilere og kjøre egen testkode på Robotino 4. Kompilere og kjøre egen testkode fra ekstern laptop 5. Starte eventuelle lokalt ferdiginstallerte programmer laget i RobotinoView 6. Oppgradere API til siste versjon via apt-get på Robotino Med RobotinoXT_CF_Image_V24_ _1GB fungerte Robotinos arm under kjøringen av det medfølgende RobotinoView-programmet cbha_linux.rvw2. På dette imaget var siste versjon av OpenRobotinoAPI installert. Openrobotino.orgs wiki-side om C++1 anbefaler å benytte RobotinoAPI2 for nye prosjekter. Derfor ble Robotino forsøkt oppgradert, både via apt-get og deretter via kompilering av kildekode fra hentet fra openrobotino.org med versjonskontrollsystmet Subversion2. Gruppen forsøkte også å benytte programmet RobotinoView til å oppdatere Robotino. RobotinoView kan i tillegg til API og daemons oppgradere firmware 3. Det var ikke mulig å bruke armen i noen av tilfellene. Det ble derfor nødvendig å kontakte Festo, som basert på vår omfattende gjennomgang avdekket og fikset en feil, testet og slapp en ny versjon av RobotinoAPI2. Tilkobling til Robotino via RobotinoAPI2 fungerte uten feil etter at den siste versjonen av RobotinoAPI2 ble installert Vurderinger Prosjektgruppen besluttet dermed å gå videre med oppgaven, da det ikke lenger var noen problemer knyttet til kontroll av roboten. I et møte med veileder ble det så besluttet at oppgaven som skal løses er Fetch, nærmere beskrevet i kravspesifikasjonen Med firmware, et begrep som ligger mellom software og hardware, menes software som installeres direkte på og benyttes i styringen av et konkret hardware. 3 Side 16 av 27

21 Prosessrapport Infrastruktur Som en del av denne fasen satte prosjektgruppen opp vår infrastruktur, en kritisk komponent i for det videre arbeidet med Robotino. Basert på tidligere erfaring med operativsystemet Ubuntu ble det besluttet å kjøre serverene på dette systemet. Figur 5, Viser oversikt over infrastruktur Det ble satt opp følgende maskiner, hvorav to fysiske: Bionic Ble satt opp som DHCP-server og router internet til andre klienter. Kjører virtualbox og virtualiserer Robotroller og RobotinoSIM. Kjører i tillegg backup av git-repository. Bionic ble i tillegg sikret mot tilgang fra internet. Det er kun SSH med nøkkelbasert autentisering tilgjengelig. RobotinoSIM Virtuell Windows XP-maskin som kjører på Bionic. Maskinen kjører softwaren RobotinoSIM som brukes til å simulere Robotino for testing av kode. Side 17 av 27

22 Prosessrapport Robocontrol Virtuell Ubuntu server som brukes til å teste ut nye versjoner av RobotinoAPI2 før disse blir installert gruppemedlemmenes laptoper. Kinect Ubuntu desktop som kjører Kinect. Brukes også til utvikling. git.trekkspilltreff.no Amazon AWS-basert Ubuntu server som kjører gitolite1 og server git-repositorier for prosjektet Dokumentasjon For enkelt samarbeid om dokumentasjonen ble det etablert en delt mappe i Google Drive, der man sammen kan skrive dokumenter og dele filer. En rekke styringsdokumenter ble opprettet, blant annet Prosjektdagbok, Timeliste, Arkitektur og Arbeidsplan Ekstraturstyr Til Robotino ble det kjøpt inn diverse ekstraturstyr: 1. Laser RangeFinder 2. North Star trackingsystem 3. Gyroskop Prosjektgruppen har gjennomgått ekstrautstyret, men vil bare benytte gyroskopet videre i arbeidet Fase 1 - Testfase RobotinoAPI2 består av flere forskjellige klasser som naturlig deler opp Robotinos funksjonalitet i objekter. Prosjektgruppen testet funksjonalitet som var nødvendig for å løse de to POC-ene som ble utviklet i denne fasen. I oppstartfasen ble armen vurdert som den teknisk vanskeligste komponenten. Hovedgrunnene til dette er: 1. Armen kontrolleres ved hjelp av pneumatikk, noe gruppemedlemmene ikke har erfaring med. 2. RobotinoAPI2 implementerer armen, men denne delen av RobotinoAPI2 er ikke dokumentert. Vurderingen var derfor at gruppen burde starte med en enkel implementasjon av armen, POC1, for å se hvordan dette skulle gjøres og deretter registrere hva armen er i stand til utvidelse av Git som på en enkel måte gjør det mulig å kjøre git som en server, svn-style. Side 18 av 27

23 Prosessrapport POC1 Implementasjonen av POC1 ble gjort på følgende måte: 1. Tilkobling til Robotino 2. Pipe1 Kinect-koordinater fra en fil over SSH til stdin (standard in) i programmet 3. Hver gang det kommer et koordinat inn, vil dette bli konvertert til verdier passende for CBHA og deretter sendt som en kommando til Robotino via APIet POC2 Implementasjonen av POC2 ble gjort på følgende måte: 1. Programmet kobler til Robotino 2. Lytter på CBHAs potmetersensorer 3. Om det registreres at armen blir presset ned lukkes gripekloen 4. Om det registreres at armen blir presset opp åpnes gripekloen Kinect Microsoft Xbox Kinect ble introdusert for oss i et møte i forbindelse med faget Bionic Engineering. Kinect har tidligere blitt brukt til å kontrollere roboter, og ble av prosjektgruppen vurdert som svært egnet til interaksjon med Robotino. Figur 6, Skjermbilde fra NITE som viser Kinectdata Figur 7, Xbox Kinect Microsoft tilbyr et Software Development Kit (SDK) til Kinect. Dette er basert på Microsofts egen.net-plattform, og ville dermed bety introduksjon av en ny plattform i prosjektet. PrimeSense, som er leverandøren bak Kinect-teknologien, tilbyr software for å bruke Kinect under Linux via nettstedet OpenNI.org. 1 Pipe, representert ved tegnet, er en måte å sende ett programs utskrift videre som inndata til et annet program. Dette er en grunnleggende komponent i filosofien bak Unix-lignende operativsystemers oppbygning, der man kan oppnå komplisert funksjonalitet ved å videresende prosesserte data gjennom en rekke programmer som hver løser en konkret del av et problem. Side 19 av 27

24 Prosessrapport Prosjektgruppen bestemte derfor å benytte PrimeSense s løsning, OpenNI, da denne kunne kjøre på våre eksisterende maskiner. For å hente ut data fra OpenNI brukes en mellomvareløsning, NITE1. Grunnet den manglende dokumentasjon av mellomvaren NITE ble det besluttet at den enkleste løsningen for å få Kinect til å fungere var å modifisere et av eksemplene som var vedlagt. På denne måten var det mulig å anvende Kinect, uten å bruke betydelige ressurser på å skrive egen kode fra bunn. Etter testing var det NITE 1.5-eksempelet SingleControl som liknet mest på det prosjektet trengte. SingleControl-eksempelet printer X,Y,Z-koordinatene for forsøkspersonens hånd. Det ble besluttet å injisere kode i SingleControl for å modifisere eksempelkodens oppførsel slik at det først startet en socket-server og ventet på en tilkobling før den startet Kinect, for å så skrive koordinatene til socketen. NITE bruker også et eget kompileringssystem bygget på make, dessverre mangler dokumentasjon. Løsningen er et shellscript som erstatter kodeeksempelet med det modifiserte, for deretter bruke NITE s byggesystem Fase 2 - Designfase Figur 8, Første utkast av Brain 1. Design av rammeverket Brain basert på resultatene av Fase Side 20 av 27

25 Prosessrapport 2. Vurdering av oppbygning, bruk av software design patterns2 etc. 3. Lære om og se på gjennomførbarhet av implementasjon og bruk av nevrale nett Denne delen av utviklingen inneholt undersøkelser, læring og diskusjoner rundt designet av Brain. Det ble etablert et arkitekturdokument, ment som et arbeidsdokument og veiledning, med beskrivelser av systemet og kodestandard. Prosjektgruppen gikk gjennom flere software design patterns som kunne være aktuelle, blant annet thread pool og strategy, men kom fram til at det ikke ville hensiktsmessig å benytte noen av disse innenfor skopet av rammeverkets implementasjon. Nevrale nett ble også viet mye oppmerksomhet. Dette er et konsept som ble introdusert i Bionic Engineering-kurset og som prosjektgruppen så og fortsatt ser stort potensiale i, spesielt i forhold til deteksjon av ytre påvirkining. Undersøkelsen av nevrale nett resulterte i følgende konklusjon: 1. Implementasjon av nevrale nett ville være mulig. 2. Samtidig ville det ikke være tilstrekkelig med tid til gjennomføre læringsfasen for det nevrale nettet. Det finnes flere læringsmetoder til bruk mot nevrale nett, disse kan i hovedsak deles i to grupper: 1. Med ett ferdig sett med inndata og en forventet respons på inndataene. Man kan da gjennomføre en læring av et nett uten at dette er i drift. En læring gjøres da ved å kjøre inndataene, som kan være svært store, igjennom det nevrale nettet, sammenligne med ønsket resultat og så gjøre justeringer. Prosessen gjentas til frekvensen av feil respons er tilstrekkelig lav. 2. Trening av et nett i drift. Ved trening av en robot introduseres roboten for påvirkninger der påvirkningen skal gi en ønsket respons. Roboten kan stå for påvirkningen selv. Sensorer enten på roboten selv, eller eksterne brukes til å vurdere i hvilken grad responsen er korrekt eller ikke. På samme måte som i punkt 1. må dette også repeteres svært mange ganger, til man har en tilfredsstillende feilrate. I forhold til punkt 1 finnes det ikke noe datasett å trene mot, og å generere dette ville være både vanskelig og tidkrevende da ingen i prosjektgruppen har erfaring med dette fra tidligere. Gjennomføringen av punkt 2 ville kreve ekstra sensorer da Robotino, etter prosjektgruppens erfaring, ikke har tilstrekkelig sensorikk til å vurdere sin egen tilstand. I tillegg ville denne ta svært lang tid og i tillegg i verste fall kunne skade Robotino. Prosjektgruppen besluttet derfor å ikke gå videre med implementasjon av et nevralt nett. 2 Et design pattern er en form for mal for å løse et konkret problem innen programutvikling Side 21 av 27

26 Prosessrapport Fase 3 - Utviklingsfase 1 Fasen startet med å implementere de deler av rammeverket Brain som var nødvendig for å implementere POC3 og POC4. POC3 krever omfattende funksjonalitet for aksellerasjon, svinging, måling av kjørelengde etc, som gjorde det nødvendig å ha mer kode klart før eksempelet skulle implementeres Implementere Brain i tilstrekkelig grad til å løse POC3 og POC4. Gjennomføre POC3 - Kjøre til koordinat Gjennomføre POC4 - Kombinasjon av POC2 og POC3. Evaluere resultater Måling av avvik under kjøring i forskjellige modi. Under gjennomføring av POC3 ble det oppdaget et forholdsvis stort avvik mellom posisjonen fra odometrien og faktisk fysisk posisjon. Det ble derfor gjennomført måling av dette for senere tiltak som korreksjon og rekalibrasjon. 4 forskjellige scenarier ble målt, for å også se effekten av gyroskopet: 1. Case 1: Uten korreksjon mot odometri og uten gyroskop 2. Case 2: Uten korreksjon mot odometri, men med gyroskop 3. Case 3: Med korreksjon mot odometri, men uten gyroskop 4. Case 4: Med korreksjon mot odometri og med gyroskop Avvikene i Odometrien ble målt på følgende måte: 1. Robotino ble instruert til å kjøre enten 1. med korreksjon til punkt [ 1.5, 0 ], der enheten er 1 meter. 2. uten korreksjon til tilbakelagt distanse var 1.5 meter. 2. Koordinatet Robotino faktisk stoppet på ble deretter registrert. 3. Robotino ble så instruert til å kjøre baklengs tilbake til punktet [0,0] 4. Koordinatet Robotino faktisk stoppet på ble deretter registrert. 5. Prosessen ble gjentatt totalt 5 ganger. Side 22 av 27

27 Prosessrapport Figur 9, skisse over målinger Fase 4 - Utviklingsfase 2 1. Omskrivning 2. Videreutvikling Denne fasen ble lagt inn som en form for sikkerhetsbuffer. I løpet av oppstartsfasen ble det klart at sjansen for at det ville dukke opp flere overraskelser var stor. Det ble derfor lagt opp til to uviklingsfaser, der den siste kunne være enten en videreutviklingsfase, en omskrivningsfase eller begge deler. Som det skulle vise seg ble det behov for en større omskrivning. Denne baserer ser rundt misforståelser av hvordan RobotinoAPI2 oppdager og gjør programmet oppmerksomt på endringer i Robotinos sensorverdier og var absolutt nødvendig for å få til den levende, dynamiske funksjonaliteten prosjektgruppen ønsket. Med omskrivningen fulgte også muligheter som var et resultat av oppdagelser og læring i den første uviklingsfasen, noe som prosjekgruppen mener har resultert i ett bedre produkt enn det som ville vært tilfelle uten omskrivningen. Det ble også rom for noe videreutvikling, da innen korreksjoner, kalibrering og bevegelse og deteksjon for armen. Dessverre har en av funksjonalitetene for kjøringen, nemlig å kjøre baklengs, ikke kommet med i den siste versjonen. Side 23 av 27

28 Prosessrapport Fase 5 - Dokumentasjonsfase Da dokumentasjon av Robotino har vært en selvstendig del av prosjektet har prosjektgruppen dedikert en egen fase til dette. I dokumentasjonsfasen har dokumentasjon av Robotino og Kinect blitt komplettert, basert på de funn som er gjort i tidligere faser. I tillegg er dokumentasjon for Brain skrevet i denne fasen. 4 Utfordringer under utviklingen 4.1 Feil i RobotinoAPI2 Underveis i utviklingen ble det oppdaget feil i RobotinoAPI2. Disse feilene har blitt meldt på forum.openrobotino.org, som har sluppet nye versjoner av APIet med rettelser. Unntaket her er for feilen som angår odometri-målingene 4.2 Feil i Robotino Daemons Til å begynne med var det ikke mulig for oss å styre Robotinos arm. Ved spørsmål om hjelp ble det henvist til wiki.openrobotino.org med tilbakemelding om at alt fungerte som det skulle. Først etter å ha brukt svært mye tid på å teste forskjellige installasjoner og oppgraderinger ble prosjektgruppen til slutt hørt1, og problemet ble rettet i form av ny release av RobotinoAPI2. Det ble da oppdaget en feil i funksjonaliteten som slår av og på kompressoren. Problemet ble rettet og nye binærfiler ble sluppet i løpet av noen dager. 4.3 Manglende dokumentasjon av NITE Under arbeidet med Kinect var det ikke dokumentasjon av mellomvaren NITE tilgjengelig. Denne ble først publisert i begynnelsen av Mai Kinect På grunn av manglende dokumentasjon av NITE var det vanskelig skrive egen kode mot NITE. I tillegg baserer NITE og OpenNI seg på et udokumentert byggesystem. 4.5 Begrenset dokumentasjon av RobotinoAPI2 RobotinoAPI2 er dokumentert, men enkelte klasser og funksjoner har manglende eller fraværende beskrivelser. Dette ble meldt til openrobotino.org den 5. april 2013, i en forumpost En ny versjon av RobotinoAPI2 med mer utfyllende beskrivelser ble publisert 17. april Event- vs interrupt-basert RobotinoAPI2 implementerer funksjonalitet som tilsier at det er støtte for eventer. Det viser seg i midlertid at dette kun fungerer om man selv gjør et kall mot Robotino for å motta eventer. Dette stemmer overens med beskrivelser av disse begrepene funnet på internett, men denne oppdagelsen et stykke ut i implementasjonen førte med seg en større omskrivning. 1 Side 24 av 27

29 Prosessrapport Å sette verdier til odometrien fungerte normalt helt til gyroskopet ble koblet til, da ble det oppdaget at verdier som ble skrevet til retnings-variabelen ikke ble oppdatert. Dette ble meldt til openrobotino.org den 24. april 2013,i en forumpost En rettelse forelå 2. mai Avvik på odometri og rekalibrering På grunn av avvik på Robotinos odometri ble det nødvendig å rekalibrere Robotino underveis i kjøringen. Basert på dokumentasjonen av Robotino og RobotinoAPI2 var dette et uventet problem som har tatt mye tid. 4.8 Deteksjon av tilkoblet utstyr RobotinoAPI2 har ingen funksjonalitet for å oppdage om et utstyr man forsøker å koble til via APIet er tilkoblet og tilgjengelig eller ikke. Dette har ført til situasjoner der alt har sett normalt ut, men uten at enkelte komponenter fungert, noe som har ført til tid kastet bort på unødvendig feilsøking. Denne mangelen er også meldt til openrobotino.org den 9. mai 2013 i en forumpost Forespøselen ble tatt til følge og satt på listen over ønsket funksjonalitet. 4.9 C++ 11 Prosjektgruppen har ikke tidligere skrevet prosjekter i denne størrelsesorden i C++. Språket er avansert, og støtter blant annet operatøroverloading, pekere (til minneaddresser) og multithreading. Valget av språk sammen med prosjektdeltakerenes tidligere bakgrunn i Java har bydd på enkelte overraskelser som har tidvis vanskelig å debugge. Et eksempel her er at det i Java er vanlig å seriekoble konstruktører, dette er ikke mulig i C++ og fører til at man sitter igjen med et uinitialisert objekt. 5 Oppsummering av prosjektet Roboter og annen hardware har lenge vært ansett som en arena for elektroingenører. Med Robotino, og tilsvarende systemer, mener prosjektgruppen at tiden er kommet til at også informasjonsteknologer kan bidra på feltet. Tilgang til en Robots funksjoner via et C++-API gir oss mulighet tll å ta i bruk høyerenivå funksjonalitet som objektorientert programmering. Roboter og styringssystemer blir stadig mer avanserte, og er ikke lenger nok med en Programmable Logical Controller som sekvensiellt gjennomkjører prosedyrer. Gruppen tror fremtidens systemer vil kjøres på langt kraftigere datamaskiner som vil ha kapasitet til å analysere kompliserte data, kommunisere med andre datasystemer og interagere med mennesker på en naturlig måte. Informasjonsteknologistudiet ved HIOA er i stor grad rettet mot utvikling av programvare. Robotino-prosjektet, og faget Bionic Engineering, har gitt oss nye utfordringer og presset oss til å tenke i helt nye baner. Side 25 av 27

30 Prosessrapport Det hadde ikke vært mulig å gjennomføre prosjektet uten vår eminente veileder Alfred Bratterud takk for alle diskusjoner, hjelp til å finne veien igjennom kaoset og filosoferingen hver fredag. Det har vært interessant å skrive kode hvor resultatet blir uttrykt som fysiske bevegelser fra en robot. Der man vanligvis opplever feil som visning av feil tekst eller en blank skjerm, vil feil mot Robotino kunne medføre kjøring til feil punkt, plutselige stopp eller i veste fall en kollisjon. Med andre ord en reell, fysisk respons. 5.1 Erfaringer Robotino XT er et prosjekt hvor målsetning og forhåndskriterier ikke har vært kjent på forhånd. Prosjektgruppen har gjennomgått en oppstartsfase hvor utfallet ville avgjøre om prosjektet i det hele tatt ville la seg realisere. I prosjekter innen informasjonsteknologi er ofte oppgaven klart spesifisert og avgrenset. I så måte representerer dette prosjektet noe nytt for prosjektmedlemmene. Oppgaven lot seg ikke definere på forhånd, og reslutatet er heller ikke et konkret produkt, snarere dokumentasjon og et rammeverk i alpha-status1. Dilemmaet som oftest har utfordret oss er vurderingen om å gå bredt og kort, eller smalt og langt. Skal Brain implementere all funksjonalitet, eller skal Brain ha en fullstendig implementasjon av kjøringen? Vi har sammenliknet oss selv med kaospiloter. Det har vært problemstillinger uten kjente løsninger. Enkelte valg har derfor vært gambling. Er det overveiende sansynlig at armen vil fungere som tiltenkt, eller må den fjernes fra oppgaven? Odometrien er upresis, kan dette løses? 5.2 Robotino i samfunnet Roboter som Robotino representerer et utvalg Roboter som kan brukes i kombinasjon med mennesker. Den typiske industrielle roboten kommer med en tydelig sikkerhetsadvarsel; ikke bruk roboten sammen med mennesker, da den kan være skadelig. I produksjon plasseres ordinært slike roboter i store bur, for å forhindre at mennesker kommer for nære. Robotino har ingen deler som kan skade et menneske. Vekt og størrelse er begge for små til å vurderes som et problem. Hastigheten er moderat, og ikke minst er Robotarmen laget av plastikk, den er bøyelig og prosjektgruppen har ikke opplevet armen eller andre deler av Roboten som farlige på noen måte. 1 Som definisjon av et program eller annen kodes modenhet brukes begrepene Alpha og Beta. Alpha vil si at funksjoner er på plass, men at man må forvente at feil oppstår og at vesentlige endringer vil komme. Beta betyr at produktet nærmer seg en produksjonsklar tilstand, men at feil fortsatt kan oppstå og at det fortsatt kan skje enringer før produktet er klart til lansering. Side 26 av 27

31 Prosessrapport I denne sammenheng kan det nevnes at Sunnås sykehus, hvor man driver med rehabilitering av trafikkskadde, slagpasienter med mer, ser nytten av denne type robot. Eksempelvis kunne man tenkt seg at robotarmen kunne blitt brukt til å holde et dusjhåndtak som dermed blir bevegelig og kan dusje en pasient som ikke har mulighet til å bevege seg selv. Andre muligheter er bistand til daglige gjøremål der en robotarm kan erstatte/supplementere pasientens reduserte løftekraft eller koordineringsevne. Rammeverket Brain muliggjør tettere integrasjon mot andre datasystemer og enklere måter for kontroll av en robot. Selv om Brain er skrevet konkret mot Robotino vil prinsippene i stor grad være overførbare på andre, tilsvarende roboter. Side 27 av 27

32 Produktrapport Produktrapport Innledning Dette er produktrapporten for hovedprosjektet Robotino XT ved Høgskolen i Oslo og Akershus våren Produktet deles inn i tre deler som bygger på hverandre: 1. Dokumentasjon av Robotino og Kinect. 2. Rammeverket Brain. 3. Applikasjonen Fetch, bygget ved hjelp av Brain, som svarer på kravspesifikasjonen. Figur 1 Flere vedlegg er publisert elektronisk i prosjektets innleveringsmappe, 1. Kildekode for programmet Brain 2. Doxygen-generert API-dokumentasjon for Brain i både pdf- og html-format 3. Rådata og beregninger fra målinger av Robotinos Odometri. 4. Filmer av POCer og funksjonalitet Side 1 av 1

33 Produktrapport Robotino En rapport om roboten Robotino, beregnet på informatikere Side 1 av 24

34 Produktrapport Innholdsfortegnelse 1 Robotino XT Bionic Engineering Hardware Oversiktsbilde Robotino Oversiktsbilde kommandobro I/O Trådløst aksesspunkt Endre oppsett av Robotinos trådløse aksesspunkt Kommandobroen Mikrokontroller Aktuatorer OmniDrive CompactBHA arm, klo og pneumatikk Sensorer Optiske avstandssensorer Måling av optiske sensorer Potmetere Odometri Ekstrautstyr Gyroskop North Star Laser RangeFinder Programvare Operativsystem Koble til Robotino over SSH Oppgradering av Robotino API Tilgjengelighet og platformer Støttede språk Dokumentasjon Design Oppbygning og benyttet teknologi Kommunikasjon Installasjon Debian Windows Andre operativsystemer Støtteverktøy RobotinoView Robotino SIM Vedlikehold Maskinvare Programvare Side 2 av 24

35 Produktrapport Oppgradering av pakker fra openrobotino.org Oppgradering av Compact Flash-kort Andre ressurser Side 3 av 24

36 Produktrapport 1 Robotino XT Robotino XT er en robot produsert av Festo Didactic. Festo er en stor aktør innen industriell automatisering med pneumatikk og elektroniske styresystemer. Festo Didactics er Festos avdeling som driver utvikling av ny teknologi innenfor automatisering 1. Roboten Robotino er en grunnplattform som støtter en mengde tilleggsutstyr. XT-versjonen er utstyrt med en arm, kalt compact Bionic Handling Assistant (cbha), som kan gripe og løfte objekter. Løftekapasiteten er 0,6 kg. cbha er et eksempel på biomimikk, da den i Figur 1, bilde av Robotino svært stor grad er inspirert av en elefantsnabel. Fingrene i kloen har sin inspirasjon fra en fiskehale, på den måten at den, når den møter motstand, vil bøye seg rundt og dermed gripe objektet den presses mot, på samme måten en fiskehale vil vri seg for å gi maksimalt skyv framover når den presses mot vannet. 1.1 Bionic Engineering Bionic Engineering er en betegnelse på anvendelse av metoder og systemer man finner i naturen i studier og design av engineering systems og moderne teknologi. Naturen rundt oss har gjennom evolusjon løst mange av sine utfordringer på elegante måter. Disse løsningene kan også være gode løsninger i en annen sammenheng, nemlig i forbindelse med utvikling av nye løsninger. Eksempler på dette kan være: 1. Haiens spesielle skinn som skaper mindre motstand igjennom vann 2. Beskytte klørne ved å trekke disse inn i poten, som er en felles egenskap hos de fleste kattedyr 3. Elefantens snabel som har mulighet for å bøyes i alle retninger 4. Hjernens mulighet for læring, hvor langt kan jeg hoppe, eller hva kan jeg spise Man kan likevel diskutere hva som inngår i begrepet. Er for eksempel øyets sammentrekning av netthinnen for å justere for varierende lysforhold, en adopsjon eller en reaksjon? Det er ikke nødvendigvis mulig å overføre en løsning fra naturen direkte inn i en ingenørverden. Prinsippene bak løsningen kan likevel være så gode at de kan anvendes, eller være til sterk inspirasjon. Disse prinsippene kan også anvendes på andre måter enn hva naturen har brukt dem til. Vår moderne tidsalder har andre utfordringer enn de planter og dyr har utviklet seg for. 1 fbid=aw50lmvulju1ny4xny4xmc4znzmyljiymti Side 4 av 24

37 Produktrapport 1.2 Hardware Oversiktsbilde Robotino Figur 2, oversiktsbilde Robotino XT 1. Kontrollpanel. Av/på-knapp, display som viser status 2. Gyro 3. Tilkoblinger; USB, ethernet RJ-45, VGA-skjermkontakt 4. Innsettingsspor til Compact Flash-kort 5. IO-kontakter 6. Kompressor 7. Omnidrive hjul 8. Optisk avstandssensor 9. Strømkontakt for lading av batterier 10. CBHA. A: Indre kamre, B: ytre kamre 11. Ledd for vridning av arm 12. Gripeklo 13. Bumper Side 5 av 24

38 Produktrapport Oversiktsbilde kommandobro Figur 3, Viser kommandobroen på Robotino med deksel fjernet Trådløst aksesspunkt Modusswitch for trådløst aksesspunkt. (Bryter på undersiden) Mikrokontroller Hovedkort (skjult) Side 6 av 24

39 Produktrapport I/O Følgende tilkoblinger er tilgjengelige på Robotino XT: Tilhørende Beskrivelse Kontakt Antall Strømtilførsel 12 volt strømtilkobling Ustandardisert kontakt 1 Kommandobro Ethernet RJ45 100mbit 1 USB 2.0 Standard USB-A 2 Display VGA 1 Compact Flash kortleser (harddisk) CF type II 1 Trykklufttilførsel, max 2.0 bar Standard 1 CBHA (arm) Trådløst aksesspunkt Robotino leveres med et innebygget trådløst aksesspunkt. Dette er et separat kort montert inne i Robotinos kommandobro. Festo leverer Robotino konfigurert som sitt eget aksesspunkt. Dette gjør at man kan koble f.eks en bærbar maskin til Robotinos trådløse nettverk for kommunikasjon. For å forenkle utviklingsprosessen er aksesspunktet satt i klient-modus. Robotino vil da oppføre seg som en ordinær nettverksklient. Dette har flere fordeler: 1. Robotino har tilgang til internett på samme måte som en vanlig datamaskin 2. Robotino kan kontrolleres av flere eksterne kilder (laptop/pc/mobil) 3. En eksternt kontrollerende maskin kan samtidig koble seg til andre eksterne maskiner Endre oppsett av Robotinos trådløse aksesspunkt Side 7 av 24

40 Produktrapport Aksesspunktet kan settes i to forskjellige modus. Bytting av modus gjøre med bryteren som er montert i underkant av hovedkortet i Robotino. For å nå denne må det høyre bakdekselet fjernes. Aksesspunktet er montert over hovedkortet i Robotino. Ved feilkonfigurasjon eller andre problemer finnes en reset-knapp på kortet. Figur 5, viser kommandobroen på Robotino med dekselet fjernet Brukerveiledning Robotino kan utstyres med forskjellig typer aksesspunkt. Robotino XT har et kort fra produsenten ALLNET. Manualen dokumenterer oppsettet for kortet i routermodus. I klientmodus vises innstillinger for å koble kortet til et annet aksesspunkt. Manual for ALLNET: Klientmodus Her vil aksesspunktet oppføre seg som en klient, tilsvarende f.eks en laptop. I klientmodus vil Robotino motta IP fra det nettverket den kobler seg til. Fordelen med klientmodus er at Robotino har tilgang til internett, noe som er viktig i forbindelse med oppdatering av Robotinos programvare. Aksesspunktmodus Her vil nettverkskortet oppføre seg som et aksesspunkt, og la andre klienter, f.eks en laptop, koble seg til. Robotino kommer fra fabrikk med routermodus. Aksesspunktet vil sørge for at alle klienter får en IP (kjører en DHCP-server) og er ment som en enkel måte å sikre kommunikasjon med Robotino. Side 8 av 24

41 Produktrapport Konfigurasjon Konfigurasjon av kortet vil foregå over kortets webgrensesnitt. Dette vil etter en switch ha default IP med brukernavn og passord admin/admin Om kortet er satt i klientmodus kan man i webgrensesnittet oppgi hvilket trådløst nettverk som skal kobles til. Om kortet er satt i routermodus kan man velge navn og kryptering av det trådløse nettet aksesspunktet skal tilby. Det er også mulig å angi DHCP-serverkonfigurasjon. DHCP-server kan også kjøres av Ubuntu, operativsystemet på Robotino Kommandobroen Kommandobroen inneholder en datamaskin, utstyrt med en 500 mhz x86 prosessor og 256 mb ram. Som standard kjører den Ubuntu 9.04 uten grafisk brukergrensesnitt, og med en spesialtilpasset Linux-kjerne. Til å være en styringsenhet i en robot har Robotino mye datakraft. Som en sammenlikning leveres mikrokontrollen Arduino Uno med bare 16mhz prosessor og 2kb ram, likevel finnes det mange prosjekter basert på Arduino som må kunne sies å være avanserte. Den største forskjellen mellom Arduino Uno og Robotino er at Robotino også kjører en fullverdig installasjon av Ubuntu De tilgjengelige systemressursene må derfor deles med operativsystemet. CPU* AMD PCS Geode LX mhz Minne* Type er ukjent 256mb Harddisk Compact Flash Type II 8gb Skjermkort** AMD Geode LX Video (intigrert i CPU) Ethernet** Intel Corporation 8255xER/82551IT Fast Ethernet Controller 10/100mbit * Uthentet fra /proc-filsystemet tilgjengelig i Ubuntu. ** Uthentet med systemkommandoen lspci Mikrokontroller En mikrokontroller er en programmerbar prosessor som benyttes i elektroniske kontroll- og målesystemer. - Mikrokontrolleren styrer og leser av akutartorene1 og sensorene2 som følger med standardversjonen av Robotino, dette inkluderer kjøresystemet, bumperen og avstandssensorene. 1 2 Defineres under Defineres under Side 9 av 24

42 Produktrapport Aktuatorer En aktuator er en komponent som gjør om elektrisk strøm (strømstyrt) eller elektrisk spenning (spenningsstyrt) til mekanisk bevegelse. Den mekaniske bevegelsen kan brukes direkte, eller til å styre hydrauliske eller pneumastiske ventiler OmniDrive Robotino har et hjulsystem av typen omnidirectional drive. Dette systemet står av tre hjul montert med sin sentrale akse vendt mot Robtinos sentrum. Disse hjulenes ytterkant er påmontert mindre hjul som kan rulle på tvers av hovedhjulets rotasjonsretning. Ved å dreie de tre hovedhjulene i relative hastigheter i forhold til hverandre er det mulig å kjøre Robotino i enhver retning og samt rotere på stedet. Figur 7, viser Omnidrivehjul Figur 8, viser Robotinos omnidrivehjul CompactBHA arm, klo og pneumatikk Bionic Handlig Assistant er en robotarm utviklet av Festo Didactics. Armens viktigste egenskap er dens mulighet for å bevege seg i alle retinger, som en elefantsnabel. Styringen av armen er basert på pneumatikk, altså luft som blir presset inn i eller sluppet ut av kamrene. For å muliggjøre og kontrollere dette er Robtino XT utstyrt med blant annet kompessor, trykktank og et elektronisk styrt ventilsystem. Den kompakte versjonen av BHA, som Robotino XT er utstyrt med er bygget opp av totalt ni forskjellige kamre, som igjen er bygget opp av ledd. Når et kammer blir fyllt med luft vil leddene i kammeret utvide seg. Armens løftekapasitet er målt til å være ca 0.6 kg. Ved for rask bevegelse kan armen gå tom for komprimert luft, noe som fører til at løftekapasiteten reduseres og armen kan bli senket nedover på grunn av tyngekraften. Side 10 av 24

43 Produktrapport Seks av kamrene utgjør de to leddene av selve armen, mens to kamre styrer vridningen av en gripeklo montert ytterst på armen. Ett kammer står for lukking av gripekloen. Kamrene som sørger for armens posisjonering og vridning styres ved å oppgi ønsket trykk for hvert av kamrene. Ventilkontrolleren håndterer så åpning og lukking av ventilene. Kammeret som lukker gripekloen har to ventiler som styres direkte. Disse regulerer henholdsvis om luft slippes inn i og ut av kammeret. Ved lukking av kloen må inn-ventilen åpnes og ut-ventilen stenges. Etter lukking vil begge ventilene stenges av, slik at armen ikke trenger å tilføre trykkluft til gripefunksjonen kontinuerlig. Ved åpning av gripekloen åpnes kun ut-ventilen. Det er fullt mulig å holde begge ventilene åpne, noe som gjør a kloen lukkes delvis, men dette skaper problemer for resten av armen da kompressoren ikke vil være i stand til å opprettholde tilstrekkelig trykk. Side 11 av 24

44 Produktrapport Figur 9, viser Robotinos CBHA med trykkamre RECs fremstilling1 av hvordan et koordinat kan regnes om til nødvendig trykk for belgene. (Belg-nummereringen har blitt endret etter at dette bildet ble laget). 1 Side 12 av 24

45 Produktrapport Sensorer Optiske avstandssensorer 1. 9 optiske sensorer med en rekkevidde på ca 40 cm montert rundt hele maskinen. Gir mulighet for deteksjon av objekter 360 grader rundt. Figur 10, Avstandssensorenes plassering.tegningen er ikke nøyaktig Bumper 1. 1 bumper, en trykkfølsom tube som går rundt hele roboten og gir signal ved kontakt (kollisjon) Måling av optiske sensorer Ved å måle rekkevidde og vinkel på sensorene ble det avgjort at det var de tre sensorene som vender forover som ville være i stand til å registrere hindringer armen kunne kollidere med. De tre sensorene er kontrollmålt med linjal, basert på en variabel avstand som stod 90 grader på sensorene. Resultatet viser at alle sensorer var tilnærmet likt nøyaktige og at 41 cm var maksimum rekkevidde. Under 40 cm gav sensorene forholdsvis stabile verdier. Disse sensorene er også testet mot forskjellige overflater. Blanke overflater, som lakkert metall, gav variable verdier, spesielt om roboten selv var i bevegelse mot objektet. Det ble målt ganske nøyaktige verdier innenfor 30 cm. Mattere overflater, som ulakkert treverk, gir stabile verdier på 40 centimeters avstand. Måledata for sensor nr 1: Materiale Avstand Min. måling Maks måling Avvik Metall 28 cm 27.9 cm 28.2 cm 0.3 cm 35 cm 32.5 cm 37.2 cm 4.7 cm Side 13 av 24

46 Produktrapport Treflate 39 cm 23.5 cm 41.2 cm 17.7 cm 28 cm 28.0 cm 28.0 cm 0.0 cm 35 cm 34.8 cm 35.1 cm 0.3 cm 39 cm 38.7 cm 39.1 cm 0.3 cm Potmetere Potmeterene er montert på Robotinos arm. 6 sensorer som leser av posisjonen til BHA, og en sensore som leser rotasjonen til kloen Odometri For enkel navigasjon finnes det en odometri-modul i Robotinos programvare. Odometrien er et software-basert system i API2 som leser av Robotinos motorer og bruker denne informasjonen til å anslå Robotinos bevegelser. Demed kan kjørelengde i X og Y retning og også rotasjon beregnes. Ved oppstart er Robotinos posisjon origo med phi (rotasjon) 0, men dette kan settes til ønskede verdier via APIet, eksempelvis for å rekalibrere eller synkronisere Robotino til et eksternt koordinatsystem. I utgangspunktet vil dette være tilstrekkelig til å kunne navigere for eksempel fra ett punkt og tilbake, dessverre er avviket på odometrien for stor til at dette er særlig anvendelig i praksis. For å håndtere avviket har kjøringen blitt optimalisert ved hjelp av et sett med metoder: 1. Gyroskopet1 er koblet på 2. Implementert funksjonalitet som korrigerer retningsavvik underveis i kjøringen 3. Aksellerasjon under start og stopp. Avvik i retningslengden oppstår under for raske hastighetsendringer. Følgende to grafer, for case 1 og case 4 illustrerer forskjellen på kjøring uten og med optimalisering. Case 1 og case 4 er valgt fordi disse casene viser det dårligste og beste resultatet. 1 Se kapittel om ekstrautstyr på Robotino Side 14 av 24

47 Produktrapport Figur 11, antatt posisjon Case 1 Figur 13, viser antatt posisjon Case 4 Figur 12, faktisk posisjon Case 1 Figur 14, viser faktisk posisjon Case 4 Forskjellen mellom grafene, figur 11 og 13 skyldes de optimaliseringer som er foretatt. I case 4 vil både de antatte posisjonene og den faktiske posisjonen begge være mer nøyaktig enn i case 1. Dette er fordi Robotino i case 1 oppfatter at den er ute av kurs, men mangler funksjonalitet til å rette dette opp. I case 4 vil funksjonaliteten utviklet av prosjektgruppen justere roboten i rotasjonsretningen slik at roboten justerer inn det avviket som til en hver tid oppstår. Side 15 av 24

48 Produktrapport Ekstrautstyr Gyroskop Et gyroskop utnytter den såkalte gyro-effekten i et hurtig roterende legeme til å måle rotasjon på tvers av legemets Figur 16, printsippet bak et gyroskop rotasjonsretning. Ved å montere og koble til Festos gyroskop Figur 15, viser gyroskop påmontert Robotino erstatter dette odometriens vinkel-beregning. Odometrien fungerer ellers på samme måte og benyttes fortsatt for å lese av vinkelen. Dette gir en vesentlig mer presis rotasjonsvinkel, noe som også gir bedre X og Y -koordinater da avvik i rotasjonen oppdages av gyroskopet og tas med i beregningene. Dette betyr ikke at Robotinos fysiske posisjon automatisk blir forbedret, man må selv anvende den forbedrede dataen fra Gyroen til å justere Robotinos retning North Star North Star1 er et sporingssystem levert av Festo. North Star baserer seg på avlesning av et stjernekart som projisereres i taket av en spesiell lyskaster, samtidig som Robotino er utstyrt med et kamera som kan lese av kartet i taket. Figur 16, North Star tracking system 1 fbid=aw50lmvulju1ny4xny4zmi4xmty4ljcwnzk Side 16 av 24

49 Produktrapport North Star er integrert i RobotinoAPI2 og kan derfor leses via API-ets NorthStar-klasse. Output fra North Star er X,Y. Dette er et koordinat som angir Robotinos posisjon relativt til kartet i taket. I seg selv vil ikke North Star bidra til forbedringer av Robotinos Odometri, men data fra North Star kan brukes til å rekalibrere Robotinos posisjon, dette er kode som utvikleren må skrive selv Laser RangeFinder RangeFinder2 er en laser som kan monteres på Robotino. Laseren vil måle avstanden i synsretning med en bredde på 180 grader. Bruksområdet er mapping (kartlegging) av rom, lokalisere objekter eller som et suppliment til navigasjon. Figur 17, En standard Robotino påmontert laser Range Finder (øverst) 1.3 Programvare Operativsystem Robotino kjører operativsystemet Ubuntu fra Canonical3, som er en Debian-basert Linuxdistribusjon. Ubuntu er den mest brukte Linux-distribusjonen, viser en undersøkelse fra Ubuntu 9.04, versjonen som kjører på Robotino, er en foreldet utgave fra april I utgangspunktet har ikke dette noen betydning for Robotino, allikevel skal man være klar over ntu_survey_says.html Side 17 av 24

50 Produktrapport at eventuelle sikkerhetsproblemer som har blitt kjent siden 23 oktober 2010, som er end-oflive-datoen, ikke vil være rettet i dette operativsystemet1. Ubuntu kan oppgraderes med kommandoen sudo apt-get update && sudo apt-get upgrade, men dette vil ikke fungere med mindre man legger inn pakkebrønnen: deb jaunty main restricted i /etc/apt/sources.list Koble til Robotino over SSH Det er mulig å koble til Robotino over Secure Shell2. Her benyttes følgende kommando fra en linuxmaskin: ssh <ip> -l robotino (passord: robotino). I vårt oppsett har Robotino ipadressen ; ssh l robotino For å bli root (administratorbruker) kan følgende kommando kjøres på robotino; sudo -s Oppgradering av Robotino Installasjon og oppgradering av Robotino kan gjøres på tre måter. I alle tilfeller må brukeren først logge seg inn på Robotino over SSH. Via apt-get Forutsetter at Robotino har tilgang til internett. 1. Legg til linjen deb i /etc/apt/sources.list. 2. Kjør kommandoen sudo apt-get update (svar yes på bekreftelse på at det nye repositoryet skal legges til selv om det ikke er signert) 3. Kjør kommandoen sudo apt-get -y upgrade for å oppgradere pakkene. Er ikke pakkene installert kan kommandoen sudo apt-get install robotino kjøres. 4. Restart Robotino. Via dpkg Foretrukken løsning om Robotino ikke har tilgang til internett. 1. Last ned deb-pakkene med programvaren som ønskes installert til lokal maskin. Disse ligger tilgjengelig på 2. Koble den lokale maskinen til Robotino 3. Flytt pakkene over til Robotino, dette kan gjøres med kommandoen scp -rc /path/til/pakker/*.deb robotino@<ip>: (under Windows kan programmet filezilla brukes for å kjøre sftp mot Robotino over SSH). 4. Logg inn på Robotino via SSH 5. Kjør kommandoen sudo dpkg -i *.deb for installasjon av deb-pakkene som ble lastet over. 1 Secure Shell, ssh, er et system bestående av en server og klient som muligjør sikker tilkobling til termnial-grensesnittet på en annen datamaskin enn den man sitter på. 2 Side 18 av 24

51 Produktrapport 6. Restart Robotino. Installasjon fra kildekode Dette er en langt mer avansert prosedyre hvor man kjører en checkout av openrobotino.orgs subversion-repository og kompilerer kildekoden selv. Kompileringen kan foregå på egen maskin, hvor det blir generert deb-pakker som så kan installeres, se punktet via dpkg. Alternativt kan kompileringen foregå direkte på Robotino. Prosedyren for å gjennomføre kompilering ligger på openrobotino.org på følgende adresse: Prosedyren blir oppdatert i tråd med den til en hver tid gjeldende prosedyre. Prosedyren gjengies derfor ikke her. Det anbefales også å konsultere forumet på forum.openrobotino.org for eventuelle endringer i kompileringen API Tilgjengelighet og platformer For Robotino foreligger det per i dag to APIer. Det opprinnelige, OpenRobotinoAPI, og det nye RobotinoAPI2. RobotinoAPI2 er fortsatt under utvikling, men er anbefalt benyttet for nye prosjekter1. Begge APIer er tilgjengelige både som kildekode og som et begrenset utvalg binærfiler som dekker både Windows og Debian GNU/Linux (inkludert avledede distribusjoner som Ubuntu). Denne rapporten begrenser seg videre til RobotinoAPI2, heretter API Støttede språk RobotinoAPI2 foreligger for C++, men det følger med wrappere for følgende språk: 1. C 2..Net 3. Java 4. LabVIEW 5. Microsoft Robotics Developer Studio (MRDS) 6. MATLAB 7. Robot Operating System (ROS) I tillegg vil det være fullt mulig å benyttes seg av språk som selv kan gjøre kall mot C++, for eksempel Python. 1 Side 19 av 24

52 Produktrapport Dokumentasjon Med API2 følger det en API-dokumentasjon generert fra kildekoden og JavaDoc-tagger ved hjelp av Doxygen. En online-versjon er tilgjenglig her: (Denne utgaven kan være noe utdatert, se dato på bunnen av siden. En oppdatert versjon følger med ved installasjon av API2, se punktet Installasjon under.) Design API2 fungerer på en måte som ligner svært mye på tradisjonell C-stil. Med dette menes at det i stor grad er brukt pekere sendt med som argumenter som blir brukt til å returnere verdier. Det er i svært liten grad brukt objekter Oppbygning og benyttet teknologi Programvaren i Robotino er utviklet av REC (Robot Equipment Corporation). API2 er basert på et kommunikasjonsrammeverk kalt REC RPC1 (Remote Procedure Call), også utviklet av REC. Både API2 og REC RPC er bygget på Qt versjon 4.5. Bruk av APIet krever følgelig at en kompatibel versjon av Qt er installert. Sett bort i fra det OpenRobotinoAPI har API2 ingen andre eksterne avhengigheter Kommunikasjon Kommunikasjonen mellom et et program som benytter API2 og Robotinos server-daemon fungerer omtrent slik: 1 Side 20 av 24

53 Produktrapport Figur 18, viser skisse over kommunikasjon fra API til Robotino Kommunikasjon skjer over en TCP socket. Det er mulig å kjøre et program direkte på Robotino. RPC-biblioteket vil da i stedet for benytte sockets kommunisere med serveren ved hjelp at direkte minneaksess, noe som effektivitetsmessig er tilsvarende om programmet skulle være en del av daemonen. Dette krever at programmet kjøres med root-privilegier for å ha tilgang til minneområdene der daemonen kjører Installasjon For å installere API2 på en ekstern maskin har man i utgangspunktet to muligheter Debian For Debian eller operativystemer basert på dette kan openrobotino.org s pakkebrønn benyttes: 1. Legg til pakkebrønnen, plasser en av følgende linjer i /etc/apt/sources.list (uten fnutter ( )) bit-systemer: deb bit-systemer: deb 2. Kjør kommandoen sudo apt-get update (svar yes på bekreftelse på at det nye repositoryet skal legges til selv om det ikke er signert) 3. Kjør kommandoen sudo apt-get install robotino-api2 Side 21 av 24

54 Produktrapport API2 vil nå oppdateres automatisk sammen resten av systemet Windows Installasjonsfil kan lastes ned her: title=downloads#openrobotino_api Andre operativsystemer Prosedyren for å gjennomføre kompilering ligger på openrobotino.org på følgende adresse: Prosedyren blir oppdatert i tråd med den til en hver tid gjeldende prosedyre. Prosedyren gjengies derfor ikke her. Det anbefales også å konsultere forumet på forum.openrobotino.org for eventuelle endringer i kompileringen Støtteverktøy RobotinoView Robotino View is the interactive graphical programming and learning environment for Robotino. - Figur 19, Robotino View Robotino View er et interaktivt grafisk programmerings- og læringsmiljø for Robotino. Programvaren lar brukeren lage sette sammen programmer via et grafisk grensesnitt som så kan koble seg til Robotino og kjøre programmet der. Robotino View kan også oppgradere programvare på Robotino Robotino SIM RobotinoSim is a software to simulate the movements of Robotino with real physics enginge. [sic] - Side 22 av 24

55 Produktrapport Figur 20, RobotinoSIM Robotino SIM er en programvare som kan simulere Robotinos bevegelser i en realistisk fysikkmotor. Dette gjør det mulig å simulere den koden man har skrevet, noe som forenkler testing betydelig og eliminerer fare for skade på roboten. Det anbefales fra prosjektgruppens side å prøvekjøre nyutviklet kode innenfor områdene kjøring og navigasjon i RobotinoSim for å unngå skade på Robotino som følge av kollisjoner. 1.4 Vedlikehold Maskinvare Støv og skitt fester seg lett til Robotinos omnidirectionale hjul. For å forhindre avvik er det derfor fordelaktig å rengjøre disse regelmessig. For å maksimere levetiden på batterieene er er det anbefalt at Robotino er slått av når laderen er tilkoblet Programvare Oppgradering av pakker fra openrobotino.org RobotinoAPI2 og alle deamons som kjører på Robotino vil kunne oppgraderes via apt-get. apt-get er et program som kjøres i Ubuntu for å oppdatere programvare. For å legge inn openrobotinos pakkebrønn i apt s kilder, kjør kommandoen (uten linjeskift): sudo echo deb >> /etc/apt/sources.list Dette gjøres kun én gang. Så kan følgende kommando brukes til å oppgradere pakkene: sudo apt-get update && sudo apt-get -y upgrade Side 23 av 24

56 Produktrapport Den siste kommandoen bør utføres jevnlig for å sørge for at den siste versjonen av programvaren er installert. For mer info se vedlikehold. Det anbefales å ta en sikkerhetskopi av Compact Flash-kortet før en oppgradering Oppgradering av Compact Flash-kort Følgende kommando tar en sikkerhetskopi av CF-kortet. Merk at kommandoene må kjøres på en linuxmaskin, hvor CF-kortet er plassert i en minnekortleser. Jobben kan ikke utføres på Robotino. CF-kortet må ikke være mountet1. sudo dd if=/dev/sde1 of=/home/~/sikkerhetskopi.dd Der /dev/sde1 er adressen til CF-kortet i Ubuntus filstruktur. Enkleste fremgangsmåte for å identifisere denne adressen er å kjøre kommandoen ls /dev/sd*, koble i kortleser med CFkortet i og kjøre ls /dev/sd* en gang til. Ved å sammenlikne listene vil det være mulig å finne den korrekte adressen. For ytterligere informasjon om dd kjør kommandoen man dd. For å skrive et nytt image til CF-kortet kjøres følgende kommando: sudo dd if=/home/~/robotino_cf_image_v24_ _4gb.dd of=/dev/sde1 1.5 Andre ressurser Følgende er en liste over generelle ressurser prosjektgruppen har hatt nytte av under arbeidet med Robotino 1. Openrobotino.org forum Openrobotino.org wiki Wikipedia.org - For innføring i pneumatikk, odometri og andre begreper som var utkjente ved prosjektstart. 4. Stackoverflow.com - C++ og andre generelle programmeringsspørsmål er besvart her, eller bør være det. 1 Når en partisjon/disk er mountet, er filsystemet koblet til operativsystemet for vanlig bruk. I tilfellet vist her leses det i stedet direkte fra enheten, noe som ikke er mulig når filsystemet er i bruk. Side 24 av 24

57 Produktrapport Kinect Kapittel om Kinect, rettet mot informatikere Side 1 av 5

58 Produktrapport Innholdsfortegnelse 1Kinect Installasjon og oppsett Installasjon Dokumentasjon... 5 Side 2 av 5

59 Produktrapport 1 Kinect Microsoft XBox Kinect er i utgangspunktet en ekstramodul til spillekonsollen XBox. Denne brukes i spill til å lese av spillerens bevegelser, slik at en spiller kontrollerer spillet med å bevege armer og/eller bein, hele kroppen blir en kontroller. Figur 1, Xbox Kinect Teknologien i Kinect er levert av PrimeSense. Dette selskapet leverer også andre, forbedrede versjoner av samme løsning. Sammenlignet med Kinect har disse bedre kameraer og kan lese av bevegelser med mer nøyaktighet. PrimeSense leverer også programvaren NITE som er en middelware for tolkning av dataene Kinecten produserer. Denne Figur 2, skisse, Kinect tracker objekt mellomvaren genererer koordinater for ulike punkter på spillerens kropp som så kan hentes ut. 2 Installasjon og oppsett Microsoft leverer et SDK (software development kit), Kinect for Windows 1, som gjør det mulig å bruke Kinect på en vanlig datamaskin. Det finnes også en Open Source-basert løsning som baserer seg på OpenNI og NITE. OpenNI har ikke offisiell støtte for Microsoft Kinect på grunn av lisenskrav. Derfor kreves 1 Side 3 av 5

60 Produktrapport også en open source driver for Kinect; SensorKinect 2. Figur 3, viser data fra Kinect i NITE Ved å velge løsningen basert på OpenNI kan Kinect kobles til en Linux-maskin. 2.1 Installasjon Denne instruksjonen tar seg av installasjon av OpenNI, NITE og SensorKinect og er basert på følgende guide: http :// igorbarbosa. com / articles / how - to - install - kin - in - linux - mint -12- ubuntu / Avhengigheter: sudo apt-get install libusb dev freeglut3-dev g++ git Opprett mappe for installasjon: mkdir ~/kinect SensorKinect: cd ~/kinect git clone cd SensorsKinect git checkout unstable sudo./install OpenNI: cd ~/kinect git clone cd OpenNI git checkout unstable (OpenNI v ) sudo./install NITE: cd ~/kinect 2 Side 4 av 5

61 Produktrapport wget Bin-Linux-x64-v tar.zip unzip NITE-Bin-Linux-x64-v tar.zip tar xvf NITE-Bin-Linux-x64-v tar.bz2 cd NITE-Bin-Dev-Linux-x64-v sudo./install 3 Dokumentasjon Produkt Versjonsnummer Dokumentasjonsstatus Dokumentasjon OpenNI 2.0 Ingen status angitt. Ingen eksempler på kode, ingen oversikt over klasser. Det finnes en Programmers Guide som forklarer deler av APIet. Det medfølger noen eksempler på bruk i installasjonspakken NITE Still preliminary. Publisert Medfølger enkelte kodeeksempler i installasjonspakken. http :// www. openni. or g/ resources /, http :// www. openni. or g/ openni - programmers - guide / http :// www. primesen se. com / wp - content / uploads /201 3/04/ PrimeSense _Ni TE 2API _ProgTutoria lguide _C + + Samples _docver pdf SensorsKinect Løpende Klasseoversikt (doxygen) Følger med installasjonspakke Dokumentasjonen er rettet mot versjon 2.0 av både OpenNI og NITE. Det er ikke publisert dokumentasjon for NITE 1.5, som er brukt i prosjektet. Dokumentasjonen for NITE2 var ikke tilgjengelig da prosjektets Kinect-funksjonalitet ble skrevet, denne ble først publisert i starten av mai måned. Side 5 av 5

62 Produktrapport Brain Rammeverk for Robotino Side 1 av 13

63 Produktrapport Innholdsfortegnelse 1 Brain Innledning Situasjon Løsning Resultat Design Hovedtrekk Geometri-bibliotek Flertrådet kjøring Innstillinger Funksjonalitet _Odometry _OmniDrive _CompactBha Hvordan ta i bruk Brain Installasjon RobotinoAPI Kompilere Brain Kjøre Brain Med RobotinoSim Legge til egen kode Videreutvikling Publisering og lisens Forslag til videre utvikling Robotinos tilleggsutstyr Avstandssensorer Forbedring av cbha Ekstern konfigurasjon og parametere Herding av Brain Versjoner Design Design Delvis implementasjon Design Implementasjon Alfa stadie Teknologier benyttet i Brain og tilhørende kode...13 Side 2 av 13

64 Produktrapport Brain Innledning En utfordring i programmering av roboter er at dette ofte gjøres på et veldig lavt nivå, ofte ved å skrive direkte til minneadresser som igjen leses av robotens mikrokontrollere. Dette gjør det svært vanskelig å få til komplisert funksjonalitet. Situasjon Med Robotino og RobotinoAPI2 har programmeringen blitt gjort vesentlig lettere ved å muliggjøre programmering mot et høyerenivå C++ API. Allikevel er det, selv med RobotinoAPI2, kun en veldig direkte kontroll som er tilgjengelig. Det må fortsatt mye til for å utføre mer enn helt grunnleggende operasjoner, abstraksjonsnivået er for lavt. Løsning For å øke abstraksjonsnivået ytterligere har prosjekgruppen laget et rammeverk kalt Brain. Brain abstraherer bort detaljbevegelsene som må utføres og lar programmeren fokusere på det han/hun vil oppnå. Resultat Brain muliggjør for eksempel forflytning til et koordinat, kun ved å oppgi koordinatet. For å oppnå det samme kun med RobotinoAPI2 må Robotinos posisjon kontinuerlig leses av, hastigheter og vinkler må beregnes og instruksjoner sendes til Robotino. Brain håndterer alt dette for utvikleren og følger samtidig mer på andre sensorer, slik at f.eks. armen vil reagere på fysisk kontakt selv uten at en funksjon kjøres av brukeren. Side 3 av 13

65 Produktrapport Design Figur 1, Viser klassediagram for Brain Hovedtrekk Brain består av en rekke klasser som håndterer Robotinos funksjonalitet gjennom RobotinoAPI2 I tillegg til en klasse for tilgang på Kinect-avlesning over nettverk muliggjort av en klasse kalt TcpSocket 1. I tillegg finnes det et bibliotek av geometri-klasser til lagring og kalkulering av blant annet vinkler og koordinater. Hovedklassen Brain arver RobotinoAPI2s Com-klasse. Com danner kommunikasjonsobjektet som kobler seg til Robotino og håndterer kommunikasjonen. Brain eier alle andre API2-objekter og står for initalisering og kommunikasjon mellom disse. I tillegg håndterer Brain tråder for sin egen hovedsløyfe, for avlesning av og aksjon mot hendelser tilhørende kommunikasjonsobjektet og for avlesning av eksterne sensorer der disse er aktivert. 1 TcpSocket er skrevet av prosjektgruppens deltakere i forbindelse med en tidligere oppgave, men har fått utført noen endringer i samsvar med nye krav som følge av dette prosjektet. Side 4 av 13

66 Produktrapport En viktig komponent er grensesnittet Axon 2. Dette arves av alle Brains underkomponenter og gir en peker tilbake til Brain, i tillegg til å forutsette implementasjon av to funksjoner, analyze() og apply(). Disse funksjonene utfører henholdsvis analyse og bearbeiding av inndata og effektuering av resultatdataene. Hensikten er å la Brain, i mellom disse stegene og utifra en større helhet, kunne modifisere hva som faktisk effektueres. I tillegg k an man også på sikt skille ut deler av analysen i egne tråder dersom mer avansert funksjonalitet Figur 2, Illustrasjon av et nervefiber, Axon fører til tyngre kalkulasjoner, uten å oppleve at Robotino aksjonerer asynkront. Geometri-bibliotek Geometri-biblioteket er skrevet for Brain og inneholder kun de klasser og funksjoner som har vært nødvendig for utviklingen av Brain. Ved videreutvikling oppfordrers det til å bygge videre på dette biblioteket i stedet for å gjøre kalkulasjoner andre steder i Brain-koden. Bestanddelene av geometri-biblioteket er utskilt Figur 3, Arvdiagram for geometriklassene på atomert nivå og arver hverandre for å bygge opp sammensatte geometriske konstruksjoner. Dette vil si at en vektor, Vector, som fra matematikken består av en skalar og en vinkel arver nettopp Scalar og Angle. På denne måten kan man direkte benytte funksjonalitet i Angle for å regne ut differanse-vinkelen mellom en posisjon med vinkel, AngluarCoordinate, og en vektor, Vector. Man kan også direkte benytte en 3d-koordinat, VolumeCoordinate, som en 2d-koordinat, Coordinate, der kun denne delen av koordinatet benyttes. Annen funksjonalitet er å regne ut vektoren fra en koordinat til en annen, reversering av en vinkel som også gjør samme for en Vector. Biblioteket har ingen knytninger til Brain og kan således på sikt skilles ut og benyttes i andre prosjekter. En endring som da bør gjøres er å endre bruken av floats til doubles. Floats er brukt da de har tilstrekkelig presisjon mot Brain. 2 Nervefiber; http :// en. wikipedia. org / wiki / Axon Side 5 av 13

67 Produktrapport Flertrådet kjøring Figur 4, Tråd som kjører i Brain Brain kjøres i hovedsak i to tråder, én hovedtråd som kjører analyse- og utføringsfunksjonaliteten, og én tråd som utfører hendelser fra kommunikasjonsgrensesnittet Com. I tillegg kommer tråder for avlesning av eksterne sensorer (Kinect). Brain eier og håndterer selv disse trådene og sørger for å stoppe og stenge trådene ned når Brain-objektet dør. Side 6 av 13