Desenvolvimento de Software Embarcado para um Veículo Aéreo Não Tripulado

Tamanho: px
Começar a partir da página:

Download "Desenvolvimento de Software Embarcado para um Veículo Aéreo Não Tripulado"

Transcrição

1 Universidade Federal de Minas Gerais Escola de Engenharia Curso de Graduação em Engenharia de Controle e Automação Desenvolvimento de Software Embarcado para um Veículo Aéreo Não Tripulado Rafael Tupynambá Dutra Orientador: Prof. Leonardo Antônio Borges Tôrres Engenharia Eletrônica - UFMG Supervisor: Prof. Paulo Henriques Iscold Andrade de Oliveira Engenharia Mecânica - UFMG Belo Horizonte, junho de 2014

2 Monograa Desenvolvimento de Software Embarcado para um Veículo Aéreo Não Tripulado Monograa submetida à banca examinadora designada pelo Colegiado Didático do Curso de Graduação em Engenharia de Controle e Automação da Universidade Federal de Minas Gerais, como parte dos requisitos para aprovação na disciplina Projeto Final de Curso II. Belo Horizonte, junho de 2014

3 i Resumo A UFMG está envolvida, desde 2009, em um projeto chamado Sistema de Mini-VANTs para monitoramento de áreas com minimização de tempo. Uma das atividades contempladas neste projeto é o desenvolvimento de um sistema de controle e navegação para Veículos Aéreos Não Tripulados, VANTs. É nessa área que se insere este Projeto Final de Curso, mais especicamente no desenvolvimento e implementação de um Sistema de Controle Automático de Voo, Automatic Flight Control System (AFCS), o qual é responsável pelas funções de telemetria e telecomando, armazenamento de dados históricos, e cálculo das ações de controle para pilotagem automática da aeronave. O sistema AFCS foi implementado em um dispositivo microprocessado comercial (Computador em Módulo fabricado pela empresa Gumstix, Inc.), que usa um sistema operacional Linux criado a partir de um projeto de software livre (Yocto Project). Além disso, o sistema AFCS foi desenvolvido em linguagem C, e faz uso de uma especicação de protocolo aberto Micro Air Vehicle Link (MAVLink) para formatação das mensagens de comunicação entre subsistemas. Foram implementadas rotinas computacionais responsáveis pelo armazenamento de dados históricos, comunicação com o subsistema de medição e estimação de atitude (chamado de Cabeça Sensora), e cálculo das ações de controle. As funcionalidades desenvolvidas foram testadas em um protótipo do sistema, indicando um bom funcionamento em bancada, bem como a viabilidade de não se empregar um sistema operacional de tempo real nessa aplicação.

4 Abstract UFMG participates, since 2009, in a project called System of Mini-UAVs for eld monitoring in minimal time. One activity encompassed by this project is the development of a control and navigation system for Unmanned Aerial Vehicles, UAVs. This is the target area for this Undergraduate Final Project, more specically the development and implementation of an Automatic Flight Control System (AFCS), which is responsible for telemetry, telecommand, datalogging, and computation of control actions for the autopilot. The AFCS system was implemented in a commercial embedded device (Computer-on-module manufactured by Gumstix, Inc.), which uses a Linux operating system derived from the open source initiative Yocto Project. The system was developed in the C programming language and uses the open source protocol Micro Air Vehicle Link (MAVLink) to format messages communicated between it subsystems. Functions were written to implemented datalogging, communication with the attitude estimation subsystem (called Sensor Head) and computation of control actions. All developed functionality has been tested on the system prototype, exhibiting good results in laboratory, as well as the feasibility of running the application in a non-real-time operating system.

5 Agradecimentos Agradeço ao meu orientador, Leonardo Tôrres, por me guiar nas atividades desenvolvidas, na escrita de toda a monograa e nas correções do texto. Por me mostrar o caminho quando eu estava perdido, sempre com comentários pertinentes. Agradeço ao Dimas Dutra, Rogério Lima e Gabriel Ribeiro, por me introduzirem ao projeto VANT, com bastante prestatividade. E principalmente pela ajuda que me deram sempre que os problemas de hardware e software apareciam, sem a qual esse trabalho não teria sido concluído. Agradeço à Financiadora de Estudos e Projetos, FINEP, pelo apoio - nanceiro. Agradeço à minha família e amigos, por tornarem a minha experiência durante todo o curso muito mais proveitosa. E agradeço ao meu país, Brasil, por me proporcionar uma educação tão rica e valiosa na UFMG.

6 Sumário Resumo Abstract Agradecimentos i ii iii 1 Introdução O Projeto VANT Sistema de Mini-VANTs para monitoramento de áreas com minimização de tempo Sistema de Controle Automático de Voo Objetivos Estrutura geral do texto Revisão Bibliográca Desenvolvimento da Plataforma Aérea na UFMG Desenvolvimento da Cabeça Sensora na UFMG Implementação digital de controladores PID PID em tempo contínuo PID em tempo discreto Escolha do tempo de amostragem para controladores digitais Controladores Lineares por Realimentação de Estados O controlador PID multi-malha Conclusão do capítulo Ambiente de Desenvolvimento do AFCS A arquitetura Gumstix O Projeto Yocto O sistema operacional Linux Desenvolvimento do Linux embarcado As ferramentas de software iv

7 SUMÁRIO v 3.4 Conclusão do capítulo Desenvolvimento do AFCS Estrutura do programa Conguração de Parâmetros Comunicação com a cabeça sensora A interface SPI Os campos das mensagens O protocolo MAVLink Armazenamento de dados históricos As threads escritoras Arquivo sensor Arquivo attitude Arquivo gps Arquivo control Arquivo telecommand Amostragem e Decimação Implementação do controlador Telemetria e telecomando Conclusão do capítulo Resultados Experimentais O protótipo do sistema Teste de coleta de dados Arquivos gerados Sinais medidos Histograma de intervalos de tempo Teste de cálculo de ação de controle Conclusão do capítulo Considerações Finais Visão geral do trabalho realizado Resultados Alcançados Armazenamento de dados históricos Comunicação com a cabeça sensora Cálculo das ações de controle Telemetria e telecomando Testes de funcionamento Outras funcionalidades implementadas Propostas de continuidade

8 SUMÁRIO vi APÊNDICES 55 A Preparação do sistema de compilação cruzada 55 Referências Bibliográcas 57

9 Capítulo 1 Introdução 1.1 O Projeto VANT O desenvolvimento de Veículos Aéreos Não Tripulados (VANTs) tem recebido crescente atenção nos últimos anos. Inicialmente projetados para aplicações militares, eles agora são construídos para as mais variadas nalidades, como o monitoramento de fronteiras, a identicação de focos de incêndio, a inspeção de rodovias e linhas de transmissão, ou até missões de busca e salvamento. Sendo assim, o aprimoramento dessa tecnologia é considerado estratégico para o Brasil. Por exemplo, a Estratégia nacional de Defesa aprovada no decreto n o 6.703, de 18 de dezembro de 2008 defende o avanço dos programas de VANTs, primeiro para vigilância e depois para combate. Ela arma que os VANTs podem oferecer um patamar mais exigente de precisão no monitoramento/controle do território nacional [Presidência da República, 2008]. Os VANTs são aeronaves, de asas xas ou rotativas, reutilizáveis, que não carregam tripulantes e são autônomas ou pilotadas remotamente [Lima, 2013]. A ausência de tripulação reduz o peso e, portanto, as necessidades energéticas da aeronave, além de permitir missões que não seriam suportadas por um ser humano, seja pela longa duração ou por condições de risco. No entanto, para que possam voar autonomamente, é imprescindível que os VANTs sejam equipados com sistemas de pilotagem automática que operem com mínima, ou até mesmo nenhuma, intervenção humana Sistema de Mini-VANTs para monitoramento de áreas com minimização de tempo A Universidade Federal de Minas Gerais (UFMG) possui um longo histórico de pesquisa na área aeronáutica, e vem realizando, desde 2004, projetos de 1

10 1.1 O Projeto VANT 2 desenvolvimento de VANTs [UFMG, 2013]. Essas pesquisas começaram com o projeto SiDeVAAN (Simulação e Desenvolvimento de Veículos Aéreos Autônomos Não-Tripulados), e englobam tanto o desenvolvimento da plataforma aérea quanto a instrumentação e controle embarcados. Um outro destaque foi o AqVS (Aeromodelo que Voa Sozinho), o primeiro mini-vant com lançamento manual totalmente desenvolvido no Brasil [Iscold et al., 2010]. Aproveitando-se da experiência acumulada na área, a UFMG, em parceria com a Universidade Federal do Amazonas (UFAM) e a empresa aeronáutica Aeromot/Fibraer, submeteu uma proposta à FINEP (Financiadora de Estudos e Projetos) em fevereiro de 2010 para o desenvolvimento de um sistema de mini-vants [Iscold et al., 2009]. Este projeto, denominado Sistema de Mini-VANTs para monitoramento de áreas com minimização de tempo, tem por objetivo a criação de uma frota de mini-vants que possam atuar em missões colaborativas para obtenção de imagens do solo. Local de realização do projeto A infraestrutura da UFMG inclui diversos laboratórios de pesquisa e desenvolvimento. A parte aeronáutica do projeto está sendo desenvolvida no Centro de Estudos Aeronáuticos (CEA), que possui uma ocina de 400 m 2 no campus da UFMG, além de um hangar de 1000 m 2 no aeroporto municipal de Conselheiro Lafaiete. Além disso, as áreas de robótica e visão computacional são desenvolvidas no Laboratório de Visão Computacional e Robótica (VERLab) e no Laboratório de Sistemas de Computação e Robótica (CORO). Finalmente, o Laboratório de Modelagem, Análise e Controle de Sistemas Não-Lineares (MACSIN) tem sido utilizado para o desenvolvimento de software embarcado. Atividades contempladas O projeto VANT contempla cinco atividades: 1. Desenvolvimento de uma plataforma aérea. 2. Desenvolvimento de uma estação de solo. 3. Desenvolvimento de um sistema de controle e navegação. 4. Desenvolvimento de estratégias de guiagem e colaboração. 5. Desenvolvimento de sistema de monitoramento de missão. Este Projeto Final de Curso se concentra no item 3, mais especicamente no sistema computacional embarcado na aeronave.

11 1.1 O Projeto VANT 3 Figura 1.1: Diagrama do uxo de sinais de controle Sistema de Controle Automático de Voo A Figura 1.1 mostra os equipamentos básicos e o uxo de sinais usados para o controle do VANT. O Sistema de Controle Automático de Voo, Automatic Flight Control System (AFCS), é o equipamento principal responsável pela pilotagem automática da aeronave, e foi desenvolvido neste trabalho. Ele vai embarcado no VANT, em um dispositivo microprocessado Gumstix. O Gumstix é um computador em miniatura, aproximadamente do tamanho de uma goma de mascar, mas que é capaz de executar um sistema operacional Linux e estabelecer conexões por interfaces seriais, Wi-Fi e Bluetooth [Gumstix, 2013b]. Ele possui um cartão de memória microsd, de 8GB, e se conecta ao modem por meio de uma porta serial RS-232, e à cabeça sensora por uma interface SPI. A cabeça sensora, desenvolvida na UFMG [Lima, 2013], é reponsável por ler as informações de todos os sensores embarcados na aeronave, realizar a fusão sensorial desses dados e fornecer periodicamente as informações de voo ao sistema AFCS. Além disso, ela também envia sinais de comando, em modulação PWM, aos atuadores do avião, para que estes executem as ações de controle do VANT. Quando o voo está no modo automático, essas ações são comandos provenientes do AFCS, mas quando o VANT é controlado em modo manual, elas vem a partir do operador de solo, transmitidas ao receptor de rádio-controle (RC) da aeronave, como ocorre em um aeromodelo convencional. A estação de solo recebe mensagens periódicas com as informações de

12 1.2 Objetivos 4 voo, que vem do sistema AFCS por telemetria, utilizando os modems de comunicação. E ela também pode enviar comandos à aeronave, para serem processados pelo AFCS. Esses comandos podem ser, por exemplo, uma mudança do modo manual/automático ou uma mudança na rota a ser seguida. Pode-se ver, portanto, que o sistema AFCS executa funções essenciais para a integração de todos os equipamentos. A cada ciclo de controle, ele lê as informações de voo atuais (fornecidas pela cabeça sensora), executa o cálculo das ações de controle e envia os sinais de comando de volta à cabeça sensora para que ela acione os atuadores. Além disso, o AFCS envia para a estação de solo relatórios periódicos sobre as condições de voo, e também pode receber comandos provenientes do operador de solo. Por m, ele também é responsável por armazenar as informações históricas de voo, incluindo as ações de controle efetuadas, no cartão de memória do Gumstix. Nesse sentido, o cartão de memória servirá como uma espécie de caixa-preta da aeronave, guardando todos os acontecimentos do voo para que o desempenho do sistema possa ser analisado posteriormente. A consolidação do sistema AFCS permitirá que muitas estratégias de controle, guiagem e navegação do VANT possam ser experimentadas. Já existem muitos trabalhos nessa área, desenvolvidos por estudantes de pós-graduação vinculados ao projeto VANT, que poderão ser testados na aeronave, quando o AFCS estiver concluído [Lima, 2013, Thums, 2012]. 1.2 Objetivos O objetivo principal do trabalho é desenvolver um Sistema de Controle Automático de Voo (AFCS), que opere em um dispositivo Gumstix, integrando todos os equipamentos de controle da aeronave, e que seja capaz de se comunicar adequadamente com a cabeça sensora e com a estação de solo, enquanto provê a capacidade de armazenar os dados históricos de voo. Uma vez que o sistema AFCS esteja operacional, poderão também ser testadas e analisadas diferentes estratégias de controle. A seguir, são detalhados cada um dos objetivos. Cálculo das ações de controle O sistema AFCS implementado deve utilizar as medições fornecidas pela cabeça sensora para calcular as ações de controle adequadas. O controle deve garantir que a aeronave siga as trajetórias de interesse, rejeitando perturbações encontradas no caminho, como mudanças atmosféricas. Aqui, estratégias de controle desenvolvidas em trabalhos anteriores podem ser testa-

13 1.2 Objetivos 5 das [Thums, 2012, Timo, 2013]. Em uma primeira implementação, foi utilizada a estratégia de Gonçalo Thums, baseada em controladores proporcionalintegral-derivativo (PID) [Thums, 2012]. Esse controlador utiliza múltiplas malhas de controle PID com ganhos sintonizados adequadamente. O desempenho do controlador deve ser avaliado, considerando-se os fatores práticos da implementação, como a escolha do intervalo de amostragem. Depois que o sistema estiver bem consolidado, outras estratégias de controle, também desenvolvidas em trabalhos anteriores, poderão ser experimentadas. Comunicação com a cabeça sensora Para que o controle possa ser aplicado, é necessário garantir primeiro uma comunicação com a cabeça sensora, que irá embarcada no veículo. Para tanto, precisam ser implementadas no Gumstix as rotinas computacionais que cuidam da comunicação SPI. O sistema AFCS deve, primeiramente, processar as mensagens enviadas pela cabeça sensora, para atualizar as variáveis que contêm as informações de voo, como velocidade e posicionamento espacial. A seguir, ele é responsável por calcular as ações de controle e enviar uma mensagem que encapsule esses comandos à cabeça sensora, também através da interface SPI. Os formatos e os campos presentes em cada mensagem são denidos tendo em vista os requisitos do sistema (quais variáveis precisam ser transmitidas). Telemetria e telecomando Também é necessário estabelecer a conexão com a estação de solo, para permitir que o VANT seja monitorado à distância em tempo real. Para isso, o Gumstix deve se comunicar com o modem, também embarcado na aeronave, por meio de uma porta serial RS-232. Nessa comunicação, o sistema AFCS precisa enviar periodicamente mensagens que trazem as informações atualizadas de voo. E ele precisa, também, estar pronto para receber comandos da estação de solo e tratá-los corretamente. Para tanto, se faz necessária uma rotina computacional que execute os comandos solicitados pela estação de solo, por exemplo, uma mudança de modo de operação manual/automático. Armazenamento de dados históricos Por m, uma missão essencial do sistema AFCS é o armazenamento dos dados históricos de voo. Esse sistema deve ser implementado de forma a facilitar a análise posterior dos dados. Assim, é necessário garantir que os dados gerados em ensaios de voo distintos possam ser facilmente identicados. E o sistema também deve permitir que os parâmetros de voo possam ser carregados a

14 1.3 Estrutura geral do texto 6 partir de um arquivo de conguração, para facilitar a preparação da aeronave antes de cada ensaio de voo. Testes de funcionamento Cada sistema deve ser testado separadamente quando for concluído e, a seguir, os diferentes sistemas precisam ser testados em conjunto. Os testes efetuados deverão garantir que todos os componentes estejam funcionando adequadamente e que a aeroanve consiga seguir a rota planejada, voando autonomamente. 1.3 Estrutura geral do texto Esta monograa está dividida em 6 capítulos. No Capítulo 1, foi apresentada uma contextualização geral do projeto VANT e, mais especicamente, do AFCS, sistema a ser desenvolvido neste trabalho. Os requisitos desejados para esse sistema foram detalhados nos objetivos do projeto. No Capítulo 2, é apresentada uma revisão dos trabalhos que já foram realizados no projeto VANT da UFMG. Ele servirá para ambientar o leitor ao projeto, preparando-o para os passos que serão tomados. Além disso, é feita uma breve introdução à implementação digital de controladores PID, em que se discutem fatores importantes a serem considerados no projeto de controladores. A seguir, o Capítulo 3 descreve a metodologia utilizada neste projeto. Ele expõe as escolhas de hardware e software e o ambiente utilizado para o desenvolvimento do trabalho. Já o Capítulo 4 relata todo o desenvolvimento do código do AFCS, detalhando a concepção e implementação de cada funcionalidade do sistema. No Capítulo 5, são mostrados alguns resultados obtidos em testes realizados com o protótipo. Por m, no Capítulo 6 é feita uma análise crítica dos objetivos alcançados e do estado atual do sistema, incluindo propostas de continuações para trabalhos posteriores.

15 Capítulo 2 Revisão Bibliográca Neste capítulo, serão introduzidos os trabalhos que já foram realizados no escopo do projeto VANT da UFMG. Além disso, serão apresentadas possíveis técnicas de controle para a aeronave, destacando-se também alguns fatores práticos importantes para sua implementação. 2.1 Desenvolvimento da Plataforma Aérea na UFMG O desenvolvimento da plataforma aérea a ser utilizada no projeto VANT da UFMG se baseia na aeronave AqVS que foi projetada na mesma universidade [Iscold et al., 2010]. O AqVS foi criado para ser um VANT portátil e de baixo custo para missões de reconhecimento de solo. Para tanto, o projeto foi concebido com um número de sensores e atuadores reduzido, mas sem prejuízo para a controlabilidade da aeronave. O AqVS foi contruído a partir de um aeromodelo comercial (modelo Spirit 100 ARF, da empresa Great Planes). A ele foram adicionados um sistema de propulsão elétrica, um compartimento de carga para comportar o hardware de controle e uma câmera de vídeo (Figura 2.1). Esse aeromodelo já completou centenas de vôos autônomos e foi a primeira aeronave brasileira a fazê-lo utilizando tecnologia de controle totalmente nacional. 2.2 Desenvolvimento da Cabeça Sensora na UFMG No escopo do projeto VANT da UFMG, a dissertação de mestrado de 7

16 2.2 Desenvolvimento da Cabeça Sensora na UFMG 8 Figura 2.1: Plataforma aérea do AqVS [Iscold et al., 2010]. Rogério Rodrigues Lima [Lima, 2013] consistiu na criação de uma cabeça sensora para um Veículo Aéreo Não Tripulado. Essa cabeça sensora é o equipamento que gerencia toda a instrumentação embarcada na aeronave. Ela é responsável por receber as leituras de todos os sensores e realizar a fusão sensorial desses dados, estimando parâmetros como os ângulos de atitude (rolamento, arfagem e guinada), a velocidade da aeronave em relação ao ar e sua altitude. Os sensores presentes na aeronave são Acelerômetro triaxial. Girômetro triaxial. Magnetômetro triaxial. Sensor de pressão absoluta (barômetro). Sensor de pressão diferencial. Receptor GPS, que fornece latitude, longitude, altitude, guinada e velocidade em relação ao solo. Rogério Lima usou como base para o projeto da cabeça sensora os requisitos mínimos do VANT AqVS (Tabela 2.1). Eles determinam a faixa de medição mínima necessária para cada sensor.

17 2.2 Desenvolvimento da Cabeça Sensora na UFMG 9 Sensor Acelerômetro Girômetro Magnetômetro Sensor de pressão diferencial Sensor de pressão absoluta Receptor GPS Características mínimas ± 2 g ± 300 / s 10 Ga ± 622 Pa 30 kpa a 120 kpa Taxa de atualização: 5 Hz Protocolo: NMEA Tabela 2.1: Requisitos mínimos para a Cabeça Sensora (adaptado de [Lima, 2013]). Figura 2.2: Ângulos de atitude da aeronave: rolamento (φ), arfagem (θ) e guinada (ψ) [Lima, 2013]. Os ângulos de atitude que precisam ser estimados pela cabeça sensora estão mostrados na Figura 2.2. Eles são os ângulos de rolamento (roll), arfagem (pitch) e guinada (yaw). Os ângulos descrevem a orientação do referencial preso ao corpo, conhecido como ABC, Aircraft Body Coordinate, em relação ao referencial NED, North-East-Down, que é um referencial estático denido localmente em função das direções de latitude e longitude terrestres. Além disso, a cabeça sensora é responsável por enviar sinais de comando modulados em PWM (Pulse-width modulation) para os atuadores. Ela é equipada com uma chave eletrônica que permite o chaveamento entre os modos manual e automático. Em modo automático, os sinais de controle são calculados na própria aeronave, no dispositivo microprocessado Gumstix. Já em modo manual, eles vem do operador de solo, sendo transmitidos à cabeça sensora pelo receptor de rádio-controle do VANT.

18 2.3 Implementação digital de controladores PID 10 Figura 2.3: Atuadores utilizados para controlar a aeronave [Carpenter, 2013]. A Figura 2.3 exibe os atuadores presentes no VANT. Como mostrado na gura, as ações de controle modicam a posição das superfícies de controle, no caso de ailerons, profundores (elevators) e leme (rudder), ou a velocidade de rotação da hélice, no caso do acelerador (throttle). 2.3 Implementação digital de controladores PID PID em tempo contínuo Os controladores PID utilizam três mecanismos de ação: proporcional, integral e derivativo: C(s) = k p C p (s) + k i C i (s) + k d C d (s). Um modelo teórico para a função de transferência de um PID, em tempo contínuo, é dado por C(s) = k p + k i s + k d s. (2.1) Ou, escrita em termos do ganho proporcional k p, tempo integral T i e tempo derivativo T d, ( C(s) = k p ) T i s + T d s. (2.2) Por razões práticas, contudo, a ação derivativa costuma ser acompanhada por um ltro passa-baixas, o que gera uma estrutura da forma ( C(s) = k p T i s + T ) d s. (2.3) αt d s + 1 Esse amortecimento da ação derivativa evita a amplicação de ruído de alta frequência e torna o controlador PID implementável na prática.

19 2.3 Implementação digital de controladores PID PID em tempo discreto A implementação de um controlador em tempo discreto envolve alguns fatores que não estão presentes nos controladores contínuos. Primeiramente, é necessário que se escolha um intervalo de amostragem T s. Essa parte do projeto será discutida mais detalhadamente na Seção 2.4. Outra decisão importante de projeto é como implementar o PID em tempo discreto. Há diferentes escolhas possíveis: pode-se fazer o projeto todo em tempo discreto ou então projetar um controlador contínuo primeiro e depois transformá-lo em discreto. Neste último caso, essa transformação pode se dar através da transformada bilinear (método de Tustin) ou da transformada retangular, por exemplo [Phillips and Nagle, 2007]. A transformada retangular consiste no uso da aproximação s 1 z 1 T s, (2.4) enquanto que a transformada bilinear é descrita pela aproximação s 2 1 z 1. (2.5) T s 1 + z 1 Pode-se utilizar, também, uma combinação desses métodos. Por exemplo, o uso da transformada retangular para a parte derivativa pode evitar a amplicação de ruído de alta frequência, enquanto que o uso da transformada bilinear para a parte proporcional e integral permite uma representação mais el de todo o espectro de frequências dessas ações. Outra consideração importante para o controle em tempo discreto é a robustez numérica do controlador. Em sistemas digitais, a precisão da representação numérica é nita e erros de arredondamento podem causar problemas ao controlador. Se ele for implementado por meio de uma equação de diferenças, pequenos erros nos coecientes da função de transferência podem deslocar os zeros e pólos do controlador, alterando a dinâmica de controle. Uma outra abordagem possível seria a implementação em espaço de estados, em que uma matriz de controle mais robusta numericamente (idealmente uma matriz diagonal) pode ser obtida. Por m, outro requisito importante ao projeto é que se evite o windup da ação integral. Essa situação se caracteriza quando o erro (diferença entre a referência e o valor medido da variável de processo P V ) se mantém com grande magnitude por um longo período de tempo até que a variável P V atinja a referência. Isso faz com que o erro acumulado na ação integral continue atuando, levando o sistema a um overshoot (sobressinal) acentuado.

20 2.4 Escolha do tempo de amostragem para controladores digitais 12 Essa situação indesejada ocorre frequentemente quando saturações existentes no sistema físico impedem que a ação de controle atue além de certos limites. Uma estratégia anti-windup é uma estratégia projetada para evitar este problema. Por exemplo, pode-se desabilitar a ação integral enquanto P V não estiver em uma faixa de valores controlável ou utilizar um saturador para impedir que a ação integral acumule além de um determinado limite. 2.4 Escolha do tempo de amostragem para controladores digitais Uma decisão crucial para o projeto em tempo discreto é a escolha do intervalo de amostragem T s. Muitas vezes, esse intervalo tem que ser modicado algumas vezes durante o projeto do controlador até que se obtenha um resultado em malha fechada satisfatório. Por um lado, é essencial garantir que T s seja pequeno o suciente para representar bem a dinâmica natural da planta, em malha aberta, e a dinâmica de controle, em malha fechada. Entretanto, um valor de T s muito pequeno também não é vantajoso, por intensicar o efeito dos ruídos de alta frequência, além de exigir maior uso do processador. Será descrito, aqui, o método de denição de T s utilizado no Projeto Final de Curso de Gabriel Timo, que se baseou na resposta em frequência para sistemas MIMO e uso do valor singular máximo [Timo, 2013]. Primeiramente, como a operação de amostragem gera réplicas do espectro original da planta centradas em múltiplos inteiros de 2π T s, é necessário que a frequência de amostragem seja maior que o dobro da banda de passagem da planta, para que não ocorra aliasing [Ogata, 1987]. E, como a planta a ser controlada é uma aeronave, que possui múltiplas entradas e múltiplas saídas, o problemas se torna a obtenção da banda de passagem de um sistema MIMO (Multiple Inputs, Multiple Outputs ). Para tanto, foi utilizado o diagrama de valores singulares. Esse diagrama fornece o maior valor singular da matriz de transferência da planta F (jω) para cada valor de frequência ω [Skogestad and Postlethwaite, 1996]. O maior valor singular indica a máxima amplicação do sistema (razão entre as normas de suas saídas e de suas entradas) em uma determinada frequência. A partir do diagrama de valores singulares, é possível determinar a banda de passagem da planta. No entanto, para a escolha do intervalo de amostragem, a caracterização em malha aberta do sistema não é suciente. É preciso levar em conta, também, a desempenho requerido em malha fechada, anal o controlador

21 2.5 Controladores Lineares por Realimentação de Estados 13 normalmente torna a resposta mais rápida, aumentando a faixa de passagem. Assim, deve-se estimar qual será a banda de passagem de malha fechada f cm, para que se possa escolher um intervalo de amostragem menor que 2π 2f cm. 2.5 Controladores Lineares por Realimentação de Estados O aluno Gabriel Reis Timo desenvolveu, em seu Projeto Final de Curso, estratégias de controle para VANTs baseadas na síntese de controladores digitais [Timo, 2013]. Esse trabalho abordou especicamente o controle da dinâmica longitudinal da aeronave, com o objetivo de manter a altitude e a velocidade do VANT constantes em um voo reto nivelado. Essas estratégias de controle multivariável foram testadas em um modelo não linear com três graus de liberdade do VANT Aerosonde. Foram levados em conta aspectos práticos importantes, como a estrutura incremental do controlador, a estratégia anti-windup e a seleção do período de amostragem. Primeiramente, o modelo não linear do VANT foi utilizado para se obter um modelo da dinâmica longitudinal linearizado em torno do ponto de operação. Este ponto é a condição de equilíbrio em que o VANT se mantém nivelado e com velocidade constante. Nessa linearização, buscou-se obter uma representação do sistema em espaço de estados. A seguir, esse modelo em tempo contínuo foi discretizado, para que o controlador pudesse ser sintetizado via abordagem direta. Para tanto, o intervalo de amostragem foi denido, como relatado na Seção 2.4. Os controladores foram sintetizados via realimentação linear de estados. Essa técnica, aplicada a sistemas representados em espaço de estados, consiste na realimentação do vetor de estados de forma a posicionar adequadamente os pólos do sistema em malha fechada. Três metodologias de controle foram utilizadas: LQR com ação integral, H 2 e H. A metodologia LQR busca minimizar uma função de desempenho, enquanto que as metodologias H 2 e H buscam a minimização de uma norma do sistema em malha fechada. Todas as três geram um controle ótimo, no sentido de que produzem o melhor controlador possível para uma determinada função de custo. Os resultados do trabalho de Gabriel Timo foram promissores e mostraram que as técnicas abordadas podem ser utilizadas no VANT que está sendo desenvolvido na UFMG. Esses métodos de síntese são capazes de sintetizar diretamente controladores digitais, uma vantagem em relação aos controladores contínuos que são posteriormente digitalizados.

22 2.6 O controlador PID multi-malha O controlador PID multi-malha A dissertação de mestrado de Gonçalo Daniel Thums abordou a estratégia de controle PID multi-malha para VANTs [Thums, 2012]. A estratégia multimalha utilizada é constituída por várias malhas de controle em cascata que atuam sobre o sistema. Ao contrário do trabalho de Gabriel Timo, nesta dissertação abordou-se o problema de controle como um todo, incluindo a dinâmica longitudinal e a dinâmica látero-direcional da aeronave. O projeto de controladores PID consiste essencialmente na sintonia dos ganhos proporcional, integral e derivativo, uma vez que a estrutura do controlador já está denida. Sintonizar cada um dos PIDs de forma independente é o método mais simples, mas não leva em consideração os acoplamentos (muitas vezes não lineares) existentes entre as malhas. O método de sintonia proposto por Gonçalo Thums utiliza um algoritmo genético com funções de custo devidamente escolhidas. Nessa técnica, é possível considerar o sistema como um todo para a sintonia das malhas, de forma que todos os acoplamentos e não-linearidades sejam considerados. O trabalho de Gonçalo Thums conseguiu obter um método para sintonia de PID robusta multi-malha que se mostrou ecaz nas simulações realizadas. Dessa forma, essa metodologia de controle poderá ser utilizada no projeto VANT em desenvolvimento na UFMG. 2.7 Conclusão do capítulo Neste capítulo, foram apresentados os trabalhos já realizados no escopo do Projeto VANT da UFMG. Foram discutidas a parte aeronáutica do projeto (plataforma aérea), a estrutura de instrumentação e fusão sensorial dos dados (cabeça sensora) e o projeto de controladores, em que várias estratégias podem ser utilizadas. A seguir, serão exibidas as ferramentas e ambientes de desenvolvimento que serão utilizadas no escopo especíco deste trabalho, para o projeto do sistema AFCS.

23 Capítulo 3 Ambiente de Desenvolvimento do AFCS Este capítulo apresenta o ambiente de desenvolvimento do AFCS, detalhando as ferramentas de hardware e software selecionadas para o trabalho. 3.1 A arquitetura Gumstix O dispositivo utilizado para implementar o Sistema de Controle Automático de Voo, Automatic Flight Control System (AFCS) da aeronave é o Gumstix. O Gumstix é um equipamento da classe computer-on-module (COM), que poderia ser categorizado entre um computador completo e um microcontrolador. Este computador embarcado é montado em um único circuito impresso, que inclui um microprocessador com memória RAM e controladores de entrada/saída. Ele não inclui, no entanto, conectores padrão para periféricos, como conexões USB e Ethernet. Para estabelecer essas conexões, a solução mais simples é a utilização de uma placa de expansão compatível. A Figura 3.1 mostra o Gumstix Overo Fire com seus componentes. Ele inclui um chip de gerenciamento de energia, um processador da Texas Instruments, um slot para entrada de cartão microsd e conexões para câmera, antenas e módulos de Bluetooth e Wi-Fi [Gumstix, 2013a]. O processador utilizado no Gumstix Overo Fire é o OMAP3530, baseado na arquitetura OMAP 3, com CPU ARM Cortex-A8 [Texas Instruments, 2013]. Ele foi projetado para prover alta qualidade de processamento gráco, suportar sistemas operacionais de alto nível e incluir técnicas de gerenciamento de energia. Na Figura 3.2, está uma placa de expansão Tobi, que fornece conectores padrão para a alimentação de 5 V, conexão USB, Ethernet, display LCD touchscreen e áudio estéreo. 15

24 3.1 A arquitetura Gumstix 16 Figura 3.1: Dispositivo Gumstix e seus componentes. Figura 3.2: Placa de expansão Tobi.

25 3.2 O Projeto Yocto 17 Várias ditribuições de Linux podem ser instaladas em um COM Gumstix, mas as populares são as desenvolvidas pelo Yocto Project. 3.2 O Projeto Yocto O sistema operacional Linux O Linux é um sistema operacional construído sobre o modelo de desenvolvimento e distribuição livre de código-fonte [Linux Foundation, 2012]. O kernel (núcleo) do sistema operacional é o que dene o Linux, servindo de base para o desenvolvimento de diversas distribuições diferentes do sistema operacional. Linus Torvalds publicou a primeira versão do kernel do Linux em 1991 e ainda participa até hoje de seu desenvolvimento, junto com um grande grupo de programadores que colaboram voluntariamente com o projeto. O Linux tem uma losoa de projeto baseada no sistema Unix, criado na Bell Labs. Essa losoa defende que o sistema operacional deve prover ferramentas simples, cada uma executando uma função limitada e bem denida, com a comunicação baseada em um sistema de arquivos unicado. Além disso, o Linux adere ao padrão POSIX, que dene interfaces de programação para garantir portabilidade de código entre diferentes sistemas operacionais. Devido à sua robustez e qualidade, o Linux é o sistema operacional mais utilizado em servidores e supercomputadores. Ele também foi mais portado para diferentes arquiteturas e plataformas de hardware do que qualquer outro sistema operacional, estando presente em diversos sistemas embarcados, como telefones celulares, tablets, roteadores, televisores e video-games Desenvolvimento do Linux embarcado Especicamente para a arquitetura Gumstix, há várias distribuições de Linux disponíveis. Os dispositivos do modelo Gumstix Overo já são vendidos com uma distribuição de Linux, chamada de Ångström, pré-instalada na memória ash [Gumstix, 2013a]. Essa distribuição, desenvolvida no projeto OpenEmbedded, é escolhida como padrão por ser a mais testada e estável para o Gumstix Overo. No entanto, essa distribuição não está mais sendo atualizada, já que o desenvolvimento de sistemas operacionais para o Gumstix está passando por uma transição do OpenEmbedded clássico para o Yocto Project. Assim, as distribuições Ångström são estáveis, mas só utilizam versões do kernel do Linux até a 2.6, não incluindo as melhorias de desempenho obtidas nas versões 3.2 e superiores. O Yocto Project (Projeto Yocto) é um projeto colaborativo de código

26 3.3 As ferramentas de software 18 aberto que provê ferramentas e métodos para a criação de sistemas Linux personalizados para produtos embarcados, independentemente da arquitetura [Yocto Project, 2013]. Ele foi anunciado pela Linux Foundation em 2010 e, em 2011, se uniu com o OpenEmbedded, que também possuía objetivos similares. O Yocto Project disponibiliza um repositório com o código-fonte e as instruções necessárias para a compilação das imagens do sistema operacional para o Gumstix [Gumstix Yocto Project, 2013]. Assim, qualquer usuário pode obter as versões mais atualizadas do sistema operacional, além de poder customizá-lo para suas necessidades especícas. O Yocto Project foi escolhido para gerar a distribuição Linux utilizada nesse trabalho, pelo alto desempenho e possibilidade de personalização do sistema operacional. As ditribuições geradas pelo Yocto Project não são Linux de tempo-real, mas acreditamos que elas conseguirão satisfazer os requisitos do projeto. O período de amostragem do controlador será denido posteriormente, como discutido na Seção 2.4. Após essa etapa de projeto, vericaremos experimentalmente se o Linux comum (que não é de tempo-real) é capaz de executar as ações de controle adequadamente com esse período. É importante destacar que o Linux embarcado é um sistema operacional completo, que possui as funcionalidades presentes no Linux de desktop. Assim, muitas facilidades usadas pelos desenvolvedores de Linux podem ser aplicadas diretamente sobre os sistemas embarcados. Por exemplo, o recebimento e envio de mensagens para outros dispositivos pode ser implementado como operações de leitura e escrita sobre arquivos, seguindo a losoa Unix. 3.3 As ferramentas de software Essa seção expõe as ferramentas de software utilizadas no projeto VANT, além de trazer motivações para o uso dessas ferramentas. A linguagem de programação escolhida para o projeto foi a linguagem C, por permitir alta eciência no gasto de memória e tempo de execução. GLib A biblioteca GLib fornece os blocos básicos de construção para outras bibliotecas e aplicações escritas em C [The GNOME Project, 2012]. Ela provê o sistema de objetos usados no famoso ambiente de janelas GNOME, além de um grande conjunto de funções para manipulação de strings e outras estruturas de dados comuns. No projeto VANT, a GLib será utilizada para simplicar a implementação de estruturas de dados básicas, como arrays e

27 3.3 As ferramentas de software 19 tabelas hash. libconfig A libconfig é uma biblioteca simples e compacta para o processamento de arquivos de conguração [Lindner, 2012]. Ela permite que aplicações escritas em C leiam e escrevam dados em arquivos de conguração, que são salvos em memória. No escopo do projeto VANT, ela será utilizada para que o sistema AFCS carregue os parâmetros do ensaio de voo a partir dos arquivos de conguração. Assim, parâmetros como o período de amostragem utilizado poderão ser congurados de forma simples e segura. CMake Para facilitar o processo de compilação, será utilizado o programa de geração automatizada de código-objeto CMake. Este programa gerencia o processo de compilação de software, gerando makeles nativos que podem ser usados com o ambiente de desenvolvimento escolhido pelo programador [Kitware, 2013]. Ele é capaz de gerenciar aplicações que dependem de múltiplas bibliotecas, sendo responsável por encontrá-las e estabelecer os links corretos para a compilação. Assim, o CMake facilitará a compilação e teste do software desenvolvido no projeto VANT. Git O Git é um dos gerenciadores de versões mais usados para projetos de programação. Originalmente criado por Linus Torvalds para realizar o controle de versões do kernel do Linux, ele se tornou um projeto separado, que já possui 36% de adoção entre desenvolvedores de software prossionais [Torvalds et al., 2013]. Sua losoa é de que cada repositório local de código deve guardar o histórico completo das versões, permitindo rastreamento da evolução do código, sem a necessidade de conexão com um servidor central. O Git foi concebido para ser um gerenciador de código-fonte rápido e eciente, mas com todas as funcionalidades necessárias para utilização em projetos grandes, como o kernel do Linux. No projeto VANT, ele será útil para facilitar o rastreamento das mudanças efetuadas em cada versão e o compartilhamento do código desenvolvido com outros colaboradores. Compilação Cruzada O sistema AFCS será gerado para o Gumstix a partir de compilação cruzada. Neste método, o código do programa é compilado em uma plataforma

28 3.4 Conclusão do capítulo 20 (ambiente de desenvolvimento) para ser executado em outra (ambiente alvo). No caso do sistema AFCS, o ambiente de desenvolvimento será um computador pessoal com um sistema operacional Linux de uso geral, enquanto que o ambiente alvo é o dispositivo Gumstix, que utiliza Linux embarcado. A compilação cruzada permite usar para a compilação os recursos de um sistema mais completo, um computador pessoal que não tem a limitação de memória e hardware dos dispositivos embarcados. Assim, o compilador ca mais eciente e pode ser usado até para compilar toda a imagem do sistema operacional do Gumstix. Após ser gerada no computador pessoal, essa imagem só precisa ser transferida para o Gumstix e ele estará pronto para utilizar o sistema operacional gerado. O protocolo de comunicação MAVLink Para estabelecer a conexão entre o Gumstix e a cabeça sensora, o protocolo de comunicação escolhido foi o Micro Air Vehicle Link, MAVLink. Este protocolo foi projetado para ser bem leve, próprio para comunicação em pequenos veículos aéreos, com mensagens que contêm apenas um cabeçalho [QGroundControl, 2013]. Sua comunicação é baseada na técnica de marshalling, que consiste em transformar em mensagens as representações em memória dos objetos em um programa. Assim, ela permite a transmissão de structs (estruturas) da linguagem C com facilidade. O protocolo inclui um código de detecção de erros pelo algoritmo CRC, Cyclic Redundancy Check [Wolfram Research, 2013]. Esse código provê con- abilidade ao sistema, detectando possíveis erros de transmissão. O MA- VLink foi escolhido para o projeto VANT por ser um protocolo simples, mas que apresenta as funcionalidades necessárias, como a facilidade de transmissão de estruturas em C e a robustez contra erros de comunicação. 3.4 Conclusão do capítulo Este capítulo exibiu os componentes de hardware e software utilizados para o desenvolvimento do sistema AFCS. A seguir, este desenvolvimento será detalhado e serão apresentados os resultados obtidos.

29 Capítulo 4 Desenvolvimento do AFCS Este capítulo relata o desenvolvimento do software do AFCS, desde a concepção inicial do sistema até a estrutura nal do programa. Serão exibidos os subsistemas presentes e seus detalhes de projeto. O código do projeto está disponível em [Dutra and Dutra, 2014a]. Lá também se encontram as instruções para instalação de bibliotecas utilizadas, compilação do sistema e execução para testes. O Apêndice A traz mais informações sobre a preparação do sistema operacional e do ambiente de compilação cruzada. 4.1 Estrutura do programa A Figura 4.1 mostra a estrutura do software do AFCS. O programa é dividido em threads, para permitir maior modularidade de código e independência entre os diferentes subsistemas. As threads são diferentes linhas de execução, mas que compartilham a mesma área de memória. A thread principal cuida da conguração inicial de todo o sistema, além de ser responsável pela comunicação com o modem para operações de telemetria e telecomando. No início da execução do programa, ela lê os parâmetros que serão usados no experimento atual a partir do arquivo de conguração. A seguir, ela cria as threads de controle e de datalog e passa a realizar as operações de comunicação com o modem. Ela também é responsável por salvar em um arquivo todos os comandos que forem recebidos a partir do modem de comunicação. A thread de datalog tem a função de salvar o estado atual do sistema em arquivos de dados históricos para diagnóstico futuro. Ela opera em conjunto com quatro threads escritoras, responsáveis pelas operações de escrita nos arquivos. A thread de datalog possui um temporizador próprio, que dispara 21

30 4.1 Estrutura do programa 22 Figura 4.1: Estrutura de threads e uxo de dados do AFCS. periodicamente para que uma nova amostra de dados seja copiada. Por m, a thread mais crítica de todo o sistema é a de controle. Ela é responsável pela leitura de dados da cabeça sensora, cálculo das ações de controle e envio das mesmas de volta à cabeça sensora. A thread de controle executa essas tarefas periodicamente, a cada disparo do temporizador de controle. Seu funcionamento é primordial para a estabilidade do sistema e o temporizador utilizado precisa trabalhar com bastante precisão. O programa inclui funções que permitem denir a política de escalonamento e a prioridade de cada thread. A política de escalonamento pode ser denida como SCHED_RR (Round Robin), para que as threads do programa sejam consideradas de tempo-real, com prioridade sobre os demais processos em execução. Além disso, é possível estabelecer, por exemplo, uma prioridade menor para as threads de datalog, que não são críticas durante a operação do sistema. Durante a realização de um experimento, as threads de controle e de datalog são chamadas a executar periodicamente, quando seus temporizadores disparam. As quatro threads escritoras são acordadas em uma frequência menor, para que escrevam os dados nos arquivos em disco. E a thread principal é executada sempre que houver novas mensagens a serem recebidas ou

31 4.2 Conguração de Parâmetros 23 transmitidas pelo modem. 4.2 Conguração de Parâmetros O sistema AFCS foi projetado para permitir que vários parâmetros possam ser denidos a partir de arquivos de conguração. Essa abordagem facilita o uso do sistema, já que para modicar os parâmetros basta editar arquivos de texto, não sendo necessário recompilar todo o projeto. Os arquivos pdva-pilot.cfg e mav_params.cfg localizados no diretório denido em PDVA_CONFIG_DIR são usados para denir parâmetros gerais do sistema e parâmetros que podem ser alterados por telemetria, respectivamente. A biblioteca libconfig é utilizada para ler e escrever os arquivos de conguração. Os parâmetros que podem ser congurados estão listados a seguir: uint8_t sysid; ///< MAVLink System ID time_t control_timer_period_s; ///< Period of control timer (s) long control_timer_period_ns; ///< Period of control timer (ns) time_t datalog_timer_period_s; ///< Period of datalog timer (s) long datalog_timer_period_ns; ///< Period of datalog timer (ns) int control_id; ///< Index of the default controller uint32_t spi_speed_hz; ///< Frequency of transmission for SPI interface (Hz) int datalog_write_ms; ///< Period between write operations on datalog files (ms) int downsample_<filename>; ///< Downsample factor int filter_<filename>_n; ///< Order of digital filter double filter_<filename>_a_<index>; ///< Denominator coefficient a_i double filter_<filename>_b_<index>; ///< Numerator coefficient b_i double param_<variable>_gain; ///< Variable gain double param_<variable>_offset; ///< Variable offset onde <FILENAME> é o nome do arquivo de datalog (sensor, attitude, gps, control ou telecommand) e <INDEX> é um inteiro que representa o índice no polinômio da função de transferência e <VARIABLE> é o nome da variável cujo ganho e polarização estão sendo congurados. O signicado desses parâmetros é descrito nas próximas seções.

32 4.3 Comunicação com a cabeça sensora 24 Figura 4.2: Diagrama da comunicação SPI [Byte Paradigm, 2014]. 4.3 Comunicação com a cabeça sensora Nesta seção serão apresentados os detalhes da comunicação entre o AFCS e a cabeça sensora. Do ponto de vista lógico, a estrutura das mensagens é denida pelo protocolo MAVLink. E no nível físico, a comunicação se dá através da interface SPI, que provê duas linhas para comunicação bidirecional A interface SPI Conforme exposto na Subseção 1.1.2, o sistema AFCS, que é executado no microcontrolador Gumstix, se comunica com a cabeça sensora através de uma interface SPI. A Figura 4.2 mostra o uxo de sinais dessa interface. O mestre é responsável por iniciar a comunicação, ativando o sinal slave select (SS). O mestre também gera o clock (SCLK), que determina os instantes exatos de transmissão e recebimento de bits. O parâmetro spi_speed_hz é usado para denir a frequência da transmissão. A comunicação é full-duplex, o que signica que bits podem ser enviados e recebidos ao mesmo tempo. A linha MOSI (master output, slave input ) transmite sinais do mestre para o escravo, enquanto que a linha MISO (master input, slave output) transmite do escravo para o mestre. No projeto VANT, o Gumstix é usado como mestre na comunicação SPI e a cabeça sensora como escrava. Como os dois dispositivos trabalham com níveis de tensão diferentes (3,3 V para o DSP da cabeça sensora e 1,8 V para o Gumstix) uma placa de ajuste de tensão foi desenvolvida por Rogério Lima para permitir a conexão [Lima, 2013]. Alguns problemas de hardware foram encontrados durante o desenvolvimento do projeto, principalmente no ajuste do nível de tensão do sinal MISO. Após uma longa pesquisa pela solução, foi descoberta a causa do problema, que era um defeito da placa de expansão Chestnut43 do Gumstix. Essa placa, usada anteriormente, possuía uma conexão do pino MISO com o controlador de touchscreen ADS7846, que acabava atuando como uma carga sobre a linha MISO. Depois que uma outra placa de expansão foi usada (a placa

33 4.3 Comunicação com a cabeça sensora 25 Summit), o problema não voltou a ocorrer. Isso demonstrou que o problema não era uma falha do circuito projetado por Rogério Lima, mas sim de uma placa comercial utilizada no protótipo. Como o sistema nal não utilizará essa placa de expansão comercial, seu projeto não teve de ser modicado. No código do Gumstix, a interface SPI é utilizada através do gerenciador de dispositivo SPIdev [Linux Kernel Organization, 2014]. Ele é usado para acessar o arquivo de dispositivo /dev/spidev1.1 e pode enviar bytes através da função write, receber bytes através da função read ou fazer uma comunicação full-duplex utilizando a chamada de sistema ioctl. Dessa forma, a comunicação SPI é implementada através de operações comuns sobre arquivos do Linux. O Apêndice A descreve como o sistema operacional foi congurado para permitir essa comunicação SPI Os campos das mensagens Para permitir a conexão entre o Gumstix e a cabeça sensora, um formato comum para as mensagens enviadas e recebidas teve que ser estabelecido. O formato mais atualizado encontra-se em [Dutra and Dutra, 2014b]. Ele foi obtido a partir de uma adaptação dos formatos utilizados anteriormente para o Gumstix e para a cabeça sensora, que eram diferentes. Neste processo de denição dos campos das mensagens, foi levada em conta a importância de os valores crus (não processados) dos sensores poderem ser utilizados para diagnóstico. Eles são necessários para que a análise do sistema possa distinguir falhas devidas aos sensores de falhas ocorridas após o processamento dos dados. Assim, foi denido que as medidas dos sensores deveriam ser transmitidas na mensagem sem nenhum tipo de conversão. Já no Gumstix, esses valores crus passam por um processo de calibração e conversão de unidades. Essa conversão pode ser usada, por exemplo, para obter os valores das variáveis no Sistema Internacional de Unidades (SI). Ou então, também é possível deixar essas variáveis sem nenhuma conversão. Por padrão, os valores de ganho são denidos como 1 e as polarizações como 0 para deixar os valores inalterados. Caso outros valores devam ser utilizados, os ganhos e polarizações são denidos nos arquivos de conguração. Essa estratégia permite também realizar o processo reverso e determinar os dados originais dos sensores a partir das medidas convertidas. Após o processo de conversão, os valores são usados para o cálculos das ações de controle e são armazenados nos arquivos de dados históricos. Além dos dados crus de sensores, a cabeça sensora também envia alguns dados já processados. Por exemplo, ela usa as medidas de pressão estática e dinâmica para estimar a altitude da aeronave e sua velocidade em relação ao ar. Neste caso, foi denido que os valores estimados pela cabeça sensora

34 4.3 Comunicação com a cabeça sensora 26 já devem ser transmitidos ao Gumstix com unidades de medida adequadas e bem denidas, após todas as calibrações e conversões serem realizadas pela cabeça sensora. O formato das mensagens transmitidas da cabeça sensora para o Gumstix é mostrado a seguir: typedef struct mavlink_sensor_head_data_t { int32_t time_gps_ms; ///< Timestamp (milliseconds) int32_t lat_gps; ///< GPS latitude (deg), multiplied by 1e7 int32_t lon_gps; ///< GPS longitude (deg), multiplied by 1e7 int32_t alt_gps; ///< GPS altitude above MSL (millimeters) float att_est[3]; ///< Estimated attitude angles (roll, pitch, yaw in radians) int32_t altitude; ///< Altitude above sea level (cm) int16_t hdg_gps; ///< GPS heading (milliradians) uint16_t speed_gps; ///< GPS groundspeed (cm/s) int16_t pos_fix_gps; ///< GPS Position Fix Status int16_t nosv_gps; ///< GPS Number of Satellites Used int16_t hdop_gps; ///< GPS Horizontal Dilution of Precision int16_t acc[3]; ///< Accelerometer readings (raw) int16_t gyro[3]; ///< Gyrometer readings (raw) int16_t gyro_temp; ///< Gyrometer temperature (raw) int16_t mag[3]; ///< Magnetometer readings (raw) int16_t dyn_press; ///< Dynamic pressure (raw) int16_t stat_press; ///< Static pressure (raw) uint16_t airspeed; ///< Airspeed (cm/s) } mavlink_sensor_head_data_t; E as mensagens de comando transmitidas do Gumstix para a cabeça sensora tem o formato seguinte: typedef struct mavlink_sensor_head_command_t { uint16_t aileron; ///< Aileron command, 0 to uint16_t elevator; ///< Elevator command, 0 to uint16_t throttle; ///< Throttle command, 0 to uint16_t rudder; ///< Rudder command, 0 to } mavlink_sensor_head_command_t; O protocolo MAVLink Uma vez denidas as estruturas (structs) da linguagem C que devem ser transmitidas, foi utilizado o protocolo MAVLink para encapsulá-las em mensagens. A Tabela 4.1 mostra o os campos do pacote MAVLink. No início da mensagem, há um cabeçalho de 6 bytes e, no nal, são incluídos dois bytes

35 4.3 Comunicação com a cabeça sensora 27 Índice Tamanho Conteúdo (bytes) 0 1 Início do pacote (valor 0xFE) 1 1 Tamanho da informação transmitida na mensagem (n) 2 1 Número sequencial do pacote 3 1 ID do sistema que envia a mensagem 4 1 ID do componente que envia a mensagem (ex: IMU ou piloto automático) 5 1 ID da mensagem (ex: mensagem de dados ou mensagem de comandos) 6 n Informação transmitida na mensagem n Checksum (CRC) Tabela 4.1: Formato da mensagem no protocolo MAVLink [QGroundControl, 2013]. de vericação calculados pelo algoritmo CRC (Cyclic Redundancy Check ). As informações das variáveis de interesse são inseridas nos n bytes de dados da mensagem. Para utilizar o protocolo MAVLink, primeiramente são denidas as variáveis dos structs que serão transmitidas, em um arquivo XML (Extensible Markup Language). A denição atualizada pode ser encontrada em [Dutra and Dutra, 2014b]. A seguir, são gerados os cabeçalhos da linguagem C contendo o algoritmo que codica e decodica as mensagens, através da ferramenta mavgen [Meier, 2012]. Assim, a biblioteca do MAVLink ca pronta para ser usada, já incluindo as mensagens especícas do projeto do AFCS. No Gumstix, seu uso é bem simples e as funções do MAVLink puderam ser implementadas diretamente. Já na cabeça sensora, foi necessária uma adaptação. Ao preparar o código da cabeça sensora, foram constatados alguns problemas devidos ao fato de ela possuir uma arquitetura de hardware não usual. No DSP utilizado pela cabeça sensora, o tamanho dos bytes é 16 bits, enquanto que o tamanho padrão dos bytes é de 8 bits. Assim, foi necessário reescrever o código da cabeça sensora que implementa o protocolo MAVLink para levar isso em consideração. Principalmente as funções que envolvem cópia ou manipulações de bytes, como a função de cálculo do checksum. Após essa adaptação, o protocolo pôde ser usado pela cabeça sensora. Mas é importante denir as variáveis transmitidas sempre com tamanhos múltiplos de 16 bits. Assim, garantimos que essas variáveis

36 4.4 Armazenamento de dados históricos 28 estarão sempre alinhadas no padrão de bytes da cabeça sensora. 4.4 Armazenamento de dados históricos As metas principais estabelecidas para o armazenamento de dados históricos foram: 1. Permitir que todos os dados recebidos da cabeça sensora e todos os comandos transmitidos a ela possam ser salvos para diagnóstivo futuro. 2. Permitir que os diferentes tipos de dados sejam salvos em arquivos diferentes. 3. Permitir a operação em um modo simplicado, em que apenas parte das informações sejam armazenadas (a ser utilizado quando já se tiver bastante conança no sistema como um todo). 4. Permitir que arquivos diferentes usem taxas de amostragem diferentes, mas com a mesma base de tempo. 5. Criar pastas diferentes para cada experimento/ensaio, para melhor organização. 6. Permitir que os parâmetros de conguração relevantes (como a taxa de amostragem e o fator de decimação de cada arquivo) possam ser carregados a partir dos arquivos de conguração. Para tanto, utilizamos a seguinte implementação. O diretório utilizado para o armazenamento de dados históricos é denido em DATALOG_DIR. Nele, é criado o arquivo last_experiment, que armazena o número do último ensaio realizado. Para cada ensaio, é criado um diretório cujo nome corresponde ao número do ensaio. Por exemplo, os dados do primeiro experimento são armazenados no diretório 00/. Neste diretório, são criados os arquivos sensor, attitude, gps, control e telecommand, descritos nas próximas seções. São criados no máximo 100 diretórios, com uma estrutura circular. Assim, se forem realizados mais de 100 experimentos, os experimentos mais antigos serão sobrescritos. Essa estrutura evita que o cartão de memória do Gumstix que completamente cheio caso muitos experimentos sejam realizados. As medidas dos sensores são transmitidas pela cabeça sensora sem nenhum tipo de processamento. Mas, antes do cálculo das ações de controle,

37 4.4 Armazenamento de dados históricos 29 eles podem ser convertidos de acordo com as escalas de calibração desses instrumentos. O ganho e polarização utilizados para cada uma das variáveis transmitidas é denido no arquivo de conguração. Assim, por exemplo, o código: param_acc_0_gain = 0.038; param_acc_0_offset = 0.0; param_stat_press_gain = 100.0; param_stat_press_offset = 1.0e5; no arquivo de conguração deniria um ganho de 0,038 e uma polarização nula para a variável acc[0] (aceleração do eixo x), e um ganho 100 com polarização 1, para a variável stat_press (pressão estática). Quando não estão denidos nos arquivos de conguração, esses parâmetros assumem valores padrão com ganho 1 e polarização 0. Após a conversão, todas as variáveis cam armazenadas no formato double (ponto utuante de dupla precisão). E é nesse formato que elas usadas pelo controlador e escritas nos arquivos de dados históricos, de forma a facilitar a análise posterior desses dados. Já as ações de controle transmitidas à cabeça sensora são enviadas em uma escala numérica de para comandar os atuadores. E elas são armazenadas nesse mesmo formato no arquivo control As threads escritoras Para implementação das rotinas de datalog, a primeira estratégia utilizada foi a de simplesmente efetuar a escrita dos arquivos dentro do código de tratamento do disparo do temporizador. Assim, a cada disparo, uma amostra nova dos valores das variáveis é tomada e essa amostra é escrita diretamente nos arquivos. Essa estratégia funcionou bem em testes que utilizavam um período de datalog de 0,5 s. Mas, para períodos menores, o programa não funcionava, pois a thread de datalog não conseguia realizar a operação de escrita em arquivos em um intervalo mais curto. Para contornar essa situação problemática, foram criadas quatro threads especícas para realizar as operações de escrita em cada arquivo. Quando ocorre um disparo do temporizador, a thread de datalog trata esse disparo, mas escreve as novas amostras das variáveis em buers locais, sem nenhuma operação sobre o sistema de arquivos. Assim, ela consegue tranquilamente processar cada nova amostra dentro do intervalo de datalog, que pode ser tão pequeno quanto 0,02 s. Já as threads escritoras cam responsáveis por escrever nos arquivos esses dados que foram acumulados nos buers locais.

38 4.4 Armazenamento de dados históricos 30 Para tanto, elas utilizam um período de escrita denido pela variável datalog_write_ms. Se, por exemplo, o período de escrita for denido como 5 s e o período de datalog for 0,02 s, as operações de escrita só ocorrem a cada 250 disparos do temporizador. Nesse momento, as threads escritoras lêem essas 250 amostras do buer e as escrevem nos arquivos. Como a escrita é feita por threads independentes da thread de datalog, esta última continua funcionando normalmente e processando cada amostra enquanto as operações de escrita são realizadas. É utilizado um buer duplo para cada arquivo, de forma que a thread de datalog vai preenchendo um dos buers enquanto o outro está sendo escrito no arquivo. Nenhuma amostra é perdida, já que todas as amostras acumuladas durante o período datalog_write_ms são escritas pelas threads escritoras. Utilizar um período de escrita maior, da ordem de alguns segundos, é uma boa estratégia devido ao custo extra (overhead) incorrido pela operações de escrita em arquivos. Esse custo faz com que poucas operações de escrita operando sobre massas de dados maiores sejam mais ecientes do que muitas operações de escrita pequenas. Alguns testes práticos mostraram o sistema não conseguiu armazenar corretamente os dados nos arquivos quando a frequência do datalog era alta e os períodos de escrita eram menores que 2 s. Mas para o período de escrita de 5 s não ocorreu nenhum problema. Já uma desvantagem de um período de escrita grande é a possibilidade de perda de dados no caso de uma pane do sistema. Caso o sistema pare de funcionar em algum instante, é possível que os dados coletados durante os últimos 5 s ainda não tenham sido escritos em disco e não possam ser recuperados Arquivo sensor O arquivo sensor é utilizado para armazenar os dados não processados de sensores. Ele inclui as leituras do acelerômetro, girômetro, magnetômetro, a medida de temperatura do girômetro e as medições de pressão estática e dinâmica. Todos os dados representam valores obtidos diretamente dos sensores, sem nenhum processamento feito pela cabeça sensora. Seu formato detalhado é mostrado a seguir. double t; ///< Timestamp (s) double acc[3]; ///< Accelerometer readings (m/s^2) double gyro[3]; ///< Gyrometer readings (rad/s) double gyro_temp; ///< Gyrometer temperature (K) double mag[3]; ///< Magnetometer readings (T) double dyn_press; ///< Dynamic pressure (Pa)

39 4.4 Armazenamento de dados históricos 31 double stat_press; ///< Static pressure (Pa) Arquivo attitude O arquivo attitude armazena as informações que são geradas pela cabeça sensora a partir do processamento dos dados dos sensores. Elas incluem os ângulos de atitude (rolamento, arfagem e guinada), a velocidade em relação ao ar e a altitude da aeronave. Esses valores são estimados a partir da fusão sensorial dos dados dos sensores. Além disso, ao arquivo attitude foram adicionadas a variável seq, que guarda o número sequencial da última mensagem recebida da cabeça sensora, e a variável ok, que indica se a última mensagem foi recebida com sucesso ou não. Essas variáveis, que são úteis para vericar mensagens perdidas, só precisavam ser salvas em um dos arquivos de datalog. Foi escolhido o arquivo attitude para essa nalidade. Seu formato detalhado é mostrado a seguir. double t; ///< Timestamp (s) uint8_t seq; ///< Last message sequential number uint8_t ok; ///< Last message received successfully double att_est[3]; ///< Estimated attitude angles (roll, pitch, yaw in radians) double airspeed; ///< Airspeed (m/s) double altitude; ///< Altitude above sea level (m) Arquivo gps O arquivo gps armazena todos os dados obtidos a partir do GPS: horário UTC, latitude, longitude, altitude, ângulo de proa (heading), velocidade em relação ao solo, status de posição, número de satélites visíveis e diluição horizontal de precisão. Seu formato é: double t; ///< Timestamp (s) double time_gps; ///< GPS UTC time (s) double lat_gps; ///< GPS latitude (deg) double lon_gps; ///< GPS longitude (deg) double alt_gps; ///< GPS altitude above MSL (m) double hdg_gps; ///< GPS heading (radians) double speed_gps; ///< GPS groundspeed (m/s) double pos_fix_gps; ///< GPS Position Fix Status double nosv_gps; ///< GPS Number of Satellites Used double hdop_gps; ///< GPS Horizontal Dilution of Precision

40 4.4 Armazenamento de dados históricos Arquivo control O arquivo control armazena os comandos que são enviados do Gumstix para a cabeça sensora, para operar os atuadores. Ele inclui os comandos de ailerons, profundores, acelerador e leme. O formato utilizado é double t; ///< Timestamp (s) uint16_t aileron; ///< Aileron command, 0 to uint16_t elevator; ///< Elevator command, 0 to uint16_t throttle; ///< Throttle command, 0 to uint16_t rudder; ///< Rudder command, 0 to Arquivo telecommand Além dos arquivos listados acima, o arquivo telecommand é criado para salvar todos os comandos recebidos pelo VANT a partir do modem de comunicação. Esses comandos podem ser a conguração de parâmetros do voo ou uma mudança entre os modos manual e automático, por exemplo. Essa funcionalidade será implementada no futuro, quando o modem de comunicação for incorporado ao protótipo do sistema Amostragem e Decimação O período base de amostragem para o armazenamento de dados históricos é denido pelos parâmetros time_t datalog_timer_period_s; ///< Period of datalog timer (s) long datalog_timer_period_ns; ///< Period of datalog timer (ns) A soma dos valores desses parâmetros dene o período do temporizador de datalog. A cada disparo deste temporizador, a thread de datalog executa uma rotina de tratamento do temporizador. Nessa rotina, ela copia os valores atuais das variáveis recebidas e enviadas para a cabeça sensora e salva esses valores nos arquivos de armazenamento. Além disso, é possível utilizar períodos de amostragem diferentes para cada arquivo atráves do processo de decimação. Os parâmetros de conguração int downsample_<filename>; ///< Downsample factor int filter_<filename>_n; ///< Order of digital filter double filter_<filename>_a_<index>; ///< Denominator coefficient a_i

41 4.4 Armazenamento de dados históricos 33 double filter_<filename>_b_<index>; ///< Numerator coefficient b_i são utilizados para esse m. Por exemplo, se utilizarmos downsample_gps = 4; o arquivo gps terá um fator de decimação 4 e só será escrito a cada 4 disparos do temporizador. Caso algum fator de decimação seja denido como 0, o arquivo correspondente não será escrito. Para que a decimação não leve a um falseamento (aliasing) dos dados, deve ser utilizado um ltro anti-aliasing sobre as medidas. O código foi projetado de forma que um ltro diferente pudesse ser utilizado para cada arquivo, para ser aplicado sobre todas as variáveis armazenadas nele. A função de transferência do ltro digital é dada por F (z) = b 0 + b 1 z b n z n a 0 + a 1 z a n z n, que corresponde a uma equação de diferenças a 0 y[k] + a 1 y[k 1] + + a n y[k n] = b 0 x[k] + b 1 x[k 1] + + b n x[k n]. Assim, por exemplo, usando os parâmetros filter_gps_n = 1; filter_gps_a_0 = 1.0; filter_gps_a_1 = -0.1; filter_gps_b_0 = 0.9; filter_gps_b_1 = 0.0; denimos para o arquivo gps um ltro digital de ordem 1 dado pela função de transferência e equação de diferenças F (z) = 0,9 1 0,1z 1 y[k] 0,1y[k 1] = 0,9x[k]. Quando os parâmetros não estão denidos nos arquivos de conguração, eles assumem seus valores padrão. Se o período do temporizador de datalog não for denido, ele será igual ao período do temporizador de controle. Se os fatores de decimação não forem denidos, eles terão o valor 1 (os arquivos serão escritos em todos os disparos do temporizador). E se os parâmetros do

42 4.5 Implementação do controlador 34 ltro digital não forem denidos, o ltro não será utilizado. Mais precisamente, os parâmetros serão congurados de forma que o ltro tenha ordem 0 e função de transferência F (z) = 1 (equação de diferenças y[k] = x[k]). 4.5 Implementação do controlador Os parâmetros time_t control_timer_period_s; ///< Period of control timer (s) long control_timer_period_ns; ///< Period of control timer (ns) são usados para denir o período do temporizador de controle. A soma desses parâmetros dene o período entre duas amostras consecutivas tomadas pelo controlador digital. A cada disparo do temporizador, é feita a comunicação SPI com a cabeça sensora, em que são recebidos os valores atuais das variáveis e são transmitidos os valores das ações de controle calculadas na amostra anterior. Como preparação para o cálculo das ações do controle, os valores das variáveis recebidas pela cabeça sensora passam pelo processo de conversão, em que são transformadas para o formato double, podendo também ser calibradas para unidades diferentes. A seguir, a função calculate_control[control_id]() é chamada para calcular as ações de controle. O índice control_id é um inteiro que indica qual controlador será utilizado. Seu valor inicial é denido por meio do parâmetro de conguração de mesmo nome. Essa função tem acesso a todas as variáveis, já convertidas para o formato double, e pode utilizá-las como quiser. Isso traz bastante exibilidade à estrutura do controlador, que pode ser projetada livremente. Após os cálculos feitos pelo controlador, as ações de controle são geradas em uma escala de 0 a 1. A seguir, esses valores são convertidos à escala numérica usada para acionamento via PWM. Os ganhos e polarizações usados para as ações de controle também são denidos nos arquivos de conguração. O código foi projetado para que vários controladores diferentes pudessem ser utilizados, sem a necessidade de se recompilar o programa. Para tanto, o programador só precisa escrever as funções executadas por cada controlador e, a seguir, inserir um apontador para essas funções no vetor calculate_control. Assim, ao invés de se chamar cada função por nome, a thread de controle só precisa chamar calculate_control[i] com o índice adequado. Essa estrutura de código permitirá, inclusive, que o controlador seja escolhido durante a execução do programa. Assim, por exemplo, pode ser criada

43 4.6 Telemetria e telecomando 35 uma mensagem de telecomando da estação de solo que determine qual controlador deve ser usado a partir desse instante. Uma simples mudança na variável control_id já dene qual função será chamada para o cálculo das ações de controle. Basicamente, o que todas essas funções de cálculo de ações de controle devem ter em comum é a interface. Ou seja, todas elas são funções que podem usar as mesmas variáveis como parâmetros de entrada e devem produzir as mesmas ações de controle como parâmetros de saída. Assim, o programador responsável pela implementação de um novo controlador só precisa garantir que a sua função utilize a interface especicada. Atualmente, há apenas um controlador implementado no sistema. Ele é baseado no trabalho de Gonçalo Thums [Thums, 2012] e utiliza uma estratégia multi-malha PID. Todas as variáveis importantes para o controlador estão protegidas por um mutex (objeto de exclusão mútua). Isso garante que todas as vezes que elas forem acessadas, estarão sendo acessadas por uma única thread, evitando condições de corrida em caso de acesso concorrente. A thread de controle só chama a função calculate_control[control_id]() depois de estar em posse desse mutex, para garantir que o acesso exclusivo às variáveis do controlador. E quando a thread de datalog ou a thread de telemetria precisam copiar os valores dessas variáveis, elas são obrigadas a usar funções de acesso que também trancam o objeto mutex. 4.6 Telemetria e telecomando A funcionalidade de comunicação com a estação de solo através de um modem não pôde ser desenvolvida por uma limitação de tempo. A comunicação com a cabeça sensora demandou um grande tempo de desenvolvimento, além de apresentar vários problemas de hardware de software que atrasaram a sua implementação. Assim, sobrou pouco tempo para desenvolver as funções de telemetria e telecomando. Já existem algumas dessas funções preparadas no código do AFCS. A funcionalidade de decimação das variáveis para envio por telemetria já está inserida no código, assim como funções para envio dos valores atuais das variáveis, leitura e escrita dos parâmetros de conguração. No entanto, essas funções ainda não foram testadas na prática. O modem de comunicação está sendo incorporado ao protótipo do sistema. Quando essa conexão e conguração inicial for concluída, será possível testar e desenvolver as funcionalidades de comunicação com a estação de solo.

44 4.7 Conclusão do capítulo Conclusão do capítulo Neste capítulo, foi detalhado o projeto de software do AFCS, incluindo todas as funcionalidades implementadas. A seguir, serão exibidos testes experimentais feitos sobre o sistema.

45 Capítulo 5 Resultados Experimentais 5.1 O protótipo do sistema Neste capítulo, são exibidos os resultados de alguns testes práticos realizados com o AFCS e a cabeça sensora. O protótipo utilizado para os testes foi adaptado a partir da montagem feita por Rogério Lima [Lima, 2013]. A placa de expansão Summit foi utilizada para o Gumstix, no lugar da placa Chestnut43, que apresentava um problema para a tranmissão SPI pelo carregamento da porta MISO. A Figura 5.1 mostra os componentes do protótipo. O módulo de instrumentação é responsável por obter os dados dos sensores de pressão estática e dinâmica, além dos dados da Unidade de Medição Inercial (IMU, Inertial Measurement Unit), que inclui acelerômetros, girômetros e magnetômetros. A antena GPS recebe os sinais dos satélites, transmitindo seus dados para o receptor GPS, que utiliza o protocolo NMEA para a formatação das sentenças que serão enviadas à cabeça sensora. A cabeça sensora é executada no TMS320F28335, um processador digital de sinais da Texas Instruments. Uma placa externa apresenta um LED indicativo, que pisca a cada ciclo do programa da cabeça sensora. Um conversor de tensão é usado para permitir a comunicação por interface SPI entre a cabeça sensora (3,3 V) e a Gumstix (1,8 V). O Gumstix utilizado é o modelo Overo Fire, com a placa de expansão Summit. Por m, a bateria LiPo pode alimentar o sistema para a execução de testes em ambientes externos. Com esse protótipo, foram realizados testes em que o AFCS e a cabeça sensora se comunicam. A cabeça sensora transmite os dados obtidos diretamente dos sensores, além de informações calculadas através da fusão sensorial. Com esses dados, o Gumstix pode calcular as ações de controle e 37

46 5.1 O protótipo do sistema 38 Figura 5.1: Protótipo do sistema, incluindo o AFCS (no dispositivo Gumstix) e a Cabeça Sensora (no DSP TMS320F28335). [Lima, 2013]. Figura adaptada de

47 5.2 Teste de coleta de dados 39 transmitir os comandos de volta à cabeça sensora. Devido à funcionalidade de armazenamento de dados históricos do Gumstix, todas as variáveis enviadas e recebidas cam armazenadas em arquivos no cartão de memória do Gumstix, que podem ser acessados posteriormente. 5.2 Teste de coleta de dados Neste primeiro teste, o objetivo principal era vericar a comunicação correta entre a cabeça sensora e o Gumstix, além do armazenamento de dados históricos. Como visto na Figura 5.1, o módulo de instrumentação possui uma Unidade de Medição Inercial (IMU) cujos eixos se mantêm xos em relação à aeronave. Ainda na Figura 5.1, o eixo x aponta para cima, o eixo y para a direita e o eixo z entra na gura, perpendicularmente à mesa. Na aeronave, o posicionamento dos eixos segue o referencial ABC, Aircraft Body Coordinate, que foi mostrado na Figura 2.2. Durante este experimento, foram efetuadas rotações em torno dos eixos y e x. Entre duas rotações seguidas, o protótipo foi deixado em repouso por aproximadamente 20 s, para permitir melhor visualização dos dados. O experimento utilizou um período T s = 0,02 s entre cada amostra, tanto para o controlador quanto para o armazenamento de dados. O eixo z inicialmente apontava verticalmente para baixo, na direção da gravidade terrestre. Então, uma rotação de ângulo π em torno do eixo y fez 2 com que o eixo x apontasse para cima. O movimento foi desfeito por uma rotação de ângulo π em torno do eixo y. A seguir, uma nova rotação de 2 ângulo π em torno do eixo y fez com que o eixo x apontasse para baixo. 2 E o movimento foi novamente desfeito para retornar o protótipo à condição inicial. O mesmo processo se repetiu ao redor do eixo x. Uma rotação de ângulo π, seguida por duas rotações de π e mais uma rotação de π em torno do eixo x foram efetuadas. A primeira dessas rotações levou o eixo y a apontar para cima e a terceira o levou a apontar para baixo Arquivos gerados Após o experimento, os arquivos de dados históricos do Gumstix foram copiados para o computador para análise. O tamanho conjunto dos quatro arquivos sensor, attitude, gps, control foi de 3,02 MiB para um experimento de 173,76 s. Isso demonstra que são gastos aproximadamente 365 bytes para armazenar cada amostra (as amostras foram feitas em períodos de 20 ms). O cartão

48 5.2 Teste de coleta de dados 40 Figura 5.2: Gráco das acelerações em função do tempo. de memória do Gumstix é de 8 GB, o que, nessa taxa de amostragem, representaria uma capacidade de armazenamento de 121 horas de experimento. Assim, ele é capaz de armazenar 100 experimentos com duração máxima de 1 hora cada, o que é suciente para a aplicação. No máximo 100 experimentos são armazenados em cada instante no cartão, sendo que experimentos novos sobrescrevem os mais antigos Sinais medidos Foi utilizado o programa MATLAB para a obtenção de grácos e estatísticas [MathWorks, Inc., 2014a]. Os dados dos acelerômetros, girômetros e magnetômetros foram multiplicados por um fator de escala para que fossem obtidos valores em unidades SI. No entanto, a polarização das medidas não foi corrigida, apenas um ganho foi aplicado. A Figura 5.2 mostra as acelerações nos três eixos em função do tempo. Os sinais estão condizentes com o experimento realizado, pois cada eixo apresenta valores signicativos de aceleração somente nos instantes em que aponta verticalmente para baixo ou para cima. Nesse instantes, a acelaração vale aproximadamente ±10 m/s 2, com sinal denido pela direção do eixo (paralela ou antiparalela à gravidade terrestre). Já na Figura 5.3, são mostradas as leituras dos girômetros. Percebe-se que o gráco está perfeitamente condizente com a descrição do experimento. Cada rotação de π em torno de um certo eixo se apresenta como um pulso 2 positivo no sinal do girômetro. E as rotações de ângulo π se apresentam 2 como pulsos negativos. A área de cada um desses pulsos corresponde ao ângulo nal de giro. Logo, as áreas devem valer aproximadamente π. 2

49 5.2 Teste de coleta de dados 41 Figura 5.3: Gráco das velocidades angulares em função do tempo. A seguir, a Figura 5.4 mostra as leituras dos magnetômetros. É possível ver que os resultados também são compatíveis com o experimento. Podese ver que a componente do campo magnético de maior intensidade é a que aponta para a direção inicial do eixo y. Em segundo lugar, a componente mais intensa é a que está na diração inicial do eixo z. E, por m, a componente menos intensa é a que tem a direção inicial do eixo x. Assim, o campo magnético no local do experimento era da forma (γ,α, β), com α > β > γ > 0, em que os eixos são denidos pela posição inicial dos eixos do protótipo. Já a Figura 5.5 mostra os ângulos de atitude estimados pela cabeça sensora. Notamos que, nos instantes em que o ângulo de arfagem estava próximo a π ou π, os ângulos de rolamento e guinada não estavam bem denidos e 2 2 apresentaram muitas oscilações. Também foram observadas muitas oscilações nos instantes em que o rolamento deveria valer π e π. Isso provavelmente 2 2 se deve a um problema na estimação dos ângulos pela cabeça sensora. Durante esse experimento, o GPS ainda não tinha conseguido obter os sinais dos satélites, então a cabeça sensora não tinha acesso aos dados do GPS, o que pode ter prejudicado a fusão sensorial dos dados. A seguir, as Figuras 5.6, 5.7 e 5.8 mostram valores de outros sensores: temperatura do girômetro, pressão dinâmica e pressão estática. Elas apresentam valores não processados, que são os valores retornados diretamente pelos sensores, no formato de inteiros de 16 bits Histograma de intervalos de tempo Em seguida, ainda utilizando dados do mesmo experimento, foi feita uma análise dos intervalos de tempo entre as amostras. Durante o ensaio, para

50 5.2 Teste de coleta de dados 42 Figura 5.4: Gráco dos campos magnéticos em função do tempo. Figura 5.5: Gráco dos ângulos de atitude em função do tempo.

51 5.2 Teste de coleta de dados 43 Figura 5.6: Gráco da medição de temperatura do girômetro em função do tempo. Figura 5.7: Gráco da pressão dinâmica em função do tempo.

52 5.3 Teste de cálculo de ação de controle 44 Figura 5.8: Gráco da pressão estática em função do tempo. cada mensagem recebida da cabeça sensora foi armazenado o instante de tempo imediatamente após o recebimento. E essas marcações de tempo foram copiadas pela thread de datalog para serem armazenadas nos arquivos. Foi detectado que, em 1,1% das amostras foram perdidas por erros na transmissão SPI. Isso fez com que a diferença (intervalo entre amostras) fosse 0 em um instante e aproximadamente 2T s = 0,04 s no instante seguinte. A Figura 5.9 mostra o gráco dos intervalos de tempo entre amostras consecutivas. Esse intervalo se mantém próximo de 0,02 s, exceto quando as amostras são perdidas. Eliminando-se essas amostras repetidas, os intervalos de tempo entre amostras caram bem próximos do valor esperado. De fato, em mais de 97% da vezes o tamanho do intervalo cou na faixa (0,02000 ± 0,00015) s. A Figura 5.10 mostra o histograma desses intervalos de tempo. Os resultados obtidos sugerem que o Gumstix conseguiu manter uma boa precisão e previsibilidade nos intervalos de controle, mesmo executando seu código em um sistema que não é de tempo real. 5.3 Teste de cálculo de ação de controle Foi realizado também um teste de funcionamento para se conrmar o cálculo correto das ações de controle. O Gumstix utiliza as informações fornecidas pela cabeça sensora para calcular os comandos que serão enviados a ela para acionar os atuadores. O controlador implementado atualmente pelo Gumstix foi escrito por Dimas Dutra, com base no projeto de Gonçalo Thums [Thums, 2012]. A

53 5.3 Teste de cálculo de ação de controle 45 Figura 5.9: Gráco do intervalo de tempo entre amostras consecutivas. Figura 5.10: Histograma do intervalo de tempo entre amostras consecutivas.

EA-291 Pilotos Automáticos para VANTs. Piloto Automático para Veículo Aéreo Não-Tripulado (VANT) MicroPilot

EA-291 Pilotos Automáticos para VANTs. Piloto Automático para Veículo Aéreo Não-Tripulado (VANT) MicroPilot Comando-geral de Tecnologia Aeroespacial Instituto Tecnológico de Aeronáutica EA-291 Pilotos Automáticos para VANTs Piloto Automático para Veículo Aéreo Não-Tripulado (VANT) MicroPilot Luis Mauro de Vargas

Leia mais

Curso de Tecnologia em Sistemas Eletrônicos MATRIZ CURRICULAR. Módulo I /Semestre 1 Carga horária total: 400h

Curso de Tecnologia em Sistemas Eletrônicos MATRIZ CURRICULAR. Módulo I /Semestre 1 Carga horária total: 400h Curso de Tecnologia em Sistemas Eletrônicos CÂMPUS FLORIANÓPOLIS MATRIZ CURRICULAR Módulo I /Semestre 1 Carga horária total: 400h Circuitos Elétricos 1 80 Lógica Combinacional 80 Física Geral 80 Comunicação

Leia mais

EXPERIÊNCIA 4: IMPLEMENTAÇÃO DE UM CRONÔMETRO

EXPERIÊNCIA 4: IMPLEMENTAÇÃO DE UM CRONÔMETRO EXPERIÊNCIA 4: IMPLEMENTAÇÃO DE UM CRONÔMETRO Autores: Prof. Dr. André Riyuiti Hirakawa, Prof. Dr. Carlos Eduardo Cugnasca e Prof. Dr. Paulo Sérgio Cugnasca Versão 1.0-05/2005 1. OBJETIVO Esta experiência

Leia mais

PIBIC/PIBITI/IC Jr Relatório das Atividades de Pesquisa 23ª SEMIC

PIBIC/PIBITI/IC Jr Relatório das Atividades de Pesquisa 23ª SEMIC ATIVIDADES EXECUTADAS PELO BOLSISTA / VOLUNTÁRIO DADOS DE IDENTIFICAÇÃO: Do bolsista: Nome: Carlos Vinícius Machado Caldeira Curso: Engenharia Elétrica com ênfase em Sistemas Eletrônicos Período de vigência

Leia mais

2.1 NesC Seguem alguns dos principais desafios impostos à linguagem NesC:

2.1 NesC Seguem alguns dos principais desafios impostos à linguagem NesC: 2 TinyOS e NesC O framework de programação mais utilizado em redes de sensores sem fio é composto pelo sistema operacional TinyOS [11] e pela linguagem de programação NesC [12]. A linguagem NesC foi definida

Leia mais

Subsistemas de E/S Device Driver Controlador de E/S Dispositivos de E/S Discos Magnéticos Desempenho, redundância, proteção de dados

Subsistemas de E/S Device Driver Controlador de E/S Dispositivos de E/S Discos Magnéticos Desempenho, redundância, proteção de dados Sistemas Operacionais Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios Gerência de Dispositivos Subsistemas de E/S Device Driver Controlador de E/S

Leia mais

Sis i te t mas a O perac a i c o i nai a s um p ouco c d a a h is i tó t ria i. a... SO His i t s ó t r ó ic i o

Sis i te t mas a O perac a i c o i nai a s um p ouco c d a a h is i tó t ria i. a... SO His i t s ó t r ó ic i o Sistemas Operacionais um pouco da história... - Evolução dos SO s através do tempo - Novas técnicas não são assimiladas simultaneamente por todos - Década de 40, não existia SO - O programador é o faz

Leia mais

VEÍCULO AÉREO NÃO TRIPULADO Demonstração e apresentação do voo de um veículo de multirotor.

VEÍCULO AÉREO NÃO TRIPULADO Demonstração e apresentação do voo de um veículo de multirotor. ESTADO DE MATO GROSSO ESCOLA ESTADUAL DESEMBARGADOR MILTON ARMANDO POMPEU DE BARROS ENSINO MÉDIO INTEGRADO EDUCAÇÃO PROFISSIONAL TÉCNICO EM INFORMÁTICA JADER JOSÉ DA SILVA WESLEY MARQUES DE OLIVEIRA VEÍCULO

Leia mais

Comparação entre Arduino, FPGA, ASIC e SoC

Comparação entre Arduino, FPGA, ASIC e SoC Comparação entre Arduino, FPGA, ASIC e SoC Prof. Odilson Tadeu Valle Instituto Federal de Santa Catarina IFSC Campus São José odilson@ifsc.edu.br 1/22 Conteúdo programático 1 Arduino 2 FPGA 3 ASIC 4 SoC

Leia mais

CURSO DE PÓS-GRADUAÇÃO LATO SENSU AUTOMAÇÃO INDUSTRIAL E SISTEMAS DE CONTROLE - MECATRÔNICA

CURSO DE PÓS-GRADUAÇÃO LATO SENSU AUTOMAÇÃO INDUSTRIAL E SISTEMAS DE CONTROLE - MECATRÔNICA CURSO DE PÓS-GRADUAÇÃO LATO SENSU AUTOMAÇÃO INDUSTRIAL E SISTEMAS DE CONTROLE - MECATRÔNICA Motivação O setor industrial experimentou nas últimas duas décadas um extraordinário avanço devido ao aumento

Leia mais

Circuitos Lógicos. Prof. Odilson Tadeu Valle

Circuitos Lógicos. Prof. Odilson Tadeu Valle Introdução Circuitos Lógicos Prof. Odilson Tadeu Valle Instituto Federal de Santa Catarina IFSC Campus São José odilson@ifsc.edu.br 1/44 Sumário 1 Introdução 2 Analógico Versus Digital 3 Bits, Bytes e

Leia mais

07/06/2015. Outras características importantes em Microprocessadores/Microcontroladores SEL-433 APLICAÇÕES DE MICROPROCESSADORES I

07/06/2015. Outras características importantes em Microprocessadores/Microcontroladores SEL-433 APLICAÇÕES DE MICROPROCESSADORES I SEL-433 APLICAÇÕES DE MICROPROCESSADORES I Redução de Potência de Operação As versões CHMOS (89C51, 89S52, etc ) da família MCS-51 possuem dois modos de controle de redução de potência de operação do chip.

Leia mais

Sistemas Operacionais. Entrada/Saída

Sistemas Operacionais. Entrada/Saída Sistemas Operacionais Entrada/Saída Atualizado em 28/02/2014 Como ocorre a comunicação de E/S Aplicação Operações de E/S Chamadas de Sistema S.O. Subsistema de E/S Núcleo (Kernel) Drivers HARDWARE Controladoras

Leia mais

Sistemas de Entrada e Saída

Sistemas de Entrada e Saída Sistemas de Entrada e Saída Eduardo Ferreira dos Santos Ciência da Computação Centro Universitário de Brasília UniCEUB Maio, 2016 1 / 33 Sumário 1 Dispositivos de E/S 2 Interrupções 3 Software de E/S 2

Leia mais

1 RESUMO. Palavras-chave: Controle, encoders, motor CC. 2 INTRODUÇÃO

1 RESUMO. Palavras-chave: Controle, encoders, motor CC. 2 INTRODUÇÃO 1 RESUMO Na sociedade moderna se tornou cada vez mais presente e necessário meios de controlar dispositivos levando em consideração precisões maiores e perdas menores. Em diversos cenários o controle de

Leia mais

Sistema de entrada e saída (E/S)- Módulos de E/S; tipos de operações de E/S

Sistema de entrada e saída (E/S)- Módulos de E/S; tipos de operações de E/S Sistema de entrada e saída (E/S)- Módulos de E/S; tipos de operações de E/S Explicitar aos alunos os modelos de entrada e saída em um computador e quais barramentos se aplicam a cada componente: memória,

Leia mais

Sistema de Aquisição de Dados em Tempo Real Utilizando Software Livre e Rede Ethernet para Laboratório de Controle

Sistema de Aquisição de Dados em Tempo Real Utilizando Software Livre e Rede Ethernet para Laboratório de Controle Sistema de Aquisição de Dados em Tempo Real Utilizando Software Livre e Rede Ethernet para Laboratório de Controle Elaine de Mattos Silva1 José Paulo Vilela Soares da Cunha1 Orlando Bernardo Filho2 1 Departamento

Leia mais

KIT DIDÁTICO PIC-2377

KIT DIDÁTICO PIC-2377 KIT DIDÁTICO PIC-77... Módulo PIC-77 Recursos internos da MCU Encapsulamento DIP40. 5 instruções (RISC). pinos de I/O configuráveis. 56 bytes de EEPROM para dados de 8 bits. 8k de memória flash para o

Leia mais

VEÍCULOS AÉREOS NÃO TRIPULADOS (VANT) NA AGRICULTURA E MEIO AMBIENTE

VEÍCULOS AÉREOS NÃO TRIPULADOS (VANT) NA AGRICULTURA E MEIO AMBIENTE VEÍCULOS AÉREOS NÃO TRIPULADOS (VANT) NA AGRICULTURA E MEIO AMBIENTE Daniel Gomes Eng. Agrônomo, Dr., PqC do Polo Regional Leste Paulista/APTA daniel.gomes@apta.sp.gov.br Um Veículo Aéreo Não Tripulado

Leia mais

Evento: XXV SEMINÁRIO DE INICIAÇÃO CIENTÍFICA

Evento: XXV SEMINÁRIO DE INICIAÇÃO CIENTÍFICA ESTUDO E DESENVOLVIMENTO DE UM SISTEMA DE ARMAZENAMENTO DE DADOS EM UM CARTÃO SD PARA UMA REDE DE SENSORES INTELIGENTES APLICADO NA AGRICULTURA 1 STUDY AND DEVELOPMENT OF A DATA STORAGE SYSTEM ON AN SD

Leia mais

Retrofitting de Robôs. Walter Fetter Lages Universidade Federal do Rio Grande do Sul Departamento de Engenharia Elétrica

Retrofitting de Robôs. Walter Fetter Lages Universidade Federal do Rio Grande do Sul Departamento de Engenharia Elétrica Retrofitting de Robôs Walter Fetter Lages Universidade Federal do Rio Grande do Sul Departamento de Engenharia Elétrica fetter@eletro.ufrgs.br 1 Introdução Robôs Manipuladores Robôs Industriais Móveis

Leia mais

Organização e Arquitetura de Computadores I

Organização e Arquitetura de Computadores I Organização e Arquitetura de Computadores I Entrada e Saída Slide 1 Entrada e Saída Dispositivos Externos E/S Programada Organização e Arquitetura de Computadores I Sumário E/S Dirigida por Interrupção

Leia mais

HARDWARE DOS RELÉS NUMÉRICOS

HARDWARE DOS RELÉS NUMÉRICOS HARDWARE DOS RELÉS NUMÉRICOS 1. CONSIDERAÇÕES INICIAIS Objetivos idênticos ao hardware dos relés convencionais, ou seja, recebem sinais analógicos de tensão, corrente e outros, sinais digitais de contatos

Leia mais

Prof. Adilson Gonzaga

Prof. Adilson Gonzaga Prof. Adilson Gonzaga Outras características importantes em Microprocessadores/Microcontroladores Redução de Potência de Operação As versões CHMOS (89C51, 89S52, etc ) da família MCS-51 possuem dois modos

Leia mais

Fundamentos da Informática Aula 03 - Sistemas operacionais: Software em segundo plano Exercícios Professor: Danilo Giacobo

Fundamentos da Informática Aula 03 - Sistemas operacionais: Software em segundo plano Exercícios Professor: Danilo Giacobo Fundamentos da Informática Aula 03 - Sistemas operacionais: Software em segundo plano Exercícios Professor: Danilo Giacobo Múltipla escolha 1. Em que consiste um sistema operacional: a. Um conjunto de

Leia mais

Aula 09. Módulos de Entrada e Saída

Aula 09. Módulos de Entrada e Saída Aula 09 Módulos de Entrada e Saída Módulo de E/S Se não tivermos como colocar dados nos computadores de que eles servirão? Os barramentos fornecem um meio de mover dados de dentro para fora do sistema.

Leia mais

8º CONGRESSO IBEROAMERICANO DE ENGENHARIA MECANICA Cusco, 23 a 25 de Outubro de 2007

8º CONGRESSO IBEROAMERICANO DE ENGENHARIA MECANICA Cusco, 23 a 25 de Outubro de 2007 8º CONGRESSO IBEROAMERICANO DE ENGENHARIA MECANICA Cusco, 23 a 25 de Outubro de 2007 SISTEMA DIGITAL DE CONTROLE DE UMA MESA DE POSICIONAMENTO D.I. Lasmar*, G.A. Rossi*, A.A.T. Maia*, J.M. Galvez* *Universidade

Leia mais

MINICURSO - PLATAFORMA ARDUINO Eixo de Informação e Comunicação Gil Eduardo de Andrade

MINICURSO - PLATAFORMA ARDUINO Eixo de Informação e Comunicação Gil Eduardo de Andrade Introdução MINICURSO - PLATAFORMA ARDUINO Eixo de Informação e Comunicação Gil Eduardo de Andrade A oficina proposta neste documento apresenta conceitos iniciais e intermediários sobre o funcionamento

Leia mais

Programação de Periféricos

Programação de Periféricos Programação de Periféricos Componentes Edson Moreno edson.moreno@pucrs.br http://www.inf.pucrs.br/~emoreno Apresentação Raspberry pi Sistema Operacional embarcado Atividade Raspberry pi Sistema computacional

Leia mais

ENGENHARIA DE SISTEMAS MICROPROCESSADOS

ENGENHARIA DE SISTEMAS MICROPROCESSADOS ENGENHARIA DE SISTEMAS MICROPROCESSADOS Prof. Pierre Vilar Dantas Turma: 0040-A Horário: 4N Aula 01-26/07/2017 Plano de ensino Professor www.linkedin.com/in/pierredantas/ TÓPICOS Conceitos gerais. Evolução

Leia mais

APLICAÇÃO E DESENVOLVIMENTO DE UM SISTEMA DE TELEMETRIA À ESTAÇÕES METEOROLÓGICAS

APLICAÇÃO E DESENVOLVIMENTO DE UM SISTEMA DE TELEMETRIA À ESTAÇÕES METEOROLÓGICAS APLICAÇÃO E DESENVOLVIMENTO DE UM SISTEMA DE TELEMETRIA À ESTAÇÕES METEOROLÓGICAS Hans R. ZIMERMANN, Débora R. ROBERTI, Josué M. SEHNEM. 1 Introdução A telemetria é uma técnica na qual uma medição realizada

Leia mais

Informática I. Aula 2. Ementa

Informática I. Aula 2.  Ementa Informática I Aula 2 http://www.ic.uff.br/~bianca/informatica1/ Aula 2-29/08/2007 1 Ementa Noções Básicas de Computação (Hardware, Software e Internet) HTML e Páginas Web Internet e a Web Javascript e

Leia mais

Sistemas Digitais: Introdução

Sistemas Digitais: Introdução Universidade Federal do Rio Grande do Norte Departamento de Engenharia de Computação e Automação Sistemas Digitais: Introdução DCA0119 Sistemas Digitais Heitor Medeiros Florencio 1 Objetivo: Projetar Sistemas

Leia mais

ü Na década de 1920 os dispositivos mecânicos foram substituídos pelos relés; ü O uso da lógica de relés dificultava modificações do processo;

ü Na década de 1920 os dispositivos mecânicos foram substituídos pelos relés; ü O uso da lógica de relés dificultava modificações do processo; O que são? CLP - CONTROLADOR LÓGICO PROGRAMÁVEL ü O CLP é um computador industrial, capaz de implementar funções de controle (sequência lógica, contagem e temporização), operações lógicas e aritméticas,

Leia mais

4 Arquitetura Adotada

4 Arquitetura Adotada 4 Arquitetura Adotada Neste trabalho foi desenvolvido um sistema para a inspeção de dutos de óleo, gás e outros fluidos. Este sistema está sendo usado em inspeções que utilizam como ferramenta de inspeção

Leia mais

Hardware Livre Arduino. Givanaldo Rocha de Souza

Hardware Livre Arduino. Givanaldo Rocha de Souza Hardware Livre Arduino Givanaldo Rocha de Souza http://docente.ifrn.edu.br/givanaldorocha Tópicos Hardware Livre Sistemas Embarcados Microcontroladores Plataforma Arduino Introdução Exemplos Cubieboard

Leia mais

2 Descrição da Unidade de Levitação Magnética e Sistema de Controle

2 Descrição da Unidade de Levitação Magnética e Sistema de Controle Universidade Federal de Minas Gerais Laboratório de Controle e Automação I Prof. Patrícia N. Pena - DELT Levitação Eletromagnética 1 Levitação Eletromagnética O módulo de Levitação Magnética da Feedback

Leia mais

Introdução ao Controle Automático de Aeronaves: Técnicas de Controle em Malha Fechada

Introdução ao Controle Automático de Aeronaves: Técnicas de Controle em Malha Fechada Introdução ao de Aeronaves: Técnicas de Controle em Malha Fechada Novembro de 2017 1 Funcionalidades de 2 Abordagens para o Projeto de Controladores Técnicas Clássicas Lineares: Diretrizes Gerais Comumente

Leia mais

INTRODUÇÃO: MICROCONTROLADORES

INTRODUÇÃO: MICROCONTROLADORES INTRODUÇÃO: MICROCONTROLADORES MICROCONTROLADOR X MICROPROCESSADOR Baixa capacidade de processamento Freq. Operação em MHz Custo de R$ 7,00 a 30,00 Aplicações mais restrita Alta capacidade de processamento

Leia mais

Controle de Ventilador de Fonte de PC em Malha Aberta

Controle de Ventilador de Fonte de PC em Malha Aberta Universidade Tecnológica Federal do Paraná Campus Curitiba Departamento Acadêmico de Eletrônica Tecnologia em Mecatrônica Industrial Sistemas Microprocessados Controle de Ventilador de Fonte de PC em Malha

Leia mais

SSC510 Arquitetura de Computadores 1ª AULA

SSC510 Arquitetura de Computadores 1ª AULA SSC510 Arquitetura de Computadores 1ª AULA REVISÃO DE ORGANIZAÇÃO DE COMPUTADORES Arquitetura X Organização Arquitetura - Atributos de um Sistema Computacional como visto pelo programador, isto é a estrutura

Leia mais

IF-705 Automação Inteligente Sistemas de Controle - Fundamentos

IF-705 Automação Inteligente Sistemas de Controle - Fundamentos IF-705 Automação Inteligente Sistemas de Controle - Fundamentos Aluizio Fausto Ribeiro Araújo Universidade Federal de Pernambuco Centro de Informática - CIn Departamento de Sistemas da Computação aluizioa@cin.ufpe.br

Leia mais

TÍTULO: CÁLCULO NUMÉRICO APLICADO AO CONTROLE DE ATUADORES EM SISTEMAS EMBARCADOS POR MEIO DE CÁLCULO DIFERENCIAL E INTEGRAL

TÍTULO: CÁLCULO NUMÉRICO APLICADO AO CONTROLE DE ATUADORES EM SISTEMAS EMBARCADOS POR MEIO DE CÁLCULO DIFERENCIAL E INTEGRAL TÍTULO: CÁLCULO NUMÉRICO APLICADO AO CONTROLE DE ATUADORES EM SISTEMAS EMBARCADOS POR MEIO DE CÁLCULO DIFERENCIAL E INTEGRAL CATEGORIA: CONCLUÍDO ÁREA: CIÊNCIAS EXATAS E DA TERRA SUBÁREA: Engenharias INSTITUIÇÃO(ÕES):

Leia mais

Utilização do solidthinking Embed em projetos de controle para sistemas embarcados utilizando técnica de controle adaptativo por modelo de referência.

Utilização do solidthinking Embed em projetos de controle para sistemas embarcados utilizando técnica de controle adaptativo por modelo de referência. Utilização do solidthinking Embed em projetos de controle para sistemas embarcados utilizando técnica de controle adaptativo por modelo de referência. Rodrigo de J. Macedo Resumo Apresenta-se, neste artigo,

Leia mais

Arduino Lab 02 Sensor de luminosidade e display de LCD 16 2

Arduino Lab 02 Sensor de luminosidade e display de LCD 16 2 Arduino Lab 02 Sensor de luminosidade e display de LCD 16 2 Display de LCD 16 2 Neste Lab, iremos descrever como conectar o sensor BH1750FVI, já citado no Lab 01, ao Arduino Micro e à um display. A indicação

Leia mais

Projeto de Algoritmos

Projeto de Algoritmos Projeto de Algoritmos Introdução aos Sistemas Computacionais Prof. Ernani Viriato de Melo / Reginaldo Costa http://www.ernani.eti.br http://reginaldofazu.blogspot.com 2º Semestre - 2008 Conceitos Básicos

Leia mais

Estudo de alternativas tecnológicas

Estudo de alternativas tecnológicas Estudo de alternativas tecnológicas Oficinas de Integração 3-2º. Sem. 2011 Prof. Heitor S. Lopes Prof. João A. Fabro Funções do engenheiro Entender o problema para poder determinar os requisitos necessários

Leia mais

Introdução à Programação Aula 01. Prof. Max Santana Rolemberg Farias Colegiado de Engenharia de Computação

Introdução à Programação Aula 01. Prof. Max Santana Rolemberg Farias Colegiado de Engenharia de Computação Introdução à Programação Aula 01 Prof. Max Santana Rolemberg Farias max.santana@univasf.edu.br Colegiado de Engenharia de Computação QUAL O OBJETIVO DA DISCIPLINA? Objetivo Tornar vocês (alunos) capazes

Leia mais

Gerência de Dispositivos. Adão de Melo Neto

Gerência de Dispositivos. Adão de Melo Neto Gerência de Dispositivos Adão de Melo Neto 1 Gerência de Dispositivos Introdução Acesso ao Subsistema de E/S Subsistema de E/S Device Drivers Controladores Dispositivos de E/S Discos Magnéticos Desempenho,

Leia mais

De Olho na Pista. Documento de Arquitetura. De Olho na Pista Documento de Arquitetura Data: 23/03/2013. AJA Software

De Olho na Pista. Documento de Arquitetura. De Olho na Pista Documento de Arquitetura Data: 23/03/2013. AJA Software AJA Software www.ajasoftware.wordpress.com De Olho na Pista Documento de Arquitetura Confidencial De Olho na Pista, 2013 1 Sumário 1. Introdução 3 2. Metas e Restrições da Arquitetura 3 3. Padrão da Arquitetura

Leia mais

Parte I Multiprocessamento

Parte I Multiprocessamento Sistemas Operacionais I Estrutura dos SO Prof. Gregorio Perez gregorio@uninove.br 2004 Parte I Multiprocessamento Roteiro 1 Multiprocessadores em Sistemas Fortemente Acoplados 1.1 1.2 1.3 Processamento

Leia mais

Universidade Federal do Rio Grande do Sul Escola de Engenharia Departamento de Engenharia Elétrica ENG04037 Sistemas de Controle Digitais

Universidade Federal do Rio Grande do Sul Escola de Engenharia Departamento de Engenharia Elétrica ENG04037 Sistemas de Controle Digitais Universidade Federal do Rio Grande do Sul Escola de Engenharia Departamento de Engenharia Elétrica ENG04037 Sistemas de Controle Digitais Introdução ao Controle Digital 1 Sistema de Controle 1. malha aberta

Leia mais

Estruturas de Sistemas Operacionais

Estruturas de Sistemas Operacionais Estruturas de Sistemas Operacionais Sistemas Operacionais - Tópicos Componentes do Sistema Serviços de Sistemas Operacionais Chamadas ao Sistema Estrutura do Sistema Máquinas Virtuais Chamadas ao Sistema

Leia mais

Métodos de Sincronização

Métodos de Sincronização Métodos de Sincronização Eduardo Ferreira dos Santos Ciência da Computação Centro Universitário de Brasília UniCEUB Maio, 2017 1 / 31 Sumário 1 Sistemas multiprogramáveis 2 Mecanismos de sincronização

Leia mais

DESENVOLVIMENTO DE VEICULOS AUTONOMOS EM ESCALA EM AMBIENTE DE SIMULAÇÃO COMPUTACIONAL

DESENVOLVIMENTO DE VEICULOS AUTONOMOS EM ESCALA EM AMBIENTE DE SIMULAÇÃO COMPUTACIONAL DESENVOLVIMENTO DE VEICULOS AUTONOMOS EM ESCALA EM AMBIENTE DE SIMULAÇÃO COMPUTACIONAL Aluno: Renan de Lima Simões Mondego Vilela Orientador: Mauro Speranza Neto Introdução O presente projeto é continuação

Leia mais

Tópicos Avançados em Sistemas Computacionais: Infraestrutura de Hardware Aula 02

Tópicos Avançados em Sistemas Computacionais: Infraestrutura de Hardware Aula 02 Tópicos Avançados em Sistemas Computacionais: Infraestrutura de Hardware Aula 02 Prof. Max Santana Rolemberg Farias max.santana@univasf.edu.br Colegiado de Engenharia de Computação POR QUE APRENDER CONCEITOS

Leia mais

Universidade Federal de Minas Gerais Laboratório de Controle e Automação I Prof. Patrícia N. Pena - DELT Twin Rotor MIMO System (TRMS)

Universidade Federal de Minas Gerais Laboratório de Controle e Automação I Prof. Patrícia N. Pena - DELT Twin Rotor MIMO System (TRMS) Universidade Federal de Minas Gerais Laboratório de Controle e Automação I Prof. Patrícia N. Pena - DELT Twin Rotor MIMO System (TRMS) 1 Rotor Duplo (TRMS - Twin Rotor MIMO System) A unidade TRMS da Feedback

Leia mais

Arquitetura de Computadores. Infraestrutura de TI: Hardware

Arquitetura de Computadores. Infraestrutura de TI: Hardware Arquitetura de Computadores Infraestrutura de TI: Hardware Computação Informação + Automação Tratamento dos dados em informação por meios automáticos Dispositivos eletrônicos Aplicados em Computadores,

Leia mais

LABORATÓRIO DE SISTEMAS OPERACIONAIS. PROFª. M.Sc. JULIANA HOFFMANN QUINONEZ BENACCHIO

LABORATÓRIO DE SISTEMAS OPERACIONAIS. PROFª. M.Sc. JULIANA HOFFMANN QUINONEZ BENACCHIO LABORATÓRIO DE SISTEMAS OPERACIONAIS PROFª. M.Sc. JULIANA HOFFMANN QUINONEZ BENACCHIO Sistema Operacional Conteúdo retirado do livro Arquitetura de Sistemas Operacionais Francis Berenger Machado Luiz Paulo

Leia mais

INTRODUÇÃO A SISTEMAS OPERACIONAIS

INTRODUÇÃO A SISTEMAS OPERACIONAIS INTRODUÇÃO A SISTEMAS OPERACIONAIS Prof. Me. Hélio Esperidião DEFINIÇÃO DE SISTEMA OPERACIONAL. O sistema operacional é uma camada de software colocada sobre o hardware para gerenciar todos os componentes

Leia mais

Parte II Arquitetura. professorferlin.blogspot.com. professorferlin.blogspot.com. Sociedade Paranaense de Ensino e Informática

Parte II Arquitetura.   professorferlin.blogspot.com. professorferlin.blogspot.com. Sociedade Paranaense de Ensino e Informática www.spei.br Sociedade Paranaense de Ensino e Informática Parte II Arquitetura 2 1 Estrutura Básica 3 4 2 Arquitetura Básica 5 CLP x Computador A fonte de alimentação possui características ótimas de filtragem

Leia mais

Minicurso de Arduino. Laboratório de Inovação em Sistemas em chip npiti - UFRN

Minicurso de Arduino. Laboratório de Inovação em Sistemas em chip npiti - UFRN Minicurso de Arduino Laboratório de Inovação em Sistemas em chip npiti - UFRN Agenda - 1º dia Motivação Introdução O Arduino, Versões, Clones Noções de eletrônica Corrente, tensão, potência, resistores,

Leia mais

DESENVOLVIMENTO DE VEICULOS AUTONOMOS EM ESCALA EM AMBIENTE DE SIMULAÇÃO COMPUTACIONAL

DESENVOLVIMENTO DE VEICULOS AUTONOMOS EM ESCALA EM AMBIENTE DE SIMULAÇÃO COMPUTACIONAL DESENVOLVIMENTO DE VEICULOS AUTONOMOS EM ESCALA EM AMBIENTE DE SIMULAÇÃO COMPUTACIONAL Aluno: Renan de Lima Simões Mondego Vilela Orientador: Mauro Speranza Neto Introdução O presente projeto é continuação

Leia mais

Estrutura e Funcionamento dos Computadores (Conceitos Básicos)

Estrutura e Funcionamento dos Computadores (Conceitos Básicos) Estrutura e Funcionamento dos Computadores (Conceitos Básicos) Sistema Computacional Peopleware (usuário) Software (programas) Hardware (máquina) Hardware Corresponde à parte material, aos componentes

Leia mais

CONCURSO PÚBLICO DE PROVAS E TÍTULOS EDITAL ESPECÍFICO 087/ CAMPUS SABARÁ

CONCURSO PÚBLICO DE PROVAS E TÍTULOS EDITAL ESPECÍFICO 087/ CAMPUS SABARÁ MINISTÉRIO DA EDUCAÇÃO SECRETARIA DE EDUCAÇÃO PROFISSIONAL E TECNOLÓGICA INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DE MINAS GERAIS CAMPUS SABARÁ MG Rodovia MGC 262, km 10, s/n, Sobradinho, Sabará/MG,

Leia mais

Introdução 12 que inuenciam a execução do sistema. As informações necessárias para o diagnóstico de tais problemas podem ser obtidas através da instru

Introdução 12 que inuenciam a execução do sistema. As informações necessárias para o diagnóstico de tais problemas podem ser obtidas através da instru 1 Introdução Atualmente a demanda pela construção de novos sistemas de software tem aumentado. Junto com esse aumento também cresce a complexidade das soluções que estão sendo desenvolvidas, o que torna

Leia mais

DESENVOLVIMENTO DE INTERFACE GRÁFICA PARA UM SISTEMA DIDÁTICO EM CONTROLE DE PROCESSOS

DESENVOLVIMENTO DE INTERFACE GRÁFICA PARA UM SISTEMA DIDÁTICO EM CONTROLE DE PROCESSOS DESENVOLVIMENTO DE INTERFACE GRÁFICA PARA UM SISTEMA DIDÁTICO EM CONTROLE DE PROCESSOS Ronaldo da Costa Freitas 1 Ágio Gonçalves de Moraes Felipe 2 1 Introdução/ Desenvolvimento O uso da automação nos

Leia mais

Introdução aos Sistemas Operacionais

Introdução aos Sistemas Operacionais Introdução aos Sistemas Operacionais Eleri Cardozo FEEC/Unicamp 1 Definição de Sistema Operacional Um sistema operacional é um gerenciador de recursos de hardware ou uma máquina virtual que oferece uma

Leia mais

Fundamentos de Sistemas Operacionais de Arquitetura Aberta. CST em Redes de Computadores

Fundamentos de Sistemas Operacionais de Arquitetura Aberta. CST em Redes de Computadores Fundamentos de Sistemas Operacionais de Arquitetura Aberta CST em Redes de Computadores Introdução Computadores Computadores são compostos, basicamente, de CPU, memória e dispositivos de entrada e saída

Leia mais

CAPÍTULO 5. Interfaces I 2 C e SPI. Interface I 2 C. Interfaces e Periféricos 37

CAPÍTULO 5. Interfaces I 2 C e SPI. Interface I 2 C. Interfaces e Periféricos 37 Interfaces e Periféricos 37 CAPÍTULO 5 Interfaces I 2 C e SPI Interface I 2 C Nos anos 80 a Philips desenvolveu um novo padrão de barramento chamado I²C, cujo objetivo era facilitar a comunicação entre

Leia mais

AULA 03: FUNCIONAMENTO DE UM COMPUTADOR

AULA 03: FUNCIONAMENTO DE UM COMPUTADOR ORGANIZAÇÃO E ARQUITETURA DE COMPUTADORES I AULA 03: FUNCIONAMENTO DE UM COMPUTADOR Prof. Max Santana Rolemberg Farias max.santana@univasf.edu.br Colegiado de Engenharia de Computação O QUE É UM COMPUTADOR?

Leia mais

Implementando PWM por soft - um método simples. Por Renie S. Marquet reniemarquet.sites.com.br - versão

Implementando PWM por soft - um método simples. Por Renie S. Marquet reniemarquet.sites.com.br - versão Implementando PWM por soft - um método simples. Por Renie S. Marquet reniemarquet.sites.com.br - versão 25.02.2005 O PWM (Pulse Width Modulation Modulação por largura de pulso) consiste em controlar o

Leia mais

Universidade Estadual do Oeste do Paraná - UNIOESTE Implementação de uma lupa digital baseada em captura de imagens Deivide Possamai, Fernando

Universidade Estadual do Oeste do Paraná - UNIOESTE Implementação de uma lupa digital baseada em captura de imagens Deivide Possamai, Fernando Universidade Estadual do Oeste do Paraná - UNIOESTE Implementação de uma lupa digital baseada em captura de imagens Deivide Possamai, Fernando Fernandes Bolsista: MEC/SESu Ciência da Computação 2011. Orientador:

Leia mais

7 Experimentos. Figura 2 Sensor Inercial (Xsens) Figura 3 Sensor GPS (Garmin) Figura 1 Robô Ambiental Híbrido

7 Experimentos. Figura 2 Sensor Inercial (Xsens) Figura 3 Sensor GPS (Garmin) Figura 1 Robô Ambiental Híbrido 7 Experimentos Foram realizados dois experimentos distintos com o sensor GPS da marca Garmin e o sensor inercial da marca Xsens, Fig. 83 e 84 respectivamente: Na floresta amazônica, onde os sensores foram

Leia mais

Sistemas Operacionais II. Linux - Introdução

Sistemas Operacionais II. Linux - Introdução Sistemas Operacionais II Linux - Introdução 2 Histórico Em 1991, um estudante de computação da Finlândia chamado Linus Torvalds desenvolveu um kernel compatível com o Unix para um processador 80386 que

Leia mais

Organização de Computadores

Organização de Computadores Organização de Computadores Aula 19 Barramentos: Estruturas de Interconexão Rodrigo Hausen 14 de outubro de 2011 http://cuco.pro.br/ach2034 1/40 Apresentação 1. Bases Teóricas 2. Organização de computadores

Leia mais

Projeto de um Controlador PID

Projeto de um Controlador PID ALUNOS 1 - NOTA 2- DATA Projeto de um Controlador PID 1.1 Objetivo Este experimento tem como objetivo a implementação de um controlador PID para um dos processos da MPS-PA Estação Compacta. Supõe-se que

Leia mais

INFRAESTRUTURA NECESSÁRIA...

INFRAESTRUTURA NECESSÁRIA... VISÃO DO SISTEMA Sumário 1 INTRODUÇÃO... 2 2 ITSCAM PRO... 3 2.1. 2.2. ARQUITETURA DO SISTEMA... 3 PRINCIPAIS FUNCIONALIDADES E TELAS... 4 3 INFRAESTRUTURA NECESSÁRIA... 11 3.1. 3.2. 3.3. 3.4. INFRAESTRUTURA

Leia mais

ENGG55 REDES INDUSTRIAIS Introdução aos Sistemas de Comunicação Industrial

ENGG55 REDES INDUSTRIAIS Introdução aos Sistemas de Comunicação Industrial ENGG55 REDES INDUSTRIAIS Introdução aos Sistemas de Comunicação Industrial Prof. Eduardo Simas (eduardo.simas@ufba.br) DEE Departamento de Engenharia Elétrica Escola Politécnica - UFBA 1 Introdução Muitas

Leia mais

Os computadores ditigais podem ser classificados em 5 grupos distintos:

Os computadores ditigais podem ser classificados em 5 grupos distintos: Informática A informática engloba toda atividade relacionada ao uso dos computadores, permitindo aprimorar e automatizar tarefas em qualquer área de atuação da sociedade. Informática é a "Ciência do tratamento

Leia mais

FERRAMENTA PARA CONFIGURAÇÃO DE SISTEMAS DE CONTROLE EMBARCADOS (IoTControl) 1

FERRAMENTA PARA CONFIGURAÇÃO DE SISTEMAS DE CONTROLE EMBARCADOS (IoTControl) 1 FERRAMENTA PARA CONFIGURAÇÃO DE SISTEMAS DE CONTROLE EMBARCADOS (IoTControl) 1 Danilo Oliveira MARTINS 2 Discente do Mestrado em Automação e Controle de Processos IFSP/Campus São Paulo Alexandre Brincalepe

Leia mais

INFORMÁTICA BÁSICA HARDWARE: COMPONENTES BÁSICOS E FUNCIONAMENTO.

INFORMÁTICA BÁSICA HARDWARE: COMPONENTES BÁSICOS E FUNCIONAMENTO. INFORMÁTICA BÁSICA HARDWARE: COMPONENTES BÁSICOS E FUNCIONAMENTO isabeladamke@hotmail.com Componentes de um Sistema de Computador HARDWARE: unidade responsável pelo processamento dos dados, ou seja, o

Leia mais

Sistemas Operacionais. BSI / UAB 2013 Hélio Crestana Guardia

Sistemas Operacionais. BSI / UAB 2013 Hélio Crestana Guardia Sistemas Operacionais BSI / UAB 2013 Hélio Crestana Guardia Visão do SO SO: camada de software, executado diretamente sobre o hardware (físico ou virtual) Permite que hardware seja usado de forma eficiente

Leia mais

AULA 9 ATUADORES ELÉTRICOS

AULA 9 ATUADORES ELÉTRICOS AULA 9 ATUADORES ELÉTRICOS Prof. Fabricia Neres Tipos de Acionamento Os acionadores são dispositivos responsáveis pelo movimento nos atuadores. Podem ser classificados em: Acionamento Elétrico; Acionamento

Leia mais

RESOLUÇÃO N.º 1010/2005 ANEXO II MODALIDADE ELÉTRICA NIVALDO J. BOSIO

RESOLUÇÃO N.º 1010/2005 ANEXO II MODALIDADE ELÉTRICA NIVALDO J. BOSIO RESOLUÇÃO N.º 1010/2005 ANEXO II MODALIDADE ELÉTRICA NIVALDO J. BOSIO 1. CATEGORIA ENGENHARIA 1.2 - CAMPOS DE ATUAÇÃO PROFISSIONAL DA MODALIDADE ELÉTRICA 1.2.1 Eletricidade Aplicada e Equipamentos Eletroeletrônicos

Leia mais

Anexo 2.8 Especificações do Sistema de Monitoramentoda Frota

Anexo 2.8 Especificações do Sistema de Monitoramentoda Frota Anexo 2.8 Especificações do Sistema de Monitoramentoda Frota ÍNDICE 1 OBJETIVOS... 3 2 ESPECIFICAÇÃO BÁSICA... 3 2.1 AQUISIÇÃO DE DADOS MONITORADOS DO VEÍCULO... 3 2.2 AQUISIÇÃO DE DADOS DE LOCALIZAÇÃO...

Leia mais

Gerência de Entrada e Saída

Gerência de Entrada e Saída Gerência de Entrada e Saída Dispositivos de Entrada e Saída (1) Constituídos de 2 partes: Mecânica Eletrônica Controladora ou Adaptadora Controladora Placa ligada a um slot livre, ou inserida diretamente

Leia mais

UNIVERSIDADE CATÓLICA DE PELOTAS CENTRO POLITÉCNICO CURSO DE ENGENHARIA ELETRÔNICA DISCIPLINA DE INSTRUMENTAÇÃO ELETRÔNICA

UNIVERSIDADE CATÓLICA DE PELOTAS CENTRO POLITÉCNICO CURSO DE ENGENHARIA ELETRÔNICA DISCIPLINA DE INSTRUMENTAÇÃO ELETRÔNICA UNIVERSIDADE CATÓLICA DE PELOTAS CENTRO POLITÉCNICO CURSO DE ENGENHARIA ELETRÔNICA DISCIPLINA DE INSTRUMENTAÇÃO ELETRÔNICA MONITOR DE MOVIMENTOS COM ACELERÔMETRO Desenvolvido por Maurício Fiss Rodrigues

Leia mais

Brilliant Solutions for a Safe World

Brilliant Solutions for a Safe World IDENTIFICAÇÃO DE FACE E RASTREAMENTO DE MOVIMENTO PARA SISTEMAS DE GERENCIAMENTO DE VÍDEO (VMS) SentiVeillance Server é um software de identificação biométrica de faces e rastreamento de movimento pronto

Leia mais

Atividade de Participação de Aula 02 (Individual) Aluno: Data: 17/08/2017

Atividade de Participação de Aula 02 (Individual) Aluno: Data: 17/08/2017 Atividade de Participação de Aula 02 (Individual) Aluno: Data: 17/08/2017 Curso: Engenharia Elétrica Período: 1. O que é uma rede Industrial? Sistema de Comunicação bidirecional em tempo real que permite

Leia mais

Computadores e Programação (DCC/UFRJ)

Computadores e Programação (DCC/UFRJ) Computadores e Programação (DCC/UFRJ) Aula 3: 1 2 3 Abstrações do Sistema Operacional Memória virtual Abstração que dá a cada processo a ilusão de que ele possui uso exclusivo da memória principal Todo

Leia mais

OSCILOSCÓPIO DIGITAL DE AMOSTRAGEM PARA COMPUTADOR

OSCILOSCÓPIO DIGITAL DE AMOSTRAGEM PARA COMPUTADOR Instituto Federal Sul-rio-grandense Campus Pelotas - Curso de Engenharia Elétrica OSCILOSCÓPIO DIGITAL DE AMOSTRAGEM PARA COMPUTADOR Disciplina: Projeto Integrador II Professor: Renato Allemand Equipe:

Leia mais

Compressão Adaptativa de Arquivos HTML em Ambientes de Comunicação Sem Fio

Compressão Adaptativa de Arquivos HTML em Ambientes de Comunicação Sem Fio Universidade Federal de Ouro Preto - UFOP Instituto de Ciências Exatas e Biológicas - ICEB Departamento de Computação - DECOM Compressão Adaptativa de Arquivos HTML em Ambientes de Comunicação Sem Fio

Leia mais

Sistemas Embarcados:

Sistemas Embarcados: Universidade Federal do Rio Grande do Norte Departamento de Engenharia de Computação e Automação Sistemas Embarcados: Microcontroladores DCA0119 Sistemas Digitais Heitor Medeiros Florencio Sistemas Embarcados

Leia mais

CURSO: ENGENHARIA DE CONTROLE E AUTOMAÇÃO EMENTAS º PERÍODO

CURSO: ENGENHARIA DE CONTROLE E AUTOMAÇÃO EMENTAS º PERÍODO CURSO: ENGENHARIA DE CONTROLE E AUTOMAÇÃO EMENTAS - 2017.2 2º PERÍODO DISCIPLINA: CÁLCULO I Estudo e aplicação de limites. Estudo e aplicação de derivadas. Estudo de soluções de problemas com utilização

Leia mais