Inaccurate simulation when complexity increase

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

Inaccurate simulation when complexity increase

Post by thereisnospoon »

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
fig 1: https://drive.google.com/file/d/1xdM4cY ... sp=sharing

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.
fig 2: https://drive.google.com/file/d/1MP63IN ... sp=sharing


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:
https://drive.google.com/file/d/1KkYlh4 ... sp=sharing
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:
https://drive.google.com/file/d/1qT5dq2 ... sp=sharing

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?

May you advise on this?

Thanks.

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

Re: Inaccurate simulation when complexity increase

Post by coppelia »

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

Post by thereisnospoon »

Hi,

Thanks for your reply and it does help.
"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.

Looking forward for your answer.

Thanks.

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

Re: Inaccurate simulation when complexity increase

Post by coppelia »

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

Post by thereisnospoon »

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
Site Admin
Posts: 8889
Joined: 14 Dec 2012, 00:25

Re: Inaccurate simulation when complexity increase

Post by coppelia »

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

Post by thereisnospoon »

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.

Thanks in advance.

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

Re: Inaccurate simulation when complexity increase

Post by coppelia »

So that code will be automatically called in each simulation step, independently of what your Python client is doing.

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.

What I previously meant: you actually have two different ways of simulating omni-wheels:
  • the first, obvious way is by having a wheel on top of which you have many non-motorized joints, each holding a conic shape. This looks more like the reality, but can be slow and less stable for the physics engine to simulate.
  • the better way is to use a rigid omni-wheel just for appearances. Hidden in a non-visible layer, you can then emulate the same behaviour with two spheres and two revolute joints (as was done in the Kuka models mentioned earlier). This will be much lighter on the physics engine and more stable.
Cheers

Post Reply