Habiendo jugado un poco con Arduino para entender cómo funcionaba y se controlaban los componentes que se le conectan, comenzamos a enfocarnos en pruebas más específicas en relación a nuestro proyecto. Seguimos con el concepto de "Divide y vencerás" y nos pusimos pequeñas metas:
- Activar un sensor de movimiento, y que este ejecute un sonido
- Activar dos sensores de movimiento, cada uno con su propio sonido
- Contemplar las diferentes combinaciones de uso con ambos sensores
Activando un sensor de movimiento
Para controlar la interacción del usuario usamos el componente HC-SR04. Básicamente, detrás de este nombre técnico con el que se lo conoce, se trata de un sensor de movimiento. Lo que hace este componente es emitir una señal y un receptor se encargará de recibir la respuesta a dicha señal en cuanto sea interceptada.
Internamente, mediante unos cálculos se puede saber a qué distancia estaba el objeto contra el que chocó. Pero no hay que ser expertos en física o ponerse a programar una lógica compleja para probarlo! Para eso están las bibliotecas de Arduino, las cuales ya traen encapsulado el código que nos servirá para probar todo esto. Sólo teníamos que saber cómo se conectaba y hacer uso de esas funciones, sumado a mucha "prueba y error".
Con un tutorial y el diagrama de conexión ya teníamos el sensor calculando distancias.
Además, parte de la meta era disparar un sonido en cuanto la señal del sensor chocase con algo. Y esto ya no era un "BIP" de los del Buzzer sino que necesitabamos que sea un sonido en serio :P - Averiguamos y lo que necesitabamos era un shield reproductor de Mp3. Recordando que los shields aumentan las funcionalidades que un Arduino brinda, este shield lo que hace es integrar las funciones de un reproductor de Mp3 al Arduino. Es decir (play, pause, stop, next, prev). Existen decenas de shields diferentes de este tipo, pero sólo encontramos uno que se vendiese por MercadoLibre por Capital y alrededores.
Acá de nuevo, una biblioteca haría de intermediario entre nuestro código y el shield reproductor de Mp3 para que implemente la lógica que quisieramos al tocar el sensor.
Como se puede ver, es como si estuviéramos controlando un reproductor mp3, pero a la distancia mediante gestos. Los resultados empezaban a motivarnos.
Dos sensores, sonidos independientes
Conectamos en paralelo los dos sensores, y duplicamos la lógica para ejecutar los sonidos teniendo en cuenta de qué sensor se trataba. Nos acercamos al resultado final esperado:
Prueba integral
Con cada sensor ejecutando su correspondiente sonido, solo quedaba contemplar cualquier caso que el usuario pudiera hacer. Por ejemplo, tocar dos sensores a la vez, o dejar de tocar un sensor y volver a tocar el mismo. Como el shield se basa en la funcion de next() y prev() para pasar de tema, tuvimos que implementar una lógica interna para que nos lleve al tema deseado teniendo en cuenta cual era el sensor que se estaba tocando (para que no sucediése que un sensor termine tocando el tema del otro sensor).
De yapa, le agregamos los sonidos de percusión que formarían parte del prototipo final:
Acá fue cuando nos dimos cuenta de un gran error que cometimos: No averiguar en detalle con anticipación qué estabamos comprando. Igualmente, todo salió bien, pudimos usar el shield como queríamos - pero en otro caso, esto podría haber significado un gasto innecesario. De todos modos, la lógica a programar fue más difícil que con el segundo shield que terminamos comprando para el segundo módulo. Este último shield, traía una manera más simple de elegir el tema que queríamos tocar. Igualmente, todo esto sucedio por las limitaciones del mercado, de hecho, este segundo shield tuvimos que mandarlo a tarer de Mar del Plata.
Otra dificultad que tuvimos fue que los sensores no eran 100% precisos. A veces las mediciones que registraban de distancia no reflejaban la realidad. Por ejemplo, de manera aleatoria marcaban como si la señal hubiese sido interceptada, cuando en realidad no lo estaba. Esto haría que sin acción alguna del usuario, se empezara a reproducir un sonido de manera inadecuada e inesperad. Por suerte, para todo problema Google tiene una solución (¿?), ni estamos solos, la comunidad Arduino es grande y a alguien también ya le paso lo mismo. Por lo que diseño su propia biblioteca para resolver esto. Usando esta nueva biblioteca para optimizar las mediciones del sensor pudimos evitar estas imperfecciones.
Nos hubiera gustado que la altura a la cual el usuario coloca su mano con respecto al sensor regulase el volúmen del sonido emitido. Pero se venían encima los tiempos de entrega, sumado a las limitaciones de los shields, por lo que esto tuvo que quedar como un "nice to have".
Proceso completo:
- Ciudad Animada: Lanzamiento TPH B
- Ciudad Animada: Juntos podemos más
- Ciudad Animada: Planning y Primeras Propuestas
- Ciudad Animada: Pruebas Generales con Arduino
- Ciudad Animada: Pruebas Específicas con Arduino
- Ciudad Animada: Presentación y Prototipado
- Ciudad Animada: Exponiendo en el CMD
