ucpbra: software para uso de brazo robotico en …

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

2

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

3

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.

4

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.

5

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.

6

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, Remotos, Virtuales,

Experimentación, Equipos, Robótica, Physilab, Internet, Datos.

7

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 .

8

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

9

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

10

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

11

ANEXO B. Pasos para la configuración y programación básica de un

Arduino a través del IDE Arduino........................................................................... 69

12

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

13

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

14

LISTA DE TABLAS

Tabla 1. Requerimiento 001 .......................................................................... 52







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







15

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

16

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 de sistemas para descubrir y resolver las diferentes

movimientos del robot, la forma de alimentar o generar 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.

17

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

18

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 los estudiantes tendrían un elemento

primordial para poder desarrollar las destrezas, habilidades, capacidades y

competencias que se conjuguen con iniciativa y creatividad en una ambiente virtual.

19

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.

20

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,

21

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

22

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

23

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

24

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 amo-

esclavo 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.

25

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

26

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).

27

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 .

28

Figura 3. PARTICIPACIÓN DE LOS SEGMENTOS DEL TI 2008 (OSEC Y PROEXPORT).

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)

Software [PORCENTAJE]

Servicios [PORCENTAJE

]

Hardware [PORCENTAJE

]

29

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.

30

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

31

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 las personas siempre han tratado de construir maravillas

mecánicas que traten de imitar 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 a una época de

comodidades. En esa misma época 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

32

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.

33

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


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


34

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


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


35

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


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

https://www.interempresas.net/Robotica

36

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)

37

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.

38

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)

39

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

40

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.

41

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".

42

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

http://es.wikipedia.org/wiki/Circuito_impreso

http://es.wikipedia.org/wiki/Microcontrolador

43

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)

44

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)

45

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)

46

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)

47

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

48

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.

49

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.

50

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

51

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, con su correspondiente

clasificación. (Ver Tablas de la 1 a la 7).

52

Tabla 1. Requerimiento 001


INGENIERIA DE SISTEMAS Y TELECOMUNICACIONES (UCP) CAPTURA Y DESCRIPCIÓN DE REQUERIMIENTOS

Nombre del proyecto: SOFTWARE PARA EL CONTROL DE UN BRAZO ROBÓTICO

Fecha: 18/03/2014

Analista Responsable: Juan Carlos Parra

Requerimiento Nro. 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



Fecha: 18/03/2014



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

53



Nombre del proyecto: SOFTWARE NO FUNCIONAL PARA UN BRAZO ROBÓTICO

Fecha: 18/03/2014



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 de requerimiento

x Funcional No funcional




Fecha: 18/03/2014



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

54

Tabla 5 Requerimiento 005



Fecha: 18/03/2014



Interfaz Intuitiva

Descripción del requerimiento: 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


INGENIERIA DE SISTEMAS Y TELECOMUNICACIONES (UCP)

CAPTURA Y DESCRIPCIÓN DE REQUERIMIENTOS


Fecha: 18/03/2014



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

55


INGENIERIA DE SISTEMAS Y TELECOMUNICACIONES (UCP)

CAPTURA Y DESCRIPCIÓN DE REQUERIMIENTOS


Fecha: 18/03/2014


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 20 Funcional

Rutina Automática 20 Funcional

Verificación de datos ingresados 15 Funcional

Configuración de Retardos

15 Funcional

Interfaz intuitiva 10 No Funcional, Interfaz

Menú Inicial 10 No funcional, Interfaz

Reinicio de Brazo 10 No Funcional

TOTAL 100

56

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.

57

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.

58

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 memoria para programar y corriendo a 16 Mhz, tiene una

capacidad 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

59

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

http://www.alsrobot.com/index.php?route=product

60

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 micro-

controladora.

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.

61

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

62

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

Recuperado de: Elaboración propia

Fecha → Ene Feb Mar 23-abr 8-May / Jun

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

63

4.4.6 Estimación de Presupuesto

Tabla 10. Estimación de Presupuesto


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.

Concepto Meses (1/2 Tiempo)

Valor

Levantamiento de información 1 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

Total: 3.060.000

64

Figura 22. DIAGRAMAS DE CASOS DE USO UCPBRA


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

65

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


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


66


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.



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.


67


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.



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.



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.


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


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


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 interfaz diferente donde

pasamos a ingresar en grados los movimientos 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


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-pruebas-

de-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. Bogota. Obtenido de

http://www.tiendaderobotica.com/categoria/81

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: 1

Objetivo Probar Arduino Mega 2560 para la conexión con el computador.

Tipo 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: 2

Objetivo Probar arduino mega 2560 para encender 2 led

Tipo Hardware /Software

Procedimiento Se instala el software de la plataforma arduino y se prueba un código básico para encender 2 led

Resultados Exitoso, se encienden los led intermitentemente.

Prueba No: 3

Objetivo Probar el funcionamiento de un servomotor.


Procedimiento Se conecta en uno de los pines.

Resultados No funciono por que se conectó incorrectamente

Prueba No: 4

Objetivo Crear un circuito alimentado con pilas AA de para alimentar los servomotores

Tipo Hardware

Procedimiento Se realiza el circuito en una protoboard

Resultados El circuito funciona después de ciertas modificaciones y pruebas con el tester eléctrico.

Prueba No: 5

Objetivo Probar dos servomotores conectados al arduino


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: 6

Objetivo Probar dos servomotores conectados al arduino


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: 7

Objetivo Conectar 4 servomotores y verificar el funcionamiento


Procedimiento Se conecta 2 motores más en los pines de PWM

Resultados 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

Prueba No: 8

Objetivo Probar adaptador de 5V

Tipo 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: 9

Objetivo Conectar adaptador de 5V al circuito

Tipo Hardware

Procedimiento Se realiza la conexión

Resultados Se verifica con el tester que este en buen funcionamiento y entregue el voltaje adecuado.

Prueba No: 10

Objetivo Conectar 1 servomotor y probar el funcionamiento

Tipo 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: 11

Objetivo Conectar 3 servomotores y verificar su funcionamiento.


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: 12

Objetivo Conectar 5 servomotores para verificar el funcionamiento del adaptador.


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: 13

Objetivo Conectar 6 servomotores para verificar el funcionamiento del adaptador.


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: 14

Objetivo Sincronizar motores según su posición en el brazo


Procedimiento Después de muchas pruebas se verifica el ajuste de los movimientos para cada servomotor para sus respectivos movimientos en su eje.

Resultados 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.

Prueba No: 14

Objetivo 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


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: 15

Objetivo Crear una rutina de movimiento automático.


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: 16

Objetivo 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.

Tipo 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: 17

Objetivo Conexión entre la interfaz de netbeans y arduino

Tipo 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: 18

Objetivo Conexión entre netbeans y arduino

Tipo Software

Procedimiento 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 El procedimiento fue exitoso pude hacer funcional la rutina automática a través de la interfaz de netbeans.

Prueba No: 19

Objetivo 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.


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 Coger y colocar un objeto en diferente lugar a través del brazo robótico


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;

Servo servo3;

Servo servo4;

Servo servo5;

Servo servo6;

Inicialmente se declaran las

variables a utilizar, representando cada

una de ella a un motor del brazo, es

decir, al haber seis motores distribuidos

en el brazo robot, se declaran 6

variables.

void setup()

{

servo1.attach(2);

servo2.attach(3);

servo3.attach(4);

servo4.attach(5);

servo5.attach(6);

servo6.attach(7);

}

void loop()

{

servo2.write(20);

servo3.write(120);

servo4.write(120);

servo6.write(130);

servo5.write(90);

delay(2500);

servo1.write(60);

delay(1500);

}

Aquí se asigna a cada

variable el pin que

representan, es decir que

cada variable representa cada

pin de salida hacia cada

motor.

A continuación se

procede a enviarle los datos a

cada pin, con el método

‘write()’ indicamos

numéricamente los grados a

mover cada motor.

Como 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.

ucpbra: software para uso de brazo robotico en …

Documents