Robôs low cost#6 - finalizando o projeto

Depois de o Jorge e a Alexandra terem:

• estudado o controlo dos motores, compreendendo como fazer variar a velocidade do carrinho;
• conseguido que o carrinho realizasse o contorno de obstáculos recorrendo a um sensor de ultrassons;
• procedido à medida da temperatura e humidade e envio de dados por bluetooth para o computador...

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

• kit com chassis e rodas, motores e driver, sensor de ultrassons, servo motor: 17,22€;
•  Conjunto de cabos de ligação (e vão sobrar imensos!): 2,23€;
• Sensor de temperatura e humidade RHT03 (ou DHT-22): 2,07€;
• Módulo bluetooth para arduino: 2,51€

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...

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

Utilitários

No momento de fazer "saltar" os circuitos da breadboard para um pequeno projeto, há sempre a questão de "e agora os fios?"...bem, é evidente que há realidades e realidades, mas, pelo menos nesta fase, gosto de ver os alunos a por "a mão na massa" e acho preferível um resultado menos perfeito mas que os alunos consigam de facto fazer por eles próprios.

Sendo assim, na altura de passar os circuitos para um pequeno projeto opto por abrir mão de soldaduras por vários motivos: porque só tenho um ferro de soldar; porque não é fácil fazer soldaduras de qualidade, que não se partam; porque não tenho isolante retrátil e cobrir as soldaduras com fita adesiva isolante resulta moroso e o resultado final também não é muito bonito; porque, muito importante, a soldadura acaba por inviabilizar muitas vezes o reaproveitamento do componente...são de facto muitos "porques"...

Assim, como alternativa, uso uns conetores simpáticos que compro na loja de eletrónica cá da terra, a 1,20€ um conjunto de 12 (ao da foto, já falta 1):

Não sei se estarei a procurar bem no Aliexpress, mas o que encontro idêntico por lá são uma molinhas a 1,66€ o lote de 10, que nunca experimentei.

Enfim, os conetores de que falo têm-me resolvido as questões de projeto que surgem, mas vi a coisa complicada no projeto do Dia dos Namorados...eram 16 LED - 32 extremidades a ligar num espaço exíguo e tendo de levar em conta polaridades...Eu, que nos trabalhos manuais sou mesmo muito incompetente, fiquei assim um bocadinho sem fôlego...mas valeu-me o jeitinho das meninas do clube que, com muita paciência e concentração, não só fizeram as ligações todas como cometeram a proeza de conseguir que todos os LED ligassem à primeira tentativa (o que para mim foi uma surpresa e tanto!).

Deixo algumas fotos com "os bastidores" do projeto, não só para  documentar o trabalho mas, especialmente, para gabar a paciência da Beatriz, da Ana e da Fabiana, que não esmoreceram com a morosidade e com a concentração que o trabalho exigia. Parabéns a todas!