Description
From MARIEWiki
Contents |
What is MARIE?
MARIE is a new design tool for mobile and autonomous robot application, designed to facilitate the integration of multiple heterogeneous software elements. It is a flexible tool based on a distributed model, thus allowing the realization of an application using one machine or various networked machines, architectures and platforms.
Motivations
The robotics field is evolving quickly : the diversity of technologies available and the software solutions developed in the various research centers throughout the world is in fact increasing the complexity of integration. All these researchers and developers, which worked to develop new solutions, see the reuse of their work by other difficult or impossible. Too much often this abandonment or negligence to use available components is due to the inherent complexity of integrate different incompatible softwares because conceived for various platforms, various operating systems or protocols and conventions of communication.
--> Fast and simplified re-use of heteroclite components developed by others is essential for the evolution of this research area.
Impacts
The impacts of such a tool on the re-use of the many existing and future technological and software solutions are very important :
- Allow the researchers and developers to concentrate on the particular aspect where they have a significant contribution to bring. Such a tool would avoid them to provide efforts for the reproduction and the adaptation of modules or applications already developed by others and which are not compatible or directly usable.
- Carry out configurations where particular components were never joined together for the same real time application. This opportunity potentially opens new avenues of research and development still not explored.
- Develop on a higher level of abstraction, such as decisional architecture. The tool makes it possible to act on this level because it abstracts the low level implementation of the robot system.
Considered Requirements
MARIE's initiative is based on the following main requirements :
- Reuse softwares, APIs, middlewares and frameworks frequently used in robotics (Player, CARMEN, RobotFlow, etc.)
- Adopt a rapid-prototyping approach to build complete system
- Allow distributed computing on heterogenous platforms
- Allow concurrent use of different communication protocols, mechanisms and standards
- Accelerate user-defined developments with well defined layers, interfaces, frameworks and plugins
- Support multiple sets of concepts and abstractions
Design Requirements
MARIE’s software architecture is based on three design choices made to address the main requirements :
Component Mediation Approach
To implement distributed applications using heterogeneous components, MARIE adapted the Mediator Design Pattern (Gamma, E. et al. 1994) to create a Mediator Interoperability Layer (MIL). The Mediator Design Pattern primarily creates a centralized control unit (named Mediator) interacting with each colleague (referred to as components) independently, and coordinates global interactions between colleagues to realize the desired system.
In MARIE, the MIL acts just like the mediator of the original pattern, but is implemented as a virtual space where components can interact together using a common language (similar to Internet’s HTML for example). With this approach, each component can have its own communication protocol and mechanism as long as the MIL supports it.
It is a way to exploit the diversity of communication protocols and mechanisms, to benefit from their strengths and maximize their usage, and to overcome the absence of standards in robotic software systems.
It also promotes loose coupling between components by replacing a many-to-many interaction model with a one-to-many interaction model. In addition to simplify each component communication interface, loose coupling between components increases reusability, interoperability and extensibility by limiting their mutual dependencies and hiding their internal implementation.
By using a virtual space approach, the MIL’s design reduces the potential complexity of managing large number of centralized components, as observed with the original pattern. This is mainly attributed on having limited centralization to communication protocols and mechanisms, and leaving most of the functionalities decentralized.
Layered Architecture
Supporting multiple sets of concepts and abstractions can be achieved in different ways. MARIE does so by adopting a layered software architecture, defining different levels of abstraction into the global middleware framework. Three abstraction layers are used to reduce the amount of knowledge, expertise and time required to use the overall system. It is up to the developer to select the most appropriate layer for adding elements to the system :
- Core Layer consists of tools for communication, data handling, distribute computing and low-level operating system functions (e.g., memory, threads and processes, I/O control).
- Component Layer specifies and implements useful frameworks to add components and to support domain-specific concepts.
- Application Layer contains useful tools to build and manage integrated applications using available components, to craft robotic systems.
Communication Protocol Abstraction
Component functionalities can often be used without any concerns with the communication protocols, as they are typically designed to apply operations and algorithms on data, independently of how data are received or sent. This eases components interoperability and reusability by avoiding fixing the communication protocol during the component design phase. Ideally, this choice should be made as late as possible, depending of which components need to be interconnected together (e.g., at the integration phase or even at runtime). Therefore, a communication abstraction framework, called Port, is provided for communication protocols and component’s interconnections.
Solution
How do we implement this?
By creating several modules which have a specific role in the overall application. The first part are the Application Adapters whom handle all the details of a specific external application which include the starting and stopping of the application and the data conversion. After this, the Application Adapters communicates together using a common data language. These communications can be handled by the Communication Adapters which implements several communication paradigms. All these modules are supervised by the Application Manager which delegate the communication part the one or several Communication Managers.
We also provide logging and debugging tools to ease these tasks.
