External controller tutorial
There are several ways one can control a robot or simulation in V-REP:
The most convenient way is to write a child script that will handle the behaviour of a given robot or model. It is the most convenient way, because child scripts are directly attached to scene objects, they will be duplicated together with their associated scene objects, they do not need any compilation with an external tool, they can run in threaded or non-threaded mode, they can be extended via custom Lua function or via a Lua extension library. Another major advantage in using child scripts: there is no communication lag as with the last 3 methods mentioned in this section (i.e. the regular API is used), and child scripts are part of the application main thread (inherent synchronous operation). There are several drawback to writing scripts however: you don't have the choice of the programming language, you can't have the fastest code, and you can't directly access external function libraries, except the Lua extension libraries.
Another way one can control a robot or a simulation is by writing a plugin. The plugin mechanism allows for callback mechanisms, custom Lua function registration, and of course access to external function libraries. A plugin is often used in conjunction with child scripts (e.g. the plugin registers custom Lua functions, that, when called from a child script, will call back a specific plugin function). A major advantage in using plugins is also that there is no communication lag as with the last 3 methods mentioned in this section (i.e. the regular API is used), and that a plugin is part of the application main thread (inherent synchronous operation). The drawbacks with plugins are: they are more complicated to program, and they need to be compiled with an external too. Refer also to the plugin tutorial.
A third and forth way one can control a robot or a simulation is by writing an external client application that relies on the remote API. This is a very convenient and easy way, if you need to run the control code from an external application, from a robot or from another computer. This also allows you to control a simulation or a model (e.g. a virtual robot) with the exact same code as the one that runs the real robot. The remote API comes in two versions: the B0-based remote API, and the legacy remote API.
A fifth way to control a robot or a simulation is via a ROS node. In a similar way as the remote API, ROS is a convenient way to have several distributed processes communicate with each other. While the remote API is very lightweight and fast, it allows only communication with V-REP. ROS on the other hand allows connecting virtually any number of processes with each other, and a large amount of compatible libraries are available. It is however heavier and more complicated than the remote API. Refer to the ROS interfaces for details.
A sixth way to control a robot or a simulation is via a BlueZero (BØ) node. In a similar way as ROS, BlueZero is a convenient way to have several distributed processes communicate with each other, and is a lightweight and cross-platform solution. Refer to the BlueZero interface for details.
A seventh way to control a robot or a simulation is by writing an external application that communicates via various means (e.g. pipes, sockets, serial port, etc.) with a V-REP plugin or V-REP script. Two major advantages are the choice of programming language, which can be just any language, and the flexibility. Here also, the control code can run on a robot, or a different computer. This way of controlling a simulation or a model is however more tedious that the methods with the remote API.
There are 7 scene files related to this tutorial:
scenes/controlTypeExamples/controlledViaScript: one robot is controlled via a non-threaded child script, the other is controlled via a threaded child script.
scenes/controlTypeExamples/controlledViaPlugin: the robot is controlled via a plugin.
scenes/controlTypeExamples/controlledViaB0RemoteApi: the robot is controlled via the B0-based remote API.
scenes/controlTypeExamples/controlledViaLegacyRemoteApi: the robot is controlled via the legacy remote API.
scenes/controlTypeExamples/controlledViaB0: the robot is controlled via the BlueZero interface.
scenes/controlTypeExamples/controlledViaRos: the robot is controlled via the ROS interface.
scenes/controlTypeExamples/controlledViaTcp: the robot is controlled via LuaSocket and TCP.
In all 7 cases, child scripts are used, mainly to make the link with the outside world (e.g. launch the correct client application, and pass the correct object handles to it). There are two other ways one can control a robot, a simulation, or the simulator itself: by using customization scripts, or add-ons. They are however not recommended for control and should be rather used to handle functionality while simulation is not running.
As an example, the child script linked to the robot in scene controlledViaB0RemoteApi.ttt has following main task:
Launch the controller application (bubbleRobClient_b0RemoteApi) with some object handles as arguments. The server functionality of the B0-based remote API is provided by object b0RemoteApiServer.
As another example, the child script linked to the robot in scene controlledViaRos.ttt has following main tasks:
Check if the RosInterface for V-REP was loaded
Launch the controller application (rosBubbleRob2) with some topic names or object handles as arguments
Yet, as another example, the child script linked to the robot in scene controlledViaTcp.ttt has following main tasks:
Search for a free socket connection port
Launch the controller application (bubbleRobServer) with the chosen connection port as argument
Locally connect to the controller application
At each simulation pass, send the sensor values to the controller, and read the desired motor values from the controller
At each simulation pass, apply the desired motor values to the robot's joints
Run the simulations, and copy-and-paste the robot: you will see that the duplicated robots will directly be operational, since their attached child scripts are in charge of launching new instances of their respective external applications, or calling the appropriate plugin functions.