The site is read-only. Please transition to use Robotics Stack Exchange
| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
 | 1 | initial version |
In the question, it was stated that OMPL, which I use, does not factor in time.
Which is correct: by default, OMPL will not consider time. It's purely kinematic planning.
However, I later found out that the trajectory planning does in fact use time, as this is processed in the JointTrajectoryPoint message.
Depending on how you define it, there is no trajectory planning in MoveIt (personally I consider planning to be more involved than interpolation or time-parameterising, but this will depend on who you ask).
Now my question is, what is done with this time info
"inside MoveIt"? Nothing.
how is it used in trajectory planning?
It isn't.
Can the PID gains have any influence on this and vice versa?
No. Not on the algorithms which actually calculate those timestamp, velocities and accelerations.
I would again refer you to the Time Parameterization in MoveIt's documentation.
To make this more than a "link only" answer, I'll quote the relevant parts here (emphasis mine):
MoveIt is currently primarily a kinematic motion planning framework - it plans for joint or end effector positions but not velocity or acceleration. However, MoveIt does utilize post-processing to time parameterize kinematic trajectories for velocity and acceleration values.
and:
MoveIt can support different algorithms for post-processing a kinematic trajectory to add timestamps and velocity/acceleration values. Currently there are three available by default in MoveIt:
Summarising: OMPL output is a path. Post-processing via the time-parameterisation algorithms turns that into a trajectory (ie: adds time, velocity and acceleration to each trajectory point).
None of those algorithms use any information other than the limits configured on each joint (which are taken from your .urdf or .xacro (in combination with and via the config/joint_limits.yaml file in your MoveIt configuration package)).
The assumption is that you've provided appropriate joint limits to those algorithms, and that the entity responsible for execution of the trajectory is capable of achieving the performance "promised" by those limits.
| | 2 | No.2 Revision |
In the question, it was stated that OMPL, which I use, does not factor in time.
Which is correct: by default, OMPL will not consider time. It's purely kinematic planning.
However, I later found out that the trajectory planning does in fact use time, as this is processed in the JointTrajectoryPoint message.
Depending on how you define it, there is no trajectory planning in MoveIt (personally I consider planning to be more involved than interpolation or time-parameterising, time-parameterisation, but this will depend on who you ask).
Now my question is, what is done with this time info
"inside MoveIt"? Nothing.
By consumers of the JointTrajectory message? They should use it to determine at which times in the execution of the trajectory the state encoded by each JointTrajectoryPoint should be achieved.
how is it used in trajectory planning?
It isn't.
Can the PID gains have any influence on this and vice versa?
No. Not on the algorithms which actually calculate those timestamp, velocities and accelerations.
I would again refer you to the Time Parameterization in MoveIt's documentation.
To make this more than a "link only" answer, I'll quote the relevant parts here (emphasis mine):
MoveIt is currently primarily a kinematic motion planning framework - it plans for joint or end effector positions but not velocity or acceleration. However, MoveIt does utilize post-processing to time parameterize kinematic trajectories for velocity and acceleration values.
and:
MoveIt can support different algorithms for post-processing a kinematic trajectory to add timestamps and velocity/acceleration values. Currently there are three available by default in MoveIt:
Summarising: OMPL output is a path. Post-processing via the time-parameterisation algorithms turns that into a trajectory (ie: adds time, velocity and acceleration to each trajectory point).
None of those algorithms use any information other than the limits configured on each joint (which are taken from your .urdf or .xacro (in combination with and via the config/joint_limits.yaml file in your MoveIt configuration package)).
The assumption is that you've provided appropriate joint limits to those algorithms, and that the entity responsible for execution of the trajectory is capable of achieving the performance "promised" by those limits.
| | 3 | No.3 Revision |
In the question, it was stated that OMPL, which I use, does not factor in time.
Which is correct: by default, OMPL will not consider time. It's purely kinematic planning.
However, I later found out that the trajectory planning does in fact use time, as this is processed in the JointTrajectoryPoint message.
Depending on how you define it, there is no trajectory planning in MoveIt (personally I consider planning to be more involved than interpolation or time-parameterisation, but this will depend on who you ask).
Now my question is, what is done with this time info
"inside MoveIt"? Nothing.
By consumers of the JointTrajectory message? They should use it to determine at which times in the execution of the trajectory the state encoded by each JointTrajectoryPoint should be achieved.
how is it used in trajectory planning?
It isn't.
Can the PID gains have any influence on this and vice versa?
No. Not on the algorithms which actually calculate those timestamp, velocities and accelerations.
I would again refer you to the Time Parameterization in MoveIt's documentation.
To make this more than a "link only" answer, I'll quote the relevant parts here (emphasis mine):
MoveIt is currently primarily a kinematic motion planning framework - it plans for joint or end effector positions but not velocity or acceleration. However, MoveIt does utilize post-processing to time parameterize kinematic trajectories for velocity and acceleration values.
and:
MoveIt can support different algorithms for post-processing a kinematic trajectory to add timestamps and velocity/acceleration values. Currently there are three available by default in MoveIt:
Summarising: OMPL output is a path. Post-processing via the time-parameterisation algorithms turns that into a trajectory (ie: adds time, velocity and acceleration to each trajectory point).
None of those algorithms use any information other than the limits configured on each joint (which are taken from your .urdf or .xacro (in combination with and via the config/joint_limits.yaml file in your MoveIt configuration package)).
The assumption is that you've provided appropriate joint limits to those algorithms, and that the entity responsible for execution of the trajectory is capable of achieving the performance "promised" by those limits.
So to answer the question which forms the title of this post:
In what way does MoveIt! process time info?
If by "time info" you mean the time_from_start field in each of the JointTrajectoryPoints in a JointTrajectory, then the answer would be: it doesn't.
MoveIt produces JointTrajectory. It does not consume them. It never looks at those values, as they are not meant for consumption by MoveIt, but by entities (ie: nodes, drivers, something else) which are capable of executing them (ie: making robots move).
| | 4 | No.4 Revision |
In the question, it was stated that OMPL, which I use, does not factor in time.
Which is correct: by default, OMPL will not consider time. It's purely kinematic planning.
However, I later found out that the trajectory planning does in fact use time, as this is processed in the JointTrajectoryPoint message.
Depending on how you define it, there is no trajectory planning in MoveIt (personally I consider planning to be more involved than interpolation or time-parameterisation, but this will depend on who you ask).
Now my question is, what is done with this time info
"inside MoveIt"? Nothing.
By consumers of the JointTrajectory message? They should use it to determine at which times in the execution of the trajectory the state encoded by each JointTrajectoryPoint should be achieved.
how is it used in trajectory planning?
It isn't.
Can the PID gains have any influence on this and vice versa?
No. Not on the algorithms which actually calculate those timestamp, velocities and accelerations.
I would again refer you to the Time Parameterization in MoveIt's documentation.
To make this more than a "link only" answer, I'll quote the relevant parts here (emphasis mine):
MoveIt is currently primarily a kinematic motion planning framework - it plans for joint or end effector positions but not velocity or acceleration. However, MoveIt does utilize post-processing to time parameterize kinematic trajectories for velocity and acceleration values.
and:
MoveIt can support different algorithms for post-processing a kinematic trajectory to add timestamps and velocity/acceleration values. Currently there are three available by default in MoveIt:
Summarising: OMPL output is a path. Post-processing via the time-parameterisation algorithms turns that into a trajectory (ie: adds time, velocity and acceleration to each trajectory point).
None of those algorithms use any information other than the limits configured on each joint (which are taken from your .urdf or .xacro (in combination with and via the config/joint_limits.yaml file in your MoveIt configuration package)).
The assumption is that you've provided appropriate joint limits to those algorithms, and that the entity responsible for execution of the trajectory is capable of achieving the performance "promised" by those limits.
So to answer the question which forms the title of this post:
In what way does MoveIt! process time info?
If by "time info" you mean the time_from_start field in each of the JointTrajectoryPoints in a JointTrajectory, then the answer would be: it doesn't.
MoveIt produces JointTrajectory. s. It does not consume them. It never looks at those values, as they are not meant for consumption by MoveIt, but by entities (ie: nodes, drivers, something else) which are capable of executing them (ie: making robots move).
| | 5 | No.5 Revision |
In the question, it was stated that OMPL, which I use, does not factor in time.
Which is correct: by default, OMPL will not consider time. It's purely kinematic planning.
However, I later found out that the trajectory planning does in fact use time, as this is processed in the JointTrajectoryPoint message.
Depending on how you define it, there is no trajectory planning in MoveIt (personally I consider planning to be more involved than interpolation or time-parameterisation, but this will depend on who you ask).
Now my question is, what is done with this time info
"inside MoveIt"? Nothing.
By consumers of the JointTrajectory message? They should use it to determine at which times in the execution of the trajectory the state encoded by each JointTrajectoryPoint should be achieved.
how is it used in trajectory planning?
It isn't.
Can the PID gains have any influence on this and vice versa?
No. Not on the algorithms which actually calculate those timestamp, velocities and accelerations.
I would again refer you to the Time Parameterization in MoveIt's documentation.
To make this more than a "link only" answer, I'll quote the relevant parts here (emphasis mine):
MoveIt is currently primarily a kinematic motion planning framework - it plans for joint or end effector positions but not velocity or acceleration. However, MoveIt does utilize post-processing to time parameterize kinematic trajectories for velocity and acceleration values.
and:
MoveIt can support different algorithms for post-processing a kinematic trajectory to add timestamps and velocity/acceleration values. Currently there are three available by default in MoveIt:
Summarising: OMPL output is a path. Post-processing via the time-parameterisation algorithms turns that into a trajectory (ie: adds time, velocity and acceleration to each trajectory point).
None of those algorithms use any information other than the limits configured on each joint (which are taken from your .urdf or .xacro (in combination with and via the config/joint_limits.yaml file in your MoveIt configuration package)).package)) together with the scaling values for those limits (ie: the velocity scaling and the acceleration scaling values).
The assumption is that you've provided appropriate joint limits to those algorithms, and that the entity responsible for execution of the trajectory is capable of achieving the performance "promised" by those limits.
So to answer the question which forms the title of this post:
In what way does MoveIt! process time info?
If by "time info" you mean the time_from_start field in each of the JointTrajectoryPoints in a JointTrajectory, then the answer would be: it doesn't.
MoveIt produces JointTrajectorys. It does not consume them. It never looks at those values, as they are not meant for consumption by MoveIt, but by entities (ie: nodes, drivers, something else) which are capable of executing them (ie: making robots move).
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.
