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
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:
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
Hi, we are team PlaNS.
We worked on the Planetary Navigation and Sensor System.
There is no GPS around Mars, so rovers, sensors and even astronauts need to be located differently.
Our PlaNS will solve this problem with a ground based positioning system. During normal data transmission from the sensor on the rover, or inside the Astronauts space suits, the PlaNS connects to it and constantly tracks the rover and determines its position inside the habitat.
So the rover can get lost in a crater and losing connection to the habitat, but the last location is known, so the rover can be recovered and also no Astronaut like Mark Watney will be left on Mars again.
Nothing and no one will be left behind on any planet with our PlaNS, even today
Find us on https://twitter.com/PlanetaryNaS
Work with us on https://github.com/aerospaceresearch/Planetary-Nav…
We support the MIT open-source license!
Mission Statement
Localizing and never loosing any sensor, rover and Astronaut on Mars without a GPS! PlaNS shall create a hybrid data and localizing sensor network, and also serve as a personal tracking aid for astronauts during extra base activities.
The Problem
During the current phase of Mars exploration it is difficult to position rovers and other assets on Mars because there are no Global Navigational Satellite Systems (GNSS) like GPS, Galileo, Glonass or Beidou in Martian Orbits and thus all rovers must rely on inertial measurement units (IMUs) for their relative position. Over time, the measured position can deviate from the real position and summing up over a long time. This poses a possible danger when the rover can drive into a creater because it calculated its position still outside the crater.
Now imagine Astronauts on Mars losing a team mate because they don’t know his/her last position! There is currently no other GNSS like system on Mars and the installation of a 12+ satellite system offering a global positioning system for Mars won’t take place during the first exploration phases due to budgiting and infrastructure reasons.
The Solution
Our solution includes a scalable approach based on a mobile antenna array system that is synchronized via a central time source from the base habitat (via wires or wireless) and localizing the position of any signal by its nominal and permanent transmission to the antennas.
The antenna system will grow with its tasks. It will start with 5-6 antennas near the first landing site’s habitat and can be place within walking distance and then to nearby elevated landmarks like mountains or crater rims. With each new habitat module, the antenna grid is expanded and the coverage zone of sensor data transmission and positioning will be expanded.
Even with a Martian GPS at one point, the PlaNS system can serve as an additional or redundant terrestrial communication and localisation system.
The Technical Approach
Our system can be realized by current, state of the art technologies. We decided for a rapid prototype appraoch by using Software Defined Radio receiver sticks serving as receivers at each antenna array’s groundstation and using two transmitters on ISM and PWM bands simulating the sensors and Astronauts transceivers.
Our appraoch also includes timesynching on the same transmitting channel as the sensors and Astronauts. Due to the fact that the relative positions of the antenna array ground stations and also the position of the central time synching transmitter are known, one time synching pulse can be used at all stations for synching their local system times. With this, a Time Difference of Arrival (TDOA) can be achieved with each incoming signal from sensors and Astronauts.
Future
Only the sampling rate of the receivers will limit the accuracy of the system. With our „cheap“ demonstrators, samplingrate is 2MHz and thus the distance the electro-magnetic wave is travelling will be about 150 meters. Our system will give rough directions but for less than 50€ per ground station. More suffisticated SDR receivers like HackRF or LimeSDR will improve the accuracy.
The team decided to keep on working on PlaNS because it is also relevant for further Planets and Moons, but mainly on Earth. A mobile search and rescue system for hikers in areas with deep valleys blocking the GNSS reception will speed up the localization, bringing the rescue team earlier to the accident area and thus saving lifes!
Status
We are currently working on the analysis of our measuring test during the Space Apps 2018 Hackathon.
The PlaNS system is part of the Distributed Ground Station Network (DGSN) where a similar approach is used to track cubesats and other satellites in orbit. So PlaNS is a natural extension of DGSN and will be worked on with the community and also during future Google Summer of Code campaigns.
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:
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.pyorbitdeterminator/kep_determination/least_squares.pyThe 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_satThe 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_mpcThe 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_satSimilar 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_mpcSimilar 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.
astropy: currently, the user is not allowed to specify the ephemerides to be used in the orbit determination of Sun-orbiting bodies.(alt, az) -> (ra, dec) conversion functions from the astropy library.
visma – VISualMAth, an equation solver and visualizer, which aims at showing the step-by-step solution and interactive plots of a given equation.
About the author: Hello everyone, I am Aakash Deep, I am a 4th year undergraduate student pursuing my degree in Bachelor's of Technology (B.Tech) in Computer Science and Engineering (CSE) from Indraprastha Institure of Information Technology, Delhi (IIIT-D) in India. I am a space enthusiast and I like travelling. My major hobby is speed-cubing.
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. „[GSoC’18|Orbit-Determinator|Aakash] Implementing Two-Line Element (TLE) Input / Output and using it for evaluation“ weiterlesen
This is GSoC’18 log#06. Here I will cover on what I have done in week #12-13. Link to the previous log. The work in these two weeks involved packaging and documenting the code.
Deciding which packaging style to choose was a difficult task. Though there were a number of options available for packaging python apps I couldn’t find one which makes it simple for packaging it for windows. I managed to convert the source into a single executable file using pyinstaller but the performance was compromised.
„[GSoC’18|VisMa|Shantanu] Week #12-13: Packing Up“ weiterlesen
In this blog post I will briefly talk about what I have done in my three month work period at AerospaceResearch.net. I will link to all the code, documentation, blogs etc. that were the product of this work.
„[GSoC2018|DirectDemod|Vinay] Final Blog Report“ weiterlesen