juliaspace / satellitetoolbox.jl

A toolbox for satellite analysis written in julia language.

SatelliteToolbox.jl

The SatelliteToolbox.jl contains a set of packages with functions to perform analysis and build simulations related to satellites. It is used on a daily basis on projects at the Brazilian National Institute for Space Research (INPE).

The set of packages are listed bellow. All of them are loaded and reexported in this one.

Package Name	Description	Build Status	Coverage
SatelliteToolboxAtmosphericModels.jl	Atmospheric models
SatelliteToolboxBase.jl	Base functions and type definitions
SatelliteToolboxCelestialBodies.jl	Celestial bodies
SatelliteToolboxGeomagneticField.jl	Geomagnetic field models
SatelliteToolboxGravityModels.jl	Gravity models
SatelliteToolboxLegendre.jl	Legendre associated functions and its time-derivatives
SatelliteToolboxPropagators.jl	Orbit propagators
SatelliteToolboxSgp4.jl	SGP4/SDP4 orbit propagator
SatelliteToolboxTle.jl	Creating, fetching, and parsing TLEs
SatelliteToolboxTransformations.jl	Transformations (reference frames, time, etc.)

Installation

This package can be installed using:

julia> using Pkg
julia> Pkg.add("SatelliteToolbox")

Documentation

Please, see each package for the related documentation of the functions.

satellitetoolbox.jl's Issues

Add Vallado's site.m to the toolbox

One function that I think could be added is David Vallado's site.m routine. The description from the code is:

%  this function finds the position and velocity vectors for a site.  the
%    answer is returned in the geocentric equatorial (ecef) coordinate system.
%    note that the velocity is zero because the coordinate system is fixed to
%    the earth.

I have typed up a Julia version, though I have not been able to test/verify it as I do not own a Matlab license. Here is my initial attempt:

function site(latgd, lon, alt)
    # Constants, names in parantheses are the original Matlab variable names
    Rₑ = 6378.137         # km, (re)
    FLAT = 1.0/298.257223563  # (flat)
    eₑ = sqrt(2.0*FLAT - FLAT^2)  # (eccearth)
    eₑ₂ = eₑ^2  # (eccearthsqrd)


    # -------------------------  implementation   -----------------
    sinlat = sin(latgd)

    # ------  find rdel and rk components of site vector  ---------
    cearth = Rₑ/sqrt(1.0 - (eₑ₂*sinlat^2))
    rdel = (cearth + alt)*cos(latgd)
    rk = ((1.0 - eₑ₂)*cearth + alt)*sinlat

    # ---------------  find site position vector  -----------------
    rs = [rdel * cos(lon),
            rdel * sin(lon),
            rk]

    # ---------------  find site velocity vector  -----------------
    vs = [0.0, 0.0, 0.0];

    return rs, vs
end

Here is the original Matlab code:

function [rs,vs] = site ( latgd,lon,alt );

        constastro;

        % -------------------------  implementation   -----------------
        sinlat      = sin( latgd );

        % ------  find rdel and rk components of site vector  ---------
        cearth= re / sqrt( 1.0 - ( eccearthsqrd*sinlat*sinlat ) );
        rdel  = ( cearth + alt )*cos( latgd );
        rk    = ( (1.0-eccearthsqrd)*cearth + alt )*sinlat;

        % ---------------  find site position vector  -----------------
        rs(1) = rdel * cos( lon );
        rs(2) = rdel * sin( lon );
        rs(3) = rk;
        rs = rs';
        
        % ---------------  find site velocity vector  -----------------
        [vs] = [0.0; 0.0; 0.0];

Thanks!

Add propagation API to a specific time

We should have an API like:

propagate!(orbp, t::Number)

that will propagate the orbit to the epoch t.

Tests error with Interpolations v0.13.3

Tests of this package error with Interpolations v0.13.3 but pass with v0.13.2. The error message is:

Testing Running tests...
Function jb2008: Error During Test at C:\dev\SatelliteToolbox.jl\test\earth\atmospheric_models\jb2008\jb2008.jl:41
  Got exception outside of a @test
  MethodError: Cannot `convert` an object of type 
    Interpolations.GriddedInterpolation{Float64{},1,Float64{},Interpolations.Gridded{Interpolations.Linear{Interpolations.Throw{Interpolations.OnGrid}}},Tuple{Array{Float64{},1}}} to an object of type 
    Interpolations.GriddedInterpolation{Float64{},1,Float64{},Interpolations.Gridded{Interpolations.Linear},Tuple{Array{Float64{},1}}}
  Closest candidates are:
    convert(::Type{T}, ::Factorization) where T<:AbstractArray at C:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.6\LinearAlgebra\src\factorization.jl:58
    convert(::Type{T}, ::T) where T<:AbstractArray at abstractarray.jl:14
    convert(::Type{T}, ::T) where T at essentials.jl:205
    ...
  Stacktrace:
    [1] SatelliteToolbox._DTCFILE_Structure(DstΔTc::Interpolations.GriddedInterpolation{Float64, 1, Float64, Interpolations.Gridded{Interpolations.Linear{Interpolations.Throw{Interpolations.OnGrid}}}, Tuple{Vector{Float64}}})
      @ SatelliteToolbox C:\dev\SatelliteToolbox.jl\src\earth\space_indices\dtcfile.jl:27
    [2] _parse_dtcfile(path::String)
      @ SatelliteToolbox C:\dev\SatelliteToolbox.jl\src\earth\space_indices\dtcfile.jl:167
    [3] _init_dtcfile(; force_download::Bool, local_path::String)
      @ SatelliteToolbox C:\dev\SatelliteToolbox.jl\src\earth\space_indices\dtcfile.jl:103
    [4] init_space_indices(; enabled_files::Vector{Symbol}, dtcfile_path::String, dtcfile_force_download::Bool, fluxtable_path::String, fluxtable_force_download::Bool, solfsmy_path::String, solfsmy_force_download::Bool, wdcfiles_dir::Nothing, wdcfiles_force_download::Bool, wdcfiles_oldest_year::Int64, wdcfiles_newest_year::Nothing)
      @ SatelliteToolbox C:\dev\SatelliteToolbox.jl\src\earth\space_indices\space_indices.jl:277

This can be triggered with init_space_indices(). Looking at the source code briefly it's probably the definition

SatelliteToolbox.jl/src/earth/space_indices/space_indices.jl

Lines 17 to 19 in 0100e74

	const _space_indices_itp_linear{T} =
	Interpolations.GriddedInterpolation{T,1,T, Gridded{Linear},
	Tuple{Array{Float64,1}}}

I wonder if there is a more general way to handle these Interpolations types while maintaining type stability here. After all, it shouldn't have broken on a patch version update of Interpolations.

Exception type changed on Julia master (1.4)

Tests for this package fails on the Julia branch that will eventually become 1.4 with

Checksum errors: Test Failed at /home/pkgeval/.julia/packages/SatelliteToolbox/blx7k/test/submodules/SatelliteToolboxTLE/tle.jl:135
  Expression: read_tle_from_string("1 22490U 93009B   18165.62596833  .00000225  00000-0  11410-4 0  9991", "2 22490  24.9690 231.7852 0042844 200.7311 292.7198 14.44524498338063", verify_checksum = true)
    Expected: ErrorException
      Thrown: MethodError
Stacktrace:
 [1] top-level scope at /home/pkgeval/.julia/packages/SatelliteToolbox/blx7k/test/submodules/SatelliteToolboxTLE/tle.jl:135
 [2] top-level scope at /workspace/srcdir/usr/share/julia/stdlib/v1.4/Test/src/Test.jl:1116
 [3] top-level scope at /home/pkgeval/.julia/packages/SatelliteToolbox/blx7k/test/submodules/SatelliteToolboxTLE/tle.jl:125

Maneuvers, state changes

Is it possible to perform maneuvers with the current SatelliteToolbox.jl? I'm trying to figure out if I could perform impulse maneuvers by directly changing values within orbit propagators. I'm also wondering about drag maneuvers, I suppose I could initialize a new propagator at the beginning of a drag maneuver based on a satellite's current ephemeris and use a different drag term, then initialize another at the end of the maneuver.

@pack!_SGP4_DeepSpace not defined

Precompiling SatelliteToolbox v0.3.1 gives the following error.

julia> using SatelliteToolbox
[ Info: Precompiling SatelliteToolbox [6ac157d9-b43d-51bb-8fab-48bf53814f4a]
┌ Warning: The macro `@pack` is deprecated, use `@pack!`
│   caller = #macroexpand#32 at expr.jl:92 [inlined]
└ @ Core .\expr.jl:92
ERROR: LoadError: LoadError: LoadError: LoadError: UndefVarError: @pack!_SGP4_DeepSpace not defined
Stacktrace:
 [1] top-level scope
 [2] #macroexpand#32 at .\expr.jl:92 [inlined]
 [3] macroexpand at .\expr.jl:91 [inlined]
 [4] docm(::LineNumberNode, ::Module, ::Any, ::Any, ::Bool) at .\docs\Docs.jl:509 (repeats 2 times)
 [5] @doc(::LineNumberNode, ::Module, ::String, ::Vararg{Any,N} where N) at .\boot.jl:451
 [6] include at .\boot.jl:317 [inlined]
 [7] include_relative(::Module, ::String) at .\loading.jl:1038
 [8] include at .\sysimg.jl:29 [inlined]
 [9] include(::String) at C:\Users\user\.julia\packages\SatelliteToolbox\R79gy\src\SatelliteToolbox.jl:1
 [10] top-level scope at none:0
 [11] include at .\boot.jl:317 [inlined]
 [12] include_relative(::Module, ::String) at .\loading.jl:1038
 [13] include(::Module, ::String) at .\sysimg.jl:29
 [14] top-level scope at none:2
 [15] eval at .\boot.jl:319 [inlined]
 [16] eval(::Expr) at .\client.jl:399
 [17] top-level scope at .\none:3
in expression starting at C:\Users\user\.julia\packages\SatelliteToolbox\R79gy\src\orbit\propagators\sgp4.jl:998
in expression starting at C:\Users\user\.julia\packages\SatelliteToolbox\R79gy\src\orbit\propagators\sgp4.jl:611
in expression starting at C:\Users\user\.julia\packages\SatelliteToolbox\R79gy\src\orbit\propagators\sgp4.jl:611
in expression starting at C:\Users\user\.julia\packages\SatelliteToolbox\R79gy\src\SatelliteToolbox.jl:73
ERROR: Failed to precompile SatelliteToolbox [6ac157d9-b43d-51bb-8fab-48bf53814f4a] to C:\Users\user\.julia\compiled\v0.7\SatelliteToolbox\VRH6F.ji.
Stacktrace:
 [1] macro expansion at .\logging.jl:313 [inlined]
 [2] compilecache(::Base.PkgId, ::String) at .\loading.jl:1185
 [3] macro expansion at .\logging.jl:311 [inlined]
 [4] _require(::Base.PkgId) at .\loading.jl:941
 [5] require(::Base.PkgId) at .\loading.jl:852
 [6] macro expansion at .\logging.jl:311 [inlined]
 [7] require(::Module, ::Symbol) at .\loading.jl:834

julia> versioninfo()
Julia Version 0.7.0
Commit a4cb80f3ed (2018-08-08 06:46 UTC)
Platform Info:
  OS: Windows (x86_64-w64-mingw32)
  CPU: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-6.0.0 (ORCJIT, skylake)
Environment:
  JULIA_EDITOR = "C:\Users\user\AppData\Local\atom\app-1.30.0\atom.exe" -a
  JULIA_NUM_THREADS = 4

Is it possible to divide the package into different packages?

It is a nice package! I have learned both Julia and simulation by reading the code.
I wonder if it is possible to divide the whole package into different packages. Because I think some parts of the code are also useful in other fields (e.g., GNSS navigation, ionosphere). I think each model (IGRF, MSISE00, etc) can be divided into an individual package. I read some parts of the code and found that these models are almost independent. if this huge package consists of many smaller packages which are separated from the package by using , it would be easier to read, maintain, and use.

Integer conversion from Julian Day to DateTime fails when the seconds are 0

The integer conversion from Julian Day to DateTime has a bug when the seconds are 0:

julia> JDtoDate(Int, 2.45754095833333e6)
(2016, 6, 1, 10, 59, 60)

The DateTime conversion will fail if the seconds are equal or large then 60.

Breaking change in `propagate!`

I found a breaking change in how propagate! and propagate_to_epoch! are used in v0.9.0 and wanted to make sure it was brought up!

The old usage was (pull from the docs):

o,r,v = propagate!(orbp, collect(0:3:24)*60*60);

whereas the new usage is:

r, v = propagate!(orbp, collect(0:3:24)*60*60);

Running my old programs with SatelliteToolbox v0.9.0, I get the error

ERROR: LoadError: BoundsError: attempt to access Tuple{StaticArrays.SVector{3, Float64}, StaticArrays.SVector{3, Float64}} at index [3]
Stacktrace:
 [1] indexed_iterate(t::Tuple{StaticArrays.SVector{3, Float64}, StaticArrays.SVector{3, Float64}}, i::Int64, state::Int64)
   @ Base ./tuple.jl:86
 [2] top-level scope
   @ ~/path/to/file.jl:28
in expression starting at /home/thatch/path/to/file.jl:28

where the offending line is the second one below:

tleprop = init_orbit_propagator(Val(:sgp4), tle);
_,rTEME,vTEME = propagate_to_epoch!(tleprop,JD); # this is line 28

So it seems like the issue is that my old code is trying to unpack 3 return values from the propagate_to_epoch! function, but in v0.9.0 only two are returned.

It'll be pretty easy to make this change in my code base, but it would be good to have this mentioned in the release notes, or included in the deprecation warnings if possible. I'd imagine a lot of users make use of the propagate functions, so this API change might cause trouble for other users as well.

How to convert velocities from ECEF to ECI?

I have converted the coordinates from ECEF to ECI. How to convert velocities also?

Sunposition?

Not really an issue, but I have code in native Julia for the sun position at given geodetic coordinates and time, returning zenith angle and azimuth. We use this to calculate the sun position relative to the satellite. It is quite fast. I never got around to put this into a package, but if you think it might fit, I would try to come up with a pull request for the SatelliteToolbox?

Some more details:

Functions for calculating the Sun's position described in
Roberto Grena (2012), Five new algorithms for the computation of sun position
from 2010 to 2110, Solar Energy, 86(5):1323–1337, doi:10.1016/j.solener.2012.01.024.

URLs:
http://adsabs.harvard.edu/abs/2012SoEn...86.1323G

The Julia code was transcribed from C++ obtained at
http://www.solaritaly.enea.it/StrSunPosition/SunPositionEn.php

by Stephan Buchert, Swedish Institute of Space Physics, [email protected]

Examples for usage:

zenith,azimuth,rightAscension,declination,hourAngle =
sunpos(...

Add fast algorithms to compute the position of the planets

We need a fast algorithm to compute the position of the planets so that we can use in a numerical orbit propagator.

Why the track is not drifting?

Hi. I used an example from the SatelliteToolbox.jl‘s document.

orbp = init_orbit_propagator(Val(:twobody), 
    KeplerianElements(0.0, 7130982.0, 0.001111, 98.405*pi/180, pi/2, 0.0, 0.0) )
r,_ = propagate!(orbp, collect(0 : 5 : 5 * 24 * 3600))

I convert r to geodetic coordinates. And the coordinates are drawn using GMT. Why the track is not drifting?

Dependency compatibility

I had a version conflict with another package that required Interpolations 0.13 while SatelliteToolbox requires 0.12. I could open a PR for Satellite Toolbox to update Interpolations to 0.13, but it requires changing the definition of _space_indices_itp_constant{T} in a backwards-incompatible way (we could not have a compat entry for Interpolations with 0.12, 0.13).

While looking at SatelliteToolbox's Project.toml file, I realized StaticArrays compat entry is also set to 0.12 instead of 1 (or possibly 0.12,1). This cannot be updated at this time because ReferenceFrameRotations compat for StaticArrays is also set to 0.12.

The new versions of these packages are only a few months old, but it might be worthwhile to add the GitHub action for CompatHelper to keep track of these updates.

Fix documentation of the function list_ss_orbits_by_rep_period

The returned matrix of the function list_ss_orbits_by_rep_period is not described correctly in the documentation.

Account for Earth shape when computing the eclipse

The algorithm that computes in which zone the satellite is (sunlight, penumbra, and umbra) assumes that the Earth is a sphere with the Equatorial radius. It will be more precise if we account for at least the Earth oblateness when doing this.

Generalize `ground_station_visible` to allow for arbitrary azimuth/elevation pointing

I have a use case for calculating ground station accesses for satellites, however, the ground stations I need to use employ off-zenith pointings. It would be helpful if ground_station_accesses and list_ground_station_accesses were generalized for arbitrary azimuth/elevation pointing of a ground station.

If it helps, I found this document that discusses arbitary access. However, it is limited to a) circular orbits, b) that are not tied to Earth's rotation (geo-synchronous), and c) it does not calculate detailed timing, but probability distributions for being inside a certain viewing window.

Reference to geodesic coordinate frames

I think it would be very useful to add to the documentation a standard reference (textbook) where the coordinate systems mentioned in

https://juliaspace.github.io/SatelliteToolbox.jl/dev/man/transformations/ecef_eci/

are defined.

Unable to change degree of gravity model

Hi,

The n_max variable given to compute_g() doesn't get used,
as in compute_dU() n_max gets overwritten by the '@unpack_GravityModel_Coefs gm_coefs' command.
Therefore the maximum degree of the gravity model is always used.

fluxtable link broken

It seems that the ftp server below has some problems.
ftp://ftp.geolab.nrcan.gc.ca/data/solar_flux/daily_flux_values/fluxtable.txt
When I used wget, it said "unable to resolve host address ‘ftp.geolab.nrcan.gc.ca’"

---

I think the new link might be
ftp://ftp.seismo.nrcan.gc.ca/spaceweather/solar_flux/daily_flux_values/fluxtable.txt

Consider breaking out components?

Hi,

Congrats on the nice package, there is a lot of really great stuff in here! Have you considered moving things into smaller, dedicated packages? For instance, just from a quick browse of the code, I think the following components would lend themselves well to being standalone packages:

• Geomagnetic field
• Gravity field
• the pure julia sgp4
• potentially the frame transformations

I think most of these would also be useful to people who do not necessarily have interest in satellite mission analysis, and who otherwise would not know this functionality exists.

Fix how types are printed

We are overloading the display function to print types, e.g. Orbit and TLE. However, we should overload the show function with the correct MIME type.

Complex Values Causing Issues in JB2008

Something strange is happening with complex variables in the JB2008 model. I tried changing all the erroneous exponentials to Complex(x)^y, but that didn't fix it. I'm trying to compare GOCE neutral density data to JB2008's predictions in May 2010. This error seems to happen for most of that month (~180,000/~242,000 times). I haven't seen any errors like this for several other runs.

ERROR: DomainError with -0.9862171602726729:
Exponentiation yielding a complex result requires a complex argument.
Replace x^y with (x+0im)^y, Complex(x)^y, or similar.
Stacktrace:
[1] throw_exp_domainerror(::Float64) at ./math.jl:36
[2] ^ at ./math.jl:849 [inlined]
[3] jb2008(::Float64, ::Float64, ::Float64, ::Float64, ::Float64, ::Float64, ::Float64, ::Float64, ::Float64, ::Float64, ::Float64, ::Float64, ::Float64) at /Users/abukowski/.julia/packages/SatelliteToolbox/blx7k/src/earth/atmospheric_models/jb2008/jb2008.jl:201
[4] top-level scope at REPL[3]:1

jb2008(DatetoJD(2010, 5, 1, 0, 44, 18), deg2rad(355.94), deg2rad(83.40), 292000.00, 80.80,76.40,78.70,73.10,79.00,75.90,86.80,79.60,31.00)

Any ideas?

Documentation out of date for init_orbit_propagator

Example usage for init_orbit_propagator not working for julia 1.4 (does work in 1.2):

julia> tle_scd1 = tle"""
       SCD 1
       1 22490U 93009B   18350.91204528  .00000219  00000-0  10201-4 0  9996
       2 22490  24.9683 170.6788 0043029 357.3326 117.9323 14.44539175364603
       """[1];

julia> orbp = init_orbit_propagator(Val(:sgp4), tle_scd1);

Running this code results in error

julia> orbp = init_orbit_propagator(Val(:sgp4), tle_scd1);
ERROR: MethodError: no method matching init_orbit_propagator(::Val{:sgp4}, ::TLE)
Closest candidates are:
  init_orbit_propagator(::Type{Val{:J2}}, ::TLE) at /.julia/packages/SatelliteToolbox/0jge1/src/orbit/propagators/api/init_orbit_propagator.jl:219
  init_orbit_propagator(::Type{Val{:J2}}, ::TLE, ::J2_GravCte) at /.julia/packages/SatelliteToolbox/0jge1/src/orbit/propagators/api/init_orbit_propagator.jl:219
  init_orbit_propagator(::Type{Val{:J4}}, ::TLE) at /.julia/packages/SatelliteToolbox/0jge1/src/orbit/propagators/api/init_orbit_propagator.jl:266
  ...
Stacktrace:
 [1] top-level scope at none:0

How to cite SatelliteToolbox.jl?

Hi!

First of all, thank you for this awesome package! We're currently using it in some of our research, and was wondering if there is any recommended way to include a citation? Is there any DOI or some other reference that we could use?

Add documentation for API functions that converts state vectors

The API functions that transform the reference frame of state vectors svECEFtoECEF, sECEFtoECI, sECItoECEF, and sECItoECI do not have documentation yet.

Make the GFC parser more generic

I have successfully used the parse_gfc function to parse a lunar gravity field. But I had to massage the file a little to make it work, e.g. change some constant from Fortran-style 1D+0.0 to normal scientific notation and change gravity_constant in the header to earth_gravity_constant.

Could the parser be made more generic so that it handles other celestial bodies (or rather non-standard GFC files)? These can be found here for example (if the website is not down, as it is now).

Fix satellite_check_station

The function satellite_check_station is broken. It must handle SVector correctly.

Generalize geodetic coordinate conversion by using Geodesy.jl

Thanks for the great job on the SatelliteToolbox, it is really useful for my work!
I was wondering if it has been already considered the possibility of using Geodesy.jl to generalize the ECEF<->LLA coordinates conversion. It would allow to support different Datum and also transformations to local coordinate systems like ENU.

Do not allow initialization of SGP4 with classical orbit elements

SGP4 is an algorithm designed to be used with TLE data, which has a specific set of mean elements computed by Kozai theory. Using it with a set of classical orbit elements can lead to discrepancies. Hence, we need to do two things:

• Add a J4 orbit propagator for mission analysis, which can receive as input the mean orbital elements.
• Allow SGP4 to be initialized in the API only using TLEs.

TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

Read eop from file

I want to read eop file locally, because ECItoECEF and ECEFtoECEF doesn't work without eop.
I downloaded the eop file from here.

eop = read_iers_eop(eop_file, :IAU2000A)

ERROR: LoadError: MethodError: no method matching rECEFtoECEF(::Type{Val{:PEF}}, ::Type{Val{:ITRF}}, ::Float64, ::SatelliteToolbox.EOPData_IAU2000A{Interpolations.Extrapolation{Float64,1,Interpolations.GriddedInterpolation{Float64,1,Float64,Interpolations.Gridded{Interpolations.Linear},Tuple{Array{Float64,1}},0},Interpolations.Gridded{Interpolations.Linear},Interpolations.OnGrid,Interpolations.Flat}})

init_space_indices() interpolation error

Hi,
I'm currently experiencing issue with the function init_space_indices(), interpolations is returning an error
I tried to use it in a clean new environment called test. I've used the function in the past (in april) with success.

Any idea what's going on?

I'm using Julia 1.6

Thanks

(@v1.6) pkg> activate test

(test) pkg> add SatelliteToolbox
    Updating registry at `~\.julia\registries\General`
    Updating git-repo `https://github.com/JuliaRegistries/General.git`
   Resolving package versions...
    Updating `.\test\Project.toml`
  [6ac157d9] + SatelliteToolbox v0.8.0
    Updating `.\test\Manifest.toml`
  [79e6a3ab] + Adapt v3.3.0
  [13072b0f] + AxisAlgorithms v1.0.0
  [a8cc5b0e] + Crayons v4.0.4
  [9a962f9c] + DataAPI v1.6.0
  [e2d170a0] + DataValueInterfaces v1.0.0
  [5789e2e9] + FileIO v1.9.0
  [59287772] + Formatting v0.4.2
  [cd3eb016] + HTTP v0.8.19
  [83e8ac13] + IniFile v0.5.0
  [a98d9a8b] + Interpolations v0.13.2
  [82899510] + IteratorInterfaceExtensions v1.0.0
  [739be429] + MbedTLS v1.0.3
  [6fe1bfb0] + OffsetArrays v1.8.0
  [fbd9d27c] + OptionalData v0.3.0
  [bac558e1] + OrderedCollections v1.4.1
  [d96e819e] + Parameters v0.12.2
  [3a141323] + PolynomialRoots v1.0.0
  [08abe8d2] + PrettyTables v0.11.1
  [c84ed2f1] + Ratios v0.4.0
  [189a3867] + Reexport v1.0.0
  [74f56ac7] + ReferenceFrameRotations v0.5.7
  [cbe49d4c] + RemoteFiles v0.3.1
  [ae029012] + Requires v1.1.3
  [6ac157d9] + SatelliteToolbox v0.8.0
  [90137ffa] + StaticArrays v1.2.0
  [3783bdb8] + TableTraits v1.0.1
  [bd369af6] + Tables v1.4.2
  [3a884ed6] + UnPack v1.0.2
  [efce3f68] + WoodburyMatrices v0.5.3
  [0dad84c5] + ArgTools
  [56f22d72] + Artifacts
  [2a0f44e3] + Base64
  [ade2ca70] + Dates
  [8bb1440f] + DelimitedFiles
  [8ba89e20] + Distributed
  [f43a241f] + Downloads
  [b77e0a4c] + InteractiveUtils
  [b27032c2] + LibCURL
  [76f85450] + LibGit2
  [8f399da3] + Libdl
  [37e2e46d] + LinearAlgebra
  [56ddb016] + Logging
  [d6f4376e] + Markdown
  [a63ad114] + Mmap
  [ca575930] + NetworkOptions
  [44cfe95a] + Pkg
  [de0858da] + Printf
  [3fa0cd96] + REPL
  [9a3f8284] + Random
  [ea8e919c] + SHA
  [9e88b42a] + Serialization
  [1a1011a3] + SharedArrays
  [6462fe0b] + Sockets
  [2f01184e] + SparseArrays
  [10745b16] + Statistics
  [fa267f1f] + TOML
  [a4e569a6] + Tar
  [8dfed614] + Test
  [cf7118a7] + UUIDs
  [4ec0a83e] + Unicode
  [deac9b47] + LibCURL_jll
  [29816b5a] + LibSSH2_jll
  [c8ffd9c3] + MbedTLS_jll
  [14a3606d] + MozillaCACerts_jll
  [83775a58] + Zlib_jll
  [8e850ede] + nghttp2_jll
  [3f19e933] + p7zip_jll

julia> using SatelliteToolbox

julia> init_space_indices()
ERROR: knot-vectors must be unique and sorted in increasing order
Stacktrace:
  [1] error(s::String)
    @ Base .\error.jl:33
  [2] check_gridded
    @ ~\.julia\packages\Interpolations\GIn2o\src\gridded\gridded.jl:51 [inlined]
  [3] Interpolations.GriddedInterpolation(#unused#::Type{Float64}, knots::Tuple{Vector{Float64}}, A::Vector{Float64}, it::Interpolations.Gridded{Interpolations.Constant{Interpolations.Nearest}})
    @ Interpolations ~\.julia\packages\Interpolations\GIn2o\src\gridded\gridded.jl:32
  [4] interpolate(#unused#::Type{Float64}, #unused#::Type{Float64}, knots::Tuple{Vector{Float64}}, A::Vector{Float64}, it::Interpolations.Gridded{Interpolations.Constant{Interpolations.Nearest}})
    @ Interpolations ~\.julia\packages\Interpolations\GIn2o\src\gridded\gridded.jl:66
  [5] interpolate
    @ ~\.julia\packages\Interpolations\GIn2o\src\gridded\gridded.jl:83 [inlined]
  [6] _parse_fluxtable(path::String)
    @ SatelliteToolbox ~\.julia\packages\SatelliteToolbox\EL8pX\src\earth\space_indices\fluxtable.jl:111
  [7] _init_fluxtable(; force_download::Bool, local_path::Nothing)
    @ SatelliteToolbox ~\.julia\packages\SatelliteToolbox\EL8pX\src\earth\space_indices\fluxtable.jl:56
  [8] #init_space_indices#144
    @ ~\.julia\packages\SatelliteToolbox\EL8pX\src\earth\space_indices\space_indices.jl:285 [inlined]
  [9] init_space_indices()
    @ SatelliteToolbox ~\.julia\packages\SatelliteToolbox\EL8pX\src\earth\space_indices\space_indices.jl:277
 [10] top-level scope
    @ REPL[4]:1

(test) pkg> status
      Status `.\test\Project.toml`
  [6ac157d9] SatelliteToolbox v0.8.0

Lambert solver

Is there a Lambert problem solver in SatelliteToolbox.jl? I used poliastro in Python and wondering whether there is such function in Julia?

Export OrbitPropagatorTwoBody

The structure OrbitPropagatorTwoBody is not being exported.

Simplify the API related to the coordinate transformations

In the API of coordinate transformations (rECEFtoECI, etc.) we have a parameter to select which theory we should use. According to Vallado, when implementing IAU2000, it is better to use the CIO approach. In this case, the name of the intermediate reference systems will not be equal to those of IAU76 theory. In the former we have ITRF <-> PEF<-> TOD <-> GCRF, whereas in the latter we have ITRF <-> TIRS <-> CIRS <-> GCRF.

Hence, in most scenarios we can infer which theory is desired by only looking the reference systems. The only possible confusion would be the conversion ITRF <-> GCRF. However, in this case, we need the EOP data, and then we can also infer the desired theory by looking the EOP data type.

Deprecate satellite_orbit_compute_f

The function satellite_orbit_compute_f must be deprecated in favor of M_to_f.

Remove unecessary headers in the files

SatelliteToolbox.jl at the very beginning was developed outside a git. Hence, all files received a header with Authors, Description, References, and Changelog. This is no longer required. Hence, it is better to remove all this information at the Headers and leave only the Description and References.

Adapt rECEFtoECI and rECItoECEF to use the original IAU-76/FK5 theory

Sometimes the user should want to use the original IAU-76/FK5 theory. In current state, it is necessary to access low level functions to do this. Hence, we should adapt rECEFtoECI and rECItoECEF(possibly rECItoECI) to provide an option to neglect the EOP corrections.

The transformations that should be feasible neglecting EOP are:

• PEF <=> TOD
• PEF <=> MOD
• PEF <=> J2000 (this is already available in rECEFtoECI and rECItoECEF)
• MOD <=> TOD (should we do this?)

Missing nutation_fk5 method?

Hi @ronisbr! This is an awesome package! I'm using nutation_fk5 to compute some reductions; nutation_fk5 takes Julian dates as an input, i.e. currently there is nutation_fk5(JD_TT::Number), where JD_TT represents a Julian date (TT):

SatelliteToolbox.jl/src/transformations/fk5/nutation.jl

Line 183 in e4b2610

function nutation_fk5(JD_TT::Number, n_max::Number = 106, nut_coefs_1980::Matrix = nut_coefs_1980)

I was wondering if there is another method for nutation_fk5 which takes "days since J2000" instead as input? If there is no such method, I'd be happy to add it! In that case, would you guys accept such a PR?

Error in JDtoDate

JDtoDate changes the 12th month to a 0th month:

julia> JDtoDate(DatetoJD(2018,12,20,2,0,0))
(2018, 0, 20, 2, 0, 1.341104507446289e-5)

Acceleration due to atmospheric drag

Have you developed the calculation of the acceleration due to the atmospheric drag?

I've found a function in Mathlab https://www.mathworks.com/matlabcentral/fileexchange/54877-satellite-orbit-modeling?focused=7116317&tab=function.

Add a few simple, full examples to the docs

As a new user, I think it might be helpful if the to have a few examples that work through an entire problem start to finish. Something similar to the ISS example here https://www.ronanarraes.com/2019/01/the-satellite-toolbox-for-julia/ would be hugely beneficial to see in the docs.

Add API function to orbit propagators to propagate to a specific epoch

It would be interesting to define an API function like propagate_to_epoch! so that we can define an specific epoch to propagate the orbit.

Fix conversion between state vector and orbit elements in equatorial cases

When converting from state vectors to Keplerian elements, the RAAN, argument of perigee, and true anomaly is NaN for equatorial orbits:

julia> sv_to_kepler( kepler_to_sv( Orbit(0.0, 42164e3, 0, 0, 0, 0, 0 ) ) )

                 Orbit
  ======================================
                  t =        0.00000
    Semi-major axis =    42164.0000 km
       Eccentricity =        0.000000
        Inclination =        0.0000 ˚
               RAAN =           NaN ˚
    Arg. of Perigee =           NaN ˚
       True Anomaly =           NaN ˚

Hence, the function rv_to_kepler must account for the special cases.

Fix documentation in nutation_fk5

SatelliteToolbox.jl/src/transformations/fk5/nutation.jl

Line 211 in 2adbf24

# Compute the mean obliquity of the ecliptic [s].

It must be [deg] instead of [s].

Drop all IERS EOP data functions and use EarthOrientation.jl

The EarthOrientation.jl package already provide the feature to download and interpolate data from IERS. I need to test if the performance is equal or better and then drop the functions related to it from SatelliteToolbox.jl.

Remove unused variables

SatelliteToolbox.jl/src/transformations/teme/teme.jl

Line 80 in 2adbf24

ϵ_1980 = mϵ_1980 + Δϵ_1980

KP tables do not download

When running init_solar_indices() the kp tables do not download.

Maybe it would be best to grab them from a different source? Or add an option when the user does not need kp data.

Increase precision in ref. system conversions

We can increase the precision in rotations that are about one axis. See, for example:

julia> JD_TT = 2.460115315972222e6
2.460115315972222e6

julia> JD_UTC = jd_tt_to_utc(JD_TT)
2.460115315171481e6

julia> D = r_eci_to_eci(TEME(), JD_UTC, TOD(), JD_UTC)
3×3 StaticArrays.SMatrix{3, 3, Float64, 9} with indices SOneTo(3)×SOneTo(3):
  1.0           3.8393e-5     4.15777e-19
 -3.8393e-5     1.0          -3.91043e-17
 -1.25473e-19  -3.91016e-17   1.0

julia> D[:]
9-element StaticArrays.SVector{9, Float64} with indices SOneTo(9):
  0.9999999992629907
 -3.8392950862527036e-5
 -1.2547321052914035e-19
  3.839295086252501e-5
  0.9999999992629907
 -3.910159364194184e-17
  4.157774012182647e-19
 -3.910427424736158e-17
  0.9999999999999999

Maybe we need a version of angle_to_rot with only one angle argument.