Projeto Casa Inteligente #2

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:

Projeto Casa Inteligente#1

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

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:

Foi você que pediu um projeto interdisciplinar de Física, Eletrónica e Programação?

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.

Relés, arduino e S4A

O uso de relés é uma enorme mais-valia em projetos que envolvam o controlo de componentes alimentados a tensões diferentes das disponibilizadas no arduino. 

Na verdade, para controlar LED através de arduino, basta ligá-los devidamente a uma saída da placa, mas...e se se quiser controlar uma lâmpada alimentada a 230V AC ou uma fita de LED alimentada a 12V? É nestes casos que o relé ganha relevância.

Há dois tipos de relés: os eletromecânicos e os de estado sólido. 

Os relés de estado sólido não têm partes mecânica em movimento, o seu funcionamento é completamente eletrónico. São relés com uma longa vida útil, alta velocidade de resposta, silenciosos, com opções de comutação de tensão AC ou DC.

Os eletromecânicos são os que usaremos neste trabalho e por isso são merecedores de uma explicação mais aprofundada sobre o seu funcionamento.

Um relé eletromecânico apresenta como componente principal uma bobina interna. Os terminais desta bobina estão ligados ao circuito de controlo. Quando este circuito fornece corrente à bobina, esta gera um campo magnético que atrairá, por ação da força magnética, os contactos móveis, acionando assim o circuito a ser controlado, circuito este que é eletricamente independente do circuito de controlo e que, por isso, pode ter uma alimentação com caraterísticas também diferentes.

Para tornar mais clara a explicação anterior, tomemos por exemplo o circuito seguinte:

Quando o interruptor S1 é acionado, a bobina (que se encontra dentro do invólucro do relé) gera, por ação da corrente elétrica que a percorre (gerada pela fonte de tensão V1), um campo magnético cuja força gerada sobre o contacto fará com que, no exemplo dado, a lâmpada passe a estar ligada (alimentada pela fonte de tensão V2). Neste exemplo concreto, o contacto ilustrado é um normalmente aberto (normally open - NO), uma vez que abre o circuito quando em repouso, e o fecha quando é atuado; existem também contactos normalmente fechados (normally closed - NC), que quando em repouso fazem contacto e o interrompem quando atuados. É vulgar um relé apresentar no mesmo invólucro estes dois tipos de contactos.

O relé que usaremos será um SRD-05VDC já incorporado num módulo preparado para arduino, o Keys_SRly. Já tinha comprado um lote de 5 por 6,33€ há algum tempo e foi altura de o experimentar.

Recorrendo à datasheet do módulo usado, é possível identificar os pinos de alimentação do relé (+ e -), que deverão ser ligados à alimentação do arduino, o pino que deve receber o sinal de controlo, assim como os contactos normalmente aberto (NO) e normalmente fechado (NC) disponibilizados:

E pronto, agora é testar o relé. E porquê agora? Porque o meu cadeeirinho de mesinha de cabeceira se estragou. Os fios do cabo junto à tomada partiram e eram tão finos, tão fraquinhos, que eu achei que mais valia usar o candeeiro como cobaia que investir na sua recuperação.

Propus-me, assim, a controlar a lâmpada do candeeiro (230V AC) através do arduino. A intenção foi mesmo só essa e por isso o circuito e o programa são simples, simples. Recorrendo a uma fotorresistência ligada a uma entrada analógica do arduino, faz-se ligar a lâmpada quando a luz ambiente diminuir; o aumento da luz ambiente deve fazer a lâmpada do candeeiro desligar. Apesar de circuitos a 230 V não serem exatamente a minha praia (inspira, expira antes de ligar à corrente...), tudo correu normalmente e sem incidentes.

Deixo a minha proposta de trabalho para testar o relé num circuito com arduino programado em S4A...

...o circuito esquemático do exercício proposto...

...e um pequeno vídeo com o circuito em funcionamento:

É UNO mas não é Arduino...e agora?

Para já, todos os arduinos do clube são genuinos, em parte devido ao facto de, lidando com financiamento do Ministério da Educação, termos de ter as faturas todas em ordem.

O material que adquiro para mim própria, no entanto, vem maioritariamente da China através do Aliexpress - as faturas são geralmente uma trapalhada, mas a diferença de preço compensa. Já há algum tempo que olhava para o valor dos kits que incluíam placas UNO que não Arduino, com preços tentadoramente baixos. Até que me presenteei com um desses kits, sem que estivesse propriamente a precisar de mais uma placa.

Optei por um kit de 5,30€ que achei que correspondia, por um valor bastante baixo, ao que um aluno precisa para começar a dar os primeiros passos na eletrónica e programação. Caso se pretenda comprar mesmo só a placa UNO (placa-clone das UNO Arduino), sem cabo de ligação ao PC, é possível encontrar preços abaixo dos 3€. O cabo USB A-B, que liga a placa ao PC, encontra-se por menos de 1€.

Pois o kit que comprei é o seguinte:

De todas as transações no Aliexpress, esta foi a que correu pior, com o produto a demorar praticamente 60 dias a chegar. Ainda abri uma disputa no site, solicitando a devolução do dinheiro, uma vez que o "período de proteção do comprador" se estava a esgotar, mas pude cancelá-la quando o kit me apareceu na caixa do correio mesmo a cumprir os 60 dias para entrega.

Foi assim que me caiu na secretária uma placa UNO que não é Arduino:

O aspeto da placa é impecável, o processador é mesmo Atmega e os primeiros testes não demonstram nenhuma fragilidade relativamente às placas genuínas.

O único cuidado a ter é instalar no PC o driver (CH340 / CH341 USB chipset drivers) que permite a comunicação desta placa-clone com o software do Arduino (e consequentemente com o software do S4A), uma vez que as placas-clone não usam o mesmo driver das Arduino originais. O driver está preparado para o Windows XP, Windows 7 e Windows 8. No meu computador tenho o Windows 10 e a instalação decorreu sem incidentes.

Uma vez instalado o driver, a placa funciona tal como as outras. Pode-se intercalar a programação desta placa com placas genuinas sem que nos apercebamos da diferença entre elas, pelo que o balanço final é bastante positivo.