Det er flere nivåer av programvarekontroll som må finne sted i alle roboter, bortsett fra de aller enkleste. Mikrokontrollerenhetene (MCU-er) og system-on-chip-løsningene (SoC) som er ansvarlige for å styre sensorer og aktuatorer, bruker vanligvis et sanntidsoperativsystem (RTOS) eller en kjerne.
Maksimering av systemressurser med RTOS-multitasking
Fordelen med å bruke RTOS er støtte for multitasking. Det er en relativt enkel måte å planlegge en rekke aktiviteter på én enkelt mikroprosessor på en måte som maksimerer ressursene og systemets evne til å reagere på eksterne hendelser. For eksempel må åpningen av sikkerhetsburet utløse et avbrudd i aktivitetene på en måte som minimerer risikoen for roboter og personell. Bare det å fjerne strømmen er kan være farlig. RTOS kan utløse alle handlingene som trengs for å plassere roboten i en tilstand der den ikke beveger seg, men samtidig sørge for at den ikke mister tunge gjenstander eller skader noe annet. Dette kan for eksempel oppnås ved å gå over til en programvaretråd som beordrer kraftelektronikkretsene til å holde motorene i forhåndsdefinerte posisjoner.
I kombinasjon med riktig utformet applikasjonsprogramvare kan RTOS gi harde garantier for hvor lang tid det tar å reagere på kritiske hendelser, som normalt signaliseres av et eksternt avbrudd til mikroprosessoren. Dette håndteres normalt gjennom en avbruddsbehandler som kan starte en programvaretråd som kan iverksette tiltak. Gjennom prioritetsbasert og forebyggende planlegging garanterer RTOS kortest mulig ventetid for denne typen respons på de viktigste problemene.
ROS: Robot Operating System
I dagens roboter blir bruk av flere mikroprosessorer og maskinvareakseleratorer stadig vanligere, og hver eneste aktuatornodene må styres av et overordnet system som tar seg av oppgaveplanlegging og atferd. Dette er en rolle som vanligvis ivaretas av mellomvare, for eksempel ROS, som kjører på en mikroprosessor med høy ytelse.
I dag er ROS designet for å kjøre på et operativsystem som Linux, i stedet for å være et eget operativsystem. ROS krever heller ikke RTOS-oppførsel fra det underliggende operativsystemet, ettersom det utfører mer langsiktige oppgaver enn de som krever mikrosekunders responstid. Det arbeides imidlertid med å bygge ROS 2.0-implementeringer som kan kjøres på RTOS-plattformer, for enda bedre responstid.
Mellomvaren som utgjør ROS, tilbyr en rekke tjenester. De omfatter maskinvareabstraksjon av lavnivåenheter og støtte for meldingsoverføring mellom prosesser for å muliggjøre flerprosessorarkitekturer og administrasjon av programvarepakker. Prosesser representeres vanligvis ved hjelp av grafer som knytter sammen noder for å angi hvor prosesseringen foregår og hvordan prosessene kommuniserer med hverandre. ROS-implementeringer er ofte pakker med åpen kildekode og bruker Linux-plattformer for å gjøre det enklere å håndtere avhengigheter mellom prosjekter med åpen kildekode. Dette har den fordelen at ROS-programvaren er lett tilgjengelig.
I ROS er noder prosesser eller programvaremoduler som håndterer én eller flere relaterte oppgaver. For eksempel kan et kamera og en bildebehandlingsnode behandle visuelle data fra en eller flere bildesensorer. For å gjøre det mulig å bruke nettverksinfrastruktur for å koble sammen noder – en arkitektur som nå er vanlig i bilsystemer – støtter ROS TCP/IP og UDP for meldingsoverføring. De ulike nodene og tilkoblingene kan beskrives ved hjelp av Universal Robot Description Format (URDF), som er et XML-filformat.
For å muliggjøre effektiv deling av sensordata og kommandoer benytter ROS en publiser-abonnér-mekanisme der noder registreres for å informeres om spesifikke emner. Eventuelle oppdateringer om hvert emne sendes til alle de abonnerende nodene. ROS Master holder oversikt over alle tjenester og emner. Den håndterer registrering av noder og driver en parameterserver slik at nodene kan lagre og hente felles konfigurasjonsdata.
En stor fordel med mellomvare som ROS er gjenbruk og deling av kode. Kodedeling gjør det mulig for alle brukere å ha en felles base av programvare, noe som bidrar til å gjøre testingen og programvaren mer pålitelig. ROS er ikke begrenset til fysiske roboter.
Den støtter også simulerte roboter.
Hvilken rolle spiller simulasjon i utvikling av roboter?
Et av de viktigste kravene til robotdesign er muligheten til å simulere robotens oppførsel i et virtuelt miljø før den implementeres i maskinvaren. Simulatoren gjør det mulig å skrive og feilsøke robotprogrammer offline. Det gjør det mulig å utvikle programvare i et risikofritt miljø og unngår å skade roboten eller robotens omgivelser hvis det foreslåtte programmet inneholder alvorlige feil. Den endelige versjonen kan deretter testes på en faktisk robot.
Det finnes flere fordeler med simulering. Designere kan utvikle i faser og starte med enkle høynivåmodeller, noe som er gunstig for komplekse prosjekter. Slike simuleringer kan brukes på et tidlig stadium for å fastslå om et system er levedyktig. Simuleringsmiljøene som er utviklet for robotteknologi, er utformet for å være kompatible med et bredt spekter av programmeringsspråk, noe som gjør utviklingen enkel. Simulering kan dessuten redusere utviklingstiden, ettersom det gjør det mulig å rette opp feil i applikasjonslogikken før de overføres til maskinvaren og dermed blir mye vanskeligere å rette opp.
Det finnes en rekke tilnærminger til robotsimulering. Tradisjonelt har simulering fokusert på kinematikken i robotbevegelser for å demonstrere om baner er gjennomførbare og praktiske.
Denne typen simulering plasserer en virtuell robot i et 3D-rom og demonstrerer hvordan leddene sannsynligvis vil bevege seg i den fysiske verden. Simuleringen kan også bidra til å avgjøre om roboten vil være i stand til å løfte og manipulere tunge eller uhåndterlige gjenstander uten å miste stabiliteten.
Noen kinematiske simulatorer bruker et forenklet sett med beregninger og fokuserer på hvordan et program kan rotere og flytte objekter for å sikre at de ikke kolliderer med grensene til et sikkerhetsbur eller en arbeidscelle. Andre innebærer mer komplekse fysikksimuleringer for å måle påkjenninger og andre forhold som kan påvirke robotens ytelse i felten.
Simulering av robotinteraksjoner i dynamiske miljøer
Når roboter beveger seg ut av kontrollerte miljøer beskyttet av sikkerhetsbur og inn i områder der mennesker og andre roboter kan bevege seg fritt, må designerne ta hensyn til mulige interaksjoner. Når det gjelder design av mobile roboter, kan simulatorer som håndterer atferd, gjøre det mulig for designere å skape virtuelle verdener som inneholder andre objekter, på et høyt abstraksjonsnivå. En enkel atferdssimulering tar bare hensyn til robotens bevegelse mellom et sett med faste objekter. Mer komplekse simuleringer innebærer bruk av flere mobile agenter eller avatarer. Disse atferdsbaserte simulatorene hjelper å designe applikasjoner der roboten sannsynligvis vil møte komplekse omgivelser. De kan lære av kollisjoner og andre interaksjoner for bedre å kunne håndtere hindringer. Fysikksimuleringer er viktige for å fastslå at robotens kinematikk er nøyaktig representert.
Velge riktig fysikkmotor for roboten din
Simuleringsmiljøer, som den åpne kildekodepakken Gazebo, kan generere realistiske sensordata som kan være korrumpert med ulike nivåer av støy. Gazebo gjør det mulig å tilpasse simuleringen til de spesifikke kravene i applikasjonen, for eksempel ved å bruke ulike fysikkmotorer. Ved simulering av uoversiktlige omgivelser velges ofte en maksimal koordinatløser som ODE eller Bullet. En Featherstone-basert løsning, som DART eller Simbody, vil finne flere anvendelser i leddede systemer som humanoide roboter eller komplekse produksjonsroboter. Alle fysikkmotorene er tilgjengelige via det samme programmeringsgrensesnittet (API).
Simulering har imidlertid sine begrensninger. Et program kan bare simulere egenskaper og hendelser som det er programmert for. Interne eller eksterne faktorer er ikke representert og vil ikke bli simulert, noe som kan føre til problemer når designet skal overføres til maskinvare. Det er også ofte vanskelig å lage tilstrekkelig representative scenarier, spesielt når det gjelder å evaluere komplekse situasjoner og atferd. Erfaringene med å oversette simulerte design til det fysiske miljøet kan imidlertid brukes i fremtidige prosjekter, noe som vil redusere antall feil med tiden.
Som et resultat av dette er simulering fortsatt et av de kraftigste verktøyene i robotingeniørens arsenal.
