[HW_IF] Prepare the handles for async operations

[saikishor]

As with #1688 and #1689 there are not many changes in the handles.hpp file. I think this is the right moment to do it, to have straight away working handles in async. The proposed changes would work with zero overhead in synchronous operations.

Looking forward for your feedback!

[codecov]

Codecov Report

Attention: Patch coverage is 59.55056% with 36 lines in your changes missing coverage. Please review.

Project coverage is 87.41%. Comparing base (b0da4a1) to head (0e3416e).
Report is 10 commits behind head on master.

Files with missing lines	Patch %	Lines
...de/hardware_interface/loaned_command_interface.hpp	37.93%	15 Missing and 3 partials ⚠️
...lude/hardware_interface/loaned_state_interface.hpp	41.17%	8 Missing and 2 partials ⚠️
...re_interface/include/hardware_interface/handle.hpp	81.39%	4 Missing and 4 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1750      +/-   ##
==========================================
- Coverage   87.60%   87.41%   -0.19%     
==========================================
  Files         120      120              
  Lines       12223    12304      +81     
  Branches     1093     1105      +12     
==========================================
+ Hits        10708    10756      +48     
- Misses       1125     1150      +25     
- Partials      390      398       +8     

Flag	Coverage Δ
unittests	87.41% <59.55%> (-0.19%)	⬇️

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

Files with missing lines	Coverage Δ
...re_interface/include/hardware_interface/handle.hpp	88.73% <81.39%> (-11.27%)	⬇️
...lude/hardware_interface/loaned_state_interface.hpp	57.57% <41.17%> (-18.90%)	⬇️
...de/hardware_interface/loaned_command_interface.hpp	51.35% <37.93%> (-48.65%)	⬇️

... and 1 file with indirect coverage changes

[saikishor]

I've just gone through the coverage report, the missing coverage lines should already be handled in the testing of #1489 and #1567

[mergify]

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

[destogl]

@mamueluth please check this. This is how we can template the access to variables. This should simplify test changes.

[destogl]

Thanks! It looks great!

[destogl]

Should we put this to "DEBUG" mode?

Or do we always want output when switching controllers?

[saikishor]

This is only when we deactivate the controller, i think it's good to have this statistical information.

Moreover, as it is conditioned it should only print for async cases and that too if you have some misses. This should give us some information of the functionality of the system

[saikishor]

If we have reported issues about this, we can put this to debug in future

[christophfroehlich]

I like the statistics part, but now its rather verbose on the CI and some percentages seem to be wrong (or some counters not properly initialized?)

2024-10-25T08:59:54.1674417Z 7: [WARN] [1729846793.768585551] [joint2/velocity]: LoanedStateInterface joint2/velocity has 1379847120 (34.40 %) timeouts and  32586 (0.00 %) missed calls out of 4011084229 get_value calls
2024-10-25T08:59:54.1677303Z 7: [WARN] [1729846793.768598835] [joint2/position]: LoanedStateInterface joint2/position has 1379846688 (10614205292.31 %) timeouts and  32764 (252030.77 %) missed calls out of 13 get_value calls

I can't give proper feedback about the threading stuff, but it looks fine for me.

[christophfroehlich]

The latest commit fixes the output in the CI, so I'm happy.

[christian-rauch]

The deprecation declaration added via 59c642a breaks builds with warnings as errors (-Werror). Please do not release such changes into stable releases within the same ROS distribution (jazzy in this case). There is usually a tick-tock cycle where deprecation warnings are first enabled for one ROS LTS distribution. Then the deprecated elements are removed in the next ROS LTS distribution.

[bmagyar]

There's a lot more we added, don't worry.
As you said, we add them first, keep backward compatibility for an LTS, then remove in the next one.

Deprecations can come in at any time though, warning users what to expect in upcoming releases. Fixing them in the current LTS helps avoiding panic migration.

Long story short, you can tell why we aren't using the blanket -Werror option ;)