Displaying grasps when 'check_approach=True'

[stepjam]

Hello,

I think I have found a problem in the code and just wanted to point it out and check my understanding.

So lets say I use the default config file supplied (api_defaults.yaml), but I set check_approach = True because I want a set of grasps that are perpendicular to the table and collision-free (like the GQ-CNN dataset). So I import a model using add_objects(), I then sample some grasps using one of the grippers with sample_grasps(), and then finally compute some metrics using compute_metrics().

The problem comes when I try to view these grasps.

In _compute_metrics(), If check_approach = False then we use the metric name to index the quality score:

grasp_metrics[grasp.id][metric_name] = q.quality

and everything works fine later when I try and view the grasps. But if check_approach = True, then we index by a created 'metric_tag':

metric_tag = '%s_%s' %(metric_name, stable_pose.id)
#Other stuff
grasp_metrics[grasp.id][metric_tag] = q.quality

This becomes a problem when you then try and view the grasps (in display_grasps()), here is the first problem in this function, but there are similar instances after it when we try and get the metric information:

metrics = self.dataset.available_metrics(object_name, gripper=gripper.name)
if metric_name not in metrics:
    raise ValueError("{} is not computed for gripper {}, object {}".format(metric_name, gripper.name, object_name))

It seems to assume that we had check_approach = False and that we access the quality via the metric name, and not the 'metric_tag'. I apologize if I have misunderstood something and this is not an error in the code.

I have one extra query: I have assume that check_approach = True for when you generated the GQ-CNN dataset (as you were picking up from a table), so my question is what would check_approach = False be useful for? Picking from the side perhaps?

Hopefully I have made somewhat sense. Thank you for your time!

[01halibut]

The GQ-CNN dataset was generated with check_approach = False, and collision checking was done afterwards using the gripper mesh.

check_approach was more for computing metrics dependent on object orientation, but since we aren't using any of those it's pretty much unused. Looking over the config params and cleaning out unused ones is something that needs to be done at some point.

[stepjam]

Im sorry, but I am still a little confused.

in line 519 of dexnet/api.py, you have:

aligned_grasp = grasp.perpendicular_table(stable_pose)

but this relies on check_approach = True, and I thought the grasps in the dataset were perpendicular to the table?

[01halibut]

The grasps in the dataset are perpendicular to the table, but the metrics used are independent of whether or not the grasp is perpendicular to the table.

Basically, everything that makes the grasps in the dataset perpendicular to the table (collision checking) isn't in the current released code.

[stepjam]

Basically, everything that makes the grasps in the dataset perpendicular to the table (collision checking) isn't in the current released code.

Ahhh, that makes more sense now! After looking through the code, I thought that was the case, but I just assumed that this code took care of the entire dataset creation process. My mistake!

Thank you for clearing that up! By the way, is there any plan to release the collision checking code?

[01halibut]

No concrete schedule at the moment, but it probably will be released at some point.

[jeffmahler]

Hi Stephen,

Thanks for the feedback! Wrt collision checking, we have plans to release that more broadly, tentatively in fall 2017. You can use a subset of our collision checking capabilities using the class dexnet.grasping.GraspCollisionChecker if you install my fork of OpenRAVE 0.9 per the installation doc on berkeleyautomation.github.io/dex-net/code.html.

The delay in release is bc we are working on removing the OpenRAVE dep. We pretty much only use it for collision checking and it can be frustrating to install. Our goal is to add a lean version of collision checking to our trimesh fork (which will replace meshpy at some point).