| ROS Resources: ROS Homepage | Media and Trademarks | Documentation | ROS Index | How to Get Help | Q&A Help Site | Discussion Forum | Service Status |
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 …
But is it controlling those joint states? 
Maybe joint_state_generator or something similar would work better?
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.
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 
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.
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.
@Levi-Armstrong this is of interest to ROS-I and our broader team.