Lunar Orbit Insertion Maneuver

New functions in the Lunar Cube module in 2016.1 allow you to easily plan lunar insertion and orbit change maneuvers. In the following pictures you can see a lunar orbit insertion from a hyperbolic orbit. In all figures the lunar terrain is exaggerated by a factor of 10.

LunarMnvr2

The same maneuver looking down on the orbit plane. The green arrows are the force vectors.

LunarMnvr1

The following figure shows a two maneuver sequence. The first puts the spacecraft into an elliptical orbit. The second circularizes the orbit.

Lunar3

Lunar Cube Module for 2016.1

We are adding the Lunar Cube Module in 2016.1 to our CubeSat Toolbox for MATLAB! It allows users to analyze and simulateCubeSats in lunar transfer and lunar orbit. It includes a new dynamical model for CubeSats that includes:

  • Earth, Moon and Sun gravity based on the JPL ephemerides
  • Spherical harmonic lunar gravity model
  • Reaction wheels
  • Thrusters
  • Power generation from solar panels
  • Battery energy storage
  • Variable mass due to fuel consumption
  • Solar pressure disturbances
  • Lunar topographic model
  • New graphics functions for lunar orbit operations
  • Lunar targeting function
  • Lunar mission control function for attitude control and orbit control

The module includes a script with a simulation of a 6U Cubesat leaving Earth orbit and reaching the moon. The following figure shows the Earth to Moon trajectory.

LunarTrajectory

This figure shows the transfer orbit near the moon. The lunar topography is exaggerated by a factor of 10 to make it visible. It is based on Clementine measurements.

LunarEncounter

Here are results from the new LunarTargeting function. It finds optimal transfers to lunar orbits. The first shows the transfer path to the Moon’s sphere of influence.

Test21

The next shows the lunar hyperbolic orbit. In this case the transfer is into a high inclination lunar orbit.

Test22

Contact us for more information!

Stofiel Aerospace and Princeton Satellite Systems at CES

Stofiel Aerospace LLC had a display at the Consumer Electronics Show. They invited Princeton Satellite Systems to display its products on their table. The booth is shown in the following picture. You can see Stofiel’s rockets.

IMG_0587

Here is a closeup showing our 3U CubeSat with a camera mounted in one of the bays.

IMG_0588
Members of the Stofiel team:

IMG_0663

More members of the Stofiel team:

IMG_0697

Stofiel Aerospace LLC is an aerospace solutions company created by five U.S. military veterans from Cleveland, Ohio. Stofiel Aerospace LLC is currently developing a portable micro/nano-satellite launch system. Their revolutionary system drastically reduces the wait time for small payloads to reach low Earth orbit to days, not years. By utilizing solid rocket motors and Hydrogen-filled balloons, their system finally offers CubeSat manufacturers and clients the opportunity to be considered a “primary payload” for orbital missions. Currently, they are partnered with the Ohio Aerospace Institute in Cleveland, Ohio and working for further funding to continue development of this industry-changing technology. For inquiries, please contact Jason Beeman, CFO at (440) 994-9035.

SunStation in October

The following image shows SunStation in operation on a bright October day! The load for the day was 12.4 kWh. This includes charging a Nissan Leaf and a Toyota Prius Plugin-in. The total power generated was 40.3 kWh and 21.4 kWh was sold to the grid. As you can see, the installation is much more than carbon neutral with regard to electrical power. It has a gas heating system so is not completely carbon neutral.

OPTICSRE

The orange line is the state of charge for the batteries. The 14.4 kWh of batteries is enough to keep the home running, charge the Prius fully and the Leaf partially, when the grid is down. The system automatically disconnects itself from the grid when there is an outage.

The house itself is fairly energy efficient with mostly LED lights and a few CFLs. The heating system is high efficiency with a 60 W fan that operates most of the time. The house is air-tight and has a whole house air exchange system that operates continuously. The refrigerator is 10 years old and the washer and dryer are less than 10 years old. As you can see, the typical load is 500 W except when the cars are charging. The efficiency could be further improved by installing a state-of-the-art central air system and replacing the refrigerator.

The Nissan Leaf is 100% electric. On a normal day the Prius operates on battery stored energy about 80% of the time. It visits the gas station once every 3 weeks or so.

Besides saving money on power, the system produces 7 Solar Renewable Energy Credits (SRECs) yearly. At current SREC prices, that is about $1500 a year in revenue. The homeowners own the system so all the revenue goes directly to them.

Pluto Spacecraft

Here is a picture of our DFD transfer vehicle. You can see the lander on the front and two Deep Space Optical Communication System (DSOC) assemblies mounted on trusses. There are 2 DFD engines.

PlutoDFD

A picture of the Pluto Lander. The solar panels are illuminated by a laser from the orbiter. The lander has a dry mass of 150 kg.

LunarLander

Both were designed in the Spacecraft Control Toolbox v2015.2.

You can get more information about the Pluto orbital mission on Slideshare.

Pluto Orbiter – the Next Step after New Horizons

The spectacular success of the NASA New Horizons mission has led to many new discoveries about Pluto. The next step would be to send an orbiter. That isn’t easy to do with chemical propulsion but could be done with Direct Fusion Drive.

We’ve done a preliminary mission analysis for a Pluto orbital mission. We are baselining a Delta IV Heavy that can put up to 9,306 kg into interplanetary orbits. These plots show various parameters versus mission duration. The maximum duration is the same as the New Horizons mission, 10 years.

PlutoMission2MW4Yr

Let’s use the 4 year mission as a baseline. It would use a 2 MW DFD engine to reach Pluto in about 4 years and go into orbit. The engine would thrust for 270 days out of the 4 year mission producing 110 km/s delta-V. The trajectory is shown below

PlutoTraj2MW4Yr

Once there, almost 2 MW of power would be available for the science mission, over 10000 times as much power as is available to New Horizons! The New Horizons bit rate is no more than 3000 bits per second. The high power would allow for a bit rate of over 135 Mbps for data transmission back to Earth using the JPL Deep Space Optical Communications System and a 30 kW laser transmitter. The time in transit is much shorter than New Horizons and would produce significant savings on operations costs. Launch times would be more flexible since gravity assists would not be needed.

DFD would use deuterium and helium-3 as fuels. Only 1700 L of helium-3 would be needed for this project. Current U.S. production of helium-3 is about 8,000 L per year.

Since we would be going all the way to Pluto it would make sense to include a lander. One way to power the lander is using laser power beamed from the orbiter. Here are results for a possible system, beaming over 30 Wh per pass from a 200 km orbital altitude.

LaserPower

Currently, experiments are taking place in the Princeton Field Reversed Configuration laboratory. Here is the machine in operation at the Princeton Plasma Physics Laboratory:

Experiment

The next step is to build a slightly larger machine to demonstrate fusion. Fusion power generation has been demonstrated in the Princeton Plasma Physics Laboratory Tokamak Fusion Test Reactor and the Joint European Torus but never in a machine using helium-3. A flight engine would follow. Its small size would keep the development and production costs down.

DFD would enable many challenging missions include human exploration of Mars, Europa landers and interstellar probes.

Lunar Topography

If you are sending a spacecraft to the moon, you will be interested in lunar topography. A new function in the Spacecraft Control Toolbox lets you superimpose a height map onto any sphere.

MoonTopoThe function RSHMoon.m gives you the Clementine spacecraft topographic data using a spherical harmonic expansion of the rangefinder data.

 

A new function, PlanetWithTerrain.m, lets you superimpose this data onto a sphere.

 

Continue reading

Fission Powered Lunar Lander

Settlements on the moon, for mining and scientific research, will require routine travel between lunar orbit and the lunar surface. One idea is to use a lunar shuttle with a nuclear fission rocket engine. The hydrogen fuel would come from water on the moon. Fission rockets have twice the specific impulse of the best chemical rockets leading to low fuel consumption. In addition, they would leave the oxygen from the electrolysis of water available for the lunar settlements.

Stanley Borowski of NASA/GRC is co-author of a paper giving the status of nuclear fission rockets:

NTR Technology Development and Key Activities Supporting a Human Mars Mission in the Early-2030 Timeframe

Fission rockets were developed in the 1970’s but the technology was never tested in flight. We used his paper to create a fission rocket. A 3D model based on a drawing the paper is shown below:

NTP

We built the launch vehicle using a single script in the Spacecraft Control Toolbox for MATLAB:

Spacecraft Control Toolbox 2015.1

The script uses a bilinear tangent steering law to estimate the required two way delta-v. The lander flies to 12 km where it meets a freighter. The crew is housed in an Orion spacecraft. The vehicle is shown below:

FissionNL

The landing legs are based on the Apollo Lunar Module. The liquid hydrogen is stored in the 4 spherical tanks. The nuclear thermal engine is hidden by the box to which the legs are attached. The lander lifts the Orion spacecraft and 6000 kg more of payload which would include helium-3 mined on the moon.

The Orion model was created by Amazing3DGraphics. Amazing3D is really good at creating low polygon count models that are useful for simulation and disturbance modeling.

The script and new supporting functions will be available as part of SCT Release v2015.2.

Comparing disturbance models

A customer recently asked us for help comparing the disturbance analysis available in the CubeSat Toolbox with the full model in SCT Professional, for a 3U CubeSat. That is, to compare CubeSatDisturbanceAnalysis to Disturbances. The CubeSat Toolbox uses a simplified model of the spacecraft geometry as a single set of fixed areas, nominally for a rectangular prism. The full model in SCT Pro allows for articulated and rotating bodies built of individual components. The CubeSat Toolbox has a subset of the environment and disturbance functions in Pro but includes drag and optical disturbances in Earth orbit. Given enough options for the two models it should be possible to get the exact same results. We will sketch out our process and discoveries in this post.

Creating a model of a 3U CubeSat in Pro was the easy part, as it is just a single box component, and verifying that the areas match those from CubeSatFaces is accomplished by a trivial command-line printout. Comparing the results of the optical and drag analysis is much more complex as there are so many variables:

  • Atmosphere model: exponential, scale height, J70
  • Solar flux model
  • Earth albedo model
  • Earth radiation model
  • Satellite optical properties (specular, diffuse, absorptive)
  • Attitude pointing (LVLH vs. ECI)

In order to compare the results, we had to call both disturbance models in a script and generate plots overlaying the resulting forces and torques. Here is the code defining the model for SCT Pro.

m = CreateComponent( 'make', 'box', 'x', 0.1, 'y', 0.1, 'z', 0.3,...
'name', 'Core', 'body', 1, 'mass', mass, ...
'faceColor', 'gold foil', 'emissivity', thermal.emissivity,...
'absorptivity', thermal.absorptivity, 'sigmaT', optical.sigmaT,...
'sigmaA', optical.sigmaA, 'sigmaD', optical.sigmaD, 'sigmaS', optical.sigmaS,...
'inside', 0);
BuildCADModel( 'add component', m );

You can see the thermal and optical properties that must be specified as well as the mass and dimensions. The spacecraft is inertially fixed and put into an equatorial orbit, so we would expect zero drag along the z axis and the x/y forces to oscillate at orbit rate. Then to call the disturbance model we generate a low Earth orbit, get the Earth environment and run the analysis, like so:

[r,v] = RVOrbGen(el,t);
e = EarthEnvironment( r, v, jD, d );
hD = Disturbances( 'init', g, e );
[fD,tD] = Disturbances( 'run', g, e, hD );

The EarthEnvironment function is where the guts of the space environment modeling occurs. This includes specifying albedo and radiation constants, calculating the atmospheric density over the orbit, computing the sun vector and solar flux magnitude, checking for eclipses, computing the Earth magnetic field, and correcting the inertial velocity for the rotation of the atmosphere for drag calculations. In the CubeSat toolbox, this data is computed inside the dynamical model, RHSCubeSat. The same steps of creating the model and calling the disturbance function are shown below.

c = RHSCubeSat;
c.mass = 3;
c.inertia = InertiaCubeSat( '3U', c.mass );
[a,n,rho] = CubeSatFaces('3U',1);
c.surfData.nFace = n;
c.surfData.area = a;
c.surfData.rFace = rho;
for k = 1:6
% Radiation coefficients [absorbed; specular; diffuse]
c.surfData.sigma(:,k) = [optical.sigmaA;optical.sigmaS;optical.sigmaD];
end
c.atm = [];
q = QZero*ones(1,size(r,2));
[tC, fC, h, hECI, fr, tq] = CubeSatDisturbanceAnalysis( c, q, r, v, jD );

Let’s look at drag first, as it proved to be the easiest to verify. The primary difference between the CubeSat model and full disturbance model for drag initially was the atmosphere model itself: CubeSat uses the Jacchia 1970 model by default, while EarthEnvironment specifies a scale height atmosphere. The Jacchia 1970 model accounts for changes in density with the time of day, resulting in an orbit rate periodicity; however it is computationally more intensive and not needed in preliminary analysis. The scale heights model depends only on altitude and is very quick. The CubeSat dynamic model already had an option to switch to the scale height atmosphere if desired, so we added that same option to the CubeSat disturbance analysis function. This promptly resulted in a close result between the models for the drag force.

Comparison of the drag force between the CubeSat and full disturbance models for a 3U CubeSat

Comparison of the drag force between the CubeSat Toolbox and SCT Pro disturbance models for a 3U CubeSat

A slight variation remains due to a difference in the transformation between the inertial frame and Earth-fixed frame between the two models. This transformation is used to account for the rotation of Earth’s atmosphere, as drag depends on the relative velocity between the surface and the air. CubeSat uses a fast almanac function, ECIToEF, to compute this matrix for a given Julian date. This model accounts for nutation but not as accurately as TruEarth does in Pro. The EarthEnvironment function in Pro, however, uses a simpler transformation using Earth’s rotational rate about the inertial z-axis, ignoring nutation. This accounts for the nonzero Z force in the CubeSat output, which can be seen to be four orders of magnitude less than the X/Y forces. Both approaches are valid for a preliminary analysis so we accept this small remaining difference.

Producing an equally close comparison for the optical forces unearthed a few bugs in the CubeSat version as well as differences in fidelity that are intentional. First, recall that there are three main contributions to optical forces in Earth orbit: solar flux; Earth albedo – that is, reflected flux; and Earth infrared radiation. The fluxes can be modeled simply as constants, or at higher fidelity by accounting for distance from the radiating body. The full disturbance model accounts for the change in solar flux over the year as the Earth moves in its orbit, which amounts to about 100 W/m2 or 7% of the average flux. The CubeSat environment model was not doing this, but since it was already calling the sun vector function which calculates the needed data, we decided to add it. The sun vector itself can be modeled a number of ways, with CubeSat providing a low fidelity almanac version and Pro a higher fidelity almanac option as well as an option for JPL ephemerides.

Making a temporary change in CubeSat to use the higher fidelity sun almanac provided closer results, but there were still differences in the optical forces. A check on the optical coefficients revealed that Disturbances assumed 100% diffuse reflection for planetary infrared radiation while the CubeSat version assumed 100% absorption. This was result of a misunderstanding of the model when the CubeSat version was created. The intention of the model is to assume 100% absorption, but the radiation has to be reemitted or the temperature of the body would increase to infinity. Hence the diffuse coefficient in the Pro model. So, the CubeSat version’s coefficients were corrected to match. This improved the agreement between the models but still not completely.

Further investigation uncovered a bug in the calculation of the planetary radiation flux and Earth albedo flux. We call this a copy/paste bug, as the distance scaling factor was in the code, but applied to the wrong variable when the CubeSat version was created from the Pro version – so the scaling was unitized out. Correctly applying the scale factor to the flux input (and not its unit vector) to the base solar force function, SolarF, resulted in exact agreement between the two models. The figure below shows the final differences with the CubeSat sun almanac function restored to its default value.

Optical force comparison

Comparison of the optical force between the simplified and full disturbance models for a 3U CubeSat

To summarize, we identified the following subtleties in making a direct comparison between these two disturbance models:

  • Selecting the same atmosphere model, AtmDens2, for both cases
  • Understanding the sun vector model in each case (SunV1 vs. SunV2)
  • Adding the solar flux scaling with the Earth’s distance from the sun to the CubeSat model (1 line)
  • Updating the optical coefficients for planetary radiation in the CubeSat model (to be diffuse)
  • Correcting a bug in the scaling of the Earth albedo and radiation fluxes with altitude in CubeSat
  • Accounting for Earth’s nutation in transforming velocity to the Earth-fixed frame

This provides a great illustration of how careful one needs to be in performing any disturbance analysis, as there are so many subleties in even simple models that must be recorded if results are to be replicated. Every constant, every scale factor, every coefficient, every source of ephemeris needs to be understood.

We were happy to provide the results of our analysis to our customer so that he could decide which models he wants to use in his analysis. This is an example of the technical support we can provide to all our SCT customers; if you have a question, just ask!

Two Stage to Orbit with the Launch Vehicle Toolbox

The Launch Vehicle Toolbox (LVT) combines the Spacecraft Control Toolbox, the Aircraft Control Toolbox and additional libraries of launch vehicle functions and scripts. We’ve used it internally to support a number of contracts.

We have studied two stage to orbit vehicles for a number of years. Our design, known as Space Rapid Transit, uses an aircraft first stage (the Ferry) with a turbo-ramjet engine to take the launch vehicle to 40 km and Mach 6.5. The turbo-ramjet engine is dual fuel using jet fuel for the turbofan and hydrogen for the ramjet. The turbofan core would be based on an existing modern jet engine. A hydrogen fueled turbo-ramjet was tested by MBB for their Sanger launch vehicle. Hydrogen fueled ramjets have been tested by NASA. The SR-71 engine was an early operational turbo-ramjet.

The Orbiter uses a cryogenic hydrogen/oxygen engine to enter the transfer ellipse and then circularize the orbit. The Ferry engine can operate in pure turbofan mode for efficient low-speed operations such as moving the Orbiter between airfields.

TSTODemo.m is a LVT script that models the trajectory from takeoff through circular orbit insertion. The TSTO stack starts on the runway in takeoff mode. When it is moving at the takeoff speed it pulls up and climbs. It transitions from turbofan to ramjet and climbs to the separation altitude and velocity. The simulation works with flight path and heading angles. You can try flying the vehicle in a variety of trajectories. The following figure shows the trajectory up to Ferry/Orbiter separation.

SRTTrajectory

The Space Rapid Transit vehicle is documented in this paper:

Paluszek, M. and J. Mueller, Space Rapid Transit – A Two Stage to Orbit
Fully Reusable Launch Vehicle, IAC-14,C4,6.2, International Astronautical Congress, Toronto, Ontario Canada, October 2014.

The Orbiter starts at the termination condition. The script computes a transfer orbit and the necessary velocity changes to get the Orbiter into an ISS altitude orbit. Part of the delta-V is the drag loss. The Orbiter trajectory is not simulated. The architecture of LVT makes it easy to build these kind of analysis and simulation scripts. Your aren’t locked into a specific design path as can happen with GUI based tools.

For more information go to Launch Vehicle Toolbox for MATLAB.