Remote API modus operandiThe remote API, or legacy remote API, should not be mixed-up with the BØ-based remote API, which is a newer version of the remote API that is more flexible, easier to use and most importantly, much simpler to extend. A remote API function is called in a similar fashion as a regular API function, however with 2 major differences: 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 (CoppeliaSim), 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: 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 CoppeliaSim 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 CoppeliaSim 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 CoppeliaSim 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. CoppeliaSim) to stop streaming that data, otherwise the server will continue to stream unnecessary 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 simRemoteApi.start 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: function sysCall_init() iteration=1 end function sysCall_sensing() simSetIntegerSignal('iteration',iteration) iteration=iteration+1 end function sysCall_cleanup() 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 incoming remote API commands are handled on the server side (i.e. on the CoppeliaSim remote API plugin side): [Remote API command handling, server side]
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 CoppeliaSim 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: Recommended topics | |