Idea The Aldrin Cycler?

Dantassii

HUMONGOUS IMS shipbuilder
Joined
Jul 14, 2012
Messages
508
Reaction score
20
Points
33
I thought that Dr Aldrin came up with a cycle system that didn't require ANY delta V once the vehicle was in the intended orbit.

https://en.wikipedia.org/wiki/Mars_cycler

Note that only some of the cycles in this article require any sort of delta V or even gravity assists once the cycler is in its final orbit.

I have no idea if these orbits can be put into Orbiter, but it would make for an very neat scenario to see if people could take the DIV or one of the XR craft with default settings from the Earth's surface to ISS, then after refueling there connect up with the cycler to Mars, and after refueling there, and a nice trip to Mars consuming no on-board resources, land on Mars.

I think I would find it interesting to actually BUILD a cycler station using IMS and a fleet of XR5s. Would you build it near Earth and then inject it into its final orbit.. or would you build it in its final orbit (which would take either a whole lot of XR5s at the same time, or a LONG LONG TIME to build).

Dantassii
HUMONGOUS IMS shipbuilder
 

Mandella

Space Cultist
Donator
Joined
Apr 5, 2008
Messages
368
Reaction score
0
Points
0
First thing, as someone who is primarily an Orbiter end user (wish I could contribute more, but time and ability have always been in short supply) it makes me really really happy to see projects like this moving forward. I wish I could do more than just say "I'm looking forward to playing with this!" to encourage this and other fascinating projects to completion.

As a thought, assuming that a correction has to be made, would it be possible for the correction to be accomplished by a low thrust device, say ion or even solar sail?
 

jedidia

shoemaker without legs
Addon Developer
Joined
Mar 19, 2008
Messages
10,892
Reaction score
2,141
Points
203
Location
between the planets
As a thought, assuming that a correction has to be made, would it be possible for the correction to be accomplished by a low thrust device, say ion or even solar sail?

Technically yes, but well outside the scope here. I have no experience writing autopilots, you'd have to ask somebody like RisingFury for that. All I'll be able to do is offer a solution that will keep the cycler on trajectory by "cheating", i.e. just set its position to where it's supposed to be, bypassing all the maneuvering and thrusting that would be required to actually keep the object on trajectory. It's a bit similar to what orbiter already does with complex orbits such as mercury, which are kept on track purely based on the knowledge of where they are supposed to be at a given point in time, because calculating mercury's trajectory precisely would require orbiter to take general relativity into account.

Note that only some of the cycles in this article require any sort of delta V or even gravity assists once the cycler is in its final orbit.

I think you're interpreting the table incorrectly. I think "Requires minimal ballistic correction" means that they require a lot less correction than the others. I didn't find any hints of a maintenance-free cycler, much less an aldrin cycler, and I think Keith_Gs algorithm would have found one if it existed. It would also be in disagreement with the general description in the article:

A cycler trajectory encounters two or more bodies on a regular basis. Cyclers are potentially useful for transporting people or materials between those bodies using minimal propellant (relying on gravity-assist flybys for most trajectory changes), and can carry heavy radiation shielding to protect people in transit from cosmic rays and solar storms.
(emphasis mine)
 
Last edited:

Mandella

Space Cultist
Donator
Joined
Apr 5, 2008
Messages
368
Reaction score
0
Points
0
Technically yes, but well outside the scope here. I have no experience writing autopilots, you'd have to ask somebody like RisingFury for that. All I'll be able to do is offer a solution that will keep the cycler on trajectory by "cheating", i.e. just set its position to where it's supposed to be, bypassing all the maneuvering and thrusting that would be required to actually keep the object on trajectory. It's a bit similar to what orbiter already does with complex orbits such as mercury, which are kept on track purely based on the knowledge of where they are supposed to be at a given point in time, because calculating mercury's trajectory precisely would require orbiter to take general relativity into account.

Oh I understand that -- I was actually thinking about the "real thing." And of course as a guide to modeling the cycler in Orbiter. Big honking chemical thrusters or smaller ion engines or a pretty sail...
 

Keithth G

New member
Joined
Nov 20, 2014
Messages
272
Reaction score
0
Points
0
I thought that Dr Aldrin came up with a cycle system that didn't require ANY delta V once the vehicle was in the intended orbit.

Until a few weeks ago, I had never heard of an Aldrin Cycler so I don't regard myself as an expert on the subject. However, I did come across the following 1993 paper co-authored by Aldrin on the subject :

https://engineering.purdue.edu/people/james.m.longuski.1/JournalArticles/1993/CyclerOrbitbetweenEarthandMars.pdf

This articles sets out the basic framework of the Aldrin Cycler and it admits that in the simple circular, co-planar model (i.e., the place where everyone starts their analysis of this subject), 230 m/s per cycle every 2 1/7 years is required to keep the Cycler going. The same paper also reports that the Aldrin Cycler was run through a full ephemeris model and a trajectory solution was found for which the delta-V requirements for a DSM over a 15 year period varied between 0.0 km/s and 1.10 km/s depending upon the date of the Cycler orbit. On average, for the full ephemeris case, average delta-V costs per cycle were around 280 m/s. At the same time, he reported hyperbolic excess velocity figures for Mars encounter in excess of 11.7 km/s.

How does this compare with my solution? Well, average delta-V per cycle is around 600 m/s - so around 300 m/s higher than the Aldrin solution. But my maximum hyperbolic excess velocity is 8.5 km/s - substantially less than that of Aldrin's solution. So, which is the better solution - the one with the lower average DSM cost or the one with the lower peak hyperbolic excess velocity?

In fact, in my whirlwind analysis of this problem, I came across solutions that had much less delta-V DSM requirements but for which peak maximum planetary encounter speeds topped out at a hefty (and unrealistic) 25 km/s! This, I think, serves to highlight a particular problem when it comes to analysing Cycler orbits - the delta-V of the DSMs is not the sole criterion by which those trajectories should be judged. Decisions need to be made according to:

1. The frequency of Earth / Mars encounters
2. The duration of the flight between Earth and Mars; and between Mars and Earth
3. The encounter speed of the Cycler at Earth and at Mars. (There is no point in having an rendezvous with the Cycler if a shuttle from the planet surface lacks the capability to match its encounter speed.
4. The total DSM delta-V requirements.

Although, I generated upwards of 50 solutions in my little analysis, it was easy to throw away a most of them because of the unacceptably higher encounter velocities (albeit at considerably lower delta-V requirements). On balance, I opted for the one set out above as being a reasonable compromise between DSM requirements and hyperbolic encounter speeds.

---------- Post added at 12:30 AM ---------- Previous post was at 12:13 AM ----------

As a thought, assuming that a correction has to be made, would it be possible for the correction to be accomplished by a low thrust device, say ion or even solar sail?

I suspect that a low thrust device could accomplish these Deep Space Manoeuvres. And, indeed, PyKEP / PyGMO has the capability of modelling the trajectories of such devices. However, PyGMO has a number of pre-installed frameworks for the analysis of trajectories such as this for engines delivering impulsive delta-V - and I leveraged one of these frameworks to do my analysis of the Cycler trajectory. This kept (my) coding requirements to a minimum. A similar framework does not exist for low thrust trajectories. It would be possible to design an algorithm that could look at this problem - but, although this may be a worthy thing to examine in detail, and simply as a matter of expediency, I'm probably going to put that piece of analysis to one side for the time being.

---------- Post added at 01:02 AM ---------- Previous post was at 12:30 AM ----------

I think I would find it interesting to actually BUILD a cycler station using IMS and a fleet of XR5s. Would you build it near Earth and then inject it into its final orbit.. or would you build it in its final orbit (which would take either a whole lot of XR5s at the same time, or a LONG LONG TIME to build).

I think it likely that one would build these Cycler stations in low Earth orbit and then, once built, inject them into their Cycler trajectories. By their nature, these stations would have to be fairly massive creations, and the question is: how would one accelerate these big, heavy ships to the high speeds needed to send it off on the Cycler trajectory?

Again, Aldrin has given some thought to that in the following paper:
https://engineering.purdue.edu/AAC/wp-content/uploads/2012/09/EstablishingCyclerTrajectoriesBetweenEarthAndMarsViaV-InfinityLeveraging-AIAA-2012-47461.pdf

The basis idea of this paper is to use a VILT. A VILT is a V-infinity Leveraged Transfer. Basically, a VILT uses a small DSM near orbital aphelion to increase the encounter velocity with Earth. The ensuing gravity assist at Earth gives the craft the momentum 'kick' to increase its speed to that needed for insertion into the Cycler orbit.

Because the Cycler trajectory is close to a 2:1 resonance with Earth (i.e., in the Aldrin Cycler it takes a little over two years for the Cycler to return to Earth), it would make sense to initiate the Cycler sequence by inserting it into a lower energy 3:2 or 4:3 resonant orbit with Earth and then execute the VILT DSM burn at the aphelion of that orbit.
 
Last edited:

Keithth G

New member
Joined
Nov 20, 2014
Messages
272
Reaction score
0
Points
0
OK, time now to say a few words about how to convert the PyKEP / PyGMO solution to the Aldrin Cycler problem into a 'high fidelity' trajectory for Orbiter 2010.

Let's start with the assertion that the PyKEP / PyGMO serves as a template or cartoon sketch of the trajectory: it sets out the basic structural elements of the trajectory but the underlying assumptions in PyKEP are of a zero-radius Sphere of Influence, 2-body Keplerian motion - i.e., a 'linked conics' approximation. If one were to try and fly this trajectory in Orbiter, one would find that one would need to apply plenty of mid-course corrections to keep the spacecraft 'on track'. Converting to a 'high fidelity' trajectory basically means tweaking the trajectory slightly so as to (with a high degree of precision) remove almost entirely the need for those mid-course corrections. What this means is that the high-fidelity trajectory will accurately model the 'true' trajectory of the spacecraft so that staying on the trajectory does not introduce any non-Newtonian forces on the spacecraft.

In other words, suppose that one had a Cycler craft being forced to run along the rails of the high-fidelity trajectory track. Like the planets in Orbiter, the Cycler is not in 'free fall'. The ephemeris solution forces it to run along a particular trajectory regardless of the true gravitational forces acting upon it. Imagine now an undocked craft immediately alongside the Cycler craft allowed to free fall in the gravitational field. Then, if the high-fidelity trajectory has been calculated correctly, there should be no change in the position of the free-falling spacecraft relative to the Cycler as it runs along its Cycler trajectory. Of course, where Deep Space Manoeuvres are required, this notion breaks down and there is a 'jump' in the speed and direction of the Cycler which is most decidedly non-ballistic. But for vast majority of the trajectory, the Cycler trajectory should accurately simulate a ballistic trajectory.


Realistic ballistic trajectory are important
This notion of accurately simulating a ballistic trajectory is most important near planetary rendezvous. Imagine that you are in a craft attempting to dock with the Cycler and suppose that you have worked your way to with, say, 100 m of the Cycler and have 'nulled out' your relative velocity with respect to the Cycler. A bit like docking with the ISS, what you hope and expect to see happen is the Cycler remain more or less stationary with respect to you. Not only does this make docking easier but it is also physically realistic. What you do not want to see is the Cycler accelerate away from you for no good reason simply because the Cycler is being forced to run along a set of rails that do not truly reflect the gravitational forces acting upon it. For you, in the nearby spacecraft, it would look as if some mysterious force were acting upon the Cycler and to dock with it you would have to continually match this mysterious acceleration. It would be weird, frustrating and completely unrealistic. Consequently, for the Cycler concept to work, we need to calculate an accurate, realistic ballistic trajectory for it.


Spicing and dicing
So, how do we go about doing that? The first step is to slice and dice the trajectory up into a series of smaller pieces. We note that the Cycler trajectory is punctuated by a series of DSMs. These occur in deep space - a long, long way from any planetary bodies. In between these DSMs, there is a ballistic arc that connects one DSM to another and with one or more ballistic planetary encounters. Between those planetary encounters where there is no DSM, we can imagine that there is a DSM at the half-way point along this arc - albeit one of zero magnitude. In this way, we can break up the entire Cycler trajectory into a series of ballistic arcs with exactly one planetary encounter in between. Rather than examine the whole trajectory in one go, we can develop ballistic trajectories for each of these arcs in turn and then splice them together. The net result will be a trajectory that is almost entirely ballistic everywhere except at the splice points where an instantaneous change in velocity (in effect, a DSM) takes place. In the PyKEP /PyGMO Cycler trajectory solution identified above, we have eleven such ballistic arcs - six contain encounters with Earth; and the remaining five encounters with Mars.

OK, so let's look at one of these encounters - one that goes from DSM - Earth - DSM, say. The PyKEP /PyGMO trajectory solution defines the 'when' and 'where' of the DSMs, the end-points of the ballistic arc. Now, PyKEP uses a slightly different coordinate system from that used in Orbiter but because these manoeuvres take place in deep-space a difference of 1,000 km, 10,000 km or even 100,000 km isn't going to make a lot of difference. So, the first thing that we can do is calculate the time and position of the DSMs from the PyKEP solution and immediately transcribe them into Orbiter's global reference frame. Now, we have what is known as boundary-value problem - we know where/when we start and where/when we finish; and we want to know the path we need to take in between. In many ways, this is similar to the classic 2-body Lambert problem. Here, though, we have a more complicated arrangement in which there is a generally low-altitude ballistic flyby of Earth in between. Moreover, we need to take be careful to take into account the perturbations induced by other Solar System gravitating bodies and so we need to use a full n-body gravity model. Here, simple semi-analytical solutions such as a Lambert Solver aren't really of much use. Instead, we need to use a high-fidelity n-body integrator to help us calculate trajectories. Fortunately, I have one of those.


The right ephemeris colution
What does the n-body integrator need to work effectively? To calculate a ballistic trajectory that would be calculated by Orbiter's own integration engine, we need to use the same gravity model as Orbiter. Since Orbiter uses a Newtonian gravity model, we need to use the same coordinate system as Orbiter, and we need to know to use the same planetary positions that Orbiter uses. In other words, we have to use the same planetary ephemeris model that Orbiter uses. Now, Orbiter planetary ephemeris is based on the VSOP87 ephemeris solution. This ephemeris can be downloaded from this code generator:

http://www.neoprogrammics.com/vsop87/source_code_generator_tool/

and so, for the most part, building an ephemeris model for Orbiter amounts to a 'cut and paste' job from this code generator. However, for the Earth, life is a little more complicated. The VSOP87 series calculates the position of the Earth-Moon barycentre and not the position of the Earth, per se. So, what we need to do here is to also calculate the position of the Moon relative to the Earth in the same way that Orbiter does - namely, by using the ELP82 ephemeris solution for the Moon. Once we have that, and the VSOP87 solution for the position of the EarthMoon barycentre, then we can back-solve to find the separate positions of the Earth and the Moon in Orbiter's global coordinate system.

With these ephemeris solutions and a symplectic integrator, we are good to go.


Completing the ballistic arc
So, how do we actually go about building the ballistic trajectory between the DSMs? Well, we start in the middle - at the planetary encounter. Let' suppose that we can guess our periapsis radius and the orientation of our encounter plane. Let's suppose also that we can guess our velocity at periapsis and the time when the encounter occurs. Using our n-body integrator, we can then propagate forward to the time of the second DSM at the end of the ballistic trajectory and we can see where we end up. In the same way, we can use our integrator to propagate backwards in time to the time of the first DSM at the start of the ballistic trajectory and see where we end up. Now, unless we are very good at guessing, there is going to be mismatch between where we the n-body integrator calculates that the DSMs take place and where the PyKEP / PyGMO trajectory design says that they should. So, we update our guess and tray again. And we keep updating our guess until we guess right. The formal procedure for doing this a multidimensional Newton-Raphson root-finding calculation but basically it consists of making a series of intelligent guesses and then updating those guesses.

Once one has solved this problem (and guessed right), one then has a fully ballistic arc that goes from one DSM to another DSM with a planetary encounter in between. If one repeats this exercise for each of the separate 11 legs of the Cycler trajectory, then one has defined the high-fidelity, almost entirely ballistic Cycler trajectory. And once this is done, the sole task to remain is to encode this trajectory as a C function call that will return the Cycler position and velocity for any time between the start of the trajectory and the end of the trajectory.


Do we have enough free variables
In solving problems of this kind, one of the things that we need to work out is do we have enough free variables to solve this problem. In this case, we have six constraints that we need to satisfy:

1. the n-body integrator has to integrate forwards and backwards from the planetary encounter so that the position of the two ends of the trajectory match the PyKEP / PyGMO DSM positions - three constraints apiece.

What about the variables? The forward/backwards integration of the ballistic trajectory is fully defined by planetary periapsis encounter. What variables define this encounter? We have:

1. three variables that define the planet-centric location of the point of periapsis,

2. two variables that define the velocity of the Cycler in the plane that is perpendicular to the position vector that connects the planet centre to the point of periapsis, and

3. the MJD of periapsis.

In total, then, we have six free variables to solve six equations. This should give us enough free variables with which to solve the boundary-value problem. To start the guessing game, we need an initial guess. Again, we can use the PyKEP /PyGMO solution to provide this


It's going to take a while
All of this amounts to some fairly heavy-duty computations of my laptop. And it will take a while. First step, though is to understand the ELP82 ephemeris solution and make sure that I have an Earth-Moon ephemeris tool that closely matches that of Orbiter's. I have done this in the past for the Galilean moons by implementing the Galsat routines used by Orbiter. Her, as there, I expect that the result will be an online Earth-Moon ephemeris tool capable of replicating Orbiter's ephemeris calculations to with a few metres.
 
Last edited:

Keithth G

New member
Joined
Nov 20, 2014
Messages
272
Reaction score
0
Points
0
Just a bit of an update on building the Aldrin Cycler trajectory.

Although I said that the next step in building the trajectory was to focus on the ELP82 ephemeris for the Moon, after some thought I decided I would side-step that for a little while and focus on decoding the PyKEP / PyGMO solution (above) to give more precise quantitative information about a) the time and location (in absolute inertial space) of the Deep Space Manoeuvres (DSMs); and b) an initial guess as to the state vectors of the Cycler at of each of the planetary encounters.


Decoding the trajectory
The Aldrin Cycler trajectory solution found above using PyKEP / PyGMO was presented in coded form. In principle, it can be de-coded to provide any and all information about the trajectory. But to do this, one has to write a Python code to decrypt it. The Python code that I have used to do this I present at at the end of the post for those interested but it may be more useful to present the result of that decryption.


The location of the DSMs
The first thing that we need to do is to identify the times and spatial coordinates of the DSMs of the Aldrin Cycler solution. The decoded solution yields the following information for these:

Code:
TABLE OF DEEP SPACE MANOEUVRES (DSMs) - ALDRIN CYCLER - POSITIONS (m)

MJD              dV (m/s)      Sun-centric X         Sun-centric Y         Sun-centric Z
---------------------------------------------------------------------------------------------
52023.076395        0.80      -126600635057.91       -89932855265.49        -1514347113.64
52585.864490     1286.88       -41492314948.32       249414354063.38         5403671124.29
52781.329016        1.12       -73274404470.41      -132254984607.24         -138302121.36
53190.441912      560.50       -26189458068.87       316060736248.40            6278836.18
53604.827184      321.64       141270001106.04       -56038256856.10         6529194137.77
54013.913536     1079.40      -309520655343.03        45531545966.75          810144734.31
54514.389340        0.00      -115657191326.87       211109587779.95         7534349320.62
54803.595155       14.19      -298416528252.61      -115202565441.37         -590389591.23
55140.132328        0.00       100459589662.29       108507960753.37         3387609068.23
55672.740027        0.00       -25356512418.68      -273376722842.79        -7580172844.08

Total            3264.52

This table shows the dates of the DSMs, the magnitude of delta-V needed to execute each of the DSMs and the heliocentric-coordinates of the DSM. These coordinates are in JPL's coordinate system. To use these results, we make the bold assumption that JPL's coordinate system is essentially the same as that used in Orbiter. However, we need to note the following:

1. Orbiter's coordinate system calls the 'y' component 'z'; and the 'z' component 'y'. So, when using these coordinates in Orbiter we always need to swap the 'y' and 'z' components of position and velocity. (Why is Orbiter set up in this way? I have no idea.)

2. The coordinates given above are heliocentric coordinates. Heliocentric coordinates are not inertial coordinates since the Sun rotates around the Solar System barycentre. To convert to Orbiter's (inertial) global reference frame, we also need to add the x, y and z coordinates of the Sun in the barycentric reference frame. And to do that we need to use the VSOP87 ephemeris solution for the Sun. This is adjustment is straightforward.

Once we complete these steps, we now have the backbone of our Aldrin Cycler. We know when and where the DSMs occur. We now construct the Cycler as a series of ballistic arcs between these DSMs. Along these ballistic arcs, there is one and only one planetary encounter - whether that be Earth or Mars.


Getting information about the periapsis encounters
To construct the ballistic trajectory, we first need to identify the Cycler's state vectors at planetary periapsis. This provides a set of initial conditions for using a method of differential correction to refine the ballistic trajectory connection one DSM to another DSM. Again, we have to use the PyKEP / PyGMO to do this. Decoding this solution yields the following information about the state vectors of the encounters at planetary periapsis:

Code:
TABLE OF PLANETARY ENCOUNTERS - ALDRIN CYCLER - POSITIONS (m)

Planet     MJD               Planet-centric X      Planet-centric Y      Planet-centric Z   
---------------------------------------------------------------------------------------------
Earth      52004.753695 
Mars       52127.050494           -3419377.13            -879393.02            1223895.16 
Earth      52779.687635          -24047904.77          -61222434.11           -4364874.46 
Mars       52909.466442           -1677283.66           -6318053.49            1831171.57 
Earth      53547.266758            6419691.70          -11251455.49           -9082148.58 
Mars       53746.577034            4062097.07           -2447741.43           -2180450.34 
Earth      54366.232480           40652360.40           -4647545.27           -9578413.44 
Mars       54519.476968          -10370384.58           -6147240.72          -43487587.71 
Earth      55115.054714           13632649.96            4785152.81           -1449149.10 
Mars       55285.966695            4501590.59            6760896.63          -27248803.47 
Earth      55862.850807 



TABLE OF PLANETARY ENCOUNTERS - ALDRIN CYCLER - VELOCITIES (m/s)

Planet     MJD               Planet-centric X      Planet-centric Y      Planet-centric Z   
---------------------------------------------------------------------------------------------
Earth      52004.753695 
Mars       52127.050494               2217.56              -8892.41               -193.85 
Earth      52779.687635               5196.17              -1944.04              -1360.42 
Mars       52909.466442               7382.40              -2149.00               -652.63 
Earth      53547.266758               7718.31               4213.81                235.36 
Mars       53746.577034               2287.71               5183.27              -1556.74 
Earth      54366.232480               1057.74               6658.08               1258.66 
Mars       54519.476968              -2903.17               6923.46               -286.36 
Earth      55115.054714              -2757.88               8609.30               2484.00 
Mars       55285.966695              -7384.16               4525.26                -97.09 
Earth      55862.850807

These tables provide the initial guess for our forward and backward n-body integration from planetary periapsis to each of the 'end-point' DSMs. Note that I have not calculated the first and last planetary encounters. The calculation of this is different from the other encounters and I will do this separately. To calculate the inertial coordinates of these state vectors in Orbiter's inertial global coordinate system, we need to:

1. Swap the values of 'y' and 'z' for both position and velocity;

2. Calculate the position of the heliocentric positions and velocities of the Mars and Earth on the encounter dates in question using the VSOP87 heliocentric ephemeris solutions for the planets.

3. In addition we need to use the VSOP97 barycentric ephemeris solution for the Sun.

With this information, we can make a simple adjustment to Orbiter's global reference frame.


A quick check
As a quick check on whether or not the encounter values make any sense, we can put into Orbiter the planet-centric values for the periapsis state vector and we should end up with a heliocentric orbit in IMFD that looks halfway sensible.

For example, let's take the planetary encounter at Mars on MJD 54519.476968. The Mars-centric state vector (in Orbiter's coordinate system - i.e., after swapping 'y' and 'z') is

MJD: 54519.476968
X: -10370384.58 m
Y: -43487587.71 m
Z: -6147240.72 m
VX: -2903.17 m/s
VY: -286.36 m/s
VZ: 6923.46 m/s

We can now use Orbiter's scenario editor to give a DeltaGlider, say, this state vector. If we do this, and then open IMFD's Map program to look at the resulting heliocentric orbit, we get the following:



IMFD shows a current location near Mars with a resulting trajectory that (even before DSMs makes a tolerably close encounter with Earth. This suggests that the calculations of periapsis state vectors 'makes sense' - particularly given that the PyKEP / PyGMO was based on a simple linked-conics, 2-body model. The full n-body integration to calculate the DSM-to-DSM ballistic trajectory will eliminate almost all of any errors in the 2-body trajectory and only small adjustments will be needed to these periapsis state vector values to calculate the n-body ballistic trajectory via an iterative method.

Next steps
Now on to (complete) the building of a VSOP87 ephemeris engine. This will be used to convert the above state vectors into Orbiter's (inertial) coordinate system; and the basis of force calculations of the n-body integrator.


The decryption code - a python script
For those interested, here is the Python script used to decode the PyKEP / PyGMO trajectory solution:

Code:
# The purpose of this script is to decode the PyKEP / PyGMO Aldrin Cycler trajectory solution
from PyKEP import *
from numpy import *
from math  import *

# this is the Aldrin Cycler trajectory in coded form.  It needs decoding.
x  =  ( 460.75369460319706,
           0.7069050962242127,  0.6214959546930826, 4000.0, 0.14982158316513236, 122.29679960906849, 
          4.380174952347228,   1.1000182978081348, 0.703015454393247,    652.6371404861663, 
          -2.9492286318127783, 10.335640036722038,  0.012647529445689552, 129.77880733788749, 
          -1.8568139426004193,  1.9983925762907067, 0.4405383052735283,   637.800315850365, 
          -2.5771013300458767,  2.480504028371953,  0.28879808652169864,  199.31027584206157, 
          -1.0673155399248222,  1.5365945604928082, 0.43142766546357125,  619.655446714997, 
          -1.0354621289411179,  6.588793961832874,  0.9668005854954329,   153.24448706242566, 
           0.2603611739095676, 13.284556431647848,  0.4770463460128354,   595.5777463673718, 
           5.267437226681595,   2.27666462477012,   0.1467282393627724,   170.91198098239667, 
           6.007154170375971,   8.370217924817446,  0.6704523900421687,   576.8841120389012)

# define the planets - Earth & Mars - used in the Aldrin Cycler
earth  = planet.jpl_lp('earth')
mars   = planet.jpl_lp('mars' )

# get some useful data for Earth
muE    = earth.mu_self       # the gravitational constant for Earth
radE   = earth.radius        # the radius of Earth

# get some useful date for Mars
muM    =  mars.mu_self       # the gravitational constant for Mars
radM   =  mars.radius        # the radius of Mars

# calculate the times of the planetary encounters
dt     = []
eta    = []
enc_t  = [x[0]]
for i in range(10):
    dt.append(   x[5 + 4*i])
    eta.append(  x[4 + 4*i])
    enc_t.append(enc_t[i] + dt[i])

# calculate some useful quantites relating to the encounterd
bp     = ["Null"]  # beta plane
rp     = ["Null"]  # periapsis radius
mu     = ["Null"]  # gravitatinal constant
for i in range(9):
    bp.append( x[6 + 4*i])
    if (i % 2)==0:
        rp.append( radM * x[7 + 4*i] )
        mu.append( muM )
    else:
        rp.append( radE * x[7 + 4*i] )
        mu.append( muE )
bp.append("Null")
rp.append("Null")
mu.append("Null")

# calculate the position of the planets of the planetary encounters
r_p    = []
v_p    = []
for i in range(11):
    if (i % 2)==0:
        r, v   = earth.eph(enc_t[i])
    else:
        r, v   =  mars.eph(enc_t[i])
    r_p.append(r)
    v_p.append(v)
    
# initialise some stuff
vin    = []
vout   = []
DSM_t  = []
DSM_r  = []
DSM_dV = []

# calculate the initial vin and vout
theta  = 2 * pi * x[1]
phi    = acos(2 * x[2] - 1) - pi / 2
vinf   = x[3]
vin.append("Null")
vout.append( vinf * array([cos(theta) * cos(phi), sin(theta) * cos(phi), sin(phi)]) + v_p[0])

# work through each of the middle 9 legs
for i in range(9):
    r, v   = propagate_lagrangian(r_p[i], vout[i], eta[i]*dt[i]*DAY2SEC, MU_SUN)
    l      = lambert_problem(r, r_p[i+1], (1-eta[i])*dt[i]*DAY2SEC, MU_SUN)
    vin.append( l.get_v2()[0])
    vout.append( fb_prop(vin[i+1], v_p[i+1], rp[i+1], bp[i+1], mu[i+1]) )
    DSM_t.append( enc_t[i] + eta[i]*dt[i] )
    DSM_r.append( r )
    DSM_dV.append( array(l.get_v1()[0]) - v )

# update the final leg
r, v   = propagate_lagrangian(r_p[9], vout[9], eta[9]*dt[9]*DAY2SEC, MU_SUN)
l      = lambert_problem(r, r_p[10], (1-eta[9])*dt[9]*DAY2SEC, MU_SUN)
vin.append( l.get_v2()[0])
vout.append("Null")
DSM_t.append( enc_t[9] + eta[9]*dt[9] )
DSM_r.append( r )
DSM_dV.append( array(l.get_v1()[0]) - v )


# print out the information relating to the Deep Space Manoeuvres (DSMs)
s = 0
print("TABLE OF DEEP SPACE MANOEUVRES (DSMs) - ALDRIN CYCLER - POSITIONS (m)")
print
print("MJD              dV (m/s)      Sun-centric X         Sun-centric Y         Sun-centric Z")
print("---------------------------------------------------------------------------------------------")
for i in range(10):
    temp = linalg.norm(DSM_dV[i])
    s    = s + temp
    x    = DSM_r[i][0]
    y    = DSM_r[i][1]
    z    = DSM_r[i][2]
    print("%10.6f  %10.2f  %20.2f  %20.2f  %20.2f" % (epoch(DSM_t[i]).mjd, temp, x, y, z))
print
print("Total         %10.2f" % round(s, 3))
print
print
print
print("TABLE OF PLANETARY ENCOUNTERS - ALDRIN CYCLER - POSITIONS (m)")
print
print("Planet     MJD               Planet-centric X      Planet-centric Y      Planet-centric Z   ")
print("---------------------------------------------------------------------------------------------")
print("Earth      %10.6f " % (epoch(enc_t[0]).mjd))
for i in range(9):
    temp = array(vin[i+1]) - array(vout[i+1])
    temp = rp[i+1] * temp / linalg.norm(temp)
    if i%2==0:
        print("Mars       %10.6f  %20.2f  %20.2f  %20.2f " % (epoch(enc_t[i+1]).mjd, temp[0], temp[1], temp[2]))
    else:
        print("Earth      %10.6f  %20.2f  %20.2f  %20.2f " % (epoch(enc_t[i+1]).mjd, temp[0], temp[1], temp[2]))
print("Earth      %10.6f " % (epoch(enc_t[10]).mjd))
print
print
print
print("TABLE OF PLANETARY ENCOUNTERS - ALDRIN CYCLER - VELOCITIES (m/s)")
print
print("Planet     MJD               Planet-centric X      Planet-centric Y      Planet-centric Z   ")
print("---------------------------------------------------------------------------------------------")
print("Earth      %10.6f " % (epoch(enc_t[0]).mjd))
for i in range(9):
    v0     = array(vin[i+1])  - array(v_p[i+1])
    v1     = array(vout[i+1]) - array(v_p[i+1])
    x      = v0 - v1
    y      = cross(v1, v0)
    z      = cross(x, y)
    temp = z / linalg.norm(z) * sqrt(dot(v0, v0) + 2 * mu[i+1] / rp[i+1])
    if i%2==0:
        print("Mars       %10.6f  %20.2f  %20.2f  %20.2f " % (epoch(enc_t[i+1]).mjd, temp[0], temp[1], temp[2]))
    else:
        print("Earth      %10.6f  %20.2f  %20.2f  %20.2f " % (epoch(enc_t[i+1]).mjd, temp[0], temp[1], temp[2]))
print("Earth      %10.6f " % (epoch(enc_t[10]).mjd))
 
Last edited:

jroly

Donator
Donator
Joined
Jan 26, 2014
Messages
404
Reaction score
1
Points
18
I read Zubrins book about settlement of Mars, he said those who could not afford anything else would choose a cycler to travel to Mars but it was was a comedy book. I would say a cycler would look a lot like the Arrow.
 
Top