Robotics middleware: Difference between revisions

Revision as of 16:23, 27 March 2009

Latest revision as of 03:07, 11 August 2025

(106 intermediate revisions by 52 users not shown)

Line 1:

{{short description|Middleware used in complex robot control software systems}}

{{article issues|expand=February 2009|intromissing=February 2009|primarysources=February 2009|unreferenced=February 2009}}

{{external links|date=May 2018}}

==General concepts==

'''Robotics middleware''' is [[middleware]] to be used in complex [[robot]] control software systems. It is the ''glue'' software that every system developer wants to use to connect software (and hardware) components together. Often, only ''communication'' between components is considered to be middleware, but this article takes a broader view, by including all ''application-independent'' code that helps system developers in the composition of subsystems into larger systems.

:"''...robotic middleware is designed to manage the complexity and heterogeneity of the hardware and applications, promote the integration of new technologies, simplify software design, hide the complexity of low-level communication and the sensor heterogeneity of the sensors, improve software quality, reuse robotic software infrastructure across multiple research efforts, and to reduce production costs.''"<ref>{{cite journal|last1=Elkady|first1=Ayssam|title=Robotics Middleware: A Comprehensive Literature Survey and Attribute-Based Bibliography|journal=Journal of Robotics|date=29 January 2012|volume=2012|pages=1–15|doi=10.1155/2012/959013|ref=959013|doi-access=free}}</ref>

It can be described as "software glue" to make it easier for robot builders focus on their specific problem area.<ref name="MW-00">{{Cite web|title=What is Middleware? |url=http://www.middleware.org/whatis.html |publisher=Defining Technology |work=Middleware.org |year=2008 |accessdate=2013-08-11 |url-status=unfit |archiveurl=https://web.archive.org/web/20120629211518/http://www.middleware.org/whatis.html |archivedate=June 29, 2012 }}</ref>

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.

The ''[[Principle of compositionality|composition]]'' of sub-systems into a new system is often a difficult task: designing the ''[[Systems architecture|architecture]]'' of the system is hard, since it requires to find the optimal trade-offs between ''all'' system requirements and to realise the optimal cooperation between all system components. There are currently close to no [[software tool]]s, or internationally accepted standards and [[workflow]]s, to support the job of the system designer.

==Robotics middleware projects==

Some of the problems to be solved when designing a composite system are:

A wide variety of projects for robotics middleware exist, but no one of these dominates - and in fact many robotic systems do not use any middleware.<ref name=tools>{{cite web|title=Tools, Standards, and Platforms for Commercial Robotics Development: An Adoption Profile|url=https://www.roboticsbusinessreview.com/uncategorized/tools-standards-and-platforms-for-commercial-robotics-development/|archive-url=https://web.archive.org/web/20180116004433/https://www.roboticsbusinessreview.com/uncategorized/tools-standards-and-platforms-for-commercial-robotics-development/|url-status=dead|archive-date=January 16, 2018|website=roboticsbusinessreview.com|accessdate=8 May 2017|date=October 2009}}</ref> Middleware products rely on a wide range of different standards, technologies, and approaches that make their use and interoperation difficult, and some developers may prefer to integrate their system themselves.<ref name=tools/>

* the composed system should have an interface that is not (much) more complex than the combination of all composing subsystems. Otherwise, the composite system offers no real design advantages to the human developer. In practice, this means that the composite system developer makes some design decisions that restrict the use of each of the components to only a part of its potential ___domain.

* the composed system should act to its users as one consistent, monolithic system in itself.

* 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''.

===Player Project===

At a conceptual level, a complex robot controller has components that each ''serve'' one of the following four [[separation of concerns|concerns]]:

The [[Player Project]] (formerly the ''Player/Stage Project'') is a project to create [[free software]] for research into [[robotics]] and [[sensor]] systems.<ref>Gerkey, B., Vaughan, R., and Howard, A. (2003) The Player/Stage Project: Tools for Multi-Robot and Distributed Sensor Systems. ''Proceedings of the International Conference on Advanced Robotics'' 317-323</ref> Its components include the ''Player'' network server and the ''Stage'' robot platform simulators. Although accurate statistics are hard to obtain, Player is one of the most popular open-source robot interfaces in research and post-secondary education.<ref>Collet, T. H. J., MacDonald, B. A., and Gerkey, B. (2005) Player 2.0: Toward a practical robot programming framework. ''Proceedings of the Australasian Conference on Robotics and Automation (ACRA)''</ref> Most of the major intelligent robotics journals and conferences regularly publish papers featuring real and simulated robot experiments using Player and Stage.

* '''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.

* '''Configuration''': components should be usable in more than one possible configuration (i.e., concrete settings for each of their variable parameters), but the amount of configuration is an important aspect of the design and the implementation of components and systems. Configuration is required at various moments in the lifetime of a software system: [[compile time]], [[software deployment|deployment]] time, [[runtime]],…

* '''Coordination''': the activities in components have to be coordinated by ''something'' at the system level, in order to guarantee the expected behaviour and performance of the composed system. Coordination involves: decision making, scheduling, (de)activating subsystems and/or their interconnections,…

Whether these four above-mentioned primitive concepts are really ''minimal'' (i.e., one needs only these four concepts to cover all relevant system design aspects) and/or ''complete'' (i.e., these concepts cover ''all'' possible systems) is not so important in this discussion; the important thing is that, at systems level, the designer should benefit from a level of abstraction that is an appropriate trade-off between complexity (the fewer concepts are needed, the better) and flexibility (the more diverse systems can be represented by the conceptual primitives, the better). Again, the ''appropriate'' trade-off is not an absolute concept, so it will depend on many (non-functional) design requirements. As such, both the number and the nature of the primitive concepts, and the particular trade-off, are discriminating factors between different middleware projects.

=== RT-middleware ===

Composing two or more components that each belong to one of these categories is an [[software architecture|architectural]] design activity. It is often complex, in that it has to balance a large amount of functional and non-functional requirements (performance, [[compositionality]],…). The robotics research community has not yet come up with fully satisfying software frameworks, architectures, or methodologies to deal with the composition problem, but a large number of ([[open source]]) projects exist already, and they all claim to provide good solutions to this component composition problem, at least to (implicitly described) parts of it. Anyway, many fundamental questions are still unsolved, or rather, are still unnoticed within the robotics research community. This article presents an overview of some of the relevant issues to be considered in the design and use of such middleware, and also provides an annotated list of middleware projects with an evaluation of which design constraints they took (or did not take) into account, and about how well they perform.

[[RT middleware|RT-middleware]] is a common platform standards for Robots based on distributed object technology.<ref>Noriaki ANDO, Takashi SUEHIRO, Kosei KITAGAKI, Tetsuo KOTOKU, Woo-Keun Yoon, "RT-Middleware: Distributed Component Middleware for RT (Robot Technology)", 2005 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS2005), pp.3555-3560, 2005.08, Edmonton, Canada</ref> RT-middleware supports the construction of various networked robotic systems by the integration of various network-enabled robotic elements called [[RT-Components]]. The specification standard of RT-components is discussed and defined by the [[Object Management Group]] (OMG).<ref>[http://www.omg.org/spec/RTC/1.0/ Robotics Technology Component Specification version 1.0], Object Management Group (OMG)</ref>

=== Urbi ===

==Composition of subsystems==

[[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.

How to ''optimally'' compose subsystems into a larger system is the core activity of system developers, but is remains more of an art than of a science. The major challenge is to develop subsystems that are ''stable'' on their own, while still very ''willing'' to be part of a larger system. There are four different ways of composing software components:

* linking object classes by providing explicit references to each other:

* composing object classes without them knowing about each other

* composing [[component-based programming|components]]

* composing [[software service]]s:

===MIRO===

A composed system is ''stable'' if it can be used without the user having to know that it is a composed system in itself. Examples of commonly used compositions that are not stable are:

[https://www.openhub.net/p/miro-middleware/ Miro] is a distributed object oriented framework for mobile robot control, based on [[CORBA]] (Common Object Request Broker Architecture) technology.

* [[Simulink]] blocks in feedback controllers: one often has to introduce explicit delay blocks; one cannot predict the overall performance on the basis of the performance of the individual blocks.

The Miro core components have been developed under the aid of ACE (Adaptive Communications Environment), an object oriented multi-platform framework for OS-independent interprocess, network and real time communication. They use TAO (The ACE ORB) as their ORB (Object Request Broker), a CORBA implementation designed for high performance and real time applications.

* [[Real-time computing|Realtime]] aspects at the system level: only one of the components can really have the highest priority; schedulability of the activities in all components becomes exponentially harder to analyse, let alone to guarantee, when the number of components grows; [[Inter-process communication|IPC]] [[deadlock]]s become more likely, and more difficult to trace; [[formal verification]] becomes more difficult, since [[jitter]] and [[latency (engineering)|latency]] deteriorate in less predictable ways, compromising the ideal, abstract model of states with atomic and infinitely fast transitions and condition checks.

Currently supported platforms include [[Autonomous research robot|Pioneers]], the B21, some robot soccer robots and various robotic sensors.<ref>{{citation |url=https://www.academia.edu/31375091 |doi=10.1016/S1474-6670(17)41721-6|title=Miro: Middleware for Autonomous Mobile Robots|journal=IFAC Proceedings Volumes|volume=34|issue=9|pages=297–302|year=2001|last1=Enderle|first1=Stefan|last2=Utz|first2=Hans|last3=Sablatnög|first3=Stefan|last4=Simon|first4=Steffen|last5=Kraetzschmar|first5=Gerhard|last6=Palm|first6=Günther|doi-access=free}}</ref>

* Adding sensor processing or control blocks to a control loop: each new sensor can bring with it a [[device driver]] that requires a different [[sampling frequency]], that provides a different [[spatial resolution]], …

===Orca===

==Robotics middleware projects==

[https://orca-robotics.sourceforge.net/ Orca] describes its goals as:

* to enable software reuse by defining a set of commonly used interfaces;

* to simplify software reuse by providing libraries with a high-level convenient API; and

* to encourage software reuse by maintaining a repository of components.

They also state: "To be successful, we think that a framework with such objectives must be: general, flexible and extensible; sufficiently robust, high-performance and full-featured for use in commercial applications, yet sufficiently simple for experimentation in university research environments."<ref name=orcao>{{cite web|title=Orca Overview|url=https://orca-robotics.sourceforge.net/orca_doc_overview.html|accessdate=7 May 2017}}</ref>

They describe their approach as:

=== [[Player Project]]===

* adopts a Component-Based Software Engineering approach without applying any additional architectural constraints

<table class="wikitable" style="border:1px solid lightblue" align="justify" valign="center">

* uses a commercial open-source library for communication and interface definition

<tr >

* provides tools to simplify component development but makes them strictly optional to maintain full access to the underlying communication engine and services

<td style=" border:1px solid lightblue" align="justify" valign="center">

* uses cross-platform development tools<ref name=orcao/>

*<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.

Orca software is released under LGPL and GPL licenses.

</td>

</tr>

===OpenRDK===

<tr>

[http://openrdk.sf.net/ OpenRDK] is an open-source software framework for robotics for developing loosely coupled modules. It provides transparent concurrency management, inter-process (via sockets) and intra-process (via shared memory) blackboard-based communication and a linking technique that allows for input/output data ports conceptual system design. Modules for connecting to simulators and generic robot drivers are provided.

<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>

</tr>

===Rock===

<tr>

[https://robotik.dfki-bremen.de/en/research/softwaretools/rock.html Rock] (Robot Construction Kit), is a software framework for the development of robotic systems. The underlying component model is based on the Orocos RTT (Real Time Toolkit). Rock provides all the tools required to set up and run high-performance and reliable robotic systems for wide variety of applications in research and industry. It contains a rich collection of ready to use drivers and modules for use in your own system, and can easily be extended by adding new components.

<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.

</td>

</tr>

===ISAAC SDK / Simulation===

<tr>

[https://developer.nvidia.com/isaac-sdk ISAAC], The NVIDIA Isaac Software Development Kit (SDK) is a developer toolbox for accelerating the development and deployment of Artificial Intelligence-powered robots. The SDK includes the Isaac Robot Engine, packages with high-performance robotics algorithms (to perform perception and navigation), and hardware reference applications. Isaac Sim is a virtual robotics laboratory and a high-fidelity 3D world simulator. It accelerates research, design, and development in robotics by reducing cost and risk. Developers can quickly and easily train and test their robots in detailed, highly realistic scenarios. There is an open source community version available at GitHub with supported hardware platform includes BOM details, refer [https://github.com/nvidia-isaac/kaya-robot kaya-robot]

<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.

</td>

</tr>

===ROS===

<tr>

[http://www.ros.org/core-components/#communications_infrastructure ROS] {{Webarchive|url=https://web.archive.org/web/20180115071720/http://www.ros.org/core-components/#communications_infrastructure |date=2018-01-15 }} ([[Robot Operating System]]) is a collection of [[software framework]]s for [[robot]] software development on a heterogeneous [[computer cluster]]. ROS provides standard operating system services such as [[hardware abstraction]], low-level [[Device driver|device control]], implementation of commonly used functionality, [[Inter-process communication|message-passing between processes]], and package management.

<td >

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

|-

|style="border:1px solid lightblue; width:350px; height:100px" align="center" valign="center"|[[Image:PlayerNew1.jpg|350px]]

|style="border:1px solid lightblue; width:350px; height:100px" align="center" valign="center"|[[Image:PlayerNew2.jpg|350px]]

|-

|style="border:1px solid lightblue; width:350px; height:20px" align="center" valign="center"| Figure 1: Player device server internals [http://playerstage.sourceforge.net/ (copyrighted by Player/Stage/Gazebo team) ]

|style="border:1px solid lightblue; width:350px; height:20px" align="center" valign="center"| Figure 2: Player overview [http://playerstage.sourceforge.net/ (copyrighted by Player/Stage/Gazebo team) ]

|-

|}

</td>

</tr>

===YARP===

</table>

YARP is an open-source software package, written in C++ for interconnecting sensors, processors, and actuators in robots.

<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>

<td 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:

<OL>

<LI>

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>

<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>

</td>

</tr>

=== DDX ===

<tr>

[https://research.csiro.au/software/spring/ DDX (Dynamic Data eXchange)] is ([[Linux]]/[[Berkeley Software Distribution|BSD]]/[[Unix]]) middleware developed by [[CSIRO]] to provide a lightweight real-time [[Publish–subscribe pattern|publish/subscribe]] service to distributed robot controllers. DDX allows a coalition of programs to share data at run-time through an efficient [[shared memory]] mechanism. Multiple machines can be linked by means of a global naming service and, when needed, data is [[Multicast address|multi-cast]] across machines.<ref>{{Cite journal |last=Corke |first=Peter |last2=Sikka |first2=Pavan |last3=Roberts |first3=Jonathan |last4=Duff |first4=Elliot |date=2004 |title=DDX: A distributed software architecture for robotic systems |url=https://eprints.qut.edu.au/33835/ |journal=Australasian Conference on Robotics and Automation 2004}}</ref> DDX was developed to automate a number of [https://research.csiro.au/robotics/our-work/solutions/miningtech/ large mining machines]: including [[Dragline excavator|draglines]], [[LHD (load, haul, dump machine)|LHD trucks]], [[Excavator|excavators]] and rock-breakers.

<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>

</tr>

==See also==

<tr>

* [[Middleware for Robotic Applications]]

<td >

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

|-

|style="border:1px solid lightblue; width:350px; height:100px" align="center" valign="center"|[[Image:Miro1New.jpg|300px]]

|style="border:1px solid lightblue; width:350px; height:100px" align="center" valign="center"|[[Image:Miro2New.jpg|250px]]

|-

|style="border:1px solid lightblue; width:350px; height:20px" align="center" valign="center"| Figure 3: MIRO abstraction layers [http://smart.informatik.uni-ulm.de/MIRO/index.html (copyrighted by MIRO team)]

|style="border:1px solid lightblue; width:350px; height:20px" align="center" valign="center"|Figure 4: Overview on MIRO architecture.

|-

|}

</td>

</tr>

== References ==

<tr>

{{Reflist}}

<td style="border:1px solid lightblue" align="justify" valign="center">

* <u>Platform/language support and other system features</u>

[To be done]

</td>

</tr>

== External links ==

<tr>

* [http://www.best-of-robotics.org/en/home.html BRICs]: a [[Seventh Framework Programme|European project]] that attempts to establish best practices in robot development

<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 &#8220;logging service&#8221; 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 &#8220;guards&#8221; 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>

<tr>

<td>

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

|-

|style="border:1px solid lightblue; width:350px; height:100px" align="center" valign="center"|[[Image:Miro3New.jpg|300px]]

|style="border:1px solid lightblue; width:350px; height:100px" align="center" valign="center"|[[Image:Miro4New.jpg|300px]]

|-

|style="border:1px solid lightblue; width:350px; height:20px" align="center" valign="center"| Figure 5: Action pattern

|style="border:1px solid lightblue; width:350px; height:20px" align="center" valign="center"|Figure 6: Action patterns organized in behavior hierarchies

|-

|}

</td>

</tr>

</table>

<br>

===[[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>]===

[To be done]

==See also==

* [[RoSta]]: a [[FP6|European project]] reaching out to the robotics community to get clearer insights into robotics middleware and architectures.

[[Category{{DEFAULTSORT:Robotics]] Middleware}}

[[Category:Robotics software|*]]

[[Category:Robot operating systems]]

[[Category:Robotics suites]]