2. Robotic Software Architecture Flashcards
Questions during lecutre, Adrians part, week 36
Hvorfor trenger man en arkitektur for robot programvaresystemer?
Vi trenger en solid arkitektur fordi systemene vi arbeider med er svært komplekse. De må håndtere flere forskjellige sensorer og aktuatorer i sanntid, samtidig som de kontinuerlig justerer for usikkerheter i sensorene og støy fra omgivelsene. Må jobbe for å utføre oppgaver samtidig som det overvåker og reagerer på uventede situasjoner. Må gjøre alt dette samtidig og asynkront.
En god kombinasjon av arkitektur og programmeringsverktøy gjør det mulig å administrere denne kompleksiteten på en effektiv måte. Alle arkitekturer har sine styrker og svakheter, og det er viktig at vi forstår disse når vi skal velge den beste løsningen for vår applikasjon.
Robot specific: Sanntid, og asynkront, + kompleks.
Hva er det som skiller slike arkitekturer fra arkitekturer som er beregnet på andre “vanlige” programvaresystemer?
Sanntidshåndshåndtering, kompleks interaksjon med det fysiske miljøet og sensorbruk. De ulike komponentene samhandler asynkront.
Roboter trenger å kunne håndtere mer komplekse og dynamiske situasjoner.
“Vanlige” programvaresystemer har gjerne ikke samme krav til sanntidsrespons, og jobber med data som ofte ikke er knyttet til en fysisk virkelighet (databaser, nettsider etc). Interaksjon skjer gjennom tastatur/mus, og trenger oftest ikke ta hensyn til fysiske lover.
Hva er robot arkitektur og hva er forskjellen på struktur og stil?
Et arkitekturmønster er en generell, gjenbrukbar løsning på et vanlig problem innen programvarearkitektur i en gitt kontekst. Det ligner på designmønstre, men har et bredere omfang.
Struktur refererer til hvordan et system er delt inn i delsystemer og hvordan disse samhandler. Strukturen til et robotsystem representeres ofte uformelt med tradisjonelle boks- og pil-diagrammer eller mer formelt ved bruk av teknikker som Unified Modeling Language (UML).
Stil handler om de beregningsmessige konseptene som ligger til grunn for et gitt system. For eksempel:
Ett robotsystem kan bruke en publiser–abonner-meldingsoverføring,
mens et annet kan bruke en mer synkron klient–server-tilnærming.
De første robot arkitekturene for robot systemer var SPA og Subsumption, forklar kort disse, og hvilke utfordringer kan bruk av slike arkitekturer føre til?
SPA: Hierarkisk og sekvensiell. Samler informasjon fra sensorer(Sense), analyserer og planlegger(Plan), utfører handling (Act) basert på planne. Klassisk tilnærming for roboter som opererer i veldefinerte og strukturerte miljøer.
> Siden alle handlinger må planlegges før utførelse, kan det oppstå forsinkelser, spesielt i dynamiske miljøer.
> Replanlegging tar tid.
> Kan være til fare for mennesker.
Subsumption: Reaktive, basert på tilstandsmaskiner. Deler robotens oppførsel inn i lag. Hver lag er ansvarlig for enkle, selvstendige handlinger. De mer komplekse lagene kan override enklere lag når det er nødvendig, f.eks for å styre vekk fra en hindring.
> Subsumption mangler langsiktig planlegging, og kan være vanskelig å tilpase komplekse miljøer med mange variabler.
SPA = Sense, plan, act
Subsumption: Ofte referert til som “behavioural robotics”
Hva er lagbasert arkitektur? Nevn noen eksempler, fordeler, ulemper osv.
Lagbasert arkitektur deler systemet inn i separate “lag”, der hvert lag er ansvarlig for en spesifikk funksjon eller et sett med funksjoner, og kommunikasjonen skjer mellom de ulike lagene. Dette gjør det enklere å administrere kompleksiteten ved større systemer, samtidig som det gir fordeler som modularitet, skalerbarhet og enklere vedlikehold.
Fordeler:
> Modularitet og gjenbruk; Når lagene er isolvert fra hverandre er det enklere å bytte ut eller endre et spesifikt lag uten å påvirke andre lag. Dette gjør også at man gjenbruke funksjoner og tjenester definert i et lag, i flere sammenhenger.
> Testing: Systemet kan testes lag for lag, som gjør det lettere å isolere feil.
MVC, OSI, Trelags arkitektur
Forklar kort lagene i 3 lags arkitekturen Planning, Executive, Behaviour
Planning: Ansvar for å oppnå langsiktig mål, med ressursene som er tilgjengelig. Optimalisering, prioritering, scheduling, lading.
Dekomponere til lavnivå tasks.
Ofte er Planning og Executive satt sammen.
Executive: Interface mellom numeriske behaviour kontrollaget, og det symbolske planlegginsgslaget til riktige tidspunkt, og håndtere unntak. Ansvar for å velge neste oppførsel basert på hva som nettopp skjedde, for at roboten skal oppnå en handling. Dvs oversette høynivå planer til lavnivå behaviours, starte behaviours på riktige tider. HVORDAN oppnå mål istedet for HVA trenger å gjøres. Høynivå plan = levere post, dekomponere til subtasks; path planner, dersom dør funnet -> åpne, let etter kontornummer, dersom ikke finner-> håndter.
Behaviour (laveste): Direkte koblet til sensorer og aktuatorer. Kortsiktig for en bestemt behaviour. Beveg robot, unngå hindringer, åpne dør.
Valg av kommunikasjonsmåte er meget viktig i robot programvarearkitekturer, hvorfor?
Lag/komponenter må kunne kommunsere/utveksle data som gir mening.
Når metoden først er bestemt, er den vanskelig å endre senere.
Fordelen med å velge ferdig definerte metoder er at vanlige feil er eliminert, men det kan være utfordrende å tilpasse tilstrekkelig til sitt bruk.
To basic approaches: Client-server, publish-subscribe.
** Denne kan utdjupast sikkert, han sa ikkje noko spesielt i forelesning, har ikkje sjekka pre-recorded video**.
Forklar kort client-server og publish-subscribe. Diss er tilnærminger for å kommunisere mellom komponenter/lag i ark.
To ulike tilnærminger for kommunikasjon mellom komponenter/lag i en arkitektur.
Client-server: En enhet fungerer som klient (sender forespørsler), og en annen som server (behandler forespørsler og sender svar tilbake). Klienten ber om data eller tjenester, og serveren leverer dem. F.eks: En nettleser sender en HTTP forespørsel til en webserver som svarer med nettsiden.
> RPC
> CORBA
> Ulempe: Endel overhead. Feks dersom flere klienter sender samme request samtidig.
Publish-subscribe: En publisher publiserer meldinger uten å vite hvem som abbonnerer/mottar dem. Subscribers abbonnerer på spesifikke type meldinger, og mottar dem når de publiseres.
Dette gir god fleksibilitet siden Publisherser og Subscribers ikke trenger å vite om hverandre direkte. F.eks: Et nyhetsbrev system der brukere abonnerer på oppdateringer, mottar alle abonnentene meldingen.
Ulempe: Vanskelig å debugge og feil oppfattes ikke før kjøretid, og flaskehals pga single point of failure.
RPC = Remote Procedure Calls
CORBA: Kan kalle metoder implementert av andre komponenter.
Forklar kort HTN (Hierarchical Task Net) og Planner/scheduler. Disse er forskjellige måter å planlegge en mission på, hva er fordelene og ulempene med de?
HTN er en tilnærming der en stor oppgave (“mission”) brytes ned i mindre og mer konkrete deloppgaver, strukturert i et hierarki. Hver deloppgave kan videre brytes ned inntil den blir til enkle handlinger som kan utføres direkte.
Fordel: Kan organisere komplekse oppgaver på en hierarkisk måte.
Ulempe: Kan være krevende å lage pga design av hierarki og dekoponere oppgaver, og fastlagte hierarkier kan gjøre systemet mindre fleksibelt/robust mot uforutsette situasjoner.
Panner/scheduler: En planner/scheduler fokuserer på å finne den optimale sekvensen av handlinger for å nå et mål, ofte med begrensninger som tid, ressurser eller prioriteringer. Den søker etter en løsning fra en liste med mulige handlinger, basert på optimalisering av kriterier.
Best når ressurser er begrenset.
Fordel: Planen kan tilpasses dynamisk basert på endringer i miljøet.
Ulempe: Krever mer beregning pga optimaliseringsprosesser som krever mer ressurser. Systmet kan bli komplisert og vanskelig å administrere.
Robot arkitektur → Kunst. Hvorfor? Finnes det guidelines for denne prosessen? Hvilke spørsmål bør du ha svar på for å kunne velge best mulig arkitektur? Hva er de neste stegene når du har svart på disse spørsmålene?
Tenk hypotetisk sett, pga vi blir ikke utsatt for dette valget da valget er tatt for oss.
Robot arkitektur er sagt å være som kunst, fordi det er ikke en eksagt science. Valg av arkitektur vil bli påvirket av tidligere erfaringer på teamet, roboten og dets miljø, og hvilke oppgaver roboten skal utføre.
Det finnes et sett spørsmål man kan ta stilling til for å lette valget:
1. Oppgavetype;
2. Actions;
3. Data;
4. Computational capabilities;
5. Robot Users; hvem skal kunne bruke roboten
6. Robot evaluation;
7. Architecture reusability; Er det nyttig å kunne gjenbruke i senere prosjekter?
Hva er service robots? Nevn noen utfordringer og forskjeller i forhold til utvikling av programvare for SR?
Roboter som utfører nyttige oppgaver for mennesker (sett bort ifra industrielle roboter). Robotene brukes ofte i miljøer som sykehus, hotell, kontorer, butikker, på gata (levere mat) og andre offentlige steder.
Vanlige oppgaver kan være renhold, transport, medisinlevering, eller gi informasjon og assistanse.
Utfordringer er at disse robotene må være tilpasset å opptre i samme miljø som mennesker. Dette er mye mer kompleks enn en industri robot som utfører en spesifikk oppgave, hvor den ikke risikerer at mennesker kommer i “veien”.
Videre må robotene operere autonomt over lengre tid, og ta beslutninger basert på ulike og uforutsigbare situasjoner.
Cue: Sikkerhet og tillit.
Diskuter figuren. Kan du plassere ditt eget prosjekt i denne figuren?
Naj
Hvordan tolker du tabellen på neste slide? Hva kan du si om feks problemkategorien Distributed Resource Access og egenheten av SOA som en tilnærming?
Figuren på neste slide oppsummerer utviklingen av robotikk ark frem til 2016. Hvordan ser du for deg denne utviklingen hvis du utvider survey til 2024?
