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

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!

Mais importante que ganhar, é ousar tentar!

O nosso clube surgiu há três anos, quando "tomámos de assalto"a aula de informática do 8º ano vocacional (obrigada à professora Filipa Araújo!) usando como material arduinos emprestado pela ANPRI (um obrigada à ANPRI, também!).

Desde então, com recurso a financiamento do Ministério da Educação, a doação de equipamentos por parte de entidades externas à escola, à participação em concursos, temos conseguido um espólio próprio já razoável que nos tem permitido trabalhar com um número considerável de alunos.

No ano passado, conseguimos manter com regularidade, desde janeiro, dois espaços de aprendizagem na nossa escola: O Espaço LEGO (programação de robôs EV3, dedicado a alunos do 7º ano de escolaridade) e o Espaço Programação e Eletrónica (programação de arduinos com S4A, dedicado a alunos do 10º ano de escolaridade).

Este ano, temos dois espaços diferentes, de 90 minutos cada, a que demos o nome Oficina de Programação e Projectos com Arduino (para alunos de 10º ano) e  Projetos de Electrónica e Programação (para aluno do 11º e 12º ano).

O primeiro espaço pretendia ser semelhante ao criado o ano passado para exploração de programação de arduinos com S4A...mas estas coisas raramente correm como o planeado! O grupo é este ano maior, mais heterogéneo, e alguns alunos já se juntaram ao clube com alguns objetivos definidos. O ano iniciou com aulas de programação de arduino em S4A, que foram interrompidas por vários alunos quando surgiu a oportunidade de concorrer ao desafio Astro Pi  - passando esses alunos a utilizar o espaço do clube para desenvolver trabalho em Python e usando os raspebrry pi disponíveis. Já falei deste projeto em post anterior.

Entretanto, os alunos que não se quiseram envolver no desafio Astro Pi, continuaram a explorar a programação de arduinos. Depois de concluídas as sessões que eu tinha previsto para desenvolvimento de trabalho em S4A, tomei conhecimento de um desafio organizado pelo Instituto Politécnico de Setúbal, o ONControl, para o qual esses alunos se mostraram motivados a concorrer. Achei uma boa altura para passar da linguagem gráfica para C e é neste âmbito que está a ser montado e programado o robô low cost, trabalho que pretendo documentar ao longo deste ano letivo.

Já no espaço Projetos de Electrónica e Programação, para além da prática de soldadura de circuitos impressos adquirida através da montagem de um Bot'n Roll A, e respetiva programação, apostámos na participação no concurso Can Sat Portugal 2017.

O projeto CanSat tem sido um desafio enorme e pretendo escrever um pouco sobre o caminho percorrido durante este ano. Para já, a referir que a nossa equipa, a D. João Can, foi selecionada para participar na final nacional na ilha de Santa Maria, nos Açores!

E que tem o título deste post a ver com a enumeração dos desafios fora da escola a que nos propusemos? Bem, o título é na verdade uma espécie de máxima pessoal que repito muitas vezes para mim própria quando me meto nestas andanças.

Quando propomos aos nossos alunos um desafio promovido por uma entidade exterior à escola estamos a dar-lhes horizontes, estamos a aumentar as suas expectativas, estamos a desenvolver nas equipas que concorrem competências que não conseguimos desenvolver devidamente nas aulas convencionais (como a capacidade de realizar um trabalho sem guião, de resolver problemas, gestão de trabalho em equipa, organização de um desafio complexo...), e também a consolidar temas científicos através da reflexão e cruzamento de dados.

Ainda assim, e apesar de todas vantagens, estamos, alunos e professores, a sair da nossa zona de conforto, estamos a expor a nossas fraquezas, estamos a ganhar muito trabalho extra por vezes sem muito retorno evidente...e por isso repito para mim própria a importância do "ousar tentar". Não imponho a mim própria (nem às equipas que acompanho) a necessidade de ganhar. Temos de ser humildes o suficiente para perceber o quanto temos de aprender e de reconhecer que é muito provável que haja quem saiba mais que nós - e por isso, dar o nosso melhor não implica ser o melhor. Mas dar o nosso melhor, "ousar tentar", é já imenso. Dar o nosso melhor implica querer saber, procurar soluções, pedir ajuda, apoiar a equipa - aprender para a vida, portanto. E é já tanto, que merece bem o esforço e a possibilidade de falhar.

O nosso melhor é tudo o que nos pode (e deve) ser pedido. E, nesse espírito, os desafios a que concorremos a nível regional, nacional ou até europeu são de uma enorme riqueza. Votos de bom trabalho para todas as equipas envolvidas no clube deste ano!

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.