vrep demo problem.

[Marek Gawryszewski]

I'm trying to run vrepdemo.m from RTB9.10 but without success.
I have encountered error:

>> vrepdemo
Running Matlab win32
Note: always make sure you use the corresponding remoteApi library
(i.e. 32bit Matlab will not work with 64bit remoteApi, and vice-versa)

p =

    4.4821   -7.5992    4.3189

--VREP destructor called
Error using remApi/simxGetObjectPosition
Method 'simxGetObjectPosition' is not defined for class 'remApi' or is removed from MATLAB's search path.

Error in VREP/getpose (line 845)
            [s,pos] = obj.vrep.simxGetObjectPosition(obj.client, h, relto, obj.mode);

Error in VREP_obj/getpose (line 171)
                p = obj.vrep.getpose(obj.h);

Error in vrepdemo (line 28)
T = bill.getpose()

I can connect to VREP, and I can see, that "Bill" object has been created.
Any advice, what to look for?

I'm using RTB 9.10, Matlab 2012b and V-REP 3.2.3 rev 4, both 32bit.

Thanks in advance.

[Peter Corke]

you need to help the script find the VREP binary

>> help vrepdemo

  open a connection to the VREP simulator

 

  Notes::

  - the VREP constructor needs to know where V-REP is installed.

  - This can come from the environment variable VREP

  - Or you can edit this file to something like

     vrep=VREP('/Applications/V-REP_PRO_EDU_V3_1_3_rev2b_Mac');

[Marek Gawryszewski]

Hi,
It seems resolved my problem.
As Peter suggested, I added full path in vrepdemo.m (line 19), but there is also one change that needs to be done in VREP.m.

            libpath = { fullfile(opt.path, 'programming', 'remoteApi')
                fullfile(opt.path, 'programming', 'remoteApiBindings', 'matlab', 'matlab')
                fullfile(opt.path, 'programming', 'remoteApiBindings', 'lib', 'lib')
                };

has to be extended with '32Bit'

            libpath = { fullfile(opt.path, 'programming', 'remoteApi')
                fullfile(opt.path, 'programming', 'remoteApiBindings', 'matlab', 'matlab')
                fullfile(opt.path, 'programming', 'remoteApiBindings', 'lib', 'lib', '32Bit')
                };

I suppose this is a matter of latest version of V-REP.
Anyway, vrepdemo crashes at:

Undefined function 'idisp' for input arguments of type 'uint8'.

Error in VREP_camera/grab (line 206)
                idisp(image);

Error in vrepdemo (line 75)
    camera.grab();

but I suppose this is a matter of paths, so maybe little fix will help.

Happy vrepping:-)

[Peter Corke]

Marek, thanks for experimenting with this interface.  It's hard to progress or develop code in a vacuum so your testing is very helpful.

Are you on a Windows machine?  Maybe the 32 bit option is specific to that?

idisp() is a Machine Vision Toolbox function that is quite independent of VREP.  You need to install MVTB from my website, it's the sister toolbox for RTB.  Alternatively you could replace the call to idisp() with image() which is a builtin MATLAB function to display images.

peter

[Marek Gawryszewski]

Hello,
Good to know, that it was useful.

Yes, I'm using Windows 7 64bit.
Actulally, the interface was divided into 32Bit and 64Bit thee are two folders with remoteApi binaries. I suppose this is a matter of recent update of V-REP.
In case of Windows, there is only one version of V-REP, and I suppose it is 32-bit (it is installed in Program Files(x86) ). On Linux, there are 64 an 32bit versions.

It seems that Matlab is _very_ fragile to path issues and this is main problem in using VREP with RTB. Anyway, I'll work on it.

[paul.mes...@gmail.com]

Hello,

I had the same issue, and the above solutions works great on ubuntu 64Bit.
I put in vrepdemo.m :

vrep = VREP('path', '/home/pauka/V-REP_PRO_EDU_V3_2_3_rev4_64_Linux');

in VREP.m, I add the version (64Bit) in libpath :

libpath = { fullfile(opt.path, 'programming', 'remoteApi')
                fullfile(opt.path, 'programming', 'remoteApiBindings', 'matlab', 'matlab')

                fullfile(opt.path, 'programming', 'remoteApiBindings', 'lib', 'lib', '64Bit')
                };

Next, same issue with idisp, so I have replace idisp for 'image', works great. But the next issue is :

Error using remApi/simxStartSimulation
Method 'simxStartSimulation' is not defined for

class 'remApi' or is removed from MATLAB's search
path.

Error in VREP/simstart (line 322)
            s =
            obj.vrep.simxStartSimulation(obj.client,
            obj.mode);

Error in vrepdemo (line 76)
vrep.simstart();
 
But in fact, I looked in V-REP_PRO_EDU_V3_2_3_rev4_64_Linux/programming/remoteApi/extApi.h and the method exists :

EXTAPI_DLLEXPORT simxInt simxStartSimulation(simxInt clientID,simxInt operationMode);

The path extApi.h is in the path because it is added in VREP :

libpath = { fullfile(opt.path, 'programming', 'remoteApi')
                fullfile(opt.path, 'programming', 'remoteApiBindings', 'matlab', 'matlab')

                fullfile(opt.path, 'programming', 'remoteApiBindings', 'lib', 'lib', '64Bit')
                };

So I don't know....

[mgaw...@gmail.com]

Hello Paul,
I have an impression, that remoteApi sometimes behaves in a strange way: first simulation runs correctly, but following ones are failing, and I do not exactly why. I suppose, you have similiar problem to mine.
For now I do not see any solution for this, maybe it is time to ask Coppelia for help.

[marc]

Hello,

Yes, this can happen in certain circumstances. With

vrep=remApi('remoteApi')

the remote API dll will be loaded into Matlab's memory. There is an unload function in Matlab that doesn't seem to work properly, at least on some systems.
So the library will sit all the time in memory. But one should always make sure to have all opened connections closed before starting again. You typically do this with:

vrep.simxFinish(-1);

If that doesn't help: can you describe a very simply procedure that illustrates your problem, so that I can reproduce it here?

[Peter Corke]

Thanks Marc.  For those that don't know Marc is THE creator of VREP, great to have his input.

[Marek Gawryszewski]

Hello Marc,
Thanks for this info, I'll try it today.
Good to have you here:-)

[Marek Gawryszewski]

Hello.
I made some tests, and it seems that I found a way to make almost everything work.
1. In case of error Matlab script is interrupted immediately, so destructor is not called automatically. I bet there is a better way, but 'clear' worked for me. Is there a way to call it in case of error?
2. To call simxFinnish I had to change a little the syntax:

vrep.vrep.simxFinish(-1);

For now, VREP demo works for me except camera.

Cheers!

W dniu poniedziałek, 8 lutego 2016 19:12:58 UTC+1 użytkownik marc napisał:

[paul.mes...@gmail.com]

There is an error in the above correction for idisp.

You don't have to only replace idisp to image because there is a variable called image, so the new code in renaming the variable is :

% replace 'image' to 'img'
[s,res,img] = obj.vrep.vrep.simxGetVisionSensorImage2(obj.vrep.client, obj.h, opt.grey, obj.vrep.vrep.simx_opmode_oneshot_wait);
if s ~= 0
    throw( obj.except(s) );
end
%fprintf('Captured %dx%d image\n', res(1), res(2));

if nargout == 0
    % the same
    image(img);
elseif nargout > 0
    % the same
    im = img;
end

I don't know why but there is no more the error with remApi/simxGetObjectPosition.

But now, an error occur after the camera moving :

Error using VREP/clearscene (line 418)
function caused an error on the server side (e.g. an invalid
handle was specified)

Error in vrepdemo (line 84)
vrep.clearscene();

For info, my procedure is that :

- run vrep.sh
- run matlab -> I run automatically add(genpath('/path/to/rvctools'))
- run startup_rvc
- vrepdemo

And the error occur after 5 five seconds of camera displaying.

Le vendredi 8 janvier 2016 13:11:25 UTC+1, Marek Gawryszewski a écrit :

[marc]

Hello Marek,

the destructor is actually empty, mainly because of the unloadlibrary problem. I also remember trying my chance with 'clear', but without success (the library still staying in memory).

Cheers

[marc]

Hello Paul,

in case you are trying to retrieve an image from V-REP, and if there is a error on the server side, this can only be because the specified object handle (i.e. vision sensor handle) is not valid (or not valid anymore). If you have started streaming an image from a vision sensor, and then erase the vision sensor, this will happen. A started streaming command should always be stopped with the operation mode simx_opmode_discontinue.

Cheers