# Improving MoveIt, RViz, and using trac_ik

Hello all,

I am currently attempting to use MoveIt and trac_ik to coordinate x4 UR arms for a project in ROS. I had a few questions that maybe someone could help me with/point me in the right direction with:

1. Integration with MoveIt, I saw on the BitBucket page for trac_ik that you can set the solver via the kinematics.yaml file. I have changed it, and I tried to relaunch the demo.launch file that MoveIt created for my robot, and I'm still getting non-converging solutions in RViz, not matter how small of a movement I give it (like a rotation around a joint or to move up vertically a short distance). Is there any way to improve this? I see in the terminal that i'm getting feedback that says KDL, did the solver really not change? How do I change the solver via RViz/MoveIt?

2. When we move to a programmatic method to control the robots, the use of moveit_commander (python) will probably be deployed. Since we have trac_ik set in the yaml file, it should automatically use that solver for our control scripts, right?

3. In regards to our approach, does getting good results in RViz translate to good results in moveit_commander via python? I know it may sound silly, but with the same solver we should get the same solution regardless of interface?

4. Would anyone suggest suggest a different method of getting from joint space to Cartesian? We are using the ros_controller for joint state control.

I apologize if these questions are silly, this is my first real attempt to do something with MoveIt aside from the well documented PR2 tutorials.

edit retag close merge delete

Sort by » oldest newest most voted

1 . [..] I see in the terminal that i'm getting feedback that says KDL, did the solver really not change?

What you describe is (on a high-level) how you would configure an IK plugin for a MoveIt configuration, so without seeing exactly what you did, I'd say it should work.

How do I change the solver via RViz/MoveIt?

You don't / can't. The only thing you can do -- which is somewhat via MoveIt -- is to load the MoveIt configuration pkg into the MoveIt Setup Assistant, then going to the Planning Groups screen and after selecting the group, clicking Edit Selected button. There you can select a plugin from the drop-down.

But that is essentially the same as changing the kinematics_solver entry in the kinematics.yaml file.

Make sure you've saved the file though, and relaunched everything correctly.

2 . When we move to a programmatic method to control the robots, the use of moveit_commander (python) will probably be deployed. Since we have trac_ik set in the yaml file, it should automatically use that solver for our control scripts, right?

The commander will talk to whatever move_group instance you have configured and running. So if you have your solver configured properly, it should use that.

3 . In regards to our approach, does getting good results in RViz translate to good results in moveit_commander via python? I know it may sound silly, but with the same solver we should get the same solution regardless of interface?

I can't say for sure, as I'm not intimately familiar with the source code of moveit_commander. In the end, both RViz and the commander use the service and action interfaces exposed by a move_group. So if the service requests and action clients submit the same data, you should get the same performance.

As, depending on the planner, there will be an element of chance in the motion planning, I don't know if you'll get the exact same solution, but that would also be an issue with two consecutive RViz sessions.

4 . Would anyone suggest suggest a different method of getting from joint space to Cartesian? We are using the ros_controller for joint state control.

I'm not sure I understand this question.

more

It doesn't sound like MoveIt! is actually using trac_ik.

In the past, there have been issues with the parameter server interference. I'd point you to this closed ticket: https://bitbucket.org/traclabs/trac_i...

Essentially the parameter server might be interfering with settings set elsewhere.

more