Git Product home page Git Product logo

open-space-collective / open-space-toolkit-astrodynamics Goto Github PK

View Code? Open in Web Editor NEW
51.0 6.0 12.0 332.49 MB

Flight profile, orbit, attitude, access.

Home Page: https://open-space-collective.github.io/open-space-toolkit-astrodynamics/

License: Apache License 2.0

CMake 2.56% Makefile 0.67% C++ 85.54% Python 10.41% Shell 0.27% Dockerfile 0.56%
space engineering toolkit astrodynamics orbit flight access trajectory attitude cpp

open-space-toolkit-astrodynamics's People

Contributors

apaletta3 avatar derollez avatar etiennevincent avatar guillaumeloftorbital avatar kyle-cochran avatar lucas-bremond avatar phc1990 avatar robinpdm avatar vishwa2710 avatar vishwaloft avatar

Stargazers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Watchers

avatar avatar avatar avatar avatar avatar

Forkers

cowlicks verstaen meganmergo oygx210 surfing-gravity masood69h brandon-loft phc1990 dhruvj22 emone vishwa2710

open-space-toolkit-astrodynamics's Issues

[feat] Improve CI

Describe the solution you'd like

  • making the release workflow conditional on the main workflow passing, before it allows you to run it
  • If there's a way to reduce the time between releasing (where github dispays a new patch) and the .deb packages actually being deployed because you can't develop on any downstream ostk repos during this time period since the dev container knows about the new tag but can't find it since it hasn't been pushed yet.

[feat] Add dependency updating bot and script for our dockerfiles

Is your feature request related to a problem? Please describe.
Everytime we update an ostk repo and do a release we have to manually propagate that up the chain

Describe the solution you'd like
We have already installed dependabot for the pip package manager, but that doesn't update our dependencies listed in the dockerfiles. So we should

  1. Centralize all the versions of all our dependencies in a versions.env file at the root level
  2. Create a github action that can go and modify the dependencies in our dockerfile every so often and open a PR if they need to be updated

[fix] Git can't clone on windows 11

Describe the bug
Git can't clone this repo on windows 11 because filename contains special characters : which not support on windows:

Steps to reproduce

  1. git clone git clone https://github.com/open-space-collective/open-space-toolkit-astrodynamics.git

Expected behavior
image

Additional context

related files:

test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_7000000.0_0.0_2023-01-01T00:00:00.000_115.0_0.1_1500.0_3600.0_VNC_0.0_0.0_1.0_30.0.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_7000000.0_0.0_2023-01-01T00:00:00.000_115.0_0.1_1500.0_3600.0_VNC_1.0_0.0_0.0_30.0.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_7000000.0_98.1_2021-05-13T12:34:13.345_115.0_0.1_1500.0_3600.0_VNC_1.0_0.0_0.0_30.0.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_7000000.0_98.1_2023-01-01T00:00:00.000_1015.0_0.1_1500.0_3600.0_LVLH_1.0_0.0_0.0_30.0.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_7000000.0_98.1_2023-01-01T00:00:00.000_1015.0_0.1_1500.0_3600.0_VNC_1.0_0.0_0.0_30.0.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_7000000.0_98.1_2023-01-01T00:00:00.000_115.0_0.1_1500.0_14400.0_LVLH_1.0_0.0_0.0_30.0.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_7000000.0_98.1_2023-01-01T00:00:00.000_115.0_0.1_1500.0_14400.0_VNC_1.0_0.0_0.0_30.0.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_7000000.0_98.1_2023-01-01T00:00:00.000_115.0_0.1_1500.0_3600.0_LVLH_1.0_0.0_0.0_30.0.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_7000000.0_98.1_2023-01-01T00:00:00.000_115.0_0.1_1500.0_3600.0_QSW_0.0_1.0_0.0_30.0.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_7000000.0_98.1_2023-01-01T00:00:00.000_115.0_0.1_1500.0_3600.0_TNW_1.0_0.0_0.0_30.0.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_7000000.0_98.1_2023-01-01T00:00:00.000_115.0_0.1_1500.0_3600.0_VNC_1.0_0.0_0.0_30.0.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_7000000.0_98.1_2023-01-01T00:00:00.000_115.0_0.1_1500.0_3600.0_VVLH_1.0_0.0_0.0_30.0.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_7000000.0_98.1_2023-01-01T00:00:00.000_115.0_10.0_1500.0_3600.0_VNC_1.0_0.0_0.0_30.0.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_7500000.0_98.1_2023-01-01T00:00:00.000_115.0_0.1_1500.0_3600.0_VNC_1.0_0.0_0.0_30.0.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_Drag_7000000.0_0.0_2023-01-01T00:00:00.000_115.0_0.1_1500.0_3600.0_VNC_1.0_0.0_0.0_30.0_EXPONENTIAL_1.0_2.1_TRUE.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_Drag_7000000.0_98.1_2021-12-23T11:23:21.235_115.0_0.1_1500.0_3600.0_VNC_1.0_0.0_0.0_30.0_EXPONENTIAL_1.0_2.1_TRUE.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_Drag_7000000.0_98.1_2023-01-01T00:00:00.000_1015.0_0.1_1500.0_3600.0_VNC_1.0_0.0_0.0_30.0_EXPONENTIAL_1.0_2.1_TRUE.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_Drag_7000000.0_98.1_2023-01-01T00:00:00.000_115.0_0.1_1500.0_14400.0_VNC_1.0_0.0_0.0_30.0_EXPONENTIAL_1.0_2.1_TRUE.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_Drag_7000000.0_98.1_2023-01-01T00:00:00.000_115.0_0.1_1500.0_3600.0_QSW_0.0_1.0_0.0_30.0_EXPONENTIAL_1.0_2.1_TRUE.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_Drag_7000000.0_98.1_2023-01-01T00:00:00.000_115.0_0.1_1500.0_3600.0_VNC_1.0_0.0_0.0_30.0_EXPONENTIAL_1.0_2.1_TRUE.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_Drag_7000000.0_98.1_2023-01-01T00:00:00.000_115.0_0.1_1500.0_3600.0_VNC_1.0_0.0_0.0_30.0_EXPONENTIAL_1.0_4.2_TRUE.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_Drag_7000000.0_98.1_2023-01-01T00:00:00.000_115.0_0.1_1500.0_3600.0_VNC_1.0_0.0_0.0_30.0_EXPONENTIAL_25.0_2.1_TRUE.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_Drag_7000000.0_98.1_2023-01-01T00:00:00.000_115.0_0.1_1500.0_7200.0_VNC_1.0_0.0_0.0_30.0_EXPONENTIAL_1.0_2.1_TRUE.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_Drag_7000000.0_98.1_2023-01-01T00:00:00.000_115.0_1.0_150.0_3600.0_VNC_1.0_0.0_0.0_30.0_EXPONENTIAL_1.0_2.1_TRUE.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_Drag_7300000.0_98.1_2023-01-01T00:00:00.000_115.0_0.1_1500.0_3600.0_VNC_1.0_0.0_0.0_30.0_EXPONENTIAL_1.0_2.1_TRUE.csv

[fix] dead links in docuementation

Describe the bug

From a list compiled by Dhruv Jain

1.	OTSK Astrodynamics:
1.	https://open-space-collective.github.io/open-space-toolkit-astrodynamics/html/index.html 
1.	Documentation >>Python >> 404
2.	Tutorials >> C++ >> 404
3.	Tutorials >> C++ >> 404
4.	Contribution >> Contributing guide >> blank
5.	Dependencies >> Eigen >> http://eigen.tuxfamily.org/index.php “website seems to be down”

1.	README 
1.	Documentation >> Python >> “I do not believe the link is landing on the correct page”
2.	Tutorials >> C++ >> “sensor modelling example lacks description and comments to be easy to understand”
3.	Tutorials >> Python >> “no tutorial” -> route it to notebooks folder

[fix] Re-organize python tests fixtures for clarity

Is your feature request related to a problem? Please describe.
Currently python test fixtures are imported from other files to be used in multiple tests, and this isn't the best style-wise

Describe the solution you'd like
Add an extra fixtures/ folder in the test folder and move fixtures relevant to specific classes into that folder with names for the same classes

[feat] Reduce runtime of unit tests

Is your feature request related to a problem? Please describe.
As new unit tests have been added, the CI pipeline time has greatly increased.

Describe the solution you'd like
The tests for Orbit take a significant portion as they compare analytical results for 10 days of data at a 1 minute resolution. We can reduce the resolution and total length of this dataset to speed up the tests.

Additional context

[fix] Access generation fails when using a Tabulated Orbit model

Describe the bug
There seems to be a bug in Access generation where we request the state at an instant that is beyond the end of the search interval. This is not a problem in Orbit models such as SGP4 where states can be requested at arbitrary instants.

However, this causes issues when using a Tabulated Orbit model with a fixed validity window. Requesting an Instant outside of the valid range results in an error like:
Provided instant [2024-02-01 19:30:59.620.066 [UTC]] is outside of interpolation range [2024-01-18 19:40:59.620.066 [UTC], 2024-02-01 19:30:49.620.066 [UTC].

Steps to reproduce
Steps to reproduce the behavior (add code snippets as needed):

  1. Run access generation with a Tabulated Orbit model.

Expected behavior
Access generation works for Tabulated orbit models.

Additionally, if access generation is performed on a tabulated model without sufficient data for the search interval, it would be nice to have a useful error that says there is not sufficient data.

Additional context
Fuller error log that makes me suspect the source of the issue:

Provided instant [2024-02-01 19:30:59.620.066 [UTC]] is outside of interpolation range [2024-01-18 19:40:59.620.066 [UTC], 2024-02-01 19:30:49.620.066 [UTC].

[ERROR] 2024-01-18 19:44:24.542 [P:1] [T:140272016541440] 0# ostk::core::error::RuntimeError::RuntimeError(ostk::core::types::String const&) at /app/src/OpenSpaceToolkit/Core/Error/RuntimeError.cpp:14
[ERROR] 2024-01-18 19:44:24.542 [P:1] [T:140272016541440] 1# ostk::astro::trajectory::models::Tabulated::calculateStateAt(ostk::physics::time::Instant const&) const [clone .cold] at /app/src/OpenSpaceToolkit/Astrodynamics/Trajectory/Models/Tabulated.cpp:161
[ERROR] 2024-01-18 19:44:24.542 [P:1] [T:140272016541440] 2# virtual thunk to ostk::astro::trajectory::orbit::models::Tabulated::calculateStateAt(ostk::physics::time::Instant const&) const at /app/src/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Tabulated.cpp:53
[ERROR] 2024-01-18 19:44:24.542 [P:1] [T:140272016541440] 3# ostk::astro::Trajectory::getStateAt(ostk::physics::time::Instant const&) const at /app/src/OpenSpaceToolkit/Astrodynamics/Trajectory.cpp:92
[ERROR] 2024-01-18 19:44:24.542 [P:1] [T:140272016541440] 4# ostk::astro::access::GeneratorContext::GetStatesAt(ostk::physics::time::Instant const&, ostk::astro::Trajectory const&, ostk::astro::Trajectory const&) at /app/src/OpenSpaceToolkit/Astrodynamics/Access/Generator.cpp:519
[ERROR] 2024-01-18 19:44:24.542 [P:1] [T:140272016541440] 5# ostk::astro::access::GeneratorContext::isAccessActive(ostk::physics::time::Instant const&) at /app/src/OpenSpaceToolkit/Astrodynamics/Access/Generator.cpp:469
[ERROR] 2024-01-18 19:44:24.542 [P:1] [T:140272016541440] 6# ostk::astro::solvers::TemporalConditionSolver::EvaluateConditionAt(ostk::physics::time::Instant const&, ostk::core::ctnr::Array<std::function<bool (ostk::physics::time::Instant const&)> > const&) at /app/src/OpenSpaceToolkit/Astrodynamics/Solvers/TemporalConditionSolver.cpp:144
[ERROR] 2024-01-18 19:44:24.542 [P:1] [T:140272016541440] 7# ostk::astro::solvers::TemporalConditionSolver::solve(ostk::core::ctnr::Array<std::function<bool (ostk::physics::time::Instant const&)> > const&, ostk::physics::time::Interval const&) const at /app/src/OpenSpaceToolkit/Astrodynamics/Solvers/TemporalConditionSolver.cpp:73
[ERROR] 2024-01-18 19:44:24.542 [P:1] [T:140272016541440] 8# ostk::astro::solvers::TemporalConditionSolver::solve(std::function<bool (ostk::physics::time::Instant const&)> const&, ostk::physics::time::Interval const&) const at /app/src/OpenSpaceToolkit/Astrodynamics/Solvers/TemporalConditionSolver.cpp:46
[ERROR] 2024-01-18 19:44:24.542 [P:1] [T:140272016541440] 9# ostk::astro::access::Generator::computeAccesses(ostk::physics::time::Interval const&, ostk::astro::Trajectory const&, ostk::astro::Trajectory const&) const at /usr/include/c++/9/bits/std_function.h:369

[refactor] replace all cpp class getters with accessors for consistency

Is your feature request related to a problem? Please describe.
There is a mix of getters and accessors in OSTk cpp code, which is unnecessary and adds duplicate code.

Describe the solution you'd like
We could simply refactor all OSTk cpp getters to become accessors that return const references. This will reduce the amount of boilerplate code and also allow the user to choose what they want returned either a copy (const or non-const) or a const reference. But, for ease of use in Python we map the cpp accessors to python getters.

[fix] Build Failure in FiniteDifferenceSolver Due to Eigen Matrix Explicit Constructor Initialization

Describe the bug

The bug occurs in the FiniteDifferenceSolver.cpp file, specifically when attempting to initialize an Eigen::MatrixXd object with a brace-enclosed initializer list. This operation fails due to the explicit constructor of Eigen::Matrix, which does not allow implicit conversions that would be necessary for this kind of initialization. The error is triggered at the following line:

const MatrixXd coordinatesMatrix = {coordinates};

This line attempts to copy-initialize an Eigen::MatrixXd object with a VectorXd (or similar), which is not directly supported due to the explicit nature of the Eigen::Matrix constructor. The error message provided by the compiler points out that the chosen constructor is explicit in copy-initialization, referencing the explicit constructor declaration in the Eigen library's Matrix.h file.

The issue stems from a misunderstanding or oversight regarding Eigen's initialization requirements, leading to a build failure when attempting to compile the FiniteDifferenceSolver.cpp source file.

Steps to reproduce

  1. Fork and clone the repository.
  2. Start the dev environment in container: make start-development
cmake ..
make

Screenshot of the error message:
Screenshot from 2024-02-06 00-38-08

Potential suggestion

To resolve this issue, directly construct the MatrixXd object using a method that Eigen supports for converting or initializing from a VectorXd. If the intent is to create a matrix where coordinates are column elements then update to:
const MatrixXd coordinatesMatrix = coordinates;
If supposed to be a row in the matrix then:
const MatrixXd coordinatesMatrix = coordinates.transpose();

Re-enable tests

The following tests have been temporarily disabled:

  • Library_Astrodynamics_Trajectory_Orbit_Models_Kepler.Test_2
  • Library_Astrodynamics_Trajectory_Orbit.SunSynchronous
  • Library_Astrodynamics_Access_Generator.AerRanges

Re-enable them and make sure they pass before releasing anything.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.