Índice:

CanSat - Guia para iniciantes: 6 etapas
CanSat - Guia para iniciantes: 6 etapas

Vídeo: CanSat - Guia para iniciantes: 6 etapas

Vídeo: CanSat - Guia para iniciantes: 6 etapas
Vídeo: Meditación para principiantes. 6 minutos. 2024, Julho
Anonim
CanSat - Guia para iniciantes
CanSat - Guia para iniciantes
CanSat - Guia para iniciantes
CanSat - Guia para iniciantes
CanSat - Guia para iniciantes
CanSat - Guia para iniciantes

O objetivo principal deste instructables é compartilhar o processo de desenvolvimento de um CanSat, passo a passo. Mas, antes de começar, vamos deixar bem claro o que é um CanSat e quais são suas principais funcionalidades, aproveitando também para apresentar nossa equipe. Este projeto começou como um projeto de extensão em nossa universidade, Universidade Tecnológica Federal do Paraná (UTFPR), campus Cornélio Procópio. Orientados por nosso orientador, desenvolvemos um plano de ação com o intuito de entrar no CanSats, o que significou estudar todos os seus aspectos e características, para poder entender como funciona, o que no final resultaria na construção de um CanSat e o desenvolvimento deste guia. Um CanSat é classificado como um picossatélite, o que significa que seu peso é limitado a 1kg, mas normalmente o CanSats pesa cerca de 350g, e sua estrutura é baseada em uma lata de refrigerante, um cilindro de 6,1 cm de diâmetro e 11,65 cm de altura. Este modelo foi apresentado com o intuito de simplificar o processo de desenvolvimento de um satélite, de forma a possibilitar o acesso das universidades a essas tecnologias, ganhando popularidade devido às competições que adotaram este padrão. Em geral, os CanSats são baseados em 4 estruturas, ou seja, o sistema de potência, o sistema de detecção, o sistema de telemetria e o sistema principal. Então, vamos dar uma olhada em cada sistema: - Sistema de potência: este sistema é responsável por fornecer energia elétrica aos demais, de acordo com suas necessidades. Em outras palavras, deve fornecer aos sistemas a tensão e a corrente necessárias, respeitando seus limites. Além disso, pode apresentar componentes de proteção, de forma a garantir a segurança e o bom comportamento dos demais sistemas. Normalmente é baseado em uma bateria e um circuito regulador de tensão, mas muitos outros recursos podem ser adicionados, como técnicas de gerenciamento de energia e vários tipos de proteções. - Sistema de detecção: este sistema é composto por todos os sensores e dispositivos responsáveis pela coleta dos dados solicitados. pode ser conectado ao sistema principal de diversas formas, protocolos seriais, protocolos paralelos entre outros, por isso é tão importante dominar todas essas técnicas, para poder determinar a mais conveniente. Em geral, os protocolos seriais são os mais escolhidos, devido ao seu menor número de conexões e versatilidade, de longe os mais populares são os protocolos SPI, I2C e UART. - Sistema de Telemetria: este sistema é responsável por estabelecer a comunicação sem fio entre o CanSat e a estação de controle de solo, que inclui o protocolo de comunicação sem fio e hardware. - Sistema Principal: este sistema é responsável por interligar todos os demais sistemas, de forma que também controle e sincronize sua seqüência de funcionamento como organismo.

Etapa 1: O Sistema Principal

O Sistema Principal
O Sistema Principal

Por muitos motivos, escolhemos um microcontrolador baseado em ARM® Cortex®-M4F, é um MCU de baixa potência, que oferece um poder de processamento muito maior, além de vários recursos que não são comumente vistos em microcontroladores RISK, como funções DSP. Essas características são interessantes porque possibilitam o aumento da complexidade das funcionalidades dos aplicativos CanSat, sem a necessidade de troca do microcontrolador (claro, respeitando seus limites também).

Contanto que o projeto tivesse várias limitações financeiras, o microcontrolador escolhido também deveria ser acessível, então seguindo as especificações, acabamos escolhendo o ARM® Cortex®-M4F Based MCU TM4C123G LaunchPad, é uma plataforma de lançamento que acabou de se encaixar em nosso projeto. Também a documentação (planilhas e documentação de características fornecidas pelo fabricante) e o IDE do MCU foram prós que realmente deveriam ser considerados, desde que ajudassem muito no processo de desenvolvimento.

Neste Cansat, decidimos mantê-lo simples e apenas desenvolvê-lo usando a barra de lançamento, mas é claro que em projetos futuros, isso não será uma opção, considerando que vários recursos incluídos na barra de lançamento não são realmente necessários para o nosso projeto, mais seu formato limitou muito o projeto da estrutura do nosso CanSat, desde que as dimensões de um CanSat sejam mínimas.

Assim, após a escolha do 'cérebro' adequado para este sistema, o próximo passo foi o desenvolvimento do seu software, também para mantê-lo simples decidimos usar simplesmente um programa sequencial, que faz a seguinte sequência na frequência de 1 Hz:

Leituras de sensores> armazenamento de dados> transmissão de dados

A parte dos sensores será explicada posteriormente no sistema de detecção, assim como a transmissão de dados será explicada no sistema de telemetria. Por fim, era para aprender a programar o microcontrolador, no nosso caso precisávamos aprender as seguintes funções do MCU, do GPIO, do módulo I2C, do módulo UART e do módulo SPI.

Os GPIOs, ou simplesmente entrada e saída de uso geral, são portas que podem ser usadas para realizar várias funções, desde que sejam configuradas corretamente. Considerando que não estamos utilizando nenhuma biblioteca C para os GPIO's, nem mesmo para os outros módulos, deveríamos configurar todos os registros necessários. Por esta razão, escrevemos um guia básico contendo exemplos e descrições relacionadas aos registros dos módulos que estamos usando, que estão disponíveis a seguir.

Além disso, para simplificar e organizar o código, várias bibliotecas foram criadas. Portanto, as bibliotecas foram criadas para os seguintes propósitos:

- protocolo SPI

- protocolo I2C

- protocolo UART

- NRF24L01 + - transceptor

Essas bibliotecas também estão disponíveis abaixo, mas lembre-se de que usamos o IDE Keil uvision 5, portanto, essas bibliotecas não funcionarão para o compositor de código. Finalmente, depois de criar todas as bibliotecas e aprender todas as coisas necessárias, o código final foi montado e, como você pode imaginar, também está disponível abaixo.

Etapa 2: o sistema de detecção

O sistema de detecção
O sistema de detecção
O sistema de detecção
O sistema de detecção
O sistema de detecção
O sistema de detecção
O sistema de detecção
O sistema de detecção

Este sistema é composto por todos os sensores e dispositivos responsáveis por recolher informações sobre as condições de funcionamento do CanSat. No nosso caso, escolhemos os seguintes sensores:

- um acelerômetro digital de 3 eixos - MPU6050

- um giroscópio digital de 3 eixos - MPU6050

- um magnetômetro digital de 3 eixos - HMC5883L

- um barômetro digital - BMP280

- e um GPS - Tyco A1035D

As escolhas basearam-se principalmente na acessibilidade, o que significava que desde que as características mecânicas e elétricas (protocolo de comunicação, alimentação etc) fossem compatíveis com o nosso projeto, não foram impostos outros parâmetros às escolhas, também porque para alguns sensores a disponibilidade de opções foi limitado. Depois de adquirir os sensores, era hora de colocá-los para funcionar.

Então o primeiro a ser explorado foi o acelerômetro digital de 3 eixos e giroscópio, denominado MPU6050 (pode ser facilmente encontrado em qualquer lugar, desde que seja amplamente utilizado em projetos ARDUINO), sua comunicação é baseada no protocolo I2C, um protocolo em que cada escravo possui um endereço, permitindo que vários dispositivos sejam conectados em paralelo, considerando que o endereço tem 7 bits, cerca de 127 dispositivos podem ser conectados no mesmo barramento serial. Este protocolo de comunicação funciona em dois barramentos, um barramento de dados e um barramento de clock, portanto, para trocar as informações, o mestre deve enviar 8 ciclos de clock (aliás a informação deve caber em um byte, desde que esta comunicação seja baseada no tamanho do byte) em uma operação de recepção ou transmissão. O endereço do MPU6050 é 0b110100X, e o X é usado para chamar (indica) uma operação de leitura ou escrita (0 indica uma operação de escrita e 1 indica uma operação de leitura), então sempre que quiser ler o sensor basta usar seu endereço como 0xD1 e sempre que quiser escrever basta usar o endereço como 0xD0.

Depois de explorar o protocolo I2C, o MPU6050 foi de fato estudado, ou seja, foi lida sua ficha de dados, a fim de se obter as informações necessárias para colocá-lo em funcionamento, para este sensor foi necessário configurar apenas três registros, o gerenciamento de energia 1 registro - endereço 0x6B (para garantir que o sensor não está em modo de espera), registro de configuração do giroscópio - endereço 0x1B (para configurar a faixa de fundo de escala para o giroscópio) e finalmente o registro de configuração do acelerômetro - endereço 0x1C (em para configurar a faixa de fundo de escala para o acelerômetro). Existem vários outros registros que podem ser configurados, permitindo a otimização do desempenho do sensor, mas para este projeto essas configurações são suficientes.

Então, depois de configurar o sensor corretamente, agora você pode lê-lo. A informação desejada ocorre entre o registro 0x3B e o registro 0x48, cada valor do eixo é composto por dois bytes que são codificados na forma de complemento de 2, o que significa que os dados lidos devem ser convertidos para serem significativos (essas coisas serão discutido mais tarde).

Depois de terminar com o MPU6050, era hora de estudar o magnetômetro digital de 3 eixos, denominado HMC5883L (também pode ser facilmente encontrado em qualquer lugar, desde que seja amplamente utilizado em projetos ARDUINO), e novamente seu protocolo de comunicação é o protocolo serial I2C. Seu endereço é 0b0011110X e o X é usado para chamar (indica) uma operação de leitura ou escrita (0 indica uma operação de escrita e 1 indica uma operação de leitura), então sempre que quiser ler o sensor use seu endereço como 0x3D e sempre você deseja escrever apenas use seu endereço como 0x3C.

Neste caso, para obter o HMC5883L inicializado, três registros foram necessários para serem configurados, o registro de configuração A - endereço 0x00 (a fim de configurar a taxa de saída de dados e o modo de medição), o registro de configuração B - endereço 0x01 (para configurar o ganho do sensor) e por último, mas não menos importante, o registrador de modo - endereço 0x02 (para configurar o modo de operação do dispositivo).

Então, depois de configurar corretamente o HMC5883L, agora é possível lê-lo. A informação desejada ocorre entre o registro 0x03 e o registro 0x08, cada valor do eixo é composto por dois bytes que são codificados na forma de complemento de 2, o que significa que os dados lidos devem ser convertidos para serem significativos (essas coisas serão discutido mais tarde). Particularmente, para este sensor, você deve ler todas as informações de uma vez, caso contrário, ele pode não funcionar conforme proposto, desde que os dados de saída sejam gravados nesses registros apenas quando todos os registros forem escritos. então certifique-se de ler todos eles.

Por fim, foi estudado o barômetro digital, outro sensor do protocolo I2C, também denominado BMP280 (também pode ser facilmente encontrado em qualquer lugar, desde que seja amplamente utilizado em projetos ARDUINO). Seu endereço é b01110110X também o X é usado para chamar (indica) uma operação de leitura ou escrita (0 indica uma operação de escrita e 1 indica uma operação de leitura), então sempre que quiser ler o sensor basta usar seu endereço como 0XEA e sempre você deseja escrever apenas use seu endereço como 0XEB. Mas no caso deste sensor, o endereço I2C pode ser alterado mudando o nível de tensão no pino SDO, então se você aplicar GND a este pino, o endereço será b01110110X e se você aplicar VCC a este pino, o endereço está indo para ser b01110111X, também para habilitar o módulo I2C neste sensor você deve aplicar um nível VCC no pino CSB do sensor, caso contrário não vai funcionar corretamente.

Para o BMP280, apenas dois registradores deveriam ser configurados para fazê-lo funcionar, o registrador ctrl_meas - endereço 0XF4 (para definir as opções de aquisição de dados) e o registrador de configuração - endereço 0XF5 (para definir a taxa, o filtro e as opções de interface do sensor).

Depois de terminar a configuração, é hora do que realmente importa, os dados em si, neste caso a informação desejada fica entre os registradores 0XF7 e 0XFC. Tanto a temperatura quanto o valor da pressão são compostos por três bytes que são codificados na forma de complemento de 2, o que significa que os dados lidos devem ser convertidos para serem significativos (essas coisas serão discutidas mais tarde). Também para este sensor, a fim de obter uma maior precisão, existem vários coeficientes de correção que podem ser usados na conversão dos dados, eles estão localizados entre os registros 0X88 e 0XA1, sim existem 26 bytes de coeficientes de correção, portanto, se a precisão é não é tão importante, apenas esqueça-os, caso contrário, não há outra maneira.

E por último, mas não menos importante, o GPS - Tyco A1035D, este se baseia no protocolo serial UART, especificamente na taxa de 4800 kbps, sem bits de paridade, 8 bits de dados e 1 bit de parada. O UART, ou Receptor / Transmissor Assíncrono Universal, é um protocolo serial em que a sincronização das informações é feita via software, por isso é um protocolo assíncrono, também por essa característica, a taxa em que as informações são transmitidas e recebidas é bem menor. Especificamente para este protocolo, os pacotes devem começar com um bit de início, mas o bit de parada é opcional e o tamanho dos pacotes tem 8 bits.

No caso do GPS - Tyco A1035D, foram necessárias duas configurações, que foram o setDGPSport (comando 102) e o Query / RateControl (comando 103), todas essas informações, além de mais opções estão disponíveis no manual de referência NMEA, o protocolo usado na maioria dos módulos de GPS. O comando 102 é usado para definir a taxa de transmissão, a quantidade de bits de dados e a existência ou não de bits de paridade e bits de parada. O comando 103 é usado para controlar a saída de mensagens NMEA padrão GGA, GLL, GSA, GSV, RMC e VTG, elas são descritas com detalhes no manual de referência, mas no nosso caso o escolhido foi o GGA que significa Global Posicionamento de dados fixos do sistema.

Uma vez que o GPS - TycoA1035D esteja devidamente configurado, agora basta ler a porta serial e filtrar o string recebido de acordo com os parâmetros escolhidos, de forma a permitir o processamento da informação.

Depois de aprender todas as informações necessárias sobre todos os sensores, bastou um esforço extra para colocar tudo junto no mesmo programa, usando também as bibliotecas de comunicação serial.

Etapa 3: O sistema de telemetria

O Sistema de Telemetria
O Sistema de Telemetria

Este sistema é responsável por estabelecer a comunicação entre o controle de solo e o CanSat, além dos parâmetros do projeto, também foi restrito em mais algumas formas, desde que a transmissão de RF só seja permitida em algumas faixas de frequência, que não estão ocupadas devido a outros serviços de RF, como serviços móveis. Essas restrições são diferentes e podem mudar de país para país, por isso é importante sempre verificar as bandas de frequência permitidas para uso comum.

Existem muitas opções de rádios disponíveis no mercado a preços acessíveis, todos esses sistemas oferecem diferentes formas de modulação em diversas frequências, para este sistema nossa escolha consistiu em um transceptor RF 2.4GHz, o NRF24L01 +, pelo fato de já possuir um protocolo de comunicação bem estabelecido, contanto que sistemas de verificação, como sistemas de reconhecimento automático e retransmissão automática. Além disso, sua taxa de transmissão pode atingir velocidades de até 2 Mbps com um consumo de energia razoável.

Portanto, antes de trabalhar neste transceptor, vamos conhecer um pouco mais sobre o NRF24L01 +. Como mencionado antes, é um rádio baseado em 2,4 GHz, que pode ser configurado como receptor ou transmissor. Para estabelecer a comunicação cada transceptor recebe um endereço, que pode ser configurado pelo usuário, o endereço pode ter de 24 a 40 bits de acordo com a sua necessidade. As transações de dados podem ocorrer de forma única ou contínua, o tamanho dos dados é limitado a 1 byte e cada transação pode ou não gerar uma condição de reconhecimento de acordo com as configurações do transceptor.

Outras diversas configurações também são possíveis, como o ganho para a saída do sinal de RF, a existência ou não de uma rotina de retransmissão automática (se for o caso, o atraso, a quantidade de tentativas entre outras características podem ser escolhidas) e várias outras recursos que não são necessariamente úteis para este projeto, mas de qualquer forma estão disponíveis no datasheet do componente, caso haja algum interesse sobre eles.

O NRF24L01 + 'fala' a linguagem SPI quando se trata de comunicação serial, então sempre que você quiser ler ou escrever neste transceptor, basta ir em frente e usar o protocolo SPI para isso. O SPI é um protocolo serial conforme citado anteriormente, em que a seleção dos escravos é feita via pino CHIPSELECT (CS), que junto com a característica full duplex (tanto o mestre quanto o escravo podem transmitir e receber paralelamente) deste protocolo permite velocidades muito maiores de transação de dados.

O datasheet do NRF24L01 + fornece um conjunto de comandos para ler ou escrever neste componente, existem diferentes comandos para acessar os registros internos, o payload RX e TX entre outras operações, portanto dependendo da operação desejada, pode ser necessário um comando específico para execute-o. É por isso que seria interessante dar uma olhada na ficha técnica, na qual há uma lista contendo e explicando todas as ações possíveis sobre o transceptor (não vamos listá-las aqui, porque esse não é o ponto principal deste instructables)

Além do transceptor, outro componente importante deste sistema é o protocolo pelo qual todos os dados desejados são enviados e recebidos, desde que o sistema deva trabalhar com vários bytes de informação simultaneamente, é importante saber o significado de cada byte, É para isso que funciona o protocolo, pois permite ao sistema identificar de forma organizada todos os dados recebidos e transmitidos.

Para manter as coisas simples, o protocolo usado (para o transmissor) consistia em um cabeçalho formado por 3 bytes seguidos pelos dados do sensor, desde que todos os dados dos sensores consistissem em dois bytes, cada dado do sensor recebia um número de identificação inicial de 0x01 e seguindo em ordem crescente, assim a cada dois bytes há um byte de identificação, desta forma a sequência do cabeçalho não poderia ser repetida ao acaso de acordo com as leituras do sensor. O receptor acabou sendo tão simples quanto o transmissor, o protocolo só precisava reconhecer o cabeçalho enviado pelo transmissor e depois armazenar apenas os bytes recebidos, neste caso decidimos usar um vetor para armazená-los.

Portanto, depois de obter todo o conhecimento necessário sobre o transceptor e determinar o protocolo de comunicação, é hora de colocar tudo junto no mesmo pedaço de código e, finalmente, fazer o firmware CanSat.

Etapa 4: O sistema de energia

Este sistema é responsável por fornecer aos outros sistemas a energia de que necessitam para funcionar bem, neste caso optamos por utilizar simplesmente uma bateria e um regulador de tensão. Assim, para o dimensionamento da bateria, foram analisados alguns parâmetros de operação do CanSat, esses parâmetros auxiliariam na definição do modelo e da potência necessária para alimentar todo o sistema.

Considerando que o CanSat deveria durar várias horas ligado, o mais adequado foi considerar as situações mais extremas de consumo de energia, em que cada módulo e sistema acoplado ao CanSat consumiria a maior corrente possível. No entanto, também é importante ser razoável neste ponto para não superdimensionar a bateria, o que também não é interessante devido às limitações de peso do CanSat.

Após consulta a todas as fichas técnicas dos componentes de todos os sistemas, a corrente total consumida pelo sistema foi cerca de 160mAh, considerando uma autonomia de 10 horas, uma bateria de 1600mAh foi suficiente para garantir ao sistema as condições de funcionamento adequadas.

Depois de conhecer a carga necessária da bateria, há outros aspectos a considerar apesar da autonomia, como o tamanho, o peso, a temperatura de operação (desde que o CanSat seja mantido dentro de um foguete), as tensões e forças para a que o mesmo é submetido, entre outros.

Etapa 5: A Estrutura

A estrutura é muito importante para a segurança do CanSat, embora tenha sido um pouco negligenciada neste projeto (na verdade não houve muito interesse no desenvolvimento da parte mecânica do CanSat, devido ao fato de todos os membros cursarem estava relacionado à eletrônica). Desde que o projeto fosse baseado em um padrão existente, o padrão CanSat, não era preciso pensar muito em como seria sua aparência, então deveria ser moldado em formato de cilindro, com cerca de 6,1 cm de diâmetro e cerca de 11, 65 cm de altura (as mesmas medidas de uma lata de refrigerante).

Depois de feita a estrutura externa, a atenção foi toda voltada para o sistema de fixação, responsável por segurar todas as pranchas dentro da estrutura cilíndrica, possibilitando também a absorção das acelerações a que o CanSat seria submetido, após algumas discussões sobre o assunto, optou-se por anexar ambas as estruturas por moldagem de espuma de alta densidade, nos formatos desejados.

A estrutura externa foi construída utilizando tubos de PVC, com o diâmetro desejado, para o fechamento da estrutura foram utilizadas coberturas de tubos de PVC

Etapa 6: Conclusões e pensamentos futuros

O CanSat ainda precisa ser testado em ação, na verdade estamos nos inscrevendo para uma competição de foguetes (que vai acontecer em dezembro), também depois de passar por toda a construção (tipo, na verdade ainda precisamos terminar algumas coisas) e desenvolvimento processo, algumas perspectivas e notas que pensamos que seria interessante compartilhar com todos vocês foram observadas, principalmente sobre lutas, dicas e até boas experiências, então aqui vai:

- O início do projeto, veio a ser o período mais prolífico de desenvolvimento de todo o projeto, infelizmente o grupo ficou meio desinteressado do projeto no prazo final, talvez por falta de resultados imediatos, ou talvez apenas falta de comunicação, de qualquer maneira várias coisas boas saíram do projeto

- Demorou muito para fazer o transceptor funcionar, já que todas as bibliotecas foram desenvolvidas do zero, também porque são necessários dois programas e configurações diferentes para testar esse tipo de coisa

- No nosso caso não foi a melhor das ideias trabalhar em microcontroladores baseados em configurações de registros, nem todos os membros conseguiram acompanhar o resto do grupo, o que gerou alguns problemas como a divisão de tarefas. Existem toneladas de bibliotecas C decentes para o microcontrolador que estávamos usando, então teria sido uma ideia muito melhor usar esses recursos, há também um IDE chamado Code Composer, que também oferece toneladas de recursos para esses microcontroladores

- O CanSat ainda precisa de muitas melhorias, esta experiência foi baseada em técnicas e habilidades básicas, também várias questões não foram levadas em consideração, então, no futuro, esperamos que uma versão de primeira linha deste CanSat possa se tornar realidade com mais esforço e trabalho árduo.

Recomendado: