McClane y sus amigos

Mensajes SMS gratis

2008-01-30T05:56:00.000-08:00

LA IDEA

Mientras las operadoras sigan sin cobrar por intento de conexión (es decir, cuando llamas y el otro no contesta o comunica) existe una manera de enviar datos de un teléfono a otro sin pagar un duro.

En realidad es algo parecido a lo de las llamadas perdidas: cuando alguien te hace una es para confirmar que le ha llegado tu mensaje o para decir que se acuerda de tí (menuda mariconada...). En cualquier caso la perdida es gratis (ni tú ni el que recibe la perdida habéis pagado por hacerla) y ha servido para transmitir información.

Pero la cosa vamás allá. Muchas veces alguien te envía un SMS y te dice: "Hemos quedado a las 8 en el bar del Miguel, si puedes venir haz una perdida corta, y si no, haz una perdida larga". O en vez de una corta y una larga te dicen que hagas una o dos perdidas seguidas.

Lo curioso de las llamadas perdidas es que, por lo que me ha parecido a mi, sólo se hacen en España. A gente que he conocido de Francia, Italia, Alemania, Noruega y EEUU no se les había ocurrido nunca la utilidad de una "perdida". Haced la prueba con los Erasmus: cuando llegan aquí no lo comprenden (aunque no tardan mucho en adaptarse al modo Español de ver las cosas: si puedes hacerlo gratis, no pagues, aunque sea peor, jeje...)

Bueno... el caso es que si nos pusiésemos en modo "ultra-rata", podríamos sacrificar conveniencia y comodidad a cambio de poder enviar más información gratis por medio de "perdidas". Por ejemplo, podríamos elegir 8 mensajes comunes que solemos enviar por SMS, como los siguientes:

Si
No
Quedamos hoy a las 17:00 donde siempre
Quedamos hoy a las 20:00 donde siempre
Quedamos hoy a las 22:00 donde siempre
Ya te llamo yo luego
Te estoy esperando, date prisa
Ya voy !!

Entonces transmitir uno de esos 8 mensajes usando tres bits: "Si" sería "000", "No" sería "001", ..., y finalmente "Ya voy !!" sería "111"

Ahora acordamos que el "0" es una perdida corta y el "1" una perdida larga.

Ya lo tenemos! Para decirle a alguien que "quedamos hoy a las 17:00 donde siempre" sólo tengo que hacerle tres perdidas: una corta, seguida de una larga y finalmente otra corta.

Claro que habría que acordar una cosa más para que funcionase el invento: Nadie debe coger el teléfono hasta que esté seguro de que se trata de una llamada de verdad (y no del inicio de una secuencia de tres perdidas). Esto es fácil: basta con esperar hasta el tercer o cuarto toque, y luego coger el teléfono. (de hecho esto ya se hace ahora, por si se tratase de una perdida de las de toda la vida).

Bueno... ya veis por donde van los tiros, ¿no?

Si en vez de 3 bits utilizásemos 5, podríamos transmitir hasta 32 mensajes distintos. Pero ahora en vez de 32 mensajes lo que vamos a hacer es transmitir las 27 letras del abecedario (incluimos la "ñ" pero dejamos fuera la "ll") más los signos de "?", "!", " " (espacio) y "." Con eso tenemos 31 caracteres. El 32 lo reservamos para indicar que ha terminado la transmisión del mensaje.

Entonces ya lo tenemos todo: Si queremos enviar "Hola Luis" primero hacemos 5 perdidas (largas y cortas, la secuencia que corresponda a la "H") seguida de otras 5 perdidas (para la "o"), etc... hasta llegar a la "s". Por último enviamos el símbolo de "fin de transmisión", que es el número 32, que se corresponde con 5 perdidas largas.

IMPLEMENTACIÓN

Se trata de hacer dos aplicaciones para teléfonos móviles:

Una que dada un mensaje y un número de teléfono empiece a generar perdidas que transmitan el contenido del mensaje.
Otra que en cuanto detecte que se están recibiendo perdidas de un mismo número, vaya traduciendo la secuencia en un mensaje de texto

La aplicación debería tener acceso a la funcionalidad de "hacer y recibir" llamadas... supongo que tanto Java para móviles, Symbian o Android tienen permisos ó, como mucho, habría que proporcionárselos explicitamente de alguna manera a la hora de instalar la aplicación... pero no sería mayor problema.

La aplicación receptora debería interceptar cualquier intento de llamada entrante y sólo una vez confirmado que no se trata de una perdida, activar el speaker del teléfono para que tú atiendas la llamada. Esto es más que nada para que no te esté sonando el móvil mientras recibes el mensaje (el proceso puede durar varios minutos!)

PROBLEMAS

Para empezar, supongamos que, en el peor de los casos, hacer una perdida tarda unos 5 segundos en completarse (entre que has marcado el último número y suena el "TUUUUUUU" que confirma que el otro lado está sonando)
Las perdidas cortas serían entonces de 5 segundos, y las largas pongamos que de 7.

Cojamos el peor caso: 7 segundos. Los SMS actuales dejan enviar hasta 160 caracteres. Es decir, que para tener la misma funcionalidad que un SMS, en el peor caso necesitamos 5*7*160 = 5600 segundos, que es una hora y media más o menos.

Pero eso no es lo peor, estamos estableciendo 5*160 = 800 llamadas de extremo a extremo, y esto consume muchísima batería (de hecho, seguramente un móvil de ahora no sería capaz)... además, si enviamos un par de estos mensajes a la semana, la operadora podría terminar por sospechar y acabar cobrándo los intentos de establecimiento (como juraría que ya se hace en EEUU). Aunque no se yo como se tomaría eso la gente aquí en España :)

Se podría, por ejemplo comprimir el texto a enviar, de manera que utilizaríamos menos llamadas perdidas... pero una solución mejor todavía sería si, además, utilizásemos un sistema en base 3 ó 4 ó más, en vez de en base 2. Es decir, si en vez de poder transmitir "1" ó "0" en cada perdida (que se corresponden con "perdida larga" ó "perdida corta") pudiésemos transmitir, por ejemplo, "00", "01", "10", "11" (que se corresponderían con "perdida muy corta", "perdida corta", "perdida larga" y "perdida muy larga".

Si hiciésemos esto último, ya no necesitamos cinco perdidas para transmitir una letra, sino sólo 3, y además en esas tres ya estaríamos transmitiendo, de paso, parte de la siguiente letra.

De hecho, para mensajes de 160 caracteres (160*5 = 800 bits) ya sólo necesitamos 800 / 2 = 400 llamadas.

Pero siguen siendo muchas. Un número razonable que no hiciese despertar las sospechas sería, como mucho, 10 llamadas por cada mensaje de 160 caracteres.

Para transmitir 600 bits en 10 símbolos (llamadas) necesitamos que cada símbolo (llamada) transporte 60 bits. Es decir, necesitamos diferenciar entre 2^60 tipos de llamadas perdidas "cortas", "menos cortas", ..., "largas", etc...

2^60 es mucha tralla... En el mejor de los casos me imagino (aunque esto habría que estudiarlo) que la mayor resolución que puede obtenerse al establecer una llamada con otro extremo es de 1 milisegundo (siendo muy optimista!). Con esto estoy diciendo que desde que a mi (que soy quien llama) me suena el "TUUUUUU" de que el otro extremo está recibiendo mi llamada hasta que le suena el "RIIIING" al otro extremo (que es quien recibe la llamada) hay un desfase de +/-1 milisegundo... (ya digo que seguramente sea de muuucho más, del orden de un segundo... pero sigamos soñando que si no se nos va el invento al traste).

Bueno... pues suponiendo que distinguimos milisegundos y que una llamada perdida puede durar, como mucho, dos segundos (antes de decidir que no es una perdida, sino una llamada normal), entonces con una misma llamada podemos transmitir 2000 estados posibles. Pongamos que 2048 para que el resto de operaciones de exacto.

2048 estados se corresponden con 11 bits. Es decir, 11 bits por llamada.

Para transmitir 800 bits que hay en un mensaje de 160 caracteres de 5 bits necesitamos 800 / 11 = 72 llamadas.

Siguen siendo muchas !!!

Pero si comprimimos esos 800 bits podemos reducir su tamaña hasta por 4 y pico (en el mejor de los casos, tal y como se explica aqui) y entonces si que nos quedamos en unas 18 llamadas !!!! Por tanto sería posible.

Subtitulador automático

2007-12-20T11:52:00.000-08:00

Situación:

McClane acaba de conseguir el último capítulo de Perdidos y arde en deseos de verlo cuanto antes. Como lo ha bajado de un foro cutrero poco profesional, resulta que el capítulo está en versión original. Resulta paradójico que McClane domine todos los lenguajes de programación pero sólo hable castellano, y eso a pesar de tener un nombre tan inglés.
¿Qué hará McClane en esta peliaguda situación? Muy sencillo, ir al menú Reproducir -> Subtítulos -> Activar subtítulos automáticos. Al cabo de un instante los subtítulos empiezan a aparecer pero... ¡horror! los subtítulos salen también en inglés.

- Tranquilo McClane,--piensa con calma-- sólo tengo que configurar los subtítulos.

Así pues, McClane vuelve al menú Reproducir -> Subtítulos -> Configuración... y una vez allí, selecciona Español como idioma preferido. Un instante después los subtítulos cambian de idioma y McClane ya puede ponerse cómodo para disfrutar de su serie preferida.

Y todo gratis con sólo hacer unos cuantos clicks.

LA IDEA

El relato anterior no tiene nada de increíble.

Hace años que existe el reconocimiento del habla (me recuerdo hará unos diez años en mi pentium 600 leyendo páginas del Quijote para "entrenar" a mi ordenador) aunque sus aplicaciones sean escasas a día de hoy, pero reconoced que alguna vez le habéis dicho información a una máquina teleoperadora.
La teoría básica del reconocimiento no es muy compleja, lo malo es que los sistemas actuales son propietarios y desarrollar uno desde cero es costosísimo, aunque con algún buen trato se podría intentar usar un sistema ya hecho. También se puede usar un sistema libre, aunque va a ser mucho más malo. De todas formas, aunque haya un porcentaje de palabras no reconocidas, tampoco pasa nada, yo he bajado subtítulos de calidades lamentables y estaban hechos por humanos (o quizás por monos esclavos).

El otro tema es la traducción automática. Aquí la cosa se complica. Muchos hemos usado el traductor de Google con pésimos resultados. Y eso que Google está apostando muy fuerte por la traducción, con la intención de que en un futuro se pueda buscar información en TODA la red sin importar en qué idioma fue creada. Pero bueno, una cosa es que la traducción sea mala y otra que no se pueda hacer, y poder se puede.

EL PROCEDIMIENTO

Ahora que sabemos que todo lo fundamental para nuestra idea ya existe, sólo nos queda desarrollar el software de aplicación, que ya aviso no tiene nada de misterioso. Hay programas comerciales que hacen ambas cosas por separado. Algún día que tenga tiempo, haré los primeros ensayos del subtitulador paso a paso, aunque la idea es hacerlo todo autómatico en un filtro del reproductor.

Del archivo de vídeo se extrae el audio mientras el vídeo se guarda en memoria. Se procesa el audio con el subsistema de reconocimiento de voz. En caso de que no corresponda con el idioma a mostrar se traduce. Se empieza a mostrar el vídeo que tenemos en memoria con el audio procesado y se incorporan los subtítulos.
Tachán!

Notas Finales

Antes de comenzar la reproducción hay que esperar que se procese una cierta cantidad de información.
Una cosa que merece la pena destacar es que el tiempo necesario para el proceso no depende de la entrada, vamos, que da igual qué vídeo tengas, siempre tardará lo mismo, con lo que no se crean parones a mitad de la reproducción.
Como he dicho, el reconocimiento de voz no es sencillo, pero a las malas se puede extraer el vídeo en un archivo y meterlo como entrada en algún programa ya existente. Lo malo es que tardaría más en comenzar el vídeo.
La traducción se puede hacer también con un programa externo ya existente, aunque la calidad seguramente será mala.
El sistema también sirve para crear archivos de subtítulos en varios idiomas. Aunque luego haya que corregirlos, el trabajo pesado ya lo hace él solo.

El navegador GPS de realidad aumentada para telefonos móviles

2007-12-19T12:03:00.000-08:00

Primera entrada !!! Pero paso de presentarme (y espero que el resto haga lo mismo). Vamos al tema.

LA IDEA:
Un navegador de realidad aumentada para teléfonos móviles.
Funciona de la siguiente manera:

Tú le dices al teléfono donde quieres ir.
El teléfono se conecta a google maps, y le pasa la posición actual (del GPS) y el destino deseado.
Google maps nos devuelve una ruta.
Modelamos esa ruta como una serie de flechas en un universo 3D que indican el camino.
Ahora necesitamos más información del móvil: posición (ya la sabemos, del GPS), pero también el resto de parámetros necesarios para conocer el "punto de vista" exacto (en el universo 3D) que se obtiene al mirar por la cámara integrada. Es decir: inclinación sobre ejes X, e Y y rotación... y a lo mejor algún otro de la cámara.
Ya tenemos una cámara en una posición de un universo 3D lleno de flechas. Lo único que tenemos que hacer es superponer las flechas sobre la imagen real que se obtiene de la cámara.
A medida que grabamos con la cámara del móvil y nos movemos, vamos actualizando la posición y resto de parámetros de la cámara.
Lo que ve el usuario por la cámara son flechas "virtuales" superpuestas a la realidad que le indican el camino a seguir hasta su destino.

LOS PROBLEMAS:
No todo es perfecto, ya que...

Necesitamos teléfonos con GPS, giroscopios y acelerómetros para poder saber en todo momento dónde está la cámara y a qué está apuntando. No existen teléfonos así a día de hoy... pero no parece muy descabellado pensar que los vayan a existir en un futuro próximo, teniendo en cuenta que el API de "android" ya incorpora las funciones necesarias para hacer queries a estos sensores en la clase "android.hardware.Sensors" (ver aquí)
Esos sensores necesitarán ser muy precisos para que la imagen 3D superpuesta no tiemble y de sensación de estar integrada con el resto del paisaje. Esto va a ser jodido, así que seguramente se requerirá algún tipo de procesado de imagen para tomar referencias extra y ayudar así al sistema de posicionamiento de la cámara... pero procesamiento de imagen en el micro de un teléfono móvil suena jodido, aunque quien sabe.
Si bien la idea es buena, no es nada que no pueda hacerse en un par de semanas (o menos!) con el hardware adecuado. Así que intentar hacerse rico SOLO con eso es jodido. Para ofrecer un productor que tenga algo de valor propongo ir un paso más allá y REALMENTE analizar la imagen obtenida por la cámara, y detectar edificios y farolas y árboles, determinar su profundidad (y con ella su posición en el universo 3D) y hacer que las flechas se vuelvan más trasparentes cuando pasen por detrás de los objetos que nos las ocultan desde nuestro punto de vista. ¿Cómo obtenemos la profundidad de los objetos a partir de una imagen? Bueno... es jodido, pero se puede, como se demuestra en este "paper" que he encontrado buscando 5 minutos en google. Además, no disponemos de una sola imagen. Disponemos de video a 15 o 20 fps que nos ofrecen una misma imagen vista desde distintos puntos de vista. Y así sí que se puede obtener el "mapa de profundidad" de manera mucho más sencilla y estudiada (ver esta búsqueda en google).

EXISTE ALGO PARECIDO?
Bueno... la "realidad aumentada" parece que está mucho más desarrollada de lo que yo pensaba. Hay un toolkit para linux que permite hacer auténticas virguerías (guay!). Mirad si no lo que ha hecho Julian Oliver con él. Esto no creo que nos sirviese para nada para lo nuestro, pero sería cuestión de echarle un par de horas al asunto a ver si se me ocurre alguna otra cosa para alguna otra idea absurda :)
Por otro lado están los tipos estos (que se hicieron famosos ayer en slashdot, pero juro que yo llevo pensando lo mismo varios meses :) que muestran muy bien el concepto, pero de manera muy simple y yendo un paso más allá: proyectan la flecha virtual (que en su caso es una simple linea roja) sobre el parabrisas del coche.
Pero viendo la web parece que son un grupo de amigos que se han juntado para patentar un monton de cosas que se refieren sólo al SISTEMA DE PROYECCIÓN. El resto lo tienen muy cogido con alfileres: incluso los videos que se muestran en la web son "simulaciones" en los que la "linea virtual" en realidad se ha dibujado a mano frame a frame (ejem... tongo!... ejem...)

CONCLUSIÓN
Yo creo que esto da para algo. Una vez desarrollado el reconocimiento de formas 3D en imagenes de video se combina con el sistema de posicionamiento y una base de datos externa (google). La posibilidades son muy guapas: trazado de rutas virtuales, reconocimiento de edificios y datos sobre el mismo (¿cuanto vale un café en este bar? ¿cual es su telefono?) sin más que enfocarlo con la cámara de vídeo del móvil, etc...

¿Sugerencias? ¿Comentarios?