Revision history [back]

The shift in values between plan and observed packets seems suspicious.

this is probably due to the fact that a JointTrajectory encodes the state of the system under control at specific times, while a typical industrial robot trajectory (or really: program) specifies constraints on segments.

A segment is defined by two points: start and end. So in the JointTrajectory, start and end velocity could be 0, as in the first list of points you show. But if we translate that into segments, no velocity can be 0 any more, as that would lead the industrial robot controller to not move at all.

Without using a real-time, external motion control interface, I don't know of any industrial robot controller that allows you to specify state of the system at specific points in time. They always only let you (implicitly) define segments and attach constraints to those segments (ie: please use a maximum of 0.511 seconds to move along this segment, etc).

The shift in values between plan and observed packets seems suspicious.

this is probably due to the fact that a JointTrajectory encodes the state of the system under control at specific times, while a typical industrial robot trajectory (or really: program) specifies constraints on segments.segments (ie: between points).

A segment is defined by two points: start and end. So in the JointTrajectory, start and end velocity could be 0, as in the first list of points you show. But if we translate that into segments, no velocity can be 0 any more, as that would lead the industrial robot controller to not move at all.

Without using a real-time, external motion control interface, I don't know of any industrial robot controller that allows you to specify state of the system at specific points in time. They always only let you (implicitly) define segments and attach constraints to those segments (ie: please use a maximum of 0.511 seconds to move along this segment, etc).

The shift in values between plan and observed packets seems suspicious.

this is probably due to the fact that a JointTrajectory encodes the state of the system under control at specific times, while a typical industrial robot trajectory (or really: program) specifies constraints on segments (ie: between points).

A segment is defined by two points: start and end. So in the JointTrajectory, start and end velocity could be 0, as in the first list of points you show. But if we translate that into segments, no velocity can be 0 any more, as that would lead the industrial robot controller to not move at all.

Without using a real-time, external motion control interface, I don't know of any industrial robot controller that allows you to specify state of the system at specific points in time. They always only let you (implicitly) define segments and attach constraints to those segments (ie: please use a maximum of 0.511 seconds to move along this segment, etc).

The shift in values between plan and observed packets seems suspicious.

this is probably due to the fact that a JointTrajectory encodes the state of the system under control at specific times, while a typical industrial robot trajectory (or really: program) specifies constraints on segments (ie: between points).

A segment is defined by two points: start and end. So in the JointTrajectory, start and end velocity could be 0, as in the first list of points you show. But if we translate that into segments, no velocity can be 0 any more, as that would lead the industrial robot controller to not move at all.

Without using a real-time, external motion control interface, interface (with which you typically are able to specify the desired state of the system at any point in time (ie: specify position, velocity and/or effort setpoints)), I don't know of any industrial robot controller that allows you to specify state of the system at specific points in time. They always only let you (implicitly) define segments and attach constraints to those segments (ie: please use a maximum of 0.511 seconds to move along this segment, please execute this motion (ie: travel along this segment) with 50% of maximum joint velocity, tc).

That is a fundamentally different way of encoding robot motion and the discrepancy between the two is what I believe leads to your observations.

The shift in values between plan and observed packets seems suspicious.

this is probably due to the fact that a JointTrajectory encodes the state of the system under control at specific times, while a typical industrial robot trajectory (or really: program) specifies constraints on segments (ie: between points).

A segment is defined by two points: start and end. So in the JointTrajectory, start and end velocity could be 0, as in the first list of points you show. But if we translate that into segments, no velocity can be 0 any more, as that would lead the industrial robot controller to not move at all.

Without using a real-time, external motion control interface (with which you typically are able to specify the desired state of the system at any point in time (ie: specify position, velocity and/or effort setpoints)), I don't know of any industrial robot controller that allows you to specify state of the system at specific points in time. time.

They always only let you (implicitly) define segments and attach constraints to those segments (ie: please use a maximum of 0.511 seconds to move along this segment, please execute this motion (ie: travel along this segment) with 50% of maximum joint velocity, tc).etc). Important to realise is that those constraints (or: motion settings or modifiers) typically really only specify a desired maximum velocity or time. The industrial robot controller then uses those constraints to generate a velocity profile with the desired characteristics (ie: leads to motion that takes 0.511 seconds from start to end, or leads to a velocity profile with its maximum (ie: constant phase) velocity at 50% of maximum joint velocity, etc).

That is a fundamentally different way of encoding robot motion and the industrial_robot_client needs to translate between the two.

It is this discrepancy between the two which is what I believe leads to your observations.

The shift in values between plan and observed packets seems suspicious.

this is probably due to the fact that a JointTrajectory encodes the state of the system under control at specific times, while a typical industrial robot trajectory (or really: program) specifies constraints on segments (ie: between points).

A segment is defined by two points: start and end. So in the JointTrajectory, start and end velocity could be 0, as in the first list of points you show. But if we translate that into segments, no velocity can be 0 any more, as that would lead the industrial robot controller to not move at all.

Without using a real-time, external motion control interface (with which you typically are able to specify the desired state of the system at any point in time (ie: specify position, velocity and/or effort setpoints)), I don't know of any industrial robot controller that allows you to specify state of the system at specific points in time.

They always only let you (implicitly) define segments and attach constraints to those segments (ie: please use a maximum of 0.511 seconds to move along this segment, please execute this motion (ie: travel along this segment) with 50% of maximum joint velocity, etc). Important to realise is that those constraints (or: motion settings or modifiers) typically really only specify a desired maximum velocity or time. The industrial robot controller then uses those constraints to generate a velocity profile with the desired characteristics (ie: leads to motion that takes 0.511 seconds from start to end, or leads to a velocity profile with its maximum (ie: constant phase) velocity at 50% of maximum joint velocity, etc).etc). But you never control the state of the system (ie: the robot and its joints) directly.

That is a fundamentally different way of encoding robot motion and the industrial_robot_client needs to translate between the two.

It is this discrepancy which is what I believe causes what you observe.

The shift in values between plan and observed packets seems suspicious.

this is probably due to the fact that a JointTrajectory encodes the state of the system under control at specific times, while a typical industrial robot trajectory (or really: program) specifies constraints on segments (ie: between points).

A segment is defined by two points: start and end. So in the JointTrajectory, start and end velocity could be 0, as in the first list of points you show. But if we translate that into segments, no velocity can be 0 any more, as that would lead the industrial robot controller to not move at all.

Without using a real-time, external motion control interface (with which you typically are able to specify the desired state of the system at any point in time (ie: specify position, velocity and/or effort setpoints)), I don't know of any industrial robot controller that allows you to specify state of the system at specific points in time.

They always only let you (implicitly) define segments and attach constraints to those segments (ie: please use a maximum of 0.511 seconds to move along this segment, please execute this motion (ie: travel along this segment) with 50% of maximum joint velocity, etc). Important to realise is that those constraints (or: motion settings or modifiers) typically really only specify a desired maximum velocity or time. The industrial robot controller then uses those constraints to generate a velocity profile with the desired characteristics (ie: leads to motion that takes 0.511 seconds from start to end, or leads to a velocity profile with its maximum (ie: constant phase) velocity at 50% of maximum joint velocity, etc). But you never control the state of the system (ie: the robot and its joints) directly.

That is a fundamentally different way of encoding robot motion and the industrial_robot_client needs to translate between the two.

It is this discrepancy which is what I believe causes what you observe.