ROS has been one of the greatest advances of the robotics industry in the past years. Its development began as a way to help the development of robot applications, easing the communication between sensors and algorithms, following the paradigm of “program once, test everywhere”.
This has been the pattern of the last years, and ROS has performed extremely good in that way. For example, you could code an algorithm to take an image as its input, without caring about which model, resolution or connection type, as long as it was supported by ROS and adopted its API.
But this focusing on the high level layer of application development led to an unthinkable oblivion: How was the access to actuators managed? How were the references of the actuators calculated? As in the case of high level applications, where the end user shouldn’t care about the source and destination of the data used and produced by him, in the case of robot control the user shouldn’t care about which type of actuators are used by a robot.
But today, this is not the situation anymore. ROS Control is the API that has been developed by the ROS community to allow simple access to different actuators. Using this standard API, the controller code is separated from the actuator code. For example, one could write a new controller implementing a fancy control strategy, and test it on different hardware without changing a single line of code. Or one could test different control algorithm with same hardware to find the most suitable for its needs.
ROS Control has different features that make it really appealing: real time capabilities, that allows to run control loops at hundreds of hertz; a simple manager interface, that gives access to the actuators and handles resource conflicts; a safety interface, that knows the hardware limitation of the joints and ensures that the commands sent to the actuators are between their limits; and a set off-the-shelf controllers that are ready to be used.
Have you ever thought about the mapping between joint and actuator space? ROS Control already did it. Normally this mapping is one-to-one, i.e. one actuator controls one joint, and their movement is related by a gearbox, so you don’t need to do messy calculations. However, in case of more complex scenarios, e.g. when a differential transmission is used, ROS Control gives us an elegant solution through its transmission interface to cope with this problem.
What about mixing different robot components into one? This is a trend nowadays, where robot components are autonomous and usable on their own, but can also be assembled into a single functional system. In those cases, ROS provides high level coordination between the components, but with ROS Control this coordination is also achieved at the low level, extending the control possibilities to far and beyond, for example, with a more coupled control between a robotic arm and the tool attached to it.
Finally, the separation between controllers and actuators allows an interesting option: simulation. Gazebo, the standard robot simulator used by ROS, implements simulated ROS Control actuators, and one can write and test a controller even before it has the real robot available. This feature of ROS Control is used at Robotnik to test new kinematic configurations for its most edgy robots, allowing for quick prototype delivery.
ROS Control is one of the key parts for the domination of the robotic world by ROS. As a world leading company in the ROS community, Robotnik makes an extensive use of ROS Control to give its customers the best products available on the market.Tweet