en corto circuito(15)febrero2008

Febrero 2008

EDITORIAL

DEL EDITOR AL LECTOR

2

PROYECTOS Computación Distribuida

3

Diseño de Modulador OFDM en Banda Base Utilizando System Generator de XILINX

6

Diseño de Modulador Implementación del Modelo Hidrológico Swat Sobre una Plataforma Distribuida

10

Pierna Robótica

13

Reconocimiento de Caracteres Gráficos (OCR) Usando Matlab

15

Transmisión de Audio y Video Portátil

20

EXTRAS Informe IEEE

Nuestra Escuela

28 30

Telemetría de Signos Vitales para Control de la Salud

25

CONTENIDO

U

TPL

Elec

trónica

y

Tele

comunicacio

nes

Escuela de Electrónica y Telecomunicaciones

2

“Quedan abiertas las puertas de este modesto medio de comunicación para que todos quienes deseen desarrollar, investigar e innovar dentro del maravilloso campo de la Electrónica y las Telecomu- nicaciones, lo hagan.” R a f a e l - S á n c h e z Puertas

Página 2 EDITORIAL

DEL EDITOR AL LECTOR

En esta nueva entrega de nuestra revista “En Corto Circuito” tenemos el agrado de poner a su consideración un nuevo formato, que esperamos sea de su agrado. Dentro de este marco de cambio, en cada una de nuestras ediciones esperamos que ustedes, nuestros lectores, nos ayuden con sus debidas correcciones y actualizaciones, pasando a ser parte de nuestro gran círculo.

No. 15

Febrero 2008

Director Ing. Jorge Luis Jaramillo

[email protected]

Editor Juan Carlos Veintimilla L.

[email protected]

Revisión Técnica Ing. Rafael Sánchez Puertas

[email protected]

“EN CORTO CIRCUITO” es una

publicación de la Escuela de Electrónica y Telecomunicaciones de la

Universidad Técnica Particular de Loja

ED

ITO

RIA

L

El por qué de esta revista La Escuela de Electrónica y Telecomunicaciones de la UTPL, creó la revista con la intención de gestionar un espacio para la difusión del trabajo de investigación y desarrollo de profesionales en formación y docentes investigadores.

LICENCIA CREATIVE COMMONS <a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/3.0/"> <img alt="Creative Commons License" style="border-width:0" src="http://creativecommons.org/images/public/somerights20.png" /> </a> <br />Esta obra está bajo una <a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/3.0/">licencia de Creative Com-mons</a>.

3

Página 3

RESUMEN: El presente artículo tiene como objetivo dar a conocer la definición y características de la Computación Distribuida, así como también el proyecto que se está desarrollando en el Área de Arquitectura de Computadores del Grupo de Electricidad y Sistemas Electrónicos (GESE) de la Universidad Técnica Particular de Loja. INTRODUCCIÓN Actualmente la ciencia ha avanzado notablemente, y para su buen desarrollo se requiere que la tecnología complemente estos avances de manera que los procesos sean más ágiles, es así que se necesita una tecnología que brinde más rapidez en la obtención de resultados. En los últimos años han surgido nuevos sistemas de alto rendimiento, perfeccionándose de tal manera que permiten cubrir las necesidades de diversos usuarios; dichos sistemas varían en la manera que utilizan tanto procesadores como memoria y en la forma de interconectarlos. Una solución a esta gran demanda es la implementación de sistemas distribuidos.

COMPUTACIÓN DISTRIBUIDA La computación distribuida o informática en rejilla es un nuevo modelo para resolver problemas de computación masiva utilizando un gran número de computadoras organizadas en racimos incrustados en una infraestructura de telecomunicaciones distribuida. La informática en rejilla consiste en compartir recursos heterogéneos (basadas en distintas plataformas, arquitecturas de equipos y programas, lenguajes de programación), situados en distintos lugares y pertenecientes a diferentes dominios de administración sobre una red que utiliza estándares abiertos. En otras palabras, consiste en virtualizar los recursos informáticos.

CLUSTERING Un cluster es un conjunto de computadoras construidas mediante la utilización de componentes de hardware comunes y que se comportan como si fuesen una única computadora.

La tecnología de clusters ha evolucionado en apoyo de actividades que van desde aplicaciones de supercómputo y software de misiones críticas, servidores Web y comercio electrónico, bases de datos de alto rendimiento, soluciones de problemas de las ciencias, las ingenierías, entre otros. GRID COMPUTING Grid Computing es una tecnología que permite utilizar de forma coordinada todo tipo de recursos (entre ellos cómputo, almacenamiento y aplicaciones específicas) que no están sujetos a un control centralizado. Es una nueva forma de computación distribuida, en la cual los recursos pueden ser heterogéneos (diferentes arquitecturas, supercomputadores, clusters...) y se encuentran conectados mediante redes de área extensa (por ejemplo Internet). El propósito del grid es facilitar la integración de recursos computacionales de Universidades, laboratorios de investigación, empresas, etc. GLOBUS El Globus Toolkit es una colección de componentes software que ofrecen la infraestructura básica necesaria para la creación y ejecución de aplicaciones distribuidas, así como para la construcción de Grids. El proyecto Globus provee un software toolkit open source que puede ser utilizado para la construcción de grids computacionales y aplicaciones basadas en grid. El toolkit de Globus se basa en tecnologías estándar como XML, SOAP, WSDL, Servicios Web y está implementado íntegramente en Java. - Servicios Globus - Servidor: - prerequisitos - construcción toolkit - seguridad: se utiliza CA (certificados de autorización) - gridFTP - webservices container - configuración RFT

COMPUTACIÓN DISTRIBUIDA Marielisa Peralta Valarezo

Universidad Técnica Particular de Loja Grupo de Electricidad y Sistemas Electrónicos

[email protected]

PROYECTOS

AR

QU

ITE

CT

UR

A D

E C

OM

PU

TAD

OR

ES

4

Página 4

Tabla 5. Pre-requisitos de software

Tabla 6 - Paquetes del Globus Toolkit utilizados

- Nodos - construcción toolkit - seguridad - gridFTP - webservices CONCLUSIONES • Se ha seleccionado la herramienta Globus para

plataforma Linux, ya que es una herramienta ampliamente utilizada en la construcción de servicios grid, a más de ser open source, tiene un enfoque toolkit, un conjunto de herramientas y bibliotecas de funciones que se pueden acoplar fácilmente a sistemas y programas ya existentes sin necesidad de grandes cambios

• Es de gran importancia, realizar un estudio

previo de la disponibilidad de hardware, software y red, para conocer bajo qué entorno se implementará las herramientas Grid, además de las características y capacidad total que se obtendrá al final de la implementación.

• Considerando las características presentadas se

puede considerar que la implementación de una tecnología es la solución más acertada para la resolución de problemas complejos,

incrementando la potencia de cálculo y optimizando gran capacidad de recursos.

RECOMENDACIONES • Al momento de realizar la implementación

de un Grid, se requiere que el personal que lo haga tenga conocimientos básicos de las herramientas a utilizar y de la plataforma donde será implementado, para identificar y resolver de la mejor manera posible cualquier problema que se presente.

• Un aspecto muy importante que debe ser

considerado también es la reutilización de equipos, es decir que se puede implementar un Grid con equipos donde su capacidad de computo no es aprovechada al máximo, sin tener la necesidad de adquirir nuevo hardware, obteniendo una solución de menor costo. Pero de igual manera es aconsejable que lo equipos sean de similar arquitectura para no tener problemas en el acceso a recursos y en rendimiento.

REFERENCIAS 1. A Globus Primer. Describing Globus

Toolkit Version 4. Disponible en: http://www.globus.orgtoolkit/docs/4.0/key/index.html

2. MONROY, José. Globus Toolkit. Departamento Ingeniería Sistemas Telemáticos. Madrid. Disponible en: in-ternetng.dit.upm.es/joe/Art/Globus.pdf

3. MANUALI, Carlo. Implementazione di un ambiente Grid per il calcolo ad alte prestazioni. Università degli Studi di Pe-rugia. Facoltà di Scienze Matematiche Fisiche e Naturali. 2001 - 2002-Disponible en: http://www.unipg.it/carlo/Tesi.pdf

4. DIAZ, Gilberto. Herramientas GRID para la integración y administración de servicios de redes en Latino América. Universidad de los Andes. Mérida. Disponible en: www.programafrida.net/docs/informes/herramientas_grid.pdf

5. The Globus Alliance. Sitio Oficial de Globus: www.globus.org

PROYECTOS

Requerimientos GNU tar,sed,Make,gcc

Ant 1.5.1+

J2SE 1.4.2+

zlib 1.1.4+

Sudo

JDBC compliant Database

IODBC

Tomcat Junit

Plataforma Package

RedHat AS gt4.0.4-x86_rhas_4-installer.tar.gz

Fedora Core gt4.0.4-x86_fc_4-installer.tar.gz

AR

QU

ITE

CT

UR

A D

E C

OM

PU

TAD

OR

ES

5

Página 5

DESARROLLO DEL PROYECTO El proyecto que se está desarrollando en el Área de Arquitectura de Computadores, está orientado a la construcción de sistemas distribuidos los que servirán, en futuro, para la obtención de resultados de aplicaciones en áreas como Sistemas de Información Geográfica, Laboratorio de Física, entre otros. Se decidió utilizar herramientas Open Source tanto para el sistema operativo (Linux) como para el middleware de la infraestructura grid (globus). Dentro de los requerimientos básicos para la implementación se consideran los siguientes:

Tabla 1. Descripción de Hardware Descripción del Hardware:

Tabla 2. Descripción de Software

Descripción del Software: Descripción de Red Con una topología de red tipo estrella, se configuró una intranet con: 1 máquina como servidor 4 máquinas como nodos

Tabla 3. Descripción de Red

Dominio: gese.com

Fig. 1 Diseño Físico

Tabla 4 – Descripción Servicios Básicos Preparación del Ambiente Distribuido Para la implementación de la infraestructura distribuida, se está trabajando con una infraestructura grid, con la instalación y configuración de la herramienta globus toolkit version 4.0.4 que actuará de middleware para la utilización del grid con aplicaciones prototipo.

AR

QU

ITE

CT

UR

A D

E C

OM

PU

TAD

OR

ES

PROYECTOS

Hardware Software (Sistema

Operativo Red

Memoria 512 Mb

Red Hat Enter-prise AS 3 Red Hat Enter-

prise AS 4 Fedora Core 5

CentOS 4

Tarjeta: FastEthernet 10/100

Mbs

Disco Duro

80 Gb

Procesador

3000 MGhz

Sistema Operativo

Red Hat Enterprise AS 3

Red Hat Enterprise AS 4

Fedora Core 5

CentOS 4

Hostname Dirección IP

sergese.gese.com 172.16.3.209

nodo1.gese.com 172.16.3.169




Nombre

Sistemas Operativo Servicios

servgese CentOS 4

Servidor DNS

Servidor NTP

Servidor Mail

ssh

nodo1

nodo2

nodo3

nodo4

Red Hat Enterprise 3.0

Fedora Core 5



Cliente DNS

Cliente NTP

Cliente Mail

ssh activado

6

Página 6

RESUMEN: El presente trabajo, tiene por finalidad utilizar las herramientas de modelado en hardware como es: System Generator de Xilinx para la formación del símbolo OFDM, subsistema que forma parte de un Modulador OFDM

INTRODUCCIÓN En los últimos años, el diseño de sistemas de comunicación digital ha reducido su complejidad y extendido el manejo de herramientas de síntesis de hardware a través de lenguajes de descripción de hardware como VHDL o con software especializado como el de Xilinx System Generator (XSG). XSG es una herramienta muy poderosa para realizar el modelamiento en hardware de prototipos de sistemas de comunicación digital. La combinación con MATLAB-Simulink, le brindan al diseñador la posibilidad de sintetizar un diseño a partir de una descripción funcional con alto grado de abstracción en un dispositivo lógico programable, donde los FPGAs son una gran opción debido a sus características de reconfigurabilidad, costo y desempeño. Dentro de las comunicaciones digitales la técnica de modulación OFDM, viene siendo adoptada como componente base de sistemas digitales de última generación (DVB-T, DAB, WiMax, 802.11a/g, HIPERLAN2, PLC, etc.) [1][2]. Por tanto, el diseño de un modulador OFDM en una FPGA, es un a gran reto a cumplir, cuyo logro estimula el aprendizaje de sistemas de comunicación inalámbrica. MODELO PROPUESTO El símbolo OFDM estará formado por 64 subportadoras, de las cuales 48 transportan información y 4 son los símbolos piloto [4]. Si l es el número de subportadora, los índices de las subportadoras que transportan información son: -26 ≤ l ≤ -22, -20 ≤ l ≤ -8, -6 ≤ l ≤ -1, 1 ≤ l ≤ 6, 8 ≤ l ≤ 20, 22 ≤ l ≤ 26

Y los índices de las subportadoras piloto son: l =-21,-7, 7,21 La subportadora del equivalente pasa bajas (posición cero), contiene la componente continua, y tiene el valor cero. Si n es el índice de cada símbolo OFDM, Cl, n es el símbolo complejo (datos o pilotos) por subportadora l por n símbolo OFDM [4], la distribución del grupo de datos Dm, n dentro de los símbolos Cl, n se muestra en la Fig 1.

Fig. 1. Distribución de datos y portadoras piloto en símbolo OFDM

Para conseguir esta distribución, hay que ordenar los datos tal como se muestra en la figura 2.

Fig. 2: Distribución de símbolo OFDM a la entrada del bloque IFFT

PR

OY

EC

TO

DE

FIN

DE

CA

RR

ER

A PROYECTOS

DISEÑO DE MODULADOR OFDM EN BANDA BASE UTILIZANDO SYSTEM GENERATOR DE XILINX

Luis M. Moreno Yaguana Universidad Técnica Particular De Loja

Escuela De Electrónica y Telecomunicaciones [email protected]

Loja-Ecuador

7

Página 7

Se puede ver que el primer dato es el cero, que corresponde a la componente continua del espectro del equivalente pasa bajas. Cabe comentar que los 48 datos (D0, n…D47, n), que arriban por símbolo OFDM tienen que ser reordenados. El reordenamiento consiste en coger los últimos 24 datos y colocarlos al principio. También se puede ver la inserción de ceros entre las posiciones 26 a 38 que corresponden a las bandas laterales del espectro [4]. La Fig. 1 muestra la ubicación de los cuatro símbolos píloto (Pl, n), que se insertan en las subportadoras correspondientes. Donde Pn es una secuencia pseudo aleatoria con una extensión de 127 elementos, generada por el polinomio X7 + X4 +1.[5] La ubicación y la cantidad de portadoras piloto, necesarias para la sincronización se detallan en [3]. DISEÑO EN XSG DE BLOQUE FORMADOR

DE SIMBOLO OFDM

La entrada a este bloque corresponde la parte real e imaginaria del símbolo complejo obtenido mediante el mapeo de datos según el tipo de modulación empleado En la formación del símbolo OFDM, los elementos principales constituyen las Memorias RAM doble puerto, donde se aplica paginado doble para el procesamiento de datos continuo y los bloques de control de escritura y lectura de los datos que ingresan a la memoria. Proceso de escritura: La escritura en la memoria RAM doble puerto, se realiza por el puerto A que se establece de forma fija en modo escritura, el bloque que genera los valores del puntero de escritura se muestra a continuación en la Fig. 3. Los valores del puntero de escritura en la figura 3 corresponden a los presentes en la salida del multiplexor, el selector del multiplexor es controlado por una señal que indica el cambio de página cuando una vez escritos los 48 datos en una página, se empiece a escribir desde la primera posición de la otra página. Los bloque de la parte inferior en la figura 3, sirven para especificar el instante en que se empiece el proceso de lectura de los datos almacenados en las memorias.

Fig. 3. Control de escritura para formación de símbolo OFDM

La memoria RAM de doble puerto permite que la velocidad de escritura de datos pueda ser diferente a la de lectura, para el propósito de formar el símbolo OFDM, se utiliza una relación de escritura lectura de ¾ ya que se escriben 48 datos por página y se leen 64 datos por página. El bloque de control del puntero de lectura se muestra en la Fig. 4.

Fig. 4. Control de lectura para formación de símbolo OFDM

Se observa también que en el diseño propuesto no existe solapamiento de los punteros de lectura y escritura.

PROYECTOS

2rst

1ControlWrit

sysgenen out

WritePagB

sysgenen out

WritePagA

sysgen↑4

Up Sample

sysgenaben

a=bz-1

Relational1

sysgen

a

b

a=bz-0

Relational

sysgend

enqz-1

Register1

sysgend

rstqz-1

Registersysgen

sel

d0

d1

Muxsysgenxnorz-0

Logical

sysgennot

Inverter1

sysgennot

Inverter

sysgen↓3z-1

Down Sample

sysgenz-29

Delay

sysgenout

Counter1

1

Constant4

47

Constant2

1

Constant14

Constant

3zeropad

2CtrlMux

1AddRead

rest swapP

SwapPage

sysgen

sel

d0

d1

MuxS

sysgen

sel

d0

d1

Mux2

sysgen

sel

d0

d1

Mux1

sysgenrst

enout

CpB7295

sysgenen out

CpB4871

sysgenrst

enout

CpA2347

sysgenen out

CpA023

rst

enac1

enac2

ctrlmux2

zeropad

ctrlmux1

ControlMuxZeroPad

1rst

PR

OY

EC

TO

DE

FIN

DE

CA

RR

ER

A

8

Página 8

Fig. 5. Barrido de puntero de escritura del puerto A, puntero de lectura del puerto B, y señal de intercambio

de página Intercambio de Páginas: La funcionalidad del intercambiador de páginas es sencilla, una vez que se han escrito los 64 datos de un símbolo OFDM se empieza por leer desde la primera localidad de memoria de la otra página para la formación del siguiente símbolo OFDM.

Fig. 6. Generador de señal de intercambio de página La salida de este bloque conmuta de una valor lógico positivo a un negativo siempre que la condición de igualdad se cumpla entre un contador de rango [0-63] y la constante 63 (Tamaño de pági-página de memoria menos uno), y se sume con el valor anterior de salida del registro, cuyo resultado es la señal de reset del registro. La salida del registro es la señal lógica que selecciona el multiplexor que tiene por entradas los contadores que representan a los punteros de lectu-lectura de ambas páginas de memoria. La salida del multiplexor se conecta al pin de direcciones del puerto B de la memoria RAM doble puerto. Control de Multiplexores y relleno con ceros:

Este bloque indica los instantes en que se insertan las portadoras pilotos, la portadora que representa la componente continua, bandas de guarda (relleno con ceros) al bloque de datos proveniente de la memoria RAM. Un valor lógi-lógico positivo de este bloque hace que se inhiba el puntero de lectura y se inserte el dato corres-correspondiente (Portadoras Piloto o Ceros): Un valor lógico negativo hace que el puntero de lectura se habilite y continué desde el valor de memoria que tuvo el momento de inhibirse.

Fig. 7. Inserción de portadoras piloto, portadora DC y relleno con ceros

El bloque Control de Multiplexores y relleno con ceros esta estructurado según se muestra en la figura 8. Los componentes de este bloque se muestran en las Fig. 9,10 y 11.

Fig. 8. Control de Multiplexores y relleno con ceros

PROYECTOS

0 500 1000 1500 2000 2500 3000 35000

10

20

30

40

50

60

70

80

90

100

Puntero de escrituraPuntero de lecturaCambio de página

1swapP

sysgena

ba=bz-0

Relational2

sysgend

rstqz-1

Register

sysgenxnorz-0

Logical1

sysgenrst out

Counter2

1

Constant4

63

Constant3

1rest

600 800 1000 1200 1400 16000

20

40

60

80

100

Inserción de portadoras

Página A.

Página B.

D

Relleno con ceros

5ctrlmux1

4zeropad

3ctrlmux2

2enac2

1enac1

sysgena

b

a>bz-0

Relational8

sysgena

b

a<bz-0

Relational7

sysgenrst out

MasterCountersysgenand

z-0

Logical4

sysgenandz-0

Logical3

sysgenandz-0

Logical1

sysgennot

Inverter1

sysgennot

Inverter

num2 CtrlZp

CtrlZP

num1 CtrlPN

CtrlPN

num Crtdc

CtrlDC

37

Constant8

27

Constant7

sysgen

hi

lo

Concat

1 rst

PR

OY

EC

TO

DE

FIN

DE

CA

RR

ER

A

9

Página 9

Fig. 9. Bloque de control de inserción de portadoras piloto C trlPN

Fig. 10. Bloque de control de inserción de portadoras DC C trldc

Fig. 11. Bloque de control de relleno con de ceros CtrlZp

CONCLUSIONES

• Los datos obtenido concuerdan con los pro-puestos, con lo que se valida el desempeño de la herramienta XSG.

• El análisis del retardo que posee cada bloque

es importante, ya que posibilita hacer el cálculo del momento en que los datos de entrada a los diferentes bloques son válidos.

• El bloque de formación del símbolo OFDM,

es parte de la implementación futura en una FPGA de Xilinx de un tranceiver OFDM.

• Se ha omitido los detalles del bloque de generación de las portadoras piloto (Bloque de generación de secuencia de Pseudo ruido PN), el cual es fácil de im-plementar, siguiendo el esquema propues-to en [5].

• El uso de paginado en memorias de doble

puerto permitirá que se pueda realizar cualquier procesamiento continuo de da-tos en diferentes aplicaciones como: pro-cesamiento de audio y video, procesa-miento de imágenes, etc.

REFERENCIAS [1]. Luders Christian y Schulze Henrik. Theory

and Applications of OFDM and CDMA, Editorial Wiley & Sons Ltd, Inglaterra 2005.

[2]. Shinsuke Hara, Ramjee Prasad. Multicarrier

Techniques for 4G Mobile Communications, Editorial Artech House.Inglaterra 2003.

[3].César A. Medina S., “Sistemas de Comuni-

cação MultiPortadora”, Diciembre de 2005. [4].M.Serra, X.Rafael, J.Ordeix, P.Martí,

J.Carrabina, Prototipo demostrador de OFDM:Transmisor,II Jornadas sobre com-putación reconfigurable y aplicacio-nes ,Almuñecar,18,20-09-2002.

[5]. Tranter W, Shanmugan K. y Rappaport T.

Principles of Communication System Simu-lation, Editorial Prentice Hall, USA 2005.

PROYECTOS

1CtrlPN

sysgenaba!=bz-0

Relational4

sysgena

ba!=bz-0

Relational3

sysgenaba!=bz-0

Relational2

sysgenaba!=bz-0

Relational1

sysgenandz-0

Logical

57

Constant4

43

Constant3

21

Constant2

7

Constant1

1num1

1Crtdc

sysgena

b

a!=bz-0

Relational

0

Constant

1num

1CtrlZp

sysgenaba<bz-0

Relational6

sysgena

b

a>bz-0

Relational5 sysgenandz-0

Logical238

Constant6

26

Constant5

1num2

PR

OY

EC

TO

DE

FIN

DE

CA

RR

ER

A

10

Página 10

Resumen: El presente trabajo define las ventajas y requerimientos de la implementación del modelo hidrológico Catamayo - Chira sobre un entorno distribuido en el cual se desea distribuir el trabajo en un entorno grid los procesos que utiliza el mo-delo hidrológico con el uso de todas las variables del modelo SWAT. INTRODUCCIÓN El proyecto del modelo hidrológico aborda objetivos cada vez más ambiciosos que requieren la resolución de problemas computacionales comple-jos, tanto por el volumen de los cálculos a realizar como por la cantidad de repeticiones en las simula-ciones debido a la calibración y variabilidad espa-cial y temporal de las variables del ciclo hidrológi-co, en las cuales el objetivo es realizarlo cada vez en periodos más cortos de tiempo. Es por ello que la tecnología grid se acopla en la implantación del modelo hidrológico, el cual propone agregar y compartir recursos de computa-ción distribuidos, a través de redes de alta veloci-dad, de modo que el acceso a los mismos por parte de los usuarios para sus necesidades de cálculo y servicios sea de la forma más sencilla, flexible, fia-ble y lo mas transparente posible.

DEFINICIÓN DEL PROBLEMA Hasta la actualidad se ha realizado la eje-cución de todos los componentes del ciclo hidroló-gico con la ayuda de un computador, pero solo se puede realizar las simulaciones de muy pocas varia-bles del modelo SWAT debido a las largas horas

que este se toma en realizar dicho proceso y aún más en la calibración respectiva que involucra dichas variables. El modelo ha sido identificado como una aplicación para ser procesado bajo un entor-no distribuido por las necesidades de procesa-miento que se producen en ciertos procesos. VENTAJAS Y REQUERIMIENTOS DE LA IMPLANTACIÓN DEL MODELO SOBRE UNA PLATAFORMA DISTRIBUIDA El procesamiento distribuido se puede implementar tomando como base el modelo cliente – servidor, donde nos permite dividir el problema computacional en tareas independien-tes que pueden ser distribuidos. Otro de los procesos de este entorno es coordinar la solución del problema computacio-nal, asignando tareas independientes a los nodos clientes, esta asignación se realiza bajo una exa-minación y categorización de acuerdo a las ne-cesidades o requerimientos de los procesos a ser ejecutados o a las capacidades técnicas necesa-rias de acuerdo a la infraestructura implementa-da. Los mecanismos de ejecución en este esquema involucran tareas de distribución de carga de trabajo y contemplan los siguientes pasos: 1. Dividir el problema computacional en tareas

independientes. 2. Inicializar los procesos clientes. 3. Especificar las tareas de comunicación que

se realizarán entre el cliente y el servidor. 4. Emitir los resultados parciales desde los

clientes, y recopilarlos en el servidor (ensamblaje de las soluciones parciales y presentación de la solución final) dicho pro-ceso puede ser realizado en forma dinámica o estática.

5. Asegurar que se recolectaron todos los re-sultados, y que los procesos clientes fueron liberados.

PROYECTOS

IMPLEMENTACIÓN DEL MODELO HIDROLÓGICO SWAT SO-BRE UNA PLATAFORMA DISTRIBUIDA

Gloria Susana Quezada Alvarez Universidad Técnica Particular de Loja

Escuela de Electrónnica y Telecomunicaciones Loja – Ecuador

AR

QU

ITE

CT

UR

A D

E C

OM

PU

TAD

OR

ES

11

Página 11

VENTAJAS En si las ventajas que se observan al imple-mentar el modelo SWAT sobre un grid computing son: • Emplee un esquema de notificaciones que infor-

me a los clientes del estado de sus simulaciones en tiempo real, haciendo conocer al usuario final los progresos de dichas simulaciones con sus res-pectivos resultados; independientes de la plata-forma en la que este se encuentre.

• Servicio grid encargado de simular, bajo deman-da, el comportamiento estructural mediante la aplicación paralela.

• Uso y variabilidad de diferentes plataformas para la realización de la ejecución del modelo.

• Ejecutar el mayor número de simulaciones por unidad de tiempo.

• A partir de un conjunto de recursos computacio-nales Grid conocidos el planificador seleccione el más adecuado para cada simulación.

• Múltiples niveles de tolerancia a fallos. • Contener un repositorio estructural donde tempo-

ralmente se almacenan los resultado de cálculo. • Ofrezca a los clientes software de cálculo, recur-

sos computacionales y espacio de almacenamien-to.

REQUERIMIENTOS Una infraestructura Grid computing necesita, para mantener su estructura, de diferentes servicios como: • Internet, conexiones de 24 horas, los 365 días,

con banda ancha • Servidores de capacidad • Seguridad informática • VPN, firewalls • Encriptación • Comunicaciones seguras • Políticas de seguridad • Normas ISO, entre otras INFORMACIÓN REQUERIDA La información con la que se cuenta es neta-mente información topográfica de tipos de suelos y uso actual, la que se obtuvo a partir de los estudios del Plan Hidráulico de Loja, así como de los estudios de la Oficina de Planificación de la Presidencia de la República (ODEPLAN). Tres estaciones metereológicas de la red del Instituto Nacional de Meteorología e Hidrología (INAMHI), dos dentro de la cuenca y una vecina a ella. Además, para fines de calibración se recolec-ta la información de caudales medios diarios registra-

dos en una estación limnigráfica localizada a la salida de la cuenca. A su vez se cuenta con: • Bases de Datos de todos los modelos digitales

del terreno en donde se encuentran ubicadas las principales cuencas y subcuencas

• Imágenes y planos • Mapas e imágenes satelitales • Mapas de ubicación de puntos postes • Mapas de especies vegetales • Mapas de lugares físicos METODOS Y HERRAMIENTAS Entre las principales herramientas tanto en hardware como en software utilizadas se observa: Arcview y SWAT. • Arcview es la herramienta que nos permite vi-

sualizar, consultar y realizar el análisis de in-formación geográfica es decir la información presentada en imágenes o mapas del modelo.

• SWAT es el modelo que se integra a Arcview el cual nos permite realizar la simulación de las cuencas y subcuencas del modelo.

• Grid Computing es la infraestructura que nos servirá de base para la ejecución del modelo con un alto nivel de procesamiento y velocidad requeridos.

GRID COMPUTING Está creado con el fin de brindar una solu-ción a problemas que requieren un gran número de ciclos de procesamiento o acceso a una gran canti-dad de datos. Para este propósito se integran diferentes tipos de máquinas y de recursos, por lo tanto una red grid nunca queda obsoleta, todos los recursos se aprovechan, recalcando que si en la grid se ob-serva diferentes características técnicas, la grid hará referencia al equipo de mínimo procesamiento como la base para el procesamiento general. Por otra parte, esta tecnología brinda como principal característica la velocidad, con lo que provee una mejora de los tiempos para la produc-ción de nuevos productos y servicios. Facilita la posibilidad de compartir, acceder y gestionar infor-mación, mediante la colaboración y la flexibilidad operacional. La tolerancia a fallos significa que si una de las máquinas que forman parte del grid colapsa, el sistema lo reconoce y la tarea se reenvía a otra máquina, con lo cual se cumple el objetivo de crear infraestructuras operativas flexibles y resistentes.

PROYECTOS

AR

QU

ITE

CT

UR

A D

E C

OM

PU

TAD

OR

ES

12

Página 12

SWAT Soil and Water Assessment Tool (SWAT) es un modelo integral de cuenca la cual permite simular la producción de agua y sedimentos en cuencas hidrográficas. Se basa en un balance hídrico que nos per-mite dividir en pequeñas subcuencas la cuenca hidrográfica con el fin de mejorar la exactitud de los cálculos. Las variables climáticas utilizadas por el SWAT son: La precipitación, La temperatura del aire, Radiación solar, Velocidad del viento y Hume-dad relativa. CARACTERÍSTICAS • Opera en intervalos de tiempo diario • Permite condiciones de simulación en tiempo

diario de grandes registros • La cuenca pueden ser subdividida para conside-

rar tipos de suelos, uso de la tierra, cultivos, topografía entre otros

• Permite y acepta datos de salida de otros pro-gramas (EPIC)

• Presenta varias versiones en diferentes platafor-mas (DOS, WINDOWS [Con GIS] UNIX [Con GIS])

SWAT se muestra como una buena herra-mienta de estudio y conocimiento de una cuenca y los procesos que ocurren dentro de ella. Permite establecer un balance global de los flujos y la distri-bución espacial y temporal, siempre que se trabaje sobre datos ya conocidos. Calibrado bajo determi-nadas situaciones, permite realizar extrapolaciones espaciales y temporales de los datos. ARCVIEW ArcView es una herramienta desarrollada por la empresa estadounidense ESRI. Con ella se pueden representar datos georreferenciados, anali-zar las características y patrones de distribución de esos datos y generar informes con los resultados de dichos análisis. Básicamente se encarga de: • Explorar y administrar la información geográfi-

ca y alfanumérica en múltiples formatos • Visualizar y consultar la información geográfica

y alfanumérica • Crear y mantener los meta datos de la informa-

ción catalogada CONCLUSIONES • El modelo hidrológico Catamayo Chira si es

una aplicación en la que se pueden paralelizar sus procesos, por ende si se puede implemen-tar en un grid computing.

• La herramienta Arcview, principal herramienta utilizada no nos permite realizar el proceso de gridificación del modelo por lo que se deben buscar otras alternativas en relación a herra-mientas que nos permitan realizar este proce-so, sin embargo el producto arcgis de ESRI es la plataforma que si permite la paralelización.

• La infraestructura grid computing opera con múltiples plataformas por ende los usuarios o nodos finales que necesiten realizar la visuali-zación de la información en arcview pueden hacerlo, para ello esta información debe estar compartida con herramientas que permitan el procesamiento de dicha información y a su vez que dichas herramientas permitan realizar el proceso de gridificación del modelo hidrológi-co.

RECOMENDACIONES • No se recomienda trabajar con herramientas

como Arcview o Argis porque son herramien-tas propietarias ya que su elevado costo sería uno de los grandes inconvenientes.

• Lo aconsejable sería migrar a plataformas open source ya que no tendríamos que preocu-parnos por los costos de las herramientas a implementar; además estas herramientas se acoplarían al grid computing debido a las faci-lidades que nos brinda este para trabajar con múltiples plataformas.

• Pero si se tiene como requerimiento la utiliza-ción de Arcview o cualquier otro programa propietario este podría ser utilizado solo por el usuario final, ya que este va a ser el principal actor que va interactuar con el grid y la imple-mentación no se elevaría demasiado en sus costos.

REFERENCIAS Oñate, Aguilar. Aplicación del modelo SWAT para la estimación de caudales y sedimentos en la cuenca alta del Río Catamayo, Universidad Técni-ca Particular de Loja, 2003.

PROYECTOS

AR

QU

ITE

CT

UR

A D

E C

OM

PU

TAD

OR

ES

13

Página 13

RESUMEN: En este artículo se presenta la construc-ción de un prototipo de pierna robótica, así como la técnica de coordinación de los servomotores. El Pro-yecto incluye elementos de electrónica, mecánica, pro-gramación a bajo nivel y embebida, programación a alto nivel y programación de interfaces gráficas (simuladores en 3d), control, y tratamiento de señales.

Palabras clave: Robótica, Bípedos, Sistemas de tiem-po real, Microcontrolador Pic, Servo Motor. INTRODUCCIÓN El desarrollo de robots y la dotación cada día de mas sensores y dispositivos actuadores mecánicos como manos, dedos, piernas, brazos, etc.; ha permitido crear prototipos o robots humanoides con similitudes abismales con respecto al hombre un ejemplo de este es ASIMO (Fig.1) fabricado por honda que dentro de sus características tiene como medidas pensadas para adap-tarse al entorno humano: 1,20 cm de altura, 450 mm de ancho de hombros, 440 mm de profundo y 43 Kg de peso.

Fig. 1. Asimo de Honda

El presente trabajo de investigación tiene como objetivo diseñar y construir un robot bípedo completa-mente autónomo y como primera fase se presenta la construcción de la parte mecánica principal del proyec-to, una de sus piernas FUNDAMENTOS DE LA CAMINATA Cada vez que damos “un paso” estamos utili-zando un complejo sistema que para los humanos es

algo fácil y además utilizando muy poca energía. Cuan-do se trata de modelar matemáticamente estos movi-mientos se aprecia que existe una cadena cinemática muy compleja y con una alta redundancia de movimien-tos es decir existen muchas posibilidades de dar un mo-vimiento. Nuestro cuerpo tiene algunos tipos de articu-laciones, para nuestro investigación nos centraremos en las que tiene una cavidad sinovial (Fig.2) es decir un eje de giro dentro de estas tenemos la articulación tipo bisa-gra que la encontramos en las rodilla, codo y tobillo y permite solo flexión y extensión; otro tipo es la esferoide y permite movimiento en todas direcciones flexión, ex-tensión, abducción, aducción y rotación ejemplo de esta es el hombro y la cadera. Basándonos en los principios y la teoría de estas articulaciones construiremos un modelo de un bípedo con 12 DOF (Grados de Libertad), 6 por cada pierna. En esta primera parte de esta investigación se dará una introducción y creara las primeras nociones de simulación. En la siguiente figura se verá un ciclo de cami-nata de un humano. Este ciclo empieza cuando se pone el pie en el piso, luego se flexiona el pie y el pie contra-rio se levanta del piso es aquí donde se pierde el equili-brio el robot y nuestro sistema debe responder ajustando el centro de gravedad pues el cuerpo cae hacia ese lado y adelante o atrás dependiendo de la dinámica del movi-miento, hasta aquí se ha logrado un 50% del proceso, lo restante se desarrolla de forma similar al anterior.

Fig. 2. Ciclo de caminata

Hay que reconocer que existen 2 tipos de cami-natas que son: activa y pasiva, ya que existen robots que por inercia y gravedad pueden caminar (caminata pasi-va), opuesto a esto existen los robots que están dotados de sensores, motores y baterías los cuales pueden despla-zarse por cualquier lugar e incluso gradas.

CONTROL NUMÉRICO Y SIMULACIÓN DE UNA EXTREMIDAD INFERIOR (PIERNA ROBÓTICA)

PARTE I Bruno M. Valarezo, David I. Ruiz, Tayron Ramirez

Grupo de Electricidad y Sistemas Electrónicos Universidad Técnica Particular de Loja

[email protected], [email protected], [email protected] Loja-Ecuador

PROYECTOS

GR

UP

O D

E R

OB

ÓT

ICA

14

Página 14

SIMULACIÓN DEL PROTOTIPO Se ha iniciado la simulación del prototipo en la Labview, que basándonos en parámetros bási-cos y con tres grados de libertad para empezar a familiarizarnos con el control automático en lazo cerrado del prototipo.

Fig. 3. Simulador de la pierna

También se ha desarrollado una maqueta del prototipo para la comprobación de los algorit-mos y empezar a trabajar de forma practica la pla-neación de la caminata de un robot bípedo

Fig.4. Maqueta del prototipo

CONCLUSIONES Se ha logrado entender el proceso de cami-nata de un humano y tratar de modelarlo. Se ha comprendido la magnitud del pro-yecto por lo que lo hemos dividido en fases que se irán publicando en ediciones posteriores de la re-vista. Se ha empezado el estudio matemático, pero por razones de complejidad aun no hemos escrito ya que tenemos una fase dedicada específi-camente a la cinemática inversa del robot. TRABAJOS FUTUROS Se pretende crear un prototipo de un robot bípedo totalmente autónomo y luego agregarle al-goritmos de visión artificial, sistemas de sensores para evadir obstáculos, etc.

La magnitud del proyecto es bastante com-pleja y necesita una investigación baste fuerte, por lo que invitamos a todas las personas que se quieran unir al grupo de control automático y robótico. REFERENCIAS [1]http://es.wikipedia.org/wiki/Imagen:Robot_asimo.jpg [2] Tortora- Derickson Principios de Anatomia y Fisiologia [3]- Adam. B. Zoss. H.Kazerooni, Andrew Chu. WBiomechanical Desing of Berkeley Lower Extrem-ity Exoskeleton(BLEEX) [4]http://www.roboticspot.com/spot/artic.shtml?todo=&block=5&newspage=tiposderobots [5]ht tp: / /es .geoci t ies .com/oscar_vele/pdfs/resumen_dyc_rob_bip.pdf [ 6 ] h t t p : / / u m s i s . m i a m i . e d u / ~ a s k l a r / H D P -WCAFR2005.pdf BIOGRAFÍA Tayron E. Ramirez M.

Profesional en Formación Mail: [email protected] Experiencias: Trabajo en Telecomu-nicaciones dentro del área de Cablea-do Estructurado, actualmente se des-empeña realizando gestión producti-va en el GESE, Grupo de Control Automático y Robótica

Bruno M. Valarezo.

Profesional en Formación Mail: [email protected] Experiencias: Se desempeña reali-zando gestión productiva en el GE-SE, Grupo de Control Automático y Robótica

David Israel Ruiz Cabrera

Profesional en Formación E-mail :[email protected] Experiencias: Trabajo en Gestión productiva en el grupo de Investiga-ción “Software Radio” dentro del área de GESE de la Unidad de Pro-yectos de Sistemas Informáticos (UPSI). Actualmente se desempeña realizando gestión productiva en el

GESE, Grupo de Control Automático y Robótica.

GR

UP

O D

E R

OB

ÓT

ICA

PROYECTOS

15

Página 15

RESUMEN: El presente artículo muestra la for-ma de usar Matlab y funciones de su toolbox de procesamiento de imágenes para reconocer una palabra o conjunto de palabras y números en una imagen.

Palabras clave.- correlación, OCR, IPT, filtrado, imagen binaria, imagen RGB.

INTRODUCCIÓN La tecnología OCR proporciona a los sis-temas de reproducción por escáner y sistemas de imágenes la habilidad de convertir imágenes de caracteres en letra de máquina, en caracteres capa-ces de ser interpretados o reconocidos por una computadora. Así, las imágenes de caracteres en letra de máquina son extraídas de un mapa de bits de la imagen reproducida por el escáner [1].

Fig.1. Esquema de un OCR

El proceso OCR envuelve varios aspectos como segmentación, extracción de características y clasificación [2].

Image Processing Toolbox proporciona a MATLAB un conjunto de funciones que amplía las capacidades del producto para realizar desarro-llo de aplicaciones y de nuevos algoritmos en el campo del proceso y análisis de imágenes. El en-torno matemático y de creación de MATLAB es ideal para el procesado de imágenes, ya que estas imágenes son, al fin y al cabo, matrices. Este tool-box incorpora funciones para:

• Diseño de filtros • Mejora y retocado de imágenes

• Análisis y estadística de imágenes • Operaciones morfológicas, geométricas y de

color • Transformaciones 2D El procesamiento de imágenes es un cam-po de trabajo absolutamente crucial para aquellos colectivos e industrias que estén trabajando en áre-as como diagnóstico médico, astronomía, geofísi-ca, ciencias medioambientales, análisis de datos en laboratorios, inspección industrial, etc. [3].

DESARROLLO DEL PROGRAMA

SEGMENTACIÓN Como primer paso, se recorta la imagen para ajustarla al texto. Luego de esto, se separa línea por línea. La función que realiza el recorte de la imagen se muestra a continuación: function imgn=clip(imagen)

% Crops a black letter with white background. %Example: % imagen=imread('metal.bmp'); % imgn=clip(imagen); % subplot(2,1,1);imshow(imagen); %title('INPUT IMAGE') % subplot(2,1,2);imshow(~imgn); %title('OUTPUT IMAGE') if ~islogical(imagen) imagen=im2bw(imagen,0.99); end a=~imagen; [f c]=find(a); lmaxc=max(c);lminc=min(c); lmaxf=max(f);lminf=min(f); imgn=a(lminf:lmaxf,lminc:lmaxc);%Clip image

Fig.2. Esquema de función que recorta la imagen al tamaño de la letra

RECONOCIMIENTO DE CARACTERES ÓPTICOS (OCR) USANDO MATLAB

Diego Barragán, Pablo Vallejo Universidad Técnica Particular De Loja

Escuela De Electrónica y Telecomunicaciones [email protected], [email protected]

Loja-Ecuador

PR

OFE

SIO

NA

LES

EN

FO

RM

AC

IÓN

PROYECTOS

16

Página 16

Tal como se ve en la función, el umbral para la transformación a imagen binaria es 0.99 (bn=im2bw(imagen,0.99)). Este umbral se tomó para que colores con valores RGB muy cercanos a 255 (valor máximo) sean considerados como 0 en la imagen binaria. Una vez recortada la imagen, el siguiente paso es separar cada línea. Para esto se usó la si-guiente función: function [fl re]=lines(aa) %Divide text in lines. %aa->input image; fl->first line;re->remain line %Example: %aa=imread('heavy_metal.bmp'); %[fl re]=lines(aa); %subplot(3,1,1);imshow(aa); %title('INPUT IMAGE') %subplot(3,1,2);imshow(fl);title('FIRST LINE') %subplot(3,1,3);imshow(re); %title('REMAIN LINES') aa=clip(aa); [r c]=size(aa); for s=1:r if sum(aa(s,:))==0 nm=aa(1:s-1,1:end);%First line matrix rm=aa(s:end,1:end);%Remain line matrix fl=~clip(~nm); re=~clip(~rm); %Uncomment lines below to see the result % subplot(2,1,1);imshow(fl); % subplot(2,1,2);imshow(re); break else fl=~aa;% Only one line. re=[]; end end

Fig.3. Esquema de la función para separar líneas en la imagen

EXTRACCIÓN

Una vez obtenidas por separado cada línea de la imagen, se procede a extraer letra por letra de la imagen matriz fl. Para esto se usó la función bwlabel, la cual etiqueta los componentes conecta-dos de la imagen. En otras palabras, esta función cuenta los trazos continuos y los enumera. Para separar cada letra se usó el siguiente código: %-*-Calculating connected components*-*-*-*-* %Code from: %http://www.mathworks.com/matlabcentral/fileexchange/loadFile.do?objectId=8031&objectType=FILE

L = bwlabel(imgn); mx=max(max(L)); BW = edge(double(imgn),'sobel'); [imx,imy]=size(BW); for n=1:mx [r,c] = find(L==n); rc = [r c]; [sx sy]=size(rc); n1=zeros(imx,imy); for i=1:sx x1=rc(i,1); y1=rc(i,2); n1(x1,y1)=255; end %*-*-END Calculating connected components*-*-

Luego cada letra es normalizada a un ta-maño de 42 x 24 píxeles, que es el tamaño de la plantilla con la que realizará la correlación. Para la normalización se usó la siguiente función: function img_r=same_dim(imagen_g) %Example: % imagen_g=imread('a_reducir.bmp'); % img_r=same_dim(imagen_g); % subplot(2,1,1);imshow(imagen_g); % title('Image m x n') % subplot(2,1,2);imshow(img_r); % title('Image 42 x 24') [a b]=size(imagen_g); img_r=imagen_g(1:a/42:end,1:b/24:end);

Fig.4. Esquema de la función de normalización de tamaño de muestra

CLASIFICACIÓN La operación principal que se empleó para la clasificación fue la correlación en dos dimensio-nes. Esta operación da un valor de la semejanza entre dos matrices (imágenes). La función corr2 desarrolla esta operación según la siguiente ecua-ción [4]:

Donde =mean2(A) y =mean2(B).

( )( )

( ) ( )2 2

mn mnm n

mn mnm n m n

A A B Br

A A B B

− −=

⎛ ⎞⎛ ⎞− −⎜ ⎟⎜ ⎟⎝ ⎠⎝ ⎠

∑∑

∑∑ ∑∑

A B

PROYECTOS

PR

OFE

SIO

NA

LES

EN

FO

RM

AC

IÓN

17

Página 17

La siguiente función realiza la correlación entre las plantillas y cada letra extraída: function letter=read_letter(imagn) %Compute the correlation between template and %input image and its output is a string con-taining the letter. %Size of 'imagn' must be 42 x 24 pixels %Example: % imagn=imread('D.bmp'); % letter=read_letter(imagn) comp=[]; load templates for n=1:36 sem=corr2(templates{1,n},imagn); comp=[comp sem]; end vd=find(comp==max(comp)); %*-*-*-*-*-*-*-*-*-*-*-*-*- if vd==1 letter='A'; elseif vd==2 letter='B'; elseif vd==3 letter='C'; elseif vd==4 letter='D'; elseif vd==5 letter='E'; elseif vd==6 letter='F'; elseif vd==7 letter='G'; elseif vd==8 letter='H'; elseif vd==9 letter='I'; elseif vd==10 letter='J'; elseif vd==11 letter='K'; elseif vd==12 letter='L'; elseif vd==13 letter='M'; elseif vd==14 letter='N'; elseif vd==15 letter='O'; elseif vd==16 letter='P'; elseif vd==17 letter='Q'; elseif vd==18 letter='R'; elseif vd==19 letter='S'; elseif vd==20 letter='T'; elseif vd==21 letter='U'; elseif vd==22 letter='V'; elseif vd==23 letter='W'; elseif vd==24 letter='X'; elseif vd==25 letter='Y'; elseif vd==26 letter='Z'; %*-*-*-*-**-*-*-*-**-*-*- elseif vd==27 letter='1'; elseif vd==28 letter='2'; elseif vd==29 letter='3'; elseif vd==30 letter='4'; elseif vd==31 letter='5'; elseif vd==32 letter='6'; elseif vd==33 letter='7'; elseif vd==34 letter='8'; elseif vd==35 letter='9'; else letter='0'; end

PLANTILLAS Cada plantilla es una imagen binaria bmp de 42 x 24 píxeles. El script para almacenar las plantillas en una estructura de celda es el siguien-te: %CREATE TEMPLATES %Letter A=imread('A.bmp');B=imread('B.bmp'); C=imread('C.bmp');D=imread('D.bmp'); E=imread('E.bmp');F=imread('F.bmp'); G=imread('G.bmp');H=imread('H.bmp'); I=imread('I.bmp');J=imread('J.bmp'); K=imread('K.bmp');L=imread('L.bmp');

M=imread('M.bmp');N=imread('N.bmp'); O=imread('O.bmp');P=imread('P.bmp'); Q=imread('Q.bmp');R=imread('R.bmp'); S=imread('S.bmp');T=imread('T.bmp'); U=imread('U.bmp');V=imread('V.bmp'); W=imread('W.bmp');X=imread('X.bmp'); Y=imread('Y.bmp');Z=imread('Z.bmp'); %Number one=imread('1.bmp'); two=imread('2.bmp'); three=imread('3.bmp');four=imread('4.bmp'); five=imread('5.bmp'); six=imread('6.bmp'); seven=imread('7.bmp');eight=imread('8.bmp'); nine=imread('9.bmp'); zero=imread('0.bmp'); %*-*-*-*-*-*-*-*-*-*-*- letter=[A B C D E F G H I J K L M... N O P Q R S T U V W X Y Z]; number=[one two three four five... six seven eight nine zero]; character=[letter number]; templates=mat2cell(character,42,[24 24 24 24 24 24 24 ... 24 24 24 24 24 24 24 ... 24 24 24 24 24 24 24 ... 24 24 24 24 24 24 24 ... 24 24 24 24 24 24 24 24]); save ('templates','templates')

PROGRAMA PRINCIPAL El programa principal se muestra a con-tinuación: %OCR (Optical Character Recognition). %PRINCIPAL PROGRAM

%Private Technical University of Loja

% (ECUADOR-SUDAMERICA) %************************************* warning off,clc, close all, clear all imagen=imread('judas.jpg');%Read Binary Image %*-*-*Filter Image Noise*-*-*-* if length(size(imagen))==3 %RGB image imagen=rgb2gray(imagen); end imagen = medfilt2(imagen); [f c]=size(imagen); imagen (1,1)=255; imagen (f,1)=255; imagen (1,c)=255; imagen (f,c)=255; %*-*-*END Filter Image Noise*-*-*-* word=[];%Matrix to store word from image re=imagen; fid = fopen('text.txt', 'wt');%Open text.txt as file for write while 1 [fl re]=lines(re);%Fcn 'lines' separate %lines in text imgn=~fl; %*-*Uncomment line below to see %sentences*-*-*-* %imshow(fl);pause(1) %*-*--*-*-*-*-*-*- %*-Calculating connected components*-* %Code from: %http://www.mathworks.com/matlabcentral/fileexchange/loadFile.do?objectId=8031&objectType=FILE

L = bwlabel(imgn); mx=max(max(L)); BW = edge(double(imgn),'sobel'); [imx,imy]=size(BW); for n=1:mx

PROYECTOS

PR

OFE

SIO

NA

LES

EN

FR

OM

AC

IÓN

18

Página 18

[r,c] = find(L==n); rc = [r c]; [sx sy]=size(rc); n1=zeros(imx,imy); for i=1:sx x1=rc(i,1); y1=rc(i,2); n1(x1,y1)=255; end %-END Calculating connected compo-nents*- n1=~n1; n1=~clip(n1); img_r=same_dim(n1);%To size 42 X 24 %Uncomment line below to see %letters % imshow(img_r);pause(1) %*-*-*-*-*-*-*-* letter=read_letter(img_r);%img to text word=[word letter]; end fprintf(fid,'%s\n',word);%Write 'word' in %text file word=[];%Clear 'word' variable %*-*When sentences finish, breaks the loop** if isempty(re)%See variable 're' %in Fcn 'lines' break end %*-*-*-*-*--*-*-*-*-*-*-*--*-*-*-*-*-*-*-*-* end fclose(fid); winopen('text.txt')%Open 'text.txt' file

ENSAYO DEL PROGRAMA Una vez terminado el programa, al ejecu-tarse puede usarse las funciones tic y toc al inicio y final del código para medir su tiempo de res-puesta. Cuando termine la ejecución se abrirá un archivo de texto que contiene las palabras de la imagen:

Fig. 5. Resultado del programa

Otro ensayo que se realizó fue con una hoja escaneada con una resolución de 200 PPP y un brillo de 128 (parámetros por defecto del escá-ner) que contenía varias palabras manuscritas y

algunos números. La muestra se indica en la figura siguiente:

Fig. 6. Texto de prueba a escanear

Al escanear la imagen se produce cierto ruido (puntos negros) en ésta. La solución es im-plementar un filtro al inicio del código para elimi-nar el ruido.

%*-*-*Filter Image Noise*-*-*-* if length(size(imagen))==3 %RGB image imagen=rgb2gray(imagen); end imagen = medfilt2(imagen); [f c]=size(imagen); imagen (1,1)=255; imagen (f,1)=255; imagen (1,c)=255; imagen (f,c)=255; %*-*-*END Filter Image Noise*-*-*-*

Al aplicar el programa se obtuvo los si-guientes resultados:

Fig. 7. Texto reconocido

Se puede deducir que el error presente en los tres primeros sietes se debe a la pequeña curva-tura que posee la plantilla, que si la posee el últi-mo 7.

PROYECTOS

PR

OFE

SIO

NA

LES

EN

FO

RM

AC

IÓN

19

Página 19

CODE METRICS MATLAB posee dos herramientas que ayudan a mejorar el código. La una es el profile, la cual, entre otras cosas, calcula el tiempo de ejecu-ción de cada función, y muestra que variables pue-des descartarse del código para acelerarlo. La segunda herramienta es code metrics, un programa que está disponible en el File Ex-change de MathWorks [5]. Este programa determi-na si los nombres de las funciones que estamos usando no tienen conflicto con funciones ya defi-nidas en el path del MATLAB, una medida de la complejidad del programa (cyclomatic complexity) y sugerencias muy prácticas para mejorar el fun-cionamiento del programa. El resultado de aplicar code metrics al OCR es el siguiente:

CONCLUSIONES

• El tamaño de la letra debe no ser menor a 42 x 24 píxeles.

• La imagen de entrada puede ser con letras de color o no.

• Si la imagen presenta ruido en los bordes mayor al que puede filtrar la función med-filt2, será necesario usar la función imcrop para recortar la imagen.

• Si el tamaño de la letra es delgado, se debe usar la función imdilate para aumentar su grosor antes de pasar al programa.

• Para tener como resultado un texto en minúsculas, se usa la función lower sobre la variable word del programa principal.

• El tiempo de procesamiento del texto de prueba de la figura 6 fue: >> tic;OCR;toc Elapsed time is 3.806446 seconds. Sin em-bargo, en un PC con 1 GB de RAM el tiem-po de procesamiento fue de 2.4 segundos

• Este tiempo de procesamiento se reduciría si

se usa una plantilla de 20 x 20 píxeles.

REFERENCIAS

[1]. http://www.pearsonncs.com/

[2]. A MATLAB PROJECT IN OPTICAL CHAR-ACTER RECOGNITION (OCR), Jesse Han-sen

[3]. http://www.eldish.net/hp/automat/matlab.htm

[4]. RECONOCEDOR DE DÍGITOS MANUS-CRITOS, Marcelo Valdiviezo C., Revista “En Corto Circuito”, núm. 11, Enero de 2007.

[5]. Link de code metrics en mathworks: http://www.mathworks.com/matlabcentral/fileexchange/loadFile.do?objectId=10514&objectType=file

BIOGRAFÍAS

Diego Barragán Guerrero Profesional en formación

E-mail: [email protected] Experiencias: editor de la Revista de Electrónica y Telecomunicaciones “En Corto Circuito”, actualmente se desempeña como pasante en la cen-tral de conmutación de Pacifictel Loja.

Pablo Vallejo Zúñiga Profesional en formación

E-mail: [email protected] Experiencias: gestión productiva en el departamento de Electricidad y Siste-mas Electrónicos en Diseño y Mante-nimiento Eléctrico, actualmente se desempeña como pasante en proyec-tos de telecomunicaciones en Pacific-

tel Loja.

PROYECTOS

PR

OFE

SIO

NA

LES

EN

FO

RM

AC

IÓN

20

Página 20

RESUMEN: El presente proyecto se lo realizó con el objetivo de implementar una unidad portátil para la transmisión de audio y video de alta calidad disponible en el Campus de la Uni-versidad Técnica Particular de Loja. El sistema consta de un transmisor portátil y un receptor fijo. Para establecer la cobertura del sistema se utilizó las recomendaciones UIT-R P.1411-2 y UIT-R P.526. Según los resultados obtenidos existe señal de audio y video en todo el Campus, tanto para las áreas con y sin visibilidad directa; pero al realizar el estudio de campo se determinó que existe comunicación únicamente en los pun-tos con línea de vista. INTRODUCCIÓN La Universidad Técnica Particular de Loja no cuenta con un sistema de comunicación en ra-diofrecuencia (RF) que permita la transmisión desde cualquier punto del campus a una estación de recepción en tiempo real. Para solventar este requerimiento se plan-tea el proyecto “Sistema de transmisión de audio y video portátil” y para ponerlo en marcha es nece-sario que el sistema de audio y video portátil opere en la banda ISM, ya que el uso de equipos en esta banda no requiere licencia de funcionamiento emi-tida por parte del organismo regulador. La solución escogida es el equipo “Eagle PLUS” de la casa comercial TrangoBroadband que es un sistema profesional de video inalámbri-co de alta resolución de 2.4Ghz.

DISEÑO E IMPLEMENTACION CARACTERÍSTICAS GENERALES Para implementar un sistema de comuni-cación de audio y video en el campus UTPL se debe tener en cuenta algunas condiciones genera-les propias del sistema, tales como: • Entorno: Campus Universitario (radio de co-

bertura 250m) • Banda de frecuencia: libre • Equipo de transmisión portátil • Transmisión de la señal en tiempo real

• Transmisión de la señal en tiempo real • Medio de transmisión: espectro radioeléctrico • Estándar NTSC Estas consideraciones permiten hacer una adecuada selección del equipo a implementar, el modelo de propagación a aplicar y determinar la zona de cobertura obtenida en base al estudio de campo. EQUIPO DE TRANSMISIÓN El equipo portátil consta de una fuente de poder ininterrumpida, una tarjeta de transmisión de audio/video y un sistema radiante. Fuente de poder ininterrumpida (UPS) Durante la transmisión es necesario garan-tizar que esta sea continua y no presente interrup-ciones en caso de que cese la energía proveniente de la red de distribución, es por ello que se cons-truyo un sistema de respaldo (UPS) sistema que proporciona una transferencia igual a cero. La fuente de poder ininterrumpida esta integrada por un rectificador, una batería recarga-ble e indicadores (Fig.1)

Fig. 1. Esquema de la fuente de poder ininterrumpida

Tarjeta de transmisión La placa VTX2500 [1] posee las siguientes interfa-ces (Fig.2): • Video • Audio (estéreo) • Datos/Configuración • Salida de RF • Alarmas

PROYECTOS

PR

OY

EC

TO

DE

FIN

DE

CA

RR

ER

A

SISTEMA DE TRANSMISIÓN DE AUDIO Y VIDEO PORTÁTIL

Ana Gabriela Correa Mena, Marco Morocho Yaguana Universidad Técnica Particular de Loja

Escuela de Electrónnica y Telecomunicaciones [email protected], mvmorochoqutpl.edu.ec

Loja – Ecuador

21

Página 21

Fig. 2. Esquema de la tarjeta de recepción

Sistema radiante El equipo EAGLE PLUS incluye antenas sectoriales de 60º con 10 dBi de ganancia y una polarización circular, para ser utilizadas tanto en el transmisor como en el receptor. La antena de recepción tiene un conector hembra SMA (Sub- Miniature version A connec-tor), y en transmisión un conector hembra RPSMA (Reverse Polarity SMA). Con las antenas viene incorporado un pigtail (KSR200) [2] de 20cm de longitud, en el transmisor se agrega una línea de transmisión flexible y de bajas pérdidas (RG58ultra) [2] de 3mpara facilitar su portabili-dad. EQUIPO DE RECEPCIÓN El receptor tiene la misma funcionalidad que la tarjeta de transmisión (Fig. 3).

Fig. 3. Esquema de la tarjeta de recepción CONFIGURACIÓN DE EQUIPOS El transmisor y el receptor pueden ser programa-dos a través del PC gracias al software Trango-Link [1]. Transmisor Eagle Plus La fig. 4 muestra el panel principal de configuración en el que se puede seleccionar el

canal de operación, modo de transmisión: standby o normal. El modo standby permite el ahorro de energía hasta que vuelva al estado normal median-te la activación de la alarma 1, switch Toggle/Standby o mediante el software TrangoLink. Una vez activado al modo normal se activa un tempori-zador preconfigurado de 1 a 255 minutos, una vez que el temporizador expire vuelve al estado de standby. Si el tiempo es 0 el transmisor no regresa al modo standby.

Fig. 4. Pantalla principal de control (Tx)

Transmisión de datos En la figura 5 se ilustra la ventana de con-figuración para la transmisión de datos, en la cual se puede configurar la velocidad de transmisión y la paridad. Cabe señalar que para la transmisión de datos el switch “Alm/Data Mode On” debe estar activado, el canal de audio derecho se deshabilita y solo se puede transmitir en mono aural. Las alar-mas y la autenticación no se transmiten en este mo-do. Para la transmisión de datos se utiliza el CBLDAT-2 [1] para conectar el transmisor/receptor con el PC que maneja la interfaz RS232 y se puede visualizar mediante el Hyper Terminal.

Fig. 5.

Modo de configuración de datos

PROYECTOS

PR

OY

EC

TO

DE

FIN

DE

CA

RR

ER

A

22

Página 22

Código de autenticación En la ventana de autenticación (Figura 6) se configura un código de 32 bits que envía el transmisor al receptor para verificar que la señal está siendo recibida desde la propia fuente. Si el código es incorrecto el video es receptado pero no se garantiza que la señal sea emitida por el emisor deseado.

Fig. 6. Configuración del código de autenticación Receptor Eagle Plus La figura 7 presenta la pantalla principal de configuración del receptor, que permite selec-cionar el canal de operación, visualizar la potencia de la señal, el estado de las alarmas, Link Verifi-cations Error, Sync Loss y Low Transmitter Batte-ry. Si el Link Verifications Error está de color verde indica que el receptor se ha autenticado con el transmisor, es decir que tienen el mismo código, caso contrario el indicador se pondrá de color rojo. El color verde en Sync Loss indica que el receptor detecta un pulso vertical síncrono en la señal de video recibida. El rojo indica que el video no está siendo transmitido. Si Low Transmitter Battery está de color verde indica que los niveles de tensión están entre 6 y 12V. El color rojo indica que el transmisor tiene un voltaje menor que 6V.

Fig.7. Pantalla principal de control (Rx) La configuración del código de autentica-

autenticación y del modo de datos en el receptor es la misma que en el transmisor. ESTUDIO DE PROPAGACIÓN El campus universitario (Figura 8) está compuesto por diferentes ambientes que dificultan la propagación de una manera homogénea. Las recomendaciones que se ajustan a este ambiente son: • UIT-R P.1411-2 “Datos de propagación y

métodos de predicción para la planificación de los sistemas de radiocomunicaciones de exte-riores de corto alcance y redes de radiocomuni-caciones de área local en la gama de frecuen-cias de 300MHz a 100GHz” [3].

• UIT-R P.526 “Propagación por Difracción” [4]. Para aplicar adecuadamente las recomen-daciones, al campus se lo ha dividido en áreas. • Área1. No existe línea de vista con el receptor

ubicado en el edificio de la UPSI (UIT-R P.1411-2)

• Area2. Sectores con visibilidad directa (UIT-R P.1411-2)

• Área3. Cafetería (UIT-R P.526)

Tabla 1: Área 1

Tabla 2: Área 2

Tabla 3: Área 3

Descripción Edificio Altura(m) T Centro de Convencio-

nes 8.10

B Modalidad Abierta 14.35 A Central 7.80

Descripción Edificio Altura(m) M Cafetería 5.55

PROYECTOS

PR

OY

EC

TO

DE

FIN

DE

CA

RE

RR

A

Descripción Edificio Altura(m) J,E,C Octógono 9.20

K Laboratorio 16.80 I Sala de Usos Múlti-

ples 10.60

3 Oskar Jandl 11.20 4 Virginia Riofrío 11.20 5 Contabilidad 11.60 6 Bellas Artes 9.30

23

Página 23

Figura 8. Campus UTPL Recomendación UIT-R P.1411-2 Parámetros necesarios para la aplicación de la recomendación: • Tipo de célula: Microcélula (Campus universi-

tario: radio de 250m) • Situación de propagación: Propagación por

encima de los tejados sin visibilidad directa. • Altura de la antena de la estación base (hb):

15.57m (transmisión desde el cuarto piso) • Altura de la antena de la estación móvil (hm):

1.5m. • Frecuencia de operación (f): 2400MHz. • Distancia desde la estación base a la estación

móvil (d): 500m Esta recomendación utiliza el modelo de difracción multipantalla, valido si las alturas de los edificios tienen aproximadamente la misma altura, se definen tres tipos de pérdidas: • Pérdidas en el espacio libre (Lbf) • Pérdidas de difracción entre el tejado y la calle

(Lrts) • Reducción debida a la difracción de pantalla

múltiple al pasar por líneas de edificios (Lmsd)

Para obtener la potencia de recepción se debe tomar en cuenta las pérdidas entregadas al utilizar el modelo multipantalla. Recomendación UIT-R P.526 El modelo de obstáculo redondeado resul-ta aplicable a los trayectos que salvo esta obstruc-ción, son de visibilidad directa. Al realizar las transmisiones desde la cafetería el edificio Central crea obstrucción, es por ello el uso de ésta reco-mendación.

En la fig. 9 se muestra los niveles de po-tencia al utilizar las dos recomendaciones UIT-R P, en las tres áreas existe un nivel aceptable de poten-cia de recepción que esta por encima de la sensibi-lidad del receptor (-90dB).

Fig. 9. Niveles de potencia de recepción ZONA DE COBERTURA Y CALIDAD DE LA

SEÑAL Puntos de Prueba Los puntos a evaluar corresponden a las áreas analizadas en el estudio de propagación. Ca-be recalcar que la ubicación del receptor es el cuar-to piso del edifico UPSI. Del estudio de campo, que permite corro-borar los niveles de potencia obtenidos en el estu-dio de propagación, se concluye que la señal de audio y video está presente en los sectores en los que únicamente hay línea de vista (Fig. 9).

Fig. 10. Señal de audio y video en el campus UTPL Calidad de la señal Para evaluar la calidad y degradación de las imágenes se utiliza la recomendación UIT-R BT. 500-11

PROYECTOS

PR

OY

EC

TO

DE

FIN

DE

CA

RR

ER

A

24

Página 24

“Metodología parala evaluación subjetiva de la calidad de las imágenes de televisión”, que utiliza una escala de cinco notas (Tabla 4).

Tabla 4: Escala de cinco notas

Las imágenes son de excelente calidad y degradación imperceptible solamente cuando exis-te línea de vista (Tabla5).

Tabla 5: Comparación de la imagen en transmisión y recepción

CONCLUSIONES • La transmisión de audio y video es en tiempo

real. • El requisito indispensable para poder lograr

enlaces óptimos con el equipo EAGLE PLUS es tener línea de vista entre los puntos a enla-zar.

• La distancia máxima de transmisión es de 1.8 Km con línea de vista.

• La fuente de poder ininterrumpida en el trans-misor tiene una transferencia igual a cero.

• El sistema de audio y video permite la transmi-sión de datos con velocidades de transmisión de 1200 a 9600 bps.

• Los equipos implementados no permiten real-

zar un procesamiento del audio y video a ser transmitido.

• La calidad de la señal es excelente en los luga-res con visibilidad directa.

RECOMENDACIONES • Si se observa interferencia (líneas) en el moni-

tor, se debe cambiar el canal de transmisión pa-ra una mejor recepción.

• El transmisor y el receptor tienen que estar con-figurados en el mismo canal.

• Para alcanzar distancias superiores a los 1.6Km se puede utilizar antenas con mayor ganancia en recepción, por ejemplo con antenas (grilla) de 23dBi se logra una distancia de 6.4 Km.

• Si la alimentación en el transmisor es menor a 6V las alarmas no se generan.

• Para la transmisión de datos el transmisor y re-ceptor deben estar el modo de configuración de datos y el switch activo en “ALM/Data Mode On”.

• La velocidad de transmisión y la paridad deben ser los mismos valores configurados tanto en el transmisor como receptor.

• Si se quiere que el transmisor realice funciones de vigilancia se puede conectar detectores de movimiento, sensores de seguridad en las alar-mas de la tarjeta de transmisión.

• Si se necesita procesar la señal de audio y video antes de ser transmitida se sugiere realizarlo mediante el uso de una consola.

REFERENCIAS [1] Página Web TrangoLink Software, equipo Ea-gle Plus: www.trangosys.com

[2] Página Web Tipos de cables coaxiales: www.kingsignal.com

[3] UIT-R P.1411-2 “Datos de propagación y métodos de predicción para la planificación de los sistemas de radiocomunicaciones de exteriores de corto alcance y redes de radiocomunicaciones de área local en la gama de frecuencias de 300MHz a 100GHz”.

[4] UIT-R P.526 “Propagación por Difracción”

[5] UIT-R BT.500-11 “Metodología para la eva-luación subjetiva de la calidad de las imágenes de televisión”

PROYECTOS

PR

OY

EC

TO

DE

FIN

DE

CA

RR

ER

A

25

Página 25

RESUMEN En este trabajo se presenta la implementación de un sistema de telemetría de constantes vitales desarrollado por medio de sistemas integrados (embedded system). El uso de sistemas integra-dos nos permite desarrollar aplicaciones versáti-les como la presentada aquí. Este tipo de tecno-logía permite dar conectividad a dispositivos que sólo cuentan con entrada serial a redes locales. Palabras Claves: TINI, Oxímetro, Java INTRODUCCIÓN El siguiente trabajo describe la implemen-tación de un sistema de telemetría que esta basado en un protocolo de comunicación, diseñado para permitir al equipo médico tal como sensores oximétricos que cuentan con salida serial y otros tipos de dispositivos físicos de entrada/salida se-riales comunicarse sobre una red de datos. La mayoría de los dispositivos médicos sólo cuen-tan con una interface serial para comunicación, sin embargo, la telemetría se realiza a través de una red de datos, en este caso Internet, por lo cual se ha visto la necesidad de crear un sistema que nos permite comunicar al sensor oximétrico con la red Internet para lo cual se hizo uso de la tarjeta TI-NI1 como interfaz, la cual nos permitirá que este dispositivo interactúe con la red de Internet.

La interfaz nos permitirá dar conectividad a dispositivos con sólo salida serial (RS-232) a la red de área local. Se ha desarrollado una aplicación JAVA,

para la plataforma TINI, que implementa un puente entre protocolos RS-232 (serie) y Ethernet. CARACTERÍSTICAS Para el desarrollo de sistemas y redes de telemedicina, se debe tener en cuenta las estructu-ras básicas de un sistema de telemetría médico. Un sistema de telemetría consta de tres estructuras básicas:

a) Estación de captura y envió de la información médica permite generar y/o capturar la información médica, manejarla, digitalizarla y enviarla a las estaciones remotas a través de una red que conecta a estas estaciones con la estación de captura.

b) Red de comunicaciones de la información médi-ca. Consiste en la infraestructura de comunicacio-nes que permite, a través de medios físicos y me-diante la utilización de protocolos específicos, transmitir la información médica entre la estación de envió, y las de recepción de dicha información.

c) Estación de recepción de la información médica.

Consiste en la infraestructura informática que permite recibir y recuperar la información médica en su forma original, así como procesarla y reproducirla, de acuerdo a las necesidades médicas correspondientes a la aplicabilidad que se le de a la misma. El PC es el encargado de monitorear, reci-bir y manipular la información a través del softwa-re que viene incluido con el sensor. DESCRIPCIÓN DEL HARDWARE Tiny InterNet Interface (TINI) es una pla-taforma desarrollada por Dallas Semiconductor que proporciona un medio simple, flexible y económico para diseñar una extensa variedad de dispositivos hardware, capaces de conectarse a re-des corporativas y locales [1].

PROYECTOS

TELEMETRÍA DE SIGNOS VITALES PARA CONTROL DE LA SALUD

Alberto Bravo, Juan Carlos Macas Universidad Técnica Particular de Loja

Escuela de Electrónica y Telecomunicaciones [email protected] / [email protected]

Loja, Ecuador.

PR

OY

EC

TO

FIN

DE

CA

RR

ER

A

26

Página 26

La características de la plataforma son expuestas al desarrollador de software a través de un set de interfaces de programación de aplicacio-nes (APIS)2 [2] en JAVA, brindando un poderoso entorno de programación orientado a objetos y facultando al programador en la creación de apli-caciones utilizando la potencia y bondades que ofrece el lenguaje JAVA [3].

API: (Interfaz de programación de Aplicaciones) es el conjunto de funciones y procedimientos (o métodos si se refiere a programación orientada a objetos) que ofrece cierta librería para ser utilizado por otro soft-

ware como una capa de abstracción FUNCIONAMIENTO DEL SISTEMA La aplicación desarrollada permitirá un control y configuración vía web y realiza la con-versión de protocolos RS-232 a Ethernet. El software de implementación esta for-mado por 3 etapas que son: a) Etapa de Monitoreo.- formado por software que viene con el sensor Oximétrico a usar y es de uso exclusivo del medico donde se visualizarán las constantes vitales del paciente. b) Etapa de Conversión y almacenamiento.- for-mado por el modulo TINI donde se realizará la conversión serial a Ethernet así como el almacena-mientos de los datos enviados por el sensor. c) Etapa de Adquisición.- formado por el sensor oximétrico el cual se encargara de adquirir los da-tos y enviarlos a la etapa de conversión y almace-namiento de la información. El sistema de conversión de protocolos esta compuesto de un servidor y un cliente los mismos que se detallan a continuación: Cliente.- en el cual se obtendrán y visualizarán los datos en este caso será un PC donde el médico

podrá acceder a través e la interfaz SPO2 y dis-pondrá del software de control y monitorización del dispositivo serie a conectar al sistema (sensor oximétrico). Servidor.- en el cual se conectará el sensor oximé-trico a monitorizar y además se encargara de reali-zar la conversión de datos RS-232 a Ethernet. Además el modulo TINI serán configurado para que trabaje como un servidor para que cualquier momento se pueda acceder al mismo. DIAGRAMA DE FLUJO

PROYECTOS

PR

OY

EC

TO

FIN

DE

CA

RR

ER

A

27

Página 27 INFORME IEEE

CONCLUSIONES Y RECOMENDACIONES El resultado del proyecto puede conside-rarse globalmente como de muy satisfactorio, pu-diendo esta conclusión de tipo general ser detalla-da y matizada en los siguientes apartados: • Se ha desarrollado un producto de conversión

de protocolos serie a Ethernet bastante similar a otros existentes en el mercado.

• En la construcción del conversor, la mayor parte del tiempo (aproximadamente un 80% del total), se emplea en la comprensión, estruc-turación, especificación formal y pruebas de cada uno de los protocolos originales.

• JAVA nos proporciona una herramienta de control de la aplicación vía Web. Esto permite a cualquier usuario sin conocimientos de siste-mas operativos ni de aplicaciones de conexión remota a hacer funcionar la aplicación de ma-nera muy intuitiva.

• En cuanto a los sistemas de información hospi-talarios, debe considerarse el desarrollo de sis-temas de bases de datos accesibles remotamen-te, esto permitirá a los médicos el fácil acceso a los datos para su posterior análisis.

REFERENCIAS BIBLIOGRÁFICAS [1] LOOMIS, Don. The TINI Specification and Developer‘s Guide. Addison-Wesley, 2001. [2] http://www.rxtx.org [3] http://java.sun.com

PR

OY

EC

TO

FIN

DE

CA

RR

ER

A

28

Página 28 PROYECTOS

SE CUMPLIÓ CON ÉXITO EL I STUDENT ETHICS COMPETITION DE SECCIÓN ECUADOR Y REGIÓN 9

La Rama Estudiantil IEEE-UTPL desarrolló este 11 de Enero la I Competencia Estudiantil de Éti-ca, a la cual se dieron cita la mayoría de ramas estudiantiles de la Sección Ecuador. Este evento pretendía, entre otras cosas, lo siguiente: - Fomentar la familiaridad con el código de IEEE de ética y de conceptos éticos, en las ramas estudiantiles

de la Sección Ecuador. - Promover un mejor ejercicio profesional a través del ejercicio ético y moral. - Promover un modelo para discutir y analizar preguntas éticas entre profesionales y estudiantes, y, - Proporcionar experiencia en la aplicación de conceptos éticos a las situaciones profesionales típicas. Este evento se realizó en el auditorio Virginia Riofrío en dos jornadas, puesto que la cantidad de equipos participantes demandó hacerlo de este modo. Fueron 12 los equipos participantes, de las diferentes universidades y Ramas Estudiantiles del Ecuador, los que en un marco de camaradería y respeto, intervi-nieron uno a uno, proponiendo sus soluciones al caso de estudio propuesto, y que había sido enviado por el Comité de Ética y Conducta (EMCC, Ethics & Member Conduct Committee) para los organizadores. El Jurado calificador estuvo conformado por importantes personalidades de diferentes institucio-nes así como de la Sección Ecuador. Finalmente, luego de que intervinieron todos los equipos participan-tes, el jurado dio su veredicto declarando como triunfadores del primero y segundo lugar a los equipos de la Rama Estudiantil IEEE-ESPOCH, (Escuela Superior Politécnica del Chimborazo) de la ciudad de Rio-bamba, para los cuales los premios fueron de USD 600 y USD 400, respectivamente. Los integrantes de estos grupos fueron: Kléver López, Patricio Granda, Enrique Piguave, Marco Oto, Vinicio Macas y Byron López.

Foto del Evento Cabe destacar que los premios son para actividades futuras de la Rama Estudiantil, y no para los miembros de los equipos. Como organizadores felicitamos a ésta y todas las ramas participantes, por el trabajo desempeñado y el esfuerzo grupal; y esperamos que éste sea el primer paso para que eventos como éstos se realicen en nuestra Sección y Región. Pues el proceder ético de un profesional, hará que las metas en materia de ciencia y tecnología sean alcanzadas en menor tiempo.

INFORME DE ACTIVIDADES IEEE

RIN

CÓ

N IE

EE

29

Página 29

PROYECTO FUTUROS INGENIEROS El grupo de robótica de la Escuela de Electrónica y Telecomunicaciones llevó a cabo este 12 de enero la finalización del proyecto denominado “Futuros Ingenieros”, que en su primera etapa llegó a su término con la clausura realizada este viernes 18 del presente mes y año en las instalaciones de la Universi-dad. Lo que se pretende con este proyecto es formar futuros ingenieros, aficionados a la programación electrónica, desde temprana edad.

Momentos en los cuales un futuro ingeniero realizaba la demostración

El proyecto inició en la Escuela Miguel Riofrío, con los alumnos de los quintos, sextos y séptimos años de educación básica de la escuela.

Los futuros ingenieros luego de recibir sus certificados

Con la realización de un concurso de manualidades interno entre alumnos, los promotores del evento calificaron creatividad, inventiva y originalidad de los niños para desarrollar maquetas de robots prototipo, la acogida de participantes fue tal que se presentaron más de 200 ejemplares al concurso. El apoyo del director de la Escuela Miguel Riofrío en primera instancia fue importante porque a ello se sumaron los padres de familia y los mismos niños que participaron con mucho entusiasmo, y lo que presentaron finalmente fueron dos robots armados por ellos mismos, el uno es un escorpión que abre sus tenazas para atacar al enemigo, el otro un robot que pide música para bailar. Los niños muy deseosos de adquirir más conocimientos aprendieron muy rápido esto se evidenció en la respuesta de los chicos, que a la segunda semana ya podían programar. La segunda parte del proyecto se complementará eligiendo a las siguientes escuelas con las que se continuará el trabajo.

INFORME IEEE

INFORME DE ACTIVIDADES IEEE

RIN

CÓ

N IE

EE

30

Página 30

MATERIA DE LIBRE CONFIGURACION PARA EL PROXIMO SEMES-TRE

Para este nuevo semestre que se nos aproxima en nuestra escuela se pone a consideración las si-guientes materias de libre configuración, en el marco del sistema de créditos académicos, con lo cual po-demos compartir destrezas con otros compañeros de otras carreras; a continuación ponemos los datos bási-cos de estas materias HOLOGRAFÍA DATOS BÁSICOS DE LA MATERIA

Área Académica: Técnica Escuela: Electrónica y Telecomunicaciones Nombre de la Asignatura: Holografía Semestre en el que se imparte: Marzo-Agosto/2008 Tipo de materia: Libre configuración Número de créditos UTPL - ECTS: 3 Créditos Horario de clases presenciales: Paralelo A: Lunes a Viernes 19H00-21H00

ROBÓTICA DATOS BÁSICOS DE LA MATERIA

Área Académica: Técnica Escuela: Electrónica y Telecomunicaciones Nombre de la Asignatura: Robótica Semestre en el que se imparte: Marzo-Agosto/2008 Tipo de materia: Libre configuración Número de créditos UTPL - ECTS: 3 Créditos Horario de clases presenciales: Paralelo A: Lunes a Viernes 19H00-21H00

COMPETENCIAS A DESARROLLAR

Habilidades interpersonales

Habilidad para trabajar en forma autónoma

Capacidad para formular, diseñar y gestionar proyectos

Compromiso con la calidad

Habilidades en el uso de las tecnologías de la TIC´s

Habilidad para trabajar en contextos internacionales

Responsabilidad social y compromiso ciudadano

Compromiso ético

Motivación del logro

EN NUESTRA ESCUELA

EN LA ESCUELA DE ELECTRÓNI-

EX

TR

AS

Escuela de Electrónica y Tele-comunicaciones

31

Página 31

INFORME SOBRE PASANTÍAS EN PACIFICTEL

El día 11 de Enero del presente año se llevó a cabo la firma del convenio entre la Escuela de Electrónica y Telecomunicaciones y la Empresa Estatal de Telecomunicaciones PACIFICTEL S.A. Sucursal Loja, con el fin de que los profesionales en formación amplíen sus conocimientos y puedan tener una experiencia laboral real en el periodo Enero-Marzo/2008. Luego de concluido el período de evaluación de postulaciones, fueron seleccionados para realizar la pa-santía en dicha empresa los siguientes profesionales en formación: ESTUDIANTES ÁMBITO Juan Iván Cueva Proyectos de telecomunicaciones Pablo Vallejo Proyectos de telecomunicaciones Pablo Rojas Actividades en repartidor Sergio Jaramillo Actividades en repartidor Diego Barragán Centrales de conmutación

Momentos luego de los cuales se llevó a cabo la firma del convenio entre los directivos de Pacifictel S. A. Su-

cursal Loja y los docentes responsables de la universidad El inicio de dichas pasantía fue el 14 de Enero del presente año y se están llevando a cabo de acuerdo a los siguientes parámetros: 1. Responsable académico UTPL: Ing. Patricia Ludeña González 2. Responsable técnico PACIFICTEL: Ing. Pablo Toapanta Silverio

EN NUESTRA ESCUELA

EN LA ESCUELA DE ELECTRÓNICA

EX

TR

AS

32

Página 32

4. Período de ejecución: Enero 2008 - Marzo 2008 Valoración total en horas de trabajo 240h - 210h 5. Número de créditos:

Quince (15) créditos, previa presentación bitácora de trabajo e informe de los responsables.

6. Período de asignación de créditos: Marzo-Agosto 2008 7. Horario de trabajo:

Mañana o tarde, 4 horas, durante toda la semana, a excepción del área de medios de acceso donde se deberán cubrir horarios de 8h00 a 13h00, y, 14h00 a 17h00.

8. Áreas de ejecución:

EN NUESTRA ESCUELA


EX

TR

AS

33

Página 33

MOMENTOS GRATOS EN LA ESCUELA

EN NUESTRA ESCUELA


EX

TR

AS

Gincana en Vilcabanba

Camaradería, alegría y algo mas entre docen-tes-estudiantes (salud Muchachos)

www.utpl.edu.ec/eet

Av. Marcelino Champagnat Telf.:(593-7)2570275, ext: 2656

Fax: (593-7)2585978 Ap.: 11-01-608 Loja—Ecuador

GRUPO DE ELECTRICI-DAD Y SISTEMAS ELECTRÓNICOS

LABORATORIO DE FÍSICA

SISTEMAS DE INFORMA-CIÓN GEOGRÁFICA

GRUPO DE RADIOCOMUNICA-

CIONES

en corto circuito(15)febrero2008

Technology