Postagem em destaque

Controle PID de Potência em Corrente Alternada - Arduino e TRIAC - Parte I

Este post é o primeiro de uma série de seis que escrevi tratando de controle de potência e PID (controle proporcional, integral e derivativo...

segunda-feira, 11 de julho de 2016

... e a minha geladeira agora roda Python!

Ultimamente tenho me dedicado a um novo hobby, que é cozinhar a minha própria cerveja. A ideia é produzir 20 litros por sábado, que são divididos com os amigos que participam da farra, ops, trabalho.

Em função disso tenho feito projetos legais de automação ligados ao processo cervejeiro, e agora vou passar a publicá-los cá. Sápassado (como dizemos nós de BH) fiz uma palestra no TDC sobre o assunto e surgiu a ideia de criar uma trilha de Tecnologia Cervejeira por lá ano que vem, então vamos já juntando os assuntos por aqui.

Depois eu pretendo fazer um post sobre o processo de produção de cerveja para contextualizar vcs. O fato é que essa é a minha nanocervejaria:

Toda vez que eu construo um equipamento novo, a mangueirinha do chuveiro de hóspedes encolhe...
Os processos cervejeiros são basicamente quatro: brassagem, fermentação, maturação e primming.

Nesse domingão (ontem) eu e o meu Mestre Cervejeiro Tiago, também programador e praticante do Arduinismo, automatizamos a etapa de maturação.

A maturação consiste em deixar a cerveja em um balde tampado em um ambiente climatizado, com temperatura constante e fria. Dependendo do tipo de cerveja pode haver uma rampa de temperatura, ou seja, começa-se na temperatura ambiente e vai resfriando-se o líquido até uma temperatura de uns 3 °C.

Até outro dia eu fazia essa maturação na geladeira do condomínio, em temperatura constante. Aí resolvi aperfeiçoar o processo fazendo uma câmara de maturação em casa, o que nada mais é do que uma geladeira em que eu consiga controlar a temperatura.

Ao começar a "prospectar" a geladeira, o amigo e colega de cerveja Pedro Valle conseguiu com a sogra dele uma geladeira, e ela ainda nos fez a gentileza de emprestar o veículo para transporte.

Acontece que o termostato da geladeira tava quebrado, então ela tava ligando direto. Com esse frio, olhem o que aconteceu com a cerva...


Pois é, virou picolé... isso deve ter feito com que ela se perdesse, pois o fermento deve ter morrido congelado e ele é necessário para o primming. Vou tentar "consertá-la", mas acho que vai rolar não... :(

Bom, o fato é que precisamos controlar a temperatura da máquina, e a melhor forma de fazer isso foi substituir o termostato "zuado" por um outro. E porque não um Raspberry, de maneira a colocar a geladeira na web?

Eis aí o resultado de algumas horas de trabalho no domingão:


Eu tinha um Pi antigão, relés, o Mauríllio, colega cervejeiro com quem fiz um projeto junto e do qual falarei em outros posts me deu um sensor de temperatura, mais um plug wifi que eu já tinha e a geladeira foi parar na intranet da casa!



Vcs podem ver acima o furo que fizemos na bicha para passar:

- O cabo do sensor

- Um par de fios para se conectar no par que substituiu o termostato, agora substituído pelo relé que dá pra ver na foto em detalhe (aquele gadget com o LED vermelhor aceso).

Daí fizemos uma aplicaçãozinha Python que monitora a temperatura, acionando a geladeira quando passa um grau do setpoint e desligando-a quando passa de meio grau abaixo.

Aqui o monitoramento da dita via telnet:



Bom, é isso. Nos próximos posts vamos aos detalhes.

Abracadabraço,

Mauro




domingo, 6 de março de 2016

Detectando pulsos com o Arduino

Dia desses apareceu no Automação no Parque um velho conhecido, o Bruno, um aluno que trouxe o seu TCC tempos atrás e que foi um dos projetos mais legais que a gente já fez. Foi um controle de potência de chuveiro, que deu origem aos posts mais acessados desse blog, a série sobre Controle de Potência por Ângulo de Fase.

Dessa vez ele trouxe um problema, senão tão difícil,  bem interessante. Ele está fazendo estágio num desses vários centros de pesquisa do governo que tem em SJC (me esqueci qual) e por lá rolou o seguinte problema:

- Os caras tem um equipamento que precisa coletar pulsos de um pouco mais de 2V e de 50µs de duração. Existe por lá um equipamento caro que detecta esse pulso, mas eles querem tentar substituir por algo mais em conta.

A pergunta: será que o Arduino "auguenta"???

Como o equipamento não poderia vir até nós, tínhamos que tentar gerar um sinal semelhante para testar. Prá isso, nada melhor que outro Arduino.

























Circuito "simplão", com um Arduino para gerar os pulsos e outro para detectá-los. O Arduino da esquerda gera os pulsos, o da direita detecta. O potenciômetro ajusta a tensão do pulso, para que possamos fazê-la semelhante ao que o Bruno precisa.

Para monitorar os pulsos, usamos um osciloscópio para monitorar o comportamento da bagaça:

Os pulsos vistos aqui foram os que fizemos inicialmente, de 100µs a cada ms. O potenciômetro foi usado para ajustar a tensão, também medida pelo osciloscópio e ajustada para 2V.









Os pulsos foram gerados pelo seguinte código:

#define P_OUT 7

void setup()
{
  pinMode(P_OUT,OUTPUT);
}

void loop()
{
  digitalWrite(P_OUT,LOW);
  delayMicroseconds(1000);
  digitalWrite(P_OUT,HIGH);
  delayMicroseconds(100);
}

Já na detecção foi usado o seguinte código:

#define P_IN 8

void setup()
{
  pinMode(P_IN,INPUT);
  Serial.begin(115200);
}

long t = 0;
int i = 0;

void loop()
{
  t=pulseIn(P_IN,HIGH);
  if(t==0)
    return;
  Serial.print(t-7);
  Serial.print(' ');
  i++;
  if(i > 20)
  {
    Serial.println();
    i=0;
  }
}

O comando pulseIn do Arduino é chave no processo. Ele espera, na porta P_IN, que um pulso HIGH aconteça. Um pulso HIGH significa que o sinal do Arduino saiu de LOW (0V), foi prá HIGH (mais sobre isso abaixo) e prá LOW de novo. A função retorna a duração, em µs, do pulso detectado.

A função possui um terceiro parâmetro, opcional, que recebe o tempo de espera, quer dizer, quanto tempo a função espera pelo pulso. O default é 1s. Mais informações aqui.

E qual é exatamente o valor HIGH, quer dizer, qual o valor mínimo de tensão que o Arduino detectaria? E qual a mínima largura do pulso, ou seja, quanto tempo o pino tem que ficar HIGH para que o Arduino o detecte? Esse foi o objetivo do nosso experimento, a própria documentação do Arduino fala que tem que ser assim, empiricamente.

O programa de detecção imprime a duração de cada pulso detectado. O valor da variável t é subtraído de 7 porque, depois de vários experimentos, determinamos que  chama da função retorna sempre 7µs a mais a cada valor medido. Talvez seja esse o tempo consumido pela própria função, sei lá eu.

A gente conseguiu baixar a largura do pulso até 5µs, e a tensão até 2,1V. Menos do que isso o Arduino Mega (detector) não conseguia perceber o pulso.


Ao lado, pulso de 5µs.

Acho que depois vale a pena fazer um estudo melhor disso, ver se existem outras implementações do pulseIn na internet, ver se o valor da tensão tem alguma correlação com a largura do pulso (quer dizer, se por exemplo o pulso fosse de 5V, será que ele detectaria um pulso de menos de 5µs de duração?) etc.

De toda forma, atingimos com uma certa folga (pelo menos na largura do pulso) o objetivo buscado pelo Bruno. Ele vai seguir com o projeto e depois (espero eu!) nos dará retorno sobre o que aconteceu.

É isso.

Abaixo, filme do troço funcionando. Dá prá ver os dois Arduinos, o circuito com o potenciômetro, a tela do osciloscópio e os resultados no notebook.




E abaixo, funcionando com pulsos de 5µs a cada segundo. Repare que é bem difícil de perceber o pulso na tela do oscilocópio.

É isso.


domingo, 10 de janeiro de 2016

Primeiro Automação no Parque de 2016

Ontem estreamos no Automação no Parque 2016. Começamos bem, um bocado de gente, projetos interessantes, a turma do cosplay cada vez mais presente... aí vão as fotos:
















Um dos projetos legais é um de dar uma turbinada numa espada Jedi. A ideia é fazê-la soar mais alto e intensificar o brilho do sabre. Para isso o trabalho não será fácil, acho, mas é possível chegar a um bom resultado.






















Acima o punho da espada aberto, contendo o circuito de comando.

    Abaixo estrutura que suporta os LEDs da "lâmina de luz".




































A Prefeitura está terminando a reforma do telhado do quiosque, porisso as faixas que teoricamente deveriam impedir o acesso ao espaço. Como a obra está quase pronta e não haveria trabalho ontem, o povo sempre gente fina do Parque autorizou-nos a pular a cerca.
















Acima, o projeto do Michael, segundo ele uma espécie de quadripod capaz de andar na vertical!

Esse promete!

É isso. Automação no Parque strikes back, apareceçam!

domingo, 15 de novembro de 2015

Conectando o PC e o Raspberry Pi via cabo de rede, SEM roteador no meio




Pois é, desde setembro que não rolava um post aqui por esses lados, mas o fato é que eu estou fazendo CINCO matérias do mestrado ao mesmo tempo e, por isso, não tenho tido tempo prá mais nada além de estudar, numa rotina que começa às CINCO da matina e termina por volta da meia-noite todos os dias.

Semana passada, porém, o amigão Thiago passou cá em casa para almoçar conosco, ele e D Estelinha, digníssima cara-metade. Como ele trouxe o seu Pi 2 recém adquirido para que a gente preparasse ele para rodar, assim fizemos. Ele quer trabalhar num projeto para automatizar todos os controles remotos da casa dele no celular, então fizemos também alguns testes (que funcionaram, depois de muita surra!) do uso daqueles receptores de controle remoto tipo NEC com o Pi. Sobre esse assunto vai rolar um post tb, mas como ainda não terminamos, fica prá depois.

Acontece que o Thiagão, na sua infinita gentileza largou cá em casa a título de empréstimo o seu Pi 2, de modo que hoje eu resolvi dar uma pausa nos estudos e "raspberriar" um pouco, até porque estou envolvido num projeto muito interessante e inovador sobre o qual ainda não posso escrever.

Um problema de trabalhar com o Pi é ter que levar teclado, mouse e principalmente monitor para onde a gente queira brincar. A gente pode até acessá-lo remotamente, mas tem que colocá-lo na rede do destino e alterar os parâmetros de wifi, consequentemente. Aí sem monitor não rola.

E se a gente conectasse o bicho no notebook sem a ajuda de um roteador? Será que é possível? Google prá lá e prá cá... bingo! Fiz o procedimento abaixo, que funcionou perfeitamente e é parecido com o que o cara escreveu aí:

1) Primeiro conferi no meu PC se o IP é automático ou manual. Era automático. Nesse caso, abra uma janela do DOS e dê o comando:


ipconfig

Anote o ip do seu micro no wifi e também a máscara de sub-rede coreespondente.

2) Editei o arquivo que ele indicou. Para isso, ele oferece dois caminhos, um mais simples e outro que implica em tirar o cartão do Pi etc. Fiz o mais simples:

sudo nano /boot/cmdline.txt

Esse arquivo tem uma linha só e tem que continuar assim, ou seja, qualquer coisa que vc for adicionar coloque no fim da linha e NÃO dê enter depois. Vc deve colocar no fim da linha um espaço e então ip=<número do ip do Pi>

3) Agora entra a escolha do <número do ip do Pi>. Se o IP do seu micro for automático, vc deve colocar um ip válido da faixa do seu roteador wifi que fornece o IP para o seu micro.

 Se for manual, vc tem que criar o IP do Pi respeitando as dicas que ele dá, basicamente tem que ser um IP válido com a máscara que está especificada no PC

Exemplo: se o IP do PC for 192.168.0.123 e a máscara de sub-rede for 255.255.255.0, use um IP como 192.168.0.200.

4) Em seguida, conecte o PC e o Pi através do cabo ethernet. Esse cabo éum cabo comum, antigamente seria preciso um cabo especial invertido, mas os adaptadores de rede hoje fazem eles mesmo a conexão invertida, necessária para esse tipo de conexão.

5) Reinicie o Pi. Imagino que vc tenha um monitor conectado a ele nesse ponto, então vc vai ver que ele demora uns 30 s para ativar a conexão via cabo.

6) Agora, para acessar o Pi vc pode usar o Putty, o Remote Desktop Connection caso tenha configurado esse tipo de acesso, para acessar o seu Pi.

Piece of cake, isn't it?

domingo, 6 de setembro de 2015

Startup Maker Weekend UNIFEI - Itajubá, MG

Fim de semana passado, 29,30 e 31 de agosto, participei do Startup Maker Weekend promovido pela UNIFEI. Foi o primeiro Startup Maker Weekend da América Latina. Outros já tinham acontecido, mas focados somente em software.

Devo dizer que a experiência foi... impactante!

54 horas de trabalho, cerca de 150 competidores, noss otime ficou num honroso terceiro lugar.

Os trabalhos começaram na sexta ali pelas 19, e foram até ali pela 1 da matina do sabadão. Aí, voltamos às 8 da matina e... eu fiquei dentro da UNIFEI trabalhando até meia-noite de domingo!

Dormi das 4:30 da matina até ali pelas 6 da manhã do domingão, no carro, no frio itajubense de 9°C.

O modelo do evento é muito legal:

- Primeiro as pessoas apresentam idéias. Quem tiver uma que apresente, em no máximo um minuto.

- Na apresentação vc tem que dizer qual o time vc gostaria de montar para completar as suas competências. Ex: eu dei uma ideia, como sou maker precisava de programador web, designers e gente de marketing.

- Em seguida as ideias foram relacionadas em cartazes e colocadas em uma parede, para que votássemos nas três que mais nos agradassem (colando uma espécie de "estrelinha" nas ideias).

- Os donos das quinze mais votadas foram então tentar montar os seus times, de até 10 pessoas, para desenvolver a ideia.

- Em seguida, vinha uma etapa de planejamento, com um canvas adequado.

- Aí terminou a sexta-feira.

- No sabadão, café da manhã e bora trabalhar!

A ideia é produzir não só um gadget mas também um modelo de negócios, com pesquisa de mercado, marca, preço e modelo de vendas, E assim fizemos. O povo foi a campo fazer pesquisa de mercado, inclusive.

Fim à disposição mentores técnicos, de marketing, de finanças, Pudemos pedir a ajuda deles quando necessário

- Ao fim dos trabalhos ocorre uma espécie de "feira", onde os produtos são expostos em bancadas para avalização da comissão julgadora.

- No domingo à noite cada grupo tem três minutos (!) para fazer uma apresentação de seus resultados, seguidos de quatro minutos de perguntas.

- Aí a comissão julgadora se reúne e anuncia os vencedores.

Nosso time, com os joseenses Fábio e André ficou em terceiro lugar.

O Cristian, tb joseense, levou menção honrosa, ou seja, São José fez bonito!

Abaixo, imagens do envento:

Nosso timaço de craques!


Mentor trabalhando

Fomos "às compras", escolher os componentes que usaríamos













Nosso time, quaaase completo na foto
















Hora do rango

A turma foi dividida em duas salas: essa, a nossa.

Traquitana voadora com Gopro, transmitindo imagens em tempo real

André trabalha

...

Nossa mesa

Salas dos outros makers

Voltando para o trabalho, às seis da manhã...



Esse negócio de ser maker dá uma fome...



Na madrugada nossa sala tava mais animada...

A galera já de volta aos trabalhos



Gabi e nosso mascote





















Nossos planos

As próximas três foram na tal "feira" de que falei acima


















Por fim, imagens da nossa premiação
























Por fim, timelapse que o Fábio fez com sua Gopro... reparem no sono do Everson, na madrugada...



Olha... foi muuuuuuuiiittttoooo bom! A turma que organizou lá da UNIFEI é nota dez, o povo tem a manha de fazer esse tipo de evento.

Os espaços que usamos ficaram por nossa conta, ou seja, a UNIFEI entregou a chave para a galera da organização.

Mais uma vez, o nosso time foi 10! Competência, empenho, esforço... nada faltou.

Foi simplesmente o melhor evento maker do qual já participei.

É isso.



domingo, 2 de agosto de 2015

Hackaton CI&T

No dia 25/05 participamos de hackaton think.make.move(), promovido pela CI&T, aqui em São José dos Campos.

O evento foi muito legal, com uma infra boa e a equipe da CI&T motivou bastante os times com brincadeiras. O lanche ótimo, enfim, nota dez prá infra do evento.

O tema do evento foi sustentabilidade e água. Fomos estimulados a produzir soluções que ajudassem a otimizar e reduzir o consumo de água em SP. Foi nos fornecida uma API para acessar dados de pluviômetros e também poderíamos acessar outros serviços de dados a respeito do consumo e disponibilidade de água.

Nosso time, composto por mim, Damião, Cristian, Euclides e Carlos, usou o nosso mascote SabugoEye para criar um equipamento de monitoramento em tempo real do volume de água de uma represa.



A ideia é instalar a maquininha na beira da represa para que ela possa disponibilizar dados e imagens a respeito.

O site foi feito com Unity, plataforma da Microsoft para desenvolvimento de games e sites com alta performance visual web e mobile. Ficou muuuuiiito bom, graças à habilidade do Damião e do Cristian. Eu e o Euclas fizemos a parte arduínica da coisa, dando à câmera movimento para que ela pudesse ser usada para visualizar diferentes ângulos da represa.

Os fontes da parte Unity podem ser baixados pelos interessados clicando aqui. O site está ocasionalmente no ar aqui:

Abaixo, fotos do evento. Que venham mais desses!!!



Abaixo uma RepRap que os caras levaram, feita com estrutura acrílica. E aí, Fabião???


Abaixo, vídeo do SabugoEye funcionando.

video


segunda-feira, 15 de junho de 2015

Visão Computacional no Intel Edison - OpenCV e Python


Estamos, a turma nérdica de São José dos Campos, em processo de aquecimento das turbinas para o Intel IoT Road Show, que no Brasil acontecerá a partir da próxima sexta-feira, em Sampa. O clima aqui é "Uhu! Vamo invadí!", todo mundo ansiosamente aguardando o início dos trabalhos.

O Intel Road Show é um evento promovido pela empresa quando quer disseminar um novo produto. Da outra vez em que participei foi sobre o Galileo.

Desta vez, a estrela da festa é o Intel Edison.


Recordando: o Intel Edison é essa plaquinha azul lado esquerdo, na fig. acima.

Do tamanho de um cartão de memória daqueles maiorzinhos, a bichinha roda Linux, tem WiFi e Bluetooth. Ou seja, é uma potência, apesar do tamanho diminuto. Tudo que a gente gosta num hardware: pequeno e poderoso. Aqui tem um post que fiz sobre as minhas primeiras experiências com ele, lá no blog da Intel.

Pensando no evento, nos últimos tempos tenho me dedicado a trabalhar com ele. Como vira e mexe eu faço alguma coisa em Visão Computacional, resolvi fazer algo nessa linha, usando o OpenCV & Python, para ver o potencial do Edison processando algoritmos mais exigentes em termo de esforço computacional.

Foi um pouco enrolado colocar o OpenCV para rodar no Edison por causa do "espaço em disco" do root, que era pequeno. Na última distro do site esse espaço já foi para 1,4 Gb, então sugiro que vcs atualizem antes de entrar por essa seara. Eu acabei não "tomando nota" do processo de instalação e configuração, mas prometo que farei isso assim que tiver um tempinho. É bem interessante o processo, e ensina muito sobre as "entranhas" do nosso Intel Edison. E por outro lado foi rápido, porque não precisei recompilar o OpenCV. Em outras plaquinhas só a compilação do OpenCV chega a demorar oito ou mais horas...

Bom, instalada a bagaça, toca a experimentar. Para começar, escolhi o desafio de se encontrar rostos em fotos de pessoas. Pesquisa dali, pesquisa daqui, encontrei referências a uma técnica chamada Cascade Classifier, que foi o que usei.

Cascade Classifier

Essa técnica consiste em você criar uma base de conhecimento a partir de figuras já conhecidas, ajustando os parâmetros de pesquisa e salvando esses parâmetros de maneira que o algoritmo possa se adaptar a enxergar aquele padrão específico. É o tipo de coisa que se chama de machine learning, ou aprendizado computacional, ou "de máquina".

No caso o que se pretende é treinar uma "cascade of boosted classifiers working with haar-like features" que podemos traduzir como "cascata de classificadores bombadões trabalhando com funcionalidades semelhantes a haar" (????). Bom, como esse blog gosta também da teoria, vamos entender o que há por trás disso.

Um classificador, ou algoritmo de classificação, é um algoritmo que seleciona, dentre um conjunto de alternativas, qual a melhor se encaixa para uma série de observações. Outro ramo da computação que se vale bastante desse tipo de algoritmo é o data minning, que pode ser entendido como a busca (mineração) de largas bases de dados procurando por padrões.

A cascata é porque se usam vários diferentes algoritmos um após o outro para tentar achar padrões. Real Adaboost, Gentle Adaboost e Logitboost são os algoritmos usados na função que usei do OpenCV.

E porque bombados (boosted)? Essa palavra significa a ideia de que pode-se encontrar algoritmos que estão fortemente correlacionados com a observação partindo-se de algoritmos mais fracos, ou seja, pouco melhores do que um chute.

Por fim o Haar-like: vamos supor que estejamos analisando uma área da imagem (janela de detecção) procurando por um rosto. A ideia é considerar áreas retangulares adjacentes na janela de detecção, somar a intensidade de cada pixel e calcular a diferença entre essas somas. Essa diferença é usada para classificar sub-seções na imagem. No nosso projeto: digamos que tenhamos um banco de dados de imagens com rostos humanos. Normalmente a região ao redor dos olhos é mais escura do que as faces. A ideia então é identificar retângulos adjacentes que ficam sobre a região dos olhos e da face. A posição dos limites da face seria então determinada relativamente à posição encontrada para esses retângulos. O nome Haar vem de uma técnica semelhante que é usada para analisar wavelets, que são pequenas ondulações.

"Bom, tio", perguntaria vc, "eu vou ter então que pegar um monte de fotos da parentaia toda e ficar treinando o software até ele achar as fuças do povo lá de casa?"

É um jeito. Nesse caso você teria que ter uma família bem grande, porque precisaríamos de mais de 1000 imagens positivas (ou seja, que vc sabe que é um rosto) e negativas, ou seja, onde não há rosto nenhum. Trabalhão...

Acontece que a gente pode também aproveitar o trabalho de quem já tenha feito isso. No GitHub do OpenCV, aqui nesta pasta, vc acha vários aquivos XML contendo os parâmetros para pesquisa de rosto, corpo inteiro, olhos etc.

Basta vc criar o objeto CascadeClassifier informando onde se encontra esse arquivo, antes de processar as suas imagens.

Boralá ver o "pograminha"?

De programa "mermo" tem 10 instruções. As demais são comentários.

Agora uns resultados. Comecei com umas fotos de melhor qualidade, do rostinho bonito meu e da patroa, eu de pijama no domingão à tarde...



Aí, no café da manhã da Simova, tirei uma foto da galera, muito mal tirada por sinal, e vejam o resultado.


Processei também uma foto que tirei no INPE, numa sala meio escura, sem a turma posar muito. Aí apareceu um problema comum nesse tipo de algoritmo. É que ele depende bastante dos olhos para achar o rosto. Aí, se aparece o tal do óculos... só pegou o do primeiro plano, mesmo assim só por causa da lente branca,talvez...



Legal, né?

Pretendo continuar com a brincadeira OpenCV + Edison. Aguardem!

Abracadabraço,

Mauro