Descripción del Sistema

Introducción


En este sitio WWW, encontrarás información acerca de proyecto SBEI (Un dispositivo electrónico (acústico) para percibir el entorno)

Concretamente en esta página se va a describir el sistema desarrollado en la etapa de "goteo", orientado a que este sea comprensible para un publico general. Proporcionando la información esencial para que un posible desarrollador pueda continuar de forma independiente, así como que se indicarán las principales conclusiones para los diferentes sistemas implicados, el porque de su elección así como posibles alternativas o futuros caminos a desarrollar.

El informe técnico detallado se ha hecho en ingles por ser este el idioma usado en la tecnología electrónica como standard de comunicación, está en la URL:

http://sites.google.com/site/sibiecin/technicaldataatgoteostage

En el se han incluido consejos y datos esenciales acerca del uso del sistema desarrollado en esta fase del proyecto así como su descripción hardware y el codigo fuente del software.

En esta fase también se ha realizado un estudio del "estado del arte" el cual está en inglés por los motivos expuestos anteriormente, en el, se exponen las ideas y proyectos relevantes para el proyecto que nos ocupa encontrados por todo el mundo a través de la WWW. (World Wide Web)

http://sites.google.com/site/sibiecin/informe-estado-del-arte-para-goteo-dot-org

En este sitio, encontrarás en la barra lateral las diferentes secciones donde  se incluye todo lo realizado con anterioridad a la mencionada etapa e información de interés del proyecto, también se espera que incluya los nuevos avances del proyecto. De momento se hará de forma no profesional con lo que ello implica a nivel de dedicación, etc... Pero seguimos contando con la ayuda de gente que colabora, cede espacios y materiales de forma altruista, por lo que tenemos esperanza de que el pryecto de frutos para todos con el tiempo.

Tu crítica y colaboración es importante, por lo que puedes participar activamente en el desarrollo del proyecto.

Definición Hardware


Sistema Central

-La primera idea fue la de usar un ordenador personal al que conectarle diferentes perifiericos que perimitieran probar la aplicación, se hicieron pruebas y se llegaron a generar programas muy sencillos con matlab. Pero aparentemente no teniamos la funcionalidad deseada con la tarjeta de adquisición de datos disponible, por eso se pensó en comprar una nueva tarjeta de adquisción de datos para conectarla al PC. Se presupuestó y calculó el tiempo de ejecución para formular el proyecto en goteo, bajo estos criterios.

-Pero no teníamos claro si volveriamos a tener el mismo problema de adquisición y de si podríamos programar el sistema, ademas de que obtendríamos un sistema hardware de alto coste, el cual no se podría considerar como "open hardware".

-Pensamos en seguir usando el PC como plataforma principal, pero en este caso usando el lenguaje C/C++ y una tarjeta de sonido profesional (solución más asequible para un posible desarrollador), que conociamos la caracterísitca de que pueden grabar ultrasonidos de hasta unos 50Khz ( http://www.avisoft.com/Roland%20Quad-Capture.pdf ) pero no sabiamos si podian reproducirlos, probamos con una tarjeta prestada a emitir por encima de los 20Khz pero no pudimos, por lo que tuvimos que descartar esta opción.

-En este punto teniamos un presupuesto muy ajustado y casi habíamos consumido todo el tiempo programado, por lo que, o gastabamos del orden de los 800€ en una tarjeta de adquisición y empezávamos a programar usando un PC, o intentavamos una solución más accesible en terminos de diseño y de economía.
Decidimos despues de consulta en referendum a los cofinanciadores, invertir más tiempo/recursos en la ejecución del proyecto y menos en materiales... usando una placa de desarrollo software que pueidera ser portatil, más abierta que un sistema de adquisición de datos comercial y económicamente más accesible.
Estuvimos barajando varias opciones para llenar este hueco, entre ellas la solución de open hardware:
BeagleBoard (Texas Instruments), la placa APC de "Via technologies" (se ofrecieron a esponsorizarnos, pero en aquel momento su placa de desarrollo no nos servía para nuestra aplicación), La recien salida RaspBerry Pi (Diseñada en la Universidad de Cadmbridge, para que los alumnos tuvieran una herramienta de aprendizaje, accesible a nivel de software y económicamente) Aparte de otros dispositivos de fabricación china más accesibles economicamente, pero con una comunidad de desarrolladores menor. Soluciones como ardunio, se descartaron, porque tenían limitaciones para la aplicación que teníamos en mente.

Finalmente se eligío la Raspberry pi, por criterios de precio y por la comunidad de desarrolladores que había detras.
 
-Raspberry Pi Type B Single Board Computer 512MB
http://www.raspberrypi.org/

En cuanto al software que usaría esta plataforma, en aquel momento habían basicamente dos imagenes disponibles para ser cargadas. La del Sistema Operativo Rasperberrian (modificación del Linux Debian para esta máquina) y la versión minimalista Arch Linux.
La Primera tentativa se hizo con Arch Linux, siguiendo las recomendaciones de Juan Domingo, el cual hizo mucho trabajo de forma altruista, para convertir esa primera imagen en un sistema operativo de desarrollo de la aplicación específica que teníamos en mente.

Aquí un enlace a una página con anotaciones relativas al trabajo relizado sobre este SO:
http://sites.google.com/site/sbeiprivate/tareas-demostrador-robotica/notas-uso-arch-linux-en-rbpi

Esta imagen es pública en el sitio:
http://www.mediafire.com/?9bj8yp77ebcip

Para falcilitar la descarga se pueden usar gestores de descarga como:
http://www.programasok.com/internet/gestor-de-descarga/

Para que se pueda grabar en cualquier tarjeta SD de 8Gbytes (o más) del mercado, lo que hay que hacer, es descargarse los 13 trozos de 200Mbytes que se convierten en un único archivo al extraer el .zip y estando los otros archivos en el mismo directorio, esto es, porque mediafire deja alojar para usuarios "básicos" archivos de como máximo 200Mbytes

Para grabar la imagen a la tarjeta SD de 8 Gigas, hay que usar el programa "USB image tool" que se puede descargar en:
http://www.alexpage.de/usb-image-tool/download/

Y también en esta página:
https://sites.google.com/site/sibiecin/descripcionsistema/usbit.zip


Es muy intuitivo de usar... solo hay que considerar que si la tarjeta a grabar, es ligeramente diferente en tamaño (menor) a la original, puede ser sea necesario activar la opción "Truncate oversize images in device mode" que escribe en la tarjeta aunque esta sea de menor tamaño que la imagen. Esta última imagen está preparada para esto, pues se le ha redimensionado la partición ext2 para que quepa en todas las tarjetas de 8 Gigas que existen en el mercado. (se han dejado 500Mbytes de espacio libre al final de esta)

Un video tutorial de como usar este programa en:
http://www.youtube.com/watch?v=3vuFTz4fN4I

Pero al contrario de lo indicado, hay que usar para restaurar la imagen el modo "device mode".




Perifericos


Control del sistema. (comunicación, humano -> maquina)

Igual que en el apartado anterior, el proceso de elección ha seguido un camino similar parejo a la elección del sistema principal, lo que pasa es que en este caso, el dispositivo de control puede ser siempre el mismo independientemente de la plataforma elegida.

La idea original desde el principio, era la de hacer el control del sistema, usando la mano, para ello se pensó en un guante de realidad virtual, pues es el dispositivo existente, más adecuado para ello. Se hizo una pequeña búsqueda, y se encontró que el guante P5, era un producto asequible y bastante documentado en la red.

Se compró y se hizo funcionar bajo ArchLinux/RPi, pero al no ser considerado esencial para desarrollar la aplicación (pues se puede simular con 4 variables que varien entre 0 y 64) se ha donado a la Fundación Fuentes Abiertas por su colaboración.

Al principio las primeras pruebas de control bajo PC y matlab se hicieron con un gamepad, y quizás esta pueda ser la solución de un primer prototipo, para hacer un control del sistema portatil sin usar un teclado.

Para los que quieran usar el guante P5 con la plataforma RPi, o cualquier pc, aquí los repositorios con el código fuente para ser compilado. Incluye ejemplos en lenguaje C, para su uso.

-Guante de realidad virtual P5 de vrealities. (drivers bajo linux Arch linux)

http://code.google.com/p/libp5glove/source/checkout

http://noisybox.net/computers/p5glove/

Sistema I/O de Señales del sitema. (Tiempo Real)


Para comunicarse con el entorno, los computadores tienen sistemas de entrada/salida (Input / Output en inglés), y para esta aplicación se requiere que el sistema se comunique con el entorno a frecuencias ultrasónicas, para lo cual, los sistemas que vienen de serie en la RPi no sirven, pues solo generan señales analógicas en el rango de los sonidos audibles, además de no poder leer señales analógicas (por ejemplo con un micrófono)
Pero la RPi tiene puertos dititales para estos propósitos, tales como el I2C, SPI, y pines GPIO. De todos ellos, el único que servía para la aplicación que nos ocupa, es el SPI que puede alcanzar velocidades de hasta 125 Mbps y es fulduplex nativo. El puerto I2C se quedaba un poco justo para esta aplicación, ya que fue pensado para trabajar con señales de audio, y el puerto GPIO está pensado para controlar señales tipo LED, Motores, etc... por lo que tampoco sirve...

Una vez elegida la opción del puerto SPI, tenemos que pensar el como hacer la conversión digital analógica y viceversa. Al ser un puerto serie, solo usa 3 cables para transmitir las palabras de cualquier longitud, y en nuestro caso, queremos hacer una transmisión de palabras de 16bits, ya que son el tipo de datos que maneja la tarjeta de sonido de la RPi.
Por ello buscamos entre los distintos proveedores de hardware actualmente disponibles en el mercado, tales como:
-Farnell
        http://www.farnell.com/
-RS
        http://www.rs-online.com
-Mouser
http://www.mouser.com
          -DigiKey
                  http://www.digikey.com/

Y la principal conclusión es que los chips para trabajar a las frecuencias requeridas (333KSPS) y con una resolución mínima de 16bits suelen ser relativamente caros (del orden de los 20€ cada uno) y tienen funcionalidades únicas separadas (conversion analogica-digital y viceversa separadas en dos chips de unos 15€ cada uno) los chips para trabajar a frecuencias de audio, incluyen varios conversores AD-DA en un único chip y son mucho más baratos, pues se fabrican en masa para una gran cantidad de aplicaciones, pero no nos sirven para la nuestra, pues en la mayoría de los casos llevan filtros reconstructores y antialiasing que impiden trabajar a las frecuencias de interés.

Se eligieron dos chips y solo se ha podido comprovar el funcionamiento de uno de ellos.
Todos los detalles de los esquemas, componentes usados, etc... estan escritos en inglés en la web:

https://sites.google.com/site/sibiecin/technicaldataatgoteostage

Hay que comentar que definir unos chips como diseño final es un error, pues hay muchas cosas que pueden hacer que el chip elegido, no sea válido para un posterior diseño. Tales como componentes descatalogados, etc...

Par el uso del puerto SPI, es necesario un software capaz de controlarlo con un programa en c++ , para ello se eligió primeramente una librería ( http://www.open.com.au/mikem/bcm2835/ ) con funciones prediseñadas que manejaban dicho puerto, escribiendo en en los registros del chip bcm2835 y usando el método de programación por polling (tambien existe el metodo por interrupción y por DMA) Pero esta librería, pese a modificar las funciones originales para nuestra aplicación, no parecia hacerla funcionar correctamente, por lo que estuvimos haciendo pruebas con la librería:

http://gnublin.org/gnublin-api/doc/html_en/index.html

Pero esta no funcionó, pues estaba diseñada para aplicaciones más sencillas.

Incluso probamos de hacer que la aplicación funcionara en un hilo de alta prioridad para solucionar problemas de discontinuidad, pero aún así no funcionaba, con lo que consultamos al foro bcm2835 y obtuvimos la respuesta siguiente:

http://mural.uv.es/efere/archivos/sbei/spi_email.pdf

En la que nos indica que hemos de programar en Baremetal que significa usar la placa sin sistema operativo, solo usando el codigo de programa que necesitemos y sus complementos directamente ejecutado en el procesador sin intermediarios (S.O.) Pero nosotros no podíamos programar nuestra aplicación en esta modalidad, porque usabamos una gran cantidad de librerías y funciones que dependían del SO, por lo que pensamos que tampoco era nuestra solución al problema...

Al final buscando por la red, encontramos una posible solución, usando la controladora DMA y modificando el kernel de linux para poder programarla:

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=71&t=19797

Pero hasta ahora no la hemos podido implementar, pues no hemos podido recompliar el kernel de linux todavía.


Transductores Ultrasónicos.

Existen en el mercado una gran variedad de transductores que permiten trabajar a la frecuencia de los ultrasonidos, pero por características físicas, suelen ser:

-Resonantes, que trabajan muy bien (gran eficiencia en la conversión de un tipo de energía a otra) en una banda muy estrecha, por ejemplo son típicos los que trabajan a 40Khz

-Los elsctroestáticos, que trabajan con una banda más ancha, pero que requieren de bastante circuitería adicional (tensión de bias, etc...) una muestra de que tipo de transductores estamos hablando en http://www.avisoft.com/usg/microphones.htm

En este proyecto desde el principio, nos hemos basado en un documento que ha funcionado de forma correcta, se trata de "A BIOLOGICALLY INSPIRED SONARHEAD" ( https://sites.google.com/site/sbeiprivate/tareas-demostrador-robotica/tareas-agosto/biosonar.pdf ) Este documento y los materiales para montaje fueron comprados y seleccionados por Francisco Vegara.

Toda la circuitería y los transductores "cuelgan" en cascada del los circuitos de conversión AD y DA que están conectados al puerto SPI de la RPi.

Y tienen un ancho de banda útil de unos 20KHz con frecuencia central de 50KHz, aunque pueden trabajar de los 40Khz a los 100Khz ya que antes de diseñar el sistema AD-DA se probaron con un generador de funciones.


Interfaz haptica/sonido del sistema (comunicación, maquina -> humano)

Se estudió la posibilidad de hacer una interfaz háptica, pero con la dedicación programada en goteo y productos disponibles en el mercado, se pensó que no era la solución para hacer algo asequible y sencillo de usar por cualquier desarollador potencial. 

Al ser informado por Juan Domingo de la posibilidad de usar la tecnología "bone conduction" cambió el planteamiento, pues esta tecnología no obstruía el canal auditivo y hacía ahún más "natural" el invento, pues podían ser transformados en frecuencias audibles los ultrasonidos emitidos y recibidos, haciendo la interpretación de la información, más natural para el cerebro.

Para la sintesis de señales se usan un conjunto de librerías "open" definidas en:

http://www.music.mcgill.ca/~gary/rtaudio/

https://ccrma.stanford.edu/software/stk/

Estas librerías se han compilado y usado en el SO Arch linux y plataforma hardware RaspBerry Pi. Pero no se han llegado a aprovechar toda la potencialidad de estas, pues solo se han llegado a sintetizar senos.

La tecnología bone conduction sin amplificación puede ser insuficiente para el propósito del proyecto ya que nivel sonoro máximo experimentado con la RBPI resulta ser de un bajo nivel comparado con el nivel experimentado con auriculares tradicionales, quizás suficiente, pero no necesariamente pues en entornos ruidosos puede quedar enmascarado por otros sonidos. Por lo que puede considerarse para futuros avances, la tecnología bone conduction autoamplificada, u otra placa de desarrollo embarcado, que emita con más potencia por el puerto analogico de sonido.

Para el desarrollo y prueba de la idea, es suficiente con auriculares normales pues son los que producen un mejor rendimiento en el laboratorio. Despues el cambio a la tecnología "bone conduction" es inmediato.

Para todo esto, es suficiente con usar el sistema de sonido de la RPi, o el de cualquier sistema equivalente.

Para futuros desarrollos se considerará desarrollar una interfaz haptica siguiendo la idea original. Pero no parece ser algo alcanzable a corto plazo.

Modulos software para la applicacion.

Para hacer más facil el trabajo de desarrollo software, se han dividido en diferentes partes el sistema, de acorde a la funcionalidad deseada. 

Los archivos y el codigo fuente se encuentran en la documentación en inglés:

https://sites.google.com/site/sibiecin/technicaldataatgoteostage

También se pueden encontrar aquí las instrucciones para manejar el SO Arch linux generado, desde la consola, a través de la linea de comandos, así como del método usado para la compilación del codigo fuente y las herramientas de edición consideradas.

También se describe el proceso que se ha seguido para hacer que el sistema pueda usar todas las librerias necesarias para la aplicación.

Normalmente se ha generado un único archivo fuente por cada módulo software para simplificar su comprensión, en algunos casos se ha generado archivos grandes pero manipulables.

El lenguaje de programación usado ha sido el C/C++ Siendo el compilador capaz de compilarlos ambos simultaneamente.


Modulo Control Guante Realidad Virtual.


Guante de realidad virtual P5 de vrealities. (drivers bajo linux Arch linux) repositorios codigo fuente.

http://code.google.com/p/libp5glove/source/checkout

http://noisybox.net/computers/p5glove/

Se ha conseguido Recoger los valores numericos enteros correspondientes a la flexión de los dedos (de 0 a 63) además de los valores de los botones del guante para guardarlos en variables enteras que pueden ser pasadas a otros programas, pero es posible capturar la posición en el espacio respecto al detector de infrarojos de cada uno de los leds infrarojos que existen en el guante, por si es necesario para otras aplicaciones.

Para que funcione el guante es necesario que el receptor de infrarojos vea almenos un led del guante.

Ese modulo funciona bien de forma aislada, pero al intentar combinarlo con otros modulos, no funciona todo lo bien que se esperaba y habría que depurar el codigo para hacerlo funcionar.

Para el desarrollo software de la aplicación, no es necesario contar con el guante físicamente, ya que este es facilmente simulable con entradas del teclado.

Se puede desarrollar un sistema de control alternativo, pero no se ha hecho hasta ahora.


Modulo Sintesis de Señales.

Para la sintesis de señales se usan un conjunto de librerías "open" definidas en:

http://www.music.mcgill.ca/~gary/rtaudio/

https://ccrma.stanford.edu/software/stk/

Se usan vectores en la memoria RAM de la RPi para almacenar las secuencias numericas de datos generadas.

Los vectores generados son de datos de 64 bits, haciendolos desproporcionadamente grandes para la información que almacenan, ya que la tarjeta de sonido de la RPi manipula datos de 16 bits.

Posiblemente la librería esté diseñada así para que se puedan trabajar con los datos de cualquier tarjeta de sonido existente y futura (los drivers actuales están manipulando datos de 32 bits) pero el hardware existente no suele pasar de los 24 bits.

Hasta ahora solo se han conseguido sintetizar senos, pero el software definido tiene un potencial mucho mas grande para sintetizar señales.


Modulo interfaz puerto SPI.

En este programa, se han dedicado la mayor parte de los esfuerzos, pues incluye la mayor cantidad de tiempo invertido en el software del proyecto.

Basicamente se ha combinado la sintesis de señales y la comunicación con la tarjeta de sonido para poder probar el bus SPI, para poder enviar datos se han tenido que transformar de los 64 bits en coma flotante originales a los 16bits "enteros" necesarios para los chips DA y el proceso inverso para la captura de datos procedentes del conversor AD

Este modulo está estrechamente relacionado con el hardware pues es el que se comunica con el a más bajo nivel de todos los módulos.

Modulo que reproduce sonidos de feedback al usuario.

Este modulo está integrado en el anterior módulo y usa las funciones de STK y RtAudio para comunicarse con la tarjeta de sonido de la RPi.

Modulo procesado digital de señal.

En este apartado no se ha implemantado nada, pues no se ha llegado a capturar ninguna señal externa, pero se ha pensado en usar la librería STK que contiene muchas funciones para el tratamiento de señales, tales como filtros digitales, etc...

Modulo Integrador submodulos.

Las primeras tentativas de unificar toso el software, ha resultado en problemas del contro del tiempo del ciclo del programa, así como problemas con el acceso a los dispositivos de control P5, por lo que es posible que haya que depurar mucho para implementar un modulo integrado que incluya todo el hardware descrito, sobre todo el guante P5. Hay mucho que hacer todavía incluso para obtener una funcionalidad básica.


Conclusiones

El diseño del sistema está definido pero no está probado completamente, pero con poco que hagamos, podremos empezar a hacer pruebas de la idea original a un bajo coste y con una pequeña inversión, hay muy poco hecho en el campo de los ultrasonidos y las investigaciones en este campo pueden dar grandes satisfacciones. El sistema está definido a un nivel de desarrollo básico y hay muchas cosas que se han de mejorar para que esto se pueda convertir en un producto "maduro" para el mercado, solo el trabajo en este sentido, nos dará las respuestas en cuanto a la inversión necesaria y el tiempo necesario.

Durante la investigación del "estado del arte" hemos descubierto proyectos en el ambito de la Investigación, conceptualmete similares a SBEI y con unos resultados esperanzadores, por lo que esto es motivo suficiente como para animarnos a trabajar en la "dirección" tomada.

Esperemos que con nuestro trabajo en esta "etapa" haber facilitado un poco la tarea a cualquier interesado en continuar con el desarrollo de las ideas expuestas, así como haber proporcionado información util a cualquier usuario interesado en el desarrollo de sistemas embarcados y la ingeniería electrónica en general.



Para más info


https://sites.google.com/site/sbeiprivate

DVD con datos recopilatorios del proyecto en:

http://www.mediafire.com/folder/y8wfumcnyvih3/DVDgoteo
Para falcilitar la descarga se pueden usar gestores de descarga como:
http://www.programasok.com/internet/gestor-de-descarga/

Descargar las 14 partes + el archivo .zip, descomprimir este último teneiendo todas las partes en el mismo directorio.