KavrakiLab / tmkit

A Task-Motion Planning Framework
http://tmkit.kavrakilab.org
BSD 3-Clause "New" or "Revised" License
48 stars 12 forks source link

Debugging: Best Practices #7

Open clemense opened 6 years ago

clemense commented 6 years ago

Hi, I wanted to know whether there are some hints on how to best debug a newly defined problem that doesn't work as expected (i.e., no plan was found). I figured out that the pure task domain can be verified via tmsmt ops.pddl facts.pddl which is a first step. But once this is done, I would like to get more insight into the full blown geometric problem. For example: Is it possible to output the initial and goal state conjunction? The initial state depends on the scene file, the optional task problem definition (:init) and the initial state (-q). I'm not sure I fully understand what happens when competing facts are defined in these different sources.

I'm also using the python interface and first thought that outputting the return value of tm.bind_scene_state and tm.bind_goal_state might give all necessary information but I realized that these lists are not the full state (at least the planner even fails when both are identical -- although there should be a trivial solution). Any hints on how to debug (without going the LISP way)?

ndantam commented 6 years ago

You can get the start/goal task expressions by calling tmsmt --write-facts=FACTS.pddl ..., which will output the PDDL facts for the input scene/semantics.

clemense commented 6 years ago

Great, that helps a lot. Thanks!

clemense commented 6 years ago

Sorry, just one tiny question regarding the "debugging" thing. I'm now at the point where the RRT cannot sample valid goal states: "Error: RRTConnect: Unable to sample any valid states for goal tree" Is there a way to visualize/get insight into what this potential goal state looks like?

ndantam commented 6 years ago

This probably means either (1) the goal is in collision or (2) there are no IK solutions for the goal.

You could try loading/viewing the scene and drawing in some marker at the goal position.

clemense commented 6 years ago

Alright. I'm trying to figure out in which coordinate systems the poses are expressed. According to the documentation the function op_tf_abs returns "the absolute pose of FRAME". Does "absolute" mean in the coordinate frame of the scene's root node?

ndantam commented 6 years ago

Yes, absolute is with respect to the scene's root.

clemense commented 6 years ago

Ok, thanks. There's no simple way to visualize all frames in aarxc, right? I guess adding markers to all frames defined in the scene files myself is the easiest way to accomplish this...

clemense commented 6 years ago

Ok, one final question. I cannot find any valid goal state for RRTConnect ("Unable to sample any valid states for goal tree"), even if I do forward kinematics and use the resulting endeffector pose as a desired goal state. I also turned off collisions (geometry { collision 0; ..}) for all meshes. I guess there is no more information about the exact problem available?

ndantam commented 6 years ago

Possible that there is some detected self-collision in the robot at the goal state. The simplified collision geometry for many robots results in spurious collisions that need to be "allowed" by the motion planner.

You can view the collision geometry and check for self-collisions with either the C API or Lisp API. I will add that to my TODO list for CLPython binding.

clemense commented 6 years ago

Ok, that would help in general. But in my case it's impossible, since I provide a file with the allowed collisions in which I put all possible pairs of robot links.

andrewmw94 commented 6 years ago

In my experience the "Unable to sample any valid states for goal tree" usually happens when I set my transform incorrectly for grasping an object. So I have the gripper inside the object I want to grasp or something like that.

clemense commented 6 years ago

Ok, thanks. One related question: is the geometry attribute collision 0; used? It is generated when converting from URDF to robray scene files but it is nowhere documented (http://amino.kavrakilab.org/scenefile.html). I assume it means that this geometry cannot generate any collisions. Am I right?

ndantam commented 6 years ago

Yes, the collision attribute sets whether the geometry is considered for collisions. There is also a visual attribute for collision-only geometry

clemense commented 6 years ago

Is there some documentation on this, or a file that I can look at? (e.g. the 'cone' option is also not available although the docs say so)

ndantam commented 6 years ago

Just the documentation here: http://amino.golems.org/scenefile.html.

Here is the parser: https://github.com/golems/amino/blob/master/lisp/rx/scenefile/curly.lisp