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

cvancleef's profile - activity

2022-08-02 18:03:08 -0500 received badge  Famous Question (source)
2022-08-02 18:03:08 -0500 received badge  Notable Question (source)
2020-04-19 03:29:04 -0500 received badge  Notable Question (source)
2018-12-18 01:10:07 -0500 received badge  Famous Question (source)
2018-12-18 01:10:07 -0500 received badge  Notable Question (source)
2018-01-08 17:19:00 -0500 received badge  Famous Question (source)
2017-11-09 15:08:31 -0500 received badge  Famous Question (source)
2017-08-21 15:35:41 -0500 received badge  Popular Question (source)
2017-08-09 21:26:41 -0500 received badge  Notable Question (source)
2017-08-09 13:20:15 -0500 received badge  Popular Question (source)
2017-08-09 11:56:27 -0500 edited question Stop the robot from moving

Stop the robot from moving I'm using the MoveGroupCommander class to move my robot around, like so: group.set_p

2017-08-09 11:14:44 -0500 commented question Stop the robot from moving

So it looks like there isn't a good way to go about doing this at the moment?

2017-08-09 10:14:20 -0500 edited question Stop the robot from moving

Stop the robot from moving I'm using the MoveGroupCommander class to move my robot around, like so: group.set_p

2017-08-09 10:14:01 -0500 asked a question Stop the robot from moving

Stop the robot from moving I'm using the MoveGroupCommander class to move my robot around, like so: group.set_p

2017-08-02 04:50:51 -0500 received badge  Popular Question (source)
2017-07-31 17:45:31 -0500 received badge  Notable Question (source)
2017-07-19 06:43:02 -0500 commented question pub a joint angles to baxter_moveit_stomp_trac_ik

Could you try this after you initialize group? robot_state::RobotState start_state(*group.getCurrentState()); group.s

2017-07-19 06:42:41 -0500 commented question pub a joint angles to baxter_moveit_stomp_trac_ik

Could you try this after you initialize group? robot_state::RobotState start_state(*group.getCurrentState()); group.s

2017-07-19 06:42:24 -0500 commented question pub a joint angles to baxter_moveit_stomp_trac_ik

Could you try this after you initialize group? robot_state::RobotState start_state(*group.getCurrentState());

2017-07-19 06:41:43 -0500 commented question pub a joint angles to baxter_moveit_stomp_trac_ik

Could you try this after you initialize group? robot_state::RobotState start_state(*group.getCurrentState());

2017-07-18 11:37:03 -0500 commented question pub a joint angles to baxter_moveit_stomp_trac_ik

If you open MoveIt setup assistant and load in your robot, and go to virtual joints, do you have a joint connecting the

2017-07-18 11:21:32 -0500 commented question pub a joint angles to baxter_moveit_stomp_trac_ik

If you open MoveIt setup assistant and load in your robot, and go to virtual joints, do you have a joint connecting the

2017-07-11 10:59:22 -0500 commented answer Using correct solve_type when running code

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 f

2017-07-11 10:59:22 -0500 received badge  Commentator
2017-07-11 07:09:34 -0500 marked best answer Using correct solve_type when running code

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.

2017-07-11 06:41:12 -0500 received badge  Famous Question (source)
2017-07-10 12:04:12 -0500 received badge  Popular Question (source)
2017-07-10 10:48:58 -0500 answered a question Using correct solve_type when running code

Finally fixed this problem by editing the file roscpp_initializer.cpp (catkin_ws/src/moveit/moveit_ros/planning_interfac

2017-07-07 09:39:52 -0500 received badge  Notable Question (source)
2017-07-07 07:41:35 -0500 marked best answer Moveit! Using solve type speed instead of distance

I switched to using trac_ik for my kinematics plugin and set the solve type to distance. Here's my kinematics.yaml

manipulator:
  kinematics_solver: trac_ik_kinematics_plugin/TRAC_IKKinematicsPlugin
  solve_type: Distance
  kinematics_solver_search_resolution: 0.002
  kinematics_solver_timeout: 0.1
  kinematics_solver_attempts: 300

However, when I launch MoveIt I get the following messages:

[ INFO] [1498738699.604294668]: Looking in private handle: /move_group_commander_wrappers_1498738699102337314 for param name: manipulator/solve_type
[ INFO] [1498738699.605287670]: Using solve type Speed

Am I setting the solve type incorrectly for use in MoveIt?


EDIT: I added

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

to the start of my move_group.launch file. MoveIt! now displays the correct solve type on launch, but when I run code to move my robot, the terminal running my code still says its using solve type Speed.

[ INFO] [1498748362.955713863]: Looking in private handle: /move_group_commander_wrappers_1498748362452794445 for param name: manipulator/position_only_ik
[ INFO] [1498748362.960244821]: Looking in private handle: /move_group_commander_wrappers_1498748362452794445 for param name: manipulator/solve_type
[ INFO] [1498748362.961557738]: Using solve type Speed
2017-07-07 07:27:40 -0500 commented answer Using correct solve_type when running code

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

2017-07-07 05:25:43 -0500 received badge  Popular Question (source)
2017-07-05 08:37:01 -0500 asked a question Using correct solve_type when running code

Using correct solve_type when running code This question is related to one I posted earlier: http://answers.ros.org/ques

2017-06-29 10:11:38 -0500 received badge  Popular Question (source)
2017-06-29 10:01:45 -0500 commented answer Moveit! Using solve type speed instead of distance

I edited my question, do I need to change some other files to get this to work with my code?

2017-06-29 10:01:38 -0500 commented answer Moveit! Using solve type speed instead of distance

I edited my question, do I need to change some other files to get this to work with my code?

2017-06-29 10:01:11 -0500 edited question Moveit! Using solve type speed instead of distance

Moveit! Using solve type speed instead of distance I switched to using trac_ik for my kinematics plugin and set the solv

2017-06-29 08:10:18 -0500 marked best answer Set maximum number of joint rotations per plan

I'm issuing my robot move commands in a way similar to this tutorial:

http://docs.ros.org/hydro/api/pr2_mov...

However, many of the plans it comes up with have unnecessary joint rotations. Is there to specify the maximum amount a joint can rotate for a planned path programmatically (ie no more than two full rotations or no more than 720 degrees movement in the joint during the plan execution)? If not, is there a way to set it manually?

2017-06-29 08:08:57 -0500 received badge  Popular Question (source)
2017-06-29 07:28:16 -0500 asked a question Moveit! Using solve type speed instead of distance

Moveit! Using solve type speed instead of distance I switched to using trac_ik for my kinematics plugin and set the solv

2017-06-28 14:33:35 -0500 commented question Set maximum number of joint rotations per plan

For the URDF, would that be <limit>'s <upper> and <lower> tags? That seems like what I'm looking for,

2017-06-28 14:32:21 -0500 commented question Set maximum number of joint rotations per plan

For the URDF, would that be <limit>'s <upper> and <lower> tags? That seems like what I'm looking for,

2017-06-26 14:43:19 -0500 received badge  Supporter (source)
2017-06-26 11:45:56 -0500 commented question Set maximum number of joint rotations per plan

I think its joint_6 of the lrmate200id rotating if that makes a difference. Also, in regards to the XY problem, I suppos

2017-06-26 11:44:51 -0500 commented question Set maximum number of joint rotations per plan

I think its joint_6 of the lrmate200id rotating if that makes a difference

2017-06-26 11:44:19 -0500 commented question Set maximum number of joint rotations per plan

For simple planned paths, the head of the robot will just keep rotating throughout the movement, where very little if an