Hi,
I have a scene where I perform a grasp of a mug using the simplified barrett hand. I place the hand, grasp the object and remove the base to see if the grasp is stable using remote API. There are a number of bugs I would like to investigate and correct. I have a 50s video that shows what is going wrong pls download it from my drive:
https://drive.google.com/file/d/0B_4k6Z ... sp=sharing
1st grasp the simulation becomes unstable.
2nd grasp is great but the mug slips out of the hand, friction is as high as it can go - which is most likely the issue for the last grasp.
3rd grasp a finger sticks to the object and is recorded as a successful grasp.
This is a link to the scene I am using:
https://drive.google.com/open?id=0B_4k6 ... FEzTzFhVVU
I also have not found a way to speed up the system, I already do synchronous timing but closing of the hand takes ~30s regardless.
Thank you for your time.
Bug fixing in VREP
Re: Bug fixing in VREP
Hello,
in your scene you have many active vision sensors. I can count 8. Some have a high resolution and a filter that extracts coordinates. All this makes the simulation slow (during simulation, always check what takes the longest to compute, in order to localize your bottleneck).
You have for instance 3 invisible fast3DLaserScanner models in the scene. Is this on purpose? (invert the layers to see them, or in the scene hierarchy you can always see them).
Are you sure you need a new set of vision sensor data every 50 ms? If not, you can explicitely handle the vision sensors and have them operate to take a new image every 500ms or so. Simulation will then go much faster already.
Then, you are using the ODE engine. You can still increase the friction coefficient, on the gripper fingers. Remember that the final coefficient of friction is given by:
object1FrictionCoeff * object2FrictionCoeff = frictionCoeff
Cheers
in your scene you have many active vision sensors. I can count 8. Some have a high resolution and a filter that extracts coordinates. All this makes the simulation slow (during simulation, always check what takes the longest to compute, in order to localize your bottleneck).
You have for instance 3 invisible fast3DLaserScanner models in the scene. Is this on purpose? (invert the layers to see them, or in the scene hierarchy you can always see them).
Are you sure you need a new set of vision sensor data every 50 ms? If not, you can explicitely handle the vision sensors and have them operate to take a new image every 500ms or so. Simulation will then go much faster already.
Then, you are using the ODE engine. You can still increase the friction coefficient, on the gripper fingers. Remember that the final coefficient of friction is given by:
object1FrictionCoeff * object2FrictionCoeff = frictionCoeff
Cheers
Re: Bug fixing in VREP
That sorted a bunch of issues - Yes I knew all the sensors were there, and I was saving them, but not anymore.
Doing this uncovered something though. I recorded part of a grasp:
https://drive.google.com/open?id=0BzJFg ... WNDOENROUk
See the red box, its from the moment of inertia which we work out separately, and it keeps the object stable. But for some reason the hand sees it as an obstacle and does not close around the object, it fights the little red box.
I tried changing the inertial properties, but as you might have guessed, this makes things unstable. Any clue as to what I can do?
EDIT: this is a better example:
https://drive.google.com/open?id=0BzJFg ... UpYVDdCaU0
Doing this uncovered something though. I recorded part of a grasp:
https://drive.google.com/open?id=0BzJFg ... WNDOENROUk
See the red box, its from the moment of inertia which we work out separately, and it keeps the object stable. But for some reason the hand sees it as an obstacle and does not close around the object, it fights the little red box.
I tried changing the inertial properties, but as you might have guessed, this makes things unstable. Any clue as to what I can do?
EDIT: this is a better example:
https://drive.google.com/open?id=0BzJFg ... UpYVDdCaU0
Re: Bug fixing in VREP
The inertia visualization wireframe box (in red) has not collision influence at all. It is just to give an idea of how the inertia matrix is oriented around the object.
The second video looks quite normal to me: the hand tries to close around the box, but first collides with the blue support. Once the blue support is removed, the hand closes but the object slips through the hand (since the hand was not even in contact with the object just before removing the blue support).
Cheers
The second video looks quite normal to me: the hand tries to close around the box, but first collides with the blue support. Once the blue support is removed, the hand closes but the object slips through the hand (since the hand was not even in contact with the object just before removing the blue support).
Cheers
Re: Bug fixing in VREP
Thx. Maybe I am just seeing a problem where there isn't one.