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

From The BABEL Development Site
(The XML database)
 
(14 intermediate revisions by the same user not shown)
Line 4: Line 4:
 
</table>
 
</table>
  
 +
__TOC__
  
= RPDs =
+
'''See also:'''
 +
* [[Architecture:RPD_Server| RPD_Server]]
 +
* [[Architecture:APP_Server| APP_Server]]
  
== Description ==
+
 
 +
 
 +
 
 +
= 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 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?  
Line 25: Line 31:
  
  
== The XML database ==
+
= The RPD database =
  
 
''BABEL modules developers will usually use only the services of [[Architecture:RPD_Server| RPD_Server]] and the [[Architecture:RPD_Server#RPD_Visual_Editor|Visual RPD editor]] application, so this section can be skipped.''
 
''BABEL modules developers will usually use only the services of [[Architecture:RPD_Server| RPD_Server]] and the [[Architecture:RPD_Server#RPD_Visual_Editor|Visual RPD editor]] application, so this section can be skipped.''
Line 37: Line 43:
 
=== 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 104: Line 72:
 
</xml>
 
</xml>
  
 +
=== Table: <code>selected_RPD</code> ===
 +
 +
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:'''
  
=== Table: <code>selected_RPD</code> ===
+
* <code>selected_robot</code>: An entry from the table RPD_list.
  
<P><BR><BR>
 
</P>
 
<CENTER>
 
<TABLE WIDTH=409 BORDER=1 BORDERCOLOR="#000000" CELLPADDING=7 CELLSPACING=0>
 
<TR>
 
<TD WIDTH=136 HEIGHT=2 BGCOLOR="#f3f3f3">
 
<P ALIGN=CENTER><FONT COLOR="#000080"><FONT SIZE=1 STYLE="font-size: 8pt">NAME
 
OF TABLE</FONT></FONT></P>
 
</TD>
 
<TD WIDTH=242>
 
<P ALIGN=CENTER><FONT FACE="Courier New, monospace"><FONT SIZE=1 STYLE="font-size: 8pt">selected_RPD</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
 
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.</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=12>
 
<P ALIGN=CENTER><FONT FACE="Courier New, monospace"><FONT SIZE=1 STYLE="font-size: 8pt">selected_robot</FONT></FONT></P>
 
</TD>
 
<TD WIDTH=242>
 
<P ALIGN=CENTER><FONT SIZE=1 STYLE="font-size: 8pt">An entry from
 
the table </FONT><FONT FACE="Courier New, monospace"><FONT SIZE=1 STYLE="font-size: 8pt">RPD_list</FONT></FONT><FONT SIZE=1 STYLE="font-size: 8pt">.</FONT></P>
 
</TD>
 
</TR>
 
</TABLE>
 
</CENTER>
 
<P><BR><BR>
 
</P>
 
  
 
'''Example:'''
 
'''Example:'''
Line 171: Line 96:
 
<br>
 
<br>
  
 +
=== Table <code> <robot_name>:global_params </code> ===
 +
 +
For each robot configuration listed in the table <code>RPD_list</code>,
 +
the following table must exist containing '''common parameters which may be accessed by more than one module'''.
 +
 +
The fields of this table are:
 +
* <code>param</code>: The name of the parameter.
 +
* <code>value</code>: Its value.
  
=== Table <code> <robot_name>:shape2D </code> ===
 
  
For each robot configuration listed in the table <code>RPD_list</code>,
+
There exists a few '''meta-parameters''', which are NOT actually written in the DB but are computed by the server on the fly:
the following table must exist containing geometric information about the robot.
 
  
The 2D shape will be used by the reactive navigation engine and also by 2D graphical displays.
+
* <code>robot_name</code>: The corresponding RPD. Recall that users will access to this table <robot_name>:global_params through the RPD_Server, without knowning the actual name of this table.
  
 +
* <code><module_name>:num_alias</code>: The number of aliases of a given module, computed from the number of existing tables <robot_name>:<module_name>:*
  
<P><BR><BR>
 
</P>
 
<CENTER>
 
<TABLE WIDTH=409 BORDER=1 BORDERCOLOR="#000000" CELLPADDING=7 CELLSPACING=0>
 
<TR>
 
<TD WIDTH=136 HEIGHT=2 BGCOLOR="#f3f3f3">
 
<P ALIGN=CENTER><FONT COLOR="#000080"><FONT SIZE=1 STYLE="font-size: 8pt">NAME
 
OF TABLE</FONT></FONT></P>
 
</TD>
 
<TD WIDTH=242>
 
<P ALIGN=CENTER><FONT FACE="Courier New, monospace"><FONT SIZE=1 STYLE="font-size: 8pt">&lt;robot_name&gt;:shape2D</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 FACE="Courier New, monospace"><FONT SIZE=1 STYLE="font-size: 8pt">&lt;robot_name&gt;</FONT></FONT><FONT SIZE=1 STYLE="font-size: 8pt">
 
stands for the actual robot name, from the table </FONT><FONT FACE="Courier New, monospace"><FONT SIZE=1 STYLE="font-size: 8pt">RPD_list.
 
</FONT></FONT><FONT SIZE=1 STYLE="font-size: 8pt">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.</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">x</FONT></FONT></P>
 
</TD>
 
<TD ROWSPAN=2 WIDTH=242>
 
<P ALIGN=CENTER><FONT SIZE=1 STYLE="font-size: 8pt">
 
The only record in this table contains an x and y vector of 2D points (in meters) such as
 
they build a closed polygon (i.e. an additional point is always added to close the polygon).
 
The reference system is the reference point of the robot mobile base, i.e. typically the mid-point
 
between the motor wheels.</FONT></P>
 
</TD>
 
</TR>
 
<TR>
 
<TD WIDTH=136 HEIGHT=12>
 
<P ALIGN=CENTER><FONT FACE="Courier New, monospace"><FONT SIZE=1 STYLE="font-size: 8pt">y</FONT></FONT></P>
 
</TD>
 
</TR>
 
</TABLE>
 
</CENTER>
 
  
 +
And the following is a list of the typical contents:
  
 +
* <code>shape_2D</code>: 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 ]
  
'''Example:'''
 
  
<xml>
 
  <table name="Sancho:shape2D">
 
    <fields>
 
      <x />
 
      <y />
 
    </fields>
 
    <record>
 
      <x> -0.30 -0.30 0.30  0.30 </x>
 
      <y> -0.20  0.20 0.20 -0.20 </y>
 
    </record>
 
  </table>
 
</xml>
 
  
 
<br>
 
<br>
  
 
<br>
 
<br>
 
 
  
 
=== Tables <code> <robot_name>:<module_name>:<module_alias> </code> ===
 
=== Tables <code> <robot_name>:<module_name>:<module_alias> </code> ===
Line 297: Line 161:
 
<br>
 
<br>
  
=== Table <code> <robot_name>:RPD_physical_devices</code> ===
 
  
<BR><BR>
 
  
<center><b>THIS TABLE IS NOT IMPLEMENTED YET!!!!!!</b></center>
+
= The APP database =
 +
 
 +
''BABEL modules developers will usually use only the services of [[Architecture:APP_Server| APP_Server]] and the [[Architecture:BABEL Configuration Manager|BABEL Configuration Manager]] application, so this section can be skipped.''
 +
 
 +
Any given application is stored in a single file database which should be named "BABEL_app_<NAME>.xml". 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].
 +
 
 +
 
 +
=== Table <code> global_params </code> ===
 +
 
 +
This table contains '''common parameters which may be accessed by more than one module'''.
 +
 
 +
The fields of this table are:
 +
* <code>param</code>: The name of the parameter.
 +
* <code>value</code>: 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:
 +
 
 +
* <code><module_name>:num_alias</code>: The number of aliases of a given module, computed from the number of existing tables <module_name>:*
  
<CENTER>
 
<TABLE WIDTH=409 BORDER=1 BORDERCOLOR="#000000" CELLPADDING=7 CELLSPACING=0>
 
<TR>
 
<TD WIDTH=136 HEIGHT=2 BGCOLOR="#f3f3f3">
 
<P ALIGN=CENTER><FONT COLOR="#000080"><FONT SIZE=1 STYLE="font-size: 8pt">NAME
 
OF TABLE</FONT></FONT></P>
 
</TD>
 
<TD WIDTH=242>
 
<P ALIGN=CENTER><FONT FACE="Courier New, monospace"><FONT SIZE=1 STYLE="font-size: 8pt"> &lt;robot_name&gt;:RPD_physical_devices</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 FACE="Courier New, monospace"><FONT SIZE=1 STYLE="font-size: 8pt">&lt;robot_name&gt;</FONT></FONT><FONT SIZE=1 STYLE="font-size: 8pt">
 
stands for the actual robot name, from the table </FONT><FONT FACE="Courier New, monospace"><FONT SIZE=1 STYLE="font-size: 8pt">RPD_list.
 
</FONT></FONT><FONT SIZE=1 STYLE="font-size: 8pt">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. </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">HAD_module</FONT></FONT></P>
 
</TD>
 
<TD WIDTH=242>
 
<P ALIGN=CENTER><FONT SIZE=1 STYLE="font-size: 8pt">The name of
 
the HAD layer module.</FONT></P>
 
</TD>
 
</TR>
 
<TR>
 
<TD WIDTH=136 HEIGHT=12>
 
<P ALIGN=CENTER><FONT FACE="Courier New, monospace"><FONT SIZE=1 STYLE="font-size: 8pt">opening_params</FONT></FONT></P>
 
</TD>
 
<TD WIDTH=242>
 
<P ALIGN=CENTER><FONT SIZE=1 STYLE="font-size: 8pt">A set of
 
lines with the format “param=value” each one, containing the
 
parameters to be supplied to the module in the
 
</FONT><FONT FACE="Courier New, monospace"><FONT SIZE=1 STYLE="font-size: 8pt">DRV_COMMON::open(·)</FONT></FONT><FONT SIZE=1 STYLE="font-size: 8pt">
 
BABEL service.</FONT></P>
 
</TD>
 
</TR>
 
</TABLE>
 
</CENTER>
 
  
<P><BR><BR>
+
And the following is a list of the typical contents:
</P>
 
  
=== Table <code> <robot_name>:RPD_logical_devices </code> ===
+
* ...
  
  
<center><b>THIS TABLE IS NOT IMPLEMENTED YET!!!!!!</b></center>
 
  
<CENTER>
+
<br>
<TABLE WIDTH=409 BORDER=1 BORDERCOLOR="#000000" CELLPADDING=7 CELLSPACING=0>
+
 
<TR>
+
<br>
<TD WIDTH=136 HEIGHT=2 BGCOLOR="#f3f3f3">
+
 
<P ALIGN=CENTER><FONT COLOR="#000080"><FONT SIZE=1 STYLE="font-size: 8pt">NAME
+
=== Tables <code> <module_name>:<module_alias> </code> ===
OF TABLE</FONT></FONT></P>
+
 
</TD>
+
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:
<TD WIDTH=242>
+
 
<P ALIGN=CENTER><FONT FACE="Courier New, monospace"><FONT SIZE=1 STYLE="font-size: 8pt">&lt;robot_name&gt;:RPD_logical_devices</FONT></FONT></P>
+
* <code> <module_name> </code>: The name of the module, for example "HAD_GPS".
</TD>
+
* <code> <module_alias> </code>: 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.
</TR>
+
 
<TR>
+
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.
<TD WIDTH=136 HEIGHT=3 BGCOLOR="#f3f3f3">
+
 
<P ALIGN=CENTER><FONT COLOR="#000080"><FONT SIZE=1 STYLE="font-size: 8pt">DESCRIPTION
+
Modules at run-time can retrieve this information by calling <code>getSettingsForModule</code> from the [[Architecture:APP_Server|APP_Server module]].
OF TABLE</FONT></FONT></P>
+
 
</TD>
+
Each of these tables contains only one record with only one field named <code>config</code>.
<TD WIDTH=242>
+
 
<P ALIGN=CENTER><FONT FACE="Courier New, monospace"><FONT SIZE=1 STYLE="font-size: 8pt">&lt;robot_name&gt;</FONT></FONT><FONT SIZE=1 STYLE="font-size: 8pt">
+
'''Example:'''
stands for the actual robot name, from the table </FONT><FONT FACE="Courier New, monospace"><FONT SIZE=1 STYLE="font-size: 8pt">RPD_list.
+
 
</FONT></FONT><FONT SIZE=1 STYLE="font-size: 8pt">This table
+
<xml>
lists the logical devices of the robot, that is, the actual list
+
  <table name="Test_Module:0">
of elements building the sensory and motor system of the robot,
+
    <fields>
as well as their spatial position, physical connections between
+
      <config />
them and HAD layer modules required to access them. </FONT>
+
    </fields>
</P>
+
    <record>
</TD>
+
      <config>
</TR>
+
      // This is a configuration block for my module
<TR>
+
      [locate]
<TD WIDTH=136 HEIGHT=3 BGCOLOR="#f3f3f3">
+
      max_speed = 2.3
<P ALIGN=CENTER><FONT COLOR="#000080"><FONT SIZE=1 STYLE="font-size: 8pt">FIELDS</FONT></FONT></P>
+
     
</TD>
+
      </config>
<TD WIDTH=242 BGCOLOR="#f3f3f3">
+
    </record>
<P ALIGN=CENTER><FONT COLOR="#000080"><FONT SIZE=1 STYLE="font-size: 8pt">FIELD
+
  </table>
DESCRIPTIONS</FONT></FONT></P>
+
</xml>
</TD>
+
 
</TR>
+
<br>
<TR>
+
 
<TD WIDTH=136 HEIGHT=13>
+
<br>
<P ALIGN=CENTER><FONT FACE="Courier New, monospace"><FONT SIZE=1 STYLE="font-size: 8pt">id</FONT></FONT></P>
 
</TD>
 
<TD WIDTH=242>
 
<P ALIGN=CENTER><FONT SIZE=1 STYLE="font-size: 8pt">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.</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">type</FONT></FONT></P>
 
</TD>
 
<TD WIDTH=242>
 
<P ALIGN=CENTER><FONT SIZE=1 STYLE="font-size: 8pt">The logical
 
device type, as specified in the table </FONT><FONT FACE="Courier New, monospace"><FONT SIZE=1 STYLE="font-size: 8pt">logical_device_types</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">isChainingPoint</FONT></FONT></P>
 
</TD>
 
<TD WIDTH=242>
 
<P ALIGN=CENTER>“<FONT SIZE=1 STYLE="font-size: 8pt">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.</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">idOfBase</FONT></FONT></P>
 
</TD>
 
<TD WIDTH=242>
 
<P ALIGN=CENTER><FONT SIZE=1 STYLE="font-size: 8pt">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.</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">x</FONT></FONT></P>
 
</TD>
 
<TD ROWSPAN=6 WIDTH=242>
 
<P ALIGN=CENTER><FONT SIZE=1 STYLE="font-size: 8pt">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. </FONT>
 
</P>
 
<P ALIGN=CENTER><FONT SIZE=1 STYLE="font-size: 8pt">This allows
 
sensors mounted on PTUs, servos or robotic arms to be correctly
 
localized automatically.</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">y</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">z</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">yaw</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">pitch</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">roll</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">implementation</FONT></FONT></P>
 
</TD>
 
<TD WIDTH=242>
 
<P ALIGN=CENTER><FONT SIZE=1 STYLE="font-size: 8pt">The name of
 
the HAD module where the required driver is implemented. Is this
 
is a “chaining point”, the “</FONT><FONT FACE="Courier New, monospace"><FONT SIZE=1 STYLE="font-size: 8pt">DRV_MOBILE_JOINT</FONT></FONT><FONT SIZE=1 STYLE="font-size: 8pt">”
 
interface is assumed as well.</FONT></P>
 
</TD>
 
</TR>
 
<TR>
 
<TD WIDTH=136 HEIGHT=12>
 
<P ALIGN=CENTER><FONT FACE="Courier New, monospace"><FONT SIZE=1 STYLE="font-size: 8pt">options</FONT></FONT></P>
 
</TD>
 
<TD WIDTH=242>
 
<P ALIGN=CENTER><FONT SIZE=1 STYLE="font-size: 8pt">A list of
 
strings with the fomat “option=value” each one, where the
 
option names are stored in the table </FONT><FONT SIZE=1 STYLE="font-size: 8pt"><I>logical_device_types</I></FONT><FONT SIZE=1 STYLE="font-size: 8pt">
 
for this device </FONT><FONT SIZE=1 STYLE="font-size: 8pt"><I>type</I></FONT><FONT SIZE=1 STYLE="font-size: 8pt">.</FONT></P>
 
</TD>
 
</TR>
 
</TABLE>
 
</CENTER>
 

Latest revision as of 09:42, 29 May 2009

Previous: Modules Next: Data Types

See also:



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

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:

  • 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 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>




The APP database

BABEL modules developers will usually use only the services of APP_Server and the BABEL Configuration Manager application, so this section can be skipped.

Any given application is stored in a single file database which should be named "BABEL_app_<NAME>.xml". Currently the format of this database is the simple structure defined by the MRPT C++ library in the class mrpt::utils::CSimpleDatabase.


Table global_params

This table contains 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:

  • <module_name>:num_alias: The number of aliases of a given module, computed from the number of existing tables <module_name>:*


And the following is a list of the typical contents:

  • ...




Tables <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:

  • <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 APP_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 my module [locate] max_speed = 2.3 </config> </record>

</xml>