SW1 PRJ1 Rapport.

Institut for Elektro- og Computerteknologi Elektronik, Elektrisk energiteknologi og Softwareteknologi Semesterprojekt 1 ”Bilen” SW1 1. Semester PRJ1 16/6-2023 Aarhus Universitet #1 Stud.nr.: 202208165 #2 Stud.nr.: 202210045 #3 Stud.nr.: 202209871 #4 Stud.nr.: 202104844 #5 Stud.nr.: 201805439 Navn: Lasse Borring Petersen Navn: August Lind Hansen Navn: Altaf Rezai Navn: Louise Andersen Navn: Kim Van Le Vejleder: Thomas Nielsen PRJ1 SW1 1. Problemformulering............................................................................................................................ 5 2. Kravspecifikation ................................................................................................................................. 9 2.1 Aktør-kontekst diagram .................................................................................................................... 9 2.2 Funktionelle krav............................................................................................................................. 10 2.3. Ikke-funktionelle krav: ................................................................................................................... 12 3. Accepttestspecifikation ..................................................................................................................... 14 3.1 Accepttestspecifikation for funktionelle krav (use cases) .............................................................. 14 Use case 1: ............................................................................................................................................ 14 Use case 2: ............................................................................................................................................ 15 Use case 3: ............................................................................................................................................ 16 Use case 4: ............................................................................................................................................ 17 Test af ikke-funktionelle krav ................................................................................................................ 18 4. Systemarkitektur (HW og SW) .......................................................................................................... 21 4.1 Hardwarearkitektur......................................................................................................................... 21 4.1.1 BDD-diagram ................................................................................................................................ 21 4.1.2 IBD-diagram ................................................................................................................................. 22 4.1.3 Signalbeskrivelse .......................................................................................................................... 23 4.2 Softwarearkitektur .......................................................................................................................... 25 4.2.1 Moduldiagram.............................................................................................................................. 26 4.2.2 Modulbeskrivelse ......................................................................................................................... 27 5. Hardwaredesign ................................................................................................................................ 28 5.1 Motorstyring ................................................................................................................................... 28 5.2 Lyd ................................................................................................................................................... 32 5.3 Forlys ............................................................................................................................................... 34 5.4 Baglys .............................................................................................................................................. 37 5.5 Strømforsyning................................................................................................................................ 42 6. Softwaredesign ................................................................................................................................. 43 6.1 Class Motor ..................................................................................................................................... 43 6.1.1 setSpeed() .................................................................................................................................... 43 6.1.2 setDirection() ............................................................................................................................... 44 6.2 Class Lyd .......................................................................................................................................... 44 6.2.1 InitLyd() ........................................................................................................................................ 45 6.2.2 startLyd() ...................................................................................................................................... 45 6.2.3 reflexLyd() .................................................................................................................................... 45 6.2.4 slutLyd()........................................................................................................................................ 46 6.3 Class Lys .......................................................................................................................................... 46 Side 2 af 74 PRJ1 SW1 6.3.1 initLight() ...................................................................................................................................... 46 6.3.2 PWM-styrings funktioner ............................................................................................................. 47 6.4 Class Reflex...................................................................................................................................... 49 6.4.1 Interrupts ..................................................................................................................................... 49 6.5 SW-design af main-rutine ............................................................................................................... 50 7. Hardwareimplementering og modultest .......................................................................................... 51 7.1 HW-implementering og test af motor ............................................................................................ 51 7.2 HW-implementering og test af lys .................................................................................................. 52 7.3 HW-implementering og test af lyd.................................................................................................. 53 7.4 HW-implementering og test af refleksbrik ..................................................................................... 53 8. Softwareimplementering og modultest............................................................................................ 54 8.1 SW-implementering og test af motordriver ................................................................................... 54 8.2 SW-implementering og test af lysdriver ......................................................................................... 54 8.3 SW-implementering og test af lyddriver ......................................................................................... 55 8.4 SW-implementering og test af refleksbriksensor-driver ................................................................ 57 8.5 SW-implementering og test af main-rutine .................................................................................... 57 9. Integrationstest ................................................................................................................................. 58 9.1 Integrationstest af bilens motor ..................................................................................................... 58 9.2 Integrationstest af bilens lys ........................................................................................................... 58 9.3 Integrationstest af bilens lyd .......................................................................................................... 58 10. Accepttest ....................................................................................................................................... 59 10.1 Test af funktionelle krav ............................................................................................................... 59 Use case 1: ............................................................................................................................................ 59 Use case 2: ............................................................................................................................................ 60 Use case 3: ............................................................................................................................................ 61 Use case 4: ............................................................................................................................................ 62 10.2 Test af ikke-funktionelle krav ........................................................................................................ 63 11. Konklusion ....................................................................................................................................... 66 11.1 Konklusion for hardwaredelen...................................................................................................... 66 11.2 Konklusion for softwaredelen ....................................................................................................... 66 11.3 Konklusion for projektet ............................................................................................................... 66 12. Individuelle konklusioner ................................................................................................................ 67 12.1 Individuel konklusion: Altaf Rezai ................................................................................................. 67 12.2 Individuel konklusion: Louise Andersen ....................................................................................... 67 12.3 Individuel konklusion: Kim Van Le ................................................................................................ 68 12.4 Individuel konklusion: Lasse Borring Petersen ............................................................................. 68 Side 3 af 74 PRJ1 SW1 12.5 Individuel konklusion: August Lind Hansen .................................................................................. 68 13. Bilagsoversigt .................................................................................................................................. 69 Bilag 1. Konkurrencen ........................................................................................................................... 69 Bilag 2. Fysiske mål for karosseriet ....................................................................................................... 71 Bilag 3. Arduinoens bendiagram ........................................................................................................... 72 Bilag 4: Arbejdsfordeling ....................................................................................................................... 73 Indhold Side 4 af 74 PRJ1 SW1 1. Problemformulering Det tværfaglige projekt PRJ1, der gennemføres på 1. semester for E- og SW-studierne, drejer sig om udvikling af hardware og software til styring af en elektrisk bil. Som en indledning til projektet gennemføres 4 øvelser i E-LAB. Disse kan betragtes som en forundersøgelse eller analyse af de teknikker, der tænkes anvendt under projektet. Projektet skal udarbejdes efter retningslinjerne i dokumentet ”Vejledning til gennemførelse af projekt 1”. Under projektets forskellige faser gives der enkelte forelæsninger, der uddyber indholdet af disse faser. Et bilkarrosseri med påmonteret motor bliver udleveret til hver enkelt projektgruppe. Se figur 1. Figur 1 - Karrosseri med printplader, pendul og Arduino Mega2560 Den færdige bils formål er, at den skal kunne gennemkøre en konkurrencebane efter regler, der er nærmere beskrevet i bilag 1, ”Konkurrencen”. Side 5 af 74 PRJ1 SW1 3 Bilen skal udstyres med:  Mikrocontroller.  Elektronik til regulering af motor.  Sensorer til detektering af refleksbrikker.  For- og baglygter.  Elektronik til styring af for- og baglygter.  Elektronik og højtaler til afspilning af lyd. Nogle af de nødvendige hardwareenheder vil helt eller delvis blive udviklet i andre kurser på 1. semester. Arbejdet med disse opfattes derfor ikke som en del af semesterprojektet. Det drejer sig om:  Print med kredsløb til detektering af refleksbrikker. Dette print skal forbindes til bilens mikrocontroller. Hvis der foretages modifikationer af printet for at tilpasse det projektet, skal disse modifikationer beskrives i projektdokumentationen.  ”Fejltæller”: Print med kredsløb til tælling og visning af pulser fra et pendul. Pendulet anvendes kun som et påmonteret måleudstyr under konkurrencen, og den er ikke en del af selve projektet. Bilen skal forsynes med fremadrettet kørelys (hvidt) og baglys (rødt), samt bremselys (kraftigt rødt). Se figur 2 og figur 3. Bremselys og baglys udsendes fra samme kilde og skal kunne reguleres i to forskellige styrker. Hvert enkelt for-, bag- eller bremselys kan realiseres som et antal lysdioder, der opbygges som et LED-sæt. Hvert sæt kan opbygges som en kombination af serie- og/eller parallel-forbundne lysdioder. I projektet anvendes microcontrolleren Mega2560 på et ”Arduino Mega2560” kit. Denne anvendes til:  Styring af bilens fart og retning.  Styring af for- og baglygternes lysstyrke.  Detektering af banens refleksbrikker.  Afspilning af lyde og/eller melodier. Bilen skal under konkurrencen køre på en bane med to bander, hvor banderne vil sikre, at bilen bliver på banen. Banderne er udstyret med 7 par refleksbrikker, der kan detekteres af optiske sensorer placeret på bilen. Ved start skal bilen afspille en specifik startlyd eller startmelodi, og efter passage af mållinjen skal afspilles en specifik slutlyd eller slutmelodi. Ved passage af hver enkelt af refleksbrikkerne skal bilen afgive en specifik ”refleksbriklyd”. På figur 4 er vist placering af et af printene til detektering af refleksbrikker (der skal være et på hver side). Figur 5 viser en mulig placering af print med anden elektronik, som skal konstrueres for at kunne styre bilen. De præcise fysiske mål for bilkarrosseriet kan ses i bilag 1. Side 6 af 74 PRJ1 SW1 4 Figur 2 - Placering af to print til forlys, højre og venstre side Figur 3 - Placering af print til bag- og bremselys Side 7 af 74 PRJ1 SW1 Figur 4 - Placering af print til detektering af refleksbrikker Figur 5 - Print med øvrig elektronik placeret midt i bilen Side 8 af 74 PRJ1 SW1 2. Kravspecifikation 2.1 Aktør-kontekst diagram Skrevet af: Lasse Borring Petersen Figur 6 - Aktør-kontekst diagram Det system, som skal laves, er selve bilen. På figur 6 ses systemet, samt de aktører der interagerer med det. Aktøren ”bruger” skal starte bilens gennemløb af banen. Brugeren er derfor en primær aktør. Aktøren ”refleksbrik på venstre/højre side” kan detektere hvornår bilen passerer en refleksbrik. De regulerer altså bilen mens den kører banen, men kan ikke regulere noget ellers. Derfor er refleksbrikkerne en sekundær aktør. Side 9 af 74 PRJ1 SW1 2.2 Funktionelle krav Uarbejdet i fællesskab Figur 7 viser de ”Use Cases” som bilen skal udføre, samt hvilke aktører der indgår i disse. Figur 7 - Use case diagram for "bilen" Use case 1: ”Kør banen”: Mål: Denne use case beskriver, hvordan banen skal gennemkøres. Initieres af: Bruger. Normalt scenarie: 1. Brugeren tænder for bilen og placerer den, så den kører forlæns ind på banen ved at passere startlinjen. 2. Når bilen har passeret refleksbrik nummer 6, bringes bilen til standsning, inden refleksbrik nummer 7 nås. 3. Bilen bakker, indtil refleksbrik nummer 5 er passeret, og bringes til standsning, inden refleksbrik nummer 4 nås. 4. Bilen kører forlæns, indtil refleksbrik nummer 7 nås. 5. Bilens bringes til standsning i målområdet, der er defineret som området mellem banens slutende og en meter derefter. Generelt gælder: • Lyd afspilles som beskrevet i use case 2 ”Afspil lyd”. • Forlyset styres som beskrevet i use case 3 ”Styr forlys”. • Baglyset styres som beskrevet i use case 4 ”Styr baglys”. Side 10 af 74 PRJ1 SW1 Use case 2: ”Afspil lyd” Mål: Denne use case beskriver styringen af en systemindbygget lydgiver. Initieres af: Use case 1 ”Kør banen”. Normalt scenarie: 2.1. Når bilen tændes, afspilles en specifik ”startlyd” eller ”startmelodi”. 2.2. Hver gang en refleksbrik passeres, afspilles en specifik ”refleksbriklyd”. 2.3. Når refleksbrik nummer 7 passeres, afspilles en specifik ”slutlyd” eller ”slutmelodi”. ”Startlyden/melodien” er den lyd der afspilles i Mario Kart når man i spillet gør klar og der tælles ned fra 3-2-1-go. ”Refleksbrikslyden” er den lyd der afspilles i spillet Mario Kart når man kører ind i en item box. ”Slutlyden” er den lyd der afspilles i spillet Mario kart når man passerer mållinjen på 3. omgang i spillet. Use case 3: ”Styr forlys” Mål: Denne use case beskriver styringen af bilens indbyggede forlys. Forlyset kan være slukket eller tændt. Initieres af: Use case 1 ”Kør banen”. Normalt scenarie: Forlyset skal være tændt, når bilens motor påtrykkes en spænding der får bilen til at køre. Ellers skal forlyset være slukket. Use case 4: ”Styr baglys” Mål: Denne use case beskriver styringen af bilens indbyggede baglys. Baglyset kan være slukket, lyse med mellemstyrke (”almindeligt baglys”) eller lyse med kraftig styrke (”bremselys”). Initieres af: Use case 1. ”Kør banen”. Normalt scenarie 4.1 Baglyset skal lyse med mellemstyrke (”almindeligt baglys”), når bilens motor påtrykkes en spænding, der får bilen til at køre. Ellers skal baglyset være slukket. 4.2 Baglyset skal lyse med kraftig styrke (”bremselys”), mens spændingens til bilens motor mindskes. Side 11 af 74 PRJ1 SW1 9 2.3. Ikke-funktionelle krav: Uarbejdet af alle. 1. Generelle krav 1.1. Bilen skal på en enkelt opladning af dennes batterier kunne gennemføre mindst 5 gennemkørsler af banen. 1.2. På bilens højre og venstre side skal placeres detektorer, der kan registrere en R80 refleksbrik i afstanden 2 cm til 25 cm. 1.3. Bilen monteret med al udstyr må maksimalt veje 5,2 kg. 1.4. Bilens maksimale højde skal være 41 cm. 1.5. Bilens maksimale bredde skal være højst 46cm. 2. Bilens forlys 2.1. Forlyset består a 2 hvide LED-sæt, der monteres i højre og venstre side. 2.2. Forlyset skal kunne ses tydeligt når man ser på bilen forfra, mens der går en strøm gennem LED’erne på 60 mA +/- 6 mA. 2.3. Når forlyset er tændt, skal strømmen gennem hvert LED-sæt være 60 mA +/- 6mA. 3. Bilens bag- og bremselys 3.1. Implementeres med 2 røde LED-sæt, der monteres i højre og venstre side bag på bilen. 3.2. Baglyset skal kunne ses tydeligt når man ser bilen bagfra, mens der går en strøm gennem LED’erne på 20 mA +/- 2 mA. 3.2. Ved ”bremselys” skal middelstrømmen gennem hvert LED-sæt være 60 mA +/- 6 mA. 3.3. Ved ”almindeligt baglys” skal middelstrømmen gennem hvert LED-sæt være 20 mA +/- 2 mA. Side 12 af 74 PRJ1 SW1 4. Bilens lyd 4.1. Startlyd / startmelodi: - Mario Kart – Countdown og startlyd fra Mario Kart 8. 4.2. Refleksbriklyd: - Mario Kart - item box pickup sound fra Mario Kart 8. 4.3. Slutlyd / slutmelodi: - Mario Kart – Løbsafslutningsmelodi fra Mario Kart 8. 4.4. Lydkvalitet: - Lydene skal bestå af polyfonisk musik. Altså skal lyden komme ud af en højtaler som kan spille flerstemmigt. Side 13 af 74 PRJ1 SW1 3. Accepttestspecifikation Udarbejdet af alle. 3.1 Accepttestspecifikation for funktionelle krav (use cases) Use case 1: Use case 1: ”Kør banen” Test Forventet resultat 1. Brugeren tænder for bilen og placerer den, så den kører forlæns ind på banen ved at passere startlinjen. Visuel test: Bilen stopper mellem refleksbrikkerne 6 og 7. Opnået resultat Godkendt / kommentar Denne use case beskriver, hvordan banen skal gennemkøres. Punkt 1 + punkt 2 Punkt 3 Punkt 4 og 5 2. Når bilen har passeret refleksbrik nummer 6, bringes bilen til standsning, inden refleksbrik nummer 7 nås. 3. Bilen bakker, indtil refleksbrik nr. 5 er passeret, og bringes til standsning inden refleksbrik nr. 4 nås. 4. Bilen kører forlæns, indtil refleksbrik nummer 7 nås. 5. Bilens bringes til standsning i måleområdet, der er defineret som området mellem banens slut-ende og en meter efter banens slut-ende. Visuel test: Bilen bakker og standser mellem refleksbrikkerne 5 og 4. Visuel test: Bilen starter og kører frem til refleksbrik nr. 7, og stopper inden for det definerede måleområdet. Side 14 af 74 PRJ1 SW1 Use case 2: Use case 2: ”Afspil lyd” Test Forventet resultat 2.1. Når bilen tændes for at køre ind på banen, afspilles en specifik ”startlyd” eller ”startmelodi”. 2.2. Hver gang en refleksbrik passeres, afspilles en specifik ”refleksbriklyd”. Høretest: Den korrekte startlyd afspilles når bilen startes. Opnået resultat Godkendt/kommentar Denne use case beskriver styring af en i systemet indbygget lydgiver. Initieres af: Use case 1 ”Kør banen”. Punkt 1 Punkt 2 Punkt 3 2.3. Når refleksbrik nummer 7 passeres, afspilles en specifik ”slutlyd” eller ”slutmelodi”. Høretest: Den korrekte refleksbriklyd kan høres hver gang en refleksbrik passeres. Høretest: Bilen afspiller den korrekte slutlyd når den passerer mållinjen Side 15 af 74 PRJ1 SW1 Use case 3: Use case 3: ”Styr forlys” Denne use case beskriver styringen af bilens indbyggede forlys. Forlyset kan være slukket eller tændt. Initieres af: Use case 1 ”Kør banen”. Punkt 1: Punkt 2: Test Forventet resultat Forlyset skal være tændt, når bilens motor påtrykkes en spænding, for at bringe den til at køre. Ellers skal forlyset være slukket. Måletest: Forlyset lyser med en strøm på 60 mA +/- 6 mA. Den lyser kun når motoren er tændt på bilen. Forlyset skal lyse i en kold hvid farve ud af LED’en: LTW-2S3D8 Visuel test: Forlyset lyser med hvidt lys. Opnået resultat Godkendt/kommentar Side 16 af 74 PRJ1 SW1 Use case 4: Use case 4: Test ”Styr baglys” Denne use case beskriver styringen af bilens indbyggede baglys. Baglyset kan være slukket, lyse med mellemstyrke (”almindeligt baglys”) eller lyse med kraftig styrke (”bremselys”). Initieres af: Use case 1. ”Kør banen”. Punkt 1: 4.1 Baglyset skal lyse med mellemstyrke (”almindeligt baglys”), når bilens motor påtrykkes en spænding, for at bringe den til at køre. Ellers skal baglyset være slukket. Skriv hvor mange mA Punkt 2: 4.2 Baglyset skal lyse med kraftig styrke (”bremselys”), mens spændingens til bilens motor mindskes. Skriv hvor mange mA Forventet resultat Opnået resultat Godkendt/kommentar Måle og visuel test: mA gennem baglyset måles, og der vurderes om det lyser med en passende styrke. Måle og visuel test: mA gennem baglyset måles, og der vurderes om det lyser med en passende styrke. Side 17 af 74 PRJ1 SW1 Test af ikke-funktionelle krav 1. Generelle krav Krav- Krav nr. 1.1 Bilen skal på en enkelt opladning af dens batterier kunne gennemføre mindst 5 gennemkørsler af banen. 1.2 På bilens højre og venstre side skal placeres detektorer, der kan registrere en R80 refleksbrik i afstanden 2 cm til 25 cm. 1.3 Bilen monteret med al udstyr må maksimalt veje 5,2 kg. 1.4 Bilens maksimale højde skal være 41 cm. 1.5 Bilens maksimale bredde skal være højst 46cm - med ekstraudstyr. Test Resultat Godkendt/kommentar Visuel test: Bilen tændes og kører banen korrekt 5 gange i træk på en enkelt opladning Bilen tændes og kører banen. Hvis refleksprintet opfanger reflekssensorerne og giver et ”returlys” er kravet godkendt Bilen vejes, godkendes hvis vægten er under 5.2 kg. Bilens højde måles med et målebånd med 1 mm præcision fra gulvet til bilens højeste punkt. Godkendt hvis højden < 41 cm. Bilens bredde måles med et målebånd med 1 mm præcision fra yderste punkt i venstre side, til yderste punkt i højre side. Godkendt hvis bredden < 46 cm. Side 18 af 74 PRJ1 SW1 2. Bilens forlys Krav nr. 2.1 Krav Forlys implementeres med 2 hvide LED-sæt, der monteres med et sæt i henholdsvis højre og venstre side, foran på bilen. 2.2 Når forlyset er tændt, skal strømmen gennem hvert LED-sæt være 60 mA +/- 6mA. Test Visuel test: Sidder der en hvid LED i både højre og venstre side foran på bilen, som er synlige Måletest: Der tilsættes en strøm til begge LED’er hvor vi måles med et multimeter, at strømmen er inden for det godkendte område. Resultat Godkendt/kommentar Resultat Godkendt/kommentar 3. Bilens bag- og bremselys Krav nr. 3.1 3.2 3.3 Krav Baglyset implementeres med 2 røde LEDsæt, der monteres med et sæt i henholdsvis højre og venstre side bag på bilen. Ved ”bremselys” skal middelstrømmen gennem hvert LED-sæt være 60 mA +/- 6 mA. Test Visuel test: Sidder der på en LED og højre og venstre side bag på bilen, som er synlige Måletest: Når bremselyset er tændt,, måles strømmen gennem LED’erne med et multimeter. Strømmen skal måles til 60 mA +/- 6 mA Ved ”almindeligt Måletest: Når baglyset baglys” skal er tændt, måles middelstrømmen strømmen over Side 19 af 74 PRJ1 SW1 gennem hvert LED-sæt være 20 mA +/- 2 mA. LED’erne med et multimeter. Strømmen skal måles til 20 mA +/2 mA. 4. Bilens lyd Krav nr. 4.1 4.2 4.3 4.4 Krav Startlyden/melodien skal være den lyd der afspilles i Mario Kart når man i spillet gør klar og der tælles ned fra 32-1-go. Refleksbrikslyden skal være den lyd der afspilles i spillet Mario Kart når man kører ind i en item box. Slutlyden skal være den lyd der afspilles i spillet Mario kart når man passerer mållinjen i spillet. Lyden skal komme ud af en polyfonisk højtaler på bilen. Test Resultat Høretest: Er startmelodien den korrekte lyd Godkendt/kommentar Høretest: Er refleksbriklyden den korrekte lyd Høretest: Er slutlyden den korrekte lyd Kommer lyden ud af en polyfonisk højtaler Side 20 af 74 PRJ1 SW1 4. Systemarkitektur (HW og SW) Skrevet af: Lasse Udarbejdet af: Lasse og August 4.1 Hardwarearkitektur For at simplificere hardwaren ned i mindre bestanddele, har vi lavet hardwarearkitektur i form af BDD- og IBD-diagrammer. Dette er med til at give overblik over de forskellige dele der skal laves hardware til, og hvordan de skal forbindes internt. 4.1.1 BDD-diagram For at få et generelt overblik over hardwaren, laves et såkaldt BDD (Block Definition Diagram). Dette bruges til at inddele hardwaren i forskellige blokke med hver sin funktionalitet, og dermed give overblik. Som tillæg til BDD’en skrives også en kort forklaring på de forskellige blokke og deres funktionalitet. Vores BDD ses på figur 8. Figur 8 - BDD over bilen Side 21 af 74 PRJ1 SW1 4.1.2 IBD-diagram For så at få et overblik over interne forbindelser og inputs/outputs i hver blok i BDD’en, laves et IBD (Internal Block Diagram). Her ses alle interne forbindelser, samt dem der går ud til omverdenen. Derudover ses der også hvilken type forbindelserne skal have, evt. også deres størrelse. Fejltælleren ligger uden for diagrammet, da den ikke laves direkte i forbindelse med projektet, men stadig har forbindelser til andre komponenter på bilen. Figur 9 - IBD for bilen Side 22 af 74 PRJ1 SW1 4.1.3 Signalbeskrivelse Skrevet og udarbejdet af: Lasse Som udvidelse af IBD’en laves også en signalbeskrivelse, som går endnu dybere ned i de enkelte forbindelser. Her beskrives præcis hvilke pins på arduinoen der bruges til hvad, og om signalet er indgående eller udgående. Dette er igen med til at give overblik og gøre det nemmere at komme i gang med at lave de enkelte komponenter. Derudover undgås det også, at man kommer til at bruge den samme pins på arduinoen til to forskellige signaler. Signalnavn Funktion Område Port 1 (source) 0.0 V Power Supply, (ground.) Ground Reference til analog spænding ComponentPower Forsyningsspænding BigPower Forsyningsspænding 9.5-9.7 V Power Supply, 9.6V batteriet MotorPower Forsyningsspænding 7,1-7.3 V LightOut(R/L) Fysisk lys Power Supply, 7.2V batteri Sensor(R/L), (LED) 4.9-5.1 V Power Supply, (5V forsyningspins) Port 2 (Destination) Arduino ATMega2560 (Ground pin), SensorL (Ground pin), SensorR (Ground pin), Speaker (Ground pin), Lights (Ground pin), Motor (Ground stik). Lights (VCC pin), SensorL (VCC pin), SensorR (VCC pin), Speaker (VCC pin) Arduino ATMega2560 (– Power pin Vin) Fejltæller - veroboard, (Vin pin) Powersupply (Vin pin) Motor, (inputstik på bil). Kommentar Stel. 5V strøm fra powersupply 9.6V batteri 7.2V batteri Lys ud til refleksbrik Side 23 af 74 PRJ1 SW1 ReflexLight(R/L) Reflekteret fysisk lys MotorSpeed Justere bilens hastighed ForwardMotorDirection Justere om bilen kører fremad eller bagud BackLightSignal Justere baglysets intensitet. Tunes Afspille lyd Event: Indikerer modtaget SensorSignal(R/L) fysisk lys Sensor(R/L), (Fotodiode) Motorprint PWM, 0% til 100% duty cycle. On/Off Arduino Mega2560 (pin 5) Arduino Mega2560 (Pin 23) Motorprint PWM, 0% til 100% duty cycle. Arduino Mega2560 (pin 7, PH4, OC4B, PWM) Højtaler Baglysprint 0.0 V til 5.0 V Sensor(R/L) (Vout pin på printplade) Arduino ATMega2560 Pin 2 (L). Arduino ATMega2560 Pin 3 (R). Lys ind fra refleksbrik PWM-signal hvor duty cycle bruges til at regulere hastighed. Et On/Off signal som bruges til at afgøre hvilken vej motoren skal køre. Skrue op for baglyset ved opbremsning eller bagudkørsel Afspille startlyd, refleksbriklyd samt slutlyd. Fortælle arduinoen hvor langt bilen er på banen ved at sende et signal til den hver gang en refleksbrik passeres. Side 24 af 74 PRJ1 SW1 4.2 Softwarearkitektur Skrevet og udarbejdet af: Lasse For at hardwaren overholder de krav som blev specificeret tidligere i kravsspecifikationen, skal der selvfølgelig også laves noget software. Her vil vi igen starte med at lave arkitektur over softwaren, for at give overblik over hvilke funktioner der er brug for, og hvad disse funktioner skal kunne. Vi har taget udgangspunkt i den inddeling vi lavede af hardwaren og kravsspecifikationen, for at komme frem til forskellige klasser, til at beskrive de komponenter der indgår i bilen. Vi er kommet frem til en kodeinddeling der består af fire forskellige klasser, som er følgende:     Motor Lys Lyd Refleks Hver af disse klasser indeholder koden til den enkelte komponent, klassen har ansvaret for at kontrollere. Disse kan vi opstille i et UML-moduldiagram, hvor vi forbinder de enkelte klasser med pile, som indikerer de interne forbindelser klasserne har med hinanden, og deres relation til main-rutinen. Ved at lave dette moduldiagram bliver vores software mere organiseret, og derved bliver det også nemmere at udarbejde de enkelte drivere, når vi skal skrive main-programmet senere. Side 25 af 74 PRJ1 SW1 4.2.1 Moduldiagram Udarbejdet af: Lasse Figur 10 - Moduldiagram over softwarearkitekturen På moduldiagrammet ser vi, at refleksklassen returnerer en integer ind i main, som den bruger til at styre hvorhenne på banen bilen befinder sig. Fra main kan vi så kalde funktionerne fra de tre andre klasser. Til sidst munder det hele så ud i hardwaren, hvor selve ændringerne sker, som fx at bremselyset tænder og slukker. Tilhørende moduldiagrammet har vi også lavet en modulbeskrivelse, som beskriver de enkelte klassers ansvar, samt funktionerne i dem. Det gør det nemmere når koden skal skrives, da vi så ved præcis hvilke funktioner der skal styre hvad, om de skal have en returværdi, og om de skal have nogle parametre. Modulbeskrivelsen ses på figur XX på næste side. Side 26 af 74 PRJ1 SW1 4.2.2 Modulbeskrivelse Udarbejdet af: Lasse Figur 11 - Modulbeskrivelse af softwarearkitekturen Side 27 af 74 PRJ1 SW1 5. Hardwaredesign Skrevet af: Lasse I dette afsnit skabes et overblik over de forskellige komponenters nødvendige hardware, i sådan en detaljeret grad at det er muligt at realisere kredsløbene. 5.1 Motorstyring Skrevet af: Lasse, med hjælp fra Kim Som beskrevet tidligere i accepttestspecifikationen, skal bilen have mulighed for at ændre køreretningen. Vi skal altså have implementeret en måde hvorpå vi kan vende strømmen gennem motoren, så bilen kan bakke. Dette gøres ved hjælp af et relæ, som indeholder to switches og en spole. Når men sender strøm gennem spolen, laver den et magnetfelt omkring sig, hvilket skubber switchen, som dermed leder strømmen ud ad den anden udgang. Ved så at forbinde disse udgange på en speciel måde som vi kommer tilbage til senere, kan vi sørge for at når der går strøm gennem spolen, ændrer strømmens retning gennem motoren sig. Derved opnår vi, at bilen både kan køre frem og tilbage. Databladet for relæet 40.52 som bruges her ses på figur XX. Figur 12 - Udsnit af databladet for relæ 40.52. Vi kan se I databladet for relæet at ved påsætning af en 5V DC-spænding på spolen, afsættes en effekt i spolen på 0.65 W. Derved skal vi altså ramme en strøm på, ifølge formlen 𝑃 = 𝐼 ∗ 𝑉, på: Side 28 af 74 PRJ1 SW1 Denne strøm er større end hvad vores arduino kan levere direkte ud af en port. Derfor bruges en transistor til at forstærke denne strøm. I øvelse 3 benyttede vi os af samme princip med en lysdiode, hvor vi brugte transistoren BD139. Da fandt vi ud af, at betaværdien for BD139-transistoren er 𝛽 = 20, samt at spændingsfaldet 𝑉𝑏𝑒 = 0.7𝑉. Altså må den strøm der skal leveres af arduinoen til basebenet være: Som er under de 20mA som et ben på arduinoen kan levere. Ved at benytte os af KVL, kan vi se at spændingsfaldet over spolen må være 4.3𝑉, da arduinoen udsender 5V, og spændingsfaldet over transistoren er 0.7𝑉. For så at få strømmen ned på de 6.5mA, skal en formodstand sættes på før transistoren. Dens størrelse beregnes ved ohms lov: Vi skal altså bruge en formodstand på 662 ohm for at få den ønskede strøm ind i transistoren fra vores arduino, og dermed få den ønskede strøm gennem spolen. Ud fra denne information kan vi nu opbygge kredsløbet for motorstyringen i multisim. Kredsløbet ses på figur XX. Side 29 af 74 PRJ1 SW1 Figur 13 - Multisim diagram for motorstyring. Udover komponenterne som er blevet beskrevet tidligere, har vi også benyttet en IRLZ44N transistor som fører strøm ind i motoren. Her bruges samme princip som beskrevet tidligere omkring BD139, da vores arduino ikke kan levere nok strøm ud af en pin til at få motoren til at køre. Strømmen der skal til for at få motoren til at køre, er dog noget større end den der skal til for at få spolen til at vende relæet. Derfor bruges en større transistor, som i det her tilfælde er en IRLZ44N. Derudover har vi også bruge to beskyttelsesdioder. Dioderne er til for, at når der slukkes for strømmen går der stadig lidt strøm gennem kredsløbet. Dette gælder især for spolen. For at reducere den elektriske støj der kan forekomme, sættes dioder på som strømmen kan løbe igennem. På diagrammet er der også en frekvensgenerator på 244 Hz. Hvordan vi er kommet frem til denne værdi, kommer vi til i senere afsnit omhandlende softwaredesignet. Side 30 af 74 PRJ1 SW1 Styklisten til motorens hardware ser således ud: Antal 1 1 2 1 1 1 1 1 1 Symbol på diagram R2 R1 D1, D2 Q2 Relæ 40.52 Q1 VCC_Batteri U1 Arduino Ben 5 Arduino Ben 23 Komponentnavn 10kΩ modstand 662Ω modstand 1N4007G Diode BD139 transistor Relæ 40.52 (Udleveret af elektronikværkstedet) IRLZ44N transistor 7.2 V batteri Motor Arduino ATMega2560 ben 5 og ben 23 Side 31 af 74 PRJ1 SW1 5.2 Lyd Udarbejdet og skrevet af: Altaf Til lyden benyttes en SOMO-II (SOMO-2) MP3-afspiller til at afspille den ønskede lyd. Selve SOMO2’en styres af en UART-driver fra vores Arduino Mega2560, og i forbindelse med at SOMO’en er tilkoblet polyfoniske højtalere, kan vi med disse 3 komponenter, få afspillet de lyde vi ønsker. MultiSIM-diagrammet længere nede demonstrerer hvordan selve opsætningen og kommunikationen mellem disse komponenter fungerer. Figur 14 Figur 15 Side 32 af 74 PRJ1 SW1 Forklaring på kredsløb, kommunikation og funktionalitet: Vi bruger UART0 fra Arduino og forbinder TXD0 (Port E, pin 1) fra Arduino til RX-benet (pin 11) på SOMO-2. Vi har mellem de nævnte pins på Arduino og SOMO-2, loddet en 1𝑘Ω-modstand på, og dette gøres for at opretholde kompatibilitet mellem de to enheder, da vores ArduinoMega2560 arbejder med standard 5V, hvorimod vores SOMO-2 er kompatibel med 3,3V logisk spænding på både TX- og RX-benet. Dette er også forklaret og anbefalet i SOMO-2’ens datablad. Specifikt for lyden, benytter vi kun RX-benet fra SOMO’en, da den blot skal modtage instrukser og ikke sende. For at forbinde højtaleren til SOMO-2, forbinder vi SPK+ (pin 15) og SPK- (pin 16) fra SOMO-2’en til højtaleren. VCC (pin 9) på SOMO-2 forbindes til den fælles spændingsforsyning der leverer 5V. Ground (pin 10) forbindes også til den fælles ground på den samme spændingsforsyning. Forklaring på porte til/fra speaker og SOMO-2: BEN-NUMMER NAVN FUNKTION 1,2,3,4,5,6,7,8 -||- -||- 9 VDD Power-supply 10 GND 0V (jord) 11 RX UART Recieve-pin 12 TX UART Transmit-pin 13 DAC_R -||- 14 DAC_L -||- 15 SPK1 Differential-forstærket output til speaker 16 SPK2 Differential-forstærket output til speaker -||- = ikke vigtigt for funktionaliteten/formålet. Stykliste: Antal 1 1 1 1 Komponentnavn SOMO-II (SOMO-2) 1𝑘Ω modstand Speaker ArduinoMega2560 Side 33 af 74 PRJ1 SW1 5.3 Forlys Udarbejdet og skrevet af: Louise og August Til brug i vores forlys har vi valgt LTW-2S3D8 som LED. En skabelon af kredsløbet for forlys opbygges i multisim, for at kunne beregne de nødvendige værdier. Figur 16 – skabelon af kredsløbet for forlys Som beskrevet i kravsspecifikationen, skal middelstrømmen for et LED-sæt af forlys være 60mA. Vi har valgt at bruge 3 stk. LED pr. forlys, hvilket bliver 60𝑚𝐴 3 = 20 𝑚𝐴 pr. LED. I databladet for LED’en LTW-2S3D8, kan vi aflæse at der ved en fremadrettet strøm på 20mA vil være et spændingsfald på 3,3V over én LED. Disse data er vist på figur 17 og 18 nedenfor Side 34 af 74 PRJ1 SW1 Figur 17 – udsnit af datablad for LED LTW-2S3D8 Figur 18 – udsnit af datablad for LED LTW-2S3D8 Den valgte transistor for kredsløbet er BD139. Denne transistor er valgt, da den er magen til den der blev brugt under projektøvelse 3, og da dens maksimale collector-strøm er 3,0A, en øvre grænse vi ikke kommer tæt på at nå. I forlygten har vi valgt at bruge én formodstand for hvert forlys (R1 og R2). Beregningen af disse formodstande foretages ved brug af KVL. Side 35 af 74 PRJ1 SW1  Transistoren Q1 antages at være i mætning, og vi regner med: o β = 20 o VCE = 0,2 V o VBE = 0,7 V (oplysninger givet under projektøvelse 3.) Forsyningsspændingen er 𝑉1 = 5𝑉. KVL over kredsløbet: −𝑉1 + 𝑉𝐿𝐸𝐷 + 𝑉𝐶𝐸 + 𝑉𝑅 = 0 Ud fra ovenstående KVL for kredsløbet, findes spændingsfaldet over vores modstande R1 og R2: 𝑉𝑅 = 5𝑉 − 3,3𝑉 − 0,2𝑉 = 1,5𝑉 Vi kan nu beregne vores modstande R1 og R2 ved ohms lov: 1,5𝑉 𝑅 = 60𝑚𝐴 = 25𝑜ℎ𝑚 Som det næste, skal der findes en passende modstand til basebenet, for at der fås den korrekte strømstyrke. PWM-spænding fra Arduino er 𝑉2 = 5𝑉, vi antager altså en 100% duty-cycle for at hvert sæt af forlys får 60mA tilført. For at finde modstanden (R3), laver vi igen KVL over kredsløbet: −𝑉2 + 𝑉𝐵𝐸 + 𝑉𝑅3 = 0 𝑉𝑅3 = 5𝑉 − 0,7𝑉 = 4,3𝑉 Derefter beregnes den ønskede strømstyrke af basestrømmen: 𝐼𝑏𝑎𝑠𝑒 = 𝐼𝑏𝑎𝑠𝑒 = 6∗20𝑚𝐴 20 𝐼𝑎𝑙𝑙𝑒𝐿𝐸𝐷 𝛽 = 6𝑚𝐴 Til sidst bruges ohms lov til at finde modstanden R3: 𝑅3 = 4.3𝑉 = 716,667𝛺 6𝑚𝐴 Grundet ECE lagerets mangel på 716 ohm modstande, bruges i stedet en 680 ohm modstand. Den reelle duty-cycle der skal til for at levere hvert sæt af forlys med 60mA vil derfor beregnes: 4.3𝑉 680𝑜ℎ𝑚 = 6𝑚𝐴 ∗ 𝑑𝑢𝑡𝑦𝑐𝑦𝑐𝑙𝑒  𝑑𝑢𝑡𝑦𝑐𝑦𝑐𝑙𝑒 = 680𝑜ℎ𝑚 4.3𝑉 6𝑚𝐴 = 0.949 = 95% Med de beregnede værdier for modstande, opbygges et diagram over kredsløbet i multisim. Kredsløbet kan ses på figur 19. Side 36 af 74 PRJ1 SW1 Figur 19 – diagram af kredsløbet for forlys Stykliste til forlys: STYKLISTE Stk. 6 stk. 2 stk. Symbol på diagram LED1-6 R1 og R2 1 stk. R3 1 stk. 1 stk. 1 stk. Q1 V1_spændingsregulator Arduino_ben_6 Komponent Hvid LED LTW-2S3D8 24 ohm modstand (tætteste på 25ohm på lager) 680 ohm modstand (tætteste på 716 ohm på lager) BD139 transistor Spændingsregulator Arduino ATMega2560 ben 6 5.4 Baglys Udarbejdet og skrevet af: Louise og August Til brug i vores baglys har vi valgt C503B-RBN-CW0Z0AA1 som LED. En skabelon af kredsløbet for baglyset opbygges i multisim for at kunne beregne de nødvendige værdier. Side 37 af 74 PRJ1 SW1 Figur 20 – skabelon af kredsløb for baglys Som beskrevet i kravsspecifikationen, skal middelstrømmen for et LED-sæt af baglys være 60mA, når bilen bremser og bakker. Vi tager udgangspunkt i baklyset, da duty-cyclen af PWM-signalet altid kan sættes ned for at få 20mA til at løbe gennem hver LED-sæt. Vi har valgt at bruge 3 stk. LED pr. baglys, hvilket bliver 60𝑚𝐴 3 = 20 𝑚𝐴 pr. LED. I databladet for LED’en C503B-RBN-CW0Z0AA1, kan vi aflæse at der ved en fremadrettet strøm på 20mA vil være et spændingsfald på 2,1V over én LED. Disse data er vist på figur 21 og 22 nedenfor. Side 38 af 74 PRJ1 SW1 Figur 21 – udsnit af datablad for LED C503B-RBN-CW0Z0AA1 Figur 22 – udsnit af datablad for LED C503B-RBN-CW0Z0AA1 Den valgte transistor for baglysets kredsløbet er BD139, af samme årsag som det var for forlyset, at denne transistors collector-strøm har en maksimalværdi på 3,0A. I baglygten har vi valgt at bruge én formodstand for hvert baglys (R4 og R5). Beregningen af disse formodstande foretages ved brug af KVL.  Transistoren Q1 antages at være i mætning, og vi regner med: o β = 20 o VCE = 0,2 V o VBE = 0,7 V (oplysninger givet under projektøvelse 3.) Side 39 af 74 PRJ1 SW1 Forsyningsspændingen er 𝑉3 = 5𝑉. KVL over kredsløbet: −𝑉3 + 𝑉𝐿𝐸𝐷 + 𝑉𝐶𝐸 + 𝑉𝑅 = 0 Ud fra ovenstående KVL for kredsløbet, findes spændingsfaldet over vores modstande R4 og R5: 𝑉𝑅 = 5𝑉 − 2,1𝑉 − 0,2𝑉 = 2,7𝑉 Vi kan nu beregne vores modstande R4 og R5 ved ohms lov: 2,7𝑉 𝑅 = 60𝑚𝐴 = 45𝑜ℎ𝑚 Da den samlede strøm gennem alle LED’erne er den samme for både forlys og baglys, og de to kredsløb bruger samme transistor, ræsonnerer vi os frem til at modstanden R6 på basebenet vil være den samme. 𝑅6 = 716,667𝑜ℎ𝑚 Da vi igen mangler den præcise resistor, bruges 680 ohm resistor i stedet. Duty-cyclen findes som før. 4.3𝑉 680𝑜ℎ𝑚 = 6𝑚𝐴 ∗ 𝑑𝑢𝑡𝑦𝑐𝑦𝑐𝑙𝑒  𝑑𝑢𝑡𝑦𝑐𝑦𝑐𝑙𝑒 = 680𝑜ℎ𝑚 4.3𝑉 6𝑚𝐴 = 0.949 = 95% Baglyset skal også kunne lyse med en middelstrøm på 20mA gennem hvert sæt af baglygter. Dutycyclen for dette findes også. 4.3𝑉 680𝑜ℎ𝑚 = 2𝑚𝐴 ∗ 𝑑𝑢𝑡𝑦𝑐𝑦𝑐𝑙𝑒  𝑑𝑢𝑡𝑦𝑐𝑦𝑐𝑙𝑒 = 680𝑜ℎ𝑚 4.3𝑉 2𝑚𝐴 = 0.316 = 32% Med de beregnede værdier for modstande, opbygges et diagram over kredsløbet i multisim. Kredsløbet kan ses på figur 23. Figur 23 – diagram af kredsløbet for baglys Side 40 af 74 PRJ1 SW1 Stykliste til baglys: STYKLISTE Stk. 6 stk. 2 stk. Symbol på diagram LED1-6 R4 og R5 1 stk. R6 1 stk. 1 stk. 1 stk. Q2 V3_spændingsregulator Arduino_ben_7 Komponent Rød LED C503B-RBN-CW0Z0AA1 44 ohm modstand (tætteste på 45 ohm på lager) 680 ohm modstand (tætteste på 716,6 ohm på lager) BD139 transistor Spændingsregulator Arduino ATMega2560 ben 7 Side 41 af 74 PRJ1 SW1 5.5 Strømforsyning Udarbejdet og skrevet af: Kim Til bilen anvendes to strømforsyninger, en 9,6 V batteri, 2500 mAh og en 7,2 V, 3300 mAh. 7,2 V batteriet anvendes til motoren og bliver reguleret af motoren. Til Batteriet med 9,6 V skal det nedreguleres ved hjælp af en spændingsregulator (LM7805), det reguleres ned til 5 V og forsyner fejltælleren, bag- og forlys, refleksionsprintene, SOMO-II samt motorstyringsprintet. Figur 24 – diagram over spændingsregulatoren Figur 25 - fysiske opstilling på veroboard af figur 24 Side 42 af 74 PRJ1 SW1 6. Softwaredesign Skrevet af: Lasse Her vil softwaren til de forskellige komponenter blive beskrevet i sådan en detaljeret grad, at det er muligt at skrive den nødvendige software ud fra det. Vi har valgt at skrive alt vores software i C++, da man i det, i modsætning til almindelig C, har mulighed for at lave klasser, som er gode til at give overblik over hvilke dele af softwaren der hører til hvad, når vi til sidst skal skrive vores main-rutine. 6.1 Class Motor Skrevet og udarbejdet af: Lasse Klassen motor skal indeholde to hovedfunktioner. Den ene skal styre hastigheden på bilen, og den anden skal styre bilens retning. 6.1.1 setSpeed() Vi starter med funktionen setSpeed(), som styrer hastigheden på bilen. Dens UML-diagram ses på figur XX. Funktionen skal tage et input (int). Først skal den sørge for at inputtet altid ligger mellem 0 og 100, så alle værdier udenfor dette interval sættes til det maksimale i intervallet. Dernæst skal funktionen skrive et tal til OCR3A-registeret, som sætter motorens duty-cycle i %, svarende til inputtet i %. Grunden til at funktionen skal skrive til OCR3A-registeret, er at vi benytter os af arduinoens timer 3 i fast PWM, 10-bit mode, til at danne et PWM-signal på pin 5. Når en timer er i fast PWM-mode, fungerer den som det ses på figur XX1. Der skrives en værdi til OCRn-registeret, som er mellem 0 og registerets TOP-værdi. I dette tilfælde er TOP-værdien lig 0x03FF = 1023, som det ses nederst på figur XX2. Timeren tæller så op med en hastighed der er afhængig af CPU-frekvensen og prescalerværdien. Frekvensen for arduinoens CPU er 16MHz, og Figur 26 - UML-diagram for funktionen setSpeed() i klassen Motor. Figur 27 - Forklaring på fast PWM-signal Figur 28 - Udsnit af tabel over hvordan 16-bit timers sættes i PWM-mode 1 2 Henning Hargaard, “Mega2560 Timers”, side 20 Henning Hargaard, “Mega2560 Timers”, side 23 Side 43 af 74 PRJ1 SW1 prescalerværdien er valgt til 64. Dette giver ifølge formlen 𝑓= 𝑓𝑐𝑝𝑢 𝑁 ∗ (1 + 𝑇𝑂𝑃) En frekvens på: 𝑓= 16𝑀𝐻𝑧 = 244𝐻𝑧 64 ∗ (1 + 1023) Hver gang timeren så passerer den værdi der står i OCR3A på sin vej fra 0 til 1023, vi den udsende 5V ud på pin 5, indtil den resetter tilbage til 0, og tæller op forfra. Med dette kan vi altså styre motorens duty cycle. For at få et input i % over til en dutycycle i procent, skal der en mindre omregning til. Dette gøres af to omgange. Først tages inputtet og ganges med 10, hvilket giver os værdier mellem 0 og 1000. Men da vores TOP-værdi er 1023, skal der en smule mere til. Derfor tager vi inputtet og deler det med 4, og lægger det til. Det giver et interval for TOP-værdierne på 0 til 1025. Dette er tæt nok på til at det kan godtages, men der skal dog lige laves en begrænsning der gør at TOP aldrig kan antage en værdi over 1023. 6.1.2 setDirection() Denne funktion skal styre hvilken retning strømmen skal gå gennem motoren, ved at styre om der skal gå strøm gennem spolen, som blev beskrevet i afsnit 5.1 i hardwaredesign. Dette opnås ved at outputte en spænding på enten 0V eller 5V på arduinoens ben 23. Det ses i bilag 3, at ben 23 har udgangen PA1. Når der påsættes en spænding på 5V på benet, vil spolens magnetfelt skifte switchen i relæet, og strømmen vil ændre retning gennem motoren. På den måde skifter bilen køreretning. 6.2 Class Lyd Figur 29 - UML-diagram for funktionen setDirection() i klassen motor Udarbejdet og skrevet af: Altaf Klassen lyd indeholder fire hovedfunktioner: 1. 2. 3. 4. InitLyd(); startLyd(); reflexLyd(); slutLyd(); OBS! I alle funktioner er kommandoen sendKommandoTilSomo(); kaldt. Denne funktion sender blot kommandoen til SOMO-2’en, hvorfra den aflæses og udføres. Side 44 af 74 PRJ1 SW1 6.2.1 InitLyd() Denne funktion har til formål at initiere UART-driveren til BAUD-rate 9600 med 8bit, at hente og initiere lyden fra SD-kortet og at reset SOMO-2’en til POWER-ON-STATE. Altså har initLyd-kommandoen fået implementeret disse tre funktioner, hvilket er i stedet for at skabe og skrive kommandoerne hver for sig og kalde dem, da dette skaber uoverskuelighed i selve programmet. Funktionen med beskrivelser/forklaringer på koden: void initLyd() { initUART(9600, 8); //Initierer UART-driveren med BAUD-rate: 9600 og bit: 8. const char aCommand5[8] = { 0x7E,0x09,0x00,0x00,0x02,0xFF,0xF5,0xEF }; //Initierer lyden fra SD-kort og IKKE USB. sendKommandoTilSomo(aCommand5); const char aCommand6[8] = { 0x7E,0x0C,0x00,0x00,0x00,0xFF,0xF4,0xEF }; //RESET SOMO-2 til POWER-ON-STATE sendKommandoTilSomo(aCommand6); } 6.2.2 startLyd() Denne funktion kalder kommandoen for afspilningen af en startlyd ved starten af kørebanen. Mere specifikt er dette en kode der fortæller SOMO-2’en, at den skal afspille første lyd fra SD-kortet, og at lydfilen skal aflæses udenfor en mappe, da der ingen mappe er. Lydfilerne er indsat i SD-kortet. Beskrivelser på kommandoen kan ses nedenfor. Funktionen med beskrivelser/forklaringer på koden: void startLyd() { //Denne array opretter en command for startlyd, som den sender til SOMO-2. const char aCommand1[8] = { 0x7E,0x03,0x00,0x00,0x01,0xFF,0xFC,0xEF }; //Vi har 0x00 for ingen mappe, og 01 for track 1. sendKommandoTilSomo(aCommand1); } 6.2.3 reflexLyd() Denne funktion kalder kommandoen for afspilning af en reflekslyd når bilen passerer en refleks på kørebanen. Beskrivelser på kommandoen kan ses nedenfor. Funktionen med beskrivelser/forklaringer på koden: void reflexLyd() { //Denne array opretter en command for reflex lyd, som den sender til SOMO-2. const char aCommand2[8] = { 0x7E,0x03,0x00,0x00,0x02,0xFF,0xFB,0xEF }; //Vi har 0x00 for ingen mappe, og 02 for track 2. sendKommandoTilSomo(aCommand2); } Side 45 af 74 PRJ1 SW1 6.2.4 slutLyd() Denne funktion kalder kommandoen for afspilning af en slutlyd, når bilen er bragt til standsning for enden af kørebanen. Beskrivelser på kommandoen kan ses nedenfor. Funktionen med beskrivelser/forklaringer på koden: void slutLyd() { //Denne array opretter en command for slutlyd, som den sender til SOMO-2. const char aCommand3[8] = { 0x7E,0x03,0x00,0x00,0x03,0xFF,0xFA,0xEF }; //Vi har 0x00 for ingen mappe, og 03 for track 3. sendKommandoTilSomo(aCommand3); } 6.3 Class Lys Udarbejdet af: Louise og August Klassen Light indeholder 7 funktioner, der tilsammen tillader os at styre lysene på bilen. 6.3.1 initLight() Den første funktion initLight() skal initialisere timer 4, og initialisere ben 3 og 4 på Port H som udgange. Timer 4 bliver brugt i PWM, Phase Correct, 8 bit mode til at danne et PWM-signal på pin 6 og 7. Figur 30 - Forklaring af ikke-fast PWM-signal Side 46 af 74 PRJ1 SW1 På figur 30 kan det ses hvordan en timer i ikke-fast PWM-mode fungerer. OCRn er den værdi vi skal skrive til timeren, for at bestemme vores duty-cycle. For den valgte initialisering af timer 4, toggles udgangssignalet på OCn til at være low når OCRn = tælleregisteret under optælling, og high når OCRn = tælleregisteret under nedtælling. Frekvensen hvormed timeren tæller op, er afhængig af CPU-frekvensen, prescalerværdien og TOP. Frekvensen for arduinoens CPU er 16MHz, prescalerværdien er valgt som værende 256, og værdien for TOP i den valgte mode er 0x00FF = 255. Værdien af TOP kan findes i figur 31. Figur 31 - Udsnit af tabel over hvordan 16-bit timers sættes i PWM-mode Dette giver ifølge formlen: 𝑓= 𝑓𝑐𝑝𝑢 𝑁 ∗ 2 ∗ (𝑇𝑂𝑃 + 1) En frekvens på: 𝑓= 16𝑀𝐻𝑧 = 122𝐻𝑧 256 ∗ 2 ∗ (255 + 1) 122Hz er en acceptabel frekvens, da det eneste krav til frekvensen for PWM-signalet er at man ikke skal kunne se lysene blinke. 6.3.2 PWM-styrings funktioner Skrevet og udarbejdet af: August og Louise Ved at udskrive specifikke værdier til registrene OCR4A og OCR4B, kan vi hermed styre duty-cyclen for PWM-signalet til vores lys. Til dette bruges funktionerne: void frontLighOn(); void frontLightOff(); void backLightOn(); Side 47 af 74 PRJ1 SW1 void backLightOff(); void brakeLightOn(); void brakeLightOff(); Ingen af disse funktioner har nogen parametre eller returværdi, det eneste de gør, er at udskrive den ønskede værdi til det ønskede register. Funktionerne der styrer duty-cyclen for signalet til forlyset vil udskrive en værdi til registeret OCR4A, da forlysene kører på A-systemet af timer 4. Modsat udskriver funktionerne der styrer baglyset en værdi til registeret OCR4B, da baglysene kører på Bsystemet af timer 4. I sektion 5.3 og 5.4 beregnedes den forventede duty-cycle for både forlysene og baglysene. For forlys og bremse/bak-lys fandtes duty-cyclen til 95%, og for normalt baglys fandtes den til 32%. Værdien der skal udskrives til OCR4A/OCR4B, kan udledes ved følgende formel: 𝑑𝑢𝑡𝑦𝑐𝑦𝑐𝑙𝑒 = 𝑂𝐶𝑅𝑛 𝑇𝑂𝑃 OCRn ved dutycycle 95%: 𝑂𝐶𝑅𝑛 = 255 ∗ 0.95 = 242,25 OCRn ved dutycycle 32%: 𝑂𝐶𝑅𝑛 = 255 ∗ 0.32 = 81,6 I tabellen nedenfor, kan det ses hvad de enkelte funktioner udskriver til hvilke registre. Det bemærkes at frontLightOff() og backLightOff() begge sætter dutycyclen til 0%, hvorimod brakeLightOff() sætter dutycyclen til 32%, det samme som backLightOn(). Dette skyldes at baglyset ikke skal slukke når bilen stopper med at bremse/bakke, men derimod skal fortsætte med normalt baglys. Funktion frontLightOn() frontLightOff() backLightOn() backLightOff() brakeLightOn() brakeLightOff() OCR4A 242,25 0 OCR4B 81,6 0 242,25 81,6 Side 48 af 74 PRJ1 SW1 6.4 Class Reflex Skrevet og udarbejdet af: Lasse Klassen reflex skal indeholde funktioner og interrupts, som holder styr på hvorhenne på banen bilen er, og dermed hvad den skal gøre hvornår. 6.4.1 Interrupts Det centrale i denne klasse er, at vi skal tælle op hver gang der forekommer signal fra refleksbrikkerne. Til dette benytter vi os af interrupts, som vi kan måle på arduinoens pin 2 og 3. De sættes derfor til indgange i initieringen, samtidig med at vi definerer interruptet til at gå i gang på rising edge. Når der så forekommer et interrupt, har vi defineret en bool, som afgør om der skal tælles op, eller den allerede er opfanget på den anden refleksbrik. På denne måde undgår vi både at de begge tæller op samtidig, samt at vores tællevariabel kommer til at stige med 2 hver gang vi passerer en enkelt refleksbrik. Pseudokoden for vores interrupts ser således ud: - - Hvis der ikke er opfanget et interrupt for nylig o Interrupts ikke tilladt o Inkrementer tællevariabel Vent 200 ms Interrupts tilladt igen For at følge med i hvor mange der er talt, benytter vi os af LED-driveren som tidligere er lavet i MSYS som LAB-øvelse. Her kan vi få LED’erne på arduinoen til at vise hvad vores tællevariabel står på, og dermed teste vores program. Side 49 af 74 PRJ1 SW1 6.5 SW-design af main-rutine Skrevet og udarbejdet af: Lasse Main-rutinen skal fungere sådan, at hver gang en refleksbrik opfanges, skal der køres forskellige funktioner til de forskellige dele på bilen. Derfor er det oplagt at benytte os af switch-cases, så vi på den måde kan holde styr på hvorhenne på banen bilen befinder sig, og dermed hvilke funktioner der skal køres. Derudover er alle switch-cases, samt getCount(), lagt ind i et while(1)-loop, med en break i slutningen af hver enkelt case. Dette gør at programmet hele tiden kigger efter om en refleksbrik er passeret, og kører så tilsvarende case. Breakkommandoen i slutningen af hver case sikrer os, at hver case kun bliver kørt gennem en enkelt gang. Derudover har vi også benyttet os af LED-driveren som er blevet omtalt tidligere, til at få arduinoens LED’er til at tælle op i binær, så vi kan følge med i hvilken case der kører på hvilke tidspunkter. En skitsering af banen ses på figur 32, hvor hver enkelt røde streg svarer til en refleksbrik, og pilene til bilens retning og casenr. Bilen starter i case 0, som er før banens start, som sættes i gang af brugeren, hvor den derefter kører ind på banen og følger de enkelte cases når den tilsvarende refleksbrik passeres. Derudover skal der også oprettes et objekt til hver hardwaredel, til at benytte funktionerne på, da der er opdelt i klasser. Dette er også med til at give overblik over hvilke funktioner der hører til hvilken hardware. Figur 32 - Illustration over hvornår de forskellige cases træder i kraft ved bilens gennemkørsel af banen Side 50 af 74 PRJ1 SW1 7. Hardwareimplementering og modultest Skrevet af: Lasse Tidligere i afsnittet ”Hardwaredesign” har vi beskrevet designet for de forskellige komponenters hardware. Ud fra dette vil vi nu realisere kredsløbene, og teste at de virker som ventet, inden de sættes på bilen. 7.1 HW-implementering og test af motor Skrevet af: Lasse Udarbejdet af: Lasse, med hjælp fra Kim I afsnit 5.1 blev designet af motorens hardware beskrevet. Ud fra figur XX som blev udarbejdet der, er kredsløbet blevet realiseret på veroboard. Veroboardet ses på figur XX. Figur 33 - Veroboard med motorstyrings hardware Inden printet placeres på bilen, bliver det testet i isolation ved brug af analog discovery. Først testede vi H-broen, om den kunne skifte over når man påsatte en spænding på H-bro switch pinen. Her kunne man høre hver gang den skiftede over, så vi kunne godtage dens funktionalitet. Derefter placerede vi printet på bilen og forbandt det til motoren, da vi skulle teste om den kunne få motoren til at køre, og om hjulene skiftede retning når der blev påsat en spænding på spolen. Her kunne vi igen godtage, at hjulene drejede rundt som de skulle, og når vi påsatte en spænding på spolen, skiftede hjulene retning. Her fandt vi også ud af, at der skulle bruges en frekvens på omkring 250 Hz, for at få bilen til at køre uden at hjulene ”hakkede” frem og tilbage. Dette kommer vi tilbage til senere i softwaren til motorstyringen. Side 51 af 74 PRJ1 SW1 7.2 HW-implementering og test af lys Udarbejdet og skrevet af: August og Louise Ud fra multisim diagrammerne figur 19 og figur 23 i afsnit 5.3 og 5.4, er der blevet udarbejdet følgende kredsløb på veroboard. Veroboardene ses på figur 34 og 35. Figur 34 - Veroboard for forlys Figur 35 - Veroboard for baglys For at teste om forlysene og baglysene fungerer som forventet, måles middelstrømmen over LED’erne. Analog Discovery bruges som både spændingsforsyning, og funktionsgenerator der udsender et PWM-signal. Ifølge kravsspecifikationen skal forlysene have en middelstrøm på 60mA +/- 6mA gennem hvert sæt af forlygter. For at finde middelstrømmen, måles spændingsfaldet over formodstandene R1 og R2 for lygterne. Under testen findes at der ved en duty-cycle på 70% for PWM-signalet måles en spænding på 1,44V over resistorne R1 og R2. Ved ohms lov findes det at 1,44𝑉 strømstyrken igennem R1 så er: 𝐼𝑅1 = 24𝑜ℎ𝑚 = 60𝑚𝐴. For at teste baglysene bruges samme fremgangsmåde som ved forlysene. Der måles spændingsfald over R3 og R4, og Analog Discovery bruges som forsyningsspænding og funktionsgenerator. Når baglysene skal fungere som bremselys/baklys, skal der løbe en middelstrøm på 60mA +/- 6mA gennem hvert sæt af baglygter. Under testen findes at der ved en duty-cycle på 90% for PWMsignalet måles en spænding på 2,75V over resistorne R4 og R5. 2,75 Ohms lov: 𝐼𝑅4 = 44𝑜ℎ𝑚 = 62,5𝑚𝐴 Side 52 af 74 PRJ1 SW1 Baglysene testes også i situationen hvor de bare fungere som baglys, hvor der skal løbe en middelstrøm på 20mA +/- 2 mA gennem hvert sæt af baglygter. Under testen findes at der ved en duty-cycle på 30% for PWM-signalet måles en spænding på 0,91V over resistorene R4 og R5. 0,91 Ohms lov: 𝐼𝑅4 = 44𝑜ℎ𝑚 = 20,682𝑚𝐴 7.3 HW-implementering og test af lyd Udarbejdet og skrevet af: Altaf Ud fra multiSIM-diagrammet i afsnit 5.2, er der blevet bygget følgende på veroboard: SOMO-2 SPKSPK+ TX RX VCC GND 𝟏𝒌𝛀 Figur xx - Ovenfor kan det ses, at selve lydmodulet er opbygget på et veroboard. Til SOMO-2’en benyttes to sokler, således SOMO-2’en kan genbruges. Den polyfoniske højtaler er fastbundet til veroboardet med kobbertråd, og på den måde koblet til SOMO-2’ens SPK+ og SPK-. Derudover er der anvendt 6 pins til hhv. GND, VCC, RX, TX, SPK+ og SPK- - dog skal det bemærkes at den sjette pin ikke benyttes, hvilket er uddybet tidligere i afsnit 5.2. Med disse pins kan vi dermed forbinde SOMO-2’en til vores Arduino på følgende måde: 1. VCC til 5V-porten på Arduino. 2. GND til en af GND-portene på Arduino. 3. RX-benet til TDX0-porten på Arduino. Og vores SOMO-2 til højtaleren på følgende måde: 1. SPK+ til den første port på højtaleren. 2. SPK- til den anden port på højtaleren. 7.4 HW-implementering og test af refleksbrik Skrevet af: Lasse Selve refleksbrikkerne er lavet og testet i sammenhæng med værkstedspraktikken, så dette skal ikke beskrives her. Men en kort forklaring på deres funktionalitet er, at refleksbrikken udsender et lys gennem en rød LED, og ved siden af LED’en sidder en fotodiode, som lader strøm løbe gennem sig når den opfanger lys. Når en refleksbrik så passeres på banen, vil lyset fra LED’en blive reflekteret ind i lysdioden, som så lader strømmen løbe gennem sig. Strømmen går så ud til en pin, som vi kan forbinde til arduinoen, og dermed måle hver gang en refleks passeres på banen. Side 53 af 74 PRJ1 SW1 8. Softwareimplementering og modultest Skrevet af: Lasse Tidligere i afsnit 6 omhandlende softwaredesignet, har vi fundet frem til de forskellige funktioner som skal implementeres i de forskellige klasser. Ud fra dette skal de forskellige drivers nu skrives, samt dertilhørende testprogrammer. 8.1 SW-implementering og test af motordriver Skrevet og udarbejdet af: Lasse Ud fra SW-designet til motoren, beskrevet tidligere i afsnit 6.1, har vi skrevet koden til motordriveren. Dertil har vi også skrevet et testprogram, som benytter både setSpeed() med forskellige parametre for at teste bilens hastigheder, samt setDirection() til at køre frem og tilbage. Pseudokoden for testprogrammet ser således ud: - initiering af motoren - implementering af motorobjekt (bruges til at anvende funktionerne på, da vi arbejder i klasser) - uendeligt while-loop - kør frem - sæt hastighed til 40% - sæt hastighed til 70% - sæt hastighed til 40% - stop (sæt hastighed til 0%) - kør bagud - sæt hastighed til 40% - sæt hastighed til 70% - sæt hastighed til 40% - stop (sæt hastighed til 0%) Ved test af dette testprogram kunne vi se, at bilen kørte som forventet, og dermed kan vi konkludere at vi har en fungerende driver for motorstyringen. 8.2 SW-implementering og test af lysdriver Udarbejdet og skrevet af: Louise og August Ud fra SW-designet for lysene i afsnit 6.3, har vi skrevet koden til lysdriveren. For at teste at driveren fungerer som de skal, er der skrevet et testprogram som benytter alle funktionerne i driveren: initLight(), frontLightOn(), frontLightOff(), backLightOn(),backLightOff(), brakeLightOn() og brakeLightOff(). I både driveren og testprogrammet, anvendes de målte dutycycles fra modultest af hardware 7.2. Side 54 af 74 PRJ1 SW1 Pseudokoden for testprogrammet ser således ud: - Initiering af lysene - Oprettelse af lysobjekt - Uendeligt while-loop o Tænd for forlys o Tænd for baglys o 1 sekund delay o Tænd bremselys o 1 sekund delay o Sluk bremselys (som tænder det normale baglys) o 1 sekund delay o Sluk for forlys o Sluk for baglys o 1 sekund delay Ved test af programmet, kunne det ses at lysene skiftede tilstand når vi forventede de skulle, og vi kan dermed konkludere at lysdriveren fungerer som forventet. 8.3 SW-implementering og test af lyddriver Udarbejdet og skrevet af: Altaf Vores SOMO-2 har i sit datablad, beskrevne og angivet kommandoer som vi kan kalde, og dermed afspille lyd og skrue op og ned for lydvolumen. Disse kommandoer er alle skrevet i HEX-decimaltal. Derudover er der i vores softwareimplementering en række andre funktioner, som alle er skrevet i Csprog. Sammen med kommandoerne for SOMO-2’en og funktionerne i vores lydSystem.c, har vi lavet en class ”lyd” i C++, hvormed vi kan få SOMO-2’en til at afspille vores lyde - class’en er beskrevet nærmere i afsnit 6.2. Vi vil nu opskrive pseudokoden for vores testprogram: Side 55 af 74 PRJ1 SW1 1. 2. initLyd(); initUART(Sæt BAUD-rate til 9600, 8bit). Initiér og hent lyd fra SD-kort. Send kommandoen til SOMO-2. Reset SOMO-2 til POWER-ON-STATE. Send kommandoen til SOMO-2. Delay på 3 sekunder. setMaxLyd(); Set volumen til max (30). 3. startLyd(); - Spil track 1 fra SD-kort (INGEN MAPPE I SD-KORT). Send kommandoen til SOMO-2. - Delay på 5 sekunder. 4. reflexLyd(); - Spil track 2 fra SD-kort (INGEN MAPPE I SD-KORT). Send kommandoen til SOMO-2. Delay på 5 sekunder. 5. slutLyd(); Spil track 3 fra SD-kort (INGEN MAPPE I SD-KORT). Send kommandoen til SOMO-2. Delay på 5 sekunder. Figur xx - Opstilling af lydmodul og test. Opstillingen på figur XX består af selve lydmodulet og vores ArduinoMega2560. Testen fungerer på den måde, at vores Arduino er forbundet til en PC - både for strøm men også for selve download af vores testmain.c fra PC’en. Vi kan derefter forbinde VCC og GND fra SOMO-2 til 5V og GND til Arduino’en, RX fra fra SOMO-2 til TDX0 til Arduino og til sidst SPK- og SPK+ fra SOMO-2 til højtaleren. Testen beviste at vores softwareimplementering kunne få SOMO-2 til at udføre vores kommandoer i testmain.c og dermed afspille de ønskede lyde, og yderligere sætte lyden til max og lave delays. Side 56 af 74 PRJ1 SW1 8.4 SW-implementering og test af refleksbriksensor-driver Skrevet og udarbejdet af: Lasse Som beskrevet tidligere i afsnit 6.5 omhandlende softwaredesignet for refleksbrikkerne, har vi skrevet koden til en refleksbrikdriver. For at teste driveren, har vi også skrevet et testprogram til den. Det er et forholdsvis simpelt program, som viser på arduinoens LED’er hvor mange gange en refleksbrik er blevet opfanget. Til dette benyttes LED-driveren som er skrevet tidligere i LAB-øvelserne i MSYS. Driveren testes så ved både at tælle op ved at bevæge en refleks hen over refleksbrikken, og se at den tæller en op. Derefter testes der at den også kun tæller en op når der bevæges en refleks hen over begge refleksbrikker samtidig. Ved begge tests kunne vi konkludere, at den kun talte op en enkelt gang, og dermed kan vi konkludere, at vi har en fungerende refleksbrikdriver. 8.5 SW-implementering og test af main-rutine Skrevet og udarbejdet af: Lasse Ud fra SW-designet omhandlende main-rutinen beskrevet i afsnit 6.6, har vi skrevet selve main programmet, med alle driverne fra tidligere inkluderet. For at teste main-rutinen, har vi benyttet os af både LED-driveren og refleksbrikdriveren, som begge er omtalt tidligere i afsnit 8.4. Denne gang tester vi ved at tænde specifikke LED’er ved hver switch case, så vi kan se at den skifter mellem de enkelte cases korrekt. Ved udførelse af denne test, kunne vi konkludere at de korrekte LED’er tændte på de korrekte tidspunkter, og derfor kan vi så begynde på integrationstest af de forskellige elementer, som skal med på bilen. Side 57 af 74 PRJ1 SW1 9. Integrationstest Skrevet af: Lasse Vi skal nu begynde at ”samle” bilen, ved få de enkelte dele til at køre sammen en ad gangen. Dette gøres ved, at vi forbinder delene til bilen, og inkluderer dens software inde i main-rutinen, som tidligere er testet med refleksbrikkerne. Så kan det testes ved at køre banen igennem, og rette værdier til hvis dette viser sig at være nødvendigt. Målet med integrationstesten er at vi til sidst står med en færdig bil der kører banen korrekt, så den kan gennemføre accepttesten fra tidligere. 9.1 Integrationstest af bilens motor Skrevet af: Lasse Testet af: Lasse og Kim Den første del der integreres på bilen, er bilens motor. Det gør det nemlig muligt at teste bilen på banen, og se om de andre dele opfører sig korrekt alt efter bilens placering på banen. Testen udføres ved at sættes motorens hardware på bilen, forbinde de nødvendige forbindelser, og inkludere motordriveren inde i main-rutinen. Så sætter vi bilens hastighed i de forskellige cases som vi tror vil få bilen til at gennemføre banen, og tester den. Ved at gøre dette igen og igen, finder vi frem til nogle værdier for bilens hastighed, som får den til at gennemføre banen med så få fejl som muligt. Når dette er gjort, er vi klar til at integrere et nyt element af hardwaren på bilen. 9.2 Integrationstest af bilens lys Skrevet af: August Testet af: Louise, August, Altaf og Lasse Den anden del der integreres, er bilens lysmodul. Lyset sættes først isoleret på bilen, uden nogen af de andre moduler. Testen udføres ved at inkludere lysdriveren i main-rutinen. Både forlys og baglys bliver koblet til spændingsregulatoren, og forlysene til pin 7 på arduinoen for PWM-signalet, og baglysene til pin 6. Lysstyrken i lygterne sættes til de ønskede værdier i de forskellige cases, og en refleksbrik holdes foran reflektionsprintet for at simulere at bilen kører gennem banen. Testen går som forventet, og både forlys og baglys fungerer som de skal. Nu inkluderes også motordriveren i main-rutinen, og bilen kører igennem banen. Ved gennemkørsel af banen, ses det at både forlys og baglys ændrer tilstand på de rigtige tidspunkter, og vi kan dermed konkludere at de to moduler fungerer sammen som forventet. 9.3 Integrationstest af bilens lyd Skrevet af: Altaf Testet af: Louise, August, Altaf og Lasse Den sidste del der integreres på bilen, er vores lydmodul. Dette gør det muligt at se/høre, om lydmodulet er funktionsdygtig med initiering af startlyd når bilen skal starte, reflexlyd når bilen passerer en reflex og afslutningsvis slutlyd når bilen stopper. Denne test udføres ved først at påsætte lydmodulet på bilen, og forbinde VCC og GND til en fælles VCC- og GND-central på bilen. Derefter forbindes RX fra SOMO-2’en til TDX0 på én fælles Arduino (den Arduino som kører main-rutinen). Når SOMO-2’en er forbundet til bilen korrekt, implementerer vi herefter softwaren for lyden i vores main-rutine. Vi kan derefter teste bilens lyd på kørebanen. Side 58 af 74 PRJ1 SW1 Under denne integrationstest finder vi ud af, at når lyden er integreret i bilen, forhindrer vores SOMO-2 bilens kørsel i sådan en grad, at bilen ikke er funktionsdygtig. Yderligere ødelægger denne integration også SOMO-2’en, hvis den er forbundet til bilens kredsløb i længere tid. 10. Accepttest Skrevet af: Lasse Da vi ikke kunne få bilen til at gennemføre banen korrekt mens lyden var påsat og integreret i main, har vi valgt at gennemføre accepttesten mens bilen kun er påført motoren og lyset. Kravene til lyden er så bagefter testet uden for bilen, for at tjekke om lydens hardware og software fungerer for sig selv. 10.1 Test af funktionelle krav Accepttesten er gennemgået i fællesskab Use case 1: Use case 1: ”Kør banen” Test Forventet resultat Opnået resultat Godkendt / kommentar 1. Brugeren tænder for bilen og placerer den, så den kører forlæns ind på banen ved at passere startlinjen. Visuel test: Bilen stopper mellem refleksbrikkerne 6 og 7. Bilen stopper oftest mellem refleksbrikkerne 6 og 7. Godkendt. En gang i mellem forekommer der støjinterferens, der får bilen til at bakke en gang for tidligt. Testet uden lyd. Visuel test: Bilen bakker og standser mellem refleksbrikkerne 5 og 4. Bilen bakker og stopper oftest mellem refleksbrikkerne 5 og 4. Godkendt. En gang i mellem forekommer der støjinterferens, der får bilen til at stoppe og køre frem for tidligt. Denne use case beskriver, hvordan banen skal gennemkøres. Punkt 1 + punkt 2 Punkt 3 2. Når bilen har passeret refleksbrik nummer 6, bringes bilen til standsning, inden refleksbrik nummer 7 nås. 3. Bilen bakker, indtil refleksbrik nr. 5 er passeret, og bringes til standsning inden refleksbrik nr. 4 nås. Side 59 af 74 PRJ1 Punkt 4 og 5 SW1 4. Bilen kører forlæns, indtil refleksbrik nummer 7 nås. 5. Bilens bringes til standsning i måleområdet, der er defineret som området mellem banens slut-ende og en meter efter banens slut-ende. Visuel test: Bilen starter og kører frem til refleksbrik nr. 7, og stopper inden for det definerede måleområdet. Bilen kører frem og stopper oftest inden for det definerede målområde. Hvis støj har haft effekt på bilens kørsel, vil der forekomme følgefejl her. Test Forventet resultat Opnået resultat 2.1. Når bilen tændes for at køre ind på banen, afspilles en specifik ”startlyd” eller ”startmelodi”. 2.2. Hver gang en refleksbrik passeres, afspilles en specifik ”refleksbriklyd”. ”Høretest”: Startlyden afspilles når bilen startes. 2.3. Når refleksbrik nummer 7 ”Høretest”: Bilen afspiller slutlyden når den Testet uden lyd. Godkendt. En gang i mellem forekommer der støjinterferens, der får bilen til at bakke en gang for tidligt. Testet uden lyd. Use case 2: Use case 2: ”Afspil lyd” Godkendt/kommentar Denne use case beskriver styring af en i systemet indbygget lydgiver. Initieres af: Use case 1 ”Kør banen”. Punkt 1 Punkt 2 Punkt 3 ”Høretest”: Refleksbriklyden kan høres hver gang en refleksbrik passeres. SOMO-2’en er ikke i stand til at spille nogen lyd, når den Side 60 af 74 PRJ1 SW1 passeres, afspilles en specifik ”slutlyd” eller ”slutmelodi”. passerer mållinjen tilkobles bilens samlede hardware. Det skal også bemærkes, at den brænder på, hvis den er sat til i for lang tid. Use case 3: Use case 3: ”Styr forlys” Denne use case beskriver styringen af bilens indbyggede forlys. Forlyset kan være slukket eller tændt. Initieres af: Use case 1 ”Kør banen”. Punkt 1: Punkt 2: Test Forventet resultat Opnået resultat Godkendt/kommentar Forlyset skal være tændt, når bilens motor påtrykkes en spænding, for at bringe den til at køre. Ellers skal forlyset være slukket. Måletest: Forlyset lyser med en strøm på 60 mA +/- 6 mA. Den lyser kun når motoren er tændt på bilen. Den målte strøm er inden for det definerede område, og forlyset lyser kun når bilen kører. Godkendt Testet uden lyd Forlyset skal lyse i en kold hvid farve ud af LED’en: LTW-2S3D8 Visuel test: Forlyset lyser med hvidt lys. Forlyset lyser med hvidt lys Godkendt Testet uden lyd Side 61 af 74 PRJ1 SW1 Use case 4: Use case 4: Test ”Styr baglys” Denne use case beskriver styringen af bilens indbyggede baglys. Baglyset kan være slukket, lyse med mellemstyrke (”almindeligt baglys”) eller lyse med kraftig styrke (”bremselys”). Initieres af: Use case 1. ”Kør banen”. Punkt 1: 4.1 Baglyset skal lyse med mellemstyrke (”almindeligt baglys”), når bilens motor påtrykkes en spænding, for at bringe den til at køre. Ellers skal baglyset være slukket. Punkt 2: 4.2 Baglyset skal lyse med kraftig styrke (”bremselys”), mens spændingens til bilens motor mindskes. Bremselyset skal herefter forblive tændt i 0,5 sekund +/- 0,1 sekund. Forventet resultat Opnået resultat Godkendt/komm entar Måle og visuel test: Baglyset lyser med en middelstrøm på 20 mA +/- 2mA gennem hvert sæt af baglys, kun når motoren påtrykker en spænding for at bringe den til at køre Måle og visuel test: Baglyset lyder med en middelstrøm på 60 mA +/- 6mA gennem hvert sæt af baglys, kun når bilen bremser eller bakker. Den målte strøm er inden for det definerede område, og baglyset lyser kun når bilen kører. Godkendt Testet uden lyd. Den målte strøm er inden for det definerede område, og baglyset lyser kun når bilen bremser eller bakker. Godkendt Testet uden lyd. Side 62 af 74 PRJ1 SW1 10.2 Test af ikke-funktionelle krav 1. Generelle krav Krav- Krav nr. 1.1 Bilen skal på en enkelt opladning af dennes batterier kunne gennemføre mindst 5 gennemkørsler af banen. 1.2 På bilens højre og venstre side skal placeres detektorer, der kan registrere en R80 refleksbrik i afstanden 2 cm til 25 cm. 1.3 Bilen monteret med al udstyr må maksimalt veje 5,2 kg. 1.4 Bilens maksimale højde skal være 41 cm. 1.5 Bilens maksimale bredde skal være højst 46cm med ekstraudstyr. Test Resultat Godkendt/kommentar Visuel test: Bilen tændes og kører banen korrekt 5 gange i træk på en opladning Bilen tændes og kører banen. Hvis refleksprintet opfanger reflekssensorerne og giver et ”returlys” er kravet godkendt Bilen vejes, godkendes hvis vægten er under 5.2 kg. Bilen har kørt banen korrekt fem gange i træk Godkendt LED’erne der indikerer modtaget returlys lyser når bilen passerer en refleksbrik Godkendt Det findes ved afvejning af bilen, at den vejer mindre end 5,2 kg Det findes ved måling, at bilens højeste punkt, er lavere end 41 cm fra gulvet. Godkendt Det findes ved måling, at bilens bredde fra yderste punkt i venstre side, til yderste punkt i højre side, er under 46 cm. Godkendt Bilens højde måles med et målebånd med 0.1 cm’s præcision fra gulvet til bilens højeste punkt. Godkendt hvis højden < 41 cm. Bilens bredde måles med et målebånd med 0.1 cm’s præcision fra yderste punkt i venstre side, til yderste punkt i højre side. Godkendt hvis bredden < 46 cm. Godkendt Side 63 af 74 PRJ1 SW1 2. Bilens forlys Krav nr. 2.1 Krav Forlys implementeres med 2 hvide LED-sæt, der monteres med et sæt i henholdsvis højre og venstre side, foran på bilen. 2.2 Når forlyset er tændt, skal strømmen gennem hvert LED-sæt være 60 mA +/- 6mA. Test Visuel test: Sidder der en hvid LED i både højre og venstre side foran på bilen, som er synlige Måletest: Der tilsættes en strøm til forlyset LED’er hvor vi måles med et multimeter, at strømmen er inden for det godkendte område. Resultat Forlysene opfylder kravene Godkendt/kommentar Godkendt Den målte strøm for forlyset er inden for det definerede område. Godkendt Test Visuel test: Sidder der på en LED og højre og venstre side bag på bilen, som er synlige Resultat Baglysene sidder korrekt Godkendt/kommentar Godkendt Måletest: Når bilen deaccelererer for at køre baglæns, altså har en negativ acceleration, måles strømmen gennem LED’erne med et multimeter. Strømmen er målt til at ligge inden for det definerede område når bremselyset er tændt. Godkendt 3. Bilens bag- og bremselys Krav nr. 3.1 3.2 Krav Baglyset implementeres med 2 røde LEDsæt, der monteres med et sæt i henholdsvis højre og venstre side bag på bilen. Ved ”bremselys” skal middelstrømmen gennem hvert LED-sæt være 60 mA +/- 6 mA. Side 64 af 74 PRJ1 3.3 SW1 Strømmen skal måles til 60 mA +/- 6 mA Ved ”almindeligt Måletest: Når bilen er baglys” skal tændt, måles middelstrømmen strømmen over gennem hvert LED’erne med et LED-sæt være 20 multimeter. Strømmen mA +/- 2 mA. skal måles til 20 mA +/2 mA. Strømmen er målt til at ligge inden for det definerede område ved almindeligt bremselys Godkendt 4. Bilens lyd Krav nr. 4.1 4.2 4.3 4.4 Krav Startlyden/melodien skal være den lyd der afspilles i Mario Kart når man i spillet gør klar og der tælles ned fra 32-1-go. Refleksbrikslyden skal være den lyd der afspilles i spillet Mario Kart når man kører ind i en item box. Slutlyden skal være den lyd der afspilles i spillet Mario kart når man passerer mållinjen i spillet. Lyden skal komme ud af en polyfonisk højtaler på bilen. Test Resultat Høretest: Den spiller den Er korrekte lyd startmelodien den korrekte lyd Godkendt/kommentar Delvis godkendt Testet i isolation, uden for bil Høretest: Den spiller den Er korrekte lyd refleksbriklyden den korrekte lyd Delvis godkendt Testet i isolation, uden for bil Høretest: Er slutlyden den korrekte lyd Den spiller den korrekte lyd Delvis godkendt Testet i isolation, uden for bil Kommer lyden ud af en polyfonisk højtaler Ja Side 65 af 74 PRJ1 SW1 11. Konklusion 11.1 Konklusion for hardwaredelen Vi kan konkludere på hardwaredelen at vi har udviklet individuelle hardwaremoduler til motoren, forlyset, baglyset, strømforsyning og lyd, der fungerer som det er specificeret i kravspecifikationen. Vi har også testet disse moduler med Analog Discovery 2, hvor vi har konkluderet at de fungerede korrekt. Under integrationen af de forskellige moduler fandt vi dog ud af, at ved integration af lyd-modulet, stoppede bilen med at køre korrekt, og fungerede slet ikke. Dette har sandsynligvis været grundet støj fra motoren, som også var grund til problemer med kørslen tidligere. Grundet tidsnød var det ikke muligt at lægge den nødvendige tid det ville kræve at løse problemet, så vi har været nødsaget til at gennemføre accepttesten mens lyden ikke har været forbundet til bilen. 11.2 Konklusion for softwaredelen Vi kan konkludere på softwaredelen at vi har lavet fire forskellige drivere i c++, til at styre hhv. motoren, lyden, lyset, og refleksbrikkerne. Disse er blevet testet i diverse testprogrammer, hvor vi har kunnet konkludere at de hver især er velfungerende. Ved samling af disse i en main-rutine kan vi konkludere at driverne for motoren, lyset og refleksbrikkerne kan fungere sammen, mens lyddriveren giver problemer ved integrationen ind i main-rutinen. Vi har altså kunnet få bilen til at køre som det er specificeret i vores kravspecifikation, dog uden at den laver noget lyd. 11.3 Konklusion for projektet Vi kan konkludere at vi i dette projekt har designet både hardware og software efter kravsspecifikationen, og bygget hardwaren ud fra hardwaredesignet, samt skrevet driverne ud fra softwaredesignet. Disse er så blevet testet, og derefter implementeret på bilen, som har gennemført banen korrekt, dog uden at afspille lyd. Side 66 af 74 PRJ1 SW1 12. Individuelle konklusioner Hver enkelt individuelle konklusion er skrevet af personen selv. 12.1 Individuel konklusion: Altaf Rezai Personligt synes jeg, at dette projekt i starten lød lidt fjernt ift. slutproduktet, og at jeg var en smule forvirret over hvor vi skulle starte og slutte, da dette er det første store projekt jeg har været en del af. Dog forsvandt forvirringen da vi hver især fik vores fokuspunkter på hardware og softwaredelen, og især dette forløb har lært mig, at et projekt i denne størrelse bliver udarbejdet og skabt af en gruppe, og ikke kun af enkeltmanden. Læringskurven for projektet og hele semesteret generelt, har også været stejl, men dette har også presset os individuelt til at tage ved lære rimelig hurtigt, og dermed har vi lært en masse af dette projekt. Jeg kan med klarhed sige, at dette er en god forudsætning for de kommende projekter og ikke mindst semestre. Jeg synes personligt at gruppearbejdet i starten var lidt varierende, men at det mod enden har været rimelig fast, og at vi har alle vidst hvad vi skulle i gang med. Ift. vores insight profiler, har projektet også vist mig, hvordan større projekter kan påvirke min profil. Jeg er normalt meget rød, men har lært at være mere blå og grøn, hvilket jeg ikke er vandt til. Altså synes jeg samlet set, at dette projekt har været lærerigt og dermed også en god start på denne uddannelse, da den skaber en positiv forventning om de kommende semestre. 12.2 Individuel konklusion: Louise Andersen I starten, virkede dette projekt for mig lidt fjernt. Jeg havde svært ved at forholde mig til, hvordan vi skulle komme fra A til B. Det hele var stadig meget nyt og jeg følte ikke, at jeg havde nok viden om de forskellige ting, hvilket gjorde det ret uoverskueligt. Det blev klart bedre da vi dykkede ned i de forskellige ting, men jeg synes først, at jeg rigtig fandt min plads, da vi fik uddelegeret opgaverne og derved hver især havde vores del, at holde styr på. Personligt, synes jeg ikke, at vi kom særligt godt fra start mht. samarbejdet i gruppen. Kommunikationen har været svær. Vi har alle haft nogle forskellige behov og forskellige ønsker til tidspunkter at mødes, som vi måske kunne have været bedre til at imødekomme. Samarbejdet blev bedre, da vi fik uddelegeret opgaver og vi ’kun’ skulle forholde os til ’vores’ del af opgaven. Det blev mere overskueligt og målet var knap så fjernt. Der er dog stadig helt klart plads til forbedringer på den front og det er bestemt noget jeg har taget ved lære af. Men jeg synes, at vi som gruppe, er kommet i mål med et godt resultat. Generelt er jeg bedst til at sidde med tingene på egen hånd. Jeg bliver hurtigt forstyrret, hvis der er mange mennesker omkring mig. Jeg har derfor tendens til at lukke mig selv lidt inde og måske glemme at spørge om hjælp hvis nødvendigt. Dette passer også ret godt overens med min insightsprofil, som siger, at jeg er en stille og observerende person. Projektet har lært mig rigtig meget både på det personlige, men også det, at skulle samarbejde som en gruppe. Der er helt klart plads til forbedringer fra min side, som jeg vil ta med mig videre, i de næste forløb. Side 67 af 74 PRJ1 SW1 12.3 Individuel konklusion: Kim Van Le Projektet virkede lidt uoverskueligt fra starten af semesteret, da jeg ikke havde et overblik over, hvordan vi som gruppe kom fra start til slut. Det hjalp lidt med oplæggene og de diverse vejledende møder, men det var svært at se den røde tråd i hele forløbet, og vide hvad der skulle laves, siden vi blev gradvist informeret om hvad der skulle gøres. Det føltes til tider, at der var noget at lave og andre gange følte man sig bagud. Det hjalp på det, da vi uddelegerede opgaver og blev inddelt i grupper til motor, lys og lyd, da der var et bedre overblik og vidste hvad man skulle gå i gang med. I forhold til indsights-profilerne var det meget fint i starten at gå over dem, men de var ikke meget relevante for vores gruppe undervejs, da vi sjældent har været fuldtallige under møder/gruppearbejde, det har været med til at skabe besvær med samarbejdet og kommunikationen i gruppen. Indsights har dog givet mig selvrefleksion over min del af samarbejdet i projektet. Projektet har givet erfaring med samarbejde og hvordan arbejdsprocessen udvikler sig fra start til slutproduktet. 12.4 Individuel konklusion: Lasse Borring Petersen I starten virkede projektet med overvældende, men både oplæggene i starten af semesteret samt vejledermøderne var med til at gøre det hele mere håndgribeligt. Da vi gik i gang med IBD, BDD og softwaredesignet, var det hele stadigvæk meget fjernt, og jeg følte dengang at vi manglede viden omkring hvordan det hele skulle laves, og det var tit nødvendigt at gå tilbage og rette i det, i stedet for at man kunne bruge det som man egentligt skulle, ved at lave ting ud fra det. Da vi så inddelte os i undergrupper til hhv. motor, lys og lyd, blev det også mere håndgribeligt, i og med at man ikke længere behøvede at bekymre sig specielt meget om de andre ting. Personligt havde jeg ansvaret for motoren, så det var rart bare at kunne sidde og dykke ned i det, uden at skulle tænke på at man også skulle nå at lave alle de andre elementer der skulle med på bilen. Selve gruppearbejdet var i vores gruppe svært at få til at hænge sammen. I bagklogskabens lys skulle vi have gjort det mere klart i vores samarbejdsaftale hvad vores ambitioner var som gruppe, og lavet ordentlige og klare konsekvenser for ikke at møde op til gruppemøder og aftaler, som der også skulle ydes en indsats for at få overholdt. Jeg synes at mit eget personlige udbytte har været stort, men det hører nok sammen med at jeg endte med at tage en masse initiativ for mig selv, og bare få tingene gjort. Det passer også ret godt overens med min insights-profil, som sagde at jeg er en person som har det bedst med at sidde selv og fordybe mig i ting, hvilket jeg også gjorde klart overfor gruppen i starten af forløbet. Alt i alt vil jeg sige at projektet som helhed er forløbet nogenlunde, men der er helt klart plads til forbedring, som jeg vil tage med videre til kommende projekter. 12.5 Individuel konklusion: August Lind Hansen Projektforløbet har været en længere historie, som desværre ikke fulgte en lineær udfordringskurve. Det føltes modsat som en stejl mur Side 68 af 74 PRJ1 SW1 13. Bilagsoversigt Bilag 1. Konkurrencen ”Pokaljagten” er en dyst, hvor en elektrisk bil skal gennemføre en bane med forhindringer på kortest mulig tid. Bilen er under konkurrencen udstyret med en accelerationssensor (et pendul), der kan registrere accelerationer over en fast grænse. Overskridelse af denne grænse udløser strafpoint. Forhindringerne er udformet som ramper, bilen skal passere. Det vanskelige ved gennemkørslen er at tilpasse bilens acceleration til banens forskellige dele. Det er kun bilens fart og bevægelsesretning, der kan reguleres. Banen har bander, der sørger for bilens retning, og banderne er forsynet med refleksbrikker til positionsbestemmelse. De 7 par refleksbrikker er placeret parvist overfor hinanden på hver sin side af banen i positionerne: 1) 0,5 m fra banens start-ende 2) 0,5 m før bakken 3) På toppen af bakken 4) 0,5 m efter bakken 5) 1,5 m efter bakken 6) 2,5 m efter bakken 7) 0,5 m før banens slut-ende Figur 8. Banen med refleksbrikker Følgende regler gælder for gennemkørslen af banen: Point gives ud fra forskellige kriterier: • Point er lig med gennemførselstiden i sekunder. • Det dobbelte af fejltællerens visning tillægges som strafpoint. • Der tillægges strafpoint, hvis bilens samlede vægt (inklusiv udstyr og fejltæller) er over 5,2 kg. Der tillægges 1 strafpoint for hver påbegyndt 100 gram over 5,2 kg. • Bilen diskvalificeres, hvis dens kørsel ikke overholder kravspecifikationens use case 1. • Bilen diskvalificeres, hvis den ikke standser i målområdet. Banen er udstyret med lysbarrierer ved banens start og ved banens mål. Side 69 af 74 PRJ1 SW1 15 Gennemførselstiden måles fra lysbarrieren ved start til lysbarrieren ved slut. Efter mål skal bilen holde stille i målområdet. Hvis bilen kører længere end målområdet, diskvalificeres kørslen. Det samlede pointtal udregnes ved: Samlet point = Gennemførselstid i sekunder + strafpoint Laveste antal point vinder. Side 70 af 74 PRJ1 SW1 Bilag 2. Fysiske mål for karosseriet Side 71 af 74 PRJ1 SW1 Bilag 3. Arduinoens bendiagram Side 72 af 74 PRJ1 SW1 Bilag 4: Arbejdsfordeling Grøn = Primær aktør på området, har lavet det meste af delen. Gul = Sekundær aktør på området, har været med til delen i mindre grad. Rød = Har ikke været med til delen. Blå = Givet på forhånd el. lavet andetsteds. Emne (nr.) 1. 2. 2.1 2.2 2.3 3. 4.1.1 4.1.2 4.1.3 4.2 4.2.1 4.2.2 5. 5.1 5.2 5.3 5.4 5.5 6. 6.1 6.1.1 6.1.2 6.2 6.3 6.3.1 6.3.2 6.4 6.4.1 6.5 7. 7.1 7.2 7.3 7.4 Beskrivelse Lasse Problemformulering Kravspecifikation Aktør-kontekst diagram Funktionelle krav Ikke funktionelle krav Accepttestspecifikation BDD-diagram HW-arkitektur IBD-diagram HW-arkitektur Signalbeskrivelse HW-arkitektur Softwarearkitektur Moduldiagram Modulbeskrivelse Hardwaredesign Motorstyring Lyd Forlys Baglys Strømforsyning Softwaredesign Class motor setSpeed() setDirection() Class Lyd Class Lys InitLight() PWM-styrings funktioner Class Reflex Interrupts SW-design af main-rutine Hardwareimplementering og modultest HW-implementering og test af motor HW-implementering og test af lys HW-implementering og test af lyd HW-implementering og test af refleksbrik Kim Altaf Louise August Side 73 af 74 PRJ1 8. 8.1 8.2 8.3 8.4 8.5 9. 9.1 9.2 9.3 10. 11. 12.1 12.2 12.3 12.4 12.5 SW1 Softwareimplementering og modultest SW-implementering og test af motordriver SW-implementering og test af lysdriver SW-implementering og test af lyddriver SW-implementering og test af refleksbriksensor-driver SW-implementering og test af mainrutine Integrationstest Integrationstest af bilens motor Integrationstest af bilens lys Integrationstest af bilens lyd Accepttest Konklusion Individuel konklusion: Altaf Individuel konklusion: Louise Individuel konklusion: Kim Individuel konklusion: Lasse Individuel konklusion: August Side 74 af 74

SW1 PRJ1 Rapport.

Products

Support

SW1 PRJ1 Rapport.

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib