Planet

Probando nueva configuracion del feed __

Un apunte rápido, el desarrollo de JavaDiKt volvió con fuerza después del puente, y como prueba esta semana la forja Red Iris concede al proyecto el (dudoso) honor de figurar en el primer puesto del ranking según el índice de actividad.

Un apunte rápido, el desarrollo de JavaDiKt volvió con fuerza después del puente, y como prueba esta semana la forja Red Iris concede al proyecto el (dudoso) honor de figurar en el primer puesto del ranking según el índice de actividad.

Buenas noches,
 
Ya he podido recopilar suficiente información sobre el sistema de reconocimiento de órdenes por voz como para poder comentároslo por aquí. Hasta que no me venga el chip no podré hacer las suficientes pruebas como para darlo por bueno, asique ésto es solo una aproximación teórica, de momento. El integrado que me permite reconocer comandos por voz, por hardware, es el HM2007, el cual utiliza una SRAM 8Kx8 para guardar hasta 40 comandos y su número asociado. Veamos los modos del Sistema de Reconocimiento por Voz:
 
El sistema puede ser primeramente de dos tipos, dependiente e independiente del hablante.

• Dependiente del hablante significa que si dos personas con la misma lengua mandan comandos al HXBot, el robot sólo obedecerá al que haya programado sus comandos con su propia voz, e ignorará los comandos del segundo, ya que es sensible a, por ejemplo la diferencia de timbre, énfasis o dialecto lingüístico de una misma lengua.
• Independiente del hablante implica que, sean dos personas mandando lenguajes con la misma lengua, son capaces de hacer reaccionar y por tanto controlar al HXBot.

NOTA: Como se puede comprobar, en éste caso conviene más un sistema dependiente, ya que así el usuario es entrenado junto con el HXBot y, en caso de varios HXBot, no hay lugar a confusión de comandos entre ellos.
 
Otra posible diferenciación de estos Sistemas, son los llamados Isolated, Connected, y Continuous:
 

• Isolated. Llamados también Aislados. El reconocimiento se hace palabra a palabra, una aislada de la otra, habiendo una pausa notable entre una y otra.
• Continuous. Los sistemas de reconocimiento Contínuos son capaces de reconoces frases seguidas, en lenguaje natural y fluido.
• Connected. Este tipo está a medio camino entre los Aislados y los Continuos.

NOTA: Para el HXBot, con un sistema tipo Isolated basta, ya que las órdenes serán precisas, claras y concisas, habiendo claras diferencias fonéticas entre unas y otras.
 
 
Este sistema funciona  tal y como sigue:
 
Programando el HM2007

• Se debe programar los comandos. Para ello, pulsa el nº del comando que quieras programar, pulsa la tecla # y di en voz alta la palabra asociada a dicho comando.
• Sigue hasta hacerlo con todos los comandos.

 
Probando el HM2007

• Decir en voz alta la palabra asociada al comando, y el HXBot la ejecutará.

 
El circuito que conseguido encontrar es el siguiente …

… aunque el que ofrece la página oficial [1] del sistema es el siguiente:

 
La 1º imagen corresponde al circuito para poder utilizarlo con Arduino, y el 2º al sistema de prueba que te proponen en su página. Como pueden comprobar, los pines que van del teclado numérico al HM2007 son los mismos que dan interfaz del Arduino al chip. Sin embargo, observo algunas discrepancias en la imagen 1, sobre todo en el envio del comando al microcontrolador. Cuando lo tenga en mis manos veremos si dicho esquema funciona bien, o realmente hay algo que no va tan bien.
 
 
Ahora mismo no puedo dar muchos más detalles como ya dije, por el hecho de que se están retrasando todos los pedidos con esto de las Navidades y la Pascua. Por lo menos me llegó el Arduino Mega (un gran alivio) con todos los componentes que traía la oferta más las piezas de la arquitectura K`nex, y he podido ponerme a crear un pequeño programa que me controle mediante un par de potenciómetros los servos de un prototipo de pata, y así poder los vectores de posición de ellas. De dicho programa hablaré en próximas entradas y entraré en detalles con la estructura del programa del HXBot.
 
Hasta entonces, gracias por leerme.
 
Un saludo,
Ángel Cayetano
 
[1]: http://www.imagesco.com/articles/hm2007/SpeechRecognitionTutorial02.html

Tras ausentarme por motivos de trabajo y estudios, vuelvo tras el puente con ganas y para empezar describiremos el diseño brevemente, ya que para más detalles podeis acceder a las páginas del blog que he añadido que detallan dichos documentos:
Introducción
Diseño
Dicha arquitectura, contará inicialmente con una serie de dispostivos, llamados nodos que recogerán la información y la transmitirán al controlador o nexo. El nexo enviará la información de los nodos al servidor, quien se encargará de comprobarla y almacenarla en la base de datos. Finalmente el cliente podrá interactuar con el servidor por medio de algún dispositivo con conexión a internet.
Ahora describiremos las partes mencionadas de la arquitectura, empezando por la aplicación web, que se basará en el Modelo Vista Controlador, separando los diferentes componentes de una aplicación web, Datos de la aplicación, Interfaz de usuario y lógica de control. Para esto utilizaremos Kumbia PHP, que es un framework para aplicaciones web libres basado en PHP5.
Pasamos a la Red de Sensores, que se compondrá de Nodos repartidos por las habitaciones y que se encargarán de recoger la información por medio de sensores, y según dicha información accionará los dispositivos actuadores que posea para ello, además de enviar la información de dichos sensores y del estado de los actuadores por via inalámbrica. Por último, contarán de una autoconfiguración para que el cliente pueda configurar dichos nodos. Y para terminar los componentes de la Red de Sensores, tenemos tambíen el Controlador, que recibirá la información de los nodos y la comunicará al servidor, además de comunicar a los nodos de las nuevas configuraciones que solicite el usuario. Para los nodos y el controlador usaremos la plataforma Arduino, que nos dá la ventaja de ser open-hardware, añadiendo el bajo coste económico y de consumo. Y para la comunicación nos basaremos en Zigbee, usando los módulos arduino, Xbee, que nos mantiene el bajo consumo energético y nos da un buen alcance y fiabilidad. Para el controlador además usaremos un módulo Ethernet, para la comunicación con el servidor, y para los nodos, usaremos diferentes sensores y actuadores según la demanda o necesidad, como puede ser un Sensor de Movimiento que accionará una bombilla, etc.
En cuanto al Servidor, será el encargado de interactuar con la base de datos, para almacenar, comprobar y recoger la información de la base de datos, además de alojar la aplicación web y según las comprobaciones de los datos anteriores lanzar las alarmas. Para ello, nos basaremos en LAMP, que es el acrónimo de Linux + Apache + My-SQL + PHP. Que son un subconjunto de sistemas libres para una solución global.
Según mencionamos antes, el servidor se realizar una serie de operaciones sobre la base de datos y de interactuar con el Controlador, estas operaciones las realizas una serie de procesos programados para ello, basados en Lenguaje C, lo que nos dá mayor robustabilidad y fiabilidad ya que es un lenguaje más relacionado con la administración de sistemas. El primero de ellos es, Get, que es un Socket encargado de recoger la información enviada del Controlador en formato CSV, y de validarlo, para pasar dicha información al proceso Check, que comprueba que los datos recibidos son coherentes y si lo son llama al proceso Save que se encarga de almacenar dichos datos, y si no son coherentes llamaría al proceso Error, que se encarga de almacenar el error producido y si es de emergencia llamaría al proceso Alarm que se encarga de lanzar la Alarma y de almacenar dicha alarma. Para comprobar que los nodos no dejan de enviar información, tendremos el proceso TimeOut, que si no envían información durante media hora llamaría al proceso Error y haría lo anteriormente mencionado. Y para terminar, el proceso Send, es el encargado de enviar al Controlador la nueva información que quiere el cliente que posean los nodos.
En cuanto a la base de datos, debemos mencionar que es un diseño en 3FN (Tercera Forma Normal) y con ausencia de ciclos, lo que nos dá mayor fiabilidad en cuanto a los datos almacenados.
Bueno pronto tendré la primera versión lista, espero que os agrada.
Un saludo
Fernando

He liberado una nueva versión del Proxy Bluetooth, la 0.1.1. Supone sólo una corrección al programa sin importancia funcional. Tenía indicada la licencia en el archivo about pero no tenía el contenido de dicha licencia. Ahora, el programa incluye un archivo con la licencia.

Acabo de liberar la primera versión del Proxy Bluetooth (versión 0.1.0), así como la primera versión de la documentación de Predesys (versión 1).
Esta versión del Proxy Bluetooth está disponible en formatos tarball y paquete Debian y se puede descargar desde la sección Descargar. La documentación está disponible en formato PDF y se puede descargar desde la sección Documentación.
Al terminar la instalación del Proxy Bluetooth, éste ya estará ejecutándose, como servicio del sistema. Si se quiere parar el servicio, volver a iniciarlo o reiniciarlo basta con ejecutar como administrador una de las siguientes órdenes, respectivamente:
service predesys-bluetooth-proxy stop
service predesys-bluetooth-proxy start
service predesys-bluetooth-proxy restart
Nótese que al instalarse como un servicio del sistema, éste se ejecuta en cada inicio del sistema operativo.
Su configuración está en /etc/predesys-bluetooth-proxy/configuration.xml y si se quiere modificar, ha de hacerse con un editor de texto.

Por sí solo, el Proxy Bluetooth, a priori, no tiene ninguna utilidad ya que requiere que estén implementados el resto de componentes del proyecto. Sin embargo, puede usarse para otros fines, como puede ser el de disponer de un proxy muy sencillo para hacer peticiones HTTP a una página web o a un servicio web cualquiera a través de bluetooth. Eso sí, tenga en cuenta que el Proxy Bluetooth sólo admite peticiones HTTP no persistentes.

He cambiado un poco el esquema de la arquitectura aunque, en esencia, sigue siendo la misma:

Hola,
hoy os traigo el reloj a medio terminar para que le veais como está quedando. El código está subido el la forja [1], está dentro de “/trunk/src/tablerogo/arduino/RelojMejorado.pde” por si alguien quiere echarle un vistazo.
Os dejo una foto [2] para que veais como está quedando.
También os dejo con una imágen para que monteis el circuito fácilmente [3].
Espero que os sirva,
Un saludo !!
[1] https://forja.rediris.es/projects/cusl5-tablerogo/
[2] http://tablerogo.files.wordpress.com/2010/12/reloj.jpg
[3] http://tablerogo.files.wordpress.com/2010/12/text3900.png

He hecho un pequeño cambio de orden y de fechas en el roadmap (ver sección Roadmap). La fecha de liberación de la primera versión del Bluetooth Proxy, prevista para hoy, no cambia, por lo que la liberación de este componente es inminente.