[JTC] Add time-out for trajectory interfaces#609
[JTC] Add time-out for trajectory interfaces#609bmagyar merged 19 commits intoros-controls:masterfrom
Conversation
|
Just wondering now, should the timeout be counted from the reception of the message, or from the time of the end of the trajectory (i.e., |
|
Good question... It's intuitive to do it from receiving the message but since this particular message has explicit timing in it I think we should only allow timeouts defined relative to the trajectory |
|
We should define it from the end for the trajectory (time of the last point) |
|
This pull request is in conflict. Could you fix it @christophfroehlich? |
|
@christophfroehlich this PR shouldn't really target the jtc-features branch no? |
It is somehow independent, but why not? |
|
This pull request is in conflict. Could you fix it @christophfroehlich? |
eac9765 to
881d01e
Compare
joint_trajectory_controller/src/joint_trajectory_controller_parameters.yaml
Show resolved
Hide resolved
|
This pull request is in conflict. Could you fix it @christophfroehlich? |
|
Putting this on hold. It's not essential for the things on the |
|
CI fails because of flaky JTC tests, not related to this PR |
7bc5a35 to
e1ba1c2
Compare
|
This pull request is in conflict. Could you fix it @christophfroehlich? |
bmagyar
left a comment
There was a problem hiding this comment.
Thank you, I'll apply the comments to fix the test compilation (due to the updated test API)
| traj_msg_external_point_ptr_.reset(); | ||
| traj_msg_external_point_ptr_.initRT(set_hold_position()); |
There was a problem hiding this comment.
do we always have to call both? I'd imagine re-setting the value resets things properly
There was a problem hiding this comment.
this is a consequence of #168, I didn't know how to perform this because there is no set-method. But probably the reset() is not necessary before.
This adds an optional time-out parameter for the trajectory interfaces (topic or action).
If using velocity as command interface, and the last velocity point is not zero -> the robot would move forever without stopping if no new trajectory is received.