• Descarga | Suscripciones en iVoox / Apple Podcasts / Spotify / Google Podcasts •
Juegos Robótica episodio 15. ¿Cómo afrontar un proyecto o reto de robótica en equipo?
Bienvenidos a Juegos Robótica, el podcast en el que hablamos de robótica educativa, iniciación a la programación, aplicaciones para docentes, entornos de programación para niños y en general todo lo que tiene que ver con despertar la curiosidad de los más jóvenes por la programación y la tecnología para que se conviertan en creadores y no en meros consumidores.
Como ya sabes este podcast es un reflejo sonoro de los contenidos y cursos que puedes encontrar en juegosrobotica.es
Y recuerda que si quieres aprender a programar a través de la robótica o quieres formarte para enseñar a programar puedes darle un vistazo plataforma de cursos en juegosrobotica.es/cursos y acceder a la formación online más completa con robótica educativa por 10 euros al mes, aprendiendo desde la base y a tu ritmo.
Proceso de diseño de un robot.
En el episodio de hoy quiero contarte cómo es el proceso para llevar a cabo un proyecto de robótica. Puede ser que quieras afrontar un reto concreto o preparar un robot para una competición, y en cualquier caso es muy similar a la manera de trabajar de un equipo profesional a la hora de integrar una solución automatizada industrial.
La mayoría de los puntos que te voy a comentar hoy pueden parecer obvios pero no siempre se tienen en cuenta. Mi recomendación es que sigas esta dinámica siempre que quieras afrontar un proyecto de robótica en equipo, sobretodo de cara a una competición, pero en general siempre que trabajes en equipo.
En cualquier proyecto de automática te servirá entender cómo funciona un robot. Ten en cuenta que un robot tendrá que tomar decisiones a través de su programa continuamente y como idea general debes pensar que el robot se hará preguntas cuya respuesta debe ser si o no.
Por ejemplo un robot sigue líneas se preguntará si está en la línea de manera que si está en la línea avance en línea recta, pero si la respuesta es que no está en la línea deberá preguntarse por ejemplo si está a la derecha de la línea… y de nuevo la respuesta será positiva o negativa y en base a la respuesta actuará de una manera u otra.
Esta dinámica de preguntas y respuestas es mucho más fácil de ver y plantear mediante un diagrama de flujo o flujograma que intentar plantear directamente el programa.
Mediante un diagrama de flujo podemos observar la evolución y comportamiento del robot de manera clara siguiendo los diferentes caminos cuando tenga que haber una toma de decisión.
En el ejemplo sencillo de un siguelíneas habrá diferentes caminos que definirán las acciones a tomar dependiendo si el robot está sobre la línea, o se ha salido por la derecha o se ha salido por la izquierda. Un programa siguelíneas puede ser mucho más complejo, pero estoy tomando el ejemplo sencillo para explicarlo mejor.
Esa toma de decisión se toma en cada ciclo de programa, es decir, en el ciclograma iríamos tomando básicamente uno de los tres caminos (en línea, salida por la derecha o salida por la izquierda) y acabaríamos tomando una acción (seguir recto, girar a la izquierda o girar a la derecha) finalizando el flujograma.
En ese punto el camino del diagrama de flujo volverá al inicio para volver a decidir en qué lugar de la línea se encuentra el robot y así indefinidamente. Ese camino de retorno constante al inicio es lo que en programación llamamos bucle y se ve muy claramente en el diagrama de flujo.
Todas las tomas de decisión y el bucle principal o bucles secundarios son mucho más fácil plantearlos en un diagrama de flujo que en un programa aunque sea a través de bloques.
Te he contado todo esto para darte una primera premisa… utiliza diagramas de flujo para plantear tus proyectos de robótica, al menos en las primeras fases de diseño.
Otra recomendación es abordar los proyectos por partes e ir avanzando poco a poco, tanto a nivel de mecatrónica como a nivel de programación.
Si planteas un programa más o menos complejo de golpe será muy difícil de depurar porque los fallos que aparezcan serán complicados de identificar dentro de un programa grande.
Si vas programando poco a poco, probando un requerimiento sencillo y comprobando que no falla, y vas añadiendo funcionabilidades poco a poco, en el momento en el que algo no funcione como esperabas lo sabrás en el mismo momento en el que has añadido esa parte, por lo que será mucho más fácil identificar el error y solucionarlo.
Créeme si te digo que esta es una de las cosas que más tiempo te van a ahorrar y que aunque parezca lógica no se suele hacer.
A nivel industrial, en donde a un cliente se le entrega la solución completa en sus instalaciones, este suele ser el gran problema. Al haber previsto la solución integral y programado todo sin haber hecho el montaje, la fase de depuración del programa una vez ya instalado todo se alarga mucho y puede ser un problema. Por eso muchos integradores montan toda la instalación poco a poco en sus instalaciones, comprobando paso por paso que va funcionando la solución mientras se va desarrollando, para finalmente desmontar todo, trasladar a las instalaciones del cliente y volver a montar. Al final el sobrecoste de montar y probar previamente es menor que si hubiera que depurar todo al final.
En el caso de una competición de robótica no hay excusa en este punto, hay que probar todo lo que hagamos poco a poco según vayamos diseñando y programando nuestro proyecto, no dejar las pruebas para cuando el programa sea tan complejo que no haya por donde cogerlo.
Trabajar en equipo.
Ahora vamos a ponernos en la piel del equipo que se enfrenta a un reto de programación para preparar una competición de robótica por ejemplo.
Conocido el reto y las reglas de la competición lo natural es que el equipo ponga en común qué van a construir y programar. Cada miembro del equipo planteará un concepto de robot y seguramente que no coincidan.
Mediante el debate la mayoría del equipo llegará a un consenso sobre el proyecto que van a realizar, pero puede quedar algún integrante que no esté del todo convencido con la solución.
Es muy importante que todos los integrantes del equipo estén convencidos de que se ha elegido la mejor opción, por lo que se puede realizar una especificación de diseño para mostrar las ventajas de la elección.
En ingeniería se utiliza ese término de especificación de diseño, pero no debe asustarte el nombre… de hecho daría igual el nombre que le quieras poner. Simplemente se trata de documentar mínimamente la solución que hemos determinado por consenso indicando el diseño general, las partes principales que lo componen y sus ventajas o qué problemas será capaz de solucionar.
En este punto todos los integrantes del equipo ya deberían estar de acuerdo en que esa es la mejor opción. Si algún integrante no está realmente convencido será un problema más adelante, no dejes de debatir y llegar a una solución conjunta.
La especificación de diseño también nos ayudará en la siguiente fase a la hora de enfrentarse a un proyecto de robótica, ya que gracias a ella podemos identificar las diferentes partes que conforman la solución elegida.
En este punto hay que poder dividir el proyecto en diferentes partes o retos más pequeños y si fuera posible asignar cada parte a un integrante del equipo o varios.
Dar responsabilidad de cada parte del proyecto a un integrante ayudará a que el proyecto avance a buen ritmo. Aunque todos los integrantes se pueden ayudar cada uno se asegurará que la parte de la que es responsable no quede rezagada.
De hecho otro punto a tener en cuenta es los plazos que queremos marcarnos y el orden en el que hay que ir resolviendo las partes pequeñas del proyecto si es necesario que unas estén resueltas para abordar otras. Todo esto se puede controlar a través de un planning.
Recuerda que cuando hablamos de partes del proyecto estas pueden ser a nivel de montaje o de programación o de cualquier otro tipo como por ejemplo recopilación de información o documentación del proyecto. Todas son importantes para el éxito final.
Pues ahora con ese planning y orden de preferencia es el momento de ir poniendo todas las piezas del rompecabezas poco a poco, y comprobando bien su funcionamiento en cada nuevo paso como ya te comenté antes.
En el caso de un proyecto diseñado para una competición lo más importante es la fiabilidad, no dejéis de probar y seguir probando para asegurar que el sistema no fallará justo el día en el que todo debe funcionar a la perfección.
Para finalizar te invito a reflexionar y comparar lo que hemos visto con cualquier proyecto o reto que se pueda plantear a nivel personal en la vida adulta. ¿No crees que es interesante que los niños y jóvenes puedan aprender a trabajar en equipo antes de que se lo exija su trabajo?
Saber trabajar en equipo es una cualidad muy apreciada en un trabajador, pero nadie nos enseña a trabajar en equipo.
Proceso de diseño en ingeniería.
Te pongo un ejemplo de la manera de trabajar en ingeniería industrial a la hora de afrontar un problema.
En un proceso en ingeniería cuando aparece un problema o un requerimiento desgraciadamente no hay una solución mágica. Al contrario de lo que alguna gente cree al ingeniero no le vienen las soluciones ante problemas por inspiración divina instantánea.
De hecho la ingeniería se basa en un camino sistemático y lógico para identificar el problema de manera que permite encontrar la solución.
Estaría bien que el ingeniero ante un problema en vez de usar la magia se parase a recapacitar y le viniese una idea para solucionar el problema. Pero es muy probable que la primera idea no sea la ideal.
Por eso estudia detenidamente el problema y se plantea diferentes ideas para solucionarlo. No se queda con la primera idea que le viene sino que se esfuerza en reunir diferentes alternativas.
En ese punto, comparando las diferentes alternativas, se decide por la idea que considera más adecuada, y que no tiene por qué ser la primera. Entonces se pondrá a trabajar en ella e irá corrigiendo los problemas que se vayan dando para que esa idea funcione por sí misma y pueda solucionar el problema planteado en origen.
De la misma manera que he comentado anteriormente habrá menos problemas si investigamos antes y planificamos la puesta en marcha de la solución elegida.
En resumen un buen proceso de ingeniería, que se puede trasladar a un proyecto de robótica educativa, debe pasar por una fase de investigación, planificación, programación y prototipado y finalmente testeo y puesta en marcha.
Siguiendo estas fases a la hora de diseñar un proyecto y siguiendo las pautas para trabajar en equipo te aseguro que será mucho más fácil alcanzar la meta que quieras conseguir con tu proyecto de robótica o automática.
A través del soporte en la plataforma de cursos también os ayudo a dirigir esos proyectos y de hecho esta semana inauguramos una sección en la que mostraremos algunos ejemplos de proyectos de robótica en los que he ayudado a algún alumno o alumna.
Esto ha sido todo por hoy. Nos escuchamos en un próximo episodio con otros consejos a la hora de enfrentarse a un proyecto de robótica, o hablando de algún entorno de programación, un kit de robótica educativa o cualquier otra herramienta que nos ayude en el aprendizaje de la programación y la robótica.
Hasta entonces que tengas una feliz semana, nos vemos en siete días… adiós!
Actualización.
Quiero compartir en esta entrada el magnífico trabajo de Pedro Landín inspirando a sus alumnos para realizar infografías sobre el proceso tecnológico y sus etapas.
Por un lado les ayuda a diferenciar el proceso tecnológico del método científico, y por otro lado los alumnos aprenden a expresar sus ideas de forma esquemática a través de infografías con la utilización de Canva y Piktoarcht.
Es una muy buena idea como actividad en clase. Podéis ver los trabajos de sus alumnos de 2º de ESO en la entrada de su blog.
Deja una respuesta