• No results found

Iterativa metoder f¨ or inverterad kinematik

In document Hur är det att vara en robot? (Page 76-81)

A.7 Slutsatser

D.3.2 Iterativa metoder f¨ or inverterad kinematik

Ett annat alternativ ¨ar att anv¨anda en iterativ eller numerisk metod som letar sig fram till en giltig l¨osning. Iterativa metoder kan vara mer flexibla och l¨attare

att implementera men de kr¨aver generellt sett mer ber¨akningstid. Den mest popul¨ara metoden f¨or numerisk IK ¨ar att anv¨anda en s˚a kallad jacobimatris f¨or att hitta en linj¨ar approximation [54]. Ett annat exempel p˚a en iterativ algoritm f¨or inverterad kinematik ¨ar Forward And Backward Reaching Inverse Kinematics (FABRIK). FABRIK ¨ar l¨att att implementera och kr¨aver relativt f˚a iterationer f¨or att f˚a fram en l¨osning. [55]

D.4

Metod

F¨or att kontrollera roboten Peppers armar anv¨andes handkontrollerna till HTC Vive vilka gav koordinater i ett 3D-rum. D¨arf¨or beh¨ovdes n˚agon form av IK f¨or att f˚a fram vinklarna till lederna. Det fanns flera m¨ojliga val:

• Implementera en algoritm sj¨alva

• F¨ors¨oka hitta en f¨ardig implementation som var anpassad f¨or Peppers leder • F¨ors¨oka anpassa den implementationen som fanns inbyggd i Unity f¨or att

den skulle fungera f¨or det t¨ankta anv¨andningsomr˚adet

Implementationen p˚ab¨orjades med att f¨ors¨oka utnyttja Unitys inbyggda IK- system. F¨or att anv¨anda inverterad kinematik i Unity beh¨ovs en “Animator Controller” och en “Animator Component” som ¨ar en komponent som s¨atts p˚a det objekt anv¨ands som avatar [56]. Position och orientering l¨astes av fr˚an handkontrollerna och applicerades p˚a en 3D-modell som hittats p˚a Unity Asset Store. Unity r¨aknade automatiskt ut de n¨odv¨andiga vinklarna som l¨astes av fr˚an 3D-modellen och skickades till roboten genom Aldebarans API.

D.5

Resultat

Arbetet ledde s˚a sm˚aningom till fungerande styrning av Robotens armar. Vissa positioner gav resultat som inte s˚ag ut som de gjorde i Unity p˚a grund av bris- tande flexibilitet i Peppers leder. Lite linj¨ar algebra och trigonometri anv¨andes f¨or att projicera Unity-ledernas ¨andpunkter p˚a ett plan som var bundet till den ¨

ovre leden. Se Figur 14. ¨Andpunkterna fick d˚a 2D-koordinater (x, y) som kan r¨aknas om till en vinkel med arctan.

Figur 14: Hur vinklarna m¨attes inuti Unity

I Unity finns det en klass som heter Transform och som inneh˚aller position, ro- tation och skala f¨or ett Game Object. En s˚adan transform kan anv¨andas ungef¨ar som ett koordinatsystem som ¨ar bundet till objektet om man anv¨ander funk- tionen InverseTransformPoint som ¨overs¨atter en punkt fr˚an globala till lokala koordinater sett fr˚an objektet. Se Figur 15 f¨or ett exempel p˚a hur vinklarna r¨aknades ut, i det h¨ar fallet f¨or den v¨anstra armb˚agen.

Figur 15: Hur vinklarna r¨aknades ut Unity

D.6

Diskussion

Vi st¨otte p˚a en hel del problem under implementationen. Det f¨orsta problemet vi st¨otte p˚a var hur vi skulle f˚a Unitys animationssystem Mecanim att g¨ora som vi ville ¨overhuvudtaget. N¨ar vi till slut hade lyckats f˚a 3D-modellen att f¨olja v˚ara r¨orelser kom n¨asta problem med att l¨asa av vinklarna. Unitys system var inte anpassat f¨or att ge information tillbaka till programmeraren. Det var mer t¨ankt att ta en position och vrida 3D-modellens leder s˚a att den s˚ag ut att n˚a dem.

Ledernas orientation kunde l¨asas ut som kvaternioner eller eulervinklar men det enda vi egentligen var intresserade av var deras vinkel i f¨orh˚allande till leden ovanf¨or i hierarkin. Vi t¨ankte f¨orst att vi skulle kunna anv¨anda eulervinklar- na men i m˚anga fall ¨overensst¨amde deras referensaxlar inte s¨arskilt bra med robotens ledaxlar. Undantaget var handlederna d¨ar ett av vinkelv¨ardena fr˚an

eulervinklarna kunde anv¨andas direkt till robotens leder.

Ett tag funderade vi ¨over om vi skulle byta till en egen IK-implementation ist¨allet f¨or Unitys inbyggda. Vi hittade bland annat ett bibliotek skrivet i Pyt- hon som var anpassat just f¨or Pepper och fr˚an vilket man kunde f˚a ut vin- kelv¨arden direkt ist¨allet f¨or 3D-orientationer. Det hade gett oss st¨orre m¨ojlighet att p˚averka resultatet om vi inte var n¨ojda. Men eftersom det skulle inneb¨ara en hel del jobb och vi visste att det skulle g˚a att l¨asa ut de ¨onskade vinklarna p˚a n˚agot s¨att kom vi fram till att det kanske skulle vara on¨odigt.

Unitys animationssystem ¨ar anpassat f¨or att se bra ut inuti i ett spel och inte f¨or att kontrollera en robot. Vi var tvungna att g¨ora vissa “fulhack” f¨or att l¨asa av vinklar fr˚an resultatet som Unity r¨aknat ut och visat upp genom 3D-modellen vi anv¨ande. Till exempel anv¨ande vi i de flesta fall oss inte av ledernas orientering som l¨astes ut i kvaternioner utan genom att ledernas positioner m¨attes sett fr˚an andra leder h¨ogre upp i ledhierarkin.

Unitys system hade ocks˚a f˚a anpassningsm¨ojligheter f¨or att till exempel markera begr¨ansningar i r¨orelserna f¨or leder. Vilken metod f¨or inverterad kinematik som anv¨ands inuti Unity ¨ar tyv¨arr inte offentligt k¨ant men det skulle m¨ojligtvis kunna vara en iterativ metod som bygger p˚a en jacobimatris eftersom det ¨ar en s˚a pass v¨alk¨and metod.

Vi hade antagligen kunnat f˚a ett b¨attre resultat om man skrivit en egen im- plementation fr˚an grunden av exempelvis FABRIK eller n˚agon annan algoritm men det hade ocks˚a kr¨avt mer tid till implementation och fels¨okning.

Under projektet visade vi upp v˚art system p˚a KVIT-m¨assan. D¨ar fick flera personer prova p˚a hur det var att styra roboten. Fr˚an feedbacken vi fick verkade det som att robotens r¨orelser var tillr¨ackligt ¨overtygande f¨or att de som testade skulle k¨anna att robotens armar f¨oljde efter deras egna armar.

D.7

Slutsatser

Unitys inbyggda IK-system ¨ar fullt anv¨andbart f¨or enklare anv¨andningsomr˚aden, som v˚art, d¨ar det inte ¨ar extremt viktigt att r¨orelserna blir precisa. Om man har h¨ogre krav ¨ar det definitivt v¨art att se p˚a en mer avancerad l¨osning d¨ar man har mer kontroll ¨over resultatet.

E

Studie av dokumentation ¨over byggprocesser

i mjukvaruprojekt av Patrik Sletmo

Denna del av rapporten ¨ar skriven av Patrik Sletmo som agerade utvecklingsle- dare under projektet.

E.1

Inledning

Allt eftersom projekt utvecklas och underh˚alls h¨ander det att de byter ¨agare ibland. Personer som ansvarat f¨or stora delar av en komplex mjukvara kanske inte l¨angre arbetar p˚a f¨oretaget n¨ar det flera ˚ar senare beh¨over ses ¨over. Att ¨

overl¨amna ett projekt inneb¨ar f¨orutom att sj¨alva produkten l¨amnas ¨over ¨aven att kunskapen om det m˚aste ¨overf¨oras. Den h¨ar kunskapen inkluderar bland annat projektets struktur och hur det anv¨ands. Till vardags refereras den h¨ar kunskapen till som dokumentation.

E.1.1 Syfte

Det h¨ar individuella arbetet behandlar en av aspekterna i m¨ojligheten att vida- reutveckla ett projekt, n¨amligen steget fr˚an kod p˚a disk till en k¨orbar produkt. Syftet med arbetet ¨ar att unders¨oka inst¨allningen till dokumentation i mjukva- ruprojekt och hur v¨al den applicerats av studenter vid Link¨opings universitet.

In document Hur är det att vara en robot? (Page 76-81)