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

What you're trying to do can't work (at least not with current HEAD of ur_modern_driver): the driver checks a few constraints upon receiving a new goal and one of them is whether the first trajectory point in the trajectory is sufficiently close to the 'current pose' of the robot (here).

A possible way to solve this is by specifying the time_from_start as non-zero value.

As ThomasTimm/ur_modern_driver#36 explains, this check does not depend on time, but on the joint angles of the robot at the time the goal is received.

I'm not sure how setting the time_from_start to some value will influence this.

What you're trying to do can't work (at least not with current HEAD of ur_modern_driver): the driver checks a few constraints upon receiving a new goal and one of them is whether the first trajectory point in the trajectory is sufficiently close to the 'current pose' of the robot (here).

A possible way to solve this is by specifying the time_from_start as non-zero value.

As ThomasTimm/ur_modern_driver#36 explains, this check does not depend on time, but on the joint angles of the robot at the time the goal is received.

I'm not sure how setting the time_from_start to some value will influence this.


Edit: trajectory replacement (which is sort of the 'official' name for what you are trying to do) is supported by the joint_trajectory_controller of ros_control. ur_modern_driver has support for ros_control (and that side of the driver does not include the 'start state check'), however that comes with its own set of constraints and requirements.

You could look into that, but please carefully review the open issues.

What you're trying to do can't work (at least not with current HEAD of ur_modern_driver): the driver checks a few constraints upon receiving a new goal and one of them is whether the first trajectory point in the trajectory is sufficiently close to the 'current pose' of the robot (here).

A possible way to solve this is by specifying the time_from_start as non-zero value.

As ThomasTimm/ur_modern_driver#36 explains, this check does not depend on time, but on the joint angles of the robot at the time the goal is received.

I'm not sure how setting the time_from_start to some value will influence this.


Edit: trajectory replacement (which is sort of the 'official' name for what you are trying to do) is supported by the joint_trajectory_controller of ros_control. ur_modern_driver has support for ros_control (and that side of the driver does not include the 'start state check'), however that comes with its own set of constraints and requirements.

You could look into that, but please carefully review the open issues.


Edit2: you may also want to take a look at ThomasTimm/ur_modern_driver#120, which is a candidate upgrade of ur_modern_driver, and Zagitta/ur_modern_driver#9, which is an upgrade / extension of that.

Zagitta/ur_modern_driver#9 does not influence ros_control performance / compatibility at all.