Means of communication in and around V-REP

Make sure you understand the overall structure of the simulator, and its API framework before going ahead reading this section.

V-REP's API supports following communication mechanisms to exchange random data between two entities:

[V-REP's messaging methods for random data]


Above's communication mechanisms, together with some alternative communication mechanisms (i.e. those that are not directly part of V-REP's API) are described hereafter:


Signals

Signals can be seen as global variables. Three types of signals are currently supported: integer-type signals, floating-type signals and string-type signals. Signals can be defined, redefined, read and cleared. At simulation end, all signals created by the main script or any child script will be cleared.


Tubes

Tubes are bidirectional communication lines similar to pipes. The tube denomination was selected in order to avoid confusion with pipes, since tubes cannot be used to communicate with the outside world. Tubes are a very convenient and easy means to connecting two entities and exchanging information in a sequential way. They are often used between a child script and a server-like threaded communication child script (e.g. where the latter could handle socket or serial port communication).


Wireless communication simulation

V-REP allows simulating wireless communications in a very flexible way: data can be emitted into a specific direction, and over a specific distance. Emitted data can then be received if the receiver is located within the specified emission area. Refer to the corresponding functions in the regular API for more details. Wireless emission/reception activities can be visualized by enabling the Visualize wireless emissions and Visualize wireless receptions items in the environment dialog. Following figure illustrates the visualized wireless communication between two mobile robots:

[Wireless communication simulation between two mobile robots]


Persistent Data

Persistent data blocks can be seen as persistent global buffers. Persistent data blocks can be defined, redefined, read and cleared, and are shared across all opened scenes. They persist until the simulator ends, but can also persist on file and automatically be reloaded next time V-REP starts.


Script simulation parameters

Child scripts can read and write data to their own, or other's script simulation parameters. Refer to the script simulation parameters dialog and to the related functions in the API for more information.


Custom Lua functions

The main client application or any plugin can register custom Lua functions via the Lua customization API commands. The custom Lua commands will then, when called from a script, call back a registered function in the main client application or a plugin. This is very convenient to achieve high level Lua commands (e.g. one could imagine having a plugin handle a robot's movement with a single Lua command simExtRobot_moveAndAvoidObstacles() !)


Serial port communication

V-REP implements specific functions in the API for serial port communication.


LuaSocket

V-REP ships with a Lua extension library called LuaSocket (see here for acknowledgements and credits related to this library). It allows performing various type of socket communication from within an embedded script or an add-on. Following code section illustrates how a threaded child script would fetch a webpage:

http=require("socket.http")
simSetThreadIsFree(true) -- Allow real threading from here (to avoid blocking V-REP)
page=http.request("http://www.google.com")
simSetThreadIsFree(false) -- Forbid real threading from here

Notice how the blocking part of the request command is put within a non-blocking section. For more information on how to avoid external commands to block, refer to the simSetThreadIsFree API command.

If your application requires socket communication, it is very convenient to set-up a threaded script as a request server and have the other scripts access it for socket communication as in following example:

The threaded request server:

http = require("socket.http")
-- Open a communication tube:
tubeHandle=simTubeOpen(0,'http_communication_test',1)

while (simGetSimulationState()~=sim_simulation_advancing_abouttostop) do
    -- Wait for a message in the tube and reat it:
    data=simTubeRead(tubeHandle,true)
    if (data) then
        -- Fetch the page:
        simSetThreadIsFree(true) -- Allow real threading from here (to avoid blocking V-REP)
        reply=http.request(data)
        simSetThreadIsFree(false) -- Forbid real threading from here
        -- Send back the page:
        if (reply) then
            simTubeWrite(tubeHandle,reply)
        else
            simTubeWrite(tubeHandle,'Page could not be retrieved')
        end
    else
        simSwitchThread() -- explicitely switch thread
    end
end

Following non-threaded child script example could then be used to access socket information:

if (sim_call_type==sim_childscriptcall_initialization) then
    -- Open a communication tube:
    tubeHandle=simTubeOpen(0,'http_communication_test',1)

    urlsToCheck={'http://www.google.com','http://www.yahoo.com','http://www.titech.co.jp'}
    urlIndex=1
end

if (sim_call_type==sim_childscriptcall_sensing) then
    s,r,w=simTubeStatus(tubeHandle)
    if (s==1)and(r==0)and(w==0) then
        -- Send a request for a page:
        simTubeWrite(tubeHandle,urlsToCheck[urlIndex])
    end
    if (s==1)and(r==1) then
        -- Read the reply (the page):
        page=simTubeRead(tubeHandle)
        print('URL: '..urlsToCheck[urlIndex])
        print(page:sub(1,200)) -- Only print the first 200 chars
        urlIndex=urlIndex+1
        if (urlIndex>3) then
            urlIndex=1
        end
    end
end

Custom communication

The user is free to implement any type of custom communication (e.g. sockets, pipes, etc.) with the outside world from the main client application or a plugin. Best is to create a communication thread that handles exclusively the communication. Make sure that the communication thread doesn't call any V-REP API commands, since that would lead to a crash. For examples, refer to the Robot language interpreter integration tutorial, or the remote API source code located in programming/remoteApi.


simBroadcastMessage call

The best way to achieve communication between two or more plugins is by using the simBroadcastMessage API function.


Lua extension library

It is possible to extend the means of communication of V-REP almost infinitely, by using Lua's extension library mechanism. As is done with the LuaSocket library (see above), you could add any other type of Lua extension library available online. You will just have to install the library in V-REP's installation directory according to the library's instructions. As illustrated with the LuaSocket here above, make sure you make use of a non-blocking section with the simSetThreadIsFree API command should an extension library command block V-REP.


Calling script functions

From the main client application, from a plugin, from an embedded script, from a remote API client or from a ROS node it is possible to call a script function using simCallScriptFunctionEx, or simxCallScriptFunction. The called script function can perform various tasks, then send back data to the caller.


Setting a script variable

From the main client application or from a plugin it is possible to set/clear script variables (i.e. Lua variables) using simSetScriptVariable.



Recommended topics

  • Writing code in and around V-REP
  • Embedded scripts
  • Add-ons
  • Plugins
  • The main client application
  • Regular API
  • Remote API
  • ROS interfaces