Remote API modus operandi

A remote API function is called in a similar fashion as a regular API function, however with 2 major differences:

  • most remote API functions return a similar value: a return code. Always remember that the return code is bit-coded (so you will have to test the individual bits in order to correctly interpret it).
  • most remote API functions require two additional argument: the operation mode, and the clientID (identifier returned by the simxStart function)
  • The need for an operation mode and a specific return code comes from the fact that the remote API function has to travel via socket communication to the server (V-REP), execute a task, then return to the caller (the client). A naive (or regular) approach would be to have the client send a request, and wait until the server processed the request and replied: in most situations this would take too much time and the lag would penalize the client application. Instead, the remote API lets the user chose the type of operation mode and the way simulation advances by providing four main mechanisms to execute function calls or to control the simulation progress:

  • Blocking function calls
  • Non-blocking function calls
  • Data streaming
  • Synchronous operation


  • Blocking function calls: a blocking function call is the naive or regular approach, and meant for situations where we cannot afford not to wait for a reply from the server, like in following situation:

    // Following function (blocking mode) will retrieve an object handle:
    if (simxGetObjectHandle(clientID,"myJoint",&jointHandle,simx_opmode_blocking)==simx_return_ok) 
    {
        // here we have the joint handle in variable jointHandle!    
    }

    Following diagram illustrates a blocking function call:

    [Blocking function calls]


    Non-blocking function calls: a non-blocking function call is meant for situations when we simply want to send data to V-REP without the need for a reply, like in following situation:

    // Following function (non-blocking mode) will set the position of a joint:
    simxSetJointPosition(clientID,jointHandle,jointPosition,simx_opmode_oneshot); 
    

    Following diagram illustrates non-blocking function calls:

    [Non-blocking function calls]


    In some situations, it is important to be able to send various data within a same message, in order to have that data also applied at the same time on the server side (e.g. we want the 3 joints of a robot to be applied to its V-REP model in the exact same time, i.e. in the same simulation step). In that case, the user can temporarily halt the communication thread in order to achieve this, as shown in following example:

    simxPauseCommunication(clientID,1);
    simxSetJointPosition(clientID,joint1Handle,joint1Value,simx_opmode_oneshot);
    simxSetJointPosition(clientID,joint2Handle,joint2Value,simx_opmode_oneshot);
    simxSetJointPosition(clientID,joint3Handle,joint3Value,simx_opmode_oneshot);
    simxPauseCommunication(clientID,0);
    
    // Above's 3 joints will be received and set on the V-REP side at the same time

    Following diagram illustrates the effect of temporarily halting the communication thread:

    [Temporarily pausing the communication thread]


    Data streaming: the server can anticipate what type of data the client requires. For that to happen, the client has to signal this desire to the server with a "streaming" or "continuous" operation mode flag (i.e. the function is stored on the server side, executed and sent on a regular time basis, without the need of a request from the client). This can be seen as a command/message subscription from the client to the server, where the server will be streaming the data to the client. Such a streaming operation request and reading of streamed data could look like this on the client side:

    // Streaming operation request (subscription) (function returns immediately (non-blocking)):
    simxGetJointPosition(clientID,jointHandle,&jointPosition,simx_opmode_streaming);
    
    // The control loop:
    while (simxGetConnectionId(clientID)!=-1) // while we are connected to the server..
    { 
        // Fetch the newest joint value from the inbox (func. returns immediately (non-blocking)):
        if (simxGetJointPosition(clientID,jointHandle,&jointPosition,simx_opmode_buffer)==simx_return_ok) 
        { 
            // here we have the newest joint position in variable jointPosition!    
        }
        else
        {
            // once you have enabled data streaming, it will take a few ms until the first value has arrived. So if
            // we landed in this code section, this does not always mean we have an error!!!
        }
    }
    
    // Streaming operation is enabled/disabled individually for each command and
    // object(s) the command applies to. In above case, only the joint position of
    // the joint with handle jointHandle will be streamed.

    Following diagram illustrates data streaming:

    [Data streaming]


    Once you are done streaming the data, the remote API client should always inform the server (i.e. V-REP) to stop streaming that data, otherwise the server will continue to stream unessesary data and eventually slow down. Use the simx_opmode_discontinue operation mode for that.


    Synchronous operation: from above function calls you might have noticed that a simulation will advance or progress without taking into account the progress of the remote API client. Remote API function calls will be executed asynchronously by default. There are however situations where the remote API client needs to be synchronized with the simulation progress, by controlling the simulation advance from the remote API client side. This can be achieved by using the remote API synchronous mode. The remote API server service needs in that case to be pre-enabled for synchronous operation (this can be achieved via the simExtRemoteApiStart function, or via the continuous remote API server service configuration file remoteApiConnections.txt). Following is an example of the synchronous mode:

    simxSynchronous(clientID,true); // Enable the synchronous mode (Blocking function call)
    simxStartSimulation(clientID,simx_opmode_oneshot);
    
    // The first simulation step waits for a trigger before being executed
    
    simxSynchronousTrigger(clientID); // Trigger next simulation step (Blocking function call)
    
    // The first simulation step is now being executed
    
    simxSynchronousTrigger(clientID); // Trigger next simulation step (Blocking function call)
    
    // The second simulation step is now being executed
    
    ...

    Following diagram illustrates the synchronous mode:

    [Synchronous mode]


    When calling simxSynchronousTrigger, the next simulation step will start computing. This doesn't mean that when the function call returns, the next simulation step will have finished computing. For that reason you have to make sure to read the correct data. If no special measure is taken, you might read data from previous simulation step, or from current simulation step, as illustrated in following diagram:

    [Synchronous mode, uncertain data update]


    You have several possibilities to overcome above problematic situation. The simplest is to call a function in a blocking fashion directly after calling simxSynchronousTrigger:

    simxSynchronous(clientID,true); // Enable the synchronous mode (Blocking function call)
    simxStartSimulation(clientID,simx_opmode_oneshot);
    
    // The first simulation step waits for a trigger before being executed
    
    simxSynchronousTrigger(clientID); // Trigger next simulation step (Blocking function call)
    
    // The first simulation step is now being executed
    
    simxGetPingTime(clientID); // After this call, the first simulation step is finished (Blocking function call)
    
    // Now we can safely read all streamed values

    Following diagram illustrates above procedure:

    [Synchronous mode, correct data update]


    When you have several remote API clients that each need to send their trigger for next simulation step to start, then you should place following code inside of a non-threaded child script in your scene:

    if (sim_call_type==sim_childscriptcall_initialization) then
       iteration=1
    end
    
    if (sim_call_type==sim_childscriptcall_sensing) then
       simSetIntegerSignal('iteration',iteration)
       iteration=iteration+1
    end
    
    if (sim_call_type==sim_childscriptcall_cleanup) then
       simClearIntegerSignal('iteration')
    end

    and following code in each one of your remote API clients:

    // enable the synchronous mode on the client:
    simxSynchronous(clientID,1);
    
    // start the simulation:
    simxStartSimulation(clientID,simx_opmode_blocking);
    
    // enable streaming of a value:
    int anyValue;
    simxGetIntegerSignal(clientID,"anyValue",&anyValue,simx_opmode_streaming);
    
    // enable streaming of the iteration counter:
    int iteration1;
    simxGetIntegerSignal(clientID,"iteration",&iteration,simx_opmode_streaming);
    
    // Now step a few times:
    for (int i=0;i<30;i++)
    {
        int res=simxGetIntegerSignal(clientID,"iteration",&iteration1,simx_opmode_buffer);
        if (res!=simx_return_ok)
            iteration1=-1;
        simxSynchronousTrigger(clientID);
        int iteration2=iteration1;
        while (iteration2==iteration1)
        { // wait until the iteration counter has changed
            res=simxGetIntegerSignal(clientID,"iteration",&iteration2,simx_opmode_buffer);
            if (res!=simx_return_ok)
                iteration2=-1;
        }
    
        // Now fetch other values:
        simxGetIntegerSignal(clientID,"anyValue",&anyValue,simx_opmode_buffer);
        printf("Streamed value: %i\n",anyValue) // this is the freshest value
    }

    In above code just make sure that the last streaming command that you enabled is for signal iteration, otherwise iteration will not be the last updated value.



    Following diagram illustrates how incomming remote API commands are handled on the server side (i.e. on the V-REP remote API plugin side):

    [Remote API command handling, server side]



    Additional details

    On the client side (i.e. your application), at least 2 threads will be running: the main thread (the one from which you will be calling remote API functions), and the communication thread (the one that will be handling data transfers behind the scenes). There can be as many communication threads (i.e. communication lines) as needed on the client side: make sure to call simxStart for each one of them. The server side, which is implemented with a V-REP plugin, operates in a similar way. Following figure illustrates the remote API modus operandi:

    [Remote API functionality overview]


    Following describes the various supported modes of operations:

  • simx_opmode_oneshot: non-blocking mode. A command is sent to the server for execution (1)-(b)-(3). A reply to a same command, but previously executed, is returned from a local buffer, if available (i)-(2). The function doesn't wait for a reply from the server (7)-(i). On the server side, the command is stored temporarily (4)-(d), executed once (d)-(9)-(g) and a reply sent back (g)-(6). This mode is often used with "set-functions" (e.g. simxSetJointPosition), where the user doesn't care about the return value.
  • simx_opmode_blocking: blocking mode. A command is sent to the server for execution (1)-(b)-(3), and the function waits for the reply from the server (7)-(i)-(2). The received reply will then be erased from the inbox buffer (i), which doesn't happen with the other operation modes. On the server side, the command is stored temporarily (4)-(d), executed once (d)-(9)-(g) and a reply sent back (g)-(6). This mode is often used with "get-functions" (e.g. simxGetObjectHandle), where the user requires a reply to the sent command.
  • simx_opmode_streaming: non-blocking mode. A command is sent to the server for execution (1)-(b)-(3). A reply to a same command, but previously executed, is returned from a local buffer, if available (i)-(2). The function doesn't wait for a reply from the server (7)-(i). Similar to simx_opmode_oneshot, but with the difference that the command will be stored on the server side (4)-(e), continuously executed (e)-(9)-(g), and continuously sent back to the client (g)-(6). This mode is often used with "get-functions" (e.g. simxGetJointPosition), where the user requires a specific value constantly.
  • simx_opmode_oneshot_split (not recommended): non-blocking mode. A command is sent gradually (in small data chunks) to the server for execution (1)-(a)-(3). A reply to a same command, but previously executed, is returned from a local buffer, if available (i)-(2). The function doesn't wait for a reply from the server (7)-(h)-(i). When the command was fully sent, it is removed from (a). On the server side, the command chunks are remporarily stored (4)-(c) and when the command was fully received, the command will be executed once (5)-(d)-(9)-(f) and a reply gradually sent back to the client (f)-(6). The client receives the reply in small chunks (7)-(h) and when the reply is complete, it is stored in the local buffer (8)-(i). This mode is often used with "set-functions" associated with large amounts of data (e.g. simxSetVisionSensorImage), in order not to overload the communication network.
  • simx_opmode_streaming_split (not recommended): non-blocking mode. A command is sent gradually (in small data chunks) to the server for execution (1)-(a)-(3). A reply to a same command, but previously executed, is returned from a local buffer, if available (i)-(2). The function doesn't wait for a reply from the server (7)-(h)-(i). When the command was fully sent, it is removed from (a). On the server side, the command chunks are remporarily stored (4)-(c) and when the command was fully received (5)-(e), the command will be executed continuously (e)-(9)-(f) and a reply gradually sent back to the client (f)-(6). The client receives the reply in small chunks (7)-(h) and when the reply is complete, it is stored in the local buffer (8)-(i). This mode is often used with "get-functions" associated with large amounts of data (e.g. simxGetVisionSensorImage), where the user requires data constantly without overloading the communication network.
  • simx_opmode_discontinue: non-blocking mode. A command is sent to the server (1)-(b)-(3). A reply to a same command, but previously executed, is returned from a local buffer, if available (i)-(2). The function doesn't wait for a reply from the server (7)-(i). On the server side, the command simply clears a similar command that is located in (e). A reply is sent to the client (6)-(7) that will also clear a similar reply located in (i). This mode is used to release some memory in (i) (similar to simx_opmode_remove), or to interrupt streaming commands (i.e. by removing them from (e)).
  • simx_opmode_buffer: non-blocking mode. No command is sent to the server, but just a reply to a same command, previously executed, is returned from a local buffer, if available (i)-(2). This mode is often used in conjunction with the simx_opmode_streaming or simx_opmode_streaming_split operation mode: first, a constant command execution is started with a streaming command, then only command replies fetched.
  • simx_opmode_remove: non-blocking mode. No command is sent to the server, but just a reply to a same command, previously executed, is cleared from the local buffer, if present (i). The function doesn't return any values, except for a return code. This mode can be used to release some memory on the client side, but is rarely necessary.


  • Recommended topics

  • Remote API overview
  • Extending the remote API