Leonilson de Araújo Barboza · manualmente. As execuções de testes de rotação e translação...

Pós-Graduação em Ciência da Computação

Leonilson de Araújo Barboza

AR(M)OBO TEST:

UM BRAÇO ROBÓTICO PARA SUPORTE À TESTES AUTOMÁTICOS

DE RETRATO E PAISAGEM PARA SMARTPHONES

Universidade Federal de Pernambuco [email protected]

www.cin.ufpe.br/~posgraduacao

RECIFE 2016


AR(m)obo Test: Um Braço Tobótico para Suporte à Testes automáticos de Retrato e Paisagem para

Smartphones

ORIENTADOR(A): Prof. Dr. Juliano Manubu Iyoda

RECIFE 2016

Este trabalho foi apresentado à Pós-Graduação em Ciência

da Computação do Centro de Informática da Universidade

Federal de Pernambuco como requisito parcial para

obtenção do grau de Mestre Profissional em Ciência da

Computação.

Catalogação na fonte Bibliotecária Monick Raquel Silvestre da S. Portes, CRB4-1217

B239a Barboza, Leonilson de Araújo

AR(m)obo Test: um braço robótico para suporte à testes automáticos de retrato e paisagem para smartphones / Leonilson de Araújo Barboza. – 2017.

111 f.:il., fig., tab. Orientador: Juliano Manubu Iyoda. Dissertação (Mestrado) – Universidade Federal de Pernambuco. CIn,

Ciência da Computação, Recife, 2017. Inclui referências.

1. Ciência da computação. 2. Braço robótico. I. Iyoda, Juliano Manubu (orientador). II. Título. 004 CDD (23. ed.) UFPE- MEI 2017-150


AR(m)obo Test: Um Braço Robótico para Suporte à Testes Automáticos de Retrato e Paisagem para Smartphones

Dissertação de Mestrado apresentada ao Programa de Pós-Graduação em Ciência da Computação da Universidade Federal de Pernambuco, como requisito parcial para a obtenção do título de Mestre em Ciência da Computação

Aprovado em: 09/09/2016.

BANCA EXAMINADORA

__________________________________________

Prof. Dr. Márcio Lopes Cornélio Centro de Informática / UFPE

__________________________________________

Prof. Dr. Lucas Albertins de Lima Departamento de Estatística e Informática / UFRPE

__________________________________________

Prof.Dr.JulianoManabuIyoda

Centro de Informática / UFPE (Orientador)

Primeiramente eu dedico este trabalho a Deus que me proporcionou

o dom da vida, pela força e perseverança para terminar essa pesquisa.

Aos meu pais, Roberto Barboza e Edneide Iracema de Araújo pela

educação que me proporcionaram e por sempre me apoiar em todas

as minhas decisões que precisei tomar. À minha esposa, Suzane

Moreira da Silva por estar ao meu lado sempre, me apoirando e

confortando quando necessário.

AGRADECIMENTOS

Nesta seção, queria aproveitar para agradecer a todas as pessoas que, direta ou

indiretamente contribuíram para o progresso pessoal e acadêmico, tendo-me ajudado a superar este

desafio que particularmente incluiu compentências que não possuía. As seguintes pessoas eu

gostaria de deixar um agradecimento especial: Ao meu orientador Prof. Juliano Manabu Iyoda

pela constante disponibilidade, pelo seu indispensável apoio, pela ajuda contínua, pelos

conhecimentos transmitidos, pela enorme paciência que teve durante esses dois anos e pelo

incentivo prestado, sobretudo nos momentos em que as frustrações já tinham alcançado o mais

alto nível durante o desenvolvimento deste trabalho. Ao meu amigo Prof. Msc Darlan Florêncio

de Arruda que me acompanhou ao longo deste percurso com seus comselhos, pelas sugestões e

por todo apoio para que esse trabalho fosse concluído com sucesso.

Ao CESAR, Centro de Estudos e Sistemas Avançados do Recife, na pessoa do Benedito

Alberto de Macedo que depositou sua confiança neste trabalho e que financiou todo o material

necessário para a implementação deste projeto. Sem a ajuda do CESAR e das pessas responsáveis

pelo laboratório de Robótica este trabalho seria mais uma ideia a permanecer em um papel. Ao

CESAR e em especial ao Benedito, carinhosamente apelidado por (“Beto”) eu venho agradecer

pelo maravilhoso ser humano e profissional que ele é.

Aos meus amigos, que me acompanharam ao longo dessa jornada e que foram cruciais para

que todos os resultados fossem alcançados, em particular Renato Henrique (“Re”), Guilherme

Henrique de Souza Silva (“Guiga”), Bruno Costa Bourbon (“Brunão”), Diogo Lacerda Coutinho

(“Diogo”) que estiveram comigo e que colocaram a mão na massa para me ajudar a desenvolver

este projeto e a ensinar como fazê-lo. A eles eu dedico todo o meu carinho e respeito, pois sem

eles esse trabalho não seria possível de ser realizado.

Por fim, apesar de não haver palavras que possam ser mencionadas por mim,

primeiramente Deus, responsável por esta conquista, segundo por minha mãe, Edneide Iracema de

Araújo e meu pai, Roberto Barboza e a minha amada esposa Suzane Moreira da Silva que sempre

acreditaram em mim e que depositaram sua fé, amor e paciência durante todo esse tempo.

RESUMOQuando pensamos em testes de software para dispositivos móveis como smartphones e

tablets, o grande desafio das empresas é encontrar meios mais econômicos e eficientes para testar

as aplicações que são desenvolvidas para esse tipo de produto. Existem também aspectos dentro

do processo de testes que ainda estão deficientes devido à grande complexidade que os novos

smartphones apresentam como, por exemplo: uma interface baseada em gestos, controle de voz,

sensores de movimentos, sensores de posição, GPS e outros. Testar sensores de smartphones como

acelerômetro e giroscópio requer novas técnicas de validação, além de ser caro quando executado

manualmente. As execuções de testes de rotação e translação eventualmente têm que ser feitas no

aparelho e não em emuladores. Atualmente pouco se sabe sobre o uso de ferramentas que

substituam o trabalho braçal por métodos automáticos. Sendo assim, este trabalho propõe o

desenvolvimento e uso de um braço robótico articulado e uma aplicação Android de controle e

testes com o intuito de testar o comportamento do software e do hardware durante as mudanças de

orientação para os modos retrato e paisagem. O projeto do braço robótico foi modelado através de

diagramas SysML e implementado integrando tecnologias como Android, servomotores,

Bluetooth e Arduino. Também propusemos métricas a serem usadas no projeto, mas que também

são aplicáveis a qualquer projeto de automação de teste de caixa-preta robotizada. Estimamos as

medições destas métricas para o AR(m)obo Test e concluímos que é possível introduzir

manipuladores robóticos para validar o comportamento do software através das mais variadas

mudanças de orientação do smartphone de uma maneira lógica, segura, precisa e com retorno ao

investimento em poucos meses.

Palavras-chave: Braço robótico. Teste de caixa preta. Acelerômetro. Giroscópio. SysML.

ABSTRACT

When we think about performing tests for mobile devices such as smartphones and tablets,

the companies biggest problem is to find more efficient and less expensive ways to test their

applications. In addition, some aspects of the software testing process lack previous knowledge

due to the level of complexity posed by the new smartphones interfaces such as gesture based user-

interface, voice control, moving sensors, position sensor and GPS. Executing tests on smartphones

sensors such as accelerometer and gyroscope requires new validation techniques. In addition, these

techniques are usually expensive, especially when performing manual-based tests. The execution

of both rotation and translation tests must be performed using the device itself rather than using

emulators. Nowadays there has been little scientific research aimed at understanding how to

replace the manual work for automatic methods. Therefore, in this work we propose the

development and use of an articulated robotic arm as well as an Android application to control the

test execution. The arm was design in SysML. In addition, technologies such as Android,

servomotors, bluetooth and Arduino were used during the implementation phase. We also propose

metrics to be used in the project. These metrics are applicable to any sort of robotic black-box

automation project. We estimated the values for the metrics proposed and showed that the return

on investment happens after few months.

Keywords: Robotic arm. Black-box test. Accelerometer. Gyroscope. SysML.

LISTA DE FIGURAS

FIGURA1PILHADEPROTOCOLOSBLUETOOTH.ADAPTADO:LABIOD,H.,ETAL(2007)..................................................................26FIGURA2SERVOMOTORUTILIZADOEMUMHELICÓPTERORC.FONTE:ENGINEERSGARAGE,(2016)...............................................28FIGURA3BRAÇOSROBÓTICOSFABRICADOSCOMSERVOMOTORES.FONTE:ENGINEERSGARAGE,(2016).........................................29FIGURA4RELACIONAMENTOENTREUMLESYSML:HOLT,J.,&PERRY,S.(2008).....................................................................30FIGURA5DIAGRAMADETAXONOMIASYSML.FONTE:WEILKIENS,(2007)................................................................................31FIGURA6EXEMPLODEDIAGRAMADESEQUÊNCIA.SYSMLSPECIFICATION;V1.4(2015)..............................................................33FIGURA7DIAGRAMADEMAQUINADEESTADOSSIMPLESPARAUMJOGODEXADREZ.FONTE:HOLT,J.,&PERRY,S.,(2008).............34FIGURA8EXEMPLODEUMDIAGRAMADEDEFINIÇÃODEBLOCOS.FONTE:DELLIGATTI,(2008).....................................................36FIGURA9EXEMPLODEUMMETA-MODELOPARCIALDEUMDIAGRAMAINTERNODEBLOCOS.........................................................37FIGURA10VISÃOGERALDOPROJETOAR(M)OBOTEST.FONTE:AUTORIAPRÓPRIA......................................................................41FIGURA11DIAGRAMADEREQUISITOSEMSYSML.FONTE:AUTORIAPRÓPRIA............................................................................45FIGURA12DIAGRAMADEBLOCOSDOPROJETOAR(M)OBOTEST.FONTE:AUTORIAPRÓPRIA........................................................46FIGURA13DIAGRAMAINTERNODEBLOCOSDOPROJETOAR(M)OBOTEST.FONTE:AUTORIAPRÓPRIA...........................................48FIGURA14DIAGRAMADESEQUENCIADOPROJETOAR(M)......................................................................................................51FIGURA15DIAGRAMADEMAQUINADEESTADOSDAESPECIFICAÇÃOSYSML.FONTE:AUTORIAPRÓPRIA........................................52FIGURA16ARDUINOMEGA2560....................................................................................................................................54FIGURA17MÓDULOBLUETOOTHHC-06............................................................................................................................56FIGURA18DYNAMIXELMX-64..........................................................................................................................................57FIGURA19DYNAMIXELAX-18A........................................................................................................................................59FIGURA20BASECOMVISTAFRONTAL..................................................................................................................................61FIGURA21BASECOMVISÃOLATERAL..................................................................................................................................61FIGURA22MOVEL_MX-64MEDIDA1................................................................................................................................62FIGURA23MOVEL_MX-64MEDIDA2................................................................................................................................62FIGURA24FIXO_MX-64MEDIDA1.....................................................................................................................................62FIGURA25FIXO_MX-64MEDIDA2.....................................................................................................................................62FIGURA26OSSOMEDIDA1...............................................................................................................................................63FIGURA27OSSOMEDIDA2...............................................................................................................................................63FIGURA28MOVEL_AX-18AMEDIDA1...............................................................................................................................64FIGURA29MOVEL_AX-18AMEDIDA2................................................................................................................................64FIGURA31CASE_FONE.....................................................................................................................................................65FIGURA30FIXO_CASE......................................................................................................................................................65FIGURA32BRAÇOROBÓTICOEMOPERAÇÃO2......................................................................................................................66FIGURA33BRAÇOROBÓTICOEMOPERAÇÃO1......................................................................................................................66FIGURA35BRAÇOROBÓTICOEMMODODESLIGADO1............................................................................................................66FIGURA34BRAÇOROBÓTICOEMMODODESLIGADO2............................................................................................................66FIGURA36MX-64FIXADOÀBASE......................................................................................................................................67FIGURA37MX-64FIXADOAOCOTOVELO............................................................................................................................67FIGURA38AX-18FIXADOAOPULSO(AX-18)......................................................................................................................67FIGURA39ÍCONEDOAR(M)OBOTESTAPP..........................................................................................................................69FIGURA40TELADECONFIGURAÇÃOAR(M)OBOTESTAPP.......................................................................................................69FIGURA41TELADERESULTADOSDOSTESTES........................................................................................................................70FIGURA42PROCESSODEFLUXODEDADOS...........................................................................................................................70FIGURA43PROCESSODETRANSMISSÃODEMENSAGENS.........................................................................................................71FIGURA44CÓDIGOINICIAL................................................................................................................................................74FIGURA45COMUNICAÇÃOBLUETOOTH...............................................................................................................................75FIGURA46CÓDIGOLOOP..................................................................................................................................................76FIGURE47-TELAPRINCIPALDAAPLICAÇÃO.FONTE:ELABORADOPELOAUTOR............................................................................80FIGURE48-TELAGERENCIADORDETESTES.FONTE:ELABORADOPELOAUTOR............................................................................81FIGURE49-TELACRIAÇÃODESUÍTE...................................................................................................................................82FIGURE50-POP-UPCRIAÇÃODETESTES.............................................................................................................................83FIGURE51-PROCESSODEEXECUÇÃODESUÍTESDETESTES.....................................................................................................84FIGURE52-TELADERESULTADOS......................................................................................................................................85FIGURE53-TELADERESULTADOSPORSUÍTE........................................................................................................................86FIGURE54-RESULTADO:FORMASIMPLIFICADA....................................................................................................................87FIGURE55-TELADERESULTADOS:MODOFULL....................................................................................................................88

FIGURA56TOUCH-SCREENTESTINGROBOTS.FONTE:KANSTRÉN,T.ATAL(2015)....................................................................101FIGURA57TOUCHBOT.FONTE:ENGADGET(2014).............................................................................................................101

LISTA DE TABELAS

TABELA1REQUISITOSDESOFTWARE...................................................................................................................................43TABELA2REQUISITOSDEHARDWARE..................................................................................................................................44TABELA3BLOCOSATUADORESESUASANGULAÇÕES..............................................................................................................47TABELA4MÉTODOSDEOPERAÇÕESDOSERVOMOTOR...........................................................................................................49TABELA5MÉTODOSDEOPERAÇÕESDOSSERVOSMOTORES.....................................................................................................50TABELA6LISTADEMATERIAISUTILIZADOS............................................................................................................................53TABELA7ESPECIFICAÇÃODOARDUINOMEGA2560............................................................................................................55TABELA8ESPECIFICAÇÃODOMÓDULOBLUETOOTHHC-06.....................................................................................................56TABELA9DYNAMIXELMX-64SPECIFICATION.FONTE:DYNAMIXEL...........................................................................................58TABELA10DYNAMIXELAX-18ASPECIFICATION.FONTE:DYNAMIXEL.......................................................................................59TABELA11MÉTODOSDASMENSAGENS...............................................................................................................................72TABELA12ESTRUTURADEMENSAGEM................................................................................................................................73TABELA13ESQUEMADECASOSDETESTES...........................................................................................................................73TABELA14TESTESPORMINUTO.........................................................................................................................................95

LISTA DE ABREVIATURAS E SIGLAS

Baseband Banda Base bdd Diagrama de Definição de Blocos Black Box Caixa Preta BR/EDR Taxa de bits/taxa de dados realçada DC Corrente contínua Endless turn Giro Infinito Feature Característica FTDI Future Technology Devices International Gaps Lacunas GATT Generic Attribute Profile Grey Box Caixa Cinza GUI Graphical User Interface Half duplex Sistema que fornece comunicação em ambas as direções Hoppin Salto de canais ibd Diagrama Interno de Blocos ICSP In-system programming IDC International Data Corporation IEEE Institute of Electrical and Electronics Engineers L2CAP Logical link control and adaptation protocol LMP Link manager protocol Open source Código Aberto PathPlanning Planejamento de Caminho PCs Computadores de mesa e laptops Peer-to-peer Entre pares Piconets Adhoc network PWM Pulse Width Modulation QA Garantia da Qualidade RC Rádio Controle RS485 Multi-point specification Sd Diagramas de Sequência SPP Bluetooth Serial Port Profile Stm Diagrama de Maquina de Estados SysML The Systems Modeling Language TTL Level Multi Drop Bus UML Unified Modeling Language URATs Portas seriais de hardware USB Universal Serial Bus V&V Verificação & Validação White Box Caixa Branca

SUMÁRIO

1 INTRODUÇÃO ............................................................................................................................ 14 1.1 MOTIVAÇÃO .............................................................................................................................. 15 1.2 CARACTERIZAÇÃO DO PROBLEMA .................................................................................. 16 1.3 OBJETIVOS ................................................................................................................................. 17 1.4 CONTRIBUIÇÕES ...................................................................................................................... 17 1.5 ESTRUTURA DA DISSERTAÇÃO ........................................................................................... 18 2 FUNDAMENTAÇÃO TEÓRICA .............................................................................................. 19 2.1 TESTE DE SOFTWARE ............................................................................................................. 20 2.1.1 PROCESSO DE TESTES DE SOFTWARE ................................................................................. 21 2.1.2 ABORDAGENS DE TESTE DE SOFTWARE ............................................................................ 22 2.1.3 TESTE DE CAIXA PRETA .......................................................................................................... 22 2.1.4 PROJETO DE CASOS DE TESTES ............................................................................................. 23 2.2 BLUETOOTH .............................................................................................................................. 24 2.2.1 PROTOCOLO BLUETOOTH ....................................................................................................... 25 2.3 SERVOMOTORES ..................................................................................................................... 27 2.4 SYSML .......................................................................................................................................... 30 2.5 DIAGRAMAS COMPORTAMENTAIS ................................................................................... 32 2.5.1 DIAGRAMA DE SEQUÊNCIA .................................................................................................... 32 2.5.2 DIAGRAMA DE MAQUINA DE ESTADOS .............................................................................. 34 2.6 DIAGRAMAS ESTRUTURAIS ................................................................................................. 35 2.6.1 DIAGRAMA DE DEFINIÇÃO DE BLOCOS .............................................................................. 35 2.6.2 DIAGRAMA INTERNO DE BLOCOS ........................................................................................ 37 2.7 CONSIDERAÇÕES FINAIS ...................................................................................................... 38 3 PROJETO E IMPLEMENTAÇÃO ........................................................................................... 39 3.1 INTRODUÇÃO ............................................................................................................................ 40 3.2 DESCRIÇÃO DO PROJETO ..................................................................................................... 40 3.3 PROJETO AR(M)OBO TEST EM SYSML .............................................................................. 42 3.3.1 REQUISITOS ................................................................................................................................ 42 3.3.2 REQUISITOS DE SOFTWARE ................................................................................................... 42 3.3.3 REQUISITOS DE HARDWARE .................................................................................................. 44 3.3.4 DIAGRAMA DE REQUISITOS EM SYSML .............................................................................. 44 3.4 ARQUITETURA DO PROJETO EM SYSML ......................................................................... 46 3.4.1 DIAGRAMA INTERNO DE BLOCOS ........................................................................................ 48 3.4.2 DIAGRAMA DE SEQUÊNCIA .................................................................................................... 51 3.4.3 DIAGRAMA DE MAQUINA DE ESTADOS .............................................................................. 52 3.5 IMPLEMENTAÇÃO ................................................................................................................... 53 3.5.1 MATERIAIS UTILIZADOS ......................................................................................................... 53 3.5.2 KIT ARDUINO MEGA 2560 ........................................................................................................ 54 3.5.3 MÓDULO BLUETOOTH ............................................................................................................. 55 3.5.4 MOTORES DYNAMIXEL ........................................................................................................... 57 3.5.5 DYNAMIXEL MX-64 ................................................................................................................... 57 3.5.6 DYNAMIXEL AX-18A ................................................................................................................ 58 3.6 MONTAGEM ............................................................................................................................... 60 3.6.1 ESTRUTURA MECÂNICA .......................................................................................................... 60 3.6.2 BASE ............................................................................................................................................. 61 3.6.3 OMBRO ......................................................................................................................................... 61 3.6.4 COTOVELO .................................................................................................................................. 62 3.6.5 PULSO ........................................................................................................................................... 64

3.6.6 MÃO .............................................................................................................................................. 65 3.6.7 PROTÓTIPO MONTADO ............................................................................................................ 65 3.7 AR(M)OBO TEST APP ............................................................................................................... 68 3.8 FLUXO DE DADOS .................................................................................................................... 70 3.8.1 LÓGICA DE TRANSFERÊNCIA DE DADOS ........................................................................... 71 3.9 DESENVOLVIMENTO DO FIRMWARE ............................................................................... 74 3.10 CONSIDERAÇÕES FINAIS ...................................................................................................... 77 4 ESTUDO DE CASO .................................................................................................................... 78 4.1 DESCRIÇÃO DO ESTUDO DE CASO ..................................................................................... 79 4.2 FUNCIONAMENTO PASSO-A-PASSO ................................................................................... 80 4.3 CONSIDERAÇÕES FINAIS ...................................................................................................... 89 5 MÉTRICAS .................................................................................................................................. 90 5.1 INTRODUÇÃO ............................................................................................................................ 91 5.1.1 AUTONOMIA ............................................................................................................................... 91 5.1.2 PAUSA .......................................................................................................................................... 92 5.1.3 JORNADA DE TRABALHO ........................................................................................................ 92 5.1.4 PAUSA ENTRE JORNADAS ....................................................................................................... 93 5.1.5 TESTE POR MINUTO .................................................................................................................. 94 5.1.6 PRODUTIVIDADE ....................................................................................................................... 95 5.1.7 ECONOMIA .................................................................................................................................. 96 5.2 CONSIDERAÇÕES FINAIS ...................................................................................................... 96 6 CONCLUSÕES ............................................................................................................................ 98 6.1 INTRODUÇÃO ............................................................................................................................ 99 6.1.1 TRABALHOS RELACIONADOS ............................................................................................... 99 6.2 BRAÇOS ROBÓTICOS ............................................................................................................ 100 6.3 CONCLUSÃO ............................................................................................................................ 102 6.4 CONTRIBUIÇÕES .................................................................................................................... 103 6.5 LIMITAÇÕES ............................................................................................................................ 104 6.6 RECOMENDAÇÕES PARA TRABALHOS FUTUROS ...................................................... 105 REFERÊNCIAS ......................................................................................................................... 106

Capítulo1–Introdução

14

Capítulo

11 INTRODUÇÃO

Este capítulo descreve a introdução deste trabalho, bem como a motivação, a questão

de pesquisa, os objetivos do trabalho. Por fim, é apresentada a estrutura desta dissertação em

capítulos.


15

1.1 MOTIVAÇÃO

Nos últimos anos, a venda de celulares com recursos limitados se tornará uma minoria até

2018 e pela primeira vez após 2015, estimasse que mais de 2,56 bilhões de pessoas comprarão

smartphones, o que representa mais da metade de 51,7% de todos os usuários de telefones celulares

do mundo (EMARKETER, 2014). Segundo a Emarketer, o comércio de telefonia móvel em 2015

foi impulsionando pela busca de dispositivos com telas ainda maiores (EMARKETER, 2016). De

acordo com o IDC (International Data Corporation) o mercado de smartphones em todo mundo

cresceu cerca de 13,0% em 2015, com 341,5 milhões de vendas. O sistema operacional Android

lidera o mercado com uma participação de 82,8% em 2015 (IDC, 2016). Com esse crescimento

nas vendas de smatphones em larga escala, aumentam ainda mais o nível de exigência dos usuários

por produtos com maior qualidade.

Dado o crescimento dos dispositivos móveis no mercado, novas áreas de testes de software

estão emergindo. A garantia de qualidade (QA) é uma parte crítica do processo de

desenvolvimento de aplicativos móveis focando na busca por problemas que, antes, caíam nas

mãos dos usuários (TESTDROID, 2014). Testar sistemas móveis requer um conhecimento mais

avançado, por exemplo: o usuário pode tocar na tela do dispositivo em mais de um ponto

simultaneamente e interagir com o software através da fala ou por gestos (EMARKETER, 2014).

De acordo com ESBJORNSSON, L., 2015, é importante testar as aplicações móveis através das

interações com a interface física (seja gráfica ou gestual) da mesma forma que um usuário comum

faria. Se a interface não for testada corretamente, o usuário poderá ser exposto a falhas que podem

estragar a sua experiência com o smartphone.

Para MUCCINI, H., et al (2012), o crescimento exponencial do mercado móvel impõe uma

atenção aos aspectos de confiabilidade sobre as aplicações que rodam sobre eles. Vários estudos

apontam que aplicações móveis não estão livres de erros e que novas abordagens da Engenharia

de Software são necessárias para testar essas aplicações (MUCCINI, H., et al, 2012; C. Hu e I.

NEAMTIUN, 2011; A. K. MAJI et al, 2010). Visando a melhoria do processo de qualidade no

desenvolvimento de aplicações móveis, robôs estão sendo desenvolvidos como ferramentas de

apoio a testes automáticos para smartphones e tablets.

Automação de testes para sistemas móveis utilizando robôs ainda é um assunto recente que

está ganhando espaço na academia e na indústria (KYLLONEN, KALLE., 2015). O uso de robôs

está substituindo cada vez mais o trabalho manual realizado por seres humanos (DA FONSECA,


16

C. S., 2016). Tais robôs podem ser utilizados para testar GUI ou gestos porque eles são capazes

de imitar o usuário final de forma satisfatória e eficiente (MATTI VUORI, 2014).

Um projeto da NOKIA (2015) em parceria com a Universidade de Tecnologia de Tampere

desenvolveu um robô acoplado com uma câmera e com dedos que, por sua vez, é capaz de olhar

para a tela do smartphone e pressionar os botões para encontrar sequências de textos, números,

escrita de textos, arrastar e soltar ícones, localizar ícones e símbolos diretamente na tela. Isto

significa que o robô pode fazer basicamente quase as mesmas funções que um testador humano

pode fazer com as mãos e os com os olhos, exceto criar gestos para reconhecimento visual.

Diante do exposto, novos conceitos e ferramentas de testes devem ser considerados para

tornar o processo de testes ainda mais criterioso, de modo que possibilite uma maior cobertura das

funcionalidades e uma maior eficiência no modo em que os testes são aplicados. Portanto, para

garantir a qualidade no contexto de testes para sistemas móveis é fundamental criar novas

abordagens de testes a fim de solucionar gaps que comumente não são resolvidos através das

práricas conhecidas e disponíveis na literatura.

1.2 CARACTERIZAÇÃO DO PROBLEMA

Antes de estar disponível no mercado, o celular físico precisa ser testado por um usuário,

pois testes em simuladores ou testes em software já foram realizados e não servem mais. O teste

final por um usuário é imprescindível. Porém, testar manualmente é caro. Uma pessoa tem que

ficar dedicada a esta tarefa muitas vezes tediosa e desperdiçando um tempo valioso que poderia

ser alocado a outra atividade mais intelectual ou criativa.

Além disso, os mecanismos convencionais de testes como, por exemplo, testes automáticos

via scripts e testes manuais não são suficientes para testar sensores embarcados como o

acelerômetro e o giroscópio, seja por tratar de uma simulação (scripts), seja pela falta de precisão

nos movimentos (manual). Até onde conseguimos pesquisar, foram encontrados trabalhos sobre

usos de braço robóticos para automação de outras tarefas, porém um pouco distante do campo de

pesquisa proposto por etsa dissertação. Realizar testes em sensores de smartphones constitui um


17

grande desafio, sendo, então, uma área importante a ser explorada e trabalhada a fim de encontrar

uma solução para suprir essa lacuna.

1.3 OBJETIVOS

O objetivo geral deste trabalho é apoiar a execução de testes funcionais de acelerômetro e

giroscópio através do uso de um braço robótico. Pretende-se permitir que um braço robótico

substitua o trabalho manual de um ser humano no contexto de teste físico, possibilitando mudanças

de orientações com angulação controlada e precisa. Tal atividade será realizada de forma

automática.

Para que se possa alcançar o objetivo geral, alguns pontos específicos devem ser

alcançados:

1. Modelar o braço robótico usando modelos na notação SysML;

2. Implementar uma aplicação Android para testes que permita a seleção de

movimentos e ângulos a fim de verificar o comportamento do software durante

mudanças de orientação do smartphone;

3. Estabelecer uma comunicação sem fio entre o smartphone e o braço robótico a

fim de evitar enroscos com cabos durante a operação do braço;

4. Notificar o testador com informações sobre os testes realizados de forma que seja

possível inferir um nível de aceitação sobre cada teste executado;

5. Possibilitar uma leitura adequada sobre os resultados de cada teste diretamente na

tela do celular e através de registro de logs.

1.4 CONTRIBUIÇÕES

Como resultado do trabalho apresentado por esta dissertação, destaca-se: criação de um

modelo de arquitetura de hardware e software através da linguagem de modelagem gráfica

SysML, e a implementação e montagem de um braço robótico articulado que substituirá o trabalho

braçal humano para execução de testes de rotação de smartphones.

Espera-se que o modelo proposto de arquitetura da aplicação de testes e o modelo de

implementação e montagem de um braço robótico possam ser utilizados, mediante devidas


18

adaptações, por qualquer empresa de tecnologia ou afins que necessite introduzir o conceito de

robótica como ferramenta de apoio a testes automáticos para smartphones com Android.

Métricas foram propostas e suas medições foram utilizadas para termos uma noção

quantitativa de produtividade e economia que um braço robótico como este pode trazer. Em

particular, estimamos que, após 3 meses de operação, o custo de construção do braço já tenha sido

coberto (comparando-se com um testador que ganha salário mínimo). O retorno financeiro pode

ser mais rápido considerandodo uma média salarial de até três salários minímos ou mais.

1.5 ESTRUTURA DA DISSERTAÇÃO

Este trabalho está organizado como a seguir.

No Capítulo 2 são apresentados os principais conceitos associados com a solução proposta,

a saber: Testes de Software, Bluetooth, Servosmotores e SysML.

No Capítulo 3 são apresentados a arquitetura do projeto AR(m)obo Test e os requisitos de

hardware e software. Tendo como base as questões levantadas no Capítulo 3, os conceitos sobre

servosmotores e Bluetooth se fazem necessários para a implementação do aplicativo Android e

implementação e montagem do braço robótico, que é abordado no final do Capítulo 3.

No Capítulo 4, nós propomos métricas e realizamos medições estimadas acerca do uso do

braço robótico.

Finalmente, o Capítulo 5 apresenta os trabalhos relacionados, conclusões e os trabalhos futuros.

Capítulo2–FundamentaçãoTeórica

19

Capítulo

22 FUNDAMENTAÇÃO TEÓRICA

Este capítulo tem como objetivo apresentar a fundamentação teórica necessária para o

entendimento dos principais conceitos abordados no desenvolvimento deste trabalho.


20

2.1 TESTE DE SOFTWARE

Apesar de o processo de desenvolvimento de software envolver um conjunto de atividades

realizadas por pessoas de forma planejada, gerenciada, utilizando teorias, métodos, técnicas e

ferramentas adequadas, erros no produto ainda podem ocorrer. Para evitar esse tipo de problema,

testes de software são aplicados com o objetivo de encontrar falhas para que as causas dessas falhas

sejam identificadas e possam ser corrigidas antes da entrega do produto de software ao cliente.

Teste pode ser considerado como uma técnica de verificação e validação (V&V) cujo

objetivo é estabelecer a confiança de que o sistema está adequado ao seu propósito. Segundo

SOMMERVILE (2007), verificação é a atividade que assegura a consistência, completude e

corretude do produto em cada fase do ciclo de vida do software (o que está sendo desenvolvido

está de acordo com o que foi especificado?), enquanto a validação verifica se o software atende às

expectativas do cliente (estamos construindo o produto certo?). Dentre as técnicas de verificação

e validação, a atividade de testes tem sido uma das mais utilizadas, minimizando a ocorrência de

erros e riscos associados ao processo de desenvolvimento do software e enquadrando-se dentro

das atividades agregadas à Garantia de Qualidade de Software (DELAMARO et al., 2007).

Com a expansão das tecnologias da informação, a qualidade dos produtos tem se tornado

imprescindível nos processos de desenvolvimento de aplicações e sistemas, sendo um elemento

critíco da qualidade do software, aumentando ainda mais o nível de confiança sobre o software.

Segundo PRESSMAN (2006) 40% do esforço de desenvolvimento é gasto em teste e que, em

projetos de software crítico (por exemplo, controle de vôo ou monitoramento de reatores

nucleares), o seu custo pode chegar a três vezes o custo de todas as outras fases de

desenvolvimento.

Alguns autores trazem diferentes definições sobre testes de software, dentre os quais

podemos citar:

• MYERSM (2004): “Testes é o processo de executar um programa ou sistema a fim

de encontrar defeitos ou falhas”.

• HETZEL (1987): “Testar é o processo de certificar que o programa faz o que era

suposto fazer”.

• IEEE (2004): “Uma atividade desempenhada para avaliar a qualidade do produto e

melhorá-lo, uma vez que identifica defeitos e problemas”.

• KOSCIANSKI & SOARES (2007): “Testes é um processo que avalia um sistema

ou um componente de um sistema por meios manuais ou automáticos para verificar


21

se ele satisfaz os requisitos especificados ou identificar diferenças entres resultados

esperados e obtidos”.

As definições apresentadas pelos autores acima abordam dois assuntos importantes referentes

ao processo de testes de software. A primeira característica é a qualidade e a segunda são os

diferentes significados dos problemas que o software pode apresentar que podem comprometer a

garantia da qualidade, tais como: erro, defeito e falha. Segundo o IEEE - Institute of Electrical

and Electronics Engineers – (IEEE 610, 1990) existe uma diferença entre essas terminologias:

• Falha: é a incapacidade de um sistema ou componente para executar funções requeridas

pela especificação dos requisitos de software.

• Erro: é um resultado incorreto, seja em uma etapa, processo ou na definição de um dado,

por exemplo, uma instrução incorreta em um programa computacional.

• Defeito: é uma manifestação concreta de um erro em um artefato de software que pode

resultar em outros defeitos.

2.1.1 PROCESSO DE TESTES DE SOFTWARE

Um processo de testes bem definido pode melhorar a efetividade dos testes, controlando as

atividades e consequentemente gerando mais valor ao produto. DAVIS (2000) define um processo

de testes genérico dividido em quatro fases que respondem algumas perguntas relativas às

atividades de testes. São elas:

• O que testar?

• Como testar?

• Quando testar?

• Quais são os resultados?

A fase de análise de teste pode responder a primeira pergunta (o que testar?). Também

conhecida como Base do Teste, nesta fase são identificadas as documentações como requisitos,

especificação do projeto, análise de riscos do produto, interface e outros. Os conteúdos dessas


22

informações são convertidos em informações que definirão o escopo geral do que será testado,

como número de cenários e, posteriormente, a quantidade de testes criados.

A fase de design pode responder a segunda pergunta (como testar?). Nesta fase, todos os

artefatos gerados, tais como Documento de Requisitos, wireframes e outros serão analisados e

documentados através de estímulos (entradas e pré-condição). Os resultados esperados que

demonstram que as condições de testes foram atendidas e estão de acordo com o que foi

estabelecido pelos requisitos também são estabelecidos.

A fase de planejamento inclui o cronograma de testes e pode responder a terceira pergunta

(quando testar?). Nesta fase é criado um cronograma para as atividades de testes e seus respectivos

responsáveis e quais procedimentos de testes serão executados ao longo do projeto.

A fase de execução reponde a quarta e última pergunta (quais são os resultados?). Esta fase

é conhecida como a parte prática do teste. A partir daqui os testadores seguem os procedimentos

de testes registrando todas as atividades de execução, tais como: data e hora da execução, autor do

teste, procedimento seguido, pessoal envolvido, resultados obtidos e outros.

O processo de testes de software dever ser refinado continuamente para permitir seu

amadurecimento de modo que dê ampliação e atuação pelas partes envolvidas no projeto, provendo

maior visibilidade, organização e maior valor ao cliente.

2.1.2 ABORDAGENS DE TESTE DE SOFTWARE

Algumas abordagens de testes são utilizadas como base para geração de casos de testes.

Das abordagens existentes, temos os testes funcionais ou caixa preta (Black Box), os testes

estruturais ou caixa branca (White Box) e os testes de caixa cinza (Grey Box). Estas são

consideradas as principais abordagens aplicadas durante qualquer estágio de do processo de testes

(KIT, E., 1995).

2.1.3 TESTE DE CAIXA PRETA

Segundo PRESSMAN (2002), os testes de caixa preta são métodos de testes realizados na

interface do programa. Tal abordagem não necessita explorar a estrutura interna do software. Os


23

testes de caixa preta são derivados das especificações do software ou do componente a ser testado,

verificando se as funções exigidas pelo usuário estão funcionando adequadamente (LEWIS, 2000).

Testes de caixa preta também são conhecidos como testes funcionais, pois focam

especificamente nas funcionalidades do sistema. Para DELAMARO (2007), a técnica de testes de

caixa preta se propõe a executar o software sob uma perspectiva de usuário final, onde o software

é investigado através de entradas a um determinado componente ou sistema sem conhecimento de

sua organização interna. Em seguida, suas saídas são examinadas a fim de verificar se estão de

acordo com as especificações do software.

Para PRESSMAN (2005) os defeitos mais comuns encontrados utilizando a abordagem de

caixa preta são:

• Funcionalidades incorretas ou ausentes;

• Defeitos de interface;

• Defeitos de desempenho do software;

• Defeitos de inicialização e término (fluxo).

Testes de caixa branca e caixa cinza são complementares ao teste de caixa preta e tomam

como base para geração de testes o funcionamento interno do sistema (tipicamente, o código

fonte). Este projeto trabalha exclusivamente com testes caixa preta.

2.1.4 PROJETO DE CASOS DE TESTES

Um projeto de caso de teste tem como objetivo projetar casos de entradas e saídas esperadas

que testam o sistema a fim de validar os requisitos funcionais e não funcionais e a eficácia dos

seus componentes. Além disso, são descritos nos casos de testes as entradas e saídas de acordo

com cada característica do software (PRESSMAN, 1995). Segundo BLACK (2003) planejar é

identificar em que momento dentro do processo de desenvolvimento do software as demais

atividades como projeto, execução e análise deverão ser desempenhadas.

Para DELARAMO et al (2007) a forma mais praticada para identificar defeitos em uma

parte do software é fazer com que os testadores selecionem um conjunto de dados de entrada e em

seguida as execute sob um conjunto particular de condições. Os resultados finais da execução dos


24

dados de entrada são denominados “dados de saída”, que devem ser posteriormente comparados

com os requisitos do sistema.

De acordo com SOMMERVILLE (2007), os casos de testes são criados para exercitar um

ramo em um programa validando adequadamente se o software atende a um requisito específico.

No sentido prático um caso de testes deve ter as seguintes informações (CARTAXO, 2006):

Entradas

Condição inicial: Assegura as condições iniciais para que o teste seja executado. São

exemplos de condições/pré-condições: ambiente configurado, massa de dados disponível, rede

disponível e etc.

Passos: Passos ou procedimentos a serem executados, identificados pelos métodos de testes;

Saídas

Resultados esperados: Respostas esperadas do sistema para a entrada atual. Também

refletem uma característica do comportamento do sistema.

Esta seção introduziu a área de testes e apresentou de forma mais detalhada uma das

abordagens mais difundidas e utilizadas na área: teste funcional. Diante do que foi apresentando,

este trabalho se enquadra no contexto de testes de caixa preta com o propósito de detectar defeitos

de interface ou defeitos de funcionalidades, cujos passos (dados de entradas) devem ser realizados

de forma mecanizada através de um braço robótico articulado. Embora o foco deste trabalho esteja

ligado à execução de testes funcionais dispensando recursos humanos para a execução dos testes,

os conceitos aplicados nesta seção se fazem necessários para o entendimendo do planejamento,

das técnicas e estratégias que serão aplicadas nos próximos capítulos desta dissertação.

2.2 BLUETOOTH

Bluetooth é uma tecnologia peer-to-peer (entre pares) sem fio e de baixo consumo de

energia que nasceu em um laboratório da Ericsson em Lund, Suécia, na década de 1990 e tornou-

se um padrão global de conexão sem fio de curta distância. Quando a tecnologia celebrou o seu

11º aniversário em 2008, a quantidade de dispositivos habilitados para Bluetooth já era de 2

bilhões. Hoje, a tecnologia não é somente utilizada em telefones celulares, e PCs (computadores


25

de mesa e laptops), mas também por dispositivos de quase todos os produtos eletrônicos de

consumo, dispositivos médicos, de saúde, esportivos e fitness, além de carros e casas inteligentes

(ERICSSON, 2016).

Uma das aplicações mais populares para Bluetooth é para transmitir streaming de música

de smartphones e tablets para fones de ouvidos e autofalantes sem fio de automóveis. Estes

dispositivos utilizam uma versão do Bluetooth chamado de BR/EDR (taxa de bits/taxa de dados

realçada), que é otimizada para o envio de um fluxo constante de dados de alta qualidade (ou seja,

música) com uma forma eficiente de energia. A tecnologia BR/EDR tem uma estrutura de

desenvolvimento inteiramente nova usando atributos genéricos, ou GATT (Generic Attribute

Profile). O GATT fornece serviços de descoberta e descrição de perfis, é extremamente flexível do

ponto de vista de um desenvolvedor e pode ser usado para praticamente qualquer cenário. Como

resultado, o Bluetooth não só conecta dispositivos de forma eficiente, mas também conecta

dispositivos para aplicativos no smartphone, computadores pessoais ou tablets (BLUETOOTH

SIG, 2016).

Dispositivos Bluetooth usam ondas de rádio em vez de fios ou cabos para se conectar a um

telefone ou computador. Produtos Bluetooth, como fone de ouvido ou relógio, contêm um chip de

computador minúsculo com um rádio Bluetooth e software para se conectar. Quando dois

dispositivos Bluetooth querem se comunicar um com o outro, eles precisam se emparelhar. A

comunicação entre dispositivos Bluetooth acontece ao longo de um curto alcance, em redes ad-

hoc conhecidas como piconets. A rede varia de dois a oito dispositivos conectados. Quando uma

rede é estabelecida, um dispositivo assume o papel do mestre, enquanto todos os outros

dispositivos agem como escravos (BLUETOOTH SIG, 2016).

Uma das principais motivações para o uso do Bluetooth aplicado em sistemas de controle

de robôs é a transferência de dados com baixo custo, a grande quantidade de dispositivos com

chips Bluetooth disponíveis e a facilidade de integração entre os dispositivos.

2.2.1 PROTOCOLO BLUETOOTH

O protocolo Bluetooth possui uma pilha de cinco camadas que também é conhecida como

procedimentos para conexões e troca de dados entre dispositivos Bluetooth. De acordo com


26

KOBAYASHI, C. Y. (2004), o núcleo de protocolo é uma pilha de cinco camadas que consistem

dos elementos abaixo:

• Rádio: É a interface entre o canal no ar e a banda-base (interface de área), incluindo

a freqüência, o uso do hopping (salto de canais), esquema de modulação e o alcance

de transmissão;

• Baseband: A camada de banda-base é responsável pela codificação e decodificação

do canal. Também é responsável pelo estabelecimento da conexão dentro de uma

piconet, endereçamento, formato do pacote, sincronismo e controle de energia;

• Link manager protocol (LMP): Responsável pelo setup entre os dispositivos

Bluetooth e gerência de requisições externas. Isto inclui aspectos de segurança como

a autenticação e criptografia, mais o controle do tamanho do pacote do baseband;

• Logical link control and adaptation protocol (L2CAP): Adapta os protocolos da

camada superior à camada do baseband.

A Figura 1 mostra o detalhe da hierarquia da pilha de protocolos Bluetooth e seus cincos

principais elementos.

A tecnologia Bluetooth permite a comunicação entre software e hardware com

configuração transparente, caracterizada através da formação de grupos de transmissão (piconets).

Tal tecnologia está enquadrada no contexto de computação oculta (MILER, 2001, p. 44) e

possibilita aos dispositos conectados o envio de tarefas específicas (comandos, sinais) com

Figura 1 Pilha de protocolos bluetooth. Adaptado: Labiod, H., et al (2007)


27

autorização e sem nenhuma ação do usuário. Os conceitos apresentados nesta seção são

importantes para compreender o modo de comunicação entre um software controlador (mestre) e

um braço robótico (escravo), onde o usuário é capaz de enviar informações através de um

smartphone com Android para um módulo bluetooth adaptado a um microcontrolador. Além disso,

a tecnologia é considerada barata e de fácil uso, permitindo aos dispositivos pareados o uso direto

do protocolo L2CAP e a praticidade da comunicação via serial que serão mais bem detalhadas nos

próximos capítulos desta dissertação. Por fim, o uso de comunicação sem fio via Bluetooth é

essencial neste projeto pois rotações e translações de um celular conectado via cabo seria bem

mais complicado para evitar enroscos e, consequentemente, quebras e acidentes.

2.3 SERVOMOTORES

Servomotores são frequentemente aplicados na construção de manipuladores robóticos e

são utilizados para controlar os movimentos angulares. A angulação dos servomotores pode variar

de acordo com o modelo. Tipicamente, a angulação mais comum dos servomotores varia entre 0º

a 180º. Servomotores também são conhecidos como atuadores que, junto com sensores, funcionam

como uma forma de transdutores (PATRÍCIO, T. P., 2013), (SINCLAIR, I., 2000). Uma outra

característica importante é que os servomotores funcionam músculos por detrás de um sistema

mecatrônico, que recebem comandos de controle (sinais elétricos) e produz uma mudança em um

dado sistema físico. Essas mudanças podem ser: força, movimento, calor, fluxo, giro, dentre outros

(MATARIC, M. J., 2007).

De acordo com BISHOP, R. H. (2007) o “efetor” é um outro efeito relacionado aos

atuadores utilizados para construção de robôs articulados. O “efetor” é um dispositivo que tem um

determinado efeito, que pode ser um “impacto” ou uma “influência” no seu ambiente e é capaz de

realizar uma ação ou um movimento. Alguns autores trazem diferentes conceitos e formas de

classificar os atuadores e o seu uso. Abaixo seguem algumas deifinições:

• Os motores “acoplados a um conjunto de engrenagens redutoras, um codificador de

rotação e eletrônica de controle de posição do motor, designam-se servomotores”

(CORREIA, 2006, p. 4).

• Atuadores são servomotores (motores de passo e corrente contínua) que

possibilitariam deslocar as partes de protótipos robóticos (DE SOUZA PINTO at

al, 2015).


28

• O servomotores são utilizados em operações de posicionamento e possuem um

torque robusto em relação ao seu tamanho e tem uma enorme aplicabilidade em

projetos de robótica (DE SOUZA PINTO at al, 2015).

• Os servomotores são motores que realimentam a sua posição, garantindo o

deslocamento exigido pelo seu controlador com excelente precisão (PIERIN,

ALMIR ROBERTO, 2015).

Os servomotores também são conhecidos como RC (rádio controle) servomotores (servos

de modelos: miniaturas: carros, aviões, barcos ou trens, com rádio controle). Ambos são motores

DC (corrente contínua) equipados com um mecanismo servo para o controle preciso da posição

angular que normalmente tem um limite de angulação de 90º a 180º. Alguns servosmotores

também tem limite de rotação de 360º ou mais. Tais servomotores são utilizados para o

posicionamento de precisão. Eles são usados nos braços e pernas robóticas, scanners sensores e

em brinquedos de RC como helicópteros, aviões e carros (ENGINEERS GARAGE, 2016). As

Figuras 2 e 3 mostram, respectivamente, dois servomotores do tipo RC aplicados em aeromodelos

e em braços mecânicos articulados.

Figura 2 Servomotor utilizado em um Helicóptero RC. Fonte: Engineers Garage, (2016).


29

Figura 3 Braços robóticos fabricados com servomotores. Fonte: Engineers Garage, (2016).

O servomotor possui um sistema eletrônico de controle e um potenciômetro interno que

está conectado ao eixo de saída. Este potenciômetro possibilita ao circuito de controle monitorar

o ângulo do eixo do servomotor. Se o eixo estiver no ângulo correto, o motor para de girar. Se o

circuito detecta que o ângulo está incorreto, o motor é ativado até que o ângulo desejado seja

obtido. Nas engrenagens de um servomotor existe um limitador que atua no ângulo de giro do

eixo, fazendo com que este vá de 0 a 180º. Este limitador pode ser removido e o servomotor pode

ser utilizado como um motor com caixa de redução com eixo girante de 360º (SANTOS, 2007).

Os servomotores são extremamente úteis em robótica. Os motores são pequenos, possuem

internamente o circuito de controle, engrenagens redutoras, mecanismos de posicionamento por

feedback e são extremamente potentes para o seu tamanho (MONTEIRO, 2001). Os atuadores

escolhidos para a implementação do braço robótico consistem em cinco servomotores de posição.

Atualmente existem dois tipos de servos: os de posição, com giro de 180º até 360º, e o de rotação,

que possui o giro contínuo. O servo de posição é utilizado em braços robóticos para articulações e

movimentos gerais, na robótica móvel terrestre para o controle de pernas mecânicas e para o

controle de câmeras. Já os servos de rotação são prioritariamente escolhidos para a locomoção por

rodas (PEREIRA, 2010).

Neste projeto, utilizamos servomotores para construção de um braço robótico articulado a

fim de simular movimentos humanos. Cada servomotor foi introduzido no ombro, cotovelo, punho

e garra. Foram escolhidos um total de quatro servomotores, sendo dois motores com limite de

angulação de 90º a 180º e dois servomotores com rotação limite de até 360º. Os servomotores

adotados por este trabalho possuem um conjunto de quatro elementos, são eles: um motor de

corrente contínua (DC), um conjunto de engrenagens, um circuito de controle e sensores de


30

posicionamento (potenciômetro) que permitem um controle com maior precisão, diferentemente

dos servomotores RC (corrente contínua padrão). Tais motores são projetados para tarefas mais

refinadas, como mover o braço robótico em diferentes posições e graus.

2.4 SYSML

A SysML (System Modeling Language) é uma linguagem gráfica de modelagem de

propósito geral que apoia a análise, especificação, projeto, verificação e validação de sistemas

complexos que incluem componentes de harware, software, dados, pessoal, procedimentos e

instalações (FRIEDENTHAL, 2008), (HAUSE, 2006). A linguagem SysML especificamente

fornece representações gráficas com significado semântico para modelar requisitos,

comportamento, estrutura e integração do sistema da engenharia em larga escala (WEILKIENS,

2006). Um outro aspecto importante sobre a SysML é a intenção de unificar diversas linguagens

de modelagem que são utilizadas por engenheiros de sistemas, facilitando a comunicação entre

times heterogêneos como, por exemplo: times compostos por engenheiros mecânicos, eletricistas

e analistas de sistemas (SOARES e VANCKENV, 2007).

A SysML é baseada na UML (Unified Modeling Language) (HOLT, J., & PERRY, S.,

2008), uma linguagem de modelagem gráfica de uso geral destinada a engenheiros de software. A

SysML reutiliza um subconjunto da UML 2 fornecendo extensões adicionais necessárias que

podem atender os requisitos da engenharia de sistemas (Vanderperen e Dehaene 2005). A SysML

faz uso da maior parte dos diagramas da UML conforme a Figura 4. No entanto, SysML foi

desenvolvida para ser ainda mais robusta que UML para modelagem de sistemas (HOLT, J., &

PERRY, S., 2008).

Figura 4 Relacionamento entre UML e SysML: Holt, J., & Perry, S. (2008).


31

Como pode ser visto na Figura 4 algumas partes da UML foram consideradas como não

necessárias pela SysML. Em particular, os seguintes diagramas não existem em SysML: Diagrama

de Objeto, Diagrama de Implantação, Diagrama de Comunicação, Diagrama de Tempo e o

Diagrama de Visão Geral de Interação. Alguns diagramas da UML foram reutilizados e sofreram

algumas modificações para tornar a notação SysML mais adequada à engenharia de sistemas como,

por exemplo: Diagrama de Classes (chamado, em SysML, de Diagrama de Blocos), Diagrama de

Atividades e o Diagrama de Estrutura chamado de diagrama de Bloco Interno. Os diagramas de

Máquina de Estados, Diagrama de Caso de Uso, Diagrama de Sequência e o Diagrama de Pacotes

foram incluídos sem alterações significativas. Dois novos diagramas são exclusivos da SysML:

Diagrama de Requisitos e o Diagrama Paramétrico. Embora o diagrama de Objetos não exista na

SysML, especificações de instâncias podem ser mostradas em um diagrama de Definição de Blocos

(HOLT, J., & PERRY, S., 2008).

Segundo VANDERPEREN & DEHAENEV (2005) a principal vantagem da SysML em

relação a UML é o suporte para representar os requisitos e relacioná-los com os modelos do

sistema, o projeto real e os testes. Atualmente existem nove diagramas que compõem a SysML e

podem ser visualizados na Figura 5.

Figura 5 Diagrama de Taxonomia SysML. Fonte: Weilkiens, (2007).

Os diagramas podem ser divididos em três grupos: estrutural, comportamental e genérico

(HAUSE, 2006).

• Estrutural: O aspecto estrutural de um modelo representa a estrutura do

sistema, pois identifica e define os elementos do sistema, define suas propriedades,


32

identifica os seus comportamentos e identifica as relações entre eles (Holt, J., &

Perry, S., 2008).

• Comportamental: O aspecto comportamental de um modelo mostra o

“como” do sistema. Ele identifica o comportamento do sistema no tempo e no espaço

entre os elementos do sistema, dentro dos elementos do sistema e nas operações dos

elementos do sistema (HOLT, J., & PERRY, S., 2008).

• Genérico: Também conhecidos como Diagramas Transversais, estes

diagramas podem ser aplicados nas partes estruturais ou nas partes comportamentais

como, por exemplo, Diagrama de Requisitos.

2.5 DIAGRAMAS COMPORTAMENTAIS

Esta seção apresenta os conceitos dos Diagramas de Sequência (sd) e Diagrama de Maquina

de Estados (stm).

2.5.1 DIAGRAMA DE SEQUÊNCIA Para HOLT, J., & PERRY, S. (2008), o objetivo principal do Diagrama de Sequência

(Sequence Diagram) é mostrar um exemplo particular de uma operação do sistema. Esses

exemplos representam interações entre objetos através de mensagens, onde cada mensagem pode

ser entendida como um serviço solicitado de um objeto a outro e a respectiva resposta dos serviços

solicitados. De acordo com a SysML Specification; v1.4 (2015) os diagramas de seqüência podem

representar interações altamente complexas com construções especiais para representar vários

tipos de lógicas de controle, interações de referências em outros diagramas de seqüência e


33

decomposição de linhas de vida em suas partes constituintes. A Figura 6 mostra um exemplo de

Diagrama de Sequência.

A Figura 6 nos mostra em detalhes o comportamento geral do sistema para operar o veículo

em formato de Diagrama de Sequência. Para gerenciar a complexidade, um diagrama de Sequência

hierárquico é utilizado para referenciar outras interações que elaboram ainda mais o

comportamento do sistema “refStartVehicleBlackBox”. CombinedFragments são usados para

ilustrar que a direção pode ocorrer no mesmo tempo que o controle da velocidade e que a

velocidade pode estar em marcha lenta, acelerando/cruzando ou travando.

Figura 6 Exemplo de Diagrama de Sequência. SysML Specification; v1.4 (2015).


34

2.5.2 DIAGRAMA DE MAQUINA DE ESTADOS

O Diagrama de Máquina de Estados (State Machine Diagrams) é utilizado para modelar o

comportamento dos blocos durante toda a vida de um bloco. Ou seja, eles descrevem o

comportamento das instâncias de blocos, conhecidos na SysML como especificações de instâncias

(HOLT, J., & PERRY, S. 2008). A Figura 7 exibe um exemplo simples para um jogo de xadrez

definindo o comportamento do bloco “jogador”.

O diagrama da Figura 7 mostra a instância da especificação do “Jogador”, onde ele pode

estar em dois diferentes estados: “waiting” ou em “moving”. Para que o jogador atravesse o estado

“waiting” para “moving” o evento “Player 2 moved” deve ter ocorrido. A fim de atravessar o

estado “moving” para “waiting”, o evento “Player 1 moved” deve ser enviado. As duas transições

representam eventos de recebimento e de envio de eventos, sendo o evento “Player 2 moved” um

exemplo de evento de recebimento e o “send Player 1 moved” um evento de envio (send). Em

ordem, o evento 1 é recebido a partir do lado de fora do limite do Diagrama de Máquina de Estados

e o evento 2 é transmitido fora dos limites da Máquina de Estados para outras especificações de

instâncias.

Figura 7 Diagrama de Maquina de Estados simples para um jogo de xadrez. Fonte: Holt , J., & Perry, S.,

(2008).


35

2.6 DIAGRAMAS ESTRUTURAIS

Esta seção apresenta os conceitos dos Diagramas de Definição de Blocos (bdd) e Diagrama

Interno de Blocos (ibd).

2.6.1 DIAGRAMA DE DEFINIÇÃO DE BLOCOS

O Diagrama de Definição de Blocos (Block Definition Diagram) descreve a hierarquia do

sistema, tal como: componentes, suas propriedades, operações e relações (HOLT, J., & PERRY,

S., 2008). De acordo com a OMG (2012), o Diagrama de Blocos é utilizado para definir blocos,

suas características e relações com outros blocos estruturais facilitando a ilustração da estrutura do

sistema. O “bloco” representa a unidade básica da estrutura em SysML e são usados para

representar hardware, software, instalações ou qualquer outro elemento do sistema. Em particular

o Diagrama de Blocos é considerado o mais comum da SysML e é a maneira mais simples de

descrever a estrutura de um sistema (DELLIGATE, 2013).

No Diagrama de Blocos, é possível entender as partes de um grande sistema com foco no

processo lógico através de uma visão estática e estrutural, sendo possível exibir os relacionamentos


36

entre os blocos com um maior nível de abstração. A Figura 8 mostra um exemplo de Diagrama de

Blocos.

A Figura 8 mostra a hierarquia de blocos de um satélite. O bloco ‘DellSat-77 Satellite’ é

composto dos blocos ‘Electrical Power Subsystem’, ‘Attitude and Orbital Control Subsystem’,

‘Environmental Control Subsystem’ e ‘Communication and Data Handling Subsystem’. O losango

preto representa a relação de composição, que relaciona um elemento com suas partes de forma

que, se o elemento pai é removido, as partes também o são. A composição também é chamada de

relacionamento todo-parte, onde um bloco que representa o todo é associado a um bloco que

Figura 8 Exemplo de um Diagrama de Definição de Blocos. Fonte: Delligatti, (2008).


37

representa a parte. Os blocos possuem propriedades e operações, assim como as relações entre

eles.

2.6.2 DIAGRAMA INTERNO DE BLOCOS

O Diagrama Interno de Blocos (Internal Block Diagrams) é utilizado para modelar a

estrutura interna de um bloco. Usando um diagrama de blocos interno, em que as composições e

agregações são implicitamente representados pela contenção de peças dentro do bloco proprietário

ou dentro de outras partes, a ênfase pode ser colocada sobre as relações lógicas entre os elementos

da composição, em vez da quebra estrutural em si (HOLT, J., & PERRY, S., 2008). A Figura 9

mostra um exemplo de Diagrama Interno de Blocos.

Podemos observar na Figura 9 um meta-modelo parcial de um Diagrama Interno de Blocos

composto de uma ou mais partes (Part), zero ou mais portas (Port), zero ou mais conectores

vinculados (Binding Connector) e de zero ou mais itens de fluxos (Item Flow). A ‘Port’ define um

ponto de interação para uma ‘Part’ e vem com dois tipos: “Full Port” e “Proxy Port”. A 'Part'

pode ser conectada diretamente a zero ou mais ‘Part’ através de um ‘Binding Connector’. Esta

conexão também pode ser de uma ‘Part’ para a ‘Port’ em outra ‘Part’. Uma ‘Part’ também pode

estar ligada a zero ou mais ‘Port’. Um ‘Item Flow’ pode fluir através de um ‘Binding Connector’.

Para HOLT, J., & PERRY, S., (2008) o conceito de portas está presente nos diagramas ‘bdd’ e

Figura 9 Exemplo de um meta-modelo parcial de um Diagrama Interno de Blocos. Fonte: Holt, J., & Perry, S., 2008


38

‘ibd’, a diferença é que, no Diagrama de Definição de Blocos, são mostradas as portas em um

bloco, mas não as conexões entre eles.

Diante dos conceitos apresentados nesta seção, este projeto utilizou a notação de

modelagem gráfica SysML para modelar a arquitetura geral do projeto AR(m)obo Test, permitindo

uma análise visual que pode facilitar a compreensão por engenheiros de software, administradores,

gerentes de projetos e outros interessados em soluções de testes para dispositivos móveis. A

modelagem em SysML proporciona: a) visão e controle do que está sendo produzido; b)

especificação da estrutura/comportamento do software e do hardware; c) um template para

construção de um sistema controlador e de um manipulador robótico (objetivo desta dissertação);

d) identificação do escopo, a fim de gerenciar os riscos; e) demonstração da complexidade do

sistema provendo um melhor gerenciamento e controle das atividades.

2.7 CONSIDERAÇÕES FINAIS

Este capítulo apresentou, através de uma revisão bibliográfica, os principais conceitos

necessários para o entendimento desta dissertação. Para entender o projeto AR(m)obo Test o leitor

deve se familiarizar com contexto de Testes de Software e os componentes necessários para

criação de manipuladores robóticos. A construção deste projeto será apresentada através da SysML

em um nível mais alto de abstração de modo que facilite a replicação da solução proposta para a

indústria. O próximo capítulo aborda a arquitetura do projeto proposto seguido da sua

implementação.

Capítulo3–ProjetoeImplementação

39

Capítulo

3

3 PROJETO E IMPLEMENTAÇÃO

Este capítulo tem como objetivo apresentar a arquitetura e os detalhes da implementação

do desenvolvimento do AR(m)obo Test utilizando a notação SysML. São apresentados a

construção mecânica do robô e a implementação de um aplicativo móvel que o controla.


40

3.1 INTRODUÇÃO

O projeto AR(m)obo Test pode ser considerado como interdisciplinar, a julgar por englobar

diversas áreas do saber, como Automação (Engenharia mecânica, Elétrica e Eletrônica) e Ciência

da Computação. A Engenharia Mecânica é responsável por prover os métodos necessários para a

construção, análise, operações e manutenção do sistema mecânico. As Engenharias Elétrica e

Eletrônica provêem recursos e técnicas para manipulação de eletroeletrônicos como integração de

sensores e atuadores, circuitos elétricos, microcontraladores e interfaces. As abordagens descritas

são amplamente utilizadas para o desenvolvimento de componentes eletrônicos interligados via

software embarcado controlado por ferramentas lógicas e eletrônicas. Por último, a Ciência da

Computação oferece ferramentas para programação de manipuladores conduzindo-os à realização

de tarefas programadas de forma específica e controlada.

O AR(m)obo Test é constituído por servomotores conectados a uma placa Arduino

controlado remotamente através da comunicação celular via Bluetooth. Outro aspecto que será

mostrado neste capítulo é o desenvolvimento de um aplicativo Android capaz de controlar e apurar

as informações de angulação do braço robótico e do dispositivo móvel em teste. O objetivo geral

da implementação do braço robótico é ter um suporte para testes automáticos aplicados em

smartphones e tabletes embarcados com sensores como acelerômetro e giroscópio, garantindo que

as aplicações desenvolvidas respondam de forma adequada às mais variadas orientações do

dispositivo.

3.2 DESCRIÇÃO DO PROJETO

Esta seção apresenta a visão geral inicial do AR(m)obo Test e seus princípios de

funcionamento. A Figura 10 ilustra a topologia geral do projeto.


41

O projeto AR(m)obo Test consiste dos módulos abaixo:

• AR(m)obo Test App: Unidade de testes composta por um smartphone com a

plataforma operacional móvel Android e um aplicativo denominado AR(m)obo Test

App. Tal aplicativo permite definir quais movimentos e angulação o braço irá realizar.

O AR(m)obo Test App também será capaz de exibir as informações dos sensores de

ambos os dispositivos, tais como: acelerômetro e giroscópio, velocidade dos atuadores

e a temperatura dos atuadores.

• Central de Comunicação e Testes (CT): Unidade central de testes passa a existir após

a comunicação entre dois dispositivos de hardwares (smartphone e braço robótico).

Para que a comunicação do braço robótico aconteça é necessário fazer uso de uma fonte

alimentadora e um módulo Bluetooth interligado à placa Arduino. Após estabelecer

comunicação entre o aplicativo e o braço robótico o AR(m)obo Test App será capaz de

enviar comandos para o braço robótico.

• Unidade de Consulta (UC): Unidade de consulta consiste na utilização de um laptop

que possibilite o acompanhamento da execução dos testes para fins de processo, tal

como: registro de bugs/issues e reports. Este trabalho utilizou as ferramentas “open

source” Testlink para criação de cenários de testes e a ferramenta Mantis para geração

de reports.

Figura 10 Visão geral do projeto AR(m)obo Test. Fonte: Autoria própria.


42

3.3 PROJETO AR(M)OBO TEST EM SYSML

Esta seção utiliza a linguagem de modelagem gráfica SysML para o hardware e o software

AR(m)obo Test. SysML foi utilizado para modelar Requisitos, Diagramas de Blocos, Diagrama

Interno de Blocos, Diagrama de Estados e Diagrama de Sequência.

3.3.1 REQUISITOS

Dentre os diagramas que serão apresentados ao longo deste capítulo, o Diagrama de

Requisitos se destaca por ilustrar os requisitos do sistema e suas relações com outros componentes.

Além disto, oferece uma ponte entre as ferramentas de gerência típicas da Engenharia de

Requisitos e os demais modelos do sistema (DA SILVA, 2009).

Para este trabalho, os requisitos serão levantados de acordo com a necessidade de testar

gestos de rotação automaticamente em um smartphone sem nenhum estímulo ou esforço que

advenha de um ser humano. Para isto, foram desenvolvidos requisitos para a implementação de

um software (o aplicativo AR(m)obo Test App) e o desenvolvimento de um hardware (braço

robótico). Tais requisitos serão apresentados em tabelas e posteriormente será derivada toda a

modelagem do software e do hardware, bem como diagramas de requisitos em SysML.

3.3.2 REQUISITOS DE SOFTWARE

O aplicativo AR(m)obo Test App desenvolvido neste trabalho apresenta duas

características importantes: a primeira consiste em controlar remotamente o braço robótico através

da conexão celular via Bluetooth; a segunda é que cada movimento gerado pelo braço robótico

consiste em um ou mais casos de testes definidos pelo usuário a partir da aplicação. Cada caso de

teste gera um ou mais movimentos com o objetivo de testar uma feature (funcionalidade) do

smartphone. Os detalhes da implementação da aplicação serão apresentados na Seção 3.4. A

Tabela 1 mostra os requisitos de Software com as seguintes informações: ID para referência, Nome


43

do requisito, Descrição do requisito e o campo Derivado do Requisito para informar se o requisito

foi originado a partir de outro.

Tabela 1 Requisitos de Software

ID Nome Descrição Derivado do Requisito

[RFApp01] Selecionar movimento

Permite que o usuário escolha um tipo de movimento pré-definido para cada teste. [REQHW01]

[RFApp02] Selecionar angulação

Permite que o usuário escolha um tipo de ângulo pré-definido para cada teste. [REQHW02]

[RFApp03] Calibrar braço robótico

Permite conhecer o ambiente interno do dispositivo de teste através da captura dos logs do acelerômetro e do giroscópio, provendo ao usuário o ponto de calibragem antes do início dos testes.

[REQHW03]

[RFApp04] Exibir status do braço robótico

Permite conhecer o status do braço robótico, tais como: último teste realizado, temperatura do braço e condicionamento para realização do próximo teste.

[REQHW09]

[RFApp05] Exibir status de conexão

Provê o status de conexão entre o dispositivo e o braço robótico. [REQHW09]

[RFApp06] Iniciar teste Permite que o teste inicie após a verificação da calibragem e a escolha do tipo de movimento e da angulação.

[REQHW07]

[RFApp07] Interromper teste

Permite que o teste seja interrompido para iniciar novamente ou iniciar novo teste. [REQHW08]

[RFApp08] Exibir resultado

Permite exibir um resultado resumido do teste através da aplicação e um resultado completo com as informações sobre posição do braço robótico e a posição dos sensores do dispositivo.

[REQHW09]

[RFApp09] Gerar log

Permite armazenar os resultados dos testes com detalhes exibindo a resposta em frequência, velocidade, tipo de orientação, angulação entre os dois hardwares, provendo uma forma fácil de comparar os resultados.

[REQHW09]

[RFApp10] Entrar em modo repouso

Permite enviar comando de repouso para o braço robótico recuperar sua temperatura ideal após atingir uma execução máxima de até 10 casos de testes.

[REQHW03]

Fonte: Autoria própria


44

3.3.3 REQUISITOS DE HARDWARE Nesta seção serão apresentados os requisitos de hardware. Na construção de um braço

robótico, vários itens devem ser levados em consideração na composição da sua estrutura, tais

como a estrutura mecânica do robô, fonte de alimentação, sensores, atuadores e automação. Esses

detalhes serão melhor explicados na Seção 3.4. Os requisitos de hardware foram levantados com

a ajuda e validação da equipe de robótica da empresa CESAR. A Tabela 2 expõe os requisitos para

construção do braço robótico proposto por este trabalho. Alguns dos seus requisitos possuem

derivação dos requisitos de software da aplicação Android e serão apresentados no diagrama de

requisitos da Figura 11.

Tabela 2 Requisitos de Hardware

ID Descrição Derivado do Requisito

[REQHW01] O braço robótico deve possuir uma analogia semelhante a um braço humano. [RFApp01]

[REQHW02] O Arduino deve controlar os atuadores através da comunicação serial. Todos os servomotores devem estar interligados entre si através de conectores de três fios de alimentação.

[RFApp02]

[REQHW03] O braço robótico deve ser usado em intervalos programados entrando em modo de repouso após 20 minutos de funcionamento.

[RFApp10] [RFApp03]

[REQHW04] O braço robótico deve operar com baixa quantidade de potência elétrica. Tensão recomendada: 10v até 12v. [RFApp04]

[REQHW05] O braço robótico deve ser capaz de levantar um peso de até 160g. -

[REQHW06] A estrutura física do braço robótico deve ser constituída utilizando materiais leves e de preferência moldável. -

[REQHW07] O braço robótico deve atuar entre 0 a 6 graus de liberdade [RFApp06]

[REQHW08] O braço robótico deverá ser programado para parar diante de interrupções ou obstáculos. [RFApp07]

[REQHW09] O controle Entrada/Saída do braço robótico deve ocorrer através da comunicação celular via Bluetooth.

[RFApp05] [RFApp04] [RFApp08] [RFApp09]


3.3.4 DIAGRAMA DE REQUISITOS EM SYSML

Esta seção apresenta o diagrama de requisitos em SysML a fim de modelar a hierarquia entre

os requisitos de hardware e software, além disso também é possível visualizar a derivação entre


45

um requisito e outro. Utilizamos a ferramenta de modelagem proprietária Astah SysML v1.4.0 e

devido a limitações de espaço em cada bloco a descrição dos requisitos não foram consideras. A

relação entre os requisitos é mostrada na Figura 11.

Figura 11 Diagrama de Requisitos em SysML. Fonte: Autoria Própria.


46

3.4 ARQUITETURADOPROJETOEMSYSML

Após o levantamento dos requisitos, foi criada uma modelagem de parte da arquitetura do

projeto em termos de Diagrama de Blocos utilizando a ferramenta de modelagem open source

Modelio v3.6. Este modelo pode ser visualizado na Figura 12.

Figura 12 Diagrama de Blocos do Projeto AR(m)obo Test. Fonte: Autoria própria.


47

O Diagrama de Blocos da Figura 12 permite compreender a hierarquia e a natureza de cada

bloco. O AR(m)obo Test é composto pelo aplicativo Android (AR(m)obo Test app) e pelo Braço

Robótico. O bloco Aplicativo Android é composto por um único sistema que controla o braço

robótico. No entanto, o controle do braço robótico contém uma unidade de processamento e drivers

de motores.

A unidade de processamento é representada pelo bloco Arduino, também conhecido como

unidade de controle, que por sua vez é responsável pelo gerenciamento dos parâmetros

operacionais requeridos para realizar tarefas pré-definidas pelo bloco Aplicação Android. O bloco

Arduino é constituído pelos blocos PathPlanning e Barramento de controle. Os blocos que

constituem o bloco Arduino fazem parte da programação do hardware e serão detalhados na Seção

3.3.6.

As unidades de motores são representadas pelos blocos Ombro, Cotovelo, Pulso e Garra.

Cada bloco atuador é capaz de executar uma ou mais posições controladas (giro) dentro de um

alcance de limites de ângulos especificados. Tais blocos podem ser compreendidos como uma

força aplicada capaz de simular movimentos semelhantes a um braço humano. Na tabela 3 serão

apresentados os tipos de motores que compõem o bloco Atuador.

Tabela 3 Blocos Atuadores e suas angulações.

Bloco Angulação

Ombro Até 90º

Cotôvelo Até 90º

Pulso Até 180º

Garra De 0º a 330º de forma controlada De 0º a 360º de forma contínua


O braço robótico foi construído sobre uma estrutura física plástica produzida exclusivamente

para atender os requisitos. As partes físicas que o constitui são representadas pelos blocos Fixador,

Antebraço, Braço e Base.


48

3.4.1 DIAGRAMA INTERNO DE BLOCOS Analisando o bloco AR(m)obo Test da Figura 12 de uma maneira mais profunda, tem-se

disposto na Figura 13 o Diagrama Interno de Blocos que mostra o funcionamento das interações

entre blocos do braço robótico. O Diagrama Interno de Blocos foi modelado através da ferramenta

proprietátia Astah SysML v1.4.0.

Figura 13 Diagrama Interno de Blocos do projeto AR(m)obo Test. Fonte: Autoria Própria.


49

O bloco Aplicativo Android deve possuir uma interface gráfica amigável para o utilizador

poder criar movimentos denominados “testes”. Um teste é um comando ou um conjunto de

comandos que serão enviados ao Arduino. Tais comandos podem ser classificados como métodos,

onde cada método é interpretado pela biblioteca Arduino e convertido, porsteriormente, em um

conjunto de dados que se transformarão em uma operação a ser executada pelos servomotores.

Tais comandos são genericamente classificados como: iniciar motor, parar motor, ligar motor,

desligar motor, mover, girar, etc.

O bloco PP – PathPlanning da Figura 13 é capaz de planejar a movimentação do braço

robótico baseando-se no seu conhecimento local. O bloco BC – Barramento de Controle atua como

um regulador das outras funções (barramento de dados, barramento de endereço), podendo limitá-

las ou expandi-las em razão da sua demanda.

Os dados enviados aos servomotores pelos blocos PP e BC podem ser descritos como

valores que definirão um movimento. O software que será gravado no Arduino recebe três

caracteres através da comunicação serial como, por exemplo, “000″ para fazer o motor ir para 0

graus. Se receber “050″, irá para 50 graus, “120” para 120 graus, e assim por diante. É dessa forma

que os comandos são enviados para o servomotor e cada valor pode variar de acordo com o

objetivo do teste. Na Tabela 4 é exibido um exemplo com os valores enviados para um servo

motor:

Tabela 4 Métodos de Operações do Servomotor

ID Método Aº Velocidade On/Off

A4 045 45 1,5 ms 1

Fonte: Autoria Própria.

As informações apresentadas na Tabela 4 exemplificam uma operação que será executada

por apenas um atuador. O atuador com ID “A4” vai receber o método “045” a um pulso de “1,5

milissegundos” girando de forma controlada até “45 graus”. Os atuadores da Figura 13 são

controlados via porta serial e estão interligados entre si através de conectores de três fios de

alimentação, cada fio tem um pino positivo, um pino negativo e um pino de sinal (pulso). Cada

servomotor trabalha independentemente de quem está enviando o sinal para ele. A Tabela 4


50

demonstra um exemplo de controle via porta serial representado pelo Diagrama Interno de Blocos

da Figura 13.

Tabela 5 Métodos de operações dos servos motores.

Fonte: Autoria Própria

Como pode ser visualizado na Tabela 5 cada atuador vai ler um conjunto de informações,

este conjunto de informações pode ser compreendido como dados ou sinais. A comunicação serial

permite uma leitura dinâmica de dados, ou seja, uma instrução pode ser repassada para o atuador

A2 sem que o atuador A1 execute qualquer ação. Este recurso possibilita que os atuadores tenham

um grau de liberdade sem nenhum tipo de dependência entre eles. Sendo assim, teremos casos de

testes que necessitarão mover apenas o atuador A1 e A4, e casos de testes que moverão todos os

atuadores de uma maneira simultânea ou paralela.

O conjunto de instruções mostrados na Tabela 5 representam um exemplo de caso de teste.

Para simplificar o entendimento, lê-se ‘ID’ conforme representado abaixo:

• A1: representa a articulação do ombro

• A2: representa a articulação do cotovelo

• A3: representa a articulação do pulso

• A4: representa a articulação da mão

O caso de teste representado através da Tabela 5 mostra a primeira leitura de dados sendo

realizada por A1, onde recebe o método “000”, isto significa que A1 não executará nenhum

comando de movimento. A2 recebe o método “050”, logo o atuador do cotovelo rotacionará para

um ângulo de 50º a uma velocidade de 1,5 milissegundos. O mesmo caso que ocorre em A2 se

repetirá para A3. Por último, o atuador A4 que representa a articulação da mão, sendo responsável

por rotacionar o dispositivo de teste com o objetivo de testar os sensores do smartphone será

rotacionado para uma angulação de 120º a uma velocidade de 1,5 milissegundos.

Atuador ID Método Aº Velocidade On/Off A1 A1 000 0º 1,5 ms 1

A2 A3 050 50º 1,5 ms 1

A3 A3 050 50º 1,5 ms 1

A4 A4 120 120º 1,5 ms 1


51

3.4.2 DIAGRAMA DE SEQUÊNCIA

Nesta seção é apresentado mais um diagrama comportamental da SysML, o Diagrama de

Sequência. O Diagrama de Sequência foi modelado utilizando a ferramenta open source Modelio

v3.6. Na Figura 14 pode-se observar um exemplo simples sobre as interações entre os objetos

através de mensagens.

O Diagrama de Sequência da Figura 14 descreve a sequência de eventos que ocorrem em

um determinado processo. Nele, é possível identificar alguns métodos impulsionados entre os

blocos envolvidos. Além disso, também é possível verificar a ordem como isso acontece. As

sequências de comunicação entre os blocos mostram alguns eventos descritos nos requisitos de

software e hardware da Seção 3.3.1. O bloco AR(m)oboTest App envia sequencialmente dois

Figura 14 Diagrama de Sequencia do projeto AR(m)


52

serviços para o bloco Arduino. São eles: Iniciar Calibração e Mover Pulso. Em seguida, o bloco

Arduino trata essas informações e as repassa para o último bloco (Braço Robótico), resultando em

um fluxo de entrada e saída onde se tem a execução de uma determinada tarefa e a resposta dela

(neste caso, a definição de um ângulo e a movimentação do pulso). Neste diagrama, seguindo uma

ordem de execução, é necessário que uma mensagem seja executada até o final para que uma

próxima seja iniciada (mensagens síncronas).

3.4.3 DIAGRAMA DE MAQUINA DE ESTADOS

Nesta seção é apresentado um modelo simples do Diagrama de Máquina de Estados do bloco

Braço Robótico utilizando a ferramenta open source Modelio v3.6. Na Figura 15 pode-se observar

o comportamento do braço robótico através de sequências de estados que ocorrem em resposta a

um evento/operação.

O exemplo da Figura 15 representa duas situações que poderão ocorrer em um determinado

momento durante os testes com o braço robótico. A operação “Iniciando Teste” leva o braço

robótico para o estado “Conectando”. Tal estado permite a escolha de eventos ou estímulos que

acarretará na mudança de um estado a outro. Na primeira transição da Figura 15, um usuário pode

selecionar um tipo de teste que moverá as articulações do braço robótico. Após o final do teste, o

Figura 15 Diagrama de Maquina de Estados da Especificação SysML. Fonte: Autoria própria.


53

braço deverá retornar para seu estado inicial Neutro; a segunda transição mostra a seleção de um

evento capaz de calibrar os articuladores (servomotores) para o ângulo “0”. Após o final do evento,

o braço retorna para o seu estado inicial Neutro. Após a conclusão dos testes o usuário será capaz

de desligar o braço robótico completamente.

3.5 IMPLEMENTAÇÃO

Esta seção descreve de forma sucinta todos os passos da implementação do hardware e do

software do projeto AR(m)obo Test e seus respectivos princípios de funcionamento. A primeira

seção diz respeito aos materiais utilizados na constituição do braço robótico. Depois, encontra-se

uma seção onde são explicados detalhes sobre a implementação do braço robótico.

Por fim, será apresentada uma seção sobre o desenvolvimento de uma aplicação Android

que controla o braço robótico.

3.5.1 MATERIAIS UTILIZADOS

A implementação do braço robótico articulado constitui na fixação de servomotes

acoplados por material plástico produzido em impressora 3D do tipo MakerBot Replicator 2X.

Para fixação, foram utilizados de forma padronizada parafusos e fixadores de encaixe. A Tabela 6

a seguir informa o custo para desenvolvimento do projeto baseados nos valores dos materiais

utilizados, não estando considerados nesta estimativa os custos homem/hora e utilização de

ferramentas. Tabela 6 Lista de materiais utilizados

Fonte: Autoria Própria

Item Quantidade Valor aproximado

Kit Arduino MEGA 2560 1 US$24,95

Dynamixel AX-18A 2 US$95.90

Dynamixel MX-64T 2 US$305.00

Módulo Bluetooth HC-06 1 US$14,22

Miscelâneos (Fio, Conectores, Rebites, Fitas) -

R$100,00

MakerBot PLA Filament 4kg US$192,00


54

A seguir, serão apresentadas as principais características básicas iniciais dos componentes

utilizados na implementação do braço robótico, a saber: Kit Arduino Mega 2560, Módulo

Bluetooth HC-06 e Servomotores Dynamixel.

3.5.2 KIT ARDUINO MEGA 2560

Este projeto adotou o KIT Arduino MEGA 2560 ilustrado pela Figura 16 por possuir

recursos sofisticados para uma prototipagem mais robusta, podendo ser utilizada em áreas

industriais. O MEGA 2560 se destaca por não utilizar o chip controlador FTDI para fazer a

conversão de serial para USB que foi substituído pelo ATmega8U2 programado para realizar esta

mesma função. Isso permite que o microcontrolador seja programado como um conversor USB-

to-serial. A comunicação escolhida pelo projeto AR(m)obo Test ocorre via serial, o que tornou a

escolha do MEGA 2560 crucial. O microcontrolador em questão dispõe de 54 pinos de

entrada/saída (dos quais 15 podem ser usados como saídas PWM), 16 entradas analógicas, 4

URATs (portas seriais de hardware), um cristal oscilador de 16 MHz, uma conexão USB, uma

tomada de energia, um conector ICSP e um botão de reset (ARDUINO 2016).

Figura 16 Arduino MEGA 2560

O MEGA 2560 pode ser alimentado por uma conexão USB ou por uma fonte externa. A

entrada de alimentação escolhida na implementação deste projeto ocorre através de uma fonte

alimentadora que opera entre 6 e 20 volts. A fonte pode ser conectada plugando um conector de

2,1mm, positivo no centro, na entrada de alimentação. Na Tabela 7 são apresentadas as principais

características do microcontrolador Arduino MEGA 2560.


55

Tabela 7 Especificação do Arduino MEGA 2560

Fonte: ARDUINO (2016).

3.5.3 MÓDULO BLUETOOTH

A comunicação via Bluetooth foi escolhida para controlar o braço robótico por diversos

fatores: comunicação rápida com baixo consumo de energia, não utilização de cabos durante os

testes automáticos, liberdade de movimentos entre o braço robótico e o dispositivo de testes sem

oferecer um atraso significativo na performance da execução. Para garantir a comunicação com o

braço robótico, este projeto utilizou o módulo Bluetooth HC-06 que oferece uma forma fácil e

barata de comunicação sem fio com o Arduino, uma vez que é possível utilizar uma aplicação

Android para enviar e receber mensagens para o Arduino e fazê-lo movimentar um robô ou outro

dispositivo eletrônico. Na Figura 17 é mostrado o Módulo Bluetooth HC-06.

Características Dados

Microcontrolador ATmega2560 Tensão de alimentação 5V Tensão de entrada (recomendada) 7-12V Tensão de entrada (limites) 6-20V Pinos digitais I/O 54 (dos quais 15 podem ser saídas PWM) Pinos de entrada analógica 16 Corrente contínua por pino I/O 40 mA Corrente contínua para o pino 3.3v 50 mA Memória Flash 256 KB (dos quais 8KB usados pelo bootloader) SRAM 8KB EEPROM 4KB Velocidade de clock 16MHz


56

O módulo Bluetooth HC-06 atinge um alcance de aproximadamente 10 metros e funciona

apenas em modo slave (escravo), ou seja, ele permite que outros dispositivos se conectem a ele,

porém não é possível conectar-se a outros dispositivos Bluetooth por si só. A Tabela 8 exibe as

principais características do BT HC-06. Tabela 8 Especificação do módulo Bluetooth HC-06

Fonte: Bluetooth HC-06 Specification

Características Dados Protocolo Bluetooth V2.0+EDR Firmware Linvor 1.8 Frequência 2,4GHz Banda ISM Modulação GFSK Emissão de energia <=4dBm, Classe 2 Sensibilidade <=84dBm com 0,1% BER Velocidade Assíncrono 2,1Mbps[Max]/160Kbps Velocidade Síncrono 1Mbps/1Mbps Segurança Autenticação e Encriptação Perfil Porta Serial Bluetooth Alcance 10m Banda de Onda 2,4Hhz-2,8Ghz, Banda ISM

Figura 17 Módulo Bluetooth HC-06


57

3.5.4 MOTORES DYNAMIXEL

Os servomotores escolhidos para o projeto são da marca Dynamixel. Os servos Dynamixel

possuem um microcontrolador capaz de entender 50 comandos, dos quais são lidos em conjuntos

de parâmetros que definem o seu comportamento. O hobby, controle de rádio típico do servo, só

entende a ordem "ângulo do alvo" (dado por um sinal PWM), mas os atuadores Dynamixel

permitem que vocês os utilize como um atuador profissional com sensores. Os atuadores podem

trabalhar com softwares que podem reagir ao ambiente usando as informações do sensor de leitura

dos motores. Estas informações podem conter a posição atual, a corrente consumida ou a variação

de temperatura do servo para a carga aplicada à mesma, permitindo um feedback sofisticado

(ROBOTIS, 2016). Dois modelos de servomotores foram utilizados na composição do braço

robótico e serão apresentados nas próximas seções.

3.5.5 DYNAMIXEL MX-64

O servomotor Dynamixel MX-64T mostrado na Figura 18 possui um protocolo do tipo half

duplex comunicação serial assíncrona (8bit, 1stop, No Parity) e uma taxa de transmissão de 8Kbps

a 4.5Mbps. Este motor consegue trabalhar com uma angulação que pode variar entre 0º a 360º e

tem funções de giro infinito (endless turn). Além disso, com um serial inteligente do tipo TTL

Level Multi Drop Bus (TTL usa conectores de 3 pinos, enquanto RS485 usa 4), permite um alto

desempenho para atuadores ligados em rede para robôs totalmente integrados com função de

feedback e capacidade de programação.

Figura 18 Dynamixel MX-64


58

A Tabela 9 exibe as principais características do servomotor Dynamixel MX-65.

Tabela 9 Dynamixel MX-64 Specification. Fonte: Dynamixel.

Especificações Tensão de operacão 14.8V 12V 11.1V

Stall torque

74 kg·cm 1033 oz·in

7.3 N.m

61 kg·cm 849 oz·in 6.0 N.m

56 kg·cm 778 oz·in 5.5 N.m

No-load Speed 78 RPM 63 RPM 58 RPM Peso 126g Tamanho 40.2 x 61.1 x 41.0 mm Ângulo de operação 360° ou giro contínuo Temperatura de operação -5°C ~ 80°C Corrente máxima 4.1A @ 12V Motor Maxon RE-MAX

3.5.6 DYNAMIXEL AX-18A

O servo motor Dynamixel AX-18ª mostrado na Figura 19 possui um protocolo do tipo half

duplex comunicação serial assíncrona (8bit, 1stop, No Parity) e uma taxa de transmissão de 7Kbps

a 1Mbps. Este motor também consegue trabalhar com uma angulação que pode variar entre 0º a

360º e tem funções de giro infinito (endless turn). O AX-18A fornece cerca de 50 comandos e

parâmetros de feedback que permite um controle completo sobre uma aplicação robô. Com um

protocolo de série interligado, o motor é capaz de se conectar com vários servos que, interligados

em cadeia, oferecem várias conformidades e parâmetros de detecção que podem ser configurados

e lidos, incluindo posição, velocidade e temperatura.


59

A Tabela 10 exibe as principais características do servomotor Dynamixel AX-18A.

Tabela 10 Dynamixel AX-18A Specification. Fonte: Dynamixel.

A energia necessária para alimentar os servomotores é um fator importante a ser

considerado. Entretanto, uma falha na alimentação desses hardwares pode comprometer o seu

funcionamento ou até mesmo a perda total do motor. Para impedir que uma tensão inapropriada

Especificações Tensão de operacão 14.8V 12V 11.1V

Stall torque

74 kg·cm 1033 oz·in

7.3 N.m

61 kg·cm 849 oz·in 6.0 N.m

56 kg·cm 778 oz·in 5.5 N.m

No-load Speed 78 RPM 63 RPM 58 RPM Peso 126g Tamanho 40.2 x 61.1 x 41.0 mm Ângulo de operação 360° ou giro contínuo Temperatura de operação -5°C ~ 80°C Corrente máxima 4.1A @ 12V Motor Maxon RE-MAX

Figura 19 Dynamixel AX-18A


60

fosse passada para os servos motores, um filtro de tensão foi criado permitindo que os mesmos

sejam alimentados por no máximo 14V evitando sobrecarga.

Os motores Dynamixel AX-18A e MX-64 foram escolhidos para a implementação do deste

projeto por serem considerados de alta qualidade e de alta performance (ENGINEERING, 2013).

O motor Dynamixel MX-64 consegue levantar uma carga de até 6,4kg a uma distância de 10 cm.

Este projeto utilizou dois motores Dynamixel MX-64, sendo um aplicado no ombro e outro

aplicado no cotovelo permitindo um equilíbrio na distribuição da força gerada pelos testes sem

causar danos ao protótipo. A escolha dos servomotores AX18 foram influenciadas pela pouca força

aplicada nas articulações do pulso e da mão, esses detalhes serão explicados nas próximas seções.

3.6 MONTAGEM

Esta seção apresenta a montagem do protótipo proposto por este trabalho. Grande parte dos

componentes mecânicos (estrutura física) necessários ao funcionamento do braço robótico foi

desenvolvida pelo autor, tal como: fixadores, braço, antebraço, base, garra e outros componentes

que serão apresentados ao decorrer do texto. Os componentes eletroeletrônicos apresentados nas

seções anteriores estão disponíveis comercialmente e dispõem de bibliotecas de código aberto e

documentações. Todas elas estão disponíveis nos sites de seus respectivos fabricantes.

3.6.1 ESTRUTURA MECÂNICA

O braço robótico desenvolvido é composto por motores articulados e uma base. As

articulações, por sua vez, são responsáveis por gerar movimentos de translação e rotação. O braço

robótico foi confeccionado utilizando um material plástico denominado MakerBot PLA Filament

(Filamento MakerBot PLA) para impressão de objetos sólidos tridimensionais. A escolha dos

componentes físicos para a criação do braço robótico levou em consideração a leveza dos materiais

produzidos em impressoras 3D apresentando um bom equilíbrio entre resistência e flexibilidade.

A seguir serão mostrados os módulos que constituem o braço robótico.


61

3.6.2 BASE

A base do braço robótico foi produzida para ser encaixada nas extremidades de uma mesa

que mede 25,6mm, possibilitando o seu deslocamento para outros ambientes. O modelo da base

mostrado na Figura 20 e Figura 21 é fixada a uma peça denominada fixo_mx-64 através de

parafusos do tipo allen (2,7mm de diâmetro) que, por sua vez, é responsável por fixar e sustentar

a estrutura do completa do braço robótico.

3.6.3 OMBRO

O Ombro é o servomotor Dynamixel MX-64 escolhido por ter um torque de

aproximadamente 5.5N.m (à 11.1V,3.9A) capaz de sustentar todo o peso do braço, que pode ter

até no máximo 2,8kg acoplado com um dispositivo móvel de até 155g. O motor é fixado à base

através de uma peça denominada movel_MX-64 (Figura 22 e Figura 23). A parte superior do motor

é fixada a uma peça denominada fixo_mx-64 (Figura 24 e Figura 25) através de parafusos do tipo

Figura 20 Base com vista frontal

Figura 21 Base com visão lateral


62

allen (2.7mm diâmetro) que, por sua vez, são responsáveis por transferir a rotação para o resto do

braço. A rotação do Ombro pode chegar até 90º.

3.6.4 COTOVELO

O Cotovelo é o servomotor Dynamixel MX-64 escolhido por ter um torque de

aproximadamente 5.5N.m (à 11.1V,3.9A) capaz de sustentar todo o peso do braço, que pode ter

até no máximo 2,8kg acoplado com um dispositivo móvel de até 155g. O motor é fixado ao osso

(Figura 26 e Figura 27) através de uma peça denominada movel_MX-64 (Figura 24 e Figura 25).

A parte superior do motor é fixada a uma peça denominada fixo_mx-64 (Figura 23) através de

Figura 24 fixo_mx-64 medida 1 Figura 25 fixo_mx-64 medida 2

Figura 23 Movel_MX-64 medida 2 Figura 22 Movel_MX-64 medida 1


63

parafusos do tipo allen (2.7mm diâmetro) que, por sua vez, é responsável por transferir a rotação

para o pulso e para a mão do braço. A rotação do Cotovelo pode chegar até 90º.

Figura 26 Osso medida 1

Figura 27 Osso medida 2


64

3.6.5 PULSO

O Pulso usa o servomotor Dynamixel AX-18A, escolhido por ter um torque de

aproximadamente 1.8N.m (à 12.0V,2.2A), capaz de sustentar o peso da estrutura da mão (vide

Seção 3.5). A parte superior do motor é fixada a uma peça denominada movel_AX-18A (Figura

28 e Figura 29) através de parafusos do tipo allen que, por sua vez, é responsável por rotacionar a

estrutura da mão. A rotação do Pulso pode chegar até 180º.

Figura 29 movel_AX-18 Amedida 2

Figura 28 movel_AX-18 A medida 1


65

3.6.6 MÃO

A mão usa o servomotor Dynamixel AX-18A, escolhido por ter um torque de

aproximadamente 1.8N.m (à 12.0V,2.2A) e capaz de sustentar um dispositivo móvel com um peso

de até 155 g. A parte superior do motor é fixado a uma peça denominada fixo_case (Figura 30)

que, por sua vez, está fixada a uma outra peça denominada case_phone (Figura 31). O case foi

produzido para suportar apenas a linha de smartphone Moto G 1a geração. Para a fixação das

peças, foram utilizados parafusos do tipo estrela. A rotação da mão pode ser programada para

variar de 0º a 330º de forma controlada e de 0º a 360º de forma contínua.

3.6.7 PROTÓTIPO MONTADO

Esta seção apresenta o resultado final do protótipo braço robótico em diferentes

perspectivas. A Figura 32 e a Figura 33 respectivamente mostram o braço robótico montado e em

operação.

Figura 31 fixo_case Figura 30 case_fone


66

A Figura 34 e a Figura 35 mostram o braço robótico em modo desligado.

Figura 32 Braço robótico em operação 2 Figura 33 Braço robótico em operação 1

Figura 34 Braço robótico em modo desligado 1 Figura 35 Braço robótico em modo desligado 2


67

Aqui, são mostrados os detalhes da fixação dos motores do ombro, cotovelo, pulso e mão

a seus respectivos componentes físicos. A Figura 37 mostra o servomotor MX-64 fixado à base.

Figura 37 MX-64 fixado ao cotovelo Figura 36 MX-64 fixado à base

Figura 38 AX-18 fixado ao pulso (AX-18)


68

A Figura 36 mostra o servomotor MX-64 fixado ao braço e antebraço (cotovelo)

sustentando o peso aplicado sobre o pulso do braço robótico. Por último, são mostrados através da

Figura 38 os motores AX-18 A representando respectivamente a articulação do pulso e da mão do

protótipo.

3.7 AR(M)OBO TEST APP

O aplicativo AR(m)obo Test App é um programa destinado a aparelhos móveis com

sistema operacional Android com versão 5.0 (SDK API Level 21) ou para versões mais recentes.

O aplicativo é capaz de conectar a um dispositivo Bluetooth pareado anteriormente, de forma a

enviar comandos específicos e receber respostas a esses comandos via Bluetooth Serial Port

Profile (SPP).

O dispositivo Bluetooth alvo é o controlador Arduino do braço que está programado para

responder aos comandos enviados pelo aplicativo Android.

A aplicação Android fornece uma interface amigável para que o usuário seja capaz de

selecionar o tipo de teste e a angulação que fará o motor do pulso rotacionar, fazendo com que o


69

app leia as informações dos sensores Acelerômetro e Giroscópio durante cada teste. A Figura 39

apresenta o ícone do AR(m)obo Test app e a Figura 40 mostra a tela de configurações da aplicação.

A tela de configuração da aplicação permite ao usuário interagir com o braço robótico

através da funcionalidade Tests (Testes) e da funcionalidade Calibrate (calibração).

Respectivamente, a primeira opção permite a criação de suítes de testes e a sua execução, a

segunda opção oferece o recurso de calibração do braço robótico após a conclusão dos testes. A

funcionalidade de calibração permite que todos os servos do braço robótico sejam posicionados

para 0º. Além disso, também é possível verificar o status de conexão entre os dois hardwares e

compartilhar os resultados dos testes via bluetooth ou através do armazenamento interno ou

externo do smartphone.

A tela com o resultado dos testes ainda está em fase de desenvolvimento, porém pretende-

se exibir o resultado dos testes com a exibição da posição dos sensores de ambos os hardwares

(braço robótico e sensores do smartphone) para que o testador seja capaz de analisar a

conformidade dos sensores embarcados do smartphone durante as mudanças de orientação

Figura 39 Ícone do AR(m)obo Test app Figura 40 Tela de configuração AR(m)obo Test app


70

realizadas pelo protótipo. A Figura 41 mostra a tela com o resultado dos testes com as informações

dos sensores do braço robótico.

3.8 FLUXO DE DADOS

Todos os dados de controle do braço robótico são enviados pela aplicação AR(m)obo Test

app através da comunicação celular via Bluetooth. O KIT recebe esses dados e os convertem em

sinais para os servosmotores. A Figura 42 exibe esse processo.

Figura 42 Processo de fluxo de dados

Figura 41 Tela de Resultados dos testes


71

A programação do microcontrolador foi feita através da linguagem C com o uso da

biblioteca Savage Electronics Dynamixel para criar um conjunto de comandos a fim de posicionar,

mover e girar os servosmotores do braço robótico.

3.8.1 LÓGICA DE TRANSFERÊNCIA DE DADOS

A aplicação móvel gerencia os comandos enviados para o braço robótico, onde o KIT

Arduino MEGA aguarda receber algum valor na sua interface serial para iniciar um processo.

Logo, o KIT responde ao app com as informações do ID do motor, temperatura e a posiçao exata

do motor. Em seguida, guarda os valores gerados através de um log que pode ser armazenado na

memória do smartphone. A Figura 43 representa essa etapa.

Figura 43 Processo de transmissão de mensagens


72

A Figura 43 representa o início eficiente da transmissão dos dados que serão utilizados para

a construção dos sinais que serão interpretados pelos servomotores.

Foram definidos alguns formatos de mensagens que serão interpretadas pelos atuadores do

braço robótico. As mensagens e as suas respectivas funções de controle estáo descritas na Tabela

11.

Tabela 11 Métodos das mensagens

Métodos Descrição

Str Ombro (); //o00 O valor representado pela string ‘o’ representa o controle da articulação

do Ombro. O controle é pré-definido e não pode ser alterado pelo

usuário.

Str Cotovelo(); //c00 O valor representado pela string ‘c’ representa o controle da articulação

do Ombro. O controle é pré-definido e não pode ser alterado pelo

usuário.

Str Pulso(); //p00 O valor representado pela string ‘p’ representa o controle da articulação

do Pulso. O controle é pré-definido e não pode ser alterado pelo usuário.

Str Mao(); //000 Nesta função é esperado um valor de angulação, ex: 45º que será

convertido em string.

O conjunto de valores enviados pela aplicação Android do exemplo da Figura 43 são

responsáveis por mover o servomotores que representam o cotovelo e o pulso. Em sequência,


73

conclui-se o teste realizando um giro de 45º na articulação da mão. A Tabela 12 representa a

estrutura da mensagem.

Tabela 12 Estrutura de Mensagem

Estrutura de Mensagens

0 c p 0 4 5

bytes bytes

Através do exemplo da Tabela 12 várias combinações de movimentos podem sem geradas.

Essas combinações são chamadas de test cases (casos de testes). A Tabela 13 representa alguns

exemplos de casos de testes.

Tabela 13 Esquema de Casos de Testes

A Tabela 13 apresenta três exemplos de testes que são iniciados através da aplicação

Android. No primeiro exemplo, o aplicativo enviará uma mensagem que moverá o servomotor do

ombro e em seguida efetuará uma angulação de 15º. No segundo exemplo, temos uma instrução

que moverá três atuadores: o cotovelo, o pulso e por último a angulação da mão. No terceiro e

último exemplo, temos todos os motores trabalhando em um único teste, onde todas as articulações

recebem um sinal que culminará em um conjunto de movimentos. Percebe-se que quando um dos

atuadores não recebe a mensagem eles ficam no modo stand-by (ocioso) aguardando por alguma

instrução.

Os efeitos causados pelas angulações dos atuadores do ombro, cotovelo e pulso ocorrem

apenas no sentido horário, sendo assim, cada atuador irá rotacionar sempre para frente do testador.

Instrução Motores Mão/Ângulo

o00015 Ombro 15º

0cp045 Cotovelo/Pulso 45º

ocp060 Ombro/Cotovelo/Pulso 60º


74

O atuador da mão rotaciona no sentido horário criando uma circunferência. Essas limitações se

dão ao fato de que o protótipo ainda está em fase de desenvilmento e que se pretende expandir a

rotação para os sentidos horário e anti-horário.

3.9 DESENVOLVIMENTO DO FIRMWARE

O Firmware foi desenvolvido utilizando-se a IDE Arduino 1.6.10 (The Arduino Integrated

Development Environment) com a linguagem de programação C para o microcontrolador Arduino

Mega 2560. Foram utilizadas duas bibliotecas adicionais:

1. SoftwareSerial: Essa biblioteca é responsável pela comunicação Bluetotth entre o

módulo Bluetooth HC 06 presente na placa de controle do braço e a interface

Bluetooth do dispositivo celular que executa a aplicação.

2. DynamixelSerial3: Essa biblioteca é responsável pela interface de controle dos

servomotores presentes nas articulações do braço robótico

A Figura 44 representa uma parte inicial do código, onde podemos ver a inclusão das duas

bibliotecas citadas anteriormente nas linhas #include

Figura 44 Código Inicial


75

Em seguida, podemos visualizar os pinos 10 e 11 da placa Arduino, que são conectados

nos pinos tx (Transmissor) e rx (Receptor) do módulo Bluetooth. Logo após, vemos a criação da

estrutura de comunicação, que utiliza os dois parâmetros (pinos rX e tx) para inicializar.

Também é possível visualizar as definições de constantes, que irão representar cada motor.

Previamente, foi feita uma parte da configuração, de forma que os servomotores de cada

articulação possam ter um identificador único. Assim tornou-se possível poder controlá-los

separadamente, a fim de cada servo realizasse o movimento requerido pelo método de Setup.

Através da Figura 45, podemos ver que foram inicializados alguns parâmetros para a

comunicação Bluetooth e o controle dos servomotores.

Com a linha de código DynamixelBegin, foi configurado o baud rate que é a taxa de

transmissão de dados entre o firmware e os motores. O segundo parâmetro é o pino 2, que

Figura 45 Comunicação Bluetooth


76

funcionará hora como tx, hora como rx. Após isso, são ajustados os parâmetros da comunicação

Bluetooth.

A Figura 46 apresenta um método loop, neste método existe o fluxo de conexão entre os

dispositivos. O firmware checa continuamente se existe um dispositivo pareado com o módulo. Se

existirem dados no buffer de entrada, o Arduino irá analisar o que foi recebido a fim de executar

as tarefas que são descritas na Tabela 13.

Um exemplo de mensagem que pode ser recebida, por exemplo é “o00015”. Essa string é

montada na aplicação móvel e enviada para o Arduino. Ao receber essa mensagem, o código

identifica que foi mandado um comando ‘o’, que representa um movimento simples para o ombro.

Os dois zeros seguidos representam que não há mais movimentos para o respectivo teste, e o valor

‘015’ determina angulação de 15º que deverá ser executado pela articulação da mão. Essa

Figura 46 Código Loop


77

separação é feita pegando-se os 3 primeiros bytes para análise, que representam os movimentos, e

os 3 últimos bytes para gerar o valor de angulo requerido.

Após analisar os dados recebidos, o controlador irá executar um ou mais de um dos

métodos, por exemplo: método do cotovelo (c), método do pulso (p) e método do ombro (o).

Após realizar os métodos específicos demonstrados na mensagem da Tabela 13, o braço

irá executar o método da mão, passando como parâmetro o valor adquirido na mensagem, como

por exemplo, o valor de 15 graus.

Após o fim da execução dos testes, os dados dos motores serão enviados em formato de

string para a aplicação. A string será composta pela concatenação de informações dos motores e

após os testes, essas informações serão: posição, ângulo e temperatura do motor.


Este capítulo descreveu o projeto e implementação do braço robótico AR(m)obo Test e da

aplicação que o controla. Este trabalho envolve o desenvolvimento de hardware e software,

especificado em nível arquitetural através da linguagem gráfica SysML. Também foi possível notar

a diversidade de tecnologias envolvidas no projeto, tal como a linguagem Android, Arduino,

Bluetooth, servomotores e impressão 3D. A implementação foi executada pela equipe de robótica

do C.E.S.A.R. coordenada pelo autor. O motor ainda não se encontra em produção, mas já

encontra-se em fase de testes finais.

Capítulo5–Métricas 78

Capítulo

44 ESTUDO DE CASO

Este capítulo descreve a utilização da aplicação móvel AR(m)obo Test controlando o

braço robótico em um projeto da Motorola, relatando a experiência e os resultados obtidos ao

introduzir o uso de manipuladores robóticos para testes de sensores de smartphones como

ferramenta de apoio ao processo de automação de testes.


4.1 DESCRIÇÃO DO ESTUDO DE CASO

Vimos, no Capítulo 1, as dificuldades encontradas pelos testadores na execução de testes

manuais para sensores de smartphones, quanto na parte referente à execução de testes de rotação

para os modos retrado e paisagem. É sabido que antes do projeto AR(m)obo Test, as atividades de

testes eram realizadas rotineiramente de maneira manual. Esse processo manual funcionava da

seguinte maneira: um testador recebia uma atividade designada para execução de todos os testes

manuais de uma suíte. Primeiramente o testador precisava instalar um aplicativo no smartphone

alvo para fazer a leitura dos sensores acelerômetro e giroscópio, o aplicativo não possui interface

e é iniciado via comando adb. O testador segue um roteiro manual de testes solicitando mudanças

de orientação do smarphone, essas mudanças de orientação eram executadas através de uma

perspectiva dedutiva, sem nenhum tipo de fixação em uma roda giratória com ponteiros e graus.

Após a finalização dos testes o log é interrompido e um relatório é gerado para ser enviado via

pacote aos responsáveis do componente. No Capítulo 1, a maioria dos problemas que impactam a

produtividade dos testadores, como por exemplo, testes fisícos exaustivos, fadiga muscular,

imprecisão nos resultados de cada teste e falta de critérios de aceitação e falha por falta de

domínimo e conhecimento do aplicativo que faz a leitura dos sensores embarcados no smartphone.

Este cenário é comum em quase todos os testes associados ao uso de sensores de smartphones que

sempre precisam da execução adivinda de um ser humano, o que não é ideal.

Com a implantação da abordagem do AR(r)obo Test nos projetos, o testador não precisará

mais gastar energia física para execução repetitiva de suítes de testes como também pode continuar

com suas atividades paralelas sem se preocupar com o andamento da execução dos testes. Sendo

assim, basta criar um conjunto de suítes de testes utilizando um aplicativo instalado no smartphone

que converte os testes da suíte em sinais que serão enviados ao braço robótico. A aplicação de

testes é capaz de executar um conjunto de suítes de até 10 testes obedecendo uma sequência lógica

de pausar sem causar danos ao robô. Para iniciar a execução, o testador só precisar pressionar o

botão Iniciar.

No cenário real de projetos de software que utilizam um processo formal de testes o

responsável pela execução inicia o processo de analise de resultados baseado nos requisitos de


software e de hardware, esta analise define os critérios de aceitação e falha de cada teste. Na seção

a seguir serão mostrados os passos para utilização do aplicativo e do braço robótico.

4.2 FUNCIONAMENTO PASSO-A-PASSO

Nesta seção, serão descritos o funcionamento da aplicação AR(m)obo Test app, desde as

funcionalidades de interagir com o braço robótico até a criação de casos de testes, suítes de testes

e visualização de resultados. Os resultados dos testes serão concatenados e exibidos através de um

único log que estará disponível após a parada total de todas as suítes de testes. A Figura 47 mostra

a tela principal da aplicação.

A Figura 47, ilustra a tela principal da ferramenta. A tela é composta pelas seguintes

funcionalidades:

• Gerenciador de Testes • Calibração

Figure 47 - Tela principal da aplicação. Fonte: Elaborado pelo autor.


• Estatus • Últimos Resultados • Gerenciador de Logs • Status de Conexão • Configurações • Compartilhamento • Exportar

Os primeiros passos para interagir com o aplicativo do projeto AR(m)obo Test é entender

o que cada funcionalidade representa, sendo assim, iniciaremos esta seção explicando em detalhes

o funcionamento do recurso Gerenciador de Testes.

O Gerenciador de Testes é a opção responsável pela criação de suítes de testes e fornece

ao utilizador a escolha de todos os comandos que serão enviados para o braço robótico. Para criar

Figure 48 - Tela Gerenciador de Testes. Fonte: Elaborado pelo autor.


uma suíte ou um conjunto de súites de testes basta apenas clicar na opção para iniciar o processo

de criação/edição de suítes. Este rescurso pode ser visualizada através da Figura 48.

O app disponibiliza a opção (Add suíte) onde o usuário é direcionado para a tela de criação

de suítes de testes. Além disso, o usuário também pode editar uma suíte da lista clicando no botão

representado por um ícone de menu ao lado do ID da suíte. A Figura 49 exibe a tela de criação de

suíte de testes.

Para criar uma suíte de teste o usuário poderá selecionar um conjunto de até 10 testes. O

primeiro passo é selecionar um movimento e em seguida uma angulação. Após a criação do teste

Figure 49 - Tela Criação de Suíte.


o usuário tem a opção de excluir ou editar o referido teste. A Figura 50 mostra um pop-up com o

input (entrada) dos dados de Movimeto e Ângulação.

A Figura 50 representa um exemplo de criação de um test case (Caso de teste) onde apenas

dois movimentos foram selecionados (Ombro e Cotovelo) com um ângulo de 45º. Observe que as

informações podem ser editadas antes de salvar o teste. Cada teste tem por default um ID que é

representado por um número e por um texto para facilitar o visualização e controle de cada teste,

tais informações são geradas de maneira automática pela aplicação.

Após concluir todos os passos necessários para rodar as suítes de testes, o usuário pode

retornar para a tela de Gerenciador de Testes (Vide Figura 48), nesta tela o usuário pode editar

alguma suíte ou iniciar a execução das suítes. O processo de execução obedece às pausas e

autonomia do protótipo que foram estabelecidas na concepção e desenvolvimento desse projeto,

Figure 50 - Pop-up Criação de Testes.


evitando danos ao braço robótico. O processo de execução pode ser compreendido a partir dos

modelos gráficos em SysML descritos no Capítulo 3.

Após iniciar o processo de execução o usuário poderá aproveitar o período de pausa entre

uma suíte e outra para parar ou pausar a execução. O recurso de Stop para totalmente a execução,

logo, todos as suítes que não foram executadas serão perdadas. O Recurso de Pausa visa parar a

execução por um tempo determinado. A Figura 51 exibe a tela com o processo de execução das

suítes de testes.

Como podemos visualizar na Figura 51, cada suíte de testes é executada obedecendo um

período de descando de 10 minutos para que uma próxima súite seja iniciada. Um ícone

representado pela sigla ‘positivo’ é exibido ao lado de cada suíte de testes para confirmar que todos

os testes foram executados, enquanto as suítes que não foram iniciadas recebem o estatus waiting

(aguardando) para sinalizar que a suíte está em modo de espera. Durante a execução o braço

Figure 51 - Processo de Execução de Suítes de Testes


robótico executará uma série de movimentos fazendo uma analogia entre um braço humano a fim

de identificar o comportamento dos sensores acelerômetro e giroscópio.

A tela do aplicativo serve como um modelo de app que também deve rotacionar durante os

giros efetuados pela mão do braço robótico. Um recurso importante é que o usuário poderá

reiniciar o todo o processo de execução, assim os logs serão novamente lidos e subscreverão os

antigos.

A Figura 52 apresenta a tela após a execução de todas as suítes de testes. Após o fim do

processo de execução de todas as suítes o nome da tela muda para Tela de Resultados, nesta tela o

Figure 52 - Tela de Resultados


usuário poderá selecionar uma das suítes para verificar o estatus da execução de todos os testes da

suíte. Este processo pode ser visualizado na Figura 53.

As verificações dos resultados podem ser mostradas de forma simplificada ou através da

visualização full. Para visualizar as informações do teste de forma simplificada, basta clicar sobre

o ID do teste. Após clicar no ID do teste o resultado será apresentado conforme a Figura 54.

Figure 53 - Tela de Resultados por Suíte


A Figura 54 nos mostra uma visualização simplificada de cada teste, neste caso é possível

visualizar apenas as angulações executadas pelo braço robótico e pelo sensor embarcado no

smartphone. Combase nos resultados o usuário será capaz de inferir um nível de aceitação ou de

falha do teste. Ainda nesta tela o usuário também tem as opções de deletar os resultados da suíte,

e isso implica na remoção de todos os resultados da suíte de testes. O usuário também poderá

Figure 54 - Resultado: Forma simplificada


salvar o resultado dos testes da suíte na memória do telefone ou exporta para o SD card ou através

de email ou por outros modos que estão disponíveis nas versões do Android.

A forma de visualização full ocorre como mostrado na Figura 55, onde as informações

gerais acerca dos testes são mostradas, tais como, a velocidade (torque) dos atuadores (motores)

do braço robótico, a temperatura durante a execução dos testes e a posição em que o atuador do

punho que é responsável pela rotação parou em ângulo. Da parte do smartphone será possível

Figure 55 - Tela de Resultados: Modo full


verificar qual a posição exata na qual o dispositivo parou durante a rotação. A geração dos logs

ainda está em fase de desenvolvimento e por este motivo não foi apresentado neste capítulo.


Este capítulo apresentou o uso do aplicativo AR(m)obo Test simulados no ambiente do

laboratório de robótica do CESAR (Centro de estudos e sistemas avançados do Recife) e está em

fase de desenvovimento e testes. Atualmente, o aplicativo e o braço robótico não estão em

operação devido a requisições de melhorias e pelo desenvolvimento do recurso de geração de logs

que ainda está em processo de investigação. O projeto apresentado é essencial para execução dos

testes de rotação e de sensores para os projetos de embarcados do CESAR. O aplicativo e o braço

robótico demonstraram um bom desempenho através dos resultados obtidos na execução de alguns

testes, apesar de uma confirmação estatística deste fato ainda ser necessária.


Capítulo

55 MÉTRICAS

Este capítulo tem como principal objetivo propor métricas a serem usadas no projeto

AR(m)obo Test que são aplicáveis a qualquer projeto de automação de teste caixa-preta robotizada

e apresentar os resultados particulares para o projeto AR(m)obo Test. O intuito de introduzir estas

métricas é ter uma estimativa quantitativa do ganho de produtividade que o AR(m)obo Test pode

trazer.


5.1 INTRODUÇÃO

Para compreender a utilização de métricas no contexto da Engenharia de Sistemas, mais

precisamente no contexto de uma solução que envolve hardware e software, é necessário

esclarecer o conceito de métricas utilizada neste trabalho.

Segundo FERNANDES (1995), toda medida aplicada à Engenharia de Software pode ser

considera uma métrica. De acordo com PARK, GOETHERT e FLORAC (1996), existem quatro

razões para utilizar métricas: avaliação, prevenção e melhoria. Métricas são medidas quantitativas

e fornecem uma indicação da extensão, quantidade, dimensão, capacidade ou tamanho de algum

atributo relacionado a produtos ou processos (PRESSMAN, 2005).

O foco deste capítulo é fornecer, através da proposição de métricas, uma visão quantitativa

sobre a complexidade do uso prático do braço robótico, da sua qualidade, do nível de desempenho,

da produtividade, dos custos e da economia pertinentes ao projeto AR(m)obo Test (FARINES et

al, 2013). Estas métricas são genéricas para serem aplicadas em qualquer projeto similar de

automação robotizada de testes caixa-preta. Alguns valores destas métricas para o braço robótico

serão estimados e outros, calculados a partir das estimativas.

5.1.1 AUTONOMIA

A Autonomia mede por quanto tempo o sistema pode trabalhar continuamente sem

interrupção. De acordo com MICHAELIS (2009) autonomia é algo que possui independência

funcional.

No caso do braço robótico, ele pode operar sobre uma carga de no máximo 190 g.

Dispositivos como Apple Iphone SE, Microsoft Lumia 650 e Google Nexus 5X pesam em torno

de 122 g até 136 g (MOBILEPHONES, 2016). A linha dos smartphones mais potentes têm um

peso suportável para realização de testes através do braço robótico. De acordo com as

especificações dos servomotores utilizados neste trabalho (vide Seção 3.4.4), existe um fator

limitador que não permite o uso contínuo do braço robótico indefinidamente. Cada atuador

(servomotor) possui uma temperatura limite de até 80ºC, exigindo, portanto, um planejamento para

que esse limite não seja excedido. Se os atuadores do braço robótico atingirem a temperatura


limite, eles receberão de forma automática um alarme interno que culminará em um auto-

desligamento dos motores.

Recomendamos que, para evitar que os motores atinjam uma temperatura perto de 80ºC,

o braço possa trabalhar continuamente sem interrupção por até no máximo 10 minutos. Este tempo

é uma estimativa de segurança baseado em testes com o braço durante 2 horas ininterruptas e

baseado na opinião da equipe. Não fizemos nem podemos fazer testes de estresse para definer esta

métrica com precisão dado o alto custo do braço robótico. A especificação dos servomotores

também não dá uma forma de cálculo desta operação. Todas as estimativas deste capítulo são feitas

de forma bastante conservadora para não colocar em risco o funcionamento do braço.

5.1.2 PAUSA

A Pausa é o tempo de descanso que o sistema tem que fazer após o trabalho contínuo

ininterrupto de Autonomia.

O braço robótico tem uma Autonomia de até 10 minutos de trabalho ininterrupto. Após

atingir esse prazo, um tempo de Pausa deve ser estabelecido visando o descanso total dos

servomotores. Recomendamos que o braço deva parar 10 minutos após o tempo de Autonomia.

Após atingir esse prazo, o braço será capaz de retomar suas atividades sem apresentar danos aos

motores.

Um outro aspecto importante utilizado nessa estimativa está associado ao protótipo

desenvolvido. Suas limitações técnicas, como torque, velocidade e temperatura (vide Seção 3.4.4)

requerem uma atenção maior, de modo que o braço trabalhe dentro das condições favoráveis sem

apresentar interrupções, falhas ou baixa performance.

5.1.3 JORNADA DE TRABALHO

A Jornada de Trabalho é o período total de tempo que o braço robótico pode operar

intercalando execuções de Autonomias e Pausas sem necessitar de uma pausa maior.

A Jornada de Trabalho considera o tempo de Autonomia e o tempo de Pausa para responder

a seguinte pergunta: podemos deixar o braço robótico trabalhando 24 horas por dia, 7 vezes por


semana e operando através de períodos de Autonomia seguido de Pausa? Infelizmente, é

necessário um período de pausa maior após uma sequência de Autonomia → Pausa → Autonomia

→ Pausa, etc. O período de Autonomia → Pausa → Autonomia → ... → Pausa antes de iniciar

uma pausa maior é o que chamamos de Jornada de Trabalho.

As referências técnicas de cada servomotor operando sobre um peso de até 190 g, foi um

fator crucial para estimamos que o braço robótico deva trabalhar em uma sequência de Autonomia

e Pausas de no máximo 5 horas.

5.1.4 PAUSA ENTRE JORNADAS

Dada que uma Jornada de Trabalho foi cumprida, a Pausa entre Jornadas é um intervalo de

descanso (tipicamente bem maior que a Pausa) antes de uma nova Jornada iniciar.

Estimamos que uma operação segura do braço exige um intervalo de Pausa entre Jornadas

de 1 hora.

Seja A o tempo de Autonomia, P o tempo de Pausa e JT o tempo de Jornada de Trabalho.

A quantidade de períodos de Autonomia em uma Jornada de Trabalho (AJT) é dada pela equação

abaixo.

𝐴𝐽𝑇 =𝐽𝑇

(𝐴 + 𝑃)

No caso do braço robótico, calculando-se em minutos, temos AJT = (5*60)/(10+10) = 15.

Ou seja, o braço robótico trabalha ininterruptamente 15 vezes ao longo de 1 Jornada de Trabalho.

Seja PJT o tempo de Pausa entre Jornadas. A quantidade de Jornadas de Trabalho e Pausa

entre Jornadas em 24 horas (JT24) é dada pela equação abaixo.

𝐽𝑇24 =24

(𝐽𝑇 + 𝑃𝐽𝑇)

Para o nosso caso, temos JT24 = 24/(5+1) = 24/6 = 4. Ou seja, em 24 horas, temos a

execução de 4 Jornadas de Trabalho (e 4 Pausas entre Jornadas).

A quantidade de períodos de Autonomia em 24 horas (A24) é o produto de AJT * JT24.


𝐴24 = 𝐴𝐽𝑇 ∗ 𝐽24

No caso do braço robótico, A24 = 15 * 4 = 60 períodos de Autonomia em 24 horas. Ou

seja, em 24 horas, o braço trabalha de forma ininterrupta 60 vezes.

Finalmente, a quantidade de tempo trabalhado ininterruptamente em 24 horas (TT24) é a

quantidade de períodos de Autonomia A24 multiplicado pelo tempo de 1 período de Autonomia.

𝑇𝑇24 = 𝐴24 ∗ 𝐴

Para o braço robótico, TT24 = 60 * 10 = 600 minutos (ou 10 horas de trabalho ininterrupto

ao longo de 24 horas).

5.1.5 TESTE POR MINUTO

O Teste por Minuto é a quantidade de testes que pode ser executado em 1 minuto.

A produtividade do braço robótico está intrinsecamente relacionada com a quantidade dos

testes que ele consegue executar dentro de um ciclo. O tempo de execução de um caso de teste

depende da quantidade de movimentos que cada teste pode ter. A aplicação AR(m)obo Test

oferece vários tipos de movimentos para cada teste. Para medir o tempo de execução de um caso

de teste típico, os seguintes dados foram levantados:

1. Teste Curto (caso de teste com 1 movimento): tempo médio de 15 segundos;

2. Teste Médio (caso de teste com 2 movimentos): tempo médio de 30 segundos;

3. Teste Longo (caso de teste com 3 movimentos): tempo médio de 60 segundos.

Com base nestas informações, a Tabela 14 mostra a Quantidade de Teste por Minuto para

testes curtos, médios e longos. A última coluna também mostra quantos testes de cada tipo podem

ser executados em um período de Autonomia.


Tabela 14 Testes por Minuto

5.1.6 PRODUTIVIDADE

Métricas de produtividade têm como principal foco identificar tamanho, prazos, quantidade

de atividades, complexidade e outros. As métricas de produtividade também podem fornecer uma

visão geral sobre o que está ocorrendo, como por exemplo: recursos utilizados e a eficiência da

qualidade dos serviços (SCHULZ, 2009).

No nosso caso, a Produtividade é uma métrica da quantidade de testes que podem ser

executadas em 24 horas.

Para medir Produtividade (P), basta multiplicar a quantidade de testes que são executados

por minuto (QTM) pelo tempo de trabalho ininterrupto em 24 horas (TT24).

𝑃 = 𝑇𝑇24 ∗ 𝑄𝑇𝑀

Para o caso do braço robótico, temos:

• Teste Curto: P = 600 * 4 = 2.400 testes em 24 horas

• Teste Médio: P = 600 * 2 = 1.200 testes em 24 horas

• Teste Longo: P = 600 * 1 = 600 testes em 24 horas

Para comparar com a produtividade do braço robótico com a de um testador humano,

vamos assumir alguns valores. Inicialmente, vamos assumir que o tempo trabalhado

ininterruptamente seja de 8 horas (uma suposição agressiva, pois ninguém consegue usar as 8 horas

do dia de trabalho testando sem fazer pausas). Neste caso, o TT24 = 480 minutos. Assumindo

também que o ser humano é 2 vezes mais rápido que o braço robótico (suposição realista, dado à

velocidade dos motores), temos:

• Teste Curto (humano): P = 480 * 8 = 3.840 testes em 24 horas

• Teste Médio (humano): P = 480 * 4 = 1.920 testes em 24 horas

Tipo de Teste Tempo médio da execução

Testes por Minuto

Testes por período de Autonomia

Teste Curto 15 segundos 4 40 casos de testes

Teste Médio 30 segundos 2 20 casos de testes

Teste Longo 60 segundos 1 10 casos de testes


• Teste Longo (humano): P = 480 * 2 = 960 testes em 24 horas

Apesar de a produtividade humana ser superior ao do braço ao longo de 24 horas de

trabalho nestes cálculos, alguns fatores ignorados podem fazer a produtividade do braço ser

superior: trabalho braçal causa fadiga e exige pausas que não foram computadas acima; outras

pausas relativas a interrupções acontecem inevitavelmente; e erro de execução ao executar um

movimento (o que não ocorre com o braço robótico).

5.1.7 ECONOMIA

Economia calcula quanto tempo leva para o sistema pagar o investimento de sua

construção.

Para calcular os custos em relação ao trabalho realizado pelo braço robótico, devemos

considerar o custo de construção e do tempo do retorno do valor investido.

Seja C o custo do braço robótico. Seja S o salário mensal do funcionário que executa as

mesmas tarefas do braço robótico. A Economia (E) em meses é calculada da seguinte forma.

𝐸 = 𝐶/𝑆

A construção do braço robótico, desde a etapa de concepção até o desenvolvimento final,

foi em torno de R$ 3.500. Considerando o cenário em que um testador ganha um salário mínimo

de R$ 880,00, temos que E = 3.500/880 = 3,98 meses. Como o salário de um testador é maior que

o salário mínimo, o retorno ao investimento acontece antes destes 3,98 meses.


Este capítulo introduziu diversas métricas do braço robótico a fim de fornecer dados de

produtividade e estratégicos para a aquisição deste novo conceito de testes que envolve hardware

e software. Através dos números obtidos, podemos entender a complexidade dos testes, o tempo

de execução e retornos do investimento. O trabalho manual é mais caro e passivo de perdas, como

erros de execução e danos à saúde do indivíduo. As métricas apresentadas são estimativas


conservadoras que não foram baseadas em experimentos controlados. No entanto, servem como

base para uma avaliação da produtividade e retorno ao investimento.

Capítulo5–Conclusões 98

Capítulo

56 CONCLUSÕES

Este capítulo tem como objetivo apresentar as informações acerca dos trabalhos

relacionados, as conclusões, contribuições e recomendação para trabalos futuros.


6.1 INTRODUÇÃO

Este capítulo está estruturado nas seguintes seções:

• Trabalhos relacionados: esta seção provê uma visão geral acerca de alguns

trabalhos relacionados com a presente pesquisa;

• Conclusões, Limitações e Principais Contribuições: são apresentadoas nessa

seção as conclusões e as principais contribuições da dissertação;

• Recomendações para Trabalhos Futuros: nesta seção são apresentadas e

comentadas as oportunidades para realização de trabalhos futuros.

6.1.1 TRABALHOS RELACIONADOS

No Capítulo 2 nós apresentamos um breve histórico e descrição a respeito das técnicas de

testes de caixa-preta para dispositivos móveis utilizando manipuladores robóticos. Porém, não

foram encontradas propostas que tratassem do assunto referente a testes de acelerômetro e

giroscópio de smartphones realizados por um braço robótico articulado controlado via bluetooth.

Por outro lado, existem alguns trabalhos que focam em testes de caixa-preta utilizando a

abordagem de usar robôs para testar o desempenho geral de smartphones e até mesmo simulando

toques humanos para testes de interface. A seguir introduziremos algumas abordagens de testes de

caixa-preta aplicados por manipuladores robóticos.


6.2 BRAÇOS ROBÓTICOS

Robot-assisted smartphone performance testing é uma abordagem apresentada por

KANSTRÉN, T. et al (2015) que utiliza um robô fisico para fazer testes de performance em

smartphones baseados em perfis de usuários. Tal processo consiste em capturar as ações do usuário

abstraindo-os a perfis de uso e transformando-os em modelos de testes e geração de casos de testes

a partir desses modelos. O objetivo geral do trabalho é apoiar testes de performance através do

touch screen (tela sensível ao toque) em aplicações através de um ambiente real de testes.

Os autores usaram o conceito de ‘atividade’ como sendo um ou mais eventos realizados

pelo usuário diretamente na interface do sistema Android. Um outro aspecto importante está

relacionado ao efeito de sondagem (probe-effect) utilizado para descrever o impacto que uma

medida tem sobre o sistema que está sendo observado. O Modelo de Markov (Markov-model)

também foi utilizado para modelar os aspectos comportamentais do usuário.

A arquitetura geral da solução tem três principais partes: um aplicativo de coleta instalado

no smartphone, um servidor e o agente de testes. O mobile clients (aplicativo de coleta de dados)

recolhe os dados de uso do smartphone, enquanto o servidor coleta, armazena e converte esses

dados em um modelo de Markov adequado para geração de casos de testes. Finalmente, o agente

de testes gera casos de testes a partir do modelo e os executa, controlando o robô de teste.

Cada transição feita através dos modelos de Markov é mapeado para uma etapa de testes

reproduzida com o auxílio do robô. O robô executa um conjunto de comandos onde um dedo

artificial toca na tela do dispositivo, que acontece dentro de uma precisão milimétrica. Quando o

robô toca em um determinado ponto, o smartphone é configurado para gravar as coordenadas onde

o evento de toque aconteceu, servindo como dados para comparação da performance entre o tempo

de toque e o tempo de resposta ao evento. A Figura 47 mostra o uso do robô tocando na tela do

smartphone em testes.


A Google utiliza uma abordagem de testes de performance um pouco parecida com a

solução proposta por KANSTRÉN, T. et al (2015): o Chrome TouchBot. Tal robô é utilizado para

testar o tempo de latência da interface do Android e do Chrome OS (ENGADGET, 2014). A Figura

48 mostra o Chrome TouchBot tocando na tela do smartphone em teste.

Percebe-se que a academia e a indústria têm se preocupado cada vez mais com a inclusão

de robótica no contexto de verificação e testes utilizando manipuladores robóticos controlados por

aplicativos Android para diversos fins.

Figura 56 Touch-screen testing robots. Fonte: Kanstrén, T. at al (2015).

Figura 57 TouchBot. Fonte: Engadget (2014).


Um outro trabalho relacionado foi recentemente publicado por Jason Huggins (HUGGINS,

2012) denominado BitbeamBot, que é um hardware (robô CNC) open-source que pode testar

qualquer aplicação em qualquer dispositivo móvel da mesma forma que uma mão humana faria.

O projeto de Jason Huggins utiliza as linguagens de automação Selenium API e Python para criar

testes automatizados que serão executados pelo robô. Esta solução visa diminuir os efeitos dos

testes exaustivos e repetitivos. O projeto BitbeamBot é apenas um protótipo e não pode ‘ver’ onde

estão os elementos na tela do smartphone, sendo necessário criar scripts de testes a partir de um

computador que enviará sinais elétricos para os motores que moverão o pino (dedo robótico) sobre

qualquer lugar da tela (BITBEAMBOT, 2012).

Empresas como a SYMBIO (2016), GRUPO HDI (2016) e OPTOFIDELITY (2016)

desenvolvem soluções robóticas para garantia da qualidade em diversas áreas, incluindo a

utilização de braços robóticos para interagir com smartphones como se fossem seres humanos. O

objetivo geral dos robôs fabricados por essas empresas é esgotar as possibilidades lógicas de um

sistema antes que ele se torne público. Os testes mais aplicados também estão relacionados à gestos

e toques na tela do smartphone.

Nenhum dos trabalhos relacionados apresentados utilizam a abordagem de testar sensores

de smartphones como o acelerômetro e o giroscópio a fim de verificar o comportamento do sistema

nas diferentes mudanças de orientação do dispositivo em testes. A maioria não poderia ser utilizada

dentro do contexto proposto pelo nosso trabalho. Porém utilizam alguns serviços e infraestrutura

que podem ser classificadas como tal. Um ponto em comum em quase todos os trabalhos aqui

relacionados é a utilização de um aplicativo que lê dados do smartphone em testes e a simulação

de movimentos humanos para viabilizar um cenário mais próximo da realidade humana nas

interações entre sistemas e com isto, economizar esforço manual.

6.3 CONCLUSÃO

O planejamento do projeto proposto, a implementação e, por fim, as métricas resultantes

do trabalho realizado com o uso do braço robótico mostram que é possível introduzir a abordagem

de testar o comportamento do software através das mais variadas mudanças de orientação do

smartphone de uma maneira lógica e precisa. Este trabalho apresentou a arquitetura do sistema

através da representação gráfica SysML, o que possibilita informações relevantes para os usuários

e clientes de empresas de software que desejam mergulhar no contexto de testes que envolvem

software e hardware.


Através das métricas e informações contextuais inferidas, a aplicabilidade dos testes para

sensores de smartphones podem notificar aos interessados erros de software comumente não

identificados quando testados por seres humanos, tais como: perda de componentes textuais,

mudanças de orientação, interferências entre sensores (sensor de proximidade vs acelerômetro),

falha de sensores e outros. Esta nova modalidade de validação e testes nos permite inferir uma

maior cobertura em áreas pouco exploradas por existir um gap em soluções de apoio a esse tipo

de teste. Como também, incrementar um maior nível de segurança e confiabilidade ao processo de

planejamento e execução de testes através de um braço robótico.

O modelo proposto por esta dissertação difere dos trabalhos relacionados apresentados

anteriormente por utilizar uma forma de comunicação e controle sem fio (via bluetooth), por

utilizar a abordagem de desenvolvimento de código aberto e por focar diretamente no contexto de

testes de caixa preta em software e hardware. Até o momento da escrita desta dissertação, não

foram encontradas na literatura trabalhos com esse tema de modo que contribuíssem para o escopo

geral desta pesquisa.

De acordo com as métricas apuradas foi possível identificar as vantagens do uso do braço

robótico em detrimento ao uso de um ser humano. As principais vantagens estão associadas aos

aspectos relacionados à repetição de testes com carga fisíca, execução controlada e programada,

comparação entre posições de sensores, registro de logs de ambos os hardwares e a possibilidade

de automação de testes através do uso de frameworks que podem acessar o aplicativo AR(m)obo

Test criando suítes de testes.

Com base nos resultados apresentados, pode-se afirmar que o modelo de arquitetura

proposto neste trabalho permite a construção de um manipulador robótico de baixo custo que pode

ser facilmente implementado em empresas de software e afins. O modelo do protótipo e do

aplicativo que o controla também pode ser readaptado de acordo com as necessidades dos seus

stakeholders e podem ser aplicados em dois diferentes contextos como: testes de software; testes

de hardware; ou em ambos.

6.4 CONTRIBUIÇÕES

As contribuições resultantes deste trabalho de pesquisa e desenvolvimento foram as

seguintes:


1. Projeto e arquitetura em SysML de um braço robótico articulado para teste caixa-

preta de acelerômetro e giroscópio de smartphones;

2. Desenvolvimento do projeto pela coordenação da equipe de robótica do CESAR na

implementação e montagem do protótipo e da aplicação Android de testes,

integrando tecnologias como: servomotores, Bluetooth, Arduino, Android e

impressão 3D.

3. Criação de métricas para extração de informações de desempenho e performance

do uso do braço robótico, tais como: métricas de autonomia, pausa, jornada de

trabalho, pausa entre jornadas, testes por minuto, produtividade e ecomomia,

mostrando a viabilidade de construção do braço tanto técnica quanto econômica.

6.5 LIMITAÇÕES

Devido a pouca disponibilidade de equipamentos da empresa parceira, não houve tempo

suficiente para terminar a criação e programação de todos os movimentos propostos para o braço

robótico, apesar de todos os esforços dos envolvidos pelas equipes do laboratório de robótica do

CESAR – Centro de Estudos e Sistemas Avançados do Recife.

Desta maneira, limitou-se a um dia de testes e avaliação dos resultados obtidos pelo ser

humano e pelo braço robótico.

Vislumbrou-se a possibilidade de utilização de um frameowork automático de testes para

iniciar a aplicação AR(m)obo Test app e colocá-la em background de modo que o comportamento

de um outro software (app) fosse verificado. Isso enriqueceria a cobertura e verificação do

comportamento de outras aplicações disponíveis no smartphone em testes. A aplicação AR(m)obo

Test app não dispõe de um recurso para gravar a tela do smartphone durante os testes a fim de

verificar possíveis falhas durante as mudanças de orientação do dispositivo após a finalização de

cada teste.

Uma outra limitação, porém não menos importante está relacionada à leitura do LOG

durante os testes com o braço robótico que se dá apenas pelo log gerado pela própria aplicação de


testes (AR(m)obo Test app). O Logcat do Android é um recurso que monitora mensagens de logs,

porém não pôde ser utilizado porque o braço robótico dispensa uso de cabos, visto que os

movimentos que o braço robótico efetua são de rotação frequente, o que impossibilitaria o uso de

fios conectados a computadores.

6.6 RECOMENDAÇÕES PARA TRABALHOS FUTUROS

A empresa CESAR – Centro de Estudos e Sistemas Avançados do Recife, que viabilizou

este projeto de pesquisa e desenvolvimento, já iniciou o processo de utilização do protótipo

AR(m)obo Test desenvolvido. Primeiramente em seu ambiente de testes/homologação e

posteriormente, no seu ambiente real de produção. Diante deste cenário foram propostos alguns

trabalhos fututos, dos quais podemos destacar:

1. Integrar novos sensores ao escopo do aplicativo de testes, como: sensor de

proximidade, sensor de movimento, sensor geomagnético (magnetômetro) e sensor

RGB (sensor de luminosidade).

2. Incrementar a aplicação de testes com adição de novas regras de negócio que

permitam usar automação de testes para verificar o comportamentos de outras

aplicações que não utilizam sensores como acelerômetro e giroscópio.

3. Melhorar a interface do aplicativo AR(m)obo Test app de modo que seja possível

visualizar o comportameno de outras aplicação durante os testes com o braço

robótico.

4. Utilizar uma interface mais apropriada para possibilitar a leitura dos LOGs, de

modo que seja possível diminuir os riscos associados ao não entendimento dos

LOGs gerados, entre outros problema

106

REFERÊNCIAS

A. K. Maji, K. Hao, S. Sultana, and S. Bagchi, “Characterizing Failures in Mobile OSes: A Case

Study with Android and Symbian,” Software Reliability Engineering, International Symposium

on, vol. 0, pp. 249–258, 2010.

Bitbeambot. Building a Robot that Can Play Angry Birds on a Smartphone, (or Robots are the

Future of Testing), 2012 <https://us.pycon.org/2012/schedule/presentation/470/>. Acesso em: 05

de ago. 2016.

Black, R. (2003). Critical Testing Process: Plan, Prepare, Perform, Perfect. Addison Wesley.

C. Hu and I. Neamtiu, “Automating GUI Testing for Android Applications,” in Proc. of the 6th

Int. Workshop on Automation of Software Test, ser. AST ’11, 2011, pp. 77–83.

CARTAXO, E. G. Geração de Casos de Testes Funcional para Aplicações de Celulares.

Dissertação (Ciências da Computação) – Universidade Federal de Campina Grande, Campina

Grande - Paraíba, 2006.

DA FONSECA, Celso Suckow. Centro Federal de Educação Tecnológica. 2016.

DAVIS, G. (2008). ―Managing the Test Processǁ, IEEE 2000, 2000.

de Souza Pinto, Hugo Rodrigues, et al. "O desenvolvimento de elementos de proteção de fachada

responsivos: explorando o cobogó." Blucher Design Proceedings 2.3 (2015): 519-527.

E. Kit. Software Testing in the Real World: Improving the Process. Addison-Wesley, 1995.

Emarketer 2014. 2 Billion Consumers Worldwide to Get Smart(phones) by 2016 - <https://www.emarketer.com/Article/2-Billion-Consumers-WorldwideSmartphonesby2016/1011694> Acesso em: 05 de ago. 2016.

Emarketer 2016. Mcommerce Trendsfor 2016 – Behind the Rapid Growth, 2016

<http://www.emarketer.com/Webinar/Mcommerce-Trends-2016Behind-RapidGrowth/4000137>

Acesso em: 05 de ago. 2016.

107

Engadget. Here's how Google checks for lag on your Android phone, 2015. Disponível em:

<https://www.engadget.com/2015/06/28/google-chrome-touchbot/>.Acesso em: 05 de ago. 2016.

ENGINEERING, 2013. “Dynamixel: Networkable Robotics Servo Motor Family”

<http://www.engineering.com/Library/ArticlesPage/tabid/85/ArticleID/6626/DynamixelNetwork

able-Robotics-Servo-Motor-Family.aspx> Acesso em: 10 de ago. 2016.

Esbjörnsson, Linus. "Android GUI Testing: A comparative study of open source Android GUI

testing frameworks." (2015).

FARINES, Jean-Marie; FRAGA, Joni da Silva; OLIVEIRA, RômuloSilva de. Sistemas de Tempo

Real. Disponível em: <http://www.das.ufsc.br/~romulo/livro-tr.pdf>. Acesso em 02 de Agosto de

2013.

FERNANDES, A. A., “Gerência de Software Através de Métricas”. Atlas, São Paulo, São Paulo,

1995.

FRIEDENTHAL, S., MOORE, A., STEINER, R., OMG Systems Modeling Language (OMG

Tutorial), USA, 2008.

Grupo HDI. Robotic Arm Testing, 2016 <http://www.grupohdi.com/webnew/robotic.html>.

Acesso em: 05 de ago. 2016.

GUEDES, G. T. A. UML 2 - Guia de Consulta Rápida. São Paulo: NovaTec Editora, 2005.

HARROLD. M. J. Testing: a roadmap. In: 22nd International Conference on Software

Engineering. Junho, 2000.

HAUSE, M. The SysML Modelling Language. In: FIFTEENTH EUROPEAN SYSTEMS

ENGINEERING CONFERENCE. Anais. . . [S.l.: s.n.], 2006.

HETZEL, W. Program test methods. Prentice Hall, 1973.

IDC. Smartphone OS Market Share, 2015 Q2, 2016. <http://www.idc.com/prodserv/smartphone-

os-market-share.jsp>. Acesso em: 05 de ago. 2016.

108

IEEE (2004). Guide to the Software Engineering Body of Knowledge. IEEE Computer Society,

2004.

IEEE Standard 610-1990: IEEE Standard Glossary of Software Engineering Terminology, IEEE

Press.

J. Awrejcewics e Z. Koruba, “Advances in Mechanics and Mathematics,” em Classical Mechanics:

Applied Mechanics and Mechatronics, Springer, 2012, pp. 15-26.

Kanstrén, T., Aho, P., Lämsä, A., Martin, H., Liikka, J. and Seppänen, M., 2015, May. Robot-

assisted smartphone performance testing. In 2015 IEEE International Conference on Technologies

for Practical Robot Applications (TePRA) (pp. 1-6). IEEE.

KOBAYASHI, Carlos Yassunory. "A Tecnologia Bluetooth e aplicações."Computação Móvel–

BBC–IME–USP (2004).

Koscianski, A. e Soares, M. S. (2007). Qualidade de Software: Aprenda as metodologias e técnicas

mais modernas para o desenvolvimento de software. 2 ed. São Paulo: Novatec, 2007. 395p.

Kyllönen, Kalle. "Evaluating Model Based Testing using Robot Platform for Nokia Product

Software Testing." (2015).

Labiod, Houda, Hossam Afifi, and Costantino De Santis. WI-FITM, BluetoothTM, ZigbeeTM and

WiMAXTM. Springer Science & Business Media, 2007.

LEWIS, W. E. Software Testing Continuous Quality Improvement. Boca Raton, USA: Auerbach,

2000.

M. J. Mataríc, “Arms, Legs, Wheels, Tracks, and What Really Drives Them: Effectors and

Actuators,” em The robotics primer, The MIT Press, 2007, pp. 29-45.

Matti Vuori, Tampere University of Technology, (2013), RATA project report: elements-of-robot-

assisted-test-systems. Used in 28.9.2014

MELHORAMENTOS. Dicionário Michaelis. Melhoramentos, 2009.

109

MILLER, B. et. al. “Bluetooth Revealed”, 1. ed. Addison Wesley, 2001.

MOBILEPHONES. Top 5 Lightest Smartphones. Written by Michael Brown on 30th March 2016.

Disponível em: <http://www.mobilephones.com/top-5-lightest-smartphones/>. Acesso em: 27

dez. 2016.

MUCCINI, Henry; DI FRANCESCO, Antonio; ESPOSITO, Patrizio. Software testing of mobile

applications: Challenges and future research directions. In: Automation of Software Test (AST),

2012 7th International Workshop on. IEEE, 2012. p. 29-35.

MYERS, G. The art of software testing. John Wiley and Sons, 1979.

Myers, J. G. (2004). The Art of Software Testing. Second edition Revised and updated by Tom

Badgett and Todd M. Thomas with Corey Sandler. John Wiley and Sons, New Jersey, U.S.A.,

2004. 234 p.

Optofidelity. Mission: Solution for replicating and testing human handwriting, 2016

<http://www.optofidelity.com/our-work/>. Acesso em: 05 de ago. 2016.

PARK, R. E.; GOETHERT, W. B.; FLORAC, W. A. Goal Driven Software Measurement - A

Guidebook. Pittsburgh, PA 15213: Software Engineering Institute, Carnegie Mellon University,

1996.

PFLEEGER, Shari L. Engenharia de Software: Teoria e Prática. 2ª ed. São Paulo: Pearson Prentice

Hall Brasil, 2004.

PIERIN, Almir Roberto; VARGEM, Bruno Marçau; FERRES; Rogério da Veiga. Implementação

do sistema de controle e acionamento de mesa posicionadora XYZ. 2015. 75 f. Trabalho de

Conclusão de Curso (Graduação) – Universidade Tecnológica Federal do Paraná, Curitiba, 2015.

PRESSMAN, I. (2005). Engenharia de Software. Pearson Education do Brasil.

PRESSMAN, R. Software Engineering: A Practitioner’s Approach. 6. ed. New York, NY, USA:

McGraw-Hill, Inc., 2005.

110

PRESSMAN, Roger S. Engenharia de Software. São Paulo: Pearson Makron Books, 1995.

PRESSMAN, S. R. Engenharia de Software. São Paulo, BRA: McGraw-Hill. 5. ed., 2002.

R. H. Bishop, Mechatronic Systems, Sensors, and Actuators: Fundamentals and Modeling, Boca

Raton : Taylor & Francis, 2008.

SCHULZ, George. The green and virtual data center. [S.L.]: Taylor & Francis Group, 2009.

SILVA, A. J. d. Aspectos da modelagem em SYSML ligados à seleção de processador para sistema

embutido. 2006. Dissertação (Mestrado em Ciência da Computação) — Universidade Federal de

Santa Catarina.

Sinclair, Ian. Sensors and transducers. Newnes, 2000.

Soares, M. d. S. e Vrancken, J. L. M. (2007). Requirements specification and modeling through

SysML. In IEEE International Conference on Systems, Man and Cybernetcs, 2007. ISIC. on, pp.

1735-1740.

Sommerville, I. (2007). Engenharia de Software. Addison Wesley, 8 ed. 2007.

Sommerville. Software Engineering. Addison-Wesley, 2000.

SYMBIO. MULTI-DEVICE UI TEST AUTOMATION WITH RATA, 2016

<http://www.symbio.com/solutions/quality-assurance/rata-robot-aided-test-automation/>. Acesso

em: 05 de ago. 2016.

System Modeling Language (SysML) Specification. Version 1.4, Junho. 2015.

Systems Modeling Language (SysML) Specification. Version 0.9, Janeiro. 2005.

TESTDOID 2014. Bitbar Mobile App Testing on Android and iOS Devices, http://testdroid.com/,

referenced 3 Oct 2014. Acesso em: 05 de ago. 2016.

111

Vanderperren, Y. e Dehaene, W. (2005). SysML and Systems Engineering Applied to UML-Based

SoC Design.

Weilkiens, T. (2011). Systems engineering with SysML/UML: modeling, analysis, design.

Morgan Kaufmann.

WEILKIENS, T. Systems engineering with SysML/UML: modeling, analysis, design. The

MK/OMG Press. Elsevier. Amsterdam, 2006.

WEILKIENS, Tim, Systems Engineering with SysML/UML ,1 ª edição, Morgan Kaufmann

Publishers Inc., 2007.

Leonilson de Araújo Barboza · manualmente. As execuções de testes de rotação e translação...

Documents

Transcript of Leonilson de Araújo Barboza · manualmente. As execuções de testes de rotação e translação...