Hubee - Marketplace for Things

Participantes:

Christopher Villagra
Vinicius Fiorentino

Resumo do projeto:

Gateway que realiza a comunicação entre coisas da sua casa e marketplace de serviços, e gerenciando os serviços de forma conveniente e inteligente.

Descrição do projeto:

Espalhado pelo mundo, existem muitas cidades que os substantivos ‘Sociedade’ e ‘Tecnologia’ estão sempre caminhando lado a lado de forma progressiva e em constante evolução. Produtos e serviços são criados, ou inovados, a fim de tornar a vida de todos mais proveitosa, do que desgastante. O termo ‘smart’ tem sido utilizado para tratar pessoas, empresas, cidades, ou qualquer grupo de indivíduos, que enxergam e compreendem as mudanças que estes produtos, ou serviços, devem sofrer para que uma linha evolutiva seja seguida.

Infelizmente este cenário está com delay no Brasil, onde temos pessoas que confiam no mais trabalhoso – muitas vezes mais custoso – e desconfiam do inovador e comodo. É claro que existem muitas pessoas, consideradas como smart, que possuem um crivo mais racional, trazendo uma luz no final do túnel brasileiro. Do outro lado estão indivíduos que além de reprovar sem avaliar, como corresponde, também pregam o regresso de todo o trabalho evolutivo que profissionais e instituições tem trabalhado muito para tornar realidade. Depredação de equipamentos disponibilizados para o uso da sociedade, interesse de tirar proveitos e vantagens de algo ou alguém, ou qualquer outro comportamento que não faz parte dos casos de usos de quem produziu, ou de quem presta o serviço, é sim um assunto preocupante que deve ser tratado melhor.

Para mudar esse cenário, trazendo novas experiências para consumidores e fornecedores, o projeto Hubee foi criado.

O Hubee foi criado para trazer o incrível conceito de ‘Marketplace for things’, com a missão de ir além da solução para uma dor específica de um consumidor de serviços, minando a evolução tecnológica da sociedade como um todo. Soluções Iot irão conectar as suas coisas de casa com os serviços favoritos de cada pessoa, sendo ela entusiasta de tecnologia ou conservadora, que prefere manter o jeito tradicional que ‘não falha’. Isso será possível, porque o projeto Hubee desenvolve dispositivos para serviços de diferentes níveis de necessidadeXcomodidade, como a de um serviço de lavanderia que substitui um equipamento – volumoso -, na casa do consumidor, por cesto inteligente que sabe o momento de requerir uma coleta para a higienização do seu conteúdo, ou como o serviço de entrega de gás que é acionado momentos antes de esvaziar um botijão de gás, que por um acaso é sempre no momento do preparo de uma refeição. Com estes dois exemplos podemos visualizar as duas pontas que o projeto Hubee pretende atingir, uma que temos os indivíduos que estão dispostos a substituir procedimentos e equipamentos arcaicos por soluções que trazem agilidade, comodidade e satisfação, e outra ponta com os indivíduos que preferem se manterem conservadoras mas que podem aderir ao mínimo de soluções extra conceituais, para que as suas rotinas tradicionais não sejam afetadas – entrando numa encubadora tecnológica sem perceber.

Como frisado anteriormente, o foco do projeto Hubee vai além dos interesses dos consumidores, entra também no interesse dos prestadores de serviços. Isso porque, seja qual for o porte ou nível de acesso a canais de vendas e recursos para adquirir clientes, o prestador de serviço conseguirá disponibilizar o seu serviço para a utilização no ecossistema Hubee. Serviços como o de entrega de água, que em determinadas localizações, podem possuir apenas um smartphone para receber os seus pedidos, ainda por aplicativos de mensagem, poderão seguir com a sua estrutura mas com mais visibilidade. Com um registro na plataforma, para o(s) determinado(s) dispositivo(s), e definindo a forma com que receberá as notificações de novos pedidos, já é o bastante para conectar serviços de pequeno porte com grandes necessidades. Ainda para estes pequenos prestadores de serviços que não possuem uma grande variedade de formas de pagamentos, muitas vezes não aceitando nem cartão de crédito ou débito, poderão receber seus pagamentos pela plataforma, tirando o risco de perder vendas por conta disso. Agora, subindo o nível de prestador de serviço, temos os grandes marketplaces de serviços, como os de refeição, lavanderia, transporte, que já possuem todos os recursos tecnológicos para atender bem o seu cliente. Para estes serviços, o projeto Hubee tem uma configuração especial, que o tornará um ‘dispatcher’ de pedidos prontos para serem executados por eles, com o pagamento realizado, no melhor dos cenários. um dispositivo de acionamento de serviços favoritos será desenvolvido, deixando o caminho livre para o consumidor configurar serviços rotineiros que independem de ‘coisas’ interconectadas em sua residência. Agendamento de serviços a domicilio, serviço de entrega de um restaurante favorito com o seu pedido de sempre, solicitação de um serviço de transporte para suas rotas mais comuns, estes são poucos dos muitos serviços que o projeto Hubee pode trazer através de dispositivo que se encaixa em qualquer ambiente.

Abaixo temos um diagrama que ilustra a rede que o projeto Hubee cria:

[DIAGRAMA HUBEEE]

O projeto Hubee tem a visão de que é possível dinamizar cidades deixando a tecnologia de ponta mais acessível, sem ter que seus habitantes tenham que sofrer uma burocratização para tornar o cenário real. O modelo aplicado no protótipo do projeto Hubee tem um alto nível de escalabilidade, podendo ser aplicado numa casa, num condomínio, bairro, cidade e até onde os limites territoriais permitirem. Facilmente, pequenas cidades, ou bairros isolados, podem ter seus serviços conectados com tecnologia de ponta, com o devido esforço aplicado, claro.

Os diagramas abaixo ilustram essa escalabilidade:

[DIAGRAMA CASA]

[DIAGRAMA CONDOMINIO]

[DIAGRAMA CIDADE]

Histórico do desenvolvimento:

Semana 1 – 11 de Agosto a 18 de Agosto:

Para o momento inicial desse concurso, os integrantes do projeto se reuniram para discutir assuntos gerais do projeto e para que fique claro qual o objetivo e conceito que serão cumpridos durante a execução.
Foi realizado um brainstorm para prever o máximo de tarefas a ser executado para a entrega do projeto. Para não existir a possibilidade de chegar no dia da entrega e não termos algo funcionando para mostrar, organizamos as sprints de forma que cada uma delas seja uma versão estável do projeto. Dessa forma, o desenvolvimento do projeto fica progressivo e mais seguro.
Foram definido os dias que os integrantes iriam se reunir – obrigatoriamente – para informar o status da sprint em execução. Outras chamadas no dia-a-dia podem surgir, mas a reunião de status deve ser cumprida.
Para finalizar a primeira semana, criamos a identidade do projeto Hubee:

Semana 2 – 19 a 25 de Agosto:

Nesta semana recebemos o kit de desenvolvimento Arrow – DragonBoard 410C e Kits com sensores Mezzanine.

Foi realizado um longo review da placa dragonboard, no qual esclareceu as possibilidades e os limites que teríamos no decorrer do desenvolvimento do projeto.
Instalação do sistema operacional Ubuntu Core, e outros softwares, para já ire preparando o laboratório de testes com o hardware principal. Houveram algumas dificuldades (limitações) ao utilizar o sistema, como o acesso SSH que era impossibilitado ao trocar de rede WIFI.
O projeto dos recursos de hardware foi finalizado e a listagem para providenciar está pronta para ser providenciada. Buscamos por hardwares Qualcomm, porém no Brasil é bem dificil à pronta entrega, então optamos por utilizar componentes, módulos e placas de prototipagem mais popular – apenas para entregarmos o protótipo da forma que foi definida. O momento do projeto Hubee após a entrega, para se chegar a um MVP, sofreria mudanças no cenário de recursos para se alcançar a qualidade e novos objetivos.

Semana 3 – 26 a 01 de Setembro:

Demais recursos tecnológicos foram definidos, como o fornecedor da nuvem, plataforma de aplicativo. Também foi realizado um benchmark de empresas que fornecem o serviço GSM, focando nos que possuíam a propriedade de trabalhar com IoT. Entramos em contato com as que melhores se encaixavam com a nossa necessidade, entre elas a Vodafone, Hologram, easy M2M, Vecto Mobile, Tim e Vivo. Algumas já responderam que não atendem a região no momento, outras foram descartadas por burocracia.
Foi iniciado o desenvolvimento da arquitetura da nuvem, que será a centrar de informações do projeto. Em cima da arquitetura, será implementado uma plataforma para tratar as informações trafegadas pela ‘rede interna’. Pela performance e tempo de resposta num fluxo estressante de dados, foi definida como linguagem do software o Python 3.x.

Com a compra dos hardwares, componentes e outros itens que irão compor o parque do projeto, torna-se possível iniciar o desenvolvimento e testes com o laboratório completo. Os primeiros testes foram na Dragonboard, acessando os seus GPIOs.

Semana 4 – 02 a 08 de Setembro:

Depois de uma série de testes de conexão com o GPS da Dragonboard, e depois de consultar e participar do fórum da 96boards, decidimos fazer um down grade na opção do sistema operacional Linaro, para a versão 17.04. Essa mudança foi exclusivamente para o uso do GPS, já que na notações do ultimo release (V18) ele tenha sido desabilitado, como consta:

NOTAÇÃO
Onboard GPS using Qualcomm GNSS subsystem (disabled in this release)
https://releases.linaro.org/96boards/dragonboard410c/linaro/debian/18.01/

Agora é possível realizar a leitura do GPS, claro que esperando um pouco até a resposta do satélite, que só é possível em céu aberto. Com isso uma nova demanda é gerada para uma sprint futura, onde uma antena externa é necessária.

 

Após algumas ligações e reuniões com os fornecedores de serviço GSM, ficou decido passar por um período de testes com a empresa Vecto Mobile, que disponibilizou um kit de SIM Cards com todas as funcionalidades ativas para prototipar de acordo com a necessidade do projeto. Também foi realizado um ótimo treinamento na plataforma de monitoramento da Vecto Mobile, para entendermos o formato de trabalho deles e para facilitar o uso do serviço.

Alguns endpoints já começam a ser testados na API, que vai criando forma ao ser instalada numa instancia na nuvem da AWS. Todo o território da API está preparada, com os DNS apontados, certificados Letsencrypt criados e tratados, segurança de dados aplicado, e outros recursos de infra aplicado.

Instalação do software mraa, para a utilização das GPIOs. Além das GPIOs, foram testadas as conexões UART e IC2, que serão utilizados para os módulos externos de GPS e Display (ainda incerto);

Semana 5 – 09 a 15 de Setembro:

A API está finalizada e com todos os endpoints previstos configurados e prontos para utilizar. Foi criado uma Postman Collection com os endpoints que seriam utilizados nesta fase de prototipagem, assim os integrantes do projeto atualizado a fim de testes e documentação.

Com o recebimento do kit da Vectomobile com os SIM Cards, é possível iniciar os testes de comunicação GSM. Também foi adquirido um SIM Card da TIM, para efeitos de comparação.

Após inúmeros testes não tivemos sucesso na comunicação GSM, descartando problemas de conexão física e lógica entre a Dragonboard e o módulo GSM, descartando problemas no módulo GSM e descartando defeito no kit de SIM Cards da Vecto Mobile. Através de uma fonte controlada, inserimos uma tensão regulada a 4.2V diretamente no módulo, e também conectamos a conexão GND do módulo com o GND da Dragonboard. Essa calibragem de tensão fez o módulo funcionar corretamente.
Um regulador de tensão Step Down foi solicitado para ser incluído no conjunto de hardwares do Gateway.

Houve uma nova ligação com o Thiago da Embarcados e com o Bruno da Qualcomm, que informaram a nova data de entrega do projeto. Com isso foi feito uma reunião extra, entre os participantes do projeto, para fazer alguns ajustes de entregas, em relação ao novo cronograma. Foi adicionado 4 novas micro entregas, como a de acabamento.

Semana 6 – 16 a 22 de setembro:

Esta semana foi desenvolvido o software que ficará embarcado na Dragonboard 410C. Nele contém rotinas e procedimentos que em conjunto, gerenciam todos os dispositivos que estão em rede, manipulam hardwares externos, e realiza a comunicação com a nuvem, fazendo as verificações e tratamento de dados necessários.
Definimos utilizar rede do tipo Mesh para a rede Hubee, que ira interconectar todos os dispositivos da rede. Isso porque, imagina-se que os nodes (dispositivos IoT) nem sempre estarão próximos o bastante do gateway, mas quem sabe de um outro node – que pode funcionar como ‘extensor’ da sua rede. A imagem abaixo ilustra como imaginamos que será o Hubee quando utilizado por inúmeros nodes:

A Dragonboard foi definida como hotspot da rede, e também será o broker da rede para a troca de dados via protocolo MQTT. Para isso foi utilizado o software Mosquitto, ajustando algumas informações para os acessos dos dispositivos sem maiores burocracias tecnológicas, mas om segurança.

Nesta semana finalizamos também o desenvolvimento do app do usuário final. Através desse APP o usuário poderá controlar os seus dispositivos, adicionando ou removendo eles, setando limites, verificando status, e o principal, definindo seus serviços favoritos para eles.


Semana 7 – 23 a 29 de setembro:

Começamos nessa semana a implementar a testar o gateway de pagamento Iugu, para simular as gerações de pagamentos a medida que o usuário for consumindo os serviços pela rede. Finalizado a integração com a API da Iugu, foram adicionado alguns endpoints, e outros procedimentos internos, para determinadas ações tomadas dentro da nuvem, ou porque algum dado recebido de qualquer outro dispositivo autorizado.

Em paralelo também foi iniciado o desenvolvimento do painel gerenciador do Hubee onde, através de camada de acesso, o prestador de serviço também conseguirá acessar seus pedidos e extratos, obviamente que além do acesso master, onde é controlado todos os usuários, dispositivos, prestadores de serviços e as configurações gerais.

Semana 8 – 30 a 06 de Outubro:

Desenvolvimento do primeiro node, dispositivo que se comunicará com o gateway informando os dados lidos por um sensor de carga. Foi necessário incluir um módulo de leitura de resistência desconhecida, criando uma ponte Wheatstone para a leitura dos dois valores analógicos de comparação, para enfim ter o peso real em gramas.
Para que cada node não demande uma tomada, e mais um regulador de tensão, foi definido a utilização de uma bateria alcalina de 9 Volts, sendo a tensão máxima permitida na placa microcontroladora utilizada no node.
Algumas outras formas de alimentar a placa está descrita neste link.
O software padrão do node já foi implementado e já pode ser transferido para cada node que for produzido, alterando apenas informações únicas do hardware que ficarão armazenadas na EEPROM da placa. Com isso, o firmware poderá ser atualizado sempre que necessário, sem perder as informações de fábrica do dispositivo físico.
A comunicação pelo protocolo MQTT também foi validada entre os dispositivos, fechando a comunicação client (node) e broker (gateway).

Semana 9 – 07 a 13 de Outubro:

Houve a necessidade ed fazer algumas correções e incluir novos endpoints na API. Estes que foram adicionados, não haviam sido definidos no início e surgiram por pequenas alterações e correções no escopo inicial.

Desenvolvimento do segundo node, que realizará a leitura de um sensor de pressão de gás e informará o gateway, e subsequentemente a todas as frentes, quando houver alguma variação de valor em Kpa. Houve dificuldades em extrair os dados medidos pelo sensor, realizando multiplexagem para os múltiplos dados analógicos, utilizando extensor analógico e outras. Em estudo, constatamos que o sensor pode ser tratado, porque na verdade é, como uma ponte Wheatstone. Portanto, foi decidido utilizar o mesmo módulo de amplificação do primeiro node desenvolvido, sem a necessidade de completar a ponte, já que o sensor já possuía um pino dedicado ao valor de mínimo e outro pino para o valor de máximo. Com isso foi possível realizar a medição do sensor de pressão, calibrando a constante de calculo para se chegar ao valor mais preciso.

Foram feitos todos os desenhos técnicos 2 e 3D para a impressão dos cases do gateway e dos dois nodes:

Estudo e definição de antenas externas para serem utilizadas com a Dragonboard 410C. Após contato com alguns fornecedores, a SmartCore decide apoiar o projeto Hubee, liberando para testes do protótipo duas antena LTE, uma antena ativa GPS e conectores uFL para serem soldadas na Dragonboard 410C. Para o switch de antena interna para externa e a instrução de mudanças de componentes, seguiu-se este documento disponibilizado pela Qualcomm.


Semana 7 – 14 a 20 de Outubro:

Após fazer muitas cotações para os cases do gateway e dos dispositivos, por injeção ou impresso 3D, decidimos fazer a impressão 3D, já que para cada case o investimento de injeção era muito alto. Para isso, entramos em contato com alguns prestadores de serviço de impressão 3D, até que chegamos ao FabLab Livre, da prefeitura de São Paulo. Em conversa e apresentando o projeto para algumas unidades da cidade, para verificar possibilidade e disponibilidade, a unidade do Parque Jockey abriu uma exceção na agenda para apoiar o projeto, disponibilizando suas impressoras para materializarmos nossos cases.

Foram confeccionados também as etiquetas de identificação dos equipamentos (gateway e nodes), fornecidas em apoio ao projeto pela prestadora de serviços de serigráfica Rabisko SP.

Iniciamos a montagem dos nodes já com todos os seus componentes finais. Algumas adaptações tiveram que ser feitas nos cases, por inclusão de alguns componentes após a impressão dos cases, como as braçadeiras de metal que fazem a vedação da mangueira de gás, ou a inclusão do módulo de aplicação para a leitura do sensor de pressão. Nada que altere a vista do produto acabado após o fechamento do case.

Os conectores uFL foram soldados na Dragonboard, seguindo o documento de instrução da Qualcomm, tornando possível fecharmos o case do gateway, sem problemas com os sinais de GPS, GSM e Wireless.

Semana 8 – 21 a 28 de Outubro

Esta última semana foi destinada para realização dos testes finais e passando todas as frentes por QAs minuciosos, para termos uma versão mínima e estável para a entrega. Havia uma vaga possibilidade de termos tempo para produzir um terceiro node, este serviria para um acionamento de serviços definidos como favoritos através de um encoder rotativo, para realizar a seleção e a requisição do serviço. Infelizmente todos os cálculos de esforços excediam o deadline do concurso, por isso optamos em desenvolver este e outros dispositivos no momento pós entrega do concurso.

Tanto o gateway quanto os nodes foram devidamente montados, porém com um problema de percurso, a montagem final foi adiada até a compra de numa nova placa controladora para o node 2, que foi queimada durante os testes. Então não houve o finalização oficial dos cases, deixando a limpeza e inclusão da etiqueta identificadora para o momento certo.

A placa controladora foi substituída e agora os cases ficaram prontos para serem finalizados.

Esta semana tivemos que dedicar um tempo extra para a apresentação do projeto, criar o artigo no Instructables, formatar este post, para incluir as imagens finais e videos de entrega do projeto.

Numa última reunião antes da entrega, foi levantado todo o backlog a ser ‘splitado’ em tarefas, para o momento pós entrega, deixando uma direção para que o projeto Hubee siga em desenvolvimento e evolução.

ENTREGA

GATEWAY + DISPOSITIVOS

VÍDEO

INSTRUCTABLES

Hardware:

Gateway

Dragonboard 410C
Regulador de tensão StepDown
Antena LTE
Antena GPS interna
Módulo de comunicação GSM
Componentes eletrônicos gerais

Node 1

NodeMCU ESP8266-12 0.9
Módulo amplificador
Bateria 9 Volts
Sensor de pressão de gás
Componentes eletrônicos gerais

Node2

NodeMCU ESP8266-12 0.9
Módulo conversor de ponte Wheatstone
Bateria 9 Volts
Célula de carga até 50Kg
Componentes eletrônicos gerais

Software/Firmware:

Gateway

Linaro 17.04.01
Python 3.7.1
Mosquitto 3.1.1

Node

C++ 8.2

Cloud

Ubuntu 18.04
Prisma 0.1.0
Python 3.7.1
MongoDb 4.0

Manager

NodeJS 8.12.0
Express 4.16.0
Bootstrap 4.1.3

App

Xamarin Forms 3.3.0
C# 7.3

Site

WordPress 4.9.8

Referências:

 

 

 

 

 

APOIO AO PROJETO HUBEE