Revista Avances en Sistemas e Informática

ISSN: 1657-7663
avances@unalmed.edu.co
Universidad Nacional de Colombia
Colombia

Londoño Ospina, Nelson de J.

Arquitectura software para robots móviles aplicando la metodología MDASR
Revista Avances en Sistemas e Informática, vol. 6, núm. 3, diciembre, 2009, pp. 133-144
Universidad Nacional de Colombia
Medellín, Colombia

Disponible en: http://www.redalyc.org/articulo.oa?id=133112611012

Cómo citar el artículo

Número completo
Sistema de Información Científica
Más información del artículo Red de Revistas Científicas de América Latina, el Caribe, España y Portugal
Página de la revista en redalyc.org Proyecto académico sin fines de lucro, desarrollado bajo la iniciativa de acceso abierto
 Arquitectura software para robots móviles aplicando la metodología 
MDASR 

Software architecture to mobile robots using the methodology 
MDASR 
Nelson de J. Londoño Ospina. PhD. 
Profesor Departamento de Ing. Eléctrica, y miembro del grupo de investigación en manejo eficiente de la energía 
GIMEL. Facultad de Ingeniería, Universidad de Antioquia, Medellín.Colombia. 
nlondono@udea.edu.co 

Recibido para revisión 24 de Abril de 2009, aceptado 23 de Octubre de 2009, versión final 25 de Noviembre de 2009 

Resu men —Se  a p lica   la   M et od ología   d e  Desa r r ollo  d e  ­Lenguaje  Unificado  de  Modelado­  [3]­[4]­[20]­[19], 
Ar quitecturas Software para Robots –MDASR­, como herramienta  complementados con métodos empleados en Ingeniería Software 
de especificación, análisis y diseño de una Arquitectura de Control  [12] [6]. 
R ea ct iva .  L a   met od ología  se  a p oya   en   mét od os  y  lengu a jes 
a mplia ment e  a d op t a d os  como  el  P U  (P r oceso  Un ifica d o  d e  Con  base  en  la Arquitectura  Reactiva  aplicada  a  un  robot 
Desarrollo de Software) y UML (Lenguaje Unificado de Modelado),  comercial, se ejemplifica cada uno de los pasos propuestos en la 
apropiando conceptos y métodos empleados en Ingeniería Software  metodología,  enfatizando en  los diagramas  de  casos de  Uso, 
que permiten ilustrar la arquitectura, y presentando las etapas 
de  análisis  y  diseño  de  forma  general  mediante  los  pasos 
Palabras Clave—Robótica, Arquitectura de Robots, Ingeniería de 
concebidos en MDASR. 
Software, Proceso  Unificado de  Modelado. 
Es importante aclarar que, por limitaciones de espacio, todos 
Abstract—Adopting  a  methodologica l  str ategy  that  covers  the  los casos de uso, diagramas de diseño y análisis no pueden ser 
different stages  of the development  of a system,  the Methodology  detallados,  presentando  solo  algunos  de  los  esquemas  y 
of Development of Architectures Software  for Robots ­ MDASR­, 
resultados obtenidos en el desarrollo del proyecto. 
it  is  applied  as  tool  of  specifica tion,  analysis  and  design  of  a 
Reactive Control Architecture. The methodology rests on methods 
and  languages  widely  adopted  as  the  PU  (Pr ocess  Unified  of 
II.  M DASR  ­  DIAGRAM A  GENERAL 
Development  of  Softwar e)  and  the  UM L  (Language  Un ified  of 
Shaped)  and  adapting  concepts  of  methods  used  in  Engineering 
Softwar e. 
La Metodología de Desarrollo de Arquitecturas Software para 
Keywords—Robotics, Robots  architecture,  Software  engineering,  Robots  (MDASR)  [14],  es  una  metodología  concebida  para 
Unified  Modeled  Process, software  Development.  facilitar la comunicación entre el ingeniero en Robótica (quien 
concibe  la  arquitectura)  y  el ingeniero  de  sistemas  (quien  la 
I .  I NTR O DUC C IO N  desarrolla),  se  apoya  en  los  paradigmas  de  la  ingeniería  de 
software, adoptando métodos de especificación, análisis, diseño 

T  omando  como base  una propuesta  Metodológica   para 

Arquitecturas Robot [13], que cubre las diferentes etapas 
del desarrollo de un sistema, se presentan como caso de estudio 
e implementación estándares y el lenguaje de representación 
más relevante actualmente como es UML. La figura 1 ilustra, de 
forma gráfica, la metodología, que proponen los pasos a seguir 
la arquitectura reactiva aplicada a un sistema robot, siguiendo  en la concepción, análisis, diseño e implementación. Se toma 
los  pasos propuestos en MDASR  (Metodología de Desarrollo  como  caso  de  estudio  e  ilustración  de  la  metodología,  una 
de  Arquitecturas  Software  para  Robots  [14]­[15],  cuya  Arquitectura Reactiva aplicada a un robot comercial [10]. 
característica  más  importante  es  que  se  apoya  en  métodos  y  El  objetivo  es  que,  siguiendo  los  lineamientos  de  la 
lenguajes ampliamente aceptados por la comunidad científica y 
metodología, la solución propuesta por el Ingeniero en Robótica, 
adoptados en diferentes áreas del conocimiento, como lo son: el  "Arquitectura Reactiva", sea representada de forma estándar,
PU (Proceso Unificado de Desarrollo de Software) [9]  y el UML 

Revista Avances en Sistemas e Informática, Vol.6 No.3, Diciembre de 2009 ISSN 1657­7663 
134  Revista Avances en Sistemas e Informática, Vol.6 No.3, Diciembre de 2009 ISSN 1657­7663 

guiada por un procedimiento sistemático, como se ilustra en la  programador, quien en última instancia convertirá la arquitectura 
figura 1, para obtener un sistema completamente especificado  en un conjunto de elementos software. 
por Casos de Uso, Analizado y Diseñado siguiendo un conjunto 
En el ejemplo se toma cada paso y se desarrolla hasta un nivel 
los pasos, bajo un lenguaje y procedimiento que llegue hasta el 
que sea fácilmente comprendido por el ingeniero de sistemas 

VI SI ON G ENERAL  Preliminares: 

DEL SIST EM A  Entorno, 
“El Rob ot­E ntor no”  Considera ciones, 
Usuario  Arquitectura General 

Propósito 
E SP EC IFI CACI ON 
Objetivo 
de la Ar quitectur a  S.Actual 
Usuario 
S.Propuesto 
Requisitos(CU) 

­ Visión   Gen er al d el Sistema Rob ot 

In ter fa z 
­ Ar qu itectu r a ­ ob jeto de desa r r ollo 
Usua r io 
­ Req uisitos (Casos d e Uso) 

M O DELO  
(CASOS DE USO)  Arquitectura. 
Paquetes 
ANAL ISIS 
Usuario  Sub­Paquetes 
Arquitectura  Softwa re 
Clases 
Modelo Anal 

Desarrollador 
­ Sistemas o Paq u etes 
Arq u itectu ra  Softwa r e 
­ Su bPaq u etes y Sub sistema s 
de An álisis 
­ Identifica r. Clases Aná lisis 
­ Dia gr ama  d e In ter acción 

Arquitectura 
DISEÑO  Clases/Objeto 
M ODELO  DE ANALISIS 
Desarrollador  s 
Arquitectura Softwa re para 
Modelo 
Robots 
Clases 
Diseño Clases 

­ Nod os 
­ Sistema s y Sub sist emas  M O DELO DE DISEÑO  
­ Casos de Uso Diseñ o  Arquitectura Softwa re 
­ Clase (d ia gr am s) 

Desarrollador 
IM PLEM ENTACION 

­ Clases, 
­ Compon entes  ARQUITECTURA 
Usuario  ­ Emp aq u etar   SOFTWARE 
­ Depen d encia s 

Figur a  1.  Diagrama  general  de  MDASR. 

III.     ARQUITECTURA  REACTIVA  Como se dijo anteriormente, para ilustrar la metodología, se 

seguirán  los  pasos  propuestos  por  la  MDASR,  aplicados 
específicamente a una la arquitectura reactiva. 
En el campo de las arquitecturas software para robots, son 
muchas las propuestas enfoques y tendencias de control que  A. Especificación - Control Reactivo 
se proponen. Es así como se cuenta con una gran cantidad de  El control reactivo, se concibe como una serie de módulos 
arquitecturas con orientaciones de acuerdo  a las técnicas de  elementales, capaces de producir acciones de respuesta directa, 
procesamiento  de información,  algoritmos  de evaluación  de  en concordancia con la información sensorial disponible, este 
decisiones, etc. Unas de las mas recurrentes, cuando se trata de  tipo de acción puede ser ejecutada como respuesta fija, ante un 
sistemas  de navegación  y  exploración,  son las  arquitecturas  proceso  de  sensado  (proceso  reactivo  o  instintivo)  o  por 
reactivas [5]­[7]­[16]­[21]­[17]­[11]­[18], se basan en modelos  ejecución  refleja,  después  de  ser  aprendido    (procesos 
biológicos y de acciones, que explican el comportamiento de  reflexivos). 
diversos organismos vivos de tipo estímulo respuesta; así, el 
robot percibe el mundo y ejecuta, en respuesta, la acción que  El modulo de control reactivo es el encargado de ejecutar los 
parezca más apropiada [17]. En este tipo de arquitecturas, la  comportamientos  elementales  que  requieran  los  módulos 
información percibida no se integra ni se asocia a ningún modelo  superiores, entendiéndose como comportamientos elementales 
del mundo.  aquellos conformados por un ciclo de sensorización, acciones 
elementales  y  combinación  de  ellas.  Un  comportamiento
 Arquitectura software para robots móviles aplicando la metodología MDASR – Londoño.  135 

elemental se define como un dispositivo computacional, que  •  Velar por la seguridad 
interpreta  datos  sensoriales,  los  procesa  y  produce  una  •  Resolver problemas de atascamiento y errores producidos 
respuesta [8].  en el sistema (Software/Hardware). 
Visión  general  del  sistema:   El  bloque  Reactivo  es  el  •  Informar las fallas ocasionadas a los niveles superiores. 
encargado de ejercer propiamente el control directo del Robot.  Sistema actual. Se cuenta con el sistema Khepera básico, de 
Su objetivo fundamental es garantizar su navegación, operado  consecución comercial [10]. 
por  un  sistema  de  Control  Reactivo  (CR),  basado  en  Sistema  Control  reactivo  propuesto.  La  Arquitectura 
Comportamientos [1].  Sus características principales son:  Software  propuesta,  debe  implementar  el  conjunto  de 
operaciones  que  garanticen  que  el  sistema  ejecute  control 
•  Permitir ejecución de comportamientos elementales. 
reactivo,  el  Caso  de  Uso  principal  es  precisamente 
•  Ser  flexible,  lo  que  permite  incluir  comportamientos  “Ejecutar_Control_  Reactivo”,  el  cual  ejecuta  las  acciones 
adicionales.  necesarias  para garantizar  dicho  comportamiento  y, por  sus 
•  Permitir que su implementación soporte una gran variedad  características, requiere un conjunto de comandos considerados 
de técnicas, incluyendo reglas heurísticas, redes neuronales,  Casos de  Uso que  extienden el principal.  Por esta  razón, es 
lógica borrosa algoritmos genéticos, etc.  necesario  realizar  una  especificación  mas  detallada  de  este 
•  Los  comportamientos  elementales  son  conmutados  de  sistema, que conlleve a definir un diagrama de casos de uso 
acuerdo a los requerimientos del Usuario  como se ilustra en la figura 2. 
Propósito del sistema CR: En general este bloque recibe las  En  el  esquema  propuesto,  el  actor  puede  ser  un  operador 
órdenes del USUARIO y garantiza su ejecución; para ello, toma  humano, un computador o simplemente un Caso de Uso de un 
la información sensórica requerida, la procesa, y envía una orden  sistema de control más general denominado “Ejecutar_Control 
de Acción, resultado del procesamiento del Control Reactivo.  _Reactivo”. 
Alcance del sistema CR: En general, el control reactivo debe:  Caso  de  Uso  “Ejecutar  Control  Reactivo”:   La  figura  3 
•  Garantizar funcionamiento reactivo  propone el diagrama de Casos de Uso de una Arquitectura de 
“Control Reactivo”. 
Ejecutar_Rectiva 
<<Include>> 

<<Include>> 
Leer 
Sensores 

Usuario 

Mover 
Motores 
Robot 
Figur a  2.  Caso  de  Uso  “Ejecutar_Control_Reactivo” 
Activar/Desactivar_ 
Modo _Reactivo 

<<Extend>>  Tomar 
Info_Sensor  <<Include>> 
es 

Evaluar_Info 
_Sensorica 
<<Extend>> 

Evaluar  Seguridad  <<Include>> 

comportamiento_a_ 
Activar  Leer 
Sensores 
Preventivo 
<<Extend>>  <<Extend>>  <<Include>> 
Rectiva  Activar_ 
Comportamiento 
Ejecutar  Desbloqueo 
<<Extend>> 
tarea 
<<Include>> 
<<Extend>>  Evaluar 
<<Include>>  <<Include>> 
<<Extend>> 
Navegación 
Eject.Modo  Calcular_ 
Automo  Comportamietnos 
Acion_Motores 

<<Include>> 
Gestion_ 
<<Extend>>  <<Extend>>  Fallas 

Deliberativo  Robot 
Gestion_ 
Alarmas 

<<Include>> 
Usuario  Mover  Mover 
Robot  Motores 

Figur a  3.  Diagrama  de  Casos  de  Uso  detallado  Ejecutar_Control_Reactivo”

136  Revista Avances en Sistemas e Informática, Vol.6 No.3, Diciembre de 2009 ISSN 1657­7663 

Este  tipo  de  diagramas,  es  producto  de  un  proceso  de  •  El robot permanece parado hasta tanto se de la orden de 
especificación previo, que por limitaciones de espacio no se  Arrancar. 
detalla en este artículo, en el que se han detallado y justificado  •  Debe permitir comportamientos adicionales, lo que exige 
los diferentes Casos de Uso que lo conforman y además, debe  modularidad y estandarización de los objetos. 
ir acompañado de una descripción, Identificación, Análisis y 
Refinamiento de cada uno de dichos Casos de Uso [15]. 
•  Debe permitir cambiar los comportamientos en el instante 
que lo requiera el usuario. 
Desde  una  concepción  general,  "Control  Reactivo"  debe  •  Debe  permitir  una  comunicación  con  el  usuario,  para 
cumplir una serie de funciones que se resumen en el diagrama  informarlo del estado del sistema cuando lo requiera. 
de  casos  de  uso,  pero  que  para  efectos  de  claridad,  en  las 
•  En el instante que el usuario decide parar, todas las tareas 
primeras etapas de especificación, es conveniente definir con 
que se estén ejecutando en el momento deben ser paradas y 
un poco mas de detalle. Por ejemplo, el control reactivo debe: 
se debe dar orden de paro a los actuadores. 
•  Iniciar el modo de control Reactivo en el momento de recibir  •  Permite desactivar todo el sistema de control reactivo. 
la orden correspondiente.  •  Debe detectar las inconsistencias y fallos del sistema. 
•  Cargar comportamiento  deseado por el usuario  o definir 
Análisis de Requerimientos no Funcionales: Son aquellas 
comportamiento por defecto. El tipo de comportamiento está 
exigencias del sistema que no tienen efectos funcionales, pero 
definido  de  acuerdo  a  las  necesidades  del  usuario  o  en 
que ayudan a identificar necesidades o restricciones, para el 
función de la respuesta en la evaluación de la información 
ejemplo: 
sensorial. 
•  Adquirir los datos de los sensores.  •  El sistema debe ser confiable, versátil y tener la posibilidad 
•  Evaluar la información recibida. Implica definir el algoritmo  de  interactuar  con  diferentes  tipos  de  Robot  o  vehículos 
de evaluación y los criterios de decisión definidos por el  implemetado en una plataforma. 
usuario  •  El sistema de control obedece a un comportamiento reactivo, 
•  Definir los comportamientos que deben se tenidos en cuenta  por  lo  cual  su  respuesta  está  sujeta  a  la  velocidad  de 
de  acuerdo  a  la  misión  y  las  condiciones  de  el  medio  procesamiento,  la  simplicidad  de  los  algoritmos  y  a  la 
(Información sensada).  confiabilidad y sencillez de los sensores. 
•  Activar el comportamiento.  •  Debe funcionar en diferentes tipos de ambiente, con una 
•  Evaluar el comportamiento activo y definir su continuidad o  gran variedad de sensores y actuadores. 
cambio de estado.  •  Debe permitir incorporar otros módulos de comportamiento. 
•  Calcular la información de salida del comportamiento, como  •  Debe permitir involucrar, en los comportamientos, cualquier 
una  acción  de  velocidad  lineal  y  curvatura  (Acción  de  tipo  de  sistema  de  control:  PID,  Fuzzy,  Neuronal,  etc. 
Control), en parámetros normalizados y darlas ordenes a los  (Comportamientos reflejos). 
motores.  •  Velar por la seguridad 
•  Ejecutar el algoritmo de gestión de fallos, cuando se detecte  •  Resolver problemas de atascamiento y errores producidos 
una condición no prevista.  en el sistema (Software/Hardware). 
También, se identifica, en la especificación del sistema reactivo  •  Cada uno de los comportamientos puede ser considerado 
esperado,  una  serie  de  requerimientos    de  Comportamiento  como una forma de Control del Robot. 
(Behavioral), que ayudan a identificar, con mayor nivel de detalle,  •  Su salida debe ser determinística 
los elementos que definen el sistema de control deseado. Así,  •  Cada uno es completamente independiente 
por ejemplo:  •  Los comportamientos no poseen memoria. 
•  El  Software  debe  poder  iniciar  en  cualquier  instante,  B. Refinamiento Caso de Uso “Ejecutar Control Reactivo” 
independiente del estado del Robot.  Una revisión general de Identificación y Análisis de Casos de 
•  La  señal  de  Activar  debe  iniciar  el  proceso  de  Uso, implica detallar más la especificación, para muchos casos 
comportamiento reactivo del robot e  iniciar todas las tareas  de  uso,  que  deben  ser  iterativamente  refinados,  ejemplo: 
que se requieran. Por defecto arrancará en una configuración  “Navegación”, “Desbloqueo”, “Preventivo” , “Seguridad”, etc. 
básica. Entonces, al iniciar:  Las figuras 4 ilustran el resultado del proceso de refinamientos 
•  Habilita comportamiento Cargado.  del caso de uso “Navegación”.
•  Calcula  permanentemente  la  velocidad  relativa  Robot­ 
Obstáculo 
•  Opera permanentemente en un modo protección (Prioridad). 
 Arquitectura software para robots móviles aplicando la metodología MDASR – Londoño.  137 

C. Especificación Comportamientos  del paquete, requiere ser detallado y, al igual que el anterior, 

Como  se  observa  en  la  figura  4,  otro  elemento  básico  de  debe ser especificado con mayor precisión. Producto de este 
una arquitectura de control, para un sistema robot, es el Caso  procedimiento, se presenta el diagrama de Casos de Uso que 
de Uso  Comportamiento, pues es  posible que el  robot tenga  implementa  este  paquete,  figura  5.  Como  se  observa,  es 
la capacidad de actuar, no solo en operación reactiva pura, sino  dispendioso,  pero  necesario,  realizar  todos  los  procesos  de 
obedeciendo  a  comportamientos  [2].  El  control  de  identificación, análisis y refinamiento de cada uno de los casos 
comportamientos del sistema, propuesto como objetivo básico  de uso contemplados en el sistema. 

Otros 
<<Include>> 

<<Extend>>  Braitenberg 
Activar_ 
<<Extend>> 
Comportamiento 
<<Include>> 

Navegacion  <<Extend>> 
Vargar­ 
<<Extend>>  Explorar  <<Include>> 
<<Extend>>  Leer 
Sensores 
Seguir  <<Include>> 
Rectiva 
Trayectoria 
<<Extend>> 
<<Extend>>  <<Include>> 
Atraccion a 
<<Extend>> 
Punto 
Ejecutar 
tarea  <<Extend>>  <<Include>> 
Ir Zona 
<<Include>>  Libre 

Eject.Modo  <<Include>> 
Automo 
Misma  Robot 
Usuario  Direcion 

Mover  <<Include>>  Mover 

Robot  Motores 

Figur a  4.  Diagrama  de  Casos  de  uso  detallado      "Navegación" 

Fusionar 

Combinar 

Conmutar
Gestionar 
Comportami 
etnos 
Reactivo 

<<Extend>> 
<<Include>> 
Ejecutar 
Arrastrar 
Comportamietnos 
Objetos 
<<Extend>> 
<<Extend>>  Seguir 
<<Extend>>  <<Extend>>  Trayectoria 
Leer 
Ejecutar  Tareas  <<Extend>>  Acoplar  Sensores 
tarea  Basicas 
<<Include>>  <<Extend>> 
Seguir 
<<Extend>> 
Objeto 
Eject.Modo 
Automo  Buscar 
<<Extend>>  Objetivo 
Usuario 
Otros 
Robot 
Mover 
Robot 

<<Include>> 
Mover 
Motores 

Figur a  5.  Diagrama  de  Casos  de  uso  detallado  que  implementa  “Ejecutar_Comportamientos” 
138  Revista Avances en Sistemas e Informática, Vol.6 No.3, Diciembre de 2009 ISSN 1657­7663 

D. Análisis - Identificación de Paquetes de Análisis -Por casos Sistema_Control_Reactivoi 

de uso 
Sist_Navegacion 
En este punto, cada uno de los paquete de análisis del sistema,  Sist_Desbloqueo  Sist_Preventivo  Sist_Seguridad 

va de la mano con el tipo de Caso de Uso que resuelven, así, por 
ejemplo , se define un paquete denominado “Sist_Navegación, 
que  implementa  todos  los  casos  de  uso  relacionados  con  la 
navegación del robot en modo reactivo. En la figura 6 se ilustra  Figur a  7.  Arquitectura  por  paquetes  de  Sistema  de  Control  Reactivo 
el paquete y sus casos de uso que implementa. 
En la figura 7 se presenta el sistema de control reactivo que 
E jecutar_c ompo rta  cobija  las  cuatro  funciones  fundamentales  de  un  sistema  de 
m ie tnos_na ve gac ió n 
control reactivo como el propuesto. 
S ist _ N a ve g a c io n 
E je c _ C o m p_ 
B ra i te n b er g 
Cada  uno  de  los  sub­paquetes,  contiene  las  clases  y 
E je c _ C om p _V 
elementos  necesarios  para  implementar  las  acciones 
a rg a r­ E x p lo ra r 
correspondientes a su función específica. 
E je c _ C om p _ 
S e g u ir 
T ra y e c to ria 
E. Identificación de Clases 
…  Tomando como base los paquetes y sub­paquetes, definidos 
…  en las últimas iteraciones del sistema de control anterior, se 
… 
propone una serie de clases que implementarán cada uno de 
ellos. 
Figur a  6.  Diagrama  de  Casos  de  uso  detallado  que  implementa  A Partir de los (Sub) Paquetes de Análisis: Cada sub­paquete, 
“Sist_Navegación”  en función de sus características y particularidades definidas 
De forma similar, se plantean los otros paquetes del sistema  en las etapas anteriores, puede ser implementado mediante un 
de control reactivo que se resumen el numeral siguiente.  conjunto de clases que se identifican en esta etapa del proceso 
Arquitectura por paquetes:  En el proceso de subdivisión  (en muchas ocasiones, están apoyados por el esquema general 
del sistema software, el control reactivo puede ser clasificado  presentado por el ingeniero en robótica) 
de acuerdo a las características específicas de la función que  ­ Control  Reactivo: El control  reactivo, definido  como un 
cumple,  en  la Arquitectura  propuesta.  En  nuestro  caso,  se  conjunto de  paquetes que apoyan  esta estructura  de control, 
subdivide  dicho  control  en  paquetes  que  desempeñan  puede ser propuesto como un modelo de clases que implementan 
funciones específicas, en el contexto de la arquitectura y que,  cada uno de estos paquete, en la figura 8 se ilustra algunos de 
por  sus  características,  implementan  los  casos  de  uso  estos paquetes, obtenidos mediante el procedimiento propuesto 
relacionados con su función.  por la metodología. 
Na vega cion  Desbloqueo 

G esto_  E stados_ 
G estor _ 
Na vega ción  Desbloqueo  Estados_ 
Sensores_ 
Senso res_ 
Requeridos 
Requeridos 

A lgoritm o_  Algoritm o_  Algoritm o_  Algoritm o_  Algoritmo_  Algoritmo_ 
E vadir  Ir_a_Onjetivo  Seguir  Otros 
Va ga r/E xplora r  Salir_Zonas  Bordea_ Muro  Otros 
tra yectoria  
_ M uertas 

P reventivo  Segurida d 

Gesto_  Estados_  Gesto_  Estados_ 

P r eventivo  Sensores_  Segur ida d  Sensores_ 
Requeridos  Requeridos 

Algoritm o_  Algoritm o_  Algoritm o_  Algoritmo_  Algoritmo_  Algoritmo_ 

Otros  Otros
Ir_a_Zona_  Alejarse_de_  Bor dea r_  Giro rapido  Alejarse_  Eva dir_Ra pid 
Libre  Obstaculo  Obsta culo  Rapído  o 

Figur a  8.  Modelo  de  Clases  Sub­paquete:  Navegación,  Desbloqueo,  Preventivo,  Seguridad 
 Arquitectura software para robots móviles aplicando la metodología MDASR – Londoño.  139 

A Partir de los Casos de Uso: En esta etapa, tomando como  identifican clases y su interrelación. En la figura 9, se ilustran 

referencia  los  casos  de  uso  definidos  anteriormente,  se  algunos modelos de clases propuestos para la Arquitectura: 

Iniciar 

Velocidad 
Límite 

Velocidad 
actual  Mover_Por 
_Velocidad 
Velocidad 
Generador Set  Mover  Velocidad  actual 
IU­Iniciar  Motores (n)  Límite 
Poin 

Mover 
IU­Fijar  Actualizar_  Actualizar  Generador Set  Motores (n) 
velocidad  Velocidad  Velocidad  Poin 

Generador Set  Mover 
Poin  Motores (n)  Motores  Generador Set  Mover 
Usuario  IU­Fijar  Poin  Motores (n)  Motores 
IU­Iniciar  Actualizar 
velocidad  Velocidad 
Usuario 

Velocidad  Velocidad 
Límite  actual 
Velocidad  Velocidad 
actual  Límite 

“Modo Teleoperación”  “Moverse por velocidad” 
Seguir_Muro 
Base Datos 
Trayectoria 

Evaluar 
sensores  Ejecutar_ 
Trayectoria  Velocidad 
Comado  I_Sensores  actual 
Seguir Muro 

M over 
Velocidad  Motores (n) 
consigna  Velocidad 
Algoritmo  Límite 
Generador Set 
Seguimiento 
Poin  IU­Fijar  Evaluar 
muros 
Trayectoria  Obstaculo 
IU_Sensores (n) 
Generador 
Trayectoria 
Generador Set  IU.Actuadorte(n) 
Poin 

Motores 

Generador Set  Mover 
Poin  Motores (n) 
Usuario  Seguir muro  Generador Set  IU.Actuadorte(n) 
IU­Fijar  Poin  Motores 
Sensores 
I_Sensores  Trayectoria 
Usuario 

Generador 
Evaluar 
Trayectoria 
Obstaculo  Sensores 
Velocidad  Algoritmo  Evaluar 
consigna  Seguimiento  sensores  IU_Sensores (n) 
muros  Base Datos 
Velocidad  Velocidad 
Trayectoria 
actual  Lí mite 

“Seguir_Muro”  “Ejecutar trayectoria” 
Figur a  9.  Identificación  de  clase  e  interacciones    Caso  de  Uso 

F. Interacciones Entre Objetos de la Arquitectura - Diagrama ejecuta la orden seguimiento de muro. 

de Secuencias  •  El generador de Valor consigna (set point)  evalúa sensores: si 
El Diagrama de secuencias, correspondiente a cada uno de  no se detectan obstáculos, genera un valor de consigna igual 
los casos de uso, se ejemplifica en la figura 10, en el cual se  para los dos motores y lo envía a la interfaz Mover_Motores 
presenta    solo  el  caso  de  condición  normal  y  se  omite  la  •  Si detecta obstáculos, sigue una secuencia de pasos definido 
condición de  bloqueo y colisión.  por el flujo de eventos propuesto por la figura 10, que ilustra 
Caso de Uso "Seguimiento Muro" : Descripción textual del  la relación entre clases que actúan es este caso de uso, y 
flujo  de  sucesos  una propuesta inicial del flujo de eventos.
•  El usuario, mediante la interfaz (Gráfica, comando o botón), 
140  Revista Avances en Sistemas e Informática, Vol.6 No.3, Diciembre de 2009 ISSN 1657­7663 

1:Orden Seguir muro  2:Iniciar Seguir muro  13:Set Point Motores  13:Set Point Motores 

:Operador  Seguir muro  Interfaz Motores (n) 

Generador Set Poin 
Motores 

3:Calcular dirección 
12:Valores 
11:Leer Valores límite  Limite) 

10:Nueva consigana  5:Leer Sensores 
(Dirección y ángulos)  4:Hay cambio de estado?  6:Valores Leídos 
Proximidad 

Velocidad  consigna  9:Hay  Evaluar  7:Lectura  Interfaz_ 

Algoritmo  Sensores 
cambio  sensores  Normalizada  Sensores 
Seguimiento  de estado 
muros 

8:Loop Evaluar 
hasta Cambio 
de estado 

Flujo de sucesos ­ (Condición normal) 
Figur a  10.  Interrelación  y  flujo  de  eventos.  Caso  de  Uso  “Seguir_Muro” 

G. Modelo de Clases  En esta sección se presenta, someramente, los conceptos más 

El Modelo de Análisis de la Arquitectura de control Software  relevantes que han de considerarse, como ilustración en el marco 
para Robot, se presenta en la figura 11.  del desarrollo de la arquitectura propuesta. 

H. Diseño - Control Reactivo  Refinamiento de la Solución: Tomamos como referencia el 

sistema de control reactivo. En la figura 12 se proponen los 
El diseño está más próximo a los dominios del Ingeniero de 
subsistemas  que  lo  conforman,  los  cuales  se  subdividen  de 
Software y, por tanto, es éste quien,  en última instancia, identifica 
acuerdo  a  las  características  de  comportamiento  que  debe 
y define cada uno de los elementos constitutivos de esta etapa. 
ejecutar el robot, en función de su responsabilidad. 

Experticia  Mapas  Mapas  Modelo  Modelo  Parámetros  Parámetros 

Objetvo 
Sensores  Actuadores  Robot  Tareas 

Acople 
Gestor_Base_Datos 
Arrastre 

:Operador   IU 
Gestor_  Seguimiento_ 
Supersor_  Gestor_  Objeto 
Tares  Comportamiento 

Busqueda_ 
I_Inp  I_Out  Interprete_  Objetivo 
Planificador 
Comandos 
Otros
Interfaz_Sensores 

Evaluador_ Planificad_  Sistema_ 
Trayectoria  Local  Localizacion 

Sensores 
Algoritmos_  Control_ 
Comandos 
Especiales  Reactivo 
Básicos  Interfaz_ 
Motores 

Motores 

Navegación 
Preventivos  Desbloqueo 
Seguridad 
Evadir_ 
Obstaculos 
Evadir_  Vagar 
Abismo 
Paro_  Seguir_  Evadir_  Seguir_  Ir_a_ 
Emergencia  Muro  Ostáculo  Trayectoria  Objetivo 
Fuga  Ir_Zona_ 
Salir_Zona_ 
Muerta  Libre 
Giro_  Pasar_Zona_ 
Emergencia  Estrecha 

Figur a  11.  Ejemplo  de  Modelo  de  Clases  de  una Arquitectura  Software  de  Control  para  Robots 
 Arquitectura software para robots móviles aplicando la metodología MDASR – Londoño.  141 

Cada  unos  de  estos  subsistemas,  a  su  vez,  pueden  ser  Nota: La relación entre subsistemas puede generar interfaces, 
subdivididos  en  unidades  más  pequeñas  y  manejables  para  así por ejemplo, para el Subsistema Control_Reactivo propuesto 
facilitar la implementación y modularidad del software. Así, por  anteriormente, se puede representar sus diferentes interfaces 
ejemplo,  el  subsistema  de  navegación  reactiva,  puede  ser  como se ilustra en la figura 14. 
subdividido en: 
Control 
Reactivo 
•  Vagar (Navegación aleatoria) 
•  Seguir una trayectoria pintada en el suelo.  Seguridad 

•  Moverse hacia un objeto (Atracción a un punto).  Navegación 
Paro_Emergencia  

•  Ir a zonas libres dirigidas. 
Comandos Básicos  Giro_Emr gencia 

•  Moverse en la misma dirección (permanecer en trayectoria).  . 
. 
Comandos Básicos 
•  Arrastrar objeto.  . 
. 
•  Moverse una dirección relativa (posición/Angulo)  . 

A su vez, el sistema de navegación puede ser considerado como  Comandos Básicos 
Preventivos 
un subsistema (apoyado en el modelo de análisis), figura 13. 
Desbloqueo  Seguir _Muro 

Zona s _Libres  Evadir 

Contr ol 
Reactivo 
. 
. 
Navegació n 
Segu rida d 
Figur a  14.  Interfaces  "Relación  entre  Subsistemas  y  clases" 

J. Diseño de Clases-Objetos 
Desbloqueo 
P reventivo s  Diseño de Casos de Uso: Identificación ­ clases de diseño 
por caso de uso. 
Tomando como base el Caso de Uso "Seguimiento de muro", 
visto en la etapa de análisis,  se identifica cada una de las clases 
participantes en el Caso de Uso, y se presenta como un diagrama 
Figur a  12.  Subsistemas  de  “Control_Reactivo” 
UML figura 15. 
Navegación  Diagrama de secuencia para cada parte de Caso de Uso: 
Para el Caso de Uso propuesto en el numeral anterior, se puede 
Atraccion_ 
Vagar  Seguir_Linea 
a_Punto 
plantar el diagrama de secuencias, ejemplificado en la figura 16. 
Se asume, en este ejemplo, que los comandos se ejecutan vía 
teclado. 
Nota: Podría considerarse que el usuario sea un nivel superior 
Arra stra r_ 
de control, en cuyo caso es posible que se requiera una interfaz 
Zona s_Libres  Objetos  que facilite la comunicación. 
Clases de Diseño 
Una versión simplificada del diagrama de clases para 
Figur a  13.  Subsistemas  de  “Navegación”  una arquitectura de robot se ilustra en la figura 17. Cada una de 
las clases representadas puede contener o extender otras clases. 
Diseño de Cada Clases 
I. Identificación Interfaces de Subsistemas 
La  interfaz  corresponde  a  una  clase,  que  suministra  El  diseño  de  cada  clase está  ligado  a  las  características  y 
todos  los  elementos  necesarios  para  comunicar  la  clase  con  especificaciones definidas anteriormente. Como ilustración, se 
otras  clases  u  objetos  externos;  por  tanto,  incluirá  las  presentan algunos ejemplos representativos de este caso.
características, atributos y métodos que permitan ejecutar la 
orden. 
142  Revista Avances en Sistemas e Informática, Vol.6 No.3, Diciembre de 2009 ISSN 1657­7663 

Seguir_Muro  Seguir Muro 
:Teclado  :Pantalla  :Parametros  :Seguir_  :Calculo_  :Procesad_  :Procesad_  :Gestor_ 
Muros  SetPoint  Sensores  Motores  Alarmas 

Orden Segumiento 
Teclado  Leer sensores Proximidad 
Estado Sensores 

Leer_Distancia_Límite 

Pantalla 
Evalua (no critico) 
Gestor 
Alarmas 

Botones  Define dirección y ángulo 
Procesador_Mo 
Comandos 
tores 
Valores consigan para cada motor 

Parametros 
Procesador_Sen 
sores 
Seguir_Muros  CalculoSet 
Poin 

Figur a  15.  Clases  que  intervienen  en  el  Caso  de  Uso  “Seguir_Muro”  Figur a  16.  Diagrama  de  Secuencias,  "Seguir_  Muro" 

Interfaz_Usuario  Supervisor_Gestor_  Modelo_Entorno 

Comportamientos 

Planificador_ 
Global 

Pantalla  Botones  Teclado 

Comandos 

Estado_Actual 

Control 
Reactivo 
Sistema_Sensor 

Seguridad  Preventivo  Desbloque  Navegacion  Sistema  Sensor_Infraroj  Sensor_Ultraso  Sensor_.... 

Actuador  o 

N­Aleatoria Atracción_Punt  Ir­Z_Libre  Seguim_Muro 

o 

Figur a  17.  Ejemplo  de  Diagrama  de  Clases  de Arquitectura  Software  para  Robots 
 Arquitectura software para robots móviles aplicando la metodología MDASR – Londoño.  143 

Clase:  " Seguimiento_Mur os"   información  se  genera  como  respuesta  un  vector  (d,  )  que 
representa el incremento de distancia y ángulo que debe recorrer 
­  Esbozo  de  la  clase:  Seguimiento_Muros  contiene  los 
el robot, respectivamente. Cuando no se detecta obstáculo, la 
algoritmos  necesarios  para  bordear  los  obstáculos  que  son 
clase se inhabilita automáticamente. 
detectados en el recorrido de robot, para ello utiliza como datos 
de entrada los valores captados por los sensores de ultrasonidos  ­ Esquema general: Figura 18 
y la distancia a la que se realiza el seguimiento. A partir de esta 

Seguimiento_Muros 
­V_Sensores: Num=0  Sensores 
­V_Velocidad: N um=0 
­Angulo de giro: Num=0 

+Iniciar_S_M ( ) 
+Parar_S_ M ( ) 
Actuadores 

S_M_ Izquierda  S_MDerecha  S_M_ Aleatorio  S_M…. 

Figur a  18.  Representación  gráfica  de  la  clase  “Seguir_Muro” 

•  Descripción  de  los  métodos:  En  este  aparte  se  define  e  Se demuestra, que es posible, siguiendo un procedimiento 
método utilizado para el seguimiento de contorno que puede  sistemático, como lo propone MDARS, facilitar la concepción 
ser  presentado  como  una  formula  o  como  un  algoritmo,  al Ingeniero en Robótica y su comunicación con el Ingeniero de 
dependiendo del algoritmo escogido.  Sistemas. 

•  Requisitos especiales: Para el seguimiento de contorno, la  Como  se  observa,  se  hace  un  énfasis  muy  marcado  el  los 
respuesta  del  algoritmo  debe  se  menor  que  un  tiempo  Caso de Uso y su representación mediante Diagramas de Casos 
predefinido por el usuario, o puede ser definida dependiendo  de  Uso  de  la  arquitectura  propuesta,    facilitando  una 
de la velocidad actual del robot.  aproximación muy rápida a las etapas de Análisis y Diseño. 

Los  valores  de  ángulo  y  distancia  pueden  ser  igualmente  Cubrir con más detalle las etapas de Diseño, Implementación, 

limitados a un valor mínimo para evitar daños en los dispositivos  propuestas  en  la  metodología  (MDASR),  al  igual  que  una 
de actuación.  descripción más detallada de cada uno de los elementos software, 
no es objeto de este artículo pero, con él es posible identificar y 
evaluar los alcances y ventajas de la metodología, con el ejemplo 
I V.  C O NC L USI O NE S  propuesto. 

Cubrir  la  brecha  de  comunicación  entre  disciplinas  muy  REFERENCIAS 

especializadas,  fue el  objetivo de  la propuesta  metodológica 
ejemplificada  en  este  artículo,  cuyo  objetivo  es, 
[1]  Arkin,  R.  C.  (www),  2009.    http://www.cc.gatech.edu/ai/  robot­lab/ 
fundamentalmente, ilustrar los procedimientos mas relevantes  publications.html.  [Con  acceso  en  Feb.  2009]. 
al afrontar el desarrollo de una arquitectura de control reactiva,  [2] Arkin,  R.  C.    1999.  Behavior­Based  Robotics.  2ª  ed.  The  MIT  Press, 
concebida por el especialista en Robótica y presentada de tal  Cambridge,  Massachusetts,  London,  England. 
forma que sea fácilmente asimilada por el Ingeniero de Software,  [3]  Booch,  G.,  Jacobson,  I.,  Runbaugh,  J.,  1999.  El  Lenguaje  Unificado  de 
Modelado. Addison  Wesley.  México. 
quien  en  última  instancia  es  el  que  desarrolla  el  Software  [4]  Booch,  G.,  Rumbaugh,  J.;  Jacobson,  I.,2005.  The  Unified  Modeling 
requerido.  Language  User  Guide"  2a  Ed. Addison  Wesley  Professional. 
[5]  Braitenverg,  V.,  1984.  Vehicles:  Experiments  in  Synthetic  Psycology". 
En el artículo se hace una demostración un poco mas focalizada  Cambridge.  MIT  Press. 
en el tema de la especificación y se ilustra, de manera general,  [6]  Brengge,  B.;  Dutoit, A.  H.,  2002.  Ingeniería  de  Software  Orientada  a 
los  pasos  relacionados  con  el  Análisis  y  diseño  de  la  Objetos.  Pearson    Educación,  México. 
[7]  Brooks,  (www).  http://www.ai.mit.edu/people/  brooks/ 
arquitectura propuesta.  publications.shtml.  [Con  acceso  en  Feb.  2009].
144  Revista Avances en Sistemas e Informática, Vol.6 No.3, Diciembre de 2009 ISSN 1657­7663 

[8]  Gachet,  D.,  1993.  Control  Reactivo  de  Robots  Móviles.  Tesis  Doctoral. 
Universidad  Politécnica  de  Madrid. 
[9]  Jacobson,  I.;  Booch,  G.;  Rumbaugh,  J.,  2000.  El  Proceso  Unificado  de 
Desarrollo  de  Software. Adison  Westley,  Madrid­España. 
[10]    K­Team  Corporation,  2009.  Pagina  disponible  en  internet  en: 
<http://www.k­team.com>.  [Con  acceso  en  Feb.  2009]. 
[11]  Lampe,  A.,  Chatila,  R.,  2006.  Performance  Measure  For  The 
Evaluation  of  Mobile  Robot Autonomy.    Proceedings  of  the  2006 
IEEE  International  Conference  on  Robotics  and Automation  Orlando, 
Florida. 
[12]  Londoño  O.,  N.,  Tornero,  J.,  1998.  Análisis  de  la  Metodología 
HOOD  para  la  Implementaciónde Arquitecturas Aplicadas  a  Robots. 
VIII  Congreso  Latinoamericano  de  Control  Automático,  Viña  del 
Mar,  Chile, 
[13]  Londoño  N.,  2009.  Metodologías  de  Desarrollo  de  Software,  un 
Enfoque  a  Robots  Móviles. 
Revista  Politécnica.  Politécnico  Colombiano  JIC. 
[14]  Londoño  N.,  2009. Aquitecturas  Software  de  Robots,  Metodología 
de  Desarrollo.  Octava  Conferencia  Iberoamericana  en  Sistemas, 
Cibernética  e  Informática.  Orlando,  Florida. 
[15]  Londoño  N.,  2009.  Una  Propuesta  Metodológica  para  el  Desarrollo 
de Arquitecturas  Software  Para  Robots  (MDASR).  Tesis  Doctoral, 
Universidad  del Valle,  Escuela  de  Ingeniería  Eléctrica  y  Electrónica. 
[16]  Mataric,  M.  J.,1990.  Behavior­Based  Control:  Main  Properties  and 
Implications".  http://www  robotics.usc.edu/~maja/publications.html. 
[Con  acceso  en  Feb.  2009]. 
[17]  Mukerjee, A.,  Mali, A.  D.,  1999.  Reactive  Robots  and Amnesics: A 
Comparative  Study  in  Memoryless  Behavior.  IEEE  Transactions  on 
Tystems,  Man,  and  Cybernetics­part  C: Applications  and  Reviews, 
Vol.  29,  No.  2. 
[18]  Muñoz,  N.  D.,  2007.  Estudio  e  Implementación  de  una Arquitectura 
de  Control  para  el  Robot  Móvil  GIRAA_02.  Tesis  de  Maestría. 
Universidad  de Antioquia,  Facultad  de  Ingeniería. 
[19]  OMG,  2003.  Unified  Modeling  Language  Specification.  Retrieved 
March  18,  2003.  Disponible  en  internet  en:  <http://www.omg.org/ 
technology/documents  /formal/uml.htm 
[20]  Rumbaugh,  J.,  Jacobson,  I.;  Booch,  G.,  2000.  El  lenguaje  Unificado 
de  Modelado,  Manual  de  Referencia.  Racional  Software  Corporation. 
[21]  Ram, A., Arkin,  R.  C.,  Moorman,  K.,  Clark,  R.,  1996.    Case­  Base 
Reactive  Navigation: A  Method  for  on  Line  Selection  and Adaptation 
of  Reactive  Robotic  Control  Parameters.  IEEE,  Transaction  on 
systems,  Man,  and  Cybernetics,  Vol.  27,  No.  3.