Requirements to UPnP for Robot Middleware - Semantic Scholar

Proceedings of the 2006 IEEE/RSJ International Conference on Intelligent Robots and Systems October 9 - 15, 2006, Beijing, China

Requirements to UPnP for Robot Middleware Sang Chul Ahn, Jung-Woo Lee, Ki-Woong Lim, Heedong Ko, Yong-Moo Kwon, and Hyoung-Gon Kim Imaging Media Research Center Korea Institute of Science and Technology(KIST) Seoul, Korea {asc, ricow, lkw, ko, ymk, hgk}@imrc.kist.re.kr Abstract – The UPnP (Universal Plug and Play) defines an architecture for pervasive peer-to-peer network connectivity of intelligent appliances. It shares the service oriented architecture with emerging Web Service technology, and has many advantages for future robot middleware such as automatic discovery of services and accommodation of dynamic distributed computing environment. However, the UPnP needs some additional features for being used as a robot middleware. This paper discusses them, and presents some requirements when developing a UPnP SDK for robot middleware as well. This paper also presents an experimental result of applying the UPnP to robot components.

work together over networks. It is based on object oriented programming model. On the other hand, as the internet is widely spread, computing environment is changing to be dynamic, where computing devices can join and leave the network dynamically. Thus, middlewares are being developed to accommodate this environment. Jini[6], .Net[7] and UPnP[8] are such middlewares for accommodating ‘dynamic’ distributed computing environment. This paper considers the possibility of using the UPnP (Universal Plug and Play) as a robot middleware. The UPnP defines an architecture for pervasive peer-to-peer network connectivity of intelligent appliances. It shares the service oriented architecture with emerging Web Service technology[9], and has many advantages such as automatic discovery of services. Additionally, robot will be an appliance like TV’s and refrigerators in the future. And, it will have to dynamically join and communicate with home and office networks. In other words, a robot will have to communicate with external dynamic distributed computing environment. So, the UPnP has advantage for this if it is used as robot middleware. However, the UPnP needs some additional features for being used as a robot middleware. This paper discusses them. In order to include the additional features, we are developing an SDK for UPnP based robot middleware. The paper also presents some requirements when we develop the SDK for UPnP based robot middleware in contrast to existing UPnP SDK’s. Lastly, this paper presents an experimental result of applying the UPnP to real robot components.

Index Terms – Robot, Middleware, UPnP, SOA, Web Service.

I. INTRODUCTION Recently robot technology seems to be one of the most rapidly advancing technologies. In addition to industrial robots, animal-shaped robots and two-legged humanoid robots have been developed by companies and research institutes. Accordingly robots are expanding their application area from industry to entertainments and services at home. The Roomba of iRobot[1] is a robot that works as an automatic vacuum cleaner. It is reported that iRobot has been shipped more than 1 million Roombas[2]. The AIBO of Sony[3] and NeCoRo of Omron[4] are animal-shaped robots that have capability of giving fun and comfort to people by interacting and communicating with people. As robots are used to various applications, it requires that robots have more functionalities than ever before. In turn, this makes robot systems to be more and more complicated. Thus, development of a robot is not trivial any more. It needs more systematic development and integration methodology. Middleware is at the core of systematic development and integration methodology, and it has become one of the key components for robot development. Middleware is located between hardware and software. It reduces the complexity of developing applications that span multiple operating systems and network protocols by insulating the application developer from the details of the various operating system and network interfaces. It also increases the interoperability, portability, and flexibility of an application by allowing the application to be distributed over the network. The most commonly used middleware in robot development is CORBA (Common Object Request Broker Architecture)[5]. The CORBA is an open, vendor-independent middleware architecture that enables various applications to

1-4244-0259-X/06/$20.00 ©2006 IEEE

II. UPNP (UNIVERSAL PLUG AND PLAY) The UPnP(Universal Plug and Play) architecture offers pervasive peer-to-peer network connectivity of PCs, intelligent appliances, and wireless devices. The UPnP architecture is a distributed, open networking architecture that leverages TCP/IP and the Web to enable seamless proximity networking in addition to control and data transfer among networked devices[8]. It was originally developed by Microsoft, and now is being upgraded by UPnP forum. The UPnP forum defines and publishes UPnP device and service control protocols built upon open, Internet-based communication standards. The UPnP forum is supported by more than 760 companies. The major companies such as Microsoft, Intel, HP, Sony, and Samsung Electronics lead the forum as the steering committee members.

4716

The UPnP architecture defines a base set of standards and conventions for describing devices and the services they provide. It is designed to bring easy-to-use, flexible, standards-based connectivity to ad-hoc or unmanaged networks. It provides the service oriented architecture, which is the base of emerging Web service technology as well. It uses standard protocols and web technologies such as TCP/IP, UDP, SSDP, SOAP, GENA, HTTP and XML. The main components of the UPnP architecture are Devices, Control Points, and Services. A UPnP Device is an entity that provides Services. A Control point is a service requester. A Service is a unit of functionality implemented by a Device. A UPnP Device can contain zero or more Services. Fig. 1 shows a basic relation among Device, Control Point, and Service. The UPnP networking is accomplished through 6 steps: Addressing, Discovery, Description, Control, Eventing, and Presentation. Table I explains the 6 steps of the UPnP networking.

interoperability framework of the DLNA is one of the strongest candidates of the future home and office networking framework. TABLE II FUNCTIONAL COMPONENTS AND TECHNOLOGY INGREDIENTS FOR DLNA INTEROPERABILITY GUIDELINES Functional Components

Technology Ingredients

Networking and Connectivity

IP, Wired and Wireless Ethernet Media, and QoS Mechanism

Device and Service Discovery and UPnP V1 Architecture and Technology Control Media Formats and Streaming Protocols

Media Format and Transport Model

Media Management, Distribution, and Control

UPnP AV v1.0

Authentication and Authorization

UPnP and other IP based security mechanisms

III. REQUIREMENTS TO UPNP FOR ROBOT MIDDLEWARE

Fig. 1 Basic relation among Device, Control Point, and Service. TABLE I THE UPNP NETWORKING STEPS Steps

Description

Addressing

Control point and device get addresses

Discovery

Control point finds interesting device

Description

Control point learns about device capabilities

Control

Control point invokes actions on device

Eventing

Control point listens to state changes of device

Presentation

Control point controls device or views device status using HTML UI

On the other hand, the UPnP is also adopted as the base protocol of device discovery and control in the home networked device interoperability architecture of the DLNA(Digital Living Network Alliance)[10]. The DLNA is a consortium of CE(Consumer Electronics), mobile, and PC companies, which is formerly called DHWG (Digital Home Working Group). The DLNA is working on delivering an interoperability framework among digital appliances on the home network, such as digital TVs, digital set-top boxes, mobile phones, PDAs, and PCs. Table II shows the functional components and the technology ingredients for DLNA interoperability guidelines. It can be seen that it is based on IP networking and UPnP technology. The DLNA is currently supported by more than 220 companies. Thus, the

UPnP technology is independent of any particular operating system, programming language, or physical medium. The UPnP architecture supports zero-configuration networking and automatic discovery whereby a device can dynamically join a network, obtain an IP address, announce its name, convey its capabilities upon request, and learn about the presence and capabilities of other devices. DHCP and DNS servers are optional and are only used if they are available on the network. A device can leave a network smoothly and automatically without leaving any unwanted state information behind. Though UPnP technology has a lot of advantages, it needs some additional features for being used as a robot middleware. First, a mechanism for assigning priorities to control messages(or commands) and for managing the priorities is needed in robots. In a robot, each software component needs message priority. A high priority message should be delivered before low priority ones. For instance, when a robot vision component detects an obstacle in front of the robot, a control signal for stopping the robot should be delivered to the motor control component faster than any other messages. However, UPnP technology has not defined any mechanism for message priority assignment and management. Recently the UPnP forum released the standardized service descriptions for Quality of Service V1.0, and UPnP QoS(Quality of Service) architecture. But, it contains QoS implementation mechanism just for UPnP AV services. Secondly, a mechanism for synchronous request and response should be provided. In the UPnP architecture, a software component can be mapped to a Control Point or a Device. The Control Point plays the role of the client, and the Device plays the role of the server in the terminology of client-server architecture. The service request of a Control Point is invoking an action on a Device, and the Device returns a response to the Control Point. While a function call in an object-oriented program generally is blocked until a

4717

return value is obtained, a service request in the UPnP architecture is usually not blocked. The Control Point does not wait the response after a service request, but proceeds its processing. The response is returned afterwards as an event. It means that UPnP Control Points work in the non-blocking mode. In other words, the service requests and responses are generally asynchronous in the UPnP architecture. However, sometimes blocking mode or synchronous service requests are needed when UPnP technology is used in robot integration. Thirdly, combination of Device and Control Point should be practically feasible. In the UPnP architecture, the Control Point and the Device are clearly divided in their roles. However, there is a case where a software component has to play a role of the Control Point(client) to another component while it works as a Device(server) to the third component. Fig. 2 shows an example of the case.

network connections among hardware devices. For instance, a robot could consist of multiple computers, which are connected with Ethernet and IEEE 1394 network as shown in Fig. 3.

Fig. 3 An example of robot hardware configuration.

In this case, networks can be classified to high speed and low speed networks. Then, the network can be used efficiently. For example, important messages that need to be delivered fast can use the high speed network while non-realtime messages such as discovery messages and description messages can use the low speed network.

Fig. 2 An example case of the combination of the Device and the Control Point.

In this figure, the navigation coordinator receives commands for navigation from the task manager. Thus, the navigation coordinator should work as a Device. In turn, in order to accomplish the command from the task manager, the navigation coordinator sends requests to other components such as the path planner and the navigation map component. In this case, the navigation coordinator works as a Control Point. The UPnP Device Architecture does not mention the possibility of this combination. Only there is a simple comment about it on the reference book by Intel[11]. The UPnP SDKs that we have tested do not support the combination of the Device and the Control Point. Fourthly, complex data types such as struct and array type should be supported and can be easily used by developers. The data types defined in the UPnP Device Architecture specification V1.0 includes signed/unsigned character, integer, and long for integer type, and float, double, and fixed.14.4 for float type. Besides, it defines boolean, string, date, time, URI, and UUID. It also forces MIME-style Base64 encoding or hexadecimal digit representation for binary data. However, service requests from a software component can not include only the above data types, but also complex data types. The UPnP Device Architecture specification mentions the possibility of non-standard vendor extensions. The extension method is using XML schema, which is similar to that of the Web Service. Thus, defining and using complex data types should be easy for developers. Additionally, if the UPnP based robot middleware supports the functionality of network selection out of multiple networks, it would be beneficial. A robot could have multiple

IV. UPNP SDKS Currently several companies provide UPnP SDKs with which developers can develop UPnP devices. For instance, Microsoft provides UPnP APIs as a part of the Windows Platform SDK[12]. It is COM based API, and runs on the Windows platform. Siemens also provides its own UPnP SDK, which supports Java and C++[13]. It includes programming guide and samples. Intel UPnP SDK may be the most complete UPnP SDK because it provides many useful tools for the development of UPnP devices[14]. Intel also developed and opened to the public the Linux SDK for UPnP Devices(libupnp)[15]. Since we are developing a UPnP based robot middleware for Linux system, we have tested and examined the Intel UPnP SDK and the libupnp. The Intel UPnP SDK consists of two groups of tools, so called Intel Authoring Tools for UPnP Technologies and Intel Tools for UPnP Technologies. The first one is the authoring toolkit that allows developers to quickly build UPnP Device and Control Point stacks. The other one is the toolkit for testing and deployment of UPnP-compliant devices. The Intel UPnP SDK supports many platforms including Linux, Microsoft Windows, and Microsoft Pocket PC. The main components of the SDK are ‘Service Author’ and ‘Device Builder.’ The Service Author generates Service Description for UPnP services by receiving user inputs or by retrieving information of UPnP devices on the network. Once the XML

4718

document of the Service Description is obtained, the Device Builder can generate template code for UPnP Device or Control Point. Though the Intel UPnP SDK has been continuously updated and has many useful tools, it is covered by Intel license and there are some restrictions in modification and usage of it. The Linux SDK for UPnP Devices(libupnp) was opened by Intel, and supports Linux platform. It provides support for building UPnP-compliant control points, devices, and bridges. It complies with the UPnP Device Architecture specification V1.0. Fig. 4 shows the architecture of the libupnp.

version 4-bit

header length 4-bit Identification 16-bit TTL 8-bit

total length 16-bit

ToS 8-bit

flags 3-bit protocol 8-bit

fragment offset 13-bit

header checksum 16-bit

Source IP address (32-bit) Destination IP address (32-bit) options Fig. 5 The diagram of IPv4 header.

Fig. 6 The Type of Service(ToS) octet.

Fig. 4 The architecture of Libupnp SDK.

The architecture consists of three components, XML parser, ThreadUtil, and UPnP SDK. The three components provide their own APIs. The main part of the architecture is the UPnP SDK, which in turn consists of BSD socket layer, mini server, HTTP parser, web server, and components for handling SSDP, GENA, SOAP messages. The libupnp does not provide any tool with GUI for development, but UPnP protocol stacks and a few sample programs. It does not generate template codes automatically, either. Users have to refer the sample programs to develop UPnP devices. However, since the libupnp is under the BSD license, it has an advantage for modification and reuse of its code. Thus, we tried to implement the required features mentioned above with the code of libupnp. V. IMPLEMENTATION AND EXPERIMENTS In the UPnP technology, device discovery and control are accomplished by passing SSDP and SOAP messages using UDP/IP and TCP/IP protocol, respectively. As mentioned before, it would be beneficial to attach priorities to these messages, and to manage them according to the priorities. We have used the Type of Service(ToS) octet of the IPv4 header to attach priority to a message. Fig. 5 shows the diagram of IPv4 header. The Type of Service octet represents the quality of network service. It is defined in the standard documents such as RFC791, RFC1349, RFC2474. The Type of Service is one byte long, and the details of it are shown in Fig. 6.

The TOS facility is one of the features of the Type of Service(ToS) octet in the IP datagram header. The Type of Service octet consists of three fields as shown in Fig. 6. The first field, labeled ‘PRECEDENCE’ above, is intended to denote the importance or priority of the datagram. The second field, labeled ‘TOS’ above, denotes how the network should handle the traffic. The last field, labeled ‘MBZ’ (for ‘must be zero’) above, is currently unused and set to zero. The TOS field can have 5 values such as delay(1000), throughput(0100), reliability(0010), cost(0001), and normal(0000). The ‘delay’ means to minimize delay, and the ‘throughput’ means to maximize throughput. We determined to use the ‘delay’ for high priority, and the ‘throughput’ for low priority. In order to set the value of TOS field, we can use the ‘setsockopt’ function commonly in both of Microsoft Windows and Linux. Thus, we modified the UPnP APIs so that it provides users with the functions that can set the TOS value. Once the TOS field is set, it can be managed accordingly by the network traffic control utility called ‘tc’(traffic controller) in Linux. The ‘tc’ program is a QoS control tool in Linux. It controls network traffic using 3 components; Queuing discipline, Filter, and Class. The Filter classifies network packets with a pre-defined rule, and sends them to appropriate Class. The Class is an object that has more than a Queuing discipline. The Queuing disciplines are software mechanisms that define the algorithms used for treating queued IP packets. Fig. 7 shows one example of the relations among them.

4719

Fig. 7 Queuing discipline with multiple classes[16].

We implemented the priority assignment mechanism in the libupnp, and tested it. In the experiment, we built UPnP Devices and Control Points and checked the response time according to the priorities. We increased the number of devices and control points from 10 to 80 each, and assigned high priority to half of the Devices and low priority to the other half. The message was set to be transmitted every 10ms. We used two single board computers, and each had a Mobile Pentium 4-M, 2.2GHz CPU and 1GB memory. The operating system was Redhat 9.0 with the kernel upgrade to version 2.4.27. The system architecture was similar to that in Fig. 3. We located the UPnP Devices on one computer, and the UPnP Control Points on the other computer. The two computers were connected by 100Mbps Ethernet. The message body transferred between Devices and Control Points was small number of bytes. Fig. 8 shows the response time according to the increase of the number of Devices when the PRIO(priority) Queuing discipline was used. There were several methods that we can use in Queuing discipline. We obtained similar result with the HTB(Hierarchy Token Bucket) Queuing discipline. The figure shows that the traffic control works well in the UPnP network.

Fig. 8 The change of average response time using the PRIO Queuing discipline.

Fig. 9 The mechanism of synchronous request.

As for the combination of Device and Control Point, the Intel UPnP SDK does not provide any method for it. The libupnp does not, either. We modified the libupnp so that it can accommodate it. We made a Device and a Control Point run as two threads, and work together as a UPnP component. They could communicate with each other through global variables and a shared memory. In robot development, the arguments of complex data type such as struct and array type are frequently used. As mentioned before, the complex data type can be implemented with non-standard vendor extensions. We dealt with the complex types by defining new types such as ‘X_STRUCT_TYPE’ in a XML schema, and by using the schema in the services. Since the combination of Device and Control Point, and the accommodation of complex data type, are the issues at generating template codes, we have developed a GUI based author tool that is equipped with the functionalities. As a whole, we modified the libupnp so that it contains the features mentioned above. In the following experiment, we developed a ‘Robot Hello’ program with UPnP components, and checked the usefulness of UPnP as robot middleware by running the program on a robot. The testbed robot consists of 3 single board computers(SBC) in hardware, and they are connected each other with networks as shown in Fig. 3. The SBC’s are based on Linux and adopt a realtime OS such as RTAI. Fig. 10 shows the appearance of the robot.

We also implemented a mechanism for synchronous request in the libupnp. We made a double linked list structure for the registration of outgoing requests, and let the program register request information whenever it made a request. The information included the service name, the action name, the returning argument name, the returning argument value, and the waiting time. When a Control Point program makes a request with this mechanism, it is blocked until it receives a response or time is over. We also made an event handler to handle the responses when a response is received. Once a response is received, the event handler finds a matching node in the list. If a matching node is found, the Control Point program can get the response and continue its processing. Fig. 9 explains the mechanism of the synchronous request. Fig. 10 The appearance of the testbed robot.

4720

The goal of the Robot Hello program is to let a robot show a greeting expression to a man in front of it. The robot is supposed to move forward a little, to make a bow, to say hello, and to display ‘Hello’ characters on the display. The Robot Hello program consists of 6 software components. Each component was programmed to be UPnP Device or Control Point with our UPnP based robot middleware SDK. Fig. 11 shows the relation of the UPnP components for Robot Hello.

developed for robots, it shares the service oriented architecture with emerging Web Service technology, and has many advantages for future robot middleware such as automatic discovery of services and accommodation of dynamic distributed computing environment. However, the UPnP needs some additional features for being used as a robot middleware. This paper has discussed them, and presented some requirements when developing a UPnP SDK for robot middleware. Some of the required features are not defined in the UPnP specifications while the others are defined, but are not implemented in the existing UPnP SDKs. In our research, we added the new features and implemented non-implemented features to the ‘libupnp’ UPnP stacks. This paper presented a few results of the modification. This paper also presented an experimental result of applying the UPnP to robot components. The result was successful, and convinced us that the UPnP can be a good candidate for future robot middleware. ACKNOWLEDGMENT This work was performed for the Intelligent Robotics Development Program, one of the 21st Century Frontier R&D Programs funded by the Ministry of Commerce, Industry and Energy of Korea. REFERENCES

Fig. 11 The relation of UPnP components for the Robot Hello program.

The figure shows the 6 components, and the relation between them. The ‘Robot Head’, ‘Robot Motion’, ‘Robot Voice’, ‘Robot GTK Hello’ components were programmed into UPnP Devices. The ‘Robot Head’ component controls the motion of robot head. The ‘Robot Motion’ component controls the movement of robot. The ‘Robot Voice’ component generates ‘Hello’ sound using voice synthesis when it receives a command. The ‘Robot GTK Hello’ component is supposed to display ‘Hello’ characters on the display that is installed on the robot body. The ‘Robot Greeting’ component was transformed into the combination of UPnP Device and Control Point using the new feature of the modified libupnp. We let the ‘Robot Greeting’ component include 4 Control Points inside it. The ‘Robot Greeting’ component acts as a UPnP Device to the task manager. When we tested the program, we could find that the new UPnP-based components worked together without any problem. The combination of UPnP Device and Control point worked well. In addition, dynamic tearing down and installation of UPnP Devices did not cause any problem and showed smooth work. So, we could see the possibility of UPnP as a good robot middleware. Currently we are implementing more UPnP Devices on the robot for various functionalities.

[1] Roomba, www.irobot.com [2] CNET news, http://news.com.com/The+leader+of+the+robot+pack/20087337_3-5776430.html [3] AIBO, www.jp.aibo.com [4] Necoro, www.necoro.com/home.html [5] CORBA, www.omg.org [6] Jini, www.jini.org [7] .net, www.microsoft.com/net [8] UPnP, www.upnp.org [9] Web Services, www.w3.org/2002/ws [10]DLNA, www.dlna.org [11]M. Jeronimo and J. Weast, UPnP Design by Example, Intel Press, 2003. [12]Microsoft UPnP APIs, www.microsoft.com/whdc/device/netattach/upnp/ UPnPSDK.mspx [13]Siemens UPnP SDK, www.plug-n-play-technologies.com [14]Intel Tools for UPnP, www.intel.com/cd/ids/developer/Asmo-na/eng/ download/upnp/index.htm [15]Linux SDK for UPnP Devices, upnp.sf.net [16]Queuing discipline, lion.cs.uiuc.edu/courses/cs397hou

VI. CONCLUSION The UPnP (Universal Plug and Play) defines an architecture for pervasive peer-to-peer network connectivity of intelligent appliances. Even though it was not originally

4721