You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment, the interface of the Eigengrasp planner supports only single-threaded access.
Specifically, after calling method EigenGraspPlanner::plan(), subsequent EigenGraspPlanner::getResults() will retrieve the last results produced by plan(). And there are other limitations (with the GraspIt! world itself) which don't allow multiple simultaneous planning tasks. This allows the interface to be used by one robot only.
Accordingly, the class grasp_planning_graspit_ros::GraspItServices is limited to similar single-threaded access.
It would be nice to provide an implementation, at least of GraspItServices, which allows serving multiple simultaneous planning requests. The easiest way to implement this at the moment would probably be to create a separate GraspIt! world (and planner instance) for each request, but this would mean that each request must maintain its own database as well. It's not as quickly implemented as it seems at first glance.
The text was updated successfully, but these errors were encountered:
At the moment, the interface of the Eigengrasp planner supports only single-threaded access.
Specifically, after calling method EigenGraspPlanner::plan(), subsequent EigenGraspPlanner::getResults() will retrieve the last results produced by plan(). And there are other limitations (with the GraspIt! world itself) which don't allow multiple simultaneous planning tasks. This allows the interface to be used by one robot only.
Accordingly, the class grasp_planning_graspit_ros::GraspItServices is limited to similar single-threaded access.
It would be nice to provide an implementation, at least of GraspItServices, which allows serving multiple simultaneous planning requests. The easiest way to implement this at the moment would probably be to create a separate GraspIt! world (and planner instance) for each request, but this would mean that each request must maintain its own database as well. It's not as quickly implemented as it seems at first glance.
The text was updated successfully, but these errors were encountered: