Idea The Aldrin Cycler?

[richfororbit]

Hi,

For anyone who knows about the idea of the cycler proposed by Mr Aldrin, you know the former Lunar Module pilot.

Further orbits around the Martian planet line up to eventually get back to the Earth.

Could this be an addon for Orbiter?

 

[GLS]

Probably yes, as Orbiter has shown to be very accurate. I don't know it well enough to know if it needs orbit corrections.
Anyway, it's a very interesting concept and if I was going to Mars now, I'd get 2 of those things going to "pave the way".

 

[jedidia]

I was thinking about that every now and then. Technicall it should work, but I have no Idea how stable it would be at high time acceleration. Would probably require user intervention to keep it on track over several cycles.

 

[richfororbit]

For anyone up to the challenge of creating this type of addon, it would be interesting to see part of Aldrin's plan with assisting to get a crew to Mars.

I've seen on the youtube site a clip with a proposed station that goes into this orbit between the planets.

 

[jroly]

I think the cycler is too difficult and impractical to work. I mean how is something supposed to rendevous it, eg wait in LEO for it to arrive, when it arrives apply enough thrust for a Mars transfer, then rendevous.

 

[Urwumpe]

I think the cycler is too difficult and impractical to work. I mean how is something supposed to rendevous it, eg wait in LEO for it to arrive, when it arrives apply enough thrust for a Mars transfer, then rendevous.

You can also do rendezvous in solar orbit. It is not that hard, quite contrary - the long orbit period makes it a lot easier to simply fly straight towards the cycler from a longer distance.

 

[jedidia]

Dug out the old thread about it (what do you know, you search for "aldrin cycler orbital elements" and of course an OF thread would be among the top 5... )

There's two scenarios as well as links to a few papers, some of them with more math than I can take on a normal day, much less after being shellshocked by a shell script examn we turned out to have to do on paper.

As I expected, the cycler trajectory isn't maintenance free... the required adjustments consume very little propellant, but they need to be made, or you won't see neither earth nor mars again after the first half of the cycle. Automating this in orbiter would seem a major mathematical undertaking.

 

[Keithth G]

I really don't know very much about cycler orbits, but based on what I have quickly read from this paper - http://russell.ae.utexas.edu/FinalPublications/ConferencePapers/03Feb_AAS-03-145.pdf - it would seem that to operate the cycler trajectory requires some very precise gravity-assist encounters for it to operate. Performing any gravity-assist is like balancing on a knife's edge: a slight variation in approach altitude or angle will have a large effect on the outgoing trajectory. No matter how you do it, course corrections will be required and automating those course corrections is challenging.

The best way that I can think of doing it is for someone to invest time in designing a 'reference trajectory' for the cycler orbit. This reference trajectory would be specific to a particular date range and would specify the 'ideal' state vectors (position and velocity) of the spacecraft at any point in time during the cycler orbit. Then, one would set up some form of autopilot that would make small adjustments to speed and direction so as to stay 'close' to the reference trajectory - with 1 km and 1 m/s say of the 'ideal' position and velocity. Under high time-warp, though, this scheme may fail miserably.

 

[richfororbit]

Unfortunately, my maths is at a school's level, really bad.:dry:

 

[jedidia]

The best way that I can think of doing it is for someone to invest time in designing a 'reference trajectory' for the cycler orbit.

I was thinking the same, but I have no clue how to do it. A cycler ephemeris, so to speak.
I guess I could write a short plugin that saves the state vectors to a file every minute or so, and then cycle for a few weeks, but with a six-days work week and two kids, there's no chance of that happening :lol:

Under high time-warp, though, this scheme may fail miserably.

Not that much of a problem, really. Since you'd have the complete state vectors, you could just make the autopilot cheat at high time acelerations and let him set vessel state vectors directly.

 

[Keithth G]

I was thinking the same, but I have no clue how to do it. A cycler ephemeris, so to speak

Yes, a cycler ephemeris - exactly so.

With some effort, I daresay I could calculate an accurate ephemeris for a cycler orbit and present this in an appropriate (compressed) form. (I would have to learn somewhat more than I do now about cycler orbits first, but that's an acceptable cost.)

But, sadly, my skills don't extend to coding an Orbiter addon.

 

[richfororbit]

Folks if it isn't workable, don't worry. It was just another idea.

 

[jedidia]

But, sadly, my skills don't extend to coding an Orbiter addon.

Coding up a dll that will just keep the cycler stoically on trajectory by setting its state vectors (similar to how ephemeris for planets is handled) would be a breeze, a few hours at most, I could do that pretty easily if I had the data. An actual autopilot would be a lot more work of course, and somewhat outside my area of expertise.
As a bonus, a general enough dll could just as easily be used to do stable lagrange point stations and stuff like that if there's a data set.

It was just another idea.

One that I happen to like, and if there's a chance I can get somebody to do the number crunching, I have to seize the opportunity :lol:

 

[richfororbit]

Ah right. Well for anyone that can try this out, should be interesting. As for an actual cycler outpost?

 

[Keithth G]

Coding up a dll that will just keep the cycler stoically on trajectory by setting its state vectors (similar to how ephemeris for planets is handled) would be a breeze, a few hours at most, I could do that pretty easily if I had the data.

OK, I'll have a look at a simple Earth-Mars cycler trajectory scheme. It may take a while before I have a detailed trajectory worked out, though. At the moment, I'm thinking of modelling a basic Aldrin Cycler trajectory. The trajectory plan would cover a time-period of either 15 or 30 years (i.e., once of twice the time taken for the position for the Earth and Mars to return to the same starting configuration with respect to the Sun). What I would produce would be a function written in C such that, given any given MJD in the relevant 15 or 30 year time interval, return the state vector of the Aldrin Cycler. The function would have to have access to a trajectory ephemeris file which would decode the data contained therein and map the information to an Orbiter-Friendly state vector representation.

The basic scheme for determining the Cycler trajectory is:

1. Work out the basic logic of the Cycler trajectory assuming circular, co-planar orbits for Earth and Mars;

2. Using this as a starting point, refine the trajectory plan in a linked-conics model that takes not account orbital eccentricity and inclination of Earth and Mars; then

3. Using that as a starting point, produce the full ephemeris trajectory solution using an n-body integrator; and finally

4. Encode the n-body ephemeris trajectory as a data file that can be decoded using the C function call.

I have all the tools needed to do this - but it still isn't the work of a few moments. The result, though, will be a high-fidelity model consistent with Orbiter's underlying gravity model and accurate to, say, < 10^-2 m/s in speed and < 10 m in position.

As a bonus, a general enough dll could just as easily be used to do stable lagrange point stations and stuff like that if there's a data set.

Strictly speaking, you don't need a data set for this. There is an analytical solution for the elliptical restricted three-body problem. I've written a lua script which calculates the state-vectors for a body at the Earth-Moon L2 lagrange point here: http://www.orbiter-forum.com/showthread.php?t=36110. The speed is accurate to < 10^-3 m/s and position < 1 m. For convenience, the script is copied below:

     -- get the handle for the spacecraft
       ves 		 = vessel.get_focushandle()

       -- get the handles for the Earth and the Moon
       earth		 = oapi.get_objhandle("Earth")
       moon		 = oapi.get_objhandle("Moon")

       -- define a set of constants relevant to the Earth-Moon L2 libration points
       GM1		= 398600440157821.0    -- gravitational constant for the Earth (SI units)
       GM2		=   4902794935300.0	   -- gravitational constant for the Moon  (SI units)
       GM	        = GM1 + GM2
       MU1		= GM1 / GM
       MU2		= GM2 / GM
       alpha		= 1.155682111433621	   -- the libration parameter for the Earth-Moon L2 point
	
	-- get the current location of the vessel
	q 		= oapi.get_globalpos(ves)
	p 		= oapi.get_globalvel(ves)
	
	-- get the current location of Earth
	q_ear 	= oapi.get_globalpos(earth)
	p_ear 	= oapi.get_globalvel(earth)
	
	-- get the current location of the Moon
	q_mon 	= oapi.get_globalpos(moon)
	p_mon 	= oapi.get_globalvel(moon)
	
	-- calculate the weighted average position and velocity of the Earth and Moon
	com   = vec.add( vec.mul( q_ear, MU1 ), vec.mul( q_mon, MU2 ) )
	cov	 = vec.add( vec.mul( p_ear, MU1 ), vec.mul( p_mon, MU2 ) )
	
	-- calculate the position of the Moon relative to the Earth
	r	= vec.sub( q_mon, q_ear )
	v	= vec.sub( p_mon, p_ear )
	
	-- calculate some quantities that are used multiple times in the ensuing calculations
	vsq	= vec.dotp( v, v)
	rln	= vec.length( r )
	rv	= vec.dotp( r, v)
	
	-- calculate:
	--    'e'	- the eccentricity vector of the Moon relative to Earth
	--    'ecc' - the eccentricity
	--    'a'	- the semi-major axis
	--    'nu'	- the mean anomaly
	e	= vec.sub( vec.sub( vec.mul( r, vsq / GM ), vec.mul( v, rv / GM) ), vec.mul( r, 1.0 / rln ) )
	ecc	= vec.length(e)
	a	= GM / (2.0 * GM / rln - vsq)
	nu	= math.acos( vec.dotp(e, r) / ecc / rln)
	if rv < 0 then
		nu 		= 2.0 * math.pi - nu
	end
	
	-- calculate the unit vectors of a dextral reference frame aligned with the Moon's
	-- orbital plane and orbital orientation:
	--		'xhat'	- a unit vector pointing in the direction to the Moon's orbital periapsis
	--		'zhat'	- a unit vector point normal to the Moon's orbital plane
	--		'yhat'	- the third unit vector to complete the trio
	xhat	= vec.unit( e )
	zhat	= vec.unit( vec.crossp( r   , v    ) )
	yhat	= vec.unit( vec.crossp( zhat, xhat ) )
	
	-- calculate some more intermediate values
	k1	= a * (1.0 - ecc * ecc )
	k2	= math.sqrt( GM / k1 )
	cnu	= math.cos(nu)
	snu	= math.sin(nu)
	k3	= 1.0 + ecc * cnu		
	
	-- calculate the position of the Lagrange point in the dextral reference frame:
	--		'qx'	- the position of the Lagrange point in the 'xhat' direction
	--		'qy'	- the position of the Lagrange point in the 'yhat' direction
	--		'qz' = 0  by definition
	--		'px'	- the speed of the Lagrange point in the 'xhat' direction
	--		'py' 	- the speed of the Lagrange point in the 'yhat' direction
	--		'pz' = 0  by definition
	qx	=  alpha * k1 * cnu / k3
	qy	=  alpha * k1 * snu / k3
	px	= -alpha * snu * k2
	py	=  alpha * (ecc + cnu) * k2
	
	-- caluclate the position of the Lagrange point in Orbiter's global reference frame
	l2qa	= vec.mul( xhat, qx   )
	l2qb	= vec.mul( yhat, qy   )
	l2qc	= vec.add( l2qa, l2qb )
	l2q    = vec.add( l2qc, com  )
	
	-- calculate the velocity of the Lagrange point in Orbiter's global reference frame
	l2pa	= vec.mul( xhat, px   )
	l2pb	= vec.mul( yhat, py   )
	l2pc	= vec.add( l2pa, l2pb )
	l2p	= vec.add( l2pc, cos  )

I doubt that it would take much effort to convert this into a C function. Moreover, by changing the value of 'alpha' in the above script to 0.83691519487205988712 one could also calculate the state vectors for the Earth-Moon L1. And if one wants to change the gravitational constants to reflect bodies other than the Earth and Moon, one could calculate similar points for other bodies - e.g. Sun-Earth.

 

[Malky]

General addon to keep any station/ship on given trajectory, with list of preconfigured trajectories (Aldrin cycler, various L points) and possibility to add own trajectories would be IMHO amazing addition to orbiter.

 

[jedidia]

What I would produce would be a function written in C such that, given any given MJD in the relevant 15 or 30 year time interval, return the state vector of the Aldrin Cycler. The function would have to have access to a trajectory ephemeris file which would decode the data contained therein and map the information to an Orbiter-Friendly state vector representation.

That would be great. The rest of the add-on is basically just a few lines to update the state, and a small parser to enable external configuration.

General addon to keep any station/ship on given trajectory, with list of preconfigured trajectories (Aldrin cycler, various L points) and possibility to add own trajectories would be IMHO amazing addition to orbiter.

Well, the difficult thing here is getting the data set, and those won't write themselves...

 

[Keithth G]

Just in case people aren't too sure what an Aldrin Cycler looks like, here is a graph of an Earth-Mars (Aldrin) Cycler in the simple co-planar circular orbit theory:



The orbit of Earth is shown in red; that of Mars is shown in Orange; and the Aldrin Cycler trajectory is shown in black. The span of this trajectory is 15 years. In that time, the Cycler visits encounters Earth and Mars seven times. I propose to develop a trajectory plan for a 30 year period from around 2020 to 2050 allowing for 14 transits to from Earth to Mars and back again.

Here are a couple of useful things to know about the Aldrin Cycler:

1. The Aldrin Cycler is not a ballistic trajectory. That is to say, there needs to be an impulsive manoeuvre near the aphelion of each of 'leg' of the orbit to position the spacecraft for the next Earth encounter. This impulsive manoeuvre is needed because Earth doesn't have sufficient mass to induce the required turning angle of the trajectory during each of the Earth gravity assist manoeuvres.

2. The time between successive Earth encounters is around 2.14 years. The Cycler is normally set up so that there is a fast transit time from Earth to Mars. To have a fast transit from Mars back to Earth, the Cycler is normally viewed as having two Cyler craft - the second slightly out of phase with the first. One of the pair, facilitates a fast transfer from Earth to Mars, while the other facilitates a fast transfer from Mars back to Earth.

3. Although there is an impulsive manoeuvre near aphelion of each orbit, encounters with Earth and Mars are entirely ballistic. Minimum target altitude at Earth is 1,000 km. Hyperbolic excess velocity at Earth encounter is 6,500 m/s.

The above graph was produced using PyKEP. PyKEP is a piece of free trajectory optimisation software from the European Space Agency (ESA). Although not sufficient to develop a high-fidelity trajectory for use in Orbiter, it does possess a fast multi-revolution Lambert solver, a sophisticated global optimisation suite, and a comprehensive (JPL) ephemeris package that can be used as a robust starting point for trajectory planing in Orbiter.

Now to work out the elliptical theory.

Readers may also wish to view the following Youtube link shown here:
https://www.youtube.com/watch?v=qCVfUlFZQ4U

 

[Keithth G]

This is a direct continuation of the preceding post on developing an Aldrin Cycler for Orbiter.

The preceding post focused on the Aldrin Cycler for the circular, co-planar model for the orbits of Earth and Mars. The painted a useful picture of Cycler orbit but, by itself, was not particularly realistic because the orbits of Earth and Mars are elliptical and inclined with respect to each other. This post, then, focuses on developing a Cycler orbit for the elliptical, non co-planar theory for the motion of Earth and Mars. The result is an orbit that is a distorted rendering of the very symmetric circular theory orbit and (for five Earth-Mars encounter sequences at any road) looks something like this:



Here the trajectory is in blue; Earth's orbit is in orange; and Mars' orbit is in green. The small circles depict the encounters with Earth and Mars. The Sun is in the centre. And distances are measured in Astronomical Units (AUs) such that 1 AU is about 150 million km. As you can see, this more realistic trajectory has much in common with the neat, regular circular theory orbit (see previous post) but now the encounters with Earth and Mars are no longer regularly spaced.

In a little more (quantitative) detail, the trajectory plan looks like this:



OK, so what do these numbers mean? Leaving Earth on 5th April, 2001 with a hyperbolic excess velocity of 4,000 m/s, the Cycler encounters Mars 122.3 days later. The hyperbolic excess velocity of that encounter is 7,817 m/s. After encountering Mars, the Cycler encounters Earth after another 652.6 days. During that transfer, the Cycler must execute a precisely timed Deep Space Manoeuvre (DSM) of 1,287 m/s. At Earth encounter its hyperbolic excess velocity is 4,532 m/s. After this earth encounter, the Cyler has a 129.8 day transfer out to Mars and its hyperbolic excess velocity of 6,850 m/s. And so on, for another four laps around the Sun. The total flight duration is 10.56 years.

A few points to note. First, encounter speeds at Mars (and Earth) are generally higher than one may be used to in setting up Hohmann transfers from the the Earth to Mars. Here, encounter velocities of around 3,000 to 4,000 m/s are more typical. The higher encounter speeds of the Aldrin Cycler is an unavoidable characteristic of this particular Cycler. Second, the transfer from Earth to Mars in this Cycler is always short and the transfer from Mars to Earth is always very long. The trajectory shown here is an 'up' cycler trajectory enabling a fast transfer from Earth to Mars. In principle, one should also develop a 'down' cycler that enables a fast transfer from Mars back to the Earth, but for the time being I'm just going to focus on developing an 'up' cycler trajectory. Third, I'll include some more specific details of the trajectory solution at the end of this post.

How was this trajectory designed?
OK, so where did this trajectory come from? Although the development of the circular theory Aldrin Cycler of the previous posts is simplified by exploiting the seven-fold symmetry of the problem, if one puts back the elliptical character of the Earth/Mars orbits as well as the inclination of Mars' orbit with resect to the ecliptic, this symmetry is destroyed and the problem suddenly becomes much, much harder.

How hard? Well let's suppose that we imagine we want to design an Aldrin Cycler orbit over a 30 year time span. This will involve one Earth departure; 14 Mars encounters and a further 14 Earth encounters. Let's suppose that we describe each of the Earth-Mars transfers and the Mars-Earth transfers as a ballistic manoeuvre with a maximum of one DSM per transfer, then it works out that we can fully specify the trajectory with 114 numbers. I won't go into why this is so, but what it means is that finding an Aldrin Cyler orbit in the elliptical case means carrying out a non-linear, non-convex optimisation in 114 variables. And in case this description of the problem doesn't immediately make you shudder in horror, suffice to say that this makes it a hard, hard problem to solve.

The firs step in proceeding, then, is to make this a somewhat smaller problem. Instead of a sequence of 14 Mars encounters and 14 earth encounters over a 30 year time-span, let's focus on a shorter time interval of, say 5 Mars encounters and 5 earth encounters over a ten year time-span. Immediately, the number of variables needed to describe this problem drops from 114 down to just 42. Although a smaller problem, it is still a tough nut to crack and at this point one needs to think about tools for solving problems of this kind. Firstly, one should note that pen and paper solutions don't exist. TransX and IMFD aren't suited to problems of this kind. And Microsoft Excel's 'Solver' utility isn't up to the challenge. Instead one has to resort to using some fairly high-powered numerical solvers.

Fortunately, the Advanced Concepts Team of the European Space Agency (ESA) has made public a suite of tools called PyKEP and PyGMO. These tools are free, very powerful and (with some caveats) largely compatible with Orbiter. Let's break this down a bit: PyKEP can be split into two bits - 'Py' and 'KEP'. The 'Py' bit refers to a free scripting language called Python. Python is a nit like Orbiter's 'Lua' scripting language except that Python is widely used and there is a large suite of add-ons to Python that convert Python into a very powerful tool for solving mathematical problems. The 'KEP' bit of the name refers to a suite of Keplerian tools - a Lambert Solver, a trajectory propagator, and a planetary ephemeris (JPL's Low Precision ephemeris or, if one wants JPL's Spice Ephemeris). With this toolkit, one can solve a variety of trajectory planning problems using a high-level scripting language. Now let's look at the 'PyGMO' bit of the title. Again, the 'Py' refers to the Python scripting language so that PyGMO is a Python version of a program called PaGMO. Now , the 'Pa' bit of that refers to 'parallel' so that the software natively used the multiple cores available on your laptop or desktop to solve problems; and the 'GMO' bit refers to a general purpose optimisation software suite developed by the ESA to solve some very complex real, word trajectory planning problems - e.g., Cassini and Messenger missions.

All of this is now available, free of charge. All you have to do is download it and install on your machine. And, voila! - one immediately has access to a very high-powered general optimisation package tailored for interplanetary trajectory planning on your desktop/laptop. Think of it as TransX/IMFD on steroids.

Anyway, recognising that solving the Aldrin Cycler problem was a 'tough problem' I decided to crank the handle on PyKEP / PyGMO and see what it produced.

The results from PyKEP / PyGMO
At the start of this post, I presented a summarised version of the trajectory plan produced by PyKEP / PyGMO. A more fulsome description is provided below:

First Leg: earth to mars
Departure: 2001-Apr-05 18:05:19.213716 (4.607536946031971e+02 mjd2000)
Duration: 1.222967996090685e+02 days
r_dep: [-143885682261.71964, -41280724972.580193, 128571.82841878776]
v_dep: [6691.9997807496957, -32483.898498774866, -971.8781086485543]
VINF_dep: 4.000000000000000e+03 m/sec
r_arr: [85539266734.333725, -193142327710.50067, -6148199112.5546856]
v_arr: [23809.128224291406, 4111.9653215695471, -76.765340069924335]
VINF_arr: 7.817133488628867e+03 m/sec
DSM after 1.832270013345958e+01 days
DSM magnitude: 7.970658826285643e-01 m/s

leg no: 2: mars to earth
Duration: 6.526371404861663e+02 days
Fly-by epoch: 2001-Aug-06 01:12:42.699940 (5.830504942122656e+02 mjd2000) 
Fly-by radius: 1.100018297808135e+00 planetary radii
r_dep: [85539266734.333725, -193142327710.50067, -6148199112.5546856]
v_dep: [26068.622552803125, 4693.0604958428166, -885.5044973457201]
VINF_dep: 7.817133488628869e+03 m/sec
r_arr: [-77486684394.375519, -130049987579.21567, 1028527.3385918017]
v_arr: [28743.854768974143, -17818.246303665761, -1119.1082781225123]
VINF_arr: 4.531763864156497e+03 m/sec
DSM after 4.588139958727916e+02 days
DSM magnitude: 1.286878424365651e+03m/s

leg no: 3: earth to mars
Duration: 1.297788073378875e+02 days
Fly-by epoch: 2003-May-20 16:30:11.637945 (1.235687634698432e+03 mjd2000) 
Fly-by radius: 1.033564003672204e+01 planetary radii
r_dep: [-77486684394.375519, -130049987579.21567, 1028527.3385918017]
v_dep: [29495.920076702012, -15903.59847125894, -982.60280355112445]
VINF_dep: 4.531763864156499e+03 m/sec
r_arr: [206206859238.84271, -22408470470.0401, -5536070829.4254637]
v_arr: [9854.651737352795, 23506.856607030088, 104.49074923235119]
VINF_arr: 6.850275148974602e+03 m/sec
DSM after 1.641381287232403e+00 days
DSM magnitude: 1.116627156541113e+00m/s

leg no: 4: mars to earth
Duration: 6.378003158503650e+02 days
Fly-by epoch: 2003-Sep-27 11:11:40.591938 (1.365466442036319e+03 mjd2000) 
Fly-by radius: 1.998392576290707e+00 planetary radii
r_dep: [206206859238.84271, -22408470470.0401, -5536070829.4254637]
v_dep: [10255.815071921832, 25017.973335948809, -333.47863435004541]
VINF_dep: 6.850275148974603e+03 m/sec
r_arr: [12429985766.293575, -151562214588.65811, 1918374.7613635447]
v_arr: [34214.037739057712, 2718.997890290952, -1318.1924655389641]
VINF_arr: 5.195573488630804e+03 m/sec
DSM after 2.809754702476408e+02 days
DSM magnitude: 5.605020334144223e+02m/s

leg no: 5: earth to mars
Duration: 1.993102758420616e+02 days
Fly-by epoch: 2005-Jun-26 06:24:07.881410 (2.003266757886684e+03 mjd2000) 
Fly-by radius: 2.480504028371953e+00 planetary radii
r_dep: [12429985766.293575, -151562214588.65811, 1918374.7613635447]
v_dep: [32178.457659295411, 6286.6518754976642, 1561.6094938434749]
VINF_dep: 5.195573488630804e+03 m/sec
r_arr: [40339651945.64045, 227554364459.72998, 3776299443.5925317]
v_arr: [-20330.721173710815, 9231.9403972235432, -930.47917668335037]
VINF_arr: 4.256001597987443e+03 m/sec
DSM after 5.756042628729932e+01 days
DSM magnitude: 3.216383994716669e+02m/s

leg no: 6: mars to earth
Duration: 6.196554467149970e+02 days
Fly-by epoch: 2006-Jan-11 13:50:55.714164 (2.202577033728746e+03 mjd2000) 
Fly-by radius: 1.536594560492808e+00 planetary radii
r_dep: [40339651945.64045, 227554364459.72998, 3776299443.5925317]
v_dep: [-22395.815988412756, 10476.326740925728, 178.02133772976129]
VINF_dep: 4.256001597987444e+03 m/sec
r_arr: [150129353476.00769, -731488458.31877899, 12964.813353931997]
v_arr: [1745.2154439621218, 34504.943326826753, 635.15744050027092]
VINF_arr: 5.297416500750841e+03 m/sec
DSM after 2.673365027680375e+02 days
DSM magnitude: 1.079398016710800e+03m/s

leg no: 7: earth to mars
Duration: 1.532444870624257e+02 days
Fly-by epoch: 2007-Sep-23 05:34:46.310339 (2.822232480443743e+03 mjd2000) 
Fly-by radius: 6.588793961832874e+00 planetary radii
r_dep: [150129353476.00769, -731488458.31877899, 12964.813353931997]
v_dep: [-843.90239317537817, 34800.941941513323, 1245.1992892021228]
VINF_dep: 5.297416500750838e+03 m/sec
r_arr: [-125763661087.81613, 209708279765.48022, 7482440709.6356039]
v_arr: [-22744.019212650473, -3613.2572904676153, -133.26743000433964]
VINF_arr: 7.385566408354761e+03 m/sec
DSM after 1.481568598159004e+02 days
DSM magnitude: 1.321794340763914e-06m/s

leg no: 8: mars to earth
Duration: 5.955777463673718e+02 days
Fly-by epoch: 2008-Feb-23 11:26:49.992533 (2.975476967506169e+03 mjd2000) 
Fly-by radius: 1.328455643164785e+01 planetary radii
r_dep: [-125763661087.81613, 209708279765.48022, 7482440709.6356039]
v_dep: [-22685.970520005212, -3578.8478349482079, 110.15629192642143]
VINF_dep: 7.385566408354761e+03 m/sec
r_arr: [142255724157.72513, 45481672354.851105, -1016809.8295723405]
v_arr: [-8612.9173829282354, 33821.330176458971, 1094.9417352446803]
VINF_arr: 5.744103760280696e+03 m/sec
DSM after 2.841181876711140e+02 days
DSM magnitude: 1.419200947090572e+01m/s

leg no: 9: earth to mars
Duration: 1.709119809823967e+02 days
Fly-by epoch: 2009-Oct-11 01:18:47.278674 (3.571054713873541e+03 mjd2000) 
Fly-by radius: 2.276664624770120e+00 planetary radii
r_dep: [142255724157.72513, 45481672354.851105, -1016809.8295723405]
v_dep: [-13511.149619049127, 32102.017364514169, 1615.623250827148]
VINF_dep: 5.744103760280697e+03 m/sec
r_arr: [-227767178142.90509, 100898900781.73105, 7707169112.347394]
v_arr: [-16109.843203469642, -15611.292044883759, -463.87996796442121]
VINF_arr: 8.485320233354389e+03 m/sec
DSM after 2.507761405555070e+01 days
DSM magnitude: 3.411432095557483e-09m/s

leg no: 10: mars to earth
Duration: 5.768841120389012e+02 days
Fly-by epoch: 2010-Mar-30 23:12:02.435553 (3.741966694855937e+03 mjd2000) 
Fly-by radius: 8.370217924817446e+00 planetary radii
r_dep: [-227767178142.90509, 100898900781.73105, 7707169112.347394]
v_dep: [-16164.898520245812, -15693.979107971605, -130.6218727451936]
VINF_dep: 8.485320233354389e+03 m/sec
r_arr: [121894382825.22475, 85043845250.83577, -2294714.2955327546]
v_arr: [-20402.481538263753, 28471.273770649019, 1266.5374418900508]
VINF_arr: 5.205969594500140e+03 m/sec
DSM after 3.867733316938355e+02 days
DSM magnitude: 1.350636532014951e-08m/s

Arrival at earth
Arrival epoch: 2011-Oct-28 20:25:09.715714 (4.318850806894839e+03 mjd2000) 
Arrival Vinf: 5.205969594500140e+03m/s
Total mission time: 1.056289421571976e+01 years

This details the exact time and locations of the planetary encounters, the encounter speeds and the magnitudes and times of the DSM. However, even this verbose description isn't enough to fully-specify that trajectory. To do that, one has to examine the list of 42 numbers that fully specify the trajectory. These are as follows:

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)

The number in the first row identifies the start-date for the trajectory in days after epoch J2000.0

The second row has five numbers that identify the initial Earth escape plan for the Aldrin Cycler. The first two specify a direction away from Earth in heliocentric coordinates; the third specifies the hyperbolic excess velocity at Earth escape and the final two numbers specify the arrival date at Mars and the date of a DSM (if any) on that leg of the trajectory.

Next we have nine rows of four numbers - one for each of the successive nine interplanetary legs of the trajectory. The format of these rows is always the same. The first number in the row identifies the orientation of the spacecraft's orbital plane during its hyperbolic encounter; the second indicates the radius of approach at periapsis of that encounter (in multiples of planetary radii); and the last two numbers specify the arrival date at the next planet in the sequence as well as the date of a DSM (if any) on that trajectory leg.

Although you may have to think about this for a bit (as indeed I did) , if armed with a Lambert solver and Keplerian orbit propagator (courtesy of PyKEP), this list of numbers is sufficient to fully specify the Aldrin Cycler trajectory.

Code used to generate the Cycler trajectory
And what of the code used to generate the cycler trajectory? Well, here is the Python script used to generate the above trajectory:

import matplotlib         as mpl
import matplotlib.pyplot  as plt

from PyKEP                import trajopt, planet, epoch
from PyKEP.planet         import jpl_lp
from PyGMO                import *
from PyGMO.problem        import *
from PyKEP.orbit_plots    import plot_planet, plot_lambert

from math                 import *
from numpy                import *


earth    = jpl_lp('earth')
mars     = jpl_lp('mars' )

sequence = [earth, mars,
            earth, mars, 
            earth, mars, 
            earth, mars, 
            earth, mars, 
            earth]

t0       = [epoch(0),epoch(1000)] 

tof      = [[100,200], [500,700], 
            [100,200], [500,700], 
            [100,200], [500,700],
            [100,200], [500,700],
            [100,200], [500,700]]

vinf     = [4.0,7.0]

prob     = problem.mga_1dsm_tof(seq = sequence, t0 = t0, tof = tof, vinf = vinf, add_vinf_dep = True, add_vinf_arr = True)
algo     = algorithm.jde(gen = 1000, memory = True)

l = list()
for i in range(1):
    archi = archipelago(algo, prob, 8, 20, topology = topology.rim())
    for j in range(500):
        archi.evolve(10)
        print min([isl.population.champion.f[0] for isl in archi])
    tmp = [isl for isl in archi]; tmp.sort(key = lambda x: x.population.champion.f[0]);
    l.append(tmp[0].population.champion)
print "Results: \n"
print [ch.f[0] for ch in l]

l.sort(key = lambda x: x.f[0])
x_so = l[0].x
print prob.pretty(x_so, True)
print x_so

In glancing through this script, you might note a couple of things. First, it is short. One of the advantages of PyKEP /PyGMO is that need only use a high-level description of the optimisation task. The rest is carried out seamlessly by PyKEP / PyGMO. This makes solving even really very tough computational tasks something of a breeze.

The second thing to note is that the optimisation sequence talks about 'islands', 'archipelagos', 'populations', 'generations' and 'topologies'. Schooled as I am in more traditional optimisation techniques, my first reaction upon seeing this was "What the ...". But, really, it all boils down to something that is quite simple. The basic mind-set of the underlying PaGMO solver is that it uses a model of 'differential evolution' to try and identify the global optimum of any given problem. In this scheme, on each 'island' (a CPU core) a genetically diverse population of 'individuals' is created. Each 'individual' is identified by its 'chromosome' (the set of 42 numbers) that identifies a particular Aldrin Cycler trajectory. And then a set of such 'islands' is created across multiple CPU cores thereby creating an 'archipelago'. The 'islands' in the 'archipelago' are linked together in a particular way - i.e. by a 'topology'. And this topology identifies how individuals in the various island populations may randomly migrate between islands. And once having set up this system of chromosomes, individuals, islands, archipelagos and topologies, PaGMO allows the populations to 'evolve' by introducing random perturbations in the chromosomes where Darwinian selection is based according to some criterion - e.g., minimising total delta-V of the DSMs of the trajectory. And, if the system is allowed to evolve for long enough, and sufficient migration takes place, the chromosomes of the archipelago population converges upon the optimal Aldrin Cycler solution.

Multiple solutions
And when I say 'the' optimal AldrinCycler, I really mean 'an' optimal Aldrin Cycler. The underlying mathematical problem is non-convex which means that there are a number of local minima - possibly thousands of them. Each is a legitimate solution to the Aldrin Cycler problem, each with different total DSM delta-V characteristics and with different hyperbolic excess velocities. So, if you install PyKEP /PyGMO on your machine, don't expect to get the same trajectory as given above. In all likelihood you will find a different solution. If you don't like the characteristics of that solution then run it again and examine that solution. And keep running the script until you find a solution you do like.

Next steps
Having identified an (albeit truncated) Aldrin Cycler trajectory, I now propose to construct a high-fidelity Orbiter-Specific Cycler ephemeris based on this trajectory.

 

[jedidia]

mmediately, the number of variables needed to describe this problem drops from 114 down to just 42.

Because, of course it would :lol: