search

SoMa-Project / ec_grasp_planner

Grasp Planner Based on Environmental Constraint Exploitation
BSD 3-Clause "New" or "Revised" License
7 stars 3 forks source link

Force transformation in grasp_success_estimator is wrong #56

Closed ptriantd-ocado closed 5 years ago

ptriantd-ocado commented 5 years ago

The force transformation in grasp_success_estimator should not be affected by the translational component of the base_link -> ee_frame tf. This was fixed in 63505be47144f33d723ce372ece12e9f40a8c82f

@JannisW

JannisW commented 5 years ago

Yes, you are right. Thanks for pointing that out. I'll merge the fix. However, I think we can remove the translational part completely from the code, instead of multiplying it with zero.

Did this change actually influence your classification results? I'm currently running experiments (without the merged fix) and did not encounter a single misclassification so far.

ptriantd-ocado commented 5 years ago

Yes, removing the translational part completely makes more sense. I just kept it because it will be needed if you want to transform moments later on.

We have been having quite a lot of issues with the classification actually. Mainly on the wall grasp where there seems to be a significant offset between the two measurements. We only discovered this bug just yesterday so we haven't really tested whether it fixes our problems.

The reason we investigated it in the first place was that the estimator worked mostly correctly when the pregrasp and the after-lift-up pose were more or less the same (which is typically the case with surface grasps but not for wall grasps). So, it makes sense that this kind of bug could cause an issue like that...

Let's leave this open and I will come back sometime early next week to confirm whether it solved our issues...

JannisW commented 5 years ago

I'm looking forward to hear about your results. I did some quick comparison here and it doesn't make a big difference on our system. If you track /graspSuccessEstimator/continues_mass you can still see differences after changing the EE pose (which is probably due to flaws in the hand model, such that the ft measurements are still influenced by how much weight is pushing/pulling by the hand itself). Is your ft topic already accounting for the weight of the hand? However, these changes are apparently cancelled out by modelling the robot noise (calculated using the calculate_success_estimator_object_params.py script and the difference model). At least I didn't see a misclassification on our side during the latest experiment session (performing surface, wall and corner grasps).

ptriantd-ocado commented 5 years ago

I think it probably has to do with the fact that our ft topic is not accounting for the weight of the hand. Therefore we are transforming a much larger force than you do. I imagine that if we were only transforming the "object's force" then due to the fact that pre to post-grasp translation is quite small, the bug's effect would be "drowned" in the F/T sensors noise.

In my efforts to model the robot noise, I was getting quite varied results from the grasp_success_estimator so the values I eventually picked were just some that seemed reasonable based on previous experiments we have performed with this F/T sensor. That is what was bugged me about the node and helped identify the bug...

ptriantd-ocado commented 5 years ago

@JannisW

I can confirm that the grasp success estimator works nicely after the fix :100:

JannisW commented 5 years ago

Great! Thanks for letting me know.