A)Quatro a seis

PROGRAMAÇÃO EM ROBÓTICA

1
 NOSSA HISTÓRIA

A nossa história inicia-se com a ideia visionária e da realização do sonho

de um grupo de empresários na busca de atender à crescente demanda de
cursos de Graduação e Pós-Graduação. E assim foi criado o Instituto, como uma
entidade capaz de oferecer serviços educacionais em nível superior.

O Instituto tem como objetivo formar cidadão nas diferentes áreas de co-
nhecimento, aptos para a inserção em diversos setores profissionais e para a
participação no desenvolvimento da sociedade brasileira, e assim, colaborar na
sua formação continuada. Também promover a divulgação de conhecimentos
científicos, técnicos e culturais, que constituem patrimônio da humanidade,
transmitindo e propagando os saberes através do ensino, utilizando-se de pu-
blicações e/ou outras normas de comunicação.

Tem como missão oferecer qualidade de ensino, conhecimento e cul-

tura, de forma confiável e eficiente, para que o aluno tenha oportunidade de
construir uma base profissional e ética, primando sempre pela inovação tecno-
lógica, excelência no atendimento e valor do serviço oferecido. E dessa forma,
conquistar o espaço de uma das instituições modelo no país na oferta de cur-
sos de qualidade.

2
Sumário
NOSSA HISTÓRIA .................................................................................. 2

1. O ARDUINO ................................................................................... 5

1.1 Componentes de uma placa Arduino .......................................... 6

1.2 Família Arduino .............................................................................. 7

2. SENSORES .................................................................................... 8

3. LINGUAGENS E SISTEMAS DE PROGRAMAÇÃO DE ROBÔS 10

3.1 Os três níveis da programação de robôs ..................................... 10

3.1.1 Ensinar mostrando .............................................................. 10

3.1.2 Linguagens de programação explícitas ............................... 11

3.1.3 Linguagem de programação em nível de tarefa .................. 12

4. REQUISITOS DE UMA LINGUAGEM DE PROGRAMAÇÃO DE

ROBÔS 13

4.1 Modelagem do mundo ................................................................. 13

4.2 Especificação de movimento ....................................................... 14

4.3 Fluxo de execução ....................................................................... 15

4.4 Ambiente de programação ........................................................... 16

4.5 Integração de sensores ................................................................ 16

5. PROGRAMAÇÃO PECULIARES ÀS LINGUAGENS DE

PROGRAMAÇÃO DE ROBÔS ......................................................................... 17

5.1 Modelo de mundo interno versus realidade externa .................... 17

5.2 Sensibilidade ao contexto ............................................................ 19

5.3 Recuperação de erro ................................................................... 20

6. SISTEMAS DE PROGRAMAÇÃO OFF-LINE ............................... 21

6.1 Principais aspectos dos sistemas OLP ........................................ 24

6.1.1 Interface do usuário ............................................................... 24

6.1.2 Modelagem 3D ...................................................................... 26

3
 6.1.3 Emulação cinemática ............................................................ 27

6.1.4 Emulação de planejamento de trajetória ............................... 28

6.1.5 Emulação dinâmica ............................................................... 28

6.1.6 Simulação multiprocesso ....................................................... 29

6.1.7 Simulação de sensores ......................................................... 29

6.1.8 Tradução de linguagem para o sistema alvo ......................... 30

6.1.9 Calibração de célula de trabalho ........................................... 31

7. REFERÊNCIAS: ........................................................................... 32

4
 1. O ARDUINO

O Arduino que é um processador de código aberto baseado em hardware

e software, de fácil manuseio. Ele tem várias entradas, que podem ser
analógicas ou digitais, o que nos permite uma grande versatilidade, pois
podemos utilizar, como sensores de entrada, sensores ópticos, botões,
mensagens digitais por bluetooth, entre outros.
Atualmente, a sua utilização está em franca expansão em instituições de
ensino, com vistas a construir instrumentos cientificos de baixo custo, para
iniciação à robótica e até mesmo para experimentos de Fisica.
O Arduino foi desenvolvido pela empresa Ivrea Interaction Design
Institute, como uma ferramenta fácil e prática para a prototipagem, pois não
requer conhecimentos sofisticados de eletrônica e/ou programação. Seu custo
beneficio é bastante interessante. Mais adiante, iremos detalhar o custo para a
montagem do experimento de pêndulo simples utilizando o Arduino.
Os fabricantes do Arduino disponibilizam em sua página guias tutoriais
para auxiliar os usuários, mesmo os mais leigos em programação, para
popularizar a sua aplicação em diversos tipos de projetos, inclusive
educacionais.
Ele foi desenvolvido para o ensino de estudantes, e em 2005 lançado
comercialmente, por Massimo Banzi e David Cuartielles. Os projetos de Arduino
estão disponíveis gratuitamente sob licença da Creative Commons. Por serem
abertos, há muitas fabricantes alternativas que fabricam seu próprio Arduino
para comercializar.
Constitui-se de uma pequena placa, com um microcontrolador e um
conector USB, que facilita a conexão a um computador. A placa tem terminais
de saída e entrada, tanto analógicos como digitais, que permitem a conexão de
periférico como motores, relés, autofalantes etc. Sua alimentação se dá pela
conexão USB com o computador, ou por meio de uma fonte externa que pode
variar entre 7V e 12V. Essa porta USB também serve para que possamos
transferir os programas de um computador para o Arduino ou receber
informações do Arduino.

5
 O microcontrolador que o compõe é um pequeno computador em um
único chip, que contém um núcleo de processador, memória e periféricos
programáveis de entrada e saída. Possui memória RAM, flash ou /eprom. Essas
memórias em geral estão na casa de quilo bytes, muito menos que qualquer
computador ou smartphone atual, mas devemos lembrar que o Arduino é para
pequenos projetos, de modo que tais valores de memória são suficientes.

1.1 Componentes de uma placa Arduino

Basicamente, a placa é composta pelos seguintes componentes:

► Jack de Corrente Contínua para alimentação: o valor de alimentação

deverá ser entre 2,5V e 12V, dependendo do tipo de Arduino utilizado, e é
regulada internamente para 5V. Um LED indicador acenderá sempre que o
Arduino estiver ligado.
▶ Porta USB: permite conexão com computadores para a inserção de
▶ programas ou ainda a utilização como saída de dados
Botão de reset: utilizado para reiniciar um programa e limpar a memória.
▶ Conector serial de programação (ICSP): permite que o dispositivo seja
gravado no próprio circuito.
▶Entradas analógicas com tensão de saida em até 5V.
Entradas digitais.
▶ Entrada/saida serial (TX/RX).
▶Microcontrolador: o microcontrolador utilizado é o da Atmel AVR de 8
bits. Na sequência, vamos mostrar a familia do Arduino, inclusive com a
capacidade de cada microcontrolador utilizado.

6
 1.2 Família Arduino

O Arduino tem várias versões de placas que podem ser escolhidas de

acordo com a necessidade de processamento e memória requeridas pelo projeto
a ser executado.
A seguir a imagem do harware do modelo UNO.

Imagem:

No quadro a seguir mostramos alguns dos modelos de Arduino

comercializáveis.

Tabela 1- Alguns modelos de Arduino comercializáveis

Itens Uno mega nano BT mini Pro Lilypad
Micro
E/S 28 54 22 14 14 20 14

Memória Flash 32 128 32 32 3 32 16

(KB)

7
 RAM (KB) 2 8 2 2 2 2.5 1

EEPROM (KB) 1 4 1 1 1 1 512B

CLOCK (MHz) 16 16 16 16 16 16 8

Corrente 20 40 40 40 40 20 40

Tensão Entrada 7-12 7-12 5 5 5 7.12 2.7-5.5

(V)

Tensão Máxima 6-20 6-20 7.12 2.5- 7-9 6-20 2.7-5.5

(V) 12

Entradas/ 6 16 8 6 8 12 6
saídas
analógicas

Entradas/saídas 6 15 6 6 6 7 6
digitais

2. SENSORES

Para compor os projetos do Arduino, podemos utilizar vários tipos de

sensores, que podem ser conectados em suas portas de entrada ou salda. A
seguir veremos alguns tipos de sensores inclusive o que será utilizado no
protótipo do pêndulo [Link] sensores de entrada podemos ter o sensor
Infravermelho, que consiste em um LED emissor e outro receptor de
infravermelho, ou ainda apenas um emissor que serve para a detecção de
obstáculos ou padrões de cores. Ele é utilizado no projeto e servirá para detectar
a passagem do pêndulo e enviar o sinal para o microcontrolador, que calculará
o tempo de oscilação. O modelo é o Sensor Reflexivo Infravermelho de Distância
Ajustável E18-D80NK. Esse sensor tem emissor e fotorreceptor no mesmo
componente, funcionando por reflexão da luz no objeto em questão. O objeto
deve estar situado na faixa entre 3cm e 80cm, e fornece uma saída digital a cada
detecção. A conexão para alimentação do sensor é a seguinte:
▶Marrom: +5Vcc

8
 .▶Azul: GND
▶ Preto: Saída

Importante ressaltar que o tempo de resposta é menor de 2ms. Este é um

dado importante para levar em conta nas medições de tempo de oscilação.
▶ Sensor LDR: resistor variável à luz, utilizado onde variações de luz
devam ser monitoradas. Seu sinal é analógico.
▶ Sensor ultrassom: emissor e receptor de utrassom juntos. Pode ser
utilizado como sensor de presença mediação de distância, radar de ultrasson.
► Sensor de tempearatura/ umidade: detecta a temperatura na
proximidade do sensor, sendo que alguns sensores também detectam a
umidade do ar.
► Sensor de gás: detecta o gás liquefeito de petróleo (GLP). Pode
detectar concentrações bem pequenas (200 ppm até 10000 ppm). Utilizado em
sistemas de monitoramento e proteção.
► Sensor de contato: sistema de contato simples que indica condução ou
corte de tensão elétrica. Utilizado para limitar movimentos ou áreas de trabalho
de um dispositivo.

Como sensores de saídas podemos ter os seguintes:

LEDS: são dispositivo emissores de luz que podem ser encontrados

individualmente ou em conjunto.

► Relés: utilizado para acionamento de circuitos elétricos que necessitam

de uma maior corrente para seu funcionamento. Podem acionar painéis elétricos,
sistemas de iluminação e motores, por exemplo.

► Motor DC: utilizado para movimentação de carros, robôs ou

acionamento de hélices. Importante ressaltar que não há controle do movimento
do motor.

► Motor de passo: são motores com grau de controle sobre o giro, que
são medidos em passos. O programa pode acionar o motor nas duas direções

9
Autolalante: emitem sinais sonoros fixos, por exemplo, para serem utilizados
como avisos. Normalmente é utilizado junto com um amplificador.

►Display LCD: permite a visualização dos dados de saída do Arduino.

►Display 8 segmentos: display que contém LEDs na forma de segmentos

para escrita dos dígitos, podendo ser encontrado na forma simples ou composto
em mais dígios.

3. LINGUAGENS E SISTEMAS DE PROGRAMAÇÃO

DE ROBÔS

3.1 Os três níveis da programação de robôs

Muitos estilos de interface de usuário já foram desenvolvidos para a

programação de robôs. Antes da rápida proiferação dos microcomputadores na
indústria, os controladores robóticos pareciam sequências simples usadas em
geral para o controle de automação fixa. As abordagens modernas concentram-
se na programação de computadores e as questões da programação de robôs
incluem todas aquelas encontradas na programação de computadores em geral.

3.1.1 Ensinar mostrando

Os primeiros robôs eram todos programados através de um método que

chamaremos de ensinar mostrando, que implica movimentar o robô até um ponto
desejado e gravar sua posição em uma memória que um sequeciadornleria
durante a reprodução. Na fase de ensinar, o usuário levaria o robô à mão ou pela
interação com uma caixa de controle (conhecida como teach pendant). Teach
pendant são botoeiras portáteis que permitem o controle de cada junta do
manipulador ou de cada grau cartesiano de liberdade. Alguns desses
controladores permitem testes e ramificações, de forma que aceitam programas

10
simples envolvendo lógica. Algumas teach pendant têm visores alfanumércos e,
em termos de complexidade, aproximam-se dos terminais portáteis.

3.1.2 Linguagens de programação explícitas

Deste o advento de computadores potentes e baratos, a tendência vem

sendo, cada vez mais, no sentido de programar robôs por meio de programas
escritos em linguagem de programação de computadores. Em geral, essas
linguagens têm características especiais que se aplicam aos problemas de
programar manipuladores e são, portanto, chamadas de linguagens de
programação de robôs, ou RPLs ( do inglês, robot programming languages). A
maioria dos sitemas que vêm equipados com uma linguagem de programção de
robôs manteve, mesmo assim, uma interface no estilo teach pendant.
As linguagens de programação de robôs assumiram várias formas.
Vamos dividí-las em três categorias?

1. Linguagens de manipulação especializadas. Foram construídas

mediante o desenvolvimento de uma linguagem totalmente nova que, embora
voltada para áreas robóticas em especial, podem muito bem ser consideradas
linguagens genéricas de programação de computador. Um exemplo foi a
linguagem VAL criada para controlar os robôs industriais da Unimation, Inc. A
VAL foi desenvolvida especialmente como linguagem de controle de
manipuladores; como linguagem genérica de computação ela era bastante fraca.
Por exemplo, não suportava números reais ou cadeias de caracteres e as sub-
rotinas não conseguiam passar argumentos. Uma versão mais recente, a V-II,
fornecia esses recursos. A versão atual dessa linguagem, a V+, inclui muitos
recursos novos. Outro exemplo de uma linguagem de manipulação
especializada é a AL, desenvolvida na Universidade de Stanford. Embora a
linguagem AL seja hoje uma relíquia do passado, ela mesmo assim fornece bons
exemplos de alguns recursos que ainda não são encontrados nas linguagens
mais modernas (controle de força, paralelismo). Além disso, como foi
desenvolvida em um ambiente académico, há referências disponíveis para
descrevê-la. Por tais motivos, continuamos fazendo referência a ela.

11
 2. Biblioteca de robótica para uma linguagem de programação
existente.
Essas linguagens de programação de robôs foram desenvolvidas com
base em uma linguagem de programação já popularizada (por exemplo, Pascal)
e acrescentando-se uma biblioteca de sub-rotinas específica para robótica. O
usuário, então, escreve um programa em Pascal chamando, com frequência, o
pacote de sub-rotinas especifico para necessidades robóticas. Um exemplo é a
AR-BASIC da American Cimflex, que é em essência uma biblioteca de sub-rotina
para uma implementação em BASIC. Desenvolvida pelo Laboratório de
Propulsão a Jato da NASA. a JARS é um exemplo de linguagem de programação
robótica baseada em Pascal.

3. Biblioteca de robótica para uma nova linguagem de uso geral.

Essas linguagens de programação de robôs foram desenvolvidas primeiro
criando-se uma nova linguagem de uso geral como base de programação e, em
seguida, acrescentando-se uma biblioteca de sub-rotinas predeterminadas,
específicas para robôs. Exemplos são a RAPID, desenvolvida pela ABB Robotics
[6]: a AML, desenvolvida pela IBM; e a KAREL. desenvolvida pela GMF Robotics.

3.1.3 Linguagem de programação em nível de tarefa

O terceiro nível da metodologia de programação de robôs está

incorporado nas linguagens de programação em nível de tarefa. Essas
linguagens permitem que o usuário comande as submetas da tarefa diretamente
em vez de especificar os detalhes de todas as ações que o robo deverá realizar.
Em um sistema desse tipo, o usuário é capaz de incluir instruções no programa
da aplicação, em um nivel significativamente mais alto do que em uma linguagem
explícita de programação de robôs. Por exemplo, se a instrução para "pegar o
parafuso" for dada, o sistema deve planejar uma trajetória para o manipulador
que evite colisões com os obstáculos circundantes, deve automaticamente
escolher um bom local no próprio parafuso para que seja pego e deve pegá-lo.
Em contrapartida, em uma linguagem explícita de programação de robós, todas
essas escolhas devem ser feitas pelo programador.

12
 A fronteira entre as linguagens de programação explícitas e as linguagens
em nível de tarefa é bastante definida. Avanços incrementais vêm sendo feitos
nas linguagens explícitas de programação de robôs para ajudar a facilitar a
programação, mas esses aperfeiçoamentos não podem ser considerados
componentes de um sistema de programação em nível de tarefa.

4. REQUISITOS DE UMA LINGUAGEM DE

PROGRAMAÇÃO DE ROBÔS

4.1 Modelagem do mundo

Os programas de manipulação devem, por definição, incluir objetos que

se movimentam no espaço tridimensional e, portanto, é claro que qualquer
linguagem de programção de robôs precisa de um meio para descrever essas
ações. O elemento mais comum das linguagens de programação robóticas
é a existência de tipos geométricos especiais. Por exemplo, tipos são
introduzidos para representar conjuntos de ângulos de juntas, posições
cartesianas, orientações e sistemas de referência. Operadores predefinidos que
podem manipular esses tipos estão frequentemente disponíveis.
Dado um ambiente de programação que suporta tipos geométricos, o robô
e outras máquinas, peças e instalações podem ser modelados definindo-se
variáveis identificadas associadas a cada objeto de interesse.
Em muitas linguagens de programação robóticas, a habilidade de definir
variáveis identificadas de vários tipos geométricos e fazer referència a elas no
programa constitui a base do modelo de mundo. Observe que as formas fisicas
dos objetos não fazem parte desse modelo de mundo e nem as superficies,
volumes, massas ou outras propriedades. Até onde os objetos do mundo são
modelados é uma das decisões de projeto básicas na elaboração de um sistema
de programação robótica. A maioria dos sistemas atuais suporta apenas o estilo
que acabamos de descrever.

13
 Alguns sistemas de modelagem do mundo permitem a noção de afixação
entre objetos identificados. Ou seja, o sistema pode ser informado de que dois
ou mais objetos se tornaram "afixados" dali por diante, se um objeto é
explicitamente movido com uma expressão da linguagem, qualquer objeto
afixado a ele será movido junto. Assim, na nossa aplicação, uma vez inserido o
pino no furo do suporte, o sistema seria informado (por uma expressão da
linguagem) de que esses dois objetos tornaram-se afixados. Os movimentos
subsequentes do suporte (ou seja, mudanças de valor da variável do sistema de
referência "suporte") fariam o valor armazenado para a variivel "pino ser também
atualizado.

4.2 Especificação de movimento

Uma função muito básica de uma linguagem de programação robótica é

permitir a descrição dos movimentos desejados do robo. As expressões de
movimento permitem ao usuário especificar pontos de passagem, o ponto meta
e a escolha entre usar o movimento por interpolação de juntas ou o cartesiano
em linha reta. Além disso, o usuário pode ter o controle sobre a velocidade ou
duração de um movimento.
Para ilustrar várias sintaxes das primitivas de movimento, vamos
considerar o seguinte exem plo de movimentos do manipulador:
(1) mover-se para posição "goal1", em seguida (2) mover-se em linha reta
para posição "goal2", depois (3) mover-se sem parar por "via 1" e chegar ao
repouso em "goal3". Presumindo que todos esses pontos de trajetória já foram
ensinados ou descritos tex tualmente, esse segmento de programa seria escrito
como se segue.

Em VAL II.
● move goall moves goal2
● move via 1
● move goal3

14
 Em AL (aqui controlando o manipulador chamado "garm"),

● move garm to goal 1;

● nove garm to goal 2 linearly:
● move garm to goals via via 1

A maioria das linguagens tem uma sintaxe semelhante para expressões

de movimento simples como essas. As diferenças entre as primitivas de uma
linguagem de programação robótica c de outra se tomam mais evidentes se
considerarmos recursos como os seguintes:

1. a habilidade de fazer cálculos matemáticos em tipos estruturados como

sistemas de refência, vetores e matrizes rotacionais.

2. a habilidade de descrever entidades geométricas como sistemas de

referència tações convenientes variadas-junto com a capacidade de comersão
entre representações;

3. a habilidade de prover restrições à duração ou à velocidade de um

determinado movimento – por exemplo, muitos sistemas permitem ao usuário
especificar diretamente uma duração ou uma velocidade máxima de junta
desejada.

4. a habilidade de especificar metas relativas a vários sistemas de

referência, inclusive os definidos pelo usuário e sistemas de referência em
movimento ( em uma esteira transportadora, por exemplo).

4.3 Fluxo de execução

Como nas linguagens de programação de computador mais

convencionais, um sistema de programação robótica permite ao usuário
especificar o fluxo de execução - ou seja, conceitos tais como teste e

15
ramificação, laços, chamadas de subrotinas e mesmo interrupções são
encontradas nas linguagens de programação robóticas.
Mais do que em muitas aplicações para computadores, o processamento
paralelo é importante nas aplicações de células de trabalho automatizadas.
Antes de tudo, muitas vezes dois ou mais robôs são usados numa única célula
e trabalham em simultânco para diminuir o tempo de ciclo do processo.
Outra ocorrência frequente é a necessidade de monitorar vários
processos com algum tipo de sensor. Depois, seja interrompendo ou através de
polling, o sistema robótico deve ser capaz de responder a certos eventos
detectados pelos sensores. A capacidade de especificar com facilidade tais
monitores de eventos é proporcionada por algumas linguagens de programação
robóticas.

4.4 Ambiente de programação

Como acontece com qualquer linguagem de computação, um bom

ambiente de programação promove a produtividade do programador. A
programação de manipuladores é difícil tende a ser bastante interativa com
muitas tentativas e erros. Se o usuário fosse forçado a repetir continuamente o
ciclo de "editar-compilar-executar" das linguagens compiladas, a produtividade
seria baixa. Portanto, a maioria das linguagens de programação é hoje
interpretada, de forma que expressões individuais de linguagem podem ser
executadas isoladamente durante o desenvolvimento do programa e a
depuração.

4.5 Integração de sensores

Uma parte de extrema importância da programação de robôs está

relacionada à interação com os sensores. O sistema deve ter, no mínimo, meios
de questionar os sensores táteis e de força e de usar as respostas em construtos
do tipo if-then-else. A capacidade de especificar monitores de eventos para
observar transições nesses sensores em segundo plano também é muito útil.

16
 A integração com um sistema de visão permite que este envie ao sistema
manipulador as coordenadas de um objeto de interesse. Por exemplo, em nosso
modelo de aplicação, um sistema de visão localiza os suportes na esteira
transportadora e envia ao controlador do manipulador sua posição e orientação
em relação à camera. O sistema de referência da câmera é conhecido em
relação ao da estação de trabalho de forma que um sistema de referência da
meta desejado pode ser computado para o manipulador a partir dessa
informação.
Certos sensores podem fazer parte de outros equipamentos da célula de
trabalho - por exemplo, alguns controladores robóticos podem usar entradas
vindas de um sensor fixado à esteira transportadora para que o manipulador
acompanhe o movimento da esteira e retire dela os objetos à medida que ela se
movimenta.
Em sistemas que suportam o controle de força ativo, a descrição da
aplicação da força de sejada pode se tornar parte da especificação de
movimento. A linguagem AL descreve o controle de força ativo nas primitivas de
movimento especificando seis componentes de rigidez (três translacionais e três
rotacionais) e um viés de força. Dessa maneira, a rigidez aparente do
manipulador programável. Para aplicar uma força, geralmente a rigidez é
ajustada em zero naquela direção e um viés de força é especificado.

5. PROGRAMAÇÃO PECULIARES ÀS
LINGUAGENS DE PROGRAMAÇÃO DE ROBÔS

Os avanços feitos nos últimos anos têm ajudado, mas a programação de

robôs continua sendo dificil. Ela compartilha de todos os problemas da
programação convencional de computadores, somados a algumas dificuldades
causadas pelos efeitos do mundo físico.

5.1 Modelo de mundo interno versus realidade externa

17
 Uma característica central dos sistemas de programação de robôs é o
modelo de mundo mantido internamente no computador. Mesmo quando esse
modelo é bastante simples, há amplas dificuldades para garantir que ele
corresponda à realidade física que está tentando modelar. Discrepâncias entre
o modelo interno e a realidade externa resultam em falha ou ineficiência para
pegar objetos, colisões e uma série de outros problemas sutis.
Essa correspondência entre o modelo interno e o mundo externo deve ser
estabelecida para o estado inicial do programa e mantida no decorrer da sua
execução. Durante a programação inicial ou depuração, cabe geralmente ao
usuário o ônus de garantir que o estado representado no programa corresponde
ao estado fisico da célula de trabalho. Ao contrário da programação mais
convencional, onde apenas as variáveis internas precisam ser salvas e
restauradas para restabelecer uma situação anterior, na programação robótica
os objetos fisicos devem, geralmente, ser reposicionados.
Além da incerteza inerente quanto à posição de cada objeto, o
manipulador em si é limitado a certo grau de acurácia. É comum que os passos
de uma montagem requeiram que o manipulador faça movimentos que exigem
uma precisão além da sua capacidade. Para complicar ainda mais a questão, a
precisão do manipulador varia no espaço de trabalho.
Ao lidar com objetos cuja localização não é conhecida com exatidão, é
essencial de alguma forma refinar a informação de posição. Isso às vezes pode
ser feito com sensores (por exemplo, de visão ou tátil) ou através de estratégias
apropriadas de força para movimentos restritos.
Durante a depuração dos programas de manipuladores, é muito útil poder
modificar o programa para depois voltar e tentar um procedimento novamente.
Essa volta implica restaurar o manipulador e os objetos que estão sendo
manipulados a um estado anterior. No entanto, ao trabalhar com objetos físicos,
nem sempre é fácil, ou sequer possível, desfazer uma ação. Alguns exemplos
são as operações de pintura, rebite, perfuração e solda que provocam a
modificação física dos objetos que estão sendo manipulados. Pode, portanto,
ser necessário que o usuário obtenha uma nova cópia do objeto para substituir
a antiga que foi modificada. Além disso, é provável que algumas das operações,
imediatamente anteriores à que está sendo refeita, tenham também que ser

18
repetida para estabelecer o estado adequado necessário a fim de que a
operação desejada seja refeita com sucesso.

5.2 Sensibilidade ao contexto

A programação bottom-up ( de baixo para cima) é uma abordagem padrão

para a elaboração de um programa de computador extenso, na qual são
desenvolvidas partes menores, de nível mais baixo para, por fim, formar com
elas um programa completo. Para o método funcionar, é essencial que as partes
menores sejam relativamente insensíveis às expressões de linguagem que as
precedem e que não haja pressupostos relativos ao contexto no qual essas
partes do programa o executam. Para a programação de manipuladores, esse
frequentemente não é o caso; um código que funciona de forma confiável
quando é testado isoladamente costuma falhar quando é colocado no contexto
do programa mais amplo. Esses problemas surgem em geral das dependências
de configuração do manipulador e da velocidade dos movimentos.
Programas de manipuladores podem ser altamente sensíveis às
condições iniciais – por exemplo, a posição inicial do manipulador. Nas
trajetórias de movimento, a posição inicial influenciará a trajetória que será usada
para o movimento. A posição inicial do manipulador pode, também, influenciar a
velocidade com a qual o braço se moverá durante alguma parte crítica do
movimento. Tais efeitos podem, às vezes, ser tratados com o cuidado adequado
em termos de programação, mas frequentemente esses problemas não surgem
até depois que as expressões iniciais da linguagem tenham sido depuradas em
separado para serem depois unidas às expressões precedentes.
Por causa da acurácia insuficiente do manipulador, um segmento de
programa escrito para realizar uma operação em um determinado local
provavelmente precisará ser ajustado ( ou seja, reensinado ou coisa semelhante)
para que funcione em um local diferente. Mudanças de local dentro da célula de
trabalho resultam em mudanças na configuração do manipulador para chegar
aos locais metas. Tais tentativas de recolocação dos movimentos do
manipulador dentro da célula de trabalho testam a precisão da cinemática do

19
manipulador e do sistema servo e, com frequência, surgem problemas. Uma
recolocação desse tipo pode provocar uma mudança na configuração cinemática
do manipulador- por exemplo, do ombro esquerdo para o ombro direito, ou de
acima do cotovelo para abaixo do cotovelo. Além disso, essas mudanças de
configuração podem causar grandes movimentos do braço durante o que, antes,
seria um movimento curto e simples.
A configuração do manipulador também afeta a delicadeza e a acurácia
das forças que podem ser aplicadas com ele. Essa é uma função de quão bem
condicionado o Jacobiano do manipulador está em uma determinada
configuração, algo difícil de avaliar durante o desenvolvimento dos programas
robóticos.

5.3 Recuperação de erro

Outra consequência direta de trabalhar com o mundo físico é a de que os

objetos talvez não estejam exatamente onde deveriam e, portanto, os
movimentos que lidam com eles podem falhar. Parte da programação do
manipulador implica tentar considerar isso e tornar as operações de montagem
o mais robustas possível, mas, mesmo assim, é provavel que os errros ocorram
e uma parte importnate da programação do manipulador é como se recuperar
desses erros.
Praticamente qualquer expressão de movimento no programa do usuário
pode falhar, às vezes por uma série de razões. Algumas das causas mais
comuns são objetos que saem do lugat ou caem da mão, um objeto que não está
onde deveria, obstrução durante uma inserção e não conseguir localizar um
orifício.
O primeiro problema que surge para a recuperação de erro é a
identificação de que um erro, de fato, aconteceu. Como os robôs normalmente
têm recursos de detecção e raciocínio bastante limitados, a detecção de erro
frequetemente é dificil. A fim de detectar um erro, um programa robótico deve
conter algum tipo de teste explícito. O teste pode envolver a verificação da
posição da posição do manipulador para ver se ele tem o alcance apropriado;
por exemplo, ao fazer uma inserção, a falta de mudança de posição pode indicar

20
uma obstrução ou, se há mudança demais, isso pode significar que o orifício foi
completamente perdido ou que o objeto caiu da mão. Se o sistema manipulador
tem algum tipo de recurso visual, poderá fotografar e verificar se o objeto
continua lá e não caiu.
Toda expressão de movimento do programa é sujeita a falhar, de forma
que as verificações explícitas podem ser bastante trabalhosas e ocupar mais
espaços do que o resto do programa. Tentar lidar com todos os erros possíveis
é extremamente difícil; em geral, só as poucas expressões mais prováveis de
falhar daõ verificadas. O processo de prever certo grau de interação e de testes
parciais com o robô durante o estágio de desenvolvimento do programa.
Uma vez que um erro foi detectado, pode ser feita uma tentativa de
recuperação. Isso pode ser feito totalmente pelo manipulador sob controle do
programa, pode implicar a intervenção manual do usuário ou em uma
combinação das duas coisas. De qualquer forma, a tentativa de recuperação
pode, por sua vez, resultar em novos erros. É fácil ver como o código de
recuperação de erros pode ser tornar a maior parte do programa do manipulador.
O uso de paralelismo nos programas de manipuladores pode complicar ainda
mais a recuperação de erros. Quando vários processos estão sendo executados
ao mesmo tempo, e um deles provoca um erro, ele pode frequentemente afetar
outros processos. Em muitos casos, será possível voltar o processo prejudicial
permitido que os demais continuem. Em outras ocasiões, será necessário
restaurar vários ou todos os processos em execução.

6. SISTEMAS DE PROGRAMAÇÃO OFF-LINE

Definimos um sistema de programação off-line (OLP) como uma

linguagem de programação robótica que foi suficiente estendida, geralmente por
meio de computação gráfica, de forma que o desenvolvimento de programas de
robótica pode ser feito sem acessar robô em sí. “Sistemas de programação off-
line são importantes tanto como auxílio na programação dos equipamentos de
automação industrial quanto como plataformas para a pesquisa em robótica.
Muitos aspectos têm de ser considerados no projeto desses sistemas.

21
 Nos últimos 20 anos, o crescimento do mercado de robôs indústriais não
foi tão rápido quanto se previa. Um dos principais motivos é que robôs são muito
difíceis de usar. Muito tempo e conhecimentos são necessários para instalar um
robô em uma determinada aplicação e levar o sistema ao nível onde está pronto
para a produçã[Link] várias razões, esse problema é mais grave em algumas
aplicações do que em outras, assim, vemos certas áeas de aplicação (por
xemplo, solda ponto e pintura em spray) sendo automatizadas com robôs muito
antes que outros domínios de aplicação (por exemplo, montagem). Ao que
parece, a falta de instaladores de sistemas robóticos bem treinados vem
limitando o crescimento em algumas, se não em todas as áreas de aplicação.
Em algumas empresas de fabricação, a administração estímula o uso de robôs
em um grau maior do que o factível pelos engenheiros de aplicações. Além disso,
uma grande porcentagem dos robôs instalados está sendo usada de maneiras
que não tiram proveito total dos recursos. Esses sintomas indicam que os atuais
robôs industriais não são fáceis o suficiente de usar para permitir uma instalação
bem-sucedida e uma programação adequada.
Há muitos fatores que tornam a programação de robôs uma tarefa difícil.
Primeiro, ela está intrinsecamente relacionada à programação de computadores
em geral e, portanto, compartilha de muitos dos problemas encontrados nesse
campo; mas a programação de robôs, ou de qualquer máquina programável, tem
problemas particulares que tornam o desenvolvimento de software pronto para
a produção ainda mais difícil.
Embora esteja difícil para manter um modelo interno acurado do ambiente
do manipulador, parece não haver dúida de que isso gera grandes benefícios.
Áreas inteiras de pesquisas em sensores – das quais a mais notável talvez seja
a visão computacional- concentram-se no desenvolvimento de técnicas pelas
quais modelos do mundo podem ser verificados, corrigidos ou descobertos.
Claro, a fim de aplicar qualquer algoritmo computacional ao problema de geração
de comandos, o algoritmo precisa acessar um modelo do robô e do que está à
volta dele.
No desenvolvimento de sistemas de programação para robôs, o avanço
dos recursos das técnicas de programação parece diretamente ligado à
sofisticação do modelo interno referenciado pela linguagem de programação.
Nos primeiros sistemas robóticos de “ensinar mostrando” o espaço de juntas

22
usavam um modelo de mundo limitado e havia modos muito limitados nos quais
o sistema podia auxiliar o programador a realizar a tarefa. Controladores
robóticos um pouco mais sofisticados incluíam modelos cinemáticos, assim o
sistema podia, pelo menos, auxiliar o usuário na movimentação das juntas de
forma a realizar movimentos cartesianos. As linguagens de programação de
robôs (RPLs) evoluíram para dar suporte a muitos tipos diferentes de dados e
operações, os quais o programador pode usar conforme necessário para
modelar atributos do ambiente e computar ações para o robô. Algumas RPLs
suportam primitivas de modelagem do mundo como afixações, tipos de dados
para forças e momentos, além de outros recursos.
As linguagens de programação de robôs de hoje podem ser chamadas de
“linguagem explícitas de programação”, visto que toda ação feita pelo sistema
tem de ser programada pelo engenheiro da aplicação. Na outra extremidade do
espectro, estão os chamados sistemas de programação em nível de tarefa
(TLP), nos quais o programador pode expressar metas de alto nível como “inserir
parafuso” ou talvez, até, “montar uma torradeira”. Esses sistemas usam técnicas
oriundas das pesquisas em inteligência artificial para gerar automaticamente
movimentos e planos de estratégias. No entanto, linguagens em nível de tarefa
tão sofisticadas ainda não existem; vários trechos desses sistemas estão sendo
desenvolvidos por pesquisadores. Os sistemas de programação em nível de
tarefa requerem um modelo muito completo do robô e do seu ambiente para
desenvolver operações de planejamento automatizadas.
A programação off-line de robôs tem outros benefícios potenciais e que
estão apenas começando a ser avaliados pelos usuários de robôs industriais.
Os sistesmas de programação off-line devem servir como caminho natural de
crescimento desde sistemas de programação explícita até os de programação
em nível de tarefa. O sistema OLP mais simples é apenas uma extensão gráfica
da línguagem de programação robótica, mas a partir daí pode ser estendido para
um sistema de programação em nível de tarefa. Essa extensão gradual é
atingida mediante soluções automatizadas para várias subtarefas ( à medida que
tais soluções se tornam disponíveis) que podem ser usadas pelo programador
para explorar opções no ambiente simulado. Até descobrirmos como construir
sistemas em nível de tarefa, o usuário precisa se manter no circuito a fim de
avaliar as subtarefas planejadas automaticamente e orientar o desenvolvimento

23
do programa da aplicação. Adotando esse ponto de vista, um sistema OLP serve
como base importante para a pesquisa e desenvolvimento de sistemas de
planejamento em nível de tarefa e, de fato, para apoiar seu trabalho, muitos
pesquisadores desenvolveram vários componentes de um sistema OLP ( por
exemplo, modelos 3D e exibição gráfica, pós-processadores de linguagem).
Assim, os sistemas OLP devem ser uma ferramenta útil de pesquisa, além de
auxliar nas práticas industrais existentes.

6.1 Principais aspectos dos sistemas OLP

Esse intem aborda muitos dos aspectos a serem considerados nos

projetos de um sistema OLP. O conjunto de tópicos discutidos ajudará a
estabelecer o escopo para a definição de um sistema OLP.

6.1.1 Interface do usuário

Uma grande motivação para o desenvolvimento de um sistema OLP é

criar um ambiente que torna mais fácil a programação de manipuladores, de
forma que a interface é de fundamental importância. Entretanto, outra grande
motivação é eliminar a dependência de uso do equipamento físico durante a
programação. À primeira vista, essas duas metas podem parecer conflitantes –
se os robôs já são difícies de programar qunado se pode vê-los, como isso pode
ser mais fácil sem a presença física do equipamento? Essa questão toca a
essência do problema do projeto do OLP.
Os fabricantes de robôs industriais aprenderam que as RPLs que
fornecem com os robôs não podem ser usadas com sucesso por uma grande
porcentagem dos funcionários das fábricas. Por esses e outros motivos
históricos, muitos robôs industriais são equipados com uma interface em dois
níveis, uma para programadores e outra para não programadores. Os não
programadores utilizam um teach pendant e interagem diretamente com o robô
para desenvolver os programas. Os programadores escrevem códigos na RPL
e interagem com o robô para ensinar pontos de trabalho e depurar o fluxo de

24
programação. Em geral, essas duas abordagens ao desenvolvimento de
programa trocam a facilidade de utilização pela flexibilidade.
Quando visto como extensão de uma RPL, um sistema OLP contém, por
natureza, uma RPL como subconjunto da sua interface do usuário. Essa RPL
deve proporcionar recursos que já foram definidos como importantes nos
sistemas de programação robóticos. Por exemplo, para serem usadas como
RPL, as linguagens interativas são muito mais produtivas do que as linguagens
compiladas-as- quais forçam o usuário a passar pelo ciclo "editar compilar-
executar" a cada modificação no programa.
A parte relativa à linguagem na interface de usuário herda muito das RPLs
"tradicionais"; é a interface de nivel mais baixo (isto é, mais fácil de usar) que
deve ser considerada com cuidado em um sistema OLP. Um componente
fundamental dessa interface é uma visão em computação gráfica do robô que
está sendo programado e do seu ambiente. Utilizando um dispositivo apontador,
como um mouse, o usuário pode indicar a localização de vários objetos na tela
gráfica. O projeto da interface de usuário trata, exatamente, de como o usuário
interage com a tela para especificar um programa robótico. O mesmo dispositivo
apontador pode indicar itens de um "menu" a fim de especificar modos ou invocar
funções variadas.
Uma primitiva fundamental é o que ensina ao robô um ponto de trabalho
ou sistema de referência com seis graus de liberdade através da interação com
as telas gráficas. A disponibilidade de modelos tridimensionais de equipamentos
e peças de trabalho nos sistemas OLP frequentemente torna a tarefa bastante
fácil. A interface fornece ao usuário meios de indicar locais em superfícies,
permitindo à orientação do sistema de referência assumir a perpendicular de
uma superfície localizada e, depois, fornece métodos para deslocamento,
reorientação e assim por diante. Dependendo de aspectos específicos da
aplicação, tais tarefas são facilmente especificadas através da janela gráfica
para o mundo simulado.
Uma interface de usuário bem projetada deve permitir que não
programadores executem muitas aplicações do começo ao fim. Além disso,
sistemas de referência e sequências de movimento "ensinadas" por não
programadores devem ser passíveis de tradução, pelo sistema OLP, em
expressões textuais na RPL. Esses programas simples podem ser mantidos e

25
tornados mais atraentes, em formato RPL, por programadores mais experientes.
Para os programadores, a disponibilidade de uma RPL permite o
desenvolvimento de códigos arbitrários para aplicações mais complexas.

6.1.2 Modelagem 3D

Um elemento fundamental nos sistemas OLP é o uso de modelos gráficos

do robô simulado e sua célula de trabalho. Isso requer que o robô e todos os
equipamentos, peças e ferramentas da célula de trabalho sejam modelados
como objetos tridimensionais. Para acelerar o desenvolvimento do programa, é
proveitoso usar todos os modelos CAD de peças ou ferramentas que estejam
diretamente disponíveis a partir do sistema CAD no qual o projeto original foi
feito. À medida que os sistemas CAD se tornam mais e mais preponderantes na
indústria, aumentam também as chances de que esse tipo de dado geométrico
se torne mais prontamente disponível. Como é altamente desejável esse tipo de
integração CAD do projeto à produção, faz sentido que um sistema OLP
contenha um subsistema CAD de modelagem, ou seja, em si, um parte do
sistema CAD de projeto. Se um sistema OLP estiver isolado, deve ter as
interfaces adequadas para transferir modelos de e para sistemas CAD externos.
No entanto, mesmo um sistema OLP isolado deve ter, pelo menos, um recurso
CAD local simples que permita rapidamente criar modelos de itens não críticos
da célula de trabalho, ou para o acréscimo de dados específicos do robô aos
modelos CAD importados.
Os sistemas OLP requerem múltiplas representações das formas
espaciais. Para muitas operações, uma descrição analítica exata da superfície
ou volume costuma estar presente; no entanto, para aproveitar a tecnologia de
exibição, muitas vezes outra representação é necessária. A tecnologia atual é
bastante adequada aos sistemas nos quais a primitiva de exibição é um polígono
planar; assim, embora a forma de um objeto possa ser bem representada por
uma superfície lisa, a exibição prática (principalmente para animação) requer
uma representação facetada. As ações gráficas da interface do usuário, como
apontar para um ponto em uma superfície, devem agir internamente de forma a
especificar um ponto na verdadeira superfície mesmo que, graficamente, o
usuário veja uma representação do modelo facetado.

26
 Uma utilização importante da geometria tridimensional dos modelos de
objeto é na detecção automática de colisão – ou seja, quando alguma colisão
ocorre entre objetos no ambiente simulado, o sistema OLP deve
automaticamente alertar o usuário e indicar com exatidão onde ela acontece.
Aplicações como montagem podem impliar várias “colições” desejáveis, de
forma que é necessário que o sistema possa ser informado de que colisões
quando objetos passam dentro de uma tolerância especificada para certa
colisão.

6.1.3 Emulação cinemática

Um componente fundamental na manutenção da validade do mundo

simulado é a emulação fiel dos aspectos geométricos de cada manipulador
simulado. Em relação à cinemática inversa, o sistema OLP consegue fazer a
interface com o controlador do robô de duas formas distintas. Primeiro, o sistema
OLP pode substituir a cinemática inversa do controlador do robô e sempre
comunicar suas posições no espaço de juntas do mecanismo. A segunda opção
é comunicar locais cartesianos ao controlador do robô e deixar que o controlador
use a cinemática inversa fornecida pelo fabricante para resolver as
configurações robóticas. A segunda opção é quase sempre preferível,
principalmente na medida em que os fabricantes começam a incorporar aos
robôs o estilo de calibração chamado de arm signature. Tais técnicas de
calibração personalizam a cinemática inversa para cada robô individual. Nesse
caso, torna-se desejável comunicar as informações no nível cartesiano aos
controladores robóticos.
Essas considerações em geral significam que as funções de cinemática
direta e inversa usadas pelo simulador devem refletir as funções nominais
usadas no controlador robótico fornecido pelo fabricante do robô. Existem vários
detalhes da função cinemática inversa especificada pelo fabricante que devem
ser emulados pelo software simulador. Todo algoritmo de cinemática inversa tem
de fazer escolhas arbitrárias a fim de resolver singularidades. Por exemplo,
quando a junta 5 de um robô PUMA 560 está no local zero, os eixos 4 e 6 se
alinham e surge uma condição singular.

27
 A função cinemática inversa do controlador do robô pode solucionar a
soma dos ângulos de junta 4 e 6, mas em seguida terá de usar uma regra
arbitrária para escolher valores individuais para as juntas 4 e 6. O sistema OLP
terá de emular seja qual for o algoritmo usado. A escolha da solução mais
próxima quando existem muitas soluções alternativas proporciona outro
exemplo. O simulador deve usar o mesmo algoritmo que o controlador a fim de
evitar erros potencialmente catastróficos na simulação do manipulador de fato.
Uma característica útil que é ocasionalmente encontrada nos controladores
robóticos é a capacidade de comandar uma meta cartesiana e especificar qual
das possíveis soluções o manipulador deve usar. A existência dessa
característica elimina a necessidade de e que o simulador emule o algoritmo de
escolha de solução; o sistema OLP pode apenas forçar a sua escolha no
controlador.

6.1.4 Emulação de planejamento de trajetória

Além da emulação cinemática para o planejamento estático do

manipulador, um sistema OLP deve emular com precisão a trajetória seguida
pelo manipulador na sua movimentação pelo espaço. Aqui, também, o principal
problema é que o sistema OLP precisa simular os algoritmos do controlador
robótico utilizado e tais algoritmos de planejamento e execução de trajetória
variam consideravelmente de um fabricante de robô para o outro. A simulação
da forma espacial da trajetória adotada é importante para a detecção de colisões
entre o robô e o seu ambiente. A simulação dos aspectos temporais da trajetória
é importante para a previsão dos tempos de ciclo das aplicações. Quando um
robô opera em um ambiente que se modifica (por exemplo, próximo de outro
robô), a simulação exata dos atributos temporais do movimento necessária para
a previsão acurada das colisões e, em alguns casos, para a previsão dos
problemas de comunicação ou sincronização, como um bloqueio total.

6.1.5 Emulação dinâmica

28
 O movimento simulado dos manipuladores pode negligenciar atributos
dinâmicos se o sistema OLP for eficiente na emulação do algoritmo de
planejamento de trajetória do controlador e se o robô de fato seguir as trajetórias
desejadas com erros desprezíveis. No entanto, em alta velocidade ou em
condições de cargas pesadas, os erros de rastreamento de trajetória podem se
tornar importantes. A simulação desses erros de rastreamento necessita da
modelagem da dinâmica do manipulador e dos objetos que ele movimenta, bem
como da emulação do algoritmo de controle usado pelo controlador do
manipulador. Atualmente existem problemas práticos para a obtenção de
informações suficientes dos fornecedores robôs que permitam fazer esse tipo de
simulação dinâmica de valores práticos, mas em alguns casos ela pode ser
buscada com sucesso.

6.1.6 Simulação multiprocesso

Algumas aplicações industriais envolvem um ou mais robôs que

cooperam no mesmo ambiente. Mesmo células de trabalho com um só robó
muitas vezes contém uma esteira transportadora, uma linha de transferência, um
sistema de visão ou algum outro dispositivo ativo com o qual o robo tem de
interagir. Por isso, é importante que um sistema OLP seja capaz de simular
múltiplos dispositivos em movimento, além de outras atividades que implicam
paralelismo. Como base para esse recurso, a linguagem subjacente na qual o
sistema é executado deve ser uma linguagem multiprocessos. Tal ambiente
torna possivel escrever programas independentes de controle robótico para cada
um dos dois ou mais robôs de uma mesma célula e depois simular a ação da
célula com os programas sendo executados simultaneamente. Acrescentar as
primitivas de sinal e espera à linguagem permite que os robôs interajam da forma
que ocorreria na aplicação que está sendo simulada.

6.1.7 Simulação de sensores

Estudos já demonstraram que um grande componente dos programas

robóticos consiste não de expressões de movimento, mas sim de expressões

29
para inicialização, verificação de erro, entrada e saída, e outros tipos. Assim,
torna-se importante a capacidade do sistema OLP de proporcionar um ambiente
que permite a simulação de aplicações completas, inclusive interação com
sensores, várias entradas e saídas e comunicação com outros dispositivos. Um
sistema OLP que suporta a simulação de sensores e multiprocessamento pode
não só verificar os movimentos do robô quanto à sua viabilidade, mas também
verificar a parte de comunicação e sincronização do programa do robô.

6.1.8 Tradução de linguagem para o sistema alvo

Um aborrecimento para os atuais usuários de robôs industriais (e de

outras automações programáveis) é que quase todos os fornecedores desses
produtos inventaram linguagens únicas para a programação dos seus produtos.
Se um sistema OLP tiver a pretensão de ser universal em termos dos
equipamentos com os quais consegue lidar, terá de lidar com o problema de
traduzir de e para várias linguagens diferentes. Uma opção para lidar com esse
problema é escolher uma única linguagem a ser usada pelo sistema OLP e
depois pós-processá-la a fim de convertê-la ao formato necessário para a
máquina alvo. Um recurso para fazer o upload de programas que já existem nas
máquinas alvo e trazê-los para o sistema OLP também é desejável.
Dois possíveis benefícios dos sistemas OLP estão diretamente
relacionados ao tópico de tradução da linguagem. A maior parte dos proponentes
dos sistemas OLP observa que ter uma única interface universal que permita aos
usuários programar uma variedade de robôs resolve o problema de ter de
aprender e lidar com várias linguagens de automação. Um segundo benefício
resulta das considerações econômicas em cenários futuros nos quais centenas
ou talvez milhares de robôs encherão as fábricas. O custo associado a um
ambiente de programação eficiente (por exemplo, uma linguagem e interface
gráfica) talvez impeça a sua colocação no local de cada instalação robótica. Em
vez disso, parece fazer mais sentido em termos económicos colocar apenas um
controlador "burro" e barato em cada robô para que ele receba o download de
um sistema OLP inteligente e potente localizado em um ambiente de escritório.
Assim, o problema geral de traduzir um programa de aplicação de uma

30
linguagem universal eficiente para uma linguagem simples feita para ser
executada em um processador barato se torna uma questão importante nos
sistemas OLP.

6.1.9 Calibração de célula de trabalho

Uma realidade inevitável de um modelo de computador de qualquer

situação prática é a falta de precisão do modelo. A fim de tornar utilizáveis os
modelos desenvolvidos em um sistema OLP, métodos de calibração da célula
de trabalho devem ser parte integrante do sistema. A magnitude do problema
varia muito com a aplicação; essa variabilidade torna a programação off-line de
algumas tarefas muito mais factíveis do que de outras.
Muitas aplicações envolvem a realização frequente de ações relativas a
um objeto rígido. Considere, por exemplo, a tarefa de perfurar várias centenas
de orifícios em um anteparo. A localização do anteparo em relação ao robô pode
ser ensinada usando-se o próprio robô e tomando-se três medidas. Com base
nesses dados, os locais de todos os orifícios podem ser atualizados auto-
maticamente se estiverem disponíveis como coordenadas das peças a partir de
um sistema CAD. Nessa situação, somente esses três pontos - e não centenas
- têm de ser ensinados ao robô. A maioria das tarefas envolve esse tipo de
paradigma de "muitas operações em relação a um objeto rígido"; por exemplo, a
inserção de componentes nas placas-mãe de computadores, roteiro, solda
ponto, solda em arco, paletização, pintura e rebarbagem.

31
 7. REFERÊNCIAS:

ARANTES, J. T. Bacon e Newton: em busca da alma do mundo. São

Paulo: Terceiro Nome, 2005.
BUCHWEITZ, B. O uso de diferentes recursos de ensino na
aprendizagem de Física. Cadernos de Educação, v.6. n.9.p. 99-114, 1997.
CRAIG. J. “Issues in the Design of Off-line Programming Systems,
“International Symposium of robotics Research, R. Bolles e B. Roth (Eds.).
Cambridge, Massachusetts: MIT Press, 1988.
FIGUEIRA, J. S. Easy Java simulations-Modelagem computacional para
o ensino de Física. Revista Brasileira de Ensino de Física, 2005.
GOLDMAN, R. Design of na Interractive Manipulator Programming
Environment, Umi Ann Arbor. Michigan: Research Press, 1985.
PIETROCOLA, M. A matemática como estrutura do conhecimento físico.
Caderno brasileiro de ensino de física, 2002.
PIRES, A. S. T. Evolução das Ideias da Física. São Paulo: Livraria da
Física, 2011.
ROCHA, J. F. Origens e evolução das Ideias da Física. Salvador:
EDUFBA, 2002.
SHIMANO, B. VAL: A versatile Robot Programming and Control system,
“Proceedings of compsac, 1979, chicago.
TAYLOR. R., SUMMERS, P. e MEYER, J. “AML: “Disponível na Adept
Technology ine., Livermore, Califórnia, 2001.

32