Robotics middleware: Difference between revisions

Revision as of 14:37, 28 January 2009

Latest revision as of 03:07, 11 August 2025

(125 intermediate revisions by 57 users not shown)

Line 1:

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

'''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. The ''composition'' of sub-systems into a new system is a difficult task, with currently close to no support from software tools, or from internationally accepted standards and workflows.

{{external links|date=May 2018}}

'''Robotics middleware''' is [[middleware]] to be used in complex [[robot]] control software 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>

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.

==Robotics middleware projects==

* Computation: each component performs certain computations that are necessary to provide the functionality that is expected from the system.

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

* Configuration: components should be usable in more than one possible configuration, but the amount of configuration is an important aspect of the design and the implementation of components and systems.

* Coordination: the activities in components have to be coordinated by ''something'' at the system level, in order to guarantee the expected behaviour and peformance of the composed system.

===Player Project===

Composing two or more components that each belong to one of these categories is an [[software architecture|architectural]] design activity that has to balance a large amount of functional and non-functional requirements (performance, [[compositionality]],…). The robotics research community has come up with a large number of ([[open source]]) projects that claim to provide good solutions to this component composition problem, but many questions are still unsolved, are rather, still unnoticed. 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.

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.

=== RT-middleware ===

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

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

===MIRO===

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

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.

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>

===Orca===

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

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

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

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

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

Orca software is released under LGPL and GPL licenses.

===OpenRDK===

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

===Rock===

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

===ISAAC SDK / Simulation===

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

===ROS===

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

===YARP===

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

=== DDX ===

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

==See also==

* [[Middleware for Robotic Applications]]

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

== References ==

{{Reflist}}

== External links ==

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

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

[[Category:Robotics software|*]]

[[Category:Robot operating systems]]

[[Category:Robotics suites]]