Power went down when Hurricane Isaias moved in. Fortunately our customer had a SunStation solar power system with Lithium battery backup. Unlike other solar systems, this system has a transfer switch to disconnect the solar system from the grid so that the solar power system can power the house when the grid is down. The batteries provide enough power to keep critical systems going when it is really cloudy or at night.
You can see the system in operation here. The first shows the system when the solar power is insufficient to power the house.
The following shows the system with enough solar power to charge the battery and power the house.
Even on a cloudy day, you usually get enough solar power to keep the house running. The 0.2 kW load includes lighting, refrigerator, WiFi and other loads. This system has 14.4 kWh of storage, so it could run the house, without solar, for 72 hours.
For more information check out our SunStation page.
Over 80 new functions and scripts were added in Version 2020.1. Updates were made to dozens of existing functions to improve their performance and expand their applications. Built-in demos and default data structures were added to many more functions.
In the Spacecraft Control Toolbox, we added new tools for orbit control. The figure below shows a low thrust orbit raising starting from the ISS orbit and proceeding to a higher inclination, higher semi-major axis orbit. The controller also can change the ascending node.
A new function, was added for animating spacecraft. The image below shows two spacecraft in formation.
A new function that provides the Keplerian elements for asteroids was also added.
Optical navigation demonstrations for Earth/Moon missions were added. this shows the centroid and lunar disk. The system uses a high dynamic range sensor that can see stars and the moon at the same time.
For operations people, a demonstration of one pulse nutation damping was added. Both roll angle and angular rate are reduce nearly to zero with one thruster firing.
The Aircraft Control Toolbox has many new features specifically added to support electric airplane development. This includes a new propeller efficiency model.
Please contact us for more information! If you have purchased our toolboxes or updated your maintenance in the last year, the update is free!
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.
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.
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!
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:
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.
Princeton Satellite Systems has been in a leader in renewable energy with its SunStation home solar power system with battery backup. We introduced this product back in 2013. SunStation has lithium-ion phosphate batteries, the most stable and reliable batteries for home use. The core of the system is the Outback Inverter that seamlessly switches from grid power to internal power.
The solar system in the installation produces 7.3 kW of power, much more than the house needed for electric power including charging a Nissan Leaf and Toyota Prius Prime. The heating and air conditioning system was nearing its end-of-life so we decided to replace it with a geothermal heat pump. A heat pump is essentially an air conditioner that can both reject heat to a source and absorb heat from a source. The problem with both is that when the outside temperature is high, for rejecting heat, and low, for absorbing heat, the system loses efficiency. Modern air-source heat pumps are very efficient but do need backup resistance heating in some climates.
A ground source heat pump, or geothermal heat pump, uses the ground as the medium for absorbing or rejecting heat. The option we chose, due to land constraints, is to have two wells several hundred feet deep as the source. Alternatives are trenching, or a pond if you have one in your yard. The ground is always at around 50 deg F. The system was sized so that it rarely, if ever, needs resistance heating.
The geothermal system, which is made by WaterFurnace, was installed by Princeton Air. No changes to the SunStation were needed. The core geothermal system is shown below. The valves to the ground loops are in the foreground and the geothermal system is on the left.
The lines that run to the outside ground loops are shown below.
The system has a preheater for the (still gas) hot water heater. The gas water heater was less than a year old, so it didn’t make sense to replace it. The preheater is an electric hot water heater that does not have the heating coils connected.
The SunStation is shown below. The Outback inverter is on the bottom left. The boxes on top provide arc protection, which is now included in the inverter. The batteries on on the right and the battery management electronics between the inverter and the battery cabinet.
The well digging was quite a project. This picture shows the drilling rig.
This second picture shows the yard after the drilling was complete. Drilling took three days total.
The following system shows the SunStation with geothermal in operation. The Prius Prime is charging which is most of the load. The system is still sending considerable power to the grid. On average the house powers itself and two other houses.
Geothermal, with solar and battery backup is the ideal solution for new homes and for renovations to existing homes. There is no reason to even have a gas hookup anymore. Contact us at SunStation for more information
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:
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)
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.
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:
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?
Time spent coasting
0 km/s (I don’t care about time)
1 km/s (I care about time a little)
2 km/s (I care about time a lot)
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?
Yes, that is the name of the very famous computer game.
In our last blog post we talked about optical navigation for lunar missions. Optical navigation is also very valuable for asteroid missions. It is being used today on OSIRIS-REx. The system we developed can be used anywhere in the solar system without, hopefully, too much attention from the ground.
Now that you’ve decided to go to an asteroid, where are they? As it turns out there is a fabulous website with a downloadable database of asteroids http://naic.edu/~nolan/astorb.html. You can download a file with thousands of asteroid.
In Version 2020.1 of the Spacecraft Control Toolbox, we’ve added a function to plot the asteroids. It reads the file and returns the orbital elements, name, number and epoch. Here are two examples of asteroids in motion.
Ceres is the most famous asteroid. You may find one named after you! If you want the bigger picture, here is a second plot with 1000 asteroids. The circles are the orbits of Earth and Jupiter. The function will propagate all the asteroids you select if you don’t request any outputs.
There is great interest in lunar missions. The U.S. plans to land astronauts on the moon in this decade. Several commercial companies are working on landers. Many other national space programs are working on their own landers and rovers.
As with all spacecraft, you need to know where you are. The traditional way is to use a communications link from the ground to get range and range rate (via Doppler shift.) This works well but you need to collect data over a long period of time to get an 3-dimensional fix.
Recently, NASA discovered via the Magnetospheric Multiscale Mission (MMS), that GPS could be used at altitudes higher than the GPS altitude, and maybe all the way to the moon!
Princeton Satellite Systems developed an Optical Navigation System for NASA as part of an SBIR project. It uses two cameras. One is a navigation camera mounted on a 2-axis gimbal that looks for nearby planets or asteroids. A second camera points out of the orbit plane just looking at the star field. The navigation camera has sufficient dynamic range so that it can image a planet or moon and still see stars. The whole system works as a sextant, that has been used by mariners for hundreds of years. The Apollo astronauts used a sextant for backup navigation. Our system automates the process so that it is fully autonomous. Our simulations for the SBIR were for deep space missions, like simulated NASA Messenger and New Horizons spacecraft, and for communication satellites.
Recently we’ve customized the system to lunar missions. The following images are from a MATLAB script that simulates a transfer from the Earth to the Moon. The first is from the star camera pointing out of the orbit plane. The numbers are the star id from a list and don’t correspond to numbers in the Hipparcos Catalog which is used for the star simulation.
The second is the navigation camera, that points at the moon. The star moves as the relative angle changes. The circle around the moon is its disk.
The third shows the trajectory. It starts from behind the Earth. A lunar orbit insertion is done when the spacecraft reaches the moon.
Here is the spacecraft in lunar orbit.
The simulation runs until the spacecraft reaches the moon. The following video shows the simulation in action.
The simulation uses functions coming out in the 2020.1 release of the Spacecraft Control Toolbox. Contact us for more information!
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:
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:
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!