System Introspection for System Analysis on Mobile Devices

More documents

Recommendations

Info

LogThread - the Logging CycleA LogThread represents a single logging cycle <strong>for</strong> one client. A LogThreadextends the Thread class to allow the execution of multiple logging cyclesin parallel. Components to be logged are added as LogClass elements toa map by using the LogClassInterface. On initialization the LogThreadcreates a new XML document. Every cycle a new element is created and attachedto the XML document containing the current timestamp of the probe.This element is called TimestampElement and used as container <strong>for</strong> the currentdata of the logged components. The LogThread iterates over the mapof LogClass elements and reads the data of each LogClass by calling thereadData() method. The result of the method is added as child to the currentTimestampElement.For backup reason a LogThread saves the current XML document to a temporaryfile at a given frequency defined in the configuration file. The temporaryfile is unique <strong>for</strong> each cycle and is used to backup the logged data in caseof an error occurring on runtime. When the LogThread is interrupt by theLogDispatcher, the XML document is saved to a final file on the file systemof the probe. Each file gets a unique name containing the creation timestampand is saved in a separate folder unique <strong>for</strong> each client.LogClassInterface - How to Read the DataThe LogClassInterface is created <strong>for</strong> concrete implementations of loggingclasses. It is used to read and collect data from the ComponentHolder. Thecollected data is placed inside a new XML element and can be accessed by thereadData() method. The idea behind single logging classes is to support extensionof logging cycles. To create new logging classes the LogClassInterfacemust be implemented and the class itself added to the XML configuration file.Once added the component is automatically offered by the LogDispatcher onrequest by the client.6.3 Implemented Components of the RobotDue to the limited time <strong>for</strong> implementing the system only seven componentsof the used robot plat<strong>for</strong>m have been implemented as component thread. Implementedsensors are the laser sensor, SLAM sensor, person sensor, speechsensor and a camera sensor <strong>for</strong> an USB camera. Implemented actuators arecontrolling the navigation and the speech component of the robot.41
The selected sensors give a good impression the data collected on differenttasks the robot can per<strong>for</strong>m. Laser and SLAM sensors are used <strong>for</strong> navigation,person and speech sensor represent in<strong>for</strong>mation needed <strong>for</strong> human-machineinteraction.The USB camera was used <strong>for</strong> testing the capability of sendingbigger payloads by using higher frequencies. Laser and SLAM sensors providetheir data as arrays of numbers and some additionally in<strong>for</strong>mation about therobot position. To filter this data the different arrays have been translated toa visual presentation as image. The additional data, like the position of therobot, is added to each images. XMPP does not support binary attachment.In order to still send the image, each image is decoded to a string by usingbase64 2 and then attached to a new message. On the client side the stringis encoded with base64 back to an image. Base64 allows to translate a bytearray to a string and vice versa. The same principle has been used <strong>for</strong> sendingimages captured by the USB camera. The data of the person sensor and thespeech sensor is provided as string containing in<strong>for</strong>mation about spoken wordsor angle of leg pairs from persons standing in front of the robot. This data isadded as normal String-pair to a message.Each implemented component thread controlling an actuator can receive specificcommands which are <strong>for</strong>warded to the robot via the component holder.The component thread <strong>for</strong> the navigation actuator can receive X/Y coordinates<strong>for</strong> navigation or direct commands like “manual_stop“. The componentthread communicating with the speech actuator parses the sentence to be spokenand calls the corresponding function on the speech actuator by using thecomponent holder.6.4 ClientThe design <strong>for</strong> the client described in chapter 5.3 has been implemented on thethe android operation system and on a common computer. To display the dataof the component threads a tabbed navigation system is implemented in bothclients presenting data inside tab views. Although the views presented can besimilar implemented, the system in the background <strong>for</strong> controlling the viewsis different <strong>for</strong> the clients. On mobile devices the resources are very limitedcompared to the common computer. At the time of this thesis a mobile deviceis not capable of using multi-cores <strong>for</strong> threading. On the common computermore resources are available which allows to use more resources and displaymore views at once. For example two views presenting the laser data and thenavigation planing can be combined inside one view. The following sectiongives an introduction of the implementation on both systems.2 http://www.webcitation.org/5x3gUQW3U - Base64 (RFC 4648)42
Page 1: Bringing System <s
Page 5 and 6: AbstractSystem <st
Page 7 and 8: output, so each component is offeri
Page 9 and 10: of the system and the decisions mad
Page 11 and 12: created a telelaboratory where two
Page 13 and 14: Like the telelaboratory there is a
Page 15 and 16: with a very high frequency which ma
Page 17 and 18: Due to improving technology the use
Page 19 and 20: Figure 4.1: ToBI platfor</s
Page 21 and 22: Figure 4.3: The architecture behind
Page 23 and 24: Figure 4.5: Typical instant messagi
Page 25 and 26: 5 System DesignThe
Page 27 and 28: Figure 5.2: Message exchange betwee
Page 29 and 30: Figure 5.4: Beacon running between
Page 31 and 32: Figure 5.5: Reading and processing
Page 33 and 34: data and only forw
Page 35 and 36: For example a developer can select
Page 37 and 38: Figure 5.13: Principle of tabbed na
Page 39 and 40: 6.1 The Communication InterfaceThe
Page 41 and 42: 6.2 The Probe - Implementation of t
Page 43 and 44: stop all active processes of the co
Page 45: is received containing the TAG of t
Page 49 and 50: 1 2 4 6 8 Listing 6.2: Example of t
Page 51 and 52: TabConfig - The Status ViewThe TabC
Page 53 and 54: Each view adds a listener to the co
Page 55 and 56: LoginController which also observes
Page 57 and 58: tends the JPanel class. The templat
Page 59 and 60: 7 EvaluationIn the previous chapter
Page 61 and 62: Name Description CharactersSingleli
Page 63 and 64: Figure 7.1: Latency of receiving da
Page 65 and 66: For this thesis only a rough estima
Page 67 and 68: Laptop CPU load without Probe CPU l
Page 69 and 70: 8 ConclusionsIn the context of this
Page 71 and 72: 9 OutlookGiven this new tool its no
Page 74: BibliographyBurrell, A. and A. Soda
Page 77 and 78: 6.10 Main classes of the Java clien
Page 79 and 80: AppendixUse CasesUse Case 1: Connec
Page 81 and 82: Use Case 4: Disconnect from compone
Page 83 and 84: Use Case 9: Sending beacon to keep
Page 85 and 86: Figure 9.4: Latency of receiving da

System Introspection for System Analysis on Mobile Devices

Create successful ePaper yourself

Delete template?

Save as template?