MATLAB-to-ROCI Interface. Member(s): Andy Chen Faculty Advisor: Camillo J. Taylor

Transcription

1 MATLAB-to-ROCI Interface Member(s): Andy Chen Faculty Advisor: Camillo J. Taylor Abstract The Remote Objects Control Interface, or ROCI, is a framework used within the University of Pennsylvania s GRASP Laboratory to manipulate a network of distributed sensory nodes. The objective of this project is to build interfaces for querying and controlling these nodes, and thusly the network that they compose. In particular, the goal is to bridge the MATLAB environment to ROCI. The end result is an API of primitive operations on ROCI nodes for use within the MATLAB environment (e.g. on an interactive console or in script files). These operations then will serve as the basic building blocks for implementing higher-level programs to interact with the ROCI network. Related Work The applications that result from this project build on top of the ROCI framework developed within the GRASP Laboratory at the University of Pennsylvania. ROCI enables the manipulation of a network of distributed sensory nodes. Each node executes a ROCI operating system kernel that is capable of running on existing network types, such as Ethernet and wireless LAN; the host machines on the network that run the kernel form a ROCI sensory network. Nodes can be dynamically added to a ROCI network during runtime; the new node broadcasts its arrival to other nodes already on the network, and each node then updates its list of known peer nodes. The nodes in a ROCI network gather sensory information from the environment, and this collection of information from all nodes forms a distributed database. Information input and output to a node occurs through ROCI modules; the ROCI architecture defines a framework for developing reusable, self-describing modules. The modules can be used to build larger Task modules by interconnecting module interfaces, where the Task (i.e. the module connections) is defined by an XML document. Modules interface with other modules through ROCI Pins. The Pins are self- Page 1 of 10

2 describing and strongly typed; e.g. an input Pin can only be connected to an output Pin of compatible type. Examples of Pin types include those for data such as GPS, internal or external temperature, video, and motor control. The MATLAB-to-ROCI interface addresses one limitation of the ROCI architecture; namely, a framework does not exist to interface with ROCI nodes through MATLAB. A MATLAB interface is desired for several reasons. First, the MATLAB language is simple in that developers can quickly code and deploy client applications, as in scripting programming languages. Also, MATLAB has an interactive console, which would enable users to interface with ROCI nodes in real-time. Second, MATLAB is a familiar tool already commonly used within some research projects involving large volumes of data. Third, MATLAB has several built-in features and add-on toolboxes for data processing, which users can utilize to analyze the results of queries on the ROCI network. The MATLAB-to-ROCI interface is not a modification of the existing implementation of the ROCI architecture. Rather, it is built on top of ROCI, and serves as a tool to enhance interactions with ROCI systems and the data that they produce. Page 2 of 10

3 Technical Approach Overview The MATLAB-to-ROCI interface is a collection of classes and functions written in the MATLAB programming language. This MATLAB-to-ROCI API provides basic operations, which ultimately will be used to build larger, more complex applications for high-level interactions with a ROCI network. The implementation of the API mainly involves utilizing the existing interfaces of the ROCI kernel and processing XML data. Communicating with ROCI In the existing ROCI architecture, each machine that is executing a ROCI kernel is capable of handling HTTP requests; the kernel listens for requests on port Prior to the MATLAB-to-ROCI interface, this feature was primarily used to support an AJAX-based web browser interface, which similarly, enables a user to query and control the state of a ROCI node. Acting as a HTTP server, the kernel serves XML documents that describe the state of the ROCI node, such as meta-information about each of the currently running tasks, its data pins, and the data acquired by sensors. Each document can be located through a URL that follows a pattern specific to the type of data content. For example, the URL to locate the XML document describing a task module running on a ROCI node has the pattern: name]:2010/[task name] (The domain name is the domain or IP address of the machine running the ROCI kernel, i.e. the ROCI node, of interest) Similarly, the pattern to locate a ROCI module of a running task is: name]:2010/[task name]/[module name] It is through HTTP that the MATLAB-to-ROCI API communicates with the ROCI kernel. For instance, many of the functions rely on the MATLAB function xmlread, which retrieves an XML DOM object at a specified file path or a specified URL. In the case of the latter, the xmlread function ultimately sends a HTTP GET request to the HTTP server (i.e. the ROCI node), similar to the web browser in the AJAX interface. After the document has been downloaded and encapsulated into the DOM object, the MATLAB function traverses the XML tree and encapsulates the data of interest into either a Page 3 of 10

4 MATLAB built-in data type or one of the data types provided in the MATLABto-ROCI interface the latter is discussed in more detail within the section Object Encapsulation. The ROCI kernel also supports handling of HTTP POST requests. These requests enable users to modify the state of the ROCI node, such as starting or ending ROCI tasks, and writing data to a ROCI pin. The content type of the HTTP POST requests in ROCI is primarily XML text. However, MATLAB does not provide a suitable analogue to xmlread for sending XML data to a specified URL. So, a low-level solution was applied, where the HTTP POST request was manually built and sent directly on a java.net.socket object attached to the URL of interest. The diagram below summarizes the communications between MATLAB and the ROCI kernel through the MATLAB-to-ROCI interface: MATLAB Environment MATLAB data structure MATLAB to ROCI API Process XML XML HTTP GET HTTP POST url1 url2 port 2010 ROCI Kernel XML Since ROCI is in continual development, there isn t formal documentation on the schema of the XML documents in ROCI. However, in implementing the MATLAB-to-ROCI API, the structures of the XML documents were inferred from informal sources, such as the XSLT style-sheets and JavaScript functions in the AJAX interface. Often the XML structures were fairly simple, and so, examining instances of the XML documents provided sufficient insight into the general structure. Page 4 of 10

5 Object Encapsulation The MATLAB-to-ROCI API is implemented in an object-oriented fashion. The outline below lists the important objects (the items in bold) and their compositions: v Node List of Peers Node List of Available Tasks Task Descriptor List of Running Tasks Task List of Modules Module List of Pins Pin Pin Data Control Parameters These objects are modeled in corresponding MATLAB data structure classes, with appropriate functions to retrieve the objects for its subcomponents. The subcomponent objects themselves are not stored within its parent object at all times, but rather, they are constructed at each invocation of the retrieval function in the parent object. The aim of this design is to restrict transmitting and processing XML documents to an as-needed basis, to avoid parsing documents that are not of interest. For example, a user may be interested in only one of the running tasks, so it doesn t make sense to encapsulate all running tasks into objects; i.e. it doesn t make sense to retrieve and parse the XML documents for all running tasks when the one document for the task of interest would suffice. This may minimize the delay experienced by a user while interacting with ROCI on the MATLAB console, especially if communicating across a low-bandwidth network. Each of the objects stores only enough information to locate the XML documents related to the ROCI component it is modeling and to locate the XML documents of its subcomponents. In this case, a base URL is sufficient. The structure of the URLs to locate each of the objects parallels the nesting structure of the outline above. For example: Object Base URL Node Task Module Page 5 of 10

6 Pin Pin Data As the table shows, the base URL of an object becomes the prefix of its subcomponent s URL i.e. the URL directory-like path structure parallels the nesting of the object composition structure in the outline. In essence, each object is an encapsulation of data from a collection of XML documents. Parsing and translating the XML documents is straight-forward for most of the objects, as the XML structure (e.g. nesting of elements and tag names) remains fixed across nodes. The exception to this occurs in encapsulating the pin data object; since each pin has a type property, the contents of the pin data is dependent on the pin s type. For the XML encoding of the pin data, the pin type specifies the element tag names and the nesting structure. So, there is no static structure that is uniform across pin data XML documents from pins of different types. However, it is preferred to encapsulate the pin data in a MATLAB data structure that retains the same nesting structure as in the XML, as it may be the most natural way of modeling the data for the user. Since the MATLAB language supports dynamically adding new field names to struct objects, the pin data XML can be translated into an analogous MATLAB data structure. In the API, the pin data object is built by recursively adding each XML element in the pin data as a field, using the tag name as the field name. In addition, since the pin data XML also identifies the type of its text nodes (which correspond to the scalar values in the pin data), a recognized type (e.g. integer, float, Boolean, image, etc.) is stored as its equivalent primitive data type in MATLAB. Query/Modify State of ROCI Kernel (Examples) Querying the state of a ROCI kernel consists of retrieving one of the objects discussed in the previous section, and then invoking the proper function belonging to object s class. Often, this involves starting from the Node object at the top of the object composition outline, and then traversing down the subcomponent tree until the proper component has been obtained. The following is an example of this interaction on the MATLAB console: >> % Construct node object with domain localhost >> node = RociNode('localhost') node = ROCINode@localhost Page 6 of 10

7 >> % Retrieve task objects of node >> tasks = getrunningtasks(node) tasks = [ROCINode@localhost]:CommunicationTestProducer [ROCINode@localhost]:HelloWorld [ROCINode@localhost]:Browser >> % Retrieve module objects of HelloWorld task >> helloworldmodules = getmodules(tasks(2)) helloworldmodules = [ROCINode@localhost]:HelloWorld.HelloWorld >> % Retrieve pins of module HelloWorld >> helloworldpins = getpins(helloworldmodules(1)) helloworldpins = chenbox64.helloworld.helloworld.mylogpin chenbox64.helloworld.helloworld.myalertpin >> % Retrieve data from MyLogPin pin >> pindata = readdata(helloworldpins(1)) Time: '4/11/ :59:45 PM' Message: 'Hello World!' Priority: 'NOTICE' Some objects also possess functions that modify the state of the ROCI kernel. For example, the node object contains an inject operation which starts the execution of a task. The task objects themselves have operations to suspend, resume, or terminate (kill) its execution. The behavior of the modules can be modified by altering the control parameters or sending pin data onto one of its pins. All of these operations are implemented using HTTP POST requests, as described in the section Communicating with ROCI. The following is an example of modifying a control parameter in the HelloWorld module in the previous example: >> params = getcontrolparams(helloworldmodules(1)) params = Message: 'Hello World!' Page 7 of 10

8 >> params.message = 'Good Bye World' params = Message: 'Good Bye World' >> setcontrolparams(helloworldmodules(1), params); >> pindata = readdata(helloworldpins(1)) Time: '4/11/2006 1:34:20 PM' Message: 'Good Bye World' Priority: 'NOTICE' Page 8 of 10

9 Conclusion The MATLAB-to-ROCI interface did not break new ground by contributing to research or innovation. As stated earlier, the interface was intended to be a new tool to enhance interactions with ROCI networks. Though the interface was initially envisioned to be a much higher-level query API (e.g. involving AI searching and discovery), it became apparent that an API of basic operations would be more useful and flexible in building the applications specific to the varying kinds of ROCI networks. In regards to implementation, experimental design was not a factor while working on this project, and much of the technical difficulty arose while becoming familiar with the MATLAB language and environment, and the ROCI architecture. Since ROCI is in continual development, the MATLAB-to- ROCI interface is expected to continue to be developed and modified alongside the ROCI architecture. Page 9 of 10

10 References Cowley, A., Hsu, H., and Taylor, C.J. Distributed Sensor Databases for Multi-Robot Teams, Proceedings of the 2004 IEEE Conference on Robotics and Automation (ICRA), New Orleans - LA, USA, April Cowley, A., Hsu, H., and Taylor, C.J. Software Design for Distributed Sensing and Computing Tasks, Proceedings of SPIE Vol Mobile Robots XVII, 2004, pages MATLAB 7.1. (2005). [Computer software]. The MathWorks, Inc. Page 10 of 10