Robôs low cost#4 - medindo temperatura e humidade

Nesta série de posts intitulados "Robôs low cost#", tenho vindo a descrever o trabalho realizado ao longo do ano letivo pelo Jorge e pela Alexandra em ambiente de clube de robótica. Os alunos referidos são do 10º ano do curso de Ciências e Tecnologias e não têm no currículo nenhuma disciplina de eletrónica ou programação. Tudo o que foram construindo foi fruto de trabalho extra curricular, pesquisa autónoma, muita carolice. Trabalho que foi feito de forma voluntária e com a consciência que não seria refletido na avaliação das disciplinas do curso. Só por isto, os alunos que se envolvem - com responsabilidade e persistência - neste tipo de projetos merecem o meu respeito e a minha simpatia.

De forma a colmatar este "vazio de reconhecimento", promovi a inscrição por parte dos alunos em projetos dinamizados por entidades exteriores à escola, nem que fosse para criar uma meta e um objetivo para o trabalho desenvolvido.

Foi assim que a Alexandra e o Jorge se inscreveram no ONControl, um desafio lançado pelo Politécnico de Setúbal às escolas secundárias da região com o objetivo de criar protótipos controlados por arduino.

O projeto que a Alexandra e o Jorge idealizaram para concorrer ao desafio foi um robô exploratório preparado para percorrer regiões inóspitas ou inacessíveis enquanto fazia medições do meio ambiente e enviava esses dados para um estação fixa.

Depois de ter o robô a deslocar-se desviando-se de obstáculos, estava na altura de decidir o que medir.

A primeira ideia era medir a taxa de monóxido de carbono no ar, dado o nível de toxicidade deste gás, para além de medir a temperatura e a humidade atmosférica.

O grupo acabou por abrir mão do primeiro objetivo depois de testar o sensor MQ7.

Na verdade, o uso do sensor, ilustrado na figura acima, não revelou dificuldades do ponto de vista da eletrónica, bastando alimentá-lo e ligar a saída (output) a uma entrada analógica do arduino. O problema foi compreender qual a relação entre o valor de saída (compreendido entre 0-1023) e a taxa de monóxido de carbono. A pesquisa realizada em fóruns, apontou para a necessidade de uma calibração a partir de um atamosfera com uma taxa de monóxido de carbono conhecida, algo a que não tínhamos acesso. Para além disso, este sensor aquece bastante, gastando muita energia - os alunos optaram então por evitar a sua utilização.

Para medir a temperatura e a humidade, foi usado o sensor RHT03 (também conhecido por DHT-22), popular por ser um sensor de humidade e temperatura de baixo custo com um único pino que realiza o interface com o arduino. O sensor é calibrado e não necessita de componentes extra para funcionar adequadamente. Com este sensor é possível medir temperaturas entre os -40ºC e os +80ºC (± 0.5ºC). A humidade medida é a humidade relativa, entre 0 e 100% (±2%).

Eis uma imagem do sensor e a respetiva pinagem:

A ligação entre o sensor e o arduino foi realizada através da entrada analógica A0:

A livraria que usámos para recolher dados a partir deste sensor foi a dht.h.

Segue o programa usado para visualizar na porta série os valores obtidos, segundo a segundo, por este sensor:

Robôs low cost#3 - detetando e contornando obstáculos

Para que o robô consiga ter um comportamento "inteligente", detetando e contornando obstáculos, há que dar-lhe a capacidade de "ver" o que o rodeia. São várias as formas de o conseguir - com detetores de infravermelhos, câmaras, sensores de toque...como o nosso kit low cost vinha equipado com um sensor de ultrassons SR04, foi esse o que o alunos usaram.

O SR04 é dos sensores de ultrassons mais comuns para pequenos projetos. Permite a medida de distâncias entre 2 cm e 4 m com um ângulo de sensibilidade de 15º.

Apresenta 4 pinos, dois para a alimentação (Vcc e GND), um para o trigger (o "disparo" de um sinal) e o restante para receber o som refletido (o eco):

As ligações realizadas foram as seguintes:

Assim, ao robô montado na sessão anterior, acrescentámos o sensor de ultrassons de acordo com o seguinte esquema:

Já aqui no blog tínhamos explorado o sensor de ultrassons no âmbito da programação gráfica. Os conceitos associados a este sensor encontram-se neste post, e por isso não nos alongaremos com mais considerações quanto ao princípio de funcionamento de um sensor deste tipo.

A programação deste sensor em C é facilitada com uma série de livrarias disponíveis que evitam a preocupação de enviar, detetar e analisar sinais, disponibilizando uma série de comandos que incluem todos esses passos. Usámos a Ultrasonic.h, e explorámo-la através dos exemplos dados.

De forma a testar o funcionamento do sensor, usámos o programa seguinte que escreve na porta série a distância (em cm) a que um obstáculo é detetado pelo sensor:

Com o sensor a funcionar, houve que adaptar a marcha do robô de acordo com a distância lida pelo sensor. O objetivo era manter o robô a andar em frente caso o obstáculo estivesse a mais de 20 cm e alterar a sua trajetória caso o obstáculo estivesse mais perto que essa distância.

Nesta fase, os primeiros testes revelaram que o controlo da velocidade através das saídas PWM não é suficiente para as baixas velocidades pretendidas. Na verdade, para valores mais baixos registados nas saídas PWM, os motores não tinham força para se moverem. A opção passou por criar períodos de ponto morto de forma a diminuir a velocidade do robô.

Como ilustração, deixamos o aspeto do robô nesta fase...

...e um vídeo com o robô em funcionamento (quando o vídeo foi feito, o robô ainda só parava na presença do obstáculo. Com o programa proposto, perante o obstáculo o robô anda para trás, gira e retoma a marcha):

Robôs low cost#2 - controlo da velocidade

É possível controlar a velocidade do pequeno carrinho que montámos através do driver L298N que controla os motores. Para isso, há que recorrer aos pinos Ativa MA e Ativa MB ligando-os a uma saída PWM do arduino.

A Alexandra e o Jorge tinham já trabalhado com saídas PWM em S4A, pelo que o conceito não era novo para os alunos. Uma semana antes, enviei-lhes por email um post do blog Vida de Silício que descreve de forma clara o controlo de velocidade através do L298N e que deviam estudar em casa.

Ao fazer os primeiros testes com o carrinho, sem controlo de velocidade, foram mantidos os jumpers nos pinos Ativa MA e Ativa MB:

http://blog.vidadesilicio.com.br/arduino/ponte-h-l298n-controle-velocidade-motor/

Com os jumpers conectados, os pinos Ativa MA e Ativa MB estarão a 5V e o carrinho estará, de acordo com a programação, ou parado, ou em andamento com velocidade máxima. Ao ligar esses pinos a uma saída PWM do arduino, o intervalo de tempo em que a saída estará a 5V dependerá do valor indicado na programação através do comando analogWrite().

A sintaxe desse comando é analogWrite(pin, value), sendo pin o número da saída digital PWM do arduino (os indicados com um ~, saídas digitais 3, 5, 6, 9, 10 e 11, para um arduino UNO) e value um valor entre 255 (sempre a 5V) e 0 (sempre a 0V) - valores intermédios correspondem a ondas quadradas cujo tempo em que permanecem a 5V está entre 0% e 100% do período da onda:

https://www.arduino.cc/en/Tutorial/PWM

Embora o arduino não tenha saídas analógicas, as saídas PWM permitem realizar essa função, uma vez que o valor médio da tensão de uma onda quadrada depende do valor do duty cycle.

Na sessão anterior, as experiências foram feitas com a alimentação do arduino feita ainda por cabo, ligando-o ao computador. Para libertar o carrinho do computador, os motores continuaram ligados a uma pilha de 9V e foi reciclada uma bateria de um brinquedo velho para alimentar o arduino:

Durante a sessão do clube, o Jorge e a Alexandra modificaram as ligações realizadas anteriormente e assim: 

 - IN1, IN2, IN3 e IN4 ligadas respetivamente às saídas digitais 2, 4, 6, 7

 - ENA e ENB ligadas respetivamente às saídas PWM: 3, 5

O esquema do circuito é agora o seguinte:

O aspeto atual do carrinho é este:

Um possível programa de teste para controlo da velocidade dos motores...

...e um vídeo de demonstração do carrinho em movimento.

Termino referindo que este post foi concebido já depois da Alexandra e do Jorge terem feito a sua exploração do controlo de velocidade através do driver dos motores. A estratégia foi enviar uma semana antes o link sobre o controlo da velocidade dos motores e deixar os alunos a trabalhar de forma autónoma durante 90 minutos. O meu trabalho foi mesmo só fazer o pequeno vídeo no final da sessão. Muito bem, meninos!

Robôs low cost#1 - uma experiência

Há já algum tempo atrás, comprei um pequeno carrinho por menos de 20€ no Aliexpress e tinha desde então curiosidade em experimentá-lo, mas outras tarefas mais prementes se impunham e o tempo foi passando...até que este ano, em ambiente de clube, o Jorge e a Alexandra, depois de explorar a programação de arduinos em linguagem gráfica, decidiram assumir eles a missão de por o carrinho a funcionar.

O equipamento de maior relevo que podemos encontrar neste kit é: o chassis; 2 rodas; 2 motores DC; caixa de bateria para 4 pilhas; interruptor bipolar simples; 1 sensor shield V5.0 para arduino; 1 arduino UNO R3; 1 servo motor SG90; 1 suporte FPV; 1 driver L298N; 1 sensor de ultra sons HC_SR04. Todo o kit está ilustrado nas imagens seguintes:

O kit completo

 Em termos de literatura de apoio, o kit inclui as instruções de montagem do chassis...e é tudo!

Por isso, a parte fácil é mesmo chegar até aqui:

Chassis do carrinho já montado

Daqui em diante...nada encaixa com nada!!!

A primeira missão foi estudar o driver, montá-lo, ligá-lo ao arduino e programar o arduino de forma a colocar o carrinho a descrever um movimento pré-estabelecido.

O driver L298N, que faz o circuito de potência para controlar os motores, vem inserido numa placa para arduino muito fácil de compreender. É possível encontrar bons tutoriais sobre o funcionamento desta placa. Em termos de pinagem, a imagem seguinte é clara:

http://blog.filipeflop.com/motores-e-servos/motor-dc-arduino-ponte-h-l298n.html

Os conetores Motor A e Motor B devem ser ligados a cada um dos motores do carrinho.

Os pinos AtivaMA e Ativa MB são os pinos responsáveis pelo controlo PWM dos motores A e B, isto é, que permitirão a variação da sua velocidade. Trataremos dessa questão em post posterior. Por defeito, nestes pinos estão dois jumpers que manterão estes pinos a 5V, mantendo a velocidade constante.

O driver disponibiliza um regulador de tensão integrado. Caso estejamos a alimentar o driver no pino 6-35V, e se mantivermos o jumper no pino Ativa 5V, o regulador de tensão disponibiliza uma tensão regulada de 5V no pino 5V. Esta informação é importante porque, neste caso, o pino 5V deve ser usado como um saída (para alimentar outro dispositivo, por exemplo), mas nunca deve ser ligado à saída 5V do arduino, o que o poderia danificar. Se estivermos a controlar motores de 4-5,5V, há que retirar o jumper e ligar um alimentação de 5V ao pino 5V.

O barramento IN1, IN2, IN3 e IN4 é responsável pela rotação de cada um dos motores (IN1 e IN2 - motor A; IN3 e IN4 - motorB).

A forma como o motor A é controlado, que é idêntica à forma de controlo do motor B, é a seguinte:

http://blog.filipeflop.com/motores-e-servos/motor-dc-arduino-ponte-h-l298n.html

Portanto...estamos prontos para a primeira experiência...antes de mais, houve que arrumar o material no chassis. Começámos por usar para o driver dos motores uma bateria reciclada de um carrinho de brincar velho e uma pilha de 9V para o arduino, mas a bateria revelou ter uma duração muito pequena, pelo que, nesta fase, alimentámos o driver com a pilha de 9V e mantivemos o arduino ligado por cabo ao computador. As entradas IN1, IN2, IN3 e IN4 foram ligadas, respetivamente, às saídas digitais 4, 5, 6 e 7 do arduino, tal como ilustrado no esquema seguinte:

As placas e a pilha de 9V foram fixadas com fita adesiva de dupla face. Eis o aspeto final:

Deixamos o programa que fizemos para testar o que aprendemos sobre o driver dos motores...

...um pequeno vídeo com o carrinho em funcionamento...

...e ainda um pequeno registo fotográfico do trabalho realizado pelo grupo:

Nota final: como se pode observar no vídeo, a velocidade do carrinho é sempre constante. O controlo da velocidade através do driver dos motores será explorado em post posterior.