Cleanup all the deprecations warning from the recent ros2_control variant changes

[saikishor]

Recently after the new variants feature in Handles (#1688) We have a bunch of deprecation warnings that needs to be cleanup. This could be a nice first issue.

[MartinPeris]

I'd like to take this one. Quick couple of questions. For example in this situation:

/root/ws_ros2_control/src/ros2_control/hardware_interface/include/hardware_interface/system_interface.hpp: In member function ‘double hardware_interface::SystemInterface::get_state(const std::string&) const’:
/root/ws_ros2_control/src/ros2_control/hardware_interface/include/hardware_interface/system_interface.hpp:410:56: warning: ‘double hardware_interface::Handle::get_value() const’ is deprecated: Use bool get_value(double & value) instead to retrieve the value. [-Wdeprecated-declarations]
  410 |     return system_states_.at(interface_name)->get_value();
      |            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~

The original code is:

double get_state(const std::string & interface_name) const
  {
    return system_states_.at(interface_name)->get_value();
  }

Since the new API signature is bool get_value(double &value), how do you want me to handle the bool returned by get_value?

Ignoring it would not be an option for me, so this leaves 3 possibilities:

1. Throw an Exception
2. Return a Sentinel Value (e.g., NaN)
3. Log an Error and Return Default Value

Either 1 or 2 would be acceptable for me (leaning towards 2, but that is just personal preference). In any case, new unit tests will have to be added... I charge extra karma for that :P

Also, I see a lot of -Wunused-result:

In file included from /root/ws_ros2_control/src/ros2_control/hardware_interface/include/mock_components/generic_system.hpp:25,
                 from /root/ws_ros2_control/src/ros2_control/hardware_interface/src/mock_components/generic_system.cpp:17:
/root/ws_ros2_control/src/ros2_control/hardware_interface/include/hardware_interface/system_interface.hpp: In member function ‘void hardware_interface::SystemInterface::set_state(const std::string&, const double&)’:
/root/ws_ros2_control/src/ros2_control/hardware_interface/include/hardware_interface/system_interface.hpp:405:49: warning: ignoring return value of ‘bool hardware_interface::Handle::set_value(double)’, declared with attribute ‘nodiscard’ [-Wunused-result]
  405 |     system_states_.at(interface_name)->set_value(value);
      |     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~

Should I deal with those too?

Is it OK to remove the deprecated API as I refactor? or should I leave them for backwards compatibility?

[MartinPeris]

mmmm looking at the documentation source code looks like a quiet NaN is the way to go:

[[deprecated("Use bool get_value(double & value) instead to retrieve the value.")]]
  double get_value() const
  {
    std::shared_lock<std::shared_mutex> lock(handle_mutex_, std::try_to_lock);
    if (!lock.owns_lock())
    {
      return std::numeric_limits<double>::quiet_NaN();
    }
    // BEGIN (Handle export change): for backward compatibility
    // TODO(Manuel) return value_ if old functionality is removed
    THROW_ON_NULLPTR(value_ptr_);
    return *value_ptr_;
    // END
  }

[saikishor]

Hello @MartinPeris!

First of all, I want to apologize for not getting back to your earlier.

For your question! I think we should also deprecate them that have void and instead they have to return bool the one from the handles. and so, we will have it similar to the Handles. Something like the following:

ros2_control/hardware_interface/include/hardware_interface/handle.hpp

Lines 175 to 188 in 038a05f

	[[nodiscard]] bool set_value(double value)
	{
	std::unique_lock<std::shared_mutex> lock(handle_mutex_, std::try_to_lock);
	if (!lock.owns_lock())
	{
	return false;
	}
	// BEGIN (Handle export change): for backward compatibility
	// TODO(Manuel) set value_ directly if old functionality is removed
	THROW_ON_NULLPTR(this->value_ptr_);
	*this->value_ptr_ = value;
	return true;
	// END
	}

So, the user will be able to know if what he gets is valid or not.

You can add the gcc ignore deprecated warnings to the deprecated methods, so we don't see them any more.

What do you think of this approach? @MartinPeris @ros-controls/ros2-maintainers

[AdityaPawar162]

Hi, I’m trying to work on this issue and replicate it. However, when I build ros2_control from source using colcon build on Humble, I don't see any warnings appearing. @saikishor could you please help me with this?

[saikishor]

Hello @AdityaPawar162!

Most of them are already fixed in #2061 and #2092. We have some warnings in transmissions that we are going to address in #1845.

Sorry, it was not referenced here. I had to make the fixes to see how the API looks

[AdityaPawar162]

Thanks for the update @saikishor! I see that the warnings in transmissions are being addressed in #1845. Is there any other good first issue available that I can work on?

[saikishor]

Hello @AdityaPawar162

Maybe for now, try to get something from the ros2_control_demos repository. We have a couple over there. In the meantime, If we find something else, we will open an issue with the tag again.

[github-actions]

This issue is being labeled as stale because it has been open 45 days with no activity. It will be automatically closed after another 45 days without follow-ups.

[github-actions]

This issue was closed because it has been stalled for 45 days with no activity.

[christophfroehlich]

@saikishor is this done?

[saikishor]

@saikishor is this done?

@christophfroehlich it is not done.