desenvolvimento de um software para monitoramento de um

Transcrição

Universidade Federal de Minas Gerais
Curso de Graduação em Engenharia de Controle e Automação
Projeto de Fim de Curso II
DESENVOLVIMENTO DE UM SOFTWARE
PARA MONITORAMENTO DE UM
MANIPULADOR ROBÓTICO VISANDO A
MANUTENÇÃO PREDITIVA
Gustavo Mendes d'Angelis
Orientador: Professor Luciano C. de Araújo Pimenta
Supervisor: Engenheiro Renato Marcio Lemos Oliveira
Dezembro de 2010
Monograa
Desenvolvimento de um Software Para Monitoramento de um
Manipulador Robótico Visando a Manutenção Preditiva
Monograa submetida à banca examinadora para avaliação curricular da disciplina PFCII, para obtenção do grau de Engenheiro
de Controle e Automação.
Belo Horizonte, Dezembro de 2010
i
Resumo
Robôs são caros e normalmente importados, logo, seus defeitos são pontos
críticos e uma das principais fontes de riscos para os projetos que os utilizam.
O objetivo desse trabalho é implementar um sistema de controle de alarmes
e sensoriamento dos manipuladores robóticos da família Smart da Comau,
com o intuito de caracterizar o robô e diagnosticar principais falhas, além
de vericar algumas variáveis que são diretamente relacionadas aos maiores
empecilhos apresentados por estes.
Tal projeto foi desenvolvido junto ao Grupo de Pesquisa e Desenvolvimento de Veículos Autônomos (PDVA) da UFMG, grupo relacionado ao
Laboratório CORO e a Comau do Brasil Indústria e Comércio, empresa do
grupo Fiat que utiliza tais robôs em seus projetos de linhas de montagem de
carroceria e de motores.
Esse projeto identicou quais os sensores instalados no robô são acessíveis
e os que seriam úteis no diagnóstico de algumas falhas, dessa forma, elaborouse um software para coleta e apresentação desses dados. Esse mesmo software
também ilustrava os alarmes mais frequentes e os mais críticos do robô.
Palavras chaves: Manipulador robótico, aplicativo de sensoriamento,
controle de alarmes, detecção de falhas e manutenção preditiva.
Abstract
Robots are expensive and usually imported, so its failures are critical and
a major source of risk for projects that use them.
The aim of this work is to implement a system for Smart robotic family
of COMAU which is responsible for collecting data on some variables that
are directly related to major failures.
This project was developed by the Group for Research and Development
of Autonomous Vehicles (Grupo de Pesquisa e Desenvolvimento de Veículos
Autônomos) - PDVA - UFMG, group related to the CORO Laboratory and
Comau do Brasil Indústria e Comércio, a Fiat Group company that uses such
robots in their projects of assembly lines for car body and engines.
This project identied the sensors on the robot that would be useful in
identifying some failures and developed a software for collecting and presenting these data. This software show the alarms that more happens and the
more dangerous.
Keywords: Robotic Manipulator, application sensing, communication
with sensors, fault detection and predictive maintenance.
Lista de Siglas e Abreviaturas
C4G - Unidade de Controle do Robô
C4GOpen - Extensão do software do controlador C4G
CLP - Controlador Lógico Programável
COMAU - Consorzio Macchine Utensili (Consórcio de Máquinas Ferramentas) - Empresa Grupo Fiat
CORO - Laboratório de Sistemas de Computação e Robótica
FIFO - First In - First Out (Primeiro a entrar, primeiro a sair - Usado
para tratamento de requisições)
GNU LGPL - GNU Lesser General Public License (Licensa pública geral)
MCP - Motion Control Processor (Processador de controle de movimento)
PDL2 - Linguagem de programação do robô
PDVA - Grupo de Pesquisa e Desenvolvimento de Veículos Autônomos
RIA - Robot Institute of America (Instituto robótico americano)
RTAI - Real Time Application Interface (Interface da aplicação em tempo
real)
RTnet - Real Time Networking for Linux - (Rede em tempo real para
Linux)
RPU - Robot Processing Unit (unidade de processamento do robô)
SIX - Menor robô da família Smart de Robôs
SMART - Família de robôs da Comau
SMP - Master Processor Unit (Unidade de processamento mestre)
SMP+ - Master System Processor Plus (Unidade de processamento mestre
mais - Utilizado para C4GOpen)
Unimate - Primeiro robô industrial
WiTP - Interface do operador com a unidade de controle
Sumário
Resumo
i
Abstract
ii
Siglas
iii
Lista de Figuras
vii
Lista de Tabelas
viii
1 Introdução
1.1 Apresentação . . . . . .
1.2 A Empresa . . . . . . .
1.3 Motivação . . . . . . . .
1.4 Objetivos do Projeto . .
1.5 Estrutura da Monograa
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2 Revisão Bibliográca
2.1 Manipuladores Robóticos . . . . . . . . . . . . . . . . . . .
2.1.1 Smart SiX Comau . . . . . . . . . . . . . . . . . . .
2.1.2 Smart NS Comau . . . . . . . . . . . . . . . . . . . .
2.1.3 Smart NJ Comau . . . . . . . . . . . . . . . . . . . .
2.2 Sensores e Detecção de Falhas . . . . . . . . . . . . . . . . .
2.2.1 Referências Relacionadas a Sensores e Detecção de
Falhas . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Trabalhando em Tempo Real . . . . . . . . . . . . . . . . .
2.3.1 Linux com RTAI . . . . . . . . . . . . . . . . . . . .
2.3.2 RTNet . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.3 C4GOpen . . . . . . . . . . . . . . . . . . . . . . . .
2.3.4 Trabalho relacionado ao Linux com RTAI . . . . . . .
2.4 Comunicação com o Robô . . . . . . . . . . . . . . . . . . .
2.5 wxWidgets . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iv
.
.
.
.
.
1
1
1
2
4
5
6
. 6
. 9
. 11
. 12
. 12
.
.
.
.
.
.
.
.
18
19
19
20
21
22
23
25
v
SUMÁRIO
2.6 Panorama Atual . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3 Desenvolvimento e Implementação
3.1 Trabalhos Iniciais . . . . . . . . . .
3.2 O Programa - Izimov . . . . . . . .
3.2.1 Módulo de Alarmes . . . . .
3.2.2 Módulo C4GOpen . . . . .
3.2.3 Módulo PDL2 . . . . . . . .
4 Testes e Análise de Resultados
4.1 Testes Módulo de Alarmes . . . . .
4.1.1 Diagnóstico . . . . . . . . .
4.2 Testes Módulo C4GOpen . . . . . .
4.2.1 Testes Oine do C4GOpen
4.2.2 Testes Online do C4GOpen
4.3 Testes Módulo PDL2 . . . . . . . .
4.3.1 Testes Oine do PDL2 . .
4.3.2 Testes Online do PDL2 . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
27
27
28
30
34
42
.
.
.
.
.
.
.
.
46
46
46
50
50
50
51
51
52
5 Conclusão
60
5.1 PDL2 e C4GOpen . . . . . . . . . . . . . . . . . . . . . . . . 61
5.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . 61
Referências Bibliográcas
62
Lista de Figuras
1.1 Robô Six adquirido pela UFMG. . . . . . . . . . . . . . . . .
2.1 Distribuição de robôs por tipo de indústria nos EUA, Japão e
China.[Campos, 1998] . . . . . . . . . . . . . . . . . . . . . .
2.2 Interface homem-máquina WiTP juntamente com o controlador C4G. [Robotics, 2005] . . . . . . . . . . . . . . . . . .
2.3 Espaço de trabalho do Robô SiX. [Robotics, 2007c] . . . . .
2.4 Ilustração do Robô Six. [Robotics, 2005] . . . . . . . . . . .
2.5 Espaço de trabalho do Robô NS. [Robotics, 2007b] . . . . .
2.6 Robô NS com indicação de seus eixos. [Robotics, 2009b] . .
2.7 Espaço de trabalho do Robô NJ110. [Robotics, 2009c] . . . .
2.8 Robô NJ com indicação de seus eixos. [Robotics, 2009b] . .
2.9 Esquema geral do C4GOpen. [Sintesi, 2008] . . . . . . . . .
2.10 SMP e suas interfaces de comunicação. [Robotics, 2009a] . .
2.11 Estrutura do pacote da camada de aplicação da comunicação
PC-C4G. [Sintesi, 2008] . . . . . . . . . . . . . . . . . . . . .
2.12 Conversos de RS422 para RS232. [Robotics, 2007a] . . . . .
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
.
7
.
.
.
.
.
.
.
.
.
9
10
11
13
14
15
16
22
23
. 23
. 25
Um exemplo de código de movimentação para o robô em PDL2.
Um exemplo da variável POSITION no PDL2. . . . . . . . . .
Diagrama macro do funcionamento do programa. . . . . . . .
Diagrama de entidade relacionamento do banco de dados para
alarmes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Diagrama macro do funcionamento da aba "Alarmes". . . . .
Exemplo de código em MySQL++. . . . . . . . . . . . . . . .
Exemplo da tela de "Alarmes". . . . . . . . . . . . . . . . . .
Exemplo da tela "Corrente dos Eixos"do módulo C4GOpen. .
Exemplo da tela de "Posição e Velocidade dos Eixos"do módulo C4GOpen. . . . . . . . . . . . . . . . . . . . . . . . . . .
Diagrama macro do funcionamento das abas "Corrente dos
Eixos"e "Posição e Velocidade dos Eixos". . . . . . . . . . . .
vi
4
28
29
30
31
32
33
34
35
36
37
vii
LISTA DE FIGURAS
3.11 Diagrama macro do funcionamento do programa C4GOpen
dentro do programa Izimov. . . . . . . . . . . . . . . . . . .
3.12 Diagrama macro do funcionamento do programa C4GOpen
externo ao programa de interface. . . . . . . . . . . . . . . .
3.13 Implementação nal do módulo C4GOpen. . . . . . . . . . .
3.14 Exemplo da tela de "Corrente dos Eixos"do módulo PDL2. .
3.15 Exemplo da tela de "Posição dos Eixos e Velocidade"do módulo PDL2. . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.16 Implementação nal do módulo PDL2. . . . . . . . . . . . .
. 39
. 40
. 41
. 43
. 43
. 45
4.1 Tela de Alarmes após teste para Robô Six. . . . . . . . . . . .
4.2 Tela de Alarmes após teste para Robô NJ. . . . . . . . . . . .
4.3 Resultado do teste da tela "Corrente dos Eixos"do módulo
C4GOpen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4 Resultado do teste da tela de "Posição e Velocidade dos Eixos"do
módulo C4GOpen. . . . . . . . . . . . . . . . . . . . . . . . .
4.5 Tela "Posição dos Eixos e Velocidade"do módulo PDL2 para
velocidade em 80% em MOVE LINEAR para NS. . . . . . . .
velocidade em 80% em MOVEFLY LINEAR para NS. . . . . .
4.7 Tela "Corrente dos Eixos"do módulo PDL2 para velocidade
em 40% em MOVE LINEAR para NS. . . . . . . . . . . . . .
em 40% em MOVEFLY LINEAR para NS. . . . . . . . . . . .
em 50% em MOVE LINEAR para NJ110. . . . . . . . . . . .
velocidade em 50% em MOVE LINEAR para NJ110. . . . . .
47
48
51
52
54
54
55
56
56
57
57
58
58
59
Lista de Tabelas
4.1
4.2
4.3
4.4
Teste Alarmes Robô Six - Nível . . . . . . .
Teste Alarmes Robô Six - Ocorrências . . . .
Teste Alarmes Robô NJ FIAT - Nível . . . .
Teste Alarmes Robô NJ FIAT - Ocorrências
viii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
47
48
49
49
Capítulo 1
Introdução
1.1 Apresentação
Este capítulo apresenta o problema que motivou o projeto de um software
para monitoramento e controle de alarmes para um manipulador robótico.
Além disso, é explicitada a empresa, o grupo de pesquisas e o laboratório em
que o trabalho foi desenvolvido. Para nalizar apresenta-se a estrutura da
monograa.
1.2 A Empresa
O projeto do software para monitoramento e controle de alarmes, descrito
neste trabalho, foi desenvolvido junto ao Grupo de Pesquisa e Desenvolvimento de Veículos Autônomos (PDVA) da UFMG e à Comau do Brasil Indústria e Comércio.
O Grupo PDVA atua, principalmente, nos desenvolvimentos de um veículo
automóvel autônomo e de sistemas de instrumentação e controle embarcados
para veículos aéreos tripulados ou autônomos. Além disso, tal grupo tem
o CORO - Laboratório de Sistemas de Computação e Robótica do Departamento de Engenharia Elétrica da Universidade Federal de Minas Gerais,
como um dos laboratórios vinculados. Esse possui atuação em diversas áreas
da robótica, como: manipuladores robóticos (o CORO é a base da disciplina "Manipuladores Robóticos"ministrada pelo professor Guilherme Augusto Silva Pereira - Diretor do laboratório), robótica móvel, visão computacional, sistemas integrados de hardware e software, processamento de
imagem, sistemas a eventos discretos, instrumentação e controle computacional. [CORO, 2010].
A Comau é uma empresa do Grupo Fiat, que foi fundada na Itália em
1
1.3
Motivação
2
1973 com o nome COnsorzio MAcchine Utensili (Consórcio de Máquinas
Ferramentas). Após vários anos de expansão, em 1995, a Comau do Brasil
Ind. E Com. Ltda e a Comau Argentina S.A. são estabelecidas, marcando
presença da Comau no Mercosul. Em 1998, surge a Comau Service com a
missão de fornecer serviços de manutenção.[COMAU, 2010].
Posteriormente, a empresa expandiu suas atividades que agora se caracterizam em:
• Engenharia;
• Carroceria;
• Powertrain Systems;
• Montagem Final;
• Robótica;
• Service;
• Manufacturing.
Essa última área foi estabelecida no ano de 2010. Essa diretoria foi criada, emancipando a Central de Serviços, braço membro da Comau Service
responsável pela construção de estruturas e equipamentos industriais.
Os Robôs Comau são implantados em diversos ramos industriais, como:
siderúrgicas, renarias, mineradoras e indústria automobilística. Tais equipamentos, além de serem fornecidos pela Robótica da empresa, são utilizados
em projetos da Carroceria e Powertrain Systems. O trabalho será realizado
na área de carroceria. Tal setor está localizado na Rodovia Fernão Dias km
429 - BR 381, Distrito Industrial Paulo Camilo Pena, Betim / MG - CEP:
32.530-970, portaria 03 / galpão: 57 - parte externa.
1.3 Motivação
A Comau, empresa do grupo Fiat, fornece, dentre outros produtos, robôs
manipuladores para as mais diversas necessidades de seus clientes. Embora
exista uma linha de estudos para viabilizar a nacionalização desses equipamentos, a realidade vigente é a produção na Itália, o que acarreta os mais
diversos empecilhos.
O primeiro empecilho que se pode pontuar é o alto custo dos robôs. Os
mesmos oneram todos os projetos em que são utilizados, dicultando a venda
1.3
Motivação
3
dos produtos da empresa. Posteriormente, todo o conhecimento envolvendo
esses equipamentos se concentra nos laboratórios italianos, o que diculta
signicativamente a resolução de qualquer novo defeito apresentado.
A grande maioria dos problemas identicados gera a necessidade de a
Comau do Brasil, ou enviar para a Comau Itália o equipamento defeituoso
ou solicitar serviços de engenheiros italianos para reparo. Tais ações geram
perdas nanceiras, além de atrasos nos projetos.
Para evitar a necessidade de tantos reparos, o ideal seria realizar a
manutenção preditiva dos manipuladores. Para realizar a manutenção (especialidade da Comau Service) precisa-se inicialmente coletar os dados do
robô. A linha Smart de robôs Comau já possui alguns sensores, entretanto,
esses sensores não são utilizados, isto é, problemas que poderiam ser diagnosticados no seu princípio são negligenciados.
Portanto, a Comau do Brasil necessita que os robôs fornecidos para seus
clientes tenham seus sensores identicados, e, assim, seja criado um sistema
para medir algumas variáveis que estão diretamente relacionadas às maiores
fontes de defeitos. As variáveis escolhidas foram: corrente dos motores,
posição e velocidade dos eixos.
A corrente dos motores pode ajudar a detecção de falhas mecânicas e
elétricas, além de indicar choque dos braços do manipulador (essa abordagem
de choques não será implementada, já que o robô já a contém). Frequentemente, no chão de fábrica, um ambiente insalubre, com poeira, empilhadeiras
em trânsito, resto de soldas, detritos transportados pelo ar podem entrar nos
motores gerando falhas mecânicas, o que conseguir-se-ia perceber vericando
as correntes dos motores. Falhas elétricas devido à grande velocidade com
que se manifestam, dicilmente poderão ser identicadas com antecedência,
mas as medições das correntes podem indicar o momento da falha ou auxiliar
no diagnóstico do motivo desta.
Alguns trabalhos em manutenção utilizam a posição e velocidade para
determinar se um sistema está se degradando. Tal abordagem também será
realizada, por isso, medir-se-a tais variáveis. Outro motivo para se utilizar
tal análise é a frequente necessidade de se consultar a posição do robô em
diversos pontos, principalmente quando se lida com robôs de solda. O projeto
visa além de gerar uma interface para a rápida visualização dos dados, coletar
tais dados e salvá-los em um arquivo.
Além disso, todos os alarmes gerados pelo robô são catalogados num
arquivo. É importante tratar esse arquivo, organizando os alarmes de forma a
vericar os mais comuns, assim como quais alarmes são mais críticos, ou seja,
transformar dados em informações. Dessa forma, juntamente com o histórico
de posição, velocidade e corrente dos motores, será possível diagnosticar o
robô, além de ser possível apurar qual o motivo de uma grande falha ter
1.4
4
Objetivos
ocorrido.
Vale ressaltar que esse sistema visa à manutenção preditiva, mas devido
ao grande escopo do projeto para um Projeto Final de Curso, assim como, o
know-how da Comau em manutenção, o estudo dos dados coletatos não será
realizado, estes serão disponibilizados para que possam ser usados posteriormente.
Em paralelo às necessidades da Comau, recentemente a Universidade Federal de Minas Gerais, adquiriu um robô SIX Comau. Um manipulador de
pequeno porte, com seis graus de liberdade e capacidade de carga de 6 quilogramas. Tal robô pode ser visualizado na Figura 1.1. Portanto, esse projeto
terá utilidade também para o laboratório, CORO, que o adquiriu e parte de
seu desenvolvimento ocorrerá no mesmo.
Figura 1.1: Robô Six adquirido pela UFMG.
1.4 Objetivos do Projeto
Ao nal do projeto, tem-se o objetivo de possibilitar que a Manutenção Comau consiga diagnosticar cada robô que se queira unindo as informações
1.5
Estrutura da Monograa
5
provenientes dos alarmes juntamente com os sensores. Essas informações
serão repassadas aos técnicos de manutenção da Comau que poderão tomar
as atitudes cabíveis evitando futuras falhas de maior gravidade.
Deseja-se buscar novos conhecimentos quanto aos programas do robô, já
que utiliza-se módulos do robô Comau ainda não explorados no Brasil. Além
disso, tem-se o objetivo de incentivar a Comau do Brasil a trabalhar com
módulos do robô que ainda não são usufruídos.
Como objetivo acadêmico, visa-se aprimorar técnicas de programação e o
conhecimento em manipuladores robóticos, especicamente os da linha Smart
da Comau, além de concluir o curso de Engenharia de Controle e Automação.
1.5 Estrutura da Monograa
Esta monograa é estruturada em 3 capítulos além da introdução, conclusões
e referências. De forma sucinta são eles:
CAPÍTULO 2 - REVISÃO BIBLIOGRÁFICA: Neste capítulo é apresentado todo o material selecionado que aborda a elaboração de aplicações que
se conectam a sensores e os caracterizar. Aborda referências relacionadas a
manipuladores robóticos e seus defeitos. Ilustra a programação em tempo
real e os requisitos para o mesmo, além da biblioteca utilizada para a programação visual.
CAPÍTULO 3 - DESENVOLVIMENTO E IMPLEMENTAÇÃO: Este
capítulo aborda os trabalhos iniciais com o robô, como foi realizada a implementação do software, a forma de coleta dos dados medidos. Ademais,
apresenta-se diculdades encontradas e como foram resolvidas.
CAPÍTULO 4 - TESTES E ANÁLISE DE RESULTADOS: Capítulo destinado a mostrar testes realizados no robô Six da UFMG, nos Robôs NS e
NJ110 da Comau, coletando dados de seus sensores. Essa seção mostra também o tratamento dos dados dos alarmes dos manipuladores Six e NJ110. A
seção de testes é crucial para ilustrar o funcionamento do projeto.
Capítulo 2
Revisão Bibliográca
Este capítulo apresenta as referências utilizadas como base para o desenvolvimento desse trabalho. Inicialmente explicita-se sobre manipuladores robóticos, abordando com mais ênfase, os robôs utilizados: Smart Six, Smart NS e
Smart NJ110. Posteriormente fala-se sobre os sensores desta linha de robôs
e a detecção de falhas. Ilustra-se as ferramentas necessárias para se trabalhar em tempo real. Para nalizar aborda-se a comunicação com o robô e a
biblioteca wxWidgets.
2.1
Manipuladores Robóticos
O termo robô é comumente utilizado para caracterizar um grupo composto
basicamente por manipuladores robóticos e robôs móveis. Este termo segundo [Michelini, 2001], utilizado pela primeira vez por Karel Capek em um
drama, datado de 1921 e intitulado R.U.R. (Rossum's Universal Robots ),
advém de uma palavra de origem tcheca, cujo signicado é "trabalhador
forçado".
Já a denição do RIA - Robot Institute of America (Instituto robótico
americano), reproduzido em [Fu, 1987], arma que um robô é um manipulador re-programável multifuncional projetado para mover materiais, peças,
ferramentas ou dispositivos especializados, através de movimentos programados para o desempenho de uma variedade de tarefas. Além disso, são
máquinas equipadas com sistemas de visão e/ou outras modalidades de dispositivos sensores.
Para [Galhano, 1992] um manipulador robótico é um dispositivo composto por articulações lineares e/ou rotacionais acionadas por atuadores
elétricos, pneumáticos ou hidráulicos. O manipulador tenta simular um braço
humano no que diz respeito à capacidade de transporte e manipulação de car6
2.1
7
gas críticas.
Com base nestas denições, percebe-se que a idéia fundamental de um
robô é substituir trabalhos manuais. A mão de obra humana é passiva de
erros e imperfeições, além de necessitar de maiores cuidados quanto à segurança e repetitividade. Então, a versatilidade, conabilidade, precisão e
velocidade dos robôs solucionam a maioria dos empecilhos provenientes da
utilização de mão de obra convencional. A versatilidade dos manipuladores
pode ser percebida pela Figura 2.1 que ilustra a distribuição de robôs por
tipo de indústria nos EUA, Japão e Europa.
Figura 2.1: Distribuição de robôs por tipo de indústria nos EUA, Japão e
China.[Campos, 1998]
Os primeiro trabalhos em robótica, segundo [Pires, 2002] , surgiram entre
1940 e 1950 e tratam de equipamentos mestre-escravo que manipulavam produtos radioativos. O pioneiro a adentrar a indústria foi o "Unimate" (195962) que era programável, exível e contava com ferramentas próprias. Este
robô ilustrou o poder da robótica e fez surgir a idéia de utilização de sensores
em retro-alimentação para melhora de desempenho. A partir deste ponto,
a robótica industrial avançou profundamente, com diversos fabricantes, produtos e aplicações.
Além dos benefícios anteriormente mencionados, a conquista de mercado
pela robótica pode ser atribuída a [Campos, 1998]:
• O elevado custo de mão de obra em países desenvolvidos;
• A demanda de produtos com dimensões tão reduzidas que torna inviável
ser realizada por seres humanos, tais como discos rígidos, placas de
circuitos impressos, camcorders, dentre outros e
2.1
8
• A redução de custo de produção entre 5% e 8%.
Todavia, vale ressaltar [Pires, 2000] que embora tenham certa sosticação,
os robôs atuais são basicamente controladores de posição e movimento,com
mecanismos de comunicação e conectados a um CLP(controlador lógico programável) realizando essas funções com elevada precisão. Sendo assim, muito
ainda pode-se agregar ao desenvolvimento da robótica.
A empresa Comau seguiu a tendência do mercado e expandiu suas atividades para o fornecimento de robôs. Estes são implantados em vários ramos
industriais, atuando em várias frentes, como:
• Serviço de prensas de estamparia;
• Transferência de peças;
• Manipulação de cargas pesadas;
• Pintura;
• Posicionamento de peças para solda;
• Solda a arco;
• Solda a ponto;
• Solda laser;
• Acabamento de peças.
A linha de fornecimento de robôs da Comau, denominada Smart, é composta por robôs de diversos tamanhos e especializações. Tal linha possui um
controlador C4G que pode controlar robôs congurados com até 10 eixos.
Incorpora a RPU - Robot Processing Unit (unidade de processamento do
robô), principal unidade, composta basicamente por:
• RPS - Rack Power Suply (fonte de energia do rack): Fornece as tensões
requeridas pelas demais placas do Rack;
• SMP - Master Processor Unit (Unidade de processamento mestre):
Unidade principal, onde estão o sistema operacional e os programas
de aplicação. Este é provido de interfaces de comunicações como serial
RS232/RS422 e Ethernet (melhor detalhado na seção 2.4) e
• MCP - Motion Control Processor (Processador de controle de movi-
mento): CPU que gerencia os movimentos.
2.1.1
Smart SiX Comau
9
O WiTP é responsável pela interface homem-máquina, gravando posições,
controlando , exibindo e editando programas em PLD2 (linguagem de programação do robô). Tal interface, juntamente com o C4G podem ser vistas
na Figura 2.2
Figura 2.2: Interface homem-máquina WiTP juntamente com o controlador
C4G. [Robotics, 2005]
A linha Smart também inclui sensores, estes serão abordados na Seção
2.2. Os robôs utilizados serão melhores descritos nas próximas sub-seções.
2.1.1 Smart SiX Comau
A grande maioria dos robôs possuem seis eixos e, desta forma, estão aptos a
alcançar qualquer posição/orientação no seu espaço de trabalho [Pires, 2002].
Os robôs Smart SiX, projetados para atender aplicações como ligeiros manuseio e soldagem, não são diferentes. As características principais do robô
estão listadas abaixo [Robotics, 2007c]:
• Pré-projetados para uso com uma variedade de dispositivos opcionais;
• Lubricação com óleo de todas as reduções, com exceção dos eixos 5 e
6, que são lubricados com graxa;
• Possibilidade de conexão de ferramentas elétricas e pneumáticas para
o antebraço;
• Dimensões reduzidas que permitem alta capacidade de orientação em
espaços pequenos, seu espaço de trabalho é ilustrado na Figura 2.3.
2.1.1
Smart SiX Comau
Figura 2.3: Espaço de trabalho do Robô SiX. [Robotics, 2007c]
10
2.1.2
Smart NS Comau
11
A manipulação dos eixos é controlada por motores síncronos sem escovas
e com transmissão direta de movimento para os eixos 1-2-3-4 por meio de
unidades de redução mecânica. Já os eixo 5-6 a transmissão utiliza correias
para uma unidade de redução. A ilustração do SiX, juntamente com as
posições de suas juntas, pode ser visualizada na Figura 2.4.
Figura 2.4: Ilustração do Robô Six. [Robotics, 2005]
2.1.2 Smart NS Comau
O robô Smart NS é voltado para manipulação de cargas leves e soldagem.
Este possui seis graus de liberdade. A manipulação dos eixos é controlada
por motores síncronos sem-escovas, enquanto a transmissão para todos os
eixos é por meio de unidades de redução mecânica. Utilizou-se o SMART NS
16-1.65 Hand-SMART, este possui carga útil de 16 kg e alcance de 1850mm.
As principais características deste são [Robotics, 2007b]:
• Disponível para uso com dispositivos opcionais;
• Lubricação com óleo de todas as reduções, com exceção dos eixos 5 e
6, que são lubricados com graxa;
2.1.3
Smart NJ Comau
12
• Possibilidade de conexão de ferramentas elétricas e pneumáticas para
o antebraço;
• Dimensões reduzidas que permitem alta capacidade de orientação em
espaços pequenos, seu espaço de trabalho é ilustrado na Figura 2.5;
• Capacidade de execução de tarefas com alta repetibilidade.
Algumas características desse tipo de manipulador são idênticas às do
robô Six, entretanto, vale frisar que o NS é um pouco maior que o Six, dessa
forma, é encontrado na indústria com mais frequencia.
A ilustração do NS, juntamente com a indicação de seus eixos, pode ser
visualizada na Figura 2.6.
2.1.3 Smart NJ Comau
O robô Smart NJ é amplamente utilizado na indústria. O robô Smart NJ110
- 3.0 é um tipo especíco dos manipuladores NJ, que possui carga útil de
110kg e alcance de 2980mm. Existe uma variedade de robôs NJ, estes são
diferenciados pela carga, área de trabalho e alcance.
O manipulador NJ é utilizado principalmente para [Robotics, 2009c]:
• Manipulação,
• Soldagem, principalmente a soldagem a ponto;
• Remoção de cavaco de usinagem fazendo limpeza, polimento, dentre
outros.
O espaço de trabalho do robô NJ110 pode ser visualizada na Figura 2.7,
enqaunto sua ilustração, juntamente com a indicação de seus eixos, pode ser
vista na Figura 2.8.
2.2 Sensores e Detecção de Falhas
Segundo [Bastos Filho, 2007] sensores são dispositivos utilizados para quanticar ou detectar parâmetros especícos provenientes a do meio externo, por
meio de transdutores. Em suma, transdutores transformam grandezas físicas
em outras, da forma que as últimas são mais facilmente manipuláveis.
Ainda pautado [Bastos Filho, 2007], pode-se armar que os sensores são
de contato (interruptores, sensores m de curso, placas de orifício, tubos
de venturi) ou de não-contato (utilizando campos elétricos, magnéticos, luz,
2.2
Sensores e Detecção de Falhas
Figura 2.5: Espaço de trabalho do Robô NS. [Robotics, 2007b]
13
2.2
14
Figura 2.6: Robô NS com indicação de seus eixos. [Robotics, 2009b]
dentre outros). Além disso, os sensores, mais especicamente os inseridos em
robótica, têm-se uma divisão em internos e externos.
Os sensores internos são dispositivos utilizados, na maioria dos casos,
para medir posição, velocidade, aceleração das juntas e/ou das extremidades
de manipuladores, além de indicarem posição para robôs móveis. Alguns
outros visam à segurança, como sensores de temperatura e pressão de uidos.
Exemplos são encoders, tacômetros, acelerômetros, potenciômetros, dentre
outros. No trabalho desenvolvido foram utilizados sensores internos, tal como
os encoders.
Existem também os sensores externos, estes são utilizados para monitorar
e relacionar-se com o ambiente, além de auto-proteger o robô. Podem ser
visuais ou não-visuais. Alguns exemplos são sensores ultra-som, eletromagnéticos e de proximidade.
Há a possibilidade de existir um robô sem qualquer sensor. Entretanto,
2.2
Figura 2.7: Espaço de trabalho do Robô NJ110. [Robotics, 2009c]
15
2.2
Figura 2.8: Robô NJ com indicação de seus eixos. [Robotics, 2009b]
16
2.2
17
conforme explicitado na Seção 2.1 a inclusão de sensores é um passo crucial para melhorar o funcionamento do manipulador. O robô Smart vem
de fábrica com sensores habilitados para a medição de correntes, posição e
velocidade dos motores, posição e velocidade dos eixos.
A primeira etapa para desenvolver um sistema de monitoramento é
classicá-lo, obtendo assim sua visibilidade. Esta permite especicar como
o sistema conseguirá atender aos critérios necessários para uma dedigna
medição dos sensores, ou seja, como os estes devem ser tratados. Segundo
[Chou, 2005] muitas vezes sistemas de sensoriamento, como o proposto neste
projeto, não funcionam da forma desejada quando trabalham como parte
de um sistema maior. Portanto, uma análise criteriosa sobre os sensores é
ainda mais crucial, principalmente quando se vislumbra a escalabilidade do
sistema.
Em [Chou, 2005] os sistemas wireless de monitoramento são classicados.
Tal classicação será utilizada para o software desenvolvido, apesar do mesmo
não utilizar redes sem o. Para [Chou, 2005] existem três categorias:
• Detecção de eventos x Aquisição de dados x Agregação dos dados;
• Sensoriamento passivo x Sensoriamento ativo e
• Registro de dados em tempo real x Acompanhamento.
Exemplos de detectores de eventos incluem sensores de fumaça, movimento, luz, cuja nalidade é determinar a presença destes ou valores acima
do esperado dos mesmos. Por outro lado, sensores de aquisição de dados
devem apresentar a magnitude do evento sendo monitorado, por exemplo,
um sismógrafo e um termômetro. Sistemas híbridos também são possíveis,
como um sismógrafo pode ser normalmente inativo até vibrações acima de
um limiar que irá acordá-lo para a aquisição. Por último, dispositivos com
agregação de dados primeiramente coletam dados de dispositivos de detecção,
os armazenam na memória local, e executam os algoritmos de agregação. O
software proposto neste trabalho é híbrido, pois adquire os dados dos sensores, alertando caso os mesmos ultrapassem um valor limiar, além de ser
possível armazenar tais dados para visualização futura, ou até mesmo em
outro software.
Embora [Chou, 2005] considere sensoriamento ativo aquele em que o sistema emite um sinal dirigido e verica a resposta ao mesmo. Um exemplo
seria um sonar, que emite um impulso de som e mede a reexão para determinar a distância. A classicação em ativo e passivo será feita segundo
[Manik, 2007], que arma que sensores passivos são aqueles que a própria
energia do sistema medido supri as necessidades energéticas dos trasdutores.
2.2.1
Referências Relacionadas a Sensores e Detecção de Falhas
18
Enquanto sensores ativos necessitam de uma fonte externa. Desta forma,
todos os sensores utilizados neste projeto são ativos, já que precisam de
alimentação de tensão. Esses sensores são conectados a plataforma C4G,
cabendo apenas coletar esses dados e tratá-los de forma a transformá-los em
informação.
Registro em tempo real é o sensoriamento com urgência, devido à demanda do processo. Acompanhamento são processos com maior exibilidade
de tempo de resposta. O sistema proposto possui funcionalidade para ambos, entretanto, o mesmo não necessita ser de tempo real, já que seus dados
serão utilizados para ns estatísticos e análise posterior por um técnico em
manutenção. Na Seção 2.3 expõe-se a biblioteca, o software e o tipo de
comunicação necessária para realizar a coleta de dados em tempo real.
A Subseção 2.2.1 aponta exemplos similares ao desenvolvido no que referese a sensores e detecção de falhas.
2.2.1 Referências Relacionadas a Sensores e Detecção
de Falhas
O sistema de acionamento mais comum em robôs são os motores síncronos
de imãs permanentes sem escovas, o que não difere para os robôs da linha
Smart. Sendo assim, após algumas análises, [Ferretti, 2002] armou que a
perturbação que motores sem escovas inserem no sistema, associado a imperfeições deste se a comutação de fase for não ideal, pode danicar a estrutura
mecânica do manipulador.
Os autores em [Ferretti, 2002] elaboraram um modelo para o robô com
base na medição dos sensores de corrente. Entretanto, vale ressaltar que
qualquer método para corrigir o funcionamento dos motores necessita num
primeiro momento medir as correntes destes. Dessa forma o software elaborado para sensoriar o robô mede os sensores de corrente das juntas, trata
e fornece tais dados para o usuário. Este, então, pode utilizar a informação
adquirida para ajustar os motores dos robôs da forma que lhe convir.
Em [Ferretti, 2002] utiliza-se um robô COMAU SMART 3-S, manipulador
industrial antropomórco com 6 graus de liberdade , com pulso não esférico e
capacidade de 6kg de carga. O mesmo possui a versão aberta do controlador
C3G-9000. Tal robô é bastante similar ao robô SiX, entretanto este possui a
versão aberta C4G.
Em [Caccavale et al., 2009] arma-se que é crucial desenvolver um sistema de detecção de falhas para manipuladores robóticos. Este deve ser
capaz de detectar rapidamente o surgimento de falhas, reconhecer o local de
ocorrência e estimar a evolução do tempo das falhas encontradas. Ademais,
2.3.0
Coleta em Tempo Real
19
ele acrescenta a existência de métodos para detecção de falhas utilizando lógica fuzzy, técnicas de estimação de parâmetros, redes neurais, dentre outros.
Todos os métodos utilizam a medição da posição, velocidade e aceleração
dos eixos para elaboração de algoritmos de detecção de falhas.
O usuário do software de monitoramento proposto pode desejar vericar
o comportamento dos motores em caso de impactos, sendo assim, expõe-se
novamente que medir as correntes dos motores é, não só viável, como bastante
útil.
O que se percebeu foram alguns trabalhos que ou utilizaram sensores
externos ao robô, ou utilizaram apenas os sensores de corrente e posição. Em
[Macchelli, 2002] fez-se medições em tempo real, para a retro-alimentação de
um controlador a ser implementado. Além disso, coletam-se sinais de uma
câmera instalada no robô COMAU SMART 3-S com C3G-9000 sem ser em
tempo real, visando realizar deslocamentos orientados.
Outro ponto notado é que como os robôs utilizados em pesquisas não
cam em funcionamento durante muitas horas seguidas e não se encontram
em ambientes com componentes danosos a sua estrutura, pouco se pesquisa
sobre a manutenção dos mesmos, cando isso, na maioria da vezes, a cargo
das empresas. Pesquisas relacionadas à manutenção são normalmente relacionadas aos motores síncronos em si, pouco se encontra sobre a manutenção
destes como componentes de manipuladores industriais.
A utilização quase que exclusiva de manipuladores robóticos industriais é
para pesquisas relacionadas a controle de posição, já que os mesmos possuem
grande precisão nesse âmbito, é claramente visível.
2.3 Trabalhando em Tempo Real
Conforme explicitado na Seção 2.2, o sistema possui um módulo em tempo
real para coleta da posição das juntas e corrente dos motores. Entretanto,
para um sistema ser qualicado como tal, necessita-se a instalação de alguns
componentes, bibliotecas e softwares que serão descritos nesta seção.
2.3.1 Linux com RTAI
O Linux [Sintesi, 2008] é um sistema operacional com compartilhamento de
tempo de bom desempenho, mas desprovido de um suporte em tempo real.
Portanto, para se atingir um comportamento correto de tempo, é necessário
fazer algumas alterações nas fontes do kernel, ou seja, na manipulação de
interrupção e políticas de escalonamento.
2.3.2
RTNet
20
O
RTAI
(Real
Time
Application
Interface)
[Real Time Application Interface Ocial Website, 2010] é uma extensão para a plataforma Linux, que permite o sistema operacional atuar
em aplicações de tempo real em que o tempo de ciclo de amostragem
é menor do que o suportado pelo Linux convencional. Entretanto,
[Sintesi, 2008] fazendo-se uma análise de forma rigorosa, RTAI não é
um sistema operacional de tempo real, como VxWorks e QNX. Segundo
[Real Time Application Interface Ocial Website, 2010] RTAI é composto
basicamente por:
• Um patch para o kernel do Linux, que introduz uma camada de ab-
stração do hardware;
• Variedade de serviços que tornam a programação concorrente, utilizada
para aplicações em tempo real, mais facilitada.
Essa extensão provê serviços de tempo real, tais como: escalonador de
tempo real, listas FIFOs (First In First Out ), memória compartilhada e outros usando a arquitetura modular presente no Linux convencional. A atividade de escalonamento deixa de ser do kernel e passa a ser responsabilidade
do RTAI. Assim, ele trata o sistema operacional Linux como uma tarefa de
baixa prioridade, enquanto as tarefas de tempo real são colocadas como de
alta prioridade. Logo, o sistema operacional só entra em execução quando
não existem mais tarefas de tempo real para executar. As tarefas de tempo
real são inseridas como módulos no kernel.
Portanto, o RTAI torna o Linux capaz de dar suporte a tarefas de tempo
real críticas, nas quais é extremamente importante que os seus deadlines
sejam respeitados. O RTAI provê desempenho preemptivo e determinístico,
ademais ainda permite o uso de funções, aplicações e drivers do Linux padrão,
como: suporte aos protocolos TCP/IP, ambiente gráco, sistema de janelas,
sistema de arquivos, etc.
Desta forma, como será necessário lidar com interfaces, sistemas de arquivos, protocolos de comunicação, utilizou-se a distribuição Ubuntu Versão
9.04 com RTAI para a realização das atividades propostas em tempo real.
2.3.2 RTNet
RTnet é um protocolo de rede em tempo real para RTAI [Sintesi, 2008], cujo
código é aberto e utiliza Ethernet, suportanto até mesmo Gigabit Ethernet.
Para evitar colisões e congestionamentos imprevisíveis sobre Ethernet, uma
camada de protocolo adicional chamado RTmac controla o acesso à mídia.
2.3.3
C4GOpen
21
Este protocolo implementa UDP/IP, TCP/IP (características básicas),
ICMP e ARP em uma maneira determinística [RTNet, 2010]. Uma das características mais interessantes do RTnet é a sua independência de hardware
especíco para suportar comunicações de tempo real, isto é, pode-se utilizar
placas de rede comuns, desde que tenham suportes para RTnet hard real-time.
RTnet [RTNet, 2010] foi originalmente desenvolvido por Ulrich Marx em
seu trabalho de graduação no Instituto de Engenharia de Sistemas, Grupo de
Sistemas de Tempo Real, da Universidade de Hannover (Alemanha). Agora
ele está sendo mantido e melhorado por colaboradores em todo o mundo.
2.3.3 C4GOpen
Alguns robôs da Comau podem ser adquiridos com o módulo C4GOpen habilitado [Sintesi, 2008]. Este módulo, que na verdade é um extensão do software
do controlador C4G, permite que o usuário consiga manipular o robô, realizar
medições, utilizar sensores externos, tudo com um dispositivo externo, como
um PC, e em tempo real. O C4Gopen é composto basicamente por:
• SMP + (Master System Processor Plus), que contém C4G software do
sistema, intérprete PDL2 e gerador de trajetória;
• DSA (Digital Servo Amplier), que contém o código de controle para
a posição, velocidade e circuitos de corrente;
• PC, que é o dispositivo externo interagindo com C4G;
• switch Fast Ethernet.
Na Figura 2.9, pode-se vericar o esquemático de funcionamento do
C4GOpen.
A biblioteca C4GOpen é de código aberto, distribuído sob os termos da
GNU LGPL (GNU Lesser General Public License ), é escrita em C++. O seu
objetivo é a interface de GNU/Linux/RTAI/RTnet/PC com "C4G Open", a
m de utilizar todos os modos de operação fornecidos pelo controlador C4G
Comau.
Dentro da biblioteca existe a classe do tipo C4GOpen. Essa classe possui
basicamente os seguintes métodos [Sintesi, 2008]:
• Métodos para inicializar uma instância C4gOpen, isto é:
Abertura e ligação com o soquete RTnet;
Criação de tarefa de tempo real RTAI ;
2.3.4
Linux com RTAI
22
Figura 2.9: Esquema geral do C4GOpen. [Sintesi, 2008]
Espera da chegada do pacote de inicialização de C4G.
• Métodos para enviar/receber um pacote de/para C4G;
• Métodos Get para leitura de valores em pacotes provenientes C4G;
• Métodos Set para gravar valores em pacotes que vão para C4G;
• Métodos para vericar a regularidade das operações;
• Métodos para nalizar um exemplo C4gOpen, isto é:
Destrói tarefa de tempo real RTAI ;
Fecha o socket RTnet.
Será abordado mais detalhes sobre o C4GOpen na implementação do
software.
2.3.4 Trabalho relacionado ao Linux com RTAI
Em experimentos utilizando robôs similares, como [Macchelli, 2002], utilizouse uma rede serial para comunicar o manipulador a um computador operando
com RTAI-Linux. O computador implementa os algoritmos de controle em
2.4.0
Comunicação com o Robô
23
tempo real. Para conexão do sistema de coleta de dados visuais, foi utilizada
interface Ethernet como o protocolo TCP/IP. Um simples cliente/servidor
foi desenvolvido: a aplicação cliente é executada no sistema RTAI-Linux e o
servidor trabalha no Linux para PC, este gerencia as tarefas de visão e envia
os dados requisitados por aquele.
2.4 Comunicação com o Robô
A comunicação com o manipulador para a coleta dos dados apresentados
pelos sensores é um ponto chave para a elaboração do sistema proposto. Uma
das primeiras decisões a ser tomada é quanto à interface de comunicação.
Como explicitado na Seção 2.1.1 temos o SMP que possui portas seriais
RS232/RS422, USB e Ethernet, conforme a Figura 2.10.
Figura 2.10: SMP e suas interfaces de comunicação. [Robotics, 2009a]
Para o C4GOpen [Sintesi, 2008], a comunicação com o PC deve ser realizada utilizando protocolo UDP/IP através da rede Ethernet. O computador
age como um servidor, enquanto o robô tem o papel de cliente. Como trata-se
de uma aplicação em tempo real o sistema determina uma velocidade de comunicação de 1 ou 2 milissegundos. A camada de aplicação da comunicação
C4G-PC é baseada na troca de um pacote cuja estrutura está representada
na Figura 2.11.
Figura 2.11: Estrutura do pacote da camada de aplicação da comunicação
PC-C4G. [Sintesi, 2008]
2.4.0
Comunicação com o Robô
24
Existem diversos modos de operação efetivamente suportados pela extensão C4GOpen 2.11. Os modos são programas confeccionados em PDL2
que rodam no robô estipulando a conguração do manipulador. No que diz
respeito à biblioteca C4GOpen alguns dos modos de operação são:
• Modo 0: Determina o comportamento normal do controlador C4G com
o requisito adicional de um comunicação em tempo real rígido com o
PC, utilizado caso se queira somente leitura;
• Modo 1: Estipula comportamento mais completo e aberto, o PC pode
fornecer aos eixos habilitados todos os parâmetros, além de realizar
leitura;
• Modo 501: Modo para o transitório de um "Drive ON" ;
• Modo 504: Modo que permite o fechamento da comunicação;
• Modo 505: Possibilita que o PC agende um "Drive OFF" ;
• Modo 506: Útil para reiniciar o processo de comunicação no cliente
SMP+ sem reiniciar o C4G.
A comunicação com o módulo que utiliza PDL2 para coletar os dados
foi implementada de duas formas, utilizando o protocolo FTP via Ethernet
e utilizando a porta serial RS422. Como essa última implementação é mais
eciente, maiores detalhes na Seção 3.2.3, a mesma foi priorizada.
A unidade de controle C4G tem uma porta serial RS422 normalmente
instalada no SMP+, com conector X7/SMP. Entretanto, para fazer a conexão
com o computador utilizou-se um conversor para RS232 com a estrutura
ilustrada pela Figura 2.12.
Em experimentos utilizando robôs similares da Comau, como
[Macchelli, 2002], foi utilizada porta serial para funções envolvendo o controle do manipulador e Ethernet para aplicações de coleta e envio de dados,
neste caso, sinais de uma câmera de vídeo. Ao mesmo tempo [de Lima, 2008]
utiliza serial 232 para detecção de sinais de vibração.
Sendo assim, pensou-se em utilizar Ethernet tanto para as medições utilizando C4GOpen, quanto para as usufruindo da linguagem PDL2. Entretanto, conforme será explicitado, a utilização da serial para o módulo que
utiliza PDL2 foi mais eciente.
2.5.0
wxWidgets
25
Figura 2.12: Conversos de RS422 para RS232. [Robotics, 2007a]
2.5 wxWidgets
A biblioteca em C++ wxWidgets (anteriormente denominada wxWindows)
contém os componentes básicos para a elaboração de interfaces grácas. A
mesma é uma versão estável, além de ser versátil, pois permite criar aplicativos para Windows, Mac OS X, Linux e UNIX em arquiteturas 32 bits
e 64-bit, assim como diversas plataformas móveis como Windows Mobile,
iPhone SDK e GTK+ [wxWidgets Cross-Platform GUI Library, 2010]. Esta
foi escolhida, principalmente, pela versatilidade, já que como o programa
deve funcionar no Linux (módulo tempo real) e no Windows (módulo sem
tempo real), faz-se necessário uma biblioteca desse tipo. Além disso, trata-se
de uma biblioteca leve, que não necessita grandes processamentos.
2.6 Panorama Atual
Atualmente a robótica adentra cada vez mais o mercado, como ilustrado na
Seção 2.1. Várias pesquisas com manipuladores e principalmente robótica
móvel aparecem todos os anos, com um crescimento exponencial. Entretanto, o que se percebe quanto aos trabalhos acadêmicos é a utilização de
manipuladores usando sensores externos ou em experimentos com controle
de posição.
Encontrou-se poucas pesquisas sobre manutenção dos mesmos. Muitas
vezes sistemas de manutenção cam a cargo da indústria. Como poucas empresas possuem robôs nos seus catálogos de produtos, torna-se ainda mais
restrito o desenvolvimento de softwares de monitoramento para os manipuladores. Dessa forma, nada similar foi encontrado. Além disso, no Brasil a
2.6.0
Panorama Atual
26
extensão C4GOpen é utilizada apenas pela UFMG.
Portanto, o projeto realizado nesse trabalho pode ser considerado como
inovador, não pelos conceitos envolvidos em seu desenvolvimento, mas pela
sua aplicabilidade e funcionalidade prática na indústria, e pionerismo na
pesquisa da biblioteca C4GOpen.
No capítulo seguinte será exposto a especicação de requisitos do software
desenvolvido.
Capítulo 3
Desenvolvimento e
Implementação
Este capítulo apresenta todo o desenvolvimento do projeto, os problemas
encontrados e as soluções propostas. Inicialmente abordam-se alguns passos
inicias necessários ao desenvolvimento. Posteriormente fala-se do software e
como cada módulo do mesmo foi construído.
3.1 Trabalhos Iniciais
Após o robô Comau ser devidamente instalado, testado e estar pronto para
operar, foi ministrado um curso com duração de duas semanas visando ensinar a programação na linguagem PDL2. Durante o curso, tentou-se congurar o modo de detecção de choques. Tal modo determina uma colisão de
acordo com a variação da corrente dos motores da junta. Uma sensibilidade
congurável de 0% a 100% determina a força máxima de choque (variação especíca da corrente) aceitável. Essa conguração foi realizada no método de
tentativa e erro, de forma errada. Na forma correta, deveria-se colocar o manipulador para realizar a tarefa desejada e depois congurar a sensibilidade.
Estipulou-se a sensibilidade antes de movimentar o robô, dessa forma para
sensibilidade acima de um valor, movimentos mais bruscos foram sentidos
como choques devido à variação da corrente. Em contrapartida utilizando
sensibilidade baixa nem todos os choques foram detectados.
O que se pode perceber no curso é a grande semelhança entre PDL2 e a
linguagem Pascal. Um código de movimentação comum possui uma função
main que chama ciclicamente uma rotina que executa os movimentos para as
posições desejadas, conforme ilustra Figura 3.1. Estas posições são variáveis
do tipo POSITION que contém indicações de x, y e z, além de informações
27
3.2
O Programa - Izimov
28
Figura 3.1: Um exemplo de código de movimentação para o robô em PDL2.
sobre o sentido da rotação dos motores, conforme ilustra Figura 3.2. Todos
os movimentos do exemplo foram do tipo junta, isto é, as juntas se movimentam da melhor forma para alcançar o ponto desejado. Entretanto, quando
o sistema estiver funcional e estabilizado, serão realizados testes com movimentos lineares e utuantes. Movimentos utuantes são aqueles utilizados
principalmente para transporte, já que o robô não chega exatamente nos
pontos estipulados, passa próximo, unindo um translado a outro, visando o
ganho de velocidade. Todos estes movimentos, assim como melhores explicações sobre os testes serão apresentados no capítulo seguinte.
Os códigos em PDL2 não são exclusivamente para movimentos. Utilizando essa linguagem é possível coletar e setar variáveis do robô. Maiores
detalhes serão expostos na Subseção 3.2.3.
3.2 O Programa - Izimov
O software é denominado Izimov em homenagem ao considerado pai da
robótica Isaac Azimov, além de lembrar o nome de sua principal obra "I
Robot". Este sistema possui basicamente os módulos:
• Alarmes;
• C4GOpen, este sendo divido em:
Corrente dos Eixos;
3.2
O Programa - Izimov
29
Figura 3.2: Um exemplo da variável POSITION no PDL2.
Posição e Velocidade dos Eixos.
• PDL2, composto por:
Corrente dos Eixos;
Posição dos Eixos e Velocidade.
No módulo PDL2 preferiu-se utilizar a velocidade do robô e não das juntas. A velocidade dos eixos pode ser determinada pela derivada das posições,
a do robô é mais complicada de se inferir a partir das outras informações.
Poderia-se coletar as informações da variável RAD VEL que aponta a velocidade do eixo por cada tick (para o robô em especíco é 2 ms). Entretanto,
visando um módulo um pouco diferente do C4GOpen preferiu-se medir a
velocidade do robô.
Para o início do desenvolvimento escolheu-se a biblioteca para fazer a
interface gráca. Conforme explicitado em 2.5, a biblioteca wxWidgets foi
escolhida por ser versátil e de código livre, ter uma versão estável e não
demandar grandes requisitos de hardware.
A Figura 3.3 ilustra em forma de diagrama o funcionamento geral do
programa. No programa você escolhe a aba em que deseja acompanhar ou
pode sair do programa. Cada aba tem um funcionamento especíco, mais
3.2
Módulo de Alarmes
30
detalhes sobre cada aba estão nas Seções 3.2.1, 3.2.2 e 3.2.3, onde se explica,
também, o desenvolvimento dos módulos.
Figura 3.3: Diagrama macro do funcionamento do programa.
3.2.1 Módulo de Alarmes
O módulo de alarme tem intenção de transformar o log dos robôs em informação para a equipe de manutenção. Os robôs geram alarmes para cada
ação inconveniente tomada pelo usuário, ou algum incidente provocado pelo
próprio robô. Os alarmes são desde erros na compilação do código PDL2 até
falhas na comunicação, desligamento, dentre outros.
O que agrega valor é separar os alarmes em mais frequentes e mais críticos,
isto é, cujo nível é o mais alto. Os níveis dos alarmes são de 0 a 15, sendo os
de nível "0"alarmes informativos e "15"alarmes que podem causar danos ao
robô ou à atividade desempenhada por este.
3.2
Módulo de Alarmes
31
Inicialmente, pensou-se em criar uma classe do tipo Alarme, que receberia os alarmes ocorridos pelo robô e contaria quantas vezes cada tipo de
alarme ocorreu através da implementação de um multimap. Entretanto, ao
perceber a variedade de alarmes existentes, deniu-se que a criação de um
banco de dados que contém todos os alarmes existentes é mais viável, já que
se fosse criada uma classe para cada alarme o sistema teria problemas com
armazenamento dinâmico. Além disso, ao se fechar o programa tudo seria
perdido.
Figura 3.4: Diagrama de entidade relacionamento do banco de dados para
alarmes.
Na Figura 3.4 percebe-se a tabela Alarme, que é povoada com todos os
alarmes existentes para o robô. Tal tabela possui o código único Comau de
cada alarme, o nível do mesmo e a descrição genérica do alarme. Exemplo:
15442, 2 e WARNING File nome le transferido corretamente de C4G a host.
Nesse exemplo é possível vericar porque se diz que a descrição é genérica.
Qualquer falha que dê problema no arquivo, será agrupada em um tipo só,
já que o importante é o tipo de alarme que ocorre no robô.
Além disso, há a tabela Tratamento que contem a identicação, o tratamento em si e o identicador do alarme. Tratamento é um instrução que
direciona o robotista para a provável solução do problema. Por motivos de
condencialidade não se pode povoar com os tratamentos corretos para os
alarmes, isso só será feito apenas na Comau.
Ademais, tem-se a tabela Ocorrência, esta contém o identicador da ocorrência (auto-incrementável), data e hora da mesma. Essa tabela se relaciona com os alarmes, por isso possui uma chave estrangeira que se refere
3.2
Módulo de Alarmes
32
aos mesmos. Por último, Ocorrência também contém uma relação com
a tabela Robô da forma N:M, por isso, utiliza-se a tabela intermediária
Robô has Ocorrência. A tabela Robô contém um número identicador para
o robô e um nome fantasia para o mesmo.
O banco de dados é implementado utilizando o MySql Workbench 5.2.27
CE. Essa ferramenta permite gerar o diagrama entidade relacionamento, tal
como o da Figura 3.4, além de rodar o servidor do banco de dados. Escolheuse utilizar MySql por se tratar de um software livre, não exigir grandes recursos de hardware e ser compatível com Linux e Windows.
A Figura 3.5 ilustra de forma supercial o funcionamento da aba alarme.
Figura 3.5: Diagrama macro do funcionamento da aba "Alarmes".
Como primeiro passo visando classicar os alarmes, deve-se coletar o arquivo no formato texto (.log) que o próprio robô gera. Tal arquivo é coletado
utilizando o software WinC4G que acompanha o robô Comau.
Utilizando-se o programa WinC4G, pode-se coletar o log com todas as
informações. Após coleta-lo, o usuário deve ir na barra de menu->Arquivo>Abrir Log. Ao fazer essa seleção o programa instancia uma classe do tipo
3.2
Módulo de Alarmes
33
Leitura, que pega o arquivo com o histórico de alarmes, trata o mesmo,
conecta-se ao banco de dados e povoa a tabela Ocorrência com as referentes
àquele robô. A conexão do programa com o banco de dados é realizada
através da biblioteca MySql++. Essa conexão é realizada via código em
C++, um exemplo pode ser visualizado na Figura 3.6.
Figura 3.6: Exemplo de código em MySQL++.
Utilizando pesquisas SQL ordenaram-se os alarmes por nível e frequência.
O resultado dessas pesquisas é coletado e povoa os respectivos grácos e
grids. Para os grids utilizou-se a biblioteca wxGrid, membro da biblioteca
wxWidgets. Para os grácos em barra (utilizados nesse módulo) criou-se
uma classe em especíco. Essa classe possui construtores similares aos itens
existentes do wxWidgets. Além disso, esse tipo de gráco recebe até cinco
pares de strings mais inteiros. Ademais, mantém as barras separadas de
forma igualitária.
Vale ressaltar que para ns de visualização no próprio programa, lista-se
apenas os dez alarmes mais frequentes e os dez mais impactantes. Enquanto
nos grácos apresentam apenas os cinco primeiros de cada tipo. Entretanto,
o programa gera um arquivo texto com todos os dados tratados e ordenados
por nível e outro para ocorrências. Tais arquivos deverão ser repassados a
equipe de manutenção Comau para o correto diagnóstico de cada robô.
A Figura 3.7 ilustra como cou a tela para gestão de alarmes. As indicações são apenas para ilustrar cada componente utilizado.
3.2
Módulo C4GOpen
34
Figura 3.7: Exemplo da tela de "Alarmes".
3.2.2 Módulo C4GOpen
O módulo C4GOpen tem intenção de coletar informações do robô em tempo
real. Ele é composto por duas abas, uma que monitora as posições e velocidades dos eixos e outra que monitora as correntes alvo dos motores. Corrente
alvo é aquela que o robô seta para realizar o movimento especíco.
Inicialmente pensou-se em realizar o monitoramento de mais variáveis.
Entretanto, a biblioteca C4GOpen, como ilustrado na Figura 2.11, possui um
pacote pré-denido de variáveis, com uma quantidade restrita das mesmas.
Portanto, escolheram-se as que poderiam ser úteis à manutenção Comau.
A tela "Corrente dos Eixos"possui uma tabela que armazena as 100
medições mais recentes em amperes, além disso, contém um gráco com
as correntes dos eixos 1-2-3 e outro com as dos eixos 4-5-6. Para os grácos
criou-se uma classe especíca. Essa classe possui construtores similares aos
itens existentes do wxWidgets e recebe valores doubles para três variáveis.
Usou-se uma função de buer que armazena os 50 valores passados do gráco,
dessa forma, cada nova inserção não solicita que todo o gráco seja redesenhado, mas sim, apenas o inserido. Os passados são recarregados diretamente
do buer. O gráco ajusta suas escalas do eixo vertical e horizontal de forma
a contemplar os últimos 50 valores, isto é realizado dentro da função Refresh,
3.2
Módulo C4GOpen
35
chamada a cada inserção. Tal tela pode ser vista na Figura 3.8.
Figura 3.8: Exemplo da tela "Corrente dos Eixos"do módulo C4GOpen.
Já a tela "Posição e Velocidade dos Eixos"contém duas tabelas, sendo
um para posição e outro para velocidade de todas as juntas. Estes expõem
apenas as 100 últimas medições. Esta tela está exposta na Figura 3.9.
Vale ressaltar que embora as Figuras 3.8 e 3.9 estejam com visual do
Windows as mesmas serão úteis apenas no Linux.
A Figura 3.10 expõe um diagrama do funcionamento das abas "Corrente dos Eixos"e "Posição e Velocidade dos Eixos", referentes aos módulo
C4GOpen.
O usuário deve ir à barra de menu->Robô->Conectar C4GOpen. Ao
fazer essa seleção o programa chama o evento para a conexão. Como se
sabe, tal módulo utiliza a biblioteca C4GOpen e, portanto, necessita rodar
no Linux com RTAI e RTnet. Dessa forma, a primeira implementação realizada foi testar se o programa está executando no Linux ou Windows. Caso
esteja executando no Windows uma mensagem aparece na tabela e no memo
armando que não é possível a execução. Se o sistema estiver executando no
Linux ele inicia os procedimentos para coleta das informações, chamando o
programa de coleta em C4GOpen.
O programa de coleta é baseado no exemplo do C4GOpen, que impõe
uma senóide em cada motor do robô. Este programa inicialmente instancia
3.2
Módulo C4GOpen
36
Figura 3.9: Exemplo da tela de "Posição e Velocidade dos Eixos"do módulo
C4GOpen.
3.2
Módulo C4GOpen
37
Figura 3.10: Diagrama macro do funcionamento das abas "Corrente dos
Eixos"e "Posição e Velocidade dos Eixos".
3.2
Módulo C4GOpen
38
uma classe do tipo C4GOpen e habilita os eixos que se deseja movimentar.
O usuário escolhe qual a amplitude e a frequência da senóide. Posteriormente ele coleta a taxa de transmissão do eixo especicado, pois o mesmo é
necessário para determinar a posição dos eixos, e inicia um laço (loop ). Esse
loop verica se o sistema recebeu o pacote de informações do tipo da Figura
2.11. Caso tenha recebido verica qual o modo estipulado. Se for de saída
ele sai do laço. Caso seja ou modo Drive On, ou modo 0 (somente leitura) ou
modo 4 (seta posição e velocidade, além de fazer leitura) ele continua executando. Se for a primeira vez que ele entra dentro dessa condição, ele seta as
posições inicias para cada eixo. Depois testa se o robô está em "Drive On".
Se estiver "Drive O" ele verica novamente se recebeu os pacotes, caso
esteja "On", seta o movimento e mede as posições, velocidades e correntes.
Na primeira implementação, o programa de coleta executava internamente ao Izimov, enviando para as tabelas e grácos correspondentes. Importante ressaltar que como a coleta é feita a cada 2 milissegundos, há um
contador interno para atualizar os grácos e a tabela a cada 2 segundos,
entretanto, se qualquer valor de corrente for maior que 20% que a corrente
nominal, o usuário seria noticado por um memo. A Figura 3.11 ilustra o funcionamento do programa para coleta de informações rodando internamente
ao Izimov.
Entretanto, conforme será explicitado em 4.2 ao ativar a parte em tempo
real dentro do Izimov o programa parou de funcionar. Desta forma partiu-se
para a nova implementação.
Nesta nova implementação, utilizou-se um arquivo onde eram escritas as
variáveis advindas do programa de coleta em C4GOpen e o programa Izimov
cava encarregado de ler o arquivo e atualizar a tela. O controle de acesso
ao arquivo foi realizado através de um semáforo que verica se o arquivo
(seção crítica) está sendo usado. A nova implementação pode ser visualizada
na Figura 3.12. Repare que todo o programa de coleta em C4GOpen foi
resumido em um "estado", com o intuito de simplicar o diagrama e pelo
mesmo motivo, omitiu-se o teste de sistema operacional.
Tal implementação não foi suciente para a execução do programa. Este
novamente parou de funcionar. Partiu-se para os testes Oine, isto é, coletando os dados, salvando-os em arquivo, e por m, lendo o arquivo. Dessa
forma percebeu que o programa parava até o m da leitura do arquivo.
Quando a leitura se encerrava, ele apresentava todos os dados das tabelas
preenchidos. Dessa forma, chegou-se a duas conclusões:
• A tabela não estava atualizando a cada inserção, era necessário chamar
a função para que o mesmo atualizasse a cada adição de valor;
3.2
Módulo C4GOpen
39
Figura 3.11: Diagrama macro do funcionamento do programa C4GOpen dentro do programa Izimov.
3.2
Módulo C4GOpen
40
Figura 3.12: Diagrama macro do funcionamento do programa C4GOpen externo ao programa de interface.
3.2
Módulo C4GOpen
41
• Era necessário criar threads para que o programa principal não casse
bloqueado, além de reduzir a prioridade da coleta do RTAI.
Dessa forma, dispensaram-se os semáforos e retornou a primeira implementação, entretanto, com inserção de threads. A Figura 3.13 ilustra a versão
nal do módulo. Nela pode-se observar a mesma estrutura de outrora, com
o programa de coleta rodando dentro do Izimov. A diferença está na inserção de uma thread para a execução da coleta dos dados e outras para
preenchimento das tabelas e grácos. Utilizou-se wxThread da biblioteca
wxWidgets para esta implementação. Ademais, adicionou-se mutexes para
acesso aos grácos e às tabelas, dessa forma as threads não poderiam acessar
simultaneamente os mesmos.
Figura 3.13: Implementação nal do módulo C4GOpen.
Vale ressaltar que muito tempo foi despendido no início do desenvolvimento tentando implementar threads no programa de coleta de dados.
3.2
Módulo PDL2
42
Pensou-se que para ler as variáveis do sistema em tempo real seria necessário
utilizar threads para processamento paralelo. Entretanto, o C4GOpen dispensa o uso das mesmas, já que envia um pacote com todas as informações,
para o caso especíco, a cada 2 milissegundos. Além disso, para familiarização com Linux e desenvolvimento de software no mesmo, foi necessário muito
esforço e tempo.
Por m, é importante frisar o tamanho da ajuda do aluno Adriano Araújo
Abreu Mourão, bolsista junto ao laboratório CORO. O mesmo despendeu
muito tempo para congurar o C4GOpen, além de repassar ao autor as diretrizes para utilizar esta biblioteca. Sendo assim, o mesmo foi um facilitador
desse trabalho.
3.2.3 Módulo PDL2
O módulo PDL2 visa realizar a coleta das informações do robô. Entretanto,
tal método não é realizado em tempo real. Esse módulo é composto por
duas abas, uma que monitora as posições dos eixos e a velocidade, e outra
que monitora as correntes dos motores.
A aba "Corrente dos Eixos"em PDL2 é similar a de mesmo nome do
C4GOpen. Contém uma tabela que ilustra as 100 medições mais recentes
em amperes, contém um gráco com as correntes dos eixos 1-2-3 e outro com
as dos eixos 4-5-6. Por m, possui um "memo"para alertar sobre-correntes.
Os grácos para essas correntes são idênticos aos do módulo C4GOpen. A
tela pode ser vista na Figura 3.14.
Enquanto isso, a aba "Posição dos Eixos e Velocidade"possui duas tabelas,
sendo um para posição da ponta do robô (em coordenadas cartesianas) e
outro para velocidade do braço em m/s. Estes expõem apenas as 100 últimas
medições. Esta tela é ilustrada na Figura 3.15. É importante ressaltar,
que a posição do robô depende diretamente da referência utilizada. Tal
conguração é feita via WiTP, na opção Motion.
Para a coleta dos dados, a princípio tentou-se habilitar uma rede TCP/IP
, dessa forma o robô enviaria os dados diretamente pela própria rede. Entretanto, conectava-se ao robô, mas não se conseguia coletar as informações
enviadas pelo mesmo.
Posteriormente pensou-se que a solução utilizando transferência de arquivos com os dados coletados seria a forma mais eciente. Como havia
se perdido a característica de tempo real e a principal característica do sistema é fornecer informações à manutenção Comau, logo o mais importante
é se criar um histórico com os dados. Ademais, tal solução seria funcional
independente das congurações de rede do robô. Tentou-se implementar o
envio dos arquivos através do comando em PDL2 SYS CALL. Este utiliza o
3.2
Módulo PDL2
43
Figura 3.14: Exemplo da tela de "Corrente dos Eixos"do módulo PDL2.
Figura 3.15: Exemplo da tela de "Posição dos Eixos e Velocidade"do módulo
PDL2.
3.2
Módulo PDL2
44
comando de envio para o drive 'COMP:' que detecta qual rede está estabelecida com o computador e envia o arquivo para o mesmo. A pasta para onde
se encaminha o arquivo é escolhido na conguração de conexão do WinC4G
e a comunicação é realizada via TCP/IP.
O robô é um servidor FTP ativo, por isso, criou-se um cliente FTP que
realizava downloads assíncronos dos arquivos com os dados medidos.
Dessa forma implementou-se um programa em PDL2 executando no robô
que coletava as informações desejadas e salvava em arquivos. Ele fazia a
coleta de 1000 medidas, fechava o arquivo e abria outro com outro nome.
A mudança de nome era feita através do função ENCODE que basicamente
converte e une strings, inteiros, reais, dentre outros, em uma única string. O
programa Izimov instanciava uma classe de leitura do tipo "LeituraPDL2",
e possuía um delay para esperar que o arquivo fosse gerado e recebido, só
então leria o mesmo, este processo executaria de forma periódica. Essa implementação necessitou de testes para garantir que esse delay fosse maior que o
tempo de elaboração e recebimento do novo arquivo. Em contrapartida, esse
deveria ser o menor possível para reduzir o atraso nas medições. Após ler o
arquivo o Izimov preenche as tabelas e grácos correspondentes. Para habilitar a coleta o usuário deve ir no seguinte caminho> menu->Robô->Conectar
PDL2.
Dessa forma, para construir tal módulo implementou-se um programa em
PDL2 cuja estrutura é a da Figura 3.16.
Entretanto, depois de inúmeros contatos com a Comau Itália, após vericar com a Comau do Brasil a melhor forma de realização desse módulo,
chegou-se a conclusão que utilizando a porta serial RS422 com um conversor
para RS232. Para tal implementação utilizou-se um programa em PDL2, NoHold (executando em paralelo ao programa principal) que habilita a porta
serial e escreve os sinais medidos com Baud Rate (pulsos por segundos) de
9600, 8 bits por por caracter, sem paridade e 1 bit de parada. Enquanto isso,
no programa Izimov há um cliente que se conecta ao robô e recebe os dados
em uma string única. O Izimov trata os dados e atualiza as tabelas e grácos
chamando threads para tal.
Para parar a coleta deve-se apenas ir ao botão menu->Robô>Desconectar PDL2. É recomendável desativar o programa em PDL2 que
está rodando no robô.
No próximo capítulo serão apresentados os testes com os módulos.
3.2
Módulo PDL2
Figura 3.16: Implementação nal do módulo PDL2.
45
Capítulo 4
Testes e Análise de Resultados
Este capítulo apresenta os testes realizados com todos os módulos do programa Izimov.
4.1 Testes Módulo de Alarmes
Visando testar o módulo de alarme, coletou-se o log do robô Six da UFMG
na data de 21 de setembro de 2010 e o de um robô NJ destinado a solda da
linha de produção do novo Pálio da FIAT no dia 04 de novembro de 2010.
Realizando o procedimento para tratar os alarmes, ativou-se o servidor
do banco de dados dos alarmes e abriu-se o log relativo ao robo Six. Para
tal robô, teve-se como resultado a Figura 4.1.
As Tabelas 4.2 e 4.1 apresentam os 20 primeiros resultados presentes nos
arquivos gerados. Não se colocou todos os valores, por se tratarem de um
arquivo extenso que não agregariam muito valor.
Realizou-se o mesmo procedimento para o robô NJ. A Figura 4.2 ilustra
como cou a tela para gestão de alarmes.
As Tabelas 4.4 e 4.3 ilustram os resultados presentes nos arquivos gerados
para tal robô.
4.1.1 Diagnóstico
Analisando os resultados obtidos nos alarmes do robô Six pode-se fazer
algumas inferências e conclusões. Vericando os alarmes mais frequentes,
percebemos que "DRIVE OFF Mau funcionamento do dispositivo de habilitação"é a falha mais comum. Entretanto, esta ocorre na maioria dos casos
quando o usuário pressiona fortemente ou solta o dispositivo de segurança do
WiTP. Sabendo que tal robô é utilizado para ns acadêmicos, esta situação
46
4.1
Diagnóstico
47
Figura 4.1: Tela de Alarmes após teste para Robô Six.
Nível
14
13
13
11
11
11
11
11
11
11
11
11
11
11
11
11
11
11
11
11
Código
28675
64001
64026
28820
28833
61952
64031
28818
28829
62001
28826
61991
61953
28819
54290
28811
54277
62014
28828
61992
Tabela 4.1: Teste Alarmes Robô Six - Nível
Descrição
FATAL SMP tarefa <nome tarefa> anulada
FATAL DSA: <num dsa> erro de comunicação
FATAL C4GOpen: erro de comunicação
DRIVE OFF Telerutores de potência, erro no canal 2
DRIVE OFF Habilitação acionamentos falida(sts:<estado>,
DRIVE OFF DSA: <num servo> Erro nas fases da seção de
DRIVE OFF C4GOpen: arm <num arm> eixo <num ax> erro de
DRIVE OFF Mau funcionamento contactores de potência
DRIVE OFF Mau funcionamento do telerutor da Aplicação
DRIVE OFF DSA: <num servo> Falta da alimentação a 24 volt
DRIVE OFF Anomalia no output 1 das seguranças (cnl:<canal>,
DRIVE OFF SAX: <num servo> <num arm> <num eixo> erro
DRIVE OFF DSA: <num servo> Incongruência na função de freamento
DRIVE OFF Telerutores de potência, erro no canal 1
DRIVE OFF Ausência de comunicação no CAN Bus
DRIVE OFF Stop geral
DRIVE OFF Nó <endereço>, não conectado
DRIVE OFF SAX: <num servo> <num arm> <num eixo> DSP
DRIVE OFF Anomalia do relé de segurança das chas no canal d
DRIVE OFF DSA: <num servo> Tensão no bus não coerente
4.1
48
Diagnóstico
Ocorrências
135
110
93
46
45
41
38
35
34
28
27
26
23
21
18
17
17
14
13
13
Tabela 4.2: Teste Alarmes Robô Six - Ocorrências
Código
28846
28825
64026
28811
62513
64033
62014
58881
36884
61991
36926
62465
59411
36999
28828
64031
36945
62466
39960
61970
Descrição
DRIVE OFF Mau funcionamento dispositivo de habilitaçao
DRIVE OFF Anomalia cha seguranças (cnl:<canal>, sts:<estado>)
FATAL C4GOpen: erro de comunicação
DRIVE OFF Stop geral
DRIVE OFF SAX: <núm servo> <núm arm> <núm eixo> relevada colisão
DRIVE OFF C4GOpen: Drive O do PC
DRIVE OFF SAX: <num servo> <num arm> <num eixo> DSP
DRIVE OFF SAX: <num servo> <num arm> <num eixo> eixo em um
PAUSE <id prog>(<núm linha>): linha de mov <núm linha> tem erro
DRIVE OFF SAX: <num servo> <num arm> <num eixo> erro
PAUSE <id prog>(<núm linha>): acesso a LUN é inválido
WARNING SAX: <núm servo> <núm arm> <núm eixo> limite de curso
HOLD SAX: <núm servo> <núm arm> <núm eixo> mov após desligaçao
PAUSE <id prog>(<núm linha>): indicador de posição da cfgn err
DRIVE OFF Anomalia do relé de segurança das chas no canal
DRIVE OFF C4GOpen: arm <num arm> eixo <num ax> erro
PAUSE <id prog>(<núm linha>): var JOINTPOS não inicializada
WARNING SAX: <núm servo> <núm arm> <núm eixo> limite de curso
PAUSE <id prog>(<núm linha>): SYS CALL erro <núm erro>
DRIVE OFF SAX: <num servo> <num arm> <num eixo> DSP Cabo motor
Figura 4.2: Tela de Alarmes após teste para Robô NJ.
4.1
49
Diagnóstico
Nível
11
11
11
11
11
10
10
10
10
8
8
4
4
Tabela 4.3: Teste Alarmes Robô NJ FIAT - Nível
Código
61952
62475
61970
28833
61992
58880
13339
58881
62513
23555
23559
23580
13364
Ocorrências
19
14
11
9
9
7
5
3
2
2
2
2
1
Descrição
DRIVE OFF DSA: <num servo> Erro nas fases da seçao
DRIVE OFF CPU <núm cpu> cadeia segurança aberta como erro
DRIVE OFF DSA: <num servo> erro de DRIVE ON
DRIVE OFF TP erro
DRIVE OFF SAX: <num servo> <num arm> <num eixo>
Relé 1 do package 1 não aberto.Espera IN[49] = True. IN[49] = False
Falta de uxo d'água package 1 Flux 1 IN[ 34]= False
Temporizador de soldadura 1 alarme 032 Corrente soldagem nula
PAUSE TP desconectado
Tabela 4.4: Teste Alarmes Robô NJ FIAT - Ocorrências
Código
58881
23580
62475
58880
28833
13364
23555
61970
62513
61952
13339
23559
61992
Descrição
DRIVE OFF SAX: <num servo> <num arm> <num eixo>
Temporizador de soldadura 1 alarme 032 Corrente soldagem nula
DRIVE OFF CPU <núm cpu> cadeia segurança aberta como erro
DRIVE OFF DSA: <num servo> erro de DRIVE ON
PAUSE TP desconectado
Relé 1 do package 1 não aberto.Espera IN[49] = True. IN[49] = False
DRIVE OFF DSA: <num servo> Erro nas fases da seção de
DRIVE OFF TP erro
Falta de uxo d'água package 1 Flux 1 IN[ 34]= False
4.2
Módulo C4GOpen
50
é, não só justicável, como previsível. Além disso, há erros de comunicação
frequentes, estes são justicáveis pela utilização do C4GOpen, que possui um
sistema sensível para comunicação. As falhas relativas a colisões provavelmente é consequência dos testes para conguração do detector de choques.
Ao focar-se nos mais impactantes, os alarmes relativos ao C4GOpen são
os mais impactantes, eles estão relacionados à conexão do robô com o computador. Portanto, tratando-se dos alarmes do robô Six não há nada com o
que se preocupar.
Observando as informações do robô NJ, percebe-se que há falhas de programação e Drive O, comuns em qualquer robô. Aparentemente esse robô
teve problemas graves com seu sistema de solda e com o cabo do seu terminal
de programação.
4.2 Testes Módulo C4GOpen
Para o módulo C4GOpen executou-se dois modos de testes: os testes ditos
"Oine "e "Online ". As Subseções 4.2.1 e 4.2.2 apresentam esses dois testes.
É importante frisar que por motivos de segurança o programa não movimenta
o eixo 2, já que devido a um acidente ocorrido recentemente, a utilização desse
eixo é recomendado apenas em caso de necessidade extrema.
4.2.1 Testes Oine do C4GOpen
Conforme explicitado na Subseção 3.2.2 pensou-se que o correto seria implementar um programa para executar a coleta das informações do robô e
colocá-las em um arquivo, enquanto o Izimov leria esse arquivo e atualizaria
as tabelas, grácos e memo correspondentes. O controle de acesso ao arquivo
seria feito por um semáforo. Entretanto, tal módulo cava parado até o término de leitura do arquivo. Dessa forma implementou-se threads para coleta
e atualização da tela.
No modo oine todos os dados foram coletados em um arquivo e o Izimov
leu e atualizou as telas. Utilizando o arquivo gerado o software funcionou
corretamente. É importante ressaltar que o teste de apresentação dos valores
de sobre-correntes ocorreu apenas no teste oine, já que foram inseridos
valores falsos de corrente no arquivo. Assim, partiu-se para os testes online.
4.2.2 Testes Online do C4GOpen
O modo online é o sistema rodando de forma integrada, isto é, coletando e
atualizando a tela a medida que os dados são coletados. Como a coleta é
4.3
Módulo PDL2
51
a cada 2 milissegundos, apresenta-se apenas uma medida a cada 500 realizadas. Isso é para melhor visualização do usuário. Ademais, esse projeto
visa vericar o aumento progressivo das correntes dos motores e não picos
momentâneos destas. Além disso, caso a corrente seja maior que um valor
determinado o memo apresentará.
Realizando o teste online e as abas caram como ilustram as Figuras 4.3
e 4.4.
Figura 4.3: Resultado do teste da tela "Corrente dos Eixos"do módulo
C4GOpen.
4.3 Testes Módulo PDL2
Para o módulo PDL2 também foram realizados dois tipos de testes: "Ofine "e "Online ". As Subseções 4.3.1 e 4.3.2 apresentam estes testes. Da
mesma forma que para o C4GOpen, a noticação de sobre-correntes foi testada apenas para o módulo oine, já que inseriu-se valores falsos ao arquivo
de correntes.
4.3.1 Testes Oine do PDL2
Como já visto na Seção 3.2.3, implementou-se um programa em PDL2 no
robô que coleta os dados necessários. Inicialmente esse programa salvava
arquivos no robô que eram coletados via download FTP pelo computador. O
4.3
Testes Online do PDL2
52
Figura 4.4: Resultado do teste da tela de "Posição e Velocidade dos Eixos"do
módulo C4GOpen.
programa Izimov aguardava até que o arquivo seja recebido, fazia a leitura
do mesmo e atualiza as telas referentes ao PDL2. No teste oine os dados
foram enviados para o computador via comando no WiTP e o Izimov leu e
atualizou as telas.
Para testar a conexão serial utilizou-se inicialmente um programa denominado Hercules. Tal software verica a conexão e informações transferidas,
percebeu-se que o sistema estava funcionando corretamente. Encaminhou-se
para os testes online.
4.3.2 Testes Online do PDL2
No modo online todo o sistema é integrado e roda junto. Os testes foram realizados com um programa de movimentação simples, que integra movimento
de todos os eixos. Estes foram realizados na Comau por três motivos, possibilidade de se movimentar todos os eixos sem preocupação, acompanhamento
da robótica Comau e cabo serial com conversor já construído e pronto para
testes.
Executou-se o mesmo programa com as seguintes variações:
• Velocidade em 40% da máxima com movimentos do tipo MOVE LIN-
EAR ;
4.3
53
EAR ;
EAR ;
• Velocidade em 40% da máxima com movimentos do tipo MOVEFLY
LINEAR ;
LINEAR ;
LINEAR.
Inicialmente realizou-se também o teste linear com 50% da velocidade,
entretanto, a diferença entre seus resultados e da velocidade de 40% são
pequenos.
Para a posição dos movimentos do tipo MOVE LINEAR não encontrou-se
grandes diferenças entre os sinais medidos apesar do aumento de velocidade.
O que pode iludir é o fato da medida está sendo feita a cada 1 segundo e é
difícil coincidir a coleta para duas velocidades diferentes o mesmo ponto. Para
os movimentos MOVEFLY percebeu-se que com o aumento da velocidade
impacta diretamente nas posições, quanto maior a velocidade, mais distante
o robô passa do ponto desejado. Para ilustrar cada medição mostra-se nas
Figuras 4.5 e 4.6 movimentos com velocidade 80% para MOVE LINEAR e
para MOVEFLY LINEAR.
Para as correntes nota-se grande diferença, principalmente visualizando
os grácos, quando se altera o tipo de movimento ou a velocidade do mesmo.
O primeiro ponto que se comprova é que ao solicitar maiores acelerações, as
correntes aumentam. Além disso, para movimentos do tipo MOVE LINEAR,
como o robô deve alcançar exatamente aquele ponto, tem-se um aumento da
corrente para frenagem e para partida. Logo, possui correntes mais altas do
que para os movimentos do tipo MOVEFLY. Como a temperatura dos motores depende, dentre outros fatores, das correntes dos mesmo, e robôs para
solda (mais utilizado pela Comau) precisam ser precisos e rápidos, faltamente
estes são os que apresentam maiores defeitos. Sendo assim, tais robôs são o
foco inicial de monitoramento proposto por este trabalho.
As Figuras 4.7, 4.8, 4.9, 4.10, 4.11 e 4.12 ilustram as medições de correntes
para todos os testes realizados. Os testes foram feitos no robô NS da Comau,
para o mesmo movimento, apenas aumentando a corrente e variando entre
MOVE LINEAR e MOVEFLY. Tentou-se realizar movimentos que afetassem
4.3
54
Figura 4.5: Tela "Posição dos Eixos e Velocidade"do módulo PDL2 para
velocidade em 80% em MOVE LINEAR para NS.
velocidade em 80% em MOVEFLY LINEAR para NS.
4.3
55
todos os eixos. Para os robôs da Comau que passarão por análise, o técnico
em manutenção terá a sua disposição uma simulação que indicará exatamente
qual o movimento executado por cada robô.
Figura 4.7: Tela "Corrente dos Eixos"do módulo PDL2 para velocidade em
40% em MOVE LINEAR para NS.
Por m, utilizando o robô NJ110 com um gripper pneumático com velocidade de 50% da velocidade máxima, obteve-se as Figuras 4.13 e 4.14.
O próximo capítulo expõe as conclusões do projeto e sugestões de trabalhos futuros.
4.3
56
4.3
57
40% em MOVEFLY LINEAR para NS.
4.3
58
50% em MOVE LINEAR para NJ110.
4.3
59
velocidade em 50% em MOVE LINEAR para NJ110.
Capítulo 5
Conclusão
Com esse trabalho notou-se o quanto o robô Comau possui diversas funcionalidades, é versátil, preciso e eciente. Muito ainda pode ser feito com
o mesmo, pois seu potencial é enorme. Esse trabalho tem o intuito de ser o
passo inicial para o desenvolvimento de novos programas, funcionalidades e
pesquisas com a linha Smart.
Este projeto possibilita à manutenção Comau diagnosticar robôs conciliando as informações provenientes do módulo de alarmes, juntamente com
os dados medidos pelos sensores. Agora a equipe de manutenção conseguirá
fazer outros estudos sobre os manipuladores.
Quanto aos conhecimentos acadêmicos, muito foi aprendido, principalmente em relação a programação gráca, a manipuladores robóticos, programação em tempo real e concorrente, a linguagem PDL2 e a biblioteca
C4GOpen, atendendo aos objetivos iniciais propostos.
Esse trabalho diversas vezes se deparou com grandes diculdades em encontrar informações de como realizar a coleta dos sensores, quais sensores
estavam habilitados, dentre outros. Isso se deve ao fato de ser algo pouco
pesquisado, de o maior material de referência ser apenas os manuais Comau
e o grande centro de informações se encontrar em Turin.
Além disso, a tarefa de se utilizar as bibliotecas wxWidgets e MySQL++
foi árdua, pois todo o conhecimento para tal foi adquirido durante o desenvolvimento através de pesquisas, discussões e testes.
Outro ponto relevante foi a utilização de threads, algo aparentemente
trivial, mas que foi descoberto de certa forma tardia, quando outras implementações já haviam sido testadas.
A seguir é exposta uma comparação entre PDL2 e C4GOpen, além de
sugestões para trabalhos futuros.
60
5.1
PDL2 e C4GOpen
61
5.1 PDL2 e C4GOpen
Inicialmente pensou-se que utilizando a biblioteca C4GOpen ter-se-ia acesso
de forma livre às variáveis e aos parâmetros do robô. Entretanto, ela é
mais simples que a linguagem PDL2, já que suas informações são restritas às
enviadas pelos pacotes de comunicação. Deve-se pensar que essa biblioteca
tem um objetivo distinto e não substitui a linguagem PDL2.
Enquanto o PDL2 é uma base para o robô, onde se consegue movê-lo e
ler variáveis, o C4GOpen possibilita fazer um controle especíco, além de
adicionar sensores externos. O C4GOpen não pode ser usado diretamente na
indústria, já que necessita de plataformas especícas e programar movimentos no mesmo possui complexidade muito superior ao PDL2. Entretanto, o
domínio da mesma permite avanço e melhorias nos robôs da linha Smart.
Uma das intenções desse trabalho era fazer com que a Comau investisse na
pesquisa com tal biblioteca, conseguiu-se expor para a alta gerência o benefício da mesma, além de apontar o quanto o robô possui potencial.
5.2 Trabalhos Futuros
A FIAT, principal cliente e parceira da Comau, tem o intuito de fazer um
sistema centralizado para monitorar os robôs. Esse trabalho é o primeiro
passo em direção a esse objetivo. Com ele expõe-se a capacidade de se fazer
tal sistema.
Além disso, pensa-se em realizar mais pesquisas com o C4GOpen com o
intuito de otimizar o controlador do manipulador. Como existe o interesse
em nacionalizar a construção dos robôs, visando um objetivo maior, imaginase a possibilidade de estabelecer na UFMG um centro de pesquisa similar ao
existente em Turin.
Fazer a monitoração do alarme em tempo real é outro trabalho proposto
para o futuro, isto é, receber o alarme do robô assim que ele detectá-lo e
apresentar imediatamente o tratamento. Desta forma, conseguiria-se fazer
reparos de forma mais rápida e eciente.
Referências Bibliográcas
[Bastos Filho, 2007] Bastos Filho, T. F. (2007). Guia da aula da disciplina Ocina
de Robótica ministrada para Mestrado e Doutorado. Universidade Federal do
Espírito Santo.
[Caccavale et al., 2009] Caccavale, F., Cilibrizzi, P., Pierri, F., and Villani, L.
(2009). Actuators fault diagnosis for robot manipulators with uncertain model.
Control Engineering Practice, 17(1):146 157.
[Campos, 1998] Campos, M. (1998). Slides módulo 1 de introdução a robótica.
www.verlab.dcc.ufmg.br/cursos/introrobotica/2009-2/transparencias/index.
Acessado em 05 de maio de 2010.
[Chou, 2005] Chou, Pai H.; Park, C. (2005). Energy-ecient platform designs for
real-world wireless sensing applications. Computer-Aided Design, pages 913920.
[COMAU, 2010] COMAU (2010). http://www.comau.com.br/ogrupo.htm. Acessado em 31 de março de 2010.
[CORO, 2010] CORO (2010). http://coro.cpdee.ufmg.br/index.php/home. Acessado em 31 de março de 2010.
[de Lima, 2008] de Lima, M. F. M. (2008). Análise dinâmica de vibrações em
manipuladores robóticos. PhD thesis, Universidade de Coimbra, Portugal.
[Ferretti, 2002] Ferretti, G. G. M. P. R. (2002). Adaptive compensation of torque
disturbances in an industrial robot. Paper in 15th IFAC World Congress Barcelona - Spain, 15(1).
[Fu, 1987] Fu, King Sun ; R. C. Gonzalez; Lee, C. S. G. (1987). Robotics - Control,Sensing, Vision and Intelligence. McGraw-Hill, Inc. New York, NY, USA.
[Galhano, 1992] Galhano, A. M. S. F. (1992). Uma modelagem estática à modelização de manipuladores robóticos. PhD thesis, Universidade do Porto.
[Macchelli, 2002] Macchelli, Alessandro; Melchiorri, C. (2002). A real-time control
system for industrial robots and control applications based on real-time linux.
Paper in 15th IFAC World Congress - Barcelona - Spain, 15(1).
62
REFERÊNCIAS BIBLIOGRÁFICAS
63
[Manik, 2007] Manik, E. O. D. D. N. (2007). Measurement Systems: Application
and Design. McGraw-Hill, New York, 5th edition.
[Michelini, 2001] Michelini, R.C.; Acaccia, G. (2001). Instrumental robots design
with applications to manufacturing. International series in engineering, technology and applied science., VII:7.017.62.
[Pires, 2000] Pires, J. N. (2000). Using actual robot manipulators with construction tasks. Proceedings of the ISARC17 Taipei - Taiwan.
[Pires, 2002] Pires, J. N. (2002). Das máquinas gregas à moderna robótica industrial. Jornal Público, Caderno de Computadores.
[Real Time Application Interface Ocial Website, 2010] Real Time Application
Interface Ocial Website, R. W. (2010). https://www.rtai.org/. Acessado em 10
de outubro de 2010.
[Robotics, 2005] Robotics, C. (2005). SMART SiX Maintenance. Comau.
[Robotics, 2007a] Robotics, C. (2007a). C4G Release 4 Control Unit Integration
guidelines, Safeties, I/O, Communications. Comau.
[Robotics, 2007b] Robotics, C. (2007b). SMART NS Technical Specications. Comau.
[Robotics, 2007c] Robotics, C. (2007c). SMART SiX Technical Specications. Comau.
[Robotics, 2009a] Robotics, C. (2009a). C4G Motion Programming - System Software Rel. 3.3x. Comau.
[Robotics, 2009b] Robotics, C. (2009b). SMART NJ Maintenance. Comau.
[Robotics, 2009c] Robotics, C. (2009c). SMART NJ Technical Specications. Comau.
[RTNet, 2010] RTNet, O. (2010). http://www.rtnet.org/. Acessado em 10 de outubro de 2010.
[Sintesi, 2008] Sintesi (2008). C4GOpen Library, Users Guide. Version 1.2.1.
[wxWidgets Cross-Platform GUI Library, 2010] wxWidgets
Cross-Platform
GUI Library (2010). http://www.wxwidgets.org/. Acessado em 10 de outubro
de 2010.

desenvolvimento de um software para monitoramento de um

Transcrição

Documentos relacionados

IMPLEMENTAÇÃO DE UM ROBÔ MÓVEL PARA AUTOMAÇÃO.

Desenvolvimento de Um Robô Autônomo para

desenvolvimento de um robô autônomo para participação em

Implementação de Comportamentos Reactivos no Robot Insónia

gass swampp

Aula Tipos de Robôs

o Gasparzinho não cura, mas joga a apanhada, e traz crianças para

Artigo Completo - Grupo de Controle Automação e Robótica

Prova Teórica do Nível 5

tectyl na proteção de eixos