[Poder das Pontas - fenômeno eletromagnético consistindo na capacidade das pontas em aglutinar cargas elétricas, aumentando o campo elétrico no entorno]. O Poder das Pontas é o blog aglutinador dos conhecimentos em Engenharia Elétrica.
Por falar em motores elétricos, que foi tema do nosso último post, gostaria de dar conhecimento a outro trabalho de conclusão de curso que estou orientando, no âmbito do curso de Engenharia Elétrica da Unisul. Trata-se do desenvolvimento de uma bancada automatizada para extração de parâmetros de circuito de um motor de indução trifásico, de autoria dos acadêmicos Fábio Peixer e Lucas Groposo Silveira.
Arquitetura da bancada proposta
Como pode ser visto no diagrama acima, a proposta envolve um módulo de processamento, responsável em controlar as fases do ensaio a partir da parametrização de um inversor de frequência, marca Danfoss, obtendo deste os dados elétricos necessários para que o módulo de processamento determine os parâmetros do motor. Este módulo foi implementado com FPGA, possuindo um sistema operacional baseado em Linux embarcado, especialmente configurado para as necessidades e rodando as aplicações destinadas à finalidade do projeto. Além disso, possui uma aplicação web rodando em servidor http, o que permite iniciar a bateria de ensaios e obter os resultados através de um navegador web.
A extração de parâmetros de um motor de indução trifásico para obtenção de seu modelo de circuito elétrico equivalente é importante para diferentes aplicações, que vão desde a possibilidade de se simular o comportamento deste motor, até seu uso em equipamentos de eletrônica de potência que o alimentam, a fim de viabilizar sua controlabilidade.
Contudo, é ensinado nas disciplinas referentes a máquinas elétricas o método tradicional de obtenção, através de uma abordagem manual. O trabalho então se propõe a automatizar este processo, conforme pode ser visto no vídeo abaixo, que resume o protótipo da bancada desenvolvida.
Pelos resultados obtidos, esta proposição possui tanto aplicações para fabricantes ou usuários realizarem este tipo de ensaio para suas necessidades, como também pode ser empregada para cursos técnicos, tecnológicos, de engenharia e afins, uma vez que está preparada tanto para o contexto de aulas de laboratório presenciais, como na concepção de laboratório virtual de experimentação em máquinas elétricas de indução trifásicas, destinada a cursos na modalidade à distância (EAD).
O trabalho será defendido na próxima semana. Quem quiser maiores detalhes sobre a agenda da defesa, pode me contatar a respeito.
Mais uma vez o IEEE Spectrum nos brinda com um artigo publicado recentemente, acerca dos desafios por trás do desenvolvimento de carros elétricos melhores, o qual compartilho através do link abaixo:
Os autores propõem uma mudança no foco para incremento dos veículos elétricos, das baterias para os motores elétricos que impulsionam os carros, abordagem que causou controvérsias desde a publicação, como pode ser atestado pela leitura da seção de comentários, logo abaixo ao término do texto.
Polêmicas à parte, a abordagem proposta pelos autores é uma interessante descrição sobre as questões associadas à substituição dos automóveis impulsionados por motores de combustão interna pelos elétricos, bem como o funcionamento dos motores elétricos e sua aplicação em veículos automotivos. Por isso, este post sintetiza alguns pontos interessantes apresentados no texto.
Em primeiro lugar, um dado histórico curioso. Durante a primeira década do século XX, 38 % de todos os carros nos EUA eram elétricos, participação que praticamente declinou a zero a partir de 1920, onde os motores de combustão interna se tornaram dominantes. Contudo, os carros elétricos voltaram à tona com as necessidades dos novos tempos relacionadas à economia de energia e à redução da poluição. Porém, seu ainda alto custo combinado com uma autonomia limitada vem sendo entraves para sua adoção massiva e substituição dos modelos movidos a hidrocarbonetos.
Para o melhor entendimento nas questões que envolvem a melhoria dos motores elétricos aplicados a carros, uma noção básica sobre estes é dada: trata-se de um motor mais simples que um motor de combustão interna, formado por duas partes. Uma parte estatórica, que é fixa e envolve o rotor, que é necessário para rotacionar o eixo e criar torque. Para isto, o estator e o rotor interagem magneticamente para converter energia elétrica em mecânica.
É esta interação magnética que é responsável pelas diferenças existentes entre tipos de motores elétricos. Em motores CC com escovas a corrente flui através das escovas que deslizam sobre um comutador. Esta corrente energiza as bobinas no rotor, que por sua vez cria campo magnético que é repelido por ímãs ou bobinas alimentadas localizadas no estator. O comutador por sua vez periodicamente inverte o sentido da corrente, de tal forma que rotor e estator se repelem ciclicamente, gerando a rotação do eixo. Contudo, esta abordagem limita o torque e está sujeito a desgaste das escovas, tendo assim decaído seu uso em tracionamento. Uma ideia do funcionamento do motor CC pode ser visto no vídeo abaixo.
Carros elétricos modernos utilizam corrente alternada suprida por um inversor. Neste, a dinâmica do motor depende mais do campo magnético girante do estator do que do rotor. Esta característica alivia as restrições no desenho do rotor, que é o elemento mais complicado do motor, o que reduz os desafios de projeto em linhas gerais.
Temos dois tipos de motores CA: assíncronos e síncronos. Segundo os autores, o síncrono tem um desempenho melhor e mais eficiente, quando aplicados aos veículos elétricos.
Os motores síncronos também o são em duas variedades: o mais comum é a máquina síncrona de ímã permanente (PMSM), o qual emprega ímãs no rotor. Para fazer o rotor girar, um campo girante é formado a partir da alimentação das bobinas do estator em CA. Assim, os polos do ímã do rotor estão alinhados com o campo girante do estator, fazendo o eixo rotacionar. Esta variedade equipa automóveis como o Chevrolet Bolt e Volt, a BMW i3 e o Nissan Leaf, dentre outros, podendo alcançar eficiência de 97 %. Os ímãs são constituídos de terras raras, como os de Neodímio, desenvolvido em 1982 pela General Motors e Sumitomo.
As máquinas síncronas de polos salientes (SPSM) empregam bobinas no rotor no lugar de ímãs. Estas bobinas são alimentadas em corrente contínua através de anéis deslizantes, o qual, diferentemente de um comutador de uma máquina CC, não precisam inverter o sentido da corrente. Os polos do campo do rotor são portanto estáticos. Assim, a rotação do eixo se dá de forma idêntica ao PMSM. Entretanto, por causa desta necessidade de energização do rotor, a eficiência é um pouco mais baixa, ficando entre 94 e 96 %. Porém, tem a vantagem de ter o campo do rotor ajustável, o que permite desenvolver torque mais eficiente em altas velocidades, quando comparado com o PMSM. Assim, a performance em geral para a propulsão de carros pode ser maior. O único fabricante que usa este tipo de motor é a Renault, em seus modelos Zoe, Fluence e Kangoo. O vídeo abaixo sintetiza os conceitos acerca do funcionamento deste tipo de máquina.
Veículos elétricos devem ser concebidos utilizando componentes que sejam não só altamente eficientes, como também leves. A abordagem mais óbvia é melhorar a razão peso-potência reduzindo o tamanho do motor. Entretanto, tal máquina produzirá menos torque para uma certa velocidade de rotação. Assim, para obter a mesma potência, o motor necessitará girar a rotações mais elevadas, compensando a redução do torque (a famosa relação P = ω x T). Hoje estes motores em carros elétricos giram até 12.000 rpm. Motores até 20.000 rpm estão sendo preparados para a próxima geração. Máquinas alcançando 30.000 rpm estão sob investigação. O problema das altas velocidades é que elas requerem caixas de transmissão de mais alta complexidade, uma vez que são geradas rotações maiores que àquelas que são necessárias para girar os pneus. Tais caixas implicam em maiores perdas energéticas.
Uma segunda abordagem é a aumentar a força devido ao campo magnético do motor, o que incrementa o torque. Esta é a razão que leva a adoção de um núcleo ferromagnético às estruturas bobinadas do motor, o que, embora aumente o peso, eleva a indução por um fator de 2, o que justifica seu uso em todas as máquinas elétricas da atualidade. Contudo, esta elevação da indução tem um limite, dado pelo fenômeno da saturação, dado pelas características construtivas do aço empregado, mas que nos materiais mais efetivos em custos não passa de 1,5 Tesla. Somente aços muito caros e baseados em ligas como ferro-cobalto alcançam induções de 2 Tesla ou mais.
Finalmente, a terceira abordagem possível para se elevar o torque é fortalecer o campo pela introdução de mais corrente nas bobinas. Aqui, novamente, tem-se outros limitantes. Aplicar mais corrente incrementa as perdas devido a resistência ôhmica dos condutores (as perdas no cobre), reduzindo a eficiência e produzindo calor que pode danificar o motor. É possível então usar fios condutores melhores que o cobre para melhorar isto. A prata, por exemplo, estaria disponível para tal intento, mas é absurdamente cara para tal propósito. Desta forma, a maneira mais prática de contornar tal limitação é controlar o calor via refrigeração do motor. O Estado da arte é o envio de água refrigerante diretamente nos enrolamentos, mais que simplesmente passar o líquido refrigerante externamente ao estator da máquina (ver figura abaixo).
Arrefecimento avançado inclui a passagem de líquido refrigerante diretamente nas bobinas (esquerda) do que esta sendo feita externamente à carcaça do motor (direita)
Quando o custo não é problema, é possível carros elétricos tão leves quanto 0,15kg/kW, sendo páreos para os melhores carros de Fórmula 1 movidos com motores à combustão, como pode ser provado pelo exemplo de projeto apresentado pelo artigo. A questão relevante é como fazer isso para um carro em que as pessoas possam pagar.
Carro de corrida da Fórmula Estudantil de Carros Elétricos, onde foi possível aplicar técnicas especiais de refrigeração ao motor
A proposta dos autores se baseia no fato pelo qual os motores elétricos aplicados a veículos devem operar melhor no modo motor do que no modo gerador, a despeito destes motores funcionarem da mesma forma nos dois modos. A máquina elétrica em um carro só deve funcionar como gerador durante uma frenagem regenerativa, o qual pode ser usado para recarga das baterias.
Em essência, em um motor síncrono temos duas forças atuando para a criação do movimento: a primeira, devido a força de Lorentz, está associado à atração entre o campo girante do estator (pela circulação de correntes nos enrolamentos desta parte) e o campo fixo do rotor. A outra, decorrente da saliência dos polos do rotor, é uma força de relutância, associada à atração do bloco de aço pelo campo. Ambas forças são próximas de zero quando os campos do rotor e estator estão perfeitamente alinhados. A medida que o ângulo entre os campos aumenta, a máquina desenvolve potência mecânica. E em uma máquina síncrona, sem o escorregamento entre os campos (como num motor assíncrono), o campo de estator possui um ângulo particular com respeito ao rotor, podendo ser variado livremente durante a operação para se obter uma eficiência mais alta. Este ângulo ótimo para produção do torque pode ser determinado previamente para uma dada corrente e então esta é devidamente ajustada para alimentar as bobinas do estator, o que é feito pela parte de eletrônica de potência responsável pelo controle e acionamento do motor.
Entretanto, há um problema: a medida que o campo do estator se move com respeito à posição do rotor, as forças de Lorentz e de relutância não estão alinhadas de forma a se obter o máximo da combinação destas duas forças, devido as distribuições desiguais destas ao longo de uma referência angular, como pode ser visto abaixo.
No topo, as forças de Lorentz e de Relutância em cinza são deslocadas a fim de se obter o pico da força máxima conforme curva azul. Abaixo, a distribuição destas forças e a força total em azul em um motor convencional.
Como pode ser atestado, a força de Lorentz se distribui como uma função sinusoidal que atinge seu pico em um ponto a 90 graus do ponto de origem da referência. Já a força de relutância alcança seu pico a 45 graus e a uma frequência que é o dobro da de Lorentz. Como os picos ocorrem em diferentes pontos, o pico total é menor que a soma dos picos das partes. Assim, se o motor puder ser redesenhado para que as duas forças encontrem seus picos no mesmo ponto, haverá um incremento na potência do motor, sem adição de custos. Esta é a proposição do artigo, no qual os autores combinam PMSM com SPSM resultando em uma máquina síncrona híbrida.
Protótipo do motor construído pelos autores
Vista em corte do motor proposto e suas partes
Maiores detalhes construtivos podem ser obtidos na leitura deste. A única contrapartida desta abordagem, no entanto, é uma perda na eficiência da máquina quando opera como gerador, no qual os autores descrevem uma maneira de contornar tal situação. Quando numa situação em que irá atuar como gerador, inverte-se o campo do rotor pela mudança no sentido da corrente que alimenta os enrolamentos desta parte. Medições no protótipo indicaram que esta mudança leva menos que 70 ms, o qual é adequado para uso em carros.
Com a adoção deste motor, um carro que viajaria 100 km com uma carga, irá até 104,4 km, segundo medidas feita com um protótipo construído.
Sumarizando algumas das ideias aqui apresentadas, compartilhamos abaixo um vídeo que descreve o funcionamento de um carro elétrico, usando o modelo Tesla S, que emprega motores CA assíncronos, utilizando assim um tipo diferente do que fora explorado neste post:
Por tudo isto, considero que esta proposição, apesar de interessante sobre o ponto de vista do design de motores e de oferecer algum ganho de desempenho, ainda não dispensa os avanços a serem feitos nas baterias (ou qualquer outra forma de suprimento que se mostre vantajosa) como o ponto crucial para a mudar o paradigma dos carros movidos a motores de combustão interna.
E você, o que acha? Deixe seu comentário a respeito.
Nos programas desenvolvidos nos últimos posts, o intervalo de tempo em que o LED fica aceso ou apagado é implementado através de estruturas de repetição for, cuja quantidade de iterações define o tempo, de certa forma intuitiva. Neste post, discutiremos uma forma alternativa de se definir este tempo, agora de forma objetiva, através do uso de Timers.
Os timers são configurados como um múltiplo do clock do sistema. O código abaixo ilustra a esta configuração e uso do timer para a criação de uma função Delay usada no programa.
A primeira providência é o fragmento entre as linhas 24 e 26, onde é configurado o Systick Timer. A base para esta configuração é a constante SystemCoreClock, que é o número de ticks, ou ciclos do clock do sistema por segundo. Quando dividido por 1000, isto equivale a um intervalo de 1 ms onde o Systick_Handler será chamado (linha 45). Desta forma, a cada 1 ms é executado o código entre as linhas 45 e 48, onde a variável TimingDelay é decrementada até chegar a zero.
A variável TimingDelay é declarada na linha 38. Observe o uso de "__IO": isto faz com que o compilador não faça uma otimização indesejada, adulterando o padrão de tempo configurado.
E como esta variável é setada? Observe que seu valor é atribuído na passagem do parâmetro da função Delay, entre as linhas 40 e 43 do código.
Desta forma, agora podemos definir o tempo desejado em que o LED pisca, que, a exemplo do código acima, foi setado como 250 ms.
No próximo post da série, apresentaremos uma nova aplicação, onde utilizaremos o botão da placa como uma entrada. Até lá!
O excelente IEEE Spectrum publicou um relato histórico sobre o processador TMS9900 da Texas Instruments, que poderia ter sido "o" processador da revolução dos PCs.
Na época de seu desenvolvimento, a IBM estava trabalhando em um projeto secreto que culminaria no lançamento do IBM-PC. Neste, o grupo de desenvolvimento tinha carta branca para usar partes de terceiros no projeto, como o sistema operacional e os aplicativos, desde que tivesse o time-to-market adequado e fosse validado pela empresa, a fim de não manchar a reputação renomada de qualidade e confiabilidade.
A seleção do microprocessador foi parte deste processo, girando em torno TMS 9900, o Motorola 68K e o Intel 8088. Daí vem a parte interessante da história, que compartilho abaixo, em como a IBM escolheu um chip inferior (8088), dentre um que já nasceu perdedor (TMS9900) e um superior (68K) que perdeu a disputa.
É um ótimo artigo para entendermos o embate entre as diferentes propostas de arquitetura de microprocessadores na nascente era da computação pessoal. E de quebra, o texto apresenta a ligação disto tudo com o início da Microsoft no domínio dos sistemas operacionais e da formação de um dos maiores impérios do segmento de software.
Não contente, a Texas ainda tentou produzir o primeiro computador de 16 bits, a partir do TMS9900, cuja história é apresentada como um link do artigo acima, cujos prejuízos aceleraram a retirada da empresa do mercado de computadores pessoais.
Sorte nossa que a Texas mudou de estratégia, aproveitando este conhecimento para focar em microprocessadores de aplicação específica, o que culminou no desenvolvimento da família TMS320 de processadores de sinais digitais, o que vieram a se tornar quase metade da receita da empresa e colocando-a em uma posição de vanguarda para processadores embutidos em um chip. Tal medida reverteu o declínio da empresa no segmento de semicondutores, gerando receitas em chips voltados para modems, controladores de discos e outra variedade de produtos.
Alternativamente à forma apresentada na parte I desta série, é possível facilitar o processo de programação dos periféricos da placa STM32F4Discovery usando a Standard Peripheral Library do Cortex-M4. Cada periférico tem sua própria biblioteca de software correspondente.
No CoIDE, na aba Repositório, basta incluir o periférico desejado. Para o primeiro projeto apresentado, significa selecionar as bibliotecas RCC (referente ao controle do reset e clock para a STM32F4) e GPIO (referente as portas genéricas de entrada e saída da placa). Em outras palavras,
Isto adicionará a estrutura do projeto o código correspondente a estas bibliotecas, como pode ser comprovado pela adição dos arquivos de cabeçalho correspondentes na pasta cmsis_lib/include:
Isto proporcionará a possibilidade de se usar rótulos que se referem aos valores que necessitam ser atribuídos aos campos que configuram o clock e a porta (como GPIO_Mode_OUT ou RCC_AHB1Periph_GPIOD), conforme mostrado no código abaixo:
Ao compilá-lo, no entanto, o tamanho do programa aumentará, em relação à versão apresentada na parte I, como pode ser visto a seguir:
Tamanho com uso da SPL
Tamanho sem SPL (versão da Parte I)
Assim, o uso de bibliotecas implicam no aumento dos custos com espaço em memória.
Podemos ir além no uso da SPL, configurando os campos através da declaração/ uso de uma estrutura, como feito na linha 5 e nas linhas 15 a 20 do código abaixo:
Observe também a chamada a funções para habilitar o clock (linha 11) e para setar (linha 27) ou resetar (linha 29) o pino 12 da placa, ligando e desligando o LED correspondente, respectivamente.
Para se ter uma ideia do aumento do espaço proporcionado por estas pequenas modificações, observe o tamanho resultante, após compilar o projeto:
Por fim, podemos usar uma função alternativa para ligar/ desligar o respectivo pino, que é a função ToggleBits, conforme linha 28 do código abaixo:
Ao compilarmos este código, o programa resultante terá o seguinte tamanho:
É notável a redução proporcionada por esta abordagem. Por isso, vale a pena investir tempo estudando o que as bibliotecas nos proporcionam, pois elas podem nos oferecer formas de otimizar o código. E no CoIDE tais informações são proporcionadas pela janela de Help, que, ao selecionar uma biblioteca do repositório, serão exibidos os recursos que esta proporcionam na janela do Help à direita:
No próximo post da série ensinaremos como definir e usar um Timer para implementar uma função de delay, em substituição aos laços for usados para este fim.
Publico este post para apresentar os progressos no trabalho de conclusão de curso do acadêmico Carlos Henrique Kraus, sob minha orientação, que está desenvolvendo um controlador PID de posição de um drone quadcóptero, no contexto do curso de graduação em Engenharia Elétrica da Unisul.
Toda a dinâmica de voo do frame e seu controlador foram desenvolvidos em Python embarcado em uma plataforma Raspberry Pi. O vídeo abaixo apresenta os testes no protótipo do controlador, para seu devido tuning.
Assim que o projeto for evoluindo, divulgaremos maiores informações em posts futuros.
Iniciaremos uma série de posts para guiar os leitores deste blog no desenvolvimento de aplicações com a placa STM32F4Discovery, da ST. Trata-se de uma placa com um microcontrolador STM32F407VG, que é um ARM Cortex-M4 de 32 bits com unidade de ponto flutuante, mais:
1 MB de memória flash;
192 kB de RAM;
clock de 168 MHz;
acelerômetro de 3 eixos;
microfone omnidirecional;
conversor D/A com interface serial e amplificador classe D;
8 LEDs e 2 botões push-button;
conector mini e micro USB.
Para desenvolver aplicações, é necessário uma tool chain, que é a família de ferramentas onde o software que implementa a aplicação é escrito em um computador host para posteriormente ser transferido para a flash do microcontrolador. Para tanto necessitaremos de:
um compilador GCC para ARM embedded, que pode ser baixado aqui;
o driver USB para comunicação com a placa ST-Link, baixado daqui;
Um ambiente integrado de desenvolvimento, no qual optamos pelo CoIDE, dentre outros disponíveis para esta plataforma. Uso a versão 1.7.7, embora já tenhamos versões mais recentes.
Uma vez instalados estes programas no computador host, deve ser realizada a configuração do CoIDE para que ele aponte para o diretório do compilador gcc a ser utilizado, na forma como segue:
A partir desta configuração, criamos um novo projeto:
Após o qual selecionamos Chip:
E depois procuramos por ST > STM32F4x > STM32F407VG
Pronto. Antes de prosseguirmos, devemos fazer com que o debugger aponte para o ST-Link, da forma como segue:
Para um primeiro projeto, selecionaremos do repositório apenas uma biblioteca imprescindível para o desenvolvimento de uma aplicação mínima para a placa, que é a biblioteca CMSIS-Core:
Observe que na estrutura do projeto serão acrescentados dois subdiretórios, o cmsis, necessário para processadores ARM, e o cmsis-boot/startup, para a inicialização da placa e gestão básica dos periféricos.
Abra então o arquivo main.c e substitua pelo fonte abaixo:
Vá então em Project > Build ou pressione F7 e inicie a compilação. Se tudo der certo, teremos no console:
Por fim, conecte a placa em uma porta USB do computador host e vá em Flash > Program Download para carregar o firmware na flash da placa. Neste processo, o LED LD1 próximo a interface Mini USB da placa (CN1) comutará entre verde e vermelho durante a transferência, voltando ao estado vermelho contínuo após esta. Assim, se tudo der certo, o resultado será o LED da placa (LD4) piscando.
Observe que também ligamos um LED Verde externo à placa no pino PD12, mostrando esta possibilidade.
Passamos assim a explicação do código.
Na linha 1 incluímos o arquivo de cabeçalho stm32f4xx.h, que contém os rótulos para os endereços dos periféricos da placa, além de permitir acesso a este através de registros, que são acessados por campos de estruturas (structs) em linguagem C.
Dentro do main, após a declaração da variável inteira index (usada nos laços for das linhas 18 e 20), segue um conjunto de linhas (de 7 a 14) para configuração da porta de entrada e saída GPIO que dá acesso ao Led verde (LD4) da placa. Para um entendimento pleno desta configuração, é importante ter em mãos o manual de referência do microcontrolador.
Na linha 7 se habilita o clock do periférico em questão, a GPIOD, como segue:
Nas linhas 8 e 9 se define o modo da pino 12 da porta GPIOD, o qual está conectado o LED verde, como de saída:
Na linha 10 se define o respectivo pino como saída do tipo push-pull:
Nas linhas 11 e 12 se define a velocidade do pino da porta como High Speed:
Terminando a configuração da Porta D/Pino 12, define-se como operação pull-up:
Concluída esta parte do código, passamos ao que é executado infinitamente, que é o fragmento dentro do laço while(1), a partir da linha 15. Ali, na linha 17 é setado o bit 12 da parte baixa do campo BSRR, o que "liga" o pino 12 da porta GPIOD. Após, é executado um laço for cem mil vezes, apenas para segurar este pino ligado (e consequentemente seu LED) por um certo tempo. Enfim, na linha 19 é setado o bit 12 da parte alta do campo BSRR, o que "desliga" o pino 12 da porta GPIOD, apagando o LED e o deixando assim neste estado pelo tempo da execução do laço for seguinte.
Maiores detalhes:
Foi possível compreender a aplicação e seu código correspondente? Dê um feedback comentando o post abaixo.
No próximo post, apresentaremos uma outra versão para esta mesma aplicação, só que usando a biblioteca específica de cada periférico constituinte da Standard Peripheral Library da placa. Nesse ínterim, aproveite para verificar o entendimento deste código, através das seguintes modificações:
Use valores em hexadecimal para configurar os campos da porta GPIOD, ao invés da notação apresentada;
Altere o código para piscar o LED vermelho (LD5), que está conectado ao pino 14 da porta GPIOD;
