Content deleted Content added
Line 107:
* <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.
▲|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.
▲|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.
|-
| style="border:1px solid lightblue" align="justify" valign="center" |
* <u>Communication approach</u> -
▲|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.
▲|Special queue objects also reside in the repository and they share the same global URL-like addressing scheme of other properties.
▲|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.
|-
| style="border:1px solid lightblue" align="justify" valign="center" |
| |||