LectoRA – Realitat augmentada aplicada a la...

LectoRA – Realitat augmentadaaplicada a la lectoescriptura

TITULACIÓ: Enginyeria tècnica d'informàtica de gestió

AUTOR: Marc Robledo Caparrós.DIRECTOR: Maria Ferré Bergadà

DATA: Juny 2010

Departament d’Enginyeria Informàtica i Matemàtiques

LectoRA - Realitat augmentada aplicada a la lectoescriptura

Índex

1 Introducció 4

1.1 El projecte 4

1.2 Resum 6

2 Estat de l'art 7

2.1 La realitat augmentada 7

2.2 Interfícies naturals 9

2.3 Usos de la realitat augmentada 10

2.4 La realitat augmentada aplicada a l'educació 11

3 Especificacions del projecte 14

3.1 Punt de partida 14

3.2 Requisits de l'aplicació 15

3.3 Passos a realitzar 16

4 Disseny 17

4.1 Disseny de classes 17

4.2 Disseny de la base de dades 18

4.3 Interfície gràfica 19

4.3.1 Diagrama de casos d'ús 19

4.3.2 Disseny interfície gràfica d'administració 20

5 Desenvolupament 21

5.1 Cronologia 21

5.1.1 Conèixer l'entorn desenvolupat fins al moment 21

5.1.2 Conèixer el procés de generació i detecció d'un patró 22

2


5.1.3 Afegir a l'aplicació una base de dades 26

5.1.4 Interfície d'usuari de l'aplicació 26

5.1.5 Passos finals 27

5.2 Decisions de disseny 28

5.2.1 Llenguatge de programació escollit 28

5.2.2 j/ARToolKit 29

5.2.3 Gestor de base de dades 31

5.2.4 Tipus d'aplicació: local o web 33

5.3 Treball addicional 34

5.3.1 Algoritme de detecció de frames erronis 34

5.3.2 Mini-API de HSQLDB 38

6 Avaluació 39

6.1 Joc de proves 39

6.1.2 Joc de proves amb el joc LectoRA 39

6.1.3 Joc de proves amb l'aplicació d'administració 40

6.2 Presentacions públiques 40

6.3 Línies futures 41

7 Conclusions 42

8 Recursos utilitzats 44

9 ANNEX A: Instruccions de jARToolKit 45

10 ANNEX B: Manual d'usuari 47

3


1 Introducció

1.1 El projecte

L'objectiu del projecte que es presenta a continuació és dissenyar un entorn d'aprenentatge de lectura utilizant la tecnologia de la realitat augmentada.

Concretament, s'ha creat un entorn educatiu i interactiu enfocat a nens de 3 a 6 anys, en el qual se'ls proposa un joc de suport a l'aprenentatge de la lectoescriptura, alhora que fan ús de la seva primera aplicació informàtica. És important tenir en compte que tractant-se de nens petits, és probable que no sapiguin interactuar amb l'ordinador amb el ratolí o el teclat, per això farem ús de la tecnologia de la realitat augmentada.

Durant la fase d'aprenentatge de la lectura i escriptura per als nens, és habitual ensenyar-lis imatges i/o sons relacionats amb les lletres. D'aquesta manera els hi és més fàcil aprendre, ja que aconsegueixen associar una lletra a la imatge o al so. Prendrem com a referència aquests conceptes didàctics i els aplicarem en un joc informàtic, així aconseguirem un entorn que ajudarà als nens a avançar en l'aprenentatge de la lectura i l'escriptura.

Per a fer possible aquesta idea s'ha decidit fer ús de la tecnologia de la realitat augmentada. En poques paraules, la realitat augmentada es la barreja d'un món virtual amb un món real. El métode més fàcil per a fer possible la realitat augmentada s'obté amb un equip informàtic convencional més una càmera web. Gràcies a la realitat augmentada, la càmera web podrà obtenir informació del món real, interpretar la imatge capturada, mostrar-la a la pantalla de l'ordinador i modificant-la si és necessari.

En el projecte LectoRA, inclourem al món real unes cartulines que els nens tindran a la seva disposició durant el joc, cadascuna de les cartulines tindrà imprimida una de les lletres de l'abecedari i un petit codi de barres que anomenarem patró. Al món virtual tindrem diferents elements que anomenarem representacions virtuals, que seran imatges o sons relacionats a paraules. El repte del joc de LectoRA consistirà en demanar al nen que col·loqui una determinada lletra (cartulina) sota la webcam, el programa captarà la imatge i decidirà si la lletra colocada és correcta. Per tant, s'ofereix als nens una interacció immediata, sense cap tipus de barrera com podrien ser l'ús de teclat i ratolí, ja que jugant a LectoRA podran interactuar amb l'ordinador simplement col·locant uns elements tangibles (amb els quals ja estan acostumats a manegar) sota la webcam.

4


Figura 1. Esquema de realitat

D'altra banda, el projecte també inclou una part important destinada als professors dels nens. A més del joc que els nens jugaran, LectoRA té un programa que permetrà als professors crear els seus propis jocs, així com afegir noves representacions virtuals. Aquest programa serà molt fàcil d'utilitzar, i permetrà una personalització única dels jocs que jugaran els nens i es podran adaptar segons diferents nivells de dificultat. Per últim, tots els resultats de les partides dels nens son emmagatzemats en una petita base de dades; els professors podran consultar aquests resultats en qualsevol moment i crear nous jocs.

El desenvolupament es va començar utilitzant com a base un altre projecte presentat l'any anterior. Tot i que en un principi l'objectiu era treballar sobre aquest projecte i millorar-lo, finalment LectoRA va prendre una forma pròpia, el·liminant per complet la resta del codi antic i convertint-se en una nova aplicació.

5


1.2 Resum

En aquest document s'explicarà:

• ESTAT DE L'ART

El món de la realitat augmentada. Què és, com funciona, altres projectes on s'aplica la tecnologia...

• ESPECIFICACIONS DEL PROJECTE

Què és LectoRA? Com ha de funcionar?

• DISSENY

Com ha quedat la versió final de LectoRA?

Inclou disseny de classes, disseny de la base de dades, diagrama dels casos d'ús...

• DESENVOLUPAMENT

S'explicarà quines tecnologies i llibreries s'utilitzen a LectoRA i s'argumentarà perquè les he escollit, i es descriu com ha evolucionat l'etapa de desenvolupament i escriptura del codi.

• AVALUACIÓ I CONCLUSIONS

Després de diferents proves, també és important explicar quins han sigut els resultats, com es pot enfocar el projecte de cara al futur...

6


2 Estat de l'art

La realitat augmentada és una tecnologia relativament actual, ja que tot i que es podria dir que els seus inicis daten als anys 60, el terme 'realitat augmentada' va aparèixer en projectes informàtics durant els anys 90 quan les càmeres web comencen a formar part d'un equip informàtic convencional. Actualment no para de créixer, i s'està establint en molts camps, com per exemple la publicitat.

2.1 La realitat augmentada

El principal requisit de la realitat augmentada és poder barrejar el nostre món real amb un món virtual. Hi ha molts mètodes per a fer possible la realitat augmentada. Ara per ara, el més barat i factible és la combinació d'una pantalla d'ordinador i una simple càmera web. Amb aquests dispositius és possible complir l'objectiu d'aquesta tecnologia. En alguns casos, l'ordinador pot ser substituït per un teléfon móbil o similars.

Bàsicament, el que busca la realitat augmentada és captar la realitat com nosaltres la veiem i afegir-li nous elements o augmentar-ne el seu significat. Per a fer possible això, i tenint en compte la configuració esmentada (pantalla+càmera web), es segueix el següent procés:

• la càmera web capta la imatge

• el software identifica certs elements a la imatge

• la imatge captada és modificada segons l'objectiu de l'aplicació

• la imatge modificada es mostra per la pantalla

7


La gran majoria d'aplicacions que utilitzen la tecnologia de la realitat augmentada fan servir el que anomenem patrons.

Figura 3. Exemple de patró

Un patró és com un codi de barres. Gràcies a aquest identificador únic, l'aplicació pot identificar què és el que està veient la webcam i fer les modificacions necessàries.

El motiu pel qual es fan servir els patrons és perquè, pel moment, és el sistema més ràpid i eficient per a identificar els elements que augmenten la realitat. N'hi ha d'altres sistemes per a fer possible la comunicació entre el món real i el virtual com per exemple el body-tracking que detecten la posició del cos d'una persona, però requereixen unes càmeres cares i equips informàtics molt potents.

Una altra raó per la qual també és comú l'ús de patrons (sobretot a aplicacions amateurs) és l'aparició de ARToolKit. ARToolKit son unes llibreries creades pel Dr. Hirokazu Kato a l'any 1999. Gràcies a aquestes llibreries es va fer un gran pas en apropar la realitat augmentada a qualsevol ordinador del món, ja que es tracta d'unes llibreries molt eficients pensades exclusivament en el reconeixement de patrons per una webcam. A més, el codi original de les llibreries es va fer lliure i es va poder portar a altres llenguatges i plataformes; com per exemple a Adobe Flash, que durant el 2009 va rebre la seva propia versió de ARToolKit que aviat algunes companyies famoses utilitzarien com a promoció a les seves planes web.

En el cas de LectoRA, s'utilitza la realitat augmentada per a poder identificar els patrons que la càmera web capta. Tot i que la imatge que apareix en pantalla no es modifica, també existeix un món virtual que és creat per la col·lecció de representacions virtuals que conté la base de dades, i la seva projecció a la pantalla.

8


2.2 Interfícies naturals

La realitat augmentada forma part de l'àmbit de les interfícies naturals.

Anomenarem interfícies naturals a tots els sistemes d'interacció entre l'usuari i la màquina on la comunicació entre aquestos és més natural. És a dir, tots aquells sistemes que intenten eliminar tots els dispositius que fins ara eren necessaris per a la comunicació entre l'usuari i l'ordinador (ratolí i teclat), substituint-los per actes i accions naturals del nostre cos, com poden ser: tocar una pantalla tàctil, “manar” a l'ordinador amb la nostra veu, etc.

El principal objectiu de les interfícies naturals és, òbviament, facilitar l'ús dels ordinadors i dispositius similars. Però no només això, sinó que a més obre noves portes a gent amb discapacitats que fins ara no podien interactuar amb els ordinadors, per exemple.

Les interfícies naturals són la clara evolució de les actuals interfícies gràfiques de la majoria d'aplicacions informàtiques i sistemes operatius.

Figura 4. Evolució d'interfícies

Hi ha hagut varis intents d'eliminar aquesta barrera tecnológica, desenvolupant alguns dispositius d'entrada adaptats i aconseguir una comunicació més natural: Lector de targetes BSP, Concept Keyboard o la tauleta sensible IDL, per exemple. Però en aquests casos, tot i que s'intenta eliminar aquesta barrera, es crea una de nova i es que estem parlant d'adquirir nous dispositius que no formen part de la configuració estàndar d'un ordinador.

9


En el cas de LectoRA, l'ús d'elements tangibles (patrons) és també una interfície natural. Són simplement peces, rectangles de cartolina que representen les lletres. I gràcies a això, podem complir un dels principals objectius del projecte: el·liminar la necessitat d'utilitzar el teclat o el ratolí, apropant la interacció a usuaris joves que encara no han desenvolupat una destresa necessària per a manegar aquests dispositius.

Altres exemples d'ús d'interficies naturals poden ser les pantalles tàctils de alguns dispositius portàtils, o els nous mandos de control de videojocs amb sensors de moviment.

2.3 Usos de la realitat augmentada

Actualment, la realitat augmentada comença a implantar-se de manera massiva en diferents àmbits.

S'utilitza en publicitat, videojocs, catàlegs de productes, informació turística als telèfons móbils, llibres virtuals, etc. A continuació hi ha uns exemples on ja s'utilitza:

Publicitat: Diferents companyies estan començant a utilitzar la realitat augmentada per a promocionar-se amb petites aplicacions interactives que inclouen patrons als seus productes que poden “cobrar vida” quan els hi ensenyem amb la càmera a les seves pàgines web..

Medicina: Gràcies a aquesta tecnologia és possible recrear virtualment parts deteriorades d'un cos i facilitar certes operacions. També s'utilitzen unes ulleres especials (que actuen com a pantalla) per a visionar parts internes del cos, simulant un visor de rajos-X virtual.

10


Turisme: Molts museus ja utilitzen la realitat augmentada per a que els visitants puguin enfocar estatues, quadres, etc. amb els seus telèfons móbils amb càmera, d'aquesta manera poden obtenir informació adicional d'aquestos o fins i tot reconstruir-los virtualment si només runes.

Arquitectura: la tecnologia de la realitat augmentada pot ser utiltizada per a simular projectes de construcció.

És pot dir que la realitat augmentada suposarà un nou pas important en la tecnologia informàtica quan estigui totalment implantada.

2.4 La realitat augmentada aplicada a l'educació

Com ja s'ha comentat, en museus ja utilitzen aquesta tecnologia. També s'utilitza a parcs temàtics, exhibicions, etc.

Aquests llocs aprofiten les conexions inalàmbriques dels dispositius portàtils dels assistents per a mostrar informació sobre objectes o llocs, així com projeccions virtuals superposades a runes o paisatges, amb l'objectiu d'ensenyar com eren aquells elements en runes fa milers d'anys. A Japó van aprofitar aquesta idea per a fer un petit recorregut educatiu sobre els dinosaures.

11


D'altra banda, moltes companyies ja s'estan animant a treure llibres educatius que inclouen patrons a les seves pàgines.

D'aquesta manera, quan el lector es troba amb un patró a una de les pàgines pot ensenyar-lo a la videocàmera (amb un software especialitzat incluit conjuntament amb el llibre) i automàticament es generarà una imatge tridimensional damunt el llibre , inclús es pot reproduir so.

Si el lector gira el llibre, veurà que també gira el model tridimensional. D'aquesta manera es pot veure detalladament totes les parts de l'objecte, convertint l'educació en un procés molt més interactiu i entretingut.

12


Pel que fa a aplicacions informàtiques dedicades exclusivament a projectes educatius per a nens, encara no ha aparegut cap producte important. Però si que comencen a sorgir noves idees i projectes molt interessants. Per exemple un de la Universitat de Saragossa, on han desenvolupat un joc educatiu en el qual el nen veu a la pantalla una granja i ha de col·locar cartulines amb diferents animals sota la videocàmera per a poder veure l'animal dins la granja i sentir el so que emet.

O com el nostre projecte en qüestió: el LectoRA.

13


3 Especificacions del projecte

En aquest apartat s'explicarà què és LectoRA, per on es començara la fase de desenvolupament i quins passos es seguiran en aquesta.

3.1 Punt de partida

S'utilitzarà un prototip desenvolupat en un projecte anterior que inclou:

• implementació de les llibreries de detecció i reconeixement de patrons en Java

• construcció i disseny de patrons que simbolitzen lletres de pal

• aplicació per a associar patrons amb imatges, sons i/o text

Aquest és el punt de partida per al desenvolupament de LectoRA.

De cara a l'usuari final, l'aplicació anterior consta de dos móduls:

• Joc

En poques paraules, és un joc per a nens en el qual els apareix una imatge per pantalla i/o es reprodueix un so relacionat amb un element del món real. Els nens han de buscar una cartulina (patró) que contingui la lletra per la qual comença la paraula d'aquest element, i col·locarla sota la càmera web. Depenent del resultat, el joc continuarà o obligarà a buscar un altre patró si no era correcte.

• Eina per a configurar el joc

Els professors tenen a disposició una eina per a poder configurar el joc que jugaran els nens. És molt limitada i té poques opcions, però permet afegir a una simple base de dades paraules d'elements del món real i relacionar-los amb imatges i sons.

14


3.2 Requisits de l'aplicació

LectoRA estarà dividit en dos móduls, com l'aplicació original, però amb importants diferències i haurà de ser una aplicació que segueixi les següents pautes:

• Joc

LectoRA serà un joc per a nens que utilitzarà la tecnologia de la realitat augmentada per a ajudar en la seva etapa d'aprenentatge de la lectoescriptura.

El nen interactuarà amb la màquina amb uns elements tangibles (cartulines plastificades, per exemple) que tindran uns patrons impresos. Amb aquestos elements haurà de contestar a les preguntes i reptes que es proposaran.

El joc seguirà les mateixes regles que al projecte original, però a més s'inclouran les següents novetats:

• hi haurà diferents nivells de dificultat

• cada joc agafarà certes representacions virtuals d'una sola categoria

• podrà ser puntuat per temps o bé per torns

A més, el nen podrà jugar a diferents jocs seguits sense haver de reiniciar l'aplicació cada cop que s'hagi de canviar de joc.

• Eina per a configurar el joc

Els professors dispondran d'una eina de configuració que els permetrà:

• registrar els seus alumnes com a usuaris

• crear noves representacions virtuals i categories on es classificaran

• relacionar imatges i sons a aquestes representacions virtuals

• crear jocs per als seus alumnes amb multitud de paràmetres

• consultar els resultats de les partides dels seus alumnes

Tot això serà possible amb una aplicació molt fàcil d'utilitzar, inclús per a usuaris no experimentats a la informàtica.

15


3.3 Passos a realitzar

L'objectiu és millorar els dos móduls esmentats a l'apartat enterior. Abans, però, s'ha de fer una llista dels passos que s'hauran de seguir per a complir l'objectiu:

1. Conèixer l'entorn desenvolupat fins al moment.

És necessari aprendre el funcionament de ARToolKit i com està dissenyat el projecte anterior.

2. Conèixer el procés de generació d'un patró i la seva detecció per part de l'aplicació.

Per a aconseguir-ho, modificarem els patrons i refarem el procés fins a millorar el resultat.

3. Afegir a l'aplicació la lectura de continguts des d'una base de dades. Hi ha dos possibilitats:

• MySQL

• HSQLDB

4. Dissenyar la base de dades per a complir els requisits de la nova aplicació.

És necessari fer un bon disseny que pugui satisfer les necessitats de l'aplicació esmentades al punt 3.2.

5. Dissenyar la interfície d'usuari de l'aplicació perals requisits demanats.

Ha de ser principalment fàcil d'utilitzar i ràpida.

6. Desenvolupar el codi de l'aplicació necessari per a proporcionar les utilitats demanades. Aquí es barallen també dos alternatives:

• Aplicació local

• Aplicació web

16


4 Disseny

4.1 Disseny de classes

Figura 9. Diagrama de classes

17


4.2 Disseny de la base de dades

Figura 10. Disseny de la base de dades

18


4.3 Interfície gràfica

4.3.1 Diagrama de casos d'ús

Figura 11. Diagrama de casos d'ús

Es comprova que el professor és el que podrà manegar l'aplicació d'una forma més complexa.

Això és a causa d'un dels objectius de LectoRA: el nen estarà limitat a jugar a jocs amb els patrons i en cap moment manegarà una interfície gràfica complexa amb el ratolí o el teclat (farà ús total d'una interfície natural). Mentre que per part del professor, aquest tindrà total llibertat per a crear els diferents jocs per als seus alumnes (una interfície gràfica d'usuari serà obligatòria), així com oferir ajuda a aquests en cas que ho necessitin.

Per tant, l'única part on es centrarà el desenvolupament d'una interfície gràfica important és la del professor.

19


4.3.2 Disseny interfície gràfica d'administració

Com que es tracta d'una aplicació preparada per a qualsevol usuari (amb experiència informàtica o no), cal pensar en fer un bon disseny fàcil d'utilitzar i el més minimalista possible per a que l'usuari final no es perdi.

La idea és tenir una pantalla principal on es pugui accedir a unes pantalles secundàries que permetin fer les quatre principals accions del professor.

Figura 12. Disseny simplificat de la interfície gràfica

20


5 Desenvolupament

Aquí explicaré com va evolucionar el desenvolupament de l'aplicació, un cop ja tenia pensat el disseny de classes, la base de dades i la interfície gràfica.

5.1 Cronologia

Inicialment, i com indicava l'enunciat del projecte, el punt de partida era treballar sobre un prototip desenvolupat en un projecte anterior. Havia d'agafar la idea principal d'aquest projecte i implementar les noves característiques que em demanaven.

5.1.1 Conèixer l'entorn desenvolupat fins al moment

Per a començar, calia llegir i entendre tot el disseny del projecte anterior.

El projecte anterior feia ús de:

• ARToolKit per a C

• JNA per a fer crides de C a Java

• Programa desenvolupat en Java

El primer problema va sorgir a l'hora de muntar i compil·lar el projecte. Mai havia utilitzat les JNA per a fer crides natives d'unes llibreries d''un sistema operatiu a Java. De fet, no sóc partidari de fer servir aquest tipus de wrappers. D'altra banda, la jerarquia de paquets i directoris del projecte no ajudava a muntar-lo més fàcilment.

Quan per fi vaig aconseguir compil·lar el projecte el vaig executar i vaig estar fent proves amb els patrons, movent-los, tapant-los, etc. El primer problema va aparèixer gairebé d'immediat. El joc estava preparat per a que l'alumne col·loqués un patró sota la webcam i el programa li diria si és correcte o no, però abans que pogués col·locar un patró va detectar una 'F' a la taula on encara no hi havia cap.

21


Vaig començar a mirar el codi i a entendre com funcionava el ARToolKit.Vaig descubrir que aquestes llibreries, de tant en tant, detectaven patrons inexistents a la imatge. Això no es podria dir que és un problema de les llibreries, sinó d'un defecte de la càmera web: sol passar que algun frame pot contenir petits defectes a la imatge que poden enganyar les funcions de detecció de patrons. Per tant, era un detall a tenir en compte més endavant i que s'hauria de solucionar d'alguna manera (veure punt 5.4).

A més, l'interfície gràfica d'administració era pobre i poc entendible, era fàcil perdre's. Aquest seria un altre punt important.

Finalment, vaig decidir començar tot des de zero. Escrivint jo mateix el codi, però mirant el del projecte anterior per a totes les instruccions del ARToolKit, per a entendre com s'inicialitza, com carrega els patrons, com els detecta, etc. La seva implementació en Java, el jARToolKit, té les mateixes funcions que el ARToolKit original, així que el codi antic em podria servir de base per a entendre el seu funcionament.

5.1.2 Conèixer el procés de generació d'un patró i la seva detecció

Abans de començar a reescriure el codi, havia de començar a pensar en un nou sistema per a dissenyar els patrons.

Juntament amb el codi del projecte anterior, també vaig rebre els antics patrons que utilitzaven ells.

Figura 13. Patrons antics

22


Es pot comprovar que aquests patrons no eren aptes per als nens. Les lletres eren dins el patró, però moltes d'elles inclouen, també, petits detalls com línies o punts. Per què?

Figura 14. Matriu generada per ARToolKit superposada al patró antic

Quan es crea un nou patró amb l'eina de creació de patrons (explicat al punt 5.2), la imatge capturada es divideix en una matriu de 16x16 bytes. Cada byte inclou la informació de la lluminositat (com que els patrons sempre són en blanc i negre no cal guardar la informació dels tres colors RGB). El que fa es reduir la imatge a 16x16 aplicant-hi un filtre d'anti-aliasing per a perdre el mínim detall possible, després guarda la informació de la matriu dels pixels i la guarda 4 vegades girant-lo 90º a cada volta (així aconsegueix poder detectar els patrons inclús quan estan girats més eficientment).

Aviat vaig entendre que els autors del projecte anterior van afegir aquest detalls per a que les funcions de detecció de patrons de ARToolKit poguessin distingir les diferents lletres. Com que una matriu de 16x16 és molt petita per a guardar una imatge tan gran, moltes lletres compartien una matriu força semblant.

En un principi el meu objectiu era modificar aquests patrons per tal d'evitar haver d'afegir aquests detalls, ja que seria molt confús per als nens. Però va ser completament impossible. En el moment que els treia d'una lletra, apareixien conflictes amb una altra.

23


Després de molts intents, em va sorgir una bona idea que permetria no només el·liminar aquests detalls, sinó també fer els elements tangibles (on anirien els patrons) molt més grans i pràctics per als nens.

De fet, la idea és bastant simple. En comptes d'intentar inserir una lletra dins el patró, el que calia era ficar la lletra fora del patró. I dins el patró hauríem de posar un codi de barres completament diferent de cadascun i no caldria que s'assemblés a cap lletra.

A més de tot això, tenint en compte la forma de treballar del capturador de patrons de l'ARToolKit, vaig pensar en fer els patrons completament pixelats. L'objectiu d'això és senzillament haver d'evitar que durant la reducció de la imatge del patró i el seu filtre d'anti-aliasing es creïn zones grises, només hi haurà zones blanques i negres. Així, el fitxer final amb la matriu del patró serà gairebé perfecte. Això, no és res nou, ja que per exemple els QR Codes fan servir exactament la mateixa idea.

Figura 15. Matriu generada per ARToolKit superposada al patró nou

A la figura es pot comprovar que tots els punts de la matriu coincideixen només a una zona blanca o a una zona negra complerta. No hi ha cap punt on hi hagi una zona de negre i una de blanca. Així, en el moment de fer el redimensionament de la imatge a 16x16, no tindrà cap defecte.

24


I per a acabar-ho d'arrodonir, vaig fer tots els patrons de 4x4 punts grans “pixelats” (és a dir, 4x4 punts de la matriu coincidiran amb un punt gran de la meva imatge), d'aquesta manera puc imprimir el patró més petit a l'element tangible, per a que destaqui la lletra gran i passi a ser un simple i petit identificador.

I aquest va ser el resultat:

Figura 16. Patrons nous

Es comprova que ara les cartulines contenen la lletra molt gran i no dóna peu a confusions, el patró passa a un segon plà. Així s'oferirà al nen una experiència molt més real, i podrà diferenciar perfectament la lletra i el patró.

Per últim, un altre avantatge amb el nou sistema de patrons és que aquests es poden reutilizar per a fer altres cartulines. Per exemple, si el professor volgués fer un joc que es jugui amb lletres lligades en comptes de lletres de pal, només caldria modificar les lletres grans, mantenint els patrons iguals, així seguirien sent compatibles amb el joc.

25


5.1.3 Afegir a l'aplicació la lectura de continguts des d'una base de dades

Com que havia decidit reescriure l'aplicació desde zero, ja no calia pensar en com modificar el projecte anterior per a afegir una base de dades SQL al projecte anterior.

Aquest utilitzava arxius de text TXT per a emmagatzemar la informació de les representacions virtuals (paraules, imatges i sons). Manegar aquest tipus de fitxers que contenen certa quantitat de text és molt complicat, així que afegir una base de dades SQL permetria una total personalització de la distribució de la informació.

Amb la base de dades SQL seria molt més fàcil modificar l'estructura de les dades a emmagatzemar sempre que es volgués durant l'etapa de desenvolupament, per això era important decidir quin tipus s'utilitzaria (punt 5.2.5). Un cop escollit el sistema HSQLDB, només caldria dissenyar la base de dades (punt 4.2).

5.1.4 Interfície d'usuari de l'aplicació

Com que en el meu cas la base de dades manegaria molta més informació que la del projecte anterior, no podia reutilitzar la interfície gràfica d'usuari antiga ja que era molt simple i no podria oferir-me les funcionalitats que demanva.

Així que, de la mateixa manera que vaig oblidar-me de reutilitzar la base de dades del projecte anterior, també era important dissenyar una nova interfície d'usuari, la que farien servir els professors.

Un cop fet el disseny d'aquesta interfície amb el seu diagrama dels casos d'ús, només quedava decidir quina plataforma utilitzar per a poder desenvolupar-la. Aquí també es barallaven dues possibilitats, i finalment es va decidir per Java (punt 5.2.6).

26


5.1.5 Passos finals

Un cop complerts els objectius:

• solucionar el problema dels patrons antics

• dissenyar la base de dades

• dissenyar la interfície gràfica

Ja es podia començar a escriure el codi.

No recordo haver-me trobat amb cap barrera important durant aquesta fase. El desenvolupament va ser fàcil gràcies a la coherència de la jerarquia de paquets i classes.

Vaig tenir problemes amb l'execució de LectoRA des d'un arxiu extern (.BAT) per culpa de les llibreries externes .DLL de JOGL, però això no forma part del desenvolupament. Les principals barreres van ser solucionades gairebé al moment.

27


5.2 Decisions de disseny

En aquest apartat explicaré quin llenguatge de programació he fet servit, quines llibres he utilitzat i les raons per les quals he hagut de sacrificar altres alternatives. A més, també descriuré diferents idees adicionals que van sorgir per decisió própia (no estaven a l'enunciat) per a millorar el resultat final de LectoRA.

5.2.1 Llenguatge de programació escollit

De cara al desenvolupament del joc (no l'aplicació de configuració) era important decidir quin llenguatge s'utilitzaria. El projecte original utilitzava Java, i JNA per a fer les crides a ARToolKit.

No tenia cap dubte a l'hora d'escollir. Vaig decidir utilitzar Java principalment perquè és el llenguatge amb el qual he treballat des de el primer any de carrera. El desenvolupament seria fàcil i continu si tot anava bé, ja que és un llenguatge que conec molt bé i l'IDE que utilitzaria (Eclipse) ja el dominava. Així doncs, no caldria perdre el temps en aprendre'n un de nou.

Java ofereix molts avantatges:

• és obert i està en continua evolució

• està ben documentat i hi ha molta informació a la red

• és un llenguatge semi-interpretat

• això ofereix la possibilitat de convertir fàcilment l'aplicació en multiplataforma en el futur si fos necessari

• orientat a objectes

• el colector de brossa gestiona la memòria automàticament

entre altres.

28


Java seria, doncs, el llenguatge de programació escollit per al desenvolupament del projecte.

5.2.2 j/ARToolKit

Com que inicialment s'havia de treballar amb un projecte ja existent, no es barallava cap altra possibilitat per a escollir les eines o llibreries per a la detecció de patrons. ARToolKit era l'única opció i, de totes maneres, la més adequada si n'hi hagués altres possibilitats.

Les ARToolKit apareixen a internet a l'any 1999, firmades pel Dr. Hirokazu Kato de del grup Human Interface Technology Laboratory (HIT Lab) de la Universitat de Washington.

Les ARToolKit són unes llibreries dissenyades exclusivament per a la construcció d'aplicacions amb la realitat augmentada com a idea principal. Aquestes ententen la realitat augmentada com a la superposició d'imatges en un món real que es visualitza per la pantalla de l'ordinador.

Característiques principals:

• Codi de detecció per a simples patrons amb vorera negra

• Configura i calibra la càmera automàticament

• Suficientment ràpid per a aplicacions de realitat augmentada en temps real

• Codi lliure

29


Una de les dificultats al desenvolupament d'aplicacions de realitat augmentada és poder localitzar patrons a la imatge i identificar les seves posicions a l'espai tridimensional (per a poder “augmentar” el significat de la imatge). ARToolKit utilitza de forma transparent uns algoritmes de computació visual per a trobar els patrons i les seves posicions a la imatge, de forma que el desenvolupador no s'ha de preocupar per complexos algoritmes perquè amb una sola línia de codi ja obté la posició relativa de tots els patrons a la imatge. Així, ARToolKit solventa un dels problemes clau a la realitat augmentada.

L'objectiu principal de ARToolKit és poder apropar la realitat augmentada a qualsevol programador, ja que realment només ofereix instruccions mínimes per al reconeixement de patrons quadrats amb un requadre negre, que són suficients per a que els programadors puguin donar forma a les seves idees fàcilment. Les possibilitats són molt àmplies, el desenvolupament d'aquestes aplicacions amb les llibreries és molt fàcil i es poden obtenir uns resultats impressionants.

La seva senzillesa i la seva facilitat d'ús l'han convertit en unes de les llibreries més famoses del sector, utilitzant-se fins i tot a companyies importants. A més, el seu codi és lliure, cosa que ha permés que el desenvolupament sobre aquestes no pari, i altres programadors han continuat afegint noves característiques.

El fet de tenir el projecte anterior documentat, que feia un bon ús de les llibreries ARToolKit era clau per a no haver de pensar en altres llibreries i utilitzar directament aquestes.

Malauradament, l'anterior projecte feia ús de les llibreries ARToolKit originals (compilades per a C). Òbviament, per a poder utilitzar-les desde Java era necessari un element addicional per a poder fer crides. L'autor utilitzava Java Native Acces (JNA).

A mi no m'agradava la idea d'utilitzar un wrapper per a això. Principalment perquè el codi quedava bastant brut i caótic; i a més, significava que si en algun punt de la fase de desenvolupament volia fer multiplataforma el projecte seria impossible, ja que s'utilitzava ARToolKit compilat per a Windows.

Vaig buscar una alternativa per internet i aviat coneixeria jARToolKit.

jARToolKit no és més que la implementació en Java de ARToolKit. Era la solució perfecta. No només podia prescindir de les JNA per fi, sinó que a més la inserció al codi era molt simple. jARToolKit ve distribuit en un simple fitxer .jar.

30


Tot i així, jARToolKit encara no era una implementació perfecta de les ARToolKit originals, ja que fa ús d'unes llibreries extra (pots escollir entre GL4Java, JOGL i Java3D) per al manegament de la imatge i els càlculs de les posicions dels patrons en aquesta a l'espai tridimensional. Però això no era cap problema perquè, aquests paquets extra també són multiplataforma.

5.2.3 Gestor de base de dades

Les possibilitats recomanades a l'enunciat eren:

• Mysql

• HSQLDB

A més d'aquestes dues, també coneixia una alternativa anomenada Derby, molt semblant a HSQLDB en quant a l'estructura, així que vaig decidir afegir-la com a una possibilitat més.

Mysql és potser el sistema de manegament de bases de dades més usat a tot el món. Tot i així, potser no era l'elecció més adequada pel projecte. Mysql està preparat per a bases de dades importants, i la seva instal·lació (i conseqüent incorporació al servidor) als ordinadors pot ser relativament difícil per a un usuari no experimentat.

I com que una de les idees principals del projecte era desenvolupar una aplicació totalment intuïtiva i fàcil d'utilitzar des de el primer moment per a gent aliena a la informàtica, finalment la vaig rebutjar.

D'altra banda, tenia HSQLDB i Derby com a alternatives. Totes dues són implementacions d'un sistema de gestió de bases de dades basades purament en Java, tot un avantatge per a mi ja que és el llenguatge utilitzat durant la carrera i poc a poc està guanyant terreny a altres llenguatges d'alt nivell.

31


Els dos sistemes no són més que unes llibreries empaquetades en format .jar, fàcils d'importar a qualsevol aplicació en Java amb una sola línia de codi. Això suposava un gran avantatge de cara a la incorporació de la base de dades al codi del projecte anterior.

Tampoc requereixen cap tipus d'instal·lació complicada, ja que es poden incloure com a paquet a junt amb l'aplicació principal. Definitivament, aquesta seria la meva opció.

L'únic que em faltava era decidir si fer servir HSQLDB o Derby. Tots dos permeten fer el mateix, però tenen algunes diferències. Vaig buscar informació i opinions d'usuaris d'ambdós sistemes.

Tot i que Derby es molt més antic (1996) que HSQLDB (2001), es tracta d'un projecte que ha passat per les mans de molts propietaris. El codi original va arribar a ser, fins i tot, propietat d'IBM, que finalment va cedir-lo a Apache Software Foundation, per a adaptar-lo al que seria Derby anys després. 10 anys després del naixement del projecte, Sun va decidir incloure Derby al JDK amb el nom de Java DB.

El fet que Derby hagués estat en diferents companyies, va fer que part de la idea original (simplicitat a l'hora de manegar bases de dades amb Java) es perdés, i el projecte canviés de rumb en moltes ocasions.

Per aquesta mateixa raó, al 2001 un grup de programadors va fundar la HSQL Development Group. El seu objectiu era crear una alternativa a Derby, amb millors prestacions.

El resultat va ser HSQLDB, que en menys de la meitat de l'espai (Derby 2MB i HSQLDB 700kb) ofereix les mateixes funcions però amb uns resultats molt més òptims i eficaços. La comunitat de programadors de Java prefereixen, generalment, HSQLDB en comptes de Derby, tot i que aquest últim formi part del JDK oficialment.

Vaig fer unes proves ràpides, i en pocs moments ja m'havia familiaritzat amb el sistema HSQLDB. Són unes llibreries molt simples de cara a l'usuari, però molt potents.

La següent figura demostra que HSQLDB es una opció encertada. Es tracta d'unes proves realitzades amb diferents sistemes de gestió de bases de dades, totes utilitzant un script anomenat PolePosition (www.polepos.org) preparat per a fer proves de velocitat i eficiència en aquests sistemes. Es veu clarament que HSQLDB ha oferit uns resultats molt més ràpids.

32

http://www.polepos.org/


Figura 18. Comparativa rendiment sistemes de bases de dades

5.2.4 Tipus d'aplicació: local o web

A l'hora de seleccionar quin sistema utilitzaria per a crear la interfície gràfica d'usuari d'administració (per a que els professors poguessin configurar el joc LectoRA) tampoc hi va haver cap dubte. L'enunciat oferia dues possibilitats:

• Aplicació local

• Aplicació web

Desenvolupar una aplicació web només serviria per a gastar més temps aprenent un nou llenguatge i adaptant el programa per a poder llegir i escriure dades a HSQLDB, tot i que la idea de tenir l'aplicació web a un servidor i poder accedir desde qualsevol ordinador de la xarxa sonava interessant.

Sense cap dubte, em vaig decantar per fer una aplicació local en Java que s'hauria d'instal·lar només a l'ordinador on estigués oberta la base de dades. No seria accessible a qualsevol ordinador de la xarxa, però tampoc seria un problema.

Utilitzaria Swing per al manegament de botons i finestres ja que també el conec molt bé i seria un avantatge.

33


5.3 Treball addicional

Durant el desenvolupament de LectoRA van aparèixer dos petits problemes que no impedien el correcte funcionament de l'aplicació, però si que dificultaven l'evolució del projecte. Per a agilitzar el procés, vaig dur a terme un treball addicional no inclós a l'enunciat que no només millorarien el resultat del projecte, sinó que m'ajudarien a fer més fàcil la part del desenvolupament del codi o, inclús la fase del joc de proves.

5.3.1 Algoritme de detecció de frames erronis

Durant les primeres execucions del projecte anterior per tal d'habituar-me a les ARToolKit vaig notar que, de tant en tant, la funció per a obtenir els patrons a la imatge retornava certs patrons que realment no hi eren allà.

Després de més proves, vaig treure les següents conclusions:

• com que les ARToolKit busquen quadrats amb la vorera negra, una simple ombra de qualsevol objecte a la taula podia enganyar i les llibreries creurien que són un patró

• la imatge de la video càmera no sol ser neta i pot tenir petites interferències o defectes visuals que també poden influènciar al funcionament de les ARToolKit

Les solucions més ràpides i fàcils d'incloure eren:

• configurar sempre la càmera web amb la resolució màxima possible

• reduïr el nombre de quadres per segon (fps)

Malauradament, cap de les propostes va donar resultats satisfactoris.

34


Així que vaig decidir crear una petita funció que ajudés a evitar els frames erronis.

La idea seria retornar els patrons que hi ha a la imatge només quan no es movéssin i quan es repetissin els mateixos patrons durant X frames seguits. És a dir, hi hauria un comptador que ens diria si tot va bé (cap patró s'ha mogut i són sempre els mateixos), en el moment que aquest comptador arribés a un valor determinat es podria donar per bo i es retornaria la llista de patrons a la imatge. Aleshores, si en cap moment apareixia un frame erroni, cap dels patrons es retornaria i el comptador tornaria a comptar des de zero.

Això semblava una bona idea però tenia un greu defecte i és que si en cap moment els frames erronis apareguessin molt seguits, el comptador mai arribaria al final i mai podria detectar els patrons correctes. Per a solucionar-ho, havíem de crear unes variables (anomenades marges d'errors) que ens dirien la freqüència en la qual es podria permetre un error.

Les variables necessàries serien les següents:

//el patrons que ARToolKit ens ha retornat

int[] patronsTrobats;

//mantindrem una cópia dels patrons del frame anterior

int[] copiaPatrons;

//comprovarem en tot moment si la cópia i els patrons del frame actual son els mateixos

booleà esDiferent;

//comptadors

int intentsError=0;

int intentsIgual=0;

CONSTANT margeErrorDiferent=110;

CONSTANT margeErrorIgual=80;

35


I el pseudo-codi de la funció del joc amb l'algoritme en qüestió és el següent:

//comença el joc

bucleJoc(;;){

//si s'ha acabat el temps de joc sortir

si(tempsHaFinalitzat)

break;

actualitzarGrafics();

esDiferent=fals;

//demanem els patrons actuals a ARToolKit

patronsTrobats=ARToolKit.demanarPatrons();

//comprovem que siguin els mateixos

si(copiaPatrons==nul || patronsTrobats.tamany !=

copiaPatrons.tamany){

esDiferent=cert;

}sino{

per(int i=0;i<patronsTrobats.tamany;i++)

if(patronsTrobats[i]!=copiaPatrons[i]){

esDiferent=cert;

break;

}

}

36


//si han canviat els patrons trobats...

si(esDiferent){

si(intentsError==margeErrorDiferent){

per(int i=0;i<copiaPatrons.tamany;i++){

copiaPatrons[i]=patronsTrobats[i];

}

intentsError=0;

intentsIgual=0;

}sino{

intentsError++;

}

//si són iguals

}sino{

intentsError=0;

si(intentsIgual==margeErrorIgual){

si(comprovarResposta(patronsTrobats)){

//Resposta correcta!!

break;

}

}sino si(intentsIgual<margeErrorIgual){

intentsIgual++;

}

}

}

37


5.3.2 Mini-API de HSQLDB

Per a finalitzar l'apartat de treball addicional explicaré breument unes petites instruccions própies que vaig haver de fer per a manegar la base de dades.

Ja tenia decidit quin sistema de bases de dades faria servir (apartat 5.2.3): HSQLDB, però uan va arribar el moment d'utilitzar-lo em vaig adonar de que tot i que ser unes llibreries molt potents, les crides a la base de dades SQL retornaven els valors en variables própies de la classe java.sql.ResultSet.

Com que treballar amb aquestes variables seria difícil, vaig pensar que seria una bona idea fer-me una mini-API de HSQLDB amb les funcions que faria servir més sovint i transformant sempre els resultats en Strings o variables natives de Java.

Aquestes funcions es troben a la classe:

common.manegador_hsqldb.ManegadorHSQLDB

i els seus funcionaments són totalment auto-explicatius si es mira el codi.

38


6 Avaluació

6.1 Joc de proves

Per a comprovar el correcte funcionament de l'aplicació s'han realitatzat totes les proves possibles, intentant passar per tots els casos en que es pot trobar l'aplicació (això inclou no només proves amb la col·locació dels patrons, sinó també proves amb les finestres de la interfície gràfica d'usuari).

6.1.2 Joc de proves amb el joc LectoRA

Compte que els nens utilitzaran una interfície natural per a comunicar-se amb l'ordinador, és necessari que s'evitin tota mena d'errors possibles. Quan comencen a jugar, el teclat i el ratolí passen a un estat inactiu, ja que no serveixen absolutament per a res. Si hi hagués cap error durant el joc, només es podria tancar la finestra amb el ratolí, perdent tots els resultats de la partida. Aquestes possibles situacions han sigut tractades, i gràcies a la coherència de la base de dades és pràcticament impossible que apareguin errors com tenir un joc sense patrons o sense representacions virtuals.

D'altra banda, també és important tenir en compte els possibles errors que el nen pot crear mentre juga només amb els patrons, per tant, s'ha comprovat que:

• mostrar més d'una lletra als nivells 1 i 2

• mostrar més de quatre lletres al nivell 3

• mostrar lletres en qualsevol ordre al nivell 4

Els resultats han sigut satisfactoris, a la pantalla surt la icona de incorrecte i no permet als nens fer trampes.

39


També s'ha provat de jugar en diferents situacions:

• diferents nivells de lluminositat

• diferent distància entre la càmera web i la taula

• col·locant els patrons girats

També han resultats satisfactoris. Aquestos resultats eren completament impossibles d'assolir al projecte anterior, i tot és gràcies al nou sistema de patrons.

6.1.3 Joc de proves amb l'aplicació d'administració

Ja hem parlat de les proves fetes al joc LectoRA, però també és important dur a terme més proves a l'aplicació de configuració. Si no es tractessin tots els errors possibles podria donar problemes com crear jocs sense cap paràmetre o alumnes sense nom que, durant l'execució del programa no afectaria en res però a l'hora de jugar podria causar greus problemes. Per exemple:

• adjuntar una imatge amb un format diferent dels recomanats a una representació virtual

• crear un joc de nivell 1 sense marcar cap paràmetre

• crear un usuari (alumne o professor) sense nom

6.2 Presentacions públiques

LectoRA s'ha presentat al públic en dues ocasions.

Durant l'event de la 15a Setmana de la Ciència a Tarragona (Novembre 2009) LectoRA va estar exposat al públic. Molts visitants van dedicar una mica del seu temps a provar l'aplicació, entre ells alguns professors. Les seves opinions eren positives i creien que era una idea amb molt potencial.

40


Més endavant, també es va dur a dues escoles de Tarragona. Després d'una presentació conjuntament amb una demostració de les capacitats i les facilitats d'ús, els professors van donar la seva opinió, així com diferents suggerències i noves idees. És important destacar que sent treballadors del sector educatiu, és important tenir en compte les seves propostes, ja que seran els futurs usuaris de l'aplicació.

6.3 Línies futures

LectoRA ha sigut un projecte en continu desenvolupament, des del seu començament a l'estiu de 2009.

Gràcies a les presentacions públiques esmentades anteriorment, vaig poder rebre suggerències i s'han fet les modificacions necessàries per satisfer les necessitats dels futurs usuaris de l'aplicació.

Com per exemple la inclusió de l'opció d'utilitzar lletres lligades en comptes de lletres de pal a l'hora de crear un joc. Aquesta proposta la van fer professors de les dues escoles a les quals es va fer una demostració.

De cara al futur, el projecte pot continuar el seu desenvolupament sense cap problema. Gràcies a la seva estructura de codi és possible continuar-lo, afegint noves característiques o bé millorant les ja existents.

A més, les dues escoles que es van interessar per LectoRA ja tenen una cópia de l'aplicació llesta per a ser instal·lada. Durant el curs 2010-2011 volen provar-la, i estarem en contacte per a qualsevol suggerència, possibles errors que puguin sortir, millores en la interfície gràfica per tal de fer-la encara més senzilla, etc.

41


7 Conclusions

L'objectiu principal d'aquest projecte era dissenyar un entorn d'aprenentatge de lectura utilitzant la tecnologia de la realitat augmentada. Alhora, aquesta aplicació hauria de ser un joc senzill i divertit per als nens, que els permetés interaccionar amb l'ordinador sense cap necessitat d'utilitzar el ratolí o el teclat. Podem dir que s'ha dut a terme satisfactòriament.

La inclusió de la realitat augmentada permetrà als nens, no només interaccionar amb una interfície natural, sinó a més fer un bon ús de la tecnologia barrejant el seu món real (els elements tangibles amb els que jugaran) amb un món virtual (les paraules i representacions virtuals que apareixeran en pantalla o es reproduiran als altaveus).

És important destacar que durant el desenvolupament del projecte van sorgir diferents problemes com el redisseny total dels patrons que formen la col·lecció de lletres o la detecció de frames erronis que detectava la càmera web ocasionalment. Aquests problemes han servit no només per a renovar el sistema i l'estructura del projecte, sinó també per a millorar l'experiència del joc per als nens.

D'altra banda, un altre objectiu del projecte era poder desenvolupar una aplicació d'administració del joc destinat als professors. Aquesta aplicació hauria de ser fàcil d'utilitzar, permetria manegar els usuaris, les representacions virtuals i els jocs en sí, i hauria de funcionar conjuntament amb una base de dades.

En quant al joc LectoRA, es demanava que fos totalment personalitzable. Tots els paràmetres de configuració de joc esmentats a l'enunciat es van implementar. I, a més, sorgien noves idees durant la fase de desenvolupament del projecte, com ara nous nivells de dificultat o la possibilitat de jugar amb lletres de pal o lligades.

Encara que la idea principal de LectoRA era treballar sobre un projecte antic, finalment es va començar tot desde zero. Però el codi i la documentació de l'anterior van ser útils per a algunes consultes. Les diferències de LectoRA respecte el projecte base són notables, però podem destacar la inclusió de la base de dades SQL, el nou sistema de jocs i l'algoritme per a la correcció de frames erronis.

42


Com que no hi ha gaires aplicacions conegudes que segueixen la mateixa filosofia que LectoRA és difícil decidir si el projecte en qüestió pot tenir cap avantatge respecte d'altres semblants. Però sabem que diferents escoles s'han interessat en el projecte i estan disposats a provar-lo de cara al curs vinent,(com s'ha explicat a l'apartat d'Avaluació), i això és un punt a valorar, ja que ens assegura que hem complert els objectius principals de fer una aplicació útil, ràpida i interessant.

El codi ha quedat ben estructurat, i pot permetre una futura reutilització per a projectes semblants o fins i tot la creació una nova branca sobre LectoRA, utilitzant-se com a base, amb millores respecte l'original.

Com a desenvolupador del projecte, puc dir que ha estat una experiència gratificant.

Tot i que coneixia la tecnologia de la realitat augmentada, mai m'havia imaginat totes les possibilitats que pot tenir. Tampoc creia que m'hauria enganxat tant. Potser la finalitat de poder aproximar la informàtica d'alguna manera als nens, i de treballar amb interfícies naturals, han servit com a al·licient extra a l'hora de desenvolupar el projecte, ja que sempre m'han agradat les noves idees que sorgeixen per a ajudar en l'evolució de la interacció entre ordinadors i persones.

43


8 Recursos utilitzats

Informació sobre tecnologies i llibreries utilitzades

ARToolKit

http://www.hitl.washington.edu/artoolkit/

jARToolKithttp://sourceforge.net/projects/jartoolkit/files/

JOGL (Java bindings for OpenGL)https://jogl.dev.java.net/

HSQLDBhttp://hsqldb.org/

GIMP (per al disseny de patrons)http://www.gimp.org.es

APIs i/o manuals consultats

API de ARToolKit

http://artoolkit.sourceforge.net/apidoc/index.html

API de JOGLhttp://jogamp.org/jogl/doc/userguide/

API de Swinghttp://java.sun.com/j2se/1.4.2/docs/api/javax/swing/package-summary.html

Manual de HSQLDBhttp://www.hsqldb.org/doc/guide/

44

http://www.hsqldb.org/doc/guide/

http://java.sun.com/j2se/1.4.2/docs/api/javax/swing/package-summary.html

http://jogamp.org/jogl/doc/userguide/

http://artoolkit.sourceforge.net/apidoc/index.html

http://www.gimp.org.es/

http://hsqldb.org/

https://jogl.dev.java.net/

http://sourceforge.net/projects/jartoolkit/files/

http://www.hitl.washington.edu/artoolkit/


9 ANNEX A: Instruccions de jARToolKit

int loadPattern(String path)Carrega i col·loca a la cua el patró que es troba a la ruta passada per paràmetre.

Paràmetres:

path : ruta relativa del patró a carregar

Retorna:

0 si tot va bé

int freePattern(int i)Allibera el patró carregat a la posició i de la cua de patrons i reordena la cua.

Paràmetres:

i : posició del patró a alliberar

Retorna:

0 si tot va bé

int[] detectMarker(void* buffer,int threshold)Detecta patrons a una imatge donada per paràmetre.

Paràmetres:

buffer : array de la matriu de pixels on es buscaran patrons

threshold : valor de lluminància

Retorna:

array de les posicions a la cua de patrons dels patrons detectats

si un valor de l'array és -1 significarà que l'ha detectat però no l'ha reconegut

45


JARToolKit.create()Crea una instància necessària per a la crida de les funcions ARToolKit.

Retorna:

referència a la instància

int paramLoad(String params)Carrega els paràmetres de la càmera web (resolució, driver, etc).

Paràmetres:

params : cadena amb els paràmetres (documentats a la API de jARToolKit)

Retorna:

0 si tot va bé

int paramChangeSize(int width, int height)Reinicia la resolució de la càmera web per al reescalat de la imatge (opcional, però

ofereix millors resultats).

Paràmetres:

width : amplada de la matriu de pixels de la resolució

height : alçada de la matriu de pixels de la resolució

Retorna:

0 si tot va bé

int initCparam()S'inicia la càmera web amb els paràmetres carregats amb paramLoad. Obligatori.

Retorna:

0 si tot va bé

46


10 ANNEX B: Manual d'usuari

10.1. Introducció

10.1.1. Què és LectoRA?

LectoRA és una aplicació informàtica d'aprenentatge orientada a alumnes i professors

d'escola.

Mitjançant la tecnologia de la realitat augmentada, l'objectiu de LectoRA és ensenyar als

nens a llegir i escriure alhora que s'inicien en el món de la informàtica amb un divertit joc.

Tots els resultats d'aquest joc són emmagatzemats, i el professor pot consultar-los en

qualsevol moment.

Aquest manual li permetrà aprendre a utilitzar l'aplicatiu d'administració de LectoRA,

necessari per a la configuració i preparació per a l'ús dels seus alumnes.

47


10.1.2. Esquema del funcionament bàsic

L'aplicatiu d'administració de LectoRA (anomenat Configurador LectoRA) té una interfície

gràfica molt simple i intuïtiva, però ofereix moltes possibilitats a l'hora de preparar el joc

pels alumnes. A continuació veurem una línia temporal del procés a seguir per a l'ús de

LectoRA:

• Instal·lació de LectoRA als ordinadors

• Professor

• Obre base de dades

• Registra tots els seus alumnes

• Es registra com a usuari

• Crea jocs

• Escull la dificultat dels jocs

• Escull la categoria del joc

• Alumne

• Juga als jocs creats pel professor

• Els seus resultats són emmagatzemats

• Professor

• Consulta els resultats de l'alumne

• Crea nous jocs adequats a l'alumne segons els resultats

• Tanca base de dades

Aquest manual l'ajudarà a seguir aquest procés fàcilment alhora que aprèn a utilitzar totes

les funcions LectoRA.

48


10.2. Instal·lació

10.2.1. Preparació

El procés d'instal·lació de LectoRA és senzill, però abans de continuar s'hauran de tenir en

compte diferents requeriments:

• PC amb sistema operatiu Windows XP o superior

LectoRA pot funcionar només amb un ordinador, però si l'escola disposa d'una aula

informàtica amb més màquines, es recomana instal·lar-lo en totes.

• Webcam USB amb resolució mínima de 352x288

Una webcam amb resolució de 640x480 ajudarà a obtenir uns resultats millors.

49


10.2.2. Instal·lació

Per a començar la instal·lació, farem doble clic a la icona de l'auxiliar d'instal·lació.

El procés d'instal·lació és auto-explicatiu i, seguint les instruccions en pantalla, no hi haurà

cap complicació. Tot i així, s'ha de tenir en compte que LectoRA es divideix en dues parts

importants:

• Configurador LectoRA

És l'aplicatiu que els professors utilitzaran per a preparar els jocs que els alumnes

jugaran, així com per a consultar els resultats de les partides dels alumnes.

Només s'ha d'instal·lar un cop, a la màquina que els professors utilitzaran.

• Joc LectoRA

És el joc que jugaran els alumnes.

Totes les màquines disponibles pels alumnes necessitaran tenir instal·lada aquesta

part.

LectoRA necessita, també, les llibreries Java 1.6. Si l'ordinador no disposa encara

d'aquestes llibreries, el propi instal·lador de LectoRA ens dóna l'opció de poder-les

instal·lar. Això és obligatori en qualsevol cas.

Per a seleccionar quins components volem instal·lar, farem clic a les caselles de la llista,

com es mostra a la següent imatge.

50


10.3. Administració

10.3.1. Execució

Un cop instal·lat el paquet de LectoRA (l'aplicatiu d'administració i el joc), el que haurem

de fer és obrir la base de dades.

La base de dades de LectoRA és imprescindible per al funcionament de les dues

aplicacions inicials: Configurador i joc.

Quan s'executa la base de dades, es queda en memòria i no s'ha de tancar (s'ha de mantenir

la finestra oberta), ja que els ordinadors dels alumnes accediran a aquesta per a llegir

informació del jocs, així com emmagatzemar els resultats de les partides.

Més endavant, quan els alumnes hagin acabat de jugar, i els professors hagin consultat els

resultats, la base de dades podrà ser finalitzada sense problema. Per a finalitzar la base de

dades és tan simple com tancar la finestra d'aquesta.

Ara que ja tenim la base de dades oberta, ja podem començar a configurar LectoRA. Per a

això, executarem el Configurador LectoRA.

51


10.3.2. L'entorn gràfic

Un cop executat el Configurador LectoRA (amb la base de dades oberta), obtindrem una

finestra com la següent:

Configurador LectoRA té quatre diferents seccions amb les quals podrem configurar tots

els aspectes importants del joc.

Aquest manual ajudarà a seguir les pautes proposades al punt 1.2 amb l'entorn gràfic de

Configurador LectoRA.

52


10.3.3. Manegament d'usuaris

El primer pas per a fer funcionar el joc LectoRA correctament és crear i registrar nous

usuaris i grups d'usuaris. Farem clic al botó de la dreta: Registre usuaris.

Aquesta és la pantalla que veurem al clicar el botó:

Des d'aquí podrem registrar-nos com a professors i crear grups d'alumnes.

53


Un professor té varis grups d'alumnes i un alumne pertany a un sol grup, com podem veure

a la següent figura.

Començarem creant els grups, després afegirem els alumnes a aquests. Cliquem a Crear

nou grup d'alumnes.

54


A continuació introduïm el nom del grup (exemple: 1r A) i acceptem.

Ara ja tenim el grup 1r A creat. A l'esquerra de la pantalla Registre usuaris tenim un menú

desplegable on s'aniran acumulant tots els grups creats.

Els grups no tenen perquè incloure la classe sencera. El professor pot dividir una classe en

diferents grups, segons el nivell de cadascun dels alumnes. Més endavant podrà passar

alumnes d'un grup a un altre.

Un cop creat el grup, el seleccionem al desplegable esmentat i ja podrem afegir nous

alumnes al grup. Cliquem a Afegir alumne.

55


Introduïm el nom de l'alumne (exemple: Daniel) i acceptem. Ara ja tenim el nostre primer

alumne registrat al grup 1r A! Podem repetir aquest procés tantes vegades com sigui

necessari per a registrar cadascun dels alumnes del grup 1r A. Al nostre exemple hem

afegit varis alumnes més, i així és com queda la llista d'alumnes a l'esquerra.

També hem creat altres grups amb altres alumnes, però al manual sempre farem servir el

grup 1r A com a exemple.

56


Per acabar, ja podem crear un professor com a usuari. És, bàsicament, el mateix procés que

per a afegir un nou grup o alumne: cliquem a Afegir professor.

L'única diferència és que, a més d'introduir el nom del professor, ara també haurem de

marcar quins seran els grups d'aquest professor. D'aquesta manera el professor podrà tenir

un seguiment dels resultats dels jocs dels seus alumnes. En el nostre exemple, Marc serà el

professor del grup 1r A, per tant, serà professor de tots els alumnes que pertanyen a aquest

grup.

Si en algun moment volem modificar la informació d'un usuari (canviar el nom i/o el grup

al qual pertany), podem fer servir els botons d'Eliminar o Editar. El seu funcionament és

auto-explicatiu.

Ja podem sortir de la pantalla Registre usuaris. Fem clic a Tornar.

57


10.3.4. Representacions virtuals

El següent pas és administrar les representacions virtuals.

Cliquem al botó Representacions. I així veurem la pantalla Configuració representacions.

58


10.3.4.1. Què és una representació virtual?

Una representació virtual és, com el seu nom indica, qualsevol cosa (persona, animal,

objecte, etc) que pertany al nostre món real representada al món virtual de l'ordinador.

Aquesta representació pot ser donada mitjançant imatges i/o sons. Una representació

virtual pot tenir una o vàries imatges o sons que l' identifiquen al nostre món real.

El nostre objectiu és omplir la base de dades amb infinitat de representacions virtuals, com

més varietat millor.

Tot i que LectoRA inclou algunes representacions virtuals d'exemple, aquí seguirem unes

pautes per tal d'aprendre com afegir-ne de noves.

59


10.3.4.2. Categories

El primer que haurem de fer és crear categories on afegir les representacions virtuals.

Això s'haurà de fer tenint en compte que cada joc està relacionat amb una sola categoria.

Per tant podrem crear diferents tipus de jocs, al nostre exemple crearem la categoria de

Fruites, i tot seguit afegirem representacions virtuals en aquesta.

Al desplegable Categories cliquem al botó de la creu verda (Afegir categoria).

I introduïm el nom de la nova categoria. Al acceptar, ja sortirà la nova categoria afegida al

llistat desplegable de categories. A l'exemple, nosaltres hem creat més categories.

60


Un cop creada la categoria, haurem de crear les representacions virtuals. Seleccionem la

categoria on volem afegir la representació, en el nostre cas Fruites. I cliquem al botó de la

creu verda a sota de la finestra (Afegir representació).

Un cop més, introduïm el nom de la representació i acceptem.

Podem repetir aquest pas tants cops com sigui necessari.

61


10.3.4.3. Imatges i sons

Quan tinguem creades les representacions virtuals, és hora d'afegir una imatge o un so que

les identifiqui al món real. Aquest pas no és difícil, però és costós en temps.

Tenim diferents possibilitats per a afegir imatges relacionades amb una representació:

• Buscar la imatge per internet

• Fer una fotografia nosaltres mateixos al món real

Per a la majoria de casos serà més viable buscar la imatge desitjada per internet i desar-la

al disc dur.

Però en altres haurem de fer nosaltres les fotografies. Per exemple, si afegim una categoria

amb els noms dels nens dels alumnes, haurem de fer una fotografia a cadascun dels nens.

I per als sons, també tenim diferents possibilitats:

• Enregistrar la nostra veu dient el nom de la representació

• Utilitzar un altre tipus de so relacionat amb la representació

Normalment, durant el joc de LectoRA, el que voldrem es que s'escolti pels altaveus la

pronunciació de la paraula.

Però també es podria variar lleugerament el joc fent servir altres tipus de sons. Per

exemple, a la categoria Animals podríem buscar i afegir els sons que emeten els diferents

animals.

En qualsevol cas acabarem amb una imatge o un so emmagatzemat al nostre disc dur, que

podrem fer servir al joc de LectoRA.

Els tipus d'imatges suportats són JPG (recomanat), PNG i BMP.

Les imatges són redimensionades automàticament al joc LectoRA. Però es recomana, si és

possible, tractar la imatge (retallar, canviar de tamany, etc) abans de ser afegida.

Pels sons només podem fer servir el format WAV.

62


Ara ja podem afegir una imatge o un so relacionat amb la nostra representació virtual

creada a l'exemple: Taronja.

Aquí s'explica com afegir una imatge. Però afegir un so segueix exactament el mateix

mètode.

Cliquem al botó Afegir nova imatge.

Apareixerà una finestra on podrem navegar pel nostre disc dur i seleccionar la imatge

desitjada. Així tindrem la nostre imatge afegida a la base de dades.

Un cop afegida la imatge, es fa una còpia al directori d'instal·lació de LectoRA. Així, la

imatge original es pot esborrar del disc dur sense cap inconvenient.

63


Haurem de repetir aquest procés per a cadascuna de les representacions virtuals creades, i

ja podrem tornar al menú principal.

Addicionalment, una representació virtual només necessita una imatge i/o un so. Però

podem continuar afegint imatges/sons a la mateixa representació virtual (diferents fotos

d'una taronja). Això no té cap finalitat important, però donarà més varietat al joc, que

mostrarà una de les imatges o reproduirà un dels sons a l'atzar.

I per acabar, en alguns casos es pot reutilitzar una imatge o un so que ja hagi sigut afegit a

la base de dades. Això es pot fer clicant als botons 'Reutilitzar imatge' o 'Reutilitzar so' i

seleccionant la imatge o el so.

Exemples:

• Si hem enregistrat la nostra veu dient la paraula 'Taronja' ens pot servir tant per a la

fruita com per al color.

• Una imatge còmica que inclou un ratolí tocant un piano ens pot servir per a l'animal

(ratolí) com per a l'instrument (piano).

64


10.3.4.4. Còpia d'imatges i sons

Abans de continuar, s'ha de tenir en compte que les imatges que hem afegit a la base de

dades només es troben a la màquina on estem actualitzant la base de dades.

Normalment, aquesta màquina serà única i no serà la mateixa que els alumnes utilitzaran.

Si aquest és el nostre cas, el que haurem de fer és copiar tots aquests arxius a totes les

màquines que els alumnes utilitzaran.

El subdirectori o carpeta on es guarda tot aquest material es troba dintre del directori on es

va instal·lar LectoRA.

El subdirectori en qüestió és 'data' i simplement l'haurem de copiar al mateix directori on es

va instal·lar el joc LectoRA als altres ordinadors, sobreescrivint els arxius que ja existeixin.

Tenim dos maneres de fer-ho:

• Mitjançant la xarxa: si tenim coneixements de manegament de xarxes ho podem

copiar directament des de la màquina servidor.

• Amb un dispositiu d'emmagatzemament extern (pendrive): primer copiarem el

nostre subdirectori al pendrive, i després el copiarem de nou a totes les màquines.

Es recomana, primer, crear una gran base de dades amb moltes categories, imatges i sons

per a no haver d'actualitzar aquest subdirectori sovint.

65


10.3.5. Configuració joc

Un cop tinguem creades les categories i afegides les representacions virtuals, és hora de

crear els jocs per als alumnes. Cliquem al botó Preparar jocs del dia.

A continuació, veurem la finestra de configuració dels jocs.

El primer que haurem de fer és crear una llista de jocs. Després podrem seleccionar d'entre

tots els jocs creats, els que es jugaran a la sessió del dia.

66


10.3.5.1. Els diferents nivells

Cliquem al botó Crear nou joc.

Ens apareixerà una finestra que haurem d'omplir per tal crear el nostre primer joc.

• Títol de joc: és el títol que li posarem a aquest joc. No afecta a l'experiència dels

alumnes, només ens servirà per a identificar ràpidament el joc que busquem per a un

alumne específic.

• Categoria: de totes les categories creades al punt 2.4.2 hem de seleccionar una. Un

joc només pot tractar una sola categoria.

67


• Nivell: cada joc pot ser configurat per a tenir diferents nivells de dificultat que es

tradueixen diferents tipus de jocs per a l'alumne.

• Nivell 0: pot ser útil per a iniciar-se als jocs de LectoRA. Aquest nivell no té cap

objectiu, l'alumne pot col·locar lliurement qualsevol patró i el joc mostrarà una

representació relacionada. Fins i tot, pot provar de construir paraules.

• Nivell 1: el nivell més fàcil. Es pot configurar de forma que aparegui una imatge, es

reprodueixi un so o es vegi la paraula sencera en pantalla. Llavors l'alumne ha de

buscar el patró amb la primera lletra de la representació.

68


• Nivell 2: en aquest nivell els alumnes sempre veuran una imatge i/o escoltaran un

so d'una representació virtual. A la pantalla també veuran la paraula que identifica

aquesta representació, però li faltarà una lletra que és la que els alumnes hauran de

col·locar sota la webcam.

• Nivell 3: aquest nivell és més complicat ja que no demana un sol patró, sinó quatre.

L'alumne veurà en pantalla quatre representacions, i haurà de buscar entre els

patrons les quatre lletres per les quals comencen cadascuna de les representacions.

69


• Nivell 4: el més difícil de tots. Aquí l'alumne haurà de col·locar sota la webcam tots

els patrons de les lletres que formen la paraula.

• Tipus de patrons que s'utilitzaran: aquesta opció no s'ha de canviar normalment.

LectoRA té informació sobre els patrons que els autors van predefinir durant el

desenvolupament de l'aplicatiu.

• Reptes nivell 1: si el joc creat és del nivell 1, és obligatori especificar quin tipus

d'ajuda s'oferirà a l'alumne. Podem seleccionar entre: mostrar una imatge, reproduir un so o

mostrar la paraula sencera. Com a mínim hem de seleccionar una. Com més opcions

seleccionem, més fàcil serà el joc. D'aquesta forma podem crear nous jocs de nivell 1

incrementant la dificultat poc a poc i habituant als alumnes al joc de LectoRA.

• Mode de joc: l'últim paràmetre a modificar es el mode. El joc podrà ser limitat per

temps o per torns.

• Si es vol limitar per temps, podem seleccionar quant de temps (en minuts)

podrà jugar un alumne. Els resultats s'emmagatzemaran com el nombre màxim

d'encerts que ha fet l'alumne en aquest temps.

• Si es limita per torns, l'alumne només haurà de respondre tants cops com

s'especifiqui. En aquest cas, s'emmagatzemarà, com a resultat, el temps emprat per

resoldre totes les preguntes.

70


Així, al nostre exemple crearem un joc fàcil de nivell 1 (on mostrarem la imatge i

reproduirem el so de cada representació virtual), amb la categoria fruites i que duri 10

minuts, com veiem al següent exemple:

10.3.5.3. Personalitzant un joc

Ara que ja tenim un joc creat, podem personalitzar-lo encara més.

LectoRA ofereix la possibilitat de fer jocs especialitzats, excloent algunes representacions

de la categoria.

Per exemple, volem fer un joc basat només amb animals aquàtics però la categoria Animals

inclou tots els animals possibles. Això ho podem solucionar personalitzant el joc:

seleccionem el joc a personalitzar i cliquem a Editar joc.

71


Ens apareixerà una finestra on podrem seleccionar o de-seleccionar les representacions

virtuals de la categoria.

El que haurem de fer es deixar seleccionades només les que vulguem que surtin en aquest

joc. En el nostre cas, seleccionarem només els animals aquàtics de tots els animals que

tenim.

Un altre exemple vàlid és el fer un joc més fàcil, excloent algunes representacions que

comencin amb una lletra poc usada. Per exemple, per als nivells més fàcils podem treure la

representació Kiwi d'un joc de fruites.

72


10.3.5.4. Creant una sessió del dia (opcional)

Un cop afegits tots els jocs necessaris, podem crear (opcionalment) una sessió del dia.

Amb aquesta característica podem preparar un conjunt de jocs que els alumnes podran

jugar seguits.

A la pantalla de Preparar jocs del dia seleccionem el nom del professor a l'esquerra. Sota

apareixerà una llista de tots els grups d'aquest professor.

L'únic que hem de fer ara és marcar, a la dreta, tots els jocs que volem que aquest grup

jugui avui.

Per exemple, si és el primer dia que els nostres alumnes juguen a LectoRA, és recomanable

marcar els jocs de nivell 1.

D'aquesta manera, avui els nostres alumnes jugarien aquests dos jocs: 'Colors fàcils!' i

'Fruites nivell fàcil'. Els jugaran seguits, amb una petita pausa entre joc i joc. A més, l'ordre

dels jocs a jugar és aleatori; això significa que potser un alumne jugarà primer el joc dels

colors i un altre jugarà el de les fruites.

73


10.4. El joc pels alumnes

10.4.1. El joc LectoRA

Després d'acabar tota la part de configuració (creació de categories i representacions

virtuals, creació de jocs...), els alumnes ja poden començar a jugar, per fi, al joc LectoRA.

El joc LectoRA serà una eina per a reforçar l'aprenentatge de la lectura i l'escriptura dels

alumnes.

LectoRA els demanarà una o vàries lletres d'una representació virtual

Els nens no tindran accés al ratolí o al teclat. En comptes d'això, hauran de fer servir unes

cartolines (cadascuna amb una lletra de l'abecedari) i col·locar-les sota una webcam que

s'encarregarà de comprovar si la lletra escollida és la correcta.

Els resultats s'emmagatzemen a la base de dades, per a que els professors puguin consultar-

los en qualsevol moment.

74


10.4.2. Primera execució

Executarem el joc LectoRA per primera vegada.

La següent finestra només apareixerà aquest cop:

En aquesta casella haurem d'introduir la direcció IP local de la màquina on s'està executant

la base de dades.

Podem esbrinar-ho fàcilment si mirem a la finestra del Configurador LectoRA, a sota de tot

(si hem sortit del Configurador s'haurà de tornar a executar).

Les xifres marcades a la figura són les que ens interessen (aquestes xifres seran diferents

segons l'ordinador on estigui oberta la base de dades). Les haurem de copiar al requadre de

text:

Podem fer clic a Acceptar.

Com que la màquina on estarà oberta la base de dades sempre serà la mateixa, aquestes

xifres no variaran i a les properes execucions el joc, aquesta finestra no tornarà a sortir i

LectoRA es connectarà automàticament a la base de dades.

75


10.4.3. Pantalla de configuració

Un cop s'hagi configurat la direcció IP ens apareixerà una finestra com aquesta:

L'explicació de cada casella és auto-explicativa.

Haurem de seleccionar, primer, el nostre nom a la llista de professors.

Així, ens sortirà a sota una llista de tots els nostres alumnes. Seleccionarem l'alumne que

jugarà el proper joc.

I finalment podem seleccionar el joc a jugar o bé la Sessió del dia. Si seleccionem Sessió

del dia l'alumne jugarà tots els jocs que prèviament hem seleccionat al Configurador

LectoRA com a jocs del dia.

Si fem clic a Acceptar el joc LectoRA començarà per a l'alumne seleccionat!

76


10.4.4. Com jugar

El joc LectoRA ha començat.

Tot i que el seu funcionament és molt simple, és convenient que els professors expliquin

prèviament com funciona i ajudin als alumnes a col·locar els patrons correctament.

Els tipus de jocs s'han explicat al punt 2.5.1. Però també és important que els alumnes

sàpiguen com col·locar els patrons.

Els alumnes jugaran amb unes cartolines que inclouen una lletra i un patró.

El patró és com un codi de barres i ha d'estar sempre visible. Per tant, els alumnes hauran

de tenir en compte que no poden tapar aquest codi de barres amb la mà.

El patró ha d'estar sempre a sota i, si pot ser, la cartolina el més recte possible. Tot i que el

joc LectoRA pot detectar els patrons inclús si estan inclinats, es recomana que els patrons

es col·loquin rectes per a uns millors resultats.

L'alumne seleccionat jugarà els jocs del dia (o un sol joc si es va especificar) seguits. Entre

joc i joc veurà una pantalla de pausa, en la qual el professor haurà de facilitar-li informació

sobre el proper joc que jugarà i donar (treure) els patrons nous (antics) si cal.

77


10.5. Estadístiques

10.5.1. Explicació puntuació

Un cop s'acabi la partida, els seus resultats s'emmagatzemaran a la base de dades

automàticament.

• Si el joc era per torns: es guardarà el temps que ha trigat en respondre totes les

preguntes (torns)

• Si el joc era per temps: es guardarà el nombre màxim de preguntes encertades

Si el joc és parat abans de que s'acabi (tancant la finestra del joc LectoRA), els resultats no

s'emmagatzemaran.

78


5.2. Consultar estadístiques

Per a consultar les estadístiques dels nostres alumnes haurem de tornar a obrir el

Configurador LectoRA a la màquina servidor.

Clicarem al botó estadístiques:

I veurem la següent pantalla:

A l'esquerra haurem de seleccionar el nostre nom com a professor, i a sota ens apareixerà

una llista dels nostres alumnes.

79


Si cliquem a un alumne podrem veure els seus resultats:

A la taula de la dreta s'aniran acumulant tots els seus resultats. Podrem veure el temps que

han emprat per a contestar les preguntes.

• Si el joc era per torns: ens marcarà quant de temps han emprat per a respondre les

preguntes

• Si el joc era per temps: ens marcarà quantes preguntes han contestat correctament

80

LectoRA – Realitat augmentada aplicada a la...

Documents

Transcript of LectoRA – Realitat augmentada aplicada a la...