Sensor PIR de movimento

Ontem no Automação do Parque uma turma que está fazendo um projeto de automação residencial reapareceu. Uma das demandas que tem o projeto deles é um sensor de presença, para funcionar como um alarme. Aí nos dedicamos a entendê-lo e usá-lo a partir do Raspberry. Como eu também tenho um, resolvi usá-lo também num projeto de MQTT que vou escrever mais tarde.

O sensor de presença mais barato e comum é o PIR (Passive InfraRed), ou sensor passivo baseado em infravermelho. O sensor propriamente dito é esse aí:



Dois pinos para alimentação e um para o sinal.

Para usar em projetos normalmente se usa um dispositivo "inteligente", que já vem com um amplificador de sinal e também permite ajuste da sensibilidade e da latência (o que possibilita o sistema parar de dar alarme depois de um tempo se o movimento continua. Fica assim:



Foi um esses daí que a gente usou ontem na brincadeira, e também é muito semelhante ao que eu tenho.

Essa parte branca de plástico é uma lente colocada sobre o sensor da primeira foto, de modo a amplificar o "sinal" (no caso, o calor do corpo) e também aumentar o ângulo de percepção do sensor.

Para aqueles versados no idioma de Sir Mick Jagger aqui tem uma descrição bastante detalhada e interessante sobre o bicho. Aqui, as usual, o negócio é por prá rodar, então vamolá.

Para testar o bicho, primeiro liguei no Arduino. Como sou mais familiar com o bicho e ele é danado de simples e robusto, além de custar muito menos e ser mais fácil de encontrar que o RPi, toda vez que vou testar um sensor novo prefiro usar o Arduino. Depois que funciona aí levo prá outra plataforma.

Acima o circuito como ligado no RPi. Usa-se um resistor de 10k como pull-up. Para entender o papel desse resistor é só clicar.

Para testar no Arduino o circuito é o mesmo só que conecta-se o fio amarelo (saída do sensor) a uma entrada digital do Arduino (dããããã!). Usei o seguinte código:

 i#define pirInput 8  
 void setup()  
 {  
  Serial.begin(9600);  
  pinMode(pirInput,INPUT);  
 }  
 void loop()  
 {  
  int sensor = digitalRead(pirInput);  
  if (sensor == 0)  
  {  
   Serial.println("Movimento");  
  }  
  delay(300);  
 }  

Simples a mais não poder, não?
Basicamente a gente lê o sinal da porta onde está conectado o PIR, no caso a 8 e se for 0 quer dizer que o sensor indica movimento.

Funcionou que foi uma beleza.

No Raspberry Pi

Como sabemos de outros carnavais, o RPi trabalha com 3,3V e o Arduino com 5V. O sensor, segundo me confidenciou o Google, "guenta" de 3 a 5V. Testei no Arduino alimentando o circuito com as duas tensões, e como sói acontecer (ui! essa foi do fundo do baú!) com sensores, ele funcionou melhor com 5V do que com 3V3.

Aí vc pergunta: "Mas e aí, tio, cumé qui faiz? Se a gente plugar ele na porta 5V do RPi não vai dar zica?". Bom... depende. Se a SAÍDA do sensor for mais do que 3V3 a coisa pega, mas vai que a entrada é 5V e a saída é "menas" tensão?

Pelo multímetro vi que, quando o sensor "sente", ou seja, envia sinal de movimento, apesar de estar plugado em 5V a saída é no máximo 3,5. Ou seja, corajoso que sou, tasquei o bicho no 5V e liguei direto na porta. Vc, mais cuidadoso, pode ligar na alimentação 3,3V ou usar um divisor de tensão para abaixar um pouco a tensão de entrada do RPi.

No Pi, em Python:

1:  import RPi.GPIO  
2:  import time  
3:  RPi.GPIO.setmode(RPi.GPIO.BCM)  
4:  RPi.GPIO.setup(24, RPi.GPIO.IN)  
5:  sensor=0  
6:  try:  
7:    while True:  
8:      sensor=RPi.GPIO.input(24)  
9:      if(sensor):  
10:        print "Movimento"  
11:      else:  
12:        print sensor  
13:      time.sleep(1)  
14:
15:  finally:  
16:    print 'Fim'  
17:    RPi.GPIO.cleanup()  

Aqui, na linha 4 a gente define que a porta 24 vai ser de entrada. Na linha 8 a gente lê o valor, se verdadeiro imprime a palavra movimento, semelhante ao que rolou no Arduino.

O que tem de novo é a linha 6 em conjunto com as linhas de 14 em diante. É um recurso que não tem no Arduino, que é o tratamento de exceção. Observe que o programa tem um "loop eterno" (while True, linha 7), ou seja, se a gente deixa rodando ele vai até o Fim dos Tempos. Para parar o bicho dá-se então um Ctrl-C, o que interrompe a aplicação Ptython. Acontece que se a gente faz isso, a porta GPIO fica "pendurada", quer dizer, o Pi fica achando que ela está bloqueada para uso da aplicação que morreu. Ou seja, mesmo que o programa termine com Ctrl-C, temos que rodar a instrução RPi.GPIO.cleanup(), que libera a porta para outro programa que vier atrás, ou esse mesmo executando de novo.

Para isso usa-se o bloco try...finally. O que estiver dentro do bloco try roda de forma "protegida", quer dizer, em caso de erro o programa, em vez do bicho simplesmente abortar a execução, ele executa o bloco definido pelo comando finally. Como o Ctrl-C gera uma condição de erro, o sistema vai sair "elegantemente", liberando a porta para outro uso posterior.

Aqui imagens dos nossos testes no parque:

O sensor exposto...

E aqui ele coberto com a nossa Campânula de Calibração para Sensores PIR (CACASPIR), que impede que o sensor fique sentindo quando a gente não quer.

Abaixo, fotos do Parque ontem. Os meninos à esquerda são alunos de nível médio e estão cá aprendendo Arduino para fazer um trabalho de escola., e os marmanjos à direita estão cuidando da maquete de sua casa domótica.

E por fim, fotos da minha caminhada pela "orla" joseense hoje pela manhã. Para quem não é daqui, São José dos Campos tem o Banhado, que é um ex-banhado ou ex-brejo, já que foi drenado há muito tempo. É uma baixada imensa (uns mil ha) ao lado da praça da matriz (!) que pertence ao município e servirá para algum uso futuro pela cidade. Aqui vc vê a dita, é essa área verde limitada leste pela cidade e a oeste pelo rio Paraíba do Sul.

De longe não parece uma praia?

Bom, e o que isso tem a ver com automação? Nadica, só queria compartilhar com vosotros as belezas matinais joseenses...