[joint_trajectory_controller] Purpose of some warning statements

[adolfo-rt]

I'm observing the following log output while using the joint_trajectory_controller:

[ WARN] [1385987384.325046066]: Dropping all 1 trajectory points, as they occur before the specified time of 1385987384.327102
[ WARN] [1385987384.325116861]: Last trajectory point: 0.060309278

The fact that the statements are logged is expected, no problem there. What I don't understand well is the purpose of the last statement, i.e., what can I make of it?. From the implementation, I can see that the 0.0603... value is the time_from_start of the last point in a command trajectory, but this is not evident from the log statement. Also, the two WARN messages are printing data that can't be related together: The first one is a time (absolute), while the second is a duration (relative).

What was the original intent when the Last trajectory point: statement was added?.

@davetcoleman

[davetcoleman]

I do not recall - did I add this? I remember having lots of issues with
sending trajectory actions to the trajectory controller from MoveIt that
kept being flagged as expired, though they should not have been, so I might
have added this then. If no one else knows its purpose I'd say remove it.

On Monday, December 2, 2013, Adolfo Rodriguez Tsouroukdissian wrote:

I'm observing the following log output while using the
joint_trajectory_controller:

[ WARN] [1385987384.325046066]: Dropping all 1 trajectory points, as they occur before the specified time of 1385987384.327102
[ WARN] [1385987384.325116861]: Last trajectory point: 0.060309278

The fact that the statements are logged is expected, no problem there.
What I don't understand well is the purpose of the last statement, i.e.,
what can I make of it?. From the implementationhttps://github.com/ros-controls/ros_controllers/blob/hydro-devel/joint_trajectory_controller/include/joint_trajectory_controller/init_joint_trajectory.h#L272,
I can see that the 0.0603... value is the time_from_start of the last
point in a command trajectory, but this is not evident from the log
statement. Also, the two WARN messages are printing data that can't be
related together: The first one is a time (absolute), while the second is a
duration (relative).

What was the original intent when the Last trajectory point: statement
was added?.

@davetcoleman https://github.com/davetcoleman

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/68
.

:: dave | 251.463.2345 c

[adolfo-rt]

git blame said I should talk to you ;-). If it's not something that's currently adding value, I'd either remove it, or at least present the data in a form that can be used more usefully.

[adolfo-rt]

Please check commit f4cf52e of the associated pull request. The log statements now read like this:

[ WARN] [1.0]: Dropping first 2 trajectory point(s) out of 3, as they occur before the current time.
First valid point will be reached in 1.000s.

[ WARN] [2.0]: Dropping all 3 trajectory point(s), as they occur before the current time.
Last point is 1.000s in the past.

[adolfo-rt]

Changes pushed.

[andreaskoepf]

@adolfo-rt I have a safety related question regarding the warning
Dropping first 1 trajectory point(s) out of N... which I get for every single trajectory generated by MoveIt!. I observed some very dangerous movements of our UR5 robot over the last few days. We are using the joint_trajectory_controller in position mode in combination with the ur_modern_driver. While at the root of the problem probably MoveIt! is generating paths with wrong start states (far away from the current robot state - e.g. moveit/moveit_ros#442) I was wondering why the path deviation protection of the joint_trajectory_controller does not kick in. Could it be that by dropping the first trajectory point the current robot state indirectly becomes the first trajectory point and the interpolated path between the current robot state and 'the first valid state' is internally considered a valid path - even though it could mean that extreme movements are made through regions of joint-space that were never considered by the original trajectory? Would it not make sense to add a sanity check to compare the first trajectory point and the current robot state - e.g. enforcing similar path-tolerance values as during normal trajectory execution? What I definitely can say so far is that the paths generated by MoveIt! which trigger the unexpected high-speed motion of the robot itself have limited acceleration and velocity values (even if I check them myself by inspecting state-to-state distances and divide by the path segment-time).
I know it is always the questions which part of the system finally is responsible for detection of invalid robot motion, e.g. finally a limitation of the robot hardward capabilities itself is probably the most effective protection against injuries with co-bots. But to some extend I would argue that every level of the stack, e.g. path-planner, controller & robot-driver should have some command validation/sanity-checking built-in (e.g. as it is already currently the case with the path-tolerance checks).

If you look at the joint_trajactory_controller implementation inside the ur_modern_driver you see that they added an explicit check whether the current robot pose matches the trajectory start state, see ur_ros_wrapper.cpp#L330-L336.