Implementation of data analysis compilation interface in a satellite monitoring simulator

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.

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

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: