[GSoC2019|DirectDemod|Vladyslav M] Installing DirectDemod. Map overlays.

This post will cover the installation process of DirectDemod package, we’ll also talk on how to create pretty map overlays using the directdemod.georeferencer module.

Installing DirectDemod

Recently, the installation process for DirectDemod has been updated (currently on Vinay_dev and Vladyslav_dev dev branches only). You must have anaconda or miniconda distribution installed. From here do the following:

  1. Clone repository:
    • git clone https://github.com/aerospaceresearch/DirectDemod
  2. Change branch to Vinay_dev
    • git checkout -b Vinay_dev
  3. Create environment
    • conda env create -f environment.yml -n my_env
  4.  Activate the environment
    • conda activate my_env
  5. Add directdemod module to your PYTHONPATH.
  6. Test installation with pytest.

Create fancy map overlays

Before creating map overlays we need to have a georeferenced image, let’s make one. samples/decoded directory contains 2 already decoded and preprocessed NOAA images ready for georeferencing. Create an empty file – SDRSharp_20190521_170204Z_137500000Hz_IQ.wav in samples directory, it will serve as a placeholder; the image was already extracted but the name of SDR file contains valuable information needed for georeferencing. 

To georeference the image, we will first extract information from the name of SDR file. Go to directdemod directory and type the following command.

python misc.py -f ../samples/SDRSharp_20190521_170204Z_137500000Hz_IQ.wav -i ../samples/decoded/SDRSharp_20190521_170204Z_137500000Hz.png

misc.py extracts data about satellite’s orbit and position, and then embeds it in json format into created tif file.

 Now we will use georefencer.py CLI interface to georeference the image and create a map overlay.  -m or –map option tells the georeferencer to overlay the image with map boundaries after georeferencing.

python georeferencer.py -m -i ../samples/decoded/SDRSharp_20190521_152538Z_137500000Hz.tif

Finally, the georeferenced image.

Figure 1. Georeferenced image combined with country boundaries.

Note on shapefiles

A shapefile is a vector data storage format for storing geographical features [1]. In the context of this application, country boundaries are being represented as a shapefile. Inside the shapefile points may be stored as polygons or as polylines, overlaying an image with polylines will have an effect of overlaying country frontiers, while overlaying an image with polygons will have an effect of overlaying country areas. 

Figure 2. Georeferenced image combined with polygons shapefile.

Further work

The next blog post will discuss merging NOAA satellite images, including different techniques for handling overlapping areas cases.

References

  1. https://en.wikipedia.org/wiki/Shapefile

[GSoC2019|DirectDemod|Vladyslav M] Introduction – Georeferencing NOAA images

Hello everyone!

Let me introduce myself, my name is Vladyslav Mokrousov, I am a second year student at software engineering department of Kyiv Polytechnical Institute, Ukraine. This summer I will be working on Google Summer of Code (GSoC) project for AerospaceResearch.net

Please check my github and twitter.

This blog will briefly describe the goal of the project, and then will proceed to describe what has been done so far.

BigImage and BigGlobe Projection

During this summer I will work on creating software for visualization of satellite imagery, mainly images from NOAA satellites. The goal of the project, as my proposal states:

Current software provides possibility for decoding APT signals received by RTL-SDR receivers, but the task of understanding the extracted data is hard, because an open-source programs for proper visualization of these images do not yet exist. This project aims to create an open-source software to target that issue, so more developers and enthusiasts will receive an efficient tool to help them in their research. The software would provide functionality for creating different types of interactive visualizations of satellite weather images, along with their georeferencing.

Particularly, I am working on software, which will combine many satellite images into one big picture (BigImage). The software will handle cases of overlapping images using different merging strategies. Another main task of the software will be to provide accurate image georeferencing [1].

Image georeferencing

Image georeferencing refers to the process of associating image coordinate system with geographical coordinate system, i. e. each pixel of the image will be paired with certain geocoordinates. This will allow combining these images with maps or with each other.

Figure 1. Georeferenced image combined with map.

An example above shows how the georeferenced image can be used for visualization. The process of georeferencing is divided in two parts:

  1. Computing set of Ground Control Points (GCPs).
  2. Fitting the image to match these GCPs.

To compute GCPs we will use the TLE file, which describes the orbit parameters of the satellite. Using pyorbital module we consistently calculate the position coordinates of satellite and match them with relative position of pixels on the image. The 2 part is carried out by gdal [2] library, which is called via it’s Python API.

Performance

The aim for created software is to produce visualizations of big amount of image data, therefore the implementation should be fast and should handle memory expensive cases. To satisfy this requirement gdal library is used. It is an open source software designed for raster and vector data manipulations. gdal is written in C++, that’s why it is extremely fast. Manual memory management ensures the efficiency of memory use. The implementation makes use of gdal Python bindings, which provide interface for using gdal functionality in Python.

Further work

Image georeferencing is the first step required to produce good looking projections of satellite images, especially for creating image overlays. In the next blog we will talk about map overlays and techniques for merging overlapping parts of NOAA images.

References

  1. https://en.wikipedia.org/wiki/Georeferencing
  2. https://gdal.org/

Call for ESA Summer of Code in Space 2019! Be our Summer Student and code your open-source space projects (stipends of up to 4000€)

this summer will purely be a summer of code! We are not only offering you Google Summer of Code (GSOC 2019, still open until April 9th), but also the European Space Agency’s Summer of Code in Space 2019 (ESA SOCIS).

Now it is up to you to decide if you want to code open-source space with us during ESA Summer of Code in space 2019? You should!
Be our Summer Student and code your open-source space projects. You get stipends of up to 4000€. The Call for ESA SOCIS 2019 is now open!

Together, we as AerospaceResearch.net, Ksat-Stuttgart (University of Stuttgart) and EP2Lab (Carlos III University of Madrid) are proud to be selected as official mentoring organizations for the ESA Summer of Code in Space 2019.
And we are now looking for students to spend their summers coding on great open-source space software, getting paid by ESA, releasing scientific papers about their projects and supporting the open-source space community by useful programmes.
Are you a student? You have time until May 4, 2019, to apply for various coding ideas to work on, and be part of out team!

More information and registration here.

ESA Summer of Code in Space

ESA Summer of Code in Space (SOCIS) is a program run by the European Space Agency that focuses on bringing student developers into open source software development for space applications. Students work with a mentoring organization on a 3 month programming project during their summer break.

Through SOCIS, accepted student applicants are paired with a mentor or mentors from the participating organizations and with experts from ESA (where available), thus gaining exposure to open source software development and insights from ESA. In turn, the participating organizations are able to prototype new open source projects and possibly bring in new developers to work on relevant topics for space.

SOCIS is inspired by (but not affiliated or related in any way to) Google’s Summer of Code initiative, and is designed with the following objectives in mind:

  • raise the awareness of open source projects related to space, especially among students;
  • raise awareness of ESA within the open source community;
  • improve existing space-related open source software.

For further information, please chat with us on https://aerospaceresearch.zulipchat.com

Call for Google Summer of Code 2019! Be our Summer Student and code your open-source space projects (stipends of up to $6600)

Again for the 5th time, AerospaceResearch.net[0] is proud to be selected as an official mentoring organization for the Summer of Code 2019 (GSOC) program run by Google[1].
And we are now looking for students to spend their summers coding on great open-source space software, getting paid up to 6600 USD by Google, releasing scientific papers about their projects and supporting the open-source space community.

Until 9. April 2019, students can apply for an hands on experience with applied space programs. As an umbrella organisation, AerospaceResearch.net, KSat-Stuttgart e.V. and ep2lab of Carlos III University of Madrid are offering you various coding ideas[2] to work on:

  • The Distributed Ground Station Network – global tracking and communication with small-satellites[2][4]
  • KSat-Stuttgart – the small satellite society at the Institute of Space Systems / University of Stuttgart[2]
  • ep2lab of Carlos III University of Madrid[2]
  • or your very own proposal![2]
„Call for Google Summer of Code 2019! Be our Summer Student and code your open-source space projects (stipends of up to $6600)“ weiterlesen

We have a ZulipChat now. Join us there!

During the Google Summer of Code 2018 Mentors Summit, many projects used the open-source Zulip Chat for discussing their projects and planning their next steps.

It is a fine little chat in the spirit of Slack, but fully open-source.

We started using it for our projects and for our general discussions. So if you are looking for us, want to onboard the projects or have an idea to propose, we welcome you to join our ZulipChat channel. We are looking to meet you on

AerospaceResearch.ZulipChat.com

Space Lightning Talks! Start of the radion workshop week “FUNKWOCHE”

Our event in Jena will be special because it will be the first and currently only location that is a „Makerspace“. Makerspaces are places were people can work on creative solutions for global or private problems. And this kind of free „maker“ spirit is what will also help solve problems in space exploration. So you have the unique chance to join other creative people during the #SpaceTalks and also to take part in a full week of workshops. Because #SpaceTalks will initiate the FunkWoche during which you can come here and work on everything related to communications, be it radio frequencies, lasers, amateur radio,…. and also satellite communications. So we will bring #SpaceTalks to Jena under this flag of „FunkWoche 2018/2 and ESA’s European Spacetalks – space and even more radio! / FunkWoche 2018/2 und ESA’s European Spacetalks – Raumfahrt und noch mehr Funk“.

The event will take place at the Jena Hackspace, will be hybrid with Lightning Talks (short 15-20 minute talks of you!) for #SpaceTalks and as the starting event for the hamradio workshop week FunkWoche – and be on Monday, 19 November 2018, 2000hrs to 2130hrs. Talks and discussions may be in German or in English. Everyone is welcome.

Lightning Talks:

  • Intro: Satelliten Communication – what flies where and what can I do with it, and why to uwe and my build an antenna rotator?! (Working Title), Andreas
  • Status of the Distributed Ground Station Network for Tracking Cubesats, Andreas
  • (TBC) GroundStations, but safe/secure!, lowl3v3l
  • Your Space Topic, YOU!

Due to limited places, please register here or on meetup and RVSP this in your calendars! Further details tbc in the next weeks. We are inviting you to give a lightning talk. Just send us your title at contact@aerospaceresearch.net.

„Space Lightning Talks! Start of the radion workshop week “FUNKWOCHE”“ weiterlesen

FunkWoche 2018/2 und ESA’s European Spacetalks – Raumfahrt und noch mehr Funk (19.-24.11.2018 ab 19:00 Uhr, im Hackspace Jena e.V.)

Es ist wieder Zeit sich mit Funk zu beschäftigen und dieses mal mit mehr Raumfahrt.
Daher rufen wir nun die „FunkWoche 2018/2 und ESA’s European Spacetalks – Raumfahrt und noch mehr Funk“ aus.
Das Konzept ist wie letztes mal, dass wir jeden Tag in dieser Woche an Funkthemen arbeiten, reden, diskutieren, auslegen, oder anderweitig kreativ umsetzen werden. Und mit „wir“ meinen wir auch euch!. Mögliche Themen sammeln wir bereits hier[0] und Uwe und ich werden eine Motorsteuerung aus Aliexpressteilen bauen, mit der wir Satelliten verfolgen und damit kommunizieren wollen. Wir laden euch ein dabei mitzumachen!
Dazu passend werden wir ESA’s European Spacetalks[0] nach Jena holen und kurze Vorträge über Raumfahrt halten.
Spacetalks sind so: „We are all concerned by space activities because they make a difference to our lives on a daily basis and correspond to one of humanity’s greatest challenges. In November 2018, members of the European Space family will be sharing their passion in a series of talks presenting a vast array of space-related topics.“Zur zeit sind es Europaweit 170 Talks, und wir sind dabei. Ihr seht also, jeder kann, soll und darf da mitmachen!

„FunkWoche 2018/2 und ESA’s European Spacetalks – Raumfahrt und noch mehr Funk (19.-24.11.2018 ab 19:00 Uhr, im Hackspace Jena e.V.)“ weiterlesen

It is time again for Hacktoberfest 2018!

It is time again for Hacktoberfest and we already took part in it with our projects and earned our free t-shirt already. On the 20th of October, we started projects during NASA Space Apps Challenge Stuttgart 2018 and collaboratively worked on open-source projects and created pull-requests.

The goal Hacktoberfest was and still is that everyone create at least 5 pull-requests by adding new features or fixing bugs to the software projects and earning a free and limited edition t-shirt by doing so. Hacktoberfest is from 1st to 31st of October 2018.

The hackathon was great, but the Hacktoberfest is still not over. You can start coding your improvements to your own or other people’s projects right now and we would be more than happy if we see your pull-request popping up on our github repository!

Start earning your hacktoberfest shirt today, and never stop coding for open-source software!

Hacktoberfest Shirt 2015
Hacktoberfest Shirt 2015

Join the next NASA Space Apps Challenge 2018 hackathon in Stuttgart this Saturday and Sunday (20.&21.October)

This Saturday, join the next NASA Space Apps Challenge 2018 hackathon in Stuttgart[0].

For the fifth time your team of engineers, hackers, makers and artists will solve global problems during the biggest hackathon event on this planet (20. & 21. October 2018) and you have the possibility to join!

During the last space apps, the Stuttgart teams were regularly among the final 25 projects out of 900 projects in various categories. For this year’s open-source topics NASA selected challenges all about “Earth and Space”.

Please register for Stuttgart today[0] to be part of this great space community, find your challenge to tackle, win awesome prizes and maybe start your space start-up.

Take this chance. NASA will bring together more than 20000 people at more than 200 locations and your project could make a change!

Infos in a nutshell:

  • SpaceApps Stuttgart 2018 Hackathon Weekend (20./21.10.2018)
  • start 20.10.2018 11:00 CEST, launching event 13:00 CEST, coming later is okay
  • end 21.10.2018 18:00 CEST
  • in shackspace, Stuttgarter Hackerspace (Ulmer Str. 255, Stuttgart-Wangen)
  • next to subway station “Im Degen” (U4/9)[1]
  • no fees, (donations are welcome).
  • for everybody
  • registration is open on SpaceAppsChallenge.org[0]. limited amount of places, so please be fast and register your slot today!

„Join the next NASA Space Apps Challenge 2018 hackathon in Stuttgart this Saturday and Sunday (20.&21.October)“ weiterlesen

[GSoC2018|OrbitDeterminator|Jorge] Angles-only orbit determination: Gauss method and least-squares

1. Introduction

During GSoC 2018, I worked on developing a ra/dec angles-only Keplerian orbit determination implementation for AerospaceResearch.net’s orbitdeterminator project. Our implementation incorporates both elements from the Gauss method for orbit determination, as well as from the least-squares principle. I did this both for Earth-orbiting bodies (satellites, space debris, etc.), and Sun-orbiting bodies (asteroids, comets, centaurs, etc.).

My implementation makes use of the astropy library, whose SkyCoord class provided the adequate abstraction in order to perform the required computations. astropy was also really useful for handling of units, angles, longitudes, etc., as well as providing access to the SPK kernel of JPL ephemerides DE432s, which are at the core of the orbit determination for Sun-orbiting bodies. Also, the poliastro library was useful for the evaluation of Stumpff’s functions in order to perform the refinement stages of the Gauss method. Finally, scipy’s functionality allowed the use of the Levenberg-Marquardt method for the least-squares fit to ra/dec observations.

2. Link to my GSoC 2018 project work:

The main part of the work I did is contained in the following modules:

  • orbitdeterminator/kep_determination/gauss_method.py
  • orbitdeterminator/kep_determination/least_squares.py

The pull request associated to my GSoC project is in GitHub at: aerospaceresearch/orbitdeterminator PR #141. My GitHub handle is @PerezHz . You can also find me on Twitter as @Perez_Hz.

3. Gauss method

The orbitdeterminator/kep_determination/gauss_method.py module allows the user to input files which contain ra/dec observations of either Earth-orbiting or Sun-orbiting celestial bodies, following specific formats for each case, and allows to compute an orbit from n>=3 observations.

If the number of observations is n==3, then the Gauss method is applied to these 3 observations. Otherwise, if n>3, then the Gauss method is executed over n-2 consecutive observation triplets. A set of orbital elements is computed for each of these triplets, and an average over the resulting n-2 set of elements is returned. A refinement stage has been implemented for the Gauss method such at each iteration of the refinement stage, a better approximation for Lagrange’s f and g functions are computed; which in turn allows to get better estimates for the cartesian state of the observed body.

The right ascension and declination observations topocentric, i.e., they are referred to registered sites either by the MPC or COSPAR. The information about the geocentric position of these sites is contained in registered lists. Both the IOD and MPC formats contain the alphanumeric codes associated to each observation site, so that for each observation it is possible to compute the geocentric position of the observer. This whole process is automatically processed during runtime in the background, so the user does not need to worry about these details.

3.1 Earth-orbiting bodies: gauss_method_sat

The gauss_method_sat function computes Keplerian elements from ra/dec observations of an Earth-orbiting body. The call signature is the following:

gauss_method_mpc(filename, bodyname, obs_arr, r2_root_ind_vec=None, refiters=0, plot=True)

Where filename refers to the name of the file which contains the observations in IOD-format, bodyname is an user-defined name for the observed object, obs_arr is a list/array of integers which define the numbers of the lines in the observation file filename which are going to be processed, r2_root_ind_vec allows the user to select the roots whenever multiple solutions to the Gauss polynomial exist (default behavior is to select always the first root), refiters is the number of iterations for the refinement stage of the Gauss method (default value is 0), and plot is a flag which if set to True will plot the orbit of the object around the Earth. More details may be found at the examples and the documentation. The orbital elements are returned, respectively, in kilometers, UTC seconds and degrees, and they are referred to the (equatorial) ICRF frame. More details may be found at the examples and the documentation.

Example output:

3.2 Sun-orbiting bodies: gauss_method_mpc

The gauss_method_mpc function computes Keplerian elements from ra/dec observations of an Earth-orbiting body. The call signature is practically same as gauss_method_sat (see section 3.1). One of the differences with respect to the Earth-orbiting case is that in this case the orbital elements are returned, respectively, in astronomical units, TDB days and degrees. But the main difference in the internal processing is that in this case, since the orbit is referred to the Sun, then the position of the Earth with respect to the Sun has to be determined at each of the observation times. gauss_method_mpc uses the JPL DE432s, as provided by the astropy library, in order to compute the heliocentric position of the Earth. This also involves a conversion from the UTC to the TDB time scale, which is also handled again using astropy’s time scale conversion functionalities. Finally, a third difference is that Sun-orbiting orbital elements are returned in the mean J2000.0 ecliptic heliocentric frame. More details may be found at the examples and the documentation.

Example output:

4. Least-squares

The least-squares functionality developed during my GSoC project may be thought of as differential corrections to the orbits computed by the Gauss method. That is, once a preliminary orbit has been determined by the Gauss method, then the best-fit of the observations to a Keplerian orbit in terms of the observed minus computed residuals (the so-called O-C residuals) may be found by a least-squares procedure. It is worthwhile to mention that in the current implementation all the observations have the same weight in the construction of the O-C residuals vector.

4.1 Earth-orbiting bodies: gauss_LS_sat

Similar to gauss_method_sat in call signature, but after applying the Gauss method to the subset of the observations defined by obs_arr, this function applies a least-squares procedure to the whole set of observations (unless otherwise selected by the user using the optional argument obs_arr_ls; see documentation), returning the Keplerian elements of the best-fit to the observations. Orbital elements are returned in kilometers, UTC seconds and degrees, and they are referred to the (equatorial) ICRF frame. More details may be found in the documentation and the examples.

Example output:

4.2 Sun-orbiting bodies: gauss_LS_mpc

Similar to gauss_method_mpc in call signature, but after applying the Gauss method to the subset of the observations defined by obs_arr, this function applies a least-squares procedure to the whole set of observations (unless otherwise selected by the user using the optional argument obs_arr_ls; see documentation), returning the Keplerian elements of the best-fit to the observations. Orbital elements are returned in astronomical units, TDB days and degrees, and they are referred to the mean J2000.0 ecliptic heliocentric frame. More details may be found at the examples and the documentation.

Example output:

5. Acknowledgments and credits

We wish to thank the satobs.org community, who gave us valuable comments and suggestions, and also provided us with observations of the ISS and other civilian satellites. We also wish to thank the Mathematical Physics group at the University of Pisa, for all the helpful discussions and feedback which contributed to this work.

6. TODOs

  • Allow the user to select ephemerides from astropy: currently, the user is not allowed to specify the ephemerides to be used in the orbit determination of Sun-orbiting bodies.
  • Add perturbations: for Sun-orbiting bodies, add planetary and non-gravitational perturbations; for Earth-orbiting bodies, add oblateness and atmospheric drag to orbit model.
  • For IOD-formatted files, allow the use of other „angle subformats“. There are actually 7 ways to codify the angles in IOD format, but currently the code only allows the angle subformat 2. Subformat 2 was chosen because it is the most used in the Satobs community. Some of this subformats involve alt/az measurements, so in a future version the code should know how to handle alt/az measurements in addition to ra/dec measurements. This could be done, e.g., by using the (alt, az) -> (ra, dec) conversion functions from the astropy library.
  • Implement orbit determination algorithms for SDP/SGP4 models from ra/dec measurements.
  • Let the user choose between two possible values for the signed difference between two angles, instead of always choosing the shortest signed difference by default.
  • Add support for new or non-listed observatories in the MPC or the COSPAR lists of registered observatories.
  • Take into account the finite light propagation time, as well as atmospheric refraction.
  • Add support for radar delay/Doppler observations of Sun-orbiting bodies.
  • Add support for non-equal weights in least-squares subroutines.