Robotics middleware: Difference between revisions

Revision as of 15:53, 18 May 2009

Revision as of 09:21, 17 August 2009

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

* '''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, [[Run time (computing)|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.

Line 35:

==Robotics middleware projects==

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

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

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

<tr >

Line 63 ⟶ 62:

</table>

<br>

=== [http://smart.informatik.uni-ulm.de/MIRO/index.html '''MIRO''']===

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

<tr>

Line 102 ⟶ 100:

</tr>

</table>

<br>

===[[Wasp Actuator Sensor Protocol]]===

[To be done]

===[http://orca-robotics.sourceforge.net/ '''Orca2''']===

[To be done]

===[http://openrdk.sf.net/ '''OpenRDK''']===

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

Line 140 ⟶ 137:

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

{{DEFAULTSORT:Robotics Middleware}}

[[Category:Robotics]]