• If you have problems with the config file, take pr2.yaml as an example, this one is used for tests and will always be up to date.

Here is an explanation of possible error codes that Giskard might return.

• uint8 SUCCESS=0
  • If there is no error, giskard will converge to a local minimum. If it returns success but didn't do what you want, check your goal.
• uint8 INSOLVABLE=1, this can have multiple causes
  • The path is contains high frequency waves, usually indicates conflicting goals that won't allow Giskard to converge
  • empty goal
  • unknown contraints
  • tf errors
• uint8 PATH_COLLISION=2 # not implemented
• uint8 START_STATE_COLLISION=3 # not implemented
• uint8 END_STATE_COLLISION=4 # not implemented
• uint8 SOLVER_TIMEOUT=5 # not implemented
• uint8 INTERRUPTED=6
  • goal got canceled via action server interface
• uint8 MAX_NWSR_REACHED=7
  • NWSR is a parameter for the qp solver. As a quick fix you can increase the number in the config yaml that you are loading until it works. However, the default is None which triggers a heuristic, that has never failed so far, so please create an issue as well.
• uint8 QP_SOLVER_ERROR=8
  • Something is wrong with the qp problem that giskard created. If you didn't implement the constraint yourself, create an issue https://github.com/SemRoCo/giskardpy/issues.
• uint8 UNKNOWN_OBJECT=9
  • One of the object identifies in your goal refers to an unknown object
• uint8 SYMENGINE_ERROR=10
  • There is something wrong with the constraint. If you didn't implement the constraint yourself, create an issue https://github.com/SemRoCo/giskardpy/issues.

• The collision avoidance is generally not smart enough to find complicated paths around objects, but it can move along surfaces.
• Giskard will stop planning if it finds a local minimum and returns success. For example, it might get stuck in a stable position behind an object that is blocking the path. There is no check if the goal is properly satisfied, because this is not necessarily wanted.
• The collision avoidance can get unstable if there are to many objects in unfortunate configurations close to the robot.
• The API to program constraints is not (yet) easy to use and therefore not documented here.
• pybullet doesn't like mimic joints very much, complicated mimic chains seem to be buggy, which results in inaccurate collisions

If you are debugging Giskard it might be useful to look into it behavior tree.

sudo apt install ros-<your-distro>-rqt-py-trees

And then run

rosrun rqt_py_trees rqt_py_trees

and select giskards log topic.