desenvolvimento de uma interface para teleoperação ... · palavras-chave: braço robótico, ......

Revista Eletrônica Produção & Engenharia, v. 3, n. 2, p. 301-312, Jul./Dez. 2010. 301

Desenvolvimento de uma interface para teleoperação robótica com

transporte de dados via TCP/IP e comunicação serial utilizando

JAVA

Marlon José do Carmo

[email protected]

Rodrigo de Albuquerque Pacheco Andrade

[email protected]

André Del Bianco Giuffrida

[email protected]

Angelo Rocha de Oliveira

[email protected]

RESUMO

Este trabalho apresenta um projeto de teleoperação robótica e teve como objetivos projetar e implementar um

sistema que possibilite operar e monitorar um braço robótico com seis graus de liberdade via internet. Para a

realização do trabalho, foi utilizado um Robô Industrial da ABB, modelo IRB 2400/10, do Laboratório de

Otimização de Processos de Fabricação (LOPF), pertencente ao Núcleo de Manufatura Avançada (NUMA) da

USP, de São Carlos, SP, em parceria com o CEFET-MG Campus III-Leopoldina. Nesse projeto, os softwares

foram desenvolvidos em JAVA, envolvendo acesso à porta serial, porta USB e transporte dos dados através do

protocolo TCP/IP. Com o sucesso da conclusão do trabalho, o robô pôde ser operado e monitorado de

qualquer lugar do mundo, tendo como aplicação direta a teleoperação em ambiente cuja problemática seja a

segurança intrínseca.

Palavras-chave: Braço robótico, Teleoperação, Processos de fabricação.

Developing an interface for robotic teleoperation data transport over TCP/IP and

serial communication using JAVA

ABSTRACT

This paper presents a robotic teleoperation’s project and aims to design and implement a system which enables

to monitor and to operate a robotic arm with six degrees of freedom through the Internet. To conduct the work,

it was used an ABB Industrial Robot, model IRB 2400/10, from the Optimization Laboratory of Manufacturing

Process Optimization (OLMP, belonging to the Center for Advanced Manufacturing (CAM) at USP, São

Carlos – SP, in partnership with the CEFET from the MG-Campus III Leopoldina. In this project, the software

was developed in JAVA involving access to serial port, USB port, and transport of data via TCP/IP. With the

successful completion of this work, the robot can be operated and monitored from anywhere in the world,

having as direct application the teleoperation in an environment in which the problem is intrinsic safety.

Keywords: Robotic Arm, Teleoperation, Manufacturing processes.

Marlon J. do Carmo, Rodrigo de Albuquerque P. Andrade, André Del Bianco Giuffrida e Angelo R. Oliveira

302 Revista Eletrônica Produção & Engenharia, v. 3, n. 2, p. 301-312, Jul./Dez. 2010.

1. Introdução

Desde os tempos mais primórdios, o ser

humano tem feito uso de ferramentas que estendam

seu alcance, com o objetivo de aumentar sua

destreza, seja qual for a aplicação. Os homens das

cavernas, por exemplo, utilizavam galhos de árvore

para cavar covas, fazer fogo, extrair raízes que

serviam como alimento ou até para servir de lança,

seja para caça, seja para pesca. Recentemente, há os

ferreiros como exemplo dos que utilizavam, e

utilizam, ferramentas que facilitam o manuseio de

objetos quentes. É claro que há certa limitação

quanto ao manuseio desse objeto quando

comparado com a mão humana. Tal limitação é

imposta pela natureza da ferramenta utilizada.

A teleoperação é uma técnica

particularmente interessante, pois permite que

determinado trabalho seja realizado remotamente,

mas ainda sim controlado pelas próprias mãos, em

circunstâncias em que a ação direta não é possível,

inadequada ou em situações em que é impossível

estabelecer rotinas para a operação, seja pela sua

imprevisibilidade, grau de risco ou complexidade

(AGUIRRE, 2007).

Com a evolução e desenvolvimento de

novas tecnologias, algumas tarefas que antes

pareciam ser impossíveis de executar, hoje, com o

auxílio da teleoperação, são perfeitamente

possíveis.

Os pioneiros da pesquisa em radioatividade

tomaram conhecimento dos perigos da radiação na

primeira parte deste século, e precauções de

segurança não foram tomadas quando a

manipulação de isótopos radioativos naturais era

realizada, até que os perigos da irradiação (através

da inalação ou absorção) foram descobertos. A

partir desse momento, percebeu-se que corpos

radioativos tinham que ser manipulados a uma

distância grande o suficiente para diminuir o efeito

da radiação. Garras de laboratório e pinças de

manipulação a distância eram usadas para

manipular objetos a uma distância de até 50 cm de

distância.

Como a atividade das fontes tratadas

aumentou os mecanismos de manipulação a

distância, elas se tornaram mais comuns, e a

manipulação de material radioativo era feita atrás de

barreiras de proteção que reduziam a radiação,

juntamente com uma janela de vidro, que permitia

que a manipulação pudesse ser observada. A troca

das primeiras varetas radioativas dos reatores

nucleares foi realizada em 1943, sendo estes

desenvolvidos por Oak Ridge e Argonne National

(MARTINS, 2008), utilizando sistemas de cabos,

carrinhos e pinças para que esses materiais

pudessem ser movimentados até certa distância

(AGUIRRE, 2007).

A teleoperação de veículos robustos no

espaço para acesso a ambientes desconhecidos e

não estruturados permitirá a inspeção, manutenção,

montagem e outras atividades críticas no espaço.

Hoje, os robôs não necessitam de atenção e

dedicação exclusivas de um operador (ÁLVARES,

2001).

Desde o ano 2000, a NASA vem

desenvolvendo um novo modelo de interação entre

humanos e robôs, com controle colaborativo, que se

baseia no diálogo entre humanos e robôs. Ao invés

de um supervisor ficar ditando as funções ao

subordinado, robôs e seres humanos conversam

para trocar informações, fazer perguntas e resolver

problemas. Com essa abordagem, a interação entre

humanos e robôs fica mais natural, equilibrada e

direta do que as abordagens convencionais. Com o

controle colaborativo, as funções humanas servem

como um recurso para os robôs. Como

consequência, o robô pode fazer perguntas do tipo:

“Com base nessa imagem, é seguro para avançar?”

Isso permite que o ser humano contribua

compensando a autonomia limitada do robô, mas

sem forçá-lo a dedicar atenção contínua para o robô

(ÁLVARES, 2001).

Recentemente no Brasil, um sistema de

teleoperação para um manipulador mestre-escravo

de 3 GDL foi desenvolvido, utilizando-se

realimentação háptica como forma de operação a

distância Uma área em que o sistema poderia

facilmente ser aplicado seria a militar. Uma

situação fácil de exemplificar é a tentativa de

desarme de minas terrestres sem que haja

detonação. Para maior segurança da pessoa

responsável, o sistema lhe permitiria estar em um

local distante e seguro e receber as sensações

hápticas importantes e necessárias na execução

dessa tarefa, como se estivesse o próprio

manipulando a mina (CORREIA, 2008).

O Brasil começou a corrida tecnológica,

iniciada em 1946, bastante atrasado. Segundo

Gudrun Litzenberger, chefe do Departamento de

Estatística da Federação Internacional de Robótica

(IFR) e secretária geral da Federação na Alemanha,

há hoje cerca de um milhão de robôs em operação

no mundo. Dois terços deles estão instalados no

Japão, na América do Norte e na Alemanha, os

Desenvolvimento de uma interface para teleoperação robótica com transporte de dados via TCP/IP e

comunicação serial utilizando JAVA


mercados mais importantes. O Brasil tem apenas

quatro mil robôs. “Nossa estatística pode estar

subestimada, porque só temos dados completos do

Brasil a partir de 2004, mas, de qualquer forma, o

grau de automação ainda é muito baixo”, segundo

Correia (2008).

De acordo com a Robotic Industries

Association – RIA, fonte oficial de estatísticas do

setor nos Estados Unidos, em 2008 havia cerca de

182 mil robôs, número superado apenas pelo Japão

(CORREIA, 2008).

Muitos desses robôs presentes no Brasil não

são teleoperados, ou seja, exige a presença de um

operador próximo ao robô para ser devidamente

operado. É mais do que óbvio que, com o passar do

tempo, esses robôs vão ficando ultrapassados, e os

preços para atualizá-los são exorbitantes.

O Robô IRB 2400/10 da ABB é um ótimo

exemplo. Com um sistema fechado, onde só é

possível operá-lo fazendo uso de seu Joystick

denominado Teach Pendant, é um tipo de robô

muito comum nas indústrias brasileiras.

Atualmente com a globalização com

crescimento em exponencial e a disputa pelo

mercado consumidor, faz que as empresas a cada

dia mais tendam a produzir produtos novos e

diferenciados. E para isso são comuns a mudança

do leiaute do chão de fábrica, a calibração e

reprogramação de robôs para se adaptar ao novo

leiaute do novo produto.

Um tipo comum de problema que ocorre é

com relação à reconfiguração realizada nesses

robôs, pois é necessária a presença real do

técnico/engenheiro. O que pode levar muito tempo

e dinheiro, pois nem sempre poderá existir um

profissional apto e disponível naquele local e

momento. Portanto, imagine-se a situação descrita

no parágrafo subsequente.

Certa montadora no Brasil possui 30 robôs

distribuídos em seis plantas, em locais distintos e

afastados. A montadora dispõe de três engenheiros

especializados nesses robôs industriais. É chegado o

segundo trimestre, e os novos modelos já estão

sendo produzidos, porém os 30 robôs precisam

urgentemente ser reconfigurados em alguns

parâmetros internos e realinhar os pontos de

soldagem, pois a configuração anterior fez que as

peças tivessem problemas no setor de qualidade.

Acontece que a distância física que existe entre as

plantas impede que os engenheiros reconfigurem

todos os robôs a tempo, fazendo que a montadora

pare a produção e perca dinheiro.

E se fosse possível realizar essas alterações,

sem sair do escritório? O trabalho proposto é

direcionado para esses tipos de robôs e soluciona

esse e outros tipos de problemas, pois, muitas

vezes, a presença de um operador no local de

atuação do robô, nem sempre é possível, seja por

insalubridade, seja por periculosidade.

No âmbito do ensino, a teleoperação é

extremamente útil, pois o mesmo robô, uma vez

feito teleoperado, poderá servir para ensinar a

alunos de qualquer lugar do mundo, sem a

necessidade de sair de sua própria sala de aula. É o

ensino a distância ganhando forças no ramo da

robótica.

A principal motivação deste trabalho foi o

desenvolvimento de um sistema (baseado em

hardware, firmware e software) que permite a

teleoperação do Robô IRB 2400/10 da ABB.

É importante ressaltar que o projeto tem

duração que transpõe a data de apresentação deste

trabalho, portanto os resultados apresentados aqui

são parciais e não caracterizam de forma completa o

estudo. O trabalho proposto é o início de um projeto

maior, que terá sequência no Laboratório de

Otimização de Processos de Fabricação da USP, de

São Carlos. Uma vez que o projeto tenha sucesso

com o robô descrito, ele também será aplicado em

outros robôs e centros de usinagem.

2. Descrição do robô

O robô industrial é um manipulador

multifuncional reprogramável projetado para mover

materiais, peças, ferramentas ou dispositivos

especiais, através de movimentos variáveis

programados, possibilitando a realização de uma

variedade de tarefas (ÁLVARES; ROMARIZ,

2002).

O que distingue um robô de outros

dispositivos de movimentação é sua habilidade de

ser reprogramado para o cumprimento de tarefas

distintas. A maioria dos robôs modernos possui a

capacidade de armazenar diversos programas na

memória, permitindo, com um simples apertar de

um botão, selecionar o programa desejado para a

realização de determinada tarefa.

O robô é composto por duas partes

principais: caixa de controle (controlador) e

manipulador, como mostrado na figura 1.



Manipulador

Controlador

Figura 1 - Controlador e manipulador

A Interface Homem-Máquina é realizada

através do teach pendant e, ou, do painel de

operação, localizado na parte frontal do controlador,

como mostrado na figura 2.

Teach Pendant Painel de Operação

Figura 2 - Interface homem-máquina

O manipulador IRB 2400/10 é equipado

com motor AC e freios eletromecânicos em todas as

juntas. Os freios travam todos os eixos do robô

quando este permanecer inoperante por mais que 3

min (ABB Flexible Automation, 1990a).

A Figura 3 mostra os vários graus de

liberdade do manipulador e suas principais partes.

Eixo 1

Eixo 2

Eixo 3

Eixo 6

Eixo 5

Eixo 4

Figura 3 - Graus de liberdade do braço manipulador

O controlador contém toda a eletrônica

responsável pela operação do manipulador e dos

demais equipamentos periféricos. A Figura 4 indica

a localização dos vários componentes da caixa de

controle (ABB FLEXIBLE AUTOMATION,

1990b).

Chave geral Painel do Operação

Teach Pendant

Disk Drive

Figura 4 - Componentes do controlador

A seguir são apresentadas as

funcionalidades com as descrições de todos os

botões do Teach Pendant.

Teclas de Menu

Teclas de

Janela

Teclas de

Movimento

Incremental

Apagar

Stop

Contraste

Teclas de

Navegação

Enter

Teclas

Numéricas

Teclas de Função

Tela

Figura 5 - Teclas do teach pendant

Toda a eletrônica responsável pelas tarefas

de controle e supervisão é montada na caixa de

controle. As Figuras 6 e 7 indicam a posição das

unidades e placas eletrônicas a partir das visões




frontal e superior da caixa, considerando-se as

portas abertas.

Unidade Computacional

Painel frontal do controladorDisjuntores

Figura 6 - Painel frontal do controlador

Painel superior do controlador

Módulos I/O

Bateria

Conexão Serial

Painel

(Cadeia de segurança)

Conexões: sinais de

Potência e de Sensores

Figura 7 - Painel superior do controlador

O robô apresenta dois canais de

comunicação serial: RS232 e RSS485/RS422 Full

Duplex. Esses canais podem ser utilizados para

comunicação ponto a ponto com impressoras,

terminais, computadores e outros equipamentos.

Esses canais seriais podem ser utilizados

com velocidades de 300 a 19.200 bits/s, e o sistema

suporta apenas um canal com a velocidade máxima.

Para taxas mais elevadas ou para

comunicação em rede, os robôs podem ser

equipados com interface ethernet.

3. A comunicação entre o teach pendant e o

controlador

O IRB 2400 é um robô industrial com seis

graus de liberdade, projetado especificamente para

indústrias que fazem uso da automação de um modo

maleável. O robô tem estrutura aberta e é

especialmente adaptado para uso flexível e pode se

comunicar intensamente com os sistemas externos,

como sensores atuadores, impressoras etc. (ABB

FLEXIBLE AUTOMATION, 1990a).

A comunicação com o computador é, porém,

extremamente limitada, pois essa versão S4C do

controlador não possui protocolo de comunicação

aberto. O que permitiria algumas funções básicas

através da comunicação serial EIA-232, como a

movimentação do braço robótico, salvar, editar e

carregar arquivos através de um computador.

Assim, à primeira vista, é inviável a operação a

distância de um robô com essas características.

Como a proposta é deslocar o Teach

Pendant, resta saber quais são as ações tomadas por

ambas às partes quando a comunicação física é

interrompida.

O ato de deslocar o TP é fazê-lo se

comunicar com o controlador, sem estar conectado

fisicamente, utilizando para isso conversores, placas

de aquisição, computadores e outros periféricos.

Em um projeto de teleoperação envolvendo

um robô com protocolo de comunicação fechado,

existem grandes riscos de a teleoperação não ser

bem-sucedida, seja pela limitação natural do

sistema, seja imposta pelos projetistas, portanto se

faz necessário realizar testes passo a passo para

assegurar a viabilidade do projeto.

3.1. Entendendo a comunicação

Para entender como funciona a comunicação

do robô, vários testes foram realizados. O primeiro

teste foi executado com o robô ligado e

funcionando no modo manual. O cabo que liga o TP

ao controlador foi desconectado. O resultado foi

uma parada imediata do robô. Ao reconectar o cabo,

percebeu-se que apareceu um erro na tela do TP

informando que a conexão havia sido perdida e a

parada de emergência, ativada. Após religar os

motores, o robô continuou funcionando

normalmente. Esse teste indica que não é necessário

reinicializar o controlador, caso o cabo se

desconecte.

Teste dos Conversores EIA-485/EIA-

232

O cabo de conexão do Teach Pendant é

formado por 10 fios:

4 fios para liberar os freios

4 fios para parada de emergência

2 fios de comunicação com padrão EIA

485

Os computadores convencionais não

possuem suporte ao tipo de padrão EIA 485,

portanto dois conversores EIA-485/EIA-232 são

utilizados para a comunicação com os PCs. Um

teste extremamente importante parte do princípio

em conectar os conversores entre si para ver se o

robô funciona.

O esquema de ligação segue na Figura 8.



Figura 8 - Teste utilizando conversores RS-485

O sucesso da ligação dos dois conversores

EIA485/EIA232 entre si mostra que é viável

trabalhar com o padrão EIA232, que será utilizado

para levar o sinal até o computador.

Vale ressaltarar que os outros oito fios de

segurança não trabalham com o mesmo padrão,

portanto terão que ser transportados de maneira

diferente, e no início dos testes eles foram mantidos

conectados fisicamente entre o Teach Pendant e o

controlador, e somente os dois fios de comunicação

passaram pelos testes. O tratamento dos sinais dos

oito fios será discutido mais na frente, e por

convenção os fios não estão sendo mostrados nas

figuras.

3.2. Inserindo um PC no caminho

O próximo passo é ligar cada um dos dois

conversores em um PC com duas portas seriais,

como mostrado na Figura 9.

Figura 9 - Teste utilizando um PC com duas conexões seriais

O resultado desse teste, se executado com

sucesso, demonstra se é possível utilizar um PC

para transportar os dados. O computador

inicialmente servirá apenas como uma bridge para

os sinais.

Utilizando o software Labview® (RITTER,

2002), famoso programa para criação de

instrumentos virtuais diversos, uma Virtual

Instrumente (VI) foi criada, a fim de ler os dados de

uma porta serial e escrever na outra e vice-versa. A

Figura 10 ilustra a montagem do VI utilizado.

Figura 10 - Virtual instrument montado no Software Labview




3.3. Descobrindo o Baud Rate

Quando se adiciona um computador no meio

da transmissão, alguns conceitos devem ser

observados. Um software para ler e reproduzir

fielmente um dado conectado à porta serial deverá

estar configurado exatamente no mesmo Baud Rate

utilizado pelo TP. O Baud Rate é a velocidade em

que um equipamento consegue transmitir os dados,

e a configuração incorreta desse valor impossibilita

a comunicação.

Realizando uma pesquisa no User Guide

(ABB Flexible Automation, 1990a) e no Product

Manual (ABB FLEXIBLE AUTOMATION,

1990b) do robô, esse valor em nenhum momento é

citado. O manual do fabricante cita que a máxima

velocidade que as Inputs e Outputs (IO) seriais do

controlador trabalham é 19.200. Portanto, na base

da tentativa e erro, configurou-se o VI com valores

de 19.200, 9.600 e 4.800, entre outros, porém sem

sucesso. A dúvida que pairava com relação ao que o

computador estava recebendo de dados fez que

fosse criado um cabo específico que lesse tanto o

que o TP escrevia quanto o controlador. A Figura

11 ilustra essa configuração.

Figura 11 - Teste para a leitura dos sinais de comunicação

Esse cabo específico na verdade se divide

em dois, em que um deles lê o sinal do RX e o outro

lê o sinal do TX do cabo serial que transporta os

dados. Utilizando o VI no Labview, os valores

foram lidos em diversas frequências distintas, e não

tinham sentido algum. O Teach Pendant sempre

informava a seguinte mensagem:

“Teach Pendant connection lost.”

Pensou-se até que o sinal poderia ser

criptografado para proteger contra alterações, mas

logo essa ideia foi descartada, porém se acreditava

que não seria possível ler e reproduzir os sinais por

alguma limitação imposta pelos desenvolvedores.

No entanto, fazendo uso de um osciloscópio, pode-

se diagnosticar o valor correto do Baud Rate. E o

valor aferido foi de 38.400 bauds, o que indica que

a informação da frequência dada pelo Product

Manual não se enquadrava na conexão do Teach

Pendant.

Com a frequência correta determinada, os

dados agora, quando lidos pelo PC, faziam sentido,

e era possível até ler as mensagens de aviso que

eram impressas na tela do TP.

Utilizando o VI da Figura 10, pela primeira

vez a mensagem de “conexão perdida” que sempre

era mostrada na tela deu lugar às mensagens de

inicialização do robô. Nesse momento, a

teleoperação começava a tomar forma. Mas, em

determinado momento, a comunicação

simplesmente travou e o robô teve de ser reiniciado.

Esse problema curioso intrigou bastante o

grupo e, após certo tempo, foi solucionado. O

momento no qual a comunicação é interrompida

origina-se quando ambos trocam uma grande

quantidade de informações. E o “buffer” da serial

do PC é limitado e acabou “transbordando”, e os

dados enviados de seus remetentes não foram

entregues ao destinatário. E, como nesse caso não

existe sinal de aviso de chegada de mensagem,

ambos ficaram esperando a resposta um do outro.

Como esse problema é causado pelo teste

em um PC com duas seriais, e a solução foi pular o

teste com apenas um PC e testar diretamente a

comunicação entre dois PCs em rede.

3.4. Alcançando o sucesso utilizando dois PCs em

rede

Utilizando um software chamado de

TCPCom (DEILTEL, 2010) (que tem a propriedade

de ler/enviar os dados de/para uma porta serial e

enviar e receber via TCP/IP para/de outro

computador que faz uso do mesmo software), dois

computadores ligados em uma rede local foram

configurados como mostrado na Figura 12.

Figura 12 - Teleoperação com dois Pcs em rede



Configurando o software do PC do

controlador como Servidor e o software do PC do

TP como Cliente, tudo estava pronto para o teste de

teleoperação. E pela primeira vez foi possível

teleoperar o robô com sucesso. O problema de

buffer não existe neste caso, pois apenas uma porta

serial é utilizada em cada PC.

Com o sucesso desse último teste, veio

finalmente a certeza de que era possível teleoperar o

robô de qualquer lugar do mundo. Porém, faz-se

necessário também transportar os sinais dos outros

oito fios descritos no início deste capítulo. Para

isso, duas placas de aquisição serão projetadas e

desenvolvidas. Uma placa acompanhará o Teach

Pendant, junto com um conversor EIA-485. A outra

placa será conectada ao controlador, juntamente

com o conversor restante.

3.5. Placas de Teleoperação

As placas de aquisição serão responsáveis

por ler os dados de segurança entre o TP e o

controlador. Para transportar esses dados fielmente,

um estudo acerca dos sinais nos 10 fios foi feito.

Figura 13 - Esquema elétrico de comunicação do Teach

Pendant

A Figura 13 representa o esquema elétrico

de sinais do TP. Como se pode perceber, 10 fios são

responsáveis por todas as informações trocadas

entre o Teach Pendant e o controlador.

Os sinais TP e TP-N são

responsáveis pela troca de informações entre o

controlador e o robô, em que os dados que chegam

ao TP indicam as posições dos eixos do robô que

serão exibidas na tela, ou alguma mensagem. Todos

os testes feitos anteriormente se referiam ao

transporte desse sinal. Os outros oito fios são

responsáveis por transportar os sinais de segurança,

Enable Device e Emergency Stop.

O botão de Enable Device (Botão de

Habilitação) serve para liberar os freios dos motores

quando o robô estiver no modo de operação manual

<250 mm/s ou 100%. E, quando acionado, o robô

poderá ser levado para a condição MOTORS ON. A

liberação desse botão provocará a parada do robô e

o acionamento dos freios. Já o botão de Emergency

Stop (parada de emergência) para imediatamente o

robô quando é pressionado, independentemente do

modo ou estado do sistema. Esse botão permanece

apertado e deve ser retornado à posição original

para que o robô volte à condição MOTORS ON.

Os oito fios restantes são responsáveis por

transportar esses sinais de segurança. Os sinais de

24V TP e 0V são responsáveis pela alimentação do

TP. A diferença de potencial entre os sinais EN1 e

EN2 indicam para o controlador se o botão de

Enable Device foi (ou não) acionado. Os sinais

ES2A e ES1A possuem entre si ddp de 24V, que

são devolvidos para ES2B e ES1B,

respectivamente, caso o Emergency Stop não esteja

pressionado, pois o botão é normalmente fechado.

Levando em consideração que esses sinais

devem ser levados para lugares distantes, faz-se a

necessidade de fazer a aquisição desses sinais,

através de uma placa.

Essas placas de aquisição precisam ler os

dados e enviar ao PC, bem como receber os dados

do PC e escrever na saída da placa.

A partir dessa indigência, começou-se a

projetar duas placas de aquisição de dados. Uma

para o Teach Pendant e outra para o controlador.

Essas placas foram projetadas utilizando como base

um microcontrolador da Microchip, modelo

PIC18f4550. A característica principal desse PIC é

a comunicação via USB com o computador (DE

SOUZA; SOUZA, 2008). Essas placas serão

responsáveis por ler os sinais de ambos os lados e

enviar para o computador ao qual estiverem

conectadas. Esses computadores, por sua vez,

através do software de teleoperação, empacotarão

esses dados, junto com os sinais lidos da porta

serial, e fará o envio via TCP/IP para o servidor,

que encaminhará essas mensagens recebidas para o

destinatário.

O projeto da placa de aquisição foi feito

baseado em uma placa feita pela própria Microchip

(PICDEM™ FS USB Demo Board) (DE SOUZA;

SOUZA, 2008), para aquisição de dados.

3.6. Placa de Teleoperação – Teach Pendant

A placa de Teleoperação do TP será

responsável pelas seguintes tarefas:

Fornecer alimentação de 24 v para o

NF

ES2A

ES1A

ES1B

ES

2B




Teach Pendant

Comunicar com o PC Via USB

Ler, empacotar e enviar ao PC o estado

de cada um dos seguintes botões:

Enable Device

Emergency Stop

Motors On

Receber e desempacotar os sinais do PC e

acionar os LEDs que indicarão o estado de cada

uma das ações a seguir:

Enable Device

Emergency Stop

Motors On

É necessário saber exatamente que tipo de

dados devem ser lidos e, por isso, antes de qualquer

coisa é extremamente necessário fornecer, através

de uma fonte externa, a tensão CC de 24 v para

alimentar o circuito do TP. Portanto, a placa do

Teach Pendant contará com uma fonte com a tensão

indicada anteriormente conectada ao circuito.

O sinal do Enable Device é advindo

justamente dos mesmos 24 v que alimentam o TP. E

por esse motivo adicionou-se à placa um relé de

24v, que chaveia os 5V que acionam (ou não) a

porta RB4 do PIC.

O sinal do Emergency Stop também é

advindo de uma tensão de 24 v, porém essa tensão

não alimenta o circuito interno do TP. Um relé,

semelhantemente ao utilizado anteriormente, foi

usado para chavear o sinal de 5 v na entrada RB5 do

PIC.

O sinal do Motors On, diferentemente dos

dois anteriores, não faz parte originalmente do

Teach Pendant e foi adicionado à placa por questão

de necessidade, visto que para a operação manual

do robô é necessário, antes de Liberar o Freio

(acioando a Enable Device), acionar o botão Motors

On, que originalmente se encontra no painel do

controlador. Esse sinal vem através de uma botoeira

que chaveia 5 v da própria placa, na porta RB3 do

PIC.

Nas três chaves anteriores, utilizou-se um

resistor Pull-Down de 10 k para assegurar o valor

de 0 v, pois na transição dos contatos o pino ficará

com um valor indeterminado (em aberto) e sujeito a

ruídos, o que pode causar mau funcionamento do

firmware.

A distância física entre o TP e o controlador

é fator de pouca importância, desde que a latência

entre o PC do TP e do controlador seja baixa.

Os sinais de entrada na placa de

teleoperação foram o Enable Device, Emergency

Stop e Motors On. Esses sinais serão transportados

até serem entregues no controlador. Porém, o

tráfego do sinal, até o controlador em definitivo,

leva certo tempo, geralmente na ordem de

milissegundos, mas que, dependendo da conexão,

pode chegar até a ordem de segundos. Levando esse

aspecto em consideração, é interessante para o

operador saber o atraso com que essas informações

são entregues. Para isso, a placa foi projetada, com

três LEDS nas saídas RD2, RD3 e RD4, que

indicam o acionamento dos três sinais citados,

respectivamente. Porém, o sinal lido para

acionamento desses três LEDs, não é diretamente o

valor dos sinais de entrada no PIC.

Pegando como exemplo o Enable Device, ao

pressionar esse botão, chaveia-se o sinal na Placa e

ele envia os sinais ao PC, ao qual está conectado.

Esse PC, através do software desenvolvido

(apresentado no próximo capítulo) e fazendo uso de

uma conexão TCP/IP, envia os sinais até o PC do

controlador. Esse PC, através do software de

teleoperação, repassa os sinais à placa de

teleoperação do controlador, e a placa, por sua vez,

ativa o relé que aciona o Enable Device. A mesma

placa envia ao PC o valor atual do EN, e esse sinal é

enviado de volta ao PC do TP, que aciona o LED

mostrando que o Enable Device foi acionado.

Assim, é possível determinar, visualmente, a

latência da conexão que une os dois sistemas. Esse

processo é semelhante ao PING-PONG utilizado

nos computadores para saber o tempo que leva para

uma mensagem ir e voltar de algum outro PC.

A Figura 14 ilustra a primeira versão da

placa de teleoperação do Teach Pendant.

Figura 14 - Placa de teleoperação - Teach Pendant



3.7. Placa de teleoperação – Controlador

A placa de teleoperação do controlador será

responsável pelas seguintes tarefas:

Comunicar com o PC Via USB.

Ler, empacotar e enviar ao PC o estado

da lâmpada sinalizadora do Motors On.

Receber e desempacotar os sinais do PC

e chavear os relés referentes aos

seguintes sinais do Teach Pendant:

Enable Device.

Emergency Stop.

Motors On.

Esses valores recebidos, do Enable Device e

Emergency Stop, também deverão retornar ao PC

do TP para acionar os LEDs indicadores.

A função física principal dessa placa é

substituir o Teach Pendant por dois relés e, com

outro relé, chavear o Sinal de Motors On.

O único sinal que a placa capta

externamente é o estado da luz (que pisca) no botão

Motors On (ou não) a porta RB3 do PIC.

Os outros dois sinais que a placa recebe

advêm da própria placa e são os valores dos estados

dos botões Enable Device e Emergency Stop.

Esses três valores são empacotados e

enviados para o PC, que empacota esses dados e,

junto com os dados internos do Teach Pendant, são

enviados até o outro PC.

Considerada a parte mais importante, pois

nela estão contidos os três relés que chavearão os

estados emitidos no controlador pelos botões no

Teach Pendant, que percorreram todo o caminho. O

Sinal do Enable Device é normalmente aberto. Em

questões de projeto, isso significa que na posição

NO do relé duplo nada será conectado, pois o sinal

deverá ficar aberto para que atinja o valor de -24 v

(intrínseco ao projeto do controlador). E na posição

NC os dois sinais EN1 e EN2 são conectados. O

Motors On funciona do mesmo jeito que o Enable

Device. Já no caso do Emergency Stop, que é NC,

os Sinais ES2A e ES1A são conectados aos comuns

e os sinais ES1B e ES2B, conectados ao lado NO.

A Figura 16 mostra a placa de teleoperação

do controlador.

Figura 16 - Placa de teleoperação – Controlador

4. Softwares e firmwares de teleoperação

O projeto de teleoperação robótica utiliza

placas microcontroladas para fazer a aquisição dos

dados e de computadores para enviar e receber os

dados via internet, portanto é extremamente

necessário o desenvolvimento de Softwares e

Firmwares específicos para o projeto.

Como se pode perceber, as palavras

software e firmware estão no plural. Isso quer dizer

que estão sendo desenvolvidas duas versões de

cada. O software será dividido entre duas versões de

clientes e um servidor. Utilizando a API Java.net.,

um dos clientes ficará no computador onde o Teach

Pendant está conectado e o outro ficará no

computador cujo controlador se encontrava. O

servidor também ficará no PC do controlador.

Os firmwares por pertencerem a placas

fisicamente diferentes também são distintos e

compatíveis com seus propósitos.

Os softwares responsáveis pela teleoperação

foram desenvolvidos utilizando a linguagem Java.

A linguagem Java possui um grande

benefício quando comparado a outras plataformas

de desenvolvimento. O software, uma vez

desenvolvido, poderá ser executado em diversas

plataformas sob uma mesma compilação, ou seja,

não é necessário reescrever ou, nem mesmo,

recompilar o código fonte como é comum em outras

linguagens. Porém, existem algumas desvantagens.

Pois fazer comunicação diretamente com o

hardware torna a vida do programador um pouco

mais árdua.

A teleoperação de um sistema legacy como

o do robô só é possível se reproduzir exatamente

aquilo que for lido, ou seja, não é possível acessar o

controlador e operar o robô somente utilizando um

computador, pois para essa versão do robô não é

disponibilizado um protocolo de comunicação com

as funções básicas do robô. É necessário fazer a




aquisição dos sinais do cabo do TP e, através de

dois computadores conectados à internet, reproduzir

os sinais (respeitando o padrão de comunicação de

cada sinal) para o controlador e vice-versa.

Portanto, o software de teleoperação é um fator

fundamental nesse processo.

Para que a teleoperação ocorra com sucesso,

é necessário que o operador enxergue exatamente o

que está acontecendo e com o menor atraso

possível, para aumentar a sensação de presença.

O primeiro passo, para o projeto do software

de teleoperação, é especificar exatamente o papel a

ser desempenhado por ele.

O cabo que liga o Teach Pendant e o

controlador possui 10 fios, sendo dois deles

responsáveis pela troca de dados entre o Teach

Pendant e o controlador, e os outros oito são

responsáveis por levar os sinais de segurança

Enable Device e Emergency Stop, além de

alimentar o TP com 0 e 24V.

O padrão de comunicação dos dois

primeiros sinais é o RS485, que fazendo uso de um

conversor RS485/RS232 é possível conectar a um

computador que possua uma conexão serial.

Portanto, o primeiro desafio no campo do

desenvolvimento do software foi trabalhar com a

comunicação serial em Java.

4.1. Comunicação Serial em JAVA

A Sun e demais empresas envolvidas no

desenvolvimento Java desenvolveram algumas

APIs para facilitar o trabalho, como é o caso da API

RXTX (API RXTX, 2010) para a comunicação

tanto serial quanto paralela, podendo, também,

trabalhar via USB como será também o caso nesse

projeto.

A API RXTX é baseada na API Javacomm

(JAVA COMUNICATIONS API, 2010) distribuída

pela própria Sun, com a seguinte vantagem: essa

API é portável para Linux, Windows e Mac, o que

garante a vantagem de construir um software que

roda em qualquer plataforma.

A placa de aquisição de dados, que

transporta os sinais do Enable Device, Emergency

Stop e Motors On, possui comunicação USB,

utilizando no firmware a classe CDC, faz que a

placa de teleoperação seja vista como uma conexão

serial pelo PC ao qual estiver conectada. Essa tarefa

facilita a vida do desenvolvedor do software, uma

vez que ele já faz leitura serial utilizando a API

RXTX.

4.2. Comunicação entre os softwares

As informações, tanto das placas de

teleoperação quanto dos sinais de comunicação,

precisam ser enviadas do TP para o controlador e

vice-versa. O elo entre os processos do servidor e

dos clientes (PC-TP e PC-Controlador) é o socket.

Ele é a “porta” na qual os processos enviam e

recebem mensagens. Portanto, socket é a interface

entre a camada de aplicação e a de transporte dentro

de uma máquina. Inicialmente, o cliente deve se

comunicar com o servidor da seguinte maneira: O

servidor determina previamente determinada porta

e, com um socket, fica aguardando conexões nela.

Já o cliente, através do IP do servidor e da porta

previamente estabelecida, solicita uma conexão

com esse servidor.

Por sua vez, o servidor aceita a conexão

gerando um novo socket em determinada porta do

lado do servidor, criando um canal de comunicação

entre o cliente e o servidor, permitindo, assim, a

liberação do socket inicial para que este possa ser

chamado por outros clientes.

A API Java.net possui um conjunto de

funções bem conhecidas que realizam essas tarefas

de acesso. Essas bibliotecas implementam o código

necessário internamente e disponibilizam uma

interface-padrão para que as aplicações Java

possam executar essas tarefas.

Para identificação, os clientes recebem um

nome de remetente e do respectivo destinatário.

Figura 17 - GUI inicial do software de teleoperação

O funcionamento da teleoperação pode ser

apreciado em: <http://www.youtube.com/

watch?v=JHxGcm-bZMU>.

5. Conclusões

Durante a execução deste trabalho, foi

possível determinar a possibilidade de teleoperar o

Robô IRB 2400/10 da ABB. Esse robô que possui

protocolo de comunicação fechado, em que a

solução encontrada para o seu manuseio foi



deslocar o TP, utilizando placas de aquisição,

conversores EIA-485/EIA-232 e computadores para

enviar, através da rede, as mensagens para o outro

PC.

Essa nova metodologia para interface de

sistemas robóticos é extremamente interessante para

o pátio tecnológico brasileiro e mundial, visto que

muitos robôs em atividade possuem arquitetura

fechada, e as atualizações desses controladores são

de alto custo.

No âmbito educacional, a ideia é utilizar o

sistema para dar aulas a distância, possibilitando,

assim, o acesso de mais usuários, como meio de

incentivo à área de robótica.

6. Referências

ABB Flexible Automation. BaseWare OS 3.0,

3HAC 0930-1. User Guide (Guia do usuário do

Robô – IRB2400), 1990a.

ABB Flexible Automation. M97A, 3HAC 0818-1.

Product Manual IRB 2400, 1990b. (Manual do

Produto – IRB2400).

AGUIRRE, L. A. Inciclopédia de Automática.

São Paulo: Edgard Blücher, 2007.

ÁLVARES, A. J.; ROMARIZ, L. J. Telerobotics:

Methodology for the development of a through

the - Internet Robotic Teleoperated System.

Journal of the Brazilian Society of Mechanical

Sciences, v. 24, n. 2, p. 122-126, 2002.

ÁLVARES, A. J. Telemanufatura: Teleoperação via

web da máquina de oxi-corte CNC AUTOCUT

2.5L. In: CONGRESSO BRASILEIRO DE

ENGENHARIA MECÂNICA – COBEM, 16.,

2001. Resumos... [S.l. : s.n.t.], 2001.

CORREIA, Flávio Augusto Coutinho. Um sistema

de tele-operação para um manipulador mestre-

escravo 3 GDL com realimentação háptica. Rio

de Janeiro: Instituto Militar de Engenharia, 2003.

Dissertação (Mestrado) – Instituto Militar de

Engenharia, Rio de Janeiro, 2003.

DEILTEL, P.; DEILTEL H. Java: Como

programar. 8. ed. São Paulo: Pearson, 2010.

DE SOUZA, D. R.; SOUZA, D. J. Desbravando o

PIC. Rio de Janeiro: Érica, 2008.

LITZENBERGER G. Robôs made in Brasil.

Revista Inovação em Pauta, n. 7, p. 57, 2009.

MARTINS, Rodrigo. Projeto de um protótipo de

um Manipulador Teleoperado. São José, 2008.

Trabalho de Conclusão de Curso (Graduação em

Engenharia de Computação) –Universidade do Vale

de Itajaí, São José, SC, 2008.

RITTER, D. J. LabView GUI: Essential

techniques. Rio de Janeiro: MC Graw Hill, 2002.

Artigo selecionado entre os 10 melhores do

VII Encontro Mineiro de Engenharia de

Produção - EMEPRO 2011.

desenvolvimento de uma interface para teleoperação ... · palavras-chave: braço robótico, ......

Documents