Hur kan en typisk ingenjörsuppgift se ut?

Tjenis!

Man hör ofta beskrivningar om hur det är att vara ingenjör, vad målet med ens arbete är (exempelvis simulera robotar på Mars), men om man inte arbetat som ingenjör är det svårt att veta vad det faktiskt innebär. Iallafall tyckte jag det innan jag började plugga, jag hade ingen aning. I det här inlägget vill jag därför skriva om något som är lite mer tekniskt än vanligt och försöka beskriva hur en typisk arbetsuppgift som ingenjör kan se ut!

Om du inte förstår det som står här nedanför beror det till 100% på att du inte borde förstå något till fullo efter att bara ha läst om det i ett blogginlägg. Tro mig. Syftet med det här inlägget är bara att visa hur ett problem kan se ut och hur man kan lösa det!

Idag hade jag en såndär typisk ingenjörsuppgift, en liten kluring. Om ni har läst den här bloggen vet ni att jag jobbar med simulering av robotar som ser ut såhär:

De gula, oranga och lila pinnarna är stänger (av exempelvis aluminium), och de svarta snörena som förbinder dem är kablar som går att dra ut och in. Genom att göra det tippar roboten över, och på så vis har den rört sig framåt. Det ni ser på bilden ovan är visualiseringen av simuleringen, men det är vääääldigt mycket kod som körs i bakgrunden för att få allting att funka. Här är ett kort utdrag från koden (som är skriven i C++ ifall någon är intresserad):

Det som ses här i koden är en del av hur roboten ska se ut. Man måste tala om för simuleringen vart man vill ha stänger och vart man vill ha kablar osv. Först skapar man ‘noder’, vilket i det här fallet är 24 st punkter som svävar fritt i simuleringen. Dessa punkter kommer att bli änden på stängerna där kablarna är fastsatta.

Jag trollade lite med hjälp av paint för att sätta in de fina lila pilarna med kommentarer för att kunna förklara den översta delen av koden. Varje rad beskriver en nod, och för att skapa den används funktionen ‘s.addNode’. Efter det följer nodens position i x, y och z, och allt avslutas sedan med en kommentar i blått som berättar vilket nodnummer just den specifika noden har.

Nästa steg är att skapa stängerna, och det gör man genom att koppla ihop noderna i två och två.

Det här är undre delen av koden, och visar först funktionen som används (s.addPair). Sen följer numret på de noder man vill koppla ihop, den understa raden kopplar exempelvis ihop noderna 22 och 23. “rod” är det ordet vi använder när vi vill ha en stång där.

På liknande sätt kopplas kablarna ihop, fast med ordet “cable” istället för “rod”.

Voila! Vi har en robot!

Vad var då problemet jag fick lösa idag?

Jag ville testa ett nytt sorts rörelsemönster genom att programmera roboten att dra i dessa lila kablarna här.

Hittills när jag har kört mina simuleringar, har det inte riktigt spelat någon roll vilken nod som är vilken. Jag har alltså inte behövt veta vilket nummer som hör till vilken nod.

Idag behövde jag det. Jag ville veta exakt vilket nummer kablarna i blått hade.

Problemet är att programmet jag använder inte visar det i visualiseringen. Man har alltså inget sätt att på en bild kunna se framför sig vilken nod som är vilken.

Vad gör en ingenjör då? Man får försöka klura ut det själv!

Till min hjälp hade jag bilderna på simuleringen och koden ovan, samt dessa två 3D-printade modellerna av min robot.

Båda modellerna föreställer roboten som syns i simuleringen. Den lilla vita till höger är precis likadan (förutom färgerna), och den stora grå till vänster är en lite enklare variant där alla ytor är täckta. När roboten faktiskt är byggd på riktigt kommer den aldrig att se ut så, men då man ofta pratar om ytorna på roboten hjälper den att visualisera exakt vad man pratar om. Exempelvis kanske man säger “nu står roboten på ytan som består av noderna 8, 16, 18 och 4”, och då kan man enkelt se hur den står.

Jag tänkte inte på att ta kort på modellerna innan jag redan var klar med uppgiften, så det som synes ovan är modellen med nodnummer utsatta. I början av dagen var den grå modellen alltså helt utan klisterlappar, med andra ord inte till så mycket hjälp när man vill se vilken yta som är vilken.

Här nedan kommer en steg-för-steg-lista på hur jag löste detta problemet. Det kanske inte är jätteintressant att veta tycker du, men det jag vill visa med det här är arbetsmetoden! Det är nämligen precis såhär man ofta får jobba. Att först hitta små delmål och att sedan systematiskt hitta lösningen på dem. Oftast är problemen mer komplicerade än just det här exemplet, men tänket är detsamma! (Och allt det där komplicerade lär man sig att handskas med när man pluggar. Inget att oroa sig för. :)

Steg 1: Lista ut hur koordinatsystemet i bilden är riktat

Jag vet ju x, y, och z-positionerna på mina noder. Jag visste att y var uppåt, men jag vet inte riktigt vilket håll som är x och vilket som är z. I koden nedan kan man se att nod nummer 0, 2 och 4 har position y = 0, och eftersom y är höjd över marken måste det betyda att de tre noderna står på marken.

Nod 0, 2 och 4 måste alltså vara de tre inringade noderna på bilden.

Genom att studera hur de tre noderna förhåller sig till varandra i bilden, och att kolla på vilka koordinater de har i koden, kunde jag sluta mig till att koordinatsystemet måste vara riktat såhär:

Steg 2: Hitta nod nummer 0

I princip alltid när man programmerar benämner man den första saken som nummer 0, och inte nummer 1. Det är förvirrande i början, men något man får acceptera. Andra uppgiften var alltså att hitta den första noden, nod nummer 0.

Jag visste ju redan att det var någon av dessa tre:

Återigen, genom att jämföra bilden med koordinaterna kunde jag sluta mig till att den oranga stången längst till höger hade nod nummer 0 i marken.

Det här var den svåraste biten!

Steg 3: Hitta resten av noderna

Från den här delen av koden visste jag att att nod nummer 0 och nod nummer 1 var sammankopplade med en stång. När jag listade ut vilken nod som var nummer 0, visste jag också automatiskt vilken nod som var nummer 1 också!

Efter det listade jag också ut vilken av de andra två inringade noderna som var nummer 2 och vilken som var nummer 4, och eftersom de var sammankopplade med en stång till noderna 3 och 5, hade jag helt plötsligt sex stycken noder klara!

För varje nod jag hittade, satte jag en tejpbit på den grå modellen. Men hjälp av uteslutningsmetoden hade jag till slut alla noder, vilket hjälpte mig att kunna dra i rätt kablar! Såhär såg det ut när det var klart:

De gröna klisterlapparna representerar noder, de röda representerar kabelnummer och de blå representerar de fyrkantiga ytorna som jag var intresserad av idag! Det kanske verkar lite löjligt, men modellen kommer att hjälpa mig hela projektet och gör det mycket lättare att programmera roboten.

Det här tog mig kanske en timme att lista ut, vilket ju är en väldigt liten del av en arbetsdag. Om man jobbar som ingenjör består dagen av många, små problem som detta. Tills slut har man löst så många delproblem att det sammanlagt blir ett helt projekt.

Om du gillar utmaningar och att få tänka till, så passar ingenjörsyrket dig!