Sådan implementeres humanoide robotter i produktion uden robotikingeniører

Motions Field Deployment Engineers træner robotten i jeres opgaver og træner jeres team til at arbejde sammen med den – udrul og skaler uden robotteknikere ansat.

Motion1 Inc. · 2026-05-18

Fremstillingssektoren står over for et paradoks. Efterspørgslen efter automatisering har aldrig været højere, men ingeniørerne, der skal implementere den, har aldrig været sværere at finde. Humanoide robotter – generelle maskiner, der kan navigere i menneskedesignede arbejdsområder og udføre en bred vifte af fysiske opgaver – indtager fabrikkerne i et accelererende tempo. De er det hidtil klareste eksempel på fysisk AI: kunstig intelligens, der opfatter, beslutter og handler i den fysiske verden snarere end på en skærm. Men den traditionelle deployment model antager noget, de fleste producenter simpelthen ikke har: et team af robotteknikingeniører.

Den antagelse er ved at ændre sig. En ny deployment model gør det muligt for domæneeksperter – fabrikschefer, procesingeniører og driftsledere, der forstår arbejdet – at sætte humanoide robotter i drift uden at ansætte et robotteam. Field Deployment Engineers træner robotten i de opgaver, disse eksperter definerer, og træner deres operatører til at arbejde sammen med den. Denne artikel forklarer, hvordan det fungerer, hvad det kræver, og hvad producenter bør vide, før de går i gang.

---

Manglen på robotteknisk talent: Hvorfor det er næsten umuligt at finde ingeniører

Den globale mangel på robotteknikingeniører er ikke en midlertidig ansættelsesudfordring. Det er en strukturel begrænsning. Universiteter producerer en brøkdel af de specialister, markedet efterspørger, og de, der dimitterer, absorberes overvældende af teknologivirksomheder, forsvarsentreprenører og forskningslaboratorier. Fremstillingssektoren – især små og mellemstore virksomheder – er overladt til at konkurrere om en talentpulje, der knap nok eksisterer.

Ifølge analyser af industriens arbejdsstyrke er kløften mellem åbne robotteknikstillinger og kvalificerede kandidater blevet større hvert år siden 2022. I Vesteuropa er situationen særligt akut: aldrende arbejdsstyrker, faldende tilmelding til tekniske uddannelser og intens grænseoverskridende konkurrence om talent betyder, at en mellemstor producent i Tyskland eller Holland kan vente tolv måneder eller mere på at besætte en enkelt robotteknikstilling.

Denne talentmangel bremser ikke kun adoptionen. Den skaber en afhængighed. Producenter, der lykkes med at ansætte en robotteknikingeniør, bliver operationelt afhængige af den enkelte. Når de forlader virksomheden – og på et så konkurrencepræget marked gør de det ofte – går hele automatiseringsprogrammet i stå.

Konklusionen er ligetil: hvis implementering af humanoide robotter kræver robotteknikingeniører, vil de fleste producenter aldrig implementere dem. Industrien har brug for en anden model.

---

Den gamle måde vs. den nye måde: At skrive kode vs. at træne robotten

Traditionel robotprogrammering er en specialiseret disciplin. Det involverer at skrive bevægelsesplaner i sprog som Python eller C++, konfigurere sensorintegrationer, finjustere kontrolsløjfer, bygge tilstandsmaskiner og fejlfinde adfærd i simulering, før det overføres til hardware. Hver robotplatform har sit eget SDK, sine egne konventioner og sine egne fejltyper. Selv erfarne softwareingeniører står over for en stejl indlæringskurve, når de bevæger sig ind i robotteknik.

Dette er den gamle måde: skriv kode, kompilér, simuler, test, deploy, fejlfind, gentag. Det virker, men det kræver ekspertise, som de fleste producenter ikke har adgang til.

Den nye måde erstatter internt robotarbejde med en deployed service. I stedet for at skrive en bevægelsesplan beskriver en fabrikschef jobbet til en Field Deployment Engineer, som træner robotten i den opgave, indtil den udfører den autonomt. En AI Workflow Builder konfigurerer hver workflow og integrerer humanoiden i den specifikke use case, og hver workflow valideres i simulering, før den når gulvet. Domæneeksperten bevarer kontrollen over, hvad robotten gør. Deployment teamet håndterer, hvordan den gør det.

Dette er ikke en forenkling af den gamle proces. Det er en fundamentalt anderledes arbejdsdeling. Den person, der forstår fremstillingsprocessen, behøver ikke længere at ansætte og fastholde en robotteknikingeniør for at få en maskine på linjen. Den ekspertise ankommer med deployment og forbliver der.

---

Hvordan AI Workflow Builder konfigurerer en robotopgave

AI Workflow Builder er et softwarelag, der sidder mellem kundens use case og robothardwaren. Field Deployment Engineers bruger det til at udføre flere funktioner, der tidligere var det eksklusive domæne for et internt ingeniørteam:

• Opgaveindfangning. Arbejdet starter fra kundens egen beskrivelse af jobbet – "Saml komponenten op fra transportbåndet, inspicér den visuelt, og placer den i den passende beholder baseret på kvalitetsgrad" – sammen med egocentriske optagelser af operatører, der udfører det. Builder'en dekomponerer dette til en struktureret sekvens af handlinger, robotten kan udføre.
• Bevægelsesplanlægning. For hver handling i sekvensen genererer platformen bevægelsesplaner, der tager højde for robottens fysiske kapaciteter, arbejdsområdets geometri, undgåelse af forhindringer og effektivitetsbegrænsninger. Dette er det arbejde, der traditionelt krævede en styringsingenør med dyb viden om kinematik og dynamik.
• Sensorintegration. Moderne humanoide robotter er udstyret med kameraer, kraftsensorer, LiDAR og andre perceptionssystemer. Workflow Builder konfigurerer, hvordan disse sensorer bruges til hver opgave – hvilke kamerafeeds der skal behandles, hvilke krafttærskler der skal indstilles, hvordan visuelle data skal fortolkes til kvalitetsinspektion – uden at producenten skriver en linje integrationskode.
• Validering og sikkerhedskontrol. Før en opgave når den fysiske robot, kører platformen den gennem simulering og sikkerhedsvalidering. Den kontrollerer for kollisioner, verificerer at kraftgrænser er inden for sikre områder, sikrer at opgavesekvensen er komplet, og markerer potentielle problemer til menneskelig gennemgang.
• Kontinuerlig læring. Mens robotten udfører opgaver, indsamler platformen præstationsdata og bruger dem til at forfine, hvordan fremtidige workflows konfigureres. Over tid bliver systemet bedre til at håndtere det specifikke layout, delmix og den operationelle kontekst for hvert anlæg. Disse data forbliver kundens.

Resultatet er et system, hvor robotteknisk ekspertise ligger hos platformen og deployment teamet, ikke på fabrikkens lønningsliste. Kunden leverer domæneviden – hvad der skal ske på fabriksgulvet. Motion leverer robotteknisk viden – hvordan man får det til at ske sikkert og effektivt.

---

Fra beskrevet opgave til robotaktion: Implementeringspipelinen

Processen med at gå fra en beskrevet opgave til en deployed robotopgave følger typisk en konsekvent pipeline:

• Trin 1: Opgaveindfangning. Operatøren beskriver opgaven og, hvor det hjælper, optages mens den udføres. Beskrivelsen kan være så overordnet som "sorter indgående dele efter størrelse" eller så specifik som "saml genstande op fra position A, roter 90 grader, og placer dem i position B med etiketten opad." Field Deployment Engineer arbejder ud fra både beskrivelsen og optagelsen og vender tilbage til operatøren, når jobbet er tvetydigt.
• Trin 2: Opgavedekomponering. Workflow Builder opdeler opgaven i diskrete, eksekverbare trin. For en sorteringsopgave kan dette omfatte: nærme sig transportbånd, identificere del, måle dimensioner, klassificere efter størrelseskategori, samle op, navigere til korrekt beholder, placere. Hvert trin er knyttet til robottens kapaciteter.
• Trin 3: Simulering. Hele opgavesekvensen kører i en digital tvilling af arbejdsområdet. Operatøren kan se den simulerede udførelse, identificere problemer og forfine opgavebeskrivelsen. Det er her, de fleste fejl fanges – før den fysiske robot overhovedet bevæger sig.
• Trin 4: Menneskelig gennemgang og godkendelse. Platformen præsenterer den validerede opgaveplan for operatøren til godkendelse. Kritiske parametre – hastighedsgrænser, krafttærskler, udelukkelseszoner – fremhæves for eksplicit bekræftelse. Intet deployes uden menneskelig godkendelse.
• Trin 5: Deployment. Den godkendte opgave sendes til robotten. Udførelsen begynder med øget overvågning. Platformen sporer ydeevne i realtid og kan automatisk sætte robotten på pause, hvis der registreres anomalier.
• Trin 6: Iteration. Baseret på ydeevne i den virkelige verden forfines opgaven. "Sæt farten ned under placeringssteppet" eller "tilføj en pause efter inspektion for manuel tilsidesættelse" er den slags justeringer, der tidligere krævede, at en intern ingeniør omskrev kode. Nu er de en anmodning til deployment teamet, anvendt i Workflow Builder og re-valideret i simulering, før ændringen når gulvet.

---

Hvad "Ingen robotteknisk ekspertise påkrævet" faktisk betyder i praksis

Det er vigtigt at være præcis omkring denne påstand. "Ingen robotteknisk ekspertise påkrævet" betyder ikke "ingen ekspertise påkrævet." Effektiv implementering af humanoide robotter kræver stadig dyb viden – det er bare en anden form for viden.

De personer, der er bedst positioneret til at implementere robotter i et produktionsmiljø, er de personer, der allerede forstår det miljø: procesingeniører, der kender workflowet, kvalitetschefer, der forstår inspektionskriterier, driftsledere, der ved, hvor flaskehalse opstår, og hvor automatisering tilføjer mest værdi.

Hvad de ikke behøver at vide, er hvordan man skriver ROS-noder, tuner PID-controllere eller konfigurerer URDF-modeller. De behøver ikke at forstå invers kinematik eller skrive computer vision-pipelines. Motions Field Deployment Engineers og Workflow Builder håndterer alt det.

I praksis betyder "ingen robotteknisk ekspertise påkrævet":

• Ingen programmering. Opgaver beskrives af de personer, der udfører dem, og konfigureres derefter i Workflow Builder af Field Deployment Engineers.
• Ingen maskinteknik. Platformen håndterer bevægelsesplanlægning og fysiske begrænsninger.
• Ingen datalogiuddannelse. Sensorintegration, perception og beslutningslogik styres af platformen og deployment teamet.
• Domæneekspertise er afgørende. Operatøren skal forstå fremstillingsprocessen, kvalitetsstandarder, sikkerhedskrav og operationel kontekst. Denne viden kan ikke outsources – det er den input, hele deployment afhænger af.

Skiftet er fra robotteknisk ekspertise til procesekspertise. De mennesker, der er tættest på arbejdet, bliver de mennesker, robotten trænes omkring, og de mennesker, der beslutter, hvad den skal gøre næste gang.

---

Simuleringens og digitale tvillingers rolle

Simulering er ikke valgfrit i denne model – det er fundamentalt. Når fabrikken ikke har en robotteknikingeniør ansat, har du brug for en mekanisme til at fange fejl, før de når den fysiske verden. Den mekanisme er den digitale tvilling.

En digital tvilling er en virtuel replika af det fysiske arbejdsområde – fabriksgulvet, transportsystemerne, lagerområderne, selve robotten. Workflows bygget til robotten udføres først i dette virtuelle miljø, hvor fejl er omkostningsfrie, og iteration er hurtig.

For producenter, der deployer uden robotteknikingeniører, giver den digitale tvilling flere kritiske funktioner:

• Risikofri eksperimentering. Operatører kan prøve forskellige opgavekonfigurationer, teste edge cases og udforske "hvad nu hvis"-scenarier uden nogen risiko for udstyr, produkter eller personale.
• Visuel validering. Ikke-tekniske operatører kan se den simulerede opgave og straks se, om robotten gør, hvad de havde til hensigt. Denne visuelle feedback-loop erstatter den kodegennemgang, som en intern ingeniør normalt ville udføre.
• Ydeevnebenchmarking. Simuleringen giver estimater for cyklustid, identificerer potentielle flaskehalse og hjælper operatører med at optimere opgavesekvenser, før de forpligter sig til fysisk deployment.
• Generering af træningsdata. Simuleringsmiljøet genererer syntetiske data, der forbedrer AI'ens evne til at håndtere variationer i den virkelige verden – forskellige delorienteringer, lysforhold eller uventede forhindringer.

Kvaliteten af den digitale tvilling påvirker direkte pålideligheden af deployment. Førende platforme investerer massivt i fysiknøjagtige simuleringsmotorer, der modellerer ikke kun geometri, men også materialegenskaber, friktion, deformation og sensorstøj. Jo tættere tvillingen matcher virkeligheden, desto færre overraskelser opstår der under fysisk deployment.

---

Læringsstakken: VLA'er, verdensmodeller og forstærkende læring

Hvorfor er alt dette muligt nu, når det ikke var det for fem år siden? Fordi den måde, robotter lærer på, har ændret sig. Tre ingredienser, hver et offentligt forskningsgennembrud fra de seneste år, får deployment modellen til at fungere:

• Vision-language-action-modeller (VLA'er). En VLA er et enkelt neuralt netværk, der modtager, hvad robotten ser, og en beskrivelse af opgaven, og udsender motorkommandoerne til at udføre den. Dette er teknologien bag hele "vis, ikke program"-skiftet: fordi modellen forbinder perception, sprog og handling direkte, kan en robot trænes ud fra demonstrationer af en opgave snarere end programmeres med håndskrevet bevægelses-kode. Det er grunden til, at en operatørs førstepersonsoptagelser overhovedet er nyttigt træningsmateriale.
• Verdensmodeller. En verdensmodel er et AI-system, der har lært, hvordan en fysisk scene opfører sig – hvordan objekter bevæger sig, falder, stables og reagerer på kontakt. Verdensmodeller er det, der gør digitale tvillinger til mere end smukke animationer: robotten kan øve en opgave gennem tusindvis af simulerede variationer, herunder situationer, der aldrig opstod i optagelserne, fordi simuleringen forudsiger plausibel fysik snarere end at afspille faste scripts.
• Forstærkende læring. Demonstrationer giver robotten en startadfærd; forstærkende læring skærper den. I simulering forsøger robotten opgaven igen og igen, scores mod de kriterier, der betyder noget – succesrate, cyklustid, sikre kraftgrænser – og opdaterer sig selv mod det, der scorer godt. Det er sådan, en adfærd går fra "omtrent hvad mennesket viste" til pålidelig i produktionskvalitet, og hvordan den fortsætter med at forbedre sig fra de assisterede kørsler under deployment.

Ingen af disse teknikker tilhører et enkelt firma – de er den nuværende state of the art inden for robotlæring. Hvad der betyder noget for en producent er, at de tilsammen erstatter det, der plejede at være flaskehalsen: en ingeniør, der skriver opgavespecifik kode. Robotten lærer opgaven; ingeniørerne, der besøger dit anlæg, er der for at lære den, ikke for at programmere den.

---

Teleoperation: Broen fra simulering til autonomi

Simulering fanger de fleste fejl, men ingen digital tvilling forudsiger alt, hvad en rigtig produktionsdag kaster efter en robot. Det hul lukkes på gulvet. Under deployment teleopererer ingeniører humanoiden gennem de edge cases, simuleringen ikke fuldt ud kunne forudse – den fejlmarkerede del, den skæve palle, den tote, der ankommer halvt åben.

Teleoperation udfører to opgaver på én gang. Den holder linjen i gang, mens robotten stadig lærer, fordi et menneske er involveret i præcis de situationer, robotten endnu ikke kan håndtere alene. Og den genererer de mest værdifulde træningsdata, der findes: hver assisteret kørsel er en demonstration af den korrekte adfærd, der foldes tilbage i robottens færdigheder. I løbet af en deployment skifter balancen – assisterede kørsler bliver sjældnere, autonome kørsler bliver normen, indtil robotten står på egne ben.

Intet af dette kræver, at nogen af kundens medarbejdere betjener en robot. Teleoperationen, ligesom resten af robotarbejdet, ankommer med deployment teamet og efterlader en robot, der ikke længere har brug for det.

---

Implementering i den virkelige verden: Hvordan processen ser ud uden ingeniører

Her er, hvordan en typisk integrationsmission ser ud for en mellemstor producent uden en robotteknikingeniør ansat:

• Uge 1-2: Stedvurdering og arbejdsområdekortlægning. Deployment teamet udfører en stedvurdering – på stedet eller eksternt ved hjælp af 3D-scanning. Det fysiske arbejdsområde digitaliseres for at skabe den digitale tvilling, og de vigtigste workflows dokumenteres og prioriteres.
• Uge 3-4: Hardwareinstallation og opgaveindfangning. Den humanoide robot leveres og installeres fysisk af deployment teamet, ligesom industrielle udstyrsleverandører håndterer installation i dag. Parallelt beskriver operatører deres opgaver og optages, mens de udfører dem – råmaterialet, træningen starter fra. Der er ikke behov for løbende ingeniørpersonale.
• Uge 5-10: Træning, simulering og assisteret drift. Field Deployment Engineers træner robotten i kundens opgaver, startende med de enkleste og mest gentagne. Hver workflow øves i den digitale tvilling, gennemgås af operations teamet og forfines, før den når gulvet. På selve gulvet teleopererer ingeniører robotten gennem de resterende edge cases, og hver assisteret kørsel skubber opgaven tættere på autonomi. De første opgaver er typisk pick-and-place, palletering eller grundlæggende materialehåndtering – højvolumen, lav-variabilitetsarbejde, der leverer øjeblikkelig ROI.
• Uge 11-15: Autonomi-overdragelse og optimering. Assisterede kørsler aftager, efterhånden som robotten overtager. Teamet udvider til mere komplekse workflows – inspektionsopgaver, kitting operations, machine tending – og operatører trænes i hver enkelt, efterhånden som den går live. Præstationsdata fra tidlige opgaver forbedrer nøjagtigheden for efterfølgende opgaver.
• Løbende: Overvågning og iteration. Fleet platformen sporer opgavepræstation, robotudnyttelse, fejlfrekvenser og vedligeholdelsesalarmer. Operations staff flagger ændringer, efterhånden som produktionskravene skifter – en ny produktlinje, et modificeret workflow, et sæsonbestemt volumenforskydning. Disse justeringer foretages i Workflow Builder og re-valideres i simulering, uden at fabrikken ansætter en ingeniør.

Gennem hele missionen følger kunden fremskridt og giver alle godkendelser i en sikker online portal, ikke i e-mailtråde. En typisk integrationsmission varer 12 til 15 uger fra site assessment til autonom operation, med en Field Deployment Engineer på stedet under hele forløbet. Sammenlign det med den traditionelle model, hvor ansættelse af en robotteknikingeniør alene kan tage tre til seks måneder – før noget deployment arbejde er startet.

---

Sikkerhed og overholdelse uden specialiseret personale

Sikkerhed er den mest almindelige bekymring, producenter rejser, når de overvejer deployment uden robotteknikingeniører. Det er en legitim bekymring – og en, som moderne AI-platforme er designet til at adressere direkte.

• Indbyggede sikkerhedsrammer. Platformen håndhæver sikkerhedsbegrænsninger på systemniveau, ikke brugerniveau. Hastighedsgrænser, krafttærskler, udelukkelseszoner og nødstopadfærd konfigureres i henhold til industristandarder og kan ikke tilsidesættes af opgaveniveauinstruktioner. Ingen workflow-konfiguration kan presse robotten hurtigere, end sikre grænser tillader.
• Automatisering af lovgivningsmæssig overholdelse. Standarder som ISO 10218 (industriel robotsikkerhed) og ISO/TS 15066 (collaborative robot safety) definerer specifikke krav til kraftbegrænsning, hastighedsreduktion og sikkerhedsgodkendt overvåget stop. Platformen koder disse krav direkte, hvilket sikrer, at hver opgaveplan er compliant som standard.
• Support til risikovurdering. Platformen kan generere risikovurderingsdokumentation baseret på de konfigurerede opgaver og workspace – den slags dokumentation, som regulerende organer og arbejdspladssikkerhedsinspektører kræver. Dette erstatter ikke en ordentlig sikkerhedsrevision, men det giver et struktureret udgangspunkt, som traditionelt ville kræve en safety engineer at producere.
• Anomalidetektion. Under operation overvåger platformen kontinuerligt for afvigelser fra forventet adfærd. Hvis robotten støder på uventet modstand, hvis en sensorlæsning falder uden for normalområdet, eller hvis et menneske træder ind i en restricted zone, reagerer systemet automatisk – sænker farten, stopper eller alerter operatøren – uden at nogen på fabrikken behøver at konfigurere disse reaktioner.
• Audit trails. Hver opgavedefinition, simuleringsresultat, godkendelse og deployment event logges. Dette skaber et komplet audit trail for regulatory compliance, incident investigation og continuous improvement.

Den vigtigste indsigt er, at sikkerhedsekspertise, ligesom robotteknisk ekspertise, ligger hos platformen og deployment teamet snarere end at være påkrævet af operatøren. Operatørens ansvar er at beskrive opgaven og den operationelle kontekst nøjagtigt. Platformens ansvar er at sikre, at opgaven udføres sikkert.

---

Kom godt i gang: Hvad producenter skal vide

For producenter, der overvejer denne vej, er her de praktiske overvejelser:

• Start med de rigtige opgaver. Ikke alle produktionsopgaver er lige velegnede til indledende humanoid robot deployment. Begynd med opgaver, der er gentagne, fysisk krævende og veldefinerede: materialehåndtering, palletering, basic inspection, machine tending. Disse opgaver leverer den hurtigste ROI og giver den operationelle erfaring, der er nødvendig for at tackle mere komplekst arbejde senere.
• Vurder dit workspace. Humanoide robotter opererer i menneskedesignede miljøer, men de har stadig brug for tilstrækkelig plads, passende belysning til vision systems og stabile overflader. De fleste moderne fabrikker opfylder disse krav, men en pre-deployment assessment er essentiel.
• Identificer dine domæneeksperter. De personer, der skal programmere og styre robotterne, bør være de personer, der forstår arbejdet bedst. Dette er typisk en procesingeniør, en senior operator eller en production manager – en person, der tydeligt kan formulere, hvad der skal ske, og evaluere, om resultatet opfylder kvalitetsstandarderne.
• Aftal succeskriterier på forhånd. Beslut før deployment starter, hvordan succes ser ud: hvilke opgaver, hvad throughput, hvad quality bar. Skriftlige succeskriterier holder begge sider ærlige og gør beslutningen ved afslutningen af en pilot til en måling snarere end en debat.
• Planlæg for change management. Introduktion af robotter ændrer workflows, og det ændrer, hvordan folk føler om deres arbejde. Gennemsigtig kommunikation om, hvad robotten vil gøre (gentagne, fysisk krævende opgaver) og hvad folk vil gøre (supervision, quality assurance, higher-value work) er essentiel for en succesfuld adoption.
• Evaluer providers på deployment support, not just technology. Softwaren er kun en del af ligningen. Evaluer providers på fuldstændigheden af deres deployment support: site assessment, hardware installation, initial task programming assistance, training og ongoing support. Den bedste teknologi er værdiløs uden en pålidelig vej fra purchase til production.
• Tænk i form af leasing, not buying. Økonomien ved humanoid robot deployment er under forandring. En 36-måneders operating lease med maintenance, fleet software og insurance inkluderet – og en buyout option ved udløb – gør robotten til en forudsigelig operational expense snarere end en capital investment. Dette fjerner den upfront financial barrier og aligns costs with value delivery.

Fordelsvinduet er åbent nu. Producenter, der deployer humanoide robotter i dag – selv uden robotteknikingeniører ansat – vil opbygge operationelle kapaciteter og institutionel viden, der akkumuleres over tid. Dem, der venter på de "perfekte" betingelser, den "rigtige" ansættelse eller den "modne" teknologi, vil finde sig selv permanent bagud.

Robotterne er klar. Deployment modellen er klar. Spørgsmålet er, om din operation er klar til at lade de mennesker, der forstår arbejdet, definere, hvad maskinerne gør.

← Tilbage til bloggen