ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A

Ros_control in ROS2 wishlist




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.
  • Use a common E-stop topic to stop all the controllers at once.


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.

1 Like

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

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

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 :slight_smile:
  1. “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 :slight_smile:

  1. “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.

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

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

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

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).

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.

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: 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.

This is minor, but just thought of another “wish”: let’s not use the name “controller” for everything that is not a hardware_interface.

It’s one of the first things that I always have to explain to new users of ros_control: no, joint_state_controller doesn’t actually control your robot, it just publishes JointState messages …

1 Like

But is it controlling those joint states? :wink:

Maybe joint_state_generator or something similar would work better?

1 Like

Off-topic here, but:

It is definitely in control of something, but not sure that should be the main reason to give it that name. It’s almost akin to *Manager: all classes manage something.

The class doesn’t really generate joint states either: all it does is transform, translate or convert from one representation (stored in the resource it has a handle to) to another (JointState). And then publishes.

Unfortunately joint_state_publisher has already been taken …

Not helping keep things on topic, but I originally called it fake_joint_state_publisher or something like that.


It would be good to have diff_drive_controller and the velocity_controllers/JointVelocityController.

@bmagyar Can you give a brief status update on the progress of porting ros_control to ROS 2?


@bmagyar Friendly ping.

1 Like

We are currently in the process of readying code in Melodic to move to ROS2.
@sloretz is currently working on this for control_toolbox and realtime_tools. Plans are to go do dashing with these packages. In the mean time, the first proof of concept version is still available for Crystal.