- 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? 
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?
2 Likes
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.
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.