GSOC2021 ideas for AerospaceResearch.net + ep2lab of Carlos III University of Madrid

Google Summer of Code 2021 with AerospaceResearch.net, KSat-Stuttgart eV, the Institute of Photogrammetry (IFP, University of Stuttgart) and ep2lab of Carlos III University of Madrid.

This is AerospaceResearch.net’s common ideas page for Google Summer of Code 2021. Read everything, have fun, make space possible! You want to find here …

  1. General information
  2. Our Coding Ideas List for you
  3. Coding Ideas Full Description
  4. Infos for Students
  5. What else do we offer?
  6. Contacts

1. General information:

Constellation brings space to people by means of citizen science. We believe there is an open space for everybody …

„Space, is big, really big, you just do not believe how much, hugely, mind-bogglingly, big it is, I mean, you may think it’s a long way down the road to the chemists, but that’s just peanuts to space “ – Douglas Adams

We really enjoyed mentoring creative students during GSOC 2013, 2014, 2017, 2018, 2019 and 2020. We’ve learned a lot, so we want to share this experience again and support you! We collaborated with the Cosmic Dust Group and the KSat-Stuttgart Team of the Institute of Space Systems (IRS) at the University of Stuttgart. With them, we have launched two new apps, we even supported the European Space Agency (ESA) and their Interplanetary meteoroid environment for exploration (IMEX) project, we released several papers, simulated comets worth 10000 hours of computing power and discussing our findings with an astronaut and experts. How cool is that? And we want you to be part of this again. So we are re-applying this year and give you three chances to be part of this coding family.

– Be a GSOC student! 
– Be a GSOC Mentor! 
– Provide a GSOC Project!

We did not expect overwhelming reactions about our ideas. So we would like to expand the mentoring and projecting the process. There is space for everyone!

If you are interested in working with AerospaceResearch.net please follow the following steps.

  1. Join our Zulip Chat https://aerospaceresearch.zulipchat.com/ If you are interested in an open-source space technologies project that has its own channel please feel free to join in too.
  2. Open-source space technologies and open-source projects are quite diverse, each following their own needs to provide solutions. Read the available documentation and don’t hesitate to reach out to the Zulip chat rooms for clarification and guidance.
  3. When you have a good understanding of the project and read this full ideas page, write your proposal.

2. Coding Ideas List

Okay, ready for lift-off, we are approaching our coding ideas for GSOC 2021. 
The following is our list of current tasks we offer you. Feel free to select one or more for your application. If you can not find one you like, we have always attached it to you. The Cometary Dust simulation for ESA in the next video what so proposed by a student.

And we have lift-off with headlines (full description below) …

AerospaceResearch.net and IFP

  • [gsoc21-a-cal1] CalibrateSDR: Add more input sources for calibrating an SDR
  • [gsoc21-a-sat1] SatSignals: Center of Satellite Signal(s) in the frequency domain
  • [gsoc21-a-od1] OrbitDeterminator: Improve Doppler Shift calculation and compare results from different satellite orbits
  • [gsoc21-a-od2] OrbitDeterminator: Find an efficient optimization strategy for solving an orbit determination with 7 unkown inputs
  • [gsoc21-a-sat2] SatSignals: Auto-calibration of frequency-offset of satellites in orbit

ep2lab @ UC3M

  • [gsoc21-e-cb1] Implementation of sensor and actuator models in Cubesat Simulator
  • [gsoc21-e-cb2] Enhance visualization tool for Cubesat Simulator
  • [gsoc21-s-ha2]  Visualization tool of Halo manifolds in the Circular Restricted Three Body Problem.
  • [gsoc21-s-op1] Improvement of web api for automatic design of interplanetary missions using MOLTO-IT
  • [gsoc21-e-op2] Generation of a library of real missions using MOLTO-IT

Misc

3. Coding Ideas Full Description

We are fully aware that GSOC changed a bit compared to the last years. Now, it has smaller project sizes (all students participating in the 2021 program will be working on a 175 hour project instead of the previous standard of 350 hrs project) and a shortened coding period (the coding period will be 10 weeks with a lot more flexibility for the mentor and student to decide together how they want to spread the work out over the summer). For the following ideas we had this in mind. If you think otherwise, please give us feedback during the community phase. That will help us and we can decide together where to tweak it a bit.

It is ALWAYS a working together!

AerospaceResearch.net and IFP

[gsoc21-a-cal1] CalibrateSDR: Add more input sources for calibrating an SDR

Software Defined Radio receivers use local oscilators for tuning on the demanded frequency. The oscilator itself is influenced by heat and other factors and the stability of the oscilating frequency can vary, and that also means the tuned freuquency will vary. To know this frequency drift, a reference signal is used that the SDR receiver is tuning on. Then the reference and the measured signal is compared and the drift is know. For simple receivers, this is in the range of +-100PPM, and that means depending on the frequency of interest, you miss the frequency at all. For NOAA satellites, that are transmitting on 137.5 MHz, that is an offset of 100 * 137.5 Hz and almost outside the NOAA satellites 15 KHz bandwidth where they send.

The CalibrateSDR tool is helping there. Currently it uses the known DAB+ radio channel frequencies and can precisely calculate the frequency error. But unforturnately DAB+ is mainly used in Europe, so it will be your task to add more reference input sources. This will not just help our projects, but everyone on the SDR community.

We are interested in these signals, and you can also suggest signals from your local area and interest:

Expected Outcome: You will select the NOAA Weather Services (NWS) and at least one other input source from the above list and add this to CalibrateSDR. NWS is rather idea and will help you understand why Calibration is essential. The othere source(s) of your choices are then to add new features and allow Calibrate to be used not just in EU and the US. Keep in mind this is using the different features of the signals‘ standards. This is not just a „frequency measuring“ task. For DVB-T, you will use their synch pulses within the data. Part of this is to document, with respect to explain the code but also to explain scientifically how you solved this. Read this how we used DAB+ for CalibrateSDR and similarly we want to see for the other inputs.

Mentor: A. Hornig, Kai Wilke

Code Difficulty: Python-medium, but you should have knowledge of the standards!

Chat with us: All questions about it here in our #CalibrateSDR zulip stream

Source: https://github.com/aerospaceresearch/CalibrateSDR

[gsoc21-a-sat1] SatSignals: Center of Satellite Signal(s) in the frequency domain

Satellite’s are transmitting data back to earth via radio frequencies (and soon optically). Each satellite has their transmitting way/method. There are several standards how the signal needs to be modulated and when watched on a waterfall diagram (in the frequency domain), you can most often obviously see by the shape of the signal which standard was used.

This characteristic we want to exploit and use to find the center of the signal at each time step in the frequency domain. This will be helpful for our Org’s effort to detect and track signals by their dopplershift pattern. For that we need the precise center of a signal for each time step in the waterfall. These single centers together form the dopplershift pattern. But due to the different forms of signals this needs to be done for each signal modulation method.

  • APT = NOAA
  • APRS = ISS
  • B/QPSK = Meteor
  • you select…

Expected Outcome: You select one of the listed signals in addition to NOAA. With NOAA you will start to understand the problem and test your first algorithm. NOAA is a relatively simple pattern and the advantage is it is continously send, so you will have a lot of signals. After this, you will detect on the selected signal and also check. You will check your dopplershift patterns with that of the satellite. You will check with orbital data (TLEs) what pattern was expected and compare it with your. If you are faster with this, you can also extend to further signals or check with a related GSOC21 project.

Mentor: A. Hornig, Kai Wilke

Code Difficulty: Python-medium, DSP-medium

Chat with us: All questions about it here in our #OrbitDeterminator zulip stream

Source: Signal Wiki

[gsoc21-a-od1] OrbitDeterminator: Improve Doppler Shift calculation and compare results from different satellite orbits

In physic lessons we learn about doppler shift. About the apparent change of frequency depening on the relative movement of the transmitter with respect to the receiver. Most libraries in we used offered the strict geometric interpretation of it. This is good enough for close distances, like from LEO to the ground stations (about 400 to 2000 km). We can neglegt travelling time of the signal wave. We want to improve the implementation by adding the releativistic implementation and also by signal propagation.

So the idea is to implement the standard, the reletivisitic and the propagated simulation of the signal wave from distances such as:

  • LEO (400km)
  • MEO (20000km)
  • GEO (36000km)
  • Lunar (400000km)
  • Mars (it depends where it is ;))

Expected Outcome: You will implement the different proposed doppler shift calculations. You will compare the results from the given distances to see the error influences. And you will also use Two Line Elements (Orbit parameters from real satellites) and simulate runs of the satellite over a ground station and compare again during the simulated run.

Mentor: A. Hornig, Daniel Horwedel

Code Difficulty: Python-medium

Chat with us: All questions about it here in our #OrbitDeterminator zulip stream

Source: https://github.com/aerospaceresearch/orbitdeterminator

[gsoc21-a-od2] OrbitDeterminator: Find an efficient optimization strategy for solving an orbit determination with 7 unkown inputs

An orbit is defined by 6 parameters, the kepler parameters. With these you can describe the exact position of a satellite in its orbit. For each object in orbit, there is even a 7th one, because there is still remaining athmosphere or atomic gas particles (oxygen, nitrogen, etc…) that induces drag into the satellite and slow it down and finally let it re-enter and burn-up into earth lower and dense atmosphere. We need these 7 parameters to define these orbits idealized and compare it with measurement points of satellites while they were spotted during their real passages over the sky. For all of us who tried to solve such an equation with 7 unknowns this is very complex.

In this project, you will work under Andreas‘ mentorship to find an efficient optimization strategy. You can break down the task in sub tasks with subsets of the unkown paramaters. You can first solve only the paramters that define a circular orbit. That are 4 paramaters. This narrows down the solution space. After that the orbit is then modeled eliptically and not as a circle any more and so on and on.

Expected Result: Coding an easy to use and easy to configure code that uses EMCEE. Modelling the orbit with the 7 unknowns and compare it with the measured orbit.

Mentor: A. Hornig, Daniel Howedel

Chat with us: All questions about it here in our #OrbitDeterminator zulip stream

Code Difficulty: Python-medium

Source: https://github.com/aerospaceresearch/orbitdeterminator

[gsoc21-a-sat2] SatSignals: Auto-calibration of frequency-offset of satellites in orbit

Satellites transmit their signals via radio frequencies. These frequencies are often generated with a local oscillator on board the satellite. Due to external factors like heat or mechanical loads, or just due to the oscillator itself, it can have an offset in frequency with respect to the frequency it should have. In tests with NOAA satellites we saw offsets for NOAA-15 that was far-off the expected one and also not explainable with unknown orbits or the unprecise freqeuency in the receiver SDR.

That could mean that even though a satellite frequency is known (by its filling in the official ITU application) it can be a bit off. And we need this knowledge to better track these satellites by their doppler shift paterns.

Expected result: You will select 1 satellite that you are interested in. During GSOC, you will have written a redimentory scheduler for knowing when this satellite is above the given ground station. This is based on TLEs (Two Line Eleements). With this you will start a recording with a SDR receiver of this ground station (based on RTL-SDR or LimeMicro MINI). Andreas will provide knowledge of how to detect a signal in the received data and center it. You will implement it and will compare the received doppler shifted frequency with the doppler shift provided by the simulation (sgp4, skyview, pyepem) based on the TLE. At the end of the GSOC phase you shall have a few hours of results for your selected 1 satellite. If possible several satellites should be monitored with this. This is scalable depending on the difficulty of the project due to the signal centering algo and also the dopler shift calculation (see other projec ideas).

Mentor: Daniel Horwedel, Kai Wilke

Chat with us: All questions about it here in our #OrbitDeterminator zulip stream

Code Difficulty: Python-medium, DSP knowledge, Orbital Mechanics!

Source: https://github.com/aerospaceresearch/orbitdeterminator

ep2lab @ UC3M

[gsoc21-e-cb1] Implementation of sensor and actuator models in Cubesat Simulator & [gsoc21-e-cb2] Enhance visualization tool for Cubesat Simulator

Cubesat are now widespread as affordable tools for teaching and researching for Universities and Research Centers. Although they are simple platforms, their complexity can be increased in a budget. One of the elements that increase the capabilities of cubesats is the incorporation of an attitude (and orbit) control system (AOCS). Simulation of the capability of these subsystems is the first step to assess the convenience to include such subsystems in a platform. There is currently a simulator that is able to model the main dynamics of the orbit and attitude motion, that can be enhanced by the proposed ideas.

Expected Outcome: 

[gsoc21-e-cb1] Implementation of sensor models in Cubesat Simulator: currently the set of sensors for navigation and actuators for control is limited. It is planned to include multiple options to customize the cubesat and evaluate the control and navigation functions depending on the selected hardware. 

[gsoc21-e-cb2] Enhance visualization tool for Cubesat Simulator. There is currently the option to visualize the attitude of the cubesat in a limited way. Visualization can be improved including multiple views, some rendered figures, and other features.

Mentors: Manuel Sanjurjo Rivo, David Morante

Code difficulty: Matlab/Octave – medium

Chat with us: All questions about it here in our #ep2 zulip stream

Source: https://github.com/msanrivo/SmallSat_FDIR

[gsoc21-s-ha2]  Visualization tool of Halo manifolds in the Circular Restricted Three Body Problem.

The analysis of dynamical systems as the Circular Restricted Three Body Problem is of great use when designing missions to Lagrangian points of the Earth-Moon system or when searching for periodic orbits in cis-lunar space. The use of tools for computation of periodic orbits, assessment of their stability and the associated manifolds is mandatory in those missions. We have a tool able to perform these tasks but without visualization, which is also relevant for mission design purposes.

Expected Outcome: Development of a GUI for the tool. And incorporate visualization capabilities.

Mentors: Manuel Sanjurjo Rivo, David Morante

Chat with us: All questions about it here in our #ep2 zulip stream

Code difficulty: Matlab/Octave – medium

Source: https://github.com/uc3m-aerospace/MOLTO-3BP

[gsoc21-s-op1] Improvement of web api for automatic design of interplanetary missions using MOLTO-IT & [gsoc21-e-op2] Generation of a library of real missions using MOLTO-IT

The preliminary design of interplanetary missions with low-thrust engines is a highly complex process. The mission designer must select the number of gravitational assists, the planets where they are carried out and, in some cases, the final destination. In addition, the law of guidance based on time is obtained as a solution to an optimization problem. Normally the evaluation of thousands or millions of possible trajectories is required, which can be very expensive in terms of human work hours. For all this, the department is developing the MOLTO-IT computer tool with the aim of solving the problem automatically.

Expected Outcome: [gsoc21-s-op1] Extension of current MOLTO-IT’s web api capabilities, including: change flow after creating a mission, so users are redirected to the page where a code needs to be added; implementation of styled components and theme, improve performance of the website; implement actions, reducers, and constants using redux-toolkit; normalize reducers, one option is to use createEntityAdapter from redux-toolkit.

[gsoc21-s-op2] Development of tutorials for first-time users. Selection of real missions to be simulated using MOLTO-IT. Test the code and compare with the actual solution. Identify improvements in the dynamical model or optimisation process.

Mentors: Manuel Sanjurjo Rivo,  Brandon Escamilla, David Morante

Chat with us: All questions about it here in our #ep2 zulip stream

Code difficulty: Matlab/Octave – medium

Source: https://github.com/uc3m-aerospace/MOLTO-IT https://github.com/uc3m-aerospace/MOLTO-IT-UI https://github.com/uc3m-aerospace/MOLTO-IT-API

Misc

[gsoc21XX] Propose YOUR idea!

This is up to you! Propose your idea what you think we need and miss. Please contact us to discuss it beforehand. Also provide your expected results. Having working code would be beneficial!

Chat with us: All questions about it here in our #GSOC zulip stream

[XXXX21XX] Previously unused ideas of other coding campaigns

Click the link above to find previous ideas of previous coding campaigns. Please refer to their ideas code (in []).

Chat with us: All questions about it here in our #GSOC zulip stream

4. Info for Students:

Being accepted as a GSOC 2021 student is quite competitive. Accepted students typically have thoroughly researched the technologies of their proposed project and have been in frequent contact with potential mentors. Simply copying and pasting an idea here will not work. On the other hand, creating a completely new idea without first consulting potential mentors is unlikely to work out. But we encourage you to also submit and post your own ideas. Prepared and working code works best for our well-acceptance.

As a result of our last two participations in Google and ESA summer of code campaigns, we adapted our selection process. We now have a transparent application scheme where you see for what you get points. And you get points for what we expect of you. We tried to find a good compromise between the fundamental skills we want to see, and also give newcomers and space students a fair chance. And as you can see, there is also a way to surprise us with your creativity. We like to be convinced with working prototypes and good community interaction. Overall, we BELIEVE everyone can do that and we mentors will help you help yourself.

When you will ask us afterwards, we will also take time to discuss with you how you ranked. This could help you improve for next year’s GSOC.

If selected you are expected to:

  • Communicate with your mentor weekly or more often
  • Contribute during the community bonding period
  • Write blog posts about your work. Feel free to tweet/post about it!

Transparent Application Rating (New since 2016)

Please read the baseline and the optional parts of the pointing schemes. We are listing those points to help you successfully apply and not missing an obvious point. You can always do more, but please check those points. We will be fair, we promise. You can always ask us and we will help you.

BASELINE:

  • 5pts Communicated with us org mentors (via their emails below)?
  • 5pts Communicated with the community (via email list)?
  • 5pts Does your application contain a motivation letter? Tell us why you like us and our projects! And prove that you know who we are and what we do!  (1 page is okay)
  • 5pts Do you reference projects you coded WITH links to repos or provided code?
  • 5pts Do you provide all demanded ways of contact (email, skype, mobile/phone, and twitter, chat and/or tumblr if available)
  • 3pts Do you add a preliminary project plan (before, during, after GSOC)?
  • 3pts Do you state which project you are applying for and why you think you can do that?
  • 3pts Do you have time for GSOC? This is a paid job! State that you have time in your motivation letter, and list other commitments!
  • 1pts Only applied via the GSOC 2021 page (please don’t send it directly to us!)
  • 1pts Added a link to ALL your application files to a cloud hoster like github or dropbox? (easy points!  )
  • 0pts Be honest! Only universal Karma points. 
  • 5pts Did you do push code to the existing code? Or did a bugfix?

OPTIONAL:

  • 10pts Do you have an aerospace background and did you reference it in your application?
  • 15pts Wild space. Be creative, impress us! 
  • 5pts completed CV (1-2 pages optimal!)
  • 2pts If you select hardware related projects, do you have (access to) it?
?

Again, please try to get the maximum number of points! 

5. What else do we offer?

  • Awesome space projects
  • long term involvement
  • scientific papers with you as Co-Author for international conferences (video below)
  • letter of recommendation

6. #contact