STM32F4: Cómo utilizar el ADC con DMA

Para este post, continuando con los post de esta placa, veremos los primeros pasos a dar para comenzar a obtener datos del ADC utilizando el DMA.

Pero la primera pregunta que debemos contestar es ¿qué es el DMA? El DMA (Direct Memory Access) es una forma de leer o escribir en memoria sin utilizar la CPU de la que disponen ciertos elementos como el ADC. Esto significa que no estamos perdiendo tiempo de CPU en procesar las muestras, por lo que éstas se procesan en background y mientras podemos estar haciendo otra cosa. Además, esto permite que las muestras de una señal no se pierdan por tiempo de procesado de la CPU.

CONFIGURACIÓN INICIAL

Abrimos CubeMX y habilitamos el ADC como en pasados tutoriales, pero esta vez habilitamos la opción de DMA Continuous Requests.

Configuración ADC

En ese momento, en la pestaña de DMA Settings tenemos que añadir un stream que tenga las características que se muestran en la imagen y después comprobar que en NVIC Settings de éste está habilitado. Es importante prestar atención al tipo de buffer a utilizar. Para esta primera prueba utilizaremos el normal, y después pasaremos al circular, puesto que es el que nos permite tener una captación de datos continua y renovada.

Ajustes para usar el DMA con el ADC

Tenemos que mantener el timer interno funcionando como en el tutorial anterior, ya que así garantizamos que estamos tomando las muestras correctamente, pero también se puede utilizar el ADC con DMA sin timer.

LECTURA Y REPRESENTACIÓN DE LA SEÑAL

Empezamos arrancando el timer y el ADC, pero para este último, utilizando las funciones que están relacionadas también con el DMA (como HAL_ADC_Start_DMA). Esta última función tiene como uno de sus argumentos el tamaño de los datos que vamos a leer.

Tras esto, haciendo uso de las funciones relacionadas con el DMA y el ADC, podemos controlar cuando ha terminado la lectura para, en ese momento, guardar los datos. De hecho, podemos controlar tanto la transacción completa como la mitad de la misma. Se deja la implementación al lector.

Finalmente, representamos estos datos para saber si lo estamos haciendo bien, (considerando que la configuración del timer es la misma que en el ejemplo anterior y la señal de entrada también). Manteniendo esta configuración y cambiando el buffer del DMA a circular en adc.c (hdma_adc1.Init.Mode = DMA_CIRCULAR;), lo que conseguimos es que el array donde se actualizan los datos esté en continuo cambio, pero hasta que no se detecta el fin de la transacción, no se guarda. La representación sería la misma en los dos casos (normal y circular).

Representación de los datos procesados por el DMA del ADC

 

Nota: la imagen de la portada se ha obtenido de CocoaStream Technologies.

STM32F4: Configuración del ADC con un timer

Este tutorial debe seguirse después de haber realizado el tutorial sobre la configuración y el uso básico del ADC, el cual se encuentra en la lista de tutoriales de la placa de desarrollo STM32F4.

 

CONFIGURACIÓN INICIAL

Timer externo:

En este caso, en CubeMX, también seleccionamos el pin PA1 como pin de entrada al ADC, pero además, en las opciones de la izquierda que se muestran al desplegar el ADC1, debemos seleccionar External-Trigger-for-Regular-Conversion. Esto se debe a que vamos a utilizar un timer para controlar cuando realizamos las lecturas del ADC. Por lo tanto, tenemos que habilitar este timer también. Podría ser cualquiera de los que muestra cubeMX, nosotros hemos elegido el timer 1, canal 1. Entre las opciones posibles para su configuración, hemos elegido PWM generation CH1, para así utilizar la información de uno de los anteriores tutoriales, aunque ésta no sería la única opción.

Todo esto puede verse reflejado en la imagen siguiente, donde encontramos los pines ADC1_TIM1, TIM1_CH1 y ADC1_EXTI11, la casilla de External-Trigger-for-Regular-Conversion marcada y el timer configurado como PWM.

Pinout ADC – PWM Timer

Al activar estas opciones, la configuración del ADC y del timer es la que encontramos en las imágenes siguientes. En cuanto al timer, hemos impuesto una frecuencia de 1 KHz y un ciclo del 50%. Sabiendo que la frecuencia del sistema es de 96 MHz, nos queda la siguiente igualdad:

(Preescaler + 1)x(Periodo + 1) = fclk/fPWM

Donde suponemos el preescalado y el periodo y obtenemos el pulso.

Configuración del ADC y del PWM Timer

Se deja al lector la implementación del timer externo sin configuración PWM.

Timer interno:

Para este otro caso, seleccionamos un timer que no tenga muchas funcionalidades, como el timer 2 (TIM2). En la opción clock source, seleccionamos Internal Clock, y después en la pestaña de configuración, ponemos la misma configuración que teníamos con el PWM en los campos que sean iguales.
Es importante seleccionar en “Trigger Event Selection TRGO” la opción de Update Event.

 

LECTURA Y REPRESENTACIÓN DE LA SEÑAL

Timer externo:

Ahora conectaremos el pin asociado al TIM1_CH1 con el pin asociado al ADC1_EXTI11 con un cable externo, y el generador de funciones en la entrada del ADC (PA1). Estas señales se pueden visualizar en el osciloscopio para comprobar que efectivamente es como esperamos.
Pasamos la configuración de CubeMX a Eclipse. Ahora no solo tenemos que iniciar el ADC sino también el timer. Después, la toma de datos sería de la misma forma que en el anterior tutorial. Se deja al lector la tarea de implementar el código, sería necesario el código del tutorial anterior del ADC y del tutorial relacionado con el timer.

Sin embargo, aquí tenemos que tener en cuenta el teorema de Nyquist, puesto que ahora tenemos una frecuencia de muestreo conocida. La señal de entrada será de 50 Hz, ya que así dispondremos de 20 muestras por período. El array en el que se guardan será de 100 muestras, por lo que tendremos 5 períodos de una representación muy aproximada de la señal, como bien puede observarse en la imagen.

Señal de 1 KHz procesada por el ADC
Timer interno:

En este caso no sería necesario conectar ningún cable adicional.
Tras pasar la configuración a Eclipse, iniciamos el timer de una forma diferente a la anterior, utilizando la función HAL_TIM_Base_Start(&htim2). Y ya podríamos correr nuestro código.

 

Nota: la imagen de la portada se ha obtenido de Jóvenes Científicos

STM32F4: Configuración y uso básico del ADC

Como continuación de los tutoriales relacionados con la placa de desarrollo STM32F411E-Discovery, en este post vamos a explicar las nociones básicas para el uso del ADC.
El ADC (Analog to Digital Converter) es un elemento que se utiliza en electrónica para convertir una señal analógica en una señal digital, es decir, es la comunicación entre Hardware y Software. Al permitir esta comunicación, el ADC se convierte en un elemento fundamental a la hora de poder utilizar las señales digitalmente.

En este tutorial aprenderemos el funcionamiento básico para realizar la lectura de un dato y de una señal, sin utilizar el DMA.

 

CONFIGURACIÓN INICIAL

El primer paso es utilizar CubeMX, al igual que en el resto de tutoriales. Para entender la configuración básica nos basamos primero en lo que nos cuentan los documentos relacionados con nuestra discovery (manual de usuario y manual de referencia) y con el ADC, y segundo en lo que nosotros buscamos obtener. Esto implica conocer los siguientes conceptos sobre la configuración:

  • Clock Prescaler: la frecuencia a la que se capturarán datos del ADC.
  • Scan Conversion Mode: este modo se activa cuando queremos usar varios canales del ADC.
  • Continuous Conversion Mode: al activarlo el ADC se pone a leer muestras de forma continua.
  • Discontinuous Conversion Mode: se utiliza para convertir un grupo cerrado de conversiones.
  • DMA Continuous Requests: se habilita cuando queremos utilizar el DMA.
  • End Of Conversion Selection: este flag se utiliza para determinar cuando se ha realizado una conversión.
  • Number of Conversion: determina el número de canales que van a realizar conversiones.

En este caso, el trigger externo no es necesario, por lo que se deja la opción de configuración mediante el software. Las opciones de Rank se dejan por defecto salvo que en los documentos anteriores nos indique lo contrario.

Por tanto, escogemos el pin PA1 como ADC1_IN1 y seguimos la configuración que puede verse en las imágenes. Tras lo cual, podemos pasar el código a Eclipse (el resto de pines que se ven marcados son los que se marcan al aceptar la configuración por defecto).

Configuración del ADC
Pin del ADC

Es importante tener en cuenta que aunque el modo continuo esté habilitado, si el modo End Of Conversion Selection está habilitado sólo se realizará una lectura.

 

LECTURA DE UN POTENCIÓMETRO

Conectamos un potenciómetro a la discovery, siendo la salida la conexión con el pin PA1 y los otros dos pines se conectan a VDD (alimentación) y GND (masa).

Entonces, dentro del main.c, tenemos que utilizar una función que permita empezar la conversión, otra que compruebe que el ADC está funcionando de forma correcta (utilizando la opción de polling) y otra que permita leer el valor del ADC. Se deja al lector la implementación de estas 3 funciones, las cuales pertenecen a la HAL – Hardware Abstraction Layer (es decir, aquellas funciones que permiten la interación entre Hardware y Software). Por ello, es conveniente revisar estas funciones, explicadas en este link. El valor deberá ser guardado en una variable.

Finalmente, compilamos y lanzamos el debugger. Al darle a empezar lo que tendremos será el valor que el ADC ha leído del potenciómetro una vez, el cual se encuentra entre 0 y 4096 (debido a los 2^12 bits que tiene el ADC). Para tener claro si el valor es leído correctamente, lo mejor es hacer 3 medidas: una con el potencióemtro en el mínimo (la variable tendría un valor cercano a 0), otra con el potenciómetro en el máximo (la variable tendría un valor cercano a 4096) y otra con el potenciómetro en el valor intermedio (la variable tendría un valor cercano a 2048).

Para leer la variable es necesario pausar la reproducción y poner el cursor encima de la variable en cuestión.

 

LECTURA DE UNA SINUSOIDE

El siguiente paso a dar es conseguir leer una sinusoide correctamente, es decir, teniendo en cuenta que la frecuencia de la señal obtenida es la misma que la de la sinusoide de entrada.

Conectamos el generador de funciones al pin PA1 y generamos una sinusoide de 1 KHz. El uso del osciloscopio para comprobaciones de entrada o salida es opcional y su uso se deja a elección del lector.

Las propiedades del ADC que tenemos que cambiar son las siguientes:

  • hadc1.Init.ContinuousConvMode = ENABLE; — Si lo teníamos DISABLE.
  • hadc1.Init.EOCSelection = DISABLE;

Esto se puede hacer directamente en el archivo adc.c, no es necesario ir a cubeMX a cambiar la configuración.

Sería necesario un array en el que guardar las muestras necesarias para la lectura de la sinusoide. Tras recoger las muestras, es necesario comprobar la señal que se está guardando a partir de estas muestras, lo cual se puede hacer utilizando cualquier herramienta que permita la representación de datos. En este caso, hemos utilizado MatLab, y lo que hemos obtenido es lo que se muestra en la imagen siguiente.

Sinusoide obtenida con los datos leídos del ADC

Podríamos pensar que ha funcionado correctamente al ver la imagen, pero si tenemos en cuenta que tenemos un array de 1000 elementos y una señal de entrada de 1 KHz, deberíamos estar haciendo 1 lectura cada milisegundo como máximo, y entonces podríamos ver un período de la señal. Si realizáramos lecturas más rápidas, veríamos menos de un período; y si son más lentas estaríamos perdiendo muestras y la señal no sería la misma. El problema es que no sabemos a qué velocidad se está realizando la captura y lectura de datos del ADC, pero por la imagen podemos deducir que lo que ocurre es el último caso. Las lecturas son más lentas, lo que provoca que estemos perdiendo muestras, y al perder muestras, para rellenar el array, necesitamos muestras de períodos siguientes, lo que hace que en su representación se observen varios períodos.

Una forma de intentar corregir este aspecto es aumentar la frecuencia de muestreo. Si no conseguimos una buena representación ni cuando la aumentamos, esto quiere decir que la limitación se encuentra en el tiempo que tarda el microcontrolador en procesar las instrucciones, y ahí poco podemos mejorar.

 

CONCLUSION

En este tutorial hemos aprendido a configurar un ADC y a realizar lecturas del mismo, tanto individuales como continuas. Pero los resultados muestran que esta forma de obtener datos solo es útil si buscamos obtener datos independientes o de forma continuada pero lenta.

Para mejorar este comportamiento tenemos dos opciones: utilizar interrupciones o utilizar el DMA. Ambas formas son explicadas en los siguientes tutoriales.

 

Nota: La imagen de la portada ha sido obtenida de THine Electronics

The Twelve Of B105 – Smart Fridge

Con este post de octubre completamos el primer año de…

theTwelveOfB105

Y qué mejor forma que hablando sobre nuestra nevera inteligente. Ésta, al igual que el futbolín, es un desarrollo propio 100% B105.

Esta idea surgió de la necesidad de disponer de un control tanto de las existencias como del dinero, que luego permitiera la correlación entre ambos. Además, se llevaría un registro sobre quién compra qué cosa. Así, el sistema ayudaba tanto a las personas que realizaban el pedido como a las personas que compraban, dándoles información relacionada con lo que podían comprar y sobre el dinero disponible en su cuenta.

Para su implementación fue necesario el uso e integración de diferentes tecnologías. Era necesario la comunicación entre el sensor de huellas y la Raspberry Pi, que a su vez debía conectarse con la pantalla táctil y con la página web. Debido a esto, no sólo fue necesario trabajar con Python, sensores y pantallas, sino que también había que hacer uso de las herramientas necesarias para construir una web como son HTML, CSS o Javascript.

fridge

Este sistema fue realizado en un Trabajo Fin de Grado, el cual dispone de su correspondiente post. Desde entonces no ha caído en el olvido, sino que sigue en continua revisión y actualización.

Esto es todo por este mes. Siempre podéis consultar el resto de temáticas ya abordadas en el siguiente link. Podéis seguir nuestro progreso en las redes sociales (@elb105). ¡Os esperamos!

The Twelve Of B105 – WSN & Firefighting

Y aquí estamos de nuevo, tras unas buenas vacaciones y con las pilas cargadas. Eso sí, conscientes de que la vuelta puede ser algo dura, esperamos suavizarla con una nueva entrega de…

theTwelveOfB105

Todos habremos oído de los graves incendios forestales que se producen periódicamente en nuestro país. Acrecentados por el cambio climático, estos desastres naturales ya no solo se limitan a periodos estivales (enlace), extendiéndose a primavera y otoño.

Con el fin de atajar este problema, hace unos años se realizó una gran inversión en investigación e innovación para la prevención y lucha contra incendios con Prometeo. Este proyecto se enfoca desde un punto de vista integral, considerando todos los actores involucrados en las labores de monitorización y extinción.

Imagen post (2)

El papel de nuestro grupo fue el desarrollo de una red de sensores inalámbrica para detectar la presencia de fuego, y monitorizar variables ambientales relacionadas con el proceso de ignición. El sistema se diseñó con vistas al bajo coste y baja ocupación del espectro, además de no requerir de otras infraestructuras de telecomunicaciones (p.e. GSM, WiFi, etc.).

La red a desplegar consta de dos tipos de nodos:

Centrales: con un alcance de comunicación de hasta 15 Km, estos nodos agrupan y coordinan la información recopilada por los nodos sensores, además de incorporar otras funciones de gestión de red.

Sensores: encargados de la monitorización del entorno, incorporan sensores de temperatura, humedad, niveles de CO y CO2, y velocidad y dirección del viento. Su diseño de bajo consumo, basado en el procesador MSP430 de Texas Intrument, garantiza una vida útil de dos años con tan solo una batería de 600 mAh.

Nueva imagen de mapa de bits (2)

Este proyecto, probado y finalizado hace unos años, tuvo recientemente un impacto mediático considerable.

Y con esto acabamos por este mes. Esperamos que os haya resultado interesante, al igual que las pasadas entregas, y… ¡nos vemos el mes que viene!

 

How to deploy a Node-Red environment on a GCP instance

Son numerosos los tutoriales en Internet que explican cómo montar un servidor Node-RED sobre GCP haciendo uso de clústers. Sin embargo cuesta encontrar (si es que los hay), tutoriales sobre como desplegar dicho servidor en una instancia, por lo que en este tutorial, nos centraremos en este caso. ¿Te suena a chino todo lo que hemos dicho? ¿Por qué montarlo sobre una instancia y no un clúster? Expliquemos brevemente los conceptos más raros de la frases anteriores para entendernos mejor.

  • Node-RED: es una herramienta de programación, de libre distribución, la cual nos permite de una forma rápida, y sobretodo muy intuitiva, desplegar una web con un estilo moderno y funcional. Node-RED hace uso de la programación “en cajas”, en la cual interconectamos distintos bloques ya pre hechos de las librerías disponibles. Node-RED usa Javascript y permite introducir bloques con nuestro propio código, pero para las tareas más sencillas no será siquiera necesario saber Javascript. Un ejemplo de un desarrollo simple en Node-RED sería el siguiente:

node_red_example

Node-RED permite además añadir librerías creadas por usuarios, siendo la librería “dashboard” una de las más populares, pues incorpora cajas con elementos visuales que permiten la interacción con el usuario así como la visualización de datos. Un ejemplo de ello:

maxresdefault

¿Fácil, verdad? Quien diría viendo esa web que se ha hecho sin necesidad de saber ningún lenguaje, solo juntando las cajas correctas. Existen otras opciones, como thingsboard.io, pero para gustos los colores, además de no ser la mayoría gratuitas (o tener planes gratuitos muy limitados). Nosotros preferimos Node-RED porque integra soporte para comunicaciones por UDP, TCP y el reciente MQTT, lo que permite comunicaciones con cualquier tipo de dispositivo, especialmente con dispositivos IoT. Además, la comunidad de desarrolladores es enorme y podemos encontrar muchos ejemplos ya hechos para su libre distribución, siendo estos ejemplos a veces, justo lo que buscamos.

Tenemos muchas formas de ejecutar Node-RED, en nuestro PC (esto es corriendo en un servidor local), en páginas que ponen a nuestra disposición servidores ya montados y listos para empezar a trabajar (FRED) o en servidores virtuales privados (VPS) de los cuales hay cientos de ofertas en Internet (aunque destacan por su catálogo y precios Microsoft Azure, Amazon Web Services [AWS] y Google Cloud Platform [GCP]). Las ventajas de ejecutar nuestro entorno en un VPS frente a nuestro ordenador o un entorno ya hecho (y cerrado) son inmensas: disponibilidad total, herramientas de protección, escalabilidad, no compromiso de nuestros datos privados, gestión de recursos… y esas son solo alguna de ellas.

  • Google Cloud Platform: es uno de los tantos servicios de gestión de VPS que hay hoy en día. Si bien es cierto que uno de los que más fuerza tiene es AWS, Google ofrece algo que no ofrece el resto: un servidor gratuito al año con 24/7 en ejecución. Vale que es un servidor muy modestito (10 GB de almacenamiento; 0.6 GB de RAM y un único procesador), pero es gratis y para diseños simples puede ser más que suficiente. Es por esto que nos centraremos en este gestor VPS en este tutorial.
  • Instancia vs. cluster: Google denomina a cada uno de los VPS que creamos instancia. Un grupo de instancias trabajando de forma conjunta, compartiendo recursos y distribuyéndose el tráfico de red entre ellas forma un clúster. Claro, a priori parece que el clúster es mejor (y lo es), pero no es gratis. La instancia, sin embargo, sí. Siempre y cuando esa instancia sea de las más simples de Google, como ya hemos comentado antes.

Ahora que ya hemos explicado todo un poco, relee si quieres el primer párrafo del post. Ahora ya parece obvio por qué queremos desplegar Node-RED (y no otro) sobre una instancia (y no un clúster), porque…

free

 

Empecemos…

Lo primero, lógicamente, es tener una cuenta de Google activa. Nos dirigiremos a la consola de Google Cloud y activaremos nuestra cuenta, registrándonos en la versión de prueba gratuita.  Solo por registrarnos Google nos regala 300 $ en servicios GCP. Para nuestros propósitos no nos harán falta, pero nos vendrán genial si queremos cacharrear con todas las opciones que GCP ofrece. Completaremos todos nuestros datos (incluida la tarjeta de crédito, pero no pasa nada: Google nos avisará previamente en caso de que hiciéramos algo que incurriera en un desembolso). Tras registrarnos se nos creará nuestro primer proyecto (que podremos renombrar si queremos pinchando en configuración de proyecto).

En el buscador escribimos Compute Engine y en la nueva ventana, una vez cargue, creamos una nueva instancia, con la configuración que vemos en la siguiente imagen:

g1
La zona da igual siempre que sea en América (salvo Virginia del Norte). América es la única región con VPS gratuitas. El tipo de máquina ha de ser micro y permitir el tráfico HTTP y HTTPS. Nosotros hemos elegido Ubuntu por familiaridad con los comandos, pero cualquier otra distribución de las gratuitas que ofrece Google es válida. Notad que para saber que estáis siguiendo los pasos correctos, debe apareceros el texto de la derecha donde os informa de que la máquina seleccionada es gratuita. Pulsamos en crear y esperamos.

Una vez creada, hay diferentes cosas que sería interesante hacer antes de empezar a cacharrear (asignarnos una IP estática y abrir algunos puertos).

-Asignando IP estática podremos entrar en nuestro servidor sin necesidad de consultar qué IP nos ha concedido Google esta vez: siempre será la misma. Para ello escribimos Red de VPC en el buscador y entraremos en la sección del menú lateral izquierdo “Direcciones IP externas”. Seleccionaremos nuestra instancia y cambiaremos su tipo a estática. Le ponemos un nombre identificativo a esta IP y aceptamos.

-Abriendo puertos (bien sea TCP o UDP) permitiremos un acceso remoto a nuestro servidor. Hay que notar que esto es un arma de doble filo, pues si bien no podemos hacer mucho sin tener acceso a nuestro servidor remoto también es una puerta abierta a hackers, por lo que recomendamos abrir solamente los puertos que vayamos a necesitar. En nuestro caso será obligatorio abrir el puerto TCP 1880, pues será el que usará Node-RED tanto para la interfaz de diseño (donde colocaremos las cajitas) como para la interfaz web (donde nos mostrará el resultado de colocar y conexionar esas cajitas). Para ellos tecleamos en el buscador “Reglas de cortafuegos” y elegimos la opción que lleve también escrito Red de VPC.

Creamos una regla nueva:allowtcp

 

El nombre es opcional, todo lo demás, recomiendo dejarlo a esos valores. Cuando cojáis más soltura con GCP os recomiendo etiquetar vuestras distintas instancias para poder elegir destinos de reglas del cortafuegos y así que cada máquina tenga abiertos los puertos que necesita. Por ahora, y como solo tenemos una máquina creada, no pasa nada por aplicar en el campo destinos “todas las instancias de la red”. Guardamos y ya estaremos listos para empezar la instalación de Node-RED sobre nuestro VPS.

Volvemos a la vista de Compute Engine, donde estará nuestra instancia. En el campo “Conectar” pulsamos sobre SSH. Se nos abrirá una ventana nueva y cuando cargue ya estaremos dentro de nuestro VPS.

Para poder empezar a trabajar, tecleamos los siguientes comandos:

Nótese que entre los comandos, se instalará nodejs. En nuestro caso hemos instalado la versión 8.x por ser la recomendada en el momento de realizar este tutorial, pero se aconseja mirar en la página de nodejs cual es la última versión recomendada. Escribimos ahora el comando que instalará Node-RED en nuestro VPS.

Es también interesante instalar algunas herramientas de node-red que nos harán más fácil la gestión de nuestro servidor, por lo que teclearemos:

Después de esto ya podemos probar que Node-RED está correctamente instalado. Para ellos tecleamos:

Lo que debería arrojar en el terminal una salida que acaba con:

Esto es indicativo de que todo está correcto. ¡Probémoslo! Escribamos en nuestra barra del navegador la IP estática concedida por Google (sin http ni https delante seguida del puerto de acceso a Node-RED, separado por dos puntos “:”), algo así como 123.123.123.123:1880. Deberíamos ver esto:

node-red1

 

¡Todo funciona! Sin embargo esto presenta un enorme, enorme inconveniente: cualquiera que sepa nuestra IP puede acceder a nuestro servidor Node-RED y borrarnos todo el trabajo o inyectar código malicioso. Por ello, el siguiente paso, de vital importancia, es proteger nuestro servidor. Volviendo a la terminal abierta por SSH, pulsamos ctrl+C para parar la ejecución de Node-RED y escribiremos:

Lo que nos preguntará por la contraseña con la que deseamos proteger el servidor. Tras escribirla y pulsar intro, nos devolverá una secuencia hash con nuestra contraseña encriptada, que deberemos copiar, pues usaremos ahora. Escribiremos sobre el archivo de configuración de Node-RED. En el terminal tecleamos:

y dentro de este archivo buscaremos el siguiente texto:

adminAuth: {
type: “credentials”,
users: [{
username: “USUARIO“,
password: “HASH_GENERADO“,
permissions: “*”
}]
},

// To password protect the node-defined HTTP endpoints (httpNodeRoot), or
// the static content (httpStatic), the following properties can be used.
// The pass field is a bcrypt hash of the password.
// See http://nodered.org/docs/security.html#generating-the-password-hash
httpNodeAuth: {user:”USUARIO“,pass:”HASH_GENERADO“},
httpStaticAuth: {user:”USUARIO“,pass:”HASH_GENERADO“},

En usuario escribiremos el usuario que queramos, y en los campos password y pass, el hash generado anteriormente. La primera parte protegerá la parte de gestión (donde colocamos las cajitas), la segunda, la parte de visualización (la web que crean las cajitas). Es importante descomentar las lineas necesarias (esto es, eliminar los caracteres “//” con los que empiezan algunas lineas), para que el resultado quede tal y como hemos puesto arriba. Guardamos con CTRL+O y salimos con CTRL+X.

Por último, será interesante que nuestro servidor cargue automáticamente Node-RED cuando se reinicie, lo que hará más tolerante a fallos nuestra implementación. Para ello, escribimos:

Que nos indicará nuestro nombre de usuario. A continuación:

donde copiaremos el siguiente texto:

[Unit]
Description=Node-RED
After=syslog.target network.target

[Service]
ExecStart=/usr/bin/node-red
Restart=on-failure
KillSignal=SIGINT

# log output to syslog as ‘node-red’
SyslogIdentifier=node-red
StandardOutput=syslog

# non-root user to run as
WorkingDirectory=/home/TUUSUARIO/
User=TUUSUARIO
Group=TUUSUARIO

[Install]
WantedBy=multi-user.target

Hay que modificar solo los campos en rojo. Nuevamente, guardamos con CTRL+O y salimos con CTRL+X. Activamos el servicio creado escribiendo:

Comprobaremos que todo se haya hecho correctamente. Para ello primero es necesario reiniciar, por lo que escribimos:

Y tras esperar unos dos minutos, cargamos de nuevo la página con la IP del servidor en nuestro navegador. Ahora, al cargar node-RED debería pedirnos login, tanto a la parte de gestión como a la de visualización.

¡Eso es todo por nuestra parte! Ahora, a jugar.

The Twelve of B105 – Brain Patterns

Para ambientar este caluroso mes tenemos una nueva entrega de …

theTwelveOfB105

En este caso, hemos decidido recuperar la temática relacionada con la bioingeniería, campo que ya introdujimos en el cartel de Abril de 2018 con las Redes Neuronales Inalámbricas.

Este post está relacionado con el Trabajo Fin de Máster finalizado titulado “Diseño de estrategias para la detección de potenciales de acción en acciones basadas en movimientos”.

El objetivo de este trabajo es obtener patrones que nos permitan saber cuando alguien ha pensado en moverse, sin haber realizado el movimiento. Tras un largo trabajo para conocer este tipo de señales, llegamos a la conclusión de que era necesario un filtrado que permitiera utilizar sólo las señales de la banda de frecuencia relacionada con los movimientos, a saber, la banda alfa y la banda beta de la imagen (8-30 Hz aproximadamente).

stages

También concluimos que no sería suficiente con un procesado único, sino que el algoritmo debería estar formado por un conjunto de características o parámetros obtenidos de manera sencilla, de tal forma que la suma de varias de éstas nos permitiera saber si la persona quería moverse o no.

Se implementaron varios algoritmos que agrupaban ciertas características de las señales y después se probaron sobre unas señales obtenidas de una base de datos pública, de diferentes personas.

Ampliando el número de personas que se utilizaron en el TFM nombrado anteriormente, se ha llegado a tener un acierto de entre el 50 y el 80 %. Al ser este porcentaje muy variable y bajo para lo que nosotros queremos, hemos decidido proceder de la siguiente forma:

– Obtener nuestras propias señales para controlar totalmente el entorno.
– Implementar otros algoritmos que permiten detectar patrones, lo que supone aumentar la complejidad.

Para conocer el resto de temáticas del resto de meses, no dudéis en consultar la siguiente página.

El mes que viene se publicaran las ofertas de TFG/TFM/PFC para el siguiente curso, ¡Estad atentos! ¡Os esperamos!

The Twelve of B105 – Customized Foosball

Llegan las vacaciones, y qué mejor manera de empezar que disfrutando de un nuevo número de…

theTwelveOfB105

Y volvemos nada menos que con uno de los iconos del grupo: el futbolín. Tras una década con nosotros, este ya indispensable miembro del laboratorio ha sido objeto de múltiples mejoras y experimentos (véase su historia).

Mucho tiempo ha pasado desde el primer (y ahora arcaico) sistema para contabilizar los goles. Algunas de las últimas mejoras son:

Red inalámbrica de sensores/actuadores en el futbolín.  Las funcionalidades soportadas por esta red incluyen la gestión de la iluminación, detección de goles, lectura de huellas dactilares (ver TFG asociado), medición de la velocidad de la bola, etc.

Nuevas funcionalidades en la Raspberry Pi. Además del control de la pantalla táctil, esta plataforma actúa como nodo pasarela de la red de sensores/actuadores, registra las estadísticas de jugadores y equipos, e incluso envía notificaciones de los resultados a Slack y Twitter. Por otro lado, incorporamos una cámara para grabar las últimas jugadas, evitando así acaloradas discusiones.

Enlace con otros sistemas del AMIB105 (Ambient Intelligence). Periódicamente se transmite información de estadísticas de juego y replays.

Futbolín -Esquema (2)

Y aquí termina nuestro número de julio. Mientras esperáis al mes que viene, podéis echar un ojo a temáticas anteriores en el siguiente enlace.

¡Hasta el mes que viene!

 

 

The Twelve Of B105: Intelligent TAGs

Y para esta nueva entrega de….

theTwelveOfB105

… hablaremos del estado de otro de los proyectos en los que estamos trabajando.

Éste se basa en el uso de etiquetas inteligentes activas que almacenan información sobre la señal vial y el entorno que le rodea, como por ejemplo, el estado de la carretera. El esquema de cada una de éstas es el que puede verse en la imagen de abajo.

esquema

El sistema deberá encenderse periódicamente para detectar si hay alguien cercano pidiendo datos. La cercanía a la cual los datos pueden ser obtenidos por un receptor es uno de los problemas que encontramos al implementar este tipo de sistema, ya que el receptor puede estar en movimiento, debiendo poder realizarse la lectura/escritura desde un vehículo a cierta velocidad.

La gran diferencia con respecto a las etiquetas pasivas es que necesitan energía para poder funcionar, el cual es el otro problema que encontramos, porque los sistemas tienen que funcionar de forma autónoma durante varios años. Para ello, existen las técnicas de Energy Harvesting, las cuales se fundamentan en obtener energía del medio que está desaprovechada normalmente.

La técnica más implementada por el momento es la que permite obtener energía solar. Sin embargo, si buscamos la innovación en este tipo de técnicas, encontramos la energía de la radio frecuencia, dónde se pretende utilizar la energía de las ondas que se propagan por el aire; la energía mecánica que pretende utilizar las vibraciones y el flujo del aire; y la energía térmica, que intenta aprovechar los cambios de temperatura que hay en el entorno.

Esta energía debe no solo ser suficiente para alimentar el sistema, sino también para ser almacenada en baterías o supercondensadores, garantizando así el funcionamiento del sistema en condiciones límites. La elección de uno u otro dependerá de muchos factores, como la cantidad de energía generada, el tiempo en generarla, la cantidad de energía que necesitaría el sistema y cada cuanto. Aunque, preferiblemente, preferiríamos utilizar supercondensadores.

Como ya sabéis, podéis leer más sobre nuestros otros trabajos consultando los antiguos posts. También estamos en las redes sociales (@elb105) y en el edificio B, salas 104 y 105. ¡No seáis tímidos, os esperamos!