Using correct solve_type when running code

asked 2017-07-05 08:37:01 -0500

cvancleef
24 ●5 ●7 ●11

This question is related to one I posted earlier: http://answers.ros.org/question/26513... . MoveIt! currently launches correctly with solve_type: Distance, which is the solve type I want. However, when I run a Python script to issue move commands, it still uses solve_type: Speed:

[ INFO] [1499261352.380466647]: Looking in private handle: /move_group_commander_wrappers_1499261351880510562 for param name: manipulator/position_only_ik
[ INFO] [1499261352.381577584]: Looking in private handle: /move_group_commander_wrappers_1499261351880510562 for param name: manipulator/solve_type
[ INFO] [1499261352.382617524]: Using solve type Speed

The code I use to set up my node comes from the tutorial: http://docs.ros.org/hydro/api/pr2_mov... .

How would I guarantee the solve_type used when running my code is the type I want? The first idea that comes to mind is changing where it looks for the parameter manipulator/solve_type, but I'm not sure how to do that.

edit retag flag offensive close merge delete

add a comment

0

answered 2017-07-10 10:48:58 -0500

cvancleef
24 ●5 ●7 ●11

Finally fixed this problem by editing the file roscpp_initializer.cpp (catkin_ws/src/moveit/moveit_ros/planning_interface/py_bindings_tools/src) to avoid generating a number at the end of the node name so that I can reference it in my launch file (thanks to gvdhoorn for pointing me in the right direction).

I changed

ros::init(fake_argc, fake_argv, ROScppNodeName(),
ros::init_options::AnonymousName | ros::init_options::NoSigintHandler);

to

ros::init(fake_argc, fake_argv, ROScppNodeName(), ros::init_options::NoSigintHandler);

Then I went to my move_group.launch file and added the following

  <group ns="move_group_commander_wrappers">
    <rosparam command="load" file="$(find fanuc_lrmate200id_moveit_config)/config/kinematics.yaml"/>
  </group>

After running catkin_make, my code now outputs that it is using the correct solve_type

edit flag offensive delete link

Comments

I appreciate you marking my answer as the answer, but I feel in this case that you have actually solved it yourself. The only thing I did was provide you with some guidance.

I've marked your answer as the correct one.

gvdhoorn ( 2017-07-11 07:50:53 -0500 )edit

Having said that: this should really not have required you editing the sources of the Python wrapper for the MoveIt commander.

It would perhaps be nice if you could report this as an issue on the MoveIt issue tracker, and perhaps also hint at what you did to work around this.

gvdhoorn ( 2017-07-11 07:51:46 -0500 )edit

Ok, i'll make an issue. Also I couldn't select myself as the answer due to my low score, so I just went with yours. Ty for fixing it

cvancleef ( 2017-07-11 10:59:22 -0500 )edit

add a comment

0

answered 2017-07-07 04:01:13 -0500

gvdhoorn
86574 ●283 ●1432 ●1054 http://cor.tudelft.nl/

The solution here would be to set the manipulator/solve_type parameter in the private namespace of the move_group_commander_wrapper before it gets instantiated.

I haven't looked at how the Python wrappers for the move_group_commander are created, so I don't know where the _1499261351880510562 suffix comes from. I suspect it's a Unix timestamp, which is typically added when nodes are created with anonymous=True as one of the arguments.

If that can be left out, then you should be able to first set the required parameters (using a launch file), and then start the node that instantiates the move_group_commander_wrapper. That should allow you to set the solve_type parameter.

edit flag offensive delete link

Comments

I have anonymous set to False now, but move_group_commander_wrapper still gets a different number every time I run my code.

cvancleef ( 2017-07-07 07:27:40 -0500 )edit

Then it's probably something internal to how the Python wrappers work for move_group_commander. Perhaps some of the other MoveIt devs can shine some light one this. @v4hn?

gvdhoorn ( 2017-07-07 07:35:59 -0500 )edit

add a comment

Using correct solve_type when running code

2 Answers

Comments

Comments

Question Tools

Stats

Related questions

Using correct solve_type when running code edit

2 Answers

Comments

Comments

Question Tools

Stats

Related questions

Using correct solve_type when running code