Robotics middleware: Difference between revisions

Revision as of 16:37, 11 April 2014

Revision as of 18:14, 13 April 2014

Line 79:

| style="border:1px solid lightblue" align="justify" valign="center" |

* <u>System organization/decomposition</u> - MIRO uses an abstract machine model, i.e. the system is divided into several distinct layers, as depicted in figure 3. The higher layers can only access the lower layers via their interfaces. In case of MIRO, these layers are:

{{ordered list

<OL>

|MIRO device layer - this layer provides classes to interface hardware and abstract the low level hardware details This classes enable access to hardware resources via simple procedure calls.

<LI>

|MIRO service layer - this layer provides service abstractions for sensors and actuators by means of the CORBA interface definition language (IDL). These services are implemented as network transparent objects/CORBA objects. The classes in this layer present the sensors and actuators as generic services. For example the RangeSensor class defines functionality common to the sensors which return range readings such as sonars, lidars and other type of range finders.

MIRO device layer - this layer provides classes to interface hardware and abstract the low level hardware details This classes enable access to hardware resources via simple procedure calls.

|MIRO framework layer - on this level functional modules specific to robotics are provided. Examples are mapping, localization, path planning and similar facilities.

</LI>

}}

<LI>

MIRO service layer - this layer provides service abstractions for sensors and actuators by means of the CORBA interface definition language (IDL). These services are implemented as network transparent objects/CORBA objects. The classes in this layer present the sensors and actuators as generic services. For example the RangeSensor class defines functionality common to the sensors which return range readings such as sonars, lidars and other type of range finders.

</LI>

<LI>

MIRO framework layer - on this level functional modules specific to robotics are provided. Examples are mapping, localization, path planning and similar facilities.

</LI>

</OL>

|-

| style="border:1px solid lightblue" align="justify" valign="center" |

Line 115 ⟶ 109:

* <u>System organization/decomposition</u> -

OpenRDK is a modular software framework focused on rapid development of distributed robotic systems. It has been designed following users' advice and has been in use within our group for several years. By now OpenRDK has been successfully applied in diverse applications with heterogeneous robots and as we believe it is fruitfully usable by others we are releasing it as open source.

{{unordered list

<ul>

<li>|In our framework the main entity is a software process called '''agent'''. A '''module''' is a '''<u>single thread</u>''' inside the agent process; modules can be loaded and started dynamically once the agent process is running. In the figure below we see an example. Two agents are executed on two different machines and three modules run inside them: <tt>hwInterface</tt> retrieves data from a laser range finder and the odometry from a robotic base; given this data, <tt>scanMatcher</tt> uses a scan-matching algorithm in order to estimate the robot positions over time; <tt>mapper</tt> uses the estimated robot positions, together with the laser scans, to build a map of the environment.</li>

<li>|An '''agent configuration''' is the list of which modules are instantiated, together with the values of their parameters and their interconnection layout. It is initially specified in a configuration file.</li>

}}

</ul>

|-

| style="border:1px solid lightblue" align="justify" valign="center" |

* <u>Communication approach</u> -

{{Unordered list

<ul>

<li>|Modules communicate using a blackboard-type object, called '''repository''' (see figure below), in which they publish some of their internal variables (parameters, inputs and outputs), called '''properties'''. A module defines its properties during initialization, after that, it can access its own and other modules' data, within the same agent or on other ones, through a global URL-like addressing scheme. Access to remote properties is transparent from a module perspective; on the other hand, it reduces to shared memory (OpenRDK provides easy built-ins for concurrency management) in the case of local properties.</li>

<li>|Special queue objects also reside in the repository and they share the same global URL-like addressing scheme of other properties.</li>

<li>|In the figure below, the <tt>hwInterface</tt> module pushes laser scan and odometry objects into queues, that are remotely accessed by the <tt>scanMatcher</tt> module, which, in turn, pushes the estimated poses in another queue, for the <tt>mapper</tt> to access to them. Finally, the <tt>mapper</tt> updates a property which contains a map.

}}

</ul>

<center>http://wiki.robot-standards.org/images/5/55/OpenRDK-rconsole.png</center>

|-