Soporte de PDIs en LliureX

Uno de los principales problemas que nos encontramos al usar LliureX para la tarea docente es la falta de soporte de PDIs (Pizarras Digitales Interactivas). Además nos encontramos con que, actualmente, es el "regalo" preferido por las editoriales para los centros educativos. Así pues nos estamos encontrando con más y más centros que disponen de diferentes marcas y modelos de PDIs que no funcionan o al menos no todo lo bien que deberían en LliureX (y quien dice LliureX dice Ubuntu o GNU/Linux en general).

Es sabido que el soporte de hardware para Linux llega siempre más tarde que para "el sistema operativo más popular". Esto es así por un motivo, el cual es menos conocido en según qué círculos. Se trata de que, si eres un fabricante de hardware, quieres que la experiencia del usuario de tu producto sea lo más fácil posible (enchufar y listo). Y los desarrolladores que se encargan de crear el "driver" (el software que permite a un hardware específico interactuar con el sistema operativo) dedican su tiempo a hacerlo funcionar en el "sistema operativo popular" olvidándose de que hay otras alternativas que van poco a poco asentándose. Así, la imagen errónea que queda en la mente de muchos usuarios es que LliureX/Ubuntu/Linux es un sistema anticuado y poco compatible.

Para colmo, cuando el desarrollador de linux trata de hacer sus propios drivers surge un problema que la mayoría desconoce, incluso los usuarios de Linux: El hardware no se ciñe a los estándares. Aqui en Lliurex hemos visto de todo, desde dispositivos que violan impunemente el estándar USB, otros que simplemente lo cumplen a medias y como colofón, los que lo cumplen tajantemente pero aprovechan las puertas traseras que Microsoft dejo abiertas en el estándar para llevar siempre la ventaja. Esto se suele resolver en la mayoría de los casos con ingeniería inversa.

En Lliurex estamos trabajando en un driver para dar soporte a tantos dispositivos como podamos, pero, a diferencia de un driver normal, este funciona en el espacio de usuario. Vamos, que es un programa normal y corriente, con las ventajas y desventajas frente a un driver clásico. Aunque este debate se puede dilatar muchas páginas, para hacerlo mas rápido simplemente comentar que este driver nos permite desarrollar a mas velocidad y nos hace prácticamente independientes del kernel.

Afortunadamente, los fabricantes están mejorando sus dispositivos, y las últimas unidades que hemos tenido oportunidad de probar cumplen bien con los estándares USB, con lo cual son detectados automáticamente por LliureX.

Actualmente tenemos una serie de pizarras digitales y tabletas de dibujo funcionando, pero el driver esta todavía en fase de diseño/desarrollo temprano. Actualizaremos la wiki cuando tengamos una lista definitiva, cuando el driver este en una fase mas beta. Se espera lanzar con la versión de Lliurex 12.06 Nemo. Os mantendremos informados!

El misterio de Marty

Supongo que todo el que haya probado ya la última versión de Lliurex, se habrá preguntado que significa y de donde viene eso de Marty. Todas las versiones de Lliurex tienen una numeración y un nombre en clave; 9.09 indi, 10.09 leia, 11.09 marty... La numeración indica el año y mes de publicación de la versión estable. El nombre en clave, es un nombre que se decide internamente tomando como punto de partida la letra del abecedario correspondiente. Marty McFly es el personaje principal de una trilogía cinematográfica de los años 80. Los desarrolladores de Lliurex crecimos con las aventuras en el tiempo de este personaje y decidimos hacerle un guiño. Colores, tipografías, decoración, Lliurex Marty nos invita a viajar en el tiempo, hasta los años 80.

Mientras tanto, el equipo de Lliurex ya esta manos a la obra preparando la próxima versión denominada Nemo. Parece fácil, ¿No? Habrá que esperar un poco para conocer que nos deparará Lliurex Nemo.

El truco del hombre del tiempo

Tras mas de un mes atareado hoy voy a desvelar la "magia" que permite al hombre del tiempo, entre otros, para superponerse a un fondo virtual.

Básicamente el objetivo consiste en reemplazar unas zonas de la imagen original, y sustituirlas por fragmentos de una segunda imagen. La técnica mas comun es el chroma key.

Esta es la famosa técnica en la que los actores realizan su papel delante de paredes verdes "fosfi" y azules. Seguro que todos hemos visto esto en el "como se hizo" de algún DVD. Después de tomarse la imagen original, se procesa pixel a pixel, substituyendo el color que hemos puesto de fondo por nuestra imagen virtual, donde Anakin y ObiWan se dan leches sin parar sobre magma incandescente.

Así de primeras puede parecer sencillo, pero en la práctica surgen dificultades. Paso a explicar el algoritmo donde se apreciará con mas facilidad donde reside el problemilla. Recorremos el fotograma en cuestión pixel a pixel, si el pixel tiene el valor RGB que hemos configurado como fondo, substituimos el pixel en cuestión por su correspondiente en la imagen virtual. Fácil no? Esto con imagenes sintéticas funciona perfectamente, en la práctica no acaba de ir tan bien sin unos ajustes. Porque? Bien, porque el fondo nunca es homogéneo en un 100%, las cámaras arrastran también mayores o menores desviaciones en el color y por buena que sea la iluminación del plató, siempre habrán pequeñas sombras o brillos. Cuando el algoritmo tira a procesar la imagen, se encuentra con colores parecidos, pero no iguales dando como resultado un fracaso !

Que no cunda el pánico ! Solo sera necesario modificar el algoritmo para que admita colores parecidos. Imaginar los 3 ejes cartesianos, el centro es negro total (0,0,0) sobre un eje va creciendo el color rojo, de igual manera con los otros dos, verde y azul. De esta manera, cada color rgb se interpreta como un punto en el espacio cartesiano (x,y,z). Por tanto, cuanto menor sea la distancia entre dos colores, mayor su semejanza.

Tomemos una distancia, que la llamaremos Delta y dos colores, el del pixel de entrada P, y el de referencia para contrastar el chroma C. El valor de Delta se ajusta de manera empírica (en castellano: probando hasta que quede bien) ya que depende de las condiciones que tengamos a la hora de capturar la imagen.

//calculamos el vector entre los dos puntos
Vr = Cr - Pr
Vg = Cg - Pg
Vb = Cb - Pb

//modulo del vector
dist = sqrt(Vr*Vr + Vg*Vg + Vb*Vb)

//son colores parecidos ?
if(dist < Delta)
{
putPixel (..... )
}



Ajustar la distancia es primordial para que chroma de buenos resultados, valores muy bajos, provocaran que parte del fondo no consiga ser discriminado. Sin embargo valores muy altos tomarían como fondo demasiados colores, desintegrando el aspecto de la imagen. Por poner un ejemplo, es como si el hombre del tiempo, fuera deshaciendose conforme el Delta aumenta, viéndose solo el mapa metereológico.

Tras haber entendido todo esto, se intuye el porqué se emplean colores tan llamativos como fondo para el chroma key. Por un lado se debe de usar un color que no vaya a estar presente en los actores. Por otra parte, estos colores tan exagerados permiten aumentar el Delta reduciendo el riesgo de "amputarle" algún miembro a nuestro presentador :-)

Por supuesto el algoritmo aquí explicado es perfectamente mejorable, los chicos de George Lucas usan chroma keys bastante mas sofisticados, que permiten tratar transparencias y reflejos. Si alguien le da por jugar con la webcam, ya aviso que con webcams malas (si Logitech, estoy hablando contigo) los resultados son algo decepcionantes.

Una cita con la naturaleza

Como ya adelantaba la semana pasada, he aprovechado la festividad del 9 de Octubre para hacer una escapada mtb por tierras Valencianas. La escapada ha sido un auténtico éxito; buen tiempo, hermosos paisajes, ruta divertida...

La ruta está bastante bien definida, puesto que transcurre en su mayoría por carriles bici. Además, si no dispones de vehículo o manera de transportar las bicis en él, no es problema, ya que esta ruta tiene la especial peculiaridad de poder valerse del transporte público tanto en la ida como en su regreso.

El recorrido nace donde finaliza la linea de metro con destino a Lliria. Desde este histórico pueblo pedaleamos dirección Olocau, valiéndonos de un magnifico carril bici que une sendos pueblos. Una vez visitado Olocau, ya por terrenos algo mas abruptos, realizamos un divertido descenso hasta la localidad de Bétera.

Aunque no recomiendo la ruta para principiantes, puesto que tiene dos ascensos pronunciados, sus casi 35 km si son altamente recomendables para cualquier amateur de la bici. Eso si, de montaña ! no importa si rígidas o dobles, puesto que un tramo del trayecto (el mas divertido) no esta asfaltado.

Ciclistas que te devuelven un cordial buenos dias, hermosas vistas y hermosos árboles, y siempre relativamente cerca de núcleos habitados por si tenemos un susto. Que maravilla ! :D

Por cierto quiero aprovechar para saludar al chaval con la topbike del carrefour que en un intento de impresionarnos con sus acrobacias ha reventado la cámara trasera con su característico Bloom! Ha sido la nota cómica del día :_D

Os dejo un link con toda la información necesaria para llevar acabo la excursión. Aunque los datos no son muy precisos, con una brújula y preguntando a los paisanos se completan los detalles.

Aquí va el link: LLíria-Olocau-Bétera (33,8 Km)

Y aquí unas cuantas fotos:

Para los ciclistas, el cielo no esta arriba, mas bien el infierno.



Asi se ve el mundo desde la Calderona.


Alguien estaba muy nervioso y se lió a tiros :S

Las bicis, bautizadas como "Agonia" y "Sufrimiento" en el vagón de regreso a casa. Les vendrá bien una buena lavada y un engrase....vaya, igual que a mi :D

Fallo de diseño

Vaya ! Ando algo atascado con el scalextric digital casero. La etapa lógica se ha comportado bien, pero en la etapa de potencia es donde no consigo pasar. Tras un medio-éxito con un L298, decidí simplificar el esquema usando transistores en su lugar. Me decanté por un TIP-41, sinceramente sin tener las ideas demasiado claras. Monté un pequeño prototipo y no parecía hacer mención alguna. Polímetro en mano me percaté que el voltaje que proporcionaba la etapa lógica era de no mas de 4.8 V, voltaje que creo que es insuficiente para que el tip-41 abra entre colector y emisor. Bueno...de los errores se aprende, ahora manos a la obra en busca de una solución.

Mientras tanto, dejo colgada un esquema de lo que es la etapa lógica para una sola pista (extenderlo a dos es replicar parte del circuito, no tiene demasiado misterio).

Por supuesto se admiten críticas ! :D

Aprovecho para adelantar que en este primer puente de octubre voy a marcarme una pequeña ruta BTT por tierras Valencianas, y de paso igual hago un pequeño reportaje fotográfico de la sierra Calderona ^_^

Que tengáis buen finde !

Contacto en 3,2,1.... BANG !!!

Para que luego digan que la electrónica es aburrida. Cual cerdo en barro me he reido hoy al ver explotar un pequeño integrado. Si es que... los datasheets no estan llenos de cifras para impresionar a los novatos, esas cifras estan para algo. Y cuando no respetas o no te da al gana respetarlas pasa lo que debe de pasar. En mi caso una pequeñita explosión.

Estabamos usando un L293 a modo de etapa de potencia, faltos de un transistor que encajara mejor ahi. Y se nos ha ido la mano con la corriente, supongo que fruto de las prisas y la ignorancia dando como resultado un pequeño cráter en la superficie del integrado. Imagen que obviamente adjunto con orgullo :D



Según mi colega, una burbuja del aire que se ha dilatado debido a las altas temperaturas ha sido la causante de tal explosión. Y yo los habia visto medio derretirse, pero esto... ha sido gracioso !!! Y tu?? Que has hecho explotar en esta vida ?? :_D

Cacharreando con PyGame

Como echo de menos mi adolescencia, cuando tenía mas horas para programar juegos. Antaño (1999) surgió un lenguaje de programación llamado DIV Games Studio que causó furor entre la comunidad hispana de programadores. Como toda idea revolucionaria, tenía sus seguidores y sus detractores, pero el caso es que se llegó a editar una revista sobre DIV, y noche tras noche nos reuníamos cerca del centenar de usuarios en el irc-hispano para hablar sobre la programación de videojuegos. Pero la empresa que sacó DIV al mercado cerró al poco de sacar su segunda versión, y esto sentenció la vida de este lenguaje. La gente lejos de quedarse de brazos cruzados, trató de mantener al dia este lenguaje y surgieron varios proyectos con su versión libre de DIV (Fenix y eDIV). A varios colaboradores de sendos proyectos he tenido el gusto de charlar con ellos y aprovecho para mandarles un saludo :)

Aunque proyectos como Fenix han conseguido mantener el lenguaje DIV hasta nuestros dias, su poca aceptación fue desperdigando a la gente hacia otras alternativas. Yo encontré la mia en la combinación de C con SDL, pero quedaba lejos de ser tan fácil como DIV, y los lenguajes basados en BASIC siempre han estado ligados a licencias no libres y a una baja o nula portabilidad.

En python he encontrado la manera mas productiva de desarrollar juegos caseros y seguir disfrutando de este mundo fruto de la combinación de técnica y arte.

Vamos a comentar un ejemplo sencillito, que puede servir a su vez como un esqueleto básico con el que hacer unos primeros pinitos.

Empezaremos incluyendo la/s librerias que nos hacen falta, que por ahora será exclusivamente pygame:

import pygame

Tecnicismos a un lado, esto es algo similar al import de java o al include de C. Ahora veamos como ponemos la maquinaria a rodar:

def main():
 print "Python game tutorial 01"

 pygame.init()

 screen=pygame.display.set_mode( (800,600),pygame.DOUBLEBUF)

Para los nuevos en python, respetar las tabulaciones ! es la forma que tiene este lenguaje para delimitar los bloques de código. Aunque al principio parece algo bizarro, cuando te acostumbras te ayuda a mantener el código algo mas elegante. Bien, pasemos a comentar este trozo. Las tres primeras lineas no tienen mucho que decir, se define la funcion main, se imprime por consola una cadena de texto y se inicializa pygame. Es necesario llamar a pygame.init() antes de cualquier otra función de pygame. Analicemos ahora la cuarta instrucción: pygame.display.set_mode establece el modo gráfico y si lo consigue nos devuelve el buffer para dibujar en el. En el ejemplo se desea una resolución de 800 x 600 pixeles y con la opción de doble buffer (para animaciones mas suaves). Si no se especifica lo contrario, será en modo ventana. La pantalla completa suele dar algun problema que otro, no recomiendo usarla hasta no tener algo estable.

Una vez en marcha pygame y el modo gráfico establecido, es un buen momento para poner a punto las variables de nuestro juego:

 default_fnt=pygame.font.Font(None,24)

 quit_request=False
 x=0
 y=0
 dx=1
 dy=1

De aquí poco hay que comentar, se genera una fuente de tamaño 24 y se inicializan unas cuantas variables que mas tarde se usarán. Para los mas culebrines, es fácil ver que no hemos declarado las variables, se declaran en el mismo momento que se les asigna por primera vez un valor, a la par que toman el tipo del tipo de dato que se les asigna (Integer, bool, string....) que comodidad no !??? :D

Teniendolo todo preparado, es momento ahora de entrar en un bucle y comenzar la animación. En la primera parte del bucle, vamos a leer la cola de eventos de pygame buscando aquellos eventos que nos interesen, como es el caso de las pulsaciones de teclado. Esto quedaría asi:

while not quit_request:
  for event in pygame.event.get():
   if event.type == pygame.QUIT:
    quit_request=True
   if event.type == pygame.KEYDOWN:
    if event.key==pygame.K_ESCAPE:
     quit_request=True

Tenemos un while, cuyo comportamiento es idéntico al de otros lenguajes, sin misterio alguno, iteraremos mientras se de la condición. La que viene a continuación es un bucle For algo mas propio de lenguajes mas modernos como el caso de C# o java. La función pygame.event.get() nos devuelve una lista con todos los eventos pendientes de ser procesados y la variable event se emplea como variable iteradora. Ahora mismo hacemos mas bien poco, tan solo damos la condición de salir del bucle principal si detectamos que se ha hecho click en cerrar la ventana o se ha pulsado la tecla ESCAPE.

Bueno, de el siguiente código poco hay que comentar, nos valdrá para darle algo de movimiento al programa.

  x=x+dx
  y=y+dy
  if x>799:
   dx=-1
  if x<0:
   dx=1

  if y>599: 
   dy=-1
  if y<0:
   dy=1

Hemos leido los eventos del usuario, actualizamos las variables que le dan la lógica a nuestro juego... pero como dibujamos cosas? Hoy solo dibujaremos algo de texto en pantalla.

  screen.fill((0,0,0))  

  text_srf=default_fnt.render("Hello World",False,(255,0,0))

  screen.blit(text_srf,(x,y))
  pygame.display.flip() 

Como se vio anteriormente, en screen se guarda la referencia a nuestro buffer gráfico. Se suele emplear el nombre de Surface o Superficie a las imágenes que residen en la memoria RAM. Como no sabemos en que estado está el buffer, lo primero que debemos hacer es limpiarlo, llenandolo ( screen.fill() ) de otro color, como en este caso, que se emplea un negro total para limpiar el buffer. En la segunda linea se genera una superficie con un texto dibujado en su interior, no es dificil ver que se trata de la cadena "Hello World" ^_^

Como si de pegatinas se tratara, tenemos que ir montando el buffer "pegando" en el las imágenes que formaran la animación, personajes, fondo, textos... A estos pegados se les llama blits. Ahora mismo no nos vamos a lucir tanto, y tan solo pegaremos en la pantalla esa imagen con el texto que se ha generado anteriormente, indicando además, las coordenadas donde se debe pegar, siendo las variables x e y en este caso.

Cuando hemos acabado de componer la escena, pygame.display.flip() manda el buffer al monitor y se nos da otro buffer para que en la siguiente iteración del bucle, dibujemos otra vez la escena.

Con todo esto, solo nos queda añadir un par de lineas para completar el ejemplo básico de pygame:

if __name__=="__main__":
 main()

Esto no tiene mucho que ver con pygame, es algo de Python. De aquí simplemente entender que cuando se lance el programa se ejecutará la función main anteriormente definida.

Pues esto es python y pygame ! A mi parecer, es tremendamente fácil aunque nunca hay nada exento de polémica. No hay que olvidarse de que no deja de ser un lenguaje de programación imperativo y que como tal, es necesario tener experiencia programando. Querer hacer juegos sin programar normalmente acaba por no dar muy buenos resultados.

Tengo que hacer un par de proyectillos con pygame (Entre ellos el scalextric pseudo digital) así que aprobecharé para colgar mas tutoriales sobre pygame :)