Spider Manufacturers (Maskin):
Denne uken har Spider Manufacturers utført FEM analyser på ulike komponenter. I tillegg har vi modellert og utført noen små endringer. Samtidig som vi har gjort de ytterste leddene av beina mer smidige.
Creepy Coders (Data):
Denne ukens highlight:
Veldig små skritt, men store fremskritt!
Vi har nå fått på plass et enkelt ganglag. Vi har ikke løst gåten med invers kinematikk enda, så vi har vært nødt til å se på en nødløsning. Denne løsningen ble å låse av den en servoen og bare rotere beinene i små buer. To grunner til at det blir så små skritt: For det første så er dette maks rekkevidde beinene har med den nåværende bunnplaten. Dette kan løses med å lage en lengre bunnplate. Den andre grunnen er at med å løse bevegelsen på denne måten, med å bare rotere benene så vil punktet som er i kontakt med bakken skape buer. Dette er ikke optimalt. Vi har fortsatt håp om å klare kode et mer fancy ganglag på den lille tiden vi har igjen. Uansett så har vi fremdrift nå 😀Det ble skrevet ganske mange linjer med kode denne uke så vi feirer med å lansere versjon 2.0 av koden: https://github.com/martintara/creepy/tree/creepy2.0/src
Individuelle innlegg
Ole Martin:
Denne uken har vært produktiv, vi har gjennomført den første vandringstesten. Vi oppdaget at de ytre delene av bena trenger å forlenges noe for å forbedre avstanden mellom batterikassen og komponentplaten. I tillegg bør batterikassen minskes og plasseres nærmere komponentplaten. Dette vil øke avstanden mellom bakken og batteriholderen.
Jeg har derfor produsert og tilpasset de ytre leddene i bena med en forlengelse på totalt 20 mm fordelt på begge deler. jeg måtte utføre en tilpasning av hullene til leddet mellom bena etter produksjon for å få en jevnere demping i fjærsystemet, uten at det oppstår hakking eller kilte seg fast.
I tillegg er det utført statiske analyser og topologioptimalisering for å oppnå optimal stivhet i forhold til vekten av delene. Simuleringene er utført under de samme posisjonsforholdene som roboten utsettes for i sin nåværende gangbevegelse.
Ut fra simuleringene ser vi muligheter for ytterligere optimalisering av delene, både med tanke på stivhet og vekt. Dette vil kunne effektivisere robotens strømforbruk samtidig som vi opprettholder en robust struktur.
Vinay:
Denne uken har jeg jobbet blant annet med FEM-analyse av modellen vår. Fokuset mitt er komponentholderen/bunnplaten med batteriholder og batteriet.
Her er ett bilde fra tidlig stadie, der jeg fokuserer på vektreduksjon, men samtidig opprettholder stivhet og styrke i platen.Her har jeg definert materialet som Akrylic (Medium-High impact), kreftene som er satt på er høyere enn behovet og målet var å redusere vekten med 10%:
Jeg har også modellert litt om på roboten vår. Blant annet ønsket Creepy Coders at mer klaring under roboten. Derfor designet jeg batteriplasseringen og økte klaringen med ca 20mm.
Dette gjorde jeg ved å lage 4 ører på selve batteriholderen, slik at vi får montert den direkte på undersiden av platen. Ved å gjøre dette slipper vi å ha bunnplaten som går på undersiden som igjen gjør at vi får mer klaring.
Denne skal produseres med 3D printing i PLA og vil være ferdig printet noen timer etter at denne bloggen blir lagt ut.
Dette er nye plasseringen til batteriet:
Creepy Coders ønsket også å øke avstanden mellom beina på roboten, noe som innebærer en lengre kropp/plate. Selv om det ikke er bestemt om denne lengre platen skal tas i bruk, måtte 3D-modellen tilpasses slik at Bjørn Ole kan laserkutte platen i akryl og ha den klar til rask bruk.
Her er bilde av den nye lange platen og nåværende plate for sammenligning:
Kristian:
Denne uka har jeg begynt på et av C-kravene, som er å lage en dekorativ radar antenne. Den gjør lite annet enn å snurre rundt, men den vil se veldig kul ut. For rotasjonen bruker jeg en SG90 motor som vi brukte på en gammel prototype. Det som gjenstår nå er noe for å holde søylen på plass og for å feste til selve roboten.
Martin:
Denne uken har hovedfokuset mitt ligget på å sette sammen alle delene av koden vår til et kjørbart program hvor vi lett kan teste forskjellige funksjoner. Delene jeg nå har “limt” sammen er raspberry pi’en, servomodulen, xbox kontrolleren og sense hat’en (LED-matrisen). Sånn systemet fungerer nå er følgene:
Systemet har nå forskjellige states. Første state er STARTUP: Her instrueres alle servoer til å bevege seg til initial positon. Deretter går systemet inn i neste state som heter IDLE. I IDLE står systemet bare å lytter på instrukser fra xbox kontrolleren. Herfra kan vi nå velge å gå inn i andre states. På dette tidspunktet så blir de resterende state’ene brukt til å teste forskjellig funksjonalitet.
Jeg har også flyttet “databasen” av servoinstrukser (en lang tekst i main.py) ut av main. Disse instruksene ligger nå i JSON filer utenfor programmet. Vi har nå funksjonalitet slik at vi kan laste inn nye instrukssett til servoene mens programmet kjører. Dette var nødvendig funksjonalitet vi oppdaget at vi trengte. Didrik snakker mer om kalibreringsprosessen.
Jeg har prøvd å ta til meg filosofien “Make it work, Make it beautiful, Make it fast”. Det måtte til et langt kodemaraton i helgen for å få programmet til å fungere. Det er langt ifra beautiful. Og git commit loggen er en skam (har mye å lære her med å bli mer systematisk, men i det minste lærer jeg masse!) Mye av funskjonaliteten burde nok trekkes ut av koden inn i mindre moduler. Koden fungerer, men den er ikke enormt oversiktlig og det finnes noen bugs. For eksempel er det vanskelig å skifte ut av en state hvis det foregår alt for mye i en loop. Hovedfokuset ligger ikke på å fikse bugs nå, men på å få roboten til å gå.
Jeg har fortsatt hovedansvar for å lage et ganglag basert på invers kinematikk. Jeg har enda ikke klart å forstå meg på hvordan jeg skal implementere dette i kode, men under prosessen med å finne ut av dette, kom jeg på at det kanskje ville være lurt å kunne sende antall grader jeg ønsker å sette en servo i (sånn det har fungert opp til nå er at vi har måtte sende et bestemt koordinat, disse koordinatene varierer fra servo til servo pga. hvordan de er kalibrert. Her startet da arbeidet om å implementere funksjonen angle_to_position i servo.py. Her oppdaget jeg at måtte til enda en runde med manuell testing med å mappe servoposisjoner opp mot vinkler. Jeg har testet og bekreftet at dette nå fungerer. Dette hadde en tricke-down effekt på koden Didrik har hatt ansvar for. Så i det minste så er koden hans beautiful nå.
Ida:
Denne uken har mye av tiden gått til prosjekter i andre fag, men jeg har sett litt på koden til led matrisen på roboten og eksperimentert litt med den. Jeg har også begynt å se på mulighet for simulering i Unity igjen og hvordan man kan bruke invers kinematikk der.
Didrik:
Denne uken så begynte jeg å kode opp et enkelt ganglag siden vi har kommet fram til at hvis vi skal få til et effektivt ganglag så må vi forstå oss på invers kinematikk, men det er komplekse saker så som en nødløsning lager vi et enkelt ganglag slik at A-kravet fortsatt kan fullføres.Senere i uken så fant vi ut at løsningen for et enkelt ganglag ikke var mulig slik vi hadde tenkt. Originalt hadde vi diskutert et ganglag hvor vi satte senterposition til de innerste servoene slik at servoene på hjørnene hadde samme offsett fra senter. (Enkel tegning for forklaring)
Men når vi prøvde det enkle ganglaget så var det tydelig at med et ganglag som kun bruker to grader av frihet så fører det til at beinene på kanten dytter i forskjellige retninger. Så for at vi skal kunne utføre et enkelt ganglag så må senterpositionen være parallell med hverandre. (Sånn her)
Men en slik løsning fører til en sterkt redusert skrittlengde, så maskin-gutta tenker å øke lengden på platen og lengden på beina for å hjelpe løsningen.Som også fører til at ting måtte rekalibreres igjen.
Senere for å forenkle koden vår så mappet jeg verdiene til servoene til angles.
Jeg impliminterte så funktionen move_to_angle som lar koden ta en angle istedenfor en verdi så den ble mye mer oversiktelig.
(Gammel)
(Ny)
Bjørn Ole:
Mye sykdom denne uken har begrenset arbeidsmengden for min del. Men jeg jobber med å lære meg hvordan all koden fungerer slik at jeg kan kjøre tester på systemet. Har også laget en oppdatert versjon av klasse-diagrammet, slik at dette er tilpasset den nåværende koden.