ade E18-D80NK. Esse design poderá ser utilizado como referência para seu Sistema atual e suas futuras implementações com o E18-D80NK, e inclusive com outros sensores com comportamento similar (e não precisa necessariamente ser de proximidade).
O ponto mais importante é definir três parâmetros no código, relacionados ao tempo que cada peça (objeto) fica "na frente" do sensor. Renan, conforme as informações que vc passou, mais à frente no texto eu mostro como podem ser especificados os três parâmetros de forma a atender seu Sistema.
Mas não deixe de ler todo o texto, pois há considerações importantes nele.
Sobre o uso do módulo Relé, aconselho a leitura de um tópico aqui no LDG, onde esclareço alguns pontos importantes sobre isolação e o controle desses módulos. É este aqui: "Módulo Relé sem JD-VCC"
Sobre o uso de um Teclado Matricial, faço algumas observações no final do post.
Inicialmente, gostaria de esclarecer melhor a topologia que sugeri no post inicial, a fim de minimizar falhas na detecção usando o Sensor de Proximidade. Para isto, apenas reformulei o desenho da topologia evidenciando como ela é implementada, mostrando o cabo de conexão entre o Sensor e o Arduino. Isto pode ser visto na figura a seguir:
(clique na figura para "zoom")
Aqui o ponto a ressaltar, é que a alimentação de 5V é enviada até o Sensor pela extensão do cabo. Assim, na extremidade do cabo conectada ao Sensor de Proximidade, há a filtragem da alimentação (na área em "verde claro" na figura anterior). Isto é implementado com R7, C5, e C6. As considerações sobre estes componentes (valores e tipo) são as mesmas que já ressaltei no post inicial, e são fundamentais (naquele post há também considerações sobre outros componentes usados no circuito da Interface/Driver que estão na área em "azul claro" na figura anterior).
Não sei qual a extensão do cabo que está sendo usado entre o Sensor e o Wemos. Mas caso esta extensão seja de 10 metros ou mais (até mesmo 50 metros), aconselho usar uma implementação com Módulos RS-485. Estes módulos tem baixo custo e são facilmente encontrados no mercado (basta pesquisar por "modulo rs485" no famoso site de compras "ML"). O uso destes módulos aumenta tremendamente a imunidade a ruídos, pois eles trabalham com Drivers Diferenciais em "loop de corrente". Assim para o caso em questão, dois módulos são necessários: na ponta do lado do Sensor um módulo seria configurado como "transmissor", e na outra ponta no lado do Arduino o outro módulo é configurado como "receptor". Esta configuração é apenas no Hardware, ou seja, apenas com as ligações adequadas (no código nada precisa ser feito). Na figura a seguir mostro essa implementação:
(clique na figura para "zoom")
Observar, que a alimentação ainda está sendo enviada pela extensão do cabo, e por isso há o mesmo circuito de filtragem mostrado anteriormente (agora de uma forma mais "realística" com a imagem dos componentes). Para o cabo, uma boa opção é usar cabo de rede "CAT5", devido à grande disponibilidade no mercado e ao seu baixo custo. Neste caso, observar que para a transmissão do sinal do Sensor, devem ser usados dois fios que constituem um "par-trançado", mostrados na figura como um fio de cor "verde" e "verde-branco". Observar também as ligações desse "par-trançado" aos módulos RS-485: note que o sinal "A" de um módulo vai ao sinal "A" do outro, o mesmo se aplicando para o sinal "B".
Nesta configuração "A <==> A" e "B <==> B", a lógica de acionamento do Sensor de Proximidade é mantida, ou seja, quando um objeto é detectado e o sinal de saída do Sensor vai a "LOW", isto também ocorre no sinal que chega ao pino do Arduino. Caso se deseje inverter esta lógica (ou seja, para que quando acionado o Sensor o sinal no pino do Arduino seja "HIGH"), basta trocar a ligação do "par-trançado" fazendo "A <==> B" e "B <==> A".
Notar que as ligações aos módulos RS-485 são muito simples, mas devem ser feitas com atenção para evitar erros. Para a alimentação, na figura é mostrado o uso dos fios de cor "laranja" (para o 5V) e "marrom" (para o GND) do cabo "CAT5", mas pode-se usar qualquer outro "par-trançado" disponível no cabo (com isso aumenta-se a imunidade a ruídos na alimentação, principalmente no lado do próprio Arduino), apenas tomando-se o cuidado para não trocar 5V com GND em cada ponta do cabo.
O Resistor do Filtro da Alimentação no lado do Sensor, foi reduzido para 10 Ω, pois o uso está previsto para cabos com grandes extensões.
No lado do Arduino, o Driver com Transistor que havia antes, foi substituído pelo Módulo RS-485 "receptor". Na saída desse módulo (o sinal "RO"), apenas um simples Filtro de Sinal é necessário, composto de dois Resistores e um Capacitor. Este filtro é o mesmo usado no post inicial. Mas neste caso, aumentei para 1 kΩ o Resistor que vai ao pino de Entrada Digital do Arduino, e com isso eliminei o Diodo "BAT85" que havia anteriormente, simplificando o circuito. Dessa forma, o mesmo circuito pode ser usado tanto para o Arduino convencional a 5V (UNO, Mega, etc), como para Arduinos com Processador alimentado a 3.3V (como ESP8266, ESP32, Due, STM32, etc). Importante: o Capacitor do Filtro de Sinal deve ser obrigatoriamente do tipo "Cerâmico".
Qualquer dúvida sobre esta Implementação com Módulos RS-485, não deixe de perguntar.
Como de costume, quando possível implemento também uma simulação, o que permite que aqueles que não tem o Hardware em mãos, possam testar, fazer experimentações, e aprender com isso. O arquivo para simulação no Proteus está anexado no final do post.
Mas como no Proteus não há modelo para o ESP8266, fiz a simulação usando um Arduino UNO, mas o código foi escrito de forma que possa ser também usado no ESP8266 e em outros Arduinos.
Para a simulação, utilizei o mesmo circuito com Driver a Transistor que publiquei no post inicial. Já para o Sensor de Proximidade E18-D80NK, utilizei um circuito que gera de forma cíclica o sinal de objeto detectado. Conectei o Display LCD 20x4 usando a interface paralela, devido à grande lentidão da simulação da Interface I2C (no final do post falo mais sobre isso). Por isso, no código é possível selecionar qual a Interface será usada com o LCD (paralela ou I2C), sendo esta seleção muito simples (mostro mais adiante). O circuito usado na simulação é mostrado na figura a seguir:
(clique na figura para "zoom")
Na simulação (e no código), algumas informações são "printadas" na Serial do Arduino, e portanto podem ser vistas no Terminal do Arduino no PC. Caso isso não seja desejado, basta comentar as linhas no código referentes a esta "printagem" (o que será mais fácil de fazer no "loop" do Arduino, como pode ser notado mais no final do post).
Notar que a saída do circuito equivalente ao Sensor, é do tipo "Open Collector" (via Transistor "Q50"), pois o sensor real E18-D80NK tem uma saída deste tipo.
E junto ao circuito equivalente ao Sensor de Proximidade, há um contador (o "COUNT1"), o qual conta todos os pulsos ali gerados. Isto nos permite comparar o valor mostrado nesse Contador, com o valor de contagem de objetos mostrado no Display LCD. Neste circuito do Sensor, há também a chave "SW1", que atua como se fosse um "liga/desliga" da esteira que transporta os objetos (ou "peças") a serem contados. Uma coisa a lembrar, é que quando o Sistema inicia (após ser ligado ou após um Reset), uma mensagem inicial é exibida no LCD por 2 segundos, e se a chave "SW1" já estiver fechada, o contador "COUNT1" iniciará a contagem antes do código executando no Arduino, sendo isso algo equivalente a ligar a esteira 2 segundos antes do Arduino iniciar a contagem de objetos.
Há também um circuito para "emular" uma interferência (ou perturbação) no sinal do Sensor de Proximidade. Neste circuito, ao pressionarmos o Botão de nome "Interferência", será gerada uma forte perturbação no sinal do Sensor, o que nos permite verificar a imunidade do Sistema, já que a perturbação não afeta o contador "COUNT1" (então por comparação podemos verificar visualmente a integridade da contagem no Arduino).
A figura a seguir, mostra o resultado da simulação após cerca de 1 minuto dela ter sido iniciada (fechei a chave "SW1" logo que a mensagem "iniciou o Monitoramento!" apareceu no Terminal do Arduino):
(clique na figura para "zoom")
No Osciloscópio virtual, podemos ver dois sinais: em "amarelo" é o sinal de saída do Sensor de Proximidade, e em "azul" o sinal na saída do circuito Driver+Filtro que vai ao pino de Entrada Digital "3" do UNO. Notar que estes sinais são complementares (conforme já dito no post inicial que fiz neste tópico).
Pelos sinais no Osciloscópio virtual, é possível ver que cada objeto fica "na frente" do Sensor por cerca de 100 ms (0,1 segundo). E a taxa de objetos (ou seja, a velocidade que os objetos passam na frente do Sensor), está em 1 objeto por segundo. Na simulação, estas duas características estão definidas no gerador de sinal usado no circuito que equivale ao Sensor (sendo possível alterar as mesmas nas propriedades desse gerador). Conforme explico mais adiante, o conhecimento do tempo mínimo que os objetos ficam "na frente" do sensor, e o conhecimento da taxa máxima de objetos por segundo, é fundamental para o funcionamento correto do mecanismo que permite aumentar a imunidade da detecção dos objetos em relação a perturbações no sinal do Sensor.
Alguns segundos após a captura do resultado da simulação mostrado na figura anterior, acionei repetidas vezes o Botão de "Interferência", para gerar uma perturbação no sinal do Sensor de Proximidade. O resultado disso pode ser visto na figura a seguir, notadamente no Osciloscópio virtual:
(clique na figura para "zoom")
Dois pontos chamam a atenção na figura. Primeiro, a contagem no LCD continua igual à contagem mostrada no contador "COUNT1", mostrando que nenhuma contagem deixou de ser computada. Segundo, o sinal do Sensor em "amarelo" no Osciloscópio, mostra as interferências geradas, enquanto que em "azul" o sinal presente na Entrada Digital do Arduino tem alguns mínimos ruídos mas mantém o "shape" característico do sinal original. O "grosso" da perturbação foi removido pelo Filtro de Sinal composto por R5 e C4 no circuito. No entanto, mesmo que ruídos de grande amplitude ainda estivessem presentes no sinal "azul", ainda assim o código conseguiria ignorá-los, devido ao mecanismo implementado para identificar o sinal de detecção de objetos vindo do Sensor de Proximidade. Uma forma de comprovar isso, é remover o Filtro de Sinal (curto-circuitar R5 e desconectar C4) e abrir a chave "SW1", e então acionar o Botão "Interferência" de forma intermitente ou contínua, e verificar que nenhum objeto é contado. Claro que eu fiz isso e comprovei, mas ao invés de postar uma figura mostrando isso aqui, acho interessante que cada um faça a experiência.
Agora falando sobre o código. As funções implementadas são extremamente simples (se vc achar que não, pode ter certeza: sua visão e seus pensamentos estão te enganando), e praticamente não há muito o que dizer sobre elas. O código também está documentado com comentários funcionais, e qualquer um que entenda um mínimo de programação (mas entenda mesmo, sem enganação que alguns insistem em praticar) irá também entender o funcionamento com relativa facilidade.
Assim inicio a seguir, a descrição das configurações mais significativas das funcionalidades no código.
A figura a seguir, mostra a especificação do pino do Arduino a ser usado para a leitura do sinal do Sensor de Proximidade, e que portanto será configurado como uma Entrada Digital:
(clique na figura para "zoom")
Na simulação foi usado um Arduino UNO, e o pino usado está definido como sendo o "3". Mas qualquer outro pino disponível pode ser usado. Mas é melhor evitar pinos usados para a Serial "padrão" do Arduino, pelos motivos que apresentei em post anterior neste tópico. E pinos usados para o "LED_BUILTIN" (no UNO é o pino "13"), também devem ser evitados, uma vez que no "boot" são configurados como saídas digitais (mas esse problema pode ser desconsiderado se no pino for usado o circuito com Filtro de Sinal mostrado anteriormente).
Também é preciso especificar qual o Nível Lógico presente no pino, quando um objeto é detectado pelo Sensor. Quando um objeto está "na frente" do Sensor E18-D80NK, o Nível Lógico presente na saída deste é "LOW". Mas observar que estamos falando do Nível Lógico presente no pino do Arduino, e portanto o Nível a ser especificado no código irá depender dos circuitos existentes entre a saída do Sensor e o pino do Arduino. No caso do circuito com Driver+Filtro mostrado na área em "azul claro" da primeira figura neste post (e também usado na simulação), o Nível Lógico será "HIGH" pois o circuito do Driver inverte o sinal vindo do Sensor, e esta especificação pode ser vista na figura a seguir:
(clique na figura para "zoom")
Caso seja usado o circuito mostrado no início do post com módulos RS-485, então o Nível Lógico a ser especificado é "LOW", pois aquele circuito não inverte o sinal vindo do Sensor. E claro: se o sinal do Sensor for conectado diretamente ao pino do Arduino, o Nível Lógico a ser especificado também será "LOW".
Ainda sobre o pino usado para a leitura do Sensor, este pino só deve ser configurado como "Pullup" se o Sensor estiver conectado diretamente ao respectivo pino do Arduino. E como a saída do Sensor é do tipo "Open Collector", mesmo que em alguns Processadores (ESP8266, ESP32, etc) exista a opção de ligar um "Pulldown", isto não tem sentido.e não deve ser feito.
Mas se forem ligados os circuitos mostrados anteriormente neste post, que terminam com o Filtro de Sinal, então o pino deve ser configurado obrigatoriamente com "INPUT". Isto porque um Resistor de Pullup "pendurado" ali, irá alterar o funcionamento do Filtro, principalmente em termos da tensão presente no pino, o que impossibilitará detectar corretamente o sinal do Sensor de Proximidade.
Esta configuração pode ser vista na figura a seguir, onde o pino é configurado apenas como "INPUT", uma vez que o Filtro de Sinal está presente no circuito:
(clique na figura para "zoom")
Na figura anterior, é mostrada a função que configura o pino, neste caso como "INPUT", ressaltado na cor "verde claro" na figura. Mas se o Sensor for conectado diretamente ao pino do Arduino, então deve-se mudar a configuração para "INPUT_PULLUP".
Nota: a página do post não comporta o restante do texto, então estou continuando logo a seguir:
…
Adicionado por Elcids Chagas ao 12:35 em 1 dezembro 2020
mosa “luzinha azul”
No mundo do IoT e da automação em geral, é muito comum deparar-nos com controles remotos via celulares utilizando tecnologia BT. Isso é devido a 3 componentes básicos mas muito importantes:
Plataforma de desenvolvimento para Android
Módulos BT baratos e acessíveis (Como por exemplo o HC-06)
E claro, o velho e bom Arduino....
Neste tutorial, vou desenvolver algumas idéias de como controlar as saídas de um Arduíno através de um celular de maneira a mover um Robot, acionar lâmpadas em uma casa, etc.
No mercado é comum encontrar módulos de BT 3.0 “Master-Slave” como o HC-05 e “Slaves” como o HC-06. Já mais recentemente, apareceram os HC-08 e HC-10 que trabalham com tecnologia BT 4.0 ou BLE (“Bluetooth Low Energy”). Os módulos BLE são os únicos que podem ser conectados a um Iphone, pois infelizmente a Apple não fornece suporte a ao BT 3.0.
Para os projetos discutidos aqui, usarei um HC-06 que é bem popular e barato (Bye, bye, Iphone, vamos de Android!). O Módulo é alimentado com 5V o que faz com que ele seja facilmente conectado a um Arduino UNO por exemplo, para receber e transmitir informações a outros dispositivos como um PC ou um telefone celular. Seus pinos de transmissão e recepção podem ser conectados diretamente ao UNO, não havendo a necessidade de se utilizar divisores de tensão como vimos no caso do ESP8266.
Na prática, o HC-06 deve ser ligado diretamente aos pinos 0 e 1 do Arduino (Serial):
HC06-Tx ao Arduino pin 0 (Rx)
HC06-Rx ao Arduino pin 1 (Tx)
Ao se usar a entrada serial por HW do UNO é muito importante lembrar-se que o HC-06 não pode estar fisicamente conectado aos pinos 0 e 1 durante a carga do programa, isso porque o USB também usa essa mesma serial. Uma maneira simples de se contornar esse probleminha (se seu projeto não utiliza muitos GPIOs do UNO) é usar uma porta serial por SW através da library SoftwareSerial (a mesma que usamos no caso do ESP8266). Em nosso caso aqui, usaremos os pinos 10 e 11 do UNO (Tx, Rx respectivamente).
O passo seguinte será escrever um codigo bem simples para se poder testar, programar e inicializar o HC-o6:
Para iniciar, incluir a Library Software Serial, definindo a variável “BT” como a nova porta serial.
#include <SoftwareSerial.h> SoftwareSerial BT(10, 11); // RX, TX String command = ""; // Stores response of bluetooth device
void setup() { Serial.begin(9600); Serial.println("Type AT commands!"); BT.begin(9600); // HC-06 usually default baud-rate }
Em seguida vem o corpo principal do código que simplesmente espera por dados vindos do BT e uma vez que eles chegem, os mesmos são escritos no Serial Monitor. Da mesma maneira, se podem enviar comandos AT desde o monitor serial até o módulo HC-06.
void loop() { if (BT.available()) // Read device output if available. { while(BT.available()) // While there is more to be read, keep reading. { delay(10); //Delay added to make thing stable char c = BT.read(); //Conduct a serial read command += c; //build the string. } Serial.println(command); command = ""; // No repeats } if (Serial.available()) { delay(10); // The DELAY! ********** VERY IMPORTANT ******* BT.write(Serial.read()); } }
Uma vez carregado o programa, faça alguns testes básicos. Por exemplo:,
Envie “AT“, o módulo deverá responder “OK“.
Pergunte a versão do Firmware: “AT+VERSION”, o módulo deverá responser, por exemplo: “linvorV1.8“.
Com o HC-06 é possível definir um nome para o módulo por exemplo: “AT+NAMEMJRoBot_BT_HC06“. Mas diferente de outros módulos, voce não conseguirá saber qual é o nome que está definido para o módulo. Ao se enviar o comando anterior, o HC-06 responderá simplesmente: “OKsetname”.
Em geral, o HC-o6 vem de fábrica com o password (ou PIN): 1234. Voce poderá definir um novo com o comando AT: AT+PINxxxx onde ‘xxxx‘ serão 4 números.
OK! Módulo conectado ao UNO e funcionando. Hora de lançar mão do velho e bom celular Android!!!
Existem muitas apps na loja da Google que podem ser utilizadas. Vou sugerir duas delas, por serem as que usarei em meus tutoriais. Essas apps foram desenvolvidas por mim utilizando o MIT Application2 tool (ver projeto aqui) e estão disponíveis sem custo na loja da Google:
MJRoBoT II BT Control
MJRoBot BT Digital Analog Voice Control
O App MJR0Bot II foi desenvolvido para comandar Robots. Ele basicamente envia um caracter para cada comando de direção, modos AUTO/MANUAL, velocidade + e velocidade-. Alem de permitir o envio de mensagens em modo texto.
O App. MJRoBot Digital Analog Voice Control, envia comandos para acionamento digitais (ligar/desligar) tanto por botões como por voz e comandos numéricos para controle de PWMs (0-255).
Faça o Download de qualquer uma das duas Apps, vá ao set-up do celular e procure o modulo BT fazendo a conexão (entre com o PIN 1234 ou algum outro definido por você). Isso deverá ser feito uma única vez, pois o celular guardará os dados de conexão. Uma vez que o celular e o HC-06 estão conversando, é só usar as APPs.
A partir da segunda vez, ao lançar-se a app, o modulo BT estará desconectado.
Acione o botão de BT, para que o app informe dos modulos disponíveis:
Selecione o nome do módulo (No caso é esse com o HC-06 ao final).
O App então mostrará “CONNECTED”, informando que está “pared” com o HC-06
A partir daí, é só ir acionando os botões do APP e observar no Monitor Serial, o que é que o APP está enviando.
Por exemplo, acionando “ON” e “OFF” sequencialmente para os 4 devices, no caso da APP MJRoBot Digital Analog Voice Control, o resultado seria:
dev1on dev1off dev2on dev2off dev3on dev3off dev4on dev4off
Agora que já temos um App para o Android e sabemos como funciona um modulo BT, vamos colocar a mão na massa e criar algo de util!
Controlando as saídas do Arduino.
Vamos construir o circuito abaixo:
A idéia será usar o App MJRoBot Digi/Ana/Voice Ctrl para acender e apagar os LEDS e também controlar a intensidade dos mesmos usando PWM.
Estaremos relacionando:
Device 1: "dev1on/dev1off" ==> LED Red ==> Pin 3 do UNO
Device 2: "dev2on/dev2off" ==> LED Yellow ==> Pin 5 do UNO
Device 3: "dev3on/dev3off" ==> LED Green==> Pin 6 do UNO
Device 4: "dev4on/dev4off" ==> LED Blue==> Pin 9 do UNO
Ou seja, ao acionar o botão “ON” relacionado ao “Device 1”, a mensagem de texto “dev1on”será enviada ao Arduino. Ao receber essa mensagem, o LED vermelho deverá acender e assim por diante.
Observe que os 4 pinos são pinos com capacidade de gerar PWM. Isso é importante para a utilização dos “sliders” da App, que enviarão valores para controlar a intensidade dos LEDs via PWM:
Dev A0: "r/ 0-255" ==> LED Red ==> Pin 3 do UNO
Dev A1: "y/ 0-255" ==> LED Yellow ==> Pin 5 do UNO
Dev A2: "g/ 0-255" ==> LED Green==> Pin 6 do UNO
Dev A3: "b/ 0-255" ==> LED Blue==> Pin 9do UNO
No caso dos controles deslizantes (“sliders”), antes dos valores para controle do PWM (0 a 255), um caracter será enviado para que o Arduino saiba de que “slider” estará chegando o comando.
O Código:
Setup inicial:
#include <SoftwareSerial.h>
SoftwareSerial BT(10, 11); //TX, RX respectively String device;
const int dev1 = 3; //PWM const int dev2 = 5; //PWM const int dev3 = 6; //PWM const int dev4 = 9; //PWM
void setup() { BT.begin(9600); Serial.begin(9600);
pinMode(dev1, OUTPUT); pinMode(dev2, OUTPUT); pinMode(dev3, OUTPUT); pinMode(dev4, OUTPUT); }
Podemos dividir a parte principal do programa em 4 blocos:
Espera dos comandos BT e construção da variável “device”
Acionamento dos LEDS a partir dos botões
Acionamento dos LEDS a partir de comandos de voz
Controle do intensidade dos LEDs via Sliders
void loop() { while (BT.available()) //Check if there is an available byte to read { delay(10); //Delay added to make thing stable char c = BT.read(); //Conduct a serial read device += c; //build the string. } if (device.length() > 0) { Serial.println(device); // Button control: if (device == "dev1on") {digitalWrite(dev1, HIGH);} else if (device == "dev1off") {digitalWrite(dev1, LOW);} else if (device == "dev2on") {digitalWrite(dev2, HIGH);} else if (device == "dev2off") {digitalWrite(dev2, LOW);} else if (device == "dev3on") {digitalWrite(dev3, HIGH);} else if (device == "dev3off") {digitalWrite(dev3, LOW);} else if (device == "dev4on") {digitalWrite(dev4, HIGH);} else if (device == "dev4off") {digitalWrite(dev4, LOW);}
// Voice control: else if (device == "ligar um" || device == "Ligar 1") {digitalWrite(dev1, HIGH);} else if (device == "desligar um" || device == "desligar 1") {digitalWrite(dev1, LOW);} else if (device == "ligar som" || device == "Ligar som") {digitalWrite(dev2, HIGH);} else if (device == "desligar som" || device == "Desligar som") {digitalWrite(dev2, LOW);} else if (device == "ligar TV" || device == "Ligar TV") {digitalWrite(dev3, HIGH);} else if (device == "desligar TV" || device == "Desligar TV") {digitalWrite(dev3, LOW);} else if (device == "ligar quarto" || device == "Ligar quarto") {digitalWrite(dev4, HIGH);} else if (device == "desligar quarto" || device == "Desligar quarto") {digitalWrite(dev4, LOW);}
// Slider control: char colour = device[0]; int value = device[2]; Serial.print(" "); Serial.println(value); if ( colour == 'r') { analogWrite(dev1, value); // use value to set PWM for LED brightness } if ( colour == 'y') { analogWrite(dev2, value); // use value to set PWM for LED brightness } if ( colour == 'g') { analogWrite(dev3, value); // use value to set PWM for LED brightness } if ( colour == 'b') { analogWrite(dev4, value); } device=""; //Reset the variable } }
Deixo aqui o link para os códigos usados neste tutorial:
Link para os códigos Arduino
No vídeo abaixo, uma demonstração da porção programa acima (botões & Slider):
Vídeo demo comando por botões e Slider
O controle de dispositivos IoT por voz é uma tendência nos dias de hoje. Conseguir este tipo de controle com o conjunto Arduino/HC-06/Android é extremamente simples. Os dispositivos Android já possuem essa característica “de fábrica”. No App que desenvolvi, apenas acrescentei um botão que faz com que o Android “escute” um comando e o envie em formato texto para o Arduino. O codigo se encarrega de “ler” a string que chega.
Em vermelho, ressalto no código alguns possíveis comandos de voz. Ao receber por “Ligar TV” por exemplo, o LED verde (correspondente ao device 3) acenderá (em vez do LED podíamos ter uma relé que ligaria a TV).
No vídeo abaixo, uma pequena demonstração do controle por voz:
Vídeo demo de comandos por voz.
Bom, acredito que já é possível ver o enorme potencial do controle de “coisas” usando BT/Android/Arduino. Em meus próximos posts estarei desenvolvendo Robots que poderão ser controlados remotamente como vimos aqui.
Para mais tutoriais, demos, vídeos, etc. visite meu blog:
MJRoBot.org
Um abraço e até mais!
…
Adicionado por Marcelo Rovai ao 19:45 em 31 janeiro 2016