Sensores de infravermelhos (PIR)

Os sensores de infravermelhos são úteis em projetos onde a deteção de um obstáculo é importante. Ao contrário dos sensores de ultrassons, que retornam um sinal analógico que permite calcular o valor da distância de um objeto ao sensor, os sensores de infravermelhos (ou PIR - Passive Infrared Sensor) retornam apenas um sinal digital ON / OFF que informa se há ou não um objeto a uma distância pré-definida.

Foram dois os sensores testados: um detetor de obstáculos - módulo para arduino e um HC-SR501. O primeiro, comprei-o por 0,86€ e o segundo por 0,71€ (aqui e aqui).

Relativamente ao princípio de funcionamento, este é idêntico aos dois sensores: cada um deles apresenta um LED emissor de infravermelhos e um receptor de infravermelhos. Os infravermelhos mais não são que radiação térmica, não detetável pelo olho humano. Quando o feixe de infravermelhos emitido pelo LED emissor bate num obstáculo, é refletido e detetado pelo sensor, que transmite essa informação alterando o estado da saída digital.

Os dois sensores testados têm caraterísticas diferentes e adequam-se a diferentes aplicações. Um quadro-resumo apresenta principais caraterísticas e aplicações possíveis:

Segue-se uma apresentação eletrónica com uma proposta de trabalho para explorar o funcionamento de cada um dos sensores referidos:

 

Converter linguagem de blocos em C? Comparámos o Blocklyduino e o mBlock

A programação de arduino por blocos é uma ferramento poderosíssima em termos de democratização da programação de circuitos eletrónicos e como forma de introduzir no mundo da eletrónica crianças (bastante) pequenas. Tem, como é evidente, algumas limitações, o que já referi em post anterior. Foi na altura em que escrevi esse post que tomei contacto com o Bloklyduino.

Entretanto, por sugestão da Casa de Makers, cujo trabalho muito admiro, descarreguei para o meu PC o mBlock e pus-me a experimentar alguns circuitos.

Depois, achei que era boa ideia testar os dois softwares em situações-tipo que nos aparecem em ambiente de aprendizagem e em projetos simples e ver até onde podíamos ir com eles.

Atenção que neste estudo não foi analisada a facilidade com que, em cada um dos programas, são realizados novos blocos - o que pode contornar várias limitações identificadas. A criação de novos blocos será certamente feita em ambientes de aprendizagem mais específicos ou até por quem cria produtos didáticos a serem explorados em ambiente de programação por blocos (não há razão para que o BlocklyDuino não use o SR04 ou para que o mBlock não disponha da função map). Os testes foram feitos assumindo o utilizador comum que descarrega o programa e trabalha com a sua versão base.

Depois de vários testes, descritos e comentados na apresentação eletrónica que fecha este post, as principais conclusões da comparação entre os dois softwares foram as seguintes:

Como conclusão, se a ideia é substituir o S4A criando, em linguagem Scratch, programas para arduino, com a vantagem de tornar o funcionamento do arduino autónomo do PC, o mBlock é sem dúvida a melhor opção - a programação é feita diretamente em Scratch, não havendo preocupações didáticas relativamente à aprendizagem em C. Se a ideia é fazer uma transição entre a linguagem por blocos e a linguagem C para arduino, o BloclyDuino ganha com vantagem pela qualidade do código C que gera; ainda assim, essa transição terá de ser sempre orientada, já que há questões-base no código gerado que devem ser esclarecidas quanto antes, como o caso da inicialização das variáveis dever ser feita na função Setup e não na função Loop.

Finalmente, ao explorar e reconhecer algumas limitações aos softwares referidos, não é minha intenção retirar-lhes o devido valor. Tanto o BlocklyDuino como o mBlock são ferramentas muito úteis e com grande potencial pedagógico. Cabe aos educadores explorá-las e conhecer as suas potencialidades e as suas limitações de forma a aproveitar cada uma delas da melhor maneira.

Deixo uma apresentação eletrónica com os testes realizados e alguns comentários adicionais: