sexta-feira, 14 de julho de 2017

Robôs low cost#6 - finalizando o projeto

Depois de o Jorge e a Alexandra terem:
...chegou a hora de integrar todos os componentes no projeto.

A arquitetura final está esquematizada na figura seguinte:


As ligações de cada um dos componentes estão descritas nos posts anteriores e indicadas na seguinte tabela:

Tendo todos os componentes a funcionar, a intenção era apenas juntar os códigos realizados nas etapas anteriores do trabalho. Os alunos depararam-se então com a questão das temporizações - o intervalo de tempo usado para recolher os valores da humidade e temperatura (1 segundo) tornava a verificação da existência de obstáculos demasiado lenta.

A pesquisa levou-os ao conceito de Thread, a capacidade de realizar múltiplas tarefas em paralelo. Na verdade, o arduino não tem esta capacidade. Existem, no entanto, livrarias que permitem "agendar" tarefas para determinados intervalos de tempo. Neste caso, foi usada a livraria Thread.h.

Quanto à programação, houve que conciliar os programas realizados anteriormente com a utilização da livraria Thread.h, o que implicou a inclusão desta livraria e a criação de objetos associados - um objeto moveThread associado ao movimento do robô (incluindo a sua locomoção e a capacidade de se desviar de obstáculos) e um segundo objeto, sensorThread, associado à medida da humidade e temperatura e envio desses dados através de bluetooth para o computador: 


Na função setup() foram incluídas as chamadas das funções moveCar e sensorRead em intervalos de tempo 0s (i.e., a correr ininterruptamente) e 1s, respetivamente (o movimento do robô, sendo contínuo, não necessitaria de ser incluído numa thread - tal foi feito apenas para tornar o programa mais percetível.):

 A função loop() passa a ser apenas a execução de cada uma das duas funções a realizar:

É na função moveCar() que é incluído o código que controla o movimento do robô:


A função sensorRead() inclui o código relacionado com a medida de valores e envio para a porta série:

Os testes realizados revelaram que o movimento do robô apresenta uma ligeira perturbação de segundo a segundo, quase impercetível, fruto da execução da função sensorRead().

A pergunta que se impõe - o robô foi mesmo low cost? Pessoalmente, a minha experiência é que depende do local de compra dos componentes. Como a minha intenção é criar trabalhos que possam ser replicados em ambientes sem muitos recursos, a contenção de custos é uma preocupação. Sempre que posso, recorro ao Aliexpress para adquirir componentes. Consigo valores muito inferiores relativamente às lojas locais a que tenho acesso. Estou a falar de diferenças de mais de 5 vezes o valor do componente no Aliexpress, por exemplo. Com o Aliexpress perde-se, evidentemente, a oportunidade de pedir apoio técnico, sugestões, e, muito importante, faturas em ordem - e há situações em que essas mais valias são de facto fundamentais. Para além disso, recorrendo ao Aliexpress há que contar com 3 a 4 semanas para entrega dos produtos - nunca me aconteceu não ter recebido os componentes em bom estado.

Portanto, mandando vir os componentes pelo Aliexpress, este pequeno robô fica-nos em:
Total = 24,03€. Este valor, que não inclui as pilhas para alimentação do arduino e motores, parece-me razoável para um número significativo de contextos. É certamente muito mais baixo que a maioria das soluções encontradas no mercado para robôs didáticos e tem a enorme vantagem de, sendo um projeto modular, poder crescer com os alunos, com a inclusão de novos componentes e a novas ideias.

E ficou giro? Eu acho que sim, mas sou suspeita...







quarta-feira, 5 de julho de 2017

Robôs low cost#5 - comunicando com o PC por bluetooth

De acordo com o projeto idealizado pela Alexandra e pelo Jorge, o envio dos dados para uma estação fixa era especificação fundamental, já que previa o protótipo de um robô que podia não ser recuperável.

Tendo disponível um módulo bluetooth HC-06, a solução passou por experimentar este modo de comunicação, com a consciência que, apresentando um alcance de 10 metros, esta não seria a solução mais adequada numa situação real de um robô exploratório, onde se imporia uma comunicação via rádio, por exemplo.

A solução bluetooth justificou-se neste trabalho por interesse académico e por razões práticas (por disponibilidade do equipamento).

Eis a imagem de um módulo bluetooth HC-06 e respetiva pinagem:



Caso o módulo disponível seja de 5V, a ligação deste componente ao arduino é bastante simples, bastando seguir as ligações propostas na tabela seguinte:

HC - 06
Arduino
Pino VCC
5V
Pino GND
GND
Pino TX
RX
Pino RX
TX
  
O módulo bluetooth com que os alunos trabalharam, no entanto, trabalha a 3,3V, pelo que houve que usar um divisor de tensão no pino RX para não danificar o componente:



Com um PC equipado com bluetooth, depois do equipamento emparelhado, a comunicação é automática. Para visualisar os dados foi utilizado o programa Tera Term, software gratuito disponibilizado pela empresa LogMeTT, bastando, ao fazer correr esse software, selecionar a abertura de uma porta série via bluetooth:



Depois...é só fazer correr um programa que esteja a escrever dados numa porta série, como o apresentado no post anterior - ao fazê-lo, os valores da temperatura e da humidade aparecerão no ecrã do computador:




Como nota importante, destacamos que, ao fazer o upload de qualquer programa para o arduino, é necessário retirar previamente o módulo bluetooth do circuito.

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:



terça-feira, 4 de julho de 2017

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):