Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add logger and clock interfaces from ResourceManager to HardwareComponent interfaces #1585

Open
wants to merge 18 commits into
base: master
Choose a base branch
from

Conversation

saikishor
Copy link
Member

@saikishor saikishor commented Jun 24, 2024

As discussed in the WG meeting on 19th June 2024, I've added the logging and the clock interfaces to ResourceManager and HardwareComponents. I've also modified all the RCUTILS logging to RCLCPP logging.

[INFO] [1719246718.869627728] [resource_manager]: Loading hardware 'MockHardwareSystem' 
[INFO] [1719246718.869987243] [resource_manager]: Loaded hardware 'MockHardwareSystem' from plugin 'mock_components/GenericSystem'
[INFO] [1719246718.870008000] [resource_manager]: Initialize hardware 'MockHardwareSystem' 
[WARN] [1719246718.870122036] [resource_manager.hardware_component.system.MockHardwareSystem]: Custom interface with following offset 'actual_position' does not exist. Offset will not be applied
[INFO] [1719246718.870130775] [resource_manager]: Successful initialization of hardware 'MockHardwareSystem'
[INFO] [1719246718.870288251] [resource_manager]: 'configure' hardware 'MockHardwareSystem' 

Thank you

Copy link

codecov bot commented Jun 24, 2024

Codecov Report

Attention: Patch coverage is 51.88679% with 51 lines in your changes missing coverage. Please review.

Project coverage is 87.75%. Comparing base (86dd7d2) to head (812d103).

Current head 812d103 differs from pull request most recent head 5bc3c93

Please upload reports for the commit 5bc3c93 to get more accurate results.

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #1585      +/-   ##
==========================================
- Coverage   87.79%   87.75%   -0.04%     
==========================================
  Files         102      102              
  Lines        8764     8797      +33     
  Branches      787      789       +2     
==========================================
+ Hits         7694     7720      +26     
- Misses        792      798       +6     
- Partials      278      279       +1     
Flag Coverage Δ
unittests 87.75% <51.88%> (-0.04%) ⬇️

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

Files Coverage Δ
..._interface/include/hardware_interface/actuator.hpp 100.00% <ø> (ø)
.../include/hardware_interface/actuator_interface.hpp 100.00% <100.00%> (ø)
...re_interface/include/hardware_interface/sensor.hpp 66.66% <ø> (ø)
...ce/include/hardware_interface/sensor_interface.hpp 100.00% <100.00%> (ø)
...re_interface/include/hardware_interface/system.hpp 100.00% <ø> (ø)
...ce/include/hardware_interface/system_interface.hpp 100.00% <100.00%> (ø)
hardware_interface/src/actuator.cpp 75.00% <100.00%> (ø)
hardware_interface/src/sensor.cpp 70.40% <100.00%> (ø)
hardware_interface/src/system.cpp 75.00% <100.00%> (ø)
...dware_interface/test/test_component_interfaces.cpp 96.16% <100.00%> (+0.12%) ⬆️
... and 3 more

Copy link
Contributor

@christophfroehlich christophfroehlich left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

How can we promote this new feature? Please add something to the release notes, maybe also hardware components docs. Possibly we can use this in the demos as well?

@saikishor
Copy link
Member Author

How can we promote this new feature? Please add something to the release notes, maybe also hardware components docs. Possibly we can use this in the demos as well?

Yes, we can use them in the demos as well. I've used it inside the MockHardwareSystem in this PR.

Copy link
Contributor

mergify bot commented Jun 25, 2024

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

Copy link
Contributor

@christophfroehlich christophfroehlich left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

Comment on lines 243 to 253
rclcpp::Clock get_clock() const
{
if (clock_interface_)
{
return *(clock_interface_->get_clock());
}
else
{
return rclcpp::Clock(RCL_ROS_TIME);
}
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

isn't this misleading? If we have no clock we shouldn't return any...

Suggested change
rclcpp::Clock get_clock() const
{
if (clock_interface_)
{
return *(clock_interface_->get_clock());
}
else
{
return rclcpp::Clock(RCL_ROS_TIME);
}
}
std::optional<rclcpp::Clock> get_clock() const
{
return clock_interface_ ? std::optional<rclcpp::Clock>{*(clock_interface_->get_clock())} : std::nullopt;
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Better yet, just use the existing sharedptr

Suggested change
rclcpp::Clock get_clock() const
{
if (clock_interface_)
{
return *(clock_interface_->get_clock());
}
else
{
return rclcpp::Clock(RCL_ROS_TIME);
}
}
rclcpp::node_interfaces::NodeClockInterface::SharedPtr get_clock() const
{
return clock_interface_;
}

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, maybe shared_ptr is better and makes sense.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or maybe even better yet... can we validate the clock interface sharedptr we are getting and turn it into a clock? Is that dangerous?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

*(clock_interface_->get_clock()); That's what I'm doing here right?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes but what I mean is we should do this at the top and not even accept invalid clocks

Copy link
Member Author

@saikishor saikishor Jun 27, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bmagyar Yes, I just pushed the changes!

With the new changes, we will need to push a fix to ros2_controllers as well inorder to fix some load tests. For instance this one

https://github.com/ros-controls/ros2_controllers/blob/b81be48fb1b6101a3c601c0ea11c5393e5a7026e/imu_sensor_broadcaster/test/test_load_imu_sensor_broadcaster.cpp#L34-L37

Before:

  controller_manager::ControllerManager cm(
    std::make_unique<hardware_interface::ResourceManager>(
      ros2_control_test_assets::minimal_robot_urdf),
    executor, "test_controller_manager");

Now:

controller_manager::ControllerManager cm(
    executor, ros2_control_test_assets::minimal_robot_urdf, "test_controller_manager");

Take a look at the changes and let me know if they look fine to you. If yes, I will open a PR for the controllers as well.

While making these modifications, I was under the dilemma to still have the NodeClockInterface and NodeLoggingInterface or just replace them with the rclcpp::Clock::SharedPtr and rclcpp::Logger so, it is easy on the tests, but just in case, I left the same.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here is the PR of ros2_controllers: ros-controls/ros2_controllers#1184

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants