Blog

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!

Becas Cátedra BQ 2018/2019

Un curso más, y cumplimos 5 años, continúa la colaboración del B105 con BQ. Dentro de las actividades de la cátedra BQ se contempla el establecimiento de un programa de becas en áreas de interés para la empresa y que complementen el proceso formativo de los estudiantes.

Por lo tanto, se lanza esta convocatoria de becas para el curso académico 2018/2019 (ver documento adjunto).

C20182019-ConvocatoriaBecasCBQ

Los interesados en alguna de las becas deberán enviar un correo electrónico a la dirección  catedra.bq.upm@bq.com con la siguiente información:

  • Asunto: [Becas Cátedra  BQ].
  • Curriculum Vitae.
  • Beca/s en las que estás interesado y la motivación.
  • Situación actual del candidato: curso, asignaturas pendientes, limitaciones de horarios, interés en realizar TFG, TFM, Prácticas en Empresa, etc.

Información de interés:

  • Fecha límite de recepción de CV: 21 de Septiembre de 2018.
  • Fecha de inicio de las becas: Preferiblemente 24 de Septiembre de 2018.

Os esperamos!

TFM: DESIGN AND IMPLEMENTATION OF NODES FOR CONTINUOUS MONITORING OF STRUCTURES BASED ON MEMS ACCELEROMETERS AND POWERED BY SOLAR ENERGY

Monitoring of large structures, such as buildings or bridges, is a very important task and must be done constantly, due to the danger that can lead to a sudden failure of these. These failures can cause a large number of damages, not only material, but also human losses.

This project aims to design and implement a system that is capable of monitoring the vibrations of a certain place and must also be energetically self-sufficient. For this, the main purpose is to implement a node of this type based on a MEMS accelerometer and powered by solar energy and batteries. The developed monitoring node must be a low power system because it must be able to work autonomously for long periods of time. This will be achieved through the implementation of a power system based on an external battery recharged by solar energy. For the measurement part, accelerometer data will be collected every so often and stored on an SD card for later reference.

The B105 Laboratory has several types of PCBs that have different modules needed to carry out this project (accelerometers, battery management, SD card …). For the development of the hardware it was decided to take advantage of the PCBs already designed. The modules and components to be used were chosen and subsequently welded with two different techniques: manual and by oven.

The software was programmed in C language and it was decided to perform 3 different implementations: first, software was designed on bare machine to check the correct functioning of the measurement module; Later software with operating system was developed to optimize the performance of the system; Finally, tests were performed measuring vibrations with the accelerometer and stored on the SD card to obtain final results and conclusions.

TFG: Design and implementation of an access control system based on NFC technology

 

The B105 Electronic Systems Lab has an electronic access system in its door based on a Radio Frequency Identification (RFID) card reader. This system was developed more than 12 years ago so the technology it uses is obsolete and several of its features are out of use. The development of this degree project is intended to implement an alternative to this access control system based on Near Field Communication (NFC) technology.

The RFID system requires the use of physical cards, which are easily misplaced and force the user to carry them around with him/her to enter the laboratory. To solve this problem, the new system allows the users to open the door using their smartphone. This makes it even easier to enter the laboratory, as users always have their mobile phone with them. In addition, users are assigned specific entry times, providing greater security and a better access control to the laboratory.

There is an equipment reservation management service in the laboratory that already has a database of members, an application and an administration website. Therefore, these resources have been used to facilitate the implementation of the new system and avoid data replication on the server.

Once the system has been implemented, any user who is registered in the system and has certain permissions can open the door by bringing their mobile phone closer to the reader. To achieve this, the existing access system has been built on and relevant technologies have been studied.

The development and implementation work has been divided into three blocks: the NFC reader, the application and the server. The reader, integrated into the door opening system, acts as an intermediary between the application and the server. On the other hand, the application only has to emulate the access card and send the entry request. Then, the server evaluates this request checking the user information and its database and it sends a response to the reader. Depending on the message received, the reader opens the door or not and finally informs the user of the decision.