Mission Planning Updates, Part 1: Trajectory

 

Last semester, the Cislunar Explorers team completed our latest and most successful trajectory plan. We have done work on this before, but the planned launch date given to us by SLS has changed several times, necessitating a re-run. Because the launch date of SLS is nearly two years away and still subject to change, it is possible that we may need to regenerate our trajectory again based on a new launch date in the future. Each time we need to do so, we take the opportunity to improve the new trajectory based on lessons learned from working the previous launch date.

There is more to mission planning than just a “bus schedule” of where the spacecraft will be and when. Within the next week, we will have several follow up posts about some different examples, including orbital debris assessment, power budgeting, and thermal analysis. But first, an examination of some of the challenges facing our trajectory plans, and a description of the current trajectory.

Trajectory Challenges:

In the past, we have designed our trajectories semi-manually, using STK software with the Astrogator module and its built-in targeter for individual maneuvers, after manually planning out what we want from each maneuver and inputting initial guesses for optimization by the software. Now, we have improved on this by writing monte carlo scripts for STK using its MATLAB interface, allowing us to automatically generate arbitrary numbers of slightly perturbed trajectories. In this way, we can see how robust our trajectory is with regards to e.g. deployment by the Interim Cryogenic Propulsion Stage (ICPS) of the SLS in random directions.

Another challenge in designing our trajectory is that our electrolysis propulsion thruster does not behave exactly like either a typical chemical or chemical thruster. Our spacecraft produce many small thruster pulses over time, instead the constant steady thrust of an electric thruster or the large, nearly impulsive burns of a chemical thruster. In practice, the most realistic way to design trajectories using this thruster has been to average out its thrust over a long period of time and treat it like an electric thruster.

Finite burns are more challenging to calculate than impulsive burns, and more difficult to target in the STK software. The best way we have found to do this is to start by implementing an impulsive burn that does what we need, then having the software “seed” a finite burn based on that. We also need to avoid any maneuvers that require an actual impulsive burn, such as orbit injections with a sudden and large DeltaV, because our thruster is not capable of doing so. To avoid this and still achieve lunar orbit, we need to set up a ballistic capture using only lunar flybys and low-thrust course correction maneuvers over the days or weeks in between lunar encounters.

Current Trajectory:

The current trajectory begins with deployment from the SLS ICPS at the first available “bus stop,” mere hours after launch. The reason for this is that our spacecraft need time to perform their separation from each other and reach their desired stable 6 rad/s spin before the mission can begin. With this deployment, we ride out the inner Van Allen belt while powered off inside the ICPS, but the spacecraft must survive the outer Van Allen belt by itself. Fortunately, the Raspberry Pi flight computer is quite tough when it comes to radiation, and we expect it to survive easily.

When our spacecraft our deployed from the ICPS, they are on course for an unavoidable lunar flyby, between 5-6 days after deployment depending on when exactly deployment occurs. These few days include the most time-sensitive maneuvers of the mission, because we need to tweak this lunar flyby to prevent the resulting gravity slingshot from ejecting our spacecraft from the Earth-Moon system. This is obviously key to mission success–for spacecraft called the “Cislunar Explorers,” being hurled out of cislunar space entirely would be embarassing!

Once that is avoided, the spacecraft will be on a trajectory that takes them to about one million kilometers away from Earth, several times farther than the Moon is, but staying within Earth’s gravitational influence the whole time. Course corrections over about a month will guide the spacecraft to a second lunar encounter, one which we will have more control over.

We are working on being able to capture into lunar orbit directly from that second encounter, but currently, we require using it as a second flyby and gravity assist, to set up a third and final encounter. At this encounter, and several months after launch, our spacecraft will arrive in a highly elliptical orbit around the Moon.

Over the following months, the spacecraft will spiral its orbit down closer to the Moon for the dual purpose of claiming the CubeQuest prize by getting close enough to it, and preparing for the eventual disposal of the spacecraft. For the end of the mission (up to one year after the launch), the spacecraft will continue to lower its periapsis until it intersects with the far side of the Moon, ensuring an impact far from any historic landing sites.

Upcoming Work:

Our current trajectory is sufficient, and better than past efforts, but not yet optimal. Every gram of propellant we can save from needing to achieve lunar orbit is another gram that can be used for stationkeeping to increase the longevity of the spacecraft, as well as margin in case things don’t go as expected. Therefore, we are working on optimizing the trajectory this semester.

We have already tweaked our approach for the first flyby to setup a more favorable approach for the second lunar encounter. This semester, we will work on attempting to capture into lunar orbit on that second encounter, eliminating the need for a third, and the propellant cost that comes with it.

We will also re-run our existing mission analyses based on that more optimal trajectory. We have performed a number of mission-related simulations, and the code used for most can take arbitrary trajectory inputs , so they can be re-run at will. Expect posts coming in the next few days specific to:

  • Micrometeoroids and orbital debris (MMOD) damage assessment, including the expected odds of a mission failure from MMOD impact (<<1%).
  • Power generation, consumption, and budgeting for the mission, including the maximum battery depth of discharge expected during eclipses.
  • Thermal analysis, coating, and heating strategies to keep the spacecraft electronics cool and the water liquid.

 

3 thoughts on “Mission Planning Updates, Part 1: Trajectory

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s