Dagen jeg ville bygge en robotarm — og endte med at slås med en skruetrækker

Planen var enkel. Brilliant, endda. Et par timer, tænkte jeg. Måske tre. Det blev en hel dag — og en lille sejr på et bord i Silkeborg.

Idéen var at bygge en robotarm. Ikke en industriel én — en hjemmebygget, 3D-printet sag med seks led, designet til at kunne plukke ting op, vinke, måske en dag servere kaffe. Den slags man kender fra fabrikker, bare i lille format og uden den industrielle pris. Mit hjørne af projektet den dag var beskedent: få én motor til at dreje rundt. Bare én. Som et bevis på at hele kæden virkede.

Det skulle have taget et par timer. Det tog en hel dag. Og som med så mange ting her i livet endte det egentlig ikke med at handle om robotter — men om tålmodighed, detektivarbejde, og en jumper-pin der gemte sig på bagsiden af et printkort.

Da computeren ville have en skærm

Først skulle hjernen sættes op. En lille computer — en Intel NUC, ikke større end en madpakke — skulle styre det hele. Jeg installerede et styresystem, og det første problem dukkede op næsten med det samme: jeg ville gerne have noget at kigge på. En grafisk brugerflade, ligesom Windows eller Mac. Noget med ikoner.

Computeren foreslog at downloade et softwarepakke. 1165 små filer ved 38 kilobyte i sekundet. Estimeret ventetid: knap tre timer. Jeg afbrød. Fandt en lettere løsning. Fem minutter. Færdig.

En lille læring

Når noget tager tre timer at downloade, er der næsten altid en vej udenom. Maskiner foreslår tit den nemmeste vej for dem selv — ikke for dig.

Når fremtiden ankommer for tidligt

Næste skridt var at installere selve robotsoftwaren. Den hedder Klipper og er egentlig lavet til 3D printere, men den er så fleksibel at man kan bruge den til at styre motorer i alt muligt andet. Inklusive robotarme.

Den ville ikke installere sig.

Det viste sig, at min computer kørte en helt ny version af et programmeringssprog kaldet Python — version 3.14, helt frisk fra fabrikken. Så frisk, at intet andet software endnu var nået at blive klar til den. Det er lidt som at købe en bil med en helt ny type benzin, kun for at opdage at ingen tankstationer i landet sælger den endnu.

Python 3.14 er fra fremtiden og burde ikke eksistere endnu på en arbejdsmaskine.

Efter lidt detektivarbejde — og en gammel version af Python installeret ved siden af den nye — kom tingene igennem. Robotsoftwaren startede. En lille webside dukkede op i browseren med sit røde logo og en venlig fejlmeddelelse: "Kan ikke forbinde til styringskortet."

Selvfølgelig.

SD-kortet der ikke ville være med

Mellem computeren og motorerne sidder et lille printkort. Det er hjertet i hele systemet — det sted hvor digitale beskeder bliver til fysiske bevægelser. Kortet kom fra fabrikken med en anden software end den, jeg ville bruge. Så jeg skulle udskifte den. Det gøres normalt med et SD-kort, som man stikker i kortet, hvorefter det automatisk opdaterer sig selv.

Jeg lagde den nye software på SD-kortet. Stak det i. Tændte. Intet skete.

Prøvede igen. Intet. Reformaterede kortet. Intet. Printkortet kiggede på SD-kortet som en kat der kigger på en støvsuger — med fuldstændig ligegyldighed.

Skjult bagpå

Der findes en bagvej. Den hedder DFU-flash og kræver at printkortet sættes i en særlig tilstand ved at kortslutte to små metalben. Problemet var bare at finde dem.

Jeg studerede kortet. Tog billeder. Sammenlignede med tegninger på nettet. Den lille gule firkant øverst i hjørnet — kunne det være en knap? Nej, en hukommelseschip. Den sølvfarvede prik — knap? Nej, en kondensator. Jeg ledte i tyve minutter.

Til sidst vendte jeg kortet om. Og der, på bagsiden, i et lille hjørne med teksten "3V3 BOOT0", sad to bittesmå metalpinde og ventede. Ikke en knap. Bare to pinde, som skulle røre ved hinanden i et splitsekund.

Jeg tog et lille stykke metal — bagenden af en skruetrækker — og kortsluttede dem. Stak USB-kablet i. Skrev en kommando på computeren. Og der, midt i en lang stribe tekst, kom svaret:

STMicroelectronics — DFU Mode

Det var den. Printkortet havde vågnet op i den rigtige tilstand. Nu kunne jeg endelig overskrive softwaren.

Motoren drejer

Resten var små detaljer. Et bogstav for meget her, en manglende indstilling der, en termometerfunktion der troede der var minus 59 grader fordi den ikke var koblet til. Hvert problem tog fem minutter at finde og fem sekunder at løse.

Og så — efter en hel dag, efter ventetider og fejlmeddelelser og en computer der ville have en grafisk skærm den ikke skulle bruge — skrev jeg den sidste kommando.

Motoren drejede.

Ikke en stor, dramatisk bevægelse. Bare en lille stepper-motor der roterede roligt og præcist på et bord i Silkeborg, styret af en lille computer via et printkort med software jeg selv havde bygget og installeret med en skruetrækker.

Det var nok.


Hvad er det egentlig?

Det færdige projekt skal være en robotarm med seks led — én af de der ledningsslangede sager man ser på fabrikker, bare en del mindre og lavet derhjemme. Den skal kunne dreje, løfte, gribe. Den er printet i plastik, drevet af præcise små motorer, og styret af software der oprindeligt er lavet til 3D printere.

Selve mekanikken ligger og venter. Strømforsyningen er på vej. Når den ankommer, skal alle seks motorer prøvekøres samtidig. Det er den næste lille forhindring.

Det er sådan her, jeg lærer ting nu om dage. Lidt ad gangen. Med fejlmeddelelser som vejvisere. Og en stille tilfredshed når noget endelig drejer rundt.