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!
In the “good old days” the only people worried about rendezvous were those designed space missions with crews. ISS established the need for robotic rendezvous and docking on a regular basis.
Orbit dynamics can be complex. If you are looking at rendezvous with any other spacecraft in a very different orbit you can start with Lambert’s Time-of-Flight algorithm. Given initial velocity and position vectors, and desired final position and velocity vectors and time of flight, it will give you the initial impulse velocity change needed to rendezvous. There are numerous formulation as it is complex math problem.
If you happen to be close to your target you can formulate your orbits as a relative orbit problem with Hill’s equations, shown below in state space form.
is the orbit rate of the target spacecraft. , and are the position of the “chase” spacecraft in the Hill’s frame. is the control acceleration. You want to reduce the positions and velocities to zero. This can be done with a Proportional Derivative (PD) Controller, or with a Linear Quadratic (LQ) Controller. If your chase and target spacecraft have GPS it is relatively easy to find this state vector in the above equation. A PD controller will ignore the coupling in the above equations while the LQ will accommodate the coupling.
It is interesting to look at the gain matrices for the two cases and the corresponding eigenvalues. We tweaked the PD to make its position gains close to that for the LQ. The PD is designed for a damping ratio of 1. The eigenvalues are identical. The cross-axis gains are small, but non-zero.
The results are very close. The PD has no overshoot, as expected. The LQ is slightly faster but has some overshoot. Both get the chase spacecraft to the target in a few minutes, assuming, of course, that you have the acceleration capability shown in the plots.
Both are linear controllers. You can approximate a linear controller with thrusters by using pulse width modulation. An issue will be the minimum impulse bit of the thrusters, that will lead to a minimum velocity and position error that can be achieved.
This script is included in the Spacecraft Control Toolbox 2020.1 coming soon!
Many small satellites are launched from the ISS or near the ISS by one of the transfer vehicles. A new function in the Spacecraft Control Toolbox 2020.1, coming in May, allows you to visualize your spacecraft near the ISS. Here is an example. You can also display a trajectory.
It is sometimes necessary to change your orbit semi-major axis, ascending node and inclination with a low-thrust engine. It is easy to do, as long as you can point your engine along orbit normal and tangential to the orbit.
It is easiest to see how this is done by looking at the Gauss’ Variational equations, simplified for small eccentricity.
I is inclination, is semi-major axis, is the gravitational parameter, is argument of perigee, is true anomaly, is ascending node. and the orbit tangential acceleration and is the orbit normal acceleration.
The resulting simulation is shown below. Mode 0 is semi-major axis change, Mode 1 is ascending node change, Mode 2 is inclination change and Mode 3 is off. It is best to change inclination and ascending node at the highest semi-major axis. You should change ascending node at the lowest inclination. The burns are done where the rate of changes are higher. Some change in inclination and ascending. node will happen when the other is being corrected.
The script for this simulation with the controller is part of the Spacecraft Control Toolbox Release 2020.1 coming in May.
A popular way of launching a small satellite is to bring it up on an International Space Station resupply mission. The Spacecraft Control Toolbox has functions to help you animate the orbit of your spacecraft near the ISS. A function, ISSOrbit, generates the orbital elements for the ISS. ISSOrbit generates Keplerian Elements from the latest 2-line elements. We use the function CoplanarOrbit to create an orbit 50 m below the ISS. There are no disturbances and the gravity model is for a point mass Earth.
DrawSpacecraft.m is a function that will draw any number of spacecraft in the viewer. This is the ISS and our, very small, NanoSatellite. The MATLAB camera controls allow you to zoom in or rotate the view. The view is with respect to the first satellite entered in the argument list, which in this case is the nano satellite.
DrawSpacecraft also does animation and will create an avi file. You can see the animation on our YouTube Channel or by clicking the video below. We converted the avi file to an mp4 file using a movie converter.
The script is an m-file that you can download, just to view, here.
We developed a round trip mission to Mars using Direct Fusion Drive. Key parameters are:
Specific power of 1.2 kW/kg
Exhaust velocity of 110 km/s
40 MW engine
Payload of 55 MT out, 40 MT return
Outward leg 128 days
Inward leg 110 days
Stay on Mars 650 days
The following plot shows the trajectory. Some additional time would be needed to enter and exit the Mars and Earth’s orbit. That could be shortened by using a nuclear thermal engine tug.
The payload is based on the NASA Deep Space Habitat. It could be replaced by a less massive habitat and a lander. Two spacecraft, one including a lander, is another possibility. A dual spacecraft mission would enhance safety.
This mission plan has the DFD decelerating the spacecraft and going into Mars orbit. Some time could be saved using aerodynamic braking. The mass of the aeroshell would need to be included as part of the “engine” mass.
It may from time to time necessary to damp nutation with thrusters on a momentum bias spacecraft. For example, nutation can happen when you transition from stationkeeping mode, which uses thrusters, to normal mode, in which you use low control authority actuators, such as magnetic torquers, for control.
We’ve written a script that simulation a momentum bias spacecraft. Let’s show the results.
The spacecraft body rate is 0.01 rad/s. This is much greater than you will ever see on your own spacecraft. The peak roll angle is about 18 degrees! The last plot shows the thruster control. In this simulation we don’t apply any control so the line is flat.
All you need is one thruster pulse, properly timed, to drive the x angular rate to zero. You must time it properly so as not to not leave a roll error. What we do is measure the peak angular rate, compute the pulsewidth needed to drive the rate to zero, and turn on the thruster when the roll angle is zero and the nutation rate is at its peak with the appropriate sign. The following plot shows the results.
The results aren’t perfect, as they would not be operationally. We did both simulations with the same Spacecraft Control Toolbox http://www.psatellite.com/products/sct/ script. This is a link to the m-file, saved as a zip file.
You won’t be able to run this without our toolboxes but you can see how we implemented “manual” nutation control. This script, and the new function RHSGyrostat.m will be available in SCT 2020.1 coming soon!