ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
2021-05-05 02:54:56 -0500 | received badge | ● Favorite Question (source) |
2020-12-14 05:32:20 -0500 | asked a question | Trac IK joint positions beyond +/-180 degrees Trac IK joint positions beyond +/-180 degrees Whenever I compute joint positions for a trajectory using TracIK, where on |
2020-03-26 12:07:42 -0500 | marked best answer | MoveIt End effector moves correctly but reports back different orientation I've got a simulation setup of the Kuka KR6 Agilus running in Gazebo using MoveIt for movement. In order to move the robot I'm calling MoveGroupInterface::setPoseTarget and MoveGroupInterface::asyncMove(), and to get the current pose I'm calling MoveGroupInterface::getCurrentPose. There is an inconsistency between the pose that is set and the pose that is reported from MoveIt. The image below shows the pose I'm requesting and the pose I'm getting after the robot has reached its pose. I guess the pose is correct, but why the difference in the quaternions representing orientation? I don't specify the end_effector_link in any calls to setPoseTarget() or getCurrentPose(). |
2020-03-26 12:06:29 -0500 | commented question | MoveIt End effector moves correctly but reports back different orientation Sorry for the late reply, added the answer but I'm unable to accept my own answer due to limited points. |
2020-03-26 12:05:55 -0500 | answered a question | MoveIt End effector moves correctly but reports back different orientation Not really a fix, but orientations became accurate when a tool was included in the kinematic chain. From what I can re |
2019-10-21 05:50:45 -0500 | commented question | MoveIt End effector moves correctly but reports back different orientation Not really a fix, but orientations became accurate when a tool was included in the kinematic chain. From what I can reca |
2019-10-21 05:40:45 -0500 | commented question | Joint position pertubation using effort_controllers/JointPositionController No fix I'm afraid, just a bypass. Check out this thread on github https://github.com/ros-controls/ros_controllers/issues |
2019-10-08 04:16:22 -0500 | received badge | ● Taxonomist |
2019-07-14 01:44:24 -0500 | received badge | ● Famous Question (source) |
2019-05-29 08:32:59 -0500 | received badge | ● Famous Question (source) |
2019-02-19 03:36:13 -0500 | received badge | ● Notable Question (source) |
2019-02-19 03:36:13 -0500 | received badge | ● Popular Question (source) |
2019-01-23 08:17:13 -0500 | commented question | MoveIt End effector moves correctly but reports back different orientation The problem is with the last joint. When joint values are calculated it is set to arbitrary positions as it doesn't infl |
2019-01-23 07:52:36 -0500 | received badge | ● Notable Question (source) |
2019-01-23 07:52:36 -0500 | received badge | ● Popular Question (source) |
2019-01-23 07:49:02 -0500 | commented question | MoveIt End effector moves correctly but reports back different orientation Without any changes it now reports the following orientation (0.0, 0.7071, 0.0, 0.7071) with the same desired position a |
2019-01-23 07:43:05 -0500 | asked a question | MoveIt End effector moves correctly but reports back different orientation MoveIt End effector moves correctly but reports back different orientation I've got a simulation setup of the Kuka KR6 A |
2018-10-25 00:59:52 -0500 | received badge | ● Enthusiast |
2018-10-19 11:57:25 -0500 | commented question | Joint position pertubation using effort_controllers/JointPositionController Here's a video showing the behavior https://youtu.be/PqQh9spXjgM |
2018-10-17 08:06:53 -0500 | asked a question | Joint position pertubation using effort_controllers/JointPositionController Joint position pertubation using effort_controllers/JointPositionController This question has already been posted on ans |