Rosanswers logo


I am trying to use MoveIt's python interface to plan cartesian trajectories with a UR3e robot using ROS-Melodic. I have set up everything and it works fine. I am using it with the TRAC-IK solver.

The problem is that when I get a solution from the planner, the solution can change very drastically from a small motion to an unnecessarily long trajectory. The main difference between trajectories is the goal joint configuration from the goal pose. So my question is, how to request the closes IK solution to the current joint configuration?

I can do that manually by computing the IK solutions using TRAK-IK, computing the closes solution to my current configuration, and then requesting MoveIt to plan using the joint configuration that I choose rather than using a goal pose. When I do that, the resulting trajectory is always similar. However, isn't there a way to request MoveIt to use a specific IK solution over another?

Edit: Video for clarity. From the same initial position, and to the same target pose (Cartesian goal), different IK solutions. https://youtu.be/7GiPZUdlPNA

Originally posted by cambel07 on ROS Answers with karma: 92 on 2021-02-19

Post score: 0

Original comments

Comment by fvd on 2021-02-20:
I'm not sure I understand what you're asking. When you say "cartesian trajectories", do you mean one calculated by the cartesian path planning function? Because for 6-DOF robots this should not depend on the IK solution at the goal pose. Also, do you mean "How to request closest IK solution to a given joint configuration?"

Comment by gvdhoorn on 2021-02-20:
Is TracIK configured to use its Distance solve type, instead of the default Speed?

Comment by cambel07 on 2021-02-20:
@fvd Sorry, about "cartesian trajectories" I meant that I am using the move_group.set_pose_target() method, which offers no option to specify which of the possible IK solutions to use.

And, yes, I also mean to ask "how to request the closest IK solution to a given joint configuration?", it just that I want to get the closest to the current joint configuration of the robot.

I included a video in the question for clarity

@gvdhoorn no, how do I configure TRACK-IK to do that? I checked the code and the logs and it is expecting a rosparam move_group(leftarm in my case)/solve_type, but even if I specify "Distance" it still doesn't seem to recognize it :/

Looking in common namespaces for param name: leftarm/solve_type

Using solve type Speed

Comment by fvd on 2021-02-20:
Can you add how you define the parameter your question?

Comment by gvdhoorn on 2021-02-20:\

how do I configure TRACK-IK to do that?

In the kinematics.yaml of your MoveIt cfg package, like so (manipulator is the group name here, change to whatever you have of course):

  kinematics_solver: trac_ik_kinematics_plugin/TRAC_IKKinematicsPlugin
  solve_type: Distance

Comment by cambel07 on 2021-02-20:
@gvdhoorn thank you! Silly me, I was publishing a rosparam with that "manipulator/solve_type" but that way didn't work. I wonder why...

Anyways, I just tried using the kinematics.yaml and it worked. TRAC-IK recognizes the solver type and it does seem to work as I wished, the IK solution seems to be the same every time.

Comment by cambel07 on 2021-02-20:
@fvd sorry, I don't understand your question. Do you mean the TRAC-IK parameter?

if that's the case I defined the parameter <param name="leftarm/solve_type" type="str" value="Distance" />, I defined the parameter before calling the move_group definition, and I checked that the parameter existed in the parameter server but still for whatever reason TRAC-IK was not able to read from it or something.

Comment by gvdhoorn on 2021-02-20:\

@gvdhoorn thank you! Silly me, I was publishing a rosparam with that "manipulator/solve_type" but that way didn't work. I wonder why...

it needs to be in a specific namespace. If it's not there, TracIK will not find it and default to Speed.

Comment by cambel07 on 2021-02-21:
@gvdhoorn I see, thanks. I suppose for the TRAC-IK solver that is the right solution. should we close this question? should I add the answer?

Comment by gvdhoorn on 2021-02-21:
Technically, the Trac-IK configuration is not an answer to your question.

Your question was:

MoveIt - Python interface: How to request closest IK solution to current joint configuration?

Afaik, there is no way to do that with MoveIt currently, but perhaps @fvd can add something here.

The fact we can 'circumvent' this limitation by configuring the IK solver to achieve the desired behaviour is nice, but not an answer to your actual question.

Unless this was an xy-problem.

Comment by cambel07 on 2021-02-22:
I see, yes, it would be rather nice to have an option in MoveIt to obtain the IK solution that matches some criteria, such as the closest to the current joint configuration. Especially in the cases where there are multiple valid IK solutions.

Comment by gvdhoorn on 2021-02-22:
Then I guess the answer right now would be: you can't.

With the suggestion to post this as a feature / enhancement request on the MoveIt issue tracker.


1 Answer 1


Rosanswers logo

A workaround was already proposed in the comments, but for context:

  • In C++, you should be able to obtain multiple IK solutions from the Kinematics API, and then sort through them yourself, as described in this question. You can also see how RobotState uses Kinematics methods here. The need for a function to get the "closest" IK solution from the KinematicsBase API has been brought up in a Github issue.

  • The Python interface is quite limited, especially for moveit_core (the C++-native internals like this). There are quite a lot for the move_group_interface(MoveGroupCommander in Python), and a few for the RobotState and planning_scene_interface. There have been long discussions about this on Github. There is no obstacle to adding Python bindings yourself as needed - except that it is a bit confusing that they are defined in two places (here and here for the move_group_interface).

  • Another option to access C++ functionality in Python is to add a MoveGroupCapability and then call that in your Python code. You can go all the way and add a convenience function to the MoveGroupInterface and expose that to Python as well.

I hope that is a little helpful. As always, if you implement something that might be useful or fix a problem, do consider contributing it upstream. Cheers

Originally posted by fvd with karma: 2180 on 2021-02-22

This answer was ACCEPTED on the original site

Post score: 2

Original comments

Comment by gvdhoorn on 2021-02-23:
Pedantic, but technically, the answer is then still: "right now, this is not supported".

Comment by fvd on 2021-02-23:
The "this is not supported right now, but" is silent :)


Your Answer

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