Conclusion

I think this is far from an idiomatic implementation so I’ll keep this brief. I don’t think I used JS or Observable as well as I could have so treat this as a beginner stabbing into the dark because thats essentially what the code is.

This was quite a bit more work than the original Python implementation, but running real time, having beaufitul defaults, and being interactive without a backend make this leagues better than anything offered by any other language. There is definitely a loss of energy in the system over time that I attribute to Javascript being a mess, but I doubt that I would ever move all of my analysis to JS anyways so I don’t think it matters. Its also very likely I’m doing something bad with my timesteps.

Data Preparation

The models were processed in Blender, which quickly converted the assemblies to stl files, giving 108 unique parts to be processed. Since the expected final size of the dataset is expected to be in the magnitude of the thousands, an algorithm capable of getting the required properties of each part is the only feasible solution. From the analysis performed in Report 1, we know that the essential debris property is the moments of inertia which helped narrow down potential algorithms. Unfortunately, this is one of the more complicated things to calculate from a mesh, but thanks to a paper from (Eberly 2002) titled Polyhedral Mass Properties, his algorithm was implemented in the Julia programming language. The current implementation of the algorithm calculates a moment of inertia tensor, volume, center of gravity, characteristic length, and surface body dimensions in a few milliseconds per part. The library can be found here. The characteristic length is a value that is heavily used by the NASA DebriSat project (Murray et al. 2019) that is doing very similar work to this project. The characteristic length takes the maximum orthogonal dimension of a body, sums the dimensions then divides by 3 to produce a single scalar value that can be used to get an idea of thesize of a 3D object.

The algorithm’s speed is critical not only for the eventual large number of debris pieces that have to be processed, but many of the data science algorithms we plan on performing on the compiled data need the data to be normalized. For the current dataset and properties, it makes the most sense to normalize the dataset based on volume. Volume was chosen for multiple reasons, namely because it was easy to implement an efficient algorithm to calculate volume, and currently, volume produces the least amount of variation out of the current set of properties calculated. Unfortunately, scaling a model to a specific volume is an iterative process, but can be done very efficiently using derivative-free numerical root-finding algorithms. The current implementation can scale and process all the properties using only 30% more time than getting the properties without first scaling.

 Row │ variable               mean      min        median     max
─────┼───────────────────────────────────────────────────────────────────
   1 │ surface_area           25.2002   5.60865     13.3338     159.406
   2 │ characteristic_length  79.5481   0.158521    1.55816     1582.23
   3 │ sbx                     1.40222  0.0417367   0.967078    10.0663
   4 │ sby                     3.3367   0.0125824   2.68461     9.68361
   5 │ sbz                     3.91184  0.29006     1.8185      14.7434
   6 │ Ix                      1.58725  0.0311782   0.23401     11.1335
   7 │ Iy                      3.74345  0.178598    1.01592     24.6735
   8 │ Iz                      5.20207  0.178686    1.742       32.0083

Above is a summary of the current 108 part with scaling. Since all the volumes are the same it is left out of the dataset, the center of gravity is also left out of the dataset since it currently is just an artifact of the stl file format. There are many ways to determine the ‘center’ of a 3D mesh, but since only one is being implemented at the moment comparisons to other properties doesn’t make sense. The other notable part of the data is the model is rotated so that the magnitudes of Iz, Iy, and Ix are in descending order. This makes sure that the rotation of a model doesn’t matter for characterization. The dataset is available for download here:

• scaled_dataset.csv

Characterization

The first step toward characterization is to perform a principal component analysis to determine what properties of the data capture the most variation. PCA also requires that the data is scaled, so as discussed above the dataset that is scaled by volume will be used. PCA is implemented manually instead of the Matlab built-in function as shown below:

% covaraince matrix of data points
S=cov(scaled_data);

% eigenvalues of S
eig_vals = eig(S);

% sorting eigenvalues from largest to smallest
[lambda, sort_index] = sort(eig_vals,'descend');


lambda_ratio = cumsum(lambda) ./ sum(lambda)

Then plotting lambda_ratio, which is the cumsum/sum produces the following plot:

The current dataset can be described incredibly well just by looking at Iz, which again the models are rotated so that Iz is the largest moment of inertia. Then including Iy and Iz means that a 3D plot of the principle moments of inertia almost capture all the variation in the data.

The next step for characterization is to get only the inertia’s from the dataset. Since the current dataset is so small, the scaled dataset will be used for rest of the characterization process. Once more parts are added to the database it will make sense to start looking at the raw dataset. Now we can proceed to cluster the data using the k-means method of clustering. To properly use k-means a value of k, which is the number of clusters, needs to be determined. This can be done by creating an elbow plot using the following code:

for ii=1:20
    [idx,~,sumd] = kmeans(inertia,ii);
    J(ii)=norm(sumd);
end

Which produces the following plot:

As can be seen in the above elbow plot, at 6 clusters there is an “elbow” which is where there is a large drop in the sum distance to the centroid of each cluster which means that it is the optimal number of clusters. The inertia’s can then be plotted using 6 k-means clusters produces the following plot:

From this plot it is immediately clear that there are clusters of outliers. These are due to the different shapes and the extreme values are slender rods or flat plates while the clusters closer to the center more closely resemble a sphere. As the dataset grows it should become more apparent what kind of clusters actually make up a satellite, and eventually space debris in general.

Next Steps

The current dataset needs to be grown in both the amount of data and the variety of data. The most glaring issue with the current dataset is the lack of any debris since the parts are straight from satellite assemblies. Getting accurate properties from the current scans we have is an entire research project in itself, so hopefully, getting pieces that are easier to scan can help bring the project back on track. The other and harder-to-fix issue is finding/deriving more data properties. Properties such as cross-sectional or aerodynamic drag would be very insightful but are likely to be difficult to implement in code and significantly more resource intensive than the current properties the code can derive.

Next Steps

The current dataset needs to be grown in both the amount of data and the variety of data. The most glaring issue with the current dataset is only two different material types. Modern satellites, and therefore their debris, is composed of dozens of unique materials. The other and harder to fix issue is finding/deriving more data properties. Properties such as cross-sectional are or aerodynamic drag would be very insightful, but there is no good way to collect that data. Thankfully, the 3D scanner methods to obtain more properties can be developed and applied over the entire dataset.

Once the dataset is grown, more advanced analysis can begin. PCA is the current goal and can hopefully be applied by the next report.

Check out the repo for this report for all the code and raw data. https://gitlab.com/orbital-debris-research/directed-study/report-1

Project Summary

There are currently approximately 23,522 debris objects 10 centimeters in size or larger tracked by NASA, an estimated 500,000 objects 1 centimeter in size or larger, and upwards of 100 million debris objects at least 1 millimeter in size [1]. Furthermore, the average relative velocity of objects in Low Earth Orbit is ten km/s [2], which means collisions with even tiny pieces of debris can end a space mission and create more debris. These factors could combine and lead to a vicious cycle where debris causes more debris, potentially creating debris faster than atmospheric drag could remove it and, in an extreme case blocking access to space for decades [3]. Essential factors in predicting the damage due to collision with space debris are its mass, density, speed, and shape. As a result, developing models to predict the orbits of debris and categorizing them based on their shape characteristics is a growing focus for the US and allied space agencies [4]. These models are used to maneuver around the upcoming debris or assess the potential damage due to collisions. Current studies have the following shortcomings. Although they only utilize a few shape characteristic factors for space debris classification, namely characteristic length, and average cross-section, they do not consider shape characteristics vital in calculating collision damage, such as ballistic coefficient. This proposal aims to improve state-of-the-art through advanced object classification with the following methodology that utilizes 3D scanning and Machine Learning. First, high-resolution 3D scans of satellite debris are acquired imported in CATIA, and solid models from them are created from which an abundance of shape characteristics factors can be obtained. 3D scanning is followed by employing Machine Learning techniques for reducing the dimensionality of the obtained features (via the Principal Component Analysis) and replacing the current decision trees with more reliable clustering algorithms, such as K-Means Clustering or Artificial Neural Networks. Then this data is processed with Ballistic coefficient and other essential factors in the collision of a satellite with different classes of space debris found from machine learning will be calculated, and further refinement in these clusters will be investigated.

Project Description

Project Approach

Below in Figure 1, you can see an example of the current decision tree method used by DebriSat alongside the advanced 3D scan data science pipeline that we propose. Our method utilizes complex analysis only possible with a high-resolution scan of the models and then uses a variety of machine learning and data science techniques to process the data into useful metrics. Our method is a modern approach that can eventually be developed into complex simulations of debris.

Enough samples to get the project started have been provided by Dr. Madler, but as of now, they are entirely uncharacterized. The first step towards characterizing the debris we have is to manually organize them into different clusters. The clusters are based on similar characteristics that can be observed visually to produce a preliminary characterization and are just meant to be a starting point for the MATLAB code. Then three to five samples from each cluster will be scanned to give a somewhat even distribution of what we expect MATLAB to provide for each cluster. When clustering using machine learning methods, every cluster must have a few pieces to ensure minimal outliers in the data. As more data becomes available, the machine learning methods get more powerful. Before being put into MATLAB, every scan will be uploaded into CATIA to take data from the scans and clean up the model. CATIA makes some of the desired characteristics of the debris samples, such as the moment of inertia, the center of gravity, etc., very easy to collect. Future iterations of this project will likely do all processing in MATLAB to reduce the manual labor required for each piece of debris. Below in Figure 2 is a render of a real piece of debris scanned by the Rapid Prototyping Lab on campus. Even after reducing the number of points provided by the scanner, the final model has over 1.2 million points, which is an impressive resolution given that the model is only a few inches in length on its longest axis. With debris created by hyper-velocity impacts having such complex shapes, it becomes clear almost immediately that the geometry is far too complex for any sort of meaningful characterization by a human without machine learning techniques. This issue is compounded by the fact that satellites comprise many exotic materials. The DebriSat program uses a simplified satellite to reduce costs, and it still comprises 14 different categories of materials where a category is primarily a way to determine how dense the material is [9] and not for each unique material. This also means that the shapes vary wildly since PCBs, wires, batteries, and the aluminum structure reacts entirely differently to a hypervelocity collision. The example in Figure 2, and every piece of debris we have at our disposal, are from a hypervelocity impact involving aluminum sheet metal. A dataset of one material type is beneficial at this point since our dataset is still small; it makes sense to start our characterization with a single type of debris.

Our data collection process gives us much more data than the traditional methods, so machine learning is required to make sense of the data. The first step towards processing our data once it has been tabulated into MATLAB is to perform a principal component analysis (PCA). Utilizing PCA has two significant benefits at this stage of the project in that it reduces the required size of our dataset and decreases the amount of computational power to process the dataset. Reducing our dataset’s dimensionality will allow us to derive what aspects of the orbital debris are truly important for the classification. This may be easy for a human to discern at this stage of the project, but the DebriSat database has almost 200,000 pieces of debris cataloged [8], so it is essential to start with an approach that is adaptable to big data and is robust enough to handle the metrics we are trying to classify that are very complex. Once PCA has reduced the dataset, it can be clustered using the k-means method. K-means is a method of categorizing large, complex datasets using pattern recognition. Depending on which insight we are looking for, k-means could produce a valuable result, or it could be a step to much more advanced machine learning methods of analysis.

Safety Considerations

As with any research, safety is the number one priority, and steps need to be taken to ensure that every step of the project is approached as safely as possible. Lucky for this project, the only safety consideration is that the debris pieces can have sharp edges and need to be handled with care. Anyone interacting with the debris will be informed of this risk, and the debris will only be handled in the RPL lab where it is safely stored, and the room also has a first aid kit. That said, the risk of a cut from the debris is very low, and the severity would likely be on the magnitude of a paper cut.

Outreach Activities

Outreach will be performed at the Prescott Regional SciTech Festival, which Embry-Riddle holds on March 5th, but this year will be held virtually. This is an excellent opportunity to share our research with professionals across the STEAM community. Expected Project Outcomes Orbital debris is pollution and is on a visible path towards reaching a point of no return where our access to space could be completely cut off for decades. Even a reduction in space activities could have a long-standing impact on military, commercial and civilian operations [7]. This research will increase our understanding of the current orbital debris environment and enable further research to mitigate new debris by creating more advanced collision avoidance and manufacturing techniques for rockets and satellites that decrease the amount of debris generated. The student researchers will also benefit from performing this project. First, students will learn how to collect a large dataset specifically to make it accessible by the code they write. Then a great deal of work will be spent on analyzing the data, which will rely on knowledge of solid mechanics, space mechanics, materials science, and machine learning to characterize the debris properly.

What is Nano

Nano is fast because it uses a block-lattice architecture. This means that there is no concept of block times which are the limiting factor for most cryptocurrency’s transaction time. Every wallet has a unique blockchain, and each “block” only contains a single transaction. Since the block is only needed when a transaction is made, wallets can pre-mine a block and hold onto the proof of work. Since each wallet manages its blockchain and proof of work, nodes only need to worry about the balance of each wallet. This enables transactions to be instantly propagated to the network, and the nodes that govern the network only keep track of the balance of each wallet.

Nano is free to transact because it does not rely on paying miners for proof of work, and it is designed to be efficient so running a node is cheap and does not require support from the network. Bitcoin requires 1900 kWh of power for a single transaction¹⁰, whereas Nano is only 0.111 Wh per transaction¹¹ which is a difference of about 17 million percent.¹² There are many arguments that no one will run the nodes required to keep the Nano network healthy without proper incentives. Nano can work around this by keeping the requirements to run a Node very low so that the indirect benefits of running a node far outweigh the costs of the hardware. Companies will likely run nodes since running a node will be cheaper than paying transaction fees for other payment methods. The Nano whitepaper goes into great detail about the types of nodes.

Why isn’t Nano Mainstream

Most cryptocurrencies have features that directly benefit other users or network maintainers from being used. Transaction fees fed back into the coin’s ecosystem are a great way to create feedback loops that generate more use for a coin. The incentive structure for Nano is much less direct but arguably much more potent. Established players in the cryptocurrency and payment processor world benefit significantly from having transactions go through them. To single out Coinbase, they have a feature where you can transfer crypto between any other member on the platform instantly and free¹³. This proprietary feature could create a walled garden that Nano threatens to dismantle.

It would be unfair to suggest that Nano’s problems are from big established players fighting innovation. Nano’s most vital features also make it susceptible to spam attacks. Since there is no fee and the network supports dividing 1 Nano into 30 decimal places, attackers can spam the network by sending trace amounts of Nano to random addresses. The ability to send these dust transactions creates a ton of stress on the network and has even ground Nano to a halt in the past¹⁴. However, the network did perform better than most had hoped, and the spam attack worked as an excellent verification of Nano’s capabilities. Since then, the development team has focused on solutions to ensure that the issue doesn’t occur again. It is worth noting that although Nano is feeless, it is not free. So, while sending Nano does not cost any Nano, it does cost computation, so attacks on the network are still costly.

I’ll close this off by saying that I highly recommend any cryptocurrency enthusiast to please read the Nano Whitepaper since it is one of the best cryptocurrency whitepapers, and in my opinion, second only to the original Bitcoin Whitepaper. I hope that this article was insightful, and even though I am a holder of Nano, I hope that the information is unbiased. If you think Nano is worth checking out, the Nano Foundation has an excellent getting started page: https://nano.org/try-nano

The Solution

With Continuous Integration and a little Python, my GitLab repository automatically builds the latest code, runs the code, produces plots with the results, and makes an executable available if someone is inclined to run the code themselves. The automation means that the project readme is always up to date, and if anyone is wondering how progress is proceeding, they can check the readme and view the current performance in an accessible format.

The data availability is also excellent for when my team has to produce a progress report because there is never waiting on the person who can run the code and then build some plots. Unfortunately, the same can’t be said for the other sub-teams who usually have difficulty compiling their progress into a report.

The Result

All of the code being used for the Capstone is public, and the specific repository that I’ve been talking about can be accessed here: https://gitlab.com/lander-team/lander-cpp As you can see, the readme has charts that are always up to date. The .gitlab-ci.yml file contains all the build info, and you’ll likely be surprised how simple of a setup it is.

What is an Eclipse

{fig-alt=“A diagram of an eclipse. The sun is shown as a large yellow circle on the left. A smaller blue circle labeled”Body” is to the right of the sun. A spacecraft is shown above the body. The umbra and penumbra are labeled.”}

The above image is a simple representation of what an eclipse is. First, you’ll notice the Umbra is complete darkness, then the Penumbra, which is a shadow of varying darkness, and then the rest of the orbit is in full sunlight. For this example, I will be using the ISS, which has a very low orbit, so the Penumbra isn’t much of a problem. However, you can tell by looking at the diagram that higher altitude orbits would spend more time in the Penumbra.

Here is a more detailed view of the eclipse that will make it easier to explain what is going on. There are 2 Position vectors, and 2 radius that need to be known for simple eclipse determination. More advanced cases where the atmosphere of the body your orbiting can significantly affect the Umbra and Penumbra, and other bodies could also potentially block the Sun. However, we will keep it simple for this example since they have minimal effect on the ISS’s orbit. Rsun and Rbody are the radius of the Sun and Body (In this case Earth), respectively. r_sun_body is a vector from the center of the Sun to the center of the target body. For this example I will only be using one vector, but for more rigorous eclipse determination it is important to calculate the ephemeris at least once a day since it does significantly change over the course of a year. The reason that I am ignoring it at the moment is because there is currently no good way to calculate Ephemerides in Julia but the package is being worked on so I may revisit this and do a more rigorous analysis in the future. r_body_sc is a position vector from the center of the body being orbited, to the center of our spacecraft.

The Code

using Unitful
using LinearAlgebra
using SatelliteToolbox
using Plots
using Colors
theme(:ggplot2)

To get the orbit for the ISS, I used a Two-Line Element which is a data format for explaining orbits. The US Joint Space Operations Center makes these widely available, but https://live.ariss.org/tle/ makes the TLE for the ISS way more accessible (“ARISS,” n.d.). The Julia Package SatelliteToolbox.jl makes it super easy to turn a TLE into an orbit that can be propagated. Simply putting the TLE in a string and using the tle string macro like below, we now have access to the information to start making our ISS orbit.

ISS = tle"""
ISS (ZARYA)
1 25544U 98067A   21103.84943184  .00000176  00000-0  11381-4 0  9990
2 25544  51.6434 300.9481 0002858 223.8443 263.8789 15.48881793278621
"""

TLE:
                      Name : ISS (ZARYA)
          Satellite number : 25544
  International designator : 98067A
        Epoch (Year / Day) : 21 / 103.84943184 (2021-04-13T20:23:10.911)
        Element set number : 999
              Eccentricity :   0.00028580
               Inclination :  51.64340000 deg
                      RAAN : 300.94810000 deg
       Argument of perigee : 223.84430000 deg
              Mean anomaly : 263.87890000 deg
           Mean motion (n) :  15.48881793 revs / day
         Revolution number : 27862
                        B* :   1.1381e-05 1 / er
                     ṅ / 2 :     1.76e-06 rev / day²
                     n̈ / 6 :            0 rev / day³

Now that we have the TLE, we can pass that into SatelliteToolbox’s orbit propagator. Before propagating the orbit, we need to have a range of time steps to pass into the propagator. The TLE gives the mean motion, n, which is the revolutions per day, so using that, we can calculate the amount of time required for one orbit, which is all that we’re worried about for this analysis. The propagator returns a tuple containing the Orbital elements, a position vector with units meters, and a velocity vector with units meters per second. For this analysis were only worried about the position vector.

ISS.mean_motion

15.48881793

orbit = Propagators.init(Val(:SGP4), ISS);
time = 0:0.1:((24/ISS.mean_motion).*60*60);
propagated = Propagators.propagate!.(orbit, time);
r = first.(propagated); # Get distance from propagator

We just need to use the radii and vectors discussed earlier to determine if the ISS is in the penumbra or umbra. This is a lot of trigonometry and vector math that I won’t bore anyone with. However, using the diagrams above and following the code in the sunlight function, you should follow what’s happening. For a rigorous discussion, check out (Vallado 1997).

function sunlight(Rbody, r_sun_body, r_body_sc)
    Rsun = 695_700u"km"

    hu = Rbody * norm(r_sun_body) / (Rsun - Rbody)

    θe = acos((r_sun_body ⋅ r_body_sc) / (norm(r_sun_body) * norm(r_body_sc)))

    θu = atan(Rbody / hu)
    du = hu * sin(θu) / sin(θe + θu)

    θp = π - atan(norm(r_sun_body) / (Rsun + Rbody))
    dp = Rbody * sin(θp) / cos(θe - θp)

    S = 1
    if (θe < π / 2) && (norm(r_body_sc) < du)
        S = 0
    end
    if (θe < π / 2) && ((du < norm(r_body_sc)) && (norm(r_body_sc) < dp))
        S = (norm(r_body_sc .|> u"km") - du) / (dp - du) |> ustrip
    end

    return S
end

sunlight (generic function with 1 method)

Then we can pass all the values we’ve gathered into the function we just made.

S = r .|> R -> sunlight(6371u"km", [0.5370, 1.2606, 0.5466] .* 1e8u"km", R .* u"m");

Plotting the Results

The sunlight function returns values from 0 to 1, 0 being complete darkness, 1 being complete sunlight, and anything between being the fraction of light being received. Again since the ISS has a very low orbit, the amount of time spent in the penumbra is almost insignificant.

Code

# Downsample for plotting (keep ~1000 points for visual fidelity)
n_points = length(S)
step = max(1, n_points ÷ 1000)
idx = 1:step:n_points
S_plot = S[idx]

# Get fancy with the line color.
light_range = range(colorant"black", stop=colorant"orange", length=101);
light_colors = [light_range[unique(round(Int, 1 + s * 100))][1] for s in S_plot];

plot(
    LinRange(0, 24, length(S_plot)),
    S_plot .* 100,
    linewidth=5,
    legend=false,
    color=light_colors,
);

xlabel!("Time (hr)");
ylabel!("Sunlight (%)");
title!("ISS Sunlight Over a Day")

ISS Sunlight

Looking at the plot, the vertical transition from 0% to 100% makes it pretty clear that the time in the penumbra is limited. Still, almost counterintuitively, it also looks like the ISS gets more sunlight than it does darkness. So, using the raw sunlight data, we can calculate precisely how much time is spent in each region.

Time in Sun:

sun = length(S[S.==1]) / length(S) * 100

62.04757721886597

Time in Darkness:

umbra = length(S[S.==0]) / length(S) * 100

37.627951167918546

Time in Penumbra:

penumbra = 100 - umbra - sun

0.32447161321548634

This means that even with the ISS’s low orbit, it still gets sunlight ~62% of the time and spends almost no time in the penumbra. This would vary a few percent depending on the time of year, but in a circular orbit like the ISS, the amount of sunlight would remain pretty constant. There are other orbits like a polar orbit, lunar orbit, or highly elliptic earth orbits that can have their time in the sunlight vary widely by the time of year.

The Simulation

I chose an off-the-shelf paintball gun tank for the pressure vessel. The primary consideration was the incredible pressure to weight ratio, and the fact that it is designed to be bumped around would be necessary for proving the safety of the system further into the project.

# Tank https://www.amazon.com/Empire-Paintball-BASICS-Pressure-Compressed/dp/B07B6M48SR/
V = (85 ± 5)u"inch^3";
P0 = (4200.0 ± 300)u"psi";
Wtank = (2.3 ± 0.2)u"lb";
Pmax = (250 ± 50)u"psi"; # Max Pressure that can come out the nozzle

The nozzle diameter was changed until the air prop system had a burn time similar to a G18ST rocket motor. The propulsion system’s total impulse is not dependant on the nozzle diameter, so this was just done to make it plot nicely with the rest of the rocket motors since, at this time, it is unknown what the optimal thrust profile is.

# Params
d_nozzle = ((1 // 18) ± 0.001)u"inch";
a_nozzle = (pi / 4) * d_nozzle^2;

These are just universal values for what a typical day would look like during the summer in Northern Arizona. (Çengel and Boles 2015)

# Universal Stuff
P_amb = (1 ± 0.2)u"atm";
γ = 1.4 ± 0.05;
R = 287.05u"J/(kg * K)";
T = (300 ± 20)u"K";

The actual simulation is quite simple. The basic idea is that using the current pressure, you can calculate , which allows calculating the Thrust, and then you can subtract the current mass of air in the tank by and recalculate pressure using the new mass then repeat the whole process.

The bulk of the equations in the simulation came from (Çengel and Boles 2015), while the Thrust and equations came from (Sutton and Biblarz 2001, eq: 2-14).

The initial pressure difference is 4190.0 ± 300.0 psi, which is massive, so the area of the nozzle significantly alters the thrust profile. The paintball tanks come with pressure regulators, in our case, 800 psi which is still a huge number compared to atmospheric pressure. While the total impulse of the system doesn’t change with different nozzle areas, the peak thrust and burn time vary greatly. One of the benefits of doing air propulsion and the reason it was even considered so seriously is that it should be possible to change the nozzle diameter in flight, allowing thrust to be throttled, making controlled landing easier to control.

t = 0.0u"s";
P = P0 |> u"Pa";
M = V * (P / (R * T)) |> u"kg";
ts = 1u"ms";
df = DataFrame(Thrust=(0 ± 0)u"N", Pressure=P0, Time=0.0u"s", Mass=M);
while M > 0.005u"kg"
    # Calculate what is leaving tank
    P = minimum([P, Pmax])
    ve = sqrt((2 * γ / (γ - 1)) * R * T * (1 - P_amb / P)^((γ - 1) / γ)) |> u"m/s"
    ρ = P / (R * T) |> u"kg/m^3"
    ṁ = ρ * a_nozzle * ve |> u"kg/s"

    Thrust = ṁ * ve + a_nozzle * (P - P_amb) |> u"N"

    # Calculate what is still in the tank
    M = M - ṁ * ts |> u"kg"
    P = (M * R * T) / V |> u"Pa"
    t = t + ts

    df_step = DataFrame(Thrust=Thrust, Pressure=P, Time=t, Mass=M)
    append!(df, df_step)
end

Analysis

Below in figure 1, the result of the simulation is plotted. Notice the massive error once the tank starts running low. This is because the calculation for pressure has a lot of very uncertain variables. This is primarily due to air being a compressible fluid, making this simulation challenging to do accurately. The thrust being below 0 N might not make intuitive sense, but it’s technically possible for the pressure to compress, leaving the inside of the rocket nozzle with a pressure that’s actually below atmospheric pressure. The effect would likely last a fraction of a second, but the point stands that this simulation is wildly inaccurate and only meant to get an idea of what an air propulsion system is capable of.

thrust_values = df.Thrust .|> ustrip .|> value;
thrust_uncertainties = df.Thrust .|> ustrip .|> uncertainty;
time_values = df.Time .|> ustrip;

# Downsample for plotting (keep ~1000 points for visual fidelity)
n_points = length(thrust_values)
step = max(1, n_points ÷ 1000)
idx = 1:step:n_points

air = DataFrame(
    Thrust=thrust_values[idx],
    Uncertainty=thrust_uncertainties[idx],
    Time=time_values[idx]
);

plot(air.Time, air.Thrust,
    title="Thrust Over Time",
    ribbon=(air.Uncertainty, air.Uncertainty),
    fillalpha=0.2, label="Thrust",
    xlabel="Time (s)",
    ylabel="Thrust (N)",
)

In Figure 2, the air propulsion simulation is compared to commercially available rocket motors. This early in the project, we have no idea whether short burns or longer burns are ideal for a propulsive landing, so the air propulsion system was compared to a variety of different motors with unique profiles.

f10 = CSV.read("AeroTech_F10.csv", DataFrame);
f15 = CSV.read("Estes_F15.csv", DataFrame);
g8 = CSV.read("AeroTech_G8ST.csv", DataFrame);

plot(air.Time, air.Thrust, label="Air Propulsion", legend=:outertopright);

for (d, l) in [(f10, "F10"), (f15, "F15"), (g8, "G8ST")]
    plot!(d[!, "Time (s)"], d[!, "Thrust (N)"], label=l)
end

title!("Propulsion Comparison");
xlabel!("Time (s)");
ylabel!("Thrust (N)")

In the end, the air propulsion system’s performance has a very impressive total impulse and, with more time and resources, could be a serious option for a propulsive landing on Earth. One of the largest abstractions from the Moon mission that the mission here on Earth will have to deal with is the lack of Throttling engines since any propulsion system outside of model rocket motors is well beyond the scope of this Capstone.

Future Work

After determining that solid model rocket motors are the best option for the current mission scope, the next step is determining what motor to use. There are many great options, and deciding what thrust profile is ideal may have to wait until a Simulink simulation of the landing can be built so that the metrics of each motor can be constrained more. Instead of throttling motors, the current working idea is that thrust vector control may be a way to squeeze a little more control out of a solid rocket motor. Thrust Vector Control will undoubtedly be challenging to control, so another essential piece that needs exploring is whether an LQR controller is feasible or if a PID controller is accurate enough to control our system.

Codebase: https://gitlab.com/lander-team/air-prop-simulation

Go to the Autodesk 360 Dashboard

Going to https://myhub.autodesk360.com will give you a similar looking Project and file options as the data panel in the Desktop version. Navigate to your model and open it. Whether you are in the Design View or the 3D View in the top right corner, you’ll have a few options to choose from.

Clicking the download button provides you with a ton more options than the desktop version offers. Unfortunately, you cannot download straight from the website as it takes time to convert, so you have to wait for an email. In my experience, this usually takes less than a minute although I would imagine more complex models take more time.

Below I have a list of every file-type that can be exported and a quick summary of what they are good for.