|
<br>
=== [http://smart.informatik.uni-ulm.de/MIRO/index.html <b>'''MIRO</b>''']===
<table class="wikitable" style="border:1px solid lightblue" align="justify" valign="center">
<tr>
<tr>
<td style="border:1px solid lightblue" align="justify" valign="center">
* <u>Fault tolerance and robustness aspects</u> - MIRO does not provide any explicit fault tolerant capabilities on the system level, not considering the ones provided by the underlying middleware and the operating system (resource management, conflict resolution etc). There are some exception handling capabilities apart from the ones provided by the underlying middleware, though, and there is a list of MIRO exceptions which indicate hardware problems, service call failures or malfunction and load problems. In addition, a post- or predevelopment phase capability which may improve reliability of the software is a so-called “logging“logging service”service” with several levels of notification. To increase the reliability of the software and minimize the number of errors, a partially automated code generation is provided. This comes automatically when using the IDL compiler, which helps to generate all the code for the communication and underlying middleware services. But again, most of the features mentioned are not part of the SIS itself but rather facilities it relies on. The use of a BAP (behaviors, action patterns, policy) framework can contribute to the robustness of the applications based on MIRO. The BAP proposes ways of combining simple behaviors to form complex ones. The principle used for creating complex behavior hierarchies is similar to the finite state machine (FSM) principle, represented in figure 6. Action patterns, represented in figure 5, are composed of behaviors and “guards”“guards” which can notify about some external event. Apart from this, the authors claim that a dynamic reconfiguration of policies is possible. This feature also may contribute to robustness. On the other hand, there are no implications whether it is possible to implement any planning or learning capabilities.
</td>
</tr>
===[[Wasp Actuator Sensor Protocol]]===
[To be done]
===[http://orca-robotics.sourceforge.net/ <b>'''Orca2</b>''']===
[To be done]
===[http://openrdk.sf.net/ <b>'''OpenRDK</b>''']===
<table class="wikitable" style="border:1px solid lightblue" align="justify" valign="center">
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.
<ul>
<li>In our framework the main entity is a software process called <b>'''agent</b>'''. A <b>'''module</b>''' is a <b>'''<u>single thread</u></b>''' 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 <b>'''agent configuration</b>''' 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>
</td></tr>
* <u>Communication approach</u> -
<ul>
<li>Modules communicate using a blackboard-type object, called <b>'''repository</b>''' (see figure below), in which they publish some of their internal variables (parameters, inputs and outputs), called <b>'''properties</b>'''. 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.
| 