Using VREP for simulation of force-controlled models

I’ve been playing around a bit with different simulators, and one that we’re a big fan of in the lab is VREP. It’s free for academics and you can talk to them about licences if you’re looking for commercial use. I haven’t actually had much experience with it before myself, so I decided to make a simple force controlled arm model to get experience using it. All in all, there were only a few weird API things that I had to get through, and once you have them down it’s pretty straight forward. This post is going to be about the steps that I needed to take to get things all set up. For a more general start-up on VREP check out All the code in this post and the model I use can be found up on my GitHub.

Getting the right files where you need them

As discussed in the remote API overview, you’ll need three files in whatever folder you want to run your Python script from to be able to hook into VREP remotely:

  • remoteApi.dll, remoteApi.dylib or (depending on what OS you’re using)

You can find these files inside your VREP_HOME/programming/remoteApiBindings/python/python and VREP_HOME/programming/remoteApiBindings/lib/lib folders. Make sure that these files are in whatever folder you’re running your Python scripts from.

The model

It’s easy to create a new model to mess around with in VREP, so that’s the route I went, rather than importing one of their pre-made models and having some sneaky parameter setting cause me a bunch of grief. You can just right click->add then go at it. There are a bunch of tutorials so I’m not going to go into detail here. The main things are:

  • Make sure joints are in ‘Torque/force’ mode.
  • Make sure that joint ‘Motor enabled’ property is checked. The motor enabled property is in the ‘Show dynamic properties dialogue’ menu, which you find when you double click on the joint in the Scene Hierarchy.
  • Know the names of the joints as shown in the Scene Hierarchy.

So here’s a picture:

where you can see the names of the objects in the model highlighted in red, the Torque/force selection highlighted in blue, and the Motor enabled option highlighted in green. And of course my beautiful arm model in the background.

Setting up the continuous server

The goal is to connect VREP to Python so that we can send torques to the arm from our Python script and get the feedback necessary to calculate those torques. There are a few ways to set up a remote connection in VREP.

The basic one is they have you add a child script in VREP and attach it to an object in the world that sets up a port and then you hit go on your simulation and can then run your Python script to connect in. This gets old real fast. Fortunately, it’s easy to automate everything from Python so that you can connect in, start the simulation, run it for however long, and then stop the simulation without having to click back and forth.

The first step is to make sure that your remoteApiConnections.txt file in you VREP home directory is set up properly. A continuous server should be set up by default, but doesn’t hurt to double check. And you can take the chance to turn on debugging, which can be pretty helpful. So open up that file and make sure it looks like this:

portIndex1_port                 = 19997
portIndex1_debug                = true
portIndex1_syncSimTrigger       = true

Once that’s set up, when VREP starts we can connect in from Python. In our Python script, first we’ll close any open connections that might be around, and then we’ll set up a new connection in:

import vrep 

# close any open connections
# Connect to the V-REP continuous server
clientID = vrep.simxStart('', 19997, True, True, 500, 5) 

if clientID != -1: # if we connected successfully
    print ('Connected to remote API server')

So once the connection is made, we check the clientID value to make sure that it didn’t fail, and then we carry on with our script.


By default, VREP will run its simulation in its own thread, and both the simulation and the controller using the remote API will be running simultaneously. This can lead to some weird behaviour as things fall out of synch etc etc, so what we want instead is for the VREP sim to only run one time step for each time step the controller runs. To do that, we need to set VREP to synchronous mode. So the next few lines of our Python script look like:

    # --------------------- Setup the simulation 


and then later, once we’ve calculated our control signal, sent it over, and want the simulation to run one time step forward, we do that by calling

    # move simulation ahead one time step

Get the handles to objects of interest

OK the next chunk of code in our script uses the names of our objects (as specified in the Scene Hierarchy in VREP) to get an ID for each which to identify which object we want to send a command to or receive feedback from:

    joint_names = ['shoulder', 'elbow']
    # joint target velocities discussed below
    joint_target_velocities = np.ones(len(joint_names)) * 10000.0

    # get the handles for each joint and set up streaming
    joint_handles = [vrep.simxGetObjectHandle(clientID,
        name, vrep.simx_opmode_blocking)[1] for name in joint_names]

    # get handle for target and set up streaming
    _, target_handle = vrep.simxGetObjectHandle(clientID,
                    'target', vrep.simx_opmode_blocking)

Set dt and start the simulation

And the final thing that we’re going to do in our simulation set up is specify the timestep that we want to use, and then start the simulation. I found this in a forum post, and I must say whatever VREP lacks in intuitive API their forum moderators are on the ball. NOTE: To use a custom time step you have to also set the dt option in the VREP simulator to ‘custom’. The drop down is to the left of the ‘play’ arrow, and if you don’t have it set to ‘custom’ you won’t be able to set the time step through Python.

    dt = .01
            dt, # specify a simulation time step

    # --------------------- Start the simulation

    # start our simulation in lockstep with our code

Main loop

For this next chunk I’m going to cut out everything that’s not VREP, since I have a bunch of posts explaining the control signal derivation and forward transformation matrices.

So, once we’ve started the simulation, I’ve set things up for the arm to be controlled for 1 second and then for the simulation to stop and everything shut down and disconnect.

    while count < 1: # run for 1 simulated second

        # get the (x,y,z) position of the target
        _, target_xyz = vrep.simxGetObjectPosition(clientID,
                -1, # retrieve absolute, not relative, position
        if _ !=0 : raise Exception()
        track_target.append(np.copy(target_xyz)) # store for plotting
        target_xyz = np.asarray(target_xyz)

        q = np.zeros(len(joint_handles))
        dq = np.zeros(len(joint_handles))
        for ii,joint_handle in enumerate(joint_handles):
            # get the joint angles
            _, q[ii] = vrep.simxGetJointPosition(clientID,
            if _ !=0 : raise Exception()
            # get the joint velocity
            _, dq[ii] = vrep.simxGetObjectFloatParameter(clientID,
                    2012, # ID for angular velocity of the joint
            if _ !=0 : raise Exception()

In the above chunk of code, I think the big thing to point out is that I’m using vrep.simx_opmode_blocking in each call, instead of vrep.simx_opmode_buffer. The difference is that you for sure get the current values of the simulation when you use blocking, and you can be behind a time step using buffer.

Aside from that the other notable things are I raise an exception if the first parameter (which is the return code) is ever not 0, and that I use simxGetObjectFloatParameter to get the joint velocity instead of simxGetObjectVelocity, which has a rotational velocity component. Zero is the return code for ‘everything worked’, and if you don’t check it and have some silly things going on you can be veeerrrrryyy mystified when things don’t work. And what simxGetObjectVelocity returns is the rotational velocity of the joint relative to the world frame, and not the angular velocity of the joint in its own coordinates. That was also a briefly confusing.

So the next thing I do is calculate u, which we’ll skip, and then we need to set the forces for the joint. This part of the API is real screwy. You can’t set the force applied to the joint directly. Instead, you have to set the target velocity of the joint to some really high value (hence that array we made before), and then modulate the maximum force that can be applied to that joint. Also important: When you want to apply a force in the other direction, you change the sign on the target velocity, but keep the force sign positive.

        # ... calculate u ... 

        for ii,joint_handle in enumerate(joint_handles):
            # get the current joint torque
            _, torque = \
            if _ !=0 : raise Exception()

            # if force has changed signs,
            # we need to change the target velocity sign
            if np.sign(torque) * np.sign(u[ii]) < 0:
                joint_target_velocities[ii] = \
                        joint_target_velocities[ii] * -1
                        joint_target_velocities[ii], # target velocity
            if _ !=0 : raise Exception()

            # and now modulate the force
                    abs(u[ii]), # force to apply
            if _ !=0 : raise Exception()

        # move simulation ahead one time step
        count += dt

So as you can see we check the current torque, see if we need to change the sign on the target velocity, modulate the maximum allowed force, and then finally step the VREP simulation forward.


And there you go! Here’s an animation of it in action (note this is a super low quality gif and it looks way better / smoother when actually running it yourself):


All in all, VREP has been enjoyable to work with so far. It didn’t take long to get things moving and off the ground, the visualization is great, and I haven’t even scratched the surface of what you can do with it. Best of all (so far) you can fully automate everything from Python. Hopefully this is enough to help some people get their own models going and save a few hours and headaches! Again, the full code and the model are up on my GitHub.


  • When you’re applying your control signal, make sure you test each joint in isolation, to make sure your torques push things in the direction you think they do. I had checked the rotation direction in VREP, but the control signal for both joints ended up needing to be multiplied by -1.
  • Another nit when you’re building your model, if you use the rotate button from the VREP toolbar on your model, wherever that joint rotates to is now 0 degrees. If you want to set the joint to start at 45 degrees, instead double click and change Pos[deg] option inside ‘Joint’ in Scene Object Properties.
Tagged , , , ,

33 thoughts on “Using VREP for simulation of force-controlled models

  1. jandalf42JCK says:

    The html escaper destroyed your code, e.g. while count < 1:

  2. dds says:

    Did you have any problem with the simulation step configuration and dynamic engine simulation step?

  3. waggelfoot says:

    This was awesome. Thanks.

  4. waggelfoot says:

    As ever I am working through your stuff 🙂

    I think you have missed a 0.05m on line 90 in Your joint are offset various amounts on all the other arms, which you accounted for in L on line 85. Whilst your base block indeed has a height of 10cm, the shoulder is offset 5cm – I believe you haven’t included this offset, lest I am mistaken?

  5. […] clean code to generate everything we need for our controller. Using the controller developed in this post as a base, we can replace the calculations with compact code to create everything we […]

  6. Neil Dhir says:

    Hello again!

    Have you thought about using ‘vrep.simxGetObjectGroupData()’ to calculate the end effector position? I noticed that you’re currently doing it by hand as it were.

    • travisdewolf says:

      Howdy! Yup, I actually have some updated code I’m hoping to release in the next month or so that has that as an option, but for calculating the end-effector positions I still like to use the transforms to do it to make sure that as I’m tinkering around with the set up I don’t accidentally change anything that throws them off (because the transforms are then used to calculate the Jacobians for the controller).

  7. wagglefoot says:

    Oh dear there appears to be an issue with the out-of-the-box example on git too; see the raised issue (so sorry, your blog is great).

    • travisdewolf says:

      Hi Neil,

      thanks for finding this! I’ll try to address it asap!

    • travisdewolf says:

      Hi Neil,

      It turned out I had accidentally set the simulation time step to be too large. I dropped it to 1ms and that seems to have taken care of it! I also updated the code a bit to auto-disconnect and reset the sim in VREP, if you pull the controller code and ttt file again it should hopefully work for you now!

  8. adamconkey says:

    I tried running your code as is on Ubuntu 14.04, but it seems at every timestep the second joint (elbow) rapidly switches connecting position on link 2 (forearm) from proximal to distal back and forth. Have you seen that behavior at all or have an idea as to what might be causing it?

  9. Hi there,

    I’m currently studying your application, and trying to adapt it to a three-joint manipulator much like the one you’ve built, but I don’t have de slightest idea of what to change on the code itself. When I try to run it like it is, it starts flickering all over the place. What do I need to change on the code to support another link?

    • travisdewolf says:

      Hello! Can you confirm for me that it runs the two-link example without flickering all over the place? The most common cause of this that I’ve seen is the time step isn’t being set to 1ms.
      It needs to be set in a couple of places, could you check and let me know what it is in the three-link as well?

      • Yes, it does run smoothly with two-links. The time step is set as .001 everywhere it needs to be, apparently, so the two-link example works just fine. But translating it to the three-link one is the problem I’m facing. Adding another joint means adding another calculation to the code?

      • travisdewolf says:

        yup, you’ll need to change the calculation for the end-effector and also add in the jacobian for the COM of the third link, and add those into the inertia matrix calculation. But i’m surprised that it becomes unstable, could you send me your VREP file?
        when i have a chance i can take a look at it. you created it by modifying the two link modef from my repo and not starting from scratch, right?

  10. I was trying to do it from scratch, but using your model actually made the whole thing behave a lot smoother when I ran the code. But I didn’t modify it, so it didn’t really followed the position of the target, as I expected. However, I’ll try to account for the third link adding a JCOM matrix on the code. I’ll send the v-rep scene anyway, thank you for the assistance, your blog is awesome, even for someone that’s just starting, like I am!

    • travisdewolf says:

      ah, OK! so the reason i ask is because my model has the time step saved as .001, but when you create a new model it’s by default .01, which is probably the cause of this error (not going to the desired position is expected when not accounting for the 3rd link). you can set the time step in the tool bar by changing the drop down to the left of play from the (dt=50ms (default)) to the last option (dt=50ms (custom)), which will then allow the script to set the time step.

      Additionally, you might have to set it in the tools > calculation module properties > dynamics > adjust engine parameters section, by setting Configuration to Customized and then changing the Bullet time steps [s] parameter from .005 to .001.

      Glad that you’ve found the posts helpful, good luck! 🙂

  11. Gianluca says:

    Hi, I would like to implement a simplified version of this, with just a single mass (no manipulator, no joints, etc.) that moves on the plane, being controlled by a force. Have you got any idea on how to do this in V-REP? How can I set the mass to be in “force” mode?

  12. Duc says:

    Hi Travis,

    Thanks for the tutorial. It is very useful and well explained.

    But I don’t understand how you find the values of i1 = 0.5 and i2 = 0.1 used in the controller code.
    It is commented that these values are taken from the vrep simulator but when i checked the values of inertia in vrep, i found 8.121e-3 for the first shape and 2.224e-3 for the second. It is clear for me that in vrep inertia values are massless but i still don’t understand how you find the values of i1 and i2 used in the controller.

    • travisdewolf says:

      Whoops! Thanks for finding this! I had some weird values in there, must have been playing around and forgotten to reset things.
      I’ve changed them to the VREP settings now, and also added in gravity to the .ttt file (so make sure you pull that from the repo that too!)
      The controller was compensating for some gravity effects that weren’t being simulated, so now it’s working better. I don’t have time to tune it at the moment but hopefully this at least clears up the confusion!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: