Content deleted Content added
m →Player Project: Typo fixing, typos fixed: , → , using AWB |
Magioladitis (talk | contribs) m Cleaned up using AutoEd |
||
Line 4:
==General concepts==
As ''glue'' code, the middleware should be invisible, and introduce no overhead or extra constraints on the components. This is of course an unreachable [[non-functional requirement|(non-functional)]] design requirement, so compromises have to be made. Different middleware projects mostly differ in which compromises are made (implicitly, most often!) and in which robotics applications are being targeted.
As glue software, middleware should support the ''coupling'' of subsystems, which is a fundamentally different software development skill than the ''[[separation of concerns|decoupling]]'' [[Requirements analysis|design requirements]] that most [[software engineer]]s are educated in. Indeed, decoupling is the major focus of class library development: one should make a library as independent from other libraries as possible. Middleware, on the other hand, must provide optimal support for ''coupling'': allowing to couple multiple, decoupledly designed components together in a way that satisfies [[systems engineering|system-level]] requirements.
Line 14 ⟶ 13:
* building a system from reusable components is challenging with respect to the balance between ''performance'' (it (seems to be) easier to optimize performance if one is not restricted to using only pre-built components) and ''ease of reuse''.
At a conceptual level, a complex robot controller has components that each ''serve'' one of the following four [[separation of concerns|concerns]]:
* '''Communication''': components must exchange information (data, events, commands,…), and ''how'' this exchange is done is an important property of the composite system.
* '''Computation''': each component performs certain computations that are necessary to provide the functionality that is expected from the system.
Line 36 ⟶ 35:
==Robotics middleware projects==
===
|-
* <u>System organization/decomposition</u> - Player is a device server (application server) with the collection of dynamically loadable device shared libraries. The main portion of this server is custom communication protocol which enables client-server communication model. Player is implemented in C++ and uses POSIX compliant pthread interface for multithreaded applications. Player can be viewed as a multithreaded application server providing applications/services to client programs. Here application/services are devices which are used by client programs. Since devices (applications/services that is) can be loaded dynamically, Player can be considered as "some way in between monolithic application and modular middleware+services" approach. A main Player server thread listens to client side connections and spawns threads whenever the client program asks a service from some specific device. Each device (device program) has its own thread of execution. As can be seen from the figure 1, the threads communicate via a shared global address space. Each device has an associated command and data buffer. Whenever the client needs to access some specific device, it sends a command which is queued in a command buffer and then read by the device. The same applies to the data buffer: The device writes the data to the buffer and the client side program reads it. Since Player does not implement any device locking mechanism whenever multiple clients are connected to a Player server, one can overwrite the commands of other clients. This applies to commands and data (it is noteworthy to mention that data and commands are implemented as asynchronous one-way continuous streams) but not to configuration requests which can be used to access specific hardware features (this mechanism is implemented as a two-way synchronous request-reply interaction). One can also define the frequencies at which a particular device provides data to the client, by default this value is 10 Hz. Depending on the needs of a client data can be served in PUSH or PULL modes, by default the mode is PUSH, so server/devices send all data available to the client.
|-
▲<td style="border:1px solid lightblue" align="justify" valign="center">
* <u>Communication approach</u> - Player, of current version, decomposed into two main parts: Player core, which is the core Player API, device drivers, driver loading code, configuration parsing code and driver registry. Transport layer, this part is independent of device drivers and can be any type of transport system, of current version it is implemented as two libraries, libplayertcp and libplayerxdr, and is based on TCP communication protocol using sockets (and message queues). Other transport types which can be used are JINI and CORBA based (means there is support for RMI and RPC).
|-
▲<td style="border:1px solid lightblue" align="justify" valign="center">
* <u>Platform/language support and other system features</u> - Support for plugin drivers and simulation environments Stage and Gazebo. No device locking mechanism, client side data is always older than server side data because of the "buffer sit" times. Devices are treated as files with read/write access. Most of the devices adopt character device model. On the client side, programs communicate with server/devices through their respective local proxycies. There is no considerable support for fault tolerant capabilities. One of the features which can be accounted for is the “libplayererror” library, which can be used to perform error reporting. Also, there are some procedures to perform thread locking in order to avoid conflicts. Player is supported on most of the UNIX flavors and under Windows using Cygwin. Client programs can be written in any language providing socket mechanism, e.i. TCL, Python, C, C++, Java etc.
|-
* <u>Fault tolerance and robustness aspects:</u> Though the Player project has been active for quite a long time, there have been no considerable developments to improve its fault tolerant capabilities. One of the features which can be accounted for is the libplayererror library, which can be used to perform error reporting. Also, there are some procedures to perform thread locking in order to avoid conflicts. From the perspective of robustness, it should be possible to implement planning, learning, state estimation or similar functionalities for an application based on Player. In the future the authors want to implement a resource awareness attribute, i.e. enable the programs to perform resource discovery and change their behavior according to the availability of resources.▼
|}
▲<td style="border:1px solid lightblue" align="justify" valign="center">
▲*<u>Fault tolerance and robustness aspects:</u> Though the Player project has been active for quite a long time, there have been no considerable developments to improve its fault tolerant capabilities. One of the features which can be accounted for is the libplayererror library, which can be used to perform error reporting. Also, there are some procedures to perform thread locking in order to avoid conflicts. From the perspective of robustness, it should be possible to implement planning, learning, state estimation or similar functionalities for an application based on Player. In the future the authors want to implement a resource awareness attribute, i.e. enable the programs to perform resource discovery and change their behavior according to the availability of resources.
=== Urbi ===
[[URBI|Urbi]] is an open source cross-platform software platform in C++ used to develop applications for robotics and complex systems. It is based on the UObject distributed C++ component architecture. It also includes the urbiscript orchestration language which is a parallel and event-driven script language. UObject components can be plugged into urbiscript and appear as native objects that can be scripted to specify their interactions and data exchanges. UObjects can be linked to the urbiscript interpreter, or executed as autonomous processes in "remote" mode, either in another thread, another process, a machine on the local network, or a machine on a distant network.
===
|-
* <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:
<OL>
<LI>
Line 84 ⟶ 71:
</LI>
</OL>
|-
▲<td style="border:1px solid lightblue" align="justify" valign="center">
* <u>Communication approach</u> - For communication purposes MIRO relies on a TAO middleware C++ implementation of the CORBA standard. Subsystems/Objects communicate according to a client-server model, which is an example for a distribution model. With respect to the time properties both synchronous and asynchronous modes of communication are utilized. The system also supports event driven communication. Both push and pull models are used. A comprehensive overview on the layout and accessibility of each respective layer is depicted in figure 3
|-
▲<td style="border:1px solid lightblue" align="justify" valign="center">
* <u>Platform/language support and other system features</u>
[To be done]
|-
* <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 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” 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 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 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” 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.
===Wasp Actuator Sensor Protocol===
Line 113 ⟶ 91:
===[http://openrdk.sf.net/ OpenRDK]===
|-
▲<table class="wikitable" style="border:1px solid lightblue" align="justify" valign="center">
▲<td style="border:1px solid lightblue" align="justify" valign="center">
* <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.
Line 123 ⟶ 100:
<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>
|-
* <u>Communication approach</u> -
<ul>
Line 132 ⟶ 109:
</ul>
<center>http://wiki.robot-standards.org/images/5/55/OpenRDK-rconsole.png</center>
|-
* <u>Tools</u> -
OpenRDK comprises also <tt>RConsole</tt> (RDK Console), which allows for remote operations, inspection, parameter updates, etc.<br />
<center>http://wiki.robot-standards.org/images/5/55/OpenRDK-rconsole.png</center>
|}
==See also==
| |||