Architecture:The RPD and APP databases

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.

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