Effort group position controller

[Karsten1987]

No description provided.

[bmagyar]

Any updates on this sire?

[shonigmann]

I would be interested in trying to build on @Karsten1987's work this if this is in the backlog, as I'd be interested in using this controller for my own work.

I'm curious what the state of joint_limits_interface is though, as it seems like adding joint type and limit considerations was the only TODO left? I haven't seen any other controllers using it yet in ROS2, so perhaps it is not quite ready yet?

Thanks!

[Karsten1987]

we are having it currently in use, but it's not strongly tested and I've left it on "draft mode" until I have to angles wraparound sorted out. See #172

@shonigmann please by all means go ahead and work on top of this PR. Happy to review stuff once you have some contribution.

[shonigmann]

hi @Karsten1987 - thanks for the update. I am happy to try to contribute, but I think I need to get a better grasp of all the moving parts to determine how to best proceed.

JointLimits seems like the logical place to start to track and apply joint limits and to determine whether angle_wraparound is needed. But it also looks like a refactor is underway with how and where JointLimits are handled (ros-controls/ros2_control#441). Would it be worth basing off destogl:joint_limit_interface?

As far as handling angle wraparound goes, it looks like in ROS1, this function was included in the Joint Trajectory Controller. Does it make sense for this function to be controller specific? Are there any plans to have a separate header for angle wraparound, as I would imagine it would be an important consideration for any position-tracking controller? Or should I just include a wraparound function in this controller, and worry about where it lives at a later date?

Thanks in advance for your guidance - I'm definitely still familiarizing myself with the current state of ros2_control and ros2_controllers

[destogl]

As far as handling angle wraparound goes, it looks like in ROS1, this function was included in the Joint Trajectory Controller. Does it make sense for this function to be controller specific? Are there any plans to have a separate header for angle wraparound, as I would imagine it would be an important consideration for any position-tracking controller? Or should I just include a wraparound function in this controller, and worry about where it lives at a later date?

It makes also sense to have a separate header for angle wraparound. Especially because it is still not 100% clear how to sync controllers and joint limits. How to include those into control loop and at which place exactly.

[shonigmann]

as an update, i've implemented and lightly tested a position-PID and velocity-PID controller with basic limit checking and angle wraparound (on my fork, here).

Caveat being that I used a modified version of the potentially obsolete joint_limits_interface package, removing the COLCON_IGNORE and references to joint_limits_interface.hpp so that the package would build. This lets me reuse joint_limits.hpp, joint_limits_rosparam.hpp, and eventually joint_limits_urdf.hpp.

There's definitely room for discussion on how to best implement limits with a PID controller, how to manage limit overrides (from URDF vs ROS Param), etc, but maybe its still useful as a first wrong answer.

In any case, I'm open to feedback and happy to keep building on this.

[destogl]

@shonigmann in ros-controls/ros2_control#462 we propose the updated structure to read joint limits from yaml file and using it in controllers. Do you find this useful? (Let's continue the discussion on ros-controls/ros2_control#462.)

[mergify]

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

[mergify]

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

[mergify]

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

[mergify]

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