Arduino en la Escuela

Propuesta de actividades
2023 - 08 - 01

Esta obra está bajo una Licencia Creative Commons Atribución-NoComercial-CompartirIgual 4.0 Internacional.

Índice

Índice        2

Módulo 1: Introducción a Arduino        3

Actividad 1: Explorando sensores y actuadores        3

Actividad 2: La automatización en la vida cotidiana        4

Actividad 3: Primeros pasos en programación        5

3.1 Prender o apagar        5

3.2 Prender y apagar        6

Módulo 2: Comandos y actuadores        6

Actividad 1: Conectando un led        6

1.1 Led fijo        7

1.2 Led programado        7

Actividad 2: Mensajes en clave morse        7

2.2 Código de luces        7

2.3 Código de sonidos        8

Actividad 3: ¿Qué más sabe hacer mi Arduino?        8

Módulo 3: Problemas, estrategias y subtareas        10

Actividad 1: La súper merienda        10

Actividad 2: Todos para uno y uno para todos        11

Actividad 3: Melodías divertidas        11

Módulo 4: Expresiones y sensores        13

En este documento resumimos algunas de nuestras propuestas para llevar a las escuelas la enseñanza de la programación a través de Arduino y la enseñanza de la electrónica aplicada. Lo confeccionamos en base a nuestras experiencias y nuestras ideas. Deben tomarlo como una guía por si no tienen nada planificado pero son libres de modificar lo que crean necesario para adaptarlas a sus clases o pueden utilizar otra planificación si ya tienen una preparada. En particular, esta secuencia didáctica está pensada para estudiantes sin conocimientos de electrónica y poca o nula experiencia en programación.

Módulo 1: Introducción a Arduino

Objetivos: Primer acercamiento a las placas y cómo interactuar con ellas.

Actividad 1: Explorando sensores y actuadores

Objetivos: Empezar a conocer los conceptos de sensores y actuadores. Distinguir las partes de un dispositivo con un comportamiento programado.

Desarrollo: La primera actividad se realiza sin computadoras y consiste en explorar algunos dispositivos construidos con Arduino y programados con Arduino en la Escuela. Cada dispositivo consta de un sensor y un actuador y presenta algún comportamiento simple que los conecte. Solemos arrancar todos los talleres con esta actividad porque funciona primero para romper el hielo con estudiantes (o docentes) que no se conocen entre sí (ni a nosotres) y segundo para que empiecen a acostumbrarse a los mecanismos de interacción de Arduino que se basan principalmente en la transmisión de información entre sensores y actuadores.

Los 3 dispositivos que solemos presentar son:

1. La luz inteligente: Una luz (representada con un led) que se enciende cuando está oscuro y su intensidad depende de la intensidad de la luz ambiente. A mayor oscuridad, mayor es la intensidad con la que se enciende el led. Funciona con un led como actuador y un ldr de 4 pines como sensor.
2. El asistente de estacionamiento: Un dispositivo que simula el asistente de estacionamiento de los autos modernos en los que se hace sonar una chicharra cuando se detecta cierta proximidad. En este caso se utiliza un buzzer como actuador y un sonar como sensor. Cuando la distancia medida es menor a cierto umbral, el buzzer comienza a sonar. Cuanto menor es la distancia medida más rápido suena.
3. Control de posición por joystick: Un servomotor que se puede controlar con la palanca de un joystick. La posición del sensor (la palanca) determina en qué ángulo se posicionará el actuador (el servomotor) para imitarlo.

Solemos dividir a la clase en grupos de no más de 4 personas y le damos un dispositivo a cada grupo para que lo analicen. La idea es que explorando (pero sin desconectar los cables) descubran cuál es su funcionamiento. Cada grupo deberá responder estas preguntas.

Cierre: Se hace una puesta en común para que une integrante de cada grupo cuente lo que el grupo descubrió. Intentamos describir en castellano el comportamiento de cada dispositivo. Definimos sensores y actuadores como módulos que sensan información del ambiente o que realizan alguna acción sobre él, respectivamente. Solemos comparar los sensores con los 5 sentidos y los actuadores con los músculos. Luego mencionamos que el Arduino en el cerebro que se encarga de conectar todo y de decidir qué acciones realizar (enviando señales a los actuadores) a partir de la información que tiene (observando los datos medidos por los sensores).

Actividad 2: La automatización en la vida cotidiana

Objetivos: Pensar qué otros sensores y actuadores existen (o podrían existir). Entender que la automatización en base a sensores y actuadores aparece en muchos lugares de nuestra vida cotidiana.

Desarrollo: Esta actividad consiste simplemente en pensar situaciones de la vida cotidiana en la que nos encontramos con algún tipo de automatización. Se les pide a les estudiantes que mencionen todos los que se les ocurran mientras anotamos los ejemplos en el pizarrón. Luego, por cada ejemplo encontrado pensamos qué sensores y qué actuadores intervienen y describimos cómo se usa la información sensada (por los sensores) para determinar las acciones ejecutadas (por los actuadores). A continuación presentamos una tabla con los casos que más suelen aparecer. Se puede usar para completar con casos adicionales que a nadie se les haya ocurrido.

Actividad 3: Primeros pasos en programación

Objetivos: Considerar la forma en que determinamos el comportamiento de una placa Arduino (a través de la programación). Aprender lo básico del entorno de programación Arduino en la Escuela. Programar un primer comportamiento simple.

Desarrollo: Ahora vamos a la computadora y abrimos Arduino en la Escuela. Para comenzar utilizaremos una placa sin conectarle ningún módulo. Observamos la interfaz de Arduino en la Escuela y explicamos sus principales componentes:

• El espacio de bloques, donde vamos a armar el programa que determinará el comportamiento del Arduino.
• El bloque principal que contendrá la descripción del programa.
• La caja de herramientas, de donde podemos tomar nuevos bloques y arrastrarlos al espacio de bloques para construir el programa.
• Los controles para ejecutar y verificar el código.
• Los controles para abrir y guardar el proyecto.

3.1 Prender o apagar

Como primer programa haremos que el Arduino encienda el led incorporado. De esta forma podemos aprender a programar la placa sin necesidad de empezar a conectarle módulos. Dejamos un rato para que exploren y se acostumbren a la herramienta y luego hacemos la puesta en común. Para encender el led incorporado tomamos el bloque “encender led incorporado” del cajón “actuadores” y lo agregamos dentro del bloque principal. Con esto ya podemos usar el botón para ejecutar el código y comprobar si el Arduino se comporta como esperamos. Es importante hacer esta prueba cuanto antes para comprobar que no haya inconvenientes para subir el código a la placa. Algunas cosas a verificar:

• La placa debe estar conectada a la computadora.
• La placa conectada debe ser la misma que la configurada en el menú de ajustes.
• El puerto seleccionado en el menú de ajustes debe coincidir con el puerto en el que está conectada la placa.

Aprovechamos esta oportunidad para mencionar la salida del IDE de Arduino en donde se nos mostrarán los mensajes del mismo. Cuando el programa se haya compilado y subido correctamente aparecerá el mensaje “Código subido exitosamente”. En otro caso, esta ventana mostrará un mensaje de error. Preguntamos cómo lo hicieron para ver si alguien encontró otra forma de resolverlo o se trabó y no pudo completar la consigna. Algunos errores comunes:

• Usar el bloque “encender led en pin” en lugar del bloque “encender led incorporado”.
• Dejar el bloque suelto en lugar de meterlo dentro del bloque principal.

Cuando todes hayan podido subir su primer programa cambiamos el código por uno que apague el led incorporado, cambiando el bloque “encender led incorporado” por “apagar led incorporado” y volvemos a ejecutarlo.

3.2 Prender y apagar

En este punto es interesante preguntarnos cómo hacer que la luz parpadee. Dejamos un rato para que exploren a ver qué pueden hacer y luego hacemos puesta en común. Ver si alguien lo consiguió y ver en dónde se trabaron (o qué intentos hicieron) quienes no. La intuición podría llevarnos a poner los dos bloques, uno debajo del otro. Habrá quienes también repitan esa secuencia de dos bloques varias veces pensando en que debería prenderse y apagarse varias veces. En ambos casos el resultado será que el led quedará fijo con intensidad media. Esto es porque el parpadeo se ejecuta demasiado rápido y al ojo humano no llegamos a percibirlo. La solución es intercalar los bloques con comandos para esperar una determinada cantidad de tiempo (por ejemplo, un segundo). De esta forma, podemos controlar cuánto tiempo queda encendido y cuánto tiempo queda apagado (notar que se necesitan ambos bloques ya que con uno sólo el led quedará siempre prendido o siempre apagado). En cuanto a la necesidad de repetir la misma secuencia varias veces, se puede aprovechar para mostrar que sólo es necesario describir una repetición y que el comportamiento de Arduino consiste en repetir esa misma secuencia indefinidamente (esto es así por defecto pero puede modificarse desde el menú avanzado del bloque principal). Si hay interés se puede indagar en cuál podría ser la razón de tal comportamiento (sobre todo si ya programaron antes en otros entornos en los que la ejecución termina cuando se acaban los bloques). La respuesta es que las tareas para las cuales se suelen utilizar las placas Arduino suelen ser comportamientos que se espera que se repitan indefinidamente. Recordar el comportamiento de los aparatos vistos en Explorando sensores y actuadores o todos los ejemplos de La automatización en la vida cotidiana. ¿Tendría sentido que se ejecutaran una única vez y luego se apagaran?

Cierre: Usando bloques podemos darle instrucciones al Arduino y de esta forma definir su comportamiento. Los bloques de comandos que ingresemos dentro del cuerpo del bloque principal serán los que se ejecuten cuando subamos el código a la placa. Los comandos se ejecutan en orden, uno tras otro y al finalizar vuelve a empezar. El bloque principal tiene un menú avanzado (que se abre con la flechita blanca) que permite modificar, entre otras cosas, el comportamiento por defecto del programa principal (si se ejecuta una única vez y termina o se ejecuta en ciclo indefinidamente).

Módulo 2: Comandos y actuadores

Objetivos: Empezar a extender los posibles comportamientos de Arduino con actuadores. Desarrollar programas más complejos utilizando herramientas de lógica y programación. Introducir los conceptos de comando y de procedimiento.

Actividad 1: Conectando un led

Objetivos: Conectar un primer módulo al Arduino. Aprender sobre los principios básicos de la electrónica. Conocer los pines de la placa.

Desarrollo: Esta actividad comienza con una explicación simple de cómo funciona la electricidad. En nuestros talleres solemos explicarlo de forma vaga ya que no es sobre eso que queremos poner el foco pero ustedes pueden aprovechar si tienen que dar contenidos relacionados. Para continuar, alcanza con entender que un dispositivo eléctrico funciona cuando se cierra el circuito. Para ello, hay que conectar a la corriente las terminales positiva y negativa.

1.1 Led fijo

Usaremos un led para ejemplificar. El led es un diodo y sólo tiene dos patitas (pines) para conectar. Cada pin se corresponde con una terminal. El pin más largo es la terminal positiva y el más corto es la terminal negativa.Conectamos el pin positivo al pin 3.3V del Arduino y el pin negativo al pin GND del Arduino. Explicamos que esto es como enchufarlo a la pared ya que está recibiendo corriente constantemente, sin importar lo que haga el programa del Arduino. En general no va a ser esto lo que queramos hacer. En general vamos a querer que sea el Arduino quien prende y apaga el led.

1.2 Led programado

El pin 3.3V del Arduino está enviando corriente constantemente. Para poder controlar cuándo se prende y se apaga necesitamos controlar ese flujo de corriente. Para eso, cambiamos la terminal positiva del led y la conectamos en uno de los pines digitales. Estos pines tienen la particularidad de que su flujo de corriente se puede controlar desde el Arduino. Funcionan como una canilla que deja pasar o impide el flujo de corriente. Una vez reconectado el pin positivo del led volvemos a Arduino en la Escuela para escribir el programa que queremos. Esta vez, en lugar de usar el bloque para encender el led incorporado, usamos el bloque que enciende un led externo. Este bloque permite seleccionar el pin en el que se encuentra conectado el led que queremos encender. El mismo bloque permite apagar el led cambiando la opción seleccionada en el menú desplegable. Combinando este bloque con el bloque de espera utilizado ya en el módulo anterior podemos crear una secuencia para que el led se encienda y se apague. Para esta actividad también está bueno dejar un tiempo de indagación aunque es probable que lo hagan rápido ya que el comportamiento es muy similar al anterior pero cambiando el bloque usado para encender el led. Algo interesante que se puede mostrar es que el bloque del led tiene una opción para agregarle una duración desde el menú avanzado (que se abre con la flechita blanca). Esto simplifica bastante el programa ya que ese bloque reemplaza al bloque que enciende, al que espera y al que apaga.

Cierre: Recordamos que los módulos que conectamos necesitan electricidad para funcionar. En el caso de los diodos, sólo tienen dos pines que podemos usar para crear un circuito. Si reciben corriente por el pin positivo, se encienden. Hablamos de los pines del Arduino, que son los conectores que nos permiten agregarle módulos. Por ahora conocemos los de corriente (3.3V y GND) y los digitales. Así como sucede con el led, vamos a ver que la gran mayoría de los bloques requieren elegir los pines en los cuales conectamos los módulos. También hay varios bloques que pueden personalizarse con opciones adicionales desde el menú avanzado.

Actividad 2: Mensajes en clave morse

Objetivos: Escribir un programa no trivial que use un módulo. Escribir un programa con un objetivo claro.

Desarrollo: Contamos un poco sobre el lenguaje basado en el código morse que permite codificar mensajes asignándoles secuencias de sonidos a las letras. Usando alguna hoja de referencia (que pueden conseguir buscando en internet) deberán escribir mensajes en código morse.

2.2 Código de luces

En una primera instancia utilizaremos el parpadeo de un led en lugar de sonidos (la principal razón para esta decisión es que termina resultando molesto tener un montón de Arduinos reproduciendo chillidos en la misma aula). Se pide primero que determinen tiempos para representar el punto y la raya y luego que armen y reproduzcan una palabra completa. Pedimos primero que “escriban” sus nombres.

2.3 Código de sonidos

Una vez terminado el programa proponemos pasar a usar sonido en lugar de luces. Es recomendable que lo vayan haciendo de a poco para que no estén todos los Arduinos sonando a la vez. Lo interesante es que no es necesario volver a programar la placa, ya que al ser el buzzer también un diodo, funciona exactamente igual que el led. Esta situación se puede aprovechar para mostrar el código generado por el programa que sólo tiene un bloque para encender un led y por el programa que sólo tiene un bloque para hacer sonar el buzzer (son exactamente iguales y lo que hacen es enviar corriente por el pin seleccionado). Queda a consideración de cada docente si quiere meterse o no con el código generado. En caso de no querer hacerlo, aún así es buena idea contar que ambos bloques se traducen al bloque de escritura digital que puede elegir si escribir HIGH o LOW para dejar pasar o impedir el paso de corriente. De esta forma concluimos que el Arduino en realidad no sabe prender luces o activar buzzers. Sólo sabe enviar corriente por determinados pines y el efecto que ese pasaje de corriente tenga dependerá de lo que le hayamos conectado en los pines en cuestión. Como actividad adicional les pedimos que ahora escriban la palabra “TEMA” pero ahora usando tiempos particulares para los puntos y las rayas:

Cierre: Retomamos la idea de que la placa sólo sabe decidir si dejar pasar o impedir el flujo de corriente, además de controlar el tiempo. Mencionamos (haciendo referencia al código si decidió mostrarse o al bloque de escritura digital si no) que se usan los valores HIGH y LOW para representar el paso de corriente o su ausencia, respectivamente.

Actividad 3: ¿Qué más sabe hacer mi Arduino?

Objetivos: Introducir procedimientos para poder ordenar mejor el código, facilitar la reutilización y la corrección de errores y mejorar la legibilidad.

Desarrollo: Siguiendo con la idea de la actividad anterior, mostramos una posible solución al ejercicio de “escribir” la palabra “TEMA” en código morse. Pedimos como una nueva actividad que ahora escriban la palabra “MATE”. Después de un par de minutos (dejamos poco tiempo intencionalmente, la idea es que no lleguen a terminarlo) les pedimos que dejen lo que están haciendo y ahora escriban “MAAATE” y repetimos. Al poco tiempo hacemos una puesta en común rápida mostrando posibles soluciones. Luego mostramos una solución de “TEMA” hecha con procedimientos, habiendo definido un procedimiento para cada letra y mostramos lo rápido que podemos convertirla en una solución para “MATE” y luego para “MAAATE”. Les preguntamos si cuando les cambiamos el ejercicio empezaron de cero o modificaron lo que ya tenían hecho. En la solución sin procedimientos parece ser mucho más complicado hacer seguimiento del código e identificar los puntos del mismo en los que se deben realizar las modificaciones. Si bien estos bloques violetas no se corresponden con cosas que el Arduino sabe hacer, son cosas que podemos enseñarle a hacer. Introducimos el concepto de procedimientos como el mecanismo que nos permite definir nuevos comandos. En otras palabras, enseñarle al Arduino a hacer cosas que antes no sabía hacer. Para ejemplificar, intentamos escribir una nueva palabra (por ejemplo “MANTEL” para aprovechar las letras ya definidas). Mostramos cómo tomar un bloque de procedimiento y ubicarlo en el código. Se usa como cualquier otro comando pero tenemos que ponerle un nombre. Lo nombramos “Decir N” y agregamos otro para “Decir L”. Ahora podríamos probarlo para ver si funciona pero nos va a saltar el error de que estos dos nuevos procedimientos no están definidos. Dijimos que definir un nuevo procedimiento es equivalente a enseñarle al Arduino a hacer algo pero ahora le estamos pidiendo hacer cosas (decir “N” y decir “L”) que no le enseñamos. Cuando le enseñamos a hacer algo, tenemos que explicárselo en términos de cosas que sí sepa hacer. Mostramos la definición de los procedimientos. En este punto me gusta usar la siguiente analogía: Si llega alguien al colegio y no sabe dónde queda la dirección, no podemos decirle “andá a la dirección” porque no sabe dónde está. Pero si primero le enseñamos cómo llegar, dándole instrucciones como “subí la escalera”. “doblá a la derecha en el pasillo”, etc, luego podemos decirle “andá a la dirección” y va a saber hacerlo. Hacer hincapié en la diferencia entre “enseñar a hacer algo” (el bloque de definición de procedimiento) y “pedir que se haga eso” (el bloque de uso de procedimiento). En la analogía de la dirección, yo puedo todos los días darle las instrucciones a la persona para que llegue o puedo una vez decirle “para llegar a la dirección tenés que hacer tal, tal y tal” pero al haber dicho eso sólo le enseñé cómo llegar a la dirección; no le pedí todavía que vaya. Recién después de haberle dado esa explicación puedo pedirle todas la veces que quiera “andá a la dirección”. Está bueno también mostrar en el código sin procedimientos qué parte del programa se corresponde a qué letra para que quede claro que no estamos inventando cosas nuevas sino que le estamos dando nombres a cosas que el Arduino ya sabe hacer.

Cierre: Empezar definiendo “comando” que, a pesar de que los venimos usando desde el principio, nunca nos detuvimos a definirlos. Los comandos son las acciones que el Arduino puede realizar. Los que estuvimos usando hasta ahora son “comandos primitivos” ya que “vienen” de antemano. Son las cosas que Arduino ya sabe hacer y no hace falta que le enseñemos. Los procedimientos en cambio son comandos que podemos definir nosotres. Destacar la importancia de los procedimientos y las múltiples ventajas que nos otorga. En primer lugar hace que el código sea más fácil de leer (se pueden comparar dos programas que escriban palabras en morse, uno escrito con procedimientos y otro sólo con primitivas y mostrar que el primero se entiende instantáneamente mientras que en el otro es imposible saber qué palabra se está escribiendo sin ponerse a hacer un seguimiento detallado del código). Facilita la modificación del código y la detección de errores (se puede recordar el caso de convertir “TEMA” en “MATE”). También facilita la reutilización (para escribir “MAAATE” fueron necesarias tres letras “A” pero no hubo que volver a escribir todos los comandos que la componen cada vez sino que la definimos una vez y la usamos 3 veces). Recordar la diferencia entre la definición de un procedimiento y la invocación del mismo ya que es algo con lo que se suelen confundir bastante. Siguiendo la analogía, el bloque de definición expresa el proceso de enseñanza, pero al enseñar sólo le estoy explicando cómo hacerlo, no le estoy pidiendo que lo haga. El bloque de invocación sí detona la ejecución del comando (el equivalente en la analogía a pedir que se realice aquello que acabo de enseñarte). Para definir un nuevo procedimiento debo elegir un nombre y definir su comportamiento a partir de otros comandos (que pueden, a su vez, ser procedimientos). Vamos a insistir mucho en que pongan nombres descriptivos a los procedimientos. Por último, se puede mostrar que todos los procedimientos que ejecutan letras reutilizan los bloques que ejecutan puntos y líneas así que también podríamos definir los procedimientos “Punto” y “Línea”.

Módulo 3: Problemas, estrategias y subtareas

Objetivos: Introducir mediante diferentes actividades los conceptos de “estrategia de solución”, “resolución de problemas top-down” y “división en subtareas”. Alentar el uso de procedimientos y reforzar sus múltiples ventajas. Introducir el concepto de parametrización.

Actividad 1: La súper merienda

Objetivos: Presentar un problema en el que se admiten múltiples soluciones posibles. Estructurar la solución utilizando la estrategia top-down.

Nota: Esta actividad no tiene nada que ver con Arduino pero nos parece importante realizarla en este punto para evitar (o al menos, reducir en lo posible) propagar malos hábitos de programación. Puede ser reemplazada por cualquier otra actividad que ponga en juego los mismos conceptos.

Desarrollo: Esta es una actividad sin computadoras en la que se propone escribir una secuencia de instrucciones para “preparar una merienda”. Las instrucciones se las vamos a dar a un robot que sólo conoce algunos comandos primitivos pero que tiene la capacidad de aprender nuevos comandos. Algunos posibles comandos primitivos:

Lo interesante es que no hay una solución única ya que cada quien escribirá su propia solución en base a lo que le gusta merendar. Mientras estén trabajando, preguntar si alguien le está enseñando nuevos comandos al robot o si están escribiendo todos los comandos uno detrás de otro. Para la puesta en común hacemos una solución en el momento, a partir de sugerencias pero usando la metodología top-down. Es importante escribir la solución en el momento y no mostrar una terminada para que vean cómo es el proceso de división en subtareas. Deberíamos llegar a una solución como esta:

Cierre: Mencionar que la forma en que resolvimos este problema se llama “top-down” porque consiste en pensar primero en “lo de más arriba” (es decir, “lo más genérico”, “lo más abstracto”) y descomponer el problema en problemas más chicos para ir “bajando” (es decir, continuar con “lo más específico”, “lo más concreto”). Esta metodología es la que vamos a seguir en adelante. Primero analizamos el problema y describimos la solución de la forma más general y concisa posible (por ejemplo, diciendo que vamos a hacer exactamente lo que el enunciado pide que hagamos). Luego planteamos la estrategia a partir de problemas más chicos (más simples) que combinados resuelvan el problema principal. A esto lo llamamos división en subtareas. Luego definimos un nuevo procedimiento para cada subtarea y volvemos a empezar con el método hasta que las subtareas sean tan simples que puedan expresarse en términos de comandos primitivos.

Recordar que en Arduino en la Escuela también podemos definir procedimientos y que los comandos primitivos de Arduino son sólo la escritura digital y la espera. Encender el led es algo que alguien más le enseñó al Arduino a hacer. Cuando resolvamos problemas con Arduino, no pensemos en cómo resolver el problema con lo que Arduino sabe hacer. Pensemos primero qué queremos lograr y enseñémosle a Arduino a hacerlo usando procedimientos. Cuando estemos en el proceso de enseñanza, también seguimos pensando en qué queremos lograr. Si necesitamos hacer cosas que Arduino no sabe hacer, primero suponemos que sí lo sabe, usamos bloques de procedimientos como si fuesen comandos primitivos de Arduino y luego le enseñamos a Arduino a hacerlos.

También se debe remarcar el hecho de que cada quien llegó a una solución distinta pero que todas son correctas porque cumplen la consigna. En general, los problemas admiten varias soluciones válidas.

Actividad 2: Todos para uno y uno para todos

Objetivos: Practicar la metodología top-down en Arduino en la Escuela.

Desarrollo: Mostramos en el pizarrón cómo hubiéramos resuelto el ejercicio de decir “TEMA” en morse usando Arduino en la Escuela y usando la metodología top-down recién explicada. Primero creamos un procedimiento para enseñarle al Arduino cómo decir “TEMA”. Luego tenemos que escribir la definición. Habíamos dicho que para enseñarle algo nuevo tenemos que hacerlo usando cosas que ya conoce. Pero aplicando división en subtareas, podemos pensar procedimientos para cada letra, como habíamos hecho en el módulo anterior. Estamos enseñando algo que no conoce usando otras cosas que tampoco conoce. Pero eso no es ningún problema porque podemos enseñarle estas otras cosas después, y eso es lo que vamos a hacer. Para escribir cada letra, también hacemos división en subtareas, creando los procedimientos “Punto” y “Raya” (que definiremos más adelante). Al finalizar, pedimos que cada estudiante escriba “todos para uno y uno para todos” en código morse. No hace falta que lo terminen, pero si siguen la metodología top-down es posible que lo hagan, o al menos que avancen bastante más rápido que en las actividades anteriores.

Cierre: Volvemos a destacar la utilidad de los procedimientos y comparamos lo rápido que avanzaron en esta actividad en comparación a las actividades anteriores en las que sólo ponían comandos primitivos y apenas llegaban a escribir unas pocas letras. Volvemos a recordar la metodología top-down que consiste en plantear la estrategia para resolver un problema grande, dividirlo en subtareas y definir procedimientos para cada una de ellas.

Actividad 3: Melodías divertidas

Objetivos: Introducir el concepto de parametrización. Ampliar la capacidad de reutilizar código por medio de parámetros (ya no sólo reutilizamos código idéntico sino también código parecido).

Desarrollo: Primero explicamos la consigna. Deberán elegir una melodía y programar al Arduino para que la toque. Les pasamos el link a la lista de melodías entre las que pueden elegir y les explicamos cómo están escritas. Cada canción es una lista de notas. Cada nota a su vez viene acompañada de un número entre paréntesis correspondiente a la duración en milisegundos de dicha nota. Los guiones bajos son silencios. Entonces, la secuencia C4 (250) __ (500) D4 (250) dice “tocar la nota C4 por 250ms, hacer silencio por 500ms y tocar la nota D4 durante 250ms”. Además, después de tocar cada nota (o cada silencio) se debe esperar una cantidad de milisegundos igual a la duración de la nota tocada antes de empezar a tocar la nota siguiente. Por último, les mostramos cómo hacer para que el bloque del buzzer funcione con notas, cambiando el selector de intensidad (en el menú avanzado del bloque) al valor “nota”. Ahora sí les dejamos un rato para que trabajen con la melodía elegida. Después de un par de minutos sugerir que definan procedimientos para cada nota. Después de un rato se puede hacer una puesta en común en la que se muestre que hacer procedimientos en este caso no está siendo de tanta ayuda como en los casos anteriores. Definir un procedimiento para cada nota no sirve porque no siempre suenan con la misma duración. Lo correcto sería hacer un procedimiento para cada par nota-duración (un procedimiento “C4 250”, otro “C4 125”, etc.). Haciendo eso el código queda bastante bien pero nos obliga a definir cientos de procedimientos que son todos muy parecidos. Mostrar 3 de las definiciones con la misma duración pero con distintas notas, una sobre la otra para que se vea que sólo cambia la nota que se toca pero que los bloques son los mismos. Luego mostrar los 3 bloques de uso y compararlo con alguno de los bloques que ya viene en Arduino en la Escuela, por ejemplo, el de espera (este está bueno porque es bien simple). Hacer notar que no hay un bloque para esperar un segundo y otro bloque para esperar 2 segundos sino que son el mismo bloque que tiene un agujero para pasarle la cantidad de segundos que se quiere esperar. Mostrar que el bloque numérico se puede sacar (algo que puede ser que hasta ahora no haya surgido) y al sacar los 3, quedan 3 bloques idénticos. Volver ahora a los bloques de uso y mencionar que estaría bueno que la nota elegida, que parece estar escrita sobre el bloque como la palabra “esperar” en el bloque de espera, sea un agujero como la duración en el bloque de espera. Esto es complejo así que es importante detenerse hasta que todo el mundo entienda lo que estamos sugiriendo. Una vez que parezca quedar claro qué es lo que queremos podemos volver a la definición y mostrar cómo parametrizar un valor dentro de una definición. Esto se puede hacer desde el menú desplegable haciendo clic derecho sobre el bloque que queremos parametrizar (la nota) y eligiendo la opción “parametrizar”. La herramienta nos pregunta qué nombre queremos ponerle al parámetro. Preguntarles qué nombre le pondrían. Es probable que respondan “C4” (suponiendo que es “C4” el bloque sobre el cual realizamos la acción) pero hay que hacerles entender que lo que estamos haciendo justamente es que un mismo procedimiento funcione para cualquier nota, no sólo para C4. Entonces, el nombre debería ser “nota”, “nota elegida” o “nota a tocar”. Una vez que queda claro eso le damos aceptar y vemos qué cambió. Por un lado, el bloque del buzzer en la definición que antes decía “tocar C4” ahora dice “tocar nota”. Esto significa que la nota que va a tocar ya no es necesariamente C4. Es interesante preguntar qué nota se va a tocar cuando se ejecute ese bloque. ¿Se va a tocar C4? ¿Se va a tocar la nota “nota”? Pero “nota” no es una nota. ¿O sí? Alguien quizás diga que se va a tocar C4 porque es lo que le estamos pasando como argumento. Si eso pasa aprovechar para ver lo otro que cambió. En el bloque de uso, donde antes estaba escrito “C4” ahora sigue diciendo “C4” pero ya no está escrito sobre el bloque del procedimiento sino que es un agujero. Volver a compara este bloque con el bloque de espera. En ambos casos lo que pasa es que ese agujero nos brinda un pedazo de información adicional. El bloque de espera está definido una única vez (aunque no podemos ver esa definición) y podemos usarlo pasándole en el agujero la cantidad de tiempo que querramos. Pasa lo mismo con el procedimiento que acabamos de construir. En la definición dice “tocar nota” porque lo que hace es tocar “la nota recibida por parámetro”. No sabemos en principio cuál es esa nota pero sabemos que, sea cual sea, es la que vamos a tocar. Crear otro bloque de uso para el procedimiento parametrizado pero ahora cambiando la nota en el agujero por otra (por ejemplo D4). Esto sirve para mostrar que no siempre se va a tocar C4. Cuando se ejecute el bloque “tocar C4” en la definición, “nota” va a valer “C4” pero cuando se ejecute el bloque “tocar D4”, “nota” va a valer “D4”. Los parámetros son valores que no sabemos cuánto valen y que recién cuando se esté ejecutando el programa van a tomar un valor particular. Además, puede ser que ese valor sea distinto en distintos momentos del programa. Mostrar que, ahora que tenemos el procedimiento parametrizado, podemos deshacernos de todos los procedimientos que usaban la misma duración pero distinta nota y reemplazarlos por el parametrizado. Y no sólo reemplazamos esos 3 sino que ya tenemos definido el procedimiento para cualquier nota. Sin parámetros, cada vez que querramos una nueva nota, tendríamos que definir un nuevo procedimiento. Con parámetros, sólo tenemos que crear un bloque de uso nuevo para el procedimiento parametrizado y ponerle en el agujero la nota que queremos tocar. No olvidar cambiar el nombre del procedimiento ya que ahora no puede llamarse “Tocar C4” (porque ya no es cierto que siempre es C4 la nota que toca) sino que debería llamarse simplemente “Tocar”.

Extensión: En este punto puede que sea bueno detenerse y pedir que, aplicando lo que acabamos de ver sigan por su cuenta. El bloque se puede seguir parametrizando para que sea también paramétrica la duración pero quizás es demasiada información junta y sea preferible esperar a que se acostumbren al uso del procedimiento con un parámetro antes de ver cómo parametrizar un segundo valor. Si se sigue por esta vía, sería necesario definir un procedimiento para cada duración (que igual no son muchos porque suelen repetirse bastante) y lo siguiente se puede realizar en una próxima clase. Si no, igual es recomendable dejarles trabajar un rato con lo visto porque puede que alguien pregunte si no se puede hacer lo mismo con la duración. La respuesta es que sí se puede. Ya sea porque alguien lo sugirió o porque fuimos nosotres quienes preguntamos si no se puede mejorar aún más está bueno preguntarles cómo harían o qué parametrizarían. Quizás alguien sugiera parametrizar tanto la duración de la nota como el tiempo de espera después de tocarla. Incluso si nadie lo sugiere, está bueno ver primero esta alternativa. Nos quedaría un procedimiento con 3 parámetros. Lo que debería llamarnos la atención es que en todos los bloques de uso los dos parámetros numéricos son iguales. Esto es porque uno depende del otro. No hace falta pasarle dos veces la misma información. Podemos usar el mismo parámetro “duración” como duración de la nota y como tiempo de espera después de haberla tocado. Esto está bueno porque se muestra por un lado, que un procedimiento puede tener más de un parámetro y por otro, que un mismo parámetro puede utilizarse más de una vez en una definición.

Cierre: Seguimos viendo formas de escribir código de forma más prolija, más legible y más eficiente (en tanto no tenemos que escribir las mismas instrucciones una y otra vez). Al definir procedimientos pudimos darle un nombre a una secuencia de comandos particular, lo que nos permitió poder nombrarla cada vez que la necesitemos, en lugar de tener que escribir los comandos que lo componen cada vez. Eso sólo nos servía si los comandos eran exactamente los mismos. Al agregar parámetros, podemos nombrar no sólo a una secuencia particular sino a todas las que sean parecidas entre sí (variando únicamente algunos valores). Así como pasa con los procedimientos, con los parámetros también vamos a insistir mucho en que usen nombres descriptivos. El nombre no debería corresponderse con algún valor particular que el parámetro pueda tomar sino que debería describirlos a todos. En el caso de las notas “C4” es un valor particular que el parámetro puede tomar así que no es un buen nombre ya que podría tomar un valor diferente a C4. Sí son buenos nombres “nota”, “nota elegida” o “nota a tocar” ya que en cualquiera de los casos se está describiendo cualquiera de los valores que el parámetro puede tomar (no importa si es C4, D4 u otra, siempre va a ser una nota).

Módulo 4: Expresiones y sensores

Objetivos: Seguir extendiendo los posibles comportamientos de Arduino a través de la incorporación de sensores. Empezar a definir comportamientos automáticos como los vistos al principio (un actuador que reacciona a un sensor). Introducir los conceptos de expresión, de función y de alternativa condicional. Tener un primer acercamiento a los tipos de datos.

Actividad 1: Cada cosa en su lugar

Objetivos: Introducir las expresiones y distinguirlas de los comandos. Seguir trabajando con la noción de parámetros. Asociar sensores con expresiones y actuadores con comandos.

Desarrollo:

Cierre: Retomamos la actividad anterior para mostrar que los parámetros no fueron algo nuevo sino que ya veníamos trabajando con parámetros casi desde el principio (el único bloque que no tenía ningún parámetro era el del led incorporado). Si bien nuestros programas consistieron siempre en secuencias de comandos, usábamos todo el tiempo estos bloques de parámetros para proveer información adicional sobre qué hacer. Definimos a estos bloques que proveen información adicional como expresiones. Si los comandos son las acciones que el Arduino puede ejecutar, entonces las expresiones son los datos que el Arduino puede interpretar (debería sonarles a actuadores y sensores). Hacemos notar que la gran mayoría de los bloques tiene una de dos posibles formas: la forma de bloque de comando (recto a la izquierda y muescas arriba y abajo) o la forma de bloque de expresión (recto arriba y abajo y con una orejita a la izquierda). Tanto los bloques de comandos como los bloques de expresiones pueden tener agujeros para parámetros. Estos agujeros, casualmente, tienen la forma justa como para conectar una expresión y por eso los llamamos “agujeros de expresiones”. Los agujeros de comandos también existen y tienen la forma de una letra “C”. Los vimos en los bloques de definición de procedimientos y en el bloque principal. Dejar clara la distinción entre “expresión” y “parámetro” que suele confundir. Todos los datos son expresiones. Decimos que una expresión es un parámetro si es un agujero en una definición. Es decir, “parámetro” no es una categoría sino un rol. Podemos decir que “una expresión está siendo usada como parámetro de un procedimiento”.

Actividad 2:

Objetivos:

Desarrollo:

Cierre:

Actividad 3:

Objetivos:

Desarrollo:

Cierre:

[MÓDULO EN DESARROLLO] La idea de este módulo es presentar distintos sensores y ejemplos minimales que se pueden construir con ellos. La presentación será similar a la realizada en la planificación del taller pero se explorará primero el uso de sensores sin presentar la alternativa condicional, por ejemplo, conectando la salida de un sonar a la entrada de un servo y así generar un comportamiento enlazado sin primitivas de control en el medio. Luego se desarrollará la actividad propuesta en planificación del taller para presentar la alternativa condicional, el sensor de luz, la distinción entre pines digitales y analógicos y las operaciones booleanas (la comparación primero y la conjunción después).