[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 50.64935% with 38 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.40%. Comparing base (38124b7) to head (8e3fe4e).

Files with missing lines	Patch %	Lines
...re_interface/include/hardware_interface/handle.hpp	37.14%	19 Missing and 3 partials ⚠️
...ardware_interface/hardware_component_interface.hpp	61.90%	10 Missing and 6 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2831      +/-   ##
==========================================
- Coverage   89.55%   89.40%   -0.16%     
==========================================
  Files         152      152              
  Lines       18087    18126      +39     
  Branches     1470     1474       +4     
==========================================
+ Hits        16198    16205       +7     
- Misses       1301     1329      +28     
- Partials      588      592       +4     

Flag	Coverage Δ
unittests	89.40% <50.64%> (-0.16%)	⬇️

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

Files with missing lines	Coverage Δ
...ardware_interface/hardware_component_interface.hpp	75.00% <61.90%> (-2.86%)	⬇️
...re_interface/include/hardware_interface/handle.hpp	75.88% <37.14%> (-10.79%)	⬇️

🚀 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..

[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.

[mamueluth]

Why do we expose this method in the interface? I would make it protected. The Handle should be a thread save entity in my point of view and locking/unlocking should be handled internally. I think exposing of bool get_value(T & value) const should be enough or am i missing something?

And am i mistaken or is the function actually thradunsafe because if you create mutex_2 lock it with some std::shared_lock<std::shared_mutex> lock2(handle_mutex_, std::try_to_lock); and pass it i would break thread safety or not?

[saikishor]

Why not, this is useful to avoid the copies and then you want to do it in a thread safe approach right?. Moreover, it has similar schema as set_value method

And am i mistaken or is the function actually thradunsafe because if you create mutex_2 lock it with some std::shared_lockstd::shared_mutex lock2(handle_mutex_, std::try_to_lock); and pass it i would break thread safety or not?

If you do that and if it doesn't own the lock, it would enter the condition !lock.owns_lock() immediately and then returns

[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

[mamueluth]

Why do we expose this method in the interface? I would make it protected. The Handle should be a thread save entity in my point of view and locking/unlocking should be handled internally. I think exposing of bool get_value(T & value) const should be enough or am i missing something?

And am i mistaken or is the function actually thradunsafe because if you create mutex_2 lock it with some std::shared_lock<std::shared_mutex> lock2(handle_mutex_, std::try_to_lock); and pass it i would break thread safety or not?

[mamueluth]

i think id rather move this to the handle. have a blocking and a non blocking method where the blocking grantees to set the value and the non blocking is the current.

Then in the user code we can just directly call the Shared pointer instance and call either the blocking or non blocking method

[mamueluth]

i know it is written in the comment but i think ensure_set masks a bit the fact that we now have a different api.

I would maybe just distinguish on api level

[saikishor]

creating different API is sometimes confusing for beginners, better to have one API and add proper documentation for the users to understand. With VSCode, you can understand the args while coding from the docs

[mamueluth]

For get_state basically the same reasoning applies as for set_state

[saikishor]

I modified a bit