A Methodology for the Development of Robot
Anuncio
1 A Methodology for the Development of Robot Software Architecture (MDASR) Nelson de J. Londoño Ospina. Abstract— The Methodology for the Development of Robot Software Architecture (MDARS) follows the most significant concepts and standard languages in all the stages of the process of development (Specification, Analysis, Development, Implementation, Validation and Testing). In this paper, basic steps are presented in a graphic representation as well as the methodology, which is exemplified in a proposal of representative architecture giving support and enlightening every stage. The methodology is grounded on software engineering paradigms by applying methods and languages widely accepted by the scientific community. Key words— Robot Architecture, Software Engineering, Unified Modelling Process, Software Development, Software Methodologies. I. INTRODUCTION Robot software architectures [1]-[8], strategies and approaches to achieve proper operation, set of sensors, actuators and processing hardware [9]-[15], are currently extended fields of study that enhance and uphold the science of Robotics. The particular complexity and inconveniences of these systems along with the large variety of approaches and representations of Control Architectures, especially when it comes to “Mobile Robots”, have hindered communication and understanding of those not directly involved in the subject, and obstruct the interrelation between the engineer proposing the architecture (robotics engineer) and the engineer who applies the architecture (commonly a software systems specialist). Such pitfall in communication is clearly noticeable given the variance of experiences and languages handled by every expert. These problems prompted a research project proposal to assess different alternatives aimed at overcoming the encumbrances between conception, representation and development of these systems. Through the analysis of multiple approaches of representation, conception methods and development techniques, a need to underpin the process in the proper paradigms of software engineering [16]-[27] became evident; specifically, as regards methodologies and methods applied to develop a software system with high complexity levels [22], [28]-[34]. In fact, this provides systematic procedures and fully-grown representation languages for the design and development of Robot Software Architecture, which give support to a methodology of systems conception, design and validation. The “Unified Process of Software Development”[34] suggests guidelines and procedures enclosed within the Object-Oriented Concept, based on (UML) [35]-[40]. It was adopted as the cornerstone of the proposal, accompanied by typical elements of software engineering and applied on the specific case for Control Software of Mobile Robots. II. MDASR MDASR (Methodology for the development of Robot Software Architecture), follows the paradigms of Software Engineering, which are based on the assembly of interrelated steps that capture the main features of the system and its environment [17], [18], [19], [22], [37], though defined and applied to the issue of Robot Software Architecture. As any methodology, this is a systematic process that benefits the development of said architectures. MDASR involves, the vast majority of stages in developing a project, provides the operation and speed up its conception, analysis, design, implementation and validation; it fosters and illustrates the use of an easy-tounderstand language and engages other actors in the process: - The robotics engineer, whose objective is to have a well designed system able to comply with the expected specifications and functional structure. - The computer engineer, who shall know the requirements in a basic language, in order to turn such requirements into a software program that shall comply with the customer’s demands. In Fig. 1, the general methodology outline is presented. Every single step to be considered in the development of Robot Software Systems is given herein. III. PROPOSED ARCHITECTURE In order to illustrate all steps as planned, which require at the same time a set of tasks and activities, an architecture involving many of the most recurrent elements in today’s architectural proposals, is taken as basis. In Fig. 2, a generic outline of this architecture is shown. 2 VISION GENERAL DEL SISTEMA “El Robot-Entorno” Preliminares: Entorno, Consideraciones, Arquitectura General Usuario Propósito Objetivo S.Actual S.Propuesto Requisitos(CU) ESPECIFICACION de la Arquitectura Usuario - Visión General del Sistema Robot - Arquitectura - objeto de desarrollo - Requisitos (Casos de Uso) Interfaz Usuario MODELO (CASOS DE USO) Arquitectura. Paquetes Sub-Paquetes Clases Modelo Anal ANALISIS Usuario Arquitectura Software Desarrollador - Sistemas o Paquetes Arquitectura Software - SubPaquetes y Subsistemas de Análisis - Identificar. Clases Análisis - Diagrama de Interacción DISEÑO MODELO DE ANALISIS Arquitectura Software para Robots Desarrollador - Nodos - Sistemas y Subsistemas - Casos de Uso Diseño - Clase (diagrams) Arquitectura Clases/Objeto s Modelo Clases Diseño Clases MODELO DE DISEÑO Arquitectura Software IV. APLICATION OF METHODOLOGY Having as starting point the architecture proposed by the robotics engineer, all the steps shown in Fig. 1 are illustrated in this section, thereby it is expected to provide a general development overview as suggested by MDASR. A. System Overview The first stage deals with a general feature identification which shall rule the software architecture. These features are: hardware system, operation environment, tasks to be completed, special considerations, general architecture. B. Specification The specification of requirements stage is outlined in the diagram of Fig. 3. This proceeding is subject to the characteristics required on each case, and might be extended or modified. ESPECIFICACION de la Arquitectura -Hardware - Entorno - Tareas -Consideraciones especiales IMPLEMENTACION Desarrollador - Clases, - Componentes - Empaquetar - Dependencias Usuario Visión General Del Sitema Robot ARQUITECTURA SOFTWARE - Propósito - Alcances - Objetivo Especificación del Problema La Arquitectura como Objeto de Desarrollo - Plataforma utilizada Estado Actual Del Robot - Identificación - Descripción - Modelación Requisitos - Requisitos no funcionales Arquitectura Software Propuesta Fig. 1. MDASR General Diagram Panorama General de la Arquitectura Conocimiento Aprendizaje Captura de requisitos Identificar y Definir Actores INTERFAZUSUARIO Describir Requisitos Identificar y Definir Casos de Uso MODELO CASOS DE USO PLANIFICADORGLOBAL (Planificador Misiones) S I S T E M A MODELODE ENTORNO C O N T R O L Diagramas de Casos de Uso PLANIFICADORLOCAL (Control Alto Nivel) (Navegación) (PilotajeEurísticay Experiencia) 1) Purpose of the System The purpose of the system intended to be developed is to implement a software architecture to control a mobile robot with different modes of operation: Remote Controlled, semi-autonomous and autonomous, involved in unknown static environments and running in a PCcontrolled Kephera [41] robot. SUPERVISOR YGESTOR DECOMPORTAMIENTOS (Control medio) (Subsistema MotorAuRA) Diagnóstico Recuperación CONTROLREACTIVO S E N S O R I A L Detalles de Casos de Uso Fig. 3. Specification Flowchart Conocimiento Aprendizaje S I S T E M A Requisitos No Funcionales INTERFAZ/ACTUADORES EXPERTICIA SISTEMASENSORIAL (PercepciónEncontrar Onstáculo, Referencias, caminos) SISTEMA ACTUADOR ESTADOINTERNO (Sitemahomeostático) ENTORNO Fig. 2. Proposed architecture 2) Current System Within the framework of the above-mentioned methodology, that the architecture intended to be developed shall be implemented on a basic robot platform must be assumed, thus making relevant the identification, during this stage, of the system characteristics by giving details of both software and hardware. This information is commonly available in the user’s manual or in the technical information of the robot. It is suggested to represent its characteristics supported in a UML scheme. In Fig. 4, the characteristics of the Khepra system represented on UML are presented. There both the Robot system and the corresponding actors that interact with the system are specified. 3 Almacenar TrayectoriaTarea Cargar Parámetros PC <<Include>> Mostrar Sensores Interfaz de Usuario-PC <<Include>> Interfaz Puerto Usuario Usuario Mover Robot <<Extend>> Eject.Modo Manuel Leer Sensores <<Include>> <<Extend>> <<Extend>> Eject.Modo SemeiAutom <<Include>> Robot Eject.Modo Automnomo <<Include>> Interfaz de Usuario-Robot Interfaz sensor/ actuador Robot Mover Motores Entorno Fig. 6. Use Case Model of the Software Architecture for Mobile Robots Control Básico Base de Datos d ) Use Case Analysis The use cases specified in the previous section are herein closely described. For this purpose, a form to describe its operation and functional relationship with every actor involved or use case of the system is provided. Operaciones y Procesos Fig. 4. Current Model 3) Requirements Capture a) Description of "Software Architecture" The “Control Arquitecture” allows the robot to move in response to an order given by the operator. It shall allow functioning in any of the three basic operation modes, selected via interface: autonomous, semi-autonomous, remote controlled (manual). In fig. 5, the architecture wished-for to be implemented is presented. This is the first description that widely identifies the architecture and its relationship with the environment and user (Actors). e ) Use Case Refinement To identify use cases that require specifications with a higher degree of detail is common in the general use case model. In fact, this entails checking of every single use case. On that account, it is important to identify those use cases comprising a more general scope. To set an illustrative example, the use case “Ejecutar_Modo_ Manual” is presented: - Use Case: Execute Manual Mode (Remote Controlled) Manual mode requires a series of functions and services captured as use cases. Such proceeding shall be developed following the foregoing procedures. Robot Usuario Entorno Ecuaciones <<Extend>> Interfaz de Usuario Interfaz Actuadores Interfaz Sensores Estrategias de Control Modelos de entorno <<Extend>> <<Extend>> <<Extend>> Captura manual Leer Sensores <<Include>> <<Extend>> Robot Mover Robot Base de datos Otros Algormos <<Extend>> Otros métodos Almacenar trayectoria Modelos Perifericos Tablas <<Include>> Mover Motores Usuario <<Extend>> ARQUITECTURA SOFTWARE Fig. 5. Representation of Software Eject.Modo Manuel <<Extend>> <<Extend>> Paro Normal <<Extend>> Para Emergencia <<Extend>> Moverse Velocidad <<Extend>> b) Identification of Actors The actors are institutions, individuals or Software/ Hardware elements interacting with the system. A categorization of actors is given in detail and some others that were not previously considered are identified. c ) Use Case Models The use case model is the resulting product after a close evaluation of the functions and services that the architecture shall offer. It is summarized in a UML diagram which provides a first overview of the system specification. Fig 6 relates the general use case diagram of the proposed architecture Iniciarl Moverse Posicion Fig. 7. Use Case: “Execute Manual Mode” (Remote Controlled) Fig. 7 shows the final product and use case model obtained through the specification of “Use Case: Ejecutar_ Modo Manual”. 4 C. Analysis The second stage involving MDASR methodology, after having been specified, suggests the analysis of the system to be developed, and the identification of the general solution. Fig. 8 outlines the steps suggested in the MDASR for this stage of the analysis. 1) Analysis of the Software Architecture (First Level of Detail). Being the development methodology inspired in the PUD, both the analysis and the specification stages shall be iterative and incremental. A first analysis of the general solution is suggested on the first stage. Subsequently, through consecutive iterations, repeat the specification and analysis steps to architectural specific packages. are presented as a preliminary solution to the system to be developed. A more detailed examination of each of the packages previously proposed requires inspection of the subpackages comprising the above-mentioned ones, following, likewise, a process of analysis and evaluation based upon use cases. InterzaUsuario SistControl BaseDatos SistMotori SistSensor ESPECIFICACIÓN ANALISIS Arquitectura Software - A partir de los Casos de Uso Sistemas o Paquetes Arquitectura Software SubPaquetes y Subsistemas de Análisis: - Identificar - Relación y - Dependencia) Identificar. Clases Análisis A partir de Subsistemas A partir de Caos de Uso Diagrama de Interacción MODELO DE ANALISIS Arquitectura Software para Robots Análisis de Clases Fig. 10. - Control architecture, packages and their interrelation. - Responsabilidad - Atributos - Asociaciones Agregaciones - Generalización Fig. 8. Analysis Flowchart Diagram a ) Identification of the architecture systems Analysis packages - Based on the system specification, through use case models, the analysis packages that implement the use cases are identified and classified according to their features and functionality. -Control Systems As a response to the case “Mover_ Robot”, an analysis package that implement the basic control functions is detected. In Fig. 9, the package named as “SistControl” is shown. Control System - RefinementA second iteration allows greater details of packages that apply more specific use cases, such as the subpackage “Deliberative Control”, which puts into effect the use cases shown in Fig. 11 corresponding to the refinement of the "SistControl” package. A diagram of the Control System and its interrelation is presented in Fig. 12 as a consequence of the analysis of every single subpackage identified. Ejecutar Modo Deliberativo CDeliberativo Supervisar y gestionar tareas Procesar modelo de entorno Planificar trayectoria SistControl Mover Robot Ejecutar Modo manual Planificar trayectoria local Ejecutar Modo Semi-autónomo Fig. 11. Use Cases “CDeliberativo” Ejecutar Modo Autónomo Fig. 9. Package “Sistema Control” b) Definition of general packages (Subsystems) and their interrelation After a close identification, definition and analysis of the analysis packages that implement all the use cases, a pattern of analysis of the general system is obtained (Fig. 10), where the packages conceived and their interrelation 5 Sistema_Controli process, on which the different uses cases required to implement the above-mentioned use case have been detailed and justified. The scheme shows the diagram globally, however every single one of the cases has passed through a detailed and more specified process of specification, description, identification, analysis and particular refinement resulting in a comprehensive description of all the use cases required by the system. Gestor_Su pe rv_ Tarea s CDeliberativo CCompo rtam iento s CReactivo Activar/Desactivar_ Modo _Reactivo Comand os_Ba sicos Tomar Info_Sensor es <<Extend>> <<Extend>> Fig. 12. Relationship diagram, package elements of ControlSystem <<Include>> Evaluar_Info _Sensorica Seguridad Evaluar comportamiento _a_ Activar Preventivo <<Extend>> <<Include>> Leer Sensores <<Include>> Activar_ Comportamiento Rectiva Desbloqueo <<Extend>> <<Extend>> <<Include>> Evaluar 2 ) Analysis of Architecture Subpackages (Second Iteration) <<Extend>> Ejecutar tarea <<Include>> During a second iteration, execution of the same previous proceedings is suggested for those packages that might be handled as systems almost independent. A representative example of this occurrence is the reactive control system, which might be considered as an independent system (Architecture), and therefore, a complete inspection of all the steps proposed including a detailed specification of the system is accomplished. a ) Specification of Reactive Control Subpackage System Overview Fig. 13 shows, from the standpoint of the Robotics engineer, an overview of a system on which a “Reactive” control architecture has been created and implemented on a predefined robot (Khepera). Navegacion Calcular_ Acion_Motores <<Extend>> Eject.Modo Automo Gestion_ Fallas Usuario Robot <<Include>> Gestion_ Alarmas Mover Robot Mover Motores Fig.15. Detailed Use Case Diagram “Ejecutar_ Control_Reactivo”. b ) Subpackage Specification: Deliberative Control. To illustrate another example, the deliberative control is implemented by using inclusion relationships along with more specific use cases such as those detailed in Fig. 16. Almacenar Trayectoria Planificar <<Include>> Definir trayectoria Deliberativo Inicio Paro Comportam. Estado Motores <<Extend>> Control Reactivo Sensores <<Include>> RePlanificar Ejecutar Tarea Robot Dividir en Subtareas <<Extend>> Evalaur Estado Actual <<Include>> <<Extend>> Eject.Modo Automo Usuario Almacenar Traect-Local Usuario Fig. 13. Reactive Control System The generic use case diagram, a product of the process of specification of the proposed reactive control system is shown in Fig. 14. The actors and their corresponding use cases are clearly identified thereby conceiving the new system (Reactive Control Architecture) as a process of software development nearly independent. Robot Mover Robot <<Include>> Mover Motores Fig. 16. Detailed Use Case Diagram implementing “Deliberative” c ) Analysis of Reactive Subsystem In a second iteration, identification of packages and subpackages of all the systems created during the process shall be done. For instance, Fig. 17 illustrates an analysis diagram, the “Navigation System”, which corresponds to a subpackage identified in the Reactive Control, from the use cases that it implements. Ejecutar_Rectiva <<Include>> <<Include>> Leer Sensores Usuario Mover Motores Robot Fig. 14. Use Case "Ejecutar_Control_Reactivo" - Use Case "Ejecutar_Control_Reactivo" After a refinement process of the use cases identified on the previous stage, a more detailed diagram is obtained in Fig. 15. This type of diagrams results from a prior specification 6 Desbloqueo Ejecutar_comporta mietnos_navegación Sist_Navegacion Ejec_Comp_ Braitenberg Gesto_ Desbloqueo Estados_ Sensores_ Requeridos Ejec_Comp_V argar-Explorar Ejec_Comp_ Seguir Trayectoria … … … Fig. 17. Identification of the analysis package "Sist_Navegacion" from its use cases Algoritmo_ Bordea_Muro Algoritmo_ Salir_Zonas _ Muertas Fig. 20. Unblock Subpackage ClassModel Similarly, the other system packages of the reactive control are introduced, which, obviously lead to package architecture proposals as shown in Fig. 18. . e) Model -Analysis- “ Reactive Control Software Architecture” 1:Orden Seguir muro :Operador 2:Iniciar Seguir muro Seguir muro 13:Set Point Motores 13:Set Point Motores Inte rfaz Motores (n) Generador Set Poin Motores 3:C alcular dirección Sistema_Control_Reactivoi 12:Valores Limite) 11:Leer Valores límite 10:Nueva consigana (Dirección y ángulos) Sist_Navegacion Otros Sist_Desbloqueo Sist_Preventivo Velocidad consigna 5:Leer Sensores Proximidad 4:Hay cambio de estado? Sist_Seguridad Algoritmo Seguimiento muros 9:Hay cambio de estado E valuar sensores 7:Lectura Normalizada 6:Valores Leídos Interfaz_ Sensores Sensores 8:Loop Evaluar hasta Cambio de estado Fig. 18. Architecture through Reactive Control System Packages (a). Flowchart of occurrence-Track Wall (Normal Condition) 12:Iformar estado bloqueado 1:Orden Seguir muro :Operador Seguir muro 13:Set Point Motores 11:Parara motores Inte rfaz Motores (n) Generador Set Poin Motores d ) Identification of Classes Founded on the packages and subpackages defined in the latest iterations of the previous control system, a series of Classes executed by every single one of these is suggested. - Reactive Control The reactive control, defined as a set of packages supporting this control structure, might be suggested as a model of Classes executed by each one of these packages. In Fig. 19 and 20, this item is illustrated by subpackages “Navigation” and “Unblock”. Each one of these Classes must be defined and detailed by giving its features and functionality within the general design of the package. Either text, chart, sketch, or diagram may be useful to such purpose, e.g. a description of the Classe “Bordear_muro” is presented in Fig. 21. It shows the flowchart of occurrences and events that must be implemented by this Class. Navegacion Gesto_ Navegación Algoritmo_ Evadir Algoritmo_ Ir_a_Onjetivo Estados_ Sensores_ Requeridos Algoritmo_ Seguir trayectoria Algoritmo_ Vagar/Explorar Otros Fig 19. Navigation Subpackage ClassModel 3:C alcular dirección 10:Sistema Bloqueado) 5:Leer Sensores Proximidad 4:Hay cambio de estado? Velocidad consigna Algoritmo Seguimiento muros 9:Hay cambio de estado Evaluar sensores 7:Lectura Normalizada 6:Valores Leídos Interfaz_ Sensores Sensores 8:Loop Evaluar hasta Cambio de estado (b). Flowchart occurrences- Track Wall (Blocking Condition) Fig. 21. Interrelation and flowchart of occurrences. “Seguir_Muro” The analysis model of the robot system is illustrated in Fig. 22. There, each one of the Classes of the system is identified and the reactive control software architecture ensuing from the previous analysis is highlighted. Every single one of the Classes shall be reviewed in detail and presented in such a way that it must provide identification of its function and interrelation with the system. Due to the restrains of this paper, previous processes are not detailed, however they are clearly explained in the methodology. All the elements identified in the architecture (packages and subpackages) shall be closely specified and subject to strict analysis. During this stage, active involvement of both robotics engineers and computer engineers shall be interactive and well recorded. 7 Experticia Mapas Mapas Modelo Sensores Modelo Parámetros Parámetros Actuadores Robot Tareas Interfaz Usuario Modos de Control y Tareas Acople Gestor_Base_Datos IU I_Inp Gestor_ Supersor_ Tares Planificador Local Seguimiento_ Objeto Gestor_ Comportamiento I_Out Interprete_ Comandos Modelo Entorno Supervisor_Gestor Comportamientos Arrastre :Operador Planificador Global Objetvo Control Reactivo Estado Actual Busqueda_ Objetivo Planificador Otros Interfaz_Sensores Sistema Sensorial Interfaz Actuadores Evaluador_ Planificad_ Sistema_ Trayectoria Local Localizacion Sensores Algoritmos_ Especiales Control_ Reactivo Comandos Básicos Librerías SistemaControl del Robot Comandos Robot Interfaz_ Motores Capa Intermedia de Aplicación Motores Navegación Preventivos Desbloqueo Seguridad Evadir_ Obstaculos Evadir_ Abismo Sensores Capa Hardware del Sistema Vagar Seguir_ Evadir_ Muro Ostáculo Paro_ Emergencia Actuadores Fuga Seguir_ Trayectoria Fig. 25. Software Architecture –Levels of Abstraction- Ir_Zona_ Libre Salir_Zona_ Muerta Giro_ Emergencia Ir_a_ Objetivo Pasar_Zona_ Estrecha Fig. 22. Illustrating a Model of Classes of a Software Architecture for Robots Control Control Reactivo Navegación Seguridad D. Design DISEÑO Casos de Uso Diseño Identificación Sistemas y Subsistemas Identificación Nodos Subsistemas Desbloqueo Diagramas de Secuencia Identificar Clase Preventivos Estados Métodos Interfases Diagrama de Clases Diseño de Clases Atributos Dependencias Operaciones Modelo de Diseño Fig. 26. Subsystems of “Control_Reactivo” Fig. 23. Design Activities The steps suggested in MDASR for this stage of the Design is summarized in Fig.e 23. On the subsequent sections, brief descriptions of these steps are presented, highlighting the graphic charts as suggested by the methodology. c ) Refinement of the Solution Continuing with the example of reactive control, refinement of the solution implies to define a set of Classes as shown in Fig. 26, which in turn is to be split in accordance with the results obtained in previous stages (Fig. 27). Navegación 1) Architecture Design a ) Nodes Identification Two nodes conceived for the proposed architecture are presented graphically in Fig. 24. PC Usuario PC / µ p Robot Usuario Vagar Robot Zonas_Libres Seguir_Linea Atraccion_ a_Punto Arrastrar_ Objetos Fig. 24. Nodes configuration of the robot system b ) Subsystems Identification A diagram of proposed packages is presented in Fig 25 whose purpose is to identify clearly the packages and Classes to be defined in the Design stage. Fig. 27. Subsistemas de “Navegación” d) Identification of Subsystems Interfaces Visibility and interrelationship among Classes for particular cases of the designed system are presented in Fig. 28 and 29. 8 :Teclado :Pantalla :Parametros Arrastrar_Objetos :Seguir_ Muros :Calculo_ SetPoint :Procesad_ Sensores :Procesad_ Motores :Gestor_ Alarmas Orden Segumiento Leer sensores Proximidad Estado Sensores Leer_Distancia_Límite Arrastrar Evalua (no critico) Fig 28. Object Interface Representation Define dirección y ángulo Control Reactivo Valores consigan para cada motor Seguridad Navegación Paro_Emergencia Giro_Emrgencia Comandos Básicos . . Comandos Básicos . . . Fig 31. Sequences Diagram “SeguirMuro” Comandos Básicos f ) Classes of Design Model Preventivos Seguir_Muro Desbloqueo Zonas _Libres Evadir . . Fig 29. Interfaces “Relationship between Subsystems and Classes” The general design process concludes with a clear definition of Classes, their interfaces and essential relationship for the subsequent stage, where full understanding of the solution proposal (software architecture) is required. . Modelo_Entorno Supervisor_Gestor_ Comportamientos Interfaz_Usuario Planificador_ Global e ) Objects- Classes Design Classes and objects of the system might be identified from the use cases, and once more based on previous analysis. Identification - Classes of design by Use Cases is shown in Fig. 30 as an example of this step. An example of a sequence diagram leaned on a previous one as seen in the analysis stage is presented in Fig. 31. Pantalla Botones Comandos Teclado Estado_Actual Control Reactivo Sistema_Sensor Seguridad Preventivo Desbloque Navegacion Sistema Actuador Sensor_Infraroj o Sensor_Ultraso Sensor_.... Seguir Muro Seguir_Muro N-Aleatoria Atracción_Punt o Ir-Z_Libre Seguim_Muro Teclado Fig. 32. Diagram Example of Classes of Robot Software Architecture Pantalla Gestor Alarmas Botones Comandos Procesador_Mo tores Parametros Procesador_Sen sores Seguir_Muros Calculo Set Poin Fig. 30. Identification of Classes that intervene in the Use case “Seguir_Muro” Analysis model corresponding to the control architecture proposal is shown in Fig. 32. Some of the Classes are presented there aimed at providing a close insight of the general scheme of the architecture. As a subsequent step suggested in the chart of Fig. 23, the corresponding design of every Class shall be carried out detailing their own features, methods and characteristics. D) Implementation and Testing The general scheme proposed in the methodology MDASR for the stages of architecture implementation connected to the programming language selected and the steps to be followed in the test stage of the final software is presented in Fig. 33 and 34. 9 -Ficheros Fuente -Ejecutables Interfaces -Paquetes IMPLEMENTACION Implementar Clases Empaquetar componentes Componentes - Organizar - Definir dependencias Fig. 33. Diagram of activities proposed for “Implementation” of Control Software Architecture. -Modelos -Casos -Procedimiento -Componentes -Evaluación PRUEBA Planificar Describir casos Diseñar Describir e identificar procedimientos Implementar De integración Del Sistema Evaluar Fig. 34. Diagram of activities proposed for “Testing” V. CONCLUSION The Methodology for the Development of Robot Software Architecture (MDARS) has been conceived as a tool to shorten the communication gap existing between the actors involved in the process, such as the robotics engineer and the computer engineer. It has become an essential tool in the development of Robot Software Architectures. The methodology that allows specification, analysis, design and implementation of Robot Software Architecture leads the development stages of mobile robot systems in a natural way, which, due to their complexity, require identification of systematic processes that may be of any help when facing troubles emerged between the representation proposed by the robotics engineer, and the implementation itself, which is the task of the computer engineer. In order to exemplify one of the troubles, the following suggestion is given: given a basic robot, work in the development of a complex system that may satisfy the needs of the different actors by maximizing all the strengths of those experts involved in the process: the final user, who defines the problems intended to be solved; the robotics engineer, who defines the most accurate strategy, and the software engineers, who assist the design phase and implement the final system. Despite the fact that the design and development of robot architectures is a relatively mature process, identification of standard procedures to tackle such problem turned out to be a more complicated problem than expected, as great amount of tendencies and approaches emerged from knowledge engineering and methodologies of representation, conception and languages that offer parcial solutions to this issue. Since MDASR rely on the strategies of software engineering, and particularly, in the PU, it has proven to be a good choice to accomplish the goal proposed due to its intelligibility and standarization of all the aspects involved in the development process (Specification, Analysis, Design, Validation, Testing). In order to illustrate the methodology, a software architecture that may ensure its functioning in three operation modes (manual, semi-autonomous, autonomous) is presented. As a result, most of the typical applications of mobile robot systems are covered. After conceptual constraint prompted by hardware characteristics and purposes of the robot, the methodology process proposal is then illustrated with the purpose to present clearly every single one of the steps and methods through a standard language (UML). The stages considered of high relevance are explained in further detail in order to achieve a more solid and fluid communication between the robotics engineer (who proposes and defines the architecture) and the team in charge of developing in fact the software system itself (who implements the system). For that reason, the systematic process is detailed in the specification stage stressing on the needs and expectations proposed in the architecture. Likewise, the analysis stage implies a closer involvement between the robotics engineer and the engineers in charge of software development, since the conceptual solution of the architecture is grounded on this stage, thus allowing a more immediate participation to those engineers involved by using, both of them, the right and easy-to-follow charts, diagrams and languages. During the design stage, the stress lays on the presentation of charts and diagram oriented towards the interests of the software engineer, and thus, Classes and packages identification make use of a more software-like language. The elements introduced as examples of such stage are conceived to illustrate the concept. They require, however, an exhausting development, which implies a more specific and specialized team work. Although the implementation and testing stage are assumed in the methodology, they also require participation of specialists and the application of a programming language consistent with the needs and characteristics of the architecture. VI. REFERENCES [ I ] Brooks, Rodney. "A Robust Layered Control System for a Mobile Robot". IEEE Journal of Robotics and Automation, Vol. 2, No. 1, March 1986, pp. 14-23; also MIT AI Memo 864, September 1985. [2] Brooks, Rodney A. "Elephants don't Play Chess". Robotic andAutonomous Systems 6. 1990. [3] Arkin, Ronald C. "The impact of Cybernetics on the Design of a Mobile Robot System: A Case Study". IEEE Transactions on System, Man and Cybernetics. Vol. 20. N° 6. 1990. [4] Ridao, P.; Batlle, J.; Amat, J.; Roberts, G.N. "Recent trends in Control architectures for autonomous underwater vehicles". InternationalJournal of Systems Science, vol. 30. No 9, pags.1033-1056, Sep. 1999. http://eia.udg.es/~pere/publicacions.htm. [5] Ridao P., Carreras M., Batlle J., Amat J. "O2CA2: A New Hybrid Control Architecture For A Low Cost AUV". Control Application in Marine Systems CAMS'2001. Scotland (UK), 2001. http://eia.udg.es/~pere/publicacions.htm. [6] Vilchis, A.; Troccaz, J.; Cinquin, P.; Masuda, K.; Pellissier, F. "A New Robot Architecture for Tele- 10 echography". IEEE Transactions on Robotics and Automation, , Volume: 19, Issue: 5, Year: Oct. 2003. pp. 922- 926. [7] Lopera Luís. "Arquitectura de Navegación, Planificación y Supervisión para un Dirigible no Tripulado". Master Thesis, Universidad de los Andes, Bogota, Colombia, 2005. [8] Dongqing, shi. "Aerial Robot Navigation in Cluttered Urban Environments". PhD Thesis, The Florida State University, 87pp, Florida, EEUU. [9] Surla, Dusan; Konjovic, Zora; Rackovic, Milo. "UML Specification of the System for Gernerating Simbolic Models of Robotic Mechanism Dynamics". 13th ISPE/IEE International Conference on CAD/CAM, Robotics / Fabricatories on the Future - Pereira 1997. [10] Bryson, Joanna; McGonigle, Brendan "Agent Architecture as Object Oriented Design". Laboratory for Cognitive Neuroscience and Intelligent Systems, Edinburgh University, Edinburgh EH8 9JZ, UK, 1997. [11] Muñoz L., José L. "Control en Robótica Móvil. Arquitectura y Metodología". PHD Thesis. Universidad de Murcia. Industrial Automation, Electricity and Electronics Department. 1998. [12] Londoño O, Nelson; Tornero, Josep, "Análisis de la Metodología HOOD para la Implementación de Arquitecturas Aplicadas a Robots". VIII Latinamerican Congress on Automation Control, Viña del Mar, Chile, Nov. 1988. HOOD_Afrb.doc [13] Montano, Luis; Garcia, F. José; Villa, José. "Using the time Petri Net Formalism for specification, Validation and Code Generation in Robot Control Applications". Universidad Zalamanca - Universidad la Rioja, Jul, 1999. [14] Drake, José M.; Medina, Julio L. "Robot Teleoperado:Ejemplo UM-Mast". Grupo de computación y tiempo Real, Universidad de Cantabria. 2001. Available on the Web: <http://mast.unican.es /umlmast/ umlmast-example.pdf>. [Last access on Feb. 2009]. [15] Hornby, G.S.; Lipson, H.; Pollack, J.B. "Generative representations for the automated design of modular physical robots" IEEE Transactions on Robotics and Automation. Volume: 19, Issue: 4. Aug. 2003. pp 703719. [16] Farley , Rochard.st "Software Enguneering Concepts". McGraw-Hill, 1 ed. 1987. [17] Sommer, Ian. "Ingeniería de Software". 2a Ed. Addison WesleyIberoamericana. 1988. [18] Cerrada, J. A. y Collado, M. "Introducción a la Ingeniería del Software". UNED, 1995. [19] Sommerville. I. "Software Engineering". AddisonWesley: Reading, MA, 5th edition, 1995 [20] Pressman, Roger S. "Software engineering". IEEE Computer Society, 1997. pags. 57-74. [21] Zavala R. 2000. "Diseño de un Sistema de Información Geográfica sobre internet". Tesis de Maestría en Ciencias de la Computación. Universidad Autónoma Metropolitana-Azcapotzalco. México, D.F. [22] Brengge, Bernard; Dutoit, Allen H. "Ingeniería de Software Orientada a Objetos". Pearson Educación,, Mexico, 2002. [23] Silva, Darío Andrés; Mercerat, Bárbara. "Construyendo Aplicaciones web con una metodología de diseño orientada a objetos". http://www.unab.edu.co/editorialunab/revistas/rcc/pdfs/r2 2_art5_c.pdf. [24] Farley , Rochard. "Software Enguneering Concepts". McGraw-Hill, 1st ed. 1987. [25] Giret Boggino, Adriana. "Anemona: Una Metodologíia Multi-Agentepara Sistemas Holónicos de Fabricación".PHD Thesis, Universidad Politécnica de Valencia; Valencia, Spain. July 2005. [26] Software Engineering Institute. Available on the Web: <http://www.sei.cmu.edu/>, [Last access on July, 2009]. [27] The Rational Edge. Available on the Web:<http://www.therationaledge.com/>, [Last Access on July, 2009]. [28] Douglass, Bruce Poewl. "DOING HARD TIME. Developing Real-Time Systems with UML, Objects, Frameworks, and Patterns". Addison- Wesley, 1999. [29] Rumbaugh, J. Et al. "Object Oriented Modeling and Design". Prentice Hall. 1991. [30] Jacobson, I.; Christerson, M; Jonson, P; Overgaard, G. "Object Oriented Software Engineering - A Use Case Driven Approach". Addison-Wesley, Reading, 1992. [31] Booch, Grady. "Object Oriented Analysis and Design". 2nd ed. Benjamin Cummings 1994. [32] OMG "Unified Modeling Language Specification. Retrieved" March 18, 2003. Available on the Web: <http://www.omg.org/technology/documents/ formal/uml.htm>, [Last Access on March. 2009]. [33] Shalloway, Alan; Trott, James R. "Design Patterns Explained: A New Perspective on Object Oriented Design". 2a Ed.Addison Wesley Professional, 2005. [34] Jacobson, Ivar; Booch, Grady; Rumbaugh, James. "El Proceso Unificado de Desarrollo de Software". Adison Westley. 2000. [35] Booch, G; Jacobson,, I y J. Runbaugh. "El Lenguaje Unificado de Modelado". México : Addison Wesley, 1999. [36] Rumbaugh, James; Jacobson, Ivar; Booch, Grady. "El lenguaje Unificado de Modelado, Manual de Referencia". Racional Software Corporation. 2000. [37] Booch, Grady; Rumbaugh, James; Jacobson, Ivar "The Unified Modeling Language User Guide" 2nd Ed. Addison Wesley Professional. 2005. [38] OMG "Unified Modeling Language Specification. Retrieved" March 18, 2003, from <http://www.omg.org/technology/documents/formal/ uml.htm>. [39] European Space Agency, HOOD Working Group, "HOOD Reference Manual". Issue 4.0, 1995. HOOD, User Group. "HOOD User ". Issue 1.0, 1996. [40] K-Team. Available on the Web: <http://www.kteam.com/kteam/home.php>. [Last access on. 2009]. VII. BIOGRAPHY Nelson Londono Ospina was born on July 31, 1955, in Medellin, Colombia. He is an Electronics Engineer graduated from Universidad de Antioquia (University of Antioquia) of Medellin, Colombia, who has practiced his profession as a Maintenance and Design Engineer in different companies throughout the country (Colombia). At present, he is an Associate Professor of Universidad de Antioquia in the electronics, automation and control fields of the Electrical Engineering department. Engineer Londono Ospina is a member of the Electric Power Efficiency Research Team- GIMEL (Grupo de Investigación en Manejo Eficiente de la energía Eléctrica GIMEL), and is in charge of the automation and robotics area. He has also been a member of research projects carried out with some colleges in Colombia. He has completed doctorate studies at Universidad Politecnica de Valencia (Spain) and is currently studying at Universidad del Valle (Colombia).
