ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
1

How to use planners in Moveit?

asked 2020-10-21 11:26:03 -0500

Kappa95 gravatar image

Hi Community, i'm a newbie of ROS and i'm working on a project in which i have to control a robot Yumi of ABB (IRB 14000), searching in the web i found the ROS packages for the Yumi link. After playing around and working with the same points i have notice that each time i'm executing the code the trajectory is different and sometimes very different, there is a way to constraint better the choice of the trajectory? I searched and found that changing the file: "ompl_planning.yaml" is possible to change and add different planners and so i changed this the RRTConnect into:

  RRTConnectkConfigDefault:
type: geometric::RRTConnect
optimization_objective: MaximizeMinClearanceObjective
range: 0.0  # Max motion added to tree. ==> maxDistance_ default: 0.0, if 0.0, set on setup()
goal_bias: 0.05
delay_collision_checking: 1

in order to achieve better accuracy, but this is not true, do you have some advices/references? Thank you so much

PS: I'm using ROS Kinetic

edit retag flag offensive close merge delete

Comments

What is "not true"? Is accuracy the problem, or that the robots are doing very different motions? Could you provide a video or two of the issue?

fvd gravatar image fvd  ( 2020-10-21 19:18:33 -0500 )edit

Hi, thank you so much for your answer. I tried also today to execute again the program and i make 2 videos that i joined together here the youtube link: Yumi ABB with ROS Kinetic and Moveit. If you see the first time the left arm make two "full turn" for reaching the same pose, instead the second time no. I understand that infinity solutions exist for the same pose (particularly with an arm with 7DOF) but i don't understand how to control and constraint "better" this. If you want i can share also the code and the log.

Kappa95 gravatar image Kappa95  ( 2020-10-22 10:13:28 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted
2

answered 2020-10-22 11:35:03 -0500

fvd gravatar image

I understand that your main problem are the unintuitively large motions that can sometimes occur when free planning to a Pose goal, as shown in the first half of your video. There are multiple things to consider:

  1. Your Pose goal is converted via the IK to a joint goal, which becomes the goal of the MotionPlanRequest. If the pose goal is not easy to reach (for the IK) from your current joint state, the IK (by default KDL) can easily be chosen from any of the many possible solutions, which may require the large motions you see.
    One way to combat this is to use a seed for the IK if you know you will always work within a certain area of the workspace in a certain orientation. Another way is to use another kinematics package like TracIK or BioIK, and hope that they are more robust. Those two have MoveIt plugins you can use pretty easily, TracIK even has a tutorial page.

  2. If your joint space goal is reasonable, but the path there is obstructed, free planning in joint space (the default like with RRTConnect) can produce large and erratic-looking motions in joint space. You can try to simplify the trajectory, but it may not solve the problem (and could use some work in MoveIt; feel free to contribute), or you could try optimization-based methods like STOMP, CHOMP or TrajOpt.

Another very common practice is to use named poses to return to or move between known joint configurations, rather than planning long motions with pose goals. This makes motions more predictable if there are no collisions between the poses.

edit flag offensive delete link more

Comments

This is the most clear answer read today! Thank you so much! I have only another question about the seed for IK that you mentioned before: do you mean to reduce some joint limit directly?

Kappa95 gravatar image Kappa95  ( 2020-10-22 11:56:49 -0500 )edit

No, I meant to give an appropriate initial joint configuration as a seed to the IK so that it converges to the configuration you want on first try, rather than resetting and starting from a random configuration. But reducing the joint limits to keep the robot in a certain range of orientations is also a very common strategy. Can't believe I forgot to mention that.

fvd gravatar image fvd  ( 2020-10-23 06:21:10 -0500 )edit

Thank you so much again, probably following your advices i have solved setting the workspace for each arm group. Using Python i had defined 2 different workspaces as a vector of min and max x, y, z coordinates, one for each arm. And then i had setted them using:

`group_l.set_workspace(ws_L)
 group_r.set_workspace(ws_R)`

Instead i didn't understand how can i choose the initial joint configuration for using as a seed with KDL (if it is possible)? Thank you again for your patience

Kappa95 gravatar image Kappa95  ( 2020-10-25 14:28:34 -0500 )edit

The RobotState's current state is used as the seed. You can set it with this, for example. Consider opening a new question if you have any more, and accepting this answer so this question is out of the queue. Cheers

fvd gravatar image fvd  ( 2020-10-25 22:00:12 -0500 )edit

Question Tools

3 followers

Stats

Asked: 2020-10-21 11:26:03 -0500

Seen: 440 times

Last updated: Oct 22 '20