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.

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