Developing Service Oriented Robot Control System Davide Brugali∗ , Andrea Fernandes da Fonseca∗ , Andrea Luzzana∗ and Yamuna Maccarana∗ ∗ Department of Engineering, University of Bergamo, Italy Email:
[email protected],
[email protected],
[email protected],
[email protected]
Abstract—The work presented in this paper is motivated by the aim of simplifying the integration of robotic and information systems technology. This would allow for example to extend the capabilities of autonomous robots with the possibility to access Web resources and services. For this purpose, this paper presents the Task Component Architecture, a framework for the implementation of Service Component Architecture (SCA) components that execute autonomously their service and that can be seamlessly integrated with robotic software control systems. Keywords-Robot programming, Software Components
I. I NTRODUCTION Autonomous robots are complex hardware-software systems made up of sensors (vision system, sonar, laser, etc.), actuators (wheeled platform, grasping tools, etc.), and computational units. Simple robotic devices for tasks such as cleaning floors and cutting the grass have met with growing commercial success thanks to their low cost and single purpose design. At the same time, more sophisticated robotic devices such as Care-O-bot (http://www.care-o-bot.de/) have been developed for more advanced tasks, such as housekeeping and elder care, further raising expectations. Recent approaches investigate how the robot can exploit the World Wide Web to retrieve useful information such as 3D models of furniture [1] and images of objects commonly available at home [2]. In [3] the Robotic Information Home Appliance is illustrated as a robot interconnected to the home network that offers a friendly interface to information equipment and home appliances. This new trend poses new challenges in the development of robot software applications since they have to integrate robotic and information systems technologies, which account for quite different non-functional requirements. At one side, modern robot control systems are typically designed as (logically) distributed component-based systems [4], [5], where the interactions between components (control, sensing, actuating devices) are usually more complex compared to more traditional business applications. In Robotics, the software developer faces the complexity of event-based and reactive interactions between sensors and motors and between several processing algorithms. Performance and real-time guarantees are the most critical non-functional requirements. For this reason, robotic-specific componentbased models and toolkits have been developed, which offer mechanisms for real-time execution, synchronous and
asynchronous communication, data flow and control flow management, and system configuration. At the other side, Service Oriented Architectures (SOA) have been proposed as an architectural concept to enhance scalability, portability, and flexibility of complex information systems. Some attempts to develop robotic applications as SOA systems can be found in the literature (a recent survey can be found in [6]). Their main disadvantage is that they give up the typical component-based nature of robotics systems and force a pure service oriented approach. The Distributed Agents with Collective Intelligence (DAvinCi) framework [7] enable teams of heterogenous robots to collaborate by sharing maps of a large environment environment via a Software as a Service (SaaS) Model. The DAvinCi server, which provides access to a cloud computing distributed data storage and processing system. Service Component Architectures (SCA, http://www.oasis-opencsa.org/sca) have been proposed as an architectural concept for the creation of applications that are seamlessly integrated with web services and the most common Java toolkits. A SCA system is built by assembling loosely coupled and interoperable components, whose interactions are defined in terms of bindings between provided and required services. In [8] we have presented the JOrocos library, which allows to interconnect SCA components with hard real-time control components implemented using the Orocos robotic framework (http://www.orocos.org). The JOrocos library solves the architectural mismatch between the service-oriented architectural style of SCA and the data flow architectural style of Orocos. In this paper we address the integration of SCA with another popular robotics framework used by research teams worldwide, i.e. the Robot Operating System (ROS, http://www.ros.org). The main issue related to the integration of SCA components and ROS components (called nodes) is the architectural mismatch between the service-oriented architectural style of SCA and the event-driven architectural style of ROS (Section II). This problem has been addressed also in [9], where the iCCM framework has been presented for integrating OMG Data Distribution Service (DDS) technology into the CORBA Component Model (CCM). Our approach leverages the SCA technology by defining a software framework for the implementation of SCA components that can perform control activities concurrently
Figure 1.
The robot navigation architecture
and periodically and can exchange data and events asynchronously (Section III). For this purpose, we have exploited the Java Concurrency Utilities [10] and the Java Messaging Service (JMS) API (http://docs.oracle.com/javaee). The result is what we call the Task Component Architecture (TCA). TCA components have been then enabled to exchange data and event with ROS components through the ROSJava API (http://code.google.com/p/rosjava/) (Section IV). The Jadex framework (http://www.activecomponents.org/) provides similar capabilities but does not support the implementation of components that execute their activities periodically. The conclusions are discussed in Section V. II. ROBOT C ONTROL A RCHITECTURE In this context, the SCA framework can be used to provide the robot system with higher-level funcionalities such as the access to large data repository, the coordination of the robot tasks and activities, and for implementing complex humanrobot interaction functionalities. As a case study we consider the component-based navigation architecture for autonomous robots depicted in Figure 1, which results from the refactoring of open source robotics libraries [11]. The lower part consists in reactive components implemented as ROS nodes implementing the functionalities (i) for computing the speed of the rover wheels to move it at the velocity specified by the Twist command (RoverDriver), (ii) for reading the laser measures used to detect unexpected obstacles (LaserDriver), (iii) for controlling the rover velocity in order to follow a precomputed trajectory (TrajectoryFollower), and (iv) for adapting the precomputed
trajectory to avoid a detected obstacle (TrajectoryAdapter). ROS nodes exchange messages of the topics represented by green boxes. In particular, the TrajectoryFollower and the TrajectoryAdapter publish events that notify the arrival of the robot at destination and the need of recomputing the trajectory when an obstacle cannot be avoided. The upper part of the navigation architecture is composed of TCA components that implement concurrent activities and exchange messages through the JMS framework. In particular, the ROSProxy component acts as a bridge between the TCA and ROS frameworks that maps ROS messages to JMS messages and viceversa. The MapServer component acts as an interface for accessing GIS data (http://geotools.org/) to retrieve maps of given locations. The TrajectoryPlanner generates obstacle-free trajectories to given goal positions. Finally, the ASMCoordinator coordinats the activities of the TCA components and to react to events published by both TCA and ROS components. The ASMCoordinator allows to specify coordination policies using the SCA-ASM language [12] that combines SCA with the formal method Abstract State Machine (ASM) in terms of service behavior, interactions, and orchestration in an abstract but executable way. III. SCA FOR CUNCURRENT EVENT- DRIVEN SYSTEMS The TCA framework has been conceived as a Java library that can be used to implement SCA components that execute autonomously their service and do not require client components to invoke them. The specification of a SCA component is defined as an XML-based model in terms of provided services, required services (called references), and properties and is independent from specific SOA platforms and middleware programming APIs (as Java, C++, Spring, PHP, BPEL, Web services, etc.). SCA systems can be built by wiring services and references of components pairs according to the client/server interaction paradigm. Runtime environments (like Apache Tuscany and FRAscaTI) enable to create service components, assemble them into a composite application, and then run/debug the resulting composite application. TCA components are SCA components which are implemented as Java classes that extend the TCA framework. TCA components can thus interact according to the standard SCA client/server interaction paradigms and can be composed to form SCA composite. In addition, TCA components leverage the Java Concurrency Utilities [10] to implement periodic activities and the JMS API for asynchronous communication. A. Task Component Architecture The core module of the TCA framework is the Task class (see Figure 2). Task implements the TaskInterface interface, which defines the scheduleTask and unscheduleTask methods, that can be used to start and interrupt the
Figure 3. Planner
Figure 2.
The TCA class diagram
periodic execution of the component, and the isRunning method, which returns a boolean value corresponding to the actual state of the component. The component’s periodic execution is achieved using Java Concurrent Framework, which provides a set of safe and robust low-level services that enable and simplify the writing of concurrent and periodic threaded applications. We used the ScheduledExecutorService and ScheduledFuture classes (see Figure 2) to manage schedulation and termination. As an example, Figure 3 illustrates the code that implements the initialize() and execute() methods of class TrajectoryPlanner.java, which is used to implement the TrajectoryPlanner component. The implementation of the TrajectoryPlanner class consists in three steps: First, the developer has to declare the topics of the messages that the component will publish and subscribe. For this purpose, the TCA framework offers the TopicObject class (Figure 3, line 2 to 5). Second, the initialize() method has to be implemented to declare the intention of subscribing and publishing to specific topics (Figure 3, line 7 to 10) using the methods publish() and subscribe(). The initialize() method is called by the init() method of the Task class (Figure 4, line 9) when the component is instantiated.
Listing: initialize() and execute() methods in class Trajectory-
The third step is to implement the execute() method, which retrieves the last incoming message for each subscribed topic (lines 13 and 14) using the method receiveLast(), performs some computation based on the received messages (line 16 to 22) and publishes new messages on specific topics using the send() method. The component can retrieve all the messages received during the previous execution cycle using the receiveAll() method instead of the receiveLast() method. The execute() method is called by the run() method of the Task class (Figure 4, line 29) during every execution period. The message forwarding to the JMS broker is handled by the run() method at the end of the cycle (Figure 4, line 31). Every component has ten SCA properties that are used to define the Task’s behaviour: id, period and delay, runOnStartup, mayInterruptIfRunning and useJMS are the required ones. The properties runOnStartup and mayInterruptIfRunning define if the component must be scheduled as soon as it is read in the composite file and if it may be interrupted during its execution before the completion of its cycle. The property useJMS indicates if the messaging service is going to be enabled and, if true, the connection to the JMS message broker may be configured using three optional properties, namely: user, password and url. The optional property called topicRename allows to rename the component topics by specifying the pair of String hardcoded-topic-name and logical-topic-name. Topic
Figure 5.
Figure 4.
Listing: init() and run() methods in class Task
renaming is needed to dependently developed the system integrators topics that have to be components.
ensure interoperability between incomponents. At deployment time, specifies the logical names of the exchanged between interconnected
IV. I NTEGRATING TCA WITH ROS The Robot Operating System (ROS) is an open-source meta-operating system for robots. It provides a communication layer above the Linux host operating system that supports the execution of components in a distributed system. ROS offers message-based peer-to-peer communication infrastructure supporting the integration of independently developed software components, called ROS nodes, that are organized into a graph. Nodes are implemented as classes that wrap robotic software libraries and provide access to the communication mechanisms of the underlying run-time infrastructure of ROS called roscore. Messages are typed data structures and are exchanged between nodes according to the publish/subscriber communication paradigm. The message exchange is organized into topics that can be published or subscribed by components. When a message is received on a topic, all subscribed nodes are asynchronously notified by the roscore. When notified in this way, nodes perform some computation on the payload data carried with the message and eventually output the computation results on another topic by publishing a new message.
The ServiceROS Package
Messages are defined in a programming-language independent IDL that is translated into programming language objects by the framework. The ROS infrastructure is distributed as a software library that implements mechanisms for managing the node execution, the topic based communication and the organization of the graph of nodes across one or more computers. This library is implemented in C++, Python and, recently, in Java language. This last implementation is called rosjava. Rosjava nodes are implemented by extending the AbstractNodeMain class provided by the library, which includes the main program. Several rosjava nodes can run in a thread pool into a single Java Virtual Machine. They are launched by the rosjava’s CommandLineLoader by specifying the name of the .class files implementing the nodes. This characteristics prevents the encapsulation of a rosjava node into other Java classes. In order to integrate rosjava with TCA, we have developed the ServiceROS library. For these reasons we have developed the ServiceROS library, which encapsulates the rosjava mechanisms into a Java class (see Subsection IV-A) that can be used to implement TCA components (see Subsection IV-B). A. The ServiceROS library The ServiceROS library is distributed as a package containing three main classes and an interface as depicted in Figure 5. The RosProxyNode class provides means for the creation phase by implementing the NodeMain interface of the rosjava package described above. The RosProxyNode class implements the NodeMain interface of the rosjava. It hides the details of the CommandLineLoader to the developers and automates the node creation. This ensures that the node will be created with the correct path and class name in order to be effectively loaded by the ROS system. The RosProxyNode class is also in charge of allowing the user to configure the newly created node by adding publishers and subscribers objects for interfacing with ROS topics. For this purpose, RosProxyNode class implements the
Figure 6.
The ROSTask
RosProxyIntf interface that specifies methods for adding publishers, subscribers and user defined observers to topics. The class keeps a list of publishers, subscribers and observers objects associated to each topic. When a new publisher is added to a topic, the class verifies if it is already present before adding it and eventually throws an exception. The same mechanism is adopted for subscribed topics that cannot be subscribed more than once. When adding an observer to a subscribed topic, the class verifies if the topic is present in the list of subscribed topics before adding it. More than one observer can be associated to a single subscribed topic since the RosProxyNode class manages the notification of multiple observers. These features provide more control on the topic management resolving the second limitation of rosjava. Finally, the RosProxyNode enriches the asynchronous notification functionality offered by rosjava through its MessageListener interface by implementing it with the TopicMessageListener class. This class implements the java.util.Observable class allowing the RosProxyNode to add multiple Observers objects to it. So doing, one single TopicMessageListener is associated to each subscribed topic by the RosProxyNode while one or more observers can be associated to it. Each TopicMessageListener is in charge of capturing new message events on the topic (by implementing the onNewMessage method of the MessageListener interface) and forward the notifications to all of its observers. The RosProxy class wraps the functionality of the RosProxyNode class following the Facade pattern [13]. In particular it collects the node creation operations into its constructors and provides the setup() method that is in charge of configuring the ROS node and verify its presence in the ROS runtime graph. This class also allows the user to add his own observer objects to subscribed topics provided that they implement the java.util.Observer interface. Moreover, the RosProxy class mediates the access to the TopicMessageFactory class of rosjava. This class provides
Figure 7.
initialize() and execute() methods in class TrajectoryPlanner
concrete ROS objects representing message types given their string representation (e.g. “geometry msgs/Twist” for a ROS Twist message). B. TCA wrapper of ROS nodes The integration between the ROS and the TCA subsystems is achieved by the ROSTask component that extends the Task class of TCA and instantiates a RosProxy object. The ROSTask acts a gateway that forwards messages from ROS to TCA and from TCA to ROS without making computation on them. Figure 6 shows the UML class diagram of the ROSTask. The ROSTask class must be reimplemented according to each specific application since the message translation between TCA and ROS is not automated. This operation, however, is simplified by the fact that both ROS and TCA message objects are simple data container classes that do not make computation on the carried payload. The listing in Figure 7 shows the simplified code of the initialize() method and the execute() method of the ROSTask component that manages the subscription and publication of Trajectory messages from TCA to ROS and the Event messages from ROS to TCA. The RosProxy object is initialized by passing the URI of the machine which is currently running the roscore. In the lines below, the rosproxy is used to create a message listener and a message publisher and to add an observer (Line 7 in Figure 7) for managing the incoming Event messages. This observer is initialized with the current ROSTask instance that will be used to forward incoming Event
messages. When notified, the observer retrieves the ROS message from the argument parameter and creates a TCA’s OdometryMessage (tcaOdoMsg) that is the added to the list of output messages of the ROSTask instance. Subsequently the setup() method is called in order to register the node to the ROS node graph and for connect topics. After the initialization the rosproxy object is used to obtain the concrete objects representing Event and Trajectory messages. Finally, the publishers and subscribers of the TCA component are configured. The execute() method shown in the listing of Figure 7 forwards Trajectory messages received from TCA components to the ROS nodes of the system. V. C ONCLUSIONS In this paper we have discussed the integration of the Service Component Architecture (SCA) and the Robot Operating System (ROS) framework and runtime infrastructure for the development of robot control systems that are able to easily access distributed information services. We have illustrated the Task Component Architecture (TCA), which extends SCA by supporting the development of software components that execute periodic control activities, exchange data and events with other TCA components through JMS, and are able to publish on and subscribe to ROS topics. The TCA framework is implemented in Java, a programming language that is gaining momentum in the development of robotic applications [14]. As future work, we aim at extending the HyperFlex toolchain [15] with the possibility to develop robotic software product lines (SPL) based on the TCA framework. HyperFlex is a Model-based toolchain that allows to graphically design the software architecture of a robotic SPL in terms of variation points and variants, to graphically select functional features according to the application requirements, and to automatically generate the deployment configuration of the robot control system [16]. R EFERENCES [1] O. Mozos, Z.-C. Marton, and M. Beetz, “Furniture models learned from the www,” Robotics Automation Magazine, IEEE, vol. 18, no. 2, pp. 22 –32, june 2011. [2] M. Tenorth, U. Klank, D. Pangercic, and M. Beetz, “Webenabled robots,” Robotics Automation Magazine, IEEE, vol. 18, no. 2, pp. 58 –68, june 2011. [3] T. Yoshimi, N. Matsuhira, K. Suzuki, D. Yamamoto, F. Ozaki, J. Hirokawa, and H. Ogawa, “Development of a concept model of a robotic information home appliance, aprialpha,” in IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), vol. 1, 2004, pp. 205 – 211. [4] H. Bruyninckx and et al., “The brics component model: A model-based development paradigm for complex robotics software systems,” in Proceedings of the 28th Annual ACM Symposium on Applied Computing, ser. SAC ’13. New York, NY, USA: ACM, 2013, pp. 1758–1764.
[5] D. Brugali, L. Gherardi, A. Biziak, A. Luzzana, and A. Zakharov, “A reuse-oriented development process for component-based robotic systems,” in Proceedings of the Third International Conference on Simulation, Modeling, and Programming for Autonomous Robots, ser. SIMPAR’12. Springer-Verlag, 2012, pp. 361–374. [6] R. de Molengraft, van, M. Beetz, and T. Fukuda, “A special issue toward a www for robots,” Robotics Automation Magazine, IEEE, vol. 18, no. 2, pp. 20–20, june 2011. [7] R. Arumugam, V. Enti, L. Bingbing, W. Xiaojun, K. Baskaran, F. F. Kong, A. Kumar, K. D. Meng, and G. W. Kit, “Davinci: A cloud computing framework for service robots,” in Robotics and Automation (ICRA), 2010 IEEE International Conference on, 2010, pp. 3084–3089. [8] D. Brugali, L. Gherardi, M. Klotzbcher, and H. Bruyninckx, “Service component architectures in robotics: The sca-orocos integration,” in Leveraging Applications of Formal Methods, Verification, and Validation, ser. Communications in Computer and Information Science. Springer, 2012, pp. 46–60. [9] D. Feiock and J. Hill, “Using component-based middleware to design and implement data distribution service (dds) systems,” in Software Engineering and Advanced Applications (SEAA), 2013 39th EUROMICRO Conference on, 2013, pp. 208–211. [10] “Java Concurrency http://docs.oracle.com/javase/7/docs/ notes/guides/concurrency/.
Utilities,” tech-
[11] D. Brugali, W. Nowak, L. Gherardi, A. Zakharov, and E. Prassler, “Component-based refactoring of motion planning libraries,” in Intelligent Robots and Systems (IROS), 2010 IEEE/RSJ Int. Conf. on. IEEE, 2010, pp. 4042–4049. [12] D. Brugali, L. Gherardi, E. Riccobene, and P. Scandutta, Coordinated execution of heterogeneous service-oriented components by Abstract State Machines, ser. Lecture notes in computer science ; 7253. Springer, 2012, pp. 331 – 349. [13] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, “Design patterns: Elements of reusable object-oriented design,” 1995. [14] L. Gherardi, D. Brugali, and D. Comotti, “A java vs. c++; performance evaluation: A 3d modeling benchmark,” in Proc. of the Third Int. Conf. on Simulation, Modeling, and Programming for Autonomous Robots, ser. SIMPAR’12. SpringerVerlag, 2012, pp. 161–172. [15] D. Brugali and Gherardi, “Modeling and reusing robotic software architectures: the hypeflex toolchain,” in Proceedings of the 2014 IEEE Int. Conf. on Robotics and Automation, ser. ICRA2014. IEEE, 2014. [16] N. Hochgeschwender, L. Gherardi, A. Shakhirmardanov, G. K. Kraetzschmar, D. Brugali, and H. Bruyninckx, “A model-based approach to software deployment in robotics,” in Intelligent Robots and Systems (IROS), 2013 IEEE/RSJ Int. Conf. on, 2013, pp. 3907–3914.
