ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A answers.ros.org

Ros_control in ROS2 wishlist

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

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.

2 Likes

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?

3 Likes

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

Are there already plans beyond a plain port?

Not yet unfortunately. As matters stand, the maintainers can’t commit any serious effort beyond reviewing and small bugfixes. Happy to collaborate with whoever can contribute though.

The reason for this thread was to probe interest and it seems the community needs the current main features and controllers + some more :slight_smile:

If there are different parties interested in contributing we could jump on a hangouts call and discuss a roadmap with maintainers helping setting scope & approximating time commitment.

1 Like

What is the main bottleneck here? Time? Or funding?

ros_control is a prime candidate for funding from the ROSIN project.

If there are users / maintainers interested in putting together a proposal and getting (part of) their time funded through ROSIN that would have a high chance of being granted.

Seeing the interest in ros_control expressed by the contributors to this thread, perhaps a small team could be put together to work on a ROS 2 implementation?

We would be interested. Some more idea: the hardware interface is kind of great to do some introspection on the hardware for a generic controller. What would be interesting is a high level description of the CPU power to know how much real-time thread spawnning the controller can do.

As I’m part of the coordinating organisation of ROSIN, I cannot participate in any projects.

If you can get together a small team of people that could work on this, a proposal would not be too much work I believe.