DasherUS 1.2.3 Beta

octubre 24, 2011

Ha pasado mucho tiempo desde que actualizamos por última vez. Sin embargo, la espera ha merecido la pena y el tiempo transcurrido no ha pasado en vano.

Hemos asistido como ponentes en dos conferencias de las jornadas imaginática 2011. También hemos asistido al congreso internacional [drt4all] 2011, que se ha celebrado en Madrid los días 27, 28 y 29 de junio, para presentar la primera revisión del sistema DasherUS. La segunda revisión de DasherUS ha constituido el trabajo de fin de máster de Rafa. Hemos obtenido una mención honorífica en los premios PFC 2011 de la Escuela Técnica Superior de Ingeniería Informática de la Universidad de Sevilla.

Más adelante actualizaremos el blog para contaros en profundidad todo lo que nos ha ocurrido gracias a DasherUS. Pero ahora vamos a centrarnos en la mejor de las noticias: la versión Beta de DasherUS ya está lista!

El estado actual de DasherUS es el siguiente:

  • Amplificación. Realizado!
  • FiltradoRealizado!
  • Selección de ejesRealizado!
  • Perfiles de usuarioRealizado!
  • Selector de puerto COMRealizado!
  • Autodetección del pueto COMRealizado!
  • Revisión general de bugsRealizado!
  • Otros dispositivos: Se ha considerado que este punto debería revisarse tras la realización de las pruebas de usuario.
  • Traducción al españolRealizado!
  • Sistema de LogRealizado!
  • Sistema de reproducción mediante Log: Este punto, finalmente, se ha desechado.
  • Mejora del sistema de calibrado: Al ser algo opcional aun no se ha implementado. No obstante, en futuras versiones podría implementarse.
  • Selección de modoRealizado!
  • Cambio automático de modoRealizado!

El siguiente paso es elaborar un completo plan de pruebas para determinar la utilidad de DasherUS en personas afectadas de parálisis cerebral.

Por otro lado, sois muchos los que nos pedís que subamos el código fuente de DasherUS. Sin embargo, os tenemos que pedir paciencia. Estamos trabajando para proporcionar toda la información pero eso será después de realizar las pruebas de usuario.

Anuncios

Inicio de la segunda parte

enero 8, 2011

Después de unos meses muy movidos volvemos a actualizar para poneros al día de todo lo que hemos hecho y lo que nos queda aún por hacer.

Tras la defensa del proyecto de fin de carrera, los profesores nos propusieron ser alumnos internos y becarios en el departamento para, de esta forma, continuar con el proyecto. Como es lógico nosotros aceptamos y es por ello por lo que volvemos a trabajar en DasherUS. Ahora somos colaboradores del Grupo TAIS.

Tenemos pensado hacer un post especial en el que os queremos contar nuestra experiencia en el congreso ICCHP’10 y en la defensa de nuestro proyecto. Mientras tanto, os pondremos al día de las cosas que estamos haciendo ahora y de las que nos quedan por hacer.

A pesar de ser ambos alumnos internos, Rafa será becario desde el 1 de diciembre y Pablo será becario a partir de marzo, todo ello  debido a incompatibilidad de horarios. Por ello, durante este primer periodo el que posteará será Rafa en exclusiva.

Pese a que se empezó a trabajar de nuevo en DasherUS a partir del 1 de diciembre no se ha podido postear antes por cuestiones de tiempo. Sin embargo en este tiempo se ha trabajado y avanzado mucho con DasherUS. Cuando hicimos la documentación establecimos cuales serían las lineas de trabajo que creímos debían seguirse, esas lineas eran:

  • Amplificación y Filtrado: Amplificar el rango de valores ofrecidos por el acelerómetro y filtrar dichos valores para mejorar la usabilidad y la experiencia del usuario.
  • Selección de ejes: La elección de los ejes que queramos usar nos permite colocar el acelerómetro en otras posiciones y por tanto en otras localizaciones del cuerpo del usuario.
  • Perfiles de usuario: La inclusión de un sistema de perfiles proporcionará a DasherUS una comodidad extra al permitir almacenar los datos de calibración de cada usuario. Esta característica cobra especial interés para las asociaciones en las que son muchos los usuarios que utilicen este sistema.
  • Selector de puerto COM: Es importante incluir en el menú de opciones un apartado en el que se pueda elegir cual es el puerto COM que se va a utilizar para el hardware ya que, aunque al instalarlo generalmente se establece por defecto el puerto COM3, este puede variar si el puerto COM3 está siendo utilizado.
  • Revisión general de bugs: Dasher trae algunos bugs (fallos en el código) que hacen que el software se bloquee e impide su nueva ejecución al modificar ciertos parámetros del menú de configuración.
  • Otros dispositivos: La conexión de diferentes dispositivos a DasherUS permitiría su uso para un mayor número de usuarios con diferentes discapacidades o minusvalías.

La lista ha cambiado un poco pasando a ser la siguiente:

  • Amplificación: Este punto y el siguiente estaban juntos y ya fueron explicados anteriormente sin embargo han sido separados ya que el Shield de amplificación que ha sido diseñado para Arduino solo amplifica. El filtrado debe realizarse por software. Actualmente se está trabajando en este punto.
  • Filtrado: Explicado en el punto anterior. La realización de este punto aún está por revisar.
  • Selección de ejes: Explicado anteriormente. La realización de este punto aún está por revisar.
  • Perfiles de usuario: Explicado anteriormente. La realización de este punto aún está por revisar.
  • Selector de puerto COM: Explicado anteriormente. Este punto está ya realizado.
  • Autodetección del pueto COM: Este punto se ha añadido con posterioridad. Pensamos que es más cómodo para el usuario que el hardware se detecte automáticamente ya que el usuario no tiene por que tener los conocimientos de informática necesarios para determinar en que puerto se ha instalado. Por ello se ha incluido en el menú de configuración un botón que permite al usuario configurar automáticamente el puerto al que está conectado el hardware. Este punto está ya realizado.
  • Revisión general de bugs: Explicado anteriormente. He podido solventar los bugs más importantes que conocíamos y sabíamos cómo reproducir. No obstante podrían aparecer bugs que desconocemos y que produzcan efectos no deseados, como en todo software informático.
  • Otros dispositivos: Explicado anteriormente. La realización de este punto aún está por revisar.
  • Traducción al español: Explicado anteriormente. Completado casi al 100%.
  • Sistema de Log: Este punto se ha añadido con posterioridad. Se trata de crear, durante el uso de DasherUS, un fichero con las coordenadas proporcionadas por el acelerómetro. La idea es poder reproducir las veces que sean necesarias la sesión llevada a cabo por el usuario para estudiar el uso y funcionamiento del sistema. La realización de este punto aún está por revisar
  • Sistema de reproducción mediante Log: Este punto forma parte del anterior pero ha sido separado en dos partes ya que para poder realizar éste, primero hay que realizar el anterior. Al no haber comenzado con el primero, éste también está por revisar.
  • Mejora del sistema de calibrado: Este punto se ha añadido con posterioridad. La realización de este punto aún está por revisar. El sistema de calibración funciona perfectamente , sin embargo es poco gráfico. Actualmente el menú de calibración sólo cuenta con indicadores numéricos los cuales no ayudan a que el usuario tenga una idea muy concreta de lo que está haciendo. Por ello se nos ocurrió que el proceso de calibrado sería más agradable para el usuario si pudiera contar con un elemento gráfico que mostrase de algún modo dicho proceso.
  • Selección de modo: Es importante añadir un sistema mediante el cual el usuario pueda alternar entre el acelerómetro y el ratón. En este punto y el anterior ya se empezó a trabajar, pero quedó en suspensión cuando llegó el Shield de amplificación, debido al riesgo a tener que volver a diseñarlo si tenía algún error de hardware.
  • Cambio automático de modo: La desconexión del hardware y el consiguiente error y cierre automático de DasherUS fue un problema que advertimos mientras desarrollabamos DasherUS cuya solución no pudimos encontrar tiempo. Se ha solucionado este problema de forma que cuando se desconecta el acelerómetro se pase automáticamente a modo ratón.

Actualmente se está trabajando en el sistema de Amplificación y en función de los resultados que se obtenga puede que después se busque algún método de filtrado.

¡Hasta la próxima actualización!

Fin de la primera parte

mayo 11, 2010

Casi dos meses después de la última entrada del blog, volvemos para anunciar lo que estábamos deseando desde hace tiempo:

¡TERMINAMOS!

Sí, habéis leído bien. Esta noche dimos por terminada la parte de hardware y software del proyecto después de días y días intentando ampliarlo para incluirle un menú de calibración. Éste nos ha llevado más tiempo del que hubiéramos deseado, pero tampoco queríamos hacer cualquier cosa hecha mal y pronto. El retraso ha sido debido a que hemos tenido que aprender e investigar muchas cosas antes de poder terminarlo. A cada paso que dábamos, aparecía un problema nuevo que teníamos que solventar que, entre exámenes y otras obligaciones, nos ha retrasado bastante. Finalmente hemos conseguido lo que queríamos.

Hemos añadido unas cuantas características al menú que hacen que realice su trabajo de una forma muy eficiente, e incluso nos hemos permitido mejorar algo del propio Dasher. Al menú que diseñamos en un principio le hemos añadidos dos botones, que inicia o detiene la calibración. Nuestro menú tiene comunicación directa con la función que obtiene las coordenadas del ratón, nuestra famosa GetCoordinates. Allí hemos incluido unas funciones nuevas que permiten, entre otras cosas, decirle a DasherUS que pare de mostrar el cursor de escritura de DasherUS. Tomamos esa decisión porque pensamos que era algo desconcertante estar calibrando mientras DasherUS estaba escribiendo cosas por detrás. Por otro lado, las otras funciones nos permiten hacer el cálculo que sirve para reajustar el rango de valores en el que se va a mover el acelerómetro.

Nuestro mayor problema estaba en el hecho de que teníamos que actualizar los valores continuamente y todas las soluciones que adoptamos nos suponían entrar en un bucle infinito que cerraba el programa directamente. Por como está hecho Dasher, cada archivo de cada pestaña del menú de preferencias tiene un método llamado WndProc que se encarga, exclusivamente, de tratar eventos. Dichos eventos son generados cuando un usuario pulsa un botón, hace click en ciertos puntos de la pantalla, o cuando el programa hace ciertas operaciones internas. La opción ideal consistía en crear un Timer, cosa que normalmente es muy facil usando MFC o el ClassWizard… elementos de los que no podíamos disponer. Por tanto, tuvimos que ponernos, de nuevo, a investigar por nuestra cuenta hasta encontrar la manera de crearnos nosotros mismos un Timer. Realmente lo único que necesitábamos era algo que nos enviara un evento cada cierto tiempo para que WndProc lo detectase y actualizase los valores nuevos del calibrado. Obviamente, esto era imposible sin crear un hilo paralelo o utilizando algún elemento que no paralizase el programa. Ese elemento es nuestro Timer. Una vez creado y con todo lo que habíamos aprendido no fue difícil unirlo todo para que hiciese lo que queríamos.

¿Y ahora qué? Pues por ahora estamos ante 3 líneas de trabajo las cuales son, por orden de importancia:

  • Documentación: Gracias a todos los documentos que hemos obtenido durante el desarrollo del proyecto, a los comentarios que hemos ido haciendo en el código, los archivos de cambios que fuimos actualizando cada vez que hacíamos algo nuevo y a este blog, esperamos reunir suficiente información para hacer, en el relativamente poco tiempo que tenemos, una documentación digna del proyecto que tenemos entre manos.
  • Pruebas de campo: Gracias a un contacto que nos proporcionará Isabel Gómez, es posible que podamos organizar una cita con una asociación de personas víctimas de accidentes de tráfico. Se nos ofreció concertar una cita antes, pero no quisimos antes de terminar el calibrado.
  • Interfaz gráfico: Durante el desarrollo del proyecto hemos podido profundizar mucho en el código del Dasher original y hemos visto gran cantidad de errores que podrían ser mejorados. Aparte de traducir el programa, podríamos cambiar los iconos por unos más vistosos  y diseñar una última mejora para el menú de calibrado que muestre gráficamente la posición del cursor para que sea más intuitivo.

Para terminar, comentar que a todo esto tenemos que añadir el hacer una presentación y preparar la conferencia que daremos en el ICCHP’1o en Viena este julio para el cual ya tenemos los billetes de avión y el hotel, así que todo sigue adelante. Además, parece que la exposición del proyecto en España ante el departamento vamos a hacerla en inglés, como si fuera un ensayo de lo que diremos en Viena.

Así que a pesar de haber conseguido la mitad del proyecto, aun nos queda por hacer. ¡Seguimos trabajando!

Menú de calibración

marzo 10, 2010

Desde que empezamos este Proyecto en septiembre del 2009, hemos pasado por varias fases y hemos sentido desde decepción, hasta el júbilo más grande. Sin embargo, si tuviéramos que definir una constante durante todas las fases, sin duda sería nuestro afán de superación personal. Gracias a él nos embarcamos en este proyecto y gracias a él hemos vuelto a lograr lo que pretendíamos.

Captura de DasherUS

Lo que podemos observar en la imagen superior es un menú de calibración hecho por nosotros mismos integrado en el propio menú de configuración de DasherUS. A pesar de no haber realizado el código interno que lo controle, creemos que la peor parte ya la hemos superada y tenemos ubicados todos los archivos que tenemos que modificar para incluir lo que falte.

Su funcionamiento será tan simple como entrar en ese menú y mover el acelerómetro en círculos. Y nos referimos al acelerómetro y no a la cabeza porque creemos que, gracias a la posibilidad de realizar un calibrado, el dispositivo podrá ser instalado el cualquier parte del cuerpo que, con su debida calibración, podrá controlar el programa.

La ventaja de saber el funcionamiento del menú de DasherUS, posibilita añadir un sistema para seleccionar el puerto COM utilizado. Si el sistema será manual o automático aun tenemos que estudiarlo, pero tampoco creemos que sea excesivamente complicado incluirlo.

Por ahora, nuestro trabajo se centrará en:

  • Terminar el menú de calibración.
  • Añadir el selector del puerto COM.
  • Limpieza de opciones no implementadas o inútiles de DasherUS.
  • Estudiar la posibilidad de traducción del programa.
  • Continuar con la documentación.

Documentación, calibrado y Viena

marzo 3, 2010

Antes de nada nos gustaría comentar algo que nos hace mucha ilusión que ha ocurrido recientemente. Hace aproximadamente un mes, aunque con pocas esperanzas, enviamos un borrador de nuestro proyecto a un congreso llamado ICCHP o International Conference on Computers Helping People. Sin embargo y contra todo pronóstico han aceptado nuestro artículo para ser presentado en Viena este mismo julio. Nos gustaría agradecer a nuestros tutores del proyecto el apoyo que nos han ofrecido en todo momento y que va a hacer posible algo que cuando empezamos no podríamos siquiera imaginar. Aunque aun no nos hayan dicho claramente si vamos a ir nosotros, ellos o nadie a presentarlo, la aceptación del artículo ya es un inmenso triunfo que indica que todo el trabajo realizado es interesante para la comunidad internacional y que, realmente, podemos ayudar a las personas. Como ha dicho Rafael Cabrera: “Aunque sólo consigamos ayudar a una persona, ya habrá merecido la pena“.

Con respecto al tema de la documentación, ya nos hemos puesto en marcha. Tras leer toda la reglamentación especificada en la página web del departamento y visto una guía de todo lo que se requiere, hemos empezado a recopilar datos de nuestro trabajo para plasmarlos en dicha documentación. Ésta posee una sección que creemos importantísima basada en las pruebas realizadas con nuestro proyecto. Para ello lo más seguro es que tengamos que desplazarnos a alguna asociación de personas discapacitadas, aunque eso no podemos planteárnoslo sin tener aún un sistema de calibrado efectivo de verdad.

Hablando de ese sistema, estamos planteando varias posibilidades para hacerlo. Creemos que la opción más factible sería almacenar unas coordenadas o unos datos útiles para nosotros en un archivo de texto en algún sitio. Gracias a ellos, DasherUS podría leerlos y hacer las modificaciones necesarias para calibrar el programa con la ventaja de que, si el sistema es usado siempre por la misma persona, no tendrá que estar calibrando una y otra vez. Ahora bien, el mecanismo de creación de ese archivo es lo que estamos estudiando. Barajamos las dos posibilidades obvias: modificar DasherUS para hacerlo desde dentro con un menú, o crear un programa externo para que lo haga. Sabemos que éste último, con mayor o menor dificultad, podríamos desarrollarlo bastante rápido. También sabemos que integrarlo dentro de DasherUS sería la opción ideal, pero modificar el programa nos resulta una tarea ardua debido al desorden del código.

En resumen, mientras esperamos a los profesores nos hagan una plaquita para amplificar las salidas del Arduino, nos centramos en hacer la documentación y calibrar el sistema para optimizar su uso. El final de curso está aquí mismo, así que… ¡Hay que darse prisa!

Average

enero 29, 2010

Tras un pequeño periodo en el cual apenas hemos podido hacer gran cosa entre unas cosas y otras, volvemos al trabajo con energías renovadas. En esta ocasión, con muchas cosas que hacer y poco tiempo para llevarlas a cabo, nos hemos dedicado a hacer diversas pruebas con distintos dispositivos:

Sensores y conectores

En la imagen podemos observar los nuevos sensores de los que disponemos para probarlos. Tres de ellos son acelerómetros entre los que están uno de 2g, otro de 5g y uno de 3 ejes. El sensor que es más grande que los demás es un giróscopo que por ahora no nos es de mucha utilidad pero vamos a estudiar si podríamos conectarlo a nuestro software. Todos ellos venían sin los pines conectados así que tuvimos que acercarnos a una tienda de electrónica para comprar todos los materiales necesarios para prepararlos para ser conectados a nuestro Arduino. Todo este trabajo se complicó cuando nuestro único soldador se estropeó sin más y nos hizo retrasarnos bastante.

Después de haber terminado las mediciones que comentaba en la entrada anterior y comprobar que los valores que enviaba el acelerómetro no eran tan poco lineales como pensamos en un primer momento, nos dispusimos a hacer un estudio de las palabras por minuto que podríamos escribir con nuestro sistema. Sin embargo, al intentar hacer esto, recordamos que si aumentábamos la velocidad de obtención de los datos, aumentaban los picos espúreos que recibíamos y éramos incapaces de eliminar. Tras barajar varias posibilidades de truncamiento y reconocimiento de outliers en las medidas, pensamos en que una simple media conseguiría el resultado deseado. Sin más dilación, nos pusimos a modificar el programa que teníamos cargado en el Arduino para que hiciera automáticamente la media de unos cuantos valores anteriores. Gracias a este sistema, el valor que envía la placa al ordenador no es el valor que obtiene del acelerómetro sino que es una media calculada con los valores enviados anteriormente. En un principio pensamos que habría muchos problemas que no tendríamos en cuenta con este sistema, que no iba a funcionar… nos equivocamos, ¡y vaya que si nos equivocamos! Los resultados de manejo que obtuvimos con este sistema fueron, sencillamente, impresionantes. Hemos conseguido justamente la fluidez y precisión que nos faltaba para que el sistema fuera realmente bueno.

Tras comprobar que DasherUS respondía correctamente, comenzamos a prepararlo todo para realizar las pruebas de palabras por minuto. Para ello nos fabricamos una especie de diadema con unos auriculares antiguos en los cuales le instalamos el acelerómetro.

Diadema de auriculares con acelerómetro

La instalación es bastante sencilla pero funciona perfectamente. Surgieron algunos problemas de ruido que se introducía en DasherUS pero comprobamos que era debido al Arduino. Si la placa se mueve demasiado o se tira mucho del cable, DasherUS se bloqueaba al no reconocer bien esos valores. En cualquier caso, todo esto en un futuro se podrá solucionar fácilmente aislando bien la placa de cualquier elemento externo que pueda influirle.

Pablo Anaya

Rafael Cabrera

Finalmente, hicimos las pruebas pertinentes. Nos preparamos algunas frases para escribir mientras cronometrábamos el tiempo que tardábamos. Decidimos que primero lo haríamos sin ningún diccionario de entrenamiento cargado, para ver cómo salía. Hay que reconocer que estos valores son un poco bajos, pero la gran ventaja de DasherUS es su capacidad de ir aprendiendo a medida que se usa. Gracias a este sistema de inferencia, pudimos llegar incluso a las 26 palabras por minuto, que no está nada mal comparado con las 29 del eyetracking o las 39 de uso experto con ratón. Creemos que para una persona discapacitada, el poder escribir a esta velocidad supone un gran avance en su calidad de vida, que es lo que precisamente pretendemos con este proyecto.

Respecto al software, no hay demasiado que contar ya que nos hemos centrado más en hardware y pruebas. Conseguimos adecentarlo un poco cambiándole el icono por uno nuestro, el nombre es oficialmente DasherUS y el menú “Acerca de:” lo hemos personalizado también. Otro avance ha sido localizar un menú con todas las strings con todos los textos del programa, así que eso nos facilita la posibilidad de traducirlo en un futuro.

¿Qué viene ahora? Pues seguir modificando el software para conseguir una mayor optimización de uso, opciones de calibrado de acelerómetro, limpieza de menús, y procurar conectarlo por otros interfaces a otros dispositivos. Respecto a hardware, intentar poner en funcionamiento el giróscopo ya que es significativamente distinto de lo que venimos haciendo hasta ahora.

Mediciones

diciembre 23, 2009

Aquí vemos la serie de modificaciones llevadas a cabo.

Básicamente en eso se basa el trabajo que estamos realizando últimamente. Gracias a un medidor de ángulos que nos proporcionaron en el Departamente, lo hemos adaptado un poco a nuestras necesidades. Nuestro objetivo es obtener una medida más exacta para conocer bien el funcionamiento de nuestros componentes y poder así entenderlos un poco mejor.

El trabajo se basa en obtener 180 mediciones, una por grado, y anotar el valor que nos devuelve el Arduino. Usando ese medidor de ángulos, le pegamos encima un papel con los grados impresos para que nos fuera más facil. Una vez hecho eso, lo pegamos a una tabla de madera con el objetivo de que se quedase lo más quieto y recto posible. Por último, pegamos con celo el acelerómetro al aparato para que no se moviera lo más minimo involuntariamente. A pesar de ello, la enorme inestabilidad de lo que nos dieron (ya que cuanto más se acerca al 180 más se afloja el tornillo y menos agarre tiene) dificulta mucho las mediciones así que vamos lentamente. Para colmo, una vez conseguimos afinar bien el grado que queremos medir, los valores que devuelve el Arduino pueden variar facilmente en ± 3 grados y tenemos que esperar hasta ver cual se repite más.

A pesar de todo, el proyecto sigue avanzando. Hoy hemos hablado con unos chicos que trabajan para el Departamento que están interesados en DasherUS para conectarlo a dispositivos de electroculografía y electromiogragía. Por nuestro lado, aún tenemos pendiente conectarle una plaquita que nos amplifique los valores que devuelve el acelerómetro y modificar opciones del programa para dar pie a más dispositivos y a una posible calibración. Todo esto sin hablar de la documentación que debemos ir haciendo.

Hay mucho trabajo por delante, pero a pesar de todo… ¡Seguimos trabajando!

¡Conectado!

diciembre 9, 2009

Como podéis ver, hemos logrado con éxito conectar Dasher con el Arduino y con una velocidad apta para el uso humano. Al final la solución fue crear una variable global para que gestionara el monitor. Con ésto, nuestro problema de que la apertura, configuración y cerrado del puerto que ralentizaba la obtención de las coordenadas quedó solventado. Tras hablar con nuestros tutores de proyecto del trabajo realizado, definimos los nuevos pasos a seguir:

  • Aumentar la resolución del acelerómetro mediante un pequeño circuito que vamos a fabricarnos.
  • Hacer un estudio de las salidas exactas de nuestro adxl3xx para distintos ángulos.
  • Estudiar las distintas posibilidades de incluir en el programa un menú para calibrar.
  • Hacer limpieza de opciones inservibles del programa.
  • Estudiar la posibilidad de traducir el programa.
  • Estudiar la posibilidad de conectar diversos dispositivos al Arduino para enviar los datos por puerto serie al Dasher.

Por ahora parece que vamos por el buen camino, cumpliendo los plazos, y finalmente vamos a firmar el documento para la adjudicación del proyecto y la idea es presentarlo en junio. Por último, lo único que falta comentar es que hemos detectado, unos picos en los datos obtenidos que hacen que cada cierto tiempo, y durante sólo una muestra, el cursor se sitúe en un lugar incorrecto de la pantalla.

¡Seguimos trabajando!

¡Se mueve!

noviembre 11, 2009

Estas últimas semanas hemos centrado nuestros esfuerzos en transformar, de alguna manera, coordenadas del acelerómetro a coordenadas de ratón. Como dijimos, atacamos al proyecto a través del puerto serie gracias a un monitor que conseguimos por Internet. Después de solventar todos los problemas que obtuvimos por integrar el código del monitor en el propio código del Dasher, conseguimos que éste “escuchara” al Arduino. El siguiente paso fue adaptar esas coordenadas al ratón, cosa que conseguimos mediante una simple transformación lineal.

Así que, ¿cómo está la cosa actualmente?. Dasher recibe los datos del ratón correctamente del puerto serie, por el cual el Arduino está enviando las coordenadas. El programa después las transforma haciéndolas válidas para usarlas por el cursor. En efecto, hemos conseguido que el acelerómetro controle al Dasher.

¿Entonces ya está todo hecho? Ojalá, pues nuestro problema actual reside en que Dasher recibe las coordenadas del puerto serie de manera demasiado lenta, así que el ratón va a trompicones. Creemos que debe ser porque estamos continuamente abriendo, leyendo y cerrando el puerto COM, proceso el cual tarda un tiempo en efectuarse.

¿Próximo objetivo? Conseguir, mediante recolocación del código, acelerar esa obtención de coordenadas para que el movimiento del cursor se haga de forma natural. Pero eso, por supuesto, conllevará resolver infinidad de problemas que también se nos presentarán.

¡Tiembla puerto serie!

octubre 8, 2009

Porque vamos a por él. Sí señores, lo tenemos todo listo para comenzar a pedirle datos al puerto serie virtual que se crea al conectar el Arduino. Hemos conseguido un serial monitor para C++ que hemos analizado a fondo y cuidadosamente para comprenderlo al 100%. Como tuvimos poco tiempo no pudimos integrarlo en el Dasher pero actualmente esa es nuestra idea. De momento hemos descartado la opción que comentamos en el anterior post de usar sockets puesto que no está del todo implementado en el programa. Al usar tanto la versión oficial instalable para Windows como la nuestra compilada, nos encontramos con dos opciones de entrada: Tilt Socket, Mouse imput y Socket. Tilt Socket hace que el programa se cuelgue, Mouse input es la opción por defecto y Socket se supone que debería funcionar pero si cambias el puerto los valores toman datos inesperados como 0 ó -1. Pero eso no es todo, porque si le das a guardar, todos los datos toman otro que no coincide con el que le has metido. En definitiva, un caos absoluto. Ésto nos ha hecho pensar que es posible que los creadores hicieran el programa con las cositas básicas o, digámoslo así, la carcasa, para después ir después metiéndole cosas poco a poco. Nuestra conclusión es que el método de entrada por socket aun no está implementado y, por tanto, tenemos que tomar una ruta alternativa.

En nuestra próxima sesión de proyecto integraremos el código del serial monitor en Dasher de manera que éste obtenga los datos enviados por el arduino y trabaje con ellos. La mayor dificultad que se nos presenta es dónde meter ese código nuevo. Nuestras conclusiones, en el próximo resumen del día.