Universidade Tecnológica Federal do Paraná – UTFPR

Departamento Acadêmico de Eletrônica – DAELN

Departamento Acadêmico de Informática – DAINF

Engenharia de ComputaçãoOficina de Integração 3 (IF66J) – S71 – 2016/2

Relatório TécnicoAlfred: O Robô Garçom

André B. Santos – andrebadenas@gmail.com

Felipe Minatel – minatel@alunos.utfpr.edu.br

Jimmy Y. T. Soares – jimmytsoares@gmail.com

Outubro de 2016

Resumo

A automação tem sido o foco em diversas áreas de conhecimento nosúltimos anos, e é com esse objetivo que esse projeto chamado Alfred foidesenvolvido. O Alfred busca, através de dois aplicativos em Android e umrobô automatizado, otimizar o tempo de chegada dos pedidos, bem comoproporcionar uma experiência diferenciada aos consumidores. Neste re-latório serão tratados as tecnologias utilizadas, o processo de concepçãobem como testes com o robô e aplicativos. A partir dos testes realizados,foi obtido um resultado satisfatório, com o robô chegando ao seu destinode forma correta e rápida, mostrando que futuras aplicações em restau-rentes podem se tornar viáveis.

1 Introdução

A busca pela automação e agilidade serve como catalisador para o desenvolvi-mento de novas tecnologias, que por sua vez tem o objetivo de melhorar o co-tidiano do ser humano. Essas melhorias podem se mostrar tanto em software,com aplicativos de gerenciamento, quanto em hardware, como por exemplo acriação de robôs para uma tarefa específica[1].

Acredita-se que a criação de robôs para uso pessoal crescerá da mesma formaque o uso de computadores pessoais nos últimos 40 anos[2], mostrando-se por-tanto uma área promissora. Como citado em [3] e [4], a presença de robôs emrestaurantes é algo que é realidade.

A ideia de um sistema mais ágil em um restaurante não é nova. Foi em 1958que o japonês Yoshiaki Shiraishi abriu o primeiro restaurante de sushi de esteirado mundo em Osaka, Japão [5]. Com o passar dos anos a popularidade da inven-ção de Shiraishi só aumentou, chegando a virar um negócio de U$2,1 bilhões deacordo com [6]. Atualmente é possível encontrar esse tipo de restaurante comfacilidade nas grandes cidades ao redor do mundo, o que mostra que a pratici-dade levou esse mercado ao sucesso.

1

Relatório Técnico: Alfred 2

Projeto Alfred tem o intuito de criar um sistema automatizado de atendi-mento em restaurantes. Ao integrar um robô autônomo a um sistema para fazerpedido controlado pelo próprio usuário, Alfred busca otimizar o atendimentoem restaurantes deixando-o mais rápido, pois agiliza o processo de recebimentode pedidos. Além disso, com a realização de pedidos via aplicativos, Alfred for-nece uma experiência diferenciada ao cliente.

O desenvolvimento, como esquematizado na Figura 1, consiste na imple-mentação de dois aplicativos Android para organizar os pedidos e um robô comsoftware de navegação autônoma.

Figura 1: Visão Geral do Projeto.

O aplicativo para o cliente deve ser aberto quando ele chegar ao restaurante.Ao sentar em uma mesa vazia, o cliente digita o nome e o número da mesa,para que então possa fazer seu pedido com sucesso. No próprio aplicativo ocliente escolhe pelo cardápio o que deseja e então manda o pedido para a cozi-nha, onde fica o aplicativo Gerente. Nesse aplicativo o cliente também poderáacompanhar o status do pedido, cancelar um pedido e o consultar o valor daconta.

No aplicativo Gerente, que administra os pedidos que são recebidos, o funci-onário tem listado as informações de nome do cliente e a mesa de cada pedido.Assim que o prato estiver pronto, o Gerente, que opera o aplicativo Gerente,coloca o prato no robo e seleciona a opção do aplicativo chamada de enviarpedido, que envia para o robo qual mesa correspondente ao prato que ele estálevando. Nesse aplicativo também será possível fazer alterações no cardápio.

O robô então começa seu percurso em direção à mesa. O número da mesaé convertido no robô em duas cores distintas. A primeira cor sinaliza qual trilhao robô deverá seguir e a segunda qual a cor do ponto de parada. É importanteressaltar que as cores devem ser distintas, para o robô reconhecer que a segundacor é um ponto de parada e não continuação da trilha. Assim, o robô segue atéa mesa correspondente, para e aciona um LED para avisar ao cliente que suarefeição chegou. O LED fica acionado enquanto o robo estiver parado na mesa.Após um tempo pré-determinado, suficiente para o cliente retirar sua refeição,

Relatório Técnico: Alfred 3

o robô volta pelo mesmo caminho para a cozinha.Para que a concepção do projeto seja possível, foram levantados os seguin-

tes requisitos funcionais e não-funcionais:Requisitos Funcionais

• O cliente deve ter o aplicativo instalado em seu celular ou tablet e deveestar conectado a internet.

• O cliente deve informar nome e um número da mesa existente, o sistemanão deve aceitar números de mesa inexistente.

• Assim que o cliente mandar o pedido, o servidor remoto deve então no-tificar o aplicativo Gerente (na cozinha). Devendo conter nome, númeroda mesa e pedido do cliente e possíveis observações.

• Com o pedido pronto, o Gerente deve colocá-lo no robô e então informarpelo aplicativo o número da mesa e pedido.

• O robô não deve aceitar outro número de mesa até que entregue o atual.

• O robô deve seguir em direção a mesa sem pausas em quaisquer outrasmesas que não seja a recebida pelo Aplicativo Gerente.

• O robô deve seguir seu caminho por meio das trilhas demarcadas no chão,com diferentes cores para diferentes grupos de mesas.

• O robô deve reconhecer a mesa desejada por meio de cores no chão, decor diferente a trilha traçada.

• Ao reconhecer a mesa, o robô deve parar e continuar na posição por umtempo aceitável para o cliente retirar o pedido. Um LED deve indicar aocliente que aquele é de fato o pedido dele.

• Ao exceder o tempo limite o robô deve dar meia volta e seguir o caminhoaté a cozinha, onde deve haver um outro padrão para parada.

Requisitos Não-Funcionais

• Os aplicativos serão feitos para Android. As funcionalidades feitas na lin-guagem Java e o layout em XML.

• O software de navegação será feito em C++.

• A biblioteca OpenCV será utilizada.

• O robô deve ser portátil o suficiente para funcionar sobre um balcão delargura moderada.

Relatório Técnico: Alfred 4

• A velocidade do robô não deve ser muito alta para não acarretar proble-mas com o pedido, mas ao mesmo tempo não deve ser muito lento.

• O funcionário deve operar o aplicativo Gerente sabendo das restrições dosistema.

• As trilhas devem estar em um ambiente com luz controlada, devido a sen-sibilidade que uma câmera pode ter com alterações luminosas.

2 Componentes e Tecnologias

Esta seção é separada em sistema embarcado, bibliotecas utilizadas, plataformaestrutural e aplicativos, citando e descrevendo a função de cada componente etecnologia necessário para a construção do Alfred.

2.1 Sistema Embarcado

O sistema embarcado do projeto em questão será construído, assim como foimostrado pela Figura 1, usando os componentes que serão a seguir descritos.

Raspberry PiAssim como mencionado anteriormente, o Raspberry Pi 3(RPI3) é essencial

para o Alfred. Isso porque ele fornece uma performance muito boa pelo seupreço e tamanho, o que é necessário para manipular os dados da câmera corre-tamente e de forma eficiente. As características específicas do RPI3 são:

• CPU: Quadcore 64-bit 1.2GHz ARM Cortex A53

• GPU: Broadcom VideoCore IV @ 400MHz

• RAM: 1GB (LPDDR2-900 SDRAM)

• Armazenamento: Micro SD

• Portas USB: 4

• Ethernet: 1

• Wi-Fi: 802.11n Wireless LAN

• Bluetooth 4.0

• Saída de video: HDMI

• GPIO: 40

Relatório Técnico: Alfred 5

Além da sua capacidade de processamento, os pinos 40 pinos de GPIO (General-purpose Input/Output) do RPI3 deixam espaço de sobra para atender todas asnecessidades do projeto.

O sistema operacional utilizado é o Raspbian Jessie, gratuito e baseado noDebian otimizado para o uso no RPI.

Módulo da CâmeraO módulo da câmera do RPI utilizado é a versão 1 de cinco megapixels com

foco fixo. Ela é conectada por meio da porta CSI. Embora a versão 2 possuaqualidade melhor e um sensor feito pela Sony, ela exige maiores capacidades deprocessamento, podendo sobrecarregar o RPI3. Ainda, a versão 2 é mais caraque a 1.

2.2 Bibliotecas Utilizadas

Com todos os equipamentos definidos, é necessário que eles consigam se co-municar entre si. Antes mesmo de programar, diversas bibliotecas devem serinstaladas para que o funcionamento do Raspberry Pi ocorra como se deve noprojeto. Segue abaixo as principais bibliotecas utilizadas e suas funções.

WiringPi: Uma biblioteca para C/C++ para o controle das portas GPIO do RPI.Com essa biblioteca é fácil mandar comandos para a ponte H e acender oLED de notificação.

OpenCV : A biblioteca é referência para visão computacional em inúmeras pla-taformas. Permite que os dados vindos da câmera sejam traduzidos emmatrizes que podem ser manipuladas e analisadas para poder navegar orobô corretamente.

Biblioteca de integração do módulo da câmera do RPI: A princípio o OpenCVnão consegue lidar com o módulo da câmera do RPI diretamente. Aoanalisar essa complicação, dois desenvolvedores independentes decidi-ram criar uma biblioteca para auxiliar as pessoas que desejam utilizar essacombinação. Pierre Raufast1 criou a primeira biblioteca, onde ele explicadetalhadamente a motivação em seu site. Algum tempo depois, Emil Val-kov2 decidiu aprimorar o código de Raufast e deixou no Git as suas altera-ções .

Com essas bibliotecas utilizadas em conjunto o objetivo é alcançado com me-nos dificuldade. Essa combinação foi utilizada em um projeto parecido de um

1https://thinkrpi.wordpress.com/2013/05/22/opencv-and-camera-board-csi/2https://robidouille.wordpress.com/2013/10/19/raspberry-pi-camera-with-opencv/

Relatório Técnico: Alfred 6

desenvolvedor chamado Arne Baeyens3. Ele criou um robô seguidor de linhacom as mesmas bibliotecas, mas chassi e motores diferentes.

2.3 Plataforma Estrutural

A equipe decidiu comprar um chassi pronto devido a nenhum integrante dogrupo ter qualquer experiência em confecção de um design. Foi encontrado umchassi de dois andares redondo que possui tudo necessário para a parte mecâ-nica do Alfred. Além da base em acrílico o chassi acompanha dois motores DCcom redução, rodas e, para gerenciar os motores, uma ponte H L298N, uma dasmais utilizadas para essas aplicações.

Figura 2: O chassi utilizado pela equipe.

2.4 Estação Base

Para o Alfred foram proposto duas estações bases, o aplicativo Cliente e o apli-cativo Gerente, ambas em Android. Para justificar o uso de tais estações, assimcomo foi apontado por [7], o crescimento do número de smartphones faz comque o uso dessa tecnologia tenha um futuro promissor, portanto, isso torna inte-ressante para o projeto utilizar os mesmos como “estação-base”. Contudo tam-bém existem vários Sistemas Operacionais (SO) a disposição do usuário, desta-cando iOS, Android e Windows Phone como os principais. Para limitar o escopodesse projeto, com base nos dados apresentados por [8], uma empresa especia-lizada em comportamento do consumidor, é capaz de perceber que o mercadobrasileiro é dominado por 92.4% dos dispositivos vendidos que utilizam o SOAndroid.

Para a implementação dos aplicativos, serão utilizados o Android Studio comoplataforma de desenvolvimento e o Hostinger como servidor para banco de da-dos remoto. Para a integração do banco de dados com o aplicativo foi usada abiblioteca Volley, uma biblioteca HTML que facilita e agiliza serviços de rede emAndroid, como envio de dados.

3https://www.raspberrypi.org/blog/an-image-processing-robot-for-robocup-junior/

Relatório Técnico: Alfred 7

3 Desenvolvimento

O desenvolvimento foi separado nos três principais componentes do projeto, oAplicativo Cliente, o Aplicativo Gerente e o Robô Garçom.

3.1 Aplicativo Cliente

Para o desenvolvimento do Aplicativo Cliente foi utilizado o Android Studio etodas as funcionalidades a ele pertinentes. Em sua tela inicial, o usuário devedigitar seu nome e a mesa em que sentou. Essas informações são armazenadasem um banco de dados externo hospedado no Hostinger. Em seguida apareceráuma tela com três opções: Fazer pedido, consultar pedido e fechar conta.

(a) (b)

Figura 3: Telas do aplicativo Cliente. (a) Tela de boas-vindas, (b) Tela de Menu.

Ao selecionar "Fazer Pedido", o aplicativo importa do banco de dados re-moto a tabela cardápio. O usuário ao selecionar os produtos do cardápio quedeseja consumir, cria uma instância na tabela pedidos, contendo os atributos:código do pedido, mesa, código do produto, quantidade, preço, situação(na filaou a caminho) e observarções. No campo observações o cliente especifica pe-quenas alterações ao pedido quando comparado ao original, como por exemploum suco de laranja sem gelo, onde sem gelo é a observação relacionada ao sucode laranja.

Ao clicar em "Consultar Pedido", o aplicativo busca na tabela Pedidos os pe-didos associados à mesa do cliente e exibe seu conteúdo, omitindo o código dopedido, e dá destaque a sua situação(na fila ou a caminho). Após o robô entregaro pedido, e assim que ele voltar a cozinha sem prato, envia uma solicitação aoaplicativo Gerente para mover o pedido recém entregue para a tabela entregues.

Relatório Técnico: Alfred 8

Por fim, em "Fechar Conta", calcula-se o preço final de todos os pedidosrealizados pela mesa salvos na tabela entregue, enviando uma notificação aoaplicativo Gerente para enviar um garçom para receber o pagamento. Também,"fechar conta"apaga todos os pedidos da mesa que o solicita, bem como as in-formações do cliente na tabela cliente.

3.2 Aplicativo Gerente

Como o Aplicativo Cliente, também foi utilizado o Android Studio para seu de-senvolvimento. O aplicativo Gerente deverá ser instalado somente no smartphonedo Gerente, para evitar problemas de segurança. A tela principal tem as opções:Modificar Cardápio, Pedidos e Enviar Pedido.

Figura 4: Tela de Menu do aplicativo Gerente.

Em Modificar Cardápio, o Gerente é capaz de alterar produtos do cardápio,adicionar novos produtos ou excluir. Já em Pedidos, o aplicativo mostra quaissão os pedidos feitos pelos clientes que ainda não estão prontos, listando porordem de chegada. Finalmente quando o Gerente colocar o prato ou bebida norobô e clicar em Enviar Pedido, o aplicativo abre uma tela e o Gerente selecionaqual pedido deverá ser entregue. Feito isso, é enviado por Wi-Fi a mesa referenteao pedido e ao mesmo tempo modifica a situação do pedido de "na fila"para "acaminho", bem como envia uma notificação ao aplicativo do cliente que fez esseo pedido informando que está "a caminho".

3.3 Robô Garçom

O robô possui várias funções que serão abordadas nas subseções abaixo, bus-cando explanar como foram feitas as implementaçãos de tais funções.

Relatório Técnico: Alfred 9

3.3.1 Distinção das cores

Com o uso da biblioteca OpenCV a manipulação de imagens é significativa-mente facilitada devido as diversas funções prontas que a biblioteca oferece.As imagens captadas pela câmera são por padrão no sistema de cor RGB, po-rém filtrar cores utilizando esse sistema é complicado pois não é intuitivo comoalgumas cores são formadas.

Uma solução é transformar no sistema de cor HSV, que separa a imagemem 3 canais, sendo eles matiz, saturação e valor. Com isso obtemos um canalque representa o espectro de cores e ajuda muito na detecção das cores. Essestrês canais são analizados separadamente que o programa converte a imagemobtida pela câmera em três imagens em escala de cinza. Cada canal é transfor-mado em imagens binárias utilizando uma função que retorna cada ponto daimagem branco caso tal ponto esteja em um certo limite determinado. Para dis-tinguir uma cor, cada canal é analizado e posteriormente são adicionados no-vamente para formar uma única imagem binária. Com essas informações umprograma foi feito apenas para a calibração das cores, em que a cor desejada émostrada para a câmera e depois cada canal é ajustado para ter o alcance dese-jado, obtendo no fim uma gama de valores para cada cor a ser utilizada.

3.3.2 Seguidor de linha

Para rastrear, e posteriormente seguir uma linha, é necessário saber que cor éa linha a ser seguida. Essa escolha depende do teste a ser feito, mas as cores jáserão pré-definidas pelas trilhas, logo cada cor já estará bem definida para serrastreada. Utilizando o método da subseção anterior, deverá existir uma ima-gem binária que mostra apenas a linha a ser analizada.

O começo da análise parte da criação de três regiões de interesse(Region Of

Interest,ROI)

, que são divididas em três colunas na imagem. Uma ROI é umaimagem que consiste em uma subparte de uma imagem original. Uma conta-gem de pixels brancos são feitos em cada uma das ROI. A tomada de decisãoé bem simples, caso a coluna da esquerda tiver mais pixels, deve-se virar à es-querda. A mesma abordagem é feita para as outras ROI. A Figura 5 mostra isso.

3.3.3 Acionamento dos motores

Para acionar os motores, a biblioteca WiringPi deixou tudo simplificado. O GPIOdo Raspberry Pi é capaz de gerar até 5V em seus pinos, o que é o suficiente paraa entrada da ponte H, que aceita níveis TTL. A biblioteca é simples, basta cha-mar algumas funções para definir se um pino é entrada ou saída no começo doprograma. Como o projeto não depende de entradas, todos os pinos utilizadosforam de saída, que são atribuídos como níveis alto ou baixo com uma simplesfunção que recebe o número do pino e seu nível.

Cada motor possui duas entradas, a fim de poder girar em ambas as dire-ções. Portanto, um programa teste foi feito para saber os níveis corretos para

Relatório Técnico: Alfred 10

Figura 5: Representação de como as ROI funcionam.

seguir em frente, virar para esquerda ou para a direta e para virar 180º. Tal testeproporcionou os níveis necessários para cada operação dos motores, tornandopossível a criação de funções no código que realizem tais operações.

3.3.4 Comunicação

Para comunicar o aplicativo Gerente com o robô e por fim enviar o pedido paraa mesa, é utilizado a comunicação Wi-Fi, da mesma forma que os aplicativos secomunicam entre si. O aplicativo Gerente escreve no banco de dados as infor-mações de qual mesa e qual pedido está sendo colocado no robô. Em seguida orobô acessa o banco de dados e lê qual é o seu destino.

Essa comunicação é facilitada por meio da biblioteca cURL, que facilita aobtenção do arquivo HTML de uma página na web. A página acessada e obtidapossui apenas dois números, correspondentes a número do pedido e da mesa,facilitando o parseamento dos dados. O número do pedido é necessário paraque o robô não volte a mesma mesa que ele acabara de ir, interpretando comoum novo pedido. Quando um novo pedido está pronto para ser enviado, a pá-gina é atualizada, e uma flag no programa permite o robô avançar por não ser omesmo pedido anterior, mesmo se for na mesma mesa.

Relatório Técnico: Alfred 11

4 Resultados

Esta seção debate os resultados obtidos fazendo a análise dos custos e dos testesrealizados.

4.1 Montagem do Robô

O primeiro passo a fim de ter testes com sucesso é conseguir montar o robô demaneira eficaz, balanceado e com espaço livre em seu topo.

Figura 6: A montagem final do robô e seus componentes destacados.

Como visto na figura 6, a montagem deixou um espaço no topo do robô paraque o pedido possa ser colocado. Além disso, foi necessário duas fontes distintasde tensão: uma para o RPI e outra para a Ponte H. O RPI não pode alimentar di-retamente a ponte H pois os motores requerem uma alta corrente, o que causa-ria problemas no funcionamento do computador. Outro ponto a se mencionaré que utilizando 4 pilhas alcalinas para a ponte H acabou gerando tensão alta(6V) demais, fazendo com que a velocidade do motor atrapalhasse no seguidorde linha. Testes empíricos mostraram que utilizando pilhas de tensões menoresem dois dos quatro espaços, uma velocidade ideal para o robô seguidor de linhaé obtido, permitindo um tempo suficiente para que cada frame seja processadoantes de uma decisão do motor, evitando um efeito zigue-zague, em que o robôacaba não andando em linha reta, mas tentando virar o tempo todo a fim de

Relatório Técnico: Alfred 12

deixar a trilha em seu ROI central.

4.2 Teste de Iteração Completa

O teste de iteração completa consiste em pegar os dados do aplicativo clienteaté a volta do robô a cozinha após levar o pedido a mesa. Primeiro o aplicativocliente é aberto e faz um pedido, simulando um cliente real. O aplicativo Ge-rente recebe com sucesso o pedido, e então informa o robô o número do pedidoe qual mesa deve ser entregue. A Figura 7 mostra a tela do aplicativo que realizatal função.

Figura 7: Tela do aplicativo Gerente em que se manda o pedido para o robô.

O robô deve conseguir chegar até a mesa seguindo a linha corretamente, pa-rar e acender um LED de notificação. Após determinado tempo, deve dar meiavolta e chegar ao ponto inicial, dando novamente meia volta a fim de ficar coma câmera apontada para as trilhas.

Esse teste foi realizado com sucesso, tal constatação foi feita após diver-sas mesas diferentes serem atendidas. O teste pode ser visto na seguinte URL:https://youtu.be/t1c-gNnA4Cs

Além disso, foram feitas medidas de velocidade média para o teste, comopode ser visto na Tabela 1. Essas medidas levaram em consideração o tempodesde a saída do robô até a meia-volta ocorrida ao retornar para o ponto inicial.Por tal razão, as mesas mais distântes acabaram ficando com uma velocidademédia superior, tendo em vista que parte do tempo é constante para todas asmesas. Sem contar os tempos de parada, a velocidade média é bem maior doque os vistos na tabela, chegando a um valor de 0,195 m/s.

Relatório Técnico: Alfred 13

Figura 8: Exemplo de trilha utilizado no teste de iteração completa.

Mesa Distância Total Tempo Velocidade Média1 1,3m 11s 0,12 m/s2 2m 15s 0,13 m/s3 2,8m 18s 0,15 m/s4 3,6m 21s 0,17 m/s

Média Final 0,1425 m/s

Tabela 1: Velocidade média para o alcance de cada mesa.

4.3 Custos

Os custos do projeto realizado estão descritos na Tabela 2.A partir da tabela, é possível perceber que para uma aplicação comercial al-

guns custos poderiam ser reduzidos ou até mesmo inexistentes. O chassi podecustar menos se for feito ao contrário de ser comprado pronto, evitando cus-tos extras com o suporte de acrílico. Além disso, o teclado foi um custo para odesenvolvimento do projeto, porém não é necessário para o funcionamento domesmo, podendo então ser descartado em uma aplicação em maior escala.

5 Conclusões

Com o fim do projeto, algumas conclusões podem ser feitas:

• O projeto Alfred pode muito bem cumprir seu objetivo inicial, de ser um

Relatório Técnico: Alfred 14

Custo AlfredComponente Quantidade ValorRaspberry Pi 3 1 R$200,00

Câmera 1 R$85,00Chassi 1 R$115,00

Adesivos p/ trilhas 2 R$30,00Cabos 5 R$5,00

Suporte Pilha AA 1 R$3,90Teclado 1 R$60,00

Pilhas (pacote) 1 R$6,90LED 3 R$2,00

Suporte Acrílico Bateria 2 R$30,00Total R$537,80

Tabela 2: Custos do projeto.

sistema de automação de restaurantes, contanto que o ambiente seja bemcontrolado.

• A câmera do RPI pode gerar variações indesejadas durante a operação,portanto muitos testes de calibração devem ser feitos sempre.

• Por meio de testes empíricos, se constatou que a velocidade média idealpara um robô seguidor de linha é de 0,18m/s.

• Utilizando uma bateria portátil para celulares, tendo saída 5V 2.1A (am-peragem essencial para não haver problemas) e capacidade 10000mAh, oRPI pode ser mantido ligado por pelo menos 6 horas, possivelmente che-gando a muito mais que isso, faltando testes para saber o real potencial.Portanto é possível afirmar que funcionaria em um restaurante com ho-rário de funcionamento padrão de 12 horas.

• O robô que serviu de inspiração para esse projeto, chamado L2Bot (feitona Lawrence Technological University), tem um custo total para quemdeseja comprar um exemplar da universidade de 290 dólares (982 reais),sendo necessário ainda um laptop para seu funcionamento. O projeto Al-fred conseguiu as mesmas funcionalidades e ainda dispensou o uso deum laptop por quase metade de tal valor. Portanto o custo do projeto éconsiderado satisfatório.

Relatório Técnico: Alfred 15

Referências

[1] Mannuela Cruz and Vidigal De Oliveira. Sistema de Automao de Pedidos eServios. 2007.

[2] Bill Gates. A Robot in Every Home. 2008.

[3] Sakari Pieska, Mika Luimula, Juhana Jauhiainen, and Van Spiz. Social ServiceRobots in Wellness and Restaurant Applications. Journal of Communicationand Computer, 10(1):116–123, 2013.

[4] Rafael M Teixeira and Robert E Werutsky. AUTOMAÇÃO EM RESTAURAN-TES.

[5] Agence France-Presse. Yoshiaki Shiraishi, 87, Sushi Innovator, 2001.

[6] Mark Magnier. Yoshiaki Shiraishi; Founded Conveyor Belt Sushi Industry,2001.

[7] Graziela Simone Tonin. Tendencias em Computação Móvel. 2012.

[8] Kantar Worldpanel. Smartphone OS sales market share.