| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
I am planning, executing and recording linear robot movement with computeCartesianPath().
I would like to "simulate" this program. Essentially just computing the previously recorded movement (format: joint angles with fixed sampling frequency).
I am not sure how to go about this without actually executing the movement on the real or simulated robot.
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.
Thanks for the answer, Ill try it that way and then report back!
I want to check for paths that command configurations in close proximity to singularities via evaluating joint velocities.
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. I figured computeCartesianPath() may look "in the past" to not command instant configuration changes.
Asked: 2019-11-13 00:53:17 -0500
Seen: 401 times
Last updated: Nov 13 '19
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
This confuses me:
but:
What does "simulate" mean in the first sentence?
Are you asking how to concatenate two trajectories?
Essentially, I have a bunch of linear movements, say 400, that I want to evaluate, i.e. what joint angles would be commanded. If I compute, execute, record and log the joint angles of every single linear movement, then my program takes very long. 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 the very same linear movement. That way, I want to save time.
So you want to
computeCartesianPath(..)and then process the output without sending it off for execution?Yes, exactly.
This will be pedantic, but: the output of
computeCartesianPath(..)is not what I would call a "program". It's a series of joint angles with associated timing information. With a stretch, that could be considered similar to a (traditional) robot program containing only joint motions, but even then it would be far from an actual program.