You are seeing poliastro blog. If you want to see documentation, the latest version can be found in docs.poliastro.space.

CZML Extractor: An overview

As the proverb says "all good things must come to an end". Unfortunately, it's time to bid adieu to the summer and have a look on what has been accomplished so far.

The CZML Extractor

This was undoubtedly the main and most time-consuming part of the project. The extractor allows users to easily convert orbital data to CZML. You can find an overview of the extractor's usage in the User Guide or take a look in the more in-depth Jupyter notebook tutorial

The Cesium Application

Since we need more parameters to accurately represent the data, we also need a specific application to parse said parameters. For this reason, I worked on a Cesium application that allows you to easily visualize the data. At this moment, there are two separate applications: one that runs remotely and one you can copy-paste directly …

Hard reformat week

Reformat on poliastro.atmosphere

After implementing the COESA62 and COESA76 models in #738 I was not completly happy because of lots of data and coefficients at the beginning of each script. Therefore and after asking Juanlu, it was finally decided to move all those numbers to text files under the *.dat extension.

Furthermore, I decided not only to do that but also to completely reformat the poliastro.atmosphere module:

  • base.py: holds different mother classes for atmospheric models.
  • coesa62.py: U.S Standard Atmosphere 1962 model.
  • coesa76.py: U.S Standard Atmosphere 1976 model.
  • util.py: contains atmospheric utilities.

Documentation was also added together with a notebook to better see not only how these objects work but their differences in output results. In the following image properties for COESA76 against geometrical altitude are plotted:

COESA76

Reformat on poliastro.bodies

While working …

Atmospheric models and more!

Tasks for this last period...

While checking the stability of the 0.13, GSOC continues and new bugs, implementations, and others need to be solved for the 0.14. Most of them are related to:

  • New frame modeling, implementation, and testing.
  • New plotting capabilities, such us two attractors in the same plot.
  • New orbit creation methods.
  • Start using non-dimensional units.
  • Different bug solving.

Issues related to frames are the most tricky ones since working with them is not so intuitive. Plotting capabilities are directly related to frames and therefore no major improvements are done in this field without solving something in the previous one.

New atmospheric models

I have been trying to model and implement some famous atmospheric models for poliastro. Drag is one of the main perturbations for LEO orbits. By making use of Cowell's formulation we can integrate …

Ground track plotting and Ellipsoids

The second evaluation period has come to the end and with the end of the program drawing ever closer, I'm happy to announce that most work on the additional deliverables has been complete!

CZML3

I've added polylines and points (along with myriad of other dependent properties/types). These also marked the release of v0.1.3!

Ground Track Plotting

Having added the necessary CZML properties, I finally managed to add the ground track plotter. It allows to draw both a static path and an animated one. The coolest feature is that it automatically calculates the path's orthographic projection, allowing you to see the satellite in 2D mode. I was also toying with the idea of allowing the users to export gif images directly from the application, which would mean no longer relying on external screen capturing software to create and …

New propagators

What are propagators and why do we care about them?

One of the most common problems in astrodynamics and orbital mechanics is that we want to know where a body will be at a given position along its orbit for a given time. It is possible to integrate by hard the two-body equation and then apply some boundary conditions. However, this last option is just insane and would take several hours or days to be done by a human.

There is a better way to get the position as a function of time or propagate an orbit. Johannes Kepler's contributions to the astrodynamics and orbital mechanics field were really important and can be summarized here, in the so-called Kepler's Laws:

  • Planets' orbits follow an elliptical path around the Sun, which is located in one of the focus.
  • Planets cover equal …

Moving forward with the Cesium application

I feel like in the last couple of weeks I got to work a little in several aspects of the project. While this didn't allow me to focus on a single feature, it allowed me to make progress in various different areas.

Bug resolving and 2D mode

First and foremost, I got rid of a particularly frustrating bug in the application. Certain javascript events (such as the one that allows the inertial view), where tied to a single Viewer and thus wouldn't trigger when the Viewer was destroyed (which is the case when, for example, loading the data from the file). I also made a few minor changes in the code and introduced the option to set the Viewer mode to 2D. This isn't any useful as of now, but it will be with the new feature I'm planning to …

Converting to CZML and next steps

So the first phase of GSoC is over and with it, it's time to reflect what has been achieved in the last couple of months.

CZML3

As I mentioned in the last blogpost this is a very useful library created by juanlu. After a few patches, the library now supports most CZML properties and - as far as I can tell - this is the only currently mantained Python library for creating CZML packets.

CZML Extractor

This is the first feature I've started to work on and while it is still far from complete, I'm happy to say that it is now usable.

At first, the czml document was represented by a nested dictionary and then converted to valid JSON format. This worked ok and I did write a function which made manipulating the dictionary a tad more intuitive, but it was …

Getting done for next release

Version 0.13 is getting closer

Version 0.13 is expected to be tagged in about a month. As any other release, it includes new features such as a new method in the Orbit class called change_attractor or the trail parameter in StaticOrbitPlotter. However, this release will also include really important bug fixes such as:

  • Minor issues related to Lambert's problem.
  • Propagator's are supposed not to hang out anymore due to robust solutions and propagation methods.

Now that my final exams ended I am completely free to work in poliastro and direct all my efforts to the software. I want to close issues #495 and #475 in the next days since they are previously commented bugs.

Propagator methods in the twobody problem

Kepler's equation (KE) allows us to solve either for the time at a given position or the position …

Communication satellites and refactoring

Those couple of weeks were spent mainly on setting future milestones and improving the quality of the code. In a way, Tom Cargill's famous aphorism came to my mind:

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.

Writing stuff that "just works" is relatively easy. But when programming, you always have to keep track of myriad variables including but not limited to: maintanability, integration and readability.

CZML3

My mentor, Juanlu, wrote a fully-fledged library for composing czml packets. While it's still in the early stages of development, I would urge anyone interested to check it out. I'm currently trying to refactor the czml core, so it utilizes the library instead of the current approach …

Lambert maneuvers and trails in plots

What's new?

Three weeks have passed since the coding phase began and new features have been added to the software:

  • Lambert is now a Maneuver instance.
  • A trail keyword in StaticOrbitPlotter for showing orbits' trails.

Lambert just needs now two orbits!

Although the raw algorithms are kept under the module poliastro.iod, it is possible now to simplify the process of solving this famous astrodynamics problem by making use of the poliastro.maneuver module.

Imagine that we want to solve the classical problem ongoing from Earth to Mars for a trip of 600 days duration. Let us compare before and after Maneuver.lambert implementations:

With 0.12 version:

from astropy import units as u
from astropy.time import Time

from poliastro.bodies import Earth, Mars, Sun
from poliastro.iod.izzo import lambert
from poliastro.twobody import Orbit

LAUNCH = Time.now …