Uma espécie de diário de uma professora que começou por explorar as potencialidades do Scratch na programação de arduinos...e que depois foi experimentando novos caminhos com os seus alunos!
Como já tinha referido em post anterior, foi espontaneamente que os alunos que frequentam o Espaço Programação e Eletrónica (10º ano) sentiram a necessidade de ir além da programação gráfica de arduinos.
Por isso, depois de concluído o projeto da Casa Inteligente, voltámos ao registo de aula mais convencional, com cada um deles num computador, com o arduino , e a seguir as tarefas por mim propostas.
Nesta sessão, explorámos a estrutura de um programa típico em C, os símbolos usados, as funções pinMode, digitalWrite, digitalRead, delay e if. Introduzimos ainda alguns tipos de variáveis e fizemos a comunicação com o computador através de porta série.
Confesso que quando preparei a aula, a achei muito extensa e presumi que não seria possível terminá-la em 90 minutos. Mas não só a terminei, como a terminei 10 minutos antes, como os alunos continuavam frescos e sem sinais de cansaço.
A facilidade com que os alunos responderam a esta introdução foi motivo de reflexão da minha parte. Devo referir:
A montagem de circuitos estava interiorizada das sessões anteriores. Não foi factor com que tivesse de me preocupar;
A arquitetura do arduino era familiar a todos. Noção de digital / analógico / PWM, entrada / saída foi algo que pude referir sem perder tempo em explicações;
Embora a programação em C exija o conhecimento das funções associadas e dos símbolos usados, o background de uma linguagem gráfica deu aos alunos capacidade de perceber de antemão quais as instruções necessárias para que um programa reagisse de determinada maneira (quando introduziram o interruptor, por exemplo, assumiram logo a necessidade de uma variável).
Em conclusão, foi muito positiva para mim a experiência de iniciar a exploração do arduino em linguagem gráfica com os alunos para depois lhes apresentar a linguagem C. É um método que exige mais tempo, é certo, mas o processo de programação é feito de forma mais natural e acessível para a maioria dos nossos jovens.
O Scratch Day é um conjunto de eventos a nível mundial com o intuito de promover a linguagem de programação Scratch. O objetivo é o encontro entre utilizadores Scratch de todas as idades para a partilha de projetos, de conhecimentos e de práticas de aprendizagem.
Este ano, o Scratch Day celebrou-se dia 14 de maio e em Setúbal foi organizado, como em anos anteriores, pelo EduScratch na Escola Superior de Educação de Setúbal. E, como em anos anteriores, foi um dia de partilha e de convívio entre escolas e entre gerações!
De sublinhar que, embora as escolas tenham um papel dominante neste tipo de eventos, porque é nas escolas que se desenvolvem a maioria dos projetos, este é um evento aberto a toda a comunidade. Em Setúbal foram 240 as inscrições, entre professores, alunos, pais e interessados no tema. Uma plateia muito heterogénea e muito rica em termos de experiências e expectativas.
Foi com prazer que representei o Arduino na Escola no Scratch Day com uma apresentação onde partilhei as nossas experiências com arduino e Scratch. E foi um prazer ainda maior conviver com tanta gente com tanto para dar e tanta vontade de fazer mais percorrendo novos caminhos...
Um nota final para o número de meninas presentes no evento. A dar-lhe crédito, o futuro da tecnologia no feminino parece bastante risonho...
Deixo a riqueza do encontro em imagens:
Palestras, concursos de programação, robótica e controlo de drones - foram algumas das atividades em todos puderam participar
O Arduino na Escola representado no Scratch Day - no auditório, com uma partilha do que fazemos com arduino e Scratch, e depois do almoço, com um grupo de meninos muito interessados na simulação de movimento oblíquo
Este projeto arrastou-se mais no tempo do que eu gostaria. Não porque o número de sessões em que os alunos nele trabalharam tenha sido excessivo, mas foram descontinuadas pelas férias das Páscoa, por um feriado e por uma visita de estudo, por isso parecia nunca mais acabar...mas acabou!
Como sempre, neste tipo de trabalhos, surgem problemas com que não contávamos. Neste caso em particular, os estores foram uma dor de cabeça . Depois de papel, de papel vegetal, de tecido, optámos por um tecido tipo o usado em proteções de roupa descartáveis (como as que os pintores usam) a que prendemos chumbos de pesca. Não está ainda perfeito, mas já funciona.
No facebook do projeto temos vindo a partilhar o caminho percorrido ao longo das sessões que este projeto durou. Aqui, faço um apanhado de algumas fotos (porque ver um projeto ganhar forma é para mim o mais gratificante do caminho) e deixo um vídeo com o projeto em funcionamento.
Termino com um louvor aos alunos envolvidos: à Ana Cortes, ao Diogo Mira, ao Diogo Rodrigues, à Fabiana Nascimento e ao Miguel Magrinho. Este projeto é de todos vós.
Sessão 1
Sessão 2
Sessão 3
Sessão 4
Sessão 5
E, para finalizar, um vídeo com o projeto em funcionamento:
No Espaço Programação e Eletrónica, os alunos envolvidos estão já familiarizados com os componentes eletrónicos mais comuns, esquemas elétricos e entradas e saídas do arduino. A programação por blocos começa, para estes alunos, a ser insuficiente e a motivação para iniciar a aprendizagem em C está a nascer espontaneamente.
Antes de passar para o C, no entanto, achei que o grupo devia fazer um último trabalho de projeto programado em linguagem gráfica. As razões para esta minha decisão prendem-se, por um lado, por eu continuar a afirmar a importância da "fabricação" de um produto - quando os circuitos não saem da breadboard, perde-se a oportunidade de pensar "e agora?...como tornar isto real?", perde-se a oportunidade de usar ferramentas, perde-se a oportunidade de ter de cumprir uma tarefa para a qual não há guião; por outro lado, o trabalho de projeto apela ao trabalho de grupo, ao convívio, à cooperação - e como os alunos deste espaço são de turmas diferentes, achei que era mais importante apostar neste tipo de trabalho antes de voltar ao método de trabalho que envolve grupos de dois alunos por computador.
Assim, antes das férias da Páscoa, pedi ideias e foram as meninas do clube que sugeriram construir uma casa inteligente.
Como o objetivo era usar o maior número possível de componentes explorados em sessões anteriores,ficou decidido que:
Uma fotoresistência devia controlar dois LED (acendendo-os caso escurecesse,apagando-os caso fosse dia) e um motor de passo (para descer e subir estores em caso de noite ou de dia, respetivamente);
Uma campaínha devia tocar quando premida e fazer abrir uma porta (que fechará passados alguns segundos) através de um servo motor.
De acordo com os gostos pessoais de cada um, o grupo dividiu-se entre a conceção do circuito e programa e a realização da maqueta da casa. A integração do circuito na maqueta teve de contar com o trabalho de todos como um grupo único.
O facto de um dos motores ser de passo, tornou necessário o software Snap4Arduino em vez do S4A. Mais uma vez, o Snap4Arduino revelou-se mais instável que o S4A e mais exigente em termos de computador a usar. Se fosse agora, teria proposto aos alunos a programação em mBlock.
Os alunos não revelaram problemas em integrar os conhecimentos adquiridos em sessões anteriores, tendo realizado o circuito e programação por etapas, sessão a sessão (primeiro o controlo dos LED, depois do motor de passo e finalmente do servo motor). Deixarei algumas fotos da evolução do projeto em post posterior.
Deixo o circuito construído e o programa em Snap4Arduino realizado...
...o circuito esquemático...
E um pequeno vídeo com o circuito em funcionamento (explicado pelo Diogo, um dos alunos que o criou):
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:
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:
Foi há 4 anos que tomei contacto com o Scratch pela mão da professora Teresa Martinho e do inestimável Fernando Frederico (o grande especialista em Scratch a quem toda a gente, alunos inclusivé, tratava simplesmente por Fred). Nessa altura, era professora de duas turmas de Física de 12º ano na Escola Secundária de Bocage, em Setúbal, e envolvi-me num projeto de iniciação à programação em Scratch. O objetivo era incentivar os alunos a criar, em Scratch, simulações das aulas práticas realizadas na disciplina durante o ano.
Como em todos os trabalhos desta natureza, há sempre alunos que, pela inclinação natural, pela persistência ou pela disponibilidade, se destacam nos trabalhos que realizam. Neste caso, não esqueço a máquina de Atwood que o Jorge criou (aliás, o Jorge criou várias simulações que podem ser acedidas a partir do link da máquina de Atwood - basta clicar em "mais projetos deste autor") nem o divertido jogo imaginado e implementado pela Ana que envolvia um dinossauro a lançar uma bola, recorrendo às equações do movimento oblíquo, bola essa que tentava encestar apesar dos obstáculos que surgiam a complicar-lhe a vida.
A pensar no projeto da Ana, achei que podia aproveitar a pausa letiva da Páscoa para implementar um projeto que envolvesse Física e programação de arduinos. Usei o mesmo dinossauro e a mesma bola. E apliquei, como a Ana, as equações do movimento oblíquo. Em vez de fazer um jogo, optei por fazer uma simulação convencional de movimento oblíquo. O principal upgrade foi lançar mão do arduino e construir um consola, como as dos jogos, a partir da qual se controlam as variáveis de entrada e se dão as ordens de lançar a bola ou de fazer reset à simulação. A alteração da velocidade e do ângulo de lançamento é feita através de resistências variáveis. A alteração da aceleração gravítica é feita através de um botão de pressão que permite a adoção de 3 valores diferentes para esta grandeza (o valor da aceleração gravítica na Terra, na Lua, e em Júpiter). A ordem de lançamento da bola é feita através de outro botão de pressão, assim como o reset, que, depois de um lançamento, repõe as posições iniciais permitindo novo lançamento.
Um RGB (usei um de ânodo comum, por ser o que tinha mais à mão) permite identificar que a simulação espera pela ordem de lançamento, ficando verde, ou que uma simulação está ainda a decorrer, ficando vermelho.
Eis a consola construída:
O programa em si é um exercício de Scratch mais complicado que os exercícios de S4A que costumo propôr. Por isso, em vez de fazer uma cópia dos blocos, como de costume, opto por desta vez disponibilizar o programa completo, para que possa ser analisado, alterado e melhorado.
Em termos de Física, as equações fulcrais são as do movimento oblíquo:
Assumindo a posição inicial na origem (x0=0; y0=0), sendo o valor inicial da velocidade e o ângulo inicial (de lançamento) dados a partir da leitura das entradas analógicas, temos todos os dados para, através de um incremento no tempo, obter todos os valores de x e y para o movimento completo. Há apenas de terminar a contagem do tempo quando a posição y voltar a ser 0. O valor da altura máxima (H, na figura) será o valor máximo assumido pela posição y e a amplitude (A, na figura) será o valor da posição x no final do movimento.
O problema põe-se quando queremos posicionar as figuras (sprites) no ecrã do S4A. Os valores obtidos nas equações vêm em metro e essa não é, evidentemente a escala do ecrã. Na verdade, o S4A usa as mesmas definições de posição que o Scratch:
Foi altura de fazer considerações de ordem prática:
Limitei a velocidade inicial entre 0 e 20 m/s (1023 na entrada analógica correspondente passaram a significar 20 m/s);
Limitei o ângulo de lançamento entre 0º e 90º (1023 na entrada analógica correspondente passaram a significar 90º);
Considerei o eixo horizontal igual a 20 metros (2x240 = 480 passaram a significar 20 m);
Usei a mesma escala para o eixo vertical (2x180 = 360 passaram a significar 15 m);
Como a posição inicial da bola é (-118; -155), tive de levar em conta essas posições no seu movimento.
E pronto. Acho que o enquadramento geral do projeto está feito. Deixo a minha proposta de trabalho com o circuito da consola, os blocos fundamentais da programação em S4A e printscreens de alguns resultados...
...o circuito esquemático do projeto da consola...
...e um pequeno vídeo com a consola e a demonstração da simulação em funcionamento (com a colaboração da Rita, 13 anos):
NOTA FINAL: Quando fiz o filme anterior, ao premir o botão de reset, o valor da amplitude não voltava a zero´. Apesar de tal não ter implicação nos cálculos posteriores, é de facto mais elegantes que depois do reset o valor da amplitude seja levado a zero. Essa situação está já corrigida no programa que deixo para download.
