What is a cubesat?

It consists of a modular cube of 10x10x10 cm with a mass of 1.33 kg, which is known as 1-unit (1U) CubeSat.

Cubesats were created to provide a low-cost, flexible and quick-build alternative to reach the space, in a few words a cubesat is a satellite with a cubic form.

Cubesat are now affordable tools for teaching and researching for Universities and Research Centers. Although they are simple platforms, their complexity can be increased. Simulation of the capability of these subsystems is the first step to assess the convenience to include such subsystems in a platform. In this case, Implementation of sensor and actuator models in a CubeSat Simulator and visualization.

Software and hardware specifications and parameters:

The parameters were selected by Javier Sanz Lobo in his master thesis “ Design of a Failure Detection Isolation and Recovery System for Cubesats“

LEO ( Low earth orbit) was selected by its highly demanding orbit maintenance and pointing accuracy. The satellite selected to perform is a 2U CubeSat.
Therefore, its size is 10x20x10 cm, and it weights 2.66 kg. The image illustrates the relative position of the main elements with respect to the body axis, the Earth and the orbit motion. The propulsion system was placed in the opposite face to the orbit motion to counteract the drag and the optical payload pointing to nadir(a selected face to always be syncronized to Earth).

Example proposed in master thesis:

Internally and intrinsically how does the software work?

Attitude and Orbital Control System Elements included for calculations summary

• 1.Control
  • 1.1 Attitude control
    • 1.1.1 Attitude controller, magnertorquer, reaction wheel allocation, reaction wheel controller and reaction wheel model.
  • 1.2 Orbit Controll
    • 1.2.1 Thruster allocation, orbit controller and thruster model
• 2. Dynamics
  • 2.1 Six degree of freedom model: attitude dynamics and kinematics(with quaternions evolution)
  • 2.2 Environment
    • 2.2.1 Atmospheric drag, gravity gradient torque, J2 perturbation, magnetic torque and third body perturbation
  • 2.3 Keplerian Orbit: Vectors normalizations
• 3. FDIR: with frozen and/or sudden death signals included if desired
  • 3.1Gyroscopes FDIR (Control panel included)
  • 3.2 Reaction Wheels FDIR (Control panel included)
  • 3.3 Thrusters FDIR (Control panel included)
• 4. Guidance
  • 4.1 Directions cosine matrix to quaternions (positive and negative traces included)
• 5. Navigation: Sensors and actuators included.
  • 5.1 Attitude Filter, GNSS, Gyroscope, Orbit Filter, and startracker
• 6. Visualization: 3D orbit, groundtrack and COE

Interface created with improved and modifiables 3D models:

Input data:

Output interface results:

Expected Visualization Results:

Orbit plot

Desired Orbit Plot

Download code:

https://github.com/msanrivo/SmallSat_FDIR/pull/4/commits

https://summerofcode.withgoogle.com/projects/?sp-search=R.David%20A#4750821465522176

Google summer of code journey and experience:

It was one of the best experiences I have had, talking and working with leaders in the technology, computer and aerospace industry has given me a lot of feedback. Let’s start from the beginning, I do not remember how I found the call by chance scrolling on the internet in leisure time, it caught my attention a lot, but I thought it would be very difficult to enter, then I saw that there were only two days left to apply to what I put my hands on the work, I took a bit of each project that I had already worked on and uploaded my proposal, a few weeks later I realized that it had been accepted and I was inside, I couldn’t believe it since it was a very hasty proposal.

The person in charge of aerospaceresearch contacted us in the following days, always very kind and cordial, when he invited us to the zulip group, I realized that there were many applicants with incredible ideas who have planned their projects months in advance and failed to enter, that was what made me think it would be even more difficult than I thought, but I was up for the challenge.

We started working and the weeks went by while I was still at the university, sometimes I didn’t have time for anything since I had to do a lot of research for what we would implement in the gsoc.

Initially the idea and what I was selected for was to implement sensors and actuators in a software for cubesat, which would be my surprise that the final turn was completely different, we went through that idea to a virtual reality simulator for the results of the software, weeks passed and I began to make the models, it was very difficult since I had never entered this area, nor had I ever used Matlab, after several meetings, we realized that it would not be the best implementation to the software, since if it counted with a display environment, although simple, useful. Finally, and after several ideas, the end was to create an interface, an application, user-friendly software to use the program in Matlab, since its use was really complex, even for certain experienced aerospace engineers, the thesis had to be read and spend several days to understand how the software worked and how to edit it, how to edit the input data.

Within the program, there were several files in Matlab and others in simulink, approximately 80 in total, with editable and non-editable data, it was a huge challenge.

There were many preliminary ideas of how the interface would be, what would be modifiable and how it would be done without affecting the code, initially with physical properties of the cubesat, dynamic properties of the orbit, among others; the approach was good, but after making all this data editable, Matlab flagged hundreds of errors, we had a good idea but we weren’t executing it in the best way, instead of letting the user modify the mass at desired, we agreed on do it in cubesat units from 1 to 27, since to control the centers of mass it has to be geometrically distributed and it cannot be a random mass, I did not know that until my expert mentor on the subject told me about it. After that, there were many problems about the execution of data that did not enter the workspace correctly, they entered as strings instead of arrays, horizontal instead of vertical. The biggest challenge was always to send the data and return it, without the software marking an error, the part of displaying the results was the last challenge, since it was necessary to activate and deactivate blocks in simulink, for which many had to be created iterative cycles with codes.

Summary improvements:

The work achieved in the GSOC was brutal, with incredible results, the graphic interface was a success, and from a complex program that only the creator understood, an interface was achieved that would allow the user to edit the data and apply it to different scenarios that they may interest you or arise in their trajectories, the application runs directly from the app designer and you do not have to guess which files you have to preload for it to work, there is also the part of default data that allows you to see how the pre-established case is and understand how it works. Enter the data, now, you do not have to enter to edit or Matlab or simulink to comment, uncomment, edit, and change everything, everything is executed only from the app designer, allowing the user to create an infinite number of cases and applications than before, they could not and adjust it to any needs.

Future work:

Perfection is never achieved, there are always things that can be improved, in this case, there are still certain limitations not only in the base software but in the interface created, one of them is to export all the code to an application or open source code, so that it is open to all public and not only for people with a Matlab license. Also to this, one of the limitations is that when running the program, there are certain data in the simulink that are saved and the second time when using it, in order to erase these data from the previous execution, they have to be erased only by closing and opening the simulink file, which can be a bit tedious, in the Matlab workspace part this is solved. Another limitation is that you have to have the simulink file open to be able to run the app, although you should not edit anything to the simulink, just have it open. Finally, the interface with the user can always be improved, with the passage of time and the comments that are received, I will be able to improve the order of the interface to make it even easier to use.

Roadmap:

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]
• ep2lab of Carlos III University of Madrid[2]
• or your very own proposal![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!

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,

Andreas Hornig, Head of Platform

[0] https://aerospaceresearch.net/?page_id=2156
[1] https://summerofcode.withgoogle.com
[2] https://aerospaceresearch.net/?page_id=2156#codingideas
[3] http://ksat-stuttgart.de
[4] https://www.youtube.com/watch?v=TC4Ls3AGHf4
[5] https://www.youtube.com/watch?v=FY0vjbBp4eg
[6] https://www.youtube.com/watch?v=gkklxZxjT-8&list=PL-lXf3kTWgqybFL-VOmVxKyjnrVPE7DBB

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!

Introduction

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.

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.

This threshold is calculated as follows:
Threshold = Mean + SD + safety gap

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.

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.

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. 

Acknowledgement 

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.

Links

• Github Repo
• Google Docs

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.

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.

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.

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.

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).

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).

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]
• ep2lab of Carlos III University of Madrid[2]
• or your very own proposal![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!

Introduction:

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:

1. 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.
2. Least square subroutines: Add support for non-equal weights in least-squares subroutines.
3. Conversion scripts: Added various functions helpful in orbit determination.
4. Parsing scripts and Inter-frame coordinate conversion, added support for all angle subformats in IOD data.
5. Field testing and validation with satobs community.
6. Comparison mode for web-app: Allows user to compare plots and results produced by various keplerian determination techniques.
7. 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-

1. Savintzky Golay.
2. Triple moving average.
3. Both(Savintzky Golay and Triple moving average).
4. None (no filter).

User can now select the method of keplerian determination from the following-

1. Ellipse Fit.
2. Gibbs method.
3. Cubic Spline Interpolation.
4. 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:

• orbitdeterminator/kep_determination/custom_prop.py
• orbitdeterminator/kep_determination/least_squares.py
• orbitdeterminator/util/conversion_module.py
• orbitdeterminator/kep_determination/satobs.py
• orbitdeterminator/kep_determination/gauss_method.py
• orbitdeterminator-webapp/app.py
• orbitdeterminator-webapp/comparison_app.py

The work I did during GSoC is here: 

Orbitdeterminator:

https://github.com/aerospaceresearch/orbitdeterminator/pull/177

https://github.com/aerospaceresearch/orbitdeterminator/pull/168

Orbitdeterminator-webapp:

https://github.com/aerospaceresearch/orbitdeterminator-webapp/commits/master

TODOS:

1. Refining custom perturbation module.
2. Add support for radar delay/Doppler observations of Sun-orbiting bodies.
3. Add support for R.D.E. format data in orbit determinator.
4. Add support for all formats(IOD, RDE, UK) into the web-app.
5. Incorporate app.py and comparison_app.py into a single multi-page web-app.
6. 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.

Contact me at:

• https://twitter.com/rakshitbhatt183
• https://github.com/rak183 
• rakshit.bhatt@aerospaceresearch.net
• https://www.linkedin.com/in/rakshit-bhatt-27aaa5148/