[HardwareComponentInterface] Add get state and command interface handle methods

[saikishor]

This PR adds a few new methods that could be really helpful if we want to catch the information of the exported interfaces to improve the performance of the setting and getting of handles

[codecov]

Codecov Report

❌ Patch coverage is 46.42857% with 45 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.33%. Comparing base (fd12e90) to head (85d03d5).

Files with missing lines	Patch %	Lines
...ardware_interface/hardware_component_interface.hpp	55.17%	14 Missing and 12 partials ⚠️
...re_interface/include/hardware_interface/handle.hpp	26.92%	18 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2831      +/-   ##
==========================================
- Coverage   89.51%   89.33%   -0.18%     
==========================================
  Files         152      152              
  Lines       18020    18065      +45     
  Branches     1468     1476       +8     
==========================================
+ Hits        16130    16139       +9     
- Misses       1304     1330      +26     
- Partials      586      596      +10     

Flag	Coverage Δ
unittests	89.33% <46.42%> (-0.18%)	⬇️

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	77.01% <26.92%> (-8.91%)	⬇️
...ardware_interface/hardware_component_interface.hpp	73.00% <55.17%> (-5.02%)	⬇️

... and 2 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[christophfroehlich]

You suggest storing the interface handles once inside the hardware components, instead of having to lookup the maps at every set/get call?

[saikishor]

You suggest storing the interface handles once inside the hardware components, instead of having to lookup the maps at every set/get call?

Yes, this way the users will be able to cache the command interfaces and will be able to implement the logic they want. I think this way we have less execution time, so you might not need to do a lookup everytime.

[saikishor]

However, I'm rethinking some part of API right now. I'll update with more API

[christophfroehlich]

The API seems to be very useful from the user perspective, but I'm not sure about the compiler optimization I commented below..

[christophfroehlich]

Why not leaving also T get_state(const StateInterface::SharedPtr & interface_handle) and use this here instead? I don't know how the compiler will be able to optimize that, so please ignore if this is not relevant.

[saikishor]

I don't think it is significant for most simple datatypes we support

[christophfroehlich]

shall we ask the @copilot ? :D

[saikishor]

Sure

[christophfroehlich]

I had a private chat with it ;)

but the difference in runtime is mostly theoretical

[saikishor]

Lol! So you are convinced?

[mhubii]

Thanks @saikishor! This should address #2816

[Copilot]

Pull Request Overview

This PR enhances the HardwareComponentInterface by adding methods to retrieve state and command interface handles, along with overloaded getter/setter methods that accept handles directly. These additions enable caching of interface handles to improve performance by avoiding repeated map lookups during interface access operations.

Key Changes:

• Added get_state_interface_handle() and get_command_interface_handle() methods to retrieve interface handles by name
• Introduced overloaded get_state(), set_state(), get_command(), and set_command() methods that accept interface handles directly
• Added get_value() methods in the Handle class that use output parameters instead of return values for better performance with large data types

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
hardware_interface/include/hardware_interface/hardware_component_interface.hpp	Added handle retrieval methods and handle-based getter/setter overloads with ensure_get/ensure_set parameters for state and command interfaces
hardware_interface/include/hardware_interface/handle.hpp	Added get_value() methods with output parameters to support thread-safe value retrieval without copying return values

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The documentation states the method is 'non-blocking', but the method uses std::shared_lock which can block if a writer holds the mutex. Consider clarifying this as 'non-blocking only if the lock is successfully acquired' or removing the non-blocking claim.

Suggested change

	* @note The method is thread-safe and non-blocking.
	* @note The method is thread-safe and non-blocking only if the lock is already acquired.
	* Acquiring the lock itself may block if a writer holds the mutex.

[Copilot]

The documentation incorrectly states the method is 'non-blocking'. The method uses std::try_to_lock which makes it non-blocking in terms of lock acquisition, but it returns false if the lock cannot be acquired rather than guaranteeing non-blocking behavior. The documentation should clarify that the method attempts to acquire the lock without blocking and returns false if unsuccessful.

[saikishor]

Come onnnnn copilot 😅😅

[christophfroehlich]

it has a point in being more specific what "retrieved successfully" means?

[saikishor]

I don't think so. Atleast, I wrote it as per my understanding