View/Open - Universidad Católica de Pereira

UCPBRA: SOFTWARE PARA USO DE BRAZO ROBOTICO EN PHYSILAB
JUAN CARLOS PARRA VILLA
UNIVERSIDAD CATÓLICA DE PEREIRA
FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA
PROGRAMA DE INGENIERÍA DE SISTEMAS Y TELECOMUNICACIONES
INFORME FINAL
2015-1
UCPBRA: SOFTWARE PARA USO DE BRAZO ROBOTICO EN PHYSILAB
JUAN CARLOS PARRA VILLA
DIRECTOR DE PROYECTO DE GRADO
JAMES BARRERA MONCADA
Ingeniero Electricista
UNIVERSIDAD CATÓLICA DE PEREIRA
FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA
PROGRAMA DE INGENIERÍA DE SISTEMAS Y TELECOMUNICACIONES
INFORME FINAL
2015-1
2
Declaración de derechos de autor
Yo JUAN CARLOS PARRA VILLA declaro que el trabajo presentado es de mi
propia autoría, hasta el momento no ha sido presentado para antes para optar algún
título o calificación profesional, he hecho citas que están debidamente referenciadas,
respetando los derechos de autor de las fuentes, incluidas en este documento.
La Universidad Católica de Pereira –UCP- puede hacer uso de lo consignado
en este documento, según lo establecido por las normas y la Ley de Propiedad
Intelectual y la normatividad constitucional vigente.
3
Agradecimientos
Agradezco inicialmente al Todo poderoso, la Suprema Personalidad de Dios,
que nos ilumina con su gran sabiduría, dotándonos de paciencia para sortear cada
uno de los pasos a dar para llegar a esta instancia.
Mi familia se merece un agradecimiento especial por los momentos de apoyo
incondicional, cuando yo quería desfallecer ellos siempre han estado allí para dar un
gran aliento de fuerza para continuar el camino.
Sinceros agradecimientos a todo el personal humano que compone la
Universidad Católica de Pereira, desde las instancias administrativas, pasando por
docentes, secretarias, empleados, y todos aquellos que de una u otra forma hacen
posible este proceso educativo.
A PHYSILAB, su director, el equipo de trabajo, los monitores, asesores y
estudiantes que hacen un uso adecuado de este laboratorio, como espacio
incuestionable de conocimiento y aprendizaje.
A mis compañeros estudiantes que han compartido conmigo tantos
momentos tan especiales, algunos duros, otros alegres, pero todos unidos por los
lazos donde los esfuerzos se coordinan.
4
Dedicatoria
A mi madre, por su dedicación y esfuerzo, mi hermano, con ellos a toda mi
familia, por su apoyo incondicional, aun cuando ya no creía tener fuerzas ellos
siempre han estado allí.
A la Universidad Católica de Pereira, con todo su recurso humano, con ellos
en estas aulas he crecido como persona y principalmente como profesional.
Un profesor generalmente es un mutilador de sueños y utopías, aquel que
coarta la iniciativa y creatividad de la generación en honor de quien es su profesión,
sin embargo un maestro, es aquel que nos ofrece la luz sin restricción, aquel le
ofrece a sus discípulos la antorcha del conocimiento, sin ninguna ambición, es un
deleite aprender a su lado, en fin de cuentas, a los muchos Maestros, que me han
ensañado,
sin ellos este paso importante en la vida no sería posible, por su
acompañamiento y comprensión en tantos momentos de tensión.
5
Resumen
En los actuales desarrollos de programas, existe una tendencia fuerte por la
aplicación de la Ingeniería del Software, con el fin de obtener productos
estructurados y de calidad, debido a los resultados obtenidos por las metodologías
existentes, asegurando así un proceso de desarrollo eficiente y con posibilidad de
mejora.
Los laboratorios remotos y virtuales se han convertido en una gran posibilidad
para expandir la adquisición de conocimientos de las leyes naturales por medio de la
experimentación, puesto que el usuario de los mismos no necesita trasladarse hasta
una locación remota en donde se encuentren los equipos correspondientes para su
uso y apropiación de los conceptos relacionados con la temática correspondiente.
Este trabajo de investigación está destinado a la aplicación de la robótica, en
el laboratorio remoto y virtual denominado PHYSILAB de la Universidad Católica de
Pereira. Específicamente consiste en el desarrollo de un software para la
manipulación de un brazo robótico, el cual, posteriormente pueda ser integrado con
los elementos de laboratorio de PHYSILAB como utilidad complementaria del mismo,
basándose en información recopilada de diferentes publicaciones de Internet, libros y
datos obtenidos mediante la experimentación.
Palabras
claves:
Metodologías,
Laboratorios,
Experimentación, Equipos, Robótica, Physilab, Internet, Datos.
6
Remotos,
Virtuales,
Abstract
In the current developments of programs, there is a strong tendency for the
application of software engineering, in order to obtain structured quality products due
to the results obtained by the existing methodologies, thus ensuring efficient process
development and for improvement.
Remote and virtual laboratories have become a great opportunity to expand
the acquisition of knowledge of natural laws through experimentation, since the user
thereof need not travel to a remote location where related equipment are to use and
appropriation of the concepts related to the corresponding topic.
This research is intended for the application of robotics in remote and virtual
laboratory called PHYSILAB of the Catholic University of Pereira. Specifically is the
development of software for manipulating a robotic arm, which can then be integrated
with laboratory PHYSILAB elements as complementary usefulness, based on
information gathered from various Internet publications, books and data through
experimentation.
Keywords: Methodologies , Laboratories, Remote , Virtual , Experimenting ,
Equipment , Robotics, Physilab, Internet , Data .
7
TABLA DE CONTENIDO
Pag
Introducción ................................................................................................... 15
1.
FORMULACION DEL PROYECTO ....................................................... 17
1.1 DESCRIPCION Y FORMULACION DEL PROYECTO ........................ 17
1.2 OBJETIVOS ......................................................................................... 19
1.2.1 Objetivo General ........................................................................... 19
1.2.2 Objetivos Específicos .................................................................... 19
1.3 Justificación ......................................................................................... 20
2. MARCOR TEORICO ................................................................................. 21
2.1 ANTECEDENTES ................................................................................ 21
2.2 MARCO CONTEXTUAL ...................................................................... 25
2.2.1Desarrollo de Software en Colombia .............................................. 25
2.2.2Desarrollo de las TIC en Risaralda................................................. 29
2.3 MARCO CONCEPTUAL ...................................................................... 31
2.3.1 Brazo robot .................................................................................... 31
2.3.2 Tipos de brazo robot ..................................................................... 32
8
3. ARQUITECTURA DEL SOFTWARE ......................................................... 35
3.1 UML ..................................................................................................... 38
3.2 JAVA ................................................................................................... 41
3.3 NETBEANS ......................................................................................... 42
3.4 ARDUINO ........................................................................................... 42
3.5 METODOLOGIAS DE PROGRAMACION ........................................... 43
3.5.1 Rapid application development (Rad) .......................................... 43
3.5.2 Rational unified process (Rup) ..................................................... 44
3.5.3 Cascada ....................................................................................... 45
3.5.4 Prototipado .................................................................................... 46
3.5.5 Incremental.................................................................................... 47
3.5.6 Espiral ........................................................................................... 48
3.6 METODOLOGIA SELECCIONADA.................................................. 49
4. ESPECIFICACION DE LA SOLUCION ..................................................... 50
4.1 REQUERIMIENTOS ............................................................................ 50
4.2 PONDERACION DE LOS REQUERIMIENTOS................................... 55
4.3 DESCRIPCION DE LA TECNOLOGIA ................................................ 56
4.3.1 Brazo robótico AS-6DOF ............................................................... 56
4.3.2 Arduino mega 2560 ....................................................................... 58
4.3.3 Servomotores ................................................................................ 59
9
4.4 DESCRIPCION GENERAL DE LA SOLUCION ................................... 60
4.4.1Sistema General............................................................................. 60
4.4.2 Software en Arduino ...................................................................... 60
4.4.3 Software de Escritorio ................................................................... 61
4.4.4 Integración..................................................................................... 61
4.4.5 Cronograma de Actividades .......................................................... 62
4.4.6 Estimación de Presupuesto ........................................................... 63
5. ARQUITECTURA DEL SOFTWARE ......................................................... 63
5.1 Diagrama de casos de uso .................................................................. 63
5.2
Diccionario de casos de uso ........................................................... 64
5.3 Diagrama general de secuencias......................................................... 53
5.4 Prototipo no funcional .......................................................................... 55
5.5 Descripción del proceso de desarrollo ................................................. 56
5.6 Inconvenientes en el proceso de desarrollo ......................................... 55
6. RESULTADOS .......................................................................................... 56
Conclusiones ................................................................................................. 56
Referencias bibliográficas ............................................................................. 58
Bibliografía .................................................................................................... 58
ANEXO .......................................................................................................... 61
Anexo A. Pruebas realizadas ..................................................................... 61
10
ANEXO B. Pasos para la configuración y programación básica de un
Arduino a través del IDE Arduino........................................................................... 69
11
TABLA DE FIGURAS
Figura 1. UNO DE LOS PRIMEROS BRAZOS ROBÓTICOS ................................... 21
Figura 2. Brazo ensamblador .................................................................................... 23
Figura 3. PARTICIPACIÓN DE LOS SEGMENTOS DEL TI 2008 (OSEC Y
PROEXPORT). ......................................................................................................... 28
Figura 4. RELACIÓN ENTRE UN BRAZO ROBOT Y UN BRAZO HUMANO ........... 31
Figura 5. BRAZO ROBOT CARTESIANO ................................................................. 32
Figura 6. BRAZO ROBOT CILÍNDRICO ................................................................... 33
Figura 7. BRAZO ROBOT POLAR ............................................................................ 33
Figura 8. BRAZO ROBOT ARTICULADO ................................................................. 34
Figura 9. BRAZO ROBOT PARALELO ..................................................................... 34
Figura 10. BRAZO ROBOT ANTROPOMÓRFICO.................................................... 35
Figura11. MAPA MENTAL DE LOS PROCESOS UML
39
Figura 12. UML DIVISIÓN DE DIAGRAMAS ESTRUCTURALES ............................ 41
Figura 13. RAPID APPLICATION DEVELOPMENT (RAD). ...................................... 44
Figura 14. RATIONAL UNIFIED PROCESS (RUP)................................................... 45
Figura 15. MODELADO EN CASCADA .................................................................... 46
Figura 16. MODELADO EN PROTOTIPADO ............................................................ 47
Figura 17. MODELO INCREMENTAL ...................................................................... 47
12
Figura 18. MODELADO EN ESPIRAL....................................................................... 49
Figura 19. BRAZO ROBOT AS-6DOF....................................................................... 57
Figura 20. ARDUINO MEGA 2560 ............................................................................ 58
Figura 21. SERVOMOTOR RB-150MG .................................................................... 59
Figura 22. DIAGRAMAS DE CASOS DE USO UCPBRA.......................................... 64
Figura 23. DIAGRAMA DE SECUENCIA .................................................................. 53
Figura 24. INTERFAZ DE INICIO UCPBRA .............................................................. 55
Figura 25. INSERCIÓN DE DATOS PARA RUTINA MANUAL UCPBRA ................. 56
13
LISTA DE TABLAS
Tabla 1. Requerimiento 001 .......................................................................... 52
Tabla 2. Requerimiento 002 .......................................................................... 52
Tabla 3. Requerimiento 003 .......................................................................... 53
Tabla 4. Requerimiento 004 .......................................................................... 53
Tabla 5. Requerimiento 005 .......................................................................... 54
Tabla 6. Requerimiento 006 .......................................................................... 54
Tabla 7. Requerimiento 007 .......................................................................... 55
Tabla 8. Ponderación de Requerimiento
…………………………………. 55
TABLA 9. CRONOGRAMA DE ACTIVIDADES UCPBRA ........................................... 62
Tabla 10. Estimación de Presupuesto ........................................................... 63
Tabla11. Diccionario de casos de uso 1 ........................................................ 64
Tabla 12. Diccionario de casos de uso 2 ....................................................... 65
Tabla 13. Diccionario de casos de uso 3 ....................................................... 65
Tabla 14. Diccionario de casos de uso 4 ....................................................... 66
Tabla 15. Diccionario de casos de uso 5 ....................................................... 66
Tabla 16. Diccionario de casos de uso 6 ....................................................... 67
Tabla 17. Diccionario de casos de uso 7 ....................................................... 67
Tabla 18. Diccionario de casos de uso 8 ....................................................... 67
14
Introducción
Las Nuevas Tecnologías de la Información y la comunicación TIC, poco a
poco se han ido integrando en los procesos de enseñanza aprendizaje a todo nivel,
no solo con el fin de dinamizar dichos procesos si no buscando resolver problemas
tendientes a mejorar la calidad de vida de la población.
La robótica es una muestra de ello, la cual se define como el conjunto de
conocimientos teóricos y prácticos
que nos dejan crear, realizar y mecanizar
sistemas basados en estructuras mecánicas articuladas, proporcionados de un
determinado grado de “inteligencia” y destinados a la manufactura industrial o al
remplazo del hombre para diversas tareas.
El nivel de tecnología y desarrollo de software que puedan llegar a tener los robots
determinará lo que estos podrán hacer para facilitar las actividades diarias,
para realizar tareas que no pongan en peligro la integridad del ser humano, en la
diversión y el entretenimiento; en el aspecto productivo, no sólo en tiempo sino
en calidad.
Debido al movimiento acelerado y al desarrollo vertiginoso que presenta la
tecnología en la vida de las personas, poco a poco surgen aplicaciones más
complejas, que deben cumplir los requisitos de calidad, rendimiento, usabilidad,
escalabilidad, mantenimiento, accesibilidad, entre otros. La labor que debe realizar
un ingeniero del software es compleja, la cual parte de la documentación de todo el
proceso de diseño, los requerimientos deben de ser planteados analizados y
ponderados, debe ser apoyada por los diagramas necesarios. La ausencia de
algunas partes del proceso para el desarrollo de software produce daños que a
veces son intangibles o imperceptibles, principalmente en la tapa de mantenimiento.
En el campo académico se hace necesario desarrollar nuevas propuestas,
nuevas prácticas a partir del desarrollo del software. Para el caso concreto el
15
desarrollo de un software que permita el movimiento de un brazo robótico y su uso
en el laboratorio de física de la Universidad Católica de Pereira, PHYSYLAB.
En el marco de los nuevos paradigmas educativos, se debe pensar en una
academia que esté a la altura del reto de preparar los estudiantes para enfrentar la
nueva sociedad, la del conocimiento, donde se tengan mayores avances en el
análisis en contraposición a la metodología que obedece a procesos repetitivos,
rutinarios esto es, desarrollar novedosas metodologías, necesarias en la nueva era
donde la sociedad funciona con información, debemos saber la importancia de la
enseñanza fusionada con las TIC, donde surjan las facilidades y ventajas con la que
la tecnología posibilita el rápido intercambio de información lo cual contribuye al
mejoramiento del proceso enseñanza-aprendizaje.
El objeto de este trabajo es poder desarrollar un conjunto de tareas y rutinas
que permitan el funcionamiento un brazo robótico con seis grados de libertad, con el
fin
de apoyar a las labores en prácticas académicas
que se realizan en el
laboratorio de física de la universidad Católica de Pereira denominado PHYSILAB;
se
utiliza
teoría
movimientos del
de
sistemas
robot, la
para
descubrir
y
resolver
forma de alimentar o generar
las
diferentes
información de los
componentes de un problema, los cambios que provocan la transición de un
estado a otro, todos estos elementos importantes para poder construir e
implantar la aplicaciones más adecuada.
16
1. FORMULACION DEL PROYECTO
En
la vida moderna es muy común el uso de robots que ayudan en la
dinámica diaria, en la producción, educación etc. La diversidad en los modelos y las
aplicaciones de los robots ha hecho que evolucione no solo la concepción que se
tiene de ellos, sino también su morfología; esto quiere decir, que no solo hay robots
industriales, espaciales, sino también de uso militar, agrícolas, médicas y
pedagógicas; por ejemplo las prótesis robóticas, los dispositivos de rehabilitación,
robots utilizados como herramientas pedagógicas, entre otros.
Bajo esta línea se ha enfocado PHYSILAB, su propósito es permitir que los
estudiantes puedan desarrollar sus prácticas de
física sin necesidad de estar
ubicados físicamente en el laboratorio, la implementación de un brazo robótico, va a
permitir la modificación de elementos al interior del Laboratorio, así como el
desarrollo de nuevas prácticas en lo que tiene que ver con el campo vectorial. Los
trabajos y los esfuerzos impulsados desde PHYSILAB no son sólo un aporte
importante al avance tecnológico de la universidad, sino también de la región.
Este proyecto es una primera etapa cuya operación se realiza
de manera
local, puesto que en una segunda fase se desarrollará la implementación de los
procesos que permitan las funcionalidades remotas del software.
1.1 DESCRIPCION Y FORMULACION DEL PROYECTO
Las tareas de laboratorio en nuestro país generalmente no cumplen las
expectativas de los estudiantes debido a la falta de estructuración de los mismos,
también por la falta de instrumentación necesaria para su desarrollo y prácticas
experimentales que no alcanzan a desarrollar el conocimiento científico. En los
últimos años se están buscando mecanismos para suplir dicha problemática, como el
apoyo de trabajos que tengan entre sus objetivos el crear y desarrollar plataformas
que posibiliten la enseñanza a través de sistemas hipermedia y multimedia, de las
redes de comunicaciones de área extendida, estas herramientas o TIC brindan la
posibilidad de crear nuevos espacios, dinamizadores de enseñanza, aprendizaje
17
dentro y fuera del aula de clases posibilitando que los estudiantes sean partícipes de
su propio aprendizaje. (Rosado, 204)
En este sentido el laboratorio de PHYSYLAB, viene buscando alternativas
que orienten los productos académicos hacia el desarrollo de nuevas prácticas de
laboratorio, en este caso se pretende integrar un brazo robótico, como una
herramienta indispensable para los procesos de práctica remota en el laboratorio,
cabe notar que en PHYSYLAB no cuenta con un software para el manejo del mismo,
de esta forma nos lleva a el diseño de UCPBRA, el cual manipula un brazo robótico
de seis grados de libertad y su consecuente desarrollo en un trabajo
complementario. Con este proyecto se busca que el laboratorio tenga una ayuda
eficaz a la hora de probar localmente los movimientos del brazo antes de subir los
cambios en el laboratorio virtual, donde
primordial
los estudiantes tendrían un elemento
para poder desarrollar las destrezas, habilidades, capacidades y
competencias que se conjuguen con iniciativa y creatividad en una ambiente virtual.
18
1.2 OBJETIVOS
1.2.1 Objetivo General
Diseñar y desarrollar de un software para el control local de un brazo robótico
como apoyo de las prácticas dentro del laboratorio PHYSYLAB de la Universidad
Católica de Pereira.
1.2.2 Objetivos Específicos

Identificar el funcionamiento del brazo robótico para luego simularlo a través
del software

Identificar los requerimientos del software que permitan el control del brazo
robótico de acuerdo a las necesidades de la práctica.

Analizar los diferentes aspectos que permitan diseñar una solución software
que lleve al cumplimiento de los requerimientos.

Diseñar un sistema software de control, que interactúe con los sensores y
permita la manipulación de los mecanismos y motores del brazo.

Implementar el software construido de tal manera que interactúe con el brazo
robótico.

Realizar pruebas de las diferentes etapas que intervienen en el desarrollo del
proyecto.
19
1.3 Justificación
Actualmente los países altamente industrializados desarrollan y comercializan
aparatos y
equipos avanzados y costosos, invierten muchos
recursos en
investigación de nuevas tecnologías. De ahí la gama de productos ofertados
Lamentablemente este no es el caso de Colombia, las empresas nacionales buscan
soluciones en otros países y solo se limitan a utilizar los
equipos, es decir, la
escueta transferencia de tecnología; esto se debe a que no se fomentan las
investigaciones de forma adecuada.
Dicha ausencia de desarrollo también se aprecia en el campo de la robótica y
la educación, en nuestro país se encuentra muy limitada, son pocas universidades,
las que han venido desarrollando proyectos de investigación, donde desarrollen
rápidamente diferentes tecnologías de la información o sistemas permitiendo que el
proceso de la enseñanza y aprendizaje sea más fácil para los estudiantes. Por lo
anterior la universidad decidió crear un software que permita controlar localmente un
brazo robótico antes de ser manejado remotamente
desde la plataforma de
PHYSYLAB, es importante el apoyo que brindara este software en el movimiento de
algunos implementos dentro del laboratorio, ya que se realizaran localmente antes
de ser configurados en la plataforma remota, esto permite que a la hora de hacer las
practicas no tengan inconvenientes que impliquen altas perdidas económicas en
equipos tecnológicos, instalación y mantenimiento de los mismos, También es una
herramienta que sirve como apoyo, dando precedente base para el desarrollo del
software de control remoto para el brazo robótico en la plataforma virtual. Por estas
razones se decidió diseñar e implementar un software (UCPBRA) que manejara un
brazo robótico de seis grados de libertad para el funcionamiento en el laboratorio de
PHYSILAB,
20
2. MARCOR TEORICO
2.1 ANTECEDENTES
Desde tiempos atrás, el ser humano ha tenido una atracción y fascinación por
las maquinas que imitan los movimientos, funciones y acciones de diferentes seres
vivos. La construcción y realización de diferentes proyectos con mecanismos
hidráulicos; donde podían funcionar a través de poleas, engranaje, resortes o
simplemente por la morfología de su estructura, ha sido la constante desde tiempos
muy remotos.
La palabra robot fue usada por primera vez en el año 1921, cuando el escritor
checo Karel Capek (1890 - 1938) estrena en el teatro nacional de Praga su obra
Rossum's Universal Robot (R.U.R.). Su origen es de la palabra eslava robota, que
se refiere al trabajo realizado de manera forzada.
Figura 1. UNO DE LOS PRIMEROS BRAZOS ROBÓTICOS
Recuperado de http://proton.ucting.udg.mx/materias/robotica/r166/r63/r63.htm
Con el objetivo de diseñar una maquina flexible, adaptable al entorno y de
fácil manejo, George Devol, pionero de la Robótica Industrial, patento en 1948, un
manipulador programable que fue el germen del robot industrial, como muestra la
figura 1.
En 1948 R.C. Goertz del Argonne National Laboratory desarrollo, con el
objetivo de manipular elementos radioactivos sin riesgo para el operador, el primer
21
tele manipulador. Este consistía en un dispositivo mecánico maestro-esclavo. El
manipulador maestro, reproducía fielmente los movimientos de este. El operador
además de poder observar a través de un grueso cristal el resultado de sus
acciones, sentía a través del dispositivo maestro, las fuerzas que el esclavo ejercía
sobre el entorno.
Años más tarde, en 1954, Goertz hizo uso de la tecnología electrónica y del
servo control sustituyendo la transmisión mecánica por eléctrica y desarrollando así
el primer tele manipulador con servo control bilateral. Otro de los pioneros de la tele
manipulación fue Ralph Mosher, ingeniero de la General Electric que en 1958
desarrollo un dispositivo denominado Handy-Man, consistente en dos brazos
mecánicos teleoperados mediante un maestro del tipo denominado exoesqueleto.
Junto a la industria nuclear, a lo largo de los años sesenta la industria submarina
comenzó a interesarse por el uso de los tele manipuladores.
A este interés se sumo la industria espacial en los años setenta.
La evolución de los tele manipuladores a lo largo de los últimos años no ha sido tan
espectacular como la de los robots. Recluidos en un mercado selecto y limitado
(industria nuclear, militar, espacial, etc.) son en general desconocidos y
comparativamente poco atendidos por los investiga- dores y usuarios de robots. Por
su propia concepción, un tele manipulador precisa el mando continuo de un
operador, y salvo por las aportaciones incorporadas con el concepto del control
supervisado y la mejora de la tele presencia promovida hoy día por la realidad virtual,
sus capacidades no han variado mucho respecto a las de sus orígenes.
La sustitución del operador por un programa de ordenador que controlase los
movimientos
del
manipulador
dio
paso
al
concepto
de
robot.
La primera patente de un dispositivo robótico fue solicitada en marzo de 1954 por el
inventor británico C.W. Kenward. Dicha patente fue emitida en el Reino Unido en
1957, sin embargo fue Geoge C. Devol, ingeniero norteamericano, inventor y autor
de varias patentes, él estableció las bases del robot industrial moderno. En 1954
22
Devol concibió la idea de un dispositivo de transferencia de artículos programada
que se patento en Estados Unidos en 1961.
En 1956 Joseph F. Engelberger, director de ingeniería de la división
aeroespacial de la empresa Manning Maxwell y Moore en Stanford, Conneticut.
Juntos Devol y Engelberger comenzaron a trabajar en la utilización industrial de sus
máquinas, fundando la Consolidated Controls Corporation, que más tarde se
convierte en Unimation(Universal Automation), e instalando su primera máquina
Unimate (1960), en la fábrica de General Motors de Trenton, Nueva Jersey, en una
aplicación de fundición por inyección.
En 1968 J.F. Engelberger visito Japón y poco más tarde se firmaron acuerdos
con Kawasaki para la construcción de robots tipo Unimate. El crecimiento de la
robótica en Japón aventaja en breve a los Estados Unidos gracias a Nissan, que
formo la primera asociación robótica del mundo, la Asociación de Robótica industrial
de Japón (JIRA) en 1972. Dos años más tarde se formó el Instituto de Robótica de
América (RIA), que en 1984 cambio su nombre por el de Asociación de Industrias
Robóticas, manteniendo las mismas siglas (RIA).
Por su parte Europa tuvo un despertar más tardío. En 1973 la firma sueca
ASEA construyo el primer robot con accionamiento totalmente eléctrico, en 1980 se
fundó la Federación Internacional de Robótica con sede en Estocolmo Suecia.
Figura 2. Brazo ensamblador
Recuperado de http://proton.ucting.udg.mx/materias/robotica/r166/r63/r63.htm
23
La
configuración
de
los
primeros
robots
respondía
a
las
denominadas
configuraciones esférica y antropomórfica, de uso especialmente valido para la
manipulación. En 1982, el profesor Makino de la Universidad Yamanashi de Japón,
desarrolla el concepto de robot SCARA (Selective Compliance Assembly Robot Arm)
que busca un robot con un número reducido en grados de libertad (3 o 4), un coste
limitado y una configuración orientada al ensamblado de piezas, ver figura 2.
La definición del robot industrial, como una máquina que puede efectuar un
número diverso de trabajos, automáticamente, mediante la programación previa, no
es válida, porque existen bastantes máquinas de control numérico que cumplen esos
requisitos. Una peculiaridad de los robots es su estructura de brazo mecánico y otra
su adaptabilidad a diferentes aprehensores o herramientas. Otra característica
especifica del robot, es la posibilidad de llevar a cabo trabajos completamente
diferentes e, incluso, tomar decisiones según la información procedente del mundo
exterior, mediante el adecuado programa operativo en su sistema informático.
Se pueden distinguir cinco fases relevantes en el desarrollo de la Robótica
Industrial:
1. El laboratorio ARGONNE diseña, en 1950, manipuladores amoesclavo para manejar material radioactivo.
2. Unimation, fundada en 1958 por Engelberger y hoy absorbida por
Whestinghouse, realiza los primeros proyectos de robots a principios
de la década de los sesentas de nuestro siglo, instalando el primero en
1961 y posteriormente, en 1967, un conjunto de ellos en una factoría
de general motors. Tres años después, se inicia la implantación de los
robots en Europa, especialmente en el área de fabricación de
automóviles. Japón comienza a implementar esta tecnología hasta
1968.
3. Los laboratorios de la Universidad de Stanford y del MIT acometen, en
1970, la tarea de controlar un robot mediante computador.
24
4. En el año de 1975, la aplicación del microprocesador, transforma la
imagen y las características del robot, hasta entonces grande y
costoso.
5. A partir de 1980, el fuerte impulso en la investigación, por parte de las
empresas
fabricantes
de
robots,
otros
auxiliares
y
diversos
departamentos de Universidades de todo el mundo, sobre la
informática aplicada y la experimentación de los sensores, cada vez
más perfeccionados, potencian la configuración del robot inteligente
capaz de adaptarse al ambiente y tomar decisiones en tiempo real,
adecuarlas para cada situación.
En esta fase que dura desde 1975 hasta 1980, la conjunción de los efectos
de la revolución de la Microelectrónica y la revitalización de las empresas
automovilísticas, produjo un crecimiento acumulativo del parque de robots, cercano
al 25%.
La evolución de los robots industriales desde sus principios ha sido
vertiginosa. En poco más de 30 años las investigaciones y desarrollos sobre robótica
industrial han permitido que los robots tomen posiciones en casi todas las áreas
productivas y tipos de industria. En pequeñas o grandes fábricas, los robots pueden
sustituir al hombre en aquellas áreas repetitivas y hostiles, adaptándose
inmediatamente a los cambios de producción solicitados por la demanda variable.
(Ingenierías, 2004)
2.2 MARCO CONTEXTUAL
2.2.1Desarrollo de Software en Colombia
Debido a que el mundo de la informática es susceptible al cambio
constantemente, de igual manera debido a que en Colombia no se han creado las
condiciones necesarias para un desarrollo del software con el sello Made in
Colombia. Es claro que el desarrollo del software en Colombia es monopolizado
por grandes multinacionales como indra, Softec, Unisys, etc. Esto indica que en
25
nuestro pais el talento humano especializado para el desarrollo del software es
uno de los mejores a nivel internacional.
El desarrollo del software colombiano a pesar de sus inconvenientes ha
tenido un leve crecimiento en los últimos años ( 2010 y 2011), se cuentan con más
de 40 empresas certificadas, se ha visto también un descenso en piratería, en
este panorama se pueden encontrar algunas oportunidades como la integración
de servicios técnicos, el desarrollo de aplicaciones y modernización, outsourcing
de infraestructura tecnológica, servicios de apoyo, gestión de data center entre
otros, como lo plantea Proexport y Osec en un estudio relacionado con sector, en
el cual también se afirma que:
El sector de las TICs en Colombia está compuesto por PYMEs. En términos
de tecnología y profesionalismo, estas compañías están operando a buen
nivel. Estas compañías por lo general no tienen vocación exportadora y les
hace falta la experiencia necesaria. La mayoría de estas empresas son
familiares y la estructura financiera está orientada hacia los negocios locales
y no hacia el riesgo, como el que representa exportar. Las tecnologías que se
implementan están a la par con las tecnologías de punta. (OSEC y
PROEXPORT, 2012)
En Medellín hay unas 100 desarrolladoras de software. Un gran porcentaje se
agrupa en la Red Intersoftware, que promueve la calidad de esta industria, y
cuyas empresas generan el 80% del empleo del sector en la región; unos 3.200
puestos. (COLOMBIANO, 2013)
El segmento del software está representado por el software estándar. El
software a la medida forma parte del segmento de servicios (integración y
desarrollo).
26
Los segmentos del mercado dentro del sector de servicios colombianos de
TI1 son:





Soporte y Mantenimiento
Contratación externa
Integración y Desarrollo
Consultoría
Educación y Entrenamiento (OSEC y PROEXPORT, 2012)
La educación impartida por las universidades es de alto estándar, sin
embargo, hay una clara deficiencia en el campo de formación profesional.
Esta situación ya representa un gran reto para Colombia en cuanto a
contratar empleados que estén bien capacitados a todo nivel y en todas las
áreas del conocimiento. En caso que las exportaciones generen una gran
demanda de empleados calificados, el sistema actual no estaría en
capacidad de atenderla. (OSEC y PROEXPORT, 2012)
En la figura 3, se puede observar la participación del software en el mercado
nacional con respecto a las tecnologías de información lo cual deja ver claramente
que el hardware ocupa la mitad de la participación, dejando al software un escaso
7%, lo cual da muestras de todo el camino por recorrer en cuanto a desarrollo de
software, llenando de contenido lo planteado, el desarrollo de software en
Colombia está muy bajo.
El software y las aplicaciones estándar se ajustan a las normas (Iso, Spice,
CMM) y mercados internacionales. En Colombia no hay software con
estándares específicos. Algunas de las soluciones de software utilizarán los
parámetros establecidos por el mercado local (por ejemplo los sistemas
contables). La mayoría de las interfaces con los usuarios para las
aplicaciones estándar son en español. (OSEC y PROEXPORT, 2012)
1
TI Tecnologías de la Información .
27
Figura 3. PARTICIPACIÓN DE LOS SEGMENTOS DEL TI 2008 (OSEC Y PROEXPORT).
Software
[PORCENTAJE]
Hardware
[PORCENTAJE
]
Servicios
[PORCENTAJE
]
Recuperado de: Proexport Colombia Industria BPO-IT
Uno de los problemas en el desarrollo del software se encuentra que las
empresas y los desarrolladores (léase y entiéndase programadores) creen que
desarrollar software es escribir tres líneas de código y hacer clic pero esto no es así.
En este sentido en cuanto a la educación este mismo estudio plantea:
El sistema educativo en la fase de pregrado tiene tres niveles diferentes, el
nivel técnico, nivel tecnológico, y nivel profesional. En el nivel profesional se
está presentando diferentes conflicto con las compañías que quieren un alto
nivel educativo pero a un bajo costo, muchas de las universidades no están
orientadas a la investigación que nos lleve a enfocar la implementación de
acciones encaminadas hacia la creación de un valor agregado y obtener
relaciones internacionales con universidades de talla mundial. Son pocas las
personas que cuentan con un buen nivel educativo; no están dispuestos a
trabajar en proyectos educativos como desarrollo de software, pruebas,
investigación etc. Las compañías están orientadas fundamentalmente hacia
los negocios y la tecnología. Por esta razón requieren de mano de obra con
capacidades que se ajusten a todas las áreas de competencia de las TIC.
(OSEC y PROEXPORT, 2012)
28
2.2.2Desarrollo de las TIC en Risaralda
La Gobernación de Risaralda ha puesto en marcha una política educativa que
buscar hacer uso de las TIC para transformar la sociedad. Por ello estamos
trabajando para que los alumnos de los planteles públicos, desde la primera infancia,
estén inmersos en el bilingüismo y el acceso a las nuevas tecnologías de la
información y la comunicación.
Resulta inaceptable que exista una brecha profunda entre la formación que
reciben los estudiantes de planteles oficiales y sus pares de los colegios privados.
Por ello hemos dicho que las instituciones educativas del sector oficial, deben
marchar a la par con los avances de la ciencia, la tecnología y la innovación. No
existe otro camino para romper con los paradigmas de la pobreza y la desigualdad.
Pero también está claro que el acceso a la formación y el uso de estas
tecnologías debe extenderse a otros segmentos de la población, en especial al
sector empresarial y productivo.
En este orden de ideas, la Gobernación de Risaralda ha construido una
interesante alianza con la Cámara de Comercio de Pereira, en el marco de la cual
nos propusimos instalar esta Mesa TIC del Triángulo del Café. El propósito principal
de esta iniciativa es el de consolidar criterios y desarrollar actividades que atiendan
las necesidades de las empresas industriales en materia de tecnologías de la
información y la comunicación y que las acerque a las oportunidades que se abren
en un mundo moderno como el actual.
Así lo planteamos hace algunas semanas, al presentar el Clúster TIC del
Triángulo del Café, ante varias empresas, organizaciones e
instituciones
académicas de la región que han venido incursionando en el desarrollo de empresas
con base tecnológica.
29
Con la instalación de la mesa TIC de Risaralda no solo la visibilidad de las
empresas de la industria TIC del departamento será mayor ante el Ministerio y la
misma industria,
sino que también tendremos un proceso local incluyente y
articulado entre las empresas, la academia y el estado con base en los
requerimientos reales del sector y que permita preparar a las empresas TIC en
procesos de calidad más sólidos y por ende participar en ejercicios comerciales
nacionales e internacionales mucho más exitosos.
En Risaralda tenemos algunos ejemplos muy positivos en esta dirección,
como lo es el caso de empresas acogidas por ParqueSoft, las cuales han
desarrollado
innovaciones
supremamente
interesantes
que
les
han
valido
reconocimientos y premios a nivel internacional. (MINTIC, 2015)
Como respuesta de ayuda a solucionar alguno de los anteriores problemas la
Universidad Católica de Pereira está trabajando en la investigación de nuevos
proyectos, tiene como objetivo liderar y ejecutar los recursos de un nuevo proceso
para la enseñanza y el aprendizaje llamada PHYSYLAB, con el acompañamiento de
la Universidad Católica de Manizales y la Universidad de Medellín apoyando
el
desarrollo de laboratorios remotos y virtuales para enseñanza de la Física, bajo el
esquema de laboratorio distribuido, usando para esto la instrumentación como
herramientas indispensables en el desarrollo de equipos que puedan ser accedidos
de manera Remota. Para que estos puedan ser manipulados de manera remota y se
puedan crear un conjunto de prácticas de laboratorio de Física en el área de
mecánica clásica, donde puedan ser ejecutadas por los estudiantes y docentes que
se encuentren conectados a la red académica de Alta Velocidad (RENATA). Estos
laboratorios se diseñan de tal forma que permita mejorar las estrategias de
enseñanza y aprendizaje para cursos de Física a nivel básico e intermedio.
(PHYSILAB, 2012)
Este proyecto de investigación nace en el seno del Grupo de Investigación
GEMA , Grupo de investigación de la Universidad Católica de Pereira en asocio con
las universidades Católica de Manizales y la Universidad de Medellín y que fue
30
aprobado en la convocatoria “banco de proyectos elegibles para apoyar la
investigación, el desarrollo y la innovación educativa que (PHYSILAB, 2012) hagan
uso de la infraestructura y servicios de la red nacional académica de tecnología
avanzada (RENATA) para el año 2010”, convocatoria financiada por el Ministerio de
Educación Nacional.
2.3 MARCO CONCEPTUAL
2.3.1 Brazo robot
Por décadas
mecánicas
las personas siempre han tratado de
que traten de
imitar
construir maravillas
partes del cuerpo humano. En 1805, Henri
Maillardert fabrico una muñeca que sería capaz de hacer dibujos. De esta manera
se fueron evidenciando algunas creaciones mecánicas que fueron reflejando el
ingenio del hombre para poder ir acercando más y más
comodidades. En esa misma época
a una época de
hubieron muchas más invenciones
que
ayudaron a las industrias en su agilidad para hacer los procesos en el transcurso de
la revolución industrial, y casi siempre dirigidas al sector de la industria textil de esa
época. Entre las cuales se hace notar la hiladora giratoria de Hargreaves (1770)), el
telar mecánico de Cartwright (1785) la hiladora mecánica de Crompton (1779), y
otros.
Figura 4. RELACIÓN ENTRE UN BRAZO ROBOT Y UN BRAZO HUMANO
https://www.interempresas.net/Robotica
31
Un brazo robot es un brazo mecánico, como muestra en la figura 4, con
funciones y movimientos parecido a los de un brazo humano, es un manipulador
multifuncional; normalmente
reprogramable con varios grados de libertad, está
compuesto de materiales
electrónicos y su estructura que sostienen los
mecanismos; estos son interconectados a través de articulaciones capaz de realizar
Infinidad de actividades repetitivas, manipulando diferentes materiales dependiendo
de la programación o rutinas que previamente se haya ingresado en su tarjeta
controladora.
La robótica ha avanzado de tal manera que ya se incluyen poderosas
computadoras al interior de los robots las cuales son fusionadas con actuadores
mecánicos alimentados de nuevos controles o software para una tarea específica y
así agilizar nuevas tareas dentro de la industria.
2.3.2 Tipos de brazo robot
2.3.2.1 Brazo cartesiano
Figura 5. BRAZO ROBOT CARTESIANO
Recuperado de https://www.interempresas.net/Robotica
Como se observa en la figura 5, este brazo es utilizado habitualmente para
tomar y colocar, en algunos casos para operaciones de manipulación de
herramientas
o ensamblado, esta clase de brazo maneja tres articulaciones
coinciden en los ejes del plano cartesiano, esto quiere decir que los ejes principales
para el control del brazo son lineales, esta clase de brazo se mueve en línea recta.
32
2.3.2.2 Brazo cilíndrico
En la figura 6 muestra un brazo que es utilizado habitualmente para tareas de
ensamblaje, soldadura de puntos, y cuyo eje forma una relación de coordenadas
cilíndricas.
Figura 6. BRAZO ROBOT CILÍNDRICO
Recuperado de https://www.interempresas.net/Robotica
2.3.2.3. Brazo esférico / polar
Es usado en aplicaciones sobre manipulación de diferentes tipos de
máquinas, en este caso
sus ejes que
forman un sistema de coordenadas
cilíndricas. Es usado en aplicaciones sobre manipulación de diferentes tipos de
máquinas, en este caso
sus ejes que
forman un sistema de coordenadas
cilíndricas, en la figura 7, nos muestra un brazo robot polar.
Figura 7. BRAZO ROBOT POLAR
Recuperado de https://www.interempresas.net/Robotica
33
2.3.2.4 Brazo articulado
Se utiliza en tareas de ensamblaje y diferentes funciones, por otro lado este
brazo el momento trabaja con tres articulaciones, lo cual no lo hace multifuncional,
como lo muestra en la figura 8.
Figura 8. BRAZO ROBOT ARTICULADO
Recuperado de https://www.interempresas.net/Robotica
2.3.2.5 Robot paralelo
En la figura 9, nos muestra un breve ejemplo de estos brazos es la
manipulación de las cabinas de simuladores de vuelo en la aeronáutica, estos brazos
sus articulaciones son de tipo prismáticas y rotatorias.
Figura 9. BRAZO ROBOT PARALELO
Recuperado de https://www.interempresas.net/Robotica
34
2.3.2.6 Brazo antropomórfico
En la figura 10, nos muestra que este brazo es muy similar a un brazo
humano, y lo que busca es la sustitución de un brazo humano y necesidades de esta
sociedad. (DOCSETOOLS.COM, 2008)
Figura 10. BRAZO ROBOT ANTROPOMÓRFICO
Recuperado de https://www.interempresas.net/Robotica
3. ARQUITECTURA DEL SOFTWARE
Es importante brindar un panorama general de lo que es la Arquitectura del
Software como una disciplina emergente que poco a poco se abre paso en los
espacios académicos, muy a pesar de fosilizados docentes que creen que
desarrollar software es simplemente tirar código, lo cual se traduce en una
separación, en una dicotomía entre la formación académica y el qué hacer industrial,
precisamente en ese sentido, (Reynoso, 2004) citando a Jan Bosch plantea que
existe una considerable diferencia entre la práctica industrial y la percepción
académica de la arquitectura del Software, es decir, que los problema de la
academia no son los mismos problemas de la industria. Por ello es importante
avanzar en eliminar tal brecha. Como es sabido los patrones de diseño fueron
fundamentalmente orientados a servicios, estableciendo una limitante en el avance y
el desarrollo de la disciplina, situación está que ya ha dado pasos importantes, por
ello las cuestiones teóricas y metodológicas del diseño y la arquitectura se han
35
quedado a medio elaborar, y por parte de los docentes en las aulas a medio
mencionar.
Si bien los orígenes de la Arquitectura se pueden remontar a los años 90, con
unos primeros párrafos de Mary Shaw o David Garlan, tales referencias solo son de
carácter histórico, por lo que es necesario acudir a la literatura más reciente, es
decir, como la de (Reynoso, 2004) quien plantea que esos orígenes difusos permiten
distinguir corrientes de pensamiento diversas, cuyas diferencias distan de ser
triviales a la hora de plasmar las ideas en una metodología en este sentido y según
la literatura revisada se halló que no se habla de una metodología única, sino de una
serie de metodologías, como se verá más adelante.
En esta búsqueda por los orígenes de la Arquitectura del Software se halló
que la Universidad Tecnológica de Eindhoven en Holanda Edsger Dijkstra, sostenía
que las ciencias de la computación debían ser una rama aplicada de las
matemáticas, para lo cual sugería descomponer los problemas mayores en pasos
lógico formales a seguir para llegar a la resolución de un problema (Reynoso, 2004).
Fue pionero en proponer que los sistemas operativos estén organizados “como
capas de cebolla”; igualmente ayudó a precisar una serie de conceptos que para
cualquier ingeniero de sistemas son básicos, como el algoritmo del camino más
corto, los stacks, vectores, semáforos, entre otros, además de acuñar otro concepto
tras dar luces de respuesta a la problemática de la computación, donde la mayor
dificultad es escribir programas de cómputo libres de defectos, comprensibles,
mantenibles y verificables, denominado “crisis del software.. Los conceptos de
Dijkstra sentaron las bases para lo que luego fue llamado “programación en grande”;
precisamente P.I. Sharp, en la conferencia NATO n1969 dice acerca del genio
holandés; el piensa que tienen algo muy aparte de la ingeniería del software, algo de
lo que se ha hablado muy poco pero que debería poner sobre la mesa, para
concentrarse más en ello. Como ejemplo habla sobre OS/360 que están
extremadamente bien codificadas; su diseño fue delegado a varios ingenieros, cada
uno de ellos realizo su propia arquitectura y cuando todas estas partes se integraron
en una sola no produjeron una tersa y bella pieza de software. (Reynoso, 2004)
36
Y la siguiente frase es más que visionaria, es una profecía para tiempos de
caos, en los que décadas después los ingenieros están perdidos en lo referente a la
ingeniería y arquitectura del software, en este sentido Sharp continúa: indica que lo
que sucede es que las especificaciones de software se creen son funcionales. En
este caso solo hablamos de lo que puede hacer el programa. Dice que cualquier
desarrollador responsable de la implementación o partes del software debe
especificar más que esto, debe especificar el diseño, la forma; dentro de este marco
de referencia los desarrolladores de software deben crear algo.(Reynoso, 2004)
Ya para el año de 1975, aparece la publicación del diseñador del sistema
operativo OS/360, quien utilizaba el concepto de “arquitectura del sistema” para
designar la relación especifica del usuario con una interfaz específica, comparando al
arquitecto del software con el arquitecto de una casa [Brooks, 75] citado por
(Reynoso, 2004)
Sin embargo en el sentido estricto del término la expresión
Arquitectura del Software fue usada concretamente hasta el año de 1992 por Perrry
Wolf, diciendo que el propósito es construir el fundamento para la arquitectura del
software, donde primero se desarrollaran una percepción, recurriendo a diferentes
disciplinas de arquitectura bien definidas. Sobre la base de esta percepción, Perry
Wolf presenta un modelo para la arquitectura del software que consiste en tres
componentes: elemento, forma y razón. Los elementos son
los procesamientos,
datos o conexión. La forma son las propiedades, restricciones de la relación entre
los elementos. La razón proporciona una base para la arquitectura en término de
restricciones (Reynoso, 2004). En este sentido puede resultar útil estas analogías
guardadas, resaltando los tres componentes fundamentales que son elementos,
razón y forma, los cuales al moldearse en un mismo sistema de diseño, permite
ampliar las posibilidades eliminando las restricciones, por el contrario permitiendo el
desarrollo del software, allanando el camino para el futuro desarrollo de los
estándares de calidad y unificación en el modelado.
37
3.1 UML
El lenguaje unificado de modelado UML permite modelar visualmente los
sistemas de información y tiene como objeto el escribir con cierta formalidad los
sistemas de información, esto para especificar, visualizar, construir y documentar los
artefactos de un software. Está pensado para usarse con los métodos de desarrollo,
sus etapas del ciclo de vida, dominios de aplicación y medio. Igualmente es
concebido para ser utilizado en herramientas interactivas de modelado visual que
tengan generadores de código así también como generadores de informes. UML fue
adoptado unánimemente como estándar en noviembre de 1997, asumiendo la
responsabilidad de futuros desarrollos en el estándar de modelado. El surgimiento de
UML fue atractivo para el público informático ya que se pretende apoyar tanto la
expansión del uso del modelado a objetos, como la aparición de nuevas
herramientas de formación y utilización, teniendo en cuenta que ya no hay que
pensar en metodologías a usar y mantener. (Booch, Jacobson, & Rumbaugh, 2000)
Cómo se observa en la figura 11, UML está pensado para cubrir una serie de
necesidades en el proceso de diseño de un software, relacionándolo a diferentes
procesos que proporcionan a los desarrolladores de software, a los arquitectos de
sistemas, y a los ingenieros de software las herramientas necesarias para el análisis,
diseño, implementación de los sistemas de software. Su función es capturar las
partes esenciales del sistema para desarrollar, probar y mejorar más fácilmente
dicho software. (Booch, Jacobson, & Rumbaugh, 2000)
38
Figura 11. MAPA MENTAL DE LOS PROCESOS UML
Recuperado de http://lizeth-hoyseraundiamas.blogspot.com/2009/09/mapa-mental-uml.html
El modelado se puede considerar como la espina dorsal del desarrollo de
software con alta calidad, el cual busca representar los planos del software, es decir,
buscado visualizar lo que el cliente quiere que haga el sistema, especificar la
estructura o comportamientos del mismo, proporcionar plantillas que guíen al
desarrollador en la construcción, además de documentar las decisiones tomadas;
proporcionando un vocabulario con reglas de utilización y representación conceptual
de los modelos que pueden ser interpretados por algunas personas que no hayan
participado en su diseño. (Booch, Jacobson, & Rumbaugh, 2000)
Como muestra en la figura 12, los diagramas UML se dividen en diagramas
de estructura y diagramas de comportamiento, los primeros a su vez se dividen en
39
diagramas de clases, diagramas de componentes, diagrama de despliegue,
diagramas de paquetes, diagrama estructura compuesta y diagramas de objetos; los
diagramas de comportamiento se dividen en diagramas de estado, diagrama de
casos de uso, diagramas de actividades y diagramas de interacción, estos últimos a
la vez se dividen en diagramas de secuencia, diagramas de colaboración, diagrama
global de interacción y diagrama de tiempos. Sin embargo al realizar el modelado de
un software no es necesario realizar todos los diagramas propuestos por UML,
debido a que se debe analizar la importancia que puede tener cada diagrama para el
tipo de desarrollo a realizar, y así poder generar los diseños de los diagramas que se
consideren relevantes según las características del software.
Para definir cualquier modelo es necesario contar con un lenguaje de
modelado. Los metamodelos definen formalmente la sintaxis abstracta de los
lenguajes de modelado, recogiendo sus conceptos (palabras del lenguaje), así como
las reglas que indican cómo se pueden combinar dichos conceptos para formar
modelos válidos.
Por otra parte, la representación asociada a cada uno de los
elementos del modelo (conceptos y relaciones) constituye la sintaxis concreta del
lenguaje.
40
Figura 12. UML DIVISIÓN DE DIAGRAMAS ESTRUCTURALES
Recuperado de http: http://www.uml-diagrams.org/uml-24-diagrams.png
3.2 JAVA
Java hacia el año de 1991 cuando un grupo de ingenieros de Sun
Microsystems, buscaban diseñar un lenguaje de programación independiente de las
máquinas utilizadas, ya que éstas eran cada vez más reducidas. En este sentido se
diseñó
un código neutro que no dependía del tipo de CPU utilizado, éste se
ejecutaba sobre una máquina hipotética o virtual denominada "Java virtual machine".
41
Esta interpretaba el código neutro convirtiéndolo al código particular de cada CPU. Al
programar en Java el desarrollador no parte desde cero, sino que cuenta con un
gran número de clases pre-existentes, algunas hechas por el mismo. (TUTORIAL DE
JAVA)
El principal objetivo del lenguaje es llegar a ser el nexo universal que conecte
a los usuarios con la información, sitúan un ordenador local, en la web, en una base
de datos, o en cualquier otro lugar.
3.3 NETBEANS
NetBeans es un entorno desarrollo integrado (IDE) de carácter libre, el cual
fue hecho principalmente para el lenguaje de programación Java. Este proyecto de
código abierto tiene gran éxito, con una comunidad de usuarios en constante
crecimiento.
Esta plataforma permite que las aplicaciones sean desarrolladas a partir de
módulos, entendiendo un módulo como un archivo Java para interactuar con las
aplicaciones de Netbeans y un activo especial que lo identifica como tal. El hecho de
desarrollar los módulos independientemente permite que las aplicaciones basadas
en esta plataforma puedan ser extendidas o ampliadas por otros desarrolladores.
(Netbeans.org, 2014)
3.4 ARDUINO
Es
una
plataforma
de hardware
libre,
basada
en
una placa con
un microcontrolador y un entorno de desarrollo, diseñada para facilitar el uso de la
electrónica en proyectos multidisciplinares.
Se puede usar Arduino para crear objetos interactivos, leyendo datos de una
gran variedad de interruptores y sensores y controlar multitud de tipos de luces,
motores y otros actuadores físicos. Los proyectos de Arduino pueden ser autónomos
o comunicarse con un programa (software) que se ejecute en tu ordenador (ej. Flash,
Processing, MaxMSP). La placa se puede montar por cualquier persona o comprarla
42
ya lista para usar, y el software de desarrollo es abierto y se puede descargar gratis.
(ARDUINO ORG, 2012)
3.5 METODOLOGIAS DE PROGRAMACION
3.5.1 Rapid application development (Rad)
La metodología de desarrollo rápido de aplicaciones (RAD) se desarrolló para
responder a la necesidad de entregar sistemas muy rápido. El enfoque de RAD no es
apropiado para todos los proyectos. El alcance, el tamaño y las circunstancias, todo
ello determina el éxito de un enfoque RAD.
El método RAD tiene una lista de tareas y una estructura de desglose de
trabajo diseñada para la rapidez. El método comprende el desarrollo iterativo, la
construcción de prototipos y el uso de utilidades CASE (Computer Aided Software
Engineering). Tradicionalmente, el desarrollo rápido de aplicaciones tiende a
englobar también la usabilidad, utilidad y rapidez de ejecución.
El desarrollo rápido de aplicaciones es un proceso de desarrollo de software,
desarrollado inicialmente por James Martin en 1980. El término fue usado
originalmente para describir dicha metodología. La metodología de Martin implicaba
desarrollo iterativo y la construcción de prototipos. Más recientemente, el término y
su acrónimo se están usando en un sentido genérico, más amplio, que abarca una
variedad de técnicas dirigidas al desarrollo de aplicaciones rápidas.
RAD requiere el uso interactivo de técnicas estructuradas y prototipos para
definir los requisitos de usuario y diseñar el sistema final. Usando técnicas
estructuradas, el desarrollador primero construye modelos de datos y modelos de
procesos de negocio preliminares de los requisitos. Los prototipos ayudan entonces
al analista y los usuarios a verificar tales requisitos y a refinar formalmente los
modelos de datos y procesos. El ciclo de modelos resulta a la larga en una
combinación de requisitos de negocio y una declaración de diseño técnico para ser
usado en la construcción de nuevos sistemas, como muestra la figura 13.
(gestionrrhhusm, 2011)
43
Figura 13. RAPID APPLICATION DEVELOPMENT (RAD).
Recuperado de: http://www.zlouatom.ru/wp-content/uploads/2013/04/rad.png
Los enfoques RAD pueden implicar compromisos en funcionalidad y
rendimiento a cambio de permitir el desarrollo más rápido y facilitando el
mantenimiento de la aplicación. (gestionrrhhusm, 2011)
3.5.2 Rational unified process (Rup)
El proceso unificado Rational (RUP) es un marco de trabajo de proceso de
desarrollo de software iterativo creado por Rational Software Corporation, una
división de IBM desde 2003. RUP no es un proceso preceptivo concreto individual,
sino un marco de trabajo de proceso adaptable, con la idea de ser adaptado por las
organizaciones de desarrollo y los equipos de proyecto de software que
seleccionarán los elementos del proceso que sean apropiados para sus
necesidades, como muestra la figura 14. (gestionrrhhusm, 2011)
44
Figura 14. RATIONAL UNIFIED PROCESS (RUP).
Recuperado de: http://projects.staffs.ac.uk/suniwe/images/rup-cycle.gif
RUP fue originalmente desarrollado por Rational Software, y ahora disponible
desde IBM. El producto incluye una base de conocimiento con artefactos de ejemplo
y descripciones detalladas para muchos tipos diferentes de actividades.
RUP resultó de la combinación de varias metodologías y se vio influenciado
por métodos previos como el modelo en espiral. Las consideraciones clave fueron el
fallo de proyectos usando métodos monolíticos del estilo del modelo en cascada y
también la llegada del desarrollo orientado a objetos y las tecnologías GUI, un deseo
de elevar el modelado de sistemas a la práctica del desarrollo y de resaltar los
principios de calidad que aplicaban a las manufacturas en general al software.
(gestionrrhhusm, 2011)
3.5.3 Cascada
En este modelo los pasos del desarrollo son vistos hacia abajo, a través del
análisis de las necesidades, el diseño, pruebas, implantación, integración y
mantenimiento como lo muestra la figura 15. (gestionrrhhusm, 2011)
45
Figura 15. MODELADO EN CASCADA
Recuperado de: http://www.gavide.com/images/page10_img1.jpg
Los principios básicos para este modelo son:



Este modelo está dividido en secuencias
Se hace insistencia en la parte de organización, horas, fechas,
presupuestos y la actuación del sistema una sola vez
La documentación de todo el proceso realizado, comentarios y
aprobación por el usuario.
3.5.4 Prototipado
Como se muestra en la figura 16, este modelo permite desarrollar los
modelos para aplicaciones de software que deja ver el funcionamiento básico del
mismo, condesciende al cliente verificar el producto temprana mente, el usuario tiene
una interacción con los diseñadores y desarrolladores para revisar si se está
cumpliendo satisfactoriamente con los requisitos y las funcionalidades anteriormente
acordadas. (gestionrrhhusm, 2011)
46
Figura 16. MODELADO EN PROTOTIPADO
Recuperado de: http://www.gavide.com/images/page10_img1.jpg
3.5.5 Incremental
Proporciona una estrategia para inspeccionar la complejidad de los riesgos,
reservando una parte del producto software para algunos aspectos en el futuro,
como muestra la figura 17. (gestionrrhhusm, 2011)
Figura 17. MODELO INCREMENTAL
Recuperado de: http://sg.com.mx/images/stories/200602/praticas_procesos_1.gif
47
Algunos de los principios son:



Se realiza una mini cascada para una parte del sistema, antes de
seguir con el proceso incremental.
Se realiza una mini cascada del desarrollo para cada uno de los
incrementos del sistema.
Se utiliza un enfoque de cascada para el análisis de las necesidades y
el diseño de la arquitectura, que finaliza con la instalación del prototipo
final o terminado. (gestionrrhhusm, 2011)
3.5.6 Espiral
Los principios básicos de este modelo son:

Se centra más que todo en la evaluación y reducción de los riesgos
del proyecto, dividiéndolo por segmentos pequeños para más facilidad
al proceso de cambio durante el desarrollo del mismo, también deja
ver la posibilidad de evaluar los riesgos con la aplicabilidad en el
proyecto durante todo el ciclo de vida.

Cada vez que realiza el proceso del espiral atraviesa cuatro enfoques
muy básicos:
1. Determinar objetivos, alternativas, y desencadenantes de la
iteración
2. Evaluar, identificar y solucionar los riesgos.
3. Desarrollar y verificar los resultados.
4. El ciclo siempre se comienza con el usuario y sus requisitos para
luego terminar con la revisión. (gestionrrhhusm, 2011)
La figura 18, muestra los enfoques básicos de esta metodología.
48
Figura 18. MODELADO EN ESPIRAL
Recuperado de: http://www.tutorialspoint.com/sp/software_engineering/images/sdlc_spiral.png
3.6 METODOLOGIA SELECCIONADA
Para el desarrollo del proyecto se realizó la búsqueda necesaria de las
diferentes tipos de metodología; acoplándose de una mejor forma la metodología de
la programación en cascada, debido a que se tienen claro cada uno de los procesos
que va realizar el sistema. Teniendo la necesidad de software requerida y analizando
en términos generales que el proyecto a desarrollar no es tan robusto, de manera
que no exige de un gran rendimiento de la metodología, sin embargo la misma es
una de las utilizadas por su facilidad y por buen desempeño en los proyectos, esta se
puede definir en los siguientes pasos:
Análisis: Esta consiste en levantar la información actual del problema y
proponer los casos generales de la solución.
49
Diseño: Permite describir o establecer los componentes o módulos que
formarán el software para ser producido. Donde, describen, con mucho detalle, cada
módulo que contendrá el sistema, y que operación va realizar.
Desarrollo: Esta consiste en desarrollar cada uno de los módulos creación
“física” donde se hacen los procesos de codificación, implementación de interfaz y
más.
Pruebas: Permite llegar al momento de verificar que el sistema es
consistente con la definición de requisitos y la especificación funcional.
Mantenimiento: El mantenimiento ocurre cuando existe algún problema
dentro de un sistema existente, e involucraría la corrección de errores que no fueron
descubiertos en las fases de prueba.
De acuerdo con la metodología y su estructura secuencial, cuando se finaliza
una etapa se lleva a cabo un proceso de revisión en el que se verifica el
cumplimiento de los requerimientos o de todos las actividades de esta etapa, para
así, dar paso a la siguiente etapa y continuar con los procesos de la metodología;
pero cuando se encuentran inconsistencias, se solucionan para así continuar con el
proceso, lo cual permite tener una reducción de errores al momento de implementar
el sistema.
4. ESPECIFICACION DE LA SOLUCION
4.1 REQUERIMIENTOS
Un requerimiento es la característica que debe tener determinado sistema de
cómputo, a su vez un requerimiento es una restricción que el sistema debe cumplir
para que de este modo pueda ser aceptado por la persona o entidad que demande
un software acorde a sus necesidades. Si el requerimiento se entiende como una
condición, una capacidad de una necesidad a cumplir por el usuario debe también
ser una representación documentada de esta condición o capacidad. El
50
requerimiento es necesario para que no hayan deficiencias en el sistema, debe ser
conciso fácil de leer, pero a su vez debe de ser completo con la información
suficiente para la comprensión.
Ahora bien, continuando el proceso se llega al paso siguiente es que el
levantamiento de los requerimientos, lo cual se puede entender como una
especificación del sistema de cómputo en los términos más sencillos para que
siguiente lo entienda, lo que a la larga que constituye en el contrato desarrollado
entre ambas partes.
Existen dos clases de requerimientos, los funcionales y los no funcionales.
Los funcionales son los que describen la interacción entre el sistema de cómputo
visual y el ambiente de manera independiente a la implementación; en este sentido
el ambiente incluye un determinado usuario y cualquier otro sistema que de manera
remota, a través de internet, pueda interactuar con el sistema. Para el levantamiento
de los requerimientos se pueden utilizar dos conceptos, los cuales deben ser escritos
en un lenguaje natural o sencillo, es decir, no técnico para que puedan ser
entendidos por el usuario. Los escenarios son usados para describir la aplicación y
su funcionalidad, con ejemplo de los puntos del sistema en términos de interacciones
entre el usuario y el sistema mismo. Continuando en este mismo orden de ideas,
cada escenario es una descripción de situaciones específicas en la aplicación
centrándose directamente en el comportamiento de la misma.
Los requerimientos no funcionales son aquellos que describen aspectos
visibles para el usuario pero que no necesariamente incluyen una relación directa
con el comportamiento funcional del sistema, incluyen restricciones generalmente de
seguridad, de tiempo y precisión. De acuerdo a este marco se procede a realizar la
especificación
de
los
requerimientos
levantados,
clasificación. (Ver Tablas de la 1 a la 7).
51
con
su
correspondiente
Tabla 1. Requerimiento 001
INGENIERIA
(UCP)
DE
SISTEMAS
Y
TELECOMUNICACIONES
CAPTURA Y DESCRIPCIÓN DE REQUERIMIENTOS
Nombre del proyecto:
Fecha:
SOFTWARE PARA EL CONTROL DE UN 18/03/2014
BRAZO ROBÓTICO
Analista Responsable:
Requerimiento Nro.
Juan Carlos Parra
001
Configuración Manual del Movimiento
Descripción del requerimiento:
Permitir la manipulación del brazo a partir de la configuración manual del
movimiento que realizará cada motor.
Tipo de requerimiento
x Funcional
No funcional
Tabla 2. Requerimiento 002
INGENIERIA
(UCP)
DE
SISTEMAS
Y
TELECOMUNICACIONES
CAPTURA Y DESCRIPCIÓN DE REQUERIMIENTOS
Nombre del proyecto:
Fecha:
SOFTWARE PARA EL CONTROL DE UN 18/03/2014
BRAZO ROBÓTICO
Analista Responsable:
Requerimiento Nro.
Juan Carlos Parra
002
Rutina Automática
Descripción del requerimiento:
Permitir que el usuario pueda activar la rutina automática por defecto a ser realizada
por el brazo.
Tipo de requerimiento
X Funcional
No funcional
52
Tabla 3. Requerimiento 003
INGENIERIA
(UCP)
DE
SISTEMAS
Y
TELECOMUNICACIONES
CAPTURA Y DESCRIPCIÓN DE REQUERIMIENTOS
Nombre del proyecto:
Fecha:
SOFTWARE NO FUNCIONAL PARA UN 18/03/2014
BRAZO ROBÓTICO
Analista Responsable:
Requerimiento Nro.
Juan Carlos Parra
003
Verificación de datos ingresados
Descripción del requerimiento:
Delimitar el rango permitido de los grados a ser enviados al dispositivo hardware para
asegurar un correcto funcionamiento del mismo.
{ñ-Tipo
requerimiento
de x Funcional
No funcional
Tabla 4. Requerimiento 004
INGENIERIA
(UCP)
DE
SISTEMAS
Y
TELECOMUNICACIONES
CAPTURA Y DESCRIPCIÓN DE REQUERIMIENTOS
Nombre del proyecto:
Fecha:
SOFTWARE PARA EL CONTROL DE UN 18/03/2014
BRAZO ROBÓTICO
Analista Responsable:
Requerimiento Nro.
Juan Carlos Parra
004
Menú Inicial
Descripción del requerimiento:
Mostrar un menú inicial para la selección de la rutina automática, o la rutina manual
Tipo de requerimiento
Funcional
x No funcional
53
Tabla 5 Requerimiento 005
INGENIERIA
(UCP)
DE
SISTEMAS
Y
TELECOMUNICACIONES
CAPTURA Y DESCRIPCIÓN DE REQUERIMIENTOS
Nombre del proyecto:
Fecha:
SOFTWARE PARA EL CONTROL DE UN 18/03/2014
BRAZO ROBÓTICO
Analista Responsable:
Juan Carlos Parra
Interfaz Intuitiva
Descripción del requerimiento:
Requerimiento Nro.
005
Realizar una interfaz simple, y entendible, de manera que el software pueda ser
utilizado de una manera intuitiva
Tipo de requerimiento
Funcional
X No funcional
Tabla 6. Requerimiento 006
INGENIERIA
(UCP)
DE
SISTEMAS
Y
TELECOMUNICACIONES
CAPTURA Y DESCRIPCIÓN DE REQUERIMIENTOS
Nombre del proyecto:
Fecha:
SOFTWARE PARA EL CONTROL DE UN 18/03/2014
BRAZO ROBÓTICO
Analista Responsable:
Juan Carlos Parra
Requerimiento Nro.
007
Configuración de Retardos
Descripción del requerimiento:
Se debe poder configurar un retardo entre cada movimiento enviado en la sección de
rutina manual con el fin de no desgastar el juego de engranajes que está situado en la
caja reductora del servomotor.
Tipo de requerimiento
X funcional
No funcional
54
Tabla 7. Requerimiento 007
INGENIERIA
(UCP)
DE
SISTEMAS
Y
TELECOMUNICACIONES
CAPTURA Y DESCRIPCIÓN DE REQUERIMIENTOS
Nombre del proyecto:
Fecha:
SOFTWARE PARA EL CONTROL DE UN 18/03/2014
BRAZO ROBÓTICO
Analista Responsable:
Juan Carlos Parra
Requerimiento
Nro.007
Reinicio de Brazo
Descripción del requerimiento:
En el software debe existir la opción de reiniciar el brazo para que el mismo quede en
la posición inicial por defecto.
Tipo de requerimiento
funcional
X No funcional
4.2 PONDERACION DE LOS REQUERIMIENTOS
Tabla 8. Ponderación de Requerimientos
REQUERIMIENTOS
PONDERACIÓN
(%)
CLASIFICACIÓN
Configuración manual del movimiento
Rutina Automática
Verificación de datos ingresados
Configuración de Retardos
20
20
15
Funcional
Funcional
Funcional
15
Funcional
Interfaz intuitiva
10
Menú Inicial
Reinicio de Brazo
TOTAL
10
10
100
55
No
Funcional,
Interfaz
No funcional, Interfaz
No Funcional
4.3 DESCRIPCION DE LA TECNOLOGIA
Para el desarrollo del proyecto se implementaron diferentes tecnologías y
dispositivos hardware que mediante su interconexión logran dar forma al sistema
completo de prototipo físico y producto software. El brazo robótico AS-6DOF fue una
de las tecnologías escogidas con un diseño para realizar movimientos precisos de
alta repetitividad, además su estructura esta hecho de aluminio que nos permite fácil
movilidad e integración en el laboratorio, dentro de la misma estructura del brazo en
función de su movilidad tiene integrado diferentes servomotores de gran precisión
para poder ubicar cada articulación dentro del rango que se requiere en la operación,
estos servomotores tienen una ventaja que pueden ser controlados a través de un
integrado que recibe la señal o instrucciones desde la placa base para poder
controlar la fuerza y la velocidad de su caja reductora. Otro de sus componentes
tecnológicos es el arduino Mega 2560 o la placa base que se utilizó, es ideal para
proyectos de robótica, lo más destacado es su elevada cantidad de pines de entrada
y salida, su
plataforma de hardware es libre y está compuesta de un micro
controlador que después de estar programado ayuda con las tareas de movilidad de
nuestro brazo robótico, tiene un software libre (ID Arduino) para la programación de
las rutinas a integrar en el micro controlador que puede ser instalada en cualquier
sistema operativo, su entorno de desarrollo es diseñado para facilitar la funcionalidad
y programación de diferentes componentes que nos ofrece arduino.
4.3.1 Brazo robótico AS-6DOF
Después de analizar diferentes referencias de brazos robots para su
implementación con el sistema se decidió optar por el brazo robótico AS-6DOF que
se observa en la figura 19, debido a su estructura, porque permite encajar
perfectamente en el laboratorio de PHYSILAB, ya que por su peso, medidas, su
material de aluminio hace que sean elementos más fáciles e importantes a la hora
de integrarlo con otros elementos para el funcionamiento. De otra forma, fue
escogido por su forma de conexión con otros elementos el cual nos permite un
control total de sus movimientos.
56
Figura 19. BRAZO ROBOT AS-6DOF
Recuperado de: http://www.alsrobot.com/index.php?route=product/product&path=65
Es un brazo mecánico que contiene 6 servo motores que ayudan a mover sus
articulaciones, trae internamente un controlador para 32 servomotores, esto quiere
decir que puede manejar esta cantidad de motores al mismo tiempo, para poder
tener la conexión entre el arduino y el computador se debe utilizar una interconexión
USB para que la tarjeta sea reconocida por el computador y así poder manejar el
software de arduino, este entorno de programación es muy parecido a C++ que para
y así se facilita la programación o rutinas que manejarían el brazo robótico,
parámetros son enviados al micro controlador de la placa base que siempre está
activo a recibir instrucciones, estas rutinas son quemadas dentro del micro
controlador
a través de la interfaz del software de arduino y se almacena
inmediatamente para estar listo a ser ejecutado para realizar la rutina o los
parámetros programados en el movimiento de cada uno de los motores del brazo.
57
4.3.2 Arduino mega 2560
Para el desarrollo de este proyecto se tuvieron en cuanta diferentes tarjetas
de la familia Arduino, sin embargo la placa arduino mega 2560 la cual se observa en
la figura 20; fue seleccionada a diferencia de otras placas de éste tipo, incluye un
amplio espacio de
capacidad
memoria para programar y corriendo a 16 Mhz, tiene una
SRAM de 8 KB y cuenta con 54
pines que permite
tener otros
dispositivos similares, es decir, se eligió por sus especificaciones técnicas de alto
rendimiento, lo que lo hace atractivo para diferentes proyectos con alto nivel de
complejidad, además es perfecto pensado en la integración con PHYSILAB (un
proyecto de mayor envergadura) es importante contar con buenas posibilidades de
escalabilidad. El Aduino MEGA 2560 es ideal para los proyectos de robótica con el
control de varios elementos al mismo tiempo, su conexión USB hace más flexible y
fácil a la hora de interactuar con nuestro sistema de cómputo. (ARDUINO ORG,
2012)
Figura 20. ARDUINO MEGA 2560
Recuperado de: http://arduino.cc/en/Main/arduinoBoardMega2560
La tarjeta Arduino Mega está basada en el micro controlador ATmega2560,
esta board es la sucesora de la Arduino MEGA1280, Trae 54 I/O digital de los cuales
podemos usar 14 PWMs, 16 canales de entradas analógicas, 4 puertos seriales a 16
MHz, tiene integrado una conexión a USB, entrada de alimentación tipo Jack y
58
conector ICSP(In-Circuit Serial Programming), su uso es muy sencillo; éste tipo de
Arduino no requiere una programa de control externo, solamente es conectarla a la
tarjeta a través del puerto USB y descargar el programa o instrucciones en su Micro
controlador. (ARDUINO ORG, 2012)
4.3.3 Servomotores
Como se observa en la figura 21 un servomotor es un motor DC que está
conectado a un integrado. El integrado lo que hace es recibir una señal de control,
esta señal es de tipo PWM (pulse-width modulation), que quiere decir modulación
por ancho de pulso, el integrado lo que hace es recibir esta señal y la demodula para
verificar a cuantos grados tiene que girar el motor. El servomotor tiene una parte
mecánica denominada caja reductora, está compuesta de conjunto de engranajes o
piñones que nos proporcionan movimientos precisos aumentando la fuerza del servo
motor. (TdRobotica.co, 2012)
Figura 21. SERVOMOTOR RB-150MG
Recuperado de: http://www.alsrobot.com/index.php?route=product
59
4.4 DESCRIPCION GENERAL DE LA SOLUCION
Realizando el análisis de los requerimientos y de la contextualización del
proyecto se realiza la estructuración del sistema de la siguiente manera:
4.4.1Sistema General
El solución consta de 3 partes fundamentales, el prototipo hardware (Brazo
Robótico), el software para la tarjeta micro-controladora Arduino que permite
el
control del brazo y el Software de escritorio para el control de la tarjeta microcontroladora.
4.4.2 Software en Arduino
El software principal de control del brazo es el desarrollado para el dispositivo
Arduino Mega 2560, puesto que esta tarjeta es la primera capa de control del
dispositivo dentro del sistema general.
El dispositivo debe estar programado de manera que su estructura permita
por medio de parámetros ejecutar las funciones de movimiento que se requieren en
el sistema, como lo son una Rutina Automática, Posicionamiento Inicial y una Rutina
Manual.
La ejecución de la rutina automática se debe realizar al enviar un parámetro
que identifique esta opción dentro del dispositivo Arduino para así ejecutar los
diferentes movimientos (ángulos de posición y retardos) programados internamente,
es decir que se posicione en un objetivo inicial, descienda para agarrar un objeto
determinado, ascienda nuevamente y posteriormente sea llevado hasta una posición
final para soltar el objeto.
La ejecución del posicionamiento inicial, igualmente debe realizarse a partir
del envío de un parámetro que identifique la misma, en el software desarrollado para
el Arduino, y así ejecutar las acciones que permitan que el brazo se ubique en la
posición por defecto para el cual haya sido programado.
60
La ejecución de la rutina manual se realiza a partir del envío de un parámetro
de tipo cadena el cual incluya los valores de todas las posiciones y retardos de
manera que al ser enviado al software creado para la tarjeta, tome dichos
parámetros y se los asigne a cada servomotor con el fin de que estos realicen su
posicionamiento determinado.
4.4.3 Software de Escritorio
El sistema debe contar con una interfaz gráfica el cual actúa como canal de
comunicación entre el usuario y el sistema general.
El software debe estar compuesto por un menú principal en el cual se
encuentre la opción de inicializar la conexión con el brazo robot, la opción de
ejecutar la rutina automática y una tercera opción para la rutina manual.
La opción para la conexión al brazo robot debe existir puesto que los
sistemas operativos de los computadores pueden reconocer el dispositivo Arduino
desde diferentes puertos (COM1, COM2, COM3…) y se debe poder seleccionar el
puerto con el cual se quiere realizar la conexión al software.
Para la ejecución de la rutina manual debe aparecer otra interfaz, en la cual
se pida al usuario la posición en grados que sea que se mueva cada motor, y un
retardo posterior a cada movimiento, En la interfaz se debe enumerar cada uno de
los motores e indicar gráficamente que motor pertenece a que parte del brazo para
que sea entendible para el usuario la configuración de los mismos. En la interfaz de
la rutina manual deben estar habilitados 3 botones, uno de ellos que ejecute la rutina
que ha sido configurada, otro para regresar a la posición inicial, y el tercero que me
permita volver a al menú inicial.
4.4.4 Integración
Las 3 partes fundamentales del sistema deben estar integradas finalmente, El
dispositivo hardware debe estar conectado de manera que cada motor del brazo
robot se encuentre conectado a la alimentación de energía eléctrica y que
61
igualmente esté conectado a un pin correspondiente de la tarjeta micro-controladora
como medio para recibir las instrucciones.
La tarjeta micro-controladora igualmente debe estar conectada al computador
en donde esté instalado el software por medio de cable USB, para lograr la recepción
de instrucciones desde el software de escritorio.
4.4.5 Cronograma de Actividades
Las áreas sombreadas en verde corresponden a los avances que se
ejecutaran, y las áreas sombreadas en amarillo, son los momentos en los cuales
debe irse desenvolviendo el proyecto.
TABLA 9. CRONOGRAMA DE ACTIVIDADES UCPBRA
Fecha →
ACTIVIDAD
Formulación
Problema
Objetivos
Metodología
Marco Teórico
Marco Conceptual
Marco Contextual
Requerimientos
Armado de brazo
Análisis Diseño
Implementación
INFORME FINAL
Redacción Informe
Revisión
Exposición
Pruebas
Ajuste y corrección
Sustentación
Ene
Feb
Mar
23-abr 8-May
Recuperado de: Elaboración propia
62
/
Jun
4.4.6 Estimación de Presupuesto
Tabla 10. Estimación de Presupuesto
Concepto
Meses
(1/2 Tiempo)
1
Levantamiento de información
Valor
250.000
Conceptualización
1
200.000
Elección de Tecnologías
1
150.000
Diseño de Software
1
350.000
Creación y Programación de la interfaz UCPBRA
1
400.000
Programación de Rutinas en software de arduino
1
300.000
Brazo Robótico AS-6DOF
1
780.000
Arduino Mega 2560
1
150.000
Dispositivos Electrónicos
1
200.000
Reparación y compra de elementos dañados
3
280.000
3.060.000
Total:
Recuperado de: Elaboración propia
5. ARQUITECTURA DEL SOFTWARE
5.1 Diagrama de casos de uso
Los casos de uso se utilizan para describir los pasos de las actividades que
deberían realizar para poder llegar a ejecutar un proceso, todos los personajes que
actúan en un caso de uso se le denominan actores, en nuestro caso como muestra
la figura 22, existe un usuario que tendrá que tomar una decisión, si quiere que el
brazo efectué una rutina manual o si quiere que la realice automática, cada uno de
ellos tiene sus actividades por cumplir dependiendo a la decisión que se tome.
63
Figura 22. DIAGRAMAS DE CASOS DE USO UCPBRA
Recuperado de: Elaboración propia
5.2 Diccionario de casos de uso
Tabla11. Diccionario de casos de uso 1
No. Caso de Uso:
1
Nombre:
Rutina Manual
Descripción
El usuario del software podrá configurar los movimientos del
brazo seleccionando realizando la parametrización de los
diferentes motores.
Relaciones
Asociación: Usuario
64
Tabla 12. Diccionario de casos de uso 2
No. Caso de Uso:
2
Nombre:
Indicar Grados Motores
Descripción
Como segundo paso para la rutina manual, se deberá
ingresar el valor a ser enviado a los motores para su
respectivo movimiento
Relaciones
Asociación: Usuario
Tabla 13 Diccionario de casos de uso 3
No. Caso de Uso:
3
Nombre:
Definir Retardos
Descripción
Como tercer paso se debe ingresar el valor de los retardos
que se desean enviar después del movimiento de los motores
Relaciones
Asociación: Usuario
65
Tabla 14 Diccionario de casos de uso 4
No. Caso de Uso: 4
Nombre:
Ejecutar Rutina
Descripción
Finalmente la rutina con los motores y sus valores de
movimiento
previamente
asignados
y
sus
retardos
correspondientes son enviados al brazo robot conectado al
equipo para su inmediata ejecución. La rutina enviada tendrá la
opción de seleccionar la cantidad de veces que se quiere
repetir la rutina, o si se quiere realizar la rutina en un ciclo
infinito.
Relaciones
Asociación: Usuario
Tabla 15 Diccionario de casos de uso 5
No. Caso de Uso: 5
Nombre:
Ejecutar Rutina
Descripción
Finalmente la rutina con los motores y sus valores de
movimiento
previamente
asignados
y
sus
retardos
correspondientes son enviados al brazo robot conectado al
equipo para su inmediata ejecución. La rutina enviada
tendrá la opción de seleccionar la cantidad de veces que se
quiere repetir la rutina, o si se quiere realizar la rutina en un
ciclo infinito.
Relaciones
Asociación: Usuario
66
Tabla 16 Diccionario de casos de uso 6
No. Caso de Uso: 6
Nombre:
Posición Inicial
Descripción
Los motores son reiniciados para que el brazo quede
en la posición inicial por defecto.
Relaciones
Asociación: Usuario
Tabla 17 Diccionario de casos de uso 7
No. Caso de Uso:
7
Nombre:
Rutina Automática
Descripción
Se envía la rutina configurada por defecto a ser
ejecutada por el brazo, la misma puede ser ejecutada una
sola vez, o en un ciclo infinito.
Relaciones
Asociación: Usuario
Tabla 18 Diccionario de casos de uso 8
No. Caso de Uso:
8
Nombre:
Detener Brazo
Descripción
Detiene cualquier movimiento que se esté realizando y se
devuelve a su posición inicial por defecto.
Relaciones
Asociación: Usuario
67
5.3 Diagrama general de secuencias
En la figura No.23 se determinan las actividades del software y la secuencia en las que se ejecutan para lograr la
integridad de las opciones requeridas para el sistema.
Figura 23. DIAGRAMA DE SECUENCIA
Recuperado de: Elaboración propia
De acuerdo en la figura 23, se muestra como las actividades se comunican
entre sí al transcurrir la secuencia ordenada de cada una de las funciones que
realiza al ejecutar nuestro software, en este caso se tiene un inicio donde inicializa
una conexión con arduino o placa base (arduino mega 2560), donde se verificar la
conexión de puertos en el administrador de dispositivos; verificada esta acción se
sigue con la siguiente actividad que es la seleccionar puerto, se elige el puerto
donde esta el dispositivo y se ejecuta la siguiente actividad que es conectar, se
verifica si ha conectado, en caso de que la conexión no fue exitosa; inmediatamente
se vuelve hacer la actividad de conexión con arduino, pero si fue exitosa se pasa a
la toma de decisiones donde se encuentran tres actividades para seleccionar que
son: rutina Manual, rutina Automática y desconectar.
Si su elección fue la actividad de rutina manual se ingresa a una nueva
interfaz donde se verifica la siguiente actividad de configurar posición de motores,
se ingresan los grados para cada movimiento en los servo motores, terminando la
anterior configuración y se procede a la siguiente actividad que es la de configurar
retardos; dentro de unas casillas que muestra la interfaz, se coloca en milisegundos
los retardos de los motores, efectuada la anterior actividad se ejecuta la rutina para
el funcionamiento de los motores; dentro de esta misma interfaz se tiene otra
actividad que se puede ejecutar en caso no dejar el brazo en su posición inicial, se
pasa a realizar la siguiente actividad que es volver a posición inicial, si se desea
parar las actividades en esta misma interfaz existe otra actividad para desconectar
donde se hace la desconexión entre el arduino y el software, pero si se desea
regresar a la ventana inicial se selecciona la actividad de volver selección rutinas
y automáticamente se regresa nuevamente al menú inicial o donde se seleccionan
nuevamente rutina Manual, rutina Automática y desconectar.
Si su elección fue rutina automática se inicia la actividad de rutina
automática ya con unos parámetros inicialmente ingresados y guardados en el micro
controlador del arduino, la última
actividad que tendríamos es desconectar,
habilitada en caso de que se desee desconectar la aplicación.
5.4 Prototipo no funcional
Figura 24. INTERFAZ DE INICIO UCPBRA
Recuperado de: Elaboración propia
El programa en su menú principal (ver figura 24) permite realizar la conexión
con el Arduino por el puerto que sea seleccionado en el ítem de conexión situado en
la parte superior derecha, ingresamos el puerto donde está conectado nuestro
arduino y ejecutamos el botón conectar, en esta ventana inicial tenemos 2 opciones,
la Rutina Automática, la cual, al ser presionada, inmediatamente realiza la rutina por
defecto que ha sido programada para el brazo dentro del micro controlador de la
placa base y la Rutina manual, la cual consta de una
pasamos a ingresar en grados
los movimientos
interfaz diferente donde
a realizar con sus respectivos
retardos en milisegundos para la ejecución ordenada para cada motor, antes de
hacer el movimiento gradualmente debemos verificar la limitante de cada motor.
Figura 25. INSERCIÓN DE DATOS PARA RUTINA MANUAL UCPBRA
Recuperado de: Elaboración propia
En la figura 25, se muestra la interfaz de la sección “Rutina Manual” en la cual se
puede seleccionar los grados a los que se desea mover cada motor, y el retardo
posterior al movimiento. Se cuenta con dos botones, el de Ejecutar Rutina, para
enviar los parámetros asignados y realizar el movimiento, y el de Posición Inicial, el
cual reinicia el brazo para que éste se ubique en la posición por defecto de inicio.
5.5 Descripción del proceso de desarrollo
El proceso de desarrollo del prototipo hardware se realiza según los
siguientes lineamientos.
Se procede a la construcción del brazo robot, armando los diferentes
componentes, y posicionando los servomotores correspondientes en cada una de las
articulaciones.
Cada servomotor debe estar conectado al integrado. El integrado lo que hace
es recibir una señal de control, esta señal pasa por un proceso de PWM (modulación
por ancho de pulso) para verificar el valor en la cual se debe posicionar el motor y
enviar dicha instrucción al mismo para ejecutar el movimiento.
Se energiza el brazo robótico, utilizando una fuente de energía eléctrica
continua de 5 voltios y 1 amperio para el funcionamiento de los servomotores.
Se realiza la preparación del entorno procediendo a la instalación de IDE
Arduino, con el driver correspondiente para la tarjeta, el IDE Netbeans y el Kit de
Desarrollo de Java (JDK).
El Arduino IDE se utiliza para la codificación del micro-controlador. La
codificación realizada de manera que para la ejecución de cualquier proceso se
necesite un parámetro que indique cual es el movimiento a realizar.
Se diseña un algoritmo estructurado cómo se describe a continuación: Se
importa la librería Servo.h para la gestión de los servomotores. Se inicializan 6
variables se tipo ‘servo’ que representarán los 6 motores y se relacionan con el pin
en el que se encuentran conectados al Arduino. Se crea el método loop el método
que se ejecutará indefinidamente y estará verificando se hay valores enviados en el
puerto de conexión al computador. Se codifica de manera que sólo la primera vez de
la ejecución del ‘loop’ el robot se ubique en la posición inicial (esto se realiza para
que al momento de energizar el Arduino, éste de inmediato ubique los motores en
dicha posición). Después de la configuración de la posición inicial, se entra a validar
si hay datos en el puerto, Si el dato recibido es ‘1’ se ejecutan las instrucciones que
realizan la rutina automática determinando los grados de posición de cada motor, y
los retardos necesarios para que la rutina fluya apropiadamente, (La rutina
automática es diseñada a prueba y error siguiendo la descripción realizada en la
definición general de la solución), Si el dato recibido es ‘2’ se ejecutan las
instrucciones para ubicar el brazo en la posición inicial, Y si el dato recibido es de 48
caracteres se realiza la rutina manual. Los 48 caracteres vienen de la manera en
cómo diseñó la cadena que se recibe, puesto que el movimiento de cada motor
cuenta con 3 caracteres que indican la posición, va desde ‘000’ a ‘180’, y 5
caracteres que indican el retardo en milisegundos ejecutado después de la
instrucción de posicionamiento, va desde ‘00000’ a ‘99999’, cómo cada motor ocupa
8 caracteres, y son 6 motores, el tamaño de la cadena total es 48. El código
diseñado para la opción de rutina manual evalúa la cadena y la divide para obtener
los caracteres necesarios que indican cada movimiento o retardo, y posteriormente
son asignados a su motor determinado (esto se puede realizar ya que la cadena
siempre viene organizada de la siguiente manera ‘posicion_motor1’ + ‘retardo1’ +
’posicion_motor2’ + ’retardo2’ + ’posicion_motor3’ + ’retardo3’ y así sucesivamente
hasta el motor 6).
Se desarrolla la interfaz del software de control que utilizara el usuario, en el
ambiente de desarrollo Netbeans.
Se codifica la navegación entre las pantallas diseñadas en el prototipo no
funcional.
Se programa el software de escritorio asignándole el envío de información ya
determinada en la codificación del Arduino para que éstas concuerden y se realicen
los procesos correspondientes, es decir al botón ‘Rutina Automática’ se codifica de
tal manera que se envíe por el puerto al cual está conectado el Arduino el carácter
‘1’, al botón ‘Ejecutar Rutina’ en la pantalla de Rutina Manual se codifica de tal
manera que arme la cadena de 48 caracteres que recibe el Arduino, con todo
los valores de posición y retardo, y al botón ‘Posición Inicial’ se le asigna el envío del
carácter ‘2’.
Se hace la conexión con el equipo en donde se encuentre el software de
control por medio del cable USB-Serial para la realización de pruebas de
comunicación.
Se procede a realizar las correspondientes pruebas de integración entre el
software de control en el computador y el dispositivo Arduino programado con su
correspondiente conexión a los motores.
Se revisan posibles inconsistencias y fallos de comunicación o de algoritmos
en la integración y se procede a su corrección.
Se realizan las pruebas finales para comprobar que no existan fallos
adicionales, y si los hay corregirlos hasta obtener una versión estable del producto
5.6 Inconvenientes en el proceso de desarrollo
Una gran parte del desarrollo de este software fue basado en la
programación del Arduino Mega 2560, puesto que dicha tarjeta de programación
contiene el código base para realizar las instrucciones del brazo el cual debe estar
realizado de manera que al recibir un parámetro por el puerto serial, se realice la
ejecución de una serie de actividades para las cual ha sido programado, La
herramienta para realizar la programación es el IDE Arduino, generó diferentes
inconvenientes, no reconocía el puerto COM, el programa en ocasiones se
bloqueaba y se cerraba, y se debió realizar la posterior desinstalación y reinstalación
del IDE y del driver de Arduino en repetidas ocasiones, debido a causas no
identificadas particularmente, pero finalmente se logró una estabilidad del IDE y el
desarrollo se llevó a cabo.
Un desarrollo en el cual se involucra la manipulación de un dispositivo
hardware incrementa sustancialmente la cantidad de errores y la detección del origen
de los mismos, puesto en el transcurso del desarrollo se puede presentar una falla o
técnica del dispositivo o de codificación.
En algunas ocasiones los motores se detenía o atascaban por fallas en la
construcción o por debilidad de algunos motores para cargar con movimientos muy
pesados para los mismos, por lo cual se realizó la alternación de motores en algunos
momentos.
La estabilidad de la estructura se veía afectada cuando se realizaban
movimientos fuertes de los servomotores, por lo que se fijaron limitantes en los
rangos en los que se podían mover cada uno de ellos, e igualmente se amarró la
estructura a una base para evitar movimientos inadecuados de la misma.
El programa que esta quemado internamente en el micro controlador tiene
varias etapas y estas rutinas son ejecutadas por medio de la interfaz de java, antes
de hacer todo, este código luego ser quemado en el micro controlador se realizaron
pruebas de movimiento con cada uno de los motores los cuales fueron evidenciando
la manera más fácil de construir el software localmente.
Estas etapas de pruebas se realizaron repetitivamente hasta logran la rutina
que se deseaba, se sumó que los servomotores solo se posicionan en el ángulo
especifico y no tuvimos que delimitarlos en ese sentido, esto quiere decir que si
volvemos a dar la misma rutina manual no sucederá nada ya que se encuentran
posicionados en el ángulo anteriormente descrito, Sin embargo la estructura del
brazo y la fijación realizada a una base para lograr una mejor estabilidad del mismo,
limitan de alguna manera el espacio en el cual el brazo se puede mover, y existen
posiciones en las cuales la libertad de un motor está condicionada a la posición en la
que esté otra de articulaciones, por lo que se realizó una delimitación de cada motor,
para que estos puedan ser movidos libremente pero evitando la ejecución de
algunos movimientos que llegan a ser obstaculizados por la estructura. Tal
delimitación quedo explícitamente visible en la interfaz del usuario al lado de la
sección de los grados para cada motor.
6. RESULTADOS
Aunque el proyecto de forma general está orientado al control de un proceso
físico, en este caso el control de un brazo robótico, el prototipo desarrollado en
realidad es un software, razón por la cual es necesario asegurar que las funciones
programadas cumplen con los objetivos, lo cual llevó no sólo a desarrollar pruebas
en un entorno donde encontramos nuestro programa informático, donde se tuvo
que realizar pruebas físicas con nuestro hardware. Lo cual se hizo para hallar
posibles errores en diseño, programación y ejecución del software tendiente a unas
depuración completa, buscando cumplir con los estándares de calidad, el cual se dio
con un resultado satisfactorio.
Los resultados arrojados son los elementos necesarios para el desarrollo de
UCPBRA como aplicación de escritorio para la manipulación del brazo robótico.
Concluida la estructuración de la interfaz de programación y el acondicionamiento del
brazo robótico con sus respectivos elementos, se realizaron pruebas en las que se
analizó la interfaz como tal, es decir, las denominadas pruebas de software. En las
primeras pruebas desde el análisis probatorio donde se analizaron los parámetros de
cada elemento, que debería tener para su ejecución y obtener una respuesta física
del brazo robótico tras recibir las señales enviadas desde la interfaz del software;
dichas pruebas permite en un análisis secuencial y correcto de que solución para ser
integrada a la hora de realizar la interfaz gráfica del software como la programación
requerida.
Luego de realizar las pruebas y las consecuentes correcciones, se reflexionó acerca
del uso potencial de UCPBRA no sólo para los estudiantes de la universidad católica
de Pereira, sino también de cuán útil sería para el mantenimiento de la plataforma
virtual, donde se ejecutarían remotamente el brazo robótico e interactúe dentro del
laboratorio. Por otra parte
se analiza el impacto que desarrollarían con el
aprendizaje por medio de estos laboratorios a estudiantes de bachillerato y porque
no de primaria, puesto que también se estudió en la escuela y el colegio, el uso del
brazo robótico con tal demanda de estudiantes y aprendices, donde tengan una
importante herramienta pedagógica, la cual será manejada desde el laboratorio
PHYSYLAB.
De la misma manera al estar analizando los resultados se hizo una reflexión
acerca de las implicaciones sociales del uso del PHYSYLAB, debido a que disminuye
los costos directos de la educación ya que en una práctica de laboratorio puede
hacerse de manera habitual, es decir, desde el lugar de residencia sin incurrir en
costos de transporte y viáticos para llegar a la universidad, de manera similar en lo
educativo principalmente en la práctica en los laboratorios, lo cual lleva a un
incremento del nivel académico, y de esta forma contribuir a los estándares exigidos
por la acreditación universitaria.
Conclusiones
Gracias a los requerimientos se pudo entender muchos aspectos del mismo
hardware y cómo se manejaban cada uno de los componentes, de acuerdo a la
intensidad de la carga de cada servomotor, el retardo adecuado que ayuda a la
manipulación del brazo.
En cuanto al levantamiento de los requerimientos se tiene que al ser una
restricción del sistema, como condición o capacidad para satisfacer al usuario, en el
proyecto el realizar el proceso según los estándares de calidad llevo a minimizar las
deficiencias en UCPBRA.
Los requerimientos funcionales fueron permitir la manipulación del brazo a
partir de la configuración manual del movimiento que realizará cada motor, el usuario
pueda activar la rutina automática por defecto a ser realizada por el brazo, verificar
que los datos ingresados por el usuario si correspondan a valores dentro de los
límites establecidos, para su envío al dispositivo hardware, la opción de conexión del
puerto fue necesaria para poder conectar y desconectar nuestra aplicación con la
placa base.
Como se pudo observar al levantar los requerimientos y analizarlos, el
trabajos de diseño un sistema software de control arrojó una serie de resultados que
permiten en el entorno de desarrollo crear los elementos del software para que
pueda ser manipulado los mecanismos motores del brazo, lo cual se hizo utilizando
netbeans y la plataforma de arduino.
Los requerimientos no funcionales fueron Mostrar un menú inicial para la
selección de la rutina automática o
manual, realizar una interfaz simple, y
entendible, de forma que el software pueda ser utilizado de una manera intuitiva,
también se analizó la implementación de un botón para colocar el brazo en posición
inicial, donde normalmente esta por defecto.
La importancia de los laboratorios virtuales como un paso hacia adelante en
los usos pedagógicos, en las distintas fases de los procesos de enseñanza y
aprendizaje.
El valor agregado de verse enfrentado a responder a dar solución a
necesidades del medio en cuanto a la formación adquirida, para el caso concreto,
profesionales en sistemas y telecomunicaciones.
La importancia de los usos de otras tecnologías como es el caso de un brazo
robótico, como se pudo ver en la sección teórica del trabajo la tecnología robótica es
preferida debido a que la industria en múltiples áreas de la producción usa robots
computarizados, por agilidad, tiempo y precisión.
Referencias bibliográficas
Bibliografía
ARDUINO ORG. (2012). ARDUINO.
Booch, G., Jacobson, I., & Rumbaugh, J. (2000). El Lenguaje Unificado de Modelado:
Manual de Referencia. Madrid: Pearson Educacón S.A,.
Caicedo Bravo, E., Bacca, E. B., Calvache, B. A., Cardona, J. E., & Buitrago, J. A.
(2009). Laboratorio Distribuido con Acceso Remoto Para la Enseñanza de la
Robótica. Revista Educacion en Ingenieria, 51-61.
COLOMBIANO, E. (27 de Septiembre de 2013). El desarrollo de software local
requiere más expertos. EL COLOMBIANO.
DOCSETOOLS.COM.
(2008).
Brazos
Roboticos.
Obtenido
de
http://docsetools.com/articulos-noticias-consejos/article_125997.html
FERIA VIRTUAL. (s.f.). https://www.interempresas.net/Robotica.
gestionrrhhusm. (2011). DESARROLLO Y CICLO DE VIDA DEL SOFTWARE.
Bogota. Obtenido de http://gestionrrhhusm.blogspot.com/
Ingenierías, C. U. (2004). Robots de Servicio y Teleoperados. Universidad de
Guadalajara, Guadalajara. Obtenido de http://proton.ucting.udg.mx/
Londoño, J. H. (06 de abril de 2005). Recuperado el 21 de abril de 2013, de
Ingenieria del software: http://ing-sw.blogspot.com/2005/04/tipos-de-pruebasde-software.html
Luengas, L. A., Guevara, J. C., & Sánchez, G. (2009). ¿Cómo Desarrollar un
Laboratorio Virtual? Metodología de Diseño. Recuperado el Febrero de 2014,
de www.tise.cl: http://www.tise.cl/volumen5/TISE2009/Documento20.pdf
MINTIC. (2015). PLAN DE FORMACION EN USO DE TIC. RISARALDA. Obtenido
de http://www.mintic.gov.co/
Netbeans.org. (2014). Recuperado el mayo de 2014, de https://netbeans.org/:
https://netbeans.org/
OSEC. (2010). Generación de Capacidad Comercial hacia EFTA. Obtenido de
http://www.academia.edu/8722135/Suiza_TIC_Manufactura_TIC_Comercio_TI
C_Servicios_Detalles_de_los_servicios_Puestos_Puestos_Puestos_Software
_Fuente_Anuario_de_salarios_TIC
OSEC y PROEXPORT. (2012). Generación de Capacidad Comercial hacia EFTA:
Inteligencia de Mercado para Colombia – Sector de Software y Tecnologías.
BOGOTA:
OSEC.
Obtenido
de
Colombiatrade.com.co:
http://www.colombiatrade.com.co/sites/default/files/estudio_software__efta.pdf
PHYSILAB. (2012). PHYSILAB . Recuperado el 5 de MAYO de 2014, de
LABORATORIO REMOTO Y VIRTUAL PARA LA ENSEÑANZA DE LA
FIISCA: http://PHYSYLAB.ucp.edu.co/web/)
Reynoso, C. B. (Marzo de 2004). Introducción al a Arquitectura del Software. Buenos
Aires: Willy.net. Obtenido de willy.net.
Rosado, L. (204). APORTACIONES DIDÁCTICAS DE LOS LABORATORIOS.
Sebastián, J. M., Sanchez, F. M., & Garcia, D. (2013). LABORATORIOS REMOTOS
PARA LAS PRÁCTICAS DE INGENIERÍA DE SISTEMAS Y AUTOMÁTICA
EN LA UNIVERSIDAD MIGUEL HERNÁNDEZ. Recuperado el abril de 2014,
de
http://www.uv.es/eees/archivo/UMH-LaboratoriosRemotos03.pdf:
http://www.uv.es/eees/archivo/UMH-LaboratoriosRemotos03.pdf
TdRobotica.co.
(2012).
Servomotores.
http://www.tiendaderobotica.com/categoria/81
Bogota.
Obtenido
de
TUTORIAL
DE
JAVA.
(s.f.).
Recuperado
el
Abril
de
2014,
de
http://personales.upv.es/igil/java.PDF: http://personales.upv.es/igil/java.PDF
VACA GUZMÁN, A. E., & SEVILLANO, E. S. (2012). Diseño y construcción de un
robot scara de tres grados de libertad con un efecto final electromagnético,
para el paletizado de recipientes metálicos. Sangolquil, Ecuador.
ANEXO
Anexo A. Pruebas realizadas
Prueba No:
Objetivo
Tipo
1
Probar Arduino Mega 2560 para la conexión con el
computador.
Hardware/Software
Procedimiento
Se hace la instalación de los drivers de arduino
para su reconocimiento
Resultados
Se instala correctamente no se genera ningún
inconveniente.
Prueba No:
Objetivo
Tipo
Procedimiento
Resultados
Prueba No:
Objetivo
Tipo
Procedimiento
2
Probar arduino mega 2560 para encender 2 led
Hardware /Software
Se instala el software de la plataforma arduino y se
prueba un código básico para encender 2 led
Exitoso, se encienden los led intermitentemente.
3
Probar el funcionamiento de un servomotor.
Hardware/Software
Se conecta en uno de los pines.
Resultados
Prueba No:
Objetivo
Tipo
Procedimiento
Resultados
Prueba No:
Objetivo
Tipo
No funciono por que se conectó incorrectamente
4
Crear un circuito alimentado con pilas AA de para
alimentar los servomotores
Hardware
Se realiza el circuito en una protoboard
El circuito funciona después de
modificaciones y pruebas con el tester eléctrico.
ciertas
5
Probar dos servomotores conectados al arduino
Hardware/Software
Procedimiento
Se realiza la programación en el software de
arduino, por medio de ejemplos investigados.
Resultados
No fue exitosa ya que sale un error de librería
tengo que importar la librería servo.h
Prueba No:
Objetivo
Tipo
6
Probar dos servomotores conectados al arduino
Hardware/Software
Procedimiento
Se realiza la prueba nuevamente programando el
movimiento de 30° grados en cada motor.
Resultados
La prueba fue exitosa, los motores hicieron su
movimiento de 30°.
Prueba No:
Objetivo
Tipo
Procedimiento
Resultados
Prueba No:
Objetivo
Tipo
7
Conectar
funcionamiento
4
servomotores
y
verificar
el
Hardware/Software
Se conecta 2 motores más en los pines de PWM
No fue exitoso el arduino prende levemente y se
apaga, porque las pilas AA no entregan el voltaje
suficiente, van perdiendo su carga con cada prueba
8
Probar adaptador de 5V
Hardware
Procedimiento
Se verifica con el tester que esté enviando el
voltaje adecuado
Resultados
La prueba fue exitosa está generando los 5v
necesarios para alimentar el arduino
Prueba No:
Objetivo
9
Conectar adaptador de 5V al circuito
Tipo
Procedimiento
Resultados
Prueba No:
Objetivo
Tipo
Hardware
Se realiza la conexión
Se verifica con el tester que este en buen
funcionamiento y entregue el voltaje adecuado.
10
Conectar 1 servomotor y probar el funcionamiento
Hardware/software
Procedimiento
Se realiza la conexión y se envían datos al micro
controlador para probar el movimiento del motor.
Resultados
La prueba fue exitosa el motor dio indicios de
movimiento ya que se le ingreso 10° de movimiento, el
adaptador funciona correctamente.
Prueba No:
Objetivo
Tipo
11
Conectar 3 servomotores y verificar su funcionamiento.
Hardware/Software
Procedimiento
Se conectan los 3 motores y se programan los 3
servos con un movimiento corto en el micro controlador
del arduino
Resultados
La prueba fue exitosa funcionaron correctamente,
el adaptador soporta los 3 motores.
Prueba No:
Objetivo
Tipo
12
Conectar 5 servomotores
funcionamiento del adaptador.
para
verificar
el
Hardware/Software
Procedimiento
Se agregan 2 motores más ya que hay 3
conectados en el arduino, se programa el movimiento de
los dos motores adicionados, subimos el programa al
micro controlador.
Resultados
Funciona correctamente la prueba fue exitosa, el
adaptador funciona con 5 servomotores.
Prueba No:
Objetivo
Tipo
13
Conectar 6 servomotores
funcionamiento del adaptador.
para
verificar
el
Hardware/software
Procedimiento
Se conectan los 6 servomotores necesarios para
poder mover el brazo robotico.
Resultados
La prueba fue exitosa, funciono correctamente el
adaptador y los parámetros ingresados.
Prueba No:
Objetivo
Tipo
Procedimiento
14
Sincronizar motores según su posición en el brazo
Hardware/Software
Después de muchas pruebas se verifica el ajuste
de los movimientos para cada servomotor para sus
respectivos movimientos en su eje.
Resultados
Prueba No:
Objetivo
Tipo
Exitoso después de armar y desarmar el brazo en
reiteradas veces y se logra sincronizar los motores de
acuerdo a su necesidad de movimiento en sus ejes.
14
Colocar una rutina de posición inicial para el bazo
y probar el método loop para que el arduino al momento
de energizar ubique los motores en la posición deseada
Hardware/software
Procedimiento
Se programa una rutina de posicionamiento, y se
sube al micro controlador.
Resultados
Fue exitosa y se logró mantener en la posición
apenas se energizo automáticamente coloco los motores
en la posición indicada.
Prueba No:
Objetivo
Tipo
15
Crear una rutina de movimiento automático.
Hardware/Software
Procedimiento
Se hace la programación de los parámetros y
retardos para el movimiento de cada motor, se sube al
micro controlador.
Resultados
Después de muchas pruebas se logra sacar una
rutina automática donde el brazo funciona haciendo una
serie de movimientos.
Prueba No:
Objetivo
Tipo
16
Desarrollar una interfaz de software en netbeans,
que funcione asignándole él envió de información ya
determinada en el programa de arduino para que se
realicen los procesos correspondientes.
Software
Procedimiento
Se realiza la prueba de conexión entre los dos
programas.
Resultados
No fue exitosa, después de investigar hay que
agregar la librería arduino V 2.3.0
Prueba No:
Objetivo
Tipo
17
Conexión entre la interfaz de netbeans y arduino
Software
Procedimiento
Se agrega la librería arduino V2.3.0.jar y la
RXTXcomm.jar y se ejecuta en netbeans
Resultados
Prueba no exitosa, sale un error en pantalla de
netbeans por archivos rxtxSerial.dll y rxtxParallel.dll
Prueba No:
Objetivo
Tipo
Procedimiento
18
Conexión entre netbeans y arduino
Software
Después de investigar se deben descargar y
copiar los siguientes archivos
rxtxSerial.dll y
rxtxParallel.dll en esta dirección de mi equipo C:\Program
Files\Java\jdk1.7.0_45\jre\bin
Resultados
Prueba No:
Objetivo
Tipo
El procedimiento fue exitoso pude hacer funcional
la rutina automática a través de la interfaz de netbeans.
19
Realizar la rutina manual en la interfaz de
netbeans y poder ejecutarla en conjunto con los
parámetros programados en el micro controlador del
arduino.
Hardware/Software
Procedimiento
Se realizan muchas pruebas para poder ejecutar la
rutina desde la interfaz de netbeans, se colocan las 6
casillas donde podrán ingresar los grados para que
funcione cada motor con sus limitantes ya que después de
muchas pruebas se ha dañado un motor y se logró
conseguir otro.
Resultados
La prueba fue exitosa a pesar de que se dañó el
engranaje de un motor después de muchas pruebas
Prueba No:
Objetivo
Tipo
Coger y colocar un objeto en diferente lugar a
través del brazo robótico
Hardware/Software
Procedimiento
Se hace la configuración de los procedimientos y
rutinas en el programa arduino, se realizan de muchas
pruebas.
Resultados
La prueba fue exitosa después de muchas
pruebas se logra configurar los motores con las rutinas
deseadas, para el transporte de un elemento.
ANEXO B. Pasos para la configuración y programación básica de un
Arduino a través del IDE Arduino
1. Inicio
2. Clic derecho en equipo
3. Administrador de dispositivos
4. Ahí buscamos el del Arduino y miramos a que COM se encuentra
relacionado.
5. Nos dirigimos al programa Arduino.
Para programar con un servo es necesario configurar la librería servo
como lo muestran en estos videos o también lo podemos ver en la
siguiente grafica sketch, importar librerías, escogemos servo.
Y ahí se procede a diseñar el código, a continuación se explica un
código básico para realizar movimientos en el brazo.
#include <Servo.h>
Servo servo1;
Servo servo2;
Inicialmente
se
declaran
las
variables a utilizar, representando cada
una de ella a un motor del brazo, es
Servo servo3;
decir, al haber seis motores distribuidos
Servo servo4;
en el brazo robot, se declaran 6
Servo servo5;
variables.
Servo servo6;
void setup()
{
Aquí se asigna a cada
servo1.attach(2);
variable
servo2.attach(3);
el
representan,
pin
que
decir
que
es
servo3.attach(4);
cada variable representa cada
servo4.attach(5);
pin
servo5.attach(6);
de
salida
hacia
cada
motor.
servo6.attach(7);
}
void loop()
{
servo2.write(20);
A
continuación
se
servo3.write(120);
procede a enviarle los datos a
servo4.write(120);
cada
servo6.write(130);
pin,
con
el
‘write()’
método
indicamos
numéricamente los grados a
servo5.write(90);
mover cada motor.
delay(2500);
Como
servo1.write(60);
delay(1500);
se
puede
observar, se utiliza igualmente
el método delay() para enviar
un retardo en milisegundos
}
antes de continuar con la
siguiente instrucción. Y así
podemos proseguir a enviar
todos los movimientos que
sean necesarios.
Cuando se finalice la codificación se debe compilar el código y luego se envía
al Arduino con estos dos botones
Es importante verificar que el Arduino si tenga el puerto configurado. Para
verificarlo se puede observar en la parte inferior derecha encerrada en rojo, que
concuerde con el Arduino que se está utilizando y el puerto COM que se observó en
el administrador de dispositivos anteriormente.
Si el dispositivo no coincide dirigirse al menú ‘Herramientas’ – ‘Tarjeta’ y
seleccionar la tarjeta deseada, igualmente si el menú ‘Puerto Serial’ se encuentra
activado, seleccionar el COM correspondiente.