MK-TEAM es el grupo conformado por José Bartra, Diego Loayza, Kevin Ponce, Javier Mendoza, Darío Huanca, Enzo Cisneros, Jimm Cisneros, Luis Caballero, Melanie Benites y Giomar Quispe, todos alumnos de Ingeniería Mecatrónica de nuestra Facultad, que representó por primera a Perú en la CanSat Competition que se realizó en el Instituto Politécnico y Universidad de Virginia en Blacksburg del 9 al 12 de junio del 2022.
En la siguiente entrevista, conversamos con José Bartra (equipo de Mecánica), Javier Mendoza (equipo de Electrónica), Enzo Cisneros (equipo de Programación/software) y Luis Caballero (equipo de Telemetría) para que nos cuenten su experiencia en la competencia y el lanzamiento del MK-Sat.
¿Cómo se conformó el equipo para la competencia?
José Bartra: De hecho, Enzo y Luis fueron los reclutadores; Javier y yo, los reclutados. Me enteré de esta convocatoria porque me comentaron que habría una convocatoria este año, al igual que el 2021.
Javier Mendoza: En mi caso vi que el Grupo de Robótica de la PUCP (GR-PUCP) había lanzado una convocatoria para diversos proyectos. Una de ellas era para el CanSat, así que me animé. Además, mi hermano también influyó un poco porque me decía que debía hacer más actividades fuera de los cursos porque así aprendería lecciones que no se ven en las aulas. Así fue. Ha sido muy interesante participar de este proyecto.
Enzo y Luis, ¿ustedes lanzaron la convocatoria desde el GR-PUCP?
Luis Caballero: Nosotros, en conjunto con Darío Huanca y Daniel Menacho, vimos este concurso (CanSat Competition USA) e investigamos cuáles eran los requisitos, bases, etc. Ya habíamos escuchado acerca de este concurso, de hecho, hay varios de este tipo de competencias aeroespaciales. En un primer momento, nos habíamos decidido por un concurso más complejo, pero decidimos participar en la CanSat Competition USA porque nos pareció un buen primer paso para comenzar.
Examinamos cuántas personas se necesitaban para cada equipo, cuáles eran las limitaciones porque, por ejemplo, no se puede hacer un grupo de solo diez egresados. Al inicio, había dos equipos, diez participantes para cada uno. Luego, con el pasar del tiempo, por otras prioridades u otros temas que desconocemos terminamos siendo solo los diez que conformamos el actual equipo.
Enzo Cisneros: De estas diez personas que quedaron al final, siete eran estudiantes y tres egresados. Precisamente, ese era el límite que permitía la competencia.
¿Cómo fue el proceso de selección?
Luis C.: Al inicio, contamos con un formulario con preguntas sobre la disponibilidad de tiempo para el proyecto; conocimientos en áreas como mecánica, electrónica o programación, justamente, las categorías en las que el proyecto se divide; y, después, consideramos la presentación de una carta de motivación para que puedan comentar puntos que no se incluyeron en las preguntas.
¿Podían participar estudiantes de cualquier especialidad?
Luis C.: Ahora que lo mencionas, en el apartado de “”¿a qué carrera perteneces?””, eran cinco, seis ingenierías y una sección de “”otros””. En un primer momento, la mayoría de personas que se presentaron eran de Ingeniería Mecatrónica, unos cuantos de Ingeniería Electrónica y uno de Gestión. Fue una convocatoria abierta para cualquier Facultad.
¿Por qué el nombre MK-SAT?
José B.: En la página de este concurso, hay un apartado en el que debes registrar a tu equipo. En este proceso, debes completar los nombres de los participantes y el nombre propio del equipo. Así que, cuando llegamos a esa parte, estábamos en Discord, nos tomamos veinte minutos o más pensando, entre bromas, cómo nos podríamos llamar.
Como peruanos, siempre surge la idea de ponerle un nombre en quechua, pero, en realidad, sentimos que ese recurso está bastante explotado. Entonces, como iríamos a una competencia en Estados Unidos, queríamos un nombre que se pueda pronunciar y entender en inglés. Dentro de la Facultad, a los estudiantes de Ingeniería Mecatrónica se les suele abreviar como MK o MKT, así que le pusimos MK y SAT por satélite.
Vimos en competencias pasadas que, casi todos los equipos, al final de su nombre, le añaden SAT por esto de los satélites precisamente. En realidad, nuestro grupo se denomina MK-TEAM, pero, según la competencia a la que apuntemos, el nombre se podría modificar a MK-SAT o MK-ROVER, básicamente fue así cómo surgió. Quedó MK porque, de momento, en el equipo, todos somos mecatrónicos.
¿Cómo organizaron los subgrupos en el equipo?
José B.: Este tipo de proyectos siempre tiene distintos rubros: diseño mecánico, programación o software, la electrónica y telemetría. Nos dividimos en subgrupos para poder tener un mejor avance. Al final, como todos somos mecatrónicos, cada quien sabe un poco de todo y nos apoyamos en las diferentes áreas.
En el área de telemetría, todos éramos completamente nuevos. Nadie sabía mucho acerca de ese apartado. Fue, aparentemente, una primera dificultad, pero, conforme se fueron dando las fechas de presentación, nos dimos cuenta de que no era tan complicado como parecía. Supimos llevar adelante este apartado.
¿De qué se encargó cada uno en los diversos subgrupos?
José B.: Yo soy del área de Mecánica, Javier de Electrónica, Enzo de Software y Luis de Telemetría. Empezando por mi área, trabajé junto con Diego Loayza y Kevin Ponce. Ellos se encargaron del paracaídas. Consistía en utilizar dos paracaídas: uno que se abría ni bien salía del cohete y, un segundo paracaídas, que se abría cuando el satélite estaba a 400 m. de altura. Se encargaron del diseño, cálculos y manufactura de los paracaídas: compraron tela, revisaron las dimensiones y cosieron. Hubo bastante esfuerzo detrás de esos dos paracaídas.
Yo me encargué del diseño de la estructura del CanSat: qué materiales utilizar, cómo sería la estructura y del mecanismo de descenso, ya que este picosatélite consta de dos partes, ambas cargas útiles, pero la primera queda dentro del satélite y, la segunda, se desprende 10 m. del contenedor. Esa fue mi labor.
Javier M.: Para empezar, en electrónica debí buscar algunos componentes que eran necesarios para la competencia. Por ejemplo, nos pedían sensores de temperatura, presión, GPS, voltaje y módulos de telemetría.
Una vez identificados estos sensores, buscamos tres ejemplos de cada uno de estos requerimientos para determinar cuáles serían los más oportunos para el proyecto. Tomamos en cuenta varios criterios como voltaje, consumo de corriente, potencia y el alcance de cada uno de ellos. Después, se realizaron diseños de tarjetas electrónicas y, así, realizar un cálculo de la energía que se requiere. En este caso, utilizamos baterías de litio. En base al cálculo realizado, se determinó que estas baterías podrían funcionar correctamente durante dos horas. Luego se soldaron y acomodaron todos los componentes en las tarjetas electrónicas.
Enzo C.: En el área de software, trabajé con mi hermano, Jimm Cisneros. Con los sensores ya seleccionados, buscamos librerías implementadas en python para cada uno de ellos y se probó una funcionalidad básica: tener un solo archivo que ejecutara sensor por sensor y obtener su data.
Después de haber probado todos los sensores se trató de integrarlos en un proto-board solo con cableado y, luego, se intentó probar todos a la vez. Se partió de un solo sensor, luego tres o cuatro y comenzaron algunos problemas de conexión.
Algunos sensores no funcionaron como esperábamos, sobre todo, el GPS. Este está encargado de devolver información como número de satélites conectados, longitud, latitud y, en Perú, nunca dio un buen resultado, siempre devolvía cero en todo. Mientras que, en Estados Unidos, a veces, sí arrojaba buena información. En el lugar que estuvimos alojados, hicimos pruebas y sí funcionaba correctamente: devolvía número lógicos.
Luis C.: Yo estuve en el área de Telemetría junto con Giomar Quispe y Melanie Benites. El cohete debía subir a una altura máxima aproximada de 750 m. Entonces, considerando esta altura máxima y a la que nosotros estaríamos alejados del sitio del lanzamiento estimamos que debería transmitir información a una distancia de 1,5 km.
Partiendo de este requerimiento, seleccionamos módulos que se utilizarían en la estación de tierra, ya que una de nuestras computadoras estaría en dicha estación recibiendo la información. El satélite tiene dos módulos que interactúan entre sí, por lo que mantuvimos constante comunicación con el equipo de software porque debíamos resolver inconvenientes en conjunto.
Otro punto importante en nuestra sección fue el diseño de una estación de tierra. La información que recibíamos debía graficarse en tiempo real, por lo que la base debía estar preparada para esta tarea.
¿Cómo fue la experiencia de trabajar en un equipo tan grande?
José B.: En realidad fue con el tiempo con que nos fuimos conociendo más. Para la mayoría de nosotros era nuestra primera experiencia trabajando en un proyecto así. Al principio, todo fue un tanto desordenado. Comenzamos con reuniones dominicales a mediados de 2021 en Discord y presentábamos avances. Más que nada, era hacer una suerte de estado del arte del proyecto.
Cuando llegó noviembre nos inscribimos porque teníamos solo hasta diciembre para hacer el pago de la inscripción. En ese punto la situación mejoró bastante. Comenzamos a saber quiénes estaban más cómodos en ciertas áreas. Es así que cada quien eligió un área y veíamos cómo nos desenvolvíamos. Se conversaba y se iban definiendo puestos.
Una vez definido eso, empezamos a presentar documentación. La primera meta era tener un diseño preliminar. Casi cien equipos de distintos países mandaron su diseño. Por nuestra parte, logramos entrar dentro de los 49 cupos disponibles.
Luego, presentamos otro documento, uno más crítico, hacer mejoras y, desde ese punto, dejamos las reuniones de Discord para comenzar con las reuniones presenciales. Estas se dieron gracias al apoyo de Darío Huanca porque hicimos uso de su casa para estas reuniones. Optamos por esta alternativa porque hubo algunas complicaciones al momento de acceder a las instalaciones de la Universidad, debido a las medidas de prevención por la COVID-19. Más adelante pudimos acceder al campus y utilizarlas para nuestras pruebas.
Sin embargo, estas primeras reuniones fueron fructíferas, ya que comenzamos a probar los diseños desarrollados, y a detectar las fallas. De esto se tratan estas competencias: equivocarse varias veces y encontrar las soluciones adecuadas.
Para muchos ha sido la primera experiencia de salir de la virtualidad. Si esto hubiese sido un curso convencional todo habría terminado con la nota final, pero acá fue distinto: nuestro diseño tenía que funcionar. Hay que probarlo, darnos cuenta de los errores, replantear las soluciones y probar varias veces.
El Instituto de Radioastronomía de la PUCP (INRAS) nos acogió bastante bien. Nos prestaron su cámara térmica, de vacío y su mesa vibratoria, ya que el satélite debía pasar ciertas pruebas ambientales. Estas eran una de vibración, una de vacío, una de temperatura y una de caída. Así, el INRAS nos prestó sus instalaciones, nos reuníamos y recibimos asesoramiento por parte del ingeniero Valenzuela.
Javier M.: Como lo mencionó José, en el área de electrónica, hubo un buen asesoramiento por parte del ingeniero Valenzuela. Tuve la oportunidad de reunirme con él, pudimos mejorar el diseño de las tarjetas electrónicas y comprobar que los componentes puedan funcionar por dos horas. Utilizamos unos capacitores que garantizaban ese funcionamiento. Creo que sin ese asesoramiento no hubiese sido posible esa duración de dos horas.
Luis C.: Desde el área de Telemetría, como no manejábamos el tema a profundidad, fue un tanto más complejo su desarrollo. Sin embargo, profundizamos en el tema e investigamos constantemente, llegamos a tener reuniones diarias después de clases o del trabajo de algunos y, nos comunicábamos a través de Discord para dar un resumen con el fin de que todos estemos al tanto de los avances. En Estados Unidos, como compartíamos ambientes, nos mantuvimos trabajando 24/7 como se dice.
José B.: Una buena experiencia, como grupo, fue la de amanecernos. Fue increíble la noche en la que probamos el paracaídas. Teníamos un prototipo de satélite sin sensores porque se podían dañar. Lo que queríamos era probar el paracaídas.
Recuerdo que arriba estaban Luis, Javier, Diego y Darío, y abajo yo estaba con Kevin. Ver la emoción de Diego y Kevin al ver que su paracaídas sí funcionaba fue increíble. En verdad, fue una emoción de todos, una emoción compartida. Haber visto cómo se abría el paracaídas y cómo descendía y, a pesar de chocarse con una escalera, resistió. Fue increíble. No hay nada como la presencialidad.
¿Y desde las otras áreas, cuál fue su aporte para el funcionamiento del picosatélite?
José B.: En el área de Mecánica, lo que ocurre es que se coloca el satélite en un cohete que provee la empresa organizadora en la competencia. Este cohete acelera rapidísimo. Hay 15G de aceleración que debe soportar la estructura. Entonces, ves cómo, de un segundo a otro, el cohete ya está en el cielo y tiene que llegar entre 750 a 800 m. de altura.
Una vez alcanzada esa altura, la punta del cohete se desprende del cuerpo del cohete y es ahí cuando sale eyectado el pico-satélite. Comienza a descender, se despliega la carga útil cae a tierra y hay que ir a buscarlo. Ese es el funcionamiento en el área de mecánica.
Javier M.: Antes de que el satélite sea colocado en la nariz del cohete, lo primero que se hace, es energizar el sistema mediante interruptores colocados en la carga útil y en el contenedor. Una vez completado este paso, se coloca en la nariz. Lo que se busca es que, incluso dentro de la nariz, se siga enviando la información a la estación de tierra.
Cuando se lanza el cohete, llega a 750 m., se accionan los paracaídas y, en primer lugar, se recoge la data del contenedor. Luego se libera la carga útil y ya, en este punto, el descenso está controlado por un microcontrolador en el contenedor y un motor que permitiría que se despegue 10 m.
Luis C.: Como los apartados de telemetría y programación están muy conectadas se puede decir que, durante el lanzamiento, las actividades de estas dos secciones son las mismas. Antes de lanzar el satélite, desde la estación central, ubicada a 50 o 100 m., se debe verificar la comunicación.
Entonces, habíamos llevado una antena que conectamos a la computadora para comprobar, delante de jueces, una correcta comunicación y luego se procede con el lanzamiento. José fue quien dio la cuenta regresiva. En ese momento estábamos muy emocionados. Incluso, creo que hubo unos segundos de demora en nuestro cohete (risas). Se lanzó y, como ya se dijo antes, son solo segundos para que alcance la altura adecuada. Fue rapidísimo. En todo momento, el satélite debe enviarnos información. Cada dato que nosotros recibimos debemos almacenarlo y graficarlo. Además, como respaldo, en el mismo satélite, cada dato enviado es almacenado allí mismo. Esto porque si, en algún momento se llega a perder la comunicación, nosotros no recibiríamos ningún tipo de información, pero precisamente por eso se tiene este respaldo para tener la información de todas maneras.
Enzo C.: En primer lugar, en la parte de programación, la dificultad de integrar todas las funcionalidades que se requerían hizo que el código se complejice cada vez más. Al final, durante el lanzamiento, el código debía ejecutarse automáticamente en cuanto se encienda el CanSat. Para ello, se tuvo que configurar el sistema operativo, se creó un archivo autoejecutable y el código debía funcionar a la perfección porque no habría forma de corregirlo. Por lo que se tuvo especial cuidado en esa área.
Cuando se lanzara el satélite todos los sensores debían funcionar simultáneamente. Para ello, el concurso nos mencionaba que la telemetría debía recibir un comando desde la estación en tierra para empezar a captar la información de los sensores y generar un CSV. Es un archivo separado por comas. Algo como altura, presión, latitud, longitud, en ese formato y con 1 Hertz de frecuencia de muestreo. Ese CSV se almacenaba en la propias raspberry del CanSat y también se enviaba por telemetría a la estación en tierra.
Cabe mencionar que eran dos raspberrys: una de la carga útil y otra por el contenedor o carga útil principal, la más grande. La carga útil que se desprendía tenía que enviar su información al contenedor y esta más grande enviaba la información de ambas partes del CanSat a la estación en tierra.
¿Qué dificultades enfrentaron para el desarrollo del MK-SAT?
José B.: en mi área, fue difícil no haber tenido contacto antes con las impresiones 3D. Ya que, en un principio, gran parte de la estructura fue diseñada para que sea impresa con este tipo de tecnología. Luego se rediseñó porque el peso excedía a las bases, las cuales solo permitían un peso de 600 gramos. Esa fue una primera complicación: debíamos ahorrar peso en el diseño.
Otra complicación fue el mecanismo de descenso continuo que teníamos. Este mecanismo descendía por tramos, por golpes, daba saltos y era inestable. Felizmente, luego, se pudo solucionar.
Javier M.: En el apartado de electrónica, una vez que se eligieron los sensores se buscó la manera de integrar todos los componentes. Para ello se realizó un primer diseño de una tarjeta electrónica que se manufacturó en Perú. Después, revisando cómo ensamblar todo en la mencionada tarjeta tuvimos problemas para acomodar los componentes pero se logró mejorarlo.
Luis C.: Dificultades ya no solo en el apartado de telemetría, sino en general, por ejemplo, con el tema de los espacios. Estamos muy agradecidos con Darío Huanca porque usamos su casa, nos quedaba cerca y nos podíamos reunir. A inicios de año fue más complicado conseguir espacios disponibles en la Universidad debido a la crisis sanitaria, pero luego nos dieron un lugar en el Pabellón K, el de Ingeniería Mecatrónica.
En telemetría, comenzamos casi desde cero. Debimos investigar cómo se configuraban los módulos que compramos, cómo era la data que se transmitía o cuestiones más técnicas como las direcciones, configuraciones o temas así, pero se resolvió satisfactoriamente. Por la competencia misma, debía haber ciertos requerimientos para los datos. Entonces, los tomamos en cuenta y solucionamos las dificultades.
Enzo C.: En programación, la primera dificultad fue integrar las operaciones de todos los sensores al mismo tiempo en un solo scrip de programación. Al comienzo, daba muchos errores, pero poco a poco se fueron resolviendo uno por uno.
El otro gran problema fue integrar la telemetría, la capacidad de comunicación del CanSay junto con la programación de los sensores porque se tenía que hacer por hilos y, a veces, no se recibía la información a tiempo u otros problemas similares.
El problema final era que el CanSat, ni bien era encendido, debía correr un código automáticamente y lograr hacer esa funcionalidad en el satélite fue lo más complejo que se tuvo.
¿Cómo fue el momento del lanzamiento?
José B.: Se sentían buenas vibras entre latinoamericanos. Nadie veía a otros equipos latinos con la intención de que le vaya mal, sino, todo lo contrario. Queríamos que les vaya bien a todos y nos alegrábamos cuando así era. Se sentía el apoyo.
Hubo varios días importantes. En el primero, solo recogimos dos memorias USB y conocimos a otros equipos. En el segundo día, el viernes, estaba destinado a realizar el drop test (prueba de caída) para ver si la estructura soportaba el impacto. Pasamos esa prueba y nos dijeron que ya estamos listos para el vuelo. Nosotros nos quedamos fríos. Es una cosa completamente diferente verlo en la computadora que verlo en la realidad ya armado.
El tercer día fue el del lanzamiento. Acá cada quién la vivió de manera distinta. Por mi lado, hubo un poco de nervios, pero tratando de controlarme para trasmitir esa energía al equipo. Fue muy emocionante ver a nuestro proyecto ser lanzado.
Luis C.: Los nervios siempre están. Te mentiría si te dijese que no los tuve, pero es cosa de cada uno controlarlos para no trasmitir esa desesperación a los compañeros. Mientras estábamos esperando a ser llamados vimos, por primera vez, cómo despegaba el cohete. Nos sorprendió lo rápido que era. Sube en dos segundos, cae en otros dos y ahí se acabó todo. Ahí los nervios comenzaron a crecer, pero también la motivación. Todo el equipo estaba optimista.
Los lanzamientos no son de manera simultánea, sino que hay un horario en el que es asignado por grupos. Comenzamos a las 11:00 a.m. y no fue hasta las 3:00 p.m. que recién fuimos llamados. Nos acercamos a un espacio en el que estaban todos los satélites de todos los equipos, recogimos el nuestro, nos dieron un cohete y comenzamos la caminata hasta la zona de lanzamiento.
Durante esa caminata conversábamos y nos preguntábamos si funcionará o no, ¿caerá bien?, ¿se destrozará?, pero son detalles que cada quien lo vive diferente. En mi caso, lo viví con mucha emoción al igual que varios de mis compañeros.
Enzo C.: Como mencionaron mis compañeros: emocionado y nervioso. En el lanzamiento sentí la mayor cantidad de nervios. El grupo estaba expectante por ver cómo se daría el lanzamiento. Estuvimos en la mesa con Luis viendo el sistema en su laptop y yo con la antena apuntando al CanSat para recibir la telemetría y José dando el conteo.
Javier M.: Sentí nerviosismo por el tema de estar apurado porque teníamos que llegar hasta las 11:30 a.m., esa era la hora de ingreso del satélite. Nosotros llegamos diez minutos antes, ya que nuestro hotel estaba lejos del lugar y, en el camino, íbamos pensando el tema del peso porque habíamos añadido algunos detalles a la estructura final. Felizmente, el peso sí cumplió con las bases: fue de 600 gramos exactos. El límite era 600±10 gr. Luego lo colocaron en la nariz del cohete, lo posicionan en un lugar en específico y te dan un horario para el lanzamiento.
Luego vimos los lanzamientos de otros grupos. A algunos les fue bien y a otros mal, hubo de todo. Por ejemplo, el satélite de un equipo cayó como una roca y nos hizo pensar qué pasaría con el nuestro y ahí te das cuenta que todos los grupos tienen las mismas preocupaciones. Lo únicos tranquilos son los que ya habían terminado (risas).
Yo estaba encargado de recoger el satélite en el lugar en donde cayera, por lo que debía estar muy atento. Fui con Darío y, en el camino, nos preguntábamos si estaría bien el satélite. Revisé el satélite. Estaba completo y funcionando, así que, por ese lado, todo bien.
¿Cómo sintieron el apoyo de la universidad y de sus compañeros?
José B.: En realidad, toda la comunicación se dio mediante nuestro asesor el Ingeniero Diego Arce. Confió en nosotros y, mediante él, conseguimos el apoyo para comprar los componentes o, incluso con el pago de la inscripción que fue de doscientos dólares. Ese fue un gran apoyo.
Enzo me ayudó a redactar algunos correos y los enviamos a empresas, pero mucho no nos contestaron. Sin embargo, la empresa Tumi Robotics nos dio apoyo económico a todos. La universidad también nos ayudó con la compra de pasajes y sin esas colaboraciones hubiese sido muy complicado.
Dentro de GR-PUCP también se sintió mucho el compañerismo para con nuestro proyecto. Nos motivó mucho para viajar a representar a la universidad y al país. Además, resaltaron antes del lanzamiento de nuestro satélite que éramos el primer equipo peruano en esta competencia.
¿Qué mensaje enviarían a sus compañeros para animarlos a participar en competencias?
José B.: Atrévanse. No la duden ni lo piensen dos veces. Tampoco esperen el momento adecuado porque eso no existe. Inténtalo, lánzate, vale muchísimo la pena. Se aprende mucho. Miedo y nervios los tenemos todos, pero es cuestión de intentar y seguir el camino que nos propongamos. Debes formar parte de proyectos como esto que te brindan nuevas experiencias y aprendizajes.
Luis C.: Todos fallamos, pero no está mal. Lo malo es no aprender de esos errores. Cada uno de nosotros hemos aprendido de nuestros errores dentro de todas las áreas. Es parte del proceso. Para aprender hay que dar un primer paso y ese paso es intentarlo.
Javier M.: No tengan miedo a fallar. Además, involúcrense en proyectos como este. No saben los aprendizajes que se pueden obtener de experiencias como esta. Yo he aprendido muchísimo con este grupo y somos muy buenos amigos. Uno nunca sabe hasta dónde va a llegar, así que siempre hay que tomar las oportunidades que se nos presenten.
Enzo C.: Para quienes lo dudan: si tienen ganas de algo, ¡esfuércense por ello porque vale la pena! Proyectos de este tipo ayudan a adquirir conocimiento y experiencia que, de manera teórica, no lo vas a conseguir. Además, esta experiencia te servirá a lo largo de tu vida, no solo para este concurso. Esto es invaluable.
Si quieren seguir de cerca el trabajo del MK-TEAM pueden hacerlo a través de su página en Instagram como @mkteam.grp y en Facebook como MKTeamGRP.
[:]