PSS Awarded Two NASA SBIRs!

We are pleased to share that PSS has been selected for two NASA Small Business Innovative Research (SBIR) awards. The SBIR program enables small business to engage in research or research and development funded by the federal government. The purpose of a SBIR award is to move toward commercialization of a product. It’s a great program that allows small businesses to get a product on the market without putting up as much of their own internal research and development funds.

For a full list of all of the awards from this round, you can go here: https://sbir.nasa.gov/award_firm_list/selection_nid/63001 There, you can see PSS alongside the other winners. More information on the SBIR/STTR program can be found here.

Our first award is for a proposal called “Neural Space Navigator.” This proposal is for research that builds off of our Optical Navigation System (ONS), adding a new capability to the system: Terrain-relative navigation using neural networks. This capability comes at a critical time for NASA’s ongoing lunar exploration program, whose small Commercial Lunar Payload Services (CLPS) landers are scheduled to have their first missions in 2021. In Phase II, we would work with Lockheed Martin (LM). LM created the optical navigation system used on NASA’s OSIRIS-REx mission. Professor Michael Littman of Princeton University will be helping on this contract.

Our second award is for a proposal called “Multi-Megawatt Superconducting Motor for Electric Aircraft.” This proposal is for research toward a powerful superconducting motor for use in partially- and fully-electric aircraft. We are working with Superconducting Systems, Inc. from Massachusetts on this contract. There are some great ideas for ways to make aircraft more fuel-efficient using electric motors (see a NASA report here for some examples). This research will make lighter and higher power motors possible, powerful enough to propel large commercial aircraft, allowing some of the concepts in that report to become a reality.

This work is a spin-off of our nuclear fusion work, in particular our current NASA STTR (with PPPL) to study the effects of plasma pulses on superconducting coils.

We are very excited to be working with NASA on such interesting projects. The next step in the process is contract negotiations, in which the details of the proposed research are hammered out. If the next 6 months go well, these awards can serve as the basis for a Phase II SBIR, which awards significantly more time and resources.

Spacecraft Control Toolbox To The Moon

Today, I will discuss two functions in release 2020.1 of the Spacecraft Control Toolbox (SCT) which can be used to get your spacecraft into a lunar orbit. They are LunarTargeting.m and LunarMissionControl.m. They are demonstrated together in the script LunarMission.m.

LunarTargeting.m produces a transfer orbit that starts at a Low Earth Orbit (LEO) altitude and ends up passing by the Moon with a specified perilune (periapsis of the Moon) and lunar orbital inclination. Its novel approach to the patched-conic-sections model of multibody orbital transfers uses the solution to Lambert’s problem to target a point on the gravitational boundary between the Earth and the Moon. Then it numerically optimizes over points on that surface until the initial velocity of the transfer is minimized. LunarTargeting.m requires the MATLAB optimization toolbox.

LunarMissionControl.m implements a control system which enables a spacecraft to propulsively enter lunar orbit. Like the other control systems implemented in the SCT, it stores its active state and degrees of freedom in a data structure, and accepts a list of commands as arguments. The commands we’ll see used here are ‘initialize,’ ‘lunar orbit insertion prepare,’ ‘align for lunar insertion,’ and ‘start main engine.’

LunarMission.m ties them both together and simulates a spacecraft, down to the attitude-control level. The simulation includes power and thermal models. The spacecraft can be controlled by reaction wheels or thrusters. Forces from the Sun, Earth, and Moon are included. The spacecraft starts on the trajectory returned by LunarTargeting.m, then acts in accordance to commands to LunarMissionControl.m. It takes the spacecraft 4.5 days to get to perilune, at which point it inserts itself into lunar orbit. Let’s take a look!

A figure produced by LunarMission.m. This figure shows the whole trajectory, from Low Earth altitude to a complete orbit around the Moon after insertion.

Take a look at the above figure. This is the entire mission trajectory in the Earth-Centered Inertial (ECI) frame. We can see the initial transfer orbit as the red line. Then it approaches the blue line (the Moon’s orbit), and begins corkscrewing around it after orbital insertion. Let’s look at that insertion in close-up:

One figure produced by LunarMission.m. This figure shows the lunar orbit insertion.

The above figure shows the final part of the trajectory in Moon-centered coordinates. The red line starts as the spacecraft passes the imaginary gravitational boundary between the Earth and the Moon. It falls closer to the Moon, and at its closest point, fires its engines to reduce its velocity. You can’t see it in this figure, but that process is actually resolved on a 2 second timescale. The spacecraft is commanded to point retrograde using a PID controller, waits until it has pointed correctly, then fires its engines for a prescribed duration. If you look closely, you will see that moon has a 3 dimension surface courtesy of the Clementine mission.

Let’s finish this post off with some technical details:

On the far left, you can see the reaction wheel rates. They stay at zero for 4.5 days, as the spacecraft coasts. Then, when the craft is commanded to point retrograde for its orbital insertion, you can see wheels 2 and 3 spin up. Wheel 1 stays near zero; its vertical scale is 10^-16. Then in the center, you can see fuel use. The only fuel use is the insertion burn, so fuel stays constant until 4.5 days in. Less than 2 kg of fuel is used for this example, as the spacecraft is a 6U cubesat. On the right, the components of the body quaternion are displayed. Again, they are constant until 4.5 days in, when the craft is commanded to point retrograde.

I hope you’ve enjoyed this demonstration of how to simulate a lunar mission with the SCT! For more information on our toolboxes check out our Spacecraft Control Toolbox for MATLAB. You can contact us directly by email if you have any questions.

Three-Burn Solutions for Very Large Inclination Change

This is the second of two blog posts which introduce functionality from the Orbit Transfer Module of the Spacecraft Control Toolbox (SCT). The Orbit Transfer Module has lots of tools to allow you to numerically optimize the engine burns that a spacecraft needs to apply to go from some initial orbit to its target orbit, with a minimum of fuel used, time elapsed, or some other metric. You can do this to impulsive burns, continuous (low-thrust) burns, and a special model that splits large impulsive burns into many small impulsive burns.

In this blog post, I’d like to discuss an interesting thing that happens when a spacecraft aims to change its inclination by more than 37 degrees. In real life, of course, this would never happen. This is a truly impractical amount of inclination change. If you were truly faced with a mission that required coverage of orbits that were different by 37 degrees, you would simply launch two spacecraft.

But if you were to explore this hypothetical, you would find an interesting feature emerge. Here we will consider the case that a spacecraft starts in a circular, equatorial LEO and targets a circular LEO which is 49.5 degrees inclined to the equator. The well-known solution is to burn once, at the common node of the initial and target orbits, to change direction by the target inclination:

The 1-burn inclination change solution for 49.5 degrees. This requires a truly impractical amount of delta-V.

As we can see from the above figure, this inclination change requires 6.47 km/s of delta-V, almost the spacecraft’s entire orbital velocity!

But, as the Orbit Transfer Module’s OptimizeElementsImpulsiveSearch finds, there is actually another transfer which can marginally reduce the delta-V required for this inclination change. It finds that the following transfer saves delta-V:

  • Burn prograde to raise apoapsis (and a very slight inclination change)
  • Coast up to apoapsis, where inclination change is cheaper
  • Perform an inclination change
  • Coast down to periapsis
  • Burn retrograde to lower apoapsis (and a very slight inclination change)
The 3-burn inclination change solution for 49.5 degrees. Loops out to high altitude before changing inclination. This also requires an impractical amount of delta-V, but it is a smaller amount.

As we can see from the above figure, this transfer only expends 5.97 km/s of delta-V. While this is still impractical, it is interesting that there exists this other category of optimal inclination transfers which exists for high inclination changes.

It is interesting to note that, for 0 through 37 degree inclination changes, the direct approach is superior. Then, from 37 degrees to 60 degrees, this 3-burn solution produces a smaller required delta-V. Above 60 degrees, the intermediate, high-apoapsis orbit actually exceeds escape velocity so the transfer takes infinite time.

Hohmann Transfer, but Faster: Optimizing for fuel and elapsed time

In this blog post, we are going to introduce you to functionality found in the Orbit Transfer Module of our Spacecraft Control Toolbox. The Orbit Transfer Module has lots of tools to allow you to numerically optimize the engine burns that a spacecraft needs to apply to go from some initial orbit to its target orbit, with a minimum of fuel used, time elapsed, or some other metric. You can do this to impulsive burns, continuous (low-thrust) burns, and a special model that splits large impulsive burns into many small impulsive burns.

The following is an example of a case in which the impulsive burn optimization functions can reveal new and interesting classes of orbit transfer trajectories.

The spacecraft starts in a circular, equatorial low Earth orbit (LEO) and targets a circular, geosynchronous equatorial orbit (GEO). The fuel-optimal trajectory is well known: a Hohmann Transfer, wherein the craft burns once to raise its apoapsis to the target altitude, then at apoapsis it burns again to raise its periapsis to the target altitude. It looks like this:

A Hohmann Transfer from LEO to GEO, which is also the fuel-optimal transfer. Burn once to raise the apoapsis to the target altitude, then again to raise the periapsis.

The craft starts in the blue LEO orbit, then at the big black arrow it burns its engine until 2.42 km/s of delta-V has been applied, then coasts for 5.28 hours on the yellow transfer orbit until it reaches the altitude of the purple dashed, target orbit. Then a final insertion burn until 1.47 km/s has been expended, and GEO has been achieved! Final tally: 3.89 km/s of delta-V has been expended and it took 5.28 hours to get to the requested orbit.

This Hohmann transfer results from optimizing for the minimum delta-V expended, but what happens if you optimize both fuel and coast time? If you care just as much about decreasing the elapsed time by one hour as expending 1 km/s of fuel? The function OptimizeElementsImpulsiveSearch can solve this problem also. Take a look:

In these plots, we’ve told the optimizer that we care about both fuel and time. In the plot on the left, we’ve specified a tradeoff of 1 hour of elapsed time to 1 km/s of delta-V. If the optimizer can decrease the coast time by more than 1 hour at the cost of 1 km/s delta-V, it will do it. And we can see that the optimizer has in fact returned a faster, more delta-V intensive trajectory. Final tally: 5.06 km/s of delta-V has been expended and it took 3.29 hours to get to GEO.

In the plot on the right, we’ve specified a tradeoff of 1 hour of elapsed time to 2 km/s of delta-V, indicating that we care much more about elapsed time than the previous case. And again, we can see that the optimizer returns an even faster, even more delta-V intensive trajectory. Final tally: 6.23 km/s of delta-V has been expended and it took 2.55 hours to get to GEO.

Time tradeoff:
1 hour is worth how much delta-V?
Delta-V expendedTime spent coasting
0 km/s (I don’t care about time)3.89 km/s5.28 hours
1 km/s (I care about time a little)5.06 km/s3.29 hours
2 km/s (I care about time a lot)6.23 km/s2.55 hours
Numerically optimized LEO GEO transfer trajectories, given different priorities between delta-V and time. These 3 points are part of a family of trajectories which are called fuel-time optimal.

We can visually verify the fingerprints of this faster transfer on the plots. The transfer orbit in the Hohmann transfer ends right at the target altitude, but for 1km/s = 1 hour, the transfer orbit extends out beyond this altitude, and for 2 km/s = 1 hour, the transfer orbit extends farther still. This is a hallmark of being a faster transfer orbit. The spacecraft doesn’t actually loop all the way out there; it performs a braking and insertion burn when it gets to the required altitude.

There are real-world scenarios where you’d want to do this. If your spacecraft is sensitive to radiation and you want to minimize the time spent in the Van Allen belts, for example. Or taking a more science-fiction approach, what if you need to urgently resupply or rescue a stranded crew?

Fun with Wavelet Analysis

Not all the new functions in 2020.1 are specific to spacecraft. We have also been hard at work adding new functionality to the core toolbox. Here, I’d like to give an example of one of our new functions for performing a Wavelet analysis.

But what is a Wavelet analysis? Well, you plot the Wavelet transform of a signal when you want to visualize how the frequency spectrum changes in time. The Wavelet transform is a lot like a Fourier transform that you perform at every possible starting point, with an appropriate window function multiplied in so that you’re only looking at a portion of the signal.

But there’s one added wrinkle, because the frequency spectrum at a specific frequency at a specific time doesn’t technically exist. It’s not technically possible to know what the component of a signal at 100 kHz is at 0.5 seconds in, because the frequency spectrum depends on the entire signal. There has to be some trade-off between time resolution and signal resolution. If we look at a very long chunk of the signal, we can nail down its frequency components very well but we can’t see them change quickly. If we look at a very short chunk of the signal, we know precisely when the frequency changes but we can’t tell the difference between two similar frequencies. It’s a trade-off.

Now let’s get to the examples! The new function in 2020.1 is called WaveletMorlet because the specific window function we use is called the Morlet wavelet (A Wavelet transform using a Morlet wavelet is also called a Gabor transform). Here’s the signal that we’ll be analyzing:

A test signal. We want to visualize how the frequency spectrum changes in time.

We already know what we’re going to expect in this example. It looks like there’s a persistent, low-frequency component, then a higher-frequency component whose frequency goes up, peaks around 0.25 seconds, then goes down, and bottoms around 0.75 seconds. Here’s what the Wavelet transform looks like:

A visualization of the wavelet transform of the test signal. Wavelet width parameter: 10

Great! Exactly what we expected. This was a simple case, but you can imagine how this analysis would be useful if there were a greater spread in frequencies, a longer signal, or both.

Now, let’s explore that trade-off that I mentioned earlier. What does the signal look like when you choose a different value on that trade-off? For the above analysis, I kept the default wavelet width parameter of 10. Here’s what it looks like when we prioritize time resolution over frequency resolution by choosing 5, then frequency resolution over time by choosing 25:

For a wavelet width parameter of 5, all that happens is that the signal gets broader in the frequency direction. For 25, what’s happening here? Sure, at 0.25 seconds it appears that the visualization is able to nail down the frequency to a tighter band, but what’s happening to the rest of the image? The answer is that the frequency is changing too fast for this chosen time resolution. The signal doesn’t spend long enough at any given frequency for the algorithm to identify a significant component there.

Thanks, all, for tuning in to this update from PSS, and thanks for this opportunity to get into the nitty gritty of one of our new mathematics functions!

The PFRC on Fusion Shark Tank

The PFRC made an appearance on Dr. Matthew Moynihan’s monthly investor pitch event, the Fusion Shark Tank! This event is a conference call on the first Wednesday of every month in which fusion startups pitch their businesses in a Shark-Tank-like format. It’s good practice, and forces us to think carefully about the business case of our technology.

Luckily, this is one area where the PFRC and DFD excel. The market of high-value portable power is one were the small, clean PFRC provides a clear and unique competitive advantage.

PSS physicist Charles Swanson presented to Fusion Shark Tank on June 5. Take a look below!

NASA SBIR Phase III: Low Energy Mission Planning

Hello PSS fans! This is Charles Swanson, recently minted doctor of plasma physics and PSS’s newest employee. It’s my distinct pleasure to discuss our most recent NASA contract: A Phase III SBIR to integrate our Low Energy Mission Planning Toolbox (LEMPT) into NASA’s open source Orbit Determination Toolbox (ODTBX).

Have you read about the kinds of maneuvers conducted by Hiten and AsiaSat 3 that allowed them to reach orbits that would seemingly be outside their Delta-V budgets? Have you always wondered how one goes about planning such maneuvers?

What about the Lunar Gateway from which NASA plans to stage missions to the surface of the Moon in the coming decades? What kinds of clever orbital tricks can we use to get to, from, and about the Moon with the minimum possible fuel?

That’s what LEMPT is for. LEMPT is a suite of tools written in MATLAB for the planning of low energy missions, the kinds of missions that loop way outside the target orbit of the Moon and deep into chaotic regions of the gravitational landscape. Here’s an example:

This LEO to Lunar Orbit mission takes just one impulsive burn of 2.8 km/s. It loops way outside the Moon and back in for a ballistic capture.

To go from LEO to a low lunar orbit usually takes almost 4 km/s of Delta-V. The maneuver depicted takes only 2.8 km/s. This is the kind of planning capability that NASA would like for their ODTBX. From now until December, we’ll be integrating the LEMPT into ODTBX, where it will help NASA mission planners evaluate all of their options along the trade-off of mission time and Delta-V.

The orbit above doesn’t look anything like the Keplerian ellipse that we know and love. That’s because this is a four-body system, with the Sun, Earth, Moon, and spacecraft all interacting gravitationally. Even the three-body system is famously chaotic: here are two examples of the kind of distinctly weird-looking orbits you can get:

This is a periodic orbit in the Sun-Earth-Spacecraft system. Periodic orbits are rare in such systems.

This orbit starts with only 0.01% more velocity than the periodic orbit but escapes the Earth entirely. This is an example of chaos.

It’s this chaos that the LEMPT leverages to plan exotic and efficient maneuvers.