The RobotCub software architecture is based on YARP, an open-source framework that supports distributed computation with an eye at robot control and efficiency. In short, we decided to adopt YARP for RobotCub while keeping the two project separated. Yarp is a set of libraries which can be embedded in many different systems and robots, while for the iCub we customize Yarp to handle its hardware and devices. iCub's code is client code with respect to YARP.
YARP provides a set of protocols and a C++ implementation for:
- Inter-process communication on a local network, in fact enabling parallel multi-processor computation.
- Standardization of the hardware interface through run-time dynamically loadable modules.
- Data types for images, vectors, buffers, etc.
- Various interfaces to commonly used open-source packages (e.g. openCV).
To learn more about the philosophy of Yarp you can see the paper:
G. Metta, P. Fitzpatrick, L. Natale. YARP: yet another robot platform. In the International Journal on Advanced Robotics Systems, Special Issue on Software Development and Integration in Robotics. March 2006. (pdf)
or a more recent submission:
P. Fitzpatrick, G. Metta, L. Natale. Towards Long-Lived Robot Genes. March 2007. (pdf)
A manual including a description of Yarp's standard protocols is available:
And full documentation (online) from:
Developing iCub Software with Yarp: A Novice User's View
There are three ways you can view Yarp as an implementation platform for iCub software.
- The first is to see it as a network of processes with which your code interfaces via ports using Yarp-compatible iCub control and data acquisition protocols. These protocols are specific to the iCub. Your code should also be written as a Yarp process, with a well-specified port-based interface protocol.
- The second is a device view. Here, your code is more closely coupled with Yarp. Yarp is simply a class hierarchy and your iCub application code is directly linked with the Yarp objects, with control and data acquisition being achieved by method invocation.
- Both of these views are remote views (in the sense that you can assume that all the iCub devices are set up and just need to be polled). There is a third view that is local and it is a counter-part of the second - device - view above. In this case, however, your iCub application software has much greater control but it also has much greater responsibility for configuration of the iCub devices and for bootstrapping them.
Most application developers will choose approach no. 1. Those who are particularly concerned about efficiency will choose no. 2, and those with very strong timing constraints will choose approach no. 3.
Using view no. 1, an application will typically comprise several Yarp processes. This means that to run your iCub application, you need to invoke each process and also instantiate the port-based communication between them. You can instantiate the communications between the Yarp iCub processes with in-line code embedded in your software but the Yarp philosophy is to decouple the process functionality from the specification of the inter-process (port-to-port) connections. This encourages modular software with reusable processes that can be used in a variety of configurations that are not dependent on the functionality of the process or embedded code. Thus, e.g., the processes might be invoked and the connections instantiated using a script.
We plan on implementing the iCub cognitive architecture as a set of Yarp processes. That is, we expect that each of the iCub phylogenetic abilities as well as the modules for their modulation, for prospection and anticipation, and for self-modification, will be implemented as distinct Yarp processes.
Further information on Yarp
For further information on how to obtain, compile, and use Yarp please see:
iCub specific material
The RobotCub repository is described at:
- Notes on CVS: RobotCub repository
- iCub software documentation
- Details are also available from Deliverable 8.2 and from Deliverable 7.3
- RobotCub CVS server
- VVV Summer School 2006
RobotCub licenses (GPL/FDL) that also apply to software are available at: