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.

Rocket Launch (Continued: Part 2)

Julian Date: 2456504

Brief update: I have been working on a function to have a user input solar system lazily between working on more interesting programs (like the one this post is about). It will work with all of the written programs and will be finished . . . eventually.

Last time I mentioned this function*, the code ended at the point where the engines stop firing. So from there, the program asks if you want to plot the trajectory of the rocket. This uses the N-Body approach to find and plot the trajectory, taking into account the sun, moon, and all 9 planets (Yes I know, Pluto etc. do not effect it too much, but it is easier to code this way, it is more accurate, and it does not take much computing power.) There is a direction cosine matrix which transfers the latitude into radius. For simplicity, I assumed that at the end of firing, the rocket is on the x axis. This means the perpendicular horizontal motion is in the y direction, parallel horizontal motion is in the x direction, and all vertical motion is in the z direction. Also, I add velocity in the y direction to compensate for Earth's rotation (compensates for tilt but need to write something to launch from a certain point on earth and/or have a preset destination and assume/calculate an ideal launch.)

*Rocket Launch (part 1)

So here it is:

As I said, after all of the choices made in the previous rocket launch post (see above*), it gives an option to plot the trajectory. It then prompts the run time and number of time steps.

So the launch used in this example: Falcon 9 Light, 15000 kg payload, thrust vector at 20 seconds for 20 seconds at 4 degrees 30 degrees from East, and run for 1e4 seconds. The result was as follows:

This is the resulting n-body projection using all 9 planets, the sun, and the moon. 

Rocket: Blue

Planet: Black

Left: Projected trajectory of the Falcon 9 Light. Notice it "crashes" into the planet.

Right: Projected trajectory of the Earth, and the rocket about it.

Rocket: Saturn V, 55000 kg payload, turn at 20 seconds for 20 seconds at 30 degrees to east with a 4 degree vector. Run for 1e7 seconds.

Left: Position of rocket from Earth. The spirals are from the rotation around the sun. What this graph shows is that the rocket gets further away, eventually it would reverse.

Right: Total orbit of the rocket and planet. The rocket has a shorter orbit and will constantly be moving away from Earth until it catches up in the orbit.

As I said before, I need to program some way to launch to a certain destination or from a certain point, but for now this is it. There will eventually be an option to include the moon in a simulation as well as a function for a missile launch.

A True-er Geocentric View

Julian Date: 2456500

I decided to edit the code for the geocentric view to include the ~23.44 tilt in the axis of the earth. The program now also outputs the apparent latitude of the planets on the starting date (which is defaulted to the user's current day). Notice the increased range of motion from the non-tilted version.

Left: Apparent relative radii from the tilted Earth of all 9 planets and the Sun.

Center: Apparent location of planets as seen from the Earth.

Right: Color assignments and initial apparent latitude

Left: Apparent relative radii from the tilted Earth.
Center: Apparent locations of planets as seen from Earth.
Right: Color assignment and initial apparent latitude

A True Geocentric View

Julian Date: 2456497

Before beginning this blog, the main Earth function was not geocentric based. Instead it was just an earth-moon based model. While still including the Earth-Moon model, in light of changing it to geocentric I decided to make a geocentric view of planets moving with respect to a stationary Earth over the course of a year.

The function finds the relative radii of each planet and the sun with respect to the earth, then plots them. It then normalizes the radii and plots again, with all the plants being shown at where they are in the nights sky. To avoid confusion, the planets/lines are color coded. It may be a little difficult to make out the planets in the first figure because of the large scale (~40 AU), the second only takes the first 4 planets so it is much easier to view (~2 AU). Keep in mind that, while it may seem relatively 2 dimensional, there is differences in the z-axis radii (This can best be seen in the center plot on the first figure. On the left of Earth there is a small dot detached from the "rings", this is the track of Pluto.)

Left: Actual relative radii from the earth of all 9 planets and the sun.

Center*: Location of view from the Earth.

Right: Color assignments

Left: Actual radii

Center: Location from Earth

Right: Color assignments

*this model does not take the earth's tilt in its axis (~23 degrees) into account, planets do not necessarily appear on the equatorial plane.

The story so far (part 4: Rocket Launch [in progress])

Julian Date: 2456496

Rocket Launch Simulation (in progress):

This is where things start to get interactive and fun.

When beginning the launch functions, the user is given an option to either use preset rockets or design their own. I will begin by showing a few random designs I have created. 

The editable qualities are as follows: Number of stages, if there are parallel thrusters (and how many), the command capsule (diameter, length, angle of nose), body (diameter, length, angle to next stage), thrusters (outlet diameter, length), structure mass (payload/capsule mass, structure mass and ratio for each stage and booster), and fuel (specific impulse and mass flow rate for each stage and booster). Once the program is finished, I will go back and put in additional variables which will vary the performance of the spacecraft.

Above are some potential rocket designs. 

The preset designs are currently limited to the Saturn V,  Falcon 9 (light), and the Falcon 9 (Heavy). However I am planning on adding in rockets periodically. 

Left: Saturn V

Center: Falcon 9 (light)

Right: Falcon 9 (heavy)

While the two are not exact, there is a resemblance between the program's rockets and the actual. I will go back eventually to both fix these and add more.

Once the rocket is chosen or created, the program will output the masses and thrust of each stage.

Rocket statistics for a Falcon 9 (heavy) rocket.

After choosing if there is going to be thrust vectoring to cause a gravity assisted turn, the program runs until the last stage of the rocket fires. It then outputs a series of graphs (which I have been using for troubleshooting) which shows the voyage. 

Velocity, mass, height, longitude, and latitude are self explanatory. Phi is the angle to the local vertical (WRT earth) and psi is the angle to the local east.

This is how far I have gotten so far. I will explain some of the assumptions I have made in this and other sections in the future because I am tired of doing this for today. 

More to come soon. 

The story so far (part 3: N-Body simulation)

Julian Date: 2456496

N-Body Simulation:

While N-Body simulations are employed in both the geocentric and heliocentric models, this simulation uses only user input radius, velocity, and masses. Following are examples of Sun-Earth-Moon and Earth-Moon systems.

Sun-Earth-Moon:

Left: The dashed lines show all the places where the Moon (green) comes in front of the Earth (blue). The simulation was run for 1 year, and as you can see, Moon circles the earth 12 times (12 months). The sun did not move significantly, and does not show in the figure.

Right: If you look closely, the green line is rotating around the blue line. This represents a time period of almost 3 months.

Earth-Moon: 

The figure on the left is similar to the N-body simulation for the geocentric model, however, as shown in the figure on the right, due to the movement of the Earth, the Moon moves in a helix. The Earth also moves in a helix around the Sun as it circles the Milky Way.

You are able to model any number of bodies, however it make take an large amount of time to iterate a system of many point masses. I am looking into potentially using a tree-method or figure out some simplification to apply to simulation cases with a larger number of point masses. This will be used to simulate an asteroid belt or numerous celestial bodies.

The story so far (part 2: Geocentric simulation)

Julian Date: 2456496

Geocentric Simulation (quite similar to the heliocentric simulation):

Outputs the date and time as well as the location and velocity of the moon at the current time. This runs off data taken on 2000 AD and is extrapolated to estimate current locations (at the time it was accurate to +- 20 m). It assumed to be accurate, but corrections for current locations will be edited in at a later time.

Upper left: Default view of Earth-Moon system.

Upper right: View from side

Lower left: View from top

Lower right: View along inclined plane.

This is a N-body simulation of the Earth-Moon system. It takes the initial radius and velocity and then runs through a specified number of iterations to result. In the figure, the black line represents the Earth's movement (starting at zero velocity) and the blue line represents the Moon's. Since the Earth began at zero velocity, it is interesting to notice how much the gravity from the Moon effects its motion. This example was run for 1e7 seconds (115.7 days) and iterated 1e6 times (10 seconds each). Because there were only two objects in this simulation, the result is fully in plane (as seen in the right image).

There is also a function to animate the system and will be a function to launch a rocket off of Earth with intention to land on the moon or another celestial body.

The story so far (part 1: Heliocentric simulation)

Julian Date: 2456496

In the next four posts (parts 1-4) I will explain each of the four main functions I currently have. These are the heliocentric, geocentric, rocket launch, and N-body simulation functions.

First option screen

Heliocentric simulation:

Outputs the date and time as well as the locations and velocities of the 9 planets at that time (figure shows the date output by the program and the date and time according to my computer). This runs off data taken on 2000 AD and is extrapolated to estimate current locations (at the time it was accurate to +- 20 m). It assumed to be accurate, but corrections for current locations will be edited in at a later time.

Upper left: Default view of solar system.

Upper right: View from top

Lower left: View from side

Lower right: View of Venus through Mars

Notice the three dimensions and skewed elliptical orbits. Also, the size of the planets (x1000) and sun (x10) are increased for easy view ability. There is also a function to animate the system.

This is a N-body simulation of the planets. It takes the initial radius and velocity and then runs through a specified number of iterations to result. On the left is an example of the first four planets (Sun: black, Mercury: dark blue, Venus: green, Earth: Red, Mars: light blue) run for 1e8 seconds (3.1688 years) and iterated 1e6 times (1.6655 minutes each). The inclinations of these planets are relatively small (as seen in the right image).

Yeah, so this is the heliocentric model, I think Copernicus (before him Aristarchus) would be proud. Is there anything anybody would like to see added? I hope that eventually all of the functions play a part together, but until then I will just keep on coding.

The point of this blog

Julian Date: 2456496

The point of this blog: Not only do I want to share my project with whoever would find it intriguing, but I hope to attract the attention of those with the same interests to throw their two cents in. Hopefully this blog will not only help motivate me, but also bring me more insight of this field.

Not that I have the alpha version out of the way, I am going to skip beta and head on to the real deal. I am making this program as realistic as possible (disclaimer: Being 100% realistic is not possible). Adding a third dimension to this code has proven difficult, but in the ~2 months I have spent casually writing this I feel like I have made decent progress. However, with my computer breaking and having to send it in for a few weeks, this project has had its fair share of setbacks.

I have been working continuously on the many functions. Some have bugs, some are perfect, some have a small math error which propagates downstream and cause a catastrophic cluster-fuck of numbers, but I am trying to fix it all. Regardless, welcome and I hope you find this as interesting as I do.

Space Sandbox alpha

Julian Date: 2456496

So this began as a programming project for my Spaceflight Mechanics class based around a two dimensional circular orbit model of our solar system (or a user created solar system). Written in MatLab's .m code, it includes functions for non-Hohmann elyptical transfers in planetary and solar orbit (also simplified for Hohmann transfers), Kepler's equations, plotting and animating the system, designing a different solar system,  launching a rocket, and gravity assists. It is a bit buggy in certain parts though.

Examples:

Planets Venus through Pluto and their distance from the sun, angular velocity, and true anomaly. As you will see in version 1.0, having circular orbits simplifies everything significantly. 

Again all the planets. As you would first think, the first three are not extremely close to the sun. Pluto sits at around 39 Au while the earth sits at 1 Au. Also, looking at a realistic figure of the solar system (as seen in version 1.0) shows how inaccurate the circular 2-d model is.

The launch program assumes a bunch of things and is not too accurate. You can do non-Hohmann interplanetary transfers, but this is a Hohmann. All of the outputs are relatively consistent with real launches, ie a circular 2-d can be used to estimate but will not work in real world conditions. You may also notice how large the third burn is. It is because this program does not use drag to slow the rocket down, as occurs in real situations.

Essentially this is what the alpha program does. Version 1.0 is a 3-d elliptical version of this, and includes many more functions which add to the experience. Read on to check out Version 1.0. 

The code is available upon request (alpha version).