Difference between revisions of "Architecture:The RPD and APP databases"

From The BABEL Development Site
(RPDs)
(The XML database)
Line 29: Line 29:
 
''BABEL modules developers will usually use only the services of RPD_Server and the Visual RPD editor application, so this section can be skipped.''
 
''BABEL modules developers will usually use only the services of RPD_Server and the Visual RPD editor application, so this section can be skipped.''
  
RPDs for all robotic platforms, together with the required information about modules, are stored in a single file database (“roboticPlatformDescriptors.db”). Currently the format of this database is the simple structure defined by the MRPT C++ library  in the class <code>mrpt::utils::CSimpleDatabase</code>. Next we enumerate the existing tables in this database, describe its fields and how they are used. Note that all these specifications are only needed to programmers of the RPD_Server module and the Visual RPD Editor, since all other modules directly use the BABEL services of RPD_Server and do not deal with the database file at all.  
+
RPDs for all robotic platforms, together with the required information about modules, are stored in a single file database (“roboticPlatformDescriptors.db”). Currently the format of this database is the simple structure defined by the MRPT C++ library  in the class [http://babel.isa.uma.es/mrpt/reference/svn/classmrpt_1_1utils_1_1_c_simple_database.html mrpt::utils::CSimpleDatabase].  
 +
 
 +
Next we enumerate the existing tables in this database, describe its fields and how they are used. Note that all these specifications are only needed to programmers of the RPD_Server module and the Visual RPD Editor, since all other modules directly use the BABEL services of RPD_Server and do not deal with the database file at all.  
  
 
Next the general tables are specified. These tables will always be present, independently of the number of RPDs.  
 
Next the general tables are specified. These tables will always be present, independently of the number of RPDs.  
Line 35: Line 37:
 
<CENTER>
 
<CENTER>
 
<TABLE WIDTH=409 BORDER=1 BORDERCOLOR="#000000" CELLPADDING=7 CELLSPACING=0>
 
<TABLE WIDTH=409 BORDER=1 BORDERCOLOR="#000000" CELLPADDING=7 CELLSPACING=0>
<COL WIDTH=136>
 
<COL WIDTH=242>
 
 
<TR>
 
<TR>
 
<TD WIDTH=136 HEIGHT=2 BGCOLOR="#f3f3f3">
 
<TD WIDTH=136 HEIGHT=2 BGCOLOR="#f3f3f3">
Line 83: Line 83:
 
<CENTER>
 
<CENTER>
 
<TABLE WIDTH=409 BORDER=1 BORDERCOLOR="#000000" CELLPADDING=7 CELLSPACING=0>
 
<TABLE WIDTH=409 BORDER=1 BORDERCOLOR="#000000" CELLPADDING=7 CELLSPACING=0>
<COL WIDTH=136>
 
<COL WIDTH=242>
 
 
<TR>
 
<TR>
 
<TD WIDTH=136 HEIGHT=2 BGCOLOR="#f3f3f3">
 
<TD WIDTH=136 HEIGHT=2 BGCOLOR="#f3f3f3">
Line 138: Line 136:
 
<CENTER>
 
<CENTER>
 
<TABLE WIDTH=409 BORDER=1 BORDERCOLOR="#000000" CELLPADDING=7 CELLSPACING=0>
 
<TABLE WIDTH=409 BORDER=1 BORDERCOLOR="#000000" CELLPADDING=7 CELLSPACING=0>
<COL WIDTH=136>
 
<COL WIDTH=242>
 
 
<TR>
 
<TR>
 
<TD WIDTH=136 HEIGHT=2 BGCOLOR="#f3f3f3">
 
<TD WIDTH=136 HEIGHT=2 BGCOLOR="#f3f3f3">
Line 202: Line 198:
 
<CENTER>
 
<CENTER>
 
<TABLE WIDTH=409 BORDER=1 BORDERCOLOR="#000000" CELLPADDING=7 CELLSPACING=0>
 
<TABLE WIDTH=409 BORDER=1 BORDERCOLOR="#000000" CELLPADDING=7 CELLSPACING=0>
<COL WIDTH=136>
 
<COL WIDTH=242>
 
 
<TR>
 
<TR>
 
<TD WIDTH=136 HEIGHT=2 BGCOLOR="#f3f3f3">
 
<TD WIDTH=136 HEIGHT=2 BGCOLOR="#f3f3f3">
Line 352: Line 346:
 
<CENTER>
 
<CENTER>
 
<TABLE WIDTH=409 BORDER=1 BORDERCOLOR="#000000" CELLPADDING=7 CELLSPACING=0>
 
<TABLE WIDTH=409 BORDER=1 BORDERCOLOR="#000000" CELLPADDING=7 CELLSPACING=0>
<COL WIDTH=136>
 
<COL WIDTH=242>
 
 
<TR>
 
<TR>
 
<TD WIDTH=136 HEIGHT=2 BGCOLOR="#f3f3f3">
 
<TD WIDTH=136 HEIGHT=2 BGCOLOR="#f3f3f3">

Revision as of 22:04, 17 May 2009

Previous: Modules Next: Data Types


RPDs

Description

The Robotic Platform Descriptors (RPDs) address two problems of the robotic software: which parts do constitute the body of the robot, and how are they disposed spatially?. For example: how many devices of each type are attached to the robot? Where are they? If the head is turned to a given direction, where the cameras are pointing to?

The RPD aims to solve these questions for modules in run-time. We define the RPD for a specific robot as the set of logical devices constituting that robot, their descriptions and their physical disposition on the robot. Some logical device types we consider are: sonar, infrared or laser sensors, wheels based mobile bases, cameras, PTUs or robotic arms.

From our experience we know the usefulness of portable robotic applications, which can be executed on different robots. In these cases a part of the application will remain unchanged (high-level functions), while low-level, hardware dependant modules must be interchanged in the porting process. Now a given robotic platform is totally specifically by its RPD, which also specifies the low-level modules required for executing any application in that robot. Therefore, we store a diversity of such RPDs in a database, where additional information about low-level modules (HAD layer) is also kept.

RPD overview.png

Fig. Robotic Platform Descriptors (RPDs) play the central role in the representation of the robot itself and its sensory and motor elements. In the figure the main concepts stored in this database are summarized. Refer to the text for further explanation.


The RPDs is stored in a file in a database format. A design-time visual application (Visual_RPD_editor) allows us to visualize and change this database easily. It can be used, for example, to specify the addition of new sensors to a robot. This database is read in execution-time by the BABEL module RPD_Server, which did not appear in Error: Reference source not found, but acts as a server of information about the robotics platform for the rest of modules. Next we formally specify the database format.


The XML database

BABEL modules developers will usually use only the services of RPD_Server and the Visual RPD editor application, so this section can be skipped.

RPDs for all robotic platforms, together with the required information about modules, are stored in a single file database (“roboticPlatformDescriptors.db”). Currently the format of this database is the simple structure defined by the MRPT C++ library in the class mrpt::utils::CSimpleDatabase.

Next we enumerate the existing tables in this database, describe its fields and how they are used. Note that all these specifications are only needed to programmers of the RPD_Server module and the Visual RPD Editor, since all other modules directly use the BABEL services of RPD_Server and do not deal with the database file at all.

Next the general tables are specified. These tables will always be present, independently of the number of RPDs.

NAME OF TABLE

RPD_list

DESCRIPTION OF TABLE

This table enumerates all defined RPDs in the database: one per robotic platform (physical or simulated robots)

FIELDS

FIELD DESCRIPTIONS

robot_name

The name of the robotic platform.





NAME OF TABLE

selected_RPD

DESCRIPTION OF TABLE

This table holds only one record, with the name of the currently selected robotic platform (or “robot”). This is checked at run-time to determine which RPD is to be read.

FIELDS

FIELD DESCRIPTIONS

selected_robot

An entry from the table RPD_list.





For each robot configuration listed in the table RPD_list, the following tables must be also inserted in the database. They therefore represent the part of the database which can be customized to specify concrete information about robots.



NAME OF TABLE

RPD_physical_devices_<robot_name>

DESCRIPTION OF TABLE

<robot_name> stands for the actual robot name, from the table RPD_list. This table lists the physical devices attached to the robot. It can be used to determine the HAD layer modules which must be executed in the robotic application. This table is also used to enter the parameters to those modules for the specific case of this robotic platform.

FIELDS

FIELD DESCRIPTIONS

HAD_module

The name of the HAD layer module.

opening_params

A set of lines with the format “param=value” each one, containing the parameters to be supplied to the module in the DRV_COMMON::open(·) BABEL service.



NAME OF TABLE

RPD_logical_devices_<robot_name>

DESCRIPTION OF TABLE

<robot_name> stands for the actual robot name, from the table RPD_list. This table lists the logical devices of the robot, that is, the actual list of elements building the sensory and motor system of the robot, as well as their spatial position, physical connections between them and HAD layer modules required to access them.

FIELDS

FIELD DESCRIPTIONS

id

A numerical index, starting from 0, which can be used as index for devices (0,1,2,3,…). Typically the robotic mobile base is the element with id=0.

type

The logical device type, as specified in the table logical_device_types

isChainingPoint

1” or “0” depending on this element allowing (or not) other elements to be physically attached to it. Most elements do not, but for example, PTU or robotic arms can be used in this way. A “1” in this field allows other devices to set this one as their basePoint.

idOfBase

The numerical id of the physical device acting as the reference for the 3D-pose of this one. Typically the base id=0 (mobile base) is used as reference.

x

The 3D pose of this device, using the reference of the pose of the base element specified in “idOfBase”. If this base is “a chaining point”, the exact pose to be used is not the one of that base element, but a relative displacement found through the DRV_MOBILE_JOINT interface.

This allows sensors mounted on PTUs, servos or robotic arms to be correctly localized automatically.

y

z

yaw

pitch

roll

implementation

The name of the HAD module where the required driver is implemented. Is this is a “chaining point”, the “DRV_MOBILE_JOINT” interface is assumed as well.

options

A list of strings with the fomat “option=value” each one, where the option names are stored in the table logical_device_types for this device type.



NAME OF TABLE

RPD_shape2D_<robot_name>

DESCRIPTION OF TABLE

<robot_name> stands for the actual robot name, from the table RPD_list. This table gives a simple 2D shape of the robot, which can be used for visual display or obstacle avoidance purposes. Notice that this description is static as it does not change with possible mobile parts of the robot.

FIELDS

FIELD DESCRIPTIONS

x

Each record in this table defines a 2D point (x,y) in meters, such as they build a closed polygon. The reference system is the reference point of the robot mobile base, i.e. typically the mid-point between the motor wheels.

y