Cykelstiplan for Vordingborg Kommune

Transcription

2009
DIY SegWay Projektrapport
Jesper Aagaard Vuholm 04230
Daniel Christoffersen 06523
29-05-2009
DIYS
Forfattere:
Jesper Aagaard Vuholm 04230 & Daniel Christoffersen 06523
Vejleder:
Henning Hargaard
Projektnummer:
Dokument-id: (filnavn)
Antal sider:
Kunde:
08126
Projektrapport.pdf
38
IHA
Jesper Aagaard Vuholm
Daniel Christoffersen
Version 1
side 2 af 38
DIYS
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
DIYS
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
DIYS
INDHOLDSFORTEGNELSE
Forord ................................................................................................................................................................................. 4
Indledning ........................................................................................................................................................................... 7
Projektbeskrivelse............................................................................................................................................................... 8
Projektafgrænsning ........................................................................................................................................................ 8
Projektgennemførelsen .................................................................................................................................................. 9
Overordnet tidsplan.................................................................................................................................................... 9
Metoder ....................................................................................................................................................................... 11
Extreme programming XP ......................................................................................................................................... 11
Rational Unified Process RUP ................................................................................................................................... 12
Specifikations- og analysearbejdet............................................................................................................................... 12
Kørestolen ................................................................................................................................................................. 13
Motorstyringen ......................................................................................................................................................... 15
Konstruktionen ......................................................................................................................................................... 16
Måling af hældningsvinkel ........................................................................................................................................ 19
Regulering af motorerne ud fra den målte hældningsvinkel .................................................................................... 25
Software.................................................................................................................................................................... 26
Designprocessen .......................................................................................................................................................... 29
Udviklingsværktøjer ..................................................................................................................................................... 29
Generelt .................................................................................................................................................................... 29
PC Udviklingsværktøjer ............................................................................................................................................. 30
mobil Udviklingsværktøjer ........................................................................................................................................ 30
Microcontroller udviklingsværktøjer software ......................................................................................................... 30
Microcontroller udviklingsværktøjer hardware ........................................................................................................ 30
Resultater ..................................................................................................................................................................... 31
Diskussion af opnåede resultater ................................................................................................................................. 32
Opnåede erfaringer ...................................................................................................................................................... 32
Gcc i Eclipse .............................................................................................................................................................. 32
Version 1
side 5 af 38
DIYS
DC motor driver ........................................................................................................................................................ 33
Software filtrering ..................................................................................................................................................... 33
PD regulering ............................................................................................................................................................ 33
Windows Presentation Foundation .......................................................................................................................... 33
BlueTooth ................................................................................................................................................................. 33
ADC Fejl grundet overclockning ................................................................................................................................ 33
ADC Fejl grundet Interrupt problem ......................................................................................................................... 33
STK500 afbryderen ................................................................................................................................................... 34
Projektets fortræffeligheder ........................................................................................................................................ 34
Bluetooth kalibrering ................................................................................................................................................ 34
Konstruktionen ......................................................................................................................................................... 34
Motorstyringen ......................................................................................................................................................... 34
ADC konstruktionen .................................................................................................................................................. 34
Hældningsvinklen ..................................................................................................................................................... 34
Forslag til forbedringer af DIYS ..................................................................................................................................... 35
Konklusion ........................................................................................................................................................................ 35
Referencer ........................................................................................................................................................................ 37
Net kilder ...................................................................................................................................................................... 37
Bøger ............................................................................................................................................................................ 37
Bilag .................................................................................................................................................................................. 38
Vinkelestimering........................................................................................................................................................... 38
Logbog .............................................................................................................................................................................. 38
Version 1
side 6 af 38
DIYS
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
DIYS
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 2008. 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 45-55.000kr.
Vi vil gerne vise at man kan lave en SegWay selv, til en noget anden pris, anslået pris på 6-9.000kr.
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
DIYS
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 10.000kr.
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
DIYS
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
Test
Udvikling af
software til
MIC
Finde og bestille
komponenter
Uge 7
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.
Test
Udvikling af
software til
mobil
Ledningsnet
Uge 14
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
DIYS done
Uge 19
Rapportskrivning
Version 1
Uge 22
side 10 af 38
DIYS
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
•
•
DIYS
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 DIYS 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 DIYS 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
DIYS
KØRESTOLEN
Vi fik doneret en kørestol af Roltec, som vi har brugt som base for DIYS. 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
DIYS
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 DIYS 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
DIYS
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 DIYS 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
1
Motorkontrollernes funktion er at omsætte PWM 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
DIYS
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
2
laver 24V om til 12V. For at dette trick kan lykkes, er det et krav at DC-DC konverterens output er galvanisk
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 DIYS 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
DIYS
Figur 4 Motor, gear og hjul konstruktion
For at holde produktionstiden og kompleksiteten nede, har vi valgt
valgt et meget simpelt design. Konstruktionen er reelt
bare en kasse som motorerne er monteret på. Da DIYS
YS er en prototype, har filosofien været fleksibilitet
fle
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 DIYS 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
ramme 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
ste vores uerfarenhed i konstruktionsdesign sig. Pga. kassen, kunne
konstruktionen ikke tilte mere end
d ca. 10 grader til hver side. Dette
D
er et problem, da selv den mindste kantsten ville
være en uoverkommelig forhindring for DIYS. Vi
V fik derfor ændret lidt på kassens design,, så der nu er ca. 20 graders
tilt til hver side. Derudover konstruerede
truerede vi et kontrolpanel,
kontrolpanel, hvor det er muligt at starte og stoppe DIYS. Der er også et
e
lille joystick til højre/venstre styring. Derudover er der et RS-232
R 232 stik, så det er hurtigt og nemt at flashe nyt software i
microcontrolleren.
Version 1
side 17 af 38
DIYS
Figur 6 Kontrolpanel
Vi har 2 konfigurationer, enten med en akrylplade eller metalplade til at stå på.
Figur 7 DIYS med akrylplade
Version 1
side 18 af 38
DIYS
Figur 8 DIYS 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
DIYS
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 DIYS 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
DIYS
HÆLDNINGSVINKEL
Vi har valgt at benytte os af en PD kontrol til at regulere motorerne. Forklaringen af PD regulering, og hvorfor vi har
valgt en PD regulering, findes i afsnittet om regulering.
Vores regulering vil se ud som følgende
Motor output = Kp*vinkel + Kd*vinkelhastighed
Omregningen af aflæsningerne fra sensorerne til brugbare data gennemgås i systemdesignet under afsnittet
”Aflæsning af vinkelsensorer”. Kort fortalt har vi fundet en lineær sammenhæng mellem den målte værdi fra A/D
konverteringen og henholdsvis vinkel for accelerometret og vinkelhastighed for gyroskopet.
For at lave reguleringen, som skal holde DIYS i balance, skal vi bruge to ting: Hældningen, og hastigheden af
ændringen af denne hældning. Man kan illustrere det som følgende.
Vi har de 2 input, som bliver sendt igennem en black box. På den anden side, får vi en hældningsvinkel og en vinkel
hastighed ud.
Med de to sensorer vi har, er den åbenlyse løsning som følgende:
Vinkelhastigheden har vi direkte fra gyroskopet, så dette kræver ikke meget beregning. Vi mangler blot en pålidelig
hældningsvinkel.
Der er flere måde at måle hældningsvinklen på, men ikke alle metoder er lige optimale for vores system. Den direkte
tilgang er at overføre accelerometerværdien direkte. Dette ville virke, hvis bare DIYS står stille. Accelerometret
fungerer vha. tyngdekraften. Desværre kan den ikke skelne mellem tyngdeacceleration og horisontal acceleration.
Dette medfører, at når vi bevæger os bliver målingerne ukorrekte, pga. denne horisontale kraft, som motorerne
introducerer.
Version 1
side 21 af 38
DIYS
For at løse dette problem, kunne man implementere et lavpasfilter på accelerometret.
f.eks. som en simpel gennemsnitsmåling.
0,75 · 0,25 · Dette vil fjerne de korte udsving som den horisontale acceleration giver, men lade de længere udsving fra
tyngdekraften slippe igennem. Dette giver en forsinkelse i målingerne, så denne løsning er heller ikke den optimale.
En tredje måde kunne være kun at bruge gyroskopet.
Dette kan gøres ved at lave en numerisk integration af målingerne fra gyroen.
· Dette giver dog et problem, da gyroens nulpunkt altid vil flytte sig lidt – det, som kaldes gyro drift. Denne drift vil lige
så langsomt blive akkumuleret til et større problem. Så denne metode er heller ikke optimal.
En fjerde løsning kunne være ”magi” også kaldet Kalman filtrering.
Version 1
side 22 af 38
DIYS
Kalman filtrering er en matematisk/fysisk model som, hvis lavet rigtigt, kan estimere hældningsvinklen og
vinkelhastighed ud fra de to sensorinputs. Vi har ikke den fornødne viden til at konstruere filteret og alle vi har
snakket med om Kalman filtrering siger, at det skal vi ikke give os i kast med, da det er meget komplekst, og et projekt
i sig selv. Så Kalman filtrering er udelukket fra dette projekt!
Den femte løsning er at kombinere de to sensorer.
Hvis vi laver lavpasfilteret på accelerometeret og et højpasfilter på den numeriske integration af gyroskopet, vil vi
opnå både at fjerne den horisontale acceleration, da den er forstyrrelser over kortere tid, og gyrodriften, som er
forstyrrelser over længere tid. Dette kan gøres på den som følgende.
· · 1 · Filterkonstanten a skal selvfølgelig indstilles til den ønskede effekt. Dette har vi fundet nemmest ved at lave
beregningseksempler og derefter praktiske forsøg. Bestemmelsen af filterkonstanten a, kan findes ved at bestemme
tidskonstanten for filteret, dvs. den grænse, hvor vi tror mere på den ene sensor frem for den anden.
Sammenhængen mellem tidskonstanten τ og filterkoefficienten a er som følgende.
· 1
Eksempel:
0,98 · · 0.005 1 0,98 · Hvor dt er tiden mellem hver udregning. I dette eksempel reguleres der 200 gange i sekundet, så dt er 1/200 = 0,005.
Her kan vi regne tidskonstanten ud, altså tidsgrænsen for, hvor når vi skal tro på gyroen eller accelerometret.
0,98 · 0,005
0,245
1 0,98
Dette betyder at 0,245s er grænsen for hvornår vi stoler på gyroen frem for accelerometret. Hvis accelerometret
holder den samme værdi i over 0,245s, vil det være accelerometret vi stoler på, og ellers er det gyroskopet. En
tydeliggørelse af dette, kan ses på følgende figur.
Version 1
side 23 af 38
DIYS
Her kan man se at jo større a er, des mere stoler man på gyroskopet.
Der er to fremgangsmåder til at bestemme filterkoefficienterne: Enten bestemmer man sig for en tidskonstant, eller
også prøver man sig frem med nogle test data. Vi prøvede først at bestemme os for en tidskonstant, og derefter
rettede vi på a, indtil den ønskede effekt var opnået.
Gennemløbstiden for vores regulering er ca. på 3,7ms. Vi ved fra databladet for gyroskopet, at den er meget præcis,
og drifter ikke mere end ±0,55°/s, så vi vil gerne bruge gyroskopet meget, ved at vælge en forholdsvis høj tidskonstant
på 0,8s. Så skal det fyldes i formlen, så vi kan udregne vores filterkoefficienter.
0,8
0,995
0,8 0,0037
Herefter kan vi konstruere filtret, og teste det.
0,995 · · 1 0,995 · 0,995 · · 0,005 · Efter filterkoefficienten var fundet implementerede vi filtret og lavede nogle tests på vores vinkeltestopstilling.
Følgende figur viser tydeligt resultatet.
I den grønne markering, har vi forsøgt at lave en horisontal acceleration, hvilket kan ses ved at accelerometret giver
nogle små udslag, men gyroskopet læser nul. I den nederste graf er de to sensorers bud på hældningsvinkel afbilledet,
Version 1
side 24 af 38
DIYS
samt den filtrede vinkel, her både filtreret på PC og på microcontrolleren. I den blå markering, kan man se, at
gyroskopet drifter en smule, men den holder filteret styr på og fjerner driften. Det skal dog siges at ’Gyro angle Est’ er
udregnet i Microsoft Excel, og med en fast dt, som godt kan afvige fra den egentlige dt. Derfor kan man også se, at
’MIC angle’ er en bedre estimering af vinklen, end den Microsoft Excel udregner. Men alt i alt har vi den ønskede
effekt - vi får fjernet den horisontale acceleration, samt gyrodriften. Så filtret fungerer efter hensigten og vi kan
fortsætte med at få lavet en regulering af motorerne ud fra denne vinkel.
REGULERING AF MOTORERNE UD FRA DEN MÅLTE HÆLDNINGSVINKEL
Vi har besluttet at bruge en PD regulering, pga. egne erfaringer fra Lego SegWay’en. Desuden kan vi se på lignende
projekter, at denne form for regulering løser opgaven ganske udmærket. Så vi holder os til det vi ved der virker, samt
er simpelt at implementere. Og begge dele opfylder PD reguleringen.
For at holde balancen, skal vi have omsat vores målte hældningsvinkel til en reaktion på motorerne. Det vil sige, at når
vi tipper fremad, skal motorerne køre nøjagtigt så stærkt fremad at DIYS ikke vælter. Men hvis motorerne kører for
stærkt, vil DIYS stå og oscillere og ikke køre fremad.
PD reguleringen består af 2 led. P-leddet er den proportionelle afvigelse, altså hvor meget vi skal reagere på baggrund
af den aktuelle afvigelse. Denne styres af en konstant, Kp, som multipliceres med den aktuelle afvigelse. Altså vil den
fungere som en forstærkning af afvigelsen. Dette vil i princippet kunne fungere alene, men vil nok give en noget
oscillerende, og ikke særlig behagelig, kørsel. Dette løses med D-leddet, som er den afledte funktion af afvigelserne
over tid. Med andre ord fortæller dette led os noget om, hvilken retning vi bevæger os i, og med hvilken hastighed vi
gør det. Dette led bruges som en dæmper på P-leddet. Reguleringen vil blive mere blød, og give en mere rar
fornemmelse når man kører på DIYS.
Den matematiske formel for PD reguleringen er følgende:
" #$ #%
Man kan sige at P-leddet vil fungere som en fjeder, og D-leddet som en dæmper (se Figur 9 regulering). Ved at styre
disse to led med to konstanter, Kp og Kd, kan vi bestemme hvor aggressivt vi vil regulere.
Figur 9 regulering
Implementeringen af reguleringen er meget simpel, og vi har gjort som følgende
Version 1
side 25 af 38
DIYS
"'" #$ · ()* #% · ()*+ )+
Der er flere måde at finde frem til de rette Kp og Kd konstanter. Vi regnede os først frem til nogle konstanter, som vi
vidste ikke var for aggressive og derefter har vi, via vores PC eller mobil program, prøvet os frem.
60
40
20
0
-20
Angle
0
5
10
15
20
25
30
35
40
PWM
-40
-60
-80
Her er PWM afbilledet sammen med den udregnede vinkel. Dog er PWM afbilledet med en faktor 10, altså PWM/10,
for at kunne have de to grafer sammen. I overstående regulering er Kp=25 og Kd=2. Disse 2 tal er vi kommet frem til,
ved at lave nogle forskellige beregninger, som ligner den ovenstående. D-leddet bidrager til at vi reagerer på forkant
med ændringerne. Dermed får vi en god reaktion på ændringerne i hældningsvinklen, men også en blød og behagelig
reaktion.
Vores motordriver kan giver et output på mellem -255 og 255 til motorerne. Den overstående PWM udregning vil
derfor bliver klippet til, så den er indenfor de givne grænser, inden signalet sendes til motorerne.
SOFTWARE
Når alle de trivielle ting er overstået, som at læse værdier fra sensorerne og styre motorerne, er systemet egentlig
meget simpelt og fylder ikke mange liniers kode. Princippet kan illustreres som følgende.
Version 1
side 26 af 38
DIYS
På baggrund af erfaringerne fra Lego projektet, vidste vi at regulering godt kunne være noget besværlig at få på plads.
Derfor har vi udviklet et bluetooth interface, hvor det er muligt at se data fra beregningerne fra DIYS, samt mulighed
for at ændre på de to gain konstanter i PD-reguleringen (Kp og Kd). Derudover er det muligt at stille på en gain
konstant til styringen Ks. Denne konstant multipliceres med joystickets ADC værdi. På denne måde har vi kunnet
”tune” os ind på nogle indstillinger, som giver en behagelig fornemmelse, når man kører.
Når DIYS tændes, går der lige et par sekunder inden den er klar til at køre. Når DIYS startes, går den igennem en
initialiseringsfase, hvor bl.a. vinklen bliver initialiseret. Dette bliver gjort ved at midle over accelerometeret, og
derefter initialisere vinklen med denne værdi. Dette gøres for at undgå unødige pulsning af motorerne, pga. en forkert
startvinkel. Afslutningen af initialiseringen markeres med et beep og herefter er DIYS klar til brug.
Kommunikationen foregår via en GridConnect FireFly serial to Bluetooth adapter. Grunden til at vi valgte denne
løsning, var igen at holde kompleksiteten nede. Da FireFly adapteren er en transparent seriel til Bluetooth adapter,
skal vi blot lave koden, som om det var en almindelig kablet seriel forbindelse. Så sørger FireFly’en for at sende det via
Bluetooth.
Til streaming af data, har vi konstrueret en simpel protokol, hvor karakteren ’,’ benyttes til at adskille de forskellige
værdier, karakteren ’$’ markere at datadelen af pakken er slut. Det sidste i pakken er den medsendte
checksumsberegning. Denne checksumsberegning sker både på microcontrolleren og på PC eller mobil. Beregning er
meget enkel: Efter datadelen af strengen er lavet, summeres hver enkelt karakter af strengen i microcontrolleren
indtil transmission-end karakteren ’$’ nås. Resultatet af denne summering placeres efter ’$’, hvorefter pakken sendes
afsted. Hos modtageren vil der foregå akkurat den samme checksumsberegning af den indkomne pakke. Forskellen er
Version 1
side 27 af 38
DIYS
at her sammenlignes resultatet af summeringen blot med den medsendte checksum. Passer de ikke, kasseres pakken
og næste pakke afventes. Passer checksumsberegningen derimod, sendes pakken videre til fortolkning i systemet.
Figur 10 Stream datapakke
Kommunikationen den anden vej, altså fra PC eller mobil til DIYS, foregår via nogle få kommandoer. Vi har lavet en
kommandoprotokol, som ser ud som følgende:
[Kommando][Værdi]~
Mulige kommandoer er
Kommando
P
D
S
T
Beskrivelse
Ny værdi til Kp, værdi sendes over med en faktor 10
Ny værdi til Kd, værdi sendes over med en faktor 10
Ny værdi til Ks, værdi sendes over med en faktor 10
Toggle Bluetooth Radio [ ON / OFF ], starter eller stopper stream
For at bekræfte at microcontrolleren har modtaget og forstået kommandoer, har vi implementeret en buzzer, som
kan give en auditiv tilkendegivelse på kommandoer. Dette er igen en erfaring vi har taget med fra Lego projektet, hvor
netop denne tilgang viste sig meget brugbar.
På PC programmet er det muligt at se live data fra DIYS visualiseret på nogle XY-plots. Derudover er det muligt at
sende kommandoer til DIYS og på den måde konfigurere den. Der er også mulighed for at logge valgfrit data fra DIYS.
Disse data bliver logget direkte i et Excel ark.
Efter DIYS kom op at køre kunne vi hurtigt se, at det ville være rart med en mere mobil løsning, når der ændres på
konstanterne i DIYS. For at løse det problem, lavede vi et lille program til en Windows Mobile, hvorfra det er muligt at
ændre på konstanterne i DIYS. Det er også muligt at se live data herfra. Denne kommunikation foregår også via
Bluetooth. Programmet har vist sig ganske anvendeligt, da det nu er hurtigt og nemt at ændre på konfigurationen af
DIYS.
Vi har også konstateret, efter at have fået en del køretimer, at der er en sammenhæng mellem hvor lang tid man har
kørt og hvor følsom regulering skal være. Hvis det er første gang man prøver DIYS, skal den ikke være så følsom, da
man lige skal have fornemmelsen af hvordan det fungerer. Og hvis DIYS er for følsom når man prøver første gang, har
man tendens til at prøve at holde balancen selv og dette kan give en noget oscillerende kørsel. For at gøre første tur så
rar som muligt, skal reguleringen derfor ikke være for aggressiv. Hermed mister man dog også lidt af topfarten og
reaktionstiden. Når man har fået lidt øvelse føles det rarere, hvis DIYS reagerer lidt mere aggressivt. For hurtigt at
kunne ændre på disse indstillinger, har vi implementeret tre profiler på mobilen, som man nemt kan skifte imellem.
Version 1
side 28 af 38
DIYS
DESIGNPROCESSEN
Figur 11 Designprocessen
Designprocessen har været noget anderledes end vi har bekendt med hidtil. Overstående figur er en skitse over den
designproces vi har været igennem. Vi startede med at analysere kørestolen og vurdere hvad vi kunne bruge og hvad
vi skulle købe. Derefter lavede vi en skitse af konstruktionen, da vi vidste værkstedet skulle i gang så tidligt som muligt,
hvis de skulle have mulighed for at nå det. Efter værkstedet var sat i gang og komponenterne bestilt, gik vi i gang med
udviklingen af softwaren. Her har vi kørt to parallelle forløb. Jesper havde hovedansvaret for softwareudviklingen til
microcontrolleren og Daniel havde hovedansvaret for softwareudviklingen til PC og mobil. Da konstruktionen var
færdig og alle komponenter ankommet, begyndte vi at samle en prototype og trække ledninger til det hele. Herefter
begyndte vi at lave nogle målinger af hældningsvinkel i en testopstilling. Da vinkelmålingen var på plads, lavede vi PD
reguleringen. Da vi var tilfredse med reguleringen, prøvede vi at sætte det hele sammen. Da vi kunne konstatere at
det hele fungerede som forventet, lavede vi test og tweaks, hvor vi har fundet konstanter til reguleringen som er
behagelige.
UDVIKLINGSVÆRKTØJER
GENERELT
•
•
Bray Terminal
o Et terminalprogram, som vi har brugt til at skrive og læse data til og fra DIYS. En hurtig terminal,
intuitiv og let at bruge. Desuden har den en god log funktion, som blev benyttet til at opsamle data
med, til senere analyse.
Microsoft Office 2007
o Word
Brugt til dokumentationen
o Excel
Brugt til beregninger, logging og simulering
o Visio
Brugt til diverse diagrammer
Version 1
side 29 af 38
•
•
•
•
•
DIYS
Paint.net
o Gratis tegneprogram, har mulighed for at arbejde i layers
TortoiseSVN, AnkhSVN og SubClipse
o Klienter til versionsstyring af softwaren
Googlecode
o Versionsstyring – vi har oprettet et projekt på code.google.com. Dette har fungeret meget fint, dog
var det lidt kompliceret at sætte op i Eclipse.
Dropbox
o Gratis plads på nettet, hvor man kan dele filer og mapper. Indeholder en simpel versionsstyring af de
delte filer. Har været en god oplevelse, og virkelig lettet delingen af filer.
Wordpress
o Et weblog værktøj, som vi har brugt som logbog. Kan ses på http://diys.daller.dk
PC UDVIKLINGSVÆRKTØJER
•
•
Microsoft Visual Studio 2008
o Har fungeret upåklageligt. Der er udviklet i C#.net 3.5 sp1
Microsoft Expression Blend 2.5
o Værktøj til at lave WPF brugerflader visuelt
MOBIL UDVIKLINGSVÆRKTØJER
•
•
Microsoft Visual Studio 2008
o Har igen fungeret upåklageligt. Der er udviklet til Windows Mobile 6.1 i C#.net 3.5 Compact
HTC Touch Diamond mobiltelefon
MICROCONTROLLER UDVIKLINGSVÆRKTØJER SOFTWARE
•
•
•
Eclipse IDE
o Super open source udviklingsmiljø, der indeholder mange gode elementer, man normalt ikke finder i
C udviklingsmiljøer.
WinAvr Gcc compiler
o WinAvr installeres for at få GCC compileren og dennes system paths sat korrekt på en nem og
elegant måde.
The AVR Eclipse Plugin
o Open source plugin til Eclipse, der i kombination med GCC compileren, muliggør udvikling på
størsteparten af AVRs microcontrollere i Eclipse udviklingsmiljøet.
MICROCONTROLLER UDVIKLINGSVÆRKTØJER HARDWARE
•
•
•
•
20 MHz Oscilloskop
o Flittigt benyttet i forbindelse med diverse tests af motordriveren.
Multimeter
o Ofte benyttet i forbindelse med fejlsøgning af hardwaren.
Shunt modstand
o Benyttet sammen med multimetret til at bestemme strømdræn med.
Laboratorie strømforsyning
o Brugt i diverse forskellige testopstillinger.
Version 1
side 30 af 38
•
DIYS
STK500 kit
o Projektets hardware platform.
RESULTATER
DIYS fungerer! Den kan holde balancen, den kan køre frem og tilbage, og dreje med hjælp af joysticket. Tænde og
slukke vha. nøglen. Afbryde motorerne vha. dødemandsknappen. Desuden kan man følge med i, hvad der sker vha.
Bluetooth streamen, både på PC og på mobilen. Alt i alt fungerer det og skal opleves. På den medfølgende CD, er der
nogle billeder og video af DIYS.
En af de vigtigere dele af DIYS er vinkelmåling. Hvis vi ikke kan aflæse en stabil og præcis vinkel, vil det være meget
svært at holde balancen, da vinklen er den eneste reference DIYS har til omverdenen. Følgende tabel viser aflæsninger
af vinklen vha. henholdsvis DIYS og den mekaniske vinkelmåler fra testopstillingen. Vi har kun testet indenfor ±20°, da
det er i dette område vinkelmålingen er optimeret til.
Vinkel aflæst med mekanisk vinkelmåler
-20°
-15°
-10°
-5°
0°
5°
10°
15°
20°
DIYS
-21°
-15°
-10°
-5°
0°
5°
10°
15°
20°
Afvigelse
1°
0°
0°
0°
0°
0°
0°
0°
0°
Et af målene for dette projekt, har været at holde et budget på under 10.000kr. Budgettet for projektet ser ud som
følgende
Enhed
Motor
Hjul
Motorstyring
Gearing
Aluminiumskonstruktion
NiMH
Lader NiMH
Relæer
Bluetooth
Dødemandsknap
Buzzer
STK500
On/Off switch
Microcontroller
Gyro
Version 1
Enhedspris Antal Samlet pris Beskrivelse
Heavy duty HW & konstruktion
kr 0,00
2
kr 0,00
Roltec
kr 0,00
2
kr 0,00
Roltec
kr 0,00
2
kr 0,00
Roltec
kr 0,00
2
kr 0,00
Roltec
kr 0,00
1
kr 0,00
Lavet på IHAs værksted af IHA
Batterier
kr 744,74
4
kr 2.978,98 NiMH 12V 10Ah battery pack
kr 0,00
4
kr 0,00
Inkluderet i batteripakken
Elektronik
kr 0,00
2
kr 0,00
Roltec
Transparent Gridconnect firefly udlånt af
kr 0,00
2
kr 0,00
HH
kr 0,00
1
kr 0,00
Roltec
kr 0,00
1
kr 0,00
Fra IHA
kr 0,00
1
kr 0,00
Fra IHA
kr 30,94
1
kr 30,94
Standard SPST Key Switch
kr 64,00
1
kr 64,00
ATmega644PV-10PU MCU DIL40
kr 1.602,00 1
kr 1.602,00 CRS03-02 - Angular Rate Sensor
side 31 af 38
Accelerometer
DC/DC 24V-12V Konverter
Thumb Joystick
I alt
DIYS
kr 244,00
kr 175,00
kr 22,63
1
1
1
30
kr 244,00
kr 175,00
kr 22,63
kr 5.117,54
ADXL320EB Evalboard
DC/DC-konverter TEN3-2412
Bruges til at styre dreje til højre/venstre
Til dette skal der dog knyttes en bemærkning, told og transport er ikke indregnet i budget. Det er købspriser, som de
er noteret hos sælgerne. Vi har desuden brugt forskellige småting, som velcrobånd, træplader og akrylplade, som alt
sammen er fra IHA.
DISKUSSION AF OPNÅEDE RESULTATER
At vi kom mål med dette projekt, og at DIYS fungerer upåklageligt, er en klar identifikation af at vi har gjort noget
rigtigt. Gennem hele projektet har vi arbejdet disciplineret for at komme sikkert i mål. Måden vi har arbejdet på, har
helt klart været en medvirkende årsag til at vi kom i mål. Vi har ikke på noget tidspunkt bekymret os om noget vi ikke
var klar til endnu. Eksempelvist kan nævnes, at da vi arbejdede med at få motorerne til at køre, brugte vi overhovedet
ikke tid på f.eks. vinkeludregningen. DIYS er bygget op af nogle elementer som er afhængige af hinanden. Vi har ikke
lavet mere end det der var nødvendig for at løse det aktuelle problem vi stod med. Hvis vi ikke kunne styre motorerne,
så var der igen grund til at fortsætte. Så det var noget af det første vi kiggede på. Da motordriverne var på plads,
kunne vi begynde at aflæse en hældningsvinkel og det var først da det var på plads at vi begyndte at kigge på
reguleringen. Igen fordi reguleringen var afhængig af hældningsvinklen. Hele arbejdsmetoden med at lave
fundamentet først og derefter bygge ovenpå i et højt, men overkommeligt, tempo har fungeret perfekt for os.
Vinkelmålingen fungerer perfekt indenfor vores arbejdsområde. Vi skal dog sige, at testopstillingen ikke har været
optimal, da vi kun har haft en mekanisk vinkelmåler som reference. Det er meget svært at aflæse i mere end 1°
opløsning. Dette har dog vist sig at være nok. Filtreringen af de to sensorer til én vinkel, har vist at være meget
effektiv. Det er ingen drift fra gyroskopet og kun en meget lille påvirkning af horisontal acceleration. Denne
horisontale acceleration er dog så lille, at den ikke kan mærkes. Alt i alt er vi meget tilfredse med løsningen af
vinkelmålingsproblemet.
Vi har klart holdt os indenfor det budgetterede, men vi har også fået mange af de dyrere ting sponseret. Motor, gear,
hjul og motorkontrollerne fra Roltec, ville have været en meget stor post i budgettet. At Roltec har doneret kørestolen
til os har klart været udslagsgivende for at vi kunne holde budgettet. Aluminiumskonstruktionen er lavet af
værkstedet på IHA, så her har vi heller ikke måtte ud og købe en løsning. Dette ville også have været en stor post i
budgettet. Vi mener derfor stadig, at vi har lavet et prisbilligt alternativ til den originale SegWay.
OPNÅEDE ERFARINGER
Da vi har vores baggrund i softwareverdenen, er langt de fleste erfaringer i dette projekt opnået gennem det
omfattende hardwarearbejde. Det at arbejde med et så hardwareorienteret projekt, har til tider givet anledning til grå
hår, også selvom vi begge er under 30! Det skal så rettelig nævnes, at da vi så endelig fik ”hul” på diverse
hardwareproblemer, var glæden også stor. Nedenfor er de væsentligste opnåede erfaringer beskrevet:
GCC I ECLIPSE
Det var en smule bøvlet at få Eclipse til at virke med gcc kompileren, versionsstyringen samt kodebackup. Man skulle
selv installere diverse plugins, og herefter pille ved en del forskellige indstillinger, for at få det sat perfekt op. Heldigvis
var der meget gode guides, og vejledninger at finde på nettet. Da det først kørte, var tiden brugt på opsætningen
glemt. Det var uden tvivl, det mest komfortable og elegante c udviklingsmiljø vi til dato har arbejdet med.
Version 1
side 32 af 38
DIYS
DC MOTOR DRIVER
Der er draget gode erfaringer i arbejdet med at få lavet en motordriver til DC motorerne, hvor der gennem hele
forløbet blev lavet grundige signalanalyser vha. Oscilloskopet. Efter at driverne var færdig lavet, var der en god
forståelse af hele emnet.
SOFTWARE FILTRERING
Det har bestemt ikke været let at få vores høj-lavpasfiltrene til at fungere perfekt. Der er blevet investeret meget tid i
forståelse af filterteorien. Dette var nødvendigt for at kunne beregne korrekte filter konstanter. Da filteret først var
korrekt indstillet, og implementeret i softwaren, virkede det forbløffende godt.
PD REGULERING
Igen har denne form for regulering været en god oplevelse. På baggrund af de erfaringer vi havde fra Lego projektet,
implementerede vi et trådløst debug miljø, DIYS debug, hvor det er muligt at følge med i hvad der sker, og ændre på
reguleringskonstanterne. Dette har været en stor hjælp i forbindelse med fintuningen af reguleringen, som ellers kan
være en noget besværlig og tidskrævende proces.
WINDOWS PRESENTATION FOUNDATION
Det har været en rigtig god oplevelse at lave brugerflader i Windows Presentation Foundation. Især Microsoft
Expression Blend har været en god oplevelse. Det er meget intuitivt og let at gå til. Alt det visuelle laves visuelt, hvilket
gør udviklingen af brugerfladen meget hurtig.
BLUETOOTH
BlueTooth modulet fra Gridconnect var en fornøjelse at arbejde med, det tog en god time at få den korrekt opsat vha.
jumperne, og herefter kørte modulet upåklageligt. Efter akrylpladen blev monteret, fik vi også en noget bedre
rækkevidde, hvilket bare gjorde oplevelsen med adapteren endnu bedre. Vil helt sikkert komme med i relevante
fremtidige projekter.
ADC FEJL GRUNDET OVERCLOCKNING
Tidligt i projektforløbet blev der benyttet en 16Mhz krystal som clock til microcontrolleren, dette fungerede
umiddelbart fint. Denne overclockning ville give os en faktor 1,6 på antallet af gennemløb pr. sekund af vores
reguleringsloop, resultatet heraf ville medføre en mere glidende regulering. Dog begyndte der at komme
regelmæssige bit fejl i A/D konverteringerne, disse fejl kom frem under en af vores mange tests, hvor vi forventede at
den konverterede værdi skulle ligge fast på 512. Dog var værdien ca. 2 % af tiden 768 eller 256, der var altså tale om
en binær aflæsningsfejl. Mistanken rettes efter nogen tid til samplehold registrene i ADC konverterne og timingen af
disse. Da mega644P microcontrolleren ikke officielt understøtter en clock hastighed større end 10Mhz. blev 16Mhz
krystallen nu byttet ud med en 10Mhz. Dette løste problemet.
ADC FEJL GRUNDET INTERRUPT PROBLEM
Denne fejl blev IKKE fundet i forbindelse med de tests der ellers blev udført. Fejlkonverteringerne viste sig ca. hvert 5
sekund, og da vi læser 11.942 samples pr. sekund, må det betyde at fejlraten var på ca. en ud af 59.710 samples.
Fejlkonverteringerne "røbede" først sig selv i den endelige konstruktion, ved at DIYS lavede et lille hop ca. hvert 5
sekund. Dette problem havde reelt ikke nogen betydning for kørslen, men det var til stort irritation for os. Heldigvis
drejede fejlen sig om en "tanketorsk". Når vi benytter de konverterede værdier, blev de hentet direkte fra det samme
array, hvor ADC interruptet også skriver de nyeste konverteringer i. Løsningen var simpel, imens den seneste sample
Version 1
side 33 af 38
DIYS
hentes, bliver interrupts disabled, seneste sample gemmes i en variabel, interrupts enables igen, og variablen med
den seneste sample returneres. Efter dette var implementeret kørte DIYS helt perfekt uden hop eller lignende.
STK500 AFBRYDEREN
Efter at havde brændt logikkredsene på motorkontrollerne 2 gange, fandt vi ud af, at afbryderkontakten på STK500kittet, afbryder kransen på stikket, og ikke centerpinden som forventet. Vi havde, som man normalt gør, sat stel på
kransen af stikket og forsyningen i centeret. Dette betød så bare, at når vi afbrød STK500 på dens afbryder, så afbrød
vi stel, (Se evt. nederst side 6 og øverst side 7 i ’Datablad over STK500-kittet’). Hvilket så gjorde at vi fik en strøm den
forkert vej igennem motorkontrolleren, som forsynede STK500-kittet. Løsningen på dette var bare, at vende
polariteten på stikket, altså bytte om på stel og forsyning. Efter dette var gjort, har der ikke været nogen problemer.
Så helt klar en dyr og tidskrævende erfaring, som vi tager med. Heldigvis har Roltec været flinke til, at hjælpe med
fejlsøgning af motorkontrollerne, samt reparere dem.
PROJEKTETS FORTRÆFFELIGHEDER
BLUETOOTH KALIBRERING
Der er sparet - rigtig - meget tid ved at muliggøre kalibrering af diverse forskellige parametre via BlueTooth. Havde vi
ikke implementeret BlueTooth interfacet, skulle vi alternativet omprogrammere microcontrolleren hver gang, der
skulle ændres på nogle parametre. Dette har helt klart hjulpet, på det ellers stramme tidsbudget.
KONSTRUKTIONEN
Vi er stolte af den endelige fysiske konstruktion. Desuden bør panelet, der fungere som MMI, specielt fremhæves. Via
den er det muligt at komme med flere forskellige inputs til DIYS. Joystick løsningen samt placeringen fungerer rigtig
godt, og gør det meget let at styre DIYS.
MOTORSTYRINGEN
Motorstyringen bør også nævnes, der var en mange ting der skulle fungere i sammenspil, før det var muligt at få
kontrol over motorerne. Da elektronikken omkring motorkontrollerne var på plads, begyndte testen af motordriveren.
Denne driver er skrevet specielt til netop dette projekt, og løser opgaven perfekt.
ADC KONSTRUKTIONEN
Vi syntes at vores ADC implementering er en elegant og smart løsning. Hvor der er tænkt på at få hvert ADC sample
afviklet på den hurtigste måde, uden at der er gået på kompromis med andre parametre.
HÆLDNINGSVINKLEN
Kombinationen af to sensorer til en vinkel, fungere rigtig godt. Vi investerede en del tid til at løses denne opgave, da vi
vidste at det var af stor betydning for om DIYS ville fungere. Hvis vi ikke ville kunne finde den rigtige hældningsvinkel,
ville kørslen med DIYS være meget ubehagelig, hvis den overhovedet ville kunne køre.
Version 1
side 34 af 38
DIYS
FORSLAG TIL FORBEDRINGER AF DIYS
Der er helt klar plads til forbedringer af konstruktionen, rent faktisk skal konstruktionen repareres. Efter et par styrt i
overmod, er styret blevet en smule skævt, og svejsningen mellem styr og kasse er revnet. Dette kan løses ved at flytte
kraften fra styret væk fra svejsningen, og ned i selve kassen. Vi har snakket med smeden om det, men har vurderet at
det ikke er noget vi kan nå at få lavet.
Frihøjden kunne også være større. Man vil have problemer med at komme over kanter på mere end 4-5cm. Dette kan
løses ved at bruge nogle større hjul.
Drift, den ene motor er dårligere end den anden, og dette giver sig udslag i at DIYS drifter en smule til den ene side. Vi
kompenserer for dette med en drift-faktor i vores motordriver, der gør den gode motor tilsvarende dårligere. Men der
er ikke en lineær sammenhæng mellem hastighed og drift. Så faktoren løser ikke drift problemet ved alle hastigheder.
Dette kunne løses med f.eks. en ekstra gyro, som monteres så den måler sidelæns rotation. På denne måde kan man
holde styr på driften ved alle hastigheder. Denne løsning vil også løse andre problemer. Hvis man f.eks. kører over en
forhindring med det ene hjul, skal der mere kraft til den side for at komme over. Dette vil også kunne måles med det
ekstra gyroskop, og man vil kunne styre hastigheden på den enkelte motor mere dynamisk.
Det vil også være en stor forbedring, at få de fire ladere ind i konstruktionen, så det vil være nemmere at sætte DIYS til
ladning. Lige nu skal man pille låget af konstruktionen, pille batterierne fra, og sætte dem til at lade. Det er en lidt
omstændelig proces, og kunne sagtens gøres smartere.
KONKLUSION
Dette projekt har været en fornøjelse at lave. Det har hele vejen igennem være spændende og meget udfordrende.
Det har betydet rigtigt meget for os, at bevise vi kunne løse opgaven med vores softwarebaggrund. Men det har heller
ikke været uden ofre. Vi har brugt en del mere tid, end man nok normalt vil bruge på et projekt af denne størrelse.
Men det har vi været nød til, for at forstå de ting, som vi ikke har prøvet før. Samarbejdet har fungeret rigtig godt, og
vi har begge haft den samme indstilling til dette projekt, nemlig at det skulle lykkes.
Der har været mange usikkerheder i projektet. Kunne motorerne og motorkontrollere klare opgaven. Kunne vi filtrere
sensorerne til en brugbar vinkel? lave en brugbar regulering? på trods af vores manglede erfaring med begge dele.
Men med en god portion gå-på-mod, og en ingeniørmæssig tilgang til problemerne. Er de en efter en blevet løst, og til
sidst sat sammen til den endelige prototype.
Vi har ikke haft de store problemer, udover de par gange motorkontrollerne gik i stykker. Heldigvis har Roltec været
flinke til at hjælpe, når vi ikke selv har kunnet rette fejlene på motorkontrollerne. Vi har arbejdet med den filosofi, at
mindre er godt. Altså små men sikre skridt. Vi har hele vejen været meget forsigtige, da vi har at gøre med nogle
meget kraftige motorer, og stærke strømme. Denne filosofi betød så også, at første gang vi prøvede DIYS, virkede det
fuldstændig som forventet. DIYS kunne holde balancen, og man kunne køre frem og tilbage, dreje til højre og venstre.
Det var en meget tilfredsstillende følelse, at se DIYS fungerede fra første forsøg af.
Vi tager en del erfaringer med fra dette projekt, og det er sikkert ikke den sidste SegWay lignende projekt vi laver. De
emner vi har været omkring, har været udfordrende og spændende. Og man kan næste ærgrer sig over, at man ikke
har fået mere undervisning i discipliner, som filtrering, regulering og elektronik generelt.
Vi mener stadig det kunne være meget spændende, at kigge på forskellige reguleringsteknikker. Og se hvilke der ville
klare opgaven bedst. Desuden kunne det også være meget spændende at få implementeret et Kalman-filter på
accelerometer og gyroskop inputtene. Men dette vil vi lade andre om. Vi har hele vejen igennem, forsøgt at lave en
Version 1
side 35 af 38
DIYS
platform, så andre vil kunne lave projekter på DIYS. Det eneste der er fastmonteret i konstruktionen, er motorerne og
kontrolpanelspladen, mens alt andet enten ikke sidder fast, eller er monteret med velcrotape. Så der er helt klart base
for, at man ville kunne bruge DIYS i andre projekter. Vi vil se det som opfyldes af et uskrevet mål, hvis der bliver
arbejdet videre med DIYS, og gøre os endnu mere stolte af projektet.
Version 1
side 36 af 38
DIYS
REFERENCER
NET KILDER
•
•
•
•
•
Extreme programming - http://da.wikipedia.org/wiki/Extreme_Programming
PID regulering - http://en.wikipedia.org/wiki/PID_controller
RUP - http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process
Lego SegWay projektet - http://lego.daller.dk
Lignende SegWay projekt - http://tlb.org/scooter2.html
BØGER
Titel:
Forfatter:
Embedded C programming and the Atmel AVR
Barnett,Richard; O'Cull,Larry; Cox,Sarah
2006, 19, 532 s., Thompson Delmar Learning, Clifton Park, N.Y., 2. ed.
Titel:
Forfatter:
Håndbog i struktureret programudvikling
Biering-Sørensen,Stephen
2002, 361 sider, ill., Ingeniøren-Bøger, Kbh., 1. Udgave
Titel:
Forfatter:
UML distilled: a brief guide to the standard object modeling language
Fowler,Martin
2003, xxx, 175 sider, Addison-Wesley, Reading, Mass., 3. Edition
Titel:
Forfatter:
C-programmering : The C programming language
Kernighan,B.W.; Ritchie,D.M.
1991, 284 s., Hempstead : Prentice Hall ; København : Teknisk Forlag, 2. udg.
Titel:
Applying UML and patterns: an introduction to object-oriented analysis and design and iterative
development
Larman,Craig
2005, xxv, 703 s., ill., Prentice Hall Professional Technical Reference, Upper Saddle River, N.J., 3. ed.
Forfatter:
Titel:
Forfatter:
Version 1
Digital design: principles and practices
Wakerly,John F.
side 37 af 38
DIYS
BILAG
VINKELESTIMERING
LOGBOG
Til logføring har vi benyttet os af ”WordPress Blog and publishing tool”. Dette har fungeret rigtigt godt, hver gang der
var lavet noget i forbindelse med projektet, blev det løbende tilføjet til bloggen.
Version 1
side 38 af 38

Cykelstiplan for Vordingborg Kommune

Transcription

Similar documents

juleinvitation A4 2015

Motor - Bockwoldt GmbH & Co. KG

AIRVEKS 500-1 EC

Brugervejledning - ROLTEC el

Diy – Lille julesok til bestik ©