[GSoC2018|VisMa|Shantanu] Week #03-05: Integrating the Integrator

This is GSoC log#02 (view log#01 here). Here I will cover on what I have done in week #03-05 and a gist of what has been accomplished in Phase I coding period.

Done so far …
  • Created parser.py which handles conversion of tokens to LaTeX or strings and vice-versa.
  • Some simplification issues were fixed
  • Integrated the differentiation.py and integration.py to the project along with the step-by-step explanation.
  • Support for partial differentiation and „partial integration“ was added.
  • The code was again refactored to decrease complexity and remove unused modules.
  • Added factorize.py module. Can currently factorize polynomials.

„[GSoC2018|VisMa|Shantanu] Week #03-05: Integrating the Integrator“ weiterlesen

[GSoC2018|DirectDemod|Vinay] Week #3-4 : NOAA-APT signal decoding

In my last blog  the process of accurately extracting sync locations within the NOAA APT signal was explored. In this blog, I would like to extend the comparison of the two methods that were implemented. Then look at how the process is influenced by presence of noise, sample drops and doppler effect.

„[GSoC2018|DirectDemod|Vinay] Week #3-4 : NOAA-APT signal decoding“ weiterlesen

[GSoC2018|OrbitDeterminator|Arya] Week #3-4 – Ground Track and WebApp for OrbitDeterminator

We got important stuff done in weeks 3 and 4. Everybody knows that visuals and graphics are very important for presentation purposes. The most popular library for plotting is matplotlib. It can generate excellent plots but in the end, they are static images. Instead of static images it’s better if some interactive content is presented. So we decided to make a webapp for OrbitDeterminator. A webapp makes it easier for the end-user to run the program. It can also be hosted on a publicly-accessible server, which means that anyone can use it without going through the pain of downloading and installing the program. For making the webapp, my mentor Alexandros suggested the excellent Dash library by Plotly.

Dash by Plotly

Dash is a Python library that can be used to make web applications. The library is built to be hosted on a server and be used by multiple people at once. It is powered by Plotly which produces beautiful, interactive plots in the browser itself. Programming in Dash is simple. First, you have to define the layout of the app in the form of a list of html components. You can style them as you like or add additional parameters. After this, you have to define callback functions. These functions will be triggered whenever the user interacts with the UI (like pressing a button, or typing some text). These functions can be used to change the elements displayed on the app. This makes the app interactive.

Designing the app

For now, OrbitDeterminator’s primary function is to find a good set of orbital elements that match a noisy set of observations. The webapp will be a graphical way to do this. Observations are stored in CSV files in the following format:

# Comments
# here.
#
# t x y z
<time_1> <x_1> <y_1> <z_1>
<time_2> <x_2> <y_2> <z_2>
...
<time_n> <x_n> <y_n> <z_n>

So the webapp must have a place to upload csv files. We also want to show the name of the file and the file contents in case the user has uploaded the wrong file. And of course, we have to show the results and plots of the results. After discussing with Alexandros, I settled on this layout:

  • File upload box
  • File name and contents
  • Keplerian elements
  • Spatial plots
  • Ground track
  • Coordinate vs time plot
  • Residuals plot

But the user might not require all this information at once. So all the components must be collapsible, to hide them from view if not required. Making the webapp required lots of googling but was relatively easy. The end result is this:

OrbitDeterminator Webapp
OrbitDeterminator Webapp

All the plots are interactive. You can zoom, pan, and rotate them. You can also save any plot you want as a png file. Most of the plots were straightforward. The most difficult plot was the ground track, whose algorithm I will discuss below.

Plotting the ground track of a satelllite

To plot the ground track, we have to know the position of the satellite with respect to the Earth’s surface. First, I thought that just converting the coordinates into polar form and plotting φ vs θ would do the job. But I forgot that the satellite coordinates were measured with respect to an inertial (fixed) reference frame, whereas the Earth’s surface is rotating. So the actual coordinates will be different. I went through two articles on CelesTrak and Astronomy StackExchange to come up with the algorithm.

NORAD uses True Equator Mean Equinox (TEME) reference frame for its TLEs. In this frame, the origin is at the Earth’s centre. The z-axis points toward the North Pole. The x-axis points to the vernal equinox. And the y-axis completes the right-handed coordinate system.

TEME Coordinate System
TEME Coordinate System

We need to convert coordinates in TEME to an Earth-Centered-Eath-Fixed (ECEF) reference frame. In such a frame, the origin is at the Earth’s centre and the the coordinate axes are fixed to the Earth’s surface (which means that they rotate along with the Earth). Many such frames exist but the standard one is the International Terrestrial Reference Frame (ITRF). In this frame, the z-axis points toward the North Pole, the x-axis points toward 0°E 0°N. And the y-axis completes the coordinate system. Since both TEME and ITRF share a common z-axis, the latitude will not be affected. Only the longitude will be shifted by a certain amount. This amount, known as the Earth Rotation Angle, is the angle between TEME’s x-axis and ITRF’s x-axis. Now I will write down the pseudocode I used to determine this angle.

Let t be the time at which we want to find the Earth’s rotation. Let t_mid be midnight on the same day, so that t - t_mid is the UTC time during the day. Let J2000 be the time Jan 1 2000 12:00 pm UTC(this is the J200 epoch). Then the pseudocode is:

days_since_J2000 = t_mid - J2000
# multiply the above by an appropriate 
# constant to convert the units into days

# centuries since J2000
Tu = days_since_J2000/36525

# effects of precession of the Earth's axis
tg0h = 24110.54841         +
     8640184.812866 * Tu   +
           0.093104 * Tu^2 -
           6.200e-6 * Tu^3

# Greenwich Mean Siderial Time in seconds
tgt = tg0h + 1.00273790935 * (t-t_mid)

# rotation angle in degrees
rotation_angle = (tgt%86400)*360/86400

After getting the rotation angle, we can subtract it from θ to get the actual longitude.

Putting everything together , we get this plot of the ISS for 21st May 2018 18:27:54 UTC. I used this NASA website to generate the NASA ISS plot.

Ground Track of the ISS on 21st May 2018 from 18:27:54 for 2 orbits.
Ground Track of the ISS as generated by OrbitDeterminator
Ground Track of the ISS as generated by NASA.
Ground Track of the ISS as generated by NASA.

As you can see, the results line up pretty well. Note that this is a simplified model and is not super-accurate, but it gives roughly the same results.

Future Work

  • Integrating the SGP4 model into OrbitDeterminator.
  • Making a DGSN simulator (this will be used until the real DGSN starts working).
  • Making a Kalman filter to combine the two sources of data.

[GSoC2018|USOC GUI|Pedro] Weeks 3-4 – Handling Protocol Data

This is my second post since the start of GSoC18. I would recommend you check my first post for a bit of context before reading this.

Current state of the project

I spent the past two weeks designing a new Window for assigning variables defined in a protocol file anytime during runtime of the application. This feature is one of the main goals/tasks of my project during these 3 months as a GSoC student, so I don’t want to rush a definitive solution.

For a little insight, a protocol file is a XML file that tells the Ground Station how incoming data should be handled. It contains multiple sensors, each one with different variables and datatypes. Before, the selected protocol was hardcoded which means that the user would have to compile and re-run the application for the changes to take effect. This was fixed in my first implementation of the Layout Creator Window in the first two weeks. Now, there’s the need of assigning data from the protocol to the created charts and states. My first solution for this problem was an ‚Assign Data‘ Button inside each chart/state in the LayoutCreator window.

Assign Data Button
Assigning Data to a Chart

After some time, i figured this would not be the optimal solution for many reasons:

  • The user may not want to assign variable information to UI components right away.
  • If there is a big number of charts and states, assigning variables to each one becomes time-expensive and tedious.
  • There’s no way of knowing which variables and sensors are assigned to each chart. The user would have to open each component’s window and check.
  • No support for dragging and dropping variables (another project requirement)

All of these above go against what was proposed right at the beginning: a quick and simple implementation of a ground station that lets the user focus on what’s important, rather than the User Interface.

So, I came across another design and solution for this. Instead of assigning variables to a chart/state one at a time, all desired charts and segments are shown inside a TreeView.

Assigning Data to Charts/States

By selecting a variable from the left TreeView (source) and a state/chart from the right TreeView(destination), the user can easily assign data to UI components. For now, a button click is needed to shift variables from one tree to another, but I plan on implementing a drag-and-drop‘ feature in the future.

Protocol data persistence

Last dev blog I talked about how GUI preferences are being stored in a JSON file. To avoid having to handle protocol data each time the user loads an existing configuration file, I had to store some more information in the JSON file (protocol name, variables and sensors). For now, only the corresponding names are stored.

What’s next

There are still some bugs with the new iteration of the AssignDataWindow. It seems simple shifting variables from one tree to another, but since each item is treated as a String, there’s quite a lot of logic behind it to make sure the right components and variables are being correctly assigned. Besides, I still haven’t started working on actually assigning protocol data to charts and states (i need to make the layout creation process as solid as possible before that).

First month and evaluations

After 4 weeks of work, I finish my first coding period. I believe I achieved what I planned in my proposal for this time. I’ve been having a great time at this organization and I believe every other student feels the same. Our mentors are great and really want us to succeed more than anything. See you in two weeks!

 

– Pedro Portela

Four weeks at GSoC

About the Author: Hello guys, I am Aakash Deep. I am a B.Tech. student from Indraprastha Institute of Information Technology, Delhi (IIIT-D) in Computer Science and Engineering (CSE). I am a speed-cuber and obviously, my hobby is solving Rubik's Cube.

This post is in the continuation of my last post, as the last post contains the information about the first two weeks as being a GSoC student and the work done in that time frame. Those who missed it can access that post here.

Week 3 and 4

As the database was created earlier and now it is updating every day as the new TLEs are getting store into it. Now, the work left is implementing propagation model.

For the propagation algorithm, the SGP4 algorithm is used. The algorithm takes the TLE as input and computes position and velocity vectors. Now, we will come to the workflow of the code,  that how the code is behaving. A sample test file is added to my github (can be found here). The file contains the multiple TLEs of a single satellite which is taken from the database. The code takes this as input and passes it to the propagation model. Then propagation model computes the position and velocity vectors of each TLE. After that, the averaging occurs and in the end, we get a single position and velocity vector. These vectors are then used to find the orbital elements of the satellite.

Evaluation 1

Phase 1 evaluation of the GSoC is nearby. The dates of the deadline are from June 11 to June 15. Following checkpoints are met before the deadline:

  • Creating database
    Creating the database and a table for mapping satellite’s name to its corresponding md5 hexadecimal hash and initializing tables in the database for each satellite.
  • Scraping data from web
    Scrape data from the celestrak site and populated it into the database into their respective tables.
  • Maintaining database
    Updating database whenever new TLE comes on the website.
  • Implement Propagation Model
    Converting TLE into position and velocity vector and then computing orbital elements. Now, there can be two ways to do it.  We have a file containing multiple TLE of the same satellite at different time points.
    The first way is, feeding this file as input. Compute position and velocity vector of every TLE and average these vectors to get a single vector. Use this averaged vector to calculate orbital elements.
    The second way is, feeding the file as input. Compute position and velocity vector of each TLE and from these TLE calculate position and velocity vector for each pair of vector and then average the orbital elements. After this, we will get the averaged orbital elements.
    Right now, I don’t know which way is better but we as a team trying to figure it out.
  • Compute orbital elements
    Calculates orbital elements from the given pair of position and velocity vector.

Work on Progress

  • Documentation
  • Testing

[GSoC2018|OrbitDeterminator|Jorge] Week #3-4 – Least squares fit to cartesian positions as a function of time

Introduction

An orbital fit by least-squares is a technique for computing the set of six Keplerian elements which best describe an orbit with respect to a *whole* set of observations.
As the set of Keplerian elements we choose semimajor axis a, eccentricity e, time of perigee passage τ (i.e., how much time has elapsed since the last perigee), as well as the standard Euler angles which describe the orientation of the orbital plane with respecto to the inertial frame: argument of pericenter ω, inclination I and longitude of ascending node Ω. We denote by X the set of these six Keplerian elements; that is, X = (a, e, τ, ω, I, Ω).
A least-squares fit is simply to look the minimum of a scalar (i.e., real-valued) „cost“ function Q(X). The Q function is simply a measure of how well our theoretical predictions, for a given set X of orbital elements, depart from observations. In an ideal world, we could find a set of orbital elements such that it perfectly matched the observations and thus Q(X)=0. Nevertheless, real-world measures carry uncertainties, and we can only hope to find orbital elements X which make Q attain its minimum possible value with respect to all the observations we have made.
The values of the cost function Q(X) for a least-squared problem are constructed the following way: take *all* the values you observed (call them v_i), and substract from each of those the values you were expecting to measure for a given set of orbital elements X (say, V_i(X) ). Call each of these differences the residuals, xi_i(X) = v_i-V_i(X) . Then, square the residuals, and sum all the squared residuals. The value you obtain following this recipe, is the value of Q(X).
In practice, the least-squares method finds a local minimum of the cost function by performing an iterative procedure, which needs a good initial „guess“ solution X0; otherwise the procedure may converge to non-feasible results. Hence, it is necessary that the „good“ initial guess be provided by a preliminary orbit determination method.

„[GSoC2018|OrbitDeterminator|Jorge] Week #3-4 – Least squares fit to cartesian positions as a function of time“ weiterlesen

[GSoC2018|OrbitDeterminator|Aakash] Implementing Two-Line Element (TLE) Input / Output and using it for evaluation

About the author: Hello everyone, I am Aakash Deep, B.Tech student in Computer Science and Engineering (CSE) from Indraprastha Institute of Information Technology, Delhi (IIIT-D). Currently completed my 3rd year in it. I am a space enthusiast and always keep searching about the space.

Introduction

Orbit Determinator,  I think the project is self-explanatory. Yes, you are right the project is tracking the orbit of the satellites using their TLEs at different time points.

TLE short for Two-Line Element. It is a data format encoding a list of orbital elements of the Earth-orbiting object for a given point in time. It consists of two line with each having character length 70. Orbital elements play a major role in plotting the orbit of the satellite. Line2 of the TLE contains all the orbital elements. „[GSoC2018|OrbitDeterminator|Aakash] Implementing Two-Line Element (TLE) Input / Output and using it for evaluation“ weiterlesen

[GSoC2018|OrbitDeterminator|Jorge] Week #1-2 – Look up to the sky and marvel!

Hi, everyone! My name is Jorge Pérez, I’m a Physics PhD student at UNAM, Mexico, and this year I have been honored to form part of Aerospaceresearch.net as a GSoC student. Since I am a Python newbie, in these lines, I will try to follow the great Kepler, who in the Preface of his New Astronomy wrote:

What matters to me, is not merely to impart to the reader what I have to say, but above all to convey to him the reasons, subterfuges, and lucky hazards which led me to my discoveries. When Christopher Columbus, Magellan and the Portuguese relate how they went astray on their journeys, we not only forgive them, but would regret to miss their narration because without it the whole grand entertainment would be lost.

So, indeed, even when these last few days have been about warming up, I have been learning a lot. As a first task for my GSoC project, I have been coding some Python functions which will allow orbitdeterminator to load data from text files which contain position observations of either satellites or natural bodies, such as Near-Earth Asteroids (NEAs). Observational data for these type of objects is usually written to text files following fixed-width column formats. That is, in this kind of text files, for example, column 1 to 5 might refer to a numeric ID of the observed object; etc…

As a first thought to implement this, since these formats are defined via columns, my idea was that it might be safer to read these files using Python’s native file reading functions. And I was indeed able to read formatted files and save them into a Python list, but then I would have had to convert that to e.g. a numpy array, or something similar, in order to compute interesting stuff from the data.

So, as a second option, and after learning more about numpy, I thought that the `numpy.loadtxt` function might be the best approach, interpreting the whitespaces as delimiters and read each element as a string. This worked for a particular case I was working with, but I wasn’t sure if this approach would work for other formats.

And then, I worked on a third attempt at this. I realized that there was another numpy file-reading function, `numpy.gentfromtxt`. I liked this function better, since it tolerates files with missing values, as well as admitting files formatted with fixed-width columns. So, at the end, this was the approach that I took, and went on to code file-reading functions for some relevant formats which we will be using during the summer.

So now that we have the ability to load actual position data for satellites and asteroids, the next step, besides refining what I already coded, will be to implement orbit determination methods which take into account this kind of observational data from optical instruments, i.e., telescopes. And once this is done, the next step will be to code an orbit determination subroutine for radar observations, which are more subtle to reduce, but we will talk about this in a future blog post.

Incidentally, these last few days in Mexico City have been unusually warm; but tonight this weather, with clear skies and soft winds, allowed one of the most beautiful sights of the rising Moon in Mexico City since I can remember. Let’s not forget to always look up to the sky and marvel!

[GSoC2018|USOC GUI|Pedro] Week #1-2 – First 2 weeks as a GSOC Student

Introduction

Hello everyone. I’m Pedro Portela, a Software Engineering undergraduate student at ISEP, Portugal.  This year I applied for the first time to the Google Summer of Code Program and even though only 2 weeks have passed, I must say that I have been having a great time. In this blog post, I’m going to talk a little about how the past days have been and how I handled my work and schedule. My end goal for these dev diaries is for future gsoc students to read and get an understanding of how working for this program and AerospaceResearch looks like.

„[GSoC2018|USOC GUI|Pedro] Week #1-2 – First 2 weeks as a GSOC Student“ weiterlesen

[GSoC2018|DirectDemod|Vinay] Week #1 – Accurate sync detection from NOAA-APT signals

Hello everyone!

A little introduction since this is my first post: I am Vinay, an Electronics and Communication engineering student from IIIT Bangalore, India. I am working for AerospaceResearch.net under the Google Summer of Code (2018) programme. This organization was among very few organizations that caught my eye, owing to their very interesting projects in my fields of interest. I really believe in the core ideas of this organization, which is a great motivation for me. So far, it has been a great experience working on my project under the mentorship of Mr. Andreas Hornig.

This blog post will look at how synchronisation signals are being detected in the NOAA APT transmissions accurately.

„[GSoC2018|DirectDemod|Vinay] Week #1 – Accurate sync detection from NOAA-APT signals“ weiterlesen