YARP is plumbing for robot software.

It is a set of libraries, protocols, and tools to keep modules and devices cleanly decoupled. It is reluctant middleware, with no desire or expectation to be in control of your system. YARP is definitely not an operating system.

Robot projects are often evolutionary dead ends, with the software and hardware they produce disappearing without trace afterwards. Common causes include dependencies on uncommon or obsolete devices or libraries, and dispersion of an already small group of users. In humanoid robotics, a small field with an avid appetite for novel devices, we experience a great deal of churn of this nature. YARP is our attempt to make robot software that is more stable and long-lasting, without compromising our ability to constantly change our sensors, actuators, processors, and networks. It helps organize communication between sensors, processors, and actuators so that loose coupling is encouraged, making gradual system evolution much easier. The YARP model of communication is transport-neutral, so that data flow is decoupled from the details of the underlying networks and protocols in use (allowing several to be used simultaneously, key to smooth evolution). YARP uses a methodology for interfacing with devices (sensors, actuators, etc.) that again encourages loose coupling and can make changes in devices less disruptive. At the same time, YARP doesn't expect to be in charge; we want to minimize problem of incompatible "architectures", "frameworks", and "middleware" (also known in this context as "muddleware").

YARP is free and open software. Along with many other benefits, the Free Software social contract can speed software development for small communities with idiosyncratic requirements, such as ourselves.

YARP is written by and for researchers in robotics, particularly humanoid robotics, who find themselves with a complicated pile of hardware to control with an equally complicated pile of software. At the time of writing (*), running decent visual, auditory, and tactile perception while performing elaborate motor control in real-time requires a lot of computation. The easiest and most scalable way to do this right now is to have a cluster of computers. Every year what one machine can do grows, but so do our demands. YARP is a set of tools we have found useful for meeting our computational needs for controlling various humanoid robots.

The components of YARP can be broken down into:

YARP_os - interfacing with the operating system(s) to support easy streaming of data across many threads across many machines. YARP is written to be OS neutral, and has been used on Linux, Microsoft Windows, Apple macOS and iOS, Solaris, and Android. YARP uses the open-source ACE (ADAPTIVE Communication Environment) library, which is portable across a very broad range of environments, and YARP inherits that portability. YARP is written almost entirely in C++.

YARP_sig - performing common signal processing tasks (visual, auditory) in an open manner easily interfaced with other commonly used libraries, for example OpenCV.

YARP_dev - interfacing with common devices used in robotics: framegrabbers, digital cameras, motor control boards, etc.

These components are maintained separately. The core component is YARP_os, which must be available before the other components can be used.

For real-time operation, network overhead has to be minimized, so YARP is designed to operate on an isolated network or behind a firewall. If you expose machines running YARP to the internet, expect your robot to one day be commanded to make a crude gesture at your funders by a script kiddie in New Zealand (or, if you are in New Zealand, New York).

For interfacing with hardware, we are at the mercy of which operating systems particular companies choose to support - few are enlightened enough to provide source. The YARP_dev library is structured to interface easily with vendor-supplied code, but to shield the rest of your system from that code so that future hardware replacements are possible. Check the requirements imposed by your current hardware; YARP will not reduce these, only make future changes easier.

YARP has consequently three levels of configuration: operating system, hardware, and robot level. The first level of configuration should concern you only if you're planning to compile YARP on a new operating system.

The second level is the hardware. A new addition on an existing platform or a new platform altogether might require preparing a few YARP device drivers. These are to all effects C++ classes that support the methods for accessing the hardware which is normally implemented through function calls to whatever provided by the hardware vendor. This comes typically in the form of either a DLL or a static library.

Finally, you can prepare configuration files for an entirely new robotic platform.

(*) We wrote this years and years ago, but in fact this statement doesn't seem to depend on the time of writing. The software expands to fill the cycles available, and then some.