EuRoC Forum

[proprentnerl]

So while testing alle the task we came across two serious problems:

1. Sometimes when grasping an object after moving the robot it happens, that the object is catapulted out of the gripper:
https://www.dropbox.com/s/y95pleax4nbnf ... t.avi?dl=0

2. Cubes fall of the conveyor belt after dropping:
https://www.dropbox.com/s/k31zf9ws40byi ... l.png?dl=0

Is it possible that this has to do with slower machines? I have a real time factor of 0.3 and on other machines these errors happen less frequently.

regards
Lukas

[fschmidt]

1. Sometimes when grasping an object after moving the robot it happens, that the object is catapulted out of the gripper:
https://www.dropbox.com/s/y95pleax4nbnf ... t.avi?dl=0

this looks like the cube touches the table-plane and then the physics engine produces this ugly response. you can enable the display of contacts within the gazebo viewer: "View" menu enable "Contacts".

to further investigate this i would need the generated logfile from the simulation. just call the "save_log"-ros-service after such an event and find the generated logfile in ~/euroc_c2s1_logs/euroc_c2_s1_*.log
please send this log then via mail to the support-challenge02@robotics-challenges.eu mailing list.

2. Cubes fall of the conveyor belt after dropping:
https://www.dropbox.com/s/k31zf9ws40byi ... l.png?dl=0

this was not intended and will not happen in the final evaluation. i've changed the task6_v2 scene description file and will release a new euroc-c2s1-scenes_1.0.11_i386.deb package.

[joma]

Hello,
I'm not sure which video you saw, but on that one posted above there is no way that the cube touches the table plane with this robot configuration. The cube is more than 15 cm above the table and just jumps out of the gripper for no obvious reason. We will start the task again and make a video where you can definitely see that the cube is above the table and come back to the forum with the video.
The log file will be sent to the proposed email adress.

[proprentnerl]

Here is the new video and I have sent an email with the log file.
https://www.dropbox.com/s/ufb23e1pkccp4 ... 2.mp4?dl=0

[fschmidt]

Sometimes when grasping an object after moving the robot it happens, that the object is catapulted out of the gripper

thanks for sending the logfile. from the logfile and your video its clearly visible how one of the gripper-fingers violate its joint-condition. (its a gazebo prismatic joint which is implemented as a bullet btSliderConstraint)

this should not happen in a perfect physics simulation. our simulation is certainly not perfect. to make such grasping situations behave more realistic we enabled a modified version of gazebo's "GripperHack".

this gripper hack simply observes contacts between gripper fingers and objects in the scene. when an object has contact to both gripper fingers for more than 0.25 simulated seconds and there is no relative velocity between gripper and that object, and there is a gripper-force of atleast 5N then the hack is enabled and a new "fixed joint" is added to the physics simulation which holds/fixes the objects pose relative to the gripper.
this fixed joint is automatically removed when there is less than 5N of gripping force.

this gripper hack did not activate in your case because after closing the gripper fingers you immediately started moving the robot and this caused a movement of the cube relative to the gripper (because of the cube's inertia and the limited friction between cube and gripper fingers).

without that activated gripper hack there was only the relatively high gripping force of 48N (which you specified in your grip-stop-condition) that should keep the cube between the fingers.

this high-forces, many-contacts, multiple objects & joint-constraints situation is problematic for physics engines like bullet with our step-times, masses & frictions.

you should avoid such situations (atleast in this simulator).

for the gripper hack to work you should wait atleast 0.25 simulated seconds after closing the gripper fingers and while having atleast 5N of gripping force.

i suggest this procedure:

• close gripper fingers with a gripper stop condition of 10N (once the gripper hack is active the actual mass of the object is meaningless for the grasp to be stable...)
• wait atleast 0.5 simulated seconds
• lift the object / start moving the arm...

please report back if this procedure solved those problems.

[joma]

Is there any possibility to see if the gripperhack works? In the terminal of the simulator we can not see any change. Still after grasping an object "attached" ist printed.
We changed the timing as recommened and it seems to work better now, but we have to do some further simulations.

[fschmidt]

Is there any possibility to see if the gripperhack works? In the terminal of the simulator we can not see any change. Still after grasping an object "attached" ist printed.

a line "attach!" is printed on the terminal output of the simulator(where the task_selector was started) when the gripper hack has bound an object to the gripper. and "detach!" when it is released again.

there is no ros-topic or the like which publishes this information.

[joma]

In this case the gripper hack did not solve above issue. Apparently we cutted the first video a little bit to much. 5s after the cube flow away from the gripper we moved the terminal into the viewpoint of the screencamera and one can see the "attached" "detached!" lines (a longer version of the video will follow. Thus the gripper hack was active after grasping the object and still the cube was flying away.
How to aware this in all situations?
The video will be posted in a few minutes, we are currently cutting it.

[proprentnerl]

here is the longer version:

https://www.dropbox.com/s/xhmhu6hd8pz33 ... .mpeg?dl=0

[fschmidt]

please only report problems about lost objects when you made sure to have waited atleast 0.5s before lifting the object and your grip-force is somewhere between 10N and 20N in that time.

if you still encounter problems please send the logfile - otherwise we have no way to debug this.