/**
\page what_is_yarp What exactly is YARP?

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:

\li \link yarp_os YARP_os \endlink - 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++.

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

\li \link dev_all YARP_dev \endlink - 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.

*/
