Architecture:The RPD and APP databases
| Previous: Modules | Next: Data Types |
Contents
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.
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 tableRPD_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>
