Detector de entupimento de drenagem: 11 etapas (com imagens)

2024 Autor: John Day | [email protected]. Última modificação: 2024-01-30 11:39

Não deixe um ralo entupido atrapalhar você! Voltando de nossas férias, eu e minha esposa ficamos surpresos com a água cobrindo o chão do nosso apartamento, e descobrimos que não é nem água limpa, é ralo por toda parte. Depois de limpar o ralo e limpar o chão, tive a seguinte pergunta: por que não temos um sistema de alarme para possíveis entupimentos do ralo? Drenos entupidos não apenas podem paralisar sua casa, mas consumirão custos adicionais de seus bolsos. $ 206 em média é o custo de limpar um ralo entupido de acordo com o HomeAdvisor, além de custos ocultos de tapetes danificados, móveis de madeira, … etc. Nossa ideia é permitir que proprietários de residências, bem como empresas como departamentos de manutenção de cidades / compostos e prestadores de serviços especializados tenham um sistema eficiente e inteligente que alerte os responsáveis o mais cedo possível para uma ação, o que contribui para o enriquecimento de cidades inteligentes com um importante recurso.

A ideiaEmbora a detecção de obstruções possa ser feita por meio de uma série de técnicas, como o uso de sensores de gás ou mecanismos internos, nossa equipe se concentrou em usar o som como entrada, pois sabemos que bater em um tubo onde ele está aberto é um som diferente do que aconteceu ao ser fechado. De acordo com este conceito simples, se pudermos treinar um modelo com os padrões de som que ocorrem na superfície do tubo durante entupimentos, bem como esses padrões ocorrem em tubos abertos, podemos então aplicar o modelo para detectar proativamente quando um entupimento começa a se compor, e então tocar algumas contas.

Créditos para

• Mohamed Hassan
• Ahmed Emam

Projeto em detalhes3 fases são implementadas neste projeto: Coleta de dados, Aprendizagem e previsão.

Antes de aplicar este sistema na vida real, precisávamos criar um ambiente de simulação forçada, onde temos o cano, água corrente e, de alguma forma, simular o entupimento. Então, nós temos um tubo, uma mangueira de água com fonte de água fazendo isso na banheira, e usando a superfície da banheira para fechar o tubo que representa o entupimento. Neste vídeo, explicamos como construímos o ambiente e como coletamos dados para o treinamento do modelo.

E neste próximo vídeo, mostrando como fizemos os testes do sistema e do modelo, no modo aberto, depois no modo entupimento e de volta ao modo aberto, porém

Então, vamos explorar nossa implementação passo a passo:

Etapa 1: o experimento

Neste cenário, usamos um pequeno cano de água conectado ao nosso hardware e sensor de som. O hardware lê o valor do sensor e o envia de volta para a nuvem. Isso foi feito por 10 minutos para o tubo bloqueado e mais 10 minutos para o tubo que não está bloqueado.

Etapa 2: Hardware

I- Arduino

Para detectar o som da água dentro do cano, precisamos de um sensor de som. No entanto, o Raspberry Pi 3 não tem GPIO analógico. Para lidar com esse problema, usamos o Arduino, pois o Arduino tem GPIO analógico. Assim, conectamos o sensor Grove Sound ao escudo Grove Arduino e conectamos o Shield ao Arduino UNO 3. Em seguida, conectamos o Arduino e o Raspberry usando um cabo USB. Para obter mais informações sobre o sensor Grove Sound, você pode verificar sua folha de dados. Você pode encontrar na planilha de dados um código de amostra de como ler os valores do sensor. O código de amostra está quase sendo usado com pequenas alterações. No código abaixo, conectamos o sensor a A0 na blindagem. Para escrever em série, usamos a função Serial.begin (). Para se comunicar com a taxa de transmissão do Raspberry definida como 115200Os dados serão enviados para o Raspberry se for maior que um determinado limite para cortar o ruído. Muitos testes foram feitos para escolher os valores de limite e atraso desejados. Limiar encontrado em 400 e valor de atraso em 10 milissegundos. O limite foi escolhido para filtrar o ruído normal e garantir que apenas dados significativos sejam enviados para a nuvem. O atraso foi escolhido para garantir que o sensor detectou quaisquer mudanças no som do fluxo dentro do tubo imediatamente.

II- Raspberry Pi 3Para baixar coisas do Android no Raspberry, você pode baixar a versão mais recente do Android Things Console. Neste projeto usamos a versão: OIR1.170720.017. siga os passos no site do Raspberry para instalar o sistema operacional no raspberry, para Windows você pode usar estes passos. Após a instalação, você pode conectar o Raspberry ao seu computador usando USB. Então, no console do seu computador, use o comando abaixo para obter o IP do Raspberry

nmap -sn 192.168.1. *

Depois de obter o IP, conecte-se ao seu Raspberry usando o comando abaixo

adb conectar

Para conectar seu Raspberry ao Wifi (adicione seu SSID e senha)

adb am startservice

-n com.google.wifisetup /. WifiSetupService

-a WifiSetupService. Connect

-e ssid *****

-e senha longa ****

Etapa 3: Google Cloud - Registro

O Google oferece um nível gratuito para todos os usuários por um ano com teto de $ 300, graças ao Google:). Siga as telas para criar um novo projeto no Google Cloud

Etapa 4: Google Cloud - Pub / Sub

O Google Cloud Pub / Sub é um serviço de mensagens em tempo real totalmente gerenciado que permite enviar e receber mensagens entre aplicativos independentes.

Etapa 5: Google Cloud - IOT Core

II- IOT CoreA serviço totalmente gerenciado para conectar, gerenciar e receber dados de maneira fácil e segura de dispositivos globalmente dispersos. IOT Core ainda Beta, para ter acesso a ele você precisa fazer uma solicitação com a Justificativa ao Google. Fizemos o pedido, nossa justificativa foi este concurso. Google aprovado, obrigado ao Google novamente:). O Raspberry enviará dados do sensor ao IOT Core, que encaminhará as leituras para o tópico PubSub criado na etapa anterior

Etapa 6: Google Cloud - Cloud Functions

Cloud Functions é um ambiente sem servidor para criar e conectar serviços em nuvem. O gatilho para esta função é o tópico PubSup criado na etapa 1.;; Esta função será acionada quando o novo valor for escrito no PubSup e gravá-lo no Cloud DataStore com o tipo "SoundValue"

Etapa 7: Google Cloud - Cloud DataStore

O Google Cloud Datastore é um banco de dados de documentos NoSQL criado para escalonamento automático, alto desempenho e facilidade de desenvolvimento de aplicativos. Embora a interface do Cloud Datastore tenha muitos dos mesmos recursos dos bancos de dados tradicionais, como um banco de dados NoSQL, ela difere deles na maneira como descreve os relacionamentos entre os objetos de dados. Não há necessidade de qualquer configuração, uma vez que o Cloud Functions grava os valores do sensor no DataStore, os dados são adicionados ao DataStore

Etapa 8: Google Cloud - BigQuery

Coletamos uma amostra de 10 minutos do tubo normal e 10 minutos do tubo bloqueado, com diferença de exatamente 1 hora entre as 2 iterações. Depois de baixar os dados do DataStore e fazer alguma manipulação para adicionar classificação para cada linha. Agora temos 2 arquivos csv, um para cada categoria. Como prática recomendada, faça upload dos arquivos CSV de dados primeiro para o Cloud Storage. Na tela abaixo, criamos um novo intervalo e carregamos os 2 arquivos CSVs Como esse intervalo será usado apenas para análise, não há necessidade de escolher o intervalo multirregional Em seguida, crie um novo conjunto de dados e uma nova tabela no BigQuery e carregue o arquivo 2 CSVs do intervalo para a nova mesa

Etapa 9: Google Cloud - Data Studio

Em seguida, usamos o Data Studio para extrair alguns insights. O Data Studio lerá os dados da tabela do BigQuery. Nos gráficos, podemos ver a diferença entre 2 categorias em número de telemetrias e soma de valores por minuto. Com base nesses insights, podemos projetar um modelo simples, o tubo é considerado bloqueado se, em 3 minutos sucessivos, a contagem dos valores de telemetria que são superiores ao limite de ruído (400) for superior a 350 telemetrias. e em 3 minutos sucessivos, a contagem do valor de telemetrias que é maior do que o limite de ignição (720) é mais de 10 telemetrias.

Etapa 10: Fase de previsão

Referimo-nos a uma leitura, quando ultrapassa um determinado valor (THRESHOLD_VALUE) que foi definido para 350 que filtra o ruído e reduz o caudal de água no tubo, de ser considerado como uma leitura

A análise dos dados mostrou que no modo aberto o número de leituras é inferior a 100, mas no modo entupir, os valores são muito maiores (atingiram 900 por minuto), mas em casos raros também foram menores do que 100. No entanto, esses casos não se repetem consequentemente, e por três minutos subsequentes, o número total de leituras sempre excedeu 350. Tendo o modo aberto nos mesmos três minutos somará menos de 300, poderíamos colocar esta regra com segurança: Regra nº 1 Por três minutos em uma forma bruta, se forem leituras totais > 350, então um entupimento é detectado. Descobrimos que o valor máximo alcançado no modo aberto não excede um certo valor (SPARK_VALUE), que é 770, então adicionamos esta regra: Regra # 2 Se o valor de leitura for> 350, então um entupimento é detectado principalmente.

A combinação de ambas as regras nos deu uma maneira fácil de implementar a lógica de detecção, conforme mostrado. Observe que o código abaixo foi implantado no Arduino, que avalia as telemetrias recebidas com base em nosso modelo e envia para o raspberry se o tubo estiver entupido ou aberto.

Etapa 11: Código

Todos os códigos para Arduino, Raspberry e Cloud Function podem ser encontrados no Github.

Para mais informações você pode verificar este link