Difference between revisions of "MRT"

Revision as of 21:25, 28 April 2009

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.

MrBrian: Multilevel Ruling Brian Reacts by Inferential ActioNs

The Behavior-based Paradigm

The Overall Architecture

Fuzzy predicates

CANDO and WANT Conditions

Informed Hierarchical Composition

Output Generation

Modules

Fuzzyfier

Preacher

Predicate Actions

Candoer

Wanter

Behavior Engine

Rules Behavior

Composer

Defuzzyfier

Parser and Messenger

Configuration Files and Examples

Fuzzy Sets

Fuzzy Predicates

Predicate Actions

CANDO and WANT Conditions

Playing with activations TODO

Defuzzyfication

Behavior Rules

Behavior List

Behavior Composition

Parser and Messenger

Using Mr. BRIAN

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.

Agora

Different Agoras can communicate on the same machine through local sockets, this simple code fragment shows how you can instantiate an Agora using the STANDALONE option.

int main (int argc, char *argv[]) {

DCDT_Agora *agora;

agora = new DCDT_Agora();

.... }

Otherwise you can create an Agora using the NETWORK option. In this case you need to write a configuration file with all the network parameters required to allow communication between the different machines where the Agoras are executed. The following code lines show the use of the overloaded constructor that takes the configuration file as parameter. int main (int argc, char *argv[]) { DCDT_Agora *agora; agora = new DCDT_Agora("dcdt.cfg"); .... } The configuration file for the Agora includes the following information: • network parameters of the machine: these parameters define the TCP/IP address and the port of the Agora, plus the multicast address of the local network; 20 • policy of the PostOffice: this parameter define the behavior of the PostOffice, so far three different policies have been implemented: – SLWB: Single Lock With Buffer; – SLWDWCV: Single Lock With DispatcherWith Conditional Variable; – SLWSM: Single Lock With Single Message; [—-Queste voci sopra andrebbero spiegate meglio ma c’ da cercare dove sono state documentate——-] • list of the available communication channels: this is a list of static links to other Agoras, using different physical communication channels, such as: – RS-232 serial connections; – TCP/IP network addresses You can use the DCDT framework also in dynamic environment when the addresses of the machines are not known a priori, in this case the Finder Member of the Agora can use the multicast address to search for other Agoras on the local network. When the Agoras belong to different networks the multicast address and the Finder are useless. In this case the communication involves directly the Members, as it will be described below. [——-INIZIO parte da rivedere (continua fino a FINE parte da rivedere)— —– questa parte va rivista a tavolino con matteo, perch ci ono delle cose che non vanno. es: non chiaro cosa si intende con memeberche che iteragiscono ”directly”. vanno spiegati meglio i thread LinkRx e LinkTx. va spieato meglio la differenza tra link e bridge. quando si dice the tutti i messaggi vengono transmitted, non viene detto dove. e la questione del level va chiarita.——–] In Figure 3.2 you can see an example of three different types of communications among Agoras. Agora1, Agora2 and Agora3 are executed on the same computer, so they can exchange messages through the InnerLinkerManager that handles the communication when the Agoras reside on the same machine; Agoras1 and Agora4 belong to the same network and the Finder is responsible for searching for other Agoras on different machines dynamically; Agora4 and Agora5 belong to different networks, so the communication involves the Members directly. [——– che cosa sono i moduli LinkRx e LinkTx? Non sono mai stati menzionati prima...——-] For each communication channel, you need to determine whether the local node acts as a link or as a bridge. In the first case only the messages generated locally will be sent to other Agoras, in the second case the node

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

SCARE Coordinates Agents in Robotic Environments

SPIKE Plans In Known Environments