Architecture:Motivation - Revision history

Jlblanco: /* Motivation */

2009-05-17T21:42:59Z

‎Motivation

Jlblanco at 14:45, 17 May 2009

2009-05-17T14:45:56Z

Jlblanco at 14:45, 17 May 2009

2009-05-17T14:45:39Z

Jlblanco at 14:45, 17 May 2009

2009-05-17T14:45:18Z

Jlblanco at 14:45, 17 May 2009

2009-05-17T14:45:01Z

Jlblanco at 14:43, 17 May 2009

2009-05-17T14:43:29Z

Jlblanco: New page: Back to : Architecture index
= Motivation = Distributed, multi-modules robotics applications are currently built in the System and Aut...

2009-05-17T14:41:06Z

New page: Back to : Architecture index = Motivation = Distributed, multi-modules robotics applications are currently built in the System and Aut...

New page

Back to : [[MAPIR's_Module_Architecture|Architecture index]] 

= Motivation =

Distributed, multi-modules robotics applications are currently built in the System and Automation Engineering department using the BABEL [1] development tools: the Module Designer (MD), the Execution Manager, and the Debugger. With the MD we can specify the attributes, services and events of modules. The interface of a module is given by its services, which can be called in a RPC (Remote Procedure Call) style if we know the service name and its input and output parameters. Traditionally, module interfaces have been developed based solely on the designer’s criterion, while not taking entirely into account their potential reusability and coherent integration into larger software structures. The ACHRIN robotic architecture [2] solves part of this problem with the introduction of common interfaces for Functional Groups, modules in charge of a specific task like navigation or manipulation. However, we rethink in this report the problem of interfaces between modules, keeping the following points in mind:

* Modules are elements of a larger structure, which we call the Control Architecture. Therefore their design must take into account not only intra-module issues, but the connections with the rest of the system.
* At some points, it is desirable to define BABEL level interfaces acting as frontiers between low and high-level tasks. This makes easier the maintenance, reusability and substitution of existing modules, as well as the creation of new modules.
* The same architecture should run over different mobile robots with different sensors, or over a simulator, without recompiling any module. Since low-level tasks are highly related to the specific robotic platform, a normalized description of the execution platform (the robot) should be used for the software to discover the hardware details and to behave accordingly.
* The units in which parameters are given have typically been a source of confusions. Here we propose to use always units from the Systeme International (S.I), as meters, seconds, meters/second and so on.
* Modules dealing with hardware sensors must cope with a number of the same device attached to the robot (e.g. two laser scanners). It would be desirable for some modules to access to sensory data by groups for commodity and reusability, e.g. to read the laser scans from all the laser range finders on the robot.
* Reliable error propagation is another major goal. Failures in hardware or low-level software must be reported to high-level modules as sensors or actuators malfunction.
* Initialization parameters have been traditionally hard-wired in the code or set apart in “.ini” files. This specification provides a unified interface to configuration parameters of all low-level modules. Further more, a visual application for easily editing them has been developed.
* It is desirable an event-driven data flow, as opposed to the current polling mechanism for obtaining data from sensors.

In the rest of this report we discuss these issues: in section 2 we give an overview of the proposed architecture model. The next section examines it in detail, giving developers all the needed information to maintain or create BABEL modules according to the proposed framework. Section 4 is dedicated to Robotic Platform Descriptors (RPDs) and a new graphical user interface (GUI) created to facilitate their edition. Finally we discuss issues to be specified in the future. Additional appendixes are provided with implementation details.

@@ Line 15: / Line 15: @@
 * Modules dealing with hardware sensors must cope with a number of the same device attached to the robot (e.g. two laser scanners). It would be desirable for some modules to access to '''sensory data by groups''' for commodity and reusability, e.g. to read the laser scans from all the laser range finders on the robot.
 * Reliable '''error propagation''' is another major goal. Failures in hardware or low-level software must be reported to high-level modules as sensors or actuators malfunction.
-* Initialization parameters have been traditionally hard-wired in the code or set apart in ".ini" files. This specification provides a unified interface to '''configuration parameters stored using XML''' of all low-level modules. Further more, a visual application for easily editing them has been developed.
+* Initialization parameters have been traditionally hard-wired in the code or set apart in ".ini" files. This specification provides a unified interface to '''configuration parameters stored using XML''' of all low-level modules. Further more, a [[Architecture:RPD_Server#RPD_Visual_Editor | visual application]] for easily editing them has been developed.
 * It is desirable an '''event-driven data flow''', as opposed to the current polling mechanism for obtaining data from sensors.
 In the rest of this report we discuss these issues: in section 2 we give an overview of the proposed architecture model. The next section examines it in detail, giving developers all the needed information to maintain or create BABEL modules according to the proposed framework. Section 4 is dedicated to '''Robotic Platform Descriptors (RPDs)''' and a new graphical user interface (GUI) created to facilitate their edition. Finally we discuss issues to be specified in the future. Additional appendixes are provided with implementation details.

@@ Line 1: / Line 1: @@
 <table width="95%"><tr>
-<td align="left"> <small>'''Previous:''' [[MAPIR's_Module_Architecture|Architecture index]]</small> </td>
+<td align="left"> <small>Previous: [[MAPIR's_Module_Architecture|Architecture index]]</small> </td>
-<td align="right"> <small>'''Next:''' [[Architecture:Brief_discussion_of_the_model|Overview]]</small></td></tr>
+<td align="right"> <small>Next: [[Architecture:Brief_discussion_of_the_model|Overview]]</small></td></tr>
 </table>

@@ Line 1: / Line 1: @@
 <table width="95%"><tr>
-<td align="left"> <small>Previous: [[MAPIR's_Module_Architecture|Architecture index]]</small> </td>
+<td align="left"> <small>'''Previous:''' [[MAPIR's_Module_Architecture|Architecture index]]</small> </td>
-<td align="right"> <small>Next: [[Architecture:Brief_discussion_of_the_model|Overview]]</small></td></tr>
+<td align="right"> <small>'''Next:''' [[Architecture:Brief_discussion_of_the_model|Overview]]</small></td></tr>
 </table>

@@ Line 1: / Line 1: @@
 <table width="95%"><tr>
-<td align="left"> <small>Back to : [[MAPIR's_Module_Architecture|Architecture index]]</small> </td>
+<td align="left"> <small>Previous: [[MAPIR's_Module_Architecture|Architecture index]]</small> </td>
 <td align="right"> <small>Next: [[Architecture:Brief_discussion_of_the_model|Overview]]</small></td></tr>
 </table>

← Older revision		Revision as of 14:45, 17 May 2009
Line 1:		Line 1:
−	<small>Back to : [[MAPIR's_Module_Architecture\|Architecture index]]</small><br>	+	<table width="95%"><tr>
		+	<td align="left"> <small>Back to : [[MAPIR's_Module_Architecture\|Architecture index]]</small> </td>
		+	<td align="right"> <small>Next: [[Architecture:Brief_discussion_of_the_model\|Overview]]</small></td></tr>
		+	</table>

@@ Line 6: / Line 6: @@
 Distributed, multi-modules robotics applications are currently built in the System and Automation Engineering department using the BABEL [1] development tools: the Module Designer (MD), the Execution Manager, and the Debugger. With the MD we can specify the attributes, services and events of modules. The interface of a module is given by its services, which can be called in a RPC (Remote Procedure Call) style if we know the service name and its input and output parameters. Traditionally, module interfaces have been developed based solely on the designer’s criterion, while not taking entirely into account their potential reusability and coherent integration into larger software structures. The ACHRIN robotic architecture [2] solves part of this problem with the introduction of common interfaces for Functional Groups, modules in charge of a specific task like navigation or manipulation. However, we rethink in this report the problem of interfaces between modules, keeping the following points in mind:
-* Modules are elements of a larger structure, which we call the Control Architecture. Therefore their design must take into account not only intra-module issues, but the connections with the rest of the system.
+* Modules are elements of a larger structure, which we call the '''Control Architecture'''. Therefore their design must take into account not only intra-module issues, but the connections with the rest of the system.
-* At some points, it is desirable to define BABEL level interfaces acting as frontiers between low and high-level tasks. This makes easier the maintenance, reusability and substitution of existing modules, as well as the creation of new modules.
+* At some points, it is desirable to define '''BABEL-level interfaces''' acting as frontiers between low and high-level tasks. This makes easier the maintenance, reusability and substitution of existing modules, as well as the creation of new modules.
-* The same architecture should run over different mobile robots with different sensors, or over a simulator, without recompiling any module. Since low-level tasks are highly related to the specific robotic platform, a normalized description of the execution platform (the robot) should be used for the software to discover the hardware details and to behave accordingly.
+* The same architecture should run over different mobile robots with different sensors, or over a simulator, without recompiling any module. Since low-level tasks are highly related to the specific robotic platform, a '''normalized description of the execution platform''' (the robot) should be used for the software to discover the hardware details and to behave accordingly.
-* The units in which parameters are given have typically been a source of confusions. Here we propose to use always units from the Systeme International (S.I), as meters, seconds, meters/second and so on.
+* The '''units''' in which parameters are given have typically been a source of confusions. Here we propose to use always units from the Systeme International (S.I), as meters, seconds, meters/second and so on.
-* Modules dealing with hardware sensors must cope with a number of the same device attached to the robot (e.g. two laser scanners). It would be desirable for some modules to access to sensory data by groups for commodity and reusability, e.g. to read the laser scans from all the laser range finders on the robot.
+* Modules dealing with hardware sensors must cope with a number of the same device attached to the robot (e.g. two laser scanners). It would be desirable for some modules to access to '''sensory data by groups''' for commodity and reusability, e.g. to read the laser scans from all the laser range finders on the robot.
-* Reliable error propagation is another major goal. Failures in hardware or low-level software must be reported to high-level modules as sensors or actuators malfunction.
+* Reliable '''error propagation''' is another major goal. Failures in hardware or low-level software must be reported to high-level modules as sensors or actuators malfunction.
-* Initialization parameters have been traditionally hard-wired in the code or set apart in “.ini” files. This specification provides a unified interface to configuration parameters of all low-level modules. Further more, a visual application for easily editing them has been developed.
+* Initialization parameters have been traditionally hard-wired in the code or set apart in ".ini" files. This specification provides a unified interface to '''configuration parameters stored using XML''' of all low-level modules. Further more, a visual application for easily editing them has been developed.
-* It is desirable an event-driven data flow, as opposed to the current polling mechanism for obtaining data from sensors.
+* It is desirable an '''event-driven data flow''', as opposed to the current polling mechanism for obtaining data from sensors.
-In the rest of this report we discuss these issues: in section 2 we give an overview of the proposed architecture model. The next section examines it in detail, giving developers all the needed information to maintain or create BABEL modules according to the proposed framework. Section 4 is dedicated to Robotic Platform Descriptors (RPDs) and a new graphical user interface (GUI) created to facilitate their edition. Finally we discuss issues to be specified in the future. Additional appendixes are provided with implementation details.
+In the rest of this report we discuss these issues: in section 2 we give an overview of the proposed architecture model. The next section examines it in detail, giving developers all the needed information to maintain or create BABEL modules according to the proposed framework. Section 4 is dedicated to '''Robotic Platform Descriptors (RPDs)''' and a new graphical user interface (GUI) created to facilitate their edition. Finally we discuss issues to be specified in the future. Additional appendixes are provided with implementation details.

Architecture:Motivation - Revision history

Jlblanco: /* Motivation */

Jlblanco at 14:45, 17 May 2009

Jlblanco at 14:45, 17 May 2009

Jlblanco at 14:45, 17 May 2009

Jlblanco at 14:45, 17 May 2009

Jlblanco at 14:43, 17 May 2009

Jlblanco: New page: Back to : Architecture index = Motivation = Distributed, multi-modules robotics applications are currently built in the System and Aut...

Jlblanco: New page: Back to : Architecture index
= Motivation = Distributed, multi-modules robotics applications are currently built in the System and Aut...