Real Time Joint Control (MIMO) in ROS

The Robotic Operating System is quite effective as a software framework for building robotic applications. It is like a glue that holds everything together. But there were a couple of areas where I got stuck and I thought I should write a post about it.

ros_control : Some of the naming of controllers and packages could have been a tad better. For example, a joint_state_controller is actually not a controller but just publishes the joint states. And it took a good amount of time for me to become familiar with forward_command_controller and hardware_interface.

Also joint_position_controller and joint_velocity_controller are basically not controllers into themselves but derived classes from forward_command_controller which do as the name suggests i.e. pass on the commands to the hardware_interface.

Also ros_control veers towards a linear Single Input-Single Output system based on the traditional PID law. Sophisticated control techniques that require control values to be calculated from all other inputs (Multiple In-Multiple Output) are sparsely documented in the ROS Wiki.

So when I set out to write a computed torque controller for my six dof arm, I felt myself nonplussed. Computed torque is a classical non-linear MIMO control technique. Individual joint torques are calculated based on an inverse dynamics model for achieving trajectory execution.

A caveat here. No textbook or course tells you about what hardware or motors you require for implementing a particular control method. I went through an entire course of robotics without realizing on which motor can certain control techniques be implemented. So when I got down to writing my controller, I grasped that you need motors which can apply a “given torque” when you command them. Neither Steppers nor Brushed DC can. Only Brushless DC can. And they cost a bomb.

Controller implementation follows here:

• In ROS, controllers are plugins which are loaded by the controller_manager. Main function of the controller is to respond to the update() calls from the hardware_interface.
• Use pluginlib to write a catkin package for your controller. A computed torque control approach requires an inverse dynamic solver which is easy enough to implement using the Newton-Euler formulation. Use orocos_kdl for computing Jacobians and transforming between frames.
• My case also involved creating a custom inverse kinematics solver using the kinematics::KinematicsBase class from MoveIt! . IK_Fast, kdl or Trac-IK can also be used.
• Include your custom controller params in the config yaml files.
• Real Time implementation tasks of the controller should be scheduled by a preemptive strict priority based scheduler policy. To obtain hard real time capability on your Linux system, it is essential to install the PREEMPT_RT kernel patch.
• Test your controller using gtests.

If you want to know more, shoot me a mail at rohin@nymble.in ! Would love to connect and learn from you!

Cheers!