MRT

Modular Robotic Toolkit

Introduction

This is the Modular Robotic Toolkit user manual, a comprehensive guide to the software architecture for autonomous robots developed by the AIRLab, Artificial Intelligence and Robotic Laboratory of the Dept. of Electronics and Information at Politecnico di Milano.

Most of the content of these pages comes from a cleanup (under construction) of the MRT manual written by Luigi Malago'. These WIKI pages are intended for continuous update and completion. Anybody wishing to cooperate is welcome!

MRT, Modular Robotic Toolkit, is a framework where a set of off-the-shelf modules can be easily combined and customized to realize robotic applications with minimal effort and time. The framework has been designed to be used in different applications where a distributed set of robot and sensors interact to accomplish tasks, such as: playing soccer in RoboCup, guiding people in indoor environments, and exploring unknown environments in a space setting.

The aim of this manual is to present the software architecture and make the user comfortable with the use and configuration of the different modules that can be integrated in the framework, so that it will be easy to develop robotic applications using MRT. For this reason, each chapter will include some examples of code and configuration files.

MRT Architecture

The MRT architecture is described in the paper published on the Springer STAR Series.

DCDT: The Middleware

DCDT, Device Communities Development Toolkit, is the framework used to integrate all the modules in MRT. This middleware has been implemented to simplify the development of applications where different tasks run si- multaneously and need to exchange messages. DCDT is a publish/sub- scribe framework able to exploit different physical communication means in a transparent and easy way.

The use of this toolkit helps the user dealing with processes and inter process communication, since it makes the interaction between the processes transparent with respect to their allocation. This means that the user does not have to take care whether the processes run on the same machine or on a distributed environment.

DCDT is a multi-threaded architecture consisting in a main active ob- ject, called Agora, hosting and managing various software modules, called Members. Members are basically concurrent programs/threads executed pe- riodically or on the notification of an event. Each Member of the Agora can exchange messages with other Members of the same Agora or with other Agoras on different machines.

The peculiar attitude of DCDT toward different physical communication channels, such as RS-232 serial connections, USB, Ethernet or IEEE 802.11b, is one of the main characteristics of this publish/subscribe middleware.

Agora and Members

An Agora is a process composed of more threads and data structures required to manage processes and messages. Each single thread, called Member in the DCDT terminology, is responsible for the execution of an instance of an object derived from the DCDT Member class. It is possible to realize distributed applications running different Agoras on different devices/machines, each of them hosting many Members. It is also possible to have on the same machine more than one Agora that hosts its own Members. In this way you can emulate the presence of different robots without the need of actually having them connected and running. There are two different type of Members, User Members and System Members. The main difference between the two is that System Members are responsible for the management of the infrastructure of the data structures of the Agora, while User Members are implemented by the user according to his needs. Moreover System Member are invisible to User Members.

The main System Members are:

• Finder: it is responsible for searching for other Agoras on local and

remote machines dynamically with short messages via multicast;

• MsgManager: this Member manages all the messages that are exchanged

along several members. In case each single Member handles its own message queue locally, the MsgManager takes care of moving messages from the main queue to the correct one;

• InnerLinkManager: its role is to arrange inter Agora communication

in case they are executed on the same machine;

• Link: those Members handle communication channels between two

Agoras, so that they messages can be exchanged. Each link is responsible for the communication flow in one direction, so there are separate Members for message receiving and sending;

Members of the Agora can exchange messages through the PostOffice, using a typical a publish/subscribe approach. Each Member can subscribe to the PostOffice of its Agora for a specific type of messages. Whenever a Member wants to publish a message, it has to notify the PostOffice, without taking into accont the final destinations of the deliveries.

Messages

DCDT Messages are characterized by header and payload fields. The header contains the unique identifier of the message type, the size of the data contained in the payload and some information regarding the producer. Members use unique identification types to subscribe and unsubscribe messages available throughout the community. Messages can be shared basically according to three modalities: without any guaranty (e.g. UDP), with some retransmissions (e.g. UDP retransmitted), with absolute receipt guaranty (e.g. TCP).

Sometimes the payload of a Message can be empty. For example you can use Messages to notify events, in this case the only information is the specific event that matches a particular Message type. This implies that all the Agoras must share the same list of Message types. In MRT, the interfaces among different modules are realized through messages. According to the publish/subscribe paradigm, each module may produce messages that are received by those modules that have expressed interest in them. In order to grant independence among modules, each module knows neither which modules will receive its messages nor the senders of the messages it has requested. In fact, typically, it does not matter which module has produced an information, since modules are interested in the information itself.

For instance, the localization module may benefit from knowing that in front of the robot there is a wall at the distance of 2.4 m, but it is not relevant which sensors has perceived this information or whether this is coming from another robot. For this reason, our modules communicate through XML (eXtensible Markup Language) messages whose structure is defined by a shared DTD (Document Type Definitions). Each message contains some general information, such as the time-stamp, and a list of objects characterized by a name and its membership class. For each object may be defined a number of attributes, that are tuples of name, value, variability, and reliability. In order to correctly parse the content of the messages, modules share a common ontology that defines the semantic of the used symbols.

The advantages of using XML messages, instead of messages in a binary format, are: the possibility of being readable by humans and of being edited by any text editor, well-structured by the use of DTDs, easy to change and extend, the existence of standard modules for the syntactic parsing. These advantages are paid by an increase in the amount of transferred data, parsing may need more time, binary data can not be included directly. The middleware encapsulates all the functionalities to handle Members and Messages in the Agora, so that the user does not have to take care of executing each single thread neither handling message delivery. This results in making the use of this middleware very easy.

Configuration Files and Examples

The Agora is the main object instantiated in every application that makes use of DCDT. Each Agora is composed of threads, called Members, that execute specific tasks and communicate through messages. The Agora can be instantiated using two different options called STANDALONE and NETWORK, according to the physical distribution of the Members. If you want Members to exchange messages from different machines, you need to use the NETWORK option, otherwise you can use the STANDALONE. Both allow the communication along Members of the same Agora and between Agoras on the same machine.

MAP Anchors Percepts

Paper about the concepts supported by MAP.

MUREA: Multi-Resolution Evidence Accumulation

MUREA, MUlti-Resolution Evidence Accumulation, is a module that im- plements a localization algoritm.

This module has several configurable parameters that allow its reuse in different context, e.g., the map of the environment, the required accuracy, a timeout.

MUREA completely abstracts from the sensors used for acquiring localization information, since its interface relies on the concept or perception, which is shared with the processing sub-module of each sensor