Agregador de canales de noticias

Tras las actividades de pulsar sobre las figuras, hoy he añadido una actividad consistente en arrastrar y soltar:


Como se puede observar, además he añadido un fondo al escenario, e instrucciones de en qué consiste la actividad.

Una vez que el alumno sabe arrastrar y soltar, podemos pasar a un ejercicio de discriminación de formas:


En esta otra actividad el alumno tiene que elegir la forma adecuada antes de empezar a arrastrar.

Los niños de educación infantil (preescolar) deben realizar un apresto, es decir, prepararse para aprender a leer y escribir.

Por tanto las primeras actividades de la Cartilla Ilustrada se orientarán a la percepción visual, auditiva, orientación espacial, coordinación sensomotriz (sicomotricidad), etc.

He implementado las dos primeras actividades.

En la primera aparece en pantalla una figura geométrica, que el niño debe pulsar.  Cuando lo hace, aparece una nueva figura en otra posición, repitiéndose el proceso.

La segunda actividad es similar, pero en este caso la figura no es estática, sino que se desliza por la pantalla, de modo que se exige al niño una mayor coordinación.
Las próximas actividades desarrollarán la discriminación visual.

Mar 27, 2015 NumberDance pushed to master at NumberDance/InformaT

• 7e783a2 Creando Usuarios

.

Se empieza a realizar cambios en el código para que sea
las legible y intente seguir el estilo del kernel.

Commiter:
José María Caballero Alba
caballeroalba@gmail.com
Added:

Modified:
src/chain.c
src/main.c
src/screen_work_flow.h

Deleted:

Commit:
Link

Repositorio

Hello there! I’ll write today a brief review of how DPMbox manage the file uploads, and how we solved a small problem that had complicated this feature.

So, the steps to upload a file to the Disk Pool Manager would be as folllows:

In the DPM architecture one entity handles the namespace with the metadata, and other ones store the files with the actual data. This means that any request must go through a server hosting the namespace first, and then redirect to the disk node storing the physical file. We execute a PUT call and the file won’t be yet uploaded but DPM will answer back, then our web application has to try a second time. The URL needed to actually do the PUT would look like this, you can see the specific DPM node where the file will be uploaded, including a token validating the transaction:

http://lxfsra04a04.cern.ch/srv/dpm/01/nogroup/2015-03-02/XHR.js.zip.2900489.0?sfn=%2Fdpm%2Fcern.ch%2Fhome%2Fdteam%2Faalvarez%2Fpublic%2Fcollection_d%2FXHR.js.zip&dpmtoken=dbf5fcbe-7c31-4849-aa57-b07c6b474f5e&token=ojkU%2FdgyPqTYEvu4TfZAyueVDqQ%3D%401425288602%401

User agents commonly apply same-origin restrictions to network requests. These restrictions prevent a client-side Web application as DPMbox running from one origin from obtaining data retrieved from another origin, and also limit unsafe HTTP requests that can be automatically launched toward destinations that differ from the running application’s origin. In user agents that follow this pattern, network requests typically include user credentials with cross-origin requests, including HTTP authentication and cookie information. As DPMbox relies heavily on XHR calls this has to be handled carefully or we’ll face a lot of error messages like this:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://lxfsra04a04.cern.ch/dpm/cern.ch/home/dteam/aalvarez/public/test5.file. (Reason: CORS header 'Access-Control-Allow-Origin' missing).

You can check a bit of history of XHR and CORS and why is this happening here [2].

Back in our development, the DPM initial behaviour was to answer with a 302 code indicating redirection, and then the browser will try transparently to reach that new location. That would work it out, but the thing is that 30x responses are treated as error by CORS specification [1]:

This is the actual request. Apply the make a request steps and observe the request rules below while making the request.

If the response has an HTTP status code of 301, 302, 303, 307, or 308 Apply the cache and network error steps.

(…)

Whenever the network error steps are applied, terminate the algorithm that invoked this set of steps and set the cross-origin request status to network error.

Note: This has no effect on setting of user credentials. I.e. if the block cookies flag is unset, cookies will be set by the response.

Whenever the cache and network error steps are applied, follow these steps:

Remove the entries in the preflight result cache where origin field value is a case-sensitive match for source origin and url field value is a case-sensitive match for request URL.

Apply the network error steps acting as if the algorithm that invoked the cache and network error steps invoked the network error steps instead.

So with ths configuration it would be impossible to get any information of the response, not any header at a JavaScript level, specifically the Location header. Finally, the solution given was manage the uploads though a first empty PUT including a header X-No-Redirect and the server will answer with a 202 Accepted response. We can extract any header from this type of response as it’s not treated as error for XHR CORS requests.

After this we have to add this new header information to our server CORS security settings and add it to the directive Access-Control-Expose-Headers. There’s a lot of tutorials for different servers CORS configuration, for example you can check this one for Apache [2]. But in the end, in the server side we would need to configurate it as to response with this headers:

Access-Control-Allow-Origin: UrlWhereDPMboxIsHosted.host Access-Control-Allow-Credentials: true Access-Control-Allow-Methods: ACL, CANCELUPLOAD, CHECKIN, CHECKOUT, COPY, DELETE, GET, HEAD, LOCK, MKCALENDAR, MKCOL, MOVE, OPTIONS, POST, PROPFIND, PROPPATCH, PUT, REPORT, SEARCH, UNCHECKOUT, UNLOCK, UPDATE, VERSION-CONTROL Access-Control-Allow-Headers: Authorization, Overwrite, Destination, Content-Type, Depth, User-Agent, Translate, Range, Content-Range, Timeout, X-File-Size, X-Requested-With, Accept, Accept-Version, If-Modified-Since, X-File-Name, Cache-Control, Location, Lock-Token, If, X-No-Redirect Access-Control-Expose-Headers: DAV, content-length, Allow, Location

At first, find a solution to this problem was tough since I’m not very familiar with this Cross-Origin Resource Sharing HTML5 new settings, but after all it was properly (and happily) solved. Good night!

References:

[1] W3 CORS specification w3.org/TR/cors

[2] Unleash your AJAX requests dev.housetrip.com/2014/04/17/unleash-your-ajax-requests-with-cors

[3] CORS and complex AJAX requests danieldemmel.me/blog/2013/01/18/getting-cross-origin-resource-sharing-with-complex-jquery-ajax-requests

Hoy hablaremos sobre la aplicación para móvil de android. Este es el “Splash” de la aplicación. El dibujo es el también el lanzador de la aplicación

La función de esta imagen es preparar la aplicación al inicio de la misma ya que necesita una conexión con el servidor para cargar los objetos, cargar la lista de electrodomésticos disponibles, saber cual es su configuración y el estado en el que se encuentra en ese momento. Por ejemplo, imaginaros que alguien en casa enciende el aire acondicionado, la aplicación cuando se conecte deberá saber que ese electrodoméstico esta encendido y mostrárselo al usuario.

Ahora pasemos a ver la aplicación principal que consta de una lista expandible de electrodomésticos y una sublista con la configuración para cada elemento.

En cuanto a la listas se pueden observar varios elementos:

• Texto del electrodoméstico: Indica el nombre del electrodoméstico (por ejemplo “Cafetera” o “Aire Acondicionado”)
• Texto del modo: Indica en el modo en el que se encuentra. Existen dos modos: modo predictivo y modo tiempo fijo(los explicaremos más adelante).
• Botón Interruptor: (,) Actúa como un habilitador de la vista, activa la configuración seleccionada y habilita el resto de los botones. Si está en gris se encuentra desactivado y en azul activado.
• Botón Modo: (, ,,) Habilita el modo que se desee.Este icono significa que está en modo “tiempo fijo”, significa que el electrodoméstico se encenderá en una hora en concreto y si se desea un hora también para apagarlo. Este otro significa que está en modo “predictivo”, significa que el aparato se encenderá cuando, según el tiempo establecido para que el aparato cumpla su objetivo, el usuario se esté aproximando a la casa. Pongamos un ejemplo para aclarar esto, en el caso de que el aire acondicionado necesita unos 20 minutos para calentar la casa (y esa es su función), si la persona activa la ventana con el modo predictivo y con una configuración de 20 minutos, cuando el servidor compruebe que el usuario tardará menos del tiempo estipulado, el electrodoméstico se encenderá. Así que cuando llegues tendrás la casa calentita para ti sin tener que esperar.
• Botón Encendido: (, , ) Este botón ofrece la información para saber si un electrodoméstico está encendido (Verde) o apagado(azul) y también ofrece la acción de encenderlo y apagarlo sin hacer caso de la configuración predefinida. Si está en gris es porque la vista se encuentra desactivada por el “botón interruptor”.
  Esto es todo lo que hay en la parte de lista de objetos, ahora pasemos a explicar la parte de la sublista, ésta actúa como configurador de los dos modos que tenemos. veamos que contiene:

Esta parte pertenece a la configuración de modo ”Tiempo Fijo”, se puede modificar la hora de inicio para encender la aplicación y si activamos el “Check Button” podemos configurar una hora de apagado. Para cambiar las horas, llamo a un “Time Picker Dialog” que se lanza al pulsar en el texto de la hora.

Esta otra parte pertenece a la configuración de modo “Predictivo”, es un “Edit Text” donde se ponen los minutos de preparación del electrodoméstico. Como habíamos explicado anteriormente con un ejemplo, si el aire acondicionado necesita 20 minutos para cumplir su función, se ubica en este apartado. Tambien, por ejemplo, si la cafetera necesita 5 minutos para hacer una jarra de cafe, en la configuración pondríamos 5 minutos. Y el resto lo hacemos nosotros.

También en el menú (Esos tres puntos verticales que se ven en la esquina superior derecha) hay un apartado ayuda que explica brevemente como funciona la aplicación.

A partir de esta semana (15 al 20 de abril) me limité a escribir la tesis, dejando el blog un poco de lado, haciendo simplemente algún borrador. La tesis la esquematicé de la siguiente manera: (5 puntos) Introducción (respuesta a las 5W). What?, qué es Shoali. Who?, quién lo hace (desarrolladores), quién lo usa (prestamista, […]

En esta sección se listan y detallan los recursos software y hardware empleados en la construcción de la plataforma.

Hardware

• Raspberry Pi - Se trata de la unidad de detección y despliegue del sistema. Se ha utilizado el modelo B con 512 MB de memoria RAM.

• Raspberry Pi Camera Board - Se trata de una minicámara de 5MP con un sensor Omnivision 5647, que se conecta directamente a la Raspbery Pi a través de un conector CSI.

• Proyector portátil - Se trata del medio principal que permite el despliegue de gráficos del sistema. El proyector empleado es un Optoma PK320 que soporta una resolución panorámica máxima de 854x480.

• Amplificador de Audio - Se trata de un circuito integrado LM386 montado en una placa de test con un altavoz de 1W para proporcionar audio al sistema.

• Tarjeta de memoria - Se emplea una MicroSDHC Trascend de 32GB clase 10, como unidad de almacenamiento de la Raspberry Pi. Proporciona una velocidad de lectura y escritura de 20 MB/s y 17 MB/s respectivamente.

• Equipo informático - Para el desarrollo del proyecto ha sido necesario hacer uso de un computador conectado por red a la plataforma Raspberry Pi, para poder acceder remotamente a ella y de esta forma ejecutar las pruebas. El equipo es un Intel Core i7-2600K 3.4 GHz 4 núcleos y dos hilos por núcleo 16 GB de RAM y Nvidia GeForce GTX 560 Ti.

Software

A continuación se enumeran las diversas herramientas software empleadas y diferenciadas por categorías:

Lenguajes de programación

• C++ - El lenguaje empleado para el desarrollo del proyecto ha sido C++, debido a la eficiencia y velocidad de ejecución que proporciona a la hora trabajar en aplicaciones y sistemas en tiempo real. También por ser el estándar referente en bibliotecas gráficas y de visión artificial.

• GLSL - El lenguaje de programación de shaders para OpenGL. Para la elaboración de los distintos componentes gráficos se hace uso de distintos shaders que sirvan para dibujar círculos, aplicar texturas o simplemente transformar los vértices de los componentes.

Sistemas Operativos

• Debian - Es una distribución de GNU/Linux desarrollada y mantenida por una comunidad de voluntarios. Es una de las famosas y un gran número de distribuciones están basadas en ella. Para el desarrollo del proyecto se ha utilizado la versión unstable.

• Raspbian - Es una distribución de GNU/Linux basada en Debian Wheeze especialmente diseñada y optimizada para la ejecución en la placa Raspberry Pi con CPU ARMv6

Aplicaciones de desarrollo GNU

• GNU Emacs - Editor y entorno de desarrollo. Se ha utilizado la generación del código fuente y la escritura de la documentación. Se han empleado, además, algunos plugins como ECB, que añade al editor funcionalidades propias de un entorno de desarrollo completo.

• GNU Make - Herramienta para la compilación incremental, con soporte multiproceso.

• GNU GCC - La colección de compiladores GNU. En concreto se ha utilizado el compilador de C++ (g++).

• GNU GDB - Se trata del depurador por excelencia de los sistemas GNU/Linux.

Bibliotecas

• OpenCV - Biblioteca libre que proporciona funciones dirigidas principalmente para el desarrollo de aplicaciones de visión por computador en tiempo real. La versión utilizada es la 2.4.9

• OpenGL ES 2.0 - Se ha empleado OpenGL por soportar aceleración gráfica en la unidad de detección y despliegue.

• RapidXML - Se trata de un intérprete o parser para archivos XML.

• RaspiCam - Es una biblioteca para la utilización de la cámara Raspberry Pi Board desarrollada en C++ por el grupo de investigación «Aplicaciones de la Visión Artificial» de la Universidad de Córdoba.

• SDL Mixer - Por su facilidad de uso y potencia se ha empleado esta biblioteca para la reproducción de audio del sistema.

• freetypeGlesRpi - Como se comentó anteriormente, son escasas las bibliotecas de carga y despliegue de textos basados en fuentes true-type. Esta biblioteca ofrece una solución a tal problema.

• GLM - Se trata de una biblioteca matemática que abstrae al desarrollador de las operaciones algebraicas empleadas a la hora de realizar transformaciones 3D.

• Simple OpenGL Image Library (SOIL) - Se trata de una pequeña biblioteca escrita en C usada principalmente para cargar imágenes como texturas en OpenGL. Soporta una gran cantidad de formatos, como PNG, JPEG y BMP, entre otros.

• Boost.Asio - C++ no especifica nada relativo a redes o sockets en su estándar. Por esto mismo se ha empleado la biblioteca Asio de Boost para gestionar la comunicación por red.

Control de Versiones

• Git - Sistema de control de versiones distribuido. Como repositorio central se ha utilizado la plataforma GitHub.

Este post pretende explicar de forma breve y concisa los diferentes modelos de red, así como las técnicas utilizadas para reducir los efectos de la latencia en los videojuegos actuales.

click to read the rest of the article

Con la idea general del proyecto definida, se adquieren un par de Raspberry Pi y se realiza una búsqueda de pico-proyectores candidatos para utilizar. El proyector debe tener un precio ajustado, ser lo más reducido posible, y además, tener una luminosidad suficiente para que las proyecciones sean visibles en estancias iluminadas.

Una vez recibida la Raspberry Pi, se procede a la configuración del entorno de trabajo. Este proceso incluye la instalación del sistema operativo Raspbian, la biblioteca OpenCV, compiladores, editores y la configuración del servicio de SSH para poder controlar la Raspberry desde el puesto de trabajo.

Finalmente, se mantuvo una reunión con los miembros de la Asociación ASPRONA para explicarles los objetivos del proyecto y obtener de ellos, un escenario de casos de uso basados en la experiencia que tienen en la inserción laboral de personas con discapacidad. Estos casos de uso, se transformó en una especificación de requisitos para nuestro sistema.

Iteración 1

Las limitadas capacidades de la Raspberry Pi y la experiencia que otros programadores han tenido a la hora de trabajar en sistemas de visión por computador en este dispositivo, nos pone en alerta de que es posible, llegado un momento, la alta carga de computo que tienen los procesos de visión por computador afecten al rendimiento y perdamos la sensación de tiempo real. Las consecuencias de esto, es que sea necesario que los procesos más costosos deban ser ejecutados en otro dispositivo o computador con mejores prestaciones.

Partiendo de las premisas anteriores, no queda otra opción que realizar una arquitectura completamente modular y con todos los subsistemas desacoplados. Una clase core será la encargada de inicializar todos los subsistemas, establecer las comunicaciones entre ellos, y ejecutar la lógica de usuario soportada dentro de un bucle infinito.

El objetivo de esta primera iteración es obtener una arquitectura básica, que iremos completando y refinando en cada una de las sucesivas iteraciones. Se decide que el sprint abarque la construcción y pruebas de las siguientes historias:

• Captura de imágenes. La Raspberry tiene la opción de conectar cámaras USB. Se construye un módulo de captura de vídeo, utilizando las funciones de la clase VideoCapture de OpenCV, que proporciona los distintos frames necesarios para dar soporte al resto de módulos del sistema.

  Para la medida de rendimiento, se implementa el cálculo de los FPS que da el sistema a la salida y que nos va a determinar si se obtienen resultados aceptables para un sistema de tiempo real. Los primeros resultados son mucho peores de lo esperado. A una resolución de 320x240 píxeles y sólo realizando el proceso de captura y visualización de los frames capturados en pantalla, se observa un lag de 2 segundos y una tasa de 2 FPS.

  Si estos valores son inadmisibles en un sistema en tiempo real con una arquitectura tan básica, y sin realizar ningún tipo de procesado en la imagen, cuando se deba realizar algún tratamiento a la imagen o computo adicional, el sistema no será usable, con una sensación de bloqueo del sistema para el usuario.

  Se vuelven a realizar las pruebas con otra cámara USB más moderna (Logitech S720) y afortunadamente los resultados mejoran sensiblemente, a 6 FPS y hasta 10 FPS para imágenes obtenidas en blanco y negro.

• Detección de una hoja de papel. Mediante segmentación de la imagen obtenida, se detecta una hoja de papel y se obtiene la posición de sus 4 esquinas en píxeles de pantalla. Esta funcionalidad se encapsula dentro de la clase PaperDetector Durante las primera fase de pruebas nos pone en situación de los numerosos factores que influyen en este tipo de sistemas. El primero de ellos es la iluminación. El tipo de luz (natural, fluorescente, incandescente,...), intensidad de la luz natural (luz por la mañana, al mediodia o por la tarde), dirección de la luz (crea sombras en uno u otro sentido), los reflejos producidos por las superficies se convierten en interferencias en forma de grandes manchas en la imagen. Incluso se han detectado variaciones en la detección al encontrase varias personas entre el sistema y una ventana.

Iteración 2

Los objetivos de esta iteración venian condicionados por los malos resultados obtenidos en el sprint anterior. Hay que conseguir mejorar enormente los resultados anteriores o la viabilidad del proyecto se verá seriamente afectada.

• Optimización de la captura de imágenes. Durante las pruebas de la iteración anterior, con sólo cambiar la cámara USB se obtuvieron grandes mejoras, por lo que la elección de la cámara era un elemento importante. Tras consultar en diversos foros especializados, se decide que la mejor opción es utilizar la Raspberry Pi Camera Board. Esta cámara está especialmente diseñada para utilizarse en la Raspberry, y se conecta directamente al conector CSI de la placa mediante un cable plano flexible de 15 pines. Dispone de un sensor de 5MP de resolución y puede llegar a grabar vídeo a 1080p a 30 fps.

  El gran inconveniente de es que la cámara no incluye drivers video4linux, por lo que cualquier biblioteca para lectura de cámaras web estándar, OpenCV incluido, no es capaz de obtener los frames producidos. Se investiga la manera que tienen las aplicaciones para acceder a la información de la cámara, y se encuentran unos drivers en desarrollo, basados en la API MMAL, que ha liberado la Universidad de Córdoba.

  Tras utilizar en el módulo de captura los nuevos drivers para la Raspberry Camera Board, se realizan de nuevo los test de rendimiento, y obtenemos casi 30 PFS, que es un buen resultado para aplicaciones en tiempo real.

• Calibrado de la cámara. Se construye un programa externo para el calibrado de la cámara basado en un patrón de tablero de ajedrez. Esta primera versión, devuelve un fichero XML con los parámetros intrínsecos de la cámara y los coeficientes de distorsión obtenidos, pero no tiene en cuenta el error de reproyección.

• Sistema básico de cálculo de homografías. En esta primera fase, los cálculos son los necesarios para realizar el registro y visualizarlo en la pantalla del ordenador. Dentro del proyecto, se crea la clase CameraModel encargada de leer los ficheros de calibración y almacenar los parámetros propios de la cámara que serán utilizados para el cálculo de los parámetros extrínsecos.

  Para el cálculo y almacenamiento de la posición de los folios respecto a la cámara se construye la clase Paper.

  Las pruebas realizadas al módulo de cálculo de la posición y rotación del papel, son satisfactorias, y se puede comprobar que el dibujado de ejes de coordenadas, o distintos poliedros en el espacio 3D es correcto y perfectamente alineado con el papel.

• Dibujado mediante OpenCV. En la iteración anterior se realizaron una serie de funciones auxiliares para dibujado de contornos, puntos y polígonos mediante OpenCV que sirviesen de soporte para el «modo debug». Para la iteración actual, estas funciones se ha aumentado con dibujado de ejes de coordenadas, cubos y ortoedros para validar los cálculos de la posición y rotación de los folios. También permite recibir una ventana con la imagen por medio de SSH. Con todas estas funciones se ha creado la clase estática DrawCV.

Iteración 3

El siguiente paso es incorporar el proyector al sistema. Acoplando la Raspberry Pi sobre el proyector y colocando la raspiCam junto a la lente obtenemos un conjunto compacto y reducido. El sistema se monta sobre un trípode y se coloca en dirección a la mesa.

Los objetivos son, por tanto, obtener un sistema de calibrado. Debido a la complejidad de la tarea, se establece como la única tarea a realizar en este sprint.

• Calibrado del sistema cámara-proyector. Un proyector se calibra usando los mismos algoritmos que una cámara ya que puede considerarse como una «cámara invertida». Sin embargo como el proyector no ve, y el método no es tan directo como en el caso de una cámara. Además es necesario realizar los cálculos para la transformación entre el sistema de referencia de la cámara y el sistema de referencia del proyector.

  El estudio de distintas técnicas de calibrado nos llevó a considerar dos procedimientos. El primero, siguiendo el enfoque de Zhang, en el se utilizan patrones planos, y el propuesto por Daniel Moreno y Gabriel Taubin, basado luz estructurada.

  Aunque según los papers consultados, el método basado en luz estructurada, es más preciso que otras técnicas de calibrado, el procedimiento es más costoso de realizar. El método de Zhang, permite un procedimiento más flexible, no necesita una preparación exhaustiva de la escena y tiene una precisión aceptable para los objetivos de nuestro proyecto.

  Con el código para el calibrado de cámaras de la iteración anterior, realizamos una ampliación para añadir la funcionalidad del calibrado del proyector.

  Para calibrar el proyector, es necesario obtener un conjunto de coordenadas 3D-2D correspondientes. Las coordenadas se determinan utilizando la cámara situada en una posición con una vista similar a la que tendría el proyector. El método consiste en realizar una proyección de un plano de calibrado y establecer la correspondencia entre lo proyectado y lo que ve la cámara.

  Ahora dispondremos de los puntos 3D en el sistema de referencia global (el patrón), y también su proyección (puntos 2D en la imagen) en el sistema de referencia de la cámara y en el sistema de referencia del proyector.

  Finalmente, aplicando un procedimiento de calibrado estéreo como el que proporciona OpenCV obtenemos la transformación entre la cámara y el proyector.

  El resultado, con los parámetros intrínsecos y extrínsecos, se escribe en ficheros YAML para cargarlos en el sistema. Mientras que la cámara y el proyector mantengan su posición y rotación entre ellos, no es necesario realizar una nueva calibración y es posible mover todo el sistema.

  Entre las decisiones tomadas en este sprint, fue realizar el calibrado como una aplicación externa al sistema. Esto nos permite la reutilización del módulo para otros sistemas estéreo.

  Otras decisión fue la resolución de imagen con la que trabajaría el sistema. El proyector tiene una resolución nativa de 854x480 en formato 16:9, pero la Raspberry Pi no la soporta. Se eligió una resolución de 1280x720, pero con este tamaño de imagen, el rendimiento disminuía significativamente. También se utilizó 800x600 en formato 16:9, pero la distorsión que realizaba el proyector para mostrar la imagen en formato panorámico no podíamos medirla para realizar una corrección, y los puntos calculados no correspondían con los objetos situados sobre la mesa.

  La resolución que se estableció finalmente fue de 800x600 en formato 4:3. Se perdía algo de superficie de proyección, pero con aumentar un poco la distancia entre el proyector y la mesa se compensaba esta área, y además, el rendimiento del sistema con esta resolución era adecuado y entraba dentro de los parámetros para un sistema de tiempo real.

Iteración 4

Desde la iteración 2, se arrastraba un pequeño bug en el cálculo de los parámetros extrínsecos del papel. Entre los objetivos planificados en esta iteración se decidió que también se corrigiese este bug, quedando finalmente el sprint backlog con los siguientes elementos:

• Corrección de la orientación del papel. En el cálculo de los parámetros extrínsecos del papel, dependiendo de la posición del papel, el sistema confundía la orientación y consideraba que el papel se encontraba apaisado cuando realmente no era así.

  La corrección del bug fue relativamente sencilla. Tras una serie de pruebas rotando la hoja de papel para comprobar en que casos se producía el error, se observó que el problema era debido a como OpenCV enumera las esquinas del papel.

• Detector de documentos mediante descriptores de imágenes. Se eligió utilizar SURF como detector y descriptor de características debido que es más rápido y robusto que otros algoritmos. Aun así, la implementación de esté modulo se realizó utilizando los wrappers que proporciona OpenCV para la construcción de detectores y descriptores, y que tiene como ventaja, cambiar el algoritmo aplicado sin necesidad de modificar la implementación, únicamente modificando en el constructor un string con el método que queramos utilizar (BRISK, ORB, SURF,...).

• Optical Flow. Para la estimación y descripción del movimiento, se implementó Optical Flow (Lucas-Kanade) que proporciona herramientas para detección, segmentación y segumiento de la hoja de papel en la escena a partir de un conjunto de imágenes. En etapas posteriores, debido a la oclusión que se realiza sobre el papel, se decidió que no cumplía las expectativas como metodo de tracking y se rechazó.

Iteración 5

A estas alturas del desarrollo del proyecto, la carga de trabajo que debe soportar la Raspberry Pi es muy significativa. Se aprecia que el rendimiento se ve afectado al incluir la detección de documentos, ya que es una tarea costosa para el sistema, y aun queda por implementar el módulo de interacción natural, que se trata también de una tarea con gran carga de trabajo.

• Implementación de Arquitectura cliente/servidor Como ya se venía observando, en cada iteración el rendimiento general del sistema en la Raspberry era cada vez menor. La solución fue crear una arquitectura cliente-servidor que permitiese la delegación de tareas entre la Raspberry Pi y un servidor. Este servidor, seria el encargado de realizar la ejecución de los módulos más costosos del sistema y descargar a la Raspberry Pi, para realizar las tareas de captura y representación más holgadamente.

  Gracias a que se tuvo en cuenta que este caso pudiese ocurrir, y la decisión temprana construir un sistema modular y desacoplado, la migración al servidor y la conexión mediante la unidad de delegación de tareas fue prácticamente transparente y sin realizar modificaciones en los módulos creados.

  Aprovechando esta arquitectura, también se separó el programa de calibración, lo que supuso una reducción considerable del tiempo empleado para realizar el calibrado del sistema cámara-proyector.

• Implementación de un histórico de percepciones Al igual que en ARToolKit, se desarrolla una función de tratamiento del histórico de percepciones para estabilizar el tracking. Este histórico se implementa almacenando las últimas 4 percepciones similares y realizando una media ponderada, en la que las percepciones recientes tienen más peso que las antiguas.

  Para determinar si son percepciones próximas se establece un umbral. Mediante el uso de esta técnica eliminamos gran parte del efecto tembloroso en la proyección.

• Optimización del proceso de detección de rectángulos La función para detectar hojas de papel implementada en la iteración 1 es muy básica. No permite que exista ninguna oclusión y es muy sensible a la iluminación. Tras un estudio de técnicas alternativas, se opta por implementar el cálculo de la envoltura convexa del contorno. Además de ser un algoritmo más reducido, la mayor ventaja que aporta este método es que tolera ciertos solapamientos en los bordes del papel.

  Para optimizar más la función, se sustituye el método de binarización de la imagen. Se cambia la umbralización adaptativa por el método de Canny. Con este cambio, se obtiene un algoritmo más robusto, más tolerante a la iluminación y que devuelve bordes más finos, con lo que también aumenta la precisión del sistema.

Iteración 6

Esta iteración supone la construcción del sistema de interacción natural de usuario. Al finalizar esta iteración, se podrá realizar acciones sobre los botones que se están desarrollando en la parte cliente, y que permitirán ofrecer una experiencia de usuario muy enriquecida al mostrar información opcional a petición del usuario.

• Segmentación de manos Para extraer el contorno de la mano de la imagen se decide utilizar un filtrado por el color de la piel. Existen numerosos artículos sobre este tema, y todos concluyen que los mejores resultados se obtienen realizando la búsqueda en el espacio de color HSV (Hue, Saturation, Value). Para convertir las imágenes a este espacio de color, es necesario que la captura se realice en color. Hasta esta iteración, la adquisición de imágenes se estaba efectuando en escala de grises, ya que consumía menos recursos, y el color no era una propiedad que necesitásemos.

  Teniendo en cuenta que los procesos de cálculo están en el servidor, obtener las imágenes a color no supuso una pérdida de rendimiento en el sistema. Además, con sólo realizar la conversión a escala de grises de la imagen, los métodos ya implementados y que no necesitan la imagen a color, no tienen que ser modificados.

  La segmentación implementada, se basa en la selección del los píxeles de la imagen que pertenezcan al rango habitual del color de la piel. Para aumentar la tolerancia del algoritmo, se le aplica a la imagen una serie de filtros, y finalmente se obtiene una máscara con la región de la mano en la imagen.

• Cálculo de la posición del dedo Una vez obtenida el contorno de la mano, se debe buscar su posición. En un principio se pensó en implementar el reconocimiento de todos los dedos de la mano, pero se optó por sólo reconocer el índice. Esta decisión, vino determinada por la funcionalidad de interacción que se iba a implementar, que era la pulsación de un botón, por lo que examinar la posición del resto de los dedos es, en principio, innecesaria.

Iteración 7

Con el sistema de interacción de usuario funcionando, se advierte que el módulo de detección de papeles funciona correctamente cuando no hay solapamientos o si la oclusión se encuentra muy próxima a los bordes. En la reunión del sprint se considera que se debe implementar una nueva mejora de la detección de papeles.

• Detección de papeles con solapamiento. Analizando los solapamientos que se realizan sobre el papel en función de las posiciones de la mano, se observa que normalmente quedan visibles partes de los lados del papel. Se decide realizar la búsqueda de segmentos rectos mediante la transformada de Hough y generar las posibles combinaciones de 4 segmentos del conjunto de rectas detectadas. Aquellos que cumplan las restricciones de formar una hoja de papel, serán los posibles candidatos.

  Este segundo método de detección es más costoso que el anterior, por lo que se determinó que de forma predeterminada, el sistema utilizase la detección basada en la envoltura convexa cuando no existiesen solapamientos, y en caso de fallo, se aplicase esta nueva función. Los resultados de las pruebas fueron muy satisfactorias. Esta nuevo algoritmo detectaba el papel aún existiendo grandes solapamientos, tanto en bordes como en esquinas del documento.

Iteración 8

Recibimos de la Asociación ASPRONA una serie de formularios y partes de trabajo para que se implementase un caso real mediante los documentos que ellos utilizaban habitualmente. Las tareas que se realizan son la preparación y entrenamiento del sistema para adecuarlo a la documentación recibida.

Para facilitar el cambio de configuración y no tener que recompilar constantemente, se implementa un gestor de configuración. Este gestor nos permite la modificación de los distintos parámetros del sistema sin la necesidad de recompilar nuevamente el proyecto cada vez que se realiza un cambio. También, de cara a la versión final, se ajustan el sistema para que no sea necesario utilizar una base de fondo negro, que se estuvo utilizando para mejorar el contraste entre papel y mesa.

Se concertó una reunión final con la Asociación ASPRONA, donde tras la demostración, expresaron interés por el sistema y el potencial que tiene para la adaptación y ayuda a personas con discapacidad en el puesto de trabajo.

Mar 24, 2015 NumberDance pushed to master at NumberDance/InformaT

• 2843d40 Creando Paises

El objetivo de este proyecto es construir un sistema de ayuda a la gestión de documental que permita el tratamiento directo sobre documentos físicos impresos mediante el uso de técnicas de visión por computador, síntesis visual y auditiva y técnicas de realidad aumentada.

Características de los usuarios

Aunque el usuario final del sistema, será cualquier persona que necesite soporte en la gestión documental de documentos impresos, el fin de esté proyecto es construir un sistema que permita la integración laboral a personas con discapacidad.

El tipo de usuarios a los que estará dirigido son, en primer lugar, personas que pueden presentar un amplio espectro de discapacidades. El sistema debe proporcionar soporte a usuarios con discapacidades sensoriales (visuales y auditivas) e intelectuales.

Restricciones

Debido a los objetivos del sistema, se deben tener en cuenta las siguiente restricciones:

• Funcional en dispositivos móviles. El prototipo final se construirá sobre un dispositivos con arquitectura ARM con limitaciones de tanto en capacidad de computo como memoria. El sistema deberá estar optimizado para este tipo de dispositivos, obteniendo una respuesta fluida y en tiempo real.

• Se debe basar en componentes de bajo coste. Para facilitar la implantación real en el entorno de trabajo, deberá funcionar con componentes de bajo coste, incorporando mecanismos de corrección de distorsión y registro 3D totalmente software.

Interfaces Hardware

• La implementación del sistema se realizará sobre una Raspberry Pi Modelo B de 512MB de RAM y arquitectura ARM.

• La visualización será a través de un pico-proyector mediante conexión HDMI.

• El acceso al sistema y conexión a internet se establece por medio de cable ethernet durante el desarrollo y pruebas, siendo la conexión WiFi el tipo de conectividad final.

Requisitos funcionales

• RF-001: Adquisición de imágenes mediante cámara USB.
• RF-002: Adquisición de imágenes mediante raspiCam.
• RF-003: Sistema de calibrado de cámaras y proyectores.
• RF-004: Implementación de una interfaz natural de usuario.
• RF-005: Control gestual.
• RF-006: Identificación rápida de documentos.
• RF-007: Sistema de cálculo de homografías.
• RF-008: Realización de videoconferencias.
• RF-009: Soporte para completar formularios.
• RF-010: Guiado para clasificación y archivado de facturas.
• RF-011: Entorno configurable por el usuario.

Requisitos no funcionales

• Rendimiento: El sistema debe funcionar de manera fluida y en tiempo real en dispositivos móviles basados en arquitectura ARM. Sólo existirá un único usuario del sistema simultáneamente y los documentos a tratar también se tratarán de uno en uno.

• Seguridad: A parte de la información que se proporcione al usuario directamente, se mantendrá un log donde se registrará toda la actividad realizada en el sistema. Debido al carácter experimental del proyecto, no se tendrán en cuenta la aplicación, por lo menos en la primera fases de desarrollo, de técnicas criptográficas para ficheros, bases de datos o comunicaciones.

• Fiabilidad: Todo tipo de incidente producido en el sistema debe ser controlado y tratado.

• Disponibilidad: La disponibilidad del sistema debe ser de al menos un 99 % del tiempo que esté en ejecución. En caso de caída del sistema se deben proporcionar mecanismos automáticos para que la maquina y el sistema se reinicien y sean nuevamente operativos sin la necesidad de intervención directa del usuario.

• Mantenibilidad: El desarrollo en un dispositivo tan reciente implica que se liberen con relativa frecuencia bibliotecas o controladores, en los que se corrigen bugs y/o mejoran su rendimiento. Seria recomendable hacer una revisión de los módulos actualizados antes de la instalación del sistema para valorar si es relevante el beneficio que aportan y no comprometer el la estabilidad del sistema.

• Portabilidad: El desarrollo se realizará siguiendo estándares, tecnologías y bibliotecas libres multiplataforma, con el objetivo de que pueda ser utilizado en el mayor número de plataformas posibles tanto software como hardware.

Otros requisitos

La distribución del proyecto se realizará mediante la licencia libre GPLv3, para ello se utilizarán bibliotecas compatibles con dicha licencia.

Estas últimas semanas hemos estado registrando descargas de la aplicación y recibiendo también algo de feedback sobre por dónde les gustaría que continuara el desarrollo de la aplicación y, por este motivo, venimos a darles un premio :).

Les traemos la noticia de la traducción de la aplicación. Tenemos ahora la aplicación traducida al español e inglés, y el idioma se elige automáticamente dependiendo del idioma del sistema. Si no se encuentra, el idioma por defecto es el inglés.

De todas formas el idioma también se puede cambiar en cualquier momento, por lo que es posible elegir el idioma que se prefiera entre nuestra extensa gama.

Vale, no, nuestra variedad de idiomas no es que sea todo lo extensa que nos gustaría, pero ahí entráis vosotros.

<solemne>
AMIGOS DE INTERNET: HACEMOS UN LLAMAMIENTO A TODO AQUEL QUE QUIERA DEDICAR 10 MINUTOS DE SU VIDA A TRADUCIR NUESTRA APLICACIÓN A CUALQUIER IDIOMA A CAMBIO DE RECONOCIMIENTO MUNDIAL Y NUESTRO ETERNO AGRADECIMIENTO Y RESPETO
</solemne>

¿Sabes francés, alemán, italiano, polaco, vasco, gallego o esperanto? Esta es la oportunidad de fama y riqueza más fácil que encontrarás en tu vida. No la desperdicies. Tu madre estará orgullosa de tu trabajo.

No somos publicistas, pero te necesitamos.

Un saludo,
El equipo de MazeSolver

Se añade las vistas correspondientes a crear cadenas (con funcionalidad
hecha) y listar cadenas, esta última lista las cadenas
pero no muestra detalles de esta. Se deja como tarea pendiente.

Commiter:
José María Caballero Alba
caballeroalba@gmail.com
Added:

Modified:
src/main.c
src/table.c

Deleted:

Después de una semana de descanso (y sin post de por medio >_<) para pensar en la siguiente fase de Saving Granny, retomo el trabajo.

Creo que no lo he mencionado en anteriores post, pero estoy participando en el Concurso de Software Libre de este año ->  enlace y tengo como “tope” dos semanas para que me evalúen el proyecto con lo que tenga hecho hasta ese día, por lo que estoy en la cuenta atrás.

En este plazo tengo marcado como objetivos marcados lo siguiente:

– Añadir la longitud de las fases, ya que por el momento la durabilidad del juego no supera ni los tres minutos y eso es muy triste (Realizado al 50%).

– Añadir una tercera fase en la que se tenga que vencer al Lobo y esté en sintonía con la historia de Caperucita.

– Añadir el enemigo Jabalí en la fase del Bosque.

– Añadir por cada nivel una melodía diferente que acompañe al paisaje.

– Añadir el ‘timing’ del juego para saber en qué tiempo se ha finalizado las fases.

– No me va a dar tiempo a dibujar los terrenos y los fondos que es lo que tenía en mente, por lo que tengo que buscar imágenes de uso libre que acompañen mejor a mis personajes (Realizado al 30%).

– La acción de ‘cestazo’ no funciona correctamente por lo que queda corregirlo también.

– Efectos de muerte de todos los personajes (Realizado al 40%).

 

Después de semejante presión por todo lo que tengo que hacer, me despido.

 

Lucra.

One of the advantages of being based on NPM is the so modular that NodeOS is. That's the reason why [you would have not seen too much movement lately](https://github.com/NodeOS/NodeOS/commits/master), but the fact is that in the project dependencies [there has been a huge improvement](https://github.com/piranna/nodeos-mount-filesystems): now thanks to a huge and agressive usage of the new Linux kernel multi-layer OverlayFS (we are needing to use a release candidate version of upcoming Linux 4.0 so [it could be available](http://www.phoronix.com/scan.php?page=news_item&px=Linux-3.20-OverlayFS-Changes)! :-D), NodeOS offer a per-user independent & isolated root filesystem, and in fact now there's no real root partition at all (that's great to simplify the process to create a live ISO or a Raspberry PI disk image!!! :-D), making this not only the first OS to have a similar approach (loosely inspired in [Plan9 ```bind``` union directories](http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs#Union_directories_and_namespaces)) but probably making it one of the most secure OSes, at least from a file access point of view :-) ```Javascript [ 1.072752] EXT4-fs (sda): warning: mounting unchecked fs, running e2fsck is recommended [ 1.076131] EXT4-fs (sda): mounted filesystem without journal. Opts: errors=remount-ro Hello! I'm a user init script :-) Welcome to NodeOS!: username: nodeos Welcome to NodeOS!: password: / # ls [ 'bin', 'dev', 'etc', 'init', 'lib', 'proc', 'share', 'tmp', 'usr' ] / # ls /bin [ 'blessed', 'cat', 'cp', 'ip', 'ln', 'ls', 'man', 'mkdir', 'mv', 'node', 'npm', 'nsh', 'pwd', 'rm', 'sh', 'slap' ] / # node > process.env { HOME: '/', TERM: 'linux', LANG: 'es_ES.UTF-8', vga: '0x318', PATH: '/bin' } / # cat init #!/usr/bin/env node console.log("Hello! I'm a user init script :-)") / # ./init Hello! I'm a user init script :-) / # ls usr/bin/ [ 'env' ] / # cd usr/bin/ /usr/bin # ls [ 'env' ] /usr/bin # cd / # ls share/ [ 'man' ] / # ls share/man/ [ 'man1', 'man3', 'man5', 'man7' ] / # ``` Pretty, isn't it? :-D The way it works is fairly simple and it's inspired by [this IBM article about mount namespaces](http://www.ibm.com/developerworks/linux/library/l-mount-namespaces/index.html) (that definitely are the next step where to move to improve all this OverlayFS big hack... if needed :-P): ```initramfs``` not only mount the users filesystem, but also means as a basis for the "general root filesystem" used as basis later for all the users (since by design since Linux 2.6.0 it will be always loaded in memory, so we re-use it). This is done by removing the unneeded modules and executables used to start and mount the filesystem so earn some RAM, but also to remove some possible security holes on that modules, so we keep only with an initram only with the Node.js executable and its needed dynamic libraries, and since they will be used everywhere this makes also the system faster. The users partition need to be mounted somewhere, so I'm doing it on the ```/tmp``` folder on the initramfs, so this way I can later mount over it an in-ram ```tmpfs``` filesystem for each user, hidding the raw users partition from being accesible by anybody and also preventing to write temporal data on the real hard disks. After that, we use this initram as a read-only "carbon copy" where to mount over each of the users home (also root) and later using [chroot](https://github.com/melor/node-posix#posixchrootpath) to give to each users an unique root filesystem isolated from the others. This is only needed to exec the per-user ```/init``` executable and when login in the system, so it's easy to have the access controlled, and all their subsequent process will be running inside their corresponding user ```chroot``` jail. There's a minor exception regarding to the ```root``` user: if it's available in the users filesystem (that's not mandatory at all), since [logon](https://github.com/piranna/logon) needs to access to the users home directory to read their login configuration, it is mounted first and later the users partition mount point is moved to a ```home``` folder inside its own filesystem, so it can access to them without modifying the carbon-copy initram root filesystem. After that, it is configured exactly the same way as any other regular user. This also has the advantage to give to the users a simple filesystem hierarchy were to work, since their "home" is in fact the root of their own filesystem hierarchy, so they can easily install packages globally without requiring special permissions and will not need to configure anything since they will naturally be installed in their home directory by deafult. There are some improvements that need to be done, obviously. First of all, the "demo" users filesystem that's automatically generated on the build process needs to give diferent ```uid```s and ```gid```s to each one of the users folders since this is used as basis for the security scheme (maybe a patch for [genext2fs](http://genext2fs.sourceforge.net/)?), but since it's only for demo purposses this is not so a problem (but definitely we need to add some some info about how to create and config a custom, real one...). Other notable problem is regarding to the ```/dev``` and ```/proc``` filesystems, since they are shown on each user filesystem as empty folder. In the case of ```/dev```, the best solution is [to implement a filesystem that only show the device entries that are accesible by the user and owned by him or not currently used](https://github.com/NodeOS/NodeOS/issues/95), so they could be exclusively accessed. This could be easily done by using [fusejs](http://c4milo.github.io/fusejs/), since the NodeOS Linux kernel is already being compiled with support both for [FUSE](http://fuse.sourceforge.net/) and [CUSE](http://lwn.net/Articles/308445/). Regarding to ```/proc```, something similar could be done, but seems its configurable at mount how accesible it is, so by using shared mountpoints I could have it replicated on all the users root filesystem. On the other hand, I would like that [Node.js remove its dependency on it](https://github.com/joyent/node/issues/10426) so it could be removed at all from NodeOS, since it's obviously a posible entry point for security issues since you hace access to all the kernel internal structures... :-/ Next step, update the project documentation, some love for Docker (I have been focusing on QEmu since by default Docker needs ```sudo```, so it makes more dificult to build the images) and generate (nightly) live ISOs :-) It will be funny to see NodeOS running on real hardware... :-D P.D.: oh, and [we have now 2200 stargazers](https://github.com/NodeOS/NodeOS/stargazers) and counting!!! :-D

Cuando se listan las tablas, al seleccionar una de ellas
se pasará a la siguiente vista que contiene los detalles de tabla
así como opciones para la edición de la tabla.

Commiter:
José María Caballero Alba
caballeroalba@gmail.com
Added:

Modified:
src/main.c
src/screen_work_flow.h

Deleted:

¡Buenas a todos!

Ya tenemos fecha para la fase de calificación de los proyectos. Hemos tenido que dar prioridad a la app por encima del resto de cosas en las que trabajamos, porque queda poco más de una semana para que comience la evaluación.

Cada día que pasa tenemos implementadas nuevas funcionalidades, y aunque tenemos la sensación de estar con el agua al cuello, esperamos tenerla terminada para la fecha límite. Lo que más trabajo nos está costando es, aunque parezca mentira, el tema diseño (en XML). Queremos que la aplicación tenga algo de dinamismo, pero encontrar el punto medio entre legibilidad y atractivo está suponiendo un quebradero de cabeza para ambos.

De momento hemos conseguido implementar Layouts con esquinas redondeadas y estamos jugando con el alpha del Linear que contiene el texto para que se intuya más o menos el fondo. ¿Se nota que nos gusta más la parte que tiene que ver con lógica que la de diseño? Esperamos que en el resultado final no se aprecie tanto que nos gusta mucho más Java que XML.

Con un prototipo de View ya diseñada, vamos a pasar al menú principal, que ya tiene implementada una bienvenida personalizada. Hemos utilizado SharedPreferences para guardar booleanas de progresos y el nombre del usuario, porque con el tiempo de que disponemos es imposible enfocarlo de otra forma. La parte negativa de este método es que de momento no tenemos previsto poder alojar dos usuarios en un mismo terminal, y por supuesto, al desinstalar la aplicación se pierden todos los progresos que se hayan logrado.

De cualquier forma, enfrentarnos a este reto nos está ayudando a aprender nuevos conceptos sobre Android (recordad: no somos expertos ni mucho menos) y de paso, estamos refrescando algunos que ya teníamos casi olvidados.

Como ya sabéis, podéis consultar nuestros progresos y estar al tanto de cómo evoluciona el proyecto en tiempo real, visitando nuestro repo en GitHub.

¡Saludos!

Se añade la funcionalidad de listar las tablas creadas para
que cuando se pulse en alguna de ellas se obtengan los detalles
necesario para su uso.

Esto es:
~Añadir cadenas (sin implementación)
~Listar cadenas (sin implementación)

Commiter:
José María Caballero Alba
caballeroalba@gmail.com
Added:

Modified:
src/main.c
src/screen_work_flow.h

Deleted: