0
$\begingroup$

Rosanswers logo

Hello there,

I am trying to create a ROS based application in which i use a Joystick to control the robot, then save the robot state and later create plans from those saved positions.

However i am encountering several bugs when planning Trajectories with moveit. One of which is shown in the following Screenshot. It shows the start State (not touching the frame), the state which is somewhere in the Trajectory and touches the frame, and the goal state. As you can see, there must clearly be a valid path!
Or am i mistaken and the obvious path is only obvious to humans, but not to a IK-Solver? Robot touching the Frame

Other times, i try to make a path from let's say the robot being in some configuration under the table to somewhere above the table (without moving the robots base_link), but the plan is invalid and the robot dances around... which is fun to watch, but unacceptable for the application.

The Trajectory is of course not excecutet, and moveit points out, that the path might just not be valid due to postprocessing. So might that be the cause of my problem?

So much to my problem... now to my "long-story-short-question":
Is it possible to configure moveit in such a way that it is aware of objects in the Scene and gives me a valid path for over 90% of the requests?


Originally posted by David_111 on ROS Answers with karma: 32 on 2017-06-27

Post score: 0

$\endgroup$

2 Answers 2

0
$\begingroup$

Rosanswers logo

It's hard for me to see anything from your description in your screenshot.

the robot dances around... which is fun to watch, but unacceptable for the application.

This sounds like a plan produced by the default planner configuration in indigo - we changed it in kinetic. Try to choose RRTConnect as your planner, if you didn't do that already..

One of which is shown in the following Screenshot. It shows the start State (not touching the frame), the state which is somewhere in the Trajectory and touches the frame, and the goal state. As you can see, there must clearly be a valid path!

MoveIt uses the FCL library for collision testing and until now only tests discrete states for collisions. If you have thin collision structures, it might miss collisions if the arm can move through them between collision checks.

Try to increase the amount of checks. You can do that by reducing longest_valid_segment_fraction in the group section of your ompl_planning.yaml. We currently advise a value of 0.005 which should be good enough for your setup.


Originally posted by v4hn with karma: 2950 on 2017-06-28

This answer was ACCEPTED on the original site

Post score: 0


Original comments

Comment by David_111 on 2017-07-07:
does moveit_commander.set_planner_id("RRTConnectkConfigDefault") do the job for choosing that planner? because after doing so, the robot is still "dancing" when a plan involves collision avoidance. I dont think that the structures i use are so thin that it causes problems

Comment by David_111 on 2017-07-07:
to clarify(your first citation of me): the path, i took a screenshot of, is invalid due to the collision, which you can see in the screenshot. But in my opinion, there has to be another path.

$\endgroup$
0
$\begingroup$

There is a (now deleted) answer, that was potentially useful, posted by Iñigo Moreno. Reproducing it here. If the answer is undeleted, then this wiki answer can be deleted.


Just in case someone stumbles into this question like I did, I'm posting my findings here:

Kinematic solvers on ROS have access to a solution_callback function which they can use to check for the validity of a solution. This can be seen on kinematics_base.h#L263.

For example you can see how the default KDL plugin uses this in kdl_kinematics_plugin.cpp#L402.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.