## Inaccurate simulation when complexity increase

Report crashes, strange behaviour, or apparent bugs
thereisnospoon
Posts: 5
Joined: 14 Oct 2019, 07:34

### Inaccurate simulation when complexity increase

Hi,

This is Joe, a PhD candidate.
I am currently using VREP version and with setting as below:
- 3.6.2 (rev. 0) 64bit
- Bullet 2.83
- Very accurate
- dt=20ms
- mode: vrep.simxSynchronousTrigger(clientID)
- for vrep.simxSetJointTargetVelocity I am using vrep.simx_opmode_oneshot_wait and wait until it return ok, to make sure that the command reach each actuator.
- 231 omniwheels & 231 actuator. Omniwheels were modelled by using spheres.

I have been using VREP since the past 1 year to create an omnidirectional conveyor called EOCC (see fig 1). See the published work at here: https://www.mdpi.com/2075-1702/9/2/43

Please let me explain the problem I am facing now. Please bear with me.
Everything is fine when I am using only one carton. Until today when I add one more carton (total = two). See fig 2.

In all the cases below, both the cartons never touch each other, and without sharing a same actuator etc. They are significantly far apart.

The result when 2 cartons are running together: https://drive.google.com/file/d/1FOhHav ... sp=sharing

With exactly the same coding and algorithm, the result when ONLY left carton is running:
I off the controller for right carton.

With exactly the same coding and algorithm, when I remove the carton on the right in the VREP, and let only the left carton running:

Three similar condition and setting for the carton on the left, but I get three different result...
It seems like VREP acts differently when complexity changes?

Thanks.

coppelia
Posts: 8889
Joined: 14 Dec 2012, 00:25

### Re: Inaccurate simulation when complexity increase

Hello,

it is very difficult to say what is going on. If your scene does not otherwise react because of the second box (i.e. the second box has no influence on your control algorithm and or sensors), then the problem lies entirely with the physics engine. Make sure that this is the case. Physics engines sometimes behave in an unexpected manner, e.g. in order to speed-up computations with a complex world, etc.).
Also try to further adjust the overall parameters of the physics engine (e.g. time step of 5ms, constraint solving iterations of 500) and/or the material properties.
How do the other engines run the simulation?

Two additional comments: It seems you are simulating the omni-wheels from reality. Oftentimes you get better and still very accurate results by mimicing on omi-wheel behaviour (have a look at the Kuka omnirob or Kuka YouBot for an example of what I mean).
Additionally, it is always recommended to run the newest version of CoppeliaSim.

Cheers

thereisnospoon
Posts: 5
Joined: 14 Oct 2019, 07:34

### Re: Inaccurate simulation when complexity increase

Hi,

"time step of 5ms, constraint solving iterations of 500" --> I set them to 1ms and 500, respectively.
500 iterations doesn't change much, but 1ms of time step significantly make the simulation of 2 cartons better.

So, I have a new question, is it lower the time step + higher iterations = more accurate simulation and closes to real-life?
What's the ideal setting? Or this is a very subjective question?

Yes, I am considering switching to CoppeliaSim soon.
I would like to take this opportunity to say thank you to you and your team for making and maintaining such a great simulation tool.

Thanks.

coppelia
Posts: 8889
Joined: 14 Dec 2012, 00:25

### Re: Inaccurate simulation when complexity increase

Yes, you are right, it is a very subjective question ;)
Each engine will have its strengths, weaknesses, and particularities, and it takes a lot of fiddling around to find out about best parameters and settings for a given application.

But I still believe that your application would be much better served by having omni-wheels simulated with a sphere that is constantly reset. Simulation speed will also be drastically better I guess.

Cheers

thereisnospoon
Posts: 5
Joined: 14 Oct 2019, 07:34

### Re: Inaccurate simulation when complexity increase

Ok, understand for that :)

Yes, my omni-wheels are simulated using spheres.
I refer the Mecanum wheel of Kuka robot in VREP on how it was done - two spheres, one for roller and one for main wheel. It was mind-blown.

But I do not know how to make my omni-wheels constantly reset. What does it means? Which keywords in documentation I should refer?

Thanks.

coppelia
Posts: 8889
Joined: 14 Dec 2012, 00:25

### Re: Inaccurate simulation when complexity increase

Following is typically how the fake omni-wheels are simulated in CoppeliaSim:

Code: Select all

function sysCall_init()
motorizedJoint=sim.getObjectHandle('motorizedJoint')
freeJoint=sim.getObjectHandle('freeJoint')
wheel=sim.getObjectHandle('wheelShape_respondable')
end

function sysCall_actuation()
sim.resetDynamicObject(wheel)
sim.setObjectPosition(freeJoint|sim.handleflag_reljointbaseframe,motorizedJoint,{0,0,0})
sim.setObjectOrientation(freeJoint|sim.handleflag_reljointbaseframe,motorizedJoint,{math.pi/4,0,math.pi})
sim.setObjectPosition(wheel|sim.handleflag_reljointbaseframe,motorizedJoint,{0,0,0})
sim.setObjectOrientation(wheel|sim.handleflag_reljointbaseframe,motorizedJoint,{0,0,0})
end 
basically the wheel is reset in each simulation step, i.e. it is like removing its representation from the physics engine, and adding it again immediately after. And we reset the positions/orientations of the free joint and wheel to what we had at the start of the simulation. Looking at the hidden layers of such a simulation helps understand the principle.

Cheers

thereisnospoon
Posts: 5
Joined: 14 Oct 2019, 07:34

### Re: Inaccurate simulation when complexity increase

Oh, great. Now I see it. Thanks for sharing this.

I saw that this few lines of code are at the non-threaded child script of the Kuka robot.

For my case, I am using Python API and synchronized simulation.
So, do I need to call this non-threaded script every time step in my python code? Or, it will be called automatically to do the reset?

Another question is, how this non-threaded child script speed up the simulation? I thought by adding more scripts, it will be adding more 'works' for the simulator?

Sorry if I am asking basic question, please bear with me that I still yet to fully read the documentation.

coppelia
Adding lightweight code in child scripts will not have a big impact on performance. Of course it always depends on what you are doing in your scripts. With threaded scripts, it is slightly more tricky not to waste too much precious time, but there the function sim.switchThread comes in handy.