YARP: a communication and device layer for robot software

What YARP is and the layer it occupies

YARP stands for Yet Another Robot Platform, and the README describes it as a library and toolkit for communication and device interfaces, used on everything from humanoids to embedded devices. That is a short description with a lot inside it. YARP is not a control framework, not a simulator and not a perception stack. It sits below those, in the layer where a robot's software has to talk to its sensors, to other processes on the same machine, and to other machines on the network.

The project topic list names the territory precisely: middleware, interprocess communication, devices, network, human-robot interaction, humanoids and robotics-libraries. So the scope is the plumbing that a robotics group would otherwise write for itself, once per robot family, usually with a different implementation on each platform.

The version history shows a project at a major-version boundary. Release 4.0.0 and 4.0.1 were both published on 2026-09-07, and 3.12.3 came on 2026-07-15, so the 4.x line is fresh and any documentation or tutorials you find may still describe the 3.x API. The repository was last pushed on 2026-10-19 and is not archived. Documentation lives at yarp.it, and the README points at a dedicated tutorials page listing the available guides, which is the fastest way to see whether the project covers the ground your robot needs.

Supported systems and what the CI list actually guarantees

The README publishes the systems that are officially supported and tested by GitHub CI, which is a shorter and more useful list than a compatibility matrix.

For Linux it is Ubuntu 22.04 with clang 17 and Ubuntu 22.04 with gcc 11.4.0. For Windows it is Windows 10.0.17763 with Visual Studio 16.11.2.50704 and Windows 10.0.20348 with Visual Studio 17.8.34309.116. For macOS it is 12.6.9 with clang 14.0.3 and 13.6 with clang 14.0.3.

Read that list as a floor, not a ceiling. Every entry pairs an operating system version with a specific compiler version, which means the project is pinning known-good combinations rather than claiming that any recent toolchain works. The two Windows entries spanning three Visual Studio generations is the clearest sign of the project's intent to keep older industrial and research machines working, which is a different priority from chasing the newest compiler.

The repository carries a CI workflow badge, a .ci directory and both .clang-format and .clang-tidy configurations, so formatting and linting are enforced rather than left to taste. It also uses the REUSE licensing tooling, with a .reuse directory and a LICENSES directory, which is the mechanism behind the mixed licence set described later.

Building YARP from source on Linux

The README points at the full installation instructions on the project site and then gives the Linux sequence, which starts with the build tools and the ACE development package.

sudo apt-get install cmake libace-dev
wget -nv https://github.com/robotology/ycm/releases/download/v0.15.3/ycm-cmake-modules-0.15.3-all.deb
sudo dpkg -i ycm-cmake-modules-0.15.3-all.deb
git clone https://github.com/robotology/yarp
cd yarp && mkdir build && cd build && cmake .. && make
sudo make install  # Optional

The second step is the one that surprises people. Before cloning YARP, the instructions install the ycm-cmake-modules package from a release of the robotology ycm repository, as a Debian package fetched with wget and installed with dpkg. So YARP's CMake build depends on an external CMake module package that has to be present on the machine first, and that is a separate repository with its own release numbering rather than something bundled in the YARP tree.

The clone and build itself is a standard out-of-source CMake build: clone the repository, create a build directory, enter it, run cmake and then make. Installing the result with make install is optional, so a developer can build and run from the build tree without touching system paths, which is the safer default on a shared robotics machine.

cmake ..

Since the build is CMake-driven, the usual variables apply, and the README names the one that matters most: on Linux and macOS, YARP can be compiled without ACE by adding -DSKIP_ACE=TRUE when running cmake. The command above is the plain configure step; adding that flag to it produces the ACE-free build.

The ACE dependency and what skipping it costs

Regular YARP builds use the ACE library, the Adaptive Communication Environment from the DOCGroup, and the Linux install step asks for libace-dev before anything else happens. ACE is what gives YARP its cross-platform transport layer, its threading model and its service-oriented pieces, so it is a foundational dependency rather than an optional extra.

The escape hatch matters because ACE is heavy and has a history of its own. The SKIP_ACE=TRUE path is documented for Linux and macOS only, so a Windows build does not have the same option, and that asymmetry is worth knowing before you plan a build matrix around it.

The cost of skipping ACE is that whatever YARP does with sockets, threads and event loops has to be done differently, and the guaranteed behaviour on the two platforms where the flag is available may not be identical to the ACE-backed behaviour elsewhere. If your deployment is Linux-only, the flag is a reasonable way to drop a large C++ dependency and its build time. If you plan to ship the same binaries on several platforms, staying with the default keeps one transport implementation across all of them.

What the repository contains: examples, bindings, containers and optional modules

The tree layout shows the breadth of the project. The src directory holds the library itself, bindings holds language bindings, cmake holds the build system, doc holds the documentation sources, docker holds container definitions, scripts holds helper tooling, extern holds vendored dependencies, data holds data files, and opt-modules holds optional components. Tests live in their own directory and AUTHORS records the contributors.

The example directory is the most informative part, because the folder names read like a table of contents for the library's feature surface. There are examples for the carrier, the dev layer, the framerate, the game layer, IDL, math, matrix handling, modular robots, OpenCV integration, operating system calls, Perl support, plugins, power management of ports, port monitoring, dynamic library loading, external devices and ImageMagick. A dedicated libYARP_serversql example, a ContainerExample and an RFModulePlugin example sit alongside them, and the directory also has its own README and CMakeLists.

Those names tell you what to expect from the library without needing the documentation: ports with an associated carrier protocol, a device abstraction layer, a rate control mechanism, an interface definition language for typed messages, port monitoring for debugging distributed systems, and a plugin mechanism for loading modules at runtime. The scripting language integration and the plugin examples are the two that most often decide whether an existing toolchain can be connected to a robot without a rewrite.

Licence mix, upgrade cost and where YARP is the wrong choice

The licence picture is the most complicated thing about YARP and the README is precise about it. Material included in YARP is copyright of the Istituto Italiano di Tecnologia, the RobotCub Consortium and other contributors. Most YARP components are released under the terms of the BSD-3-Clause licence, while some optional components are released under LGPL-2.1 or later, GPL-2.0 or later, GPL-3.0 or later, or the Apache-2.0 licence, with the COPYING and LICENSE files holding the details.

That is a manageable arrangement for most users, since the core is permissive, but it is not a single licence, and the optional components are exactly where the copyleft terms live. A commercial product that links an optional GPL component inherits obligations that the BSD core does not impose. The REUSE tooling in the repository, with its LICENSES directory, means the per-file terms are discoverable rather than implicit, and reading them before you link a specific optional module is the sensible step. The repository's own licence metadata is not detected automatically, so the LICENSE file at the root is the authoritative statement.

The wrong-tool case is straightforward. If your robot already ships with a middleware stack, or your team's other software is built around a DDS-based transport with global discovery, adding YARP gives you a second communication model rather than a better one. YARP is also a poor fit if you want a simulator, a behaviour tree framework or a perception pipeline, because none of that is in scope here. It is at its best when a group has accumulated several ad-hoc socket protocols across its robots and wants one tested, cross-platform layer with device interfaces underneath.

Editorial conclusion

YARP suits research groups that need a transport and device layer that spans several robots and several operating systems, and that want one codebase rather than a bespoke socket layer per robot. It is a poor fit for a project that needs ROS-level tooling, a simulator ecosystem or hardware that already comes with a mature middleware stack. Verify first that your platform is on the CI-tested list, that you can accept the ACE dependency or the SKIP_ACE build path, and that the component you need falls under the licence you can ship.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. robotology/yarp on GitHub