YARP RoadMap

From Wiki for iCub and Friends
Jump to: navigation, search

See Planned Changes for discussion.

Installation and use thread

YARP is a portable library. Currently, end-users are required to compile YARP on their system. This can be burdensome, especially if they are not set up for compiling C++ code (for example, if they are python programmers). It would be useful to provide pre-compiled versions of YARP.

  • Develop a run-time plugin architecture to simplify user installation of optional devices and network protocols.
  • Improve the SWIG translation of YARP, so that all functionality of YARP is exposed in a clearly documented way. The most maintainable way to do this is by implementing and documenting an interface to YARP that (1) uses single-inheritance only, and not multiple inheritance, and (2) avoids the use of templates.
  • Put in place a documented mechanism for generating pre-compiled YARP binaries supporting several operating systems and compilers.

Interoperability thread

Interoperation between YARP and other middleware is desirable to facilitate collaboration, particularly in the following cases:

  • When a user of YARP wishes to control with a non-YARP-using robot.
  • When a user of another middleware wishes to control a YARP-using robot.

The most obvious way for a user to achieve these goals is to learn enough of the other middleware involved in order to write a “bridge” between the two that is sufficient for their goals.

  • Produce and maintain examples and documentation for writing bridges to and from YARP for common tasks, for popular robotics middleware. This will save a bridge-writer time, and help estimate how long specific integration tasks might take.

The interface between YARP-using program and the YARP library is sufficiently flexible that it may well be possible to directly support another middleware’s protocols. When possible, this is more efficient than bridging, since it eliminates unnecessary copying or reformatting operations.

  • When possible, produce and maintain direct support for the protocols used by ROS, LCM, and other middleware of interest. Document the use of this support, providing examples.

Apart from dealing with specific middleware, YARP can improve interoperability by using popular standards when possible.

  • Examine existing YARP protocols and formats, and provide standards-based alternatives when appropriate standards exist, with the goal of reducing the amount of YARP-specific knowledge needed in order to communicate with YARP-based programs. As an example, the JSON format has evolved to be a suitable default format for text-based connections YARP, and could replace the existing YARP-specific text representation. As another example, configuration and state information could be represented and queried using standard database formats and languages.


YARP supports a variety of communication styles, including classic RPC (“Remote Procedure Call”) style operation. Historically, YARP developers have held back from providing an IDL (“Interface Definition Language”) which makes writing RPC calls convenient, for philosophical and practical reasons. However, now seems a good time to revisit this, at least for the purposes of interoperation.

  • Design an IDL for YARP, implement support for it, and document its use. The guiding principles for the design should be minimal interference with a user’s build chain, and maximum interoperability with other middleware.

Other tasks

  • Add a visualization of connections in a YARP network, bearing in mind that some of those connections may involve external processes not using the YARP library.
  • Put in place a documented mechanism for generating pre-compiled binaries of the ICUB repository supporting several operating systems and compilers.