Difference between revisions of "Architecture:Specification of BABEL Interfaces"
m (Protected "Architecture:Specification of BABEL Interfaces" [edit=autoconfirmed:move=autoconfirmed]) |
(→Interfaces) |
||
| Line 6: | Line 6: | ||
= Interfaces = | = Interfaces = | ||
| + | |||
| + | == Overview == | ||
| + | |||
| + | In this page we present a number of '''standardized interfaces''' (IFs) for each layer of modules in our architecture. One given module may implement only one or several such interfaces simultaneously, a specially common case in the HAD layer. | ||
| + | |||
| + | Each interface is implemented in one and only one '''BABEL service groups''', whose services are specified here. | ||
| + | Data types are given in the standard BABEL description language (BDL), with some small additions declared under the namespace BABEL::COMMON, | ||
| + | as shown in [[Architecture:Data_Types| this Appendix]]. | ||
| + | |||
| + | The input parameter "devIndex" deserves more discussion, since it solves the problem of '''multiple copies of hardware devices''' with just one software module. | ||
| + | This parameter is a zero-based index which specifies which device is being referenced for each access. The number of different devices is stored in the RPD (see section 4). Only modules in layers 2 and 3 are supposed to know about this parameter, so high-level modules never need to worry about how many hardware devices are present on the robot. | ||
| + | |||
| + | Please, developers of HAD modules are encouraged to '''do implement support for "devIndex"'''. For example, at module start-up, the RPD may be checked to discover how many devices are present on the robot and what are they parameters (configuration ".ini"-like text block). An internal list of objects can be hold within the BABEL module, one for each physical device, so each request is directed to the appropriate device. | ||
| + | |||
| + | |||
| + | == == | ||
Revision as of 22:25, 17 May 2009
| Previous: Overview | Next: Modules |
Interfaces
Overview
In this page we present a number of standardized interfaces (IFs) for each layer of modules in our architecture. One given module may implement only one or several such interfaces simultaneously, a specially common case in the HAD layer.
Each interface is implemented in one and only one BABEL service groups, whose services are specified here. Data types are given in the standard BABEL description language (BDL), with some small additions declared under the namespace BABEL::COMMON, as shown in this Appendix.
The input parameter "devIndex" deserves more discussion, since it solves the problem of multiple copies of hardware devices with just one software module. This parameter is a zero-based index which specifies which device is being referenced for each access. The number of different devices is stored in the RPD (see section 4). Only modules in layers 2 and 3 are supposed to know about this parameter, so high-level modules never need to worry about how many hardware devices are present on the robot.
Please, developers of HAD modules are encouraged to do implement support for "devIndex". For example, at module start-up, the RPD may be checked to discover how many devices are present on the robot and what are they parameters (configuration ".ini"-like text block). An internal list of objects can be hold within the BABEL module, one for each physical device, so each request is directed to the appropriate device.
