• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Software Architecture for Robotics
 

Software Architecture for Robotics

on

  • 304 views

Report about Software Architecture for Robotics, for class of Introduction to Robotics of Prof. Sukhan Lee, of department of computer engineering of Sungkyunkwan University. ...

Report about Software Architecture for Robotics, for class of Introduction to Robotics of Prof. Sukhan Lee, of department of computer engineering of Sungkyunkwan University.

Student: Lorran Pegoretti.

Suwon, South Korea, December 2013

Statistics

Views

Total Views
304
Views on SlideShare
304
Embed Views
0

Actions

Likes
0
Downloads
1
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Software Architecture for Robotics Software Architecture for Robotics Document Transcript

    • REPORT FOR “SOFTWARE ARCHITETURE FOR ROBOTICS”, PROF. SUKHAN LEE. Software Architecture for Robotics Lorran de Souza Pegoretti Dept. of Computer Engineering, Sungkyunkwan University Suwon, South Korea December 2013 Abstract – Programming a software for robotics is a non-trivial task. The software must coordinate a countless number of different hardware elements and software elements and must support some requirements of heterogeneous systems. In this report, I want to present briefly, some idea of how should be the software architecture for a robot and in addiction explain what a middleware is, and how it can help us to develop the software for a robot. 1 Introduction Programming a software for robotics is a non-trivial task; it requires a significant iteration and coordination of hardware and software elements. The aggregation of a large number of sub-systems must be based on a solid software architecture, for this way be possible realize the ambitious objectives of robotic research. In addition, we need to guarantee a certain level of flexibility, performance and reusability of both hardware and software and support the requirements of heterogeneous modern robotic system that can be briefly summarized as: hardware abstraction, scalability, modularization, support for multiple operating systems, extendibility, simplicity, limited runtime, networked computing, completeness, etc. Systems for robotics are becoming more and more complex, increasing the number of constitutional parts that make up current robotic, as multiple sensors for perception, torque, radar, laser based on sensors or vision systems including cameras as different as low-cost web-cams and high-dynamic-range cameras. Moreover, there are required and desired features for a robot software. In an academic perspective there are required features as; support for multiple components, communication between components, easy way to write own components, possibility to replace individual components, easy to extend, means for data logging and debugging and support for decentralized components. Desired features are; robustness, hardware abstraction, open access (open source would be the ideal case) and hardware and operating systems independence. 1
    • REPORT FOR “SOFTWARE ARCHITETURE FOR ROBOTICS”, PROF. SUKHAN LEE. Figure 1 - Hardware and software communication In this scenario, of many hardware and software components needing to communicate and collaborate to each other to reach a goal, a plenty of required and desired features that need be covered, is exactly where a middleware can help improving the organization, the maintainability and the efficiency of the code. In this report I will introduce the meaning of middleware, what is a middleware, how a middleware can help us in the development of software for robots, how is the middleware architecture and where we fit the middleware in our system. 2 Middleware 2.1 Middleware Origins Middleware is a relatively new concept in computer science. It gained popularity in the 1980’s as solution to wrap legacy system and interface them with newer application. However, the introduction for the term “Middleware” can be dated of 1968 [1], when d’Agapeyeff used it for the first time to identify the part of the software that could be shared between different applications. D’Agapeyeff described an inverse pyramid (Figure 2) that describes a primitive software architecture in which the high-level applications are build using a set of middle level routines, so from this description comes the name “middleware”. Figure 2 - Inverse pyramid of d'Agapeyeff 2
    • REPORT FOR “SOFTWARE ARCHITETURE FOR ROBOTICS”, PROF. SUKHAN LEE. 3 2.2 What is a Middleware? According to Wikipedia, “Middleware is a computer software that provides service to software applications beyond those available from the operating system. It can be described as “software glue”. Middleware makes it easier for software developers to perform communications and input/output, so they can focus just on the specific purpose of their application”. Generally, a middleware consists of a set of services that allows multiple process running on one or more machines to interact. This technology evolved to provide interoperability in support the diffusion of coherent distributed architectures, which are most often used to support and simplify the development of complex distributed applications. It includes services, applications servers, and similar tools that support application development and delivery. [2] Middleware “sits in the middle” between software applications that may run on different operating system, it is stretched across multiple systems or applications. The middleware cannot be confused with operating system; however, both are software used to support other software, such as the application programs. Both provide a similar range of services centered around controlled interaction. Like and operating system, middleware may enforce rules designed to keep the computations from interfering with one another. [3] Middleware is a set of libraries and APIs for specific applications; however, middleware is not just this, middleware also represent a way of thinking the software, which will be designed and developed on a specific middleware, so that defines the foundation for a complete application. 2.3 Why use Middleware? Middleware is useful for a number of reasons when designing large, distributed systems. Some relevant aspects are: Portability: middleware offers a common programming model across language and/or platform boundaries, as well as across distributed end systems. Thanks to this, it is possible to make cooperative applications developed in different languages (e.g. Java and C++) and executed on different operating systems (e.g. Windows and Linux) without any specific effort by the programmer. Reliability: middleware are developed and tested separately from the final application. This allow the application programmer to abstract low-level aspects and use (and re-use) a well-tested library. Managing complexity: low-level aspects could be managed by suitable libraries that abstract specific operating system or hardware aspects. This simplifies development and reduces the probability of errors. [4] 3 Middleware in Robotics 3.1 Introduction Robotic systems are usually complex systems built on many different hardware and software components, as sensors, actuators, cameras, planners and control algorithms.
    • REPORT FOR “SOFTWARE ARCHITETURE FOR ROBOTICS”, PROF. SUKHAN LEE. 4 In general, on each robot runs a software that is responsible for reading sensors data, extracting the needed information from them, computing the sequence of actions to accomplish a given task and controlling the actuators to execute the actions. In a custom approach, there will be a single application that will handle all these tasks, making code maintenance, code reuse extremely hard and preventing any form of code sharing between different projects. In this scenario, with many hardware and software components that needs to communicate and collaborate to each other to reach a goal, is exactly where a middleware can help improving the organization, the maintainability and the efficiency of the code. Different components can exchange data using a common communication channel provided by the middleware, using interfaces that are consistent between different applications. In this way, it becomes easy to share and reuse code among different projects, since is only necessary to keep the same interface. As an example, if we need to switch from a proximity sensor to another, it is possible to write a new component that share the same interface and update it without modifying the rest of the application. This concept can be extended to large and complex applications, in which using a middleware can clearly improve the overall code organization and reduce the programming effort. 3.2 Robotics Middleware Projects There are plenty of robotics middleware projects, now I will present some of them and explain how they are built, which programming language is used to develop each one and what does it offer to us. Player Project: It is an application server with the collection of dynamically loadable device shared libraries. The main portion of this server is custom communication protocol, which enables client-server communication model. Player is implemented in C++ and uses POSIX compliant pthread interface for multithreaded applications. Player can be viewed as a multithreaded application server providing applications/services to client programs. For Player application/services are devices that are used by client programs. Since applications/services can be loaded dynamically, Player can be considered as "some way in between monolithic application and modular middleware + services" approach. Player does not implement any device locking mechanism whenever multiple clients are connected to a Player server, so one can overwrite the commands of other clients. This applies to commands and data but not to configuration requests, which can be used to access specific hardware features. RT-middleware Project: RT-middleware (Robotics Technology Middleware) is a common platform standards for Robots based on the distributed object technology. [5] RT-middleware supports the construction of various networked robotic systems by the integration of various network enabled robotic elements called RT-Components. The specification and standard of the RT-component is discussed/defined by the Object Management Group (OMG). [6] In the RT-middleware, robotics elements, as actuators, are regarded as RT-components, and the completely robotic system is constructed by connecting those RT-components. Using this
    • REPORT FOR “SOFTWARE ARCHITETURE FOR ROBOTICS”, PROF. SUKHAN LEE. 5 distributed architecture developers can re-use the robotic elements, and boosts the reliability of the robotic system. RT-middleware is just standard of the Robotics platform software. Therefore, there are several implementations of RTM. RT-middleware does not assure the communicability between the RTM implementations, however, the bridging tools that intermediate the communication can be easily created because the state machines and their programming model is defined. As example:  OpenRTM.NET is an implementation of the RT-middleware for the .NET Framework platform. [7]  "RTM on Android" is an implementation on Android OS that is communicable with OpenRTMaist. [7]  "RTC Lite" is a modified RT-middleware for embedded or small-resource systems such as PIC (Microchip), ARM, H8 (Runesus), etc. [7] MIRO: MIRO uses an abstract machine model; the system is divided into several distinct layers. The higher layers can only access the lower layers via their interfaces. In case of MIRO, these layers are:  MIRO device layer: this layer provides classes to interface hardware and abstract the lowlevel hardware details, these classes enable access to hardware resources via simple procedure calls.  MIRO service layer - this layer provides service abstractions for sensors and actuators by means of the CORBA interface definition language. These services are implemented as network transparent objects/CORBA objects. The classes in this layer present the sensors and actuators as generic services. For example, the RangeSensor class defines functionality common to the sensors, which return range readings such as sonars, lidars and other type of range finders.  MIRO framework layer - on this level functional modules specific to robotics are provided. Examples are mapping, localization, path planning and similar facilities. For communication purposes, MIRO relies on a TAO middleware C++ implementation of the CORBA standard. Subsystems/Objects communicate according to a client-server model, which is an example for a distribution model. With respect to the time properties, both synchronous and asynchronous modes of communication are utilized. The system also supports event driven communication. 4 Middleware for Space Robots 4.1 Problem Looking to middleware’s potential and what it has to offer us, we can think that using the proper middleware is the solution to any problem that we may have about projecting and developing a software for a robot. However, in some cases we cannot use a middleware, so we need to appeal to other solution. One example that a middleware is not a solution is when we need to develop a software for space robot. In this situation, we cannot use a middleware because it does not meet the requirements of flight software and hardware.
    • REPORT FOR “SOFTWARE ARCHITETURE FOR ROBOTICS”, PROF. SUKHAN LEE. 6 As requirements that are not meet, we can cite: performance and memory usage, the fact of the software does not have dynamic memory allocation, does not have callbacks and there is no large external libraries. 4.2 Solution - CLARaty A possible solution for software architecture for a space robot is to use approach proposed by CLARaty (Cloupled Layer Architecture for Robot Autonomy). One difference between the CLARaty architecture and the conventional three-level architectures is the explicit distinction between levels of granularity and levels of intelligence. In conventional architectures, both granularity and intelligence were aligned along one axis. As you move to higher abstractions of the system, intelligence increases. This is not true for CLARaty, where intelligence and granularity are on two different axes. In other words, the system decomposition allows for intelligent behavior at very low levels while still maintaining the structure of the different abstraction levels. The CLARaty architecture has two distinct layers: the Functional Layer and the Decision Layer. The Functional Layer uses an object-oriented system decomposition and employs a number of known design patterns to achieve reusable and extendible components. These components define an interface and provide basic system functionality that can be adapted to a variety of real or simulated robots. It provides both low-level and mid-level autonomy capabilities. The Decision Layer couples the planning and execution system. Figure 3 - Two layers of CLARaty approach
    • REPORT FOR “SOFTWARE ARCHITETURE FOR ROBOTICS”, PROF. SUKHAN LEE. 7 The Decision Layer uses a declarative-based model while the Functional Layer uses a procedural-based model. Because the Functional Layer provides an adaptation to a physical or simulated system, all specific model information is collocated in the system adaptations. The Decision layer receives this information by querying the Functional Layer for predicted resource usage, state updates, and model information. The Decision Layer accesses the Functional Layer at various levels of granularity (Figure 3). The architecture allows for overlap in the functionality of both layers. This intentional overlap allows users to elaborate the declarative model to lower levels of granularity. However, is also allows the Functional Layer to build higher-level abstractions (e.g. navigator) that provide mid-level autonomy capabilities. In the latter case, the Decision Layer serves as a monitor to the execution of the Functional Layer behavior, which can be interrupted and preempted depending on mission priorities and constraints. [8] 5 Conclusion Having researched about middleware, understood how it works and how it can help us to develop a robotic software. I can notice that using a proper middleware our work becomes easier, for controlling all the sensors, for replacement of any sensor in a different one, for sharing code between different projects and for maintenance of the code. However, we must be sure about what must be done in the project. As cited, in some situations using a middleware is not the best solution, so we need appeal to other approach. As in the example of special robot or flying robot, using a middleware we may not reach the proposed goals, so we can appeal for the usage the CLARaty approach, which works in a different way, in a double layer and not in a three-level architecture. I can also notice that this research field is far from state of art, we are just in the beginning, and there is still a long way to roam when the subject is software architecture for robotics. References [1] Report on a conference sponsored by the NATO SCIENCE COMMITTEE. Garmisch, Germany, 7th to 11th October 1968 [2] Simone Ceriani and Martino Migliavacca. Report for “Advanced methods of information technology for autonomous robotics”, Milan, Italy [3] Thomson Course. Operating Systems and Middleware: Supporting Controlled Interaction., California, USA, October 18, 2005 [4] C.D. Gill and W.D. Smart. Middleware for robots? Proceedings of the AAAI Spring Symposium on Intelligent Distributed and Embedded Systems, 2002. [5] Noriaki ANDO, Takashi SUEHIRO, Kosei KITAGAKI, Tetsuo KOTOKU, Woo-Keun Yoon, "RT-Middleware: Distributed Component Middleware for RT (Robot Technology)", 2005, Edmonton, Canada [6] Object Management Group (OMG). “Robotics Technology Component Specification version 1.1” [7] OpenRTM-aist, [http://openrtm.org/] [8] I. A. D. Nesnas, A. Wright, M. Bajracharya, R. Simmons, T. Estlin, and W. S. Kim, “Claraty: an architecture for reusable robotic software,” in Space Robots, vol. 5083 of Proceedings of SPIE, April 2003.