Systems Engineering Project Documentation PDF

Documentación de avances Robocol 2020-10
Autor:
Profesores Asesores:
Carlos Francisco Rodríguez - Departamento de Ingeniería Mecánica
Fredy Enrique Segura - Departamento de Ingeniería Electrónica
23 de junio de 2020
MISIÓN
Robocol es una iniciativa estudiantil, de la Universidad de los Andes, cuyo propósito es la
formación de sus integrantes en el área de tecnología aplicada a la robótica; con la finalidad
de ofrecer un profesional con cualidades idóneas para los requerimientos del mercado laboral.
VISIÓN
Queremos ser un referente latinoamericano en la formación de profesionales de alto nivel en
el área de robótica mediante la investigación, innovación y creación de proyectos, estando a la
vanguardia en cambios tecnológicos.
VALORES
En Robocol valoramos e inculcamos:
Excelencia Aprendizaje
Innovación Trabajo en equipo
Integridad Resiliencia
2
AUTORES
Carlos Alfonso Oliveros Forero Daniel Villar Gonzalez
Franz Kevin Luepke Prieto Daniel Ricardo Barcasnegras Moreno
Sebastian Sierra Alarcón Alvaro Daniel Plata Marquez
Juan David Medina Tobón Brenda Catalina Barahona Pinilla
Natalia López Arango David Andres Caliz Hernandez
Martin Pelaez Londoño Valentina Parra Garcés
Felipe Gomez Jasbon Gabriela Estefania Marquez Loaiza
Eloy Andrés Briceño Moreno Javier Hernán García Sánchez
Jorge Alfredo Chaparro Gamboa Angela Maria Vargas Guerrero
Paulina Michelle Acosta Cevallos José Alexander Da Cámara Sousa
Jose Cristobal Arroyo Castellanos María Alejandra Escalante Pérez
Juan Jose Rosas Esteban Juan David Serrano Mugica
Ana Sofia Miranda Ramirez Jorge Felipe Gaviria Fierro
Santiago Usme Martinez Luis Felipe Pinzón Troncoso
David Andres Sanchez Umbarila Felipe Berón
Cesar Sebastian Gomez Mozo Jhoan Esteban León Echeverri
Santiago Andres Rondon Huertas Laura Juliana Aldana Giraldo
Jaime Andres Nuñez Gonzalez Nicolás Grandas Suarez
Hermes Steve Ayala Calvo Luisa Fernanda Rengifo Cajías
Jesus David Espinosa Rubio Alvin David Gregory Tatis
Juan Sebastian Alegría Zuñiga Jorge Luis Lamprea
Juan Camilo Gutierrez Gonzalez
Daniel Esteban Ortiz Carvajal
3
ÍNDICE ÍNDICE
Índice
1. Introducción 8
2. Rover 9
2.1. Subsistema Brazo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.1. Miembros del subsistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.2. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.3. Trabajo realizado este semestre . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.4. Modelo dinámico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.5. Desarrollo de brazo virtual . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.6. Planeamiento de mejoras . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.7. Primeras pruebas de autonomía . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.8. Trabajo futuro a realizar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1.9. Errores y aprendizajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2. Subsistema Tracción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.2. Rediseño Rocker Bogie y junta Bogie . . . . . . . . . . . . . . . . . . . . 20
2.2.3. Caja Diferencial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.4. Controlador MIMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.3. Subsistema Comunicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.3.2. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.3.4. Red de Wi-Fi dual: Jhoan Esteban León . . . . . . . . . . . . . . . . . . . 36
2.3.5. First Person View (FPV) : Laura Juliana Aldana y David Caliz . . . . . . . 37
2.3.6. Interacción con la Jetson desde casa : Franz Luepke . . . . . . . . . . . 38
2.3.7. Sistema de comunicaciones por XBee . . . . . . . . . . . . . . . . . . . . 39
2.4. Subsistema Sensórica y Extracción . . . . . . . . . . . . . . . . . . . . . . . . . 42
4
ÍNDICE ÍNDICE

2.4.2. Cotización de sensores nuevos . . . . . . . . . . . . . . . . . . . . . . . . 42
2.4.3. Programación de sensores en Arduino . . . . . . . . . . . . . . . . . . . . 43
2.4.4. Base de datos en Excel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.4.5. Re-diseño de pala . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.5. Subsistema Computación Científica . . . . . . . . . . . . . . . . . . . . . . . . . 49
3. Submarino 50
3.1. Subsistema Chasis y Tanque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.1.2. Restricciones de diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.1.3. Estructural y Acoplamiento . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.1.4. Tanque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.1.5. Investigaciones e innovaciones . . . . . . . . . . . . . . . . . . . . . . . . 71
3.2. Subsistema Dinámica y control . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
3.2.2. Análisis del Submarino . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
3.2.3. Algoritmos de Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
3.2.4. Caracterización de Motores . . . . . . . . . . . . . . . . . . . . . . . . . . 80
3.2.5. Simulaciones de Gazebo . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4. Complementarios 87
4.1. Subsistema Potencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.1.2. Creación del subsistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.1.3. Definir objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.1.4. Primeras Ideas BMS (Battery Management System) . . . . . . . . . . . . 88
5
ÍNDICE ÍNDICE

4.2. Subsistema Visión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.2.3. Objetivos establecidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
4.2.4. Software/Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.3. Subsistema Interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
4.3.3. Introducción a documentación . . . . . . . . . . . . . . . . . . . . . . . . 95
4.3.4. Herramientas Necesarias para correr el servidor . . . . . . . . . . . . . . 95
4.3.5. Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
4.3.6. Pestaña de Tracción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.3.7. Pestaña de Autonomía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.3.8. Pestaña de Brazo Robótico . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.3.9. Pestaña de Sensórica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.3.10. Pestaña de Estatus del Rover . . . . . . . . . . . . . . . . . . . . . . . . . 101
5. Lunabotics 103
5.1. Subsistema Lunabotics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.1.2. Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.1.3. Interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
5.1.4. Mecánica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
5.1.5. Actuadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
5.1.6. Motores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
6. Gestión 124
6
ÍNDICE ÍNDICE
6.1. Subsistema Gestión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

6.1.2. Sistema integrado de información . . . . . . . . . . . . . . . . . . . . . . 125
6.1.3. Sistema integrado compras . . . . . . . . . . . . . . . . . . . . . . . . . . 125
6.1.4. Base datos y organigrama . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
6.1.5. Nueva Página Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
6.1.6. Planeación de eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
6.1.7. Concurso ACOFI 2020 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
6.1.8. Patrocinadores Internacionales . . . . . . . . . . . . . . . . . . . . . . . . 131
7
1 INTRODUCCIÓN
1. Introducción
La iniciativa estudiantil de la Universidad de los Andes, Robocol, contiene dos ramas
operacionales y una de capacitación, rover, submarino y Lunabotics, respectivamente. Cada
una cuenta con sus respectivos subsistemas propios y tres de ellos que son compartidos.
Estos subsistemas compartidos desarrollan tecnología que es compatible con los dos
proyectos principales, como potencia, visión e interfaz. Cada subsistema tiene un capitán que
tiene un puesto en la Junta de Directores (BoD Robocol) y es responsable de la gestión y la
comunicación del progreso de su respectivo equipo. La mayoría de los subsistemas tienen
miembros de distintas carreras y departamentos, esto nos permite tener varias opiniones y
experiencia en múltiples temas que conducen a soluciones innovadoras y es lo que hace a
Robocol un equipo interdisciplinario. Este año adicionalmente se tiene un equipo de gestión
con la labor de coordinar la financiación, los medios, las relaciones públicas y la logística del
equipo, entre otros.
Este documento tiene como objetivo presentar todos los avances que se realizaron en
Robocol a lo largo del semestre 2020-10. Adicionalmente, tener una visión más clara del
progreso del equipo y llevar un control de los logros y tareas completadas a lo largo del
semestre para poder planear de la mejor manera el trabajo a realizar el próximo periodo. Se
identifico que en los 10 años de Robocol, hay muy poca información, experiencias y
aprendizajes de proyectos anteriores, lo cual es muy valioso para la continuidad y avance de
grupo. Este documento que se realizara de ahora en adelante a final de cada semestre
permitirá a nuevos y futuros integrantes construir sobre cimientos antiguos integrantes y
permite a Robocol crecer como organización en términos tecnológicos y de experiencia.
Este documento también permite que todos los miembros actuales tengan un conocimiento
básico de todos los subsistemas para tomar mejor decisiones y, además, permite difundir los
avances y trabajo con con publico externo a Robocol.
Cada capitulo de subsistema contiene la siguiente estructura básica:
Integrantes (con sus respectivos departamentos de trabajo).
Avances realizados.
Logros alcanzados.
Trabajos futuros y posibilidades de mejoramiento.
Lecciones y aprendizajes
8
2 ROVER
2. Rover
9
2.1 Subsistema Brazo 2 ROVER
2.1. Subsistema Brazo
2.1.1. Miembros del subsistema
Felipe Gómez - Ingeniería Mecánica (Capitán)
Franz Luepke - Ingeniería Electrónica
Jaime A. Nuñez - Ingeniería Mecánica
Jorge Gaviria - Ingeniería Electrónica
Daniel Barcasnegras - Ingeniería Mecánica
Juan Camilo Gutiérrez - Ingeniería Electrónica
David Andrés Sanchez - Ingeniería Electrónica
2.1.2. Introducción
Este semestre fue el primero donde un equipo se dedico totalmente al desarrollo del Brazo
Robótico del Rover. Al inicio, el equipo fue conformado por solo 4 miembros, pero en las ultimas
instancias del semestre se unieron dos miembros de Lunabotics. El subsistema tiene varios
campos de estudio, tales como: dinámica, ambientes de simulación, automatización, diseño
estructural, etc. En este año se buscaba el desarrollo de una segunda versión del brazo robótico
actual del equipo, buscando mejorar el diseño de brazo, Crotalus, de la alumni Sofía La Rota,
sin cambiar su diseño funcional. No obstante, debido a la situación actual este objetivo dejó
de ser la prioridad, debido a que se volvió necesario un fortalecimiento de las herramientas de
simulación y modelos para poder seguir trabajando sin la necesidad de un brazo físico. Por lo
tanto los desarrollos presentados a continuación enfatizan la segunda situación expuesta.
2.1.3. Trabajo realizado este semestre
Como se expuso en la introducción, se situó un objetivo grande de mejoras físicas y

posteriormente se desarrollaron dos objetivos para la parte virtual del semestre y el periodo
inter-semestral. Sin embargo en adición a los dos objetivos planteados, se presentará un
proyecto que se venía trabajando desde finales del anterior año.
2.1.4. Modelo dinámico
Desde el anterior año, en conjunto con el desarrollo del brazo físico, se inició el desarrollo
de un Modelo Dinámico (MD) del brazo. Sin embargo, por cuestiones de tiempo y del constante
prototipado del Crotalus, este MD, no se logró terminar. Con esto en cuenta, el equipo definió
que para la situación actual, el desarrollo de este MD, sería de gran ayuda para complementar
un ambiente de simulación para el brazo virtual. Ya que, con este MD se pueden iniciar los
10
primeros pasos al desarrollo de un modelo de dinámica inversa, el cual es necesario para

proyectos futuros.
Con lo anterior en cuenta el equipo definió desarrollar un modelo dinámico el cual cumpla
con el siguiente objetivo:
Por medio de la entrada de las 6 velocidades angulares de los grados de libertad posibles,
se logra, en un sistema de coordenadas homogéneo, saber la posición en tres dimensiones
del End Effector del brazo. Por último a partir de esta posición tener un esquema básico, de no
solo la posición, sino la orientación del mismo End Effector.
Figure 1. Sistemas coordenadas
Cuando se desarrolle este modelo y se tenga una caracterización del Brazo, Se iniciará el
desarrollo del modelo de dinámica inversa, por medio del uso de una base de datos, la cual
con una regresión polinómica, arrojará el polinomio que cumpla con las trayectorias del brazo.
De esta forma, se modela el siguiente vector que permitirá el cumplimiento de este objetivo.
11
Figure 2. Vector de posición
Para lograr este objetivo, el equipo se puso en contacto con el asistente graduado Daniel
Beltrán y el profesor Carlos Francisco Rodriguez para guiar el proyecto. Debido a que este
era un tema nuevo para todos los integrantes, se guía el proyecto por medio de las siguientes
fuentes:
Robotics: Modelling, Planning and Control
Bruno siciliano, Lorenzo, Sciavicco, Luigi Villani, Guiseppe Oriolo
Dinámica Mecánica
Carlos Francisco Rodríguez
Actualmente en el desarrollo del modelo, se logró el desarrollo del sistema de coordenadas
homogéneo mostrado en la figura anterior, el cual se muestra en la siguiente matriz de rotación.
Figure 3. Matriz de rotación en 3 ejes coordenados
Se espera que en el periodo inter-semestral, el desarrollo del modelo esté terminado, y el

modelo en el software Matlab ya este acoplado al ambiente de simulación, MoveIt.
2.1.5. Desarrollo de brazo virtual
Para poder conocer el estado del brazo virtual y hacer la planeación de las rutas a seguir
del mismo se hace uso de una herramienta de ROS llamada MoveIt, la cual permite un modelo
de robot, sus capacidades, limitaciones, alcances y demás parámetros para darle a entender al
sistema sobre el funcionamiento del robot. Esta herramienta después de configurada permite
agregar el modelo del brazo como el que se muestra en la figura 4, este se logró con ayuda de
los CADs diseñados en Inventor los cuales fueron importados y configurados correctamente
en MoveIt para su correcto funcionamiento.
12
Figure 4. Brazo virtual simulado y para uso como retroalimentación en tiempo real y planeación
de rutas.
El modelo virtual tiene muchas ventajas ya que permite la movilidad y una gran cantidad
de complementos como el poder agregar elementos visuales al ambiente (como lo muestra la
figura 5 donde se muestra a la garra agarrando una bandera) y definir sus restricciones para el
correcto planeamiento de trayectorias.
Figure 5. Brazo virtual agarrando una bandera con las pinzas.
Uno de los avances más importantes de este primer semestre del año 2020 fue la
implementación correcta la garra del brazo en MoveIt el cual permite ser abierta y cerrada en
su totalidad como su homólogo físico real, como se puede ver en la figura 6. Además también
es posible obtener todas las posiciones intermedias entre esta 2 para poder agarrar objetos
de diferentes grosores.
13
(a) Garra abierta (b) Garra cerrada
Figure 6. Garra del brazo completamente abierta y completamente cerrada.
La herramienta MoveIt también es de gran utilidad para hacer planeación de rutas, esto lo
hace por medio de una interpolación de rutas muy cercanas a la actual las cuales son muy
fáciles de alcanzar (ver figura 7), el número de interpolaciones en una trayectoria se puede
aumentar para tareas de mayor delicadeza según se requiera, aunque aumenta el costo
computacional entonces no se recomienda para trayectoria largas, sino es más recomendable
llegar a la cercanía del punto requerido con bajo número de interpolaciones, como se ve en la
figura 7 y posteriormente hacer una planeación más precisa para cumplir con el objetivo.
Figure 7. Planeación de ruta del brazo. Se muestra una trayectoria hecha por interpolación de
diferentes posiciones que el brazo tiene que seguir hasta llegar desde lejos hasta estar donde
se encuentra la bandera.
Este trabajo de MoveIt se unió posteriormente con MATLAB para integrar el modelo
dinámico junto con MoveIt, de esta manera dado que los cálculos y pruebas dinámicas se
estaban realizando en Matlab se decidió unir el software a ROS para lograr observar el
comportamiento del brazo dado los parámetros dinámicos calculados de la manera más real
posible con este acercamiento virtual.
14
2.1.6. Planeamiento de mejoras
Como se comentó en la introducción del subsistema, el plan original era diseñar e

implementar las mejoras para la segunda versión del Rem-U. Hablando con la diseñadora del
primer brazo y recibiendo su retroalimentación. Después de un análisis preliminar se
determino la siguiente lista de mejoras:
2.1.6.1 Impresión 3D
Se analiza que las piezas en impresión 3d las cuales soportan el brazo, no resistieron las
fuerzas que proporcionaba los movimientos del mismo. Por lo tanto es necesario analizar por
medio de programas de simulación estructural cuales serían los esfuerzos a los cuales se
someterían cada pieza. Siguiendo con esto se ejecutarían pruebas de resistencia del material
con una gama de probetas de varios infill de impresión 3d, para ver cual es el infill necesario
para asegurar un buen mantenimiento del brazo. No obstante se explica que este estudio sería
hecho de manera superficial y no con toda la profundidad como es posible la investigación de
resistencia del material.
2.1.6.2 Substituto fibra de carbono
En esta primera iteración del brazo se exploro el desarrollo estructural del brazo con fibra de
carbono. El material se comporto como lo esperado y dio muy buenos resultados. Sin embargo
varios problemas iniciaron a surgir con el mismo. Estos problemas en su mayoría consistieron
en la mala manufacturabilidad de las piezas y como debido a falta de tolerancias esperadas,
muchas partes no tuvieron el ajuste esperado. Por otra parte al momento de desarrollar orificios
en la Fibra de Carbono, se estaban cometiendo malas practicas de ingeniería debido a que
se estaba dañando el compuesto. Con lo anterior en cuenta se explica que para la próxima
iteración del brazo se buscará una impresión en 3d que logre cumplir con los requisitos.Para lo
anterior se hará el mismo proceso que con la impresión 3d en el párrafo anterior.
2.1.6.3 Desarrollo de carriles
Debido a los problemas con las tolerancias del párrafo anterior, se explica que los
mecanismos de ajuste no deberían depender de solo un ajuste sino poder desplazarse para
poder arreglar la conexión de tornillos. Por lo tanto la nueva iteración tendrá esto en cuenta.
2.1.6.4 Vibraciones
Debido a los movimientos del brazo, se analizó que los tornillos usados y ajustes, después
de cierta cantidad de repeticiones, se iniciaban a desprender. Esto se debe a que ningún
ajuste fue diseñado para soportar las vibraciones generadas por el mecanismo. Con lo anterior
15
en cuenta se diseñará sobre los carriles expuestos previamente un mecanismo que pueda
amortiguar estas vibraciones y darle al brazo un tiempo más largo antes de tener que ser
rearmado.
2.1.6.5 Sensores
Exponiendo los anteriores dos problemas dispuestos para el brazo se expone que los
sensores no se usaron de manera correcta. Los potenciómetros utilizados aunque de gran
calidad, debido al mecanismo de engranajes desarrollados, no sirvieron de manera perfecta.
En varias instancias debido a los problemas expuestos previamente se menciona que había
momentos que debido a los acoples y tolerancias los potenciómetros no giraban con la junta
entregando información incorrecta. Con lo anterior en cuenta es necesario desarrollar un
mecanismo que sin importar los engranajes y acoples siempre permita el giro del
potenciómetro y por tanto entregue la información correcta.
2.1.7. Primeras pruebas de autonomía
Con el trabajo realizado en MoveIt se conectó este modelo virtual con el brazo real por
medio de un control de XBox, en la primera parte del semestre fue posible realizar pruebas
antes de iniciar el tiempo de cuarentena. En la figura 8 se puede ver como el control permite
controlar la interfaz de MoveIt de manera tal que se pueda llegar a poses del brazos
previamente preestablecidas y comparadas con el brazo real de manera que se tenga fácil
acceso de 3 configuraciones mínimo (rest, ready, pick).
Figure 8. Planeación de ruta con control de Xbox.
16
Pose Descripción Imagen

Posición de descanso del brazo
usada para guardarlo lo más posible
Rest
y poder mover la tracción con
tranquilidad y seguridad.
Posición ideal para poder realizar un

trabajo de manipulación de un panel
Ready
que esté en frente del rover a la altura
accesible por una persona.
Posición ideal para recoger un objeto

Pick del suelo que esté al frente del rover
en una vecindad cercana.
Posición ideal para dejar un objeto

Place recogido en los contenedores fijos del
rover.
Cuadro 1. Diferentes poses preestablecidas del brazo para realizar labores básicas como lo
son guardarse, queda listo para manejar un panel o recoger y dejar un objeto.
Con la planeación de MoveIt, la interfaz para controlar el brazo mediante el control de Xbox
y el brazo real se configuraron los drivers y el código de control en la FPGA para poder mover
17
el brazo siguiendo la interpolación de trayectorias propuesta por MoveIt, esta se corroboraba

por medio de la lectura de los potenciómetros usada como lazo de retroalimentación. Con esto
se puedo llegar a las posiciones del cuadro 1 almacenadas en las diferentes teclas del control.
En la figura 9 se muestra un fragmento de la interpolación de la posición de rest hacia la
posición de recoger algo. Esta imagen es una superposición de 3 diferentes momento de esa
trayectoria.
Figure 9. Planeación de ruta con control de Xbox y seguimiento de trayectoria de manera

autónoma. Interpolación de posiciones para salir de la posición de rest dirigiéndose hacia la
posición de pick
2.1.8. Trabajo futuro a realizar
Realizar una simulación del movimiento real del brazo teniendo en cuenta las
características de los motores y demás componentes, agregando posibles errores en la
medición y en el control.
Mejorar el sistema de retroalimentación para tener mayor precisión en el movimiento.
Definir un mejor método de controlar el brazo, ya sea con joysticks, acelerómetros,

controles de consola, entre otros.
Acoplar con el trabajo que está siendo realizado en visión de profundidad de objetos.
Evaluar métodos alternativos de manejo del brazo con realidad virtual, por ejemplo con
Kinect.
Agregar cámaras simuladas a la simulación para ver como se vería en competencia.
18
2.2 Subsistema Tracción 2 ROVER
Agregar a la simulación elementos simulados de la competencia y hacer pruebas para

entrenar y saber los cambios a realizar.
Unir modelo dinámico con MoveIt.
Poder recoger y dejar objetos con precisión en Moveit.
Definir junto con visión la estructura de la información para poder realizar tareas
autónomas, por ejemplo saber a que distancia se encuentra un objeto del brazo.
Definir los procesos necesarios para realizar cada una de las tareas que se planean lograr
que el brazo realice de manera autónoma.
El desarrollo de la sección de planeamiento de mejoras.
El desarrollo de mecanismos para aumentar la fuerza posible del brazo.
2.1.9. Errores y aprendizajes
En el semestre se denotaron errores en su mayoría por funcionamiento del equipo. En

varias instancias no se trabajo de manera totalmente coordenada y frente a la situación de la
pandemia no se inicio un plan guía para ejecutar hasta últimos momentos del semestre.
Por otra parte se presentaron varios errores en la preparación de la virtualización y no se
desarrollo un plan especial para los confortantes del equipo para una transición directa a los
ambientes de simulación.
Por último hubo varios problemas con el desarrollo de las actividades. En este caso se
habla del desarme del brazo y del desarrollo del modelo. En ambos casos no se contacto con
profesores o con la anterior diseñadora del brazo para tener una guía y por lo tanto las tareas
se subestimaron y no se pudieron terminar totalmente.
Con lo anterior en cuenta se aprendieron muchas cosas. Primero El equipo aprendió que
la comunicación es vital y el sentimiento de grupo es necesario. Segundo el equipo vio como
ante situaciones imprevistas es de vital importancia planear lo antes posible como afrontarlas.
Tercero es vital para el funcionamiento tener una guía y supervisión de personas con
experiencia para no caer en los mismos errores y hacer uso del tiempo de la mejor manera.
2.2. Subsistema Tracción
Carlos A. Oliveros Forero - Ingeniería Mecánica (Co-Capitán)
Eloy Briceño - Ingeniería Electrónica (Co-Capitán)
Santiago Usme - Ingeniería Mecánica
19
Jesus David Espinosa - Ingeniería Mecánica
Franz Kevin Luepke - Ingeniería Electrónica
Miguel Ángel Díaz - Ingeniería Electrónica
Jose Alexander Da Cámara - Ingeniería Electrónica
Paulina Acosta - Ingeniería Electrónica
2.2.2. Rediseño Rocker Bogie y junta Bogie
Inicialmente se analizó el funcionamiento del sistema Rocker-bogie a profundidad y se

identificó un problema con el diseño actual. Se encontró que los momentos generados por las
cargas a las que se sometía la estructura generaba que el rover se .abriera de patas no
2
estuvieran perpendicular al suelo. En pruebas pasadas se identifico que el ángulo de apertura

es superior a 9 % por cada rocker 10. El problema se genera principalmente en las juntas de
acople con los tubos de fibra de carbono. Debido a un retraso con la llegada con los tubos, fue
necesario diseñar y manufacturar sin tenerlos en físico y verificar las dimensiones que nos
ofrecía el fabricante. Cuando se ensamblo se encontró que había un pequeño juego entre las
2 piezas lo cual debilitó y expandió el tubo con el tiempo. Esto genero que las 2 piezas rotaran
entre ellas y lo que generan el efecto que se menciono al inicio. Se trato minimizar el efecto
presionando el tubo contra el acople con arandelas y ángulos de aluminio pero esto no
soluciono el problema. En la competencia ERC2019 fue necesario instalar guayas de acero
para cancelar momentos como último recurso, esto solucionó el problema pero redujo
significativamente la movilidad de rocker bogie.
(a) Rocker Bogie 2019 (b) Problema
Figure 10. Sistema Rocker Bogie 2019
Para corregir seria necesario cambiar todos acoples y tubos por lo cual se decidió una
búsqueda en internet de los distintos diseños de rovers que participaron en la competencia
URC SAR 2019 y basado en los diseños que llamaron más la atención se realizaron 2 bocetos
de alternativas que podrían dar solución al problema existente y funcionar óptimamente.
20
Boceto 1
Este primer boceto está inspirado en un diseño anterior del rover y sigue una geometría
curva que además de solucionar el problema de los momentos, nos permite tener un gran
ángulo efectivo por su geometría curva y al estar compuesto de dos placas de aluminio
podría tener una buena resistencia ante los esfuerzos a los que se somete la estructura.
(a) Render 1 (b) Render 2
Figure 11. Boceto 1
Boceto 2
Este boceto está inspirado por el rover construido por KNR Team. Este supone realizar
un ensamble con 4 tubos de fibra de carbono con uniones de aluminio, estas uniones se
realizan con tornillos lo cual ofrece una muy buena resistencia ante cargas a las que se
someterá el rover.
(a) KNR Team Rover (b) Render 1
Figure 12. Boceto 2
Después de una discusión con el equipo del subsistema se descartaron los dos diseños
anteriores para enfocarnos en un nuevo diseño que resulta ser más prometedor dado que
basado en lo aprendido con el sistema anterior el objetivo principal es reducir la cantidad de
sujetadores que tenía, aumentar la rigidez de todo el sistema y facilitar el ensamble del
21
componente. Inspirados por el rover construido por PCz Rover Team se inicio a trabajar sobre
este diseño. 13
(a) PCz Rover 1 (b) PCz Rover 2
Figure 13. PCz Rover
Boceto 3
Este nuevo diseño supone realizar un ensamble de dos tubos de aluminio doblados. El
radio de curvatura de estos tubos se definió realizando una superposición con el diseño
actual, ya que el brazo está diseñado para funcionar a una altura especifica.
(a) Render Preliminar 1 (b) Render Preliminar 2
Figure 14. Nuevo Rocker Bogie
Para la unión se han pensado dos alternativas, la primera consiste en un eje que atraviesa
el tubo del bogie para unirse con unos rodamientos que se ajustarían a las placas que
conforman la estructura de la unión como se ilustra a continuación:
22
(a) Render 1 (b) Render 2 (c) Render 3
Figure 15. Nueva Junta Bogie 1
La segunda opción no necesita de los rodamientos y resulta ser un poco más sencilla
para su manufactura y ensamble. Esta consiste en un eje que atraviesa el tubo y se
sujeta en la estructura de la unión con un buje de bronce que se acopla y se atornilla en
las placas laterales como se muestra a continuación:
(a) Render Preliminar 1 (b) Render Preliminar 2
Figure 16. Nueva Junta Bogie 2
Se eligió este tipo de unión sobre la anterior por su simplicidad y porque con esta unión
el diámetro del agujero de perforación por donde pasa el eje es menor, lo cual hace
que la placa sea más resistente. La manufactura de esta unión se llevaría a cabo por
la soldadura de tres placas de aluminio, en la placa superior se soldaría al tubo y esta
soldadura se podría reforzar soldando una platina triangular de aluminio sobre la platina
horizontal y contra el tubo. Por otro lado, para asegurar el eje se realizaría un ajuste de
chaveta.
2.2.3. Caja Diferencial
El diferencial del sistema actual de tracción para el Rover consta de cuatro engranajes
cónicos. Dos de estos están acoplados a los ejes vienen directamente de la tracción de un
23
lado del Rover (uno por cada lado). Los otros dos engranajes se encargan de controlar la
diferencia de tracción de los lados del Rover. De esta forma el Rover es mas estable cuando
cruza obstáculos.
Problemática actual y solución
El sistema actual utilizado en el Rover tiene mucho juego en los engranajes y esto causa
fallas y choques innecesarios en los dientes del diferencial. Debido al juego, cuando se
posiciona todos los elementos mas pesados, como el brazo y las baterías, el chasis se inclina
y se desestabiliza. Además de esto, dado al naturaleza del chasis con platinas, ángulos y
uniones no permanentes, este se deformaba en ciertos puntos lo cual generaba que la
chumaseras se descuadraran y por ende el eje también.
Figure 17. Diferencial Actual
Para solucionar un problema como estos tocaría cambiar cada engranaje del diferencial.
Claro que esta podría no sería la mejor solución. Para que los engranajes, en un futuro,
tengan menos juego se pueden utilizar engranajes con mayor cantidad de dientes. Todo el
sistema debería tener algún tipo de substancia que evite algunos daños por fricción y
promueva el ajuste. En este caso se podría pensar en una caja diferencial para asegurar que
estén acoplados y posicionados de forma correcta.
También existen engranajes con diseños helicoidales. Las desventajas de este tipo de
engranajes son que necesita mayor lubricación, tienen mayor desgaste y son mas costosos.
Estos engranajes generalmente se usan para velocidades más altas.
Después de observar diferentes productos por internet, se pensó que lo mejor sería diseñar
el producto que se desea. Sin embargo, esto resultaría bastante caro y tampoco se tienen las
herramientas/maquinaria/materia prima para lograrlo. Por lo que ahora toca elegir un engranaje
24
que sirva de internet y en un futuro adecuarlo al Rover. Se podría comprar un engranaje más
grande o pequeño y realizar varios procesos para adecuar su tamaño.
Implementación inicial
Figure 18. Boceto Inicial
Teniendo en cuenta el primer boceto 18, lo más adecuado es construir una caja que sea
más fácil de manufacturar en la universidad, sin embargo, hay que cambiar la perspectiva
que se tenía de la caja. En los primeros bocetos, la caja era un componente que mantenía
todo junto, pero era muy delgada y difícil de hacer. La idea es que la caja no solo “sostenga”
sino “mantenga” todo junto y a presión. Esto es importante ya que, a la hora de instalar los
rodamientos y ejes, estos no deben moverse de ninguna forma, deben permanecer totalmente
firmes.
Se prioriza la compatibilidad con los elementos que se tienen actualmente y su utilidad. Por
lo que, una de las cosas más importantes es que pudiera usarse con los ejes que se tienen
con los nuevos engranajes.
Por esta razón, se decidió que el diámetro del engranaje debía ser menor al del eje, para
que se mantenga el ajuste y si es necesario expandir su diámetro, lo que se puede hacer
fácilmente con las maquinas de la universidad.
La medida actual de los ejes del Rover es de 19.050 mm y la medida con mejor ajuste para
el engranaje era de 0.625 in o de 15.875 mm. Afortunadamente, al seleccionar esta como el
diámetro de perforación en la página, esta acomodaba todos los valores para el engranaje.
Además de lo descrito anteriormente, también se tuvo en cuenta que el número de dientes
debía ser mayor que el del anterior modelo, para evitar un posible juego entre los engranajes.
Este engranaje tiene 20 dientes, incremento con respecto al del año pasado. (cerca de 12
dientes).
25
Producto final de la implementación
(a) Vista ortogonal del diseño final para la (b) Vista frontal del diseño final para la caja
caja diferencial del Rover diferencial del Rover
Figure 19. Nuevo Rocker Bogie 2
Figure 20. Vista ortogonal de corte a la mitad de los engranajes y ejes.
26
Figure 21. Vista lateral de corte medio.
El diseño final de la caja diferencial esta basado en una figura principal cubica con 4
agujeros en cada cara para asegurar tapas con las que se mantendrán los rodamientos
asegurados. En este caso se planea tener dos rodamientos por eje (como debería ser), sin
embargo, para lograr esto tocaría cambiar ciertas características de los ejes que ya tenemos.
Por lo que, por ahora solo se tendrá en cuenta un rodamiento por eje. Esto se busca cambiar
más adelante. Respecto a los engranajes, están basados en las medidas tomadas por el
producto que se cotizó en Amazon. La caja también cuenta con 4 agujeros en la cara frontal
para asegurarla a la estructura principal del Rover. En un futuro es muy probable que cambien
las medidas de la caja para optimizar espacio y material. La parte de en medio de la caja en
donde parece que sobra algo del material de los ejes es algo que puede cambiar junto con los
ejes.
Manufactura de la caja
Como se dijo anteriormente, se busca adecuar el diseño a los ejes que ya se tenían, por lo
que el proceso de manufactura se va a centrar en la caja. La materia prima de la caja se va a
obtener como un bloque o cilindro grande del material. En este caso será un metal (ojalá no
muy pesado) que pueda soportar las cargas. Esto puede ser un acero de bajo carbono o un
aluminio aleado.
El bloque se va a cortar primero con sus medidas cúbicas básicas (la estructura cúbica
básica de la caja) para luego hacer los agujeros y redondeados (si es necesario). Para el
agujero principal, donde van los engranajes, y los intersticios de los ejes se va a hacer uso del
torno (ya que es posible que no poseamos brocas de esos calibres). Para los demás agujeros
se puede usar la fresadora. En algunos agujeros se necesitará rosca interna para su fácil unión,
si ese el caso, se usará el torno nuevamente. Al final si se considera necesario se pueden
hacer redondeos en las esquinas y bordes de la estructura para que se reduzcan los puntos
de esfuerzo del material y se vea más estético.
27
Como se ensamblaría
En primer lugar se ajustan los 4 rodamientos que van a ir dentro de los 4 intersticios de la
caja. Seguido se debe ingresar cada eje por su agujero respectivo a la caja y hacer su ajuste
con sus respectivos engranajes en simultaneo y se aseguran las chavetas y anillos sengel.
Después se hará el ajuste final con todos los rodamientos y se pondrán las tapas que aseguran
cada rodamiento. Al final la caja deberá quedar totalmente rígida y los ejes se deberían mover
libre y fácilmente. Para ensamblar todo el sistema de tracción diseñado debe ubicarse dentro
de la caja previamente mostrada y la caja de asegurará mediante pernos y tornillos al chasis
principal.
2.2.4. Controlador MIMO
En cuanto al control planteado para el sistema de tracción, inicialmente se tenían seis

controladores PID de bajo nivel para cada llanta. Lo anterior nos brindaba muchas
limitaciones a la hora de manejar el rover, especialmente desde un punto de vista autónomo.
La propuesta planteada es implementar un controlador de medio nivel para el sistema de
tracción.
Un controlador MIMO (Multiple Input Multiple Output) se basa en tener múltiples señales
de referencia para así poder controlar múltiples variables o estados del sistema. En nuestro
caso, se tomó cada llanta del rover como un estado (variable); lo que estamos buscando
lograr es poder tener un controlador general del sistema de tracción, que permita controlar de
forma independiente cada una de las ruedas. En principio, esto no pareciera ser distinto a
simplemente generar el "setpoint"de cada rueda y dejar que el controlador PID de bajo nivel
se encargue, sin embargo, el controlador MIMO nos permite, no solo facilitar la generación de
esas señales de referencia de cada una de las ruedas, sino también el dejar de pensar en
instrucciones como "Mover rueda delantera derecha a 60RPM empezar a pensar en
2
instrucciones como Ïr hacia adelante a 1 m/s". En otras palabras, el aporte presentado por el
controlador MIMO es el poder pensar en instrucciones más complejas a realizar por el rover.
Es necesario destacar, que este trabajo ha estado siendo supervisado por el profesor Michael
Bressan, quien nos ha guiado en el paso a paso en la implementación de este controlador.
El primer paso que se tuvo que realizar fue la caracterización de cada uno de los motores
con carga y sin carga ante las condiciones en las cuales operan en el rover, es decir, bajo la
misma arquitectura utilizada la cual incluye un driver para cada motor. La arquitectura bajo la
cual se realizó la caracterización se presenta a continuación en la Fig.22
28
Figure 22. Arquitectura utilizada para la caracterización
Cabe destacar que hasta el momento, los "Buck Converter"no han sido implementados y
por lo tanto no fueron utilizados para la caracterización de los motores. Hasta el momento, solo
se han caracterizado los motores sin carga, por lo que es necesario realizar la caracterización
con carga para observar en que punto, la función de transferencia de cada motor difiere entre
cuando tiene carga y cuando no. Los resultados obtenidos para todos los motores, indican
un sistema de primer orden, todos los resultados fueron similares entre sí. A continuación, se
presenta en la Fig. 23 los resultados obtenidos para el motor 3.
29
Figure 23. Caracterización del Motor 3
Luego, se sintonizaron todos los controladores PID de bajo nivel mediante la herramienta
.autotune"de Matlab y se buscó que la respuesta escalón de cada uno de los sistemas
independientes fuera la misma. En la Fig. 24 se puede observar los resultados obtenidos para
una sintonización buscando un overshoot menor al 10 % y un tiempo de establecimiento de 2
segundos.
Figure 24. Respuesta escalón de todos los motores con sus respectivos controladores
Por último, se observó la respuesta escalón de cada uno de los sistema (motor y controlador
PID) con una alimentación de 24V y cambiando el setpoint aumentándolo y disminuyéndolo.
A continuación en la Fig.25 se puede observar el resultado obtenido para un motor. Cabe
destacar que se obtuvo el mismo resultado para todos los motores.
30
Figure 25. Respuesta escalón del motor 3 ante cambios en el setpoint
Como se puede observar, la respuesta obtenida ante el los cambios de setpoint, presentó
un overshoot y tiempo de establecimiento dentro de los parámetros establecidos en el diseño
de los controladores. Es necesario destacar que la razón por la que se escogieron dichos
valores fue arbitraria, sin embargo, se pensó en la física del rover, no se quería que el
arranque fuera ïnstantáneo"debido a la inercia presentada por el resto de los componentes.
Una vez realizado todas estas caracterizaciones, procedimos al planteamiento del

controlador MIMO, sin embargo, al mismo tiempo fue cuando ocurrió la pandemia del
Covid-19, la cual nos impidió realizar las pruebas físicas por lo que tuvimos que replantear los
objetivos. En base a ello, procedimos con la implementación del controlador MIMO en
simulación. Para lograr lo anterior, utilizamos Gazebo, el cual es un paquete del sistema ROS
que permite realizar simulaciones cercanas a la realidad bajo las mismas condiciones físicas
que presenta el rover en la realidad. Utilizamos un modelo aproximado del rover para ser
movido dentro de Gazebo. En la Fig.26 se puede observar el modelo simulado del rover.
31
Figure 26. Modelo del rover dentro de Gazebo
Una de las ventajas de este simulador es el hecho que permite modelar la física de los
elementos incluyendo colisiones, inercias, fricción, entre otros. Como podemos observar en
la Fig.27 se muestran distintas situaciones y análisis que se pueden realizar sobre el modelo
del rover. Otra ventaja que presenta Gazebo es que es un paquete de ROS, por lo que el
funcionamiento sigue los mismos lineamientos de tópicos, nodos y servicios haciendo así que
el trabajo en este fuera fácil.
32
(a) Centros de masa (b) Inercia de las piezas
(c) Simulación de cámara en el rover para (d) Rover en las escaleras.

visualización de competencia.
Figure 27. Configuraciones distintas del rover.
Una vez que se tuvo el modelo del rover en Gazebo, se procedió a realizar la
implementación del controlador MIMO en MATLAB y utilizando el Ros Toolbox de MATLAB, se
pudo comunicar ROS con MATLAB. Todo el procedimiento y análisis matemático realizado
para lograr la implementación del controlador MIMO se encontrará en un artículo que está en
proceso de redacción, dicho documento se encontrará en la base de datos de Robocol en la
herramienta Teams. La estructura base que se utilizó fue que el control de alto nivel hecho en
ROS le publicara las distintas instrucciones a realizar (setpoints) a un tópico en el que
MATLAB está subscrito, al igual que Gazebo funcionaba como retroalimentación del sistema
publicando información sobre las velocidades de las ruedas a un tópico al cual MATLAB
también está subscrito. Luego de forma iterativa, MATLAB realizaba la acción de control
generada por el MIMO implementado en este y enviaba a Gazebo la acción de control para
que fuera realizada por los motores.
33
Por último se muestra el rover en diferentes ambientes de Gazebo en la Fig. 28, en donde
se puede ver el rover en un ambiente de marte junto al curisosity y en una ambiente de la tierra
junto a elementos comunes de la calle, este simulador no solo permite dibujar los diferentes
ambiente sino que también las condiciones atmosféricas, climáticas, la gravedad, el viento lo
cual permite tener un mejor acercamiento a la realidad. El diseño que se realizó del rover en
Gazebo se hizo basado en el estudio del modelo más complejo del Curiosity, este al ser más
complejo dio un amplio espectro de todo lo que se puede realizar con Gazebo y Rviz, además
de ser una excelente base de aprendizaje. Como se ve en la figura b se pudo simular el rover
del tamaño adecuado comparándolo con objetos, personas e incluso otro robot que se tiene
en la universidad en el laboratorio de Colibrí.
(a) Comparación del rover actual con (b) Rover en ambiente de asfalto
el Curiosity en simulación de Gazebo.
Figure 28. El rover en diferentes ambientes de Gazebo.
1. Por el lado mecánico de la tracción:
Ya teniendo un CAD preliminar del rocker bogie se procede a realizar simulaciones

sobre la estructura con las cargas encontradas el semestre pasado para validar su
correcto funcionamiento. Teniendo estos resultados muy seguramente se van a
optimizar las piezas y se pasará a realizar los planos de manufactura del todos los
elementos.
Es necesario implementar sensores en las juntas rocker y bogie para que se pueda
registrar la posición real de sistema y poder incluirla en la simulación en tiempo real.
Por parte del diferencial es necesario simular el ultimo prototipo y optimizar las
geometrías de este debido a su peso. Iterando con las simulaciones se espera
llegar a sistema óptimo para poder proceder con los planos de manufactura.
34
2.3 Subsistema Comunicaciones 2 ROVER
2. Por parte del control de la tracción:
Es necesario realizar la caracterización de los motores con carga y observar las

diferencias existentes entre dicho modelo y el modelo sin carga ante distintas cargas.
Es necesario lograr la implementación del controlador MIMO en el rover, para lograr
esto solo se tiene que reemplazar los motores simulados por Gazebo y utilizar los
motores reales al igual que utilizar la retroalimentación real de los motores y no la
de Gazebo.
Finalizar el artículo que se encuentra en proceso de redacción en donde se realiza
todo el análisis matemático de la implementación del controlador MIMO.
Este semestre se vivió una situación atípica que nos tomó por sorpresa desde un punto de
vista académico como personal. Tuvimos que afrontar una serie de problemas e inconvenientes
debido a la virtualización y la imposibilidad de trabajar de forma presencial. La desmotivación
por parte de los distintos integrantes del equipo fue uno de los problemas más grandes que se
enfrentó. Sin embargo, de esta experiencia logramos probar y demostrar distintos de nuestros
valores como integrantes de Robocol que es la excelencia y la resiliencia. A pesar de que
nos afrontamos a un problema que literalmente cambió "las reglas del juego", no titubeamos
y cambios nuestros objetivos a corto plazo, buscamos la forma de poder trabajar así fuera
a distancia y mantener la excelencia por la que hemos trabajado tanto en mantener. Esta
experiencia nos abrió los ojos a que siempre existirá algo que no hayamos previsto y que en
ese momento no hay que desesperarnos sino parar por un momento, replantear la situación y
trabajar en pro de nuestras metas y objetivos.
2.3. Subsistema Comunicaciones
Sebastián Gómez - Ingeniería Electrónica (Capitán)
Franz Luepke - Ingeniería Electrónica
Laura Juliana Aldana - Ingeniería Electrónica
Jhoan Esteban León - Ingeniería Electrónica
David Caliz - Ingeniería Electrónica
2.3.2. Introducción
El semestre 2020 − 1 se creó el subsistema de comunicaciones con el fin de mejorar los

sistemas de comunicaciones ya empleados, proponer distintos enlaces de conexión entre la
35
estación base y el rover y permitir el control del rover de forma remota sin importar los
posibles fallos que puedan ocurrir en él. El equipo se creó con 4 miembros y posteriormente
se incluyó un miembro de Lunabotics. Basándose en las experiencias previas y los problemas
tenidos anteriormente en las pruebas del Rover se propusieron distintas soluciones y
alternativas. Los sistemas de comunicaciones cuentan con distintas capas de estudio, desde
la capa física en la que es necesario diseñar o escoger las antenas necesarias para cubrir el
rango necesario dependiendo de su sensibilidad, ganancia, polarización y potencia requerida,
también la capa de enlace y red en la que es necesario definir qué tipo de protocolo se va a
implementar, hasta la capa de aplicación en la que es necesario brindarle a los distintos
subsistemas una conexión simple con el Rover.
En este período se buscaba como objetivo inicial la caracterización de las antenas que
pertenecen a Robocol, con el fin de aprovechar al máximo su potencial dentro del proyecto,
esta meta no fue posible alcanzarla debido a la coyuntura actual por lo que fue necesario
avanzar a la etapa de propuestas e investigación en donde con base en las deficiencias del
sistema de comunicaciones usado anteriormente se busca plantear soluciones y distintos tipos
de canales de transmisión de datos.
2.3.4. Red de Wi-Fi dual: Jhoan Esteban León
Anteriormente se contaba con un sistema de comunicaciones en donde se utilizaba un

acces point y un router que trabajaba en la banda de 2,4 GHz, aunque en condiciones tipicas
no presentaba mayores problemas, al momento de estar situados en un campo con una alta
presencia de redes Wi-Fi se presentaba una demora considerable en el tiempo de envío y
recibo de datos con el rover, por esta razón se propuso implementar una red dual de Wi-Fi (2,4
y 5 GHz) en donde fuera posible transmitir por cualquiera de las 2 bandas si alguna llegara a
colapsar, además de que trabajar con una red de 5 GHz permite velocidades de transmisión
mas altas. Se realizó un trabajo de investigación en donde se presentó un documento con la
consignación de distintos routers que cumplían con las características deseadas en cuanto a
doble banda, velocidades de transmisión, alcance, posibilidad de conectar antenas externas
para mayor cobertura y costo. Aunque no es posible en este momento comprar los modelos
seleccionados y realizar las correspondientes pruebas, de acuerdo a las hojas de
especificación de los fabricantes es posible implementar este sistema y además eliminar el
AP usado anteriormente, lo que conlleva a eliminar la batería de alimentación del AP que
agrega peso al rover.
36
Figure 29. Router actual de una sola Figure 30. Posibilidad de nuevo router de 2
banda. bandas.
2.3.5. First Person View (FPV) : Laura Juliana Aldana y David Caliz
La información proporcionada por las cámaras es de vital importancia para el manejo y

control del rover, en el proyecto se cuenta con distintas camaras que permiten desde el
desplazamiento del Rover hasta la interacción de el brazo con distintos objetos, aun así, la
capacidad de transmisión necesaria para enviar toda esta información es bastante alta, y si se
congestionan los canales y se vuelve imposible controlar a precisión el rover, además de que
si el sistema colapsa no hay forma de conectarse nuevamente con el rover. Por esta razón se
decidió implementar otro canal de comunicación dedicado a la recepción de vídeo del rover.
Este sistema FPV permite enviar vídeo a frecuencias mas altas que las redes Wi-Fi evitando
interferencias con otras redes y permitiendo una latencia menor. Se realizó un documento
donde se especificó el funcionamiento del sistema y sus correspondientes elementos de
implementación, cada uno con su correspondiente opción disponible en el mercado. Listo para
comprar e implementar una vez sea posible.
37
Figure 31. Transmisor seleccionado como Figure 32. Receptor seleccionado como
primera opción primera opción
Además de la sección de investigación también se desarrollaron avances prácticos
2.3.6. Interacción con la Jetson desde casa : Franz Luepke
Debido a las dificultades presentadas en el semestre fue necesario buscar alternativas y

soluciones para trabajar desde casa, se logró conectar e interactuar con la Jetson creando una
VPN y conectando la tarjeta a esta red, de esta forma fue posible probar nuevas ideas, como
lo son:
Trabajo Multi-Master en ROS en donde es posible contar con distintos ROScore en el

sistema, de forma que si ocurre algún problema con uno, sea posible seguir conectado y
en funcionamiento con los otros.
Trabajar distintas personas, sobre la Jetson al mismo tiempo desde distintos lugares.
Este sistema de Multi-Master es de gran utilidad ya que permite seguir conectado con el
rover en ROS aún incluso en caso de que toda la red WiFi se caiga por medio de la Xbee
y un segundo maestro en la estación base. Esta es una ventaja enorme cuando se trabaja
con el rover a distancia ya que un problema que sería muy sencillo de arreglar si se tuviera el
rover cerca se convierte en un enorme problema cuando se tiene un sistema remoto, y esto
precisamente es la solución a este problema.
La solución planteada al problema de perdida de conexión WiFi se representa en la figura
33, en esta se pueden ver 3 círculos, estos son los nodos (los diferentes programas del
sistema), el nodo [node_fpga] se encarga de toda la comunicación entre la Jetson y la FPGA
38
(la FPGA es la encargada de hacer cumplir las ordenes recibidas, de los controladores y de la
lectura de los sensores), el nodo [Django_node] es la página web que corre en la Jetson cuyo
host es el rover y que sirve para enviar los comandos y presentar todos los datos recibidos y
finalmente el nodo [node_xbee_pc] corre en un computador de la estación base (no en el
rover) el cual tiene conectado un Xbee por USB y establece una comunicación permanente
con la Xbee conectada en el rover es el encargado de mantener la comunicación con el
segundo maestro (computador en la base) de modo que si el primer maestro (Jetson en el
rover) llega a perder su comunicación Wi-Fi por cualquier motivo este no salga ni un momento
del ambiente de ROS y sea posible mantener la comunicación continua con el rover,
permitiendo pasar toda los comandos por este medio de ser necesario, aunque la
comunicación sería un poco más lenta y habría que aprovechar de esa manera mejor los
recursos para el manejo del rover.
Figure 33. Gráfico de conexiones de nodos (programas) y tópicos (enlaces de comunicación)

básicos del rover.
2.3.7. Sistema de comunicaciones por XBee
Debido a los problemas que puede presentar una red Wi-Fi como la congestión del canal e
interferencia, se propone implementar un canal de comunicaciones alterno con una tarjeta
XBee 868LP , este canal de comunicaciones transmite a una frecuencia baja de 868 MHz,
pero cuenta con un alcance alto, es por esta razón que se selecciona como sistema de
comunicaciones de respaldo encargado de enviar información básica y permitir reiniciar la
FPGA o la Jetson de ser necesario y otras funcionalidades de complejidad baja pero
importancia alta. En este trabajo ya se logró realizar una conexión de la Jetson con la XBee y
crear un nodo que recibe información entre las 2 tarjetas.
39
Figure 34. Configuración Host XBee Figure 35. Configuración Cliente Rover
Implementar funciones de la XBee con su respectivo nodo de ROS en la Jetson.
Implementar sistema de GPS para conocer la posición del rover.
Diseño y simulación de antenas para FPV.
Creación de scripts que permitan manejar la conexión con la Jetson de forma mas fácil
por cualquier integrante de Robocol.
Sebastián Gómez : Ser líder del subsistema ha sido una experiencia bastante importante
para mí, el plantear unas metas y delegar tareas para cumplirlas ha sido enriquecedor, como
grupo hemos aprendido juntos sobre implementación de sistemas de comunicaciones,
conocimientos que no se adquieren en el aula de clase y permiten entender la forma en la que
los proyectos conjuntos se realizan. Debido a la cuarentena fue complicado adecuarnos al
cambio y tener que cambiar de planes drásticamente, además como integrante nuevo de
Robocol fue complejo entender al inicio como funcionaba el proyecto, aún así he aprendido de
40
ROS y de distintas herramientas que antes no conocía.
Laura Juliana Aldana: Al comenzar a trabajar no tenía mucho conocimiento en el campo

de comunicaciones, pero a medida que avanzábamos en el subsistema aprendí mucho sobre
las diferentes partes que componían el rover en este aspecto. Aprender sobre temas como el
FPV o ROS (temas que no he tenido la oportunidad de conocer en mis estudios en la
Universidad) es motivador. Tener presente que debido a los sucesos de este año no pudimos
probar muchas de las metodologías planteadas, lo cual ha representado una gran dificultad
porque no se han podido implementar algunas de la mejoras planteadas.
Jhoan Esteban León : El trabajo en el grupo y específicamente en el subsistema ha sido, en

buena medida, enriquecedor y beneficioso para mi tanto a nivel académico como personal. He
logrado aprender ciertas cosas y adquirir conocimiento que de otra forma no hubiese adquirido.
Claramente se presentaron diferentes dificultades para desarrollar las actividades del grupo,
entre las cuales está la carga académica de la Universidad, todo el tiempo que consumen los
cursos y pues eventualmente la virtualidad del trabajo. Estos inconvenientes han obstaculizado
un poco el trabajo y el buen desempeño que se hubiera tenido en el subsistema. Sin embargo,
se puso lo mejor de nuestras partes para sacar adelante nuestros deberes y poder aportar
desde nuestro subsistema al proyecto en general.
Franz Luepke: Como miembro antiguo de Robocol he visto grandes cambios en el equipo
a lo largo del tiempo lo cual me ha traído mucho aprendizaje, ser parte de este equipo con
miembros nuevos me muestro como a pesar del tiempo siempre se sabe tan poco y siempre
hay mucho por aprender, conocer nuevas personas con ideas frescas con experiencias
diferentes a las de uno enriquece mucho todo este aprendizaje. He podido enseñar muchas
cosas sobre lo que se ha realizado pero también he aprendido mucho de nuevos y mejores
métodos de hacer las cosas que pueden ser mezclados con los que ya se conocían. De lo
que más queda de este grupo es ver como muchas veces las cosas se complican más de lo
que deberían por falta de conocimiento y de aprovechar mejor recursos que se tienen.
David Caliz: Siendo el miembro más reciente del subsistema, rápidamente he descubierto
el potencial que tiene por delante el subsistema aparte de las muy buenas ideas que ya se
vienen implementando. Conocer a detalle el rover me ha motivado a aprender sobre algunos
temas sobre los cuales sabia muy poco así como he podido aportar a las propuestas con algo
de experiencia personal. En materia del progreso realizado hasta ahora, siento que uno de
los puntos más importantes ha sido el intercambio de conocimiento involucrado en la creación
de las propuestas; donde no solo ocurre un crecimiento personal por el ciclo de aprendizaje -
enseñanza entre los miembros sino además se agrega valor a los proyectos futuros. A pesar de
las dificultades que nos han impedido comenzar la implementación y realizar pruebas practicas,
me mantengo optimista sobre el futuro de las propuestas, dado que se han podido estructurar
y sustentar razonablemente para que se lleven a cabo una vez tengamos la oportunidad.
41
2.4 Subsistema Sensórica y Extracción 2 ROVER
2.4. Subsistema Sensórica y Extracción
Natalia López Arango- Física (Capitana)
Luisa Fernanda Rengifo - Geociencias
Laura Juliana Aldana - Ingeniería Electrónica
Johan Esteban León - Ingeniería Electrónica
Franz Kevin Luepke - Ingeniería Electrónica
Daniel Villar - Ingeniería Electrónica
2.4.2. Cotización de sensores nuevos
Durante el primer semestre de 2020, se decidió comenzar con mejorar los sensores que
ya se tenían puesto que los anteriores no eran muy convenientes en términos de precisión de
medida y de calidad de los mismos. Por esto, se realizó la cotización de los siguientes sensores
1. MQ-4 Sensor de metano: Este es un sensor para detectar Gas Metano (Gas Natural)
en el aire. El MQ-4 puede detectar concentraciones desde 300ppm hasta 10000 ppm.
Presenta una alta sensibilidad y un tiempo de respuesta rápido. La salida del sensor
tiene una resistencia analógica.
2. MQ-7 Sensor de monóxido de carbono (CO): Sensor de monóxido de carbono de uso

simple, ideal para medir concentraciones de CO en el aire de forma rápida y con precisión
aceptable. El módulo posee una salida analógica que proviene del divisor de voltaje que
forma el sensor y una resistencia de carga. También tiene una salida digital que se calibra
con un potenciómetro, esta salida tiene un led indicador.
3. MQ-8 Sensor de hidrógeno: Es un sensor para detectar concentraciones de hidrógeno

en el aire, puede detectar concentraciones de gas de hidrógeno en cualquier lugar entre
100ppm y 10000ppm. Además, tiene una alta sensibilidad y rápido tiempo de respuesta.
4. TGS3870 Sensor gas metano y monóxido de carbono: Puede detectar ambos gases
aplicando periódicamente dos voltajes de calentamiento diferentes. Consume tan solo
38mW y tiene alta sensibilidad y selectividad a ambos gases, mientras tiene una baja
sensibilidad a vapores de alcohol.
5. SEN-DS18B20-2M Sensor de temperatura: Sonda de temperatura sumergible basada

en sensor DS18B20 que se comunica por interfaz 1-wire, lo cual implica que solo usará
3 hilos hacia el microcontrolador. Cada sensor DS18B20 tiene un único código serial de
64-bit que permite conectar múltiples DS18B20 al mismo bus 1-wire, permitiendo realizar
mediciones de temperatura en múltiples puntos.
42
6. SEN0114 Sensor de humedad: Este sensor de humedad de suelo cuenta con un

revestimiento que lo protege de la oxidación, puede leer la cantidad de humedad
presente en el suelo que lo rodea. Este sensor utiliza las dos sondas para pasar
corriente a través del suelo, y luego se lee que la resistencia a obtener el nivel de
humedad. Más agua hace que la electricidad se conduzca por suelo Más fácilmente
(menos resistencia),mientras que el suelo seco conduce menos electricidad (mayor
resistencia).
7. ADAFR-3709 Sensor de calidad de aire: Sensor Adafruit SGP30 de calidad de aire para
partículas VOC y eCO2 de interfaz 2 Wire I2C calibrado de fábrica con una precisión
típica del 15 %. Este sensor combina múltiples partículas de sensado en metal-óxido en
un solo semiconductor para entregar una señal fideigna de la calidad del aire. El sensor
detecta un amplio rango de componentes orgánicos volátiles y H2 para implementarlo en
monitoreo de calidad de aire en interiores. Al conectarse el sensor devolverá una lectura
de TVOC o su equivalente en dióxido de carbono sobre la interfaz I2C.
Con estas nuevas referencias, se espera tener medidas mucho más precisas de las
propiedades físicas y químicas y una completa caracterización del suelo por donde pasa el
rover.
2.4.3. Programación de sensores en Arduino
Debido a la situación actual, los sensores no han llegado aunque están incluídos dentro del
presupuesto actual de Robocol, sin embargo los miembros del equipo que estudian ingeniería
electrónica lograron programarlos en arduinos con ayuda de los Datasheet de cada uno. Los
códigos realizados se encuentran en la carpeta de los archivos generales del rover y serán
usados cuando se tengan finalmente los sensores.
2.4.4. Base de datos en Excel
Otro de los objetivos del grupo, es tener una base de datos en la interfaz del rover tal que
durante la toma de medidas con los sensores, se pueda tener un estimado de las
características de las muestras recogidas en la pala así que desde el grupo de sensórica se
recogieron en Excel los datos de las características físicas y químicas típicas de diferentes
minerales. Este documento también se encuentra en los archivos generales del rover y
adicional a él se le hizo la respectiva documentación para que haya claridad con lo que se
espera de cada medida. En las siguientes imagenes se puede ver un poco de lo que se ha
recopilado hasta durante la construcción de la base de datos.
43
Figure 36. Rangos medibles por los sensores de pH y metano, hidrógeno y monóxido de
carbono.
Figure 37. Rangos medibles por los sensores de temperatura, humedad y concentración de
CO2.
44
Figure 38. Posibles minerales presentes en el suelo según el pH.
Figure 39. Información que se puede obtener de la medida con el sensor de monóxido de
carbono.
45
Figure 40. Información que se puede obtener de la medida con el sensor de temperatura.
Figure 41. Información que se puede obtener de la medida con el sensor de humedad.
46
Figure 42. Asociación de diferentes minerales con el valor del pH medido en el suelo.
Las anteriores figuras son el boceto de la base de datos que se está construyendo. Con ella
se espera que en el momento en que la pala recoja la muestra, se realice la medición de las
propiedades físicas mencionadas anteriormente, es decir, que se haga una medición in-situ.
Después, se espera que los datos arrojados sean comparados con la base de datos y que
en la interfaz de ROBOCOL se pueda dar la información correspondiente al rango de valores
medidos.
2.4.5. Re-diseño de pala
Hasta el año pasado, se contaba con una pala para extraer las muestras durante las
competencias, sin embargo, luego de la competencia de septiembre de 2019 se concluyó que
dicha pala no tenía un diseño adecuado para las características del suelo donde se sacan las
muestras ya que el suelo de dicha competencia era bastante rígido y la pala no tenía la rigidez
adecuada para excavar. Debido a esto, se optó por re-diseñar la pala para volverla a hacer en
un material mucho más resistente y con una forma adecuada para la correcta extracción.
El nuevo diseño, cuenta con una pieza metálica en la punta de la pala con la que se busca
facilitar el proceso de excavación del terreno, además cuenta con unos canales dispuestos en
la superficie de la misma, para poner el cableado de los sensores que van dentro de ella. Los
CADs de este diseño se encuentran en la carpeta de archivos generales del subsistema de
sensórica.
47
Figure 43. Nuevo diseño de la pala para extracción de muestras del suelo
Debido al confinamiento, el trabajo del subsistema se vio bastante afectado ya que no se

pudieron hacer pruebas con los sensores directamente sobre muestras y en general se
atrasaron muchos de los planes que se tenían. A continuación, se enumeran las tareas que
faltan para completar los objetivos actuales.
1. Implementación de la base de datos construída, en la interfaz de ROBOCOL para ser

usada in-situ.
2. Migración de los códigos de los sensores, de Arduino a ROS para poder ser usados con
el resto de sistemas del rover.
3. Fabricación de la pala basados en los CADs del nuevo diseño.
4. Realizar mediciones con los sensores en muestras preparadas por el equipo para
calibración y perfeccionamiento de los códigos.
5. Diseño de sistema para extracción de núcleos, para esto es necesaria la compra de una
broca especializada en la extracción de núcleos.
6. Diseño de sistema para medir densidad de muestras.
7. Re-diseño de cajas herméticas donde son depositadas las muestras recogidas con la
pala.
Las tareas mencionadas anteriormente, se propusieron con el fin de dar una solución
adecuada a las exigencias de las competencias, especialmente ERC. Consideramos también
que los sistemas que se están proponiendo, darán bastante información científica sobre lo
que el rover recoge durante su paso por el terreno de las competencias. Además, el aporte
científico de prototipos como este que se fabricó de manera conjunta con estudiantes de
diferentes departamentos de la universidad, es también de igual importancia al desarrollo del
rover mismo.
48
2.5 Subsistema Computación Científica 2 ROVER
La actual organización del equipo (por subsistemas, como se desarrolla en el presente

documento) es bastante reciente, por lo tanto, se considera que este semestre no hubo ningún
error considerable dentro del funcionamiento como grupo sensórica y extracción sino que hubo
bastante aprendizaje. A continuación, se enumeran algunas de las cosas que se aprendieron
durante el 2020-1
1. Trabajar en el desarrollo de un proyecto tangible con estudiantes de carreras tan

diferentes como lo son física e ingeniería electrónica ha sido bastante enriquecedor
porque se da la oportunidad de aprender de las diferentes metodologías (que se
fundamentan en los conocimientos adquiridos durante cada carrera) que se proponen
para resolver problemas.
2. Los estudiantes de ingeniería electrónica pertenecientes a este subsistema, tienen

bastantes habilidades para la programación en Arduino, sin embargo, toda la parte
electrónica del rover se ha programado en ROS así que los encargados de la
programación de nuestro subsistema, están adquiriendo nuevas habilidades para
facilitar la comunicación con el resto del rover.
3. Para el trabajo de los siguientes semestres, partiremos con bases teóricas bastante
sólidas que en condiciones de trabajo normales, no se hubieran adquirido.
2.5. Subsistema Computación Científica

Durante el semestre no se reporto trabajo del subsistema. Se esta evaluando la razón para
que no vuelva a ocurrir.
49
3 SUBMARINO
3. Submarino
50
3.1 Subsistema Chasis y Tanque 3 SUBMARINO
3.1. Subsistema Chasis y Tanque
Martín Pelaez - Ingeniería Mecánica (Capitán)
Felipe Pinzón - Ingeniería Mecánica
Ana Sofía Miranda - Ingeniería Mecánica
Juan Rosas - Ingeniería Mecánica
3.1.2. Restricciones de diseño
Cada equipo tendrá 20 minutos de tiempo durante la competencia. Los primeros 5

minutos constituyen el período de preparación. Durante este tiempo, el vehículo puede
no ser desplegado en el agua. El período de rendimiento de 15 minutos de duración
sigue inmediatamente. Estos horarios están sujetos a cambios dependiendo del número
de concursantes.
Un equipo puede intentar múltiples carreras durante el período de rendimiento. Una vez
que un equipo hace que los oficiales vuelvan a desplegar su vehículo, todos los puntos
ganados en carreras anteriores se pierden.
Cada equipo puede ingresar uno o varios vehículos a la competencia. Cada vehículo
será inspeccionado físicamente por el personal técnico de la competencia. El personal
técnico puede descalificar cualquier vehículo que considere que representa un riesgo de
seguridad irrazonable para la instalación anfitriona.
Durante una carrera clasificatoria, semifinal o final, cada vehículo debe operar de
manera autónoma durante su carrera. Mientras lleva a cabo la misión, no se permite la
comunicación entre el vehículo y cualquier persona o computadora fuera del tablero. Los
vehículos deben operar únicamente en función de su capacidad de detectar y maniobrar
en la arena utilizando los recursos a bordo. Al realizar una carrera clasificatoria,
semifinal o final, todo lo que se adjunte al vehículo debe sumergirse con el vehículo.
Cualquier parte que rompa la superficie se considera una violación.
Para la seguridad de su vehículo, requerimos que se cuelgue de un arnés o eslinga de

algún tipo. Incluso si el vehículo es lo suficientemente ligero como para llevarlo a mano,
queremos evitar accidentes humanos. Además, debemos pesar el vehículo y exigir que
el vehículo sea colgado de alguna manera para la medición.
Todos los vehículos deben contener un interruptor de apagado claramente marcado que
un buzo pueda activar fácilmente. El interruptor debe desconectar las baterías de todos
los componentes y dispositivos de propulsión en el AUV. Tenga en cuenta que esto no
51
tiene que matar la computadora. Tras la reactivación, el vehículo debe volver a un estado
seguro.
Todos los accesorios deben estar envueltos. Las cubiertas deben rodear el puntal y
tener al menos una distancia de 5,1 cm (2 inch). Entre el disco giratorio del puntal y los
bordes de la cubierta. Los propulsores comerciales califican como son, siempre que
estén envueltos.
No se permitirá un vehículo en el agua sin un interruptor de apagado y cubiertas

protectoras que funcionen correctamente.
3.1.2.1 Reglas y requerimientos
Para la competencia RoboSub, el AUV debe caber dentro de una caja de 1.83m de largo
por 0.91m de ancho por 0.91m de alto.
La siguiente tabla muestra las bonificaciones y penalizaciones asociadas con el peso del
AUV en el aire:
Peso Bonificación Penalización

Peso del AUV >56.7 kg N/A Descalificación
56.7 kg ≥ peso del AUV >38 kg N/A –(250 +11*(kg – 56.7)) puntos
38 kg ≥ peso del AUV >22 kg 4.4*(38 – kg) puntos N/A
Peso del AUV ≤ 22 kg 80 + 2.2*(22 – kg) puntos N/A
Cuadro 2. Peso del vehículo en el aire con bonificación o penalizaciones
Todos los vehículos deben tener una flotabilidad positiva de al menos la mitad del uno por
ciento de su masa cuando se hayan apagado mediante el interruptor de apagado.
Todos los vehículos deben funcionar con baterías. Todas las baterías deben estar
selladas para reducir el riesgo de electrolitos ácidos o cáusticos. Las baterías no deben
cargarse dentro de recipientes sellados en ningún momento. El voltaje de circuito abierto
de cualquier batería (o sistema de batería) en un vehículo no puede exceder los 60 VCC.
3.1.2.2 Objetivos generales
El sistema debe permitir ser transportado y manipulado por una sola persona sin la
necesidad de asistencia.
Mantener el sistema y todos sus componentes de forma compacta sin afectar la

modularidad de este para facilitar el mantenimiento y la actualización de los
componentes.
52
Debido a la situación actual global nos enfrentamos a una reducción de presupuesto y se

debe considerar la reducción de costos del sistema, por lo tanto, muchas de las piezas,
tornillos, acoples y servicios de manufactura serán obtenidos de proveedores locales.
Cumplir con las tareas en los plazos establecidos en el cronograma para lograr que la
dinámica del grupo sea eficiente, manteniendo un ambiente saludable entre los
integrantes.
3.1.2.3 Objetivos específicos
Tarjeta electrónica
• Permitir un sencillo acceso a las piezas electrónicas para facilitar el mantenimiento

de esta.
• Asegurar una sujeción firme y segura de los componentes electrónicos al tanque,
para garantizar el buen funcionamiento del sistema.
Integridad estructural
• El chasis debe permitir una movilización sencilla y segura a la hora de transportarlo

a eventos o pruebas.
• Crear acoples que sean intercambiables entre sí para la unión de los componentes
del sistema.
• El diseño del sistema tiene que incorporar rigidez estructural de parte de su
geometría y materiales que produzcan un sistema duradero.
• Se deben balancear todos los componentes teniendo en cuenta las líneas de inercia
y flotabilidad neutra.
• Mantener el modelo del sistema con una geometría hidrodinámica para permitir una
dinámica de maniobrabilidad más sencilla, para simplificar el control y hacerlo más
eficiente.
3.1.3. Estructural y Acoplamiento
En chasis y tanque se afrontan retos de integridad estructural. Se debe crear un chasis

que permita la facilidad de transporte a la hora de movilizarse para asistir a eventos o
pruebas, el sistema debe permitir ser transportado y manipulado por una sola persona sin
necesidad de asistencia. Es importante mantener un sistema y todos sus componentes de
forma compacta sin sacrificar la modularidad de este para permitir un fácil mantenimiento y
actualización de componentes en un futuro. La unión de los componentes de un sistema es
tan importante como el funcionamiento de estos, por lo tanto, crear acoples que sean
intercambiables entre sí para la unión de los componentes. Se busca el diseño de un sistema
que incorpore rigidez estructural dada por su geometría y materiales que cree un sistema
53
duradero. Se deben balancear y posicionar todos los componentes teniendo en cuenta las
líneas de inercia y flotabilidad neutra, así como mantener el modelo con una geometría
hidrodinámica para permitir una dinámica de maniobrabilidad más sencilla y suave que
permita simplificar y hacer más eficiente el control. Debido a la situación actual de salud todos
los subsistemas se enfrentan a reducción de presupuesto y se debe considerar la reducción
de costos del sistema, por lo tanto, muchas de las piezas, tornillos, acoples y servicios de
manufactura serán obtenidos de proveedores locales. A continuación en la figura 44 se
encuentra una imagen del progreso realizado en el modelo CAD en el semestre 2020 - 01.
Figure 44. Vista de el CAD para el ROV hasta 18/5/20
3.1.3.1 Materiales
A la hora de diseñar un sistema dinámico tan complicado como un submarino, que cambia
de ambiente de forma tan agresiva, se deben tener en cuenta varios factores. Uno de ellos
son los materiales de ingeniería que serán expuestos a los elementos. Para desarrollar un
chasis robusto estructuralmente y que cumpla con los requisitos estipulados por Robocol y la
competencia MATE. Se plantearon los siguientes requerimientos para la selección de
materiales:
Económico: Dada la situación actual por el Covid-19 el presupuesto otorgado a Robocol

fue considerablemente reducido. Adicional a esto, dado que el submarino es un programa
nuevo la capacidad iterativa que provee un material económico es altamente beneficiosa.
De esta forma se define que el material a usar deberá ser tanto económico como de fácil
adquisición (preferiblemente local) y que su costo de compra sumado al de manufactura
sea inferior al presupuesto estipulado al inicio del semestre académico.
54
De fácil manufactura: Debido a que el chasis del submarino cuenta con una cantidad
tan grande de elementos, cerca de 60 componentes individuales, incluyendo tornillería.
Es muy importante incorporar un proceso de manufactura rápido y eficaz que nos
permita hacer correcciones durante las etapas preliminares del prototipaje. De esta
forma se define un material de fácil manufactura, aquel cuyo proceso de manufactura
para llevarlo a la pieza deseada no demore mas de una semana, incluyendo logística y
dicho proceso, adicionalmente que dicha manufactura pueda ser llevada a cabo en las
cercanías o en la misma institución universitaria
Propiedades adecuadas: Para cada pieza en el subsistema se plantean diferentes

requerimientos de ingeniería, en el caso de la mayoría de los elementos se busca
rigidez y tenacidad. Sin embargo, estos requerimientos se explicarán individualmente de
acuerdo con las especificaciones de las piezas y su función en el sistema. Asegurar una
sujeción firme y segura de los componentes electrónicos al tanque, para garantizar el
buen funcionamiento del sistema.
A continuación, se muestran los materiales utilizados para sus respectivas piezas y porque
se utilizaron:
Armazón cerchado:
En el armazón o chasis principal se busca armar el esqueleto de todo el cuerpo del
submarino, por lo tanto, elegir una forma óptima tanto como un buen material es de vital
importancia. Para armar el chasis bbservado en la figura 44. se consideraron únicamente
termo plásticos, esto se debe a que otro tipo de materiales como los metales tienden a ser
más costosos y difíciles de manufacturar para el volumen que se esta buscando en una etapa
de prototipaje, adicional a esto son bastante pesados y aquellos que cuentan con propiedades
intrínsecas de resistencia a la oxidación por agua suelen tener un costo elevado mayor al
estipulado en el presupuesto.
55
Figure 45. Render de esqueleto en PMMA del chasis
Este chasis consta de 4 piezas independientes que dan la posibilidad de albergar todos
los componentes del submarino (Tanque, motores, flotadores, etc.) Para la fabricación de este,
se especulo utilizar policarbonato o polietileno de alta densidad (HDPE). Esta sugerencia fue
dada por uno de los miembros pertenecientes al equipo de ERC IMPULSE quienes lideran la
competencia a la fecha. Sin embargo, a la hora de realizar una investigación y realizar una
cotización y revisar disponibilidad con los siguientes proveedores:
Amazon
CatalogoDeEmpaque
Mercado libre
Al buscar alternativas gracias a la página web MakeltFrom.com Se encontró una

alternativa al HDPE. Esta alternativa es el polimetilmetacrilato o más conocido como Acrílico o
PMMA, cuenta con propiedades muy similares a las de polietileno de alta densidad (HDPE).
Las propiedades adecuadas para esta pieza son: Una densidad similar a la del HDPE, una
alta resistencia al impacto y un esfuerzo de tensión axial mayor a los 25 MPa, dado por la
simulación. cómo se puede observar en la siguiente figura:
56
Figure 46. Comparación de propiedades HPDE vs PMMA
las propiedades deseadas en el HDPE se encuentran adicionalmente en el acrílico, la mayor

diferencia siendo el costo:
Costo HPDE: 39 USD/lb
Costo PMMA: 15 USD/lb
Simulacion de elementos finitos:

Al simular este material con elementos finitos nos encontramos con los siguientes
resultados mostrados en las Figuras 47 y 48, obtenidos para el material PMMA aplicado sobre
el chasis. Al realizar un análisis de elementos finitos para el conjunto de las piezas, aplicamos
una carga de (30kg) con un factor de seguridad de 2 sobre las partes más cargadas del
57
submarino y de las cargaderas donde se transportará el submarino y se extraerá del agua. Al

analizar los resultados arrojados por nuestro análisis de elementos finitos nos damos cuenta
de que nos encontramos con que la selección de material realizada fue exitosa para analizar
estos resultados obtenemos un desplazamiento menor a una décima de milímetro junto con
un estrés máximo de 1 Mpa por Von Mises en las uniones de tornillería, esto es de esperarse
sin embrago nos da un factor de seguridad de 15 lo cual es bastante provechoso.
Figure 47. Simulación de desplazamiento en el esqueleto del chasis
58
Figure 48. Simulación en el esfuerzo mayor alcanzado en el chasis con Von Mises
Uniones entre laminas:

Un sistema solo es tan bueno como las uniones que lo mantienen, En esta sección se
habla de la selección de material para la unión de las piezas en el chasis, Para unir todas las
láminas de PMMA utilizadas para la construcción del chasis principal se consideró el uso de
pegamento por medio de acetona o cloroformo, sin embargo al investigar un poco más en el
asunto, nos encontramos con que este tiende a disolverse en el agua con el tiempo y pierde
sus propiedades al estar expuesto a alta humedad o sumergido, por esta razón se decidió
recurrir a la Unión de piezas por medios físicos. Para esto se implementó el uso de ángulos
de aluminio reforzados por enlace, esto nos da una mayor inercia en la pieza por muy poco
aumento de peso.
59
Figure 49. Acoples de aluminio de una pulgada
Para unir estas piezas se utilizarán tornillos de acero inoxidable dadas sus propiedades
resistentes al agua y lo elementos y aún más importante su fácil adquisición en el mercado. La
denominación de tornillería utilizada es M5x16
Unión entre motores
La unión directa entre motores obtenidos por bluerobotics T-200 thruster es simple de
realizar, se deben conseguir 4 tornillos estándares M3x12 de acero inoxidable ya que se debe
tener en cuenta tanto el grosor de la placa de acrílico, como la penetración del tornillos sobre
el motor y queda como se muestra en la siguiente figura:
60
Figure 50. Acoples de motor
3.1.3.2 Modularidad
El submarino al ser un sistema complejo, es vital que sea modular para permitir que el
sistema sea de fácil acceso para reparar y que sus piezas sean intercambiables entre sí. Para
lograr este modularidad, lo más importante es tener en cuenta las uniones de los componentes
y que estas sean estándar y de fácil adquisición. Pero mas importante que se puedan acoplar,
o cambiar de lugar cada uno de los sistemas.
Para mantener todos los sistemas y piezas intercambiables entre el sistema, se decidió
mantener un estándar de piezas a utilizar y mantener el tipo de piezas a en la menor cantidad
posible, mantener los tornillos de la misma denominación o denominación similar (para el caso
del submarino M5), el tipo de acoples angulares se mantiene constante a lo largo de todos
los soportes angulares, adicionalmente todas las piezas extraídas de laminas de PMMA se
utilizan para formar las piezas que son del mismo grosor. Utilizar esta geometría plana permite
almacenar mas de estos perfiles para repuestos y permite adicionar componentes adicionales
en un futuro.
61
Figure 51. Imágenes de elementos que permiten la modularidad del sistema
Para el acople de los motores se decidió manejar un sistema de doble configuración que
permite configurar los motores de dos formas diferentes: Modo control y Modo Turbo. El modo
turbo posiciona los motores directamente de forma frontal maximizando velocidad sobre todo
lo demás y la configuración de control le da prioridad al control y precisión en los movimientos
al únicamente cambiar la posición de una docena de tornillos.
3.1.3.3 manufactura y diseño
Realizar un proceso de diseño considerando la fase de manufactura tanto como la fase

de operación facilita el proceso de producción y reduce costos a la hora de manufacturar las
piezas, en el caso de un sistema complejo como el submarino este proceso no es diferente,
en especial cuando se habla de un prototipo en el que se debe iterar sobre varios procesos
para encontrar la mejor forma de resolver un problema de diseño. En este caso se denominará
el método de manufactura para aquellas piezas que no sean estandarizadas como tornillos o
motores.
Paredes y piso de chasis principal
Método: Láminas de acrílico cortadas con agua o corte láser para mayor precisión.
Costo aproximado: 120,000 COP por lamina.
62
Figure 52. Diagrama DWG para corte láser de las piezas.
Para el diseño de las paredes laterales del chasis se basó en una de las figuras
geométricas más resistentes de la naturaleza, el triángulo. Esto se realizo para distribuir las
fuerzas de carga directamente al suelo y unirlo minimizando el esfuerzo en otros lugares del
chasis. Debido a esto, no se puede construir un chasis completamente cerrado ya que esto
limita la fuerza producida por los thrusters T-200. Esto se puede observar en la figura 52 en
donde se muestra la magnitud de las fuerzas a lo largo de las líneas junto con un lineamiento
que permite ver la incorporación de la geometría triangular en el diseño. Adicionalmente se
añadieron concentradores de esfuerzo en todos los ángulos y esquinas pertenecientes a las
laminas principales del armazón del chasis.
63
Figure 53. Análisis de distribución de fuerzas en la estructura cerchada.
3.1.4. Tanque
El proceso de concepción de un tanque que contenga los componentes electrónicos para

el AUV debe empezar por considerar los requerimientos más importantes para el desempeño
del sistema. Primero, el tanque debe proporcionar un ambiente que permita el funcionamiento
esperado de los componentes, a la vez de un espacio suficiente para estos. En este caso
un ambiente adecuado es aquel que aísle del agua y acoplé los componentes de tal manera
que no permita choques entre ellos y el tanque, y por lo tanto futuros daños. Además de
esto, también se considera importante el fácil acceso a los componentes debido a que cómo el
diseño del AUV es un proceso iterativo, la dificultad para cambiar y/o reparar piezas del sistema
electrónico entorpecería las iteraciones.
Ahora si se considera el funcionamiento del AUV además de solo el de los componentes
electrónicos dentro del tanque, se hace claro que el tanque debe permitir una comunicación
entre los componentes internos y externos (como los motores) del tanque; en este caso la
comunicación va a ser por medio de cables. Adicionalmente, debe procurarse que el tanque
afecte en la menor medida a la dinámica del AUV. Por lo tanto, debe buscarse que la estructura
del tanque sea lo más dinámica posible.
Considerando todos los requerimientos previos se llegó al modelo mostrado en la Figura
54, cuyo proceso de diseño se muestra detalladamente a lo largo de los siguientes literales de
64
esta sección.
Figure 54. Diseño del tanque hasta la fecha.
3.1.4.1 Materiales
La selección de materiales para el Tanque y su tarjeta electrónica, que es la parte interna

que acopla a los componentes electrónicos con el tanque, se hizo siguiendo los mismos
criterios presentados en el literal de materiales de la sección Estructural y Acoplamiento. De
esta forma, a continuación se muestran los requerimientos de ingeniería para cada parte y el
material seleccionado.
Tanque:
Para el tanque se decidió utilizar modelos que hayan sido empleados y probados con
anterioridad. El tanque propuesto es el WTE6-ASM-R1 fabricado por la empresa
BlueRobotics mostrado en la Figura 55. El cual consta de un cilindro de acrílico extruido y dos
tapas laterales de aluminio 6061-T6.
65
Figure 55. Plano del tanque WTE6-ASM-R1 de BlueRobotics. Tomado de:

https://bluerobotics.com/store/watertight-enclosures/6-series/wte6-asm-r1/.
Tarjeta electrónica:
Para la tarjeta electrónica se planteó el requerimiento particular de un material que pudiera
soportar el peso de los componentes electrónicos sin superar su punto de fluencia, para evitar
deformaciones permanentes y posteriores fracturas. El peso de los componentes se calculó
tomando como referencia al BlueRov de BlueRobotics, como se muestra en la Ecuación 1.
Adicionalmente, Esta selección de material también debió considerar el diseño de la tarjeta
electrónica mostrado en la Figura 56.
Wtanque − Welectronicos − Wcilindro − Wtapas = 0 (1)
Welectonicos = 1,02kg
66
Figure 56. Diseño de la tarjeta electrónica 18/05/20. Esta se encuentra acoplada a la tapa
trasera del tanque.
Se escogió el ABS cómo el material para la tarjeta electrónica y los soportes circulares
mostrados en la Figura 56. Esta elección se hizo principalmente por el bajo costo del material
y por su posibilidad de ser manufacturado tanto por impresión 3D (proceso disponible en la
Universidad) como por corte láser (proceso de fácil acceso y corta duración). Para evaluar si
este material soporta el peso de los componentes electrónicos, se realizaron simulaciones para
la tarjeta y los soportes en Autodesk Inventor, utilizando el ABS con las propiedades mostrados
en el Cuadro 3. Los resultados de estás pruebas se muestran en las Figuras 57 y 58.
Nombre ABS plastic

Densidad 1, 06g/cm3
General Esfuerzo de Fluencia 20, 00M P a
Esfuerzo de Fractura 29, 60M P a
Módulo de Elasticidad 2, 24GP a
Mecánicas Coeficiente de Poisson 0, 38ul
Módulo de Corte 0, 81GP a
Cuadro 3. Propiedades del ABS utilizado para las simulaciones.
67
Figure 57. Factor de seguridad para la placa electrónica. La Fuerza aplicada es el peso de los
componentes electrónicos y se fijaron los encajes de la tarjeta.
Figure 58. Factor de seguridad para el soporte circular. Las Fuerzas aplicadas son un cuarto
del peso de los componentes electrónicos y se fijó la superficie del aro externo.
Debido a que para ambos casos el factor de seguridad de se mantuvo superior a 1, se

decidió continuar trabajando con el ABS cómo el material elegido para los soportes y la tarjeta
electrónica. Aún así, se tiene en cuenta que está sujeto a cambios debido a posibles
68
modificaciones en el diseño de la tarjeta electrónica.
3.1.4.2 Diseño
Para el Diseño del tanque se decidió, como se mostró en las partes anteriores, tener dos
partes que constituyeran el modelo y se acoplaran entre sí: El tanque (Parte externa) y la
tarjeta electrónica (parte interna). Para el tanque, como ya se mencionó, se propuso utilizar
un modelo estándar fabricado por BlueRobotics procurando que este cumpliera con todos los
requisitos de ingeniería del tanque. Por otro lado, la tarjeta electrónica fue diseñada con base
en el tanque seleccionado buscando que generara un buen acople y que cumpliera con los
requerimientos de ingeniería.
Tanque:
El tanque tiene un diametro interno de 152mm y una longitud libre de 228mm, el equipo
consideró que debido a la cantidad de componentes electrónicos y a sus dimensiones, este
espacio proporcionado es adecuado para su distribución interna. Este tanque cuenta con una
tapa de sellado que impide el paso de agua hasta 65m de profundidad y que requiere de solo
una persona para su extracción sin uso de herramientas adicionales ni una fuerza considerable.
Por último, la comunicación por cable podrá llevarse a cabo debido a los orificios que presenta
esta tapa como se muestra en la Figura 59.
Figure 59. Tapa trasera del tanque.
Tarjeta Electrónica:
69
La tarjeta electrónica consta de tres partes principales, como puede verse en la Figura 56:
la placa electrónica que es en donde se distribuyen los componentes, los soportes circulares
que se encargan de restringir el movimiento de la tarjeta por medio de un ajuste de holgura
con el tanque y los acoples entre estas partes y con el tanque.
La placa electrónica es una lamina rectangular de 150x179mm y 5mm de espesor con
unos encajes en sus extremos para acoplarse a los soportes circulares, como se muestra en
la figura 57. Esta fue pensada para ubicarse en el eje medio del tanque con el fin de sujetar
componentes tanto arriba como abajo de la tarjeta y aprovechar el espacio disponible.
Modificaciones en la tarjeta, como orificios que permitan el paso de cables entre sus caras,
están previstas para trabajos futuros a medida que se vaya determinando la distribución
adecuada de los componentes dentro del tanque.
Los soportes son dos círculos con un diámetro de 150mm y 5mm de espesor. Cuenta con
unos orificios de encaje para la placa y unos agujeros para tornillos M3 en los cuales van los
acoples entre ambos soportes y con la tapa trasera del tanque. Además, tiene cortes en forma
triangular que atraviesan su espesor, como se muestra en la Figura 58, pensados para que
permitan el paso de los cables de los componentes.
Las varillas de acoples y los tornillos utilizados para la tarjeta son los fabricados por
BlueRobotics. El acople con la tapa trasera se hace utilizando los cuatro orificios para tornillos
que esta tiene, como se muestra en la Figura 55. De esta manera, toda la tarjeta se encuentra
sujeta a la tapa del tanque y aprovecha su característica de fácil extracción asegurando un
acceso sencillo a los componentes electrónicos del AUV.
3.1.4.3 Trabajo Futuro
Teniendo en cuenta lo realizado y reportado este semestre para el tanque se consideran

tareas por realizar:
Evaluar las propiedades hidrodinámicas del tanque y, con base en los resultados,
proponer posibles mejoras.
Considerar el requerimiento de conductividad térmica para el tanque, debido a una

posible insulación de los componentes dentro del tanque.
Investigar los costos del material de la tarjeta electrónica y de su manufactura para

realizar una selección de material más precisa.
Iterar sobre el diseño de la tarjeta electrónica para la distribución de componentes

electrónicos, más específicamente de los componentes de vídeo del AUV.
Definir la forma de acople entre el tanque y el chasis.
Analizar la viabilidad de la adquisición de las piezas estándar, como el tanque, los acoples
y tornillos, para el nuevo panorama actual.
70
3.1.5. Investigaciones e innovaciones
3.1.5.1 Flotadores
Uno de los retos a los que nos enfrentamos en el diseño fue mantener el submarino con
flotabilidad neutra, esto se logra agregando elementos que tengan una densidad menor a la
del agua, para así disminuir la densidad general del sistema y lograr que el submarino se
mantenga suspendido en el agua sin la intervención de los motores, esto es, que no se hunda
ni empiece a flotar mientras está en reposo.
Cómo se mencionó antes, se necesita un material con densidad menor a la densidad del
agua para producir la flotabilidad necesaria para contrarrestar el peso del submarino. Para
poder escoger un material que pueda producir la flotabilidad se tuvieron en cuenta dos
polímeros que ya se han usado para esta aplicación, espuma de poliuretano y poliestireno
expandido (Icopor). Para escoger entre las opciones se comparó la densidad y la facilidad de
compra o y manufactura. Otra propiedad de gran importancia es la resistencia a la
compresión, ya que buscamos un material que pueda mantener un volumen constante a una
profundidad de 10 metros (el doble de la profundidad a la que se va a realizar la competencia).
Esto es, un material con una resistencia a la compresión mayor a 100 KPa. A continuación, se
muestran ambos materiales con los valores de las propiedades de interés, comparados
también con la espuma de referencia, la espuma R-3318 que vende la empresa BlueRobotics.
Propiedad Espuma de Poliuretano Poliestireno expandido Espuma R-3318

Densidad[kg/m3 ] 35 30 192
Resistencia a la 100 150 1800
compresión [kPa]
Precio [COP] 50.000 55.000 603.000
Cuadro 4. Comparación materiales y referencia.
El precio en cada espuma es el precio que costaría levantar una pesa de 10 kg,esto se hace
para tener un valor de referencia para poder comparar el costo que tendría levantar la misma
masa para cualquier material.
Las diferencias entre el poliestireno y el poliuretano son la facilidad de manufactura y
resistencia a la compresión. el poliestireno cumple los requisitos pero se encuentra en el limite
de la resistencia a la compresión, debido a esto se siguió el proceso de selección enfocados
en la espuma de poliestireno.
Después de escoger la espuma de poliuretano como el material principal para los flotadores
se realizó una investigación más profunda sobre este material y su compra y manufactura en el
país. Existen dos tipos principales de espuma de poliuretano, la espuma de celda abierta y de
celda cerrada. Al ser un producto celular el porcentaje de células cerradas tiene gran influencia
en la densidad, resistencia a la compresión y absorción de agua.a continuación se muestra la
comparación de las propiedades mecánicas para la espuma de poliuretano de celda abierta y
71
cerrada.
Figure 60. Comparación espuma de poliuretano celda cerrada y abierta.
72
teniendo claros los rangos de Densidad, resistencia a la compresión y resistencia al agua

se procedió a buscar proveedores. Se contactaron las empresas espumlatex y promoespuma,
en las cuales, después de hablar con los asesores se nos recomendó contactar la empresa
espumados S.A. Pero debido a que las principales empresas distribuidoras de espuma de
poliuretano en el país están enfocadas en las espumas para tapicería no se pudo conseguir
una espuma comercial que pueda cumpla con los requerimientos de resistencia al agua y a la
compresión.
3.1.5.2 Retos
Espuma
Debido a la dificultad para obtener la espuma requerida uno de los retos que tenemos
a corto plazo es encontrar un distribuidor que venda una espuma de poliuretano de celda
cerrada con los requerimientos de densidad, resistencia a la compresión y resistencia al agua
mostrados en la figura 11. Además de esto se planea trabajar en la caracterización de una
Espuma de poliuretano - Poliol e Isocianato. Caracterizar esta espuma de dos componentes
nos permitirá conocer su rango de operación, y variar factores como la temperatura de curado,
la humedad, la forma del recipiente y el porcentaje de la superficie en contacto con el aire
nos conocer los procesos que debemos modificar para óptimizar las propiedades requeridas,
para los flotadores y para futuras aplicaciones que se quieran realizar en Robocol o en la
Universidad que requieran espumas de poliuretano.
Optimización Topológica
Otro de los retos que tenemos para el tiempo de vacaciones y para el próximo semestre es
refinar el diseño del chasis por medio de herramientas computarizadas, para así reducir el peso
al máximo sin sacrificar la estabilidad estructural. Una de las herramientas que nos pueden
ayudar para el diseño del chasis es la optimización topológica, este tipo de optimización busca
distribuir el material en el dominio para encontrar la estructura. comenzando con una pieza
solida, las restricciones (apoyos), las condiciones de carga y el dominio donde se desarrollará
la pieza. Los métodos de homogenización son los más utilizados en la optimización topológica
y consisten en optimizar las zonas según su densidad. A densidad nula, se generan huecos
o cavidades, eliminando las zonas que no soportan esfuerzo estructural. Este método puede
necesitar de filtros o limitaciones para seguir cumpliendo con los requisitos de fuerza, torsión,
resistencia y no perder las propiedades para la que fue diseñada la pieza.
Martín Pelaez
Trabajar en este subsistema a lo largo del semestre presento un nuevo reto para mí. Es
mi primera vez siendo líder de un subsistema de un proyecto nuevo y adicional a esto se
presentó una situación muy complicada en el mundo que afecto la forma en la que
trabajan las personas y se despeñan en sus campos. Con esto me vi obligado a cambiar
73
mi forma de pensar y hacer las cosas frente al equipo. Durante este proceso de
aprendizaje en el equipo nos tuvimos que adaptar a trabajar con los recursos que se
tenían y comunicarse por los medios digitales no fue tan sencillo como esperaba, así
como mantener el equipo motivado. A pesar de esto, siento que todos los integrantes en
el equipo querían dar lo mejor de ellos inclusive en tiempos de alta demanda académica
y estrés. En un futuro deseo mantener mi trabajo más documentado y promover este
comportamiento en los demás miembros del grupo para facilitar la comunicación de
avances y promover lo longevidad del conocimiento e investigación y desarrollar una
mejor forma de atender las necesidades de los integrantes y promover más la
autosuficiencia en los miembros del equipo.
Felipe Pinzón
al comenzar el proyecto este semestre no esperaba que tocará terminar el semestre en
casa, con las complicaciones que eso le trae a cada miembro del equipo. Creo que uno
de mis mayores inconvenientes durante este semestre fue la demora en adaptarme al
trabajo desde casa, algo a lo que creo que aún no me adapto del todo. esto obviamente
redujo mi productividad y en consecuencia la del equipo, además de que afecta la
comunicación y la calidad de las entregas. A pesar de esto considero que pude tener
aprendizajes de calidad, como los aprendizajes técnicos de las espumas, las
herramientas computacionales y la comunicación con empresas distribuidoras. Pero
considero más importante el aprendizaje de como seguir encontrando motivación para
continuar con los compromisos del proyecto.
Ana Sofía Miranda

Como la nueva integrante en este subsistema y de la universidad como estudiante de
primer semestre, no pensé que el semestre fuera a terminar de esta manera, tuve
algunas dificultades en adaptarme en esto de la virtualización de la universidad además
de adaptarme a la universidad en las primeras semanas, pero me siento satisfecha con
mi progreso en este semestre y muy contenta de poder estar en este subsistema. En el
poco tiempo que es estado en el grupo me he esforzado en cumplir las tareas que me
han asignado de manera satisfactoria. En el futuro espero seguir contribuyendo al
equipo y poder aprender más conocimientos de parte de mis compañeros de semestres
más adelantados.
Juan Rosas
Este semestre, además de ser el primero en el que estoy en Robocol, fue uno en el que
las adversidades que se me presentaron afectaron de forma negativa mi rendimiento en
diversos aspectos. La situación que en mayor medida afectó mi rendimiento fue que me
vi obligado a trabajar en ambientes en los que se me dificultaba encontrar motivación
por lo que hacía. Esto término llevándome a tener un pésimo manejo del tiempo y una
percepción negativa de mi mismo por los bajos resultados que obtuve a lo largo del
semestre. Estos aspectos negativos se retro alimentaban entre sí al saber que me
faltaba motivación que no era capaz de conseguir por mi mismo y que no estaba
74
3.2 Subsistema Dinámica y control 3 SUBMARINO
actuando como la persona que me había presentado en la entrevista de admisión.

Después de haber cometido varios errores con el grupo y recibir por parte de ellos
consejos y tal ves más compresión de la que pudiera esperarse, he aprendido que para
trabajos futuros debo reflexionar y recordar los motivos de mis deberes; y a
comprometerme solo con lo que de verdad entiendo que puedo dar en ese momento y a
cumplir con lo que me comprometí de verdad.
3.2. Subsistema Dinámica y control
Juan David Medina Tobón - Ingeniería Electrónica (Capitán)
Jorge Felipe Gaviria Fierro - Ingeniería Electrónica y Eléctrica
Maria Alejandra Escalante - Ingeniería Electrónica y Sistemas
Jorge Luis Lamprea - Ingeniería Electrónica
Nicolás Grandas - Ingeniería Mecánica
Javier Hernán García - Matemáticas
3.2.2. Análisis del Submarino
Esta es la sección en la que menor cantidad de avances se han logrado. Para comenzar, lo
primero que se realizó fue una investigación sobre los modelos matemáticos que se utilizan
para los submarinos. El modelo que se escogió para esto es aquel presentado a continuación.
Este se escogió principalmente por dos razones. Primero, este es un modelo bastante
complejo, sin embargo dependiendo de nuestra implementación particular este se puede
simplificar bajo ciertos supuestos. Segundo, este es el mismo modelo que se utiliza en el
simulador de robótica de Gazebo, por lo cual se pueden encontrar los parámetros específicos
de nuestro submarino y suministrar dicha información al simulador y así lograr simular nuestro
diseño específico del submarino. De esto último se mencionará más en la sección de
Simulaciones en Gazebo. El modelo es, entonces, el siguiente:
M v̇ + C(v)v + D(v)v + g(s) = τ
La matriz M corresponde a la matriz de inercia. Este incluye los términos de masa MRB e
inercia añadida MA . Ambas matrices son diagonales y se denotan con diag.
75
M = MRB + MA
MRB = diag(m, m, m, Ix , Iy , Iz )
MA = diag(−Xv̇x , −Yv̇y , −Zv̇z , −Kω̇y , −Mω̇y , −Nω̇z )
La matriz C(v) incluye los de efectos de fuerzas de Coriolis y centrípeta y se expresa

mediante 2 matrices CRB (v) y CA (v).
C(v) = CRB (v) + CA (v)

 
0 0 0 0 mvz −mvy
 0
 0 0 −mvz 0 mvx  
 0 0 0 mvy −mvx 0 
 
CRB (v) = 
 0 mvz −mvy 0 Iz ωz −Iy ωy 

 
−mvz 0 mvx −Iz ωz 0 Ix ωx 
mvy −mvx 0 Iy ωy −Ix ωx 0
 
0 0 0 0 −Zv̇z vz Yv̇y vy
 0
 0 0 Zv̇z vz 0 −Xv̇x vx 

 0 0 0 −Yv̇y vy Xv̇x vx 0
 
CA (v) = 

 0 −Zv̇z vz Yv̇y vy 0 −Nω̇z vz Mω̇y ωy 

 
 Zv̇z vz 0 −Xv̇x vx Nω̇z ωz 0 −Kω̇x ωx 
−Yv̇y vy Xv̇x vx 0 −Mω̇y ωy Kω̇x ωx 0
La matriz D incluye los efectos de amortiguamiento hidrodinámico con términos lineales y

cuadráticos.
D(v) = diag(Xvx + X|vx |vx |vx |, Yvy + Y|vy |vy |vy |, Zvz + Z|vz |vz |vz |,
Kωx + K|ωx |ωx |ωx |, Mωy + M|ωy |ωy |ωy |, Nωz + N|ωz ωz |ωz |)
El vector g(s) representa las fuerzas restauradoras y momentos, debido a la gravedad y a

la flotabilidad.
 
(W − B)sinφy

 −(W − B)cosφy sinφx 

−(W − B)cosφy cosφx
 
g(s) = 
 
yB Bcosφy cosφx − zB Bcosφy sinφx 

 
 −zB Bsinφy − xB Bcosφy cosφx 
xB Bcosφy sinφx + yB Bsinφy
En total se cuenta entonces con 27 parámetros diferentes. Cada uno de estos se deben
estimar para lograr simular el submarino. Claro esta, algunas suposiciones se pueden realizar
76
dependiendo del problema que se va a atacar. Por ejemplo, los efectos de Coriolis se pueden
eliminar o se pueden considerar amortiguamientos únicamente lineales. Esto reduciría el
número de parámetros y también la complejidad del modelo. Aún así, estos parámetros se
deben calcular de alguna manera, así que inicialmente se planteó utilizar herramientas de
CFD (Dinámica de Fluidos Computacional) para aproximar estos valores. Sin embargo, este
primer intento ha probado ser bastante complicado de llevar a cabo principalmente debido a la
dificultad que conlleva realizar un análisis preciso de la dinámica de fluidos, en este caso del
agua. Por lo tanto, los únicos parámetros que se han aproximado son la masa m y los
momentos de inercia Ix , Iy e Iz , los cuales son fáciles de calcular con herramientas como
Autodesk Inventor. El programa con el que inicialmente se estaba intentando realizar el
cálculo de los demás parámetros era ANSYS Workbench, pero el problema probó ser
bastante complicado y no se han obtenido resultados. Actualmente, el grupo está en la
búsqueda de otros programas que puedan servir. Uno de estos es WAMIT, el cual es más
especializado y con el cual en la literatura ya se ha logrado los parámetros en otros
submarinos.
Otro aspecto importante dentro del análisis del Submarino es la configuración de los
motores. En la siguiente Figura 61 se muestra la ubicación de los motores en el diseño actual
del submarino.
Figure 61. Tomado de: http://www.ardusub.com/introduction/features.html
Los factores importantes incluyen una movilidad adecuada para nuestro requisitos, es decir,
que el robot sea capaz de moverse con 6 grados de libertad y de generar las fuerzas y torques
necesarios para moverse en tiempos mínimos. Esta parte del trabajo no se ha realizado aún
con detalle, sin embargo es de gran importancia y se debe tener en cuenta.
77
3.2.3. Algoritmos de Control
Para lograr que el submarino se mueva de manera autónoma dentro del agua se debe
implementar alguna estrategia de control. La primera estrategia que se implementó fue un
controlador con MPC (Model Predictive Control). Esta implementación actualmente se
encuentra en MATLAB, sin embargo uno de los trabajos futuros propuestos incluye pasarla a
Python para lograr implementarla fácilmente en ROS en conjunto con las demás
funcionalidades del submarino. Esta implementación utiliza un MPC lineal, por lo cual el
modelo presentado anteriormente se linealizó alrededor de un punto de operación y después
se discretizó con un tiempo de muestreo de 1 segundo. Con esto se implementó el
controlador utilizando como entradas las fuerzas y torques que actúan sobre el submarino y
se simuló su desempeño con diferentes trayectorias previamente indicadas y bajo las
restricciones de los motores. A continuación, se presentan los resultados que se obtuvieron.
Se presentan resultados sin considerar perturbaciones externas en las Figuras 62 y 64 y
considerando perturbaciones debido al oleaje en las Figuras 64 y 65.
Figure 62. Posición del robot con trayectoria de referencia 1
78
79
De estas 4 Figuras anteriores se puede ver que el controlador logra seguir las trayectorias
de manera adecuada. Se cree que este controlador puede ser bastante bueno para resolver
el problema del movimiento del submarino, sin embargo aún falta su verificación dentro del
simulador de Gazebo y la traducción de las fuerzas generadas por el controlador al empuje
que cada uno de los motores debe generar. El código para el MPC se puede encontrar en
GitHub haciendo click aquí: Repositorio en GitHub.
Finalmente, el equipo se encuentra actualmente implementando una estrategia de control
diferente basándose en un proyecto de tesis doctoral de un integrante del equipo. Esta aún se
encuentra en sus etapas iniciales, sin embargo se han logrado algunos resultados preliminares
en un modelo simplificado del submarino en 2 dimensiones.
3.2.4. Caracterización de Motores
Un trabajo también importante es tener una caracterización de los motores. Es decir,

queremos encontrar una función que indique el empuje generado por cada motor, de acuerdo
con la señal de control que estamos enviando. Esto es importante a la hora de realizar
simulaciones del robot, ya que podemos incluir curvas que simulen el comportamiento de los
motores que vamos a utilizar y simular con base en esto. Actualmente, el diseño del
submarino se plantea utilizando los motores T200 de Blue Robotics en conjunto con un ESC
(Electronic Speed Controller), asi que se pueden utilizar los datos recopilados para el
producto disponibles en la página de Blue Robotics. Estos son datos experimentales que
80
indican el empuje que el motor genera dependiendo del ancho de pulso que se envía. Así, lo
que se realizó en esta sección fue descargar estos datos y generar diferentes curvas que se
acomoden a los datos. Esto se implementó en un cuaderno de Jupyter en Python y el archivo
se encuentra en el repositorio del proyecto y también en los archivos compartidos en
Microsoft Teams para que los futuros integrantes puedan hacer uso de el. Se escogieron 2
tipos de curvas. La primera curva es una expresión como la que se presentan a continuación.
Es importante mencionar que en ambos casos un empuje negativo se refiere a la dirección de
reversa del motor, mientras que un empuje positivo es aquel en la dirección hacia adelante.
Empuje = RotorConstant · x· | x |
El parámetro RotorConstant depende del motor, por lo cual al ajustar esta curva a los
datos del motor se encuentra este parámetro, el cual después es suministrado al simulador. A
continuación, se presentan los resultados para la curva encontrada.
Figure 66. Curva 1 y Datos Experimentales
En la Figura 66 se muestran los datos en azul y la curva estimada en rojo. Es importante

mencionar que se utilizó un método de mínimos cuadrados para ajustar la curva a los datos.
Por lo tanto, el parámetro Rotor Constant que se va a utilizar para la simulación de los motores
es 3.913 396 32 × 10−5 .
La anterior curva presenta dos problemas. Primero, esta no considera la zona muerta de los
motores. Esta zona se puede ver en los datos correspondientes a anchos de pulso cercanos
a 1500 µs y corresponde al intervalo de anchos de pulso en el cual el motor no genera ningún
empuje. Segundo, esta curva tampoco considera que el empuje depende de la dirección en la
81
que se está generando el empuje. En estos motores el empuje que alcanza en la dirección de
reversa es menor a aquel en la dirección hacia adelante. Debido a esto, se escogió utilizar una
segunda curva que incluyera esta zona muerta de los motores y también usara dos parámetros
para cada dirección. La expresión para esta segunda curva es la siguiente:

RotorConstantL · x · |x| x · |x| ≤ ∆L


Empuje = RotorConstantR · x · |x| x · |x| ≥ ∆R


0 dlc
En esta expresión se pueden identificar 2 parámetros ∆ y otros 2 indicados con

RotorConstant. Los primeros indican la zona muerta del motor. Es decir, en el intervalo
delimitado por ∆L a la izquierda y ∆R a la derecha del punto central de 1500 µs el empuje del
motor es 0. Afuera de esta región, el empuje está dado por una expresión similar a la de la
curva anterior, solo que ahora se utiliza una función para la región de la derecha y otra para la
parte de la izquierda, las cuales corresponden a la dirección de reversa y hacia adelante,
respectivamente. Por lo tanto, se tienen los otros 2 parámetros de RotorConstantR y
RotorConstantL para generar curvas diferentes en cada dirección. Los parámetros ∆ se
encontraron utilizando los datos y verificando dentro de que valores el empuje registrado era
0. Los otros 2 se estimaron realizando un ajuste de curva por el método de mínimos
cuadrados de manera similar al caso anterior. A continuación, se presentan los resultados
para esta segunda curva.
Figure 67. Curva 2 y Datos Experimentales
En la Figura 67 se puede ver la curva estimada en rojo junto con los datos experimentales
82
en azul. En esta se puede apreciar que la curva se ajusta mejor a los datos y también logra
incluir la zona muerta. Por lo tanto, los parámetros del motor que se le suministran al simulador
son los siguientes:
RotorConstantL = 3.409 509 7 × 10−5 RotorConstantR = 4.420 218 × 10−5
El cuaderno de Jupyter con la implementación para estimar las curvas se puede encontrar
en el siguiente link: Cuaderno de Jupyter para Estimación de Curvas
3.2.5. Simulaciones de Gazebo
Gazebo es un simulador de robótica 3D de código abierto. Este cuenta con soporte de

renderización, simulación de sensores, integración con ROS y una gran cantidad de
funcionalidades adicionales que se pueden agregar por medio de plugins. Uno de estos
paquetes adicionales es UUV Simulator que permite simular vehículos sumergidos dentro del
agua. Este utiliza el mismo modelo presentado en la primera sección para el movimiento del
robot. Otra ventaja con la que cuenta el programa es que permite agregar una gran cantidad
de sensores, como por ejemplo cámaras o acelerómetros. Estos no solo son simulaciones de
los sensores, sino que también están basados en sensores que se pueden comprar
físicamente. Por lo tanto, esta herramienta también permite evaluar diferentes sensores antes
de realizar la compra. Por último, dentro del simulador también se pueden crear toda clase de
escenarios como el que se muestra en la siguiente Figura.
Figure 68. Submarino RexRov2 explorando un barco hundido
En este Figura 68 se puede ver la simulación de un submarino (RexRov2), en la cual este

puede explorar un barco hundido. Se cree que esto va a ser de gran utilidad para prepararse
83
para la competencia, ya que se puede crear el escenario específico en el cual el submarino va

a llevar a cabo la tarea.
El trabajo principal que se ha venido realizando en conjunto con el simulador es aquel
de lograr seguir la posición y orientación del robot mediante sensores. A continuación, en la
Figura 69 se presentan algunos resultados preliminares, sin embargo este trabajo aún no se ha
terminado hasta la fecha. Este trabajo intenta resolver el problema mediante el uso de varios
sensores IMU (Unidad de medición inercial) y la teoría de fusión de sensores, pero no se han
logrado obtener buenos resultados y a la implementación aún le falta considerar las fuerzas
externas que actúan sobre el submarino, como por ejemplo el empuje generado por lo motores
o las perturbaciones debido a las olas. En esto se continuará trabajando.
Figure 69. Posición en x del robot
En la Figura 69 se puede ver que se tiene un error en la medida de aproximadamente 5cm,

por lo cual esta implementación aún no es suficiente para lograr seguir la posición y orientación
del robot. Es importante mencionar que, aún cuando el funcionamiento no es el esperado, este
trabajo aportó bastante para manejar mejor las herramientas de Gazebo y UUV Simulator.
Nuevamente, este trabajo se encuentra en un repositorio de GitHub en el siguiente link:
Repositorio del Submarino. Cabe recalcar que este trabajo hasta la fecha cuenta con varios
errores y no contiene documentación.
1. La implementación actual del controlador por MPC es en Matlab, asi que se quiere
traducir este trabajo a Python para que pueda ser implementado en ROS. Otra opción
sería explorar alternativas como el toolbox de ROS de Matlab que permite comunicarse
84
con ROS. Esto también es un trabajo futuro a realizar, ya que hasta el momento no se
ha utilizado ROS en conjunto con Matlab y puede que ofrezca ventajas frente a una
implementación en Python. También hace falta traducir las fuerzas indicadas por el
controlador al empuje que cada motor debe generar.
2. Terminar la implementación del controlador con el trabajo de la tesis doctoral de un

integrante del equipo. Este método ofrece ventajas frente a otros algoritmos de control,
ya que no requiere de sistemas lineales, como por ejemplo si lo requiere la
implementación actual del MPC.
3. Continuar con la investigación y las implementaciones en Gazebo para realizar un

seguimiento de la posición y orientación del submarino por medio de sensores. Esto es
de suma importancia, ya que se requiere conocer con alta precisión y exactitud la
ubicación del robot para llevar a cabo las diferentes tareas. Para esto se cree que
Gazebo ofrece una amplia gama de alternativas. Este simulador permite simular una
gran variedad de sensores, así que también se considera como trabajo futuro obtener un
mejor manejo de esta herramienta.
4. El simulador de Gazebo permite simular el robot dentro de situaciones variadas. Por

ejemplo, se puede crear el escenario de las competencias en las que participará el
equipo. Esto también se cree que es de gran importancia, ya que permitiría evaluar el
desempeño del submarino dentro de la tarea específica de la competencia en
simulación sin necesidad de probarlo físicamente.
5. Utilizar aprendizaje por refuerzo para resolver el problema del control del submarino.
6. Explorar la posibilidad que herramientas como WAMIT puedan brindar para caracterizar
el submarino y así lograr iterar sobre el diseño y proponer mejoras.
7. Realizar tutoriales sobre lo aprendido de Gazebo y UUV Simulator para que aprender
a usar estas herramientas sea más eficiente para nuevos integrantes del equipo. Estas
plataformas han probado ser bastante útiles, sin embargo hay una falta de recursos y
tutoriales para aprender a usar las herramientas, en especial al comienzo.
8. Detallar el proceso para escoger la configuración de los motores. Esto incluye la cantidad
de motores y su ubicación y orientación en el robot. Esto con el objetivo de escoger la
mejor configuración posible para las tareas que el submarino llevará a cabo.
Sin duda el mayor aprendizaje ha sido desde el lado de simulación. Debido a la crisis
que hasta la fecha se continúa viviendo del COVID-19, ha sido obligatorio la búsqueda de
alternativas para diseñar el submarino. La compra de componentes y la fabricación del robot
puede tomar varios meses aún, sin embargo dentro del grupo no se puede frenar simplemente
por esto. Por lo tanto, decidimos intentar hacer todo lo posible para simular de la mejor manera
85
el submarino y así poder implementar todo tipo de funcionalidades. Lo que se encontró es que
existen grandes variedades de herramientas con las cuales se puede trabajar y se ha logrado
avanzar bastante gracias a dichas herramientas. Aquí entonces lo importante es escoger de
manera adecuada los programas que se van a utilizar. Algunos son más especializados y
permiten resolver problemas complejos, mientras que otros hacen posible la evaluación de
diferentes tipos de funcionalidades.
A continuación se presentan algunas reflexiones personales de los integrantes del grupo.
Juan David Medina Tobón: En lo personal esta ha sido una oportunidad para aprender
algunas cosas que nunca he tenido la oportunidad de aprender. Es la primera vez en mi vida
que me he puesto en una posición de liderazgo y debo confesar que no me parece para nada
fácil. Esta es una labor muy importante para el adecuado funcionamiento del equipo. Se debe
estar pendiente de cada integrante, saber como están y en que andan, más aún durante esta
época de crisis del COVID-19. Aún así, lo que más difícil me ha parecido a mi es también estar
pendiente de uno mismo. Como soy el capitán del equipo, nadie va a tomar el papel de estar
pendiente, de preguntarme en que ando y saber como estoy. Es por eso que dicha labor debe
ser realizada por la misma persona y, en mi opinión, puede no ser fácil.
86
4 COMPLEMENTARIOS
4. Complementarios
87
4.1 Subsistema Potencia 4 COMPLEMENTARIOS
4.1. Subsistema Potencia
Franz Luepke - Ingeniería Electrónica (Capitán)
María Alejandra Escalante - Ingeniería Electrónica
Juan David Serrano - Ingeniería Electrónica
Jorge Chaparro - Ingeniería Electrónica
4.1.2. Creación del subsistema
En este año se creó una rama independiente encargada de alimentar los diferentes
sistemas del rover y del submarino, si bien esta rama ya existía, ya que sin ella no se puede
pensar en sistemas electrónicos, no se tenía como un subsistema independiente con el
objetivo único de alimentar de manera adecuada los diferentes prototipos.
4.1.3. Definir objetivos
En el grupo de potencia, al ser un grupo nuevo, se tuvieron que definir muy bien los objetivos
y los alcances del mismo. Estos se enfocaron primeramente en conocer muy bien los sistemas
actuales y su implementación, anotar las cosas buenas de estos, detectar fallas, pensar en los
sistemas faltantes y con esta información empezar a planear nuevos sistemas que lleven a una
mejoría en la alimentación. Los objetivos principales del grupo son los siguientes:
Realizar sistemas de alimentación muy seguros tanto para el operario como para el
prototipo y sus componentes.
Estimar las capacidades, cargas, voltajes y demás parámetros pertinentes para cada
prototipo con el fin de diseñar con esos lineamientos en mente.
Quitar la dependencia de equipos de laboratorio o comerciales para la correcta carga,

descarga, almacenamiento y uso de los sistemas de alimentación.
4.1.4. Primeras Ideas BMS (Battery Management System)
Como primeras ideas de diseño se quieren implementar BMS (Battery Management

System) el cual consiste en un sistema que permite cargar, descargar, balancear y proteger
las pilas de manera eficiente y segura. El diagrama inicial propuesto se muestra en la figura
70.
88
4.1 Subsistema Potencia 4 COMPLEMENTARIOS
Figure 70. Diagrama de bloques de BMS.
Realizar esquemáticos y simulaciones de primeras iteraciones de BMS.
Diseñar PCBs con los esquemáticos y simulaciones realizados.
Realizar las pruebas de carga y descarga posibles si la situación del momento lo permite.
El error más grande de este grupo puede ser el no existir anteriormente como un
subsistema independiente que se encargue exclusivamente de esto, ya que en el tiempo que
se ha investigado, aprendido y trabajado se ha podido ver la absoluta necesidad de contar con
este grupo y de como pueden mejorar las cosas con la implementación de los sistemas
planteados.
89
4.2 Subsistema Visión 4 COMPLEMENTARIOS
4.2. Subsistema Visión
Sebastián Sierra Alarcón - Ingeniería Electrónica (Capitán)
Valentina Parra Garcés - Ingeniería Electrónica
Alvin David Gregory Tatis - Ingeníeria Electrónica y Biomédica
Jose Cristobal Arroyo - Ingeniería Electrónica
Paulina Acosta -Ingeníeria Electrónica y Sistemas
Juan Sebastian Alegria - Ingeniería Electrónica
Como primera medida, este semestre se conformo oficialmente este subsistema, cuyo
enfoque se encuentra orientado a la creación del sistema de visión del rover y del submarino
teniendo en cuenta las restricciones que se manejan en cada competencia y el nivel
computacional permitido por la Jetson TX2.
Por un lado, se realizaron practicas y pruebas directas sobre ROS, esto debido a que la
mayoría de los integrantes no tenían un conocimiento avanzado y cada vez que se deseaba
realizar una implementación se perdía un poco de tiempo.
Se trabajo en el uso de la cámara de profundidad y en la forma en la cual se puede extraer
la información proveniente de ella y articularla con la parte RGB. Para esto se comenzó
trabajando usando sobre el SDK propio de intel y en matlab (fig. 71) en miras a hacer la
transición a un nodo de ROS con una funcionalidad similar.
90
Figure 71. PointCloud Intel Depth en Matlab
Se implemento una selección de las cámaras existentes en Robocol. Con el fin de enfocar
el trabajo en aquellas que nos ofrecieran una mayor utilidad, se optó por el uso de cámaras
USB HD, las cámaras intel y las camaras IP (Foscam y Ezviz)
Para poder trabajar a distancia se consolido la creación de una red local con ayuda de
Hamachi permitiendo compartir información a través de nodos debido a que cada integrante
del equipo tenia una tecnología diferente sobre la cual se encuentra trabajando.
Finalmente, tras la separación del subsistema de Lunabotics, se incorporaron tres nuevos
integrantes al equipo, a los cuales se les realizó una capacitación express en temas
relacionados al manejo de imágenes, técnicas de segmentación y principios de machine
learning.
4.2.3. Objetivos establecidos
Complementar el sistema existente del tracking del rover a partir del uso de la cámara
intel T265
Brindar al subsistema del brazo un algoritmo de reconocimiento de objetos (distancia,

forma y color) con precisión que permita mejorar la cinemática existente
Analizar todo el entorno del rover y del submarino (consolidar un sistema de visión
global) en miras a mejorar la autónoma de ambos proyectos y considerar una
navegación reactiva.
91
4.2.4. Software/Hardware
Como elementos principales en el desarrollo del sistema de visión se tienen las cámaras
mediantes las cuales observamos el comportamiento del Rover:
Cámara Intel T265 de Tracking (fig. 73)
Cámara Intel Depth D435 (fig. 72)
Cámara HKVision
Cámaras IP: Foscam, Ezviz y EasyN (fig. 74)
Jetson TX2
Figure 72. Camara Intel D435 Depth
92
Figure 73. Cámara Intel 7265 Tracking
Figure 74. Cámaras IP
Por otro lado, se utilizó python para crear un nuevo programa de visualización del rover. Se
pensó así ya que es totalmente necesario visualizar el prototipo en todo momento e incluirlo
como una pestaña en el programa principal volvería el proceso más difícil. Los elementos
necesarios para crear esta interfaz fueron:
93
4.3 Subsistema Interfaz 4 COMPLEMENTARIOS
Utilización de librería PyQT
ROS
Hamachi
Open CV
Tensorflow
Segmentación de objetos de interés utilizando cámaras RGB, utilizando como localizador

espacial la cámara depth, para conocer la forma geométrica del objeto en cuestión.
Entrenamiento de algorítmos capaces de reconocer ambientes, con el fin de tener un

robot totalmente autónomo en campo.
Obtención de cámaras RGB con un acceso óptimo para conexión IP.
Relación con demás departamentos con grupos de investigación relacionados con Visión
Artificial, tales como Ingeniería de Sistemas e Ingeniería Biomédica.
Creación de la Vision Interface, para interacción con las cámaras y los algorítmos
planteados.
Durante el tiempo de creación del grupo de visión, nos enfrentamos a una variedad de
nuevas tecnologías que se convirtieron en retos de aprendizaje. El uso de este nuevo hardware,
aunque esencial, nos llevó a dedicarle un tiempo considerado en entender su funcionamiento
y cómo implementarlo utilizando ROS.
Parte del aprendizaje adquirido en el equipo, se ha basado en el manejo de software para
el entrenamiento de los modelos necesarios para suplir con las tareas de visión del Rover.
Entre ello se encuentra librerías de ML en Python, ROS y herramientas para construcción de
interfaz.
Dada la virtualidad, el trabajo en la Jetson TX2 se vio limitado dado el poco acceso que se
tenía. Para sobrellevar este problema, realiamos conexión via Hamachi con el grupo, pudiendo
satisfactoriamente conectarnos a la Jetson y trabajar remotamente.
4.3. Subsistema Interfaz
Franz Luepke - Ingeniería Electrónica (Capitán)
94
Álvaro Plata - Ingeniería Sistemas
Ángela Vargas - Ingeniería Electrónica y Sistemas
Brenda Barahona - Ingeniería Sistemas e Industrial
En términos de los avances de este año en el sistema de la interfaz comenzó con forma
este subsistema, ya que no existía como grupo hasta este año, para realizar las tareas de
este subsistema de manera correcta primero se comenzó por realizar una documentación del
interfaz, analizarla, ver sus funcionalidades, sus fallas y ver que mejoras se podrían realizar, a
continuación se presenta la documentación realizada.
4.3.3. Introducción a documentación
En la siguiente sección se muestra la interfaz actual, dando una breve explicación de cada
una de la pestañas de la misma y explicando sus funciones, sus fallas y las partes que están
inhabilitadas. Esta interfaz se desarrolló en Django y luego se incluyó como un nodo de ROS
y es la mayor encargada de la interacción con el rover. Aunque cuenta de muchas
funcionalidades aún carece de muchas otras que son esenciales. Requiere cambios en tanto
agregar, eliminar cosas y de organización.
Entre las ventajas de esta interfaz está que al ser una página web es accesible fácilmente a
través de cualquier dispositivo después de que el servidor está corriendo y de poder accedida
desde varios dispositivos al mismo tiempo.
4.3.4. Herramientas Necesarias para correr el servidor
Para correr la interfaz el servidor de la misma requieree tener las siguientes herramientas
instaladas y funcionales, es necesario revisar si hay algún requerimiento adicional que no esté
mencionado. Los clientes solo requieren conectarse a la red y poder solicitar un servicio
HTTP (a través de un navegador comúnmente) colocando la dirección IP del servidor con su
respectivo puerto.
4.3.5. Herramientas
ROS (Melodic recomendado)
• http://wiki.ros.org/melodic
Django Channels (versión ....)
• https://channels.readthedocs.io/en/latest/
95
Simple JSON
• https://simplejson.readthedocs.io/en/latest/
Numpy
• https://numpy.org/
Redis
• https://redis.io/
4.3.6. Pestaña de Tracción
Permite controlar el movimiento del rover por medio de un joystick virtual, tiene un deslizador
de sensibilidad para definir la velocidad máxima del joystick. Tiene 2 botones para definir el
método de comunicación (si es por WiFi o por RF), esta función está actualmente deshabilitada
aunque se usó en algún momento con una configuración anterior del rover. Los datos que
entrega son los de odometría (posición relativa al punto de encendido del rover en x y en y,
esto lo hace por medio de los datos de la IMU (Inertial Mesaurement Unit) la cual tiene un
acelerómetro, un giroscopio y un magnetómetro para devolver el norte, la velocidad lineal y
angular del rover. Por último cuenta con la velocidad en RPM enviada del lado izquierdo y
derecho del rover que vienen dadas por la posición del joystick así como la sensibilidad al
tener un joystick físico conectado al nodo de ROS. Los campos de PID eran de prueba para
configurar los controladores y hay que quitarlos.
96
Figure 75. Pestaña de tracción. Permite moverlo y obtener información relacionada con el
movimiento.
97
4.3.7. Pestaña de Autonomía
Esta pestaña fue diseñada para la movilidad autónoma del rover, tiene el mapa de Bogotá
cargado por defecto (aunque en la imagen no aparece) y muestra la ubicación del rover en
Bogotá dada por el GPS cuando este entrega los datos, actualmente el GPS no se ha migrado
a ROS pero se hará. Además de eso permite seleccionar varios puntos de llegada dada por
sus coordenadas (latitud y longitud), botones Start y Continue para empezar o seguir con la
siguiente trayectoria de la lista y un botón de STOP de emergencia que se encargaría de enviar
una gran cantidad de comandos de parada al rover para asegurar que este se detenga.
Figure 76. Pestaña de autonomía. Permite hacer un tracking del rover por medio de GPS para
conocer su ubicación actual y asignar puntos de llegada con coordenadas.
98
4.3.8. Pestaña de Brazo Robótico
En esta sección se tienen varios botones que permiten controlar cada uno de las junturas
(joints) del brazo por separado (esto es cinemática directa) el brazo que se muestra en la figura
77 es solo una referencia para saber que el número de la juntura que se está moviendo, los
botones lo mueven en el sentido de la manecillas del reloj o en contra. Además de esto se tiene
una retroalimentación del ángulo de cada juntura en grados e igual un deslizador que permite
abrir y cerrar la garra (end effector).
Figure 77. Pestaña del brazo robótico. Permite controlar el brazo de manera remota y conocer
su estado.
99
4.3.9. Pestaña de Sensórica
En la pestaña de sensórica se tiene actualmente los datos de humedad (en %RH),

temperatura (en ◦C), concetración de hidrógeno y de metano (en P P M ). Esta pestaña es la
que más requiere trabajo ya que se necesita comunicarse con una base de datos que
contiene información de las muestras al ser medidas.
Figure 78. Pestaña de sensórica. Permite obtener datos de muestras recolectadas.
100
4.3.10. Pestaña de Estatus del Rover
La sección del estatus del rover muestra la información del voltaje de las pilas (cambie de
color de verde a amarillo y a rojo al descargarse la pila). Así como la corriente y RPM en
cada uno de los motores de tracción, de igual manera permite habilitar o deshabilitar la salida
de cada motor de manera independiente, esto con el objetivo de realizar pruebas a ciertos
motores, o desconectar alguno (o varios) en caso de fallas. El botón de Enable All no está
funcionando pero se quiere este apague o prenda todas las llantas con un solo click. (Puede
también incluirse uno de Disable All)
Figure 79. Pestaña de estatus del rover. Permite conocer el estado de las pilas, la corriente
consumida por los motores y la velocidad de cada llanta. Además también se puede habilitar y
deshabilitar los drivers de cada llanta de manera individual.
Arreglar los problemas actuales de la página web del rover.
Conectarse con la base datos (a definir) del subsistema de sensórica y agregar los
elementos necesarios para este subsistema, así como organizar la pestaña de la mejor
manera con la información actual y la nueva.
Permitir que la página sea responsive de manera que se pueda abrir en una tablet o
celular de manera cómoda y usar toda su funcionalidad.
Revisar las funciones inactivas y removerlas, arreglarlas o terminarlas según sea el caso.
101
Hablar con el equipo de visión y definir si la interfaz tendrá cámaras, o al menos un acceso
a ellas.
Hablar con el equipo de tracción y de brazo para añadir las funcionalidades faltantes a la
interfaz.
Empezar con la página web del submarino definiendo sus requerimientos y la forma en
que se realizará.
102
5 LUNABOTICS
5. Lunabotics
103
5.1 Subsistema Lunabotics 5 LUNABOTICS
5.1. Subsistema Lunabotics
Jorge Alfredo Chaparro Gamboa - Departamento de Ingeniería Eléctrica y Electrónica

(Capitán)
Paulina Acosta - Departamento de Ingeniería Eléctrica y Electrónica (Capitana)
Daniel Villar- Departamento de Ingeniería Eléctrica y Electrónica
David Sanchez- Departamento de Ingeniería Eléctrica y Electrónica
Cristobal Arroyo- Departamento de Ingeniería Eléctrica y Electrónica
Jorge Lamprea- Departamento de Ingeniería Eléctrica y Electrónica
Juan Camilo Gutiérrez González - Departamento de Ingeniería Eléctrica y Electrónica
David Andrés Cáliz - Departamento de Ingeniería Eléctrica y Electrónica
Álvaro Daniel Plata Márquez - Departamento de Ingeniería de Sistemas y Computación
Juan Sebastián Alegría Zúñiga - Departamento de Ingeniería de Sistemas y Computación
Ana Sofía Miranda Ramírez - Departamento de Ingeniería Mecánica
Daniel Ricardo Barcasnegras Moreno - Departamento de Ingeniería Mecánica
Este subsistema fue creado con el objetivo de capacitar a los nuevos integrantes de
Robocol. En la bodega del departamento de mecanica se encontró el robot que participo en la
competencia Lunabotics: Mining Competition de la NASA en el año 2013. Dado que el robot
ya estaba prácticamente armado y contenía muchos de elementos para su funcionamientos,
se procedió a crear un reto para los nuevos integrantes que consistía entender como
funcionaba para poder reparar o acuatizar la parte mecánica y electrónica del robot.
5.1.2. Drivers
Propósito y funcionamiento de un driver: ya que el control de todo el robot se está

haciendo con un microcontrolador, en este caso un Arduino, no podemos alimentar los
motores con las señales lógicas que este nos proporciona, no solo porque son de 5V y no de
12V como piden los motores para operar, sino porque la máxima corriente que puede
suministrar el microcontrolador a lo largo de todos sus pines es 200mA, cuando cada motor
puede llegar a consumir 10A o más. Es por esto que recurrimos a utilizar drivers, los cuales
reciben esta señal lógica por parte del Arduino y la convierten en encendidos o apagados del
paso de corriente de la fuente de alimentación de 12V a los motores u actuadores, diseñados
104
para aguantar esta corriente y en este caso incluso mucho más.
Para este caso particular son drivers denominados “puentes H”, esto es debido a como está
estructurado internamente, que de manera simplificada:
Figure 80. Drivers "Puentes H".
Ya que no solo debemos controlar el paso o no de corriente a través de las terminales sino
también la dirección en la que esta fluye, son necesarias 2 señales de entrada para su control.
Contenido y clasificación: son un total de 5 PCBs fabricadas de la misma manera con

las únicas diferencias siendo el color de los relay. 2 de ellas están conectadas entre ellas y
corresponden a los drivers de los actuadores lineales debido a que pueden compartir la
entrada de alimentación al no consumir una gran cantidad de corriente. Uno de los 3 restantes
tiene como diferencia 2 huecos adicionales que se le hicieron en la PCB, esto para montarle
un disipador de calor al IC, incluso hay restos de pasta térmica en su superficie. Este driver
corresponde al del motor de la rueda excavadora en tanto el consumo de corriente por el
torque generado es considerablemente mayor al del resto de motores de solo movimiento. No
hay distinción entre izquierda y derecha de cada motor de movimiento por lo que pueden
usarse para cualquiera de los 2, lo mismo aplica para los actuadores lineales.
Otros posibles usos: en caso necesario, estos drivers podrían utilizarse para controlar
algún dispositivo que pueda funcionar con un flujo de corriente reversible entre ambas
terminales, con un voltaje de operación en el intervalo para el que fue diseñado (ver siguiente
página de especificaciones) y siempre y cuando no sobrepase la corriente máxima. Además,
para altos consumos de corriente es necesario el correspondiente disipador de calor sobre el
IC para evitar un probable daño permanente.
Drivers STmicro VNH3ASP30: cada PCB contiene un driver de puente H, conexiones de
alta potencia de entrada y salida, un header de pines 4x2 para las conexiones lógicas y un
relevo que controla la entrada de alta potencia al controlador. Cada motor es controlado por
una de estas placas.
105
Voltaje de operación diseñado: 5.5v – 16v
Voltaje de operación funcional: 5v – 18v
Nivel lógico: 5v
Corriente máxima: 30A* (con disipación de calor adecuada)
Protección de sobre temperatura: 150°C
Frecuencia máxima de la entrada PWM: 20kHz
Descripción de los pines lógicos:
1. Enable
2. Direction input A
3. Direction input B
4. GND
5. Current sense
6. PWM in
7. Enable
8. Power relay
Figure 81. Drivers STmicro VNH3ASP30.
106
Notas: los pines 1 y 7 están interconectados, el controlador se habilita con un pull-up a

alguno de estos, de lo contrario el driver no funcionará. En caso de una falla, el driver llevará a
low el pin y se deshabilitará hasta que se retire y se vuelva a colocar el voltaje en el pin. Las
entradas de dirección (pines 2 y 3) funcionan según la siguiente lógica:
*El estado stop hace cortocircuito entre las conexiones de salida para frenar el motor, esta
es una “dirección” permitida del driver.
El pin de medición de corriente (5) genera un voltaje proporcional a la corriente que fluye a
través del controlador y se debe conectar con una resistencia a tierra para medirlo
correctamente con una entrada análoga de un microcontrolador. El ciclo de trabajo de la señal
de PWM (6) controla proporcionalmente la velocidad del motor. Esta señal debe ser de al
menos 3v para que el controlador funcione consistentemente. Cuando los pines de dirección
pasan al estado de stop, el motor se detiene de inmediato ignorando esta entrada. Cuando la
señal baja a 0v sin cambiar los pines de dirección el motor desacelera libremente. La entrada
del relevo (8) también es una entrada lógica y solo se requiere una señal de 5v para activar el
relevo el cual controla la entrada de alta potencia del controlador.
5.1.3. Interfaz
Introducción: en el marco del proyecto “Lunabotics”, dentro el subsistema de Ingeniería

de Sistemas y Computación, desarrollamos una aplicación móvil para Android y iOS, que
funciona como interfaz visual del robot. La función principal de ésta consiste en permitirle a un
usuario controlar los movimientos y funciones principales del Rover desarrollado por los
demás subsistemas, a través de un medio sencillo e intuitivo.
En breve, se pretende exponer el proceso de creación de esta aplicación, sus

componentes principales, herramientas de desarrollo utilizadas, entre otros aspectos que la
conforman.
Herramientas de desarrollo utilizadas: El primer paso para el desarrollo de la aplicación

era decidir qué herramientas se utilizarían para lograrlo. Para esto, se optó por trabajar
principalmente en Flutter y Android Studio.
Flutter: ¿Qué es Flutter?: Flutter es un kit de herramientas de interfaz de usuario, creado
107
por Google, para desarrollar aplicaciones nativas para dispositivos móviles Android y iOS,
web y de escritorio desde una única base de código. Esta es la característica más atractiva de
Flutter, que desde un único código se autogenera una aplicación diferente para una gran
cantidad de dispositivos y plataformas, los cuales usan sistemas operativos, frameworks y
lenguajes diferentes.
Anteriormente, si quisiéramos ejecutar una aplicación en varios dispositivos, tendríamos

que desarrollar la misma aplicación específicamente para cada plataforma, por lo que Flutter
es una herramienta que ahorra mucho tiempo en el desarrollo de nuestro proyecto.
A continuación, enumeramos unas de las principales características de Flutter, al igual que

las razones para construir nuestra interfaz con esta herramienta.
¿Por qué Flutter?: con Flutter podemos crear nuestra aplicación para Android y iOS, al
mismo tiempo, con una única base de código.
El proceso de creación de interfaces con Flutter es sencillo e intuitivo, gracias a su sistema

de Widgets, donde cada widget es una declaración inmutable de parte de la interfaz de
usuario.
Es de código abierto, y tiene una gran comunidad creciente de desarrolladores que lo

utilizan y aportan a su crecimiento. Flutter cuenta con un sistema de paquetes, que
básicamente son código funcional creado por cualquier desarrollador, y que ha compartido
con el resto de la comunidad. De esta manera, si llegáramos a necesitar esta funcionalidad
que este desarrollador ya ha creado, simplemente debemos importarla a nuestro proyecto y
podremos utilizarla sin problema, lo que ahorra una gran cantidad de tiempo.
Otra gran característica de Flutter es su Hot Reload. Esta es una funcionalidad que
permite compilar el código que hemos escrito de manera casi inmediata y ver los cambios
realizados directamente en el dispositivo móvil o en un emulador. Esto es muy importante, ya
que, en el desarrollo convencional de aplicaciones nativas, este proceso de compilación
puede llegar a ser bastante demorado, al tener que exportar la aplicación, instalarla, y hacer
una serie de pasos adicionales. “La funcionalidad hot reload de Flutter te ayuda a rápida y
fácilmente experimentar, construir UIS, añadir funcionalidades y arreglar bugs. Hot reload
trabaja inyectando ficheros de código fuente actualizados en la Máquina Virtual (VM) Dart en
ejecución.” (https://flutter-es.io/docs/development/tools/hot-reload).
Resumen técnico de Flutter: https://flutter-es.io/docs/resources/technical-overview
¿Cómo funciona Flutter?: Flutter se basa en un sistema de Widgets. Todo dentro de una
108
aplicación Flutter es un widget, desde un simple texto, botones o cualquier diseño. Estos
widgets se organizan en un orden jerárquico para mostrarse en la pantalla. Es decir, un widget
puede componerse de varios widgets, y éstos a la vez de más widgets. Es así cómo se
estructuran las aplicaciones, en una composición de widgets, de la que obtenemos una
organización jerárquica.
En el siguiente ejemplo se puede ver este concepto. Esta es la representación visual de la

composición de una app básica en Flutter. En este caso, está compuesta de un Widget Scaffold,
que es un Widget de diseño (para situar elementos en la pantalla), que está compuesto de dos
Widgets, un AppBar y un Row (Fila). El AppBar se compone de un Widget de Texto, y el Row
está compuesto por Widgets Image. De esta manera podemos diseñar nuestra aplicación y
agregarle más y más elementos.
Figure 82. ¿Cómo funciona Flutter?
Existe una clasificación general para los Widgets en Flutter. Estos pueden ser Stateless
Widgets (Widgets sin estado) o Stateful Widgets (Widgets con estado). De esta manera
diferenciamos los widgets que tendrán una funcionalidad dentro de la aplicación (con estado)
y los que generalmente sólo desplegarán información (sin estado). Por ejemplo, un Stateless
widget podría ser un widget imagen o texto, y un Stateful Widget un botón o un slider. El
estado del Widget nos permitirá asignarle su funcionalidad.
Dart es el lenguaje de programación con el que se desarrollan las aplicaciones en Flutter.

Éste fue creado por Google, tiene una gran aceptación en la comunidad, por lo que su uso
está creciendo rápidamente, y es muy similar a muchos otros lenguajes orientados a objetos.
109
Debido a esto, su aprendizaje resulta bastante sencillo si ya se ha trabajado con lenguajes

como Java o C, entre otros.
Android Studio es el entorno de desarrollo integrado (IDE) oficial para el desarrollo de

apps para Android, es decir, es el programa en el cual podemos escribir código en Dart y
crear nuestras aplicaciones Flutter.
Para crear una aplicación con este framework, Google recomienda usar Android Studio o
Visual Studio Code, un IDE desarrollado por Microsoft. Sin embargo, Android Studio posee
características que hacen mucho más sencillo el desarrollo, como mayor facilidad para
ejecutar un simulador de un dispositivo Android y probar nuestra aplicación, consejos de
optimización del código, estadísticas de uso, entre otras.
Descripción de la interfaz:
Pantalla de inicio: es la primera pantalla que se muestra al abrir la aplicación. En ella se
muestra el logo de Robocol y las opciones para conectarse al robot por medio de Bluetooth, o
una pestana para obtener más información sobre el la interfaz, que redirige al usuario a la
página de GitHub que contiene la documentación del proyecto.
Controlador de avance: este control maneja los movimientos de avance del Rover en
cualquier dirección. Se implementó en forma de Joystick para que su manejo sea más sencillo
e intuitivo.
Accionador permanente de la rueda excavadora: este es un botón que al accionarlo activa

el funcionamiento de la rueda excavadora del Rover, y hace que ésta permanezca activada
hasta que se presione el botón nuevamente. El color del botón cambia para hacerle saber al
usuario cuándo está activado o desactivado.
Accionador manual de la rueda excavadora: este es un botón que al accionarlo activa el

funcionamiento de la rueda excavadora del Rover mientras el botón se mantenga presionado.
Es decir, al dejar de presionar el botón la rueda se detendrá. El color del botón cambia para
hacerle saber al usuario cuándo está activado o desactivado.
Controlador de movimientos de los actuadores lineales: estos botones se encargan de

manejar el movimiento de los actuadores lineales, logrando que se muevan hacia arriba o
hacia abajo al presionar el botón respectivo. Cuando el botón se deje de presionar, los
actuadores se detendrán.
Controlador de giro: estos controles tienen el objetivo de hacer rotar al Rover sobre su
propio eje, de manera que éste gire hacia la izquierda o derecha, pero no avance.
110
5.1.4. Mecánica
Sistema de oruga: el robot Intensity cuenta con un sistema de orugas trapezoidales

escalenos el cual presenta una rueda de transmisión suspendida por encima de la línea de
apoyo, transfiriendo parte del peso del robot a la rueda de transmisión. La principal ventaja de
este tipo de oruga es que son altamente funcionales en suelos barrosos, gracias a que la
rueda de transmisión está suspendida.
Figure 83. Oruga izquierda del Intensity.
Rueda de transmisión: Esta se encarga del transmitir el movimiento proveniente del motor
hacia la banda de transmisión del sistema. Las dos ruedas que hacen parte del Intensity se
encuentran en buen estado desde el visto funcional y no requieren de reparaciones.
111
Figure 84. Rueda de transmisión derecha del Intensity.
Figure 85. Rueda de transmisión izquierda del Intensity.
Caracterización:
7,60 ± 0,10 cm de ancho.
112
1,375 ± 2,50 cm de grosor.
1,3 de diámetro de cilindros guía.
3,175 ± 2,50 cm distancia entre puntas de cilindros guía.
Engranage principal: estos hacen parte de los sistemas de transmisión de movimiento de

los motores inferiores del Intensity a los sistemas de oruga. El sistema de transmisión está
conformado por: un engranaje de 9 dientes ensamblado al motor inferior, el engranaje
principal de 45 dientes ensamblado a la rueda de transmisión y una cadena de transmisión.
Los engranajes pequeños y las cadenas se desacoplaron del Intensity cuando se retiraron
los motores inferiores. Los componentes del sistema se encontraban en buen estado, pero el
engranaje de principal del lado derecho falta, como se muestra en la figura 2. Se plantearon
dos soluciones del problema: el primero es cotizar otro engranaje, o manufacturarlo en
maquinado CNC.
La cotización quedo detenida debido a la cuarentena.
Figure 86. Engranaje izquierdo.
Caracterización:
9 cm de diámetro de diente a diente.
5 mm distancia entre dientes.
5 mm profundidad de diente.
45 dientes.
113
Ruedas guías: el sistema de oruga cuenta con 4 guías cada uno, de las cuales una de
ellas sirve para expandir el perímetro de la oruga y adaptarla a la banda de transmisión, todas
estas se encuentran en buen estado.
Figure 87. Rueda guía.
Caracterización:
8 cm de ancho.
8 cm de diámetro.
1,55 cm de espesor en bordes.
Banda de transmisión: La oruga tiene 215cm de perímetro en su posición más abierta.

Inicialmente se habló con Carlos sobre la posibilidad de reemplazar el sistema de orugas con
un sistema 6x6, dada las diversas desventajas que presenta un sistema de orugas.
Sin embargo, nos comentó que la prioridad era más que nada recuperar la movilidad del robot
y ya después se miraría si valía la pena cambiarle el sistema de tracción.
A partir de allí, se hizo ingeniería inversa y se empezó a investigar posibles opciones de
proveedores y/o manufactura para desarrollar las orugas.
Se cotizó una banda transportadora “personalizada” en la central de bandas, dado que las
correas de transmisión disponibles no brindaban la separación ni la altura de dientes
necesaria, además de que tenían poca flexibilidad a la hora de amoldarse a las ruedas guía.
La banda tenía una separación de dientes de aprox. 3,25 cm, una altura de diente de 1,5 cm,
espesor de 3,5 mm y un largo total de 200 cm. Hecha en material de PVC y dientes de
caucho* (probablemente) vulcanizados en la cara externa.
Se podían agregar dientes en la cara interna de la banda, pero la empresa no nos podía
garantizar que el vulcanizado sería duradero.
114
Bajo estas condiciones, la oruga tendría un costo de aprox. 230.000 pesos, a lo cual hay que
sumarle refuerzos en cada diente y la adición de dientes en la cara interna.
Considerando las condiciones de operación y el uso que se le dará al robot (tengo entendido
que tendrá fines principalmente didácticos), el material de la oruga cumpliría con los
requerimientos técnicos, solo habría que verificar la resistencia a la abrasión.
También se consideraron otras opciones para el diseño de la oruga, pero eran poco viables
por las modificaciones estructurales que requerían.
Figure 88. Diseño alternativo de oruga.
115
Figure 89. Diseño alternativo de oruga.
Figure 90. Diseño alternativo de oruga

.
116
Figure 91. Diseño alternativo de oruga

.
Debilidad estructural: el robot presenta múltiples puntos a mejorar a nivel estructural, lo

cual es bastante estimulante desde el punto de vista de desarrollo. Hay que hacerle cosas
básicas de mantenimiento como limpiarlo, reducir el óxido, pintarlo y agregarle lubricante en
puntos críticos. Sin embargo, hay 2 puntos que requieren especial atención: Arreglar
soldaduras y ajustar el equilibrio/estabilidad de la estructura.
Se ha observado que el robot presenta algunos desequilibrios o asimetrías en la manera
como está ensamblado, lo cual se manifiesta en inclinaciones estructurales hacia un lado
especifico, cantidad diferente de arandelas de cada lado, entre otros.
La inclinación estructural se debe parcialmente a que los actuadores no se expanden al
mismo ritmo, lo cual ocasiona que un actuador siempre esté más extendido que el otro.
Electrónica ya sabe esto y están trabajando en ello En cuanto a la estabilidad estructural, hay
que ajustar múltiples pernos y añadirles arandelas para minimizar el “juego” que presentan
algunas uniones.
Por último, durante la última reunión que se hizo antes de la semana de receso falló la
soldadura de un brazo estructural. También se observó que un punto cercano debajo de uno
de los rieles guía (los que permiten la elevación del robot) presenta una falla en la soldadura.
117
Figure 92. Fallo en soldadura de brazo estructural.
Figure 93. Fallo en soldadura cercana al riel guía.
5.1.5. Actuadores
Funcionamiento y contexto del uso de actuadores:
A continuación, se ponen en contexto conceptos que fueron utilizados para llevar a cabo
118
este estudio y proceso de caracterización de los actuadores lineales.La caracterización de un

dispositivo electrónico es el proceso en el cual se establecen valores y relaciones entre
características que porta un dispositivo como tensiones, energía, etc. En este proceso se
utilizó para relacionar datos de voltaje, velocidad, y tiempo.
Un actuador lineal es una herramienta utilizada en diversos espacios principalmente en la
industria el cual tiene la función de convertir un movimiento de un motor giratorio a un
movimiento lineal. de esta forma tiene una amplia gama de utilidades, en nuestro proyecto se
está utilizando para establecer movilidad del robot de forma vertical.
La fuente variable es un dispositivo que nos permite regular el voltaje de alimentación de
determinado circuito y así adecuarlos a necesidades propias, en el presente proyecto es
utilizado para para la medición y caracterización de las relaciones necesarias para un claro
funcionamiento de los actuadores lineales.
Descripción del procedimiento:
En el proceso de caracterización de los actuadores se utilizaron múltiples maneras para llegar
a datos concretos y más acertados, a continuación, nombraremos los que mejor dieron
resultado:
1. Accionar los actuadores a diferentes voltajes para determinar relaciones entre energía y
velocidad.
2. Medir las distancias adquiridas para luego determinar las relaciones de “tiempo –
distancia” y así saber que voltaje es necesario para alcanzar determinada distancia en
determinado tiempo.
3. Implementación de Arduino para observar funcionamiento de los actuadores

ensamblados en el prototipo, en el cual observamos que al aplicar igual voltaje a los dos
actuadores lineales tenían diferentes velocidades y por consiguiente diferentes valores
en las relaciones nombradas anteriormente.
4. En el documento de especificaciones mencionan que “cuando la carga en empuje es

superior a 4000 N (máx. 6000 N), la longitud máxima de la carrera es de 250 mm.” Sin
embargo, en los procesos de pruebas los dos actuadores no dan el mismo rendimiento;
esto ocurre cuando se arrancan al mismo instante con igual voltaje a consecuencia de
esto, en el ensamble se necesitará calibrar los actuadores de forma que ambos guarden
una misma posición respecto al punto de postura.
Resultados de la caracterización
Se procede a mostrar los resultados del procedimiento realizado a los actuadores sin carga.
En las figuras 94 y 95 se muestran los resultados de una entrada de voltaje contra el tiempo
que se demoran estos actuadores en recogerse o alargarse.
119
Figure 94. Voltaje con Tiempo de los actuadores lineales al alargarse
Figure 95. Voltaje con Tiempo de los actuadores lineales al recogerse
Conclusiones
Se concluye de la información anteriormente planteada la caracterización de los actuadores
120
lineales de una forma mucho más concreta la cual va a permitir una implementación de este
dispositivo de una manera más sencilla, sin embargo, hay que tener en cuenta las
recomendaciones implícitas expresadas anteriormente. También debemos tener en cuenta los
datos que nos ofrecen las gráficas respecto a las relaciones encontradas en el proceso de
caracterización de los dos dispositivos ya que se encontraron diferencia en el funcionamiento
de los mismos.
5.1.6. Motores
Funcionamiento y contexto de motores

Los motores son parte fundamental del rover ya que estos controlan el movimiento horizontal
del rover y el movimiento de la rueda excavadora. Los motores van ubicados en una banda,
de tal manera que al energizar los motores esta banda gira y asi empeiza el movimiento del
rover.
Descripción del procedimiento:

Primero se desarmó el robot para extraer sus partes. Se tomaron aquellos motores que
movían las ruedas de oruga y la rueda excavadora. Se utilizó una fuente de voltaje con el fin
de darle voltaje a los motores, un cronómetro para medir el tiempo en el que el motor
completaba un giro.
Se midió con un cronómetro el tiempo que le tomaba al motor dar una vuelta, con el fin de
sacar la velocidad del motor en revoluciones/segundo.
Se realizaron las pruebas varias veces para cada motor, cambiando el voltaje con el fin de
saber con precisión la velocidad del motor dado el voltaje.
Resultados:
Se obtuvieron los resultados presentados en la figura unos resultados que indican que los
motores tienen un buen funcionamiento. Se presentan en las figuras 96 y 97
Figure 96. Tabla de caracterización de los 3 motores
121
Figure 97. Gráfica de caracterización de las velocidades de los 3 motores a distintos voltajes
Conclusiones:
De aquí de puede concluir que el motor 3 es más rápido en voltajes menores, mientras que en
voltajes más altos como 20V, los tres motores tienen casi la misma velocidad. A mayor voltaje
mayor velocidad. Los tres motores mantienen una velocidad promedio parecida. El motor 4 es
el más rápido a mínimo voltaje, pero cuando empieza a aumentar, disminuye su velocidad. El
motor 3 es el más rápido de entre los tres.
Debido a la problemática actual, consecuencia del COVID-19, quedó pendiente realizar la

etapa final de pruebas, en las cuales hay que verificar el correcto funcionamiento de todas las
partes del robot anteriormente mencionadas, en conjunto. Adicionalmente, queda pendiente,
a partir de los resultados de las pruebas anteriormente mencionadas, la programación del
Arduino, la implementación de la sensórica, la interfaz y los arreglos finales para "decorar.el
robot (principalmente, iluminación).
Los aprendizajes que deja este trabajo son una valiosa experiencia para este grupo.
Inicialmente no conocíamos los componentes de los cuales se compone el rover ni tampoco
122
funcionaban. Por medio de experimentar e investigar se logro entender el funcionamiento del

rover y el papel de cada uno de los componentes. También se ganaron habilidades
experimentales ya que se debía obtener la caracterización de los componentes que en
principio eran desconocidos para los integrantes del grupo.
En este proceso de aprendizaje tambien hay errores o cosas por mejorar. Al montar los
actuadores lineales al rover, estuvo cercano a romperse debido a que uno de los actuadores
ejerce mas fuerza que el otro cuando esta montado sobre el rover. De tal manera que es
necesario calibrar y caracterizar los actuadores con carga. Por otro lado, al montar el motor
de la rueda excavadora se debilito estructuralmente el rover ya que se desprendió una pieza
debe ser soldada, adicionalmente la rueda no tenia el comportamiento esperado ya que no gira
completamente sino que tiene un obstáculo para moverse.
123
6 GESTIÓN
6. Gestión
124
6.1 Subsistema Gestión 6 GESTIÓN
6.1. Subsistema Gestión
Carlos A. Oliveros Forero - Ingeniería Mecánica (Capitán)
Daniel Ortiz Carvajal - Ingeniería Industrial
Brenda Barahona Pinilla- Ingeniería Industrial y Sistemas
Gabriela Marquez Loaiza - Diseño
Hermes Ayala Calvo - Administración
Eloy Briceño Moreno - Ingeniería Electrónica
Martín Pelaez Londoño - Ingeniería Mecánica
6.1.2. Sistema integrado de información
Con el objetivo de centralizar toda la información de Robocol desde su fundación en el 2010

y futuro, se creo un equipo en la plataforma en Teams con el correo oficial de Robocol. Esta
plataforma hace parte del paquete institucional y es una excelente herramienta para organizar
información y coordinar el trabajo del equipo. La idea es agrupar toda la información por años
en la carpeta general. De esta forma, futuros integrantes pueden ingresar y conocer todo lo
que se ha hecho en el grupo en las diversas competencias y crear sobre lo que ya se ha
investigado y realizado. A inicios del año se realizo un gran esfuerzo para recolectar todo tipo
de documentos, informes fotografías, vídeos, experiencias de los primeros años de Robocol.
Se contacto con varios integrantes los cuales nos enviaron todo lo que tenían relacionado con
Robocol. La idea es crear una carpeta a finalizar cada año y almacenar absolutamente todo
tipo de documentación que se tenga de forma organizada.
6.1.3. Sistema integrado compras
Debido a la cantidad de integrantes y subsistemas que pueden realizar compras en el

equipo, se decidió crear una plataforma que nos permitiera hacer pedidos y que estos se
tramiten de forma practicante automática. Un sistema de este tipo no es nada nuevo para
empresas, sin embargo el costo de adquisición de realmente alto. Por este motivo se
desarrollo una macro de Excel que se acomodara a nuestras necesidades como organización.
Ya se tiene la versión final y se están realizando pruebas para validar su correcto
funcionamiento.
El proceso para que un integrante realiza un compra es la siguiente forma.
125
El integrante ingresa a la macro en inicia el proceso. Inicialmente debe ingresa su nombre

y elige el medio por el cual se requiere hacer la compra. (Puede ser departamentos de
ingeniería mecánica o electrónica por el momento)
El integrante selecciona si la compra es nacional o internacional.
Se abre una pestaña donde el integrante debe ingresar todos los datos de la compra
como se muestra en la figura 98. Al enviar el pedido se crea la orden de compra y se
asigna en la capeta respectiva.
Figure 98. Pestaña de pedido
Dos veces por semana el encargado de compras actualiza los nuevos pedidos y genera
un documento el cual incluye todos los datos necesarios de los pedidos realizados en
ese periodo. Este documento es enviado a los asesores para aprobación y finalmente se
envía al departamento de compras de la universidad.
El día que llegue el pedido, se le informará al integrante para que lo reclame.
Para instruir a todos los integrantes como funciona el nuevo modelo se creo un vídeo
instructivo.
126
6.1.4. Base datos y organigrama
Debido a que el grupo se compone por más de 50 estudiantes, 3 proyectos y 10 subsistemas

fue necesario realizar un base de datos todos los integrantes activos. A inicio de cada periodo
todos los integrantes deben ingresar y actualizar su datos.
Datos personales: Código uniandes, Nombre, fecha de nacimiento, cédula, carrera,

correo uniandes y celular.
Datos Salud: tipo de sangre, alergias, Contacto de emergencia.
Datos Robocol: Subsistema 1, subsistema 2, semestre de ingreso a Robocol, Instagram.
Una vez se tiene esta información se procede a realizar el organigrama. Dado que se
conoce el líder e integrantes de cada subsistema se procede a crear códigos de dependencia
y la lista con el ID (Codigo Uniandes), Nombre, Carrera y Manager ID. Esta nueva tabla se
ingresa al software Visio y crea automáticamente el organigrama del equipo. Este fue
únicamente un resumen del proceso, en la carpeta de gestión se encuentra un manual
detallado para actualizar y crear el organigrama de Robocol. En la siguiente figura 99 se
muestra el organigrama del semestre 2020-1.
Figure 99. Organigrama Robocol
127
6.1.5. Nueva Página Web
La pagina web del equipo es de suma importancia. Es el sitio principal donde futuros
integrantes, nuevos patrocinadores y publico en general se pueden enterar sobre el grupo, su
historia y que esta haciendo en la actualidad. La pasada pagina web de Robocol no se
actualizaba desde el 2015 y estaba programada en HTLM. Para la nueva pagina se decidió
cambiar de plataforma y utilizar una ofrecida por el DSIT Uniandes. Joomla es un sistema de
gestión de contenido y de código abierto para publicar contenido web.
A continuación se presenta la estructura la nueva pagina.
Inicio: Descripción general (Misión, visión, valores), preliminar de proyectos,

patrocinadores principales, noticias y experiencias de ex-integrantes.
Nosotros: Descripción equipo, información convocatorias, Timeline Robocol, Integrantes

por subsistemas.
Proyectos: Descripción general de proyecto Rover y ROV, foto interactiva prototipos,

especificaciones principales de cada proyecto, vídeo, fotos y documentos de entregas
competencias.
Patrocinadores: Logos con hipervínculo de todos los patrocinadores y
Prensa y medios: Noticias principales del equipo, competencias con fotos e historias
integrantes, documento de actualización semestral.
Contacto: Información de contacto y redes sociales.
(a) Render 1 (b) Render 2
(c) Render 3
Figure 100. Página Web
128
6.1.6. Planeación de eventos
Con el objetivo de visualizar y promover la robótica en Colombia se planearon varios

eventos para este año.
6.1.6.1 Evento Escuela de robótica del Choco
Evento organizado en conjunto con la Escuela de Robótica del Choco tiene como objetivo
mostrar que lo único que les impide çrecer"son sus limitaciones y no las que otros les imponen,
se logrará gracias a que les brindaremos. Conocimientos en diferentes áreas. Los integrantes
de Robocol se dirigen al departamento del choco a dar unos cursos de robótica básica a
estudiantes de colegio y primaria. Como objetivos secundarios del evento se tiene:
Enseñarles que ellos pueden ser y son agentes de cambio.
Brindar herramientas para que ayuden a su comunidad.
Informar acerca de Pa’Lante Pacifico.
6.1.6.2 Evento 10 años Robocol
Evento presencial planeado para celebrar los 10 años de Robocol y mostrar el impacto
que ha tenido en la sociedad y la comunidad uniandina. Además de esto, hacer la
presentación de los nuevos proyectos en modo de lanzamiento. El evento planea reunir a
antiguos integrantes y actuales para compartir historias y aprendizajes. El documento con el
orden del día y organización especifica se encuentra en la carpeta de gestión en Teams.
Desafortunadamente ambos no se podrán realizar debido a las restricciones actuales de
pandemia pero se buscara una manera que modificarlos a una forma virtual.
6.1.6.3 Webinar: Kiwibots, de canastas a robots
Con el objetivo de fortalecer la relaciones que se tienen los capítulos de CIMANDES,

SISANDES, INELANDES, se organizo un evento sobre Kiwibots. El conferencista es un
antiguo miembro de Robocol que trabaja en la empresa. Resumen de la charla: Esta charla
habla sobre el proceso de desarrollo tecnológico y la evolución que han tenido los Kiwibots,
durante los últimos años. Cuenta varias anécdotas que hacen parte del detrás de escenas de
la construcción de este producto en Colombia, que hoy en día es usado para la entrega de
domicilios en varias partes del mundo.
129
Figure 101. Publicidad
6.1.7. Concurso ACOFI 2020
La Asociación Colombiana de Facultades de Ingeniería (ACOFI) realizará del 15 al 18 de

septiembre de 2020 en Cartagena una nueva edición del Encuentro Internacional de
Educación en Ingeniería ACOFI (EIEI ACOFI 2020). Con el título "La formación de ingenieros:
un compromiso para el desarrollo y la sostenibilidad", el EIEI ACOFI 2020 reunirá a decanos,
directivos académicos y administrativos, profesores y estudiantes de ingeniería,
representantes del sector productivo, entidades del Estado, gremios y la sociedad, quienes
interactuarán para estudiar, analizar, debatir y reflexionar sobre el aporte de las facultades,
profesores y programas para el bienestar y el progreso.
Robocol decidió participar en el concurso de IV Muestra de trabajos de estudiantes de
ingeniería ACOFI 2020. Para la aplicación se envió el siguiente resumen del proyecto.
Un robot marciano para la exploración y la educación
A lo largo del 2019 se llevó a cabo el proyecto REM-U por la iniciativa estudiantil Robocol
de la Universidad de los Andes. Esta iniciativa está conformada y liderada por estudiantes de
diversas disciplinas como ingeniería mecánica, electrónica, sistemas, industrial,
administración y diseño. El proyecto REM-U consiste en un rover de exploración que fue
diseñado y manufacturado por los estudiantes para participar en la competencia European
Rover Challenge 2019. Esta consiste en interpretar e implementar todos los requerimientos de
un rover de exploración, los cuales son obtenidos directamente de documentos utilizados en
130
la planificación de misiones estratégicas de la NASA y la ESA. La competencia se compuso

en varias etapas de clasificación finalizando con una competencia practica llevada acabó en el
mes de septiembre en Polonia, en cual Robocol hizo participe. De las características
generales del REM-U se puede destacar el sistema de tracción Rocker-Bogie inspirado por la
NASA, llantas Honey Comb en impresión 3D, brazo robótico en fibra de carbono de 6 grados
de libertad y automatización de navegación entre otras. El peso total del rover es de 60 kg.
Las tareas que desarrollo el robot, independientes de su éxito fueron las siguientes. Una
tarea en ciencia que consistió en recolectar muestras mediante el uso de cualquier técnica
(por ejemplo: perforación, pala en un brazo robótico) y asegurarlas adecuadamente para
realizar pruebas en tiempo real. Una tarea de mantenimiento en al que se debía maniobrar el
rover hacia un panel de control y realizar varias operaciones manuales, como colocar los
interruptores en la posición y orden correcto, realizar mediciones eléctricas y reconocer
ciertos aspectos del panel de forma automática. Una tarea de recolección que consistió en
encontrar y recolectar diferentes elementos de tres ubicaciones diferentes y luego entregarlos
en un lugar designado de manera segura; una tarea de transverso de recorrido, tal vez la más
complicada debido a que el rover debía navegar de forma completamente autónoma y
encontrar diferentes puntos en Mars Yard (Campo de pruebas). A diferencia de las demás, los
operarios no podían utilizar ningún tipo de cámaras. El rover debía navegar utilizando solo un
mapa y diferentes códigos QR que se encontraban en la pista para ubicarse.
Este proyecto les permitió a los estudiantes poner en práctica todo el conocimiento y
habilidades que se adquieren en los cursos vistos en la universidad y trabajar con estudiantes
es otras carreras en un proyecto de ingeniería complejo e interdisciplinario. Es importante
reforzar estas competencias dado que oportunidades de trabajo interdisciplinario no se
presentan frecuentemente en la carrera universitaria y es un elemento fundamental en la vida
profesional. Dado que el proyecto el liderado por los mismos estudiantes es necesario
desarrollar habilidades blandas para gestionar, comunicar y conseguir patrocinadores y
recursos indispensables para la construcción y el viaje. Este ejercicio académico es
fundamental para el desarrollo de ingenieros críticos y hábiles, que al graduarse puedan
afrontar cualquier problema actual con experiencia que brinda participar en proyectos
similares a este en esta etapa académica de pregrado.
El 17 de mayo llegaron los resultados de la convocatoria y Robocol fue seleccionado para
participar en el este importante evento. Se realizará el informe y poster correspondiente para
el evento.
6.1.8. Patrocinadores Internacionales
En el semestre se logro el primer patrocinador internacional de Robocol. Se llego un

acuerdo con la empresa BlueRobotics de USA. Este empresa es líder en fabricación y venta
de componentes para aplicaciones subacuáticas como ROV Y AUV. Se logro obtener un
descuento del 10 % en todas las compras que se realicen en la página online.
131
Figure 102. Blue Robotics
Estatutos/Handbook Robocol: Documento donde se detalla los principios del equipo y

procedimientos generales para mantener y gestionar efectivamente. Incluye todo lo
aprendido por los integrantes actuales y pasados, desde manual para competencias,
organización de proyectos, presupuesto, PR, pratrocineos.
Terminar la secciones restantes de la página web y lanzarla en el mes de junio.
Estrategia de medios Robocol 2020: Con el objetivo de aumentar la presencia del equipo
en la redes, se planea hacer unas serie de campañas con post semanales utilizando
hastags y tag estratégicos en las redes de Facebook, Instagram, LinkedIn y Youtube. Es
un total de 35 post para la segunda parte del año. Y el objetivo es tener mas de 2500
seguidores en la cuenta de Instagram al finalizar el 2020. Se va incluir: 10 años Robocol,
lazamiento de nuevas página, eventos (Mars 2020) y presentación de nuevo equipo.
Plan de financiamiento: Se planea hacer un plan y campaña para presentar al equipo

y conseguir patrocinadores de empresas nacionales como internacionales en distintas
modalidades y paquetes. Se cuenta con el asesoramiento de Daniel Medina, ingeniero
electrónico y estudiante doctoral de la universidad.
Planeación de logística para ERC2020. Dado que la competencia se va a realizar de

forma virtual y las condiciones que podamos trabajar están cambiando constantemente,
es necesario tener claro como se va a llevar la competencia para que todos los integrantes
puedan participar activamente.
132

Systems Engineering Project Documentation PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Systems Engineering Project Documentation PDF

Cargado por

Copyright:

Formatos disponibles

Documentación de avances Robocol 2020-10

Innovación Trabajo en equipo

Carlos Alfonso Oliveros Forero Daniel Villar Gonzalez

Franz Kevin Luepke Prieto Daniel Ricardo Barcasnegras Moreno

Sebastian Sierra Alarcón Alvaro Daniel Plata Marquez

Juan David Medina Tobón Brenda Catalina Barahona Pinilla

Natalia López Arango David Andres Caliz Hernandez

Martin Pelaez Londoño Valentina Parra Garcés

Felipe Gomez Jasbon Gabriela Estefania Marquez Loaiza

Eloy Andrés Briceño Moreno Javier Hernán García Sánchez

Jorge Alfredo Chaparro Gamboa Angela Maria Vargas Guerrero

Paulina Michelle Acosta Cevallos José Alexander Da Cámara Sousa

Jose Cristobal Arroyo Castellanos María Alejandra Escalante Pérez

Juan Jose Rosas Esteban Juan David Serrano Mugica

Ana Sofia Miranda Ramirez Jorge Felipe Gaviria Fierro

Santiago Usme Martinez Luis Felipe Pinzón Troncoso

David Andres Sanchez Umbarila Felipe Berón

Cesar Sebastian Gomez Mozo Jhoan Esteban León Echeverri

Santiago Andres Rondon Huertas Laura Juliana Aldana Giraldo

Jaime Andres Nuñez Gonzalez Nicolás Grandas Suarez

Hermes Steve Ayala Calvo Luisa Fernanda Rengifo Cajías

Jesus David Espinosa Rubio Alvin David Gregory Tatis

Juan Sebastian Alegría Zuñiga Jorge Luis Lamprea

Juan Camilo Gutierrez Gonzalez

Daniel Esteban Ortiz Carvajal

2.4.1. Miembros del subsistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.1.6. Errores y aprendizajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

6.1. Subsistema Gestión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

Integrantes (con sus respectivos departamentos de trabajo).

Trabajos futuros y posibilidades de mejoramiento.

2.1. Subsistema Brazo

2.1.1. Miembros del subsistema

Felipe Gómez - Ingeniería Mecánica (Capitán)

Franz Luepke - Ingeniería Electrónica

Jaime A. Nuñez - Ingeniería Mecánica

Jorge Gaviria - Ingeniería Electrónica

Daniel Barcasnegras - Ingeniería Mecánica

Juan Camilo Gutiérrez - Ingeniería Electrónica

David Andrés Sanchez - Ingeniería Electrónica

2.1.3. Trabajo realizado este semestre

Como se expuso en la introducción, se situó un objetivo grande de mejoras físicas y

2.1.4. Modelo dinámico

primeros pasos al desarrollo de un modelo de dinámica inversa, el cual es necesario para

Figure 1. Sistemas coordenadas

Figure 2. Vector de posición

Figure 3. Matriz de rotación en 3 ejes coordenados

Se espera que en el periodo inter-semestral, el desarrollo del modelo esté terminado, y el

2.1.5. Desarrollo de brazo virtual

Figure 5. Brazo virtual agarrando una bandera con las pinzas.

(a) Garra abierta (b) Garra cerrada

Figure 6. Garra del brazo completamente abierta y completamente cerrada.

2.1.6. Planeamiento de mejoras

Como se comentó en la introducción del subsistema, el plan original era diseñar e

2.1.6.2 Substituto fibra de carbono

2.1.6.3 Desarrollo de carriles

2.1.7. Primeras pruebas de autonomía

Figure 8. Planeación de ruta con control de Xbox.

Pose Descripción Imagen

Posición ideal para poder realizar un

Posición ideal para recoger un objeto

Posición ideal para dejar un objeto

el brazo siguiendo la interpolación de trayectorias propuesta por MoveIt, esta se corroboraba

Figure 9. Planeación de ruta con control de Xbox y seguimiento de trayectoria de manera