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

From The BABEL Development Site
(The XML database)
(Table: RPD_list)
Line 35: Line 35:
 
=== Table: <code>RPD_list</code> ===
 
=== Table: <code>RPD_list</code> ===
  
<CENTER>
+
This table enumerates all defined RPDs in the database: one per robotic platform (physical or simulated robots)
<TABLE WIDTH=409 BORDER=1 BORDERCOLOR="#000000" CELLPADDING=7 CELLSPACING=0>
+
 
<TR>
+
'''Fields: '''
<TD WIDTH=136 HEIGHT=2 BGCOLOR="#f3f3f3">
+
 
<P ALIGN=CENTER><FONT COLOR="#000080"><FONT SIZE=1 STYLE="font-size: 8pt">NAME
+
* <code>robot_name</code>: The name of the robotic platform.
OF TABLE</FONT></FONT></P>
+
 
</TD>
 
<TD WIDTH=242>
 
<P ALIGN=CENTER><FONT FACE="Courier New, monospace"><FONT SIZE=1 STYLE="font-size: 8pt">RPD_list</FONT></FONT></P>
 
</TD>
 
</TR>
 
<TR>
 
<TD WIDTH=136 HEIGHT=3 BGCOLOR="#f3f3f3">
 
<P ALIGN=CENTER><FONT COLOR="#000080"><FONT SIZE=1 STYLE="font-size: 8pt">DESCRIPTION
 
OF TABLE</FONT></FONT></P>
 
</TD>
 
<TD WIDTH=242>
 
<P ALIGN=CENTER><FONT SIZE=1 STYLE="font-size: 8pt">This table
 
enumerates all defined RPDs in the database: one per robotic
 
platform (physical or simulated robots)</FONT></P>
 
</TD>
 
</TR>
 
<TR>
 
<TD WIDTH=136 HEIGHT=3 BGCOLOR="#f3f3f3">
 
<P ALIGN=CENTER><FONT COLOR="#000080"><FONT SIZE=1 STYLE="font-size: 8pt">FIELDS</FONT></FONT></P>
 
</TD>
 
<TD WIDTH=242 BGCOLOR="#f3f3f3">
 
<P ALIGN=CENTER><FONT COLOR="#000080"><FONT SIZE=1 STYLE="font-size: 8pt">FIELD
 
DESCRIPTIONS</FONT></FONT></P>
 
</TD>
 
</TR>
 
<TR>
 
<TD WIDTH=136 HEIGHT=13>
 
<P ALIGN=CENTER><FONT FACE="Courier New, monospace"><FONT SIZE=1 STYLE="font-size: 8pt">robot_name</FONT></FONT></P>
 
</TD>
 
<TD WIDTH=242>
 
<P ALIGN=CENTER><FONT SIZE=1 STYLE="font-size: 8pt">The name of
 
the robotic platform.</FONT></P>
 
</TD>
 
</TR>
 
</TABLE>
 
</CENTER>
 
<P><BR><BR>
 
</P>
 
  
 
'''Example:'''
 
'''Example:'''
Line 101: Line 63:
 
   </table>
 
   </table>
 
</xml>
 
</xml>
 
 
  
 
=== Table: <code>selected_RPD</code> ===
 
=== Table: <code>selected_RPD</code> ===

Revision as of 09:14, 29 May 2009

Previous: Modules Next: Data Types


RPD 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 RPD 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.

Table: RPD_list

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

Fields:

  • robot_name: The name of the robotic platform.


Example:

<xml>

<fields> <robot_name /> </fields> <record> <robot_name>SENA</robot_name> </record> <record> <robot_name>Sancho</robot_name> </record> <record> <robot_name>Picasso</robot_name> </record> <record> <robot_name>SimRobot</robot_name> </record>

</xml>

Table: selected_RPD



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.



Example:

<xml>

<fields> <selected_robot /> </fields> <record> <selected_robot>Picasso</selected_robot> </record>

</xml>



Table <robot_name>:global_params

For each robot configuration listed in the table RPD_list, the following table must exist containing common parameters which may be accessed by more than one module.

The fields of this table are:

  • param: The name of the parameter.
  • value: Its value.


There exists a few meta-parameters, which are NOT actually written in the DB but are computed by the server on the fly:

  • robot_name: The corresponding RPD. Recall that the users will access to this table <robot_name>:global_params through the RPD_Server, without knowning the actual name of this table.
  • <module_name>:num_alias: The number of aliases of a given module, computed from the number of existing tables <robot_name>:<module_name>:*


And the following is a list of the typical contents:

  • shape_2D: The 2D shape, which will be used by the reactive navigation engine and also by 2D graphical displays. It's a 2xN matrix in MATLAB format, X and Y being the first and second row, respectively. Example:
shape_2D = [ -0.30 -0.30 0.30  0.30; -0.20  0.20 0.20 -0.20 ]




Tables <robot_name>:<module_name>:<module_alias>

Each of these tables contains essential information for BABEL modules to properly initialize when executed under each specific robot. The name of the table is composed of:

  • <robot_name> : One of the robot configuration listed in the table RPD_list.
  • <module_name> : The name of the module, for example "HAD_GPS".
  • <module_alias> : An integer number for the "alias" of the module, starting at 0. Modules with only one "internal instance" or those where "alias" are not applicable must have this set to "0". This field is mainly intended for sensors, where several devices may be connected to the robot and thus only one module may have several "internal alias", each one dealing with one device.

The contents of each of these tables is a ".ini"-like configuration text block, which must replace any external configuration files needed by the modules.

Modules at run-time can retrieve this information by calling getSettingsForModule from the RPD_Server module.

Each of these tables contains only one record with only one field named config.

Example:

<xml>

<fields> <config /> </fields> <record> <config> // This is a configuration block for HAD_GPS [gps] COM_port = COM1 baud_rate = 9600 </config> </record>

</xml>




Table <robot_name>:RPD_logical_devices

THIS TABLE IS NOT IMPLEMENTED YET!!!!!!

NAME OF TABLE

<robot_name>:RPD_logical_devices

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.