OMPL state validation callback is 2-3 times slower than using default state validation checking

Report crashes, strange behaviour, or apparent bugs
Post Reply
Uli_v
Posts: 23
Joined: 14 Dec 2018, 18:07

OMPL state validation callback is 2-3 times slower than using default state validation checking

Post by Uli_v » 24 Jan 2019, 18:19

I noticed that using simOMPL.setStateValidationCallback is slower than using the default state validation (e.g. specifying collision pairs by simOMPL.setCollisionPairs). I have implemented the same collision checking in the callback function that I would expect to be implemented by default when no callback function is specified. You can find the demo scene here: https://drive.google.com/open?id=1uTJMo ... QdaOhqDKMj

All you need to do is comment one of the following 2 lines, run the simulation and look at the terminal and check "Info: PRMstar: Created xxx states."

Code: Select all

--simOMPL.setCollisionPairs(t,collisionPairs)
simOMPL.setStateValidationCallback(t,'stateValidationCheckCollision')
With callback function it is about 3 times slower (3 times fewer created states) than without callback function.

My questions:
  • Why is the callback function slower? Shouldn't both methods perform the same operations (e.g. reading/writing states and collision checking)? Are there any additional operations by the callback that slow it down?
    Or is it because LUA script is slower than the compiled plugin?
  • Would I get a speed up by implementing the state validation on the plugin side instead of using a callback function? It might not be straight forward implementing that on the plugin side.

In general I would like planning to run as fast as possible. I noticed that when running OMPL planning, that only one CPU core is fully utilized. How could I run planning on several CPUs? Do I need to run several instances of identical V-REP scenes? But how would I "distribute" the work and "combine" the results for planning in several environments"?

Thanks,
Uli

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

Re: OMPL state validation callback is 2-3 times slower than using default state validation checking

Post by coppelia » 25 Jan 2019, 11:01

Hello Uli,

calling lua functions is quite an overhead, specially if you have to do it for every collision checking, i.e. very often. Additionally, in your example, both planning tasks are not the same, so you can't directly compare both methods (i.e. one is doing minimum distance calculation within a certain range for validation, the other is doing simple collision checking for validation).

Doing state validation on the plugin side is certainly faster, but I am not sure how large that difference is (smaller if your state validation function is complex).

Multithreaded calculation are currently not possible since that would involve having several threads access the V-REP API for collision checking (which is currently forbidden)

Cheers

Uli_v
Posts: 23
Joined: 14 Dec 2018, 18:07

Re: OMPL state validation callback is 2-3 times slower than using default state validation checking

Post by Uli_v » 25 Jan 2019, 22:15

Okay thanks, so calling V-REP API function via LUA scripts is slower than calling c-functions from the plugin side.

About using multiple CPUs. Maybe I can run several instances of V-REP (as well as several PMPL plugins) in parallel? I would need to do path planning for different scenes anyway (e.g. for different obstacle placements).

Btw, I am not doing distance measurement in the callback, I have added "stateValidationCheckCollision" (I am not using "stateValidation" from the example). See below script below:

Code: Select all

stateValidationCheckCollision=function(state)
    -- Read the current state:
    local p=sim.getObjectPosition(robotHandle,-1)
    local o=sim.getObjectOrientation(robotHandle,-1)

    -- Apply the provided state:
    sim.setObjectPosition(robotHandle,-1,{state[1],state[2],p[3]})
    sim.setObjectOrientation(robotHandle,-1,{o[1],o[2],state[3]})

    -- check for collision
    local collision = sim.checkCollision(collisionPairs[1],collisionPairs[2])


    -- restore the state ( I might not even need this, maybe just restore at the and after planning)
    sim.setObjectPosition(robotHandle,-1,p)
    sim.setObjectOrientation(robotHandle,-1,o)    

    if collision == 0 then
        state_valid = true
    else
        state_valid = false
    end


    -- Restore the current state:
    sim.setObjectPosition(robotHandle,-1,p)
    sim.setObjectOrientation(robotHandle,-1,o)

    -- Return whether the tested state is valid or not:
    return state_valid
end

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

Re: OMPL state validation callback is 2-3 times slower than using default state validation checking

Post by coppelia » 28 Jan 2019, 15:21

Yes, you can run several instances of V-REP, that should work, even if not really elegant ;)

Cheers

Post Reply