IngPeq 01: La aventura del Faro¶

• IngPeq 01: La aventura del Faro
  • Objetivos
    • Botín para el equipo (Recompensas)
      • Acercamiento a la programación
      • Por que lo económico importa...
    • La edad del niño
  • Cómo nació la idea de compartir ésta aventura
  • Comienza la aventura
    • Especificación: partiendo de una frase.
    • Derivando el concepto técnico

Objetivos¶

Compartir la experiencia de haber desarrollado conjuntamente con un “peque” (Javier) un pequeño faro robotizado con materiales reciclados, pinturas, un arduino, software, pinturas y pegamentos, para que otras personas puedan repetirla y así pasar con sus “peques” un rato divertido e instructivo.

Partimos de un papel en blanco y cubrimos las siguientes etapas:

• Concepto funcional.
• Concepto técnico.
• Diseño preliminar.
• Prospecciones técnicas para validar fabricabilidad y tiempo de vida.
• Diseño detallado.
• Fabricación.
• Acabados.
• Envoltorios.
• Documentación del proceso en vídeo.
• Documentación del proyecto en web.

Botín para el equipo (Recompensas)¶

Cubriendo la experiencia del proyecto, el equipo recibe los siguientes premios:

• Para el "grandullón":
  • Una bonita experiencia compartida con su “peque”.
  • Nociones de mecatrónica.
  • Nociones sobre ingeniería “de andar por casa”.
  • Un faro robotizado.
  • y a ésto hay que sumarle las mismas recompensas, que está recibiendo el “peque”.
• Para el peque (como él lo expresaría):
  • ¡Una aventura alucinante con mi grandullón!
  • ¡He hecho un robot!
  • ¡Sé cómo hay que pensar para hacer robots!
  • ¡Tengo un super faro robótico que da vueltas suuuuumm suuuummm!

    

• Conviene re-enumerar las recompensas para el "peque", en un lenguaje más adulto, y extender la lista con todo aquello que recibe que él mismo no podría enumerar:
  • Obtiene toda la atención y complicidad del adulto.
  • Resuelve problemas que se le plantean.
  • Ejercita su nivel de abstracción.
  • Ejercita la deducción.
  • Comprende un proceso lógico de trabajo y lo sigue.
  • Se siente importante y valorado.
  • Aprende a especificar: se marca unos requisitos y trabaja hasta cumplirlos.
  • Recibe la recompensa de comprobar que lo que se especificó se consiguió.
  • Entiende que la acción de diseño es descomponer el problema grande en partes más pequeñas y semánticas.
  • Entiende que la acción de integración y fabricación es recomponer la solución de manera análoga a como se descompuso el problema.
  • Aprende a diseñar metódicamente derivando soluciones a partir de requisitos.
  • Aprende a diseñar heurísticamente tirando de catálogo.
  • Asiste a las deducciones lógicas del adulto, en aquellas partes que él no puede deducir.
  • Asiste a la búsqueda de soluciones de diseño o construcción del adulto.
  • Entiende las soluciones encontradas, las sabe explicar.
  • Aprende a formar parte de un equipo que persigue un objetivo más elaborado que un juego o un deporte.
  • Trabaja en equipo
  • Comprende el trabajo de los adultos, se hace una idea de cómo los adultos se ganan la vida.
  • Responde a muchas preguntas sobre cómo se inventan o se construyen cosas.
  • Se acerca al software desde el punto de vista de un diseñador de dispositivos.
  • Programa parte del software (la parte que decide el comportamiento del dispositivo).
  • Aprende lenguajes gráficos y hace diagramas que expresan ideas, composiciones, estructuras temporales, comportamiento.
  • Aprende a usar los ordenadores para crear algo, que es una faceta de la informática, nueva para él, que se suma a las que ya conocía: como herramienta educativa, de entretenimiento y de comunicación.
  • Aprende a editar comportamiento usando un lenguaje gráfico y formal.
  • Ve un chip (microcontrolador) en una placa electrónica, decide cómo se va a comportar y comprende el proceso de volcado del programa.
  • Aprende cómo un chip se comunica con el resto del mundo a través de sus pines.
  • Se da cuenta de cómo un chip puede contener un montón de procesos secuenciales en su interior, y que actúa como un director de orquesta de los elementos activos (botones, leds y motores) del producto.
  • Entiende cómo se fabrica un juguete “de los de pilas”.
  • Relaciona los elementos (dispositivos) activos con sus funciones: pulsar –> botón, iluminar –> LED, girar –> Motor, contar –> ordenador.
  • (y como ésto es una wiki, seguiremos enumerando más recompensas según se nos ocurran )

    

Acercamiento a la programación¶

Entre todas las recompensas que enumeramos, vamos a hacer “zoom” en una particular: el acercamiento del “peque” a la programación. Aquí, el que está escribiendo ésta línea (Txinto) adoptará un tono personal al escribir.

Como “niño” en los años 80, tuve la gran suerte de asistir al desembarco de la informática en los hogares. Viví la época de los 8 bits, de las revistas con listados, de los programas en cassette. En concreto, mi primer ordenador fue un Toshiba HX-10E, un MSX de 64kb, con un buen teclado. En aquél momento la mayoría de los juegos venían en cassette, y el cassette era un dispositivo de entrada y salida. Al contrario de las consolas (que en mi época y entorno aún no estaban), los ordenadores estaban pensados para consumir, y para crear. Es cierto que había juegos, pero éstos no venían en CD, ni DVD, ni bajaban de servidores. Había cartuchos pero sólo para algunos títulos. La cinta de cassette, como el disquette, era algo que podías ir a comprar virgen en la papelería de la esquina. Las revistas publicaban listados. Los ordenadores se vendían, de serie, con un manual en Basic y normalmente con un único juego de cinta y alguna aplicación también en cinta. Para cargar ese primer juego, ya tenías que teclear un comando de un lenguaje de programación. Al principio, tecleabas ese comando literalmente como un acto repetitivo, mientras te “cansabas” de ese primer juego. Pero había algún día en que el ordenador se quedaba así, en su pantalla de BASIC, esperándote. Hasta que algún evento (un listado de un juego que parece atractivo, hojear el libro de basic, que llegue un amigo y te explique lo que ha aprendido...) te animaba a escribir un:

10 print "hola" 

Luego ya querías que te preguntara por el nombre y te respondiera “Hola <nombre>” ...
Luego hacerle repetir 100 veces “No volveré a desobedecer a <nombre>”
Luego dibujar un túnel a base de hacer círculos cada vez más grande y moviendo su centro.
Luego que cada uno de esos círculos tuviese un color....

Seguro que en aquél momento, de habernos parado a pensar cuáles serían las competencias en materia de programación de un niño de 10 años en 2017 nos hubiésemos sentido incapaces de acotarlas. Hubiésemos pensado que con la programación tendría que pasar como el inglés. Pensaríamos que alucinaríamos como padres de la capacidad de nuestros futuros hijos, de la misma forma que nuestros padres habían alucinado al ver cómo nos manejábamos programándoles el vídeo.

Sin embargo, con poco temor a equivocarme, pienso que hoy en día los niños tienen un nivel de competencia en programación inferior al nuestro. Competencias digitales por las nubes, manejo de software superior, multimedia con el ordenador... fabuloso pero... programación? Los niños, en aquella época, estábamos invitados a la sala de máquinas del software, hoy en día no los dejamos salir del puente de mando.

¿Lo necesitan? Sí. Cada día veo profesionales de la ingeniería con los brazos atados por no saber hacer un script en Python o Ruby. Para cosas tan sencillas como automatizar una tarea repetitiva llamamos a un informático. Incluso sabiendo programar, nos restringimos a la parcela que se supone que dominamos y tenemos miedo a salir de ella: científicos que hacen programas de reducción de datos no intentan adaptar sus artes para, por ejemplo, crear un árbol de subdirectorios para alojar los datos de un nuevo experimento. No sabemos “customizar” nuestras herramientas software.

El desarrollo del faro nos obliga, al “grandullón” y al “peque” a programar. Gracias al Arduino, que nos vuelve a dar un espacio para poner seis o siete líneas en un editor de texto, y que esas líneas sean capaces de maravillarnos. Algo tan sencillo como mover un servo o encender un led, aún nos conmueve y nos hace sentir especiales. La mecatrónica y la automatización ha estado siempre tan oculta (incluso para nosotros, los “niños del basic”) que una pequeña aplicación que mueve unos relés para encender as luces tiene aún el poder de hacernos gritar “Eureka”.

Por eso creo que es tan importante regalarles lo que se nos regaló a nosotros.

Por que lo económico importa...¶

No nos engañemos: dar competencia de programación y mecatrónica a los niños no es nada nuevo. Desde hace tiempo prestigiosos colegios privados, corajudos colegios públicos, y multinacionales de los juguetes constructivos ponen en las manos de niños afortunados las herramientas para desarrollar juguetes mecatrónicos. Lego Mindstorms, Meccano Meccanoid, etc... abanderan toda una industria juguetera que vende precisamente eso: facilitar que el niño desarrolle la capacidad de crear sus propios proyectos robóticos.

¿Cuál es el problema de ésto? Por centrarnos en el más llamativo: el desembolso económico que implica. Esos juguetes no son baratos. A nivel mecánico están, normalmente, bien resueltos y compensados, pero a nivel de automatización suelen ser muy caros y muy poco potentes.

Ejemplo

Sólo la centralita de Lego ronda unos 200€, y tiene capacidad para conectar muy pocos dispositivos. Actualmente tiene una potencia “semejante” a una RPi (que viene a ser cuatro veces más barata, más flexible y con muchos más puertos). Antes el panorama era aún peor, ya que el modelo de centralita que ofrecían era aún más cara, y tenía una potencia similar a la de un arduino uno.

Un niño pintor va llenando lienzos, un niño dibujante va llenando hojas, un niño escultor va gastando barro, un niño “diseñador de robots” tiene que desmontar lo anterior para hacer lo nuevo. Es un juguete para diseñar juguetes, que en cuanto están acabados dejan de tener sentido. No es algo válido para sustentar una “fabricación”. Pocos padres tienen la capacidad económica suficiente para permitir que su hijo vaya construyendo (y disfrutando) sus propios juguetes, así que el niño queda modificando la forma en que interconecta y programa siempre el mismo conjunto de piezas, lanzando sus creaciones al olvido.

Eso por no mencionar que cada compañía juguetera te atrae hacia “encerrarte” en sus productos: las centralitas de la marca X sólo funcionan con los actuadores de la marca X. Las piezas tienen un precio que no te permite considerarlas “consumibles”.

O sea, que todo eso convierte la experiencia mecatrónica infantil en cosa de ricos o afortunados. Aún en el caso de que un niño acceda a ese material a través de un colegio público o concertado, no va a poder llevarse sus creaciones a casa.

Si alzamos un poco más la vista, si ampliamos el “horizonte mecatrónico” más allá de los juguetes para niños, nos encontramos con lo que hoy son los “juguetes mecatrónicos para adultos”: el mundo del Arduino. Gracias a ellos, a sus precios, a su disponibilidad, a la enorme comunidad... conseguimos hacer pequeñas aplicaciones tan satisfactorias que nos sentimos realizados a bajo coste y esfuerzo. Cada ejercicio de investigación o creatividad se ve recompensado.

Y ahora viene el ejercicio de honestidad: “Tú, superhombre, lo que estás haciendo ¿es que no lo puede hacer un niño?” La respuesta es no...... pero no anda lejos. Con nuestra ayuda, y con una pequeña inversión económica por nuestra parte, podemos abrirle a los niños la puerta al paraiso. Podemos regalarle lo que sentimos al programar unos futuristas ordenadores delante de nuestros padres, en aquél momento en que unos cuantos prints y un goto ya eran una receta mágica.

La opción Arduino no te va a permitir seguir viendo un partido de fútbol o una serie de TV mientras tu “peque” se convierte él solito en un genio. Olvida esa ida, eso no funciona así. Es una opción que te va a exigir que estés con él, una opción que sólo funciona en equipo, y que puede ser un verdadero frustre de lo contrario. Y no, no se hará un genio a base de conectar cables y teclear, pero sí ganará competencias y actitudes ante los problemas y la vida. Ampliará el conjunto de los problemas para los que existe una solución, y eso le ayudará a tener más confianza en sí mismo a la hora de encarar el mundo.

Por eso, por que el dinero no debe ser la barrera que impida a tu “peque” desarrollar su “sentido mecatrónico”, es por lo que se comparte ésta primera experiencia usando soluciones Arduino.

La edad del niño¶

Como ya dijimos antes, la competencia que ostenta un niño hoy en día para programar en software o hacer montajes electrónicos de hoy en día suele ser tan baja, que ésta aventura (por desgracias) aún ofrece muchas recompensas para niños de 15 años, y seguramente no diferirán tanto de las que reciben los de 6. Seguramente hasta los de ¡30 años! aprenderán algo!

Después de la experiencia con mi “peque” creo que de 6 años para arriba es una buena estimación. Como es un equipo de dos, cuanto más capaz sea tu acompañante, menos trabajo para tí, ¡y viceversa!

También ayuda (mucho) disponer de los elementos electrónicos de antemano, para que el niño pueda tocarlos y conocerlos desde el principio. Incluso si tienes más de los necesarios, mejor, podrás usarlos para reforzar el descarte de las opciones no adecuadas.

¡¡Bienvenidos a la aventura!!

Cómo nació la idea de compartir ésta aventura¶

Como ya se mencionó antes, el faro mecatrónico original de ésta historia respondía a un regalo que queríamos hacerle a la madre del “peque” con motivo del día de la madre. Queríamos hacer algo juntos, algo que representara una aventura para él, que le encantara y maravillara a ella, y que enlazara con las cosas que me gustan a mí. Si eres compositor haces una cancioncita, si eres buen dibujante un dibujo, todo el mundo sabe apreciarlo, pero ¿si eres ingeniero es que tienes alma de metal?

Entonces ideé unos primeros pasos a dar, muy improvisados, y me planté en la mesa de la cocina con dos montones de hojas de papel (uno para él y otro para mí). Le regalé un portaminas igual que el mío y le dije “es tu lápiz de ingeniero” y me dispuse a guiarlo para que enfrentara un proceso de desarrollo normal, con su especificación, diseño....
De vez en cuando, iba parándome para ver si el siguiente paso lo podía ir deduciendo él solito o con menos ayuda.

Al acabar aquella primera sesión me di cuenta de que habíamos asistido a un momento “mágico”, sentí una gran alegría, pero también me apenaba que su madre no lo hubiese podido ver por un agujerito mientras volcaba su ilusión e imaginación en aquellos papeles. Decidí, por tanto, que la segunda sesión se grabaría en vídeo y que recapitularíamos lo hecho en la primera. El resto de sesiones también se grabarían en vídeo. Y así ha sido: ha habido más momentos mágicos, y tenemos más de 8 horas de grabación. A lo mejor algún día se editan y se comparten

Nuestro faro era para un regalo, y teníamos sólo una o dos tardes por semana para avanzarlo sin que Mónica se enterase de lo que estábamos haciendo. Como un secreto: ¡aumentaba el nivel de aventura!

¿Qué pasa cuando tienes un secreto que guardar pero te encuentras eufórico? Que lo tienes que compartir con alguien. Y ahí, chateando lo que habíamos hecho con los miembros de Canarias Go Retro, al ver su reacción y los ánimos que nos mandaban, surgió la idea de recoger la experiencia y documentarla no sólo para compartirla con la madre, sino para compartirla con todo el que tenga un “peque” con el que lanzarse a la aventura.

Comienza la aventura¶

Partimos de dos “lápices de ingeniero” y dos fajos de papel (ideal si son para reciclar). Un lápiz y un fajo para el “peque” y el otro para “nosotros”. La idea es que empecemos a hacer los pasos en nuestro papel, con su ayuda, y que luego él lo transcriba en su papel, con nuestra ayuda. Hay que permitir (y alentar si ocurre) que cambie la forma en que expresa lo mismo, pero hay que ayudarlo para que siempre quede documentado de forma lógica y “legible”.

Especificación: partiendo de una frase.¶

Nuestra frase fué:

Queremos construir un faro que, cuando pulsas un botón, su luz se enciende y da 10 vueltas.

Ese es el objetivo. El niño, más adelante, volverá hacia esta frase y verá, con enorme satisfacción, que lo que ha construido la cumple. Que cumplir lo que nos prometimos es lo que valida que se ha hecho un buen trabajo.

Derivando el concepto técnico¶

Personalmente, llamo el concepto técnico a la solución técnica que se garabatea en un papel el primer día de un proyecto, que comparte todo el equipo. Ese bosquejo debe tener la virtud de convencer al equipo de que se encuentra ante un concepto que puede sustentar una solución válida, que desarrollarla es factible y que, organizativamente, el equipo es capaz de desarrollarla.

Aún no hemos diseñado, pero ya nos hemos “envalentonado” a pintar una primera solución, así al tún tún. ¿Al tún tún? ¿Seguro? Puede que sí o puede que no.

• “Puede que no” por que: quizás hayas seguido un proceso lógico de diseño rápido descendente y no te has dado cuenta.
• “Puede que sí” por que: hayas tirado de intuición o experiencias pasadas o de juntar elementos que suelen estar en ese ámbito... pero en ese caso ¿queremos realmente hacer las cosas al tún tún?

En nuestro caso no. Estamos guiando a un niño. No queremos darle la impresión de ser “magos”, queremos darle una herramienta que le haga creer que comprende cómo se desarrollan éstos dispositivos, de momento con nuestra ayuda, y darle también la impresión de que no está tan lejos el día en que podrá hacerlo él solito. Vamos a partir de la frase de especificación y ayudarle a “derivar” lógicamente un concepto técnico. Si él no es capaz de realizar éste paso, al menos asistirá al momento en que nosotros lo ejecutamos.

El método:

Primero vamos a ponerle un identificador a la función, F1, para poder llamarla así:

F1: Queremos construir un faro que, cuando pulsas un botón, su luz se enciende y da 10 vueltas.

Luego vamos a subrayar las acciones del sistema o del usuario que se encuentran “escondidas” en esa frase:

F1: Queremos construir un faro que, cuando pulsas un botón, su luz se enciende y da 10 vueltas.

Y ahora vamos a intentar encontrar los elementos clave que nos van a permitir realizar esas acciones:

• 'construir un faro’ –> algunos elementos físicos que puedan acabar teniendo el aspecto de un faro.
• 'pulsas un botón’ –> botón
• 'su luz se enciende’ –> bombilla
• 'da 10 vueltas’ –> motor

Pintaremos los elementos en el papel, tal y como vayan saliendo.

De momento, para el concepto, nos centraremos en los dispositivos “funcionales” y evitaremos dibujar los dispositivos “de soporte”. Un ejemplo de dispositivo de soporte es la batería, o el enchufe que nos provea electricidad. También la caja o platarforma para situar el faro y/o el botón, etc... Esos elementos ya aparecerán más tarde.

Una vez hemos puesto la bombilla, el motor y el botón deberíamos preguntarle (al peque) "¿nos falta algo?” y guiarlo un poco en su respuesta. El objetivo de éste punto es que él vea que le hace falta un “ordenador”, pero si sus respuestas se “desvían” hacia los dispositivos de soporte, también las aceptaremos y las pintaremos en nuestros diagramas.

A continuación unas preguntas que pueden ir bien para guiar éste paso del proceso:

• Si conectamos todo eso ¿funcionará? ¿por qué no?
• ¿Cómo sabe el faro que le han pulsado el botón?
• ¿Cómo sabe el faro cuándo se enciende y apaga la bombilla?
• Revisa la frase ¿hay alguna información que no estemos usando? (el número 10).
• ¿Cómo podemos conseguir que dé exactamente 10 vueltas, y no 1 o 1000? ¿Quién las cuenta?
• Si tú miraras el botón y pudieras hablarle a la bombilla para que se encendiera y al motor que se moviera, ¿funcionaría? Si es que sí... ¿qué podemos poner ahí para que te sustituya y lo haga solito?

Por la faceta de “director de orquesta” o por la de “contador”, por algún lado, llegará (o llegaréis) a la conclusión de que tienes que pintar un “ordenador”. Aquí es cuando va bien tener una Teensy, Arduino, PIC... cualquier tipo de microcontrolador para enseñárselo mientras le explicas que, ahí dentro, hay un ordenador entero. Sin teclado ni ratón ni tele, pero que es capaz de hacer todo el rato lo que tú le digas que haga. Y le avanzas que utilizarás un ordenador “grande” para programar el pequeñito, y que programarlo significa explicarle al micro qué es lo que tiene que hacer. El “ordenador pequeñito” se quedará dentro del faro controlándolo todo y gastando muy poquita energía.

Así pues, pintaremos un primer diagrama donde tenemos un botón, un faro, un motor, una bombilla, y con un ordenador en el centro.

Para dejar bien atado el concepto, intentaremos dibujar los diferentes estados principales del sistema, acompañándolos de dibujos de los elementos en los estados en los que se encuentra.

En el caso del faro, los dos estados principales son:

• Reposo:
  • Luz apagada.
  • Motor quieto.
  • Ordenador no está contando.
• Funcionando:
  • Luz encendida.
  • Motor dando vueltas.
  • Ordenador contando hasta 10.

¿Y el botón? El botón es lo que nos permite cambiar de reposo a funcionando, se puede pintar algo que lo ilustre, como en la frontera entre ambos estados.

Éste es un gran momento para una pausa. Ya tenemos el concepto técnico. Ahora nos podremos poner a discutir con él sobre la forma física que adoptará el faro, y sobre el resto de elementos que vamos a necesitar.

• Forma física, en nuestro caso:
  • Cuerpo del faro: una botella de cerveza Viru, muy bonita, que llevaba tiempo rondando por casa, que siempre nos evocaba un faro:
  • Cabeza del faro: una tapa de cristal de una azucarera, que había quedado “viuda” al morir el bote.
  • Soporte: una caja de madera de unos congelados del Lidl.

• Resto de elementos:
  • Cables para conectarlo todo.
  • Una fuente de electricidad:
    • Unas pilas
    • Un enchufe

Seguramente que tu peque y tú ya tenéis recursos para llevar ésta charla. Como dije antes, ayuda tener elementos en casa para presentarlos como candidatos y aceptarlos o desestimarlos.

Corregir y continuar......