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.
1 hour is worth how much delta-V?
|Delta-V expended||Time spent coasting|
|0 km/s (I don’t care about time)||3.89 km/s||5.28 hours|
|1 km/s (I care about time a little)||5.06 km/s||3.29 hours|
|2 km/s (I care about time a lot)||6.23 km/s||2.55 hours|
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?