Χρήση WSN για ιχνηλάτηση της τροχιάς ενός κινητού με εφαρμογή του walking GPS

Transcript

1 ΡΑΝΕΡΙΣΤΗΜΙΟ ΡΑΤΩΝ ΡΟΛΥΤΕΧΝΙΚΗ ΣΧΟΛΗ ΤΜΗΜΑ ΗΛΕΚΤΟΛΟΓΩΝ ΜΗΧΑΝΙΚΩΝ ΚΑΙ ΤΕΧΝΟΛΟΓΙΑΣ ΥΡΟΛΟΓΙΣΤΩΝ ΤΟΜΕΑΣ ΗΛΕΚΤΟΝΙΚΗΣ ΚΑΙ ΥΡΟΛΟΓΙΣΤΩΝ ΕΓΑΣΤΗΙΟ ΗΛΕΚΤΟΝΙΚΩΝ ΕΦΑΜΟΓΩΝ Χρήση WSN για ιχνηλάτηση της τροχιάς ενός κινητού με εφαρμογή του walking GPS ΔΙΠΛΩΜΑΣΙΚΗ ΕΡΓΑΙΑ ΣΟΤ Αναςτάςιου Αρβανιτόπουλου του Ευαγγζλου ΕΡΙΒΛΕΡΩΝ ΚΑΘΗΓΗΤΗΣ: ΣΤΑΥΟΣ ΚΟΥΜΡΙΑΣ ΣΥΝΕΡΙΒΛΕΡΩΝ ΚΑΘΗΓΗΤΗΣ: ΓΗΓΟΙΟΣ ΚΑΛΥΒΑΣ ΑΙΘΜΟΣ ΔΙΡΛΩΜΑΤΙΚΗΣ ΕΓΑΣΙΑΣ /2011 ΙΟΥΛΙΟΣ 2011

2 2

3 ΡΕΙΕΧΟΜΕΝΑ Ευχαριςτίεσ 6 Ρερίλθψθ. 7 Ρερίλθψθ ςτα αγγλικά Abstract. 8 Ακρωνφμια. 9 Ειςαγωγι 11 Κεφάλαιο 1 ο Αςφρματα Δίκτυα Αιςκθτθρων 1.1 WSN ςθμαίνει Wireless Sensor Networks Χαρακτθριςτικά ενόσ WSN Κόμβοσ Το δομικό ςτοιχείο ενόσ WSN Δομι και Αρχιτεκτονικι Δικτφου Φυςικό επίπεδο MAC επίπεδο Ρρότυπο Δομι δικτφου και είδθ κόμβων Αρχιτεκτονικι Φυςικό επίπεδο MAC επίπεδο. 27 Κεφάλαιο 2 ο Σο δορυφορικό ςφςτθμα GPS 2.1 Node localization και Geographical Routing GPS Global Positioning System Γενικζσ πλθροφορίεσ για το ςφςτθμα Το δορυφορικό ςιμα Διαμόρφωςθ δορυφορικοφ ςιματοσ GPS Δζκτεσ GPS Δορυφορικόσ προςδιοριςμόσ κζςθσ Ρρωτόκολλο ΝΜΕΑ Ρεριγραφι προβλιματοσ Στόχοσ Διπλωματικισ.. 44 Κεφάλαιο 3 ο ΤΛΙΚΟ-Hardware 3.1 Ειςαγωγι IRIS Motes ATmega ATRF230 RF πομποδζκτθσ ΜΙΒ520 Ρρογραμματιςτικι πλακζτα MTS420CC Sensor board 55 Κεφάλαιο 4 ο Λειτουργικό φςτθμα-operating System 4.1 Ειςαγωγι Σχεδίαςθ Λειτουργικοφ Συςτιματοσ για WSN Απαιτιςεισ Λειτουργικό Σφςτθμα TinyOS Μοντζλο Λειτουργίασ Αρχιτεκτονικι Δομι του TinyOS Η γλϊςςα προγραμματιςμοφ nesc. 64 3

4 4.4.1 Async ςυναρτιςεισ και Atomic statements. 66 Κεφάλαιο 5 ο Τλοποίθςθ Εφαρμογισ 5.1 Ειςαγωγι Ρρϊτα βιματα υλοποίθςθσ Δθμιουργία απλισ εφαρμογισ για επικοινωνία κόμβων Εξομοίωςθ TOSSIM Ανάπτυξθ μιασ πρϊτθσ ζκδοςθσ του Base Station Εγκατάςταςθ ςε πραγματικό κόμβο IRIS και ζλεγχοσ Υλοποίθςθ των κυρίωσ εφαρμογϊν Ειςαγωγι: Ρροπαραςκευι και οργάνωςθ των εργαςιϊν Ανάπτυξθ driver του MTS420CC για πλατφόρμα IRIS Ανάπτυξθ εφαρμογισ για λιψθ μετριςεων GPS από το sensor board MTS420CC Ανάπτυξθ εφαρμογισ για λιψθ πακζτων GPS από τον απομακρυςμζνο κόμβο και προϊκθςισ τουσ ςτον υπολογιςτι. 93 Κεφάλαιο 6 ο Επικοινωνία κόμβου υπολογιςτι 6.1 Ειςαγωγι Ανάπτυξθ προγράμματοσ για tracking ςε offline mode Ανάπτυξθ προγράμματοσ για tracking ςε online mode. 105 Κεφάλαιο 7 ο Εφαρμογι και Πειραματικι μελζτθ 7.1 Ειςαγωγι Ρροεργαςία Ρροετοιμαςία πειράματοσ Εντοπιςμόσ κζςθσ και απεικόνιςθ ςτο Google Earth TM ςε offline mode Ραρακολοφκθςθ τθσ τροχιάσ ενόσ κινθτοφ (tracking) και καταγραφι τθσ για απεικόνιςθ ςτο Google Earth TM ςε offline mode Εντοπιςμόσ κζςθσ κόμβου με απεικόνιςθ ςε πραγματικό χρόνο ςτο Google Earth TM (online mode) Ραρακολοφκθςθ τθσ τροχιάσ ενόσ κινθτοφ (tracking) ςε πραγματικό χρόνο και καταγραφι τθσ για απεικόνιςθ ςτο Google Earth TM 123 Κεφάλαιο 8 ο υμπεράςματα και Περαιτζρω ζρευνα 8.1 Συμπεράςματα Σφάλματα Μελλοντικι εργαςία Βιβλιογραφία. 131 Παράρτθμα Α Α.1 Εγκατάςταςθ TinyOS περιβάλλοντοσ ςε Linux 132 Α.2 Εξομοιωτισ TOSSIM TinyOS SIMulator. 133 Α.3 Μετατροπζσ ςτον driver που αναπτφξαμε για το MTS420CC sensor board ζτςι ϊςτε να διαχειρίηεται platform independent τφπουσ δεδομζνων

5 Παράρτθμα Β DataSinkFiFoGPS TinyOS application 136 MyMoteSendReceiveGPS TinyOS application 139 MyMoteSendReceiveSIM TinyOS application 142 USB_read πρόγραμμα ςε C. 145 FirstGEApp πρόγραμμα ςε C# 150 5

6 ΕΤΧΑΡΙΣΙΕ Φτάνοντασ ςτθ γραμμι του τερματιςμοφ μιασ πολφ μεγάλθσ προςπάκειασ, κα ικελα να ευχαριςτιςω ολόκερμα τον κακθγθτι του Ρανεπιςτθμίου Ρατρϊν, κφριο Σταφρο Κουμπιά, για τθν εμπιςτοςφνθ που ζδειξε ςτο πρόςωπό μου με τθν ανάκεςθ τθσ εκπόνθςθσ τθσ παροφςασ διπλωματικισ εργαςίασ, αλλά και για τθν άριςτθ ςυνεργαςία και επικοινωνία που είχαμε, δίνοντάσ μου τθν απαραίτθτθ ϊκθςθ που τόςο χρειαηόμουν αλλά και υποςτιριξθ ςε ανκρϊπινο επίπεδο. Οι γνϊςεισ που μου μεταλαμπάδευςε τόςο ςτο πλαίςιο αυτισ τθσ εργαςίασ, όςο και από τθν παρακολοφκθςθ προπτυχιακϊν μακθμάτων του, είμαι ςίγουροσ ότι κα αποτελζςουν εφόδιο για τθν μελλοντικι επιτυχθμζνθ μου πορεία ςαν μθχανικόσ. Επίςθσ, κζλω να εκφράςω τισ ειλικρινείσ μου ευχαριςτίεσ ςτον Διδάκτωρ (Dr.) του τμιματοσ Ηλεκτρολόγων Μθχανικϊν και τεχνολογίασ Η/Υ, κφριο Ιωάννθ Γιαλελι, για τισ καίριεσ ςυμβουλζσ του και για το ενδιαφζρον που ζδειξε κακ όλθ τθ διάρκεια τθσ εργαςίασ. Οι επικοδομθτικζσ παρατθριςεισ και τοποκετιςεισ του, κακϊσ και θ ςυνεχισ κακοδιγθςθ που προζβαλε προσ το άτομό μου, αποτζλεςαν καταλυτικό παράγοντα για τθν επίτευξθ του τελικοφ ςτόχου. Στθν εξίςωςθ κα ςυμπεριλάβω τουσ μεταπτυχιακοφσ, Δθμιτριο Τςιτςιπι και Χριςτο Ραναγιϊτου, τουσ οποίουσ και ευχαριςτϊ για τθν πολφτιμθ βοικειά τουσ ςε δυςκολίεσ ςχετικζσ με το αντικείμενο τθσ διπλωματικισ, όποτε αυτζσ προζκυπταν. Τζλοσ, κα ικελα να εκφράςω τθν ευγνωμοςφνθ μου ςτουσ γονείσ μου και ςτον αδερφό μου, που όλα αυτά τα χρόνια μου ςυμπαραςτζκονται θκικά και οικονομικά και διαμορφϊνουν γφρω μου ζνα άνετο περιβάλλον, μζςα ςτο οποίο μπορϊ να εργαςτϊ και να επεκτείνω τισ γνϊςεισ μου. Δεν κα μποροφςα να μθν αναφζρω ςε αυτό το ςθμείο, τισ ευχαριςτίεσ μου ςε όλουσ τουσ πραγματικοφσ μου φίλουσ, ςυμφοιτθτζσ και μθ, που ιταν δίπλα μου όποτε τουσ χρειάςτθκα, για τθν ςυμπαράςταςι τουσ και τθν πολφτιμθ βοικειά τουσ κυρίωσ ςτον ψυχολογικό τομζα, και όχι μόνο, δίνοντάσ μου τθ δυνατότθτα πλιρουσ αφοςοίωςθσ ςτο ςτόχο. 6

7 ΠΕΡΙΛΗΨΗ Τα τελευταια χρόνια ειμαςτε μαρτυρεσ ενόσ εντυπωςιακοφ παραδόξου ςτο χϊρο τθσ τεχνολογίασ. Ενϊ όλθ θ ανκρωπότθτα αναηθτά το κάτι παραπάνω ςε υπολογιςτικι ιςχφ, ςε χϊρο αποκικευςθσ και ςε ταχφτθτα, μικρζσ αυτόνομεσ ςυςκευζσ ζρχονται να κατακτιςουν όλο και περιςςότερουσ τομείσ τθσ κακθμερινότθτάσ μασ. Μονάδεσ με τθν ικανότθτα τθσ επεξεργαςίασ και τθσ αποκικευςθσ δεδομζνων, τθσ αίςκθςθσ του περιβάλλοντοσ αλλά και τθσ επικοινωνίασ μεταξφ τουσ, ενςωματϊνονται ςχεδόν ςε όλουσ τουσ τομείσ δραςτθριοποίθςθσ του ανκρϊπου. Ο τρόποσ αυτό-οργάνωςθσ αυτϊν των κόμβων - μονάδων ςτα πλαίςια μεγάλων αςφρματων δικτφων αιςκθτιρων, και θ ςυλλογι δεδομζνων από μια ευρεία περιοχι, τουσ δίνει τθ δυνατότθτα λιψθσ αποφάςεων, πολλζσ φορζσ κρίςιμων, ανάλογα με τισ επικρατοφμενεσ ςυνκικεσ. Τα παραπάνω χαρακτθριςτικά των δομικϊν ςτοιχείων των αςυρμάτων δικτφων αιςκθτιρων, ςε ςυνδυαςμό με τισ υπθρεςίεσ τθσ υψθλισ και κακιερωμζνθσ τεχνολογίασ του ςυςτιματοσ GPS (Global Positioning System) μποροφν να δθμιουργιςουν ζναν εκρθκτικό ςυνδυαςμό και ερευνθτικζσ ιδζεσ για ανάπτυξθ αςτικϊν εφαρμογϊν αυτοματιςμοφ, ςτο πλαίςιο των λεγόμενων «ζξυπνων πόλεων». Μζςα ςε ζνα απζραντο δίκτυο αςυρμάτων αιςκθτιρων, αποτελοφμενο από χιλιάδεσ οντότθτεσ, θ ικανότθτα του κάκε κόμβου να εντοπίηει τθν κζςθ του και να τθν μοιράηεται με τουσ υπόλοιπουσ, κερδίηει ολοζνα και περιςςότερο ζδαφοσ ειδικά ςε κζματα δρομολόγθςθσ. Η χριςθ τθσ τεχνολογίασ GPS από ζναν κόμβο, αντικείμενο που μελετάμε ςτθ παροφςα εργαςία, μπορεί να οδθγιςει από τθν επιτυχι εφαρμογι του Geographical Routing ςε ζνα WSN, μζχρι τθν υλοποίθςθ απαιτθτικϊν εφαρμογϊν για αντιγραφι κίνθςθσ αλλά και δθμιουργίασ «ζξυπνων αυτοκινθτόδρομων» μζςα ςτουσ οποίουσ κα γίνεται αυτόματθ πλοιγθςθ των κινθτϊν υπό τθν επίβλεψθ ενόσ μεγάλου WSN με κόμβουσ που ςυνεργάηονται με το ςφςτθμα δορυφορικοφ εντοπιςμοφ κζςθσ αλλά και μεταξφ τουσ. Ππωσ γίνεται άμεςα αντιλθπτό, θ παροφςα εργαςία, που πραγματεφεται τθν ςωςτι ςυνεργαςία και επικοινωνία ενόσ δικτφου αςυρμάτων αιςκθτιρων με τθν τεχνολογία GPS για τθν ιχνθλάτθςθ τθσ πορείασ ενόσ κινθτοφ, μπορεί να δϊςει μελλοντικι τροφι για εναςχόλθςθ ςε πολλαπλά ερευνθτικά επίπεδα. Η εργαςία μασ χωρίςτθκε ςε τρείσ κεματικζσ ενότθτεσ. Η πρϊτθ αφορά τον τομζα του WSN και του προγραμματιςμοφ των κόμβων, για επικοινωνία με τουσ δορυφόρουσ, με τον υπολογιςτι αλλά και μεταξφ τουσ, με τισ απαραίτθτεσ λειτουργικζσ εφαρμογζσ που κλθκικαμε να υλοποιιςουμε. Η δεφτερθ αναφζρεται ςτθν εργαςία μασ από τθν πλευρά του υπολογιςτι, που λειτουργεί ςαν ςυλλζκτθσ των δεδομζνων του δικτφου, και τθ ςφνδεςθ του ςυςτιματόσ μασ με τθν πρότυπθ εφαρμογι Google Earth TM για απεικόνιςθ ςε πραγματικό χρόνο τθσ τροχιάσ που ακολουκεί ζνα κινθτό. Η τρίτθ ενότθτα περιλαμβάνει εκτζλεςθ πειραμάτων χριςθσ του ςυςτιματοσ που ςχεδιάςαμε και παράκεςθ οπτικοποιθμζνων αποτελεςμάτων, για τθν εφκολθ εξαγωγι χριςιμων ςυμπεραςμάτων όςον αφορά ςτθ λειτουργικότθτά του. 7

8 ABSTRACT The last few years we witness a striking paradox in the field of technology. While all humanity is seeking for more computing power, more storage capabilities and more proccessing speed, small autonomous devices have appeared to occupy more and more areas of our lives in the daily routine. Units with the capabilities of data proccessing, data storage, enviromental sensing and communication with each other, are incorporated in almost all areas of human activity. The way in which these nodes are self-organized into large Wireless Sensor Networks and their ability to collect data from a wide area, enables them in taking decisions, critical ones sometimes, according to the prevailing conditions. The above characteristics of the components of wireless sensor networks, combined with the services of the established and standard technology of the GPS (Global Positioning System) can create ideas for research and development of urban applications of automation in the so-called smart cities. In a vast network of wireless sensors, consisting of thousands of entities, the ability of each node to detect its position and share it with others, is gaining more and more ground especially in routing topics. The use of GPS technology from a node, which is one of the subjects we study in this thesis, could lead from the successful implementation of the Geographical Routing, to the implementation of more demanding applications for motion replication but also to creating smart highways through which mobiles will execute an automatic navigation, supervised by a large WSN consisting of nodes cooperating with the satellite positioning system and with each other. As is readily apparent, the present thesis which is dealing with the good cooperation and communication of a wireless sensor network with the GPS technology in order to trace the path of a mobile, can provide room for future involvement in multiple levels of research. Our work was divided into three thematic sections. The first concerns the field of WSN and node programming so that they can be able to communicate with satellites, with the computer and with each other, by installing them with the necessary functional applications that we had to implement. The second section refers to our work on the computer side, which acts as a network data collector, and the link of our system with the standard Google Earth TM application to display the path of a mobile in real time. The third section includes conducting experiments using the system we designed. The results are visualised and listed for an easy extraction of usefull conclusions regarding the functionality of our system. 8

9 Ακρωνφμια WSN Wireless Sensor Network ADC Analog to Digital Converter DSP Digital Signal Processing FPGA Field Programmable Gate Array ASIC Application Specific Integrated Circuit ISM Industrial, Scientific and Medical radio band RF Radio Frequency RAM Random Access Memory PDA Personal Digital Assistant DSSS Direct Sequence Spread Spectrum FHSS Frequency Hopping Spread Spectrum MAC Medium Access Control CTS Clear To Send RTS Request To Send SHR Synchronization Header PHR Physical layer header MFR Most Forwarding progress within Radius NFP Nearest with Forwarding Progress GFG Greedy Face Greedy GPS Global Positioning System IF - Intermediate Frequency DLL - Delay Lock Loop PLL- Phase Lock Loop GPIO General Purpose Input Output RX Receiver TX Transmitter SPI Serial Peripheral Interface PLL Phase-Locked Loop IRQ Interrupt Request PA Power Amplifier PPF Poly-Phase Filter LNA Low Noise Amplifier CLKM Clock Main ACK Acknowledgement MMCX Micro Miniature Coaxial ISP In System Programming OS Operating System TCP Transmission Control Protocol UDP User Datagram Protocol AM Active Message TOS Tiny Operating System I2C Inter Integrated Circuit UTC Coordinate Universal Time GMT Greenwich Mean Time CR Carriage Return 9

10 LF Line Feed FIFO First In First Out API Application Programming Interface DCB Device Control Block XML extensible Markup Language GPX GPs exchange format GE TM Google Earth TM GUI Graphic User Interface DGPS Differential GPS 10

11 Ειςαγωγι Η ανάγκθ του ανκρϊπου για πλθροφορία ςτο πλαίςιο μιασ ςφγχρονθσ κοινωνίασ, τον κάνει να ζρχεται πιο ςυχνά ςε επαφι με τουσ υπολογιςτζσ και τθν τεχνολογία. Αν και οι δφο ζννοιεσ δεν είναι ταυτόςθμεσ, παρόλα αυτά τα τελευταία χρόνια θ εξζλιξθ τθσ τεχνολογίασ ζρχεται μζςω των υπολογιςτϊν. Ήχοσ, εικόνα, τθλεπικοινωνίεσ και αυτόματοσ ζλεγχοσ εγκαταλείπουν τθν αναλογικι τουσ υπόςταςθ και μεταβαίνουν ςτον ψθφιακό κόςμο. Στθν ψθφιακι κατάςταςθ θ επεξεργαςία τθσ πλθροφορίασ είναι πολφ πιο εφκολθ με χριςθ υπολογιςτϊν. Το βάροσ, πλζον, πζφτει ςτθ μεταφορά των πλθροφοριϊν και ςτθν αξιοποίθςθ των εν δυνάμει φυςικϊν μζςων διάδοςθσ (καλϊδια, οπτικζσ ίνεσ, ραδιοςυχνότθτεσ) με τον καλφτερο δυνατό τρόπο. Πλοι οι τομείσ τθσ κακθμερινότθτασ προςφζρουν αμζτρθτεσ πθγζσ άντλθςθσ πλθροφορίασ ςαν μζροσ τθσ παρατιρθςθσ ι πρόβλεψθσ τθσ ζκβαςθσ ενόσ φυςικοφ φαινομζνου (ι μιασ ςτοχαςτικισ διαδικαςίασ) και τθσ χειραγϊγθςθσ των παραγόντων που τθν επθρεάηουν. Η πρόκλθςθ που δθμιουργείται είναι ο ςχεδιαςμόσ και θ υλοποίθςθ ςυςτθμάτων ςυλλογισ μετάδοςθσ και επεξεργαςίασ πλθροφοριϊν. Τα τελευταία χρόνια ζχουμε γίνει μάρτυρεσ μιασ μεγάλθσ ςυηιτθςθσ ςχετικά με το ποιο κα είναι το επόμενο μεγάλο βιμα ςτο κόςμο τθσ πλθροφορικισ μετά τθ διάδοςθ του Διαδυκτίου και του παγκόςμιου δικτυακοφ χϊρου. Μια από τισ κατευκφνςεισ για τθν οποία γίνεται ςυχνά λόγοσ είναι θ ςφνδεςθ του ψθφιακοφ με τον φυςικό κόςμο. Αυτι θ κατεφκυνςθ ζχει δφο όψεισ: από τθ μια πλευρά, ο ψθφιακόσ κόςμοσ επικοινωνεί με το περιβάλλον του ανκρϊπου, γίνεται αόρατοσ, μζροσ τθσ κακθμερινότθτάσ του και αλλθλεπιδρά μαηί του παρατθρϊντασ τισ ενζργειζσ του και από τθν άλλθ, ο άνκρωποσ παρατθρεί τισ διεργαςίεσ και τθ δραςτθριότθτα του φυςικοφ κόςμου, μζςω του ψθφιακοφ κόςμου. Αυτζσ οι δφο διατυπϊςεισ καλφπτουν ζνα ευρφτατο φάςμα εφαρμογϊν. Χαρακτθριςτικά παραδείγματα για τθν πρϊτθ περίπτωςθ, δθλαδι για τθν επικοινωνία του ψθφιακοφ κόςμου με τον άνκρωπο, είναι τα ambient intelligence, pervasive computing, disappearing computer κ.α. το περιεχόμενο των οποίων δεν παραμζνει ςτακερό, αλλά και αυτό μεταβάλλεται παράλλθλα με τισ εξελίξεισ τθσ τεχνολογίασ, δίνοντασ κατά καιροφσ βάροσ ςε διάφορεσ πλευρζσ τθσ ανκρϊπινθσ δραςτθριότθτασ. Σχετικά με τθ δεφτερθ περίπτωςθ, δθλαδι τθσ παρατιρθςθσ του φυςικοφ κόςμου μζςω του ψθφιακοφ, ζρχεται μια ειδικι κατθγορία δικτφων για να γεφυρϊςει τθ φυςικι και τθν ψθφιακι κατάςταςθ, τα αςφρματα δίκτυα αιςκθτιρων (WSN) με τα οποία και κα αςχολθκοφμε ςτθν παροφςα εργαςία. Στθν υπθρεςία τθσ ςφγχρονθσ κοινωνίασ, τα WSN αποτελοφν μια αιχμι τθσ εξζλιξθσ τθσ τεχνολογίασ ϊντασ μια νζα κατθγορία δικτφων υπολογιςτικϊν μονάδων. Χαρακτθριςτικό τουσ είναι ότι αποτελοφνται από ανεξάρτθτεσ αυτόνομεσ μονάδεσ ςυλλογισ μετριςεων που τοποκετοφνται ςε μια γεωγραφικι ζκταςθ και μεταδίδουν τισ πλθροφορίεσ τουσ, μζςω αςυρμάτων ηεφξεων, ςε ζνα κεντρικό ςφςτθμα για επεξεργαςία. Τα αςφρματα δίκτυα αιςκθτιρων ζχουν ιδθ αρχίςει να χρθςιμοποιοφνται ςε μια ευρεία γκάμα εφαρμογϊν που ςυνικωσ περιλαμβάνουν 11

12 λειτουργίεσ όπωσ θ ανίχνευςθ ςυμβάντων (event driven) ι περιοδικζσ λιψεισ μετριςεων (time driven). Μερικά από τα βιομθχανικά και επιςτθμονικά πεδία ςτα οποία ενδείκνυται θ χριςθ των WSN είναι: Ρεριβαλλοντικόσ ζλεγχοσ και καταγραφι βιοποικιλότθτασ Οικιακοί αυτοματιςμοί Αγροκαλλιζργιεσ ακρίβειασ Φαρμακευτικι και υγειονομικι περίκαλψθ Τθλεματικι Βιομθχανικοί αυτοματιςμοί ομποτικι Αςφάλεια Η νζα τάςθ εφαρμογϊν απαιτεί ο κάκε κόμβοσ ενόσ WSN να μακαίνει τθ πλθροφορία για τθν κζςθ ςτθν οποία εναποτίκεται και να τθν μοιράηεται με τουσ υπόλοιπουσ κόμβουσ που ςυκροτοφν το δίκτυο ζτςι ϊςτε να ξζρει ο κάκε ζνασ ποιοι είναι και που βρίςκονται οι γειτονικοί του κόμβοι. Ριο εξειδικευμζνεσ και ςφγχρονεσ εφαρμογζσ ειςάγουν τθν ανάγκθ τθσ κίνθςθσ των οντοτιτων που αποτελοφν το WSN και ξεφεφγουν από το περιοριςμό τθσ παραμονισ ςε ςτακερό ςθμείο για τθ παρακολοφκθςθ ενόσ φυςικοφ φαινομζνου. Η εφρεςθ τθσ κζςθσ που ζχει κόμβοσ από τον ίδιον τον κόμβο αποτελεί τθν νζα πρόκλθςθ ςτα δίκτυα αςυρμάτων αιςκθτιρων και καλείται node localization. Στθν κατθγορία του node localization υπάγεται και θ εφαρμογι που πρόκειται να ςχεδιάςουμε και με βάςθ αυτι να προγραμματίςουμε το hardware ςτα επόμενα κεφάλαια. Ωσ node localization ορίηεται το πρόβλθμα του κακοριςμοφ τθσ γεωγραφικισ κζςθσ του κάκε κόμβου ςτο ςφςτθμα. Το localization είναι από τα ποιο κεμελιϊδθ και δφςκολα προβλιματα που πρζπει να λυκοφν ςε ζνα WSN. Ρρόκειται για μια ςυνάρτθςθ πολλϊν παραμζτρων και απαιτιςεων που το κακιςτά αρκετά πολφπλοκο. Στθ παροφςα εργαςία, θ εφαρμογι μασ εμπίπτει ςτθν κατθγορία time driven εφαρμογϊν και προορίηεται για καταγραφι τθσ τροχιάσ ενόσ κινθτοφ που φζρει πάνω του κόμβο ενόσ WSN. Ο κόμβοσ πρζπει περιοδικά να εντοπίηει τθ κζςθ του και να αποςτζλει τθ πλθροφορία ςε ζνα data sink όπου και κα γίνεται θ επεξεργαςία τθσ για να καταςτεί δυνατι θ απεικόνιςι τθσ ςε ζναν παγκόςμιο χάρτθ. Η εφαρμογι λοιπόν μποροφμε να ποφμε ότι ζχει δφο ςκοποφσ. Ο πρϊτοσ είναι θ ςυλλογι δεδομζνων για τον εντοπιςμό τθσ κζςθσ του κόμβου. Αυτό κα υλοποιθκεί με τθ χριςθ του ςυςτιματοσ GPS. To GPS είναι ζνα ςφςτθμα πλοιγθςθσ βαςιςμζνο ςε δορυφόρουσ, που αποτελείται από ζνα δίκτυο 24 δορυφόρων τοποκετθμζνων ςε τροχιά γφρω από τθ Γθ. Ο δεφτεροσ ςτόχοσ είναι θ μεταφορά των δεδομζνων ςε ζνα κεντρικό ςφςτθμα και απεικόνιςθ τθσ κζςθσ του κόμβου, ο οποίοσ ζχει επιςυναφτεί ςε ζνα κινθτό, τθν κάκε χρονικι ςτιγμι. Η απεικόνιςθ κα γίνεται μζςω τθσ εφαρμογισ Google Earth ΤΜ και για να γίνει αυτό με επιτυχία, τα δεδομζνα κα πρζπει να περνάνε από μια διαδικαςία επεξεργαςίασ για να υπάρχει ςυμβατότθτα. Από τα παραπάνω προκφπτει ότι θ ςχεδίαςθ ενόσ τζτοιου WSN ζχει ωσ βαςικό άξονα τθν περιοδικι λιψθ μετριςεων και τθν αποκικευςι τουσ ςε μια βάςθ δεδομζνων για τθν ιχνθλάτθςθ τθσ κίνθςθσ ενόσ κινθτοφ. Η κακυςτζρθςθ ςτθν αποςτολι των δεδομζνων δεν παίηει τόςο ςθμαντικό ρόλο επομζνωσ δεν χρειάηεται 12

13 να εφαρμόςουμε τεχνικζσ hard real time. Ζτςι μποροφμε να χρθςιμοποιιςουμε πρακτικζσ για τθν αφξθςθ του χρόνου ηωισ του δικτφου εισ βάροσ τθσ αμεςότθτασ. Η επιτυχία ςτθν προςπάκεια του node localization ανοίγει διάπλατα τισ πόρτεσ για άμεςθ εφαρμογι του Geographic routing. Το geographic routing (ονομάηεται επίςθσ georouting ι routing βαςιςμζνο ςτθ κζςθ) είναι ζνασ τρόποσ δρομολόγθςθσ που βαςίηεται ςε πλθροφορίεσ τθσ γεωγραφικισ κζςθσ. Ρροτείνεται, κυρίωσ, για εφαρμογι ςτα αςφρματα δίκτυα και ςτθρίηεται ςτθν ιδζα ότι θ πθγι ςτζλνει ζνα μινυμα προσ τθν γεωγραφικι κζςθ του αποδζκτθ αντί να χρθςιμοποιεί τθν δικτυακι του διεφκυνςθ. Το γεγονόσ αυτό αποτελεί μεγάλο πλεονζκτθμα αφοφ για τθν αποςτολι ενόσ πακζτου από τθν πθγι προσ ζναν απομακρυςμζνο κόμβο ςτα πλαίςια ενόσ δικτφου, δεν χρειάηεται να είναι γνωςτι θ τοπολογία του. 13

14 ΚΕΦΑΛΑΙΟ 1 ο ΑΤΡΜΑΣΑ ΔΙΚΣΤΑ ΑΙΘΗΣΗΡΩΝ 1.1 WSN ςθμαίνει Wireless Sensor Networks Ζνα αςφρματο δίκτυο αιςκθτιρων (WSN) αποτελείται από χωρικά διανεμθμζνουσ αυτόνομουσ αιςκθτιρεσ για τθν παρακολοφκθςθ φυςικϊν ι περιβαλλοντικϊν ςυνκθκϊν, όπωσ θ κερμοκραςία, θχοσ, δόνθςθ, πίεςθ, κίνθςθ ι ρφπανςθ. Μποροφμε να το περιγράψουμε ςαν μια ςυλλογι από κόμβουσ οργανωμζνθ ςε ζνα ςυνεταιριςτικό δίκτυο. Ο χαρακτθριςμόσ αυτόσ δεν είναι κακόλου τυχαίοσ αφοφ οι αιςκθτιρεσ ζχουν τθ δυνατότθτα να ςυνεργάηονται με κφριο ςτόχο το πζραςμα των δεδομζνων τουσ, μζςω του δικτφου, ςε μια κεντρικι τοποκεςία. Τα πιο ςφγχρονα δίκτυα είναι διπλισ κατεφκυνςθσ (bi - directional) επιτρζποντασ ζτςι τον ζλεγχο τθσ δραςτθριότθτασ των αιςκθτιρων. Η κάκε μονάδα του δικτφου δθλϊνεται ωσ κόμβοσ. Ζνα WSN είναι χτιςμζνο από κόμβουσ, από λίγουσ ζωσ πολλοφσ εκατοντάδεσ ι ακόμα και χιλιάδεσ, όπου κάκε κόμβοσ ςυνδζεται με ζναν (ι και μερικζσ φορζσ περιςςότερουσ) αιςκθτιρεσ. Κάκε τζτοιοσ κόμβοσ δικτφου αιςκθτιρων διακζτει μια ικανότθτα επεξεργαςίασ (ζνασ ι περιςςότεροι μικροελεγκτζσ, CPU ι DSP chips), μπορεί να περιζχουν πολλαπλοφσ τφπουσ μνιμθσ (προγράμματα, δεδομζνα και flash μνιμεσ), ζναν RF πομποδζκτθ με εςωτερικι κεραία ι ςφνδεςθ με μια εξωτερικι κεραία, ζνα θλεκτρικό κφκλωμα για τθν διαςφνδεςθ με τουσ αιςκθτιρεσ και μια πθγι ενζργειασ που ςυνικωσ είναι μια μπαταρία. Στθν πιο «πράςινθ» μορφι τουσ οι κόμβοι μποροφν να υποςτθρίξουν φωτοβολταϊκά κφτταρα και να εκμεταλεφονται ζτςι τθν θλιακι ενζργεια αποταμιεφοντασ ενζργεια. Με αυτόν τον τρόπο οι κόμβοι μποροφν να «αιςκάνονται» τα φυςικά φαινόμενα, να επεξεργάηονται τα πρωτογενι δεδομζνα και να μοιράηονται τθν επεξεργαςμζνθ πλθροφορία με τουσ γειτονικοφσ κόμβουσ. Το μζγεκοσ ενόσ αιςκθτιριου κόμβου ποικίλει από ζνα κουτί παπουτςιϊν μζχρι κόκουσ ςκόνθσ αγγίηοντασ τα όρια τθσ τεχνολογίασ. Πςον αφορά ςτο κόςτοσ είναι όμοια μεταβλθτό με το μζγεκοσ και κυμαίνεται από εκατοντάδεσ ευρϊ μζχρι μερικά cents ανάλογα με τθν πολυπλοκότθτα των μεμονομζνων κόμβων. Επίςθσ θ καταςκευι τουσ ςυνικωσ περιλαμβάνει και ζνα προςτατευτικό περίβλθμα για αντοχι και διατιρθςθ των λειτουργικϊν χαρακτθριςτικϊν τουσ ςε αντίξοεσ ςυνκικεσ. Σε ςυνδυαςμό τα τρία παραπάνω χαρακτθριςτικά των αιςκθτιριων κόμβων, δθλαδι μικρό μζγεκοσ, μικρό κόςτοσ και αντοχι κακιςτοφν τα αςφρματα δίκτυα αιςκθτιρων χρθςιμοποιιςιμα ακόμα και ςε περιπτϊςεισ όπου θ τοποκεςία είναι δφςκολα προςβάςιμθ από τον άνκρωπο, για παρατιρθςθ και ζλεγχο του φυςικοφ περιβάλλοντοσ αλλά και τθσ ανκρϊπινθσ υγείασ. Στθν επιςτιμθ των υπολογιςτϊν και των τθλεπικοινωνιϊν, αςφρματα δίκτυα αιςκθτιρων είναι μια ενεργι περιοχι ζρευνασ με πολλζσ θμερίδεσ και ςυνζδρια που διοργανϊνονται κάκε χρόνο. 14

15 Ανεξάρτθτα από τθν τοπολογία και τα πρωτόκολλα με τα οποία ζχει υλοποιθκεί ζνα WSN, ςτόχοσ του δικτφου είναι θ ροι δεδομζνων από τον κεντρικό αποδζκτθ προσ τουσ κόμβουσ και το αντίςτροφο. Από αυτιν τθν άποψθ, ζχουμε να κάνουμε με ζνα κεντρικοποιθμζνο ςφςτθμα με κατανεμθμζνουσ και ςυνεργαηόμενουσ κόμβουσ. Μποροφμε να ποφμε ότι τα WSN είναι μια ειδικι περίπτωςθ κατανεμθμζνου ςυςτιματοσ δικτφου, παρόμοιου με ςυςτιματα όπωσ τα ενςωματωμζνα (embedded), τα real time και τα ςυςτιματα βάςθσ με τθν διαφορά των περιοριςμζνων πόρων. 1.2 Χαρακτθριςτικά ενόσ WSN Τα WSN διακζτουν χαρακτθριςτικά που τα διαφοροποιοφν ςθμαντικά από ςυμβατικά αςφρματα δίκτυα (όπωσ για παράδειγμα WiFi). Τα πιο αξιοςθμείωτα από αυτά αναφζρονται παρακάτω: 1. Application Specific: Ζνα δίκτυο ςχεδιάηεται με βάςθ τισ απαιτιςεισ μιασ ςυγκεκριμζνθσ εφαρμογισ και δφςκολα μπορεί να χρθςιμοποιεικεί για κάποια άλλθ, αν δεν υποςτεί ςθμαντικζσ αλλαγζσ τόςο ςτον αλγόρικμοσ λειτουργίασ όςο και ςτθ δομι και το χρθςιμοποιοφμενο υλικό. Για παράδειγμα, για ζνα αςφρματο δίκτυο που οι αιςκθτιρεσ είναι τοποκετθμζνοι πάνω ςε ρομπότ που κινοφνται αλλθλεπιδρϊντασ μεταξφ τουσ, ακολουκείται διαφορετικι ςτρατθγικι ςε ςχζςθ με ζνα ςτατικό WSN όπου οι αιςκθτιρεσ είναι τοποκετθμζνοι ςε ςτακερό ςθμείο και λαμβάνουν μετριςεισ. 2. Κλίμακα μεγζκουσ: Ο αρικμόσ των κόμβων ςε μια περιοχι οι οποίοι ςυγκροτοφν ζνα WSN μπορεί να ποικίλει. Υπάρχουν αςφρματα δίκτυα που αποτελοφνται από 2-3 κόμβουσ κακϊσ και από εκατοντάδεσ κόμβουσ. Η αρχιτεκτονικι και τα πρωτόκολλα δικτφου πρζπει να είναι ςε κζςθ να διαχειριςτοφν τόςο τισ μικρζσ όςο και τισ μεγάλεσ χωρικζσ πυκνότθτεσ. 3. Self-Configurability και Fault-Tolerance: Ο αλγόρικμοσ λειτουργίασ πρζπει να είναι ικανόσ να ρυκμίςει τθν τοπολογία κατά τθν εγκατάςταςθ του δικτφου, αλλά και να μπορεί να διαχειριςτεί τισ μεταβολζσ που μπορεί να προκφψουν. Η απϊλεια κόμβων, είτε από εξάντλθςθ ενζργειασ είτε από καταςτροφι, ι θ είςοδοσ νζων κόμβων ςτο δίκτυο δεν πρζπει να διαταράςει τθ ςυνολικι λειτουργία του. Γενικά το ςφςτθμα επιβάλεται να καταγράφει τακτικά τθ κατάςταςι του και να διακζτει μεγάλο βακμό προςαρμοςτικότθτασ. 4. Χρόνοσ ηωισ: Στισ περιςςότερεσ περιπτϊςεισ WSN θ λειτουργία των κόμβων εξαρτάται από μια περιοριςμζνθ πθγι ενζργειασ (ςυνικωσ μπαταρίεσ). Η προςεκτικι διαχείρθςθ ενζργειασ από τον κάκε κόμβο παίηει βαςικό ρόλο ςτθν διατιρθςθ του δικτφου για μεγάλο χρονικό διάςτθμα. Ο χρόνοσ ηωισ είναι ζνα μζγεκοσ αντιςτρόφωσ ανάλογο τθσ ποιότθτασ λειτουργίασ (QoS). Αυτό γιατί, αν 15

16 αναλογιςτοφμε ότι, ξοδεφοντασ περιςςότερθ ενζργεια ζχουμε καλφτερθ απόδοςθ αλλά μικρότερο χρόνο ηωισ. Το είδοσ τθσ εκάςτοτε εφαρμογισ είναι ο ρυκμιςτικόσ παράγοντασ που επθρεάηει τθν εξιςορρόπθςθ αυτϊν των δφο. 5. Αυτονομία λειτουργίασ και προγραμματιςμόσ: Κάκε κόμβοσ ςτο πλαίςιο ενόσ WSN πρζπει να μπορεί να πάρει αποφάςεισ για τθν εξζλιξθ τθσ εφαρμογισ, χωρίσ τθν παρζμβαςθ χειριςτι, ςε περίπτωςθ ςθμαντικϊν μεταβολϊν των μετροφμενων μεγεκϊν (για παράδειγμα θ αφξθςθ τθσ ςυχνότθτασ δειγματολθψίασ). Σε περίπτωςθ αλλαγισ ςτρατθγικισ είναι απαραίτθτθ θ δυνατότθτα επαναπρογραμματιςμοφ του κόμβου. 6. Simplicity: Από τθ ςτιγμι που κάκε κόμβοσ διακζτει περιοριςμζνουσ πόρουσ, ςυνεπάγεται πωσ το λειτουργικό και ο αλγόρικμοσ λειτουργίασ δεν μποροφν να ζχουν ιδιζτερα υψθλό επίπεδο πολυπλοκότθτασ. 7. Quality of Service: Η ζννοια τθσ ποιότθτασ επικοινωνίασ μπορεί να διαφζρει πολφ απ ότι ςε ςυμβατικά δίκτυα, αφοφ ςε ζνα WSN πικανόν να μθν παίηει πρωταρχικό ρόλο θ ταχφτθτα και ο ρυκμόσ μετάδοςθσ δεδομζνων αλλά θ αξιόπιςτθ μετάδοςθ όλων των πακζτων χωρίσ να χρειάηεται να γίνει ςυνζχεια επανεκπομπι. 1.3 Κόμβοσ Σο δομικό ςτοιχείο ενόσ WSN Ζνα αςφρματο δίκτυο αιςκθτιρων όπωσ είδαμε δομείται από ςυςκευζσ χωρικά κατανεμθμζνεσ που αποτελοφν τουσ κόμβουσ του δικτφου και χρθςιμοποιοφν αιςκθτζσ (ολοκλθρωμζνα κυκλϊματα) για να παρατθροφν και να μετροφν ςυνεργατικά μεγάλθ ποικιλία δεδομζνων ανάλογα με τθ φφςθ τθσ εφαρμογισ και το ςκοπό τθσ υλοποίθςθσ. Οι κόμβοι αυτόι ςτθν διεκνθ βιβλιογραφία ςυναντϊνται με τθν ονομαςία nodes ι και motes. Ζνασ sensor node, επομζνωσ, είναι ζνασ κόμβοσ ςτα πλαίςια ενόσ αςυρμάτου δικτφου αιςκθτιρων που μπορεί να εκτελεί επεξεργαςία ζχοντασ υπολογιςτικι δυνατότθτα, να ςυγκεντρϊνει δεδομζνα από τουσ αιςκθτιρεσ και να επικοινωνεί με άλλουσ κόμβουσ που είναι ςυνδεδεμζνοι ςτο δίκτυο. Οι κόμβοι ενόσ αςφρματου δικτφου αιςκθτιρων ζχουν τα εξισ χαρακτθριςτικά: Είναι μικροί, αυτόνομοι, κινθτοί ι μθ, τυχαία κατανεμθμζνοι και ζχουν τθ δυνατότθτα να επικοινωνοφν μεταξφ τουσ ςε περιοχζσ που δεν υπάρχει εγκατεςτθμζνθ υποδομι με ςτόχο τθν ανταλλαγι πλθροφοριϊν. Μποροφν ςε ςφντομο χρονικό διάςτθμα να δθμιουργιςουν δίκτυο μεταξφ τουσ, να το λειτουργιςουν και να το ςυντθριςουν χωρίσ καμία (ι περιοριςμζνθ) ανκρϊπινθ παρζμβαςθ. Με αυτό τον τρόπο παρζχουν 16

17 ςτοιβαρι επικοινωνία καλφπτωντασ τισ ανάγκεσ μιασ μεγάλθσ ποικιλίασ εφαρμογϊν. Η τοπολογία του δικτφου που δθμιουργοφν ζχει ςτόχο τθν ςυλλογι και δρομολόγθςθ δεδομζνων ςε διάφορα ςθμεία του δικτφου που μπορεί να είναι είτε άλλοι κόμβοι του δικτφου είτε ζνασ ςτακμόσ βάςθσ. Ο ςτακμόσ βάςθσ μπορεί, με τθ ςειρά του, να επικοινωνζι με το internet ι δορυφορικά με ζναν task manager node για τθ δθμιουργία κάποιου βιομθχανικοφ βρόχου ελζγχου ι τθν επεξεργαςία αυτϊν των μετριςεων. Οι περιοριςμοί ςτο μζγεκοσ και ςτο κόςτοσ των motes ςυνεπάγονται αντίςτοιχουσ περιοριςμοφσ ςε πόρουσ όπωσ ενζργεια, μνιμθ, υπολογιςτικι ταχφτθτα και εφροσ ηϊνθσ. Τα motes είναι επίςθσ επιρρεπι ςε αποτυχίεσ και εφκολα καταρρζουν, ζχουν όμωσ τθν δυνατότθτα γριγορθσ ανάκαμψθσ. Κάκε κόμβοσ αίςκθςθσ (sensor node) ςε ζνα WSN είναι τυπικά εφοδιαςμζνοσ με ζναν μικροελεγκτι, ζναν πομποδζκτθ ι άλλθ ςυςκευι αςφρματθσ επικοινωνίασ, μια εξωτερικι μνιμθ, μια πθγι ενζργειασ και ζναν ι περιςςότερουσ αιςκθτζσ. Τα παραπάνω ςτοιχεία φαίνονται και ςχθματικά ςτθν ακόλουκθ εικόνα. Εικόνα: Συπικι αρχιτεκτονικι αςφρματου κόμβου Ελεγκτισ: Ο ελεγκτισ αποτελεί τον πυρινα του κόμβου, εκτελεί tasks, δζχεται δεδομζνα από τουσ αιςκθτιρεσ και τουσ άλλουσ κόμβουσ, επεξεργάηεται τα δεδομζνα, αποφαςίηει πότε και που κα τα ςτείλει, κακορίηει τθ ςυμπεριφορά των ενεργοποιθτϊν και ελζγχει τθν λειτουργικότθτα των άλλων ςτοιχείων - ςυςκευϊν του sensor node. Σθμαντικι παράμετροσ για τθν επιλογι κατάλλθλου ελεγκτι είναι θ κατανάλωςθ ενζργειασ και θ δυνατότθτα να απενεργοποιείται όταν δεν εκτελείται κάποια λειτουργία (sleep mode). Ραρόλο που ο πιο ςυνθκιςμζνοσ ελεγκτισ για χριςθ ςε τζτοιεσ περιπτϊςεισ είναι ζνασ μικροελεγκτισ υπάρχουν και άλλεσ επιλογζσ που μποροφν να χρθςιμοποιθκοφν εναλλακτικά όπωσ ζνασ γενικοφ ςκοποφ desktop μικροεπεξεργαςτισ, επεξεργαςτζσ ψθφιακοφ ςιματοσ (DSPs), FPGAs και ASICs. Ζνασ μικροελεγκτισ χρθςιμοποιείται ςυχνά ςε πολλά ενςωματωμζνα ςυςτιματα όπωσ κόμβουσ αιςκθτιρων λόγω του χαμθλοφ κόςτουσ του, τθν ευελιξία του ωσ προσ τθ ςφνδεςθ με άλλεσ ςυςκευζσ, τον εφκολο προγραμματιςμό του και τθ χαμθλι κατανάλωςθ ενζργειασ. Ζνασ γενικοφ ςκοποφ 17

18 μικροεπεξεργαςτισ χαρακτθρίηεται γενικά από υψθλότερθ κατανάλωςθ ενζργειασ ςε ςχζςθ με ζναν μικροελεγκτι και γι αυτό ςυχνά δεν κεωρείται θ κατάλλθλθ επιλογι για ζναν sensor node. Οι επεξεργαςτζσ ψθφιακοφ ςιματοσ μποροφν να επιλεγοφν για ευρυηωνικζσ εφαρμογζσ αςφρματθσ επικοινωνίασ, αλλά ςτα αςφρματα δίκτυα αιςκθτιρων θ αςφρματθ επικοινωνία είναι ςυχνά περιοριςμζνθ (απλοφςτερθ, ευκολότερθ διαδικαςία διαμόρφωςθσ και τα tasks για τθν επεξεργαςία ςιματοσ των πραγματικϊν δεδομζνων αίςκθςθσ είναι λιγότερο πολφπλοκα). Συνεπϊσ τα πλεονεκτιματα των DSPs δεν είναι ςυνικωσ μεγάλθσ ςθμαςίασ για τουσ κόμβουσ των αςφρματων δικτφων αιςκθτιρων. Τζλοσ τα FPGAs δίνουν τθ δυνατότθτα για εφκολο επαναπρογραμματιςμό και αναδιαμόρφωςθσ ανάλογα με τισ ανάγκεσ αλλά ςτθ πραγματικότθτα αυτό παίρνει πολφ περιςςότερο χρόνο και καταναλϊνει αρκετι ενζργεια ϊςτε θ χριςθ τουσ να μθν ςυνίςταται. Πομποδζκτθσ: Τα sensor nodes κάνουν ςυχνά χριςθ τθσ ηϊνθσ ISM που δίνει ελεφκερθ ραδιοφωνία, κατανομι του ραδιοφάςματοσ και παγκόςμια διακεςιμότθτα. Οι πικανζσ επιλογζσ των αςυρμάτων μζςων μετάδοςθσ είναι οι ραδιοςυχνότθτεσ (RF), οι οπτικζσ επικοινωνίεσ (laser) και οι υπζρυκρεσ. Η επιλογι των laser ζχει το πλεονζκτθμα των μικρότερων απαιτιςεων ςε ενζργεια αλλά χρειάηονται οπτικι επαφι πάνω ςε μια γραμμι για να επιτευχκεί θ επικοινωνία και παρουςιάηουν ευαιςκθςία ςτισ ατμοςφαιρικζσ ςυνκικεσ. Οι υπζρυκρεσ, όπωσ και τα laser, δεν χρειάηονται κεραία αλλά είναι περιοριςμζνο ωσ προσ τθν χωρθτικότθτα μετάδοςθσ. Η επικοινωνία που βαςίηεται ςτισ ραδιοςυχνότθτεσ αποτελεί το ςθμαντικότερο μζςω αςφρματθσ επικοινωνίασ και ταιριάηει ςτισ περιςςότερεσ εφαρμογζσ WSN. Τα αςφρματα δίκτυα αιςκθτϊν τείνουν να χρθςιμοποιοφν τισ license-free ςυχνότθτεσ επικοινωνίασ 173, 433, 868 και 915 ΜHz κακϊσ και τθν 2.4 GHz. Η λειτουργικότθτα τόςο του πομποφ όςο και του δζκτθ ςυνδυάηεται ςε μια ςυςκευι γνωςτι με το όνομα πομποδζκτθσ. Οι καταςτάςεισ λειτουργίασ τουσ είναι «Μετάδοςθ», «Λιψθ», «Αδράνεια» και «Sleep». Η τρζχουςα γενιά πομποδεκτϊν ζχει ενςωματωμζνεσ μθχανζσ κατάςταςθσ που εκτελοφν οριςμζνεσ λειτουργίεσ αυτόματα και αναλαμβάνουν και άλλεσ εργαςίεσ που αφοροφν το πρωτόκολλο επικοινωνίασ, κυρίωσ με βαςικό γνϊμονα τθν μείωςθ τθσ κατανάλωςθσ ενζργειασ, μειϊνοντασ το φόρτο εργαςίασ του ελεγκτι. Μια άλλθ παράμετροσ είναι πωσ οι περιςςότεροι πομποδζκτεσ που λειτουργοφν ςε κατάςταςθ αναμονισ ζχουν κατανάλωςθ ενζργειασ ςχεδόν ίςθ με τθν ενζργεια που καταναλϊνεται ςτθ λειτουργία λιψθσ. Ζτςι είναι προτιμότερο να γίνεται τερματιςμόσ τθσ λειτουργίασ του πομποδζκτθ από το να μείνει ςε κατάςταςθ αδράνειασ όταν δεν μεταδίδει ι δεν λαμβάνει. Σθμαντικό ποςό ενζργειασ καταναλϊνεται κατά τθ μετάβαςθ από τθ κατάςταςθ «sleep» ςτθ κατάςταςθ «Μετάδοςθσ» για τθν εκπομπι ενόσ πακζτου. Εξωτερικι μνιμθ: Από πλευράσ κατανάλωςθσ ενζργειασ, τα πιο ςχετικά είδθ μνιμθσ είναι θ on-chip μνιμθ του μικροελεγκτι και θ μνιμθ flash. Κάκε κόμβοσ μπορεί να διακζτει τριϊν ειδϊν μνιμεσ. Μια RAM που είναι θ μνιμθ χριςτθ και χρθςιμοποιείται για τθν αποκικευςθ των μετριςεων και των πακζτων που λαμβάνονται, μια flash που είναι θ μνιμθ προγράμματοσ και μια EEPROM για configuration. Οι μνιμεσ flash χρθςιμοποιοφνται κυρίωσ λόγω του κόςτουσ και τθσ αποκθκευτικισ τουσ ικανότθτασ. Οι απαιτιςεισ μνιμθσ ςε ζναν κόμβο εξαρτϊνται από τθν εφαρμογι. Δφο κατθγορίεσ μνιμθσ με βάςθ τουσ ςκοποφσ αποκικευςθσ 18

19 είναι θ μνιμθ χριςτθ, που χρθςιμοποιείται για αποκικευςθ προςωπικϊν δεδομζνων και δεδομζνων ςχετικϊν με τθν εφαρμογι, και θ μνιμθ προγράμματοσ που χρθςιμοποιείται για τον προγραμματιςμό τθσ ςυςκευισ. Η τελευταία επίςθσ μπορεί να περιζχει ςτοιχεία αναγνϊριςθσ τθσ ςυςκευισ, αν υπάρχουν. Η διάκεςθ των ολοκλθρωμζνων μνιμθσ ςτουσ κόμβουσ ποικίλει ανάλογα με τθν εταιρεία καταςκευισ τουσ. Πθγι ενζργειασ: Ζνα sensor node καταναλϊνει ενζργεια για να εκτελεί λειτουργίεσ όπωσ αίςκθςθ, επικοινωνία και επεξεργαςία δεδομζνων. Για να καταλάβουμε μια τάξθ μεγεκϊν, αρκεί να αναλογιςτοφμε ότι το ενεργειακό κόςτοσ για τθν μετάδοςθ 1Κbyte ςε απόςταςθ 100 μζτρων (330 πόδια) είναι περίπου το ίδιο με αυτό που χρειάηεται για τθν εκτζλεςθ 3 εκατομμυρίων εντολϊν από ζναν επεξεργαςτι με δυνατότθτα εκτζλεςθσ 100 εκατομμυρίων εντολϊν/sec. Η απαιτοφμενθ ενζργεια αποκθκεφεται είτε ςε μπαταρίεσ είτε ςε πυκνωτζσ. Οι μπαταρίεσ, επαναφορτιηόμενεσ και μθ, αποτελοφν τθ κφρια πθγι τροφοδοςίασ για τουσ κόμβουσ αιςκθτιρων. Είναι επίςθσ ταξινομθμζνεσ ανάλογα με το υλικό που χρθςιμοποιείται για τθν θλεκτροχθμικι των θλεκτροδίων, όπωσ NiCd (Νικελίου- Καδμίου), NiZn (Νικελίου-Ψευδαργφρου), NiMH (Νικελίου-υβριδίου μετάλλου) και ιόντων λικίου. Οι ςθμερινοί αιςκθτιρεσ είναι ικανοί να ανανεϊςουν τθν ενζργειά τουσ από θλιακζσ πθγζσ, από διαφορζσ ςτθ κερμοκραςία ι από κραδαςμοφσ. Υπάρχουν και χρθςιμοποιοφνται δφο πολιτικζσ εξοικονόμθςθσ ενζργειασ, το Dynamic Power Management (DPM) και το Dynamic Voltage Scaling (DVS). Με το DPM εξοικονομείται ενζργεια κλείνοντασ τμιματα του sensor node που δεν χρθςιμοποιοφνται εκείνθ τθ ςτιγμι ι δεν είναι ενεργά. Με το DVS μποροφμε να πετφχουμε μια διακφμανςθ ςτα επίπεδα ενζργειασ ςτο εςωτερικό του κόμβου ανάλογα με το μθ ντετερμινιςτικό φόρτο εργαςίασ. Με αυτό τον τρόπο μεταβάλλοντασ τθν τάςθ, μαηί με τθ ςυχνότθτα, είναι δυνατόν να επιτευχκεί τετραγωνικι μείωςθ τθσ κατανάλωςθσ ενζργειασ. Η κατανάλωςθ ενζργειασ ςτουσ κόμβουσ ζγκειται κυρίωσ ςτισ εξισ λειτουργίεσ: δειγματολθψία ςιματοσ και μετατροπι των φυςικϊν ςθμάτων ςε θλεκτρικά, θ μετατροπι του ςιματοσ από αναλογικό ςε ψθφιακό. Αιςκθτιρεσ και Ενεργοποιθτζσ: Ρρόκειται για hardware ςυςκευζσ που παράγουν μια μετριςιμθ απόκριςθ ςε μια αλλαγι μιασ φυςικισ κατάςταςθσ όπωσ θ κερμοκραςία ι θ πίεςθ. Οι αιςκθτιρεσ μετράνε φυςικά δεδομζνα από τισ παραμζτρουσ που παρακολουκοφνται. Το ςυνεχζσ αναλογικό ςιμα που παράγεται από τουσ αιςκθτζσ ψθφιοποιείται από analog-to-digital μετατροπζα (ADC) και ςτζλνεται ςτον ελεγκτι για περαιτζρω επεξεργαςία. Ζνασ κόμβοσ κα πρζπει να ζχει μικρό μζγεκοσ, να καταναλϊνει πολφ λίγθ ενζργεια, να είναι αυτόνομοσ και να λειτουργεί χωρίσ επίβλεψθ και να είναι προςαρμοςτικόσ ςτο περιβάλλον που τοποκετείται. Από τθ ςτιγμι που οι αςφρματοι κόμβοι αιςκθτιρων είναι πολφ μικρζσ θλεκτρονικζσ ςυςκευζσ μποροφν να εφοδιάηονται με πθγι περιοριςμζνθσ ιςχφοσ, τθσ τάξθσ των ampere-hour και volt. Οι αιςκθτιρεσ κατατάςςονται ςε τρείσ κατθγορίεσ: πακθτικοί παγκαντευκυντικοί, πακθτικοί αιςκθτιρεσ ςτενισ δζςμθσ και ενεργθτικοί αιςκθτιρεσ. Οι πακθτικοί αιςκθτιρεσ είναι αυτοί που βαςίηονται ςτθν ενζργεια που εκπζμπεται από άλλεσ πθγζσ (όπωσ ο ιλιοσ). «Αιςκάνονται» τα δεδομζνα χωρίσ ουςιαςτικά να επεμβαίνουν ςτο 19

20 περιβάλλον με ενεργι εξερεφνθςθ. Υπάρχει θ δυνατότθτα να είναι αυτοτροφοδοτοφμενοι από το ίδιο το περιβάλλον, με θλιακά κφτταρα για παράδειγμα, και θ ενζργεια που χρειάηονται είναι απαραίτθτθ μόνο για να ενιςχφςει το αναλογικό τουσ ςιμα. Οι ενεργθτικοί αιςκθτιρεσ εξερευνοφν ενεργά το περιβάλλον (όπωσ για παράδειγμα το ςόναρ ι το ραντάρ) και απαιτοφν ςυνεχϊσ ενζργεια από μια πθγι ιςχφοσ. Οι αιςκθτιρεσ χαρακτθρίηονται ςτενισ δζςμθσ όταν ζχουν μια ςαφϊσ οριςμζνθ ζννοια τθσ κατεφκυνςθσ τθσ μζτρθςθσ. Οι παγκατευκυντικοί αιςκθτιρεσ, αντίκετα, δεν ζχουν καμία ζννοια κατεφκυνςθσ που να εμπλζκεται ςτισ μετριςεισ που παίρνουν. Κάκε κόμβοσ αιςκθτιρασ ζχει μια ςυγκεκριμζνθ περιοχι κάλυψθσ για τθν οποία μπορεί με αξιοπιςτία και ακρίβεια να δϊςει αναφορά για το ςυγκεκριμζνο φυςικό μζγεκοσ που παρατθρεί. Η χωρικι πυκνότθτα των κόμβων αιςκθτιρων μπορεί να φτάςει τουσ 20 κόμβουσ ανά κυβικό μζτρο. Οι ενεργοποιθτζσ, αν και γενικά χωρίηονται και αυτοί ςε κατθγορίεσ, ςτα WSN ςυνικωσ εκτελοφν μια απλι εργαςία όπωσ το άνοιγμα κλείςιμο κάποιου διακόπτθ. 1.4 Δομι και Αρχιτεκτονικι δικτφου Μποροφμε να διακρίνουμε τισ ςυςκευζσ που αποτελοφν ζνα αςφρματο δίκτυο αιςκθτιρων ςε πθγζσ (sources) και ςε αποδζκτεσ (sinks). Ρθγι είναι κάκε οντότθτα του δικτφου που μπορεί να παρζχει πλθροφορίεσ, επομζνωσ κάκε κόμβοσ του δικτφου αποτελεί πθγι. Αποδζκτθσ κεωρείται κάκε οντότθτα που ηθτά πλθροφορίεσ. Υπάρχουν τρεισ περιπτϊςεισ αποδεκτϊν. Μπορεί να είναι ζνασ κόμβοσ ςαν όλουσ τουσ άλλουσ, μπορεί όμωσ να είναι μια οντότθτα που δεν ανικει ςτο δίκτυο αιςκθτιρων. Μια τζτοια περίπτωςθ είναι θ χριςθ ενόσ PDA ι ενόσ φορθτοφ υπολογιςτι ωσ αποδζκτθ, που κα αλλθλεπιδροφν με το δίκτυο όταν χρειάηονται πλθροφορία. Η Τρίτθ περίπτωςθ είναι ο αποδζκτθσ να παίηει το ρόλο ενόσ gateway προωκϊντασ τισ πλθροφορίεσ ςε ζνα μεγαλφτερο δίκτυο (για παράδειγμα Internet). Οι πθγζσ και οι αποδζκτεσ μποροφν να ςυνδυαςτοφν για το ςχθματιςμό τριϊν ειδϊν τοπολογίασ. Εικόνα: Δομι δικτφου WSN παράδειγμα 20

21 Star: Αποτελείται από ζνα κεντρικό αποδζκτθ και περιφερειακοφσ κόμβουσπθγζσ τοποκετθμζνουσ γφρω του. Οι περιφερειακοί κόμβοι επικοινωνοφν μόνο με τον αποδζκτθ και όχι μεταξφ τουσ. Peer to Peer (Mesh): Στθν τοπολογία mesh ζνασ κόμβοσ πθγι μπορεί να επικοινωνεί με οποιονδιποτε κόμβο-γείτονά του (router). Πλεσ οι οντότθτεσ μποροφν να επικοινωνιςουν μεταξφ τουσ ακόμα και αν δεν βρίςκονται εντόσ εμβζλειασ. Αυτό επιτυγχάνεται με multi-hop μθνφματα. Οι αποδζκτεσ εδϊ μπορεί να είναι περιςςότεροι από ζναν. Cluster-Tree (Hybrid): Η τοπολογία cluster-tree είναι μια ειδικι περίπτωςθ τθσ peer to peer. Υπάρχει και πάλι ζνασ κεντρικόσ αποδζκτθσ με τθν διαφορά ότι τϊρα το δίκτυο εξαπλϊνεται με τθ μορφι δζντρου. Εδϊ κόμβοι-πθγζσ είναι τα «κλαδιά» του δζντρου και παίηουν το ρόλο τοπικϊν ςυντονιςτϊν, ενϊ «φφλλα» (endpoints) είναι κόμβοι-πθγζσ που λειτουργοφν όπωσ ςτθ τοπολογία star. Ενϊ ςτθν peer to peer τοπολογία το δίκτυο είναι ομότιμο, ςτθν cluster-tree υπάρχει ςαφισ ιεράρχθςθ των κόμβων. Εικόνα: Μοντζλα τοπολογιϊν Πςον αφορά ςτθν αρχιτεκτονικι του δικτφου, ςε όλα τα WSN απαιτείται θ φπαρξθ, ζςτω και ςε απλι μορφι, ενόσ φυςικοφ, ενόσ MAC και ενόσ Link Layer επιπζδου πρωτοκόλλων, ενϊ κάποια πιο ςφνκετα απαιτοφν τθν υλοποίθςθ αλγορίκμων δρομολόγθςθσ. Στισ επόμενεσ ενότθτεσ παρατίκενται μερικά βαςικά ςτοιχεία ςχετικά με τθ ςτοίβα πρωτοκόλλων των WSN Φυςικό επίπεδο Το φυςικό επίπεδο αναλαμβάνει τθν διαμόρφωςθ και αποδιαμόρφωςθ του ψθφιακοφ ςιματοσ. Αυτι θ εργαςία εκτελείται από τον πομποδζκτθ για αυτό και 21

22 δεν πρζπει να είναι ιδιαίτερα περίπλοκθ ζτςι ϊςτε να μπορεί να υλοποιθκεί από hardware χαμθλοφ κόςτουσ και χαμθλισ κατανάλωςθσ, επιτυγχάνοντασ όςο το δυνατόν αξιόπιςτο αποτζλεςμα. Στισ περιςςότερεσ περιπτϊςεισ χρθςιμοποιοφνται τεχνικζσ εξάπλωςθσ φάςματοσ οι οποίεσ ονομάηονται ζτςι γιατί βαςικό ςτοιχείο τθσ λειτουργίασ τουσ είναι ότι οι εκπεμπόμενεσ κυματομορφζσ καταλαμβάνουν μεγαλφτερο bandwidth από αυτό που χρειάηονται για τθν μετάδοςθ των δεδομζνων. Οι πιο διαδεδομζνεσ τεχνικζσ εξάπλωςθσ φάςματοσ είναι θ Εξάπλωςθ Φάςματοσ Άμεςθσ Ακολουκίασ ι DSSS και θ Εξάπλωςθ Φάςματοσ με υνεχι Αλλαγι υχνότθτασ ι FHSS. Στθν DSSS, το ςιμα πριν τθν εκπομπι του πολλαπλαςιάηεται με μια ψευδοτυχαία ακολουκία bits ι chips όπωσ λζγονται. Το κάκε chip ζχει μικρότερθ διάρκεια από ζνα κομμάτι πραγματικισ πλθροφορίασ. Δθλαδι, κάκε κομμάτι πλθροφορίασ διαμορφϊνεται από μια ακολουκία πολφ γρθγορότερων chips. Ζτςι το ςιμα διευρφνεται χωρίσ όμωσ να χάςει τθν ςυνολικι του ενζργεια και το φάςμα του μοιάηει με αυτό του κορφβου. Χρθςιμοποιοφνται 11 ςυχνότθτεσ ςτθν Αμερικι και 13 ςτθν Ευρϊπθ, αλλά θ ςυχνότθτα επικοινωνίασ παραμζνει κάκε φορά ςτακερι και κάκε κανάλι καταλαμβάνει 22 MHz. Στο δζκτθ το λαμβανόμενο ςιμα πολλαπλαςιάηεται πάλι με τθν ίδια ψευδοτυχαία ακολουκία και ζτςι απομονϊνεται το αρχικό ςιμα. Στθν FHSS μζκοδο, θ ςυχνότθτα του φζροντοσ ςιματοσ μεταβάλλεται ςυνεχϊσ ςφμφωνα με μια ψευδοτυχαία ακολουκία. Σαν αποτζλεςμα, το ςιμα διευρφνεται ςε μία μεγάλθ περιοχι του φάςματοσ, ανάλογθ του αρικμοφ των διαφορετικϊν ςυχνοτιτων που χρθςιμοποιοφνται. Ο αρικμόσ των διακζςιμων ςυχνοτιτων μπορεί να διαφζρει από χϊρα ςε χϊρα, αλλά για τισ ΗΡΑ και τθν Ευρϊπθ ζχει κακοριςτεί ςτισ 79, και κάκε κανάλι καταλαμβάνει από 1 MHz. Αυτι θ ςυνεχόμενθ μετακίνθςθ τθσ ςυχνότθτασ του φζροντοσ ζχει ςαν αποτζλεςμα το ςιμα να είναι λιγότερο επιρρεπζσ ςε παρεμβολζσ, αφοφ παρεμβολι ςε μια ςυγκεκριμζνθ ςυχνότθτα κα επθρεάςει ζνα μικρό τμιμα των μεταδιδόμενων bits. Η γνϊςθ τθσ ψευδοτυχαίασ αυτισ ακολουκίασ επιτρζπει τθν αποδιαμόρφωςθ του ςιματοσ ςτο δζκτθ. Επειδι θ δθμιουργία τθσ ακολουκίασ των bits που μεταδίδει ζνασ πομποδζκτθσ βαςίηεται ςτθ χριςθ του εςωτερικοφ ταλαντωτι του, τισ περιςςότερεσ φορζσ, λόγω φπαρξθσ αποκλίςεων τθσ ονομαςτικισ ςυχνότθτασ των ταλαντωτϊν, δθμιουργείται ςφάλμα ςτον ςυγχρονιςμό πομποφ και δζκτθ (drift) και θ αποκωδικοποίθςθ των λθφκζντων bits αποτυγχάνει. Γι αυτό το λόγο ςε κάκε πακζτο που μεταδίδεται προςτίκεται μια επιπλζον δοκιμαςτικι ακολουκία (training sequence) που επιτρζπει ςτο δζκτθ να αναγνωρίςει τισ παραμζτρουσ μετάδοςθσ του πομποφ και να ςυγχρονιςτεί με βάςθ αυτζσ. Η ακολουκία αυτι τοποκετείται κυρίωσ ςτθν αρχι του πακζτου (preamble), αλλά υπάρχουν και περιπτϊςεισ όπου τοποκετείται ςτθ μζςθ (midamble) MAC επίπεδο Το επίπεδο MAC είναι υπεφκυνο για τον ςυγχρονιςμό δυο ι περιςςοτζρων ςυςκευϊν και για τον ζλεγχο τθσ πρόςβαςθσ ςτο κανάλι, ζτςι ϊςτε να 22

23 αποφεφγονται οι ςυγκροφςεισ κατά τθ μετάδοςθ (εδϊ όταν λζμε ςυγχρονιςμό αναφερόμαςτε ςτθ χρονικι ςτιγμι ςτθν οποία κα γίνει θ μετάδοςθ του πακζτου). Στα WSN υπάρχει μια πολφ βαςικι ιδιαιτερότθτα που πρζπει να λθφκεί υπόψιν ςτθ ςχεδίαςθ ενόσ MAC πρωτόκολλου και αυτι είναι θ περιοριςμζνθ ενζργεια των κόμβων. Η λιψθ και θ μετάδοςθ μθνυμάτων είναι εκ των πραγμάτων θ πιο απαιτθτικζσ ςε ενζργεια διαδικαςίεσ που καλείται να εκτελζςει ζνασ κόμβοσ. Αν υπάρχει και αιςκθτιρασ για GPS τότε θ λειτουργία του GPS module καταναλϊνει ακόμα πιο πολφ ενζργεια από το RF κφκλωμα. Στόχοσ λοιπόν του MAC επιπζδου είναι να ελαχιςτοποιιςει το χρόνο λειτουργίασ τζτοιων κυκλωμάτων επιτρζποντασ μια καλφτερθ διαχείριςθ ενζργειασ (power aware). Για τθν βαςικι λειτουργία τθσ επικοινωνίασ υπάρχουν τζςςερισ παράγοντεσ που προκαλοφν ςπατάλθ ενζργειασ. υγκροφςεισ: Πταν ςθμειϊνεται ςφγκρουςθ δυο πακζτων το επακόλουκο είναι θ αμοιβαία καταςτροφι τουσ. Ζτςι, θ ενζργεια που δαπανικθκε για τθν αποςτολι και λιψθ τουσ πάει χαμζνθ. Τα πακζτα πρζπει να ακολουκιςουν διαδικαςία επανεκπομπισ, πράγμα που ςθμαίνει περιςςότερθ κατανάλωςθ ενζργειασ. Overhearing: Πλα τα μθνφματα ςυνικωσ ζχουν μια πθγι και ζναν προοριςμό. Και λζμε ςυνικωσ επειδι υπάρχουν και κάποια που ςτζλνονται με ενεργι τθν παράμετρο broadcast επομζνωσ και κα λθφκοφν από όςουσ κόμβουσ αποδζκτεσ βρίςκονται μζςα ςτθν εμβζλεια του κόμβου αποςτολζα. Σε μια τζτοια περίπτωςθ, κα υπάρχουν κόμβοι που λαμβάνουν μθνφματα χωρίσ να τουσ αφοροφν. Ραρόλα αυτά το overhearing μπορεί να χρθςιμοποιθκεί και με ωφζλιμο τρόπο (για παράδειγμα ςε data-centric αλγόρικμουσ). Overhead πρωτοκόλλου: Το overhead ειςάγεται από πλαίςια ελζγχου, ςχετικά με το MAC, όπωσ τα CTS και RTS, κακϊσ και από κεφαλίδεσ (headers) ι επίμετρα (trailers) που προςτίκενται ςτα πακζτα. Idle listening: Ζνασ κόμβοσ που βρίςκεται ςε κατάςταςθ ετοιμότθτασ, περιμζνοντασ τθν εμφάνιςθ μθνφματοσ, ξοδεφει άςκοπα ενζργεια κατά τθ διάρκεια τθσ αναμονισ. Η ταυτόχρονθ αντιμετϊπιςθ όλων των παραπάνω παραγόντων είναι αδφνατθ. Τα περιςςότερα MAC πρωτόκολλα για WSN επικεντρϊνονται ςυνικωσ ςτθν ελαχιςτοποίθςθ των επιπτϊςεων ενόσ ι δφο παραγόντων. 1.5 Πρότυπο Το hardware και το πρωτόκολλο επικοινωνίασ που χρθςιμοποιικθκαν για αυτι τθν εργαςία και ςτα οποία κα αναφερκοφμε και ςτα επόμενα κεφάλαια, βαςίηονται κατά ζνα μεγάλο μζροσ ςτο πρότυπο Γι αυτό το λόγο, αλλά και επειδι αποτελεί βαςικι εξζλιξθ ςτο χϊρο των αςυρμάτων δικτφων αιςκθτιρων, αξίηει να αναφερκοφμε πιο αναλυτικά ςε αυτό. Η αρχι ζγινε το Δεκζμβριο του 2000 οπότε και ςχθματίςτθκε το Task Group 4, κάτω από το IEEE 802 working group 15, για να ξεκινιςει θ ανάπτυξθ του ςτάνταρ IEEE για LR-WPAN (low rate wireless personal area network). Ο 23

24 ςχεδιαςμόσ του προτφπου εςτιάηει κυρίωσ, ςτθ χαμθλι πολυπλοκότθτα, ςτθν ελαχιςτοποίθςθ τθσ κατανάλωςθσ ενζργειασ, ςτο χαμθλό κόςτοσ και ςτθν αξιόπιςτθ μετάδοςθ δεδομζνων για αςφρματθ ςφνδεςθ μεταξφ φτθνϊν, φορθτϊν, ακίνθτων ι κινθτϊν ςυςκευϊν τροφοδοτοφμενεσ από μπαταρίεσ ι κάποια άλλθ περιοριςμζνθ πθγι ενζργειασ. Το πρότυπο ορίηει τισ προδιαγραφζσ του φυςικοφ επιπζδου και του επιπζδου MAC, ενϊ οι ςυςκευζσ που το υποςτθρίηουν ςχεδιάηονται για να μποροφν να ςυνεργαςτοφν με άλλα πρότυπα όπωσ το ΙΕΕΕ b. Η πρόκεςθ του ΙΕΕΕ είναι να υποςτθρίηει εφαρμογζσ (βιομθχανικζσ, αγροτικζσ, οικιακζσ, ιατρικζσ κ.α.) ςτισ οποίεσ οι υπάρχουςεσ λφςεισ και τεχνολογίεσ, όπωσ το Bluetooth, δεν είναι απαραίτθτεσ. Το πρότυπο ςχεδιάςτθκε για χριςθ ςε μεγάλου εφρουσ ποικιλία εφαρμογϊν που απαιτοφν απλι αςφρματθ επικοινωνία, με περιοριςμζνθ ενζργεια και με ελαςτικι ανάγκθ διεκπεραιωτικισ ικανότθτασ. Η χριςθ του ςτα WSN επιτυγχάνει μείωςθ του κόςτουσ εγκατάςταςθσ ενόσ κόμβου και ταυτόχρονα δυνατότθτα υλοποίθςθσ δικτφων με μεγάλο πλικοσ κόμβων. Για να επιτευχκεί χαμθλι μζςθ κατανάλωςθ ιςχφοσ, το πρότυπο κεωρεί ότι το ποςό των δεδομζνων προσ μετάδοςθ είναι μικρό και ότι δεν μεταδίδεται ςυχνά ϊςτε να κρατιζται χαμθλά το duty cycle. Επιπλζον θ δομι του πλαιςίου ςχεδιάςτθκε ζτςι ϊςτε να προςκζτει τθν ελάχιςτθ πλθροφορία ελζγχου ςτο διακινοφμενο φορτίο. Οι ςυμβατζσ με το ΙΕΕΕ ςυςκευζσ μποροφν να λειτουργοφν ςε τρεισ ηϊνεσ ςυχνοτιτων που κακορίηονται από αυτό. Στθ ηϊνθ των MHz, με ζνα μόνο κανάλι και ρυκμοφσ μετάδοςθσ μζχρι 20 kbps, ςτθ ηϊνθ MHz, χωριηόμενθ ςε 10 κανάλια και ρυκμοφσ μετάδοςθσ μζχρι 40 kbps και τζλοσ ςτθ χωριηόμενθ ςε 16 κανάλια των 5 MHz ηϊνθ των 2.4 GHz όπου επιτυγχάνονται ρυκμοί μετάδοςθσ ζωσ και 250 kbps. Η ηϊνθ 868 είναι ελεφκερθ προσ χριςθ ςτθν Ευρϊπθ, θ 905 ςτθν Αμερικι, ενϊ θ 2.4 παγκοςμίωσ και είναι θ ηϊνθ που χρθςιμοποιείται για βιομθχανικζσ, επιςτθμονικζσ και ιατρικζσ εφαρμογζσ. Ραρόλο που ςτισ δυο τελευταίεσ ηϊνεσ είναι διακζςιμα περιςςότερα από ζνα κανάλια, το MAC πρωτόκολλο του προτφπου χρθςιμοποιεί ζνα τθ φορά. Το πρότυπο υποςτθρίηει αποτελεςματικά δφο δικτυακζσ τοπολογίεσ, τθν τοπολογία αςτζρα και τθν peer to peer τοπολογία. Στθν τοπολογία αςτζρα θ επικοινωνία γίνεται μεταξφ των ςυςκευϊν δικτφου και ενόσ κεντρικοφ ελεγκτι, του PAN ςυντονιςτι, ο οποίοσ είναι υπεφκυνοσ για τθ διαχείριςθ τθσ λειτουργικότθτασ όλου του αςτζρα. Η τοπολογία peer to peer επιτρζπει διάφορουσ ςφνκετουσ ςχθματιςμοφσ να υλοποιθκοφν, δθλαδι ad hoc και αυτό-οργανωμζνα δίκτυα. Επίςθσ υποςτθρίηεται και θ τοπολογία cluster tree. Ο μθχανιςμόσ δρομολόγθςθσ ςτα δίκτυα αυτά είναι μζροσ του επιπζδου δικτφου και ςυνεπϊσ δεν ζχει ςχζςθ με το ΙΕΕΕ Δομι δικτφου και είδθ κόμβων Στο πρότυπο ορίηονται δφο είδθ κόμβων όςον αφορά ςτο επίπεδο MAC. Full Function Device (FFD) Reduced Function Device (RFD) 24

25 Ζνασ FFD κόμβοσ μπορεί να λειτουργιςει με τρείσ τρόπουσ: Ωσ κεντρικόσ ςυντονιςτισ ενόσ δικτφου ΑΝ, ωσ τοπικόσ ςυντονιςτισ ςε οποιαδιποτε περιοχι του δικτφου και ωσ απλι ςυςκευι. Το δίκτυο ςχθματίηεται από FFD κόμβουσ οι οποίοι ζχουν δυνατότθτα να επικοινωνοφν με οποιονδιποτε κόμβο εντόσ τθσ εμβζλειασ τουσ, από RFD κόμβουσ οι οποίοι επικοινωνοφν μόνο με τον πλθςιζςτερο FFD κόμβο και από ζναν κεντρικό FFD κόμβο ςυντονιςτι που ςυνικωσ είναι ςυνδεδεμζνοσ με ζναν υπολογιςτι ι με κάποιο άλλο δίκτυο. Οι FFD κόμβοι αποτελοφν τον βαςικό κορμό του δικτφου, ενϊ οι RFD προορίηονται μόνο για απλζσ εργαςίεσ. Οι ςυςκευζσ μποροφν να χρθςιμοποιθκοφν για τον ςχθματιςμό και των τριϊν ειδϊν τοπολογίασ που αναφζρκθκαν ςε προθγοφμενεσ ενότθτεσ. Εικόνα: Σοπολογίεσ προτφπου Αρχιτεκτονικι Η αρχιτεκτονικι του ορίηεται μζςα από ζνα ςφνολο ξεχωριςτϊν επιπζδων, όπωσ και ςτο μοντζλο OSI. Κάκε επίπεδο είναι υπεφκυνο για ζνα τμιμα των λειτουργιϊν του προτφπου και παρζχει υπθρεςίεσ ςτα υψθλότερα επίπεδα. Ζτςι θ αρχιτεκτονικι μιασ ςυςκευισ αποτελείται από το φυςικό επίπεδο, το οποίο περιλαμβάνει τον RF πομποδζκτθ μαηί με κάποιουσ χαμθλοφ επιπζδου μθχανιςμοφσ ελζγχου και τον MAC επίπεδο, που παρζχει πρόςβαςθ ςτο φυςικό κανάλι για όλουσ τουσ τφπουσ μετάδοςθσ. Εικόνα: Αρχιτεκτονικι ςυςκευισ LR-WPAN 25

26 1.5.3 Φυςικό επίπεδο Το πρότυπο κακορίηει ωσ επιτρεπόμενθ τεχνικι μετάδοςθσ για το φυςικό επίπεδο, τθν τεχνικι DSSS (βλζπε παραπάνω), με δφο επιλογζσ διαμόρφωςθσ, BPSK ι O-QPSK [18]. Το χαρακτθριςτικό αυτό επιτρζπει τθ χριςθ ψθφιακϊν ολοκλθρωμζνων κυκλωμάτων χαμθλοφ κόςτουσ. Και οι δφο επιλογζσ κάνουν χριςθ τθσ ίδιασ βαςικισ δομισ πακζτου για λειτουργία με χαμθλό duty-cycle και με χαμθλι κατανάλωςθ ιςχφοσ. Η βαςικι διαφορά των δυο επιλογϊν είναι θ ηϊνθ ςυχνοτιτων και οι διαφορετικοί ρυκμοί μετάδοςθσ που παρζχουν, όπωσ φαίνεται και ςτθν παρακάτω εικόνα. Εικόνα: Οι δφο επιλογζσ ςτο Φυςικό επίπεδο του ΙΕΕΕ Το φυςικό επίπεδο αναλαμβάνει τθν εκτζλεςθ των ακόλουκων εργαςιϊν: Ανίχνευςθ Ενζργειασ ςτον Δζκτθ (Receiver Energy Detection, RED) Είναι μια εκτίμθςθ τθσ ιςχφοσ του λαμβανόμενου ςιματοσ εντόσ του εφρουσ του καναλιοφ, χωρίσ να γίνεται προςπάκεια αναγνϊριςθσ ι αποκωδικοποίθςισ του. Το αποτζλεςμα τθσ μζτρθςθσ αποκθκεφεται ςαν ζνασ ακζραιοσ 8-bit και χρθςιμοποιείται ςαν πλθροφορία και από άλλα επίπεδα του δικτφου. Ζνδειξθ Ποιότθτασ υνδζςμου (Link Quality Indicator, LQI) Μετά από τθν λιψθ ενόσ πακζτου, το φυςικό επίπεδο υπολογίηει μια εκτίμθςθ τθσ ποιότθτάσ του. Η εκτίμθςθ μπορεί να γίνει με τθ βοικεια τθσ τιμισ RED και αποκθκεφεται και αυτι ςαν ακζραιοσ 8-bit. Και αυτι θ πλθροφορία είναι διακζςιμθ ςτα ανϊτερα επίπεδα. Ζλεγχοσ Αδράνειασ Καναλιοφ (Clear Channel Assessment, CCA) Αυτι θ εργαςία μπορεί να επιτευχκεί με τρείσ τρόπουσ. Ο πρϊτοσ είναι με ζλεγχο τθσ τιμισ RED. Ριο ςυγκεκριμζνα, αν ζχει ξεπεραςτεί ζνα προκακοριςμζνο όριο, το κανάλι κεωρείται κατειλθμμζνο. Ο δεφτεροσ είναι με ανίχνευςθ φζροντοσ (Carrier Sense). Το κανάλι κεωρείται κατειλθμμζνο μόνο αν ανιχνευκεί ςιμα με διαμόρφωςθ που ορίηει το πρότυπο. Ο τρίτοσ τρόποσ αποτελεί ςυνδυαςμό των δφο προθγοφμενων. Επίςθσ, το φυςικό επίπεδο είναι υπεφκυνο για τον τελικό οριςμό τθσ ςυχνότθτασ του καναλιοφ και προφανϊσ για τθν αποςτολι και λιψθ των πακζτων από και προσ το φυςικό μζςο. 26

27 Δομι Πακζτων Φυςικοφ Επιπζδου Η δομι των πακζτων του φυςικοφ επιπζδου φαίνεται ςτθν ακόλουκθ εικόνα: Εικόνα: Δομι πακζτων φυςικοφ επιπζδου Η κεφαλίδα SHR αποτελείται από το preamble ςιμα (4 bytes), που χρθςιμεφει για τον ςυγχρονιςμό και από το SFD (1 byte), που κακορίηει το τζλοσ τθσ SHR και τθν αρχι του υπόλοιπου πακζτου. Η κεφαλίδα PHR είναι πάντα 8 bits και περιζχει πλθροφορίεσ ςχετικά με το μικοσ πλαιςίου. Τελευταίο ακολουκεί το τμιμα δεδομζνων του πακζτου φυςικοφ επιπζδου (PHY Payload), το οποίο περιλαμβάνει και το πλαίςιο του MAC επιπζδου και είναι μεταβλθτοφ μικουσ (2-127 bytes) MAC Επίπεδο Το MAC επίπεδο ελζγχει τθν πρόςβαςθ ςτο αςφρματο κανάλι κάνοντασ χριςθ ενόσ πρωτοκόλλου Πολλαπλισ Πρόςβαςθσ με Ανίχνευςθ Φζροντοσ και Αποφυγι υγκροφςεων ι CSMA-CA (Carrier Sense Multiple Access with Collision Avoidance), μζςω του οποίου επιλζγεται θ χρονικι ςτιγμι που κα εκπζμψει μια ςυςκευι ι κα τεκεί ςε αναμονι για τθ λιψθ ενόσ πακζτου. Αν τα παραπάνω επίπεδα διαπιςτϊςουν μια μείωςθ ςτθν ικανότθτα διεκπεραίωςθσ κάτω από ζνα κατϊφλι, το MAC επίπεδο κα πάρει εντολι να διεξάγει ζναν ζλεγχο εντοπιςμοφ ενζργειασ, με βάςθ τθν CCA διαδικαςία που επιτελεί το φυςικό επίπεδο, ςτα διακζςιμα κανάλια. Ανάλογα με τθν ενζργεια που εντοπίςτθκε, τα υψθλότερα επίπεδα κα επιλζξουν το κανάλι με τθ χαμθλότερθ ενζργεια. Το πρωτόκολλο είναι υπεφκυνο για τον ζλεγχο ροισ μζςω τθσ αναγνϊριςθσ πλαιςίων που ζχουν παραδοκεί επιτυχϊσ, τθν πιςτοποίθςθ πλαιςίων, τθν επίβλεψθ τθσ αςφάλειασ των ςυςκευϊν και για τθν διαμόρφωςθ του εγγυθμζνου time slot (χρονικϊν υποδοχϊν) μθχανιςμοφ. Επιπλζον, προβλζπει ςυγχρονιςμό με χριςθ beacon frames και των χρονικϊν υποδοχϊν (slotted CSMA), ζτςι ϊςτε μια ςυςκευι ςυντονιςτισ να μπορεί να επικοινωνιςει με πολλζσ απλζσ ςυςκευζσ αποφεφγοντασ ςε μεγάλο ποςοςτό τισ ςυγκροφςεισ, αλλά και τθν άςκοπθ κατανάλωςθ ενζργειασ αφοφ οι ςυςκευζσ απενεργοποιοφνται ςε επιλεγμζνεσ υποδοχζσ. Επίςθσ, παρζχει δφο υπθρεςίεσ ςτα ανϊτερα επίπεδα: τθν υπθρεςία δεδομζνων μζςω του common part sublayer (MCPS-SAP) και τθν υπθρεςία διαχείριςθσ μζςω του MAC layer management entity (MLME-SAP). 27

28 Το slotted CSMA CA είναι ιδανικό για τοπολογίεσ star όπου υπάρχει επικοινωνία ενόσ master με πολλοφσ slave κόμβουσ. Για ομότιμα δίκτυα όπου θ επικοινωνία γίνεται μεταξφ ςυςκευϊν router, καταλλθλότερθ είναι θ unslotted εκδοχι του πρωτοκόλλου. 28

29 ΚΕΦΑΛΑΙΟ 2 ο ΣΟ ΔΟΡΤΦΟΡΙΚΟ ΤΣΗΜΑ GPS 2.1 Node localization και Geographical Routing Στόχοσ τθσ παροφςασ εργαςίασ, είναι όπωσ ιδθ αναφζρκθκε, θ ιχνθλάτθςθ τθσ τροχιάσ που ακολουκεί ζνα κινθτό (ρομπότ, αυτοκίνθτο, άνκρωποσ κ.α.) με εφαρμογι του node localization. Η ανάγκθ του να μπορεί ο κάκε κόμβοσ ςτα πλαίςια ενόσ δικτφου να αναγνωρίηει τθ κζςθ του αρχίηει να γίνεται όλο και πιο επιτακτικι. Σφγχρονεσ εφαρμογζσ, απαιτοφν τθν ςυγκρότθςθ δικτφου με εκατοντάδεσ και ίςωσ χιλιάδεσ κόμβουσ. Αυτό ζχει ωσ άμεςθ ςυνζπεια θ γνϊςθ τθσ τοπολογίασ από τον κάκε κόμβο να είναι μια διαδικαςία χρονοβόρα και, ςε όρουσ WSN, αρκετά ςπάταλθ ςε κατανάλωςθ ενζργειασ και μνιμθσ από τουσ ιδθ περιοριςμζνουσ πόρουσ. Σε αρκετζσ περιπτϊςεισ επίςθσ, οι κόμβοι αυτοί χρειάηεται να είναι κινθτοί και όχι απλά να παρακολουκοφν τθν περιοχι ςτθν οποία τοποκετικθκαν. Τότε θ τοπολογία του δικτφου γίνεται αρκετά δυναμικι, αφοφ ςυνεχϊσ μεταβάλλεται. Επομζνωσ, θ γνϊςθ τθσ από ζναν κόμβο, που κζλει να ςτείλει ζνα μινυμα ςε ζναν άλλον κόμβο, είναι μια λειτουργία που κα επιβαρφνει πολφ το ςφςτθμα. Με το node localization ο κάκε κόμβοσ ζχει τισ προδιαγραφζσ ανά πάςα ςτιγμι να μπορεί να εντοπίςει τθ κζςθ του και να μοιραςτεί αυτι τθ πλθροφορία με τουσ υπόλοιπουσ κόμβουσ του δικτφου ζτςι ϊςτε να ξζρουν και αυτοί τθ κζςθ του. Με αυτόν τον τρόπο, αρχίηει να μπαίνει ςτο δίκτυο θ ζννοια του Geographic Routing (GR). Η δρομολόγθςθ με βάςθ τθν γεωγραφικι κζςθ, όπωσ υποδθλϊνει και το όνομα τθσ, δίνει άμεςθ λφςθ ςτο παραπάνω πρόβλθμα. Ρλζον ο κάκε κόμβοσ δε χρειάηεται να γνωρίηει τθν τοπολογία του δικτφου, θ οποία μπορεί να είναι ςφνκετθ και δυναμικι, και επιπλζον δεν υπάρχει θ ανάγκθ ανακάλυψθσ ενόσ μονοπατιοφ που να ςυνδζει τθν πθγι με τον αποδζκτθ. Το geographic routing για να υλοποιθκεί απαιτεί ο κάκε κόμβοσ του δικτφου να ζχει τθν ικανότθτα να εντοπίςει το που βρίςκεται και ότι ο κόμβοσ-πθγι γνωρίηει τθ κζςθ του κόμβουαποδζκτθ. Ζτςι, για τθν αποςτολι ενόσ πακζτου προσ ζναν κόμβο παραλιπτθ αρκεί θ πλθροφορία τθσ γεωγραφικισ του κζςθσ και όχι τθσ δικτυακισ του διεφκυνςθσ. Υπάρχουν διάφορεσ προςεγγίςεισ για το GR όπωσ θ single path, θ multi path και θ flooding based. Οι περιςςότερεσ εφαρμογζσ κάνουν χριςθ του single path, με δφο τεχνικζσ: το greedy forwarding και το face routing. Στθ πρϊτθ περίπτωςθ το μινυμα προωκείται με τζτοιο τρόπο ϊςτε να πθγαίνει, ςε κάκε βιμα, πιο κοντά ςτον κόμβο-ςτόχο χρθςιμοποιϊντασ μόνο πλθροφορίεσ κζςθσ. Ζτςι, ο κάκε κόμβοσ προωκεί το μινυμα ςτον γειτονικό του κόμβο που είναι ο πιο κατάλλθλοσ από τοπικι άποψθ. Ο πιο κατάλλθλοσ γειτονικόσ κόμβοσ, δθλαδι, μπορεί να είναι αυτόσ που ελαχιςτοποιεί τθν απόςταςθ από τον κόμβο-προοριςμό ςτο κάκε βιμα που πραγματοποιείται (greedy). Εναλλακτικά, μια άλλθ ζννοια προόδου είναι θ 29

30 προβλεπόμενθ απόςταςθ που ορίηει θ γραμμι θ οποία ενϊνει τθν πθγι με τον προοριςμό (MFR, NFP) ι θ ελάχιςτθ γωνία μεταξφ ενόσ γειτονικοφ κόμβου και του κόμβου προοριςμοφ (compass routing). Οι προαναφερκείςεσ ςτρατθγικζσ δρομολόγθςθσ δεν είναι όλεσ loop free. Για παράδειγμα, μπορεί να καταλιξει να εκτελεί κφκλουσ μεταξφ κόμβων με μια ςυγκεκριμζνθ επαναλαμβανόμενθ πορεία. Είναι γνωςτό ότι, από τισ παραπάνω, θ βαςικι greedy ςτρατθγικι κακϊσ και θ MFR είναι απαλλαγμζνεσ από αυτό το φαινόμενο, ςε αντίκεςθ με τισ ςτρατθγικζσ NFP και compass routing. Ραρόλο που θ greedy forwarding επιλογι είναι loop-free, εντοφτοισ μπορεί να οδθγιςει ςε αδιζξοδο, ςε μια κατάςταςθ, δθλαδι, όπου δεν υπάρχει γειτονικόσ κόμβοσ πιο κοντά ςτον κόμβο-προοριςμό. Σε μια τζτοια περίπτωςθ, το face routing βοθκάει τον κόμβο να ανακάμψει από αυτι τθ κατάςταςθ και να βρει ζνα μονοπάτι προσ ζναν άλλον κόμβο, ςτον οποίον μπορεί να επαναλθφκεί θ ςτρατθγικι greedy forwarding. Μια τζτοια ςτρατθγικι ανάκαμψθσ, όπωσ το face routing, είναι απαραίτθτθ για να παραδοκεί το μινυμα ςτον τελικό προοριςμό του με επιτυχία. Με το face routing κάνοντασ χριςθ ενόσ επίπεδου γράφου για μοντελοποίθςθ του δικτφου χωρίηει το επίπεδο ςε όψεισ (faces). Η νοθτι γραμμι που ενϊνει τον κόμβο-πθγι με τον κόμβο-παραλιπτθ τζμνει κάποια faces. Με τθ μζκοδο αυτι το πακζτο προωκείται κατά μικοσ των ορίων αυτϊν των faces. Οι προδιαγραφζσ του πρωτοκόλλου αυτοφ παρζχει ζνα ςφνολο κανόνων για κάκε κόμβο για να μπορεί να αποφαςίηει που να ςτείλει ζνα πακζτο χρθςιμοποιϊντασ μόνο τοπικζσ πλθροφορίεσ, ςχετικά με τουσ γείτονζσ του, και τισ πλθροφορίεσ από τον header του πακζτου. Ο ςυνδυαςμόσ των greedy forwarding και face routing προτάκθκε για πρϊτθ φορά το 1999 με το όνομα GFG (Greedy-Face-Greedy). Το GFG εγγυάται τθν παράδοςθ του μθνφματοσ ςε ζνα, όπωσ αποκαλείται, unit disk graph μοντζλο δικτφου. Μετζπειτα, προτάκθκαν διάφορεσ παραλλαγζσ και για non-unit disk graphs, που βαςίηονταν ςτισ αρχζσ του GFG. Στισ παρακάτω εικόνεσ δίνονται παραδείγματα των άνωκι ςτρατθγικϊν. Εικόνα α: Σενάπιο Greedy Forwarding. Ο κόμβορ-πηγή (S) έσει διάθοπερ επιλογέρ για να βπει έναν κόμβο αναμεηάδοζηρ για ηην πεπαιηέπω πποώθηζη ενόρ μηνύμαηορ ππορ ηο πποοπιζμό (D). Επιλογή κόμβος Α = Nearest with Forwarding Progress (NFP), επιλογή Β = Most Forwarding progress within Radius (MFR), επιλογή C = Compass Routing (δπομολόγηζη πςξίδαρ), επιλογή Ε = greedy. Εικόνα β: Face Routing.Ένα μήνςμα δπομολογείηαι καηά μήκορ ηος εζωηεπικού ηων κςηηάπων (faces) ηος γπάθος επικοινωνίαρ ηων οποίων οι πλεςπέρ (κόκκινο σπώμα) ηέμνοςν ηην νοηηή γπαμμή πος ενώνει ηον κόμβο-πηγή με ηον κόμβο-παπαλήπηη. Το ηελικό μονοπάηι δπομολόγηζηρ θαίνεηαι με μπλε. 30

31 Μιασ και, ςτθν εργαςία μασ αυτι, το κφριο κζμα δεν είναι αυτό τθσ δρομολόγθςθσ πακζτων, δεν χρειάηεται να επεκτακοφμε περιςςότερο όςον αφορά ςτο geographic routing. Με τα παραπάνω, γίνεται άμεςα αντιλθπτι θ ςθμαςία που ζχει το node localization ςε ζνα δίκτυο αςυρμάτων αιςκθτιρων. Το ηιτθμα αυτό ςυνικωσ δεν είναι απλό και εξαρτάται από πολλζσ παραμζτρουσ. Τζτοιοι παράμετροι είναι: το κόςτοσ του επιπλζον hardware για τον εντοπιςμό κζςθσ, θ φπαρξθ ι όχι κόμβων που γνωρίηουν εξ αρχισ τθ κζςθ τουσ, πόςοι είναι αυτοί και ποια θ ακρίβειά και θ εμβζλειά τουσ, είναι το ςφςτθμα εςωτερικό ι εξωτερικό, υπάρχει οπτικι επαφι μεταξφ των κόμβων, απαιτείται διςδιάςτατοσ ι τριςδιάςτατοσ εντοπιςμόσ κζςθσ, ποια είναι τα αποκζματα ενζργειασ, πόςο χρόνο χρειάηεται ο εντοπιςμόσ τθσ κζςθσ, είναι τα clocks ςυγχρονιςμζνα, το ςφςτθμα βρίςκεται ςε «φιλικό» ι ςε «εχκρικό» περιβάλλον. Για κάποιουσ ςυνδυαςμοφσ απαιτιςεων το πρόβλθμα μπορεί να είναι πιο εφκολο να λυκεί. Ζνασ τρόποσ υλοποίθςθσ του node localization είναι το walking GPS. Με τον όρο αυτό εννοοφμε τον εξοπλιςμό κάκε κόμβου του αςφρματου δικτφου με ζνα ολοκλθρωμζνο GPS receiver. Σε μια τζτοια περίπτωςθ υπάρχουν κάποιεσ παραδοχζσ που πρζπει να γίνουν και μασ περιορίηουν. Καταρχάσ, θ χριςθ του GPS ςυνεπάγεται ότι το ςφςτθμά μασ είναι εξωτερικό, μιασ και το GPS δεν μπορεί να λειτουργιςει ςε εςωτερικοφσ χϊρουσ. Επίςθσ, με το GPS κα πρζπει να κεωρείται αποδεκτι μια ακρίβεια τθσ τάξθσ των μερικϊν μζτρων και αυτό επειδι οι μετριςεισ που δίνει ζχουν μια απόκλιςθ ±11 μζτρων από τθν πραγματικι κζςθ. Αν αναφερόμαςτε ςε WSN που εξαπλϊνεται ςε μια ευρεία περιοχι, τότε θ εφαρμογι του walking GPS απαιτεί να μπαίνει ζνασ κόμβοσ τθ φορά ςτο δίκτυο. Μια τζτοια λφςθ, για τθν επίτευξθ του node localization, είναι κομψι και αποφεφγεται οποιαδιποτε χειροκίνθτθ διαμόρφωςθ τθσ κζςθσ του κάκε κόμβου. Στθ παροφςα εργαςίασ μασ, ςτα πλαίςια ενόσ απλοφ δικτφου αςφρματων αιςκθτιρων αποτελοφμενου από 2 κόμβουσ, κα ακολουκιςουμε τθ λογικι του walking GPS για να μπορεί ο κινοφμενοσ κόμβοσ να γνωρίηει τθ κζςθ του ανα πάςα χρονικι ςτιγμι και να μοιράηεται αυτι τθ πλθροφορία. Με αυτόν τον τρόπο, κα υλοποιθκεί θ καταγραφι τθσ τροχιάσ ενόσ κινθτοφ. Το κινθτό κα φζρει επιςθναμμζνο πάνω του ζναν κόμβο WSN που κα διακζτει αιςκθτιρα GPS. Με ζνα time-driven ςενάριο, ο κόμβοσ περιοδικά κα δζχεται το ςτίγμα του από το GPS module και κα το ςτζλνει ςε ζνα datasink (κόμβο βάςθσ). Από εκεί, οι μετριςεισπακζτα κα μεταφζρονται ςε ζνα ςτακμό επεξεργαςίασ (laptop) όπου και κα γίνεται, με περαιτζρω επεξεργαςία, θ απεικόνιςθ τθσ τροχιάσ που ακολουκεί το κινθτό ςε μια εφαρμογι παγκόςμιων χαρτϊν. Δεδομζνου ότι ςτθ ςυνζχεια κα χρθςιμοποιιςουμε το ςφςτθμα GPS ςτθν εργαςία μασ, ακολουκεί εκτενζςτερθ αναφορά για τισ αρχζσ λειτουργίασ του κακϊσ και ςτο πρωτόκολλο που εφαρμόηει. 2.2 GPS Global Positioning System 31

32 2.2.1 Γενικζσ πλθροφορίεσ για το ςφςτθμα Το NAVSTAR/G.P.S. (NAVigation Satellite Timing And Ranging Global Positioning System) ι απλά GPS είναι ζνα παγκόςμιο ςφςτθμα προςδιοριςμοφ κζςθσ (ςυντεταγμζνεσ), χρόνου και ταχφτθτασ, οπουδιποτε ςτθν επιφάνεια τθσ γθσ ι και κάτω από αυτιν, ςε οποιαδιποτε χρονικι ςτιγμι και ανεξάρτθτα από καιρικζσ ςυνκικεσ. Το ςφςτθμα ςχεδιάςτθκε ςτθ δεκαετία του 1970, αναπτφχκθκε ςτθ δεκαετία του 1980 και βρίςκεται ςυνεχϊσ υπό τον ζλεγχο του υπουργείου άμυνασ των ΗΡΑ (Department of Defense). Αρχικά ςχεδιάςτθκε για τθν κάλυψθ των αναγκϊν τθσ ναυςιπλοΐασ και για ςτρατιωτικοφσ ςκοποφσ, με ςτόχο τον προςδιοριςμό τθσ κζςθσ ενόσ αντικειμζνου ςε πραγματικό χρόνο με ακρίβεια ±10-15 μζτρα. Γριγορα ζγινε αντιλθπτι θ δυνατότθτα χριςθσ του ςυςτιματοσ και για τθν κάλυψθ πολιτικϊν αναγκϊν όπωσ οι εφαρμογζσ πλοιγθςθσ και διαχείριςθσ ςτόλου οχθμάτων. Το GPS ανικει ςτθν κατθγορία των ςυςτθμάτων GNSS (Global Navigation Satellite Systems), δθλαδι των παγκόςμιων δορυφορικϊν ςυςτθμάτων πλοιγθςθσ όπωσ είναι και το πολλά υποςχόμενο, κακαρά πολιτικό Ευρωπαϊκό ςφςτθμα GALILEO. Το GPS, εκτόσ από τισ εφαρμογζσ όπωσ ενθμζρωςθ χαρτϊν, εφαρμογζσ GIS, πλοιγθςθ, εντοπιςμόσ προεπιλεγμζνων κζςεων, χρθςιμοποιείται και ςε εφαρμογζσ υψθλισ ακρίβειασ όπου θ απαίτθςθ ςε ακρίβεια κυμαίνεται από μερικά χιλιοςτά του μζτρου ζωσ μερικά εκατοςτά, όπωσ είναι οι γεωδαιτικζσ και τοπογραφικζσ εφαρμογζσ. Τα κυριότερα πλεονεκτιματα του GPS ζναντι των άλλων παλαιότερων επίγειων και δορυφορικϊν μεκόδων είναι: 1. Δίνει απευκείασ τθ κζςθ ενόσ ςθμείου ςτθν επιφάνεια τθσ γθσ, ςυνεπϊσ μποροφμε να γνωρίηουμε κάκε ςτιγμι τθ κζςθ μασ ςε καρτεςιανζσ ςυντεταγμζνεσ Χ, Y, Z. 2. Είναι ζνα ςφςτθμα «παντόσ καιροφ», δθλαδι μπορεί να χρθςιμοποιθκεί κάτω από όλεσ τισ καιρικζσ ςυνκικεσ. 3. Για τον προςδιοριςμό κζςθσ δεν απαιτεί αμοιβαία ορατότθτα μεταξφ των ςθμείων τθσ παρατιρθςθσ. Απαιτείται μόνο ορατότθτα προσ ικανοποιθτικό αρικμό δορυφόρων (ανοιχτόσ ορίηοντασ ςτα ςθμεία ςτάςθσ). 4. Μπορεί να ςυνεργαςτεί με άλλα ςυςτιματα προςδιοριςμοφ κζςθσ (LORAN-C, Αδρανειακά ςυςτιματα, κ.α.) κακϊσ και με άλλεσ ςφγχρονεσ εφαρμογζσ και ςυςτιματα (GIS, Φωτογραμμετρία, κ.α.). 5. Η διαδικαςία των μετριςεων είναι αρκετά απλι και απαιτείται μικρόσ χρόνοσ μζτρθςθσ. Η λιψθ των μετριςεων είναι δυνατι όλο το 24ωρο. 6. Δίνει καλι ακρίβεια προςδιοριςμοφ κζςθσ με πολφ μικρότερο χρόνο μζτρθςθσ ςε ςχζςθ με άλλεσ μεκόδουσ. 32

33 Αντίκετα, τα μόνα μειονεκτιματα του GPS ζναντι άλλων μεκόδων εντοπιςμοφ κζςθσ είναι ότι: 1. Απαιτεί ανοιχτό ορίηοντα για να ζχει οπτικι επαφι με δορυφόρουσ γεγονόσ που κάνει δφςκολθ τθ χριςθ του μζςα ςε πόλεισ και πυκνοκατοικθμζνεσ περιοχζσ. 2. Η μείωςθ τθσ ακρίβειασ του ςυςτιματοσ και θ ειςαγωγι ςφαλμάτων από πλευρά των HΡΑ κατά χρονικά διαςτιματα λόγω του ςτρατιωτικοφ του χαρακτιρα δεν εγγυϊνται τθν απρόςκοπτθ λειτουργία του. Το παγκόςμιο ςφςτθμα εντοπιςμοφ κζςθσ αποτελείται ουςιαςτικά από «πομποφσ ςε τροχιά», που είναι οι δορυφόροι GPS, και από δζκτεσ GPS ςτθ γιινθ επιφάνεια. Ο δζκτθσ μπορεί να αναπτφςςεται όπωσ ζνα κλαςςικό τοπογραφικό όργανο ςε τρίποδα, να τοποκετείται ςε κινοφμενο όχθμα ι ακόμα απλά να κρατιζται ςτθν παλάμθ του χεριοφ και να λαμβάνει θλεκτρομαγνθτικά ςιματα που εκπζμπονται και λαμβάνονται από τουσ ορατοφσ ωσ προσ το δζκτθ δορυφόρουσ. Οι δζκτεσ αυτοί παρζχουν πλθροφορίεσ για τθ κζςθ ενόσ ςθμείου, το υψόμετρό του, τθν ταχφτθτά και τθν κατεφκυνςθ τθσ κίνθςισ του. Τα δορυφορικά ςιματα χρθςιμοποιοφνται για τθν εκτζλεςθ μετριςεων από το δζκτθ, που ιςοδυναμοφν ςε αποςτάςεισ μεταξφ δζκτθ και δορυφόρων ςε κάκε χρονικι ςτιγμι. Οι πλθροφορίεσ αυτζσ καταγράφονται ςτθ μνιμθ του δζκτθ και επεξεργάηονται εςωτερικά από το λογιςμικό του είτε ςε real time είτε εκ των υςτζρων παρζχοντασ τθ κζςθ (ςυντεταγμζνεσ) ι τθν ταχφτθτα και το χρόνο. Κατά τθ διάρκεια των μετριςεων ο δζκτθσ «διαβάηει» και ζνα μινυμα δεδομζνων πλοιγθςθσ που περιλαμβάνει απαραίτθτεσ πλθροφορίεσ για τον υπολογιςμό τθσ κζςθσ ςε πραγματικό χρόνο, όπωσ είναι τα ςτοιχεία τροχιάσ των δορυφόρων, από τα οποία υπολογίηονται οι ςυντεταγμζνεσ των δορυφόρων, οι παράμετροι διόρκωςθσ χρόνου και άλλα ςυςτθματικά ςφάλματα. Το δορυφορικό τμιμα ςιμερα αποτελείται από 30 δορυφόρουσ οι οποίοι ςταδιακά ςυμπλθρϊνονται και αντικακίςτανται αφοφ ζχουν οριςμζνθ διάρκεια ηωισ. Ο αρχικόσ ςχεδιαςμόσ του ςυςτιματοσ προζβλεπε 21 δορυφόρουσ, ενϊ από τα τζλθ του 1993 ο αρικμόσ τουσ είναι ςτακερά πάνω από 24. Οι δορυφόροι που ςυγκροτοφν το διαςτθμικό GPS είναι ςε τροχιά γφρω από τθ Γθ περίπου μίλια Εικόνα: Οπτικοποίθςθ του «αςτεριςμοφ» GPS 33

34 πάνω από τθν επιφάνειά τθσ. Είναι ςυνεχϊσ ςε κίνθςθ εκτελϊντασ δυο κανονικζσ τροχιζσ ςε λιγότερο από ζνα εικοςιτετράωρο (θ περίοδόσ τουσ είναι μιςι αςτρικι μζρα). Η τροφοδοςία τουσ γίνεται με θλιακι ενζργεια, ενϊ ζχουν και εφεδρικζσ μπαταρίεσ για τθν αντιμετϊπιςθ περιπτϊςεων θλιακισ ζκλειψθσ. Επίςθσ διακζτουν μικροφσ πυραυλοκίνθτουσ προωκθτζσ που τουσ «κρατάνε» ςτο ςωςτό μονοπάτι. Ο αρικμόσ των 24 δορυφόρων αποτελεί τον απαραίτθτο αρικμό για τθν πλιρθ λειτουργία του ςυςτιματοσ. Με αυτόν τον τρόπο μποροφν να παρατθροφνται ταυτόχρονα ζξι ζωσ οκτϊ δορυφόροι από οποιοδιποτε ςθμείο τθσ γιινθσ επιφάνειασ με καλό ορίηοντα. Ο δορυφορικόσ ςχθματιςμόσ ζχει τζτοια διάταξθ ϊςτε από κάκε ςθμείο τθσ γιινθσ επιφάνειασ να λαμβάνεται δορυφορικό ςιμα τουλάχιςτον από 4 δορυφόρουσ, κεωρϊντασ ότι δεν παρεμβάλλονται εμπόδια μεταξφ δζκτθ και δορυφόρων. Ο μζγιςτοσ αρικμόσ δορυφόρων που μπορεί να λαμβάνει ζνασ δζκτθσ ξεπερνά και τουσ 10 με πολφ καλό ορίηοντα (πάντα όμωσ μικρότεροσ των 12). Εικόνα: Σρόποσ μεταβολισ του αρικμοφ των δορυφόρων ςε κζαςθ από ζνα δοςμζνο ςθμείο ςτθν επιφάνεια τθσ Γθσ, κακϊσ αυτι περιςτρζφεται. Οι δορυφόροι είναι κατανεμθμζνοι ςε ζξι τροχιακά επίπεδα και κάκε ζνασ τουσ φζρει ωσ βαςικό εξοπλιςμό ταλαντωτζσ ι ατομικά χρονόμετρα, υπολογιςτζσ και κεραίεσ επικοινωνίασ. Μεταφζρει τρία ι τζςςερα ατομικά ρολόγια καιςίου ι και ρουβιδίου, εκ των οποίων το ζνα χρθςιμοποιείται για τθν παραγωγι μιασ κεμελιϊδουσ ςυχνότθτασ για το δορυφορικό ςιμα και τθ διατιρθςθ τθσ κλίμακασ του χρόνου (τα υπόλοιπα ωσ εφεδρικά). Οι δορυφόροι τείνουν να αποκλίνουν από τισ ςχεδιαςμζνεσ τροχιζσ τουσ και υπόκεινται κατά διαςτιματα ςε διορκϊςεισ από το ςφςτθμα ελζγχου Σο δορυφορικό ςιμα Το θλεκτρομαγνθτικό κφμα (θλεκτρομαγνθτικι ακτινοβολία) είναι θ ταυτόχρονθ διάδοςθ ενόσ θλεκτρικοφ και ενόσ μαγνθτικοφ πεδίου. Τα θλεκτρομαγνθτικά κφματα παράγονται από τθν επιταχυνόμενθ κίνθςθ θλεκτρικϊν φορτίων που ταλαντϊνονται. Για παράδειγμα, μια πθγι εναλλαςςόμενθσ τάςθσ, ςυνδεδεμζνθ ςε δυο μεταλλικοφσ αγωγοφσ αναγκάηει τα κετικά και αρνθτικά φορτία, που ςχθματίηονται ςτα άκρα των αγωγϊν, να μεταβάλλονται θμιτονοειδϊσ με το χρόνο και κατά ςυνζπεια οι δφο αγωγοί διαρρζονται από εναλλαςςόμενο θλεκτρικό ρεφμα (ταλαντευόμενο θλεκτρικό δίπολο, κεραία εκπομπισ θλεκτρομαγνθτικϊν κυμάτων). Με αυτόν τον τρόπο δθμιουργείται ςυνεχϊσ 34

35 θλεκτρικό και μαγνθτικό πεδίο τα οποία απομακρφνονται ςτο χϊρο με τθν ταχφτθτα του φωτόσ. Τα διανφςματά τουσ είναι κάκετα μεταξφ τουσ και κάκετα ςτθ διεφκυνςθ διάδοςθσ (εγκάρςιο κφμα). Τα θλεκτρομαγνθτικά κφματα χρθςιμοποιοφνται ςε πάρα πολλζσ εφαρμογζσ. Εξαιτίασ του γεγονότοσ ότι μποροφν να μεταφζρουν πλθροφορία ςε μεγάλεσ αποςτάςεισ, θ χριςθ τουσ ςτισ τθλεπικοινωνίεσ είναι ευρζωσ διαδεδομζνθ και μια από αυτζσ είναι και το GPS. Για τθν επίτευξθ τθσ επικοινωνίασ, όπωσ γνωρίηουμε, απαιτείται ζνασ πομπόσ και ζνασ δζκτθσ. Στον πομπό, θ πλθροφορία μετατρζπεται ςε θλεκτρικό ρεφμα το οποίο ςτθ ςυνζχεια προςτίκεται ςε μια υψίςυχνθ ςυχνότθτα (θλεκτρικό ρεφμα) που καλείται φζρουςα ςυχνότθτα ι φζρον κφμα. Το προκφπτον θλεκτρικό ρεφμα διαμορφωμζνο κφμα εκπζμπεται από τθν κεραία με τθ μορφι θλεκτρομαγνθτικοφ κφματοσ. Η διαδικαςία τθσ πρόςκεςθσ καλείται διαμόρφωςθ και γίνεται ακριβϊσ γιατί ζνα θμιτονοειδζσ ςιμα από μόνο του δεν είναι ικανό να μεταφζρει πλθροφορία. Ζτςι, μεταβάλλοντασ μια βαςικι του παράμετρο, δθλαδι το πλάτοσ ι τθ ςυχνότθτα, ι τθ φάςθ όπωσ ςυμβαίνει ςτθν περίπτωςθ παραγωγισ των δορυφορικϊν ςθμάτων GPS, τότε το διαμορφωμζνο ςιμα μεταφζρει μια πλθροφορία. Ζπειτα, ζνασ δζκτθσ, μζςω τθσ κεραίασ του, λαμβάνει το διαμορφωμζνο ςιμα και το επεξεργάηεται ϊςτε να αντλιςει τθν πλθροφορία που μεταφζρεται Διαμόρφωςθ δορυφορικοφ ςιματοσ GPS Το ατομικό ρολόι του κάκε δορυφόρου, εκτόσ από τθ διατιρθςθ τθσ κλίμακασ του χρόνου, παράγει μια κεμελιϊδθ ςυχνότθτα f 0 =10.23 ΜHz από τθν οποία προκφπτουν οι δφο βαςικζσ ςυμφαςικζσ φζρουςεσ ςυχνότθτεσ ι κφματα φορείσ (carrier waves). Η ςυχνότθτα L 1 = 154 με f 0 = 154 x 10.23MHz = MHz και μικοσ κφματοσ λ cm Η ςυχνότθτα L 2 = 120 με f 0 = 120 x 10.23MHz = MHz και μικοσ κφματοσ λ cm Ο προςδιοριςμόσ κζςθσ ςε real time απαιτεί τθ μζτρθςθ αποςτάςεων μεταξφ δεκτϊν και δορυφόρων. Επειδι οι μετριςεισ είναι μιασ κατεφκυνςθσ, δθλαδι τα ςιματα εκπζμπονται μόνο κατά τθ φορά «δορυφόροσ δζκτθσ», χρθςιμοποιοφνται δφο μετρθτικοί κϊδικεσ. Ο C/A (Coarse acquisition code) και ο P (Precision code) ι κρυπτογραφθμζνοσ P(Y), που δεν είναι παρά δυαδικζσ ακολουκίεσ από κάποιουσ αλγόρικμουσ. Οι κϊδικεσ αυτοί είναι κϊδικεσ ψευδοτυχαίου κορφβου (PNR codes, Pseudo Random Noise) και δεν μποροφν να μεταδοκοφν ςε μεγάλεσ αποςτάςεισ και για αυτό το λόγο προςτίκενται πάνω τουσ τα δφο ςιματα φορείσ τθσ δζςμθσ L, το L 1 (διαμόρφωςθ από C/A και P(Y)) και τθν L 2 (διαμόρφωςθ μόνο από P(Y)). Η διαμόρφωςθ είναι τζτοια ϊςτε να μπορεί να γίνεται θ μζτρθςθ του χρόνου διάδοςθσ, ι χρόνου ταξιδιοφ του ςιματοσ, από το δορυφόρο ςτο δζκτθ. Οι δφο φορείσ διαμορφϊνονται και από ζνα μινυμα πλοιγθςθσ, ι μινυμα δεδομζνων, για τθν παροχι πρόςκετων πλθροφοριϊν (ςτοιχεία τροχιάσ των δορυφόρων, παράμετροι για τον ςυγχρονιςμό των ρολογιϊν). Το μινυμα αυτό είναι μια δυαδικι ακολουκία που αντιςτοιχεί ςε γράμματα και αρικμοφσ-δεδομζνα, τα 35

36 οποία παράγονται με ςυχνότθτα 50 Hz ι ψθφιακό ρυκμό 50 bps, τακτοποιθμζνα ςε πλαίςια (frames) των 1500 bits. Από τα παραπάνω γίνεται κατανοθτό ότι ο δορυφόροσ εκπζμπει ζνα αρκετά ςφνκετο ςιμα, το οποίο με τον τρόπο που διαμορφϊνεται ζχει χαρακτθριςτικά διευρυμζνου φάςματοσ ςτο πεδίο των ςυχνοτιτων προςφζροντασ μεγάλθ ανκεκτικότθτα ςε παρεμβολζσ και ικανοποιθτικι αςφάλεια. Εικόνα: Οι βαςικζσ ςυνιςτϊςεσ του δορυφορικοφ ςιματοσ Οι κϊδικεσ PRN είναι ςιματα που χρθςιμοποιοφνται για τθν μζτρθςθ ψευδοαποςτάςεων. Είναι ςτθν πραγματικότθτα ακολουκίεσ δυαδικϊν αρικμϊν (0 και 1), οι οποίεσ παράγονται από ςυγκεκριμζνουσ μακθματικοφσ αλγόρικμουσ ςε ειδικζσ διατάξεισ που καλοφνται FBSR (feedback shift registers) και επαναλαμβάνονται φςτερα από κάποιο χρονικό διάςτθμα. Οι κϊδικεσ αυτοί είναι μοναδικοί για κάκε δορυφόρο και μποροφν να αναπαράγονται ακριβϊσ οι ίδιοι και ςτον δζκτθ ανεξάρτθτα από τθ παραγωγι τουσ ςτο δορυφόρο. Ο δζκτθσ ζχει τθν ικανότθτα να ςυγκρίνει τον λαμβανόμενο κϊδικα με τον κϊδικα που παράγει ο ίδιοσ. Ο χρόνοσ που απαιτείται για τθν ςφγκριςθ ταφτιςθ αντιςτοιχεί ςτο χρόνο ταξιδιοφ του ςιματοσ, ςυνεπϊσ και ςτθν ψευδοαπόςταςθ. Η ςυςχζτιςθ που γίνεται είναι μια «ψθφίο προσ ψθφίο» ςφγκριςθ για τμιματα του κϊδικα. Στο τζλοσ τθσ διαδικαςίασ μπορεί να ζχω υψθλι ςυςχζτιςθ (ταφτιςθ) ι χαμθλι (μθ ταφτιςθ). Το ηθτοφμενο, είναι να επιτευχκεί θ μεγαλφτερθ δυνατι ταφτιςθ. Οι πρωτογενείσ μετριςεισ ςτουσ κϊδικεσ PRN είναι μετριςεισ χρονικϊν διαςτθμάτων («χρόνοσ λιψθσ ςτο δζκτθ» - «χρόνοσ εκπομπισ ςτο δορυφόρο»), που ζπειτα πολλαπλαςιάηεται με τθν ταχφτθτα του φωτόσ και μετατρζπεται ςε ψευδοαπόςταςθ. Η ςυςχζτιςθ με τουσ κϊδικεσ επιτρζπει, εν ςυνεχεία, και τθν απομάκρυνςι τουσ από το δορυφορικό ςιμα (πολλαπλαςιαςμό με το αντίγραφο), το διάβαςμα του μθνφματοσ δεδομζνων, τθν μετζπειτα απομάκρυνςθ των δεδομζνων και τθν περαιτζρω επεξεργαςία του κακαροφ φορζα που απομζνει για τθν μζτρθςθ των φάςεων. Ο κϊδικασ P προςφζρεται για μετριςεισ ψευδοαπόςταςθσ με ακρίβεια 10 φορζσ μεγαλφτερθ ςε ςχζςθ με τον κϊδικα C/A. Ο τελευταίοσ είναι ςε ελεφκερθ χριςθ, ςε αντίκεςθ με τον που είναι διακζςιμοσ μόνο ςε εξουςιοδοτθμζνουσ χριςτεσ. 36

37 2.2.4 Δζκτεσ GPS Από τθν πλευρά του χριςτθ, για τον εντοπιςμό τθσ κζςθσ απαιτείται μια ςυςκευι πολφ υψθλισ τεχνολογίασ θ οποία και μπορεί να λαμβάνει τα θλεκτρομαγνθτικά ςιματα που εκπζμπουν οι δορυφόροι και να κάνει υπολογιςμοφσ για τθν εφρεςθ των ςυντεταγμζνων. Αυτζσ οι ςυςκευζσ καλοφνται δζκτεσ GPS (GPS receivers). Ζνασ δζκτθσ χωρίηεται ςε δφο βαςικά μζρθ: τθν κεραία και τον κυρίωσ δζκτθ. Η κεραία ςυνικωσ περιλαμβάνει και τον προ-ενιςχυτι του ςιματοσ και μπορεί να είναι εξωτερικι, ςαν μια ανεξάρτθτθ μονάδα ςυνδεδεμζνθ με τον κυρίωσ δζκτθ μζςω ενόσ καλωδίου, ι εςωτερικι ϊςτε όλο το ςφςτθμα δζκτθσ κεραία να είναι μια ςυμπαγισ ςυςκευι. Ο κυρίωσ δζκτθσ αποτελείται από διάφορα επιμζρουσ τμιματα: το τμιμα των ραδιοςυχνοτιτων, τουσ διαφλουσ (κανάλια) παρακολοφκθςθσ του δορυφορικοφ ςιματοσ με τουσ βρόχουσ παρακολοφκθςθσ, ζναν μικροεπεξεργαςτι και τθ μονάδα επικοινωνίασδιαςφνδεςθσ με τον χριςτθ. Η κεραία λαμβάνει το αρκετά εξαςκενθμζνο δορυφορικό ςιμα από όλουσ τουσ «ορατοφσ» δορυφόρουσ, το ενιςχφει με τον προ-ενιςχυτι και το διοχετεφει εςωτερικά ςτο δζκτθ για επεξεργαςία. Μετατρζπει ςτθν ουςία τθν ενζργεια των θλεκτρομαγνθτικϊν κυμάτων ςε θλεκτρικό ρεφμα, δθλαδι ςυντελείται μια μετατροπι των δορυφορικϊν θλεκτρομαγνθτικϊν κυμάτων ςε θλεκτρικά ςιματα. Οι κεραίεσ είναι μικρϊν διαςτάςεων, μικροφ βάρουσ και ςυνικωσ πανκατευκυντικζσ για λιψθ ςθμάτων από όλεσ τισ διευκφνςεισ. Σχεδιάηονται ζτςι ϊςτε να μποροφν να λάβουν είτε το ςιμα ςτθν L 1 (δζκτεσ μιασ ςυχνότθτασ), είτε ςτθν L 1 και L 2 (δζκτεσ δφο ςυχνοτιτων). Για τθ ςωςτι λιψθ των δορυφορικϊν ςθμάτων, οι κεραίεσ δεν πρζπει να επιςκιάηονται από γειτονικά αντικείμενα, όπωσ μεγάλα κτιρια, δζντρα κ.α. Σε τζτοιεσ περιπτϊςεισ ςθμειϊνονται ςθμαντικά ςφάλματα ςτισ παρατθριςεισ γιατί δθμιουργοφνται πολλαπλζσ διαδρομζσ του ςιματοσ εξαιτίασ τθσ ανάκλαςισ του ςτισ γειτονικζσ επιφάνειεσ. Τα ανακλϊμενα ςιματα λειτουργοφν ωσ παράςιτα και ειςάγουν κάποιο ςφάλμα (ςφάλμα πολυανάκλαςθσ, multipath error). Η επίδραςθ αυτοφ του ςφάλματοσ είναι ακόμα μεγαλφτερθ όταν θ εφαρμογι μασ είναι κινθματικι και όχι ςτατικι. Στον κυρίωσ δζκτθ, το πρϊτο τμιμα που αναλαμβάνει τθν επεξεργαςία του ειςερχόμενου δορυφορικοφ ςιματοσ, μετά τθν προενίςχυςθ, είναι το τμιμα των ραδιοςυχνοτιτων (RF section). Το τμιμα αυτό περιλαμβάνει διάφορεσ διατάξεισ όπωσ είναι οι ταλαντωτζσ ι ρολόγια τφπου χαλαηία για τθν παραγωγι των θμιτονοειδϊν ςθμάτων αναφοράσ, οι πολλαπλαςιαςτζσ για τθν δθμιουργία μεγαλφτερων ςυχνοτιτων, τα φίλτρα για τθν απομάκρυνςθ ανεπικφμθτων ςυχνοτιτων, οι μίκτεσ για τον πολλαπλαςιαςμό δυο διαφορετικϊν ςθμάτων και οι βρόγχοι παρακολοφκθςθσ και εξαγωγισ μετριςεων. Ο βαςικόσ λόγοσ φπαρξισ του είναι θ μετατροπι τθσ ςυχνότθτασ του ειςερχόμενου ςιματοσ ςε μικρότερθ ςυχνότθτα για να είναι εφκολα διαχειρίςιμο από το δζκτθ. Η διαδικαςία αυτι ολοκλθρϊνεται ςε βιματα και περιλαμβάνει, αρχικά, τθ ςυμβολι του ειςερχόμενου ςιματοσ με ζνα θμιτονοειδζσ ςιμα αναφοράσ που παράγεται από τον ταλαντωτι του δζκτθ. Από τθν ςυμβολι αυτι προκφπτει ζνα ςιμα για κάκε δορυφόρο με δυο ςυνιςτϊςεσ, που ζχουν ςυχνότθτα το άκροιςμα και τθ διαφορά των ςυμβαλλόμενων ςυχνοτιτων αντιςτοίχωσ. Με κατάλλθλα θλεκτρονικά φίλτρα 37

38 διατθρείται μόνο θ ςυνιςτϊςα τθσ διαφοράσ των ςυχνοτιτων, ι ιςοδφναμα τθσ διαφοράσ φάςεων, που ονομάηεται ενδιάμεςθ ςυχνότθτα (intermediate frequency, IF). Το IF ςιμα που παραμζνει, είναι και το παρατθροφμενο ςιμα ςτο δζκτθ. Στθ ςυνζχεια το ςιμα αυτό μεταβιβάηεται ςε όλουσ τουσ διαφλουσ-κανάλια. Ο αρικμόσ των καναλιϊν ςχετίηεται άμεςα με τον αρικμό των δορυφόρων που μπορεί να παρακολουκεί ταυτόχρονα ο δζκτθσ. Αν ο δζκτθσ διακζτει λιγότερα κανάλια από τον αρικμό των ορατϊν δορυφόρων, επιλζγει ποιουσ κα παρακολουκιςει με βάςθ κάποια κριτιρια ανάλογα με τθν εφαρμογι. Οι ςφγχρονοι δζκτεσ λαμβάνουν κεωρθτικά όλουσ ςχεδόν τουσ δορυφόρουσ πάνω από τον ορίηοντα (all in view). Σε κάκε δίαυλο, με τθ βοικεια των βρόγχων παρακολοφκθςθσ, γίνεται θ ανάκτθςθ των ςυνιςτωςϊν του ςιματοσ του κάκε δορυφόρου (αποδιαμόρφωςθ) και εξάγονται οι μετριςεισ μζςω τεχνικϊν ςυςχζτιςθσ του ειςερχόμενου ςιματοσ με ζνα ςιμα αντίγραφο που παράγει ο δζκτθσ. Οι βρόγχοι παρακολοφκθςθσ αναλαμβάνουν τθν εξαγωγι των μετριςεων. Διακρίνουμε τουσ βρόγχουσ προςδιοριςμοφ κακυςτζρθςθσ (Delay Lock Loop, DLL) όπου γίνονται οι ςυςχετίςεισ με τουσ κϊδικεσ και ςυνεπϊσ εξάγονται οι μετριςεισ των ψευδοαποςτάςεων, και τουσ βρόγχουσ προςδιοριςμοφ φάςθσ (Phase Lock Loop, PLL) όπου γίνονται οι μετριςεισ φάςεων. Κάποιοι δζκτεσ διακζτουν και βρόγχουσ μζτρθςθσ τθσ ςυχνότθτασ των φορζων (Frequency Lock Loop, FLL) είτε ωσ βοθκθτικοφσ, είτε αντί των PLL, οπότε μετροφν το ρυκμό μεταβολισ τθσ απόςταςθσ δορυφόρου-δζκτθ με ςκοπό τον υπολογιςμό ταχυτιτων ςε οχιματα που υπόκεινται ςε ζντονεσ επιταχφνςεισ (αεροπλάνα). Η ςειρά των ςυςχετίςεων ξεκινάει ςυνικωσ με τον κϊδικα C/A για τθ ςυνιςτϊςα L 1 ςτουσ βρόγχουσ DLL. Μόλισ επιτευχκεί θ ςυςχζτιςθ για τον κϊδικα το ςιμα εγκλωβίηεται και εξάγεται θ μζτρθςθ τθσ ψευδοαπόςταςθσ. Στθ ςυνζχεια, απομακρφνεται ο κϊδικασ (πολλαπλαςιαςμόσ με το αντίγραφό του) και το ςιμα που απομζνει οδθγείται ςτουσ βρόγχουσ PLL. Εκεί ζνα τοπικό αντίγραφο ςυςχετίηεται με το ειςερχόμενο ςιμα, διαβάηεται το μινυμα πλοιγθςθσ το οποίο αμζςωσ μετά απομακρφνεται και ο εναπομζνων κακαρόσ θμιτονοειδισ φορζασ IF χρθςιμοποιείται για τθ μζτρθςθ τθσ διαφοράσ φάςθσ μεταξφ αυτοφ και του αντίςτοιχου τοπικοφ αντιγράφου. Επειδι ο γνωςτόσ κϊδικασ C/A δεν μεταδίδεται με τθ ςυχνότθτα L2 παρά μόνο ο κϊδικασ ωσ κρυπτογραφθμζνοσ κϊδικασ Υ, για τθν ανάκτθςθ τθσ ςυνιςτϊςασ L2 χρθςιμοποιοφνται τεχνικζσ διαφορετικζσ όπωσ αυτι του τετραγωνιςμοφ για παράδειγμα. Ο μικροεπεξεργαςτισ του δζκτθ ελζγχει όλεσ τισ λειτουργίεσ του, από τον εγκλωβιςμό των δορυφόρων και τθν επεξεργαςία του ςιματοσ μζχρι τον υπολογιςμό τθσ κζςθσ ςε πραγματικό χρόνο. Εκτελείται κάκε φορά που ο δζκτθσ τίκεται ςε λειτουργία. Τζλοσ, το τμιμα του κυρίωσ δζκτθ διακζτει και μονάδεσ αποκικευςθσ, που είναι ςτθν ουςία μνιμεσ κάποιου τφπου Δορυφορικόσ προςδιοριςμόσ κζςθσ Ο ελάχιςτοσ αρικμόσ των 4 δορυφόρων «ορατϊν» προσ ζνα δζκτθ GPS είναι και θ ελάχιςτθ απαίτθςθ για να καταςτεί δυνατόσ ο εντοπιςμόσ τθσ κζςθσ (Χ, Y, Z) 38

39 του ςθμείου. Τα γνωςτά ςθμεία είναι οι δορυφόροι και τα άγνωςτα οι δζκτεσ GPS. Ο δορυφορικόσ προςδιοριςμόσ κζςθσ, όπωσ αποκαλείται, προχποκζτει ότι: Πλοι οι δορυφόροι ζχουν ςυγχρονιςμζνα τα ρολόγια τουσ ςτθν ίδια ϊρα που είναι και θ ϊρα αναφοράσ. Οι δορυφόροι γνωρίηουν τθ κζςθ τουσ μζςω δεδομζνων που λαμβάνουν από τουσ διαχειριςτζσ του ςυςτιματοσ. Ο κάκε δορυφόροσ εκπζμπει ςτον ορατό δζκτθ GPS τθν κζςθ του και ζνα ςιμα χρόνου. Τα ςιματα «ταξιδεφουν» ςτον δζκτθ με κακυςτζρθςθ ανάλογθ τθσ απόςταςθσ που διζνυςαν. Οι διαφορετικζσ αποςτάςεισ που διανφει το κάκε ςιμα μζχρι να φτάςει ςτον δζκτθ GPS δίνουν τθν εντφπωςθ πωσ κάκε δορυφόροσ ζχει διαφορετικι ϊρα. Ο δζκτθσ υπολογίηει τθν απόςταςι του από κάκε δορυφόρο και μετά υπολογίηει τθ δικι του κζςθ. Αν τα ρολόγια των δεκτϊν GPS και των δορυφόρων είναι τζλεια ςυγχρονιςμζνα ωσ προσ τθν ενιαία κλίμακα χρόνου GPS, τότε θ κζςθ του δζκτθ, ςε κάκε χρονικι ςτιγμι, ορίηεται γεωμετρικά από τθν τομι τριϊν ςφαιρϊν με κζντρα τουσ αντίςτοιχουσ δορυφόρουσ και ακτίνεσ τισ αντίςτοιχεσ αποςτάςεισ. Από τθν τομι δφο ςφαιρϊν προκφπτει μια καμπφλθ (κφκλοσ), ενϊ από τθν τομι τθσ καμπφλθσ αυτισ με τθν τρίτθ ςφαίρα προκφπτουν δφο ςθμεία εκ των οποίων εκείνο που βρίςκεται πιο κοντά ςτθ Γθ είναι και το ηθτοφμενο. Είναι προφανζσ ότι χρειάηονται 3 ταυτόχρονεσ παρατθριςεισ αποςτάςεων, όςεσ δθλαδι και οι άγνωςτεσ ςυντεταγμζνεσ (X,Y,Z) που εκφράηουν τθ κζςθ. Επειδι όμωσ, όπωσ είδαμε, υπάρχει και μια χρονικι κακυςτζρθςθ του χρονομζτρου του δζκτθ ςε ςχζςθ με το χρόνο αναφοράσ του GPS ςε κάκε ςιμα, κατά τον προςδιοριςμό τθσ κζςθσ ενόσ δζκτθ προςτίκεται και ζνασ επιπλζον άγνωςτοσ dt που τθν αντιπροςωπεφει. Με αυτόν τον τρόπο οι άγνωςτοι ςυνολικά γίνονται 4 αφοφ υπειςζρχεται και θ άγνωςτθ παράμετροσ «διόρκωςθ χρόνου του δζκτθ» ωσ προσ τθ κλίμακα του GPS. Επομζνωσ απαιτοφνται τζςςερισ ταυτόχρονεσ παρατθριςεισ αποςτάςεων προσ τζςςερισ διαφορετικοφσ δορυφόρουσ για να επιτευχκεί ο απόλυτοσ προςδιοριςμόσ κζςθσ ςε real time. Ανάλογα με το αν ο δζκτθσ παραμζνει ακίνθτοσ ι όχι διακρίνουμε τον ςτατικό προςδιοριςμό κζςθσ και τον κινθματικό προςδιοριςμό κζςθσ (kinematic positioning). Στθν δεφτερθ περίπτωςθ, που είναι και ςχετικι με τθν εφαρμογι που κα υλοποιιςουμε, ο δζκτθσ GPS κινείται κατά μικοσ μιασ διαδρομισ και υπολογίηει ςυντεταγμζνεσ ςε «τυχαία ςθμεία» τθσ διαδρομισ ανά τακτά χρονικά διαςτιματα που εμείσ ορίηουμε. Σε μια τζτοια περίπτωςθ θ «επαφι» του δζκτθ με τουσ δορυφόρουσ κα πρζπει να είναι ςυνεχισ κατά τθ διάρκεια τθσ κίνθςθσ. Σε ζνα παγκόςμιο ςφςτθμα πλοιγθςθσ δεν κα μποροφςε παρά να χρθςιμοποιείται ζνα παγκόςμιο ςφςτθμα αναφοράσ, βάςει του οποίου να κακορίηονται τόςο οι μεταβαλλόμενεσ κζςεισ των δορυφόρων όςο και οι ηθτοφμενεσ κζςεισ των δεκτϊν. Το ςφςτθμα που χρθςιμοποιείται για το ςκοπό αυτό είναι το WGS84 (World Geodetic System) και όλοι οι δζκτεσ εκφράηουν τθν υπολογιςμζνθ κζςθ τουσ με γεωγραφικζσ ςυντεταγμζνεσ λ (longitude), φ (latitude) και h (υψόμετρο) ςε αυτό. Οι δφο πρϊτεσ, από αυτζσ, δθλαδι το γεωγραφικό 39

40 μικοσ (longitude) και το γεωγραφικό πλάτοσ (latitude), μετριοφνται ςε μοίρεσ και αντιπροςωπεφουν τισ γωνιακζσ αποςτάςεισ, υπολογιςμζνεσ από το κζντρο τθσ Γθσ. Μποροφμε να φανταςτοφμε τθ Γθ ςαν μια ςφαίρα, με ζναν άξονα γφρω από τον οποίο περιςτρζφεται. Τα άκρα του άξονα είναι ο Βόρειοσ και ο Νότιοσ πόλοσ. Ο Ιςθμερινόσ είναι μια γραμμι γφρω από τθ Γθ, ςε ίςθ απόςταςθ από τουσ δφο πόλουσ. Ο ιςθμερινόσ είναι επίςθσ θ γραμμι γεωγραφικοφ πλάτουσ (latitude) με δοςμζνθ τιμι 0 μοιρϊν. Είναι δθλαδι, το ςθμείο εκκίνθςθσ για τθ μζτρθςθ του γεωγραφικοφ πλάτουσ. Οι τιμζσ του latitude δείχνουν τθν γωνιακι απόςταςθ ανάμεςα ςτον ιςθμερινοφ και ςε ςθμεία που βρίςκονται βορειότερα ι νοτιότερα από αυτόν ςτθν επιφάνεια τθσ Γθσ. Μια γραμμι που ςυνδζει όλα τα ςθμεία με το ίδιο γεωγραφικό πλάτοσ καλείται γραμμι γεωγραφικοφ πλάτουσ. Πλεσ αυτζσ οι γραμμζσ είναι παράλλθλεσ με τον ιςθμερινό και αρκετζσ φορζσ ςτθν βιβλιογραφία αναφζρονται ωσ «παράλλθλοι». Οι «παράλλθλοι» απζχουν το ίδιο μεταξφ τουσ. Το Εικόνα: Γεωγραφικζσ ςυντεταγμζνεσ ςτο WSG84 γεωγραφικό πλάτοσ μετράει μζχρι τισ 90 ο βόρεια από τον ιςθμερινό και μζχρι 90 ο νότια του ιςθμερινοφ. Ο βόρειοσ πόλοσ ζχει γεωγραφικό πλάτοσ 90 ο βόρεια, ενϊ ο νότιοσ πόλοσ 90 ο νότια του ιςθμερινοφ. Σε μερικζσ εκφράςεισ μπορεί να παραλείπεται θ κατεφκυνςθ, τότε τα βόρεια γεωγραφικά πλάτθ ζχουν κετικζσ τιμζσ και τα νότια γεωγραφικά πλάτθ ζχουν αρνθτικζσ τιμζσ. Οι γραμμζσ του γεωγραφικοφ μικουσ (longitude), που ονομάηονται και μεςθμβρινοί, είναι γραμμζσ κάκετεσ του γεωγραφικοφ πλάτουσ και όλεσ τουσ περνοφν από τουσ δφο πόλουσ. Δεν υπάρχει προφανζσ ςθμείο 0 μοιρϊν για το γεωγραφικό μικοσ. Με διεκνι ςυμφωνία αποφαςίςτθκε ο μεςθμβρινόσ που περνάει από το Greenwich (England) να είναι αυτόσ με τιμι 0 μοίρεσ γεωγραφικό μικοσ. Ο μεςθμβρινόσ αυτόσ καλείται ωσ «πρϊτοσ μεςθμβρινόσ». Οι τιμζσ του γεωγραφικοφ μικουσ εκφράηουν τθν γωνιακι απόςταςθ ανάμεςα ςτον πρϊτο μεςθμβρινό και ςε ςθμεία που βρίςκονται δυτικότερα ι ανατολικότερα ςε ςχζςθ με αυτόν, ςτθν επιφάνεια τθσ Γθσ. Ο πλανιτθσ μασ χωρίηεται ιςότιμα ςε 360 ο γεωγραφικοφ μικουσ. Υπάρχουν 180 ο γεωγραφικοφ μικουσ ςτα ανατολικά του πρϊτου μεςθμβρινοφ και αυτζσ οι τιμζσ είναι κετικζσ όταν παραλείπεται θ ζνδειξθ τθσ κατεφκυνςθσ. Επίςθσ, αντίςτοιχα υπάρχουν 180 ο γεωγραφικοφ μικουσ δυτικά του πρϊτου μεςθμβρινοφ οι οποίεσ ζχουν αρνθτικό πρόςθμο ςε εκφράςεισ όπου παραλείπεται θ κατεφκυνςθ. Η γραμμι των 180 ο γεωγραφικοφ μικουσ είναι απζναντι από τον πρϊτο μεςθμβρινό του πλανιτθ και είναι το ίδιο πθγαίνοντασ είτε δυτικά είτε ανατολικά. 40

41 Εικόνα: Γεωγραφικό μικοσ (longitude) και Γεωγραφικό πλάτοσ (latitude) Οι μοίρεσ, με τισ οποίεσ μετράμε το γεωγραφικό μικοσ και πλάτοσ, μποροφν να υποδιαιρεκοφν ςε λεπτά και δευτερόλεπτα. Υπάρχουν 60 λεπτά (ϋ) ανά μοίρα και 60 δευτερόλεπτα (ϋϋ) για κάκε λεπτό. Μια ςυντεταγμζνθ μπορεί να εκφραςτεί με τρεισ διαφορετικοφσ τρόπουσ: Μοίρεσ Λεπτά δεκαδικά Δευτερόλεπτα Μοίρεσ δεκαδικά Λεπτά δεκαδικζσ Μοίρεσ Πλεσ αυτζσ οι εκφράςεισ μασ επιτρζπουν να εντοπίηουμε περιοχζσ ςτθ Γθ με αρκετι ακρίβεια. Μία μοίρα γεωγραφικοφ πλάτουσ είναι περίπου 69 μίλια, ενϊ ζνα λεπτό γεωγραφικοφ πλάτουσ είναι περίπου 1.15 μίλια. Ζνα δευτερόλεπτο γεωγραφικοφ πλάτουσ είναι περίπου 0.02 μίλια, δθλαδι κοντά ςτα 33 μζτρα. Κάτι αντίςτοιχο για το γεωγραφικό μικοσ δεν υπάρχει, αφοφ μια μοίρα του ποικίλει ςε μζγεκοσ ανάλογα με τθ κζςθ. Στον ιςθμερινό είναι περίπου 69 μίλια (όπωσ και το γεωγραφικό πλάτοσ). Κακϊσ οι μεςθμβρινοί ςυγκλίνουν ςτουσ πόλουσ, το μζγεκοσ μειϊνεται ςταδιακά ςτο μθδζν. Επειδι ακριβϊσ μια μοίρα γεωγραφικοφ μικουσ ποικίλει ςε μζγεκοσ, το μζγεκοσ των λεπτϊν και δευτερολζπτων του επίςθσ ποικίλει και μειϊνεται και αυτό κακϊσ κινοφμαςτε προσ τουσ πόλουσ. 2.3 Πρωτόκολλο ΝΜΕΑ Το πρωτόκολλο ΝΜΕΑ είναι ζνα ςτάνταρ πρωτόκολλο, που χρθςιμοποιείται από τουσ δζκτεσ GPS για τθν μετάδοςθ δεδομζνων. Το ΝΜΕΑ προκφπτει από τα αρχικά National Marine Electronics Association και ςχεδιάςτθκε για τθν επικοινωνία μεταξφ των καλάςςιων θλεκτρονικϊν ςυςκευϊν όπωσ βακφμετρο, ςόναρ, ανεμόμετρο, γυροςκοπικι πυξίδα, αυτόματο πιλότο και δζκτεσ GPS. Τα περιςςότερα προγράμματα θλεκτρονικϊν υπολογιςτϊν που παρζχουν πλθροφορίεσ για τθ κζςθ ενόσ αντικειμζνου ςε πραγματικό χρόνο, καταλαβαίνουν και περιμζνουν τα δεδομζνα να είναι ςε μορφι ΝΜΕΑ. Τα δεδομζνα αυτά περιλαμβάνουν τθν πλιρθσ PVT (position, velocity, time) λφςθ που ζχει υπολογιςτεί από τον δζκτθ GPS. Η ιδζα του πρωτόκολλου ΝΜΕΑ είναι να ςτείλει μια γραμμι δεδομζνων που καλείται «πρόταςθ» (sentence) και θ οποία είναι εντελϊσ αυτόνομθ 41

42 και ανεξάρτθτθ από άλλεσ «προτάςεισ». Υπάρχουν ςτάνταρ προτάςεισ για κάκε κατθγορία ςυςκευισ. Πλεσ οι ςτάνταρ προτάςεισ ζχουν ζνα πρόκεμα δφο γραμμάτων, το οποίο ορίηει τθν ςυςκευι που χρθςιμοποιεί αυτό το είδοσ «πρόταςθσ». Συγκεκριμζνα, για τουσ δζκτεσ GPS που μασ ενδιαφζρει, το πρόκεμα είναι GP. Το πρόκεμα ακολουκείται από μια αλλθλουχία τριϊν γραμμάτων, θ οποία κακορίηει το περιεχόμενο τθσ «πρόταςθσ». Επιπλζον, το πρωτόκολλο επιτρζπει ςτουσ καταςκευαςτζσ υλικοφ να κακορίςουν τισ δικζσ τουσ «προτάςεισ» για οποιοδιποτε ςκοπό κρίνουν. Πλεσ οι ιδιόκτθτεσ τζτοιεσ «προτάςεισ» ξεκινοφν με το γράμμα και ακολουκοφνται από τρία γράμματα τα οποία προςδιορίηουν τον καταςκευαςτι που ελζγχει τθν «πρόταςθ» αυτι. Για παράδειγμα, μια GARMIN «πρόταςθ» κα ξεκινάει με PGRM. Η κάκε πρόταςθ ξεκινάει με ζνα $ και τελειϊνει με μια ακολουκία CR (carriage return) ι LF (line feed) και δεν μπορεί να είναι μεγαλφτερθ από 80 χαρακτιρεσ ορατοφ κειμζνου (ςυμπεριλαμβανομζνου του χαρακτιρα τερματιςμοφ γραμμισ). Οι «προτάςεισ» αποτελοφνται από δεδομζνα που διαχωρίηονται μεταξφ τουσ με κόμματα. Τα δεδομζνα, ςτα πλαίςια μιασ «πρόταςθσ» ςυνικωσ μεταβλθτοφ μικουσ, είναι ςτθν πραγματικότθτα απλό ASCII κείμενο. Το ποςό τθσ ακρίβειάσ τουσ ενδζχεται να διαφοροποιείται από μινυμα ςε μινυμα. Για παράδειγμα, θ κζςθ μπορεί να ζχει ακρίβεια 3 ι ακόμα και 4 δεκαδικά ψθφία μετά τθν υποδιαςτολι. Για αυτό το λόγο, τα προγράμματα που διαβάηουν τα δεδομζνα κα πρζπει να χρθςιμοποιοφν μόνο τα κόμματα για να κακορίηουν τα όρια των πεδίων των δεδομζνων ςε μια «πρόταςθ» και να μθν εξαρτϊνται από τισ κζςεισ ςτιλθσ. Επίςθσ, ςτο τζλοσ τθσ κάκε «πρόταςθσ» υπάρχει πρόβλεψθ για άκροιςμα ελζγχου (checksum) που μπορεί να ελεγχκεί από τθ μονάδα που διαβάηει τα δεδομζνα. Το πεδίο του checksum αποτελείται από ζνα χαρακτιρα * και από δφο δεκαεξαδικά ψθφία που δίνουν ζνα 8-bit αρικμό ο οποίοσ αντιπροςωπεφει το exclusive OR όλων των χαρακτιρων μεταξφ τουσ, εξαιρετζων των χαρακτιρων $ και *. Σε μερικζσ «προτάςεισ» το πεδίο checksum είναι απαραίτθτο. Στθν πορεία των χρόνων, ζχουν υπάρξει πολλζσ αλλαγζσ και τροποποιιςεισ ςτο πρωτόκολλο. Για χριςθ ςε δζκτεσ GPS όμωσ, οι μόνεσ εκδοχζσ του προτφπου που χρθςιμοποιοφνται είναι θ 1.5 και 2.0 με 2.3. Μερικά GPS δίνουν τθ δυνατότθτα να ρυκμίςει ο προγραμματιςτισ το ςετ των «προτάςεων» που κζλει να λάβει, ενϊ άλλοι προςφζρουν ζνα ςετ fixed επιλογϊν. Οι περιςςότεροι δζκτεσ GPS βγάηουν ςτθν ζξοδό τουσ ζνα ςτακερό ςφνολο «προτάςεων» που δεν μπορεί να μεταβλθκεί από τον χριςτθ. Το hardware interface για τουσ δζκτεσ GPS ςχεδιάηεται ζτςι ϊςτε να ανταποκρίνεται ςτισ απαιτιςεισ του πρότυπου ΝΜΕΑ. Οι τελευταίεσ είναι ςυμβατζσ και με τισ περιςςότερεσ ςειριακζσ κφρεσ του υπολογιςτι που χρθςιμοποιοφν το πρωτόκολλο RS232. Η ταχφτθτα διαςφνδεςθσ μπορεί να ρυκμιςτεί ςε μερικά μοντζλα δεκτϊν, αλλά ςτο πρότυπο ΝΜΕΑ είναι ςτα 4800 bps, με 8-bits δεδομζνων, χωρίσ χριςθ parity bit και με ζνα stop bit. Πλεσ οι μονάδεσ που είναι ςυμβατζσ με το ΝΜΕΑ κα πρζπει να μποροφν να υποςτθρίξουν αυτι τθν ταχφτθτα. Σε αυτό το ςθμείο, να ςθμειϊςουμε ότι με μια ταχφτθτα τθσ τάξθσ των 4.8 Kbps μποροφμε μόνο να ςτείλουμε περίπου 480 χαρακτιρεσ το δευτερόλεπτο. Από τθ ςτιγμι που μια «πρόταςθ» ΝΜΕΑ μπορεί να αποτελείται από 82 χαρακτιρεσ, αυτό μπορεί να μασ περιορίςει ςτθν αποςτολι λιγότερων από 6 διαφορετικϊν «προτάςεων» ςτθ μονάδα του χρόνου. Το όριο, ςτθν πραγματικότθτα, κακορίηεται από τισ 42

43 ςυγκεκριμζνεσ «προτάςεισ» που επιλζγονται για αποςτολι, αλλά καταλαβαίνουμε ότι δεν είναι δφςκολο να γίνει υπζρβαςθ των δυνατοτιτων όταν κζλουμε ταχεία απόκριςθ «προτάςεων». Το πρότυπο ΝΜΕΑ ζχει ςχεδιαςτεί για να λειτουργεί ςαν μια διαδικαςία ςτο παραςκινιο εξάγοντασ προτάςεισ, οι οποίεσ ςτθ ςυνζχεια ςυλλζγονται και χρθςιμοποιοφνται αναλόγωσ από το πρόγραμμα που τρζχει. Οι περιςςότεροι δζκτεσ GPS κατανοοφν το πρότυπο με όνομα ΝΜΕΑ 0183, που είναι θ ζκδοςθ 2.0 του πρωτοκόλλου και υπαγορεφει ταχφτθτα μετάδοςθσ δεδομζνων ςτα 4800 bps. Υπάρχουν όμωσ και μονάδεσ που μποροφν να ρυκμιςτοφν ςτα 9600 bps ι ακόμα και ςε υψθλότερεσ ταχφτθτεσ όςον αφορά ςτθν ζξοδο του ΝΜΕΑ. υκμίηοντασ τθν ταχφτθτα ςτο υψθλότερο όριο μπορεί να βελτιϊςει τθν απόκριςθ του προγράμματοσ (ςθμείωςθ: ςε μερικζσ μονάδεσ ςτισ οποίεσ θ αρχικι ρφκμιςθ είναι για ταχφτθτα 4800 bps, θ αφξθςθ από τα 4800 ςτα 9600 bps προχποκζτει ότι ζχουμε δοκιμάςει επιτυχϊσ λειτουργία ςτα 4800). Ππωσ είπαμε και παραπάνω, το πρότυπο ΝΜΕΑ αποτελείται από «προτάςεισ», θ πρϊτθ λζξθ των οποίων, κακορίηει τθν ερμθνεία τθσ υπόλοιπθσ «πρόταςθσ». H GGA (που φαίνεται παρακάτω) «πρόταςθ» δίνει ςθμαντικά fix data. Άλλεσ «προτάςεισ» μπορεί να επαναλαμβάνουν κάποια από αυτά τα δεδομζνα αλλά παρζχουν και κάποια καινοφρια. Οποιαδιποτε ςυςκευι ι πρόγραμμα που διαβάηει τα δεδομζνα εξόδου του προτφπου ΝΜΕΑ μπορεί να ψάχνει απλά για τθν «πρόταςθ» που χρειάηεται και απλά να αγνοεί όλεσ τισ υπόλοιπεσ. Ζτςι, κάκε δζκτθσ GPS ςτζλνει όλα τα δεδομζνα που δζχεται από τουσ δορυφόρουσ και αναμζνει πολλά απ αυτά να αγνοθκοφν ςτθν πορεία. Δεν υπάρχει κάποιοσ τρόποσ με τον οποίο να γίνεται αναφορά πίςω ςτθ μονάδα του δζκτθ για το αν οι «προτάςεισ» παραλιφκθκαν και διαβάςτθκαν ςωςτά ι να γίνεται αίτθςθ για επανάλθψθ αποςτολισ δεδομζνων που δεν ζφταςαν ςτον παραλιπτθ. Αντίκετα, θ μονάδα παραλαβισ ελζγχει μόνο το checksum και αγνοεί τα δεδομζνα εάν τον checksum δεν είναι αυτό που πρζπει, γνωρίηοντασ πωσ κα λάβει καινοφρια ςφντομα. Κάποιεσ από τισ «προτάςεισ» που ζχουν εφαρμογι ςτουσ δζκτεσ GPS είναι οι ακόλουκεσ (όλεσ τουσ ξεκινάνε με το πρόκεμα GP ): GGA (Global Positioning System fix data) Δίνει ουςιϊδθ ςτοιχεία που κακορίηουν τθν κζςθ ενόσ αντικειμζνου ςτισ τρεισ διαςτάςεισ και ακριβι δεδομζνα. GLL (Geographic position Latitude and Longitude) GSA (GPS receiver operating mode and satellites used for navigation) GSV (Satellites in View) RMA (Navigation data from current position) RMB (Recommended minimum navigation information) RMC (Recommended minimum specific GPS/TRANSIT data) RTE (Waypoints in active route) VDM (Automatic information system position reports from other vessels) VTG (Track made good and ground speed) WPL (Waypoint location) ZDA (Data and time) Οι παραπάνω είναι κάποιεσ από τισ πολλζσ «προτάςεισ» του προτφπου ΝΜΕΑ που χρθςιμοποιοφνται από τουσ δζκτεσ GPS. Από αυτζσ, οι πιο ςθμαντικζσ 43

44 περιλαμβάνουν τθν GPGGA, που παρζχει τα τρζχοντα fix δεδομζνα, τθν GPRMC, που παρζχει τισ ελάχιςτεσ πλθροφορίεσ που απαιτοφνται για το GPS ςε μια «πρόταςθ» και τθν GPGSA, που παρζχει δεδομζνα κατάςταςθσ των δορυφόρων. [τθ ςυνζχεια τθσ εργαςίασ, κα γίνει αναφορά για το χρθςιμοποιοφμενο υλικό και τον δζκτθ GPS που επιλζχκθκε όπου και κα αναλφςουμε τισ «προτάςεισ» που θ ςυγκεκριμζνθ ςυςκευι διαχειρίηεται.] 2.4 Περιγραφι προβλιματοσ τόχοσ Διπλωματικισ Μζχρι ςτιγμισ ζχουμε αναφζρει περίπου ποιοσ είναι ο ςτόχοσ τθσ παροφςασ διπλωματικισ εργαςίασ. Θ χριςθ δικτφου αςυρμάτων αιςκθτιρων (WSN) για ιχνθλάτθςθ τθσ τροχιάσ ενόσ κινθτοφ, που φζρει πάνω του κόμβο του δικτφου, με εφαρμογι του walking GPS. Για τθν υλοποίθςθ ενόσ δικτφου WSN κάναμε χριςθ των διακζςιμων κόμβων IRIS motes (XM2110) τθσ εταιρείασ CROSSBOW. Τα motes, από μόνα τουσ, δεν ζχουν τθν ικανότθτα τθσ αίςκθςθσ. Υπάρχει μια μεγάλθ ποικιλία από sensor boards, που το κάκε ζνα ζχει διαφόρων τφπων αιςκθτζσ και επιςυνάπτεται πάνω ςτον κόμβο ςειριακά (μζςω UART). Το MTS420CC είναι το sensor board που επιλζχκθκε και το οποίο φζρει πάνω του δζκτθ GPS. Εικόνα: χθματικι απεικόνιςθ τθσ λειτουργίασ του ςυςτιματοσ που κα ςχεδιάςουμε. Ζνα κινθτό κα κινείται ςε μια διαδρομι ζχοντασ πάνω του το mote με το ςυνδεδεμζνο δζκτθ GPS. Στθ διάρκεια τθσ κίνθςθσ, ο δζκτθσ GPS κα δζχεται και κα επεξεργάηεται τα δορυφορικά ςιματα εντοπίηοντασ τθ κζςθ του κινθτοφ κάκε ςτιγμι. Τα δεδομζνα τθσ κζςθσ, κα περνάνε ςτον κόμβο (mote) και από εκεί κα αποςτζλλονται μζςω radio ςτον άλλο κόμβο του δικτφου ο οποίοσ και ζχει το ρόλο ενόσ datasink (basestation). Το datasink, το οποίο ςυνδζεται ςειριακά ςε κφρα USB με τον υπολογιςτι, τρζχει μια εφαρμογι ςυλλογισ των πακζτων που του ςτζλνονται από τουσ άλλουσ κόμβουσ και προϊκθςισ τουσ ςτον υπολογιςτι. Εκεί κα γίνεται και θ απεικόνιςθ τθσ τροχιάσ που ακολουκεί το κινθτό ςτθν πρότυπθ εφαρμογι Google Earth TM. 44

45 Για τθν επίτευξθ αυτοφ του ςτόχου, θ εργαςία μπορεί να χωριςτεί ςτα εξισ επιμζρουσ τμιματα: Ανάπτυξθ εφαρμογισ θ οποία κα δθμιουργεί ςυνκικεσ ςωςτισ επικοινωνίασ με το sensor board, κα ενεργοποιεί τον αιςκθτιρα δζκτθ GPS και κα ηθτάει δεδομζνα από αυτόν. Επίςθσ, ςτισ προδιαγραφζσ αυτισ τθσ εφαρμογισ κα πρζπει να είναι θ ςωςτι ςειριακι ανάγνωςθ των δεδομζνων μζςω UART (τρόποσ ςφνδεςθσ mote sensor board) και θ οργάνωςθ των δεδομζνων ςε κατάλλθλεσ δομζσ για τον ςχθματιςμό «πακζτων». Τζλοσ, θ εφαρμογι αυτι πρζπει να ςτζλνει τα πακζτα που δθμιουργεί προσ το datasink μζςω radio. Η εφαρμογι κα είναι εγκατεςτθμζνθ ςτο mote που κα βρίςκεται ςτο κινθτό. Ανάπτυξθ εφαρμογισ DATASINK για τθν λιψθ πακζτων μζςω radio και προϊκθςθ τουσ με ςειριακι επικοινωνία (μζςω USB) ςτον υπολογιςτι. Η εφαρμογι αυτι κα βρίςκεται εγκατεςτθμζνθ ςτο mote που κα ζχει το ρόλο του basestation, και κα είναι ςυνδεδεμζνο με τον υπολογιςτι. Από τθν πλευρά του υπολογιςτι, απαιτείται θ ανάπτυξθ προγράμματοσ για τθν ανάγνωςθ δεδομζνων από κφρα USB, τθν επεξεργαςία τουσ και τθν τοποκζτθςθ των χριςιμων πλθροφοριϊν ςε μια λειτουργικι δομι. Το πρόγραμμα επιπλζον κα πρζπει να αποκακιςτά ςφνδεςθ με τθν εφαρμογι Google Earth TM και να περνάει ςε αυτιν τα περιεχόμενα τθσ δομισ. Ζνα μζροσ του προγράμματοσ κα πρζπει να μεριμνεί ζτςι ϊςτε να δεδομζνα να είναι ςε μορφι ςυμβατι με τισ απαιτιςεισ τθσ εφαρμογισ Google Earth TM. Στο πλαίςιο αυτισ τθσ εργαςίασ θ δρομολόγθςθ, ανάμεςα ςε πολλοφσ κόμβουσ ενόσ WSN, είναι ζνα κζμα που δεν κα μασ απαςχολιςει. 45

46 ΚΕΦΑΛΑΙΟ 3 Ο ΤΛΙΚΟ Hardware 3.1 Ειςαγωγι Το hardware που χρθςιμοποιικθκε για το δίκτυο ςχεδιάςτθκε και καταςκευάηεται από τθν εταιρεία Crossbow Technology Inc. και αποτελείται από δφο αςφρματουσ κόμβουσ τφπου IRIS (καινοφρια βελτιωμζνθ ζκδοςθ motes τθσ οικογζνεια micaz), μια πλακζτα αιςκθτιρων τφπου MTS420CC και μια προγραμματιςτικι πλακζτα τφπου MIB520. Σε αυτό το κεφάλαιο δίνεται μια ςφντομθ περιγραφι τθσ δομισ, τθσ λειτουργίασ και των δυνατοτιτων των ςυγκεκριμζνων εξαρτθμάτων. 3.2 IRIS Motes Η δομι του κόμβου IRIS ακολουκοφν το γενικό μοντζλο κόμβων για WSN που είδαμε και ςε προθγοφμενα κεφάλαια. Ρρόκειται για μια ολοκλθρωμζνθ μονάδα που χρθςιμοποιείται για τθν δθμιουργία χαμθλισ ιςχφοσ αςυρμάτων δικτφων αιςκθτϊν και ζχει τα χαρακτθριςτικά: Ζχει ςχεδιαςτεί ςυγκεκριμζνα για Deeply Embedded Sensor Networks. Διακζτει RF πομποδζκτθ που χρθςιμοποιεί το ΙΕΕΕ πρότυπο. Υποςτθρίηει υψθλοφσ ρυκμοφσ μετάδοςθσ δεδομζνων τθσ τάξθσ των 250 kbps. Λειτουργεί ςε μια κακολικά ςυμβατι ISM ηϊνθ από 2.4 ζωσ 2.48 GHz. Ο κάκε κόμβοσ μπορεί να χρθςιμοποιθκεί ςαν δρομολογθτισ. Υποςτθρίηει μια μεγάλθ ποικιλία από sensor boards για μζτρθςθ διαφορετικϊν ποςοτιτων όπωσ αιςκθτιρεσ φωτόσ, κερμοκραςίασ, υγραςίασ, πίεςθσ, επιτάχυνςθσ, μαγνθτικοφ πεδίου κ.α. Μπορεί να υποςτθρίξει δθμιουργία WSN με μεγάλο πλικοσ κόμβων (>1000). Τα IRIS motes (XM2110CA) χρθςιμοποιοφν τον μικροελεγκτι ΑΤmega1281 και τον πομποδζκτθ RF230 και τα δφο προϊόντα τθσ εταιρίασ Atmel. Ασ δοφμε όμωσ αναλυτικότερα τα επιμζρουσ ςτοιχεία που ςυνκζτουν τον κόμβο IRIS. 46

47 Εικόνα: (Αριςτερά) Mote IRIS XM2110CA upper view. (Δεξιά) Block diagram του XM2110CA ATmega1281 Τα IRIS XM2110CA βαςίηονται ςτον μικροεπεξεργαςτι χαμθλισ ιςχφοσ ATmega1281, ο οποίοσ μπορεί να τρζξει τισ custom εφαρμογζσ από τθν εςωτερικι flash μνιμθ. Κάκε mote μπορεί να προγραμματιςτεί ζτςι ϊςτε να τρζχει ταυτόχρονα τθν ςτοίβα εφαρμογισ/επεξεργαςίασ και τθν ςτοίβα επικοινωνίασ του δικτφου. Ο 51-pin connector υποςτθρίηει διεπαφζσ αναλογικϊν, ψθφιακϊν Ε/Ε, SPI και UART, που επιτρζπουν ςφνδεςθ με διαφορετικζσ περιφερειακζσ ςυςκευζσ. Ο μικροεπεξεργαςτισ είναι ςχεδιαςμζνοσ με αρχιτεκτονικι RISK, διακζτει ζνα ςετ 135 εντολϊν και 32 x 8 καταχωρθτζσ γενικοφ ςκοποφ οι οποίοι είναι άμεςα ςυνδεδεμζνοι με τθν αρικμθτικι λογικι μονάδα (ALU). Δεδομζνου ότι διακζτει πλθκϊρα πόρων και δυνατοτιτων που περιγράφονται ςτο manual του, κα παρακζςουμε μόνο ότι αξιοποιεί το IRIS mote. Μνιμθ προγράμματοσ (Flash) 128 kb: Αποκθκεφει τον κϊδικα τθσ εφαρμογισ και προγραμματίηεται μζςω του αναπτυξιακοφ MIB520. SRAM 8 kb: Χρθςιμοποιείται για τθν αποκικευςθ παραμζτρων τθσ εφαρμογισ, όπωσ μεταβλθτζσ του tinyos (λειτουργικό ςφςτθμα των motes). Ρεριζχει επίςθσ και τθ ςτοίβα που χρθςιμοποιείται για αποκικευςθ προςωρινϊν δεδομζνων, τοπικϊν μεταβλθτϊν κακϊσ και διευκφνςεισ όταν γίνονται interrupts και κλιςεισ υπορουτίνων. EEPROM 4kB: Σε αυτι τθ μνιμθ αποκθκεφονται κάποιεσ ςτακερζσ, όπωσ θ ταυτότθτα του κόμβου, το radio channel κ.α. Timers: Ο μικροεπεξεργαςτισ διακζτει ςυνολικά 4 timers. Δφο των 8 bit και δφο των 16 bit. Οι δφο 16μπιτοι μποροφν να χρθςιμοποιθκοφν από τον χριςτθ, ςε αντίκεςθ με τουσ δφο 8μπιτουσ που δεςμεφονται από το tinyos. SPI bus: Δεςμεφεται για τθν ςειριακι ςφνδεςθ επεξεργαςτι πομποδζκτθ (RF module) και δεν είναι διακζςιμθ ςτον χριςτθ. 47

48 Εικόνα: Διάγραμμα ακροδεκτϊν του ATmega1281 USART: Υποςτθρίηονται δφο UARTs με δυνατότθτα ςφγχρονθσ και αςφγχρονθσ λειτουργίασ. Η UART0 δεςμεφεται για τθν επικοινωνία με το αναπτυξιακό MIB520, ενϊ θ UART1 είναι διακζςιμθ ςτο χριςτθ. ADC: 8 κανάλια με 10 bits. Η τάςθ αναφοράσ είναι θ τάςθ τθσ μπαταρίασ. GPIO: 7 ports με 8 pins θ κάκε μια. External clock (High speed) MHz: Χρθςιμεφει για τθν παραγωγι ςτακερϊν baudrates τθσ UART όταν ο κόμβοσ είναι ςυνδεδεμζνοσ με το αναπτυξιακό ΜΙΒ520. Σε κάκε άλλθ περίπτωςθ χρθςιμοποιείται το εςωτερικό ρολόι των 8 ΜΗz. External clock (Low speed) 32 khz: Χρθςιμεφει ςτον χρονιςμό του tinyos. Λειτουργεί ςυνεχϊσ για να μπορεί να «ξυπνάει» τον κόμβο από κατάςταςθ SLEEP. Ζχει ζξι καταςτάςεισ SLEEP: Οι καταςτάςεισ επιλζγονται αυτόματα από το TinyOs, μζςω του scheduler. 48

49 Εικόνα: Ενεργειακζσ καταςτάςεισ του ATmega ATRF230 RF πομποδζκτθσ Ο πομποδζκτθσ ATRF230 είναι πλιρωσ ςυμβατόσ με το πρότυπο ΙΕΕΕ και είναι ειδικά ςχεδιαςμζνοσ για εφαρμογζσ χαμθλισ ιςχφοσ- τάςθσ. Χρθςιμοποιεί τθν τεχνικι μετάδοςθσ DSSS με διαμόρφωςθ ςιματοσ O-QPSK [16] (offset quadrature phase shift keying), επιτυγχάνοντασ κζρδοσ εξάπλωςθσ βαςικισ ηϊνθσ 9 db και ρυκμοφσ μετάδοςθσ ωσ και 250 kbps. Μερικά από τα βαςικά χαρακτθριςτικά του module είναι: Μετάδοςθ ςτθ ηϊνθ των GHz (16 κανάλια των 5 ΜHz). Ρρογραμματιηόμενθ ιςχφσ εξόδου από -17 dbm ζωσ 3 dbm. Ευαιςκθςία δζκτθ -101 dbm. Χαμθλι κατανάλωςθ (0.1 μα ςε SLEEP mode, 1.7 ma ςε ΤRX_OFF, 16 ma ςε RX_ON και 17 ma ςε BUSY_TX). Χρόνοσ εκκίνθςθσ < 1ms. Σφνδεςθ με μικροεπεξεργαςτι μζςω SPI. Λειτουργία βαςιςμζνθ ςε interrupts. 64 καταχωρθτζσ από τουσ οποίουσ υπάρχει πρόςβαςθ ςτουσ byte SRAM buffer πλαιςίου (frame buffer). Τροφοδοςία volt. Εικόνα: Pin-out diagram του AT86RF230 49

50 Εικόνα: Block διάγραμμα του RF230 Εικόνα: SPI ςφνδεςθ του ATmega1281 με τον AT86RF230 Ππωσ ςθμειϊςαμε και ςτα βαςικά χαρακτθριςτικά του RF230, το module μπορεί να κάνει διάκριςθ μεταξφ ζξι interrupt events. Κάκε διακοπι μπορεί να ενεργοποιθκεί ι να απενεργοποιθκεί γράφοντασ το αντίςτοιχο bit ςτον καταχωρθτι interrupt mask. Πλεσ οι εςωτερικζσ γραμμζσ που αντιςτοιχοφν ςε ζνα interrupt ςυνδυάηονται μεταξφ τουσ με λογικό OR ςε μια εξωτερικι γραμμι διακοπισ. Εςωτερικά, θ κάκε διακοπι αποκθκεφεται ςε ζνα ξεχωριςτό bit του καταχωρθτι interrupt status. Αν θ εξωτερικι γραμμι interrupt υποδεικνφει ότι υπάρχει διακοπι, ο ελεγκτισ πρζπει πρϊτα να διαβάςει τον καταχωρθτι interrupt status για να κακορίςει τθν πθγι τθσ διακοπισ. Η πρόςβαςθ για μια διαδικαςία read ςε αυτόν τον καταχωρθτι «κακαρίηει» το περιεχόμενό του αλλά και τθν εξωτερικι γραμμι interrupt. Η διακοπι δεν κα «κακαριςτεί» αυτόματα αν το γεγονόσ που προκάλεςε το IRQ δεν είναι πια ζγκυρθ. Εξαίρεςθ ςτο τελευταίο αποτελεί θ διακοπι PLL_LOCK θ οποία κα «κακαρίςει» τθν PLL_UNLOCK και αντίςτροφα. Εδϊ να ςθμειϊςουμε ότι μετά από μια λειτουργία RESET, όλεσ οι διακοπζσ ενεργοποιοφνται. 50

51 Εικόνα: Οι διακοπζσ του RF230 module Το RF230 διακζτει επτά βαςικζσ καταςτάςεισ λειτουργίασ ςχεδιαςμζνεσ με βάςθ το πρότυπο ΙΕΕΕ τισ οποίεσ και παρακζτουμε: 1. P_ON: Πταν θ εξωτερικι τάςθ τροφοδοςίασ (VDD) ςυνδεκεί για πρϊτθ φορά με τον πομποδζκτθ το ςφςτθμα είναι ςτθν P_ON (Power ON) κατάςταςθ. Σε αυτι τθ λειτουργία, ο ταλαντωτισ κρυςτάλλου ζχει ενεργοποιθκεί και το κφριο ρολόι για τον ελεγκτι παρζχεται ςτο pin CLKM φςτερα από μια κακυςτζρθςθ τθσ τάξθσ των 128 μsec για να εξαςφαλίςει μια ςτακερι κατάςταςθ (steady state) ςτον ταλαντωτι κρυςτάλλου. Πλεσ οι ψθφιακζσ είςοδοι ζχουν pull-up ι pull-down αντιςτάςεισ. Αυτό είναι απαραίτθτο για τθν ςφνδεςθ με τον ελεγκτι μιασ και τα GPIO ςιματα είναι ακακόριςτα μετά από ζνα reset. Οι αντιςτάςεισ αυτζσ απενεργοποιοφνται όταν ο πομποδζκτθσ φεφγει από τθν κατάςταςθ P_ON. Για να φφγει το chip από τθν κατάςταςθ P_ON απαιτείται μια ζγκυρθ λειτουργία SPI εγγραφισ (write) ςτον καταχωρθτι TRX_STATE με τισ τιμζσ TRX_OFF ι FORCE_TRX_OFF. Ρριν από τθν αναχϊρθςθ από αυτι τθ κατάςταςθ ο ελεγκτισ πρζπει να κζςει τισ τιμζσ των pins ςτισ αρχικζσ λειτουργικζσ τιμζσ: SLP_TR = 0 και RST = 1. Μια on-chip, power-on-reset διαδικαςία επαναφζρει όλουσ τουσ καταχωρθτζσ ςτισ αρχικζσ τουσ τιμζσ. Ζνα επιπλζον ειδικό ςιμα reset από τον ελεγκτι που ςυνδζεται ςτο pin RST δεν είναι απαραίτθτο, αλλά ςυνίςταται για λόγουσ ςυγχρονιςμοφ HW/SW. 2. SLEEP: Στθν κατάςταςθ SLEEP όλο το ολοκλθρωμζνο κφκλωμα του πομποδζκτθ είναι απενεργοποιθμζνο. Η κατανάλωςθ ρεφματοσ ςε αυτι τθ κατάςταςθ είναι, ςτθν ουςία, μόνο ρεφματα διαρροισ. Αυτι θ λειτουργία μπορεί να επιτευχκεί μόνο από τθν κατάςταςθ TRX_OFF, όταν το pin SLP_TR πάρει τθν τιμι 1. Θζτοντασ το pin SLP_TR ςτθ τιμι 0, ο πομποδζκτθσ επιςτρζφει ςτθν κατάςταςθ TRX_OFF χωρίσ να επθρεάηει τα περιεχόμενα των καταχωρθτϊν. Χρθςιμοποιϊντασ το RST = 0 γίνεται επαναφορά του SPI και των καταχωρθτϊν διαμόρφωςθσ ςτισ προεπιλεγμζνεσ τουσ τιμζσ, ενϊ αναγκάηει το ολοκλθρωμζνο να μπει ςτθ κατάςταςθ TRX_OFF. 3. TRX_OFF: Στθν κατάςταςθ αυτι παρζχεται το κεντρικό ρολόι για τον ελεγκτι ςε ςφγχρονο τρόπο λειτουργίασ, επιτρζποντασ ςτο λογιςμικό να τρζχει χωρίσ τθν ανάγκθ να είναι ανοιχτό το radio. Τα pins SLP_TR και RST είναι ενεργοποιθμζνα για να γίνεται ζλεγχοσ κατάςταςθσ. Σε αυτι τθ λειτουργία, που καλείται και clock state, θ διεπαφι SPI και ο ταλαντωτισ κρυςτάλλου είναι ενεργά. Ο ρυκμιςτισ τάςθσ είναι ενεργόσ και παρζχει τάςθ 1.8 Volt 51

52 ςτον ψθφιακό πυρινα για να ζχει πρόςβαςθ ςτα δεδομζνα των frame buffers. Ο frame buffer είναι ζνασ εςωτερικόσ καταχωρθτισ 128 byte που μπορεί να κρατιςει ζνα TX ι ζνα RX frame κάκε φορά. 4. PLL_ON: Μπαίνοντασ ςτθ κατάςταςθ λειτουργίασ PLL_ON από τθν TRX_OFF κα προκλθκεί ενεργοποίθςθ του αναλογικοφ ρυκμιςτι τάςθσ. Στθ ςυνζχεια ενεργοποιείται ο PLL ςυνκζτθσ ςυχνοτιτων. Πταν το PLL ζχει κλειδϊςει ςτθ ςυχνότθτα λιψθσ τότε εκδθλϊνεται μια αίτθςθ διακοπισ PLL_LOCK ςτο IRQ pin. Κατά τθ διάρκεια λειτουργίασ PLL_ON, θ εντολι RX_ON ςτον καταχωρθτι TRX_STATE (register 0x02) κζτει τον πομποδζκτθ ςτθ κατάςταςθ RX_ON. 5. RX_ON / BUSY_RX: Στθν κατάςταςθ RX_ON ενεργοποιοφνται ο αναλογικόσ και ο ψθφιακόσ δζκτθσ, με το PLL να είναι ιδθ ενεργοποιθμζνο. Η μετάβαςθ από τθν κατάςταςθ TRX_OFF ςτθν RX_ON κζτοντασ τον καταχωρθτι TRX_STATE ςε RX_ON μζςω μιασ πρόςβαςθσ SPI εγγραφισ (spi write) ςτον καταχωρθτι 0x02. Η λειτουργία λιψθσ χωρίηεται ςε δφο καταςτάςεισ, τθν RX_ON και τθν BUSY_RX. Στθν κατάςταςθ RX_ON λειτουργεί μόνο θ διαδικαςία ανίχνευςθσ ενόσ ςιματοσ preamble. Πταν το τελευταίο ανιχνευκεί, ο ψθφιακόσ δζκτθσ ενεργοποιείται και θ κατάςταςθ αλλάηει ςε BUSY_RX. Κατά τθ διάρκεια λιψθσ του πλαιςίου, τα δεδομζνα αποκθκεφονται ςτον frame buffer. Η τιμι του pin SLP_TR ζχει νόθμα μόνο κατά τθν κατάςταςθ RX_ON. Στθν κατάςταςθ BUSY_RX το ςιμα αυτό δεν ζχει καμία επίδραςθ. 6. RX_ON_NOCLK: Αν το ράδιο «ακοφει» το κανάλι για ειςερχόμενα πλαίςια (frames) και ο ελεγκτισ δεν τρζχει καμία εφαρμογι, τότε ο ελεγκτισ μπορεί να απενεργοποιθκεί για να μειωκεί θ κατανάλωςθ ενζργειασ του ςυςτιματοσ. Το ςενάριο αυτό περιγράφει τθν κατάςταςθ RX_ON_NOCLK. Σε αυτι τθ κατάςταςθ ειςζρχεται το ολοκλθρωμζνο όταν βρίςκεται ςτθν λειτουργία RX_ON και το pin SLP_TR = 1. Η λιψθ ενόσ πλαιςίου ςθματοδοτείται ςτον ελεγκτι μζςω μιασ διακοπισ RX_START, ο οποίοσ και ενεργοποιείται ξανά μαηί με τον pin CLKM και ο πομποδζκτθσ μπαίνει ςτθ κατάςταςθ BUSY_RX. Το τζλοσ τθσ «ςυναλλαγισ» ςθματοδοτείται από μια διακοπι TRX_END και ο πομποδζκτθσ ειςζρχεται ςτθν κατάςταςθ RX_ON. Για να επανζλκει ςτθν κατάςταςθ RX_ON_NOCLK, μετά τθ λιψθ, κα πρζπει το ςιμα SLP_TR να ζχει γίνει reset ςτο 0 και μετά να ζχει γίνει πάλι BUSY_TX: Η εκπομπι μπορεί να ξεκινιςει μόνο από τθ κατάςταςθ PLL_ON. Η μετάβαςθ από τθν PLL_ON ςτθν BUSY_TX κατάςταςθ μπορεί να γίνει είτε με τθν άνοδο ενόσ παλμοφ ςτο pin SLP_TR ι με τθν καταχϊρθςθ τθσ εντολισ TX_START ςτον καταχωρθτι 0x02. Στθν κατάςταςθ αυτι, το PLL κλειδϊνει ςτθ ςυχνότθτα εκπομπισ, ο ενιςχυτισ ςιματοσ (Α) ενεργοποιείται και θ μετάδοςθ ξεκινά πρϊτα με το preamble ςιμα και ςτθ ςυνζχεια με το περιεχόμενο του frame buffer. Στο τζλοσ τθσ μετάδοςθσ, το ολοκλθρωμζνο απενεργοποιεί τον Α, προκαλεί τθν διακοπι TRX_END και επιςτρζφει ςτθν κατάςταςθ PLL_ON. 52

53 Εικόνα: Βαςικζσ καταςτάςεισ λειτουργίασ του ολοκλθρωμζνου RF230. Οι καταςτάςεισ λειτουργίασ εναλλάςςονται ανάλογα με τθν λειτουργία που πρόκειται να εκτελεςτεί. Οι μεταβάςεισ γίνονται μζςω των pins SLP_TR, RST και του καταχωρθτι 0x02, ενϊ ςτον καταχωρθτι 0x01 καταγράφεται θ τρζχουςα κατάςταςθ λειτουργίασ. Για μεγαλφτερθ ςυμβατότθτα με το πρότυπο ΙΕΕΕ , οι καταςκευαςτζσ εκτόσ από τισ βαςικζσ λειτουργίεσ ζχουν υλοποιιςει και κάποια επιπλζον χαρακτθριςτικά όπωσ θ αυτόματθ αποςτολι ACK και θ αυτόματθ αναμετάδοςθ πλαιςίου (frame retransmission). Αυτό ζχει ωσ αποτζλεςμα τθν απλοποίθςθ τθσ υλοποίθςθσ του MAC επιπζδου με λογιςμικό από το χριςτθ, που ςθμαίνει λιγότεροσ κϊδικασ και πικανότατα μικρότεροσ (άρα και πιο οικονομικόσ) μικροελεγκτισ. Τζλοσ, το μοντζλο του πομποδζκτθ που διακζτουν οι κόμβοι IRIS, δθλαδι το AT86RF230, περιλαμβάνει εξωτερικι διπολικι κεραία που ςυνδζεται με ζναν MMCX connector. Μετριςεισ τθσ απόδοςθσ τθσ κεραίασ δίνουν τα παρακάτω διαγράμματα ακτινοβολίασ. Από τα διαγράμματα ακτινοβολίασ παρατθροφμε ότι ζχουμε καλφτερθ ςυμπεριφορά (με γνϊμονα ότι κεωροφμε πανκατευκυντικι κεραία) ςε οριηόντιο προςανατολιςμό. Ραρόλα αυτά, ςε καμία από τισ δφο περιπτϊςεισ δεν ζχουμε τζλεια ομοιοκατευκυντικό διάγραμμα. Σε κάποιεσ γωνίεσ παρατθρείται μεγάλθ πτϊςθ τθσ ακτινοβολίασ που εκπζμπεται. 53

54 Εικόνα: Οριηόντιο διάγραμμα ακτινοβολίασ Εικόνα: Κατακόρυφο διάγραμμα ακτινοβολίασ 3.3 MIB520 Προγραμματιςτικι Πλακζτα Η αναπτυξιακι πλακζτα ΜΙΒ520 λειτουργεί ςαν ςτακμόσ βάςθσ (base station), για τα αςφρματα δίκτυα αιςκθτιρων, «ηευγαρϊνοντασ» πάνω τθσ οποιονδιποτε κόμβο. Ραρζχει τθ δυνατότθτα ISP (In System Programming) 54

55 προγραμματιςμοφ των IRIS motes και μπορεί να τροφοδοτείται με ρεφμα μζςω τθσ USB, οπότε και ανάβει το πράςινο Power OK led, εξαλείφοντασ τθν ανάγκθ για εξωτερικι πθγι ιςχφοσ. Ραρζχει δυνατότθτα ςειριακισ επικοινωνίασ με υπολογιςτι (host PC) με baudrate ςτα 57.6 ΚBd για τθν μεταφορά των δεδομζνων του δικτφου που καταλιγουν ςτον κόμβο του κεντρικοφ ςτακμοφ. Ο κόμβοσ αυτόσ, για παράδειγμα ζνα IRIS mote τθσ οικογζνειασ κόμβων MICA, ςυνδζεται με τον 51-pin connector του αναπτυξιακοφ. Επίςθσ, διακζτει τρία leds (κόκκινο, πράςινο, κίτρινο) Εικόνα: Θ προγραμματιςτικι πλακζτα ΜΙΒ520 που είναι ςτθν ουςία «κακρζφτθσ» των leds που υπάρχουν ςτο mote για οπτικοποίθςθ των διαδικαςιϊν που λαμβάνουν χϊρα ςτο εςωτερικό του. Το ISP led (κόκκινο) ανάβει όταν ο προγραμματιςμόσ του ςυνδεδεμζνου, ςτο αναπτυξιακό, κόμβου βρίςκεται ςε εξζλιξθ. Η ςφνδεςθ του MIB520 με τον υπολογιςτι, όπου βρίςκεται εγκατεςτθμζνο το λειτουργικό TinyOS, γίνεται μζςω USB. Με τθν εγκατάςταςθ ειδικϊν οδθγϊν (drivers), θ κφρα USB λειτουργεί ςαν δφο εικονικζσ ςειριακζσ κφρεσ COM. Μζςω τθσ πρϊτθσ εκτελείται ο προγραμματιςμόσ των κόμβων ςυνδζοντάσ τουσ ςτθν προγραμματιςτικι πλακζτα, ενϊ μζςω τθσ δεφτερθσ πραγματοποιείται θ ανταλλαγι δεδομζνων μεταξφ υπολογιςτι και του υπόλοιπου δικτφου WSN. 3.4 MTS420CC Sensor Board Αιςκθτζσ είναι διατάξεισ που μετατρζπουν μια φυςικι ποςότθτα ςε θλεκτρικό ςιμα κατάλλθλο για επεξεργαςία από θλεκτρονικζσ διατάξεισ. Το MTS420CC, είναι μια πλακζτα αιςκθτιρων που φζρει πζντε βαςικοφσ περιβαλλοντικοφσ αιςκθτιρεσ κερμοκραςίασ, υγραςίασ, πίεςθσ, ζνταςθσ φωτόσ, επιτάχυνςθσ και επιπλζον μια μονάδα δζκτθ GPS, κάτι που το κακιςτά ιδανικό για χριςθ ςτθν παροφςα εργαςία. Οι παραπάνω αιςκθτζσ λειτουργοφν με χαμθλι τάςθ και προορίηονται για τθν παρατιρθςθ φυςικϊν φαινομζνων και όχι μόνο. Οι δυνατότθτεσ που προςφζρει θ πλακζτα MTS420CC επιτρζπουν μια ευρεία γκάμα εφαρμογϊν που κυμαίνονται από ζνα απλό μετεωρολογικό ςτακμό ςε ζνα πλιρεσ δίκτυο παρακολοφκθςθσ του περιβάλλοντοσ. Το sensor board αυτό χρθςιμοποιεί τθ 55

56 Εικόνα: (Αριςτερά) Σο sensor board MTS420CC όπου διακρίνεται θ μονάδα GPS ςτο κζντρο. (Δεξιά) χθματικι απεικόνιςθ τθσ μορφισ ενόσ κόμβου IRIS ςυνδεδεμζνο με ζνα MTS420CC. τελευταία γενιά των αποδοτικϊν, ενεργειακά, ψθφιακϊν αιςκθτϊν που είναι ολοκλθρωμζνα κυκλϊματα βαςιςμζνα ςε πλακζτα (IC-based and board mount). Ζτςι παρζχει εκτεταμζνθ διάρκεια ηωισ τθσ μπαταρίασ. Η μονάδα GPS, που φζρει θ ςυγκεκριμζνθ πλακζτα με τουσ αιςκθτζσ, μπορεί να χρθςιμοποιθκεί για εντοπιςμό τθσ κζςθσ των κόμβων οι οποίοι μπορεί να είναι τοποκετθμζνοι ςε δυςπρόςιτα περιβάλλοντα αλλά και για τθν παρακολοφκθςθ τθσ πορείασ οχθμάτων, ςκαφϊν κακϊσ και άγριων ηϊων. Η τροφοδοςία όλων των αιςκθτϊν και θ επικοινωνία με αυτοφσ ελζγχεται μζςω δφο αναλογικϊν, οκταδικϊν διακοπτϊν τφπου ADG715BRU. Με κατάλλθλο προγραμματιςμό του διακόπτθ δίνεται τροφοδοςία μόνο ςε όςουσ αιςκθτζσ είναι απαραίτθτο. Το υπόλοιπο χρονικό διάςτθμα που δεν εκτελοφν κάποια εργαςία παραμζνουν ανενεργοί χωρίσ τροφοδοςία. Οι αιςκθτζσ πάνω ςτο sensor board ζχουν αρχικι ρφκμιςθ να είναι απενεργοποιθμζνοι. Αυτι θ ςχεδίαςθ εξοικονομεί ςθμαντικό ποςό ενζργειασ κακϊσ μειϊνονται οι απϊλειεσ από ρεφματα διαρροισ. Το GPS module που χρθςιμοποιείται ςτθ πλακζτα MTS420CC είναι το LEA- 4A, τθσ εταιρείασ ublox, που κεωρείται πωσ δίνει αρκετά ικανοποιθτικι ακρίβεια ςε μικρι κατανάλωςθ ρεφματοσ. Η ζξοδόσ του ςυνδζεται ςτθ ςειριακι USART1 διεπαφι του κόμβου (mote). Επίςθσ για τθν ςωςτι λειτουργία του δζκτθ GPS είναι απαραίτθτθ θ ςφνδεςθ ςτο sensor board μιασ εξωτερικισ ειδικισ κεραίασ, θ οποία να μπορεί να ςυλλζγει τα εξαςκενθμζνα δορυφορικά ςιματα. Το GPS module παρζχει ςτθ κεραία το απαιτοφμενο ρεφμα για να λειτουργιςει. Τζλοσ, θ ενεργοποίθςθ του γίνεται από τθ μονάδα U7. Εικόνα: Περίλθψθ των χαρακτθριςτικϊν του GPS module ςτο MTS420CC 56

57 Εικόνα: χζδιο ελζγχου ενζργειασ και ςθμάτων ςτο MTS420CC 57

58 ΚΕΦΑΛΑΙΟ 4 ο Λειτουργικό φςτθμα Operating System 4.1 Ειςαγωγι Ππωσ ζχει ιδθ αναφερκεί ςε περαςμζνα κεφάλαια, όλοι οι κόμβοι αποτελοφνται από τα ίδια περίπου βαςικά υλικά ςυςτατικά. Αιςκθτιρεσ, μικροεπεξεργαςτισ, μνιμθ, πομποδζκτθσ και μπαταρία ςυνκζτουν τον puzzle μιασ μονάδασ ενόσ WSN. Η ευελιξία των κόμβων αυτϊν δίνει τθ δυνατότθτα να προγραμματιςτοφν από το χριςτθ για να μποροφν να υλοποιιςουν ζνα μεγάλο πλικοσ εφαρμογϊν. Για να υπάρχει όμωσ μια αποδοτικι οργάνωςθ των λειτουργιϊν του κάκε κόμβου απαιτείται ζνα λειτουργικό ςφςτθμα που να μπορεί να ελζγχει το υλικό, να προςφζρει μια αφθρθμζνθ απεικόνιςι του ςτο λογιςμικό τθσ εφαρμογισ και γενικά να γεφυρϊνει τθν απόςταςθ ανάμεςα ςτισ εφαρμογζσ και ςτο χρθςιμοποιοφμενο υλικό. 4.2 χεδίαςθ Λειτουργικοφ υςτιματοσ για WSN Απαιτιςεισ Τα WSN λόγω τθσ ιδιομορφίασ των εφαρμογϊν που εκτελοφν και των περιοριςμζνων πόρων ςυςτιματοσ απαιτοφν μια διαφορετικι προςζγγιςθ ςχεδιαςμοφ του λειτουργικοφ τουσ ςυςτιματοσ ςε ςχζςθ με τα ςυμβατικά ιδθ υπάρχοντα λειτουργικά. Σε ζνα ςυμβατικό λειτουργικό ςφςτθμα (Operating System, OS) θ εκτζλεςθ πολλϊν διεργαςιϊν γίνεται δυνατι με τθν κατανομι μνιμθσ (ςτοίβα) για κακεμία ξεχωριςτά. Το περιοριςμζνο μζγεκοσ μνιμθσ ςε ζναν κόμβο όμωσ δεν επαρκεί για μια τζτοια διαδικαςία. Κάποιεσ εφαρμογζσ WSN ζχουν απαίτθςθ πραγματικοφ χρόνου (soft/hard real time) με αποτζλεςμα θ όποια εναλλαγι ςτθν εκτζλεςθ των διεργαςιϊν να ζχει ωσ αποτζλεςμα το χάςιμο δεδομζνων. Τζλοσ, ζνα ςυμβατικό OS, εξ οριςμοφ ζχει φτιαχτεί για να αξιοποιεί το ςφνολο των δυνατοτιτων του υλικοφ για τθν καλφτερθ εκτζλεςθ των προγραμμάτων, κάτι που είναι λογικό για ζναν υπολογιςτι με τροφοδοςία από το δίκτυο. Μια τζτοια προςζγγιςθ όμωσ κα ιταν εξαιρετικά ενεργοβόρα για ζνα ςφςτθμα που τροφοδοτείται από δφο μικρζσ μπαταρίεσ. Οι προχποκζςεισ που πρζπει να πλθροί ζνα λειτουργικό ςφςτθμα για αςφρματα δίκτυα αιςκθτϊν είναι: Μικρι ζκταςθ κώδικα. Δεδομζνθσ τθσ περιοριςμζνθσ μνιμθσ ενόσ κόμβου, ο πυρινασ του λειτουργικοφ πρζπει να υλοποιείται από τον ελάχιςτο δυνατό κϊδικα. Παροχι μθχανιςμοφ διαχείριςθσ πόρων ςυςτιματοσ και ενζργειασ. Ο χρόνοσ επεξεργαςτι και θ μνιμθ πρζπει να κατανζμονται κατάλλθλα, ζτςι 58

59 ϊςτε να διαςφαλίηεται θ ομαλι λειτουργία και θ τιρθςθ αυςτθρισ προτεραιότθτασ ςτθν εκτζλεςθ των διεργαςιϊν. Η διαχείριςθ ενζργειασ πρζπει να ζχει ωσ ςτόχο τθν μεγιςτοποίθςθ τθσ διάρκειασ ηωισ ενόσ κόμβου. Αυτό επιτυγχάνεται με ςωςτι χριςθ των ενεργειακϊν καταςτάςεων του επεξεργαςτι αλλά και των άλλων ολοκλθρωμζνων του κόμβου όπωσ το radio. Παροχι διεπαφισ προγράμματοσ εφαρμογισ. Δυνατότθτα επαναπρογραμματιςμοφ. Σε ζνα WSN είναι ςυχνό φαινόμενο ο επαναπροςδιοριςμόσ τθσ λειτουργίασ ενόσ κόμβου, είτε όςον αφορά ςτθ ςυλλογι δεδομζνων και τθ ςυμπεριφορά του ςτο δίκτυο μιασ και εγκακίςτανται ςε αρκετά δυναμικά περιβάλλοντα, είτε όςον αφορά ςτθν προςαρμογι τθσ κατανάλωςθσ ενζργειασ. 4.3 Λειτουργικό φςτθμα TinyOS Υπάρχουν πολλά λειτουργικά ςυςτιματα για WSN (MANTIS, Contiki, κ.α.), το πιο διαδεδομζνο όμωσ, με το οποίο και κα αςχολθκοφμε, είναι το TinyOS. Το tinyos είναι από τα πρϊτα λειτουργικά ςυςτιματα που ςχεδιάςτθκαν ειδικά για αςφρματα δίκτυα αιςκθτιρων και είναι open source. Η ανάπτυξι του ξεκίνθςε ςτο πανεπιςτιμιο του Berkeley τθσ Καλιφόρνιασ και θ πρϊτθ του ζκδοςθ κυκλοφόρθςε το 2000 και υποςτθρίηει διάφορεσ πλατφόρμεσ υλικοφ. Μερικζσ από αυτζσ είναι θ MicaZ και IRIS τθσ εταιρίασ Crossbow, θ imote τθσ Intel και θ Eyes που είναι αποτζλεςμα ςυνεργαςίασ Ευρωπαϊκϊν πανεπιςτθμίων και εταιριϊν. Το TinyOS βρίςκει εφαρμογι ςε πολλοφσ τφπουσ επεξεργαςτϊν από 8-bit αρχιτεκτονικι και 2 KB RAM, μζχρι επεξεργαςτζσ 32-bit και μνιμθσ μεγαλφτερθσ των 32 ΜΒ. Βζβαια, οι περιοριςμζνοι πόροι που είναι προσ διάκεςθ ςε ζνα κόμβο WSN, όπωσ είναι θ ενζργεια, οδθγοφν ςτθ χριςθ περιςςότερο 8-bit ι 16-bit μικροελεγκτϊν. Γι αυτό το λόγο τα δίκτυα αιςκθτϊν τείνουν να είναι ςε υψθλό βακμό βελτιςτοποιθμζνα. Η ανάπτυξθ των εφαρμογϊν TinyOS γίνεται ςε μια ειδικι γλϊςςα που αποτελεί διάλεκτο τθσ C, προςαρμοςμζνθ ςτισ απαιτιςεισ και ςτουσ περιοριςμοφσ των WSN, τθν nesc (Network Embedded system C). Ο compiler τθσ nesc κακϊσ και άλλα απαραίτθτα εργαλεία για τθ γλϊςςα είναι γραμμζνα ςε C. Το λειτουργικό περιζχει επίςθσ ενςωματωμζνεσ κάποιεσ εφαρμογζσ ςε java. Η εγκατάςταςι του γίνεται ςε ζναν υπολογιςτι (host PC) με λειτουργικό Linux ι Windows με τθν προςκικθ του Unix προςομοιωτι, Cygwin. Ο προγραμματιςμόσ των κόμβων και θ ςυλλογι δεδομζνων (data collection) γίνεται μζςω μιασ USB κφρασ του υπολογιςτι με χριςθ του αναπτυξιακοφ MIB520. Η ζκδοςθ του tinyos που χρθςιμοποιιςαμε ςτθν εργαςία μασ είναι θ Η ζκδοςθ αυτι είναι αρκετά καινοφρια και φζρει πολλζσ αλλαγζσ ςε ςχζςθ με παλιότερεσ εκδόςεισ. Αυτό ζχει ωσ αποτζλεςμα πολλά ςτοιχεία τθσ να είναι ακόμα ςε πειραματικό ςτάδιο και κομμάτια κϊδικα εφαρμογϊν που υπάρχουν open source να χρειάηονται εξαντλθτικό testing πριν να χρθςιμοποιθκοφν ςτο πραγματικό κόςμο. Στθν ιςτοςελίδα του λειτουργικοφ, αναφζρεται ότι πάνω από 500 ερευνθτικζσ ομάδεσ αςχολοφνται με πλατφόρμεσ που τρζχουν το TinyOS ςυνειςφζροντασ ςτθν ανάπτυξθ κϊδικα και ςτισ προςομοιϊςεισ πρωτοκόλλων και αλγορίκμων. 59

60 4.3.1 Μοντζλο Λειτουργίασ Με τον όρο IRIS motes τθσ εταιρίασ Crossbow, εννοοφμε μια γενικι κατθγορία τεχνολογιϊν με ςτόχο να ζχουμε μικροφσ, ανκεκτικοφσ και ευζλικτουσ αιςκθτιρεσ που εφκολα εφαρμόηονται ςε μια ευρεία περιοχι. Τα motes «τρζχουν» το λειτουργικό ςφςτθμα TinyOS το οποίο διαχειρίηεται τθν κατανάλωςθ ενζργειασ και τθν αςφρματθ επικοινωνία μζςω του radio chip (radio networking). Φτιάχτθκε για να δίνει τθ δυνατότθτα ςτο χριςτθ να εςτιάςει ςτο γράψιμο εφαρμογϊν για ςυλλογι και αλλθλεπίδραςθ με τα δεδομζνα των αιςκθτιρων. Ο βαςικόσ ςτόχοσ πίςω από το TinyOS είναι θ ελαχιςτοποίθςθ τθσ ενζργειασ που καταναλϊνεται. Αυτι είναι και θ κφρια διαφορά του από τα άλλα λειτουργικά ςυςτιματα, κακϊσ επικεντρϊνεται ςε άκρωσ χαμθλισ κατανάλωςθσ (low-power) λειτουργία (διακζτει μθχανιςμοφσ για power saving). Γι αυτό και τα ςτοιχεία του είναι γφρω από τθν λογικι «hurry up and sleep». Τον περιςςότερο καιρό το λειτουργικό ςφςτθμα διατθρεί τουσ κόμβουσ ςε μια κατάςταςθ χαμθλισ ενζργειασ (sleep mode). Ο ςχεδιαςμόσ του TinyOS προςανατολίηεται ςτθν ικανοποίθςθ τριϊν απαιτιςεων: τθν εγγυθμζνθ ροι δεδομζνων διαμζςου των εξαρτθμάτων του υλικοφ, τθσ διαίρεςθσ του υλικοφ ςε επιμζρουσ δομικά ςτοιχεία (component based architecture) και τθσ εκτζλεςισ τουσ με το μικρότερο δυνατό κόςτοσ ιςχφοσ, τόςο από πλευράσ επεξεργαςτι όςο και από μνιμθ. Για τθν επίτευξθ αυτϊν των απαιτιςεων το λειτουργικό ςφςτθμα ακολουκεί μια λογικι βαςιςμζνθ ςε ςυμβάντα (event driven). Στο TinyOS όταν ζνα ςυμβάν εμφανιςτεί, οι διεργαςίεσ που ςχετίηονται με αυτό εκτελοφνται με μεγάλθ προτεραιότθτα και γριγορα, ενϊ μόλισ ολοκλθρωκοφν ο επεξεργαςτισ τίκεται ςε κατάςταςθ SLEEP χωρίσ να ψάχνει για νζα ςυμβάντα, εξοικονομϊντασ ζτςι ενζργεια Αρχιτεκτονικι - Δομι του TinyOS Ππωσ είπαμε και παραπάνω, θ γλϊςςα προγραμματιςμοφ που χρθςιμοποιείται ςτο TinyOS είναι θ nesc. Το ίδιο το ςφςτθμα TinyOS, οι βιβλιοκικεσ και οι εφαρμογζσ του είναι γραμμζνα ςε nesc, που είναι μια γλϊςςα για τον προγραμματιςμό δομθμζνων βαςιςμζνων ςε «αντικείμενα» (component-based) εφαρμογϊν. Ζχει παρόμοιο ςυντακτικό με τθν C αλλά υποςτθρίηει και μθχανιςμοφσ για δόμθςθ, ονομαςία και ςφνδεςθ (linking together) «αντικειμζνων» λογιςμικοφ (software components) για τθ δθμιουργία ςκεναρϊν δικτφων ενςωματωμζνων ςυςτθμάτων. Ο ςτόχοσ είναι να επιτρζπεται ςτουσ ςχεδιαςτζσ εφαρμογϊν να φτιάχνουν components που κα μποροφν εφκολα να ςυνκζςουν ολοκλθρωμζνα ςυςτιματα και ακόμα να εκτελοφν εκτενζςτερο ζλεγχο κατά τθ μεταγλϊττιςθ. Μια εφαρμογι nesc μπορεί, λοιπόν, να αποτελείται από ζνα ι περιςςότερα components που είναι ςυνδεδεμζνα μεταξφ τουσ δθμιουργϊντασ ζνα εκτελζςιμο, γι αυτό και καλοφνται βαςικό δομικό ςτοιχείο τθσ γλϊςςασ. Τα components, πρακτικά, είναι, μια λίςτα από ςυναρτιςεισ και ςυμβάντα. Ζνα component μπορεί να παρζχει ι να χρθςιμοποιεί διεπαφζσ (interfaces). Αυτά τα interfaces είναι ο μόνοσ τρόποσ για πρόςβαςθ ςτο component και είναι αμφίδρομα. Ζνα interface δθλϊνει ζνα ςετ 60

61 από ςυναρτιςεισ που καλοφνται εντολζσ (commands) και ζνα άλλο ςετ από ςυναρτιςεισ που καλοφνται ςυμβάντα (events). Το ςετ εντολϊν ορίηεταιεφαρμόηεται από τον πάροχο του interface, ενϊ το ςετ των ςυμβάντων ορίηεταιεφαρμόηεται από τον χριςτθ του interface. Ζνα μόνο component μπορεί να παρζχει ι να χρθςιμοποιεί πολλαπλζσ διεπαφζσ και πολλαπλά ςτιγμιότυπα (instances) τθσ ίδιασ διεπαφισ (interface). Υπάρχουν δφο τφποι component ςτθν nesc τα modules και τα configurations για τα οποία γίνεται αναφορά ςτθ ςυνζχεια. Η αρχιτεκτονικι του TinyOS περιλαμβάνει ζνα χρονοπρογραμματιςτι (scheduler) και ζνα ςφνολο από διαβακμιςμζνα components που αποτελοφν το software. Στθν ουςία, θ ςτοίβα αρχιτεκτονικισ του TinyOS είναι μια ςτοίβα από components, θ ζννοια των οποίων αντικακιςτά, κατά ζνα μζροσ, τθν ζννοια τθσ διεργαςίασ ςτα ςυμβατικά λειτουργικά ςυςτιματα. Τα περιςςότερα είναι modules λογιςμικοφ, όμωσ αυτά που ανικουν ςτο χαμθλότερο μζροσ τθσ ςτοίβασ χρθςιμοποιοφνται κυρίωσ ςαν απλά interfaces για το υλικό του ςυςτιματοσ. Επίςθσ, Εικόνα: τοίβα αρχιτεκτονικισ TinyOS ςε αντίκεςθ με τθν αρχιτεκτονικι των ςυμβατικϊν λειτουργικϊν, εδϊ ζννοιεσ όπωσ πυρινασ, εικονικι μνιμθ, δυναμικι κατανομι μνιμθσ δεν ορίηονται. Αφοφ δεν υπάρχει πυρινασ θ διαχείριςθ του υλικοφ γίνεται άμεςα, ο χϊροσ διευκφνςεων είναι γραμμικόσ και θ μνιμθ κατανζμεται ςτατικά κατά τθ διάρκεια τθσ μεταγλϊττιςθσ. Τζλοσ, όταν λζμε ότι ζνασ κόμβοσ WSN τρζχει το TinyOS εννοοφμε ότι ζχει εγκατεςτθμζνθ ςτθ flash μνιμθ του μια binary εκτελζςιμθ εικόνα με τισ βιβλιοκικεσ του λειτουργικοφ ςυνδεδεμζνεσ με τθν εφαρμογι που πρζπει να εκτελεςτεί. Η εικόνα αυτι αποτελεί τθν εφαρμογι TinyOS. Εξάλλου το να εγκαταςτιςουμε το TinyOS ςε ζναν κόμβο δεν ζχει νόθμα κακϊσ από μόνο του δεν εκτελεί κάποια λειτουργία, οφτε ζχει κάποιο user interface. Η αρχιτεκτονικι που χρθςιμοποιεί το TinyOS είναι βαςιςμζνθ ςε ςυμβάνταγεγονότα (event-driven) και όχι ςε νιματα (threads). Αυτζσ οι αρχιτεκτονικζσ αποτελοφν ίςωσ τθν καλφτερθ λφςθ ςτθν επίτευξθ υψθλισ απόδοςθσ ςε αντίςτοιχεσ εφαρμογζσ που βαςίηονται ςε παρακολοφκθςθ γεγονότων. Κάκε γεγονόσ εξυπθρετείται από ζναν χειριςτι γεγονότων (event handler). Αυτόσ είναι υπεφκυνοσ για τθν προϊκθςθ τθσ διεργαςίασ, που αφορά το ςυγκεκριμζνο κάκε φορά γεγονόσ, ςτον χρονοπρογραμματιςτι διεργαςιϊν (scheduler). Αυτόσ χρθςιμοποιεί μια ςτοίβα με ζναν απλό FIFO μθχανιςμό, ςτθν οποία τοποκετοφνται τα γεγονότα και οι πιο πολφπλοκεσ διεργαςίεσ (tasks) προσ εκτζλεςθ, και θ φιλοςοφία λειτουργίασ του είναι γενικά χωρίσ διακοπζσ (non-preemptive). Εκεί γίνεται ζνασ διαχωριςμόσ, κακϊσ τα γεγονότα εξυπθρετοφνται άμεςα και γριγορα ενϊ πιο πολφπλοκεσ διεργαςίεσ (tasks) εκτελοφνται χωρίσ να διακόπτονται, με εξαίρεςθ από γεγονότα 61

62 μεγαλφτερθσ προτεραιότθτασ που ςυνικωσ ζχουν τον χαρακτθριςμό «αςφγχρονα». Πταν θ ςτοίβα εκτζλεςθσ αδειάςει, ο scheduler δίνει εντολι ςτον επεξεργαςτι να ειςζλκει ςε κατάςταςθ SLEEP. Τα περιφερειακά όμωσ, παραμζνουν ενεργά, οπότε μια διακοπι μπορεί να επανεκκινιςει τθν όλθ διαδικαςία. Πςον αφορά ςτθ δομι του λειτουργικοφ TinyOS, τα components ικανοποιοφν ςε μεγάλο βακμό τθν απαίτθςθ για μια αρκετά δομθμζνθ αρχιτεκτονικι λογιςμικοφ. Κάκε component αποτελείται από τζςςερα τμιματα: Ζναν χειριςτι εντολϊν (command handler) Ζναν χειριςτι γεγονότων (event handler) Μια ποςότθτα μνιμθσ (frame) Ζνα ςφνολο από δυνατζσ διεργαςίεσ (tasks) Η μνιμθ χρθςιμοποιείται για τθν αποκικευςθ τθσ εςωτερικισ κατάςταςθσ του component, ενϊ οι διεργαςίεσ και οι χειριςτζσ εντολϊν και γεγονότων εκτελοφνται με βάςθ το περιεχόμενο αυτισ τθσ μνιμθσ. Επίςθσ το κάκε component δθλϊνει τισ Εικόνα: Δομι ενόσ component εντολζσ που χρθςιμοποιεί και τα γεγονότα που δθμιουργεί. Με αυτόν τον τρόπο δθμιουργοφνται επίπεδα ςτρϊματα από components με αυτά των υψθλότερων επιπζδων να χρθςιμοποιοφν κάκε φορά εντολζσ για κλιςθ λειτουργιϊν που παρζχονται από κατϊτερων επιπζδων components και τα τελευταία να δθμιουργοφν γεγονότα προσ τα πρϊτα. Ζτςι, τα interfaces που ορίηουν τισ εντολζσ και τα γεγονότα που χρθςιμοποιοφνται κατά τθν αλλθλεπίδραςθ των components μεταξφ τουσ, από επίπεδο ςε επίπεδο, δικαιολογοφν τον χαρακτθριςμό τουσ ωσ «αμφίδρομα». Τα επίπεδα των των components είναι τα: Αφθρθμζνθσ απεικόνιςθσ υλικοφ (hardware abstractions): Εδϊ ανικουν τα components χαμθλοφ επιπζδου. Σε αυτά γίνεται θ αποτφπωςθ του hardware, όπωσ οι ςυςκευζσ ειςόδου/εξόδου, ο πομποδζκτθσ και οι αιςκθτιρεσ. φνκετου υλικοφ (synthetic hardware): Σε αυτά τα components αποτυπϊνεται θ ςυμπεριφορά προχωρθμζνων λειτουργιϊν του υλικοφ. Τψθλοφ επιπζδου λογιςμικό (high level software): Components που περιζχουν τθν εφαρμογι που ζχει αναπτφξει ο χριςτθσ. Στα πλαίςια τθσ δομισ των δομικϊν ςυςτατικϊν του TinyOS, των component, προςεγγίηουμε παρακάτω αναλυτικότερα τα ςτοιχεία που το αποτελοφν. 62

63 Commands Οι εντολζσ είναι ςτθν πραγματικότθτα αιτιςεισ (requests) προσ τα components χαμθλότερου επιπζδου. Η εκτζλεςι τουσ είναι άμεςθ, χωρίσ διακοπι και για αυτό ολοκλθρϊνεται ςε πολφ μικρό χρονικό διάςτθμα. Ζχουν τθ δυνατότθτα να καλοφν άλλεσ εντολζσ χαμθλοφ επιπζδου, tasks, αλλά δε μποροφν να ςθματοδοτιςουν events. Μαηί με τα τελευταία, αποτελοφν τον μθχανιςμό επικοινωνίασ μεταξφ των components. Events Τα γεγονότα (events) ςθματοδοτοφν τθν λιξθ μιασ λειτουργίασ. Μια εντολι, για παράδειγμα, μπορεί να ηθτιςει από ζναν αιςκθτιρα τθν ζναρξθ ςυλλογισ δεδομζνων. Ζνα event κα προκλθκεί μόλισ ο αιςκθτιρασ ολοκλθρϊςει τθ ςυλλογι μετριςεων και είναι ζτοιμοσ να τισ ςτείλει ςτισ ειςόδουσ με τισ οποίεσ είναι ςυνδεδεμζνοσ. Ζνα event μπορεί να εμφανιςτεί και αςφγχρονα εξαιτίασ μιασ διακοπισ (interrupt) του υλικοφ. Οφτε τα events υπόκεινται ςε διακοπζσ. Οι περιςςότερεσ λειτουργίεσ που ςχετίηονται με τουσ κόμβουσ WSN και με τα περιφερειακά τουσ είναι λειτουργίεσ που ολοκλθρϊνονται ςε δφο φάςεισ (split phase operations). Με χριςθ commands και events επιτυγχάνεται θ εκτζλεςθ τζτοιων λειτουργιϊν. Σε μια split phase διεργαςία το αίτθμα/command που αρχικοποιεί μια λειτουργία ικανοποιείται άμεςα. Στθ ςυνζχεια θ ολοκλιρωςθ του αιτιματοσ ςθματοδοτεί ζνα event. Τζλοσ, τα events ζχουν τθ δυνατότθτα να καλζςουν χαμθλοφ επιπζδου commands, tasks κακϊσ και να ςθματοδοτιςουν άλλα ανωτζρου επιπζδου events. Tasks Εξ οριςμοφ, τα commands/events δεν διακόπτονται και για αυτό δεςμεφουν πόρουσ ςυςτιματοσ. Επομζνωσ ο υπολογιςτικόσ τουσ φόρτοσ πρζπει να είναι ο ελάχιςτοσ δυνατόσ. Σκοπόσ τουσ εξάλλου είναι θ εκτζλεςθ βαςικϊν και απαραιτιτων για το ςφςτθμα λειτουργιϊν. Οτιδιποτε άλλο, εκτόσ από αυτά, εμπίπτει ςτθ δικαιοδοςία των tasks. Αυτά καλοφνται μζςα από commands ι events και ζχουν χαμθλότερθ προτεραιότθτα εκτζλεςθσ ςτθ ςτοίβα του scheduler. Ζνα task μπορεί μζςα ςτο ςϊμα του να καλζςει ζνα άλλο task, μια εντολι χαμθλοφ επιπζδου ι και να ςθματοδοτιςει ζνα event. Η εκτζλεςι του μπορεί να διακοπεί μόνο από κάποιο αςφγχρονο event. Τα tasks αντιπροςωπεφουν ζνα είδοσ παράλλθλθσ επεξεργαςίασ μζςα ςε ζνα component, ζτςι ζχουν πρόςβαςθ μόνο ςτα δεδομζνα που αφοροφν το ςυγκεκριμζνο component ςτο οποίο ανικουν. Frame - Πλαίςιο μνιμθσ Το πλαίςιο μνιμθσ είναι ςτακεροφ μεγζκουσ και κατανζμεται ςτατικά. Ορίηει τισ απαιτιςεισ ςε μνιμθ ενόσ component κατά τθ διάρκεια τθσ μεταγλϊττιςθσ και ζτςι εξαςφαλίηεται ότι δεν κα υπάρχουν overheads που είναι και το χαρακτθριςτικό πρόβλθμα τθσ δυναμικισ κατανομισ μνιμθσ. 63

64 4.4 Η γλϊςςα προγραμματιςμοφ NesC Η αρχικι ιδζα των ςχεδιαςτϊν του TinOS, ιταν να χρθςιμοποιθκεί θ C ςαν γλϊςςα προγραμματιςμοφ. Στθν πορεία όμωσ προζκυψε ότι για τθν ςωςτι υποςτιριξθ του μοντζλου λειτουργίασ του TinyOS, ιταν απαραίτθτθ θ δθμιουργία μιασ νζασ γλϊςςασ θ οποία ονομάςτθκε nesc (network embedded system C). Η nesc αποτελεί διάλεκτο τθσ C, όμωσ ωσ προσ τθ λειτουργία τθσ μοιάηει αρκετά ςτθν Java κυρίωσ εξαιτίασ τθσ λογικισ ςυνεργαηόμενων αντικειμζνων, που το ζνα χρθςιμοποιεί λειτουργίεσ του άλλου. Ζτςι, για τθν δθμιουργία μιασ λειτουργικισ εφαρμογισ ο κϊδικασ πολλϊν software components «ςυνδζεται» με μια διαδικαςία που καλείται wiring. Ο προγραμματιςτισ κάνει wiring για να «χτίςει» μια εφαρμογι από components γράφοντασ wiring statements. Κάκε ζνα τζτοιο statement ςυνδζει ζνα interface που χρθςιμοποιείται από ζνα component με ζνα άλλο interface που παρζχεται από κάποιο άλλο component. Κάνοντασ ςαφισ αυτζσ τισ wiring statements, ελαχιςτοποιείται θ απαίτθςθ για χριςθ δυναμικϊν μθχανιςμϊν, που υπάρχουν ςτθν γλϊςςα C, (για παράδειγμα function pointers, virtual methods, κ.α.) για να εκφραςτοφν ζννοιεσ όπωσ callbacks από μια υπθρεςία προσ ζναν client. Με αυτόν τον τρόπο, κατά ςυνζπεια, εξοικονομείται πολφτιμθ μνιμθ RAM. Η nesc, επομζνωσ, είναι μια γλϊςςα προγραμματιςμοφ που χρθςιμοποιείται για τθν υλοποίθςθ εφαρμογϊν που βαςίηονται ςτο λειτουργικό ςφςτθμα TinyOS. Οι βαςικζσ ζννοιεσ που τθν περιγράφουν είναι οι εξισ: Διαχωριςμόσ μεταξφ ςχεδίαςθσ και ςφνκεςθσ. Ρολλά τμιματα κϊδικα (components) μποροφν να αναπτυχκοφν ξεχωριςτά. Από μόνα τουσ υπάρχει μεγάλθ πικανότθτα να μθν είναι λειτουργικά. Η ςφνκεςθ αυτϊν των επιμζρουσ τμθμάτων ςε μια εφαρμογι γίνεται με τθ διαδικαςία του wiring όπωσ είδαμε. Το κάκε component κακορίηει δφο πεδία κϊδικα, ζνα για τισ προδιαγραφζσ του όπου και ορίηονται οι διεπαφζσ που χρθςιμοποιεί για να επικοινωνεί με άλλα components και ζνα πεδίο για τθν υλοποίθςι του. Μζςω των διεπαφϊν αυτϊν, νιματα ελζγχου μποροφν να περάςουν ςε ζνα component, τα οποία προζρχονται είτε από ζνα task, είτε από μια διακοπι υλικοφ. Προδιαγραφζσ τθσ ςυμπεριφοράσ των components με βάςθ τισ διεπαφζσ. Είδαμε ότι οι διεπαφζσ (interfaces) μποροφν να παρζχονται ι να χρθςιμοποιοφνται από τα components. Αυτζσ που χρθςιμοποιοφνται εκφράηουν τθ λειτουργία που χρειάηεται ζνα component για να εκτελεςτεί, ενϊ αυτζσ που παρζχονται εκφράηουν τθ λειτουργία που παρζχει ζνα component ςε ζνα άλλο το οποίο τθ χρθςιμοποιεί. Οι διεπαφζσ είναι αμφίδρομεσ (bidirectional). Τα interfaces κακορίηουν ζνα ςφνολο λειτουργιϊν που υλοποιοφνται από τα components που παρζχουν τα ςυγκεκριμζνα interfaces (εντολζσ - commands) και ζνα ςφνολο που υλοποιοφνται από components που χρθςιμοποιοφν τα interfaces αυτά (ςυμβάντα - events). Αυτό επιτρζπει ςε μια απλι διεπαφι να αντιπροςωπεφει ζναν αφθρθμζνο οριςμό μιασ ςφνκετθσ αλλθλεπίδραςθσ μεταξφ των components. Τα interfaces αποτελοφν αναπόςπαςτο κομμάτι ενόσ προγράμματοσ ςε nesc. Σα components ςυνδζονται μεταξφ τουσ μζςω των διεπαφών τουσ. Η nesc είναι ςχεδιαςμζνθ ζτςι ϊςτε ο κϊδικασ να παράγεται από τθ μεταγλϊττιςθ 64

65 (compile) ολοκλθρωμζνων προγραμμάτων και όχι κομματιϊν. Αυτό επιτρζπει καλφτερο ςχεδιαςμό και ανάλυςθ κϊδικα. Ζνα παράδειγμα είναι θ ανίχνευςθ των data races κατά τθ διάρκεια του compile των components ςε ζναν ενιαίο κϊδικα. Η δομι ενόσ κϊδικα εφαρμογισ ςε nesc αποτελείται από διεπαφζσ (interfaces) και επιμζρουσ τμιματα κϊδικα, τα components. Τα τελευταία διακρίνονται ςε υπομονάδεσ (modules) και ςε ςυνκζςεισ τμθμάτων (configurations). Τα modules είναι components που υλοποιοφν ι χρθςιμοποιοφν ζνα ι περιςςότερα interfaces. Αποτελείται από δφο πεδία, το signature block και το implementation. Στο signature δθλϊνονται τα interfaces που χρθςιμοποιεί ι και παρζχει το ςυγκεκριμζνο component. Μζςα ςτον κϊδικα του module, ςτο πεδίο implementation, βρίςκεται ο Εικόνα: Δομι μιασ εφαρμογισ ςε nesc πυρινασ μιασ εφαρμογισ του TinyOS. Εδϊ κακορίηεται θ λειτουργία που κζλουμε να εκτελζςει το πρόγραμμά μασ. Τα modules αποτελοφν τθ βαςικι δομικι μονάδα τθσ εφαρμογισ μασ, ςτθν οποία και υλοποιείται θ εκτελζςιμθ λογικι τθσ. Οι ςυναρτιςεισ και οι μεταβλθτζσ που μπορεί να χρθςιμοποιιςει ζνα module είναι μόνο αυτζσ που ζχουν οριςτεί ςτο δικό του τοπικό scope. Με λίγα λόγια, δθλαδι, ζνα module δεν μπορεί από μόνο του να καλζςει ζνα άλλο. Αυτό γίνεται με το wiring το οποίο υλοποιείται από ζνα ξεχωριςτό τφπο component που καλείται configuration. Ζνα configuration όςον αφορά ςτθν βαςικι του δομι μοιάηει με ζνα module. Χωρίηεται ςε πεδίο για specification (signature) και για implementation. Στο πρϊτο πεδίο ονομάηονται τα components που πρόκειται να γίνουν wire. Ζνα configuration πρζπει να δθλϊνει ζνα component πριν το κάνει wire, το οποίο υλοποιείται ςτο πεδίο implemetation. Συντακτικϊσ, τα configuration είναι πολφ απλά. Διακζτουν μόλισ τρεισ τελεςτζσ. «Δεξί βζλοσ» ( ), «αριςτερό βζλοσ» ( ) και «ίςον» (=). Οι δφο πρϊτοι εξυπθρετοφν το βαςικό wiring, που είναι ουςιαςτικά μια διαδικαςία αντιςτοίχθςθσ interface ενόσ component με interface ενόσ άλλου component. Η κατεφκυνςθ είναι πάντα από τθν πλευρά του χριςτθ προσ αυτι του παρόχου. Με αυτόν τον τρόπο ζνα module που χρθςιμοποιεί ζνα interface, βρίςκει το module ςτο οποίο υλοποιείται το interface αυτό, μζςω του wiring statement. 65

66 4.4.1 Async ςυναρτιςεισ και atomic statements Είδαμε ςτθν ενότθτα για τα tasks, ότι γενικά θ εκτζλεςι τουσ είναι μθ διακοπτόμενθ εκτόσ των περιπτϊςεων όπου ζχουμε εμφάνιςθ αςφγχρονων events, λόγω διακοπισ που προζρχεται απευκείασ από το hardware (hardware interrupt handlers). Σε αυτι τθ περίπτωςθ το τρζχον task διακόπτεται και εκτελείται το event. Οι ςυναρτιςεισ που ςχετίηονται με hardware interrupt handlers δθλϊνονται με τθ δεςμευμζνθ λζξθ async μπροςτά. Αυτοφ του είδουσ όμωσ θ αςφγχρονθ εκτζλεςθ, μπορεί να προκαλζςει προβλιματα ςε τμιματα κϊδικα, όπου υπάρχουν εντολζσ που επεξεργάηονται μεταβλθτζσ ελζγχου ι εντολζσ που καταχωροφν ςε μεταβλθτζσ λθφκζντα δεδομζνα. Τθ λφςθ ςε τζτοιεσ περιπτϊςεισ τθν δίνει θ χριςθ τθσ διλωςθσ atomic πριν από κάκε εντολι που κζλουμε να τρζξει χωρίσ να διακοπεί ότι και αν γίνει. Βζβαια, τα atomic statements πρζπει να χρθςιμοποιοφνται με προςοχι γιατί κατά τθν εκτζλεςι τουσ απενεργοποιοφνται οι διακοπζσ, οπότε θ άςκοπθ χριςθ τουσ προκαλεί χάςιμο κφκλων του επεξεργαςτι. 66

67 ΚΕΦΑΛΑΙΟ 5 ο Τλοποίθςθ Εφαρμογισ 5.1 Ειςαγωγι Από τθ ςτιγμι που γίνεται θ επιλογι του υλικοφ που κα χρθςιμοποιθκεί, είμαςτε ζτοιμοι να ξεκινιςουμε ςτο ςχεδιαςμό και ςτθν υλοποίθςθ τθσ εφαρμογισ μασ. Η χριςθ μιασ πλατφόρμασ για ςχθματιςμό WSN δεν κακορίηει μόνο τον μικροεπεξεργαςτι αλλά και το επιπρόςκετο υλικό που κάνει τον κάκε κόμβο χριςιμο και λειτουργικό (μονάδα πομποδζκτθ, μνιμθ, περιφερειακά) κακϊσ και το λειτουργικό του. Η επιλογι των motes IRIS, μοντζλο XM2110CA, ορίηει μια πλατφόρμα που λειτουργεί μα βάςθ το TinyOS. Για να μπορζςουμε να αναπτφξουμε εφαρμογζσ βαςιςμζνεσ ςτο TinyOS πρζπει πρϊτα από όλα να το εγκαταςτιςουμε ςτον υπολογιςτι (host PC) με τον οποίο ο κόμβοσ-βάςθ του αςφρματου δικτφου μασ κα επικοινωνεί μζςω USB. Για τθν εγκατάςταςθ του περιβάλλοντοσ TinyOS προτιμικθκε υπολογιςτισ με λειτουργικό LINUX κυρίωσ λόγω τθσ πιο εφκολθσ χριςθσ τουσ και τθσ ερευνθτικισ τουσ υπόςταςθσ. Στθ διάκεςι μασ υπιρχε υπολογιςτισ-laptop με λειτουργικό Windows Vista. Αρχικά λοιπόν, φτιάξαμε ζνα εντελϊσ αυτόνομο περιβάλλον εργαςίασ ςτον υπολογιςτι αυτόν. Αυτό επιτεφχκθκε με χριςθ του προγράμματοσ Oracle VM Virtual Box με το οποίο μπορζςαμε να δθμιουργιςουμε ζνα εικονικό περιβάλλον ςαν μια αυτόνομθ κζςθ εργαςίασ (εικονικόσ υπολογιςτισ μζςα ςτον υπολογιςτι) που χρθςιμοποιεί λειτουργικό LINUX Ubuntu LTS The Lucid Lynx. Ζπειτα, ςε αυτόν τον εικονικό υπολογιςτι ζγινε θ εγκατάςταςθ του περιβάλλοντοσ TinyOS, το οποίο ςτθν ουςία είναι ζνα «δζντρο» (TinyOS tree) από φακζλουσ που περιζχουν όλα τα απαραίτθτα αρχεία που δίνουν υπόςταςθ ςτο λειτουργικό. Ο τρόποσ με τον οποίο ζγινε θ εγκατάςταςθ περιγράφεται αναλυτικά ςτο παράρτθμα. Επίςθσ, μια λειτουργία που υλοποιείται ςε μια εφαρμογι TinyOS μποροφμε να τθν ελζγξουμε με τον εξομοιωτι TOSSIM. Ο TOSSIM, που προκφπτει από το TinyOS SIMulator, είναι ζνασ προςομοιωτισ διακριτϊν γεγονότων. Η λογικι του είναι ότι αντί να κάνω compile μια TinyOS εφαρμογι για ζναν κόμβο μπορϊ να τθν κάνω compile ςε ζνα TOSSIM framework που τρζχει ςε ζνα PC. Αυτό επιτρζπει να κάνω debug, test και ανάλυςθ του αλγορίκμου ςε ζνα ελεγχόμενο και επαναλαμβανόμενο περιβάλλον. 5.2 Πρϊτα Βιματα Τλοποίθςθσ Ζχοντασ εγκαταςτιςει το TinyOS environment ςτον εικονικό υπολογιςτι με τα LINUX, το πρϊτο βιμα είναι να κάνω ζναν ζλεγχο ότι το περιβάλλον ζχει 67

68 ρυκμιςτεί ςωςτά. Ανοίγοντασ το τερματικό, πλθκτρολογοφμε τθν εντολι tos_check_env. Το script αυτό ελζγχει ςχεδόν τα πάντα που χρειάηεται το TinyOS περιβάλλον. Ο ζλεγχοσ γίνεται κανονικά χωρίσ προβλιματα. Το επόμενο βιμα είναι να ελζγξω ότι ζχω το TinyOS build system ενεργοποιθμζνο. Αυτό το ςφςτθμα μου δίνει τθ δυνατότθτα να κάνω compile μια TinyOS εφαρμογι με τθν εντολι make [platform] θ οποία και εκτελείται από τον φάκελο τθσ εφαρμογισ. Στθ κζςθ τθσ παραμζτρου «platform» βάηω τθν οικογζνεια των κόμβων που χρθςιμοποιϊ ςτθν εφαρμογι μου. Το ςφςτθμα εμπεριζχει τθ χριςθ τθσ environment variable: MAKERULES. Στο τερματικό πάλι, πλθκτρολογϊ printenv MAKERULES και αμζςωσ εμφανίηεται το μονοπάτι: /opt/tinyos-2.1.1/support/make/makerules κάτι που ςθμαίνει πωσ θ μεταβλθτι αυτι υπάρχει και είναι ςωςτά οριςμζνθ. Στθ ςυνζχεια, αφοφ ζχω ζτοιμο το περιβάλλον εργαςίασ μου, κάνω εγκατάςταςθ τθσ αναπτυξιακισ πλακζτασ MIB520CB, θ οποία και κα είναι το μζςο επικοινωνίασ μεταξφ του WSN μου και του υπολογιςτι. Το ςυγκεκριμζνο κομμάτι υλικοφ είναι πολφ ςθμαντικό γιατί προςφζρει ςυνδεςιμότθτα με τα IRIS motes για να τα προγραμματίηουμε με τισ εφαρμογζσ που υλοποιοφμε και να διαβάηουμε τα δεδομζνα που ςυλλζγονται από το δίκτυο (ι που ςτζλνουμε ςτο δίκτυο). Ακριβϊσ για αυτό, θ εγκατάςταςι του κα γίνει τόςο ςτον πραγματικό υπολογιςτι όςο και ςτον εικονικό. Πταν βάηουμε για πρϊτθ φορά το ΜΙΒ520 ςε μια κφρα USB του υπολογιςτι, τότε τα windows το αναφζρουν ςαν νζο hardware. Χρθςιμοποιοφμε το CD με του οδθγοφσ εγκατάςταςθσ τθσ Crossbow και θ εγκατάςταςθ γίνεται από εκεί. Συνολικά πάνω από 4 εγκαταςτάςεισ πραγματοποιοφνται και όταν οι drivers εγκαταςτακοφν κα υπάρχουν 2 ςειριακζσ πφλεσ USB ςχετιςμζνεσ με το αναπτυξιακό ΜΙΒ520. Η μία πραγματικι κφρα USB λειτουργεί πλζον ςαν δφο εικονικζσ ςειριακζσ κφρεσ για το ΜΙΒ520, ακριβϊσ για τον διαχωριςμό των δφο διακριτϊν λειτουργιϊν που προςφζρει θ ςυγκεκριμζνθ ςυςκευι. Οι δφο αυτζσ virtual serial ports που ςχετίηονται με το αναπτυξιακό μασ είναι θ COM4 και θ COM5. Η πρϊτθ χρθςιμοποιείται για τον προγραμματιςμό των motes (in system mote programming), ενϊ θ δεφτερθ είναι για τθν επικοινωνία και ανταλλαγι δεδομζνων με αυτά (communication over USB). Πμοια διαδικαςία ακολουκείται και ςτον εικονικό υπολογιςτι. Η διαφορά είναι ότι εκεί ζχω τθν κφρα /dev/ttyusb0 για προγραμματιςμό, και τθν /dev/ttyusb1 για επικοινωνία με τα motes ςειριακά. Η ςυςκευι ΜΙΒ520 όταν γίνεται plug-in ςε μια κφρα του υπολογιςτι τροφοδοτείται με ρεφμα μζςω τθσ ςφνδεςθσ USB, θ οπτικοποίθςθ αυτοφ του γεγονότοσ γίνεται ανάβοντασ το πράςινο led (D3) με τθν ζνδειξθ PWROK. Αντίςτοιχα, όταν ο προγραμματιςμόσ ενόσ mote είναι ςε εξζλιξθ τότε υπάρχει φωτεινι ζνδειξθ ςτο κόκκινο led (D5). 5.3 Δθμιουργία απλισ εφαρμογισ για επικοινωνία κόμβων Ρριν αρχίςουμε τθν ανάπτυξθ των προγραμμάτων που απαιτοφνται για τθν υλοποίθςθ τθσ εφαρμογισ μασ, κεωριςαμε ςωςτι τθν αςχολία μασ πρϊτα με το ςφςτθμα και τθν εξοικείωςθ με το νζο αυτό περιβάλλον. Αρχικά λοιπόν, αναπτφχκθκε μια απλι εφαρμογι για να κάνουμε εξομοίωςθ με το εργαλείο TOSSIM. Η εφαρμογι αυτι υλοποιεί τθ λογικι τθσ αποςτολισ και αποδοχισ 68

69 πακζτων δεδομζνων από ζναν κόμβο ςτο πλαίςιο ενόσ δικτφου WSN. Στισ προδιαγραφζσ τθσ εφαρμογισ είναι: Η ενεργοποίθςθ του κόμβου ςε τυχαία χρονικι ςτιγμι, θ αποςτολι πακζτων ςε τυχαίεσ χρονικζσ ςτιγμζσ, θ ενεργοποίθςθ του chip του πομποδζκτθ όταν πρζπει να ςταλεί ζνα πακζτο, το γζμιςμα του πακζτου με δεδομζνα, θ αποςτολι του πακζτου με μια λογικι modulo για να ζχω «κυκλικι» αποςτολι ςε όλουσ του κόμβουσ τθσ τοπολογίασ, το κλείςιμο του πομποδζκτθ μετά τθν αποςτολι για να μθν καταναλϊνεται ενζργεια χωρίσ λόγο, θ λιψθ ενόσ πακζτου από κάποιον άλλον κόμβο. *θμείωςθ: Ο κϊδικασ τθσ εφαρμογισ βρίςκεται ςτο παράρτθμα Β.] Ξεκινϊντασ φτιάχνουμε το module MoteSendReceiveSIM το οποίο κα είναι και το όνομα τθσ εφαρμογισ μασ. Το module δθλϊνεται με τθν δεςμευμζνθ λζξθ ςε nesc module. Αμζςωσ μετά ακολουκεί το signature block ςτο οποίο και δθλϊνουμε τα interfaces που χρθςιμοποιοφνται από τθν εφαρμογι μασ. Αυτά είναι: boot: Χρθςιμοποιείται το boot interface το οποίο ζχει μόνο ζνα event (event void Boot.booted()) το οποίο ςθματοδοτείται όταν γίνει θ ενεργοποίθςθ του κόμβου. Receive: το interface που ζχει μζςα το event Receive.receive() το οποίο ςθματοδοτείται όταν γίνει λιψθ ενόσ πακζτου. AMSend: το interface που δθλϊνει τθν εντολι error_t send(am_addr_t addr, message_t* msg, uint8_t len) για αποςτολι ενόσ πακζτου και το event void SendDone(message_t* msg, errot_t error) που ςθματοδοτείται όταν θ αποςτολι ενόσ πακζτου ολοκλθρϊνεται. Timer<TMilli>: το interface που μου δίνει τθν δυνατότθτα οριςμοφ ενόσ χρονομετρθτι με βάςθ χρόνου τα milliseconds. Το component αυτό είναι generic. SplitControl: είναι το interface που χρθςιμοποιϊ για να μπορϊ να εναλλάςςω τον πομποδζκτθ από on ςε off και ανάποδα. Δθλϊνει, για αυτό το ςκοπό, τθν εντολι error_t start() και το event void startdone(error_t error) για τθν ενεργοποίθςθ του chip και αντίςτοιχα για τθν απενεργοποίθςθ είναι τα error_t stop() και event void stopdone(error_t error). Packet: είναι το interface που δθλϊνει εντολζσ για τθν διαχείριςθ του πακζτου. Εμείσ κα χρθςιμοποιιςουμε τθν εντολι uint8_t getpayload(message_t* msg, uint8_t len) όπου θ παράμετροσ len πρζπει να αντιπροςωπεφει το μζγιςτο μικοσ που κα ζχει το πακζτο μασ, ενϊ θ πρϊτθ παράμετροσ δθλϊνει τον τφπο του πακζτου που κα ςταλεί. Αν το payload του πακζτου είναι μικρότερο από το len του μθνφματοσ που κζλουμε να ςτείλουμε, τότε δεν χωράει και θ εντολι επιςτρζφει NULL. Η εντολι αυτι επιςτρζφει ζναν δείκτθ void, αυτό δίνει τθ δυνατότθτα να τον μετατρζψουμε ςε ότι τφπο δομισ κζλουμε με απλό casting. 69

70 Random: το interface αυτό μου δίνει τθ δυνατότθτα παραγωγισ ψευδοτυχαίων αρικμϊν δθλϊνοντασ τθν εντολι async command uint16_t rand16() θ οποία και επιςτρζφει ζναν τυχαίο 16μπιτο αρικμό. Σε αυτό το ςθμείο καλό είναι να κάνουμε κάποια ςχόλια. Ραρατθροφμε ότι το interface Timer δζχεται μια παράμετρο. Τα components που παίρνουν παράμετρο καλοφνται generic components. Η διαφορά είναι ότι τα generic components επιτρζπουν ςε πολλά ςυςτιματα να χρθςιμοποιοφν ανεξάρτθτεσ αντιγραφζσ ενόσ μοναδικοφ implementation. Αυτό επιτυγχάνεται με τθ χριςθ τθσ δεςμευμζνθσ λζξθσ new. Ραρόλο που ζνα generic component ζχει global name, κάκε ςτιγμιότυπό του ζχει ζνα local name που είναι και private μόνο για το component που το ζχει δθμιουργιςει. Υπάρχουν generic interfaces, modules και configurations. Επίςθσ, παρατθροφμε τθ χριςθ τθσ δεςμευμζνθσ λζξθσ as. Αυτό το keyword μασ δίνει τθ δυνατότθτα να εναλλακτικϊν ονομάτων για ζνα interface. Ζτςι μποροφμε να δϊςουμε ονόματα που να είναι ςχετικά με λειτουργίεσ που πρόκειται να επιτελζςει θ εφαρμογι μασ κακιςτϊντασ τθν ζτςι πιο ευανάγνωςτθ και πιο κατανοθτι. Μπορεί να χρθςιμοποιθκεί και όταν ζνα component δθμιουργεί πολλά ςτιγμιότυπα του ίδιου interface, δίνοντάσ τουσ διακριτά ονόματα. Η χριςθ τθσ γίνεται ςτα signature blocks των components. Ζπειτα, είναι ευδιάκριτεσ οι split phase λειτουργίεσ που ζχουμε αναφζρει ςε προθγοφμενα κεφάλαια. Για παράδειγμα, για τθν ενεργοποίθςθ μιασ ςυςκευισ ςτο mote χρθςιμοποιοφμε τθν εντολι start() του SplitControl interface. Πταν θ ςυςκευι ενεργοποιθκεί τότε και μόνο τότε κα ςθματοδοτθκεί το event startdone(error_t error). Δθλαδι θ ολοκλιρωςθ τθσ λειτουργίασ επιτυγχάνεται ςε δφο φάςεισ. Ππωσ και το AMSend interface περιζχει τισ εντολζσ για τθν πραγματοποίθςθ split phase μεταδόςεων πακζτων αποκθκευμζνων ςε ζναν buffer τφπου message_t. Το message_t αποτελεί Εικόνα: Θ δομι message_t τον βαςικό buffer μθνφματοσ που χρθςιμοποιείται ςτο TinyOS 2.x. Η δομι του κακορίηεται ςτο μονοπάτι του TinyOS tree: tos/types/message.h και είναι μια μορφι που διατθρεί τα δεδομζνα ςε ζνα ςτακερό offset ςε μια πλατφόρμα, κάτι που είναι εξαιρετικά ςθμαντικό κατά το πζραςμα ενόσ μθνφματοσ ανάμεςα ςε δφο διαφορετικά επίπεδα διαςφνδεςθσ (link layers). Το μζγεκοσ του πεδίου data κακορίηεται από μια ςτακερά TOSH_DATA_LENGHT = 28 bytes. Αν το payload ενόσ πακζτου είναι μεγαλφτερο από αυτι τθ ςτακερά τότε το πακζτο απορρίπτεται. Η παρατθροφμενθ παράμετροσ error_t είναι ζνασ τφποσ επιςτροφισ και αποτελεί ζναν τρόπο του TinyOS για αναφορά επιτυχίασ ι αποτυχίασ (SUCCESS=0, FAIL=1). Τζλοσ, τα uint8_t και uint16_t είναι τφποι δεδομζνων όπωσ ακριβϊσ ζχουμε και ςτθ C. Το πρϊτο δθλϊνει ακζραιο 8μπιτο αρικμό, ενϊ το δεφτερο δθλϊνει ακζραιο 16μπιτο αρικμό. Μετά τθ ςυμπλιρωςθ του signature block ακολουκεί το implementation. Εκεί περιζχεται κϊδικασ ςε nesc, με ςφνταξθ παρόμοια τθσ C, που αποτελεί και τον πυρινα τθσ εφαρμογισ. Εδϊ υλοποιοφνται όλεσ οι προδιαγραφζσ που κζςαμε ςαν 70

71 ςτόχο να ικανοποιεί θ εφαρμογι ςτθν αρχι. Το πρόγραμμα μόλισ το event Boot.booted() ςθματοδοτθκεί καλεί τθν εντολι για ενεργοποίθςθ του πομποδζκτθ. Η split-phase λειτουργία αυτι κα ολοκλθρωκεί μόλισ ςθματοδοτθκεί το event AMControl.startDone(error_r err). Η ενζργεια αυτι ςυνεπάγεται τθν ζναρξθ άλλων ενεργειϊν που δθλϊνονται μζςα ςτο ςϊμα του event. Εκεί γίνεται ζλεγχοσ για το αν θ παράμετροσ error_t err είναι SUCCESS ι FAIL. Αν θ ενεργοποίθςθ του chip ζχει γίνει με επιτυχία τότε καλείται θ εντολι rand16() για να δθμιουργθκεί ζνασ τυχαίοσ 16μπιτοσ αρικμόσ ο οποίοσ κα αποτελζςει τθν περίοδο του MilliTimer που ορίςαμε. Από το interface του καλείται θ εντολι startperiodic( period ) και αμζςωσ ξεκινάει περιοδικά να μετράει ο timer με περίοδο τθν δθλωκείςα παράμετρο. Αν θ ενεργοποίθςθ του chip απζτυχε τότε γίνεται εκ νζου προςπάκεια για ενεργοποίθςθ. Κάκε φορά που ο timer κα λιγει, κα ςθματοδοτείται το event MilliTimer.fired() το οποίο ςυνεπάγεται αφξθςθ μιασ εςωτερικισ μεταβλθτισ counter που τθν βάλαμε για το ςκοπό τθσ εξομοίωςθσ και αποςτολι ενόσ πακζτου. Η αποςτολι του πακζτου για να γίνει προχποκζτει ζναν υποτυπϊδθ ζλεγχο για το αν το κανάλι είναι απαςχολθμζνο λόγω άλλθσ μετάδοςθσ. Η λογικι μεταβλθτι locked (boolean τφπου) μασ βοθκάει προσ αυτι τθ κατεφκυνςθ. Αν γίνεται αποςτολι κάποιου πακζτου θ τιμι τθσ τίκεται ςτο λογικό 1 ενϊ όταν το κανάλι είναι διακζςιμο θ τιμι τθσ είναι το λογικό 0. Αν λοιπόν το κανάλι είναι διακζςιμο, το επόμενο βιμα που εκτελεί το πρόγραμμά μασ είναι να ελζγξει αν το μινυμα προσ μετάδοςθ χωράει ςτο payload του πακζτου τφπου message_t. Χρθςιμοποιϊντασ τθν εντολι getpayload(message_t* msg, uint8_t len) όπου τθν παράμετρο len τθν αντικακιςτά το sizeof(radio_count_msg_t) που είναι το μζγεκοσ τθσ δομισ που χρθςιμοποιείται από το ςυγκεκριμζνο module. Η περιγραφι τθσ δομισ είναι ςε ζνα αρχείο header το οποίο, όπωσ και ςτθ C, γίνεται include ςτθν αρχι του component. Ο header file τθσ εφαρμογισ μασ είναι ζνα ξεχωριςτό αρχείο που φτιάχνουμε με όνομα MoteSendReceiveSIM.h και περιλαμβάνει τθ διλωςθ τθσ δομισ radio_count_msg_t και τον οριςμό των πεδίων τθσ που μασ ενδιαφζρουν. Τα πεδία που επιλζξαμε να βάλουμε είναι το number για τον αρικμό που κα ςτζλνεται, το srcnode που δθλϊνει τον κόμβο πθγι και το dstnode για τον κόμβο παραλιπτθ. Αν λοιπόν θ getpayload δεν επιςτρζψει NULL, αν δθλαδι θ δομι radio_count_msg_t χωράει ςτο payload του message_t, γίνεται ανάκεςθ τιμϊν ςτισ μεταβλθτζσ-πεδία τθσ εςωτερικισ δομισ του component. Ραράγεται ζνασ τυχαίοσ αρικμόσ, πάλι με χριςθ τθσ rand16(), και θ τιμι του ανατίκεται ςτθ μεταβλθτι number. Η μεταβλθτι srcnode παίρνει τθ τιμι τθσ ςτακεράσ TOS_NODE_ID που περιζχει το ID του κόμβου και θ τιμι τθσ dstnode ακολουκεί μια λογικι modulo 3 ςτθ τιμι τθσ number, για να ποικίλει ο κόμβοσ παραλιπτθσ κάκε φορά και να μθν είναι ςυνζχεια ο ίδιοσ. Ζπειτα, θ εντολι send() χρθςιμοποιείται. Η εντολι παίρνει τρεισ παραμζτρουσ. Η πρϊτθ δθλϊνει τον κόμβο παραλιπτθ, θ δεφτερθ δείκτθ ςτο πακζτο που κα ςταλεί και θ τρίτθ το μζγεκοσ του payload του πακζτου. Η αποςτολι γίνεται και θ μεταβλθτι locked = TRUE. Ζνα event senddone() κα ςθματοδοτιςει τθν ολοκλιρωςθ τθσ split phase λειτουργίασ αποςτολισ. Το event αυτό ζχει δφο παραμζτρουσ, θ πρϊτθ αναφζρεται ςτο πακζτο που ςτάλκθκε και θ δεφτερθ είναι μια μεταβλθτι τφπου error_t. Με ζναν απλό ζλεγχο - ςφγκριςθ τθσ πρϊτθσ παραμζτρου με το πακζτο που ςτείλαμε, διαπιςτϊνουμε αν θ αποςτολι ζγινε με επιτυχία και θ μεταβλθτι locked τίκεται FALSE. Τζλοσ υλοποιείται και θ λειτουργία λιψθσ, με τθν ςθματοδότθςθ του event receive(). Το event ζχει τρεισ παραμζτρουσ, θ πρϊτθ δθλϊνει το πακζτο που 71

72 παραλιφκθκε, θ δεφτερθ ζναν δείκτθ ςτο payload του πακζτου και θ τρίτθ το μζγεκοσ του πεδίου δεδομζνων. Με ζναν απλό ζλεγχο γίνεται επαλικευςθ για το αν το πακζτο που παραλιφκθκε είναι πακζτο δομισ που αναμενόταν να ζρκει. Μζςα ςτο κϊδικα του implementation παρατθροφμε τθν φπαρξθ debugging προτάςεων (statements). Αυτζσ οι προτάςεισ χρθςιμοποιοφν κανάλια (θ πρϊτθ παράμετροσ τθσ πρόταςθσ) για να «βγάλουν» ςτθν οκόνθ του τερματικοφ ζνα πλαίςιο κειμζνου (δεφτερθ παράμετροσ τθσ πρόταςθσ). Τα statements αυτά ζχουν νόθμα μόνο ςτο πλαίςιο τθσ εξομοίωςθσ και όχι για εγκατάςταςθ ςε πραγματικοφσ κόμβουσ. Αφοφ πλζον ζχουμε ζτοιμο το module τθσ εφαρμογισ μασ, ςτθ ςυνζχεια μζνει να υλοποιιςουμε και το configuration αρχείο MoteSendReceiveSIMAppC. Στο implementation block δθλϊνονται τα components που χρθςιμοποιοφνται από τθν εφαρμογι. Τα generic components εκτόσ του ότι δθμιουργοφμε ζνα νζο ςτιγμιότυπό τουσ με το keyword new, παίρνουν και τθν κατάλλθλθ παράμετρο. Στθ ςυνζχεια γίνεται το wiring μεταξφ των χρθςιμοποιοφμενων interfaces και των components που περιζχουν υλοποιιςεισ των εντολϊν και των γεγονότων που δθλϊνονται ςτα interfaces. Σε αυτό το ςθμείο γίνεται πιο κατανοθτόσ ο τρόποσ με τον οποίο τα interfaces ςυνδζουν πολλά components μεταξφ τουσ ςε μια λειτουργικι εφαρμογι Εξομοίωςθ TOSSIM Ζχοντασ ολοκλθρϊςει το μζροσ «ανάπτυξθσ κϊδικα» για τθν εφαρμογι μου, ςτθ ςυνζχεια πρζπει να κάνουμε compile για εξομοίωςθ. Αυτό επιτυγχάνεται από το τερματικό με τθν εντολι make iris sim. Αποτζλεςμα αυτισ τθσ ενζργειασ είναι θ δθμιουργία ενόσ αρχείου TOSSIM.py ςτον φάκελο τθσ εφαρμογισ μασ, το οποίο είναι απαραίτθτο για τθν εξομοίωςθ μιασ και περιζχει όλεσ τισ πλθροφορίεσ για αυτιν. Για να κάνουμε μια εξομοίωςθ τθσ εφαρμογισ με τον TOSSIM πρζπει να γράψουμε ζνα python script που κα περιζχει τθ περιγραφι τθσ τοπολογίασ του WSN δικτφου μου, κα δθμιουργεί μοντζλα κορφβου και κα ορίηει τα κανάλια εξόδου για να εκτυπϊνονται ςτθν οκόνθ του τερματικοφ τα dbg μθνφματα. Το τελευταίο είναι πολφ χριςιμο εργαλείο ςτθν εξομοίωςθ κακϊσ μποροφμε να ελζγχουμε ζτςι αν αυτι εξελίςςετε κανονικά βγάηοντασ μθνφματα ορκισ λειτουργίασ (ο ζλεγχοσ αυτόσ ςτο πραγματικό κόςμο ελζγχεται με τα leds που ζχουν πάνω τα motes). Στο python script που φτιάχνουμε πρζπει να κάνουμε import το TOSSIM.py αρχείο που δθμιουργικθκε με το compile. Με αυτόν τον τρόπο κα ζχω ςφνδεςθ του script με τθν nesc εφαρμογι. Μια άλλθ πολφ χριςιμθ λειτουργία ςτον εξομοιωτι είναι ότι μποροφμε να κάνουμε επικεϊρθςθ (inspect) εςωτερικϊν μεταβλθτϊν τθσ εφαρμογισ από το python script και ανάλογα να ελζγχουμε τθν εξομοίωςι μασ, παρατθρϊντασ το πϊσ μεταβάλλονται οι μεταβλθτζσ τθσ εφαρμογισ ςαν να μεταβάλλονταν υπό όρουσ πραγματικισ λειτουργίασ ςε πραγματικό κόμβο δικτφου. Στο script γίνεται μια απλι περιγραφι του δικτφου. Οι πραγματικζσ λειτουργίεσ που κα εξομοιωκοφν είναι ςτθν εφαρμογι. Στο script με όνομα test3.py βρίςκεται ο κϊδικασ ςε python που ορίηει τθν πορεία τθσ εξομοίωςθσ. Αρχικά γίνονται τα imports, με αςτερίςκο, κάνοντασ ζτςι 72

73 «ορατζσ» όλεσ τισ απαιτοφμενεσ πλθροφορίεσ. Στθ ςυνζχεια δθμιουργοφνται οι απαραίτθτεσ κλάςεισ από τα αντικείμενα που κάναμε import, κάκε μια από τισ οποίεσ ζχει ζνα ςφνολο από μεκόδουσ. Τισ μεκόδουσ αυτζσ μποροφμε να τισ δοφμε γράφοντασ ςτο τερματικό dir(class). Με τθ μζκοδο addchannel( name, output ) ορίηονται τα κανάλια που χρθςιμοποιοφμε ςτα debugging statements, δθλαδι τα MoteSendReceiveSIM, Boot και TimeStamp που όλα τουσ ζχουν τθν ίδια ζξοδο. Η πρϊτθ παράμετροσ είναι το όνομα του καναλιοφ, ενϊ θ δεφτερθ είναι θ ζξοδόσ του. Στθ ςυνζχεια ορίηεται θ τοπολογία του δικτφου διαβάηοντασ το αρχείο topo2.txt το Εικόνα: Σοπολογία δικτφου που εξομοιϊνουμε οποίο ζχει το κατάλλθλο format, κάτι που είναι αρκετά εφκολο μιασ και θ python χαρακτθρίηεται για τθν απλι διαχείριςθ κειμζνου. Μζςω τθσ κλάςθσ r = t.radio() αρχικοποιοφνται τα κζρδθ ςτισ γραμμζσ ςφνδεςθσ των κόμβων μεταξφ τουσ. Η τοπολογία που επιλζξαμε να ςχεδιάςουμε φαίνεται ςτθν παραπάνω εικόνα. Ζπειτα προςτίκεται ζνα μοντζλο κορφβου για να κάνουμε τθν εξομοίωςθ πιο ρεαλιςτικι, χρθςιμοποιϊντασ το ζτοιμο αρχείο meyer-heavy.txt και τθ μζκοδο addnoisetracereading(val) για κάκε ζναν κόμβο χωριςτά. Μετά χρθςιμοποιοφμε τθ μζκοδο bootattime( time ) για να κάνουμε τουσ κόμβουσ να ενεργοποιοφνται ςε διαφορετικζσ χρονικζσ ςτιγμζσ. Η παράμετροσ time ςε αυτι τθ μζκοδο μετριζται ςε ticks. Γενικά υπάρχουν 10 9 ticks per msec. Επιπλζον κζλουμε θ εξομοίωςθ να ςταματάει όταν θ μεταβλθτι counter ςτον κόμβο 1 πάρει τθν τιμι 2. Επιλζγω με εντολζσ python τον κόμβο 1 και παρακολουκϊ τθν εςωτερικι μεταβλθτι του counter. Ο διακριτόσ εξομοιωτισ TOSSIM κα τρζχει τθ μζκοδο t.runnextevent() μζχρι θ ςυγκεκριμζνθ μεταβλθτι να φτάςει τθ τιμι 2. Είμαςτε πλζον ζτοιμοι για να τρζξουμε τθν εξομοίωςθ τθσ εφαρμογισ. Στο τερματικό πατάμε python test3.py και τα αποτελζςματα φαίνονται ςτθ παρακάτω εικόνα. Ραρατθροφμε ότι με τθ χριςθ των dbg statements γίνεται πιο εφλθπτο το αποτζλεςμα τθσ εξομοίωςθσ. Επίςθσ, πολφ ςθμαντικι είναι και θ χριςθ τθσ μεκόδου char* sim_time_string() που επιςτρζφει χρόνο ςε δευτερόλεπτα, για να αντιλθφκοφμε τθν ζννοια του χρόνου κατά τθ διάρκεια τθσ εξομοίωςθσ. Ραρατθροφμε επίςθσ ότι τα πακζτα που ςτζλνονται από ζναν κόμβο ζχοντασ ωσ παραλιπτθ τον ίδιο τον κόμβο τελικά χάνονται, κάτι που είναι αναμενόμενο αφοφ το αρχείο τοπολογίασ δεν προβλζπει κάποια φυςικι ςφνδεςθ για αυτό το ςκοπό. 73

74 Εικόνα: Αποτζλεςμα εξομοίωςθσ τθσ εφαρμογισ MoteSendReceiveSIM ςε TOSSIM 5.4 Ανάπτυξθ μιασ πρϊτθσ ζκδοςθσ του Base Station Φζροντασ ςε πζρασ το παραπάνω βιμα, ζγιναν αρκετά κατανοθτά ο τρόποσ λειτουργίασ του TinyOS και θ χριςθ τθσ γλϊςςασ nesc για ανάπτυξθ εφαρμογϊν που εγκακίςτανται ςε κόμβουσ WSN. Είμαςτε επομζνωσ ζτοιμοι για τθν υλοποίθςθ των βαςικϊν εφαρμογϊν μασ. Μζχρι να καταλιξουμε ςτθν τελικι μορφι των εφαρμογϊν που κα τρζχουν ςτουσ κόμβουσ, περάςαμε από πολλά ςτάδια εξζλιξθσ ενόσ αρχικοφ προγράμματοσ το οποίο αφοφ επαλθκεφαμε ότι τρζχει κανονικά και ςφμφωνα με τισ προδιαγραφζσ που ορίηαμε, του προςκζταμε μια επιπλζον λειτουργία. Ζτςι, προςκετικά καταλιξαμε ςτθ τελικι μορφι των εφαρμογϊν που φαίνονται ςτο παράρτθμα Β. Ο πρϊτοσ ςτόχοσ ιταν θ ανάπτυξθ μιασ εφαρμογισ Base Station που κα εγκαταςτακεί ςτον κόμβο που κα βρίςκεται επιςυνθμμζνοσ ςτο αναπτυξιακό ΜΙΒ520. Στο πρϊιμο ςτάδιο λοιπόν αυτισ τθσ εφαρμογισ, ο ςτόχοσ είναι θ περιοδικι ςειριακι μεταφορά, μζςω UART, ενόσ πακζτου δεδομζνων, που κα αποτελείται από ζναν ςτακερό και γνωςτό αρικμό για να μπορεί να γίνει ζλεγχοσ εκ των υςτζρων για το αν λιφκθκε ςωςτά, από το mote ςτον υπολογιςτι μζςω του ΜΙΒ520. Ξεκινάμε 74

75 καταςκευάηοντασ το module MyBasestationC.nc. Στο signature block του component αυτοφ, τθσ εφαρμογισ μασ, δθλϊνονται τα interfaces που χρθςιμοποιικθκαν. Αυτά είναι τα Boot, Leds, Timer<TMilli>, AMSend, SplitControl και Packet. Η διαφορά είναι ότι εδϊ τα interfaces AMSend και Packet τα κζλω για τθν επίτευξθ τθσ ςειριακισ επικοινωνίασ και για τον ζλεγχο των πακζτων που είναι προσ ςειριακι αποςτολι αντίςτοιχα. Ραρατθρϊ ότι χρθςιμοποιϊ πάλι το keyword as όχι μόνο για να διακριτοποιιςω τθ διπλι χριςθ του interface Timer<TMilli> με δφο ονόματα (ονομάηω τουσ δφο μετρθτζσ ωσ MyClock και CountDown) αλλά και για να δϊςω ςτα interfaces AMSend και SplitControl ονόματα UARTSend και SerialControl, που προϊδεάηουν για τον τρόπο με τον οποίο κα κλθκοφν να λειτουργιςουν ςτθ ςυγκεκριμζνθ εφαρμογι. Στθ ςυνζχεια ςτο implementation block του module δθλϊνω τον αρικμό που κζλω να ςτζλνω ςειριακά. Η διλωςθ γίνεται με uint16_t data = 10; ενϊ πάλι χρθςιμοποιϊ τθ λογικι «κλειδϊματοσ» για να μθν μπορεί να γίνει ςειριακι επικοινωνία με τον υπολογιςτι αν είναι ςε εξζλιξθ μια άλλθ. Για τισ ανάγκεσ τθσ ςειριακισ επικοινωνίασ, δθμιουργϊ μια δομι πακζτου που κα αποςτζλλεται ςειριακά. Αυτι ορίηεται ςτον header TestSerial.h ο οποίοσ και γίνεται include ςτο module τθσ εφαρμογισ μασ για να είναι ορατόσ από αυτιν. Η δομι του μθνφματοσ αποτελείται από μόνο ζνα πεδίο αφοφ μόνο ζναν αρικμό ζχουμε προσ μετάδοςθ. Επειδι θ ςυγκεκριμζνθ μετάδοςθ κα πραγματοποιθκεί μεταξφ δφο διαφορετικϊν πλατφόρμων θ δομι που δθμιουργοφμε πρζπει να είναι ανεξάρτθτθ από τθν πλατφόρμα υλικοφ (platform independent) για να γίνει με επιτυχία και χωρίσ αλλοιϊςεισ θ μετάδοςθ. Για να δθλϊςω μια δομι μθνφματοσ ςαν platform independent χρθςιμοποιϊ το δεςμευμζνο πρόκεμα nx_. Πταν δθμιουργϊ μια δομι που είναι platform independent τότε κάκε μεταβλθτι που ορίηει και ζνα πεδίο τθσ δομισ πρζπει να είναι και αυτι platform independent. Με αυτό τον τρόπο ο compiler εξαςφαλίηει ότι αυτόσ ο τφποσ ζχει τθν ίδια εκπροςϊπθςθ ςε όλεσ τισ πλατφόρμεσ δθμιουργϊντασ τουσ απαραίτθτουσ κϊδικεσ μετατροπισ. Ζτςι λοιπόν θ δομι test_serial_msg είναι τφπου nx_struct και το πεδίο που τθν αποτελεί είναι nx_uint16_t counter;. Επιςτρζφοντασ ςτον κϊδικα του implementation, ςτο πεδίο διλωςθσ των μεταβλθτϊν, δθλϊνεται μια δομι πακζτου message_t packet και ζνασ δείκτθσ προσ τθ δομι που φτιάξαμε, test_serial_msg_t* mp. Πταν γίνεται το boot του κόμβου, θ ςθματοδότθςθ του event booted κα οπτικοποιιςει το γεγονόσ ςτον εξωτερικό παρατθρθτι-χριςτθ ανάβοντασ όλα τα led του με τθν εντολι call Leds.ledxOn();. Εδϊ να ςθμειϊςουμε ότι θ ςφμβαςθ που υπάρχει για τα led είναι θ εξισ: Led0 = κόκκινο Led1 = πράςινο Led2 = κίτρινο Επίςθσ καλείται θ εντολι για ενεργοποίθςθ τθσ ςειριακισ επικοινωνίασ με το call SerialControl.start();. Μζχρι ςτιγμισ το χρθςιμοποιοφμενο interface SplitControl δεν «καταλαβαίνει» ότι ςκοπόσ του είναι να ενεργοποιιςει τθ ςειριακι επικοινωνία. Ππωσ ζχουμε πει, το interface αυτό απλά περιζχει, όπωσ και όλα τα interfaces, ςφνολο από εντολζσ και γεγονότα τα οποία υλοποιοφνται ςε άλλα components με τα οποία και ςυνδζονται ςτο wiring. Επομζνωσ θ λειτουργικότθτα του interface κα επιτευχκεί - ολοκλθρωκεί εκεί. Τζλοσ, ςτο event Boot.booted(), περιλαμβάνεται και θ ζναρξθ του χρονομετρθτι MyClock, ο οποίοσ δεν είναι περιοδικόσ αλλά εκτελεί 75

76 μόνο μια χρονομζτρθςθ των 5 δευτερολζπτων, χρθςιμοποιϊντασ τθν εντολι call MyClock.startOneShot(5000);. Στθ ςυνζχεια υλοποιείται το event void SerialControl.startDone() το οποίο, για να καταλάβουμε ότι ολοκλθρϊκθκε με επιτυχία, του βάηουμε να κλείνει το κόκκινο led με τθν εντολι call Leds.led0Off();. Επειδι υλοποιοφμε τθν ενεργοποίθςθ o compiler πρζπει να δει να υλοποιοφμε και το event για τθν απενεργοποίθςθ διαφορετικά κα βγάλει μινυμα λάκουσ. Γράφουμε επομζνωσ και το event SerialControl.stopDone(error_t error){ το οποίο δεν εκτελεί κάτι ςυγκεκριμζνο (do nothing) όταν ςθματοδοτείται. Το event MyClock.fired() το υλοποιοφμε γιατί κα ςθματοδοτθκεί όταν ο μετρθτισ που ζχουμε ορίςει μθδενιςτεί, είτε είναι περιοδικόσ οπότε και το event κα ςθματοδοτείται περιοδικά, είτε είναι για μια μόνο μζτρθςθ. Το MyClock το ζχουμε βάλει να κάνει μια μόνο μζτρθςθ 5 δευτερολζπτων, μετά το πζρασ αυτϊν το event fired() του κα ςθματοδοτθκεί και ωσ αποτζλεςμα κα ςβιςει όλα τα leds ζχουν μείνει ανοιχτά και κα ξεκινιςει τον περιοδικό μετρθτι call CountDown.startPeriodic() με περίοδο 10 δευτερολζπτων. Ο μετρθτισ αυτόσ κάκε φορά που κα λιγει κα ενεργοποιεί τθν μετάδοςθ ενόσ πακζτου δεδομζνων. Στο event CountDown.fired(), κάκε 10 δευτερόλεπτα κα αναβoςβινει το κόκκινο led και κα γίνεται ζλεγχοσ για το αν χωράει το θ δομι του μθνφματοσ test_serial_msg_t ςτο payload του πακζτου message_t όπωσ ακριβϊσ κάναμε και ςτθ προθγοφμενθ εφαρμογι. Αν θ ςυνάρτθςθ Packet.getPayload επιςτρζψει NULL τότε το μινυμά μασ δεν χωράει και ςταματάει θ διαδικαςία μετάδοςθσ. Διαφορετικά κάνουμε ανάκεςθ του δεδομζνου μασ data ςτο μοναδικό πεδίο τθσ δομισ test_serial_msg_t με τθν γραμμι κϊδικα mp counter = data; όπωσ ακριβϊσ δθλαδι γεμίηουμε τισ μεταβλθτζσ μιασ δομισ και ςτθ γλϊςςα C. Στθ ςυνζχεια καλοφμε τθν εντολι send τθν οποία ςτο wiring κα τθν ςυνδζςουμε, μζςω interface, με το κατάλλθλο component ζτςι ϊςτε να υλοποιεί ςειριακι αποςτολι μζςω UART. Η εντολι call UARTSend.send(AM_BROADCAST_ADDR, &packet, sizeof(test_serial_msg_t)) παίρνει παράμετρο για τθν διεφκυνςθ παραλιπτθ τθ ςτακερά broadcast, αφοφ ςφμφωνα με τθ κεωρία αυτό απαιτείται για τθν επίτευξθ τθσ μετάδοςθσ, δεφτερθ παράμετρο το πακζτο τφπου message_t ςτο payload του οποίου ζχει τοποκετθκεί το μινυμά μασ, και τρίτθ παράμετρο το μζγεκοσ αυτοφ του payload. Το πρόγραμμα ανάβει/ςβινει το πράςινο led, ανάλογα με τθν αρχικι του κατάςταςθ λογικι toggle, για να δείξει ςτο χριςτθ ότι θ αποςτολι βρίςκεται ςε εξζλιξθ κλειδϊνοντασ και το ςειριακό κανάλι για να μθν επιχειρθκεί ταυτόχρονα και άλλθ μετάδοςθ και οδθγθκοφμε ςε ςφγκρουςθ πακζτων. Αν θ ςυνάρτθςθ send δεν τρζξει ςωςτά και το πακζτο δεν ςταλεί, τότε το ςφάλμα οπτικοποιείται με το άνοιγμα/ςβιςιμο του κίτρινου led. Τζλοσ υλοποιείται και το event UARTSend.sendDone() το οποίο με απλό ζλεγχο πάλι, ςυγκρίνει το πακζτο που επιςτρζφει θ senddone() με το πακζτο που ςτείλαμε. Αν ζχουμε ταφτιςθ, ςθμαίνει ότι ςτάλκθκε το ςωςτό πακζτο και το κανάλι ελευκερϊνεται και είναι διακζςιμο για μετάδοςθ ξανά (locked = FALSE). Το μόνο που μζνει για να κάνουμε τθν εφαρμογι του Base Station μασ λειτουργικι είναι να υλοποιιςουμε το configuration. Αναπτφςςουμε λοιπόν το component MyBasestationAppC.nc δθλϊνοντασ τα components που χρθςιμοποιοφνται και κάνοντασ το wiring. Αυτό που πρζπει να παρατθριςουμε ςτο wiring τθσ εφαρμογισ αυτισ είναι ότι επειδι χρθςιμοποιοφμε δφο μετρθτζσ ορίηοντάσ τουσ από το generic interface Timer<TMilli>, πρζπει να τουσ ςυνδζςουμε και τουσ δφο με το component που περιζχει υλοποίθςθ για τουσ μετρθτζσ. Το 76

77 component αυτό είναι το TimerMilliC() το οποίο είναι ζνα generic configuration. Ζτςι, επειδι ζχουμε δφο μετρθτζσ δθμιουργοφμε δφο ςτιγμιότυπά του που για χάριν ευκολίασ τα ονομάηουμε με τα ίδια ονόματα που ζχουν και οι μετρθτζσ ςτο module, χρθςιμοποιϊντασ τθ δεςμευμζνθ λζξθ as. Επίςθσ, το component που περιζχει τθν υλοποίθςθ τθσ ςειριακισ επικοινωνίασ δεν είναι άλλο από το SerialActiveMessageC ςτο οποίο δίνουμε το όνομα Serial για ςυντόμευςθ (για τον ίδιο λόγο ονομάηω το module τθσ εφαρμογισ από MyBasestationC ςε App). Το component αυτό είναι ζνα configuration που παρζχει, εκτόσ των άλλων, τα interfaces AMSend[am_id_t id], SplitControl και Packet. Στο wiring του implementation block του χρθςιμοποιεί τον τελεςτι = ζτςι ϊςτε τα παραπάνω interfaces να χρθςιμοποιοφν το implementation άλλων components ςαν δικό τουσ! Αυτό γίνεται γιατί το SerialActiveMessageC όπωσ είπαμε είναι configuration και αυτά, ςαν τα modules, μποροφν να παρζχουν interfaces. Πμωσ επειδι δεν ζχουν κϊδικα εξ οριςμοφ μζςα τουσ για να υλοποιιςουν τα interfaces αυτά, χρθςιμοποιοφν τον τελεςτι = για να παίρνουν τον κϊδικα από άλλα components. Ζτςι, το AMSend[am_id_t id] και το Packet interface που παρζχονται από το SerialActiveMessageC χρθςιμοποιοφν τον κϊδικα του component SerialActiveMessageP, ενϊ το SplitControl τον κϊδικα του SerialDespatcherC. Η γραμμι κϊδικα που πρζπει να ςχολιαςτεί ςε αυτό το ςθμείο είναι θ εξισ: App.UARTSend Serial.AMSend[ AM_TEST_SERIAL_MSG];. Ππωσ είδαμε και παραπάνω το SerialActiveMessageC παρζχει το interface AMSend[am_id_t id]. Το I.D. (AM ID = Active Message Identification) είναι παρόμοιο με ζνα port number ςτο TCP ι UDP. Επειδι μπορεί να ζχω πολλζσ υπθρεςίεσ ι πρωτόκολλα που τρζχουν ςε ζναν κόμβο (με πολλαπλά send/receive interfaces) αυτό το I.D. επιςθμαίνει πιο μζροσ του κϊδικα πρζπει να λάβει το μινυμα που ζρχεται. Για να γίνει αυτό είναι απαραίτθτθ μια αντιςτοίχθςθ. Αυτι τθ δυνατότθτα μου τθν δίνει θ χριςθ των ςυγκεκριμζνων I.D. τα οποία και ορίηω με το keyword enum ςε κάποιο header file τθσ εφαρμογισ. Στθν ουςία, ο τφποσ am_id_t είναι uint8_t και επιτρζπει πολλαπλά πρωτόκολλα να χρθςιμοποιοφν τισ επικοινωνίεσ ενεργοφ μθνφματοσ (ΑΜ = Active Message) χωρίσ να ζχω ςυγκροφςεισ. Κάκε am_id_t που χρθςιμοποιείται ςτα πλαίςια ενόσ δικτφου πρζπει να ζχει μια μοναδικι δομι πακζτου (packet format) ζτςι ϊςτε το ίδιο το am_id_t ςυνδυαηόμενο με τα περιεχόμενα του πακζτου να είναι αρκετά για να προςδιορίςουν το ακριβζσ format του πακζτου. Από τα παραπάνω, είναι εμφανζσ, ότι ζνα πρόγραμμα δεν κα πρζπει να δθμιουργεί δφο ςτιγμιότυπα του AMSend[id] με το ίδιο am_id_t. Το ίδιο ιςχφει και για το interface ΑΜReceive[id]. Επίςθσ, πρζπει να είμαςτε προςεκτικοί όταν ορίηουμε το enum για τθν τιμι του id, για να μθν δϊςω αρικμοφσ που χρθςιμοποιοφνται ιδθ ςε μια άλλθ λειτουργία. Στθν εφαρμογι μασ ο οριςμόσ τθσ ςτακεράσ AM_TEST_SERIAL_MSG, που χρθςιμοποιοφμε για id, γίνεται ςτον header file TestSerial.h και ζχει τθν τιμι 0x89 Hex (= 137) Εγκατάςταςθ ςε πραγματικό κόμβο IRIS και ζλεγχοσ Για να λειτουργιςει θ εφαρμογι ςτο περιβάλλον για το οποίο αναπτφχκθκε, δθλαδι ςε ζναν κόμβο IRIS ςτα πλαίςια ενόσ WSN, πρζπει πρϊτα να γίνει compile και, αν δεν ζχω ςφάλματα, να κάνω εγκατάςταςθ τθσ εφαρμογισ ςτον κόμβο. Αφοφ 77

78 ζχω κάνει εγκατάςταςθ τουσ drivers, βάηω το αναπτυξιακό board MIB520 ςε μια κφρα USB και ανοίγω το εικονικό PC που ζχει λειτουργικό Linux Ubuntu. Πμωσ εγϊ ζχω ςυνδζςει μια πραγματικι ςυςκευι ςε μια USB κφρα του πραγματικοφ υπολογιςτι. Ρρζπει να κάνω (mount) τθν πραγματικι ςυςκευι ςτθν USB με το εικονικό περιβάλλον για να μπορϊ να τθν διαχειρίηομαι από εκεί. Στο γραφικό περιβάλλον των linux πθγαίνω «devices USB devices Crossbow MIB520CA[0500]». Αυτόματα γίνεται εγκατάςταςθ των drivers, αν δεν ζχουν γίνει. Στθ ςυνζχεια, ανοίγω ζνα παράκυρο τερματικοφ και πθγαίνω ςτο φάκελο που είναι θ εφαρμογι μου «cd Desktop/MyBasestation_new» και πατάω τθν εντολι για compile ςε IRIS πλατφόρμα «make iris». Με αυτόν τον τρόπο γίνεται το compile για τον πραγματικό κόμβο και όχι για εξομοίωςθ. Ραράγονται τα κατάλλθλα αρχεία και θ μεταγλϊττιςθ ολοκλθρϊνεται με επιτυχία. Σε αυτι τθ φάςθ δθμιουργείται ο φάκελοσ Built ςτο directory τθσ εφαρμογισ. Ρλζον, είμαςτε ζτοιμοι να κάνουμε εγκατάςταςθ ςε ζναν κόμβο IRIS. Τοποκετοφμε τον κόμβο που κζλουμε να λειτουργιςει ςαν ςτακμόσ βάςθσ, πάνω ςτον 51-pin connector του αναπτυξιακοφ. Ππωσ ζχουμε ιδθ ξαναπεί, το ΜΙΒ520 ζχει bus τροφοδοςίασ μζςω τθσ USB ςφνδεςθσ και δεν χρειάηεται εξωτερικι πθγι ενζργειασ για να λειτουργιςει. Για αυτό το λόγο, ο κόμβοσ που ςυνδζω ςτο αναπτυξιακό δεν πρζπει να ζχει μπαταρίεσ πάνω του ι ακόμα και αν τισ ζχει πρζπει να βεβαιωκϊ ότι ο διακόπτθσ λειτουργίασ είναι ςτο OFF. Επίςθσ, αν θ ςφνδεςθ κόμβου ΜΙΒ520 είναι καλι τότε ςτιγμιαία κα αναβοςβιςουν και τα τρία led (κόκκινο D2, πράςινο D7, κίτρινο D4). Αν αυτό δεν ςυμβεί, ςθμαίνει ότι το mote δεν ζχει «κάτςει» καλά ςτον 51-pin connector και δεν πρζπει να ςυνεχίςω με τθν εγκατάςταςθ τθσ εφαρμογισ μου γιατί δεν κα γίνει ςωςτά. Το τελευταίο ιςχφει μόνο αν ο κόμβοσ δεν ζχει μζςα εγκατεςτθμζνθ άλλθ εφαρμογι από πριν γιατί τότε τα led κα αναβοςβινουν ανάλογα με τισ προδιαγραφζσ τθσ υπάρχουςασ εφαρμογισ. Για να γίνει θ εγκατάςταςθ, πλθκτρολογϊ «make iris install mib510,/dev/ttyusb0» και θ εφαρμογι εγκακίςταται ςτο mote. Να ςχολιάςουμε, ότι παρόλο που χρθςιμοποιοφμε το board MIB520, ςτο τερματικό ςτθν εντολι γράφω mib510 ςαν παράμετρο αφοφ και οι δφο ςυςκευζσ δθλϊνονται εκεί με τθν ίδια και τθν αυτι παράμετρο. Η δεφτερθ παράμετροσ δθλϊνει τθν κφρα μζςω τθσ οποίασ γίνεται ο προγραμματιςμόσ του mote. Θυμάμαι ότι κατά τθν εγκατάςταςθ του αναπτυξιακοφ μασ δόκθκαν δφο διακζςιμεσ κφρεσ για χριςθ. Οι dev/ttyusb0 για προγραμματιςμό και θ dev/ttyusb1 για επικοινωνία ςτα Linux, και θ COM4 και COM5 για τισ αντίςτοιχεσ λειτουργίεσ ςτα windows. Ζτςι, θ χριςθ τθσ παραμζτρου dev/ttyusb0 γίνεται άμεςα κατανοθτι. Επειδι, προσ ςτιγμιν δεν ζχουμε φτιάξει κάποιο πρόγραμμα για να διαβάηει τα δεδομζνα από τθ USB, κα χρθςιμοποιιςουμε ζνα ζτοιμο πρόγραμμα ςε java που υπάρχει ςτο TinyOS tree, το Listen. Το πρόγραμμα αυτό πρακτικά ςυγχρονίηεται με τθν USB και «ακοφει» για ειςερχόμενα πακζτα τα οποία και αποτυπϊνει ςτθν οκόνθ του τερματικοφ του εικονικοφ υπολογιςτι. Τα πεδία του πακζτου εμφανίηονται ςε δεκαεξαδικι μορφι (Hex). Στο τερματικό, πατάω τθν εντολι «java net.tinyos.tools.listen comm Τα περιςςότερα TinyOS επικοινωνιακά εργαλεία παίρνουν μια παράμετρο comm. Αυτι θ παράμετροσ επιτρζπει να προςδιορίςουμε τθν πθγι του πακζτου (packet source) ςαν string. Το packet source είναι θ βάςθ για επικοινωνία ανάμεςα ςε Mote PC αφοφ αποτελεί ζνα επικοινωνιακό μζςο με το οποίο μια εφαρμογι μπορεί να λάβει πακζτα από 78

79 ζναν κόμβο. Σαν packet sources μποροφν να κεωρθκοφν, για παράδειγμα, κάποια serial ports ι κάποιο TCP socket. Η παράμετροσ comm ζχει τθν εξισ δομι -comm Στθ κφρα port βάηω το /dev/ttyusb1 επειδι τϊρα κζλω επικοινωνία με τον κόμβο. Η ταχφτθτα <SPEED> μπορεί να είναι είτε αρικμθτικι τιμι είτε το όνομα τθσ πλατφόρμασ που χρθςιμοποιϊ. Δθλϊνοντασ το όνομα, είναι ςαν να λζω ςτο ςειριακό packet source να χρθςιμοποιιςει τθν default ταχφτθτα που είναι οριςμζνθ για αυτι τθ πλατφόρμα. Τα IRIS motes ζχουν, ςφμφωνα με τισ προδιαγραφζσ τουσ, baud rate ίςο με Αφοφ ςυγχρονιςτεί το πρόγραμμα με τθν ταχφτθτα τθσ κφρασ αρχίηουν να εμφανίηονται τα δεδομζνα ςτθν οκόνθ του τερματικοφ όπωσ φαίνεται και ςτθν εικόνα που ακολουκεί. Το πρόγραμμα δθμιουργεί ζνα packet source και απλά τυπϊνει το κάκε πακζτο που «βλζπει». Τα Εικόνα: Ζλεγχοσ τθσ εφαρμογισ MyBasestation με το Java πρόγραμμα Listen. πακζτα αυτά αποτελοφνται από διάφορα πεδία δεδομζνων. Το πρϊτο byte (00) δθλϊνει ότι πρόκειται για ΑΜ πακζτο. Τα υπόλοιπα πεδία είναι αυτά του generic SerialActiveMessageP.nc που χρθςιμοποιεί τον header serial.h, τον οποίο και ζχουμε κάνει include ςτθν εφαρμογι μασ, και περιγράφονται ςτθ δομι nx_struct_serial_header. Σφμφωνα με αυτόν τον header τα byte «FF FF» δθλϊνουν τθν διεφκυνςθ του παραλιπτθ θ οποία είναι μεταβλθτι τφπου nx_am_addr_t, που ςφμφωνα με το header file AM.h (και αυτόσ γίνεται include ςτθν εφαρμογι μασ για να είναι ορατόσ ςτο πρόγραμμα) είναι ςτθν ουςία τφποσ nx_uint16_t. Η τιμι «FF FF» είναι απόλυτα δικαιολογθμζνθ και τθν περιμζναμε αφοφ ζχουμε ορίςει μετάδοςθ broadband ςαν πρϊτθ παράμετρο ςτθν εντολι UARTSend.send() χρθςιμοποιϊντασ τθ ςτακερά AM_BROADBAND_ADDR, θ οποία ορίηεται ςτο AM.h και ζχει τθν τιμι 0xffff. Τα επόμενα 2 bytes «00 00» είναι θ διεφκυνςθ του κόμβου πθγισ. Επειδι το serial stack δεν δίνει τιμι ςτο link source address αυτό το πεδίο, που είναι τφπου nx_am_addr_t και αυτό, κα πρζπει να είναι πάντα μθδζν. Το επόμενο byte (nx_uint8_t) δθλϊνει το μζγεκοσ, ςε bytes, του payload του πακζτου. Το μζγεκοσ είναι πράγματι 2 bytes αφοφ τα δεδομζνα που ςτζλνουμε είναι τφπου nx_uint16_t. 79

80 Στθ ςυνζχεια ακολουκεί το group I.D. που είναι τφπου nx_am_group_t το οποίο ςφμφωνα με το AM.h είναι τφπου nx_uint8_t, δθλαδι ζνα byte. Η τιμι του είναι «00» μιασ και δεν ορίςτθκε πουκενά. Σφμφωνα με τθν δομι του μθνφματοσ που περιγράφεται ςτο Serial.h ακολουκεί ο Active Message handler type, τφπου nx_am_id_t (= nx_uint8_t), ζνα byte κατά ςυνζπεια και δεν είναι άλλο από το I.D. που κζςαμε για τθν ςειριακι μασ μετάδοςθ, δθλαδι το 0x89. Τζλοσ, το πεδίο που μζνει είναι τα δεδομζνα μασ. Ρράγματι πρόκειται για δφο bytes αφοφ ο αρικμόσ προσ μετάδοςθ που είχαμε ορίςει ιταν 16μπιτοσ και θ τιμι του που διαβάηουμε ςτο τερματικό είναι «00 0Α» που ςε δεκαδικι μορφι δεν είναι άλλθ από τθν τιμι 10, που είναι ο αρικμόσ που κζλαμε να ςτείλουμε. Επομζνωσ θ εφαρμογι λειτουργεί κανονικά. Να ςθμειωκεί εδϊ ότι ςτθ ςυγκεκριμζνθ εφαρογι, τα δεδομζνα αποςτζλλονται από τον κόμβο IRIS με big-endian format. Για παράδειγμα, ζνασ 16μπιτοσ Hex αρικμόσ με απεικόνιςθ «01 02» είναι ςτθν πραγματικότθτα ο 0x x x x16 0 = 258 ςε δεκαδικι μορφι. Αυτό το format όμωσ είναι ανεξάρτθτο από το endian-ness του επεξεργαςτι, ο ATmega1281 είναι αρχιτεκτονικισ little endian, ακριβϊσ επειδι το πακζτο μου είναι μια δομι nx_struct (platform independent) που είναι ζνα big endian network format. 5.5 Τλοποίθςθ των κυρίωσ εφαρμογϊν Ειςαγωγι: Προπαραςκευι και οργάνωςθ των εργαςιϊν Ο ςτόχοσ που κζτουμε πλζον είναι θ ανάπτυξθ εφαρμογισ, θ οποία κα βαςίηεται ςτθ λογικι του MoteSendReceiveSIM που παρουςιάςτθκε ςτθν αρχι, με τθ διαφορά ότι τϊρα δεν κα αποςτζλλονται από τον κόμβο τυχαίοι αρικμοί αλλά μετριςεισ που κα λαμβάνονται από το GPS module του sensor board MTS420CC. Τα MTS400/MTS420 sensor boards γενικά είναι ςυμβατά με τθν οικογζνεια κόμβων MICA. Τα IRIS motes ανικουν ςε αυτιν τθν οικογζνεια κόμβων. Το MTS420CC είναι πιο καινοφρια ζκδοςθ των MTS420CA και MTS420CB. Ρεριλαμβάνει ζνα GPS δζκτθ από τθν εταιρεία ublox, ςε αντίκεςθ με τισ 2 προθγοφμενεσ εκδόςεισ που χρθςιμοποιοφν δζκτθ τθσ εταιρείασ Leatdek. Το ublox module ζχει προδιαγραφζσ για μεγαλφτερθ ακρίβεια ςε κατάςταςθ λειτουργίασ και για χαμθλότερθ κατανάλωςθ ρεφματοσ ςε ςφγκριςθ με το ολοκλθρωμζνο τθσ εταιρείασ Leadtek. Εκτόσ από το GPS module, θ πλακζτα MTS420CC διακζτει και τουσ εξισ αιςκθτιρεσ: Τγραςίασ και Θερμοκραςίασ Βαρομετρικισ Πίεςθσ Αιςκθτιρα φωτόσ Επινταχυςιόμετρο 2-αξόνων Οι drivers για το GPS module του MTS420CC είναι ακόμα υπό μελζτθ και ειδικά για το TinyOS-2.x. Στο διαδίκτυο ςε open source μορφι, μετά από ψάξιμο βρικαμε 80

81 drivers για το TinyOS 2 του GPS module του MTS420. Πμωσ, οι ςυγκεκριμζνοι και μοναδικοί που υπιρχαν ιταν ςχεδιαςμζνοι για πλατφόρμεσ micaz (γενιά κόμβων πριν τα IRIS) και το ολοκλθρωμζνο GPS τθσ εταιρίασ Leadtek. Ζτςι, πρζπει να βαςιςτοφμε ςε αυτοφσ για να φτιάξουμε δικοφσ μασ drivers για GPS module τθσ εταιρείασ ublox (MTS420CC) και να είναι ςυμβατοί με τουσ κόμβουσ IRIS. Συγκεντρϊνοντασ λοιπόν τα δεδομζνα μασ, διακζτουμε drivers που απαιτοφν: TinyOS 2.x λειτουργικό ςφςτθμα MicaZ motes και ζνα μζςο για τον προγραμματιςμό του MTS420 (CA ι CB) sensor board GPS κεραία ςυμβατι με το MTS420 board Εμείσ κζλουμε να φτιάξουμε drivers που κα είναι ςυμβατοί με: TinyOS 2.x λειτουργικό ςφςτθμα IRIS motes MTS420CC με GPS module τθσ εταιρείασ ublox Μιασ και ςτο TOS tree δεν υπάρχει καμία πρόβλεψθ για χριςθ του sensor board MTS420CC, κατεβάηουμε τα components που αποτελοφν τουσ υπάρχοντεσ drivers για τθν πλακζτα και τα τοποκετοφμε ςε κατάλλθλουσ φακζλουσ ςε αυτό. Ο κϊδικασ για ζνα sensor board ςτο TinyOS αποτελείται από πολλά components τα οποία κατανζμονται ςε επίπεδα. Σε αυτά τα επίπεδα κα διαχωρίςουμε τα components που κατεβάςαμε από το διαδίκτυο και κα τα αποκθκεφςουμε πριν επζμβουμε ςε αυτά με τροποποιιςεισ για να τα κάνουμε να ανταποκρίνονται ςτισ προδιαγραφζσ του δικοφ μασ ςυςτιματοσ. Αυτά τα επίπεδα ζχουν μια οργάνωςθ μζςα ςτθ δομι του TOS tree. Διακρίνουμε: Independent Chip Code το sensor board είναι μια ςφνκεςθ από διαφορετικά ολοκλθρωμζνα. Οριςμζνα από αυτά είναι αρκετά περίπλοκα και περιγράφονται από κϊδικα που δεν εξαρτάται από τθν πλατφόρμα (platform independent code) που βρίςκεται ςτθ τοποκεςία tos/chips/<chipname> Sensor board Dependent Chip Code Μερικά chips κα απαιτιςουν κϊδικα ςυγκεκριμζνο για τισ φυςικζσ ςυνδζςεισ που γίνονται ςτθ πλακζτα και ο κϊδικασ αυτόσ βρίςκεται ςτο tos/sensorboards/<boardname>/chips/<chipname> Platform Dependent Sensorboard Code κάποιοι κϊδικεσ εξαρτϊνται από τισ ςυγκεκριμζνεσ πλατφόρμεσ ςτισ οποίεσ ςυνδζεται το board, για παράδειγμα οτιδιποτε που χρθςιμοποιεί τα buses που ελζγχονται από τθ πλατφόρμα. Αυτοί οι κϊδικεσ είναι ςτο tos/platforms/<platformname>/sensorboards/<boardname> και να είναι οργανωμζνοι ςε ζνα παρόμοιο chips/<chipname> υπό-φάκελο ανάλογα με τθν περίπτωςθ. Independent Helper Code κϊδικασ που μπορεί να γραφεί και να είναι ανεξάρτθτοσ τθσ πλακζτασ αιςκθτιρων προςτίκεται ςτο φάκελο tos/lib/<name> Dependent Helper Code κϊδικασ που περιγράφει χριςιμα χαρακτθριςτικά του sensor board και είναι ςυνυφαςμζνοσ με αυτό βρίςκεται ςτο μονοπάτι tos/sensorboards/<boardname> Η τροφοδοςία με ρεφμα και θ επικοινωνία με τουσ αιςκθτιρεσ που βρίςκονται ςτο MTS420 ελζγχεται από δφο αναλογικοφσ οκταδικοφσ (octal), ςειριακά ςυνδεδεμζνουσ διακόπτεσ ADG715. Αυτοί ελζγχονται από ζνα I2C bus, που είναι ζνα bus το οποίο προςφζρει εφκολθ επικοινωνία μεταξφ οντοτιτων που 81

82 βρίςκονται ςτο ίδιο ολοκλθρωμζνο. Ο Independent chip κϊδικασ για το ADG715 είναι ζνα generic component ζτςι ϊςτε να μποροφν να δθμιουργοφνται ςτιγμιότυπά του για όποια πλατφόρμα χρθςιμοποιείται. Το component adg715controlp παρζχει ζνα παραμετροποιθμζνο interface καναλιοφ με περιοριςμζνεσ τιμζσ μεταξφ του 1 (ADG715_CH_MIN) και του 8 (ADG715_CH_MAX) που ορίηονται ςτον header adg715.h, αφοφ πρόκειται για ζνα 8-bit chip. Επειδι κζλουμε να χρθςιμοποιιςουμε το GPS module πρζπει να ςυμπεριλάβουμε τον κϊδικα που μασ δίνει επικοινωνία με το GPS chip αλλά και τον κϊδικα υποςτιριξθσ, όπωσ τα interfaces SyncUartStream και τον κϊδικα του πρωτοκόλλου ΝΜΕΑ. Η μονάδα GPS είναι αρκετά απλι ςτθ ςυμπεριφορά επειδι το ίδιο το ολοκλθρωμζνο είναι ωσ επί το πλείςτον αυτοδφναμο. Ζξω από το ολοκλθρωμζνο, όμωσ, αυτό που πρζπει να κάνουμε είναι να επιλζγω τον ςυγκεκριμζνο αιςκθτιρα από τθ πλακζτα, να τον ενεργοποιϊ και να ακοφω ςτθ ςυνζχεια τθν UART για ειςερχόμενα bytes. Ο δζκτθσ GPS που κα χρθςιμοποιιςουμε ςτθν εφαρμογι μασ λοιπόν είναι o LEA-4A τθσ εταιρείασ ublox και βρίςκεται πάνω ςτο MTS420CC. Ο δζκτθσ αυτόσ, όπωσ περιγράψαμε και ςε προθγοφμενα κεφάλαια, χρθςιμοποιεί το πρωτόκολλο ΝΜΕΑ για τθν επικοινωνία με τουσ δορυφόρουσ και τθν ςυλλογι δεδομζνων ςε «προτάςεισ». Οι προτάςεισ που ςυμπλθρϊνει και διαχειρίηεται αυτόσ ο δζκτθσ GPS είναι οι εξισ επτά: GP GSA, GP GSV, GP GLL, GP ZDA, GP RMC, GP VTG, GP GGA. Η «πρόταςθ» όμωσ που κα απομονϊςουμε εμείσ για λιψθ και επεξεργαςία ςτον κόμβο-βάςθ είναι θ GGA. Ρρόκειται για μια από τισ πιο ςθμαντικζσ ΝΜΕΑ «προτάςεισ», γιατί παρζχει fix και ακριβι δεδομζνα με δυνατότθτα τριςδιάςτατου εντοπιςμοφ κζςθσ. Η δομι τθσ «πρόταςθσ» αυτισ είναι θ εξισ: $GPGGA,hhmmss.ss,llll.ll,a,yyyyy.yy,a,x,xx,x.x,x.x,M,x.x,M,x.x,xxxx*hh Ππωσ ςε κάκε «πρόταςθ» ΝΜΕΑ, τα πεδία τθσ χωρίηονται μεταξφ τουσ με κόμματα. Τα περιεχόμενα των πεδίων ζχουν τθν ακόλουκθ ερμθνεία: Πεδίο 1: Ο χρόνοσ λιψθσ τθσ μζτρθςθσ ςε όρουσ UTC Πεδίο 2: Γεωγραφικό πλάτοσ ςε μορφι «Μοίρεσ - δεκαδικά λεπτά» Πεδίο 3: Κατεφκυνςθ γεωγραφικοφ πλάτουσ (Βοράσ ι Νότοσ) Πεδίο 4: Γεωγραφικό μικοσ ςε μορφι «Μοίρεσ - δεκαδικά λεπτά» Πεδίο 5: Κατεφκυνςθ γεωγραφικοφ μικουσ (Ανατολι ι Δφςθ) Πεδίο 6: Δείκτθσ ποιότθτασ του ςιματοσ GPS Πεδίο 7: Αρικμόσ ορατϊν, από το δζκτθ, δορυφόρων Πεδίο 8: Οριηόντια αραίωςθ τθσ κζςθσ Πεδίο 9: Φψοσ τθσ κεραίασ πάνω από το μζςο επίπεδο τθσ κάλαςςασ (γεωειδζσ) Πεδίο 10: Μονάδα φψουσ (μζτρα) του πεδίου 9 Πεδίο 11: Φψοσ γεωειδοφσ (μζςο επίπεδο κάλαςςασ) πάνω από το ελλειψοειδζσ WGS84 Πεδίο 12: Μονάδα φψουσ (μζτρα) του πεδίου 11 Πεδίο 13: Χρόνοσ ςε δευτερόλεπτα τθσ τελευταίασ ενθμζρωςθσ από ζναν διαφορικό ςτακμό αναφοράσ Πεδίο 14: Ταυτότθτα (I.D.) του διαφορικοφ ςτακμοφ αναφοράσ Πεδίο 15: Checksum το οποίο αρχίηει πάντα με αςτεράκι (*) 82

83 Ραράδειγμα χριςθσ τθσ «πρόταςθσ» φαίνεται ςτθν παρακάτω εικόνα. Εικόνα: Παράδειγμα πραγματικισ χριςθσ τθσ ΝΜΕΑ sentence GGA Ανάπτυξθ driver του MTS420CC για πλατφόρμα IRIS Ζχοντασ κατεβάςει και τοποκετιςει τα components για τουσ υπάρχοντεσ drivers ςυμβατοφσ με micaz motes για διάβαςμα από το GPS module του MTS420, ςτουσ κατάλλθλουσ φακζλουσ ςτο TOS tree, το επόμενο βιμα είναι θ αναβάκμιςι τουσ ζτςι ϊςτε να είναι ςυμβατοί με πλατφόρμεσ IRIS και τθ πλακζτα MTS420CC ςυγκεκριμζνα. Επειδι και ο δζκτθσ GPS τθσ ublox και ο αντίςτοιχοσ τθσ Leadtek χρθςιμοποιοφν το πρότυπο NMEA 0183 για επικοινωνία με τουσ δορυφόρουσ GPS, μασ οδιγθςε ςτθ ςκζψθ ότι ο driver για το ublox module κα μποροφςε να χτιςτεί πάνω ςε ζνα μεγάλο κομμάτι του driver για το Leadtek module. Το πρϊτο πράγμα που κοιτάμε είναι τα datasheets των δφο πλατφόρμων για να εντοπίςουμε διαφορζσ ςτο υλικό. Σαν μια νεότερθ ζκδοςθ των micaz, τα IRIS ζχουν τρεισ φορζσ πιο βελτιωμζνο radio range και ςχεδόν διπλάςια μνιμθ από αυτοφσ. Η πρϊτθ ουςιαςτικι διαφορά που εντοπίςτθκε είναι ότι τα XM2110CA iris motes βαςίηονται ςτον μικροεπεξεργαςτι ATmega1281, ενϊ τα micaz motes ςτον ATmega128L. Είναι προφανζσ πωσ ςε ότι κάνουμε από εδϊ και πζρα πρζπει να χρθςιμοποιοφμε τα components που βρίςκονται ςτο μονοπάτι /opt/tinyos /tos/chips/atm1281, όπου υπάρχει και το component για τον επεξεργαςτι αυτόν με όνομα HplAtm128UartP.nc. Επειδι το ίδιο αρχείο με το ίδιο όνομα υπάρχει ςτο μονοπάτι /opt/tinyos-2.1.1/tos/chips/atm128 για τον αντίςτοιχο επεξεργαςτι, αλλάηουμε το όνομα του ςε HplAtm1281UartP.nc χρθςιμοποιϊντασ τθν εντολι ςτο τερματικό «sudo cp HplAtm128UartP.nc HplAtm1281UartP.nc» όντασ ςτον φάκελο Atm1281. Αφοφ αλλάξαμε το όνομα του component, πρζπει να μποφμε ςτον κϊδικά του και να κάνουμε τθν αντίςτοιχθ αλλαγι και ςτο όνομα του module. Το configuration component για τον επεξεργαςτι είναι το HplAtm128UartC.nc. Το component αυτό, ςε αντίκεςθ με το module, είναι μοναδικό και βρίςκεται μόνο ςτον φάκελο /opt/tinyos-2.1.1/tos/chips/atm128 του chip 83

84 Atm128. Επεμβαίνουμε ςτο αρχείο αυτό αλλάηοντασ ςτον κϊδικά του το HplAtm128UartP ςε HplAtm1281UartP. Η αλλαγι αυτι ςτο configuration component ςυνεπάγεται ότι αλλάηουμε το wiring και πλζον ηθτάμε να γίνεται ςφνδεςθ με τισ λειτουργίεσ του microcontroller Atm1281 και όχι με τισ αντίςτοιχεσ του Atm128 που ιταν ςτθν αρχι. Ζτςι, πλζον κάκε φορά που κα γίνεται αναφορά ςτο υλικό IRIS κα χρθςιμοποιοφνται οι λειτουργίεσ του επεξεργαςτι Atm1281. Επίςθσ κάνοντασ μια ςφγκριςθ των αρχείων HplAtm128UartP (από τον φάκελο Atm128) και HplAtm1281UartP (από τον φάκελο Atm1281) παρατθροφμε ότι ςτο τελευταίο λείπει θ υλοποίθςθ των εντολϊν async command void HplUart0Config.getConfig(atm128_uart_config_t *cfg), -, async command void HplUart0Config.setConfig(atm128_uart_config_t *cfg), - και των async command void HplUart1Config.getConfig(atm128_uart_config_t *cfg), -, async command void HplUart1Config.setConfig(atm128_uart_config_t *cfg), - που υπάρχουν ςτο πρϊτο. Ουςιαςτικά μεταφζρω αυτζσ τισ γραμμζσ κϊδικα και ειςάγω ςτθν αρχι του component HplAtm1281UartP, τθ διλωςθ διπλισ παροχισ του interface HplAtm128UartConfig.nc με τα διακριτά ονόματα HplUart0Config και HplUart1Config, εντολζσ του οποίου είναι οι παραπάνω που υλοποιιςαμε με τθ μεταφορά κϊδικα. Ρλζον λοιπόν το χρθςιμοποιοφμενο HplAtm1281UartP παρζχει και το interface αυτό για τθ διαμόρφωςθ τθσ ςειριακισ UART, όπωσ ζκανε και ο προκάτοχόσ του. Οι τροποποιιςεισ ςτο HplAtm1281UartP.nc δεν ςταματοφν εκεί. Ρρζπει να κάνω αλλαγζσ και ςτισ ςτακερζσ που χρθςιμοποιοφνται. Η λογικι είναι ότι ςτον Atm128 ζχω κάποιεσ πρότυπεσ ςτακερζσ οριςμζνεσ, όπωσ για παράδειγμα τθν U2X για όνομα bit ςτον ζλεγχο τθσ UART, ενϊ ςτον Atm1281 ζχω δφο τζτοιεσ ςτακερζσ, τθν U2X0 και τθν U2X1 για τθν εκπροςϊπθςθ του κάκε bit των UART0 και UART1 κακϊσ ζχει διαφορετικι προςζγγιςθ διαχείριςθσ τθσ ςειριακισ κφρασ (51-pin connector). Στον επιπλζον κϊδικα, επομζνωσ, που μετζφερα ςτο HplAtm1281UartP από το HplAtm128UartP για τθν υλοποίθςθ των εντολϊν του παρεχόμενου interface HplAtm128UartConfig.nc αλλάηω τισ ςτακερζσ: από TXEN ςε TXEN0 και TXEN1 από RXEN ςε RXEN0 και RXEN1 από TXCIE ςε TXCIE0 και TXCIE1 από RXCIE ςε RXCIE0 και RXCIE1 από TXC ςε TXC0 και TXC1 από RXC ςε RXC0 και RXC1 από U2X ςε U2X0 και U2X1 από UCSZ1 ςε UCSZ10 και UCSZ11 από UCSZ0 ςε UCSZ00 και UCSZ01 από UPM1 ςε UPM10 και UPM11 από UPM0 ςε UPM00 και UPM01 από USBS ςε USBS0 και USBS1 από UDRE ςε UDRE0 και UDRE1 όπου προφανϊσ οι ςτακερζσ με «0» ςτο τζλοσ αναφζρονται ςτο κομμάτι κϊδικα για το HplUart0Config, ενϊ αυτζσ με το «1» ςτο κομμάτι κϊδικα για το HplUart1Config. Επόμενθ τροποποίθςθ που κάναμε είναι θ εξισ. Και ςτουσ δφο φακζλουσ Atm128/Atm1281 υπάρχει το component, για τθν διαχείριςθ τθσ ενζργειασ του μικροεπεξεργαςτι, McuSleepC.nc με διαφορετικι προφανϊσ λειτουργία για τον 84

85 κάκε επεξεργαςτι. Εμείσ κα αντικαταςτιςουμε ςτο wiring το χρθςιμοποιοφμενο component McuSleepC.nc που βρίςκεται ςτο /opt/tinyos-2.1.1/tos/chips/atm128 με το αντίςτοιχο που βρίςκεται ςτο /opt/tinyos-2.1.1/tos/chips/atm1281. Για να γίνει πιο ευδιάκριτθ θ δουλειά μασ, μετονομάηουμε το component του Atm1281 από McuSleepC.nc ςε McuSleep1C.nc κάνοντασ και εδϊ τθν απαραίτθτθ αλλαγι του ονόματοσ του module ςτον κϊδικά του. Το McuSleepC.nc χρθςιμοποιείται από το configuration TinySchedulerC.nc που βρίςκεται ςτο /opt/tinyos /tos/system/TinySchedulerC.nc. Αποκτϊ πρόςβαςθ ςε αυτό και αλλάηω ςτο wiring το McuSleepC.nc, όπου αναφζρεται, ςε McuSleep1C.nc για να γίνει ςφνδεςθ με τισ λειτουργίεσ του τελευταίου. Επειδι το McuSleepC.nc χρθςιμοποιείται ςε αρκετζσ περιπτϊςεισ ακόμα, τθν τελευταία αλλαγι τθν επαναλαμβάνω και ςτα configurations /opt/tinyos-2.1.1/tos/chips/atm128/hplatm128uartc.nc, /opt/tinyos-2.1.1/tos/chips/atm1281/timer/hplatm1281timer2asyncc.nc που είναι ζνασ timer ο οποίοσ ςυνδζεται με το McuSleepC.nc για τθν επίτευξθ υπολογιςμϊν με χαμθλι κατανάλωςθ, /opt/tinyos /tos/chips/atm128/spi/HplAtm128SpiC.nc που ενςωματϊνει τθ βαςικι SPI ςφνδεςθ για τον atm128, /opt/tinyos-2.1.1/tos/chips/atm128/spi/atm128spic.nc. Το επόμενο βιμα ςτθν πρόοδο ανάπτυξθσ του driver ιταν να εξετάςουμε τα κομμάτια του κϊδικα ςτα οποία κακορίηονται οι ρυκμίςεισ του υλικοφ και να τισ τροποποιιςουμε ζτςι ϊςτε να ανταποκρίνονται ςτισ προδιαγραφζσ που αναφζρονται ςτο εγχειρίδιο τθσ εταιρείασ ublox. Ο πρϊτοσ ςτόχοσ εντοπίςτθκε ςτο αρχείο Nmea.h, που είναι header για το πρότυπο ΝΜΕΑ. Ριο ςυγκεκριμζνα ςτο κομμάτι που απεικονίηεται ςτθ παραπάνω εικόνα, αφαιρζκθκε το ςχόλιο από τθ τρίτθ γραμμι (θ γραμμι ζγινε uncomment) για να υπάρχει ταίριαςμα με τισ προδιαγραφζσ του πακζτου ΝΜΕΑ που ςτζλνεται από τον δζκτθ GPS ublox. Επιπλζον, πρζπει να γίνει ρφκμιςθ του baud rate με το οποίο το GPS module επικοινωνεί με το mote. Το module τθσ εταιρείασ Leadted ιταν ςχεδιαςμζνο να επικοινωνεί με ταχφτθτα ςτα 4800 Baud. Το αντίςτοιχο όμωσ τθσ εταιρείασ ublox που χρθςιμοποιοφμε εμείσ ζχει default ρφκμιςθ ταχφτθτασ ςτα 9600 Baud, όπωσ φαίνεται και από τον παρακάτω πίνακα που λιφκθκε από το εγχειρίδιο τθσ ublox. 85

86 Εικόνα: Default ρυκμίςεισ επικοινωνίασ του GPS module LEA-4A τθσ ublox Ζτςι κάνουμε τισ απαραίτθτεσ μετατροπζσ ςτο component HplGps9546P.nc και αλλάηουμε τθν ταχφτθτα από τα 4800 ςτα 9600 baud ςτο implementation του module αυτοφ. Το component αυτό βρίςκεται ςτο μονοπάτι /tos/platforms/iris/sensorboards/mts420/chips/gps9546, δθλαδι ςτο επίπεδο όπου βρίςκονται οι Platform Dependent Sensorboard Codes. Εικόνα: Σο τμιμα του component HplGps9546P.nc που υπζςτθ τισ αλλαγζσ Με αυτζσ τισ ενζργειεσ ολοκλθρϊνεται θ δθμιουργία του driver για το GPS module LEA-4A τθσ εταιρείασ ublox, που περιλαμβάνεται ςτο MTS420CC Ανάπτυξθ εφαρμογισ για λιψθ μετριςεων GPS από το sensor board MTS420CC Στθ ςυνζχεια κα υλοποιιςουμε τθν εφαρμογι για διάβαςμα τθσ ΝΜΕΑ «πρόταςθσ» GGA, από τον δζκτθ GPS, και τθν αποςτολι τθσ, μζςω του πομποδζκτθ, ςτον κόμβο base station. Η εφαρμογι κα βρίςκεται ςτον φάκελο με όνομα MyMoteSendReceiveGPS. Ξεκινάμε τθν υλοποίθςθ από το module τθσ εφαρμογισ, με όνομα MyMoteSendReceiveC.nc. 86

87 Ξεκινϊντασ τθν εφαρμογι μασ κάνουμε τα απαραίτθτα includes για τθν επικοινωνία του κόμβου με το GPS module. Χρθςιμοποιοφμε τουσ headers Nmea.h και NmeaGga.h. Στον πρϊτο δθλϊνονται με enum ςτακερζσ απαραίτθτεσ για τθν αναγνϊριςθ και τον ζλεγχο των ςυςτατικϊν των ειςερχόμενων ΝΜΕΑ «προτάςεων» από το GPS module. Ορίηονται εκτόσ των άλλων το ςφμβολο με το οποίο αρχίηει θ κάκε «πρόταςθ» ($), οι δφο χαρακτιρεσ τζλουσ που χρθςιμοποιοφνται και οι δφο από το module τθσ ublox (CR, LF), το κόμμα που διαχωρίηει τα πεδία τθσ «πρόταςθσ», το δεκαδικό ςθμείο για τθν ακρίβεια (.) κακϊσ και τα γράμματα Α, G, M, P για τθν αναγνϊριςθ του προκζματοσ. Επίςθσ ορίηεται θ δομι πακζτου nmea_raw_t τθσ οποίασ τθ χριςθ κα δοφμε ςτθ ςυνζχεια και ςτακερζσ που αφοροφν μεγζκθ πεδίων τθσ δομισ αυτισ. Στο δεφτερο header file ορίηονται, για ζλεγχο, όλεσ οι πικανζσ καταςτάςεισ του πεδίου Fix Quality τθσ GGA «πρόταςθσ», οι κζςεισ των πεδίων δεδομζνων μζςα ςτθ πρόταςθ (με βάςθ τον διαχωριςμό τουσ από τα κόμματα) αλλά και το αναμενόμενο μζγεκοσ που κα ζχει το κάκε πεδίο ςφμφωνα πάντα με τισ προδιαγραφζσ που είδαμε να ορίηει θ κεωρία για τθν ΝΜΕΑ «πρόταςθ» GGA που μασ ενδιαφζρει. Τζλοσ, δθλϊνεται θ δομι του πακζτου nmea_gga_msg_t, θ οποία είναι πολφ βαςικι, μιασ και κα αποτελζςει τον τρόπο μεταφοράσ των δεδομζνων μασ από τον απομακρυςμζνο κόμβο WSN ςτο ςτακμό βάςθσ. Τα πεδία τθσ δομισ δθλϊνονται με χριςθ τφπων δεδομζνων, οι οποίοι ορίηονται ςτουσ headers NmeaTimeStamp.h και NmeaCoordinates.h, που γίνονται include ςτθν αρχι του αρχείου αυτοφ. Το πρϊτο, ορίηει μια απλι δομι για τθν ανάκεςθ των τιμϊν του χρόνου ςαν τφπο δεδομζνων nmea_timestamp_t. Το δεφτερο, ορίηει με enum, πάλι, τα αρχικά για τθν διλωςθ τθσ κατεφκυνςθσ S(outh), N(orth), E(ast) και W(est) για Νότο, Βορρά, Ανατολι και Δφςθ αντίςτοιχα. Επίςθσ δθλϊνεται ο τφποσ δεδομζνων nmea_coordinate_t που ςτθν ουςία είναι μια νζα δομι, αφοφ οι ςυντεταγμζνεσ δεν είναι ζνασ απλόσ αρικμόσ αλλά αποτελείται από μοίρεσ, λεπτά και δευτερόλεπτα τθσ μοίρασ. Με το keyword typedef ορίηεται ζνασ νζοσ τφποσ δεδομζνων από ζναν ιδθ υπάρχον τφπο. Ζτςι, ορίηονται οι τφποι nmea_latitude_t και nmea_longitude_t για το γεωγραφικό πλάτοσ και μικοσ αντίςτοιχα. Ρίςω ςτο NmeaGga.h, τα πεδία τθσ δομισ nmea_gga_msg_t ορίςτθκαν με βάςθ κάποια από τα δεδομζνα που χρειαηόμαςτε από τθν «πρόταςθ» GGA και περιλαμβάνουν τον χρόνο, το γεωγραφικό μικοσ και πλάτοσ, το fix Quality, τον αρικμό των δορυφόρων ςε κζαςθ, το φψοσ, το φψοσ του γεωειδοφσ πάνω από το ελλειψοειδζσ. Τα υπόλοιπα πεδία τθσ πρόταςθσ δεν κα μασ απαςχολιςουν ςτθν παροφςα εργαςία και για αυτό το λόγο ζχουν γίνει «ςχόλιο» ςτον κϊδικα. Αξίηει να ςθμειϊςουμε ότι, όταν κζλω να ορίςω μια ακζραια ςτακερά ςτθν γλϊςςα nesc προτιμϊ τθ χριςθ του keyword enum. Αυτό γιατί μειϊνω τισ απαιτιςεισ ςε μνιμθ RAM ςε ςχζςθ με τθ χριςθ του cons int και του define. Στο signature block δθλϊνουμε τα interfaces που κα χρθςιμοποιιςουμε ςτθν εφαρμογι μασ. Εκτόσ από τα γνωςτά interfaces με τα οποία ζχουμε αςχολθκεί ξανά (Boot, Leds) πλζον χρθςιμοποιοφνται και καινοφρια. Καταρχάσ, ςφμφωνα και με τισ προδιαγραφζσ με τισ οποίεσ ξεκινιςαμε να αναπτφςςουμε τθν εφαρμογι μασ, αυτι κα εμπλζκει ςτθ λειτουργία τθσ και τον πομποδζκτθ, για επικοινωνία με τον ςτακμό βάςθσ, και τθν ςειριακι επικοινωνία μζςω UART, για μεταφορά δεδομζνων από το sensor board ςτον κόμβο. Επομζνωσ, κα υλοποιιςουμε δφο είδθ επικοινωνίασ ςτο mote και για αυτό πρζπει να είμαςτε αρκετά προςεκτικοί ςτον διαχωριςμό των λειτουργιϊν του κάκε είδουσ. Αρχι ςε αυτό γίνεται από τθ διλωςθ των interfaces, 87

88 αφοφ αυτά κα μεςολαβιςουν για τθν ςφνδεςθ με τα components που περιζχουν υλοποιιςεισ για τισ πραγματικζσ λειτουργίεσ τουσ. Χρθςιμοποιοφμε το interface SplitControl δφο φορζσ, μία για τον ζλεγχο τθσ ςυςκευισ του πομποδζκτθ και μια για τον ζλεγχο του GPS module. Για να είναι πιο ευδιάκριτοσ ο διαχωριςμόσ, δίνουμε διακριτά ονόματα RadioControl για τθν πρϊτθ περίπτωςθ και GPSControl για τθν δεφτερθ περίπτωςθ, με χριςθ του keyword as όπωσ ζχουμε δει και ςε προθγοφμενεσ αναφορζσ. Στθ ςυνζχεια δθλϊνω τα interfaces Packet, ωσ RadioPacket και AMSend ωσ RadioSend για τθν διαχείριςθ και τθν αποςτολι πακζτων δεδομζνων μζςω του πομποδζκτθ. Για τθν άλλθ μορφι επικοινωνίασ χρθςιμοποιϊ τα interfaces NmeaRawReceive, για τθν λιψθ πακζτων μζςω UART από το GPS module, και το NmeaPacket<nmea_gga_msg_t> ωσ GGAPacket για τθν διαχείριςθ των πακζτων αυτϊν. Το interface NmeaPacket<t> είναι ζνα παραμετροποιθμζνο interface. Αυτό ςθμαίνει ότι μπορεί να πάρει μια παράμετροτφπο δεδομζνων και να προςαρμόςει τισ λειτουργίεσ του πάνω ςε αυτόν τον τφπο. Ζτςι, δεν χρειάηεται να ζχω ξεχωριςτά interfaces NmeaPacket για τον κάκε τφπο πακζτου που μπορεί να υλοποιιςω. Ο τφποσ δεδομζνων μπαίνει ςαν παράμετροσ και πλζον δουλεφω με αυτόν το interface. Στο implementation block τϊρα, γράφουμε τον κϊδικα τθσ εφαρμογισ μασ ςφμφωνα με τισ προδιαγραφζσ λειτουργίασ που ορίςαμε. Στθν ορίηουμε τισ μεταβλθτζσ με τισ οποίεσ κα εργαςτοφμε. Μια δομι μθνφματοσ για μεταφορά μζςω radio τφπου message_t packet;, μια λογικι μεταβλθτι για ζλεγχο τθσ κατάςταςθσ του αςφρματου καναλιοφ (ςτα πρότυπα τθσ προθγοφμενθσ εφαρμογισ που αναφζραμε) bool lockradio; και μια μεταβλθτι δείκτθ ςε δομι nmea_gga_msg_t που κα είναι και θ δομι των δεδομζνων που κα λάβουμε από τθν πρόταςθ GGA, από εκεί και το όνομα, nmea_gga_msg_t* gpsinfo;. Στθ ςυνζχεια του κϊδικα ακολουκοφν δφο ςυναρτιςεισ που υλοποιιςαμε για τθν ενεργοποίθςθ και απενεργοποίθςθ του πράςινου led. Η χριςθ των leds, γίνεται κακαρά για οπτικοποίθςθ των λειτουργιϊν που ςυντελοφνται ςτο εςωτερικό του κόμβου, ζτςι ϊςτε να μπορεί ο ςχεδιαςτισ να ελζγχει τθν ροι του προγράμματοσ. Τα διακζςιμα led ςτον κόμβο είναι τρία (κόκκινο, πράςινο, κίτρινο) και πολλζσ φορζσ δεν αρκοφν για να ανατεκοφν ςε λειτουργίεσ που ορίηει θ εφαρμογι που μπορεί να είναι αρκετζσ. Για αυτό το λόγο υλοποιιςαμε τισ δφο επιπλζον ςυναρτιςεισ void GreenLedON() και void GreenLedOFF() που απλά ανοίγουν και κλείνουν αντίςτοιχα το πράςινο led. Ζτςι, ζχουμε μια ακόμα επιλογι ςτα χζρια μασ, αφοφ αν τοποκετθκοφν ζξυπνα μζςα ςτο κϊδικα, θ χρονικι διάρκεια για τθν οποία κα είναι ανοιχτό το green led κα είναι πολφ μικρι, και το ςτιγμιαίο άναψε-ςβιςε μπορεί να αντιςτοιχιςτεί ςε μια διακριτι λειτουργία. Στθν ίδια λογικι με τθν εφαρμογι MoteSendReceiveSIM, τθν οποία περιγράψαμε παραπάνω και τθσ οποίασ εξζλιξθ αποτελεί θ εφαρμογι που αναπτφςςουμε τϊρα, μζςα ςτο event Boot.booted() προςκζτω τισ γραμμζσ κϊδικα gpsinfo = (nmea_gga_msg_t*)call RadioPacket.getPayload(&packet, sizeof(nmea_gga_msg_t));. Η εντολι αυτι, όπωσ ζχουμε ξαναπεί, ελζγχει αν χωράει ςτο payload του πακζτου packet (message_t) το μινυμα που υπάρχει ςτθ δομι nmea_gga_msg_t. Η επιςτρεφόμενθ τιμι κα είναι NULL αν δεν χωράει. Ζνα απλό casting είναι απαιτοφμενο μιασ και το gpsinfo είναι δείκτθσ ςε δομι nmea_gga_msg_t ενϊ θ εντολι επιςτρζφει δείκτθ χωρίσ τφπο για να μπορεί να προςαρμόηεται ςτισ απαιτιςεισ μασ. Επομζνωσ με το casting που κάνω ορίηω τον 88

89 τφπο δείκτθ που επιςτρζφει θ εντολι αυτι. Στθ ςυνζχεια, μζςα ςτο ςϊμα του γεγονότοσ booted καλϊ το GPS module να ενεργοποιθκεί με τθν εντολι call GPSControl.start();. Στθ ςυνζχεια, ορίηεται το γεγονόσ event void GPSControl.startDone το οποίο δείχνει ότι ζγινε ενεργοποίθςθ τθσ μονάδασ GPS. Από τθ ςτιγμι που ο δζκτθσ GPS ζχει αρχίςει να λειτουργεί, οι ΝΜΕΑ «προτάςεισ» που ςχετίηονται με τον δζκτθ αυτόν τθσ εταιρείασ ublox αρχίηουν να είναι διακζςιμεσ για λιψθ μζςω UART. Οι «προτάςεισ» αυτζσ όμωσ είναι ςτθν ουςία άδειεσ από δεδομζνα δορυφόρων και αυτό επειδι για να επιτευχκεί θ επικοινωνία του δζκτθ με τουσ δορυφόρουσ πρζπει να παρζλκει ζνα χρονικό διάςτθμα, ςτο οποίο γίνεται ο ςυγχρονιςμόσ του με αυτοφσ. Ζτςι αν επιτρζψουμε τθ λιψθ ακατζργαςτων δεδομζνων απευκείασ από τον δζκτθ τότε κα γεμίηουμε τθσ δομζσ ςτο mote με «νεκρζσ προτάςεισ», αφοφ κα περιζχουν μόνο το πρόκεμα τθσ «πρόταςθσ», τα αναγνωριςτικά αρχισ και τζλουσ, και κόμματα. Εκτόσ αυτοφ εμείσ ενδιαφερόμαςτε μόνο για τθν NMEA «πρόταςθ» GGA, τθσ οποίασ το πεδίο fixquality γίνεται 1 όταν ζχει επζλκει ςυγχρονιςμόσ και τα δεδομζνα είναι πλζον ςωςτά. Τα παραπάνω τα αναφζρουμε γιατί κα χρθςιμοποιθκοφν ςαν ζλεγχοι λιψθσ ςτθ ςυνζχεια. Για τθν λιψθ δεδομζνων από τον δζκτθ κα χρθςιμοποιιςουμε το event received του interface NmeaRawReceive. Στο wiring τθσ εφαρμογισ κα πρζπει να κάνουμε ςφνδεςθ του interface αυτοφ με το configuration NmeaRawReceiveC.nc το οποίο του ανακζτει, με τον τελεςτι =, τισ λειτουργίεσ που υλοποιεί το component NmeaRawReceiveP.nc. Το τελευταίο παρζχει το interface NmeaRawReceive κακϊσ και, φυςικά, μια υλοποίθςθ για το event NmeaRawReceive.received(). Η private λειτουργία του NmeaRawReceiveP.nc, για αυτό και το P ςτο όνομα, χρθςιμοποιεί τθν δομι nmea_raw_t που είδαμε παραπάνω. Το component αυτό δζχεται bytes από τθν UART και τα οργανϊνει ςε ζνα πακζτο τφπου nmea_raw_t (εςωτερικόσ buffer). Πταν αυτόσ ο εςωτερικόσ buffer γεμίςει, ι όταν γίνει λιψθ του byte χαρακτιρα τζλουσ CR ι/και LF, το component ςθματοδοτεί το event NmeaRawReceive.received(). Κάκε ακατζργαςτο πακζτο NMEA, κάκε «πρόταςθ» δθλαδι, είναι απλά ζνα ASCII string με πεδία που χωρίηονται μεταξφ τουσ με κόμματα. Αυτό ςθμαίνει ότι το κάκε ψθφίο που υπάρχει ςτθ «πρόταςθ» λαμβάνεται ςαν δυαδικόσ χαρακτιρασ από τουσ δορυφόρουσ, κάτι που ςυνεπάγεται και πιο εφκολθ διαχείριςι τουσ. Η δομι πακζτου nmea_raw_t ζχει για πρϊτο πεδίο ζναν πίνακα ςτον οποίο αποκθκεφει τθν ΝΜΕΑ «πρόταςθ», για δεφτερο πεδίο μια ακζραια μεταβλθτι που μετράει το μζγεκοσ τθσ «πρόταςθσ» από τον χαρακτιρα $ μζχρι τον LF, για τρίτο πεδίο ζναν πίνακα που κρατάει τισ κζςεισ των κομμάτων ςτθ πρόταςθ για να μπορεί να γίνει ςτθ ςυνζχεια πιο εφκολθ θ επεξεργαςία των μετριςεων-πεδίων, και τζλοσ ζναν μετρθτι που κρατάει τον αρικμό των πεδίων από τα οποία αποτελείται θ «πρόταςθ». Τα πεδία αυτά ςυμπλθρϊνονται κατά τθ λειτουργία του component NmeaRawReceiveP.nc, που δζχεται ζνα byte τθ φορά. Χρθςιμοποιοφμε λοιπόν το γεγονόσ event void NmeaRawReceive.received(nmea_raw_t* msg, bool complete){ μζςα ςτο ςϊμα του οποίου εφαρμόηουμε ελζγχουσ για να εξαςφαλίςουμε ότι κα κρατιςουμε τα ςωςτά δεδομζνα. Επειδι, όπωσ είπαμε και ακριβϊσ παραπάνω, αυτό το γεγονόσ ςθματοδοτείται από το NmeaRawReceiveP.nc ςε δφο περιπτϊςεισ, μζςα ςτο ςϊμα του το πρϊτο πράγμα που ελζγχουμε είναι αν θ λογικι μεταβλθτι complete, που 89

90 αποτελεί τθν δεφτερι του παράμετρο, είναι TRUE/FALSE. Το NmeaRawReceiveP.nc ανακζτει ςτθ μεταβλθτι αυτι το αποτζλεςμα τθσ ςφγκριςθσ του τελευταίου χαρακτιρα που λιφκθκε με τον χαρακτιρα τζλουσ LF που ζχει οριςτεί με enum ςτον header Nmea.h. Αν υπάρχει ταφτιςθ, τότε θ «πρόταςθ» λιφκθκε ςωςτά και θ μεταβλθτι γίνεται TRUE, διαφορετικά ςθμαίνει ότι ζγινε υπερχείλιςθ του εςωτερικοφ buffer και ο τελευταίοσ χαρακτιρασ που λιφκθκε δεν ιταν ο χαρακτιρασ τζλουσ, κάνοντασ τθ μεταβλθτι FALSE. Εμείσ με τθ ςειρά μασ, με ζναν απλό ζλεγχο (if(complete){), απαιτοφμε θ μεταβλθτι να είναι TRUE για να ςυνεχίςουμε ςτθ λιψθ τθσ «πρόταςθσ» GGA που κζλουμε. Σε αντίκετθ περίπτωςθ, θ εφαρμογι απορρίπτει τθν «πρόταςθ» και περιμζνει τθν επόμενθ. Ο αμζςωσ επόμενοσ ζλεγχοσ που εφαρμόηουμε είναι θ απαίτθςθ να μθν ζχει επιςτρζψει NULL θ εντολι RadioPacket.getPayload, γράφοντασ if(gpsinfo!= NULL){. Αυτό το χρειαηόμαςτε γιατί τα δεδομζνα τθσ δομισ nmea_raw_t αφοφ επεξεργαςτοφν κα περάςουν ςτθ δομι nmea_gga_msg_t μζςω του δείκτθ gpsinfo που δείχνει ςτο payload του πακζτου message_t packet το οποίο ζχει μζγεκοσ το μζγεκοσ τθσ δομισ nmea_gga_msg_t. Αφοφ περαςτεί και αυτόσ ο ζλεγχοσ ςθμαίνει ότι είμαςτε ζτοιμοι να υποβάλουμε τα δεδομζνα μασ ςε επεξεργαςία. Για τθν διαχείριςθ των πακζτων GPS είχαμε δθλϊςει ςτθν αρχι τθ χριςθ του interface NmeaPacket<nmea_gga_msg_t> με όνομα GGAPacket. Το interface αυτό περιζχει τθν εντολι command error_t process(nmea_raw_t* rawpacket, t* outpacket). Η λειτουργία τθσ υλοποιείται ςτο component NmeaGgaP.nc με το οποίο ςυνδζεται από το configuration component NmeaGgaC.nc, με τον τελεςτι = χρθςιμοποιϊντασ ζτςι τισ λειτουργίεσ του. Το επόμενο βιμα είναι θ απομόνωςθ τθσ πρόταςθσ GGA από το ςφνολο των προτάςεων (7), που είδαμε ότι διαχειρίηεται ο δζκτθσ GPS που χρθςιμοποιοφμε, και θ επεξεργαςία των πεδίων τθσ. Αυτιν τθν εργαςία τθν αναλαμβάνει το component NmeaGgaP.nc. Το private αυτό component παρζχει τθν υλοποίθςθ τθσ εντολισ process που χρθςιμοποιοφμε ςτον επόμενο, τρίτο ςτθ ςειρά ζλεγχο ςτο ςϊμα τθσ received. Γράφοντασ τθν εξισ γραμμι κϊδικα: if(call GGAPacket.process(msg, gpsinfo) == SUCCESS){ καλοφμε τθν εντολι process που δθλϊνεται ωσ command error_t NmeaPacket.process(nmea_raw_t* rawpacket, nmea_gga_msg_t* outpacket){. Η πρϊτθ δουλειά που κάνει αυτι θ εντολι είναι να απομονϊςει τθ πρόταςθ GGA. Αυτό το πετυχαίνει ελζγχοντασ, με μια εςωτερικι ςυνάρτθςθ που παίρνει παράμετρο τον δείκτθ ςτο πακζτο nmea_raw_t που ςτάλκθκε από τθν UART, αν το πρόκεμα τθσ «πρόταςθσ» είναι οι χαρακτιρεσ GPGGA κάνοντασ ςυγκρίςεισ των πρϊτων πεδίων τθσ με τα enums που ζχουν οριςτεί ςτον header Nmea.h. Αν θ πρόταςθ δεν είναι θ GGA τότε απορρίπτεται και εξετάηεται το επόμενο πακζτο nmea_raw_t που ςτζλνει θ UART. Πταν ανιχνευτεί ζνα πακζτο να ζχει τθν «πρόταςθ» GGA, τότε τρζχουν ςυναρτιςεισ που ορίηονται ςτα πλαίςια του NmeaGgaP.nc και ςτόχο ζχουν να ομαδοποιιςουν τουσ χαρακτιρεσ που ςυγκροτοφν το κάκε πεδίο τθσ «πρόταςθσ» μετατρζποντάσ τουσ ςε αρικμοφσ. Αυτό φυςικά δεν ςυμβαίνει για τα πεδία που δίνουν τον προςανατολιςμό, τα οποία και μζνουν ανζπαφα. Το component ουςιαςτικά χρθςιμοποιεί τισ πλθροφορίεσ του πακζτου nmea_raw_t που δζχεται για τθ κζςθ των κομμάτων ςτθν πρόταςθ GGA και με αυτό τον τρόπο αντιλαμβάνεται που είναι τα πεδία που κζλει να χρθςιμοποιιςει κάκε φορά. Στθ ςυνζχεια θ process, με τισ επεξεργαςμζνεσ μετριςεισ γεμίηει τα πεδία τθσ δομισ nmea_gga_msg_t, που δζχεται ςαν δεφτερθ παράμετρο, με ανάκεςθ τιμϊν, επιςτρζφοντασ SUCCESS. Αν 90

91 ςυμβεί οποιοδιποτε ςφάλμα κατά τθ διάρκεια τθσ επεξεργαςίασ τότε γεμίηει τα αντίςτοιχα πεδία τθσ δομισ nmea_gga_msg_t* outpacket με τθ χαρακτθριςτικι τιμι 0xFF για εφκολθ διαπίςτωςθ του λάκουσ. Επειδι θ process όταν καλείται οφείλει να γεμίηει με δεδομζνα τα πεδία του outpacket ακόμα και αν δε ζχουμε «πρόταςθ» GGA τότε αυτά γεμίηονται με τισ τιμζσ 0xFF (για 8μπιτεσ μεταβλθτζσ) και 0xFFFF (για 16μπιτεσ μεταβλθτζσ), επιςτρζφοντασ FALSE. Επομζνωσ με τον τρίτο ζλεγχο if που κάνουμε απαιτοφμε θ process να ζχει επιςτρζψει SUCCESS για να προχωριςει θ ροι του προγράμματοσ, διαφορετικά ςθμαίνει ότι το πακζτο που επεξεργάςτθκε δεν περιείχε τθν «πρόταςθ» GGA μζςα και απορρίπτεται. Στθν ςυνζχεια ακολουκεί ζνασ τζταρτοσ και τελευταίοσ ζλεγχοσ. Φτάνοντασ ωσ εδϊ ςθμαίνει ότι απομονϊκθκε θ «πρόταςθ» GGA και τα δεδομζνα τθσ, από το πακζτο που δείχνει ο δείκτθσ nmea_raw_t* msg, αφοφ επεξεργάςτθκαν ανατζκθκαν ςτα πεδία του πακζτου που δείχνει ο δείκτθσ nmea_gga_msg_t* gpsinfo τον οποίο και δζχεται ςαν δεφτερθ παράμετρο θ process. Ο τζταρτοσ ζλεγχοσ κοιτάει αν το πεδίο fix Quality τθσ πρόταςθσ GGA που λάβαμε από τθν UART ζχει τθν μθ αποδεκτι τιμι (= 0 ςφμφωνα με τον header NmeaGga.h). Ζτςι, γράφουμε if(gpsinfo fixquality!= FIX_INVALID){ και αν θ πρόταςθ είναι πράγματι θ GGA αλλά το fix Quality ζχει τθν τιμι μθδζν, που ςθμαίνει ότι θ πρόταςθ δεν είναι ζγκυρθ κυρίωσ λόγω του ότι δεν κα ζχει επζλκει ακόμα ςυγχρονιςμόσ, απορρίπτεται και το πράςινο led αλλάηει κατάςταςθ αναφζροντασ το γεγονόσ ςτον εξωτερικό παρατθρθτι (εντολι call Leds.led1Toggle(); ). Με αυτοφσ τουσ διαδοχικοφσ ελζγχουσ υλοποιοφμε ζνα είδοσ φιλτραρίςματοσ, ζτςι ϊςτε να μασ μζνει ακριβϊσ αυτό που κζλουμε αυξάνοντασ τθν αξιοπιςτία του τελικοφ αποτελζςματοσ. Αφοφ ικανοποιοφνται οι παραπάνω ζλεγχοι τότε ζχω καταφζρει να φζρω τα δεδομζνα τθσ GGA «πρόταςθσ» ςτθ μορφι που κζλω, μζςα ςτθ δομι gpsinfo, τθν οποία τθν τοποκετιςαμε ςτο payload του message_t packet ςτθν αρχι με τθν εντολι getpayload. Είμαςτε ζτοιμοι δθλαδι να εκκινιςουμε τθν διαδικαςία αποςτολισ του πακζτου packet, μζςω radio, ςτον ςτακμό βάςθσ. Για να οπτικοποιιςουμε το αποτζλεςμα του επιτυχοφσ περάςματοσ από τουσ ελζγχουσ ενόσ πακζτου, μζςα ςτο ςϊμα του τελευταίου if καλϊ τθν εντολι call Leds.led2Toggle(); για να αλλάξει κατάςταςθ το κίτρινο led και καλϊ το GPS module να απενεργοποιθκεί μιασ και αποτελεί μια αρκετά ενεργοβόρα μονάδα με τθν εντολι call GPSControl.stop();. Πταν ολοκλθρωκεί αυτι θ ενζργεια ςθματοδοτείται το event GPSControl.stopDone(error_t error){ το οποίο καλεί το κόκκινο led να αλλάξει κατάςταςθ και μετά δίνει εντολι ενεργοποίθςθσ του πομποδζκτθ ( call RadioControl.start(); ). Η ενεργοποίθςι του ςθματοδοτεί το event RadioControl.startDone(error_t error){ και αν ζχει γίνει ςωςτά, οπότε και error = SUCCESS, γίνεται BROADCAST αποςτολι του πακζτου packet με κλιςθ τθσ εντολισ call RadioSend.send. Καλείται θ ςυνάρτθςθ GreenLedON(); για να μασ δείχνει ότι μια απόπειρα αποςτολισ μζςω radio είναι ςε εξζλιξθ. Αν θ ενεργοποίθςθ του radio δεν ζγινε ςωςτά, οπότε και error = FALSE, επιχειρείται εκ νζου θ ενεργοποίθςθ του. Πταν ολοκλθρωκεί θ split phase λειτουργία τθσ αποςτολισ μζςω radio, ςθματοδοτείται το event RadioSend.sendDone(message_t* bufptr, error_t error){ το οποίο αφοφ ελζγξει ότι ςτάλκθκε το ςωςτό πακζτο, απενεργοποιεί το radio για να μθν καταναλϊνει ενζργεια μζχρι τθν επόμενθ αποςτολι. Η απενεργοποίθςθ του radio, όπωσ και θ ενεργοποίθςθ είναι split phase λειτουργίεσ επομζνωσ κα ςθματοδοτθκεί το event RadioControl.stopDone(error_t error) ςτο 91

92 ςϊμα του οποίου καλείται θ ςυνάρτθςθ GreenLedOFF(); και γίνεται κλιςθ ενεργοποίθςθσ του GPS module για να γίνει θ επόμενθ λιψθ πακζτου από τθν UART και να επαναλθφκεί ςτθν ουςία ο ίδιοσ κφκλοσ. Η μονάδα GPS και το chip του πομποδζκτθ, ςτο ςφςτθμά μασ, αποτελοφν τισ ςυςκευζσ που καταναλϊνουν τθν περιςςότερθ ενζργεια όταν λειτουργοφν. Η εφαρμογι μασ επομζνωσ, μεριμνεί για αυτό και μπορεί να χαρακτθριςτεί ικανό για εξοικονόμθςθ ενζργειασ (power aware). Αυτι θ λογικι του ανοίγματοσ και κλειςίματοσ των ςυςκευϊν αποκλείει τθν περίπτωςθ να ζχουμε ςφγκρουςθ ςτο αςφρματο μζςο, αφοφ θ μετάδοςθ πραγματοποιείται μόνο όταν ζχω το ςωςτό πακζτο και όςο πραγματοποιείται δεν ζχω λιψθ νζου, με το GPS module να είναι κλειςτό. Ζτςι, δεν χρειάηεται πλζον θ μεταβλθτι lockradio τθσ οποίασ θ λειτουργία γίνεται ςχόλιο. Ραρόλα αυτά δεν κα πρζπει να μασ απαςχολοφν οι γραμμζσ κϊδικα που αφοροφν τα ςχόλια, αφοφ κατά το compile τθσ εφαρμογισ υπάρχει μζριμνα και ο «νεκρόσ» κϊδικασ απορρίπτεται για να μθν καταλαμβάνονται πόροι μνιμθσ ςτο mote χωρίσ ςκοπό. Ζχοντασ εξθγιςει διεξοδικά τον τρόπο λειτουργίασ όλων των χρθςιμοποιοφμενων components ςτθν εφαρμογι μασ, θ καταςκευι του configuration MyMoteSendReceiveAppC είναι μια απλι διαδικαςία. Αρχικά ςτο specification block δθλϊνονται τα components που χρθςιμοποιοφμε. Στο implementation block τϊρα, επειδι ζχω επικοινωνία μζςω radio χρθςιμοποιϊ ζνα ςτιγμιότυπο του generic component AMSenderC(I.D.), όπου το I.D. κα είναι αυτό που ορίηεται ςτον header MyMoteSendReceive.h ωσ AM_RADIO_MESSAGE (= 8), με το οποίο κα γίνουν wire τα interfaces που ςχετίηονται με τθν διαχείριςθ των λειτουργιϊν του πομποδζκτθ, App.RadioSend και App.RadioPacket. Αυτό δικαιολογεί και το include του header ςτθν αρχι, για να μπορεί να γίνει ορατι θ ςτακερά αυτι. Επίςθσ, με τθν ίδια λογικι που ςτθν εφαρμογι MyBasestation_new είχαμε τθ ςφνδεςθ του interface που διαχειριηόταν το ςειριακό μζςο επικοινωνίασ (UART) με το component SerialActiveMessageC, ζτςι και τϊρα για τθν διαχείριςθ του ίδιου του πομποδζκτθ κα κάνουμε μια παρόμοια ςφνδεςθ: App.RadioControl ActiveMessageC που εξαςφαλίηει τθν λειτουργικότθτα του interface SplitControl (εγω το χρθςιμοποιϊ ςαν RadioControl), αφοφ το ActiveMessageC, παρζχει το ςυγκεκριμζνο interface. Τα wirings App.NmeaRawReceive NmeaRawReceive και App.GGAPacket NmeaGgaC ζχουν εξθγθκεί αναλυτικά ςτθν περιγραφι του module τθσ εφαρμογισ παραπάνω. Η ςφνδεςθ του GPSControl, που είναι ςτθν ουςία και αυτό το SplitControl, με το gps9546c component είναι απαραίτθτθ κακϊσ το configuration αυτό παρζχει το interface SplitControl δίνοντάσ του άλλθ υπόςταςθ, ςε ςχζςθ με το ActiveMessageC configuration που επίςθσ το παρζχει, δίνοντάσ του τθν λειτουργικότθτα του component gps9546p.nc το οποίο υλοποιεί τον τρόπο ενεργοποίθςθσ (επιλογισ του δζκτθ GPS από τθ πλακζτα) και απενεργοποίθςθσ του GPS module ςτο MTS420CC. Ζτςι, με τθν εντολι GPSControl.start()/GPSControl.stop() γίνεται ενεργοποίθςθ/απενεργοποίθςθ του δζκτθ και ταυτόχρονα ςφνδεςθ/αποςφνδεςθ των pins τθσ UART για εκκίνθςθ/ςταμάτθμα τθσ ςειριακισ UART επικοινωνίασ. Τα υπόλοιπα ςτοιχεία ςτο configuration αυτό τθσ εφαρμογισ μασ ζχουν αναλυκεί ξανά και δεν χριηουν κάποιου περιςςότερου ςχολιαςμοφ. Η τελευταία «πινελιά» που μζνει για να ολοκλθρωκεί ο «πίνακασ» τθσ εφαρμογισ για επικοινωνία με το GPS module MTS420CC sensor board, είναι να 92

93 δθλϊςουμε ςτθν καταςκευι του Makefile τθσ εφαρμογισ τθν πλακζτα αιςκθτιρων που χρθςιμοποιοφμε για να φτιαχτεί ςτο compile ο κατάλλθλοσ κϊδικασ υποςτιριξθσ. Ζτςι, ςτον κϊδικα του αρχείου Makefile προςκζτω τθ γραμμι SENSORBOARD = mts420. Η εφαρμογι μασ γίνεται compile επιτυχϊσ, με χριςθ τθσ εντολισ «make iris» ςτο τερματικό του εικονικοφ υπολογιςτι, και είναι ζτοιμθ για εγκατάςταςθ και χριςθ ςε πραγματικό κόμβο IRIS, ο οποίοσ πρζπει να ζχει ςυνδεδεμζνθ ςτον 51-pin connector του τθν πλακζτα αιςκθτιρων MTS420CC. Εικόνα: Χριςθ του εργαλείου nesdoc που ςχεδιάηει τον γράφο τθσ εφαρμογισ MyMoteSendReceiveGPS ςφμφωνα με το wiring τθσ. Ζνα απλό κουτάκι υποδθλϊνει ζνα module, ζνα κουτάκι με διπλι γραμμι υποδθλϊνει ζνα configuration, ενϊ οι διακεκομμζνεσ γραμμζσ που ςχθματίηουν κουτάκια υποδθλϊνουν ότι το component αυτό είναι generic Ανάπτυξθ εφαρμογισ για λιψθ πακζτων GPS από τον απομακρυςμζνο κόμβο και προϊκθςισ τουσ ςτον υπολογιςτι Σε προθγοφμενθ υποενότθτα είδαμε τον τρόπο με τον οποίο αναπτφξαμε μια πρϊτθ ζκδοςθ τθσ εφαρμογισ Basestation. Αυτι τθν εφαρμογι τϊρα κα εξελίξουμε ϊςτε να πάρει τθν τελικι τθσ μορφι ςτο πλαίςιο του ςυςτιματοσ που ςχεδιάηουμε. Τα επιπλζον χαρακτθριςτικά που κα βάλουμε ςτθν νζα μασ εφαρμογι κα είναι: Mια λογικι ουράσ FIFO (fifo-queue). Επειδι πολλοί κόμβοι μπορεί να ςτζλνουν ςτον κόμβο-βάςθ πακζτα δεδομζνων ςε ακακόριςτεσ χρονικζσ ςτιγμζσ, πρζπει να υπάρχει πρόβλεψθ ζτςι ϊςτε να μθν χακεί κάποιο πακζτο επειδι ζνα άλλο λιφκθκε και αποκθκεφτθκε ςτον buffer του πριν προλάβει να μεταδοκεί ςειριακά ςτον υπολογιςτι. Ζτςι, κάκε ειςερχόμενο πακζτο κα λαμβάνει μια κζςθ ςτθν ουρά, ενϊ ζνα τμιμα κϊδικα κα αναλάβει να εκτελεί ςειριακι μετάδοςθ μεταξφ κόμβου-υπολογιςτι μζχρι να αδειάςει θ ουρά με λογικι FIFO. Τλοποίθςθ λειτουργίασ για λιψθ πακζτων μζςω radio. Αυτι θ λειτουργία δεν υπάρχει ςτθ πρϊιμθ ζκδοςθ τθσ εφαρμογισ Basestation που ζχουμε περιγράψει μζχρι τϊρα. Τποςτιριξθ λιψθσ (radio) και μετάδοςθσ (UART) πακζτων δομισ ΝΜΕΑ. Ρρζπει να τροποποιιςω τθν αρχικι εφαρμογι για να μπορεί να διαχειριςτεί τα δεδομζνα από το payload των λθφκζντων πακζτων από το radio που είναι οργανωμζνα ςε δομι τφπου nmea_gga_msg_t. Ξεκινάμε τθν ανάπτυξθ τθσ νζασ εφαρμογισ DataSinkFiFoGPS μετονομάηοντασ το αρχικό module ςε MyBasestationFiFoC.nc και το configuration ςε MyBasestationFiFoAppC.nc και αρχίηοντασ να προςκζτουμε τισ επιπλζον 93

94 λειτουργίεσ. Ρροςκζτουμε ςτον φάκελο τθσ εφαρμογισ τα αρχεία Nmea.h, NmeaGga.h, NmeaCoordinates.h και NmeaTimeStamp.h. Αρχικά, τροποποιϊ τον header file TestSerial.h. Στθ δομι του μθνφματοσ test_serial_msg_t κάνω ςχόλιο το αρχικό πεδίο (nx_uint16_t counter;) και προςκζτω τα νζα πεδία: nmea_timestamp_t timereceived; nmea_latitude_t latitudereceived; nmea_longitude_t longitudereceived; uint8_t fixqualityreceived; uint8_t numsatellitesreceived; uint16_t altitudereceived; uint16_t geoidheightreceived; με τουσ ίδιουσ ακριβϊσ τφπουσ δεδομζνων για να ζχουμε ταίριαςμα με τθν δθλωμζνθ δομι μθνφματοσ που βρίςκεται ςτο αρχείο NmeaGga.h. Για να είναι ορατοί αυτοί οι τφποι δεδομζνων κάνουμε include ςτο TestSerial.h τα header files Nmea.h και NmeaGga.h. Επίςθσ, επειδι κα υλοποιιςω και τθν λειτουργία για λιψθ πακζτων μζςω αςφρματου radio κα πρζπει να ορίςω εδϊ και το I.D. και για αυτόν το τφπο επικοινωνίασ. Θυμίηουμε ότι προσ το παρόν υπάρχει μόνο το I.D. AM_TEST_SERIAL_MSG = 0x89 για τθ ςειριακι UART επικοινωνία. Ρροςκζτουμε ςτο enum το AM_RADIO_MESSAGE = 8 για I.D. τθσ αςφρματθσ επικοινωνίασ που το ζχουμε χρθςιμοποιιςει και ςτθν εφαρμογι MyMoteSendReceiveGPS για τον ίδιο ςκοπό. Στο module τθσ εφαρμογισ κάνω include τα αρχεία NmeaGga.h και Nmea.h. Επίςθσ, ςτο signature block αυτό που προςκζτω είναι το interface Receive, που του δίνω το όνομα RadioReceive, και κάνω πάλι χριςθ του interface SplitControl που το ονομάηω τϊρα RadioControl (χρθςιμοποιϊ ιδθ το SplitControl ςαν SerialControl). Τα interfaces των μετρθτϊν πλζον δεν τα χρειάηομαι και τα αφαιρϊ από τον κϊδικα, αφοφ κα αναπτφξω μια event driven εφαρμογι. Στο implementation block κρατάω αφαιρϊ τθ μεταβλθτι που είχα ορίςει για ανάκεςθ των παλιϊν δεδομζνων και προςκζτω τισ νζεσ μεταβλθτζσ ςτισ οποίεσ κα περνάω τα δεδομζνα από τα λθφκζντα πακζτα. Ρροςζχω και εδϊ να δϊςω τφπουσ αντίςτοιχουσ με τουσ τφπουσ δεδομζνων που ορίηει θ δομι nmea_gga_msg_t ζτςι ϊςτε να υπάρχει αντιςτοιχία. Επίςθσ, εκτόσ από τθ λογικι μεταβλθτι locked ορίηω και τθν uartfull. Η ουρά FIFO ορίηεται ςαν πίνακασ δεικτϊν ςε δομζσ test_serial_msg_t και το μζγεκοσ του πίνακα ορίηεται από τθν enum ςτακερά UART_QUEUE_LEN που επιλζχκθκε να ζχει τθν τιμι 10. Τζλοσ ορίηονται και δφο ακζραιεσ μεταβλθτζσ που δείχνουν τθν αρχι και το τζλοσ τθσ ουράσ. Το επόμενο βιμα είναι να γράψουμε το κομμάτι του κϊδικα που κα κάνει αποςτολι των πακζτων ςφμφωνα με τθν ςειρά που επιτάςςει θ ουρά. Επειδι το κομμάτι αυτό περιζχει αρκετοφσ υπολογιςμοφσ κεωριςαμε καλφτερο να το φτιάξουμε ςαν ζνα ξεχωριςτό task το οποίο και ονομάςαμε uartsendtask();. Ο κϊδικασ που υπάρχει μζςα ςτο task αυτό είναι πολφ ςθμαντικό να μθν διακόπτεται γιατί αν ςυμβεί κάτι τζτοιο μπορεί το πακζτο προσ αποκικευςθ να καταχωρθκεί ςε λάκοσ κζςθ ι να μθν αποκθκευτεί κακόλου, για αυτό και δθλϊνουμε τθν δεςμευμζνθ λζξθ atomic. Πτι ακολουκεί μζςα ςτο ςϊμα του task πλζον κα γίνεται χωρίσ διακοπζσ (non preemptive). Ο πρϊτοσ ζλεγχοσ που γίνεται ςτο task αυτό είναι για να δοφμε αν υπάρχουν πακζτα προσ μετάδοςθ. Αν ο δείκτθσ uartin δεν ζχει 94

95 μετακινθκεί κακόλου προσ τα πάνω τότε ςθμαίνει ότι δεν λάβαμε κάποιο μινυμα ακόμα και το task κάνει return ελευκερϊνοντασ τθν UART ( locked = FALSE ). Σε διαφορετικι περίπτωςθ ξεκινάει θ διαδικαςία αποςτολισ ακριβϊσ όπωσ τθν ζχουμε περιγράψει αρκετζσ φορζσ μζχρι τϊρα. Ρρϊτα γίνεται ζλεγχοσ για το αν χωράει το μινυμά μασ (δομι test_serial_msg_t) ςτο payload του πακζτου message_t packet. Εικόνα: Λογικι ουράσ FIFO που υλοποιείται ςτθν εφαρμογι μασ. Αρχικά τα uartout και uartin είναι αρχικοποιθμζνα με μθδζν δείχνοντασ ςτθ βάςθ τθσ ουράσ. Όταν ζρκει ζνα νζο πακζτο τότε αποκθκεφεται ςτθν κεςθ που υποδυκνυει ο δείκτθσ uartin ο οποίοσ αμζςωσ μετά αυξάνει κατά 1 για να δείχνει τθ κζςθ αποκικευςθσ επόμενου πακζτου. Αντίκετα με τον δείκτθ uartin, ο uartout παραμζνει ςτακερόσ δείχνοντασ πάντα τθν αρχι τθσ ουράσ. Όταν μια διαδικαςία αποςτολισ λαμβάνει χϊρα, το πακζτο που αποςτζλεται είναι αυτό που βρίςκεται ςτθ κζςθ που δείχνει ο δείκτθσ uartout. Μετά τθν διαδικαςία αποςτολισ ακολουκεί το task που διορκϊνει τισ κζςεισ των πακζτων που βρίςκονται ςτθν ουρά μετακινϊντασ τα όλα μια κζςθ προσ τα κάτω, ενϊ ο δείκτθσ uartin μειϊνεται κατά 1. Ζτςι τϊρα ο δείκτθσ uartout κα δείχνει το πακζτο που μπικε δεφτερο ςτθν ουρά ικανοποιϊντασ τθν απαίτθςθ FIFO. Όταν γίνει uartin = uartout θ ουρά ζχει αδειάςει από πακζτα. Αν δε χωράει τότε το task κάνει return, διαφορετικά ξεκινάει τθν ανάκεςθ των δεδομζνων ςτισ προςωρινζσ μεταβλθτζσ buffers. Η αποςτολι των πακζτων γίνεται από τθ κζςθ που δείχνει ο ςτακερόσ δείκτθσ uartout ζτςι ϊςτε να ικανοποιείται θ λογικι FIFO. Στθν παραπάνω εικόνα βλζπουμε ςχθματικά τον τρόπο λειτουργίασ τθσ ουράσ που υλοποιιςαμε και περιγράφεται ο τρόποσ λειτουργίασ ςφμφωνα με τον κϊδικα που γράψαμε. Μετά τθν ανάκεςθ των δεδομζνων ςε ενδιάμεςεσ εςωτερικζσ μεταβλθτζσ, ακολουκεί το γζμιςμα των πεδίων τθσ δομισ (τφπου test_serial_msg_t) που ζχει επιςυναφτεί ςτο payload του πακζτου packet (τφπου message_t). Στθ ςυνζχεια γίνεται αποςτολι του πακζτου packet με ςειριακι μετάδοςθ χρθςιμοποιϊντασ τθν εντολι UARTSend.send με παράμετρο διεφκυνςθσ τθν ςτακερά BROADCAST, όπωσ ακριβϊσ κάναμε ςειριακι μετάδοςθ και ςτθν αρχικι ζκδοςθ τθσ εφαρμογισ Basestation. Αν θ εντολι send επιςτρζψει SUCCESS, τότε το γεγονόσ οπτικοποιείται με τθν αλλαγι κατάςταςθσ του πράςινου led, διαφορετικά ςθμαίνει ότι κάποιο ςφάλμα ςθμειϊκθκε κατά τθ μετάδοςθ και γίνεται προςπάκεια επανάλθψθσ τθσ αποςτολισ με το task να καλεί τον εαυτό του και το κόκκινο led να αλλάηει κατάςταςθ για αναφορά του ςφάλματοσ. Αυτό είναι και το task για τθν αποςτολι των πακζτων τθσ ουράσ. Αν το send δεν γίνει με επιτυχία τότε δεν ςθματοδοτείται το event senddone() και οι δείκτεσ παραμζνουν όπωσ είναι. Αυτό ςθμαίνει ότι ποςτάροντασ ξανά το task κα γίνει προςπάκεια αποςτολισ του ίδιου πάλι πακζτου. Αν εν τω μεταξφ λθφκεί κάποιο νζο πακζτο, τότε κα τοποκετθκεί ςτο πάνω μζροσ τθσ ουράσ με τον δείκτθ uartin να αλλάηει χωρίσ να επθρεάηεται θ διαδικαςία επαναποςτολισ. Πταν το send γίνει ςωςτά τότε ςθματοδοτείται το event senddone() το οποίο εκτόσ από τον ζλεγχο που ζκανε και ςτθν αρχικι ζκδοςθ, επιπλζον ποςτάρει το task positionfix(), το οποίο διορκϊνει τισ κζςεισ ςτθν ουρά μετακινϊντασ όλα τα πακζτα μια κζςθ προσ τα κάτω και μειϊνει τον μετρθτι uartin κατά ζνα, και μετά ποςτάρει πάλι το uartsendtask() 95

96 για τθν αποςτολι του επόμενου ςτθ ςειρά πακζτου, κάτι το οποίο κα γίνεται μζχρι να αδειάςει τελείωσ θ ουρά. Μζνει να υλοποιθκεί θ λειτουργία λιψθσ πακζτων από τον απομακρυςμζνο κόμβο, που φζρει το MTS420CC sensor board. Το interface Receive που χρθςιμοποιοφμε δθλϊνει το γεγονόσ event message_t* receive(message_t* msg, void* payload, uint8_t len) το οποίο και χρθςιμοποιοφμε ςτον κϊδικά μασ. Το event ςθματοδοτείται όταν γίνεται λιψθ ενόσ πακζτου message_t από το radio. Το κίτρινο led αλλάηει κατάςταςθ για να αναφζρει το γεγονόσ και ακολουκεί ζνασ ζλεγχοσ με βάςθ το μζγεκοσ του πακζτου για να δοφμε αν είναι ζγκυρο. Στο event, το payload δθλϊνεται ςαν δείκτθσ ςε void τφπο. Για να ανακτιςουμε τα δεδομζνα του payload, και ενϊ γνωρίηουμε ότι είναι δομισ nmea_gga_msg_t, κάνουμε ανάκεςθ με casting ςε μια προςωρινι μεταβλθτι τφπου δείκτθ ςε δομι test_serial_msg_t, θ οποία είναι κακόλα ίδια με τθν nmea_gga_msg_t. Ζχοντασ το payload πλζον ςε μια προςωρινι μεταβλθτι temp ςυμβατοφ τφπου με τα ςτοιχεία που περιζχει θ ουρά FIFO που φτιάξαμε, λαμβάνει χϊρα θ τοποκζτθςι του ςε αυτιν. Επειδι και ςε αυτό το ςθμείο μια ενδεχόμενθ διακοπι κα μποροφςε να προκαλζςει τθν απϊλεια του πακζτου ι τθν αποκικευςι του ςε λάκοσ κζςθ ςτθν ουρά χάνοντασ άλλο πακζτο που πικανόν να είναι αποκθκευμζνο εκεί, κάνουμε και αυτό το κομμάτι του κϊδικα να μθν επθρεάηεται από τισ διακοπζσ με το keyword atomic. Η μεταβλθτι που δείχνει ςτο πακζτο μασ αποκθκεφεται ςτθ κζςθ που ορίηει ο δείκτθσ uartin, ο οποίοσ ςτθ ςυνζχεια αυξάνεται κατά ζνα για να δείχνει τθν επόμενθ κζςθ αποκικευςθσ. Αν για κάποιο λόγο θ ουρά γεμίςει, τότε το πρόβλθμα αναφζρεται ςτον εξωτερικό χϊρο με αλλαγι τθσ κατάςταςθσ του κόκκινου led και ακολουκείται μια ςτρατθγικι «κυςίασ» του πακζτου που μπικε τελευταίο ςτθν ουρά (μειϊνεται ο δείκτθσ uartin κατά ζνα και ζτςι θ τελευταία κζςθ κεωρείται «άδεια» οπότε το επόμενο πακζτο που κα λθφκεί κα αποκθκευτεί πάνω ςτο προθγοφμενο διαγράφοντάσ το). Στθ ςυνζχεια γίνεται post το task για αποςτολι πακζτων από τθν ουρά και το ςειριακό κανάλι κλειδϊνει ( locked = TRUE ). Το post του uartsendtask(); ςε αυτό το ςθμείο εξαςφαλίηει ότι: 1. Αν το πακζτο που λιφκθκε είναι το πρϊτο που μπαίνει ςτθν ουρά, τότε κα αποςταλεί ςειριακά άμεςα. 2. Αν θ λιψθ ζγινε ενϊ θ ουρά είχε και άλλα πακζτα αποκθκευμζνα, τότε κα γίνεται αποςτολι μζχρι θ ουρά να αδειάςει. Άλλεσ διαφοροποιιςεισ με τθν αρχικι ζκδοςθ είναι ότι ςτο boot event πλζον καλείται και το RadioControl.start(); ενϊ γίνεται On μονο το κόκκινο led. Επίςθσ υλοποιοφνται τα RadioControl.startDone(){ και RadioControl.stopDone(){. Λόγω τθσ ςθμαςίασ του κόμβου οι εντολζσ RadioControl.stop() και SerialControl.stop() δεν καλοφνται ποτζ μιασ και ο κόμβοσ βάςθ δεν τροφοδοτείται από μπαταρίεσ. Ζτςι για εξοικονόμθςθ μνιμθσ RAM τα event RadioControl.stopDone(error_r error){ και SerialControl.stopDone(error_t error){ δεν περιλαμβάνουν κϊδικα ςτο ςϊμα τουσ. Στο configuration component τθσ εφαρμογισ γίνεται include το αρχείο TestSerial.h για να γίνουν ορατά τα I.D. των δφο τφπων επικοινωνίασ που υλοποιοφνται και να μπουν ςαν παράμετροι ςτα κατάλλθλα interfaces. Το component αυτό μοιάηει αρκετά ςτο αντίςτοιχο τθσ αρχικισ ζκδοςθσ τθσ εφαρμογισ Basestation. Οι διαφορζσ είναι ότι πλζον τϊρα δεν χρθςιμοποιοφνται οι Timers και για αυτό ζχουμε ςβιςει τον κϊδικα που αναφζρεται ςε αυτοφσ. Στα 96

97 χρθςιμοποιοφμενα components, ςτο signature block δθλϊνεται ActiveMessageC που το μετονομάηουμε ςε Radio, το οποίο παρζχει λειτουργίεσ ςτα interfaces SplitControl και Receive[uint8_t id]. Ζτςι με το ActiveMessageC γίνονται wire τα χρθςιμοποιοφμενα από τθν εφαρμογι μασ interfaces App.RadioControl και App.RadioReceive. Το id που κα βάλουμε ςτο παραμετροποιθμζνο interface Receive είναι το AM_RADIO_MESSAGE για να είναι ευδιάκριτοσ ο διαχωριςμόσ από τον ςειριακό τφπο επικοινωνίασ που ζχει άλλο id (= AM_TEST_SERIAL_MSG). Το υπόλοιπο wiring μζνει ωσ ζχει ςτθν αρχικι ζκδοςθ τθσ εφαρμογισ. Ανοίγοντασ ζνα παράκυρο τερματικοφ, μπαίνουμε ςτον φάκελο τθσ εφαρμογισ DataSinkFiFoGPS και πλθκτρολογοφμε τθν εντολι make iris. Το compile ολοκλθρϊνεται χωρίσ λάκθ. Ζτςι ζχουμε ζτοιμεσ τισ δφο εφαρμογζσ, που απαιτεί το ςφςτθμα που ςχεδιάηουμε, για εγκατάςταςθ και λειτουργία ςε πραγματικζσ ςυνκικεσ. Εικόνα: Χριςθ του εργαλείου nesdoc που ςχεδιάηει τον γράφο τθσ εφαρμογισ DataSinkFiFoGPS ςφμφωνα με το wiring τθσ. Ζνα απλό κουτάκι υποδθλϊνει ζνα module, ζνα κουτάκι με διπλι γραμμι υποδθλϊνει ζνα configuration, ενϊ οι διακεκομμζνεσ γραμμζσ που ςχθματίηουν κουτάκια υποδθλϊνουν ότι το component αυτό είναι generic. χόλιο: Μετά από μελζτθ πάνω ςτο υλικό που χρθςιμοποιοφμε ςτο ςφςτθμά μασ διαπιςτϊκθκε ότι τόςο ο επεξεργαςτισ ςτον υπολογιςτι όςο και ο επεξεργαςτισ ςτο mote βαςίηονται ςε little endian αρχιτεκτονικι. Για αυτό το λόγο λιφκθκε θ απόφαςθ να μθν γίνουν platform independent οι δομζσ που εμπλζκονται ςτθν επικοινωνία κόμβου-υπολογιςτι. Παρόλα αυτά όμωσ, ςυνθκίηεται ο οριςμόσ τζτοιων δομϊν ωσ platform independent για να μθν υπάρχει πρόβλθμα με τθν διαφορετικότθτα των endianness. *το παράρτθμα Α, παρατίκεται ο τρόποσ για να γίνουν platform independent οι δομζσ που χρθςιμοποιοφμε+ 97

98 ΚΕΦΑΛΑΙΟ 6 ο Επικοινωνία κόμβου υπολογιςτι 6.1 Ειςαγωγι Μζχρι ςτιγμισ ζχουμε δει τθν ανάπτυξθ των εφαρμογϊν που απαιτεί το ςφςτθμά μασ για να λειτουργιςει από το μζροσ του WSN. Το άλλο μζροσ είναι ο υπολογιςτισ (host PC) ο οποίοσ κα δζχεται τισ μετριςεισ που ςυλλζγει το δίκτυο αςφρματων αιςκθτιρων και κα κάνει υπολογιςμοφσ. Ο ςτόχοσ, όπωσ ζχουμε περιγράψει και προθγοφμενα, είναι να γίνει απεικόνιςθ τθσ κζςθσ τροχιάσ ενόσ κινθτοφ ςτθν πρότυπθ παγκόςμια εφαρμογι Google Earth TM. Οι μετριςεισ GPS αποςτζλλονται ςειριακά από τον κόμβο βάςθ με κατεφκυνςθ τον υπολογιςτι ςτον οποίο είναι ςυνδεδεμζνοσ, μζςω του αναπτυξιακοφ MIB520. Ο υπολογιςτισ με τθ ςειρά του πρζπει να διαβάςει τα δεδομζνα από τθν κφρα USB και μετά να τα χρθςιμοποιιςει κατάλλθλα ςτθν εφαρμογι Google Earth TM. Μζνει, επομζνωσ, θ ανάπτυξθ προγράμματοσ που κα ανοίγει τθ κφρα USB, κα ςυγχρονίηεται για να αποκακιςτά ςωςτι ςφνδεςθ και κα επεξεργάηεται τα ειςερχόμενα πακζτα. Σχεδιάςτθκαν δφο προγράμματα για το ςκοπό αυτό. Το πρϊτο κάνει offline tracking, ενϊ το δεφτερο απεικονίηει τθ κζςθ του κινθτοφ ςε πραγματικό χρόνο (online). Στθν πραγματικότθτα, το πρϊτο πρόγραμμα είναι προπομπόσ του δευτζρου και αναπτφχκθκε για να επιβεβαιωκεί θ λειτουργικότθτα του ςυςτιματοσ που ςχεδιάςαμε. Αφοφ αυτι επιβεβαιϊκθκε, προχωριςαμε ςτθν καταςκευι του δευτζρου προγράμματοσ για επιςκόπθςθ του ςυςτιματοσ ςε λειτουργία πραγματικοφ χρόνου. 6.2 Ανάπτυξθ προγράμματοσ για tracking ςε offline mode Αρχικά ςχεδιάςτθκε το πρόγραμμα USB_read ςε γλϊςςα C ςτθ πλατφόρμα Dev-C++, το οποίο όπωσ αναφζρει και ο τίτλοσ τθσ υποενότθτασ αυτισ εκτελεί εντοπιςμό (tracking) τθσ κζςθσ ι/και τθσ τροχιάσ του κινθτοφ, που φζρει τον κόμβο του WSN με το GPS module (MTS420CC), ςε offline mode. Αυτό ςθμαίνει ότι τα δεδομζνα που λαμβάνονται από τθ USB, αφοφ μετατραποφν ςε μορφι ςυμβατι με αυτι που αναγνωρίηει θ εφαρμογι Google Earth TM, αποκθκεφονται ςε ζνα XML αρχείο. Το αρχείο ολοκλθρϊνεται όταν αποφαςίςουμε ότι τερματίςτθκε θ κίνθςθ του κινθτοφ που κζλουμε να «παρακολουκιςουμε» και μπορεί να ειςαχκεί (import) ςτο Google Earth TM για να δείξει τθν πορεία που κατζγραψε. Ο όροσ offline χρθςιμοποιείται για να τονίςει ακριβϊσ το χαρακτθριςτικό τθσ απεικόνιςθσ εκ των υςτζρων. Η βαςικότερθ λειτουργία που υλοποιεί το πρόγραμμα αυτό είναι θ αποκατάςταςθ ςφνδεςθσ με τθν κφρα USB ςτθν οποία επιςυνάπτεται το 98

99 αναπτυξιακό MIB520 με τον κόμβο βάςθ ςτον 51-pin connector του. Για αυτό το λόγο κα χρθςιμοποιιςουμε το windows API. Η λειτουργία αυτι ολοκλθρϊνεται ςε τζςςερα τμιματα τα οποία περιλαμβάνουν: Άνοιγμα τθσ ςειριακισ κφρασ Ρφκμιςθ των ιδιοτιτων τθσ ςειριακισ κφρασ Ρφκμιςθ των timeouts Διάβαςμα δεδομζνων Στθ ςυνζχεια το πρόγραμμα μποροφμε να το χωρίςουμε ςτα λειτουργικά μζρθ «Επεξεργαςία δεδομζνων» και «Οργάνωςθ και καταγραφι δεδομζνων». Ακολουκεί μια ςφντομθ περιγραφι του τρόπου λειτουργίασ και του τρόπου υλοποίθςθσ για το κάκε ζνα από τα παραπάνω τμιματα. Άνοιγμα τθσ ςειριακισ κφρασ (opening the serial port) Το άνοιγμα τθσ ςειριακισ κφρασ είναι μια αρκετά απλι διαδικαςία. Αρχικά κάνουμε include ςτο πρόγραμμα τον header windows.h. Στθ ςυνζχεια ορίηουμε μια μεταβλθτι τφπου HANDLE και τθν αρχικοποιοφμε καλϊντασ τθ ςυνάρτθςθ CreateFile. Η πρϊτθ παράμετροσ τθσ ςυνάρτθςθσ αυτισ είναι το όνομα του αρχείου που κζλουμε να ανοίξουμε. Στθν περίπτωςι μασ, κζλουμε να ανοίξουμε μια ςειριακι κφρα επομζνωσ κα χρθςιμοποιιςουμε ζνα string τθσ μορφισ COMx όπου x ακζραιοσ αρικμόσ ταυτότθτα τθσ κφρασ. Ζχοντασ αρκετά καλι γνϊςθ του υλικοφ που χρθςιμοποιοφμε, γνωρίηουμε ότι οι κφρεσ που ςχετίηονται με το αναπτυξιακό ΜΙΒ520 είναι για τα windows οι COM4 και COM5, με τθν πρϊτθ να είναι για προγραμματιςμό των motes και τθν δεφτερθ να είναι για επικοινωνία με αυτά. Ζτςι, θ πρϊτθ παράμετροσ που ειςάγουμε είναι θ κφρα COM5. Η επόμενθ παράμετροσ τθσ CreateFile λζει ενθμερϊνει τα windows για το αν κζλουμε να διαβάςουμε ι να γράψουμε από τθ ςειριακι κφρα. Επειδι κζλουμε να γίνει διάβαςμα δεδομζνων βάηω τθ παράμετρο GENERIC_READ. Οι παράμετροι 3 και 4 πρζπει να είναι ςχεδόν πάντα μθδζν. Η επόμενθ παράμετροσ δθλϊνει αν κζλουμε να ανοίξουμε ζνα ιδθ υπάρχον αρχείο και επειδι θ ςειριακι κφρα υπάρχει ιδθ, αυτό επιλζγουμε με τθν ςτακερά OPEN_EXISTING. Μετά από αυτό δθλϊνεται θ παράμετροσ FILE_ATTRIBUTE_NORMAL που υποδεικνφει ότι δεν απαιτείται τίποτα το ιδιαίτερο για τθ λειτουργία που κζλουμε. Η τελευταία παράμετροσ πρζπει και αυτι να είναι μθδζν. Αν θ αρχικοποίθςθ τθσ μεταβλθτισ δεν γίνει ςωςτά τότε υπάρχει μεγάλθ πικανότθτα για αυτό να φταίει το ότι δεν βρζκθκε θ κφρα που δόκθκε για παράμετροσ. Σε αυτι τθ περίπτωςθ βγαίνει ζνα μινυμα λάκουσ που ενθμερϊνει το χριςτθ τι δεν πιγε καλά και το πρόγραμμα τερματίηεται κλείνοντασ το αρχείο. Αν δεν οφείλεται ςε αυτό, τότε κάποιο άλλο λάκοσ ζλαβε χϊρα και ο χριςτθσ ενθμερϊνεται πάλι πριν το πρόγραμμα τερματιςτεί. Ρφκμιςθ των ιδιοτιτων τθσ ςειριακισ κφρασ (Setting parameters) Φτάνοντασ εδϊ ςθμαίνει ότι ζχουμε μια λαβι (HANDLE) ςτθ ςειριακι κφρα και πλζον πρζπει να ρυκμίςουμε τισ παραμζτρουσ τθσ. Τα windows το κάνουν αυτό μζςω μιασ δομισ που καλείται DCB. Στο πρόγραμμά μασ πρϊτα δθμιουργοφμε μια μεταβλθτι τφπου δομισ DCB τθν οποία και αρχικοποιοφμε με μθδζν. Μετά χρθςιμοποιοφμε τθν ςυνάρτθςθ GetCommState που δζχεται ςαν ορίςματα το handle τθσ ςειριακισ κφρασ που ανοίξαμε και δείκτθ ςτθ δομι DCB. Η ςυνάρτθςθ 99

100 αυτι ςυμπλθρϊνει τθ DCB δομι με τισ τρζχουςεσ ρυκμίςεισ ελζγχου για τθν ςυςκευι επικοινωνίασ που αναφζρεται ςτο πρϊτο τθσ όριςμα. Από τθ ςτιγμι που ολοκλθρϊνεται αυτό χωρίσ ςφάλματα, χρειάηεται να κζςουμε τισ παραμζτρουσ για τισ οποίεσ νοιαηόμαςτε. Ιδιαιτζρωσ για τα baud rate, byte size, stop bits και parity. Τα windows απαιτοφν τθν χριςθ ειδικϊν ςτακερϊν για τον κακοριςμό του baud rate. Αυτζσ οι ςτακερζσ είναι αρκετά περιγραφικζσ όπωσ για παράδειγμα θ CBR_19200 για baud, θ CBR_9600 για 9600 baud ι θ CBR_57600 για baud κ.α. Η προκακοριςμζνθ τιμι του baud rate για τα IRIS motes είναι baud. Επομζνωσ ςτο αντίςτοιχο πεδίο τθσ δομισ DCB που δθλϊςαμε ανακζτουμε τθ τιμι τθσ ςτακεράσ CBR_ Το byte size που χρθςιμοποιοφμε δθλϊνεται ςτα 8 bits άμεςα ςε αντίκεςθ με τα άλλα δφο πεδία του stop bit και parity που και αυτά δθλϊνονται με ςτακερζσ οριςμζνεσ από το ςφςτθμα. Οι επιλογζσ για το stop bit πεδίο είναι ONESTOPBIT, ONE5STOPBITS, TWOSTOPBITS. Πμοια για το πεδίο parity ζχω τισ EVENPARITY, NOPARITY, ODDPARITY. Επειδι εμείσ δουλεφουμε με ζνα stop bit και χωρίσ parity χρθςιμοποιϊ και τισ αντίςτοιχεσ ςτακερζσ. Ζχοντασ διαμορφϊςει τθ δομι DCB όπωσ ακριβϊσ κζλουμε, χρειάηεται να εφαρμόςουμε αυτζσ τισ ρυκμίςεισ ςτθν ςειριακι κφρα. Αυτό το πετυχαίνουμε με τθν χριςθ τθσ ςυνάρτθςθσ SetCommState. Ρφκμιςθ των Timeouts (Setting timeouts) Ζνα από τα μεγαλφτερα προβλιματα ςτθν επικοινωνία με ςειριακζσ κφρεσ είναι το ότι όταν δεν ζρχονται δεδομζνα ςτθ ςειριακι κφρα (αν για παράδειγμα θ ςυνδεδεμζνθ ςυςκευι αποςυνδεκεί ι κλείςει) τότε θ προςπάκεια για διάβαςμα από τθ κφρα μπορεί να προκαλζςει το «κρζμαςμα» τθσ εφαρμογισ μασ περιμζνοντασ τα δεδομζνα να εμφανιςτοφν. Υπάρχουν δφο τρόποι για να αντιμετωπιςτεί αυτό. Ο πρϊτοσ είναι να χρθςιμοποιιςουμε πολλαπλά νιματα ςτθν εφαρμογι μασ. Ζνα νιμα κα αςχολείται με κζματα τθσ ςειριακισ κφρασ και ζνα άλλο κα κάνει τθν πραγματικι επεξεργαςία. Κάτι τζτοιο όμωσ μπορεί να καταλιξει να είναι αρκετά πολφπλοκο. Ο άλλοσ τρόποσ είναι πολφ πιο απλόσ: απλά λζμε ςτα windows να μθν περιμζνουν τθν εμφάνιςθ δεδομζνων. Για να γίνει αυτό δθλϊνουμε μια δομι τφπου COMMTIMEOUTS που περιζχει τα εξισ πεδία: ReadIntervalTimeout που κακορίηει το πόςο (ςε milliseconds) κα περιμζνει το ςφςτθμα ανάμεςα ςτθ λιψθ χαρακτιρων πριν βγει ςε timeout ReadTotalTimeoutConstant που κακορίηει το πόςο κα περιμζνει το ςφςτθμα (ςε milliseconds) πριν να κάνει return ReadTotalTimeoutMultiplier που κακορίηει το πόςο επιπλζον χρόνο κα περιμζνει (ςε milliseconds) πριν κάνει return για κάκε byte που ηθτικθκε ςτθ λειτουργία διαβάςματοσ. Αφοφ διαμορφϊςουμε ςτο πρόγραμμά μασ τθ μεταβλθτι τφπου δομισ COMMTIMEOUTS ανακζτοντασ τισ τιμζσ που κζλουμε ςτα παραπάνω πεδία, πρζπει να εφαρμόςουμε και ςε αυτι τθ περίπτωςθ τισ ρυκμίςεισ ςτθ ςειριακι κφρα χρθςιμοποιϊντασ τθ ςυνάρτθςθ SetCommTimeouts. Διάβαςμα δεδομζνων (Reading data) Αφοφ ζχουμε ανοίξει μια ςειριακι κφρα με τισ ςωςτζσ παραμζτρουσ και τα ςωςτά timeouts, μποροφμε να ξεκινιςουμε τθ διαδικαςία διαβάςματοσ (read). Σε ζνα βρόγχο while που επαναλαμβάνεται ςυνζχεια χρθςιμοποιϊ τθν ςυνάρτθςθ 100

101 ReadFile που δζχεται πζντε παραμζτρουσ. Η πρϊτθ παράμετροσ είναι ζνασ HANDLER ςε ζνα αρχείο (ςτθν περίπτωςι μασ θ ςειριακι κφρα), θ δεφτερθ παράμετροσ είναι ζνασ εςωτερικόσ buffer για αποκικευςθ των δεδομζνων που ειςζρχονται, θ τρίτθ παράμετροσ δθλϊνει τον αρικμό των bytes που κα διαβαςτοφν, θ τζταρτθ είναι ζνασ δείκτθσ ςε ακζραιο που μετράει τον αρικμό των bytes που διαβάςτθκαν, ενϊ θ πζμπτθ παράμετροσ είναι πάντα NULL. Τα ειςερχόμενα bytes αντιπροςωπεφουν 8μπιτουσ μθ προςθμαςμζνουσ χαρακτιρεσ (unsigned char τφποσ). Ρροςζχουμε όλεσ οι δομζσ που φτιάχνουμε για διαχείριςθ των δεδομζνων αυτϊν να ακολουκοφν τον ςυγκεκριμζνο τφπο διαφορετικά ο compiler δεν κα βγάλει λάκθ αλλά τα castings που κα γίνονται κα αλλοιϊνουν τα δεδομζνα εςωτερικά. Η λογικι που ακολουκοφμε για το διάβαςμα του πακζτου που ςτζλνεται ςειριακά είναι byte προσ byte κακορίηοντασ κατάλλθλα τθν πρϊτθ παράμετρο τθσ ςυνάρτθςθσ ReadFile. Κάκε byte που διαβάηεται τοποκετείται ςε ζναν προςωρινό πίνακα 30 κζςεων καταλαμβάνοντασ μια κζςθ του. Ο πίνακασ αυτόσ ςτο τζλοσ τθσ λιψθσ ενόσ πακζτου κα περιλαμβάνει όλο το πακζτο μαηί με επιπλζον προκζματα που ειςάγονται κατά τθν διεξαγωγι τθσ επικοινωνίασ. Το μζγεκοσ του πίνακα κακορίςτθκε φςτερα από δοκιμζσ που ζγιναν κατά τθ διάρκεια ανάπτυξθσ του κϊδικα του προγράμματοσ. Τα bytes, που παρατθρικθκαν ότι λαμβάνονται ςειριακά ανά πακζτο, από αυτζσ τισ δοκιμζσ, περιγράφονται αναλυτικά ςτο αρχείο του προγράμματοσ πριν τθν αρχι του κϊδικα. Το τζλοσ τθσ λιψθσ ενόσ πακζτου κα γίνει αντιλθπτό από το πρόγραμμα όταν δεν λάβει byte. Αν γίνει αυτό και με τθν προχπόκεςθ ότι ςτθν ακριβϊσ προθγοφμενθ προςπάκεια λιφκθκε ζνα byte, τότε μθδενίηεται ο μετρθτισ κζςθσ του πίνακα, ζτςι ϊςτε να είναι ζτοιμοσ για τθ λιψθ του επόμενου πακζτου. Αν ζχει ξεπεραςτεί ζνα ανϊτατο όριο λθφκζντων πακζτων, τότε αποκθκεφεται το περιεχόμενο του πίνακα ςε μια εςωτερικι λειτουργικι δομι, αφοφ πρϊτα τα δεδομζνα του περάςουν από τθν απαραίτθτθ επεξεργαςία για να πάρουν τθν τελικι μορφι που πρζπει να ζχουν για τθν απεικόνιςι τουσ ςτθ πρότυπθ εφαρμογι Google Earth TM. Η διαδικαςία αυτι λιψθσ επαναλαμβάνεται ςυνζχεια, εκτόσ και αν βάλουμε ζνα ανϊτατο όριο λιψθσ πακζτων το οποίο όταν επιτευχκεί να ςταματάει θ λιψθ, ι αν υπάρξει κάποια εξωτερικι διακοπι ςτθν αποςτολι των πακζτων (αν βγάλουμε για παράδειγμα το αναπτυξιακό από τθ USB). Κλείνοντασ το τμιμα του κϊδικα ςε C που αςχολείται με τθν USB επικοινωνία, να ςθμειϊςουμε ότι οι επιςτρεφόμενεσ τιμζσ των ςυναρτιςεων που αναφζραμε παραπάνω χρθςιμοποιικθκαν και για τον ζλεγχο τθσ λειτουργίασ. Αν κάποια δεν εκτελοφνταν ςωςτά, τότε το πρόγραμμα τερμάτιηε και ζβγαηε ειδικό μινυμα ςτθν οκόνθ του τερματικοφ αναφζροντασ το ςφάλμα και με τι αυτό ςχετίηεται. Ρριν τερματίςει το πρόγραμμα, ςε κάκε περίπτωςθ, υπάρχει μζριμνα για να κλείνει θ ςφνδεςθ που ζχει αποκαταςτακεί με τθν προκακοριςμζνθ κφρα USB. Επεξεργαςία δεδομζνων (Data processing) Ππωσ ζχουμε αναφζρει πολλάκισ μζχρι ςτιγμισ, αλλά δεν ζχουμε ποτζ αναλφςει, τα δεδομζνα για τισ ςυντεταγμζνεσ που αποκθκεφω ςτον υπολογιςτι πρζπει να 101

102 είναι ςε μια ςυγκεκριμζνθ μορφι για να μπορζςουν να γίνουν αποδεκτά από τθν εφαρμογι Google Earth TM. Για το λόγο αυτό υλοποιιςαμε μια ςειρά από ςυναρτιςεισ οι οποίεσ αναλαμβάνουν τθν επεξεργαςία των ςτοιχείων των λθφκζντων πακζτων και τθν διαμόρφωςθ τουσ ζτςι ϊςτε να καταλιξουν να ζχουν τθν επικυμθτι μορφι. Η διαδικαςία αυτι κα μποροφςε να υλοποιθκεί και ςτθν εφαρμογι που αναπτφξαμε για τον κόμβο βάςθ του WSN. Πμωσ οι περιοριςμζνοι πόροι (ενζργεια, μνιμθ) που διακζτουν οι κόμβοι, μασ οδιγθςε ςτθν απόφαςθ θ επεξεργαςία αυτι να γίνει από τθν πλευρά του υπολογιςτι, μειϊνοντασ ζτςι τον υπολογιςτικό φόρτο από το mote αλλά και το μζγεκοσ του προγράμματοσ τθσ εφαρμογισ ςτθ μνιμθ του. Οι ςυναρτιςεισ που φτιάξαμε και χρθςιμοποιοφμε ςτο πρόγραμμά μασ για το τμιμα τθσ επεξεργαςίασ δεδομζνων, κακϊσ και οι λόγοι οι οποίοι μασ οδιγθςαν ςε αυτι τθ κατεφκυνςθ, δίνονται παρακάτω: unsigned int TwobytesInOne(unsigned char byte1, unsigned char byte2). Στθν περιγραφι του ςχεδιαςμοφ τθσ εφαρμογισ DataSinkFiFoGPS, είχαμε αναφζρει ότι αποφαςίςτθκε να μθν χρθςιμοποιιςουμε platform independent τφπουσ για τισ δομζσ των πακζτων προσ μετάδοςθ, επειδι τόςο ο υπολογιςτισ όςο και τα mote ζχουν το ίδιο endianness (ακολουκοφν μια little endian αρχιτεκτονικι). Οι δομζσ αυτζσ περιζχουν εκτόσ από δεδομζνα 8μπιτα, και 16μπιτα. Τα τελευταία από τθ ςτιγμι τθσ δθμιουργίασ τουσ ςτο mote, κατά τθ μετάδοςι τουσ ςτο αςφρματο μζςο αλλά και τθν αποκικευςι τουσ ςτον υπολογιςτι ακολουκοφν τθν little endian λογικι. Επίςθσ, επειδι θ λιψθ του πακζτου γίνεται byte προσ byte, διαχωρίηονται ςε δφο κομμάτια πλθροφορίασ. Για αυτό το λόγο, υλοποιιςαμε τθν ςυνάρτθςθ TwobytesInOne(), θ οποία δζχεται ςαν ορίςματα τα δφο bytes που ςυνκζτουν μια 16μπιτθ πλθροφορία, τθν ανακαταςκευάηει και τθν επιςτρζφει όπωσ πραγματικά είναι. Η λειτουργία τθσ είναι αρκετά απλι και βαςίηεται ςε bitwise λογικι. Ολιςκαίνει το byte του δεφτερου ορίςματοσ κατά 8 κζςεισ και ςτθ ςυνζχεια εκτελεί μια πράξθ «λογικοφ Ή» με το byte του πρϊτου ορίςματοσ. unsigned char fixtimehour(unsigned char hour). Στθν δθμιουργία αυτισ τθσ ςυνάρτθςθσ μασ οδιγθςε το γεγονόσ ότι ςτα δεδομζνα τθσ ΝΜΕΑ «πρόταςθσ» GGA, το πεδίο που αναφζρεται ςτο χρόνο περιζχει δεδομζνα ςε UTC μορφι. Το UTC είναι το πρότυπο χρόνου ςφμφωνα με το οποίο ο κόςμοσ ρυκμίηει τα ρολόγια και το χρόνο. Εξυπθρετθτζσ (servers) υπολογιςτϊν, online υπθρεςίεσ και άλλεσ οντότθτεσ που βαςίηονται ςτο να ζχουν μια κακολικά αποδεκτι μορφι χρόνου, χρθςιμοποιοφν το UTC. Ρρόκειται για ζνα πρότυπο χρόνου που ςτθρίηεται ςτθ διεκνι ατομικι ϊρα, με άλματα δευτερολζπτων να προςτίκενται ςε μθ τακτά χρονικά διαςτιματα για να υπάρχει ςυγχρονιςμόσ με τθν περιςτροφι τθσ Γθσ και είναι το ίδιο με το GMT (Greenwich Mean Time). Η ςυνάρτθςθ fixtimehour() ςτθν ουςία διορκϊνει το χρόνο, επεμβαίνοντασ ςτο πεδίο των ωρϊν αφοφ θ ϊρα για τθν Ελλάδα ακολουκεί το τφπο «UTC + 03:00». Ζνασ απλόσ ζλεγχοσ ςτο ςϊμα τθσ ςυνάρτθςθσ είναι απαραίτθτοσ για να ζχει φυςικό νόθμα θ επιςτρεφόμενθ τιμι τθσ διορκωμζνθσ ϊρασ (θ τιμι τθσ ϊρασ πρζπει να κυμαίνεται από το 0 μζχρι το 24). Για παράδειγμα αν θ 102

103 UTC ϊρα είναι 22:00, τότε θ διόρκωςθ κα δϊςει = 25 που δεν είναι μια αποδεκτι τιμι για τισ ϊρεσ. Μια λογικι modulo24 ενεργοποιείται ςε τζτοιεσ περιπτϊςεισ και λφνει το πρόβλθμα. Εικόνα: Ηϊνεσ χρόνου ςτθν Ευρϊπθ float fixcoordinates(unsigned char deg, unsigned int remainder, unsigned char dir). Η ςυνάρτθςθ αυτι επιτελεί τθν πιο ςθμαντικι τροποποίθςθ ςτθ μορφι των ςυντεταγμζνων ζτςι ϊςτε αυτζσ να είναι ςυμβατζσ με το πρότυπο Google Earth TM. Πταν αναλφςαμε τα πεδία τθσ «πρόταςθσ» GGA για τον δζκτθ GPS που χρθςιμοποιοφμε ςτο ςφςτθμά μασ με το MTS420CC sensor board, είχαμε αναφζρει ότι οι ςυντεταγμζνεσ (γεωγραφικό μικοσ και γεωγραφικό πλάτοσ) λαμβάνονται ςτθ μορφι «Μοίρεσ - δεκαδικά λεπτά». Το Google Earth TM δουλεφει με τθ μορφι δεκαδικϊν μοιρϊν, επομζνωσ μια μετατροπι ανάμεςα ςτισ δφο μορφζσ είναι απαραίτθτθ. Η ςυνάρτθςθ αυτι αναλαμβάνει τθν μετατροπι. Το δεκαδικό μζροσ των μοιρϊν προκφπτει από τθ διαίρεςθ των δεκαδικϊν λεπτϊν με το 60. Ζπειτα το δεκαδικό μζροσ των μοιρϊν αυτό, προςτίκεται ςτισ μοίρεσ και ζχουμε τα δεδομζνα ςε μορφι δεκαδικϊν μοιρϊν. Οι πράξεισ που γίνονται απαιτοφν αρκετά ψθφία για ακρίβεια, για αυτό και θ χριςθ του τφπου δεδομζνων float. Ρρζπει να επιςθμάνουμε επίςθσ, ότι θ εφαρμογι Google Earth TM δεν χρθςιμοποιεί τα αρχικά N(orth), S(outh), E(ast), W(est) για τον κακοριςμό τθσ κατεφκυνςθσ (βορρά, νότο, ανατολι και δφςθ αντίςτοιχα) πάνω ςτθν υφιλιο. Για τθν ακρίβεια θ κατεφκυνςθ δθλϊνεται με τθ χριςθ πρόςθμου. Τα βόρεια γεωγραφικά πλάτθ και τα ανατολικά γεωγραφικά μικθ είναι κετικοί αρικμοί, ενϊ τα νότια γεωγραφικά πλάτθ και τα δυτικά γεωγραφικά μικθ είναι αρνθτικοί αρικμοί. Με χριςθ ενόσ ελζγχου βαςιηόμενου ςτο byte που αντιπροςωπεφει το αρχικό γράμμα τθσ κατεφκυνςθσ, το οποίο και ζχουμε ςαν πλθροφορία από τα δεδομζνα τθσ «πρόταςθσ» GGA που λαμβάνουμε, κακορίηεται το πρόςθμο των ςυντεταγμζνων που επιςτρζφει θ ςυνάρτθςθ αυτι. Οργάνωςθ και καταγραφι δεδομζνων Τα δεδομζνα μασ πλζον με τθν νζα τουσ μορφι, ςφμφωνθ με τισ απαιτιςεισ, αποκθκεφονται ςε μια εςωτερικι δομι που φτιάξαμε, τθν GPS_data. Τθν 103

104 λειτουργία αυτι τθν αναλαμβάνει μια άλλθ ςυνάρτθςθ, θ FillStruct που γεμίηει τα πεδία τθσ εςωτερικισ δομισ, αφοφ πρϊτα τα επεξεργαςτεί καλϊντασ τισ ςυναρτιςεισ που αναλφςαμε παραπάνω όπου χρειάηεται. Στισ προδιαγραφζσ του προγράμματοσ αναφζραμε ότι είναι θ offline καταγραφι τθσ τροχιάσ ενόσ κινθτοφ. Αυτό επιτυγχάνεται με τθν δθμιουργία ενόσ GPX αρχείου, το οποίο ςτθν πραγματικότθτα είναι ζνα XML αρχείο το οποίο περιζχει πλθροφορίεσ για κάκε κζςθ που «επιςκζφτθκε» το κινθτό. Το GPX αρχείο ζχει ςχεδιαςτεί ςαν μια κοινι μορφι δεδομζνων GPS για χριςθ ςε εφαρμογζσ λογιςμικοφ. Μπορεί να χρθςιμοποιθκεί για να περιγράψει ςθμεία γραμμζσ και διαδρομζσ. Στισ «ετικζτεσ» του μποροφν να αποκθκευτοφν θ κζςθ, θ ανφψωςθ και ο χρόνοσ επιτρζποντασ με αυτό τον τρόπο τθ χριςθ του για ανταλλαγι δεδομζνων μεταξφ ςυςκευϊν GPS και εφαρμογϊν λογιςμικοφ, που για τθ δικι μασ εργαςία είναι το Google Earth TM. Στο αρχείο καταγράφονται κάκε ςτιγμι, οι πλθροφορίεσ για τθν κζςθ του κινθτοφ (γεωγραφικό μικοσ και πλάτοσ), το υψόμετρό του και το χρόνο. Μια τζτοια πλθροφορία για μια χρονικι ςτιγμι αποτελεί και ζνα ςθμείο (waypoint). Η διατεταγμζνθ ςυλλογι τζτοιων ςθμείων μπορεί να εκφραςτεί ωσ μια διαδρομι και ζτςι μποροφμε offline να δοφμε ιχνθλατθμζνθ τθν πορεία του κινθτοφ ςτισ δορυφορικζσ εικόνεσ. Το αρχείο GPX, ςτο πρόγραμμά μασ, καταςκευάηεται ςε τρείσ φάςεισ μζχρι να ολοκλθρωκεί και να είναι λειτουργικό, με τθ ςυνδρομι τριϊν ςυναρτιςεων. Αυτζσ είναι οι: void ExportStartXMLfile(), void ExportMiddleXMLfile(GPS_data *instruct) και θ void ExportEndXMLfile(). Κάκε ςυνάρτθςθ ανοίγει ζνα ςυγκεκριμζνο αρχείο.txt και προςκζτει νζεσ πλθροφορίεσ ςτισ ιδθ υπάρχουςεσ. Επειδι ζνα XML αρχείο είναι ζνα string από χαρακτιρεσ εξ οριςμοφ, για τθ δθμιουργία του οι τρείσ ςυναρτιςεισ «γράφουν» ςτο.txt χρθςιμοποιϊντασ τθν fprintf(). Η πρϊτθ ςυνάρτθςθ προςκζτει ςτο αρχείο κάποια αρχικά ςτοιχεία όπωσ επιβάλει θ μορφι που πρζπει να ζχει το GPX ςφμφωνα και με τθ βιβλιογραφία και καλείται μόνο μια φορά ακριβϊσ πριν αρχίςει θ διαδικαςία ανάγνωςθσ των ςειριακϊν πακζτων. Η δεφτερθ προςκζτει τισ κυρίωσ πλθροφορίεσ και τα δεδομζνα που απαιτοφνται για τον κακοριςμό τθσ κζςθσ πάνω ςτο χάρτθ. Τα δεδομζνα για τισ ςυντεταγμζνεσ και το χρόνο περνάνε από τθν εςωτερικι δομι ςτο GPX αρχείο και καταγράφονται εκεί ςτα κατάλλθλα tags. Η ςυνάρτθςθ αυτι, δθλαδι θ void ExportMiddleXMLfile(GPS_data *instruct), καλείται κάκε φορά που τα νζα δεδομζνα από ζνα ειςερχόμενο πακζτο επεξεργάηονται και αποκθκεφονται ςτθν εςωτερικι δομι GPS_data. Στθ ςυνζχεια αναλαμβάνει θ τρίτθ ςυνάρτθςθ προςκζτοντασ τα ςτοιχεία που δθλϊνουν το τζλοσ του GPX αρχείου, ολοκλθρϊνοντάσ το. Αυτι καλείται με δφο τρόπουσ, ανάλογα με το τι κα επιλζξουμε. Μποροφμε να χρθςιμοποιιςουμε το πρόγραμμα λζγοντάσ του να λάβει ζνα ςυγκεκριμζνο αρικμό πακζτων, ο οποίοσ δθλϊνεται με τθν μεταβλθτι int counter2;. Πταν ο μετρθτισ φτάςει τθ τιμι που ορίςαμε ςαν ανϊτατο όριο λιψθσ τότε θ διαδικαςία ανάγνωςθσ πακζτων ςταματάει και το πρόγραμμα τερματίηει καλϊντασ τθ ςυνάρτθςθ void ExportEndXMLfile(). Ο δεφτεροσ τρόποσ είναι να μθν κάνουμε ζλεγχο για το όριο λιψθσ. Σε μια τζτοια περίπτωςθ θ διαδικαςία ανάγνωςθσ επαναλαμβάνεται ςυνεχϊσ και ςταματάει μόνο αν διακοπεί θ φυςικι ςφνδεςθ με τθν ςυςκευι MIB520. Τότε θ ReadFile, ςτον ζλεγχο που γίνεται, επιςτρζφει FALSE και το πρόγραμμα τερματίηει καλϊντασ, εκτόσ των άλλων ενεργειϊν, τθν ςυνάρτθςθ αυτι. Η ςυνάρτθςθ αυτι ςτθν ουςία υλοποιεί το χαρακτθριςτικό του offline. Το GPX αρχείο που δθμιουργικθκε, με όλεσ τισ 104

105 χριςιμεσ πλθροφορίεσ για τθ κζςθ του κινθτοφ κάκε ςτιγμι, κα το «περάςουμε» ςτο Google Earth TM. Εκεί κα διαβαςτεί και κα γίνει απεικόνιςθ των δεδομζνων του ςτισ δορυφορικζσ εικόνεσ. Στο πλαίςιο του τμιματοσ καταγραφισ των δεδομζνων, υλοποιιςαμε και τθν void PassToFile(GPS_data *instruct). Η ςκζψθ μασ ιταν θ δθμιουργία ενόσ αρχείου, ςαν ιςτορικό, των πακζτων που λάβαμε. Αυτό το κάναμε μιασ και τα δεδομζνα τθσ εςωτερικισ δομισ, που χρθςιμοποιοφμε ςτο πρόγραμμα, ζχουν διάρκεια ηωισ μζχρι τθ λιψθ ενόσ νζου πακζτου, από τα νζα δεδομζνα του οποίου αντικακίςτανται. Η ςυνάρτθςθ αυτι δθμιουργεί ζνα νζο αρχείο.txt και εκεί προςκζτει ςε μια νζα γραμμι, κάκε φορά που καλείται, τα περιεχόμενα των πεδίων τθσ δομισ GPS_data που χρθςιμοποιεί το πρόγραμμα. Η κλιςθ τθσ γίνεται, και εδϊ, κάκε φορά που ολοκλθρϊνεται θ λιψθ και επεξεργαςία ενόσ νζου πακζτου. Τζλοσ, ςτο πρόγραμμα επίςθσ περιλαμβάνονται και οι υλοποιιςεισ βοθκθτικϊν ςυναρτιςεων, όπωσ είναι θ PrintMatrix για εκτφπωςθ του προςωρινοφ πίνακα αποκικευςθσ των πακζτων που λαμβάνονται, και θ PrintStruct για εκτφπωςθ τθσ εςωτερικισ δομισ δεδομζνων. Οι δφο αυτζσ ςυναρτιςεισ χρθςιμοποιοφνται περιςςότερο για ζλεγχο τθσ ςωςτισ ροισ των δεδομζνων, οπτικοποιϊντασ ςτο τερματικό τθν διαδικαςία. Τα τμιματα που αναλφκθκαν παραπάνω, ςυνδυάηουν τισ λειτουργίεσ τουσ ςυγκροτϊντασ το πρόγραμμά μασ USB_read. χόλιο: Στον κϊδικα του προγράμματοσ USB_read υπάρχουν ςε διάςπαρτα ςθμεία-κλειδιά πολλά printf(), που ζχουν γίνει ςχόλιο, τα οποία χρθςιμοποιικθκαν για τον ζλεγχο τθσ λειτουργίασ του και τθν ορκι πρόοδο των εργαςιϊν. 6.3 Ανάπτυξθ προγράμματοσ για tracking ςε online mode Ζχοντασ πάρει τα εφόδια γνϊςεων από τθν εναςχόλθςι μασ με το πρόγραμμα C για απεικόνιςθ τθσ κζςθσ/πορείασ ςε offline mode, κάνουμε το επόμενο βιμα για τθν ανάπτυξθ ενόσ προγράμματοσ ςε C# που κα μασ δίνει τθν δυνατότθτα να παρακολουκοφμε τθν εξζλιξθ τθσ κίνθςθσ ενόσ κινθτοφ ςε πραγματικό χρόνο, με άμεςθ απεικόνιςθ ςτθν εφαρμογι Google Earth TM. Το πρόγραμμα αυτό είναι το FirstGEApp. Για τθν παροφςα εργαςία μασ θ γλϊςςα προγραμματιςμοφ C# μασ δίνει αρκετά πλεονεκτιματα και ευελιξία ςε ςχζςθ με τθν C, κακϊσ μποροφμε να κάνουμε ςφνδεςθ του προγράμματόσ μασ με τθ πρότυπθ εφαρμογι Google Earth TM, αλλά και να παρουςιάςουμε μια εφαρμογι ςε παράκυρο (Window Application) ςχεδιάηοντασ ζνα εφχρθςτο γραφικό περιβάλλον για τον χριςτθ (GUI programming). Αυτζσ οι δυνατότθτεσ δεν ιταν διακζςιμεσ ςτθ γλϊςςα C. Επίςθσ, με τθν εμπειρία που αποκτιςαμε, δοκιμάηοντασ το πρόγραμμα USB_read, όςον αφορά ςτο ςφάλμα κζςθσ, κα υλοποιιςουμε μια ςυνάρτθςθ που κα εκτελεί ζνα calibration. Η ςκζψθ μασ είναι αρκετά απλι. Το ςφςτθμα, από τα δεδομζνα που λαμβάνει από τουσ δορυφόρουσ, κα μασ δείχνει τθν εκτιμϊμενθ 105

106 κζςθ μασ. Εμείσ, γνωρίηοντασ ςτθν αρχι το που βριςκόμαςτε, κα υποδεικνφουμε ςτο πρόγραμμα ποια είναι θ πραγματικι μασ κζςθ ςτο χάρτθ. Κάνοντασ μια απλι αφαίρεςθ τθσ εκτιμϊμενθσ από τθν πραγματικι κζςθ κα προκφπτει θ τιμι τθσ διόρκωςθσ που κα εφαρμόηεται ςε κάκε ςυντεταγμζνθ ζτςι ϊςτε να τθν κάνει πιο ακριβι με τα πραγματικά δεδομζνα. Η ςυνάρτθςθ του calibration κάνει μια παραδοχι, κεωρϊντασ τον χϊρο μιασ περιοχισ που δείχνει ο χάρτθσ ςαν επίπεδο και δουλεφει με γραμμικζσ προςεγγίςεισ εκεί. Στθν πράξθ, ςτθν βιβλιογραφία, θ μζκοδοσ αυτι είναι υπαρκτι και καλείται διαφορικό GPS (Differential GPS). Η υλοποίθςι του γίνεται με δφο δζκτεσ GPS, ο ζνασ εκ των οποίων γνωρίηει εκ των προτζρων τθ πραγματικι του κζςθ. Η χριςθ του διαφορικοφ GPS γίνεται ςε εφαρμογζσ που απαιτείται αρκετι ακρίβεια, όπωσ για παράδειγμα ςτθ τοπογραφία. Εμείσ κάνουμε μια προςπάκεια να το εφαρμόςουμε για τον πιο ακριβι εντοπιςμό κζςθσ και ιχνθλάτθςθ πορείασ ενόσ κινθτοφ. Η αρχι τθσ καταςκευισ του προγράμματοσ γίνεται με τον ςχεδιαςμό του παρακφρου επικοινωνίασ με τον χριςτθ. Δίνουμε ςτο γραφικό τθν μορφι που κζλουμε και προςκζτουμε τα κατάλλθλα κουμπιά για τον χειριςμό του προγράμματοσ, βάηουμε menu με επιλογζσ κακϊσ και ζνα πλαίςιο με το όνομα «Log» ςτο οποίο κα αναφζρονται όλεσ οι ενζργειεσ που πραγματοποιεί το πρόγραμμα. Ζτςι ο χριςτθσ μπορεί να ζχει άμεςθ εποπτεία τθσ λειτουργίασ του και κα μπορεί να το ελζγχει καλφτερα. Για κάκε ζνα χαρακτθριςτικό που τοποκετοφμε ςτο γραφικό μασ δθμιουργείται και μια ςυνάρτθςθ με ζνα μοναδικό όνομα. Η ςυνάρτθςθ ζχει κενό τον κϊδικα που υλοποιεί, τον οποίο και ορίηουμε εμείσ. Το παράκυρο ρυκμίηεται ζτςι ϊςτε να είναι πάντα ςε πρϊτο πλάνο κατά τθν εκτζλεςθ τθσ εφαρμογισ. Διακζτει ζνα τμιμα για τον κακοριςμό των ρυκμίςεων τθσ ςφνδεςθσ, ζνα πλαίςιο για τθν αποκικευςθ (capture) τοποκεςιϊν από το Google Earth TM, για γριγορθ περιιγθςθ, το πλαίςιο του ιςτορικοφ ενεργειϊν (log), μπάρεσ για άμεςθ ρφκμιςθ του εφρουσ και τθσ ταχφτθτασ τθσ κίνθςθσ τθσ κάμερασ όταν λζμε ςτθν εφαρμογι να μεταβεί ςε μια ςυγκεκριμζνθ κζςθ, κακϊσ και ζνα menu με επιλογζσ Options και Opacity. Στα options θ default επιλογι είναι το Follow GPS που εκτελεί αυτό ακριβϊσ που δθλϊνει και το όνομά του. Ανάλογα με τα δεδομζνα που ζρχονται από τον κόμβο με το GPS θ κάμερα του Google Earth TM μετακινείται για να δείχνει κάκε φορά τθ κζςθ μασ. Η άλλεσ επιλογζσ είναι για εκκακάριςθ του ιςτορικοφ (clear Log), για να εμφανίηονται ςτο ιςτορικό όλεσ οι πλθροφορίεσ που αποκθκεφονται ςτον εςωτερικό πίνακα εκτόσ από το γεωγραφικό μικοσ και πλάτοσ, και θ επιλογι για calibrate. Το Opacity, κακορίηει τθν διαφάνεια του γραφικοφ παράκυρου. Αυτό, επειδι ζχουμε ορίςει, όπωσ είπαμε, το παράκυρο να είναι ςε πρϊτο πλάνο και ίςωσ να κρφβει ζνα μζροσ από τισ δορυφορικζσ εικόνεσ του Google Earth TM. Οι επιλογζσ αυτζσ, για περιςςότερθ ευκολία ςτο χριςτθ, ορίςαμε να διακζτουν και ςυντομεφςεισ. Η ςφνδεςθ του προγράμματόσ μασ με το Google Earth TM υλοποιείται προςκζτοντασ μια αναφορά προσ τθ ςυγκεκριμζνθ εφαρμογι. Οι αναφορζσ ςε εφαρμογζσ γίνεται από ζνα ειδικό μενοφ με το όνομα «References» που ζχει θ πλατφόρμα ανάπτυξθσ C# προγραμμάτων Microsoft Visual Studio, τθν οποία και χρθςιμοποιιςαμε. Επιλζγουμε «Add Reference» και κάνουμε «browse» μζχρι να βροφμε ςτο κατάλλθλο φάκελο το αρχείο EARTHLib.dll. Ζτςι, κάνουμε μια ςφνδεςθ με τθ δυναμικι βιβλιοκικθ του Google Earth TM και μποροφμε ςτθν ουςία 106

107 να χρθςιμοποιιςουμε το API τθσ εφαρμογισ αυτισ, για τον ζλεγχο χαρακτθριςτικϊν τθσ, μζςω του προγράμματόσ μασ. Πταν ξεκινάμε το πρόγραμμά μασ, τρζχει θ ςυνάρτθςθ frmviewcapture_load. Η φόρτωςθ του παρακφρου «View Capture», όπωσ είναι και το όνομά τθσ, εκτελεί μια ςειρά από ενζργειεσ. Αρχικά δθλϊνει τθν ζναρξθ του προγράμματοσ ςτο πλαίςιο Log και ςτθ ςυνζχεια ανοίγει τθν εφαρμογι Google Earth TM. Αν θ εφαρμογι ανοίξει κανονικά βγάηει ζνα μινυμα ςτο Log για ενθμζρωςθ του χριςτθ, ενϊ ςε αντίκετθ περίπτωςθ απενεργοποιοφνται οι επιλογζσ «Follow GPS» και «Calibrate» για να μθν κολλιςει το πρόγραμμα, ενθμερϊνοντασ το χριςτθ ότι υπιρξε πρόβλθμα ςτο άνοιγμα τθσ εφαρμογισ. Η απενεργοποίθςθ των παραπάνω επιλογϊν γίνεται κζτοντασ FALSE το πεδίο «enable» που βρίςκεται ςτισ ιδιότθτεσ (properties) τθσ κάκε επιλογισ. Επιπρόςκετα για το «Follow GPS» κζτουμε και το πεδίο «checked» ςε FALSE μιασ και είναι προεπιλεγμζνο. Τθν καταγραφισ το πεδίο «Log» τθν υλοποιιςαμε με τθ ςυνάρτθςθ logme θ οποία καλείται κάκε φορά που κζλουμε να γράψουμε ζνα μινυμα ςτο ιςτορικό. Το μινυμα καταγράφεται μαηί με τθν ϊρα καταχϊρθςθσ. Από τθ ςτιγμι λοιπόν που κα εκκινιςει το πρόγραμμά FirstGEApp, το επόμενο βιμα είναι να ελζγξουμε τισ παραμζτρουσ ςφνδεςθσ. Οι παράμετροι είναι ίδιοι, προφανϊσ, με αυτζσ που αναλφςαμε ςτο πρόγραμμα USB_read απλϊσ αυτι τθ φορά ορίηονται με επιλογι ςε πεδία ςτο γραφικό περιβάλλον. Θα μποροφςαμε να βάλουμε περιςςότερεσ επιλογζσ για τθν κάκε παράμετρο ςφνδεςθσ, αλλά δεν είναι αυτόσ ο ςκοπόσ μασ ςε αυτι τθ φάςθ. Ορίηουμε για το κάκε πεδίο Baudrate, DataBits, Parity, PortName, StopBits κζτουμε τισ τιμζσ αντίςτοιχα 57600, 8, 0, COM5, 1. Ζχοντασ ορίςει αυτζσ τισ τιμζσ όταν προςκζταμε τα πεδία αυτά, μποροφμε να τισ διαχειριςτοφμε μζςα από τον κϊδικα του προγράμματόσ μασ. Με το γραφικό να ζχει φορτϊςει επιτυχϊσ, το επόμενο βιμα είναι να υλοποιιςαμε το κουμπί Start/Stop. Το κουμπί αυτό ςυνδζεται με τθν ςυνάρτθςθ btnstartstop_click. Σε αυτιν περιγράφεται θ λειτουργία του. Αν το κείμενο πάνω ςτο κουμπί είναι «Start» ςθμαίνει ότι θ ςειριακι ςφνδεςθ δεν ζχει αποκαταςτακεί. Ρατϊντασ το πλικτρο, το κείμενο γίνεται «Stop», το πρόγραμμα παίρνει τισ προεπιλεγμζνεσ τιμζσ που ζχουμε δθλϊςει ςτα πεδία των παραμζτρων ςφνδεςθσ και τισ χρθςιμοποιεί για να ανοίξει τθ κφρα COM5, δίνοντασ και αναφορά για το τι κάνει ςτο Log. Αφοφ πάρει τισ τιμζσ από τα παραπάνω πεδία, τα απενεργοποιεί για να μθν μπορεί μετά να επζμβει ο χριςτθσ ςε αυτά αλλάηοντάσ τα, ενϊ υπάρχει θ ςφνδεςθ. Αν θ ςφνδεςθ γίνει επιτυχϊσ ενεργοποιείται θ ζνδειξθ «Connected» κάνοντάσ τθν ορατι. Ππωσ αναφζραμε, το κουμπί αυτό είναι τφπου «Start/Stop». Αυτό ςθμαίνει ότι και για να διακόψουμε τθ ςφνδεςθ πατάμε το ίδιο κουμπί, που τϊρα όμωσ κα ζχει τθν ζνδειξθ Stop πάνω του. Και αυτι θ λειτουργία περιγράφεται από τθν ίδια ςυνάρτθςθ, ακολουκϊντασ τισ εξισ ενζργειεσ: Ενεργοποιεί ξανά τα πεδία με τισ παραμζτρουσ ςφνδεςθσ που είχαν απενεργοποιθκεί μετά το επιτυχζσ άνοιγμα τθσ ςειριακισ κφρασ. Αναφζρει ςτο ιςτορικό ότι θ ςφνδεςθ με τθν κφρα διακόπτεται. Διαβάηει τα εναπομείνοντα, τυχϊν, bytes πακζτου που ζχουν μείνει ςτουσ buffers τθσ. Κάνει και πάλι αόρατθ τθν ζνδειξθ «Connected». 107

108 Αλλάηει το κείμενο του κουμπιοφ ςε «Start», δθλϊνοντασ ζτςι ότι θ ςφνδεςθ διακόπθκε και θ επόμενθ ενζργεια που κα γίνει αν πατθκεί πάλι το πλικτρο κα είναι θ προςπάκεια επαναςφνδεςθσ. Αν ςε κάποια από τισ παραπάνω προςπάκειεσ ςφνδεςθσ/αποςφνδεςθσ προκφψει ςφάλμα τότε δθλϊνεται ςτο ιςτορικό. Μετά τθν αποκατάςταςθ τθσ ςειριακισ ςφνδεςθσ με τθν δοκείςα κφρα, αναλαμβάνει θ ςυνάρτθςθ gps_timer_tick, θ οποία καλείται κάκε ζνα δευτερόλεπτο, όςο δθλαδι και θ περίοδοσ αποςτολισ των πακζτων δεδομζνων από τον απομακρυςμζνο κόμβο με τον δζκτθ GPS. Τθ δυνατότθτα αυτι μασ τθ δίνει το Visual Studio τθσ Microsoft με χριςθ ενόσ timer ςτο GUI μασ. Ο timer αυτόσ ορίηεται, όταν τον φτιάχνουμε να ζχει interval 100 msec, κάτι που ςθμαίνει ότι ελζγχει τθ κφρα USB δζκα φορζσ το δευτερόλεπτο για ειςερχόμενα πακζτα. Η ςυνάρτθςθ αυτι εφαρμόηει ζναν ζλεγχο κατά τον οποίο αν το πακζτο, που υπάχει ςτουσ buffers τθσ κφρασ, είναι μικρότερο από 22 bytes τότε απορρίπτεται. Ο αρικμοσ 22 μόνο τυχαίοσ δεν είναι. Το 22 ο byte ενόσ πακζτου αντιπροςωπεφει το fixquality πεδίο τθσ GGA «πρόταςθσ». Επομζνωσ, ο αρικμόσ αυτόσ, ορίηει τα ελάχιςτα απαιτοφμενα bytes για να μπορεί να λειτουργιςει ςωςτά ο εντοπιςμόσ τθσ κζςθσ ςτθν εφαρμογι Google Earth TM. Αν ικανοποιθκεί ο παραπάνω ζλεγχοσ, τότε το πακζτο αποκθκεφεται ςε ζνα τοπικό εςωτερικό πίνακα. Για να οπτικοποιθκεί θ διαδικαςία του διαβάςματοσ ενόσ ςειριακοφ πακζτου, κάνουμε ορατό το πλαίςιο κειμζνου «Receiving», το οποίο και μζνει ζτςι για το χρόνο που διαρκεί αυτι. Επιπλζον ζλεγχοσ γίνεται για το αν το λθφκζν πακζτο ξεκινάει με τα bytes 126, 69. Οι αρικμοί αυτοί διαπιςτϊκθκαν ςαν αρχι των πακζτων από δοκιμζσ με το πρόγραμμα USB_read και πικανότατα αντιπροςωπεφουν κάποιο προκεμα που βάηουν τα windows ςτο κάκε πακζτο. Αν οι αρικμοί αυτοί δεν εντοπιςτοφν ςτθν αρχι ενόσ νζου πακζτου, τότε κεωρείται ότι για κάποιο λόγο αυτό δεν λιφκθκε ςωςτά και το απορρίπτουμε. Μζςα ςτθ ςυνάρτθςθ αυτι καλείται θ get_decimal_coordinate θ οποία εκτελεί τθν ίδια επεξεργαςία ςτισ ςυντεταγμζνεσ, όπωσ θ fixcoordinates που αναλφςαμε ςτο πρόγραμμα ςτθ C, για να τισ φζρει ςτθν μορφι που απαιτεί το Google Earth TM. Με ζναν ζξυπνο ζλεγχο, κοιτάμε αν οι καινοφριεσ τιμζσ των ςυντεταγμζνων είναι πολφ διαφορετικζσ από τισ ακριβϊσ προθγοφμενεσ που λάβαμε. Αν ιςχφει κάτι τζτοιο, τότε απορρίπτονται κεωρϊντασ ςφάλμα μζτρθςθσ. Η ςυνάρτθςθ αυτι, εκτόσ από αυτά που ζχουμε ιδθ αναφζρει, ζχει και κομμάτι κϊδικα που αναφζρεται ςτο calibration. Αν αυτό ζχει επιλεχκεί από το menu τότε βγάηει μια μζςθ εκτίμθςθ για τισ ςυντεταγμζνεσ μασ, χτθςιμοποιϊντασ δεδομζνα από είκοςι πακζτα, τα οποία κα λθφκοφν μετά τθν ενεργοποίθςθ τθσ επιλογισ. Στο τμιμα αυτό τθσ ςυνάρτθςθσ, όταν είναι ενεργό, κάκε πακζτο που ςυνδράμει ςτθν εξαγωγι τθσ μζςθσ εκτίμθςθσ, αναφζρεται ςτο ιςτορικό με κατάλλθλο μινυμα. Στθ ςυνζχεια γίνεται θ διόρκωςθ των ςυντεταγμζνων με βάςθ μεταβλθτζσ που ενθμερϊνονται ςτθν ςυνάρτθςθ calibrateevtoolstripmenuitem που είναι υπεφκυνθ για τθ λειτουργία του calibration. Τζλοσ κάκε φορά που λαμβάνεται νζεσ ςυντεταγμζνεσ, διορκωμζνεσ ι μθ, ανάλογα με το αν ζχει γίνει μζχρι τότε calibration, θ κάμερα ςτθν εφαρμογι Google Earth TM μετακινείται και εςτιάηει ςτθ κζςθ μασ. Η μετακίνθςθ τθσ κάμερασ γίνεται με τθν κλιςθ τθσ ςυνάρτθςθσ movege_lon_lat, θ οποία δθμιουργεί ζνα ςτιγμιότυπο κάμερασ που εςτιάηει ςτισ τιμζσ γεωγραφικοφ μικουσ και πλάτουσ που δίνουμε ςαν παραμζτρουσ. Οι τιμζσ τθσ ταχφτθτασ τθσ κίνθςθσ και του εφρουσ τθσ 108

109 κάμερασ ρυκμίηονται από τισ δφο μπάρεσ που υπάρχουν ςτο γραφικό. Να ςθμειϊςουμε ότι, αν είναι ενεργοποιθμζνθ θ επιλογι «Log everything» από το μενοφ «Options», τότε καλείται θ ςυνάρτθςθ logme και εμφανίηει ςτο «Log» τθ μεταβλθτι data τθν οποία ςιγά ςιγά τθν γεμίςαμε με όλα τα δεδομζνα. Η λογικι του differential GPS που υλοποιιςαμε ςτο πρόγραμμά μασ, εκτελείται όταν επιλζξουμε το ςτοιχείο «Calibrate» από το μενοφ «Options». Η ςυνάρτθςθ που το υλοποιεί είναι θ calibrateevtoolstripmenuitem, θ οποία και μπορεί να εκτελεςτεί μόνο αν θ ςειριακι κφρα είναι ανοιχτι. Αν δεν είναι ανοιχτι, θ ςυνάρτθςθ τερματίηει τθ λειτουργία τθσ, βγάηοντασ ζνα μινυμα ςτο ιςτορικό με απαίτθςθ από τον χριςτθ για ικανοποιθςθ αυτισ τθσ προχπόκεςθσ. Στθ ςυνζχεια αναλαμβάνει το τμιμα τθσ gps_timer_tick που είδαμε παραπάνω, ακροίηοντασ ςυντεταγμζνεσ για τθν εξαγωγι τθσ μζςθσ εκτίμθςθσ. Μζχρι να ακροιςτοφν οι ςυντεταγμζνεσ είκοςι προτάςεων, θ παροφςα ςυνάρτθςθ βγάηει ζνα μινυμα ςε μορφι παρακφρου, που ενθμερϊνει τον χριςτθ πωσ πρζπει να περιμζνει μζχρι να ολοκλθρωκεί θ εςωτερικι επεξεργαςία. Πταν τελειϊςει θ διαδικαςία τθσ άκροιςθσ, υπολογίηεται θ μζςθ εκτίμθςθ τθσ κζςθσ (median_lat, median_lon) και από εκεί και πζρα αναλαμβάνει ο χριςτθσ χειροκίνθτα να «δείξει» ςτο πρόγραμμα ποια είναι θ πραγματικι του κζςθ. Για να γίνει αυτό, θ ςυνάρτθςθ απενεργοποιεί τθν επιλογι «Follow GPS» για να μπορεί ο χριςτθσ να δουλζψει με τον χάρτθ. Από τθ ςτιγμι που κα γίνει θ καταχϊρθςθ τθσ πραγματικισ κζςθσ, υπολογίηεται αμζςωσ θ απόκλιςθ από τθν μζςθ εκτίμθςθ και προκφπτει το ςφάλμα (error_lat, error_lon) που ζχουν οι ςυντεταγμζνεσ που λαμβάνουμε από τον δζκτθ GPS. Αυτό το ςφάλμα κα το χρθςιμοποιεί ςτθ ςυνζχεια το πρόγραμμα ςε κάκε νζο πακζτο που διαβάηει, για να κάνει διόρκωςθ ςτισ ςυντεταγμζνεσ, δίνοντασ με μεγαλφτερθ ακρίβεια τθ κζςθ μασ. Να ςθμειωκεί, ότι και ςε αυτό το πρόγραμμα υλοποιείται θ δθμιουργία ενόσ «.GPX» αρχείου για τθν καταγραφι και απεικόνιςθ όλθσ τθσ κίνθςθσ που ιχνθλατικθκε ςτο Google Earth TM με ζνα γραφικό για τθν εφκολθ εξαγωγι ςυμπεραςμάτων. Η ςυνάρτθςθ αυτι είναι θ export_gpx_click και υλοποιεί τθ λειτουργία του κουμπιοφ «Export GPX». Το κείμενου του κουμπιοφ αλλάηει μεταξφ των καταςτάςεων, από «Export GPX» ςε «Finish GPX» και ανάποδα, ανάλογα με το πάτθμα. Η καταγραφι των ςθμείων εντοπιςμοφ (waypoints) ςτο αρχείο γίνεται κάκε ζνα δευτερόλεπτο, μζςα ςτο ςϊμα τθσ gps_timer_tick, και ςυνεχίηεται μζχρι να πατθκεί το «Finish GPX» οπότε και κλείνουν, τα όποια ανοιγμζνα, tags του και κλείνει θ πρόςβαςθ που είχαμε ςτο αρχείο για γράψιμο. Τα κατάλλθλα μθνφματα εμφανίηονται ςτο ιςτορικό ενθμερϊνοντασ τον χριςτθ για τθν εξζλιξθ των γεγονότων. Επίςθσ, υπάρχει το μενοφ «Opacity» που ελζγχεται από επτά ςυναρτιςεισ, μία για κάκε επιλογι. Ανάλογα με το ποςοςτό ορατότθτασ του παρακφρου «View Capture», καλείται και θ αντίςτοιχθ ςυνάρτθςθ που εφαρμόηει το μζγεκοσ τθσ αδιαφάνειασ που ζχει επιλεγεί από το χριςτθ. Μια πρόςκετθ λειτουργία του προγράμματοσ δθλϊνεται με το πλικτρο «Capture» και υλοποιείται από τθ ςυνάρτθςθ btncapture_click. Στο ςϊμα τθσ γίνεται κλιςθ τθσ ςυνάρτθςθσ capturegeview, θ οποία δίνει τθ δυνατότθτα ςτο χριςτθ να αποκθκεφςει ςε εςωτερικζσ μεταβλθτζσ τισ ςυντεταγμζνεσ μιασ τοποκεςίασ που κζλει απλϊσ επιλζγοντάσ τθν πάνω ςτον χάρτθ. Κάκε φορά που ο χριςτθσ κάνει capture μια τοποκεςία, εμφανίηεται και ζνα νζο view ςτο πλαίςιο 109

110 «Vies from Google Earth» του παρακφρου του προγράμματοσ. Κάνοντασ διπλο κλικ ςε ζνα από αυτά τα views το Google Earth TM μασ πλοθγεί ςτθν αντίςτοιχθ τοποκεςία. Πταν επιλζξουμε ζνα view, θ διαχείριςθ των δεδομζνων που ζχει αποκθκεφςει γίνεται με τθν κλιςθ τθσ ςυνάρτθςθσ treeview1_mouseclick. Επι τθσ ουςίασ, θ ςυνάρτθςθ βρίςκει τα δεδομζνα που ςχετίηονται με το view που επιλζχκθκε και τα ανακζτουν ςε ζνα ςτιγμιότυπο κάμερασ για να γίνει θ πλοιγθςθ. Η λειτουργία τθσ πλοιγθςθσ υλοποιικθκε με τθ ςυνάρτθςθ movege. Η ςυνάρτθςθ frmviewcapture_formclosing υλοποιικθκε για το κλείςιμο του προγράμματοσ. Καλείται όταν ο χριςτθσ πατιςει το πλικτρο «Χ», που βρίςκεται πάνω δεξιά ςτο παράκυρο τθσ γραφικισ διεπαφισ. Ραρόλο που περιλαμβάνει λειτουργίεσ που δεν οπτικοποιοφνται ςτον χριςτθ, είναι απαραίτθτθ θ παρουςία τθσ διαφορετικά το πρόγραμμα μπορεί να κολλιςει ςτο τερματιςμό του. Οι ενζργειεσ που κάνει είναι: Βγάηει μινυμα ςτο «Log» αναφζροντασ το κλείςιμο του προγράμματοσ. Αυτό δεν γίνεται ορατό ςτον χριςτθ αλλά για να είμαςτε τυπικοί και ςωςτοί πρζπει να το εφαρμόςουμε. Διαβάηει τα bytes που μπορεί να ζχουν μείνει ςτον buffer τθσ κφρασ. Κλείνει τθν ςειριακι κφρα. Απενεργοποιεί τθν ζνδειξθ «Connected». Στον κϊδικα του προγράμματοσ, που παρατίκεται ςτο παράρτθμα Β, ζχουν γίνει ςχόλια ςε αρκετά ςθμεία για τθν καλφτερθ κατανόθςι του. Εικόνα: Σο GUI (Graphic User Interface) του προγράμματοσ FirstGEApp ςε C#. Με αυτι τθ διεπαφι χριςτθ γίνεται ο ζλεγχοσ όλων των λειτουργιϊν του προγράμματοσ 110

111 ΚΕΦΑΛΑΙΟ 7 ο Εφαρμογι και Πειραματικι μελζτθ 7.1 Ειςαγωγι Ζχοντασ παρουςιάςει ςτα προθγοφμενα κεφάλαια τισ ενζργειεσ που ακολουκιςαμε για τθν δθμιουργία όλων των απαραίτθτων εφαρμογϊν και προγραμμάτων που είναι απαραίτθτα για τθν εργαςία μασ, πλζον είμαςτε ζτοιμοι να υλοποιιςουμε το ςφςτθμά μασ και να τα βάλουμε να ςυνεργαςτοφν με το διακζςιμο υλικό, ςφμφωνα με το οποίο αναπτφχκθκαν, για να ελζγξουμε τθν αποτελεςματικότθτά του. Μιασ και τα δφο προγράμματα που υλοποιιςαμε, για διάβαςμα πακζτων από τθν κφρα USB του υπολογιςτι, εκτελοφν περίπου τθν ίδια λειτουργία, κα χρθςιμοποιιςουμε το USB_read με το offline tracking για τον εντοπιςμό τθσ κζςθσ μασ και τθν απεικόνιςισ τθσ ςτθν πρότυπθ εφαρμογι Google Earth TM, ενϊ το FirstGEApp με τθ δυνατότθτα του online tracking κα το χρθςιμοποιιςουμε για τθν παρακολοφκθςθ ςτο Google Earth TM τθσ πορείασ ενόσ κινθτοφ που φζρει το ςφςτθμά μασ. 7.2 Προεργαςία - Προετοιμαςία πειράματοσ Για τθν διεξαγωγι του πειράματοσ το διακζςιμο υλικό που ζχουμε ςτθ κατοχι μασ είναι: Δφο κόμβοι IRIS (ΧΜ2110CA) τθσ εταιρείασ Crossbow για το ςχθματιςμό ενόσ υποτυπϊδουσ WSN Μια πλακζτα MTS420CC sensor board θ οποία φζρει πάνω τθσ πζντε βαςικζσ περιβαλλοντικζσ αιςκθτιριεσ παραμζτρουσ και δζκτθ GPS τθσ εταιρείασ ublox μοντζλο LEA-4A. Εξωτερικι ειδικι κεραία τθσ εταιρείασ LAIPAC TECH μοντζλο P1για τθ λειτουργία του GPS module του sensor board. Αναπτυξιακό board ΜΙΒ520 για τον προγραμματιςμό των κόμβων με τισ εφαρμογζσ που αναπτφξαμε και τθν επικοινωνία με αυτοφσ για ανταλλαγι δεδομζνων. Φορθτόσ υπολογιςτισ εξοπλιςμζνοσ με το TinyOS περιβάλλον και τα προγράμματα που αναπτφξαμε για διάβαςμα από ςειριακι κφρα USB. Αρχικά κάνουμε εγκατάςταςθ των TinyOS εφαρμογϊν που αναπτφξαμε ςτουσ κόμβουσ IRIS που κα χρθςιμοποιιςουμε ςτθν εφαρμογι μασ. Επιςυνάπτουμε τον κόμβο που κα λειτουργεί με το GPS module ςτο αναπτυξιακό, πάνω ςτον 51-pin connector, το οποίο είναι ςυνδεδεμζνο ςε μια κφρα USB του υπολογιςτι. Μπαίνοντασ ςτο TOS environment, κάνουμε εγκατάςταςθ τθσ εφαρμογισ 111

112 MyMoteSendReceiveGPS ςτον κόμβο με τθν εντολι «make iris install mib510,/dev/ttyusb0». Η εφαρμογι φορτϊνει ςτον κόμβο (το κόκκινο led με τθν ζνδειξθ ISP ανάβει) και θ εγκατάςταςθ ολοκλθρϊνεται με επιτυχία. Απομακρφνουμε τον κόμβο από το αναπτυξιακό και του επιςυνάπτουμε το sensor board MTS420CC. Στθ ςυνζχεια ςυνδζουμε τθν εξωτερικι κεραία GPS ςτθν κατάλλθλθ υποδοχι τθσ πλακζτασ αιςκθτιρων και εξοπλίηουμε τον κόμβο με δφο μπαταρίεσ τφπου ΑΑ (1.5 Volt) που κα είναι και θ πθγι ιςχφοσ του. Στθ ςυνζχεια με τθν ίδια διαδικαςία εγκακιςτοφμε τθν εφαρμογι DataSinkFiFoGPS ςτον ζτερο κόμβο IRIS που κζλουμε να ζχει τον ρόλο του ςτακμοφ βάςθσ. Και ο κόμβοσ αυτόσ φορτϊνει τθν ςυγκεκριμζνθ εφαρμογι μασ με επιτυχία και λειτουργεί πλζον ςαν κεντρικόσ κόμβοσ για ςυλλογι δεδομζνων από το δίκτυο, μζνοντασ επιςυνθμμζνοσ ςτο αναπτυξιακό και χωρίσ να του βάλουμε μπαταρίεσ μιασ και τροφοδοτείται από τθν Εικόνα: Σο ςφςτθμα των εφαρμογϊν που αναπτφξαμε και χρθςιμοποιοφμε ςτα πλαίςια τθσ παροφςασ εργαςίασ κφρα USB. Το τμιμα του WSN του ςυςτιματόσ μασ είναι ζτοιμο. Από πλευράσ υπολογιςτι τα δφο προγράμματα που υλοποιιςαμε ςε C και C#, είναι ζτοιμα για χριςθ ςε πραγματικζσ ςυνκικεσ, αποκακιςτϊντασ όποτε τα τρζξουμε επικοινωνία με τθν κφρα USB, για τθν επίτευξθ ςυνεργαςίασ μεταξφ WSN host PC με ςκοπό τθν απεικόνιςθ των μετριςεων του δικτφου ςτθν πρότυπθ και παγκόςμια εφαρμογι Google Earth TM. 7.3 Εντοπιςμόσ κζςθσ και απεικόνιςθ ςτο Google Earth TM ςε offline mode Για να ξεκινιςουμε τθ διαδικαςία του πειράματοσ, αρχικά τοποκετοφμε τον κόμβο με το GPS module και τθν κεραία ςε κατάλλθλο ςτακερό ςθμείο. Ο δζκτθσ GPS για να λειτουργιςει ςωςτά πρζπει να βρίςκεται ςε εξωτερικοφσ χϊρουσ και να βλζπει ανοιχτό ορίηοντα. Με αυτόν τον τρόπο ο δζκτθσ κα μπορεί να δει όςο το δυνατόν περιςςότερουσ δορυφόρουσ δίνοντασ μεγαλφτερθ ακρίβεια. Επίςθσ, κα πρζπει να αποφεφγεται κατά το δυνατόν θ παρουςία ψθλϊν κτιρίων ι αντικειμζνων 112

113 δίπλα ςτον δζκτθ για να μειϊνεται ςτο ελάχιςτο θ πικανότθτα εμφάνιςθσ ςφάλματοσ πολυανάκλαςθσ (multipath error). Ζχουμε τον κόμβο λοιπόν ςε ςτακερό ςθμείο για να βλζπει κακαρό ουρανό και πάντα μζςα ςτθν εμβζλεια του κόμβου βάςθσ, που είναι επιςυνθμμζνοσ ςτον φορθτό υπολογιςτι. Στον τελευταίο, τρζχουμε το πρόγραμμα USB_read για επικοινωνία του υπολογιςτι με τον ςτακμό βάςθσ του WSN, αφοφ του κζςαμε όριο 50 πακζτα που ςθμαίνει ότι κα αρχίςει να επεξεργάηεται τα δεδομζνα όταν λάβει το 51 ο πακζτο. Το πρόγραμμα ανοίγει και χωρίσ να αναφζρει ςφάλματα τίκεται ςε κατάςταςθ αναμονισ ακοφγοντασ ςυνεχϊσ τθ κφρα USB για ειςερχόμενα ςειριακά πακζτα. Γυρνάμε τον διακόπτθ του απομακρυςμζνου mote, με τον δζκτθ GPS, ςτο ΟΝ και αμζςωσ ξεκινάει να τρζχει ςτο εςωτερικό του θ εφαρμογι MyMoteSendReceiveGPS. Η εξζλιξθ των διαδικαςιϊν ςτο mote γίνονται αντιλθπτζσ με τθν παρακολοφκθςθ των leds του. Στθν αρχι το μόνο led που ανάβει είναι το πράςινο, το οποίο ςυνεχϊσ αλλάηει κατάςταςθ κάκε δευτερόλεπτο. Η χρόνοσ αυτόσ είναι και θ περίοδοσ αποςτολισ από τον δζκτθ GPS των προτάςεων που ςυμπλθρϊνει (και των επτά) προσ τον κόμβο. Η αλλαγι κατάςταςθσ του πράςινου led κακϊσ και θ ςυγκεκριμζνθ περιοδικότθτά του μασ δίνουν να καταλάβουμε ότι βριςκόμαςτε ςτθν εκτζλεςθ του κϊδικα που υποδεικνφει θ ςθματοδότθςθ του event NmeaRawReceive.received. Για να γίνει αυτό ςθμαίνει ότι ξεπεράςτθκαν επιτυχϊσ οι προθγοφμενοι ζλεγχοι που αναλφςαμε ςτο κεφάλαιο ανάπτυξθσ των εφαρμογϊν. Αυτό δθλϊνει ότι ζγινε λιψθ δεδομζνων από τον δζκτθ ςωςτά, θ δομι ςτθν οποία κα αποκθκευτεί θ ειςερχόμενθ «πρόταςθ» GGA που μασ ενδιαφζρει χωράει ςτο payload του πακζτου για αςφρματθ μετάδοςθ και τζλοσ, ότι απομονϊκθκε ςωςτά θ ΝΜΕΑ «πρόταςθ» GGA από το ςφνολο των προτάςεων που ςτζλνει ο δζκτθσ ςτον κόμβο. Το ςφάλμα που αναφζρεται με το πράςινο led είναι ότι το πεδίο fixquality τθσ «πρόταςθσ» αυτισ δεν ζχει μια αποδεκτι τιμι (είναι fixquality = FIX_INVALID θ οποία είναι μια ςτακερά οριςμζνθ μθδζν) και ζτςι θ πρόταςθ απορρίπτεται. Πταν ο δζκτθσ ςυγχρονιςτεί με τουσ ορατοφσ δορυφόρουσ τότε θ «πρόταςθ» κα αποτελείται από ζγκυρα ςτοιχεία και το fixquality κα γίνει valid. Ο ςυγχρονιςμόσ επζρχεται μετά από περίπου ζνα λεπτό και τριάντα δευτερόλεπτα οπότε και αρχίηω να ζχω διαδικαςία αποςτολισ λιψθσ πακζτων και εμφάνιςι τουσ ςτθν οκόνθ του τερματικοφ ςτα windows. Στον απομακρυςμζνο κόμβο κάκε φορά που γίνεται αποςτολι παρατθροφμε τθν αλλαγι κατάςταςθσ ςτο κίτρινο led, μαηί με το οποίο αλλάηει κατάςταςθ και το κόκκινο led που του ζχουμε βάλει να αναφζρει τθν είςοδο του GPS module ςε κατάςταςθ λειτουργίασ μειωμζνθσ κατανάλωςθσ. Ζτςι λοιπόν, οπτικοποιείται αυτό ακριβϊσ που υλοποιιςαμε ςτθν εφαρμογι, ότι δθλαδι όταν θ «πρόταςθ» GGA λθφκεί επιτυχϊσ από το mote απενεργοποιείται ο δζκτθσ GPS μζχρι να γίνει θ αποςτολι του πακζτου μζςω radio και μετά ενεργοποιείται ξανά για να δϊςει ςειριακά μια νζα «πρόταςθ». Τα ολοκλθρωμζνα του πομποδζκτθ και του GPS module είναι από τισ ςυςκευζσ που καταναλϊνουν τθ περιςςότερθ ιςχφ ςτο ςφςτθμα και για αυτό ακολουκοφμε μια λογικι του να μθν είναι και τα δφο μαηί ενεργοποιθμζνα αλλά να ενεργοποιοφνται εναλλάξ, μειϊνοντασ τθ ςυνολικι κατανάλωςθ. Τζλοσ, το flashing του πράςινου led μετά το ςυγχρονιςμό δθλϊνει το άνοιγμα κλείςιμο του πομποδζκτθ. Στθν πραγματικότθτα το led ανάβει όταν ενεργοποιείται το radio και ςβινει όταν απενεργοποιείται, αλλά επειδι οι λειτουργίεσ αυτζσ διαρκοφν για πολφ μικρό χρονικό διάςτθμα δίνεται αυτι θ εντφπωςθ για το led. 113

114 Στθν πλευρά του ςτακμοφ βάςθσ τα leds αναβοςβινουν εκτελϊντασ μια δικι τουσ χορογραφία. Στθν αρχι το κόκκινο και πράςινο led αναβοςβινουν ακαριαία. Ανάβουν ςτθν εκκίνθςθ τθσ εφαρμογισ (boot) και το κλείςιμό τουσ ςθματοδοτεί ότι ζγινε ςωςτά θ ενεργοποίθςθ τόςο του πομποδζκτθ όςο και τθσ UART. Πταν ζνα πακζτο λαμβάνεται από τον απομακρυςμζνο κόμβο αλλάηει κατάςταςθ το κίτρινο led. Αυτό επομζνωσ, ςυμβαίνει κάκε δευτερόλεπτο. Η αλλαγι κατάςταςθσ ςτο πράςινο led ςτθ ςυνζχεια δθλϊνει ότι το πακζτο, που λιφκθκε από τθν αςφρματθ μετάδοςθ ςτα πλαίςια του WSN, μεταδόκθκε ςειριακά μζςω UART ςτον buffer τθσ κφρασ USB όπου και περιμζνει να διαβαςτεί από το κατάλλθλο πρόγραμμα. Το κόκκινο led, που αλλάηει κατάςταςθ μόνο για να αναφζρει ςφάλματα μετά τθν εκκίνθςθ, δεν ανάβει ποτζ δίνοντασ το ςτίγμα τθσ ςωςτισ λειτουργίασ τθσ εφαρμογισ μασ. Στον υπολογιςτι, όπου τρζχει το πρόγραμμα USB_read τα πακζτα διαβάηονται ςειριακά byte προσ byte και απεικονίηονται με αυτό τον τρόπο ςτθν οκόνθ του τερματικοφ. Πταν το όριο που ζχουμε κζςει ξεπεραςτεί, όταν δθλαδι ζχουν λθφκεί 50 πακζτα, αρχίηει θ επεξεργαςία των δεδομζνων των ειςερχόμενων προτάςεων και θ αποκικευςι τουσ ςτθν εςωτερικι δομι για να περαςτοφν από εκεί ςτο GPX αρχείο και ςτο.txt αρχείο ιςτορικοφ, τα οποία ςυνκζτονται κατά τθ διάρκεια που το πρόγραμμα λειτουργεί. Πταν κλείςουμε (OFF) τον απομακρυςμζνο κόμβο θ κατάςταςθ ςτο ςφςτθμά μασ ςτακεροποιείται, με τα leds να παραμζνουν ςτθν τελευταία κατάςταςθ που ιταν πριν τθ διακοπι και ςτθν οκόνθ του τερματικοφ να μθν απεικονίηονται καινοφρια πακζτα. Στθ ςυνζχεια αποςυνδζοντασ τον κόμβο βάςθ, δθμιουργοφμε ςφάλμα ςτθ διαδικαςία διαβάςματοσ που επιτελεί θ ςυνάρτθςθ ReadFile. Ππωσ φαίνεται και ςτθν παρακάτω εικόνα ζνα μινυμα για αναφορά του λάκουσ εμφανίηεται ςτθν οκόνθ μαηί με μια ςφντομθ καταγραφι για το πόςεσ προτάςεισ διαβάςτθκαν και πόςεσ από αυτζσ επεξεργάςτθκαν και Εικόνα: Σελικι κατάςταςθ προγράμματοσ USB_read ςτα πλαίςια λειτουργίασ του ςυςτιματόσ μασ αποκθκεφτθκαν (ζχει να κάνει με το όριο που κζςαμε ςτθν αρχι). Επίςθσ ενθμερωνόμαςτε για το ότι το GPX αρχείο μασ ολοκλθρϊκθκε. Το επόμενο βιμα είναι να δϊςουμε το αρχείο αυτό ςτο Google Earth TM και να δοφμε τθ κζςθ μασ ςτον χάρτθ. Η διαδικαςία που ακολουκοφμε είναι απλι. Ανοίγουμε τθν εφαρμογι 114

115 GE TM και πθγαίνουμε ςτο «Tools GPS». Εκεί ανοίγει ζνα menu για να κάνουμε import το GPX αρχείο μασ. Ρατάμε τθν επιλογι «Import from file» και μετά δίνουμε το αρχείο μασ που ζχει όνομα GPS_xml.gpx. Στθ ςυνζχεια θ εφαρμογι μασ πλοθγεί ςτο ςθμείο που υποδεικνφει το αρχείο που ειςαγάγαμε και βλζπουμε τθ κζςθ μασ ςτον χάρτθ. Η παρατθροφμενθ κζςθ αποκλίνει, ςε κάποιο βακμό, από τθν πραγματικι κζςθ του κόμβου που φζρει τον δζκτθ GPS. Αυτό όμωσ ιταν κάτι αναμενόμενο, όπωσ ζχουμε αναφζρει και ςτθν ςχετικι κεωρία. Η μείωςθ τθσ ακρίβειασ του ςυςτιματοσ και θ ειςαγωγι ςφαλμάτων από τθν πλευρά των διαχειριςτϊν του (Η.Ρ.Α.), λόγω τθσ ςτρατιωτικισ υπόςταςθσ του GPS, δικαιολογοφν εν μζρει τθν απόκλιςθ. Στθν πραγματικότθτα θ ακρίβεια του GPS επθρεάηεται από πολλοφσ παράγοντεσ ςυμπεριλαμβανομζνων των δορυφορικϊν κζςεων, του κορφβου ςτο αςφρματο κανάλι radio, των ατμοςφαιρικϊν ςυνκθκϊν κακϊσ και φυςικϊν εμποδίων μεταξφ δζκτθ και δορυφόρων. Ο κόρυβοσ μπορεί να δθμιουργιςει ςφάλμα από 1 ζωσ 10 μζτρα και είναι αποτζλεςμα παρεμβολϊν από ςυςκευζσ που δουλεφουν δίπλα ςτον δζκτθ ι άλλων που λειτουργοφν ςτθν ίδια ςυχνότθτα. Αντικείμενα όπωσ βουνά ι κτίρια μεταξφ του δορυφόρου και του δζκτθ μποροφν να παράγουν επίςθσ λάκοσ, μερικζσ φορζσ τθσ τάξθσ των 30 μζτρων. Η τοποκεςία ςτθν οποία ζγινε το πείραμα αυτό ιταν κοντά ςε βουνά και κτίρια. Ππωσ αναφζραμε και προθγουμζνωσ, ο καλφτεροσ προςδιοριςμόσ κζςθσ κα γίνει όταν ο δζκτθσ και ο δορυφόροσ ζχουν μια ξεκάκαρθ οπτικι ο ζνασ με τον άλλον χωρίσ να παρεμβαίνουν αντικείμενα ανάμεςα. Ρροφανϊσ όμωσ, τα βουνά και τα ςφννεφα δεν μποροφν να ελεγχκοφν ι να μετακινθκοφν αλλά και οι παρεμβολζσ από τα κτίρια δεν μποροφν πάντα να παραλειφκοφν. Για αυτό καταλιγουμε να ζχουμε αυτό το ςφάλμα ςτθ παρατθροφμενθ κζςθ. Συνικωσ, ζνα ςφάλμα τθσ τάξθσ των 11 με 15 μζτρων από τθν πραγματικι κζςθ, κεωρείται αποδεκτό. Εικόνα: Απεικόνιςθ τθσ κζςθσ μασ ςτθν εφαρμογι Google Earth TM ςφμφωνα με τα δεδομζνα του αρχείου GPS_xml.gpx που δθμιουργεί το πρόγραμμα USB_read. Με τθν κόκκινθ κουκίδα δθλϊνεται θ πραγματικι κζςθ του IRIS mote με το GPS module. Με το μπλε βελάκι δθλϊνεται θ κζςθ του κόμβου που υπολογίηεται από το ςφςτθμα. 115

116 Να ςθμειϊςουμε ςε αυτό το ςθμείο ότι το manual τθσ εταιρείασ ublox για το ολοκλθρωμζνο του δζκτθ GPS LEA-4A περιζχει ανακριβι δεδομζνα για το λεγόμενο cold start του δζκτθ. Ριο ςυγκεκριμζνα δίνεται ςαν μζγιςτθ τιμι χρόνου τα 41 δευτερόλεπτα για τθν εκκίνθςθ του, ενϊ εμείσ χρειαςτικαμε κάτι παραπάνω από ενάμιςθ λεπτό. Επίςθσ ο δζκτθσ αυτισ τθσ εταιρείασ παρουςίαηε πρόβλθμα ςτθν τιμι τθσ μεταβλθτισ για το υψόμετρο (altitude) θ οποία και μεταβαλλόταν ςυνεχϊσ με τον χρόνο χωρίσ να ςυγκλίνει κάπου. Το γεγονόσ αυτό μποροφμε να το παρατθριςουμε και ςτθν εικόνα, θ οποία απεικονίηει τθν οκόνθ του τερματικοφ κατά τθν εκτζλεςθ του προγράμματοσ USB_read, όπου για τισ τζςςερισ μετριςεισ που κατεγράφθςαν υπάρχουν και τζςςερισ διαφορετικζσ τιμζσ για το υψόμετρο (προτελευταίο πεδίο τθσ δομισ). Για αυτό το λόγο, ςτο GPX αρχείο δεν χρθςιμοποιιςαμε το altitude που μασ δίνει ο δζκτθσ GPS LEA 4A, αλλά κζςαμε μια ςτακερι τιμι (= 4.46) ςτο αντίςτοιχο πεδίο. 7.4 Παρακολοφκθςθ τθσ τροχιάσ ενόσ κινθτοφ (tracking) και καταγραφι τθσ για απεικόνιςθ ςτο Google Earth TM ςε offline mode Αυτι τθ φορά κα χρθςιμοποιιςουμε το πρόγραμμα USB_read για να κάνουμε ιχνθλάτθςθ τθσ τροχιάσ ενόσ κινθτοφ που είναι εξοπλιςμζνο με το ςφςτθμα που ςχεδιάςαμε. Επειδι, όπωσ ζχουμε αναφζρει ξανά και ςτθν αρχι τθσ εργαςίασ μασ, ο ςτόχοσ μασ δεν είναι θ υλοποίθςθ δρομολόγθςθσ ςε μια ςφνκετθ τοπολογία WSN, το δίκτυό μασ αποτελείται από 2 κόμβουσ IRIS. Για τθν εκτζλεςθ μιασ πορείασ με ζνα κινθτό (για παράδειγμα ζνα αυτοκίνθτο) πρζπει ο κόμβοσ που φζρει τον δζκτθ GPS να είναι εντόσ εμβζλειασ του radio του άλλου κόμβου που λειτουργεί ςαν ςτακμόσ βάςθσ. Η εμβζλεια των κόμβων IRIS ςφμφωνα με τισ προδιαγραφζσ τθσ καταςκευάςτριασ εταιρείασ Crossbow μπορεί να φτάςει μζχρι και 500 μζτρα ςε εξωτερικοφσ χϊρουσ, με τθν προχπόκεςθ οπτικισ επαφισ των κόμβων, και μζτρα για εςωτερικοφσ. Επομζνωσ θ παρακολοφκθςθ τθσ τροχιάσ κα γίνει με το κινθτό να ζχει πάνω του τουσ δφο κόμβουσ και το host PC. Στθ ςυγκεκριμζνθ φάςθ, μασ ενδιαφζρει ο ςωςτόσ εντοπιςμόσ κζςθσ των κόμβων (node localization) και όχι θ μελζτθ για routing. Εξοπλίηουμε, λοιπόν το κινθτό μασ με το ςφςτθμα, βάηοντασ τθν κεραία του GPS ςτθν οροφι για να μπορεί να βλζπει κακαρό ουρανό. Στθ ςυνζχεια ςυνδζουμε τον κόμβο βάςθ ςτο αναπτυξιακό MIB520 και το τοποκετοφμε ςε μια ςειριακι κφρα USB του υπολογιςτι. Τρζχουμε το πρόγραμμα USB_read και ενϊ είμαςτε ςε αναμονι για ειςερχόμενα πακζτα, ανοίγουμε τον κόμβο με τον δζκτθ GPS. Πταν αυτόσ ςυγχρονιςτεί τα πρϊτα πακζτα κάνουν τθν εμφάνιςι τουσ ςτθν οκόνθ του τερματικοφ. Μόλισ ο εςωτερικόσ μετρθτισ ξεπεράςει το όριο που ζχουμε κζςει για τα πρϊτα πακζτα που απορρίπτει (= 50 πακζτα), αρχίηει να γίνεται θ καταγραφι των δεδομζνων και να ςχθματίηονται τα αρχεία GPS_data_tour.gpx και GPSdatabase_tour.txt. Εκείνθ ακριβϊσ τθ ςτιγμι ξεκινάμε και τθν κίνθςι μασ με το κινθτό, ζχοντασ επιλζξει μια πορεία τθν οποία και εκτελοφμε. Κακ όλθ τθ διάρκεια τθσ κίνθςθσ ελζγχουμε αν όλα ςτο ςφςτθμα δουλεφουν ςωςτά 116

117 παρατθρϊντασ τόςο τθ ροι των πακζτων ςτθν οκόνθ του τερματικοφ, όςο και τθ «χορογραφία» των leds ςτουσ δφο κόμβουσ. Ολοκλθρϊνοντασ τθν πορεία που κζλαμε να ακολουκιςουμε, γυρίηουμε ςτο OFF τον κόμβο με τον δζκτθ GPS και αποςυνδζουμε το αναπτυξιακό από τθ ςειριακι κφρα USB προκαλϊντασ μια διακοπι I/O. Η διακοπι εντοπίηεται ςαν ςφάλμα ςτθν εκτζλεςθ τθσ ςυνάρτθςθσ ReadFile και το πρόγραμμα τερματίηει κλείνοντασ τθν ςφνδεςθ με τθ κφρα, ολοκλθρϊνοντασ το GPX αρχζιο και βγάηοντασ μινυμα ςτο τερματικό περιγράφοντασ ςυνοπτικά τι ζκανε. Στθ ςυνζχεια, ανοίγουμε τθν εφαρμογι Google Earth TM και κάνουμε import Εικόνα: Ζχοντασ εκτελζςει με το κινθτό μασ τθν πορεία που απεικονίηεται με κόκκινθ γραμμι, κάνουμε import ςτο Google EarthTM το.gpx αρχείο που δθμιοφργθςε το πρόγραμμά USB_read. Θ ιχνθλάτθςθ τθσ τροχιάσ του κινθτοφ, που εκτζλεςε το πρόγραμμά μασ, φαίνεται με τθν μπλε γραμμι. Θ μπλε τροχιά (παρατθροφμενθ) προκφπτει αυτόματα ςτο Google EarthTM με το import του αρχείου, το οποίο τθσ δίνει και το όνομα IRIS track. Θ κόκκινθ τροχιά (πραγματικι) επιςθμάνκθκε εκ των υςτζρων με επεξεργαςία τθσ εικόνασ για να είναι δυνατι μια άμεςθ ςφγκριςθ. το αρχείο GPS_data.gpx. Η εικόνα που παίρνουμε παρατίκεται παρακάτω. Ραρατθροφμε ότι τα προβλιματα που είχαμε και ςτον εντοπιςμό κζςθσ με το ίδιο πρόγραμμα παραμζνουν. Μια απόκλιςθ 15 περίπου μζτρων ςτα μζγιςτα ςθμεία απόκλιςθσ μεταξφ τθσ πραγματικισ και τθσ εκτιμοφμενθσ τροχιάσ είναι πάλι εμφανισ. Η απόκλιςθ ζχει μια ςυγκεκριμζνθ κατεφκυνςθ δίνοντασ τθν εντφπωςθ ότι όλθ θ τροχιά ζχει μετακινθκεί κάποια μζτρα βορειοδυτικά. Θα μποροφςαμε να ποφμε, κάνοντασ μια προςζγγιςθ, ότι ςε κάκε ςυντεταγμζνθ που λάβαμε υπάρχει μια ςτακερι τιμι ςφάλματοσ που οδιγθςε ςε αυτιν τθν «ομοιόμορφθ» μετακίνθςθ τθσ εκτιμοφμενθσ τροχιάσ. Ρρζπει να παρατθριςουμε επίςθσ, ότι ςε δφο ςθμεία ο δζκτθσ GPS μασ ζδωςε ςυντεταγμζνεσ πολφ διαφορετικζσ, ςε ςχζςθ με τισ πραγματικζσ, κάνοντασ αςυνεχι τθν μπλε γραμμι τθσ εκτιμϊμενθσ πορείασ. Αυτό μπορεί να οφείλεται ςε πολλοφσ αιτίεσ όπωσ ζνασ ςτιγμιαίοσ αποςυγχρονιςμόσ του δζκτθ, ο οποίοσ μετά από 2-3 περιόδουσ επανιλκε, ι λόγω εξωτερικϊν παραγόντων όπωσ για παράδειγμα θλεκτρομαγνθτικι παρεμβολι από άλλεσ ςυςκευζσ που λειτουργοφςαν ςτθν ίδια ςυχνότθτα ςε εκείνα τα ςθμεία. 117

118 7.5 Εντοπιςμόσ κζςθσ κόμβου με απεικόνιςθ ςε πραγματικό χρόνο ςτο Google Earth TM (online mode) Η χριςθ του προγράμματοσ FirstGEApp που αναπτφξαμε ςε C#, με τα χαρακτθριςτικά που αναφζραμε και αναλφςαμε ςτθν περιγραφι του ςτο προθγοφμενο κεφάλαιο, ζρχεται δϊςει λφςεισ ςτα ερωτθματικά που τίκενται μετά το πρϊτο πείραμα. Ριο ςυγκεκριμζνα, ακριβϊσ για να αντιμετωπιςτοφν τα προβλιματα που είχαμε με το πρϊτο πρόγραμμα, το FirstGEApp δίνει τθ δυνατότθτα: Εφαρμογισ μιασ λογικισ διαφορικοφ GPS (Differential GPS). Η λογικι αυτι υλοποιείται με τθν επιλογι «Calibrate» του μενοφ «Options». Το calibrate πραγματοποιείται με ζναν πολφ απλό τρόπο. Από τθ ςτιγμι που κα το επιλζξουμε, από τα επόμενα είκοςι πακζτα που κα λθφκοφν, βγάηουμε ζνα μζςο όρο για το γεωγραφικό μικοσ και το γεωγραφικό πλάτοσ. Αυτό το κάνουμε για να μθν βαςιςτοφμε, για το calibrate, μόνο ςτα δεδομζνα από το τελευταίο πακζτο, αυξάνοντασ ζτςι τθν αξιοπιςτία του όλου εγχειριματοσ. Στθ ςυνζχεια το πρόγραμμα ςταματάει προςωρινά να «ακολουκεί» τα δεδομζνα του GPS που ςυνεχίηουν να ζρχονται, και ηθτάει από τον χριςτθ να υποδείξει τθν πραγματικι του κζςθ πάνω ςτον χάρτθ. Με βάςθ τθν πραγματικι και τθν εκτιμϊμενθ κζςθ, που μασ δίνεται από το μζςο γεωγραφικό μικοσ και το μζςο γεωγραφικό πλάτοσ των είκοςι τελευταίων πακζτων, υπολογίηεται μια διαφορά (για κάκε διάςταςθ), που είναι και θ απόκλιςθ των δφο κζςεων. Αφαιρϊντασ αυτό το ςφάλμα από κάκε ςυντεταγμζνθ που ζρχεται ςτθ ςυνζχεια, διορκϊνουμε τα δεδομζνα μασ και τθν ακρίβεια απεικόνιςθσ τθσ κζςθσ μασ. Με αυτό τον τρόπο, με μια εφαρμογι του DGPS, το πρόγραμμά μασ καταφζρνει να αποβάλει τθ ςυνεχι και ςχεδόν ςτακερι εμφάνιςθ του ςφάλματοσ των μζτρων από τθν πραγματικι κατάςταςθ. Απόρριψθσ ςυντεταγμζνων που διαφζρουν αρκετά ςε ςχζςθ με τισ ακριβϊσ προθγοφμενεσ που ζλαβε. Ριο ςυγκεκριμζνα το πρόγραμμα κάκε ζνα δευτερόλεπτο διαβάηει δεδομζνα από τθ ςειριακι κφρα USB με τθν οποία και ζχει αποκαταςτιςει ςφνδεςθ. Η ςυνάρτθςθ gps_timer_tick υλοποιεί τθ ςυγκεκριμζνθ λειτουργία. Εκεί γίνεται και ο ζλεγχοσ που αναφζρουμε ςε αυτό το πλαίςιο. Το πρόγραμμα κάκε φορά κρατάει ςε εςωτερικοφσ buffers τισ επεξεργαςμζνεσ ςυντεταγμζνεσ, γεωγραφικό μικοσ και πλάτοσ, από το τελευταίο πακζτο που ζλαβε. Πταν δεχτεί τισ καινοφριεσ ςυντεταγμζνεσ, από ζνα νζο πακζτο, και αφοφ τισ επεξεργαςτεί για να ζρκουν ςτθ τελικι τουσ μορφι, τισ ςυγκρίνει με τισ προθγοφμενεσ κάνοντασ αφαίρεςθ των αντίςτοιχων μεγεκϊν. Αν θ διαφορά που κα προκφψει είναι μεγαλφτερθ από πζντε εκατοςτά τθσ μοίρασ (0.05 ο 5 Km), είτε ςτο γεωγραφικό μικοσ είτε ςτο γεωγραφικό πλάτοσ, οι νζεσ ςυντεταγμζνεσ απορρίπτονται κεωρϊντασ ςφάλμα μζτρθςθσ. Θεωρθτικά, επομζνωσ, το πρόγραμμά μασ αυτό αποβάλει και το άλλο ςφάλμα που παρατθρείται ςτθν εφαρμογι του πρϊτου πειράματοσ για τθν καταγραφι πορείασ, το οποίο ζχει ωσ 118

119 αποτζλεςμα μια αςυνζχεια ςτθν εκτιμϊμενθ πορεία του κινθτοφ, λόγω κάποιων μετριςεων «αιχμϊν» (spikes) που λαμβάνονται από το δζκτθ GPS. Με αυτά τα δφο βαςικά χαρακτθριςτικά που υλοποιιςαμε αλλά και με άλλουσ, πιο ςυγκεκριμζνουσ εςωτερικοφσ ελζγχουσ, που αναλφςαμε ςτθ περιγραφι του προγράμματοσ, χρθςιμοποιοφμε το πρόγραμμα FirstGEApp για να εκτελζςουμε το δεφτερο πείραμά μασ. Αυτι τθ φορά μάλιςτα κα ζχουμε live απεικόνιςθ τθσ κζςθσ ςτο Google Earth TM, γεγονόσ που μασ το επιτρζπει θ ςφνδεςθ, που κάναμε, του προγράμματοσ με τθ ςυγκεκριμζνθ εφαρμογι, ςτθν C#. Τθ δυνατότθτα αυτι δεν τθν είχαμε με τθ γλϊςςα C. Το δεφτερο πείραμα που κα εκτελζςουμε για τον εντοπιςμό τθσ κζςθσ του κόμβου, όςον αφορά ςτθν διαδικαςία εκτζλεςθσ, είναι το ίδιο με το πρϊτο. Η διαφορά είναι ότι αυτι τθ φορά κα χρθςιμοποιιςουμε το πρόγραμμα FirstGEApp για το διάβαςμα των ειςερχόμενων ςειριακϊν πακζτων από τθν USB. Τοποκετοφμε τον κόμβο με τον δζκτθ GPS ςτο ίδιο ςθμείο που ιταν και ςτο πρϊτο πείραμα για να πλθροφνται οι προχποκζςεισ που ςχολιάςαμε και τότε. Συνδζουμε τον κόμβο βάςθ ςτο αναπτυξιακό, το οποίο βάηουμε ςτθ ςειριακι κφρα του υπολογιςτι και ςτθ ςυνζχεια τρζχουμε το πρόγραμμά μασ. Η ζναρξθ του προγράμματοσ ςυνεπάγεται τθν άμεςθ εκκίνθςθ τθσ εφαρμογισ Google Earth TM και τθν εμφάνιςθ τθσ διεπαφισ χριςτθ (GUI) που ςχεδιάςαμε. Στο πλαίςιο του ιςτορικοφ (Log) βγαίνουν μθνφματα που μασ ενθμερϊνουν ότι το πρόγραμμα εκκίνθςε κανονικά και ότι θ εφαρμογι Google Earth TM φορτϊκθκε με επιτυχία. Κάνοντασ μια γριγορθ εξερεφνθςθ ςτα διακζςιμα μενοφ «Options» και «Opacity» παρατθροφμε αυτό ότι όντωσ θ προεπιλογι του προγράμματοσ είναι ςτο «Follow GPS». Τα πεδία του τμιματοσ Connection ζχουν κακοριςμζνεσ τισ τιμζσ που είχαμε και ςτο πρόγραμμα USB_read για το άνοιγμα τθσ ςειριακισ κφρασ, ενϊ οι μπάρεσ «Range» και «Camera Speed» είναι ςτισ τιμζσ που ζχουμε προκακορίςει. Στισ τελευταίεσ μποροφμε να επεμβαίνουμε κατά τθ διάρκεια του πειράματοσ, μεταβάλλοντασ τισ τιμζσ τουσ. Σε αυτό το ςθμείο είμαςτε ζτοιμοι να ξεκινιςουμε το πείραμα πατϊντασ το κουμπί «Start». Ρατϊντασ το «Start» κλειδϊνουν τα πεδία του τμιματοσ Connection για να μθν μποροφμε να τα αλλάξουμε ςτθ ςυνζχεια και το πρόγραμμα κολλιςει. Ραράλλθλα ενεργοποιείται θ ζνδειξθ «Connected» που δθλϊνει ότι αποκαταςτάκθκε με επιτυχία θ ςφνδεςθ με τθν κφρα COM5, γεγονόσ το οποίο αναφζρεται και ςτο ιςτορικό. Το πρόγραμμα πλζον είναι ςε κατάςταςθ αναμονισ για ειςερχόμενα πακζτα από το WSN. Το κουμπί «Start» μετά το πάτθμα του άλλαξε και ζγινε «Stop» όπωσ το είχαμε περιγράψει και ςτθν ανάλυςθ του κϊδικα του προγράμματοσ. Ανοίγουμε τον κόμβο με τον δζκτθ GPS και περιμζνουμε μζχρι να παρζλκει το χρονικό διάςτθμα για τον ςυγχρονιςμό του με τουσ δορυφόρουσ. Μόλισ γίνει αυτό και το πρόγραμμα αρχίςει να διαβάηει πακζτα βλζπουμε τθν κάμερα που μασ δείχνει τθν Γθ ςτο Google Earth TM να αρχίηει να κινείται πθγαίνοντάσ μασ ςταδιακά ςτο ςθμείο που προςδιορίηουν οι επεξεργαςμζνεσ ςυντεταγμζνεσ που λαμβάνονται για τθν κζςθ του κόμβου. Κάκε μετακίνθςθ που κάνει θ κάμερα, και αυτό ςυμβαίνει κάκε δευτερόλεπτο οπότε και ζνα νζο ςετ ςυντεταγμζνων λαμβάνεται ςε ζνα νζο πακζτο, δθλϊνεται ςτο ιςτορικό όπου καταγράφεται το γεωγραφικό μικοσ και πλάτοσ. Πςο διαρκεί θ διαδικαςία του διαβάςματοσ από τθ κφρα USB μζνει αναμμζνθ και θ φωτεινι ζνδειξθ «Receiving» ςτο GUI. Μετά τθ λιψθ οριςμζνων 119

120 πακζτων θ κάμερα τθσ εφαρμογισ πλζον δείχνει τθν περιοχι που βρίςκεται ο κόμβοσ με ζνα εφροσ κζαςθσ όςο το επιλεγμζνο ςτθ μπάρα «Range». Το πρόγραμμα αυτό δεν αφινει ίχνοσ για τθ κζςθ που εντόπιςε γιατί θ διαδικαςία γίνεται τϊρα ςε πραγματικό χρόνο. Η κζςθ του κόμβου με τον δζκτθ GPS είναι το κζντρο τθσ εικόνασ τθσ περιοχισ που βλζπουμε όταν ςτακεροποιείται θ κάμερα. Η εκτιμϊμενθ κζςθ αυτι υποφζρει ακόμα από το πρόβλθμα τθσ απόκλιςθσ με τθν πραγματικι κατά περίπου 15 μζτρα. Για να το διορκϊςουμε αυτό πθγαίνουμε ςτο «Options Calibrate». Ρατϊντασ εκεί, βγαίνει ζνα αναδυόμενο παράκυρο που περιζχει οδθγίεσ για το τι πρζπει να κάνουμε. Ρατάμε ΟΚ και περιμζνουμε, χωρίσ να επεμβαίνουμε ςτθν διεπαφι, μζχρι να ολοκλθρωκεί θ λιψθ είκοςι πακζτων για τον υπολογιςμό του μζςου γεωγραφικοφ πλάτουσ και του μζςου γεωγραφικοφ μικουσ. Οι ενζργειεσ που γίνονται γνωςτοποιοφνται ςτο χριςτθ με μθνφματα ςτο ιςτορικό για να μπορεί να παρακολουκεί τισ εςωτερικζσ διαδικαςίεσ που εκτελεί το πρόγραμμα. Αφοφ πατιςουμε ΟΚ, βγαίνει ζνα νζο αναδυόμενο μινυμα που ενθμερϊνει τον χριςτθ να πατιςει εκ νζου ΟΚ όταν εμφανιςτεί ςτο ιςτορικό θ αναφορά για τθν ολοκλιρωςθ του υπολογιςμοφ των μζςων εκτιμιςεων για τισ ςυντεταγμζνεσ. Στθ ςυνζχεια, πατάμε πάλι το κουμπί ΟΚ, όπωσ ορίηουν οι οδθγίεσ και τϊρα μασ ηθτείται να εςτιάςουμε τθ κάμερα του GE TM ςτθ πραγματικι κζςθ που βρίςκεται ο κόμβοσ. Αφοφ εςτιάςουμε, πατάμε ΟΚ. Η ενζργειά μασ αυτι ςθματοδοτεί ςτο πρόγραμμα τον υπολογιςμό του ςφάλματοσ που περιείχαν οι μζχρι τϊρα ςυντεταγμζνεσ. Η αποκλίςεισ για το γεωγραφικό πλάτοσ και το γεωγραφικό μικοσ αναφζρονται ςτο ιςτορικό. Ραρατθροφμε ότι είναι αρκετά μικροί αρικμοί. Μθν ξεχνάμε ότι χρθςιμοποιοφμε μορφι δεκαδικϊν μοιρϊν. Επομζνωσ αυτοί οι αρικμοί που βλζπουμε ςτο ιςτορικό αντιπροςωπεφουν κάποια μζτρα. Η εικόνα από τθν διεπαφι χριςτθ, τθ ςυγκεκριμζνθ αυτι ςτιγμι του πειράματοσ, δίνεται ςτθν εικόνα που ακολουκεί. Ραρατθροφμε ότι το ςφάλμα που Εικόνα: τιγμιότυπου τθσ διεπαφισ χριςτθ αμζςωσ μετά τθν εφαρμογι του Calibration 120

121 είχαμε ςτο γεωγραφικό πλάτοσ (latitude) είναι τιμι αρκετά μικρι. Το αντίςτοιχο ςφάλμα για το γεωγραφικό μικοσ (longitude) είναι που όπωσ κα δοφμε είναι μια τιμι αρκετά υπολογίςιμθ. Για να καταλάβουμε τθν τάξθ μεγεκϊν ανάμεςα ςε δεκαδικζσ μοίρεσ και απόςταςθ ςε μζτρα κάνουμε τθν ακόλουκθ ςκζψθ. Στον ιςθμερινό θ ακτίνα τθσ Γθσ είναι 6,378,160 μζτρα με αποτζλεςμα να δίνει μια περιφζρεια ςτθ Γθ περίπου 40,075,161.2 μζτρα. Ο ιςθμερινόσ χωρίηεται ςε 360 μοίρεσ γεωγραφικοφ μικουσ, ζτςι κάκε μοίρα ςτον ιςθμερινό αντιπροςωπεφει 111,319.9 μζτρα ι περίπου 111 χιλιόμετρα. Ππωσ ζχουμε αναφζρει και ςτο κομμάτι τθσ κεωρίασ, ωςτόςο, όςο κάποιοσ κινείται προσ τουσ πόλουσ από τον ιςθμερινό, θ τιμι αυτι των μζτρων μειϊνεται και ςτουσ πόλουσ γίνεται ςχεδόν μθδζν. Σε αντίκεςθ με το τι ςυμβαίνει για το γεωγραφικό μικοσ, τα δεδομζνα για τθν ακρίβεια των δεκαδικϊν ψθφίων του γεωγραφικοφ πλάτουσ είναι πιο ςτακερά και δεν εξαρτϊνται από τθ κζςθ κάκε φορά. Ζτςι, για το γεωγραφικό πλάτοσ και για το γεωγραφικό μικοσ, αλλά μόνο για περιοχζσ κοντά ςτον ιςθμερινό όςον αφορά ςτο τελευταίο, μποροφμε να κάνουμε μια προςζγγιςθ για τθν ακρίβεια που δίνουν ςε μζτρα τα δεκαδικά ψθφία των μοιρϊν ςφμφωνα με τον ακόλουκο πίνακα. Ζτςι, το ςφάλμα, ςτο γεωγραφικό μικοσ ςε μζτρα προκφπτει περίπου 20 μζτρα, ενϊ ςτο γεωγραφικό πλάτοσ λιγότερο από 1 μζτρο (= 0,8 μ). Οι τιμζσ αυτζσ είναι προςεγγιςτικζσ μιασ και δεν βριςκόμαςτε ςτον ιςθμερινό, και χρθςιμοποιοφνται για να γίνει καλφτερα αντιλθπτι θ διόρκωςθ που επιτελείται. Στθν πραγματικότθτα, επειδι θ κζςθ μασ είναι μετακινθμζνθ προσ τον πόλο, οι τιμι του ςφάλματοσ του γεωγραφικοφ μικουσ κα είναι λίγο μικρότερθ. Εικόνα: Ακρίβεια Vs Δεκαδικζσ μοίρεσ Κλείνοντασ τθν παραπάνω παρζνκεςθ, ςυνεχίηουμε με το πείραμά μασ και τθ διαδικαςία του calibration. Για να γίνει ςωςτά θ εςτίαςθ τθσ κάμερασ ςτο πραγματικό μζροσ που είναι τοποκετθμζνοσ ο κόμβοσ, το πρόγραμμα είχε προθγουμζνωσ απενεργοποιιςει τθν επιλογι «Follow GPS». Για να τθν ενεργοποιιςουμε πάλι και να δοφμε αν όντοσ διορκϊκθκε θ εκτιμϊμενθ κζςθ πθγαίνουμε ςτο «Options Follow GPS» και αμζςωσ αρχίηει πάλι θ διαδικαςία ανάγνωςθσ πακζτων από τθν κφρα USB. Αυτι τθ φορά όμωσ, τα δεδομζνα των ςυντεταγμζνων επεξεργάηονται και διορκϊνονται αφαιρϊντασ τθν αντίςτοιχθ απόκλιςθ που υπολογίςτθκε από τθν κάκε διάςταςθ. Τα δεδομζνα τθσ κζςθσ αναφζρονται πάλι ςτο ιςτορικό και θ εικόνα που παίρνουμε ζχει επιςυναφτεί παρακάτω. Μποροφμε εφκολα να διαπιςτϊςουμε ότι θ νζα κζςθ που μασ δείχνει πλζον το ςφςτθμα ωσ κζςθ του κόμβου είναι ςχεδόν ταυτόςθμθ με τθν πραγματικι κζςθ του. Αν το μάτι μασ δε μπορεί να διακρίνει τθ διαφορά ςτθν εςτίαςθ ςε ςχζςθ 121