occams razor 06 03
TRANSCRIPT
EditorialUn Gran paso para Occam’s...
by The Occam’s Razor Team
Occam’sRazor
Número 6. Invierno 2011
Dirección:
David Martínez Oliveira
Colaboradores:
Guillermo Buenadicha, Roger
Oliva Balagué, Manuel
Martín-Neira, Jose Luis
Vázquez García, Fernando
Martín Rodríguez, Laura I.
Rodríguez González, Er
Imaginarius y el inefable
Tamariz de la Perdiz
Maquetación y Grafismo
Laura I. Rodríguez González
Publicidad
Occam’s Razor Direct
Impresión
Por ahora tu mismo. . . Si te
apetece
c©2010 The Occam’s Razor
Team
Esta obra está bajo una licencia
Reconocimiento 2.5 España de
Creative Commons. Para ver
una copia de esta licencia, visite
http://creativecommons.org/licenses/by/2.5/es/
o envie una carta a Creative
Commons, 171 Second Street,
Suite 300, San Francisco,
California 94105, USA.
Consulta la página 50 paralas excepciones a esta
licencia
Es otra vez esa época del año en la que Occam’s Razor llega a vuestrosdiscos duros intentando contaros algo interesante y que quizás no conozcáistodavía. Bien, aquí esta el numero 6 de Occam’s Razor.
Como reza el título de esta editorial, este número supone “Un gran paso paraesta revista”. Y el contexto espacial no es gratuito. Es un gran paso porque,con este número, finalmente hemos conseguido movernos en la dirección quesiempre hemos deseado, más contenidos científicos.En este número encontraréis dos excelentes artículos de profesionales de laAgencia Espacial Europea, concretamente del Centro de Astronomía EspacialEuropeo (ESAC) ubicado a las afueras de Madrid así como del Centro EspacialEuropeo de Tecnología e Investigación (ESTEC) en los Países bajos.En el primero de ellos Guillermo, Roger y Manuel nos describen con todolujo de detalles la misión SMOS en la que España ha jugado un papel muyimportante y bueno... mejor leed el artículo.En el segundo, Jose Luis nos presenta SPICE, desarrollado por la NASA parael cálculo de geometría de misiones. Un excelente artículo que aúna de formaamena las operaciones espaciales y los ordenadores, a la vez que nos explicaalgunos, aparentemente sencillos, pero que se complican cuando salimos denuestro querido planeta.La sección de Historia regresa con un interesante artículo sobre la TV de lamano del siempre ameno Fernando Martín. No nos olvidamos de los temas mástécnicos relacionados con los ordenadores a través de dos artículos relacionadoscon la imagen.En el primero de ellos os hablamos de una interesante y ligera solución paraleer imágenes en vuestros programas. El segundo nos introduce en el mundode la Realidad Aumentada a través de ARToolkit.Por último en la “La Cacharrería” os presentamos Teensy. Un microcontroladorcon el que crear dispositivos de entrada, como por ejemplo teclados, es muyfácil.
Esperamos que este número os resulte interesante y desde estas líneas, laredacción de Occam’s Razor os desea todo lo mejor para el próximo 2012!
The Occam’s RazorTeam
Las opiniones expresadas en los artículos, así como los contenidos de los mismos, son responsa-bilidad de los autores de éstos.Puede obtener la versión electrónica de esta publicación, así como el código fuente de la mismay los distintos ficheros de datos asociados a cada artículo en el sitio web:http://webs.uvigo.es/occams-razor
3| OCCAM’s Razor
COMUNIDAD
La Comunidad de OccamLista de Correo, Vídeos y más.
por The Occam’s Razor Team
NUESTRA LISTA DE CORREO
La lista es totalmente abierta así que cualquiera puedeleer las discusiones sin necesidad de suscribirse.
Aquí tenéis alguno de los temas que hemos tratado enla lista.
Hardware Abierto
Un tema de candente actualidad que seguimos modes-tamente en la lista, informando de nuevas iniciativasde hardware abierto como la tarjeta Snowboard, el re-ciente BeagleBone o el anuncio de la Convención deHardware Libre, Electrónica y Robótica (OSHWCon2011) celebrada en Septiembre.
También os hablamos de un interesante reportaje so-bre Arduino que apareció poco después de publicarnuestro último número
Aquí tenéis los enlaces.
Más sobre SnowBoard...
Más sobre BeagleBone...
Más sobre OSHWCon 2011...
Más sobre Arduino, El documental...
Construye tu propia red de telefonía móvil
Un interesante proyecto para construir pequeñas redesde telefonía móvil, allí donde las grandes compañía noquieren llegar.
Mas...
El nombre del programa fantasma
Nuestro amigo Carlos encontró un problema con elprograma fantasma del que os hablamos en el últi-mo número. Todos los detalles en la lista de Occam’sRazor.
Mas..
Los miembros de la lista reciben la revista antes quenadie y además tienen la posibilidad de ofrecer sus co-mentarios antes de que se publique oficialmente. Ade-más, estamos preparando nuevas actividades relacio-nadas con la revista.
NUESTROS VIDEOS
En nuestro canal de YouTube podéis encontrar un parde vídeos sobre algunos de los artículos en este núme-ro. El primero es nuestra sencilla aplicación de Reali-dad Aumentada en vivo.
No os perdáis este video de los autores del artícu-lo (“Interface Tangible Ex-Nihilo”). Que ha aparecidorecientemente en Hack a Day
El segundo vídeo que hemos añadido ilustra nuestroproyecto de la cacharrería de este número.
Si habéis producido algún video a partir de los ar-tículos de Occam’s Razor nos encantaría conocerlos yañadirlos como favoritos en nuestro canal o como vi-deo respuestas si están relacionados con alguno de losvideos ya disponibles.
UNIROS A LA COMUNIDAD!
Nos vemos en nuestra lista de correo y canal deyoutube.
Grupo Occam’s Razor
Canal YouTube
OS ESPERAMOS!!!!
OCCAM’s Razor | 4
RATAS DE BIBLIOTECA
Leyendo Imágenes con LibertadPNGs. JPGs o PSDs con una línea de código
por Er Imaginarius
Por una vez, y sin que sirva de preceden-te, no vamos a hablar de una librería en estasección, aunque generar una librería a partir destb_image sería trivial. stb_image es un fiche-ro fuente C que nos proporciona funciones paraleer en memoria los formatos de imágenes máspopulares con una sola línea de código.
stb_image es un conjunto de funciones escritas en ellenguaje C por Sean Barrett quién las liberó en el do-minio público. En su página web encontraréis algunasotras funciones que también os pueden resultar in-teresante (descompresión Ogg Vorbis o rasterizaciónde fuentes TrueType).
Su uso es muy sencillo, como veremos enseguida, ynos permite añadir soporte para la lectura de imáge-nes en los formatos JPEG, PNG, BMP, TGA, PSD,HDR a nuestros programas, muy fácilmente. Es idealsi queremos evitar que nuestra aplicación tenga de-pendencias con otras librerías o si estamos pensandoen generar un ejecutable estático para algún sistemaembebido, ya que todo el código está contenido en unfichero .C. Sin más, aquí tenéis un ejemplo de comousar esta ratilla.
#inc l ude "stb_image . h"
i n t main ( i n t ac , char ∗∗a ){
i n t w, h , c = 3 ;uns igned char ∗ img ;
img = stbi_load ( a [ 1 ] , &w, &h , &c , 3 ) ;}
Este sencillo programa, lee la imagen que le pasamoscomo primer parámetro en memoria, devolviéndonosun puntero a los datos. Además, nos devuelve el anchoy alto de la imagen, así como el número de componen-tes de color. El último parámetro nos permite indicarcuantas componentes de color queremos en nuestraimagen en memoria, es decir, le podemos pedir a lafunción que convierta la imagen por nosotros.
A modo de ejemplo, si al programa anterior le pasamoscomo primer parámetro una imagen con transparen-cia, el valor de c devuelto por la función será 4 (rojo,verde, azul y alpha), pero la imagen en memoria solotendrá 3 componentes (rojo, verde y azul).
Para obtener el ejecutable, un sencillo:
gcc -g -o image image.c stb_image.c -lm
es suficiente. Observad que necesitamos incluir la li-brería matemática ya que stb_image utiliza algunasfunciones como pow internamente.
Con stb_image podremos leerimágenes en nuestros programasde forma muy sencilla
Leer un jpeg en una línea de código está bastante bien,pero supongo que muchos de vosotros os preguntaréiscomo utilizar los datos que nos devuelve stbi_load.
PROCESADO DE IMÁGENES
Sí, el artículo habría quedado un poquillo corto deesta manera :), así que vamos a escribir un sencilloprograma para modificar el contraste de una imagende forma que podáis ver como acceder a los datos enmemoria de la imagen.
El siguiente ejemplo, implementa la función de mo-dificación de contraste de GIMP. Si no os lo creéis,podéis comprobarlo muy fácilmente.
Aquí está el programa
#inc l ude <math . h>#inc l ude "stb_image . h"
i n t main ( i n t argc , char ∗ argv [ ] ){
i n t i , w, h , c , s i z e , _tf [ 2 5 6 ] ;uns igned char ∗img , ∗p ;f l o a t f , con ;
/∗ Carga imagen ∗/p = img = stbi_load ( argv [ 1 ] , &w, &h , &c , 3 ) ;c = 3 ;s i z e = w ∗ h ∗ c ;
/∗ Calcula funcion de t r an s f e r enc i a ∗/f = ( tan ( ( ( con = 0 . 3 ) + 1) ∗ M_PI/ 4 ) ) ;f o r ( i = 0 ; i < 256 ; i++)
{_tf [ i ] = ( i n t ) ( i − 127) ∗ ( f ) + 127 . 0 ;i f ( _tf [ i ] > 255) _tf [ i ] = 255 ;i f ( _tf [ i ] < 0) _tf [ i ] = 0 ;
}/∗ Aplica funcion de t r an s f e r enc i a ∗/f o r ( i = 0 ; i < s i z e ; i++, p++) ∗p=_tf [∗p ] ;stbi_write_bmp ( argv [ 2 ] , w, h , c , img ) ;
re turn 0 ;}
5| OCCAM’s Razor
RATAS DE BIBLIOTECA
Este sencillo programa toma dos parámetros, la ima-gen a la que queremos modificar el contraste, y el nom-bre del fichero en el que queremos grabar los resulta-dos.
Veamos en detalle que es lo que estamos haciendo.
FUNCIONES DE TRANSFERENCIA
Modificar el contraste de una imagen, es una de esasoperaciones de histograma. La particularidad de estasoperaciones es que se pueden implementar de formamuy sencilla con lo que se llama una función de trans-ferencia. En nuestro caso, una tabla que nos permitecambiar un determinado valor por otro que nosotrosqueramos.
Podemos grabar BMPs y TGAscon una línea más
En el ejemplo anterior, la función de transferencia es elvector tf, que contiene una entrada por cada posiblevalor de cada una de las componentes de la imagen.Como estamos trabajando con 8 bits por componente,la matriz debe ser de 256 valores.
Ahora solo necesitamos introducir en esa tabla el valorde salida que queramos para cada posible valor de lascomponentes de nuestra imagen y utilizar el bucle foral final del programa para aplicar la tabla. Observadque en nuestro ejemplo estamos aplicando la mismafunción a las tres componentes de la imagen, pero po-dríamos aplicar una función distinta a cada una deellas. Eso dependerá de lo que queramos hacer.
Utilizando esta técnica podemos implementar unmontón de ajustes de imagen: brillo, contraste, co-rrección gamma, inverso, posterización, monocromo,etc... Solo necesitamos poner los valores apropiadosen el vector _tf.
VOLCANDO EL RESULTADO
Como ya os habréis dado cuenta stb_image tambiénnos proporciona alguna función para grabar imáge-nes. En nuestro ejemplo estamos utilizando la funciónstbi_write_bmp para generar una imagen en formato.BMP. El otro formato que podríamos utilizar es .TGA.
AJUSTES FINOS
stb_image nos proporciona un montón de ajustes fi-nos, para controlar que partes del módulo queremosutilizar y que partes no. A continuación os comenta-mos sus efectos.
STBI_NO_WRITE.
Si definimos este valor en nuestro programa (pasán-dole -DSTBI_NO_WRITE al compilador), eliminaremosel código para grabar imágenes (unos 7Kb). Pensadpor ejemplo en un juego, en el que necesitáis cargarun montón de imágenes, pero no hace falta producirninguna.
STBI_NO_STDIO.
Definiendo este valor durante la compilación de nues-tra aplicación eliminaremos el código para leer imá-genes de ficheros. Eso elimina la dependencia destdio.h que añade unos cuantos Kbytes a nuestraaplicación.
En este caso, todavía disponemos de una funciónstbi_load_from_memory. ¿Cuando nos puede intere-sar utilizar esta opción?. En general cuando obtenga-mos nuestros datos desde cualquier otra cosa que nosea un fichero (una conexión de red, una webcam queproduce imágenes JPEG, etc...)
HASTA LA PRÓXIMA
Esto es todo. Como siempre esperamos vuestros ex-perimentos con stb_image y saber de los nuevos usosque se os ocurran. Podéis enviarnos vuestros resulta-dos a nuestra lista de correo. Hay un montón de cosasinteresantes que hacer con imágenes ahí fuera ;)
OCCAM’s Razor | 6
El presente artículo versa sobre la misiónSMOS de la ESA, centrándose en sus objetivoscientíficos y tecnológicos, su evolución histórica,una breve descripción de los primeros dos añosde vida, y finalmente una serie de retos que es-peran en los años por venir. No pretende ser unadescripción exhaustiva (se proporcionan referen-cias para el lector que esté interesado en un ma-yor nivel de detalle), sino más bien se dirige alpúblico formado pero sin experiencia previa enel sector espacial.
CONTEXTO PARA LA MISIÓN.EARTH EXPLORERS, LIVING PLANET
La misión SMOS (Soil Moisture and Ocean Salinity,o Humedad del Suelo y Salinidad de los Océanos) esuno de los llamados Earth Explorers, que son compo-nentes integrantes del programa Living Planet de laAgencia Espacial Europea (ESA). La ESA mantieneactividades englobadas en el área de Observación de laTierra desde 1977. A finales de la década de los 90, seinició el programa “Planeta Viviente”, con una vertien-te científica y de investigación más que de explotaciónde datos. El objetivo era comprender nuestro planetacomo un sistema cambiante, modelar sus procesos yprofundizar en la comprensión del cambio climáticoglobal.
El componente espacial de este programa (comple-mentado con un componente terreno para la disemina-ción de los datos) son los seis primeros exploradores,familia de misiones que actualmente se está aumen-tando con 2 nuevas propuestas en estudio. Estos eranCryosat, misión dedicada al análisis del espesor de lascapas de hielo, destinada a ser la primera misión en vo-lar, aunque un fallo en el lanzador en el 2005 hizo quese reiniciase como Cryosat II (finalmente lanzado en el2010); GOCE, la misión que busca definir el mapa gra-vitatorio terrestre, lanzada en Marzo del 2009; SMOS,la misión del agua, que detallaremos más adelante ytambién volando desde finales del 2009; SWARM,
Programa Living Planet de la ESA (Cortesía ESA)
7| OCCAM’s Razor
CIENCIA Y ESPACIO
una constelación de 3 satélites para medir mejor elcampo magnético terrestre, que se lanzará a lo largodel 2012; ADM Aeolus, pendiente de lanzamiento ydedicada al análisis de los vientos, y Earth-Care, quetambién será lanzada en los próximos años y dedicadoal estudio de las nubes y la concentración de aerosolesen las capas altas de la atmósfera.
Todas estas misiones se complementarán con los Sen-tinels (Centinelas), familia de satélites que implemen-tarán el programa GMES (conjunto entre la ESA yla Unión Europea) y con misiones desarrolladas encooperación entre la ESA y Eumetsat. Como se puedever, la observación y comprensión de nuestro planetano es tarea sencilla, y requiere de un esfuerzo multi-disciplinar.
HISTORIA
Respondiendo al concurso de propuestas para el pro-grama Living Planet, se presentó en 1998 la misiónSMOS, por parte del Insituto Francés CESBIO conYann Kerr como investigador principal (PI) y el Insti-tuto español de Ciencias del Mar con Jordi Font comoco-investigador principal. La misión fue seleccionadapor la ESA en el 99. Detrás de esto se halla el hechode que tanto España como Francia fueron países den-tro de la ESA altamente interesados en la suscripcióna este programa en concreto.
Para dar una referencia de las escalas de tiempo en eldesarrollo de una misión espacial, la fase A o de defi-nición concreta de la misión se inició en el año 2000,con una fecha de lanzamiento previsto entonces parael 2007. Finalmente, como veremos, SMOS se lanzó
a finales del 2009, llevando así a un ciclo de casi 10años desde el comienzo del desarrollo de la misión unavez aprobada hasta su fase de explotación. Debería-mos añadir además un período anterior de estudios,desarrollo de la tecnología necesaria y experimentosprevios, que comenzó ya en 1992. Este ciclo, de unos18 años desde su concepción a su lanzamiento, es ra-zonable y hasta ineluctable para una misión novedosade tamaño medio como SMOS, pudiendo muchas vecesampliarse en el caso de misiones de mayor envergadu-ra.
PROGRAMA INDUSTRIAL
Como se ha indicado, tanto Francia como España de-mostraron gran interés en el programa SMOS. A lahora de definir la contribución y el retorno industrialpara estos países (siendo el retorno industrial una delas bases del funcionamiento de la ESA), Francia optópor el desarrollo de la plataforma del satélite, y porasumir las operaciones de la misma, y España escogióla construcción del instrumento así como el controly operaciones del mismo y el centro de procesado dedatos científicos. Ambos países desarrollaron también,al margen de la ESA, centros de procesado científicode más alto nivel para la explotación a fondo de losdatos.
La plataforma de SMOS, basada en el bus estándarPROTEUS, fue construida por Thales Alenia Spaceen Cannes, y el centro de operaciones se englobó enel centro del CNES francés en Toulouse. Esto facilitóel poder reutilizar conocimiento adquirido previamen-te, al haber operado CNES otras misiones basadas enPROTEUS.
Integración del instrumento MIRAS en SMOS (cortesía ESA)
OCCAM’s Razor | 8
CIENCIA Y ESPACIO
Interferometría (cortesía ESA)
El instrumento de SMOS, MIRAS, fue desarrolladopor la empresa EADS-CASA en Madrid, como prin-cipal contratista al frente de un amplio consorcio deempresas españolas y europeas entre las que se puedemencionar la participación de MIER, RYMSA, YLI-NEN, CONTRAVES, ASTRIUM-Munich, LABEN,Austrian Aeorspace, SENER y TECNOLOGICA.
El centro de operaciones y de procesado de datos delinstrumento fue desarrollado por un consorcio lide-rado por la empresa INDRA, en el que participaronGMV y Deimos entre otras empresas.
La ESA asumió el papel de coordinador global del pro-yecto, gestionando las distintas fases del programa, ybuscando el lanzador para el satélite, que se contratófinalmente con EUROCKOT, empresa germano rusaque utiliza el cohete Rockot desde la base de Plesetsken Rusia.
LÓGICA DE FUNCIONAMIENTO
El objetivo de SMOS se puede resumir en la adquisi-ción a nivel global y con periodicidad de dos variablesclaves para comprender el ciclo del agua: la salinidadsuperficial de los océanos, y la humedad retenida enlos primeros centímetros del suelo.
Ciclo del agua (Cortesía ESA).
La propuesta científica propuso la implementación deun radiómetro que captase la emisión superficial enbanda L (1.4 Ghz), debido a que esa banda es unabanda protegida para la investigación científica, y ade-más a que de la citada emisión se pueden inferir lasdos variables buscadas.
El objetivo de la misión, sobre todo en su componentede humedad superficial, exigía un tiempo de revisita(tiempo que tarda SMOS en volver a medir un mismopunto en la superficie terrestre) de 3 días en el ecua-dor, y una resolución espacial o tamaño de pixel de 30a 50 Kms. Eso exige a la vez un campo de vista amplio(aproximadamente a 1000 Kms) y un tamaño de pixelrelativamente pequeño para el mismo, asumiendo unaórbita síncrona solar a unos 760 Kms de altitud.
SMOS utiliza un radiómetro quecapta la emisión superficial debanda L
La solución encontrada, frente a una única antena pa-rabólica con barrido mecánico –cuyo tamaño no per-mitía cumplir con los requisitos de la misión ni enca-jaba en lanzadores disponibles– fue usar la interfero-metría desde el espacio. La idea consistía en componeruna antena de apertura sintética con un array en Ygriega de 69 detectores distribuidos en tres brazos a120 grados y un Hub central. Esto permitía obteneruna antena equivalente de unos 8 metros de diámetro,que podía plegarse gracias a sus segmentos articuladosa la hora del lanzamiento, y posteriormente desplegar-se en la configuración final de vuelo.
SMOS utiliza por tanto receptores pasivos, con capa-cidad de polarización tanto vertical como horizontal,y utiliza los principios interferométricos para obtenercada 1.2 segundos una imagen de la escena basada enla correlación de las distintas señales recibidas en cadauno de sus receptores.
9| OCCAM’s Razor
CIENCIA Y ESPACIO
Esta técnica es pionera por cuanto que la interfero-metría radiométrica nunca se había probado desde elespacio para observar la Tierra. La ESA planteabaun desafío tecnológico y científico importante: hacerradio-astronomía de la tierra. Para ello fue necesariouna revisión de las ecuaciones clásicas de interfero-metría utilizadas en Radioastronomía, lo que fue engran parte posible gracias a la definición y análisis delas mismas que realizó el Dr. Ignasi Corbella (UPC)reflejados en la ecuación que lleva su nombre.
Esta selección con una antena sintética impone asímismo retos que son nuevos para la ESA, como sonla selección de 69 receptores con características extre-madamente similares, y sobre todo, el que a la horade computar sus correlaciones sea necesario una trans-misión de información entre ellos que obliga a utilizaruna red distribuida de fibra óptica, siendo SMOS laprimera misión ESA que lo implementa.
Así mismo, SMOS necesita una red interna de calibra-ción para poder evaluar el adecuado funcionamientode los receptores.
SMOS es un satélite de tamaño medio, de 650 Kgs demasa de los cuales 350 corresponden al instrumentoMIRAS. Algunos de los principales parámetros de lamisión pueden verse en la siguiente tabla:
Tabla de datos de misión.
ÓRBITA DE SMOS
La órbita seleccionada para SMOS, clásica en las mi-siones de observación de la tierra, es una órbita cuasipolar (es decir, que el satélite orbita la Tierra pasan-do de polo a polo) con una altitud de 760 Kms, loque marca un periodo orbital de 100 minutos. La ór-bita no es estrictamente polar, sino que el plano de lamisma tiene una inclinación de unos 8 grados respec-to al eje terrestre, lo que permite que el plano de laórbita de SMOS se mantenga siempre perpendicularal vector del Sol. Esto es muy adecuado, ya que lospaneles solares mantienen una orientación constantey un rendimiento óptimo.
La altitud de la órbita define el compromiso entre cu-brir haz amplio de terreno (mayor cuanto más alta laórbita) y una precisión de pixel ajustada (mejor cuan-to más baja la órbita). Al tiempo, se ha seleccionadode forma que el paso ascendente por el Ecuador (co-nocido como nodo ascendente) ocurre siempre a las06:00 horas solares locales del punto de paso, por loque las condiciones en el suelo son siempre las mis-mas. Esto es esencial para una evaluación consistentede los datos.
Gráfico de la órbita (Cortesía ESA).
Como ya se ha mencionado, MIRAS es un instrumentode gran tamaño, más de 350 kgs de peso y una enver-gadura de unos 8 metros de diámetro con los brazosdesplegados. Consta de una unidad central (Hub) deforma hexagonal, que alberga unidades de electrónica(ordenador central, memoria de almacenamiento, co-rrelador, transmisor en banda X), y de una serie desegmentos (12) que se configuran en 3 brazos en Ygriega, con 4 segmentos cada uno, uno en el hub y 3desplegados en segmentos exteriores. Los 69 recepto-res o LICEF de MIRAS se ubican en esos segmentos(6 en cada uno), habiendo 3 unidades especiales quetienen un doble receptor en ellas, llamadas NIR (NoiseInjection Radiometer).
Unas unidades distribuidas (CMN’s) en cada segmen-to se encargan de proporcionar la señal de un osciladorlocal para los LICEF de su segmento, de recolectar lasseñales de los mismos para el correlador, y de ejecutarlos comandos y recolectar telemetría de estado.
OCCAM’s Razor | 10
CIENCIA Y ESPACIO
Imagen del Instrumento. Gráfico LICEF (Cortesía ESA)
Una red de calibración se encarga de alimentar, cuan-do es requerido, cada receptor con ruido correlado ono correlado, para medir la estabilidad y caracterizarel instrumento.
LANZAMIENTO, LEOPY COMISIONADO
SMOS fue lanzado por un cohete Rockot (adaptadode antiguos misiles intercontinentales rusos) el 2 deNoviembre del 2009, a la 1:50 UTC desde el cosmó-dromo de Plesetsk, en Rusia. Rockot es un sistema delanzamiento que incluye una última etapa, Fregat, quepermite una inserción bastante precisa en la órbita,minimizando así el consumo de combustible cargadoen el satélite. El lanzamiento fue todo un éxito, a laspocas horas de alcanzar la primera órbita SMOS pu-do desplegar los paneles solares y también “abrir” losbrazos del instrumento MIRAS, siendo ésta una de lasmaniobras más críticas para la misión.
Las primeras dos semanas de vida se dedicaron a ajus-tar la órbita de SMOS, y a realizar la comprobaciónde funcionamiento de la plataforma, lo que se llamael comisionado de la misma. En este periodo se veri-fican todos los subsistemas, y se alcanza la estabili-
dad térmica del satélite. En esta fase el instrumentoMIRAS permaneció apagado, con un control térmicobasado en sensores y resistencias eléctricas proporcio-nados por la plataforma.
Finalmente, el 17 de Noviembre el instrumento fueencendido, pasándose a un control térmico activo in-terno que mantiene los subsistemas estables en tornoa 22 grados centígrados. La tarde de ese mismo díalos primeros datos fueron adquiridos por la estaciónde recepción en ESAC, obteniéndose lo que se vieneen llamar la “primera luz”.
Durante las dos primeras sema-nas se ajusto la órbita y se com-probaron todos los sistemas deSMOS.
Siguió una fase de aproximadamente 2 semanas dondese realizaron unos chequeos para verificar el adecuadofuncionamiento del instrumento, de los datos genera-dos y de la capacidad de adquisición y procesado porel segmento de tierra, culminada con éxito.
11| OCCAM’s Razor
CIENCIA Y ESPACIO
Primera Luz SMOS (cortesía ESA)
Posteriormente, una fase de unos dos meses en los quese analizó más en detalle el funcionamiento científicodel instrumento, incluyendo alguna modificación dela configuración y redundancia seleccionada en el lan-zamiento, y una prueba de funcionamiento a distintonivel térmico.
Finalmente, se concluyó la fase de comisionado delinstrumento con 4 meses de operaciones donde se al-ternaron distintos escenarios y modos de MIRAS (cono sin medición de polarización cruzada) y un estudiode las frecuencias y secuencias óptimas de calibraciónbasado en las medidas en órbita. También se anali-zaron y caracterizaron distintos parámetros del siste-ma (precisión geométrica, caracterización de antenas)y se compaginaron las observaciones de MIRAS condistintas campañas en tierra para validar las medidasdel instrumento. En Mayo del 2010 se inició la fase deexplotación regular, con una configuración fija para lamisión, y con un plan de calibración estable.
La fase de comisionado de SMOS, prácticamente 6 me-ses, ha sido más larga de lo que es habitual en otrasmisiones de corte científico, debido principalmente alcarácter absolutamente innovador del concepto de ra-diometría interferométrica desde el espacio, pero almismo tiempo ha sido necesaria y esencial para que lafase nominal de la misión pueda proporcionar el má-ximo de datos científicos con la mejor calidad posible.
La fase de comisionado desveló lo que están siendo losgrandes retos de SMOS a la hora de cumplir sus ob-jetivos científicos. Posiblemente el mayor de ellos seaque la banda L en la que recibe MIRAS, teóricamenteprotegida por la regulación internacional del espacioradio-eléctrico, se encuentra en realidad contaminadapor emisiones de sistemas defectuosos o ilegales. Losdatos de SMOS descubrieron un gran número de es-tas emisiones espurias humanas en la banda protegida,que se daban en general por todo el planeta pero es-pecialmente numerosas en Europa, Oriente Medio, ysudeste asiático.
Esas emisiones enmascaran la señal natural que ob-serva SMOS dado que las emisiones humanas estánmuy por encima de los niveles naturales de radiación.Además, debido a las características del instrumento,una sola antena interferente puede afectar a SMOSaún cuando esté a miles de kilómetros del mismo.
Por otro lado, se detectaron unidades a bordo quese demostraron sensibles a la radiación (la órbita deSMOS atraviesa las zonas polares, donde la concentra-ción de partículas cargadas es mayor, pero también laAnomalía del Atlántico Sur, donde los cinturones deradiación terrestres están más cercanos a la superfi-cie) y a la iluminación solar. La configuración óptimafrente a esos efectos fue seleccionada para garantizarel mejor retorno científico; hoy en día siguen presentes,pero su impacto en el retorno científico es mínimo.
OCCAM’s Razor | 12
CIENCIA Y ESPACIO
Mapa de probabilidad de interferencia, (cortesía CESBIO)
SEGMENTO DE TIERRAY OPERACIONES DE LA MISIÓN
El segmento de tierra de SMOS está compuesto por unsegmento de control de plataforma, SOGS, en CNES,Toulouse, que se encarga de enviar todos los coman-dos (plataforma e instrumento) al satélite a través deuna red de estaciones de Telecomando y Telemetríaen banda S, así como de recabar la telemetría de laplataforma y una copia de la telemetría del instrumen-to, que posteriormente es enviada al Centro Europeode Astronomía Espacial de la ESA en España, ESAC,cerca de Madrid. Desde el CNES se mantiene la acti-tud o apuntamiento del satélite, la órbita dentro de losparámetros requeridos, y se calculan posibles riesgosde colisión con restos de basura espacial. Al mismotiempo, se garantizan la seguridad de la plataformay del instrumento en casos de anomalías que puedanponer en riesgo la integridad de la misión.
En ESAC, se lleva a cabo el control y operaciones delinstrumento, incluyendo la planificación semanal delas operaciones y calibraciones que ha de realizar, ge-nerando los comandos para MIRAS que se enviarán através de CNES, y analizando los datos de telemetríade SMOS que se reciben tanto a través de CNES comodel enlace en banda X con el instrumento.
En ESAC, así mismo, se reciben los datos científicos(recogidos por dos estaciones de seguimiento terreno,en ESAC y en SVALBARD, Noruega), y se realiza el
procesado de datos hasta generar los productos de ni-vel 2 de salinidad y humedad superficial. En paralelo,ESAC tiene la capacidad de realizar campañas de re-procesado de datos de SMOS, tarea que comparte conel centro de la ESA en Kiruna, Suecia.
Por último, ESAC también alberga el grupo de cali-dad, que garantiza que el nivel de la data de SMOSes adecuado para su diseminación a la comunidad deusuarios.
ESAC es un centro clave en lamisión SMOS.
ESRIN, el centro de la ESA en Italia dedicado a Ob-servación de la Tierra, ejerce de centro de gestión delprograma, y alberga el segmento de diseminación dedatos a usuarios así como el de centro de asistencia alos mismos.
El centro tecnológico de la ESA en Holanda, ESTEC,alberga la oficina encargada de mantener el adecuadonivel de soporte industrial tras el lanzamiento paragarantizar el máximo nivel de funcionamiento de lamisión.
Y finalmente, un amplio número de centros expertosse encargan de colaborar para definir el mejor proce-sado posible para los datos de SMOS.
13| OCCAM’s Razor
CIENCIA Y ESPACIO
Segmento de tierra de la misión SMOS (Cortesía CNES-ESA)
FASE DE RUTINA, OPERACIONESY PROCESADO DE LA SEÑAL
SMOS es una misión de escaneo periódico de la tierra.Esto quiere decir que en principio, mantiene una posi-ción fija (con una inclinación de unos 32 grados haciadelante respecto a un apuntamiento vertical, perpen-dicular a la superficie de la Tierra) y recolecta datosaprovechando que la órbita polar le permite cubrir elplaneta cada 3 días. Su modo de observación es fijo,siendo el que ubica los distintos receptores o LICEFsen polaridades distintas a lo largo del tiempo de inte-gración de 1.2 segundos, obteniendo así una señal queobtiene los 4 parámetros de Stokes.
Entendida así, las operaciones de la misión pudieranparecer sencillas. Dos operaciones se entremezclan coneste escenario rutinario:
La fase de rutina entremezcla dosoperaciones: Transmisión de da-tos y calibraciones periódicas.
Una es la necesidad de trasmitir a tierra los datos ad-quiridos por SMOS. La misión contiene un requisitode datos en tiempo cuasi real (que pide que datos pro-cesados hasta un determinado nivel estén disponiblespara los usuarios en menos de tres horas desde la tomade la imagen), que impone que SMOS vuelque en ca-da órbita de 100 minutos los datos adquiridos en ella.
Dos estaciones de adquisición, en la isla de Svalvard,Noruega (en una latitud alta, y por tanto con visibi-lidad de todas las órbitas de SMOS) y otra en ESAC(dedicada en exclusiva a SMOS) garantizan esto. Hayque comandar al instrumento para que cuando entreen zona de visibilidad por la estación de tierra vuel-que los datos almacenados en la memoria a bordo, yactualice sus punteros.
La segunda es la necesidad de realizar actividadesde calibración periódicas de forma que los datos deSMOS sean estables y precisos. Las distintas secuen-cias de calibración garantizan la estabilidad de todoslos componentes del instrumento y regulan la sensibi-lidad de estos con variaciones temporales y térmicas.Una calibración periódica (cada 10 minutos) corrigelas variaciones observadas debido a las variaciones tér-micas en órbita, controlando la estabilidad de las dife-rencias de fase entre los osciladores locales asociadosa cada pareja de receptores. La calibración de cadauno de los receptores se consigue con dos secuenciasde calibración que verifican la señal enviada por unosdiodos internos de referencia, una larga (cada dos me-ses) y otra mucho más corta (cada semana) que pro-porcionan información de los desvíos que haya sufridocualquier receptor. El nivel absoluto de la imagen secontrasta cada dos semanas con la única señal externade referencia para esta misión: las radiación cósmicade microondas, una reminiscencia del Big Bang que seobserva girando el instrumento hacia el espacio exte-rior.
OCCAM’s Razor | 14
CIENCIA Y ESPACIO
Asimismo, esta señal cósmica es aprovechada cada se-mestre para corregir cualquier desviación que hayansufrido las antenas a bordo. Estas dos últimas secuen-cias de calibración requieren un giro del instrumentode forma que MIRAS observe al espacio a 180 gradosrespecto a la Tierra. Estas actividades han de coor-dinarse y convertirse en comandos de MIRAS y peti-ciones para el centro de control de la plataforma enCNES.
El instrumento MIRAS a bordode SMOS tiene una capacidad dealmacenamiento de 20Gb.
Los datos adquirida por MIRAS (tanto la de estatusdel instrumento e información relevante de sus subsis-temas, como la de las correlaciones entre receptores)es almacenada en la memoria del instrumento (con ca-pacidad para 20 Gb, y posibilidad de almacenar másde un día de datos sin sobrescribirse), y transmitidaa tierra. Constituye los datos crudos o “raw”.
Éstos son recibidos en el centro de procesado de datos(DPGS en ESAC), y convertida primeramente en pro-ductos ordenados por semiórbitas, al tiempo que cla-sificados en distintos tipos de producto en función delos datos contenidos (correlaciones, calibración, esta-tus de instrumento, etc.). Es lo que se llama procesadode nivel 0.
Seguidamente, se corrige usando los datos de las dis-tintas calibraciones y luego se recompone la imagende SMOS aplicando una técnica similar a una trans-formada inversa de Fourier. Esa imagen, obtenida enel plano de antena, se proyecta a nivel de tierra, inclu-yendo entre otras cosas la variación de la señal debidaa la rotación de Faraday debida a la presencia de car-ga eléctrica en la ionosfera terrestre. Es el procesadode nivel 1, a menudo escindido en distintos subnivelespara identificar en qué punto del procesado nos ha-llamos. Al final de este nivel, obtendremos mapas de
Temperatura de Brillo (emisividad en banda L).
Finalmente, dos procesados diferenciados se encarga-ran de convertir la temperatura de brillo en salinidado en datos de humedad. Para ello, es preciso una segre-gación geográfica (tierra-mar), y luego aplicar distin-tos algoritmos para derivar la variable geofísica de lamedida. Sin entrar en detalles, pero a título de ejem-plo, la información de la salinidad del mar depende delconocimiento también de la temperatura física super-ficial, y sobre todo de la información de la rugosidaddel mismo, debida al oleaje. Eso hace que se precisendatos complementarios a SMOS para estos procesa-dos. Para la humedad superficial es necesario entreotros el conocimiento del índice vegetativo o cantidadde biomasa de la zona en cuestión, siendo esto algocon variabilidad estacional, así como información dela rugosidad del suelo.
Los mapas globales de salinidad y de humedad cons-tituyen los dos productos de nivel 2 que representanel final de la cadena operacional de procesado.
Todos los productos generados pasan una serie de con-troles de calidad para evitar que problemas o erroresdel procesador en tierra o el instrumento originen quedatos falsos sean diseminados.
Finalmente, los datos son entregados a un grupo desuscriptores (son usuarios que han requerido y hansido autorizados a recibir directamente los datos) ya un archivo de misión que se encarga de gestionarcualquier otra petición que se recibiera.
Los datos de SMOS son gratuitos y abiertos acualquier persona interesada en su análisis o ex-plotación. El portal de observación de la tierra(http://earth.esa.int) gestiona las peticiones o acce-so de los datos.
Procesados a niveles superiores (nivel 3, donde los da-tos de SMOS se analizan y se yuxtaponen temporal-mente, o nivel 4 donde se complementan con datos deotros sensores espaciales) son realizados por los usua-rios finales, pero también por los centros nacionalesespañol (CP34) y francés (CATDS).
Procesado de señal (Cortesía ESA)
15| OCCAM’s Razor
CIENCIA Y ESPACIO
Comparativa de humedad en Europa 2010/2011 (Cortesía CESBIO)
Como se comentó, un requisito paralelo al científicosolicita un componente de datos en tiempo cuasi real.Para ello, partiendo de los datos en nivel 0 se realizaun procesado rápido de nivel 1 (diferente al de la ca-dena nominal), y esos datos son enviados a un serviciode distribución para usuarios típicamente meteoroló-gicos que utilizan las medidas de SMOS para mejorarlas previsiones meteorológicas a corto y medio plazo.
El procesado en tierra aquí descrito está continuamen-te siendo evaluado por un grupo de usuarios expertos,que proponen y sugieren mejoras. Estas se consolidananualmente en una actualización de la cadena de pro-cesado, y una campaña de reprocesado de todos losdatos acumulados desde el comienzo de la misión selleva a cabo en procesadores con alta capacidad (convelocidades que llegan a 12 veces la del procesadoroperacional), de forma que los datos se vuelven a con-solidar con la última actualización.
RESULTADOS CIENTÍFICOS
Los objetivos científicos de SMOS, después de dosaños de misión en vuelo, están convergiendo con losrequisitos iniciales de la misión. Hay que destacar unavez más que los requisitos son ambiciosos, y que SMOSes un concepto absolutamente innovador, por lo quela consecución de los requisitos iniciales se espera trasvarios años de mejoras en la comprensión del instru-mento y campañas en tierra para respaldar sus datos.
Respecto a la humedad superficial, las mediciones deSMOS comparadas con campañas en tierra todavíamuestran un sesgo inferior. No obstante, sitios de ca-libración como Dome-C en la Antártida o en zonas nocontaminadas por interferencias, como en Australia,prueban que se puede obtener una buena correlación,mejorando sobre todo la comprensión de humedad agran escala y su variabilidad temporal e incluso anual.SMOS se ha demostrado hasta la fecha como una he-rramienta esencial para la comprensión de la acumu-lación de agua a nivel mundial, analizando fenómenoscomo las inundaciones (cuando la saturación del suelocausa escorrentía más que asimilación), y al tiempo,la ingestión de productos de SMOS en los modelos depredicción meteorológica está mejorándolos.
SMOS ha sido la primera misión que ha podido rea-lizar un mapa con una elevada precisión espacial yalta sensibilidad de la Salinidad oceánica. Fenómenoscomo los deshielos de casquetes polares y su contri-bución a las corrientes termo-halinas, o evaporación-precipitación que determinan eventos como el Niño ola Niña, o comprensión de los grandes balances salinosentre océanos (trasvase Atlántico-Pacífico) no habíanpodido ser monitorizados con antelación, y ahora sehacen visibles a la comunidad científica. Con ello, seestá abriendo una puerta a múltiples formas de inves-tigación antes no existentes. Además, en el área desalinidad, la misión Acquarius, lanzada en 2011, com-plementará y ampliará los datos de SMOS.
OCCAM’s Razor | 16
CIENCIA Y ESPACIO
Mapa de Salinidad (Cortesía CESBIO)
RETOS FUTUROS DE SMOS
SMOS ha entrado ya en su tercer año de misión, lo querepresenta su objetivo inicial para poder demostrar lavalidez de su tecnología. No obstante, la extensión dela misión está siendo analizada para garantizar másaños de datos de SMOS. Los principales retos que en-frenta SMOS de cara a los futuros años son:
Eliminación de interferencias (RFI’s). En estos últi-mos dos años, se ha llevado a cabo un intenso trabajopor parte de la ESA y las autoridades nacionales dedistintos países para identificar y apagar cuando elloes posible las fuentes de interferencia. Por otro lado,técnicas de filtrado de la señal han logrado mitigarparcialmente su impacto. A pesar de ello, un gran nú-mero de fuentes (y algunas nuevas) permanecen visi-bles, y queda todavía margen para mejorar las técni-cas de filtrado. Como ejemplo se está probando unatécnica de supresión de interferencias que permite me-jorar sustancialmente la recuperación de salinidad enel Mar Mediterráneo o en el Mar Negro, contaminadospor emisiones radio-eléctricas en la banda protegida.
Calibración. Las principales áreas para la mejora dela comprensión del funcionamiento de MIRAS pasanpor refinar el conocimiento de la estabilidad del instru-
mento a corto y largo plazo, la mejora en la definiciónde un modelo de antena, avanzar en las correccionesde fuentes intensas como el sol o las RFI’s.
Campañas en tierra. La caracterización de áreas cla-ve en tierra y la correlación de sus datos con SMOSpermitirán referenciar y calibrar mejor sus datos. Ellanzamiento de la misión Aquarius (NASA-Argentina)en Junio del 2011 proporcionará también otras refe-rencias (especialmente en salinidad) con las que SMOSpodrá ser evaluado.
Uso del tiempo cuasi real. Los datos de SMOS en tiem-po cuasi real están siendo usados en modelos de pre-dicción meteorológica a corto y medio plazo, pero to-davía a título experimental para evaluar el mejor algo-ritmo para incorporarlos. En los próximos años cabeesperar que estos modelos se refinen y se usen másampliamente.
Procesado y reprocesado. Como se ha indicado, el pro-cesado de los datos de SMOS no es un algoritmo es-tático y estable, sino abierto a continuas mejoras engran medida derivadas de una mayor comunidad cien-tífica usando los datos. En particular, será necesariomejorar la conversión de la temperatura de brillo enproductos de humedad y salinidad a través de mejorasen los procesadores de nivel 2.
REFERENCIAS
Página SMOS ESA, http://earth.esa.int/smosyhttp://www.esa.int/SMOSPágina SMOS CNES, http://smsc.cnes.fr/SMOS/Página SMOS CESBIO, http://www.cesbio.ups-tlse.fr/SMOS_blog/Página SMOS BEC-ICM, http://www.smos-bec.icm.csic.es/Edición especial SMOS, Transactions on Geoscience and Remote Sensing (TGARS) 2008.Publicaciones técnicas sobre SMOS hasta el 2009: http://esamultimedia.esa.int/docs/SMOS_publications.pdfSMOS en el boletín de la ESA:
http://esamultimedia.esa.int/multimedia/publications/ESA-Bulletin-137/pageflip.html
17| OCCAM’s Razor
MÚ RÁPIDO
Realidad AumentadaIntrodúcete en la Realidad Aumentada con ARToolkit
por Er ARturo Grandes
La realidad aumentada (augmented reality),se puede ver como la disciplina complementariaa la realidad virtual. Mientras en esta última sepretende crear un entorno lo más realista posiblede forma sintética (en la memoria de un ordena-dor) la realidad aumentada busca aumentar larealidad con información adicional.
Las aplicaciones de realidad aumentada se han po-pularizado en los últimos años gracias a multitud deavances tecnológicos que han permitido llevar a lapráctica ideas que llevaban flotando en las cabezasde los científicos e ingenieros durante varios años.
Curiosamente, los principales avances en este área sehan centrado en intentar aumentar visualmente nues-tra percepción de la realidad y, a día de hoy, el términoRealidad Aumentada se identifica única y exclusiva-mente con este concepto.
Dicho esto, para el que escribe estas líneas, el concep-to de Realidad Aumentada va mucho más allá y nopuede más que considerar esta definición una metoni-mia en la que se ha tomado la parte por el todo. Elconcepto Realidad Aumentada no implica en sí mis-mo una dependencia directa con nuestro sentido dela vista. Literalmente sugiere aumentar la realidad o,más precisamente, la realidad como nosotros la perci-bimos. ¿Y cómo percibimos la realidad?, pues a travésde nuestros sentidos.
La Realidad Aumentada nos per-mite añadir información adicio-nal a la realidad que percibimos
La vista es sólo uno de nuestros cinco sentidos (sí cin-co, aunque muchas veces nos olvidamos de que estánahí), y los seres humanos percibimos la realidad a tra-vés de nuestros sentidos. La Realidad Aumentada, ensu sentido más general, puede ser vista como el con-junto de tecnologías que permiten aumentar nuestrossentidos, y por lo tanto la realidad que percibimos através de ellos.
A lo largo de este texto nos referiremos a la RealidadAumentada por su acrónimo en inglés, AR. Las razónfundamental es que así es como se refiere la mayoríadel mundo a este tipo de tecnologías. La segunda ra-
zón es para evitar que el artículo se relacione con lamitología egipcia :).
HARDWARE PRET-A-PORTÉ
De igual forma que sucede con cualquier tecnologíarelacionada con el ser humano, el software no es sufi-ciente y junto a este nos encontramos toda una serie desistemas hardware necesarios para poder implementarla tecnología en cuestión. La Realidad Aumentada noes una excepción, y sin la existencia de ciertas solu-ciones hardware, el concepto en si mismo carece desentido.
Wearable Computing es una delas tecnologías clave en un siste-ma de Realidad Aumentada
La principal tecnología hardware relacionada con laAR es lo que se denomina Computación de llevar. Síbueno, la traducción es un poco sui-generis. El tér-mino técnico comúnmente utilizado es wearable com-puting, algo así como ordenadores para vestir, aunqueesta última traducción, además de muy larga tampo-co es que se ajuste al perfectamente al concepto engeneral.
De cualquier forma, la idea es muy sencilla. Si quere-mos extender nuestras capacidades humanas, debería-mos de poder llevar encima los dispositivos que utilice-mos para ello de una forma lo menos intrusiva posible.
Esto se aplica a todos los elementos del sistema, nosolo a los ordenadores, si bien, estos son los más pro-blemáticos. De poco sirve poder extender nuestra per-cepción de la realidad si nuestro mundo se reduce aun laboratorio al que estamos encadenados a travésde multitud de cables.
Así, esta necesidad de llevar puesto el hardware impo-ne en general dos fuertes restricciones. Por una parterestricciones físicas; los cacharros tienen que ser lo másligeros y pequeños posible. Por otra parte autonomía,lo que implica que tenemos que funcionar con bateríasy que estas deben durar lo máximo posible.
Conseguir esto ha sido un gran problema durante mu-cho tiempo. En los últimos años, la proliferación delos teléfonos inteligentes ha proporcionado un impre-sionante empujón a esta línea de investigación.
OCCAM’s Razor | 18
MÚ RÁPIDO
Hoy en día disponemos de potentes ordenadores debolsillo que podemos utilizar durante días y llevar enuno de los bolsillos de nuestra chaqueta.
Como suele ocurrir, el concepto de Wearable Compu-ting ha llegado, pero de una forma un poco diferentea la que esperaban los pioneros de este campo...
EXTENSIÓN SENSORIAL
El ordenador en nuestro bolsillo es el que va a aumen-tar la realidad, pero para ello necesita poder percibirlade alguna forma. No sólo eso, el ordenador también ne-cesita poder comunicar esa realidad aumentada al serhumano, a través de algún dispositivo que pueda co-municarse con ambos; el ordenador y la computadora.
Hasta que los interfaces neuronales se desarrollen losuficiente, la interacción entre máquinas y seres hu-manos se tiene que realizar a nivel sensorial, es decir,a través de los sentidos.
Vista, Oído y Tacto son los sen-tidos en los que más se ha inves-tigado hasta la fecha.
Utilizamos pantallas en las que los ordenadores pue-den mostrar información que nosotros entendemos.Utilizamos altavoces para que los ordenadores puedanreproducir información que nosotros podamos oír. Uti-lizamos dispositivos hápticos para que los ordenado-res puedan proporcionarnos información que nosotrospodamos sentir. Utilizamos micrófonos para que losordenadores puedan percibir nuestras palabras, etc...
Así que, necesitamos algunas cosas en torno a nues-tro ordenador portátil para ser capaces de aumentarla realidad. Por ejemplo, un sistema AR visual nece-sita como mínimo una pantalla y algún sensor con elque averiguar donde se encuentra el usuario o algúnelemento de interés. En el primer caso podríamos uti-lizar, por ejemplo, un GPS y unos acelerómetros. Enel segundo caso una cámara de vídeo sería una opciónválida. De la misma forma micrófonos, auriculares ytecnologías afines tales como, cancelación de ruido,reconocimiento y síntesis de voz son necesarias parapoder aumentar nuestro sentido del oído.
DISPOSITIVOS HÁPTICOS.EL TACTO
El siguiente sentido en el que los investigadores haninvertido muchos de sus esfuerzos es el tacto. Bajo elnombre genérico de dispositivos hápticos, se agrupandos tipos fundamentales de tecnología. Los sistemascapaces de producir vibraciones y los sistemas capa-ces de producir realimentación de fuerza. Estos dis-positivos se han desarrollado sobre todo en el ámbitode la realidad virtual, pero su aplicación a la realidadaumentada no tardara en hacerse patente.
La gama de dispositivos hápticos disponibles es bas-tante amplia. Desde un sencillo (o no tanto, según semire) guante capaz de producir pequeñas vibracionesen la yema de los dedos para proporcionar la sensaciónde que estamos agarrando algo con una determinadatextura, hasta complejos exoesqueletos capaces de au-mentar nuestras capacidades físicas de forma artificial.
Como hemos dicho, estos sistemas son más comunesen el ámbito de la realidad virtual, donde no exis-te nada real y ser capaces de transmitir la sensaciónde tocar algo incrementa el realismo de la simulaciónenormemente.
GUSTO, OLFATO, SENTIDO COMÚN
Y hasta aquí hemos llegado. El olfato y el gusto sonlos grandes discriminados de la investigación sensorial.Existen investigaciones y resultados muy prometedo-res, sin embargo, a día de hoy, distan mucho de serportables o de poder funcionar con una pequeña ba-tería.
Finalmente, está el más importante de todos los sen-tidos. El sentido común. Sí, no es tontería, al final,las cosas tienen que tener sentido y muchas veces,por “güay” que parezca alguna solución puede que noresulte práctica en absoluto o que una obsesión pormimetizar el comportamiento humano nos lleve a so-luciones poco viables, sobre todo cuando se intentanabordar antes de que llegue su momento.
Ojo, que no estamos hablando de investigación, sinode soluciones reales, que puedan ser utilizadas en elmundo real. Ahí el sentido común es fundamental.
APLICACIONES AR VISUALES
Bueno, tras esta breve introducción y reivindicacióndel espíritu más general de la Realidad Aumentada,vamos a empezar a centrarnos para poder empezara crear nuestras aplicaciones de realidad aumentada“mú rápido”.
En la actualidad, el términoRealidad Aumentada se utilizaexclusivamente en su vertientevisual.
Como dijimos más arriba, el término Realidad Au-mentada ha visto acotado su significado y hoy en díacuando escuchemos a alguien hablar de Realidad Au-mentada se estará refiriendo a sistemas AR visuales.Estos sistemas son los más sencillos de entender, esta-mos viendo el resultado directamente, y los que másse han desarrollado en los últimos tiempos. Por esaúltima razón es relativamente sencillo desarrollar unaaplicación AR muy fácilmente, utilizando herramien-tas disponibles en la actualidad.
Antes de meternos en harina un comentario más. Exis-ten básicamente dos tipos de aplicaciones AR visuales.
19| OCCAM’s Razor
MÚ RÁPIDO
A saber, las que ofrecen información al usuario en fun-ción de su posición y orientación, y las que reconocenalgún patrón o forma y proporcionan información aso-ciada al mismo. Las primeras se han hecho muy po-pulares en los nuevos teléfonos inteligentes. Estas pe-queñas bestias, además de un ordenador portatil, nosproporcionan un GPS, acelerómetros, cámara y unapantalla. Todo lo que necesitamos con su batería ycon un formato portable.
Las segundas también empiezan a estar disponiblesen estos dispositivos pero han tenido su origen en losordenadores de sobremesa y los laboratorios, ya quela posición del usuario no es tan crítica. En este ca-so, solamente es necesario disponer de una cámara. Elordenador captura las imágenes de la cámara, las pro-cesa en busca de un determinado patrón (este procesopuede ser bastante complejo... ya veremos más adelan-te), calcula la posición y orientación de dicho patróncon respecto a la cámara, y utiliza esa informaciónpara mostrar algún tipo de información asociado alpatrón.
Si asociamos la posición de la cámara a la posicióndel usuario, es decir, nos pegamos la cámara a la ca-beza, estaremos calculando la posición y orientacióndel usuario, de la misma forma que lo hacemos con elGPS, pero con unas restricciones diferentes.
Seguro que habéis visto este tipo de aplicaciones enmás de una ocasión, pero sino, no os preocupéis, yaque estas son las aplicaciones de las que os vamos ahablar en este artículo.
ARTOOLKIT
Para desarrollar nuestra aplicación de Realidad Au-mentada mú rápido vamos a utilizar la librería AR-
Toolkit.
ARToolkit fue inicialmente desarrollado por los La-boratorios de Tecnología Interacción Humana en laUniversidad de Washington (HIT Lab) y de la Uni-versidad de Nueva Zelanda (HIT Lab NZ).
Inicialmente se distribuyó como software libre con li-cencia GPL, pero a partir de la version 2.72.1, liberadaen 2007, el proyecto libre se cerró y se creó una compa-ñía para continuar con el desarrollo del sistema desdeuna óptica más comercial. Así que, la versión con laque vamos a trabajar nosotros es precisamente esa, laúltima versión libre de la librería.
De cualquier forma, esta librería marcó un hito en elmundo de la Realidad Aumentada y sirvió de punto departida para otras muchos clones que han aparecidodurante estos últimos años. Hablaremos de ellos unpoco más tarde.
INSTALANDO ARTOOLKIT
Lo primero que necesitamos hacer es instalar AR-Toolkit. Para ello descargamos las fuentes desdesu página web. ARToolkit nos permite utilizar mode-los VRML en nuestra aplicación a través de la libreríaOpenVRML. El problema es que la última versión li-
bre de ARToolkit está preparada para utilizar Open-VRML versión 0.16.
En el momento de escribir este artículo, la última ver-sión disponible de OpenVRML es la 0.18.X. El pro-blema es que la version 0.16 no compila en las distri-buciones modernas, y la versión 0.18 no funciona conARToolkit. No desesperemos, lo bueno del softwarelibre es que siempre hay opciones.
Tenemos dos posibilidades. O modificamos ARTool-kit para que funcione con la última versión de Open-VRML, o hacemos que la versión 0.16 de VRML com-pile en nuestro sistema. Nosotros hemos optado poresta última opción y generado un simple patch pararecompilar la versión 0.16. Podéis encontrar el par-che en el código fuente que acompaña a este artículo,disponible desde nuestra página web.
ARToolkit nos permitirá iniciar-nos en la AR Mú Rápido
Como algunos os habréis dado ya cuenta, existe unatercera opción. Simplemente no utilizar VRML. Afor-tunadamente el soporte VRML es opcional en la libre-ría y podemos obviarlo si no lo necesitamos en nuestraaplicación. La aplicación que vamos a desarrollar eneste artículo realmente no necesita OpenVRML, peroen el artículo queremos contaros como utilizar todo elpotencial de la librería.
Una vez dicho esto, vamos a compilar ARToolkit.
CONFIGURANDO LA LIBRERÍA
ARToolkit proporciona algunas opciones que debemosseleccionar antes de compilarla. Esta configuración larealiza el script Configure, el cual nos hará una seriede preguntas sobre nuestras preferencias.
Lo primero que tendremos que elegir es el driver decaptura de vídeo. El script nos proporciona cinco op-ciones:
Select a video capture driver.1: Video4Linux2: Video4Linux+JPEG Decompression (EyeToy)3: Digital Video Camcoder through IEEE 1394 (DV Format)4: Digital Video Camera through IEEE 1394 (VGA NONCOMPRESSED
Image Format)5: GStreamer Media Framework
Enter :
Nuestra elección dependerá de la cámara que ten-gamos disponible. En caso de duda probad conGStreamer ya que esta opción proporciona distin-tas posibilidades para adquirir video. Por ejemplo, sivuestra cámara utiliza v4l2, como los dispositivos uvcbastante comunes estos días, la primera opción no fun-cionará, pero Gstreamer sí.
En el peor de los casos, Gstreamer nos permitirá uti-lizar como fuente un vídeo pregrabado almacenado enun fichero, que no es que sea lo mejor, pero es algocon lo que trabajar.
OCCAM’s Razor | 20
MÚ RÁPIDO
Tras la configuración del sistema de captura de vídeo,el script nos hará dos preguntas más:
Do you want to create debug symbols? (y or n)Enter : nBuild gsub libraries with texture rectangle support? (y or n)GL_NV_texture_rectangle is supported on most NVidia graphics cardsand on ATi Radeon and better graphics cardsEnter : y
PROBANDO... PROBANDO... 1,2,3
A la primera pregunta nosotros hemos respondido“no”. A no ser que pretendáis depurar ARToolkit, estaopción no debería ser necesaria. La segunda depen-derá de la tarjeta gráfica que utilicemos. Como nosinforma el script, para tarjetas nVidia y ATI podemosresponder “yes”.
En nuestro caso estamos utilizando una tarjeta Intely hemos respondido “y”. De hecho, con nuestra confi-guración GStreamer y tarjeta Intel, responder “no” haesta pregunta hace que la librería se estrelle al probarlos ejemplos.
ARToolkit nos ofrece distintasopciones para la captura de vídeo,durante su configuración
Para saber si la extensión está disponible en vuestrosistema, podéis ejecutar el siguiente comando:
$ glxinfo | grep texture_rectangle
Ya solo falta hacer “make”.
Ahora estamos en condiciones de probar el resultadode nuestro trabajo. En el directorio bin encontrare-mos diferentes programas de ejemplo que nos van apermitir comprobar si todo está en orden.
El primero que probaremos es videoTest. Este pro-grama simplemente muestra el vídeo capturado por lacámara. En principio debería funcionar sin más, perosi tenemos varias cámaras instaladas o estamos utili-zando uno de los drivers que necesitan configuracionesespeciales, como es el caso de GStreamer, necesitamosdecirle a ARToolkit como queremos que capture lasimágenes.
Para ello utilizaremos la variable de entornoARTOOLKIT_CONFIG. En la documentación de ARTool-kit podéis encontrar información detallada de las op-ciones disponibles para los diferentes drivers. Comoestamos utilizando GStreamer, nuestros parámetrosserían estos:
$ export ARTOOLKIT_CONFIG="v4l2src device=/dev/video1 ! \video/x-raw-yuv,width=640,height=480 ! \ffmpegcolorspace ! \capsfilter caps=video/x-raw-rgb,bpp=24 ! \identity name=artoolkit ! fakesink"
¿Qué significa todo eso?. Bien, de hecho ese rollo deahí arriba es una configuración de pipes de GSTreamer.
La primera parte de la configuración es la fuente devideo, en nuestro caso estamos utilizando una cámaracon driver V4L2. Además estamos utilizando la segun-da cámara del sistema (/dev/video1). Nuestro orde-nador de test es un portátil con una webcam inte-grada. Lamentablemente la cámara integrada es muymala, y estamos utilizando una segunda cámara USBpara estas pruebas.
La siguiente línea configura el formato de la fuentede vídeo, vamos, de nuestra cámara. En este caso es-tamos utilizando un formato YUV para los datos yqueremos una resolución VGA estándar.
A continuación pasamos los datos de la cámara porel filtro ffmpegcolorspace que nos permite transfor-mar los datos en formato YUV en datos RGB, queson los que le gustan a OpenGL. Para forzar la con-versión al formato que necesitamos utilizamos un ele-mento capsfilter a continuación con el que limitarel formato de los datos..
Finalmente, la última línea es necesaria por ARTool-kit, para acceder a los datos de la imagen capturada.
Leyendo un poco sobre GStreamer, tendréis un mon-tón de diversión asegurada... No os olvidéis de enviar-nos vuestros experimentos.
AR... AR FIN
Vale, ya van siendo horas de que veamos unpoco de ARcción. Para ello tenemos que ha-cer dos cosas. En primer lugar abrir el fichero../patterns/pattHiro.pdf, con nuestro visor dePDFs preferido. A continuación, y sin mediar pala-bra lanzamos el programa simpleTest en el directoriobin.
Ahora solo tenemos que enfocar la cámara hacia elvisualizador de PDFs, y un bonito cubo azul aparece-rá sobre el PDF. Como habréis comprobado el patrónaparece también en esta página, así que si estáis le-yendo el artículo mientras hacéis estas pruebas podéissaltaros el primer paso.
21| OCCAM’s Razor
MÚ RÁPIDO
Aplicación de Ejemplo SimpleTest Funcionando!
Ahora que todo está funcionando perfectamente, sihabéis recompilado OpenVRML en el directorio bin
podréis encontrar una aplicación simpleVRML que per-mite asociar ficheros VRML a diferentes patrones.
En el fichero bin/Data/object_data_vrml encontra-réis el mapping entre patrones y modelos VRML uti-lizado por simpleVRML. Añadir vuestros propios mo-delos es una cuestión de editar una línea de texto :)
NUESTRA PRIMERA APLICACIÓN AR
Los ejemplos que vienen con ARToolkit, ya nos per-miten hacer algunas cosillas, pero para desarrollarnuestra propia aplicación AR, necesitamos tener máscontrol. Afortunadamente para nosotros, la librería esmuy fácil de usar como veremos a continuación.
Vamos a comenzar con una versión simplificada desimpleTest que nos va a permitir introducir los prin-cipales elementos de este tipo de aplicaciones y lasfunciones que proporciona ARToolkit para facilitar-nos la vida.
Comencemos con la función main la primera que seejecuta.
i n t main ( i n t argc , char ∗∗ argv ){
g l u t I n i t (&argc , argv ) ;
i n i t ( ) ;
arVideoCapStart ( ) ;argMainLoop ( NULL, NULL, mainLoop ) ;
re turn ( 0 ) ;}
Lo primero que vemos es que nuestro ejemplo, al igualque todos los otros ejemplos distribuidos con ARTool-kit utiliza GLUT para sus gráficos 3D. Como veremosen seguida, es muy sencillo utilizar cualquier otro mé-todo para inicializar OpenGL, glx, SDL, lo que másrabia os dé.
A continuación llamamos a la función init encargadade inicializar ARToolkit. En seguida veremos que eslo que hace. Tras ello inicia la captura de vídeo conla cámara que hayamos configurado e inicial el bucleprincipal de la aplicación en el que ejecutaremos lafunción mainLoop por cada paso del bucle.
INICIALIZANDO ARTOOLKIT
Como os adelantábamos unas líneas más arriba, lafunción init es la encargada de inicializar ARTool-kit. ¿Y en qué consiste esa inicialización?. Veámosloutilizando el código de la función.
Izquierda: simpleVRML — Derecha: Patrones Hiro y Kanji impresos
OCCAM’s Razor | 22
MÚ RÁPIDO
La función de inicialización necesita algunos paráme-tros. En nuestro sencillo ARminimo, los hemos de-clarado como variables globales que os mostramos acontinuación.
char ∗ vconf = "" ;
i n t xs i ze , y s i z e ;char ∗cparam_name = DDIR "/camera_para . dat " ;ARParam cparam ;char ∗patt_name = DDIR "/patt . h i r o " ;i n t patt_id ;
Lo primero que nos encontramos es la cadena vconf
que utilizaremos para la configuración del sistema devídeo. De hecho, esta cadena va a estar vacía, lo quesignifica que ARToolkit debe utilizar el contenido dela variable ARTOOLKIT_CONFIG para configurar el sis-tema de captura de imágenes.
Las variables xsize e ysize las utilizaremos para ob-tener el tamaño de la imagen que estamos capturando.En un momento veremos como los utilizamos.
El siguiente parámetro es cparam_name. Este paráme-tro es el nombre de un fichero que contiene los pará-metros de configuración de la cámara. El que estamosutilizando nosotros viene con ARToolkit, y en generaldebería funcionar. En caso contrarío sería necesarioproducir uno nuevo para nuestra cámara. La docu-mentación de ARToolkit nos explica como hacerlo.
La constante DDIR la pasamos desde el Makefile, conla opción -D. Si tenéis vuestro fichero de cámara enun lugar bien conocido, podéis sustituir esta constantepor ese directorio.
Los parámetros de cámara que leemos del fichero an-terior los almacenaremos en la variable cparam.
Finalmente, necesitaremos dos variables más. La pri-mera contiene el nombre del fichero que contiene elpatrón que queremos utilizar en nuestra aplicación.En nuestro caso se trata del patrón Hiro. Una vezcargado en memoria ese patrón, nos referiremos a élutilizando un identificador entero que almacenamosen la variable patt_id.
Tras declarar todas estas variables vamos a ver comolas utilizaremos para inicializar ARToolkit. El códigode la función init se muestra a continuación:
s t a t i c void i n i t ( void ){
ARParam wparam ;
i f ( arVideoOpen ( vconf ) < 0 ) e x i t ( 0 ) ;i f ( a rV ideoInqS i ze (&xs i ze , &y s i z e ) < 0 )
e x i t ( 0 ) ;
i f ( arParamLoad(cparam_name , 1 , &wparam) < 0 ){
p r i n t f ( "Camera parameter load e r ro r ! ! \ n" ) ;e x i t ( 0 ) ;
}
arParamChangeSize (&wparam , xs i ze , ys i ze ,&cparam ) ;
arInitCparam ( &cparam ) ;arParamDisp ( &cparam ) ;
i f ( ( patt_id=arLoadPatt ( patt_name ) ) < 0 ) {p r i n t f ( " pattern load e r ro r ! ! \ n" ) ;e x i t ( 0 ) ;
}
a r g I n i t ( &cparam , 1 . 0 , 0 , 0 , 0 , 0 )}
Lo primero que hacemos es inicializar el sistema decaptura de vídeo, terminando la aplicación si se produ-ce cualquier error. Como ya os comentamos, en nues-tro caso vconf es una cadena vacía ya que nosotrosestamos utilizando el método de la variable de entornopara esto.
A continuación, le preguntamos al sistema de vídeocual es el tamaño de las imágenes que vamos a cap-turar. Estos valores los utilizaremos en un momentopara terminar de inicializar la librería.
Es el momento de leer el fichero de configuración decámara, lo que conseguimos con una rápida llamada aarParamLoad con la que, de paso, almacenamos estosparámetros en una variable local.
Para finalizar la inicialización, actualizamos nuestrosparámetros leídos del fichero, con el tamaño de la ima-gen capturada, almacenando el resultado en la varia-ble cparam que contendrá nuestra configuración final.
La variable cparam se utiliza entonces para inicializarARToolkit para nuestra cámara de acuerdo al tamañode las imágenes que vamos a capturar. A modo in-formativo, mostramos estos parámetros utilizando lafunción arParamDisp.
PATRONES
Todavía nos falta un paso más para inicializar el sis-tema. Cargar los patrones que queremos utilizar ennuestra aplicación. En nuestro ejemplo vamos a uti-lizar un solo patrón que cargaremos con la funciónarLoadPatt. Esta función nos devolverá un númerocon el que poder identificar este patrón en nuestroprograma.
Si nuestra aplicación necesitara más patrones,. este esel momento de cargarlos.
Con esto, ya solo nos queda llamar a la funciónargInit para que ARToolkit quede completamenteinicializada.El segundo parámetro de la función es unfactor de escala. El valor 1.0 significa que la imagenque mostraremos en la pantalla de nuestro ordenadortendrá el mismo tamaño que la imagen capturada. Sile diéramos el valor 2.0, la imagen que mostraríamosen la pantalla sería el doble de la que estamos captu-rando.
El resto de parámetros probablemente no los necesi-téis, pero si tenéis mucha curiosidad echadle un ojoal fichero include/AR/gsub.h en las fuentes de AR-Toolkit.
23| OCCAM’s Razor
MÚ RÁPIDO
BUCLE PRINCIPAL
Ahora que todo está listo para funcionar, tenemos quehacerlo funcionar. Y esto lo conseguimos con la fun-ción mainLoop que introdujimos al principio de nues-tro ARminimo.
Esta función se ejecuta por cada ciclo del bucle princi-pal, típicamente por cada cuadro de la escena 3D quedibujamos en la pantalla. Aquí está nuestra mainLoop:
s t a t i c void mainLoop( void ){
ARUint8 ∗ i ;ARMarkerInfo ∗marker_info ;i n t marker_num ;
i f ( ( i =(ARUint8∗) arVideoGetImage ( ) ) == NULL){
a rUt i l S l e ep ( 2 ) ;re turn ;
}
argDrawMode2D ( ) ;argDispImage ( i , 0 ,0 ) ;
i f ( arDetectMarker ( i , thresh , &marker_info ,&marker_num ) < 0 ) {
cleanup ( ) ;e x i t ( 0 ) ;
}
arVideoCapNext ( ) ;
procesa_markers ( marker_info , marker_num ) ;
argSwapBuffers ( ) ;}
Pues bien, lo primero que hacemos es leer una imagende la cámara, si es que hay alguna disponible. En ca-so contrario, esperamos un poquito e iniciamos otrociclo.
Una vez que tenemos la imagen en nuestro vec-tor i, la dibujamos inmediatamente en pantalla. Pa-ra ello, primero activamos el modo 2D utilizandoargDrawMode2D y luego mostramos la imagen conargDispImage.
Lo siguiente que podemos hacer, una vez tenemos unaimagen de la cámara, es detectar nuestros markers opatrones en la imagen, y esto sí que es muy senci-
llo, basta con llamar a la función arDetectMarker.La función recibe como parámetro la imagen quehemos capturado, seguido de un umbral de detec-ción, un puntero a un vector de elementos del tipoARMarkerInfo, y un entero en el que nos devolverá elnúmero de markers detectados en la imagen.
En nuestro ejemplo, al igual que en los distintos ejem-plos que podemos encontrar en le paquete ARToolkit,el umbral se fija normalmente a un valor de 100. Es-te parámetro permite ajustar el proceso de conversiónde la imagen de color a monocromo (blanco o negro).Más o menos, los pixels por encima de este valor seránblancos y los que estén por debajo serán negros... sim-plificando el proceso mucho. Los más curiosos podéisecharle un ojo a este artículo.
En este punto ya hemos terminado con la imagen ypodemos olvidarnos de ella. Es el momento de decirleal sistema de video que empiece a capturar la siguien-te imagen mientras nosotros terminamos algunas co-sillas.
Esas cosillas las vamos a hacer en la funciónprocesa_markers, tras la cual actualizaremos la pan-talla con una llamada a argSwapBuffer.
BOTONES
Ya solo nos quedan dos funciones por comentar. Unaque analiza los patrones que hemos encontrado en laimagen, y otra que pinta algo en la pantalla basándoseen los resultados de las etapas anteriores.
Para ilustrar estos dos pasos, vamos a comenzar conel ejemplo más sencillo posible: Un botón. Como sesuele decir y para muestra un botón :).
Nuestro botón lo implementaremos tal que así. Su-pondremos que un patrón será normalmente visible,de forma que cuando no lo detectemos, supondremosque hay algo bloqueando la imagen y por tanto dire-mos que el botón ha sido pulsado.
Más sencillo no se puede, sin embargo, este simpleejemplo nos va ha permitir introducir todos los con-ceptos necesarios para que podáis desarrollar vuestraspropias aplicaciones de realidad aumentada.
Izquierda: Patrón Visible (Botón Normal) — Derecha: Patrones Ocluído (Botón Pulsado)
OCCAM’s Razor | 24
MÚ RÁPIDO
PROCESANDO MARKERS
Es momento de añadir la lógica de nuestro botón.La función procesa_markers es la encargada de ello.Aquí la tenéis.
voidprocesa_markers (ARMarkerInfo ∗mi , i n t num){
i n t j , k ;
/∗ check f o r o b j e c t v i s i b i l i t y ∗/k = −1;f o r ( j = 0 ; j < num; j++ ) {
i f ( patt_id == mi [ j ] . i d ) {i f ( k == −1 ) k = j ;e l s e i f ( mi [ k ] . c f < mi [ j ] . c f ) k = j ;
}}
i f ( k == −1 ) {i f ( boton ) {p r i n t f ( "Botton Pulsado \n" ) ;boton = 0 ;
}return ;
}
boton = 1 ;
arGetTransMat(&mi [ k ] , patt_center ,patt_width ,patt_trans ) ;
draw ( ) ;}
Si recordáis, los parámetros que recibe esta funciónson la lista de patrones detectados en la imagen cap-turada por la cámara así como su número. Así que loque vamos a hacer es buscar entre los patrones detec-tados nuestro patrón de referencia.
Obtener la posición de los mar-kers es muy fácilcon ARToolkit.
En este caso el bucle no es realmente necesario, yaque solo tenemos un patrón (hiro). Sin embargo lo he-mos dejado por conveniencia para que os resulte mássencillo hacer experimentos con distintos patrones.
Tras el bucle, la variable k valdrá -1 si no se ha encon-trado nuestro patrón (patt_id)o su índice en la tablasi el patrón aparece en la imagen.
Con esta información implementamos la lógica denuestro botón. Si el patrón a desaparecido (k = -1)y hace nada estaba allí (boton = 1) entonces es quehemos pulsado el botón. Si el patrón aparece en laimagen, entonces el botón está disponible y actualiza-mos la variable botón.
Finalmente, le pedimos a ARToolkit que nos de lainformación asociada al patrón k (nuestro patrón deinterés), tanto para representarla en 2D (centro y an-cho) o en 3D (matriz de transformación). Estos valoreslos almacenamos variables globales por simplicidad.
Una vez que tenemos nuestra matriz, ya solo nos que-da pintar algo en la posición del patrón que acabamosde localizar.
PINTANDO NUESTRO BOTÓN
Nuestro botón tomará la forma de un triángulo conuno de sus vértices coloreados. Exactamente, el trián-gulo que aparece en la figura de la página anterior.
Veamos como pintar esta figura con la informacióncontenida en la variable patt_trans, que no es otracosa que la posición y orientación de la cámara.
Esta es la función que dibuja el triángulo.
s t a t i c void draw ( void ){
double gl_para [ 1 6 ] ;
argDrawMode3D ( ) ;argDraw3dCamera ( 0 , 0 ) ;
argConvGlpara ( patt_trans , gl_para ) ;glMatrixMode (GL_MODELVIEW) ;glLoadMatrixd ( gl_para ) ;
g l T r an s l a t e f ( 0 . 0 , 0 . 0 , 25 . 0 ) ;
g lBegin (GL_TRIANGLES) ;g lCo l o r3 f ( 0 , 0 , 1 ) ;g lVertex3 f (−30 ,−30 ,0);
g lCo l o r3 f ( 0 , 0 , 1 ) ;g lVertex3 f (30 , −30 ,0) ;
g lCo l o r3 f ( 1 . 0 , 0 , 0 ) ;g lVertex3 f ( 0 , 5 0 , 0 ) ;glEnd ( ) ;
}
Lo realmente importante de esta función son las cin-co primeras líneas. El resto de la función es códigoOpenGL estándar para dibujar un triángulo. De hechopodemos sustituir este triángulo por cualquier otracosa; un modelo VRML utilizando OpenVRML, o fi-guras más complejas con luces, iluminación e inclusoshaders.
Veamos en detalle la parte de ARToolkit. La prime-ra función se encarga de activar el modo dibujo en3D. Recordad que lo primero que hacíamos tras cap-turar la imagen era activar el modo 2D para dibujaresa imagen en el fondo. A efectos prácticos, lo quetodo esto significa es que estamos cambiando de unaproyección ortográfica para 2D a una proyección enperspectiva para 3D. Las funciones argDrawMode3D yargDrawMode2D realizan este cambia pero asegurán-donos que cuando pintemos algo en 3D su posicióncorresponderá con el marker en la imagen 2D.
Ahora solo tenemos que transformar la matriz quenos ha devuelto ARToolkit al formato que esperaOpenGL.
La matriz que nos devuelve ARToolkit es realmen-te la posición y orientación de la cámara así que siasignamos esta matriz a la matriz MODELVIEW deOpenGL, estaremos posicionando la cámara virtual enla posición correcta.
25| OCCAM’s Razor
MÚ RÁPIDO
Eso es lo que hace la llamada a glLoadMatrixd.
Observad que hemos añadido una traslación en el ejez para que nuestro triángulo aparezca por encima delmarker y justo en el mismo plano.
Un último comentario sobre la función de dibujo. Nor-malmente, y así lo veréis en la mayoría de los ejemplosque vienen con ARToolkit, justo después de activar elmodo de dibujo en 3D, tendréis que restaurar el es-tado OpenGL que necesitéis para vuestra aplicación.Cosas como activar el z-buffer o la iluminación, asig-nar materiales, etc.
Nosotros hemos eliminado todo eso para mantener loslistado pequeños, pero si pretendéis hacer algo máscomplicado que nuestro simple botón echadle un ojoa los ejemplos de ARToolkit y a esta página.
INTERFACES TANGIBLES
Como nuestra demo del botón es un poco escasa, va-mos a introducir un par de conceptos más y Aumentarnuestra demo para que haga algo útil. Para ello vamosa introducir el concepto de Interfaces Tangibles
Los interfaces tangibles son un tipo especial de siste-mas AR en los que la interacción con el mundo real ylos objetos virtuales se restringe, generalmente, a unasuperficie en lugar de permitir una interacción libreen el espacio tridimensional. Esta restricción facilitala interacción con el sistema utilizando objetos reales.
Estos sistemas suelen utilizar un superficie multi-toque (Multi-Touch Screen) sobre la que se manipu-lan objetos reales con algún tipo de identificación ycomportamiento. Si bien ese es el más común de losescenarios, es posible construir este tipo de sistemascon nuestro modesto ARToolkit.
Para ilustrar lo que acabamos de comentar vamos amodificar nuestro simple botón para convertirlo en uninterfaz tangible con el que modificar el volumen denuestro ordenador :).
En los interfaces tangibles la in-teracción entre mundo real y vir-tual se restringe a las 2D.
En este sencillo ejemplo vamos a suponer que el sis-tema de audio de nuestro ordenador está controladocon PulseAudio. Simplemente necesitamos elegir uninterfaz y este parece ser el más común últimamente.
La modificación del volumen la haremos utilizando lafunción estándar system de forma que modificar elprograma para que funcione con otras configuracionesdebería ser muy sencillo.
Así que todo lo que necesitamos saber es como decir-le a PulseAudio que queremos modificar el volumendel sistema. Afortunadamente para nosotors (bueno,realmente lo hemos hecho a propósito :), PulseAudioincluye una conveniente herramienta de línea de co-
mandos llamada pacmd que nos va a salvar el día. Elcomando que nos interesa es este:
pacmd set-sink-volume 0 100
La función system nos permiteconectar con el control de volu-men de PulseAudio.
Básicamente le estamos diciendo a pulse audio queponga el volumen del sink 0 al valor 100.
CONTROL DE VOLUMEN TANGIBLE
Con todos estos elementos solo necesitamos modificarnuestra función procesa_markers añadiendo el códi-go que se muestra a continuación justo antes de lallamada a la función draw.
a = atan2 ( patt_trans [ 2 ] [ 0 ] ,patt_trans [ 2 ] [ 1 ] ) ;
i f ( a < 0) a += (2 ∗ M_PI) ;
i n t va l = round ( ( a ) / (2 ∗ M_PI) ∗ 65535 . 0 ) ;
char c [ 1 0 2 4 ] ;s n p r i n t f ( c , 1024 , "pacmd set−s ink−volume 0 %d" ,
va l ) ;system (cmd ) ;
Lo que estamos haciendo es calcular la rotación delpatrón con respecto al eje Z a partir de la matrizde transformación que nos devuelve ARToolkit. Luegoconvertimos el resultado en un valor lineal entre 0 y65535, que es el rango de valores que espera pacmd.Una llamada a system y ya estamos listos
Solo nos falta un pequeño toque en la función draw.Suponiendo que el valor a que calculamos en el peda-zo de código anterior es una variable global, podemosmodificar el color del último vértice de nuestro trián-gulo para nos de una idea de como de alto está nuestrovolumen.
glColor3f(fabs(a) / (2 * M_PI),0,0);
Con esto terminamos nuestra breve introducción a larealidad aumentada con ARToolkit. Hay varias fun-ciones que no hemos comentado, pero no os queremosquitar toda la diversión. Las bases os las hemos conta-do, y la diferencia entre nuestro sencillo interfaz tan-gible y cualquier otra aplicación AR está en vuestrasmanos.
Por ejemplo, nosotros hemos ampliado el ejemplo quedescribimos en este artículo para improvisar un re-productor MP3 con controles wireless :), conectandonuestro botón con mplayer a través de su modo escla-vo. Visitad nuestro canal de YouTube o los recursosal final del artículo para verlo en acción.
OCCAM’s Razor | 26
MÚ RÁPIDO
Resultado Final de nuestro interfaz tangible para mplayer
SIFT, SURF Y COMPAÑÍA
No podemos terminar este artículo sin daros algu-nas indicaciones sobre como funcionan los sistemas derealidad aumentada más actuales que ya no necesitanmarkers o patrones como los que hemos utilizado eneste ejemplo.
Realmente no es que no utilicen patrones, sino queahora, los patrones son imágenes arbitrarias y por lotanto más fácil de integrar en nuestras aplicaciones.
En general todos esto sistemas se basan en algún algo-ritmo de extracción de rasgos de imagen (image fea-tures en inglés), algo así como descubrir los puntosinteresantes de las imágenes y asignarles un vector devalores que luego puede ser utilizado para reconocertanto la imagen original como su posición y orienta-ción.
Existen varios de estos algoritmos, pero quizás el máspopular, por sus buenos resultados es SIFT (Scale In-variant Feature Transform o Transformación de rasgosinvariante con la escala). El algoritmo fue publicadopor David Lowe allá por 1999, pero lo que realmen-te revolucionó el mundo de la realidad aumentada fueotro algoritmo, conocido como SURF (Speeded Up Ro-bust Feature Rasgos Robustos Acelerados ).
Conceptualmente ambos algoritmos son similares y
ambos se basan en la extracción de features de laimagen, pero SURF fue diseñado para funcionar muyrápido y eso era fundamental en las aplicaciones deRealidad Aumentada.
Lo interesante de estos algoritmos es lo robustos queresultan frente a variaciones de escala, rotación e ilu-minación de las imágenes (dentro de unos márgenes),lo que es fundamental en aplicaciones que se no seutilizarán en entornos controlados.
Existen otras muchas técnicas y probablemente apare-cerán más. Las páginas de Wikipedia sobre detecciónde rasgos describen buena parte de ellos para aquellosde vosotros que queráis profundizar en el tema.
RECAPITULACIÓN
Aunque ARToolkit no es la librería de realidad au-mentada más avanzada que nos podemos encontraren 2012, sigue siendo un excelente punto de entradaen este apasionante mundo y un trampolín hacia so-luciones más complejas.
Aún con sus limitaciones, ARToolkit permite crearmuchas e interesantes aplicaciones AR y sobre todo,recordad que la tecnología no es lo más importante.Lo importante es la idea.
RECURSOS
Página Oficial de ARToolkithttp://www.hitl.washington.edu/artoolkit/
http://www.hitl.washington.edu/artoolkit/documentation/vision.htm
http://www.hitl.washington.edu/artoolkit/documentation/devstartup.htm
Páginas Wikipedia de Referenciahttp://es.wikipedia.org/wiki/Realidad_aumentada
http://en.wikipedia.org/wiki/Brain-computer_interface
http://en.wikipedia.org/wiki/Scale-invariant_feature_transform
http://en.wikipedia.org/wiki/SURF
27| OCCAM’s Razor
HISTORIA
Historia de la TelevisiónHomenaje Póstumo a la televisión analógica
por Fernando Martín Rodríguez
Cuando David (el director de esta revista)me preguntó: “¿Qué hacemos esta vez para lasección de historia?”, la verdad es que me sor-prendió. Ya sabía que me había convertido enhistoriador tecnológico aficionado (que me per-donen los historiadores de verdad), pero: ¿He-mos llegado a consolidar una sección fija en larevista? Posiblemente, la respuesta es sí ya queen cuatro números publicados hay tres artículosde esta temática. La serie sobre biometría tuvootros tres artículos, éste es el cuarto de la “sec-ción de historia”.
Y. . . ¿Sobre qué escribir? En aquel momento era inmi-nente el “apagón analógico” del 3 de abril de 2010, poreso la decisión tomada fue ésta: escribir sobre la his-toria de la televisión (sí, a veces, los artículos tienen“un poco” de retardo). Tal vez, hasta podríamos po-ner un subtítulo: “Homenaje póstumo a la televisiónanalógica”.
EL SUEÑO IMPOSIBLE
He “plagiado” el título de esta sección de un textodel profesor (y compañero) Xulio Fernández Hermi-da. Con él se refiere a que los primeros expertos encomunicaciones quisieron llegar más allá del telégra-fo (primer sistema de telecomunicación de la historia)y ser capaces de “llevar la realidad que ocurre en unlugar a otro lugar alejado”.
El teléfono (año 1876) ya supuso un avance en ese sen-tido, porque permite comunicarse a las personas de laforma más habitual para ellas (hablando). Por eso fue(y sigue siendo) el sistema de telecomunicación másutilizado de la historia.
Pero faltaba algo diferente. También había interés porser capaz de transmitir ciertos contenidos: teatro, mú-sica, deporte, otros espectáculos. . . La radio nació en1920 (aunque ya hubo experimentos desde 1906). Sehabía cumplido parte del sueño: un espectáculo produ-cido en un teatro podía ser enviado a muchas personasen sus casas. ¿Qué faltaba? Todos lo sabemos: las per-sonas recibimos la mayor parte de la información pordos sentidos: la vista y el oído. Se había conseguido“acercar los oídos de los usuarios al espectáculo” pero“faltaban los ojos”.
El sueño se empezó a completar en 1897 cuando CarlFerdinand Braun inventó el osciloscopio (1897) y con
él el tubo de rayos catódicos. Este invento junto aldescubrimiento de las propiedades electroópticas delselenio (su resistencia varía con la luz que recibe) per-mitió al ruso Vladimir Zworykin desarrollar el iconos-copio, el primer tubo de cámara práctico (año 1923).El tubo de cámara fue la primera tecnología de cap-tura de imagen en movimiento. Se basaba en un tubode rayos catódicos y una resistencia variable con laluz. No fue sustituido hasta la década de los noventa,cuando aparecieron los sensores de imagen de estadosólido (CCD’s).
La tecnología de los tubos de rayos catódicos tambiénse empleó en receptores de televisión y monitores deordenador (tubos de imagen) hasta finales de los no-venta, en esa época la tecnología de cristales líquidosLCD alcanzó la calidad suficiente para ser una opciónviable. También en ese momento aparecieron los pri-meros monitores de plasma.
El considerado por todos como padre de la televisiónes John Logie Baird que en 1927 logró transmitir unaseñal a una distancia de 438 millas entre Londres yGlasgow, para ello introdujo una señal analógica enun cable telefónico interurbano.
En 1937 estaba en el mercado en Inglaterra un recep-tor de TV de 405 líneas. La empresa que lo fabricabaera la Marconi-EMI (fundada por el conocido inven-tor Guillermo Marconi). A partir de aquel momento elsueño se había cumplido, siempre parcialmente, por-que ver un espectáculo por televisión nunca será lomismo que estar allí. Por supuesto, este nuevo servi-cio experimentó muchas mejoras y cambios y eso serálo que comentaremos en el resto del artículo.
LA SEÑAL DE TV BLANCO Y NEGRO
La señal original de televisión dependía mucho del sis-tema concebido para generarla: el tubo de cámara. Untubo de cámara, como vimos en el apartado anterior,es un caso particular de tubo de rayos catódicos. Es-to es: una cámara de vacío donde una gran diferenciade potencial provoca una descarga: un haz o flujo deelectrones a gran velocidad (esta “corriente” circulan-do por el vacío es lo que recibe el nombre de “rayocatódico”). En los tubos de televisión (tubo de cáma-ra y tubo de imagen) se utilizaban bobinas (bobinasde deflexión) para crear campos magnéticos capacesde dirigir el haz al punto deseado (nótese que existenelectrodos de “enfoque” que consiguen que el haz seaestrecho y directivo). En el tubo de imagen se obli-ga al haz a recorrer toda la superficie disponible porlíneas.
OCCAM’s Razor | 28
HISTORIA
Figura 2 - Funcionamiento del ojo.
Con eso se pretende obtener el brillo de cada puntode la imagen. Si os fijáis en el esquema de la figura 1,el circuito se “cierra” atravesando un conductor “foto-rresistivo” (hecho de selenio, material cuya resistenciacambia con la luz incidente). El tubo de cámara fun-cionaba así: en cada instante, el haz llega a un punto y“cierra” el circuito a través de ese punto (y la resisten-cia depende del brillo que llega a ese punto). Al igualque el ojo humano y que las cámaras de fotografía, unsistema óptico se encarga de formar una imagen sobreuna superficie fotosensible (la capa de selenio).
Figura 1 - Esquema del tubo de cámara.
Dado su origen tenemos una señal “barrida por líneas”,es decir: la señal va a ser una forma de onda analógicaproporcional al brillo de la imagen y que la recorrepor líneas. Nótese que hablamos de brillo (sensaciónde luminosidad de la luz, que aumenta con la energíatransportada por la misma) pero no de color, en ca-da punto tendremos un color gris del brillo adecuado;el brillo mínimo es el color negro y el máximo es elblanco.
En la figura 3, podemos ver que los tramos corres-pondientes a las diferentes líneas van separados pormínimos de tensión. Esos pulsos reciben el nombre desincronismos horizontales y ocupaban el 25 % del mar-gen dinámico (margen dinámico de una señal norma-lizada: 1 V). Nótese que se eligió un valor muy grandepara proteger los sincronismos (en un tiempo en quela electrónica no era muy avanzada). Durante el tiem-po que duran estos sincronismos (tiempo no activo deuna línea) el haz del tubo receptor vuelve a su po-sición horizontal inicial (en esos momentos el haz deelectrones está cortado, este tiempo también se llamatiempo de borrado o tiempo de retorno horizontal).
Figura 3 - Forma de onda de la señal de blanco y negro.
29| OCCAM’s Razor
HISTORIA
Durante el resto del tiempo (tiempo activo) la tensiónindica el brillo o luminancia de la imagen. Los valoresgrandes de tensión provocarán un haz de electronesgrande y un brillo grande (cercano al blanco), los va-lores pequeños de tensión provocarán haces débiles ypuntos oscuros (cercanos al negro).
Figura 4 - Tubo de imagen (monitor blanco y negro
con TRC). El haz de electrones cierra un circuito con
la capa de aluminio (ánodo) y la energía del impacto
es absorbida por el fósforo que emite luz de
intensidad proporcional a dicha energía.
Además de los sincronismos de línea (u horizontales)es necesario “señalizar” donde empieza y acaba cadaimagen. Para eso se han introducido una serie de lí-neas que no llevan información de imagen (líneas noactivas). Varias de esas líneas tienen perfiles de tensiónespecíficos que le sirven al televisor para identificarlasy así saber que ha acabado una imagen y va a empe-zar la siguiente. A estas líneas se les llama: líneas desincronismo vertical.
Las líneas de sincronismo vertical son líneas no acti-vas porque no tienen imagen (aunque son necesariaspara la sincronización de la señal). Además de estaslíneas no activas incluyeron muchas más: en la TV eu-ropea, de un total de 625 líneas por imagen se tienen576 activas y 49 no activas. El sincronismo verticalocupa 18 líneas. El exceso de líneas no activas (49-18= 31 líneas) se pensó para dejar espacio para usos fu-turos. En las primeras emisiones esas líneas estabanvacías (la señal era nula). Después, tuvieron variosusos: teletexto (señal digital), señales para el controlde calidad (por ejemplo, se pueden introducir sinusoi-des de diferentes frecuencias y se ve en qué estado sereciben, con lo que se tiene una idea de la respuestaen frecuencia de un canal) e incluso señales para con-trolar acceso a servicios de pago (sistemas de accesocondicional analógico como nagravision utilizado porCanal+ analógico).
Por último, en la figura 3 podemos ver que las líneasaparecen numeradas de una forma “extraña” (primerolas impares y después las pares). Eso se debe a que latasa temporal de imágenes entonces era relativamentebaja: 25 imágenes por segundo en Europa y 30 imá-genes por segundo en Estados Unidos. Este número
proporciona sensación de movimiento pero es insufi-ciente para evitar el “flicker” o parpadeo de la imagenen pantalla. Para evitar este problema se recurrió al“barrido entrelazado”: las líneas no van ordenadas demanera natural (1,2,3,4... ) sino divididas en dos sub-cuadros o campos: el primero formado por las impares(1,3,5...) y el segundo por las pares (2,4,6... ). Comoconsecuencia del entrelazado cada imagen supone dosrecorridos verticales de pantalla. Como consecuencia,el recorrido del haz de un tubo de cámara también eraentrelazado al igual que el de un tubo de imagen.
La tasa de imágenes de la televisión se eligió iguala la mitad de la frecuencia de la señal de corrientealterna (la corriente alterna oscila con 50 Hz en Eu-ropa y 60 Hz en Estados Unidos). Esta elección fuenecesaria para eliminar ciertas interferencias debidasa la red eléctrica. Además de eso, en Europa se eligióun sistema con 625 líneas por imagen (576 activas) yen Estados Unidos el sistema se diseñó con 525 líneas(480 activas).
LA TV COLOR: NTSC, PAL Y SECAM
Entre los años 40 y 50 la televisión en blanco y negrollegó a casi todo el mundo. Por ejemplo, en Españase empezó a emitir en 1956 (aunque se venían reali-zando pruebas desde 1952). El deseo de incorporar elcolor era natural entonces, y más con la experienciadel cine, que había logrado incorporar la tecnologíadel color en 1935.
En EEUU fue la cadena de TV CBS la que inició la in-vestigación fundando el comité NTSC (Nacional Tele-visión System Committee). Dicho comité data de 1930y pretendía encontrar una “extensión” a la señal blan-co y negro que permitiera emitir en color pero que,además, la señal fuese compatible con los televisoresblanco y negro existentes (esto es: que la señal se pu-diese visualizar, en blanco y negro, pero correctamentesin “interferencias del color”). El sistema NTSC no fueaprobado por la FCC (Comisión Federal de Comuni-caciones) hasta la década de los 50. El sistema NTSCse adoptó en Estados Unidos, gran parte de Latinoa-mérica y algunos países de extremo oriente: Japón,Filipinas. . .
En la historia de la TV en color, debemos mencionarlos trabajos realizados por el ingeniero mexicano Gui-llermo González Camarena que patentó un sistema decolor en 1940. Posteriormente, colaboró con investiga-dores norteamericanos en 1950. Fruto de su trabajose desarrolló el sistema “bicolor simplificado” con elque se emitió TV en color en México entre 1962 y1968. González Camarena murió en accidente de trá-fico en 1965. Su falta hizo que el sistema bicolor deja-ra de desarrollarse y que México decidiera pasarse alsistema NTSC (había además una gran presión paraadoptar un sistema “compatible con el resto del mun-do” ante el gran evento de la olimpiada de Ciudad deMéxico, 1968).
OCCAM’s Razor | 30
HISTORIA
Figura 5 - El espectro de la señal B/N ocupa 5 MHz de ancho de banda, pero si aumentamos la resolución
vemos que no es un espectro continuo sino que se trata de lóbulos separados.
En Europa se desarrolló el sistema PAL (Phase Alter-nate Line), que realmente es una mejora del sistemaNTSC, inventada por el investigador Walter Bruch enlos laboratorios de Telefunken (Hannover, Alemania)en 1963. El PAL ha sido el sistema de TV analógi-ca más extendido en el mundo. No sin variantes, fueadoptado en la mayor parte de Europa (excepto Fran-cia y Europa del este), Brasil, Argentina, Paraguay,Uruguay, gran parte de África (excepto países de ha-bla francesa), Australia, China, la India, Turquía ypaíses árabes. En España se utilizó en TV terrena,hasta el pasado 3 de abril de 2010 (aunque sigue enuso en algunas plataformas de TV por cable). Aun si-gue en uso en muchos países que no han completadola transición a TV digital. Es el sistema de TV conmás usuarios de la historia y, seguramente, todavía esel más visto del mundo.
El último sistema analógico del que hablaremos es elSECAM (Sequentiel Couleur Avec Mémoire) desarro-llado en Francia por Henri de France trabajando enla empresa Thomson (Boulogne, Francia). Realmente,es un sistema más antiguo que el PAL que se adoptóen Francia y países de su influencia: Marruecos, Tú-nez, Camerún. . . También fue adoptado por la antiguaUnión Soviética y por otros países del este de Europa.
Todos los sistemas de color analógicos se basan en ex-presar la señal en color como una señal en blanco ynegro (B/N) a la que se suma una “componente decolor”. Así se logra que los receptores blanco y negroreciban “su señal de siempre” y no se preocupen porla parte de color; el receptor en color deberá diseñarsepara detectar la parte de color. Una de las especifica-ciones de diseño fue que el ancho de banda total dela señal en color fuese el mismo de la antigua señalB/N, así se aprovecharían las antenas emisoras y to-da la infraestructura dedicada a llevar la señal a loscentros emisores (red terrestre de distribución). Estarestricción obliga a encontrar un “hueco” o zona sin in-formación (o sin mucha información) en la señal B/Ny, además, implica que el color realmente va a ser unaseñal interferente que puede provocar errores (sumarruido a la señal de brillo). Esa interferencia del colorsobre la luminancia, llamada cross-color, ha existidosiempre en la TV analógica. También hay una inter-ferencia de la señal de brillo (o luminancia) sobre elcolor: cross-luminancia.
Una imagen en color está formada por tres imágeneso señales: R, G y B que miden el “contenido” de ca-da punto luminoso en tres colores básicos o primarios:rojo, verde y azul.
Figura 6 - La señal de color (verde) se coloca en la parte de frecuencia alta donde la luminancia (verde) ya es
débil. Además, se modula de tal forma que los máximos no coincidan.
31| OCCAM’s Razor
HISTORIA
En el sistema NTSC se decidió utilizar una conversiónde las señales originales R, G y B según las siguientesfórmulas:
Y = 0,299R+ 0,587G+ 0,114BI = 0,595R− 0,274G− 0,321BQ = 0,211R− 0,522G+ 0,311B
Donde la señal Y corresponde con una señal B/N equi-valente a la imagen en color que tenemos. Las compo-nentes I y Q son la parte de color y serán añadidas ala señal B/N (señal principal).
La señal de TV en color reducela calidad de las componentes decolor
Fijaos que si tenemos R = G = B (que es lo queocurre con una señal gris, esto es: una imagen queya es blanco y negro como una película antigua) lascomponentes de color se anulas (I = Q = 0). A lasseñales I y Q se les aplicará una reducción de calidad(en analógico un filtrado paso-bajo) y se modularán enuna frecuencia de 3.58 MHz (subportadora de color)antes de ser sumadas a la señal principal.
Fijaos que se usa la idea de que la parte de color esmenos importante y se puede reducir su calidad (esaes una idea que se sigue utilizando en los sistemasdigitales). La subportadora de color se ha elegido deforma que la “interferencia” se sume en la parte me-nos significativa de la señal de luminancia. Además elvalor de esa frecuencia se eligió de forma que los má-ximos en el espectro de color (una vez modulados) nocoincidieran con los de luminancia “interferencia nodestructiva”.
La TV PAL utiliza la misma idea del sistema NTSC(modular el color con una sub-portadora auxiliar). Lasdiferencias son las siguientes:
PAL tiene 25 imágenes por segundo y 625 líneaspor imagen (frente a 30 imágenes por segun-do con 525 líneas cada una en NTSC). Desdesiempre, la TV europea ha tenido más resolu-ción pero menos imágenes por segundo que lanorteamericana.
PAL utiliza otras fórmulas para la transforma-ción del color:
Y = 0,299R+ 0,587G+ 0,114BU = 0,49(B − Y )V = 0,88(R− Y )
A veces, a estas componentes se les llama Y, Cb,Cr y cumplen la misma propiedad de las YIQ;si R = G = B (color gris), las componentes decolor U y V se anulan.
La portadora de color es de 4.43 MHz. La ma-yor resolución implica que se debe subir más enfrecuencia para llegar a la zona de componentesdébiles de luminancia.
La característica más definitoria del PAL (la quele da su nombre: Phase Alternate Line) es la al-ternancia en fase de la señal de color. Esto, bá-sicamente consiste en que la señal de color vamodulada con una fase en una línea y con faseopuesta en la siguiente. Los receptores PAL reci-ben ambas fases y promedian las señales demo-duladas. Con esto se consigue anular los erroresde color que aparecían, a veces, en el NTSC.
Por último, el sistema SECAM se basa en enviar al-ternativamente las dos componentes de color: en unalínea se envía U (Cb) y V (Cr) va en la siguiente. Eneste sistema, el color se modula en FM: al tener unasola componente por línea se puede utilizar un siste-ma de modulación más robusto pero con más gasto deancho de banda.
Algunos ingenieros dicen que el SECAM es un siste-ma inferior ya que la resolución en las componentes decolor se reduce a la mitad y los receptores tienen quealmacenar la línea anterior del componente que faltapara “repetirla”. Yo creo (y digo creo porque no mehe puesto a hacer simulaciones para demostrarlo) quela pérdida de resolución en el color no causa erroresimportantes (de hecho, también se hace en los siste-ma digitales) y, sin embargo, la mayor robustez de lamodulación FM hace a SECAM un sistema superior.Como la cuestión no parece resuelta (he encontradoopiniones en ambos sentidos pero ninguna parece de-finitiva, ni siquiera mayoritaria), es casi seguro que ladiferencia de calidad entre SECAM y PAL era muyleve. No puedo afirmarlo categóricamente porque nohe podido compararlos “en persona”.
Los principales sistemas de TVen color analógicos son NTSC,PAL y SECAM
Una cuestión polémica es por qué Francia adoptó elSECAM. Era un sistema de diseño más antiguo (y deorigen nacional) pero se adoptó para difusión cuan-do el PAL ya dominaba en Europa. Se dice que pudoinfluir cierto proteccionismo: adoptando un sistemadiferente se protege a la industria nacional de la lle-gada de equipos extranjeros (que acabaron llegandoya que a partir de los 90 los diseños de televisoresutilizaban chips decodificadores de vídeo capaces deentender PAL, NTSC y SECAM).
Algunos ingenieros norteamericanos bromeaban defi-niendo SECAM como “System Essentially Contrary tothe American Method”.
OCCAM’s Razor | 32
HISTORIA
El sistema NTSC (EEUU 1953) utiliza una codificación del color en cuadratura en la que la señal I vamodulada por cos(w0t) y la Q por sen(w0t). En este tipo de codificaciones el vector de color (o el númerocomplejo I+jQ) cumplen la siguiente regla:
Su módulo, s =√U2 + V 2 es proporcional a la saturación o “pureza” del color. Un color de alta
saturación tiene un porcentaje de blanco bajo. Mientras que si S es pequeña, el color tiene muchaparte de blanco.
Su fase, ϕ = tg−1(VU) es proporcional al tinte o matiz del color. El tinte es un ángulo que indica de
qué color (rojo, naranja ...) es el punto en cuestión. El origen (ϕ = 0) se suele poner en el rojo y existeuna figura llamada “vectorscopio” que nos indica la distribución de los colores.
Figura a1 - Vectorscopio, el tinte varía con el ángulo, la saturación crece al alejarse del centro.
El problema del sistema NTSC es que la acumulación de amplificadores en el camino de la señal puedegenerar un error constante en la fase de la señal en cuadratura. Eso genera un error constante en el tintey hace que las imágenes salgan con colores falsos. Los televisores norteamericanos tienen un mando paraajustar el tinte (H de “hue”, en inglés).Los diseñadores del PAL (1963) se propusieron evitar este problema. La solución fue alternar la fase de lacomponente en cuadratura. En la línea N se envía el color según la fórmula: Ucos(w0t)−V sen(w0t) y en lalínea N+1 se le cambia el signo a V: Ucos(w0t)+V sen(w0t). Eso dibujado en forma de vector podemos verloen la figura siguiente (en la mitad de las líneas enviamos el tinte cambiado de signo). Como el diseñadordel receptor ya sabe esta característica, lo que hace es cambiarle el signo a la componente V decodificadaen las líneas en que se le cambió el signo. Además, se hace el promediado de U y V entre el valor de la líneaactual y el valor correspondiente a la línea anterior (para ello los televisores PAL incorporan un circuito queretarda la señal 64 µseg, tiempo de línea de este sistema). Ese promediado es capaz de compensar erroresde tinte (figura 3.8) al precio de introducir errores mínimos ya que en vez de recibir el valor auténtico, seestá promediando el color con el de la línea anterior (dos píxeles más arriba debido al entrelazado), todofuncionará bien si la imagen es suave, suposición que suele ser cierta).
Figura a2 - Alternancia de fase en el sistema PAL (vista en polares: tinte, saturación).
Figura a3 - Corrección de un error de tiente α (negativo).
33| OCCAM’s Razor
HISTORIA
INTENTOS DE MEJORAR LA TELEVI-SIÓN ANALÓGICA
Una vez consolidados los sistemas analógicos de tele-visión en color la tecnología de receptores evolucionómucho. Por ejemplo, algunas mejoras importantes fue-ron:
El mando a distancia (finales de los 70). . . queobligó a centralizar en una CPU el control de to-dos los elementos variables del equipo y supusoun cambio radical en el diseño de los receptores.
El tubo de imagen “trinitron” que posibilitabapantallas con una curvatura mínima y mayorbrillo. Sony retuvo la patente durante el límitelegal de 20 años y en el momento de su cadu-cidad (1996) surgieron muchas imitaciones: flat-tron, diamondtron.
Relacionado con lo anterior, empezaron a apare-cer pantallas cada vez mayores de 28 pulgadas ymás (una pantalla se suele medir por el tamañofísico de su diagonal, por herencia anglosajonase mide en pulgadas, 1 pulgada = 2.54 cm).
Este último avance hizo pensar que la resolución de lossistemas analógicos era insuficiente. Hablamos de 576líneas activas en PAL y SECAM, 480 en NTSC (todosellos utilizando una relación de aspecto, ancho/alto =4/3). Se definió alta definición como aquellos sistemascapaces de representar más de mil líneas activas enpantalla.
Los primeros intentos de crear sistemas de alta defi-nición fueron:
MAC (Multiplexed Analog Components): se lle-gó a estandarizar como sistema para el envío deTV terrestre de alta definición. Debería haberempezado a utilizarse en 1995, algo que nun-ca ocurrió. El sistema se basa en multiplexaren tiempo las diversas informaciones necesarias:brillo, color, audio. . . Aunque se trata de conca-tenar señales analógicas, tanto el emisor como elreceptor deberán digitalizar la señal para poderensamblar y desensamblar la señal MAC. MACse llegó a utilizar en TV satélite pero nunca tuvomucho éxito. Tal vez el fracaso se debió al eleva-do precio de los receptores (en aquel momentoun sistema que hiciese procesado de señal digitala gran velocidad estaba en el límite de la tecno-logía) y por el hecho de que no se ganaría nadautilizando conversión a PAL para reutilizar tele-visores antiguos (haciendo esto en TDT se ganacalidad pero convertir a PAL la señal MAC esperder la mitad de la resolución).
MUSE (Multiple sub-Nyquist Sampling Enco-ding): fue un sistema desarrollado en Japón enlos años 80 y fue el primer sistema de alta defini-ción con éxito (sólo en Japón). Igual que MAC es
una técnica que combina procesos digitales conotros analógicos. Nunca se consiguió importara Europa. La principal limitación es el enormecosto en ancho de banda que supone.
Paralelamente al interés por la alta definición, nacióel concepto de formatos panorámicos. La idea es quela relación de aspecto clásica (4/3) es muy baja: lapantalla es casi cuadrada y el usuario mantiene losojos fijos en la pantalla sin apenas moverlos. Desdesiempre, el cine ha sido una experiencia más agra-dable porque la pantalla más ancha permite que lamirada del observador se desplace por la misma. Sedefinió como formato panorámico aquel que tiene unarelación de aspecto al menos aproximadamente iguala 16/9 = (4/3)2.
El primer formato comercial capaz de enviar televisiónen formato panorámico fue el PALplus. Un televisorPAL estándar representará una imagen panorámicacon barras negras arriba y abajo: las 432 líneas cen-trales tendrán imagen, la franja negra superior estaráformada por (576-432)/2 = 72 líneas, la franja negrainferior estará formada por otras tantas. Las líneas ne-gras, realmente contienen una señal modulada en altafrecuencia, invisible para un televisor PAL. Un televi-sor PALplus era capaz de decodificar esa señal oculta(señal de ayuda vertical) y utilizar esa informaciónpara generar 576 líneas con formato 16/9 (con mayorancho que las convencionales). Hubo muchas pruebasde PALplus en diferentes televisiones europeas en losaños 90 (en España se probó en autonómicas) peroninguna tuvo un éxito destacable. Actualmente, nin-gún operador utiliza PALplus.
LA TECNOLOGÍA DE IMAGEN Y SUEVOLUCIÓN
Este artículo está dedicado a los avances en la señalde televisión, sus formatos y su tecnología de emi-sión/recepción. Paralelamente a la señal también haevolucionado la tecnología de imagen, esto es: los dis-positivos de captura (cámaras) y representación (mo-nitores). Este apartado se ha incluido para conocer unpoco de esta evolución.
Hasta los años 80, tanto cámaras como monitores sebasaban en tubos de rayos catódicos (tubos de vacíodonde se provocaban descargas de electrones, “tubode cámara” para las cámaras y “tubo de imagen” pa-ra los monitores). Los tubos de rayos catódicos eranpesados (porque debían soportar las presión atmosfé-rica sobre una cámara de vacío), grandes (necesitabanmucho fondo para dar recorrido a los haces de electro-nes), difíciles de fabricar y de gran consumo (porquenecesitan enormes tensiones para generar los haces deelectrones).
Los avances vinieron de la mano de aplicar una “filoso-fía digital” (o discreta) creando matrices de elementossensores para las cámaras y otras de elementos lumi-nosos para los monitores.
OCCAM’s Razor | 34
HISTORIA
Figura 7 - Sensor CCD.
Las nuevas tecnologías de imagen son los sensoresCCD y los sensores CMOS.
Los sensores CCD (Charged Coupled Devices), sontransistores de efecto de campo sensibles a la luz.En lenguaje “cuántico” puede decirse que cada fotón(unidad de energía luminosa) recibido produce un parelectrón-hueco (una unidad elemental de carga en lacapacidad que el transistor genera entre puerta y tie-rra). Hasta aquí sabemos como convertir la luz en unaseñal (captación de imagen) pero otro problema esconseguir leer esa imagen. Los CCD’s se construyenen estructuras espaciales (1D o lineales para escáne-res o fotocopiadoras, 2D o matriciales para cámaras),además, su estructura permite que la carga acumula-da se pueda desplazar muy rápidamente de un transis-tor a otro. Esa es la propiedad que se aprovecha paraleer los CCD’s. Recordad que toda cámara imita alojo, donde un sistema óptico genera una imagen so-bre una superficie sensible a la luz (retina). Los CCD’sse convirtieron en la primera retina electrónica y portanto mucho más eficiente en tamaño y consumo queun tubo de cámara.
Los sensores CMOS se basan en el mismo principio defuncionamiento pero no utilizan desplazamientos decarga para la lectura. Se pueden leer píxel a píxel ypermiten integrar más funciones en el chip. Durantemucho tiempo fueron una alternativa barata pero deinferior calidad comparados con los CCD’s. Los prime-ros sensores CMOS no podían competir con los CCD’sen número de píxeles por unidad de área, por eso seutilizaban en cámaras sencillas y baratas (webcams).En los últimos años la tecnología CMOS ha mejoradomucho llegando a ser comparable a los sensores CCD.
En cuanto a los monitores debemos destacar dos nue-vas tecnologías: la tecnología de cristal líquido o LCDy la tecnología de plasma.
Tecnologías de cristal líquido (LCD) se basan en lapropiedad de ciertos materiales de filtrar la luz de ma-nera diferente según el campo eléctrico que reciben.Una luz inicial es polarizada por un filtro polarizador(polarizador pasivo: ángulo de polarización fijo), des-pués se atraviesa el material (polarizador activo: quepuede cambiar o no el ángulo de polarización según latensión recibida) y se encuentra, por último, otro fil-tro polarizador (un polarizador pasivo con un ángulo
diferente al inicial). La luz atravesará o no el segundofiltro dependiendo de si el material ha girado la pola-rización inicial o no. El material consiste en un líquidoque contiene moléculas orgánicas en suspensión. Losprimeros display’s LCD eran sistemas pequeños paracalculadoras y relojes. El material se excitaba a tra-vés de electrodos individuales. Para monitores se hanimpuesto matrices activas que se basan en transisto-res TFT (Thin Film Transistor) que permiten aplicartensiones individualizadas para gobernar cada píxel.
Figura 8 - Monitor TFT
Los monitores de plasma se basan en la propiedad deciertos gases (como Argón, Xenón y Neón) de ionizarsey emitir luz ultravioleta al ser sometidos a tensionesfuertes (es el mismo principio de los tubos fluores-centes). Se crea una matriz de celdas de gas que soncontroladas por electrodos. El gas emite luz ultravio-leta que es captada por granos de fósforo parecidos alos de los monitores de tubo. El efecto es el mismo:al absorber la energía de la luz ultravioleta, el fósfo-ro brilla (emite luz visible). Esta tecnología produceun tamaño de píxel mucho mayor que en los monito-res LCD (no se ha conseguido bajar de 0.3 mm, lasimágenes son de menor resolución: menor número depíxeles por unidad de longitud). Por eso, se usa enpantallas grandes que van a ser observadas a distan-cia y no en monitores de ordenador. Otros problemasson: la pérdida de brillo por desgaste del fósforo y elmayor consumo.
35| OCCAM’s Razor
HISTORIA
Como ventajas: no se ven afectados por campos elec-tromagnéticos externos (aunque, a cambio, producenmucha radiación) y son muy rápidos. Por último, des-tacar que un monitor de plasma no es capaz de crearpuntos de intensidad intermedia, todos los brillos son“todo o nada”. Para lograr intensidades se hace que loselementos conmuten a una frecuencia invisible para elojo y el ciclo de trabajo (tiempo activo/tiempo total)determina el brillo.
Figura 9 - Monitor de Plasma
MPEG Y DVB: TELEVISION DIGITAL
Y bien. . . hemos llegado a la actualidad. De esta par-te hablaremos poco. . . en parte porque “todavía” no eshistoria y también porque ya llevo escrito mucho y meestoy cansando :).
Hacia el año 1986 se consiguió reunir al “Joint Pho-tographic Experts Group” más conocido como JPEG.Como adivinaréis este grupo de expertos definieron elconocido estándar de codificación de imagen fija, aun-que tardaron hasta los primeros 90 (sí, sí, JPEG esmás que un formato de fichero, es un estándar que con-tiene varios algoritmos de compresión llamados “mo-dos de JPEG”).
El algoritmo básico JPEG (JFIF) consiste, simplifi-cando, en los siguientes pasos:
Si la imagen es en escala de grises, sólo tendre-mos luminancia. Si es en color la convertiremosal formato YUV con lo que tendremos tres sub-imágenes (planos). Los planos U y V pueden sersub-muestreados, esto es: se eliminan algunasmuestras. Hay varios formatos. El más habituales el que reduce U y V a imágenes de la mitadde altura y la mitad de anchura.
Cada plano se divide en bloques (o matrices)de tamaño 8x8. Para cada bloque se calcula latransformada discreta del coseno (DCT: Discre-te Cosine Transform). Esta transformada (depropiedades similares a la de Fourier) es capazde concentrar la mayor parte de la informaciónen la parte de baja frecuencia.
Los coeficientes (valores de la transformada) soncuantificados, esto es: se reduce su calidad de
acuerdo con las tablas de cuantificación calcu-ladas por A. B. Watson en 1993. Dichas tablasindican hasta donde se puede degradar cada coe-ficiente según su posición (en frecuencia) sin quehaya degradación apreciable en la calidad quepercibe el usuario final. Esta cuantificación, agrandes rasgos, va a reducir el margen dinámicode cada coeficiente (y por tanto el número debits necesarios para su representación) y, sobretodo, va a convertir en cero muchos coeficientesde alta frecuencia.
La cuantificación (que es la parte que introduceuna pérdida de calidad inapreciable) no es másque una preparación para aplicar un algoritmode codificación variable (se puede usar el códigode Huffman o alguna variante). El reducido mar-gen dinámico de los coeficientes y, sobre todo, lagran cantidad de ceros en la parte de alta fre-cuencia, hacen que la compresión (sin pérdidas)sea muy grande.
JPEG es por tanto un algoritmo de compresión conpérdidas (invisibles según el cálculo de Watson) quepermite reducir el tamaño binario de una imagen di-gital dividiéndolo por factores de hasta 20. Por susbuenos resultados y porque es fácil de implementar seha convertido en el estándar de facto en compresiónde imagen fija.
Y lo que os estaréis preguntando es: ¿Por qué hablarde JPEG en un artículo sobre televisión? Simplemen-te porque fue el primer paso en el desarrollo de es-tándares de codificación de vídeo. Pensad que JPEGprácticamente resuelve el problema de aprovechar almáximo la redundancia espacial (parecido de un píxelcon sus vecinos) para comprimir una imagen.
Poco después de JPEG, empezaron a aparecer están-dares de codificación de vídeo:
M-JPEG (Motion JPEG): es la idea más simple, cadafotograma (imagen individual) se codifica en forma-to JPEG. Al no aprovechar la redundancia temporal(parecidos entre fotogramas) se trata de un método in-eficiente (baja compresión). A pesar de ello, MJPEGy algunas variantes (DV-25) se siguen utilizando endispositivos como videocámaras. AL tratarse de unmétodo simple es adecuado para sistemas con pocapotencia de cálculo y, además, al trabajar con imáge-nes independientes es un formato adecuado para po-der editar el vídeo grabado que después se convertiráa un formato más eficiente.
H.261: pensado para videoconferencia es el primer es-tándar que introduce el concepto de codificación híbri-da (transformada DCT para la redundancia espacialy codificación predictiva para la redundancia tempo-ral). H.261 codifica la primera imagen con un métodoprácticamente igual al estándar JPEG. Después, sehace una “predicción” de cómo será la siguiente ima-gen y se codifica JPEG la diferencia entre la imagenque realmente hay y su predicción.
OCCAM’s Razor | 36
HISTORIA
El sistema continúa hasta el infinito construyendo pre-dicciones y “corrigiéndolas”. . . Sólo se envían las co-rrecciones, las predicciones son calculadas por igualpor emisor y receptor. H.261 mejoró mucho cuandose comenzaron a aplicar métodos de detección de mo-vimiento que permitieron hacer mejores predicciones(aunque esto obliga a enviar al receptor los movimien-tos detectados en forma de “vectores de movimiento”).
MPEG (Motion Pictures Experts Group): creado apartir de H.261 para permitir otras aplicaciones ade-más de la videoconferencia. H.261 no se puede utilizarpara almacenar vídeos y menos para emitir televisiónporque toda la secuencia depende de emitir y reci-bir correctamente la imagen inicial (la que se codificasin predicciones). Para superar ese problema se deci-dió dividir el vídeo en “grupos de imágenes” (GOP’s:Groups of Pictures) donde la primera se codifica sinpredicciones y las siguientes a partir de ella. Además,en MPEG se añadió la posibilidad de codificar algunasimágenes de forma “bidireccional”, esto es: teniendo encuenta el parecido con las anteriores y con las siguien-tes.
Figura 10 - Grupo de imágenes MPEG. Tipos de
imágenes: I (codificación independiente), P
(predicción hacia adelante), B (predicción
bidireccional).
El siguiente paso al MPEG fue estandarizarlo para suempleo en televisión digital. El estándar DVB (DigitalVideo Broadcasting) consiste en una serie de normasque definen cómo enviar y recibir vídeo. Se empezarondistinguiendo tres tipos de DVB: DVB-S (televisióndigital por satélite), DVB-C (televisión digital por ca-ble) y DVB-T (televisión digital terrestre). Cada unade estas variedades utiliza un tipo de modulación di-gital diferente para adaptarse a cada tipo de canal detransmisión. Como novedades recientes podemos des-tacar:
El uso de MPEG versión 4 para canales de altadefinición (los canales convencionales comenza-ron con MPEG-2 pero para alta definición serequiere una mayor compresión y MPEG-4 pre-senta aproximadamente el doble de eficiencia).
La aparición de nuevas variedades de difusióncomo el uso de Internet como medio de transmi-sión. Realmente, IPTV (televisión digital por In-ternet) empezó siendo un sistema independientedel DVB pero posteriormente el consorcio se haunido a la iniciativa.
CONCLUSIONES
Como conclusión me gustaría decir que “el sueño im-posible” que comentábamos al comienzo sigue desper-tando tanto interés como al principio. Quizá su mayorencanto es que “siempre será imposible” ya que pormucho que se avance nunca lograremos que la expe-riencia sea igual a presenciar un evento en directo (talvez deba ser así porque de lo contrario asistir en di-recto no tendría interés). Debido a esta conclusión es-tá claro que la evolución de la televisión no terminaránunca. Actualmente el interés en el mundo audiovisualestá volcado en los sistemas de visualización 3D. Estossistemas aprovechan la binocularidad (visión con dosojos) para crear sensación de profundidad (entregan-do una señal diferente a cada ojo). Ya se han probadoemisiones de televisión en 3D (por ejemplo, duranteel mundial de fútbol de 2010) pero todavía no hay unestándar establecido para ese tipo de emisiones. Sinduda, en breve lo habrá.
37| OCCAM’s Razor
EN LA PRÁCTICA
Introducción a SPICECálculo de Geometría para Misiones Planetarias
por Jose Luis Vázquez García
Todos hemos visto alguna vez las impresio-nantes imágenes de Marte que obtienen las son-das espaciales que orbitan el planeta. Nos dicenque son de tal o cual cráter, o del polo norte, oque corresponde a unas determinadas longitud ylatitud en la superficie de Marte. Probablemen-te alguna vez te has preguntado cómo, una vezque la sonda envía la imagen a tierra, se calcu-la esa información. SPICE juega un papel muyimportante en el proceso.
SPICE es una libreria de software (el toolkit) y unaserie de formatos de datos que pueden ayudar a uncientífico a usar datos auxiliares para planificar lasobservaciones de un vehículo espacial, o para analizarlos datos científicos obtenidos por esas observaciones.SPICE también es útil para científicos e ingenieros enla planificación de futuras misiones. En este contex-to, datos auxiliares significa geometría de misión, yconversión entre diferentes sistemas de tiempo.
Por geometría de misión se entiende el cálculo de los
parámetros geométricos necesarios para controlar un
satélite y obtener datos de él. Por ejemplo, su posición
y orientación, los parámetros que definen su órbita al-
rededor de un cuerpo, etc.
SPICE fue desarrollado y es mantenido por el Na-
vigation and Ancillary Information Facility
(NAIF) del Jet Propulsion Laboratory para laNASA. Es software libre en el sentido de que no estásujeto a restricciones a su exportación bajo las leyesde Estados Unidos, y se distribuye a través de la pági-na web de NAIF sin coste alguno. En el momento dela publicación de este artículo, SPICE está disponibleen Fortran, C, IDL y Matlab para diferentes platafor-mas, y NAIF está trabajando en una versión Java deltoolkit.
La página oficial de NAIF, http://naif.jpl.nasa.gov ofre-ce toda la información, los toolkits y la documentaciónnecesaria para entender SPICE y trabajar con él.
SPICE puede responder a preguntas del tipo:
¿Cuál será la posición de Rosetta vista desde laTierra en un determinado momento?
Tengo una imagen de Marte tomada por MGS,y conozco el valor del reloj del satélite en el mo-
mento en que fue tomada. ¿En qué instante fuetomada la imagen?
Quiero usar imágenes de Mars Express para bus-car rovers en la superficie de Marte. ¿Es la reso-lución de la cámara suficiente?
En este artículo aprenderemos a instalar la librería (eltoolkit) para C, y veremos unos ejemplos sencillos quenos ayudarán a coger soltura con SPICE.
La ESA y la NASA utilizan SPI-CE para los cálculos en algunasde sus misiones
INSTALANDO SPICE
Ya que todos los ejemplos que vamos a ver es-tán en C, mostraremos aquí como instalar el tool-kit para Linux/C (CSPICE). Ve a la página:http://naif.jpl.nasa.gov/naif/toolkit_C.html
y descarga el toolkit adecuado para tu ordenador, ydescomprímelo en el directorio en donde lo quieres ins-talar. Una vez descomprimido, ve al directorio cspice,y ejecuta el script makeall.csh (csh tiene que estarinstalado en el sistema). Si bien el toolkit ya vieneprecompilado, siempre es una buena idea ejecutar elscript para descartar posibles problemas con tu equi-po.
[jvazquez@cork: cspice] $ ls
cspice.tar.Z
[jvazquez@cork: cspice] $ uncompress cpice.tar.Z
[jvazquez@cork: cspice] $ tar xf cpice.tar
[jvazquez@cork: cspice] $ ls
cspice/ cspice.tar
[jvazquez@cork: cspice] $ cd cspice
[jvazquez@cork: cspice] $ ls
data/ doc/ etc/ exe/ include/ lib/ makeall.csh* src/
[jvazquez@cork: cspice] $
Pasos Necesarios para instalar SPICE. Una vez des-
comprimido, ejecuta el script makeall.csh para compi-
larlo
Una vez compilado el toolkit, podrás ver varios direc-torios. De momento nos interesan include, donde seencuentran los ficheros de cabecera, y lib, donde estála biblioteca de SPICE.
OCCAM’s Razor | 38
EN LA PRÁCTICA
LOS KERNELS DE SPICE
El toolkit es una parte de SPICE, la otra son los fi-cheros con datos que SPICE usa para trabajar.
Estos ficheros se llaman kernels, y almacenan posicióny orientación para los cuerpos del sistema solar (sa-télites artificiales incluidos), información de tiempo, yparámetros que describen los instrumentos a bordo deun satélite.
Los kernels pueden ser ficheros binarios o de texto,y cada kernel sólo almacena un tipo de información;es decir, un kernel no almacena, por ejemplo, infor-mación sobre la posición de un cuerpo y sobre con-versiones entre sistemas de tiempo (aunque esto es lamayoría de las veces más una convención que una res-tricción técnica).
Para usar SPICE en tu aplicación, primero tienes quecargar los kernels que necesitas. No es un paso trivial,muchas veces es más difícil averiguar cuáles son loskernels que hay que cargar que la aplicación en sí. Nohay una regla para esto, si no que es la experiencia laque te dirá que kernels necesitas y cuales no.
¿Dónde encontrar los kernels? Para kernels genéricos ymisiones de la NASA, el primer sitio en el que deberásbuscar es
ftp://naif.jpl.nasa.gov/pub/naif
Para misones de la ESA, el ’almacén’ oficial es
ftp://ssols01.esac.esa.int/pub/data/SPICE
Además, puedes acceder a este sitio a través de
su interfaz web.
Como puedes ver, este inferfaz proporciona mucha in-formación sobre los kernels, sin necesidad de entenderdemasiado sobre SPICE.
En el siguiente artículo profundizaremos un poco másen los distintos tipos de kernels que hay, y cómo ob-tener información básica sobre ellos.
PRIMER PROGRAMA SPICE
Vamos a crear un programa muy simple, para compro-bar que SPICE se ha instalado y funciona. Simplemen-te, imprimiremos la razón de conversión de grados aradianes, y de radianes a grados, que en SPICE vienendados por dos funciones, rpd_c y dpr_c.
PROGRAMA 1: Probando SPICE
#include <stdio.h>
/* Cabecera de SPICE */#include <SpiceUsr .h>
int main() {
float radianes_por_grado = rpd_c ();float grados_por_radian = dpr_c ();
printf( "1 grado = %f radianes \n",radianes_por_grado );
printf( "1 radian = %f grados\n",grados_por_radian );
return 0;}
Si has echado un vistazo al directorio include, habrás
visto un montón de ficheros de cabecera. Sin embargo,el fichero SpiceUsr.h incluye todos los ficheros necesa-rios, por lo que es la única cabecera que necesitamosincluir en nuestros programas.
Para compilar el programa, debes decir a gcc dondeencontrar las cabeceras de SPICE y la librería. SPICEtiene la particularidad de que la librería (cspice.a) seenlaza como un fichero objeto más, por lo que simple-mente la tienes que añadir a los parámetros de entradade gcc, en lugar de usar el flag -l del compilador. En miordenador, el comando para compilar este programasería:
gcc -o program1 program1.c /opt/SPICE/cspice/lib/cspice.a \-I/opt/SPICE/cspice/include/
Compilando y ejecutando el programa 1.
[jvazquez@cork: programs] $ gcc -o program1 program1.c \/opt/SPICE/cspice/lib/cspice.a \-I/opt/SPICE/cspice/include/
[jvazquez@cork: programs] $ lsprogram1* program1.c[jvazquez@cork: programs] $ ./program11 grado = 0.017453 radianes1 radian = 57.295780 grados
CALCULANDO POSICIONES
Ahora veremos un ejemplo un poco más complejo quecombina el trabajo con tiempos y el cálculo de posi-ciones. Como esto requiere un conocimiento detalladode los sistemas de tiempo y de referencia espacial queusa SPICE, no te preocupes si no entiendes todo a laprimera; paciencia.
Para simplificar imprimir vectores, creamos la libre-ria print_tools, que puedes ver en el listado siguiente.Primero el fichero de cabecera print_tools.h.
PROGRAMA 2: Librería para imprimir vectores
#ifndef PRINT_TOOLS_H#define PRINT_TOOLS_H
#include <stdio.h>
#include <SpiceUsr .h>
void printVector( FILE *out, SpiceDouble *vector ,unsigned long size );
#endif
Y este es el fichero print_tools.c
#include " print_tools.h"
void printVector( FILE *out,SpiceDouble *vector ,unsigned long size ) {
unsigned long i;
fprintf ( out , "[ " );
for (i = 0; i < size - 1; i++ )fprintf (out , " %f, ", vector[i]);
fprintf (out , " %f ]", vector[size - 1]);
}
39| OCCAM’s Razor
EN LA PRÁCTICA
Ahora, vamos a calcular la posición de la luna vistadesde la tierra, en el sistema de referencia J2000, el 1de junio de 2010, a las 12 del mediodía.
PROGRAMA 3: Calculando la posición de la Luna (1)
#include <stdio.h>
#include <SpiceUsr .h>
#include "print_tools.h"
int main() {
SpiceDouble posicion [ 3 ];SpiceDouble lt;SpiceDouble et;
/** Cargamos los kernels que necesitamos
* para nuestros cálculos*/
furnsh_c ( "NAIF0009 .TLS" );furnsh_c ( "DE405.BSP" );
/* Convertimos tiempo de formato UTC a ET */utc2et_c ( "2010-06-01T12:00:00 ", &et );
/* Calculamos la posicion de la luna */
spkpos_c ( "moon", et, "j2000", "none","earth", posicion , < );
printf( "Posicion de la luna: " );printVector( stdout , posicion , 3 );printf( " Km\n" );
return 0;
}
Vemos que las variables que declaramos son de ti-po SpiceDouble; SPICE, como muchas otras librerías,utiliza sus propios tipos que permiten que los progra-mas puedan ser compilados en diferentes plataformassin que haya que cambiar el código. SpiceDouble estádefinido como el tipo de datos de punto flotante queocupa el doble de memoria que un tipo entero; de-pendiendo de tu sistema operativo, será double o longdouble.
SPICE nos permite utilizar dis-tintos Sistemas de Referencia fá-cilmente
El siguiente paso es cargar los kernels que necesitare-mos.
DE405.BSP es el kernel que almacena informaciónsobre efemérides de los principales cuerpos del siste-ma solar, y NAIF0009.TLS almacena información quepermite convertir de UTC a ET, y viceversa. Puedesencontrar los kernels aquí y aquí (consultad el cuadroal final para obtener las URL completas si los enlacesno funcionan).
Ahora, ya que todos los cálculos que dependen deltiempo en SPICE se realizan en ET, tenemos que pa-sar de UTC a ET, con la función utc2et_c.
ET, Ephemeris Time. El tiempo de un evento en ET
se mide como segundos que han pasado desde el 1 de
enero de 2000 al mediodía.
Fíjate que el formato en que tenemos que especificarUTC es
YYYY-MM-DDThh:mm:ss
El siguiente paso es calcular la posición de la luna, conla función spkpos_c. Los parámetros que recibe son:
1. target : es el cuerpo del que queremos calcular laposición.
2. et : instante para el que queremos calcular la po-sición.
3. frame: sistema de referencia en el que queremosla solución. En nuestro caso es J2000.
4. corrections : dejaremos esto para más adelante.De momento, siempre sera none.
5. observer : es el cuerpo desde el que queremos cal-cular la posición. En este caso es earth, porquequeremos calcular la posición de la luna vistadesde la tierra.
6. position: es un vector que nos da la posición quequeremos calcular, en kilómetros.
7. light time: esto lo dejaremos también para másadelante.
Si examinamos el código, veremos alguna caracterís-tica más de SPICE:
Todas las funciones de SPICE tienen el sufijo_c.
Muchas de las funciones de SPICE no devuel-ven valores. En su lugar, devuelven resultadosen punteros que se le pasan como argumentos.Por ejemplo, la función spkpos_c devuelve dosvalores, la posición de un cuerpo y otro paráme-tro (light time), cuyas direcciones se pasan comoparámetros a la funcion (fíjate que el parámetroposicion se pasa directamente, en lugar de suposición, porque ya es un puntero).
Si compilamos el programa y lo ejecutamos (no olvi-des incluir en la compilación el fichero print_tools),obtendremos el siguiente resultado de la figura.
[jvazquez@cork: programs] $ ./pos_j2000
Posición de la luna:
[220242.595980, -312947.666645, -121185.983058] Km
[jvazquez@cork: programs] $
El problema que tiene este programa es que nos de-vuelve la posición de la luna en un sistema de referen-cia que no es muy útil para nosotros. El sistema J2000está definido de forma que, si colocamos el origen decoordenadas en el centro de la tierra, el eje Z es el ejede rotación de la tierra, y el eje X es tal que el solpasa por él en equinocio de primavera.
OCCAM’s Razor | 40
EN LA PRÁCTICA
SISTEMAS DE REFERENCIA
En física existen dos tipos fundamentales de sistemas de referencia, inerciales y no inerciales.En pocas palabras, en un sistema de referencia inercial se pueden aplicar las leyes de Newton, y en uno no inercial,no. Un sistema de referencia que está quieto o se mueve a velocidad constante (es decir, que no acelera) con respectoal fondo de estrellas fijas se considera inercial.El sistema inercial fundamental en SPICE es el sistema J2000 (también lo puedes encontrar en la literatura comoEME2000), y que se define de la siguiente forma:
El centro del sistema es el centro de la Tierra.
El eje Z del sistema coincide con el eje de rotación de la Tierra. Por lo tanto, el plano XY del sistema coincidecon el plano que contiene el ecuador de la Tierra.
El eje X se define de forma que el Sol lo cruza (atravesando el plano del ecuador de sur a norte) en el equinociode verano.
El eje Y completa el sistema de forma que X × Y = Z.
En otras palabras, el eje X de J2000 es la intersección del plano que contiene al ecuador de la tierra con el plano dela eclíptica, que es el plano que contiene la trayectoria que sigue el sol alrededor de la tierra.Otro sistema importante es el sistema IAU para la Tierra. Es un sistema que rota con la Tierra, por lo que no esun sistema inercial. Se define de forma que el eje de rotación de la Tierra es el eje Z del sistema, y el eje X estácontenido en el plano del ecuador y cruza la superficie de la Tierra en el meridiano de Greenwich. El eje Y completael sistema de forma que X×Y = Z. Este sistema se llama en SPICE IAU_EARTH; también existe un IAU_MARS,IAU_VENUS, . . . .
41| OCCAM’s Razor
EN LA PRÁCTICA
Vamos a calcular la posición ahora en un sistema mu-cho más interesante para nosotros, el sistema IAU pa-ra la tierra, que está definido de forma que el eje Z esel eje de rotación de la tierra, pero el eje X cruza elmeridiano cero. Por tanto, este sistema gira con latierra
En el siguiente programa podemos ver que simplemen-te necesitamos cargar un nuevo kernel (que define elsistema que vamos a usar), y decirle a SPICE que nosdé la posición en el nuevo sistema. El kernel lo puedesencontrar aquí. (Consulta la tabla de recursos al finaldel artículo si tu enlace no funciona)
PROGRAMA 4: Calculando la posición de la luna
#include <stdio.h>#include <SpiceUsr .h>#include "print_tools.h"
int main() {
SpiceDouble posicion [ 3 ];SpiceDouble lt;SpiceDouble et;SpiceDouble r, lon, lat;
/*
* Cargamos los kernels que necesitamos para* nuestros calculos
*/furnsh_c ( "NAIF0009 .TLS" );furnsh_c ( "DE405.BSP" );furnsh_c ( "PCK00009 .TPC" );
/* Convertimos tiempo de formato UTC a ET */utc2et_c ( "2010-06-01T12:00:00", &et );
/* Calculamos la posicion de la luna */spkpos_c ( "moon", et, "iau_earth", "none",
"earth", posicion , < );
printf( "Posicion de la luna: " );printVector( stdout , posicion , 3 );printf( " Km\n" );
/*
* Calculamos la posicion en coordenadas* esfericas*/
reclat_c ( posicion , &r, &lon, &lat );
/* Longitud de radianes a grados */lon *= dpr_c();/* Latitud de radianes a grados */lat *= dpr_c();
printf( "Distancia: %f Km\n", r );printf( "Longitud : %.2f grados\n", lon );printf( "Latitud : %.2f grados\n", lat );
return 0;
}
Cambiar nuestro Sistema de Re-ferencia es muy fácil. Solo tene-mos que decirle a SPICE en quesistema queremos las soluciones
Al final del programa, podemos ver por qué este nuevosistema de referencia es útil. Debido a cómo está defi-nido, si convertimos un vector dado en este sistema acoordenadas esféricas (ρ, θ, φ), θ y φ se correspondena la longitud y latitud del punto en que el vector cruzala superficie de la tierra. Por tanto, en nuestro ejem-
plo podemos calcular el punto de la tierra que está“debajo” de la luna.
La función reclat_c simplemente convierte un vectoren sus coordenadas esféricas, aunque las dos coorde-nadas angulares son devueltas en radianes, por lo quehay que convertirlas a grados; esto es muy fácil enSPICE, simplemente tienes que multiplicar la canti-dad por dpr_c().
SPICE nos permite calcular laposición de cualquier cuerpo parael que exista un kernel
SPICE no sólo calcula posiciones de cuerpos naturalesdel sistema solar, sino de cualquier cuerpo para el quehaya un kernel con efemérides. En este ejemplo, cal-cularemos la posición de Rosetta visto desde la Tierraen un instante de tiempo dado.
PROGRAMA 5: Calculando la posición de Rosetta
#include <stdio.h>
#include <SpiceUsr .h>
#include " print_tools.h"
int main() {
SpiceDouble posicion [ 3 ];SpiceChar utc[ 50 ];SpiceDouble lt;SpiceDouble et;
/** Cargamos los kernels que necesitamos
* para nuestros calculos*/
furnsh_c ( "NAIF0009 .TLS" );furnsh_c ( "DE405.BSP" );furnsh_c ( "PCK00009 .TPC" );furnsh_c ( "ORHR_______________00122.BSP" );
/* Leemos el tiempo de la consola */printf( "Introduce el tiempo en formato ""YYYY -MM -DDThh:mm:ss: " );scanf( " %s", utc );
/* Convertimos tiempo de formato UTC a ET */utc2et_c ( utc , &et );
/* Calculamos la posicion de Rosetta */spkpos_c ( "rosetta ", et, "iau_earth", "none","earth", posicion , < );
printf( "Posicion de Rosetta : " );printVector( stdout , posicion , 3 );printf( " Km\n" );
return 0;
}
Como ves, la única diferencia con el programaanterior es que necesitamos cargar el kernel conefemérides de Rosetta
EN LA SIGUIENTE ENTREGA
Aprenderemos algo más sobre los kernels, usaremosla base de datos de efemérides de la nasa para hacernuestros propios kernels de posición, y aprenderemosa definir un sistema de referencia referido a nuestralocalización en la tierra.
OCCAM’s Razor | 42
EN LA PRÁCTICA
MIDIENDO EL TIEMPO EN SPICE
No es tan fácil como puede parecer medir el tiempo. Según la teoría de la relatividad, depende del observador, por loque el tiempo medido en Marte puede no ser el mismo que el medido en Venus o en la Tierra. Además, los sistemasque se usan en la vida diaria para medir el tiempo (en años, meses, dias, horas,...) no son los más adecuados parahacer operaciones.En SPICE normalmente se trabaja con dos sistemas de tiempo fundamentales, UTC y ET.La definición de ET (Ephemeris Time) es muy complicada. ET es la variable temporal en las ecuaciones diferencialesque describen el movimiento de los planetas en el sistema solar. Puede aparecer en dos formas, TDB (BarycentricDynamical Time) y TDT (Terrestrial Dynamical Time). TDB describe el tiempo medido desde el baricentro (elcentro de gravedad) del sistema solar, y TDT el tiempo medido en la Tierra. La diferencia entre ellos, aunquepequeña, cambia con el tiempo, en una época del año TDB va más rápido que TDT, y en otra es al revés. Por lotanto, la diferencia entre TDB y TDT nunca es mayor que una determinada cantidad muy pequeña (del orden deuna milésima de segundo).SPICE toma TDB como ET, y se expresa como el número de segundos que han transcurrido desde un instantedeterminado (la época J2000, que es el uno de enero de 2000 a las 11 horas 58 minutos y 55.816 segundos). Este esel sistema de tiempo que usa SPICE para todos sus cálculos.UTC, por otro lado, no es un sistema de medida del tiempo propiamente dicho, sino una forma de asignar un nombrea cada segundo ET. UTC intenta mantenerse en sincronía con la rotación de la Tierra, de forma que el 1 de enerode cualquier año el Sol esté en la misma posición. Si todos los años tuvieran la misma duración en segundos, esto nose cumpliría, puesto que la velocidad de rotación de la Tierra varía con el tiempo (típicamente se va ralentizando).El IERS (International Earth Rotation Service) se encarga de mantener la sincronía, que se hace intercalando un“leapsecond” (segundo intercalar), normalmente a finales de junio o diciembre, si es necesario. Este leapsecond puedeser positivo o negativo, dependiendo de si se añade o se sustrae de la cuenta de tiempo.Por ejemplo, si la rotación de la Tierra se ralentiza, el efecto es que el año se alarga. Para corregir, se añade unleapsecond al final de un año, y la cuenta de segundos se correspondería con los siguientes momentos UTC:
... DECEMBER 31 23:59:57
... DECEMBER 31 23:59:58
... DECEMBER 31 23:59:59
... DECEMBER 31 23:59:60
... JANUARY 1 00:00:00
...
, en lugar de la cuenta normal:
... DECEMBER 31 23:59:57
... DECEMBER 31 23:59:58
... DECEMBER 31 23:59:59
... JANUARY 1 00:00:00
...
Si la rotación de la Tierra se acelerase (no se ha dado nunca desde que el sistema de leapseconds se introdujo en1972), el leapsecond se sustrae (un leapsecond negativo), y la cuenta sería por el contrario:
... DECEMBER 31 23:59:57
... DECEMBER 31 23:59:58
... JANUARY 1 00:00:00
...
SPICE proporciona varias funciones para convertir entre diferentes sistemas e tiempo. Por ejemplo, utc2et_c permiteconvertir de UTC a ET, y et2utc_c de ET a UTC. Toda la información que maneja SPICE está dada en ET, porlo que estas operaciones son muy comunes, para traducir el tiempo entre el sistema intuitivo que entendemos laspersonas y el sistema más matemático que usa SPICE. El hecho de que haya que llevar la cuenta de leapsecondsque han ocurrido históricamente para poder hacer la conversión es la razón de que tengamos que cargar en nuestroprograma un “leapseconds kernel”, que almacena precisamente esa información. Sólo hay un kernel de leapsecondsoficial que se actualiza cada vez que aparece un nuevo leapsecond; a día de hoy, el kernel es el NAIF0009.TLS, y elpróximo será el NAIF0010.TLS.En la siguiente entrega veremos un tercer sistema para medir el tiempo, usado por los satélites para registrar loseventos que ocurren a bordo.En el cuadro sobre sistemas de referencia hemos definido el sistema J2000, pero nos faltaba una pieza. El eje derotación de la Tierra no está fijo, sino que sufre un efecto que se llama precesión (se mueve como una peonza), deforma que, por ejemplo, dentro de unos años (más bien milenios) la estrella polar se habrá desviado tanto del polonorte geográfico que ya no será útil para marcar ese punto cardinal de la Tierra. Esto significa que, tal como lo hemosdefinido, J2000, se movería con el tiempo y ya no sería inercial. La forma de evitar esto es referir las posiciones quedefinen el sistema a la época J2000. Por ejemplo, el eje Z se define como el eje de rotación medio de la Tierra en laépoca J2000.
43| OCCAM’s Razor
EN LA PRÁCTICA
RECURSOS
GENERAL
Página Oficial del Navigation and Ancillary Information Facility NAIF:
Página Principal: http://naif.jpl.nasa.govDescarga CSPICE: http://naif.jpl.nasa.gov/naif/toolkit_C.html
KERNELS NASA y ESA
Misiones de la NASA:ftp://naif.jpl.nasa.gov/pub/naif
Misiones de la ESA:FTP: ftp://ssols01.esac.esa.int/pub/data/SPICEInterfaz Web: http://www.rssd.esa.int/index.php?project=SPICE&page=RepositoryBrowser
KERNELS UTILIZADOS EN EL ARTÍCULO:
Efemérides Sistema Solar:ftp://ssols01.esac.esa.int/pub/data/SPICE/MEX/kernels/spk/DE405.BSP
Conversiones tiempo UTC/ET:ftp://ssols01.esac.esa.int/pub/data/SPICE/MEX/kernels/lsk/NAIF0009.TLS
Kernel que define diferentes constantes para el sistema solar, entre ellas los parámetros que describen el sistema IAU parala tierra:ftp://ssols01.esac.esa.int/pub/data/SPICE/MEX/kernels/pck/PCK00009.TPC
Efemérides de Rosetta:ftp://ssols01.esac.esa.int/pub/data/SPICE/ROSETTA/kernels/spk/ORHR_______________00122.BSP
Numquam ponenda est pluralitas sine necessitate.Quaestiones et decisiones in quattuor libros Sententiarum Petri Lombardi (ed. Lugd., 1495), i, dist. 27, qu. 2, K
OCCAM’s Razor | 44
LA CACHARRERÍA
Teclados PersonalizadosConstrúyelos fácilmente con Teensy
por er Teo Cla D’Or
Teensy es un completo sistema de desarro-llo para microcontroladores basado en un inter-faz USB. Un simple cable USB es todo lo quenecesitamos para empezar a utilizarlo y sus po-sibilidades son muy interesantes, como veremosen este artículo.
En el momento de publicar este artículo (finales de2011), la versión actual de esta pequeña placa es la 2.0.Podemos encontrarla en dos configuraciones denomi-nadas, respectivamente, Teensy 2.0 y Teensy++ 2.0.Las diferencias fundamentales entre ambas versioneslas podéis comprobar en la siguiente tabla, extraídade la web del proyecto.
Elemento Teensy 2.0 Teensy++ 2.0Procesador ATMEGA32U4 AT90USB1286Memoria Flash 32256 130048Memoria RAM 2560 8192EEPROM 1024 4096I/O 25 46Entradas Analógicas 12 8PWM 7 9UART,I2C,SPI 1,1,1 1,1,1Precio $ 16 $ 24
Además, la versión ++, es más larga, unos 5 cm frentea los 3cm del Teensy 2.0. Nosotros vamos a trabajarcon el Teensy 2.0, más que suficiente para lo que osqueremos contar. Para que os hagáis una idea del ta-maño de esta pequeña placa, aquí lo podéis ver juntoa un Arduino.
La versión de la foto es un Teensy 2.0 con los “pines”ya soldados. Podéis comprarlo así, bastante práctico
para utilizarlo en placas de prototipos o sin los pines,de forma que podréis soldar los que mejor os conven-gan.
Con un Teensy y unos cuantosbotones podremos extender nues-tro teclado muy fácilmente
MÁS CARACTERÍSTICAS
Además de lo que ya hemos comentado, su bajo precio,su pequeño tamaño y unas especificaciones suficientespara abordar varios proyectos de distinta naturaleza,hay dos cosas más que hacen esta placa bastante in-teresante.
La primera es que utilizando un Teensy es práctica-mente trivial construir dispositivos de entrada paranuestros ordenadores, tales como teclados, ratones ojoysticks. Esto lo veremos en seguida.
La otra característica interesante de esta placa se lla-ma Teensyduino. Se trata de un paquete que extiendeel entorno de desarrollo de Arduino, para trabajar conTeensy. Además de ellos, este paquete incluye la ma-yoría de las librerías a las que estamos acostumbradoscon Arduino, y un sinfín de ejemplos.
Para terminar con esta introducción, solo comentarque en la web del proyecto podréis encontrar los esque-mas de los circuitos de todas las versiones de Teensy yuna librería para la utilidad Eagle con la que desarro-llar vuestras propias placas, basadas en este diseño.
SOFTWARE
Para empezar a trabajar con nuestro pequeñoamigo, necesitamos descargar el paquete llamado“Teensy Loader” de la página web del proyecto.
45| OCCAM’s Razor
LA CACHARRERÍA
La aplicación está disponible para los principales sis-temas operativos. Existe también una versión de líneade comandos que podéis compilar vosotros mismos siasí lo preferís. Sólo tenéis que descargarla y ejecutarla.
El paquete Teensyduino nos per-mite programar Teensy desde elentorno Arduino
La aplicación “Teensy Loader” nos permite reprogra-mar la tarjeta, en otras palabras, volcar el código quedeseemos ejecutar en el microcontrolador. Para gene-rar ese código necesitamos un “toolchain”.
En el caso de los sistemas GNU/Linux, este no es otroque el proporcionado por GCC para AVR. Compila-dor, linker y librería estándar están disponibles en lamayoría de los sistemas GNU/Linux. Si estáis utili-zando otro sistema, consultad la página del proyectodonde encontraréis instrucciones detalladas para losdistintos sistemas soportados.
Por tratarse este de un artículo introductorio, no va-mos a profundizar en este tema. Nos centraremos en elentorno Teensyduino más sencillo y familiar. Sin em-bargo, no os olvidéis de que al final, lo que escribimosen el editor del entorno de Arduino, acaba siendo com-pilador por gcc y descargado en Teensy por el “TeensyLoader”.
La web de Teensy contiene instrucciones detalladassobre como trabajar directamente utilizando estas he-rramientas, para aquellos de vosotros que queráis sa-car el máximo de ella. Para los demás vamos a instalarTeensyduino.
TEENSYDUINO
La instalación de Teensyduino no puede ser más fácil.Solo tenemos que descargar el paquete adecuado para
nuestro sistema y ejecutarlo. Una aplicación gráficarealizará todo el trabajo. Lo único que nos pregunta-rá es donde tenemos instalado el entorno de desarrollode Arduino.
El paquete Teensyduino, no funciona con la versión delsoftware de Arduino que de distribuye con Ubuntu. Eneste caso tenemos que descargar el software de la webde Arduino, y descomprimirlo donde más rabia nosdé. Luego solo tendremos que decirle a Teensyduinocual es ese lugar.
Una vez hecho esto solo tenemos que lanzar arduino yseleccionar en el menú Tools >Board nuestra versiónde Teensy. Ahora comprobemos que todo funciona co-rrectamente.
En el menú File >Examples >Teensy >Tutotial 1
cargaremos el Sketch llamado Blink (es el único queaparece). Al principio del sketch nos encontramos unavariable que indica el pin por defecto asociado al LEDen Teensy. Para Teensy 2.0 es el 11 (el que aparece enel código). Si estamos utilizando un Teensy++, debe-remos modificar esa línea para utilizar el pin 6.
const i n t l edPin = 11 ; // Teensy
const i n t l edPin = 6 ; // Teensy++
Ahora solo tenemos que pulsar el botón Upload y elprograma se compilará y se descargará en la tarjeta.El “Teensy Loader” aparecerá en pantalla y nos infor-mará del estado de la tarjeta así como del proceso dedescarga del software en el microcontrolador.
Si Teensy está ejecutando ya un programa, el inter-faz nos informará de que debemos pulsar el pequeñobotón en la tarjeta para que el nuevo programa se des-cargue. Lo hacemos y el pequeño LED naranja sobreTeensy comenzará a cambiar su estado cada segundo.
Tras comprobar que todo funciona perfectamente, va-mos a intentar hacer algo más útil con nuestro nuevojuguete.
Interfaz Teensiduino.
OCCAM’s Razor | 46
LA CACHARRERÍA
DISPOSITIVOS DEINTERACCIÓN HUMANA (HID)
Con nuestra configuración actual, podremos utilizarnuestro Teensy para hacer casi cualquier cosa que po-damos hacer con nuestro Arduino, pero lo que Teensyhace realmente bien es simular dispositivos HID.
HID (Human Interface Device o Dispositivo de Inter-faz Humano) es un protocolo estándar utilizado pordispositivos diseñados para la interacción entre hom-bres y máquinas. La mayoría de teclados, ratones,joysticks, etc. actuales son dispositivos de este tipo.
Teensy tiene la capacidad de presentarse ante el orde-nador al que se conecta como uno de estos dispositi-vos. Teensy además nos permite enviarle informaciónal ordenador utilizando este mismo protocolo y porlo tanto, puede comportarse como cualquiera de esosdispositivos. O dicho de otra forma, utilizando Teensypodemos crear, muy fácilmente, teclados, ratones ojoysticks (entre otras cosas).
TECLADOS DE UNA TECLA
Vamos a empezar por lo más sencillo, un teclado deuna sola tecla. Aunque pueda parecer un poco inú-til, hay un gran número de aplicaciones en la que nospuede interesar ofrecer a nuestros usuarios solo un nú-mero reducido de teclas para interactuar con nuestrosistema, en lugar de un teclado completo. Pensad porejemplo en un kiosko electrónico en un lugar público.
Como veréis enseguida, quien dice una tecla, dice dos,o tres o cuatro. Todo dependerá de cuantos botonesqueramos conectar a nuestras entradas digitales.
Nuestro primer programa será un simple simulador debarra espaciadora.
#inc lude <Bounce . h>
Bounce button0 = Bounce (1 , 1 0 ) ;
void setup ( ) {pinMode (1 , INPUT_PULLUP) ;
}
void loop ( ) {button0 . update ( ) ;
i f ( button0 . r i s i n gEdge ( ) ) {Keyboard . p r i n t ( " " ) ;
}}
Aún siendo un programa muy sencillo, es necesariohacer un par de comentarios. El primero es el uso dela librería Bounce. Esta librería simplifica el uso depulsadores. Normalmente, este tipo de botones, pro-duce un rebote de la señal. Cuando pulsamos el botón,no obtenemos un único pulso, sino una secuencia deellos que, si no tomamos medidas serían interpretadoscomo varias pulsaciones muy rápidas.
Este problema se puede solucionar con un sencillo cir-cuito anti-rebotes o en el software con una libreríacomo Bounce. El uso de la librería es muy sencillo.Solamente tenemos que crear un objeto Bounce indi-cándole que pin queremos filtrar, y que intervalo detiempo en milisegundos queremos considerar para el
filtrado de los rebotes.
Una vez hecho esto, solo tenemos que llamar al mé-todo update en nuestro bucle principal, ya que estalibrería no utiliza interrupciones y, por lo tanto, noso-tros tenemos que forzar la lectura de los pines.
Los objetos Bounce nos ofrecen varios métodos, pe-ro los más importantes para nuestra aplicación sonfallingEdge y risingEdge que nos permiten com-probar si se ha producido un flanco de bajada o desubida respectivamente. En otras palabras, nos indi-can si hemos pulsado la tecla o la hemos soltado.
En nuestro caso estamos enviando el carácter espacioal ordenador cuando liberamos la tecla.
El otro comentario que debemos hacer sobre este pro-grama es una extensión de Teensy al entorno Arduino.En la función setup, configuramos el pin 0 de la placacomo una entrada, pero además le estamos pidiendoque se configure en modo pull-up de forma que lee-remos un valor 1 si nada está conectado, y un valorcero, cuando conectemos la entrada a tierra, es decircuando pulsemos el botón.
+VCC
GND
PIN 0
10K
+VCC
PIN 0pinMode (0, INPUT_PULLUP)
PIN 0pinMode (0, INPUT)
PIN 0
GND
Para que este programa funcione, tenemos que confi-gurar la placa en modo teclado. Para ello en el menúTools >USB Type deberemos seleccionar uno de lostipos que incluye el teclado. Ahora solo tenemos queconectar nuestro pulsador a los pines indicados en lafigura anterior y ya tenemos nuestra barra espaciadorapersonalizada.
47| OCCAM’s Razor
LA CACHARRERÍA
TECLADOS SIN TECLAS.SEGURIDAD FÍSICA
Acabamos de ver como simular un teclado de una so-la tecla, pero ¿qué os parecería un teclado sin teclas?.Puede parecer un poco inútil, pero que sucede si soloqueremos escribir algo muy concreto y una sola vez...como por ejemplo una puerta trasera para tener acce-so a un ordenador más tarde.
Hacer lo que acabamos de decir es un poco más com-plicado que lo que os vamos a contar a continuación,pero no mucho más. Hay algunas personas ahí fue-ra que ya lo han hecho, pero si alguno os animáis nodudéis en contarnos vuestros resultados.
Nosotros os vamos a mostrar una prueba de concep-to. En lugar de un caballo de Troya vamos a generarun sencillo “Hola Mundo” y vamos a suponer que unaconsola ya se encuentra abierta y lista para ser utili-zada.
Además vamos a mantener nuestro pulsador. La razónes que, para depurar el programa y hacer pruebas esmás práctico que conectar y desconectar la placa to-do el tiempo. En cualquier caso es recomendable tenercuidado cuando juguéis con el siguiente programa, esfácil escribir algo inapropiado en el lugar incorrecto yque las cosas vayan mal.
Sin más, aquí tenéis el programa que lanza vim, escri-be el programa “Hola Mundo”, sale de vim, lo compilay luego lo ejecuta :)
#inc lude <Bounce . h>
Bounce button0 = Bounce (0 , 1 0 ) ;
void setup ( ) {pinMode (0 , INPUT_PULLUP) ;
}
void loop ( ) {button0 . update ( ) ;
i f ( button2 . r i s i n gEdge ( ) ) {Keyboard . p r i n t l n ( "vim kk . c\n" ) ;Keyboard . p r i n t l n ( ":\ %d\ n i#inc lude <s t d i o . h>"Keyboard . p r i n t l n ( " i n t main ( ) " ) ;Keyboard . p r i n t l n ( "{ p r i n t f (\" h e l l o \\n \" ) ; } " ) ;Keyboard . se t_modi f i e r ( 0 ) ;Keyboard . set_key1 (KEY_ESC) ;Keyboard . send_now ( ) ;Keyboard . p r i n t l n ( " :wq\n" ) ;de lay ( 1 00 ) ;Keyboard . p r i n t l n ( "make kk\n . / kk\n" ) ;
}}
Como podéis comprobar, el programa hace uso exten-sivo de la función println que nos permite enviar unacadena de texto seguida de un retorno de carro. En elmomento de soltar el pulsador, simplemente enviamostodo el texto que escribiríamos en el caso normal.
Hay una pequeña salvedad. La tecla ESC para volver
a modo comando en vim.
TECLAS ESPECIALES YCOMBINACIONES
Teclas como ESC o F1 no las podemos enviar utili-zando el método print que conocemos. De la mismaforma, combinaciones de teclas como CTRL+C tampo-co se pueden simular con esas funciones. En ese casotenemos que construir nuestra combinación de teclasa mano.
Podemos almacenar un programaen nuestro Teensy y hacer quese escriba y compile automática-mente al ser conectado.
Para estos casos, disponemos de los métodosset_modifier y set_keyN. El primero nos permiteconfigurar los modificadores de teclado, esto es, lasteclas CTRL, SHIFT, ALT y GUI (las teclas de Win-dows y MAC).
La segunda nos permite configurar hasta seis teclasque se enviarán simultáneamente cuando ejecutemosel método send_now. En nuestro ejemplo anterior po-demos ver como lo primero que hacemos es borrar losmodificadores para, a continuación, configurar la pul-sación de la tecla ESC y finalmente enviar todo junto.
Esto nos devuelve al modo comando de vim, lo que nospermite grabar el fichero en disco con el bien conocidocomando :wq.
Observad que tras enviar el comando esperamos unpoco. En nuestra primera prueba sin el retardo, el ca-rácter m del comando make kk se perdía, al parecerporque el ordenador estaba ocupado grabando el fi-chero en disco. Si experimentáis un problema similarprobad a aumentar el retardo.
MUCHO MÁS QUE TECLADOS
Aunque no hemos hablado de ello, para mantener elartículo corto, Teensy puede ser utilizado para cons-truir ratones o joysticks de una forma tan sencilla co-mo la que acabamos de ver para nuestros teclados es-peciales. Estad atentos a la lista de correo.
Las posibilidades son muchas. desde un panel de bo-tones para nuestro ordenador de salón (hay un intere-sante sketch en los ejemplos de Teensyduino), hastaun botón CTRL+ALT+SUPR para reiniciar servidores.
Esperamos vuestros experimentos.
RECURSOS
Página Web de Teensyhttp://www.pjrc.com/teensy/index.html
Todo sobre Teensiduinohttp://www.pjrc.com/teensy/teensyduino.html
Algunas ideas de las posibilidadeshttp://www.pjrc.com/teensy/projects.html
OCCAM’s Razor | 48
TRUCOS
Con un par... de líneasChuletillas para hacer cosas mú rápido
por Tamariz el de la Perdíz
SERVIDOR WEB IMPROVISADO
Python es un lenguaje de programación que se ha po-pularizado mucho en los últimos años. Como conse-cuencia de ello una enorme cantidad de módulos es-tán disponibles para hacer nuestras vidas mucho máscómodas.
Uno de estos módulos es SimpleHTTPServer que nospermite desarrollar sencillos servidores web de formamuy sencilla. De forma tan sencilla como esta:
$ python -m SimpleHTTPServer
Ahora solo tenemos que poner nuestros ficherosHTML en el mismo directorio en el que hemos eje-cutado nuestro comando, y apuntar nuestro servidora localhost:8000, o a la IP de nuestra máquina sipretendemos acceder de forma remota.
Por defecto el módulo escucha en el puerto 8000. Siqueremos utilizar un puerto diferente solo tenemos queañadirlo al final del comando.
$ python -m SimpleHTTPServer 8080
Un módulo muy útil para sacarnos de un aprieto “múrápido”
EL HOMBRE
Existen dos flags de la utilidad man que resultan muyútiles en el día a día. El primero es -k. Este flag ledice a man que busque cosas relacionadas con la pala-bra clave que se pasa como parámetro. El flag -f essimilar pero permite buscar cadenas.
El otro es N donde N es el número de la sección delmanual que queremos consultar. Para los que no losepáis estas son las secciones del manual:
1 Comandos Generales
2 Llamadas al Sistemas y Números de Error
3 Librería C
3p perl
4 Dispositivos y Drivers de Dispositivos
5 Formatos de ficheros y Ficheros de Configura-ción
6 Instrucciones de Juegos
7 Miscelánea
8 Mantenimiento del Sistema
9 Interioridades del Kernel
Algunos ejemplos:
$ man -k thread$ man socket$ man 7 socket
Otras páginas del manual interesantes son:
$ man 7 tcp$ man 7 ip$ man syscalls$ man standards$ man feature_test_macros$ man ascii
La utilidad man tienen un montón de flags interesan-tes, no tenéis más que pedir la página del manual,sobre el manual...
$ man man
DISCO SUPERRÁPIDO /dev/shm
El dispositivo /dev/shm es realmente memoria, y porlo tanto muy útil para almacenar información a la quequeremos acceder “mú rápido”. Y para muestra un bo-tón.
$ dd if=/dev/zero of=/dev/shm/test count=102400 bs=1024102400+0 records in102400+0 records out104857600 bytes (105 MB) copied, 0.105547 s, 993 MB/s$ dd if=/dev/zero of=/tmp/test count=102400 bs=1024102400+0 records in102400+0 records out104857600 bytes (105 MB) copied, 0.629624 s, 167 MB/s
EDITAR COMANDOS BASH SUPERLARGOS
Bash tiene un comando interno llamado fc que per-mite editar el último comando tecleado en un editor.Cuando salimos del editor, lo que hayamos escrito enel editor se ejecutará
Envía tus trucos
Puedes enviarnos esos trucos que usas a diario para
compartirlos con el resto de lectores a la dirección:
49| OCCAM’s Razor
LICENCIAS
LICENCIAS DE LAS IMÁGENES EN ESTE NÚMEROGracias a todos los que comparten su trabajo!
por The Occam’s Razor Team
Todas las imágenes de esta publicación, salvo las excepciones listadas en esta página y las imágenes que formanparte de los artículos se distribuyen bajo los siguientes términos:
Licencia: CC-BY (Creative Commons Attribution 3.0)
Autor/Creditos: Laura I. Rodríguez González/Revista Occam’s Razor
Los términos anteriormente mencionados se aplican a las secciones generales de la revista: Editorial, LaComunidad de Occam y Trucos.
PORTADAImagen del satelite SMOS utilizada de fondo
Licencia: ESA (http://www.esa.int/esa-mmg/mmgdownload.pl)
Autor/Creditos: ESA
CIENCIA Y ESPACIOTodas las imágenes en este artículo pertenecen han sido cedidas por ESA o CESBIO. Consulte el pie de foto de cadauna de ellas.
Licencia: ESA (http://www.esa.int/esa-mmg/mmgdownload.pl)
Autor/Creditos: ESA/CESBIO, ESA/CNES
EN LA PRÁCTICAImagen de Fondo Cabecera
Licencia: ESA (http://www.esa.int/esa-mmg/mmgdownload.pl)
Autor/Creditos: ESA
HISTORIAFiguras 1, 2 y 4
Licencia: CC-BY (Creative Commons Attibution 3.0)
Autor/Creditos: Fernando Martín y Xulio Fernández
Figuras 3, 5, 6, a1, a2, a3, 10
Licencia: CC-BY (Creative Commons Attibution 3.0)
Autor/Creditos: Fernando Martín
Figuras 7 y 8
Licencia: Dominio Público
Autor/Creditos: Wikipedia
Figura 10
Licencia: Creative Commons Attribution-Share Alike 3.0 Unported
Autor/Creditos: Ed g2s (Fuente Wikipedia)
Figura 10
Licencia: Licencia de arte libre (http://artlibre.org/licence/lal/es)
Autor/Creditos: Jari Laamanen (Fuente Wikipedia)
RATAS DE BIBLIOTECA, MÚ RÁPIDO, LA CACHARRERÍALicencia: CC-BY (Creative Commons Attibution 3.0)
Autor/Creditos: Laura I. Rodríguez González/Occam’s Razor
OCCAM’s Razor | 50
