[JTC] Use time of the last command for set_point_before_trajectory_msg in open-loop mode

[destogl]

This PR tackles the issues that happen in open-loop mode where on replacing trajectories the last command is repeated.
The figures below show the results of the output trajectories before and after this functionality. The trajectory that uses the time of the last command as point before trajectory messages gets smoother output.

Functionality right now:

Functionality with this PR:

P.S. The similar thing would be useful for trajectory replacement in closed loop mode, but then we would need to know exactly when the state is read from the hardware. This is just something to think about in the future.

P.P.S. I will add tests too.

[codecov]

Codecov Report

Attention: Patch coverage is 90.90909% with 1 line in your changes missing coverage. Please review.

Project coverage is 84.64%. Comparing base (623dc5d) to head (d2ca6aa).
Report is 2 commits behind head on master.

Files with missing lines	Patch %	Lines
...ory_controller/src/joint_trajectory_controller.cpp	80.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #780      +/-   ##
==========================================
- Coverage   84.66%   84.64%   -0.02%     
==========================================
  Files         123      123              
  Lines       11419    11425       +6     
  Branches      961      964       +3     
==========================================
+ Hits         9668     9671       +3     
  Misses       1449     1449              
- Partials      302      305       +3     

Flag	Coverage Δ
unittests	84.64% <90.90%> (-0.02%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
...jectory_controller/joint_trajectory_controller.hpp	100.00% <ø> (ø)
...ory_controller/test/test_trajectory_controller.cpp	99.74% <100.00%> (ø)
...ory_controller/src/joint_trajectory_controller.cpp	85.13% <80.00%> (-0.06%)	⬇️

... and 4 files with indirect coverage changes

[christophfroehlich]

Looks good for me (even more if the mentioned tests are added)
concerning closed-loop mode: I'm not sure if this is necessary, shouldn't the trajectory generator be aware of the current state? But I guess there might be configurations where this could improve something.

[destogl]

concerning closed-loop mode: I'm not sure if this is necessary, shouldn't the trajectory generator be aware of the current state? But I guess there might be configurations where this could improve something.

This is important only when trajectory replacement is done. My comment was along: "if strange behavior happens when replacing trajectories - it might be that the state of is too

[christophfroehlich]

I'm asking myself if it is desirable at all to interpolate from measured state instead of the last command with closed-loop config. but that really depends on the algorithm generating the trajectory

[mergify]

This pull request is in conflict. Could you fix it @destogl?

[christophfroehlich]

test_no_jump_when_state_tracking_error_not_updated fails

[mergify]

This pull request is in conflict. Could you fix it @destogl?

[christophfroehlich]

LGTM, I fixed the test now.

[Thieso]

Looks good to me, just need to change open-loop to be interpolate_from_desired_state according to #1525 but I do not have the permissions for this

[christophfroehlich]

for this PR it is fine with open-loop, if you approve we can merge that immediately. we then can change that in your PR, where we have to wait for a review of another maintainer anyways