Mejoramos nuestra aplicación RA: estabilizamos el tracking

Os presento ahora una importante mejora que podemos introducir en nuestros programas de Realidad Aumentada: se trata de mejorar el tracking de marcadores para conseguir una imagen capturada más estabilizada. Para ello, utilizaremos la función histórica de ARToolKit.

ARToolKit incorpora una función de tratamiento del histórico de percepciones para estabilizar el tracking. Este histórico se implementa en una función alternativa a arGetTransMat que, en realidad, utiliza únicamente la percepción anterior, llamada arGetTransMatCont. Mediante el uso de esta función se elimina gran parte del efecto de registro tembloroso.

Salida del programa con histórico

La función histórica requiere como parámetro la percepción anterior y no podrá utilizarse hasta que no dispongamos (al menos) de una percepción. Por esta razón, es necesario llamar primero a la función sin histórico arGetTransMat y, con la primera percepción, llamar a la función de histórico arGetTransMatCont. Esto lo conseguimos modificando ligeramente el código de la función mainLoop, una vez detectado el marcador, de la siguiente forma:

   if(k != -1) {   // Si ha detectado el patron en algun sitio... obtenemos
                   // transformacion relativa entre marca y la camara real
      if (useCont && contAct) {
            arGetTransMatCont(&marker_info[k], patt_trans, p_center,
            p_width, patt_trans);
            printf ("Usando historico!!!\n");
         }
      else {
            useCont = 1;      // En la siguiente iteracion lo podemos usar!
            arGetTransMat(&marker_info[k], p_center, p_width, patt_trans);
            printf ("Sin historico...\n");
         }
      draw();       // Dibujamos los objetos de la escena
  } else {
      useCont = 0;
      printf ("Reset Historico (fallo de deteccion)\n");
  } 

Utilizamos la variable  useCont (definida anteriormente) para indicarnos si ya podemos utilizar la función con histórico o no, en función de que tengamos capturado o no el primer frame. Esta variable de comportamiento booleano se tendrá que poner a false (valor 0) cuando no se detecte la marca. De este modo, si el usuario activó el uso del histórico (y ya tenemos al menos una percepción previa de la marca, utilizamos la función con histórico. En otro caso, llamaremos a la función de detección sin histórico y activaremos el uso del histórico para la siguiente llamada.

En nuestro programa, imtroducimos también una función de callback de teclado que permite activar el uso del histórico mediante la tecla h:

  // ======== keyboard ================================================
  static void keyboard(unsigned char key, int x, int y) {
  switch (key) {
      case 'H': case 'h':
                if (contAct) {contAct = 0; printf("Historico Desactivado\n");}
                else {contAct = 1; printf("Historico Activado\n");} 
                break;
      case 0x1B: case 'Q': case 'q':
                cleanup(); exit(1); 
                break;
      }
   }

Salida del programa

Salida del programa 

Esta es la salida del programa y los siguientes enlaces permiten descargar el código y el marcador utilizado (imagen para impresión y datos para el programa) y los ficheros de inicialización de la cámara. Todos los ficheros deberán estar en ...artoolkit\bin\Data.

código del programa histórico
marcador meditel
ficheros cámara

Creando mis propios marcadores

ARToolKit pone a nuestra disposición una serie de marcadores reconocibles y utilizables por sus funciones. Pero, ¿por qué no utilizar nuestros propios marcadores? ¿por qué no personalizar o utilizar nuestro logo o nuestras imágenes favoritas como patrón de un marcador?

Existen muchos métodos para realizar un marcador. De hecho, lo más sencillo es partir de una plantilla de marcador en blanco y con cualquier programa de imagen, insertar nuestro patrón en su interior. Pero con cuidado, tenemos que respetar algunas restricciones si queremos que nuestra marca pueda ser detectada sin problemas. Al final del post os dejo algunos consejos.

Generación de marcadores con mk_patt

Una vez creado el marcador, tiene que ser reconocido por ARToolKit y entrenado para generar su fichero de datos correspondiente. Para ello, ARToolKit proporciona una sencilla aplicación, mk_patt, que nos pedirá el fichero de parámetros de la cámara y abrirá una ventana de vídeo. Entonces mostraremos a la cámara nuestro marcador impreso y aparecerán en su contorno una esquina roja y otra verde. Tenemos que orientar la cámara hasta situar el contorno rojo en la esquina superior izquierda de nuestro marcador y, en ese momento, pulsar el botón izquierdo del ratón para generar el fichero del marcador. Este fichero se introduce como dato en nuestros programas ARToolKit.

Este proceso de generación de marcadores están perfectamente definidos en el apartado de documentación de la web de ARToolKit. Os dejo también un acceso a la plantilla de marcador en blanco.

Consejos sobre marcadores

• El patrón debe ser sencillo. El rango de detección se ve afectado por la complejidad de la marca. Los patrones simples (con grandes áreas de color blanco o negro) son detectados mejor.
• No debe tener simetrías.
• Cuanto mayor es la resolución del patrón reescalado, mayor es la precisión de ARToolKit, pero requiere más capacidad de cómputo para realizar las operaciones.
• El tamaño físico de la marca afecta directamente a la facilidad de detección; a mayor tamaño de marca, mayor distancia puede ser cubierta. Por ejemplo, marcas de 7 cm de lado pueden ser detectadas hasta una distancia máxima de 40 cm (a una resolución de 640x480 píxels). Si aumentamos el tamaño de la marca a 18cm, ésta será detectada hasta una distancia de 125cm.
• Finalmente las condiciones de iluminación afectan enormemente a la detección de las marcas. El uso de materiales que no ofrezcan brillo especular, y que disminuyan el reflejo en las marcas mejoran notablemente la detección de las marcas.

ARToolKit: funcionamiento básico

Para los que hayáis leído mi entrada "Mi primera aplicación de Realidad Aumentada" en la que explico a través de un sencillo programa la estructura y funcionamiento básico de una aplicación de Realidad Aumentada, en este post desarrollaré algo más el funcionamiento básico de ARToolKit.

Lo esencial en todas las aplicaciones de Realidad Aumentada, es la  necesidad de calcular correctamente el punto de vista de la cámara, para así poder realizar las operaciones necesarias sobre los objetos virtuales, para que estos se integren correctamente en el mundo real. Es decir, si queremos mostrar objetos virtuales, de modo que el usuario realmente crea que existen en el mundo real, tendremos que realizar transformaciones sobre dichos objetos de modo que el usuario los vea (a través de la cámara o dispositivo de captura utilizado) en la posición  con el tamaño, orientación e iluminación, en que esos objetos serían percibidos por el usuario en el mundo real en caso de que realmente estuvieran allí.

Marcador meditel

Para ello, herramientas como ARToolKit utilizan unas plantillas (marcadores) de forma cuadrada normalmente, formadas por un cuadrado negro con un cuadrado blanco unas cuatro veces más pequeño en su centro, y un dibujo (patrón) en el interior del cuadrado blanco. Este dibujo debe ser sencillo y evitar las simetrías. Nuestro programa será capaz de detectar una de estas plantillas en las imágenes de vídeo capturadas utilizando mediante un potente algoritmo de detección de contornos implementado en las funciones y utilidades proporcionadas por ARToolKit.

Una vez detectado el marcador en una imagen, a partir de su orientación, posición y tamaño, la aplicación es capaz de calcular la posición y orientación relativa de la cámara real respecto al marcador y dibujar el objeto 3D sobre la imagen capturada de modo que aparezca sobre el marcador en la posición, orientación y tamaño correspondiente al punto de vista de la cámara (perfectamente alineado). Esto siempre que el programador de la aplicación así lo haya decidido, pues las posibilidades son muchas y pudiera ser que una vez obtenida esta información el programador decidiese utilizarla de otra forma, hacer otras operaciones distintas, etc. Para el renderizado del objeto se utilizan librerías externas a ARToolKit (por ejemplo GLUT y OpenGL).

El proceso básico de una aplicación ARToolkit es el siguiente:

Proceso de detección
de  marcas en ARToolKit

1. Primero se captura un fotograma del mundo real mediante la cámara.
2. A continuación se detectan marcas. Para ello, la imagen se convierte a escala de grises y se binariza (según parámetro umbral threshold que indica a partir de que gris todo pixel será negro, dejando blancos el resto: compromiso entre rapidez y precisión en detección). después, se detectan todas las posibles marcas y se les asigna mediante un parámetro un valor de fidelidad para decidir cual de las marcas posibles es la real. 
3. Se normaliza la marca, se detectan los contornos de la región que la contiene (vértices y lados del cuadrado) y después se extrae el contenido de la marca comparándola con patrones de las plantillas de las que se tiene información almacenada.
4. Si la forma del patrón del marcador detectado coincide con el de la plantilla almacenada, se utiliza la información y el tamaño de marcador y plantilla almacenada para calcular la posición y orientación de la cámara respecto al marcador detectado, y se guarda en una matriz llamada Matriz de Transformación. (en el post AR Conceptos II se explica con detalle cómo es esta matriz). Conociendo las posiciones 2D de las aristas y vértices que definen el marcador 2D y el modelo de proyección de la cámara (matriz de parámetros intrínsecos P) es posible estimar la posición y rotación 3D de la cámara respecto a la marca y, por tanto la matriz de transformación T (matriz de parámetros extrínsecos). Esto se hace mediante un proceso de cálculo iteractivo.
5. La matriz de Transformación se utilizará para establecer la posición y orientación de la cámara virtual (transformación de la vista), lo que equivale a una transformación de las coordenadas de la marca a las coordenadas de la cámara y por tanto se transforman las coordenadas del objeto a dibujar. Se usa la matriz T (para hacer transformaciones geométricas) e implícitamente la P (para hacer transformaciones de proyección y visualización de la cámara).
6. Al haber puesto la cámara virtual en la misma posición y orientación que la cámara real, el objeto virtual se renderiza sobre el marcador y se muestra la imagen resultante, que contiene la imagen del mundo real y el objeto virtual superpuesto, alineado sobre el marcador. Se dibujan, por tanto, los objetos 3D alineados con la escena. 
7. Se realiza el mismo proceso con los siguientes fotogramas.

Sistema de coordenadas de ARToolKit

El siguiente diagrama muestra el funcionamiento que se acaba de describir:
.

Esquema funcional de ARToolKit

Mi primera aplicación de Realidad Aumentada

Mi primera aplicación de Realidad Aumentada es un sencillo programa que, una vez compilado, es capaz de reconocer en la escena un marcador generado por nosotros para renderizar sobre él una imagen tridimensional, en mi caso una tetera. Podéis descargaros el código y los ficheros necesarios al final del post.

A continuación os muestro el código de este programa que utilizaré para explicar la estructura y funcionamiento básico de un programa de Realidad Aumentada. El programa reconoce en la escena un marcador ARToolkit creado por nosotros (en otra entrada mostraré como hacerlo) y renderizar sobre él una imagen tridimensional.

1. #ifdef _WIN32
2. #include <windows.h>
3. #endif
4. #include <GL/gl.h>
5. #include <GL/glut.h>
6. #include <stdio.h>
7. #include <stdlib.h>
8. #include <AR/gsub.h>
9. #include <AR/video.h>
10. #include <AR/param.h>
11. #include <AR/ar.h>
12.  
13.  
14. // ==== Configuracion de la camara ===============
15. #ifdef _WIN32
16. char                *vconf = "Data\\WDM_camera_flipV.xml";
17. #else
18. char                *vconf = "";
19. #endif
20.  
21. // ==== Definicion de constantes y variables globales ===============
22. int    patt_id;                                // Identificador de la marca
23. double patt_trans[3][4];                       // Matriz de transformacion de la marca
24.  
25. // ==== Definicion de funciones =====================================
26. void print_error (char *error) {  printf(error); exit(0); }
27.  
28. // ======== cleanup =================================================
29. static void cleanup(void) {  
30.   arVideoCapStop();                      // Para captura de video y libera recursos
31.   arVideoClose();
32.   argCleanup();
33. }
34.  
35. // ======== draw ====================================================
36. static void draw( void ) {
37.   double  gl_para[16];                   // Matriz 4x4 de OpenGL
38.   GLfloat mat_ambient[]     = {0.0, 0.0, 1.0, 1.0};
39.   GLfloat light_position[]  = {100.0,-200.0,200.0,0.0};
40.  
41.   argDrawMode3D();                       // Activa modo presentacion 3D
42.   argDraw3dCamera(0, 0);                 // Activa vista de la camara 3D
43.   glClear(GL_DEPTH_BUFFER_BIT);          // Limpia buffer de profundidad
44.   glEnable(GL_DEPTH_TEST);
45.   glDepthFunc(GL_LEQUAL);
46.  
47.   argConvGlpara(patt_trans, gl_para);   // Convierte la matriz de la marca
48.   glMatrixMode(GL_MODELVIEW);           // para ser usada por OpenGL
49.   glLoadMatrixd(gl_para);               // Carga l matriz
50.  
51.   // Dibuja el objeto 3D
52.   glEnable(GL_LIGHTING);  glEnable(GL_LIGHT0);
53.   glLightfv(GL_LIGHT0, GL_POSITION, light_position);
54.   glMaterialfv(GL_FRONT, GL_AMBIENT, mat_ambient);
55.     glTranslatef(0.0, 0.0, 60.0);
56.     glRotatef(90.0, 1.0, 0.0, 0.0);
57.     glutSolidTeapot(80.0);
58.   glDisable(GL_DEPTH_TEST);
59. }
60.  
61. // ======== init ====================================================
62. static void init( void ) {
63.   ARParam  wparam, cparam;        // Parametros intrinsecos de la camara
64.   int xsize, ysize;               // Tamaño del video de camara (pixels)
65.  
66.   // Abre dispositivo de video
67.   if (arVideoOpen(vconf) < 0) exit(0); 
68.   if(arVideoInqSize(&xsize, &ysize) < 0) exit(0);
69.  
70.   // Carga los parametros intrinsecos de la camara
71.   if(arParamLoad("data/camera_para.dat", 1, &wparam) < 0)  
72.     print_error ("Error en carga de parametros de camara\n");
73.  
74.   arParamChangeSize(&wparam, xsize, ysize, &cparam);
75.   arInitCparam(&cparam);                       // Inicializa la camara con "cparam"
76.  
77.   // Carga la marca
78.   if((patt_id=arLoadPatt("data/pattMeditel")) < 0)
79.     print_error ("Error en carga de patron\n");
80.  
81.   argInit(&cparam, 1.0, 0, 0, 0, 0);   // Abre la ventana grafica
82. }
83.  
84. // ======== mainLoop ================================================
85. static void mainLoop(void) {
86.   ARUint8 *dataPtr;                     // contenedor de frame activo
87.   ARMarkerInfo *marker_info;            // informacion del marcador
88.   int marker_num, j, k;
89.  
90.   double p_width     = 120.0;           // Ancho del patron (marca)
91.   double p_center[2] = {0.0, 0.0};      // Centro del patron (marca)
92.  
93.   // Captura un frame de la camara de video
94.   if((dataPtr = (ARUint8 *)arVideoGetImage()) == NULL) {
95.     // Si devuelve NULL es porque no hay un nuevo frame listo
96.     arUtilSleep(2);  return;  // Duerme el hilo 2ms y salimos
97.   }
98.  
99.   argDrawMode2D();
100.   argDispImage(dataPtr, 0,0);    // Dibuja lo que ve la camara
101.  
102.   // Detecta la marca en el frame capturado (return -1 si error y sale de programa)
103.   if(arDetectMarker(dataPtr, 100, &marker_info, &marker_num) < 0) {
104.     cleanup(); exit(0);  
105.   }
106.  
107.   arVideoCapNext();      // Captura siguiente frame
108.  
109.   // Detecta el patron con mayor fiabilidad
110.   for(j = 0, k = -1; j < marker_num; j++) {
111.     if(patt_id == marker_info[j].id) {
112.       if (k == -1) k = j;
113.       else if(marker_info[k].cf < marker_info[j].cf) k = j;
114.     }
115.   }
116.  
117. if(k != -1) {                   // Si detecta el patron obtiene transformación
118. // relativa entre la marca y la cámara real
119.     arGetTransMat(&marker_info[k], p_center, p_width, patt_trans);
120.     draw();                       // Dibuja los objetos de la escena
121.   }
122.  
123.   argSwapBuffers();                     // Cambia el buffer con lo que tenga dibujado
124. }
125.  
126. // ======== Main ====================================================
127. int main(int argc, char **argv) {
128.   glutInit(&argc, argv);                 // Crea la ventana OpenGL con Glut
129.   init();                               
130.  
131.   arVideoCapStart();                    // Crea un hilo para captura de video y
132.   argMainLoop( NULL, NULL, mainLoop );  // asocia callbacks...
133.   return (0);
134. }

Cualquier aplicación que use ARToolKit tendrá la estructura de programa similar a la siguiente: tres grandes bloques inicialización, bucle principal y finalización (en el código están coloreados en azul, verde y rojo respectivamente):

Inicialización (función init)

Primero abre el dispositivo de vídeo con arVideoOpen (línea 67) y se obtiene el tamaño de la fuente de vídeo mediante arVideoInqSize (línea 68) (se guarda en dos variables entero el ancho y alto del vídeo). A continuación, arParamLoad (línea 71) carga en una estructura ARParam (tercer parámetro) los parámetros intrínsecos de la cámara obtenidos en la etapa de calibración (fichero genérico camera_para.dat válido para la mayoría de webcams; aunque lo ideal es trabajar con un fichero que contenga los parámetros de nuestra cámara para obtener   resultados más precisos).

Marcador meditel

Veremos cómo crear este fichero específico para cada cámara en una entrada posterior en ARexperience. Después, arParamChangeSize (línea 74) modifica los parámetros intrínsecos para la resolución en píxels con la que trabajará la cámara y se cargan en las estructuras de datos internas de ARToolKit, mediante la llamada a arInitCparam (línea 75).

Se carga el patrón asociado a la marca (línea 78). Finalmente, en la línea 81 se abre la ventana de OpenGL mediante argInit (de la librería auxiliar Gsub de ARToolKit), pasándole como primer parámetro la configuración de la cámara. El segundo parámetro indica el factor de zoom (en este caso, sin zoom).

Bucle principal
El primer lugar, se recupera un frame de la cámara de vídeo mediante la función arVideoGetImage (la llamada devuelve un puntero a un buffer donde se encuentra la imagen capturada). Si se llama a la función con mayor frecuencia de la soportada por la cámara, se duerme el hilo 2ms (línea 96) y se vuelve a ejecutar el mainLoop.

A continuación, se dibuja en la ventana (en modo 2D) el buffer que acabamos de recuperar de la cámara (línea 100) para que arDetectMarker (línea 103) localice las marcas en el buffer de entrada. El segundo parámetro de valor 100 se corresponde con el valor umbral de binarización de la imagen (a blanco y negro, explicaremos el proceso de binarización de la marca en una entrada posterior). Esta función nos devuelve en el tercer parámetro un puntero a una lista de estructuras de tipo ARMarkerInfo, que contienen información sobre las marcas detectadas (junto con un grado de fiabilidad de la detección), y como cuarto parámetro el número de marcas detectadas.

De esta forma, ARToolKit nos devuelve “posibles” posiciones para cada una de las marcas detectas. Incluso cuando estamos trabajando con una única marca, es común que sea detectada en diferentes posiciones (por ejemplo, si hay algo parecido a un cuadrado negro en la escena). ¿Cómo elegimos la correcta en el caso de que tengamos varias detecciones? ARToolKit asocia a cada percepción una probabilidad de que lo percibido sea una marca, en el campo cf (confidence value). Como se puede comprobar, todos los campos de la estructura ARMarkerInfo se refieren a coordenadas 2D, por lo que aún no se ha calculado la posición relativa de la marca con la cámara.

Campos de la estructura ARMarkerInfo

Así, en las líneas 109-115 se guarda en la variable k el índice de la lista de marcas detectadas aquella percepción que tenga mayor probabilidad de ser la marca (cuyo valor de fiabilidad sea mayor). Mediante la llamada a arGetTransMat (línea 119) se obtiene la matriz de transformación relativa entre la marca y la cámara (matriz 3x4 de doubles); es decir, se obtiene la traslación y rotación de la cámara con respecto de la marca detectada. Para ello es necesario especificar el centro y ancho de la marca. Esta matriz será finalmente convertida al formato de matriz homogénea de 16 componentes utilizada por OpenGL mediante la llamada a argConvGlpara en la línea 47. Finalmente, se renderizará una imagen 3D mediante primitivas OpenGL para uso en aplicaciones de Realidad Aumentada. (líneas 51-58).

Finalización y función Main
En la función cleanup se liberan los recursos al salir de la aplicación. Se hace uso de funciones de ARToolKit para detener la cámara de vídeo, y limpiar las estructuras de datos internas de ARToolKit. En la función main se registran los callbacks mediante la función argMainLoop. En este ejemplo, se pasa como primer y segundo parámetro NULL (correspondientes a los manejadores de ratón y teclado respectivamente). Por su parte, se asocia la función que se estará llamando constantemente en el bucle principal mainLoop.

Salida del programa

Salida del programa 

Esta es la salida del programa y los siguientes enlaces permiten descargar el código y el marcador utilizado (imagen para impresión y datos para el programa) y los ficheros de inicialización de la cámara. Todos los ficheros deberán estar en ...artoolkit\bin\Data.

código del programa
marcador meditel
ficheros cámara

AR Orígenes

La Realidad Aumentada (RA) ha ido evolucionando desde que Ivan Sutherland en 1968 creara el primer sistema. Pero la verdadera revolución de los sistemas RA está produciéndose en estos últimos años. 

Ivan Sutherland en 1968, empleó un casco de visión que permitía ver sencillos objetos 3D renderizados en wireframe en tiempo real. Usaba dos sistemas de tracking para calcular el registro de la cámara; uno mecánico y otro basado en ultrasonidos. En 1992 los ingenieros de Boeing Tom Caudell y David Mizell, acuñaron el término de Realidad Aumentada al proponer el uso de esta novedosa tecnología para mejorar la eficiencia de las tareas realizadas por operarios humanos asociadas a la fabricación de aviones.

En 1997, investigadores de la Universidad de Columbia presentan The Touring Machine el primer sistema de realidad aumentada móvil (MARS). Utilizan un sistema de visión de tipo see-through que combina directamente la imagen real con gráficos 2D y 3D proyectados en una pantalla transparente.

ARToolKit

En 1998, el ingeniero de Sony Jun Rekimoto crea un método para calcular completamente el tracking visual de la cámara (6 grados de libertad) empleando marcas 2D matriciales. Esta técnica originaría otros métodos de tracking visuales en los años siguientes. Un año más tarde en 1999, Kato y Billinghurst presentan ARToolKit, una librería de tracking visual de 6 grados de libertad que reconoce marcas cuadradas mediante patrones de reconocimiento. Liberada bajo licencia GPL se hace muy popular y es ampliamente utilizada.


En 2000, investigadores de la University of South Australia presentan una extensión de Quake (AR-Quake) que permite jugar en primera persona en escenarios reales. El registro se realizaba empleando una brújula digital, un receptor de GPS y métodos de visión basados en marcas. Los jugadores debían llevar un sistema de cómputo portátil en una mochila, un casco de visión estereoscópica y un mando de dos botones.

En 2001 se presenta Archeoguide; un sistema financiado por la UE para la creación de guías turísticas electrónicas basadas en Realidad Aumentada. El sistema proporciona información personalizada basada en el contexto, y muestra reconstrucciones de edificios y objetos mediante una base de datos multimedia adaptada al problema. La comunicación se realiza mediante Wifi, y el sistema es altamente escalable permitiendo diferentes dispositivos de visualización (portátiles, PDAs, etc).

Arqueoguide

En el 2003, Siemens lanza al mercado Mozzies, el primer juego de RA para teléfonos móviles. El juego superpone mosquitos a la visión obtenida del mundo mediante una cámara integrada en el teléfono. Este juego fue premiado como el mejor videojuego para teléfonos móviles en dicho año.

En 2004 investigadores de la Universidad Nacional de Singapur presentan Human Pacman, un juego que emplea GPS y sistemas inerciales para registrar la posición de los jugadores. El PacMan y los fantasmas son en realidad jugadores humanos que corren por la ciudad portando ordenadores y sistemas de visión, percibiendo el mundo como se muestra en la Imagen.

Human Pacman

También en el 2004, la Universidad Técnica de Viena presenta el proyecto Invisible Train, el primer juego multi-usuario para PDA's. Esta aplicación se ejecutaba totalmente en las PDA's, sin necesidad de servidores adicionales para realizar procesamiento auxiliar. Los jugadores controlan trenes virtuales y deben intentar evitar que colisione con los trenes de otros jugadores. El proyecto utiliza la biblioteca Studierstube desarrollada en la misma universidad.

En 2005 A. Henrysson adapta la biblioteca ARToolKit para poder funcionar en Symbian, y crea un juego de Tenis que gana un premio internacional el mismo año. En 2007, Klein y Murray presentan en ISMAR (uno de los principales congresos de Realidad Aumentada) el algoritmo PTAM; una adaptación del SLAM que separa el tracking y el mapping en dos hilos independientes, consiguiendo en tiempo real unos resultados muy robustos.

En 2008 Mobilizy crea Wikitude, una aplicación que aumenta la información del mundo real con datos obtenidos de entradas de Wikipedia.

wikitude

En 2009, SPRXmobile lanza al mercado una variante de Wikitude llamada Layar, que utiliza el mismo mecanismo de registro que Wikitude (GPS + Brújula electrónica). Layar define un sistema de capas que permite representar datos de diversas fuentes globales (como Wikipedia o Twitter) además de servicios locales (como tiendas, estaciones de transporte público o guías turísticas). En la actualidad Layar cuenta
con más de 100 capas distintas de contenido.

El mismo año se presenta ARhrrrr!, el primer juego con contenido de alta calidad para smartphones con cámara. El teléfono utiliza la metáfora de ventana virtual para mostrar un mapa 3D donde disparar a Zombies y facilitar la salida a los humanos que están atrapados en él. El videojuego emplea de forma intensiva la GPU del teléfono delegando en la tarjeta todos los cálculos salvo el tracking basado en características naturales, que se realiza en la CPU.

El videojuego de PSP Invizimals, creado por el estudio español Novorama en 2009, alcanza una distribución en Europa en el primer trimestre de 2010 superior a las 350.000 copias, y más de 8 millones de copias a nivel mundial, situándose en lo más alto del ránking de ventas. Este juego emplea marcas para registrar la posición de la cámara empleando tracking visual.

A partir de 2010 numerosas compañías lanzan herramientas y campañas publicitarias con tecnología de Realidad Aumentada. Algunos ejemplos pueden ser los de National Geographic o Goertz.