Equipa:	Grupo 11: Vasco Fernandes , Leonardo Rodrigues , João Mendes , João Cordeiro , Nuno Domingues
Empresa:	PICadvanced S.A.
Orientadores:	Prof. Mário Lima (DETI) Eng. Francisco Rodrigues (PICadvanced) Eng. Pedro Silva (PICadvanced)

A PICadvanced é uma empresa na área das telecomunicações que visa expandir a sua comercialização de transceivers optoelectrónicos e, para tal, atravessa desafios relacionados com a automatização da sua linha de produção. A empresa pretende implementar um braço robótico que automatize as tarefas de inserção, remoção e transporte destes transceivers nos diversos pontos de teste da linha de produção. No entanto, existem alguns erros de localização e/ou orientação destes transceivers que, levam à necessidade de otimização dos processos produtivos. Para tentar colmatar estas falhas, a nossa equipa, juntamente com a PICadvanced, pretende levar mais além esta automação e integrar no braço robótico, um sistema de visão que seja capaz de monitorizar, detetar e corrigir possíveis erros ao longo destas etapas.

Aqui deve ir o texto completo do Projeto. Não deve repetir o que está no resumo escrito em cima.

Desafio

O desafio proposto pela PICadvanced, foi o da integração de visão de computador num braço robótico, tornando-o capaz de manusear transceivers óticos, e os cabos de fibra ótica aos quais estes são ligados, de forma a aumentar a autonomia do processo de testagem destas peças.

XFP fibra Braço Robótico e a zona de trabalho Caixa de testes

Este robot teria de ser capaz de: detetar o transceiver, agarrá-lo corretamente, manuseá-lo e, por fim, inseri-lo num porto de uma caixa de testagem. Posteriormente, o braço robótico teria de receber o resultado deste teste, e identificar o transceiver e a fibra ótica a serem removidos da caixa de testagem. Uma vez removidos, o braço robótico teria de conseguir separar os transceivers operacionais (que passavam os testes), dos que demonstraram falhas.

Para a equipa, a solução para este desafio passou pela sua divisão em módulos:

1) Procurar uma câmara que apresentasse os requisitos necessários, a nível de resolução e campo de visão, que permitisse visualizar bem os XFP na área de trabalho do braço.
2) A criação de um suporte que acoplasse a câmara ao braço, assim como um suporte que ajudasse no manuseamento dos transceivers, para que estes pudessem ser inseridos.
3) Criar um sistema de visão capaz de identificar os transceivers óticos, assim como a identificação dos portos necessários na caixa de testagem.
4) Estabelecer uma comunicação entre o braço robótico e a caixa de testagem, de maneira a poder identificar quais os transceivers que passaram ou não passaram aos testes.
5) Estabelecer uma comunicação viável entre o braço robótico e o computador, por forma a que pudessem ser enviados dados relativos ao sistema de visão (coordenadas), que o braço pudesse interpretar.

Resultados

Grande parte destes módulos conseguiram ser implementados com sucesso, mas, contudo, alguns destes precisariam de ser tornados mais robustos com um maior número de testes e uma implementação mais demorada.

1) A câmara que a equipa decidiu utilizar mostrou-se ser suficiente para os objetivos do projeto. Tanto a nível de resolução como de campo de visão, a visualização nítida dos XFP a uma distância considerável, tal como os portos da caixa de testagem foram alcançados.
2) As peças desenhadas e criadas através de impressão 3D, para acoplar a câmara ao braço, também foram conseguidas com sucesso. Contudo, o suporte desenhado e impresso para facilitar o manuseamento dos transceivers ainda ficou um pouco aquém do esperado. Apesar de funcional, este suporte ainda precisaria de alguns ajustes para o tornar mais robusto.

Suporte da câmara Suporte do XFP

3) A criação de um sistema de visão, e o dataset/labelling associados, foi alcançado com sucesso, permitindo a correta identificação dos objetos em causa (transceivers e portos). Porém, um aspeto importante a salientar é o do dataset utilizado, que foi relativamente reduzido - apenas cerca de 250 fotos foram tiradas e utilizadas para treinar o sistema de visão. Para uma implementação em fábrica, um dataset maior deverá ser usado para garantir um grau de fiabilidade superior e evitar falsos positivos.

Reconhecimento dos transceivers Caixa de testagem com reconhecimento

4) A comunicação entre a caixa de testagem e o braço robótico (através do computador como mediador), foi alcançada com sucesso. Porém, mais testes ao funcionamento desta comunicação em conjunto com o resto do sistema, deverão ser levados a cabo no futuro. Nos testes que a equipa realizou não foram encontrados problemas, no entanto, este foi um dos módulos que foi tratado em último lugar, deixando pouco tempo para determinar a sua robustez.

Comunicação Caixa-PC

5) A comunicação entre o braço robótico (cliente) e o computador (servidor), demonstrou ser o módulo mais complexo de alcançar. Esta comunicação foi alcançada com algum grau de eficácia, porém, demonstrou alguns problemas de sincronismo. Apesar do grupo não ter conseguido resolver este problema por completo, a equipa estipulou um conjunto de passos a seguir, caso o projeto seja continuado, para realizar a restruturação necessária aos programas que compõe a parte do cliente (URScript) e do servidor (programa Python).

Comunicação Robot-PC

Como foi dito anteriormente, uma das partes mais crúciais da arquitetura do projeto, é a comunicação entre sistemas. O grupo passou por várias metodologias até chegar a uma que realmente resultasse:

Arquitetura final do sistema

O cliente (braço robótico) envia triggers que solicitam informação ao programa python, e mantem essa linha de comunicação aberta, apenas durante essa troca de informação. O tipo de informação que é enviada ao robot nessa troca, vem sobre a forma de imagens de onde são extraídas coordenadas, que depois são interpretadas pelo controlador do robot - um programa na interface gráfica do tablet do robot (Polyscope), escrito sobre a forma de um URScript. Esse programa tem depois a tarefa de transformar as coordenadas recebidas em movimentos possíveis. As mensagens enviadas pelo braço robótico são do tipo:

“Test Done?”: mensagem enviada sempre num novo início de ciclo de comunicação, com o papel de despoletar qual a próxima operação a seguir: ir à procura de XFP’s ou removê-los da TestBox.
“Test Position”: mensagem enviada após receber ‘1’ como resposta ao trigger “Test Done?”. Esta mensagem, após o movimento do robot, faz com que este fique à espera de receber dados relativos às posições dos XFP’s na TestBox.
“Take XFP photo”: mensagem enviada após receber ‘0’ como resposta ao trigger “Test Done?”. Esta mensagem tem a função de desencadear a captura de uma fotografia na zona de trabalho do robot. Desta foto são extraídas as coordenadas processadas pelo programa Python, para que o braço robótico possa realizar a operação de se mover e depois agarrar o transceiver. Após esta operação, o programa URScript realiza também uma série de movimentos que permite ao robot manusear e posicionar-se em frente à TestBox, de modo a poder inserir o XFP.
“Find free port”: mensagem enviada após o robot se posicionar à frente da TestBox, no final do ponto anterior. A mensagem funciona, no fundo, como a mensagem “Test Position”, mas com processos inversos. Os dados que são obtidos pela captura da foto, referem agora às coordenadas dos portos livres na TestBox, e despoletam um conjunto de movimentos que permitem que o braço robótico coloque os XFP’s na caixa de testes e posteriormente as fibras óticas nestes.

No fundo o sistema trabalha como o seguinte diagrama de estados: