Table of Contents
The following diagram shows a typical setting of clients and software architecture for an URBI application. You have clients in C++, Java and Matlab running on different machines (with Linux, Windows, Mac OSX), remote UObjects plus onboard clients and plugged UObjects and some telnet/URBILab scripting. There is also a bench of controlling scripts running from the URBI.INI file. This example shows how flexible URBI can be, having all those systems running in parallel to control your robot.
You have an URBI server running on your robot and...
Remote control of a robot
Your robot is equipped with a wifi connection, like Aibo, and you run a complex AI program on a powerful desktop computer to control it. This program is actually an URBI client written in C++ and uses the liburbi C++ or UObject library to send URBI commands to the robot when needed and to receive URBI messages from the server asynchronously and react to them. You can replace C++ by Java, Matlab or any language you like if you don't want C++. You also have some UObject-based components running some nice vision algorithm for example.
Fully autonomous robot with an onboard URBI client / UObjects
This time, you run the URBI client or UObjects on the robot and not remotely. Just like before, it is written in C++ with the liburbi C++ or with the UObject architecture. Instead of a TCP/IP wifi based connection between your client and the server, you have a direct interprocess communication on localhost or direct shared memory access with UObject plugin mode.
Fully autonomous robot controlled only by URBI scripts
In that case, it means that you have found all the functionalities you need in URBI (no need for external C++ or Java programming) and you write directly all the action-perception loops with URBI scripts running in the URBI server, making use of some pre-existing or downloaded components in plugin mode. You need a simple telnet or URBI Remote to send your URBI scripts to the server and it is set. You can also store the script directly in the URBI.INI file and your robot will start it at boot up (no need at all for an external client or computer).
A mix of 1, 2 and 3
You have a robot controlled by several URBI clients at the same time, some on the robot, some on a desktop computer, some in C++, some in Java and Matlab. On top of that, you have several URBI scripts running in the server to perform reactive action-perception loops using some powerful UObjects written by you and also downloaded from the Internet, all this started from URBI.INI but also dynamically loaded by some of the clients when needed. This is the most interesting situation, making a full use of the URBI flexibility.