ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

I wrote my own get_mark_next_dbase_task_of_type(), which worked and added grasps to the database successfully for GRASP_PLANNING and GRASP_CLUSTERING tasks. I did not test it with the other two types (GUIDED_GRASP_PLANNING, VELO_GRASP_PLANNING). It is written based on the get_mark_next_dbase_task() from the 0.5_electric.backup file.

-- Function: get_mark_next_dbase_task_of_type(text[])

-- DROP FUNCTION get_mark_next_dbase_task_of_type(text[]);

CREATE OR REPLACE FUNCTION get_mark_next_dbase_task_of_type(IN dbasetasktype text[])
  RETURNS integer AS
$BODY$
DECLARE next_id INTEGER;
 BEGIN
 SELECT dbase_task_id INTO next_id FROM dbase_task
        WHERE dbase_task_type = ANY ($1)
        LIMIT 1 FOR UPDATE;
 UPDATE dbase_task SET dbase_task_outcome_name = 'RUNNING'
        WHERE dbase_task_id = next_id;
 return next_id;
 END;
$BODY$
  LANGUAGE plpgsql VOLATILE
  COST 100;
ALTER FUNCTION get_mark_next_dbase_task_of_type(text[])
  OWNER TO willow;

Change willow in the last line to whatever your username is.

Another thing I had to do before the grasps would calculate correctly was to rescale our model to be much smaller. Rule of thumb is that both the object and the arm you're using should show up in GraspIt. Manually running GraspIt Eigengrasp Planner to see what's supposed to happen helps ( www.cs.columbia.edu/~cmatei/graspit/html-manual/graspit-manual_12.html#id5 ). The ROS GraspIt plugin uses the Eigengrasp Planner with Search Space Complete and simulated annealing to output the [tx ty tz qw qx qy qz].

Solution: I wrote my own get_mark_next_dbase_task_of_type(), which worked and added grasps to the database successfully for GRASP_PLANNING and GRASP_CLUSTERING tasks. I did not test it with the other two types (GUIDED_GRASP_PLANNING, VELO_GRASP_PLANNING). It is written based on the get_mark_next_dbase_task() from the 0.5_electric.backup file.

-- Function: get_mark_next_dbase_task_of_type(text[])

-- DROP FUNCTION get_mark_next_dbase_task_of_type(text[]);

CREATE OR REPLACE FUNCTION get_mark_next_dbase_task_of_type(IN dbasetasktype text[])
  RETURNS integer AS
$BODY$
DECLARE next_id INTEGER;
 BEGIN
 SELECT dbase_task_id INTO next_id FROM dbase_task
        WHERE dbase_task_type = ANY ($1)
        LIMIT 1 FOR UPDATE;
 UPDATE dbase_task SET dbase_task_outcome_name = 'RUNNING'
        WHERE dbase_task_id = next_id;
 return next_id;
 END;
$BODY$
  LANGUAGE plpgsql VOLATILE
  COST 100;
ALTER FUNCTION get_mark_next_dbase_task_of_type(text[])
  OWNER TO willow;

Change willow in the last line to whatever your username is.

Another thing I had to do before the grasps would calculate correctly was to rescale our model to be much smaller. Rule of thumb is that both the object and the arm you're using should show up in GraspIt. Manually running GraspIt Eigengrasp Planner to see what's supposed to happen helps ( www.cs.columbia.edu/~cmatei/graspit/html-manual/graspit-manual_12.html#id5 ). The ROS GraspIt plugin uses the Eigengrasp Planner with Search Space Complete and simulated annealing to output the [tx ty tz qw qx qy qz].