Handling V-REP timeouts

[Lauchturm]

Hi Yuri,

today my scripts crashed quite often while resetting the environment and even in other places due to timeout signals. I found that simply waiting and retrying can help in these cases and was already writing a pull request when i found out that it still didn't quite always work. Do you experience the same issues? For now I have a loop that retries on timeouts at the simstop function but maybe RAPI_rc should handle timeouts differently and try to keep the program alive at the cost of some time.sleep()s. Let me know what you think about that!

Btw if you're not even working with V-REP anymore and this would be too time consuming for you (or any other reasons) I can also just silently work on a fork without bothering you too much.

Have a nice weekend, Julian

[ycps]

Hi Julian, unfortunately, I can't reproduce the timeout issue. Are you running the server and client in the same machine? Using Shared memory? Which physics engine are you using? I remember I had some issues with Newton Dynamics, it seems this engine had a memory leak issue, which could eventually lead to a timeout. If you can share more details (and maybe a minimal working example of a scene), I can try to help. Cheers, Yuri

[Lauchturm]

Funny that you never had that issue. I thought you'd also encountered them.

It's a single machine, bullet physics and the timeouts occur mostly around stopping and restarting the simulation in reset(). It occurred on macos the last days and I haven't tried another os yet. Will probably do sometime next week.

I'll look into resetting all positions via setpos instead of stopping and starting the sim. Right now I've managed with a different RAPI_rc wrapper like such:

def RAPI_rc_wrapper(self, func, *args, tolerance=vrep.simx_return_novalue_flag, **kwargs):
        while True:
            # print(f"calling {func.__name__} with args: {args} and kwargs: {kwargs}")
            ret_tuple = func(*args, **kwargs)
            istuple = isinstance(ret_tuple, tuple)
            ret = ret_tuple[0] if istuple else ret_tuple
            if (ret != vrep.simx_return_ok) and (ret != tolerance):
                if ret == vrep.simx_return_timeout_flag or ret == vrep.simx_error_timeout_flag:
                    print(f"{func.__name__} had vrep timeout #{i}")
                    time.sleep(5)
                    break
                else:
                    raise RuntimeError(
                        'Remote API return code: (' + str(ret) + ': ' + self.str_simx_return[ret.bit_length()] + ')')
            return ret_tuple[1:] if istuple else None

It's a bit dirty but does the trick for now, haha.

I will try Ubuntu and Win10 soon and see how it behaves there. Once my version is working well I will update my fork and send you a link to see if you think it's useful for the project - probably not if others are not having these timeouts, haha. Cheers

[Lauchturm]

Hey,

I'm slowly finishing my thesis and wanted to ask you if you want your last name to appear in the bibliography. If yes please let me know otherwise I will just cite this repo without your name.

btw I was able to confirm that the problem was caused by some power saving mechanism in MacOS that caused V-REP or the communication to it to sort of sleep when the program is out of focus for too long. Stupid and solved by my try catch blocks up there and/or keeping it in the front

Cheers

[ycps]

Hi Julian, thanks for the confirmation about the timeout issue. Regarding your thesis, I have no problem if you include my last name. You can do as you see fit. Cheers & congratulations on your thesis.

[nanbaima]

Funny that you never had that issue. I thought you'd also encountered them.

It's a single machine, bullet physics and the timeouts occur mostly around stopping and restarting the simulation in reset(). It occurred on macos the last days and I haven't tried another os yet. Will probably do sometime next week.

I'll look into resetting all positions via setpos instead of stopping and starting the sim. Right now I've managed with a different RAPI_rc wrapper like such:

def RAPI_rc_wrapper(self, func, *args, tolerance=vrep.simx_return_novalue_flag, **kwargs):
        while True:
            # print(f"calling {func.__name__} with args: {args} and kwargs: {kwargs}")
            ret_tuple = func(*args, **kwargs)
            istuple = isinstance(ret_tuple, tuple)
            ret = ret_tuple[0] if istuple else ret_tuple
            if (ret != vrep.simx_return_ok) and (ret != tolerance):
                if ret == vrep.simx_return_timeout_flag or ret == vrep.simx_error_timeout_flag:
                    print(f"{func.__name__} had vrep timeout #{i}")
                    time.sleep(5)
                    break
                else:
                    raise RuntimeError(
                        'Remote API return code: (' + str(ret) + ': ' + self.str_simx_return[ret.bit_length()] + ')')
            return ret_tuple[1:] if istuple else None

It's a bit dirty but does the trick for now, haha.

I will try Ubuntu and Win10 soon and see how it behaves there. Once my version is working well I will update my fork and send you a link to see if you think it's useful for the project - probably not if others are not having these timeouts, haha. Cheers

Hey Julian,

I'm facing the same problem as you did, after some interactions I'm getting V-REP timeouts, how did you fixed it? I'm using Ubuntu. Another thing, I didn't understand how to use and implement your solution. As I couldn't find any implementation of that on your fork.

[Lauchturm]

Stupid and solved by my try catch blocks up there and/or keeping it in the front

Not described well but all I did was to keep the window in the front of the screen and use that try-catch "fix".

[nanbaima]

Stupid and solved by my try catch blocks up there and/or keeping it in the front

Not described well but all I did was to keep the window in the front of the screen and use that try-catch "fix".

Just to better understand, what would be this try-catch "fix"? The solution of (> keeping the windows in the front of the screen) didn't work for me.