Feedback control for surveillance camera. Tilbagekoblede Realtidssystemer. Titel: Tema: Projekt periode: 1/9 19/ Synopsis: Gruppe: E5 505

Transkript

1 AAL B O R G UNIVE RSI T E T Institut for Elektroniske Systemer Aalborg Universitet Fredrik Bajers Vej 7B 9000 Aalborg Phone Fax Titel: Feedback control for surveillance camera Tema: Tilbagekoblede Realtidssystemer Projekt periode: 1/9 19/ Gruppe: E5 505 Deltagere: Mohamed Ishag Glenn Christiansen Rasmus Nielsen Vejleder: Kirsten Mølgaard Nielsen Tom Søndergaard Pedersen Synopsis: Denne rapport handler om udviklingen og dimensioneringen af et automatisk overvågningssystem. Udviklingen indebærer implementationen af et reguleringsystem, som har til formål at retningsbestemme et kamera ved hjælp af en DC-motor og en steppermotor. Reguleringen på dette system foregår ved en billedeanalyse af det video feed, der bliver registeret af kameraet, for således at generere et koordinatsæt der videresendes til en hardware mæssig motorstyring. Ligeledes gør reguleringen også brug af en PIcontroller, som også dimensioneres via en analyse som vil være at finde i denne rapport. Oplagstal: 6 stk. Sideantal: 96 Bilagsantal og -art: 1 CD vedlagt Afsluttet den: 19/ Rapportens indhold er frit tilgængeligt, men offentliggørelse (med kildeangivelse) må kun ske efter aftale med forfatterne.

2

3 AAL B O R G UNIVE RSI T E T Department of Electronic Systems Fredrik Bajers Vej 7B 9220 Aalborg Ø Denmark Phone Fax Title: Feedback control for surveillance camera Subject: Feedback real-time systems Project period: 1/9 19/12, 2008 Group: E5-505 Group members: Mohamed Ishag Glenn Christiansen Rasmus Nielsen Technical adviser: Kirsten Mølgaard Nielsen Tom Søndergaard Pedersen Synopsis: This report deals with the development and the design of an autonomous surveillence camera. The design involves the implementation of a feedback system, which has the purpose of determining the direction of a camera, by the use of a DC motor and a stepper motor. The feedback of the system takes place through the use of picture analysis on the video stream, that is registered by the camera. This generates a set of coordinates which are directed to a motor-operation system. The regulator also makes use of a PI-controller, that will be designed through analysis and is included in this report. Editions: 6 ed. Pages: 96 Attachments: 1 CD attached Completion of project: 19/ The contents of this report is freely available, however, publication with source reference may only occur as agreed with the authors.

4

5 Kapitel1 Forord Denne rapport er blevet udarbejdet af gruppe 505, i forbindelse med 5. semester projektet på Aalborg Universitet. Temaet for dette semesterprojekt er Tilbagekoblede Realtidssystemer. Det forventes at læseren har en viden der svarer til 5. semester på Aalborg Universitet, eller højere. Målet med dette semester er at opnå en grundlæggende viden for tilbagekoblingsteori, samt at kunne analysere et dynamist system i tid- samt frekvensdomænet. Derudover at kunne forstå betydningen af poler og nulpunkter, samt anvende systematiske metoder og stabilitetskriterier til analyse og design af reguleringssystemer. For at opnå dette blev en række projekt forslag givet, hvoraf det valgte projekt blev udarbejdelsen af et automatisk overvågningskamera. På side 60 ses litteratur listen, med bilag efterfølgende. Bilagene indeholder supplerende materiale som er vurderet til at fremhæve forståelsen, men som ikke er af direkte betydning for løsningen af problemstillingen. Datablade, software, videoer samt en elektronisk version af rapporten o.a. relevant dokumentation kan findes bagerst i rapport på en vedlagt CD-Rom. Gruppen vil gerne takke Jean Charles Mammana, for brug af hans Java kode til billedebehandlingen i software udviklingen. Mohamed Ishag Glenn Christiansen Rasmus Nielsen 5 af 96

6

7 Indhold 1 Forord 5 2 Indledning Problemanalyse Problemformulering Analyse Use-cases og brugerinterface Funtionskrav Teknisk kravspecifikationer Hardware Software Interface og implementation Løsningsforslag Beskrivelse af blokkene Hardware Design Kameraopstilling Billede behandling Motorstyring System Interface DC-motor delen af systemet DC-motor Kommunikation mellem PC og kamera Hardware Design Hardware moduler af 96

8 INDHOLD Analyse modulet Motorstyrings modulet Kamera modul Motorstyrings modul PIC processor DA-Converter DC-motor Stepper motor Delkonklusion Software Design Realtids Systemer Motion-JPEG RGB farvemodellen Andre farvemodeller Moduler Udvinding af video feed Pseudo kode Billedebehandling Pseudo kode Lokalisering af objekt Pseudo kode Notificering af motorstyring Pseudo kode PIC program Pseudo kode Konklusion på software Konklusion 56 6 Perspektivering 58 Litteratur 60 A Modellering af DC-Motor 61 A.1 Kredsløbdiagram af DC-motor af 96 INDHOLD

9 INDHOLD A.2 Systemligning B Målejournaler 64 B.1 Forsinkelse i kamera B.1.1 Formål B.1.2 Apparaturliste B.1.3 Forsøgsbeskrivelse B.1.4 Forsøgsopstilling B.1.5 Fremgangsmåde B.1.6 Resultater B.1.7 Konklusion B.2 DC-motor B.2.1 Apparaturliste B.2.2 Opstilling C Diagram 74 C.1 Stykliste med de valgte komponenter C.2 Stepperstyring C.3 PIC D Software kode 77 D.1 JArobotTracking.java D.2 JArobotTrackingWindowListener.java D.3 Control.java D.4 MjpegParser.java D.5 MjpegParserIncompleteSegmentException.java D.6 MjpegParserListener.java D.7 MjpegStreaming.java D.8 FramePanel.java D.9 IFramePanel.java D.10 BaseImageTransform.java D.11 IImageTransform.java D.12 ImageLabel.java INDHOLD 9 af 96

10 Kapitel2 Indledning Overvågningssystemer anvendes på forskellige steder og bruges af forskellige årsager, såsom på institutioner, banker, virksomheder osv. Disse bruges til at overvåge og/eller registrere tilstedeværelsen af uvedkommende. De kan også bruges til at registrere en ønsket aktivitet som, for eksempel, i busser, butikker, metro, mm. Håndteringen af overvågningsresultater er blevet lettere som følge af Internettet og digitaliseringen. Den primære fordel ligger i håndteringen af billedoptagelse og overførsel, hvor det med et IP eller netværkskamera er muligt at overføre optagelser til computere eller andre lagringsmedier, der befinder sig fjernt fra stedet. Optagelserne kan herefter ses på stedet eller sendes via Internettet til hvilket som helst sted. Ydermere, giver det automatiske overvågningssystem en mulighed for langt nemmere at kunne fjernstyre flere kameraer i et system via en PC og derved udnytte internettet til at overføre data over lange afstande i løbet af kort tid. Dette kunne eksempelvis have sin anvendelse i afdelinger der befinder sig langt væk fra hinanden. I dette projekt udarbejdes et overvågningssystem, der er baserer sig på et digitalt farvekamera. Formålet er at iagttage et objekt (evt. et legekøretøj) i bevægelse. Automatiseringen af overvågningssystemet sker ved implementering af et softwareprogram, som ved hjælp af en form for motorstyring vil gøre det muligt at følge et objekt i forskellige retninger. Der vil blive implementeret et reguleringssystem, der sørger for at iagttagelsen skal se i realtid. Systemet kobles til en PC, så det vil være muligt at se disse realtids optagelser på skærmen. 10 af 96

11 2.1 Problemanalyse 2.1 Problemanalyse En konstruktion af et overvågningskamera, der er i stand til at iagttage et objekt i bevægelse, er ønsket. Kameraet skal kunne optage og sende data i form af realtids optagelser. Kapitlet vil først give en overordnet analyse af problemstillingen. Herefter, analyseres designet af den grafiske brugergrænseflade. Dernæst, belyses systemdesignet med udgangspunkt i UML modellen etc, som overvejende bliver benyttet. Der kan dog forekomme undtagelse og justeringer, da ikke alt i UML-modellen synes relevant i dette projekt. Til sidst redegøres for hvordan og hvorledes løsningen for problemstillingen vil være. Løsningsforslaget vil omfatte hardware, software og implementering af disse. For at kameraet skal kunne følge et objekt automatisk, kræves det at kameraet kan dreje i to retninger, hhv. horisontalt og vertikalt. Ud over roteringen på x- og y- akserne, er det vigtigt at kameraet kan følge med objektet, hvis dette bevæger sig. Problemstillingen kræver et tilpasnings system for at kunne virke i realtids tilstand. Årsagen er, at der er mange aktører, der kan påvirke miljøet omkring det overvågede objekt. Disse variationer stammer generelt fra to aspekter. Et geometrisk aspekt der bestemmes af sted, størrelse, etc., og et visuelt aspekt så som belysning og billedkvalitet. Disse spørgsmål vil blive besvaret gennem rapporten i det omfang tiden tillader. Dette giver anledning til følgende problemformulering Problemformulering Ud fra problemanalysen, formuleres projekt problemstillingen som følgende Der skal konstrueres et overvågningskamera system, der automatisk kan følge og iagttage et bevægende objekt. Det skal være muligt at overføre objektbilledet til en PC og vises på skærmen. Afgrænsning Med overvågning af et objekt i bevægelse menes det mønster, der repræsenterer objektet i systemets algoritme. Køretøjets hastighed vil ikke blive undersøgt, da dette ikke er nødvendigt for optagelsen. Dette gælder ligeledes for størrelsen af objektet. Der vil kun blive fokuseret på at tracke et objektet. Det er ønsket at bestemme, hvilken betydning stepper- og DC-motorer samt algoritmer har på systemdynamikken. Herunder, hvordan disse påvirker realtids optagelser på skærmen. Ligeledes vil der også undersøges hvilken sammenhæng der er mellem vinkelbestemmelse og lukketsløjfefunktion, for således at lokalisere hvor objektet befinder sig i rummet. da dette anses for at være relevant for at undersøge forholdene vedrørende systemstabilitet. Systemudviklingen vil tage udgangspunkt i at optage i dagslys og derfor ikke vil undersøge kameraet s funktion i mørket. 2. Indledning 11 af 96

12 2.2 Analyse Anvendte metoder Første trin af projektet er analysen. Igennem en beskrivende analyse bliver der kigget på projektets struktur. Forskellige faser af kravspecifikation, blokopdeling, hardware konstruktion og software design vil blive analyseret. Begrebet COBRA og CODRATS bliver undersøgt igennem en beskrivende analyse, med udgangspunkt i Hassan Gomaa s teorier. Ved disse analyser bruges der primære data, fra artikler af de ovennævnte, samt tekniske dokumenter og rapporter for udvikling af indlejrede systemer. Næste trin i analysen bliver en eksplorativ analyse til at få mere fokus på hvad for et konkret problem kan danne grundlag for videreudvikling af software og implementering på selve produktet. Formålet er at undersøge hvilke programmeringssprog er bedst egnet til den konkrete situation. Efter de forskellige analyser af projektets komponenter, udvikles konceptet og selve produktet. Produktet bliver designet efter de ønskede kravspecifikationer. Prototypen for produktet bliver herefter testet og test resultaterne sammenlignes med de fastlagte krav. Til sidst konkluderes på projektet, både med hensyn til udvikling af konceptet og produktet. Endelig, perspektiveres på projektet i forhold til proces, udvikling og resultater. 2.2 Analyse Analysen er delt op i fem dele, som ses forneden. 1. Use cases 2. Krav 3. Hardware 4. Software 5. Interface og implementation Use-cases og brugerinterface Brugeren har behov for at betjene et overvågningssystem. Derfor opstilles nogle brugermønstre, der har til formål at Beskrive interaktionsmønstrene med systemet Vise sekvensen af transaktioner fra/til en eller flere aktører Beskrive mulige anvendelses scenarier 12 af Indledning

13 2.2 Analyse Kamerasystem bruger Computer lokaliser objekt vis position og optag Derudover kan use-cases også hjælpe udvikleren til direkte at specificere systemkravene og udvikle sit projekt/produkt. Figur 2.1 viser use-case diagrammet for kamerasystemet. Use case moobjekt bestem retning Computer vis billede Reset Figur 2.1: Use-case diagram for kamerasystem. dellen viser tre aktører, der hver især påvirker systemet på sin egen måde. Disse aktører, som kan ses på diagrammet er nemlig, brugeren, computeren og objektet. Brugeren er den primære aktør, der får hele overvågningssystemet til at fungere. Brugeren er ligeledes aktøren, der giver systemet input og får output. Computeren spiller rollen som både aktør og en del af kamerasystemet. En aktør, fordi den giver systemet input og får output. Og en del af systemet, da systemsoftwaren ligger og kører ind i den. Den sidste aktør er objektet, der påvirker systemet kun med dets bevægelse. Ud fra use-case diagrammet kan det siges, at brugeren kun har een eller to måde(r) hvorpå brugeren kan påvirke kamerasystemet på. Dette sker ved at brugeren kan tænde/slukke for systemet via brugerinterfacet (computer tastaturet). Herefter vil kamerasystemet køre af sig selv med mindre der sker en fejl. I dette tilfælde, er det muligt at nulstille funktionen ved at slukke og tænde igen. I realiteten betyder dette at brugeren ingen indflydelse har på funktionaliteten udover at tænde, slukke og nulstille systemet, da alle de viste funktioner foretages af systemet. Dette giver anledning til at opstille følgende få funktionskrav for kamerasystemet Funtionskrav I dette afsnit opstilles funktionskravene som set fra bruger siden. Disse krav er nødvendige for interaktionen mellem slutbrugeren og kamerasystemet. De tekniske systemkrav vil blive opstillet i afsnittet om teknisk kravspecifikation. Tænd/sluk Drej i lodret 2. Indledning 13 af 96

14 2.2 Analyse Drej i vandret Optag objektbillede i realtid Vis realtids billede på skærm Teknisk kravspecifikationer I dette afsnit opstilles systemets tekniske kravspecifikationer. Kravene opstilles som set fra produktdesignerens side. Kravene opstilles, således at prototypen vil komme til at opfylde de forventede funktionalitetskrav, der blev defineret i funktionskrav og use-cases. Ud fra fastlæggelsen af tekniskkrav, vil det være muligt at give en løsningsforslag til realisering af produktprototype. Herunder defineres kamerasystemets tekniske krav. Som udgangspunkt skal systemet forsynes med 5V DC undtagen DC- og steppermotorer, der kan varierer lidt i deres spændingsniveau. Det skal være muligt, at tænde og slukke for kameraet gennem PCen Det skal være muligt at tage minimum 25 frames/sec. Maksimum billedefil skal fylde pixel Kommunikation mellem PC og kameraet Motorerne skal kunne drejes mellem 0-90 lodretretning og i vandretretning. Stepperen skal dreje med 10rpm Hardware For at finde ud af hvilke krav der stilles til dynamisk modellering af et overvågningssystem og i hvilket omfang dette kan realiseres i forhold til de begrænsninger, der er blevet sat, vil der blive kigget på hvilket hardware, systemet vil indeholde. Der vil blive anvendt et kamera, der er i stand til at optage billeder i et format, der kan vises på en computer skærm. Ud fra funktionskravene, blev det bestemt at bruge to motorer til at få kameraet til at dreje til henholdsvis vand- og lodret positioner. Der er også behov for bruger-interface, hvis formål er at give brugeren mulighed i at styre kamerasystemet. Derfor blev det bestemt at anvende en computer dels som bruger-interface og til dels som regulering enhed. Dette betyder at systemsoftwaren vil komme til at ligge og køre gennem PC en. Ud over anvendelse som bruger interface, vil computeren også bruges til at gemme systemalgoritmen. En driver modul, der kan styre motorerne, er ønsket. Modulet vil sammen med PC en udgøre hele styringsenhed for automatisering af overvågningsenhed. Figur 2.2 viser det ønskede hardware layout. De forskellige dele af blokdiagrammet, vil blive næmere beskrevet i afsnittet om løsningsforslag. 14 af Indledning

15 2.2 Analyse Spændings forsyning Computer styrmodul Motorer Kamera feedback Figur 2.2: Overordnet layout af kamerasystem Software Denne del af analysen vil undersøge hvilken software kunne være egnet til styring af kamerasystemet. Softwaren vil have det formål at den skal foretage et billedegenkendelses algoritme. Denne billedegenkendelses algoritme vil modtage et video feed fra kameraet og bryde det ned i pixels. Herefter vil hver pixel blive analyseret, og der returneres hhv. et 1 eller et 0. Formålet med dette er at lave et 640x480 array, som et undersøge et massemidtpunkt af enten ettere eller nullere i arrayet. Dette gøres således at et form for koordinatsæt beregnes. Softwaren vil have det formål at den skal foretage et billedegenkendelses algoritme. Denne billedegenkendelses algoritme vil modtage et video feed fra kameraet og bryde det ned i pixels. Herefter vil hver pixel blive analyseret, og der returneres hhv. et 1 eller et 0. Formålet med dette er at lave et 640x480 array, som undersøges for et massemidtpunkt af enten ettere eller nullere i arrayet. Dette gøres således at en form for koordinatsæt beregnes. Dette koordinatsæt er vigtigt, idet motorstyringen skal benytte sættet til at vinkle kameraet den rigtige retning til netop det objekt der ønskes at overvåge. Hvis ikke dette koordinat sæt beregnes korrekt, vil der ikke kunne forudsiges hvor motorstyringen vil sende kameraet hen. Derudover, vil det også være muligt at skifte overvågningstilstand. Udover en tracking tilstand, vil kameraet også bestå af en roame tilstand, der fungerer på den simple måde at kameraet drejer fra side til side. For at kunne lave dette skift vil det kræve en form for bruger-interface sådan at der kan skiftes frem og tilbage mellem de to tilstande Interface og implementation Interaktionsdesign og implementations analyse vil fokusere på den proces hvor, det vil være muligt at nå frem til hvordan de forskellige dele af systemet fungerer som en enhed. Til at finde ud af hvilke krav der stilles til et interface af overvågningssystemet, og hvordan og i hvilket omfang dette kan realiseres i forhold til de begrænsninger, der blev nævnt. Der vil blive kigget på hvilken, model af interface vil være egnet til systemet. 2. Indledning 15 af 96

16 2.3 Løsningsforslag 2.3 Løsningsforslag I dette afsnit redegøres for blokdiagrammerne samt deres funktionalitet. Først beskrives blokdiagrammets dele. Herefter gives en begrundelse for valget af de anvendte komponenter Beskrivelse af blokkene I det kommende afsnit beskrives blokkene og deres funktion. Der vil blive givet en detaljeret beskrivelse af hver blok og dens funktionsmæssige rolle. Baggrunden for valget af hver komponent bliver opgivet og anvendelses formål vil også blive redegjort for. Først opgives blokdiagrammet for løsningsforslaget. Figur 2.3 viser dette diagram, og fungerer som et overordnet billedet af det færdige system. Derudover vil systemet blive forsynet med en ekstern spændingsforsyning, derfor en forsyningsblok ikke er inkluderet i flowet. Spændings forsyning Driver kontroller Stepper driver Stepper motor PC RS232 PIC & Regulator DC-motor Driver DC motor Kamera Figur 2.3: Blokdiagram af kamerasystem Valg af motorer, drivere og drivere kontrollere På baggrund af de ønskede krav, vil det nu være på sin plads at bestemme hvilke motorer, der vil blive anvendt til styringen af overvågningssystemet. Det er tidligere blevet bestemt at anvende to motorer. En DC motor til styring af kameraposition i vandret retning og en stepper motor til styring af kamera bevægelse i lodret retning. Styring i vandrette akse er overladt til DC motoren, idet der ønskes en jævnbevægelse i den retning. Dette sker på grund af at det er denne akse som vurderes at ville bevæge sig mest. Derudover, er det blevet bestemt at bruge to general purpose motorer. Dermed er valget af DC motoren faldet på en gearet motor fra Maclennan Servo Supplies[Supplies, 2006]. Den anden motor er en 2-faset stepper motor fra Sonceboz. Specifikationerne for valgte motorer kan der læses mere om i afsnittet om motorstyring. Stepper motoren, samt DC motoren skal kunne styres i begge retninger. For at kunne realisere dette, vælges en L298[Thomson, 1995] der fungerer som en effektforstærker. Denne kreds er velegnet til bidirectional, hvilket på dansk antyder to-vejs styring af motoraksel bevægelse. Fordelen ved denne driver er, at den kan drive både DC og stepper motoren, dog bliver den kun benyttet til steppermodulet. En anden fordel er dens logiske lav, der ligger mellem 0 ned til 1,5 Volt. Udover dette, så er den også TTL kompatibel. Dette giver mulighed for at kunne arbejde med TTL kredse hvis konfiguration kræver en TTL kompatibilitet. For at styre DC-motoren benyttes en PIC hvorpå et styrings software bliver programmeret på. 16 af Indledning

17 2.3 Løsningsforslag Ud fra denne kode, bliver der genereret en binær tal værdi, der beskriver den spænding som skal sætte på DC-motoren for at få den til at dreje den rigtig retning. Men denne binære værdi kan ikke blot sendes til motoren, idet denne kræver analoge spændinger. For at gøre dette konverteres det digitale signal til et analogt og dermed fås den analoge spænding som skal bruges. Ved denne konvertering benyttes AD7524[Devices, 2003] der er en 8-bit Digital til Analog Converter. Udover L298, bruges der Gates til at generere de nødvendige pulser, der kræves for at styre L298 kredsen. Gruppen har valgt at styre stepper motoren i half-step tilstand. Dette vil sige at, der køres med 1,8 2 = 0,9 pr. step for at minimere fejl i forhold til kameraet. Og dette kan lade sig gøre via opkobling i Gatene. Kamera Udfra kravspecifikationerne i afsnit 2.2.3, vælges et kamera, der er egnet til formålet. På baggrund af gruppens analyse af forskellige kameratyper er det blevet bestemt at anvende IP kameraet Axis 205, fra Axis Communication. Dette kamera er i stand til at optage op til 30 frames/sec. Seriel forbindelse - RS232 En seriel port på en pc er en full-duplex enhed, dvs. den kan sende og modtage data samtidig. Det er derfor nødvendigt, at et serielt kabel som minimum består af tre ledere: en til at sende, en til at modtage og et fælles nul. Kommunikationsformen kaldes også for bi-directional. Nogle apparater kan være udstyret med en half-duplex seriel port. Dette betyder at de således kun kan sende eller modtage data på skift. På baggrund af ovenstående, har gruppen bestemt at bruge en RS-232 forbindelse til kommunikation mellem kamera styringen og PC en. For at realisere kommunikationen med RS-232 kabel, vælges en MAX232 kreds til dette formål. Denne kreds kan virke både som modtager og sender. Derudover, så er den i stand til, med sine 2 interne oplade pumpe, at konverterer +5V spændingsforsyning til ±15V, der kræves af RS232 kablet. Clock-kredsløb De valgte Gates, skal have en stabil clockfrekvens for at yde god drift. Til dette formål har gruppen valgt at bruge en 555-timer, der kan levere en stabil clockpuls. 555-kredsen er også nemmere at designe og implementere, og gøres ved hjælp af få passive komponenter. 2. Indledning 17 af 96

18 2.3 Løsningsforslag Θ ref = 0 + V b (s) ϕ 1(s) θ 1 (s) D 1 (s) G 1 (s) + w H(s) Figur 2.4: DC-motor Regulerings Blokdiagram. Regulatorblok, D(s) Som udgangspunkt starter systemet ved reference punktet Θ re f = 0. Denne vinkel er forskellen fra fejlen og det som kommer fra H(s) (kamera og PC). I realiteten fås data fra PC gennem en RS-232 forbindelse til hardware delen af systemet. Denne data kommer fra kameraet, og gennem billedebehandlingen og bliver lavet om til en form for koordinatsæt. Disse kommende data indsættes i regulatoren D(s), der består af nogle logiske gates. Ud fra D(s) fås en spænding, V a (s). Denne spænding skal, således svare til de pulser, der styrer enten DC- eller stepper motor. Procesblok, G(s) G(s) udgør processen for motorstyringen, der skal holde kameraet i den rigtige retning. Spændingen V a (s), der fås fra D(s) sørger for at motor driverne leverer den rigtige DC-spænding (for DC-motor) eller de korrekte puls modulerede signaler til stepper motor kredsen. Ud fra motor kredsløbet kommer der en vinkel ϕ(s). Denne vinkel summeres med forstyrelsen (positionsvinkel fra objektet). Det er ønsket at summen af vinklerne ϕ(s) og W(s) skal være nul, idet dette betyder at objektet bliver holdt i midten af kamerafeltet. Er vinklen θ(s) = 0, fås et stabilt reference punkt Θ re f, og dermed mindre reguleringsfejl i systemet. Sensorblok, H(s) H(s) består, som det kan ses i blokdiagrammet, principielt af kameraet og PC en. De er fysisk adskilt, men udgør til sammen en blok. H(s), er tilbagekoblingsnetværket, der modtager den tilbagekoblede udgang θ(s) og sender signalet videre til kontrolleren D(s) via reference punktet, så der således påbegyndes et nyt forløb. Overføringsfunktion fra θ til Θ re f Figur 2.5 viser overføringsfunktionen fra W(s) gennem H(s) og op til G(s). I det følgende tegnes blokdiagrammet af W(s) og dens overføringsfunktion bliver udledt som kan ses herunder overføringsfunktion udtrykkes W(s) til θ(a) kan nu udtrykkes på følgende måde 18 af Indledning

19 2.4 Hardware Design w 1 θ(s) D (s) G (s) H(s) 1 Figur 2.5: Overføringsfunktion fra θ til Θ re f. θ( s) 1 = H w( s) 1+ D( s) G( s) H ( s) L.S = Y (s) X(s) = θ(s) W(s) 1 = 1 + [1 (DGH(s)] Θ ref = 0 + D ( ) G ( s) 2 2 s V b (s) ϕ ( ) θ 2 ( s) 2 s + w H(s) Figur 2.6: Stepper motor Regulerings Blokdiagram. 2.4 Hardware Design Dette afsnit handler udelukkende om analyse for hardware design. Dette sker på baggrund af komponentvalget. Overordnet set ønskes systemet at indeholde de ønskede moduler, der kan ses i punktopstillingen nedenfor. Kameraopstilling Motorer styring Billede behandling System interface 2. Indledning 19 af 96

20 2.4 Hardware Design Kameraopstilling Kameraet skal kunne følge et objekt. For at gøre dette så simpelt som muligt antages det at objektet, der ønskes at blive overvåget, er en rød bold e.l. Derudover, antages det at kameraet har en brændvidde på 30 o, skal kamera opstillingen konstrueres på en sådan måde at det er muligt for kameraet at dreje 120 o i den horisontale retning og 60 o i den vertikale retning. Opstillingen af kameraet kan ses på figur 2.7. Opstillingen er valgt på baggrund af at laboratoriet i forvejen var i besiddelse af en opstilling, gruppen kunne benytte sig af. y V x H Figur 2.7: Kamera opstillingen. Optagelses rækkevidde Figur 2.8 illusterer optagelses rækkevidden for kameraet. Det blev besluttet at kameraet med den ovenstående opstilling, skal optage i henholdsvis lod-og vandret. I lodret retning, skal kamera bevæge sig maksimalt 90 og i vandret orientering, sker dette i maksimalt 180. y y 90 x x 180 Figur 2.8: Kamera opstillingen. 20 af Indledning

21 2.4 Hardware Design Billede behandling Overvågningskameraet vil blive styret gennem en form for billedebehandling der vil køre på en PC som bliver tilsluttet systemet. Denne billedebehandling vil modtage et live feed fra kameraet og derefter bearbejde det billede som kameraet opfanger. Herefter bliver billedet konverteret til sort og hvid alt efter hvad farve pixelen oprindeligt var. Når dette så er gjort, og billedet er blevet behandlet resultater dette i nogle instrukser der skal sendes til motorstyringen af kameraet. Disse instrukser bestemmer hvilke motorer der skal køre i hvor lang tid, således at kameraet vil pege i den rigtige retning. [Franklin et al., 2006] Motorstyring Enkelte modeller af overvågningskamera gør brug at en motor, således at kameraet kan roame fra side til side, sådan at et større område kan overvåges. I afsnit 2.2.3, kravspecifikationer, blev overvågnings vinklerne for motorstyringen fastlagt. Figur 2.8 viser stativet med de tilhørende motorer. Foran hver motor er der tegnet to pile, der hver især peger en bestemt retning. Pilene på motorerne indikerer kameraorienteringen på henholdsvis lod- og vandret. Denne roaming bevægelse er principielt dét et overvågningskamera kan gøre og essensen af dette kan realiseres let, idet styringen kan laves sådan at motoren efter et bestemt stykke tid vil stoppe, og derefter vendes polerne således at motoren kører den modsatte retning i samme tidsrum. Men målet i dette projekt er at lave en måde hvorpå at kameraet følger et objekt autonomisk. Dette vil kræve at motoren bliver styret udefra i en sådan grad at kameraets position bestemmes gennem algoritmer der bearbejder signalet fra kamera feed et System Interface Et interface til overvågningskameraet skal give brugeren mulighed for ikke kun at kunne følge med i hvad kameraet opfanger. For eksempel kunne den enkelte bruger være interesseret i at kameraet enten skal følge et bestemt objekt, eller om det blot skal roame fra side til side. Ved roame skal det forstås sådan at kameraet blot drejer fra side til side, som ved et konventionelt overvågnings kamera. Her kan brugeren så bestemme hvor kameraet skal pege, frem for at han 1 selv skal justere kameraet, fysisk DC-motor delen af systemet I de følgende afsnit foretages stabilitets undersøgelse samt af regulatorer. Men før dette kan lade sig gøre skal de valgte motorer først modelleres. Denne modellering kan findes i appendiks A.1. 1 Han skal forstås som han eller hun igennem resten af rapporten 2. Indledning 21 af 96

22 2.4 Hardware Design DC-motor DC-motor systemanalyse Figur 2.9 viser DC-motor delen af systemet, hvori følgende er opgivet R (s) + D(s) k p + ki s A p G(s) K 1 s( sτ +1) H(s) ke st d Figur 2.9: DC-motor delen af systemet. G(s) = K s(sτ+1) : Overføringsfunktion for DC-motor. H(s) = e st d: Overføringsfunktion for kamera (delay). D(s) = k p + k i s : Er den valgte PI regulator. A p : Effektforstærkning. Effektforstærkeren er blevet bestemt til have en forstærkning på 1. Og da overføringsfunktionen for DC-motoren og kameraet er blevet bestemt, kan en regulator til DC-motoren bestemmes. Det ønskes at der skal være systemstabilitet, så ud fra det standpunkt skal en regulator bestemmes. Dette gøres først ved at opskrive en overføringsfunktion for blokdiagrammet som kan betragtes i figur 2.9. Herefter undersøges det samlede system for stabilitet. Dette gøres ved at anvende Bode-plot metoden. Først opstilles overføringsfunktioner DC-motor delen. T (s) = DG(s) 1 + DGH(s) (k P + k i = k 1 + (k i P = s ) K s(sτ+1) s ) K s(sτ+1) e( st d) (k P + k i s )K s(τs + 1) + (k P + k i s )K e( st d) (2.1) (2.2) (2.3) Stabilitets undersøgelse ved hjælp af Bode-plot Det blev bestemt at Bode-plot undersøgelse foretages for åbensløjfe med k p = 1 og uden k i. Åbensløjfe overføringsfunktion for systemet er. H(s) = D(s)G(s)H(s) (2.4) = (k P + k I s ) K (τs 2 + s) e st d (2.5) 22 af Indledning

23 2.4 Hardware Design Ved først at indsætte s = jω fås H(s) som, H( jω) = (k P + k I s ) K (τ jω 2 + jω) e jωt d (2.6) = (k P + k I s ) K τω 2 + jω e jωt d (2.7) Hvor (K), (k p ), (τ) og (T d ) er konstanter. T d fandtes til at være 0,2 sec. (K) og (τ) er opgivet som, hvor det skal noteres at (K e ) = (K t ). Der beynttes (K t ). K t K = br a + K t K e K t = br a + Kt 2 τ = R aj m br a + Kt 2 Ved at indsætte forsøgs resultaterne fra appendiks B.2, ind i (K) s og (τ) s formler fås. K t K = br a + K t K e K t = br a + Kt = (2, ,87Ω) = 17,3 og τ = R aj m br a + Kt 2 352, = (2, ,87Ω) + ( ) 2 = 0,0105 Dermed bliver H( jω) 2. Indledning 23 af 96

24 2.4 Hardware Design H( jω) = (k P + k I s ) K (τ jω 2 + jω) e jωt d (2.8) = (k P + k I s ) 17,3 0,0105ω 2 + jω e 0,2 jω (2.9) Amplitude og fase for H(s) Tidsdelayet e st d i sig selv, har ikke en stor indfyldelse på amplituden, da den er 1 for alle (ω), [Franklin et al., 2006]. Det vil sige at M = G D ( jω) = e ( jωt d) = 1 ω Mens dens amplitude giver en fasedrejning på 90. I efterfølgende simuleres H(s) for at undersøge hvorvidt systemet er stabilt eller ej. Simulering er foretaget i MatLab og figur 2.10 viser amplitude og fase for H(s) inklusiv tidsdelayet. Bode Diagram 15 Magnitude (db) kp = 1 K = 17,3 Tau = 0,0105 Td = 0, Phase (deg) Frequency (rad/sec) Figur 2.10: Amplitude og fase for H(s). Ud fra Bode-plottet, kan det ses at systemet er ustabilt ikke mindst på grund af tidsdelayet, der 24 af Indledning

25 2.4 Hardware Design giver en stor fase-margin. Dette kan ses på nedenstående figur Bode Diagram Gm = db (at 7.46 rad/sec), Pm = -115 deg (at 17 rad/sec) Magnitude (db) kp = 1 K = 17,3 Tau = 0,0105 Td = 0, Phase (deg) Frequency (rad/sec) Figur 2.11: Fase-margin for H(s). Ustabiliteten i amplitude og fasekarakteristikken af overføringsfunktionen, der ses i forrige to grafer stammer fra opførelsen af tidsforsinkelsen. Da tidsforsinkelsen e st d har en overføringsfunktion, der ikke er stabil som kan ses i grafen på figur Nyquist Diagram 6 4 kp = 1 K = 17,3 Tau = Td = Imaginary Axis Real Axis Figur 2.12: Nyquist graf for tidsdelayet e st d. 2. Indledning 25 af 96

26 2.4 Hardware Design En step respons på overføringsfunktionen vil vise forholdene ved rise time, overshoot og settling time. Disse størrelse kan ikke umiddelbart mærkes på frekvens responsen, men kan ses bedre ved step respons, der ses på figur x 104 Step Response kp=1 K=17.3 tau= Td= Amplitude Time (sec) Figur 2.13: Step respons for åbensløjfe overføringsfunktion af DC-system. Ud fra undersøgelse af frekvens og steprespons, Bode-plot og grafer for systemets overføringsfunktion samt tidsdelayet, kan der konkluderes at systemet er ustabilt. I efterfølgende afsnit designes en regulator, der vil stabilisere overføringsfunktionen for DC-motoren. Først gives en beskrivelse af PID begrebet, hvorefter der belyses hvilken regulator som anvendes. Typer af Regulatorer k P = Proportional gain k I = Integral gain k D = Derivative gain En proportional kontroller (k P ) vil sørge for at reducere stigningstiden. Den vil også prøve at reducere steady-state fejlen, men aldrig fjerne fejlen helt. En integrator (k P ) vil have den virkning at eliminere steady-state fejl, men samtidig gøre transient responsen værre. En differential kontroller (k D ) vil have den virkning at øge stabiliteten i systemet, mindske overskridelsen overshoot, samt en forbedring af transient responsen. Effekten af hver af kontrollerne k P, k D, og k I er sammenfattet i tabellen nedenfor. Tabellen viser deres virkning for lukketsløjfe konfigurationen. t r : Rise time, er tiden det tager systemsignalet at stige fra 10% til 90% af max. amplitude. M p : Overshoot, er max. værdien der opnås af singalet hvorefter går til minimum. t s : Settling time, er tiden det tager system transienten at falde til ro. 26 af Indledning

27 2.4 Hardware Design Lukket-sløjfe t r M p t s Steady-State fejl k P Falder Stiger Lille ændring Falder k I Falder Stiger Falder Fjernes k D Lille ændring Falder Falder Lille ændring t p : Peak time, er tiden det tager signalet at opnå overshoot punktet. Følgende er åben-og lukketsløjfe overføringsfunktioner, der blev opstillet for DC-motor delen H(s): Åbensløjfe H(s): Lukketsløjfe H(s) = D(s)G(s)H(s) H(s) = D(s)G(s) 1 + D(s)G(s)H(s) Design af regulator: PI PI kontroller = (k P + k I s ) H(s) = D(s)G(s)H(s) (2.10) = Ke st d τs 2 + s (2.11) Den karakteristiske ligning (K.L) for systemet opstilles som K.L = 1 + (PI) H(s) ( = 1 + k P + k ) I Ke st d s τs s + s = ( τs 2 + s ) ( 1 + k P + k ) I Ke st d (τs s + s) s τs 2 + s = (τs 2 + s) + k P (Ke st d ) + k I(Ke st d) ( s = τs k I(Ke st ) d) s 2 s + k P (Ke st d ) Ud fra karakteristisk ligning ønskes bestemmelse af kontanterne k P og k I. Dette bliver lidt svært når tids forsinkelse e st d står på nuværende from. e st d kan approksimeres ved hjælp af Pade s approksimation formel [Franklin et al., 2006]. Der bruges en 2. grad s approksimation af Pade s 2. Indledning 27 af 96

28 2.4 Hardware Design formel 2 ) e st d = ( 1 st d 2 ) + ( st d 12 ( 1+sT d 2 ) + ( st (2.12) d 12 )2 = 6 6sT d + (st d ) sT d + (st d ) 2 (2.13) Tiden T d = 0,2 sec., der blev bestemt tidligere jf. forsøges resultater indsættes i formlen, som giver Ved indsættelse af 0,99 i K.L fås, = 6 s6 0,2 + (s 0,2)2 6 + s6 0,2 + (s 0,2) 2 (2.14) = 0, 9960 (2.15) K.L = τs 2 + s + k IK 0,99 s Der forlænges med s på begge side af lighedstegnet + k P K 0,99 = 0 (2.16) K.L = τs 3 + s 2 + (k P K 0,99)s + (k I K 0,99) = 0 (2.17) For at implemente regulatoren, skal konstanterne k P og k I bestemmes. Dette gøres ved anvendelse af Routh s test på sidste ligning[franklin et al., 2006]. b 1 kan findes som determinanten Derterminanten bliver: s n 1. element 2. element 3. element s 3 τ k P K 0,99 0 s 2 1 k I K 0,99 0 s 1 b s 0 k I K 0, τ a 2 det, a 2 a 3 a 1 τ k PK 0,99 = 1 k I K 0,99 1 det = (k P K 0,99) τ(k I K 0,99) > 0 (2.18) 28 af Indledning

29 2.4 Hardware Design Systemet vil være stabilt, hvis ligningen er opfyldt. Dette kræver at K > 0, k I > 0 og k P > 0. K=17,3 og τ = 0,0105. k I og k P bestemmes således k P K 0,99 0,0105 k I K 0,0105 > 0 (2.19) k P skal være større end 0, derfor vælges k P = 10. Dette giver > 0,0105 k I K 0,0105 (2.20) k P 17,2 > k I 0,2 (2.21) 17,2 > k I 0,2 k P (2.22) 17,2 > k I 0,2 10 (2.23) 17,2 10 > k I 0,2 (2.24) k I < 860 (2.25) Forholdet mellem k I og k P er 10. Det vil sige at hvis k P vælges til 1, skal k I divideres med en faktor 10. Regulatoren designes for k P = 10 og k I = 850. I forrige afsnit blev konstanterne k P og k I bestemt. Derfor blev der foretaget en simulering af H(s) med de fundne værdier for at se om der er stabilitet i systemet. Herunder vises grafer for henholdsvis fasemargin og Nyquist. 0 Bode Diagram Gm = 5.21 db (at 9.92 rad/sec), Pm = 106 deg (at 3.39 rad/sec) Magnitude (db) kp=10 ki= Phase (deg) Frequency (rad/sec) 10 1 Figur 2.14: Fasemargin af H(s) med k P = 10 og k I = 850. På figur 2.14 ses at fasemarginen for H(s) er 106 og forstærkningsmarginen er på 5,21dB. Det kan også ses at ved 0dB er fasen omkring 60. Ud fra foregående kan det konkluderes at systemet er stabilt ved de fundne regulator parametre. Dette kan også ses på Nyquist plottet i figur 2.15, hvor skæringen med x-aksen sker ved 0,5, som er langt fra kravet på 1. Dette bekræfter også at der er system stabilitet. 2. Indledning 29 af 96

30 2.4 Hardware Design 1 Nyquist Diagram kp=10 ki= Imaginary Axis Real Axis Figur 2.15: Nyquist graf for H(s) med k p = 10 og k i = 850 Realisering af digital regulator D(z) D(s) en kontinuet regulator. Regulatoren kan skrives i forhold til det ønskede signal U(s) og fejlen E(s). Dette giver følgende D(s) = U(s) E(s) U(s) = D(s)E(s) = sk P + k I s Herefter indsættes værdier af k P og k I i ligningen. Indsættes for eksempel k P = 10 og k I = 850, fås at U(s) = 10s s E(s) U(s) z-transformeres. Dette gøres ved hjælp at MatLabEfter z-transfrom fås U(z) = 14,25z 5,75 z 1 E(z) Der ganges med z 1 på begge side af lighedstegnet. Herefter 30 af Indledning

31 2.4 Hardware Design U(z)(z 1) = (14,25 5,75) E(z) = 14,25zE(z) 5,75E(z) Der ganges med z 1, herefter fås U(z) U(z)z 1 =14,25E(z) 5,75E(z)z 1 Der foretages inverse z-transfrom på ligningen, hvorefter fås U(k) U(k 1) = 14,25E(k) 5,75E(k 1) U(k) = 14,25E(k) 5,75E(k 1) +U(k 1) Den sidste ligning er i princippet den udregning, som skal foretage på PIC en, og dermed skal den kodes derpå. DC-motor delen og dens tilhørende regulator er vist på figur 2.16 nedenfor. w θ ref + θe s u pi 1 u pi K τs 2 + s ϕ θ + w ϕ = θ e st d Figur 2.16: DC-motor med med dens tilhørende regulator Kommunikation mellem PC og kamera Det blev bestemt at data overførsel mellem PC en og kamera modulet, skal ske via RS232 som bliver vist på figur Kommunikations metode implementeres via TCP/IP protokolen TCP/IP er den type protokol der bliver brugt på internettet og andre tilsvarende netværk, og har navnet efter to af de vigtigste protokoller: TCP (Transmission Control Protocol) og IP (Internet Protocol), der var de to første netværks protokoller, der var defineret i Internet protocol suite. Internet Protocol Suite, ligesom mange protokol suiter, kan betragtes som et sæt af lag. Hvert lag løser en række problemer med overførslen af data, og giver en veldefineret service til de øvre lag protokoller baseret på brug af tjenester fra nogle lavere lag. De øverste lag er logisk tættere på brugeren og varetager mere abstrakte data baseret på de lavere lags protokoller til at oversætte 2. Indledning 31 af 96

32 2.4 Hardware Design RS232 PC com port PIC Kamera modul Figur 2.17: RS232 forbindelse data til en form der til sidst kan blive sendt fysisk ud i verdenen. TCP/IP modellen består af 4 lag. Fra lavest til højest, er link laget, internet laget, transport laget og program laget. [Tanenbaum, 2003]!"#$"%& '"%()*#"+!"#$"%& '"%()*#"+,(+-"(-+,(+-"(-+./(0./(0 Figur 2.18: Netværkslag i TCP/IP Program laget Dette lag danner rammen for at brugeren har adgang til information på netværket via et program. Dette lag er bruger-grænsefladen, eller bruger interfacet til programmet, og derigennem til netværket. Transport laget For at tillade en glidende dataoverførsler mellem brugere, benyttes Transport laget. Det aflaster således de øvre lag for bekymringer, mens de giver pålidelige dataoverførsler. Transportlaget tjekker pålideligheden af en given forbindelse via flowkontrol, indpakning / udpakning og fejlkontrol. Nogle protokoller er state- og connection- orienterede. Dette betyder at transportlaget holder styr på pakkerne og gensender dem der aldrig kom frem. 32 af Indledning

33 2.4 Hardware Design Internet laget Internet laget tilbyder de rutiner der skal til, for at sende en variabel størrelse datablok, fra kilde til endestation, via et eller flere netværk. Netværkslaget udfører routing-funktioner (sender pakkerne til deres rette modtager), kan udføre ind- og udpakning og rapportere om leveringsfejl. En router arbejder f.eks. i dette lag, og sender data gennem det udvidede netværk og gør internettet muligt. Der eksisterer også 3. lags (eller IP) Switche. Dette er et logisk adresseringssystem, hvor værdier er valgt af netværksadministratoren. Adressesystemet er struktureret hierakisk. Det betyder at på internettet identificerer computere hinanden ved hjælp af IP-numre, der består af tal. for at gøre det nemmere at huske på for brugeren tildeles der en også et navn, dette sker via en DNSserver (domain name server), dette ses praktisk med at kigge på en www adresse, eksempelvis, esn.aau.dk. Dk er det øverste i den hierakiske pyramide og aau er laget under og esn er i dette tilfælde de nederste lag. Dette gør det nemmere at finde det specifikke netværk man søger. Link laget Link laget giver mulighed for at overføre data mellem netværks-moduler for at finde, og muligvis rette, fejl der måtte optræde i det fysiske lag. Adresserings-metoden er fysisk, d.v.s. MACadressen, der i de fleste tilfælde er hard-coded ind i netkortet. Nogle netværks-kort understøtter, at administratoren specificerer en anden MAC-adresse, men som regel er det ikke muligt at ændre den. Adresseringen er ikke hierakisk opdelt. Det bedst kendte eksempel på dette lag er Ethernet. I dette lag arbejder Netværksbroer og Switche. Forbindelse foregår mellem lokalt tilsluttede netværk der danner link domæner til unicast- eller broadcast-forwarding. Andre protokoller kan blive pålagt frames til at danne tunneller og logisk adskilte link domæner.[tanenbaum, 2003] Imellem lagene er der interface for at de kan kommunikere, der er en lille forsinkelse, TCP/IP protokollen kører med en minimal størrelse på interfacen. Dette giver at den samlede forsinkelse kun er afhængig af længden på kablet mellem computer og webcam. Der benyttes indkapsling til at give en abstaktion af protokoller og tjenester. Sådan en indkapsling er normalt på linje med opdeling af protokollen i lag af generel funktionalitet. I almindelighed, et program (det højste niveau af modellen) bruger et sæt protokoller til at sende sine data ned til det lag, der bliver yderligere indkapslet på hvert lag. [Wikipedia, 2008],(&-% $%&'%( *# $%&'%(!"# $%&'%( "&)&!"# '&)& *#+'&)&,(&-%+'&)&,(&-%.//)%( Figur 2.19: Indkapsling af pakker i TCP/IP Webkameraet, af typen Axis 205, virker på sådan en måde at der er indbygget en webserver i den. 2. Indledning 33 af 96

34 2.4 Hardware Design så den kan tilgåes fra en internet browser, såsom Internet Explorer, Safari eller Mozilla Firefox, og vise streamet som webkameraet opfanger. Typiske webservers kan nævnes er Apache, der har ca. 60% af markedet med hensyn til webservere[apache, 2008]. Apache er en open-source HTTP server for moderne operativsystemer, såsom Unix og Windows. Deres mål er at forsyne en sikker, effektiv og skalerbar server der sørger for at HTTP services kører synkront med den gældende HTTP standard. Apache har været den mest populære webserver på internettet siden april Apache webserveren er et projekt fra pache Software Foundation, og det var den første webserver der kunne håndtere mere end ét domæne per server, og derfor fornyede hosting verdenen, fordi alle nu kunne få deres eget domæne hosted til billig penge. 34 af Indledning

35 Kapitel3 Hardware Design Dette kapitel vil omhandle dimensioneringen af hardwaren for systemet, og dermed vil de enkelte moduler blive designet, og diskuteret. 3.1 Hardware moduler For neden ses de enkelte moduler som overvågningssystemet indeholder. Analyse Motorstyring Kamera Disse vil blive beskrevet nærmere i de følgende afsnit Analyse modulet Analyse modulet har det overordnede formål at modtage et feed fra et kamera, analysere og bearbejde det feed, således nogle data kan uddrages og bruges til motorstyringen. Dette modul, derimod, vil hovedsageligt foregå som software kode der bliver afviklet på en computer og dermed vil dette modul ikke bliver diskuteret i detaljer her, men senere i Software Design i kapitel Motorstyrings modulet For at kameraet kan orienteres i den rigtige retning, er der brug for nogle motorer. Og dermed for at kunne kontrollere disse motorer er der selvfølgelig brug for en form for motorstyring. Denne motorstyring vil modtage data fra Analyse modulet i form af en datastrøm der indeholder informationer om hvordan motorerne skal bevæge sig. 35 af 96

36 3.2 Motorstyrings modul Dette modul kan deles op i yderlige dele, fordi der er brug for en styring, der styrer det horisontale plan og en anden styring, der tager sig af det vertikale plan. Stepperen virker på en sådan måde at den kun kan tage ét step af gangen. Det er så op til en styring til at få den til at dreje rundt, mens en DC-motor vil dreje rundt når blot den får påtrykt en spænding. Dog for at kunne benytte en DC-motor skal der laves en regulering på motoren, der bestemmer om den skal dreje frem eller tilbage når den får påtrykt spændingen Kamera modul Kamera modulet er essentielt blot et IP kamera, der fungerer ved at streame en strøm af JPEG billeder, sådan at det fremstår som et video stream. Analyse modulet modtager dette stream og bearbejder det. Kameraet har dermed ikke en direkte forbindelse til systemet men er et indirekte led, idet den blot optager hvad den ser på. Analyse modulet bearbejder feedet, og sender videre til motorstyringen, som dermed drejer kameraet i den ønskede retning. Ethvert kamera er bundet af et bestemt område det kan holde øje med. Dette område kaldes brændvidde. Brændvidden for et kamera kan være forskelligt alt efter typen af kameraet. Et panorama kamera har et stort brændvidde, og dermed har det mulighed for at se meget mere. Brændvidden er ofte bestemt ved en vinkel fra side til side, og top til bund. F.eks. hvis et kamera har en brændvidde på 60 så har kameraet en billedevinkel der svarer til 60 som det kan se, i den retning det kigger på. 3.2 Motorstyrings modul Formålet med dette afsnit er at beskrive hvorledes motorstyringen vil komme til at fungere. Motorstyringen fungerer således at en datastrøm bliver sendt via en RS-232 forbindelse, til en PIC processor der behandler denne data. Herefter bliver de instrukser der blev sendt via RS-232 eren, sendt til driverkredsløbet. Figur 3.1 viser et overordnet diagram af motorstyrings modul med de elementer, der i dette afsnit. u pi PIC D/ A PC θ kamera DC motor Stepp.motor u pi PIC Figur 3.1: Overordnet blok for motorstyrings modul. Dette kredsløb kan deles op i følgende blokke: Kamera 36 af Hardware Design