B105 Radar Sensor Developments: Software

Radar Interface

 

The radar platform developed in B105 Electronic Systems Lab contains a microcontroller which process the I and Q signals adapted from the radar transceiver in order to obtain targets information -speed and distance-. The microcontroller used is a low-power STM32L496 that has a DSP module and enough RAM to perform processing tasks. It runs at 48 MHz and has low-power mode, which allows using our platform in battery-powered Wireless Sensor Networks applications.

The software developed in the microcontroller uses the YetiOS operating system which has also been developed in B105 Electronic Systems Lab and is based on well-known FreeRTOS. The architecture of the radar processing module is composed by two tasks:

  • Acquisition and Generation Task. This task is responsible of taking samples from the ADC and generating signals using the DAC synchronously. Both acquisition and generation is done using DMA, so other tasks -such as processing one- could run while taking samples.
  • Processing Task. This task provides the processed information -speed and distance of targets- to the final user. The acquired signal is filtered so the information in undesired frequency bands is eliminated. Besides, a Fast Fourier Transform (FFT) is performed in order to obtain the signals in the frequency domain. Then an OS-CFAR algorithm is applied to select the frequency peaks corresponding to targets, and the targets are selected based on signal levels and SNR ratio.

We have tested the complete radar system in real scenarios and we can process each 128 samples signal in 15 ms. That means that our radar sensor provides distance and speed information with a rate higher to 60 samples per second.

Finally, we have developed an user interface which allows us testing different configuration and the behaviour of the radar sensor on different scenarios.

 

Radar SW

B105 Radar Sensor Developments: Hardware

YetiRadar

 

Low-cost radar transceivers such as RFbeam ones allows using radar sensors in several applications where cost is an important constraint. However they need a hardware platform to work properly. Therefore, in B105 Electronic Systems Lab we have designed and implemented a hardware platform that allows obtaining using radar sensors in Doppler operating mode and FMCW operating mode.

The platform developed is low-sized and resource-constraint which allows using it in Wireless Sensor Networks applications in battery powered nodes. The hardware modules of the designed system are described below:

  • Power Source. Probably one of the most importan parts of the system as it must provide power to the radar transceiver and to the analog adaptation modules. The power source must provide 12 V, 5 V and 3.3 V for proper radar operation, and these sources must be highly noiseless to enchance radar performance.
  • Radar Transceiver. The main component of the radar sensor is the transceiver which sends and receive radar signals. K-LC5 and K-LC6 radar transceivers from RFbeam may be used, providing I and Q IF signals, and a VCO pin for FMCW operation.
  • Signal Adaptation Module. Signal adaptation is necessary to process radar I and Q signals and obtain information from them. An amplification stage, a low-pass filter and a high-pass filter are used in this module. Besides, a single-ended to differential stage is also used to improve signal acquisition.
  • Signal Acquisition. An ADC is used to digitalize the analog signals so they can be processed. The ADC used can be sigma-delta or SAR, with the higher resolution possible (12 to 16 bits), and with speeds from 10 KHz to 1 MHz. In our platform, the acquisition is done by the main microcontroller.
  • Signal Generation.  A DAC is used to generate the signals to modulate the radar transceiver through its VCO pin. Besides, an adaptation stage is implemented to provide adequated modulation signals to the radar transceivers. The DAC used in our platform is integrated in the main microcontroller.
  • Processing Unit. A microcontroller is needed to process the acquired signals and obtain information from them. In our design a low-power STM32L496 microcontroller is used.

Radar HW

 

B105 Radar Sensor Developments

radar-153679_960_720

 

Radar technology is a well-known field used since 1940s. This technology has been traditionally applied in military and aerospace fields while it has not been highly exploited in civil applications. However, in the last years, radar transceivers cost-reduction and miniaturization have allowed its application in other fields such as traffic and vehicular safety.

These low-cost radar sensors uses the Doppler effect to obtain information about obstacles or targets in its range. The radar transmits a signal and the frequency shift of the returned signal provides the velocity of the moving targets. There are two main operating modes for these radar sensors:

  • Unmodulated Doppler radar. This operating mode is the most commonly used. The hardware and processing software needed is quite simple which allows using these sensors in size-constraint and resource-contraint devices. However, they only provide velocity information of moving objects in its range. That means that static objects are missed, the distance of the objects cannot be obtained, and two objects moving at the same velocity will be detected as one.
  • Frequency Modulated Continuous Wave (FMCW) radar. This operating mode is used to obtain the distance of static and moving objects. The radar signal is frequency modulated -usually with a frequency ramp- to allow obtaining distances and velocities from the returning signal frequency shift. Thereby, it is necessary to generate a signal to realize the frequency modulation which increases the hardware complexity. Besides, the software processing is harder as there are much more information to process and there are more noise sources from unwanted environment targets.

In B105 Electronic Systems Lab we have developed a full radar system that can operate in both modes and includes all the hardware and the software necessary. This radar system is being used for traffic safety and traffic monitoring applications in several research projects.

El botón de encendido en los dispositivos actuales

always_on_device

Hasta hace no mucho, todos los aparatos que nos rodean, ya sean alimentados por baterías o desde la corriente eléctrica, disponían de un botón de encendido con dos posiciones que desconectaba el aparato completamente de la fuente de alimentación. Las únicas excepciones eran los aparatos que siempre debían estar conectados (despertadores, etc.). Algunos de estos lo implementaron de una forma más o menos disimulada en la interfaz (p.e. el temporizador de un horno), pero en otros aparatos, como televisiones, siempre suponía levantarse a pulsar el botón para encenderla.

En el caso de los aparatos alimentados por baterías, estos botones comenzaron a desaparecer antes que en los dispositivos domésticos, siendo sustituidos por un botón que, habitualmente mediante una pulsación larga, encendida o apagaba el dispositivo. Esto permitía ahorrar un botón voluminoso debido al mecanismo de enclavamiento y sólo servía para esta función. Esta forma de encendido tenía un pequeño problema, que no era útil para reiniciar el dispositivo cuando se quedaba bloqueado. Pero tampoco supuso un problema, siempre era accesible abrir la tapa de la batería y quitarla para solucionar el problema.

intBattery
Batería integrada (iPhone X).

Sin embargo, cada vez más dispositivos portátiles no permiten extraer la batería, por lo que se añaden algunas soluciones hardware para poder reiniciar el dispositivo si se queda colgado. Estas requieren, además de los componentes adicionales, una serie de consideraciones en el software que controle el dispositivo. Por otro lado, debido al aumento de funciones que realizan los dispositivos, cada vez tiene menos sentido apagarlos completamente cuando no están en uso. Estos periodos de inactividad son aprovechados por los dispositivos para descargar e instalar actualizaciones, u ofrecer funciones adicionales, como las alarmas en un teléfono móvil. En términos de experiencia de uso también suponen una ventaja, ya que reducen fricción en la interacción con el dispositivo; siempre es más probable que se use el dispositivo si siempre está listo para ser utilizado, sin tiempos de inicio ni carga.

En cuanto al desarrollo del dispositivo, supone un mayor cuidado en algunas areas:

  • Topología de alimentación: en general el dispositivo ha de ser mucho más eficiente energéticamente. En el caso de los dispositivos conectados a la red eléctrica, estos suelen estar regidos por regulaciones como la Energy Star estadounidense o su equivalente europeo, que fija unos consumos máximos en los modos de standby. Por otro lado, elementos como las fuentes de alimentación (incluidos cargadores de móviles y similares) tienen especificaciones parecidas.
    En el caso de dispositivos alimentados por baterías, el mayor problema es la duración de la misma cuando no se está usando. Esto lleva al empleo de reguladores conmutados mucho más eficientes, reducción (dinámica o fija) de las tensiones de alimentación, y la desconexión selectiva de partes del dispositivo (como la pantalla o radio). Otros aspectos que no se suelen considerar por ser despreciable su efecto, como el leakage en los condensadores de alimentación o pullups pueden ser significativos en el consumo en los modos de standby.
  • Control de brownout: si no hay la posibilidad de desconectar la batería, cuando esta no pueda proporcionar suficiente energía para que funcione el sistema, causará que no funcione correctamente pudiendo quedar bloqueado. Para ello se suelen implementar supervisores de alimentación que lo apaguen de forma preventiva, a la par que sólo permitan que se encienda cuando haya disponible energía suficiente para que arranque completamente. Esto es muy habitual en dispositivos alimentados por baterías de litio, ya que si se descargan en exceso sufren deterioro, por lo que estos dispositivos suelen impedir encenderlos cuando la batería está cerca de agotarse.
  • Control hardware de botones: dado que no hay botones de apagado, ni suele ser posible desconectar la batería en los dispositivos portátiles, se suelen implementar mecanismos hardware para poder reiniciar el dispositivo si este se cuelga. Para ello se suelen incluir circuitos de supervisión y reset, que permiten conmutar la señal de reset si una señal externa cumple ciertas características (como una pulsación muy larga en un botón).
  • Ship mode: de nuevo, debido a las baterías integradas, el consumo en standby puede suponer que, desde que se fabrica el dispositivo hasta que llega al cliente, se agote la batería completamente. Esto no solo es una “primera experiencia” de uso negativa, sino que puede suponer que la batería se deteriore. Para ello, muchos controladores de alimentación suelen disponer de un modo llamado ship mode que apaga completamente el dispositivo aislandolo de la batería para evitar este consumo. Para salir de este modo basta que el usuario pulse un botón concreto o lo conecte al cargador.
  • Gestión software de los modos de energía: todo el trabajo en el diseño hardware no es útil si la aplicación del dispositivo no gestiona adecuadamente los modos de inactividad, usando las funciones hardware disponibles (escalado dinámico de la tensión, desconexión de periféricos) y reduciendo las tareas innecesarias durante los periodos de inactividad.

Gran parte de las funciones hardware se suelen concentrar en los PMICs (Power Management IC), estos condensan cargadores de baterías, reguladores, y funciones adicionales como la gestión de botones de reset o monitorización de la carga.

Arquitectura del PMIC bq25121.
Arquitectura del PMIC bq25121.

Certificación del proyecto Lázaro ante el CDTI

IMG_2710

Hoy hemos recibido la visita del CDTI (Centro para el Desarrollo Tecnológico e Industrial) para certificar nuestro proyecto Lázaro. Este proyecto se ha realizado junto a Valoriza Servicios a la Dependencia y ha constado de dos partes muy diferenciadas. Por un lado debía desarrollarse un sistema de monitorización para residencias, en el que fuera posible medir parámetros biométricos de los residentes así como controlar forma domótica las estancias a través de una red de sensores. La segunda parte del proyecto tenía como objetivo desarrollar un sistema automático de detección y caracterización de barreras arquitectónicas. La certificación ha sido exitosa ya que se han cumplido los objetivos marcados de manera satisfactoria y se ha determinado la usabilidad del sistema en entornos reales.

IMG_1168

Dentro del primer subobjetivo, realizado por davidtrc, se ha diseñado y fabricado una pulsera wearable capaz de medir temperatura, ritmo cardiaco y saturación de oxígeno. Además se ha desarrollado una aplicación Android, que recoge y muestra los datos obtenidos por la pulsera y es capaz de gestionar múltiples pacientes y usuarios.

En el contexto del segundo subobjetivo, llevado a cabo por albarc, se ha desarrollado una aplicación Android basada en la plataforma Google Tango de visión artificial y realidad aumentada. Mediante esta aplicación, los inspectores de residencias pueden automatizar la labor de medir y caracterizar los edificios en lo que respecta a su accesibilidad. Particularmente la aplicación es capaz de medir la inclinación de rampas de acceso y la anchura de puertas, ascensores y entradas.

IMG_1159

Oferta de Becas de la Cátedra Kairós para el segundo semestre Curso 2017/18

Logo_KairosDS_CMYK (1) (1)

La Cátedra Kairós ofrece tres becas para este segundo semestre con las siguientes temáticas: Identidad digital basada en Blockchain, Asset market y
Supply Chain.

BECA 1
Identidad digital basada en Blockchain
Beca
● Duración: 4 meses
● Dedicación: 4 horas/día
● Remuneración: 500 €/mes
Objetivo
El objetivo de esta beca es estudiar el estado del arte de la identidad digital, analizar y elegir un caso de uso práctico, y realizar un prueba de concepto basado en tecnología blockchain.
Cada día las personas invierten más tiempo conectadas, bien para acceder a redes sociales, servicios online o para comunicarnos. Para poder acceder es necesario confirmar tu identidad, aspecto donde últimamente se están identificando grandes vulnerabilidades o se están utilizan complejos sistemas privados, con sus consecuentes limitaciones. Es en este reto donde las ventajas del uso de la tecnología blockchain supone una gran oportunidad tanto para proteger la privacidad del usuario como el acceso seguro a sus datos.

Beca 2
Asset market
Beca
● Duración: 4 meses
● Dedicación: 4 horas/día
● Remuneración: 500 €/mes
Objetivo
El objetivo de esta beca es estudiar el estado del arte de Asset market, analizar y elegir un caso de uso práctico, y realizar un prueba de concepto basado en tecnología blockchain.
Blockchain permite la creación de activos digitales (asset) para representar elementos materiales (algunos ejemplos son contratos inteligentes, propiedad de un bien o acceso a un curso online). El propósito es poder gestionarlos en un entorno fiable y compartido (asset market) basado en la trazabilidad, inmutabilidad de los datos y la capacidad de poder definir de forma programática la lógica en la que estos activo se gestionan que ofrece el blockchain.

Beca 3
Supply Chain
Beca
● Duración: 4 meses
● Dedicación: 4 horas/día
● Remuneración: 500 €/mes
Objetivo
El objetivo de esta beca es estudiar la aplicabilidad del blockchain dentro del ámbito de Supply Chain, elegir un caso de uso práctico, y realizar un prueba de concepto.
Dentro de la industria de consumo supone una gran oportunidad el uso de la tecnología de blockchain en su cadena de distribución (supply chain). Especialmente valioso en la certificación del origen de los productos, trazabilidad durante su vida, hasta llegar al cliente final. Son varios los enfoques que se están utilizando, de una forma u otra orientada a la mejora de la industria, revolución que en algunos círculos están denominando Industria 4.0.

Los interesados en alguna de las becas deberán enviar un correo electrónico a cualquiera de las siguientes direcciones octavio.nieto-taladriz@upm.es o joaquin.salvachua@upm.es con las siguiente información:

● Carta de presentación
● 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 la documentación: 20 de febrero
● Fecha de inicio de las becas: 1 de marzo

The Twelve of B105: Road Safety

jan18

¡Hoy, casi en la bocina, os traemos una nueva entrega de…

theTwelveOfB105

Este mes de enero hemos querido hacer un repaso de toda nuestra actividad en materia de Seguridad Vial. Desde hace ya varios años, existe en el labo una línea de proyectos de innovación en esta temática. Algunos ya terminados y otro en marcha actualmente, todos ellos persiguen la prevención de accidentes y, en caso de que estos sucedan, poder acelerar la respuesta de los servicios de emergencia. 

A continuación, os dejamos una lista de varios ejemplos de proyectos en los que hemos diseñado y desarrollado soluciones en este área temática:

  • CARRETERAS. En este proyecto desarrollamos una serie de herramientas de soporte para las entidades encargadas del mantenimiento de las carreteras. Estas herramientas les permitían de una manera ágil e intuitiva registrar eventos en la carretera, guardar sus coordenadas, capturar evidencias gráficas, etc. A lo largo del proyecto, hicimos varios días de  pruebas en terreno para pulir nuestro sistema y llegar a una versión final de calidad. También fue muy interesante poder visitar las instalaciones de estas entidades.
  • DEPERITA. Aquí trabajamos en un sistema de perimetración virtual de zonas en las que se están llevando a cabo labores de mantenimiento de modo que, en caso de producirse una intrusión en el área restringida, se alarmase inmediatamente a los trabajadores para evitar un posible accidente.
  • SIMBIOSYS. Una de las partes más interesantes de este proyecto fue trabajar en la detección de fatiga en conductores, con el objetivo de anticipar situaciones de peligro. Para ello, se trabajó en una aproximación basada en la obtención de imágenes del conductor y su procesado en tiempo real, y otra mediante electroencefalograma.

Además de proyectos de innovación, en el B105 también hemos llevado a cabo investigación en el ámbito de las Redes Vehiculares o VANETs, especialmente en aspectos como la fiabilidad y la seguridad, y en el ámbito de la visión por computador aplicada a la conducción.

unnamed-1024x576

Esperamos que nuestros twelve os entusiasmen tanto como a nosotros, y que os permitan conocer mejor todo lo que hacemos por si os interesa uniros y participar de ello. Pincha aquí si quieres ver otros meses.

Si encuentras interesante toda esta información, no dudes en seguirnos en las redes sociales para mantenerte informado.

¡Hasta el mes que viene!

YetiOS: new Operating System for IoT devices

Figure 4

IoT devices and Wireless Sensor Network (WSN) nodes are resource-contraint devices that are not capable to run standard Operating Systems (OS) used in high resource computers or smartphones. Therefore, several OSes have been developed over the years for these resource-contraint devices such as TinyOS, Contiki OS or RIOT OS. These OSes are targeted to run in microcontrollers with some tens KB of Flash memory and less than 10 KB of RAM memory. However, new low-power microcontrollers like STM32L4 have higher resources achieving up to 1 MB of Flash memory and 320 KB of RAM memory.

Therefore, we have developed in B105 Electronic System Lab a custom operating system based on FreeRTOS kernel. The operating system is called YetiOS and presents advanced features to facilitate application developing by reducing the learning curve. This OS works in new low-power microcontrollers and have a memory footprint of 90 KB in Flash and 12 KB in RAM. The OS provides advanced preemtive processes and memory management, Linux-like device drivers, user-transparent power management, time management and a layered configurable network stack.

YetiOS also provides an advanced engine to manage operating system operation. This is a very useful feature in order to ease research works that are being done in B105 Lab to improve OS features and its adaptability to dynamic changes in WSNs environments

The Twelve of B105: Robots

dic17

¡Hoy tenemos nueva entrega en …. 

theTwelveOfB105

Este mes de diciembre os traemos robots de la mano de DEMOTHERM, el robot limpiatuberías en el que llevamos trabajando un tiempo. El objetivo de este proyecto, en el que trabajamos junto a la empresa Therman es el desarrollo de un robot autónomo para la limpieza de material refractario de una chimenea (o robot autónomo de demolición de refractario para ciclones, si usamos la terminología específica). Este robot debe ser controlado de forma remota y capaz de trabajar en entornos hostiles.

Ya habéis podido ver diferentes etapas de trabajo: la integración de la electrónica con la parte mecánica, el desarrollo software, y las pruebas en entorno real. 

Pero es que.. mirad cómo se mueve!

Esperamos que nuestros twelve os entusiasmen tanto como a nosotros, y que os permita conocer mejor todo lo que hacemos por si os interesa uniros y participar de ello. Pincha aquí si quieres ver otros meses.

Si encuentras interesante toda esta información, no dudes en seguirnos en las redes sociales para mantenerte informado.

¡Hasta el mes que viene!