IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
Centro de Pesquisas Renato Archer
Programa Institucional de Bolsas de Iniciação Científica do CNPq
– PIBIC/CNPq –
Anais da IX Jornada de Iniciação Científica
do Centro de Pesquisas Renato Archer
ISSN 1678-930X
Outubro de 2007
-1-
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
Centro de Pesquisas Renato Archer
Diretor
Prof. Dr. Jacobus Willibrordus Swart
Coordenador-Geral de Tecnologias da Informação (Coordenador PIBIC)
Dr. Carlos Alberto dos Santos Passos
Coordenador-Geral de Aplicações de Informática
Dr. Silvio Barbin
Comissão Interna de Seleção e Acompanhamento
Dr. Carlos Alberto dos Santos Passos
Dr. Oscar Salviano Silva Filho
Dr. Rosana Beatriz Baptista Haddad
Editores
Dr. Carlos Alberto dos Santos Passos
Dr. Oscar Salviano Silva Filho
Dr. Rosana Beatriz Baptista Haddad
Comunicações e Gabinete
Susete Helena Z. C. Prado
Arte Final
Roberto de Oliveira
Secretária
Maria de Fátima Marrara Zamarion
Vera Lúcia Mariano Alves
Conselho Nacional de Desenvolvimento Científico e
Tecnológico - CNPq
Editado no CenPRA – Outubro de 2007
-2-
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
Programa Institucional de Bolsas de Iniciação Científica do
CNPq - PIBIC/CNPq
ANAIS
05 de Outubro de 2007
-3-
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
Ficha catalográfica
IX Jornada de Iniciação Científica do Centro de Pesquisas Renato
Archer
(10:2007:Campinas, São Paulo)
Artigos da IX Jornada de Iniciação Científica do Centro de
Pesquisas Renato Archer, 05 de outubro de 2007, Campinas, São
Paulo. Editora do CenPRA.
89 p. 30 cm
1. Tecnologia da Informação – Jornada Iniciação Científica.
ISSN 1678 – 930X
-4-
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
PREFÁCIO
A Jornada de Iniciação Científica do Centro de Pesquisas Renato Archer CenPRA é um evento anual, organizado pelo Comitê Institucional de Iniciação
Científica do PIBIC/CNPq, com o intuito de oferecer aos estudantes de
iniciação científica a oportunidade de apresentarem seus trabalhos para a
comunidade científica interna e demais atores da sociedade.
A IX Jornada de Iniciação Científica – JICC´2007, a exemplo das anteriores,
compreende uma sessão de pôsteres e a publicação destes anais contendo o
resultado dos trabalhos de Iniciação Científica realizados no CenPRA pelos
estudantes do programa. Esta jornada é aberta também a outros bolsistas de
programas de Iniciação Cientifica do CenPRA, como os do ITI/PCI, e visa
divulgar e integrar os diversos trabalhos existentes na Instituição.
A realização desta jornada no mês de Outubro se tornou tradição, estando
inserida nas atividades da Semana Nacional de Ciência e Tecnologia,
organizada pelo MCT, cujo objetivo é divulgar para a população brasileira os
trabalhos desenvolvidos pelos seus centros de pesquisas científicos e
tecnológicos.
O Comitê Institucional de Iniciação Científica orgulha-se em apresentar os
resultados dos trabalhos desenvolvidos pelos estudantes e seus orientadores e
deseja que estes auxiliem a ampliar a interação entre a comunidade interna e
externa ao CenPRA.
Agradecemos ao Conselho Nacional de Desenvolvimento Científico e
Tecnológico – CNPq, especialmente à coordenação do PIBIC, pelo apoio aos
pesquisadores e orientadores que, em complemento às suas atividades
regulares, contribuíram para o bom andamento do programa. Agradecemos
também aos consultores do CNPq que, com sua experiência e dedicação,
colaboraram para o perfeito alinhamento das atividades do programa com os
objetivos traçados pela coordenação geral do PIBIC/CNPq.
Campinas, 05 de outubro de 2007.
Comitê Institucional de Iniciação Científica do PIBIC/CNPq do CenPRA
Carlos Alberto dos Santos Passos
Oscar Salviano Silva Filho
Rosana Beatriz Baptista Haddad
-5-
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
-6-
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
Índice
Modelo de Análise de Artefatos Maliciosos
10
Angelo Carlos Martins Carvalho, Luiz Otávio Duarte, Marcelo Carvalho Sacchetin,
Antonio Montes
AURORA - Atualização e migração
14
Caio R. C. Nascimento, Josué Jr. G. Ramos
Desenvolvimento de Técnicas de BioCAD para Modelagem de Geometrias
Anatômicas
18
Daniel T. Kemmoku; Pedro Y. Noritomi; Jorge V. L. Silva.
O uso da ferramenta Solver® no Planejamento de Chão de Fábrica
22
Daniele Costa Silva; Rosana B. B. Haddad;
Reballing de BGA Utilizando Forno de Refusão: Resultados Preliminares 26
Egont A. Schenkel; Guilherme E. Prevedel; Talita Mazon; Márcio T. Biasoli
Ferramenta de Serviço de Acesso Independente para o REAL WebLab
30
Fernanda C. A. Atizani; Eliane G. Guimarães
Desenvolvimento de um Kit de Robótica Pedagógica de Baixo Custo Aspectos
de Software
34
Felipe Andrade Holanda; Josué Ramos, Ely Paiva
XMLIpthru: Infra-estrutura de Suporte para o REAL WebLab
38
Henrique Nakashima; Fernando Paolieri Neto; Eliane Gomes Guimarães
Ferramenta de Validação do Ambiente do Usuário para Execução no GigaBOT
WebLab
42
Gustavo Toshihide Uehara; Eliane Gomes Guimarães
Preparação de filmes finos de SnO2 dopados com Níquel pelo método dos
precursores polimércos
46
-7-
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
Gustavo B. Rossi; Aline P. Costa1; Elaine F. Z. A. Von-Zuben, Talita Mazon; Márcio T.
Biasoli
Desenvolvimento de um Sistema de Visão Omnidirecional aplicado ao
monitoramento de robôs móveis.
50
Igor A. Dias; Sidney P. Cunha; Artemis Moroni
Desenvolvimento de Plataforma Aberta para Robôs Didáticos: Aspectos de
Hardware
54
Lucas Aníbal Tanure Alves; Josué Jr. Guimarães Ramos.
Estudo da Importância da Informação no Desempenho da Cadeia de
Suprimento
58
Michelle Chaves Kuroda; Marcius F. H. Carvalho
Estratégia Baseada em Competências Essenciais
62
Mirella Borin; Marco Antonio Silveira
Estudos Aerodinâmicos e Dinâmicos no Dirigível AS800B
66
Pedro Raposo Barros; Samuel S. Bueno; Josué J. G. Ramos
Evolução de figuras no Ambiente MasterPiece
70
Rafael Bocaletto Maiolla; Artemis Moroni
Desenvolvimento de Software para Controle e Aquisição de Dados do
Microscópio Fototérmico.
74
Thiago Augusto Massarutto; Carlos R. M. de Oliveira
Desenvolvimento do software supervisor para o ambiente JaVox-Nomad 78
Thiago Vallin Spina
Seqüenciamento de processos industriais: uma abordagem baseada em Times
Assíncronos utilizando múltiplas memórias
83
André P. Bartholomeu; Carlos A. S. Passos
Caracterização da poliamida em função das características de prototipagem
rápida por sinterização seletiva a laser
87
-8-
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
Augusto C. Sánchez, Izaque A. Maia, Jorge Silva, Pedro Y. Moritomi, Marcelo Oliveira,
Elizabete Maria Saraiva Sanchez.
-9-
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
Modelo de Análise de Artefatos Maliciosos
Angelo Carlos Martins Carvalho, Luiz Otávio Duarte, Marcelo Carvalho Sacchetin,
Antonio Montes
Centro de Pesquisas Renato Archer - CenPRA
Divisão de Segurança de Sistemas de Informação
Rod. D. Pedro I, km 143,6
13069-901 Campinas SP
{angelo.carvalho, loduarte, marcelo.sacchetin, antonio.montes}@cenpra.gov.br
Resumo
A análise de artefatos maliciosos tem como função determinar o
funcionamento e a finalidade dos programas estudados com o objetivo de
contribuir para a prevenção de ataques gerados por artefatos similares no
futuro. O processo de análise envolve técnicas e ferramentas específicas
que permitem estudar o sistema onde o artefato esta sendo executado e o
seu comportamento neste sistema. O objetivo deste trabalho é apresentar
o modelo de análise desenvolvido para estudar os artefatos maliciosos
previamente coletados.
Palavras chave: Análise de artefatos maliciosos, Malware, Segurança de Sistemas de
Informação.
1. Introdução
Artefatos maliciosos, também conhecidos como malwares (malicious software),
causam diversos tipos de danos a empresas e pessoas, tais como: roubo de
informações sigilosas, controle da máquina infectada para realizar operações sem a
permissão que deveriam ter (como enviar e-mails ou acessar endereços) e perda de
arquivos e de desempenho.
Com o constante desenvolvimento de novos artefatos maliciosos aliado ao
grande número de artefatos já existentes tornou-se necessário analisá-los. Esta
análise visa obter informações importantes, tais como determinar os danos que os
artefatos podem causar, seus objetivos e as tecnologias por eles empregadas.
Com base nas informações obtidas é possível classificar os artefatos maliciosos
de acordo com a sua funcionalidade e o mecanismo de propagação, identificar o uso
de novas tecnologias e determinar o comportamento dos artefatos maliciosos
estudados. Assim podemos desenvolver técnicas para detectar, evitar o
funcionamento e eliminar, se possível, o artefato do sistema impedindo que outros
realizem operações indesejadas utilizando técnicas semelhantes.
Este trabalho propõe um modelo de análise que conta com ambientes
desenvolvidos em outros projetos como a PigHunter que coleta os artefatos que serão
estudados, a SandBox que realiza análise dinâmica automaticamente e a Honeynet
que possui uma estrutura de segurança e análise do tráfego na rede.
- 10 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
2. Análise de Artefatos Maliciosos
A análise de artefatos pode ser dividida em duas etapas principais, a estática e a
dinâmica. Na análise estática o artefato não é executado, é verificado diretamente o
código binário. São utilizadas ferramentas como disassemblers [IDA Pro], que extraem
o código assembly de um artefato, e os descompiladores, que extraem códigos em
linguagem de alto nível. Para melhor entender estes códigos são utilizados os
depuradores [OllyDbg], que permitem a execução passo a passo do artefato, definição
de pontos de parada além da exibição de valores de variáveis. Com o auxílio dos
depuradores é possível identificar as ações do artefato detalhadamente.
Na análise dinâmica o artefato é executado e os efeitos gerados a partir de sua
execução são analisados. Para auxiliar este processo são configuradas máquinas
virtuais [Vmware] que permitem que sistemas virtuais sejam criados possibilitando que
o artefato seja executado com maior segurança. Outras ferramentas [Sysinternals],
[Foundstone] também são utilizadas para obter informações do estado da máquina em
um dado instante.
3. Máquinas Virtuais
Uma máquina virtual é um computador fictício criado por um programa de
simulação. Neste computador é instalado um sistema operacional que, neste projeto, é
utilizado para executar artefatos maliciosos e estudar suas ações.
Uma das vantagens de utilizar máquina virtual durante uma análise é que podese salvar estados do sistema como, por exemplo, antes do artefato ser executado,
assim todo o dano causado na máquina virtual no fim de cada análise pode ser
reparado automaticamente pois é possível retornar ao estado em que o artefato não
havia ainda entrado em execução e o sistema não estava comprometido.
Apesar de facilitar a análise, fazendo com que a restauração do sistema possa
ser realizada de forma automatizada e garantindo um maior nível de segurança por se
tratar de um sistema virtual isolado, a máquina virtual, em alguns casos, é identificada
por artefatos maliciosos, pois eles supõem que, se estão em uma máquina virtual há
uma grande chance de estarem sendo analisados, então não realizam suas atividades
maliciosas. Para contornar este problema deve ser utilizada, em uma das etapas da
análise, uma máquina real para analisar os artefatos que possivelmente detectam
máquina virtual.
4. SandBox
A SandBox é um ambiente desenvolvido para automatizar o processo de análise
dinâmica de artefatos, gerar o relatório da análise com os resultados obtidos e
classificar os artefatos de acordo com as suas atividades. A Sandbox utiliza uma
máquina virtual para executar os artefatos coletados e uma máquina virtual para
responder as requisições de rede dos artefatos.
A SandBox possui diversas ferramentas que avaliam o sistema, então antes da
execução do artefato a SandBox gera um relatório da avaliação do sistema. Em
seguida o artefato é executado e então a SandBox gera um novo relatório, ao analisar
as diferenças entre os dois relatórios a SandBox identifica o que ocorreu no sistema
devido a execução do artefato. Dentre as informações obtidas, destacam-se: arquivos
que foram criados, alterados ou excluídos; portas que foram abertas; processos que
entraram em execução; programas que foram criados para serem executados
automaticamente quando o sistema inicializar; tráfego na rede [Tcpdump].
- 11 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
Como a máquina virtual em que o artefato será executado não tem acesso à
rede por questões de segurança foi desenvolvida uma máquina virtual que responde
as requisições de rede que o artefato gera com a finalidade de estabelecer uma
conexão e analisar o que ele requisita, como por exemplo, uma página web, um
arquivo ou a resposta de conectividade com algum endereço.
5. Modelo de Análise
O modelo de análise elaborado para ser utilizado neste projeto foi dividido em
cinco etapas. A imagem a seguir ilustra o modelo de análise e suas etapas.
A primeira etapa realiza uma análise estática automatizada após a coleta do
artefato, obtendo informações como hash, tipo do arquivo, localização e tamanho do
artefato. Estas informações são armazenadas no banco de dados da PigHunter, que é
a máquina que coleta e armazena os artefato encontrados na Internet. Se o artefato
coletado possui um hash diferente do hash de todos os outros artefatos coletados
anteriormente então ele é considerado um artefato novo, pois não há registro dele no
banco de dados, então ele é enviado para SandBox na próxima etapa.
A segunda etapa realiza uma análise dinâmica automatizada. O novo artefato
coletado é enviado para SandBox que gera automaticamente um relatório informando
o comportamento do artefato no sistema. O relatório gerado é analisado, se o artefato
não realizou nenhuma atividade maliciosa então existe uma possibilidade do artefato
em questão detectar a utilização de máquina virtual. Caso isso ocorra, ele é submetido
para terceira etapa, e em caso contrário ele segue para a etapa quatro. Se o artefato
realizou atividades já conhecidas então a análise termina concluindo que aquele
artefato tem o comportamento similar a algum outro já analisado.
Na terceira etapa é realizada análise dinâmica automatizada em uma máquina
- 12 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
real com acompanhamento do analista, sendo que, agora o analista irá fazer o papel
da máquina que gera respostas com a finalidade de descobrir porque o artefato não
realizou atividade maliciosa na máquina virtual, novamente um relatório é gerado. Se o
artefato realizou atividade maliciosa nesta etapa então é avaliado se seu
comportamento é similar a algum outro já estudado, se sim segue para etapa 4, senão
a atividade é registrada no banco de dados como sendo similar a algum outro artefato.
Caso o artefato não tenha realizado nenhuma atividade maliciosa então o artefato em
questão é considerado como não malicioso.
Na quarta etapa o artefato é submetido a uma estação de análise com
conectividade com a Honeynet [Spitzner ], [Honeynet], ou seja, o artefato terá acesso
limitado a Internet, pois a Honeynet permite controle e análise do tráfego de rede que
passa por ela. Assim o analista terá um relatório mais completo, pois se o artefato
aguardava alguma resposta da Internet para realizar alguma atividade agora ele irá
realizar. A análise segue para a última etapa.
Na quinta etapa é feito o estudo do código binário do artefato, é realizada uma
análise estática manual onde são obtidas informações como dll´s que o artefato
precisa para executar, packer que foi utilizado sobre o código do artefato, compilador
que gerou o código binário entre outras.
6. Conclusões
Não é necessário que todos os artefatos coletados passem por todas as etapas
de análise para identificar sua atividade, pois há similaridade entre o funcionamento de
artefatos, com isso há uma economia de recursos e mão-de-obra e mais artefatos
podem ser analisados utilizando um menor intervalo de tempo.
Com este modelo serão gerados relatórios detalhados sobre o funcionamento de
determinado artefato e o banco de dados irá, com o tempo, auxiliando cada vez mais
nas análises identificando padrões entre o funcionamento dos artefatos.
Referências
[1] Spitzner, L. (2004) The Honeynet Project, “Know Your Enemy”, Addison Wesley
[2] Honeynet, http://www.honeynet.org/ - The Honeynet Project
[3] Sysinternals, http://www.microsoft.com/technet/sysinternals/default.mspx
[4] Foundstone, http://www.foundstone.com/
[5] IDA Pro, http://www.datarescue.com/ - IDA Pro Disassembler & Debugger
[6] OllyDbg, http://www.ollydbg.de/
[7] Tcpdump, http://www.tcpdump.org/
[8] Vmware, http://www.vmware.com/
- 13 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
AURORA - Atualização e migração
Caio R. C. Nascimento, Josué Jr. G. Ramos
Centro de Pesquisas Renato Archer - CenPRA
Divisão de Robótica e Visão Computacional
Rod. D. Pedro I, Km 143,6
13069-901 Campinas, São Paulo.
{Caio.Nascimento; Josue.Ramos}@cenpra.gov.br
Resumo
Este artigo apresenta a conclusão dos estudos e realizações sobre a
migração da estação de terra do projeto AURORA. (Autonomous
Unmanned Remote Robotic Monitoring Airship) de RTLinux para RTAI
(Real-Time Application Interface for Linux).
Palavras chave: Real Time, RTAI, Linux, dirigível,robô.
1. Introdução
Com o infindável processo de criação de novos componentes para
computadores surge a necessidade da criação de drivers para o perfeito
funcionamento do hardware. A utilização da Real Time Application Interface for Linux
(RTAI) [1], desenvolvido pelo DIAPM (Dipartimento di Ingegneria Aerospaziale Politecnico di Milano), Milão, Itália, simplifica tal desenvolvimento, pois é possível
utilizar os drivers desenvolvidos para o Kernel Linux [2] em conjunto com a RTAI sem
muitos problemas.
Como o Kernel Linux está em constante desenvolvimento, ocorrem "saltos de
versão” onde novas funcionalidades como a melhora de desempenho e o
funcionamento de dispositivos só são implementadas na nova versão. O objetivo da
criação do sistema embarcado do projeto AURORA é permitir a maior compatibilidade
com dispositivos atuais enquanto se mantém os requisitos necessários do sistema [3],
sejam eles soft/hard realtime ou não.
1.1 O Que é RTAI
RTAI não é um sistema operacional em tempo real como o VXworks ou o QNX e
sim uma série de patches para o Kernel Linux que o tornam completamente
preemptível. Sendo assim, oferece os mesmos serviços que o núcleo do Linux,
adicionando funcionalidades de um sistema operacional em tempo real.
A RTAI é basicamente uma camada de abstração de harware (Hardware
Abstraction Layer – HAL), que captura as interrupções dos periféricos do sistema e, se
necessário, as redireciona para o Kernel Linux. Assim, diz-se que a RTAI considera o
Linux como um processo rodando em background quando não há atividade realtime.
2. Desenvolvimento e Implementação
Para realizar a migração de forma eficiente resolveu-se traçar uma linha de
pequenos objetivos a serem alcançados durante o estudo, de forma que a nova
estação de terra pudesse ser testada de várias formas. Tais atividades foram:
* Desenvolvimento de uma solução não Realtime
- 14 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
* Instalação da RTAI na estação de terra
* Adaptação para funcionamento em Tempo Real
2.1 Desenvolvimento de uma solução não Realtime
Completou-se a migração do software antigo para que funcionasse na nova
estação, corrigindo-se pequenos erros já existentes e alguns gerados pela brusca
troca de versões de bibliotecas, compiladores etc.
Com as aplicações já existentes portadas, iniciou-se um estudo sobre o módulo
principal de comunicação da estação de terra, que concluiu que seria necessária uma
remodelação da implementação existente, deixando seu código mais limpo e
facilitando atualizações bruscas.
Como meio para compreender o funcionamento da estação de terra, foi
desenvolvida uma solução rodando em modo normal que funciona de maneira similar
à estação de terra em tempo real.
2.2 Instalação da RTAI na estação de terra
Assim que a atividade 2.1 foi concluída, iniciaram-se estudos para a migração
completa da solução em RTLinux para RTAI. Como a RTAI está em atual e rápido
desenvolvimento, seu kernel está próximo da versão vanilla do Kernel Linux, o que
facilitou a instalação do mesmo, não havendo problemas de compatibilidade com o
hardware atual.
2.3 Adaptação para funcionamento em Tempo Real
Como a solução não Realtime foi modelada de forma a facilitar a sua
atualização, a migração para RTAI foi rápida e bem-sucedida, apenas necessitando
uma mudança nas chamadas de abertura, escrita e leitura (que eram controladas pelo
kernel normal) para as chamadas fornecidas pela API da RTAI, possibilitando um
funcionamento em hard realtime da estação.
Além da simples troca de chamadas, foi necessária a criação de uma aplicação
“ajudante”, que ficou responsável por escalar a aplicação para modo em tempo real,
criando-se um processo à parte controlado pelo escalonador da RTAI.
Graças à extensão LXRT [4], que permite o uso de aplicações em modo usuário
como aplicações em hard realtime, não houve mudança significativa no modo de
execução da solução, que continuou a ser chamada como um binário normal, sem a
necessidade de ser carregada como um módulo linux.
Apesar de toda facilidade na troca de funções, surgiu um problema conceitual: a
utilização do adaptador forçava a manutenção de certas diretivas de abertura, leitura e
escrita do linux, porém, uma implementação em tempo real deve evitar chamadas
nativas do sistema operacional de modo a conservar o sincronismo das atividades
realtime.
2.3.1 O LXRT e sua relação com a RTAI
O LXRT é uma extensão da RTAI que permite que programas hard realtime em
modo usuário (assim como daemons, processadores de texto, comunicadores
instantâneos, etc.). Como os primeiros programas para RTAI rodavam em modo
kernel, LXRT é visto como uma extensão que permite o uso da API do kernel em
- 15 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
Processo
Linux
IPC
Processo
LXRT
FIFO
Agendamento
Kernel Linux
Processo
Realtime
RTHAL/ADEOS
Processo
Realtime
Agendamento
Kernel Tempo Real
Modo Kernel
Processo
Linux
Modo Usuário
modo usuário. As vantagens são significativas: possibilita-se a definição de threads
realtime e não realtime no mesmo programa, permitindo que uma faça operações de
entrada e saída (não tempo real) enquanto a outra roda com um período
determinístico (tempo real). Isso permite, por exemplo, que haja comunicação com
processos normais do Linux e que se crie uma interface gráfica para a aplicação.
Interrupções de Hardware
Hardware
Figura 1: Esquema de funcionamento da RTAI e seus processos
2.4 Problemas no uso de um adaptador USB-Serial
2.4.1 Mapeamento de dispositivos no Linux
Dispositivos em linux são arquivos como qualquer outra coisa no sistema. São
dispositivos de caracteres que possuem dois números associados a eles: um
responsável por identificar o módulo que o controla, chamado de major number e um
que serve como identificação numérica do mesmo entre todos os dispositivos
controlados pelo mesmo módulo, chamado de minor number.
Ao se plugar o adaptador USB-Serial na entrada USB, o módulo usb-serial (No
caso, utilizando o pl2303 como controlador) gera um dispositivo /dev/ttyUSBX cujo
major number é 188.
Apesar de o dispositivo ser lido corretamente e funcionar perfeitamente
utilizando a chamadas open e suas relacionadas do SO, o major number do dispositivo
é diferente do identificado como uma porta serial, que é 4.
2.4.2 Associação de Portas e IRQs aos dispositivos seriais
Portas seriais possuem no sistema uma "porta" e um IRQ (A primeira porta serial
é geralmente 0x3F8 com IRQ 4) associados. A partir desses dados é possível
escrever e ler "em baixo nível" nos dispositivos.
Dispositivos USB, devido à atual implementação do stack usb no kernel do linux,
são mapeados dinamicamente, assim, não possuem porta e IRQs próprios
- 16 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
associados.
2.4.3 Módulo rtai-serial
O módulo rtai-serial disponibilizado como addon da RTAI provê comunicação em
tempo real com dispositivos plugados na porta serial. Por padrão lista as portas seriais
encontradas nos conjuntos 0x3F8:IRQ4 e 0x2F8:IRQ3 - para que seja mapeado
qualquer outro dispositivo serial é preciso passar como o parâmetro spconfig na
inicialização do módulo um array porta-irq.
Como o novo dispositivo não possui mapeamento de porta e IRQ, é impossível
dizer ao módulo rtai-serial como utilizar /dev/ttyUSBX.
2.4.4 Stack USB na RTAI
Não há atualmente uma implementação madura de um stack usb que funcione
de acordo com as necessidades em tempo real. Existe um projeto para o
desenvolvimento de tal – o usb4rt [5], porém este está parado há muito, não há
movimentação em suas listas de discussão e o estado em que foi deixado antes do
aparente abandono não torna viável o uso da USB em tempo real, pois não é uma
implementação genérica e não funciona nas versões atuais (3.x) da RTAI.
3. Conclusão
Levando em consideração as limitações atuais dos sistemas em tempo real de
código aberto sobre o linux, a baixa demanda de fluxo de dados na estação de terra e
o poder de processamento da atual estação, a adaptação para a geração atual do
kernel linux e a migração do RTLinux para o RTAI foi bem sucedida.
Como objetivo futuro tem-se a completa migração para RTAI do sistema
embarcado, gerando assim uma solução para dispositivos embarcados em geral.
Referências
[1] Real Time Application Interface for Linux (RTAI) – http://www.rtai.org
[2] Kernel Linux - http://www.kernel.org
[3] Maeta, S.S.; Ramos, J.J.G.; Mirisola, L.G.B.; Bueno, S.S.; Bergerman, M. (2000)
“Arquitetura de Hardware do Projeto AURORA.” XIII Congresso Brasileiro de
Automática, Florianópolis, SC, Set. 2000.
[4] E. Bianchi, L. Dozio; “Some Experiences in fast hard realtime control in user space
with RTAI-LXRT”; Realtime Linux Workshop, Orlando, Florida, USA, Nov. 2000.
[5] USB For Realtime (usb4rt) - http://developer.berlios.de/projects/usb4rt/
- 17 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
Desenvolvimento de Técnicas de BioCAD para Modelagem de Geometrias
Anatômicas
Daniel T. Kemmoku; Pedro Y. Noritomi; Jorge V. L. Silva.
Centro de Pesquisas Renato Archer - CenPRA
Divisão para Desenvolvimento de Produtos
Rod. D. Pedro I, km 143,6
13069-901 Campinas SP
{pedro.noritomi; jorge.silva}@cenpra.gov.br
Resumo
Aplicações de bioengenharia têm sido cada vez mais freqüentes no âmbito
da pesquisa acadêmica, principalmente as aplicações relacionadas com
análises de tensões e deformações por elementos finitos. No entanto, a
condição básica para realização desse tipo de análise é a disponibilidade
de representações das geometrias anatômicas em formato CAD. Este
artigo descreve uma metodologia desenvolvida para modelagem de
geometrias anatômicas complexas adaptando ferramentas CAD de
engenharia para uso em bioengenharia e BioCAD.
Palavras chave: Bioengenharia, Geometria Anatômica, BioCAD.
1. Introdução
O emprego de alta tecnologia nas mais diversas áreas do conhecimento humano
tem se tornado o cotidiano do desenvolvimento e da pesquisa. Esta tendência também
tem atingido as aplicações voltadas para a área médica e de saúde, trazendo
tecnologia antes exclusiva de outras aplicações para modernizar técnicas e
ferramental dos profissionais da saúde. Esse tipo de aplicação tem exigido alterações
na perspectiva dos profissionais envolvidos, expondo-os a um novo paradigma de
integração multidisciplinar.
Problemas de ortopedia, relacionados à recuperação ou correção de função,
seja por motivo de acidente ou deformidades congênitas, necessitam de apoio
tecnológico, principalmente para garantir resultados duradouros e que sejam
adequados às características de cada paciente, como pode ser visto no exemplo de
aplicação da figura 1, que descreve um procedimento de recuperação de calota
craniana realizado com o apoio do CenPRA.
Uma das grandes dificuldades da personalização, a de reproduzir as formar
orgânicas das estruturas do corpo humano, tem sido enfrentada pela Divisão para
Desenvolvimento de Produtos do Centro de Pesquisas Renato Archer (DDP/CenPRA),
em seu projeto ProMED (Prototipagem Rápida na Medicina) com o desenvolvimento e
integração de ferramentas de software como o InVesalius (SANTA BÁRBARA, 2006),
capaz de fornecer a representação virtual de geometrias anatômicas a partir de
exames de imagens médicas, com ferramentas de edição CAD (Computer Aided
Design) de uso típico em aplicações de engenharia, adaptadas para uso em
bioengenharia.
- 18 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
Figura 1. Ciclo de desenvolvimento de implante personalizado, desde os
dados.
O InVesalius é um software desenvolvido completamente por uma equipe
integrada ao ProMED, dispondo de um código implementado em linguagem python,
juntamente com bibliotecas para manipulação gráfica computacional chamadas VTK
(Visualization Tool Kit). Assim, trata-se de um software cujo código fonte é de domínio
dessa equipe e que pode ser alterado e adaptado conforme demandas. O InVesalius é
um programa de uso gratuito, que pode ser baixado diretamente da Internet pelo link
http://www.cenpra.gov.br/promed/contrato.htm. Esse programa é capaz de gerar a
representação sólida tridimensional, em computador, de estruturas representadas em
exames de tomografia computadoriza, por exemplo, a partir dos arquivos das fatias
geradas por esses exames em formato DICOMSM (Digital Imaging and
Communications in Medicine), que é um padrão para imagens médicas obtidas por
exames computadorizados. Uma vez recompostas as fatias DICOMSM e gerada a
representação tridimensional, o InVesalius permite a geração de um arquivo de saída
em formato STL (Stereolithography), o qual representa a geometria, em um formato
final, para máquinas de prototipagem rápida, as quais materializam o objeto digital.
Além do InVesalius, o grupo de bioengenharia do CenPRA utiliza as ferramentas
CAD Rhinoceros e Solidworks para edição e reconstrução de partes anatômicas de
acordo com demandas. Além disso, essas ferramentas CAD são utilizadas para
projeto e adaptação de dispositivos protéticos ou implantes, aproveitando a alta
qualidade da geometria anatômica obtida pelo InVesalius.
O desafio da utilização de ferramentas CAD comerciais para aplicações em
bioengenharia está no caráter singular das estruturas anatômicas e na alta
complexidade envolvida em sua representação digital. Ao contrário de estruturas
projetadas, que podem ser representadas por operações geométricas simples,
organizadas em atributos como furos e rasgos de encaixe, as estruturas anatômicas
são altamente complexas e individuais, necessitando de representação muito mais
complexa.
Neste artigo são descritos procedimentos propostos em uma metodologia para
adaptar ferramentas CAD como o Rhinoceros para modelagem de geometrias
anatômicas complexas a partir do uso de superfícies NURBS, as quais são definidas
por equações matemáticas capazes de descrever superfícies não uniformes, de
- 19 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
curvaturas orgânicas.
2. Metodologia de modelagem 3D
As ferramentas CAD são tradicionalmente utilizadas para auxílio ao
desenvolvimento de projetos mecânicos, portanto, são plataformas para a concepção
de formas tridimensionais complexas. No entanto, por maior que seja a complexidade
atingida, ela é sempre projetada, o que significa que foi proposta. Isso faz com que as
geometrias sejam bem definidas e de fácil edição.
Geometrias anatômicas não foram projetadas em aplicativos CAD, o que obriga
a realização de um processo semelhante à engenharia reversa para obter sua
representação computacional. No entanto, além do processo de digitalização, é
necessário o uso de uma ferramenta CAD com grande capacidade de manipular
geometrias complexas, dadas as características das geometrias anatômicas.
Dessa forma, foi escolhido o software Rhinoceros para manipular os arquivos
gerados pelo InVesalius, os quais podem ser interpretados como nuvens de pontos.
O procedimento também utilizou nuvens de pontos obtidas diretamente por
processo de digitalização tridimensional, a partir de digitalizadoras por toque, quando
os detalhes geométricos requeridos encontravam-se abaixo daqueles disponíveis nos
exames de tomografia computadorizada.
Uma vez disponível a nuvem de pontos, seja a partir do InVesalius ou de um
digitalizador tridimensional, o arquivo foi importado no ambiente de modelagem do
Rhinoceros, passando a ser a referência para geração de superfícies. No entanto,
para aplicações de bioengenharia, a técnica de geração das superfícies mostrou-se de
grande relevância, dado que permitiu a geração de arestas e pontos de controle em
regiões de alta importância para a qualidade da representação da geometria
anatômica.
No caso específico deste trabalho, foi modelado um dente pré-molar superior,
sobre o qual seriam realizadas simulações de tratamento dentário virtuais, todas
utilizando ferramentas CAD. Além disso, o modelo gerado também deveria ser
adequado para realização de análises por elementos finitos.
Todas essas características fizeram com que fosse desenvolvida uma técnica de
modelagem baseada em marcos anatômicos do dente, os quais foram definidos em
conjunto com equipes multidisciplinares de odontologia.
3. Resultados
O modelo do pré-molar foi obtido a partir de digitalização em máquina
digitalizadora por toque. Devido a restrições mecânicas, somente uma metade do
dente pode ser digitalizada de cada vez, o que obrigou a um procedimento inicial de
união das duas metades do sólido. Após esta etapa, foram criadas superfícies de
modo a cobrir toda a malha e definir o sólido.
É interessante notar que, como o dente é composto por três estruturas, esmalte
(figura 2a) e dentina (figura 2b) e ligamento periodontal (figura 2c), houve necessidade
de montá-las uma sobre a outra.
O resultado final pode ser visto na figura 2.
- 20 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
a
b
c
Figura 2. Dente modelado no Rhinoceros com esmalte, dentina e ligamento
periodontal.
4. Discussão
O dente modelado a partir dos dados de digitalização apresentou desafios
práticos interessantes. Inicialmente, o problema de união das duas faces originadas
pelo processo de digitalização. Nesta etapa foi exigida grande precisa do programa
CAD, a fim de ajustar corretamente a união.
A modelagem das superfícies obedeceu alguns marcos anatômicos principais do
dente, tais como vertentes de cúspides, cristas, fossas, furcas e outros. Apenas
ligamento periodontal foi construído a partir da raiz do dente, como expansão da
mesma, sem relacionamento direto com a nuvem de pontos digitalizada.
5. Conclusões
O modelo construído mostrou ser de alta qualidade, reproduzindo até mesmo os
menores detalhes da digitalização de origem. O uso de técnicas baseadas em marcos
anatômicos revelou-se de grande utilidade, principalmente quando foram necessárias
correções ou mesmo a criação do ligamento periodontal a partir de informações
digitalizadas somente para a raiz do dente.
Finalmente, o uso de superfícies complexas para a definição do modelo,
resultando em uma representação sólida mais inteligente, permitiu obter um modelo
tridimensional otimizado para aplicações em bioengenharia.
Referências
Santa Bárbara, A., Processamento de Imagens Médicas Tomográficas para
Modelagem Virtual e Física - o Software InVesalius, 2006.
- 21 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
O uso da ferramenta Solver® no Planejamento de Chão de Fábrica
Daniele Costa Silva; Rosana B. B. Haddad;
Centro de Pesquisas Renato Archer – CenPRA
Laboratório de Tecnologias de Gestão Empresarial
Rod. D. Pedro I, km 143,6
Campinas SP 13083-970
{ daniele.silva; rosana.haddad; }@cenpra.gov.br
Resumo
Esse projeto tem como objetivo o estudo do planejamento do chão de
fábrica utilizando como ferramenta de apoio às decisões a ferramenta
Solver®. Isso será feito por meio do desenvolvimento de um “ambiente
padrão” para a aplicação e a apresentação de resultados na ferramenta
Solver® e o estudo e avaliação desta, levando-se em consideração o
tamanho do problema estudado e suas respectivas restrições e variáveis.
Palavras chaves: Planejamento de Chão de Fábrica, Programação Linear, Solver®.
1. Introdução
Um problema presente na maioria das empresas de manufatura é a dificuldade
em seqüenciar as operações. O correto dimensionamento e gerenciamento da
capacidade de chão de fábrica possibilita às empresas atender pedidos de clientes
nas quantidades necessárias, no tempo devido e com os níveis de qualidade
desejados pelos clientes, a custos aceitáveis. Pretendeu-se, portanto, comparar
possíveis modelagens e escolher a mais adequada para a resolução deste problema,
utilizando como ferramenta o Solver® e algoritmos de Programação Linear.
A Programação Linear estuda a otimização de recursos. A quantidade a ser
maximizada ou minimizada é descrita como uma função matemática linear de recursos
(variáveis de decisão) escassos. As relações entre as variáveis são formalizadas
através de restrições lineares ao problema expressas como equações e/ou
inequações matemáticas.
O Solver® é uma ferramenta do MS®Excel® que faz parte de um conjunto de
programas chamado de ferramentas de análise hipotética. Com o Solver®, é possível,
por exemplo, localizar um valor ideal para uma fórmula em uma célula (célula de
destino) em uma planilha, relacionar direta ou indiretamente a célula de destino com
outras células, ajustar valores nas células variáveis (especificada pelo usuário) para
produzir o resultado especificado na célula de destino, aplicar restrições que podem se
referir a outras células que afetem a fórmula da célula de destino. A vantagem do uso
do Solver® está em que o ambiente é o mesmo utilizado no Microsoft® Excel® e,
portanto, pode ser considerado familiar para a maioria dos usuários em empresas.
Portanto utilizando essas ferramentas foi desenvolvido um “ambiente padrão”
para aplicação e apresentação dos resultados no Microsoft® Excel®. Para isto foram
usados dados de uma empresa do setor de autopeças.
- 22 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
2. O “Ambiente Padrão”
Para apresentarmos este “Ambiente Padrão” a seguir segue um pequeno
problema a ser modelado.
Problema:
Em uma fábrica são produzidos dois produtos, cujos códigos são 48004 e 48007
respectivamente. Para a produção destes, a fábrica possui duas células (23 e 24) e
trabalha-se em dois períodos.
Em nosso modelo os produtos processados nas células prioritárias possuem
lucro 15. Já aqueles processados em células alternativas possuem lucro 10. Caso
sejam utilizados armazenagem ou backorder haverá custo 1 e 5 respectivamente.
Podemos representar o problema por meio de grafos como mostra a figura 1.
1
3
0
5
1
2
4
Pontos de Tomada de Decisão
Indicam o fluxo de produtos na linha de montagem relativo ao
fornecimento de matéria prima, ou ao processamento em
alguma célula, ou ainda ao atendimento de demanda.
Indica fluxo de produto no tempo:
estoque de produto de um período
para o próximo
Indica fluxo de demanda no tempo:
entrega de produto em atraso
Célula 23
Figura 2- O Ambiente
Célula 24
Figura 1: Representação do problema por meio de grafo
Sendo assim o modelo pode ser apresentado, como na figura 2
- 23 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
Figura 2 - O Ambiente Padrão
O Ambiente padrão pode ser dividido em três partes:
•
•
•
Cenário de Entrada de Dados;
Produção;
Cenário de Saída.
O Cenário de Entrada de dados contém os dados dinâmicos, ou seja, os que
sofrem mudanças freqüentemente e influenciam os demais dados. É onde serão
inseridos dados como por exemplo demandas, quantidade de horas trabalhadas por
turno, entre outras. Desta forma procura-se centralizar as informações facilitando
alterações nos dados mais dinâmicos da empresa.
A Produção é a parte onde será simulado o processo de produção da empresa.
Boa parte de seus dados são funções dos dados do Cenário de Entrada.
O Cenário de Saída apresenta o resultado otimizado do problema, ou seja, o
quanto da demanda foi entregue no prazo, produtos armazenados e entregues em
atraso.
As variáveis de decisão do problema encontram-se no intervalo M5:M16, os
custos e ou lucros das variáveis estão no intervalo L5:L16. A função objetivo neste
caso a ser maximizada está na célula J2 (SOMARPRODUTO(L5:L16;M5:M16)). As
restrições encontram-se nos seguintes intervalos: K19:K22 (restrições de demanda),
L25:L32 (restrições de capacidade individual de produção das células), U6:U13
(restrições de capacidade das células).
3. Conclusão e trabalhos futuros
O modelo apresentado para aplicação e apresentação de resultados (“ambiente
padrão”) possui diversos pontos positivos. Tais como, aproveitar um programa
- 24 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
largamente utilizado em empresas e de uso relativamente simples (Excel); permitir
uma boa visualização e organização de dados; permitir a modelagem de problemas
relativamente grandes, além do Solver comportar um grande número de variáveis e
restrições; considerar na otimização aspectos como, custo de atraso, custo de
estocagem fazendo com que a análise de custo seja transparente ao operador e o
software de Programação Matemática minimizará o custo total da produção;
centralizar as informações facilitando alterações nos dados mais dinâmicos da
empresa, como demandas, capacidade de máquinas por períodos, etc. Quanto aos
tempos de setup foram adicionados aos tempos de processamento, pelo fato de não
poderem ser modelados na Programação Linear.
Portanto com o Chão de Fábrica modelado e o problema de otimização do uso
dos recursos resolvido, uma interessante proposta para trabalhos futuros seria analisar
vários índices de desempenho de comportamento de um chão de fábrica real, como
tempos padrões de execuções de lotes com e sem setup, tempos reais de execução,
porcentagem de ociosidade , nível de atendimento, entre outros. Tendo como base
para a análise as planilhas Excel® desenvolvidas nos projetos de Iniciação Científica
de 2005 e 2006.
Referências
BOGHI, C., SHITSUKA, R., “Microsoft Office Excel 2003 e Solver – Ferramentas
Computacionais para a Tomada de Decisão”. Editora Érica, São Paulo, 2005
LACHTERMACHER, G., “Pesquisa Operacional na Tomada de Decisões –
Modelagem em Excel”. Editora Campus, Rio de Janeiro, 2004
TAKAHASHI, M. T., “Planejamento de Produção da Manufatura: Análise de
Desempenho de Algoritmos em Ambiente Paralelizado”. UNICAMP, Campinas –
cap. 1e 2
- 25 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
Reballing de BGA Utilizando Forno de Refusão: Resultados Preliminares
Egont A. Schenkel; Guilherme E. Prevedel; Talita Mazon; Márcio T. Biasoli
Centro de Pesquisas Renato Archer - CenPRA
Divisão de Empacotamento Eletrônico
Rod. D. Pedro I, Km 143,6
13069-901 Campinas SP
{egont.schenkel; guilherme.prevedel; talita.anselmo; marcio.biasoli}@cenpra.gov.br
Resumo
BGA é um encapsulamento com alta densidade de contatos elétricos em
formas de esferas bastante utilizados na indústria eletrônica. Geralmente,
tais encapsulamentos contém circuitos integrados de alto valor agregado e
devido a problemas de soldagem que podem ocorrer durante o processo
de montagem, se faz necessário o retrabalho desse tipo de componente.
No presente trabalho é apresentado uma forma diferente de refazer os
contatos elétricos dos BGAs, utilizando pasta de solda livre de chumbo e
forno de refusão. Observou-se, que após a refusão, a pasta de solda
adquiriu o formato de semi-esferas. É necessário controlar o volume de
pasta de soldas para obter contatos elétricos esféricos e evitar curto
circuitos e migração da liga metálica entre os mesmos.
Palavras chave: Retrabalho de BGA, Tecnologia de Montagem em Superfícies, Solda
Livre de Chumbo.
1. Introdução
BGA (Ball Grid Array) é um encapsulamento com alta densidade de contatos
elétricos bastante utilizados na indústria eletrônica. Geralmente, tais encapsulamentos
contém circuitos integrados de alto valor agregado e devido a problemas de soldagem
que podem ocorrer durante o processo de montagem, se faz necessário o retrabalho
desse tipo de componente eletrônico.
Atualmente, o processo de retrabalho consiste em limpar os pads do BGA após
remove-lo da placa de circuito impresso, aplicar esferas (“balls”) em cada pad com
auxílio de um “stencil” e aquecer BGA por BGA em estações de retrabalho por
refusão. Porém, as principais desvantagens desta metodologia estão no custo elevado
das esferas e problemas de curto-circuito dos contatos elétricos causados por “missing
balls” (esferas que não foram depositadas corretamente) ou então travamento do
“stencil” após o processo de “reballing” danificando os contatos.
No presente trabalho é apresentado uma metodologia diferente de refazer os
contatos elétricos dos BGAs, utilizando pasta de solda livre de chumbo (“lead-free”)
para substituir as esferas pré-fabricadas e passando vários BGAs em forno de refusão
ao invés de aquecê-los um a um como no processo tradicional. Foram obtidas
imagens em microscópio óptico dos contatos retrabalhados e os resultados
preliminares foram discutidos.
2. Metodologia
Inicialmente 4 BGAs dummy tipo 225 lead-free com esferas de 650 m de
diâmetro, passaram por um processo de “baking” (“cozimento”) por 48 horas à
temperatura de 120°C com o intuito de eliminar a umidade que geralmente é absorvida
- 26 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
nesse tipo de encapsulamento.
Após o “baking” as esferas dos BGAs foram removidas com soprador de ar
quente e sugador de solda do sistema de retrabalho da Martin, modelo Auto Vision
Expert 09.5. O resquício de solda ainda contida no BGA foi removido utilizando malha
para dessoldagem e ferro de solda.
Utilizando um dispenser manual da Martin, modelo Smart Dispens 02, com
controle preciso de volume de aplicação, foi aplicado pasta de solda Kester EM 907
lead-free, com a composição Sn 96,5%, Ag 3,0% e Cu 0,5%. O volume de pasta
aplicado em cada contato do BGA foi igual ao volume de cada esfera do BGA mais a
perda de massa estimada devido ao fluxo contido na pasta de solda, ou seja:
4
π
π
Vaplicado = Vball + v = πr 3 + v = D 3 + v ⇒ Vaplicado = D 3 + v
3
6
6
(1)
onde D é o diâmetro da esfera e v é o volume estimado da perda de massa,
V
≅ 0,16mm 3
cerca de 11% segundo Data Sheet da pasta de solda. Portanto, aplicado
por
contato do BGA. Essa unidade de volume foi escolhida devido a unidade utilizada no
dispenser.
Após a aplicação da pasta de solda nos contatos, os BGAs passaram no forno
de refusão Heller modelo 1500s (Figura 1) e o perfil de temperatura utilizado foi obtido
a partir dos parâmetros apresentados na Tabela I.
Após a refusão, os contatos elétricos dos BGAs foram inspecionados utilizando
um microscópio óptico e os resultados foram comparados com os BGAs dummy
novos.
Tabela I
Parâmetros do forno de Refusão
Zona
Temperatura (°C)
PH
185
Z2
190
Z3
200
Z4
235
RF
262
Vel. Esteira
35 mm/s
Figura 1 – Desenho esquemático do forno de
refusão Heller 1500s.
Tempo total
8 min.
3. Resultados e Discussões
É apresentado, na Figura 2, o perfil térmico obtido no forno de refusão a partir da
leitura de 3 termopares em uma placa de testes, com auxílio do software de controle
do forno. Nota-se, que o comportamento da curva obtida, Figura 2, é de um perfil típico
para soldas isentas de chumbo.
Na Figura 3 é apresentado um BGA após passar pelo forno de refusão. É
possível notar as semelhanças entre os diâmetros do BGA retrabalhado e do BGA
novo (Figura 4). Contudo, na base do contato se forma uma fina camada de fluxo
proveniente da pasta de solda. Porem, foi possível remover essa camada com uma
leve escovação com removedor de fluxo.
Quando analisadas lateralmente, como apresentado nas Figuras 5 e 6,
- 27 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
verificamos que os contatos retrabalhados não adquirem a forma de esferas completas
(Figura 5), mas de semi-esferas, com uma diferença de altura h entre o contato
original e o retrabalhado de aproximadamente 178 m em média. Isto indica que o
volume utilizado não foi suficiente para gerar esferas. A Figura 7 apresenta um
desenho esquemático do contato novo e do contato retrabalhado.
Perfil de Temperatura
(Lead-Free)
300
Temperatura (°C)
250
200
150
100
50
0
0
1
2
3
4
5
6
7
8
9
Tempo (min)
Figura 2 – Perfil do forno de refusão
Figura 3 – Foto obtida do BGA retrabalhado. É
possível notar o acumulo de fluxo junto as bases
dos contatos.
Figura 4 – Foto obtida do BGA novo.
Figura 5 – BGA retrabalhado. Nota-se a forma
de uma semi-esfera.
Figura 6 – BGA Novo.
Figura 7 – Desenho esquemático comparando os contatos do BGA novo (à direita) e o BGA
retrabalhado (à esquerda).
É importante ressaltar que a pasta de solda depositada tende a adquirir formato
de semi-esfera, devido ao fato que, quando aquecida acima do ponto de fusão, a liga
em estado líquido tende a adquirir uma geometria com menor tensão superficial,
análogo a uma gota de água em uma superfície plana. No entanto, a obtenção de
- 28 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
contatos elétricos com altura menor que a esperada pode acarretar alguns problemas,
como a impedância geral do circuito ou problemas de dissipação de calor. Por isso, é
necessário determinar o volume exato de pasta de solda visando obter contatos com
forma de esferas e altura equivalente.
Outro cuidado que deve ser tomado no momento da deposição da pasta de
solda é evitar a formação de “tails” durante a deposição da pasta de solda por
dispenser. Esses “tails” formam curto-circuitos entre os contatos do BGA ou então
causam a migração da liga metálica de um contato para outro, como apresentado na
Figura 8. O volume de pasta de solda aplicado também deve ser controlado para evitar
que os contatos tenham diferentes tamanhos.
Figura 8 – Curto-circuito e migração da liga metálica:
problemas na deposição da pasta de solda
Embora os contatos obtidos apresentem formas de semi-esferas, os resultados
obtidos são bastante promissores visto que a metodologia desenvolvida proporcionou
uma redução do tempo de operação, quando comparado ao processo de retrabalhar
os BGAs individualmente (processo tradicional de reballing).
4. Conclusões
A pasta de solda depositada nos contatos tomou o formato de semi-esferas que
podem substituir os “balls” utilizados nos processos tradicionais de retrabalho de BGA.
Embora alguns cuidados no momento da deposição da pasta de solda devem
ser tomados para evitar curto-circuitos e migração da liga metálica de um contato para
outro, os resultados são bastante promissores.
Agradecimentos
Os autores agradecem ao CNPq pelo auxílio financeiro.
Referências
Grama, A.; Chindris, G.; “Contributions on low-cost µBGA soldering/re-soldering
methods.” 26th International Spring Seminar on Electronics Technology, Stará
Lesná, Eslováquia, Maio 2003, pp. 192-195.
Gowda, A.; Primavera, A.; Srihari K.; “Challenges in Lead-Free Rework.” Pan Pacific
Microelectronics Symposium Proceedings, 2002.
Hwang, J.; Ball Grid Array & Fine Pitch Peripheral Interconnections. Electrochemical
Publications, 1995.
Hwang, J.; Environment Friendly Electronics: Lead-Free Technology. Electrochemical
Publications, 2001.
- 29 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
Ferramenta de Serviço de Acesso Independente para o REAL WebLab
Fernanda C. A. Atizani; Eliane G. Guimarães
Centro de Pesquisas Renato Archer - CenPRA
Divisão de Robótica e Visão Computacional (DRVC)
Rod. D. Pedro I, Km 143,6
13069-901 Campinas SP
[email protected];[email protected]
1. Resumo
Esse artigo apresenta uma ferramenta de serviço de acesso independente,
onde o maior desafio e prinicipal objetivo, foi prover uma infra-estrutura
onde experimentos e usuários possam ser incorporados e alterados com
facilidade. Para isso, foi desenvolvido um sistema de cadastro de
participantes que permite que alunos, que irão utilizar os serviços do
laboratório, se cadastrem independentemente do administrador do
sistema. Além disso, esse sistema delega ao professor, a capacidade de
formar grupos de alunos com seus papéis e permissões a um determinado
laboratório e seus experimentos, de uma maneira simples e prática
descentralizando atividades que antes eram efetuadas apenas pelo
administrador do sistema.
Palavras chave: Sistemas Multimídia Distribuídos, Serviços Web, Laboratórios de
Acesso Remoto, Telerobótica
1. Introdução
Laboratórios de acesso remoto ou Web Labs têm sido propostos como
poderosas ferramentas de suporte ao ensino, tanto presencial quanto à distancia. O
maior desafio na implementação desse tipo de serviço é prover uma infra-estrutura
onde experimentos possam ser incorporados e alterados com facilidade.
Com o intuito de desvendar esse desafio, existe no CenPRA um Laboratório de
Acesso Remoto (LAR) para controle de robôs móveis, do projeto REAL (Remotely
Accessible Laboratory), da Divisão de Robótica e Visão Computacional (DRVC) . O
acesso a esse laboratório é realizado via internet ou redes avançadas, e permite aos
usuários manipular um robô através de comandos, desenvolver testes sofisticados de
algoritmos de navegação, observar o funcionamento do robô e executar funções
admnistrativas como cadastramento de usuários, acesso ao laboratório e reserva de
horários para a realização de algum experimento.
Além disso, cada componente do laboratório é disposto como um Web Service.
Os robôs, as câmeras e o controle de acesso são Web Services com interfaces
públicas WSDL (Web Service Description Language). Desta maneira é possível
realizar diferentes experimentos por associações de diferentes serviços Web[1]. A
estrutura do REAL WebLab é esquematizada na Figura 1.
- 30 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
Figura 1: Descrição esquemática dos equipamentos do Laboratório.
2. Desenvolvimento e Atividades Realizadas
Para utilizar um experimento no laboratório REAL/Gigabot WebLab[3], o
participante usa os serviços de acesso para autenticar-se e, só depois, seleciona um
experimento da lista dos possíveis experimentos. Assim, é de responsablidade do
usuário iniciar uma sessão de acesso com o WebLab.
Os serviços de gerenciamento são subdivididos em três grupos: serviços de
gerenciamento, papéis e permissões; serviços de gerenciamento de laboratórios,
experimentos e recursos; e serviços de gerenciamento de reserva e de restrições.
Para restringir o uso do WebLab, o serviço de gerenciamento (administrador) de
participantes possibilita o cadastramento, atualização e remoção de participantes
(grupos e usuários).
Com funcionalidades semelhantes, o serviço de gerenciamento de laboratórios,
experimentos e recursos possibilita o cadastramento, atualização e remoção de
laboratórios, experimentos e recursos, bem como a associação dos mesmos. Somente
depois dessas associações terem sido estabelecidas é que um experimento pode ser
disponibilizado.
Serviços iterativos com WebLab necessitam de acesso exclusivo para certos
recursos, como robôs e câmeras, e por isso, demandam facilidades que possibilitem a
reserva dos mesmos por um determinado tempo. Cabendo portanto ao sistema, que
os recursos associados ao experimento estejam disponíveis para a reserva em
questão.
Entretanto, qualquer modifição que se deseja fazer no sistema de software
necessitava-se da presença do administrador. Assim, a fim de descentralizar as
atividades do administrador, foi desenvolvido um sistema capaz de disponibilizar o
cadastramento dos participantes pelo próprio usuário que queira utilizar os
experimentos robóticos e para os próprios professores que desejarem cadastrar um
grupo de alunos para utilizarem os experimentos em algum curso de robótica e
sistemas distribuídos.
- 31 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
3. Resultados Obtidos
Com o intuito de descentralizar as atividades do administrador fez-se
inicialmente um software capaz de ler um arquivo.xml com vários nomes de
participantes que deverão ser cadastrados e subtrair dele as informações necessárias
para cadastrar todos esses usuários no banco de dados do sistema (MySQL). A
interface desse software pode ser vista na figura 2.
Esse software, foi desenvolvido utilizando essencialmente a linguagem Java[2] e
JSP[4]. Inicialmente um documento.xml é inserido pelo professor através de uma
página.jsp no qual deve conter o nome de todos os alunos que fazem parte do grupo
que será formado pelo professor.
Figura 2: Página para a criação de um novo grupo
Em seguida, esse documento.xml é lido por uma estrutura SAX, e através dos
beans criados pelo Beanbuilder, os dados são inseridos no banco, como mostrado no
esquema da figura 3.
Figura 3: Esquema para criação de um grupo
Foi desenvolvido também, um sistema que disponibiliza o cadastramento dos
participantes pelo próprio usuário que queira utilizar os experimentos. Esse usuário
entra no site, preenche o fomulário de requisição de cadastro e solicita seu pedido.
Esses dados, são inseridos primeiramente em um banco de dados intermediário
e um e-mail é enviado imediatamente ao administrador avisando que alguem solicitou
um cadastro.
Assim, o administrador, o qual tem permissão para permitir o cadastro de
usuários, entra em uma página onde estão disponíveis todos os dados das pessoas
que solicitaram cadastro e autoriza aqueles que se enquadrarem ao sistema de
seleção do administrador.
- 32 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
Assim, os dados daqueles que tiveram seu cadastro autorizado são inseridos no
banco de dados final e retirados do banco de dados intermediário. Só que agora os
dados foram inseridos em várias tabelas para uma melhor organização do sistema. E
aqueles que não foram autorizados tem seus dados retirados do banco de dados
intermediário, como mostrado no esquema da figura 4.
Figura 4: Esquema para requisição de cadastro e sua autorização
4. Conclusão
Com o intuito de desvendar o desafio de prover uma infra-estrutura de software
que facilitasse a inserção e a alteração de alunos no laboratório, foi estudada,
inicialmente, a utilização de ferramentas importantes[5] não só para construção de
Serviços Web mas também para construir uma base de conhecimentos necessários
para trabalhar com sistemas distribuídos para a criação de WebLabs.
Além disso, foi desenvolvido com sucesso uma ferramenta de cadastro de
participantes, independente do administrador de sistema, e uma ferramenta de criação
de grupos de alunos, a qual permite que o professor autorize um número razoavel de
pessoas a um determinado laboratório e seus experimentos de uma maneira simples e
prática. Este projeto já está sendo usado atualmente no Curso de Robótica Móvel,
ministrado na FEEC/UNICAMP.
Finalmente, foi entendida a grande importância dos Serviços Web para as mais
variadas aplicações, e com isso, uma área bastante interessante para continuação
desses estudos é investigar mecanismos para operação segura de WebLabs de forma
federada fazendo uma interconexão de WebLabs.
Agradecimentos
Este trabalho é suportado pelo CenPRA/PCI/ITI. Agradeço, portanto, à minha
orientadora Doutora Eliane G. Guimarães do DRVC/CenPRA e ao apoio recebido pelo
Professor Doutor Eleri Cardozo da UNICAMP e membro do grupo REAL .
Referências
[1] Apache Software Foundation (2006). Apache Projetcts. http://www.apache.org
[2] Java Como Programar,4ª Edição – H. M. Deitel e P. J. Deitel
[3] Coelho, P., Sassi, R., Cardozo, E., Guimarães, E., Faina. L., Lima, A., Pinto, R. A
Web Lab for Mobile Robotics Education. In proceeding of the IEEE International
Conference on Robotics and Automation (ICRA 07), Roma, Italy – 2007.
[4] Servlets & JavaServer Pages,2ª Edição – Hall Brown
[5] W3 School - http://www.w3schools.com
- 33 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
Desenvolvimento de um Kit de Robótica Pedagógica de Baixo Custo
Aspectos de Software
Felipe Andrade Holanda; Josué Ramos, Ely Paiva
Centro de Pesquisas Renato Archer - CenPRA
Divisão de Robótica e Visão Computacional
Rod. D. Pedro I, Km 143,6
13069-901 Campinas SP
{josue.ramos}@cenpra.gov.br
Resumo
Apresenta-se os aspectos de software que viabilizaram a disponibilização
de um ambiente de programação icônico para um kit de robótica
pedagógica de baixo custo, chamado de Gogoboard.
Palavras chave: Robótica pedagógica, software, ambiente de programação
1. Introdução
A Figura 1 mostra os componentes principais de um ambiente de robótica
pedagógica, o qual consiste de um dispositivo de programação - geralmente um
computador com uma interface de software onde uma estratégia de controle é
concebida e carregada na unidade de controle, que é comumente um processador
simples, conectado a motores e sensores e então a dispositivos mecânicos que são
usados para construir um dispositivo robótico.
Dispositivo
de
Programação
(em geral um
computador)
Unidade de
Controle
(em geral
processador
simples)
Motores
Engrenagens
Sensores
Componentes
Mecânicos
Dispositivo Dispositivo
Elétrico
Mecânico
Device
DispositivoRobótico
Figura 2:Ambiente de robótica pedagógica
O objetivo dos kits de robôs didáticos é promover ao adolescente o contato com
uma série de tecnologias através de experimentos lúdicos. O principal representante
dessa categoria é o kit chamado Lego Mindstorms. O grande problema desse sistema
na realidade brasileira é seu alto custo, na faixa de R$500,00.
Entretanto, existem sistemas abertos, que disponibilizam esquemas de
hardware, o firmware e o ambiente de programação. Alguns dos maiores
representantes deste tipo de sistema são a plataforma GoGo e o Handy Cricket,
A disponibilizarão de um ambiente de programação icônico como o Logoblocks
mostrado na Figura 3, vem facilitar muito o aprendizado, entretanto várias buscas
- 34 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
efetuadas não foi obtido sucesso.
Figura 3 : Interface de Programação via LogoBlocks
Este artigo demonstra ás atividades que conduzirão a disponibilização de um
ambiente de programação de robótica pedagógica aberto.
2. O LogoBlocks
Em relação a interface de programação diz respeito a disponibilidade ou não de
metáforas icônicas para a programação da unidade de controle. A disponibilidade
deste recurso é muito importante, já que é muito difícil para um usuário sem
experiência com computadores, usar programação textual para construir sua
aplicação. O único sistema de baixo custo que tem recurso de interface de
programação icônica é o Handy Cricket que usa LogoBlocks desenvolvido no Media
Lab do MIT (Begel, 1996). A Gogoboard funciona com a funcionalidade reduzida com
o LogoBlocks do Cricket (Figura 3). Até onde os autores estão informados, não se
conhece disponibilidade de interface aberta de programação icônica para robótica
pedagógica. Esta disponibilidade é importante, desde que toda evolução da unidade
de controle requer mudan-ças na interface de programação icônica.
A Gogoboard usa a Linguagem Logo para programação, entretanto através de
uma programação textual.
2.1 Vialização do Código Fonte do LogoBocks
A Gogoboard é diferente do handy-cricket por possuir um número maior de
entradas e a possibilidade de acionamento de um número maior de motores, sendo
necessário a disponibilidade do código fonte do LogoBlocks para realizar as
adequações.
Foram feitos buscas do código fonte do LogoBlocks, não se encontrando
alternativas. Também foi solicitado ao desenvolvedor da Gogoboard a adequação do
LogoBlocks e este também não respondeu positivamente.
A solução encontrada foi realizar a Engenharia reversa do programa do
LogoBlocks, vista este ser em Java e pela existência de vários programas que
realizam a engenharia reversa do programas objeto Java.
Foram obtidas várias alternativas, a primeira chamada de mocha
(http://www.brouhaha.com/~eric/software/mocha/), que gerou código fonte java da
maioria dos módulos, entretanto, esse software falhava para alguns módulos.
- 35 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
Após uma pesquisa mais detalhada obteve-se o programa JAD
(http://www.kpdus.com/jad.html). Este programa descompilou todos os módulos dos
pacotes do LogoBlocks. Permitindo assim a possibilidade de estudar e conhecer os
detalhes do LogoBlocks para a sua adequação a Gogoboard. A Figura 4 mostra um
extrato de um módulo do LogoBlocks.
public synchronized class LogoBlocks extends Frame implements ActionListener
{
public static Vector configs;
public static Properties selectedConfig;
public static void main(String astring[])
{
configs = Configuration.loadConfigs();
selectedConfig = (Properties)configs.firstElement();
String string1 = selectedConfig.getProperty("primList");
int i1 = Integer.parseInt(selectedConfig.getProperty("codeStart"), 16);
int j1 = Integer.parseInt(selectedConfig.getProperty("codeEnd"), 16);
int k = i1;
int i2 = j1;
boolean flag = false;
if (selectedConfig.getProperty("codeFollowsArrays").equals("true"))
flag = true;
if (flag == 0)
{
k = Integer.parseInt(selectedConfig.getProperty("arrayStart"), 16);
i2 = Integer.parseInt(selectedConfig.getProperty("arrayEnd"), 16);
}
int j2 = Integer.parseInt(selectedConfig.getProperty("menuVector"), 16);
String string2 = "hc15.lib";
BlueCricketCompiler.initialize(string1, i1, j1, k, i2, flag, j2, string2);
SyntaxChecker.initialize(string1);
LogoBlocks logoBlocks = new LogoBlocks("Untitled - Logo Blocks");
logoBlocks.setResizable(true);
LogoBlocksApplet logoBlocksApplet = new LogoBlocksApplet();
logoBlocksApplet.runApplication(logoBlocks);
logoBlocks.add(logoBlocksApplet, "Center");
logoBlocks.addNotify();
logoBlocksApplet.init();
logoBlocksApplet.start();
logoBlocks.setVisible(true);
}
Figura 4: Extrato do código de um módulo do LogoBlocks
Após o processo de Engenharia Reversa o código foi compilado e executado,
garantindo assim que se obteve um código fonte confiável do LogoBlocks.
2.2 Estudo do Código Fonte do LogoBlocks
Foi necessário estudar o código fonte do LogoBlocjs, para se localizar as classes
que requereriam modificação. Localizadas, foi feita alem de alteração a geração de
uma versão em Português. e uma versão adequada a Gogoboard. A Figura 5 mostra a
interface do LogBlocks em Português, bem como a sua compatibilização com a
GogoBoard.
Considerando que o código fonte da GogoBoard ser um código proprietário,
decidiu-se que este seria utilizado para uso interno da DRVC em aplicações em
robótica pedagógica de baixo custo.
- 36 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
Figura 5: LogoBlocks em Português e adequada à GogoBoard
2.3 Evolução da LogoBlocks
Tendo em vista a quase impossibilidade da execução do código fonte nós
computadores de baixíssimo custo do programa UCA, o conhecimento adquirido pelo
estudo do código Java do LogoBlocks, está sendo utilizado para o desenvolvimento de
uma versão aberta desse, capaz de ser executado num computador do UCA, objeto
de algumas programa PIBICs para o período 2007-2008.
Foi necessário estudar o código fonte do LogoBlocjs, para se localizar as classes
que requereriam modificação. Localizadas estas, foram feitas alem de alteração a
geração de uma versão em Português foi desenvolvida uma versão adequada a
Gogoboard. A Figura 5 mostra a interface do LogoBlocks em Português, na a sua
direita aparece um exemplo da adequção a Gogoboard, pela inclusão de um número
maior de motores (quatro) para seleção.
3. Conclusões
Apresentou-se as atividades desenvolvidas para se viabilizar um ambiente de
programção iconica similar ao LogoBlocks em Portugues, que propocionou o
conhecimento necessário para o futuro desenvolvimento de um sistema similar em
código aberto.
Referências
Josué j. G. Ramos, Othon r. Neves jr, João v. V. D’Abreu, Douglas Figueiredo Lucas
tanure, Felipe Holanda, Helio Azevedo; “Iniciativa Para Robótica Pedagógica Aberta
E De Baixo Custo Para Inclusão Social E Digital No Brasil”< SBAI 2007
Sipitakiat, A., Blikstein, P. & Cavallo, D. GoGo Board: Augmenting Programmable
Bricks for Economically Challenged Audiences, In Proceedings of the International
Conference of the Learning Sciences (ICLS 2004), Los Angeles, USA, 2004
Begel,Andrew, A Graphical Programming Language for Interacting with the World
http://research.microsoft.com/~abegel/mit/begel-aup.pdf, 1996.
- 37 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
XMLIpthru: Infra-estrutura de Suporte para o REAL WebLab
Henrique Nakashima; Fernando Paolieri Neto; Eliane Gomes Guimarães
Centro de Pesquisas Renato Archer - CenPRA
Departamento de Robótica e Visão Computacional - DRVC
Rod. D. Pedro I, Km 143,6
13069-901 Campinas SP
[email protected];[email protected];
[email protected]
Resumo
Este artigo apresenta o trabalho desenvolvido pelos alunos no contexto do
Laboratório de Acesso Remoto (REAL), especificamente no
desenvolvimento de uma infra-estrutura que provê uma API numa
linguagem neutra, independente de tecnologia, para o controle dos robôs
disponíveis no projeto.
Palavras chave: Telerobótica, Laboratórios de Acesso Remoto, WebLabs, Sistemas
Multimídia Distribuídos.
1. Introdução
O trabalho apresentado neste artigo foi realizado no contexto do projeto REAL
(Remotely Accessible Laboratory) [1][2]. Laboratórios de Acesso Remoto (LARs)
permitem a execução de atividades experimentais entre múltiplas instituições
geograficamente dispersas por meio de redes de comunicação avançadas. No
domínio de aplicações multimídia distribuídas, os laboratórios de acesso remoto,
despertam interesse especial. LARs proporcionam um mecanismo de interação que
permite aos usuários remotos utilizar os recursos do laboratório através de uma rede
de computadores. Deste modo, LARs permitem o acesso a materiais educacionais e
laboratoriais existentes em locais distintos, muitas vezes distantes daquele onde
encontra-se o usuário que os acessa. Os usuários podem planejar, executar, testar e
validar experimentos práticos remotamente, além de coletar dados experimentais para
análise e processamento a posteriori.
Dependendo dos tipos de experimentos a
serem suportados, estes laboratórios devem prover algum mecanismo de telepresença para “transportar” o usuário para o laboratório. Por exemplo, na área de
robótica, um laboratório de acesso remoto deve possibilitar que um usuário observe o
robô durante uma missão por ele submetida. Isto pode ser proporcionado ao usuário,
em seu ambiente computacional, através de canais de vídeo (caso necessário,
também de áudio) para a visualização de imagens de vídeo, mapas bidimensionais ou
uma combinação destes. Para permitir esta “imersão” de usuários remotos em um
laboratório físico, esta classe de aplicações demanda redes de alta velocidade e
comunicação multimídia com facilidades de qualidade de serviço.
Este artigo apresenta as atividades realizadas pelos alunos, mais
especificamente o desenvolvimento de uma intra-estrutura de suporte ao REAL
WebLab usando tecnologias do paradigma de sistemas distribuídos, utilizando uma
linguagem neutra para a comunicação com outras aplicações.
- 38 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
2. Infra-estrutura do Laboratório
Primeiramente, descreveremos as bases necessárias para a criação de
experimentos para o Laboratório de Acesso Remoto: infra-estrutura de hardware e
infra-estrutura de software.
A construção do ambiente do laboratório de acesso remoto demanda a aquisição
de alguns componentes de hardware, entre eles: Net Câmeras, servidores, redes sem
fio (IEEE 802,11g), rede Gigabit local e robôs móveis. As Net Câmeras são
necessárias para visualizar o local dos experimentos e as ações promovidas pelo
robô. Servidores e redes sem fio e local, permitem estabelecer a comunicação remota
entre os robôs e os usuários fisicamente ausentes.
Por fim, o elemento principal é a presença dos robôs móveis. O modelo utilizado
em nossos experimentos é o modelo Pioneer P3-DX8 da ActivMedia Robots. Este
robô dispõe de rodas com motores independentes, sonares para detecção de
obstáculos, bumpers para que, no caso do robô colidir com um obstáculo, seus
motores serem desativados a fim de evitar danos a ele, e uma câmera de bordo com
pan, tilt e zoom.
Os robôs Pioneer P3-DX possuem uma biblioteca nativa em C++ totalmente
orientada a objetos: ARIA (Advanced Robotics Interface for Applications) [3]. A
biblioteca ARIA controla de maneira dinâmica a velocidade, direcionamento do robô e
outras funções de navegação.
3. Motivação para o Desenvolvimento do XMLIpthru
Ao longo do desenvolvimento do projeto, foram encontradas certas dificuldades
na utilização da biblioteca ARIA, que controla o robô a alto nível. Sua versão na
linguagem C++ é a principal, suportando todas as diversas funcionalidades da
biblioteca. Por praticidade e maior facilidade de desenvolvimento, a versão em Java,
ligeiramente mais limitada, foi testada, mas alguns bugs da própria biblioteca
desmotivaram a sua utilização.
Percebeu-se, com isso, que uma API (Application Programming Interface) que
suportasse requisições de um cliente escrito em Java e traduzisse estas requisições
para C++ ajudaria a solucionar este problema. Para generalizar o processo, seria
interessante que ele se comunicasse com o cliente não em Java, mas em algum
formato independente de linguagem. Esta aplicação seria o XMLIpthru.
Visando sempre a modularização e um nível mínimo de acoplamento, a
linguagem XML (Extensible Markup Language) [4] foi definida como a linguagem de
comunicação do XMLIpthru, que pode ser interpretada por programas em qualquer
outra linguagem, permitindo que o código dos experimentos, scripts de teste ou Web
Services fosse escrito não apenas em Java, mas em qualquer linguagem.
4. Desenvolvimento da Aplicação
O XMLIpthru foi escrito em C++, pois utiliza a versão da ARIA nesta mesma
linguagem. Ele é uma aplicação servidor que roda no próprio robô, ou numa máquina
conectada por porta serial a ele, que recebe requisições do cliente no formato XML,
por meio de sockets UDP (User Datagram Protocol), como visto na figura 1. Ele
processa e gerencia estas requisições, controla o robô com base nela (geralmente
operações para o robô executar, tanto operações de movimentação, como de
informação, gerenciamento da câmera e utilização de ações), e retorna ao cliente uma
resposta para cada requisição, também no formato XML.
- 39 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
A aplicação é composta por três threads concorrentes: a server thread, a work
thread e a protection thread. A server thread tem a tarefa de receber mensagens XML
por socket UDP, interpretá-las, montando um objeto Work com suas informações e
colocá-la uma fila de prioridades. A work thread consome a fila de Works executando
cada um deles em sequência e mandando uma resposta para o cliente que solicitou a
operação. A protection thread funciona independente das duas outras, e impede que o
robô colida com obstáculo fazendo checagens periódicas de seus sonares e parando
os motores no caso de colisão iminente.
No projeto REAL, o XMLIpthru é uma interface entre os Web Services (em Java)
e a biblioteca de controle do robô ARIA (em C++). A figura 2 ilustra o sistema de
controle do robô do WebLab em que o XMLIpthru está inserido. Quando o usuário dá
um comando ao robô pela interface de navegação no topo esquerdo da figura, este
comando é repassado ao Web Service (localizado no servidor do laboratório), que por
sua vez converte o comando numa mensagem XML e transmite ao XMLIpthru, que
recebe a requisição e faz uma chamada à biblioteca ARIA, que faz a comunicação
direta com o robô por porta serial.
Figura 1: Troca de mensagens entre o computador de controle e o robô.
5. Conclusão
O desenvolvimento de uma camada extra de abstração na infra-estrutura do
REAL WebLab aumenta a modularização do sistema, facilitando o desenvolvimento e
manutenção do sistema como um todo, e permitindo que as camadas superiores não
se preocupem com detalhes de implementação, que cabem às camadas inferiores.
Além dos ganhos para o laboratório, os alunos tiveram contato com tecnologias
atuais e com o desenvolvimento de aplicações para fins práticos, o que representa um
grande ganho pessoal, acrescentando uma sólida experiência às suas formações.
Agradecimentos
Esse projeto de Iniciação Científica teve o suporte do CNPq/PIBIC. Os autores
são gratos ao CenPRA, que foi a instituição onde o trabalho foi desenvolvido, à Dra.
Eliane G. Guimarães (DRVC/CenPRA) pela orientação e ao Prof. Dr. Eleri Cardozo
(FEEC/UNICAMP) pela co-orientação.
- 40 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
Figura 2: Diagrama de controle do robô no WebLab
Referências
[1]Guimarães, E., et.all. “REAL: A Virtual Laboratory for Mobile Robot Experiments”,
IEEE Transactions on Education, February 2003, Volume 46(1).
[2]Coelho, P., Sassi, R., Cardozo, E., Guimarães, E., Faina. L., Lima, A., Pinto, R. “A
Web Lab for Mobile Robotics Education”. In proceeding of the IEEE International
Conference on Robotics and Automation (ICRA 07), Roma, Italy – 2007.
[3] Advanced
Robotics
Interface
for
Applications
http://www.activrobots.com/SOFTWARE/aria.html – 2007.
[4] Extensible Markup Language - http://www.w3.org/XML/ - 2007.
- 41 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
Ferramenta de Validação do Ambiente do Usuário para Execução no
GigaBOT WebLab
Gustavo Toshihide Uehara; Eliane Gomes Guimarães
Centro de Pesquisas Renato Archer - CenPRA
Divisão de Robótica e Visão Computacional - DRVC
Rod. D. Pedro I, Km 143,6
13069-901 Campinas SP
[email protected]; [email protected]
Resumo
Este documento apresenta o trabalho desenvolvido pelo aluno no contexto
do projeto GigaBOT WebLab, um dos laboratórios do REAL(Remotely
Accessible Laboratory), mais especificamente no desenvolvimento de uma
ferramenta de infra-estrutura de apoio para auxiliar os usuários a verificar e
configurar seus ambientes para poderem executar adequadamente os
experimentos do GigaBOT.
Palavras chave: Laboratórios de Acesso Remoto, Web Labs, Sistemas Multimídia
Distribuídos, Telerobótica.
1. Introdução
Este trabalho foi realizado no contexto do projeto GigaBOT WebLab[1], um dos
laboratórios do REAL (Remotely Accessible Laboratory)[2]. Laboratórios de Acesso
Remoto (LAR), ou Web Labs, têm sido propostos como poderosas ferramentas de
suporte ao ensino, tanto presencial quanto à distância. O maior desafio na
implementação de Web Labs é prover uma infra-estrutura onde experimentos possam
ser incorporados e alterados com facilidade, bem como acessados e controlados
remotamente. Com o crescente avanço na área de redes e infra-estrutura, os LARs
vem se tornando cada vez mais interessantes, podendo oferecer serviços cada vez
mais complexos, destacando-se a transmissão de áudio e vídeo em tempo real e o
gerenciamento de múltiplos serviços simultâneos. O GigaBOT é, basicamente, um
laboratório de acesso remoto para o ensino de robótica móvel, permitindo que o robô
(modelo Pioneer 3-DX, ou P3-DX da fabricante MobileRobots/ActivMedia) seja
manipulado remotamente através da internet utilizando, principalmente, uma
combinação de tecnologia Java e Serviços Web. Para possibilitar o controle remoto do
robô, o usuário conta com a visão de duas câmeras. A primeira se encontra fixada em
cima do robô e outra em algum local estratégico, geralmente um ponto elevado, para
dar uma visão panorâmica do cenário. Além disso, o usuário tem acesso a
informações de telemetria captadas pelos sensores de distância (sonares) do robô,
permitindo um mapeamento da região ao redor do mesmo. Todas essas informações
estão contidas numa interface comum, como pode ser visto na figura 1. Assim, com
essas informações, o usuário é capaz de manipular o robô como se estivesse no local,
tendo acesso a simples movimentações de translação e rotação além de opções mais
avançadas, como a execução de algoritmos de navegação pré-definidos e a
navegação orientada por comportamentos (behaviors).
Neste artigo é apresentada uma ferramenta de infra-estrutura de apoio capaz de
auxiliar os usuários a verificar e configurar seus ambientes para poderem executar
- 42 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
adequadamente os experimentos do GigaBOT. Essa necessidade surgiu quando, na
prática, alguns usuários não foram capazes de utilizar os experimentos devido ao fato
de não ter um ambiente devidamente configurado.
Figura 1 – Modo Básico de Controle
2. Desenvolvimento da Ferramenta
A solução encontrada para resolver o problema foi o desenvolvimento de uma
página de internet que faz a verificação do ambiente e fornece ajuda para
configuração, caso necessário. A grande vantagem de se utilizar uma página de
internet é a não necessidade de se instalar software adicional além de um simples
navegador, programa que na maioria dos casos já se encontra instalado e, caso não
esteja, pode ser facilmente obtido na internet. Com relação à compatibilidade, a página
foi desenvolvida dando suporte para os dois principais navegadores do mercado, o
Internet Explorer e o Firefox, tanto no Windows XP como no Linux. Outros
navegadores também podem ser compatíveis mas não possuem suporte nos tópicos
de ajuda.
No desenvolvimento da página utilizou-se uma série de tecnologias e recursos
Web atualmente disponíveis: XHTML, Javascript, CSS, DOM (Document Object
Model) e JSP (JavaServer Pages) que juntos possibilitam a criação de uma pagina
DHTML (Dynamic HTML), ou seja, uma página capaz de alterar sua apresentação e
interagir com o usuário. Um dos pontos no qual houve ênfase foi o design. Foram
desenvolvidas diversas versões da página até se obter uma que fosse bem amigável e
intuitiva, para que usuários leigos tenham o mínimo de dificuldades em utilizá-la.
Foram implementados no total 10 testes, alguns automatizados e outros que
necessitam da ação do usuário para fazer a confirmação visual. Os testes
implementados foram:
- 43 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
- Javascript: Verifica se o navegador está com o javascript habilitado.
- Navegador: Verifica se o navegador utilizado é suportado pelo projeto.
- Sistema Operacional: Verifica se o sistema operacional é compatível.
- Form: Verifica se o navegador está com o método POST habilitado.
- Resolução: Verifica se o monitor está com uma resolução adequada.
- Cookie: Verifica se a função de cookies esta ligada.
- Java: Verifica se o navegador possui o Java instalado.
- JWS (Java Web Start): Verifica se o navegador possui suporte a JWS.
- Vídeo: Verifica se o navegador é capaz de reproduzir vídeos, mais
especificamente, de extensão avi.
- Câmera: Verifica se o navegador é capaz de exibir a interface de câmera do
robô.
3. Uso da Ferramenta
Ao se acessar a página de testes, pode-se notar 3 áreas distintas na interface,
conforme a figura 2:
- Área central, que contêm a descrição do teste e, se necessário, as instruções
para se realizar o mesmo. Nela também se encontra o resultado esperado do teste,
que deve ser usado para comparação com o resultado do teste.
- Área inferior, que contêm botões para obter ajuda, refazer e continuar. Caso o
resultado do teste seja igual ao resultado esperado, deve-se clicar no botão
“Continuar” para se prosseguir com os testes. Caso contrário, deve-se clicar no botão
“Ajuda”, que irá carregar as informações para ajuda de configuração. Vale lembrar que
no caso de testes automatizados, se o teste foi bem sucedido, o botão de ajuda
permanece oculto. Por fim, a qualquer momento o teste pode ser refeito, clicando-se
no botão “Refazer”.
- Área à esquerda, que contêm alguns links para navegação na página e os
resultados dos testes.
Podem haver 3 possíveis resultados para os testes :
- Aprovado, representado pelo símbolo :
- Reprovado, representado pelo símbolo :
- Indefinido, representado pelo símbolo :
Logo, se ao final dos testes todos eles estiverem com o status "Aprovado", o
ambiente é considerado apto para executar os experimentos do GigaBOT WebLab.
- 44 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
Figura 2 – Teste de Cookie
4. Conclusão
A ferramenta foi desenvolvida e implantada com sucesso no projeto GigaBOT,
podendo, no futuro, receber novos testes e modificações facilmente, adequando-se às
constantes melhoras no projeto. Por fim, espera-se que com a utilização desta
ferramenta mais usuários possam executar os experimentos do GigaBOT de forma
adequada, minimizando a necessidade de suporte técnico individual.
Agradecimentos
Esse projeto de Iniciação Científica teve o suporte do CNPq/PIBIC. Os autores
são gratos ao CenPRA, que foi a instituição onde o trabalho foi desenvolvido, à Dra.
Eliane G. Guimarães (CenPRA) pela orientação e ao Prof. Dr. Eleri Cardozo
(FEEC/UNICAMP) pela co-orientação, pois muito contribuíram para a realização desse
projeto.
Referências
[1] Coelho, P., Sassi, R., Cardozo, E., Guimarães, E., Faina. L., Lima, A., Pinto, R. A
Web Lab for Mobile Robotics Education. In proceeding of the IEEE International
Conference on Robotics and Automation (ICRA 07), Roma, Italy – 2007.
[2] Guimarães, E. Gomes; REAL: A Virtual Laboratory for Mobile Robot Experiments;
IEEE Transactions on Education, February 2003, Volume 46(1).
- 45 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
Preparação de filmes finos de SnO2 dopados com Níquel pelo método
dos precursores polimércos
Gustavo B. Rossi1; Aline P. Costa1; Elaine F. Z. A. Von-Zuben2, Talita Mazon1; Márcio
T. Biasoli1
Centro de Pesquisas Renato Archer - CenPRA
1- Divisão de Empacotamento Eletrônico 2- Divisão de Micro-Sistemas
Rod. D. Pedro I, Km 143,6 13069-901 Campinas SP
{gbrossi; aline.costa; elaine.von-zuben; talita.anselmo; marcio.biasoli}@cenpra.gov.br
Resumo
Durante as últimas décadas, a indústria eletrônica tem sofrido uma
mudança drástica devido, principalmente, à miniaturização dos
componentes eletrônicos. Por isso, nanomateriais têm sido um tópico de
grande interesse no desenvolvimento de nanodispositivos eletrônicos de
alta capacidade. A obtenção de filmes finos homogêneos e com controle
da microestrutura (tamanho da partícula e morfologia) é muito importante
para desenvolver novos materiais com melhores propriedades funcionais.
Por isso, o objetivo deste trabalho foi preparar filmes finos de SnO2 puro e
dopado a 2 e 7 mol% de Níquel utilizando o método dos precursores
poliméricos. Para isso, foram preparadas soluções de citrato de estanho e
níquel. Após a preparação das soluções precursoras, quantidades
equivalentes das soluções foram pesadas e misturadas sob aquecimento e
agitação para promover a quelação dos cátions. Estas soluções foram
utilizadas para preparar filmes finos sobre substratos de Si por spin
coating. Os filmes obtidos foram pré-tratados a 120oC, tratados
termicamente a 800ºC e caracterizados quanto a microestrutura por
microscopia óptica com a finalidade de verificar a influência da
concentração das soluções precursoras e limpeza dos substrato na
obtenção de filmes com superfície homogênea e lisa.
1. Introdução
Durante as últimas décadas, a indústria eletrônica tem sofrido uma mudança
drástica devido, principalmente, à miniaturização dos componentes eletrônicos.
Circuitos inteiros aparecem milhares de vezes menores que um simples componente
de um circuito antigo.
Com essa miniaturização, novos materiais estão sendo alvos de pesquisas em
todo o mundo para o desenvolvimento de nanodispositivos eletrônicos de alta
qualidade. Por isso, é de fundamental importância um controle do tamanho, da
morfologia, da adição de dopantes, bem como da influência da temperatura de
tratamento térmico na obtenção desses novos nanomateriais.
Dentre estes novos nanomateriais, o óxido de estanho (SnO2) tem sido bastante
estudado por apresentar excelentes propriedades elétricas e ópticas, as quais
permitem que ele seja utilizado em inúmeras aplicações: como eletrodos em células
solares, sensores de gás, eletrodos condutivos transparentes, dispositivo de display,
entre outras. Sabe-se que as propriedades elétricas e ópticas deste material podem
ser modificadas pela adição de dopantes. Por isso, visando melhorar estas
propriedades, o SnO2 tem sido dopado, até o presente momento, com elementos da
tabela periódica do grupo III, V, VI ou VII, tais como: In, Ti, P, As, Sb, Te, F, Cl, Br e I.
Recentemente, SnO2 dopado com metais de transição-3d tem atraído bastante
- 46 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
atenção por apresentar algumas propriedades magnéticas importantes. A presença de
um íon magnético em um composto semicondutor conduz a um número de novas
propriedades ópticas e eletrônicas, tais como absorção óptica d-d devido à forte
interação coulomb entre os elétrons 3-d e a banda gap modificada pela hibridização
sp-d. Entretanto, não existe artigos que relatam a preparação, bem como as
propriedades elétricas e ópticas de filmes finos de SnO2 dopados com níquel (Ni).
Uma grande variedade de métodos para preparar filmes finos pode ser
encontrada na literatura. Dentre eles, destacam-se os métodos químicos em fase
líquida, em especial o método dos precursores poliméricos (Método de Pechini), pois
consegue-se obter materiais nanoestruturados com controle da estequiometria e da
microestrutura.
2. Objetivo
O objetivo deste trabalho foi preparar filmes finos de óxido de estanho dopado
com 2, 5 e 7 mol% de níquel pelo método dos precursores poliméricos e deposição por
spin-coating.
3. Metodologia
Inicialmente foram preparadas e padronizadas as soluções de citrato de
estanho e níquel utilizando o método dos precursores poliméricos. Em seguida,
adicionou-se à solução de citrato de estanho, quantidades apropriadas da solução de
níquel nas proporções de 2 e 7 mol% (dopagem). A solução final foi, então,
concentrada sob agitação e aquecimento a 200ºC. Após a concentração, a solução foi
dividida em duas partes: primeiramente, a solução concentrada foi submetida a um
processo de calcinação, em diferentes patamares de temperatura: 400ºC / 4h e a
800ºC / 4h. O pó obtido após a calcinação foi triturado em almofariz e analisado por
difração de Raios X, com a finalidade de observar a formação de fases secundárias.
Em uma segunda etapa, a solução concentrada foi utilizada para a preparação de
filmes finos em substrato de silílio por “spin coating”. Com a finalidade de obter filmes
finos homogêneos e com boa adesão ao substrato, os seguintes parâmetros foram
alterados durante a deposição: velocidade de rotação (2000 e 3000 rpm);
concentração iônica da solução (0,6 e 0,1 M) e metodologia de limpeza dos
substratos. Após a deposição, os filmes foram pré-tratados em “hot plate” a 120 oC por
15 minutos, para favorecer a evaporação dos solventes e, em seguida, tratados
termicamente a 800 oC por 4 horas para a formação da fase cristalina. Os filmes
obtidos foram caracterizados por Microscopia Óptica e Análises de Rugosidade com a
finalidade de verificar a influência da concentração das soluções precursoras e
limpeza dos substrato na obtenção de filmes com superfície homogênea e lisa.
4. Resultados
Os difratogramas de Raios X obtidos para os pós puro e dopados com 2 e 7
mol% são apresentados na Figura 1.
Como pode-se notar, nos difratogramas da Figura 1, não houve a formação de
fases secundárias indicando uma boa formação da fase cristalina SnO2 em todas as
amostras.
As fotos obtidas dos filmes depositados por spin-coating em diferentes condições
estão apresentadas nas Figuras 2 e 3.
Observa-se, na Figura 2, que nos filmes preparados inicialmente por spin-coating
a 3000 rpm, as soluções precursoras não ficaram bem aderidas ao substrato. Isto se
deve, provavelmente, a dois fatores: a existência de uma camada de Óxido de Silício
- 47 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
(SiO2) na superfície do substrato, o que sugere que o procedimento de lavagem dos
substratos deve ser modificado; ou que às características da soluções (alta
concentração iônica, viscosidade, etc) não devem estar adequadas.
(a) SnO2 puro
(b) SnO2 + 2 mol% Ni
(c) SnO2 + 7 mol%
Ni
Figura 1: Difratogramas obtidos por DRX do: a) Óxido de Estanho puro b) Óxido de Estanho
dopado com 2 mol% de Níquel c) Óxido de Estanho dopado com 7 mol% de Níquel.
(a)
(b)
Figura 2: Filmes finos de SnO2 dopados com 2 e 7 mol% de Ni depositados em substratos de
Si lavados por diferentes metodologias: a) extran e água; b) extran, água e tratamento com HF.
Após a primeira modificação no procedimento de lavagem do substrato, a qual
consistiu em realizar um tratamento com Ácido Fluorídrico (HF) diluído na etapa final,
foram realizadas novas deposições e as fotos dos filmes obtidos estão apresentadas
na Figura 2.b. Pode-se notar, Fig. 2.b, que a solução novamente não ficou bem
aderida ao substrato. Por isso, resolveu-se padronizar estas soluções por gravimetria
para determinar a concentração iônica das mesmas.
Determinou-se que a concentração iônica inicial estava em torno de 0,6 M.
Sabe-se que em altas concentrações iônicas, os íons metálicos não estão
uniformemente distribuídos na matriz polimérica e como conseqüência os grãos não
crescem uniformemente e trincas surgem na superfície dos filmes. Por isso, as
soluções foram diluídas em Etilenoglicol a fim de se obter uma concentração de 0,1M.
Em seguida, novas deposições foram realizadas e as fotos dos filmes obtidos estão
apresentadas na Figura 3.
Podemos notar que o filme obtido a partir da solução diluída em Etilenoglicol e
com velocidade de rotação de 3000 rpm apresentou melhor aderência ao substrato.
Por isso, foi realizada a diluição das outras soluções a fim de obter concentração
iônica 0,1 M e as deposições foram feitas com velocidade de rotação de 3000 rpm.
Este filme foi tratado termicamente a 800 oC e caracterizado por interferometria com
escaneamento de luz branca, a fim caracterizá-lo quanto a microestrutura e medidas
de rugosidade. Os resultados são apresentados na Figura 4. Observa-se que o filme
obtido apresenta microestrutura nanocristalina com rugosidade da ordem de 4,3 nm.
Também pode-se observar a presença de defeitos na superfície dos filmes devido à
baixa adesão da solução em determinados pontos do substratos. Nova metodologia de
- 48 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
lavagem do substrato está sendo desenvolvida visando minimizar estes defeitos.
(b
(a)
(c)
(d)
Figura 3: Filmes finos de SnO2 dopados com Níquel a 2 mol% depositados em substratos de
Si tratados com HF: a) solução diluída em água e depositada a 3000 rpm; b) solução diluída
em Etilenoglicol depositada a 3000 rpm; c) solução diluída em água e depositada a 2000 rpm;
d) solução diluída em Etilenoglicol depositada a 2000 rpm.
Figura 4: Imagem obtida por interferometria com escaneamento de luz branca do filme de
SnO2 dopado com 2 mol% de Ni.
5. Conclusão
É possível preparar pós de SnO2 dopados com até 7 mol% de Ni pelo método
dos precursores poliméricos sem a presença defases secundárias.. A metodologia
para a lavagem dos substratos de Si e a concentração iônica das soluções
influenciaram na obtenção de filmes finos com superfície homogênea. Filmes finos
nanocristalinos de SnO2 dopados com 2 mol% de Ni foram depositados por spincoating sobre substratos de Si tratados com HF utilizando soluções precursoras com
concentração 0,1 M.
Agradecimentos
Os autores agradecem ao CNPq pelo auxílio financeiro, ao CenPRA e a todos
que colaboraram na elaboração do trabalho, em especial aos servidores da Divisão de
Micro-Sistemas.
Referências
[1] PANCHAPAKESAN, B., CAVICCHI, R., SEMANCIK, S., DEVOE, D.L.,
Nanotechnology, v. 17, n. 2, 2006.
[2] ZHAO, Q. R., GAO, Y., BAI, X., WU, C. Z., XIE, C. Z., European Journal of
Inorganic Chemistry, v. 8, p. 1643-1648, 2006.
[3] RAO, T. R. “Fundamentals of Microsystem Packaging”, McGraw Hill, International
Edition, 2001.
[4] LIONG, S., WONG, C. P., BURGOYNE, W. F., IEEE – Electronics componets and
technology Conference, p. 1140-1146, 2002.
[5] GU, F., WANG, S. F., SONG, C. F., LU, M. K., QI, Y. X., ZHOU, G. L., XU, D., YAN,
D. R., Chem. Phys. Lett., v. 372, p. 451, 2003
[6] HWANG, J. S. “Environment – friendly electronics lead-free technology”,
Electrochemical Publications LTD, Inglaterra, 2001.
- 49 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
Desenvolvimento de um Sistema de Visão Omnidirecional aplicado ao
monitoramento de robôs móveis.
Igor A. Dias; Sidney P. Cunha; Artemis Moroni
Centro de Pesquisas Renato Archer - CenPRA
Divisão de Robótica e Visão Computacional
Rod. D. Pedro I, Km 143,6 CEP-13069-90, Campinas SP
[email protected]; {sidney.cunha, artemis.moroni}@cenpra.gov.br
Resumo
Este trabalho tem como objetivo a elaboração de um sistema de visão
omnidirecional composto de câmera de vídeo conectada a um PC e de um
espelho esférico. O sistema será utilizado para localização de robôs em
seu plano de deslocamento através do processamento de imagens em
tempo real do ambiente monitorado. Tais informações serão utilizadas para
a realimentação do sistema de controle do robô.
Palavras chave: Robótica, Visão Computacional, Sistema de Visão Omnidirecional
1. Introdução
Robôs móveis devem possuir a capacidade de realizar tarefas com o máximo de
autonomia possível. Para que isso seja possível vem sendo desenvolvido um sistema
de visão omnidirecional, ou um sistema de visão que produz imagens 360º do
ambiente, a fim de monitorar o ambiente no qual o robô está inserido e obter o maior
número possível de informações sobre o mesmo (Grassi; 2002).
Nesse contexto, o processamento das imagens será realizado automaticamente
através de sistemas computacionais. Dessa forma se torna mais eficiente trabalhar
com a própria imagem distorcida, utilizando um mapeamento que correlaciona um
ponto da imagem a um ponto no mundo real, sem que seja necessária a retificação da
imagem.
Para localizar o objeto de interesse na imagem, utilizaremos marcas que tornam
essa tarefa mais simples e barata do ponto de vista computacional, visto que o
processamento das imagens deve ocorrer em tempo real e um sistema lento tornaria
os resultados inválidos. Assim, obtemos o ponto desejado de maneira rápida e eficaz.
A seguir, é apresentado o mapeamento utilizado para correlacionar pontos da
imagem omnidirecional com pontos do mundo real. A seção 3 apresenta o
processamento utilizado para a localização do objeto de interesse no plano da
imagem. Por fim, a seção 4 discute os resultados e apresenta as conclusões do
experimento realizado.
2. Mapeamento Imagem-Mundo Real
Um sistema de visão omnidirecional vem sendo desenvolvido afim de monitorar
um ambiente no qual estão inseridos robôs previamente programados que devem
realizar tarefas, como o deslocamento entre pontos pré-determinados, ou trajetórias
específicas. Esse sistema deve ser capaz de localizar os robôs no ambiente e auxiliar
para que nada ocorra fora do esperado. Construido a partir da combinação de lente e
espelho (catadióptrico), esse sistema de visão se faz muito útil para este fim, pois nos
- 50 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
permite obter uma imagem de todo o ambiente sem que seja necessária a
movimentação da câmera (Yagi; 1999). No entanto esse sistema requer um
processamento não convencional da imagem, uma vez que a imagem obtida possui
distorções devido ao uso de espelhos convexos. O sistema de visão montado e a
imagem gerada por ele está mostrado na Figura 1.
a)
b)
Figura 6. a) Sistema de visão omnidirecional montado , e b) imagem adquirida pela
câmera do sistema.
O primeiro experimento realizado teve por objetivo buscar uma correlação entre
medidas entre pixels na imagem obtida do ambiente e medidas no mundo real. Para
tanto foi realizado um estudo da toolbox desenvolvida para MATLAB (Davide
Scaramuzza; 2006). Essa toolbox gera como resultado uma função de mapeamento
polinomial da qual conseguimos obter um vetor no mundo real, a partir da localização
de um ponto em pixels na imagem (Martins; 2006). Conseguimos com esse resultado,
localizar um ponto no piso do ambiente a partir do ponto na imagem, o que se faz útil,
visto que o robô a ser monitorado não estará se movimentando em nenhuma outra
superfície se não o piso do espaço no qual ele está inserido.
O resultado da calibração do sistema de visão omnidirecional é apresentado na
Figura 2, e consiste da curva de distorção radial do espelho (a); de um exemplo de
imagem utilizado para calibração (b); da distribuição da reprojeção dos erros de cada
ponto realizado para calibração (c); e, por fim, da representação visual dos parâmetros
extrínsecos obtidos com a calibração (d).
3. Método de identificação do robô na imagem
A captura da imagem em tempo real do ambiente, assim como o processamento
dessa imagem e posterior identificação do objeto de interesse na mesma se faz muito
importante nesse contexto, já que podemos encontrar um ponto no mundo real a partir
de um ponto na imagem. Resta-nos então localizar esse ponto específico.
Tais etapas foram primeiramente desenvolvidas em MATLAB como teste,
quando foi decidido que para auxiliar a identificação do robô na imagem seriam
utilizados LEDs, a fim de termos pontos claros de destaque na imagem, o que torna
mais simples esse processo. Posteriormente foi desenvolvido um programa em C para
realizar essa função, com o auxílio da biblioteca de visão computacional OpenCV
(Open Source Computer Vision Library), originalmente desenvolvida pela Intel, que
possui como principal foco o processamento em tempo real de imagens.
- 51 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
a)
b)
c)
d)
Figura 7. a) Curva de distorção radial do espelho, b) Exemplo de imagem
utilizado para calibração com a reprojeção dos pontos, c) Distribuição da reprojeção
dos erros de cada ponto realizado para calibração, d) Representação visual dos
parâmetros extrinsicos.
A aquisição da imagem da câmera em tempo real é realizada automaticamente
através da porta USB, utilizando algumas linhas de comando, onde a imagem
capturada da câmera em tempo real é armazenada em uma variável e pode então ser
processada com o auxílio de funções da biblioteca OpenCV.
Após a captura da imagem em tempo real são realizadas uma série de
operações, como: subtração de imagens, operações morfológicas e thresholding
(Gonzalez; 1987), com o objetivo de isolar na imagem apenas o objeto de interesse,
nesse caso o LED, para então, de uma maneira que o tempo de processamento seja
pequeno, ou seja, com um baixo custo computacional, localizar o robô na imagem,
como apresentado na Figura 3.
4. Resultados e Conclusões
Os resultados obtidos com o sistema aqui descrito geraram um erro médio de
0,17m numa área de aproximadamente 20m² com o espelho a 3m de altura.
Vem sendo desenvolvido ainda, a fim de melhorar os resultados aqui expostos,
um programa baseado em algoritmo genético, com o objetivo de aproximar a função
de mapeamento imagem-mundo-real, visando minimizar o erro.
- 52 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
a)
b)
c)
d)
e)
f)
Figura 8. a) Imagem capturada em tempo real, b) Imagem utilizada como fundo para
subtração, c) Imagem resultante da subtração e das operações de morfologia, d)
Imagem após thresholding, e) LED localizado em destaque e f) Posição real do LED
em cm.
Agradecimentos
Gostariamos de agradecer ao programa PIBIC/CNPq e ao CenPRA pela
oportunidade de desenvolver esse trabalho e à FAPESP, financiadora do projeto
AURAL(JP 05/56186-9), do qual este desenvolvimento faz parte.
Referências
Gonzalez, R.C. Woods, R.E. & Eddins, S.L. Digital Image Processing. Prentice-Hall.
Company, 1987.
Grassi Jr, V. “Sistema de visão omnidirecional aplicado ao controle de robôs móveis.”
Tese defendida na Engenharia Mecânica/USP orientada pelo professor Jun
Okamoto Jr., 2002. São Paulo, SP, 2002, Poli/USP.
Martins, I., Cunha, S., Moroni, A. “Modelagem Geométrica para Sistema de Visão
Omnidirecional” In: VIII JORNADA DE INICIAÇÃO CIENTIFICA DO CENPRA –
JICC’2006, 2006, Campinas. Anais da VIII Jornada de Iniciação Científica.
Editora do CenPRA, 2006, p. 56-59.
Scaramuzza, D., Martinelli, A. and Siegwart, R., "A Flexible Technique for Accurate
Omnidirectional Camera Calibration and Structure from Motion", in Proceedings
of IEEE International Conference of Vision Systems (ICVS'06), New York,
January 5-7, 2006.
Yagi, Y. “Omnidirecional sensing and its applications.” IEICE Transactions on
Information and Systems, 1999, Vol. E82-D, No. 3, p. 568-579.
- 53 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
Desenvolvimento de Plataforma Aberta para Robôs Didáticos: Aspectos
de Hardware
Lucas Aníbal Tanure Alves; Josué Jr. Guimarães Ramos.
Centro de Pesquisas Renato Archer - CenPRA
Divisão de Robótica e Visão Computacional
Rod. D. Pedro I, Km 143,6
13083-970 Campinas SP
{ latalves ; Josue.Ramos } @ cenpra.gov.br
Resumo
Este artigo apresenta as atividades realizadas que objetivam o
desenvolvimento de uma plataforma Aberta para Robôs Didáticos.
Fazendo referência aos aspectos de hardware.
Palavras chave - Robótica pedagógica, inclusão social, software e hardware aberto
para robôs.
1. Introdução
O objetivo dos kits de robôs didáticos é promover ao adolescente o contato com
uma série de tecnologias através de experimentos lúdicos. O principal representante
dessa categoria é o kit chamado Lego Mindstorms [1]. O grande problema desse
sistema numa realidade brasileira é o alto custo para esse sistema, na faixa de
R$500,00.
Por outro lado existem sistemas que disponibilizam esquemas do hardware, o
firmware e o ambiente de programação. Os maiores representantes deste sistema são
os sistemas Gogo Board [2] mostrado na Figura 9, Handy Cricket [3], mostrado na
Figura 10, que possui o Logo Blocks, um aplicativo para a programação da Cricket
utilizando uma linguagem gráfica, ambos desenvolvidos no MIT.
Figura 9: Placa Gogo do MIT e algumas aplicações desenvolvidas com esta.
- 54 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
Figura 10: Handy Cricket do MIT e algumas aplicações desenvolvidas com
esta.
Também se encontram sistemas vendidos no Brasil como em [5] que
disponibilizam kits para experimentos.
No inicio do deste projeto não se encontrava disponível um sistema
completamente aberto para experimentos em robótica didática. Neste sentido, o
objetivo do projeto de iniciação científica foi disponibilizar um sistema aberto baseado
nesses principais representantes, utilizando ao máximo a informação disponível sobre
esses.
2. Escolha de Plataforma:
O problema inicial foi a escolha da plataforma mais adequada para se seguir
como base. Analisando as plataformas já mencionas obtemos a seguinte tabela, (
Dados do início do projeto ) :
Projeto
Custo (US$) Hardware Aberto Software Aberto Fácil Uso
Gogo Board
$ 26,82
Sim
Não
Sim
Handy Cricket
$ 109,00
Não
Não
Não
Lego
$ 500,00
Não
Não
Sim
MindStorms
Como se pode perceber a melhor alternativa é o projeto Gogo Board. Além disto,
o projeto Gogo Board possui a melhor base de informações disponíveis. Com isso um
usuário pode realizar experimentos de forma mais fácil.
3 - Viabilização do sistema Gogo Board.
Nesta etapa o bolsista teve o objetivo de captar as informações contidas no site
do projeto. E a partir disto construir a placa de controle e um experimento que a utilize.
O processo de construção da placa evidenciou problemas na usabilidade do
sistema. Uma discussão sobre estes problemas será feita na parte sobre estudos de
alternativas para o hardware do sistema.
Entendimento das funcionalidades da placa: Foram realizados experimentos
para o entendimento das funções que a placa Gogo Board disponibiliza. Utilizando o
- 55 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
software que o projeto possui, Gogo Monitor, o bolsista realizou o controle de motores,
leitura de sensores, controle de sinais de luz e som emitidos pela placa.
Somando-se a experiência obtida o bolsista desenvolveu um carrinho capaz de
seguir uma trilha desenhada no chão.
4 - Elaboração de um experimento para o sistema Gogo Board
Utilizando os recursos disponíveis no projeto e material de baixo custo foi
desenvolvido um carrinho que identifica uma trilha (Branco e Preto) e a percorre.
A Figura 3 apresenta uma foto do carrinho.
Este carrinho utiliza um conjunto de dois sensores do tipo fototransistor e leds.
Estes sensores identificam as cores da trilha e desta forma o carrinho identifica a
trajetória a ser seguida.
Figura 3 : Foto do Carrinho Seguidor de Trilhas
5 - Estudos de alternativas para o hardware do sistema
Como já foi comentada, a construção da placa evidenciou problemas na
usabilidade do sistema. O primeiro deles é forma que é feita a conexão entre a placa
central e seus periféricos (motores, sensores e a placa de expansão) cria diversos
problemas durante os experimentos. O segundo esta na forma de parar uma rotina na
placa, pois não há como parar execução de instrução, a menos que se desligue a
placa.
Analisando-se estes problemas e suas possíveis soluções decidiu-se por alterar
o hardware da placa central. A nova placa contém novos conectores para os sensores,
os motores e a placa de expansão. O conector escolhido foi o RJ11, o mesmo das
conexões de telefone. Este conector possui duas grandes vantagens:
- Disponível no mercado a baixo custo;
- Não permite a inversão da conexão, ou seja, com este conector só há uma
forma de conectar o periférico a placa.
Quando a forma de se parar uma instrução foi adicionada a placa um botão que
interrompe as ações de seus periféricos. A Figura 4 mostra a estrutura de
componentes da placa original e do circuito modificado.
- 56 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
Figura 4: Esquemas de componentes, esquerda circuito antigo, direita circuito
novo.
6. Conclusões
Neste artigo apresentou-se o desenvolvimento de uma plataforma de robótica
pedagógica de baixo custo. Que a partir de melhorias em um projeto já existente
disponibilizou-se um hardware para controle robôs com fins pedagógicos.
Referências
[1] Lego: www.lego.com
[2] Gogo http://padthai.media.mit.edu:8080/cocoon/gogosite/home.xsp?lang=en
[3] Handy Cricket: http://handyboard.com/
[4] LogoBlock:
http://llk.media.mit.edu/projects/cricket/doc/help/logoblocks/refcricket.html
[5] Robos Br: http://www.robos.com.br/
- 57 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
Estudo da Importância da Informação no Desempenho da Cadeia de
Suprimento
Michelle Chaves Kuroda; Marcius F. H. Carvalho
Divisão de Gestão Empresarial – CenPRA
Rod. D. Pedro I, km 143,6 Campinas SP 13083-970
[email protected]; [email protected];
Resumo
Esta pesquisa tem como objetivo melhorar o desempenho na cadeia de
suprimentos com relação a custos e tempo de processos, utilizando
software de A-SIM, com foco no interior da fábrica. O maior desafio é prover
gerenciamento de todas as partes envolvidas, com métodos e ferramentas
adequadas às tarefas de projeto e reprojeto de negócios.
Palavras-chave: cadeia de suprimentos, custos da cadeia de suprimentos, políticas de gestão
simulação, A-SIM.
1. Introdução
Um sistema de manufatura ou uma rede de empresas são constituídos de um
conjunto de células com diferentes operações, contendo combinações de operações
(manuais ou automatizadas) que são extremamente extensas quando se trabalha com
um número elevado de produtos e se pretende atender diferentes níveis de demanda,
desta forma identificar a melhor operação torna-se extremamente complexo. Então um
caminho possível para a resolução deste problema pode ser a simulação, por se
basear na experimentação evolutiva em computador de processos reais.
A simulação atua como uma ferramenta importante na diminuição de custos na
cadeia de suprimentos e também no chão de fábrica, tais custos referem-se aos
custos de planejar, implementar e controlar todo o inventário de entrada (inbound), em
processo e de saída (outbound), desde o ponto de origem até o ponto de consumo.
IMA (1992).
2. Custos Logísticos
“Custos logísticos são os custos de planejar, programar e controlar todo o
inventário de entrada (inbound), em processo e de saída (outbound), desde o ponto de
origem até o ponto de consumo” IMA (1992).
O conceito logístico empregado considera o fluxo de informações e materiais em
diversas esferas: do fornecedor à fabricação (abastecimento), nos processos de
produção (planta), entrega ao cliente e distribuição, objetivando minimizar custos e
atingir melhores níveis de serviço; enquanto que a cadeia logística é uma seqüência
de eventos e operações físicas que cumprem com uma tarefa logística completa.
As atividades de abastecimento, planta e distribuição, inseridas nestas cadeias
logísticas, envolvem diversos impostos (custos) que implicam na manutenção de
inventários, que por sua vez precisam satisfazer níveis de serviço dos clientes,
podendo ou não ocasionar falhas, como paradas de produção (por quebra de
maquinas, ou falta de matéria prima), entregas erradas ou com atrasos.
Há diversos custos a serem considerados na cadeia: custos dos elementos,
- 58 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
operações físicas de logística: referentes aos custos de embalagens, dispositivos de
movimentação, com manuseio, movimentação de materiais e de suporte à fabricação,
de armazenagem e transportes; custos nos processos: abastecimentos (para
minimizar custos de abastecimento existem alternativas como: milk run – em que o
cliente é responsável pelo frete e vai buscá-lo no fornecedor – JIT – técnica Just in
Time de sincronismo de produção e geração de pedidos, diminuindo estoques – ainda
podem ser implantados Centros de Consolidação – que maximizam embarques e
otimizam o transporte), planta (consideram as atividades de recebimento das matériasprimas, fabricação e entrega dos produtos) e distribuição (engloba previsão de
demanda, quantificação e localização de estoques de produtos e administração de
recursos).
Na troca tradicional de informação da C. S. a única informação que os elos
trocam entre si é o pedido de seu fornecedor direto, mas através da tecnologia de
informação é possível trocar informações de demanda e estoque rapidamente, o que
pode, de acordo com Cachon e Fisher (2000), reduzir os custos da cadeia em até
12.1%; diminuindo tempos de lead time e ajustando lotes a redução chega a 22%. A
proposta do artigo mencionado é a comparação da troca de informação total (em que
o fornecedor tem acesso imediato ao estoque do seu cliente) e a diminuição de lead
times e lotes, como mencionado acima, a fim de analisar os estoques gerados nos
elos e a freqüência e tamanho da demanda requisitada a cada um.
A distribuição do estoque ao longo da cadeia e o custo resultante desta
distribuição são dependentes da forma de gestão adotada para a cadeia. E cada forma
de gestão está associada à característica do produto e do mercado consumidor, logo é
preciso criar cenários adequados para cada tipo de gestão e produtos, adotando
critérios diferentes para cada um.
3. Ambiente A-SIM
A linguagem de simulação A-SIM é formada por símbolos gráficos (cuja
integração é chamada de modelo de rede), que utilizam os conceitos de recurso,
entidade, fila, ação, entre outros para descrever o comportamento dinâmico de
sistemas. Entre os recursos há: estações de trabalho em uma linha de montagem,
sistemas de manipulação, um operário na prestação de serviço, etc. Já as entidades
podem ser: peças, lotes de peças, ordens de fabricação, clientes, pedidos de clientes,
jobs etc. As filas representam as áreas de espera onde as entidades aguardam uma
ação ou recurso. Uma ação representa a atuação do sistema sobre uma entidade com
o objetivo de realizar um serviço ou operação, que pode ser uma furação,
torneamento, montagem, inspeção, teste de qualidade de uma peca, etc. Durante a
operação de uma entidade outras podem estar requerendo o mesmo serviço, o que
ocasiona filas ou áreas de espera, que afetam decisivamente o comportamento do
sistema.
4. Cenários elaborados
Para análise de custos e impactos de diferentes formas de gestão de produção
de linha branca, foi desenvolvido um modelo de produção e a partir dele, criados
diversos cenários comparativos a fim de escolher o melhor mix, encontrar o menor
inventário intermediário e acrescentando os defeitos de produção avaliar as melhorias
que deveriam ser feitas e o quanto a empresa poderia ganhar com investimentos
deste tipo.
- 59 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
O modelo simulado representa a produção de peças para linha branca, que
passam por dois processos separados: estamparia (no qual as peças são prensadas)
e a esmaltação (no qual recebem acabamento em três cabines, de dois tipos:
autolimpante ou a pó).
Figura 1: Esquema de fluxo de peças analisado.
As peças são cortadas (pois vêem em bobinas), prensadas e então esmaltadas.
Foram consideradas a produção de 4200 eletrodomésticos por dia, para uma
simulação de uma semana, ou 5 dias, com 15.4 horas de trabalho/dia.
Os tempos de prensa são variáveis de acordo com as peças, o set up foi
considerado de 14 minutos para todas estas células e as paradas das mesmas foram
detalhadamente realizadas através do estudo estatístico de um histórico de 20 dias.
Figura 2: Esquema de parada de uma das prensas do sistema.
Depois de prensadas as peças são agrupadas em lotes de 100 unidades e
enviadas para um buffer intermediário, onde esperam para serem acabadas nas linhas
da Esmaltação.
Foram elaborados cenários comparativos para análise da produção de peças de
Esmaltação para Prensas e sua alimentação nas linhas Pó1, Pó2 e Autolimpante.
Os cenários estão descritos na tabela a seguir:
Prensas Não
Dedicadas
Explosão Por Peças
A
Explosão Por Modelos
C
Prensas Dedicadas
B
D
Tabela 1: Apresentação de cenários simulados no Software A-SIM.
Os quatro cenários ainda são subdivididos em: a) Sem paradas; b) Com
paradas.
Os dois primeiros cenários (A e B) foram construídos de modo que os produtos
que estavam divididos em oito modelos distintos fossem explodidos em peças e então
a produção foi realizada foi realizada uma única vez ao dia para cada uma das peças.
No primeiro modelo, as peças iriam para um grupo de possíveis prensas, no qual o
próprio simulador fazia a escolha pela menor fila, e no segundo modelo as peças
foram dedicadas.
Nos outros dois cenários foi implantado o cambam, logo, as peças não seriam
mais produzidas na ordem estabelecida nos dois primeiros modelos, mas de acordo
- 60 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
com os modelos dos produtos.
Figura 3: Diferença de cenários, a esquerda, modelo de produção por peças e a direita, modelo
de explosão por modelos.
O foco da simulação foi dado ao tamanho do buffer criado entre a Estamparia e
a Esmaltação, o impacto das paradas das prensas, o tempo total de produção e enfim,
se a fábrica teria condições de implantar a nova gestão na produção e quais suas
conseqüências.
5. Conclusão
Os cenários apresentados apresentaram os seguintes resultados:
Cenários
A a)
A b)
B a)
B b)
C a)
C b)
D a)
Tempo total (dias)
3,84
3,86
3,8
4,01
3,9
4,18
4
Estoque
56968
22552
37368
26524
25976
7368
16500
esmaltação (pçs)
Tabela 2: Resultados obtidos com a simulação dos cenários apresentados.
D b)
4,68
10560
Em todos os modelos as paradas acresceram o tempo total de produção
sugerido, porém, não de maneira muito significativa, pois as prensas que alimentam a
Esmaltação são gargalos do processo. Assim, a dimensão do estoque gerado com as
paradas é expressivamente menor em relação aos seus cenários sem paradas, uma
vez que as peças são produzidas com atraso e então, lançadas posteriormente para a
segunda etapa da fabricação.
O cenário de explosões de peças por modelos foi o escolhido para ser
implantado na empresa, uma vez que vão utilizar o processo de cambam na mesma
(para terem mais visibilidade da produção e do fluxo de peças dentro da fábrica), desta
forma, poderão dimensionar melhor este estoque intermediário, pois só serão
prensadas as peças que a montagem já tiver processado (processo puxado). O
modelo que representa tal método é o especificado no cenário D b), que atrasa
ligeiramente a produção, mas que ainda atende as metas de produção da empresa.
Referências
CACHON, G.P., FISHER, M., Management Science, Supply Chain Inventory
Management and the Value of Shared Information, Agosto 2000, p. 1032-1048.
INSTITUTE OF MANAGEMENT ACCOUNTANTS (IMA). Cost Management for
Warehousing. [S.I.].: National Association of Accountants, 4-k, september, 1989.
(Statements on Management Accounting).
- 61 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
Estratégia Baseada em Competências Essenciais
Mirella Borin; Marco Antonio Silveira
Divisão de Gestão Empresarial – CenPRA
Rod. D. Pedro I, km 143,6 Campinas SP 13083-970
[email protected]; [email protected]
Resumo
Este artigo apresenta um estudo sobre Estratégia Baseada em
Competências Essenciais, isto é, empresas que montam suas estratégias
com base em competências que permitem sua diferenciação e
sustentabilidade ao longo do tempo. Primeiramente, a bolsista
contextualizou a importância de uma estratégia bem fundamentada para as
empresas atuais, focando no conceito de qualidade como forma de garantir
a salubridade das companhias. Assim, a pesquisa teórica passa a estudar
o conceito de competência essencial e como esta permite a diferenciação
das organizações. Feito isso, a bolsista focou no estudo de casos, em
empresas que utilizam estratégias baseadas em competência essenciais
como forma de diferenciação.
Palavras-chave: Competências Essenciais – Qualidade – Diferenciação - Estratégia.
1. Introdução
As estratégias das empresas do mundo contemporâneo precisam ser muito mais
elaboradas do que as de antigamente, pois além de garantir a salubridade das
companhias no presente, precisam garantir sua sustentabilidade do futuro. Assim, o
management das organizações precisam tomar decisões no presente que impactem
positivamente o resultado no futuro e, para formar uma empresa forte e que seja
benchmark no mercado é necessário focar em qualidade.
Qualidade nos processos de forma a garantir qualidade nos resultados. A norma
de terminologia ISO 8402 (1994) define qualidade como sendo: A totalidade de
características de uma entidade que lhe confere a capacidade de satisfazer
necessidades explícitas e implícitas.
Dessa forma, o que vai garantir essa totalidade de características é uma
estratégia eficaz, ou uma boa Gestão da Qualidade, que é definida pela norma ISO
8402 como: Todas as atividades da função gerencial que determinam a política da
qualidade, os objetivos e as responsabilidades, e os implementam por meios como
planejamento da qualidade, controle da qualidade, garantia da qualidade e melhoria da
qualidade, dentro do sistema da qualidade.
Nesse sentido, cabe ao gestor saber antecipar qual a demanda do mercado e
estar pronto para atendê-la, antes de seus concorrentes.
No entanto, antecipar a demanda do mercado não é algo simples de se
conseguir, nem tampouco fácil, principalmente porque muitas vezes a demanda é por
soluções elaboradas que exigem tempo dedicado ao seu desenvolvimento.
Na tentativa de solucionar esse problema, as empresas de ponta desenvolveram
o que ficou conhecido como Competências Essenciais, otimizando o tempo de
desenvolvimento de novos produtos, garantindo a qualidade.
A competência por si só é constituída do conjunto de conhecimento, habilidade e
atitude. Isso determina as diferentes competências humanas que, quando aplicadas
em conjunto vão determinar a qualidade de uma organização.
- 62 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
No entanto, muitas organizações possuem profissionais competentes cujo
desafio passa a ser diferenciar, ou seja, se tornar competitivo diante do cenário de
concorrência acirrada, através de soluções inovadoras que antecipem a demanda do
mercado. Foi no desenvolvimento dessa idéia que surgiu o conceito de Competência
Essencial.
2. Competências Essenciais
Competência Essencial é aquela na qual a empresa foca seus esforços, ou seja,
é a base de qualquer desenvolvimento daquela organização. Ou seja, é o produto
básico dessa organização que, combinado de diferentes formas, vai resultar em
soluções inovadoras e diferenciadas. Digamos, por exemplo, que a Competência
Essencial da Coca-Cola seja produzir água gaseificada adicionada de uma fórmula
química que lhe garante o sabor. Se a demanda do mercado é por produtos light, cabe
a Cola-Cola substituir o açúcar da bebida por um adoçante pouco calórico e a nova
bebida está pronta para ser oferecida aos consumidores. Se o mercado em que se
atua é forte em sucos com sabor de fruta, basta adicionar o sabor à bebida e tem-se
um produto pronto para esse segmento.
Assim, através quando as empresas passam a estruturar suas estratégias com
base em sua Competência Essencial, passam a atender rapidamente às demandas do
mercado, respondendo prontamente as oscilações dessas demandas. É o que permite
às organizações se diferenciarem e se tornarem líderes de mercado.
A estratégia baseada em competência essencial de uma companhia pode ser de
caráter operacional, de inovação em produto ou de orientação ao cliente:
Excelência Operacional é aquela que permite que a empresa se diferencie no
mercado por visar sempre a otimização da relação qualidade/preço, garantindo a
maior competitividade de seus produtos e/ou serviços. Exemplo típico de Excelência
Operacional é o das empresas automobilísticas, com destaque para a Ford no
passado e a Toyota atualmente. No mercado de computadores, Compaq e Dell são os
maiores exemplos. No setor de serviços, McDonalds e WalMart, entre outras, são
casos de renome internacional.
Inovação em Produto As companhias que competem com uma estratégia de
Inovação em Produto estão continuamente investindo para criar conceitos de produto
radicalmente novos para clientes e segmentos de mercado definidos. A função crítica
é Pesquisa & Desenvolvimento & Engenharia (P&D&E). Exemplos de indústrias nas
quais a competitividade é regulada pela Inovação em Produto são as indústrias de
Tecnologia da Informação (TI), Telecomunicações, Computação e Internet. O mesmo
padrão é encontrado na indústria Biomédica (Ciências da Vida). Porém, há inovadores
no mercado de consumo, como a Sony e a 3M.
Orientação para cliente As empresas que adotam a estratégia Orientada para
Cliente são voltadas para as necessidades de clientes específicos e procuram se
especializar no desenvolvimento de produtos, sistemas e soluções que atendam a
suas demandas atuais e futuras. Para isso, tais companhias priorizam o
desenvolvimento do conhecimento sobre cada cliente e seu negócio: Vendas &
Marketing torna-se a função crítica, impulsionando os esforços de Pesquisa,
Desenvolvimento e Engenharia, e também de Operações. A IBM era considerada o
exemplo dessa estratégia (Wheelwright & Hayes, 1985). A Caterpillar é considerada
como um caso de "intimidade com o cliente" (Treacy & Wieserma, 1995).
3. Cases
Banco do Brasil: entre 2001 e 2003 o Banco do Brasil realizou em todas as suas
- 63 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
unidades de abrangência nacional (excetuando-se apenas Acre, Amapá e Roraima)
um competição baseada em competências, cujo objetivo era desenvolver
competências nos funcionários visando o estabelecimento de algumas práticas
baseadas nas competências de excelência. O resultado obtido foi o desenvolvimento
das práticas almejadas. No entanto o desenvolvimento das competências ficou no
nível individual e disseminado às outras unidades. Não se chegou a compor uma
competência essencial.
Sony: todas as estratégias apresentadas pelos CEO´s da empresa focam P&D
no sentido de desenvolver novas tecnologias e que permitam a evolução dos produtos
eletrônicos. Os três focos estratégicos da companhia no planejamento de 2006 foram:
eletrônicos, jogos e entretenimento. Uma das metas e o desenvolvimento de softwares
que permitam a interoperabilidade entre os diversos equipamentos eletrônicos.
Toyota: pode-se dizer que a competência essencial da Toyota a produção de
automóveis de alta-tecnologia, dotados de computadores de bordo e correlatos. Esse
é o diferencial da marca. A empresa investe em programas de desenvolvimento
educacional para os técnicos, visando formar profissionais qualificados capazes de
desenvolver tais tecnologias e acoplá-las aos automóveis. Tais programas de
formação educacional são: T-TEN (Toyota Technical Education Network) e AYES
(Automotive Youth Educational Systems).
Dell: “Customer-driven innovation”. As diretrizes de P&D são dadas pelos
consumidores. As soluções são desenvolvidas muitas vezes junto a parceiros
tecnológicos (ex.: Intel, Microsoft, Oracle e EMC). Competência Essencial: entender e
atender as necessidades dos consumidores.
McDonalds: a estratégia de excelência da empresa é dada pelo foco em 5
pilares: pessoas, produtos, lugar, preço e promoção. Através da harmonização entre
esses cinco pilares a empresa se matem líder de mercado há 50 anos. Pode-se dizer
que a competência essencial da empresa seja produzir comida rápida, de altaqualidade e com preço acessível.
WalMart: a competência essencial da empresa é oferecer aos clientes o que eles
querem, com facilidade e praticidade, sem ter que pagar muito caro por isso.
3M: a competência essencial da empresa são suas plataformas tecnológicas.
Como está definido pela própria empresa: “As plataformas tecnológicas são a
essência do talento da 3M e o impulso para ir ao encontro das necessidades de
nossos clientes. Em diversas combinações, as tecnologias 3M são a base para o
desenvolvimento de produtos inovadores . Produtos que são simples de usar, contudo
complexos o suficiente para ajudar a fazer o mundo mais saudável, seguro e melhor.”
IBM: a competência essencial da empresa é aplicar a tecnologia de forma que
essa se traduza em soluções para a indústria e comércios. Daí a sigla IBM:
International Business Machines.
Caterpillar: a competência essencial da empresa consiste em investir em
pesquisa e desenvolvimento, disponibilizando sempre novas tecnologias que resultem
em produtos que antecipem a demanda dos consumidores.
4. Conclusão
Para que uma empresa se mantenha competitiva diante do cenário atual de
concorrência acirrada é necessário mais que inovar, é preciso se diferenciar com
rapidez. Para tanto, é preciso mais que uma boa estratégia, é necessário uma
estratégia baseada em competências essenciais que vai garantir a sustentabilidade da
- 64 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
companhia ao longo do tempo.
Muitas empresas utilizam estratégias baseadas em competências essenciais, no
entanto, tal estratégia não está explícita no modelo estratégico da empresa. A bolsista
chegou a essa conclusão em função das suas buscas nos sites das empresas: quando
se procura as metas estratégicas da organização, o que se encontra são os “targets”
buscados pela empresa, os valores prezados pela organização, os processos de
trabalho adotados pela companhia, enfim, um conjunto de características que vão
determinar a cultura da organização.
Assim, o que pode-se ver são empresas muito bem estruturadas, com metas
bem claras, com processos de ponta e com culturas de excelência, no entanto o que
não fica claro (ou explícito) é o cerne da estratégia, isto é, a competência essencial
que determina do diferencial da empresa.
Os sites das empresas, bem como os links destes que tratam de estratégia, nem
se quer mencionam o termo competência essencial. Diante disso a bolsista procurou
identificar, por conta própria, qual seria a competência essencial para cada uma das
empresas pesquisadas, ou seja, procurou reunir todas as informações fornecidas pela
empresa a fim de traçar um caminho à competência essencial da organização em
questão.
Com isso, pode-se concluir que empresas líderes de mercado estão baseando
suas estratégias em competências essenciais, mesmo que esta estratégia ainda não
esteja explícita no modelo de atuação dessas organizações.
Agradecimentos
Agradeço a realização desse artigo à colaboração do professor-orientador Marco
Antonio Silveira, que possibilitou o acesso a novas informações e contribuiu com
discussões para a elaboração do relatório. Agradeço ainda ao CNPq, pela bolsa que
permitiu o custeio de despesas e colaborou para pesquisa sobre o tema.
Referências Bibliográficas
PRAHALAD, C. K.; HAMEL, G. The core competence of the corporation. Harvard
Business Review, 1990.
PRAHALAD, C. K.; HAMEL, G. Competing for the Future. Harvard Business School,
1994.
SHI, Y.; GREGORY, M. International manufacturing networks–to develop global
competitive capabilities. Journal of Operations Management, 1998.
XXIV Simpósio de Gestão da Inovação Tecnológica – ANPAD 30 anos
Simpósio – Gestão da Inovação Tecnológica – 2004
Afonso Fleury e Maria Tereza Fleury – Artigo “Competitive strategies and core
competencies: perspectives for the internationalization of industry in Brazil”. In
“Gestão e Produção”, 2003.
Nonaka, I., Takeuchi, H. Criação de conhecimento na empresa: como as empresas
japonesas geram a dinâmica da inovação. São Paulo: Campus, 1997.
BATEMAN/SNELL. Administração Managment: Construindo Vantagem Competitiva.
Editora Atlas, 1998.
DRUCKER, Peter F. Administrando em Tempos de Grande Mudança. São Paulo:
Pioneira, 1996.
PORTER, M. E. Estratégia competitiva. Rio de Janeiro: Campus, 1980.
SILVEIRA, Marco Antônio. Textos Diversos. Campinas: Mestrado em Gerenciamento
de Sistemas de Informação, Pontifícia Universidade Católica de Campinas, 2003.
Site das empresas citadas ao longo do artigo.
- 65 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
Estudos Aerodinâmicos e Dinâmicos no Dirigível AS800B
Pedro Raposo Barros; Samuel S. Bueno; Josué J. G. Ramos
Centro de Pesquisas Renato Archer - CenPRA
Divisão de Robótica e visão Computacional
Rod. D. Pedro I, km 143,6
13069-901 Campinas SP
{Pedro.Barros; Samuel.Bueno;Josue.Ramos}@cenpra.gov.br
Resumo
Este documento apresenta os resultados de estudos conduzidos sobre
dois aspectos do dirigível AS-800B. Um primeiro estudo foca na
modelagem e interpretação iniciais das características aerodinâmicas
básicas utilizando mecânica dos fluidos computacional (CFD – Computer
Fluid Dynamics) O segundo estudo aborda a influência dinâmica dos
motores do grupo propulsor, ligada a efeitos de precessão.
Palavras chave:
computacional.
dirigível,
aerodinâmica,
dinâmica,
mecânica
dos
fluidos
1. Introdução
Esse trabalho consiste na análise da configuração do dirigível AS 800 em
condições de vôo, considerando o envelope, a gôndola, grupo propulsor e superfícies
de atuação.
Dois aspectos são abordados. O primeiro utiliza ferramentas de mecânica dos
fluidos computacional (CFD – Computer Fluid Dynamics), utilizando o software
Phoenics, para modelar, analisar e determinar quais os fatores essenciais para o
cálculo e identificação do escoamento ao redor do dirigível, de modo a obter, por
exemplo, indicações para aumentar a eficiácia de propulsão, reduzir o arrasto
aerodinâmico da gôndola e buscar a máxima eficiência nos comandos das superfícies
aerodinâmicas de atuação que estão situados na parte traseira da fuselagem da
aeronave.
Um segundo estudo aborda a influência dinâmica advinda dos efeitos de
precessão giroscópica resultantes da rotação dos motores do grupo propulsor.
2. Estudos por CFD
O dirigível é constituído de envelope, gôndola que se situa sob o envelope,
grupo propulsor montado na gôndola e superfícies aerodinâmicas de atuação
montados na cauda do envelope. Sua representação e o escoamento ao seu redor,
resultantes de modelagem em ambiente de CFD são ilustrados na 1, enquanto que os
sistemas de coordenadas associados são mostrados na Figura 2.
Estudos de simulação com este modelo levaram ao estabelecimento de padrões
qualitativos de escoamento de ar resultantes da influência da gôndola, da ação dos
motores e do posicionamento das superfícies de atuação – como ilustrado na Figura 3.
Considerando especificamente o grupo propulsor, como os dois motores giram
no mesmo sentido, nota-se na parte direita da Figura 3 o efeito do fluxo do ar por eles
provocado. O fluxo de é desviado para mais para as superfícies de comando à direita
- 66 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
do dirigível, o que interfere na controlabilidade da aeronave ao introduzir um
desbalanceamento na eficácia de atuação das superfícies aerodinâmicas direita e
esquerda. A obsevação em CFD dessas condições de fluxo sugere a avaliação de uso
de motores que girem em direções opostas.
Figura 1 Gama de velocidades de escoamento ao
redor do dirigível AS-800..
Figura 2 Sistema de
coordenadas na modelagem
do dirigível
Figura 3 Estudos dos efeitos da gôndola (incluindo propulsores e caixa com sistema
embarcado), envelope e superfícies de atuação no escoamento.
2. 1. Estudo da influência do Efeito de Precessão em manobras
O caráter giratório dos motores levanta outra questão: o efeito de precessão.
Ao vetorizarmos o grupo propulsor para orientar o empuxo ou variarmos o
ângulo de arfagem da aeronave, irá surgir um momento de precessão giroscópica introduzido pelo fato dos dois motores girarem no mesmo sentido. De forma análoga,
ao executarmos uma manobra em curva (no plano horizontal) haverá um momento de
precessão para variar o ângulo de arfagem o que irá sobrecarregar o servo do
comando de vetorização, além de variar o ângulo de ataque. Considerando o
referencial da Figura 2, uma curva no eixo Z ocasiona um momento de arfagem em Y
e de forma análoga uma variação na arfagem (Y) levaria ao surgimento de um
momento de guinada em Z.
Esses comportamentos influenciam as manobras básicas de vôo e estudos
foram conduzidos para avaliar seu grau de influência.
- 67 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
Considera-se que um disco giratório aproxima a rotação das hélices do dirigível
e que são conhecidas as distâncias da hélice até o eixo de referência do sistema de
controle, velocidade de rotações das hélices em vôos de cruzeiro e manobras (Figura
4).
Figura 4: Configuração dos motores e disco aproximativo das hélices para estudo do efeito de precessão
Considera-se também os valores dos momentos de inércia e distâncias,
levantados do dirigível:
o Momento de inércia da hélice: 0,00036652 Kg m2
o Massa da hélice: 0,04758 kg
o Distância das superfícies de atuação ao eixo de vetorização: (4.5 0
1.5) m
o Distância da Hélice ao Centro de Gravidade (referência do sistema de
controle): (0.486, 0, 1.5) m
Com isso, podemos equacionar vetorialmente e estimar os momentos de
precessão giroscópica aos quais o dirigível AS-800 é submetido durante uma missão
de vôo, como segue:
2
(1)
d 2 = d1 + d 2
I h−cg = I he + m ⋅ d
(2)
2
(3)
M = I ⋅Ω⋅n
v
Ω=
ρ
(4)
onde d são distâncias, n é a rotação do motor I é o momento de inércia, Ω é a
velocidade angular da manobra, v é a velocidade à frente do dirigível (m/s) e ρ o raio
da curva (m). Substituindo a equação (2) em (3) temos que:
→
→
M = ( I he + m ⋅ d 2 ) ⋅ Ω⋅ n
(5)
M ' = ( I he + m ⋅ d 2 ) ⋅ n
(6)
Este modelo foi utilizado para calcular as forças resultantes do efeito de
- 68 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
precessão e compará-las com as forças consideradas no atual modelo dinâmico do
dirigível (o qual não inclui os efeitos de precessão).
A conclusão foi de que, apesar da existência do efeito de precessão, as forças
por ele geradas são de ordem de grandeza inferior às consideradas no modelo
dinâmico em uso. Essa conclusão é corroborada pela prática de pilotagem do dirigível,
onde não é perceptível, para os pilotos, dificuldades de manobra que seriam oriundas
do efeito de precessão.
Portanto, apesar da relevância conceitual do estudo dos efeitos de precessão,
entende-se que, em termos práticos, não é necessário considerá-los para efeitos de
controle e guiagem da aeronave, onde perturbações e dinâmicas não modeladas, a
serem compensadas pelo sistema controle têm maior influência que os efeitos de
precessão.
3. Conclusões
Os trabalhos desenvolvidos consistiram na finalização do modelamento inicial
em CFD do dirigível AS800, com a obtenção de resultados qualitativos dos efeitos da
gôndola, da rotação dos motores e do posicionamento das superfícies de atuação em
relação o escoamento de ar ao redor da aeronave.
Também foi realizado o estudo do efeito de precessão giroscópica nas manobras
realizadas pelo veículo, concluindo-se que sua magnitude pode ser desconsiderada
face a outras forças que determinam a movimentação da aeronave.
Em termos de estudos em CFD, com a gôndola e grupo propulsor montados em
bancada, é possível, a partir de medições de fluxo de ar utilizando anemômetro, para
diferentes velocidades de rotação dos motores e vetorização, validar quantitativamente
(embora de forma parcial) o modelo concebido.
Referências
Azinheira, J.R., de Paiva, E.C., Ramos, J.G., Bueno, S.S., Bergerman, M. (2001).
“Extended Dynamic Model for AURORA Robotic Airship” 14th AIAA Lighter-Than-Air
Technical Committee Convention and Exhibition Akron, Ohio, USA; July 2001;
Gomes, S. B. V.; Ramos, J. J. G. (1998) “Airship dynamic modeling for autonomous
operation.“, IEEE International Conference on Robotics and Automation, Leuven,
Belgium, Maio de 1998.
Fox, Robert W. & McDonald, Alan T – Introdução à Mecânica dos Fluidos, 4ª edição
1998;
Bramwell, A. R. S.; Done, George; Balmford, David – Bramwell’sHelicopter Dynamics,
2nd edition;
Merian, J.L. & Kraige, L.G. “ Engineer Mechanics - Dynamics “, 4a ed. John Wiley &
Sons, Inc 1997.
John D. Anderson, Jr – Fundamentals of Aerodynamics, McGrowHill Book Company,
NY;
Wilcox, David C. – Turbulence Models for CFD, 2nd edition 1994;
McCorning, Barnes W. Jr. – Aerodynamics of V/STOL Flight, 2nd ed. 1999.
- 69 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
Evolução de figuras no Ambiente MasterPiece
Rafael Bocaletto Maiolla; Artemis Moroni
Centro de Pesquisas Renato Archer - CenPRA
Divisão de Robótica e Visão Computacional
Rod. D. Pedro I, Km 143,6
13069-901 Campinas SP
{rmaiolla; artemis.moroni}@cenpra.gov.br
Resumo
Este artigo descreve MasterPiece, um ambiente desenvolvido para a
produção de composições visuais. Os objetos, inspirados por uma obra de
Kandinsky, foram programados em Java. As composições são criadas
automaticamente aplicando algoritmos e operadores genéticos. Os
resultados são apresentados em forma de figuras.
Palavras chave: Computacão evolutiva, programacão genética.
1. Introdução
Por muitos anos a arte e a música vêm sendo desenvolvidas em computadores.
A computação evolutiva é uma técnica promissora e que vem crescendo nesse
sentido. Richard Dawkins foi um dos primeiros a demostrar como as técnicas
evolutivas poderiam ser combinadas com o senso do que é agradável visualmente a
um usuário específico para gerar um conjunto praticamente infinito de formas que são
no mínimo interessantes. Desde então, algoritmos evolutivos tem aplicados como
“métodos criativos” com sucesso a uma variedade enorme de problemas que alguns
pesquisadores chegam a sugerir que eles podem modelar a criatividade nos
computadores, embora a maioria mostra-se bastante cautelosa quanto a essa
afirmação e às suas conseqüências na área computacional.
2. Sistemas Genéticos
Os algoritmos genéticos são úteis para busca em grandes espaços, usando a
simulação dos operadores de variação e seleção. O laço de repetição de um algoritmo
genético é o mais simples possível, basicamente: geração, teste e seleção. Tais
algoritmos mantêm uma população de soluções potenciais; eles possuem um
processo de seleção e alguns “operadores genéticos”, tipicamente funções
matemáticas, que simulam o crossover e a mutação. Basicamente, uma população é
gerada, os indivíduos da população são testados de acordo com determinados
critérios, e os melhores são mantidos. O processo é repetido gerando uma nova
população de indivíduos – no caso composições – que são baseados nos anteriores.
Este laço de repetição continua até que o resultado seja satisfatório de acordo com os
critérios que estão sendo usados. O desafio nesse algoritmo é definir o que significa
“gerar” e “testar” (Todd & Werner, 1999).
Todas as abordagens do processo evolutivo compartilham das mesmas
características. Elas são todas baseadas, como no diagrama da figura 1, numa
estrutura geral fornecida pelo algoritmo genético original de J. H. Holland (GA)
(Holland, 1992). A figura 1 mostra o diagrama de um algoritmo genético simples. A
população é iniciada com soluções aleatórias. As soluções que gerarão descendentes
são escolhidas aleatoriamente nas populações anteriores. Os operadores de
crossover e mutação são então aplicados, gerando uma população modificada, e o
ciclo evolutivo recomeça.
- 70 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
Figura 1: O algoritmo genético.
2.1. O Processo de Avaliação
A avaliação no sistema MasterPiece é deixada a cargo do usuário, ou seja,
existe uma interação entre o usuário e o sistema de forma que o usuário por meio de
uma interface possa classificar e dar notas às composições. Trata-se, portanto de um
algoritmo genético interativo (AGI).
2.2. A Mutação
A mutação ocorre pontualmente dentro de um alelo de um gene que é
aleatoriamente modificado resultando em um novo objeto com uma de suas
características modificadas.
A mutação pontual em um objeto ocorre da seguinte maneira. É aplicado um
algoritmo com uma probabilidade baixa de escolha de gene para mutação. Uma vez
escolhido o gene, este seleciona aleatoriamente, dentre as suas características
mutáveis, qual deve sofrer a modificação. Então um novo valor é gerado
aleatoriamente para substituir o valor antigo.
2.3. A Seleção
A seleção de uma composição é feita através do algoritmo denominado Roulette
Wheel, essa seleção é proporcional ao fitness da composição. Neste caso é feita pelo
usuário do sistema através da avaliação e aplicação da nota. Este algoritmo de
seleção é um gerador de números pseudo-aleatórios com distribuição uniforme que
permite a perda do melhor indivíduo e também que ocorra a seleção de um individuo
mais de uma vez. Os indivíduos selecionados irão gerar descendentes a partir da
reprodução ou então do crossover.
2.4. O Crossover
No sistema desenvolvido, o operador de recombinação aplicado é o crossover
simples. O ponto de cruzamento é definido por um número aleatório dentro do
intervalo definido pelo tamanho do cromossomo. Dado dois cromossomos, o ponto de
- 71 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
troca de material genético é feito a partir desse ponto, sendo que ao final do processo,
cada um dos dois cromossomos que participaram do crossover terão, em seu material
genético, uma parte sendo a sua própria (informação antiga) e a outra parte sendo
uma parte da informação do outro cromossomo (informação nova).
Figura 2: Aplicação de crossover de 2 pontos sobre os cromossomos.
O crossover no ambiente desenvolvido pode ocorrer em 2 momentos, num deles
é a aplicação direta do operador de crossover a comando do usuário sobre uma
população e a outra é, iterativamente, através do operador genético reprodução.
No primeiro caso, as composições são selecionadas dentro da população
obedecendo ao algoritmo Roulette Wheel, de forma que as novas composições vão
ocupar o lugar das composições que foram selecionadas. A seleção sempre utiliza o
critério de avaliação com interação com o usuário.
O segundo caso ocorre na reprodução que será explicado em seguida.
2.5. O processo automático de Reprodução
O processo de reprodução nesse ambiente segue os seguintes passos: seleção,
crossover e mutação, para então dar lugar aos descendentes.
Figura 3: Ilustração que representa a reprodução dentro do ambiente Masterpiece.
Neste caso está sendo simulado o mecanismo da evolução através de um
algoritmo genético interativo. É um AGI, pois a avaliação é feita pelo usuário e não por
alguma função de fitness automática.
- 72 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
No início do processo, o operador seleciona quais serão os pares que farão a
reprodução, a esses pares é então aplicado o operador de recombinação genética e
em seguida é aplicado o operador de mutação sobre esses cromossomos. O resultado
da aplicação da mutação são os descendentes que irão ocupar os lugares dos
ascendentes.
3. Conclusões
Esse sistema nasceu como um laboratório do que poderia ser criado
computacionalmente aplicando a computação evolutiva à produção artística. Foi
verificado que com técnicas adaptadas de algoritmos evolutivos é possível conseguir
composições visuais no mínimo interessantes. Composições visuais obtidas no
ambiente MasterPiece serão aplicadas à criação automática de cenários no ambiente
AURAL, (projeto FAPESP 05/56186-9), instalação interativa aplicada à programação
de coreografias robóticas.
MasterPiece
se
encontra
http://br.geocities.com/rafael.maiolla/
disponível
no
seguinte
endereço:
A figura 4 ilustra algumas imagens geradas pelo sistema.
Figura 4: Imagens geradas pelo MasterPiece
Agradecimentos
Gostariamos de agradecer ao programa PIBIC/CNPq e ao CenPRA por
possibiliar essa pesquisa e à FAPESP, financiadora do projeto.
Referências
Holland, J. H. Adaptation in Natural and Artificial Systems. University of Michigan
Press, 1975.
Holland, J. H. Genetic Algorithms, Scientific American, July, 1992.
Moroni, A., Maiolla, R., Manzolli, J., Von Zuben, F. ArTVox: Evolutionay Composition in
Visual and Sound Domains. In Butz, A., Fisher, B., Krüger, A., Oliver, P. (Eds.)
Lecture Notes in Ccomputer Science (LNCS 4073), Proceedings of the 6th
International Symposium on Smart Graphics (SG’2006), PP. 218-223, Springer,
Vancouver, BC, Canada, July 23-25, 2006. (ISBN: 3-540-36293-2) (ISSN: 03029743)
Todd, P. M.; Werner, G. M.; Frankensteinian Methods for Evolutionary Music
Composition in Griffith, N. & Todd, P. M. (eds) Musical Networks: Parallel
Distributed Perception and Performance, Cambridge: The MIT Press, pp. 313-339,
1999.
- 73 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
Desenvolvimento de Software para Controle e Aquisição de Dados do
Microscópio Fototérmico.
Thiago Augusto Massarutto; Carlos R. M. de Oliveira
DAPE Centro de Pesquisas Renato Archer - CenPRA
Rod. D. Pedro I, Km 143,6
Campinas SP 13083-970
[email protected]; [email protected]
Resumo
Este trabalho tem como objetivo desenvolver um software para o controle e
aquisição de dados do microscópio fototérmico. Dando continuidade ao
estudo e a caracterização de falhas em componentes eletrônicos com a
técnica da microscopia fototérmica de reflexão. Esta consiste em fazer um
mapeamento térmico da superfície do componente para conhecer as
informações típicas de cada falha, como suas causas e conseqüências, de
modo a melhorar a eficiência e qualidade dos métodos de analise e falhas
do laboratório e também avaliar as técnicas mais eficientes para
identificação destes mecanismos.
Palavras-chave: Análise de Falhas, Microscopia Fototérmica, Componentes
eletrônicos.
1. Introdução
Aumentar a confiabilidade em produtos eletrônicos é fundamental para garantir o
sucesso destes produtos no mercado.
Com a capacidade de prever pontos mais propícios num circuito integrado a
apresentar falha, utilizando técnicas não destrutivas, a técnica da microscopia
fototérmica de reflexão é uma importante ferramenta na análise, caracterização e
simulação de falhas em circuitos eletrônicos.
Neste estudo, procuramos conhecer e dominar a técnica da microscopia
fototérmica de reflexão para que esta sirva como uma ferramenta valiosa na análise,
caracterização e simulação de falhas em circuitos eletrônicos.
2. A microscopia fototérmica de reflexão
Em uma grande gama de materiais, as propriedades térmicas destes tem uma
dependência com as propriedades ópticas, assim é possível detectar variações na
temperatura do material analisando a refletância deste. A técnica da microscopia
fototérmica de reflexão se baseia nesse fenômeno. O material excitado é varrido por
um laser de comprimento de onda e potência fixas. A variação na energia da amostra
faz com que o índice de refração complexo na superfície do material se modifique. O
feixe refletido passa por um processo de filtragem e a leitura deste sinal permite a
montagem de mapas térmicos da superfície da amostra.
Sendo a amostra um circuito eletrônico, podemos por exemplo utilizar o método
para analisar uma trilha do circuito, observando os locais de maior temperatura que
representa locais de maior fluxo de corrente, detectando assim fuga de corrente,
curtos-circuitos e efeitos de eletromigração.
- 74 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
Como o método não é destrutivo, podemos utilizá-lo na amostra sem causar
alterações significantes nesta, poupando-a para que seja utilizada em outras técnicas
de analise de falhas.
3. Funcionamento do Microscópio Fototérmico
O laser diodo emitindo feixe contínuo, com comprimento de onda de 670nm e
potência menor que 1mW/cm2 passa através da objetiva do microscópio e é
focalizada sobre a amostra. O laser é refletido na amostra e passa novamente através
do microscópio e posteriormente é defasado de 90 graus através da lâmina de quarto
de onda. O cubo separador desvia o laser de prova para as lentes convergentes e é
captado pelo fotodiodo de Si. O fotodiodo de Si converte os sinais ópticos em sinais
elétricos, que é analisado por um amplificador lock-in. O gerador de função alimenta a
amostra com modulação de 100kHz e onda quadrada de 0 a 5V servindo de referência
para o lock-in analisar o sinal proveniente do fotodiodo.
O conversor A-D recebe os sinais fase e amplitude do lock-in e o sinal DC
diretamente do fotodiodo que são convertidos em sinais digitais para serem adquiridos
pelo software em desenvolvimento. Este software também é responsável pelo controle
do motor de passo e armazenamento das informações, as quais serão posteriormente
tratadas por algum software de tratamento ex. Matlab, Origin.
O esquema do microscópio fototérmico por reflexão está apresentado na Fig. 1.
Figura 1: Diagrama da montagem experimental para análise por microscopia fototérmica.
4. Funcionamento do Software de Controle e Aquisição
O software que estamos implementando para gerenciar o microscópio
fototérmico está sendo desenvolvido em linguagem Basic. O programa basicamente
desempenha duas funções a de controle dos equipamentos e a aquisição dos dados
experimentais. Ele é quem faz o controle dos transladadores, mesa XY, que
movimenta a amostra para ser varrida pelo laser. A resolução do passo dos
transladadores é da ordem de 0,1 m. A outra função do programa é fazer a leitura e o
armazenamento dos dados medidos. Ele irá fazer a leitura dos valores provenientes
do lock-in, a amplitude e a fase, e o sinal DC proveniente do fotodiodo. Estes dados
permitirão montar os mapas térmicos da amostra analisada.
- 75 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
O funcionamento do programa está basicamente descrito nas seguintes etapas:
1) Configuração da área a ser medida, número de pontos, tempo de exposição,
velocidade da medição;
2) Abre um novo arquivo para armazenamento dos dados obtidos;
3) Posiciona o controlador de modo que a parte a ser lida esteja alinhada;
4) Lê os dados digitais do conversor A/D do primeiro ponto e verifica a integridade do
sinal;
5) Grava em matrizes diferentes os 3 valores lidos do ponto (fase, amplitude e sinal
DC);
6) Se tudo estiver certo posiciona o controlador para o próximo ponto;
7) Lê novamente os dados digitais do conversor A/D;
8) Loop (item 3) dos processos acima até que termine a medida de toda área.
9) Salva os dados no arquivo aberto.
A Figura 2 apresenta a tela de abertura para a configuração do sistema do
programa que gerencia o funcionamento do microscópio fototérmico. Um fluxograma
simplificado do funcionamento do programa está ilustrada na Figura 3.
Figura 2: Tela do menu principal.
Configuração
dos
equipamentos
Posição da área
do chip
a ser medida
Leitura dos dados do
ponto varrido (amplitude,
fase, sinal dc)
Figura 3: Funcionamento do software.
- 76 -
Posiciona a mesa para o
próximo ponto a ser lido
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
5. Considerações Finais
Estamos na etapa final de elaboração e ajuste do programa. Esperamos em
breve provocar nas estruturas de testes defeitos monitorados no laboratório para que
os mapas térmicos das mesmas sejam conhecidos e devidamente documentados para
referência quando a técnica estiver em pleno uso na análise de falhas de
componentes eletrônicos diversos.
Agradecimentos:
Gostaria de agradecer ao GFRM/IFGW, e particularmente ao prof. Dr. Antônio M.
Mansanares por ceder o espaço do laboratório. Agradeço a todo o pessoal do DAPE
pelo apoio dado durante este trabalho e especialmente ao Dr. Carlos R. M. de Oliveira
e ao Eng. Marcos B. C. Pimentel pelo auxílio e orientação. Agradeço ainda ao
programa PIBIC/CNPq pelo suporte financeiro.
Referências
Batista, J.A. “Microscopia Fototérmica de Reflexão aplicada à caracterização de
dispositivos eletrônicos.” Dissertação de mestrado – IFGW UNICAMP. Campinas,
SP, Julho 1996.
Batista, J.A. et al; “Temperature field of biased microeletronics devices obtained by
phototermal microscopy.” Segundo workshop Iberchip, São Paulo, SP, Fevereiro
1996, pp.358-364.
Batista, J.A. et al; “Photothermal Refletance Microscopy applied to the study of
electrostatic discharge degradation in MOSFET structures” XIII SBMicro, Curitiba,
PR, Agosto 1998, pp.430-436.
L. R. de Freitas, A. M. Mansanares, E. C. da Silva, M. C. B. Pimentel, S. Finco, G.
Tessier and D. Fournier. “Thermoreflectance measurements on test microelectronic
devices at several probe wavelengths: comparison between CCD and focused laser
techniques”. 13th International Conferences on Photoacoustic and Photothermal
Phenomena (ICPPP). Rio de Janeiro, Julho 2004, pp. 05-08.
L. R. de Freitas, P. G. Giorni, W. R. de Melo, A. M. Mansanares, M. B. C. Pimentel, S.
Finco e C. R. M. de Oliveira. “Estruturas de teste para caracterização fototérmica de
circuitos integrados”. XI Workshop IBERCHIP. Salvador, Março 2005, pp. 28 a 30.
L. R. de Freitas, E. C. da Silva, A. M. Mansanares, C. R. M. de Oliveira, M. C. B.
Pimentel and S. FINCO. “Photothermal reflectance microscopy as a tool for nondestructive evaluation of operating electronic devices”. 14th International
Conference on Thermal Engineering and Thermogrammetry (THERMO). Budapest,
June 2005, pp. 22 to 24.
- 77 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
Desenvolvimento do software supervisor para o ambiente JaVox-Nomad
Thiago Vallin Spina
Centro de Pesquisas Renato Archer - CenPRA
Divisão de Robótica e Visão Computacional (DRVC)
Rod. D. Pedro I, Km 143,6
13083-970 Campinas SP
[email protected]
Resumo
Este traballho apresenta a integração entre um ambiente interativo para
composição sonora, o Javox e um robô Nomad 200, visando o
desenvolvimento de coreografias robóticas . Para o desenvolvimento desta
integração foi utilizado como base um a arquitetura para robótica
TDL/TCM.
Palavras chave: Aural, Nomad 200, Javox, robô, trajetória, coreografia, supervisor
1. Introdução
O ambiente Aural explora um dos aspectos que vem sendo cultivado cada vez
mais no ambiente científico: o uso de robôs em ambientes artísticos. Para tanto, o
projeto tem como objetivo o uso de robôs em danças coreografadas geradas por
software, podendo ser dividido em 4 partes: JaVox, alimentação visual, o software
supervisor(Trajec_Control) e o uso do REAL, acesso remoto através do uso da
Internet. O desenvolvimento do software supervisor é o alvo deste documento.
O projeto desenvolvido teve como objetivo a criação de um sistema, que fizesse
a interligação entre o ambiente Aural[1] e o Nomad 200, permitindo que as trajetórias
desenvolvidas pelo primeiro fossem repassadas e executadas de modo satisfatório
pelo segundo. Isso foi feito modularizadamente, através da criação de um servidor de
informações sensoriais que alimenta o JaVox e um módulo desenvolvido para o
controle de trajetórias, Trajec_Control, baseado nos algoritmos do AURORA[3].
Previamente à construção destes módulos, houve um trabalho de estudo dos
sensores e das limitações físicas do robô, que consistiu de uma série de testes da
capacidade de movimento do mesmo. Paralelamente foi necessário a absorção do
conhecimento sobre a linguagem TDL/TCM, e a comunicação entre processos, IPC,
ambos utilizados na tese de mestrado de Christian Manrich[2].
2. Definições e características de TDL/TCM e IPC
2.1 TDL/TCM
A arquitetura para robótica TDL/TCM(Task Description Language/Task Control
Manager) foi desenvolvida pelos pesquisadores Reid Simmons e David Apfelbaum da
Carnegie Mellon University(CMU). A TDL é uma extensão da Linguagem C++, que
permite a sincronização e execução de tarefas, bem como o tratamento de exceções
geradas por estas, que impeçam que as mesmas sejam concluídas satisfatoriamente.
O TCM é um gerenciador utilizado pela TDL, que permite que as instruções escritas
- 78 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
em TDL sejam de fato executadas e seqüenciadas em uma ou mais threads. EssaS
execução ocorre no formato de árvore, onde cada tarefa é criada por um nó e
expandida pelo gerenciador até que seja realizada com sucesso ou não, concluindo
assim o objetivo de seu pai.
Os principais elementos da TDL são:
Commands – São os executores das tarefas. Não podem criar filhos e são as
folhas das árvores.
Monitors – São executores de tarefas periódicas, e também não podem criar
filhos.
Goals – São os objetivos a serem alcançados. Eles podem criar subtarefas,
Monitors e Commands,
2.2. IPC - Comunicação entre processos
O IPC(Inter-Process Communication), também desenvolvido por Simmons,
permite a comunicação entre processos distintos através do compartilhamento de
variáveis comuns a ambos. Essa comunicação é realizada através de um servidor
central, que permite a conexão de vários módulos simultâneos em diversas máquinas,
com arquiteturas e até mesmo sisetmas operacionais distindos. Em sistemas
complexos, robóticos ou não, essa modularização é vital, pois evita a criação de
blocos monolítcos de código que geram overhead e desperdício de recursos,
permitindo a paralelização de processos sendo indispensável para o desenvolvimento
do software supervisor para o ambiente JaVox-Nomad.
3. Teste básico das limitações de movimento do Nomad 200
Visto que o ambiente JaVox permite a criação de trajetórias, que são convertidas
em música conforme estas são percorridas, mostrou-se necessário a criação de
primitivas de movimentos harmoniosos através do desenvolvimento de pequenos
softwares que determinassem a capacidade de movimentação do Nomad 200. Assim,
foram criados softwares que fizessem o robô realizar movimentos como círculos,
quadrados e outros polígonos regulares, além de uma pequena imitação da dança
popularmente conhecida como “Cirandinha”, dando a base assim para o
desenvolvimento de algoritmos de controle de trajetória para o robô.
Dos pequenos experimentos, a principal limitação apresentada pelo Nomad 200,
foi a sua não-holonomia. Isso limita sua capacidade de mudanças bruscas de direção,
fazendo com que o algoritmo de controle de trajetória tivesse que ser elaborado de
forma que essas mudanças fossem contornadas ou evitadas do melhor jeito possível.
4. Controle de trajetória e o módulo Trajec_Control
4.1 Elaboração de algoritmos de controle de trajetória
Após a determinação das limitações do robô, iniciou-se o processo de
desenvolvimento de um algoritmo de controle de trajetória para o mesmo. Tentativas
iniciais através do controle da posição absoluta do robô, e a elaboração de algoritmos
que interpolassem os pontos de uma trajetória para posterior parametrização em
relação ao tempo, não se mostraram eficazes, assim, foi adaptado um algoritmo
utilizado no controle da trajetória do dirigível utilizado no projeto
- 79 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
AURORA(Autonomous Unmanned Remote mOnitoring Robotic Airship) que utiliza o
controle das velocidades axiais para manter o mesmo em curso.
Esse algoritmo funciona da seguinte maneira: dada uma seqüência de pontos da
trajetória, o robô percorre cada um destes através de retas traçadas entre pontos
adjacentes na seqüência. A velocidade a frente do robô é mantida constante, sendo
alterada somente a velocidade angular para ajuste da direção que ele deve seguir.
Caso a posição atual do robô não seja a que ele deveria estar atualmente é calculada
a distância de sua posição atual até a reta que liga os pontos atuais da trajetória, essa
distância é então minimizada o máximo possível através da correção da direção atual
do robô pela velocidade angular, até que esta seja a mesma da reta.
Quando o robô se aproxima a um raio R do próximo ponto da trajetória, um novo
ponto da seqüência é obtido, e o algoritmo de correção de trajetória é executado
novamente, até que a lista de pontos da trajetória se esgote. Esse raio R, foi
determinado de forma empírica, e os melhores resultados foram apresentados quando
ele é igual a 20% do tamanho do segmento de reta que liga o os 2 pontos da trajetória.
Melhoras no algoritmo de trajetória estão sendo feitas, a principal é permitir que
além de retas, curvas possam ser feitas entre os dois pontos. O algoritmo do dirigível
usado como base, permite que entre os pontos seja feita ao invés de uma reta, uma
curva desde que um dos parâmetros passado seja π (PI), e que o ângulo da curva
seja especificado. O maior problema aí está no cálculo automático desse ângulo, uma
vez que no algoritmo do dirigível esse parâmetro é passado manualmente. Outra
melhoria do robô, isso será necessário para que possa ser feita uma parametrização
da trajetória em relação ao tempo.
O algoritmo foi escrito em C/C++ e TDL uma vez que a arquitetura TDL/TCM
permite o monitoramento constante da trajetória, e que a comunicação com o Nomad
200 é feita através de chamadas às funções escritas em C/C++.
5. Interligação do módulo Trajec_Control com o JaVox
Para a interligação do módulo Trajec_Control com o JaVox, foi necessária a
integração entre os dois módulos, um escrito em C++/TDL e o outro em Java. Assim
foi desenvolvida uma interface Java - C/C++, permitindo a chamada de funções
escritas na linguagem C/C++, por métodos escritos em Java.
Isso foi feito utilizando a JNI(Java Native Interface), que é uma interface que
permite a chamada de funções em C/C++, bem como a passagem e retorno de
variáveis como parâmetros para as mesmas. A partir daí foi gerada uma biblioteca
chamada libjavox_nomad_interface.so(biblioteca dinâmica) contendo uma função que
envia através do IPC pontos para o módulo Trajec_Control, e uma outra função que
recebe pontos do módulo Sensors. Essas funções são utilizadas pelo JaVox para
enviar e receber pontos para o Nomad 200. Estes passam pela função de controle de
trajetória, e são executados seqüencialmente até o último enviado.
- 80 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
Figura 1: O robô simulado do Nomad 200, à esquerda, realiza a trajetória criada pelo
JaVox, à direita
6. Conclusão
A criação do módulo Trajec_Control foi realizada de forma eficiente, atendendo
às necessidades do ambiente Aural. Sua integração com o sistema foi feita de forma
suave, e desempenha um papel fundamental na concepção e execução do projeto.
Referências
[1]Moroni, A., AURAL: Ambiente robótico interativo aplicado à produção sonora e
visual. Projeto FAPESP 05/56186-9, linha de fomento Jovens Pesquisadores,
submetido em 2005.
[2]Manrich, C. “Uma Arquitetura de Controle para Robôs Cooperativos”. Dissertação
de Mestrado, Instituto de Computação, Universidade Estadual de Campinas,
Fevereiro 2001.
[3]Azinheira, J. R.; de Paiva, E. C; Ramos, J. G. e Bueno, S. S., “Mission Path
Following for an Autonomous Unnmaned Airship”.
- 81 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
- 82 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
Seqüenciamento de processos industriais: uma abordagem baseada em
Times Assíncronos utilizando múltiplas memórias
André P. Bartholomeu; Carlos A. S. Passos
Centro de Pesquisas Renato Archer - CenPRA
Rod. D. Pedro I, Km 143,6
13069-901 Campinas SP
[email protected]; [email protected]
Resumo
Este artigo apresenta um novo método para a resolução de problemas de
seqüenciamento do tipo flowshop, a partir das técnicas anteriormente
desenvolvidas. Os agentes são baseados nas metas-heurísticas Busca
Tabu e Algoritmos Genéticos. Elas são implementadas separadamente
para formar dois agentes puros e são utilizadas por dois conjuntos
(memórias) de soluções. Os agentes são então chamados para trabalhar
sobre esses conjuntos, na esperança de obtenção de melhoria de
resultados.
Palavras chave: Sequenciamento, A-Teams, Busca Tabu, Algoritmos Genéticos e
Múltiplas memórias.
1. Introdução
Este artigo apresenta um novo método para a resolução de problemas de
seqüenciamento do tipo flowshop, a partir das técnicas anteriormente desenvolvidas,
com a utilização de métodos heurísticos para a implementação de agentes para a
arquitetura A-Teams. É feita uma análise do comportamento desses agentes sobre
uma única memória, e sobre duas memórias que se comunicam através de uma
terceira, e suas contribuições para a qualidade das soluções encontradas e do tempo
de processamento total.
O modelo Flowshop trata-se basicamente de um fluxo unidirecional de produtos
através de um conjunto de etapas de produção, sempre respeitando uma mesma
ordem e seqüência. O objetivo de um sistema para resolver problemas de Flowshop é
encontrar um sequenciamento ótimo para N tarefas em M máquinas. Em Garey et al.
(1979) é provado que esse tipo de problema é NP-Difícil, sendo assim, são largamente
utilizadas técnicas baseadas em heurísticas para encontrar soluções para casos
práticos.
A arquitetura A-Teams foi concebida por Sarosh Talukdar em Talukdar & Souza
(1990 & 1992) no intuito de ser um paradigma de organização para sistemas de
resolução de problemas que demandam grande esforço computacional. Ela é baseada
no uso de agentes autônomos, que compartilham memórias contendo uma população
de possíveis soluções para o problema em questão.
As abordagens utilizadas são baseadas em duas metas-heurísticas largamente
utilizadas: Busca Tabu (BT) e Algoritmos Genéticos (AG), as quais são combinadas de
forma sinérgica em uma estrutura A-Teams. A primeira delas faz uso de agentes
baseados nas duas heurísticas trabalhando separadamente sobre uma memória.
Sendo assim, apesar de compartilharem as soluções disponíveis na memória
- 83 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
compartilhada do A-Teams, um agente não tem acesso direto às soluções geradas por
outro agente e, dessa forma, a probabilidade de um conjunto de soluções ser
processado sequencialmente por um agente e depois por outro é muito baixa. A
segunda abordagem trata-se de uma adição de uma nova memória, fazendo com que
os agentes trabalhem nas duas memórias, o que possivelmente traria melhorias nas
soluções, uma vez que, além do espaço de trabalho dos agentes ter sido aumentado,
houve também um aumento de seu trabalho sobre populações distintas de soluções.
2. O modelo A-Teams usado
Essa seção apresenta o A-Teams proposto, descreve o esquema de fluxo de
dados, o esquema de criação das populações iniciais e os agentes utilizados.
O modelo de A-Teams utilizado anteriormente foi concebido por Passos e
Fonseca (2004). Nele, inicialmente, era criada uma população aleatória. Duas porções
distintas de memórias eram utilizadas. A primeira delas guardava soluções completas
e era chamada de memória principal. A segunda guardava fragmentos de soluções e
era chamada de memória parcial. Um agente construtor R era responsável pela
geração de novas soluções completas. O agente destrutor D mantinha a população
em um tamanho aceitável. Dois Agentes de Melhoria eram responsáveis por otimizar
as soluções – agente Busca Tabu (BT) e agente Algoritmo Genético (AG). A interface
entre a memória principal e a memória parcial era feita através de um mecanismo
baseado em dois agentes que criavam um ciclo de fragmentação e reconstrução de
soluções – agente C e Cheap-NEH, respectivamente.
Utilizando-se desse modelo, implementou-se um novo, onde não mais é utilizada
uma memória principal, mas duas, que compartilham a memória parcial. As heurísticas
são as mesmas, mas possuem políticas de leitura das soluções diferentes para o
trabalho nas duas memórias principais. A Figura 1 ilustra a configuração do modelo.
Nela, os agentes são representados por setas e as memórias por retângulos.
BT
AG
Soluções Completas
(P1)
C
R
Agente
Inicializad
D
Cheap-NEH
Soluções Parciais
(S)
Cheap-NEH
C
Soluções Completas
(P2)
BT
D
AG
Figura 1 – Arquitetura A-Teams com agente híbrido.
3. Resultados Experimentais
A bateria de testes executada possibilitou uma comparação direta entre o
desempenho do A-Teams com uma única memória versus o do A-Teams com
múltiplas memórias. Dessa forma foi possível medir o impacto da introdução de uma
nova memória sobre o desempenho do sistema.
Esses testes foram realizados com um conjunto de arquivos de entrada
- 84 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
disponibilizados juntamente com a implementação anterior, e que compreendem um
conjunto de benchmarks propostos por Taillard (1993) e disponíveis na ORLIB
(Operational Research Library), no endereço http://mscmga.ms.ic.ac.uk/info.html, e
várias instâncias grandes. Inicialmente rodou-se cinco iterações para cada instância,
uma vez que estudos com benchmarks mostraram que após esse número a taxa de
melhoria por iteração decresce drasticamente. Em seguida os testes foram repetidos
com vinte (300% maior) iterações por instância.
Os resultados desses testes são ilustrados nas Figuras 2 e 3. Pode-se observar
que a introdução de uma nova memória não trouxe melhorias de performance para o
sistema, uma vez que os valores de makespam encontrados são muito semelhantes.
Além disso, observou-se que o tempo de processamento para essa nova abordagem
foi cerca de duas vezes maior que na abordagem anterior, com os testes rodando sob
o mesmo ambiente computacional.
Figura 2 – A-Teams com múltiplas memórias x memória única para 5 iterações:
Comparação de performance para grandes instâncias
Figura 3 – A-Teams com múltiplas memórias x memória única para 20 iterações:
Comparação de performance para grandes instâncias
- 85 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
4. Conclusões
A arquitetura de múltiplas memórias teve desempenho, em relação á qualidade
das soluções, semelhante ao verificado na arquitetura que utiliza apenas uma
memória para soluções completas. Já em relação ao tempo de solução, a arquitetura
A-Teams de memória única teve um tempo menor, em média a metade, do tempo de
processamento em comparação com o A-Teams de múltiplas memórias. Portanto, não
se justifica a adoção desta nova arquitetura sem a introdução de novos agentes.
5. Próximos trabalhos
Investigar a introdução de novos agentes que possam se beneficiar da
arquitetura de múltiplas memórias. Uma das possibilidades, é a experimentação de
agentes que exploram a diversificação de soluções procurando regiões no espaço de
soluções que possam levar a soluções de melhor qualidade. Outra possibilidade é a
exploração de programação paralela para melhorar o tempo de solução dos
algoritmos.
Referências
Aquino D.M.; Passos C.A.S; Estudo comparativo entre agentes puros e híbridos numa
arquitetura A-Teams. Anais da VIIIa. Jornada de Iniciação Científica do CenPRA,
Campinas, São Paulo, ISSN 1678-930X, outubro de 2006.
Aquino D.M.; Passos C.A.S. Seqüenciamento de processos industriais: uma
abordagem baseada em Times Assincronos utilizando agentes híbridos; Anais da
VIIa. Jornada de Iniciação Científica do CenPRA, Campinas, São Paulo, ISSN 1678930X, outubro de 2005.
Baker, K. R.; INTRODUCTION TO SEQUENCING AND SCHEDULING. Jhon Wiley,
1974.
Fonseca S.L.A.; Passos C.A.S. DESENVOLVIMENTO DE ALGORITMOS DE
SEQÜENCIAMENTO DE PROCESSOS INDUSTRIAIS UTILIZANDO TIMES
ASSÍNCRONOS; Anais da VIa. Jornada de Iniciação Científica do CenPRA,
Campinas, São Paulo, ISSN 1678-930X, outubro de 2004.
Passos C.A.S.; Aquino D.M., Tabu search and genetic algorithms: a comparative study
between pure and hybrid agents in an A-teams approach. Anais do XII International
Conference on Industrial Engineering and Operations Management,. Fortaleza - CE
– Brasil, outubro de 2006.
Passos, C.A.S.; Fonseca, S.L.A. SCHEDULING OF INDUSTRIAL JOBS USING AN ATEAM APPROACH. Renato Acher Research Center - CenPRA/MCT. Campinas, SP.
2003.
Passos C.A.S.; Nazareth L.G.P. FLOWSHOP SCHEDULING IN CHEMICAL
PROCESS INDUSTRIES USING TABU SEARCH ALGORITHM; 18ª International
Conference on CAD/CAM and Factories of the Future, INESC/Porto, Portugal, 2002.
Peixoto, H.P. METODOLOGIA DE ESPECIFICAÇÃO DE TIMES ASSÍNCRONOS
PARA PROBLEMAS DE OTIMIZAÇÃO INDUSTRIAL. Instituto de Matemática,
Estatística e Ciência da Computação, UNICAMP. Campinas, SP. 1995.
Murthy, S. et al. AGENT-BASED COOPERATIVE SCHEDULING. IBM T.J. Watson
Research Center. Yorktown Heights, NY.
Talukdar, S. et al. ASYNCHRONOUS TEAMS: COOPERATION SCHEMES FOR
AUTONOMOUS AGENTS. Carnegie Mellon University, 1996.
- 86 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
Caracterização da poliamida em função das características de
prototipagem rápida por sinterização seletiva a laser
Augusto C. Sánchez, Izaque A. Maia, Jorge Silva, Pedro Y. Moritomi, Marcelo Oliveira,
Elizabete Maria Saraiva Sanchez.
Divisão de Desenvolvimento de Produtos - CenPRA
Rod. D. Pedro I, Km 143,6
13069-901 Campinas SP
[email protected]; [izaque.maia, jorge.silva, pedro.noritomi,
marcelo.oliveira]@cenpra.gov.br, [email protected].
Resumo
O presente trabalho foi elaborado baseando-se no conceito de Manufatura
Rápida. Iniciou-se um programa de caracterização físico-mecânica dos
materiais de engenharia produzidos em dois equipamentos de
prototipagem disponíveis no CenPRA. Foi introduzido um programa de
acompanhamento contínuo do material de engenharia utilizado na máquina
de Sinterização Seletiva a laser – SLS, e um estudo sobre a utilização de
corpos de prova mais econômicos nos equipamentos de SLS e FDM.
Palavras chave: Prototipagem Rápida, SLS, FDM.
1. Introdução
A Sinterização Seletiva à Laser (SLS), é uma tecnologia de construção de
protótipos por deposição de fina camada de pó termofundível, depositado por um rolo
em uma superfície e aglutinado via aquecimento por um feixe de Laser. A Modelagem
por Deposição Fundida - Fused deposition modeling (FDM), é um processo aonde um
bico deposita o polímero em estado líquido, formando as camadas que irão compor a
peça final. A caracterização das propriedades físico-mecânicas de materiais gerados a
partir de métodos de prototipagem rápida é fundamental para que se possa prever o
comportamento dos protótipos, após sua confecção, através de simulações prévias.
Para realizar um trabalho completo de caracterização nas 6 direções possíveis,
Sanchez et al (2006) precisou obter doze corpos de prova para cada tipo de ensaio
realizado – tração, flexão e impacto – para cada possível orientação, num total de 216
corpos de prova. Tal volume ocupou por completo o espaço útil para confecção de
peças do equipamento. Um acompanhamento adequado das propriedades mecânicas
no decorrer do envelhecimento da matéria-prima mostrou-se inviável devido a este
volume, já que a obtenção destes corpos de prova inviabilizaria a confecção de outras
peças.
Figura 1. Orientação dos corpos de prova de tração na área de construção de peças da
máquina SLS 2000 (Sanchez et al,2006).
A American Society for Testing and Materials (ASTM) prevê duas principais
normas para ensaios de tração de materiais poliméricos.
A norma ASTM D 638 – 02a - Standard Test Method for Tensile Properties of
Plastics engloba materiais plásticos reforçados ou sem reforço, na forma de corpos de
- 87 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
prova padrão retirados de chapas, folhas ou moldados. A norma ASTM D 1708 – 02a Standard Test Method for Tensile Properties of Plastics By Use of Microtensile
Specimens também engloba materiais plásticos, para ensaios de microtensão. A
norma prevê espessuras de no máximo 3 mm.
Figuras 2 e 3. Corpos de prova de acordo com a norma ASTM D 638 – 02a e ASTM D 1708 – 02a.
2. Metodologia
Foram comparados os resultados de ensaios de resistência à tração em peças
prototipadas segundo as duas normas citadas, com o obejetivo de substituir os corpos
de prova da norma ASTM D 638, pelos da norma ASTM D 1708, de menores
dimensões.
Figura 4. Corpos de Prova ASTM D 1708, gerados no processo SLS.
Um corpo de prova da norma ASTM D 1708 possui um volume
aproximadamente 3,5 vezes menor que da norma ASTM D 638. Para que a
substituição dos corpos de prova ASTM D 638 pelos ASTM D 1708 fosse válida, os
ensaios inicialmente realizados consistiram em comparar o resultado de um ensaio de
tração de um corpo de prova ASTM D 638 com um corpo de prova ASTM D 1708,
gerados em um mesmo lote, sob as mesmas condições de fabricação, em regiões
próximas internamente à área de fabricação. Tal comparação foi realizada entre os
processos SLS e FDM. Os ensaios de tração foram realizados no Laboratório de
Biomateriais do Departamento de Materiais da Faculdade de Engenharia Mecânica da
Unicamp. Foram inicialmente gerados 6 corpos de prova de cada norma de ensaio, em
duas direções, XY e YX, de acordo com a figura 1, para os processos SLS e FDM.
A tabela abaixo mostra os resultados dos ensaios de tração obtidos para
comparação da Polyamida 12, sob dois tipos de corpo de prova.
Tabela 1. Resultados obtidos para o processo SLS.
Norma
Amostra
XY ASTM 1708
XY ASTM 638
YX ASTM 1708
YX ASTM 638
stress
Modulo
stress
Modulo
stress
Modulo
stress
Modulo
[Mpa]
[Mpa]
[Mpa]
[Mpa]
[Mpa]
[Mpa]
[Mpa]
[Mpa]
1
46,6
1043
46
1129
48,7
960
45,5
1362
2
48,8
949
47,9
1355
50,4
1033
50,7
1413
3
47,9
967
48,4
1349
48,1
832
48
1394
4
49,1
969
47,7
1392
46,7
937
48,5
1411
5
47,7
973
49,4
1440
46,5
993
45,9
1433
6
48,8
955
49,4
1445
49,5
971
50,9
1426
Média
48,15
976,00
48,13
1351,67
48,32
954,33
48,25
1406,50
Desvio P
0,94
34,05
1,27
116,40
1,54
68,20
2,29
25,62
- 88 -
IX Jornada de Iniciação Científica do CenPRA – JICC´2007
PIBIC/CNPq/CenPRA – Outubro de 2007 – Campinas – São Paulo
Pode-se notar que para os resultados de tensão de ruptura as médias
encontram-se muito semelhantes, para ambos os tipos de corpo de prova ensaiados.
Para os resultados de Módulo de Elasticidade, há diferenças entre cada uma das
normas ensaiadas, e para cada direção de fabricação.
Os resultados obtidos para os ensaios de tração realizados com corpos de prova
gerados através do processo FDM estão listados na tabela 2.
Tabela 2. Resultados obtidos para o processo FDM.
Norma
Amostra
XY ASTM 1708
XY ASTM 638
YX ASTM 1708
YX ASTM 638
stress
Modulo
stress
Modulo
stress
Modulo
stress
Modulo
[Mpa]
[Mpa]
[Mpa]
[Mpa]
[Mpa]
[Mpa]
[Mpa]
[Mpa]
1
24,2
1321
20
1219
23,9
1126
21
1218
2
24,4
1154
20,2
1207
23,4
1120
20,8
1209
3
24,2
1421
20,3
1190
23,9
1295
20,6
1209
4
23,9
1435
20,6
1167
24,4
1438
21,4
1251
5
24,2
1153
20,7
1233
24,2
1386
20,9
1250
6
24,3
1222
22,1
1226
24,4
1170
20,5
1210
Média
24,20
1284,33
20,65
1207,00
24,03
1255,83
20,87
1224,50
Desvio P
0,17
127,16
0,76
24,78
0,38
137,36
0,32
20,42
Os resultados obtidos demonstraram que, para este processo de fabricação, há
diferenças significativas entre os valores de resistência à ruptura para cada norma
utilizada. No entanto, a partir das diferenças entre os valores obtidos para o módulo de
Elasticidade, nota-se que o tipo de norma utilizada não influi significativamente nos
resultados obtidos. A diferença entre os valores de tensão de ruptura está
provavelmente relacionada à espessura dos corpos de prova, onde a parede da peça
recebe maior densidade de material que o núcleo. Novas amostras foram
encaminhadas para um ensaio de microscopia eletrônica; os resultados ainda não
estão disponíveis.
3. Conclusões
Para o processo SLS, verificou-se que entre as orientações XY e YX não há
diferenças significativas de resistência à tração, podendo-se então caracterizar o
material, a partir de agora, em uma só direção, e através de corpos de prova de
menores dimensões, economizando espaço na máquina.
Deve-se discutir a criação de uma norma específica para caracterização de materiais
obtidos a partir destes tipos de processo de fabricação e seu ensaio mecânico, e o
CenPRA poderia sugerir a criação desta norma.
O processo FDM precisa ser melhor estudado, pois observou-se diferenças
entre a resistência das peças de diferentes dimensões.
4. Referências
Sanchez, E. M. S.; Salgado, C. L.; Silva, J. V. L.; Maia, I. A.; Oliveira, M. F.; Zavaglia,
C. A. C. Evaluation of Mechanical properties of Rapid Prototyped Polyamides
After Accelerated Aging. PPS 23.
- 89 -