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 (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

]]>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]

If you are a student, take your giant leap into the space community, realizing your very own space software, and the chance to be recognized by Google headhunters.

If you are professor, feel free to propose this great opportunity to your students or even have your projects being coded and realized!

During the last years, we mentored more than 21 students during Summer of Code campaigns[6] and now, we achieved several great things together. We have released several papers. We spent computing power worth 60,000 PCs to those students projects, even helping their bachelor theses, and indirectly supporting the IMEX program[5] by the European Space Agency(ESA). And as a surprise and an honor for us, we had been on plenary stage with Canadian astronaut Chris Hadfield to promote those projects during the International Astronautical Congress 2014 in Toronto.

We want to repeat that success, and now it’s your turn to be active in open-source space!

Apply today, find all projects on the GSOC webpage![1]

We are waiting for you,

Andreas Hornig, Head of Platform

[0] https://aerospaceresearch.net/?page_id=1111

[1] https://summerofcode.withgoogle.com

[2] https://aerospaceresearch.net/?page_id=1111#codingideas

[3] http://ksat-stuttgart.de

[4] https://www.youtube.com/watch?v=TC4Ls3AGHf4

[5] https://www.youtube.com/watch?v=FY0vjbBp4eg

[6] https://www.youtube.com/watch?v=gkklxZxjT-8&list=PL-lXf3kTWgqybFL-VOmVxKyjnrVPE7DBB

Feel free to forward this email to whomever you think it may concern!

**### More Information ###**

# About Google Summer of Code (GSOC)[1]:

Google Summer of Code is a global program focused on introducing students to open source software development. Students work on a 3 month programming project with an open source organization during their break from university.

Since its inception in 2005, the program has brought together 12,000+ student participants and 11,000 mentors from over 127 countries worldwide. Google Summer of Code has produced 30,000,000+ lines of code for 568 open source organizations.

As a part of Google Summer of Code, student participants are paired with a mentor from the participating organizations, gaining exposure to real-world software development and techniques. Students have the opportunity to spend the break between their school semesters earning a stipend while working in areas related to their interests.

In turn, the participating organizations are able to identify and bring in new developers who implement new features and hopefully continue to contribute to open source even after the program is over. Most importantly, more code is created and released for the use and benefit of all.

# About AerospaceResearch.net[0]:

We are a DGLR young academics group at the University of Stuttgart for aerospace related simulations applying distributed computing. Our global citizen scientists community of 15,000 users are donating their idle computing time of 60,000 computers and forming a virtual super computer connected via the Internet. And this massive network is used for solving difficult space numerics or for sensor applications. We are bringing space down to Earth and supporting the space community from students to organizations.

# Distributed Ground Station Network [DGSN]:

The Distributed Ground Station Network is a system for tracking and communication with small satellites and other aerial vehicles. The concept includes a global network of small and cheap ground stations that track beacon signals sent by the satellite, plane or balloon. The ground stations are located at ordinary people at home, so called citizen scientists, and are connected via the Internet. A broadcasted beacon signal is received by at least 5 stations and can be used then for trilateration to obtain the position of the signal’s origin. For this each ground station correlates the received signal with the precise reception time, which is globally provided and synchronized by GPS. This shall help small satellite provider and even Google’s Loon project to be able to track their vehicles fast, globally and simple!

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

]]>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.

German Invitation:

Hi,

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!

Folgende Themen sind bereits angedacht:

- Intro: Satellitenkommunikation – was fliegt wo rum und was macht man damit, und wieso bauen Uwe und ich diese Woche eine Antennemotorsteuerung?! (Working Title), Andreas
- Status der Distributed Ground Station Network zum Tracken von Cubesats, Andreas
- (TBC) Bodenstation, aber sicher!, lowl3v3l
- Euer Space Thema, DU![2]

Wir können also beides, die Funkwoche und die ESA SpaceTalks super kombinieren!

Info in a Nutshell:

- jeden Tag ab 19:00 Uhr vom 19-24.11.2018
- [0] Eingeleitet mit einem ESA SpaceTalk am 19.11.2018 ab 20:00 Uhr.
- im Krautspace, dem Hackspace Jena, Krautgasse 26, 07743 Jena
- im Hauptraum und im Elektroniklabor (nach Bedarf).
- Themen siehe Link und bringt Funkthemen mit! Ankündigen der Themen wäre toll, aber kein Muss!
- Jeder kann vorbeikommen!
- Wer ein RVSP braucht: https://www.meetup.
com/OpenSpaceLabs/events/ (wir haben nur bedingt Plätze!)256044725/

Wer Fragen dazu hat, der sende die gerne an die Mailingliste oder an mich. Wer einen SpaceTalks Vortrag machen möchte, der möge sich noch bei mir melden, damit ich es auf die SpaceTalks Webseite stellen kann.

Wir freuen uns auf euch!

Viele Grüße,

Andreas

—

t: @andreashornig

c: DH0RN

PS: leitet diese Email gerne weiter an Interessierte!

]]>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!

Folgende Themen sind bereits angedacht:

- Intro: Satellitenkommunikation – was fliegt wo rum und was macht man damit, und wieso bauen Uwe und ich diese Woche eine Antennemotorsteuerung?! (Working Title), Andreas
- Status der Distributed Ground Station Network zum Tracken von Cubesats, Andreas
- (TBC) Bodenstation, aber sicher!, lowl3v3l
- Euer Space Thema, DU![2]

Wir können also beides, die Funkwoche und die ESA SpaceTalks super kombinieren!

Info in a Nutshell:

- jeden Tag ab 19:00 Uhr vom 19-24.11.2018
- [0] Eingeleitet mit einem ESA SpaceTalk am 19.11.2018 ab 20:00 Uhr.
- im Krautspace, dem Hackspace Jena, Krautgasse 26, 07743 Jena
- im Hauptraum und im Elektroniklabor (nach Bedarf).
- Themen siehe Link und bringt Funkthemen mit! Ankündigen der Themen wäre toll, aber kein Muss!
- Jeder kann vorbeikommen!
- Wer ein RVSP braucht: https://www.meetup.com/OpenSpaceLabs/events/256044725/ (wir haben nur bedingt Plätze!)

Wer Fragen dazu hat, der sende die gerne an die Mailingliste oder an mich. Wer einen SpaceTalks Vortrag machen möchte, der möge sich noch bei mir melden, damit ich es auf die SpaceTalks Webseite stellen kann.

Wir freuen uns auf euch!

Viele Grüße,

Andreas

—

w: aerospaceresearch.net

t: @andreashornig

c: DH0RN

PS: leitet diese Email gerne weiter an Interessierte!

]]>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!

]]>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!

Space Apps Stuttgart is kindly supported by the Stuttgart chapter of the Deutsche Gesellschaft für Luft- und Raumfahrt (DGLR), shackspace hackerspace and AerospaceResearch.net. Our projects were also presented during the International Astronautical Congress 2015 in Jerusalem, the MRMCD 2017 and other conferences.

[0] https://2018.spaceappschallenge.org/locations/stuttgart/

]]>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.

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.

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.

`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:

`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:

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.

`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:

`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:

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.

- 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.

]]>

**visma – VISualMAth**, an equation solver and visualizer, which aims at showing the step-by-step solution and interactive plots of a given equation.

Deliverables

The major changes which were proposed for the project **visma** during GSoC’18:

- changing the codebase to follow the object-oriented style
- calculus operations like integration, differentiation (including partial diff.)
- solving equations/inequalities and multivariable linear equations
- improved GUI and interactive plots

The following file structure shows which modules were added/modified to the project during the GSoC period:

visma | |__visma (contains all modules) | | | |__calculus (added basic diff. and integr.) | |__functions (converted from dictionary to class based tokens for functions) | |__gui (added elements like qsolver, plotter, settings and modified steps displayer) | |__io (reorganized tokenize and added checks and parser for equations) | |__matrix (added matrix operation, to be integrated with GUI) | |__simplify (reorganized simplify into addsub and muldiv) | |__solvers (added solver for multivariable equation) | |__transform (added modules like factorization and substitution) | |__tests (unit tests for all the above modules using pytest) | | | |__test_calculus.py (constains test cases for calculus) : :.. : |__main.py (modified to accomodate all new GUI elements) |__run.sh (modified to support installing, testing and packaging visma) |__setup.py (for packaging visma)

Below is a real quick demo of some of the features like calculus, solver, plotter etc which were implemented in visma. To experience **visma** and explore all features, go to the install guide or code wiki.

There were many new things I came across while working on this project. I learned about integrating UI elements (using ** PyQt**), unit-testing (using

**Week #01-02: Making ViSMA ‘classy’**– Changed code to follow object-oriented style**Week #03-05: Integrating the Integrator**– Added the calculus modules**Week #06-07: Finding the Unknown**– Implemented solvers**Week #08-09: Develop, Test, Repeat**– Added unit testing for all modules**Week #10-11: Dynamic Simplification and Plotting**– Enhanced the GUI**Week #12-13: Packing Up**– Finishing touches, packaging code, documentation

Though the GSoC’18 period has ended there are a lot of new things which can be added to **visma****. **Some of the changes and features I (others can too) intend to add in **visma** ** **after GSoC are:

- Make visma accessible from the terminal
- Add support for more functions
- Fix the issues created
- Make a webapp

**Project Source**– https://github.com/aerospaceresearch/visma**My Commits**– https://github.com/aerospaceresearch/visma/commits?author=8hantanu**Final PR**– https://github.com/aerospaceresearch/visma/pull/61**Documentation**– https://github.com/aerospaceresearch/visma/wiki**TODO board**– https://github.com/aerospaceresearch/visma/projects/1**Alternate link**– https://8hantanu.github.io/projects/visma

The organization for which I am working is **AerospaceResearch.net**. It has many interesting projects not only for the under-graduate beginners but for the masters‘ degree students too. We are a small group of enthusiasts who love to solve problems related to space. The benefit of being a part of a small group is that you get to know each other in a very short duration of time. We have regular meetings with our project mentors. The best part is that we can contact our mentors anytime. My mentor is Nilesh Chaturvedi who has guided me throughout the project and is still doing so. Alexandros Kazantzidis is also one of the mentors in the organization who cleared my doubts while building the propagation model.

*Link to the organization repo.*

The title of the project is **Implementing Two-Line Element (TLE) ****Input / Output and using it for ****evaluation**.

Two-Line Element (TLE) is a data format or a way of encoding various parameters of an object orbiting Earth at any particular time point, an epoch. TLEs can describe the trajectories only of Earth-orbiting objects. It is widely used as an input for projecting the future orbital tracks of space objects. A TLE set may include a title line preceding the element data, so each listing may take up three lines in the file. The title is not required, as each data line includes a unique object identifier code. The two lines contain a lot of information about the object and have a length of 69 characters each.

The scripts that were added to the module are database initialization, scraper, parser, Gibb’s method, and propagation model. More details about each element are as follows:

Database contributes a major role in testing and generating the result of a module. In the beginning, we did not have TLE data. So, we decided that we will store TLEs from the celestrak website in the database. Now, it is time to choose which database we are going to use: SQL or NoSQL? Both the databases have their own advantages and disadvantages. After taking care of the needs and the data which we are going to store, we chose SQL based data. The reason behind this choice is that the input is well defined and structured. We only want to store 2 strings (that is, line 1 and line 2 of the TLE) at a particular time epoch. MySQL is used to store the data. The format of the data stored in the database is – timestamp, line 1 of TLE, line 2 of TLE.

For database creation, initialization, and maintenance two python scripts were written:

- initDatabase.py

The script first creates a database in MySQL so that we can create tables to store the TLEs of the satellites. After that, it crawls the celestrak website and extracts the satellite names only, so that we can create tables in our database. But there was a problem in the creation of tables as the satellite names contain special characters (like dashes, spaces and parenthesis) and giving a special character into a MySQL command produced an error. To solve this problem, satellite names were converted into their respective hexadecimal md5 hash value which was an alphanumeric value and hence the problem was solved. So, the names of the tables are now satellite’s md5 hash value. The format of the tables inside the database is,+-----------+---------------+---------------+ | timestamp | line_1_of_tle | line_2_of_tle | +-----------+---------------+---------------+ | t1 | line1 | line2 | | t2 | line1 | line2 | | .. | ... | ... | | .. | ... | ... | | tn | line1 | line2 | +-----------+---------------+---------------+

The flowchart of the script is as follows,

Following is the image of the database containing the tables,

- scraper.py

This script is responsible for updating/adding a new TLE data into the database. The script first creates a connection with the database and then crawls the celestrak website to extract TLE data for every satellite present there. After the data is extracted, it converts the name of the satellite to its md5 hash and adds the TLE data into the respective table through a MySQL query.

The flowchart of the script is as follows,

The table containing TLE data,

** Format of the table is given above*

Currently, the database module is shifted from the organization repository to my own repository (which contains all the codes created during the GSoC) on github as it is producing a build error during the build process. In this build process (which was running on github), the script is creating a connection with the locally stored MySQL database which is then creating an error in it. The database module will be added later using some online database.

The database module can be found here.

See the source code here.

Gibb’s method is based on the fact that two body orbits lie in a plane. It takes three position vectors as its input arguments and generates a pair of position vector and velocity vector, together known as the state vector. The Gibbs method is implemented using the OOP concepts and hence it supports the data abstraction and encapsulation. The method includes a lot of mathematical computation.

The input to the script is in the following format,

timestamp, x-coordinate, y-coordinate, z-coordinate t1, x1, y1, z1 t2, x2, y2, z2 t3, x3, y3, z3 .. .. tn, xn, yn, zn

A pseudo-code and a brief explanation of the script is as follows,

Pseudo-code: Note: Vector is in bold and magnitude is in normal format. e.g - 'a' represents vector and 'a' represents it's magnitude. Input:r1- first position vectorr2- second position vectorr3- third position vector 1. Taker1,r2andr3. 2. CalculateC12=r1xr2,C23=r2xr3andC31=r3xr1. 3. Verify thatû.Â23= 0 (ûis u cap or unit vector u) 4. CalculateN,DandSfrom below equations,N= r1(r2xr3) + r2(r3xr1) + r3(r1xr2)D=r1xr2+r2xr3+r3xr1S=r1(r2 - r3) +r2(r3 - r1) +r3(r1 - r2) 5. Calculatev2from below,v= √(µ/ND) . ((Dxr)/r +S) Now, take r2 as position vector, v2 as velocity vector and both will together form state vector.

A file containing position vectors at various time epoch is passed into the script. The script reads the file and takes a set of three consecutive position vectors in order to apply the Gibbs method on it. The format of the file is – timestamp, x coordinate, y coordinate, z coordinate. After taking the set, the script passes the data into *gibbs()* function (pseudo code of Gibb’s Method is mentioned above). Then the function computes the result and returns the state vector. Next time the loop iterates, the first position vector gets removed from the set and the next position vector from the file gets added as the third position vector and it is then again passed into the function. As the file contains a lot of position vectors and for a set of 3 consecutive vectors, the script is generating a state vector. It is evident that the output generated will be two less than the total number of position vectors in the input file. After taking this point into consideration, a vector is created which stores every state vector into it and returns it as result.

The script contains a function which converts the state vectors into Orbital or Keplerian elements namely semi-major axis, inclination, right ascension of the ascending node, eccentricity, argument of perigee, and mean anomaly which can thus help further in tracking and plotting satellite’s orbit and in a lot of other computation.

Pseudo code for converting state vector into orbital elements is as follows:

Pseudo Code: Note: Vector is in bold and magnitude is in normal format. e.g - 'a' represents vector and 'a' represents it's magnitude. Input:r- position vectorv- velocity vector 1. Calculate the distance, r = √r.r2. Calculate the speed, v = √v.v3. Calculate the radial velocity, vr =r.v/r 4. Calculate the angular momentum and it's magnitude,h=rxvh = √h.h5. Caculate inclination, i = cos–¹(hz/h) | hz : z-axis inh6. Calculate node line and it's magnitude,Ê= [0, 0, 1]N=ÊxhN =√N.N7. Caculate right ascension of the ascending node, _ | cos–¹(Nx/N) if (Ny ≥ 0) Ω = / \ |_ 360° - cos–¹(Nx/N) if (Ny < 0) where, Nx : x-axis inNNy : y-axis inN8. Calculate eccentricity vector,e= (1/µ)[(v² - µ/r)r- r.vr.v] 9. Calculate eccentricity, e =√e.e10. Calculate argument of perigee, _ | cos–¹(N.e/N.e) if (ez ≥ 0) ω = / \ |_ 360° - cos–¹(N.e/N.e) if (ez < 0) where, ez : z-axis ine11. Calculate true anomaly, _ | cos–¹(e.r/e.r) if (vr ≥ 0) θ = / \ |_ 360° - cos–¹(e.r/e.r) if (vr < 0) 12. Calculate semi-major axis, rp = h²/(µ.(1+e)) | µ : 398600.4418 (constant) ra = h²/(µ.(1-e)) a = (rp+ra)/2

See the source code here.

Simplified perturbations models are a set of five mathematical models (SGP, SGP4, SDP4, SGP8 and SDP8) used to calculate orbital state vectors of satellites and space debris relative to the Earth-centered inertial coordinate system. This set of models is often referred to collectively as SGP4 due to the frequency of use of that model particularly with two-line element sets produced by NORAD and NASA.

The propagation model used for the project is SGP4. The model takes a TLE without title line as input arguments. The output generated by the propagation model is a state vector.

The code is taking TLE as input. Then it extracts the necessary elements in *compute_necessary_tle() *from the TLE which helps in the computation of the SGP4. The necessary information includes inclination, right ascension of the ascending node, eccentricity, argument of perigee, mean anomaly, mean motion, and bstar drag term. After that, the propagation model is exected which include a lot of heavy mathematical computation. After the computation gets over, the function return state vector as output.

Now to check whether the code is producing the results correctly, we need to convert the resulted state vector into TLE back. So, one more function is added which recovers the TLE back from state vectors. To validate the result, Spacetrack Report 3 is used which contains a sample TLE to find the state vector at a particular epoch. The propagation model is taking two input arguments t1 (start epoch time) and t2 (stop epoch time). The resulting state vector is computed in the given range [t1, t2] (including both the points). As there is a state vector at every epoch so an output vector is created which stores all the state vectors and returns it as a result.

Now, the problem is that the input is coming in the form of Keplerian elements and the function accepts a TLE. One way to resolve this is to recover the TLE back from the Keplerian elements and then pass TLE as an input and again extract the same information (in *compute_necessary_tle()* function) in order to propagate the model. But since this approach is costly, the other way to resolve the problem is to create another function which takes Keplerian elements as input parameters. As a result, there is no need to transform the same information again and again. This is the reason why *compute_necessary_kep()* was added. Now, the code is accepting the input in both ways: keplerian elements as well as TLE. In other words, execution of the code can either start from *compute_necessary_tle()* or *compute_necessary_kep()* depending on the input. After producing state vectors from t1 to t2, the script is storing it into an array and returns it as an output.

Follow below steps to run the script: >>> obj = SGP4() >>> obj.compute_necessary_kep(<input>) or >>> obj.compute_necessary_tle(<input>) >>> obj.propagate(t1, t2)

Calling *compute_necessary_kep()* or *compute_necessary_tle()* is necessary. As this function extracts the important information from the given input and initializes the class variables which are further used in the propagation model and without which the computation will not be possible. If *compute_necessary_kep()* or compute_necessary_tle() is not called then the interpreter will throw a custom exception, which says,

Error: Call compute_necessary_kep() or compute_necessary_tle() function of the class SGP4 before calling propagate(). Function Declaration: compute_necessary_kep(list, float) Parameter 1:List of keplerian elements (semi-major axis, inclination, ascension, eccentricity, perigee, anomaly) Parameter 2:bstar drag term Returns: NIL compute_necessary_tle(str, str) Parameter 1: First line of the TLE Parameter 2: Second line of the TLE Returns: NIL

So, just remember to call the functions in the correct sequence and you are good to go.

A test file for propagation model is also written which verifies the output of the two functions *propagation_model()* and *recover_tle()*.

- Spacetrack Report No. 3 (Models for Propagation of NORAD Element Sets)
- MATLAB File Exchange SGP4

- Commits: https://github.com/aerospaceresearch/orbitdeterminator/commits?author=aakash525
- Database: https://github.com/aakash525/Orbital-Determinator/tree/master/code/database
- Gibbs Method: https://github.com/aerospaceresearch/orbitdeterminator/blob/master/orbitdeterminator/kep_determination/gibbsMethod.py
- Propagation Model: https://github.com/aerospaceresearch/orbitdeterminator/blob/master/orbitdeterminator/propagation/sgp4.py