## 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|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|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|OrbitDeterminator|Arya] Week #1-2 – Hello World!

Hello World!

I have been selected to work for AerospaceResearch.net under the Google Summer of Code program. Since I am a new contributer here, I think I should give a short introduction first. I am Arya Das, an undergraduate student of computer science at Indian Institute of Technology, Patna. I am highly passionate about space. I am also interested in robots, flight simulators, playing piano and swimming.

In this blog post I am going to describe my experience so far at AerospaceResearch.net and the project I am working on.

## [GSoC2018|VisMa|Shantanu] Week #01-02: Making VisMa classy

I came across AerospaceResearch.net when browsing through GSoC organizations. It offered projects both in my field of interests and academic domain. I had to make a hard choice between DirectDemod and VisMa and I finally chose VisMa as my project for GSoC.

This is my first GSoC dev log (more to come). Here I will be blogging about what I learned, what I have done and what I will do. So following is the work I have done in VisMa.

##### Done so far…

I used the community bonding period to fix minor errors and get more familiar with the source. I restructured the code base so that new modules could be accommodated. Code duplication was reduced using proper imports between modules. New modules like calculus, transform, solversgui etc were initialized. A token IDing module was written to handle equations during calculus operations.

## Call for Google Summer of Code 2018! Student stipends of up to 6600 USD for open-source space coding (please Forward)

Again for the 4th time, AerospaceResearch.net[0] is proud to be selected as an official mentoring organization for the Summer of Code 2018 (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 27. March 2018, students can apply for an hands on experience with applied space programs. As an umbrella organisation, AerospaceResearch.net and KSat-Stuttgart e.V. 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]
• or your very own proposal![2]

## It is time again for Hacktoberfest 2017!

It is time again for Hacktoberfest and we already took part in it with our projects. On the 7th of October, we joined people in shackspace, Stuttgart to work on open-source projects by creating pull-requests.

The goal Hacktoberfest was and still is to that everyone creates at least 4 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. We did so with 2 projects already…

## MRMCD2017: Automatisierte Pflanzenzucht und maschinelles Lernen

Seit April 2016 züchten wir so automatisch wie möglich Pflanzen. Erst Kresse inzwischen auch Phacelia und später vielleicht Gänseblümchen. Verwendet wurden hierbei alte RaspberryPIs, IKEA-Samla-Boxen und Sensoren, die noch in unseren Projekt-Boxen schlummerten. Nach über 100 Wachstumszyklen (vom Sähen bis „Ernten“) haben wir einige Fails erlebt: Schimmel (diverse), zu viel Wasser, zu wenig Wasser, Sensordefekte, Internetausfälle und menschliche Unachtsamkeit. Es wurden über 400000 Photos und über 2 Millionen Sensorwerte gespeichert. Um den fehleranfälligsten und wichtigsten Sensor (Wasserstand in der Box) zu ersetzen wurden Classifier trainiert. (Tensorflow, Convolutional-Neural-Network) Wir würden euch gerne von unseren Erfahrungen berichten.

Code und Daten: https://github.com/mfa/cress-classify

Erfahrungen bei der automatisierten Zucht von Pflanzen (Kresse, Phacelia) und spätere Verwendung der Sensor-Werte und Photos für maschinelles Lernen.