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.


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.

Elements for a 2000 satellite constellation? No problem!

A customer recently asked if we had any constellation design tools in the toolbox, which at that point we did not. This customer had been tasked with simulating a constellation of nearly 2000 CubeSats, and had available only a GUI-based tool that required him to enter each satellite’s elements individually. He was able to clone them, but still had to open up each one to edit the elements. This means he first had to make a table of the elements he wanted, then painstakingly enter them. In the Spacecraft Control Toolbox, creating these elements and simulating or visualizing the satellites is as easy as writing a for loop.

Our workflow using the SCT is mostly programmatic, using functions and scripts. Functions such as El2RV make it easy to go from Kepler elements to a Cartesian state for initializing a simulation. In just a few hours, I was able to write a function to generate elements for a Walker-Delta constellation of any size, and plot the results; to examples are shown below.

The WalkerConstellation.m function will be in our 2015.1 release, due out in a week. It can generate elements for a classic rosette or a polar star. If there is sufficient customer interest we may expand the constellation design tools available in the toolbox!

%   Form:
%   elements = WalkerConstellation( t, p, f, inc, sma, doStar )
WalkerConstellation( 720, 24, 2, 65*pi/180, 6800 )



% Create a polar star similar to Iridium
WalkerConstellation( 66, 6, f, 86.4*pi/180, 7150, true );



Full function header:
%   Compute orbital elements for a Walker constellation.
%   Generates a delta constellation be default, also called a rosette. For
%   a star geometry, pass in true for the optional doStar parameter. The
%   notation is i:n/p/f; f, the relative spacing, is an integer which can
%   take any value from 0 to (p-1).
%   Real-life examples include the Galileo, a delta geometry, and Iridium,
%   a star geometry.
%   Since version 2015.1
%   Form:
%   elements = WalkerConstellation( t, p, f, inc, sma, doStar )
%   -----
%   Input
%   -----
%   t         (1,1)    Total number of satellites
%   p         (1,1)    Number of orbital planes
%   f         (1,1)    Relative spacing between satellites in adjacent planes
%   inc       (1,1)    Inclination (rad)
%   sma       (1,1)    Semi-major axis (km)
%   raan      (1,1)    RAAN spread, optional. The default is 2*pi.
%   ------
%   Output
%   ------
%   elements   (6,t)    Kepler elements
%  Reference: Larson and Wertz, Space Mission Analysis and Design, second
%  edition (1996), "Constellation Patterns", p. 191

SolidWorks Interface in SCT 2015.1

Version 2015.1 will have a new DXF file format exporter to export CAD models built in the Spacecraft Control Toolbox into SolidWorks. The following figure shows the Lunar Lander model in the Spacecraft Control Toolbox CAD window.


Exporting requires just two lines of code:

g = BuildCADModel( 'get model' );

Rodger Stephens of Prism Engineering provided SolidWorks models from the DXF file. The file opened in SolidWorks with 7 parts creating an assembly called LunarLander-1.


Each part contains planes, sketches, and surfaces.


The Spacecraft Control Toolbox has always had DXF import capability but now it can export in a format that is supported by most CAD packages. This will speed the process of going from conceptual designs in the Spacecraft Control Toolbox to detailed designs in SolidWorks and other CAD packages.

Patched Conics

Patched conics are a useful approximation when dealing with orbits that are under the influence of multiple planets or moons. The idea is that only one planet’s or moon’s gravitational field is active at any one time. For example, at the start of a mission from Earth orbit to the Moon, we assume that only the Earth’s gravity acts on the spacecraft. For each planet or moon we define a sphere of influence where that body’s gravity is greater than all other sources. In the Earth/Moon system the Moon’s sphere of influence extends to about 66,000 km from the moon.

A new function in the Spacecraft Control Toolbox Release 2015.1 is PatchedConicPlanner.m. It allows you to explore trajectories in a two-body system. The following figure shows the trajectory of the spacecraft and the orbit of the Moon in the Earth-centered frame. The trajectories assume that the spacecraft is only under the influence of the Earth. The spacecraft is in an elliptical orbit designed to have its apogee just behind the Moon.


The next figure shows the spacecraft in the Moon centered frame. The blue line is the trajectory of the spacecraft assuming that the Moon was not there. The green line is the hyperbolic trajectory of the spacecraft starting from the patch point computed assuming the Earth’s gravity had no influence on the trajectory. Notice the sharp turn due to the Moon’s gravity. The function returns the Moon-centered orbital elements along with other useful quantities.


The following shows a closeup of the trajectory. The miss distance, as expected, is less for the hyperbolic trajectory. The plot clearly shows a good place for a delta-v maneuver to put the spacecraft into lunar orbit.


This function allows you quickly explore the effect of different patch points and to try different spacecraft transfer orbits. While a “high-fidelity” analysis requires numerical orbit propagation that includes the Moon, Sun and Earth’s gravitational fields, PatchedConicPlanner.m, let’s you generate good starting trajectories for mission planning.

Moon Lander Design

Our last post showed the mission planning script for our lunar lander. The next step was to layout the lander. We did this using the BuildCADModel function in the Spacecraft Control Toolbox. The propulsion system is designed to meet the requirements of the mission plan. We use six 1 N HPGP thrusters for attitude control and one 220 N thruster for orbit maneuvers and landing. We have two HPGP tanks for the fuel. There are two cameras. One is used as a star camera for attitude determination and navigation and the second, which is articulated, is used for optical navigation, descent navigation and science. The IMU and C&DH box can bee seen in the drawing.


The solar array has two degrees-of-freedom articulation. The high gain antenna is also articulated. We adapted the landing legs from the Apollo Lunar Module. The thruster layout is shown in the following figure and is done using the ThrusterLayout function in the toolbox.


We get full 6 degree-of-freedom attitude control and z-axis velocity change control. We use the 220 N engine as the primary engine for landing but can also use four of the 1 N thrusters for fine terminal control.

We are working on the science payload for the mission. One experiment will be to mine helium-3 from the surface. Helium-3 would be a fuel for advanced nuclear fusion power plants and nuclear fusion propulsion systems.

Landing on the Moon

There is a lot of interest in lunar landing missions for both scientific exploration and commercial purposes. Commercial applications might include mining helium-3 for future nuclear fusion power plants on earth and mining water for rocket fuel.

The Spacecraft Control Toolbox makes it easy to do preliminary planning for lunar missions. In this blog we present a single MATLAB script that takes a spacecraft from a low Earth parking orbit to the lunar surface! Here is the final segment, the descent to the moon.


We ended up with a 30 kg dry mass for a spacecraft that can use an ECAPS 220 N HPGP thruster for delta-v.

The published script can be found here:

Lunar Mission Planning as a published MATLAB script

You can also send us an email to find out more about our Lunar Mission Design Tools.

Spacecraft CAD Design in the Spacecraft Control Toolbox

AutoDesk Inventor and SolidWorks are powerful software packages for the computer-aided design of spacecraft. Ultimately you need to use one of those packages for the mechanical design of your satellite, but what about the preliminary design phase when you are still determining what components you even need? The CAD software in the Spacecraft Control Toolbox can provide you with a valuable tool to do your conceptual layouts and early trade studies, and the same model can be used as the basis for disturbance analysis in later design phases.

A CAD model in SCT is built in a script which allows you to build your models algorithmically. You can call design functions, use for loops and revision-control your source code. For example, within the script you can do an eclipse analysis and compute the battery capacity. This number can generate the volume of your batteries which you can then use to size your spacecraft.

The function BuildCADModel provides the model-building interface. The CreateComponent function is used to generate the individual components using parameter pairs as arguments. Components are grouped into bodies to allow for rotation and articulation. A GUI displays your finished model and allows you to visualize it in 3D. You then store your finished models as mat-files. Our disturbance model uses every triangle in your model for disturbance analysis.

The example figure shows a solar sail design, with the spacecraft bus in the middle. BuildCADModel allows you to group components into subsystems as on the left-hand side, which can then be highlighted using transparency.


The figure below shows the BuildCADModel GUI which allows you to verify the body and component properties.BuildCADModel-Vehicle

There are many examples of spacecraft models in the SCT to help you get started, and a lengthy chapter in the User’s Guide discussing the finer points of component location, orientation, and physical properties such as drag and optical coefficients. Your CAD model essentially functions as a database for your entire spacecraft model!

Why Use Princeton Satellite Systems’ MATLAB Toolboxes?

Almost all aerospace organizations have extensive libraries of software for simulation, design and analysis. Why then should they use our MATLAB toolboxes?

I’ve been working in the aerospace business since 1979. My experience includes:

  1. The Space Shuttle Orbiter Dynamics Analysis
  2. The GPS IIR control system design
  3. The Inmarsat 3 control system design
  4. The GGS Polar Platform control system design
  5. The Mars Observer delta-V control system
  6. The Indostar-1 control system
  7. The ATDRS momentum management system
  8. The PRISMA formation flying safe mode guidance

Continue reading

Optical Navigation for Geosynchronous Transfer Orbits

Optical navigation, using the Earth’s chord width and angles between nadir and stars, is an alternative to GPS based navigation for autonomous spacecraft. The Optical Navigation System, developed under a NASA contract, is well suited for this application.

In the Spacecraft Control Toolbox, we provide an easy-to-use demo script in the 2014.1 release that shows you how to implement optical navigation. The system uses Unscented Kalman Filters (also known as sigma point filters) with non-linear dynamics and measurement models.

This demo uses our new UKF functions shown below:

ukf.t = t;
ukf = UKFPredict( ukf );
ukf = UKFUpdate( ukf );

ukf is a data structure that includes all filter information. Measurements are passed as data structures to UKFUpdate which have pointers to the measurement functions. In this way, any type of measurement can be used in the filter and introduced at any time.

The following plots show some results from the script. The first shows the orbit and the estimated orbit which are essentially the same.


The second shows the position errors. Of course, actual errors would depend on the accuracy of the sensors, particularly the Earth sensor. Great care needs to be taken when setting up the UKF parameters. As you can see, the largest errors are at perigee and if the UKF parameters are not set properly, the filter might think a hyperbolic orbit was a valid solution!


Check out our Spacecraft Control Toolbox page for more information on the 2014.1 release! More information about optical navigation can be found on our Deep Space Navigation page.

Simulating Magnetic Hysteresis Damping

CubeSats have caused a renewed interest in magnetic control of satellites, and passive hysteresis damping in particular. Modeling actual hysteresis rods on a satellite is not trivial, and generally requires empirical data on the properties of the rods selected. Our newest CubeSat simulation demonstrates damping using rods in LEO. A permanent magnet is modeled using a constant dipole moment, and we expect the satellite to align with the magnetic field and damp. We evaluate the results by plotting the angle between the dipole and the Earth’s magnetic field and the body rates.

First, let’s verify the magnetic hysteresis model in the toolbox using the bulk material properties in orbit. We use a dipole model of the Earth’s magnetic field. The nice hysteresis curves below confirms that we are computing the derivatives of the magnetic field correctly in the body frame, which requires careful accounting of rotating coordinates. Also we stay within the saturation limits which means our magnetic flux derivatives are correct too.

Hysteresis curves from simulating magnetic hysteresis in orbit

Hysteresis curves from simulating magnetic hysteresis in orbit

We will assume the rods are 1 mm radius and 95 mm length, with rods placed perpendicular to each other and the permanent magnet. Three rods are used per axis. The apparent rod parameters are taken from the literature. The actual rods will not reach saturation while in orbit, so we will see a minor loop.

Minor loops from damping rods

Minor loops from damping rods using apparent properties

The rods produce only a small amount of damping per orbit, so we have to run for many orbits or days to see significant damping – in some passive satellites, the total time allotted for stabilization is two months! In this case we test the rods’ ability to damp the torque induced by turning on a torque rod with a dipole of 1 AM2 and allowing the CubeSat to align itself with the magnetic field, starting from LVLH pointing.

Damping in LEO using hysteresis rods

Damping in LEO using hysteresis rods

Simulating the rods is time-intensive, with a timestep of about 4 seconds required – which makes a simulation of several days on orbit take several minutes of computation. Once performance of the rods has been verified, a simple damping factor can be substituted.

This new simulation along with the functions for hysteresis rod dynamics will be in the new version of our CubeSat Toolbox, due for release in June!


  1. F. Santoni and M. Zelli, “Passive magnetic attitude stabilization of the UNISAT-4 micro satellite”, Acta Astronautica,65 (2009) pp. 792-803
  2. J. Tellinen, “A Simple Scalar Model for Magnetic Hysteresis”, IEEE Transactions on Magnetics, Vol. 34, No. 4, July 1998
  3. T. Flatley and D. Henretty, “A Magnetic Hysteresis Model”, N95-27801 (NASA Technical Repoets Server), 1995