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

Revision history [back]

click to hide/show revision 1
initial version

One of the arguments to computeCartesianPath(..) is a reference to a moveit_msgs::RobotTrajectory instance (the trajectory argument).

That reference is used to store the result of the interpolation. For typical robots (ie: serial manipulators), the joint_trajectory field of the moveit_msgs::RobotTrajectory would be the one you'd be interested in.

As this is just a regular trajectory_msgs/JointTrajectory you could do whatever you want with it.

Since I am only using IK here, I was wondering if it is possible to just compute the joint angles that would be commanded if I would execute a linear movement.

It's already a trajectory in joint space, unless I'm misunderstanding you, I don't believe you'd need to use IK here at all.

One of the arguments to computeCartesianPath(..) is a reference to a moveit_msgs::RobotTrajectory instance (the trajectory argument).

That reference is used to store the result of the interpolation. For typical robots (ie: serial manipulators), the joint_trajectory field of the moveit_msgs::RobotTrajectory would be the one you'd be interested in.

As this is just a regular trajectory_msgs/JointTrajectory you could do whatever you want with it.

Since I am only using IK here, I was wondering if it is possible to just compute the joint angles that would be commanded if I would execute a linear movement.

It's already a trajectory in joint space, so unless I'm misunderstanding you, I don't believe you'd need to use IK here at all.

One of the arguments to computeCartesianPath(..) is a reference to a moveit_msgs::RobotTrajectory instance (the trajectory argument).

That reference is used to store the result of the interpolation. For typical robots (ie: serial manipulators), the joint_trajectory field of the moveit_msgs::RobotTrajectory would be the one you'd be interested in.

As this is just a regular trajectory_msgs/JointTrajectory you could do whatever you want with it.it, including iterating over all the points and inspecting the joint angles.

Since I am only using IK here, I was wondering if it is possible to just compute the joint angles that would be commanded if I would execute a linear movement.

It's already a trajectory in joint space, so unless I'm misunderstanding you, I don't believe you'd need to use IK here at all.

One of the arguments to computeCartesianPath(..) is a reference to a moveit_msgs::RobotTrajectory instance (the trajectory argument).

That reference is used to store the result of the interpolation. For typical robots (ie: serial manipulators), the joint_trajectory field of the moveit_msgs::RobotTrajectory would be the one you'd be interested in.

As this is just a regular trajectory_msgs/JointTrajectory you could do whatever you want with it, including iterating over all the points and inspecting the joint angles.

Since I am only using IK here, I was wondering if it is possible to just compute the joint angles that would be commanded if I would execute a linear movement.

It's already a trajectory in joint space, so unless I'm misunderstanding you, I don't believe you'd need to use IK here at all.


Edit:

It's already a trajectory in joint space, unless I'm misunderstanding you, I don't believe you'd need to use IK here at all.

I thought computeCartesianPath() generates a straight line in the cartesian space and then translates that to joint angles using IK.

Yes, that is what it does, more or less.

I figured computeCartesianPath() may look "in the past" to not command instant configuration changes.

It doesn't really 'command' anything (it just interpolates), but while the function does try to minimise joint space distance between consecutive points, it is dependent on the configured IK solver to provide it with solutions. If those solutions lie very far from each other, computeCartesianPath(..) cannot avoid sometimes using a solution that would result in a configuration change.

The jump_threshold argument can be used to configure the threshold, but again, if your IK solver returns "bad" solutions, there's only so much computeCartesianPath(..) can do.

If you don't need microsecond-range solve times, I'd recommend using trac_ik with solve_type set to Distance.

One of the arguments to computeCartesianPath(..) is a reference to a moveit_msgs::RobotTrajectory instance (the trajectory argument).

That reference is used to store the result of the interpolation. For typical robots (ie: serial manipulators), the joint_trajectory field of the moveit_msgs::RobotTrajectory would be the one you'd be interested in.

As this is just a regular trajectory_msgs/JointTrajectory you could do whatever you want with it, including iterating over all the points and inspecting the joint angles.

Since I am only using IK here, I was wondering if it is possible to just compute the joint angles that would be commanded if I would execute a linear movement.

It's already a trajectory in joint space, so unless I'm misunderstanding you, I don't believe you'd need to use IK here at all.


Edit:

It's already a trajectory in joint space, unless I'm misunderstanding you, I don't believe you'd need to use IK here at all.

I thought computeCartesianPath() generates a straight line in the cartesian space and then translates that to joint angles using IK.

Yes, that is what it does, more or less.

But that is what computeCartesianPath(..) does. I still don't understand how IK is involved in your side.

I figured computeCartesianPath() may look "in the past" to not command instant configuration changes.

It doesn't really 'command' anything (it just interpolates), but while the function does try to minimise joint space distance between consecutive points, it is dependent on the configured IK solver to provide it with solutions. If those solutions lie very far from each other, computeCartesianPath(..) cannot avoid sometimes using a solution that would result in a configuration change.

The jump_threshold argument can be used to configure the threshold, but again, if your IK solver returns "bad" solutions, there's only so much computeCartesianPath(..) can do.

If you don't need microsecond-range solve times, I'd recommend using trac_ik with solve_type set to Distance.