Challenge LOP-G to Brighton Beach and Back Again

[Ajaja]

@firefox00
Don't look at RadApo. It's a keplerian apoapsis, not real. You can trust RadPer here (because it's the starting point) but not RadApo.
So, change RadPer to your periapsis (3000km), reduce numbers of orbits to 3 (For I = 1:1:3;), run, apply correction, run again, apply, increase to 4 orbits, run, apply, then 5 orbits, 7 orbits, ...
In such few steps you will get for RadPer = 3000 something like the script in the attachment. I stopped at 11 orbits.
RMAG at apoapsis here is ~69975 km (check "Command Summary" on Propagate2). But it's for the last 11 orbit. RMAG at periapsis after 11 orbits will be ~3053 km ("Command Summary" on Propagate3).

 

[firefox00]

Thank you again for your answer.

To be sure to understand correctly, in the algorithm, you propagate twice over 7 days then minimize the error on the positions and velocities obtained after propagation compared to the initial values. Since the orbit of periapse ~3000km and apoapse ~70000km, shouldn't I propagate over the period of this orbit? Which must be close to 6.5 days or so.

Once convergence is established, I'd like to retrieve the initial conditions from the NRHO orbit for use in a mission. What do you mean when you say the Keplerian apoapsis isn't real? What are the exact parameters to look at for retrieving the initial conditions? How to know the inclination and the other orbital parameters for example?

One last question: the coordinate system you are using, LunaEarth, what does the type ''ObjectReferenced'' mean?

 

[Ajaja]

To be sure to understand correctly, in the algorithm, you propagate twice over 7 days then minimize the error on the positions and velocities obtained after propagation compared to the initial values. Since the orbit of periapse ~3000km and apoapse ~70000km, shouldn't I propagate over the period of this orbit? Which must be close to 6.5 days or so.

Not exactly 7 days. It stops propagating when SC crosses YZ-plane (SC.LunaEarth.X = 0) in the Earth-Moon rotating frame. It's at the apoapsis and the periapsis. And it tries to minimize differences in position/velocity at the periapsis compared to the initial values.
The script above gives this trajectory:

SC.ElapsedDays            SC.Luna.RMAG         
0                         3000.000000000006     
3.234089922767453         71475.45994251811     
6.651159968179854         2966.328346618691     
9.723845427466586         70696.0096427058     
13.10542358085149         2907.66450710233     
16.3279317551569          70500.92748031431     
19.46152104406792         3071.822583078521     
22.95159584977227         70227.75952013436     
25.92054258672579         3288.52004584251     
29.37608398649172         71327.58093011992     
32.62882380691008         3467.112627538062     
35.74488361535259         70495.77196139318     
39.17511554792509         3532.120301729326     
42.27043593360577         70119.53452735113     
45.55336352230734         3264.86771224824     
48.82412947797275         70695.31755150993     
52.02043844385116         3079.014877744439     
55.33651769306744         71373.16584383701     
58.64043455680803         2884.038183791121     
61.77634299037163         71321.8859283878     
65.22951420173558         2942.041603775066     
68.38862034902195         69975.63841048826     
71.49312374291549         3053.746576017844     
74.92178490944934         70698.54991995606

Just remove all the code with optimization (the script in the attachment).

Once convergence is established, I'd like to retrieve the initial conditions from the NRHO orbit for use in a mission.

What are the exact parameters to look at for retrieving the initial conditions? How to know the inclination and the other orbital parameters for example?

Use "Command Summary". Calculate and print in report other initial parameters you need.

What do you mean when you say the Keplerian apoapsis isn't real?

It founds solution with:

SC.Luna.RadPer = 3000;
SC.Luna.RadApo = 92053.89183509667;

But in reality it never gets to 92000km.

What are the exact parameters to look at for retrieving the initial conditions?

To get Orbiter's RPOS/RVEL for example use X/Y/Z/VX/VY/VZ in LunaEc frame but swap Y with Z, VY with VZ and convert km to m. Orbiter uses different-handed frame of reference. And MJD epoch in Orbiter is TDBModJulian+29999.5 epoch in GMAT

One last question: the coordinate system you are using, LunaEarth, what does the type ''ObjectReferenced'' mean?

It's the rotating (non-inertial) Earth-Moon reference frame based on the corresponding position/velocity of the objects - Earth and the Moon.

 

[firefox00]

Not exactly 7 days. It stops propagating when SC crosses YZ-plane (SC.LunaEarth.X = 0) in the Earth-Moon rotating frame. It's at the apoapsis and the periapsis. And it tries to minimize differences in position/velocity at the periapsis compared to the initial values.

Ok, it makes sense, thank you !

But in reality it never gets to 92000km.

How come that RadApo never gets to 92 000km, it’s a physical reason? Then, how to choose RadApo at the beginning ?
By the way, can we really speak of inclination considering theses orbits? Because it's not the same at apo and periapsis.

Use "Command Summary". Calculate and print in report other initial parameters you need.

If I understand correcty, the for loop is there to ensure the repeatabily of the orbit over several revolutions. Then, once the convergence is established, I have to look at the first iteration to get the initial conditions allowing this repeatability, am I mistaken?

To get Orbiter's RPOS/RVEL for example use X/Y/Z/VX/VY/VZ in LunaEc frame but swap Y with Z, VY with VZ and convert km to m.

Why do we have to swap Y with Z?

Last
I changed the coordinate system in the view orbit resource. I used the LunaEc coordinate system and here the result :



How is it that in this coordinate system, the Orbiter does not fly over the poles while it does in the MoonEarth frame of reference? I mean, the NRHO orbit is supposed to be a polar orbit.

Sorry to have so many questions, it's a very interesting problem!

 

[Ajaja]

How come that RadApo never gets to 92 000km, it’s a physical reason?

The spacecraft never gets there. It's NRHO, but RadApo is calculated for an elliptical orbit.

Then, how to choose RadApo at the beginning ?

Just a guess.

By the way, can we really speak of inclination considering theses orbits? Because it's not the same at apo and periapsis.

It varies RadApo and Inclination to find a solution, but the Inclination is a parameter for an elliptical orbit too. RadApo/RadPer/Inclination are just the simpliest way to set initial settings and vary them. I tryed to vary RAAN and AOP too, but found that RAAN=180 and AOP=90 (in LunaEarth frame) are the best values here for such types of NRHO.

If I understand correcty, the for loop is there to ensure the repeatabily of the orbit over several revolutions. Then, once the convergence is established, I have to look at the first iteration to get the initial conditions allowing this repeatability, am I mistaken?

It tries to optimize trajectory and find best values for selected in the for-loop number of orbits. To get initial X/Y/Z/VX/VY/VZ you need to get rid of all of this Vary code and use "Command Summary" or Report. Or just create other SC with the optimized RadApo/RadPer/Inclination/etc in LunaEarth reference frame at the epoch and GMAT will convert to any state in any reference frame you want in the SC settings dialog.

Why do we have to swap Y with Z?

It was an example of conversion for Orbiter. Orbiter uses a left-handed coordinate system, GMAT - right-handed.

I changed the coordinate system in the view orbit resource. I used the LunaEc coordinate system and here the result :

Something is wrong here. In the LunaEc coordinate system it should look like this:

 

[firefox00]

It's NRHO, but RadApo is calculated for an elliptical orbit.

Understood, same for inclination.

Something is wrong here. In the LunaEc coordinate system it should look like this:

I corrected some parameters and this is indeed what I get. But in this coordinate system, the orbit doesn’t appear polar, it might be obvious but how come?

In parallel, I read several articles including this one : https://engineering.purdue.edu/peop...onferences/2018_AAS_WhiDavBurMcCPowMcGHow.pdf

It says that a fast transfer to NRHO can be done in two maneuvers :





On this image, the first one occurs during the flyby, most likely at the Moon’s periapsis while the second one isn’t done at a particular point.
Instinctively, I would have thought that the 2 maneuvers should be done at the periapsis, but that doesn’t seem to be the case. Have you an opinion about it ?
In addition, what could possibly be the role of each maneuver, the first one to change the « inclination » with help of the flyby, and the second to « leave » the hyperbole to put the Orbiter back in the NRHO?
That seems complicated given the very sensitive initial conditions of NRHO.

 

[Ajaja]

But in this coordinate system, the orbit doesn’t appear polar, it might be obvious but how come?

The coordinate systen is nothing to do with this. The inclination is not exactly 90 degrees, so it's not a polar orbit strictly speaking, but it's close enough to the one.

On this image, the first one occurs during the flyby, most likely at the Moon’s periapsis while the second one isn’t done at a particular point.
Instinctively, I would have thought that the 2 maneuvers should be done at the periapsis, but that doesn’t seem to be the case. Have you an opinion about it ?
In addition, what could possibly be the role of each maneuver, the first one to change the « inclination » with help of the flyby, and the second to « leave » the hyperbole to put the Orbiter back in the NRHO?

I think, at the periapsis you don't need to get into the NRHO at once, you just have to make a correction to reach the NRHO "plane" at the point of the planned orbit insertion. And the insertion is easier to make near the apoapsis. Lesser velocities. more time for corrections, more space for fixing potential problems.

That seems complicated given the very sensitive initial conditions of NRHO.

NRHOs are quite robust. Of course, if you are really planning to orbit few months without a single course correction it may look sensitive, but I doubt that it's the case for real missions.

 

[firefox00]

I tried to build a scenario to reach the NRHO orbit (3000/70000km) from Earth. My Orbiter is named Sat.

The first step is to reach the Moon, so I targeted the Moon B-plane to get a plane close to the NRHO one.

Then I tried to reach the NRHO ‘’plane’’.

To do that, I created another Orbiter in NRHO orbit, named SatNRHO, and propagated it a few days to get the insertion planned. The idea is to perform a first DV at periapsis which would allow to intersect the NRHO. The choice of intersection point is arbitrary for the moment.


At this moment, the trajectory look quite similar to the one that I found in the paper aforementioned.

To meet this goal, I propagated my Sat to the same Z as SatNRHO and then tried to optimize the maneuver at periapsis by minimizing the distance between the goal (SatNRHO point) and the Sat, in order to intersect the NRHO. Unfortunately it doesn’t work (see script attached).



I could also just target the SatNRHO point but I don’t know how to handle the propagation before reaching this point, I don’t know where or when to stop given that the Sat is on a hyperbolic trajectory.

For the trans lunar injection, it was pretty simple given that I wanted to reach the Moon periapsis under conditions (B-plane conditions), but in both cases (optimization / target), I don’t know how to propagate.

Do you have any idea?

 

[Ajaja]

It may be easier to find a way to get back from NRHO to Earth using Backward Propagation. But with 2 maneuvers from the scheme it will still be a challenging task.