Ros_control in ROS2 wishlist

[bmagyar]

Hello everyone,

Your friendly ros_control maintainer team has been busy thinking about what sort of community interest is there for a ROS2 ros_control version.

Example:

1. "We only need the diff_drive_controller as-is.
2. "My company only needs the joint_trajectory_controller as-is.
3. “I need all the controllers.”
4. “We need a more extendable framework (flexible hardware_interfaces) while maintaining the realtime-safe qualities.”
5. “My research needs interconnected controllers, the output of one is the input of the other.”
6. “My robot needs different update rates per controller.”
7. “My kids need better tutorials on how to write the hardware abstraction layer (RobotHW).”
8. “Redesign and rewrite the whole thing in X.”

Please fire away, this is an interactive wishlist

[pxalcantara]

joint_trajectory_controller as is, and position_controller/JointPositionController

[gavanderhoorn]

My first response would be: all of those, good suggestions (perhaps maybe the first two).

But thinking about it a bit more I would like to see:

1. maintain deterministic execution in everything (ie: hard real-time capability, not as a requirement (so keep components capable of running in deterministic environments, but don’t require it: see executors below))
2. support chaining controllers natively (probably using topics for input/output?), no subclassing
3. support mimo setups (should be doable if the previous item lands)
4. support industry-standard trajectory generators (almost off-topic, but you asked about joint_trajectory_controller, so: trapezoidal / s-curve profiles / higher-order interpolation / jerk-limited, etc)
5. Cartesian controllers (would probably require a Cartesian msg set as well …)
6. fully support managed nodes:
   • distribution and scheduling of controllers and other infrastructure with executors
   • full component life-cycle (error states, recovery mechanisms, etc) and management
   • full support for composite nodes (components?) with the associated benefits (zero-copy msg passing, node spin scheduling (pipelines fi), etc)
7. usability: more clearly document controller hierarchy ("position_controllers/JointPositionController ignores my PID parameters?")
8. usability: don’t call everything a “controller” (joint_state_controller)
9. C++11/14/17/20?
10. controllers in languages other than C++ (integration with ML/AI frameworks?)

And I’m sure I’m missing some things I’ve though of over the years. Others will post those probably.

---

ros-controls/ros_control#174 has some previous discussion on using a message/port based framework underneath ros_control (ie: OROCOS).

---

MachineKit devs have done a bit of work with ros_control and MachineKit integration, perhaps @zultron and @machinekoder have some inputs.

[gbiggs]

@gavanderhoorn

support chaining controllers natively ( probably using topics for input/output?), no subclassing

Using topics but allowing composition with zero-copy shared memory used (automatically by the middleware) when composed in a single process?

[nzlz]

Our final goal is to be able to use PID to help with collision avoidance in simulation, we are open to take a new approach.

From a quick look, I believe we would need the following ros-control related packages:

• gazebo_ros_control/DefaultRobotHWSim
• control_toolbox
• ros_control/hardware_interface
• ros_control/joint_limits_interface
• ros_control/transmission_interface
• ros_controllers/joint_state_controller

Not used in ros1, but we would probably need:

• ros_controllers/joint_trajectory_controller

[gavanderhoorn]

@gbiggs

@gavanderhoorn

support chaining controllers natively ( probably using topics for input/output?), no subclassing

Using topics but allowing composition with zero-copy shared memory used (automatically by the middleware) when composed in a single process?

O yes, of course. I thought that went without saying, but I should’ve been explicit about that.

[AndyZe]

I’m interested in trajectory execution with MoveIt! and the ability to modify a trajectory due to sensor feedback (aka admittance).

Also interested in not needing to make a service call to load/unload controllers, but being able to switch instantaneously.

[Loy]

AFAIK (but I’d like to be wrong here), ros_control currently requires each joint to be homed before starting ros_control.

• Support for homing joints with various methods, eg. and endstop switch

[carlossv]

@gavanderhoorn

1. maintain deterministic execution in everything (ie: hard real-time capability, not as a requirement (so keep components capable of running in deterministic environments, but don’t require it: see executors below))

+1

@gavanderhoorn

4. support industry-standard trajectory generators (almost off-topic, but you asked about joint_trajectory_controller , so: trapezoidal / s-curve profiles / higher-order interpolation / jerk-limited, etc)

+1

@gavanderhoorn

6. fully support managed nodes

+1

It would be also nice to have more support for distributed motion control. Some features that would be interesting to have:

• Remote life-cycle controller management.
• Multicast trajectory_msgs to remote JointTrajectory controllers. Each controller would execute its corresponding trajectory.
• Use a common E-stop topic to stop all the controllers at once.
• Master-slave mirroring controllers.
• Make use of DDS QoS policies (for example deadline) to implement a safe jog control.

[AndyZe]

• Use a common E-stop topic to stop all the controllers at once.

+1

[IanTheEngineer]

Having multiple controllers communicate in a shared-memory fashion, potential through a shared hardware interface, would be highly desirable.

For instance, when programming Sawyer’s ROS Control Gazebo node to achieve “Gravity Compensation”, we needed a controller to estimate arm Effort due to Gravity, Inertia, and Coriolis forces based on the current arm configuration and then combine that with the desired commanded control mode (Position PID, Velocity PID, or direct Effort).

We achieved this with a custom Hardware Interface package that would allow controllers to “share” the control over a single interface (like Position PID + Gravity compensation), and sum their component efforts to achieve the desired command without needing to worry about Gravity-related forces.

The code is all there on github, but I never took the time to figure out how to contribute the useful bits back to ros_controls. I’d be interested in helping make this part of the ROS2 ros_controls Hardware Interface.

[Jordan_Lack]

For me hard realtime would be a requirement I think. Also it would be nice to maybe start leaning on orocos for some of the desired capabilities like controllers spinning at diff rates

[gbiggs]

@Jordan_Lack

Also it would be nice to maybe start leaning on orocos for some of the desired capabilities like controllers spinning at diff rates

In ROS 2 you can do that without having to lean on Orocos.

[destogl]

I am missing following features in the current ros_control implementation:

1. “My research needs interconnected controllers, the output of one is the input of the other.”

• Cascade Control (e.g.) - This can be currently done, but it is not nice. i am doing it with inheritance.

  • maybe I do not understand something here, but I found my solution as not nice, but it works

2. “We need a more extendable framework (flexible hardware_interfaces) while maintaining the realtime-safe qualities.”

• Clear separation of RobotHW on sensors and actuators. This would enable easier integration of external sensors, e.g. FTS on an industrial robot

  • for this we started implementing an extension called combined robot_sensor_hw because currently one has to extend RobotHW directly and then robot package has new dependencies… an example of this can be found here.

  • this would mean to have HWInterface as base with SensorHW and ActuatorHW extending it. Then the RobotHW has list of SensorHWs and ActuatorHWs so one could simply add new sensors to it. Everything can be solved nicely over Pluginlib to avoid unnecessary dependencies.

  • IMHO this would be more control-theory approach

3. “I need all the controllers.”

Thanks for asking this. If you need any help with first two topics I could provide some input and implementation effort since we have kind of non-standard solution.

[robo]

• We use the Joint_Trajectory_Controller, Joint_Position_Controller and Cartesian_controllers most often.
• Cascaded Controllers and compliance controllers would be nice to have.

[athackst]

We’re mostly interested in the diff_drive_controller as is at this point

[MartinCornelis]

We’re mostly interested in the diff_drive_controller and the joint_state_controller.

[bmagyar]

Thanks! I would be very interested to see how much of this could be integrated into the current ros_control codebase (switches to dodgy whisper perhaps even for melodic).

[bmagyar]

How would you propose to do this?
Doesn’t the switch interface cover this already?

Most components that support modes at the hardware level require at least one update cycle (sending out CAN/ETHERCAT messages) to change the mode, that’s partly why we have such a rigid system. Very similar to lifecycles of OROCOS components if you are familiar with that.

[AndyZe]

I’m not very familiar with OROCOS. I think I caused some confusion by saying “instantaneous switching”. What I really want is to avoid switching controllers, period.

Why not a single velocity controller that accepts both trajectory commands and instantaneous velocity commands? While following a trajectory, if a new, instantaneous jog command comes in, the robot halts (as quickly as possible) then begins to follow the instantaneous velocity command. This PR does that: https://github.com/ros-controls/ros_controllers/pull/393 Instantaneous velocity commands always preempt trajectories.

Thus, no controller switching is needed.

The next level would be to blend the velocities so it’s not necessary to halt at a transition.

It would also be possible to blend position commands, but I didn’t have a need to take it that far.