Again for the 7th time, AerospaceResearch.net[0] is proud to be selected as an official mentoring organization for the Summer of Code 2021 (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 by Google, releasing scientific papers about their projects and supporting the open-source space community.
Until 13th ot April 2021, students can apply for an hands on experience with applied space programs. As an umbrella organisation, AerospaceResearch.net 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]
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,
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 time again for Hacktoberfest and we already took part in it with our projects and and in related projects. We will hack together, finish stuff for the GSOC projects and even some of us will take part in the virtual NASA SpaceApps Challenge. All of these open source projects can use your help. So you will do something good and also earn a brand new, limited hacktoberfest shirt!
Hi, my name is Brandon Escamilla, I am an Aerospace Engineer by Universidad Marista de Guadalajara (Guadalajara, México). This is the second time I got selected for the GSoC. I am really grateful for this opportunity. This time, I came along with a proposal to improve the actual MOLTO project. The same I did work the last year. MOLTO is a big project, which has tons of work before going to production. Last year, I worked in a way to connect MOLTO with a user interface, it was not an easy work since MOLTO is a Matlab tool which requires special connections and is not as easy as consuming a normal API, so I did create an API with Python/Flask to communicate my requests from the Frontend to Matlab directly. It did work, we did communicate successfully with the Matlab tool. But there were some problems we need to resolve in order to have a „production environment“. At the end of the GSoC, we had a UI created in React.js, an API using Flask, and a local database using SQLite. This was enough to prove the architecture I wrote in my proposal, easy architecture to get to the web those projects created in Matlab which can’t go to production because Matlab closed license.
So, here you have the new flow of MOLTO from a route-based perspective, and from a logical flow.
The main issues that needed to be solved before to go to production were the ones I will list below:
Error communication between Matlab and Python.
Delete Real-time communication between UI – Python – Matlab. (Sockets)
Create a new service based on Codes to retrieve the mission.
But there were also some improvements needed to be added with lower priority:
Friendly user interface for new users.
New Design
Create a database in production to save missions configuration and results.
Create an email service to send mission codes.
Create CMS to add information in an easy way for maintainers.
New view for the service based on codes.
Improve deployment of Frontend.
Response optimization from Matlab Genetic Algorithm.
Toy problem for new users.
Optimize responsive views of the site.
Improve Celery implementation for Background tasks.
Before continuing, I would like to add that after GSoC, I continued working on MOLTO, adding small features, and improving user experience as fas as I could. In our constant communication between my last mentor David and I, he did invite me to start a research stay in the University Carlos III where he was doing his Doctorate. This led to another experience where David has been my bachelor’s degree thesis advisor. (A good story thanks to GSoC! ?)
Hands-On!
Once accepted, I started working on my proposal which did look something like this:
For this purpose, I did use an open-source application called Strapi, which allows you to develop a CMS locally and in production in an easy way. It helps you to develop the database, API, endpoints, CDN requests, models, emails, and more…
I did install Strapi locally and started creating the services were needed for MOLTO which can be divided in this way:
Collaborators
Missions
Users
Email Service
Motors
Once I create all the services described before, I just started to launch the CMS to production. The easiest way to do this is using Heroku, which allows you to have an app in production with very few steps and configuration. Finally, you can find the Admin in this URL: https://molto-admin.herokuapp.com/admin, Of course, it has a login and just the maintainers of MOLTO can access. But I leave you a few screenshots, so you can see the interface.
I am using a PostgreSQL database which actually is a plugin from Heroku app. ✅
Before going to production we needed a new design because the first one was more like an MVP, finally, I added a link to the old site, the designs, and the newly implemented design. Almost all the components of the website did change, from the home to MOLTO-IT, and also new views were added.
Here I will leave you some screenshots of the old design and the new design. (I will include the links in case you want to check it out )
Another new feature is in the motors section of MOLTO-IT, where you can actually see the motor configuration clicking in more information.
Another feature is the mobile version of MOLTO and the new menu, at this moment is really important to have a good mobile version of websites, since most users will visit your site from their cellphones. So, I did refactor the mobile version and right now is good to work from cellphones.
3. Tour MOLTO
In order to have a better experience in MOLTO, I did try a lot of ways to do it. I started using a library called React tour, and after another one called React joyride, but I did notice that those were very intrusive with the user experience and that actually the performance of the application was really bad when using both libraries. So I did prefer to create my own component which shows an information icon and if you hover on desktop or click it in mobile, display a box with useful information in order to know what to add in the inputs or what are the inputs for.
I found this way less intrusive and useful in my opinion. Here you have one screenshot of this component.
4. New service for creating a mission or search for a mission created.
One of the requirements of the last year was to create a UI with the possibility to see how the genetic algorithm evolves in the time. This was possible, but also a bad idea from a user perspective. Once they select their configuration, they needed to be waiting for the response of the API, this time could go from 3 minutes to 10 minutes – more generations, more population, more time-, which is the time Matlab started the genetic algorithm, in this point Flask opened a socket to start consuming the files were being created in real-time in a directory of the server where MOLTO lives. This was working well but just in one situation: A mission with really low generations and population, since this kind of missions will return results fast. So, once you started a mission with more than 30 generations and more than 50 population, you needed to wait a lot of time before the sockets could return the first generation, and this leads to another problem if the user wanted to see the final generation, the user needed to wait from minutes to hours, without closing the browsers – once you closed the browser, the socket connection finished-. So in the meantime between GSoC and GSoC, I created a new architecture based on codes where you create your mission and the website returns you a code, and also the possibility to send the code to your email, so you could return, in 1 hour, 1 day or 1 week, and all your results will be there stored in the database. Of course, this was a lot of work, I need to almost change most of the logical code was created to connect with Python via sockets. And also new views needed to be created to retrieve the mission, send the code to email, etc.
Almost in the middle of the second evaluation I start working on this, and after days of coding, the new service was available, here I will add few screenshots, but of course, you could to the MOLTO website.
The view which looks for missions, has an input where you need to put the code MOLTO gives you when you finished the configuration of your mission, this input has the ability to detect invalid codes, and also returns the current status of the mission. This is thanks to Celery, which is a tool that before was just running tasks in the background, but with the proper configuration, you can check the status of the mission in real-time. ?
4. Celery and Matlab Errors
As I said at the top of this post, one big problem was that I had issues trying to connect Matlab errors with python, due to this once a mission failed, I didn’t know the real reason why it was failing. At the start, it was not a problem, because I was using always the same JSON for creating missions and testing. But once you put different configurations, it was randomly working, sometimes it works, sometimes it just crashes, and I didn’t know what was happening. So, this year, I decided to solve this issue, as said before, using Celery properly, and also the Matlab Engine For Python.
The big issue was that I was not adding some configurations to check the tasks in the UI of Celery called flower, and I was also not using some configuration to read logs from Matlab in python, It was a hard task, but finally, it is working, so I will put here one screenshot of the logs I am receiving in the server where I can know exactly why Matlab is not working.
I can also see all the missions in real-time in a dashboard, all the missions that failed, all the successful missions, and also the tasks that are running.
5. New host for Frontend
There are a lot of ways to host your frontend applications, we can host our frontend in the MOLTO server, or maybe in another service like AWS, etc. But I recently started using Vercel to host other projects, and it was a great experience since you can have multiple environments for testing, production, development, etc. All of this in one place, connected to your repository in Github or to your CLI. It makes easier the development and that’s why it is the platform MOLTO will be using for frontend hosting.
We have right now two environments dev, and production, all the changes that will be applied to the UI of MOLTO will pass first by dev, after approval all these changes could be applied to production.
6. Toy problem
One problem I faced when I was demonstrating MOLTO was that I was the only person who knows how to use it. That was a problem because you can’t deploy an application to production if it is not intuitive.
In order to improve this situation, I used the based architecture of data management called Redux to pre-load a problem, so every time you enter to MOLTO-IT you can change just the name and go to the last tab, click send, and here you have a useful mission, from Earth to Jupyter. So you can test this mission, and actually see the Pareto front without any problem.
7. New flow with code – Pareto Front
I’ve been talking about the new flow but I didn’t show you how it looks after you put a code that has a finished state. Well, actually, this view has some improvements also.
The first one is that you are able to see all the results from generation 1 to the last generation with its respective results. So you can test any value to plot the orbit. You can also see in real-time how the chart changes once you select another Pareto point.
Conclusion
It was an honor to work again in the Google Summer of Code 2020, finally, I would say I finished what I proposed at the start of this project. I also want to thank all the persons who make this possible, Dr. Manuel Sanjurjo, Dr. David Morante for guiding me, and helping me every time I have issues or problems to resolve. I also want to thank you for the research stay at UC3M, I hope I can continue working along with both in this and other projects.
I also want to thank Andreas Hornig for being there for any question and always provide the necessary stuff to keep working. Also for always remember me the deadlines ?, and pushing me to give the best of me.
As far as I know, this is the last GSoC in which I can contribute as a student ☹️, but my next goal is to keep contributing to open-source and why not contribute also as a mentor if possible in the next GSoC’s. I would really like to share all that I’ve learned during these 2 years. ?
With increasing popularity in CubeSat technologies, it has gotten ever so important to have low-cost systems that complement the economical and self-reliant nature of today’s cubesats providers. One of the most important parts of an end to end small satellite business is ground-based tracking. Satellite tracking provides valuable information on the whereabouts. Satellite tracking industry is booming with the use of large antennas and high power transmitters at cost-prohibitive nature but at the cost of expense and lead time.
It is thus important to use an alternative tracking method, for example, Doppler Tracking. Doppler based orbit determination uses a doppler frequency shift to convert to a distance problem. To do doppler tracking, one has to first track the frequency of the signal. This way the cost of the tracking system is kept low because equipment needs beyond the essential receiver are small, at a minimum consisting of an amplifier and a variable oscillator. This project aims to provide a universal tracking solution for burst and continuous type signals of satellites.
Overview
This project aims to have a universal tracker for sporadic and continuous type signals. This requires the above workflow. Overall there are three main stages of processing before we arrive at our final track. Every stage has its own function and uses a particular algorithm.
Stage 1: Pre-Processing
Stage 2: Decision Making
Stage 3: Tracking
Waterfall
Before the pre-processing stage, it’s important that we have our signal in the frequency domain, by taking the Fourier Transform. So, the program performs the FFT in chunks to improve memory performance and runtime. It then selects the desired channels of a specific bandwidth, as per the user’s requirement.
Signal Detection
FFT Averaging
Before we make a decision, whether a certain FFT frame has the signal or not, we need to remove some consistent artefacts present throughout the duration of the recording.
The basic idea of averaging for spectral noise reduction is the same as arithmetic averaging to find a mean value. This operation is a type of low-pass filtering that can reduce high-frequency noise.
APRS signal example
Calculating an average spectrum involves averaging across common frequencies in multiple spectra. So we subtract an average spectral frame from the sample frame in question. This improves measurement accuracy and also helps to compensate for a low signal-to-noise ratio.
Decision
The decision of whether a signal exists in a given FFT frame is done by checking the neighbouring frequency bins of a sample bin (n) that all have bin magnitudes greater than that of a dynamic threshold.
an illustration of the decision making
This threshold is calculated as follows: Threshold = Mean + SD + safety gap
Black indicates selected bins
A NOAA signal’s full spectra; green(channel selected)
Tracking
Finding the center
Once the signal is found in a particular FFT frame, it is a matter of finding the centre of the geometric signal. To cover most signal types a generic approach has to be taken. This is why a spectral centroid is a good enough representation of the signal center. A spectral centroid analogous to geometric center and refers to the balance point of the signal.
x(n) represents the weighted frequency value, or magnitude, of bin number n, and f(n) represents the center frequency of that bin.
Track Smoothing
The frequency track of the signal through the recording is curve fitted with a polynomial function of order 3. It is also important to remove outliers before fitting the data.
NOAA Waterfall Signal Track (white-raw track, black-filtered track)
APRS Waterfall Signal Track – (white- raw track, black – fitted track)APRS Waterfall Signal Track (BW-10kHz) – (white- raw track, black – fitted track)
Outputs
The program can output spectral frame and waterfall plots of multi-channels and bandwidths specified by the user. The frequency track of the signal from the specified channels, when found, is finally stored in a JSON file.
In the end, I would like to thank AerospaceResearch for giving me the incredible opportunity to work with them in Google Summer of Code 2020. I have learned a great deal and this journey has solidified my belief in open source for space. I would also like to thank Andreas Hornig for being the mentor of this project and extending his guidance and support, whenever needed.
I am Ginés Salar, Aerospace Engineer by University Carlos III (Madrid, Spain). As this years‘ GSoC edition comes to an end, allow me an opportunity to give a comprehensive explanation of my contributions to aerospaceresearch.net. From my university’s department of aerospace research, there is an interest to develop and test preliminary trajectory optimizers. This has led, in recent years, to the development of MOLTO (Multi-Objective Low-Thrust Optimizer). Such a tool would provide a two-step optimization process for one in three scenarios conceived: IT (Inteplanetary Transfers), OR (Orbit Raising) and 3BP (Three Body Problem). In this post I will not go into the details of these engines but I strongly advice the interested reader to access [GSoC 19′ |UC3M ] MOLTO – Mission Designer.
My efforts try to improve upon the MOLTO-3BP, specifically the first step. The classical approach to this problem searches for a set of ballistic trajectories patched by instantaneous impulses. It is assumed that by reducing the fuel consumption of these impulses, the initial guess improves. After that, the engine moves to the second step and introduces the actual control optimization to adapt the orbit to a truly low-thrust mission. There is little knowledge about whether this procedure delivers the best result or merely a local minimum. Providing an answer to this question is what motivated the work done.
2. Work Breakdown
Parallel works by other students have attempted to provide a database with sampled non-keplerian periodic orbits. Initially, these efforts were aimed to replicate real missions, or to try to improve them using their objectives as a guide. The purpose of this database would be to propagate invariant manifolds from the orbits in order to find ballistic transfers that involve libration point orbits. Finally, the aforementioned patching process is carried out by selecting a suitable Poincaré section and analyzing the trajectories‘ intersections with this surface.
Under this environment, my main objectives were:
Generalize the capabilities of these functions.
Structure the code into a single body.
Translate the existing code to Python.
Emulate libration point orbits transfers.
Provide a new metric for the trajectories‘ suitability with a shape-based approach.
The first point, was to isolate all constants from the rest of the code and allow an easy access and control of the studied system. Furthermore, the most interesting libration points, due to the small Jacobi constant required to access their neighbourhood, are the collinear points L1 and L2. We decided that the program should extensively cover both points and the motions around them. This way, the basic building blocks used previously to compute Halo and Lyapunov orbits were extended to be applied to L1 and L2, and tested for the Sun + Earth & Moon system and the Earth + Moon system.
Simple Input & Output example
From that, it is important to remember that the purpose of these orbits is to propagate the disturbed trajectories that emanate from them. This promotes the idea of generating a common access point that joins orbit creation and manifold propagation, as well as, post-processing. On that line, I homogenized the input/output requirements of both orbit families and standardized the procedure to any future orbit family. The idea still holds for any non-periodic trajectory that in turn becomes relevant to propagate manifolds from. These steps were crutial to figure out as they are particularly relevant for an eventual integration of this code as part of MOLTO-3BP.
Another relevant point is that the original code requires a Matlab’s licence. This reduces drastically the code’s accessibility from any external sources. This could be easily avoided by converting the code into an open-source language with similar inner workings. The obvious candidate was using Python as it is also a high-level language with similar flexibility to Matlab’s. This change also introduces the possibility of using any of the many freely available modules, such as numpy, scipy, spiceypy and matplotlib. This way of proceeding not only reduces programming time, but also execution times. Additionally, the program can implement features not currently present in Matlab, like the explicit Runge-Kutta method of order 8 included in scipy’s suite. This allows for more precise computations for the most sensitive problems.
Manifold’s 3D plot for the study of L1 (left, black) to L2 (right, black) halo orbits. Unstable (exiting) trajectories in red. Stable (converging) trajectories in blue. Poincaré surface to register the intersections in yellow.
Following the reshaping of the code, several testing ideas and possible future developments arose. One of the most relevant was the concept of emulating complex sequential orbit transfers, both homoclinic and heteroclinic. The code was provided with the necessary tools to discriminate which manifolds where required by the process plus the ability to iterate both the orbit generation and the manifold propagation processes.
Phase-space representation at Poincaré section.
Finally, the end objective was to reach a better understanding of the suitability conditions in order to provide better decision metrics for future optimizers handling this problem. This section is still under development. The initial idea still remains: reduce the ballistic trajectories to their complex frequencies, compare them, and deduce a figure of merit, such as the delta-v required for jumping among them. Preliminary frequency analysis have been started on top of the tools developed, specially for the 2D simpler case. There are already some promising results but much testing is still required to be able to ensure good performance.
3. Acknowledgments
In order to conclude, I would like to thank Manuel Sanjurjo for his constant and agile support during this enterprise. Without his vision this process would not have been nearly as smooth. Also, I thank David Morante, responsible for the creation of MOLTO, for assisting along the way. On a similar note, I take this opportunity to mention Andreas Hornig, as a fine and efficient manager of the community. Everything has been perfectly clear right from the start. Last but not least, I thank Google for running this program and give this sort of opportunities to students like me, it has been a great experience!
My name is Robin Müller and I am an aerospace engineer doing my graduate studies at the University of Stuttgart (github: https://github.com/rmspacefish). I am also an active student in the small satellite society KSat, which is currently working on the cube sat project SOURCE. More information on this project can be read up on https://www.ksat-stuttgart.de/de/unsere-missionen/source/.
The domain of my work was embedded programming in C++. The most simple explanation of my work would be that I programmed the handler software for sensors and the on-board computer itself. The source code is located on the gitlab server of KSat (https://git.ksat-stuttgart.de/source/sourceobsw). The extensive README provides instructions how to make the Linux version of the software work and how to setup Eclipse properly to allow convenient microcontroller development. It should be noted that the device handlers were tested on a microcontroller with FreeRTOS as the operating system. It has been really fascinating to learn about different types of sensors and their interfaces. Of course, my work included more than just making a few sensors work with something like an Arduino.
A lot of work went into making microcontroller development as convenient as possible while also staying free and open-source. The used development environment is very much in the spirit of open-source: Eclipse was used as an IDE and the software for the target on-board computer is generated using the free ARM toolchain. The used framework is also open source and it is possible to compile the software for Linux as well (Microcontroller or Desktop). It is possible to integrate the functionalities of debugger probes like Segger J-Link (debugger probe not free unfortunately) or OpenOCD and the logging of a serial port into Eclipse. That way, the software can be developed without the need of various additional tools, which might not work on every OS (my personal philosophy: coding for microcontrollers should be (almost) as convenient as coding for Desktop applications). GNU Make is used as the build system for the software. A lot of work went into making the Makefiles readable to allow for easy tweaking. The project can be developed on Linux and on Windows, as long as the ARM toolchain is installed.
Fully integrated microcontroller development environment in Eclipse
I worked with a specific framework designed for small satellite missions called the Flight Software Framework (FSFW, public at https://egit.irs.uni-stuttgart.de/fsfw/fsfw). It was initially designed and created by the Institute of Space Systems (IRS) in Stuttgart for the mission Flying Laptop, which has been launched and is still operational. Using this framework saves a lot of work for small satellite mission software developers, for example by providing powerful abstraction layers for different operating systems, building blocks for common components like devices (sensors or other microcontrollers) and controllers (attitude or thermal controllers) and building blocks to enable telemetry and telecommand handling. Keeping the recent developments in space (New Space, Miniaturization, Cubesats..) in mind, there will propably be even more small satellites in the future and the need to shorten the development cycles for satellite software. The flight software framework is based on C++, which has become more common in the space sector recently. Still, a lot of (new) flight software is still based on C. A lot of the myths surrounding C++ in the context of embedded systems (code bloat, slow..) have been disproven and the language offers excellent tools to write safe code and to model the architecture of systems in the code, using the best capabilities of object oriented programming.
The device handlers I programmed are based on the FSFW template class DeviceHandlerBase. A template class (https://en.wikipedia.org/wiki/Template_method_pattern) takes care of a lot of generic code and expects the developer to implement abstract functions to model the unique device. There are certain common functions each (space) device handler needs:
1. Modes: Needed alter behaviour, for example some devices are off for certain satellite modes. 2. Health state: For example to perform restarts when necessary. 3. Commandability: It should be possible to command the device handler from Ground. The device should also be able to generate telemtry. 4. Communication Interface: The device needs to talk to the respective sensor or microcontroller, using a data bus like SPI or UART (e.g. RS232) 5. Power Switching: The device handler has to be able to turn a device off or on, using components of the power subsystem (EPS).
Implementing the template class properly is a lot more work than simply making the sensor work on something like a Raspberry Pi or an Arduino but there is a huge advantage of going through the work of implementing the template class. All of those important functions that were mentioned above are more or less taken care of, which avoids boilerplate code. It should be noted that the SOURCE project, which is only a 3U cubesat, contains 4 microcontrollers, two FPGAs and more than 40 sensors (well, 20+ of those are temperature sensor which use the same device handler of course..), so any way to save rewriting generic code is very convenient. Furthermore, the device handlers offer a powerful decoupling mechanism by moving the API calls to the used communication bus into a different class, which is passed to the device handler. The result is that the device handlers only include the logic to handle the devices while the task of calling communication drivers of the hardware is transferred to the communication interface. This is especially nice for devices which can communicate with mulitple communication buses or where the configuration of the used bus only differs slightly (other SPI slave select, different I2C address..).
In these difficult times, it is of course better to work for home. After procuring the hardware from the institute, there was the task of setting up the hardware. I focused on two device handlers in particular: The ThermalSensorHandler, which took care of handling a MAX31865 Resistance-to-Digial converter, which in turn was connected to a Pt1000 thermal resistor, and the GyroHandler which handled a BMG250 MEMS gyroscope. Both sensors were soldered on a housekeeping board engineering model (I’d like to thank Jens Polzin, who is designing this board!), which also contains sun sensors and SPI slave select expanders (decoders). The two following pictures show the set-up. The large board on the left is the AT91SAM9G20-EK development board, which has the same chip as the iOBC, which is the on-board computer of the SOURCE project.
General setup with the AT91SAM9G20-EK development board Housekeeping board prototype (engineering model) with various sensors
The sensors are generally read and configured by reading certain registers, according to the sensors‘ datasheet. The basic test for the gyro involved taking the housekeeping board (HKB) and rotating it in both directions around every the X, Y and Z axis (kind of like a model airplane). It was also validated that the sensor values show the correct sign when rotating around a certain axis. The basic test for the thermal sensor handler included verifying the approximated temperature (room temperature) and checking whether it rises to 30-31 °C when touching the PT1000 sensor with my fingers .
Both device handlers have a start-up sequence which involves configuring the sensor and putting it into a state to perform poll the sensor properly. To perform all the initialization and configuration steps sequentially, an internal state machine is used. The usage of this state machine can be seen throughout the device handler code. The sequence of the device initialization is specified in the doStartUp() abstract function implementation. The specification of the actual commands for start-up, mode transitions or shut-down sequences is specified in the function buildTransitionDeviceCommand() (for simple sensors, this will usually only include the start-up sequence). When the configuration is complete, the device enters the MODE_NORMAL or MODE_ON mode and is ready to poll data. The commands for this nominal operation mode are specified inbuildNormalDeviceCommand(). buildCommandFromCommand() is used to specify commands from external commands (for example, commands coming from ground or from another software component) but is also used by the other command building functions to avoid duplicate code. The functions scanForReply() and interpretDeviceReply() are used to analyse the sensor data and store it into the local datapool for either downlink operation as housekeeping data or for usage by other software components.
On a microcontroller, the print functions generally have to be redirected to a UART peripheral to be sent to the host computer for display. This is used for the AT91. A sample output is show, which shows the two sensors being polled regularly.
Eclipse internal serial console, showing debug output from the AT91
I also started to work on a CoreController component, which takes care of monitoring the on-board computer itself. As a first step, I also took all necessary steps to enable communication with the iOBC on-board computer in the clean room of the IRS in Stuttgart. The iOBC engineering model (EM), being a rather expensive piece of hardware which is only available once, will be installed in the clean room and later be integrated into the flatsat, which is one of the most important testing platforms for the satellites and basically includes all the satellites component on a table wired together for testing. Of course, going to the clean room each time just to develop software is a lot of hassle. Therefore, remote development was set-up and is possible via Eclipse and RemoteGDB.
On-board computer iOBC engineering model in the clean room
The core controller will take care of monitoring the supervisor, which in turn generates voltage and temperature values of the OBC. It will also take care of monitoring all running tasks. Readers unfamiliar with embedded programming and real-time operating systems propably still understand the concept of threads, which are used extensively on desktop systems. Even though the OBC only has one core, it is possible to perform apparent multitasking by using a scheduler, which is the core component of a real-time operating system (RTOS). The most common ones for space applications among others are FreeRTOS, RTEMS and Linux. The FSFW offers abstraction layers for all of them and FreeRTOS was chosen for SOURCE because the provided driver functions by the OBC manufacturer also use FreeRTOS. The Controller uses the FreeRTOS API to monitor the stack usage of programs, and generate general CPU statistics and downlink them (in CSV format).
Task stats when printed out in debug mode
Another important task of the core controller is the scrubbing of non-volatile memories on the on-board computer. Space is a hostile environment, and the strong radiation can cause bit flips in the memories, which is also called Single-Event-Upset (SEU). Therefore, a lot of space-grade hardware features advanced error control code (ECC) to correct those anomalies. The OBC of SOURCE does not feature hardware ECC, but it is possible to implement software ECC, for example by using the Hamming Code (https://en.wikipedia.org/wiki/Hamming_code), which is able to correct one bitflip recognize two bitflips per 256 bytes. The hamming code will be generated on ground and written (or uploaded) to the non-volatile memory. It will then be used to regularly check the binaries in the non-volatile memories for bitflips. This task, which is called scrubbing, will also be performed by the core controller.
The complexity of the software is quite high. A schematic of the software architecture was created with the graph software yEd to visualize it. This software schematic is the most useful document to show the software architecture in a brief format which is also accessible for other subsystem and stakeholders which are interested in the success of the project. It also exists in similar form to visualize the architecture of the whole system (in therms of hardware).
Software Schematic for the SOURCE On-Board computer
Again for the 6th time, AerospaceResearch.net[0] is proud to be selected as an official mentoring organization for the Summer of Code 2020 (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 31. March 2020, 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]
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!
It is time again for Hacktoberfest and we already took part in it with our projects and earned our free t-shirt already. We will hack together on our projects, finish stuff for the GSOC projects and some of th team will be in the US for the International Astronautical Congress (IAC2019) in Washinton DC. And even there, we will take part in NASA SpaceAppsDC and will collaboratively work on open-source projects and creat pull-requests earning us fame, respect and a new Tee.
The goal Hacktoberfest was and still is that everyone create 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. Hacktoberfest is from 1st to 31st of October 2019.
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!
During GSoC 2019, I worked on AerospaceResearch.net’s orbitdeterminator and orbitdeterminator-webapp project, the following is what I was able to add/test/modify to these exciting projects:
A custom perturbation module: Allows user to propagate orbital elements generated by gauss method in environments of different custom perturbations, incorporated SDP/SGP4 models and displays final co-ordinates and initial and final orbital elements.
Least square subroutines: Add support for non-equal weights in least-squares subroutines.
Conversion scripts: Added various functions helpful in orbit determination.
Parsing scripts and Inter-frame coordinate conversion, added support for all angle subformats in IOD data.
Field testing and validation with satobs community.
Comparison mode for web-app: Allows user to compare plots and results produced by various keplerian determination techniques.
Incorporated units, filters and keplerian determination techniques into the web-app.
Custom propagation module:
A script that allows the user to propagate keplerian elements generated by gauss method. Propagation module consists of environments for various natural and artificial perturbation accelerations. User can select ephemeris for sun orbiting bodies both while applying gauss method and while propagating. Options to select SGP4/SDP models for the propagation of earth orbiting satellites. User can change the values of various natural constants or use the default ones. Add option to use NASA NEO Webservice for (comets and asteroids) NEOs orbital data and add method for their propagation. Prints initial orbital elements and final (position, velocity) vectors and final orbital elements. Added support for all angle subformats in IOD format used by satobs.
More units, filters and keplerian determination techniques for web-app:
Added option to select Filters and Methods of Keplerian determination for determining the orbit.
User can now select from the following filters-
Savintzky Golay.
Triple moving average.
Both(Savintzky Golay and Triple moving average).
None (no filter).
User can now select the method of keplerian determination from the following-
Ellipse Fit.
Gibbs method.
Cubic Spline Interpolation.
Lamberts Kalman.
Comparison mode for web-app:
A script that allows the user to generate comparison plots for different filters/methods.
3-d animated plotting:
Better plots for simple visualization using matplotlib.
Conversion module:
Contains various conversion functions essential for further progress of this project.
2. Link to my GSoC 2019 project work:
The main part of the work I did is contained in the following modules:
Add support for radar delay/Doppler observations of Sun-orbiting bodies.
Add support for R.D.E. format data in orbit determinator.
Add support for all formats(IOD, RDE, UK) into the web-app.
Incorporate app.py and comparison_app.py into a single multi-page web-app.
Methods for coordinate conversion when slant range is not available.
Acknowledgment:
The success and final outcome of this project required a lot of guidance and assistance from my GSoC mentors(Arya, Aakash and Nilesh) and I am extremely privileged to have got this all along the completion of my project. All that I have done is only due to such supervision and assistance and I would not forget to thank them.
I owe my deep gratitude to Andreas Hornig(organization head), who took a keen interest in our project work and guided us all along. Also because of the system aerospaceresearch.net has developed over the years working for this organization gave me the freedom to expand my knowledge rather than just implementing stuff that I simply don’t understand.
We are almost in the deadline of GSoC, and I have been working in a project called MOLTO. I didn’t publish any blog until this moment since there has been a lot of work and I’ve been really busy. In this blog I will describe the whole process behind this project that has been changing since it begins.
It has been an amazing experience where I’ve learned a lot, I appreciate the time from my mentor David Morante who has been really involved during all the program. I would like to thank him for all the support. Thanks for giving me the opportunity of being part of this incredible program, all the knowledge I got from this is invaluable for me.
By the way, it’s time to talk about the project, it started with my application where they were asking for a student who could create or improve their user interface as well as do some improvements in the algorithm code. But before going away, I will explain in brief words what is MOLTO. At first, the application was for work in the MOLTO-IT project which is a branch of a bigger project called MOLTO. MOLTO is a mission designer created by David Morante for his doctoral thesis. He divided the project into three branches that I will describe below:
MOLTO-IT (Multi-Objective Low-Thrust Optimizer for Interplanetary Transfers): It is a fully automated Matlab tool for the preliminary design of low-thrust, multi-gravity assist trajectories.
MOLTO-OR(Multi-Objective Low-Thrust Optimizer for Orbit Raising): It is an application for the preliminary design of low-thrust transfer trajectories between Earth-centered orbits.
MOLTO-3BP (Multi-Objective Low-Thrust Optimizer for the Three Body Problem): is a fully automated Matlab tool for the preliminary design of low-thrust trajectories in the restricted three body problem.
My main proposal –was specifically for MOLTO-IT but at the end it changes– was about make a great UI without losing Matlab efficiency and without the need of re-build the code in another language. Since Matlab is very limited for UI purposes. I proposed to create an architecture that could enable the communication between Matlab and external applications, using their python engine through an API. That’s why my proposal is called MOLTO-IT As A Service (MaaS). I quote myself:
The objectives of this project are to find optimizations in MOLTO-IT trying to reach the best performance due to the hard numerical process that this project does and create an API using this Matlab module as a service where the users will send a POST request with the necessary inputs, and it will return the necessary information. Such as parameters of orbits, time, fuel consumed, or even graphs, etc. This will allow the team to create a better and more attractive graphical interface without losing the Matlab efficiency. Creating in this way, the possibility to use this service wherever you want such as mobile, web and desktop applications.
Image 1 – Architecture
Once we started talking about the project during the community bonding phase, we realized that we could improve the project thinking bigger and making some changes to the initial proposal. So we started thinking on work in MOLTO instead of only MOLTO-IT. Clearly, this new way to see the application changes some stuff such as primary design but the main goals will keep mostly the same.
Main Goals:
Extend capabilities of MOLTO-IT MOLTO.
Create API in selected programming language. (JS, Python)
If it is possible, create an MVP for MOLTO-IT MOLTO.
The proof of concept that I created for my application was some-kind different from how MOLTO looks right now. In the url below you can see my proof of concept of the API and UI during GSoC application:
And this one is the re-builded design after we started working on MOLTO. The flow was created in order to create a new mission in MOLTO-IT, so click start in MOLTO-IT button and just go through the flow:
As you can see there were some big changes, in my GSoC application I created a mobile application and I ended up creating a web application, but this iterative product development allow us to reach the main goal for MOLTO which was always to create an application available for anyone.
MOLTO IT
I will explain how MOLTO-IT works for avoid extra-explanations below, MOLTO-IT is the only one that right now is completely finished, MOLTO-OR and MOLTO-3BP are under development. We have been focused on making work this service, since OR and 3BP will work pretty the same.
MOLTO-IT is a fully automated Matlab tool for the preliminary design of low-thrust, multi-gravity assist trajectories. It means, it could allow us to know which is the best trajectory for interplanetary missions. Quoting its main goal:
The purpose of MOLTO-IT is to provide a fast and robust mission design environment that allows the user to quickly and inexpensively perform trade studies of various mission configurations and conduct low-fidelity analysis.
All of this is achieved through an outer loop that provides multi-objective optimization via a genetic algorithm (NSGA-II) with an inner loop that supplies gradient-based optimization (fmincon) of a shape-based low-thrust trajectory parameterization. At the end the mission designer will need to input a series of parameters, such as the spacecraft’s departure body, its final destination and some hardware characteristics (Launcher vehicle, mass, propulsion), as well as the range of launch dates, flight times and a list of available planets to flyby. The software tool then uses these data points to automatically compute the set of low-thrust trajectories, including the number, sequence and configuration of flybys that accomplish the mission most efficiently. Candidate trajectories are evaluated and compared in terms of total flight time and propellant mass consumed. This comparation is called pareto front and will look like this through the matlab plot:
Pareto front – matlab
After all the process is finished, we will be able to see the last generation which will contain the pareto points, every point is actually the best fit for the mission designer purpose, I mean if you want to go to mars and arrive in less than one year, you know that you will sacrifice most of your fuel, but if you are able to wait for a long travel such as 5 years, you will save up a lot of fuel. Whatever the point you select in the last generation, you could be confidence it is the most optimal solution. Btw, once you are in this part of the process you could select the most convenient pareto point for your mission and this will allow the tool to create the trajectory.
The trajectory is created by another functions that all they need is the mission configuration and the pareto point selected. After that you will be able to see the trajectory which will include everything a mission designer should know such as: Number of flybys, time, where to apply impulse, and more parameters, I attach an image below of how the plot looks like.
Dotted lines: No impulse Solid lines: Impulse
FIRST EVALUATION
All the process described before was during the phase of community bonding and maybe 1 week from first evaluation. During the first evaluation, I was mainly focused on the API since I need really double check everything will work. As you could imagine if something goes wrong with the communication between Matlab and the API, maybe anything could be possible.
The API was created within python language using flask, matlab engine for python, redis, celery, socket.io, and google drive (gspread). Why google drive? – It is something that I’ll talk about! –
The UI was created using React.js, Redux, socket.io client, recharts, and some other libraries. – Completely created using Hooks even for redux! –
During my regular meetings with David, we started thinking on what we’ll need to change in Matlab code in order to call the main function from the API. We quickly realized that we should change the main function in order to receive a json, at the end it was receiving an struct from an examples file. After that, a route was created in flask in order to receive the data from the UI, process it and finally send it to Matlab. The main purpose of using matlab python engine is that we could call Matlab functions within python, and the main function called „molto_it.m“ was the only one to call in order to trigger all the process. Until this point we were happy because everything was working like a charm. So I started working on the UI that finally looks some-kind different since I made some changes on-the-fly. We decided to implement an slider in the home page instead of the images, and implement a typer feature within the slider.
Dynamic component – Slider
Excel file – Sliders
As we were advancing in the UI, we also realize that it would be a problem if all the content were static -We also think about the possibility to implement a user architecture to enable users save their missions, we knew that a database was needed but we were just trying to avoid it at least for GSoC purposes, but thinking in that feature for the near feature-. There is where Google Drive appears at least temporally, I proposed a feature where all the content could come from an spreadsheet that would be located in google drive, so every-time that we want to make a change, it would be as easier as just enter to the spreadsheet and change the content. Similarly for the collaboration component that would be updating the collaborators every so often. At the end, I would like to clarify that this feature will change, this was made just for MVP purposes. So, I finished my first evaluation implementing this feature that actually work effectively. ??
At this point, we needed to worry about the Matlab’s response since the process it’s composed by two main tasks: The pareto front and the trajectory. The real problem was that both of them plot the results, based on the real-time data. So one of our options were just to send an image of the final plot or just find a way to send the data in real-time trough the API to the frontend. But there was another problem, once the process start it was returning the generations in real-time, which was a problem because the API was making a POST request which will wait for one response, so in this way we were just able to receive the first generation.
We were having problems due to the synchronous naturalness of python. In this case, the requirement was to being constantly sending data to the UI, at least every-time the software creates a new generation, in order to display the data in real-time in the UI. –Such a task!- I thought in the feasibility of using sockets for the communication, but it was tricky because I would need a trigger to let me know once the generation is finished. And obviously all of this should be parallel to the request. Talking with David, we agreed that the best way was creating a new file every time the generation was completed, so in this way I could create a socket that should be constantly looking for files in a temporal directory. So that’s what we did, every user that creates a mission, creates a temporal UUID that will add a temporal directory within the server, so the Matlab function will redirect all the created files to this directory. Once you have the first generation you will be able to see in real-time the plot directly in the UI. All the directories will be deleted within the same day at night.
Waiting for files in the temporal directory.
In that moment, we had almost all the first part to plot the pareto front, but in the UI we needed to catch all the data and save it in the correct way. We should be able to get the data in any moment, and this data should be available in almost the entire application. That’s why, I decided to use Redux. Redux is one of the best tools for data management if you using React, so I implemented the Redux architecture in order to handle all data from the API. At the end, the store looks like this.
Redux – Store
All the data come from a kind of form, where the user puts all the inputs in order to send the data to the API. This allows me to just send a POST request with all the data from the store, once the user finished all the flow, it also allows me to remember the selections of the user, so once you select something, you can go back and you will see that your selection is still there.
User flow – Form mission
FINAL EVALUATION
In the final evaluation we were trying to finish minor details such as design details. for example, we have been testing all the application using a dropdown where we need to select planets, but of course there should be a better way to do this. So, that was one of the big new features where I could work. So, I used a library to display the planets in a cool way. You already saw the planets feature in the gif’s that I put before, but I will leave here a static image of the feature.
Planets component
Of course, It was not all. In that point, we could plot the pareto front, but the last part requires to plot the trajectory, due to the times, we chose to just display the trajectory plot from Matlab in the UI, at least for GSoC purposes. ¿How we did it? As I explained before, once you get the final pareto front the user can select one point, the optimal point for your mission in terms of mass and time. So we call the API again at same route but this time with a flag. This flag means that you have the point of the pareto front that fits into your mission design, so Matlab function is enabled to detect it and just create the trajectory instead of call the genetic algorithm. Something cool is that you could go back and select another pareto point, and just call the API again. This will create the trajectory for the new selected point. It allows the users to iterate between different configurations for the same mission almost instantly. Btw, it finally looks like this – is the last view where you could share or download your preliminary results of your mission or create a new one.
Trajectory Plot
The last feature that I implemented is related to something we saw in the second evaluation. As you know python works synchronous and every task will be lineal. And also as you know until this point, every request will long as much as the number of generations the user request. So if the user request a genetic algorithm using 200 generations, the server will be busy a lot of time. The problem remains in the fact that if 3 users design a mission at the same time, they will probably have some issues because 2 of them will wait more than the normal request. So in order to avoid this issue, I started using threads, and parallel tasks. How I did it? Using celery, redis, and eventlet. This allow me to manage many requests and start them in the background. So the server is always available for new users without affecting the running times. ?
Initial Configuration MOLTO-IT – The only difference between easy or advance is how many configurations the user could edit. For GSoC purposes, we just worked in the easy one.
Celery is an asynchronous task queue/job queue based on distributed message passing. It is focused on real-time operation, but supports scheduling as well. The execution units, called tasks, are executed concurrently on a single or more worker servers using multiprocessing, Eventlet.
Eventlet is a concurrent networking library for Python that allows you to change how you run your code, not how you write it.
Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker.
Something cool that could be a new feature, is the fact that if the user remember the UUID that it creates within the mission. I mean if you could send it to the user through email, they could create the mission, go to take lunch or wathever, come back and put the UUID and the application will find the created directory, and will display the final plots in just seconds! —- This is possible thanks to the sockets we use to search for files and directories –
I would like to say that there are a lot of features that I didn’t take in count for this blog, just for become it short, since there is a lot of information. I just went through the most important features. But if you have some questions due to other component or something else. Please don’t hesitate in let me know. One last thing, the last month, we had some problems with the servers, that’s why there is no production application now, hopefully on monday 26 august, everything will work again, and then I will push the application to production. Once it works, I will edit this post in order to share it. Right now, everything is working under development.
What’s next?
As I wrote before, there are some TO-DO’s, where I will be working the rest of the year. We are open if anyone wants to contribute to this project.
1.- Create and implement architecture for save users and missions. (mongoDB)
2.- Send email with UUID, so the users could come back after they create the mission.
2.- CMS for sliders and collaborators.
3.- Improve responsive application.
Repositories:
You will find the documentation of every project within the readme.
