Uma Sinopse dos Projetos Finais
da Turma I do Segundo Semestre de 2015
Projetistas:Diogo Hideki Shiraishi e Ricardo Akira Nagaishi
O projetista, Ricardo, sempre foi fascinado com carrinhos de controle
remoto desde a sua infância. Comprou junto com o Diogo e um outro
colega da faculdade um Freescale Cup Car kit para participar da
competição promovida pelo Freescale. 
O plano foi adiado por causa da
sobrecarga das atividades acadêmicas e da viagem de intercâmbio
(Programa de Ciências Sem Fronteira) do terceiro colega. Ricardo e
Diogo viram a oportunidade de retomar o plano nesta
disciplina. Tomando como base os códigos/
exemplos disponíveis e aplicando o
conhecimento de conexão Bluetooth adquirido na disciplina, eles
conseguiram controlar o carrinho do kit através
do Arduino Bluetooth RC Controller, como se pode
ver nos vídeos 1
e 2 por eles gravados.Através deste projeto eles constataram que os códigos-exemplo disponíveis na internet são bare metal code (a nível de registradores do Kinetis) com uma estruturação diferente da dos códigos gerados pelo Processor Expert o que dificultou muito a integração dos códigos gerados pelo Processor Expert com os códigos de controle do kit já existentes. A equipe concluiu que a falta de dominio do bare metal code foi o principal empecilho para eles incrementarem novas funcionalidades ao controle do carrinho.
Projetistas: Eduardo Carlassara e Matheus André Coletto
Os projetistas decidiram agregar mais valores ao projeto
dirigido do semestre, incluindo o controle de temperatura e umidade do
ambiente. Basicamente, o objetivo é assegurar o conforto de
temperatura e luminosidade de um ambiente pequeno, acionando
automaticamente um ventilador (cooler) e uma lâmpada
(automotiva). Inicialmente eles pensaram em utilizar o sensor de
temperatura LM61, mas discartaram a ideia assim que fizeram os
primeiros testes. Eles constataram que o sensor tem uma precisão muito
baixa. Ele foi, portanto, substituído pelo módulo
DHT11. 
Três problemas foram constatados pela equipe: aumento da complexidade no controle de fluxo do programa em decorrência do aumento de periféricos operando em paralelo, a insuficiência da fonte instalada nas bancadas do LE-33 para suprir as duas cargas simultâneamente (lâmpada e cooler) e o desconforto visual causado pela imprecisão do LDR. Para o primeiro problema, eles perceberam que o processamento dos dados de um periférico pode interferir no processamento de outros e que uma estratégia mais elaborada no controle de fluxo (de instruções) é necessária para evitar perda de dados. Para o segundo problema, a equipe substituiu a fonte por uma outra mais potente. E, para evitar o desconforto visual, os projetistas definiram uma faixa bem larga de tolerância em torno dos valores configurados pelo usuário.
Projetistas:Rafael Araújo e Felipe Alba Sousa
A equipe propôs desenvolver um sensor de estacionamento
ESTÁTICO, isto é, diferentemente de um sensor automotivo comum, este
sensor seria agregado à parede do estacionamento e não ao carro. O
sensor sonar HC-SR04 é utilizado para medir a distância dos objetos
que se aproximam da parede. A equipe agregou ainda ao sistema outras
funcionalidades que podem melhorar a qualidade dos serviços oferecidos
por um estacionamento: alerta de farol aceso, display que
mostra a distância entre o carro e a parede, registro da hora de
chegada e saída de um carro. Sinais sonoros (buzzer) e visuais
(lâmpada) são duas formas de alerta. Tomando como base os códigos
fornecidos
no tutorial, a equipe conseguiu medir com um
elevado grau de acurácia a distância entre o sensor e um anteparo. E
para assegurar a periodicidade no monitoramento das distâncias, um
temporizador foi programado para disparar periodicamente
os triggers de medição do
sensor. 
A equipe identificou dois problemas. O primeiro é a exibição de valores espúrios de distâncias medidas no LCD e o segundo é a identificação do carro para cômputo da duração de permanência do carro no estacionamento. O primeiro está relacionado com a falta de coordenação entre os eventos de interrupção para iniciar uma amostragem e os instantes em que se iniciam de fato a medição no seu fluxo de controle. E como uma solução para o segundo problema pensou-se na alternativa de aplicar as técnicas de reconhecimento de placas de carro da área de Processamento de Imagens.
Projetistas:Guilherme Farias e Larissa Fauat Schraier
Motivado a desenvolver um forno com temperatura estável
em 3 valores pré-configurados, o projetista Guilherme desenvolveu um
protótipo de forno com uma lâmpada incandescente de 100W, isolado
termicamente com lã de vidro e em seu interior instalado um termopar
do tipo K. Como projeto final da disciplina a equipe propôs projetar
um controlador de temperaturas pré-programadas para o forno. Os 3
valores pré-definidos pelo usuário podem ser gravados numa memória
E2PROM e reutilizados numa série de
fornadas.
Dois pontos que a equipe deu mais atenção: interface com o usuário, já que os potenciais usuários são leigos em computação e estabilidade no controle. Em relação à interface, a equipe aprendeu que para desenvolver uma boa interface deve considerar todos os possíveis casos e guiar interativamente os usuários de forma que qualquer erro leve à interrupção da entrada. Quanto a manter uma temperatura estável, a equipe propôs fazer correção proporcional ao erro, ou seja, fazer ajustes finos nos ciclos de trabalho da lâmpada incandescente de acordo com a diferença entre a temperatura desejada e a temperatura atual do forno. Embora os erros de 10 a 30C sejam aceitáveis para fornadas de bolos, a equipe conjetura que com um controle PID a estabilidade do processo poderia ser melhorada. A equipe reconheceu que conhecimentos sobre Teoria de Controle seriam de grande valia para desenvolver um forno de temperatura estável.
Projetistas: Matheus Ricardo de Campos Soares e Guilherme Teixeira Semissato
Em decorrência dos acidentes envolvendo vazamento de gás
nos restaurantes, a equipe se propôs a desenvolver um sistema de
supervisão de vazamento de gás. O sistema mostra a quantidade de
vazamentos ocorridos e o instante em que ocorreu o último
vazamento. Além disso, o sistema é provido de um sistema de alarmes
constituído de sinais sonoros (buzzer) e visuais (lâmpada), como mostra o video.
Através deste projeto a equipe aprendeu que o sinal digital que indica a presença do gás gerado pelo sensor de gás MQ-2 é afetado pelo fenômeno bouncing. Procedimento de debouncing foi aplicado para evitar contagem errada da quantidade de vazamentos. Outro problema que a equipe teve que contornar foi calibrar o sensor para detectar o gás (liquefeito de petróleo, GLP). A solução empírica adotada pela equipe foi ajustar o potenciômetro do módulo do sensor de forma que o nível do indicador da presença do gás vá para 1 quando um isqueiro cheio de GLP é aberto. Finalmente, a equipe aprendeu que a amostragem da presença de gás pode ser feita de forma periódica por interrupção, independentemente das operações nos outros periféricos.
Projetistas:Lucyan Comini Dourado e Renan Valadão Lima
As experiências do projetista Lucyan com o termostato de
imersão PT100 numa firma em Sumaré onde ele trabalha foram
determinantes para a proposta e a concretização deste projeto. A
proposta consiste em desenvolver um aquecedor de água para preparo de
bebidas quentes. O projetista Renan se inspirou de um problema que
acontecia frequentemente na firma onde ele trabalhava: por
esquecimento do usuário secava todo o líquido de um recipiente no
preparo de bebidas. O sistema foi concebido de forma que a temperatura
ideal para cada bebida seja programável e armazenável numa memória
E2PROM para ser reutilizada.
Enquanto o líquido não atingia a temperatura especificada, o resistor do aquecedor é ligado a uma fonte AC por meio de um módulo de chaveamento de 12V (relé). Do contrário, o resistor é desligado. Como a precisão da temperatura não é essencial para correto funcionamento do sistema, simples controle por correção proporcional aos erros da temperatura é suficiente. A equipe só teve problema com a identificação das teclas digitadas pelo usuário por querer evitar instruções bloqueantes como "esperar passar bouncings" nos seus códigos. Aprendeu que, utilizando as configurações Input Capture e Output Compare do módulo TPM, consegue-se obter o resultado desejado.
Projetistas:Mauri Mendes de Oliveira Júnior e Marina Dioto
Inspirado na invenção do físico Léon Theremin, a equipe
propôs desenvolver um sistema que emule alguma das funcionalidades do
original teremim.O teremim é um dos primeiros instrumentos musicais
completamente eletrônicos, controlado sem qualquer contato físico pelo
músico. Ao invés de utilizar duas antenas de metal para controlar a
frequência (nota musial) e a amplitude (volume), escolheu-se o sensor
infravermelho GP2Y0A21YKOF para perceber a distância da mão em relação
ao sensor e controlar a frequência a ser "tocada". O instrumento
desenvolvido tem 7 escalas uma das quais deve ser selecionada, como
mostra o video. A equipe percebeu dois problemas: a forma como foi mapeada cada distância a uma nota musical não é linear, tornando difícil para um tocador relacionar a posição espacial da sua mão com a nota musical tocada; e o tempo da música ou seja o espaçamento mínimo entre duas notas subsequentes para que a música seja compreensível.
Projetistas:Priscila Moraes de Souza e Rafael Claro Ito
Com objetivo de consolidar o aprendizado sobre projeto de
interface entre um micro-controlador e uma carga de potência maior e
de desenvolver algo lúdico, a equipe decidiu por Tetris. Tetris é um
jogo electrônico de quebra-cabeça desenvolvido pelos russos Alexey
Pajitnov, Dmitry Pavlovsky e Vadim
Gerasimov. 
A equipe decidiu agregar novos valores ao jogo permitindo que o
jogador jogue com o seu celular via
bluetooth.
Inicialmente a projetista Priscila pensou em utilizar
drivers disponíveis no mercado para acionar os leds da matriz,
mas abandonou a ideia pois não encontrou fornecedores capazes de
entregá-los dentro do prazo da entrega do projeto. Projetaram um
circuito de interface com transistores npn de forma que operem em dois
estados: CORTE e ATIVA. O problema que eles constataram foi que no
estado ATIVA o aumento da intensidade da corrente (brilho)
nos leds é mais "delicado". O projetista Rafael procurou
contornar o problema aumentando a frequência de varredura das linhas,
porém eles depararam com um novo problema: perda dos comandos do
jogador. 
A equipe identificou que se pode entrar mais de um
comando durante a varredura das linhas e o seu programa só processa o
último comando. A equipe aprendeu, então, que isso pode ser
solucionado adicionando um buffer para armazenar os dados de
entrada. Em termos da lógica do jogo, a equipe aprendeu que se pode
explorar o conhecimento prévio das situações para reduzir a quantidade
de instruções.Por exemplo, manter atualizada a posição da peça em
movimento na matriz dos leds pode evitar varredura completa da
matriz para localizá-la em cada iteração. Sem o buffer e a
otimização, a jogabilidade do aplicativo desenvolvido é boa como se
pode conferir num jogo
via via keypad
e via bluetooth. Cabe destacar a qualidade da
montagem do circuito da equipe utilizando fios de diferentes cores, o
que facilitou muito a identificação dos possíveis erros
de hardware devido à quantidade de transistores e resistores
envolvidos.