UNIVERSIDADE ESTADUAL PAULISTA JLIO DE MESQUITA FILHO CAMPUS DE ILHA SOLTEIRA DEPARTAMENTO DE ENGENHARIA ELTRICA

Manipulao Remota de um Brao Mecnico (SCORBOT ER - III) utilizando a Rede Mundial de Computadores

Marcos Antonio Estremote

Dissertao submetida Universidade Estadual Paulista UNESP, Campus de Ilha Solteira, para preenchimento dos requisitos necessrios para obteno do ttulo de Mestre em Engenharia Eltrica.

Orientador: Prof. Dr. Nobuo Oki

ILHA SOLTEIRA - SP, JANEIRO DE 2006

Manipulao Remota de um Brao Mecnico (SCORBOT ER - III) utilizando a Rede Mundial de Computadores

MARCOS ANTONIO ESTREMOTE

DISSERTAO SUBMETIDA UNIVERSIDADE ESTADUAL PAULISTA UNESP, CAMPUS DE ILHA SOLTEIRA, PARA PREENCHIMENTO DOS REQUISITOS NECESSRIOS PARA OBTENO DO TTULO DE MESTRE EM ENGENHARIA ELTRICA.

COMISSO EXAMINADORA: Prof. Dr. NOBUO OKI DEPARTAMENTO DE ENGENHARIA ELTRICA FE UNESP CAMPUS DE ILHA SOLTEIRA /SP Prof. Dr. ALEXANDRE CESAR RODRIGUES DA SILVA DEPARTAMENTO DE ENGENHARIA ELTRICA FE UNESP CAMPUS DE ILHA SOLTEIRA /SP Prof. Dr. JOS RAIMUNDO DE OLIVEIRA DEPARTAMENTO DE ENGENHARIA DE COMPUTAO INDUSTRIAL FEEC UNICAMP CAMPINAS/SP E AUTOMAO

ILHA SOLTEIRA - SP, JANEIRO DE 2006

 minha famlia, sobretudo meus pais: Lenir Almeida Estremote Joo Antonio Estremote "In Memorian", pela educao pautada, pela honestidade e trabalho, meu profundo reconhecimento e considerao.

s minhas filhas Izabella Prato Estremote e Maria Eduarda Prato Estremote e milha esposa Elaine Prato Estremote, pontos de luz, que a cada dia me fortalece e edifica para a conquista dos meus sonhos.

Ofereo! "Porque ficar de braos cruzados se o maior homem do mundo morreu de braos abertos. Pois vitorioso no aquele que vence o outro, mas sim a si mesmo.

AGRADECIMENTOS
A minha gratido, primeira e principalmente, a Deus, forte rochedo em que me abrigo autor e guia de nossas vidas, por tanto amor e tanto cuidado a mim dispensados. Agradeo a meus pais, minha esposa, aos meus irmos (Mrio Mrcio Estremote e Marcelo Estremote) e familiares, que sempre lutaram por seus ideais me ensinando, com isso, a persistir na caminhada, por mais rdua que ela seja. Ao professor Doutor Nobuo Oki, que com sua competncia e habilidade, unido sua receptividade, amizade e confiana se fez presente em toda esta caminhada. Aos amigos Edilson Souza dos Santos, Vincius de Arajo Maeda, Horncio Serrou Camy Filho, Odacir de Almeida Neves, Trcio Alberto dos Santos Filho e Cristiano Pires Martins que os considero um exemplo a ser seguido tanto no campo profissional como pessoal. A todos os colegas de trabalho que direta ou indiretamente, cooperaram para a realizao deste trabalho. "O importante no estar aqui ou ali, mas ser, e ser uma cincia delicada feita de pequenas e grandes observaes do cotidiano, seno executarmos essas observaes no chegamos a ser, apenas estamos e desaparecemos".

EPGRAFE

A ARTE DE VIVER UMA TTICA EM QUE POR MUITO TEMPO TEREMOS DE SER APRENDIZES.

vi

RESUMO

Neste trabalho descreve-se um Software de comando para o acionamento de um brao mecnico do rob SCORBOT ER - III. O software desenvolvido tem a capacidade de controlar e monitorar o rob remotamente em tempo real atravs da Rede Mundial de Computadores (WWW), utilizando bibliotecas de JAVA como: mtodos nativos (JNI - JAVA Native Interface), Invocao de Mtodos Remotos (RMI Remote Method Invocation), Conectividade com Banco de Dados JAVA (JDBC JAVA Database Connecvity) e JMF (JAVA Media Frameworks) com o Protocolo de Tempo Real RTP (Real Time Protocol). Para controle do rob, o circuito de controle originalmente desenvolvido pelo fabricante, foi reprojetado utilizando-se o ambiente Max+Plus II da Altera e a conexo entre Rob e o PC feita atravs de um dispositivo lgico programvel tipo FPGA, que recebe os comandos provenientes da Porta Paralela do PC, o monitoramento atravs de cmeras digitais do tipo WEBCAM conectadas em uma Porta do tipo USB.

Palavras-chave: Controle Remoto, Rob SCORBOT ER III, Linguagem JAVA, Tempo Real.

vii

ABSTRACT

This work describes the development of a Software for the control of a mechanical arm type SCORBOT ER - III. This software has the capacity to control and to monitor the robot remotely in real time through the World Wide Web (WWW), using libraries of JAVA as: native methods (JNI-JAVA Native Interface), Invocation of Remote Methods (RMI - Remote Method Invocation), Connecvity with database JAVA (JDBC - JAVA Database Connecvity) and JMF (JAVA Media Frameworks) with the Protocol of Real Time - RTP (Real Time Protocol). The robot control circuit was redesigned using the Altera Max+Plus II environment and the connection between the robot and personal computer was made by the Parallel Port and digital cameras of the type WEBCAM, connected USB port.

Keywords: Remote control, Robot SCORBOT III - ER, Language JAVA, Real Time.

viii

LISTA DE FIGURAS
Figura 2.1: Brao Mecnico SCORBOT ER III .................................................................... 10 Figura 2.2: Foto do brao onde se pode visualizar a esteira e sua base deslizante pertencentes ao rob .................................................................................................................... 11 Figura 2.3: Junta e vnculos em um brao de rob ................................................................... 11 Figura 2.4: Junta de rotao...................................................................................................... 13 Figura 2.5: Rob com Articulao Vertical ............................................................................. 14 Figura 2.6: Garra de movimento paralelo................................................................................. 15 Figura 2.7: Garra do SCORBOT ER - III................................................................................. 15 Figura 2.8: Diagrama de blocos do CI L298. ........................................................................... 19 Figura 2.9: Pinagem do CI L298. ............................................................................................. 19 Figura 2.10: Circuito de potncia utilizado (a) ......................................................................... 20 Figura 2.11: Circuito de potncia utilizado (b)......................................................................... 20 Figura 2.12: Kit da Altera utilizado nos testes. ........................................................................ 21 Figura 2.13: Pinagem final do CI EMP7032 fornecida pelo Max+Plus II Profissional. .......... 22 Figura 3.1: Representao de objeto......................................................................................... 33 Figura 3.2: SuperClasses e Subclasses ..................................................................................... 37 Figura 4.1: Layout do Aplicativo Cliente ................................................................................. 41 Figura 4.2: Layout do Aplicativo Servidor............................................................................... 41 Figura 4.3: Layout do formulrio de cadastro para o movimento do motor............................. 42 Figura 4.4: Caixa de dilogo para inserir um motor do banco de dados. ................................ 43 Figura 4.5: Caixa de dilogo para fornecer o deslocamento do rob. ...................................... 43 Figura 4.6: Caixa de dilogo para remover s coordenadas de um motor do banco de dados. 43 Figura 4.7: Layout do formulrio sobre o sistema. ................................................................... 44 Figura 4.8: Chamando um objeto remoto em um objeto servidor ............................................ 49 Figura 4.9: Diagrama da Arquitetura RMI. .............................................................................. 54 Figura 4.10: Arquitetura RTP ................................................................................................... 59 Figura 4.11: Transmisso RTP ................................................................................................. 64 Figura 4.12: Recepo RTP ...................................................................................................... 64

ix

Figura 5.1 Representao de uma classe usando UML ......................................................... 67 Figura 5.2: Diagrama da Classe ServidorRMIServer e recursos usados da API JAVA. .......... 70 Figura 5.3: Diagrama da Classe ServidorRMI e recursos usados da API JAVA ..................... 71 Figura 5.4: Diagrama da Classe InterfaceRMI e recursos usados da API JAVA ..................... 72 Figura 5.5: Diagrama da Classe ControlaMotores e recursos usados da API JAVA .............. 73 Figura 5.6: Diagrama da Classe SwingCapture e recursos usados da API JAVA ................... 73 Figura 5.7: Diagrama de Classe Clone e recursos usados da API JAVA ................................. 75 Figura 5.8: Diagrama de Classe TransmiteVideo e recursos usados da API JAVA ................ 76 Figura 5.9: Diagrama completo do Aplicativo Servidor. ......................................................... 77 Figura 5.10: Diagrama de Classe AbrePrograma. ................................................................... 78 Figura 5.11: Diagrama de Classe ClasseProcesso. .................................................................. 78 Figura 5.12: Diagrama de Classe InterfaceRMI do aplicativo cliente. .................................... 80 Figura 5.13: Diagrama de Classe FormSobre........................................................................... 81 Figura 5.15: Diagrama de Classe Completo do Aplicativo Cliente ......................................... 83 Figura 6.1: Tempo mdio individual de ativao dos motores do brao mecnico LAN. .... 84 Figura 6.2: Tempo global para realizao da tarefa de Reset. .................................................. 85 Figura 6.3: Utilizao da Rede com Transmisso Vdea. ........................................................ 86 Figura 6.4: Utilizao da Rede com Transmisso RTP e RMI ................................................ 87 Figura 6.5: Tamanho dos pacotes TCP/RMI na comunicao cliente/servidor. ...................... 88 Figura 6.6: Direo dos Pacotes TCP/RMI .............................................................................. 89 Figura 6.7: Total de bytes transferidos na comunicao TCP/RMI. ........................................ 89 Figura 6.8: Tamanho dos Pacotes UDP. ................................................................................... 90 Figura 6.9: Fluxo de Pacotes na rede........................................................................................ 91 Figura 6.10: Fluxo de bytes na rede. ........................................................................................ 91

LISTA DE TABELAS

Tabela 1: Implementao da classe ControlaMotores.java. .................................................... 46 Tabela 2: Arquivo de Cabealho ControlaMotores.h .............................................................. 47 Tabela 3: Assinaturas criadas pelo arquivo de cabealho. ....................................................... 47 Tabela 4: Implementao da classe InterfaceRMI.java ............................................................ 50 Tabela 5: Implementao da Classe ServidorRMI.java............................................................ 52 Tabela 6: Definio do Objeto e do Nome do Servio ............................................................. 55 Tabela 7: Definio do nome do servidor e o nome do objeto ................................................. 55 Tabela 8: Implementao da classe ServidorRMIServer.java .................................................. 55 Tabela 9: Variveis de Caminho, Usurio e Senha .................................................................. 57 Tabela 10: Conexo com o banco de dados ............................................................................. 57 Tabela 11: Cdigo fonte do arquivo SwingCapture.java ......................................................... 61 Tabela 12: Funo createProcessor ......................................................................................... 62 Tabela 13: Funo createTransmitter ...................................................................................... 63

xi

LISTA DE ABREVIATURAS E SIGLAS

Application Programming Interfaces (Interfaces de Programao de API CGI CI DEE DLL FEIS Aplicativos) Common Gateway Interface (Interface de Gateway Comum) Circuito Integrado Departamento de Engenharia Eltrica Dynamic Link Libraries (Bilbioteca Dinmica) Faculdade de Engenharia de Ilha Solteira Field Programmable Gate Arrays (Matriz de Portas Programveis em FPGA FTP HTTP Campo) File Transfer Protocol (Protocolo de Transferncia de Arquivos) HyperText Transfer Protocol (Protocolo de Transferncia de Hipertexto) Institute of Electrical and Electronics Engineers (Instituto de Engenheiros IEEE I/O Eltricos e Eletrnicos) Input/Output (Dispositivo de Entrada e Sada) JAVA Database Connectivity (Conectividade com Banco de Dados JDBC JIT JMF JNI JVM Kbps LAN Mbps PC JAVA) Just-in-Time (Tempo de Execuo) JAVA Media Frameworks JAVA Native Interface (Interface Nativa JAVA) JAVA Virtual Machine ( Mquina Virtual JAVA) Kilobits/segundo Local Area NetWork ( Rede de rea Local) Megabits/segundo Personal Computer (Computador Pessoal)

xii

RMI RTCP RTP SQL

Remote Methods Invocation (Invocao de Mtodos Remotos) Real Time Control Protocol (Protocolo de Controle de Tempo Real) Real Time Protocol (Protocolo de Tempo Real) Structured Query Language (Linguagem de Consulta Estruturada) Transmission Control Protocol/Internet Protocol (Protocolo de Controle

TCP/IP UDP UML URL USB

de Transmisso/Internet Protocol) User Protocol Datagram (Protocolo Datagrama de Usurio) Unified Modeling Language (Linguagem Unificada de Modelagem) Uniform Resource Location (Localizao de Recursos Uniformes) Universal Serial Bus (Barramento Serial Universal) Very High Speed Integrated Circuit Hardware Description Language (Linguagem de Descrio de Hardware para Circuitos Integrados de alta

VHDL WWW

velocidade) World Wide Web

xiii

SUMRIO
RESUMO ....... .................................................................................................................... vi ABSTRACT .... ................................................................................................................... vii LISTA DE FIGURAS ........................................................................................................ viii LISTA DE TABELAS .......................................................................................................... x LISTA DE ABREVIATURAS E SIGLAS ........................................................................... xi SUMRIO ...... .................................................................................................................. xiii

CAPTULO 1 INTRODUO ........................................................................................... 1

1.1 INTRODUO .......................................................................................................... 1 1.2 CONTEXTUALIZAO DO PROJETO ..................................................................... 2 1.2.1 OBJETIVOS DO TRABALHO ....................................................................... 2 1.2.2 MOTIVAO ................................................................................................ 4 1.2.3 JUSTIFICATIVA ............................................................................................. 5 1.3 ORGANIZAO DO TEXTO .................................................................................... 6

CAPTULO 2 - BRAO MECNICO SCORBOT ER - III ............................................ 7

2.1 INTRODUO ........................................................................................................... 7 2.2 ROBTICA E SUA HISTRIA.................................................................................... 7 2.3 CLASSIFICAO DOS ROBS ................................................................................... 8 2.4 SCORBOT ER - III ................................................................................................ 9 2.5 GRAUS DE LIBERDADE ......................................................................................... 12 2.6 FORMA DE ACIONAMENTO (DRIVER ELTRICO) ............................................. 12 2.7 CLASSIFICAO POR TIPO DE JUNTA (JUNTAS DE ROTAO) ........................ 13 2.8 ARTICULAO VERTICAL ..................................................................................... 13 2.9 ATUADOR DO SCORBOT ER - III ..................................................................... 14 2.10 CONTROLE DE TRAJETRIA .............................................................................. 16 2.11 MODIFICAES DE HARDWARE........................................................................ 17

xiv

2.11.1 CIRCUITO DE POTNCIA ................................................................................. 18 2.11.2 CIRCUITO DE CONTROLE ................................................................................ 20

CAPTULO 3 HISTRICO E CARACTERSTICAS DA LINGUAGEM JAVA ............ ..................................................................................................................... 24

3.1 HISTRICO.............................................................................................................. 24 3.2 CARACTERSTICAS .................................................................................................. 25 3.2.1 SIMPLES ........................................................................................................ 26 3.2.2 ORIENTADO A OBJETO .............................................................................. 26 3.2.3 DISTRIBUDO ............................................................................................... 26 3.2.4 ROBUSTO ...................................................................................................... 27 3.2.5 SEGURO ........................................................................................................ 27 3.2.6 - ARQUITETURA NEUTRA.............................................................................. 28 3.2.7 INTERPRETADO ........................................................................................... 29 3.2.8 ALTO DESEMPENHO .................................................................................. 29 3.2.9 MULTITHREADED ....................................................................................... 30 3.2.10 DINMICO ................................................................................................. 30 3.3 CONCEITOS DE ORIENTAO A OBJETOS ......................................................... 31 3.3.1 - CONCEITOS BSICOS ................................................................................... 32 3.3.1.1 OBJETOS ......................................................................................... 32 3.3.1.2 MENSAGENS .................................................................................. 34 3.3.1.3 CLASSES .......................................................................................... 34 3.3.2 CARACTERSTICAS DA TECNOLOGIA DE OBJETOS ................................ 35 3.3.2.1 ENCAPSULAO ............................................................................ 36 3.3.2.2 HERANA ...................................................................................... 37 3.3.2.3 POLIMORFISMO ............................................................................. 38

CAPTULO 4 - IMPLEMENTAO DO SOFTWARE DE CONTROLE .......................... 40

4.1 MTODOS NATIVOS .............................................................................................. 44

xv

4.1.1 IMPLEMENTAO DO MTODO NATIVO ................................................ 48 4.1.2 COMPILAO DA BIBLIOTECA .................................................................. 48 4.2 INVOCAO DE MTODOS REMOTOS ................................................................ 48 4.2.1 CHAMADAS DE OBJETOS REMOTOS ......................................................... 49 4.2.2 ESTABELECENDO CHAMADAS DE MTODOS REMOTOS ...................... 50 4.2.3 INTERFACES E IMPLEMENTAES (RMI) ................................................ 50 4.2.4 LOCALIZANDO OBJETOS SERVIDORES .................................................... 55 4.3 JDBC CONECTIVIDADE COM BANCO DE DADOS JAVA .............................. 56 4.4 - JMF (JAVA MEDIA FRAMEWORKS) ..................................................................... 57 4.4.1 - MEDIA STREAMING ..................................................................................... 58 4.4.2 - PROTOCOLOS DE MEDIA STREAMING...................................................... 58 4.4.3 - PROTOCOLO DE TRANSPORTE DE TEMPO REAL - RTP ......................... 59 4.4.4 - SERVIOS RTP ............................................................................................. 60 4.4.5 - ARQUITETURA DE RTP ............................................................................... 60 4.4.6 - APLICAES DE RTP .................................................................................. 61 4.4.7 - TRANSMISSO E RECEPO DE STREAMS RTP ....................................... 61

CAPTULO 5 MODELAGEM DO SOFTWARE DE CONTROLE.................................. 66

5.1 UML ........................................................................................................................ 66 5.2 DIAGRAMA DE CLASSE .......................................................................................... 67 5.3 DIAGRAMA DE OBJETOS ....................................................................................... 68 5.4 DIAGRAMA DE CASO DE USO .............................................................................. 68 5.5 DIAGRAMAS DE CLASSES DO APLICATIVO SERVIDOR ...................................... 69 5.6 DIAGRAMAS DE CLASSES DO APLICATIVO CLIENTE ........................................ 78

CAPTULO 6 TESTES DE COMUNICAO DO SOFTWARE ..................................... 84

6.1 TEMPO DE ATIVAO DOS MOTORES NA REDE ............................................... 84 6.2 TRFEGO DE PACOTES NA REDE ........................................................................ 85 6.3 ANLISE DOS PACOTES TCP/RMI COLETADOS NA REDE ............................. 88

xvi

6.4 ANLISE DOS PACOTES UDP/RTP COLETADOS NA REDE ............................ 90 6.5 ANLISE DO FLUXO DE PACOTES DOS PROTOCOLOS DE COMUNICAO ... 90 6.6 CONSIDERAES SOBRE O CAPTULO ................................................................ 92

CAPTULO 7 - CONSIDERAES FINAIS ........................................................... 93

REFERNCIAS BIBLIOGRFICAS .......................................................................................... 95

APTULO 1 INTRODUO

1.1 INTRODUO

Um dos tpicos fascinantes de engenharia a rea de robtica1. Os robs desempenham tarefas repetitivas e aquelas que colocariam os operrios em condies insalubres ou de risco, sendo seu uso fundamental nas atividades industriais, principalmente na indstria automobilstica onde preciso e qualidade so imprescindveis. Definem-se como robs, mquinas capazes de executar determinadas tarefas de forma programada. No projeto de desenvolvimento de robs esto envolvidos conhecimentos multidisciplinares, tais como: mecnica, eletrnica (analgica, digital e potncia), controle e entre outras. De acordo com a literatura [1], o primeiro trabalho envolvendo a manipulao remota de robs via World Wide Web2 (WWW) foi efetuado no Projeto denominado Mercrio coordenado por Ken Goldberg e Michel Mascha da University Southern Califrnia. Atualmente, existem diversos grupos trabalhando com este conceito com finalidades que variam desde a educacional, visando despertar o interesse de alunos para reas de computao, at o uso de sofisticadas teorias de controle, tais como redes neurais e tcnicas de identificao para orientao de robs em reas remotas (manuteno de satlites, por exemplo) ou de risco (rastreamento de bombas e minas, prospeco e montagem de equipamentos para extrao de petrleo em guas profundas). Por outro lado, o uso da rede mundial de computadores, cada vez mais popular, atinge um pblico bastante heterogneo, entre os quais, alunos que possam se interessar pela rea de tecnologia. O desenvolvimento de projetos, no qual se torna possvel interao de usurio com rob, grande oportunidade para despertar este interesse. A rede mundial de
1 2

o conjunto dos estudos e das tcnicas que permitem a utilizao de robs na automao. Rede Mundial de Computadores.

computadores possibilita, pela sua concepo, o acesso quase universal dos trabalhos desenvolvidos, pois a plataforma de uso encontra-se j definida e disponvel. Na rede, existe uma srie de pginas que efetuam este trabalho, no entanto o pas carece de iniciativas neste sentido. Na rea industrial os robs j fazem parte das plantas industriais onde os requisitos de alta produtividade e confiabilidade so necessrios. Para o pblico em geral, a rea de robtica desperta fascnio pela divulgao de recentes conquistas obtidas, tais como o envio de sondas tele-operadas a Marte, as aplicaes na indstria automobilstica, sua utilizao em brinquedos e mesmo sua utilizao em filmes de fico.

1.2 CONTEXTUALIZAO DO PROJETO

O projeto para o acionamento de um rob remotamente envolve a aplicao de diversas tcnicas e metodologias em relao ao interfaceamento e comunicao. O sistema original no disponibilizava condies de novas atualizaes devido a sua estrutura fechada, os circuitos de acionamento e controle tornaram-se obsoletos, alm do software de comando. Com isso, surgiu a necessidade de construir um novo hardware e software, flexvel e aberto.

1.2.1 OBJETIVOS DO TRABALHO

Neste trabalho descreve-se o desenvolvimento de um software portvel3 que permite o acionamento remoto de um rob, atravs da rede mundial de computadores como plataforma de controle. O sistema original de acionamento foi reestruturado e controlado atualmente por um microcomputador tipo PC utilizando a porta paralela para controle do brao. Os aspectos enfocados neste estudo so direcionados ao desenvolvimento de um software

Aplicaes capazes de serem executadas em uma variedade de sistemas operacionais e de arquiteturas de hardware.

responsvel pela manipulao do brao mecnico do SCORBOT ER-III via WWW, anlise e definio da linguagem JAVA utilizada no desenvolvimento, incluindo os protocolos de comunicao at a elaborao do ambiente de interface usurio-mquina. Em um trabalho existente [2] indicou-se a possibilidade de utilizao de linguagem JAVA para o acionamento e controle de dispositivos. Alm de ser uma linguagem de programao4, pode tambm ser utilizado como plataforma computacional5 [3], que apresenta vrias caractersticas tais como ser orientada a objetos, ser robusta, portvel e segura. Alguns ambientes necessrios para a elaborao deste trabalho esto descritos na literatura [4], [5] e [6]. A caracterstica de independncia de arquitetura do JAVA, o cdigo fonte, depois de compilado pode ser executado em muitos processadores, o grande motivo pelo quais seus programas so portveis. Outro aspecto da portabilidade envolve a estrutura ou os tipos de dados inerentes da linguagem, como inteiro, string e ponto flutuante. JAVA tira proveito dos padres IEEE para os tipos de dados comuns em vrias arquiteturas de computadores. Por exemplo, em JAVA uma estrutura de dados float sempre estar de acordo com o padro IEEE 754 para nmeros de ponto flutuante, enquanto o tipo de dado int ser sempre um inteiro de 32 bits com complemento de dois sinalizado. Alm disso, resolve questes relacionadas com dependncias de ordem de bytes de hardware com terminaes big endian6 e little endian7. Estes aspectos o diferem de outras linguagens, como o C++, uma vez que, o binrio de cdigo de bytes no possui dependncia de implementao, portanto portvel para vrias plataformas diferentes. com base nestes conceitos que optou-

Conjunto de instrues e regras de composio e encadeamento, por meio do qual se expressam aes executveis por um computador, seja diretamente, seja por meio de processos de compilao, interpretao ou montagem. 5 Arquitetura ou padro de um tipo de computador, ou de sistema operacional. 6 O nmero hexadecimal A02B seria armazenado como A02B pelo mtodo big endian. O mtodo big endian utilizado pelos microprocessadores Motorola. 7 O nmero hexadecimal A02B seria armazenado como 2BA0 pelo mtodo little endian. Os microprocessadores Intel fazem uso do mtodo little endian.

se em utilizar JAVA para o desenvolvimento do software de controle na manipulao do brao mecnico, tornando o aplicativo final disponvel para diversas plataformas.

1.2.2 MOTIVAO
A utilizao de robs na automao industrial e em locais de difcil acesso por seres humanos ou em situaes de alto risco cresce rapidamente em mbito mundial. Da mesma forma, provavelmente a explorao espacial tambm depender durante longo tempo de robs, capazes de atuar de modo satisfatrio em ambientes desconhecidos de outros planetas. Os pases que no dominarem o ciclo de projeto, construo e operao de robs autnomos estaro comprometendo fortemente sua capacidade de competio em um mercado globalizado, uma vez que, tais equipamentos j so considerados essenciais em vrios tipos de atividades industriais. Na indstria automobilstica, por exemplo, utilizam de forma rotineira robs de soldagem, com os quais possvel a construo de complexas estruturas dos modernos automveis com baixo custo e altssima qualidade.

Robs autnomos demandam um conjunto de tecnologias, com a participao de diversas especialidades. Um rob autnomo deve ser dotado de viso computacional e/ou sensores, capazes de posicion-lo em um ambiente desconhecido, associado a um programa de controle capaz de atuar em situaes de conflito. Adicionando-se o requisito de ao cooperativa entre mquinas inteligentes, leva-se ainda necessidade de se programar sistemas de comunicao entre os robs e a diviso de tarefas.

O estudo da robtica autnoma multi-agente tem sido realizada com baixa intensidade no Brasil. Entre os fatores limitantes na atuao dos pesquisadores, destaca-se, o alto custo de montagem de um laboratrio de robtica. Por exemplo, para adquirir e manter um rob utilizado em atividades de pesquisa em diversos pases necessrio um grande investimento, tornando difcil tal aquisio no contexto nacional.

Por outro lado, os jovens estudantes, ao fazerem sua escolha de um curso universitrio, parece se afastarem cada vez mais das carreiras tecnolgicas. Em parte trata-se de uma inclinao natural individual, mas tambm evidente que muitos jovens vem na aridez da Matemtica e da Fsica ensinada nos colgios um fator desmotivador para optarem por cursos superiores de Engenharia, Fsica, Matemtica e outras cincias consideradas difceis. Na verdade o que ocorre um desconhecimento total da aplicabilidade prtica dos conceitos tericos da Fsica e da Matemtica s situaes cotidianas, como se existisse a teoria dissociada do mundo real. Para reverter esse processo, preciso mostrar aos jovens que as frmulas e equaes, descrevem fenmenos fsicos reais, como a trajetria de um brao mecnico. Ou seja, a proposio deste trabalho, nada mais , do que uma aplicao prtica e real, de ferramentas fsicas, matemticas e computacionais avanadas.

1.2.3 JUSTIFICATIVA
O Departamento de Engenharia Eltrica (DEE FEIS UNESP) obteve o emprstimo de um brao mecnico SCORBOT ER - III de cinco graus de liberdade, junto ao Departamento de Engenharia Civil da mesma Instituio. No entanto, os circuitos de acionamento, controle e o software de controle tornaram-se desatualizados, passando por mais de quinze anos sem atualizao devido a sua estrutura fechada tipo caixa preta. Assim, fez se necessrio a construo de um novo sistema aberto de hardware (circuito de controle) e software foi de essencial importncia para que se possa atualiz-los constantemente. O circuito de controle do SCORBOT ER - III foi desenvolvido por um aluno de graduao da Faculdade de Engenharia de Ilha Solteira em seu Trabalho de Concluso de Curso [7]. Com a utilizao da Linguagem JAVA para a implementao do software de controle, o brao pode ser controlado atravs da Internet por uma aplicao cliente/servidor, fazer a interligao (link) entre o campus de Bauru, Guaratinguet e Ilha Solteira.

1.3 ORGANIZAO DO TEXTO

No segundo captulo conceituado o rob que serviu de base para a criao do software de manipulao. A linguagem de programao JAVA como ferramenta de programao, apresentada no terceiro captulo. No quarto, feita a descrio da implementao do software de controle para a manipulao do brao utilizando a linguagem proposta. No quinto captulo so mostrados os diagramas de classes do software de controle desenvolvido. No sexto captulo, so apresentados os testes de comunicao do software e por fim, no stimo captulo so relatadas as concluses do trabalho.

APTULO 2 - BRAO MECNICO SCORBOT ER - III

Neste captulo destacam-se as definies de robtica, abordando sua histria e por fim as caractersticas do rob estudado neste projeto de Mestrado.

2.1 INTRODUO
Atualmente torna-se cada vez mais necessrio a realizao de tarefas com eficincia e preciso. Alm disto, existem atividades a serem realizadas em lugares onde a presena humana torna-se difcil, arriscadas e at mesmo impossveis, como o fundo do mar ou a imensido do espao, ou mesmo locais na indstria onde o risco de acidentes com perda dos membros muito alto. Para realizar essas tarefas, se faz necessria presena de dispositivos robticos, que as realizem, sem colocar em risco a vida do homem. A Robtica uma cincia multidisciplinar, altamente ativa, que busca o desenvolvimento e a integrao de tcnicas e algoritmos para a criao de robs. Esta cincia envolve reas como engenharia mecnica, engenharia eltrica, inteligncia artificial, design, entre outras, com perfeita harmonia.

2.2 ROBTICA E SUA HISTRIA

A terminologia rob origina-se da palavra tcheca robotnik, ao qual tem o significado de servo, este termo foi idealizado primeiramente por Karel Capek em 1923, nesta poca a idia de um "homem mecnico" parecia vir de alguma obra de fico [8]. O desejo de se idealizar os robs no pertence apenas ao homem moderno, existem alguns acontecimentos histricos que j apontavam para esta idia, por exemplo, as diversas referncias sobre o "Homem Mecnico" construdo por relojoeiros com a finalidade de se

exibir em feiras; as "Animaes Mecnicas" como o leo animado de Leonardo da Vinci, e seus esforos para fazer mquinas que reproduzissem o vo das aves [8]. Contudo, certamente estes dispositivos eram muito limitados, pois no podiam realizar mais do que uma tarefa, ou um nmero reduzido delas. A grande evoluo do desenvolvimento da robtica foi no incio do sculo XX, quando houve uma grande necessidade do aumento na produtividade, porm sem perder a qualidade dos produtos. Foi nesta poca que o rob industrial encontrou suas primeiras aplicaes, sendo George Devol considerado o pai da robtica industrial [8]. Devido aos inmeros recursos que os hardwares e softwares oferecem e com o avano da inteligncia artificial, a robtica atravessa uma poca de contnuo crescimento que permitir, em um curto espao de tempo, o desenvolvimento de robs inteligentes.

2.3 CLASSIFICAO DOS ROBS

A classificao dos robs se d basicamente de acordo com as aplicaes e maneiras de executar as aes [9]: 1. Robs Inteligentes: estes robs so acionados por sistemas multifuncionais controlados por computador onde, so capazes de interagir com seu ambiente atravs de sensores e de tomar decises em tempo real. 2. Robs com controle por computador: j este tipo de rob, apesar de parecidos com os robs inteligentes, no possuem a capacidade de interagir com o ambiente. Quando estes robs so equipados com sensores e software adequado, passam a ser robs inteligentes. 3. Robs de aprendizagem: os robs de aprendizagem, apenas so capazes de repetir uma seqncia de movimentos, realizados por meio de um operador ou quando memorizados.

4. Manipuladores: os manipuladores so considerados sistemas mecnicos multifuncionais, onde o sistema de controle possibilita administrar o movimento de seus membros das seguintes formas: 4.1. manual: quando o operador controla diretamente os movimentos; 4.2. seqncia varivel: quando possvel alterar algumas das caractersticas do ciclo de trabalho. Quanto classificao dos robs em relao ao controle de seus movimentos, tm-se as seguintes configuraes: 1. Sem controle-servo: o controle de movimento em um rob sem controle-servo feito por um programa que controla o movimento dos diferentes componentes do rob, esta movimentao se realiza em um posicionamento ponto-a-ponto" no espao; 2. Com controle-servo: este tipo de controle permite duas formas de trabalho: 2.1. controle dos movimentos dos membros do rob em funo de seus eixos. Os movimentos podem ser realizados ponto-a-ponto ou com trajetria contnua; 2.2. os movimentos se estabelecem da respectiva posio de seus eixos de coordenada e da orientao da mo ferramenta do rob. Aps esta breve explanao com relao aos conceitos bsicos sobre robtica, observa-se no item seguinte as caractersticas do rob SCORBOT ER - III, os quais foram essenciais para o desenvolvimento deste projeto de pesquisa.

2.4 SCORBOT ER - III

Para o desenvolvimento e testes do software de controle, foi utilizado um brao mecnico educacional SCORBOT ER III, fabricado pela empresa ESHED ROBOTEC,

10

situada na cidade de Tel-Aviv - Israel, este rob est disponvel no Departamento de Engenharia Eltrica da Faculdade de Engenharia, Campus de Ilha Solteira UNESP. Este brao tem cinco graus de liberdade, controlado por oito motores de corrente contnua, possui juntas de rotao, caracterizando-o como um rob com articulao vertical. O mecanismo acionado por driver eltrico, atua com garra tipo dois dedos e seu comando feito ponto-aponto. O circuito de controle original do brao mecnico foi reestruturado para que pudesse haver a comunicao entre o rob e um computador pessoal. As figuras 2.1 e 2.2 mostram algumas fotos do brao mecnico SCORBOT ER - III.

Figura 2.1: Brao Mecnico SCORBOT ER III

11

Figura 2.2: Foto do brao onde se pode visualizar a esteira e sua base deslizante pertencentes ao rob

Os robs podem executar movimentos no espao, transferindo objetos e ferramentas de um ponto para outro, instrudo por um controlador e informando sua posio no espao atravs de sensores. Nas extremidades existem atuadores que realizam a execuo das tarefas. Todo rob pode ser composto de uma srie de vnculos e juntas, onde a junta conecta dois vnculos permitindo o movimento relativo entre eles, como mostra a figura 2.3. Em geral, robs possuem uma base fixa e o primeiro vnculo est preso a esta base. A mobilidade dos robs depende do nmero de vnculos e articulaes.

Figura 2.3: Junta e vnculos em um brao de rob

12

2.5 GRAUS DE LIBERDADE

O nmero de articulaes em um brao do rob tambm referenciado como grau de liberdade. Quando o movimento relativo ocorre em um nico eixo, a articulao possui um grau de liberdade e quando ocorrer em mais de um eixo, ter dois graus de liberdade. A maioria dos robs tem entre 4 a 6 graus de liberdade. J o homem, do ombro at o pulso, tem 7 graus de liberdade [7].

2.6 FORMA DE ACIONAMENTO (DRIVER ELTRICO)

O driver eltrico aciona motores eltricos que podem ser de corrente contnua, de passo ou corrente alternada. Muitos robs novos tm drivers para motor corrente contnua devido a sua boa preciso e simplicidade no controle do motor eltrico [7]. As vantagens do driver eltrico so: Eficincia calculada, controle preciso; Envolve uma estrutura simples e de fcil manuteno; No requer uma fonte de energia cara; Custo relativamente pequeno.

As desvantagens so: No pode manter um momento constante nas mudanas de velocidade de rotao; Sujeitos a danos para cargas pesadas, suficientes para parar o motor; Baixa razo de potncia de sada do motor e seu peso, necessitando um motor grande no brao.

13

2.7 CLASSIFICAO POR TIPO DE JUNTA (JUNTAS DE ROTAO)

Esta conexo permite movimentos de rotao entre dois vnculos. Os vnculos so unidos por uma dobradia comum, com uma parte podendo se mover num movimento cadenciado em relao outra, [7] como mostrado na figura 2.4. As juntas de rotao so utilizadas em muitas ferramentas e dispositivos, tais como tesouras, limpadores de pra-brisa e quebra-nozes [7].

Figura 2.4: Junta de rotao.

2.8 ARTICULAO VERTICAL

usual classificar os robs de acordo com o tipo de junta, ou mais exatamente, pelas trs juntas mais prximas da base do rob. Essa diviso em classes fornece informaes sobre caractersticas dos robs em vrias categorias importantes [7]; 1. Espao de trabalho; 2. Grau de rigidez; 3. Extenso de controle sobre o curso do movimento; 4. Aplicaes adequadas ou inadequadas para cada tipo de rob.

14

Os robs de articulao vertical caracterizam-se por possuir trs juntas de revoluo, como mostrado na figura 2.5.

Figura 2.5: Rob com Articulao Vertical

Sua rea de atuao maior que qualquer tipo de rob, tendo uma baixa rigidez mecnica. Seu controle , complicado e difcil, devido s trs juntas de revoluo e devido a variaes no momento de carga e de inrcia [7].

2.9 ATUADOR DO SCORBOT ER - III

O atuador (end effector) todo um sistema montado na extremidade do vnculo mais distante da base do rob, cuja tarefa agarrar objetos, ferramentas ou transferi-las de um lugar para outro. So exemplos de atuadores: a pistola de solda, garras e pulverizadores de tintas. A operao do atuador o objetivo final na operao de um rob, assim todos os demais sistemas (unidades drivers, controles, etc.) so projetados para habilitar sua operao. O atuador de extrema importncia na execuo de uma tarefa, portanto necessrio que o mesmo seja adequadamente projetado e adaptado as condies do seu meio e rea de

15

trabalho. Existem vrios tipos de atuadores, mas comentar-se- somente dos atuadores do tipo garra, pois , componente pertencente ao rob estudado em questo. Uma garra comparvel mo humana. No entanto, ela no capaz de simular seus movimentos, resultando na limitao dos movimentos a uma faixa de operaes. A grande demanda tem levado ao desenvolvimento de garras que podem manusear objetos de diferentes tamanhos, formas e materiais. O rob SCORBOT ER - III possui garra do tipo dois dedos. Essa garra o tipo mais comum e com grande variedade. So diferenciadas umas das outras pelo tamanho ou movimento dos dedos. Na figura 2.6 ilustra-se o movimento paralelo de uma garra de dois dedos e a figura 2.7 o atuador do rob SCORBOT ER - III. A principal desvantagem desta garra a limitao da abertura dos seus dedos restringindo a sua operao em objetos cujo tamanho no exceda esta abertura.

Figura 2.6: Garra de movimento paralelo.

Figura 2.7: Garra do SCORBOT ER - III

Diante destes fatos verifica-se que o desenvolvimento e produo de garras um estgio importante no projeto de robs para tarefas particulares. Normalmente, os fabricantes vendem robs sem o atuador. As garras e as ferramentas so escolhidas e adaptadas pela equipe de engenharia que instala o rob no local de trabalho.

16

2.10 CONTROLE DE TRAJETRIA

Cada tarefa executada por um rob pode ser considerada como uma srie de operaes, atravs da qual o atuador movido pelo brao do rob entre pontos prdeterminados e operado como programado. O controle de trajetria pode ser classificado em dois mtodos: ponto-a-ponto e contnuo [7]. O controle de trajetria ponto-a-ponto uma das caractersticas do SCORBOT. Antes da descrio do mtodo de controle ponto-a-ponto, definido alguns termos:

Ponto: localizao no espao em direo ou atravs do qual o atuador movido por uma operao do brao do rob;

Passo: uma parte do programa operacional do rob. A cada passo, o rob executa uma atividade;

Srie: uma coleo de passos que combinados formam o programa operacional do rob.

No controle ponto-a-ponto, define-se primeiramente, uma coleo de pontos para o rob. Em seguida, obtm-se a srie que armazenada na memria do controlador. Ao executar o programa, o brao do rob move-se por vrios pontos, de acordo com a ordem dos passos definidos na srie. Em cada passo o rob sabe seu destino, mas no conhece a trajetria que traar [7]. Robs com controle ponto-a-ponto so geralmente usados em sries onde o atuador no precisa realizar nenhuma funo no decorrer do movimento. Uma aplicao tpica a solda em ponto [7]. Uma grande maioria dos robs opera em controle ponto-a-ponto. J os robs de controle de trajetria contnua, podem realizar ciclos de movimento em que a trajetria seguida pelo rob controlada. Isso geralmente realizado fazendo com que

17

o rob se desloque atravs de uma srie de pontos pouco espaados em relao trajetria total que descrevem a trajetria desejada. Os pontos individuais so definidos pela unidade de controle e no pelo programador. O movimento linear uma forma comum de controle por trajetrias contnuas para robs industriais. O programador especifica o ponto de partida e o ponto final da trajetria, e a unidade de controle calcula a seqncia de pontos individuais que permitem ao rob seguir uma trajetria retilnea. Alguns robs tm a capacidade de seguir um caminho suave, curvo, que foi definido por um programador que movimenta manualmente o brao atravs do ciclo de movimento desejado. Atingir um controle por trajetrias contnuas precisas requer que a unidade controladora seja capaz de armazenar um grande nmero de localizaes de pontos individuais que definem a trajetria curva composta. Isso geralmente envolve o uso de um computador digital como controlador de rob. O controle por trajetrias contnuas requerido para certos tipos de aplicaes industriais, tais como pintura e soldagem a arco.

2.11 MODIFICAES DE HARDWARE

Para novas implementaes, o controle do brao mecnico foi substitudo por um circuito integrado programvel, o qual veio facilitar a comunicao entre o rob e um computador qualquer, atravs da porta paralela. O sistema como um todo pode ser dividido em trs partes:

O circuito de potncia tambm conhecido como driver; O circuito de controle que composto pelo FPGA8 (Field Programmable Gate Arrays);

O software desenvolvido em JAVA que comanda o circuito de controle.

Circuitos Reprogramveis.

18

Nos prximos itens, ser explanado um pouco mais sobre o circuito de potncia, o circuito de controle e o software de controle desenvolvido.

2.11.1 CIRCUITO DE POTNCIA

O circuito de potncia responsvel por gerar ganho de corrente necessrio para acionar todos os motores acoplados ao brao mecnico. Este circuito possui as seguintes especificaes:

Pode ser alimentado com tenses de at 46 V; Pode fornecer uma corrente total de 4A, sendo 1A por canal; Proteo contra superaquecimento; Todo o circuito pode acionar at oito motores, sendo que cada um no mximo de 1A de consumo;

Seu controle feito por nvel lgico (zero ou um); Foi montado com dissipadores de calor; A sua fonte de alimentao necessita de pelo menos 3A devido s correntes de recirculao apesar de o circuito ser protegido contra este tipo de corrente. O circuito composto por quatro microcontroladores L298, sendo que cada um possui

duas pontes completas de transistores bipolares. O diagrama de blocos e a pinagem deste circuito integrado so mostrados nas figuras 2.8 e 2.9 respectivamente.

19

Figura 2.8: Diagrama de blocos do CI L298.

Os pinos do CI da figura 2.9 denominados INPUT so provenientes do circuito ALTERA o qual responsvel pelo controle. Os pinos ENABLE e LOGIC SUPPLY VOLTAGE so ligados em 5 volts e os pinos CURRENT SENSING so aterrados.

Figura 2.9: Pinagem do CI L298.

O circuito foi montado e testado em laboratrio e mostrado nas figuras 2.10 e 2.11.

20

Figura 2.10: Circuito de potncia utilizado (a)

Figura 2.11: Circuito de potncia utilizado (b).

2.11.2 CIRCUITO DE CONTROLE

O circuito integrado foi simulado e implementado no componente MAX EPM7128SLC84-7 ou no componente FLEX EPF10K20RC240-7, disponvel no pacote de laboratrio do Projeto Universitrio da Altera. A linguagem VHDL9 (Very High Speed Integrated Circuit Hardware Description Language) foi utilizada para descrever o comportamento do circuito integrado.

Linguagem de Descrio de Hardware

21

O circuito de controle gera os sinais lgicos necessrios para o circuito de potncia acionar corretamente os motores, alm de multiplexar os sinais dos encoders, enviando-os para a porta paralela do computador. Os pinos D0 a D4 provenientes da porta paralela do computador so responsveis pela ativao dos motores por meio da seleo dos bits de cada sada atravs do circuito de controle. Uma vez obtido esses sinais, o circuito de controle determina qual dos motores ter o encoder ptico acionado. O CI foi programado utilizando a linguagem VHDL, a qual tornou esta etapa muito simples. A programao est inserida no apndice A. A figura 2.12 ilustra o Kit de programao da ALTERA.

Figura 2.12: Kit da Altera utilizado nos testes.

Na montagem final foi projetada uma placa de circuito impresso onde se utilizou o CI EPM7032LC44-12 tambm da ALTERA. Este circuito integrado possui 600 portas e at 36 pinos de I/O. Este circuito deve ser alimentado com 5 volts. O circuito de controle gera os sinais lgicos para o circuito de potncia para que os motores sejam acionados na ordem correta alm de realizar a multiplexagem dos sinais dos encoders para que possam ser enviados a porta paralela do computador.

22

O roteamento dos pinos do circuito integrado feito pelo Software Max+Plus II da ALTERA, como mostra a figura 2.13.

(Global Clear)

(Global OE)

(Global CLK)

(Global OE)

ent4

(Pdn)

ent2

ent3

6 encoder0 ent1 ent0 (GND) encoder7 encoder6 encoder1 encoder2 (VCC) encoder3 encoder4 7 8 9 10 11 12 13 14 15 16 17

44 43 42 41

(GND)

sada6

40

sada7

39 38 37 36 35 34 33 32 31 30 18 19
encoder5 pulsos

sada8 sada9 sada10 sada11 (vcc) sada12 sada13 sada14 sada15 (GND) sada5

20
(I/O)

21 22
(I/O) (GND)

23 24 25 26 27
sada0 sada3 sada2 sada4 (VCC)

29 28
sada1

Figura 2.13: Pinagem final do CI EMP7032 fornecida pelo Max+Plus II Profissional.

Os pinos E0 a E4 so provenientes da porta paralela do computador (D0 a D4). O pino PULSOS a sada j multiplexada dos sinais dos encoders, que vai para o pino INTERRUPT da porta paralela. Os pinos ENC0 a ENC7 so as entradas dos sinais dos encoders e os pinos S0 a S15 so as sadas para o circuito de controle.

2.11.3 SOFTWARE DE COMANDO

23

O Software de comando foi implementado utilizando a linguagem de programao JAVA, verso 1.4.2 da Sun Microsystems. responsvel pelo envio de bits de uma mquina cliente, utilizando a rede de computadores (WWW), para um servidor que est conectado ao circuito de controle determinando o funcionamento de um dos motores pertencentes ao rob, alm de receber streams de mdia do servidor, tendo como referncia seu endereo de IP. O programa computacional elaborado permite que os motores sejam acionados individualmente, fazendo com que o brao execute o deslocamento no espao. O acionamento de um motor via mquina cliente, faz com que este seja executado no servidor, atravs de trocas de mensagens na rede de computadores. Detalhes da comunicao e mtodos utilizados para este fim sero mostrados no captulo seguinte.

APTULO

3 HISTRICO E CARACTERSTICAS DA LINGUAGEM JAVA

Apresenta-se um breve relato histrico sobre a linguagem de programao JAVA. Posteriormente, definem-se as principais caractersticas, que motivaram a escolha desta linguagem para a elaborao do software de controle do brao mecnico.

3.1 HISTRICO
Cornell [10], afirma que a linguagem de programao JAVA surgiu da necessidade que a Sun Microsystems tinha, de criar um prottipo de um controle remoto que seria utilizado em aparelhos eletrnicos (eletrodomsticos). Surgiu ento, o projeto Green, que tinha por objetivo construir este prottipo. Os chips utilizados nestes controles no possuam muita potncia nem memria, e os fabricantes podiam escolher diferentes unidades centrais de processamento. Por isso, era preciso uma linguagem que gerasse um cdigo compacto o qual pudesse ser executado em vrias plataformas. Em 1991, James Gosling, programador da Sun, criou JAVA [10]. Em 1992, foi lanado o primeiro aparelho, porm, nenhum fabricante estava interessado em produzi-lo. Tentou-se utilizar o produto em um projeto de TV a cabo, e tambm no se conseguiu acertar nenhum contrato. Enquanto isso, a WWW crescia cada vez mais. Na poca, apenas um browser10 estava sendo utilizado, o Mosaic. Foi a que a Sun decidiu abandonar o hardware e adaptar o software a trabalhar com a Internet. Foi desenvolvido um browser utilizando as caractersticas do projeto Green como: arquitetura neutra, tempo real, confivel e seguro. Dessa forma nasceu o Hotjava, desenvolvido totalmente em JAVA para demonstrar o poder da linguagem.

10

Programa usado para navegar por pginas da Internet.

25

Esse browser tambm conseguia interpretar programas escritos em JAVA inseridos em uma pgina de hipertexto, as applets11. Em 1995, a Netscape lanou a verso 2.0 do seu browser (Netscape Navigator 2.0) compatvel com JAVA, o que favoreceu a divulgao da linguagem. Apesar de seu apelo ser mais forte na Internet, JAVA pode ser utilizada para construir aplicativos que rodam em arquiteturas diferentes desta, como cliente-servidor ou apenas stand-alone12 [10].

3.2 CARACTERSTICAS
JAVA uma nova linguagem de programao com elementos de C, C++ e outras linguagens com bibliotecas altamente voltadas para o ambiente da Internet. No uma linguagem de programao pequena, e aprend-la inteiramente requer certo esforo, porm para quem tem algum contato com C ou C++, ou programao orientada a objetos, se sentir mais vontade. Segundo a Sun Microsystems, JAVA foi estruturado para ser: Orientado a objetos, robusto, seguro, independente de arquitetura, alto desempenho, interpretvel, com linhas de execuo (threads13), dinmico e portvel, como j mencionado anteriormente [10] e [11]. Os autores da linguagem JAVA escreveram um Informe Oficial (White Paper) que explica os objetivos e realizaes do projeto. Este informe est organizado com base em onze termos, os quais so adjetivos que caracterizam a linguagem, atribudos segundo os motivos e problemas que se prope a resolver, os quais so relacionados a seguir.

11 12

Pequeno programa escrito na linguagem JAVA que vem embutido em pginas da web. So aplicativos completamente auto-suficientes, no necessitando de um segundo software para o seu funcionamento. Fluxo de controle seqencial isolado dentro de um programa. Permite que um programa simples possa executar vrias tarefas diferentes ao mesmo tempo, independentemente umas das outras.

13

26

3.2.1 SIMPLES
JAVA retirou de sua sintaxe algumas caractersticas presentes no C++, como arquivos de cabealho, aritmtica de ponteiros, estruturas, unies, entre outras. Algumas destas caractersticas so confusas e podem ocasionar problemas na execuo de um aplicativo, se o programador no tiver pleno conhecimento do que est fazendo, como, por exemplo, acessar uma poro de memria no destinada a ele.

3.2.2 ORIENTADO A OBJETO

A principal diferena entre JAVA e C++ no que diz respeito orientao a objeto, a herana mltipla, para qual JAVA apresenta uma melhor soluo. JAVA suporta herana, mas no herana mltipla. A ausncia de herana mltipla pode ser compensada pelo uso de herana e interfaces, onde uma classe herda o comportamento de sua superclasse alm de oferecer uma implementao para uma ou mais interfaces.

3.2.3 DISTRIBUDO
A linguagem possui bibliotecas completas de rotinas prontas para implementaes envolvendo protocolos baseados em TCP/IP14 (Transmission Control Protocol/Internet Protocol), como HTTP15 (HyperText Transfer Protocol) e FTP16 (File Transfer Protocol), permitindo abrir e acessar objetos na Internet atravs de URLs17 (Uniform Resource Location) como se estes estivessem na mquina local. Estas bibliotecas facilitam a conexo de computadores atravs da Internet ou de Intranets coorporativas, diferentemente da programao de rede em C ou C++.
14

Conjunto de padres da Internet que orienta o trfego de informaes e define o endereamento e o envio de dados. Para que dois computadores se comuniquem na Internet, preciso que ambos utilizem o TCP/IP. 15 Protocolo de comunicao que viabiliza as ligaes entre os clientes de WWW e os Web sites. 16 Protocolo para transferncia de arquivos. O FTP pode ser utilizado para copiar arquivos da rede para o computador do usurio e vice versa. 17 Padro de endereamento da Web. Permite que cada arquivo na Internet tenha um endereo prprio, que consiste de seu nome, diretrio, mquina onde est armazenado e protocolo pelo qual deve ser transmitido.

27

3.2.4 ROBUSTO
JAVA possibilita a escrita de programas que precisam ser confiveis de vrias formas. O compilador faz uma varredura antecipada de possveis problemas, realiza uma verificao dinmica (tempo de execuo) e elimina situaes sujeitas a erros, alm de possibilitar a criao de um software robusto, o que significa que o mesmo no "quebra" facilmente devido a erros de programao. Uma linguagem de programao que encoraja software robusto, geralmente, impe mais restries ao programador quando este est escrevendo o cdigo fonte. Estas restries incluem aquelas com relao aos tipos de dados e ao uso de ponteiros, eliminando, a possibilidade de sobrescrita de memria e conseqente destruio de dados. A presena de coleta automtica de lixo evita erros comuns que os programadores cometem quando so obrigados a gerenciar diretamente a memria (C, C++, Pascal). A eliminao do uso de ponteiros, em favor do uso de vetores, objetos e outras estruturas substitutivas trazem benefcios em termos de segurana. O programador proibido de acessar a memria que no pertence ao seu programa, alm de no ter chances de cometer erros comuns, tais como uso indevido de aritmtica de ponteiros. Os mecanismos de tratamento de excees tambm tornam as aplicaes mais robustas, no permitindo que elas abortem, mesmo quando rodando sob condies anormais.

3.2.5 SEGURO
Como o JAVA foi criado para ambientes de rede/distribudos, os recursos de segurana receberam muita ateno. Por exemplo, se for executado um binrio transferido por download da rede, o mesmo poder estar infectado por vrus. Os aplicativos do JAVA apresentam garantia de resistncia contra vrus e de que no sero infectados, pois so incapazes de acessar listas (heaps), pilhas (stacks) ou a memria do sistema.

28

Alguns exemplos de segurana do JAVA que supostamente diz o que um programa no pode fazer so: Evitar erros de stack overflow18. Corromper a memria fora de seu prprio processo. Ler ou escrever arquivos locais quando chamado em um carregador de classes seguro, como um browser Web. A segurana de JAVA ser comprometida, se for utilizado algum mtodo nativo na implementao de um programa JAVA. Mtodos nativos so rotinas escritas em outras linguagens, que so chamadas a partir do JAVA. Estas rotinas podem no ser to seguras quanto cdigos em JAVA, especialmente se for escrita em uma linguagem como C ou C++ que no oferecem proteo contra o perigo de se sobrescrever memria mediante uso de ponteiros invlidos.

3.2.6 - ARQUITETURA NEUTRA

O compilador gera um formato de arquivo-objeto com arquitetura neutra o cdigo compilado pode ser executado em muitos processadores, desde que o sistema local tenha o mdulo em tempo de execuo de JAVA. O compilador de JAVA faz isso gerando instrues em bytecodes19 que nada tm a ver com uma arquitetura de computador em particular. Em vez disso, eles so projetados para serem fceis de interpretar em qualquer mquina e facilmente traduzidos em cdigo de mquina nativo no momento da execuo [10]. Derivado da natureza distribuda do cliente/servidor, um importante recurso de projeto da linguagem JAVA o suporte para clientes e servidores em configuraes heterogneas de
Estouro de Pilha. O cdigo JAVA compilado e, este pseudocdigo gerado formado por bytecodes. Os bytecodes so, em geral, executados por um outro programa, o interpretador JAVA (JVM Mquina Virtual JAVA). O interpretador JAVA entende o conjunto lgico de instrues representado pelos bytecodes, simulando a arquitetura virtual para a qual foram desenvolvidos.
19 18

29

rede. Devido portabilidade da linguagem, os objetos binrios de cdigo de bytes podem ser executados em plataformas diferentes. Os objetos de cdigos de bytes de arquitetura neutra contm instrues de computador estreis; no possuem vnculos ou dependncias de nenhuma arquitetura de computador. Em vez disso, as instrues so fceis de decifrar, seja qual for arquitetura de plataforma, e podem ser convertidas dinamicamente para o cdigo de mquina nativo de qualquer plataforma com relativa facilidade. Um programa fonte escrito em linguagem JAVA traduzido pelo compilador para os bytecodes, que so interpretados pela Mquina Virtual Java (JVM JAVA Virtual Machine). A vantagem desta tcnica evidente: garantir uma maior portabilidade para os programas JAVA em cdigo-fonte e compilados. O formato de independncia de arquitetura concede grandes benefcios, tanto ao usurio quanto ao programador, pois, uma vez que o cdigo disponibilizado, pode ser executado em qualquer plataforma.

3.2.7 INTERPRETADO
O interpretador de JAVA pode executar os bytecodes diretamente em qualquer mquina para o qual tenha sido transportado. Esta uma vantagem enquanto se desenvolve uma aplicao, mas ela claramente mais lenta que um cdigo compilado. A vantagem que ela permite um acompanhamento mais apurado no processo de desenvolvimento, na depurao do cdigo.

3.2.8 ALTO DESEMPENHO

O termo no correto para descrever a desempenho de um aplicativo ou applet JAVA quando leva-se em considerao somente o interpretador. Certamente a velocidade dos bytecodes interpretados pode ser aceitvel, mas no rpida.

30

Compiladores especficos para JAVA no esto disponveis. Ao invs disso, h compiladores Just-in-time (JIT)20. Estes trabalham compilando uma vez os bytecodes em cdigo nativo. Em seguida lem o resultado e repetem a compilao caso necessrio. Ainda que mais lento que compiladores nativos, os compiladores Just-in-time podem aumentar de 10 a 20 vezes a velocidade de muitos programas e so quase sempre significativamente mais rpidos que o interpretador JAVA.

3.2.9 MULTITHREADED21
As linhas de execuo em JAVA tambm conseguem tirar proveito de sistemas multiprocessados, se o sistema operacional bsico tambm o conseguir. Por outro lado, as implementaes de thread nas principais plataformas diferem bastante, e JAVA no se esfora para ser independente de plataforma com relao a isso.

3.2.10 DINMICO
JAVA foi projetada para adaptar-se a um ambiente em evoluo. As bibliotecas podem adicionar livremente novos mtodos e variveis de instncia sem qualquer efeito sobre seus clientes. Nesta linguagem, a descoberta do tipo de dado em tempo de execuo imediata. Esta uma caracterstica importante nas situaes em que o cdigo precisa ser adicionado a um programa em execuo. Um exemplo o cdigo que transferido da Internet para ser executado no browser.

20 21

Compilao imediatamente antes da execuo do programa. Mutithread a capacidade de um programa fazer mais de uma coisa ao mesmo tempo, como por exemplo, gravar um arquivo e imprimir outro.

31

3.3 CONCEITOS DE ORIENTAO A OBJETOS

Linguagens de programao, como os prprios idiomas humanos, evoluem ao longo do tempo. H um constante refinamento e aperfeioamento para atender s exigncias cada vez maiores dos usurios. Como outras linguagens de programao modernas, como C++, JAVA uma mistura de vrias tcnicas desenvolvidas ao longo dos anos [12]. Assim, seguindo os paradigmas de desenvolvimento mais utilizados, a linguagem JAVA orientada a objetos. O paradigma de orientao a objetos j demonstrou que muito mais do que uma simples moda. Benefcios da tecnologia de objetos so observados medida que um nmero cada vez maior de empresas migram seus produtos para este tipo de modelo. Infelizmente, o conceito de orientao a objetos continua um pouco confuso e propagado como o que vai resolver todos os problemas do mundo do software. Por exemplo, uma viso superficial de programao orientada a objetos afirmar que este paradigma simplesmente uma nova maneira de organizar o cdigo fonte. Na verdade, pode-se alcanar com tcnicas de programao orientada a objetos, resultados que no seriam possveis de se obter com tcnicas procedurais. Como uma linguagem orientada a objetos, JAVA aproveita os melhores conceitos e funcionalidades de linguagens mais antigas (principalmente Eiffel, SmallTalk, Objective C e C++). JAVA vai alm do C++ pois estende o modelo de objetos e remove as maiores complexidades da linguagem. Por exemplo, com exceo dos tipos de dados primitivos, tudo em JAVA um objeto (at mesmo os tipos primitivos podem ser encapsulados dentro de objetos, se for necessrio).

32

3.3.1 CONCEITOS BSICOS

Nos prximos itens deste captulo ser definido o conceito de objetos, mensagens e classes, posteriormente algumas definies sobre encapsulao, herana e polimorfismo. Todos estes conceitos so partes essenciais da Linguagem de Programao proposta, pois uma linguagem totalmente orientada a objetos.

3.3.1.1 OBJETOS
Como o prprio nome orientado a objetos indica, o conceito de objetos fundamental para o entendimento desta tecnologia. Pode-se olhar a sua volta e encontrar vrios exemplos de objetos: cachorro, cadeira, televiso, bicicleta, entre outros. Estes objetos do mundo real compartilham duas caractersticas: possuem estados (propriedades) e tem um comportamento. Um cachorro tem uma propriedade (nome, cor, raa, com fome) e um comportamento (latindo, comendo, lambendo). Analogamente, objetos de Software so modelados de acordo com os objetos do mundo real, ou seja, possuem tambm estados e comportamento. Um objeto de software armazena seu estado em variveis e implementa seu comportamento com mtodos. Portanto, podem-se representar objetos do mundo real utilizando objetos de software. Alm disto, objetos de software podem ser usados para modelar conceitos abstratos, como por exemplo, um evento de interface grfica que representa a ao do usurio pressionando uma tecla. A ilustrao da figura 3.1 uma representao comum do conceito de objeto:

33

Figura 3.1: Representao de objeto.

Tudo que o objeto de software conhece (estado) e pode fazer (comportamento) expresso pelas variveis e mtodos do objeto. Um objeto que modela uma bicicleta poderia ter variveis que indicam seu o estado atual: velocidade 20 km/h, marcha atual a quinta. Exemplos de mtodos deste objeto seriam: frear, aumentar a velocidade da pedalagem e trocar de marcha. Estas variveis e mtodos so formalmente chamados de variveis de instncia e mtodos de instncia a fim de distingui-los de variveis e mtodos de classe descritos no item Classes. As variveis de um objeto fazem parte do seu ncleo (centro). Os mtodos envolvem e escondem o ncleo do objeto de outros componentes (objetos) da aplicao. Empacotar as variveis de um objeto sobre a proteo de seus mtodos chamado de encapsulao (seo). Basicamente, a encapsulao usada para esconder detalhes de implementao pouco importantes. Por exemplo, quando se deseja trocar uma marcha na sua bicicleta, no preciso saber como o mecanismo de troca de marchas funciona apenas qual alavanca deve ser movida. Analogamente, em programas, muitas vezes no necessrio saber como um objeto foi implementado, apenas saber qual mtodo deve ser invocado. Assim, os detalhes de implementao podem ser mudados sem afetar outras partes do programa. Esta representao conceitual de um objeto, um ncleo de variveis dentro de uma membrana protetora de mtodos, um modelo ideal que deve servir de meta para projetistas de sistemas orientados a objetos. Entretanto, esta representao no totalmente realista.

34

Muitas vezes, por razes de implementao ou eficincia, um objeto pode desejar expor algumas de suas variveis ou esconder alguns de seus mtodos.

3.3.1.2 MENSAGENS
Geralmente, um objeto sozinho no muito til e aparece como um componente de uma aplicao maior que contm vrios outros objetos. A interao entre os objetos que permite se obter todas as funcionalidades de uma aplicao. Por exemplo, uma bicicleta s til quando outro objeto (ciclista) interage com ela. Objetos comunicam-se entre si por meio do envio de mensagens. Quando um objeto A deseja que o objeto B realize um dos seus mtodos (de B), o objeto A envia uma mensagem para o objeto B. Algumas vezes, o objeto que recebe a mensagem precisa de mais informaes para saber exatamente o que fazer. Por exemplo, quando voc quer trocar as marchas em uma bicicleta, devesse indicar qual a marcha desejada. Esta informao acompanha a mensagem como um parmetro. Assim, trs componentes fazem parte de uma mensagem: O objeto para onde a mensagem endereada (bicicleta); O nome do mtodo a realizar (mudar a marcha); Parmetro(s) necessrio(s) para realizar o mtodo (segunda marcha). Objetos no precisam estar no mesmo processo ou na mesma mquina para enviar e receber mensagens de uns para os outros.

3.3.1.3 CLASSES
No mundo real, muitas vezes existem vrios objetos do mesmo tipo. Por exemplo, utilizando a terminologia de orientao a objetos, pode-se dizer que um objeto bicicleta uma

35

instncia de uma classe de objetos conhecida como bicicletas. Bicicletas possuem estados e comportamentos comuns. Entretanto, o estado de cada bicicleta independente e pode ser diferente de outras bicicletas. Em software orientado a objetos, possvel ter vrios objetos do mesmo tipo que compartilham caractersticas. Desta forma, pode-se tirar vantagem de que os objetos do mesmo tipo so similares e criar uma frma para estes objetos. Tais frmas de software so chamadas de classes. Assim, uma classe uma frma (prottipo) que define as variveis e mtodos comuns a todos os objetos de certo tipo. Valores de variveis de instncia existem para cada instncia (objeto) da classe. Assim, depois de criar a classe bicicleta, deve-se instanci-la a fim de utilizar seus objetos. Quando se cria uma instncia de uma classe, cria-se um objeto daquele tipo e o sistema aloca memria para as variveis de instncia definidas para a classe. Depois de criado, podem-se invocar os mtodos de instncia do objeto. Alm das variveis e mtodos de instncias, classes podem tambm definir variveis de classe (class variables) e mtodos de classe (class methods). Pode-se acessar variveis e mtodos de classe sem ter a necessidade de se instanciar um objeto da classe. Mtodos de classe s podem manipular variveis de classe, ou seja, no podem acessar mtodos ou variveis de instncia. O sistema cria uma nica cpia de uma varivel de classe, ou seja, todos os objetos daquela classe compartilham as mesmas variveis de classe.

3.3.2 CARACTERSTICAS DA TECNOLOGIA DE OBJETOS

Para ser considerada verdadeiramente orientada a objetos, uma linguagem de programao deve oferecer, no mnimo, estas trs caractersticas:

36

Encapsulao; Herana; Polimorfismo.

3.3.2.1 ENCAPSULAO
Uma das principais diferenas entre o paradigma de programao estruturada e o modelo de orientao a objetos a caracterstica de encapsulao. Encapsulao permite esconder, dentro de um objeto, tanto suas variveis quanto os mtodos que manipulam estas variveis. Assim, possvel controlar acessos de outros componentes aos dados do objeto. Na programao estruturada tambm pode-se esconder os dados dentro de uma funo simplesmente criando variveis locais. O problema surge quando se deseja tornar uma varivel disponvel a outras funes. Em um programa estruturado, a soluo criar variveis globais. Infelizmente, desta forma qualquer funo dentro do programa pode acessar os dados. Na programao orientada a objetos, consegue-se criar variveis de instncia, que podem ser acessadas por qualquer mtodo do objeto, mas no so visveis por outros objetos. A idia de encapsulao, apesar de simples, uma ferramenta poderosa que oferece dois benefcios principais aos programadores: Modularidade: o cdigo fonte de um objeto pode ser escrito e mantido independentemente do cdigo fonte de outros objetos. Ocultamento da informao: um objeto possui uma interface pblica que outros objetos podem utilizar para comunicar-se com ele. Alm disto, o objeto pode manter informaes e mtodos privados que podem ser mudados a qualquer momento sem afetar os outros objetos.

37

3.3.2.2 HERANA
De maneira geral, objetos so definidos em termos de classes. Consegue-se obter muitas informaes sobre um objeto conhecendo a sua classe. Por exemplo, voc pode no saber o que uma penny-farthing, mas se lhe disserem que uma bicicleta, voc consegue imaginar o objeto (duas rodas, pedais, assento, etc.). Sistemas orientados a objetos permitem tambm que classes sejam definidas em termos de outras classes. Por exemplo, mountain bikes e bicicletas de corrida so diferentes tipos de bicicletas. Na terminologia de orientao a objetos, mountain bikes e bicicletas de corrida so subclasses da classe bicicleta. Analogamente, a classe bicicleta uma superclasse de mountain bikes e bicicletas de corrida, como mostra a figura 3.2.

Figura 3.2: SuperClasses e Subclasses

Cada classe herda o estado (na forma das declaraes de variveis) da superclasse. Mountain bikes e bicicletas de corrida compartilham alguns estados (velocidade, por exemplo). Alm disto, cada subclasse herda os mtodos da superclasse. Mountain bikes e bicicletas de corrida compartilham certos comportamentos (frear, por exemplo). Entretanto, subclasses no esto limitadas ao comportamento herdado de sua superclasse. Subclasses podem adicionar variveis e mtodos a aqueles herdados.

38

Subclasses tambm podem redefinir (override) mtodos herdados e oferecer implementaes especializadas para estes mtodos. Por exemplo, se uma montain bike possui um conjunto extra de marchas, voc poderia sobrecarregar o mtodo mudar marcha de tal forma que seja possvel escolher este novo conjunto de marchas. O conceito de herana pode ser aplicado para mais de um nvel. A rvore de herana, ou hierarquia de classe pode ser to profunda quanto necessrio. Os mtodos e variveis so herdados atravs dos nveis. Em geral, quanto mais baixa na hierarquia for a posio de uma classe, mais especializado o seu comportamento. Como benefcios do conceito de herana, podemos citar: Subclasses oferecem comportamentos especializados a partir de elementos bsicos comuns, oferecidos pela superclasse. Por meio da utilizao de herana, programadores podem reusar o cdigo da superclasse vrias vezes. Programadores podem definir classes abstratas que determinam

comportamentos genricos. A superclasse abstrata define e pode implementar parcialmente o comportamento de uma classe, mas a maioria das informaes da classe fica indefinida ou no implementada. Outros programadores especializadas. completam estes detalhes por meio de subclasses

3.3.2.3 POLIMORFISMO
Segundo a terminologia de orientao a objetos, polimorfismo significa que uma mesma mensagem enviada a diferentes objetos resulta em um comportamento que dependente da natureza do objeto que est recebendo a mensagem.

39

Existem vrios tipos de polimorfismo. O primeiro tipo, descrito no item anterior, quando uma classe redefine a implementao de um mtodo herdado. Este polimorfismo classificado como polimorfismo de incluso. Se a subclasse oferece um mtodo de assinatura (nome, parmetro de retorno e argumentos) parecida com a do mtodo herdado ento no se trata de uma redefinio e sim de uma sobrecarga, pois criou-se, na verdade, um novo mtodo. Outro tipo bastante interessante de polimorfismo conhecido como acoplamento dinmico (dynamic binding). Por acoplamento, entenda-se a escolha correta de um mtodo a ser executado para uma varivel declarada como de uma classe, mas que pode conter um objeto de uma subclasse desta. Por dinmico, entenda-se tempo de execuo. Devido s caractersticas de herana, pode-se atribuir um objeto de uma subclasse a uma varivel da classe pai, mas no o contrrio. Com o acoplamento dinmico, possvel fazer com que a execuo de um mtodo dependa do tipo do objeto atribudo a varivel. Estas caractersticas proporcionam maior flexibilidade para a implementao do Software de Controle, pois JAVA independe da plataforma de trabalho, somando-se ainda o fato de JAVA ser uma linguagem gratuita (freeware). No captulo seguinte, so mostrados os conceitos empregados para a construo do Software de Controle do brao mecnico utilizando a linguagem de programao JAVA.

APTULO 4 - IMPLEMENTAO DO SOFTWARE DE CONTROLE

Para o desenvolvimento do software de controle remoto do brao mecnico SCORBOT ER - III, utilizou-se linguagem de programao JAVA verso 1.4.2 da Sun Microsystems e alguns mtodos e bibliotecas desta linguagem, como o uso de Invocao de Mtodos Remotos (RMI Remote Methods Invocation), Mtodos Nativos (JNI JAVA Native Interface), Conectividade com Banco de Dados JAVA (JDBC JAVA Database Connectivity) e JMF (JAVA Media Frameworks) para o monitoramento em tempo real do rob utilizando o protocolo RTP Real Time Protocol (Protocolo de Tempo Real). A figura 4.1 ilustra o aplicativo cliente que responsvel pelo envio de tarefas ao servidor. Este solicita quais os motores que sero ativados atravs dos botes de controle, e assim, o envio de tarefas ao servidor feito com base nos conceitos de RMI. A aquisio dos frames no software cliente ocorre atravs dos conceitos de JMF/RTP, onde passado rede, o endereo IP do host que estar recebendo os quadros e em qual porta isso ocorrer. A figura 4.2 ilustra o aplicativo servidor que responsvel pelo envio de imagens ao cliente e pela execuo das tarefas solicitadas. O servidor responsvel pelo controle do rob, pois o brao mecnico se encontra conectado a ele atravs da porta paralela do computador. Em posse de uma solicitao do cliente atravs de RMI, o servidor executa a tarefa solicitada utilizando conceitos de JNI. As imagens adquiridas por uma Webcam instalada no servidor so enviadas a um endereo IP de uma mquina cliente especfica. Esta receber os quadros (imagens) atravs de uma porta de conexo com a rede de computadores, atravs de JMF/RTP.

41

Figura 4.1: Layout do Aplicativo Cliente

Figura 4.2: Layout do Aplicativo Servidor

42

Na figura 4.3 apresenta-se o layout do formulrio de cadastro de movimentos do rob. Este formulrio possibilita a insero, remoo, alterao e navegao entre registros do banco de dados Motores.fdb, o qual armazena os valores para que o rob execute uma tarefa pr-programada.

Figura 4.3: Layout do formulrio de cadastro para o movimento do motor.

Os layouts apresentados nas figuras 4.4, 4.5 representam as caixas de dilogo para a insero de valores no banco de dados.

43

Figura 4.4: Caixa de dilogo para inserir um motor do banco de dados.

Figura 4.5: Caixa de dilogo para fornecer o deslocamento do rob.

O layout da figura 4.6 apresenta a caixa de dilogo para a remoo de uma linha, correspondente s coordenadas de deslocamento de um determinado motor, do banco de dados.

Figura 4.6: Caixa de dilogo para remover s coordenadas de um motor do banco de dados.

Na figura 4.7, ilustra-se a tela de informaes com respeito ao desenvolvimento do Sistema de Controle do SCORBOT ER III. A seguir sero detalhados os procedimentos para a criao do programa que tem por objetivo manipulao remota do brao mecnico do rob SCORBOT ER III, utilizando a rede mundial de computadores atravs da linguagem de programao JAVA. Uma cpia dos cdigos fonte do software de controle do SCORBOT est disponvel no final desta dissertao. Como dito anteriormente, uma das vantagens de se trabalhar com aplicaes JAVA a sua portabilidade. Alguns autores utilizam uma tcnica denominada Common Gateway Interface (CGI) para interpretar as entradas do usurio, por meio de um navegador, e retornar estas informaes baseadas nessas entradas [13]. Esta tcnica torna-se mais cmoda para os

44 desenvolvedores, pois no exige conhecimentos de programao nas camadas de protocolo de rede, Internet e WEB.

Figura 4.7: Layout do formulrio sobre o sistema.

4.1 MTODOS NATIVOS

O JAVA uma linguagem relativamente nova, significando que possam existir situaes em que ser necessrio integrar programas feitos em JAVA com servios j existentes escritos em outras linguagens. A plataforma JAVA proporciona o JNI para auxlio em integraes de diferentes linguagens [14]. A biblioteca JNI nos auxilia na integrao destas linguagens fazendo a especificao de como que se nomeia (dar nome aos mtodos JAVA) e se invoca esses servios de forma a que o JAVA Virtual Machine (JVM) possa localiz-los [14]. Existem trs razes bvias pelas quais o uso de Mtodos Nativos pode ser a escolha certa:

45 Possuir volumes substanciais de cdigo testado e depurado disponveis em outra linguagem. Portar o cdigo para a linguagem de programao JAVA seria perda de tempo, e o cdigo resultante precisaria ser testado e depurado novamente; Seu aplicativo exige acesso a recursos de sistema ou dispositivos e usar tecnologia JAVA seria complicado, na melhor das hipteses, ou impossvel, na pior das hipteses; Maximizar a velocidade do cdigo essencial. Por exemplo, a tarefa pode ter o tempo como um componente importante, ou ento, pode ser que o cdigo seja usado com tanta freqncia, que aperfeio-lo seria custoso. Na verdade, este o motivo menos plausvel. Com a compilao just-in-time (JIT), os clculos pesados codificados na linguagem de programao JAVA no so muito mais lentos do que um cdigo compilado em C. Para o acesso a porta paralela e controle do rob, foi utilizado um mtodo nativo programado em C++, o qual possui duas funes chamadas outportb e inportb, encarregada pelo envio de bits porta paralela para ativao dos motores do rob e controle dos encoders nos localizados junto aos motores do rob, j que a utilizao da biblioteca JAVAX.COMM, especfica da Linguagem JAVA, o controle tornou-se insatisfatrio, uma vez que, esta biblioteca no portvel a todas as plataformas computacionais existentes [15]. Portanto, possvel invocar cdigo escrito em qualquer linguagem a partir de um programa em JAVA. Para que essa invocao possa ser efetuada so necessrios os seguintes passos: Declarao de mtodos nativos (JAVA Native Methods); Carregamento da biblioteca que contm o cdigo nativo (na plataforma Windows estas assumem a forma de Dynamic Link Libraries DLL's);

46 Chamada dos mtodos nativos.

Como mencionado anteriormente, primeiramente precisa-se declarar o mtodo nativo em uma classe. Neste caso, a classe pertencente ao projeto definida como

ControlaMotores.class e, arquivo de fonte com nome ControlaMotores.java mostrada na tabela 1 define-se o mtodo. Tabela 1: Implementao da classe ControlaMotores.java.
class ControlaMotores { public static native void controle(int NumMotor, int PassoMotor); static { System.loadLibrary("Controla"); } }

A palavra-chave native alerta ao compilador que o mtodo ser definido externamente. Nestes mtodos, no aparecero cdigos de programao JAVA, e o cabealho do mtodo ser seguido imediatamente por um ponto-e-vrgula de terminao. Depois de definida, compilou-se a classe ControlaMotores.class executando o utilitrio javah, para a criao automtica das assinaturas que devero ser utilizadas na implementao do cdigo nativo. Para usar javah, primeiro compila-se o arquivo fonte da seguinte maneira: javac ControlaMotores.java

Em seguida, chamado o utilitrio javah para produzir o arquivo de cabealho que ser anexado ao cdigo em C. javah ControlaMotores

Depois de compilado com xito, o uso de javah cria um arquivo de cabealho ControlaMotores.h, como mostra a tabela 2:

47 Tabela 2: Arquivo de Cabealho ControlaMotores.h

/* DO NOT EDIT THIS FILE - it is machine generated */ #include <jni.h> /* Header for class ControlaMotores */ #ifndef _Included_ControlaMotores #define _Included_ControlaMotores #ifdef __cplusplus extern "C" { #endif /* * Class: ControlaMotores * Method: controle * Signature: (II)V */ JNIEXPORT void JNICALL Java_ControlaMotores_controle (JNIEnv *, jclass, jint, jint); #ifdef __cplusplus } #endif #endif

O arquivo ControlaMotores.h define uma interface que faz a correspondncia entre os mtodos escritos em JAVA com as funes nativas escritas em C++. Neste exemplo, a assinatura do Controle faz corresponder os argumentos e resultados do mtodo Controle implementada na biblioteca de cdigo nativo. As assinaturas deste exemplo so mostradas na tabela 3. Tabela 3: Assinaturas criadas pelo arquivo de cabealho.
/* * Class: ControlaMotores * Method: controle * Signature: (I)V */ JNIEXPORT void JNICALL java_ControlaMotores_controle (JNIEnv *, jclass, jint);

Os parmetros da assinatura do mtodo tm o seguinte significado: JNIEnv *: Um apontador para a ambiente interface nativa JAVA. jclass: Referncia para o objeto que chamou este cdigo nativo.

48

4.1.1 IMPLEMENTAO DO MTODO NATIVO

No arquivo de cdigo-fonte nativo, deve-se copiar o prottipo da funo do arquivo de cabealho e fornecer o cdigo da implementao para a funo mostrada no mtodo nativo Controla.c. Esta funo tem a finalidade de acionar atravs da sub-rotina chamada outportb, os motores que compem o rob e controlar os encoders atravs da funo inportb do SCORBOT ER - III.

4.1.2 COMPILAO DA BIBLIOTECA

A biblioteca necessita ser compilada de forma dinmica para que possa ser carregada durante o tempo de execuo do programa em JAVA (runtime). Para a compilao da biblioteca utiliza-se o seguinte comando: bcc32 -Ic:\j2sdk1.4.2_04\include -Ic:\j2sdk1.4.2_04\include\win32 -LD Controla.c -oControle.dll O comando bcc32.exe pertence ao compilador C++ 5.0 da Borland, e os parmetros restantes especificam os diretrios necessrios header files. O parmetro LD especifica que o resultado uma biblioteca dinmica. Depois de compilado o arquivo Controla.c gerada automaticamente a biblioteca dinmica Controle.dll.

4.2 INVOCAO DE MTODOS REMOTOS

Trabalhar com mtodos remotos implica em possuir um conjunto de objetos colaborativos, que possam ser localizados em qualquer lugar. Esses objetos comunicam-se atravs de protocolos padres de uma rede. Por exemplo, o objeto cliente envia uma mensagem para um objeto no servidor, contendo os parmetros da solicitao. O objeto servidor rene as informaes solicitadas ou se necessrio, comunica-se com objetos adicionais. Uma vez que o objeto servidor tenha a resposta para o cliente, este retorna as informaes.

49

4.2.1 CHAMADAS DE OBJETOS REMOTOS

O mecanismo RMI permite o acesso a um objeto em uma mquina diferente, sendo chamado de mtodos de objeto remoto. Os parmetros do mtodo devem ser enviados para uma determinada mquina e aps a execuo dos parmetros no objeto remoto, envia-se um valor de retorno para o objeto cliente [14]. Como mostra a figura 4.8, o cliente busca informaes no servidor, atravs do mtodo remoto find, este mtodo retorna um objeto para o cliente.

Figura 4.8: Chamando um objeto remoto em um objeto servidor

Na terminologia RMI, o objeto cujo mtodo faz a chamada remota denominado cliente e o objeto remoto chamado de servidor. importante lembrar que a terminologia cliente/servidor aplica-se apenas a uma chamada de mtodo simples. O computador que est executando o cdigo na linguagem de programao JAVA e chama o mtodo remoto, o cliente dessa chamada e o computador que contm o objeto que processa a chamada, o servidor. Em qualquer momento, possvel que os papis sejam invertidos. No aplicativo de controle do brao mecnico, o cliente passa um parmetro informando ao servidor qual motor dever ser executado atravs de chamadas RMI. O servidor encontrado uma vez que o mesmo possui uma nomenclatura que o diferencia dentro da rede. Depois de encontrado e de posse do parmetro enviado pelo cliente, o servidor

50 executa os comandos para a ativao dos motores fazendo uso de uma biblioteca dinmica compilada em C++ e acessada atravs de terminaes nativas JNI.

4.2.2 ESTABELECENDO CHAMADAS DE MTODOS REMOTOS

Executar o exemplo mais simples de objeto remoto exige muito mais configurao do que executar uma applet ou um programa independente. Devem-se executar programas nos computadores denominados servidor e cliente. As informaes necessrias do objeto devem separar as interfaces do lado do cliente e as implementaes no lado do servidor, no qual, atravs de pesquisas, o cliente localiza objetos no servidor. Para o funcionamento do cdigo por meio de mtodos remotos, ambas as mquinas (servidor/cliente) devero ter os servios de rede disponveis, sendo assim, necessrio o funcionamento do protocolo TCP/IP. Portanto, neste trabalho, utilizando o conceito de Invocao de Mtodos Remotos, a mquina Cliente pode acessar o Servidor, no qual, o rob est conectado e fazer a solicitao de uma tarefa para a sua manipulao. A comunicao entre o Servidor e o rob feita atravs da porta paralela do micro-computador.

4.2.3 INTERFACES E IMPLEMENTAES (RMI)

O programa cliente necessariamente manipula objetos do servidor. Como esses objetos residem no Servidor, necessrio que esses recursos sejam expressos em uma interface que compartilhada entre o cliente e o servidor e, portanto, residem simultaneamente nas duas mquinas. Para a comunicao entre o cliente e o servidor na manipulao do brao mecnico, foi criada um cdigo de interface chamada InterfaceRMI.java mostrada na tabela 4: Tabela 4: Implementao da classe InterfaceRMI.java
import java.rmi.*; public interface InterfaceRMI extends Remote {

51
void Motor1() throws RemoteException; void Motor2() throws RemoteException; void Motor3() throws RemoteException; void Motor4() throws RemoteException; void Motor5() throws RemoteException; void Motor6() throws RemoteException; void Motor7() throws RemoteException; void Motor8() throws RemoteException; void Motor9() throws RemoteException; void Motor10() throws RemoteException; void Motor11() throws RemoteException; void Motor12() throws RemoteException; void Motor13() throws RemoteException; void Motor14() throws RemoteException; void Motor15() throws RemoteException; void Motor16() throws RemoteException; void Motor17() throws RemoteException; void Motor18() throws RemoteException; void Motor1par(int x) throws RemoteException; void Motor2par(int x) throws RemoteException; void Motor3par(int x) throws RemoteException; void Motor4par(int x) throws RemoteException; void Motor5par(int x) throws RemoteException; void Motor6par(int x) throws RemoteException; void Motor7par(int x) throws RemoteException; void Motor8par(int x) throws RemoteException; void Motor9par(int x) throws RemoteException; void Motor10par(int x) throws RemoteException; void Motor11par(int x) throws RemoteException; void Motor12par(int x) throws RemoteException; void Motor13par(int x) throws RemoteException; void Motor14par(int x) throws RemoteException; void Motor15par(int x) throws RemoteException; void Motor16par(int x) throws RemoteException; void Motor17par(int x) throws RemoteException; void Motor18par(int x) throws RemoteException;}

Todas as interfaces de objetos remotos devem possuir a interface Remote definida no pacote java.rmi. Os mtodos dessa interface tambm devem declarar que lanaro uma RemoteException, pois as chamadas de mtodos remotos so menos confiveis do que as chamadas locais, podendo ocorrer falha em uma chamada remota. Por exemplo, o servidor ou a conexo de rede pode estar temporariamente indisponvel, ou pode haver um problema de rede, assim, o cdigo cliente deve estar preparado para estas possibilidades. Depois de definido as interfaces, implementou-se no lado do servidor, a classe que efetivamente executar os mtodos anunciados na interface remota. Para o programa de controle do rob, foi implementado um cdigo chamado ServidorRMI.java como mostrado na tabela 5:

52 Tabela 5: Implementao da Classe ServidorRMI.java

import java.rmi.*; import java.rmi.server.UnicastRemoteObject; public class ServidorRMI extends UnicastRemoteObject implements InterfaceRMI { public ServidorRMI() throws RemoteException { } public void Motor1() throws RemoteException { ControlaMotores.controle(1,0); } public void Motor2() throws RemoteException { ControlaMotores.controle(2,0); } public void Motor3() throws RemoteException { ControlaMotores.controle(3,0); } public void Motor4() throws RemoteException { ControlaMotores.controle(4,0); } public void Motor5() throws RemoteException { ControlaMotores.controle(5,0); } public void Motor6() throws RemoteException { ControlaMotores.controle(6,0); } public void Motor7() throws RemoteException { ControlaMotores.controle(7,0); } public void Motor8() throws RemoteException { ControlaMotores.controle(8,0); } public void Motor9() throws RemoteException { ControlaMotores.controle(9,0); } public void Motor10() throws RemoteException { ControlaMotores.controle(10,0); } public void Motor11() throws RemoteException { ControlaMotores.controle(11,0); } public void Motor12() throws RemoteException { ControlaMotores.controle(12,0); }

53
public void Motor13() throws RemoteException { ControlaMotores.controle(13,0); } public void Motor14() throws RemoteException { ControlaMotores.controle(14,0); } public void Motor15() throws RemoteException { ControlaMotores.controle(15,0); } public void Motor16() throws RemoteException { ControlaMotores.controle(16,0); } public void Motor17() throws RemoteException { ControlaMotores.controle(17,0); } public void Motor18() throws RemoteException { ControlaMotores.controle(18,0); }

public void Motor1par(int x) throws RemoteException { ControlaMotores.controle(19,x); } public void Motor2par(int x) throws RemoteException { ControlaMotores.controle(20,x); } public void Motor3par(int x) throws RemoteException { ControlaMotores.controle(21,x); } public void Motor4par(int x) throws RemoteException { ControlaMotores.controle(22,x); } public void Motor5par(int x) throws RemoteException { ControlaMotores.controle(23,x); } .. }

Todas as classes de servidor devem ser estendidas a classe RemoteServer do pacote java.rmi.server, mas trata-se de uma classe abstrata que define apenas os mecanismos bsicos

54 para a comunicao entre objetos servidores e seus stubs22 remotos. A classe UnicastRemoteObject que acompanha o RMI estende a classe abstrata RemoteServer e concreta, portanto, pode-se us-la sem escrever nenhum cdigo [14]. Um objeto UnicastRemoteObject reside em um servidor, e ele deve estar ativo quando um servio for solicitado e deve ser acessado atravs do protocolo TCP/IP. Depois de criada e compilada a classe ServidorRMI, deve-se gerar stubs para esta. A ferramenta rmic as gera automaticamente com a seguinte linha de instruo: rmic ServidorRMI Esta chamada gera dois arquivos de classes citados a seguir: ServidorRMI_Stub.class ServidorRMI_Skel.class

Na figura 4.9 apresentado o diagrama da arquitetura RMI. A transmisso dos dados na rede se d atravs do protocolo TCP/IP, na camada de transporte, de maneira transparente.

Figura 4.9: Diagrama da Arquitetura RMI.

Muitos sistemas operacionais, como o Windows 2000 e o XP por motivos de segurana restringem o acesso s portas de I/O em nvel de usurio. Como o aplicativo servidor do software de controle faz referncia direta porta paralela do computador, houve a necessidade da utilizao de um aplicativo de nome Userport, desenvolvido por Thomas Franzon em 2001
22

Classes que renem os parmetros e os resultados das chamadas de mtodos atravs da rede.

55 [16] e [17], que habilitou as portas necessrias para a comunicao com a porta paralela, no caso o endereo dos registradores para LPT1 0x37A.

4.2.4 LOCALIZANDO OBJETOS SERVIDORES

Um programa servidor registra objetos com o servio de registro de partida e o cliente recupera stubs para esses objetos. Registra-se um objeto servidor fornecendo ao servio de registro de partida uma referncia ao objeto e um nome. O nome uma string e espera-se ser nica. Na tabela 6, tem-se a implementao no lado do servidor: Tabela 6: Definio do Objeto e do Nome do Servio
String serviceName = "SCORBOT"; ServidorRMI myCount = new ServidorRMI(); Naming.rebind(serviceName, myCount);

onde: serviceName define o nome do servio e; myCount faz a referncia ao objeto.

O cdigo cliente obtm uma stub para acessar este objeto servidor, especificando o nome do servidor e o nome do objeto, mostrado na tabela 7 da seguinte maneira: Tabela 7: Definio do nome do servidor e o nome do objeto
String url ="rmi://localhost/"; InterfaceRMI myCount = (InterfaceRMI) Naming.lookup(url+"SCORBOT");

Na tabela 8, encontra-se o programa servidor baseado em RMI para anlise. Tabela 8: Implementao da classe ServidorRMIServer.java
import java.rmi.server.*; import java.rmi.*; public class ServidorRMIServer { public static void main(String[] args) { try { String serviceName = "SCORBOT"; ServidorRMI myCount = new ServidorRMI(); //Registry r = LocateRegistry.getRegistry(); Naming.rebind(serviceName, myCount); System.out.println("Count Server ready.");

56
} catch (Exception e) { System.out.println("Exception: " + e.getMessage()); //e.printStackTrace(); } } }

4.3 JDBC CONECTIVIDADE COM BANCO DE DADOS JAVA

Esse pacote permite aos programadores se conectarem com um banco de dados, consult-lo ou atualiz-lo, usando o SQL (Structured Query Language, acesso banco de dados). JAVA e JDBC possuem uma vantagem fundamental sobre outros ambientes de programao de banco de dados, pois, os programas desenvolvidos com essa linguagem de programao so independentes de plataforma e fornecedor. O mesmo programa de banco de dados, escrito na linguagem de programao JAVA, pode ser executado em um computador NT, um servidor Solaris ou um aplicativo de banco de dados utilizado na plataforma JAVA [14]. No futuro, devido universalidade da linguagem de programao JAVA e do JDBC, estes finalmente substituiro as linguagens de banco de dados proprietrias. Para o desenvolvimento deste projeto, utilizou-se JDBC para a conexo com um banco de dados Firebird. Este composto por apenas uma tabela chamada SCORBOT, onde a mesma possui os seguintes campos: SCORBOT = {codmotor, motor, deslocamento} Este banco de dados tem a finalidade de pr-programar tarefas a serem executadas pelo rob. A mquina cliente, que solicita a execuo de uma tarefa de manipulao do rob, acessa remotamente o banco de dados no servidor e configura o deslocamento de cada motor pertencente ao brao mecnico com coordenadas especficas.

57 A conexo utilizando JDBC entre a aplicao e o banco de dados Firebird feita informando o caminho de onde se encontra o banco de dados a ser utilizado. Na tabela 9, mostrado que no programa de controle do rob criou-se variveis do tipo String, que especificam o caminho, o usurio e a senha do banco de dados.

Tabela 9: Variveis de Caminho, Usurio e Senha

String sUrl = "jdbc:firebirdsql:localhost:c:/APJAVA/motores.fdb"; String vUsuario = "SYSDBA"; String vSenha = "masterkey";

Para a conexo com o banco de dados especificado na varivel sUrl, deve-se carregar o Driver JDBC especfico deste banco de dados e depois abrir a conexo com o banco utilizando a funo DriverManager, como mostrado na tabela 10. Tabela 10: Conexo com o banco de dados
Class.forName("org.firebirdsql.jdbc.FBDriver"); conApJava = DriverManager.getConnection(sUrl, vUsuario, vSenha);

4.4 - JMF (JAVA MEDIA FRAMEWORKS)

A biblioteca JAVA Media Framework (JMF) uma API que possui a capacidade de trabalhar com mdia baseada em tempo, como se faz em aplicaes JAVA e applets, provendo apoio de captura e armazenamento de mdia. Para o recebimento ou envio de mdia ao vivo (tempo real) na Internet ou Intranet, precisa-se entender o recebimento e a transmisso de streams. JMF utiliza o Protocolo de Transporte de Tempo Real (RTP) para receber e transmitir streams de mdia pela rede [18]. Utilizou-se conceitos de JMF para a captura de imagens em tempo real atravs de uma WebCam de marca PCTronix a qual disponibiliza as imagens capturadas no formato JPEG. Com a utilizao de JMF e o aplicativo JMF STUDIO da Sun Microsystems consegue-se detectar dispositivos de entrada e sada conectados ao computador de forma fcil e interativa,

58 pois este aplicativo nos mostra todas as caractersticas destes dispositivos (som e vdeo). A WebCam conectada ao computador atravs da porta USB.

4.4.1 - MEDIA STREAMING

O termo Media Streaming usado freqentemente para definir a tcnica de envio e recebimento de pacotes em cima da rede em tempo real. Quando o contedo de mdia transmitido a um cliente em tempo real, este pode comear a execut-lo sem ter que esperar seu carregamento completo transmisses ao vivo. Quando o fluxo no possui uma durao definida, seria impossvel carreg-lo inteiramente. Observa-se Media Streaming em muitos lugares da Web, rdio e televiso ao vivo, por exemplo, a transmisso de eventos que esto sendo oferecidos por um nmero crescente de portais de Web, possibilitando a administrao de conferncias em cima da Internet. A entrega de contedo de mdia dinmica pela rede est mudando conceitos de como as pessoas se comunicam e acessam estas informaes. As imagens so transmitidas do servidor ao cliente sem que haja a interrupo para carregamento ou armazenamento das imagens. Para que se possa entender como feita esta transmisso, alguns conceitos e definies so mostrados nos tpicos seguintes.

4.4.2 - PROTOCOLOS DE MEDIA STREAMING

O HTTP e protocolos de FTP esto baseados no Protocolo de Controle de Transmisso (TCP), que um protocolo pertencente camada de transporte projetado para comunicaes de dados seguros. Se um pacote for perdido ou corrompido, ser retransmitido para garantir a transferncia de dados com segurana e reduzir a velocidade da taxa de transmisso global [18]. Protocolos subjacentes diferentes de TCP so tipicamente usados para transmisso de pacotes de mdia. Nesta linha, destaca-se o User Datagram Protocol (UDP). Este um

59 protocolo incerto, no se tem garantia que a informao alcanar seu destino e que chegar na ordem em que foi enviada. O receptor se encarrega de compensar e detectar dados perdidos, pacotes duplicados e defeituosos. O protocolo padro da Internet para o transporte de dados em tempo real, como udio e vdeo, o RTP (Real Time Protocol).

4.4.3 - PROTOCOLO DE TRANSPORTE DE TEMPO REAL - RTP

O RTP prov entrega de pacotes na rede fim-a-fim para a transmisso de dados em tempo real. independente, entretanto freqentemente usado com o protocolo UDP. A figura 4.10 ilustra a arquitetura do Protocolo RTP.

Figura 4.10: Arquitetura RTP

O RTP pode ser usado em servios de rede unicast (difuso) e multicast (multidifuso). No servio de rede unicast, so enviadas cpias separadas dos dados da fonte para cada destino. J, em um servio de rede de multicast, os dados so enviados somente uma vez da fonte e a rede responsvel para transmit-los a locais mltiplos. Multicasting possui maior eficincia para muitas aplicaes de multimdia, como vdeo conferncias. O Protocolo padro da Internet (IP Internet Protocol) apia multicasting. Os servios de multicasting no so abordados neste trabalho de mestrado.

60

4.4.4 - SERVIOS RTP

O protocolo RTP permite identificar o tipo de dados que sero transmitidos, determina tambm, a ordem de apresentao dos pacotes de dados e sincroniza os streams de mdia de fontes diferentes [18]. Este protocolo no garante a chegada dos pacotes na ordem que eles foram enviados. Na verdade, no garantida a chegada dos dados em seu destino. O receptor quem se encarrega de reconstruir a sucesso de pacotes do remetente, e assim, descobrir quais foram perdidos, utilizando-se da informao contida no cabealho. Enquanto o RTP no pode prover nenhum mecanismo para assegurar a entrega oportuna de pacotes ou garantir a qualidade de servio, este controle feito por um protocolo auxiliar denominado RTCP (Real Time Control Protocol), mostrado na figura 4.5, que permite monitorar a qualidade da distribuio de dados. O RTCP tambm prov controle e mecanismos de identificao para transmisses de RTP. Se a qualidade de servio for essencial para uma aplicao particular, o RTP pode ser usado em cima de um protocolo de reserva que prov servios orientados conexo.

4.4.5 - ARQUITETURA DE RTP

Uma sesso de RTP uma associao entre aplicaes que se comunica entre si, identificada por um endereo de rede e um par de portas, sendo uma usada para os dados de mdia e a outra usada para controle de dados (RTCP). Um participante uma nica mquina, ou usurio que participa da sesso. Participao em uma sesso consiste em recepo passiva de dados (o receptor), transmisso ativa de dados (remetente) ou ambos. Cada tipo de mdia transmitido em uma sesso diferente. Por exemplo, se udio e vdeo so usados em uma conferncia, uma sesso usada para transmitir os dados de udio e

61 outra para transmitir os dados de vdeo. Isto permite que os participantes escolham quais tipos de mdia querem receber. Os dados de mdia para uma sesso so transmitidos em srie de pacotes que por sua vez, originam de uma fonte particular. Esses pacotes so chamados fluxo de RTP. Cada fluxo contm duas partes, um cabealho estruturado e os dados atuais (a carga til do pacote) [18].

4.4.6 - APLICAES DE RTP

As aplicaes so divididas freqentemente na necessidade de recepo e transmisso de dados da rede (cliente/servidor). Algumas aplicaes de conferncias capturam e transmitem dados no mesmo instante em que so receptores na rede. Neste trabalho, o servidor captura imagens (streams) da manipulao do brao mecnico e as envia para um cliente especfico na rede. Para o envio dos pacotes de informaes, o servidor especifica para quem ser enviado os frames atravs de um endereo IP, e s a mquina cliente destino poder ter acesso a estas informaes unicasting.

4.4.7 - TRANSMISSO E RECEPO DE STREAMS RTP

Na criao de uma transmisso de mdia ao vivo, o servidor utilizado neste trabalho tem a seguinte configurao: O DataSource um CaptureDevice Dispositivo de captura de som ou imagem (microfone ou webcam), para o trabalho utilizou-se uma cmera digital PCTronix do tipo vfw:Microsoft WDM Image Capture (Win32):0; Para a definio do dispositivo de captura de imagens, foi criada a classe SwingCapture.class. O cdigo fonte esta na tabela 11. Tabela 11: Cdigo fonte do arquivo SwingCapture.java
public class SwingCapture extends Panel { public static Player player = null; public CaptureDeviceInfo di = null; public MediaLocator ml = null;

62
public JButton capture = null; public Buffer buf = null; public Image img = null; public VideoFormat vf = null; public BufferToImage btoi = null; public SwingCapture() { setLayout(new BorderLayout()); setSize(800,600); String str2 = "vfw:Microsoft WDM Image Capture (Win32):0"; di = CaptureDeviceManager.getDevice(str2); ml = di.getLocator(); player = Manager.createRealizedPlayer(ml); player.start(); Component comp; if ((comp = player.getVisualComponent()) != null) { add(comp,BorderLayout.CENTER); } } }

O Processor foi implementado para ler os dados do dispositivo de captura (WebCam). Os dados capturados so formatados em um padro especfico, caso o dispositivo j no fornea um; A codificao para a criao e formatao dos dados capturados ilustrada na tabela 12 pela funo createProcessor(). Tabela 12: Funo createProcessor
private String createProcessor() { DataSource ds = null; processor = inProc; ds = Manager.createDataSource(locator); // Aguarde a configurao do Processor boolean result = waitForState(processor, Processor.Configured); // Obtm trilhas do Processor TrackControl [] tracks = processor.getTrackControls(); boolean programmed = false; // Realiza a procura de trilhas de vdeo for (int i = 0; i < tracks.length; i++) { Format format = tracks[i].getFormat(); if ( tracks[i].isEnabled() && format instanceof VideoFormat && !programmed) { // Faz a procura de trilhas de vdeo e tenta converter para o formato

63
JPEG/RTP // Verifica se o tamanho dos pacotes so mltiplos de 8 Dimension size = ((VideoFormat)format).getSize(); float frameRate = ((VideoFormat)format).getFrameRate(); int w = (size.width % 8 == 0 ? size.width : (int)(size.width / 8) * 8); int h = (size.height % 8 == 0 ? size.height : (int)(size.height / 8) * 8); VideoFormat jpegFormat = new VideoFormat(VideoFormat.JPEG_RTP, new Dimension(w, h), Format.NOT_SPECIFIED, Format.byteArray, frameRate); tracks[i].setFormat(jpegFormat); programmed = true; } } ContentDescriptor cd = new ContentDescriptor(ContentDescriptor.RAW_RTP); processor.setContentDescriptor(cd); result = waitForState(processor, Controller.Realized); setJPEGQuality(processor, quality/100); // Adquire os dados do Processor dataOutput = processor.getDataOutput(); return null; }

O Render um SendStream responsvel pelo envio dos dados capturados pela internet, via RTP. Para o envio dos dados capturados, foi codificado a funo createTransmitter() ilustrada na tabela 13. Os dados so enviados para um endereo IP especfico em tempo real. Tabela 13: Funo createTransmitter
private String createTransmitter() { // Define o endereo e a porta de destino e qual o tipos dos dados String rtpURL = "rtp://" + ipAddress + ":" + port + "/video"; MediaLocator outputLocator = new MediaLocator(rtpURL); rtptransmitter = Manager.createDataSink(dataOutput, outputLocator); rtptransmitter.open(); rtptransmitter.start(); dataOutput.start(); return null; }

A figura 4.11 ilustra a configurao dos passos definidos anteriormente.

64

Figura 4.11: Transmisso RTP

J na recepo da mdia em tempo real por parte do cliente, a configurao definida a seguir. O DataSource um InputStream, via RTP, que captura os dados transmitidos pelo servidor; O Processor um decodificador deste DataSource (Player); O Render apresenta (Player) os dados capturados em uma applet. A figura 4.12 evidencia a recepo de um pacote RTP.

Figura 4.12: Recepo RTP

Ringgenberg [15], utilizou para o envio e recebimento de pacotes de som e imagem, artifcios como a implementao de sub-programas escritos em linguagens como C++, Cobol, Fortran, etc.; e acessadas utilizando o conceito de mtodos nativos (JNI), esta forma de acesso e controle, acaba por diminuir a portabilidade dos aplicativos implementados, outros autores [2] e [13], utilizam scripts feitos em CGI, para fazer o monitoramento e controle do brao. Assim, o software implementado neste trabalho de mestrado, em relao portabilidade,

65 obteve uma crescente evoluo em relao a trabalhos anteriores com a utilizao de JMF/RTP.

APTULO 5 MODELAGEM DO SOFTWARE DE CONTROLE

Neste captulo descreve-se os conceitos que foram utilizados para o desenvolvimento deste software, no que diz respeito modelagem orientada a objetos.

5.1 UML
O significado de UML (Unified Modeling Language) linguagem de modelagem unificada, derivada da unificao de trs linguagens de modelagens, as quais so: OMT de Rumbauch, o mtodo de Booch e os casos de uso de Jacobson. Cada uma destas linguagens so bem sucedidas como mtodos de anlise orientada a objetos, mas a UML tem como objetivo tirar proveito das principais caractersticas de cada uma. A linguagem UML usada para transmitir e fornecer algumas informaes detalhadas de como um sistema deve ser implementado para efetuar o que o usurio solicita de forma satisfatria. Cada conceito a ser modelado tem uma representao grfica especfica na linguagem. importante seguir as convenes definidas na UML para que outras pessoas possam entender os diagramas gerados [19]. A UML composta de 9 diagramas, mas defini-se aqui somente os diagramas de classe, objeto e caso de uso [19]. Classe: mostra as classes que compem o sistema e as relaes entre elas. Trata-se de um aspecto esttico e estrutural do sistema; Objeto: mostra alguns objetos (instncias das classes) e as relaes entre eles. Os objetos supem a execuo do programa e que instncias so criadas para enviar e receber mensagens; Caso de Uso: mostra como o sistema vai interagir com o usurio.

67

5.2 DIAGRAMA DE CLASSE

O diagrama de classe lista todos os conceitos do domnio que sero implementados no sistema. Por exemplo, em um domnio de reserva de lugares, os itens importantes seriam: lugar, data e cliente. O diagrama mostra tambm as relaes entre os conceitos: um cliente reserva x lugar(es) para uma data especfica. Normalmente, conceitos so tratados como substantivos e relaes como verbos. O diagrama de classes define a estrutura do sistema a ser desenvolvido. Em UML as classes so representadas por caixas divididas em trs partes: nome da classe, atributos e operaes como mostrado na figura 5.1.

Figura 5.1 Representao de uma classe usando UML

Na figura 5.1, o nome da classe FormSobre, os atributos so identificados pelos nomes: sobre, itemArquivo e painel respectivamente; j as operaes so definidos pelos itens expressos na linha 3 do referido diagrama. Um atributo representa uma propriedade que todos os objetos da classe possuem como: altura da mesa, nmero de pernas e posio na sala. Cada objeto possui valores particulares para seus atributos, algumas mesas so mais baixas e outras so mais altas.

68

Operaes ou mtodos definem uma funo que os objetos devem efetuar. Por exemplo, abrir, fechar ou deslocar uma janela so operaes de uma determinada classe.

5.3 DIAGRAMA DE OBJETOS

O diagrama de objetos uma variao do diagrama de classes e utiliza quase a mesma notao. A diferena que o diagrama de objetos mostra os objetos que foram instanciados nas classes. O diagrama de objetos como se fosse o perfil do sistema em um certo momento de sua execuo. A mesma notao do diagrama de classes utilizada com duas excees: os objetos so escritos com seus nomes sublinhados e todas as instncias em um relacionamento so mostradas. Os diagramas de objetos no so to importantes como os diagramas de classes, mas eles so muito teis para exemplificar diagramas complexos de classes ajudando muito em sua compreenso. Diagramas de objetos tambm so usados como parte dos diagramas de colaborao, onde a colaborao dinmica entre os objetos do sistema so mostrados [20].

5.4 DIAGRAMA DE CASO DE USO

Um diagrama de caso de uso (ou use case) um tipo de classificador representando uma unidade funcional coerente provida pelo sistema, subsistema, ou classe manifestada por seqncias de mensagens intercambiveis entre os sistemas e um ou mais atores. Os casos de uso foram propostos inicialmente por Ivar Jacobson em sua metodologia de desenvolvimento de sistemas orientados a objetos. Posteriormente foi incorporado UML tornando seu uso uma prtica freqente na identificao de requisitos de um sistema. Nesse contexto um caso de uso descreve um comportamento que o software a ser desenvolvido apresentar quando estiver pronto.

69

Um software freqentemente um produto complexo, e sua descrio envolve a identificao e documentao de vrios casos de uso, cada um deles descrevendo uma parcela da que o software ou uma de suas partes dever oferecer. importante notar que os casos de uso no descrevem como o software dever ser construdo, e sim, como ele dever se comportar. A UML define um diagrama para representar graficamente os casos de uso e seus relacionamentos. Nas prximas sesses somente os diagramas de classes sero tratados para o software de controle do SCORBOT ER - III.

5.5 DIAGRAMAS DE CLASSES DO APLICATIVO SERVIDOR

Neste tpico so mostrados os diagramas de classes que compem o aplicativo servidor e por fim o relacionamento entre as classes. A figura 5.2, mostra a classe principal do aplicativo servidor (ServidorRMIServer) com a definio de seus atributos e suas operaes. A figura 5.2 tambm indica os mtodos e variveis utilizadas na implementao da classe ServidorRMIServer. As setas tracejadas da figura 5.2 representam as dependncias entre as classes. A relao de dependncia entre as classes representada pelo tracejado iniciado na classe que depende para a classe sobre a qual ela depende. J as generalizaes indicam que a superclasse Object do pacote java.lang possui uma sub-classe que a classe ServidorRMIServer. O funcionamento da subclasse dado como se a superclasse estivesse sido copiada integralmente para a subclasse. Estas definies tambm so expressas nos prximos diagramas.

70

Figura 5.2: Diagrama da Classe ServidorRMIServer e recursos usados da API JAVA.

71 Na figura 5.3 mostrado o diagrama da classe ServidorRMI que efetivamente executa os mtodos anunciados na classe de interface remota. A subclasse ServidorRMI herda o comportamento da superclasse UnicastRemoteObject, pertencente ao pacote java.rmi.server, e faz a utilizao dos recursos disponibilizados pelos mtodos e variveis RemoteException. da classe

Figura 5.3: Diagrama da Classe ServidorRMI e recursos usados da API JAVA

72 Na figura 5.4 mostrado o diagrama da classe InterfaceRMI, que executa a comunicao entre o cliente e o servidor na manipulao do brao mecnico. Esta classe herda as caractersticas da classe Remote, pertencente ao pacote RMI e tambm, faz o uso dos mtodos e variveis da classe RemoteException.

Figura 5.4: Diagrama da Classe InterfaceRMI e recursos usados da API JAVA

73 A figura 5.5 mostra a que a classe ControlaMotores herda o comportamento da classe Object do pacote lang,e faz uso dos recursos oferecidos por mtodos e variveis das classes String e System.

Figura 5.5: Diagrama da Classe ControlaMotores e recursos usados da API JAVA

Na figura 5.6 mostrado o diagrama da classe SwingCapture, que se encarrega da aquisio das imagens atravs da webcam e a formatao dos dados em seu formato especfico. A classe SwingCapture utiliza-se das caractersticas da classe Panel e faz a utilizao dos recursos dos mtodos e atributos das classes restantes do diagrama.

Figura 5.6: Diagrama da Classe SwingCapture e recursos usados da API JAVA

74 O diagrama da classe Clone, responsvel pela cpia dos frames capturados pelo dispositivo de vdeo ilustrado na figura 5.7.

75

Figura 5.7: Diagrama de Classe Clone e recursos usados da API JAVA

76 O diagrama 5.8 mostra a classe TransmiteVideo, responsvel pelo envio dos quadros capturados atravs de broadcasting para a rede de computadores.

Figura 5.8: Diagrama de Classe TransmiteVideo e recursos usados da API JAVA

77

Figura 5.9: Diagrama completo do Aplicativo Servidor.

78

A figura 5.9 mostra o diagrama de classe com o relacionamento entre as classes do aplicativo servidor.

5.6 DIAGRAMAS DE CLASSES DO APLICATIVO CLIENTE

Neste tpico so mostrados os diagramas de classes que compem o aplicativo cliente por fim o relacionamento entre as classes. A figura 5.10 mostra o diagrama da classe AbrePrograma, que chama o formulrio de principal do software de controle do rob. Este diagrama indica a existncia de uma operao chamada AbrePrograma().

Figura 5.10: Diagrama de Classe AbrePrograma.

Na figura 5.11 mostrado o diagrama da classe classeProcesso, responsvel pelo controle de mltiplas linhas de execuo (trheads), para evitar que o aplicativo no pare de responder a solicitaes do usurio. Neste diagrama podemos observar as operaes classeProcesso(), run(), readObject() e writeObject(). Todas estas operaes se encarregam do controle da execuo de mltiplas linhas de programao.

Figura 5.11: Diagrama de Classe ClasseProcesso.

79

Na figura 5.12 mostrado o diagrama InterfaceRMI, que se encontra do lado da mquina cliente e j definido na figura 5.4.

80

Figura 5.12: Diagrama de Classe InterfaceRMI do aplicativo cliente.

N figura 5.13 mostra-se o diagrama da classe FormSobre, classe responsvel pela criao do formulrio que traz as especificaes da criao do software de controle. A classe FormSobre definida com seus objetos e suas operaes, como mostra o diagrama.

81

Figura 5.13: Diagrama de Classe FormSobre.

Na figura 5.14 mostra-se o diagrama da classe FormBanco, responsvel pelo cadastro informaes em um banco de dados para a automao do rob. Esta classe herda o comportamento da classe JFrame do pacote Swing. Na figura 5.15 mostrado o diagrama de classe completo do aplicativo cliente, neste diagrama observamos todas as dependncias entre as classes participantes.

82

Figura 5.14: Diagrama de Classe FormBanco.

83

Figura 5.15: Diagrama de Classe Completo do Aplicativo Cliente

APTULO 6 TESTES DE COMUNICAO DO SOFTWARE

Neste captulo destaca-se o tempo de comunicao entre cliente e servidor na ativao

dos motores do rob SCORBOT ER III e tambm o monitoramento do trfego na rede na transmisso dos pacotes de dados.

6.1 TEMPO DE ATIVAO DOS MOTORES NA REDE

Os testes para a comunicao entre cliente e servidor foram efetuados a partir de uma funo disponvel em JAVA (System.currentTimeMillis()), o qual determinou o tempo efetivo global e individual de comunicao entre cliente/servidor na ativao dos motores em milissegundos. A figura 6.1 mostra o tempo mdio individual de ativao dos motores do brao mecnico. Vale ressaltar que as informaes ilustradas na figura 6.1, so oriundas da execuo da funo de Reset, responsvel por inicializar e posicionar as partes componentes do rob de forma adequada. As informaes foram coletadas na rede local da Faculdade de Engenharia de Ilha Solteira, onde houve a comunicao de mquinas cliente/servidor entre os computadores dos laboratrios de Circuitos Digitais - LPSSD (cliente) e o Laboratrio de Controle (servidor).

Mdia Geral de Reset por Motor para Posicionamento do rob em uma LAN (Local Area Network )
Tempo Mdio em Milissegundos 1,80E+04 1,60E+04 1,40E+04 1,20E+04 1,00E+04 8,00E+03 6,00E+03 4,00E+03 2,00E+03 0,00E+00

mdia

M ot or 1

Figura 6.1: Tempo mdio individual de ativao dos motores do brao mecnico LAN.

Es qu M er ot da or 1 M D ot ire or tit 2 a Es qu M er ot da or 2 M ot D ire or ita 3 Es qu M er ot da or 3 M D ot ire or tit 4 a Es qu M er ot da or 4 M ot D ire or ita 5 Es qu M er ot da or 5 M D ot ire or tit 6 a Es qu M er ot da or 6 M D ot ire or ita 7 Es qu M er ot da or 7 D ire ita
Motores

85

Na figura 6.2 mostrado o grfico que indica o tempo global para realizao da tarefa de Reset. Para a criao da ilustrao, foi efetuado o processo de reinicializao do brao afim, de observar a variao entre um processo e outro. Como observada, a figura 6.2 indica que o tempo global de posicionamento inicial fica em torno de 1 minuto e 34 segundos, com variaes desprezveis de forma geral.

Tempo de Reset do Posicionamento do rob em uma LAN (Local Area Network )

9,45E+04 Tempo em Milissegundos 9,45E+04 9,44E+04 9,44E+04 9,43E+04 9,43E+04 9,42E+04 9,42E+04 9,41E+04 9,41E+04 1 2 3 4 Iteraes de Reset 5 6 7 94188 94297 94297 94250 94203 94266 Tempo Total de Reset 94453

Figura 6.2: Tempo global para realizao da tarefa de Reset.

6.2 TRFEGO DE PACOTES NA REDE

Como j mencionado nos captulos anteriores, a comunicao entre cliente e servidor realizada de duas maneiras: Utilizao de conceitos RMI, para a comunicao com o servidor remoto e; Conceitos de mdia streaming para envio dos quadros de som e imagem para a mquina participante na comunicao e controle do rob.

86

Devido ao alto ndice de fluxo na rede em relao transferncia de pacotes, utilizando os protocolos TCP e UDP, procurou-se analisar os parmetros na transmisso desses dados. N figura 6.3, apresentado um grfico adquirido atravs do Gerenciador de Tarefas do sistema operacional Windows XP, onde relatada a taxa de transferncia de quadros de vdeos RTP na rede utilizada.

Figura 6.3: Utilizao da Rede com Transmisso Vdea.

Como observado, esta rede possui uma taxa de comunicao de 100 Mbps, e durante a execuo da aplicao de controle na transmisso das imagens capturadas pelo servidor mquina cliente, somente 0.45% desta banda foi utilizada. Em termos prticos, a rede operou com uma taxa real de 460,8 Kbps. J a figura 6.4, traz em seu bojo, informaes coletadas a partir da execuo do Gerenciador de Tarefas, quando a rede operava com a transmisso de pacotes de imagens

87

(UDP) capturados pela webcam do servidor e enviadas ao cliente especfico e, tambm pacotes utilizando conceitos TCP/RMI, pacotes enviados do cliente ao servidor com solicitao de execuo para movimentao de partes especficas do brao. Verifica-se que a taxa de utilizao do canal de comunicao de 100 Mbps, com o envio tanto de pacotes de vdeo RTP como de troca de mensagens RMI, ficou restrito a mdia de 0,83% de sua capacidade total, sendo assim, a taxa mdia de comunicao foi de 849,92 Kbps.

Figura 6.4: Utilizao da Rede com Transmisso RTP e RMI

As anlises esboadas pelas figuras 6.3 e 6.4 foram melhores evidenciadas atravs de um software chamado Ethereal Network Protocol Analyzer (Analizador de Protocolos de Rede), poderosa aplicao que faz anlise do trfego de dados da rede e reconhece centenas

88

de protocolos. Esta ferramenta est disponvel para as plataformas Windows, Linux, BSD e Mac.

6.3 ANLISE DOS PACOTES TCP/RMI COLETADOS NA REDE

Com a ajuda do software de anlise de trfego (Ethereal), chegaram-se aos grficos das figuras 6.5, 6.6 e 6.7. Na figura 6.5, apresentada s informaes coletadas pelo software Ethereal, dos pacotes TCP/RMI na comunicao cliente/servidor. O tempo de coleta das informaes foi de 123,281 segundos (00:02:03). Neste intervalo, foram coletados 2133 pacotes TCP/RMI perfazendo um total de 188277 bytes (183,63 Kbytes), tendo como tamanho mdio dos pacotes transmitidos de 1,49 Kbytes/s.

Tamanho Total dos Pacotes TCP/RMI Trafegados na rede com a Comunicao Cliente/Servidor
88836 90000 80000 70000 60000 50000 40000 30000 20000 10262 10000 1013 1241 1755 2101 2447 2793 2908 3079 3139 3365 3425 3485 4057 4177 4749 0 70 210 32 42 52 62 66 35 72 39 120 41 49 51 59 149 984

Tam anho dos Pacotes (Bytes)

Quantidade de Pacotes
Tamanho dos Pacotes na rede

Figura 6.5: Tamanho dos pacotes TCP/RMI na comunicao cliente/servidor.

Na figura 6.6, apresenta-se a demanda de pacotes enviados pelo servidor mquina cliente, e a quantidade de quadros enviados pelo cliente ao servidor solicitando a execuo de alguma tarefa. Estas trocas de mensagens so oriundas do protocolo TCP, que um servio confivel. Com isso, h a necessidade na troca de informaes, que o destino envie uma

89

confirmao positiva ao destinatrio para que a transmisso de novos pacotes se torne possvel. Em caso de confirmao negativa o pacote reenviado. Na figura 7.6, A representa o cliente e B o servidor. Nota-se que foram enviados 1158 pacotes ao servidor e este enviou um total de 975 pacotes ao cliente.

Direo dos Pacotes TCP/RMI na Rede na Comunicao Cliente/Servidor

Quantidade de Pacotes 1200 1100 1000 900 800 1158 975

Pacotes de A->B

Pacotes de B->A

Fluxo dos Pacotes Direo dos Pacotes na Rede

Figura 6.6: Direo dos Pacotes TCP/RMI

Na figura 6.7 ilustrado o tamanho total em bytes dos pacotes enviados do cliente A ao servidor B, e retornando estas informaes do servidor B ao cliente A.

Total de Bytes Tranferidos na Comunicao TCP/RMI Cliente Servidor

Bytes Transferidos 100000 95000 90000 85000 80000 99065 89212

Bytes A->B

Bytes B->A

Direo da Tranferncia de Bytes Total de Bytes Tranferidos

Figura 6.7: Total de bytes transferidos na comunicao TCP/RMI.

90

6.4 ANLISE DOS PACOTES UDP/RTP COLETADOS NA REDE

A transmisso dos pacotes enviados pelo servidor rede de computadores utilizando o protocolo UDP/RTP, um servio no confivel, pois, no garante a entrega dos pacotes enviados ao destino especificado. Os dados coletados na comunicao entre cliente/servidor na figura 6.8, apresenta um total de 13679 pacotes enviados, acumularam um total de 13042168 bytes transmitidos ou 12,42 Mbytes. A mdia de bytes transmitidos foi de 103,54 Kbytes/s.

Tamanho Total dos Pacotes UDP no Envio de Vdeo ao Cliente

1,40E+07 13023029

Tamanho em Bytes

1,20E+07 1,00E+07 8,00E+06 6,00E+06 4,00E+06 2,00E+06 2208 0,00E+00 24 25 86 13544 2870 14061

Pacotes Tamanho Total dos Pacotes UDP no Envio de Vdeo ao Cliente

Figura 6.8: Tamanho dos Pacotes UDP.

6.5 ANLISE DO FLUXO DE PACOTES DOS PROTOCOLOS DE COMUNICAO

A figura 6.9 apresenta o fluxo de dados obtidos na rede. Pode-se salientar que, a quantidade de dados do protocolo UDP/RTP foi mais expressiva por ser pacotes de contedo multimdia, e assim sendo, requer um canal de comunicao orientado a conexo. J o

91

protocolo TCP/RMI utiliza um canal de comunicao no orientado conexo para a troca de mensagens. O protocolo TCP/RMI precisa ser invocado para que haja troca de mensagens.

Fluxo de Pacotes na Rede com a utilizao do Software de Controle

11,99% 5,22% UDP/RTP TCP/RMI OUTROS 82,79%

Figura 6.9: Fluxo de Pacotes na rede.

Na figura 6.10 apresenta-se o fluxo global de pacotes em bytes na rede de computadores.

Fluxo de Bytes na Rede com a utilizao do Software de Controle

0,62%

1,32% Bytes UDP/RTP Bytes TCP/RMI Bytes Outros 98,07%

Figura 6.10: Fluxo de bytes na rede.

92

6.6 CONSIDERAES SOBRE O CAPTULO

Este captulo apresentou as informaes coletadas do fluxo de dados entre cliente/servidor e o tempo de acionamento dos motores utilizando o sistema de controle do SCORBOT ER III. Pode-se observar que o tempo para a execuo de uma tarefa em uma LAN se manteve desprezvel, no causando danos na operao solicitada. J o fluxo de pacotes na rede foi satisfatrio, mostrando que para uma conexo discada a transferncia de dados se tornaria insatisfatria. Assim, para o funcionamento do software necessrio um canal com uma transferncia significativa para que no haja a perda de informaes (vdeo) e nem atraso nas aplicaes (tarefas).

APTULO 7 - CONSIDERAES FINAIS

Os trabalhos e estudos realizados, que resultaram na criao do software de controle para a manipulao do brao mecnico SCORBOT ER III, envolveram o desenvolvimento de um conjunto de programas (classes JAVA e uma biblioteca dinmica dll) e um novo circuito de controle que, integrados, propiciam ao usurio controlar remotamente o dispositivo robtico atravs da porta paralela do computador. Nesta etapa, o circuito de controle seleciona qual dos motores ser ativado para movimentao, a partir da solicitao do software cliente ao servidor. Na criao deste software para a manipulao do brao mecnico, utilizaram-se tcnicas que buscaram ao mximo aumentar o grau de portabilidade do aplicativo. Entretanto, tal objetivo no foi possvel devido a no utilizao do pacote JAVAX.COMM, o qual, possui erros de implementao na sua verso atual. Assim, utilizou-se uma biblioteca dinmica DLL, feita com comandos ANSI da linguagem C++, para que o aplicativo pudesse enviar os bits necessrios porta paralela do computador para a ativao de um motor especfico, atravs do circuito de controle. A ligao desta biblioteca com a linguagem JAVA se deu atravs de mtodos nativos JNI. J a comunicao entre cliente/servidor foi implementada utilizando conceitos de mtodos remotos RMI. Para a execuo de tarefas pr-definidas pelo rob, utilizou-se conceitos de JDBC para o armazenamento de instrues que visam automatizar trajetrias de motores especficos. Por fim, monitorou-se os movimentos do brao remotamente atravs de uma WebCam Digital, utilizando o Protocolo de Tempo Real RTP da biblioteca JMF. Anlises do software indicaram que a latncia na comunicao para ativao dos motores do rob se manteve desprezvel em uma rede local. No mesmo tipo de rede a transferncia de quadros de imagens utilizando o protocolo RTP foi de boa qualidade,

94

proporcionando ao cliente uma ntida visualizao dos movimentos do rob remotamente. J em uma conexo discada, a transferncia de imagens se torna no confivel, pois, ocorre a perda de muitos pacotes na rede. Os temas relacionados comunicao remota entre dispositivos eletrnicos devem ser vistos como um lugar em destaque, no apenas para pessoas que trabalham na rea de automao, controle e informtica, mas tambm para aquelas que, de alguma forma, utilizam a robtica como ferramenta para facilitar seus trabalhos. Para trabalhos futuros prope-se: A leitura dos encoders atravs da porta paralela do computador; A criao de uma interface de cadastramento de usurio atravs da internet; Implementao multicast para o envio de imagens para um grupo de computadores pertencentes a rede; Estudo e implementao de mtodos para a visualizao do rob em profundidade atravs de espelhos; Estudo e implementao da biblioteca JAVAX.COMM para a leitura dos bits na porta paralela; Programao para desvios na deteco do sistema operacional corrente, para o contorno do problema de portabilidade entre diferentes plataformas.

REFERNCIAS BIBLIOGRFICAS

[1] K. Goldberg, K. Mascha, M. Genter, N. Rothenberg, C. Sutter, and J. Wiegley. Desktop teleoperation via the World Wide Web. In Proceedings of IEEE International Conference on Robotics and Automation, May 1995a. [2] B. Dalton, Techniques for WEB Telerobotics, Tese de Doutorado, Department of Mechanical and Materials Engineering University of Western Australia, Perth, Australia, 2001. [3] Sun Microsystems. The JAVA Tutorial. Disponvel na Internet via WWW. URL: http://JAVA.sun.com/docs/books/tutorial/index.html. [4] H. Hu, L. Yu, P. W. Tsui, and Q. Zhou, Internet-based Robotic System for

Teleoperation In International Journal of Assembly Automation, Vol. 21, No. 2, pages 143-152, 2001. [5] A. Malinowski and B. Wilamowski, Controlling Robots via Intenet, In 1 st International Conference on Information Technology in Mechatronics, Istanbul, Turkey, October 1-3, pages 101-107, 2001. [6] P. G. Backes, K. S. Tso and G. K. Tharp, The WEB Interface for Telescience, In Presence, Vol. 8, No. 5, pages 531-539, October, 1999. [7] GUARDIA, L. E., Controle de um Brao Mecnico SCORBOT III utilizando um computador PC, UNESP, Setembro, 2002. [8] http://super.abril.com.br/especiais/1197/futuro25.html. Acesso em 10/12/2005. [9] http://www.din.uem.br/ia/vida/robotica2/classif.htm. Acesso em 11/12/2005. [10] G. CORNELL, C. S. HORSTMANN, Core JAVA Vol I - Fundamentos, Editora Makron Books, So Paulo, 2003.

96

[11] GREMMELMAIER, C. H., Introduo Programao em Linguagem JAVA, Erechin, 2002. [12] Nascimento, F. A; Rodrigues, M., LINGUAGEM DE PROGRAMAO JAVA UNIVERSIDADE LUTERANA DO BRASIL, Canoas RS, 2003 [13] CHELLA, M. T., Ambiente de Robtica para Aplicaes Educacionais com SuperLogo, UNICAMP, Campinas, SP, 2002. [14] CORNELL, C. S. HORSTMANN, Core JAVA Vol II - Recursos Avanados, Editora Makron Books, So Paulo, 2003. [15] J. D. Ringgenberg, Object-Oriented Design of Portable Control System Software. Tese de Mestrado, Mechanical Engineering, University of California Berkeley, Spring 2001. [16] DEL CID PORTILLO, J. Parallel printer port access through. Disponvel em <http://www.geocities.com/juanga69/parport/>.Acesso em 2005. [17] MECATRNICA FCIL. Utilizando o logo em windows 2000, NT e XP. Disponvel em: <http://www.mecatronicafacil.com.br/downloads/logo_instr.htm>.Acesso em 2005. [18] JAVA Media FrameWork API guide Sun Microsystems, 1999. [19] Booch, G.; Rumbauch, J.; Jacobson, I., The Unified Modeling Language User Guide, Addison Wesley, 1998. [20] http://pt.wikipedia.org/wiki/Diagrama_de_objetos. Acesso em 05/01/2006.