[WIP] Oprettelse af en drawbot styret af et Myo -armbånd: 11 trin

2024 Forfatter: John Day | [email protected]. Sidst ændret: 2024-01-30 08:28

Hej alle!

For et par måneder siden besluttede vi at prøve at tackle ideen om at bygge en drawbot med åben ramme, som kun brugte et Myo-band til at styre det. Da vi først gik i gang med projektet, vidste vi, at det skulle deles op i et par forskellige faser. Vores første hovedfase var at forsøge at vikle vores hoveder rundt om et åbent design til vores draw bot. Dette er en ikke -standard opsætning, og vi ville se, hvad fordelene ved dette design var.

For det andet vidste vi, at det kun ville være nyttigt for os selv at bygge denne prototype. Vores design og plan var at flytte vores sidste ramme til metal og ved hjælp af en arduino modtage vores position fra accelerometeret og gyroskopet indbygget i Myo -båndet. Denne information ville derefter blive sendt til motorerne og ville replikere brugerens bevægelse. Vi vidste, at dette ville få vores anden fase til at bryde op i tre hovedaspekter:

1. programmering fra Myo til motorer, gennem Arduino
2. elektrisk design til at omsætte vores data til bevægelse
3. mekanisk design for at skabe en rimelig størrelse, der vil lette vores bevægelse

Hvert medlem på vores team følte sig mest tryg ved en unik del af vores designproces, så vi besluttede at bryde vores arbejde op mellem hver person. Vi holdt også en blog under hele vores designproces for at spore vores daglige tankegang, i modsætning til et mere globalt udseende.

Trin 1: Hvad vi planlagde at gøre

Vores mål var at kombinere disse to produkter på en måde, som vi ikke har set brugt før. Vi satte os for at lave et live -relæ mellem vores Myo -armbånd og vores egen version af et design inspireret af Evil Mad Scientists AxiDraw.

Trin 2: Prototype ingrediensliste

2 2 x 4 træplader 1 Bælte eller kædemåling> = 65”4 Træ søm 3 Tandhjul med tand, der passer til bæltet eller kæden 4 3 x 8 perforerede plader med vinkel 30 ⅜” Gummi afstandsstykker 8 1”diameter skiver 1 1” diameter træ dyvel 1 'lang 8 Vex skruer 1”8 ½” Vex skruer 8 2”Vex skruer 8 ¼” Gummi afstandsstykker 48 Vex møtrikker 1 Lille lynlås

Trin 3: [Prototype] Træbearbejdning af vores arme og vogninteriør

Vi tog to 2x4’er og skar dem ned til lige lange (33 ¼”)

Ved hjælp af en bordsav lavede vi et hak langs siden af den smalle del af brædderne ¼”dybe og ⅛” brede i midten

Skær dyvlen i 4 2”stykker og bor et hul i midten af dyvlen cirka ¼” i diameter ved hjælp af en boremaskine

Trin 4: [Prototype] Lav vores vogn

Ideelt set ville vi bruge to 7x7 stykker vex perforeret stål, men alt hvad vi havde til rådighed var 2x7 strimlerne, så vi boltede dem sammen i en "X" konfiguration

Stak 5 af ⅜”gummiafstandsstykkerne, og fastgør hjørnerne af viskepladerne til hinanden

Fastgør træduglerne løst som vist i figur 1, så de roterer frit med cirka 2”mellemrum, brug billedet til at se, hvor tandhjulene skal placeres på dette tidspunkt..

Ved hjælp af de ½ “skruer, ¼” gummiafstandsstykker og skiver med en diameter på 1”fastgøres skiverne i en forhøjet position som vist i figur 1 (vi brugte grønne plastgear, fordi vi ikke kunne finde de rigtige skiver), og sørg for, at skiverne er i stand at dreje let og passe ind i brættets hak.

Trin 5: [Prototype] Sætter det hele sammen

Læg et bræt på en overflade, og skub vognen ind i midten, så skiverne holder vognen over brættet og på hver side af brættet søm gearene ned, så de roterer frit. Spik et gear til den ene ende af det andet bræt, og sørg for, at det er centreret, og skub det på vognen vinkelret på det første bræt.

Nu skal bæltet sløjfes gennem systemet som vist. Vær omhyggelig opmærksom på, hvordan dyvlerne er på ydersiden af bæltet, og hvordan der ikke er noget i midten af chassiset, der kan forhindre bæltet, mens det bevæger sig.

Nu skal bæltet spændes på den side af brættet, der ikke har et gear. Vi brugte en ekstra søm og lynlås til at fastgøre vores. Men den anvendte metode er ligegyldig, så længe bæltet er forankret på det sted

Trin 6: [Prototype] færdig og flytter

Det skulle være det, træk bæltet i forskellige kombinationer og se de forskellige effekter, det har på armen!

Trin 7: Oversættelse af vores model til vores færdige design

Da vi havde afsluttet vores prototype, var vi i ekstase. Ingen af os var sikre på, hvordan systemet fungerede før montering. Men når vores dele kom sammen, opdagede vi hurtigt, hvad vi kunne lide, og hvordan vi ville forbedre det, når vi skabte det endelige design. Vores vigtigste klager med systemet til løsning var:

1. vægt

   1. Vores prototype var massiv og uhåndterlig, hvilket gjorde den tilbøjelig til at vælte ved kanten af vores arme
   2. Vognen var meget større end nødvendigt, og den havde meget spildplads
   3. Vores bælte (et slidt tankdæk) var meget større end nødvendigt, hvilket indførte overdreven plads mellem armene

2. Friktion

   1. Vores skrøbelige slidbaner passerede ikke let over tromlerullerne på alle punkter
   2. Plast på træ gjorde vognen uvillig til at bevæge sig i mange tilfælde

3. Motoriserende

   Vi var nødt til at gøre systemet i stand til at fungere

Med disse ting i tankerne tegnede vi vores planer for det endelige design. Vi ville have, at drawboten skulle styres med en Myo via en arduino, og vi ville gøre rammen aluminium og mindre.

For at gøre dette tog vi en procentdel af vores originale prototype og gik ud fra den størrelse. Ved at bruge metalplader, der ville blive bearbejdet til at have kanaler brede nok til, at et afskærmet leje kunne passere igennem, ville vi have et let, men robust design, der ville have højere brugstolerance.

Vores prototype gav os også mulighed for på få minutter at bestemme, hvordan motorrotationen påvirkede hovedet på vores drawbot. Dette fik os til at forstå, at vores kontroldesign ville være mere enkelt, end vi havde regnet med. Ved nærmere eftersyn fandt vi ud af, at motorens bevægelse er additiv! Det betyder, at hver motor har en uafhængig ønsket effekt på vores bevægelse, men når vi kombinerer dem sammen, begynder de at afbryde.

For eksempel, hvis det betragtes som et koordinatplan, vil motoren, der ligger i den negative x ekstremitet, altid have en tendens til at trække vores skuffe ind i den anden og fjerde kvadrant. Omvendt vil motoren, der ligger på den positive x ekstremitet, altid trække skuffen ind i den første og tredje kvadrant. Hvis vi kombinerer bevægelsen af vores motorer, vil det annullere delene af at styre denne konflikt og forstærke de dele, der er enige.

Trin 8: Kodning

Mens jeg arbejdede nogenlunde i C for et par år siden, havde jeg ingen erfaring med lua eller C ++, og det betød, at jeg skulle bruge en mærkbar tid på at kigge dokumentation igennem. Jeg vidste, at den generelle opgave, jeg ville forsøge at udføre, var at få brugerens position med mellemrum og derefter overføre den til motorerne. Jeg besluttede at bryde opgaven op for mig selv for bedre at fordøje de dele, jeg ville få brug for.

1. Få data fra Myo (lua)

Jeg vidste, at jeg var nødt til at finde ud af en måde at indsamle oplysningerne fra Myo. Dette var den første del af den udfordring, jeg ville nærme mig. For at gøre dette ville jeg have brugeren til at kalibrere deres lærredsstørrelse, før han begyndte at tegne. Dette ville give mig mulighed for at have en grænse at arbejde ud fra. Jeg kunne derefter normalisere programmet mellem forskellige brugere ved simpelthen at tage en procentdel af det maksimale lærred som mine datapunkter for at passere. Jeg besluttede at have en scriptet begivenhed, der ville foretage en getOrientation -kontrol hvert halve sekund, da det ville tillade kontrollerne aldrig at udføre et vildt spring, som du skulle gætte fra (f.eks. Hvis brugeren svingede vildt tilbage og frem).

Dette gjorde den første vejspærring, jeg ramte. Jeg opdagede en meget stor begrænsning af lua, og at det ikke ville tillade mig at vente, før jeg fortsatte scriptet. Den eneste måde at udføre denne handling på var enten at sætte CPU'en på pause (hvilket ville stoppe den globalt, selv holde systemuret) eller at bruge OS -specifikke kommandoer. I min eksempelkode forlod jeg i den originale OS -kontrol, at jeg udførte (kommenterede). Dette var efter at have foretaget en stor mængde forskning i luas dokumentation og blev udført ved at kontrollere systemstiformateringen. Det var da jeg besluttede, at jeg skulle se på dokumentationen til projekter, der var blevet offentliggjort tidligere. Jeg indså med det samme, hvor meget tid jeg spildte, og blev straks ført til platformvariablen. Med det kunne jeg implementere OS -specifikke ventekommandoer næsten med det samme, i modsætning til de dage, det tog mig at samle min tidligere løsning.

Det var omkring dette designtidspunkt, at arbejdet med det elektriske aspekt begyndte, og jeg suspenderede arbejdet med dette aspekt af koden. Hensigten er at lære, hvordan vores motorer interagerede med arduinoen.

2. Arbejde omkring Arduino (C ++)

Efterhånden som arbejdet med vores brødbræt blev mere og mere komplekst, lærte jeg, at arduinoen ikke var i stand til multitrådning. Dette var en stor skruenøgle i mit originale kodedesign, og efter at have læst mere om de begrænsninger, der blev præsenteret for vores controller, fandt jeg ud af, at jeg skulle programmere, hvordan arduinoen ville skifte mellem de to. Dette blev fokus for min indsats, da vores deadline nærmede sig. Jeg var nødt til at skrotte store dele af mit originale script, da de var designet til at skrive data til en fil synkront med motorstyringen, der læste filen. Dette skulle give mulighed for en køfunktion for at sikre, at selvom brugeren var foran vores skuffe, ville det ikke ødelægge projektet.

Jeg besluttede, at køfunktionen skulle gemmes, hvis den ikke blev implementeret på samme måde som før. For at gøre dette oprettede jeg en vektor af arrays. Dette tillod mig ikke kun at holde ånden i mit tidligere design relativt intakt, det betød også, at jeg ikke behøvede at holde styr på min plads i filen, hverken for at læse eller skrive. I stedet var alt hvad jeg skulle gøre nu blot at tilføje en ny værdi til min vektor, hvis brugeren bevægede sig (foreløbig test var mindre end 1% af lærredets størrelse forskel i både x og y fra sidst registrerede position resulterede i ingen registrering af data). Jeg kunne derefter tage den ældste værdi i min vektor og i et hug, sende den til motorstyringen, skrive den til vores fil og derefter fjerne den fra min vektor. Dette rensede op for mange af mine bekymringer om at have en konstant IO -strøm kørende.

Trin 9: Elektrisk

Mens jeg tidligere har taget en elektronik klasse, og arbejdet en hel del med arduinos. Jeg har aldrig dykket dybt ned i at få arduinoen til at modtage information fra en ekstern kilde (myo), jeg har kun erfaring med at sende information gennem arduinoen. Jeg tog dog ledningerne til motorerne på vores drawbot og arbejdede på kode, så de kunne arbejde med myo -koden.

Materialer jeg brugte:

2 x trinmotorer

1 x brødbræt

1 x Arduino (Uno)

2 x Driver IC L293DE

40 x jumper ledninger

2 x blæsere

1. Tilslutning af trinmotorer og blæseren til brødbrættet

Efter kredsløbsdiagrammet kan vi føre en trinmotor til føreren på brødbrættet. Derefter følger det samme diagram det, der gælder for den anden driver og motor, men jumpertrådene skal dog sættes i et andet sæt stifter i arduinoen (da den første motor optager plads til 4 andre).

Advarsel/tip:

Driverne er meget små, og stifterne er meget tæt på hinanden. Det ville være klogt at placere de to drivere, så ledningerne ikke bliver forvirrende.

Næste er at tilslutte ventilatorerne. Dette er ret simpelt, de fans, jeg havde til rådighed, var grundlæggende computerprocessorblæsere, som har en positiv og grund. Sæt disse to i deres respektive +/- ben på brødbrættet, og vink dem hver mod hver driver. (Vi fandt ud af, at fordi steppermotorerne modtager bursts af oplysninger og kommandoer over en lang periode, har driverne en tendens til at overophedes og lugte. Tilføjelse af en ventilator til afkøling løste dette problem).

2. Arduino -kode

Dette er den lette del!

Åbn Arduino IDE, gå til fanen "File", slip derefter til fanen "eksempel", som vil falde endnu længere ned og vise dig en "stepper" -fane. Så vil du åbne "Stepper_OneStepAtATime"

Dette vil forudindlæse en eksempelkode, der næsten er plug-and-play til arduino/motorkablerne. Vi bliver nødt til at foretage små justeringer, fordi vi vil køre to motorer, som jeg vil vise herunder. Du skal muligvis også foretage mindre justeringer afhængigt af hvilke ben du har besluttet at bruge, da Arduino IDE som standard er benene 8-11.

Koden, som jeg har brugt til at få de to motorer til at bevæge sig i "synkronisering", er nedenfor:

//#omfatte

const int stepsPerRevolution = 200;

Stepper myStepper1 (stepsPerRevolution, 9, 10, 11, 12);

Stepper myStepper2 (stepsPerRevolution, 4, 5, 6, 7);

int stepCount = 0;

void setup () {// initialiser den serielle port: Serial.begin (9600); }

void loop () {

myStepper1.step (1);

Serial.print ("trin:");

Serial.println (stepCount);

stepCount ++;

forsinkelse (0,5);

myStepper2.step (1); forsinkelse (0,5); }

3. Mulige problemer

Problemer, som jeg løb ind i under denne proces, var ikke at bruge det rigtige kodeeksempel, bruge en dårlig jumper wire, bruge den forkerte driver IC.

Sørg for, at din driver, du bruger, er i stand til at styre en motor

Kontroller serienummeret og tjek dets specifikationer

Jeg løb ind i et problem med at have en død jumper wire, hvilket fik mine motorer til at spinne mærkeligt

Jeg var nødt til at bruge et multimeter til at kontrollere hver ledning

Og tjek altid din kode for små fejl som at mangle en ende “;” kommando

Trin 10: Mekanisk

1. Materiale

For den fulde produktionsmodel af armene anbefales det, at de er lavet af stærkt, men let materiale, vi følte, at aluminium passede perfekt.

Vi brugte 032 gauge aluminiumsplader skåret til 9,125 "x 17,5" og spores mønsteret fra tegningen vist i det foregående trin.

2. Fremstilling

Ved hjælp af hammeren (den blå maskine) tilføjede vi sømme, der vender modsatte retninger, så når stykket er brudt og foldet, ville de to sømme sammenlåse og danne et enkelt komplet stykke.

Til de store sving brugte vi tennismithen på grund af dens høje præcision.

Nu til de mindre bøjninger, vil du gerne bruge en maskine med en mindre fod, det er her en maskine som roto-die kommer ind. På grund af dens mindre fod giver den mulighed for at lave mindre pauser desværre, roto-die til rådighed var stadig for stor til vores skinne, og den blev deformeret.

** Alternativt, hvis du ikke har adgang til det korrekte udstyr eller værktøj, kan der foretages en erstatning. **

I vores tilfælde skar vi vores arme af aluminiums solpanelskinner ved hjælp af en plasmaskærer og slibede enderne glatte og boltede dem bagud for at lave et dobbeltsidet skinnesystem. Ideelt set ville vi gerne svejse skinnerne sammen, men uden adgang til en svejsestation spændte vi i stedet skinnerne sammen og borede igennem og boltede dem derefter sammen. Men hvis denne rute er taget, skal der gøres særlig opmærksom på at bruge en låsemøtrik og skive for at sikre, at stykket har så lidt bøjning som muligt.

3. Bæltet

Til bælterne brugte vi nogle gamle 3D -printerbælter, som vi kunne redde.

Bælterne var i første omgang ikke lange nok, så ved hjælp af nogle varmekrympeslanger kombinerede vi to stykker til at lave et, der ville være tilstrækkeligt langt.

De grønne tandhjul og træduller blev erstattet af skive lejer med ekstra brede skiver, der blev brugt til at forhindre bæltet i at glide malplaceret.

4. Vogn

Og endelig var vognen lavet af et 5 "x 5" ark af 032 aluminium, med huller boret, hvor de tilsvarende skruer og skiver er beregnet til at gå. Afstanden vil variere afhængigt af, hvor bred din skinne er, og hvor meget frihøjde du har på dine skiver.

Trin 11: Refleksioner

Desværre løb hver side af vores projekt ind i tidens store barrikade, og vi kunne ikke færdiggøre vores design inden vores måldato. Hvert medlem af vores team endte med at samarbejde i alle andre aspekter af vores design i det mindste i et vist omfang, hvilket førte til en vis indlæringskurve. Dette kombineret med ønsket om at designe et produkt med så få eksterne ressourcer som muligt (da vi alle ønskede at skabe vores respektive dele fra bunden), fører til en stor mængde genopfundne hjul.

Alle, der arbejdede på projektet, lærte mere om de andre aspekter af projektet. At få software til at gøre en bestemt handling er en ting, så er det en anden at få software til at fungere sammen med hardware. Jeg vil sige, at det er vigtigt, at den, der arbejder med kodningsaspektet ved dette projekt, er lige så bekendt som vores projektkoder.

Samlet set var vi ikke i stand til at opnå præcis det, vi ville. Jeg føler dog, at vi var på rette vej, og vi alle opdagede og lærte nye koncepter, som vi vil kunne anvende på fremtidige projekter.