Thesis

I'm back with a quick update!

I have been sidetracked from the GUI for the time being with my thesis project, which will eventually turn into the Asteroid/Comet Toolbox along with the other asteroid functions I have made.

As of now, nothing has been coded yet. However, the method is set and the math is almost all mathed out.

Comet 67P Churyumov-Gerasimenko

There will be functions for:

• A new gravity model 
• The point mass model does not work for convex structures such as 67P seen above)
• Radiation pressure and emissivity
• Model of comet off-gassing
• Composition matrix
• Volatilizes sublimate and have set constants/parameters
• Change in orbital elements and rotation due to SRP and off-gassing
• In attempt to analyze the yarkovsky effect
• Trajectory of off-gassed elements
• If they will impact an orbiting object
• Ability to predict a tail
• Would need to include ionization model

Lucky for me, ESA currently has the Rosetta spacecraft in orbit about the comet 67P Churyumov-Gerasimenko (seen above) and the oort-cloud comet, Sliding Spring, is making a close approach to Mars in the upcoming week. I plan on using data from these missions to validate my model.

Rockets

I decided to finish the rocket editing before going on to create the tool boxes. It is similar to the previous post on rockets (found here).

I have created a video (a friend pointed me in the right direction for free video capture software) to show how the rockets are created and edited. 

How it works: 

     The user names the rocket and indicates the number of stages and parallel thrusters (0 assumes no parallel stage). Then, a preset rocket program is used to give an editable initial rocket. All physical characteristics are able to be edited, including but not limited to: masses, dimensions, specific impulse, and mass flow rate. 

By clicking update, the structure containing the object is updated and then plotted again with any changes. The masses and total deltaV are also refreshed. 

Next on my list of things to tackle is the impulsive trajectory solver.

And the world keeps spinning

So I was trying to make a stand alone movie capture and snapshot program before I posted this. I was successful in making the snapshot, however the movie poses problems when two while loops had to run simultaneously and MatLab is single thread (I do not have the parallel toolbox). It has a fix but it would take time that I am not willing to currently put into it. Maybe one day once the tools are done or I get a strike of inspiration I will do it. Regardless, here is a quick snapshot-ed image of the Earth. If you want you are able to change the rectangle of screen capture.

Round

The reason I wanted the movie capture program was to make it so I would not have to capture the following section on my phone (I don't know of any good free screen recording software). But anyway, here it goes.

As you can see from the new play, pause, rewind buttons in the above image, it has the the ability to (of course) play, pause, and rewind any plot pictured in the axis with a time step set by the user. The planets spin with their actual angular velocity and are also able to be viewed with satellites orbiting about them as well as orbiting the sun.

Earth spinning with multiple satellites orbiting. There is a 10 minute (600 second) time step between steps.

Mercury, Venus, Earth, Mars, and the asteroid Itokowa orbiting the sun with a ~2.8 day step.

Unfortunately, the buttons work in a while loop so I cannot make a video of them without including the capture code in the same loop.


Time to start working on the tools. I think I may have to write them as "plugins" to avoid the need to edit the structure of some of the other functions.

SpaceSim (GUI) 1.0

So here is the framework of the GUI. If there is any feedback, I would love to hear it. Remember, I am an engineer, not a computer scientist. For now, I have not compiled it to an .exe file and MatLab must be installed to use it.

So starting from the get-go: the main file is run from anywhere, it get's its current location and makes that, and all internal folders, part of the path. From there, the GUI is opened and populated. I will explain what each part of the figure does, then show examples of the capabilities.

Initial start-up figure of SpaceSim.

Starting from the top: 

File menu: Allows the user to save, load, or exit the GUI. The save option saves the current structure of objects, as well as any populated tools, which can then be loaded for future use/analysis. 

Edit Menu: Right now this is only a placeholder, I do not have any editable program properties yet (except for the objects, but I will get to that).

Add Object: Menu to add an object to the object list. The current addable objects are planet, rocket, asteroid, and satellite. I will speak about each of these objects in further detail in a later section.

Tools: While I have not implemented any of these into the GUI (YET!), they will consist of (but are not limited to):  an orbit simulator / impulsive and finite transfer optimizer for multiple or single central bodies (including asteroids), design and launch of a rocket, a Walker Constellation tool along with analysis abilities such as access times with constraints, and a mission design tool which splices together the other tools to create a rocket to launch a satellite to a defined orbit where further analysis can be done.

Help: A user manual which I am writing as I go along.

Toolbar Menu: I have included the generic MatLab figure toolbar since it contains all the functions I need. Until a time when I can create my own toolbar or map zooming/rotating to keys I will leave it as this, since I have more important things to do.

Time: The time is taken at the start of opening the program. This time can be edited, as long as it stays in a form which MatLab can read. To view the bodies at a different time, the plots must be updated manually.

View Dropdown Menu: Lists all the current bodies as well as an option for "Orbit", which allows the user to choose from the Earth and Sun (will eventually be every planetary body object) and takes every object whose "parent" is one of those two and allows the user to check boxes and view their orbits about the main body. 

Current bodies moving about the central body, the Sun. 

A picture of the orbits of these planets at the date indicated on the top right assuming the initial orbits are from January 1, 2000 and extrapolated to their current position via. Kepler's equations (which is when the planet data is from, but this will change in the future). The planets are currently not listed, but there will be text right next to the dot saying which planet it is. Planet Awesome = Yellow, Earth = Green, Jupiter = Blue.

Axes: Displays whatever is prompted to by the view dropdown menu. These are 3D and can be controlled via the figure toolbar.

Object List: A list of objects which the user has input. All of these objects are able to be edited and deleted at will. Currently all input angles are in radians because I am lazy. It isn't that hard to convert from degrees. Deal with it.

Current object capabilities. The editor has the same options as the create panel.

     Planets: To create a planet objects, there are two options. The first is to choose a defined planet from a list which contains all 9 (including Pluto) planets, the Sun, and Earth's Moon. All of these have images included which can looked at by changing the "View" dropdown menu to be the name of that object. The object will appear in the list as soon as it is added to the object structure. Alternatively, one can create their own planet and define all of the variables themselves, including the name, parent body, orbital elements, and any other parameter. Also (this is my favorite part), the user is able to add a .jpg image to be mapped over the planet to visualize it.  

Left: Add planet pop up.

Right: as well as the custom planet options. There will be more options in the future such as atmospheric density.

Left: Jupiter, as viewed from the program.

Right: Planet Awesome, including a picture mapped over it for the user's pleasure (, a picture which my friend wouldn't allow on facebook so I decided to defy him elsewhere).

     Asteroids: Same thing as planets only there is no creating an asteroid, since it must contain defined point and connectivity list. The parameters are able to be edited though. There are currently 4 asteroids which are programmed in, however I have a database of a fuckton (including their connectivity lists and all parameters) of asteroids which I have not converted to be able to be read by the program. Here is the image of Itokowa which I included in the last post. Right now the only thing the asteroids can do is be pretty. However (and once again as showed in the last post), I need to put the code to orbit asteroids into the GUI.

Itokowa.

     Satellites: The editable parameters of a satellite are similar to that of the previous two. The SA stands for solar array and the rest is self explanatory. Satellites are also able to be viewed, however there is only one model (rectangular everything).

Satellite edit options

Possible Satellite Configurations.

Rockets: Read this post for a full rundown of the rocket capabilities. While I have updated the code (uses inertia matrices and thrust vectoring instead of assuming a constant angular acceleration emulating a thrust vector), and implemented some of it into the GUI, this will give the gist of everything I have done with it and will put in. In short, you can create, view, and launch rockets. So far I have no put the ability to edit in rockets as I have with the other objects since it requires more effort to write the GUI and I would rather work on other parts because I already know it works. Following is a picture of the Falcon 9 Heavy, with projected staging data, as seen in the program.

Falcon 9 Heavy

I think that might be it for now ... I am pretty sure I missed something but I can always cover it some other time. 

Update

Hello!

I have not been posting about it for nearly a year due to school and nobody really reading this. While I have not worked on the Solar System Sandbox program for some time, I have still been working on a continuation of this project. My current project will be explained in the next post.


But before that, a brief update on what I have been working on:

Last semester I created a program which I dubbed "Asteroids", which does just that. Visualization and simulation of orbits about asteroids.

Visualization of Itokowa, which was visited by the Hayabusa spacecraft. 

Itokowa is one of the many asteroids already programmed in.

I included some functions from the Solar System Sandbox for orbit transfers and whatnot and used this program in a paper I co-authored titled "The Near Earth Object (NEO) Scout Spacecraft: A low-cost approach to in-situ characterization of the NEO population" (which can be found here: Neo-Scout Report). I worked specifically on the trajectory, proximity maneuvers, and attitude control sections, while editing it with a few others. Examples of these functions can be seen below (taken straight from the paper so my lazy ass doesn't have to re-run the simulations).

In the paper, the program is used to analyze the trajectory of a satellite orbiting about an asteroid with given face/vertices and density. It includes functions for station keeping and landing/taking off from the asteroid.

Other than that, I have been working realistic rocket program utilizing inertia matrices and thrust vectoring instead of assuming a set angle of turn.

And my current big project, I am making a GUI to put all of these functions together with improved graphics and usability. The frame for editing and visualization is currently finished and I will begin to add tools in very soon. But I will show all of this at a later time.

Orbit Transfer (Part 1)

Julian Date: 2456513

Last time: Plotted current and target orbit specified by the user and indicated initial/target locations of orbit

This time:

I finished the function for an orbit transfer. While I have only included the functions for an orbit transfer, the great part about the functions, namely the Lambert's problem function, is that it can be utilized for all of the transfer functions (rendezvous also require Wiltshire-Clohessey and deep space/moon requires compensation for the gravitational pull of the celestial bodies). This being said, the accuracy of this function decreases with the distance from Earth due to the increased gravitational pull of the other celestial bodies.

So on to the show:

So from the last post, the program has either launched a rocket or the orbital elements of the current orbit have been input. For this example, the elements for both orbits are as follows.

Left: Orbital elements of the two orbits. The top is printed from past inputs and the lower was just input in this frame.

Right: Current and target orbits and departure/arrival locations.

After this, there is an option to either choose the transfer time, or optimize the time for the smallest change in velocity possible. First we will go over the first option.

Choose the time:

After asking if the user wants to launch at a different anomaly, the program prompts for the time of transfer (for this example I intend to create a hyperbola, so I input 100000 seconds, or 27 hours 46 minutes and 48 seconds).

The Lambert's problem function is run and the trajectory is then plotted over the previous plot.

 Plot of the orbits and target trajectory. 

The program then runs through a bunch of equations to get the outputs shown below.

 As you can see, the transfer orbit is a hyperbola. The negative efficiency of the second turn means that the change in velocity was greater than the final velocity itself. I will fix this problem in the future. The rest is pretty self explanatory.

Optimization of the total Delta-V:

After choosing to optimize for a delta-V, the program iterates through Lambert's problem (starting at 10000 seconds, or 2 hours 46 minutes and 28 seconds, and taking 500 second steps) until the delta-V stops decreasing. I will confirm this is the most efficient path later with a function I wrote specifically for that reason. 

The trajectory is chosen from the absolute min and then plotted.

Left: Orthographic view of the trajectory and orbits.

Right: View in plane with original orbit and slightly out of plane with the transfer orbit.

It then plots the same relevant information as before.

Notice the elliptic eccentricity. All efficient transfer orbits should be an ellipse. 

So that is it for this function. I need to find an already developed program to run my results against to see how they stand up.

Proof of the delta-V efficiency:

I edited the code slightly to iterate for a certain amount of time and then plotted the delta-V and eccentricity against time, and the eccentricity vs. the delta-V. Originally I decided to optimize based on eccentricity. I made this decision based on the intuition that a hyperbolic orbit will vertically asymptote at t_transfer=0 and a an orbit would horizontally asymptote as t_transfer approaches infinity. However, and as you will see, the optimum delta-V occurs slightly after the minimum transfer orbit's eccentricity**.

Here is the data, I will zoom in and talk about each in detail after this figure.

Top Left: Delta-V vs. Time. 

Top Right: Eccentricity vs. Time

Bottom: Eccentricity vs. Delta-V

Top Left*: The absolute minimum on the delta-V  vs. time plot is at about 3.08e5 seconds.

Top Right*: The absolute minimum on the eccentricity vs. time plot is at about 2.72e5 seconds.

Bottom**: Shows the minimum delta-V, and therefore the eccentricity at which the efficiency switches direction. This will be discussed more thoroughly in the next few figures.

*As you can see, the absolute minimum for the delta-V occurs slightly after the minimum for the eccentricity. The eccentricity at 3.08e5 seconds is 0.8148, a change of in eccentricity of 0.0042.

As seen above, the minimum delta-V is around 2.051 at an eccentricity of around 0.081495. Notice again how the minimum delta-V is not at the minimum eccentricity (but it is very close).

**The plot on the right should remind you of a hyperbola (v-asymptote at x=0 and h-asymptote at y=0) and a logarithmic function (v-asymptote at x=0 and h-asymptote at y=1). This is because, as I alluded to it earlier, at lower transfer times, the trajectory is hyperbolic. Therefore the eccentricity approaches infinity as the time approaches zero (+). Also, as to not escape the gravitational pull of the earth, the eccentricity cannot exceed 1, therefore as time increases to infinity, the eccentricity would approach 1. The point where the trajectory is more efficient  should be at the minimum points of the plot because a higher eccentricity indicates a higher energy state. The lower the energy state, the less energy is needed to be added to the system. The reason the delta-V does not have a minimum has something to do with the change in inclination, and I will have to look more into that at a later time.

Well that was a lot. I will be working on the rendezvous function next, which shouldn't take long, followed by transfers to celestial bodies. I also plan on figuring out some kind of transcendental equation to optimize the orbit transfer, with variable arrival/departure anomalies, and time. But it is late and I am tired, so I will end this post riiigggghhhttt . . . here.

Rocket Launch (Continued: Part 3)

Julian Date: 2456509

Last time: Plots the trajectory of a rocket after the engines stop firing using an N-body approach.

This time:

Now, from the starting menu, the user has an option to do an orbital transfer. If this option is chosen, it asks if the user wants to either launch a rocket or input orbital elements to calculate the original location and velocity of the rocket. I will go through each in turn.


Orbital Elements:

As you can see, the program prompts for the 6 orbital elements (angular momentum found from eccentricity and semi-major axis). 

 It then plots the orbit and draws a line to the current location.

Rocket:

The program gives the same options to the user for launching a rocket as the rocket function. Once it is "launched" it takes the radius and velocity vector of the rocket and finds the 6 orbital elements from that. It then plots the projected orbit of the rocket, as seen below.

     The launch: Falcon 9 (light), 5000 kg payload, thrust vectoring at 20 seconds for 20 seconds at 30                degrees to east for 80 degrees.

Left: Projected orbit of the rocket in accordance with the orbital elements.

Right: Close up on the perigee end. Notice the line pointing to where the rocket currently is. Also, the rocket's trajectory does land it inside of the Earth (meaning it crashes) at some points on the perigee end. 

This figure shows the N-body version of an identical launch. Notice the similarities in  launch location and trajectory. If you look closely at the N-body projection, you can see the lines do not line up perfectly as they do with the orbital element plot. This is because of including the masses of all other celestial bodies instead of assuming a two body system and only using Earth's mass. While this model is more accurate in the long run, the orbital element model can be used to predict short term trajectories, and can be back checked with the N-body model and the trajectory can be adjusted if it gets off course.

Here the option is given for which type of orbital transfers the user wants. The options currently are a general orbit transfer, a rendezvous, a rendezvous with the moon, or a deep space mission which will include rendezvous with other planets, solar/celestial body orbiting, and gravity assists. Depending on the choice, the program will either prompt for the target orbit's orbital elements, target satellite/spacecraft's orbital elements, or plot where the moon is.

Left: General orbit transfer: Plot of Earth, current trajectory and location, and target orbit.

Center: Rendezvous: Plot of Earth, current trajectory and location, and target orbit and satellite location.

Right: Plot of Earth, current trajectory and location, and current trajectory and location of the Moon.

This is as far as I have written. Next the user will decide at what anomaly they wish to launch, anomaly to arrive at target orbit, and the time of the transfer. The orbital transfer, rendezvous, and moon rendezvous are going to have very similar coding so I plan on finishing those before beginning the deep space function.

There are currently 27 functions (soon to be more), so needless to say my folder is beginning to become clustered. Once I finish what I am currently working on, or when I feel like it, I am going to go through and delete redundant code and re-write some functions to increase versatility.