Embed Size (px)
Citation preview
DESARROLLO DEL SOFTWARE PARA BRAZO ROBOT
JHON SMITH ROMERO SOLÓRZANO.
UNIVERSIDAD CATÓLICA DE PEREIRA
Facultad De Ciencias Básicas e Ingenierías
Pereira.
Noviembre de 2014
2
DESARROLLO DEL SOFTWARE PARA BRAZO ROBOT
JHON SMITH ROMERO SOLÓRZANO.
Informe final como requisito para optar al título profesional de Ingeniero en
Sistemas y Telecomunicaciones
Director.
M. Sc. JUAN CARLOS HENAO LÓPEZ
UNIVERSIDAD CATÓLICA DE PEREIRA
Facultad De Ciencias Básicas E Ingenierías
Pereira.
Noviembre de 2014
3
Dedicatoria
A mis padres Edgar Romero Torres y Mariela Solórzano
Solórzano y a mi hermano Andrés Felipe Romero Solórzano, las
personas que más amo.
A mis amigos incondicionales, compañeros, y profesores y a
cada una de las personas que influyeron de manera positiva y
ayudaron a este propósito.
“No sueñes tu vida, vive tu sueño”
4
Agradecimientos
Quiero agradecer a mi Padre Celestial, por la bendición de un sueño
cumplido, a mis padres por el apoyo en este proceso, a mi hermano por su
amistad incondicional, y a mi familia por sus voces de apoyo en la distancia.
A mis compañeros en cada una de las materias y semestres con los cuales me
encontré en el camino, a los profesores que construyeron en mi un
profesional, a cada uno de los funcionarios de la Universidad Católica de
Pereira.
Por ultimo a mi asesor de proyecto, su apoyo y pro-actividad fueron
fundamentales para finalizar este proyecto y a cada una de las personas que
influyeron de una u otra manera para que este día llegara en mi vida.
5
TABLA DE CONTENIDO
1 INTRODUCCIÓN ........................................................................................... 11
2 OBJETIVOS, HIPÓTESIS Y JUSTIFICACIÓN DE LA INVESTIGACIÓN ...... 13
2.1 OBJETIVOS ............................................................................................. 13
2.1.1 Objetivo General. ............................................................................... 13
2.1.2 Objetivos Específicos. ....................................................................... 13
2.2 HIPÓTESIS DEL PROBLEMA DE INVESTIGACIÓN .............................. 14
2.3 JUSTIFICACIÓN ...................................................................................... 15
3 MARCO TEÓRICO ........................................................................................ 17
3.1 ANTECEDENTES HISTÓRICOS ............................................................. 17
3.1.1 Brazo mecánico realizado en La Universidad del Valle / México. ...... 17
3.1.2 Brazo robot dela universidad Tecnológica de Mixteca / México. ....... 18
3.1.3 Brazo robot realizado en Ecuador. .................................................... 19
3.1.4 Brazos Robots en Colombia .............................................................. 20
3.2 MARCO CONCEPTUAL .......................................................................... 20
3.2.1 Ingeniería del software ...................................................................... 20
3.2.2 Atributos del software ........................................................................ 21
3.2.3 Arduino .............................................................................................. 23
3.2.4 Los ciclos de vida del software: ......................................................... 24
3.2.5 Principios físicos y geométricos usados. ........................................... 30
3.3 METODOLOGÍAS DE DESARROLLO DE SOFTWARE: ......................... 34
3.3.1 RUP. .................................................................................................. 35
3.3.2 Scrum. ............................................................................................... 36
3.3.3 PSP ................................................................................................... 36
3.3.4 TSP. ................................................................................................... 37
3.4 MARCO CONTEXTUAL ........................................................................... 37
3.5 MARCO METODOLÓGICO ..................................................................... 39
6
3.5.1 Análisis y Diseño ............................................................................... 39
3.5.2 Producción y Pruebas: ....................................................................... 41
4 DESARROLLO DE IMPLEMENTACIÓN DE LA INVESTIGACIÓN ............... 43
4.1 ANALISIS Y DISEÑO ............................................................................... 43
4.1.1 Toma de requisitos: ........................................................................... 43
4.1.2 Especificación de los requerimientos: ................................................ 43
4.1.3 Estudio de procesos. ......................................................................... 47
4.1.4 Reingeniería de procesos. ................................................................. 47
4.1.5 Creación, socialización, corrección y últimos modelos ...................... 48
4.1.6 Tecnología a utilizar. .......................................................................... 51
4.1.7 Arquitectura: ...................................................................................... 52
4.2 PRODUCCIÓN Y PRUEBAS ................................................................... 53
4.2.1 Codificación: ...................................................................................... 53
4.2.2 Integración y corrección de componentes: ........................................ 53
4.2.3 Consolidación de partes del proyecto: ............................................... 54
4.2.4 Pruebas y corrección de errores: ....................................................... 54
4.2.5 Implementación ................................................................................. 58
5 CONCLUSIONES Y RECOMENDACIONES ................................................. 62
5.1 CONCLUSIONES..................................................................................... 62
5.2 RECOMENDACIONES ............................................................................ 63
6 BIBLIOGRAFÍA .............................................................................................. 65
7 ANEXOS ........................................................................................................ 66
7.1 INSTALACIÓN Y CAMBIOS EN EL ENSAMBLE CON PHYSILAB ......... 66
7.2 CÓDIGO FUENTE DEL BRAZO .............................................................. 70
7.3 GUÍA DE LABORATORIO ........................................................................ 68
7
LISTA DE FIGURAS
Figura 3.1. Modelo En Cascada ............................................................................ 25
Figura 3.2. Modelo Evolutivo ................................................................................. 27
Figura 3.3. Modelo Basado En Componentes ....................................................... 28
Figura 3.4. Modelo En Espiral ............................................................................... 29
Figura 3.5. Representación Geométrica De Un Vector. ........................................ 30
Figura 3.6. Método Del Paralelogramo Para La Suma De Dos Vectores. ............. 31
Figura 3.7. Representación Modelada Aproximada De Un Brazo Robótico Para El
Laboratorio De Suma De Vectores. ............................................................... 32
Figura 3.8. Modelo Matemático Para El Cálculo De La Suma De Dos Vectores En
El Plano. ......................................................................................................... 33
Figura 4.1. Caso De Uso ....................................................................................... 49
Figura 4.2. Diagrama De Actividades .................................................................... 50
Figura 4.3. Estructura Básica Del El Brazo Robot Rb-13k012 .............................. 52
Figura 4.4. Montaje Físico Del Brazo Robótico ..................................................... 59
Figura 4.5. Montaje Físico Del Brazo Robótico .................................................... 60
Figura 4.6. Montaje Físico Del Brazo Robótico ..................................................... 60
Figura 7.1. Configuración Del Framework. ............................................................ 67
8
LISTA DE TABLAS
Tabla 4.1. Captura Y Descripción Del Requerimiento 001 .................................... 44
Tabla 4.2. Captura Y Descripción Del Requerimiento 002 .................................... 44
Tabla 4.3. Captura Y Descripción Delrequerimiento 003 ...................................... 45
Tabla 4.4. Captura Y Descripción Del Requerimiento 004 .................................... 45
Tabla 4.5. Captura Y Descripción Del Requerimiento 005 .................................... 45
Tabla 4.6. Captura Y Descripción Del Requerimiento 006 .................................... 46
Tabla 4.7. Ponderación De Los Requerimientos ................................................... 46
Tabla 4.1. Prueba Pu–001 .................................................................................... 56
Tabla 4.2. Prueba Pu–002 .................................................................................... 56
Tabla 4.3. Prueba Pu–003 .................................................................................... 57
Tabla 4.4. Prueba Pu–004 .................................................................................... 57
Tabla 4.5. Prueba Pu–005 .................................................................................... 57
9
TÍTULO: DESARROLLO DEL SOFTWARE PARA BRAZO ROBOT
John Smith Romero Solórzano
Palabras Clave. Laboratorio Remoto, PHYSILAB, brazo robótico, instrumentación
RESUMEN
Este proyecto, –Desarrollo del Software Para Brazo Robot– nace como respuesta
a las necesidades que se presentan dentro de un macroproyecto de investigación
multidisciplinar más grande de la Universidad Católica de Pereira, denominado
PHYSILAB; el cual en esencia busca explorar nuevas didácticas para la
enseñanza y aprendizaje de la física a través de las tecnologías de la información
y la comunicación.
La investigación se centra en comprender las implicaciones tecnológicas
asociadas del brazo robótico de marca RobotBase serie AS-6 propiedad de la
UCP y que actualmente se encuentra en el laboratorio de PHYSILAB
construyendo para el brazo toda una infraestructura –en hardware y en software–
capaz de soportarlo pero que también sea funcional para los objetivos de la
práctica de laboratorio que se pretende que se desarrolle. Este proyecto en
software se integra a la arquitectura actual de PHYSILAB para que los usuarios –
en este caso los estudiantes–, puedan desarrollar una práctica de laboratorio
remoto para el área de física y de forma específica, para operaciones básicas con
vectores.
Al final del documento, se anexan pruebas y resultados y se hace una discusión
en las conclusiones con el fin de poder ofrecer alternativas de mejoramiento y
actualización de todo el sistema.
10
TITLE: DEVELOPMENT SOFTWARE FOR ROBOT ARM
John Smith Romero Solórzano
Keywords. Remote Laboratory, PHYSILAB, robotic arm, instrumentation
ABSTRACT
This project, -Development of Software Robot-Arm created in response to the
needs that arise within a macro largest multidisciplinary research at the Catholic
University of Pereira, called PHYSILAB; which essentially seeks to explore new
didactic for teaching and learning physics through information technology and
communication.
The research focuses on understanding the technological implications associated
robotic arm RobotBase serie AS-6 brand owned by the UCP and which is currently
in the laboratory of PHYSILAB building for the arm all one entire infrastructure -in
hardware and software- able to stand but which is also functional for the purposes
of the lab that is intended to develop. This project integrates software current
architecture of PHYSILAB for users in this case the students-can develop a
practical remote laboratory for physical and area specifically for basic vector
operations.
At the end of the document, tests and results are appended and a discussion on
the findings was done in order to offer alternatives to improve and update the entire
system.
1 INTRODUCCIÓN
Este trabajo de grado hace parte de una serie de proyectos de investigación
propuestos en PHYSILAB y que busca desarrollar toda una propuesta para
implementar laboratorios reales de física que puedan ser controlados a través de
Internet, por medio de software y hardware compatibles con las tecnologías
actuales y que a la vez mejore los procesos de enseñanza y aprendizaje de la
física, potenciado con las tecnologías de la información y la comunicación.
Debido a un creciente interés por el uso de la informática para potencializarla
didácticamente, y encontrar otras metodologías que simplifiquen y mejoren las
dinámicas que aparecen en las relaciones dialécticas de la enseñanza y el
aprendizaje para cualquier disciplina del conocimiento –esto incluye la física como
disciplina del conocimiento– han venido desarrollando propuestas innovadoras
gracias a los avances técnicos y tecnológicos de la informática, que abren un
amplio espectro de posibilidades motivadoras, pertinentes e incluyentes.
Por tanto, lo que caracteriza al sistema de software que se pretende desarrollar,
es que sea viable de implementar a través de la WEB, recreando así virtualmente
un laboratorio real con equipos que interactúan en lugares geográficamente
distantes; adicionalmente este software debe ser lo suficientemente flexible para
poder articularse con la plataforma de PHYSILAB a la vez de ser escalable en el
tiempo y en tamaño.
PHYSILAB es un proyecto de investigación de la Universidad Católica de Pereira,
el cual busca apoyar el desarrollo de laboratorios remotos y virtuales, distribuidos
en diferentes Zonas Geográficas, usando para ello herramientas software
gratuitas y la Red Académica de Alta Velocidad –RENATA-. El desarrollo de las
tecnologías y la manipulación remota hacen parte de una estrategia pedagógica
que buscan facilitar el proceso de aprendizaje de las ciencias básicas en este caso
en el Área de la Física.
El software construido en este proyecto “DESARROLLO DEL SOFTWARE PARA
BRAZO ROBOT”, puede ser manipulado por diversos usuarios, principalmente
docentes y estudiantes, a través de una red académica de alta velocidad
(RENATA) que conecta a las personas desde cualquier lugar del país permitiendo
además, mejorar las estrategias de enseñanza y aprendizaje para cursos de
Física a nivel básico e intermedio.
1. Introducción
12
Actualmente en el país no existe ni una metodología ni una infraestructura
consolidada que permita realizar el desarrollo de prácticas remotas en el área de
la física. Hasta el momento los mayores acercamientos que se tienen son del uso
de laboratorios virtuales basados en simulaciones de fenómenos físicos, los
cuales aunque permiten un acercamiento del estudiante al concepto, no generan
un ambiente de realismo, importante para el desarrollo del pensamiento crítico.
2 OBJETIVOS, HIPÓTESIS Y JUSTIFICACIÓN DE LA
INVESTIGACIÓN
Los objetivos marcan el norte de la investigación y se convierten en pilar
fundamental para comprender los alcances de la misma. Para esta investigación
se han definido un objetivo general y varios específicos que a continuación se
definen
2.1 OBJETIVOS
Este objetivo general corresponde al esperado para la investigación que se
desarrolla.
2.1.1 Objetivo General.
El objetivo general es:
Diseñar e implementar un software y su posible hardware asociado, que
permita la manipulación remota de un brazo robótico de 5 grados de
libertad para realizar operaciones en los laboratorios de PHYSILAB.
2.1.2 Objetivos Específicos.
Son objetivos específicos
Identificar y especificar los requerimientos de PHYSILAB
Diseñar la arquitectura del sistema
Desarrollar e implementar un prototipo funcional del software para el brazo
robótico de PHYSILAB
Elaboración y validación de plan de casos de prueba para el
funcionamiento.
2. Objetivos, Hipótesis y Justificación de la Investigación
14
2.2 HIPÓTESIS DEL PROBLEMA DE INVESTIGACIÓN
La Universidad Católica de Pereira en su componente investigativo viene
desarrollando toda una propuesta metodológica y didáctica para la enseñanza y
aprendizaje de la física basada en las tecnologías de la información y la
comunicación y la ha denominado PHYSILAB. Entre los elementos más
característicos de esta investigación, que busca generar a partir de las tecnologías
de información y la comunicación están:
Material didáctico de apoyo para la conceptualización de los principios
físicos, especialmente en la mecánica clásica.
Espacios para la participación y construcción de conocimiento colectivo,
haciendo uso de redes académicas digitales.
Laboratorios virtuales de apoyo al proceso de construcción y auto
aprendizaje, que puedan ser desarrollados por los estudiantes desde
cualquier computador con conexión a internet.
Laboratorios reales, igualmente como apoyo a los procesos de
construcción y auto aprendizaje, pero que puedan ser controlados de
forma remota, es decir, que el usuario pueda hacer control sin la
necesidad de estar físicamente presente en el sitio.
Con enfoque innovador, uno de los principios del plan de desarrollo que
actualmente se ha formulado en la Universidad Católica de Pereira, al igual que en
el Plan Nacional de Desarrollo Colombia 2010-2014, es ofrecer educación con
calidad, competitividad dentro de un marco tecnológico y de avanzada; PHYSILAB
en este sentido quiere diseñar y construir una herramienta tecnológica capaz de
soportar y administrar lo que puede hacer un docente en sus prácticas de aula,
pero también el que-hacer diario de la actividad estudiantil y sus procesos de
desarrollo cognitivo y cognoscitivo a fin de sensibilizar cada vez más a los actores
del proceso educativo –estudiantes, docentes, universidad, sociedad–, sobre la
importancia del trabajo colaborativo, integrativo y virtual dentro de esquemas de
aprendizaje autónomo, motivando así la capacidad emprendedora e innovadora de
los estudiantes, generando una cultura de autorregulación y de responsabilidad
consigo mismo y con su comunidad.
2. Objetivos, Hipótesis y Justificación de la Investigación
15
Actualmente existe una inmersión de los centros de formación (escuelas, institutos
de educación para el trabajo, el SENA y universidades) en la virtualización de sus
procesos, y en lo que se refiere al objeto de estudio de este proyecto, la
virtualización de algunas actividades curriculares de enseñanza y aprendizaje.
Es por eso que es cada vez más frecuente encontrar dentro de la oferta
académica de las instituciones, cursos semi-presenciales e inclusive, cursos y
carreras totalmente virtuales, que demandan una nueva organización curricular
con docentes preparados y planes bien orientados y desde luego, bien
acompañados.
Por ello PHYSILAB pretende precisamente indagar sobre las dinámicas existentes
en los laboratorios de física virtual y remoto, y servir como herramienta para el
aprendizaje en éstos campos del conocimiento.
Dada la situación como problema planteado en la sección anterior, se propone
como alternativa de solución tanto económica como técnicamente viable, la
construcción de un sistema completo que a través de un software funcione por
medio de Internet, y permita al usuario remoto, tener el acceso y control total del
brazo robótico quien ejecutará las acciones que demande la práctica de
laboratorio.
En este sentido se puede plantear como hipótesis la necesidad de desarrollar el
software que permita realizar el uso de un brazo robótico de 5 grados de libertad
para ejercer operaciones dentro del laboratorio remoto PHYSILAB.
2.3 JUSTIFICACIÓN
El proyecto se realiza con el objeto de ir a la vanguardia de las nuevas
tecnologías. Como es bien sabido en el mundo de las tecnologías todo pasa y
avanza muy rápido, a velocidades aceleradas, por ello es necesario estar
preparados con el objeto de que no disminuya la motivación y el auto-desarrollo
de talentos y capacidades de los estudiantes, haciendo que en ellos surja siempre
la reflexión, sean autocríticos y autodidactas.
El proyecto software se desarrolla para el laboratorio PHYSILAB, que busca, en
resumen, ser una plataforma que presta un conjunto de prácticas de laboratorio de
2. Objetivos, Hipótesis y Justificación de la Investigación
16
Física en el área de mecánica clásica, la mecánica ondulatoria, la electricidad y el
magnetismo que puedan ser ejecutadas de manera remotas.
El brazo robot ayuda a efectuar una práctica física de laboratorio, relacionada a la
temática de vectores, elemento conceptual fundamental para comprender las
implicaciones matemáticas y geométricas de otros movimientos como el rectilíneo
uniforme, el rectilíneo acelerado, el movimiento en el plano y las leyes de
movimiento newtoniano, columna vertebral de toda la mecánica clásica.
Con la solución física no es suficiente, es allí donde se convierte en punto clave y
necesario el tener la presencia de un software que permita manipular el brazo de
la manera adecuada. El software es el que nos permite crear los movimientos del
brazo y además podrá hacer la integración con el sistema ya desarrollado por
PHYSILAB lo que permitiría que el proyecto PHYSILAB, pueda escalar un peldaño
en sus etapas de desarrollo.
3 MARCO TEÓRICO
El marco teórico donde se sustenta la propuesta de investigación y que sirve como
referente que orienta el diseño y construcción de los prototipos y software es el
siguiente:
3.1 ANTECEDENTES HISTÓRICOS
Los antecedentes históricos de desarrollos tecnológicos y científicos de
aplicaciones similares a esta investigación, ahorran tiempo y recursos en el
sentido que han recorrido un camino y sobre este se ha obtenido algún tipo de
experiencia y se han llegado a conclusiones. Por ésta razón, la revisión de
antecedentes históricos se convierte en parte fundamental de esta investigación y
la explican mejor desde su dimensión teórica.
3.1.1 Brazo mecánico realizado en La Universidad del Valle / México.
Los brazos mecánicos han sido una práctica académica muy poco usual, y de
naturaleza distinta, morfologías diversas y aplicaciones igualmente variadas. Sin
embargo se logra identificar que para lograr el movimiento repetitivo y sistemáticos
los elementos más utilizados son los mecánicos, eléctricos y electrónicos.
“Se desarrolló y fabricó un brazo mecánico de dos grados
de libertad controlado por un PIC16F883, para asistir a los
estudiantes en el aprendizaje de materias relacionadas
con mecánica racional, electrónica, programación y
robótica. Este proyecto surge del reclamo que hay en la
actualidad y de los conceptos con los que se inicia la
construcción de un brazo mecánico controlado por un
PIC. El proyecto requirió de tres motores de corriente
directa para la manipulación de sus grados de libertad.
Teniendo así un costo considerable.”(Jeronimo, Jorge,
Esau, &Lizzouliizchel)
Este proyecto desarrollado por estudiantes de la Universidad del Valle de México,
muestra cómo toman un brazo robot y es intervenido por medio de controladores o
micro-controladores electrónicos. Estos son elementos que por medio de unos
pines de entrada y salida, reciben información, envían órdenes a otros dispositivos
3. Marco Teórico
18
y además pueden guardar programas que después se ejecutarán. Este medio de
control para los hardware es el más utilizado para circuitos electrónicos que
controlan la mayoría de elementos sistemáticos. Sin embargo se debe tener en
cuenta en el proceso de desarrollo desde que nivel se empieza a programas y las
ventajas y desventajas que se tienen en ese punto.
El brazo robot utilizado en este proyecto es un brazo independiente, es decir no va
articulado a ningún otro sistema, y sus rutinas solamente están constituidas por
una serie de repeticiones de movimientos. Su aplicación es netamente industrial,
sin embargo esto exige un alto grado de precisión.
En el desarrollo de éste proyecto desarrollado en México, se analiza la mezcla del
hardware, así que esa parte no es de interés para el actual proyecto. Sin embargo
no sobra decir que se mencionan allí una serie de programas que acompañaron el
desarrollo que se hacía en la parte de los circuitos.
Las conclusiones del proyecto implantado en la Universidad del Valle y las
adversidades mencionadas en él, sólo se refieren a la parte física del desarrollo.
3.1.2 Brazo robot dela universidad Tecnológica de Mixteca / México.
Otro proyecto interesante dentro de la línea de los brazos robots fue desarrollado
por José Alberto Chávez Aragón, en la Universidad Tecnológica de la Mixteca
donde el hardware se comunicaba a un Computador Personal, mediante el uso de
puerto serial.
“Para controlar de manera eficiente el brazo robótico, y
poder encomendarle tareas repetitivas, como es el caso
de poner piezas de juego en nueve diferentes casillas de
un tablero de gato, fué necesario desarrollar un software
en el cual se pudieran programar al robot una secuencia
de movimientos, y que éste la repitiera cada vez que
fuese necesario. Para esto lo primero que se hizo fue
definir una posición inicial o un punto de salida a partir del
cual el robot deberá iniciar cualquier secuencia de
movimiento, y al término de dicha secuencia retornar a
esa posición inicial”(Aragón, 1999)
El desarrollo software que se hizo está programado sobre plataforma Windows, sin
embargo no se especifica nada sobre el proceso de desarrollo que tuvo éste. El
3. Marco Teórico
19
proyecto hace más énfasis en las funcionalidades y opciones que tiene el
programa controlador. Como características adicionales está programado en C
que es la base del tradicional DOS de Microsoft.
El software permite principalmente crear una secuencia de movimientos que
puede ser guardado y ser utilizado después en cualquier momento. En el proyecto
lo utilizan para realizar un movimiento determinado y así desarrollar la dinámica de
un juego llamado gato.
Este brazo robot también cuenta con un sistema de visión el cual no se detalla en
la documentación reportada, sin embargo para el brazo robótico que se pretende
desarrollar para PHYSILAB no es de importancia y no tiene relación con el fin de
éste proyecto por la autonomía de la arquitectura propia.
Como dificultades a destacar en este desarrollo que se pueden tener en cuenta,
es la dificultad que se tuvo para controlar la precisión del brazo, y ésta
problemática iba muy ligada a la naturaleza de los motores que componían el
brazo robot.
3.1.3 Brazo robot realizado en Ecuador.
En ecuador se programó un robot para organizar fichas con figuras geométricas,
Este desarrollo fue realizado por dos investigadores de tecnología como proyecto
de investigación en la Escuela Politécnica Nacional. Las figuras geométricas están
sobre una superficie plana y el robot por medio de imágenes lee las coordenadas
de las fichas y sabe diferenciarlas unas de otras.
“Se ha desarrollado satisfactoriamente una aplicación que
permite distinguir dentro de un grupo de figuras
localizadas en una plataforma A, que corresponden a
figuras geométricas regulares tales como círculos
cuadrados y triángulos, para luego transportarlas de una
manera ordenada hacia una plataforma B, con la ayuda
de un adecuado posicionamiento de las articulaciones del
brazo robótico.”(Besantes Ortiz & Torres Tufiño)
Sin embargo en el documento de apoyo de éste desarrollo no se habla a
profundidad del desarrollo del software. No se menciona la metodología usada y
tampoco la plataforma en que está soportada.
3. Marco Teórico
20
3.1.4 Brazos Robots en Colombia
En el ámbito nacional si bien se ha realizado desarrollos e implementaciones de
robótica, es necesario resaltar que si se han implementado no se han
documentado, ya que en la búsqueda de referentes nacionales no se encontraron
documentos ni ningún tipo de escrito sobre algún desarrollo de esta naturaleza.
3.2 MARCO CONCEPTUAL
Éste proyecto software es orientado conceptualmente por las teorías, y principios
de la Ingeniería del Software, e igualmente tiene asociado algunos principios
físicos que se tratan más adelante, en este sentido es importante establecer
algunos elementos categoriales transversales:
3.2.1 Ingeniería del software
Según Morales (2006), la ingeniería del software es el establecimiento y uso de
principios robustos, orientados a obtener software económico que sea fiable y
funcione de manera eficiente sobre máquinas reales, de esto se puede deducir
que durante un buen tiempo en las disciplinas que apuntan hacia el sector del
software se han desarrollado muchos conceptos para que su desarrollo cada vez
sea más fiable y seguro, evitando así pérdidas en tiempo, recursos, y demás
activos en un proyecto.
La arquitectura sirve para planear mejor lo que se va hacer. La arquitectura debe
ser una respuesta, no una imposición, deber ser una necesidad para dar solución.
El rol de un arquitecto debe contar con un conjunto básico de habilidades y
conocimientos para ejercer las acciones, ya que es diferente un problema a
solucionar un problema u otro más complejo.
Cada escenario plantea retos y condiciones diferentes, por ello cada condición y
cada problema debe presentar una solución diferente, a una necesidad diferente
una solución diferente.
Programar sin planear, termina llevando a un estancamiento del software llegando
a un punto oscuro que obliga abandonar el proyecto. La arquitectura representa la
base de un software, para que satisfaga las necesidades actuales, permitiendo
3. Marco Teórico
21
que el sistema evolucione, se adapte a los cambios, según el contexto y las
necesidades de cada usuario.
El inicio de ésta arquitectura tiene partida desde la definición de los requerimientos
del Software, los cuales determinan el modelo. Estos requisitos son de variadas
formas, con conocimiento disponible a través de un sistema de información, el cual
debe ser funcional, esto es la capacidad de un sistema de hacer lo que en un
principio se pretendía que hiciese, con requisitos de calidad. Cada sistema se
descompone a la vez en variados elementos, los cuales corresponden a variados
propósitos, y ya con la arquitectura del software se implementa la funcionalidad
deseada.
3.2.2 Atributos del software
Éstos conceptos y conocimientos ya empleados y establecidos en la ingeniería del
software permiten que proyectos como éste puedan desarrollarse de una manera
adecuada empleando cada uno de los procesos que ya han sido probados y
certificados, hasta por entes y organizaciones de nivel global. Es por eso clave
poder entender a cabalidad la razón de ser de cada tarea o labor que se vaya a
desarrollar y como impactará al proyecto, para así poder tener un control lógico y
funcional del avance del software que se está desarrollando.
Está también claro que el software abarca más que el mercado de aplicaciones y
sistemas operativos, dado que también se puede encontrar en todo tipo de
máquina, y como maquina se puede entender el brazo robot, como un hardware
que ya está creado y establecido pero que necesita su software, el cual es el
objetivo de éste proyecto. De allí se puede inferir que es de vital importancia
entender y conocer la naturaleza del hardware, como funciona y qué clase de
software necesita, ésto permitirá que hardware y software se complementen de la
manera adecuada y den solución a la problemática planteada, como claramente
se ve referenciado en la siguiente cita:
“El objetivo principal de la Ingeniería del Software es: Construir
una solución de software eficiente que satisfaga las necesidades
requeridas por un cliente.” (Mórales, 2006)
Existen dos tipos de producto software(Sommerville, 2005)
3. Marco Teórico
22
1. Productos genéricos
2. Productos personalizados (o hechos a la medida)
El tipo de software requerido para el proyecto actual, según las divisiones
planteadas por este autor, es un software personalizado. El software genérico se
produce aisladamente a cualquier organización, se toma una necesidad general y
se venden a quien les pueda ser útil la solución del software construida. Como
ejemplos de estos pueden ser las líneas de sistemas operativos como Windows o
Mac O.S, o aplicaciones como editores de texto u hojas de cálculos.
Pero el software personalizado se desarrolla para una necesidad y cliente en
particular, en este caso la Universidad Católica de Pereira, con su proyecto de
investigación “PHYSILAB”. Su desarrollo está ligado al hardware del brazo y a su
funcionalidad especifica dentro de la metodología de funcionalidad dentro del
laboratorio. Su desarrollo solamente se validará para que funcione solamente en
un brazo específico, y si se va a probar en el otro, este al instante deberá ser física
y exactamente igual, ya que cualquier variación afectará el funcionamiento del
software.
Los proyectos de software pueden iniciar a partir de una o varias de las siguientes
consideraciones:
Demanda del mercado.
Necesidad de negocio.
Petición de un cliente.
Avance tecnológico (innovación).
Requisito legal (actualización o nueva implementación).
Necesidad de la sociedad.
Problema detectado.
3. Marco Teórico
23
El actual desarrollo se podría calificar, como un proyecto de software iniciado un
avance tecnológico, el cual fue Physilab y su metodología virtual. De una nueva
implementación y didáctica de aprendizaje; el brazo robot, se requiere un software
que apoye este avance tecnológico para que pueda ser funcional.
También, por su especificidad, es posible que la carta de un proyecto de software
requiera más información de la asignada, de tal forma que el Director o los
ingenieros a cargo puedan iniciar de manera adecuada el proceso de desarrollo y
de gestión.
En cuanto al hardware, aunque no es motivo de este proyecto desarrollarlo ni
construirlo, si es necesario entender su funcionamiento ya que va directamente
ligado con la función del software.
3.2.3 Arduino
El hardware del brazo robot tiene un elemento clave en su funcionamiento físico, y
es el motor. Los diferentes motores son los que permiten que el brazo se mueva.
Es importante reconocer que señales eléctricas se le tienen que dar a éstos
motores para que hagan lo que se requiere, es decir, que se muevan de forma
apropiada.
Para poder integrarlos y controlarlos todos juntos además de integrar los otros
elementos que componen el brazo, se va a utilizar un Arduino.
“Arduino es una herramienta para hacer que los
ordenadores puedan sentir y controlar el mundo físico a
través de tu ordenador personal. Es una plataforma de
desarrollo de computación física (physicalcomputing) de
código abierto, basada en una placa con un sencillo
micro-controlador y un entorno de desarrollo para crear
software (programas) para la placa.”(Arduino, 2013)
Así que el elemento de control del brazo robot, es el Arduino, el cual se convierte
en motivo de investigación de este proyecto. Los Arduino son sistemas que ya
vienen armados, poseen una serie de puertos y pines de entradas y salidas
establecidos. Los Arduino tienen un ambiente de interfaz programable que facilita
el desarrollo de aplicaciones, en este caso permitir manejar los impulsos eléctricos
que se generaran para cada motor del brazo robot.
3. Marco Teórico
24
Arduino es una plataforma de código abierto basado en prototipos de electrónica
flexible y fácil de usar hardware y software. Está pensado para artistas,
diseñadores, aficionados o cualquier persona interesada en la creación de objetos
interactivos o entornos. El entorno de código abierto Arduino hace fácil escribir
códigos y cargarlos a la placa E/S. Funciona en Windows, Mac OS X y Linux. El
entorno está escrito en Java y basado en Processing, avr-gcc y otros programas
también de código abierto.
Arduino por su naturaleza de ser código abierto pone a disposición su código
fuente a cualquier usuario, sin embargo su calidad no se pone en duda debido a la
gran cantidad de desarrollos en esta plataforma.
Es importante tener en cuenta la referencia y la línea del Arduino a utilizar, ya que
algunas placas de Arduino vienen precargadas con un gestor de arranque
(bootloader) que permite cargar un nuevo código sin necesidad de un
programador por hardware externo. Se comunica utilizando el protocolo especial
para ésta tarea.
El software de Arduino consiste en un entorno de desarrollo (IDE) y las bibliotecas
del núcleo. El IDE está escrito en Java y basado en el entorno de desarrollo de
Processing. Las bibliotecas centrales están escritos en C y C + + y compilado con
gccavr-libc y AVR. El código fuente para Arduino está ahora alojado en GitHub.
3.2.4 Los ciclos de vida del software:
Los ciclos de vida del software nos definen los tiempos y las actividades a
desarrollar dentro del desarrollo de un software. Esto permite hacer que el proceso
de ingeniería que se le hace a algún software sea organizado. Los ciclos de vida
del software establecen un modelo evolutivo, para mostrar los avances hechos por
el equipo desarrollador del proyecto.
“La producción de software es algo más que la
programación; hay etapas que la preceden y otras que la
siguen. El ciclo de vida del software está constituido de
todas éstas etapas. Los métodos y técnicas de la
3. Marco Teórico
25
ingeniería del software se inscriben dentro del marco
delimitado por el ciclo de vida del software, y, más
concretamente, por las diferentes etapas que se
distinguen. La misma existencia de distintos modelos del
ciclo de vida del software hace comprender que no hay
ninguno que sea ideal o que no tenga grandes
limitaciones.”(Campderrich Falgueras, 2003)
Existen diferentes modelos de ciclos de vida. Se nombrarán y se explicarán
brevemente los más importantes, teniendo en cuenta que por uno de ellos ira
encaminado el presente proyecto.
Modelo en Cascada: Es el modelo más antiguo; data de los años 1970.
Fuente: Sommerville, I. (2005). Ingeniería Del Software. Madrid, España:
Pearson Educación S.A.(Sommerville, 2005)
Figura 3.1. Modelo en Cascada
3. Marco Teórico
26
Es un modelo que como ventajas tiene la claridad en sus tiempos y tareas, sin
embargo su estructura rígida no permite retroceder en el proceso y el hacerlo
significa un proceso traumático dentro del desarrollo. Si éste se elige como ciclo
de vida para el actual proyecto se pueden prever las siguientes situaciones:
Una rigidez entre cada proceso, puede ocasionar que un retroceso forzado
lleve consigo un atraso importante en los tiempos establecidos.
La organización que se puede dar en cada una de las etapas es
fundamental para definir roles en cada ítem y además las tareas están más
concretas para cada tiempo de desarrollo.
Es un ciclo de vida que requiere espacio de tiempo largos y ésto haría
perder dinámica en el desarrollo.
La poca interacción con el cliente que plantea éste modelo impide una
validación constante con el cliente.
Modelo Evolutivo: Este modelo suele ser más eficiente que el modelo en
cascada porque se tiene mayor interacción con el cliente y por ellos se satisfacen
más rápido sus necesidades inmediatas. Sin embargo los sistemas desarrollados
tienen dos dificultades principalmente; que la mayoría de los procesos no son
visibles y que por su naturaleza es difícil crear una estructura sólida en el sistema.
“El desarrollo evolutivo se basa en la idea de desarrollar
una implementación inicial, exponiéndola a los
comentarios del usuario y refinándola a través de las
diferentes versiones hasta que se desarrolla un sistema
adecuado” (Sommerville, 2005)
3. Marco Teórico
27
Fuente: Sommerville, I. (2005). Ingeniería Del Software. Madrid,
España: Pearson Educación S.A. (Sommerville, 2005)
Figura 3.2. Modelo Evolutivo
Si éste modelo de ciclo de vida es el elegido para el desarrollo del actual
proyecto, se pueden describir algunas situaciones que se presentarán como:
Una constante validación con el cliente permitiendo que no se tomen
rumbos alejados del resultado esperado.
La flexibilidad de éste modelo en cuanto a los tiempos y relaciones entre
etapas de desarrollo prestan una vía dinámica, sin embargo se debe
manejar con mucha precaución debido a que sin control se puede generar
un desorden en el desarrollo.
Modelo Ingeniería basada en Componentes: Su naturaleza es hacer la
reutilización de software, tales como librerías, componentes y cualquier fragmento
de código que pueda ser implementado en cualquier otro software.
3. Marco Teórico
28
Fuente: Sommerville, I. (2005). Ingeniería Del Software. Madrid, España: Pearson Educación S.A.
Figura 3.3. Modelo basado en componentes
Como se observa en la figura, éste modelo según los requerimientos analiza
componentes (software) que puede reutilizar, modifica lo necesario en los
requerimientos para que no haya problemas con esa parte, y sigue su proceso
normalmente.
La ventaja obvia es la reducción significativa del software a desarrollar, sin
embargo el manejo que se hace con los requerimientos puede hacer que el
software no satisfaga las necesidades del cliente. Este modelo no es aplicable al
proyecto, debido a que si bien, pueden encontrarse módulos de desarrollo ya
implementados, el entorno tecnológico en que se va a desarrollar el brazo es
bastante particular, tal que exige un desarrollo único.
Modelo en Espiral: Como principal diferencia, el modelo en espiral evalúa más
concienzudamente los riesgos del proyecto, en cada una de sus fases, sin
embargo por su naturaleza iterativa es difícil a veces ensamblar las diferentes
espirales o ciclos espirales que se hacen.
“Más que representar el proceso del software como una
secuencia de actividades con retrospectiva de una
actividad a otra, se representa como una espiral. Cada
ciclo en la espiral representa una fase del proceso del
software. Así, el ciclo más interno podría referirse a la
viabilidad del sistema, el siguiente ciclo a la definición de
requerimientos, el siguiente ciclo al diseño del sistema y
así sucesivamente” (Sommerville, 2005)
3. Marco Teórico
29
Fuente: Sommerville, I. (2005). Ingeniería Del Software. Madrid, España: Pearson Educación S.A
Figura 3.4. Modelo en espiral
Esos son los principales modelos de ciclos de vida del software. Es importante que
se tenga claro que los proyectos software deben ajustarse a uno de éstos para dar
credibilidad al desarrollo.
Si éste es el ciclo de vida que adopta el proyecto, es importante recalcar que por
la naturaleza del desarrollo podría ser muy beneficioso, ya que se partirá a
construir un prototipo de menor nivel y de éste se empezará a crecer hasta
obtener el producto final. Sin embargo es necesario recalcar que éste modelo de
vida implica una dinámica de trabajo continua y organizada, además de definir en
cada tiempo de desarrollo muy bien las tareas a realizar.
3. Marco Teórico
30
3.2.5 Principios físicos y geométricos usados.
Physilab, siendo un laboratorio remoto que permite la interacción de usuarios con
experimentos de física, es el encargado de direccionar que este nuevo software
pueda ser una base para el estudio y compresión de algunos principios de los
vectores.
Un vector de una representación analítica y geométrica que tiene básicamente
cuatro propiedades importantes.
Magnitud|𝐴|: Es la longitud o dimensión del vector, también conocida
como Norma corresponde el tamaño del vector
Dirección 𝜽: Es el ángulo o conjunto de ellos, que forma el vector
con respecto a algún eje de referencia.
Sentido: Indica la posición y ubicación en el espacio bidimensional o
tridimensional, estableciendo si el vector sube, baja, tiende hacia
un lado o a otro.
Punto de aplicación: Es el lugar geométrico desde donde actúa el
vector
Fuente. PHYSILAB Conceptos y ejercicios. Pág 44.
Figura 3.5. Representación geométrica de un vector.
3. Marco Teórico
31
Con éstos vectores se pueden representar diversas situaciones en física como la
velocidad, la aceleración y la fuerza por mencionar tan solo algunas; igualmente a
éstos vectores se tienen asociadas ciertas operaciones básicas con propiedades
muy específicas; para la intención de ésta investigación solamente se analiza la
suma, ya que es la operación que se va a modelar más adelante.
Para realizar gráficamente la suma de dos vectores a través del Método del
Paralelogramo; se traslada uno de los vectores de forma paralela –sin cambiar ni
la magnitud ni la dirección y tampoco el sentido– hasta la cabeza del otro,
posteriormente se une el inicio del primer vector con el final del segundo vector y
éste nuevo vector es igual al vector suma, tal como se ilustra en la figura siguiente.
Fuente PHYSILAB. Conceptos y Ejercicios. Pág. 50.
Figura 3.6. Método del paralelogramo para la suma de dos vectores.
Tal como se expone, el brazo robótico pretende ser apoyo al desarrollo de
conceptos y categorías en los estudiantes de física, para que usen como
herramienta de mediación cognitiva, los recursos que ofrece PHYSILAB. En éste
sentido se propone la construcción de una práctica de laboratorio remoto para
fundamentar la idea de suma de vectores. Ámbito de gran importancia para
comprender la naturaleza y comportamiento en otros sistemas.
La idea fundamental es que cada brazo del robot represente un vector, del cual se
tiene la longitud y que el usuario, en éste caso el estudiante, pueda cambiar el
ángulo a través de software basado en tecnología WEB; debido a la necesidad de
3. Marco Teórico
32
reducir las complejidades para ésta parte de los cursos de física, el equipo de
gestión de PHYSILAB, determina restringir el movimiento del brazo a un solo
plano, con dos puntos de articulación. Por otro lado para resolver el problema
técnico de apreciación y reducir el error de paralelaje, se opta por el primer
cuadrante como espacio de referencia.
Imagen adaptada del portal http://www.datuopinion.com/puma-robot
Figura 3.7. Representación modelada aproximada de un brazo robótico para el laboratorio de suma de vectores.
3. Marco Teórico
33
A partir de éste modelo, se construye una representación geométrica más
aproximada del sistema y los ángulos y medidas de referencia que se toman para
la realización de la práctica de laboratorio.
Fuente Propia
Figura 3.8. Modelo matemático para el cálculo de la suma de dos vectores en el plano. .
El punto 𝑞 que corresponde con el punto de articulación de los dos brazos o
vectores, está determinado exclusivamente por la longitud y dirección del vector a
y el ángulos de inclinación 𝜃1, así la naturaleza analítica de su posición está
determinada por la siguiente expresión:
𝑞𝑥 = 𝑎 ∙ cos 𝜃1
𝑞𝑦 = 𝑎 ∙ sin 𝜃1
[Ec. 3.1]
Sin embargo para conocer el lugar geométrico del punto p, es necesario
establecer las relaciones matemáticas en magnitud y dirección de los dos vectores
que participan en esta operación, para esto, conocidas las longitudes del vector a
y del vector b y sabiendo los ángulos𝜃1 y 𝜃2 la posición final del vector suma está
dada por la expresión algebraica
3. Marco Teórico
34
𝑝𝑥 = 𝑐 ∙ cos 𝜃𝑥
𝑝𝑦 = 𝑐 ∙ sin 𝜃𝑥
[Ec. 3.1]
Donde el valor de c, se obtiene por el teorema del coseno como:
𝒄 = |√𝑎² + 𝑏² + 2𝑏𝑐 ∙ 𝑐𝑜𝑠𝜃2| [Ec. 3.2]
Y el valor de 𝜃𝑥 se obtiene mediante la expresión
𝜃𝑥 = 𝜃1 − arccos [𝑎² + 𝑐² − 𝑏²
2𝑎𝑐] [Ec. 3.2]
Con éstas ecuaciones y previamente establecidos los valores de ángulos para
cada vector, se puede encontrar el valor del vector suma, en términos de sus
coordenadas geométricas.
3.3 METODOLOGÍAS DE DESARROLLO DE SOFTWARE:
Las metodologías surgen como respuesta al gran déficit en los procedimientos que
tuvo el desarrollo de software en sus inicios. Desde allí, han salido propuestas, y
con el tiempo cada vez más completas y estructuradas, todas con el fin de hacer
que el software tenga buena calidad.
“Las metodologías se basan en una combinación de los modelos de proceso
genéricos (cascada, incremental…). Definen artefactos, roles y actividades, junto
con prácticas y técnicas recomendadas. La metodología para el desarrollo de
software es un modo sistemático de realizar, gestionar y administrar un proyecto
para llevarlo a cabo con altas posibilidades de éxito. Una metodología para el
desarrollo de software comprende los procesos a seguir sistemáticamente para
idear, implementar y mantener un producto software desde que surge la necesidad
3. Marco Teórico
35
del producto hasta que cumplimos el objetivo por el cual fue creado.”(Laboratorio
Nacional de Calidad del Software, 2009)
Han sido desarrolladas por empresas, por universidades, por algunos gobiernos o
estados y también entes regulatorios en el área de sistemas, todos con el fin de
mejorar este ítem en el desarrollo de software, y proporcionar métodos efectivos
para asegurar una buena calidad en el producto final, y así satisfacer de una
manera correcta las necesidades. En seguida se nombraran las más relevantes
dentro del mundo del desarrollo, y se describirán brevemente.
Hay dos grandes clasificaciones en las metodologías; metodologías ágiles y
metodologías tradicionales.
Metodologías Tradicionales: Se caracterizan por su robustez, por su buena
documentación en cada proceso, pero como desventaja tiene los altos
costos que se generan al implementar un cambio.
Metodologías Ágiles: Nace como una propuesta a los problemas o falencias
de las metodologías tradicionales. Son más flexibles a los cambios en el
desarrollo pero en los procesos se tiene menos control.
A continuación se nombrará las metodologías más reconocidas que existen
actualmente, la mayoría de ellas reconocidas mundialmente por los diferentes
entes que regulan el software.
3.3.1 RUP.
Rup es muy utilizada generalmente para proyectos grandes debido a que es una
metodología que es muy centrada en la fase de arquitectura, ésto permite que la
robustez de los problemas a solucionar sea abordada de una manera organizada y
muy bien planeada.
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.(Laboratorio Nacional de Calidad del Software, 2009)
3. Marco Teórico
36
3.3.2 Scrum.
Scrum por su naturaleza iterativa incremental tiende a generar tareas pequeñas
para que sean desarrolladas en cada iteración, se caracteriza también por los
pocos roles que tiene dentro de su desarrollo y por su alto uso en aplicaciones
relativamente livianas.
“Scrum es un proceso ágil que se puede usar para gestionar y controlar
desarrollos complejos de software y productos usando prácticas iterativas e
incrementales. Scrum es un proceso incremental iterativo para desarrollar
cualquier producto o gestionar cualquier trabajo. Aunque Scrum estaba previsto
que fuera para la gestión de proyectos de desarrollo de software, se puede usar
también para la ejecución(Laboratorio Nacional de Calidad del Software, 2009)
3.3.3 PSP
Proveniente del Instituto de Ingeniería del Software (SEI), PSP es una alternativa
que permite mejorar la forma en la que se construyen software. Considerando
aspectos como la planeación, calidad, estimación de costos y productividad, PSP
es una metodología que se puede implementar cuando el ingeniero de software
está interesado en aumentar la calidad de los productos de software que
desarrolla dentro de un contexto de trabajo individual.
“El proceso de software personal (PSP, Personal Software
Process) es un modelo para la mejora del proceso de
desarrollo de software, está basado en la creencia que la
calidad del software depende del trabajo de cada uno de
los ingenieros; por lo cual, el proceso debe ayudar a
controlar, manejar y mejorar el trabajo de éstos. El
objetivo de PSP es mejorar la planeación, conocer con
precisión el desempeño, medir la calidad de los productos
y mejorar las técnicas de desarrollo. .”(Weitznefeld)
3. Marco Teórico
37
3.3.4 TSP.
El TSP ofrece un contexto disciplinado para el trabajo de ingeniería. La motivación
principal es que los ingenieros siguiendo ésta metodología pueden hacer un
excelente trabajo. Los ingenieros deben estar bien capacitados, bien entrenados y
deben ser bien dirigidos por un miembro calificado que entienda bien la
metodología del TSP. El objetivo principal del TSP es guiar debidamente esos
equipos de ingenieros.
“El proceso de software en equipos, (TSP, Team Software
Process) extiende el modelo PSP e integra los aspectos
del desarrollo de software realizados por equipos de
trabajo, definiendo aspectos como la asignación y control
de tareas para los diversos miembros del equipo.
(Weitznefeld)
3.4 MARCO CONTEXTUAL
El eje cafetero, con Pereira como principal núcleo urbano en la zona, presenta un
gran potencial en los mercados del software.
El desarrollo tecnológico y el fortalecimiento de sus estructuras tecnológicas entre
otros son algunas de los factores que han sido determinantes para el
establecimiento de nuevas empresas de desarrollo de software y la apertura de
sedes de la industria internacional.
Un ejemplo es la apertura de un nuevo laboratorio de software que se suma a la
red de más de 75 Centros de Excelencia y software con los que cuenta la
compañía INDRA, empresa multinacional desarrolladora de software, que tiene
presencia en 40 ciudades, 25 de ellas en Latinoamérica.
Así como INDRA, algunas compañías fuertes han empezado a ver a Pereira como
una ciudad a tener en cuenta. También en la región existen proyectos como el
Clúster TIC del Eje Cafetero. Esta iniciativa busca la articulación real entre las
empresas desarrolladoras de software, tecnología, con las universidades y el
Gobierno, para apoyar y facilitar el fortalecimiento de la industria TIC en la región.
El clúster es un gran principio para una asociación creativa en donde la región se
pone de acuerdo para construir conocimiento que sea competitivo basado en la
calidad y en la especialización.
3. Marco Teórico
38
En todo este contexto y como abanderado del promotor del software en Pereira
encontramos a ParqueSoft, que es una fundación sin ánimo de lucro cuyo
propósito es facilitar a jóvenes emprendedores la creación y desarrollo de
empresas de base tecnológica que provean al mercado de productos y servicios
de tecnología informática. Es además, el clúster de Arte Digital, Ciencia,
Tecnología y servicios relacionados más importante de Colombia y uno de los más
sobresalientes de América Latina. (ParqueSoft, 2011)
Ubicados en la actualidad en el CDV (Centro de Desarrollo Vecinal) del barrio San
Luis, gracias al apoyo de la Alcaldía de Pereira y a la Universidad Tecnológica de
Pereira, se ha logrado consolidar un modelo de emprendimiento viable y con
resultados a nivel internacional (7 premios de innovación mundiales) que han
logrado posicionar a Pereira como un referente importante en el desarrollo de
emprendimiento en la industria del conocimiento, haciendo cada vez más pequeño
el espacio físico del parque y cada vez más grande el límite de los sueños de sus
emprendedores.
En la ciudad de Pereira, ParqueSoft inicia labores hace más de siete (7) años.
Actualmente cuenta con un total de cuarenta y ocho (48) empresas y noventa y
cuatro (94) emprendedores desarrollando proyectos de base tecnológica e
investigación en áreas de Gestión empresarial, inteligencia de negocios,
educación, media digital, medio ambiente, industria y servicios; además de ésto
cuenta con diferentes reconocimiento a nivel nacional e internacional donde
algunas de sus empresas han sido ganadoras en 5 ocasiones de TIC América y 4
veces del Global TIC.(ParqueSoft, 2011)
En cuanto el entorno específicamente académico está La Universidad Católica de
Pereira, que es una institución académica sin ánimo de lucro. La Universidad
Católica de Pereira (antes Universidad Católica Popular del Risaralda) nació
gracias a la iniciativa, la capacidad emprendedora y decisión de un grupo de
estudiantes que deseaban una alternativa académica diferente a las existentes en
la ciudad de Pereira, para su formación profesional. En medio de grandes
limitaciones financieras y académicas lograron crear un centro de estudios que
llamaron "Fundación Autónoma Popular del Risaralda", en el cual se ofrecían los
programas de Derecho y Economía Industrial.
Actualmente la Universidad Católica de Pereira está ubicada en un área
construida de 13.181 m2 y cuenta con una población cercana a los 2.300
3. Marco Teórico
39
estudiantes, 180 profesores y 100 colaboradores entre directivos, administrativos y
servicios generales, todos trabajando al servicio de una misma causa. Dentro de la
institución, está la Facultad de Ciencias Básicas e Ingeniería, que ofrece el
programa de Ingeniería en Sistemas y Telecomunicaciones. Como proyecto de
grado para esta carrera de pregrado está el presente documento.
Dentro de la Universidad Católica de Pereira y como 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 aprobado en la convocatoria
“banco de proyectos elegibles para apoyar la investigación, el desarrollo y la
innovación educativa que 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.
Este grupo de investigación da nacimiento a Physilab, el proyecto de laboratorio
de física virtual, y el software del brazo robot, será una dinámica as dentro de las
que presenta Physilab a sus usuarios.
3.5 MARCO METODOLÓGICO
Las etapas de desarrollo del software que nos definirán la metodología a seguir se
describe a continuación, aunque son conceptos bastante amplios y que se han
alimentado por muchos expertos en el mundo del software a nivel mundial, se
mencionan como se van a enfocar en este proyecto y como se van a desarrollar
las tareas que conllevan en la actual dinámica.
3.5.1 Análisis y Diseño
Aquí se centrará el trabajo en comprender en su totalidad la problemática a
solucionar. Se contextualizará el grupo de trabajo y se tendrá contacto directo con
el espacio de desarrollo e implementación. Se elegirá un modelo de ciclo de vida y
una metodología para desarrollar el software. Se empezarán a tomar en cuenta las
tareas de análisis de robótica y demás conocimientos circuitales que se requieran
para interactuar con el brazo. Se conocerán las especificaciones técnicas
necesarias del software al cual será incrustado éste proyecto y se investigará
cómo ese proceso se puede hacer sin traumatismo.
3. Marco Teórico
40
Toma de Requisitos: Se hablará con el cliente para que el de su lista de
requisitos o condiciones que debe tener y cumplir el sistema. Además
describirá la funcionalidad que se espera del software y demás expectativas
sobre éste. Se conocerá el entorno en el que el software se implementará y
demás elementos que influyan en su funcionamiento, para que su
desarrollo sea lo más adecuado posible.
Especificación de los Requerimientos: A partir de los requisitos
planteados por el cliente para el software, el equipo de trabajo elaborará los
requerimientos, los clasificará y los ponderará para empezar a trabajar
sobre ellos. Se evaluará también la metodología que implementa
PHYSILAB y lo que ésto impacta el proyecto, además éste se debe ajustar
al funcionamiento que el laboratorio remoto ha tenido planteado desde su
nacimiento y posterior desarrollo.
Delegación de Funciones: Se establecen las tareas y actividades para
desarrollar en cada una de las etapas de construcción y desarrollo y qué
actores estarán involucrados y qué función ejercerán. No sobra decir que el
actual proyecto es paralelo al desarrollo e implementación del hardware
(brazo robot), así que, aunque es un proyecto individual, se interactuará con
el ejercicio académico de otro compañero de carrera.
Estudio de Procesos: Se evaluarán los procesos establecidos por el
modelo de ciclo de vida y la metodología escogida y se planeará como
serán trabajados y enfocados por el equipo de trabajo. Se aterrizarán los
conceptos teóricos para crear tareas definidas y poder empezar a tener un
plan de ejecución bien definido.
Reingeniería de Procesos: Evaluar y rediseñar si es necesario los pasos
anteriores para que la planeación que se tiene para el desarrollo sea la
adecuada y se haya planificado de la mejor manera posible. Es importante
que aquí gran parte del análisis éste claro, ya que ésta será toda la teoría y
demás contexto conceptual que se tendrá como base para afrontar el
proyecto, dentro de todos los temas. Los dos ítems más relevantes que se
pueden visualizar, es el tema circuital del hardware y la metodología de
desarrollo para el software.
Creación de Modelos: La modelación permite plasmar el problema de una
manera más organizada y gráfica. Esto permite aumentar la productividad
3. Marco Teórico
41
del desarrollo y la calidad de la solución de software. Se modelarán los
requerimientos, los casos de uso principalmente y demás modelos que
permitan visualizar el problema de una manera clara y entendible, tanto
para el lado del software como para el tema circuital que se vea involucrado
en el desarrollo.
Socialización y Corrección de Modelos: Permiten que con el cliente se
puedan validar éstos modelos creados y desarrollados en el paso anterior.
Se harán las anotaciones necesarias y se llegarán a acuerdos con el cliente
sobre éste punto. En éste caso la UCP, tendrá una persona encargada de ir
avalando cada uno de éstos pasos para que al final ambas partes queden
satisfechas con el producto obtenido.
Últimos Modelos: Se plantean los modelos finales que muestran la visión
estática, funcional y dinámica del sistema. Con los aportes del cliente se
llega a ésta versión final del modelado. Estos modelos permitirán ver todos
los componentes del sistema, se describirá su funcionamiento y por último
como interactuarán entre sí.
Tecnología a Utilizar: Se definirá toda la plataforma tecnológica del
software, para que después de establecerla se pueda adquirir habilidad en
ésta. Acá en este punto se elegirá las herramientas de desarrollo que se
utilizarán, lenguajes de codificación, y demás plataformas que vayan a
sostener el proceso de desarrollo del software.
Arquitectura: Se terminarán de plantear los demás elementos de la
arquitectura del software. Acá se finaliza la etapa de Diseño y Planificación,
a ésta altura del proyecto la construcción del software debe estar planteada.
Esta arquitectura será el plano arquitectónico del software y permitirá que la
construcción sea un proceso productivo y que su resultado sea el esperado.
3.5.2 Producción y Pruebas:
Elaborado el análisis, y elaborado el diseño se empiezan las actividades de
implementación, codificación y pruebas.
Codificación: Se lleva a código fuente en el lenguaje de programación
elegido, en la herramienta elegida, todo lo diseñado en la fase anterior. Por
el momento se sabe que ésta etapa será una de las más laboriosas, por el
3. Marco Teórico
42
nivel de programación que se puede que llegar(un nivel muy bajo, casi de
maquina) por el tema circuital del hardware (Brazo robot)
Integración de Componentes: Conceptos como la reutilización, la
evolución dinámica o la composición tardía, fundamentales en esos
entornos, obligan a una clara separación entre los aspectos
computacionales e interoperacionales de los componentes. Es ésta fase se
delimitarán cada uno de éstos. Acá se tendrá la unión de todos los
procesos que se pudieron haber hecho por separado para tratarlos como un
conjunto.
Corrección de Componentes: Evaluación y correcciones de los
componentes a implementar en el sistema. En el paso anterior pueden
presentarse situaciones en que un componen no encaja de manera debida
o correcta con otro, así que deben ser modificados, unos en mayor
proporción que otros, para que sea exitosa su consolidación.
Consolidación de Partes del Proyecto: Proceso para unir cada una de las
piezas que compongan el software, y hacer un solo producto. De aquí sale
la primera versión del Software.
Pruebas: Se le aplicarán distintas pruebas al software para encontrar fallas,
errores y demás que se puedan optimizar. Es importante resaltar que
deberá ser probado también con el software a cual será incrustado, y así
hacer de éstas pruebas uno de los pasos finales para dejar en correcto
funcionamiento el software del brazo robot.
Corrección de Errores: Según los resultados obtenidos en la ejecución de
las pruebas se aplicarán las debidas correcciones al software para que
podamos tener una nueva versión. Al final de éste proceso se harán las
comprobaciones necesarias para demostrar que éstos cambios hechos en
el software fueron correctos y que el software ya no presente los errores
encontrados en las pruebas.
Implementación: Proceso en el cual se empieza la implementación en el
ámbito en que el brazo robot ya queda funcionando y se da finalización de
los detalles en su funcionamiento.
4 DESARROLLO E IMPLEMENTACIÓN DE LA INVESTIGACIÓN
En esta fase del proyecto se elabora todo el análisis, diseño, descripción,
desarrollo y pruebas del software. Estas actividades son realizadas según los
conceptos anteriormente descritos.
4.1 ANALISIS Y DISEÑO
Como punto de partida es necesario hacer una búsqueda y selección adecuada y
bien intencionada de la información relevante tendiente a la solución integrada del
problema, que desde luego involucra la consecución de la arquitectura en software
y hardware que da solución al problema.
4.1.1 Toma de requisitos:
La toma de requisitos se realiza a partir de entrevistas, charlas, y sesiones de
trabajo con los profesores James Andrés Barrera Moncada y Juan Carlos Henao
López, quienes están vinculados al desarrollo de PHYSILAB desde su inicio lo que
se vuelve un elemento importante para los desarrollos puesto que entienden toda
la complejidad del problema y la ruta de desarrollos que tiene este macroproyecto
de investigación multidisciplinar.
La toma de requisitos se documenta de manera sucinta pero sistémica, ya que el
objetivo de este primer acercamiento, es el de poder plantear los requerimientos
mínimos y estos si documentarlos de la manera más expedita y detallada.
4.1.2 Especificación de los requerimientos:
En base a los requisitos obtenidos se establecen los siguientes requerimientos:
Según los ángulos ingresados y las dimensiones del brazo el software debe
calcular la posición en la cual queda el punto final o extremo del brazo.
El brazo debe ejecutar los movimientos que le responden a los ángulos
ingresados.
4. Desarrollo e Implementación de la Investigación
44
El software recibe dos ángulos, por ende serán solamente dos ejes los que
se moverán.
El brazo debe tener una posición inicial.
El brazo alertara si el movimiento no fue exitoso.
El software no deberá validar si el usuario calculó bien el vector final.
A continuación, las tablas de la 4.1 a la 4.6, de formato propio diseñado, sintetizan
la captura y descripción de los requerimientos establecidos, donde se describe el
entorno, el responsable, el número, el tipo, y las restricciones de cada uno. Esto lo
que permite es poder entender de una manera detallada las funcionalidades del
software.
Tabla 4.1. Captura y descripción del requerimiento 001
Tabla 4.2. Captura y descripción del requerimiento 002
CAPTURA Y DESCRIPCIÓN DE REQUERIMIENTOS
Nombre del proyecto: DESARROLLO DEL SOFTWARE PARA BRAZO ROBOT
Entorno: Physilab
Analista Responsable: Jhon Smith Romero Solórzano
Requerimiento Nro. 001
Descripción del requerimiento: Según los ángulos ingresados y las dimensiones del brazo el software debe calcular la posición en la cual queda el software.
Tipo de requerimiento x Funcional No funcional
Restricciones del funcionamiento:
El sistema no realizará alguna acción hasta que se le envíen parámetros
CAPTURA Y DESCRIPCIÓN DE REQUERIMIENTOS
Nombre del proyecto: DESARROLLO DEL SOFTWARE PARA BRAZO ROBOT
Entorno: Physilab
Analista Responsable: Jhon Smith Romero Solórzano
Requerimiento Nro. 002
Descripción del requerimiento:
4. Desarrollo e Implementación de la Investigación
45
Tabla 4.3. Captura y descripción del requerimiento 003
Tabla 4.4. Captura y descripción del requerimiento 004
Tabla 4.5. Captura y descripción del requerimiento 005
El brazo debe ejecutar los movimientos que le responden a los ángulos ingresados.
Tipo de requerimiento x Funcional No funcional
Restricciones del funcionamiento:
El sistema deberá validar los datos ingresados.
CAPTURA Y DESCRIPCIÓN DE REQUERIMIENTOS
Nombre del proyecto: DESARROLLO DEL SOFTWARE PARA BRAZO ROBOT
Entorno: Physilab
Analista Responsable: Jhon Smith Romero Solórzano
Requerimiento Nro. 003
Descripción del requerimiento: El software recibirá dos ángulos, por ende serán solamente dos ejes los que se moverán.
Tipo de requerimiento x Funcional No funcional
Restricciones del funcionamiento:
El resto del brazo debe simular cada uno de los dos vectores.
CAPTURA Y DESCRIPCIÓN DE REQUERIMIENTOS
Nombre del proyecto: DESARROLLO DEL SOFTWARE PARA BRAZO ROBOT
Entorno: Physilab
Analista Responsable: Jhon Smith Romero Solórzano
Requerimiento Nro. 004
Descripción del requerimiento: El brazo debe tener una posición inicial.
Tipo de requerimiento x Funcional No funcional
Restricciones del funcionamiento:
La posición inicial debe estar dentro de las combinaciones de ángulos posibles.
CAPTURA Y DESCRIPCIÓN DE REQUERIMIENTOS
Nombre del proyecto: DESARROLLO DEL SOFTWARE PARA
Entorno: Physilab
4. Desarrollo e Implementación de la Investigación
46
Tabla 4.6. Captura y descripción del requerimiento 006
Los requerimientos, después de ser analizados de esta manera, se ponderan, con
el fin de entender la importancia de cada uno, y así poder trazar un plan de trabajo
dándole la prioridad a los que tengan una ponderación más alta (Ver Tabla 4.7).
La ponderación de los requerimientos se muestra en la tabla siguiente:
Tabla 4.7. Ponderación de los requerimientos
REQUERIMIENTOS PONDERACIÓN
(%) CLASIFICACIÓN
Según los ángulos ingresados y las
dimensiones del brazo el software debe
calcular la posición en la cual queda el
software.
10 Funcional
El brazo debe ejecutar los movimientos
que le responden a los ángulos
ingresados.
40 Funcional
BRAZO ROBOT
Analista Responsable: Jhon Smith Romero Solórzano
Requerimiento Nro. 005
Descripción del requerimiento: El brazo alertará si el movimiento o no fué exitoso.
Tipo de requerimiento x Funcional No funcional
Restricciones del funcionamiento:
No se dirá en pantalla el valor del vector final, el usuario debe calcularlo.
CAPTURA Y DESCRIPCIÓN DE REQUERIMIENTOS
Nombre del proyecto: DESARROLLO DEL SOFTWARE PARA BRAZO ROBOT
Entorno: Physilab
Analista Responsable: Jhon Smith Romero Solórzano
Requerimiento Nro. 006
Descripción del requerimiento: El software no deberá validar si el usuario calculó bien el vector final.
Tipo de requerimiento x Funcional No funcional
Restricciones del funcionamiento:
La posición se podrá ver por cámara IP
4. Desarrollo e Implementación de la Investigación
47
El software recibirá dos ángulos, por
ende serán solamente dos ejes los que
se moverán.
30 Funcional
El brazo debe tener una posición inicial. 5 Funcional
El brazo alertara si el movimiento o no
fué exitoso. 5 No Funcional
El software no podrá validar si el usuario
calculó bien el vector final. 10 Funcional
TOTAL 100
4.1.3 Estudio de procesos.
Con un panorama claro, que brinda la toma de requisitos y la especificación de
requerimientos se eligen el ciclo de vida y la metodología:
Modelo evolutivo: Este ciclo de vida permite que tras un panorama inicial se
pueda empezar a crear versiones iniciales las cuales tras verificaciones
constantes–del asesor en este caso– se pueda llegar la versión final más
elegante. Es un modelo dinámico y no rígido que se aplica de manera ideal
para el contexto del desarrollo y la naturaleza de sus participantes.
Scrum: Como metodología ya que puede trabajar de la mano con el modelo
de ciclo de vida evolutivo de manera eficaz y además por los tiempos de
desarrollo y la definición de roles que debe tener el proyecto.
Todo lo anterior, con el fin de tener una dinámica de trabajo rápida, dinámica y
eficaz, donde lo que se busca una iteración de procesos, en donde de una
información inicial, se haga un desarrollo e inmediatamente se valide con el asesor
y vuelva y se repita el ciclo, las veces necesarias, todo esto con cada una de las
funcionalidades del software.
4.1.4 Reingeniería de procesos.
Se evalúa el ciclo de vida, y la metodología de desarrollo, elegidos y se confirma
que dentro del abanico de opciones que se presentan, es el más adecuado para el
4. Desarrollo e Implementación de la Investigación
48
desarrollo. En este punto se tiene una visión clara de los objetivos y del plan de
trabajo a desarrollar con el fin de alcanzarlos.
Por otra parte es importante aclarar para los objetivos de la presente investigación
que la electrónica específica del brazo no es de alcance en este proyecto –de
hecho hizo parte de proyectos anteriores a este que desarrollo– aunque si fue
necesario hacer ajustes en las señales de control e instrumentación para
implementar integradamente el hardware y control local del brazo.
4.1.5 Creación, socialización, corrección y últimos modelos
Otro elemento que vale la pena aclarar es sobre el tiempo de desarrollo y la
naturaleza del proyecto; la creación, socialización, corrección y definición de los
últimos modelos se hicieron de manera dinámica, en donde los modelos iniciales
fueron documentados de manera informal. En cuanto a la socialización con el
asesor se hicieron en entrevistas y reuniones en donde fueron corregidos de
manera inmediata, llegando así rápidamente a los modelos últimos y finales. A
continuación se mostraran y describirán cada uno de los modelos desarrollados en
esta etapa.
Inicialmente, se elabora un modelo de casos de uso (Ver Figura 4.1), que es la
descripción escrita del comportamiento del sistema al afrontar una tarea. Esta
descripción se enfoca en el valor suministrado por el sistema a entidades externas
tales como usuarios humanos u otros sistemas
Se definen los actores y las actividades identificados en la dinámica que desarrolla
el software.
4. Desarrollo e Implementación de la Investigación
49
Figura 4.1. Caso de uso
Los dos actores a tener en cuenta, son el usuario final (Estudiante o Profesor) y el
software ya existente de PHYSILAB (Sistema), los cuales intervienen
decididamente en las actividades principales del software.
Es así como el usuario final será quien tenga las opciones de iniciar el sistema,
ingresar los ángulos deseados para cada vector, validar la respuesta según la
práctica y salir del sistema, y donde el sistema, tendrá la funcionalidad de verificar
las reservas, y hacer validación del movimiento de cada uno de los vectores.
Después del diagrama de casos de uno, se elabora un diagrama de actividades
(Ver Figura 4.2), que sirve para representar el comportamiento del sistema
haciendo hincapié en la secuencia de actividades que se llevan a cabo y las
condiciones que guardan o disparan esas actividades.
4. Desarrollo e Implementación de la Investigación
50
Figura 4.2. Diagrama de Actividades
Este diagrama muestra básicamente las actividades del software, representando
la realización de operaciones y las transiciones que realizará el usuario al usar el
software.
Es así como las actividades en secuencia en el software son, que el usuario inicie
el sistema, que el sistema lea los ángulos ingresados, después que el sistema
mueva el brazo robot según los ángulos, que se haga la validación según la guía
de laboratorio por el usuario, y este ciclo de se puede repetir n veces, y al final de
toda la dinámica, salir del sistema.
Por otra parte y por la naturaleza del software y la necesidad que resuelve, el
equipo concluye que no es necesario crear un modelo de datos, ya que el sistema
aunque va a manejar información, el almacenamiento de ésta no será parte de su
responsabilidad. Esa responsabilidad será del software al que se le va a embeber
el actual sistema.
En el aspecto de diseño de entradas, para los requerimientos del software, la
única vía que tiene el usuario para ingresar información es por medio del clic en la
interfaz gráfica para seleccionar una configuración dentro de una gran variedad de
posibilidades; ya que esto son solo órdenes para que el brazo robot se mueva, no
es necesario construir un diseño de entradas muy sofisticado, es suficiente con
describir cómo será ésta parte del software.
4. Desarrollo e Implementación de la Investigación
51
Y en cuanto al diseño de las salidas solamente se ejecutan por medio de avisos
en la pantalla; estos tienen la información sobre la rutina realizada y por esto no
existe por ello un modelo de salidas definido. En general la interfaz es el único
medio de entrada y salida de información del sistema. Debido a que éste es un
software que hace parte de un software remoto, no existe posibilidad alguna de
prestar el servicio sin suministro de energía eléctrica o también una caída en el
servicio de Internet.
Para éste sistema es fundamental que estos dos servicios estén disponibles, tanto
en el laboratorio como en el lado del cliente, o el usuario que vaya a usar el
laboratorio remoto.
4.1.6 Tecnología a utilizar.
La primera necesidad a futuro, es que este software sea embebido a otro, por esto
su construcción debe ser controlada y diseñada de la mejor manera, para que el
proceso sea natural y de fácil transición. Además se debe tener en cuenta las
características técnicas del software principal y adaptarse a ellas. Entre las
principales se tiene que es un software remoto, así que su acceso será por vía
WEB.
Es importante resaltar que se maneja el paradigma orientado a eventos, sin
embargo la gran diferencia de ésta dinámica con las demás tecnologías, es que
los eventos ocurren en el lado del servidor, a diferencia con los eventos de
JavaScript común que son del lado del cliente y ocurren en el navegador.
Como segundo ítem se debe reiterar que el software interactúa con un hardware y
gran parte de su funcionamiento depende de poder controlar de manera adecuada
y eficaz éste brazo robot. Esto requiere de herramientas que manejen
programación a bajo nivel ya que estas programan chips y demás elementos
electrónicos que operan con éste nivel de programación.
Con toda ésta información se concluye y establecen las siguientes herramientas y
políticas a utilizar:
Entorno de Programación a Utilizar: Visual Studio Lenguaje de programación a Utilizar: C# Plataforma Utilizada por PHYSILAB: Node.js
4. Desarrollo e Implementación de la Investigación
52
4.1.7 Arquitectura:
La arquitectura también incluye los elementos que van a ser las bases del
software, en el entorno tecnológico con los siguientes contextos:
Hardware: Se puede identificar dos factores hardware definidos. El primero
será el brazo robot a controlar por medio del software que se diseña con el
actual proyecto, este brazo robot es de la marca RobotBase y su referencia
es RB-13K012.
Figura 4.3. Estructura básica del el brazo robot RB-13K012
El segundo será donde será alojado éste software, y es un servidor
institucional en la Universidad Católica de Pereira. El software se ajustará a
la arquitectura física del cliente para que éste pueda ofrecer el servicio.
Software: El software se diseña para cubrir necesidades específicas del
laboratorio remoto PHYSILAB, por tanto estará rodeado de todo el entorno
y las interfaces definidas por PHYSILAB.
Comunicación: El software se comunica con el brazo robot y con el software
al cual será embebido. Como el software hará parte de un laboratorio
4. Desarrollo e Implementación de la Investigación
53
remoto los usuarios pueden interactuar con éste en tiempo real. Esta
aplicación requiere respuesta inmediata y así hacer efectivo su
funcionamiento.
4.2 PRODUCCIÓN Y PRUEBAS
En esta etapa se plasma y se construye el diseño anteriormente desarrolladlo. En
el proyecto es la etapa que más consume tiempo y la mayor parte del trabajo de
desarrollo del software.
4.2.1 Codificación:
Se realizan las tareas que comúnmente se conocen como programación; que
consiste, esencialmente en llevar a código fuente en el lenguaje de programación
elegido, todo lo diseñado en la fase anterior. Esta tarea se realiza siguiendo por
completo los lineamientos impuestos en el diseño.
Toda esta codificación se desarrolla en un entorno externo a Physilab, de manera
local en un computador personal, con el fin de hacer las validaciones que se
fueran necesitando en el proceso de manera local.
Como elemento adjunto a este proyecto se anexa el código desarrollado y en la
guía de implementación se muestra el código adicional desarrollado que se debe
añadir a los archivos ya existentes de PHYSILAB.
4.2.2 Integración y corrección de componentes:
Es importante tener clara la arquitectura en este punto ya que se tienen diferentes
partes, en diferentes plataformas y lenguajes.
Se tiene un software hecho en Arduino, grabado en la placa, que tras recibir unos
parámetros envía unas órdenes de movimiento a cada motor. También se tiene un
software, una aplicación de consola, hecha en lenguaje C#, que permite tomar dos
datos, que son los ángulos proporcionados de forma discrecional por el usuario y
enviar los parámetros que requiere el sistema hecho en Arduino. Sin embargo el
trabajo en este punto fue hacer la interacción de estos dos sistemas.
4. Desarrollo e Implementación de la Investigación
54
El elegir el IDE Visual Studio permite que la conexión y la comunicación de estos
dos componentes fuera de manera más simple, ya que trae un control
predeterminado para esta conexión.
4.2.3 Consolidación de partes del proyecto:
En este punto se muestra cómo se va a hacer la integración del software
desarrollado con el entorno de PHYSILAB.
La estructura de archivos de PHYSILAB, esa formada por la plataforma de
desarrollo utilizada Node.js, en donde el archivo app.js, es el archivo principal.
El archivo app.js tiene toda la programación de todos los servicios que tiene
Physilab. Es el archivo que crea el servidor y declara cada uno de los procesos
posibles en él.
Este archivo se edita, agregándole unas líneas de código que integran y vinculan
el desarrollo a la gran plataforma ya existente.
Adicionalmente se agrega a la carpeta raíz el software, cuyo archivo es nombrado
“Brazo.exe”.Este archivo es ejecutado por el servidor y recibe como parámetros
los ángulos ingresados por el usuario, y con esto envía una serie de caracteres
que son leídos por el Arduino y así mover el brazo robot como corresponde.
Y por último como requerimiento de la integración final se agrega a la carpeta
“cámaras” el archivo cámara 4, que permite visualizar la cara asignada para este
dispositivo.
Toda esta integración se elabora de forma muy natural y las dificultades
presentadas de comunicación, lenguaje y demás son comunes a los contextos
cotidianos de las configuraciones y que se fueron solucionadas de manera
inmediata; ya que no son cambios significativos no se hace necesario documentar
estas correcciones.
4.2.4 Pruebas y corrección de errores:
Las pruebas son el instrumento adecuado para determinar el status de la calidad
del software para el brazo robot. En este proceso se ejecutan pruebas dirigidas a
4. Desarrollo e Implementación de la Investigación
55
componentes del software y al sistema de software en su totalidad, con el objetivo
de medir el grado en que el software cumple con los requerimientos.
En este caso utilizaremos solo un tipo de pruebas; las unitarias, que se
implementan a una sola unidad del Sistema o una sola funcionalidad. Es
importante resaltar que los dos enfoques de pruebas que se eligen, se ejecutan en
el nivel de desarrollo, ésto por la naturaleza del entorno y del software, buscando
efectividad y agilidad a la misma vez en la implementación.
Y de estas pruebas unitarias utilizaremos dos enfoques:
Caja Blanca.
Caja Negra.
El nivel, determina la etapa del ciclo de vida donde se desarrollan las pruebas. En
este caso es en desarrollo, puesto que se van aplicando pruebas y sus respectivas
correcciones de los errores encontrados.
El objetivo de estas pruebas es verificar la funcionalidad del brazo, que a partir de
los dos ángulos ingresados por el usuario se ejecute el movimiento
correspondiente.
Estas pruebas se hacen con la intención de probar principalmente la funcionalidad
del brazo en los contextos mencionados anteriormente. Como se indica los dos
primeros tipos de pruebas se realizan paralelamente a la etapa de construcción, y
después de que la etapa de construcción finalice, se realizan las restantes;
posteriormente con la información recogida, se hacen las correcciones obteniendo
el prototipo final.
Requerimientos para las Pruebas: Los recursos a utilizar son los siguientes
Computador
IDE Visual Studio instalado.
Brazo Robot previamente configurado (Hardware)
4. Desarrollo e Implementación de la Investigación
56
Se configuraron 5 escenarios de prueba, los cuales son diferentes, y donde se
tiene claro el objetivo de la prueba, la descripción del escenario donde fue
aplicada, el resultado esperado y el resultado obtenido. A continuación la
documentación. Las tablas de la 4.1 a la 4.5 sintetizan la información de las
pruebas descritas anteriormente. Las pruebas de caja blanca fueron las pruebas
001, 002 y 003.
Tabla 4.8. Prueba PU–001
NombredelaPrueba:PU-001
Objetivo: Se envía la cadena de valores al programa Arduino con el fin de verificar el movimiento de cada uno de los motores del brazo.
Descripción del escenario: El brazo robot está debidamente conectado a la tarjeta Arduino, la cual también está conectada al computador, desde donde se le envía la cadena de valores.
Resultado Esperado:
El brazo debe mover cada uno de los motores según el número enviado para cada uno en la cadena.
Resultado Obtenido:
El brazo se mueve sin embargo se observa que cada uno de los motores tiene unos rangos de movimientos diferentes.
Tabla 4.9. Prueba PU–002
Nombre de la Prueba: PU-002
Objetivo: El software debe calcular la posición final del brazo, con los ángulos ingresados por el usuario.
Descripción del escenario: El brazo robot está debidamente conectado a la tarjeta Arduino, la cual también está conectado al computador, se ingresan los dos ángulos en grados.
Resultado Esperado:
El brazo debe calcular la posición final en el eje x y en el eje y.
Resultado Obtenido:
No se obtuvo la posición correcta en ninguno de los dos ejes, los cuales se evaluaron de nuevo y se encontró que las operaciones deben hacerse con los ángulos en radianes y no se había hecho ésta conversión. Se realizó el ajuste necesario y se solucionó el error.
4. Desarrollo e Implementación de la Investigación
57
Tabla 4.10. Prueba PU–003
Nombre de la Prueba: PU-003
Objetivo: El software debe ser intuitivo y fácil de entender y manejar.
Descripción del escenario: El brazo robot está debidamente conectado a la tarjeta Arduino, la cual también está conectado al computador, se ingresan los dos ángulos en grados.
Resultado Esperado:
El usuario debe entender rápidamente el método de uso del software
Resultado Obtenido:
En el primer intento el usuario reconoció cuales son los puntos de movimiento del brazo, en el segundo reconocía cual ángulo correspondía a cual motor y en el tercer intento la dinámica le fué totalmente clara.
Las pruebas de caja negra fueron las 004 y la 005:
Tabla 4.11. Prueba PU–004
Nombre de la Prueba: PU-004
Objetivo: Se probará que desde el uso de la interfaz las órdenes lleguen hasta el brazo y éste las ejecute correctamente.
Descripción del escenario: El brazo robot está debidamente conectado a la tarjeta Arduino, la cual también está conectado al computador, el software construido se está ejecutando en el Pc.
Resultado Esperado:
El software debe interactuar perfectamente con el brazo, que las ordenes ingresadas por el software sean las mismas ejecutadas.
Resultado Obtenido:
El software funciona de manera ideal con el brazo robot, haciendo que éste se mueva según lo ingresado por el usuario.
Tabla 4.12. Prueba PU–005
Nombre de la Prueba: PU-005
Objetivo: Se prueba la conexión local de la cámara IP integrada al software.
Descripción del escenario: El brazo robot está debidamente conectado a la tarjeta Arduino, la cual también está conectado al computador, el software construido se está ejecutando en el Pc y en la red
4. Desarrollo e Implementación de la Investigación
58
local está una cámara Ip.
Resultado Esperado:
El software debe mostrar lo que la cámara ve en tiempo real, la cámara debe enfocar el brazo robot.
Resultado Obtenido:
Localmente la cámara web funciona y se visualiza correctamente el brazo en tiempo real.
Como resultados obtenidos se puede ver que el software funciona como se
espera, en los diferentes escenarios.
Es importante resaltar que estos resultados finales fueron obtenidos después de
varia iteraciones en el ciclo de vida, muchos de los errores en la etapa de
desarrollo se fueron corrigiendo en ese mismo instante y momento del proyecto.
Lo que esto género es que hubieran una cantidad de pruebas que aunque no
formales, fueron detectando errores y fallos del sistema que se corrigieron y así la
versión final fue establecida
4.2.5 Implementación
La implementación se realiza en un servidor de PHYSILAB, ya que todos los
procesos de producción anteriores se habían hecho de manera local en un
computador externo al laboratorio.
Como parámetros básicos ajenos a los establecidos por Physilab, están:
Arduino (V. 1.0.5)
Framework .Net (V. 4.0)
Es importante aclarar que esta implantación ha permitido establecer y clarificar el
proceso de instalación y adecuación para que el software fuera funcional en
cualquier servidor.
Por otra parte, las siguientes figuras ilustran el montaje físico desarrollado para la
implementación final del brazo robótico para PHYSILAB.
4. Desarrollo e Implementación de la Investigación
59
Figura 4.4. Montaje físico del brazo robótico
El brazo robot esta paralelo a la grilla de visualización, esto con el fin de poder ver
la medición de sus movimientos.
4. Desarrollo e Implementación de la Investigación
60
Figura 4.5. Montaje físico del brazo robótico
El brazo frontalmente será enfocado por la cámara, y en el fondo la grilla hará
medible para el usuario los movimientos realizados.
Figura 4.6. Montaje físico del brazo robótico
4. Desarrollo e Implementación de la Investigación
61
El brazo está conectado a una protoboard. Dicha protoboard fuera de que es
alimentada por su conector también está conectada a un arduino, que finalmente
está conectado al servidor.
5 CONCLUSIONES Y RECOMENDACIONES
Con el desarrollo efectivo de la investigación, se tienen las siguientes conclusiones
y recomendaciones.
5.1 CONCLUSIONES
Después de desarrollar e implementar todo el sistema de brazo robótico se llegan
a las siguientes conclusiones:
Estos tipos de desarrollo deben estructurarse con bases tecnológicas
flexibles con el fin de permitir futuras mejoras o actualizaciones tanto de
software como de hardware.
Las ventajas tecnológicas encontradas y que sirven como punto de
referencia para otras aplicaciones de naturaleza similar, es que la madurez
del software y del hardware permite que el enlace con otras aplicaciones
sean exitosos; en éste contexto la madurez del software de control para el
brazo robótico simplifica enormemente su articulación con la plataforma de
PHYSILAB.
La comprensión integral del fenómeno físico que se pretende ya sea
simular o instrumental de forma remota, demanda del concurso de diversas
competencias como la comunicativa y de autogestión en adición a la
articulación de conocimientos tanto técnicos como tecnológicos.
Se hace necesario como parte de Physilab, que las actividades de
desarrollo incluyan actividades para intercambiar conceptos conjuntamente
con cada uno de los profesores, alumnos y demás involucrados en el
proyecto y así poder entender el contexto del laboratorio remoto y virtual.
En el proceso de identificación de los requerimientos para el software es
necesario que desde el inicio se tengan claras las funcionalidades que
debe tener la aplicación, los escenarios y como debe responder A cada
una de las necesidades.
La arquitectura del sistema debe tener en cuenta los parámetros que
establece el entorno, es decir, lo ya desarrollado en Physilab, además de
todos los demás elementos que podían influir, adicionalmente, aplicando la
5. Conclusiones y Recomendaciones
63
metodología más apropiada y el ciclo de vida ideal para este tipo de
desarrollo.
Los prototipos funcionales de desarrollos tecnológicos similares a los
presentados en ésta investigación, necesitan de una cuidadosa
implementación sistémica de pruebas, las cuales puedan arrojar datos e
información específica relevante de interés, ésto con el fin de poder hacer
los ajustes tendientes al mejoramiento integral del sistema. En el caso del
brazo robótico éstas pruebas se desarrollaron en dos líneas mutuamente
dependientes, la línea del hardware y la línea del software y la interacción
funcional de éstas dos, que finalmente son los pilares fundamentales en la
consecución de los objetivos.
5.2 RECOMENDACIONES
Con base en éstas conclusiones se tienen las siguientes recomendaciones para
ésta investigación e investigaciones similares:
El servidor, donde debe ejecutarse el programa, debe tener unos
programas y software preinstalado ya nombrado en el proyecto con el fin
que el sistema pueda funcionar.
Aunque no se establecieron las especificaciones técnicas mínimas
requeridas entre mayor capacidad tenga el servidor, así mismo podrá
ofrecer el servicio ininterrumpidamente y con fluidez, proporcionándole al
usuario la sensación de proximidad con los instrumentos. De igual manera
las mejoras y actualizaciones tanto de software como de hardware deben
estar acordes con las especificaciones de todo el sistema.
Las características del software desarrollado para la aplicación integral
tienen la intencionalidad de ser flexible, considerando las posibles
actualizaciones o mejoras que se hagan a futuro, tal como otros grados de
libertad o la articulación con otros sistemas dentro de Physilab. En todo
caso se debe garantizar la estabilidad, seguridad y confiabilidad en toda la
arquitectura tanto en hardware como en software.
Aunque la aplicación cumple con los objetivos tanto de la investigación
como los requerimientos de PHYSILAB, existe un error en las medidas
consecuencia del paralelaje que introduce el observador. Una mejora al
5. Conclusiones y Recomendaciones
64
sistema es indudablemente que la posición de la cámara se pueda ajustar a
la posición final del brazo.
6 BIBLIOGRAFÍA
Arduino. (6 de Abril de 2013). Arduino. Recuperado el 6 de Abril de 2013, de
Arduino: http://arduino.cc/es/Guide/Introduction
Campderrich Falgueras, B. (2003). Barcelona: Editorial UOC.
Laboratorio Nacional de Calidad del Software. (2009). INGENIERÍA DEL
SOFTWARE: METODOLOGÍAS Y CICLOS DE VIDA.Madrid: Gobierno de
España.
Lawrence J. Peters2010Getting Results From Software Developments
TeamsOttawaMicrosoft
Mórales, R. C. (2006). Introduccion al Análisis de Sistemas y la Ingeniería de
Software. San Jose, Costa Riica: Editorial Universidad Estatal a Distancia.
Palacio, J. (04 de Abril de 2006). Compendio de Ingenieria del Software.
Recuperado el 21 de Febrero de 2014, de www.navegopolis.net:
https://www.coloriuris.net/contracts/672479d95c3ff9c407dfe8b0db9334b3
ParqueSoft. (23 de Abril de 2011). Recuperado el 29 de Abril de 2013, de
ParqueSoft: http://parquesoftpereira.com/38-parquesoft-es.html
ProExport Colombia. (2012 de Julio de 18). Recuperado el 2013 de Abril de 29, de
ProExport Colombia:
http://www.proexport.com.co/multimedia/video/multinacional-indra-instalara-
en-pereira-su-segundo-laboratorio-de-software-en-colombia
Sommerville, I. (2005). Ingenieria Del Software. Madrid, España: Pearson
Educación S.A.
Weitznefeld, A. Ingenieria de Software Orientada a Objetoscon UML, Java e
Internet. Thomson.
7 ANEXOS
7.1 INSTALACIÓN Y CAMBIOS EN EL ENSAMBLE CON PHYSILAB
Se toma como base el mismo sistema que maneja Physilab, hecho en node.js, así
es como inicialmente se modifica el archivo app.js ingresando en la línea
número379, el siguiente código:
app.get('/brazo', function(req, res) { res.render('brazo.jade', {locals: {title:'Physilab',user:'lola'} } ); }); app.get('/mover_brazo/:codigo', function(req, res) { console.log("Mover brazo"); var cadena=eval('(' + req.params.codigo + ')'); var sys = require('util'); var exec = require('child_process').exec var comando="Brazo.exe "+cadena.datos[0].a1+" "+cadena.datos[0].a2 console.log(comando); child = exec(comando, function(error, stdout, stderr) { res.writeHead(200, { "Content-Type": "application/json", "Access-Control-Allow-Origin":"*" }); res.write(JSON.stringify(stdout)); res.end("\n"); }); });
Esto código lo que permite es que tras una orden dada en el cliente, el servidor
lanza un proceso ejecutando el archivo Brazo.exe el cual recibe dos parámetros
siendo estos los dos ángulos ejecutando la orden de movimiento al Arduino para
que finalmente el brazo robot se gire como lo indico el cliente.
Es importante que el servidor tenga el software de Arduino. Al tener el software de
Arduino, cada computador le asigna aleatoriamente un puerto COM al Arduino que
se conecte vía USB; el servidor donde se hicieron las pruebas designa por defecto
7. Anexos
67
el puerto COM3 a la tarjeta Arduino Mega empleada. Para poder configurar otro
puerto se debe hacer el cambio en el software de Arduino o en el código fuente del
archivo Brazo.exe en la línea de código que es:
using (SerialPortsp = newSerialPort("COM" + 3, 9600))
Se puede cambiar el número 3 por el número del puerto COM que se requiera.
Después se debe hacer la compilación del archivo.exe, teniendo en cuenta que la
versión del Framework para la que se compila sea compatible con la que tiene el
servidor. En este caso, se hizo para Framework 4.0:
Figura 7.1. Configuración del Framework.
Si se requiere otra versión de Framework, simplemente se modifica esto en las
propiedades del proyecto. Recuerde que el IDE es el Visual Studio. Por otra parte
como resultado de este cambio, el archivo Brazo.exe se añadió a la carpeta
prueba.
Por ultimo para poder asignar otra cámara, se añadió el archivo camara4.html, en
la carpeta \public\camaras.
7. Anexos
68
7.2 CÓDIGO FUENTE BRAZO
namespaceBrazo { class Program { static void Main(string[] args) { //Application.EnableVisualStyles(); //Application.SetCompatibleTextRenderingDefault(false); int a1 = Int32.Parse(args[0]); int a2 = Int32.Parse(args[1]); Console.WriteLine(a1); Console.WriteLine(a2); string s = generarCadenaRutinaManual(a1, a2); Console.WriteLine(s); using (SerialPortsp = new SerialPort("COM" + 9, 9600)) { sp.Open(); sp.Write(s); sp.Close(); } } public static String generarCadenaRutinaManual(int a1,int a2) { String s; int an2=0; if (a2 == 0) { an2 = 90; } if (a2 == 10) { an2 = 80; } if (a2 == 20) { an2 = 70; } if (a2 == 30)
7. Anexos
69
{ an2 = 60; } if (a2 == 40) { an2 = 50; } if (a2 == 50) { an2 = 40; } if (a2 == 60) { an2 = 30; } if (a2 == 70) { an2 = 20; } if (a2 == 80) { an2 = 10; } if (a2 == 90) { an2 = 0; } Console.WriteLine(a1); Console.WriteLine(a2); Console.WriteLine(an2); s = llenarConCeros("120", 3) + "01000"; s += llenarConCeros("50", 3) + "01000"; s += llenarConCeros((a1 + 24).ToString(), 3) + "01000"; s += llenarConCeros((an2 + 90).ToString(), 3) + "01000"; s += llenarConCeros("0", 3) + "01000"; s += llenarConCeros("180", 3) + "01000"; return s; } public static String llenarConCeros(string n, int size) { if (size == 3) { if (n.Length == 1) { n = "00" + n;
7. Anexos
70
} else if (n.Length == 2) { n = "0" + n; } } return n; } } }
7.3 PRÁCTICA DE LABORATORIO
En esta sección se ilustra una propuesta de guía de laboratorio de física para la
práctica de suma de vectores en el plano. Es importante recalcar que se precisa
de una práctica virtual –la cual no es objetivo de la presente investigación–, que
acompañe la práctica remota
7. Anexos
71
1.1. Laboratorio de Vectores A continuación se proponen una serie de prácticas de laboratorio tanto virtuales como remotas que buscan la reconstrucción de saberes relacionados con la comprensión del conocimiento científico en física, la solución de problemas contextualizados y el método científico como herramienta para la investigación. Recuerde programar su agenda para no congestionar la plataforma y teniendo en cuenta el cronograma de actividades del plan de asignatura, hacer las reservas de los equipos para las prácticas remotas con suficiente tiempo.
Fase Preparatoria Lea con cuidado el siguiente contenido, en él recordará algunos conceptos y categorías importantes tratadas en el libro y en clase
Recordemos
Los vectores son una de las herramientas que tiene el análisis numérico, para representar diversos fenómenos, entre ellos los fenómenos físicos; estos vectores tienen características propias y muy específicas que facilitan su aplicación a diversos contextos.
¿Y TU QUE PIENSAS?
¿Por qué crees que es importante modelar algunos fenómenos físicos a través de los vectores?, ¿Qué otras formas conoces para alcanzar esta modelación?
Existen muchas formas en las cuales los vectores representan cantidades física y cantidades no físicas, sin embargo en esta sección se centran los esfuerzos para comprender las implicaciones de la representación de los vectores en forma ordenada y en forma gráfica, igualmente se muestran las operaciones básicas que se pueden desarrollar con ellos; operaciones como la suma, la resta, la multiplicación por escalar tanto de forma analítica como de forma gráfica. En este sentido es importante recodar algunos conceptos básicos de estas propiedades.
¿Y TU QUE PIENSAS?
En el contexto de física, Qué situaciones específicas son susceptibles de aplicarse la teoría del análisis
Figura 1. Representación
cartesiana de un vector
7. Anexos
72
vectorial?, qué elementos conceptuales comparten para que sean objeto de análisis vectorial?, qué situaciones en la física no se les puede aplicar los principios analíticos de los vectores?, en la explicación, justifique muy bien sus respuestas anexando ejemplos que considere convenientes.
Ahora, para representar un vector –se usa exclusivamente las representaciones en el plano para los objetivos de este laboratorio– es frecuente utilizar la notación cartesiana, donde cada elemento es asociado a una coordenada en x –ordenadas– y otra en y –abscisas–. Tal como se muestra en la figura 1.
�⃗⃗⃗� = (𝑎𝑥 , 𝑎𝑦)
Asociados con los vectores, existen cuatro características importantes a saber; el primero es la magnitud, el segundo es la dirección, el tercero es el sentido y el último es el punto de aplicación. A continuación se define conceptualmente y se colocan algunas expresiones algebraicas que se asocian a la figura 1.
Magnitud: Es la longitud o dimensión del vector, también conocida como Norma corresponde el tamaño del vector.
|�⃗⃗⃗�| = √𝑎𝑥2 + 𝑎𝑦
2
Dirección: Es el ángulo o conjunto de ellos, que forma el vector con respecto a algún eje de referencia.
𝜃 = atan (𝑎𝑦
𝑎𝑥)
Sentido: Indica la posición y ubicación en el espacio bidimensional o tridimensional, estableciendo si el vector sube, baja, tiende hacia un lado o a otro. Punto de aplicación: Es el lugar geométrico desde donde actúa el vector.
Es posible también definir un vector en términos de su magnitud y su dirección; a esta forma se le conoce como forma polar y es ampliamente utilizada en las matemáticas y en la física
�⃗� = (𝑎𝑥 , 𝑎𝑦) = |�⃗�|⟨𝜃
Y las expresiones matemáticas para pasar de coordenadas polares a coordenadas cartesianas son las siguientes
7. Anexos
73
𝑎𝑥 = |�⃗�| ∙ cos 𝜃
𝑎𝑦 = |�⃗�| ∙ sen 𝜃
Figura 2. Descomposición analítica de vectores.
Como se menciona, los vectores como cantidad matemáticas son susceptibles de aplicar algunas operaciones como la suma, la resta, la multiplicación entre otras; a continuación se exponen los elementos analíticos y geométricos más relevantes de la suma y resta de vectores que hacen parte de los objetivos de este laboratorio: La suma de dos o más vectores, dados en términos de coordenadas cartesianas, es una operación de componente a componente; en este sentido supóngase que se tiene dos vectores en el plano,
�⃗⃗⃗� = (𝑎𝑥 , 𝑎𝑦) y �⃗⃗⃗� = (𝑏𝑥, 𝑏𝑦), la suma analítica está dada por la operación componente a
componente en el mismo plano
�⃗⃗⃗� + �⃗⃗⃗� = (𝑎𝑥 + 𝑏𝑥, 𝑎𝑦 + 𝑏𝑦)
Para los términos geométricos, supóngase que se tiene dos vectores en el plano, tal como se muestra en la figura 3.a; el método del paralelogramo consiste en desplazar de forma paralela –sin cambiar la inclianción– uno de los dos hasta la cabeza del otro.
a. b.
c. Figura 3. Suma gráfica de dos vectores.
7. Anexos
74
En este método NO importa el vector que se traslade, es indiferente la decisión que se tome mientras que se conserve el hecho de que el vector que se traslade, se haga con la misma inclinación, es decir, sin cambiar la dirección. El vector suma será la unión del origen cartesiano con la cabeza del vector trasladado –este método también es conocido como el método de cabeza con cola– tal como se muestra en la figura.
Figura 4. Vector suma de dos vectores en el plano
Nótese que el vector suma es absolutamente independiente del orden de la suma de los vectores, en otras palabras, es independientes del vector que se traslade primero. Para la resta analítica de vectores, pasa algo semejante y que viene dada por la expresión
�⃗⃗⃗� − �⃗⃗⃗� = (𝑎𝑥 − 𝑏𝑥, 𝑎𝑦 − 𝑏𝑦)
En el caso de la resta, es importante recordar que no se cumple la propiedad conmutativa, es decir si importa el orden de la resta; quien es el minuendo y quien en sustraendo; por otro lado, para la resta analítica de vectores, se usa una propiedad denominada propiedad triangular.
Figura 5. Resta de dos vectores
En este método, la propiedad indica que el vector resultante se obtiene de unir los vectores componentes, partiendo del vector sustraendo –vector que resta– y llegando al vector minuendo –vector que es restado–.
7. Anexos
75
¿Y TU QUE PIENSAS?
Para el caso de la suma, si se tuvieran tres vectores, ¿cómo quedaría la expresión algebraica que representa la suma analítica?, por otro lado, si se quisiera restar tres vectores, ¿qué consideraciones se deberían tener para ello?
Actividades
Elabore un pequeño informe sobre los siguientes conceptos matemáticos y físicos, compartiendo sus desarrollos en un foro o una Wiki. Puede trabajar con sus compañeros de curso o si lo prefiere, previa autorización del docente, formar un equipo de trabajo con compañeros de otras universidades. Los conceptos y categorías a desarrollar son: 1. Vectores unitarios. 2. Producto escalar simple de dos vectores 3. Producto punto de dos vectores 4. Producto cruz de dos vectores. 5. Expresiones para la magnitud y dirección del vector suma, de dos vectores ubicados siempre
en el primer cuadrante.
Fase Experimental A continuación usted va a realizar una práctica remota con el fin de poner en acción la construcción conceptual y categorial de sus saberes. Esto también le permitirá afianzar lo comprendido, incrementando su capacidad para dar respuesta a situaciones cada vez más complejas dentro del pensamiento científico en física.
Objetivos
Con el presente conjunto de prácticas de laboratorio, se busca que el alumno adquiera los siguientes desempeños de competencia: Explica las propiedades básicas de los vectores como son la magnitud, la dirección, el
sentido y el punto de aplicación. Describe de forma gráfica y analítica operaciones vectoriales simples como la suma, la
resta y la multiplicación por un escalar. Interactúa con sistemas análogos para representar en contextos reales, operaciones
básicas con cantidades vectoriales.
Práctica de Laboratorio Remoto
7. Anexos
76
En esta parte, usted va a interactuar un brazo robótico de seis grados de libertad, pero que se ha configurado de tal forma que con dos segmentos, se simula todo un mecanismo para la suma de dos vectores en el plano. El sistema cuenta igualmente con una cámara WEB la cual permite visualizar en tiempo casi real, la configuración y posición del brazo, elemento fundamental para poder desarrollar con éxito la práctica de laboratorio. Antes de iniciar la práctica, asegúrese de desarrollar todo el protocolo de reserva de equipos, espacios y tiempos; esto lo puede hacer en el menú principal como lo muestra la figura.
Figura 6. Pantalla principal del sitio WEB de PHYSILAB
Para iniciar entre al sistema e interactuar con el mecanismo, teclee su nombre de usuario y contraseña proporcionado por el administrador del recurso –para aprender cómo hacer reservas remítase al mismo portal y allí encontrará un video tutorial que le muestra de forma animada este protocolo– y en caso de tener problemas, por favor comunicarse con el administrador.
Figura 7. Pantalla de la página WEB para el ingreso a la plataforma de los laboratorios remotos.
7. Anexos
77
Una vez realizado el proceso de “Login” presione de clic en la etiqueta Laboratorios para ingresar y finalmente a los laboratorios de la UCP, si la reserva está previamente hecha, el sistema le permitirá acceder al entorno de control del laboratorio, en el cual podrá a través de una cámara, visualizar y controlar el brazo robótico mostrado en la figura 8.
Figura 8. Brazo robótico RB-13K012 para la práctica de vectores.
En la Universidad Católica de Pereira existe un montaje que usa el brazo robótico de la figura 8, el cual tiene varios grados de libertad –seis grados de libertad para ser exactos–, sin embargo para los fines de la práctica de laboratorio de vectores, se restringe estos movimientos a dos grados de libertad que son registrados con una cámara WEB posicionada frente al robot, de forma similar a como se muestra en la figura 9.a. Las dos articulaciones superiores simulan dos vectores de magnitud constante –la longitud es constante para cada uno de los vectores–, pero a los cuales se les puede cambiar la inclinación o dirección, tal como se muestra en la figura 9.b;
(a) (b)
7. Anexos
78
Figura 9. Representación esquemática de los vectores en el plano. (a). Ubicación de la cámara WEB con respecto al brazo. (b). Posición de los vectores componentes de la suma.
La naturaleza del brazo robótico obliga a representar de hecho la traslación final de uno de los vectores –vector B– sobre el otro vector –vector A–, para realizar la suma vectorial de estas cantidades, aunque es frecuente en el práctica que ambos vectores estén en el origen coordenado para que a partir de este punto, se realicen todas las operaciones algebraicas. El control del brazo robótico se hace por medio de la manipulación de los dos ángulos de los brazos que se representan en la figura 10. El ángulo 𝜃1 se mide desde la horizontal y el ángulo 𝜃2 se mide con respecta a lo inclinación del vector A; para ambos ángulos el sentido positivo corresponderá con la dirección dextrógira, es decir, contrarias al sentido de giro de las manecillas de un reloj.
Figura 10. Ángulos que se pueden modificar en la práctica de laboratorio remoto.
Y se hacen a través de la interfaz que se muestra en la figura 9, aquí usted –el usuario– puede cambiar los ángulos en un cierto rango de posibilidades –esto con el fin de no someter el brazo a posiciones extremas que puedan afectar su normal funcionamiento–.
7. Anexos
79
Figura 11. Pantalla de control de los ángulos de inclinación del brazo robótico
El ángulo 1 –𝜃1– y el ángulo 2 –𝜃2– pueden subir o bajar dependiendo de las necesidades propias de la práctica y de los intereses del usuario. A parte de poder ingresar estos datos, el sistema le proporciona de forma analítica la posición final del vector A –punto Q– y del vector B –punto final– tal como se muestra en la figura 12.
Figura 12. Resultados entregados por el sistema
Estos valores, sirven para corroborar las operaciones de suma de estos dos vectores, los cuales usted puede cambiar su dirección o inlinación.
Test de Diagnóstico del Sistema. Antes de desarrollar una experiencia realice este test de diagnóstico con el fin de comprobar que el sistema funciona correctamente y que se tiene control sobre los diferentes elementos y dispositivos con que cuenta el laboratorio.
Protocolo 1. Cámara. Revise que tenga una buena calidad de video, asegúrese que tiene una buena visual del brazo robótico.
7. Anexos
80
Protocolo 2. Movimiento del brazo: interactúe con la aplicación y mueve el brazo en cualquier dirección y con cualquier ángulo.
Protocolo 3. Simulador. Cerciorase que el sistema le proporcione datos
consistentes, es decir valores angulares agudos y que el brazo quede en una posición más o menos coherente con la región del espacio donde debe aparecer.
.
Si uno de estos protocolos no se cumple, usted no puede realizar la práctica de laboratorio y debe comunicarse con el administrador del sistema a través del correo que se encuentra en la plataforma en la etiqueta “Contacto”. Después de corroborar que el sistema funciona como se espera, usted ya puede desarrollar la serie de pruebas para comprobar la suma analítica y geométrica de los vectores. A continuación desarrolle cada una de las siguientes prácticas de forma cuidadosa;
Practica Remota 1. Cálculo del vector suma
Figura 13. Configuración para el brazo robótico.
Nota importante: El brazo A (vector A) mide 9 cm y el brazo B (vector B) mide 15 cm
1.1. Complete la siguiente tabla de valores para diferentes posiciones de inclinación de los
brazos y en cada posición a través de la cámara verifique la coordenada del punto final de los dos vectores.
7. Anexos
81
Tabla 1. Coordenadas del vector suma, capturadas por la cámara WEB
𝜽𝟏 𝜽𝟐 Posición x Posición y
1.2. Sabiendo los ángulos y por medio de herramientas de análisis numérico y vectorial,
encuentre el valor teórico de posición para el vector final o vector suma. Consigne estos valores en la tabla 2 y compárelos con los valores propocionados por el programa.
Tabla 2. Coordenadas del vector suma, obtenidas a través de métodos analíticos
𝜽𝟏 𝜽𝟐 Posición x Posición y
1.3. Para cada valor, encuentre el error de cada medida, expresándola en valor.
Tabla 3. Error de las medidas.
𝜽𝟏 𝜽𝟐 Error en x Error en y
Practica Remota 2. Determinación de la posición del brazo. En esta práctica, usted va a encontrar diversas situaciones para dos vectores que se muestran en la figura.
7. Anexos
82
2.1. Dado el conjunto de valores para 𝜃𝐴 y 𝜃𝐵 medidos desde la horizontal y que se encuentran en la tabla, encuentre la configuración correcta para los ángulos 𝜃1 y 𝜃2 en el sistema de brazo robótico.
Caso 𝜽𝑨 𝜽𝑩 𝜽𝟏 𝜽𝟐
Caso 1 0° 0°
Caso 2 20° 45°
Caso 3 30° 40°
Caso 4 40° 30°
Caso 5 50° 20°
2.2. Encuentre el vector suma en cada uno de los casos anteriores y corrobore el resultado
obtenido con el proporcionado por el laboratorio remoto, al introducir los ángulos 𝜃1 y 𝜃2 consignando estos valores
Valor Teórico Valor del Robot
x y x Y
Caso 1
Caso 2
Caso 3
Caso 4
Caso 5
2.3. Saque sus propias conclusiones
Preguntas y Cuestiones
7. Anexos
83
1. Qué puede concluir acerca de la propiedad conmutativa –el orden de los factores– para la
operación suma de cantidades vectoriales. 2. Qué dificultades asocia a los errores encontrados en las mediciones hechas a través del
aplicativo y los resultados encontrados de forma analítica. 3. Establezca algunos criterios –formas– para poder realizar la suma de dos o más vectores en
el plano cartesiano.
