O pacote SatelliteToolbox.jl para Linguagem Julia

Olá!

Neste post, gostaria de apresentar o SatelliteToolbox.jl, que é um pacote para a linguagem Julia com muitas opções para analisar missões espaciais. Ele é usado diariamente no Instituto Nacional de Pesquisas Espaciais (INPE). Primeiramente, apresento um breve histórico sobre o pacote e, em seguida, mostro algumas análises interessantes que podem ser feitas com ele.

Histórico

Em 2013, ingressei no INPE como Engenheiro de Sistemas Espaciais Júnior. Fui designado para a divisão de sistemas espaciais onde tive que trabalhar com o subsistema de controle de atitude e órbita (AOCS). Como eu tinha apenas um conhecimento intermediário sobre órbitas, decidi me aprofundar nesse assunto codificando algoritmos e comparando os resultados com a herança do INPE e com a literatura no meu tempo livre.

O primeiro passo foi selecionar a linguagem! Em meu Doutorado, utilizei o MATLAB para simular um sistema de navegação inercial, mas as simulações de Monte Carlo eram tão lentas que precisei reescrever muitas partes em C usando CMEX. Por outro lado, na minha pesquisa de pós-doutorado, onde estudei estimação em sistemas distribuídos não-lineares, decidi usar FORTRAN (com os padrões de 2008 para ter pelo menos um código legível …) para que a velocidade de execução não fosse um problema. Sim, o desempenho foi muito bom, mas demorei muito tempo para codificar. Então ouvi falar de uma nova linguagem que prometia o melhor dos dois mundos: algo que se assemelhava a uma linguagem interpretada com a velocidade de uma linguagem compilada! E foi assim que conheci Julia.

Naquela época (usando a v0.2, eu acho), Julia era uma linguagem realmente nova. Mas decidi aceitar as dificuldades e tentar codificar meus algoritmos com ela. De qualquer forma, era apenas um pequeno projeto pessoal para aprender mais sobre órbitas. Eu enfrentei muitos bugs e até tive que usar o branch master (pre-v0.3) devido a alguns problemas e funcionalidades que não existiam, mas foi divertido 🙂

Depois de alguns anos (e várias re-escritas devido a mudanças na linguagem), a v0.4 da linguagem Julia foi lançada. Neste momento, dada a quantidade de código que eu tinha e o estado da linguagem, comecei a ver que esse monte de algoritmos poderia, de fato, ser utilizado para auxiliar minhas atividades no INPE. Por isso, decidi criar um pacote privado, chamado SatToolbox.jl, para organizar tudo o que fiz.

Depois de algum tempo, esse pequeno projeto pessoal acabou se tornando o núcleo de um simulador do conceito operacional de missões espaciais chamado Forplan, que está sendo desenvolvido no Centro de Projeto Integrado de Missões Espaciais (CPRIME) do INPE. Dado o bom feedback que recebi, decidi renomear o pacote para SatelliteToolbox.jl e lançá-lo como um pacote oficial da linguagem Julia em março de 2018.

Neste post, gostaria de descrever brevemente o SatelliteToolbox.jl e como ele pode ser utilizado para algumas análises relativas a missões espaciais. Todos os recursos disponíveis podem ser vistos na documentação (disponível apenas em inglês). Uma lista breve dos algoritmos implementados até o momento deste post (na v0.5.0) é:

  • Modelos atmosféricos terrestre:
  • Modelos do campo geomagnético:
  • Índices espaciais:
    • Capacidade de se obter automaticamente diversos índices espaciais, como F10.7, Ap, Kp, etc.
  • Funções para realizar análises gerais relacionadas com órbitas, como conversão de anomalias, cálculo de perturbações, etc.
  • Propagadores orbitais:
    • Two body;
    • J2; e
    • SGP4/SDP4.
  • Funções para converter entre sistemas de referência ECI e ECEF:
    • Toda a teoria IAU-76/FK5 é suportada. Então, a conversão entre quaisquer sistemas de referência a seguir está disponível:
      • ITRF: International Terrestrial Reference Frame;
      • PEF: Pseudo-Earth Fixed reference frame;
      • MOD: Mean-Of-Date reference frame;
      • TOD: True-Of-Date reference frame;
      • GCRF: Geocentric Celestial Reference Frame;
      • J2000: J2000 reference frame;
      • TEME: True Equator, Mean Equinox reference frame.
  • Funções para converter entre referências Geocêntricas e Geodésicas (WGS-84).

A seguir, eu forneço alguns exemplos de como o SatelliteToolbox.jl pode ser utilizado para analisar missões espaciais.

Instalação

A primeira coisa a se fazer (assumindo que você já instalou Julia, que pode ser obtida aqui) é instalar o pacote. Isso pode ser feito digitando:

Para carregar o pacote, que deve ser feito toda a vez que Julia é iniciada, digite:

Informação

Aqui e a seguir, o comando que você deve digitar é o que está apresentado depois de julia>, como você verá no Julia REPL. Todo o resto é o que você deve ver impresso na tela.

Exemplos

Agora, mostrarei algumas análises que podem ser feitas com as funções que estão disponíveis.

Requisitos necessários

Para manter este post pequeno, assumirei que você possui conhecimento sobre linguagem Julia e um pouco de experiência em assuntos relacionados a satélites e órbitas.

Ano Novo na ISS

Vamos ver como podemos calcular onde os astronautas a bordo da ISS estavam durante o Ano Novo em Greenwich! A primeira coisa que devemos fazer é obter a informação sobre a órbita da ISS. Nesse caso, devemos obter o TLE (Two-Line Element), que é um formato de dados consistindo em duas linhas com 70 carácteres cada e que contém toda a informação relacionada à órbita. O TLE a seguir foi obtido do site Celestrak em 4 de Janeiro de 2019, às 12:25 (horário de Brasília).

Esse TLE deve ser carregado em uma variável em Julia. Existem inúmeros métodos para se fazer isso utilizando o SatelliteToolbox.jl. Aqui, utilizaremos uma string especial:

Esse código carrega o primeiro TLE especificado dentro da string entre tle"""...""" para a variável iss_tle.

Agora, devemos inicializar um propagador orbital utilizando o TLE carregado. Nesse caso, vamos usar o SGP4:

A variável orbp agora possui a estrutura do propagador orbital do tipo SGP4 com a órbita especificada pelo TLE iss_tle. Esse TLE foi gerado no dia Juliano 2458487.75253 (2019-01-04 06:03:38.592 +0000). Portanto, devemos retro-propagar a órbita para o instante desejado 2019-01-01 00:00:00.000 +0000 (Ano Novo em Greenwich). Isso pode ser feito através da função propagate!. No entanto, essa função requer o número de segundos a partir da época em que os elementos orbitais foram definidos (nesse caso, a época do TLE) para o qual você deseja propagar a órbita. O código a seguir pode ser utilizado para fazer isso:

A função propagate! retorna três valores. O primeiro o são os elementos orbitais osculantes no instante da propagação, o segundo r_teme é o vetor posição e o último v_teme é o vetor velocidade. Esses vetores são representados no mesmo sistema de referência utilizado para descrever os elementos orbitais quando o propagador foi inicializado. Como estamos utilizando o TLE, então esses vetores estão representados no sistema de referência TEME (True Equator, Mean Equinox).

TEME é um sistema de referência inercial (ECI, Earth-Centered Inertial). Então, devemos converter o vetor posição para um sistema de referência fixo à Terra (ECEF, Earth-Centered, Earth-Fixed) para que possamos calcular a posição da ISS (latitude, longitude e altitude) no instante desejado. O SatelliteToolbox.jl possui toda a teoria IAU-76/FK5 relacionada com a conversão entre sistemas de referência. Neste exemplo, converteremos o TEME para o International Terrestrial Reference Frame (ITRF) para um cálculo mais preciso. Para esse tipo de conversão, deve-se obter os dados da orientação da Terra (EOP, Earth Orientation Data) que são fornecidos pelo IERS. O SatelliteToolbox.jl pode facilmente carregar e usar esses dados através do comando:

Aviso

Os dados EOP são medidos e publicados pelo IERS. Isso significa que o sistema de referência ITRF não pode ser utilizado aqui para prever qual será a posição da ISS, uma vez que os dados EOP não estarão disponíveis. Nesse caso, se um cálculo preciso não é necessário, então pode-se utilizar o sistema de referência Pseudo-Earth Fixed (PEF). A conversão entre o TEME e o PEF utilizando a teoria IAU-76/FK5 não requer dados externos.

A DCM (matriz de cosenos diretores) que gira o TEME para se alinhar ao ITRF é calculada por:

Então, o vetor posição representado no ITRF é:

Finalmente, considerando o elipsóide de referência WGS-84, a latitude, longitude e altitude da ISS durante o Ano Novo em Greenwich pode ser obtida pela função ECEFtoGeodetic conforme mostrado a seguir:

ou seja, latitude 46.189° S, longitude 112.319° W e altitude 419.859 km. Isso está de acordo com o histórico disponível no website I.S.S. Tracker:

Informação

A pequena diferença pode ser explicada pelo TLE que utilizamos para calcular a posição da ISS e o que é utilizado pelo histórico do I.S.S. Tracker. Uma vez que o TLE possui erros e a propagação orbital os aumenta, é melhor obter um TLE gerado o mais próximo possível do instante desejado. Isso não foi buscado aqui.

Perfil de densidade atmosférica

Neste segundo exemplo, usaremos as funções disponíveis no SatelliteToolbox.jl para calcular o perfil de densidade atmosférica. Existem muitos modelos disponíveis na literatura. O SatelliteToolbox.jl implementa quatro deles: o modelo atmosférico exponencial, o Jacchia-Roberts 1971, o Jacchia-Bowman 2008 e o NRLMSISE-00. Todos eles, exceto o primeiro, requerem como entrada alguns índices espaciais, como o F10.7, que mede a atividade do Sol, e o Ap, que mede a atividade geomagnética. O SatelliteToolbox.jl está preparado para obter todos os arquivos necessários da Internet a fim de que esses índices possam ser facilmente calculados. Isso pode ser feito por:

Informação

A keyword wdcfiles_newest_year não é necessária, mas foi utilizada aqui para evitar um erro dado que o arquivo kp2019.wdc não estava disponível quando esse tutorial foi escrito. Para maiores informações, veja a documentação.

Vamos calcular o perfil de densidade atmosférica de 100 km a 1000 km (passo de 1 km), utilizando todos os quatro modelos, em 2018-11-1 00: 00: 00 +0000 sobre a cidade de São José dos Campos, SP, Brasil (Latitude 23.2237 ° S, longitude 45,9009 ° W).

O modelo atmosférico exponencial, o mais simples, não depende nem dos índices espaciais nem da localização, apenas da altitude. Assim, o perfil atmosférico é calculado por:

Cada elemento é a densidade atmosférica [kg / m³] relacionada a uma altitude.

Informação

Aqui, utilizamos o operador de broadcast . para calcular a densidade em todo o intervalo de altitudes utilizando apenas uma linha de código. Para maiores informações, veja a documentação.

Para o modelo Jacchia-Robert 2008, devemos especificar a latitude geodésica [rad], a longitude [rad] e a altitude [m]. Observe que, como já inicializamos os índices espaciais, todas as informações necessárias serão obtidas automaticamente:

Cada elemento é uma instância da estrutura JB2008_Output que contém a densidade dos constituintes da atmosfera em [kg / m³] relacionadas a uma altitude.

O modelo NRLMSISE-00 requer as mesmas informações, mas em uma ordem diferente. Mais uma vez, como já inicializamos os índices espaciais, todas as informações necessárias são obtidas automaticamente:

Cada elemento é uma instância da estrutura NRLMSISE00_Output que contém a densidade dos constituintes da atmosfera em [kg / m³] relacionadas a uma altitude.

NRLMSISE-00 online

Os valores calculados aqui podem ser comparados à versão online do modelo NRLMSISE-00. Observe, no entanto, que a versão online no momento em que este tutorial foi escrito permite apenas o cálculo entre 1960/02/14 e 2018/03/17.

O modelo Jacchia-Roberts 1971 não possui suporte à obtenção automática dos índices espaciais ainda. Portanto, precisaremos fazer isso manualmente. São necessários três índices: o F10.7 diário, a média do F10.7 (janela de 81 dias, centrada no tempo de entrada) e o índice geomagnético Kp (com um atraso de 3 horas). Essa informação pode ser obtida por:

Assim, o perfil atmosférico computado por JR1971 é obtido por:

Cada elemento é uma instância da estrutura JR1971_Output que contém a densidade dos constituintes da atmosfera em [kg / m³] relacionadas a uma altitude.

Finalmente, utilizando o pacote PyPlot.jl, os perfis atmosféricos (altitude vs. densidade) em escala semi-log podem ser plotados usando:

que leva a:

Atmospheric density: 2018-11-01 00:00:00+0000

Para mais informações sobre as muitas opções para calcular a densidade atmosférica, consulte a documentação.

Atenção

Se a data desejada não estiver disponível nos arquivos dos índices espaciais, um erro será gerado ao calcular a densidade atmosférica.

Conclusão

Espero que este tutorial tenha ajudado você a entender um pouco de como o pacote SatelliteToolbox.jl pode ser usado para realizar análises relacionadas a satélites e órbitas. Se você tiver alguma dúvida, por favor, fique à vontade para deixar um comentário abaixo!

Atualização 2018-01-08: Correção do algoritmo que plota os dados, pois a variável h não estava corretamente definida (obrigado Bernard_GODARD).

Mudanças na v3 do OrdinaryDiffEq.jl

Olá!

Eu sei, um longo, longo tempo passou desde a minha última postagem. Eu gostaria de me desculpar! Estive muito ocupado devido a uma quantidade enorme de trabalho a ser feito no INPE.

De qualquer forma, esse será uma postagem pequena. Apenas gostaria de atualizar o código-fonte da última lição de tal forma que rode corretamente utilizando Julia v0.6 e OrdinaryDiffEq.jl v3.

Como eu disse, o pacote OrdinaryDiffEq.jl, que é parte do projeto JuliaDiffEq, é maravilhoso. Na minha humilde opinião, é um dos melhores solvers de equações diferenciais de código aberto disponíveis. O desenvolvimento dessa suíte está ocorrendo a uma taxa muito elevada. Isso é bom, pois o pacote tem ficado melhor a cada dia. O lado ruim é que a API também se altera muito rápido e às vezes seu código precisa ser modificado para continuar a funcionar nas novas versões.

Experiência necessária

Isso é apenas uma atualização do código-fonte apresentado na minha última postagem. Portanto, recomendo fortemente a lê-la primeiro:

https://www.ronanarraes.com/2017/02/estendendo-as-solucoes-de-edos-em-julia-atraves-da-criacao-de-data-arrays-customizados-para-as-simulacoes/

Mudanças na v3 do OrdinaryDiffEq.jl

Desde que eu postei meu último tutorial, a API do OrdinaryDiffEq.jl mudou (na verdade, a API é definida em DiffEqBase.jl, mas ele será atualizado quando você atualizar o OrdinaryDiffEq.jl). Existem três modificações que devem ser feitas para que o código-fonte anterior possa funcionar corretamente com Julia v0.6 e OrdinaryDiffEq.jl v3.0.3.

Interface de Array de Dados Customizada

Anteriormente, uma interface de array de dados customizada podia ser criada através de uma nova estrutura que herdava o tipo abstrato DEDataArray{T}. Isso se alterou e agora o novo tipo abstrato correto é DEDataVector{T}. Então, nossa definição do SimWorkspace deve ser:

Assinatura da equação dinâmica

Na versão utilizada no último tutorial, a assinatura da função dinâmica era:

Devido a algumas mudanças internas, a assinatura agora é:

p é um vetor de parâmetros que não é utilizado nesse exemplo, mas simplifica muitas coisas. Se você quiser saber mais informações, por favor veja http://docs.juliadiffeq.org/stable/tutorials/ode_example.html#Defining-Parameterized-Functions-1.

Assinatura da função de condição do callback

A assinatura da função de condição do callback se alterou de:

para:

Código-fonte atualizado

Finalmente, o código-fonte atualizado do último tutorial pode ser visto a seguir. Ele irá fornecer exatamente o mesmo resultado.

Conclusões

Esse tutorial apenas atualiza o código-fonte do último de tal forma que se possa executá-lo utilizando Julia v0.6 e OrdinaryDiffEq.jl v3.0.3.

Estou planejando para o meu próxima tutorial um exemplo simples de como codificar filtros de Kalman em linguagem Julia!

Estendendo as Soluções de EDOs em Julia Através da Criação de Data Arrays Customizados para as Simulações

NOTA: O código-fonte desse tutorial não irá funcionar nas últimas versões de Julia e OrdinaryDiffEq.jl. Você poderá ver uma versão atualizada do código-fonte aqui.

Olá!

Nesse post, eu mostrarei como podemo utilizar um Data Array para estender as possibilidade do pacote OrdinaryDiffEq da linguagem julia para simular sistemas dinâmicos.

Experiência necessária

Esse tutorial provê informações adicionais para resolver o problema introduzido no meu último tutorial, então é muito importante que você o leia antes:

https://www.ronanarraes.com/2017/02/utilizando-julia-para-simular-sistemas-compostos-de-partes-continuas-e-discretas/

Definição do problema

No meu último post, eu mostrei como o pacote OrdinaryDiffEq da linguagem julia pode ser utilizado para simular sistema de controle que possuem partes discretas e contínuas. No entanto, existiam dois grande problemas:

  1. Eu precisei utilizar uma variável global para passar a informação da parte discreta para a função dinâmica (naquele caso, a informação era a aceleração);
  2. Eu teria que utilizar alguns hacks muito ruins para plotar a aceleração comandada (criar um vetor global para guardar os valores computados).

Como mencionei anteriormente, a solução ótima para contornar esses problemas é era de alguma forma difícil de se obter. Felizmente,  Chris Rackauckas, que é o mantenedor do pacote OrdinaryDiffEq, introduziu o conceito de Data Arrays, que simplifica muito a solução para aqueles problemas. Note que você precisará da v1.4.0 ou superior do pacote OrdinaryDiffEq para ter acesso à nova interface Data Array.

Nesse tutorial, o problema que queremos resolver é: como criar parâmetros customizados em que a parte discreta do sistema modifica e que influenciará na função dinâmica?

Uma pequena história

Quando eu comecei a usar o OrdinaryDiffEq para simular o subsistema de controle e atitude do satélite Amazonia-1, eu verifiquei que eu precisaria de dois tipos de variáveis:

  1. Aquelas que compõe o vetor de estados e que serão integradas pelo solver; e
  2. Alguns parâmetros que o loop de controle pode modificar e que irá influenciar na solução dinâmica, como, por exemplo, o torque comandado para as rodas de reação e magneto-torquers.

Entretanto, naquela época, não existia um meio fácil de se conseguir isso. O único método é criar uma estrutura (type) customizada em julia para guardar os parâmetros que são externos ao vetor de estado. O problema é que você precisava implementar muitos métodos para que essa nova estrutura fosse compatível com a interface do OrdinaryDiffEq. A seguir, você poderá ver o que deveria ser feito para que se definisse um parâmetro chamado f1. Esse código foi utilizado na issue aberta por mim no GitHub: https://github.com/JuliaDiffEq/DifferentialEquations.jl/issues/117

Antiga forma de se criar uma estrutura customizada no OrdinariDiffEq

Então, Chris Rackauckas decidiu criar uma nova interface dentro do pacote OrdinaryDiffEq para que você possa facilmente construir suas próprias estruturas customizadas para serem utilizadas nos solvers.

Nota: Na verdade, a definição da nova interface foi colocada no pacote DiffEqBase, que é uma dependência do OrdinaryDiffEq.

Interface Data Type

Essa interface permite que você defina suas próprias estruturas a serem utilizadas pelo solver. Para fazer isso, você simplesmente precisa definir um novo tipo em julia (type) que herda o tipo DEDataArray:

onde deve existir um array x que define o vetor de estados e qualquer outro parâmetro que você irá necessitar na sua simulação. Dado isso, você poderá acessar quaisquer parâmetros dentro do solver e das funções de callback utilizando u.a, u.b, etc. Você poderá também acessar o i-ésimo elemento do vetor de estados utilizando u[i]. Em outras palavras, você não precisará da notação pesada u.x[i].

Isso praticamente substitui todo aquele código que eu mostrei anteriormente 👍.

Resolvendo o nosso problema

Então, agora nós podemos remover a variável global a (🎉🎊🎉🎊🎉🎊) definindo o seguinte tipo:

Dentro de nossa função dinâmica, nós podemos agora obter a aceleração comandada utilizando u.a:

Agora, nós precisamos apenas modificar a função efeito do nosso callback para escrever nessa variável:

Você deverá ter notado um for bem estranho aqui. Esse problema é criado pela estrutura interna do solucionadores de equações diferenciais ordinárias. Por exemplo, o Algoritmo Runge-Kutta de 4ª ordem necessita quatro caches chamados \(k_1\), \(k_2\), \(k_3\) e \(k_4\), que são basicamente a função dinâmica computada em diferentes pontos do espaço de estados, sendo utilizados para obter a solução no próximo instante de amostragem. Nesse caso, o parâmetro a deve ser definido em todos esses caches para fornecer a solução correta. Isso é precisamente o que aquele for está fazendo. Ele está passando por todos os caches no solver e definindo corretamente o parâmetro a com a aceleração computada pela função efeito desse callback. Note que o vetor de estado atual integrator.u está dentro da lista user_cache(integrator) e, consequentemente, é também definido dentro daquele loop. O lado bom de se utilizar esse for é que você não precisa se preocupar com quantos caches o solver selecionado possui.

Finalmente, nós precisamos apenas definir nosso estado inicial utilizando o tipo SimWorkspace:

onde o primeiro parâmetro está inicializando o vetor de estados com zeros (posição e velocidade) e o segundo parâmetro está inicializando a aceleração. Após a execução do programa, nós podemos acessar a aceleração comandada em cada instante de amostragem que foi salvo utilizando sol[i].a.

Se você estiver utilizando o PyPlot, então o vetor de estado e a aceleração podem ser plotados através de:

que deverá fornecer o seguinte resultado:

Se você quiser alterar o estado inicial, então você deverá apenas modificar a variável u0 antes de chamar o solver:

ou

que deverá fornecer o seguinte resultado:

Conclusões

Nesse tutorial, eu mostrei como você pode utilizar a interface Data Array do pacote OrdinaryDiffEq para criar espaços de trabalho customizados para suas simulaçãoes. Portanto, agora você sabe como criar parâmetros para serem utilizados no solver que não pertencem ao vetor de estado.

Eu forneci um exemplo através da extensão da solução apresentada em um tutorial anterior, onde nós precisamos de uma variável global para lidar com esse tipo de parâmetro. Note que, embora o exemplo apresentado aqui seja muito simples, esse conceito pode ser facilmente estendido para lhe fornecer uma solução simples e elegante para simular sistemas muito mais complexos.

Se não ficou claro, por favor, me avise nos comentário. Eu irei utilizar o seu conselho para melhorar esse e meus futuros tutoriais!

A seguir, você encontrará o código fonte desse tutorial.

Código fonte

Utilizando julia para simular sistemas compostos de partes contínuas e discretas

NOTA: O código-fonte desse tutorial não irá funcionar nas últimas versões de Julia e OrdinaryDiffEq.jl. Você poderá ver uma versão atualizada do código-fonte aqui. Note que a teoria permanece a mesma!

Olá!

Nesse primeiro post, eu gostaria de explicar como eu contornei um problema que eu sempre tive relacionado com a simulação de sistemas dinâmicos que possuem partes discretas e partes contínuas. Note que com certeza esse é o território do MathWorks® Simulink. Não existe dúvida que o Simulink é a ferramenta mais rápida de prototipagem de tais tipos de aplicação em que você possui um modelo dinâmico contínuo modificado por partes discretas que são amostradas em intervalos de tempo específicos.

Entretanto, existem algumas situações em que você não consegue utilizar o Simulink (não ter uma licença é a mais óbvia…). No meu caso de uso específico, eu estou codificando o simulador do Subsistema Controle de Atitude e Órbita (AOCS, em inglês) para o satélite Amazonia-1. O Simulink me deu alguns problemas relacionados com a simulação de algumas descontinuidades, como, por exemplo, sombras de algumas partes do satélite nos sensores solares. Verifiquei que eu necessitava de mais controle no solver do que o Simulink poderia me oferecer. Portanto, decidi transcrever o simulador para uma linguagem de programação “padrão”. Após um extensiva pesquisa, a linguagem julia e o pacote OrdinaryDiffEq me forneceram a melhor solução para simular o meu sistema. Portanto, neste post, gostaria de compartilhar como eu fui capaz de resolver o problema de simular sistemas com partes discretas e contínuas utilizando essas ferramentas.

Experiência necessária

Tentarei manter esse tutorial o mais simples possível. No entanto, ajudaria se você possuir um conhecimento mínimo sobre:

  1. Linguagem julia;
  2. Sistemas de controle; e
  3. Equações diferenciais ordinárias.

Definição do problema

Na maioria dos sistemas de controle, você possui quatro partes:

  1. A planta, que é o que você quer controlar;
  2. Os sensores, que medem quantidades relacionadas com os processos que você quer controlar;
  3. Os atuadores, que agirão e modificarão o estado da sua planta; e
  4. O controlador, que irá ler a saída dos sensores e comandará os atuadores para modificar a planta dado um conjunto de especificações.

No entanto, hoje em dia o controlador é normalmente embutido em um microcomputador, que possui intervalos pré-definidos para executar suas funções. Em outras palavras, apenas em intervalos de tempo específicos (chamados de instantes de amostragem) o controlador irá ler a saídas dos sensores, atualizar a lei de controle, e enviar novos comandos para os atuadores.

Para simular tais sistemas, você deverá considerar dois tipos de modelos: contínuos e discretos. A planta, por exemplo, é um modelo contínuo, uma vez que é normalmente modelada por um conjunto de equações diferenciais e geralmente varia para todo t. O controlador, conforme mencionado anteriormente, apenas atualiza seu estado interno em um conjunto de instantes determinados.

Academicamente falando, a simulação de um sistema desse tipo pode ser resolvida utilizando a transformada Z para converter o modelo contínuo da planta em um modelo discreto. Dessa forma, todos os modelos serão discretos e poderão ser facilmente simulados. Esse método possui muitos problemas. O maior deles, na minha opinião, é que ele funciona apenas para sistemas lineares e pode ser muito difícil de ser aplicado em plantas complexas com muitas variáveis de estado.

Portanto, o problema é: como eu posso utilizar uma linguagem de programação “padrão” para simular um sistema em que a parte contínua (a planta) é controlada por um processo discreto (o controlador)? Eu irei mostrar a seguir uma solução possível utilizando julia e o pacote OrdinaryDiffEq.

Sistema dinâmico proposto

Eu decidi propor um sistema dinâmico simples para ser controlado. Isso ajudará a tornar o tutorial mais interessante e fácil de entender. O problema que selecionei é um simples controle de uma partícula em uma dimensão definido como se segue:

Controlar a posição de uma partícula que se move em uma dimensão. Você poderá alterar a aceleração da partícula e você possuí acesso às medidas de posição e velocidade.

Essa partícula pode ser modelada por um conjunto de duas equações diferenciais descrevendo a derivada temporal de sua posição e velocidade:

\(\begin{array}{ccc} \dot{p} &=& v \\ \dot{v} &=& a \end{array} ,\)

onde \(p \) é a posição da partícula, \(v \) é a velocidade da partícula e \(a \) é a aceleração da partícula, que podemos controlar.

Então, definimos o vetor de estado como:

\(\mathbf{x} = \left[\begin{array}{c} p \\ v \end{array}\right] . \)

Finalmente, nosso sistema dinâmico pode ser escrito como:

\(\dot{\mathbf{x}} = \left[\begin{array}{cc} 0 & 1 \\ 0 & 0 \end{array}\right]\mathbf{x} + \left[\begin{array}{c} 0 \\ 1 \end{array}\right] \cdot a . \)

Nota: Esse é precisamente um daqueles sistemas que podem ser facilmente simulado utilizando a abordagem da transformada Z quando você possui um controlador discreto. Mas a ideia é manter esse tutorial simples de tal forma que você possa entender o conteito para estendê-lo a cenários mais complexos.

Controlador

Nós queremos controlar a aceleração de uma partícula de tal forma que ela vá para um ponto específico no espaço, chamado \(r \). Nesse caso, eu irei propor um controlador PD (muito) simples. A lei de controle será:

\(a = 0.3 \cdot (r-p) + 0.8 \cdot (0.0-v) \)

O controle deverá ser executado em um processo discreto que é atualizado a cada 1s.

Nota: Para aqueles que não estão familiarizados com sistemas de controle, apenas assuma que calculando a aceleração conforme mostrado aqui, nós podemos levar a partícula para a posição desejada \(r \).

Nas próximas seções, eu descreverei como você poderá usar julia e o pacote OrdinaryDiffEq para simular esse sistema em uma solução muito elegante. Você verá que será capaz de facilmente estender essa ideia para lidar com sistemas muito mais complexos.

Por que eu escolhi julia?!

No meu instituto, o INPE, eu tenho que responder quase todo dia o porquê eu escolhi julia como a linguagem de programação para realizar meu trabalho. É um pouco difícil introduzir novas tecnologias especialmente quando você está lidando com áreas que pessoas ainda utilizam FORTRAN devido a todos aqueles códigos legados.

Eu comecei a utilizar julia desde a versão 0.2 (estamos atualmente na versão 0.5). As razões do porquê eu realmente gostei dessa linguagem são:

  1. Ela parece uma linguagem interpretada no sentido que você não precisa se preocupar com os tipos das variáveis, o que deixa um programador MATLAB bastante confortável;
  2. Você pode muito facilmente chamar funções escritas em C / FORTRAN, isso é importante porque modelos como IGRF e MSIS são disponibilizados em FORTRAN;
  3. O desempenho das simulações quando a vetorização é impossível (ou muito difícil) é muito melhor que o de outras linguagens interpretadas (como MATLAB, Octave, Python, etc.);
  4. Você não precisa se preocupar em vetorizar o seu código;
  5. Programação paralela é muito fácil de se obter; e
  6. A sintaxe é muito elegante (ok, eu sei, isso é uma opinião pessoal 🙂 ).

Claro que existem muitos outros pontos positivos sobre julia, por favor visite o website http://www.julialang.org para mais informações.

Além disso, para o tipo de aplicação que eu estou focando nesse tutorial, o pacote OrdinaryDiffEq desenvolvido e mantido por Chris Rackauckas é único. Chris desenvolvou uma interface maravilhosa para se interagir com os solvers que deixa você fazer praticamente tudo. Conclusão: você possui todos aqueles solvers que você precisa (Runge-Kutta, Dormand-Prince, etc.) podendo interagir muito profundamente com o algoritmo para adaptá-lo às suas necessidades específicas. Devo admitir que eu não conheço nenhum outro pacote que forneça uma solução tão elegante para nenhuma outra linguagem (por favor, me avise nos comentários se eu estou me esquecendo de algo!).

Configuração

Primeiramente, faça o download do pacote julia apropriado para o seu sistema operacional em http://www.julialang.org (note que eu testei tudo aqui utilizando o openSUSE Tumbleweed e julia 0.5).

Após a instalação, abra julia e instale o OrdinaryDiffEq:

Para mais informações sobre esses comandos para instalar o pacote, por favor leia a documentação aqui: http://docs.julialang.org/en/stable/manual/packages/

Simulando o sistema

A primeira coisa é carregar os módulos que vamos precisar:

Resolver uma EDO utilizando o OrdinaryDiffEq é muito similar aos outros solver disponíveis no MATLAB, por exemplo ode45. Você deverá definir uma função dinâmica, selecionar o estado inicial, ajustar algumas opções, e chamar o solver. Então, vamos definir a função dinâmica.

No OrdinaryDiffEq, a função dinâmica deverá possuir a seguinte assinatura:

onde t é o tempo, u é o vetor de estado e du é a derivada temporal do vetor de estado. Note que u e du possuem a mesma dimensão do estado inicial. Essa função deverá computar du, mas o usuário deve ser bastante cuidadoso para não alterar a referência ao vetor! Caso contrário, o solver não irá utilizar o valor computado.

Para o nosso problema proposto, a função dinâmica será:

Nota 1: Nesse exemplo, a variável de aceleração será global. Isso tornará as coisas simples, mas é um padrão de codificação muito (MUITO) ruim. Entretanto, a maneira correta de se evitar essa variável global é um pouco mais complicada e será tratada em um tutorial futuro.

Nota 2: O sinal .= significa que os valores no lado esquerdo serão copiados para o vetor du sem a alteração da referência.

Ok, nosso modelo do sistema dinâmico (a parte contínua do nosso problema) está pronto! A seguir, nós iremos codificar a lei de controle discreta.

Controlador discreto utilizando callbacks

Callbacks são um tipo de interface com o solver que faz o pacote OrdinaryDiffEq ser bastante poderoso. Você define duas funções: uma para verificar se um evento ocorreu (função condição) e outra para ser executada caso esse evento tenha ocorrido (função efeito). Dessa forma, a cada instante de amostragem, o solver chama a função condição e, se ele disser que o evento ocorreu, então a função efeito é executada.

O OrdinaryDiffEq provê dois tipos de Callbacks: contínuos e discretos. Nesse caso, estamos interessados em callbacks discretos em que você consegue definir precisamente antes da execução quais serão os instantes de amostragem em que a função efeito será chamada. Para maiores informações, por favor veja a documentação em http://docs.juliadiffeq.org/latest/features/callback_functions.html

Vamos definir primeiro a função condição para verificar se nós estamos em um intervalo de amostragem em que a lei de controle deve ser atualizada:

A variável tf define o tempo de simulação e o array tstops define os intervalos de amostragem do loop de controle. A função condition_control_loop, nossa função condição, simplesmente verifica se t é um dos nossos intervalos de amostragem. Se essa função retornar true, então a função efeito será executada. Note que também é possível definir uma espécie de callback baseado no vetor de estado u, mas isto não é o nosso caso.

Não se preocupe com a variável integrator. Ela basicamente define uma interface com o integrador que deixa você verificar e alterar muitas e muitas coisas. Eu irei fornecer mais informações em tutoriais futuros. Se você desejar saber mais sobre isso, verifique a documentação em http://docs.juliadiffeq.org/latest/basics/integrator.html

Agora, vamos definir nossa função efeito que, nesse caso, é nosso controlador:

onde r é a posição de referência e k e d são, respectivamente, os termos proporcionais e derivativos do controlador PD. Nesse caso, o loop de controle apenas necessita calcular a nova aceleração, que está escrita na variável global 😕 a, utilizando a posição e velocidade atual da partícula.

Agora, nós definiremos o callback:

Executando o solver

Finalmente, precisamos apenas definir nosso estado inicial e chamar o solver do pacote OrdinaryDiffEq para solucionar o problema para nós:

Tsit5()significa que estamos utilizando o método Tsitouras 5/4 Runge-Kutta. Outras soluções possíveis são DP5() para o método Dormand-Prince’s 5/4 Runge-Kutta, ou BS3() para o método Bogacki-Shampine 3/2. Todos esses métodos possuem passo de amostragem adaptativo, que é uma boa escolha para simular sistemas dinâmicos, mas você também poderá escolher métodos com passo fixo. Para maiores informações, veja a documentação em http://docs.juliadiffeq.org/latest/solvers/ode_solve.html

Após isto, a solução do problema será armazenada na variável sol. O vetor de tempo contendo todos os passos de amostragem aceitos pelo solver é sol.t e os vetores de estado em cada um desses instantes são armazenados em sol.u.

Se você estiver utilizando o PyPlot, você poderá plotar os resultados utilizando:

O resultado esperado dessa simulação é:

Note que pode-se ver facilmente os pontos em que o loop de controle é calculado, onde imediatamente se altera a velocidade da partícula.

Conclusão

Nesse primeiro tutorial, eu mostrei como eu utilizei julia para simular sistemas que possuem partes contínuas e discretas. O conceito foi introduzido por um problema muito simples em que a posição de uma partícula deve ser controlada utilizando um loop de controle discreto.

Eu espero que você possa ter entendido o conceito e o quão fácil será estendê-lo para simulações muito mais complexas. Se não ficou claro, por favor, me avise nos comentário. Eu irei utilizar o seu conselho para melhorar esse e meus futuros tutoriais!

A seguir, você encontrará o código fonte desse tutorial.

Código fonte

Introduzindo… meu novo website!

Olá!

Eu finalmente decidi mudar o meu website do servidor do INPE (http://www.inpe.br/ete/dse/ronan) para o meu próprio servidor. Isso ocorreu porque eu precisava de mais liberdade para instalar um CMS, que não é possível atualmente no meu antigo servidor.

Hoje, eu finalmente terminei a configuração e agora vocês podem esperar alguns posts nas próximas semanas sobre o meu trabalho no INPE (o Instituto Nacional de Pesquisas Espaciais). Além disso, vou tentar disponibilizar tutoriais sobre modelagem e simulação de sistemas espaciais, que atualmente é uma das mais minhas maiores responsabilidades, bem como informações relacionadas a processamento de sinais, que foi a área do meu Doutorado.

A linguagem padrão de cada post será o Inglês, mas prometo me esforçar para traduzir cada um deles também para o Português.

Espero que gostem! Fiquem ligados 😉