search

personalrobotics / ada_meal_scenario

A set of scripts for a meal serving scenario using Ada.
1 stars 4 forks source link

Demo logic for faster plans #27

Open siddhss5 opened 9 years ago

siddhss5 commented 9 years ago

One way to speed things up is to break down the PlanToEndEffectorOffset into a PlanToTSR (with free roll) to as close to the food as possible followed by a shorter PlanToEndEffectorOffset. I think this will succeed more often. @mkoval and jeking, does this make sense? I think we can encode this as an action, much like the push-grasp.

siddhss5 commented 9 years ago

I reassigned this to @jeking04 since she's working on the refactored demo. Right now, we plan a long PlanToEndEffectorOffset. I suggest breaking it down to a PlanToTSR to get above the peep followed by a shorter PlanToEndEffectorOffset, much like the PushGrasp action but vertical.

Stefanos19 commented 9 years ago

@siddhss5: Is PlanToTSR faster than the PlanToEndEffectorPose? Right now, I am moving the end effector on top of the bite using PlanToEndEffectorPose and then do a PlanToEndEffectorOffset, so I wonder if I could do what you suggest by just setting the end-effector pose of the first plan to be closer to the bite. Also, note that with the new utensils that we got, the PlanToEndEffectorOffset is much shorter.

siddhss5 commented 9 years ago

In general, I'd say yes, but I should qualify my statement by saying: a planner that natively supports PlanToTSR will be on average faster than the same planner that natively supports PlanToEndEffectorPose. More goals are often better. And, you have less of a chance of specifying a bag goal.

But, if you've preselected a good goal and run PlanToEndEffectorOffset with say VectorField, if it succeeds, it will succeed faster than PlanToTSR with cbirrt.

So, no clear winner there.

mkoval commented 9 years ago

I don't think that's true at all. Both PlanToTSR and PlanToEndEffectorPose should do goal sampling inside the planner, if possible. The implementations of PlanToEndEffectorPose on CBiRRT (and possibly OMPL?) actually create a point TSR and call PlanToTSR.

The advantage of PlanToTSR is that it's much more general (a pose can always be encoded as a point TSR, but the converse is not true). The advantage of PlanToEndEffectorPose is, like @siddhss5 said, that it's often easier to support a goal pose than a goal TSR.

@siddhss5 Why would you expect PlanToTSR to be faster here? I would expect them to be identical.

mkoval commented 9 years ago

Oh, I missed the free roll qualification in @siddhss5's original comment. PlanToTSR could be much faster if we give it a larger goalset. Nevermind! :smile:

siddhss5 commented 9 years ago

Good :).

I was actually raising the point that PlanToTSR even with a free roll with planner A might be slower than PlanToEndEffectorPose with planner B if you got lucky or smart with the end effector pose.

Another somewhat subtle point is that PlanToTSR with a planner that natively supports it (like cbirrt) might be slower than a metaplanner that samples and runs a bunch of PlanToEndEffectorOffset (like snap).

Stefanos19 commented 9 years ago

I see, thanks for explaining that!