Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
Next revisionBoth sides next revision
tutorials:intermediate:simple_mobile_manipulation_plan [2019/07/16 11:26] – [Some Useful Designators] ?grasp-pose -> ?grasp-pose-identifier amartutorials:intermediate:simple_mobile_manipulation_plan [2019/08/02 14:05] – [Expanding Failure Management Capabilities] Added information about grasps amar
Line 360: Line 360:
                                (object ?perceived-bottle)))                                (object ?perceived-bottle)))
 </code> </code>
-We see that the robot defaults the right arm when the object is in the center and will always try to grasp the left side of the bottle, even when the object is slightly favoring the left side under it (Refer the figure below).+We see that the robot defaults the right arm when the object is in the center and will always try to grasp the left side of the bottle, even when the object is slightly favoring the left side under it (Refer the figure below).  
 + 
 +Note: ''We have been using left-side here a lot. In the context of (grasp left-side), it refers to the left-side of the bottle. But what defines the "left-side"?'' 
 + 
 +''Before we understand it, we have to acknowledge that every object spawned in the bullet world has its own coordinate axes - even rotationally symmetric objects like the bottle here. And the definition for left-side is the side of the -ve Y-axis in the bottle coordinate frame. Similarly right-side is +ve Y-axis, front is denoted by +ve X-axis and the back by -ve X-axis. '' 
 +''With this the "left-side" grasp can change based on how the object is oriented in the world. But it remains the w.r.t the object coordinate frame.'' 
 + 
 +''The file at <your workspace>/cram/cram_common/cram_object_knowledge/src/household.lisp holds some definitions for grasps supported by the household objects supporte in CRAM.''
  
 {{:tutorials:intermediate:btw-tut-grasp-config-fail.png?800|}} {{:tutorials:intermediate:btw-tut-grasp-config-fail.png?800|}}
Line 492: Line 499:
  
 You can now try spawning the bottle in different points on the table and observing how the robot resolves the arm and grasp for it. Subsequently, you will notice that our plans will work as long as the bottle is within reach of the robot. You could try implementing the adjustment of the robot's position to facilitate the fetch. You can now try spawning the bottle in different points on the table and observing how the robot resolves the arm and grasp for it. Subsequently, you will notice that our plans will work as long as the bottle is within reach of the robot. You could try implementing the adjustment of the robot's position to facilitate the fetch.
 +
 +Instead of a hardcoded pose for the base of the robot, you now would now need to obtain a list of poses where the robot will be able to grasp the bottle from. This is exactly where [[tutorials:intermediate:costmaps|location costmaps]] come into play. CRAM provides an easy way to handle these where the user does not have to bother with hardcoded poses. A way to obtain this would be through the following designator
 +<code lisp>
 +(a location 
 +   (reachable-for pr2)
 +   (object (an object
 +               (type bottle))))
 +
 +</code>
 +Referencing this will give you locations where our robot PR2 can successfully reach an object of type bottle. Note that the object designator used here is pretty generic and will apply to all the bottles in the robot's belief state.
 +To make it more specific we can provide the name and the location designator where the bottle is expected to be in.
 +Eg:
 +<code lisp>
 +;; This is the location designator used to reference locations where the pr2 should be to reach an object 
 +;; named bottle-1 of type bottle which is situated on the counter-top named sink-area-surface
 +(a location
 +   (reachable-for pr2)
 +   (object (an object
 +               (type bottle)
 +               (name bottle-1)
 +               (location (a location 
 +                            (on (an object 
 +                                    (type counter-top)
 +                                    (urdf-name sink-area-surface)
 +                                    (part-of kitchen))))))))
 +</code>
 +You can see that the designator is not that intimidating as it looks, but provides a structured way to reference objects and locations. You can use these to write plans without having to worry about the actual coordinates.
  
 Since this is a simple tutorial in formulating and understanding mobile plans using CRAM, developing advanced plans and recovery behaviors is left up to you. Since this is a simple tutorial in formulating and understanding mobile plans using CRAM, developing advanced plans and recovery behaviors is left up to you.
Line 595: Line 629:
  
  
---></html>+--> 
 + 
 +</html>