Como já dito, a aplicação móvel teve por função, receber e transcrever os comandos de voz do usuário, enviando-os para o Raspberry. Já o script do Raspberry teve por função interpretar os comandos enviados pela aplicação móvel e gerar a respectiva ação, como o acionamento de uma carga elétrica, por exemplo. Dessa forma, foi necessário que
52 Capítulo 5. Resultados
ambos fossem desenvolvidos de uma única vez, pois faziam parte de um conjunto maior responsável pelos módulos de controle de cargas, como a iluminação, através de comandos de voz.
No início, o desenvolvimento da aplicação móvel se deu pela criação do protocolo de comunicação entre a mesma e o Raspberry, onde se usou sockets de conexão não persistente, que através de uma porta de rede, permitia que a aplicação enviasse e o script do Raspberry recebesse os comandos. Utilizando do problema do produtor-consumidor, foi estabelecido de que forma os comandos seriam tratados pela aplicação móvel e pelo script, mantendo uma estratégia que evitasse problemas de transmissão de comandos. Para que o
socket pudesse estabeler uma conexão entre as partes, era necessário que ambos estivessem
configurados com o mesmo endereço IP e o mesmo número de porta. Assim, na tela inicial da aplicação móvel, foi inserido dois campos, onde o usuário poderia inserir o IP e porta que estavam inseridos nas configurações do socket do script.
Como foi definido que se usaria a própria rede Wi-Fi da residência para manter a comunicação dos dispositivos, a configuração do IP na aplicação móvel se daria pelo endereço que o Raspberry se encontraria na rede, logo se o endereço IP do Raspberry fosse 192.168.0.63 por exemplo, na tela inicial da aplicação móvel, o usuário deveria inserir este endereço no respectivo campo. Por definição, foi adotado que a porta padrão para comunicação das partes seria 8000, dessa forma, o socket do Raspberry estaria configurado com a porta 8000 e na tela inicial da aplicação móvel, no campo porta já estaria por padrão, preenchido com a porta 8000. Como dito, a comunicação das partes seria pela própria rede da casa, mantida por um roteador e dessa forma, os primeiros dígitos do endereço IP seria por padrão 192.168, assim foram inseridos como valores iniciais no campo de IP da tela da aplicação móvel, que pode ser vista na figura 10.
Após inserir os dados para conexão, o usuário deve clicar no botão Conectar, porém esse botão não realiza a ação de connect do socket, ou melhor dizendo, ele não estabelece comunicação com o Raspberry, mas apenas configura as propriedades do socket da aplicação móvel, para uma futura conexão não persistente. Após configurar o endereço IP e a porta do socket, a aplicação invoca sua segunda tela de iteração com o usuário, que contém um botão para chamada da API do Google Speech e uma lista com todos os comandos já enviados para o Raspberry através da aplicação, que pode ser vista na figura 11.
Ao clicar no botão com ícone de um alto falante, a aplicação realiza uma chamada a API do Google Speech, que fornece uma ferramenta para utilizar o microfone do aparelho celular para gravar áudios e transcreve-los em texto. Não só gravar e transcrever texto, essa API também utiliza inteligência artificial para adaptar a API ao tom e tipo de voz do usuário, de forma a diminuir cada vez mais, o erro de leitura e transcrição dos áudios. Outra funcionalidade desta API que também é adotada para o projeto é o envio dos áudios recolhidos pela API para a conta Google do usuário, que é previamente inserida ao
5.1. A Aplicação Móvel e o Script para o Raspberry 53
Figura 10 – Tela Inicial da Aplicação Móvel
Fonte: Autor (2018)
começar a utilizar o aparelho com sistema Android. Dessa forma, a API do Google Speech permite que o sistema tenha uma inteligência artificial para melhorar o uso da aplicação móvel e manter os comandos do usuário em sua conta Google. A tela com a chamada da API pode ser vista na figura 12.
Assim que a API identifica uma leitura de dados e termina de transcreve-lo, ela retorna esse texto para a aplicação, que em seguida invoca uma thread no atual processo da aplicação móvel no sistema Android. Esta thread é responsável por utilizar o socket configurado previamente para abrir uma conexão com o Raspberry e então enviar o comando em forma de texto. A thread permite que todos processos para estabelecer a comunicação e enviar os comandos seja feito de forma paralela ao processo da aplicação móvel, o que evita a parada do funcionamento do aplicativo, permitindo que outras funções, como inserir o comando enviado na lista de comandos, continue acontecendo sem problemas. Assim que o comando é enviado, o socket é fechado, fazendo assim a conexão não persistente, porém a thread não é destruída, mas fica em modo de espera, sem gastar recursos do sistema operacional, aguardando outra chamada da aplicação. Uma tela com alguns comandos já enviados e inseridos na lista pode ser visualizada na figura 13.
O script para o Raspberry mantém um socket que fica esperando requisições da aplicação para que haja o envio dos comandos. Quando os comandos são recebidos, ele os interpreta e faz com que o Raspberry execute a determinada ação. Este script foi desenvolvido em Python, pelo alta facilidade de se manipular textos com esta linguagem,
54 Capítulo 5. Resultados
Figura 11 – Tela de Comandos da Aplicação Móvel
Fonte: Autor (2018)
o que foi essencial para que o mesmo pudesse interpretar de forma correta os comandos recebidos. Através de uma biblioteca do Python, também foi possível controlar as GPIOS do Raspberry, assim acionando ou desligando os módulos relés para que fosse possível então, controlar as cargas elétricas. A figura 14 traz a execução do script no terminal do sistema operacioal do Raspberry, ao receber determinados comandos.