DIY SegWay Projektrapport

Transkript

1 2009 DIY SegWay Projektrapport Jesper Aagaard Vuholm Daniel Christoffersen

2 Forfattere: Jesper Aagaard Vuholm & Daniel Christoffersen Vejleder: Henning Hargaard Projektnummer: Dokument-id: (filnavn) Projektrapport.pdf Antal sider: 38 Kunde: IHA Jesper Aagaard Vuholm Daniel Christoffersen Version 1 side 2 af 38

3 RESUMÉ I denne rapport beskrives arbejdsprocessen med udarbejdelsen af afgangsprojektet DIY SegWay. Projektet består i udviklingen af en SegWay, der er et selvbalancerende tohjulet køretøj til persontransport. Formålet, udover at løse de ingeniørmæssige problemstillinger, har været at konstruere et billigt hjemmelavet alternativ til de kommercielle SegWays. Der er taget udgangspunkt i en ældre kasseret el-kørestol doneret af firmaet Roltec. Den benyttede udviklingsmetode i dette projekt har bestået af en fornuftig blanding af de to agile udviklingsmetoder Extreme Programming XP og Rational Unified Process RUP. Projektet spænder i store træk over SegWay ens fysiske konstruktion, programmering af Atmels mega644p microcontroller, software filtrering af sensor inputs, software genereret PWM modulering, BlueTooth kommunikation, PD motorregulering, C# programmering af et debug og analyse program til PC samt et parameterindstillingsprogram til Windows Mobile platformen. For at begrænse opgavens omfang er der, hvor det har været muligt, benyttet færdigindkøbte hardware moduler. Rapporten beskriver de faser projektet har gennemgået for til sidst at nå målet, nemlig en kørende og billig SegWay. SYNOPSIS The following report describes the preparation and methods used in completing our final project DIY SegWay. The project s principal goal is the development of a SegWay which is a self balancing two wheeled vehicle used for personnel transportation. Besides the engineering problems involved in this sort of project the main purpose has been to construct a cheap Do It Yourself SegWay compared to the commercial ones. The starting point of this project was based on an older discarded electric wheelchair donated from Roltec. The developmental method used in the project consists of a sensible blend of the two development methods, Extreme Programming XP and Rational Unified Process RUP. The project covers the physical construction of our SegWay, programming of Atmel mega644p microcontroller, software filtering of sensor inputs, software generated PWM modulation, BlueTooth communication, motor regulation using PD, C# programming of a debug and analyze tool for PC and a parameter based tuning program for the Windows Mobile platform. To limit the tasks involved in this project we have used premade hardware modules where possible. This report describes the different phases the project has undergone to reach its goal - a running and cheap SegWay. Version 1 side 3 af 38

4 FORORD Dette projekt har været en del anderledes end de projekter vi har gennemført på IHA tidligere, hvilket også vil afspejle sig i denne projektrapport. Meget af det udførte arbejde er foregået i arbejdsområder, som vi hverken har haft erfaring med eller fået undervisning i. De aspekter og problemstillinger vi harmødt i de forskellige arbejdsområder vil blive beskrevet i denne projektrapport. Der vil derfor være en del teknisk information i projektrapporten, da vi har vurderet dette som nødvendigt for en fuld forståelse af de processer, vi har været igennem, samt forståelse af problemstillingerne omkring det at lave en hjemmelavet SegWay. Version 1 side 4 af 38

5 INDHOLDSFORTEGNELSE Forord... 4 Indledning... 7 Projektbeskrivelse... 8 Projektafgrænsning... 8 Projektgennemførelsen... 9 Overordnet tidsplan... 9 Metoder Extreme programming XP Rational Unified Process RUP Specifikations- og analysearbejdet Kørestolen Motorstyringen Konstruktionen Måling af hældningsvinkel Regulering af motorerne ud fra den målte hældningsvinkel Software Designprocessen Udviklingsværktøjer Generelt PC Udviklingsværktøjer mobil Udviklingsværktøjer Microcontroller udviklingsværktøjer software Microcontroller udviklingsværktøjer hardware Resultater Diskussion af opnåede resultater Opnåede erfaringer Gcc i Eclipse Version 1 side 5 af 38

6 DC motor driver Software filtrering PD regulering Windows Presentation Foundation BlueTooth ADC Fejl grundet overclockning ADC Fejl grundet Interrupt problem STK500 afbryderen Projektets fortræffeligheder Bluetooth kalibrering Konstruktionen Motorstyringen ADC konstruktionen Hældningsvinklen Forslag til forbedringer af Konklusion Referencer Net kilder Bøger Bilag Vinkelestimering Logbog Version 1 side 6 af 38

7 INDLEDNING De fleste har vist prøvet at balancere en pind opret på en finger. Får pinden overbalance i den ene eller anden retning, forsøger man at flytte hånden i den retning pinden falder. Gør man det hurtigt nok, taber man ikke pinden. Men gør man det for hurtigt, får pinden overbalance i modsatte retning. Dette ustabile system kan kaldes for et omvendt pendul. Altså et pendul der vender på hovedet. Og det er netop dette princip der ligger til grund for en SegWay, dermed også for dette projekt. En SegWay er et 2-hjulet, selvbalancerende transportmiddel, som kun har et formål, nemlig at holde balancen. Når man står på en SegWay, bruger man sin vægt til at påvirke denne balance. Vil man fremad, laver man en lille overbalance fremad med sin vægt. Denne overbalance resultere i en hældning, der registreres af systemet, som så reagere ved at køre fremad for at rette op på ubalancen. Opretholdes overbalancen, kører man dermed fremad. Det samme gælder for at køre bagud. For at vide om systemet er i balance eller ej, skal der bruges nogle sensorer, der kan detektere dette. Når man står med pinden på fingeren og prøver at holde den i balance, bruger man synet og følesansen til at holde balancen med. Men disse sanser kan vi desværre ikke benytte i en SegWay. I stedet bruges sensorer, der kan måle hældningen på SegWay ens konstruktion. Der bruges en kombination af gyroskop- og accelerometersensorer. SegWay en står i balance, når hældningen på den plade man står på er nul grader i forhold til vandret. Ændres denne hældningsvinkel, er det fordi der overbalance i den ene eller den anden retning. Når man prøver at balancere en pind på fingeren, finder man hurtigt ud af, at det ikke er nok at vide hvilken retning pinden falder. Der er også en sammenhæng mellem hvor hurtigt pinden falder og hvor hurtigt man skal reagere. Det samme gælder for SegWay'en. Til det kan man bruge forskellige reguleringsteknikker, som kan omsætte ændringerne i hældningen og hastigheden af dem, til hastigheden af den bevægelse, der er nødvendig for forsat at holde balancen. I forbindelse med faget >>Digital kontrol i en fysisk verden<< som vi fulgte ved datalogi på Århus Universitet i efteråret 2008, stiftede vi bekendtskab med denne problemstilling. Vi lavede en model af systemet i Lego, Den fik vi til at holde balancen, men det var ikke helt tilfredsstillende nok. Vores model kunne ikke andet end at holde balancen, den kunne ikke rette op, hvis man skubbede til den. Efter projektet var vi meget sikre på, at vi kunne gøre det bedre. Det var også en smule svært at lave en model i Lego, som man ville kunne stå på - vores model var ca. 40 cm høj! Så vi besluttede, at hvis vi skulle prøve at lave en SegWay selv, så skulle det være en som man vil kunne stå på og kunne bruge som den originale SegWay. At bygge sin egen SegWay giver nogle problemstillinger, som vi ikke rigtigt har fået noget undervisning i. Der skal laves en konstruktion, findes noget mekanik, som f.eks. motor og gearing. Desuden skal der laves noget elektronik til styring af motorerne osv. Så for ikke at gabe over mere end vi kunne tygge, besluttede vi at finde de ting, som vi ikke har kompetencer til at lave selv, i færdige hardware moduler, således at vi kunne bevare fokus på områder der ligger indenfor vore kompetencer. Konstruktionen har været en af de store usikkerheder, da det ikke lige er til at købe en færdig konstruktion, som vi ville kunne bruge. Heldigvis har IHA et metalværksted med nogle meget kompetente medarbejdere, som har været meget behjælpelige med konstruktionen. For at undgå at skulle lave stærktstømselektronikken til motorstyringen, besluttede vi os for at undersøge virksomhederne omkring Århus, for at se, om der ikke skulle være en virksomhed, som beskæftiger sig med dette og som kunne være interesseret i at hjælpe os. Vi kontaktede Roltec Elkørestole A/S i Lystrup, som laver elektriske kørestole. De var meget villige til at hjælpe og donerede en gammel kørestol til os. Den var fuldt funktionel, dog uden stol. I denne kørestol var der flere af de dele vi havde brug for: Hjul, gear og motorer, samt motorkontrollere, som er Version 1 side 7 af 38

8 dimensioneret til de motorer som var i kørestolen. Herfra var det blot et spørgsmål om at få fundet de resterende komponenter, samt få det hele til at gå op i en højere enhed. Vi har haft nogle milepæle, som har været afgørende for om projektet lykkedes: Få konstruktionen på plads Styre motorerne fra egen software Få omsat sensor input til en pålidelig hældningsvinkel Få lavet en regulering af motorerne i forhold til denne hældningsvinkel Når der var sat flueben ud for disse fire milepæle, vidste vi at projektet ville komme i mål. PROJEKTBESKRIVELSE Følgende opgaveformulering er fra vores forprojekt i efteråret Denne formulering dækker de tanker vi oprindeligt havde tænkt. Projektet vil omhandle at lave en SegWay (en selvbalancerende 2-hjulet el-scooter) der kan benyttes til persontransport. Denne transporttype findes allerede på markedet, hvor priserne dog ligger på omkring kr. Vi vil gerne vise at man kan lave en SegWay selv, til en noget anden pris, anslået pris på kr. Projektet vil bestå af følgende: 2 x DC motorer med gearing. xxx x Batteri(er) enten NiMH ell. Lith-ion. Der skal en del battericeller til for at få dækket det nominelle og peak drain. 2 x Hjul xx x Motordriver FET. Evt. OSMC (Open Source Motor Control) x Gyroskop x Accelerometer x Aluminium ell. stål til at konstruere chassis-rammen med. x x Atmel mega16 microcontrollere. Microcontrollerne er kontrolenheden i systemet, det er denne enhed som projektet vil fokusere på. Hardwaren kan i stor udstrækning anskaffes i moduler, dette gør det muligt at ligge meget af fokus på softwaren i kontrolenheden. Dette giver mulighed for nemt og hurtigt at skifte styringen ud. Dvs. det bliver en platform for at teste forskellige software-reguleringsteknikker, som f.eks. PID, Space State, Fuzzy Logic osv. En mulig vinkel på dette projekt kunne være at undersøge styrker og svagheder ved de forskellige softwareimplementerede reguleringsteknikker. Udover dette kunne der implementeres en MMI med knapper til tænd/sluk, hastighedsbegrænser mm., display med information om batterilevetid, hastighed mm. Der skal interfaces til den modulbaserede hardware, via UART, I2C, SPI alt efter hvad modulet kan, eller hvad der findes hensigtsmæssigt. PROJEKTAFGRÆNSNING Tidligt i forløbet kunne vi se, at opgaveformuleringen fra forprojektet var lidt for omfattende. Så vi har lavet en afgrænsning af den opgaveformulering, som vi mener, er mere realistisk. Version 1 side 8 af 38

9 Formålet med dette projekt er, at vise at det er muligt at lave sin egen hjemmelavede SegWay. Til dette vil vi benytte en Atmel microcontroller som hjerne, samt en kombination af gyroskop og accelerometer til at måle hældningsvinklen på konstruktionen. Det resterende vil være baseret på en gammel elektrisk kørestol fra Roltec. Selve konstruktionen laves i aluminium på IHAs værksted ud fra vores skitser. Vi har stadig et budget på omkring kr. Vi vil ikke implementere andre reguleringsteknikker end PID, som vi har lidt erfaring med fra et tidligere SegWay projekt i Lego. Vi har ikke fået undervisning i reguleringsteknik, så vi holder os til PID, da vi i det mindste har prøvet at implementere den før. For at have muligheden for at komme i mål med projektet, bliver vi nødt til at holde os på kendt grund, der hvor det er muligt. Det skal påpeges at det er en prototype med fokus på at få det endelige produkt til at fungere og derigennem drages erfaringer, som vil kunne bruges i forbindelse med fremtidige projekter på denne prototype. Vi vil ikke fokusere på det æstetiske i hardware, men det funktionelle. Vi mener stadig at det kunne være spændende at afprøve forskellige reguleringsteknikker, og vurdere styrker og svagheder i de forskellige teknikker, i forhold til at løse problemet med at holde balancen. Men det er helt projekt i sig selv og vil ikke være et fokuspunkt i dette projekt. Dog vil vi stræbe efter at gøre prototypen så fleksibel, at det vil være muligt at implementere andre løsninger i fremtidige projekter. PROJEKTGENNEMFØRELSEN OVERORDNET TIDSPLAN Følgende tabel viser tidsplanen, som vi havde tænkt det i forprojektet. Måned December 08 Januar 09 Februar 09 Marts 09 April 09 Maj 09 Juni 09 Beskrivelse Vejleder, budget på plads Indkøb af dele, konstruktion sat i gang Planlægning af ledningstræk, og controller print Samling af første prototype Videre samling af prototype samt tweak af software control algoritmen Test af SegWay samt debug interface Eksamen Det tog et par uger mere at lave konstruktionen, end vi regnede med. Trods dette havde vi en færdig prototype i første uge af maj, hvilket kun var lille en uge over tiden. Det må siges at være acceptabelt, da overstående tidsplan blev lavet i december. Dette projekt har været gennemført lidt anderledes end vi har været vant til, da vi tog udgangspunkt i et eksisterende produkt og brugte dette på en ny og anden måde, end det var tiltænkt. Kørestolen fra Roltec, som havde tjent et noget andet formål tidligere, blev skrællet for komponenter og af disse bjergede vi, hvad vi kunne bruge og sammensatte dem på ny. Denne fremgangsmetode har givet en masse spørgsmål, og endnu flere usikkerheder. Vi har bevæget os omkring forskellige faggrupper, som vi ikke er vant til: Vi har været forbi en elektronik, mekanik og konstruktionsdesign. Dette har gjort at vi har taget mange og små trin for at kunne holde styr på helheden. Følgende diagram giver et overblik over de trin vi har taget og den tid det har taget. Version 1 side 9 af 38

10 Uge 5 Finde mulige sponsorer Uge 6 Undersøge hvad vi har fået sponsoreret Iterativ proces der har kørt resten af forløbet Finde og bestille komponenter Uge 7 Test Udvikling af software til MIC Få tegnet et skitse til konstruktionen, og få fremstillingen af denne i gang Uge 8 Uge 9 Test af kommunikation mellem MIC og PC eller mobil Test Udvikling af software til PC Starte på softwareudvikling mens vi venter på konstruktion og komponenter Få placeret komponenter i konstruktion. Uge 14 Test Udvikling af software til mobil Ledningsnet Uge 15 Uge 16 Konstruktion af kontrolpanel Testopstilling til vinkelmålinger Uge 17 Beregninger på testdata fra vinkelmålingstesten Implementering af vinkel approximering Beregninger af PWM ud fra vinkelberegningerne Uge 18 Implementering af regulering Fintuning og test done Uge 19 Rapportskrivning Uge 22 Version 1 side 10 af 38

11 METODER I dette projektforløb har vi, populært sagt, shoppet os til de bedste og for projektet meste relevante værdier fra metoderne Extreme Programming(XP) samt Rational Unified Process (RUP). EXTREME PROGRAMMING XP Extreme Programming, populært kaldet XP, er en agil udviklingsmetode, der er karakteriseret ved at være åben for tilpasninger løbende i udviklingsprocessen. Det er ikke alle idéer og koncepter fra XP der har passet lige godt ind i vores projekt. Vi har derfor udvalgt de ting i XP metoden, som ville tilføre vores projekt værdi. XP metoden har fire hovedprincipper, hvor af vi benytter de 3: Kommunikation: I dette hovedprincip lægges der normal meget vægt på, at brugere og udviklere er i konstant kommunikation om det kommende system. Netop dette hovedprincip har ikke været relevant eller brugbart i vores projektforløb, da vi ikke har brugere før i slutningen af projektet og disse brugere er da os selv. Simplicitet: Her lægges der vægt på, at udviklerne til hver en tid kun skal skrive den kode, der netop løser det aktuelle problem. Dette princip er blevet flittigt benyttet. Alle drivere blev skrevet efter dette princip og der blev fokuseret på den aktuelle driver indtil denne var færdig, jf. den igangværende iteration. Feedback: Dette hovedprincip foreskriver at tests skal bruges, idet de er af afgørende betydning. Basalt set giver det udviklerne svar på, om det de har lavet er korrekt. Dette feedback princip er fra start til slut i projektet blevet flittigt benyttet. Specielt fordi tests ofte var den eneste mulighed for at finde den optimale løsning på et problem, f.eks. protokoldesign, streamrate, batterivalg, baudrate, m. f. Mod: Man skal turde. Vi havde inden dette projekt ikke alle de nødvendige forudsætninger for at give os i kast med et projekt, der involverer flere aspekter inden for strømstyring, elektronik, filtre og regulering. Vi tog opgaven på os og er efterfølgende blevet fortrolige med disse emner, hvilket har været en stor gevinst. Desuden opererer XP med tolv punkter ("core practices"), der beskriver den ideelle arbejdspraksis i et XP-projekt. Igen er det ikke nødvendigvis alle 12 punkter, der har passet lige godt ind i dette projekt. Vi har derfor kun valgt at benytte de punkter, som giver mening og værdi til netop vores projekt og følgende otte punkter er udvalgt: Planlægning ("Planning game") Små udgivelser med korte mellemrum Simpelt design Test Hyppig refaktorering Parprogrammering Version 1 side 11 af 38

12 Fælles ejerskab til programkoden Kontinuerlig integration RATIONAL UNIFIED PROCESS RUP Rational Unified Process er en objektorienteret agil softwareudviklingsproces. RUP bruger UML som notationssprog. I modsætning til XP er det kun få metoder vi i dette projekt har benyttet fra RUP. Der har nærmere været tale om at udnytte metoden som en portion fornuftige tanker og koncepter i forbindelse med projektudvikling. Specifikt er det følgende fra RUP vi har benyttet: Inkrementel: Tanken er her, at hver iteration i princippet giver en udvidelse af det færdige system. Dog kan der næppe, efter en afsluttet iteration i projektet, være tale om en udvidelse af et færdigt produkt, men snarere blot endnu en mursten til det byggemateriel som projektet slutteligt skal bestå af. Use case drevet: I RUP er det use cases som er kernen i udviklingen og disse bruges under såvel analyse, design, implementering samt test. Hver iteration vil normalt handle om at foretage en fuldstændig udvikling af en eller flere use cases. Igen har vi, grundet projektets specielle karakter, kun benyttet os af use cases i et meget begrænset omfang, da formålet med det endelige produkt er meget simpelt og indeholder få use cases. Risikodrevet: Her er tanken at risici skal identificeres tidligt i forløbet. De største risici findes ved en risikovurdering. Herved udvælges de største risici i projektet. I var der helt klart tre større kampe/risici, som var afgørende for om projektet ville lykkedes. Disse er identificeret som: En god og tidlig fysisk konstruktion, få en god styring af motorerne på plads og slutteligt at få filtreret gyro- og accelerometerinput og herefter få udregnet en brugbar hældningsvinkel. SPECIFIKATIONS- OG ANALYSEARBEJDET Også her i analyse- og designprocessen har forløbet været en smule anderledes end hvad vi har prøvet før. Det har ikke kun været softwareudvikling, som vi er vant til. Vi har bl.a. været omkring konstruktionsdesign, elektronik, filtre og regulering. Dette afsnit vil beskrive de processer vi har været igennem. Version 1 side 12 af 38

13 KØRESTOLEN Vi fik doneret en kørestol af Roltec, som vi har brugt som base for. Vi har genbrugt hjul, motorer, gearing og de to motorkontrollerer, der var monteret på kørestolen. Figur 1 Roltec kørestol Overstående billede er en nyere model, men platformen er meget ens. Vi fik en fuldt funktionel kørestol, dog uden sæde. Første indtryk af kørestolen, var at den var tung, meget tung. Så vi skulle helt sikkert have skrællet noget af vægten. Vi kunne ikke bruge chassiset fra kørestolen, så her skulle der laves en konstruktion, som passede til formålet. Roltec benytter sig af 2 x 12V Bly-gel akkumulatorer, som både er store og tunge. Så vi kunne meget hurtigt konstatere, at vi blev nødt til at finde nogle andre batterier. For at finde nogle batterier som passer til opgaven, måtte vi finde ud af hvor meget strøm motorerne drænede. Det blev dog et større problem, da skolen ikke umiddelbart ligger inde med et amperemeter, som kunne måle så store strømme. Løsningen blev målinger lavet med en shunt modstand. Se afsnittet Måling af motordræn i systemdesignet. Version 1 side 13 af 38

14 BATTERIVALG Figur 2 Brainstorm på mulige batteriløsninger Ifølge vores shunt målinger var der et absolut maksimum strømdræn på 110A ved 24V. Grundet netop dette til tider store strømforbrug, samt en gunstig pris, endte vores batterivalg med 40 D-celler á 1,2V 10000mAh af typen NiMH(Nickel-metal hydride). Disse 40 celler er inddelt i fire pakker bestående af 10 D-celler i serie, hvilket giver 12V og 10Ah. pr. pakke. Disse fire pakker kobles nu som vist i nedenstående setup: Dette setup kan klare kortvarige strømdræn på op til 100A, hvilket er rigeligt jf. de voldsomme strømdræntests der blev udført mens motorerne sad i deres oprindelige konstruktion. I denne nye konstruktion vil der ved afvekslende kørsel typisk være et strømdræn på 5-20A. Dette er også godt under de 40A der maksimalt er tilladt for kontinuerligt strømdræn. Skulle ved fejlbrug eller skade på et tidspunkt overstige det absolut tilladte strømdræn på 100A, er hver batteripakke desuden udstyret med et sikkerhedsprint, der vil slå fra inden batterierne bliver beskadiget. Version 1 side 14 af 38

15 OPLADNING Hver af de fire pakker kan lades med en medfølgende Smart Charger (9.6V-18V). Denne kan lade batteripakkerne til fuld kapacitet på syv timer når der lades med 1,8A. Det giver strøm til ca. 2 timers kørsel. MOTORSTYRINGEN Inden dette projekt havde vi kun ganske lidt erfaring med motorstyringer og disse var spinkle og opnået gennem "leg" med nogle ganske små stepper-motorer. Disses strømdræn var ganske anderledes i forhold til de aflagte elkørestolsmotorer, vi nu skulle benytte til at fremdrive med. Det stod klart ret tidligt i projektet, at hvis projektet skulle ende med succes, skulle der lægges meget fokus på de faser der er involveret i motorstyringen. Til at styre disse store elkørestols-motorer, benyttes der to til formålet specielt byggede motorkontrollere. Grunden til at disse to motorkontrollere, en til hver motor, skal bruges, er at der benyttes så store strømme til at drive motorerne, at vi ikke på andre måder kan levere strømmen, samtidig med at vi også skal kunne styre den. De to motorkontrollere var taget ud af deres oprindelige konstruktion, befriet fra andre print, og skulle nu bruges på en ganske anderledes måde og til et andet formål end det de var bygget til. Roltec var så flinke at give os eldiagrammerne over motorkontrollerne, hvilket lettede "reverse engineer" arbejdet en hel del. Hovedproblemet med motorkontrollerne var begrænset til "blot" at levere de rette input som kræves af motorkontrollerne for at kunne fungere. Ledningerne til disse input var dog ikke på nogen måde markeret. Vi brugte derfor en del tid på at få styr på hvilke signaler der skulle på hvilke kabler. MOTORKONTROLLERNE Figur 3 Kobling mellem motor og microcontroller Motorkontrollernes funktion er at omsætte PWM 1 signalet fra microcontrolleren til et stærkstrømsignal, således at motorerne responderer jf. den nuværende duty-cycle på PWM signalet fra microcontrolleren. Kort forklaret går PWM signalet fra microcontrolleren ind på en af de to MOSFET-driverkredse(LT1160). Denne styrer fire af de otte 75A 55V MOSFETs. Det er disse MOSFETs, der "åbner" for stærkstrømmen til motoren. De otte MOSFETs er sat op omkring motoren i en almindelig H-bro opkobling. Af samme grund er det yderst vigtigt at der ikke sendes et PWM signal fra 1 Pulse Wide Modulation Se systemdesign Microcontroller afsnittet for implementeringsdetaljer. Version 1 side 15 af 38

16 begge ender af H-broen på samme tid, da dette vil medføre en kortslutning. Se evt. systemdesign bilag motorkontroller diagram. INPUT TIL MOTORKONTROLLER Et af de større og mere tidskrævende problemer i forbindelse med dette projekt, har været at få skaffet de nødvendige input til motorkontrollerne. Se nedenstående inputoversigt med tilhørende forklaring. Shutdown: Dette signal ANDes med PWM signalet. Da vi kun benytter vores PWM til at styre motorerne med, er shutdown sat konstant høj vha. 5V forsyningen fra STK500. PWM1V: Et af de to PWM input som kommer fra microcontrolleren. PWM2V: Et af de to PWM input som kommer fra microcontrolleren. 5V: 5V forsyningen benyttes primært til at forsyne motorkontrollerens styrelogik. Leveres fra STK 500 forsyningen. 12V: 12V forsyningen benyttes primært til at forsyne de to MOSFET-driverkredse. -12V: Benyttes ikke. 36V: Bruges af MOSFET-driverkredsene til at åbne gates med. Det var et problem at få lavet 36V i et system, hvor vi ellers kun har 24V til rådighed. En simpel og effektiv løsning var at benytte en DC-DC konverter, der laver 24V om til 12V. For at dette trick kan lykkes, er det et krav at DC-DC konverterens output er galvanisk 2 adskilt fra dens input. Når dette er tilfældet, kan man koble de 12V fra outputtet oveni de 24V, der allerede eksisterer. Hvilket medfører at der nu er 36V i forhold til stel. Dette trick virkede perfekt, og vores problem med at skaffe motorkontrollerne 36V var løst. 24V: Dette er de 24V som MOSFETerne åbner for, altså den stærkstrøm som driver motorerne. KONSTRUKTIONEN Motorerne har været toneangivende for designet af konstruktionen. Da motorerne er forholdsvis store, er det en udfordring at holde konstruktionen så lille som muligt. Et andet problem er, at der i toppen af gearhuset er et lille hul, som udligner det overtryk der må komme i gearingen under kørsel. Vi vil gerne have en konstruktion, hvor man ikke står for højt over centeraksen på hjulene, men dette ville i så fald betyde, at motorerne skulle vende mere eller mindre på hovedet, i forhold til den måde de sad i kørestolen. Dette gav os et problem med oliehullet. Når motor og gearkonstruktionen vender nedad, løber olien ud af gearingen. Vi diskuterede flere løsninger på dette problem, bl.a. om det var muligt at lave en snorkel, som kunne flytte hullet eller lave en prop, som kunne lukke hullet. Løsningen på problemet blev at tømme motorerne for olie, da vi vurderede, at ikke vil blive brugt i et omfang, hvor dette ville være et problem. Dog skal man være opmærksom på at give gearingen olie en gang imellem. 2 Ved galvanisk adskillelse forstås det at der ikke er direkte forbindelse mellem inputtet og outputtet, typisk vil overførelsen bestå vha. magnetfelter eller lys. Version 1 side 16 af 38

17 Figur 4 Motor, gear og hjul konstruktion For at holde produktionstiden og kompleksiteten nede, har vi valgt et meget simpelt design. Konstruktionen er reelt bare en kasse som motorerne er monteret på. Da er en prototype, har filosofien været fleksibilitet frem for æstetik, hvorfor kasse-designet her har været optimalt. Alle komponenter er fastgjort vha. enten velcrobånd eller strips. På den måde kan man nemt flytte rundt på, eller skifte komponenterne. Figur 5 skitse Vi har valgt at få lavet konstruktionen i aluminium. Dette giver en lettere konstruktion end hvis den var lavet i stål. Selve kassen er blevet bukket af en aluminiumsplade, og for stabilitet er der lavet en ramme me i toppen af kassen i aluminiumsprofilrør. Selve motorbeslagene har vi ladet smeden konstruere selv. Det tog omkring halvanden måned før konstruktionen var færdig. Her viste vores uerfarenhed i konstruktionsdesign sig. Pga. kassen, kunne konstruktionen ikke tilte mere end ca. 10 grader til hver side. Dette er et problem, da selv den mindste kantsten ville være en uoverkommelig forhindring for. Vi fik derfor ændret lidt på kassens design, så der nu er ca. 20 graders tilt til hver side. Derudover konstruerede vi et kontrolpanel, hvor det er muligt at starte og stoppe. Der er også et lille joystick til højre/venstre styring. Derudover er der et RS-232 stik, så det er hurtigt og nemt at flashe nyt software i microcontrolleren. Version 1 side 17 af 38

18 Figur 6 Kontrolpanel Vi har 2 konfigurationer, enten med en akrylplade eller metalplade til at stå på. Figur 7 med akrylplade Version 1 side 18 af 38

19 Figur 8 med metalplade MÅLING AF HÆLDNINGSVINKEL Det at måle en hældningsvinkel, er i princippet ikke så svært. Flere nyere mobiltelefoner og kameraer kan dette. De benytter et eller flere accelerometre. Et accelerometer måler acceleration i g, som navnet også antyder. Hvis et accelerometer er placeret korrekt i forhold til de akser den måler på og jorden, kan den bruges til at måle en hældningsvinkel vha. tyngdeaccelerationen. Men i vores kontekst vil dette ikke kunne fungere alene, da vi også introducerer en horisontal acceleration, når vi bevæger os. Denne horisontale acceleration vil komme med i målingerne, og give et forkert billede af hældningsvinklen. For at løse dette problem, skal vi bruge et gyroskop. Gyroskopet måler rotationshastighed i grader/sekund. Det vil sige gyroskopet ikke påvirkes af den horisontale acceleration og vil derfor kunne give os et klart billede af hvor mange grader vi har bevæget os i løbet af en bestemt tid. Dette giver dog andre problemer. Et gyroskop vil aldrig kunne måle 0 præcist, hvilket kaldes drift. For at måle vinklen vha. et gyroskop, bliver man nødt til at summere målingerne over tid. Måden man gør det på er ved at starte et stopur mellem hver måling. Når man har en ny måling, forholder man den til tiden der er gået siden sidste måling. Dette resultat summeres hele tiden, og dermed har man et billede af hældningsvinklen. Dette giver dog nogle problemer. For det første skal man vide hvor man starter, da gyroskopet kun måler rotationshastighed og ikke vinkel. Et andet problem er, at den drift et gyroskop har, også vil komme med i summeringen. Det vil sige, at jo længere tid der går, des mere usikker bliver hældningsvinklen. En kombination af disse to sensorer vil være den bedste løsning, da de to sensorer opvejer hinandens svagheder. Gyroskopet påvirkes ikke af den horisontale acceleration og accelerometret drifter ikke. Version 1 side 19 af 38

20 VALG AF SENSORER Med valg af sensorer havde vi ikke det store erfaringsgrundlag. Vi vidste vi skulle bruge et accelerometer og et gyroskop, men derudover var vi helt nye i felten. Vi valgte derfor at kigge et lignende projekt over skulderen. Den løsning, der var mest hensigtsmæssig, var en hjemmelavet SegWay, hvor konstruktøren havde erfaringer med yderligere en DIY. Han havde derfor gjort sig nogle praktiske erfaringer omkring valg af sensorer. I hans anden version af en SegWay, var det især valget af sensorer, han havde ændret i. På baggrund af hans erfaringer har vi valgt følgende sensorer: Accelerometer: ADXL320 ±5g fra Analog devices. Denne sensor kan måle op til ±5g på 2 akser, og kan købes på et færdigt lille print. Grunden til at der er valgt en sensor der kan måle en høj g-påvirkning, er for at sensor ikke så nemt saturerer, når SegWay en kører over bump eller lignende. Gyroskop: CRS03-02 Angular Rate Sensor. Dette er en dyrere sensor, men også meget præcis. Sensoren drifter ikke mere end ±0,55 /s. Begge sensorer er analoge og varierer deres output spænding i forhold til det de måler. For at vi kan aflæse sensorerne, skal vi lave en analog/digital konvertering af denne spænding. Derefter omsættes den aflæste værdi til reel data. ANALOG DIGITAL KONVERTERING [ADC] ADC-driveren er skrevet specifik til dette projekt. Der er 3 input fra hhv. accelerometer, gyroskop og joystick. A/D konverteringerne laves kontinuert, da løbende skal beregne hældningsvinklen samt PWM ud fra accelerometret og gyroskopet. Disse to input er derfor prioriteret højere end inputtet fra joysticket. Det anbefales på det kraftigste at læseren kaster et blik på ADC delen i systemdesignrapporten, hvor bl.a. udledningen af ADC præcision og ADC frekvensen samt tilhørende design er uddybet. Version 1 side 20 af 38