search

ros-controls / ros_control

Generic and simple controls framework for ROS
http://wiki.ros.org/ros_control
BSD 3-Clause "New" or "Revised" License
469 stars 307 forks source link

Add PositionVelocityTorqueGainsJointHandle #515

Closed wxmerkt closed 8 months ago

wxmerkt commented 1 year ago

This PR proposes a new JointHandle to be able to set target position, velocities, feed-forward torques and gains at the same time from controllers. We have been using this interface on various pieces of hardware for control in the past and have seen the need for such an interface being discussed as well (and to my knowledge it's actively being worked on for ROS2-Control). Ideally, we'd love to see such a joint interface also available for ROS1-Control - what are your thoughts and feedback on this?

We also have a set of forwarding controllers for ros_controllers to be paired with this PR should there be interest in introducing this joint handle type to hardware_interface.

wxmerkt commented 1 year ago

@bmagyar Do you have suggestions who could take a look at this and provide input/feedback?

wxmerkt commented 1 year ago

Friendly ping - any suggestions or feedback?

bmagyar commented 1 year ago

I think this could work. My main concern at this point is ABI and API stability. Are you familiar with ROS Obese? Unfortunately it's source-based however I could open a master branch here that we use as a rolling version without guarantees for Obese. What do you think? Prefer Noetic?

wxmerkt commented 1 year ago

Many thanks for your time and taking a look. Since this is adding a new (separate) interface type which is only a header, does it affect ABI compatibility? It does not change existing interfaces so API/ABI shouldn't be affected - and I don't think it is included by default in any other packages that are compiled to binary? [My plan is to make a follow-on PR to propose a standard set of forwarding controllers in ros_controllers, but this will be a new package and should not affect API/ABI of existing packages]

My understanding is that ROS Obese is building off the noetic-devel branches and the maintainers are making patches where those are required - which are frequently merged into the noetic-devel branches since they do not affect backwards compatibility.