manipulação robótica na educação a distância · trabalho de graduação manipulação...
TRANSCRIPT
Trabalho de Graduação
Manipulação Robótica na Educação a Distância
Diogo Gomes de Oliveira 610429
Prof. Dr. Luiz Carlos Rosa
Prof. Dr. Galdenoro Botura Jr.
SOROCABA
2011
2
DIOGO GOMES DE OLIVEIRA
Manipulação Robótica na Educação a Distância
Trabalho de graduação apresentado ao Conselho de
Curso de Engenharia de Controle e Automação,
Universidade Estadual Paulista “Júlio de Mesquita
Filho”, como requisito parcial para a obtenção do
grau de Engenheiro de Controle e Automação.
Orientador: Dr. Luiz Carlos Rosa
Co-orientador: Prof. Dr. Galdenoro Botura Jr.
SOROCABA
2011
3
FICHA CATOLOGRÁFICA
Oliveira, Diogo G.
Manipulação Robótica na Educação a Distância – Sorocaba, 2011.
Nº de páginas
Orientador: Prod. Dr. Luiz Carlos Rosa
Co-orientador: Prof. Dr. Galdenoro Botura Jr.
Trabalho de Graduação – UNESP Universidade Estadual Paulista “Júlio
de Mesquita Filho”
1.Educação a Distância; 2.Automação Industrial; 3.Programação em
Blocos - LabView; 4.Protocolos Industriais OPC e TCP/IP
4
AGRADECIMENTOS
Aos meus companheiros de república e grandes amigos, que me ensinaram
muito nesses cinco anos e sem os quais o desenvolvimento desse trabalho não
teria sido possível.
Aos professores Dr. Luiz Carlos Rosa e Dr. Galdenoro Botura Jr., pelas
sábias e inspiradoras orientações durante os cinco anos de graduação.
Aos meus familiares e amigos, pela compreensão e apoio incondicional
durante o tempo que me dediquei a esse projeto.
À Deus, por me dar forças e coragem em todos os momentos de fraqueza e
desânimo.
5
Sumário
LISTA DE ILUSTRAÇÕES .......................................................................................................................... 7
RESUMO ................................................................................................................................................ 8
ABSTRACT .............................................................................................................................................. 9
1 OBJETIVO .......................................................................................................................................... 10
2 INTRODUÇÃO .................................................................................................................................... 10
3 PROPOSTA DO PROJETO ................................................................................................................... 12
3.1 MOTIVAÇÃO......................................................................................................................................... 13
4 BIBLIOGRAFIA FUNDAMENTAL.......................................................................................................... 14
4.1 HISTÓRICO ........................................................................................................................................... 14
4.2 PROGRESSO ATUAL ................................................................................................................................ 15
4.3 CONCEITOS DE EAD ............................................................................................................................... 16
4.3.1 E-learning .................................................................................................................................. 16
4.3.2 Ambiente Virtuais de Aprendizagem (AVAs) ............................................................................. 17
4.3.3 Telerobótica .............................................................................................................................. 19
4.3.4 Aplicação da Telerobótica ......................................................................................................... 20
4.4 TRABALHOS CORRELATOS ....................................................................................................................... 20
4.4.1 RemoteBot.net [ http://www.remotebot.net/] ........................................................................ 20
4.4.2 Telegarden [http://telegarden.oec.ot/] .................................................................................... 21
4.4.3 Bigsignal 2000 [http://www.bigsignal.net/2000/index2.html] ................................................ 21
4.4.4 Telelab [Casini, Prattichizzo e Vicino 2002]............................................................................... 21
4.4.5 AIM [Shen at all 1999] .............................................................................................................. 22
4.4.6 SIROS [D’Abreu e Chella, 2003] ................................................................................................. 22
5 BASE TEÓRICA ................................................................................................................................... 23
5.1 PROTOCOLO OPC [OPC FUNDATION, 2010] ............................................................................................. 23
5.2 PROTOCOLO TCP/IP [TANENBAUM, 2003] ............................................................................................... 26
5.2.1 Introdução................................................................................................................................. 26
5.2.2 Camadas de Aplicação .............................................................................................................. 28
5.2.2 CAMADAS DE TRANSPORTE .................................................................................................................. 29
5.2.3 Camadas de Internet ................................................................................................................. 31
5.2.4 Camadas Interface com a Rede ................................................................................................ 35
5.3 LABVIEW (NATIONAL INSTRUMENTS) ........................................................................................................ 37
5.3.1 Introdução................................................................................................................................. 37
5.3.2 LabVIEW – IMAQ....................................................................................................................... 39
5.3.3 LabVIEW Datalogging and Supervisory Control (DSC) Module ................................................. 41
6 ESPECIFICAÇÕES ................................................................................................................................ 41
6.1 ESPECIFICAÇÕES DO SISTEMA ................................................................................................................... 41
6.1.1 O Modelo Utilizado ................................................................................................................... 41
6.1.2 Representação Esquemática do Sistema .................................................................................. 43
6.2 ESPECIFICAÇÕES DA APLICAÇÃO................................................................................................................ 45
6
7 DESENVOLVIMENTO DO PROJETO..................................................................................................... 46
7.1 ESTAÇÃO SERVIDOR ............................................................................................................................... 46
7.1.1 Construção Lógica ..................................................................................................................... 47
7.1.2 Telas Gráficas e Modo de Operação ......................................................................................... 51
7.2 ESTAÇÃO CLIENTE .................................................................................................................................. 53
7.2.1 Construção Lógica ..................................................................................................................... 53
7.2.2 Telas Gráficas e Modo de Operação ......................................................................................... 62
8 RESULTADOS E DISCUSSÕES .............................................................................................................. 64
8.1 TESTES DO OPC NO LABVIEW .................................................................................................................. 64
8.2 TESTES DA INTERFACE............................................................................................................................. 64
8.3 TESTES DA COMUNICAÇÃO COM DISPOSITIVOS USB .................................................................................... 65
8.3 TESTES DA COMUNICAÇÃO TCP/IP........................................................................................................... 65
9 CONCLUSÃO ...................................................................................................................................... 66
10 REFERÊNCIAS BIBLIOGRÁFICAS ....................................................................................................... 69
APÊNDICE A – CÓDIGO FONTE DA ESTAÇÃO SERVIDOR ....................................................................... 71
APÊNDICE B – CÓDIGO FONTE DA ESTAÇÃO CLIENTE ........................................................................... 71
7
LISTA DE ILUSTRAÇÕES FIGURA 1 - LABORATÓRIO DE TELEROBÓTICA DO AMBIENTE SIROS. ......................................................................... 23
FIGURA 2 - ARQUITETURA DO TCP/IP. ................................................................................................................ 27
FIGURA 3 - COMO A CAMADA DE APLICAÇÃO FUNCIONA. ........................................................................................ 29
FIGURA 4 - PACOTE DE DADO NA CAMADA DE TRANSPORTE. .................................................................................... 31
FIGURA 5 - DATAGRAMA NA CAMADA DE INTERNET. .............................................................................................. 33
FIGURA 6 - FRAGMENTAÇÃO DE DATAGRAMA. ...................................................................................................... 35
FIGURA 7 - ARQUITETURA DO ETHERNET. ............................................................................................................. 35
FIGURA 8 - QUADRO NA CAMADA DE INTERFACE COM A REDE. ................................................................................. 37
FIGURA 9 - MODELO GENÉRICO DE UM SOFTWARE DE AQUISIÇÃO DE IMAGENS. ........................................................... 40
FIGURA 10 – ARQUITETURA DO SISTEMA PROPOSTO.............................................................................................. 42
FIGURA 11 - REPRESENTAÇÃO DO FUNCIONAMENTO DO PROGRAMA......................................................................... 44
FIGURA 12 - ESTRUTURA LÓGICA DO SERVIDOR. .................................................................................................... 48
FIGURA 13 - INICIALIZAÇÃO DO SERVIDOR. ........................................................................................................... 49
FIGURA 14 - PROGRAMAÇÃO DE LAÇO DO SERVIDOR. ............................................................................................. 50
FIGURA 15 - TELA DO SERVIDOR......................................................................................................................... 52
FIGURA 16 - ESTRUTURA LÓGICA DO CLIENTE. ...................................................................................................... 54
FIGURA 17 - INICIALIZAÇÃO DO CLIENTE. ............................................................................................................. 55
FIGURA 18 - PROGRAMAÇÃO DE LAÇO DO CLIENTE. ............................................................................................... 56
FIGURA 19 - AQUISIÇÃO DE DADOS INICIAIS. ......................................................................................................... 57
FIGURA 20 - AQUISIÇÃO DE DADOS PELO CLIENTE. ................................................................................................. 58
FIGURA 21 - IDENTIFICAÇÃO DO JOYSTICK. ............................................................................................................ 58
FIGURA 22 - DECODIFICAÇÃO DO PAINEL DE CONTROLE. ......................................................................................... 59
FIGURA 23 - DECODIFICAÇÃO DO JOYSTICK. .......................................................................................................... 60
FIGURA 24 - MAPEAMENTO DO JOYSTICK. ............................................................................................................ 60
FIGURA 25 - DIAGRAMA DO MODO AUTOMÁTICO................................................................................................. 61
FIGURA 26 - INTERFACE GRÁFICA DO CLIENTE. ...................................................................................................... 62
8
RESUMO Este trabalho apresenta a proposta, justificativas, especificações e
desenvolvimento de uma aplicação de monitoramento e controle de um robô,
voltado à Educação a Distância (EaD), com interface intuitiva desenvolvida a partir
da linguagem de blocos através da plataforma “LabView”. A aplicação proposta é
capaz de controlar os movimentos do robô e programar sua rotina. A partir das
alterações realizadas pelo usuário em um terminal remoto, o software envia os
dados por meio da internet para um computador conectado ao robô, o qual recebe
os dados do computador local e realiza a tarefa programada.
9
ABSTRACT This essay presents the proposal, justification, specification and development of a
software to monitor and control a robot, designated to Distance Education (DE),
with an intuitive interface developed from the language of blocks thought the
platform "LabView". The proposed software is able to control the robot's
movements and plan it´s routine. Throughout the alterations performed by the user
at a remote terminal, the software sends the data via Internet to a computer
connected to the robot, which receives the data from the local computer and
performs the scheduled task.
10
1 OBJETIVO O intuito desse trabalho é apresentar o desenvolvimento de uma aplicação
capaz de controlar um robô remotamente, favorecendo a área de educação a
distância, pois com essa tecnologia equipamentos de salas de laboratórios de
controle, robótica, entre outras poderão ser controladas remotamente, construindo
também o aprendizado de alunos que não têm recursos ou acessibilidade à salas
especializadas como as citadas.
2 INTRODUÇÃO A educação a distância (EaD) vem tornando-se cada vez mais viável com a
inclusão digital, aproximando cada vez mais pessoas da possibilidade de
especialização e aumentando as oportunidades (Landim, 1997). Neste trabalho
elucidou-se como a automação tem um papel importante no desenvolvimento
desta área de ensino, agregando conhecimentos de escala laboratorial e levando
pesquisas a patamares elevados de distribuição. Hoje, conhecer e saber usar um
novo recurso tecnológico significa acesso, difusão e produção de conhecimento.
Educação a distância, também chamada de teleducação, por vezes
designada erradamente por ensino a distância, é a modalidade de ensino que
permite que o aprendiz não esteja fisicamente presente em um ambiente formal de
ensino-aprendizagem, assim como, permite também que faça seu auto estudo em
tempo distinto. Diz respeito também à separação temporal ou espacial entre o
professor e o aprendiz (Fredric, 2009).
A interligação (conexão) entre professor e aluno se dá por meio de
tecnologias, principalmente as telemáticas, como a Internet, em especial as
hipermídias, mas também podem ser utilizados o correio, o rádio, a televisão, o
vídeo, o CD-ROM, o telefone, o fax, o celular, o iPad, o notebook, entre outras
tecnologias semelhantes.
Na expressão, educação a distância, a ênfase é dada ao papel do professor
(como alguém que ensina a distância). O termo educação é preferido por ser mais
abrangente, embora nenhuma das expressões seja plenamente completa.
11
Atualmente, esta tecnologia é muito utilizada como via de inserção do aluno em
ambientes de simulação.
Na medida em que avançam as tecnologias de comunicação virtual (que
conectam pessoas que estão distantes fisicamente como a Internet,
telecomunicações, videoconferência, redes de alta velocidade) o conceito de
presencialidade também se altera. Pode ter professores externos compartilhando
determinadas aulas, um professor de fora "entrando" com sua imagem e voz, na
aula de outro professor. Haverá, assim, um intercâmbio maior de saberes,
possibilitando que cada professor colabore, com seus conhecimentos específicos,
no processo de construção do conhecimento, muitas vezes a distância (Landim,
1997).
Os conceitos de curso e de aula também mudam. Hoje, ainda entende-se
por aula um espaço e um tempo determinados. Mas, esse tempo e esse espaço,
cada vez mais, serão flexíveis. O professor continuará "dando aula", e enriquecerá
esse processo com as possibilidades que as tecnologias interativas proporcionam:
para receber e responder mensagens dos alunos, criarem listas de discussão e
alimentar continuamente os debates e pesquisas com textos, páginas da Internet,
até mesmo fora do horário específico da aula. Há uma possibilidade cada vez mais
acentuada de estarmos todos presentes em muitos tempos e espaços diferentes.
Assim, tanto professores quanto alunos estarão motivados, entendendo "aula"
como pesquisa e intercâmbio. Nesse processo, o papel do professor vem sendo
redimensionado e cada vez mais ele se torna um supervisor, um animador, um
incentivador dos alunos na instigante aventura do conhecimento (Landim, 1997).
Tirando o paradigma de que todo educação a distância consistem em uma
passagem de conhecimento puramente teórico, contendo somente em seus
exemplos aplicações práticas. Com as novas tecnologias, pode-se levar ao aluno
ferramentas de manipulação prática, aplicando todo o conteúdo aprendido, com a
utilização de uma interface virtual é possível aproximar ao máximo os conceitos
teóricos com experiências práticas, antes impossíveis de serem realizadas no
conceito de educação a distância, por meio de mídias sem interação em tempo
real.
12
Este texto pretende analisar a educação a distância como uma nova
possibilidade de educação que acontece através de novas experiências e técnicas
de manipulação de elementos práticos a distâncias. Não apenas como um modo
diferente de ensinar e aprender, mas como uma aprendizagem necessária para a
atuação dos indivíduos no mundo contemporâneo já transformado pelas
tecnologias.
A robótica é um meio de possibilitar o desenvolvimento de projetos
tecnológicos e educacionais, envolvendo técnicas de construção e manipulação de
robôs e possibilitando o avanço do processo criativo, raciocínio lógico, a
interdisciplinaridade em diferentes áreas. Exemplos de atividades são o projeto e
criação de robôs, a programação de softwares, trabalhos em eletrônica e redes de
computadores.
Aplicado como ferramenta de apoio ao processo ensino/aprendizagem, o
uso das tecnologias de informação e comunicação descreve um mecanismo que
estrutura-se em práticas escolares na tentativa de disseminar um campo de
possibilidades pouco exploradas em instituições de ensino no Brasil (Villaplana,
2002).
3 PROPOSTA DO PROJETO O trabalho aqui apresentado visa o desenvolvimento de uma aplicação
intuitiva e de fácil operação, voltada para a educação à distância e que permita ao
aluno controlar as variáveis do robô e realizar uma rotina para ser seguida. Sob o
ponto de vista do status, o aluno terá acesso a uma câmera de monitoramento
para facilitar assim a visualização em tempo real da manipulação do robô e uma
interface textual para enviar e receber mensagens com quem estiver junto do robô.
A aplicação permitirá a manipulação dessas variáveis através da atuação direta do
usuário, por comandos executados através do programa, ou de forma indireta, com
o auxilio de um joystick, controle comum de um vídeo game com entrada USB,
assim o aluno poderá desenvolver a sensibilidade necessária para operar um robô
industrial, caso utilize sua console de operação nativa.
Estruturalmente, o desenvolvimento de toda a aplicação é proposta com
base na linguagem de blocos do LabView, a fim de explorar os recursos e
13
facilidades que essa plataforma pode apresentar no desenvolvimento de
aplicações no campo da educação a distância.
Os comandos executados pelo usuário são recebidos pela aplicação e
enviados através da Internet, e recebidos por outro computador, que por sua vez
os envia ao robô. Ao propor esse tipo de comunicação, tem-se como principal
intuito levar o ensino desta modalidade às diversas regiões do país.
Dessa forma, através dos recursos de controle e monitoramento da
aplicação, os alunos poderão de uma forma prática e rápida, conhecer e atuar
sobre as características do robô, realizar tarefas propostas por um exercício típico
e entender sobre as limitações e áreas de atuação do manipulador.
3.1 Motivação
Levando em consideração a crescente vertente que é a educação à
distância, as barreiras que este novo conceito ainda tem que quebrar e carências a
suprir, este trabalho tem como proposta difundir o conteúdo prático vinculado aos
meios do EaD, no que se refere ao ensino tecnológico.
É inegável que a Educação a Distância (EAD) está em processo de
expansão e a tendência é que cresça ainda mais. Um dos motivos que acelera o
avanço desta modalidade de ensino é a apropriação das novas tecnologias e
meios de comunicação, ferramentas essenciais para o desenvolvimento dos
cursos.
Tendo isto em mente nota-se que uma das grandes barreiras do EaD em
relação aos cursos mais técnicos é a falta de interatividade com o que é aprendido
na teoria e sua respectiva aplicação na prática. No caso abordado aqui se
enquadra os conceitos de manipuladores robóticos, os quais apresentados
somente com conteúdo teórico pouco valor agrega aos alunos, pois uma carga
matemática muito pesada é transmitida neste curso quando aplicado
presencialmente. Para que este conceito se fixe melhor, aulas práticas devem ser
aplicadas, entretanto está prática se torna difícil de ser realizada num curso a
distância, sendo este um dos motivos da elaboração deste projeto.
Outro ponto importante para ser ressaltado é a utilização de manipuladores
atualmente utilizados nas indústrias, sendo que o conteúdo apresentado ao aluno
14
será atual e condizente com a vivência que o mesmo terá no mercado de trabalho.
Além disso, a aplicação proposta pode ser adaptada para outros manipuladores de
diversos fabricantes, pois a comunicação da aplicação com o robô é baseada no
protocolo OPC, que será detalhado na secção “Revisão Teórica”.
Do ponto de vista das instituições de ensino e do aluno nota-se uma
motivação econômica maior que as demais, pois para a instituição um novo curso
poderá ser agregado à sua gama de ensino, aumentando seu número de alunos e
melhorando o faturamento econômico e cientifico com publicações sobre essa
nova tecnologia. Já o aluno, terá a oportunidade de aprender um curso aonde a
mão de obra qualificada está escassa no mercado de trabalho, e aliado a lei da
oferte e procura, profissionais que detém o conhecimento solicitado tem a
remuneração salarial muito maior, proporcional à sua capacitação.
Outro fator importante é que nem todas as instituições de ensino
contemplam a posse destes manipuladores, pois o custo de aquisição é muito
elevado. Sendo assim, com a aplicação desenvolvida, poderá haver uma parceria
entre instituições de ensino ou entre instituição e empresas privadas, para que o
equipamento presente somente em um local seja compartilhado, visando um ponto
em comum: formar profissionais melhores e mais capacitados.
4 BIBLIOGRAFIA FUNDAMENTAL
4.1 Histórico
Inicialmente na Grécia antiga e depois em Roma, existiam redes de
comunicação que permitiam o desenvolvimento significativo da correspondência e,
por consequência, a troca de informações, no entanto as primeiras manifestações
de aprendizado se deram com a revolução científica iniciada no século XVII, onde
cartas comunicando informações científicas ilustrvam de maneira precoce uma
maneira de aprendizado alternativa. Um primeiro marco da educação a distância
foi o anúncio publicado na Gazeta de Boston, no dia 20 de março de 1728, pelo
professor de taquigrafia Cauleb Phillips: "Toda pessoa da região, desejosa de
aprender esta arte, pode receber em sua casa várias lições semanalmente e ser
perfeitamente instruída, como as pessoas que vivem em Boston" (Educação a
Distância, Como e onde surgiu?).
15
No século XIX, mais precisamente em 1856, foi fundada a primeira escola
de ensino por correspôndencia destinada ao ensino de letras em Berlim. Com o
avanço da humanidade a demanda por educação se tornou cada vez maior e, para
atender a esta demanda, os países começaram a desenvolver sistemas de
educação a distância. Na história recente, os equipamentos mais utilizados para a
difusão foram o rádio, a televisão e o videocassete. Atualmente, o ensino não
presencial mobiliza os meios pedagógicos de quase todo o mundo, tanto em
nações industrializadas quanto em países em desenvolvimento. Novos e mais
complexos cursos são desenvolvidos, tanto no âmbito dos sistemas de ensino
formal quanto nas áreas de treinamento profissional (Educação a Distância,
Wikipédia).
A educação a distância foi utilizada inicialmente como recurso para
superação de deficiências educacionais, para a qualificação profissional e
aperfeiçoamento ou atualização de conhecimentos. Hoje também, foi cada vez
mais usada em programas que complementam outras formas tradicionais, face a
face, de interação, e é vista por muitos como uma modalidade de ensino
alternativo que pode complementar parte do sistema regular de ensino presencial.
Por exemplo, a Universidade Aberta oferece comercialmente somente cursos a
distância, sejam cursos regulares ou profissionalizantes. A Virtual University
oferece cursos gratuitos (Educação a Distância, Como e onde surgiu?).
4.2 Progresso Atual
Nesta secção são apresentados, inicialmente, conceitos de ensino a
distância. Posteriormente apresentar-se-ão alguns desses sistemas já disponíveis
no mercado e aplicações semelhantes ao aqui sugerido, que comandam
dispositivos robóticos voltados para a EaD.
A princípio necessita-se saber e entender os princípios de uma EaD, qual a
finalidade e quanto fiel deve ser o conteúdo passado aos alunos e depois como
avaliar esse conteúdo absorvido. Existem diversas técnicas de como abordar o
tema da educação a distancia e diferentes conceitos, aqui serão apresentados as
de E-Learning, Ambientes Virtuais de Aprendizagem (AVAs) e Telerobótica, mas
todos eles têm o mesmo objetivo em comum, levar o ensino em massa para
pessoas que não têm acesso aos locais onde estão essas informações.
16
Posteriormente serão apresentados os projetos já em execução, alguns
exemplos serão citados e melhor explicados para se ter uma visão geral do que já
está implantado no campo da EaD, auxiliando não somente uma disciplina, mas
contribuindo muito no campo da interdisciplinaridade, fazendo com que o aluno
tome conhecimento de outras ferramentas utilizadas em outros cursos e que
podem auxiliá-lo muito na sua área de atuação, além disso há a
intercomunicabilidade, onde alunos e professores de cursos distintos podem
compartilhar assuntos de interesse, tirar dúvidas entre si e até formar grupos de
discussão a fim de chegar numa melhor transmissão dos conteúdos.
4.3 Conceitos de EaD
4.3.1 E-learning
O termo e-Learning corresponde a um modelo de ensino não presencial
suportado por tecnologia. Atualmente, o modelo de ensino/aprendizagem assenta
no ambiente online, aproveitando as capacidades da Internet para comunicação e
distribuição de conteúdos. Desta forma, o e-learning aumentou as possibilidades
de difusão do conhecimento e da informação para os alunos e tornou-se uma
forma de democratizar o saber para as camadas da população com acesso às
novas tecnologias, permitindo que o conhecimento esteja disponível a qualquer
hora e em qualquer lugar (Wikipédia, E-learning).
Outra definição simples para e-learning é: "o processo pelo qual o aluno
aprende através de conteúdos colocados no computador e/ou Internet e em que o
professor, se existir, está à distância, utilizando a Internet como meio de
comunicação (síncrono ou assíncrono) podendo existir sessões presenciais"
(Wikipédia, E-learning).
A fim de apoiar o processo foram desenvolvidos Sistemas de Gestão de
Aprendizagem (Learning Management System ou LMS, no original). São
aplicações projetadas para funcionarem como salas de aula virtuais, gerando
várias possibilidades de interação entre os seus participantes (Wikipédia, e-
Learning). Em particular, os processos de interação em tempo real passaram a ser
uma realidade, permitindo que o aluno tenha contato imediato com o professor e
com outros alunos. As vantagens de se utilizar um LMS são:
Convergente com as necessidades dos alunos;
17
Rápida atualização dos conteúdos;
Personalização dos conteúdos transmitidos;
Facilidade de acesso e flexibilidade de horários;
O ritmo de aprendizagem pode ser definido pelo próprio
utilizador/aluno;
Disponibilidade permanente dos conteúdos da formação;
Custos menores quando comparados à formação convencional;
Redução do tempo necessário para o aluno;
Possibilidade de formação de um grande número de pessoas ao
mesmo tempo;
Diversificação da oferta de cursos;
Facilidade de cobertura de públicos geograficamente dispersos;
Registro e possibilidade de acompanhamento detalhado da
participação dos alunos;
Redução de custos logísticos e administrativos (deslocamentos,
alimentação,etc);
Desenvolvimento de capacidades de auto-estudo e auto-
aprendizagem.
4.3.2 Ambiente Virtuais de Aprendizagem (AVAs)
Os Ambientes Virtuais de Aprendizagem, conhecido como AVAs, são
softwares desenvolvidos sobre uma metodologia pedagógica para auxiliar a
promoção de ensino e aprendizagem virtual ou semi-presencial, alguns softwares
conhecidos são o Blackboard e o Moodle. Estes tipos de software permitem
interação em tempo real via internet através do envio de mensagensm, bate-papo,
envio e recepção de materiais e também são capazes de realizar a gestão de
tarefas em ambientes virtuais e físicos (Santos, 2003). As principais características
destes sistemas são:
18
Custos de formação reduzidos;
Disponibilidade a qualquer hora e local;
Possibilidade de aumento das competências dos empregados.
Diminui os custos com o pessoal.
Gestão das ferramentas de aprendizagem em conjunto com as metas dos
recursos humanos.
Mas como todo novo método de ensino, os AVAs também têm aspectos
negativos, que se manifestam principalmente das seguintes maneiras:
Problemas técnicos;
Dificuldades de adaptação a ferramenta e ao ambiente digital;
Necessidade de maior esforço para motivação dos alunos;
Exigência de maior disciplina e auto-organização por parte do aluno;
A criação e o preparação do curso on-line é, geralmente, mais demorada do
que a do presencial;
Não gera a possibilidade da existência de cumplicidades e vínculos
relacionais, que somente o processo de interação presencial permite;
O custo de implementação da estrutura para o desenvolvimento programa
de e-Learning ainda é alto;
Dificuldades técnicas relativas à Internet e à velocidade de transmissão de
imagens e vídeos;
Limitações em alcançar objetivos na área afetiva e de atitudes, pelo
empobrecimento da troca directa de experiência entre professor e aluno.
Um aspecto muito relevante na utilização de softwares de gestão de
ambientes virtuais é a crescente interatividade que os mesmos proporcionam. Ao
utilizar estas ferramentas é possível seguir uma linha de pesquisa de modo
independente entre professor e aluno. As atividades e experimentos podem ser
19
criados online e personalizados para cada aluno, e o ambiente, ao ser
programado, dá relevância inclusive ao grau de escolaridade e a cultura do
ambiente em que está sendo utilizado (Santos, 2003).
4.3.3 Telerobótica
Uma primeira abordagem é entender o sistema de telerobótica, que é nada
mais que a utilização da robótica pedagógica, como sendo uma ambiente de
ensino-aprendizagem do qual faz parte o professor, aluno e ferramentas que
possibilitam a montagem, automação e controle de dispositivos robóticos via
computador no modo presencial. Integrando à robótica pedagógica os recursos da
rede Internet de modo a permitir com que a automação e o controle dos
dispositivos passem a ser realizados na Internet é chamado de telerobótica.
No contexto de uso pedagógico da rede Internet entende-se a telerobótica
como sendo um ambiente de aprendizagem a distância que, utilizando-se das
técnicas de teleoperação e telemonitoração possibilita que uma ou mais pessoas
que estejam em locais distantes projetarem-se virtualmente em um espaço remoto
comum, com o poder de monitorar e atuar em tal espaço controlando dispositivos
tais como: braço mecânico, tartaruga de solo, andróides, dentre outros. É no
processo de controle desses dispositivos robóticos que se espera que ocorra o
aprendizado. No ambiente de telerobótica, ao desenvolver uma atividade no
laboratório um usuário estará interagindo com todos os outros que estiverem
conectados naquele instante. Isso faz com que a sua idéia seja compartilhada com
os demais, permitindo que o diálogo e cooperação sejam praticados
interdisciplinarmente de forma muito ampla (Garcia, 1995). Com isso, o número de
sugestões para a resolução de um determinado problema também aumenta. Caso
essas sugestões contribuam para que diferentes pontos de vista sejam
apresentados na resolução do problema, esse ambiente pode se transformar em
um espaço para aprendizagem colaborativa com características interdisciplinares.
Portanto, alunos e professores interagindo entre si e com essas
ferramentas produzem novos conhecimentos caracterizando esse ambiente como
um ambiente pedagógico que não existe a priori. Desse cenário podem fazer parte
dispositivos como montagens LEGO, manipulador robótico, robô móvel, tartaruga
mecânica de solo, Traçador Gráfico educacional e outros.
20
4.3.4 Aplicação da Telerobótica
Existem diferentes aplicações da telerobótica desenvolvidas para as áreas
de: medicina, exploração espacial, fins comerciais, industriais, dentre outros. Um
dos ganhos do uso da telerobótica no contexto educacional está na possibilidade
de se explorar/utilizar recursos semelhantes aos utilizados nessas áreas de
conhecimento em uma sala de aula. Isso permite criar um ambiente educacional
com alto padrão de qualidade, a baixo custo, com possibilidades de atender um
grande número de alunos que podem estar geograficamente localizados em
qualquer ponto do planeta (D’Abreu e Chella, 2003).
Assim como a utilização das ferramentas de hardware e de software têm
possibilitado desenvolver metodologias de ensino-aprendizagem baseadas no uso
do computador, a telerobótica oferece novas perspectivas para inserção de novas
tecnologias ao processo de ensino-aprendizagem. (D’Alessandro & Induni, 1998).
Do ponto de vista pedagógico acreditamos que todo o aprendizado possível de ser
realizado no ambiente presencial, poderá ser propiciado também a distância, numa
abordagem em que diferentemente da sala de aula tradicional, engloba
comunicação e conhecimento baseado na liberdade, na pluralidade e na
cooperação de forma mais ampla possível (Silva, 2000). Associa-se também a
este fato, a liberdade do aprendizado passar a acontecer em função do ritmo e
disponibilidade de tempo do aluno.
4.4 Trabalhos Correlatos
4.4.1 RemoteBot.net [ http://www.remotebot.net/]
No período de 1997 a 2000 pesquisadores do Swiss Federal Institute of
Technology, desenvolveram trabalhos relacionados ao controle de robôs
remotamente por meio da rede Internet. Os experimentos utilizavam-se de robôs
móveis Khepera produzidos pela empresa Suíça K-team. Os recursos de software
utilizados foram o Personal WEB Server da Microsoft e aplicativos desenvolvidos
em JAVA.
Estes experimentos deram origem a um pacote disponível comercialmente
constituído de software e hardware que possibilita a montagem de um sistema
completo para controle e monitoramento de robôs via WEB.
21
4.4.2 Telegarden [http://telegarden.oec.ot/]
O projeto Telegarden foi desenvolvido pela University of Southern Califórnia
e está disponível desde 1995. Este projeto de Telerobótica permite aos usuários a
visualização e interação remota com um jardim constituído de plantas, um
manipulador robótico industrial e câmeras de vídeo.
A interface com o usuário ocorre por meio de um navegador WEB e é
composta por uma janela para visualização do jardim e por um gráfico que
representa os movimentos do manipulador robótico.
4.4.3 Bigsignal 2000 [http://www.bigsignal.net/2000/index2.html]
Este projeto foi baseado no experimento de telerobótica desenvolvido pela
NASA denominado NOMAD e era constituído de um robô móvel que se deslocava
pelo continente Antártico em busca de meteoritos. O projeto Bigsinal propiciou que
alunos de diversas escolas norte americanas acompanhassem os dados
provenientes do robô em tempo real, de forma semelhante às obtidas pelos
cientistas. Uma agenda de trabalho incluía as atividades para:
Obtenção de informações sobre robótica, o continente Antártico, meteoritos
e a missão NOMAD
Organização dos grupos de trabalho e contato com o ambiente de controle
de robô na WEB.
Interação com os dados provenientes do robô como vídeo transmitido do
local, informações dos sensores e instrumentos.
Análise e elaboração de relatórios com as informações obtidas.
Os trabalhos eram realizados a partir de um site na WEB onde os alunos
podiam comunicar-se e acessar a base de dados do projeto.
4.4.4 Telelab [Casini, Prattichizzo e Vicino 2002]
O laboratório físico é constituído de sistemas hidráulicos, motores de
corrente contínua e um levitador magnético. A interação com o usuário/aluno
ocorre por meio de um navegador Web. Ao terminar o experimento um conjunto de
dados é apresentado por meio de uma interface gráfica.
22
4.4.5 AIM [Shen at all 1999]
Tendo como aplicação a caracterização de dispositivos semicondutores, é
implementado seguindo o modelo Cliente/Servidor sendo constituído de um
servidor no qual estão instalados equipamentos que se comunicam por meio do
padrão GPIB. O usuário/aluno acessa esses instrumentos para envio e
recebimento de dados por meio de um navegador Web.
4.4.6 SIROS [D’Abreu e Chella, 2003]
O ambiente telerobótica denominado Sistemas Robóticos com SuperLogo -
SIROS integra em um mesmo ambiente a construção de dispositivos,
programação destes dispositivos com o SuperLogo e controle dos mesmos via
Internet. A idéia de implementação do ambiente de SIROS está centrada na
disponibilização de um ambiente acessível à todos os usuários da rede Internet.
No SIROS, comandar um dispositivo propicia condições para aprendizado de
conceitos de programação e controle, uma vez que o usuário, não só elabora a
seqüência de comandos que o dispositivo deve executar como também visualiza
os movimentos do dispositivo. Isso tudo numa "conversa" interativa mantida on-line
com o laboratório onde o dispositivo está localizado.
São utilizados para a construção dos dispositivos Kits da LEGO Data que
consistem em uma série de peças mecânicas, motores sensores e lâmpadas que
permitem montar mecanismos que se movimentam. Além disso, são utilizados
outros tipos de materiais e componentes eletro/eletrônicos genéricos. O
SuperLogo é uma versão do Logo desenvolvido pelo NIED/UNICAMP.
Compõe ainda o ambiente de telerobótica SIROS um computador PC que
atua como servidor e uma câmera de vídeo que captura os movimentos do
dispositivo robótico que está sendo controlado remotamente, conforme a figura a
seguir.
23
Figura 1 - Laboratório de Telerobótica do Ambiente SIROS.
5 BASE TEÓRICA
5.1 Protocolo OPC [OPC Fundation, 2010]
Um dos grandes problemas de se criar um interface de comunicação entre
equipamentos e sistemas no chão de fábrica reside em encontrar dados que sejam
compatíveis nos protocolos da camada de aplicação. O MMS - Manufacturing
Message Specification foi uma tentativa de padronização que, entretanto fracassou
por falta de adeptos.
Com o crescente número de fabricantes de equipamentos e as vertentes de
sistemas supervisórios que existe, surgiu a necessidade de se criar um padrão de
comunicação entre eles, eis que um projeto inicialmente liderado pela Microsoft e
especificado pela OPC Foundation, deu-se início ao protocolo OPC. Este protocolo
é hoje o padrão de fato da indústria. Geralmente um fabricante de equipamento de
controle poderá fornecer com o seu produto um servidor OPC. O fabricante de
SDCD (Sistema Digital de Controle Distribuído) também fornece o cliente OPC. O
mesmo acontece com um fornecedor de inversores, de relés inteligentes ou de
qualquer outro dispositivo industrial inteligente. Um sistema SDCD também pode
oferecer um servidor OPC para comunicação com outro sistema de aquisição de
dados, por exemplo, um PIMS (Process/Plant Information Management System).
24
Como as aplicações precisam apenas saber como buscar dados de um
servidor OPC, ignorando a implementação do dispositivo, e o servidor precisa
fornecer dados em um formato único: servidor OPC, a tarefa de escrever drives de
comunicação fica muito facilitada.
O servidor OPC fornece dados em tempo real proveniente de sensores
(temperatura, pressão, etc.), comandos de controle (abrir, fechar, ligar, desligar,
etc.), status de comunicação, dados de desempenho e estatística do sistema, etc.
O protocolo OPC é baseado no modelo de componentização criado pela Microsoft
e denominado COM (Componet Object Model), uma maneira eficiente de se
estabelecer interfaces para aplicações que substitui as chamadas de procedimento
e as DLL usadas inicialmente para encapsular uma aplicação.
O nome OPC surge de OLE for Process Control, e foi cunhado na época
em que o COM era um modelo embrionário de comunicação entre aplicativos
como o nome de OLE (Object Linking and Embedding), que surgiu no início da
década de 90, para permitir a integração de dados entre aplicações no Windows.
Isto permitia, por exemplo, inserir uma planilha Excel em um documento do Word
e, a partir deste último, acessar e editar de forma dinâmica, todos os dados da
primeira (IWANITZ, 2002).
A abordagem do OLE foi estendida para outros tipos de aplicativos, na
forma de um modelo orientado a objetos, disponível em várias linguagens de
programação, através dos chamados componentes.
Esta tecnologia foi batizada de Component Object Model (COM), em 1995
(IWANITZ, 2002). A necessidade de compartilhar estes componentes através da
rede levou ao desenvolvimento do DCOM, resultado da união das tecnologias
COM e DCE RPC (mais especificamente, o ORPC) (IWANITZ, 2002).
O padrão OPC é baseado em comunicações cíclicas ou por exceção. Cada
transação pode ter de um a milhares de itens de dados, o que torna o protocolo
muito eficiente, superando o MMS para aplicações práticas, segundo técnicos da
divisão Powertrain da GM. O protocolo OPC não resolve o problema de nomes
globais, para isto deve-se saber exatamente em que servidor uma dada variável
pode ser encontrada.
25
As especificações do protocolo OPC estão disponíveis no site da
OPCFoundation e abaixo é mostrado uma lista das especificações mais usadas:
OPC Common Definitions and Interfaces - fornece e descreve definições,
interfaces e serviços comuns a todas especificações;
OPC Data Access (DA) - principal especificação do OPC, fornece a
funcionalidade de transferência de dados de tempo real e contínua de
CLPs, SDCDs e outros, para IHMs, sistemas supervisórios e similares;
OPC Alarms & Events (AE) - fornece notificações de alarmes e eventos
sob demanda, como alarmes de processo, ações do operador, auditagem
etc;
OPC Historical Data Access (HDA) - fornece mecanismos consistentes e
uniformes de acesso a dados de histórico já armazenados;
OPC Batch - traz a filosofia do OPC às aplicações de processamento em
batelada (batch processing), permitindo mecanismos de troca de
informações e condições operacionais atuais em equipamentos que
implementam este tipo de controle (é uma extensão da OPC-DA).
Como o servidor OPC é um objeto COM, pode-se citar como suas principais
funções:
Gerenciar grupos - criar, clonar e deletar grupos de itens, renomear, ativar,
desativar grupos;
Incluir e remover itens em um grupo;
Navegar pelas tags existentes (browser interface);
Ver os atributos ou campos associado a cada tag;
Definir a linguagem de comunicação (país) a ser usada;
Associar mensagens significativas a códigos de erro;
Obter o status de funcionamento do servidor.
O grupo de dados constitui uma maneira conveniente para a aplicação
organizar os dados de que necessita. Cada grupo de dados pode ter uma taxa de
leitura específica: pode ser lida periodicamente (polling), ou por exceção. O grupo
pode ser ativado ou desativado como um todo. A interface de grupo permite as
seguintes funcionalidades ao cliente:
26
Adicionar e remover itens dos grupos.
Definir a taxa de leitura do dado no grupo.
Ler e escrever valores para um ou mais itens do grupo.
Assinar dados do grupo por exceção.
Cada item é um objeto OPC, que proporciona uma conexão com uma
entrada física de dados. Cada item fornece ao cliente informação de: valor, time
stamp, qualidade do dado e tipo de dado. É possível definir um vetor de objetos
como um único item. Isto otimiza a comunicação de dados, já que apenas um time
stamp e uma palavra de qualidade de dados são utilizados para cada conjunto de
dados. As leituras de dados podem ser de três tipos: leitura cíclica (polling), leitura
assíncrona (o cliente é avisado quando a leitura se completa) e por exceção
(assinatura). As duas primeiras trabalham sobre listas (subconjuntos) de um grupo,
e o serviço de assinatura envia aos clientes qualquer item no grupo que mudar de
valor.
5.2 Protocolo TCP/IP [Tanenbaum, 2003]
5.2.1 Introdução
O TCP/IP não é na verdade um protocolo, mas sim um conjunto de
protocolos – uma pilha de protocolos, como ele é mais chamado. Seu nome, por
exemplo, já faz referência a dois protocolos diferentes, o TCP (Transmission
Control Protocol, Protocolo de Controle de Transmissão) e o IP (Internet Protocol,
Protocolo de Internet). Existem muitos outros protocolos que compõem a pilha
TCP/IP, como o FTP, o HTTP, o SMTP e o UDP.
A arquitetura do TCP/IP pode ser vista na figura a seguir.
27
Figura 2 - Arquitetura do TCP/IP.
Como é indicado na figura acima, o TCP/IP tem quatro camadas. Os
programas se comunicam com a camada de Aplicação, onde se encontrarão os
protocolos de aplicação, tais como o SMTP (para e-mail), o FTP (para a
transferência de arquivos) e o HTTP (para navegação web). Cada tipo de
programa se comunica com um protocolo de aplicação diferente, dependendo da
finalidade do programa.
Após processar a requisição do programa, o protocolo na camada de
Aplicação se comunicará com o protocolo na camada de Transporte, normalmente
o TCP. Esta camada é responsável por pegar os dados enviados pela camada
superior, dividi-los em pacotes e enviá-los para a camada imediatamente inferior, a
camada Internet. Além disso, durante a recepção dos dados, esta camada é
responsável por colocar os pacotes recebidos da rede em ordem (já que eles
podem chegar fora de ordem) e também verificam se o conteúdo dos pacotes está
intacto.
Na camada Internet tem-se o IP (Internet Protocol, Protocolo Internet), que
pega os pacotes recebidos da camada de Transporte e adiciona informações de
endereçamento virtual, isto é, adiciona o endereço do computador que está
enviando os dados e o endereço do computador que receberá os dados. Esses
endereços virtuais são chamados endereços IP. Em seguida os pacotes são
28
enviados para a camada imediatamente inferior, a camada Interface com a Rede.
Nesta camada os pacotes são chamados datagramas.
A camada Interface com a Rede receberá os pacotes enviados pela
camada Internet e os enviará para a rede (ou receberá os dados da rede, caso o
computador esteja recebendo dados). O que está dentro desta camada dependerá
do tipo de rede que seu computador estiver usando. Atualmente praticamente
todos os computadores utilizam um tipo de rede chamado Ethernet (que está
disponível em diferentes velocidades; as redes sem fio também são redes
Ethernet) e, portanto, deve-se encontrar na camada Interface com a Rede as
camadas da Ethernet, que são: Controle do Link Lógico (LLC), Controle de Acesso
ao Meio (MAC) e Rede Física, listadas de cima para baixo. Os pacotes
transmitidos pela rede são chamados quadros.
5.2.2 Camadas de Aplicação
Esta camada faz a comunicação entre os programas e os protocolos de
transporte. Existem vários protocolos que operam na camada de aplicação. Os
mais conhecidos são o HTTP (HyperText Transfer Protocol, Protocolo de
Transferência Hipertexto), o SMTP (Simple Mail Transfer Protocol, Protocolo
Simples de Transferência de Correspondência), o FTP (File Transfer Protocol,
Protocolo de Transferência de Arquivos), o SNMP (Simple Network Management
Protocolo, Protocolo Simples de Gerenciamento de Redes), o DNS (Domain Name
System, Sistema de Nome de Domínio) e o Telnet.
Quando um programa cliente de e-mail quer baixar os e-mails que estão
armazenados no servidor de e-mail, ele efetuará esse pedido para a camada de
aplicação do TCP/IP, sendo atendido pelo protocolo SMTP. Quando se insere um
endereço www no navegador para visualizar uma página na Internet, ele se
comunicará com a camada de aplicação do TCP/IP, sendo atendido pelo protocolo
HTTP (é por isso que as páginas da Internet começam com http://), e assim por
diante.
A camada de aplicação comunica-se com a camada de transporte através
de uma porta. As portas são numeradas e as aplicações padrão usam sempre uma
mesma porta. Por exemplo, o protocolo SMTP utiliza sempre a porta 25, o
29
protocolo HTTP utiliza sempre a porta 80, e o FTP as portas 20 (para transmissão
de dados) e 21 (para transmissão de informações de controle).
O uso de um número de porta permite ao protocolo de transporte
(tipicamente o TCP) saber qual é o tipo de conteúdo do pacote de dados (por
exemplo, saber que o dado que ele está transportando é um e-mail) e, no receptor,
saber para qual protocolo de aplicação ele deverá entregar o pacote de dados, já
que, como estamos vendo, existem inúmeros. Assim, ao receber um pacote
destinado à porta 25, o protocolo TCP irá entregá-lo ao protocolo que estiver
conectado a esta porta, tipicamente o SMTP, que por sua vez entregará o dado à
aplicação que o solicitou (o programa de e-mail).
Na Figura 3 ilustramos como a camada de Aplicação funciona.
Figura 3 - Como a camada de Aplicação funciona.
5.2.2 Camadas de Transporte
Na transmissão de dados, a camada de transporte é responsável por pegar
os dados passados pela camada de aplicação e transformá-los em pacotes. O
TCP (Transmission Control Protocol, Protocolo de Controle da Transmissão) é o
protocolo mais usado na camada de Transporte. Na recepção de dados, o
protocolo TCP pega os pacotes passados pela camada Internet e trata de colocá-
los em ordem, já que os pacotes podem chegar ao destino fora de ordem, confere
se os dados dentro dos pacotes estão íntegros e envia um sinal de confirmação
chamado “acknowledge” (“ack”) ao transmissor, avisando que o pacote foi recebido
corretamente e que os dados estão íntegros. Se nenhum sinal de confirmação
(acknowledge) for recebido (ou porque o dado não chegou ao destino ou porque o
30
TCP descobriu que o dado estava corrompido), o transmissor enviará novamente o
pacote perdido.
Enquanto que o TCP reordena os pacotes e usa mecanismo de
confirmação de recebimento – o que é desejável na transmissão de dados – existe
um outro protocolo que opera nesta camada que não tem esses recursos. Este
protocolo é o UDP (User Datagram Protocol, Protocolo de Datagrama do Usuário).
Por essa razão o TCP é considerado um protocolo confiável, enquanto que
o UDP é considerado um protocolo não confiável. O UDP é tipicamente usado
quando nenhum dado importante está sendo transmitido, como requisições DNS
(Domain Name System, Sistema de Nome de Domínio). Como o UDP não
reordena os pacotes e nem usa mecanismo de confirmação, ele é mais rápido do
que o TCP.
Quando o UDP é usado, a aplicação que solicita a transmissão será a
responsável por verificar se os dados recebidos estão intactos ou não e também
de reordenar os pacotes recebidos, isto é, a aplicação fará o trabalho do TCP.
Durante a transmissão de dados, tanto o UDP quanto o TCP receberão os
dados passados da camada de Aplicação e adicionarão a esses dados um
cabeçalho. Na recepção de dados, o cabeçalho será removido antes de os dados
serem enviados para a porta apropriada. Neste cabeçalho estão várias
informações de controle, em particular o número da porta de origem, o número da
porta de destino, um número de seqüência (para a confirmação de recebimento e
mecanismos de reordenamento usado pelo TCP) e uma soma de verificação
(chamada checksum ou CRC, que é um cálculo usado para verificar se o dado foi
recebido intacto no destino). O cabeçalho UDP tem 8 bytes, enquanto que o
cabeçalho TCP tem entre 20 e 24 bytes (dependendo se o campo opções estiver
sendo ou não usado).
Na Figura 4 ilustramos o pacote de dados gerado na camada de transporte.
Este pacote de dados será enviado para a camada Internet (se estamos
transmitindo dados) ou será recebido da camada Internet (se estamos recebendo
dados).
31
Figura 4 - Pacote de dado na camada de Transporte.
5.2.3 Camadas de Internet
Em redes TCP/IP cada computador é identificado com um endereço virtual
único, chamado endereço IP. A camada Internet é responsável por adicionar um
cabeçalho ao pacote de dados recebidos da camada de Transporte onde, entre
outros dados de controle, será adicionado também o endereço IP de origem e o
endereço IP de destino – isto é, o endereço IP do computador que está enviando
os dados e o endereço IP do computador que deverá recebê-los.
A placa de rede de cada computador tem um endereço físico. Este
endereço está gravado na memória ROM da placa de rede e é chamado endereço
MAC. Dessa forma, em uma rede local se o computador A quiser enviar dados
para o computador B, ele precisará saber o endereço MAC do computador B.
Enquanto que em uma pequena rede local os computadores podem facilmente
descobrir o endereço MAC de todos os PCs, esta não é uma tarefa tão simples em
uma rede global como a Internet.
Se nenhum esquema de endereçamento virtual for usado, precisa-se saber
o endereço MAC do computador de destino, o que não é apenas uma tarefa
complicada, mas também não ajuda no roteamento dos pacotes, já que este
endereço não usa uma estrutura em árvore (em outras palavras, enquanto o
endereçamento virtual usado na mesma rede terá endereços seqüenciais, com o
endereçamento MAC o computador com o endereço MAC seguinte ao anterior
pode estar muito distante e em outra rede).
Roteamento é o caminho que os dados devem usar para chegar ao destino.
Quando dados são solicitados de um servidor da Internet, por exemplo, este dado
32
passa por vários locais (chamados roteadores) antes de chegar ao seu
computador. Um exemplo é utilizar o comando tracert no prompt do Windows e
rastrear o site www.google.com. O resultado será o caminho entre seu computador
e o servidor web do Google. Pode-se ver como os pacotes de dados passam
através de diferentes roteadores antes de chegar ao destino. Cada roteador no
meio do caminho é também conhecido como “salto” (“hop”).
Em todas as redes conectadas à Internet existe um dispositivo chamado
roteador, que faz a ponte entre os computadores na sua rede local e a Internet.
Todo roteador tem uma tabela contendo as redes conhecidas e também uma
configuração chamada gateway padrão apontando para outro roteador na Internet.
Quando seu computador envia um pacote de dados para a Internet, o roteador
conectado à sua rede primeiro verifica se ele conhece o computador de destino –
em outras palavras, o roteador verifica se o computador de destino está localizado
na mesma rede ou em uma rede que ele conhece a rota. Se ele não conhecer a
rota para o computador de destino, ele enviará o pacote para seu gateway padrão,
que é outro roteador. Este processo é repetido até que o pacote de dados chegue
ao seu destino.
O IP coleta os pacotes de dados recebidos da camada de Transporte (do
protocolo TCP se a transmissão for de dados como e-mails ou arquivos) e os
divide em datagramas. O datagrama é um pacote que não contém nenhum tipo de
confirmação de recebimento (acknowledge), o que significa que o IP não
implementa nenhum mecanismo de confirmação de recebimento, isto é, ele é um
protocolo não confiável.
Deve-se notar que durante a transferência de dados o protocolo TCP será
usado acima da camada Internet (ou seja, acima do IP) e o TCP implementa
mecanismo de confirmação de recebimento. Portanto apesar de o protocolo IP não
verificar se o datagrama chegou ao destino, o protocolo TCP fará esta verificação.
A conexão será então confiável, apesar do IP sozinho ser um protocolo não
confiável.
Cada datagrama IP pode ter um tamanho máximo de 65.535 bytes,
incluindo seu cabeçalho, que pode usar 20 ou 24 bytes, dependendo se um campo
chamado “opções” for usado ou não. Dessa forma os datagramas IP podem
33
transportar até 65.515 ou 65.511 bytes de dados. Se o pacote de dados recebidos
da camada de Transporte for maior do que 65.515 ou 65.511 bytes, o protocolo IP
fragmentará os pacotes em quantos datagramas forem necessários
Na Figura 5 ilustrou-se o datagrama gerado na camada Internet pelo
protocolo IP. É interessante notar que o que a camada Internet vê como sendo
“dados” é o pacote completo que ela recebe da camada de Transporte, que inclui o
cabeçalho TCP ou UDP. Este datagrama será enviado para a camada Interface
com a Rede (se estiver sendo transmitindo) ou pode ter sido recebido da camada
Interface com a Rede (se estiver recebendo dados).
Como mencionamos anteriormente, o cabeçalho adicionado pelo protocolo
IP inclui o endereço IP de origem, o endereço IP de destino e várias outras
informações de controle.
Figura 5 - Datagrama na camada de Internet.
Nota-se que não necessariamente os pacotes de dados, datagramas, têm
65.535 bytes, isto implica dizer que o campo de dados do datagrama não tem um
tamanho. Como os datagramas serão transmitidos pela rede dentro de quadros
produzidos pela camada Interface com a Rede, normalmente o sistema
operacional configurará o tamanho do datagrama IP para ter o tamanho máximo
da área de dados do quadro de dados usado na rede. O tamanho máximo do
campo de dados dos quadros que são transmitidos pela rede é chamado MTU,
Maximum Transfer Unit, ou Unidade de Transferência Máxima.
34
As redes Ethernet – que são o tipo de rede mais comum hoje em dia,
incluindo sua aplicação sem fio – pode transportar até 1.500 bytes de dados, ou
seja, seu MTU é de 1.500 bytes. Por isso o sistema operacional configura
automaticamente o protocolo IP para criar datagramas IP com 1.500 bytes em vez
de 65.535 (que não caberia no quadro).
O TCP/IP é um conjunto de protocolos que lida com as camadas 3 a 7 do
modelo de referência OSI. O Ethernet é um conjunto de protocolos que lida com as
camadas 1 e 2 do modelo de referência OSI – o que significa que o Ethernet se
preocupa com o aspecto físico da transmissão de dados. Por isso eles se
complementam, já que se precisa das sete camadas completas (ou suas
equivalentes) para estabelecer uma conexão de rede.
Outra característica que o protocolo IP permite é a fragmentação. Se todas
as redes no caminho entre o computador transmissor e o receptor usarem o
mesmo tipo de rede (por exemplo Ethernet), seria o ideal, já que todos os
roteadores trabalharão com a mesma estrutura do quadro (isto é, o mesmo
tamanho de MTU).
No entanto, redes que não seguem o padrão Ethernet podem usar um
tamanho diferente de MTU. Se isto acontecer, o roteador que está recebendo os
quadros com o MTU configurado com 1.500 bytes dividirá o datagrama IP em
quantos quadros forem necessários para atravessar a rede com o tamanho de
MTU menor. Ao chegar no roteador que tem sua saída conectada a uma rede
Ethernet, este roteador remontará o datagrama original.
Na Figura 6 é possível ver um exemplo. O quadro original usa um MTU de
1.500 bytes. Quando o datagrama chega a uma rede com o tamanho de MTU de
620 bytes, cada quadro tem de ser dividido em três quadros (dois com 600 bytes e
um com 300 bytes). Em seguida o roteador na saída desta rede (roteador 2)
remonta o datagrama original.
35
Figura 6 - Fragmentação de datagrama.
5.2.4 Camadas Interface com a Rede
Os datagramas gerados na camada Internet serão passados para a
camada Interface com a Rede, durante a transmissão de dados, ou a camada de
Interface com a Rede pegará os dados da rede e os enviará para a camada de
Internet, na recepção dos dados.
Esta camada é definida pelo tipo de rede física a qual seu computador está
conectado. Quase sempre seu computador estará conectado a uma rede Ethernet
(redes sem fio também são redes Ethernet como já citado).
A Ethernet tem três camadas: LLC (Controle do Link Lógico), MAC
(Controle de Acesso ao Meio) e Física. O LLC e o MAC correspondem, juntas, a
segunda camada do modelo de referência OSI.
Figura 7 - Arquitetura do Ethernet.
A camada LLC é a responsável por adicionar informações de que protocolo
na camada Internet foi o responsável por gerar os dados. Dessa forma, durante a
recepção de dados da rede esta camada no computador receptor tem que saber
36
que protocolo da camada de Internet ele deve entregar os dados. Esta camada é
definida pelo protocolo IEEE 802.2.
A camada de Controle de Acesso ao Meio (MAC) é a responsável por
montar o quadro que será enviado para a rede. Esta camada é responsável por
adicionar o endereço MAC de origem e de destino – como explicado
anteriormente, o endereço MAC é um endereço físico de uma placa de rede. Os
quadros que são destinados a outras redes utilizarão o endereço MAC do roteador
da rede como endereço de destino.
A camada Física é a responsável por converter o quadro gerado pela
camada MAC em sinais elétricos (se for uma rede cabeada) ou eletromagnéticos
(se for uma rede sem fio). Esta camada é também definida pelo protocolo IEEE
802.3, se for uma rede com cabos estiver sendo usada, ou pelo IEEE 802.11, se
uma rede sem fio estiver sendo usada.
As camadas LLC e MAC adicionam suas informações de cabeçalho ao
datagrama recebido da camada Internet. Portanto uma estrutura completa de
quadros gerados por essas duas camadas pode ser vista na Figura 8. Nota-se que
os cabeçalhos adicionados pelas camadas superiores são vistos como “dados”
pela camada LLC. O mesmo acontece com o cabeçalho inserido pela camada
LLC, que será visto como dado pela camada MAC.
A camada LLC adiciona um cabeçalho de 3 ou 5 bytes e seus datagrama
tem um tamanho total máximo de 1.500 bytes, deixando um máximo de 1.497 ou
1.492 bytes para dados. A camada MAC adiciona um cabeçalho de 22 bytes e um
CRC (soma dos dados para identificação de erros) de 4 bytes ao final do
datagrama recebido da camada LLC, formando o quadro Ethernet. Portanto o
tamanho máximo de um quadro Ethernet é de 1.526 bytes.
37
Figura 8 - Quadro na camada de Interface com a Rede.
5.3 LabView (National Instruments)
5.3.1 Introdução
O LabVIEW (acrônimo para Laboratory Virtual Instrument Engineering
Workbench) é uma linguagem de programação gráfica originária da National
Instruments (NI). A primeira versão surgiu em 1986 para o Macintosh e atualmente
existem também ambientes de desenvolvimento integrados para os Sistemas
Operacionais Windows, Linux e Solaris.
Os principais campos de aplicação do LabVIEW são a realização de
medições e a automação. A programação é feita de acordo com o modelo de fluxo
de dados, o que oferece a esta linguagem vantagens para a aquisição de dados e
para a sua manipulação.
Os programas em LabVIEW são chamados de instrumentos virtuais ou,
simplesmente, VIs. São compostos pelo painel frontal, que contém a interface, e
pelo diagrama de blocos, que contém o código gráfico do programa. O programa
não é processado por um interpretador, mas sim compilado. Deste modo o seu
desempenho é comparável à exibida pelas linguagens de programação de alto
nível. A linguagem gráfica do LabVIEW é chamada "G".
Os blocos de funções são designados por instrumentos virtuais. Isto é
assim porque, em princípio, cada programa (Sub-VI) pode ser usado como sub-
38
programa por qualquer outro ou pode, simplesmente, ser executado isoladamente.
Devido à utilização do modelo do fluxo de dados, as chamadas recursivas não são
possíveis, podendo-se, no entanto, conseguir esse efeito pela aplicação de algum
esforço extra.
O programador liga VIs com linhas (arames) de ligação e define, deste
modo, o fluxo de dados. Cada VI pode possuir entradas e/ou saídas. A execução
de um VI começa quando todas as entradas estão disponíveis; os resultados do
processamento são então colocados nas saídas assim que a execução do sub-
programa tenha terminado. Desta forma, a ordem pela qual as tarefas são
executadas é definida em função dos dados. Uma ordem pré-definida (por
exemplo, "da esquerda para a direita") não existe.
Uma importante conseqüência destas regras é a facilidade com que podem
ser criados processos paralelos no LabVIEW. Os sub-VIs sem interdependência
dos respectivos dados são processados em paralelo.
Os sub-VIs que não possuem entradas são executados no início do
programa. Se o sub-VI não possuir saídas, os dados resultantes são ignorados ou,
então, usados pelo exterior: são escritos para o disco rígido ou para a rede, ou
enviados para impressão. Da mesma forma, um sub-VI sem entradas pode
receber dados provenientes de aparelhos periféricos ou pode gerar os seus
próprios dados (um exemplo é um gerador de números aleatórios).
Os sub-VIs podem estar interligados com muita complexidade. Muitas das
funções próprias do LabVIEW são, por sua vez, VIs normais, que podem ser
modificados pelo programador (o que não é recomendado). Todos os VIs se
baseiam numa série de funções básicas, chamadas "primitivas", que não podem
ser modificadas pelo programador (ao invés dos VIs.)
Muitos VIs e primitivas em LabVIEW são polimorfos, ou seja, a sua
funcionalidade adapta-se ao tipos de dado que recebem. Por exemplo, a função
Build-Array pode ser usada para a criação de quaisquer variáveis, ou seja, de
strings, de inteiros e também de arrays e de clusters. Também é possível ao
programador construir os seus próprios VIs polimorfos. No fundo, consistem de
uma coleção de vários VIs com diferentes tipos de dados, entradas e saídas.
39
Os dados podem ser ligados ao Painel frontal através de manipuladores.
Por exemplo, a inserção de números pode ser dependente de uma variável e uma
variável de saída booleana pode ser realizada por um LED colocado no painel.
O painel frontal do LabVIEW é um meio confortável para construir
programas com uma boa interface gráfica. O programador não necessita escrever
qualquer linha de código. A apresentação gráfica dos processos aumenta a
facilidade de leitura e de utilização. Uma grande vantagem em relação às
linguagens baseadas em texto é a facilidade com que se cria componentes que se
executam paralelamente.
Devido à estrutura modular de LabVIEW, pode-se adicionar funcionalidades
ao núcleo do software como add-on, módulos e toolkits da NI e de terceiros para
atender aos requisitos de um projeto.
5.3.2 LabVIEW – IMAQ
Entre os dispositivos de hardware que podem ser acessados via LabVIEW,
encontram-se as câmeras de vídeo. O acesso é feito através de funções
disponíveis em uma biblioteca de aquisição de imagens denominada NI – IMAQ
(National Instruments Image Aquisition). A aquisição de imagens via câmeras USB,
usando-se o LabVIEW, pode ser feita empregando-se a biblioteca NI IMAQ for
USB cameras.
A IMAQ suporta diversos tipos de formatos de comunicação com câmeras:
analógicas e digitais (USB, Firewire, Gigabit-Ethernet, Camera Link, etc). O modelo
genérico de acesso às câmeras encontra-se esquematizado na Figura 9. As
interfaces de acesso podem ser placas conectadas ao barramento do computador,
ou podem fazer parte diretamente da placa-mãe (motherboard).
Deve-se primeiramente identificar a interface eletrônica por onde as
imagens chegarão ao computador. Se a câmera for analógica, esta interface será
a chamada placa de aquisição, que é uma placa ligada ao barramento do
computador onde se encontram os circuitos de captura e digitalização do sinal de
vídeo. Se for digital, usualmente haverá uma placa com decodificador do protocolo
(ex. Firewire, GigE, USB, Camera Link) utilizado pela câmera para enviar o vídeo,
e os buffers de vídeo que recebem os dados assim que vão chegando.
40
Figura 9 - Modelo genérico de um software de aquisição de imagens.
Feita essa identificação, o programa deve ter uma instrução para ativar o
hardware, preparando-o para fazer a aquisição das imagens. Esse procedimento
recebe o nome de abertura de uma sessão (de trabalho) com o hardware. Esse
procedimento “reserva” o hardware para a aplicação desenvolvida.
Neste momento, pode-se configurar os parâmetros de aquisição a serem
usados (por exemplo, o tamanho da imagem, o tipo da imagem e a taxa de
aquisição). Alguns exemplos disso:
Tamanho : 640 x 480 ; Tipo: Colorida ; Taxa de aquisição: 60 quadros por
segundo
Tamanho: 1280 x 1024; Tipo: Monocromática (Greyscale) ; Taxa: 15
quadros por segundo
Em seguida deve-se preparar uma região na memória pertencente ao
espaço de endereçamento a ser ocupado pelo programa, realizando-se a alocação
de memória específica para as imagens capturadas.
Uma vez feito isso, realiza-se a captura das imagens através da interface
eletrônica, armazenando-as na memória alocada. Há dois tipos de captura:
Snap – captura de imagens individuais, como fotografias (snapshots).
Grab – captura contínua de vídeo, produzindo uma seqüência de imagens
(quadros = frames )
41
Terminado o procedimento, em qualquer momento antes do final do
programa, a sessão com o hardware deve ser encerrada (fechamento de uma
sessão), liberando-o para uso em outras aplicações.
5.3.3 LabVIEW Datalogging and Supervisory Control (DSC) Module
O NI LabVIEW (DSC) estende os benefícios da programação gráfica para o
desenvolvimento do HMI / SCADA ou alto número de canais de registro de dados
das aplicações. Com o LabVIEW DSC, pode-se desenvolver uma forma interativa
de monitoramento do sistema de controle distribuído que contam com dezenas de
milhares de tags. Este módulo inclui ferramentas para comunicação com PLCs
convencionais, bem como controladores programáveis para automação, tais como
o NI CompactRIO, registro de dados para bases de dados históricas, alarmes e
eventos gestão e desenvolvimento de IHMs tudo dentro de um único ambiente no
LabVIEW.
LabVIEW DSC é fornecido com suporte para protocolos comumente usados
industriais, incluindo OLE for Process Control (OPC). Isso permite que um
aplicativo se comunique com praticamente todos os PLCs e controladores
programáveis utilizados na automação industrial. Esta flexibilidade permite uma
fácil integração do LabVIEW com sistemas SCADA / HMI existentes.
Sem necessidade de utilização de um software adicional, é possível utilizar
esta ferramenta para configurar log de alarmes e eventos, definir valores de
alarmes e gerenciar everntos e salvar esses dados em bancos históricos.
6 ESPECIFICAÇÕES
6.1 Especificações do Sistema
Nessa seção é apresenta, em detalhes, todas as especificações e estrutura
do sistema e posteriormente da aplicação proposta.
6.1.1 O Modelo Utilizado
Inicialmente é apresentado modelo de comunicação utilizado inspirado nos
modelos já existentes, a fim de realizar a concepção deste projeto, plataformas
como o RemoteBot.net, Telelab e o Bigsinal 2000, já apresentados anteriormente,
foram a base para construção da figura a seguir.
42
Figura 10 – Arquitetura do Sistema Proposto.
Em relação os projetos correlatos, esta aplicação apresenta uma diferença
marcante que é a utilização de um protocolo industrial na comunicação com o
robô, OPC, e também a utilização de uma linguagem de programação visual fácil
de ser entendida, LabView. Isto tudo foi visando o desenvolvimento de aplicações
futuras com robôs industriais e para facilitar o entendimento da programação
utilizada na aplicação.
Há outro diferencial que foi a utilização de equipamentos periféricos de
baixo custo, como o controle joystick e a câmera USB, que podem ser adquiridos
em qualquer loja de informática e são Plug & Play, não necessitam de um software
específico para que funcionem em conjunto com a aplicação.
Tem-se então o robô enviando seus dados de posição espacial através do
protocolo OPC, onde o manipulador se torna um servidor e o computador local se
torna um cliente OPC, o computador local então interpreta e trata estes dados,
recebe também um sinal de vídeo pelo toolkit IMAQ do LabView e envia os dados
via TCP/IP para o computador remoto.
No computador remoto os dados são interpretados e separados para serem
tratados em dados da câmera, que são convertido em imagem e mostrado numa
43
interface para que o usuário tenha total visão do que está manipulando, os dados
OPC são interpretados como posição do robô e são encaminhados para
manipulação, onde será feita por um joystick (controle de vídeo game), ligada na
porta USB do computador remoto, ou pela interface criada no LabView para
eventual falha ou indisponibilidade do controle.
Para realizar uma comunicação entre o aluno e o técnico do laboratório, foi
implantado um sistema de mensagens instantâneas entre cliente e servidor do
LabView, respectivamente computador local e computador remoto, assim pode-se
realizar a comunicação escrita entre as duas estações.
6.1.2 Representação Esquemática do Sistema
A Figura 11 apresenta um fluxograma que explica o funcionamento do
sistema, com o fluxo das rotinas.
O fluxograma segue uma proposta de como se deve seguir na execução de
um exercício proposto e como a aplicação irá responder a cada ação tomada pelo
aluno, pode ser utilizado como base na preparação de exercícios práticos para
serem passados aos alunos.
Além de mostrar o que a aplicação está executando, o fluxograma também
mostra as possíveis ações que o aluno deve tomar caso chegue num determinado
ponto do exercício proposto, por exemplo, caso o manipulador não esteja numa
posição desejada e a mesma foi salva na lista de posições, qual ação o aluno deve
tomar, este e outros passos estão descritos adiante.
Logo após a inicialização do servidor com a porta de serviço já definida, o
seu endereço IP será mostrado e os dados OPC também, uma mensagem irá
aparecer, reportando que o cliente já pode se conectar.
No cliente a mesma porta deve ser definida e o endereço IP do servidor
deve ser inserido, após isto a conexão poderá ser concretizada. Com a mesma
estabelecida os dados da imagem serão transmitidos e o cliente já poderá realizar
a manipulação do robô, pode escolher entre a operação com o joystick ou se
preferir com o painel de controle da aplicação. Assim que a posição desejada do
manipulador for alcançada o aluno tem a possibilidade de salvá-la para criar uma
lista de posições, e assim criar uma rotina que poderá deixar o robô em modo
44
automático. Assim que todas as posições forem salvas e o robô estiver apto a
realizá-las, o modo automático pode ser ativado, caso deseje voltar e alterar a
rotina basta passá-lo para manual.
Figura 11 - Representação do funcionamento do Programa.
Há também uma área de mensagens instantâneas aonde o aluno pode se
comunicar através de textos com o responsável que estiver no computador local.
45
Para finalizar a atividade o aluno precisa somente clicar no botão “PARAR”
e a conexão entre cliente e servidor será automaticamente encerrada, para voltar a
manipular o robô é necessário conectar o servidor novamente.
6.2 Especificações da Aplicação
Pelo fato do trabalho proposto ter como intuito desenvolver uma interface
simples e prática, auxiliando no aprendizado e que permita o controle do
manipulador de forma rápida e tendo como base a Proposta do Projeto, deve-se
garantir o funcionamento da aplicação de acordo com certas especificações que
assegurem a eficiência e confiabilidade na execução dos comandos realizados
pelo usuário.
O primeiro ponto é a forma de criar uma conexão e manter a comunicação
com o restante do sistema, ou seja, como o programa irá enviar todos os
comandos que o robô irá executar. Nesse sentido optou-se pela utilização de
blocos STM, conjunto de funções desenvolvida por usuários do LabView, integrado
com a função Internet Toolkit, que permitem a criação de uma conexão confiável a
partir da especificação de parâmetros simples, que são apresentados na seção
“Desenvolvimento do Projeto”.
Quanto à tecnologia de transmissão optou-se pelo padrão TCP/IP, devido à
sua larga utilização atualmente nas mais diversas aplicações, pelo fato de que
quase todos os lugares do Brasil já contam com uma conexão com a internet que
utiliza esse protocolo.
Outro ponto importante é possibilitar o funcionamento de mais de uma
rotina em paralelo, para que o programa seja capaz de enviar e receber
informações e, ao mesmo tempo, processar os comandos executados pelo
usuário. Para tal, este recurso de executar funções e rotinas em paralelo já é
nativo do LabView. Tal aplicação permite a criação de diferentes tipos e formas de
blocos e faça com que executem diferentes tarefas que podem ser realizadas
simultaneamente.
Por tratar-se de uma aplicação que permite ao aluno total controle sobre o
robô, não existem uma ordem correta para se executar os comandos, basta o
aluno seguir o roteiro proposto pelo professor e verificar se a rotina criada por ele
atende as necessidades do exercício. Assim, todo o projeto do sistema foi
46
desenvolvido de forma a ser guiado a eventos. Toda vez que o aluno executa uma
ação ou comando o programa segue um caminho diferente, de acordo com o que
foi executado.
Em síntese, o servidor precisa habilitar a conexão para que o aluno se
conecte e comece a manipular o robô, após a conexão estabelecida todos os
comandos executados pelo aluno serão enviados ao robô ou ao servidor
dependendo do que for feito pelo aluno.
7 DESENVOLVIMENTO DO PROJETO A aplicação proposta neste trabalho foi toda desenvolvida a partir da
linguagem de blocos do software LabView. A opção por esta linguagem se deve a
três fatores importantes: primeiramente a característica de ser uma linguagem com
inúmeras ferramentas, módulos e toolkits, voltados para o desenvolvimento de
aplicações no âmbito industrial. Outro ponto importante é a flexibilidade na
execução dos blocos, sendo possível executá-los em paralelo e fazer com que
somente um programa seja iniciado, realizando multi-tarefas, facilitando assim a
envio e recebimento de sinais sem comprometer outras partes que ainda estão em
execução. E em terceiro é a fácil compreensão das linhas de código, para futuras
alterações, por ser uma linguagem visual é fácil entender quais as funções de cada
bloco, assim sendo, qualquer pessoa pode aprimorar este desenvolvimento para
outras aplicações semelhantes.
Como já foi citado a aplicação foi desenvolvida em duas partes, uma cliente
e outra servidor, para haver uma interação com o manipulador à distância. Cada
qual apresenta sua interface gráfica independente auxiliando a operação tanto do
aluno como de responsável que estiver no computador local junto ao robô.
Para esclarecer melhor o assunto sobre cliente/servidor, os tópicos a seguir
serão abortados: diagramas lógicos, telas gráficas junto com o modo de operação
de cada estrutura.
7.1 Estação Servidor
A parte da aplicação que funciona no computador servidor (local) tem o
papel fundamental nesta proposta, pois ela conta com um cliente OPC para coletar
e enviar os dados do robô, manter o funcionamento da monitoração do mesmo e
47
garantir o envio e transmissão dos dados concatenados para a estação cliente
(computador remoto).
Para isto alguns passos são seguidos na sua inicialização, primeiro uma
conexão com servidor OPC do robô é aberta e o programa coleta os dados atuais
da posição do mesmo. Logo em seguida há uma execução em paralelo, o servidor
abre a porta de comunicação TCP/IP definida na sua interface gráfica, monta o
buffer de dados que irá trafegar pela rede, o qual é composto por imagem, dados
de posição do manipulador e texto, e aguarda a conexão ser feita pelo cliente, ao
mesmo tempo a comunicação com a câmera é aberta e o espaço em disco para
alocação da imagem é iniciado, uma mensagem aparece para que o cliente se
conecte, então o programa entra em modo de espera até que a conexão por parte
do cliente seja feita.
Após o cliente realizar a conexão com o servidor os dados montado no
buffer começam a trafegar na rede e o cliente já recebe a posição atual do robô,
este é enviado somente na primeira execução do programa, pois quem irá
controlar o robô é o cliente, para isto ele deve saber qual a posição inicial do
manipulador, a câmera de vídeo começa a transmitir e a comunicação em texto
fica permitida.
Então o programa entra em loop até o cliente encerrar a conexão. Neste
loop os dados de imagem são enviados e logo em seguida os dados de texto.
Após este envio o programa segue em outra rotina que coleta os dados de texto e
dados referentes à posição do robô, enviados pelo cliente. Isto acontece
ciclicamente para garantir o sincronismo entre as duas partes da aplicação. Após
receber os dados da nova posição do robô o programa servidor as envia ao
manipulador através de variáveis globais. Este passo é o ultimo do ciclo, sendo
assim o laço faz com que todo este processo se repita.
7.1.1 Construção Lógica
Este tópico tem a função de explicar detalhadamente os blocos mais
complexos e setores específicos da programação, para se entender como o
programa executa como um todo.
Na figura a seguir pode-se ver toda a programação realizada no servidor.
48
Figura 12 - Estrutura lógica do servidor.
Esta estrutura pode ser divida em duas partes, onde a primeira é
inicialização do servidor e coleta de dados iniciais e a segunda parte é a repetição
do programa, execução cíclica que envia e depois coleta os dados do cliente.
Quando o programa inicial, os blocos “Posição X”, “Posição Y” e “Posição
Z”, coletam os valores do servidor OPC através de variáveis globais, que foram
criadas na biblioteca do LabView e já estão ligados ao servidor OPC do robô, um
tempo de 3 segundos é definido, sendo o tempo para garantir que os valores da
posição do robô seja coletado com segurança. Os valores são agrupados em uma
array e convertido em uma string para serem transmitidos pelo protocolo TCP/IP,
já que o mesmo só permite o tráfego nesse tipo de dado.
49
Figura 13 - Inicialização do Servidor.
Após a coleta, o programa entra numa nova seqüência onde é criada uma
conexão e a porta definida no painel frontal é usada para a troca de dados, um
buffer contendo dados da imagem, dados da posição do robô e texto é definido
para que o protocolo crie os datagramas necessários, os blocos referente a
inicialização da câmera são inseridos junto com o bloco IMAQ, para separar um
espaço em disco referente ao armazenamento da imagem antes da mesma ser
retransmitida. Nota-se que somente nesta etapa os dados OPC do robô são
enviados ao cliente, é necessário fazer isto para que o cliente saiba qual é a
posição inicial do manipulador, depois desta execução os dados da posição do
robô não serão mais enviados para o cliente e sim recebidos dele.
Assim que a inicialização estiver completa uma mensagem irá aparecer
dizendo que o cliente já pode se conectar, havendo o aceite da conexão pelo
cliente o programa entra na sua parte cíclica, a qual é mostrada na figura a seguir.
50
Figura 14 - Programação de laço do Servidor.
Na parte cíclica da programação a imagem começa a ser captada
continuamente e há uma janela de visualização, para que quem esteja na sala da
câmera possa ver o que ela está sendo filmado e fazer ajustes, se necessário.
Antes dos dados serem enviado para o cliente eles são comprimidos, pois dados
de imagem costumam ser muito pesado, diminuindo a velocidade da rede, e após
a compressão são convertidos de dados image para string. Notará que o servidor
51
somente envia os dados de imagem, não precisa receber feedback nenhum da
câmera, quem irá informar as condições da câmera será o aluno, utilizando a parte
textual do programa.
Logo após o envio das imagens o programa envia em tempo real o que
estiver sendo escrito na área de “Mensagens”, pois o bloco “TCP Write” está em
série com o mesmo bloco que envia as imagens. Pode-se notar que os dados de
texto já são do tipo string por isso não é necessário fazer a conversão para enviá-
los ao cliente.
Assim que todos os dados de envio já foram para o cliente, o programa
entra numa nova seqüência, agora ele irá ler os dados enviados pelo cliente,
começando pelas mensagens que o cliente escrever. O programa interpreta o que
deve ser lido de acordo com o tipo de dado colocado no conversor, antes de serem
convertido para string, no caso do texto não houve conversão então o dado lido do
protocolo TCP/IP entrará num indicador que recebe valores do tipo string.
Já para o casso dos dados da posição, que é o próximo dado a ser lido, foi
criando um array numérico então os dados possam por um bloco para converter
string em array novamente, e assim desmembrando o vetor em valores, tem-se a
posição do ponto que o robô deve estar no espaço, esta posição é passada ao
servidor OPC do robô que faz com que o manipulador alcance aquele ponto.
Após toda esta operação o programa retoma seu ciclo e inicia o envio de
dados, ele irá parar somente se houver falha na conexão, como perda de algum
dado ou se o usuário apertar o botão “PARAR”, assim que houver a interrupção, a
conexão é fechada por blocos e o programa para por completo, tanto cliente como
servidor.
7.1.2 Telas Gráficas e Modo de Operação
Nesta etapa será mostrado como a interface gráfica foi criada e como deve-
se operá-la, a figura abaixo ilustra qual será a tela visível ao usuário local.
52
Figura 15 - Tela do Servidor.
Esta tela por não ser concebida para interação com o robô é pobre em
relação aos comandos. Pode-se notar um campo para definir a porta de
comunicação, logo abaixo irá aparecer o IP do servidor que será passado ao
cliente para se conectar.
Há uma área aonde é possível ver o valor inicial da posição do robô e o
valor atual desta posição, para compara se o que esta sendo executado está
dentro do solicitado. Outra área em destaque é o monitoramento do robô, onde a
estação local poderá visualizar o que está sendo filmado, o intuito desta
funcionalidade é ajustar parâmetros de foco, distância da imagem e melhor
posição para captar os movimentos do manipulador.
Uma interface textual foi agregada ao sistema para que o aluno interaja
com o responsável local e vice-versa, a fim de realizar os ajustes necessários ou
troca de informações, não é necessário pressionar nenhum botão para enviar as
mensagens, as mesmas serão encaminhadas automaticamente a medida que o
usuário for digitando-as. E por último tem-se um botão de parada, para finalizar as
conexões e o programa.
Assim que o programa for iniciado e a porta já definida, as conexões serão
abertas e o IP do servidor irá aparecer no campo designado, junto com os valores
de posição inicial do robô, uma mensagem irá aparecer autorizando o cliente a se
conectar, após a conexão realizada pelo cliente irá aparecer a imagem atual da
53
câmera na área de monitoramento, e a área de texto estará disponível. A única
atuação direta na interface que será permitida é a finalização do programa.
7.2 Estação Cliente
Como foi explicado anteriormente a estação cliente só poderá se conectar
caso a estação servidor já tenha disponibilizado a porta de conexão e permitido o
acesso, após isto deve inserir no campo do IP o endereço do servidor e também a
porta liberada para realizar a comunicação e conectar-se, assim que a conexão é
realizada os dados começam a chegar à esta estação, monitoramento de câmera
já começa a transmissão de imagens.
A estação garante a qualidade dos dados enviados pelo servidor, ela trata
esses dados e mostra na sua interface ou os reenvia ao servidor para que uma
tarefa seja executada.
A comunicação com o controle joystick é uma das funções de
monitoramento desta estação, caso o mesmo esteja desconectado, a
funcionalidade de operação pelo controle será desativada e o usuário poderá
somente realizar o controle utilizando a interface do painel de controle inserida na
interface gráfica.
Esta estação conta também com um status que mostra se a câmera está
conectada, sendo ela essencial para sua operação, uma vez a câmera
desconectada a operação é abortada, impedindo a manipulação do robô, esta é
uma medida de segurança para evitar acidentes na manipulação do que não se
está vendo.
Há também a área de interação textual por aonde o aluno pode receber
mensagens vinda do servidor como enviar para que estiver no computador local
7.2.1 Construção Lógica
A construção lógica realizada no cliente é mais complexa do que a do
servidor, pois o anterior somente tem a função de manter a qualidade dos dados e
retransmiti-los, já o cliente deve ler os dados, manipulá-los de acordo com os
comandos do aluno e devolver esses ao servidor, abaixo se tem o esquema da
programação completa.
54
Figura 16 - Estrutura Lógica do Cliente.
55
Já, com o cliente fica mais complexo realizar uma divisão seqüencial para
um aprofundamento nas funções e nos blocos lógicos, pois seu funcionamento se
dá por um todo, seguindo caminhos diferentes de acordo com os comandos do
aluno, entretanto há duas partes distintas, a primeira é a inicialização da
comunicação e a segunda o laço que mantém o programa rodando. Dentro deste
laço pode-se tomar vários caminhos de operação, mas ainda há uma seqüência
lógica que o programa segue, destacou-se somente os mias importantes, como:
primeira execução do programa, para aquisição de valores iniciais, recebimento de
dados de imagens e texto, decodificação do controle (joystick) ou do painel de
controle, criação da lista de rotina e por fim execução no modo automático.
Primeiramente serão esclarecidos os parâmetros de inicialização do
programa que está sendo ilustrado na figura a seguir.
Figura 17 - Inicialização do Cliente.
Nesta figura observam-se os blocos criados que serão utilizados dentro do
programa e seus status e propriedades padrões, logo que o programa entre em
execução, uma mensagem aparece solicitando ao usuário que entre com o IP e a
porta de comunicação. Antes de se conectar, os comandos do painel ficam
inacessíveis, pois esta fase de inicialização garante que o usuário só poderá
manipular após a conexão ser estabelecida com o servidor.
56
Assim que tudo estiver configurado, o botão de “CONECTAR” deverá ser
acionado para que o programa continue sua execução e entre no próximo laço
cíclico, que pode ser chamado de execução permanente como que ilustrado na
figura 18.
Figura 18 - Programação de laço do Cliente.
57
Este laço é constituído por etapas seqüenciais que dão ao programa uma
linha coerente de transferência de dados, para facilitar a criação dos datagramas
pelo protocolo TCP/IP.
Na primeira execução do programa o cliente solicita ao servidor os dados
OPC do robô, para assim ter os valores iniciais da posição do robô, esta rotina é
executada somente uma vez, pois é a única vez que se recebe dados do robô, as
próximas rotinas irão escrever dados nele, também é definida a priori que a
execução terá o painel de controle como comando principal, pois somente quando
tiver a certificação de que há um joystick conectado é que poderá substituir para
este comando.
O diagrama do bloco que será executado somente uma vez é mostrado a
seguir.
Figura 19 - Aquisição de dados iniciais.
Após a primeira execução este conjunto todo de blocos fica vazio e o
programa não solicita ao servidor novos dados sobre a posição do robô.
58
A próxima seqüência tem como papel adquirir dados de imagem e texto,
assim como acontece com o servidor na parte de leitura de dados, o protocolo
TCP/IP envia todos os pacotes em formato de string, quando este pacote entra por
um bloco para decodificação somente o tipo de dado solicitado pelo decodificador
passa para a saída, então se tem dados de imagem e texto separados, prontos
para serem exibidos ao aluno.
A figura a seguir mostra os blocos responsáveis por adquirir estes dados e
decodificá-los e mostrá-los de maneira adequada, no caso de imagem numa tela
de visualização e o texto num campo de visualização.
Figura 20 - Aquisição de dados pelo Cliente.
Já a terceira parte da seqüência tem o papel de identificar e verificar se um
joystick está conectado, verificar o modo de operação e decodificar os valores para
serem transmitidos ao robô como coordenadas no espaço, e assim criar uma lista
de execução de uma rotina toda vez que uma posição for salva.
Na figura a seguir se tem a função que identifica se há um controle
conectado e retornar um status para um LED localizado no painel frontal.
Figura 21 - Identificação do joystick.
59
Os blocos de identificação retornam um status sobre a condição do
controle, se o mesmo não estiver conectado o programa só permite a manipulação
e controle através do painel de controles localizado na interface gráfica.
Executando em paralelo o programa permite ao usuário a manipulação do
robô via painel de controle, pois este está definido como padrão. A decodificação é
mostrada abaixo.
Figura 22 - Decodificação do Painel de Controle.
Como os comando gerados pelos controles do LabView são valores
numéricos, não necessita uma decodificação complexa, basta indicar que o valor
definido pelo usuário para cada eixo será a nova posição do robô.
Agora como os valores provenientes do joystick não são simplesmente
numéricos, foi realizada uma lógica um pouco mais complexa, pois os eixos do
controle retornam valores em impedância logarítmica, para tal houve uma
linearização desses valores, a fim de deixar o controle menos sensível aos
movimentos do usuário e fazer com que o robô de mova de maneira mais suave,
há também a opção de alterar a velocidade desses movimentos, utilizando dois
botões que foram mapeados para este propósito, e também há mais dois botões
com a função de salvar e o outro de apagar as posições do robô.
A seguir tem-se o diagrama que mostra como essa decodificação foi
realizado.
60
Figura 23 - Decodificação do joystick.
Com esta descodificação o controle não funciona igual o painel de controle,
aonde se tem a posição absoluta do robô no espaço, aqui a posição se dá de
maneira incremental, aonde quando mais se desloca os controles analógicos para
um dos lados, maior será o incremente na posição do robô, é possível alterar essa
velocidade incremental, deixando o movimento do robô mais rápido ou devagar, de
acordo com a precisão desejada.
A figura a seguir mostra o mapeamento físico do controle mostrando a
função que um determinado botão ou movimento realiza.
Figura 24 - Mapeamento do joystick.
61
O próximo passo da seqüência lógica é gerar uma lista com as posições
que o robô deve seguir, a fim de compor uma rotina seqüencial que o mesmo deve
realizar no modo automático.
O diagrama lógico é mostrado abaixo, junto com a execução em modo
automático e a transferência de texto.
Figura 25 - Diagrama do Modo Automático.
A cada vez que o botão “salvar posição” é pressionado a valor das
coordenas é salva numa lista, criando assim uma lista de rotina, esta lista tem no
máximo 10 itens, ou seja, o robô irá executar uma rotina com no máximo 10
posições, este número foi definido para evitar um grande fluxo de dados
trafegando e causar a queda da rede ou a perda de dados.
Assim que a lista da rotina estiver completa ou o robô for capaz de realizar
a tarefa com os pontos já salvos, pode-se passar a operação para o modo
automático, quando isso acontecer, os controles serão desativados, tanto a
funcionalidade do joystick quando o painel de controle, e assim o robô ira passar a
seguir os pontos pré definidos, automaticamente.
Neste diagrama contém também o bloco de envio de mensagens, que é
igual a parte do servidor, onde já foi devidamente explicado.
62
Um botão “PARAR” também está disponível para finalizar a aplicação e
fechar a conexão com o servidor.
7.2.2 Telas Gráficas e Modo de Operação
Abaixo se tem a figura que mostra como é a interface da tela de operação
da estação cliente (computador remoto).
Figura 26 - Interface gráfica do Cliente.
Esta tela é toda interativa e indica a ação sendo tomada pelo aluno. Assim
que o programa entrar em execução uma mensagem irá aparecer na tela,
solicitando que usuário insira o IP do servidor no campo de endereço e indique
qual porta será utilizada no trafega de dados. Lembrando que só pode haver a
conexão com o servidor somente quando o mesmo permitir, após as configurações
feitas e a permissão concebida, o cliente pode clicar no botão “CONECTAR”, e os
dados começarão a ser transmitidos.
A princípio somente a parte do “Painel de Controle” ficará ativa e já virá
indicado os valores atuas da posição do robô, o aluno poderá fazer todas as
63
atividades por está área, manipulação do braço e salvamento de posição também
são permitidos aqui. Entretanto caso o LED do joystick esteja acesso, o aluno
poderá optar por trocar a interface de controle alterando no “Modo de Operação”, e
passar assim a controlar o robô pelo joystick, como já foram mostradas as suas
funcionalidades, toda operação e recursos podem ser feitos por ele também.
A área de monitoramente é bem maior, para que o aluno tenha visão total
de todos os detalhes da manipulação, o campo de mensagens se assemelha ao
do servidor, aonde o aluno poderá trocar informações textuais com o responsável
que estiver no computador local, lembrando que não é necessário pressionar
nenhum botão para enviar as mensagens, as mesmas serão encaminhadas
automaticamente a medida que o usuário for digitando.
Quando uma posição desejada do robô é atingida e deseja-se salvar esta,
basta pressionar o botão “SALVAR” se estiver no modo de operação “Painel de
Controle”, ou o botão previamente mostrado se estiver no modo de operação
“Joystick”, automaticamente no campo de “Posições Salvas” irá aparecer as
coordenadas de X, Y e Z respectivamente na mesma linha, para cada posição
acrescentada uma novo linha também irá aparecer. Caso uma posição tenha sido
adicionada por engano é possível apagá-la pressionando o botão “APAGAR”, ou o
seu correspondente no controle, dependendo do modo de operação em que
estiver, assim a ultima posição salva será apagada.
Também na área de “Status do Manipulador”, o aluno pode conferir a
posição atual em que o manipulador está e nesta seção também se encontra a
mudança de operação do robô, entre estado “Manual” e “Automático”. No modo
manual o aluno poderá movimentar o manipular e salvar ou apagar as posições
desejadas. Quando passar o robô para modo automático, as funcionalidades dos
modos de operação ficam desativadas e o robô começa a seguir a movimentação
previamente salva na lista de posições. Assim que o modo voltar para o manual, o
manipulador interrompe sua rotina e aguarda novos comandos provenientes do
aluno.
E por último tem-se um botão de parada, para finalizar as conexões e o
programa, fechando também a aplicação.
64
8 RESULTADOS E DISCUSSÕES
8.1 Testes do OPC no LabView
Para haver comunicação com o servidor OPC do robô foi necessário criar
uma biblioteca no projeto da estação cliente, e nesta biblioteca inserir variáveis
globais que estariam ligadas aos dados OPC provenientes do manipulador. Assim
essas variáveis poderiam ser usadas dentro das aplicações VIs, para realizar a
leitura e a escrita dos valores da posição do robô.
Entretanto a funcionalidade de transferência de dados via OPC que robô
oferece não foi construída para realizar uma intervenção direta em sua posição,
pois de acordo com normas industriais, a operação de um robô não pode ser
realizada via acesso remoto, deve ser presencial, para evitar possíveis falhas e ou
acidentes, sendo assim seria impossível gerar uma programação nativa na
linguagem do robô, para que o mesmo executasse os movimentos
automaticamente e repetitivamente, quando fosse solicitado pelo aluno.
A solução para este problema foi gerar uma lista com as posições
desejadas e a aplicação envia cada posição que o robô deve assumir após a
instrução anterior ser completada. Com isso tem-se uma rotina pré definida e
sendo executada automaticamente, comparando-se ao processo real de
programação na linguagem nativa utilizando o terminal local do robô.
Realizando este procedimento em um local controlado e sem riscos, esta
atividade se torna totalmente viável para fins didáticos.
8.2 Testes da Interface
Inicialmente foram realizados os testes para verificar a funcionalidade da
interface desenvolvida, a fim de verificar se todas as telas e elementos, tais como
barras de rolagem, botões, recursos de habilitar e desabilitar elementos gráficos,
dentre outros, estavam funcionando corretamente e de acordo com o previsto.
Durante o teste foram testados diversos e diferentes caminhos que o
programa pudesse seguir, bem como a manipulação de todos os elementos
gráficos inseridos em cada estação. Baseado neste teste pode-se notar que várias
constantes de inicialização deveriam ser adicionadas no decorre do programa,
tornando o processo de inicialização um pouco lento. A fim de corrigir este caso,
65
criaram-se rotinas de inicialização, onde todos os parâmetros são definidos antes
de qualquer interferência por parte do usuário seja ele da estação cliente ou
servidor.
Além disso, testes mostraram que quando havia uma alteração entre os
modos de operação, as coordenadas que foram passadas para o robô via “Painel
de Controle” não se equivaliam a que era passada por “Joystick” e vice-versa. A
solução encontrada foi a utilização de variáveis internas que salvam as posições
de cada modo de controle e assim que havia a alteração da manipulação, essas
variáveis passam os dados salvos para serem os valores iniciais da manipulação
corrente, com isso os valores do “Painel de Controle” sempre serão iguais ao do
“Joystick” e vice-versa.
8.3 Testes da Comunicação com Dispositivos USB
Tanto a câmera de monitoramento quanto o controle, são dispositivos USB
que se são gerenciados pelo sistema operacional, sendo assim o LabView
conecta-se a eles através de seus blocos de conexão, e esses blocos buscam o
driver do dispositivo que está no sistema operacional, tendo isto em mente após a
inicialização do programa a aplicação faz somente uma varredura para ver se o
dispositivo está conectado ou não, obtendo a resposta este dado é passado ao
usuário pela interface gráfica.
Caso o dispositivo esteja desconectado e aplicação seja iniciada, o
LabView irá indicar que não encontrou o dispositivo, se o mesmo for conectado
com a aplicação ainda rodando, o LabView não tem a funcionalidade de
restabelecer a conexão deste dispositivo à aplicação.
Para este caso é necessário reiniciar toda a aplicação e garantir que todos
os dispositivos estejam conectados previamente, para garantir um melhor
funcionamento do sistema e não gerar conflitos com o sistema operacional.
8.3 Testes da Comunicação TCP/IP
Testes com esta comunicação mostram que uma seqüência lógica deve ser
estabelecida, pois quando se envia uma quantidade de dados, os mesmo serão
lidos na mesma ordem em que foram enviados, formando assim uma pilha de
informações.
66
Na comunicação TCP/IP, todos os dados enviados pelo servidor devem ser
lidos na mesma ordem de envio, pelo menos na primeira execução, ou seja, se
primeiro enviou dados sobre a posição do robô, depois dados da imagem e por
último dados de texto, os mesmos devem ser lidos na mesma ordem, posição,
imagem e texto.
Após a primeira leitura os blocos já estão com os tipos definidos e somente
será decodificado o dado pertencente àquele bloco.
Sendo assim o programa segue uma ordem de escrita e leitura por parte do
servidor e uma ordem de leitura e escrita por parte do cliente, evitando conflito
entre os dados trafegados na rede.
9 CONCLUSÃO Avaliações iniciais nas condições propostas do laboratório remoto
demonstraram a grande praticidade, funcionalidade e confiabilidade das diversas
tecnologias integradas neste sistema.
A proposta inicial era o desenvolvimento de um sistema intuitivo e de fácil
utilização por parte do aluno, auxiliando assim na educação a distância,
oferecendo-o a oportunidade de manipular um robô industrial, aplicando na prática
o aprendido na teoria. No que diz respeito à esse ponto, pode-se afirmar que a
interface desenvolvida atendeu satisfatoriamente à essa proposta, uma vez que a
manipulação a distância foi capaz de realizar todas as tarefas que se pode fazer
utilizando a programação nativa do robô.
Um ponto de melhoria identificado seria o melhor aproveitamento das
funcionalidades do robô, como rotinas de programação próprias e incorporação de
pontos salvos pelo aluno na linguagem nativa do robô. Outro ponto que pode ser
explorado é a utilização de ferramentas físicas presas à ponta do robô, para
realizar manipulações mais complexas, por exemplo, garra ou atuador pneumático.
Do ponto de vista da linguagem escolhida para o desenvolvimento, a
mesma mostrou-se totalmente adequada à aplicação, uma vez que contém
nativamente recursos para desenvolvimento de aplicações em rede, tais como as
bibliotecas prontas e desenvolvidas pelo próprio fabricante ou desenvolvidas por
usuários do software, que são publicadas no fórum do site do fabricante. As
67
bibliotecas desenvolvidas pelos usuários mostraram-se adequadas, pois os
recursos disponibilizados pelas mesmas supriram a necessidade do
estabelecimento de uma conexão confiável e estável a partir de uma fácil
parametrização. Por outro lado, um ponto a ser melhorado é a questão da
segurança ao se transmitir dados usando os recursos disponibilizados por essas
funções. As mesmas não garantem que as informações enviadas não sejam
desviadas ou até mesmo lidas e alteradas por qualquer tipo de agente malicioso.
Durante os testes de monitoramento, conexão, envio e recebimento de
informações foi mantido em funcionamento durante todo o tempo em que o usuário
utilizou o programa, não havendo nenhum travamento ou atraso, entretanto, se o
programa ficar ocioso ou realizar múltiplas repetições no modo automático
observou-se alguns travamentos e interrupções na conexão, devido ao grande
número de dados trafegados ou ao tempo de espera por um dado ser muito
grande.
Do ponto de vista comparativo com os sistemas apresentados em
Trabalhos Correlatos, a aplicação proposta aqui, utilizou muitos conceitos
apresentados nos mesmos, entretanto há alguns aspectos para serem melhorados
da área de comunicação e trafego de dados, mas em contrapartida a aplicação
apresentada foi desenvolvido em LabView, ambiente de programação voltado para
área industrial, facilitando assim a interatividade com equipamentos utilizados na
indústria, também é interessante ressaltar as possibilidades e velocidades de
comunicação conseguidas com o protocolo industrial (OPC), já que este é
desenvolvido para trafego de dados em alta velocidade e com boa confiabilidade,
não havendo lentidão nesta rede.
Além disto, a interface proposta é muito mais maleável e intuitiva para o
usuário final, pois ficou o mais enxuta possível, a fim de deixar somente o
essencial para a manipulação feita pelo aluno.
Do ponto de vista pedagógico considera-se que este uso experimental se
mostrou relativamente pobre para se avaliar tanto a desempenho do ambiente
quanto as situações de aprendizagens que ele pode propiciar em função do curto
espaço de tempo de uso. Estão previstas futuras utilizações do ambiente por
períodos de tempo mais longos a fim de se realizar essas avaliações. Ainda do
68
ponto de vista psico-pedagógico espera-se que a utilização do ambiente venha,
neste contexto, permitir o desenvolvimento de projetos colaborativos.
Baseado nessas observações e conclusões pode-se afirmar que o sistema
desenvolvido permite melhorias, como as citadas, porém atende de forma
satisfatória a proposta inicial, sendo capaz de fornecer uma interface de controle
ao aluno, para controlar e realizar uma rotina, aonde um robô industrial possa
segui-la.
Este trabalho é o princípio da manipulação robótica na educação a
distância, composta pela hierarquia: EaD, e-learning, AVA e aplicação
desenvolvida. Para tanto esta aplicação necessita estar dentro de um ambiente
virtual de aprendizado para se tornar acessível à diversos clientes ao mesmo
tempo, onde o AVA irá gerenciar os usuários e garantir que somente um por vez
manipule o robô, após está inserção é necessário disponibilizar este ambiente na
rede mundial de computadores, dando vida ao conceito de e-learning, e por fim
elaborar uma proposta pedagógica de ensino com conteúdo teórico e prático para
vir a ser um sistema EaD completo.
Para desenvolvimentos futuros, este trabalho serve como base no
desenvolvimento de novas aplicações voltadas para robôs de diferentes
fabricantes, neste caso é necessário ter conhecimento de como o robô enviará e
receberá as variáveis que indicam sua coordenada, é necessário ter uma rotina em
funcionamento no robô para que o mesmo interaja em tempo real com a aplicação
desenvolvida, sendo assim, também é preciso conhecer a linguagem nativa de
programação do manipulador e identificar quais protocolos de comunicação que o
mesmo utiliza para enviar e receber variáveis de meios externos, escrever uma
rotina indicando que o robô vá para a posição que a aplicação determinar.
Pode-se ressaltar que a grande dificuldade neste trabalho futuro é
determinar como o robô irá se comunicar com a aplicação, e vice-versa, entretanto
com o profundo conhecimento da linguagem nativa e funcionalidades do robô,
aonde se deseja utiliza esta aplicação, este procedimento se torno menos árduo.
Nesta aplicação o robô já consta com o pacote OPC, sendo ele um servidor deste
protocolo e o LabView um cliente, sem custo adicional.
69
10 REFERÊNCIAS BIBLIOGRÁFICAS BELLONI, Maria Luiza. Educação a distância. Campinas: Autores Associados,
2001. (Coleção educação contemporânea).
D’Abreu, João V. V. e Chella, Marco T., Ambiente de Telerobótica em EaD,
Anais do Workshop de Informática na Escola, 2003.
CEAD, Centro de Educação a Distância, Ministério da Educação, Assessoria de
Comunicação NEAD/UFJF
D’AlESSANDRO M. W. & INDUNI N. Educación Y Nuevas Tecnologias
Propuestas para un Madridaje Exitoso, Anais do IV Congresso Iberoamericano
de Informática Educativa Rede Iberoamericana de Informática Educativa - RIBIE,
Brasília – Brasil, 1998.
EDUCAÇÃO A DISTÂNCIA, Como e onde surgiu?, Disponível em
<http://ensinoadistancia.wikidot.com/como-surgiu-onde-surgiu>
FREDRIC M. Litto e Marcos Formiga (org.). Educação a distância: o estado da
arte. São Paulo: Pearson Education, 2009.
GARCIA, M. F. Ambiente Logo e Interdisciplinaridade: A Concepção dos
Professores. Dissertação de mestrado Faculdade da Educação FE/UNICAMP,
1995.
IWANITZ, F.; LANGE, J. OPC: Fundamentals, implementation and
applications. 2ª Edição Revisada, Editora Heidelberg-Huthig, Alemanha, 2002.
LANDIM, Claudia Maria Ferreira. Educação a distância: algumas
considerações. Rio de Janeiro, s/n, 1997.
LUCENA, Marisa. Um modelo de escola aberta na Internet: kidlink no Brasil.
Rio de Janeiro: Brasport, 1997.
NATIONAL INSTRUMENTS. About LabView. Disponível em: <http://www.ni.com>
NATIONAL INSTRUMENTS. Como Eu Uso OPC no LabVIEW?. Disponível em:
<http://digital.ni.com/public.nsf/allkb/E4F235A1643259E286257792005B0C67>
NATIONAL INSTRUMENTS. LabVIEW Datalogging and Supervisory Control
(DSC). Disponível em: <http://www.ni.com/labview/labviewdsc/>
70
NISKIER, Arnaldo. Educação a distância: a tecnologia da esperança; políticas
e estratégias a implantação de um sistema nacional de educação aberta e a
distância. São Paulo: Loyola, 1999.
OPC FOUNDATION. What is OPC?, 2011. Disponível em:
<http://www.opcfoundation.org/>
REMOTEBOT.NET, Website, disponível em: <http://remotebot.k-
team.com/museum/>
SANTOS. Edméa Oliveira. Ambientes virtuais de aprendizagem: por autorias
livre, plurais e gratuitas. In: Revista FAEBA, 2003.
SILVA M. Sala de Aula Interativa. Quarter Ed. Rio de Janeiro, 2000.
TANENBAUM, A. S. Redes de Computadores, 4ª. Edição, Editora Campus, 2003.
TORRES, G., Lima, C., Como o Protocolo TCP/IP Funciona. Disponível em
<http://www.clubdohardware.com.br/>
VILLAPLANA, A. C. La informática educativa: una reflexión crítica. Revista
Electrónica Actualidades Investigativas en Educación, Madrid, 2002.
WIKIPÉDIA, Educação a Distância., Disponível em
<http://pt.wikipedia.org/wiki/Educa%C3%A7%C3%A3o_a_dist%C3%A2ncia>
WIKIPÉDIA, E-lsearninig., Disponível em < http://pt.wikipedia.org/wiki/E-learning>
71
APÊNDICE A – Código Fonte da Estação Servidor Encontra-se em arquivo separado na mídia entregue e em anexo à este trabalho.
APÊNDICE B – Código Fonte da Estação Cliente Encontra-se em arquivo separado na mídia entregue e em anexo à este trabalho.