picknik_reset_fault_controller appears to use hardware_interface directly without declaring it in package.xml

[Plumezz]

Summary

While reviewing ROS 2 package dependency metadata, I noticed that picknik_reset_fault_controller appears to use hardware_interface directly, but hardware_interface does not seem to be declared in picknik_reset_fault_controller/package.xml in humble branch.

This may make the package rely on controller_interface or another intermediate package to provide hardware_interface transitively.

Evidence

Direct usage

picknik_reset_fault_controller directly includes hardware_interface in C++ source or public headers:

• src/picknik_reset_fault_controller.cpp:26: #include "hardware_interface/loaned_command_interface.hpp"

The package uses dependency-owned types or APIs from those headers:

• src/picknik_reset_fault_controller.cpp:30: using hardware_interface::LoanedCommandInterface;

Current package.xml

I could not find a direct declaration of hardware_interface in picknik_reset_fault_controller/package.xml.

The package currently declares the following intermediate dependency/dependencies, which make hardware_interface reachable transitively:

<depend>controller_interface</depend>

Observed during build/test

Build/test file-access tracing observed some events associated with hardware_interface during build. Representative accessed paths include:

• hardware_interface/share/ament_index/resource_index/package_run_dependencies/hardware_interface
• hardware_interface/share/hardware_interface/cmake/hardware_interfaceConfig-version.cmake
• hardware_interface/share/hardware_interface/cmake/hardware_interfaceConfig.cmake
• hardware_interface/share/hardware_interface/cmake/ament_cmake_export_targets-extras.cmake

Transitive path

picknik_reset_fault_controller -> controller_interface -> hardware_interface

Suggested fix

If this direct usage is intentional, would it make sense to add:

<depend>hardware_interface</depend>

to picknik_reset_fault_controller/package.xml? The corresponding find_package(hardware_interface REQUIRED) and CMake target dependency should also be added for the target(s) that compile these files, where required by the package's CMake structure.

Notes

This issue does not claim that the package currently fails to build. The concern is that the package directly uses hardware_interface while relying on a transitive dependency path to make it available. The observation is based on package metadata, concrete source-level use, recursive dependency closure analysis, and build/test file-access tracing.

Could you please confirm whether this dependency is intentionally left implicit through the transitive dependency path shown above, or whether adding an explicit dependency would be appropriate?

I would be happy to open a small PR adding the dependency if that matches the intended package metadata.