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