Use new handles API in ros2_controllers to fix deprecation warnings #1566

kumar-sanjeeev · 2025-03-03T19:36:10Z

This PR applies the new API changes in the handles of ros2_control in following controllers in same fashion as #1565:

…ering_controller

…ing_controller

christophfroehlich

Looks fine, thanks!

…ntroller

…llers

kumar-sanjeeev · 2025-03-05T13:43:57Z

Looks fine, thanks!

@christophfroehlich hi, one question - I have made progress on other controllers as well locally on my system. Can I push these changes into this PR as well (will update description), or should I wait for more reviews on current submitted PR ?

christophfroehlich · 2025-03-05T13:48:27Z

@saikishor ?

saikishor

The changes already look good to me. I just forgot to comment.
@kumar-sanjeeev yes, please proceed with other packages as well

…sensor_broadcaster tests

…nd_controller

…l, without failures

…ollers

…roadcaster

…_controller

…per_controller

…roller

kumar-sanjeeev · 2025-03-15T19:49:50Z

@saikishor and @christophfroehlich , one question, would you like me to complete all the controller packages first, and then you would review them of all together? Or would you prefer to first provide feedback on the commits that have already been pushed in this PR?

christophfroehlich · 2025-03-15T20:02:08Z

apply the changes to all of them please

saikishor · 2025-03-15T20:27:03Z

Yes please

…ew_api

Co-authored-by: Sai Kishor Kothakota <[email protected]>

…r/parallel_gripper_action_controller_impl.hpp Co-authored-by: Sai Kishor Kothakota <[email protected]>

Co-authored-by: Sai Kishor Kothakota <[email protected]>

Co-authored-by: Christoph Fröhlich <[email protected]>

kumar-sanjeeev

Thanks for your comments, and sorry for the late reply.

what should we do if setting a command fails? return or try to set the other commands? This is not consistent

In the current implementation, it always returns with a message. In some cases, I am setting the value to 0.0 but still returning with a message.

for filling the publisher with data: I'd suggest to resume and just leave the message field untouched (should be the old vale then if the msg struct is pre-allocated). what do you think?

Could you please explain this point with an example? I’m not able to understand the message clearly.

I have marked some conversations as resolved, but for few others, I need guidance.

christophfroehlich · 2025-06-09T21:23:23Z

for filling the publisher with data: I'd suggest to resume and just leave the message field untouched (should be the old vale then if the msg struct is pre-allocated). what do you think?

Could you please explain this point with an example? I’m not able to understand the message clearly.

For example here:

ros2_controllers/pid_controller/src/pid_controller.cpp

Line 602 in e00d4cb

    
           state_publisher_->msg_.dof_states[i].output = command_interfaces_[i].get_value();

The value is saved in state_publisher_->msg_ unless its overridden. If the get_value() fails, don't return here but just leave this message field untouched and proceed.

kumar-sanjeeev · 2025-06-10T09:24:45Z

for filling the publisher with data: I'd suggest to resume and just leave the message field untouched (should be the old vale then if the msg struct is pre-allocated). what do you think?

Could you please explain this point with an example? I’m not able to understand the message clearly.

For example here:

ros2_controllers/pid_controller/src/pid_controller.cpp

Line 602 in e00d4cb

state_publisher_->msg_.dof_states[i].output = command_interfaces_[i].get_value();

The value is saved in state_publisher_->msg_ unless its overridden. If the get_value() fails, don't return here but just leave this message field untouched and proceed.

If I understood correctly, this approach i.e., not return when get_value() fails, is only meant to be used in cases where the message structure is pre-allocated (for example, in a publisher). Am I right?

If yes, then in such cases, can I proceed with the following fix? Or should I also skip printing any warning or debug message?

      state_publisher_->msg_.dof_states[i].time_step = period.seconds();
      // Command can store the old calculated values. This should be obvious because at least one
      // another value is NaN.
      const auto command_interface_value_op = command_interfaces_[i].get_optional();

      if (!command_interface_value_op.has_value())
      {
        RCLCPP_DEBUG(
          get_node()->get_logger(), "Unable to retrieve the command interface value for %s",
          command_interfaces_[i].get_name().c_str());
          # removed return statement

      }

      state_publisher_->msg_.dof_states[i].output = command_interface_value_op.value();
    }

christophfroehlich · 2025-06-10T11:44:55Z

The value is saved in state_publisher_->msg_ unless its overridden. If the get_value() fails, don't return here but just leave this message field untouched and proceed.

If I understood correctly, this approach i.e., not return when get_value() fails, is only meant to be used in cases where the message structure is pre-allocated (for example, in a publisher). Am I right?

Exactly!

If yes, then in such cases, can I proceed with the following fix? Or should I also skip printing any warning or debug message?

      state_publisher_->msg_.dof_states[i].time_step = period.seconds();
      // Command can store the old calculated values. This should be obvious because at least one
      // another value is NaN.
      const auto command_interface_value_op = command_interfaces_[i].get_optional();

      if (!command_interface_value_op.has_value())
      {
        RCLCPP_DEBUG(
          get_node()->get_logger(), "Unable to retrieve the command interface value for %s",
          command_interfaces_[i].get_name().c_str());
          # removed return statement

      }

      state_publisher_->msg_.dof_states[i].output = command_interface_value_op.value();
    }

A debug message is fine, but I'd suggest no higher log level.

kumar-sanjeeev · 2025-06-10T12:52:37Z

The value is saved in state_publisher_->msg_ unless its overridden. If the get_value() fails, don't return here but just leave this message field untouched and proceed.

If I understood correctly, this approach i.e., not return when get_value() fails, is only meant to be used in cases where the message structure is pre-allocated (for example, in a publisher). Am I right?

Exactly!
If yes, then in such cases, can I proceed with the following fix? Or should I also skip printing any warning or debug message?
      state_publisher_->msg_.dof_states[i].time_step = period.seconds();
      // Command can store the old calculated values. This should be obvious because at least one
      // another value is NaN.
      const auto command_interface_value_op = command_interfaces_[i].get_optional();

      if (!command_interface_value_op.has_value())
      {
        RCLCPP_DEBUG(
          get_node()->get_logger(), "Unable to retrieve the command interface value for %s",
          command_interfaces_[i].get_name().c_str());
          # removed return statement

      }

      state_publisher_->msg_.dof_states[i].output = command_interface_value_op.value();
    }
A debug message is fine, but I'd suggest no higher log level.

thanks for explanation, I understood. I will make correction where it needs to be done.

kumar-sanjeeev · 2025-06-10T13:09:48Z

Thanks for your comments, and sorry for the late reply.

what should we do if setting a command fails? return or try to set the other commands? This is not consistent

In the current implementation, it always returns with a message. In some cases, I am setting the value to 0.0 but still returning with a message.

@christophfroehlich does my reply answer your question? In addition to my given answer, I have set the value to 0.0 in cases where it had already been done, before I made the modification for the deprecation fix.

christophfroehlich · 2025-06-10T13:12:23Z

In the current implementation, it always returns with a message. In some cases, I am setting the value to 0.0 but still returning with a message.

@christophfroehlich does my reply answer your question? In addition to my given answer, I have set the value to 0.0 in cases where it had already been done, before I made the modification for the deprecation fix.

In these cases, it makes sense

saikishor · 2025-06-10T13:30:25Z

Hello @kumar-sanjeeev

In the current implementation, it always returns with a message. In some cases, I am setting the value to 0.0 but still returning with a message.

In what cases are you setting the value to 0.0?. Can you please point me to the code?

If I understood correctly, this approach i.e., not return when get_value() fails, is only meant to be used in cases where the message structure is pre-allocated (for example, in a publisher). Am I right?

If yes, then in such cases, can I proceed with the following fix? Or should I also skip printing any warning or debug message?

Exactly, this part is perfect.

diff_drive_controller/src/diff_drive_controller.cpp

effort_controllers/src/joint_group_effort_controller.cpp

joint_trajectory_controller/src/joint_trajectory_controller.cpp

tricycle_controller/src/tricycle_controller.cpp

kumar-sanjeeev · 2025-06-11T07:12:13Z

Hello @kumar-sanjeeev

In the current implementation, it always returns with a message. In some cases, I am setting the value to 0.0 but still returning with a message.

In what cases are you setting the value to 0.0?. Can you please point me to the code?

Hello @saikishor , I have put comments where I have set value to 0.0. Let me know your thoughts.

saikishor · 2025-06-11T07:15:22Z

Hello @saikishor , I have put comments where I have set value to 0.0. Let me know your thoughts.

Thank you LGTM

saikishor · 2025-06-16T21:52:24Z

gpio_controllers/src/gpio_command_controller.cpp

-    command_interfaces_map_.at(full_command_interface_name)
-      .get()
-      .set_value(gpio_commands.interface_values[gpio_index].values[command_interface_index]);
+    if (!command_interfaces_map_.at(full_command_interface_name).get().set_value(command_value))


gpio_controllers/src/gpio_command_controller.cpp

saikishor · 2025-06-16T21:54:20Z

gpio_controllers/src/gpio_command_controller.cpp

+    }
+


Suggested change

}

}

else

{

here you will continue and access .value(). Here you will need a else statement

saikishor · 2025-06-16T21:54:51Z

gpio_controllers/src/gpio_command_controller.cpp

+      state_msg_interface_value_op.value();
  }


Suggested change

state_msg_interface_value_op.value();

}

state_msg_interface_value_op.value();

}

}

joint_trajectory_controller/src/joint_trajectory_controller.cpp

...r_controller/include/parallel_gripper_controller/parallel_gripper_action_controller_impl.hpp

saikishor · 2025-06-16T21:57:01Z

...r_controller/include/parallel_gripper_controller/parallel_gripper_action_controller_impl.hpp

+  {
+    RCLCPP_DEBUG(get_node()->get_logger(), "Unable to retrieve data of joint position");
+  }
+  command_struct_.position_cmd_ = position_op.value();


std::unique_lock<std::shared_mutex> lock(handle->get_mutex()); std::ignore = handle->set_value(lock, value);

Something like this

...r_controller/include/parallel_gripper_controller/parallel_gripper_action_controller_impl.hpp

pid_controller/src/pid_controller.cpp

saikishor · 2025-06-16T21:59:47Z

pid_controller/src/pid_controller.cpp

+        RCLCPP_DEBUG(
+          get_node()->get_logger(), "Unable to retrieve the state interface value for %s",
+          state_interfaces_[i].get_name().c_str());
+        return controller_interface::return_type::OK;


Sounds good

kumar-sanjeeev added 3 commits March 2, 2025 23:14

Fix deprecation warnings with use of new handles API in ackermann_ste…

0bf0670

…ering_controller

Fix deprecation warnings with use of new handles API in bicycle_steer…

1466fdc

…ing_controller

Fix typo

a447f31

github-actions bot requested review from arne48, christophfroehlich, DasRoteSkelett, homalozoa, mhubii, saikishor and VX792 March 3, 2025 19:36

christophfroehlich reviewed Mar 4, 2025

View reviewed changes

kumar-sanjeeev added 2 commits March 5, 2025 12:46

Fix deprecation warnings with use of new handles API in admittance_co…

d356e08

…ntroller

Fix deprecation warnings with use of new handles API in effort_contro…

e4f6aef

…llers

saikishor reviewed Mar 5, 2025

View reviewed changes

kumar-sanjeeev added 10 commits March 5, 2025 15:02

Fix deprecation warnings with use of new handles API in force_torque_…

44dcfcb

…sensor_broadcaster tests

Fix deprecation warnings with use of new handles API in forward_comma…

39200aa

…nd_controller

Fix deprecation warnings with use of new handles API in gpio_controllers

0c044b8

Add more descriptive message for warning

3b4685e

Change return from ERROR to SUCCESS to make it work in sychronous cal…

12d9639

…l, without failures

Fix deprecation warnings with use of new handles API in gripper_contr…

9592271

…ollers

Fix deprecation warnings with use of new handles API in joint_state_b…

704096b

…roadcaster

Fix deprecation warnings with use of new handles API in mecanum_drive…

214dcd1

…_controller

Fix deprecation warnings with use of new handles API in parallel_grip…

eaec22b

…per_controller

Fix deprecation warnings with use of new handles API in tricycle_cont…

a64136a

…roller

Merge branch 'ros-controls:master' into fix_warnings_in_controllers/n…

bf43abd

…ew_api

kumar-sanjeeev and others added 8 commits June 8, 2025 13:19

Update joint_trajectory_controller/src/joint_trajectory_controller.cpp

f382dbb

Co-authored-by: Sai Kishor Kothakota <[email protected]>

Update parallel_gripper_controller/include/parallel_gripper_controlle…

4c18e85

…r/parallel_gripper_action_controller_impl.hpp Co-authored-by: Sai Kishor Kothakota <[email protected]>

Update parallel_gripper_controller/include/parallel_gripper_controlle…

895ad29

…r/parallel_gripper_action_controller_impl.hpp Co-authored-by: Sai Kishor Kothakota <[email protected]>

Update parallel_gripper_controller/include/parallel_gripper_controlle…

c2d6b5c

…r/parallel_gripper_action_controller_impl.hpp Co-authored-by: Sai Kishor Kothakota <[email protected]>

Update joint_trajectory_controller/src/joint_trajectory_controller.cpp

14c672a

Co-authored-by: Sai Kishor Kothakota <[email protected]>

Update mecanum_drive_controller/src/mecanum_drive_controller.cpp

b473a22

Co-authored-by: Christoph Fröhlich <[email protected]>

Update joint_trajectory_controller/src/joint_trajectory_controller.cpp

4ce4139

steering_controllers_library/src/steering_controllers_library.cpp

330818c

kumar-sanjeeev commented Jun 9, 2025

View reviewed changes

christophfroehlich mentioned this pull request Jun 10, 2025

Remove deprecated feedforward parameter+service #1753

Merged

kumar-sanjeeev added 2 commits June 10, 2025 15:20

Remove return statement

fa07219

Code formatting pre-commit check

b387a61

Remove return statement

38c9e4a