0
$\begingroup$

Rosanswers logo

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


Originally posted by Kappa95 on ROS Answers with karma: 91 on 2020-10-21

Post score: 1


Original comments

Comment by fvd on 2020-10-21:
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?

Comment by Kappa95 on 2020-10-22:
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.

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

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.


Originally posted by fvd with karma: 2180 on 2020-10-22

This answer was ACCEPTED on the original site

Post score: 2


Original comments

Comment by Kappa95 on 2020-10-22:
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?

Comment by fvd on 2020-10-23:
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.

Comment by Kappa95 on 2020-10-25:
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

Comment by fvd on 2020-10-25:
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

$\endgroup$

Your Answer

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