A Reference Control Architecture for Service Robots as applied to a Climbing Vehicle

Abstract

Recent progress in mechatronics, perception and computing is opening up a number of new application domains for robotics, improving the way in which robots perform actions that release the human from dangerous or risky tasks. Nowadays, the field of service robotics is in continuous development, covering more and more application domains, from home to industry, and offering more and more capabilities in a reliable and user-friendly way. One of the new environments where robots are starting to appear is in the shipyard. Developing robots for working in shipyards is very challenging because of both the difficulty of the missions that robots should perform as well as the lack of robotic culture in this kind of industrial facility. The authors' research group, the DSIE (Division of Electronics Engineering & Systems) at the Technical University of Cartagena, has a considerable experience in the development of software applications for teleoperated service robots, mainly for nuclear power plants The work presented in this chapter has been carried out in the context of the EFTCoR project (Environmental Friendly and Cost-Effective Technology for Coating Removal) The EFTCoR project sought to develop a solution for ships' hulls cleaning and for the retrieval and confinement of the oxide, paint and sea adherences resulting from the cleaning operations. For this purpose, several robots were designed, one of which being a climbing vehicle capable of positioning a grit-blasting tool onto ships' hulls. This chapter describes our experience in the development of the climbing robot and the software architecture designed for its control unit, ACROSET (Control Architecture for Service Teleoperated Robots). Software architecture is one of the key elements of any robotic system. As technology evolves, it is possible to build systems that are capable of carrying out more complex tasks in more complex environments. But the new robot capabilities demand a great variety of components, both hardware and software, that must interact in diverse ways. Such components must be structured in a way that (1) the robot achieves its global functionality and (2) the system could be easily maintained and updated. The way in which components are organised is described by the architecture of the system. The importance of considering system architecture to handle the inherent complexity of robotic systems is well known (Coste-Manire & Simmons, 2000): overall system complexity can be reduced by dividing it