Table is growing upward, not down (world frame)

[simonflueckiger]

The table is flipped, the hight is extended upward in world frame and not downward .
Maybe we can give a picture later.

[ikrets]

What branch of this repository are you using?

In the master branch the height is extended in the direction opposite to the Z axis of the table_pose frame from the /check_kinematics_tabletop service call.

In the temp-edges branch the height is extended in the direction of the Z axis of the table_surface_pose frame from the service call. This corresponds to the way frames are defined in the tabletop usecase: https://github.com/SoMa-Project/ec_grasp_planner/blob/master/docs/example2_graph.png.

So in both cases the direction of the height extensions is not determined by the world frame, but by the table frame. Does this information resolve your problem?

If you're using the temp-edges branch, a heads up: there will be an update today changing how the table is constructed from edges. The table_surface_pose will not be used anymore when the edges are supplied and the height will extend in the direction of the normal to the created table surface, aligned with the direction that Z frames of edge frames are pointing towards. This will produce the same behavior as before but without the need to specify the table_surface_pose.

[zweistein]

We are on the integration_ms5_simon branch which is based on master and temp_edge

We understand that world frame is not used, we just described the issue we've seen in world frame because is shorter text. But we still have the same problem....

[JannisW]

Are you using the given examples when encountering this problem or is it when executing the complete system through the ec_grasp_planner?
I'll push a modified version of the ec_grasp_planner that can work with the changes made in temp_edge today.

[JannisW]

See the branch disney_edge_grasp_integration in ec_grasp_planner, in case you need basic support of the new version (table frame points downwards), introduced by temp_edge...
SurfaceGrasp should work there
Checking of EdgeGrasp as well, but currently no alternative trajectories are included in the HA (for EdgeGrasp)

[simonflueckiger]

We're using the complete system. Checking now on disney_edge_grasp_integration.

[simonflueckiger]

there is no relevant change in ec_planner that would fix this issue. Where do we consider the table frame orientation? ec_planner or feasibility?

[ikrets]

I think the relevant changes are on branch disney_edge_grasp_integration of ec_grasp_planner. I see that the flipping of frames is addressed in this commit SoMa-Project/ec_grasp_planner@6f10470.

[JannisW]

Both are relevant.

Previously the feasibility checker assumed the table's z axis to point upwards. That changed in temp_edge

Like @ikrets said, the respective changes are handled in the specified commit. The relevant changes are made in the check_kinematic_feasibilityfunction within ec_grasp_planner/src/multi_object_params.py (removing x_flip. see line 255 and 256)