A reference control architecture for service robots implemented on 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 (Iborra et al., 2003) and in shipyards industry (Fernández et al., 2004). 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) (EFTCoR, 2005). 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-Manière & Simmons, 2000): overall system complexity can be reduced by dividing itinto smaller components with well defined abstraction levels and interfaces. The definition of a good architectural framework allows rapid development of systems, maintenance, scalability and reuse of a large variety of components, with concomitant savings in time and money. As said before, the objectives of this chapter are twofold: to present the climbing vehicle (Lázaro) and the architectural framework used for designing its control unit (ACROSET). This chapter is structured in eight sections. Section two exposes the challenges and special requirements imposed by shipyards to design robots for cleaning ships’ hulls. It also includes discussion on the state of the art on climbing robots for ship cleaning and the issues that, in our opinion, can be improved. Our contribution, the Lázaro robot, is described in section three, where two versions of this climbing vehicle are presented. In section four, the importance of software architecture for the development and maintenance of a robot is discussed, including a brief description of the latest frameworks for robotics and the possible contribution of ACROSET to the state of the art. The main characteristics, subsystems, components and design guidelines of ACROSET are presented in section five. The following section explains how this architectural framework has been used to develop the control unit of the climbing robots, and towards the end the chapter, some tests, results, lessons learned and conclusions are presented.